Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2031

Re: Why is this directory structure not parsing in Prodos?

Show all headers | View raw

On Thursday, December 31, 2015 at 5:28:53 PM UTC-6, gid...@sasktel.net wrote:
> On Thursday, December 31, 2015 at 5:25:19 PM UTC-6, gid...@sasktel.net wrote:
> > On Thursday, December 31, 2015 at 1:04:26 PM UTC-6, BLuRry wrote:
> > > On Thursday, December 31, 2015 at 12:55:00 PM UTC-6, BLuRry wrote:
> > > > On Thursday, December 31, 2015 at 12:41:16 PM UTC-6, BLuRry wrote:
> > > > > I've been working on revamping the Virtual folder support in Jace, which allows you to mount a physical folder as a prodos volume.  In order to make this work it generates the prodos structures on-the-fly to map the folders and files to their physical equivalents.  What I have currently works from Copy ][+ and I've been able to teleport a number of files (specifically the A2GameServer catalogue) into an HDV image.
> > > > > 
> > > > > However when I attempt to read the sub-folders from anything else, everything goes haywire from the half-mark of the second block of the folder.   In the pastebin example, you can see the root folder at block 2 and the sub-folder (a.thru.c) at blocks e and f.  When I look at the catalog from Shrinkit or DaveX, the Cyclotron entry shows as Cyossfire instead -- so it read the length of the entry and the first two letters but took the rest of the data from the previous entry and then terminated.
> > > > > 
> > > > > I'm not sure why this is happening, but if anyone can look at the volume structure and figure out what I've done wrong it would be immensely helpful.  The ... means the rest of the block in question is all zeros.  And the data that is shown is a dump of the emulator ram for that disk buffer so there's not a case of missing data (after all, it DOES work in Copy ][+ for some reason)
> > > > > 
> > > > > http://pastebin.com/raw/LPRZ1WMj
> > > > > 
> > > > > Thanks!
> > > > > -Brendan
> > > > 
> > > >  I should add that even though the sub-folders get munged, if I put several dozen entries 
> > > 
> > > Another observation:
> > > In the root volume it doesn't have the same problem even though it's written by the same code.
> > > 
> > > In super selector, I see duplicated entries in the folder for files 6 through 12 and the same entry gets mangled after the second character except that the last part of its name comes from the first directory block (CYPLE.ZAP) but has the correct file size for cyclotron.
> > > 
> > > So what it appears like is as if the first 202 bytes are read from the second directory block but the remaining characters are from the first block of the directory.  This is crazy though because what I showed in pastebin is written out of the Apple's memory after the read MLI call has been processed -- the data shouldn't exist in two places!  This is a very, very ugly gremlin. :/
> > 
> > 
> > 
> > If you look at the Main Volume Block starting at byte $3B, it shows the file called "A.THRU.C" as being a subdirectory, which is correct.
> > 
> > And the next two bytes show the key pointer which is $000e, which is correct.
> > The next two bytes are the blocks used shows $0002, which is also incorrect.
> > This value should be a 1.
> > 
> > And the next three bytes are supposed to be the End-of-File pointer, with a value of $02CA is also incorrect.
> > 
> > Directories always have a multiple of $200.
> > 
> > With 13 entries per block and one taken up by either the volume header or the subdirectory header, leaves 12 files for the first directory block and 13 for each one after.
> > 
> > Your main volume header only has 2 files in it, otherwise the bytes at $79.$89 would show another file name if there was another entry, even if it were deleted.
> > 
> > This means the correct values for blocks used is a 1, and the correct value for the EOF pointer is $200.
> 
> 
> 
> Ugh!  pressed the POST button too quick.
> With 20 files, the blocks used is correct at 2 blocks, but the EOF pointer should be $400 and not $2CA

You're right -- I found it this morning too after I looked at where it was truncating again and went searching for 2CA or CA 02 in the data after realizing it was always cutting off in a very specific spot.  Works now!  Thanks for the extra set of eyes!!

Commit details:
https://github.com/badvision/jace/commit/732f4768a6d5f02acd2cb21c989a4b10c21537b0

If you build Jace from source (it's relatively easy; I package it as a Maven project) you can start it up and attach any folder as a prodos volume.

If your file has extensions like .BIN or .SYS then they will be treated as binary or system files.  If your file ends with .BIN#6000 then it will have the type BIN with AUX type 6000 (hence will load at $6000)  You can also use no file extension and just #TTAAAA where TT is the hex type (06 = bin, etc) and AAAA is the four-byte hex aux type like the previous examples.

So mygame.bin#0300 and mygame#063000 would both be loadable games.

Oh, one more thing, if you put prodos.sys then it will be bootstrapped and run as a bootable disk (even though there's no generated boot sector...  I just dump it straight to RAM ;-) )

-B

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Find similar

Thread

Why is this directory structure not parsing in Prodos? BLuRry <brendan.robert@gmail.com> - 2015-12-31 10:41 -0800
  Re: Why is this directory structure not parsing in Prodos? BLuRry <brendan.robert@gmail.com> - 2015-12-31 10:54 -0800
    Re: Why is this directory structure not parsing in Prodos? BLuRry <brendan.robert@gmail.com> - 2015-12-31 11:04 -0800
      Re: Why is this directory structure not parsing in Prodos? gids.rs@sasktel.net - 2015-12-31 15:25 -0800
        Re: Why is this directory structure not parsing in Prodos? gids.rs@sasktel.net - 2015-12-31 15:28 -0800
          Re: Why is this directory structure not parsing in Prodos? BLuRry <brendan.robert@gmail.com> - 2015-12-31 20:02 -0800

csiph-web