I'm battling my way through my first design and have come up with this as the decoding logic. I'd appreciate any input from the greybeards.

The address scheme is:
$0000-$7FFF RAM
$8000-$9FFF 8x 1K addressable areas for I/O (VIA, ACIA etc).
$A000-$BFFF 8K ROM
$C000-$FFFF 16K ROM

I'm planning to use two 74HCT00 quad NAND ICs for the decoding (ignore that it says 'LS' in the schematic). One chip is used to select between the 8K and 16K ROMs by connecting to their /CE pins.

Two gates on the other chip control the /CE pin for the RAM.

One more gate's output would be connected to the /OE pins of both ROM chips and the RAM (and, probably, I/O chips). On the main schematic, this is being labelled /READ_ENABLE, which gives a clue as to what my thinking is on this.

I was messing around with e 74HCT138 for selecting between 3 8K ROMs, but I like this idea better. (The 16K would actually be half of a 32K)

Does this make sense?

BTW, this is going to be a SLOW computer. This is for learning, purely. So I'm thinking 1MHz, maybe 2MHz.

_________________
I like it when things smoke.
Blog – Zolatron 64 project

You could consider using three-quarters of your 32KB ROM chip, to save the complexity of externally decoding the distinction between it and the 8KB ROM. I would also use A15 directly as the /CE line for the RAM, and use the two gates thus freed up to generate a correctly qualified /WE signal, which is actually more important than correctly qualifying /OE.

Although you can generate any logic combination using only 2-NAND gates, you might find it more efficient to also consider other gate types, particularly 2-AND, 2-OR, 2-NOR and wider NANDs. This becomes evident when you can write the /24K_ROM_CE equation as ~(A15 & (A14 | A13)); you only need two gates to implement that, a 2-OR and a 2-NAND.

You may already have noticed this, but you can feed the most-significant 6 address lines directly to a '138 to correctly select the 1KB spaces for each I/O device, because it has three CE lines with various polarities.

Here's an alternate arrangement that might interest you:


Some points:

• The split ROM seems to be overkill. The odds are you will never use the 24KB of ROM you envision. My bet is you can get by on less than half of that. The circuit I posted maps in 12KB of ROM, which is a lot of space.
  
  Incidentally, ROM decoding is such that a write to ROM address space will go into the bit bucket—the ROM will not be selected on a write cycle. You can eliminate that characteristic by removing the RWB connection to the the 74AC20 and strapping that pin to Vcc. You would only do so if you are using a ROM that can be written to in-circuit.
  
  
• The above circuit can map in up to 48KB of RAM (which you can do with a 64KB SRAM—they are readily available). RAM is like money: you'll never have enough. Grab it while you can.
  
  
• Allocating 1KB per I/O device is wasteful. The above circuit maps I/O into pages, using 2KB total, and gives you some expansion capability. You could add another 74xx138 with a relatively trivial circuit change and have eight more I/O devices in the $C000 range.
  
  
• I included a properly-qualified read/write generator for use with the SRAM, ROM and any I/O device that is not a 65xx peripheral.
  
  
• The circuit is arranged so no more than two gates are between the address bus and any chip select. That gives you plenty of timing headroom. Although I show 74AC logic, you can do it with 74HC logic and still have 8 MHz capability if you are feeling adventurous.

Incidentally, chip selects should not be qualified with Ø2 as you are doing.

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

If I may... another two chip solution for a simple system with a 32K RAM and a 32K ROM that allows inserting a variable size block into address space for I/O... Half of the 74HC139 provides the active low chip select signals for RAM and ROM and the other half of the 74HC139 provides the Ø2 qualified /RD and /WR signals. Of course you could eliminate the I/O configuration jumper block and hard-wire the 74HC688 "8-bit Identity Comparator" circuit for a specific I/O block address and size.

Have fun. Cheerful regards, Mike, K8LH

Thanks everyone. A lot to digest there, but great suggestions.

I had, indeed, planned to use a 138 for decoding the I/O space, but it hadn't occurred to me to shove that further up the map to get more RAM. That's definitely worth a shot.

Also, I divided the ROM space into separate 16K and 8K because, lurking in the back of my mind, was the idea that I might swap the 8K ROM for 8K RAM and use that for something specific, like display memory. But that wasn't ever anything more than a vague notion, and having 48K RAM contiguous makes a lot more sense.

So, back to the drawing board... literally...

_________________
I like it when things smoke.
Blog – Zolatron 64 project

Okay, so I've simplified a bit (and I am trying to keep this as simple as possible).

Address map is now:

$0000-$7FFF RAM
$8000-$BFFF -- unused: for future RAM expansion --
$A000-$BFFF 8x 1K addressable areas for I/O (VIA, ACIA etc).
$C000-$FFFF 16K ROM

Why the unused bit? Because I only have 32K RAM chips! I'll save the 40K expanded RAM for the 'Plus' version of the computer. 32K will be enough for my needs right now, but I intend to bear in mind the expansion when designing the circuit.

The attached new version of the decoding now includes the 74HC138 used for selecting the 1K I/O slots. (Ignore the chip designations for the NAND gates - I'm just using Kicad as a scratchpad to work out ideas – what my wife calls 'twotting about').

_________________
I like it when things smoke.
Blog – Zolatron 64 project

That looks good, Steve.

May I mention one advantage using a 64K or 128K RAM chip instead of a 32K RAM chip in your design, even if you're only using 32K? The 64K and 128K RAM chips have a second chip select input (CS2) which is active high. Driving CS2 with the Ø2 signal fully qualifies the RAM /OE and /WE signals. No logic gates... No propagation delays...

If you want to try this you can get a single skinny 64K RAM chip (W24512AK-15) from this Chinese vendor for 52 cents, including shipping. The chips are "pulls" but the few I have received are in good condition and tested good (see below).

Have fun (I know you will as I've been subscribed to your blog for about a year now).

Cheerful regards, Mike, K8LH

Oh okay, did not know that. Thanks for the tip.

_________________
I like it when things smoke.
Blog – Zolatron 64 project

It also causes a performance reduction in most devices, since most respond more quickly to /OE and /WE than they do to /CS or CS2. Also, qualifying a chip select with Ø2 means the device will not be ready for access until well after Ø2 goes high, which will become important as the clock speed is ramped up.

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

I suppose you're right. That 15-ns part won't be ready until a whole whopping ~15-ns after the Ø2 rising edge. But, isn't that pretty close to when you'd get the active low chip select signal through your ~14-ns decoder logic when running with a 14-MHz clock? Isn't TADS something like 30-ns with a 14-MHz clock?

Am I wrong to think that as long as you're using ROM in the design, that will probably determine your speed/performance limits before a high-speed RAM and a high-performance selection method comes into play?

Cheerful regards, Mike, K8LH

Yes; SRAM comes in speeds faster than anything else you'll be putting on the bus. I've seen SRAMs down to 6ns. 10ns is quite common; 8 and 6 less so. In any case, the data will be ready well before the processor's read setup time tDSR, IOW, before the processor needs it. The data doesn't need to be valid and stable before tDSR which is specified to be 10ns before the fall of phase 2. It's no problem if it is of course, but you don't really gain anything by it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Probably. When I was researching chips for my Ruby project ROMs did appear to be the limiting factor - so I didn't use any. Ruby runs at 16Mhz.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Most ROMs still have significantly longer access times from /CE and address change than from /OE. That means you can as much as double your maximum usable clock speed, even with a ROM on the bus, by using the proper decode circuits for /CE and /OE; make /CE depend only on the address (which becomes valid quite early in the Phi1 phase), and derive /OE from R/W and Phi2.

A bog-standard 200ns ROM should therefore be usable to 4MHz or so. That's already faster than most 1980s 8-bit micros. Add a wait-state to double the speed again when *not* accessing ROM.

EEPROMS and EPROMS in the 35-45 ns range are usually not too hard to find. I have one design around the W65C02 that will run reliably to beyond 18MHz without wait states using a 45ns EEPROM. ROM speed is probably the limitation just because the access time specification is being exceeded, but this is not necessarily so. It could be the W65C02. I've never really tried to find what causes it to get flaky at 19+ Mhz. It won't run at all at 20MHz but I'm fairly sure it's not being limited by the 12ns RAM I'm using.

_________________
Bill

One of the advantages of the large RAM sizes we can buy these days is that it should be no great cost to have RAM underneath the ROM, run a copy loop at boot time, with wait states or a slower clock, then map out the ROM leaving just RAM and go at full speed.

Not that this is a simplest-possible design any more. But it only comes into play once you start looking at speed and worrying about ROMs being slow.

(For extra points, the RAM living in ROM space could also be made write-protected.)