General Category > LisaList2

Workshop

<< < (5/5)

D.Finni:

--- Quote from: rayarachelian on March 16, 2019, 07:38:04 pm ---Yeah, I'm doing the same thing, and will add to lisafsh-tool as well as create a tool to rebuild the tags.

--- End quote ---
OK, we can compare notes. Here are three new discoveries:

- MDDF offset 158 contains the next file ID to use when creating a new file. After you delete a file, that file's ID is stored here, I assume in an effort to keep file IDs contiguous.

- Files and subdirectories (or sub-catalogs) have a separate ID numbering space. It is possible to have a file and a subdirectory with the same ID.

- Within the file attributes of a normal file entry (64 bytes long), bit 2 set is the safety switch (locked), bits 0 and 1 is protection, and bit 5 is set if the file was closed by the system

claunia:
It's already been reverse engineered:

https://github.com/discimagechef/DiscImageChef/tree/master/DiscImageChef.Filesystems/LisaFS

The only thing pending to do is the Office System catalog file (where it stores the relationship between real files and GUI files, as well as GUI positioning, etc)

claunia:

--- Quote from: D.Finni on March 16, 2019, 07:01:40 pm ---Thanks. I will try the ones from 1984 and see if I can build a Macintosh application that runs without bombing. ;-)
By the way, people running Mac OS X can build MFSLives, the file system plugin for MFS, and mount these old MFS disks in the Finder. Comes in handy.

Regarding the Lisa file system, I spent about two days reverse engineering the v3 Lisa file system by creating new files and catalogs using the Workshop File Manager, then examining the changes to the on-disk data structures. I'm not sure it's actually a B-Tree structure, as some others have stated. I also found this little graphic (attached below).

Once the MDDF is located, I think it's possible to walk the entire volume and access every file without the aid of tags. But I still need to identify and resolve a few more data structures.

Looking forward to Apple's approval of the Lisa OS source release so we can have a better understanding of the file structures...

--- End quote ---

It is a B-Tree but you will never see it creating leaves unless you use Workshop 3 to create nested catalogs or fill the disc with thousands of files. Each directory block is 4096 bytes, the end of it is a footer with pointers to next, siblings, etc.

D.Finni:

--- Quote from: D.Finni on March 14, 2019, 04:57:44 pm ---
--- Quote from: sigma7 on March 14, 2019, 03:46:19 am ---I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:
Set 1:

--- End quote ---
I think the disks in Set 1, from 1984, would be worth a shot.

--- End quote ---
I tried the 1984 Workshop 2.0 Supplement Disks, and the short story is: no joy; the application still crashes on the Mac 512K.

The long story:

I installed Workshop 2.0 on a new ProFILE image in LisaEm. I then copied the contents of the MacSupplement Lisa Workshop 2.0 disks, named BB1401.img thru BB1408.img

The "Samp" application wasn't on these disks, but "Boxes" was, and it included an Exec file (Example/BoxesX.text) so I ran that. Evereything looked fine-- I got the usual sequence of Pascal compiler, code generator, linker, resource compiler, and MacCom.

But when I mounted the resulting disk on the Mac 512K and ran the Boxes application, it crashed the same way with a 1111 Err. I disassembled the code using MacsBug and I saw a lot of garbage in between the legitimate 68000 instructions. I saw the toolbox traps. There is a lot more garbage in the code compared to what I saw coming out of Workshop 3.x. :o

Apple distributed a pre-built copy of the Boxes application, which works of course, so I was able to disassemble that to see what the code should look like.

So, it's looking more like an emulator fault, as it's hard to believe that Apple would ship an example application with Exec file that would compile to garbage and crash on the Mac.  :-\

Thanks for digging out these disks.

rayarachelian:
 ??? so all these things, the thumbs for the scroll bars being in the wrong place, the duplicated entries in the Desktop menu, the extra inserted junk instructions make me think that the results of some math operation somewhere is slightly larger than it should be.
You didn't see less code being inserted, you saw more, and stuff that shouldn't have been there. It still doesn't help pinpoint what it is exactly, but it is another clue. Some opcode in very specific but unknown contexts is returning a larger result than wanted. Whether mul/div/add or shift. Some ALU related opcode produces a result larger than it should, and that's used in a loop.

Navigation

[0] Message Index

[*] Previous page