BigEd wrote:
Do you want to restrict your I/O mapping to Bank 0? It would be conventional to do so, but it's a free choice. If your I/O mapping were as large as say 16k (pretty much the simplest possible decoding) then "wasting" 16k of each 64k bank might feel wrong. But if your I/O mapping were as small as 256 bytes, you might not care so much.
What this exposes is the interplay of your system design decisions and your software environment. How do you intend to use the many high banks of your machine? In particular, do you expect them to be contiguous, so a structure reached by a three-byte pointer might span a bank boundary? (Maybe a structure can even be larger than 64k?)
Choices, choices... this is the nature of engineering.
Ya, since day one this design has been a new choice every 5 minutes.
I worked on it last night, I think this is how I want the memory map to go and I have an idea I'll explain afterward for it:
Address map:
0x000000 0000 0000 0000 0000 0000 0000
RAM - 32k
0x007FFF 0000 0000 0111 1111 1111 1111
0x008000 0000 0000 1000 0000 0000 0000
I/O - 16k
0x00BFFF 0000 0000 1011 1111 1111 1111
0x00C000 0000 0000 1100 0000 0000 0000
ROM - 16k
0x00FFFF 0000 0000 1111 1111 1111 1111
0x010000 0000 0001 0000 0000 0000 0000
RAM2 - 4M
0x40FFFF 0100 0000 1111 1111 1111 1111
and I've been thinking about adding a "ROM2" above RAM2 that has some more EEPROM space (also, the low EEPROM space (0x00C000-0x00FFFF) will be writable via a selectable dip switch, so once I'm confident the machine won't write garbage over my fresh kernal/bios/boot up sequence, I can develop updates on the machine for itself. I may do the same for ROM2 if needed).
My idea right now is, I can do some "normal" address decoding in the low order 16 bits, by this I mean a setup that's fairly standard, like the 3 to 8 decoder for IO, and using the highest address lines to select ROM and deselect RAM. Then, I can run the top 8 bits through 3 triple input nor gates, and run their output through a single triple input or gate (kicad didn't have one of these in DIP format so I just used 2 more nor gates which ends up at 3 gate delays). I can then take the result from this and us it to deassert all CEs for any chip that's in the low order 16 bits, thus creating a sort of 2 part system. I'm going to look around today for a DIP format triple input OR gate, and that will keep me at 2 gate delays for this high order mask.