#: 8129 S12/OS9/68000 (OSK)
11-Nov-90 22:50:33
Sb: #Reading 68000 disks
Fm: Greg Law 72130,23
To: Kevin Darling 76703,4227 (X)
Kevin,
I am at wits end trying to convert a "Universal format" disk. According
to the information given to me by Stephen Weller at Windsor Systems, the
Universal format disks for OS-9/68000 (3.5 inch) use 16 sectors per track with
a sector and track offset of one. Well, I've written this program that runs on
the PC-clone that reads CoCo format disks beautifully so I altered the source
code to change the track offset to one and 16 sector tracks. It reads the ID
Sector (LSN 0), the file descriptor for the root directory, and the root
directory entries just fine. But when I select CMDS from the root directory, I
get a bizarre looking file descriptor for the CMDS directory. The first few
entries look just fine, but when it gets to the created date it's set at 4/3/50
or something similar. Examining it closer, it appears there is one byte extra
in the file descriptor from somewhere. Yet, the segment list looks fine and it
jives with the filesize. In other words, CMDS/basic is supposed to start at LSN
8 and occupies 216 sectors. The file size is 55,xxx bytes and seems to jive
with 216 sectors. I figured if the segment list looks okay, Microware must have
stuffed some funny values for the creation date and the User ID is 256 (1.0?).
When I look at the sector data at LSN 8 (CMDS/basic), the first four
values are $00,00,00,00 - I thought the header should be $4A,FC,xx,xx. I took a
peek at CMDS/runb and it's the same way. Is this normal for OS-9/68000
executable files? I've diddled the LSN values up and down and haven't spotted
anything yet - but LSN 9 has the string "Trap not installed" which seems to
allude to the fact that this must be CMDS/basic. It's a real bummer examining
all of this stuff at home on a PC with the 68000 system sitting on my desk at
work so I don't have the ability to run it through an ident or compare it
against a known good executable file.
-- Greg
There are 2 Replies.
|