• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Why Lisa didn't use 8MHz 68000?

Gorgonops

Moderator
Staff member
Wow, the proposal actually exists. It's kind of amusing, re: the discussion about page faults in the other thread, that item #1 on the "Additions and Enhancements" list is:

The 68010 has been chosen because it supports instruction restart and fast move loops.

Anyway... Skimming through this the details of the "CPU board" are fascinating. The "video" section of it has a full 128K of RAM (48k of which are used for a single frame buffer), and that new sound generation hardware that leeches off the video cycles (just like the Mac) is integrated with it. Honestly, this architecture pretty much reads like they plopped, in whole, a juiced-up revision of the "little Mac" on top of the Lisa-related bits, with the major difference being that they sped everything up and gave the CPU a fast bus channel where other "stuff" can be hung without being strictly gated by video access timings. This impression is further reinforced by the fact that the CPU board also contains the the IWM, now directly driven, the same serial ports... etc.

(Even more telling, the docs seem to imply that initialization code and "stuff" that has reasons to bypass the MMU can also run directly from the video RAM allocation.)

I guess to put it another way, if we were going to use "Amiga-centric" language to describe this thing it basically comes across as the CPU board essentially being the "Chip RAM" portion of the design, and the "Whopper MMU" is tending the "Fast RAM".
 

sunder

Well-known member
Hi Tom, sadly no Lisa 3, a color Lisa, or the Whopper made it past a thought exercise phase, so it's all speculation at this point.

You are correct, technically you can point the video buffer on a Lisa anywhere within the physical 2MB RAM space, outside of the MMU. So it's not just two screens, but you could do up to 2MB/32KB or 64 screens (though most Lisas were limited to 1MB or 1.5MB, and a handful to just 512KB.)

Certainly if you did dedicated RAM for a frame buffer, then you're limited to whatever RAM you have available for that, so if it's just 64KB, it would be 2 screens max. It's true that the alternate screen was used by LisaBug, but it's not actually limited to just two (for those who aren't familiar with the Lisa's HW design.)

I'm not saying that the Lisa was beholden to Apple ][ ways of doing things either, but rather, "here's a quick hack, we can copy what the Apple ][ does for floppy access by creating a tiny dedicated Apple ][ inside the Lisa, and boom, we're done, we can ship it." I feel that was a wasteful way of doing things, but yeah, it did help it ship on time for sure, but at a much higher cost and complexity.

Sigh... I really wish there was a Whopper, or Lisa 3, or color Lisa. alternate universe/timelines and all that, it would have been amazeballz. :) And ofc, would have been nice if it had digital sound in/out too, and ethernet, and so on...
 

lisa2

Well-known member
I seems to me that when folks learn that the Lisa was clocked at 5Mhz vs. the Macintosh at 8Mhz it gives the impression that the experience of using a Lisa is almost 40% slower than using a Macintosh. This is not helped by reports that using the Lisa Office apps are dog slow.

My experience in using both the Lisa and Macintosh side-by-side does not support this. The Lisa may be clocked at lower speed, but it certainly does not "feel" almost 40% slower in use. I ran a benchmark application on the Lisa ( Speedometer 2.0 ), and it rates the Lisa at .73 the CPU rating of a Macintosh SE. This benchmark shows that there is more going here than raw clock speed. Compared to a floppy only Macintosh 128K or Fat Mac the Lisa with her 1 Meg of RAM and hard disk is very useable and on-par or better than the experince on an early Macintosh.

Rick
 

sunder

Well-known member
I mean, I wouldn't really use a Lisa to run Mac software anymore* so it's, uh, like comparing apples to oranges, if you'll excuse the pun. MacWorks may well be far more efficient at running a single application vs multiple ones.

However, I'd also point out that most of the time, all computers are unused. They sit there idling. The only time it feels slow is when it's booting, installing LOS, formatting a Widget/ProFile, or doing some intensive disk, or CPU operation. Scrolling on a Lisa with LOS is pretty snappy - well it depends on what had to be refreshed with QuickDraw and how complex that was... So context here is the always key.

If you're doing nothing and just wiggling the mouse, it's very responsive on a MacWorks as well as LOS. If you're swapping to disk, or fully recalculating a huge spreadsheet, well, that's going to be a lot slower. (And MacOS of that era did not do virtual memory.) Certainly copying lots of things off floppy is going to be a lot slower than from ProFile to ProFile.

I don't know if LOS does file system caching if there's free RAM around like modern Linux/BSD does, certainly there's no RAM disk, but if it did that would increase the speed of the machine. Certainly some of the disk structure is cached in RAM from the behavior I saw when working on LisaEm and disassembling parts of LOS. (And to be honest, I don't really know if classic MacOS does disk caching and how effective it is, I'm sure it's not as good as modern day Linux/BSD.)

So benchmarks might not be all that useful as using real apps when saying that the Lisa is slow or not vs newer Macs. I suppose if you fire up MacDraw and LisaDraw and use both, that would be a better benchmark to see which is faster.

