Print

[sigma7]

When the Query Engineering Inc. / Sigma Seven Systems Ltd. XLerators were designed, Lisa users/purchasers were almost exclusively interested in using MacWorks Plus/II to run Macintosh applications. As a result, these accelerators were not designed to be used with the Lisa Office System and Programmer's Workshop.

The Lisa Office System uses the custom MMU design in the Lisa, which makes an accelerator design more challenging.

Now that FPGAs have become more affordable, along with the advent of "68000 core" designs (FX68K & TG68K) that can be implemented in an FPGA, I think the possibility of an accelerator that works in LOS is now a practical project.

My current thought is that this would involve a new CPU board, with the 68000 and MMU implemented in the FPGA, along with possibly all of the other CPU board logic, and with main memory on the same board to avoid the slot memory speed bottleneck. Perhaps the 32k of video memory would be separate to minimize the potential slow-down from sharing memory. Features to integrate software debugging would also be very beneficial as using a logic analyzer with the Lisa's 68k is limited without major equipment.

The potential for additional high speed hardware is there as well, such as a fast parallel port that (with a modified driver) might reach the limits of the DMA designs of the Apple ProFile and Patrick's IDEfile.

I see a post at www.atari-forum.com that describes the TG68K core running in an FPGA at 32MHz as being significantly faster than a real 68000 at 40 MHz. LOS running 10 times faster would be nice.

However, maybe such a project is of little interest with an equivalent or better emulator?

[ried]

I would personally be interested in 3-5 units. I wonder if this approach would make them compatible with all Lisa hardware + software variants, from a Lisa 1 running LOS 1.2 all the way through the 2/10 running LOS 3.1?

[bmwcyclist]

Depending on price I would be interested.

[stepleton]

I would probably have interest if it retained full compatibility with other Lisa OSs and programs.

My recollection is that the Lisa MMU is limited to being able to handle only 2 MiB of physical memory. Would the idea be just to accept this as a fundamental limitation (if I'm right)? It might be reasonable as no original Lisa OS would have been written with the expectation of having more.

[sigma7]

... if it retained full compatibility

That is what I would suggest aiming for. Perhaps something smart enough (and programmable/updateable as new requirements are discovered) so that things like adjusting speed to emulate exact original behaviour when reading the serial number and whatever other quirks require something other than full speed are done automatically.

is .. the Lisa MMU .. limited to being able to handle only 2 MiB of physical memory

The MMU covers the entire 16 MB logical address space of the 68000. The 2 MB limitation of a stock Lisa is the physical slot memory circuitry. The MMU controls the mapping of chunks of the 16 MB logical address space to physical memory, the I/O board, and expansion cards.

I haven't carefully studied how LOS uses the MMU, but imagine a scheme such as this: putting the OS in one area, and different apps in other differing areas, and then swapping pages in/out from the hard disk to the limited physical memory which is moved from area to area as required.

If the emulated MMU were smart enough to know that memory didn't always need to be purged and moved (because there is more than enough), and so the swap operations didn't need to be used as much, further performance gains would result. This may require changes to the OS memory management in some cases, but there may be others where the hardware can provide some improvement by itself.

eg. it may be the memory manager doesn't keep careful track of which pages are where, instead it checks if there is memory in the space that it needs to access, and only if there isn't memory there it sacrifices some other address space to move memory and reloads from disk. It may not know, or be easily fooled that there is memory everywhere it is needed and doesn't notice that it hasn't needed to relocate any.

[stepleton]

is .. the Lisa MMU .. limited to being able to handle only 2 MiB of physical memory

The MMU covers the entire 16 MB logical address space of the 68000. The 2 MB limitation of a stock Lisa is the physical slot memory circuitry. The MMU controls the mapping of chunks of the 16 MB logical address space to physical memory, the I/O board, and expansion cards.

It seems to me that the physical memory constraint of 2 MiB is also a consequence of another MMU design characteristic: the 12-bit SORs. Here's my thinking:

The segment origin registers (SORs) are only twelve bits long and the segment origin in use is selected by the high seven bits of the 24-bit logical address. Of the remaining 17 bits, the high eight are added to the segment origin value out of the selected segment origin register (so they don't expand the physical address space any more than the twelve bits we have so far) while the low nine are appended to the result (so these do expand it). 12+9 = 21 bits of address, which is 2 MiB. This per PDF page 36 of https://lisa.sunder.net/LisaHardwareManual1983.pdf ...

It would be sensible then to try and make bigger segment origin registers, which at a glance looks doable to me: you could expand from 12 to 16 bits. This would get you to 25 bits, which would net you an exciting 32 MiB! Of course it would not be possible to have more than 16 MiB online at once for any one program at any time.

It occurs to me to wonder whether any Lisa OSs may have used some of those unused bits 13-16 for shenanigans similar to what the "dirty" early Mac ROMs did with the upper eight bits of 32-bit addresses. You wouldn't be able to keep them in a segment origin register, but if you saved the MMU context to RAM (which you would have to have done if you were running more than three programs and the OS), then you'd be saving each SOR word in a 16-bit RAM word. And who knows, maybe you might want to use some of those bits to mark pages in ways that are meaningful to you... maybe for temporary things like garbage collection marking, for example. If you did this, or even if you were simply not careful to clear bits 13-16 before putting them back into a real SOR, then a "wide" MMU with 16-bit SOR could get you into trouble.

[sigma7]

the physical memory constraint of 2 MiB is also a consequence of another MMU design characteristic: the 12-bit SORs

I agree with that logic.

My suggested/implied approach of fooling the MMU and memory manager would require that the memory manager didn't intentionally alias a block of physical memory into multiple logical address pages, or at least be able to detect that and reproduce it instead of mapping to unique physical memory locations.

Extending the physical memory range of the MMU would be a much better approach for updated or patched software.

So I guess that could mean a runtime configurable design; with one configuration that can trick old software compiled for the existing MMU design, and another configuration implementing a wider MMU for a LOS compiled/patched for it.

Maybe some simplification is possible... some investigation of how the MMU is used in actual operation is in order.