<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Tue, 17 Apr 2007 20:49:59 +0100
From   : jgh@... (Jonathan Graham Harston)
Subject: BBC B progs on a B+128k - any known problems?

>Message-ID: <4ed3cf133finfo@...>
 
Sprow <info@...> wrote:
> The differing 'emulation' is to stash the locations &D60-D93, read sectors
> using the read track command instead, then restore &D60-D93. It looks like
 
Ah yes. I'd commented that in the disassembly as happening all the
time, not dependant on the Z-Break state.
 
> That's a good point. Looking at the disassembly, in the Master version
> anyway, there seems to be some logic that the first call to OSByte 0 returns
> the BBC B value but then also restores the interception back to its MOS
> default.
> Anyone know why?
 
I can only think that the authors wanted any occurance of
INKEY-256 to claim it was a BBC B, but only the first FX0,<>0 to
do so, and once FX0,<>0 had reported the machine was a BBC B, to
disable masquading. It could be from some investigation of
software that that was the best route to take.
 
It needs to disable masquading at some point as Z-Break puts a JMP
sequence in the middle of page &10 - even when page &10 - the
*shared* workspace - isn't owned by DFS!!!! I've had so many
problems trying to stop OSWORD &7F trampling all over page &10
when it doesn't own it that I'm strongly tempted to change the
documentation to say "&10xx - reserved for DFS and OSWORD &7F".
 
-- 
J.G.Harston - jgh@...                - mdfs.net/User/JGH
BBC BASIC for 30+ platforms - http://mdfs.net/Software/BBCBasic
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>