Print

[D.Finni]

I have an article on Lisa Workshop Pascal for Macintosh Development 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?

[rayarachelian]

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.  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 , which might or might not help.

[D.Finni]

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.

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.

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.

I do see that bitsavers has Workshop Supplement 85 and not 86 here , 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.

[rayarachelian]

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.

[D.Finni]

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.

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.

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.

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.

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. ;-)

[D.Finni]

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.

[rayarachelian]

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.

[D.Finni]

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

[D.Finni]

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.

[D.Finni]

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 when trying to use the Workshop.

[rayarachelian]

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

[D.Finni]

There's some old details about the CPU testing here: https://lisa.sunder.net/cputest.html

I read that whole page.

You said,

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.

[rayarachelian]

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.

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 mentions:

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. 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.)

[D.Finni]

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?

[sigma7]

I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:
Set 1:

• MacSupplement 1, Workshop 2.0, LisaDisk
• MacSupplement 3, Workshop 2.0, LisaDisk
• MacSupplement 4, Workshop 2.0, LisaDisk
• MacSupplement 5, Workshop 2.0, LisaDisk
• IMAGEWRITER 8/1/84, Pre-release, Workshop 2.0, LisaDisk

   (the above are 6 colour Apple labels, with text printed by a dot matrix printer)

• MacSupplement (6), Nov-84, Lisa WorkShop Disk
• MacSupplement (7), Nov-84, Lisa WorkShop Disk

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:

• MacSupplement #1, Lisa Workshop Disk, February '85

  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:

• Mac <illegible>, (NON-BOOTABLE), Mac <illegible>, December - 84
• MacSupplement #6, Lisa Workshop Disk, December 84
• MacWorks, Lisa startup Disk, December 84

Set 3:

• 5/85 Workshop Supplement 1, Lisa Workshop Format, (c) May 1985, Apple Computer, Inc.

   through #3

• 5/85 Workshop 3.9 Update 1, Must be used from, Lisa Workshop 3.0, (c) May 1985, Apple Computer, Inc.

   through #2

• MacWorks XL 3.0,  (c) May 1985, Apple Computer, Inc.

(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.

<  <

Page 6 of
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 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?