Prompted by a nearby thread, I wondered if there's a possibility of a six-chip 65816 design, or anything close to it. No programmable logic, of course, to make it a meaningful challenge, and it must have at least 128k of RAM and make use of the 816's extra address bits.

I won't say more, as I wouldn't want to limit creativity by over-specifying. And the most interesting and inventive design might not have the absolute lowest chip count.

Have fun!

Does the six-chip count include all devices or just the glue logic? I won't say it can't be done, but a six-chip design with extended addressing will be tough, especially so if you don't want anything in bank $00 being mirrored in bank $01.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Don't worry about the six. That's just a number from Grant Searle's 8 bit designs.

I think it could be done with 8 chips if the oscillator does not count, 9 if it does.

The reference design (4 chips) one of which would be a 3, 4 or 6 gate chip with inverting outputs, plus one other gate chip, a static RAM, a ROM of some sort and an I/O (65C22?). There would, of course, be a lot of mirroring. You might be able to use another ROM instead of the gate chips to reduce the count to 7, if that would be allowed. Of course, it would not be a fast machine in that case.

Shame we can't use a GAL or the like. Programmable logic really is a valid approach and it's hard to find a design since the early 80's that did not use either programmable logic or custom ICs.

Edit:

Would something like this work for the glue? Outputs going to the chip selects


You would have 2 inverters left over.

_________________
Bill

Out of reset, you need ROM at the top of Bank 0 to provide a vector and a handler routine. That's no different from a 6502. So that doesn't seem to work if you're only decoding with A22/23, since you have all RAM in Bank 0, and the ROM is all in high banks.

I'm pulling something together with the idea of using the E (Emulation mode) output to toggle mapping a 32KB ROM into the high half of Bank 0. In Native mode it would be mapped high instead, and wired so that you can rewrite it in-circuit.

I think I now have a core design (no I/O devices, just a select line for them) which interfaces to an '816 "properly" using 8 ICs:

1: The CPU itself.
2: a 512Kx8 SRAM
3: a 32Kx8 EEPROM
4: a '573 transparent latch
5: a '138 decoder
6: quad NAND
7: quad AND
8: hex inverter (of which one unit spare)

To this, add a reset controller (I'm using a DS1818-10 plus a manual reset button) and an oscillator (here an LTC6900 set to an unambitious 4.25MHz, but a crystal can would also work), and the usual array of resistors and capacitors. The components are chosen to be capable of operating within spec at 3.3V, and to at least tolerate 5V without damage. Clock speeds will primarily be limited by the 200ns addressing latency of the EEPROM, given that wait-states are not implemented (but provided for).

In native mode, RAM fills the first $80 banks, mirrored; in the other banks, the ROM is mirrored in the upper half and the I/O in the lower half of each bank. In emulation mode, to facilitate bootstrap, the ROM replaces the upper half of each bank of RAM and (for reasons of gate shortage) does not appear in the upper banks. The reset handler will be expected to move itself into accessible RAM, enable native mode, then copy the ROM back into its original position which is now RAM.

My design is a bit more than minimal, in that it's designed to allow a novice builder to extend the functionality without immediately having to redesign parts of the core to account for corner cases. Address selects are properly qualified by VDA/VPA (so there are no concerns about stray accesses during dead cycles, and all devices are deselected during WAI), and the bank latch is properly qualified by RDY (so wait-states can be added to improve performance, especially given the slow EEPROM I found to work at 3.3V LVCMOS). It should therefore be easy to add a choice of I/O peripherals - such as a UART.

One advantage of designing for 3.3V is that a UART capable of operating at that voltage would be able to interface directly with a Raspberry Pi without level shifters. I'm sure many would find that convenient. But it does mean that the EEPROM and the oscillator are surface-mount parts requiring more care in soldering. The EEPROM can be reprogrammed in situ since I've connected the /WE line, but it might be prudent to solder it to a PDIP carrier board so that it can be transferred to a normal programmer in case of inevitable bugs and fat-fingering.

Diagrams to come later…

Ed's challenge said the a 128K RAM would be used. So only A16 has to be included in the logic.

I have a logic design that doesn't mirror anything in bank $00 into bank $01. RAM is contiguous from $000000-$00BFFF and from $010000-$01FFFF. A total of seven logic ICs is required, including a flop to generate Ø1 for latching the bank and an inverter to tell the glue logic if the address is in bank $00. The flop could be eliminated and one section of the inverter could be used to generate Ø1 from Ø2. The glue logic would be reduced to six devices. That arrangement, however, would have timing problems at higher clock speeds and likely not work.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Nice! I rejigged your list, to illustrate something: I reckon the first 4 lines are obligatory, modulo the size of the RAM and the width of the latch. (I'll hand-wave the clock can and the reset circuit.) So the question is all about the glue logic: how simple it can be, and how few logic chips it might need to implement it. I would expect 3 chips to be possible, maybe even 2, but it seems a push to get it down to 1. 4 chips should be comfortable, I would hope.

Oh, but I notice something: this list has no I/O devices! I rather imagined we'd need something, either a VIA or a UART. (A from-scratch 8 bit port will take more chips than a VIA so feels unlikely to work out for this challenge.)

