Hello all,
with this post I’d like to talk through my design and ask you guys for advice and suggestions.

As I’m developing and prototyping MARC-3, I decided to follow Daryl Rictor’s “SBC-4 Plus” design and Garth Wilson’s “Expansion Buses and Interfaces” primer and won’t go with the processor's own buses off the board.
http://sbc.rictor.org/sbc4.html
http://wilsonminesco.com/6502primer/ExpBusIntrfc.html
I’ll put CPU, RAM, CPLD, ROM emulator and an expansion port on one board. The CPLD and two 74HCT245’s will buffer all signals on the expansion port. I hope this will result in more speed and stability.

Here is the schematic of the main board:


I’ll try to describe the functions of the major components is some more detail:

ATmega1284P:
Connects to A0..A13 (to directly access 16KiB), D0..D7 and the RAM control signals. It will feed the system CLOCK signal to the CPLD, which will be divided by 2 to provide a strong and symmetrical PHI2 signal. It will also provide a debounced active low N_RESET signal to the CPLD. Those two last signals are connected to the common CPLD clock and tristate inputs. The reset button input and the one free I/O pin are connected to a solder pad, they are the serial communication pins of the AVR. There’s a reset button on the board, but also pads to connect to a separate button on the computer case.
During RESET, the ATmega1284P holds the N_RESET line low while it copies the desired program(s) to RAM. Once done, it becomes transparent and releases N_RESET and the 65816 starts executing instructions from RAM.

XC9572-7PC84C & WDC65C816S:
All CPU pins are connected to the CPLD, except for the ones I don’t intend to use: VPB, E, MX, MLB and ABORTB. These are routed from the CPU to the CPLD pins but separated by a jumper. So I can either connect them or use the CPLD pins as spares for other purposes. The CPLD is also connected to A16..A18, N_MEMWR, N_MEMRD, RAMCS0 and RAMCS1..RAMCS3 solder pads to provide a maximum of 2MiB RAM.
The CPLD provides the following functions:

System clock generator / divider.
• A maximum of 2MiB address decoding through four RAM chip selects and 19 address lines using the upper address lines provided by the 65816’s data lines during PHI2 is low.
• Memory read write qualification with PHI2.
• Reset / tristate circuit.
• IRQ and NMI handler.
• I/O chip selects.
• VDA VPA address qualification.

During RESET, the CPLD holds the RESB and BE lines low, so that the CPU is transparent. All other I/O devices are also deactivated. The RAM chip selects are set to “111Z”, so that only the first SRAM chip is accessible by the AVR. The address lines A18..A0 are set to 000 11ZZ ZZZZ ZZZZ ZZZZ. That way the AVR is able to copy the program(s) to RAM from $00C000 - $00FFFF. After the AVR releases N_RESET, the CPLD does its normal business.

AS6C4008:
This is a 512KiB 55ns SRAM. A0..A13 are connected to CPLD, CPU and AVR. A14 and A15 are connected to CPLD and CPU. A16..A18 are only connected to the CPLD. Initially there’s a single 512KiB SRAM chip. The RAM is expandable by piggybacking additional SRAM chips and tying their chip selects (RAMCS1..RAMCS3 solder pads near the RAM chip) to the CPLD accordingly.

EXPANSION PORT:
Is a 50 pin IDC header which connect CPU pins buffered through two 74HC245’s: BPHI2, BRWB, BRESB, BA0..BA4 and BD0..BD7. Also N_MEMWR and N_MEMRD are provided. All remaining unused CPLD pins which will serve as chip selects, IRQ inputs etc. for I/O devices. There are several remaining pins on the header which will be connected to GND and VCC. I hope these arrangements will be adequate for a decent expansion port and will result in better performance.

A few of my questions are:
Are the 74HCT245’s direction configured the right way around regarding RWB? Do the I/O devices even work correctly with those buffers, arranged that way?
I think I have all needed signals on the expansion port, and also added several VCC and GND lines to it. Did I miss some?
Did I cover all the CPU’s “mystery” pins correctly?

_________________
Marco

It's a nice-looking list of features! You'll have fun with this. But I have to say, I hate these so-called schematics that are mostly text -- basically just a net list. You have to go searching to find the destination point (or points? who the heck knows) of any given signal. In order to make any sense of this image I had to download it and mark it up. I'm just sayin'.

MX will almost certainly never be used; I wouldn't even bother giving it a jumper option. VPA might be useful but it's unlikely; I'd jumper that one. (VDA is the important one. Arrange things so I/O devices get no chip-select unless VDA is high.)

Not "1110"? Just checking.

Yes. And the mystery pins seem alright; just remember that ABORTB etc, if unused, need to be held high by the CPLD.

Good question. Right now you have I/O and memory tied straight to the CPU data bus, and I'm uneasy about that. The '816 is hard to get along with in regard to brief transients of contention on the data bus. The '816 data bus is multiplexed to also carry address info, and that means you don't get a half-cycle of dead time to act as a timing cushion between transactions. (I talk about '816 bus issues here.) With no timing cushion it becomes difficult to achieve a graceful handover during the tiny fraction of a cycle during which the bus is released by the CPU and asserted by another device (or vice versa). In this regard it's an advantage if you insert a '245 transceiver between the CPU and memory/IO. The '245 has to play nicely with the CPU but at least memory and I/O can deal with a more relaxed, 6502-style non-multiplexed data bus that has 50% dead time. (The 245's /OE would be driven by /Phi2.)

Another reason to insert a '245 transceiver is to ensure the '816 gets the CMOS voltage levels it (supposedly) requires. (You'd use a "T" type part, such as 74HCT245 or 74AHCT245, which can input TTL levels and output CMOS levels.) Many modern memory and I/O devices only output TTL levels, which theoretically are insufficient for the '816. It's possible to ignore this issue, and in real life lots of people have gotten away with doing so (and ignoring the transient contention issue, too). I'm just making sure you're aware so you can decide for yourself.

Edit: rather than using an actual '245 you may instead wish to use the CPLD to implement the transceiver function.

Finally, you've provided a '245 to drive the off-card data bus, and its /OE should be driven by /Phi2 (rather than being grounded). Having that transceiver active 100% of the time certainly won't help, and it might hurt. Ideally you want the bus to float when it's not actually doing anything. (It's that 50% dead time which makes a 6502 data bus so forgiving.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Sorry about that, I didn’t realize that the schematic is that hard to read this way. It just looks more tidy.


No I’m using the AVR to control chip select. That’s seems and might be unnecessary but i might use that line later as an input on the CPLD.


OK, that’s a new perspective for me. Does that also mean there would be a higher maximum speed for the ‘816 possible?


Indeed my SRAM has TTL output levels, and like you said, I hope to get away with it.


OK, I’ll change that. So in essence that releases the ‘816’s data bus, and potentially would provide a better performance?

Thanks for the confirmation of the direction of the buffers. Btw. I took PHI2 and RESB off the buffer because they are generated by the CPLD, so they go straight to the expansion port.

_________________
Marco