Date : Thu, 20 Oct 1994 10:20:34 +0100 (BST)
From : clr1@...
Subject: Re: BBC: Disk Handling
I had a shot last night at implementing T1 but I didn't get very far.
I've discovered yet another bug in my emulator. As soon as I type "PRINT
TIME" the screen appears to clear, and then the BBC hangs. I have no idea
what's wrong with it.
The problem is that I'm going to have great difficulty finding out what
is wrong with it, because I am in St. Andrews again and I don't have a
BBC. I do have the permanent St. Andrews student cold, though, and yes -
it is raining. *groan*
Anyway, back to the subject in hand.
I don't like double-quoting but I think it's in order here!
On Wed, 19 Oct 1994, David Barnett wrote:
> Chris L. Rae Wrote:
> >My gut feeling is that an emulator should emulate the *whole* machine, if
> >possible. That means disks too. So I think that if you have a BBC
> >emulator, you should be able to stick BBC disks in it.....
>
> I can imagine this would be needed for some games which did obscure copy
> protection things (you would have to emulate the entire controller for some
> of these. For the older games that would mean emulating the 8271 as well).
I wasn't planning on doing that. It is tempting, mind you, because I
think the PC disk controller is in fact an 8271 as well and you could
just channell all 8271 operations directly to it, but I'm afraid I'm
chicken. I'm not all that keen on letting ADFS loose on 500Mb of stuff
that I don't have a backup of!
> Some old programs were recorded in a dual 80/40 format following my
> article in Acorn User c.1984.
Well, thanks a lot! Tsk, tsk.
> >My other idea was to set up a virtual hard disk on the PC; just a big
> >long file. Then I would intercept ADFS calls to read/write sectors to
> >that as well, and hey presto - ADFS would do all of its own filing on a
> >hard disk too.....
> >
> The BBC was designed to work with multiple filing systems. There is no
> reason why you should not make a simple PC/BBC filing system. The BBC
> portion would intercept the relevant BBC vectors and point them to some
> unused poition of the memory map (say part of Shiela unused). When the
> emulator detected a branch to these addresses it would call regular PC
> routines (are you writing is C?) to do file load/save, read/write,
> open/close etc.
That's a nice idea actually - I hadn't thought of that. That would mean
that I could have my ADFS BBC disk reader *and* PC virtual disks. In
answer to your other question, I'm writing in 8086 assembler. Well, I
suppose technically I'm writing in 80286 assembler because there are a
couple of 286-specific instructions but it would be easy to convert it.
> The only thing extra to do would be to include catalogue info: load and
> execution addresses. On a Mac I would put these in the resource fork (even
> though it wastes disc space), on other platforms I would put these at the
> beginning of the real file with the BBC virtual file starting from after
> the cat block. If you have programs which rely on directory level
> separators being '.' then your emulator could translate these but in the
> first instance I shouldn't bother.
I've discussed this with another person (no offence but I can't remember
who it was) and we seemed to agree that putting info like that at the
beginning of a file was the best idea. I toyed with using the time/date
fields that DOS has (and the BBC hasn't) but I'm not exactly sure how
much space these leave. Creating another file uses too much disk space;
on some DOS systems creating a 16 byte (or whatever) file wastes 8Kb of
disk space. I'll never forget the feeling when I did a DIR of Visual
Basic's icon directory - it said "90,000 bytes in 200 user files" or
something like that and "950,000 byte allocated"...
Isn't technology a wonderful thing.
+-------------------+-------------------------------------------------+
| /-- |_| /-- | (~ | "And the driving is like the driving of Jehu, |
| \-- | | | | _) | the son of Nimshi, for he drives furiously." |
+-------------------+-------------------- Second Book of Kings 9 v20 -+