The Architecture of the Lisa Personal Computer (1984) [pdf] | Hacker News Reader

The Architecture of the Lisa Personal Computer (1984) [pdf]

bitsavers.org

69 pointsingve35 comments

The perception of Unix at that time is very interesting — this was way before X existed (X would also not have been suitable by this definition when it did become available, of course). The NeXT UFS variant in 1997 was also probably still unreliable by this definition.

> However UNIX is a relatively large operating system with several features such as a multiuser timesharing capability, user accounting, and protection which would be wasted in a personal computer such as the Lisa. Since the Lisa would be used by people who were not computer experts, the system must be very robust. However, the UNIX file system is fragile and unreliable [10), [14]. If the power is interrupted or a system crash occurs the UNIX file system can easily be damaged. Unless a systems programmer is present to repair the damage, a user can easily lose all his data. In addition, UNIX does not provide the general inter-task communication facility that the Lisa requires. UNIX memory management does not offer sophisticated sharing of code and data between tasks. Finally, UNIX and alI other operating systems do not provide the support for graphics, multiple windows, the mouse, integration, etc., which are essential to the Lisa. Such capabilities cannot be built on top of an operating system but must be built in to work correctly and efficiently. An attempt to modify UNIX to overcome all of these deficiencies would have taken longer than designing a new operating system with all of the needed capabilities.

they were right about all of that, except that bsd did have general ipc

they ended up implementing the multiuser timesharing capability (aka multitasking), but i remember the machine as ridiculously unstable anyway

this probably made the gui unusably slow on the available hardware, though the at&t unix pc did sort of work on hardware that was only two or three times as fast

https://en.wikipedia.org/wiki/AT%26T_UNIX_PC

not sure what you'd do with ipc without multitasking tho

> An attempt to modify UNIX to overcome all of these deficiencies would have taken longer than designing a new operating system with all of the needed capabilities.

This turned out to be essentially correct (see NeXTSTEP, Mac OS X, Linux...)

Nevertheless, Unix was also available for the Lisa.

Some context here - unix of the day was actually tiny, designed to fit in 64k and run on a pdp-11. File systems weren't that unrobust .... but fsck was new and probably not well trusted, prior to that file systems had to be fixed manually

If only the Motorola 68000 line hadn't taken so long to come up with a usable MMU. Computing history could have been very different.

1979, M68000, CPU, instruction backout broken, so if you wanted to handle page faults, you needed to avoid all multi-step instructions.

1993, M68010 CPU, fixed backout bug.

1987, N68030 CPU with MMU, page faults work.

Early machines required boards full of extra hardware to work around this problem. Which is why the Macintosh, unlike the Lisa, had a plain 68000 MMU and a DOS-like OS hidden by a very nice GUI.

You missed 1983’s 68451 segment/limit MMU for the 68010, as well as 1985’s 68020 with 68851 PMMU. There also were MMU implenentations for 68K without instruction resumption—Lisa had one, and Apollo initially used two 68000s to support resumption. Finally, there really isn’t much reason to call the Macintosh operating system “DOS-like” or “hidden;” it wasn’t exposed to the user or developer at all except via APIs, and wasn’t some sort of text-based system that had a graphical interface layered on top of it.

That segmented MMU was pretty useless. And, yes, there was the 68020 machine with the separate MMU. You could run a variant of Unix, called A/UX, on it. It was really slow.

I've coded for the original MacOS. Yes, it was DOS-like at the OS level. No threads. No processes. No CPU dispatcher. A collection of interrupt driven hacks to allow a little bit of asynchronous processing by registering callbacks. Like you'd do on an Arduino today.

Yes, Apple had the Mac II with support for the 68851, but they weren’t the only ones to use it. Though Sun and HP and Apollo all skipped it and continued using extensions of the paging MMUs they’d developed for the 68010. And plenty of those 68020 systems, whether with custom or Motorola MMUs, were quite fast for their time. Any performance issue with A/UX wss on it and the Mac II hardware design itself.

In 1981-4, the era when the original Mac OS was developed, very few systems had threads. And if “has a filesystem and is single-tasking” is your criteria for being “DOS-like” I’m pretty sure every operating system between the inventions of the filesystem and timesharing is also “DOS-like” by your definition.

I’d call an operating system “DOS-like” if it used a filesystem with drive letters and short file names with extensions, a command line where argument interpretation is handled by the executed program, text files to script startup and configure device drivers, and the operating system API existed primarily to mediate filesystem and maybe printer and modem access.

The original Macintosh operating system had no scripting system, used long volume names and filenames, made file type information inaccessible to the user, didn’t include any sort of command line at all, and made providing ways to interact with documents the main point of its API set—to the point where it had no provisions for anything but graphical applications.

I seem to remember the Motorola MMUs requiring significant extra wait states for memory access which was one reason (beyond bugs, lateness, and price) they weren’t popular.

There were many MMUs for 68ks at the time - 68000s and 68010s could use the '451, it was very slow and did use wait states, some people put TLB caches around them, Sun and many others built their own MMUs out of SRAM, there was guy who went around the Valley designing Sun-like MMUs for people they were all different, some were broken, the Lisa had a base and bounds MMU (like a PDP-11)..

The 68000 couldn't restart page faults - people got around that a lot of ways, some put 2 68ks there and paused one while the other took the fault, mostly though most unixes of the day were swapping ones, the only traps that needed to be restarted were those that extended the stack down, and compilers could be persuaded to generate stack probe code. 68010s fixed that problem and were available around the time we started building paged systems.

