Re: Debugging an (unsuccessful) prodos boot

[BLuRry <brendan.robert@gmail.com>]

> Congratulations!  I'm glad things are working.  A couple of more things
> about your emulation: you've set all the bits in the access codes, but
> one of them is the invisibility bit.

Oops... funny enough everything shows up.  Oh, but I said that pre-
empting the good part: Read-only operations are working now!  It boots
to basic, I can also run launcher.system and system utilities (though
I'm not going to try disk copy, that would be odd)

> the other thing is: does putting a file in block 0
> work?  A zero pointer is used in the index block to indicate that no
> block is allocated.

Yeah, I wondered that too.  For now, I patched the allocation routine
to never return anything less than 2, so that the boot sectors are
unused.  I don't think that it would cause an issue unless the entry
was a subdirectory that spanned more than one block.  So it's probably
best to not allocate there.  The next fun things to fix are block
counts (as you've seen) and dates.  I should be able to estimate the
number of blocks required for each file/directory without actually
allocating the prodos space for it until needed.  Requires some
refactoring.  As I suspected, Prodos doesn't really care about the
block count in the volume when it reads the file, but it looks odd
that everything is only one block until accessed.

So, the code is checked in to sourceforge, but the volume root folder
is hardcoded for now in CardMassStorage.  I uploaded an archive of the
root volume of the prodos 1.9 utilities disk to the "supporting files"
downloads section of the project.  Extracting these files to a folder
and pointing the CardMassStorage root to that folder should do the
trick for anyone that cares to grab code and experiment.  I'll release
a beta when it is a little more user-friendly (e.g. configuration
support so things aren't hard-coded).

-B