From: Ethan Dicks (ethan.dicks_at_gmail.com)
Date: 2007-08-27 17:42:24
On 8/27/07, ruud.baltissen@abp.nl <ruud.baltissen@abp.nl> wrote:
> But nevertheless both the sources are not really helpfull. The reason is
> that the CBM file system is based on this track and sector pointer at
> the beginning of each sector which only supports drives up to 16 MB.
> That's why I went for four bytes that can handle up to 2 TB. If it was
> easy to port the two-byte pointer to a four-byte one (and that's how it
> looked), I wouldn't have called for help :)
From what you've posted, this sounds interesting. I don't know if
this will be easy or incredibly difficult, but one aspect of the CBM
filesystem that's made one particular thing difficult for me is that
you can't easily seek to an arbitrary point in a sequential file. The
specific example I have in mind is why Infocom chose to implement
their Z-Machine's virtual memory scheme on the C-64 and the Apple II
with random disk blocks rather than an file under its DOS.
With modern machines, you point a Z-Machine game engine at a game
file, and it plays, no matter what the underlying platform. Back in
the 8-bit era, each platform's engine compiled in a memory map so that
the token fetcher "knew" that if it fell off of, say, the game page
that ran from $2000-$20ff, it should go load, say, track 8, sector 12,
then $2100-$21ff would be found at track 8, sector, 13, etc. It's
quick, and especially easy with CBM DOS to do this, but it means that
you need a dedicated utility to extract and deposit a game file to a
game disk. Long ago, when I had some Infocom games, but not others, a
friend with an Apple II came over, and we crossmapped the entire disk
"memory map" on both platforms, then transferred a game from the Apple
II to a C-64 over bit-banged serial. It took a long time, but the
C-64 was able to play the game file from the Apple perfectly (these
days, you'd just do a copy/cp/drag-and-drop or whatever, because the
engine just performs the platform's flavor of seek() or lseek(), etc.)
The reason for bringing this up is that you mentioned using a
different scheme than an embedded track-and-sector forward pointer.
What I'm especially interested in is some way to take an open file,
and calculate what block to read in if I know I want bytes 16384
through 16640, for example. I've been bouncing some ideas around in
my head for how to do this with a real 1541, but the scheme involves
tracing through the file at least once to build a map of the file as
it sits on the disk in the drive (since it's semi-random what blocks
get allocated unless you start with a pristine diskette). I'd love to
be able to _efficiently_ calculate the location of arbitrary blocks on
the mounted medium, and getting away from track-and-sector forward
pointers seems like a great time to consider it.
I doubt any other game uses the disk so predictably, nor could easily
be modified from the vendor's original to use a new scheme that
replaces, in effect, a proprietary one-file filesystem, but since
there are numerous Infocom titles and they are stll popular, it might
be worth considering this sort of support if it's not to difficult to
consider up front.
> I'll just go on struggling with the code :)
Good luck with it all.
-ethan
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.