RETRO-65C816
Contents
Features
- 65C816 CPU
- 3.3V
- 8 MHz
- All pins are brought to FPGA
- Address A0-A15 and Data lines also go directly to the SRAM
- FPGA can have the ROM internally or download it to the SRAM
- 1MB SRAM
- 45nS access time
- USB B
- FTDI USB to TTL
- Tx/Rx LEDs
- VGA
- 2:2:2 R:G:B
- PS/2 keyboard
- 5V KEYBOARD
- Level translator to 3.3V for FPGA
- SD card socket
- Full-sized SD
- QMTECH FPGA card mounts on top
- 95x95mm card
- ODAS form factor
- (4) 6-32 Mounting holes
65C816 CPU
Block Diagram
Timing
Mechanicals
References/Notes
- On the usefulness of 65816 as a 65C02 alternative
- Helpful timing information
...potential for data bus contention during Ø2 low. My solution was two-fold: use VDA and VPA to qualify chip selects, and qualify read-accesses with Ø2. The former assures that an addressed device will not respond to selection until the address bus is truly valid—invalid bus states may occur during the execution of some instructions. The latter assures that a selected device will not drive the data bus when the '816 is presenting A16-A23 on it. This solution doesn't totally eliminate the risk of contention but greatly narrows the window of opportunity for it. The need for more stringent qualifying of D0-D7 would depend on the peripheral silicon on the bus. In the case of POC and the Ø2 rate I'm using (12.5 MHz maximum), everything gets off the data bus before the '816 starts to drive it with the bank address. That would not be the case if I were to increase Ø2 to 20 MHz, however. Floating the buses with BE creates the odd situation where no valid address exists on A0-A15, which I daresay could cause a device to be selected solely because of a residual charge in bus capacitance. Also, BE floats the RWB signal*, which may trip up other logic that is dependent on RWB always being driven to one state or the other. The most fool-proof solution is the use of a data bus transceiver as you suggested, which is a straightforward method (74AC245 or 74AHC245 recommended if Ø2 will exceed 8 MHz).
