Adding virtual prodos filesystem support to JACE
BLuRry
unrelated thread, to add Prodos "virtual" drive support mapping a
physical directory as a volume root rather than a hard drive image.
The goal is better transparency with the host filesystem, of course,
and allows better use of my daily-use tools when dev'ing some stuff
for Apple // fun things. This also means I can translate this work
over to Apple Game Server and have a 100% serial OS (and actually,
it's crazy stupid easy to translate this over, just swap the Disk
driver @ f800 with a prodos block loader similar to the one I'm doing
now -- but that will be much later). It should also lend itself to
GSOS -- which would be extremely freaking nice since I have a //gs
with no 3.5 drive. :-D
So far, Boot0 is done -- or rather not really needed. It turns out
you just need to dump the PRODOS system relocator at $2000 and execute
it -- at least for Prodos 1.9, Prodos 1.4 didn't like it much. I
didn't even load the first track to $800 or the second track to $900,
since their jobs are to locate Prodos and load it to $2000 anyway.
Right now all that happens is the Prodos kernel tries to read block 2
from the virtual drive and gets and I/O error (I haven't implemented
that part yet), then responds with a relocation error. But what this
means is that:
1) My boot0 intercept is picking up that the PC goes to $c700 and
loading Prodos into RAM and executing it -- this is actually pretty
cool because there is a useful function driving this, and its method
signature is:
function brun(java.io.File file, int startAddress)
2) Prodos is detecting and reacting to the presence of the emulated
device.
3) My intercept code is working, so a JSR $Cx42 (42 was arbitrarily
chosen for the hell of it) is immediately picked up and handled by
java code, which emulates the firmware MLI processing, sets A and C
with results, and then returns a RTS opcode to trick the emulator into
thinking it was calling a program and returning from it. This logic
is really heavily patched together because the event handler grabs
hold of the processor directly and assumes it is a 65c02
implementation. For now this is fine but in reality this could break
in the presence of other implementations unless I refactor it.
Now the next part is building prodos filesystem structures on the fly
-- and this can be done in rather interesting ways that, for example,
can work past the root directory entries limitation (provided I read
Beneath Prodos correctly) and update directory structures if there are
files added during the emulation. In short, this should be a whole
lot of fun and a big mess I'm getting myself into at the same time.
Whenever I can start the emulator without it blowing up with stack
traces, despite what little of the harddisk emulation works, I'll keep
checking stuff into Sourceforge SVN for those who are curious.
-Brendan
Steve Nickolas
development :P
I had been working on a similar project which never went anywhere. But I
didn't use a virtual filesystem - I did a virtual implementation of the OS
itself (that's a lot more complicated and much harder to get right!) - which
may be part of why I failed. (Though, there's prodosemu, which does the
same thing.)
-uso.
BLuRry
> You have reminded me to dig out one of my old emulators and continue
> development :P
Sorry, Viral ideas. ;-)
> I had been working on a similar project which never went anywhere. But I
> didn't use a virtual filesystem - I did a virtual implementation of the OS
> itself (that's a lot more complicated and much harder to get right!) - which
> may be part of why I failed. (Though, there's prodosemu, which does the
> same thing.)
Well, I'm trying to balance a trade-off between simplicity and
functionality. it's easy enough to figure out what Prodos wants when
it is asking to read a block. Writes are a different story since it
could be anything from a file append, to an overwritten file, to a
file delete -- I might want to just intercept the global where Prodos
tracks the actual MLI call being processed and queue my logic off of
that. Would be less relocatable, but the tradeoff would be greater
code simplicity and not having to capture a series of block writes to
decipher what they're supposed to be related to.
I have the disk space allocation/deallocation logic done. Freespace
blocks are generated off of the allocation table on request. The
allocation table is queried during a read to determine what node in
the filesystem owns that corresponding block, then the work of
finalizing the read is passed to that node for proper handling, etc.
Now all that I have to do for a simple test is implement directories,
seedling, saplings and tree files -- at least in a read capacity for
starters.
-B