On 8/8/2003 at 4:00 AM Thierry Godefroy wrote: >I conclude from the above that it must be a problem in the >initialization code of SMSQ/E v2.98+ as everything works just >fine with v2.91. I had a quick look to the sources, and if looks >like SMSQ/E v3.01 checks for ROMs at addresses $C000 (ROM slot) >and $4C0000 (inclusive) to $500000 (exclusive) with $4000 bytes >(16Kb) increments. > >Following the instructions in the Aurora manual, my Qubide is >configured to show its ROM from the base address of $4FC000, so >it -should- be detected, like should be the ROMdisq (address >$C000). > >BUT: I seem to remember that SGC and Aurora are using shadowing >mechanisms, so my question is: are those addresses valid at boot >time ? (Nasta, are you with us ? Three knocks for 'yes', two >for 'no', please ! ;-)
OK, first the 3 knocks requested: knock, knock, knock! SGC uses shadowing only in the screen areas, so that would be $20000 to $2FFFF, or $27FFF if screen 2 is disabled. Aurora basically follows what the SGC does, but the old screen areas also appear in the new screen area, that would be at $4C0000. It is worth noting that the Aurora actually has 256k of screen RAM, but normally only 240k is used - i.e. the block at $4FC000 to $4FFFFF is not used to display an image, but is there and acts as RAM, as long as nothing else is using those addresses. Normally, those addresses would be used by a Qubide set to $FC000. Without a Qubide there, one could actually load a 16k image of an EPROM and it should get recognised as an EPROM when the OS is restarted (or an OS is subsequently loaded and started as in the case of SMSQ/E). This is the only hardware mechnism that I can think of that could prove to be problematic, but I think it is highly unlikely. If a Qubide is connected, it would be there from the start and should get recognised and initialised. That being said, the Qubide code first copies itself into RAM then continues execution. This could potentially be a problem if the cache settings are incorrect. >Well, that's all for now... I was about to fiddle with the >hard disk driver of SMSQ/E so to allow non-blocking ATAPI >commands on my CD-ROM driver (there's a bug in SMSQ/E >preventing to delay the ATAPI queue execution, for example >when the CD-ROM spins up), but I'll wait until I find a way >to have an homogoneous setting on at least both the Q60 and >the SGC. Thierry, I have a question - would it be possible to adapt the SMSQ/E hard disk driver to the Qubide? This way there could be a standard of sorts, especially since the Qubide driver is no longer maintained, and sources are not available... The reason you are getting asked is of course being famous for writing the CD ROM driver ;-) N.
