Close
0%
0%

65C816 for RC2014

A 65C816 CPU board for the RC2014 bus

Similar projects worth following
This board provides a 65C816 CPU for the RC2014 bus. I/O is mapped at $FE00-$FEFF and the glue logic generates the expected RC2014 signals (MREQ, IORQ, RD, WR etc). M1 is simply pulled high.

From a software perspective it should look identical to the 65C02 board except to 65C816 aware code and badly behaved stuff.

Software currently includes a simple CF boot ROM and Fuzix. These are the same versions as the 65C02 card uses. Fuzix detects the 65C816 and has fast paths to use mvn/mvp in some hotspots, as well as some magic in the C library code to deal with setjmp/longjmp special cases for 6502 banked, 65C816 24bit linear and 64K banked modes.

Porting DOS65 and other projects ought to be fairly simple.

The basic design of the board is much the same as the 65C02 board combined with the standard glue used to attach 65C816 processors to a 6502. The big difference between the 65C816 and the 65C02 is the clocks. It also shares the obnoxious design 'feature' with the WDC 65C02 that is absolutely no hold on the data/address at the end of the bus cycle. (Classic 65C02 processors have 30ns).


To compensate for this U4 is used to generate a delayed clock which drives the processor. The original clock drives U3 which is used to drive the RD and WR signals. This ensures that RD and WR go high before the end of the bus cycle.


U2 and U3D generate the MREQ signal and usually the IORQ signal. It's possible to disable IORQ and this will be used for the protected mode MMU board. The NMI and vector pull signals are provided on a jumper for the MMU board.

The CPU speed you can reach will depend upon the other boards in the system. The banked memory card in particular is designed around a 7.3MHz Z80 processor and uses 55ns RAM as well as 74HC670 parts in the fast path.

Note: For reliable operation it seems to be essential that U4 is a 74HC00 not a 74AHC00 as shown on the schematic. Whilst using all 74AHC parts gives enough propagation delay to get the signals in the right order some RC2014 devices need a longer write hold than it provides.

65c816mini.zip

Gerbers

Zip Archive - 84.96 kB - 06/19/2020 at 19:12

Download

lib - 11.03 kB - 06/19/2020 at 19:10

Download

65c816-mini.pro

Kicad 5

x-kicad-project - 3.87 kB - 06/19/2020 at 19:10

Download

65c816-mini.pdf

PDF of schematic

Adobe Portable Document Format - 56.99 kB - 03/25/2020 at 22:33

Preview
Download

65c816-mini.kicad_pcb

Kicad PCB layout

x-kicad-pcb - 356.59 kB - 03/25/2020 at 21:09

Download

View all 6 files

  • 1 × 65C816 CPU
  • 2 × 74AHC00 Logic ICs / Gates and Inverters
  • 1 × 74HC688 Electronic Components / Misc. Electronic Components
  • 1 × DIP8 can oscillator
  • 1 × 10K resistor

View all 9 components

  • Performance: continued

    EtchedPixels08/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

    EtchedPixels06/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

    EtchedPixels03/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

    EtchedPixels03/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 4 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates