General Category > LisaList2

Monitor format for ProFiles

(1/4) > >>

stepleton:
This is a long-shot question: does anyone know anything about the hard drive format used by the Monitor?

(For those not aware: the Monitor is the internal-only* operating system and development environment that Apple used when creating the Lisa OS and applications that it released to the public. The Monitor is a bit like a cross between the Pascal Workshop and the UCSD p-System, perhaps being closer to the p-System. There are a few Monitor floppy disk images on Bitsavers, as well as some user documentation. There is also a source listing that may answer my question, but I haven't examined it too closely yet.)

Without documentation about Monitor internals (that I'm aware of), you might not expect to have much to go on when making guesses about how the filesystem is organised. As it turns out, though, the floppy images use the same filesystem as the p-System. If you extract all of the sector data from a disk image and place it in a single file, you can read it just fine with utilities from this project. The disks make no use of sector tags (except to mark sector 0 as bootable). Additionally, the affordances of the Monitor file manager and hints from the user documentation suggest that a hard drive would also use a p-System-like filesystem.

With that in mind, I have tried using the filesystem utilities linked above to make a fresh 5 megabyte p-System filesystem image, then giving that image some blank sector tags and loading it into my ProFile emulator. This does change the behaviour of the Monitor version I tried it with---it seems to make it crash more! (More than it did with a hard drive image with BLU on it.) There are many possible reasons for this behaviour, but it may be because the Monitor is trying to read the filesystem and is getting some unexpected data (zeroes, in fact) back instead---that is, my formatting is incorrect.

There are many additional diagnostic and trial-and-error things to attempt to figure out what's going on, but I thought I'd ask just in case---does anyone just happen to know how the Monitor filesystem was arranged on ProFiles? If so, I'd love to hear about it...


* Internal-only: technically LisaTest was an externally-released Monitor disk, but it booted straightaway into the LisaTest GUI and didn't let you use the p-System-like user environment.

rayarachelian:
I've never seen monitor installed on a profile, so that's pretty cool. I'd ask to try to figure out what the maximum sector number it searched for was? This may help figure out what the internal limits are. i.e. is it 16 bits, 12 bits? some other thing?

How is to booting? Did you find a bootloader for Profiles for Monitor or did you use your own? If you used your own, how does monitor know where it's file system starts and the boot loader end?

This might also help: http://ucsd-psystem-fs.sourceforge.net/ucsd-psystem-fs-1.22.pdf but it's way too modern, and it does mention interleave, so not sure if the one from 77 of whatever the Lisa used would have it too.

This might help: http://bitsavers.org/pdf/apple/lisa/pascal_monitor/Monitor_11_Listing_Sep82.pdf

Not to be a one trick pony and say that this is a nail, but I'd approach this by enabling tracelog in LisaEm like so: `./build.sh --with-debug --with-tracelog` - with 1.2.6 I'd enable the define that turns on tracelog on start, on 1.2.7, I'd add `--with-debug-on-start` and then boot monitor from a profile as you've set it up. The tracelog it would generate would produce many gigs of output but it would contain everything Monitor did and tried to do, but failed.

Next I'd ask if it's smart enough to do some sort of interleave on the hard drive, but I'd guess it likely wouldn't.

rayarachelian:
So in http://bitsavers.org/pdf/apple/lisa/pascal_monitor/Monitor_11_Listing_Sep82.pdf on page 21 at address 0B12 there's a mention of cluster size and another comment saying #$100 (256) is the start of the volume table.

On page 23 there are comments about profiles with and without headers, not sure what the difference is. page25 has mentions of corvus and pipin and "cable disk" - interesting.

Bingo! page 29 at 110C there is an 9:1  interleave table. Likely that's what you need to make this work

I wonder what this Marksman interface was (page 32-33), there's mention of a 4 port PIA (Parallel Interface?)

At 2924 on page 63 we see the 1st block is 0000 and the last is 7fff. So that gives you the max size of the disk to 32768 blocks or 16384K or 16MB, but don't know how clusters work here so that would change the size to much larger.

At page 90 3C42 mentions macsbug (which is also on the mac - but the mac in macsbug does not stand for macintosh, rather it comes from motorola as a 68000 debugger). Warms my heart to see it mentioned here. Good times. :)

stepleton:
Thanks for the insights!

I think I wasn't clear in my initial post---I'm not booting from a ProFile, or even accessing a ProFile successfully at all. I'm still starting Monitor from Twiggies, and then trying to get it to do anything with the ProFile besides fail to access it. I'd like to have a bootable Monitor ProFile someday, but am not even certain how possible this might be. On the other hand, it may not be too hard, and you might even get my bootloader to do it with some tweaks...

Anyway, your thoughts inspired me to spend several hours this afternoon poring over the listing and experimenting.


1. The first thing I tried is just filling every block on the disk image with an empty p-System disk catalog. Forget interleaving---if it reads anything on the disk, it's going to find that the disk is formatted and has no files on it. Sadly, no joy. The system seems to carry on as if no drive were plugged in---well, except for randomly crashing into MacsBug with an unserviced level 5 interrupt all the time. Not sure why it does this.


2. Now, looking at PDSKRD in the monitor listing ($121C on), it seems like there's a simple disk block checksum mechanism at work during reads. If the read is configured to use disk headers, then the checksum is computed over the entire 532-byte block; otherwise it only does a checksum of the 512 data bytes (and then ignores them; statements $12B8 and $12BC). I think you can bypass the checksum check in "header mode", though, if the seventh byte of the header is positive (statements $12BE and $12C2). So I tried filling every byte of every header with the obviously positive byte $21. Still didn't work.


3. Although LisaEm would surely have been effective for peeking behind the scenes, I decided to investigate the Monitor's disk activity with my hard drive emulator---it's easy to do, since it's a tiny Linux computer, and you can just log in and watch the log messages scroll by. On boot (and when you attempt to mount a ProFile in the System Manager as well), the Monitor attempts to access blocks $000003 and $000007, which, if I've reversed the interleave scheme correctly, means that the Monitor was asking for blocks 7 and then 11... but only if we were in header mode! (Statements $11F0 and $11F4; in "non-header mode", it looks like you don't interleave.

Unfortunately none of these blocks make sense to me. On floppies, block 3 is the second block of the file directory., block 7 is the second block of the first file on the disk, and block 11 is the sixth block of the first file (assuming it extends that far). I'm not sure---maybe the filesystem layout is different in hard drives?

I guess the main thing to figure out then is why it tries to access these blocks. I still haven't been able to pinpoint the spot in the code where it does this. Hmm...

stepleton:
Well, an update---it turns out that I was silly and missed something important. You can initialise a ProFile in the Monitor after all---just use the Z(ero command in the S(ysMgr. Reads and writes to the ProFile work just fine after that.

There is however an additional problem, which is that if you restart the computer (and boot the Monitor from a Twiggy again), the Monitor will now hang at some point midway through the startup process. Fortunately the Monitor has installed MacsBug prior to the freeze. I've started to use it to investigate the hangs, but have some ways to go. It seems that the Monitor is trying to report an I/O error of some kind and is waiting for the user to acknowledge this by typing the space bar, but no message appears on the screen and pressing the space bar does nothing. It's possible that this communication is actually going to somewhere besides the screen, though I haven't had any success yet from listening in on the serial ports.

The freezing occurs only when an initialised ProFile is attached to the parallel port---if you have an uninitialised ProFile ready, then it will still boot. This freezing behaviour occurs even when the ProFile has an Office System 1.0 filesystem installed (instead of a Monitor filesystem---I'm not sure how similar these filesystems are---or if whether might be the same). It doesn't seem to matter whether you're using a genuine ProFile or an emulator, though I haven't tried initialising my real ProFile (I don't want to blow away my Office System install on that disk right now).

Other notes:

After reading Monitor documentation on Bitsavers, I haven't seen any evidence that you could install and boot the Monitor off of a ProFile. There's discussion of using the ProFile as a working drive, but nothing about how to install a bootloader or anything like that that I can recall. It's possible that Apple folk just always booted the Monitor off of floppies or from the connected Apple machine (the documentation often discusses having an additional "Apple" of some kind as part of your workstation).

I've determined that the unserviced Level 5 interrupts that I had mentioned upthread were probably being raised by my AppleNet card. Removing the AppleNet card seems to have got rid of these.

Navigation

[0] Message Index

[#] Next page