* well that's a kind of lie as I do have one Lisa dedicated to just MacWorks, but for other reasons than running classic macos, in real life I just use mini-vMac for that kinda thing, and also 99% of the time use LisaEm than a real Lisa anyway and can throttle up the speed, and also the whole thing pretty much lives in RAM, including floppy and ProFile images due to our friend mmap(). Pretty much the only time I turn on real hardware these days is to repair it or test things that don't work on a real Lisa to figure out behavior. Even when the throttle is at 5MHz, it's a lot faster than a real Lisa due to most of it being in RAM (and certainly the High Level Emulation of disk access removes a lot of the transfer waits due to the protocols used.)

If anything the HQ3X video renderer with scaling is more CPU intensive than the 68000 emulation on this Linux laptop.
 

sunder

Well-known member
Lisa was never designed to use the 68010, this was just a (somewhat) recent experiment done by James Denton to see if it's possible.

A 68010 would have had better MMU support and have been faster, however, there are some very specific timing dependent bits of code, such as reading of the serial number hidden in the VSROM which break with a 68010, but work with a 68000.
 

yuhong

Well-known member
Lisa was never designed to use the 68010, this was just a (somewhat) recent experiment done by James Denton to see if it's possible.

A 68010 would have had better MMU support and have been faster, however, there are some very specific timing dependent bits of code, such as reading of the serial number hidden in the VSROM which break with a 68010, but work with a 68000.
It would have greatly simplified the Lisa OS.
 

stepleton

Well-known member
It would have greatly simplified the Lisa OS.
Would it? The Lisa OS has a lot of complexity: overdesigned filesystem, multiple forms of IPC, hardware abstraction of various kinds, built-in DRM and password protection, and dynamically-loaded shared libraries, among other things, but few of those seem attributable to the type of MMU. Aside from the extra TST.W instruction you use occasionally to proactively provoke a page fault, why would the 010+the Motorola MMU be much more simple than the 000+the Lisa's own MMU?

It's virtually certain that the Motorola MMU has some capabilities that the Lisa's homebrew MMU lacks, but does the Lisa OS miss out for not being able to use those?
 

yuhong

Well-known member
Would it? The Lisa OS has a lot of complexity: overdesigned filesystem, multiple forms of IPC, hardware abstraction of various kinds, built-in DRM and password protection, and dynamically-loaded shared libraries, among other things, but few of those seem attributable to the type of MMU. Aside from the extra TST.W instruction you use occasionally to proactively provoke a page fault, why would the 010+the Motorola MMU be much more simple than the 000+the Lisa's own MMU?

It's virtually certain that the Motorola MMU has some capabilities that the Lisa's homebrew MMU lacks, but does the Lisa OS miss out for not being able to use those?
The 68010 did not include an MMU and I am not talking about changing the MMU. I am talking about the new support for handling bus errors for example where you can just RTE.
 
Last edited:

yuhong

Well-known member
That being said I do wonder how the MC68451 compared to Lisa's segmented MMU. But AFAIK the 68451 dates before the 68010, right?
 

stepleton

Well-known member
That being said I do wonder how the MC68451 compared to Lisa's segmented MMU. But AFAIK the 68451 dates before the 68010, right?
Yes, I think this is what I was assuming you meant --- having an '010, which was not too different from the '000 speed-wise, gave you the option to use its contemporary MMU, which would have saved Apple a lot of trouble on the hardware side but maybenot the software side, I wouldn't have thought. I hadn't thought about the difficulty of recovering from a bus error, but I imagine that this is probably something whose implementation (if complicated) might not be replicated too widely?
 

yuhong

Well-known member
Yes, I think this is what I was assuming you meant --- having an '010, which was not too different from the '000 speed-wise, gave you the option to use its contemporary MMU, which would have saved Apple a lot of trouble on the hardware side but maybenot the software side, I wouldn't have thought. I hadn't thought about the difficulty of recovering from a bus error, but I imagine that this is probably something whose implementation (if complicated) might not be replicated too widely?
The bus error changes are the entire point of the 68010.
 

stepleton

Well-known member
The bus error changes are the entire point of the 68010.
I think we might be agreeing here but thinking about it differently. If I understand correctly, you're thinking about the extra information that the 68010 saves that makes RTE useful for all instructions after a bus error. I'm thinking about the limited set of instructions for which RTE and the error mechanism as implemented on the 68000 supports a viable recovery, of which TST.W is Apple's empirically-selected recommendation.

Either way, the amount of complexity in the Lisa OS seems to me like it must be about the same: if a fault, deal with it, RTE. With the '000, well-behaved programs should have caused the error with TST.W. With the '010, they can cause it with other instructions too. But that difference is in the program, not the OS.

