glitch
Veteran Member
I'm looking for some input on the design of the bus-oriented generic 8-bit system I've been working on. My experience with 8-bit processors has been limited to processors with I/O space support (8085, Z80)...as such, I've gotten used to using IN and OUT and having a 256 byte I/O space. It's easy to decode, the instructions are handy (unless you're doing something sequential like a character display), and 256 8-bit I/O devices seems like plenty.
The problem with that is the primary goal of the bus machine is to be processor-inspecific. There will be at least an 8085 and a 6502 CPU board design, and of course the 6502 has no I/O space. It would be easy to produce two sets of option boards (one memory mapped and one using I/O space), but part of the project goal is universal option boards. OSI and Apple accomplished this by using all memory-mapped devices.
The other option, and my original thought on the matter, was to create a board to map I/O space into a 256-byte block of memory, probably using a faster PIC microcontroller to interpret memory reads/writes and pull them from the I/O space. This is obviously more complicated, but preserves I/O space. It seemed like a pretty decent idea, and shouldn't be super-hard to implement.
But in the end, with memory-mapped processors you're going to end up using 256 bytes of memory address space for I/O anyway. Is it worth having the extra 256 bytes for processors that support I/O space? Will it make a worthwhile difference in, say CP/M, to be worth the trouble? Do people who have coded for both memory-only and I/O space devices really care either way?
The problem with that is the primary goal of the bus machine is to be processor-inspecific. There will be at least an 8085 and a 6502 CPU board design, and of course the 6502 has no I/O space. It would be easy to produce two sets of option boards (one memory mapped and one using I/O space), but part of the project goal is universal option boards. OSI and Apple accomplished this by using all memory-mapped devices.
The other option, and my original thought on the matter, was to create a board to map I/O space into a 256-byte block of memory, probably using a faster PIC microcontroller to interpret memory reads/writes and pull them from the I/O space. This is obviously more complicated, but preserves I/O space. It seemed like a pretty decent idea, and shouldn't be super-hard to implement.
But in the end, with memory-mapped processors you're going to end up using 256 bytes of memory address space for I/O anyway. Is it worth having the extra 256 bytes for processors that support I/O space? Will it make a worthwhile difference in, say CP/M, to be worth the trouble? Do people who have coded for both memory-only and I/O space devices really care either way?