General Category > LisaList2
A 68010 in a Lisa?
jamesdenton:
Ever wonder what happens when you install a Motorola 68010 in a Lisa?
Well, it doesn't blow up.
In my 2/10 (1 MB), you might be greeted by Error 42 (Video Circuit Error):
Upon booting UniPlus UNIX, you'll be told the Serial # cannot be found (likely related to video error):
When booting GEM, you'll get the fish, then the screen goes white and you get Error 75 (Corrupt System Files):
Xenix looks promising, but after you attempt to load the kernel you'll get some screen artifacts:
MacWorks XL 3.0 led me on and dumped a Sad Mac on me (0F000A - Line 1111 Exception?)
Which sorta resembles this other Xenix error I got (playing with parallel vs onboard HD):
BLU hung in there until the end:
Wait, what is that...?
Tom's Mandlebrot plotter is working!
Any attempt to boot Workshop or Lisa Office diskettes simply resulted in Error 75, or an unexpected reset. MacWorks 1.1h reported Error 47 (Unexpected exception).
I might kick around some 3A ROMs and see if MacWorks behaves.
Anyway, enough fun for one night.
stepleton:
Really interesting experiment! I've always wondered...
I guess I'm not really using much Lisa-specific code for the "bare metal" Mandelbrot plotter. I wonder if the 68010 does it any faster than the 68000 does...
--Tom
jamesdenton:
That was the first time I'd run it, so I'm not sure. I didn't time it, but I'm pretty sure it was at least fifteen minutes, probably longer.
Burning some 3A ROMs now and will give 'em a go later on.
jamesdenton:
--- Quote from: jamesdenton on July 16, 2019, 08:16:13 am ---Burning some 3A ROMs now and will give 'em a go later on.
--- End quote ---
I didn't burn a matching video ROM, but was able to see through the garbled video that MacWorks reported a Sad Mac, too.
On the bright side, I didn't get an Error 42 this time.
rayarachelian:
So beyond the obvious speed differences, which are likely causing the serial # misread since some opcodes run faster now, the 68010 may have a slightly different exception frame.
At least keep in mind that bus and address errors are somewhat restartable with certain opcodes on the 68000, but are likely different on the 68010, which means for each of those OSs you'd need to modify their kernel and MMU handling code; also now MOVE SR,<EA> is a supervisor only opcode. The 010 does have a bit of a cache as well which is likely going to affect timing - I don't believe LOS or MW used self-modifying code, so likely the cache won't be an issue there, but for sure, the serial # reading is going to be affected as that's a very tight, timing dependent loop.
You might have better luck with the 68008, but off the topof my head the 008 has slightly different pins so you might need to build a two-DIP socket and change the order around a bit (though this is from wetware, so I might be way wrong.)
Note that both MacWorks and Xenix are both crashing with F-line errors (1111 is F ) in your screenshots- Motorola reserved all the 0xfxxxxxxx opcodes for itself, which it uses for things like the PMMU and the FPU, with some chips these are external, with others, such as the 68040 are internal. (The A-line traps are available for use by operating systems, and Apple uses them in LOS.)
See: http://www.retronik.fr/motorola/68K/68000/M68000_ProgrammerReferenceManual_[Motorola_1992_646p].pdf
PDF pages: 20, 608-612, 628-630.633 (fig B9 on PDF page 633 shows the '10 exception frame is 18 words long vs fig B2 on page 630 which shows 7 words for the '00)
So you're going to have some very low level OS hacking to do in order to get it to work.
Navigation
[0] Message Index
[#] Next page
Go to full version