LisaList2

General Category => LisaList2 => Topic started by: D.Finni on March 01, 2019, 04:13:34 pm

Title: Workshop
Post by: D.Finni on March 01, 2019, 04:13:34 pm
I have an article on Lisa Workshop Pascal for Macintosh Development (https://macgui.com/news/article.php?t=477) and I'm missing the latest Workshop Supplement '86 disks that should have the latest libraries and interfaces for Macintosh Plus.

Now I came across these three disk images on another site, but the problem is the disks were imaged with DiskCopy 6.x, so there's no tag bytes in these images.

Anyone have these last Supplement '86 disks?
Title: Re: Workshop
Post by: rayarachelian on March 01, 2019, 05:26:35 pm
Very cool article!
One thing to note, I've seen bugs in LisaEm where the linker throws either a bus error or "Bad Intrin Instruction" error, it may be possible to use LPW in a limited fashion, but you'll likely run into this at some point. A real Lisa would help in your efforts - at least until I find a fix for it, or you could use IDLE.

I do not have those supplement disks, but perhaps the tags can be regenerated. The tags are important for booting LOS - the boot ROM and the boot sector absolutely requires tags, but theoretically it should be possible to regenerate the tags for normal files as what they are, are just volume id, next/previous and file id values, all of which are available elsewhere.
The Lisa file system uses inode like blocks that, unlike unix, also contain file names. The file id is the same as the block id of these inodes offset by the start of the volume (I think the boot blocks - that is file id bbbb might be outside the file system I don't recall off the top of my head). But basically if you find the thing that looks like an inode for a specific file, say that's block # 100 and the first 30 blocks are the boot loader, then the file id should be 70. These values are just examples and have little basis in reality, but for illustration purposes.  ;D The inode like block also has a list of the blocks in the files, I think they're pairs of words indicating a start/stop for a run, also offset to the start of the file system's first actual block. So then, with that you can then set the file id tag on each of those to the inode block #, and then the previous/next as well...
I should be able to whip up some code using libdc42 to be able to resurrect the lost tags from the inodes as described above, but I'm currently swamped with a ton of work related projects which is why it's taking so long to port the old LisaList archive here.  :'(
If they're actual Disk Copy 6 format file, what happens when you restore the Disk Copy 6 images to actual floppies, then reimage them to dc42 format? If they were made as Disk Copy 4 format from Disk Copy 6 they shouldn't need to be converted and might be readable in LPW despite the lack of tags. (Does anyone know the file format that native Disk Copy 6 uses?)

Does LPW reject them when you try?

I do see that bitsavers has Workshop Supplement 85 and not 86 here (http://bitsavers.org/bits/Apple/Lisa/workshop_3.0/) , which might or might not help.
Title: Re: Workshop
Post by: D.Finni on March 03, 2019, 04:51:22 pm
Very cool article!
One thing to note, I've seen bugs in LisaEm where the linker throws either a bus error or "Bad Intrin Instruction" error, it may be possible to use LPW in a limited fashion, but you'll likely run into this at some point. A real Lisa would help in your efforts - at least until I find a fix for it, or you could use IDLE.
I was wondering if it's an emulator bug... The resulting Macintosh application produced from the Workshop crashes when launched on the Macintosh. I opened MacsBug (the disassembler) and the assembly code isn't being generated correctly. There's some garbage, maybe a debugger label or something, that's getting inserted among the legitimate 68000 instructions.

Quote
I do not have those supplement disks, but perhaps the tags can be regenerated. The tags are important for booting LOS - the boot ROM and the boot sector absolutely requires tags, but theoretically it should be possible to regenerate the tags for normal files as what they are, are just volume id, next/previous and file id values, all of which are available elsewhere.
I was looking into doing that too. I am more familiar with the Macintosh filing system and its tags, which are documented in Inside Macintosh. I looked at all the Lisa documentation on Bitsavers archive, and could not find any documentation for Lisa tags.


Quote
I should be able to whip up some code using libdc42 to be able to resurrect the lost tags from the inodes as described above,
I could do it if I had access to Lisa file system documentation, or at least an outline of the algorithm needed to reconstruct the tag data.


Quote
If they're actual Disk Copy 6 format file, what happens when you restore the Disk Copy 6 images to actual floppies, then reimage them to dc42 format?
Disk Copy 6 has a command to convert the image files to 4.2 format. I did this, and you can mount the resulting image in LisaEm. Then in Workshop, you can read the disk's volume name, but you can't catalog it. This is almost certainly because the tags are missing.

The frustrating thing is that on the Macintosh, I have an application called Read Lisa, that will mount and show ASCII text files from Lisa 3.5" disks. This application works fine to show the contents of these Disk Copy images, but there's no way in the application to do anything more. So all I know is that the data on the disk images is good; it's just the tags are missing because the person used Disk Copy 6 instead of 4.2.

I don't recall the web site source for these disks images, but if I find it again, I'll post the link.

Quote
I do see that bitsavers has Workshop Supplement 85 and not 86 here (http://bitsavers.org/bits/Apple/Lisa/workshop_3.0/) , which might or might not help.
Yeah, maybe I should try only using the 1985 Supplement and see what happens. It could be that trying to mix the 1985 and 1986 files is leading to Macintosh applications which crash.
Title: Re: Workshop
Post by: rayarachelian on March 04, 2019, 09:11:37 am
Quote
I was wondering if it's an emulator bug... The resulting Macintosh application produced from the Workshop crashes when launched on the Macintosh. I opened MacsBug (the disassembler) and the assembly code isn't being generated correctly. There's some garbage, maybe a debugger label or something, that's getting inserted among the legitimate 68000 instructions.

Yeah, so the Lisa compiler, or perhaps linker will absolutely add the function/procedure name either before or after each function in a weird way, I think off the top of my head it takes the first byte and flips the high bit on, or something like that. I have code in LisaEm when debugging is enabled that looks for these and flags them so I know what's being executed and when. But the emitted code should ignore these and should branch/JSR/JMP around it.


I suspect it's less of a bug than perhaps there's some routine that needs to run that can strip those out and use them as the resource names in CODE resources. Or maybe you're using too new a version of the Mac System Software and it's setting up the CODE resource pointers incorrectly.


The tags are well documented, the Lisa's File System isn't. I started to do that a long time ago, and @claunia finished the job. I have notes somewhere that I've been meaning to turn into a new version of the lisafsh-tool. Perhaps I should revisit that soon'ish.

If you run lisafsh-tool on a proper image with tags and walk through the sectors you'll see the tags and what they mean.

For example:
-----------------------------------------------------------------------------
Sec 0:(0x0000)   Used Block Part of file bootsect-aaaa:"bootsect-aaaa"
-----------------------------------------------------------------------------
            +0 +1 +2 +3 +4 +5 . +6 +7 +8 +9 +a +b
tags:       00 00 00 24 aa aa . 00 00 87 ff 07 ff             
           |volid| ??  |fileid|absnext|next|previous

block 1-26 boot blocks:

Sec 1:(0x0001)   Used Block Part of file OSLoader-bbbb:"OSLoader-bbbb"
-----------------------------------------------------------------------------
            +0 +1 +2 +3 +4 +5 . +6 +7 +8 +9 +a +b
tags:       00 00 00 24 bb bb . 00 01 87 ff 07 ff             
           |volid| ??  |fileid|absnext|next|previous


Off the top of my head, the very earliest versions of the Mac System software did use tags, but in a different way, and later they were totally discarded. Certainly they were gone by the first SCSI Macs, so either the 512KE or the Mac Plus era.

Since really only Lisa Office System (and by extension the Pascal Workshop) needs them, Apple got rid of them and support for them in Disk Copy 6 thinking nobody cared about Lisa anymore. Boy were they wrong! :-D

Let me see how things go with the email system, I'm almost done setting that up. I have one more task to implement before LisaList2 can send out emails, so I might be able to invest a day or two over a weekend writing some code to rebuild LOS tags before going back to the mailing list import project.
Title: Re: Workshop
Post by: D.Finni on March 04, 2019, 12:16:01 pm
Quote
I was wondering if it's an emulator bug... The resulting Macintosh application produced from the Workshop crashes when launched on the Macintosh. I opened MacsBug (the disassembler) and the assembly code isn't being generated correctly. There's some garbage, maybe a debugger label or something, that's getting inserted among the legitimate 68000 instructions.

Yeah, so the Lisa compiler, or perhaps linker will absolutely add the function/procedure name either before or after each function in a weird way, I think off the top of my head it takes the first byte and flips the high bit on, or something like that. I have code in LisaEm when debugging is enabled that looks for these and flags them so I know what's being executed and when. But the emitted code should ignore these and should branch/JSR/JMP around it.
I think that's what's going on. Maybe David Craig would recall what's going on.

Because I can see that there is correct code in the CODE resource, as I can see the various toolbox calls to initialize dialogs, menus, textedit, and so on. But there's extra stuff in between these calls that's being executed by the 68000 thus causing an Illegal Instruction error.


Quote
Or maybe you're using too new a version of the Mac System Software and it's setting up the CODE resource pointers incorrectly.
I don't think this is the case, as I'm using a Mac 512K and its system software from 1985.


Quote
The tags are well documented, the Lisa's File System isn't. I started to do that a long time ago, and @claunia finished the job. I have notes somewhere that I've been meaning to turn into a new version of the lisafsh-tool. Perhaps I should revisit that soon'ish.

If you run lisafsh-tool on a proper image with tags and walk through the sectors you'll see the tags and what they mean.

[...]
Thanks; this should be enough information to get me started.


Quote
Off the top of my head, the very earliest versions of the Mac System software did use tags, but in a different way, and later they were totally discarded. Certainly they were gone by the first SCSI Macs, so either the 512KE or the Mac Plus era.
Right. At first tags on the Mac were for file system recovery. I don't know if Apple released any disk utilities that could restore a damaged floppy from its tags, but I do know that FEdit sector editor by John Mitchell had support for tags.

And as you said, Apple later deprecated tags.

Quote
Let me see how things go with the email system, I'm almost done setting that up. I have one more task to implement before LisaList2 can send out emails, so I might be able to invest a day or two over a weekend writing some code to rebuild LOS tags before going back to the mailing list import project.
I'll see what I can come up with this weekend too. I'd started writing code to read a Lisa file system several months ago (probably before the summer) and I might revisit it in this time of need. ;-)
Title: Lisa Workshop Samp application disassembly
Post by: D.Finni on March 09, 2019, 02:41:06 pm
The following screenshot should be self-explanatory, except to say that the disassembly on the left is from my attempt at using Workshop to assemble "Samp," and the disassembly on the right is Samp as distributed by Apple.

The one on the left crashes with an illegal instruction error, the one on the right works A-OK.
Title: Re: Workshop
Post by: rayarachelian on March 09, 2019, 09:00:42 pm
Dumb request, but can you post the same thing, but this time in hex? Maybe, could you paste that in here as text rather than as an image so it can be fed to a disassembler, etc.?

They're obvious differences in the disassembly, but would help to see what text is in there in ASCII even with the high bits set.
I'm not saying I can fix it, but maybe something will become obvious beyond the disassembly.
Title: Re: Workshop
Post by: D.Finni on March 12, 2019, 12:42:41 pm
I encoded both the good and bad Samp applications with MacBinary and attached them to this post.

Searching for the hex string A8 6E A8 FE will put you more or less at the start of the main procedure code, the back-to-back traps to _InitGraf and _InitFonts, respectively.

Two more interesting observations:
1.) CODE resource 0, the jump table, is identical in both the good and bad Samp applications
2.) CODE resource 1, the main segment, is the same length, 986 bytes, in both Samp applications
Title: The Plot Thickens!
Post by: D.Finni on March 12, 2019, 05:37:24 pm
Aha! The plot thickens!

I tried using just the assembler. I wrote a little throw-away program that calls _SysBeep, then _ExitToShell. I assembled, linked, and the application runs A-OK on the Mac 512K. I get a beep, then I return to the Finder.

So now I'm thinking that the problem lies somewhere in the Linker. Maybe not the linker itself, but perhaps one of the Pascal libraries being linked in.
Title: Re: Workshop
Post by: D.Finni on March 12, 2019, 07:41:43 pm
One thing to note, I've seen bugs in LisaEm where the linker throws either a bus error or "Bad Intrin Instruction" error, it may be possible to use LPW in a limited fashion, but you'll likely run into this at some point. A real Lisa would help in your efforts - at least until I find a fix for it, or you could use IDLE.
Looks like Tom Stepleton discovered this problem too back in 2014 (https://groups.google.com/d/topic/lisalist/8uZSN_ZLVac/discussion) when trying to use the Workshop.
Title: Re: Workshop
Post by: rayarachelian on March 12, 2019, 09:55:21 pm
Yes, that's what I was pointing out it might be. It sometimes actually throws a bus error when the linker is invoked, other times it throws "Bad Intrin Patch Instruction" - and it's repeatable, it's not random, so re-executing the same link of the same object will cause the same result.
I don't know which opcode(s) are broken. It also breaks Tom's Mandlebrot application when zooming, and possibly is related to the scrollbar thumbs being wrong, and Desktop menu repeats. It's possibly a rotate opcode, but all the CPU tests I've done match a real 68040 off a NeXTstation turbo color.

So either I didn't find the right opcode, or perhaps the 68040 does something slightly differently from the 68000. Could be as simple as a status flag or an actual result difference, not sure. I've not been able to track down this elusive bug.
Tom and I thought it might be related to division opcodes, but that too proved fruitless.
I suppose I could port the test suite to say Xenix on a real Lisa, but I don't feel comfortable leaving the Lisa on for weeks at a time for it to go through millions of opcode tests like I did with the NeXT, I don't want to damage my Lisas, but if I could get a non-rare very common 68000, not 68010 or 68020, with a unix like OS and C compiler, I might try that and see if I can track it down. The NeXT slab was nice because they're fairly reliable and have ethernet so I could use NFS as the file system for storing the results of the tests to, and could telnet into it and watch it run, etc.
I suppose an old MacPlus might do, or an Amiga 500, but these too are really old and I wouldn't want to damage them either, not that I own either of those machines.

There's some old details about the CPU testing here: https://lisa.sunder.net/cputest.html (https://lisa.sunder.net/cputest.html)
Title: Re: Workshop
Post by: D.Finni on March 12, 2019, 10:50:27 pm
There's some old details about the CPU testing here: https://lisa.sunder.net/cputest.html (https://lisa.sunder.net/cputest.html)
I read that whole page.

You said,
Quote
The idea is to get the CPU core compiled on a m68k, then execute a single opcode with the three inputs (two register values + the CCR) on both the native 68k chip, and the Generator function, then compare the results in the output register and the CCR.  If there's any difference, complain, then change the input values and try again, etc...  :)

I don't see why you need to have the CPU core compiled and running on the 68K machine. Isn't it enough just to test all the CPU instructions on the real 68000 CPU, store the results, then run your emulated 68K CPU on whichever computer, and compare the stored results?


So either I didn't find the right opcode, or perhaps the 68040 does something slightly differently from the 68000. Could be as simple as a status flag or an actual result difference, not sure.
I don't see how this could possibly be justified. The internal implementation of the 68000 instructions may differ, but how could the results differ and still offer 68K family compatibility? I had a Macintosh Quadra with a 68040 CPU and it could run old Mac software written for the 68000 just fine.
Title: Re: Workshop
Post by: rayarachelian on March 13, 2019, 10:57:04 am
Quote
I don't see why you need to have the CPU core compiled and running on the 68K machine. Isn't it enough just to test all the CPU instructions on the real 68000 CPU, store the results, then run your emulated 68K CPU on whichever computer, and compare the stored results?

Initially I thought to run just tests on the NeXT itself vs the Generator core. However, later I realized what I was actually after were the results of the 68040 itself and recorded the outputs as those are more useful. For example an emulated 68000 running on a 68000 would likely return results consistent with native code on the 68040 and would likely not differ. However the Generator core running on a SPARC, Alpha, x86_32/64, ARM, PowerPC, etc. might differ, so while that page says what it says, I did pivot to just capture the results and test externally.

Quote
I don't see how this could possibly be justified. The internal implementation of the 68000 instructions may differ, but how could the results differ and still offer 68K family compatibility? I had a Macintosh Quadra with a 68040 CPU and it could run old Mac software written for the 68000 just fine.

Weird edge cases can happen between CPU cores of the same family. Intel is much worse than Motorola, but the fact is we don't know for sure. This is a contrived example, but the bus error exceptions on the 68000 differ quite a bit from a 68010 and a 68020 and 030 and 040 and the differences are handled in the system software itself. Also for example NOP has no effect other than to eat cycles and move the PC forward on a 68000. On a 68040 it has a cache flush operation. On the 68000 you can write self-modifying code, on the 68040 because of the CPU cache, you cannot and should force the instruction cache to flush, etc.


For example https://www.revolvy.com/page/Motorola-68010 (https://www.revolvy.com/page/Motorola-68010) mentions:
Quote
The 68010 was pin-compatible with the 68000, but was not 100% software compatible. Some of the differences were:
  • The MOVE from SR instruction is now privileged (it may only be executed in supervisor mode). This means that the 68010 meets Popek and Goldberg virtualization requirements (https://www.revolvy.com/page/Popek-and-Goldberg-virtualization-requirements). Because the 68000 offers an unprivileged MOVE from SR, it does not meet them
  • The MOVE from CCR instruction was added to partially compensate for the removal of the user-mode MOVE from SR.

There were a number of bugs that I found in the BCD math modes of Generator, it's possible some of those were behaving actually correct Generator for the 68000, but when tested on the 68040 were marked as errors.

There are other weird edge cases to consider are for example, what happens if you do i<<33 or i>>33 where i is a byte, signed byte, word, signed word, long, or signed long? That actually produces different results on x86, SPARC, ARM than it does on m68k, and possibly will vary across different compilers too.
I'm not claiming the above are the exact cause for the linker emulation issues, but rather that I suspect it might be the case here. If I knew for sure, I'd be able to address the issue. and it might not even be something obvious. It could be any number of things that weren't tested, or were tested and passed, or some weird bug between two opcodes that exists only in certain cases, but not others. (Generator uses an instruction parameter cache as an optimization, I have seen certain issues with this before, which I've fixed in 1.2.7, but it did not resolve the linker/scrollbars/Desktop menu bugs.)

Title: Re: Workshop
Post by: D.Finni on March 13, 2019, 03:39:32 pm
The tags are well documented, the Lisa's File System isn't. I started to do that a long time ago, and @claunia finished the job. I have notes somewhere that I've been meaning to turn into a new version of the lisafsh-tool. Perhaps I should revisit that soon'ish.
I see in the Lisa Operating System 3.0 Reference Manual, page 2-3, text describing "Page descriptors" which are stored within each page (block) on disk. It says there are 8 components of the page descriptor, and then it lists them.

Is the page descriptor the 12 tag bytes for each block?
Title: Re: Workshop
Post by: 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:
   (the above are 6 colour Apple labels, with text printed by a dot matrix printer)
My post-it note on the box suggests there was a disk 2, as well as "MacStuff 1" through 4, which rings a bell as being utilities etc. on Mac formatted disks, MacWorks 1.0 and MacWorks with LisaBug.

Set 2:
  through #6

These have 2" x ?" die-cut office labels made on a DMP and cut about 2.75" wide.
Three are re-used disks with similar style labels underneath (I'm confident they arrived that way) reading:


Set 3:

   through #3
   through #2
(A couple of these are re-used disks with labels stuck over others; I'm confident they also arrived that way)


Let me know if images of any of these disks are a priority and I'll try to assist. 
 
<  < 
:P

Page 6 of
http://bitsavers.org/pdf/apple/lisa/workshop_3.0/Lisa_Workshop_Supplement_Ver_1.0_1986.pdf (http://bitsavers.org/pdf/apple/lisa/workshop_3.0/Lisa_Workshop_Supplement_Ver_1.0_1986.pdf)
shows the last draft of the technical document is 5/5/85.

I don't recall if there was an annual subscription for these or if one paid for each supplement when it was announced, but I believe the 5/85 version was the last of the Supplement versions available/distributed in general. After that, public distributions were made available through APDA. I don't know when the Apple Developer Program started in earnest; IIRC, I was not a participant until 1989 or so.


I have an article on Lisa Workshop Pascal for Macintosh Development (https://macgui.com/news/article.php?t=477) and I'm missing the latest Workshop Supplement '86 disks that should have the latest libraries and interfaces for Macintosh Plus.
...
Anyone have these last Supplement '86 disks?
Title: Re: Workshop
Post by: D.Finni on March 14, 2019, 04:57:44 pm
I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:

Set 1:
I think the disks in Set 1, from 1984, would be worth a shot.
Title: Re: Workshop
Post by: sigma7 on March 14, 2019, 09:37:21 pm
My scanned floppies database says I scanned these disks in 2001 (with corresponding filenames shown), so they should be trivial to provide once I find the drive with the image files on them:

Mac Supplement , 5/85 Mac Build Disk                          1884.img
Mac Supplement, 5/85 MacStuff 4                              1885.img
Mac Supplement , 5/85 MacStuff 3                              1886.img
Mac Supplement , 5/85 MacStuff 2                              1887.img
Mac Supplement, 5/85 MacStuff 1                              1888.img
Mac Supplement, 5/85 Examples 2                              1889.img
Mac Supplement , 5/85 Examples 1                              1890.img

Mac Supplement, Feb 85 MacBuild                              1891.img
Mac Supplement , Feb 85 MacStuff 4                            1892.img
Mac Supplement , Feb 85 MacStuff 3                            1893.img
Mac Supplement , Feb 85 MacStuff 5 , Bad Blocks track 78/77    1894.img
Mac Supplement , Feb 85 MacStuff 1                            1895.img
Mac Supplement , Feb 85 MacStuff 2                            1896.img

Mac Supplement, Nov 84 MacStuff 4                            1897.img
Mac Supplement, MacStuff 3                                   1898.img
Mac Supplement, MacStuff 2                                   1899.img
Mac Supplement, MacStuff 1                                   1900.img


I suspect these are all in Mac format.
My estimate is that the last 4 are from the Nov '84 set.

BTW, I've now found (condition unknown):

From Set 1:
MacSupplement 2, Workshop 2.0, LisaDisk.
MacWorks, LisaDisk
MacWorks with, LisaBug, LisaDisk

From Set 2:
MacWorks, LISA Disk, February '85
- with my handwriting "XL 2.0"

Edit:
Formatting fix as Preview wasn't working  :-\

Edit2:
Found more floppies
Title: Re: Workshop
Post by: sigma7 on March 15, 2019, 06:38:30 pm
All the disks scanned fine, so AFAICT, this 7MB archive contains all of the Mac Supplement disks that I ever received:

drive.google.com/file/d/1JbWRuPRUThtsSQPC5uZ1SEOlTcG9U0wR/view?usp=sharing

Title: Re: Workshop
Post by: 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 (https://developer.apple.com/library/archive/samplecode/MFSLives/Introduction/Intro.html#//apple_ref/doc/uid/DTS10004026), 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...
Title: Re: Workshop
Post by: 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.
Title: Re: Workshop
Post by: D.Finni on March 17, 2019, 02:12:02 am
Yeah, I'm doing the same thing, and will add to lisafsh-tool as well as create a tool to rebuild the tags.
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
Title: Re: Workshop
Post by: claunia on March 17, 2019, 05:34:21 am
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)
Title: Re: Workshop
Post by: claunia on March 17, 2019, 05:36:30 am
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 (https://developer.apple.com/library/archive/samplecode/MFSLives/Introduction/Intro.html#//apple_ref/doc/uid/DTS10004026), 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...

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.
Title: Tried the 1984 Workshop 2.0 disks, no joy
Post by: D.Finni on March 18, 2019, 01:13:39 am
I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:

Set 1:
I think the disks in Set 1, from 1984, would be worth a shot.
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.
Title: Re: Workshop
Post by: rayarachelian on March 18, 2019, 06:54:12 pm
 ??? 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.