The complexity might be different, though, if the '010 opens up a simpler version of "deal with it" thanks to its ability to make best use of the 68451, which might be an easier MMU for an OS to use than Lisa's own. On this score I have no idea --- I've never dealt with a proper Motorola MMU, and for the Lisa's I'm very happy to use the flat addressing established on startup by the boot ROM.
 

yuhong

Well-known member
I think we might be agreeing here but thinking about it differently. If I understand correctly, you're thinking about the extra information that the 68010 saves that makes RTE useful for all instructions after a bus error. I'm thinking about the limited set of instructions for which RTE and the error mechanism as implemented on the 68000 supports a viable recovery, of which TST.W is Apple's empirically-selected recommendation.

Either way, the amount of complexity in the Lisa OS seems to me like it must be about the same: if a fault, deal with it, RTE. With the '000, well-behaved programs should have caused the error with TST.W. With the '010, they can cause it with other instructions too. But that difference is in the program, not the OS.
I don't think this is how bus errors work on the 68000. You can't directly RTE from a bus error on the 68000. Remember that every intersegment call on the Lisa triggers a bus error and I believe often used special code sequences..
 
Last edited:

yuhong

Well-known member
As a side note, the proposal suggest raising the clock speed of the 68010 to 10Mhz. Given that the speed of 68010 tends to lag behind a 68000 anyway...
 

yuhong

Well-known member
Just looked at "MC68000 Group 1 and 2 Exception Stack Frame" and "MC68000 Bus or Address Error Exception Stack Frame" and the two are completely different, requiring a tons of code in the Lisa bus error handler.
 

Melkhior

Well-known member
The bus error changes are the entire point of the 68010.
Indeed, and that why every workstation vendors used the 68010 rather than the 68000, as otherwise they needed horrible kludge to get paging support in their OS. The two-68000 design from Apollo was probably the most spectacularly over-engineered system ever: the first 68000 did everything but page fault handling, the second 68000 only handled page faults...
 

stepleton

Well-known member
requiring a tons of code in the Lisa bus error handler.
I'm glad you've looked it up, but I still don't think that even cutting the bus error handler's code size by, say, 5/6ths "would have greatly simplified the Lisa OS". My bet is that it's a drop in the ocean by just about any meaningful metric: overall code size, developer-hours, cost to write, perhaps even speed and user experience. The last one is probably the most interesting metric, though.
 

stepleton

Well-known member
I decided to look it up too. My references are these two:
http://www.bitsavers.org/components/motorola/68000/MC68000_16-Bit_Microprocessor_Apr83.pdf chapter 5

The latter I didn't read too closely --- I just referenced it for the pictures. This one in particular is relevant:

1667850686349.png

You are correct that these stack frames have different shapes. There's another problem, too: the first reference says that the value of the stored program counter may differ depending on the specific instruction that caused the bus error.

It sounds to me though that this could be another reason why Apple wanted you to write your programs so that you only triggered bus errors with certain instructions: specifically TST.W with indirect addressing. See "6.6.1 The Run-Time Stack" on PDF page 110 of
Quoting:
To ensure that the stack segment is large enough before the procedure is entered, the Compiler emits code to 'touch' the lowest point that will be needed by the procedure. If we 'touch' an illegal location (outside the current stack bounds), the memory management hardware signals a bus error that causes the 68000 to generate a hardware exception and pass control to an exception handler. See the Lisa Hardware Manual for more information on the memory management hardware. This code, provided by the operating system, must be able to restore the state of the world at the time of the exception, and then allocate enough extra memory to the stack that the original instruction can be reexecuted without problem. To be able to back up, the instruction that caused the exception must not change the registers, so a TST.W instruction with indirect addressing is used.

Apple references not touching the registers here, but by restricting the number of valid ways that a program can cause a bus error, they may also have made the stored program counter behaviour more predictable.

(I assume there were similar precautions in place for the heap, but this would have happened in Apple's code (i.e. in routines that are equivalent to malloc), so no need to tell the programmer about them.)

I've never written the bus error handler for an OS before, but I'm just not getting a "tons of code" feeling from Figure 4b up there. Like, after the handler deals with the fault (which would be the same for '000 and '010, assuming we're using the Lisa MMU), then it seems like you (a) compute the address of the user code to return to (which is easier for the reasons just mentioned) and save it to the program counter location on the stack (b) restore the user's registers, which you would have saved, and which a regular interrupt handler would have had to do (c) point SSP at the saved status register on the stack (d) RTE. It feels like just a few extra instructions --- maybe just two for calculating the proper program counter location and for changing SSP. Perhaps a pair of ADDQ.Ls, a couple dozen cycles maybe. If I'm missing something, what is it?
 

yuhong

Well-known member
Indeed, and that why every workstation vendors used the 68010 rather than the 68000, as otherwise they needed horrible kludge to get paging support in their OS. The two-68000 design from Apollo was probably the most spectacularly over-engineered system ever: the first 68000 did everything but page fault handling, the second 68000 only handled page faults...
Exactly, and the Lisa was no exception.
 
Top