Page 1 of 2

Drivers and linking...

Posted: Thu Jan 18, 2018 11:30 am
by Pr0f
It's my understanding that any drivers that are loaded by ROM code are linked in ahead of the internal ones, allowing these to be replaced.

In the event that driver replacement code exists in more than one ROM, which has the priority - the one found first in the ROM scanning, or the last one scanned ?

Re: Drivers and linking...

Posted: Thu Jan 18, 2018 11:31 am
by Pr0f
I should probably reword that to any add on ROM's - as the 'internal' definitions are also in a ROM :-)

Re: Drivers and linking...

Posted: Thu Jan 18, 2018 2:27 pm
by tofro
That is, unfortunately true only for the last QL ROMs (JS, MGx, and Minerva, to my knowledge) and SMSQ/E.

There were a number of bugs in the earlier ROMs that lead to the fact that some (OS) ROMs could not simply overwrite existing drivers, some (OS) ROM versions also wouldn't find an initialize more than one add-on ROM.

Some devices/software worked around that and repaired that to the intended behavior, some didn't.

If ROM scan works properly in your OS version, the rule is, to my knowledge, that "last found is the one that is it", with "last" meaning from lower to upper addresses.

Once you start to look into what Miracle Trump Cards did, you probably will be confused. Their full memory expansion expects that there is a continuously un-populated address range above the internal RAM to be able to page in its full 768k expansion.

And once you look into Gold and SuperGold cards: They did, to my knowledge, not scan the full expansion address range for expansion ROMs, only some well-known places.

Tobias

Re: Drivers and linking...

Posted: Thu Jan 18, 2018 2:50 pm
by Pr0f
Yes - I came across some code that you can include in the ROM init code to make the ROM scanning work again for those ROM versions where it didn't.

So from what you say, if I have a replacement driver, and another vendor has a replacement driver, I would want mine to be in the last scanned ROM to be sure of becoming the 'go to' driver.

So what about drivers loaded from a storage device (HD or floppy or SD card) into RAM - are these linked in after the ROM scanned drivers ?

Re: Drivers and linking...

Posted: Thu Jan 18, 2018 3:21 pm
by tofro
Pr0f wrote: So from what you say, if I have a replacement driver, and another vendor has a replacement driver, I would want mine to be in the last scanned ROM to be sure of becoming the 'go to' driver.
Well, depends. If you supply a "win" driver and your code detects there already is one for another device, you'd probably want to re-name yours to "hdd", ideally (although I don't know of any driver that does that. Normally, drivers register with the OS under a unique name and give the user the option to change that to "win" using a BASIC command xxx_USE)

If you supply an extended "con" driver (like, for example, the PTR envirionment does), you definitely want to replace the existing one.
Pr0f wrote: So what about drivers loaded from a storage device (HD or floppy or SD card) into RAM - are these linked in after the ROM scanned drivers ?
Drivers loaded into RAM are initialized once their initialization code is run (That is, when you type "LRESPR driverBinary"). And they should go in front of the device driver linked lists, thus replacing existing drivers. That's at least the case for JS and newer. I've never checked for older ROMs, I have dumped everything older than JS already 20 years ago...

The above assumes you're talking about directory device drivers that simply register a name with the system. Serial device drivers are a bit different, here the driver can decide at run-time whether it wants to "understand" the decoded device name specified or not (i.e. you could build a driver that recognizes and handles "ser1_vhs" (for "very high speed"), and let the original driver handle everything else).

Tobias

Re: Drivers and linking...

Posted: Thu Jan 18, 2018 8:41 pm
by Pr0f
Hi Tobias,

Yes - it was SER I was thinking about - specifically replacing the existing driver with a new driver and new hardware...

That would include replacing the BAUD command too, although more by way of expanding it, so it could still be used in it's original form to set a default baud rate perhaps.

I quite like the syntax of TF services SER device, allowing a lot of the parameters including baud rate to be set when opening the device channel.

Thanks for the info so far, it's given me a few ideas to play with... :-)

Re: Drivers and linking...

Posted: Thu Jan 18, 2018 11:39 pm
by janbredenbeek
tofro wrote:That is, unfortunately true only for the last QL ROMs (JS, MGx, and Minerva, to my knowledge) and SMSQ/E.

There were a number of bugs in the earlier ROMs that lead to the fact that some (OS) ROMs could not simply overwrite existing drivers, some (OS) ROM versions also wouldn't find an initialize more than one add-on ROM.
Pre-JS versions only checked for ROMS at $C000 and $C0000. JS and later also $C4000, $C8000, etc. up to $FC000.
Once you start to look into what Miracle Trump Cards did, you probably will be confused. Their full memory expansion expects that there is a continuously un-populated address range above the internal RAM to be able to page in its full 768k expansion.

