So I was lying awake last night thinking about I/O holes.

I am much in awe of the clever address decoding that Garth describes in his primer, which leverages the multiple Chip Select lines on 65xx devices, though I've always wanted to minimize the size of the I/O region because it obscures the RAM or ROM that would otherwise appear in the region.

With my FPGA-based design, it's easy to decode regions as narrow as a single byte, and thus keep the region small. In my purer design, I like an I/O page decoded with a 74688 further divided by a 74138 in to 8 peripherals with up to 32 registers each. I keep changing my mind about whether the I/O page should obscure RAM or ROM though.

After chewing the cud, I now wonder if the on-MCU parallel ports of the 6510, 8501 and similar were added with banking out I/O in mind as the Commodore 64 does to access 65,534 bytes of contiguous RAM. Banking RAM and ROM is still possible even if the I/O is always mapped such as on the Commodore 264 series, though the I/O region (many pages) renders unusable not just a region of the KERNAL ROM but also the HI ROM of the function software and cartridge ROMs.

Gah! It's enough to make me wish for the separate I/O space of the Z80, though I think I'd then wish that it were 16-bit wide and use it for extra RAM and/or ROM and be back to square one.

Of course you could still bank out the I/O without an on-MCU parallel port but that would involve a write to an I/O register, which would then be unavailable for banking the I/O back in.

So that's when I wondered: Would it be practical to bank out the I/O and start a counter that would automatically bank the I/O back in after 256 cycles? That should be enough time to usefully use the RAM or ROM underneath the I/O region.

Has this been done before and if so, what are the drawbacks of this approach?

_________________
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?

That's a good point, and thanks for the great section on address decoding in your primer. That explains why that build worked at 3 MHz but not at 6 MHz (5V, 74HC).


I see the bigger picture there. 256 bytes out of 32K is not a lot (< 1%) and if I really need that 256 bytes then I likely need much more (banked).

I think it just offends my sense of order that the RAM or ROM underneath is not available (though my inefficient coding is much more wasteful and that doesn't bother me!), so "practical" was perhaps a poor choice of words and I just wonder if it's practicable as an academic exercise.

One reasonable option would be to insert a 256-byte hole for all I/O to use, and then decode that hole as deeply as you like - but also insert a wait-state for any access to that hole. Then it only matters that you can reliably decode accesses to RAM and ROM at full speed. Many I/O devices may need a wait-state anyway.

Using a CPLD, you can easily manage your I/O with granularity and not waste much, if any space. My recent project uses an ATF22V10 to provide a single glue logic solution. It provides phase 2 clock qualified memory read and write signals, RAM and ROM selects along with five I/O selects which are 32 bytes wide. Out of 64KB, you only lose 160 bytes of memory space. Think about 160 bytes of I/O... that's a lot... you can have two NXP DUARTs (four serial ports), two 65C22s (four 8-bit parallel ports, 8 timers, etc.), a RTC and IDE interface and you still have two I/O selects left for whatever.

For my own systems, I always allocate page $FE for I/O space. My simple reasoning is, you have Page $00 which is special, followed by page $01, which is the stack at the bottom of the memory map. At the top end of the memory map, the CPU vectors (reset, IRQ and NMI) are at the very top of page $FF, so in my view, using I/O at page $FE can give you a solid 63KB of memory in the middle. I use page $FF for some required ROM based routines and a JMP table to BIOS related functions.

_________________
Regards, KM
https://github.com/floobydust

As an aside, the BBC Micro reserves three pages for I/O, forming a contiguous 768-byte hole in the MOS ROM: $FCxx (FRED), $FDxx (JIM), and $FExx (SHEILA). All of the internal devices, including the optional ones and the Tube, are mapped into SHEILA; FRED and JIM are mapped to the 1MHz Expansion Bus port, which provides 8 address lines and two select lines.

Acorn's Master has a couple of interesting memory mapping tricks.

For one, there's some code in ROM under the I/O pages, which is used only for machine initialisation after reset. When the ACCCON TST bit is set, reads go to ROM and writes go to I/O - which allows for the bit to be cleared again.

For another, there's a mode where the screen memory is mapped in only for code running in a certain address range: by using SYNC, the vdu drivers get to see the screen, but all other code sees normal memory.

Conversely, there's some RAM which can be mapped in over the vdu drivers, allowing for various non-application code to store data without encroaching on the application's allocation.

You can always put write only latches in the permanent ROM space. This way you could devise a register for banking I/O, RAM and other areas of ROM in and out and it would always be available.

_________________
Bill

That was how Commodore did it in the C-128. The MMU configuration register, as well as the four pre-set registers, is always mapped in at $FF00, regardless of the chosen configuration.

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

Genius! So the ROM address space is really two spaces, one read-only (the ROM) and one write-only. The address decoder could select ROM when RWB is logic high or an 8-bit output port when RWB is low. I like it!

I know this is a 6502 forum, but I do wish to point out that the Z80 always drives all sixteen address lines, and all of the I/O instructions do output a sixteen bit address. However as some of the instructions use the contents of the A register for address bits A8 to A15, some are not very practical. Sinclair and Amstrad however both used sixteen bit I/O addressing for some I/O. The best I/O instructions for this are those using the C register to point to the wanted I/O address, as then the B register supplies A7 to A15

Back to the 6502 (and other systems that use memory mapped I/O), I agree that putting write only registers (such as used for configuration or bank memory) ‘under’ a ROM area is a wise thing to do. Just make sure that there are no unintended writes to this area.

In terms of systems that change their memory map, systems do exist that start-up with a ROM in the memory map (read only) and RAM underneath (write only). Then after copying the ROM to RAM, a special access flips a bit in a hardware register and the ROM is unmapped and at the same time all memory reads will now come from RAM.

Using this could allow far more RAM area, thus freeing up space for normal memory mapped I/O.

But as hinted at earlier, the more complex a system is, the greater the number of other problems that will show themselves. More complex circuitry (if built using individual off the shelf logic) will have longer propagation times, and a more complex system massively increases headaches if it fails to work for any reason.

Mark

It's tempting to seek perfection, but engineering is all about making compromises. Losing a few percent of performance, a few percent of RAM or ROM, and gaining a simpler system that's easier to debug and quicker to get working, can often be the right tradeoff.

That said, of course writing RAM under ROM or under I/O can be a good trick if it leads to a cleaner architecture, making the software side of the project simpler.