Dave wrote:
In that 32K block, only 9 bytes seem to be actually used by memory mapped IO. A couple of mouse systems use three or four bytes near the top of that 32K. Part of the problem is that the area is only partially decoded so it contains aliases of those IO registers with the frequency dependent on whether it's an Issue 5, or Issue 6/7 board.
Correction - it's a 16k area between $18000 and $1BFFF. Depending what manual is consulted, in some of them it's a 32k block extending to $1FFFF, however, the actual mapping has been established by precedent - when a common denominator is taken from all motherboard and 8301 ULA versions, you end up with the already mentioned 16k.
In any case, it is explicitly stated in the Technical manual (that does have some holes in the descriptions...) that if things alias to multiple addresses, software should ALWAYS use the LOWEST address ONLY, for future compatibility. This of course does not include hardware that needs to use aliases for it's own purposes but then it has to cater for this with appropriate drivers and documentation.
Regarding the mothrboard IO, it is decoded within the 16k area mentioned above, using only 4 address lines, of which A6 is the highest. This means there are 128 aliases of that 128 byte area within the 16k and indeed, extra aliases of addresses withing the 128 bytes. However, using the 'lowest alias' rule, everything on the motherboard is addressed in the lowest 128 bytes, so that's $18000..$1807F.
ASIDE: It is quite possible that there have been errors made in the 8301 ULA and initial board routing because it seems the original intention (and I have already contended both ULAs have started life as a single design) was to have all the IO in the first 8 bytes. The way the actual registers are decoded strongly suggest this.
The one seminal piece of hardware that first used this area for it's own purposes, and with a good deal of conceptual backing, since it was in fact expanding the capability of the motherboard itself, was QIMI. It actually reduces the on-board IO to only those aliases that have A10=0. When A10=1, it maps in it's own circuits. However, it also breaks the 'lowest address rule' by using the highest alias, which I suppose was used because Qjump did not want to bother with badly behaved software so they chose the least likely alais to cause trouble. QIMI is mapped into the top 256 bytes of the on-board IO area.
As far as I know (and indirectly everyone that ever used an Aurora), the part between the lowest and highest 256 bytes was never used by anything - or it would not have worked on Aurora. It actually decodes the addresses in this area and presents a chip select pin on the extended ROM slot that is active for any address between $18100 and $1BEFF. The extended ROM slot also has a R/W pin and a /RESET pin, and an /EXTINT pin. You know, stuff that should have been there from the beginning
do some clever simple peripherals could be made to work in the ROM slot.
My intent is to place the interface ROM and IO in the regular place on machines shipped to the general public, with the address decoded by a GAL. However, I'd like to map just the IO into the Internal IO area on
*my* machine for testing a particular address decoding arrangement.
There are some advantages to putting the IO address in that IO window: no need to have a see-through port in your ROM image for IO to operate through - even if it's just a few bytes, much simpler and more consistent address decoding if you know where the IO is going to happen, regardless of the location of the card in memory. It seems there would be advantages to having that portal in the bottom 256K of the address map. A stepping through the IO area would be added into the address from A14-17, so cards would not conflict with each other. This would later allow the expansion cards themselves to be remapped anywhere in the memory map.
That was my initial idea - but QIMI breaks this. Unfortunately it's of no consequence as automatic addressing was broken long ago, more on that later.
The idea was to provide 16x 512 bytes (=4k) of IO space from $19000..$19FFF that would track the 16k block selected by the required setting of A19..A16 that maps the expansion card into the expansion IO area at $C0000.
There are problems with this:
There are several cards that required two or in fact ALL of the expansion IO area for their own use. The best known are the SuperQboard and Trump Card (Not THAT Trump!). Once they were introduced, the use of the SP lines to select a peripheral was completely deprecated, and to a large extent so was the use of the expansion IO area - with a TC that became RAM (and it was very welcome, given how many were sold).
It should be noted that the SP0..3 system was not intended for backplanes unless the card address was set by switches or spread out to the number of backplane slots available. It's intention was for through-ported cards. Each would add one to the SP state to move the next card's address one 16k slot up. THe odd thing is, why it dod not start at the top slot and move down, that would have been more logical because RAM was permitted to grow upwards into the expansion IO area from the very beginning - this is how the OS works (and there are other tricks it does but that's another story). Cards that were intended to use up the whole space, like TC, GC and SGC actually used the fact the SP lines were tied to ground on the motherboard, to establish a better ground connection.
The TC also pioneered the use of $10000..$17FFF for ROM.
When Qubide came along, it simply had to have a jumper selectable address or it would not fit a lot of systems which would indeed be the best candidates for having a Qubide in the first place.
And once you had a Qubide in there, thre was literally no-where to go. Minerva did try to make things somewhat better but alas missed one thing, and that is using the addresses just above the 16k IO block, at $1C000..$1FFFF as a candidate for a ROM or expansion card - it did, however, add $10000 and $14000 as possible candidates. If that were added, Qubide would have worked in there (and it IS actually possible to map it there, and patch the LRESPR version of the driver to use it).
After that (S)GC came and we were back to the ROM slot as far as expansions go.
As Dave pointed out, 'real' expansions intended to work together with other ones, had to put their private IO stuff somewhere.
It should be known that 'expansion IO' actually means 'extension ROM'. Since there was no specification as to where various IO addresses should go for add-on stuff, the idea was for the ROM that drives the said IO to contain code that knows where to look for it's relevant hardware, and the typical way of doing that (in order to not have to figure out any possible conflicts) was to reserve a bit of space, usually 2^N bytes, N being a small number, subject to required IO space and decoding resources, at the very end of the 16k space allocated to the ROM. Of course, that also 'shortened' the available space for code in the ROM by that 2^N amount. 256 was the most common - and to give you an idea how few bytes are typically needed to map an IO device, Qubide uses 256 bytes at the end and maps no less than 16 IDE channels in there, given external decode. And, not only that, it maps the single data port into 8 consecutive bytes so that successive data accesses can capitalize on the 68008 being able to do 4 or more byte accesses back to back by accessing the data as long words.
It is now a moot point if decoding IO inside the on-board Io area or inside the 16k space for the ROM on an expansion card needs more or less hardware, the point is, some expansions have become ubiquitous and almost a standard, so they could well be mapped to fixed addresses.
So far we can assume the old ULAs at $18000..$180FF and Qimi (original, not the one on the SQB) at $1BF00..$1BFFF. The rest is more or less up for grabs.
One entry which I would add to this, is the entire first 4k of that area. There is a hidden agenda behind that one