And once you look into Gold and SuperGold cards: They did, to my knowledge, not scan the full expansion address range for expansion ROMs, only some well-known places.
Well the original Sinclair concept was to use the 256K from $C0000 onwards for expansion hardware, but most users only needed a disk interface and RAM expansion. Since a disk interface only needs 16K at most, this would waste 240K of precious address space. Miracle neatly filled in this gap with extra RAM and moved their firmware to more obscure locations ($10000-$17FFF, (S)GC also uses $1C000-$1FFFF).

Jan.

Re: Drivers and linking...

Posted: Fri Jan 19, 2018 7:43 am
by tofro
janbredenbeek wrote:
tofro wrote:That is, unfortunately true only for the last QL ROMs (JS, MGx, and Minerva, to my knowledge) and SMSQ/E.

There were a number of bugs in the earlier ROMs that lead to the fact that some (OS) ROMs could not simply overwrite existing drivers, some (OS) ROM versions also wouldn't find an initialize more than one add-on ROM.
Pre-JS versions only checked for ROMS at $C000 and $C0000. JS and later also $C4000, $C8000, etc. up to $FC000.
Once you start to look into what Miracle Trump Cards did, you probably will be confused. Their full memory expansion expects that there is a continuously un-populated address range above the internal RAM to be able to page in its full 768k expansion.

And once you look into Gold and SuperGold cards: They did, to my knowledge, not scan the full expansion address range for expansion ROMs, only some well-known places.
Well the original Sinclair concept was to use the 256K from $C0000 onwards for expansion hardware, but most users only needed a disk interface and RAM expansion. Since a disk interface only needs 16K at most, this would waste 240K of precious address space. Miracle neatly filled in this gap with extra RAM and moved their firmware to more obscure locations ($10000-$17FFF, (S)GC also uses $1C000-$1FFFF).

Jan.
Well, to be even more precise, the Trump Card ROM actually lives in more than one place during the boot process. Initially, it lives at $C0000 (otherwise the ROM wouldn't be recognized by any Sinclair ROM), and once it's initialization code is running, relocates itself to the "internal I/O" area like you say. Once up and running, $C0000+ is RAM again.

Re: Drivers and linking...

Posted: Fri Jan 19, 2018 12:54 pm
by janbredenbeek
tofro wrote:
Well, to be even more precise, the Trump Card ROM actually lives in more than one place during the boot process. Initially, it lives at $C0000 (otherwise the ROM wouldn't be recognized by any Sinclair ROM), and once it's initialization code is running, relocates itself to the "internal I/O" area like you say. Once up and running, $C0000+ is RAM again.
Which somewhat confused me, as this would limit the amount of RAM that the QL ROM detects to 640K. My guess is that on power-up or reset there is all RAM from $40000-$FFFFF, then when the QL ROM scans for extension ROMs the Miracle ROM gets paged in at $C0000 so the initialisation code gets called which pages it out again (by reading a byte from I/O location $1C000).
(There is only one boot sequence with TC unlike the (S)GC).

Jan.

Re: Drivers and linking...

Posted: Fri Jan 19, 2018 2:01 pm
by tofro
janbredenbeek wrote:
tofro wrote:
Well, to be even more precise, the Trump Card ROM actually lives in more than one place during the boot process. Initially, it lives at $C0000 (otherwise the ROM wouldn't be recognized by any Sinclair ROM), and once it's initialization code is running, relocates itself to the "internal I/O" area like you say. Once up and running, $C0000+ is RAM again.
Which somewhat confused me, as this would limit the amount of RAM that the QL ROM detects to 640K. My guess is that on power-up or reset there is all RAM from $40000-$FFFFF, then when the QL ROM scans for extension ROMs the Miracle ROM gets paged in at $C0000 so the initialisation code gets called which pages it out again (by reading a byte from I/O location $1C000).
(There is only one boot sequence with TC unlike the (S)GC).

Jan.
It's even a bit more complicated:

"Very" initially, the ROM can be seen at $10000+ only (But wouldn't be found by anyone).

During memory test, the TC fills all expansion space with RAM, no ROM above $40000. The memory test will detect all 768k the TC has.

Then the TC detects the first read access to $C000 (the ROM slot). It doesn' page anything in there, only does that to see if the memory test is done. This is only done to detect the initialisation phase you call "when the ROM scans for expansion ROMs" )

This triggers page-in of the TC ROM at both $10000 and $C0000 (a shadow copy).

During he search for expansion card ROMs, the copy at $C0000 is found and called by QDOS. The first thing that does, is jumping to the copy at $10000 and paging out the ROM at $C0000 - All device driver absolute addresses now can refer to the area at $10000+ and we're done.

Tobias