Date   : Tue, 01 Nov 1994 17:58:55 -0600
From   : barnett@... (David Barnett)
Subject: Re: Reading BBC disks

Mark Cooke Writes:
>
>I'd also like to start a discussion on everyone's ideas for doing disk
>I/O.  Various ways have been bandied about.
>
I shall comment on the approaches Mark lists:
>
>1. Intercepting the FDC read/write and emulating the FDC and physical disk.
>
This is the most difficult an least elegant solution.  There may be some
severe timing problems because of the need to emulate the NMI line on the
6502 and take a byte at a time.  Its sole merit is that some games would
work which accessed the controller directly (usually for copy security)
would work.  Related to this is the issue of emulating illegal opcode
effects on the 6502 itself.   Any programs which did this broke when run on
later models and even later versions of the same machine.  Originally there
was the 8271, then 1770 then 1772 and 8272 what are you going to emulate?
Same applies to the illegal opcodes on the 6502.  Not only did later models
use 65C12 where these do other things but not every manufacturer of the
6502 did it the same way.  (Incidentally I suggest you emulate a Master
with its 65C12 for maximum utility).
>
>2. Intercept osword 7F for sector read/write
>
This is almost as bad as 1 above but not quite as difficult since this can
go off to the emulator.  Osword 7F was not in the MOS but passed to the
sideways ROMS to identify and handle.  If you really want this one it could
be part of the ROM written for 3 below.  It has the same hardware specific
objections as 1.  The only times I personally used 7F to access the 8271
was when I wanted to make disks dual readable on 40 and 80 track drives
(see my Acorn User article Feb.1984) or to read/write 40 track discs on 80
track drives.  If your hope is that this is enough to get the DFS to work
beware that the DFS may sometimes call itself internally and bypass the
OSWORD call.
>
>3. Blow it all, and write an FS rom that breaks out to the emulator.
>
This is the simplest and most elegant solution.  As far as most programs
are concerned All exterior storage is in the form of files which are really
just chunks of bytes.  How to do it?

1. Every emulator should have a way for a BBC program to call it.  I
suggest that if the PC points to SHEILA at the time of an instruction fetch
the instead of reading the BBC memory map a direct emulator call be
executed.  X,Y and A can hold data used by the BBC/emulator interface.  The
address called can indicate the required routine (note the can be spaced
just 1 address apart).

2. Write a sideways FS ROM whose sole purpose is to respond to the relevant
MOS poling calls (*HELP, unidentified command, change of FS etc. - see
advanced user guide and Master series reference manuals), and when becoming
the current filing system to set the FS vectors (FINDV, OSFC etc.) to point
to the relevant SHEILA addresses.  The emulator (written in C most likely)
will simply repackage these calls and then call the hosts file functions.

3.  The FS ROM should also respond to the commands *CAT and *DIR. and any
other manipulation you might want to do at the BBC keyboard.  I Think
*SAVE, *LOAD and *DEL. are handled by the MOS using OSFILE.  *SPOOL and
*EXEC look to the FS like any other fileopen requests.

4.  Messages/catalogues from the FS should cause streams of bytes to go to
OSWRCH in case a program is looking out for these but the catalogue output
should be whatever is natural to the host machine.

5.  Optionally the FS ROM could recognize OSWORD 7F etc. but I shouldn't
bother.


Happy coding.

David Barnett