The 68020s could have an external PMMU (there was another done by Signetics, I think, it was a bit DOA), I think Sun still made their own.

The 68030 pulled the PMMU on chip.

At the time I worked for Unisoft, the company that did Unix for the Lisa, and A/UX for Apple, it was just one of about 150 Unix ports for other companies we did the bulk of them for 68Ks and most of those for those early 68000/010 - in short they were extremely popular, at the time every man and their dog were trying to make the next great workstation in their garages

There's lots of fun Silicon Valley 80's workstation folklore around the MIT 68K PCC port, Unisoft, and Silicon Valley Software's Pascal, Basic and Fortran products. Fun fact that the Sun 1 ran Unisoft Unix before the 68010 'brain transplant' and the BSD port. Also, Unisoft did at least one other UniPlus port for Apple for the YACCintosh. Maybe BigMac as well.

Yup, all true, we did Unix ports for both Sun and AT&T, at the time I think we referred to the target of that other Apple port as "the file server"

I wouldn’t say “boards”. The Sun MMU is/was quite simple (SRAM and a little TTL), only taking a small part of something like a 3/50 motherboard.

maybe the sun 1 and sun 2 were uglier

The designs are all essentially the same, two levels of high speed SRAMs to give you segment/page tables. Some designs supported bigger SRAMS for more contexts. The schematics are all up on bitsavers. Originally, I had thought they came up with it at Stanford, but from memory it seems to be roughly the same setup used in the MIT CADR.

thank you very much for the explanation

Just part of the board. An acquaintance used to own a Sun 100U which I vaguely remember as the proto Sun 2 Multibus CPU in a Sun 1 chassis. Not even an especially busy Multibus (1 before there was a 2) card.

Many years ago now already it was announced that the Lisa OS would be made available by Apple to the Computer History Museum for publication.

https://arstechnica.com/gadgets/2017/12/source-code-for-appl...

That still seems to not have happened. Would be nice to know what the hang up is and what is stopping this from happening.

Also the forum announcement seems to have been deleted to.

It's happening on January 19th: https://twitter.com/bitsavers/status/1607935736518701057

"Therefore, on the Lisa display there are 3 pixels in the horizontal dimension for every 2 pixels in the vertical. These different resolutions do compIicate, slightly, the design of the Lisa graphics soft- ware. For example, the software must remember that a graphical object 150 by 100 appears as a square, however 100 by 100 is a rectangle."

Glad this convention died. Definitely a "clever" hack to save memory bandwidth resulting in a lot of pain for future generations.

Non-square pixel graphics systems were quite common back then.

The Mac really pioneered square pixels (at least for consumer machines). Reportedly, some wanted them for the Lisa, as well, but, as the Lisa was behind schedule and working perfectly with non-square pixels already, the Lisa was denied this luxury. (One may also argue that in an office environment the horizontal resolution may have been more important than square pixels, which would have come at the cost of a third of the horizontal resolution. As usual, no free lunch…)

The Corvus Concept beat it to market, had a higher resolution bitmapped screen with square pixels, was built on top of the same SVS Pascal compiler as Lisa, and vanished because it's software was primitive, barely using the capabilities of the screen and had softkeys like the HP Amigo and no mouse.

http://bitsavers.org/pdf/corvus/Corvus_Concept/

It's essentially what Lisa would have been if the UI direction hadn't changed because of Apple's exposure to the PARC Alto (which also had a 606x808 screen with square pixels).

Fun fact:

Mike Cook, the person who designed the Corvus Concept hardware, ended up going to Apple and designed the board for the LaserWriter II.

I didn't know the Corvus Concept, at all – thank you!

Skimming the user manual, there's a label window below the screen, very similar to the soft function keys approach of the early Lisa concepts, indeed.

Why is bitsaver's informative comment downvoted to dead? Yes slightly off topic re: pixel shape but relevant to the overall topic

They still happen. The official raspberry pi 7” lcd panel has non-square pixels. As do a number of third party small lcd panels commonly used with SBCs.

Fascinating. But how does the graphics card know the pixel layout of the display or is there a chip in the display that recomputes where to display a pixel at (3,3) for example?

WAP enabled phones (the early mobile internet protocol of the early 200s, using a card metaphor) tended to have elongated pixels as well. Converting images for this was fun!

(WAP used a special, binary image format, but the compiler for this didn't care about pixel ratio. The fun part was really designing and previewing these images on square-pixel hardware and then converting this to something which was still crisp on the actual hardware target. But then there were also PDAs, which did have square pixels…)

And you'd even get MS-DOS PC image editing and desktop publishing programs that didn't didn't correct for non-1:1 pixels on-screen, only (hopefully) when printed.

Yet another way the Mac was glorious at the time.

It was a natural consequence of CRT displays being able to provide higher horizontal than vertical resolution. (If text would require higher vertical than horizontal resolution, we might have used CRTs rotated by 90 degrees.)

Only LCDs forced using a single fixed aspect ratio, which then was chosen to be the square one. (Though subpixel rendering still allows for higher horizontal resolution.)

This was interesting - they intentionally built the screen as an inverse:

> As a result, the Lisa bitmap display can operate faster by representing a black pixel as a One and white as a Zero.

The Lisa was incredible, so ahead of its time. Too bad it was so expensive, because otherwise it groundbreaking.

also unstable as fuck

With a system written in a mix of Assembly and a Pascal dialect.

Reply on news.ycombinator.com