Re: Debugging an (unsuccessful) prodos boot

[Scott Hemphill <hemphill@hemphills.net>]

BLuRry <brendan.robert@gmail.com> writes:

> 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"?)

So, you are debugging your emulation then?  Then there are a couple of
things you might want to fix: the "e5" at byte 5 should be "f5" to
indicate that it's the volume directory.  Also the block counts for the
files should be fixed.  Right now they're all 1s.

Scott
-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear