General Category > Lisa Project Ideas

LOS Compatible Accelerator

<< < (2/2)

stepleton:

--- Quote from: sigma7 on March 17, 2025, 05:42:39 am ---
--- Quote from: stepleton on March 17, 2025, 04:59:16 am ---is .. the Lisa MMU .. limited to being able to handle only 2 MiB of physical memory

--- End quote ---

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.

--- End quote ---

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:

--- Quote from: stepleton on March 17, 2025, 02:49:25 pm ---the physical memory constraint of 2 MiB is also a consequence of another MMU design characteristic: the 12-bit SORs

--- End quote ---

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.

Navigation

[0] Message Index

[*] Previous page

Go to full version