Project Logs

Collapse

• Errata

  EtchedPixels • 07/15/2021 at 12:12 • 0 comments

  There are two errata I know about on this board

  1. The XM line is pulled up. It's acutally an output. R2 can be omitted

  2. (v0.2 only) E is placed on the system clock line not the clock as it should be (the CPU clock is the E clock in the motorola sense. Ben's 6522VIA card uses CLK and nothing yet uses the separate E clock so this causes no problems. If needed just wire CLK to pin2 of the jumper). The confusion is because the E pin on a 6502 has nothing to do with the motorola E clock.
  

  It should also be possible to omit R4 as the RDY line has an internal pull-up

• Performance: continued

  EtchedPixels • 08/19/2020 at 12:22 • 0 comments

  Having finally had a chance to get a 74AHCT139 I've been repeating my tests. With the 74AHCT139 instead of the HCT139 in the 512K ROM/RAM card all appears to be stable at 7.37MHz
  

  I also now understand why my timing calculations were off. I was not allowing for the skewed clock used to give a write hold (the 65C816 having none). That of course takes about 30ns off the available time. Possibly that could be shortened but some of the other devices like the 165C550A seemed to get upset without a reasonable duration.

  Nevertheless at 7.37MHz even running 8bit mode code generated by cc65 the board feels fast at most things. If there was a usable 16bit mode compiler for this it would be way faster. Not only does the 65C816 execute instructions in far fewer clocks but in 16bit mode  it can do things like a 16bit indexed add of memory to accumulator, whereas the Z80 takes a significant hit the moment you can't juggle most stuff in registers.
  

  The other option would be to replace the clock skewing with additional buffer chips and direction logic but given skewing works I think this project is done for now.
  

• Performance

  EtchedPixels • 06/19/2020 at 19:46 • 0 comments

  3.6MHz appears to be reliable and within the timings for the 512K banked memory card. Going to 7.3MHz it becomes unreliable. I am not entirely sure why as it ought to just about work.
  

  At 5MHz you get 160ns for the entire memory cycle. The slowest memory is the flash ROM (70ns), and the RAM used is 55ns. That sounds like a lot of room but each access also goes through a 74HC670 and a 74HC139 in series which in turn drive the chip select.
  
  By 7.5MHz you get 110ns for the cycle. It almost works.. but not quite. The 74HCT139 can be replaced with a 74AHC(T) part (8ns propagation delay) but the 670 is not it seems available in high speed forms (ALS or AHCT) except as an old Soviet ALS670 equivalent.

  Need to see what a 74AHC139 does to it next experiment.

• Fuzix now running

  EtchedPixels • 03/27/2020 at 16:37 • 1 comment

  With a bit of poking around the current git head of Fuzix now runs as expected on the 65C816 board. Although it all runs in 6502 mode I've taken a moment to detect a 65C816 and add optimizations in fork() to use MVN. There are a few other spots that would benefit similarly that I need to look into.

  
  At the moment I am still running at 1.8Mhz. It should be possible to run a bit faster even with the current memory board.

• Board Bring Up

  EtchedPixels • 03/25/2020 at 21:13 • 0 comments

  At the moment this board works with the 65C02 boot ROM as expected. Fuzix crashes early in user space because the userspace contains magic code to handle flat 65C816 mode that doesn't yet cope with finding a 65C816 operating in banked memory fashion.

  Other properly behaved stuff should all be fine.

View all 5 project logs