I didn't know whether to put this in Hardware or Software as it's Firmware, but I chose here because it's a hardware issue.
I've been told that vanilla QDOS/Minerva doesn't run happily on 68EC020 due to CPU differences. The GC/SGC copies and patches the OS to work with the EC020 CPU.
My questions are: what are the differences? How does the GC/SGC boot the OS to copy the OS to boot the patched version?
I tried reading out and comparing the SGC patched version, but I don't have the knowledge to read what is an 020 change and what is a change for moved locations of resources.
I would like to prepare a version of Minerva 1.97/1.98 to run specifically with the 68EC020 system I'm building, and it could solve a lot of other problems in the future for me.
OS/CPU differences...
Re: OS/CPU differences...
From my limited experience, the GC/SGC (GC) boots first from it's EPROM (usually marked (S)GC 2.**).
Then, GC copies the Sinclair ROM into the GC RAM.
From there, the GC then modifies the Sinclair ROM to put jumps to GC EPROM addresses??
(Note: Prob. GC switches the address bits for the EPROM and RAM, around after the Sinclair ROM has been stored in RAM and modified - prob. in Altera EPLD.)
Then GC boots up with modified SInclair ROM.
So, best bet is disassemble the (S)GC EPROM.
Other way would be interrogate a former Miracle guy?
Tim
Then, GC copies the Sinclair ROM into the GC RAM.
From there, the GC then modifies the Sinclair ROM to put jumps to GC EPROM addresses??
(Note: Prob. GC switches the address bits for the EPROM and RAM, around after the Sinclair ROM has been stored in RAM and modified - prob. in Altera EPLD.)
Then GC boots up with modified SInclair ROM.
So, best bet is disassemble the (S)GC EPROM.
Other way would be interrogate a former Miracle guy?
Tim
Re: OS/CPU differences...
Reading the contents of address 0000h to BFFFh (first 48k of the address map) on a GC/SGC will actually get you a patched versiobn of whatever ROM is in use. For the 68EC020 you need a SGC to get the patched code for use with a 68020 CPU. If you use it as a ROM image, it should run normally on a 68(EC)020 from reset.
A few notes to this - the SGC ROM actually detects what ROM version is installed and applies patches appropriate to the ROM version.
Both GC and SGC initially start up from their on-board ROM. Some 'magic' is used with decoding what is where so that both the on-board ROM, the QL ROM and the RAM which will sit at the okd QL ROM addresses are mapped into the CPU's address map and accessible.
The code in the on-board ROM then checks the RAM which will be used as ROM emulation, copies the QL ROM there (in fact it also copies part of the on-board EPROM too, have a look at addresses 10000h..17FFFFh), finds out which ROM it is, applies appropriate patches, and then write protects that part of RAM so it really behaves as ROM (so that the data cannot be corrupted by misbehaving code). All of this is done by the address decoder in the PLD which takes account not only of the address lines, but also of read-write line and a 'boot status bit' which is generated by a latch in the PLD. The latch is initially reset at power on, and set by any access to some 'magic address' - it tells the decoder what to decode where immediately after reset (so the on-board ROM appears at the start of the address space where the CPU looks for the reset and SSP vectors), the QL ROM is available on an alternate address and ROM which will later emulate the QL rom is available at still another address and writeable), and then when the copy and patch process is finished, the CPU puts the 'normal' mapping in place by setting the latch via magic address. At this point, on the GC the actual ROMs are not even available any more, just their write protected copies. On the SGC, the QL and SGC ROM is available to be read IIRC at F00000h..F1FFFFh. In fact I think writing to these addresses may also be supported, i.e. will generate appropriate bus cycles on the 8-bit bus (but is obviously not implemented by the decoding hardware).
Finally, now the address map holds something similar to the old Ql just with extended RAM and some extra code to support addred peripherals, and it can run like an ordinary machine would, from COU reset, which is indeed what happens then (but the external hardware and thus the PLD decoder is not reset, only the CPU) and the OS runs as usual starting from memory test (the well known pattern on the screen).
A few notes to this - the SGC ROM actually detects what ROM version is installed and applies patches appropriate to the ROM version.
Both GC and SGC initially start up from their on-board ROM. Some 'magic' is used with decoding what is where so that both the on-board ROM, the QL ROM and the RAM which will sit at the okd QL ROM addresses are mapped into the CPU's address map and accessible.
The code in the on-board ROM then checks the RAM which will be used as ROM emulation, copies the QL ROM there (in fact it also copies part of the on-board EPROM too, have a look at addresses 10000h..17FFFFh), finds out which ROM it is, applies appropriate patches, and then write protects that part of RAM so it really behaves as ROM (so that the data cannot be corrupted by misbehaving code). All of this is done by the address decoder in the PLD which takes account not only of the address lines, but also of read-write line and a 'boot status bit' which is generated by a latch in the PLD. The latch is initially reset at power on, and set by any access to some 'magic address' - it tells the decoder what to decode where immediately after reset (so the on-board ROM appears at the start of the address space where the CPU looks for the reset and SSP vectors), the QL ROM is available on an alternate address and ROM which will later emulate the QL rom is available at still another address and writeable), and then when the copy and patch process is finished, the CPU puts the 'normal' mapping in place by setting the latch via magic address. At this point, on the GC the actual ROMs are not even available any more, just their write protected copies. On the SGC, the QL and SGC ROM is available to be read IIRC at F00000h..F1FFFFh. In fact I think writing to these addresses may also be supported, i.e. will generate appropriate bus cycles on the 8-bit bus (but is obviously not implemented by the decoding hardware).
Finally, now the address map holds something similar to the old Ql just with extended RAM and some extra code to support addred peripherals, and it can run like an ordinary machine would, from COU reset, which is indeed what happens then (but the external hardware and thus the PLD decoder is not reset, only the CPU) and the OS runs as usual starting from memory test (the well known pattern on the screen).
Last edited by Nasta on Mon Mar 25, 2013 3:26 pm, edited 1 time in total.
Re: OS/CPU differences...
SOme other notes:
The memory map as seen by the CPU remains more-or less unchanged in all of it's important aspects between all QL native hardware versions and expansions. The locations of various Io resources actually don't change, instead other resources are added (such as the floppy I/F, RTC, parallel port), and existing ones are extended (such as RAM).
It should be noted that AFAIK all versions of the OS I know of will attempt to test for RAM from 20000h onwards, in theory up to the full 4 gig of address space available to fully 32-bit versions of the 68k. Ditto for add add-on ROMs, where they check for 4AFB0001h at the first long word of the ROM slot at C000h and then every 16k boundary from C0000h onwards (IIRC Minerva also checks at 10000h and 14000h). However, there are bugs in some versions of the OS which will prevent more than about 2M of RAM being used, one I remeber is building of the slave block table which has a size proportional to the amount or RAM found, where a 16-bit index has been used to create the table so having sufficient RAm to make the table larger than 32 or 64k results in the table 'wrapping around' and corrupting either the system variables or itself. In other words (bar bugs) the OS was designed from the start to have expandable resources where expansion was most expected to happen.
Additional hardware and peripherals are not detected as such because they all behave on a case-by-case basis - instead add-on ROMs are detected, and if these happen to come as a part of a peripheral, it's the responsibility of the code in the ROMs to know how to check for added hardware, and of course, support it's functions. The GC/SGC ROM is an exception to his because code in it is run before the actual OS so 'it takes care of itself' by patching the ROM image of the OS code created in RAM to additionally run it's initialisation code from a copy of itself it created in RAM beforehand - hence the GC/SGC copyright message at the start. Internally, that part of the GC/SGC ROM behaves just like any other extension ROM except it does not rely on the usual OS mechanism to detect and start it. In principle it could have been mapped to somewhere the OS would detect it and run as an add-on ROM, but historically this was avoided to make GC hardware simpler and not take up parts of the address map which could in the future be used otherwise - so instead it is hidden in addresses which were normally not used on the original QL hardware.
AFAIK the added IO implemented on the GC and SGC also sits in a previously unused area of the address map somewhere between 1C000h and 1FFFFh.
In principle the OS could be made to check for a ROM image at any 16k boundary but because in some cases aliasing can happen, this needs to be used with caution.
One other issue that may happen on systems where the CPU has the full complement of 32 address lines, is Qliberator compatibility. QLIB uses the top 3 bits of 32-bit addresses in the code it generates to store it's internal data, so it relies on these 3 bits being unused by any system to decode parts of the address space. Instead, only A0 to A28 should be used, limiting the total size of the address space useble by a QL OS to 512M. By leaving these lines unused, this 512M address map repeats 8 times in the maximum available 4G of address space (i.e. it has 8 aliases), and QLIB depends on any offset within any of these 8 copies of the address space to map to the same physical memory, for correct operation. It should be noted that even though the available memory for a QL OS is thus reduced by a factor of 8 compared to the theoretical limit, it is still possible to use this aliasing to implement various tricks such as shadowing or cache control, by insuring that all 8 aliasas indeed have the same data but that accesses have special properties depending on which actual alias is used.
The memory map as seen by the CPU remains more-or less unchanged in all of it's important aspects between all QL native hardware versions and expansions. The locations of various Io resources actually don't change, instead other resources are added (such as the floppy I/F, RTC, parallel port), and existing ones are extended (such as RAM).
It should be noted that AFAIK all versions of the OS I know of will attempt to test for RAM from 20000h onwards, in theory up to the full 4 gig of address space available to fully 32-bit versions of the 68k. Ditto for add add-on ROMs, where they check for 4AFB0001h at the first long word of the ROM slot at C000h and then every 16k boundary from C0000h onwards (IIRC Minerva also checks at 10000h and 14000h). However, there are bugs in some versions of the OS which will prevent more than about 2M of RAM being used, one I remeber is building of the slave block table which has a size proportional to the amount or RAM found, where a 16-bit index has been used to create the table so having sufficient RAm to make the table larger than 32 or 64k results in the table 'wrapping around' and corrupting either the system variables or itself. In other words (bar bugs) the OS was designed from the start to have expandable resources where expansion was most expected to happen.
Additional hardware and peripherals are not detected as such because they all behave on a case-by-case basis - instead add-on ROMs are detected, and if these happen to come as a part of a peripheral, it's the responsibility of the code in the ROMs to know how to check for added hardware, and of course, support it's functions. The GC/SGC ROM is an exception to his because code in it is run before the actual OS so 'it takes care of itself' by patching the ROM image of the OS code created in RAM to additionally run it's initialisation code from a copy of itself it created in RAM beforehand - hence the GC/SGC copyright message at the start. Internally, that part of the GC/SGC ROM behaves just like any other extension ROM except it does not rely on the usual OS mechanism to detect and start it. In principle it could have been mapped to somewhere the OS would detect it and run as an add-on ROM, but historically this was avoided to make GC hardware simpler and not take up parts of the address map which could in the future be used otherwise - so instead it is hidden in addresses which were normally not used on the original QL hardware.
AFAIK the added IO implemented on the GC and SGC also sits in a previously unused area of the address map somewhere between 1C000h and 1FFFFh.
In principle the OS could be made to check for a ROM image at any 16k boundary but because in some cases aliasing can happen, this needs to be used with caution.
One other issue that may happen on systems where the CPU has the full complement of 32 address lines, is Qliberator compatibility. QLIB uses the top 3 bits of 32-bit addresses in the code it generates to store it's internal data, so it relies on these 3 bits being unused by any system to decode parts of the address space. Instead, only A0 to A28 should be used, limiting the total size of the address space useble by a QL OS to 512M. By leaving these lines unused, this 512M address map repeats 8 times in the maximum available 4G of address space (i.e. it has 8 aliases), and QLIB depends on any offset within any of these 8 copies of the address space to map to the same physical memory, for correct operation. It should be noted that even though the available memory for a QL OS is thus reduced by a factor of 8 compared to the theoretical limit, it is still possible to use this aliasing to implement various tricks such as shadowing or cache control, by insuring that all 8 aliasas indeed have the same data but that accesses have special properties depending on which actual alias is used.