Anyone have a DC42 image of Lisa COBOL

[Gorgonops]

That was the point of MacWorks.

Not really, or at least it doesn't accomplish what I was saying. MacWorks just turns a Lisa into a big clunky Macintosh, essentially lobotomizing whatever technical advantages the Lisa had relative to the Mac right out of it. In an ideal world the "family" approach would have been something like "On the Mac you can run one program at a time and use the clipboard to paste between them, while on its big sister Lisa you can run MacPaint and MacWrite at the same time and switch between them, while using MacTerminal in the background to transfer files to the main office! ...". IE, have real binary/file compatibility between their *native* OSes from day one.

To be frank, MacWorks only exists because A: abandoning the Lisa entirely in 1985 would have been highly politically incorrect and B: it was a quick hack to get a hard disk equipped Mac into people's hands.

...if it couldn't place a copy of the Mac ROM at the exact memory address where the software expected to find it. Luckily, it had an MMU to do the address translation  :lisa2:

Broadly speaking the only really hard requirements for a 68000 system to emulate a Mac is that it have the first 32k of the memory map be available RAM for the low memory globals and that it be equipped with a bitmapped display that uses a linear memory map. (Remember, machines like the Atari ST and Amiga also met these requirements and therefore could emulate one with essentially zero hardware.) The way the Mac handles function calls to the ROM indirectly with traps means you can shuffle around and patch the ROM to pretty much anywhere in RAM as long as it's above the top of the application heap. (The jump tables point to where ROM really lives with a global variable called "ROMBase".)

That said, I have no idea if Macworks on the Lisa/MacXL uses the MMU to map the ROM contents to the same 4MB boundary that it's at in the 128k/512k/Plus/SE/Classic or not. Just saying it wouldn't necessarily have to.

 

[Dog Cow]

Of course, the Lisa could not have emulated a Mac so easily...

...if it couldn't place a copy of the Mac ROM at the exact memory address where the software expected to find it. Luckily, it had an MMU to do the address translation  :lisa2:

The ROM and Finder both had to be patched for MacWorks. Read the article in ST.Mac May 1984, pp. 32-33.

 

[stepleton]

Shows what I know. Got a link?

 

[Dog Cow]

Not really, or at least it doesn't accomplish what I was saying. MacWorks just turns a Lisa into a big clunky Macintosh, essentially lobotomizing whatever technical advantages the Lisa had relative to the Mac right out of it.

 When you ran MacWorks on the Lisa 2 you got access to a hard disk, 512K, 1 MB, or even 2 MB of RAM.  Also slots. This was before the Fat Mac was available. I wouldn't call that lobotomizing the technical advantages of the Lisa.

That said, I have no idea if Macworks on the Lisa/MacXL uses the MMU to map the ROM contents to the same 4MB boundary that it's at in the 128k/512k/Plus/SE/Classic or not. Just saying it wouldn't necessarily have to.

Read the MacWorks article in ST.Mac.

 

[stepleton]

And hey, at least I can now cite the "source" that led me to believe the wrong thing

Here is a Wikipedia page that I swear I did not write: https://en.wikipedia.org/wiki/MacWorks_Plus

 

[Dog Cow]

The article describing MacWorks was actually in ST.Mac, May 1984, pp. 32-33. It says Jeff Parrish modified the Mac ROM and Finder to run on Lisa hardware.

 

[stepleton]

Thanks for the citation! Here's a scanned PDF online:

http://yesterbits.com/media/pubs/STMac/st.mac-1984-may-300dpi.pdf

Reading it, I'm not too sure what's going on...

First, Parrish needed to take the contents of the copyrighted Macintosh ROM, containing the heart and soul of Macintosh, and have MacWorks load them into a segment of Lisa's RAM memory. Then he had to make the Macintosh Finder—which comes with all Macintosh applications—believe that it was where it was supposed to be.

Next, Parrish had to implement the "ROM patches" that were being made to reflect last-minute changes to the Macintosh ROM code. THese needed to be made taking into account the environment of the Lisa, as well as the Macintosh Finder, which was still undergoing last-minute changes by the Macintosh software team.

And third, the hardware-specific low-level software (serial drivers, for example) had to be written to provide the appropriate I/O and the like for Macintosh programs when talking to the Lisa hardware.

But it looks like we can actually find out conclusively. Over in http://bitsavers.informatik.uni-stuttgart.de/bits/Apple/Lisa/macworks/, there are files with names like "MACWORKS SOURCES 1.IMAGE". A peek in there would let us know exactly what the tricks were.

