Very cool article!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.
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.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.
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.
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.
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.
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.
I think that's what's going on. Maybe David Craig would recall what's going on.QuoteI 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.
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.
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.Thanks; this should be enough information to get me started.
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.
[...]
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.
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. ;-)
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.
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.
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... :)
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.
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?
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.
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.
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.
Let me know if images of any of these disks are a priority and I'll try to assist. | < < | :P |
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?
I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:I think the disks in Set 1, from 1984, would be worth a shot.
Set 1:
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:
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...
I tried the 1984 Workshop 2.0 Supplement Disks, and the short story is: no joy; the application still crashes on the Mac 512K.I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:I think the disks in Set 1, from 1984, would be worth a shot.
Set 1: