Re: Debugging an (unsuccessful) prodos boot

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

On Feb 9, 3:59 pm, Scott Hemphill <hemph...@hemphills.net> wrote:
> BLuRry <brendan.rob...@gmail.com> writes:
> > I'm in the midst of debugging a very hard problem.   Trying to
> > determine why Prodos is unwilling to start.  It relocates, then reads
> > the root volume.  No other MLI calls are made, and it spits out a
> > relocation error.  The filesystem is a large prodos volume with only a
> > few files in it; though it is most likely that the volume header block
> > was written incorrectly somehow.
>
> > The volume block is as follows:
> > 00 00 00 00 e5 2e 4a 41 43 45 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 dc 00 01 19
> > 19 00 03 27 0d 0b 00 06 00 ff ff 18 53 45 54 54
> > 49 4e 47 53 00 00 00 00 00 00 00 06 00 00 01 00
> > 10 00 00 b0 00 0a 13 19 00 ff 00 03 b0 00 0a 13
> > 02 00 2e 53 59 53 55 54 49 4c 2e 53 59 53 54 45
> > 4d 00 ff 01 00 01 00 0e 03 00 b0 00 09 25 19 00
> > ff 00 20 b0 00 09 25 02 00 24 55 54 49 4c 00 00
> > 00 00 00 00 00 00 00 00 00 00 03 00 01 00 00 ab
> > 00 b0 00 09 2c 19 00 ff 00 09 b0 00 09 2c 02 00
> > 2c 42 41 53 49 43 2e 53 59 53 54 45 4d 00 00 00
> > ff 04 00 01 00 00 28 00 b7 00 10 30 19 00 ff 00
> > 20 b7 00 10 30 02 00 2f 46 41 53 54 43 4f 50 59
> > 2e 53 59 53 54 45 4d ff 05 00 01 00 56 4e 00 b8
> > 01 0f 2a 19 00 ff 00 20 b8 01 0f 2a 02 00 2f 4c
> > 41 55 4e 43 48 45 52 2e 53 59 53 54 45 4d ff 16
> > 00 01 00 2c 1d 00 b8 00 0a 31 19 00 ff 00 20 b8
> > 00 0a 31 02 00 26 55 54 49 4c 2e 31 00 00 00 00
> > 00 00 00 00 00 06 17 00 01 00 b0 79 00 b0 00 0a
> > 13 19 00 ff 00 0e b0 00 0a 13 02 00 24 55 54 49
> > 4c 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01
> > 00 85 04 00 b0 00 09 2e 19 00 ff 00 04 b0 00 09
> > 2e 02 00 25 43 4c 4f 43 4b 00 00 00 00 00 00 00
> > 00 00 00 00 19 00 01 00 59 1e 00 ba 80 17 1f 19
> > 00 ff 00 00 ba 80 17 1f 02 00 17 43 4f 50 59 2e
> > 4d 45 00 00 00 00 00 00 00 00 fc 1a 00 01 00 24
> > 00 00 ae 00 0e 33 19 00 ff 01 08 ae 00 0e 33 02
> > 00 26 50 52 4f 44 4f 53 00 00 00 00 00 00 00 00
> > 00 ff 1b 00 01 00 e8 42 00 ba 00 11 0a 19 00 ff
> > 00 20 ba 00 11 0a 02 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> I haven't seen a 32MB ProDOS filesystem formatted this way before.  The
> volume directory and the bitmap are at their usual places (block 2 and
> block 6, respectively) but the volume directory is limited to a single
> block (maximum of 13 files at the top level) and the files are allocated
> starting at block 0, weaving around the directory and the bitmap.  Since
> blocks 0 and 1 are occupied by the files SETTINGS and SYSUTIL.SYSTEM,
> there are no boot blocks present and this filesystem should not be
> bootable.  How are you booting it?

I stick PRODOS[.sys] into ram at $2000 and point the program counter
to it.  :-)   Block 0 == Boot0 bootstrap loader (don't need it for
this since all it does is locate Prodos and load it to $2000 as well),
and Block 1 == Apple /// bootstrap loader (really don't need that
either).  As for why the root volume has only one block (12 files),
it's because there were no more than 12 files present in the folder I
pointed the emulator to.  What happens, in practice, is that if a
directory has 13 files, when queried it will present itself as having
two blocks.  Basically, as files are added in the "real" directory,
the virtual directory grows on the fly -- maintaining the reserved
base block but allocating additional blocks as needed.  I could have
the main volume reserve 4 blocks as per the standard way of doing
things -- but the dynamic growth allows to exceed 51 blocks in the
root volume and so on.

Agreed, this arrangement would be completely unreasonable for a
physical disk -- but it's not a physical disk, just a mere simulation
of one that presents itself to Prodos as a block device.  And, because
of that, the directory structures, block numbers, etc, are all
dynamically regenerated whenever they change as needed.  For cases
where a host OS changes a file, the emulation should reflect an
updated directory structure as needed.  Until a base implementation is
operational, it will be hard to address where the wheels will fall off
(e.g. what happens if Prodos has stuff cached in-memory and that is
stale compared to what is on "disk"?)

-B