Hi Tobias, thanks for your thoughts on this. And your guess on Pennell's solution is correct :) Very interesting piece of information about driver shadowing. Obvious, once you think about it.... but I hadn't thought about it :)
Cheers, Petri On Mon, Feb 21, 2011 at 11:20 PM, Tobias Fröschle <[email protected]> wrote: > 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 > _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
