Am 21.02.2011 21:47, schrieb Petri Pellinen:
On Mon, Feb 21, 2011 at 9:05 PM, Daniele Terdina
<[email protected]> wrote:
Didn't Sinclair ROMs have a bug preventing usage of all expansion slots except
for the first one?
Being a re-newbie I also have (I hope!) a few related questions : This
might be a FAQ so apologies in advance if this subject has been beaten
to a painful death many times before....
Is the section "Peripheral ROM problem" in chapter 9 of "The Sinclair
QDOS Companion" still relevant? Andrew Pennell outlines a procedure to
work around the early QDOS bug where only the first peripheral routine
is discovered. Should this workaround still be applied to make sure
all peripheral drivers get initialized properly? Does the workaround
actually *break* things with newer QDOS versions and more recent
peripherals?
Quite an interesting question, just a wild guess on it:
Well, I don't have the Pennel book, so don't know his recipe - But would
expect he recommends scanning the potential expansion port ROM start
candidates for a valid ROM header and mimicking the correct
initialisation sequence (i.e calling initialisation routine at x+6 and
linking in Basic procedures at x+4.
So what could go wrong: Waste of memory - All drivers need to allocate
at least a 40+ bytes driver linkage block plus any additional scratchpad
memory they need. So if you initialize a driver twice, memory of the
first is potentially lost. (The driver as such won't be called twice,
because drivers may very well "shadow" each other, only the first one
that tells the system it has recognized its device name will actualy be
called (This is one of the mechanisms used by the PE to 'hide' the
original con_ driver)
Waste of CPU: Drivers linking in a polling or scheduler loop might very
well do that twice, same for an external interrupt routine.
Polling or scheduler loops just waste CPU. External interrupt routines
hooked in twice shouldn't hurt (but probably wasting CPU as well), as an
interrupt routine should really clear the interrupt source befor it
returns. BTW all of the link traps have no failure exit - they will just
link in whatever routine they're asked for.
Same goes with SuperBASIC extensions - just a waste of memory - the last
one hides the others.
This would be one typical usage of a thing: When a driver is
initialized, it could check for existance of its correspondent thing and
gracefully exits without further initialisation if it's already there.
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