But that's a project for another evening  :lisa2:

 

[Gorgonops]

 When you ran MacWorks on the Lisa 2 you got access to a hard disk, 512K, 1 MB, or even 2 MB of RAM.  Also slots. This was before the Fat Mac was available. I wouldn't call that lobotomizing the technical advantages of the Lisa.

It's throwing away everything about the *Lisa OS* that was (theoretically) worthwhile, IE, memory protection, object-oriented document model, multitasking (remember, the Mac didn't have the "Multifinder" for quite a while, and it took some really ugly hacks to make it work at all), etc. So, yes, sounds like something of a lobotomy.

Of course, the counter-argument is that because Apple failed so hard on making any additional native LOS software available (and there's also the issue of the Lisa Office System itself being notoriously "crashy" despite the "advanced features) it was worth "taking the hit". And it's sort of a valid one. But the fact remains that essentially what Apple did here is convert their Lisa customers into Mac customers. The Lisa died in the process, leaving an ambling zombified corpse. (That, sure, still happened to be more capable than the best "real Mac" Apple had for sale until the Plus came out. At that point Apple offered their trade-in program that took a lot of Lisa's out of circulation and officially nailed the coffin shut.)
 

Read the MacWorks article in ST.Mac.

That article is so non-technical it's really not of much help. It doesn't explicitly say, for instance, what address they mapped the ROM to. The statement "Then he had to make the Macintosh Finder... believe that was where it was supposed to be" *could* be a clue that it does reside at a different place in the memory map than it does in a 128k/512k (in which case the changes would involve updating ROMBase, modifying the trap table, etc), but it's by no means definitive. There's plenty of other stuff that has to be patched and shuffled around, maybe he's referring to something else. The video memory is a different size and located in a different location, for instance, (if you read "Inside Macintosh" you'll find that the ROM designers allowed for that possibility by having the base, length, and layout of the memory buffer stored in a global that Quickdraw is supposed to honor when drawing the screen) and the ROM would need to be patched so it'd initialize it correctly. The low-level hardware drivers would also need to be patched; again, the ROM designers took that into consideration by "modularizing" them so they could be replaced piecemeal either in situ or overridden by new versions loaded into RAM... etc. Maybe early versions of the Finder "broke the rules" and banged on some piece of hardware directly instead of making a toolbox call that would be fixed by just updating the globals. Again, without more information than is in that article we can't use it as ammunition to argue that Macworks "must have" configured the MMU in some particular way, et al.

 

[Gorgonops]

And hey, at least I can now cite the "source" that led me to believe the wrong thing

Here is a Wikipedia page that I swear I did not write: https://en.wikipedia.org/wiki/MacWorks_Plus

Hah! That's Wikipedia for you, I guess.

What they're describing in there does sound well beyond the talents of the Lisa's MMU. As I noted, the shape and size of the Lisa's display buffer is different, sound hardware's completely different, serial ports are substantially different, etc. The MMU could *help* by locating the source ROM at 0x40000 (just in case there's any code in it that uses non-relative references to other locations in ROM, if there aren't any it doesn't buy that much) but it's still going to be all about patching.

The only thing I *might* throw out there is maybe it's possible they set up the MMU so access to certain pages occupied by hardware that "naughty" programmers might like poking manually in the Plus throws a page fault, and they created a handler that would intercept the faults and try to emulate what an access to that area would do on the real hardware? There was a technique that was used by certain rotgut PC clones that had, for instance, semi-incompatible video implementations, where instead of making a register-compatible implementation of a hardware device they'd put a little stub in the memory map that would generate a non-maskable interrupt, upon which the system would jump to a ROM handler that would look at the registers and try to emulate what that access would have done. *If* they abused the Lisa's MMU to do something like that I heartily congratulate them on their deviousness.

 

[Dog Cow]

But it looks like we can actually find out conclusively. Over in http://bitsavers.informatik.uni-stuttgart.de/bits/Apple/Lisa/macworks/, there are files with names like "MACWORKS SOURCES 1.IMAGE". A peek in there would let us know exactly what the tricks were.

Ah, thanks for bringing those up! I extracted some of the ASCII source files a couple weeks ago and was looking through them, but I forgot about it until now. The source for the trap dispatcher is in there.

Gorgonops, I agree that article is missing some details. There's no mention of MMU. But it offers some clues to start from.