From: Ethan Dicks (ethan.dicks_at_gmail.com)
Date: 2007-08-27 17:42:24
On 8/27/07, email@example.com <firstname.lastname@example.org> 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.