It feels to me that the RAM's positioning in the memory map is an important decision. It feels like putting RAM in the bottom half of every bank will be simplest, but doesn't feel great. The next simplest might be RAM in the bottom half of bank 00 and in one or more full banks above that, with 32k of the RAM being inaccessible (but that's fine.)

I'm imagining that bank 00 pretty much has to end up as 32k RAM, 16k I/O, and 16k ROM, very loosely decoded.

A VIA or UART can simply be plugged into my design with no additional logic, besides any support hardware a UART itself needs (its own oscillator or crystal, for example). Fitting more than one such device will require an extra layer of decoding, ie. another '138. Note that I have not put I/O in Bank 0; it's always in a high bank, even in emulation mode (when it can still be accessed through long addressing modes).

Of course fewer glue logic gates can be achieved by reducing functionality of the core design, or making the memory map a bit less convenient to work with. Cutting out the RDY, VPA, VDA handling would save approximately one IC, at the expense of having to completely rework the design when that functionality is needed for later expansion. One weird option here is to use two RAM devices, one dedicated to Bank 0 and the other mapped to a higher range of banks. Even the "obvious" design choices are not necessarily inevitable.

Ah yes, sorry, the '138 can do a lot for you!

I did have a thought: putting I/O in a high bank could simplify the decoding, for a trivial cost in access time. We can use some lazy decoding of some high address bits to make life easier. Maybe something like this:
A23 high -> I/O selected
A22 low and A14 high -> ROM selected
A21 low or A14 low -> RAM selected

I would use A15 rather than A14.

It occurs to me that I could try using a dual 2-to-4 decoder instead of the '138 I currently have. Time to go digging in the datasheets again…

…ah yes. Substitute the '138 for a '139, and the quad 2-AND for a dual 4-AND, and we end up with a much cleaner memory map (albeit with no spare gates left over).

The first half of the '139 selects on A22/23, dividing the address space into generous 4MB chunks, and is gated by (VDA | VPA). The upper three map directly to RAM, ROM and I/O in ascending order. This arrangement allows accessing the whole RAM chip in any mode, via long addressing, and also gives a way to read and update the EEPROM from native mode. Putting I/O in high banks offers the simplest decoding strategy for an '816.

The second half of the '139 is gated by the lowest selector from the first half, and selects on A15 and E. When both are high, the ROM is selected. The other three selectors from this half go to the RAM. Hence the upper half of Bank 0 (and of every bank up to $3F inclusive) is mapped to the ROM in Emulation mode, and to RAM in Native mode, while the lower half of these banks is always RAM.

This does involve a fairly long maximum gate chain in the decoding logic. It starts with inverting VDA and VPA to feed an AND gate (effectively an active-low OR gate), which gates the first half of the '139, which in turn gates the second half of itself, then finally the ROM selects are driven through a NAND and an inverter. And the ROM is already the slowest device in the system. Clearly there are advantages to using a GAL here, though it does require that the builder have access to a reliable GAL programmer.

I promised diagrams, so…

If we discard the handling of VDA, VPA and RDY, and also forego the address space switching which allows putting the interrupt vectors in RAM rather than ROM, then we can in fact get down to 2 chips of glue logic rather then 4: a quad 2-NAND and a '138.

Three of the 2-NANDs are first set up to generate qualified /OE and /WE in the normal way, using one of them as an inverter. The fourth NAND is then used to simply invert Phi2 to gate the address latch.

The '138 is then used in the conventional way to decode addresses. The address lines it selects on are A23, A22 and A15. This puts RAM in the bottom half and ROM in the top half of every 64KB bank in the first 4MB. There are then six active-low selectors for use with whichever I/O and/or memory devices you like, which are again split between low and high halves of banks in successive 4MB ranges.

Because A15 is permanently tied up in a decode function, it should be skipped when wiring up the address inputs of memory devices, resuming with A16 and up. For the 512Kx8 device, substituting A15 with A19 should suffice.

I like it!

I feel there might be some advantage in using some high address bits as one-hot, or one-cold, decodes. There would then be some addresses which would cause contention if read, for a little extra frisson.

I'm coming to like the use of E to select the ROM, although I see that's not in this latest idea.

Ideally for me we'd see a large contiguous image of the RAM chip over several banks, but not necessarily starting at bank 01. Having a half-bank in 00 is fine, of course.

It does strike me that this latest idea with a goodly number of 32k chunks of RAM would be easy enough to handle, if the OS' memory allocator just pre-allocates the missing bits. The largest allocation would of course be 32k, but that's enough for most purposes. No reason why a linked list couldn't grow to a much larger size, even if each element is capped.

For me this is all fine, in any design which has a highest-priority requirement, in this case simplicity of the glue. Something has to give. Other threads deal with other priorities amply well.

Sounds to me like a reasonable option, given that many I/O devices have no need for protection against spurious reads.

Of course the 6522 and 6551 are notable exceptions (and popular choices for 65xx systems), but their protection requires zero gates. Assuming the active-high Chip Select input is otherwise unused, it can simply be connected to VDA. (VPA can be ignored... unless you intend to execute I/O device's content as if it were code!)

-- Jeff

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