Date   : Sun, 22 Sep 2002 18:41:14 +0200
From   : John Kortink <kortink@...>
Subject: Re: BBC B with edge-connectors instead of IDC connectors?

On Sun, 22 Sep 2002 16:29:35 +0100, Sprow wrote:

>In article <KNEEJIOPPHNNBHBMMGACGEDJCDAA.r.gellman@...>,
>   Richard Gellman <r.gellman@...> wrote:
>> [unimportant info deleted]
>
>> >>As FE30 is readonly,any interrupt routine which feels it necessary to
>> jiggle
>> >>the ROMs around reads and stacks F4.On exit from the interrupt handler it
>> >>pulls and writes to *both* F4 and FE30,hence my comment about writing to
>> F4
>> >>*first* and not bothering to disable IRQs,
>> >
>> >Yes, but oftentimes it's 'not bothering' that causes the most
>> >obscure of crashes. ?&F4 is simply meant to reflect the contents
>> >of ROMSEL *at all times*, even during interrupts. You simply do
>> >not, and should not, know what is being done in any interrupt
>> >routines that happen to run while you're switching ROMs.
>
>[paste in JK's answer]
>
>> Depends. One possible scenario is that the interrupt handler
>> needs to access the ROM that was selected when the interrupt
>> occurred and needs to do so by explicitly switching to it at
>> some point (which may be, e.g., if executes partially in a
>> sideways ROM itself, or if it needs to access other ROMs).
>> It will access the wrong ROM since ?&F4 has already been
>> updated and no longer corresponds to the actual ROMSEL.
>
>In this situation it knows which ROM was paged in when the interrupt went
>off since it's still selected by virtue of the foreground task not yet
>poking FE30.

No it doesn't. It doesn't know its number without reading ?&F4.
Which contains the wrong value. E.g. ROM X is selected, code
writes ?&F4 = Y, before changing ROMSEL an interrupt occurs,
the interrupt routine saves ?&F4, switches to ROM Z, performs
an unrelated task, switches to ROM Y (which it thinks was
current when it was called while ROM X actually is), reads
the wrong data.

>[...]


John Kortink