Can a Macintosh use non-contiguous RAM?

[Snial]

Not in "normal" use, but sort-of in "boot" mode…

From a discussion elsewhere on the 68kmla, I thought it was possible to use the FC pins to create a separate instruction/data address spaces.

Sun 3/60 <anecdotes: 4MB/8MB.. 24MB & 19.66MHz for easy 9600 baud divider>

<snip Sun 3/F FPGA limitations> Apart from that it's great

Well, when you’ve fixed these issues, you’ll be able to add more ram.

<snip> AI tools pretend to <snip> write you verilog <snip> even the simplest bits (that I can actually understand) contain bugs <snip>

There’s good evidence now to Show that AI coding wastes more time checking and fixing. People are mesmerised by it, imagining they actually reason or think, when in fact it’s just a case of Conquistadors dangling trinkets in front of indigenous South Americans. LLMs can’t think, never will, it’s just snake oil.

... for home computers. <snip>

Yes, that’s what I mean. It’s not super-hard to write a workable VM algorithm. I had a go at writing one for ARM2/MEMC which I call TAVMOS (Toy ARM VM OS ).

The challenge is that legacy home computer software could trample all over RAM. For example, if PC application programmers had avoided direct access to the segment registers (with multi-segment access being via OS APIs only), then the 286 would have been properly upwards compatible. But they didn’t, so a decade was lost.

Unless your definition of "proper use of MMUs" <snip>

I just mean an MMU which can support an app where its memory requirements can be more than available physical RAM, not counting software-only overlay techniques (like the early Mac segmentation manager). Software table-walking is OK, I think the MIPS MMU did that too.

 

[Melkhior]

From a discussion elsewhere on the 68kmla, I thought it was possible to use the FC pins to create a separate instruction/data address spaces.

It's possible - I just don't know of any implementation doing it in "normal use". As I mentioned, Sun-2/3's "boot mode" sort-of does it, but in practice it's not really separate address spaces as there's no "overlap": the PROM always use the addresses from when it's mapped by the MMU, it's just that in boot mode some upper address bits are ignored and the PROM is selected by (BOOT_EN & FC==6) rather than by physical addresses. Out of boot mode, it's just physical address-based selection as all other hardware. Only FC[2] is meaningful vs. the supervisor-only bits in the MMU output (and FC=7 as on all 68k hardware, and the case below).

The closest Sun comes is using FC==3 for system control use (the MMU, system register, irq register, etc.). It's therefore in its own address space. But it's still "sort-of", as updating the MMU/registers is a weird mix between upper 4 bits use to select which system control block to update and lower 28 bits still containing the address. This limits the usable VM range to 256 MiB (I think I could push it to two non-contiguous 512 MiB block, not sure if it's worth the hassle software-side). It's a bit hackish IMHO, but at the time 256 MiB virtual mapping per process to up to 4 GiB of physical addresses was a reasonable design choice.

I don't know any hardware that allows the exact same virtual address to be mapped to two different piece of hardware simply based on FC=1/2//5/6 (i.e. Data/Program, User//Supervisor) And on the MC68030, you'd probably better off using the 2 UPA bits (stored in the MMU mappings) as extra address bits to get up to 16 GiB of physical space instead.

 

[Arbee]

Incidentally, the SPARC architecture has a segmentation mechanism specifically to emulate the FC=2 behavior of the 68k Suns. You think other vendors' back compatibility hacks are gross, Sun made theirs mandatory in the CPU architecture.

The LC's version of the HMMU is specifically for 24-bit mode and it isn't involved in remapping memory. In fact, it's literally a programmable AND gate on A31. This works because the V8 chip only sees A0-A23 and A31, so MacOS "32-bit mode" is actually 25-bit mode. A31=1 is intended for PDS card use; the PDS slot gets all of the address lines except A28, A29, and A30, so well behaved cards can respond at $Fx000000 like normal. On the original LC the address on the bus is effectively $8x000000 but both the software and the card get to pretend we're in a perfectly normal NuBus $Fx000000 address space. Cards that did everything properly work transparently in the LC III and later systems where (via additional pins) all 32 address bits are available.

The V8's programmable memory controller does always create contiguous memory, and with some SIMM configurations it can discard some of the available memory in order to accomplish that.

 

[Snial]

<snip> SPARC <snip> segmentation <snip> FC=2 behavior of the 68k <snip>' back compatibility hacks are gross, Sun made theirs mandatory <snip>

Lol! Thanks for that! @Melkhior is very much into Suns & for kicks (mostly self-inflicted ) I'm exploring SS5 emulation on QEMU running at the same speed as the IPX I had a Manchester Uni.

I guess you've scanned earlier comments so you know we've been talking about the Sun MMU (because Melkhior is developing a Sun on an FPGA and because I sometimes play around with toy Virtual Memory algorithms for ARM-26, '286 and Interdata 7/32 architectures). Perhaps I'm wrong, but when we looked at the Sun docs on the Sun 2 MMU, SUN refer to the FC-2 behaviour as address spaces:

Sun's MMU also describes it as supporting segments, but in fact these are just second-level page tables (it's a 2-level system). They're not segments in the Multics, 80286-x86 sense. Similarly, architectures like the pdp-11 and Interdata 7/32 talk about supporting segments, but this is also misleading. You can't use them to implement Multics, they're just variable-length bank-switched memory systems (like the 'MMU' on the Z180).

The LC's version of the HMMU is specifically for 24-bit mode and it isn't involved in remapping memory. In fact, it's literally a programmable AND gate on A31. This works because the V8 chip only sees A0-A23 and A31, so MacOS "32-bit mode" is actually 25-bit mode. A31=1 is intended for PDS card use; the PDS slot gets all of the address lines except A28, A29, and A30, so well behaved cards can respond at $Fx000000 like normal. On the original LC the address on the bus is effectively $8x000000 but both the software and the card get to pretend we're in a perfectly normal NuBus $Fx000000 address space. Cards that did everything properly work transparently in the LC III and later systems where (via additional pins) all 32 address bits are available.

The information density of this paragraph is too dense for me to <snip> it!

The V8's programmable memory controller does always create contiguous memory, and with some SIMM configurations it can discard some of the available memory in order to accomplish that.

So, in theory you could add about 256MB to an LCII's PDS slot (or at least 128MB) and as Melkhior said a few posts back, on boot up physical page tables to make them all contiguous. Nevertheless, the HMMU does do some work to make SIMM memory contiguous, I guess before the MMUs get to work!

 

[Arbee]

Sun's MMU also describes it as supporting segments, but in fact these are just second-level page tables (it's a 2-level system). They're not segments in the Multics, 80286-x86 sense. Similarly, architectures like the pdp-11 and Interdata 7/32 talk about supporting segments, but this is also misleading. You can't use them to implement Multics, they're just variable-length bank-switched memory systems (like the 'MMU' on the Z180).

I helped get MAME's SS1 driver to boot and install Solaris so I have much more familiarity with the thing than I otherwise would have. (My university got all their free stuff from DEC, so my hand-on experience was with the MIPS-based DECstations and some of the early Alphas).

So, in theory you could add about 256MB to an LCII's PDS slot (or at least 128MB) and as Melkhior said a few posts back, on boot up physical page tables to make them all contiguous. Nevertheless, the HMMU does do some work to make SIMM memory contiguous, I guess before the MMUs get to work!

Yes! In theory you could have a PDS card with 256 MB of RAM (or even 512 MB) and reprogram the '030 MMU to make it contiguous with the V8's 10 megs. That's the kind of completely impractical and hilarious hack that I half expect someone to try.

 

[adespoton]

I helped get MAME's SS1 driver to boot and install Solaris so I have much more familiarity with the thing than I otherwise would have. (My university got all their free stuff from DEC, so my hand-on experience was with the MIPS-based DECstations and some of the early Alphas).

Hah; my university was in the same boat; we also migrated from SVR4 to Irix and had NextStations -- but I didn't get to play around with Solaris until after I'd graduated. So most of my educational work was done on SVR4 and Irix, with a bit done on DEC's Ultrix, or later OpenVMS. I had an account on DEC's Alpha test servers and would regularly test stuff that ran fine/glitchy on Irix just to see if it could trigger a core dump. Every once in a while, it did

 

[Snial]

I helped get MAME's SS1 driver to boot and install Solaris so I have much more familiarity with the thing than I otherwise would have. (My university got all their free stuff from DEC, so my hand-on experience was with the MIPS-based DECstations and some of the early Alphas).

That's really cool! Sorry if I was patronising, I really have no idea what involvement people have had with other architectures. All the early RISC architectures are interesting from my view (even ARM26). I don't own a Sun SPARC anything, but I do own a PA-RISC 715 (or 725/735) and an SGI Indy (R4000, low-end graphics) both of which I got for free. The Indy doesn't work, because I don't have a HD for it and because the Dallas RTC battery has failed (of course). The PA-RISC did work at one point. I have an Irix 5.6 (or 6.3?) CD.

Yes! In theory you could have a PDS card with 256 MB of RAM (or even 512 MB) and reprogram the '030 MMU to make it contiguous with the V8's 10 megs. That's the kind of completely impractical and hilarious hack that I half expect someone to try.

It's a thought isn't it?! I would probably only take my LCII up to a mere 64MB since I don't want my tea to get too cold before it finishes booting.

 

[Arbee]

If you just assume it's there and hack it into the MMU tables it won't extend the boot time.

 

[Snial]

<snip> Irix and had NextStations -- but I didn't get to play around with Solaris <snip> trigger a core dump. Every once in a while, it did

So are we saying that Solaris was the benchmark for Unix vendor workstation OS’s, better than Irix (which I think is a pretty good name), NeXTStep and that Alpha’s were pretty dodgy? (I have zero opinion either way, im
Just having fun with SunOS 4.1.3 on a QEMU emulator. Though… @Arbee , is MAME’s SS1 emulator more efficient than QEMU’s?

 

[adespoton]

So are we saying that Solaris was the benchmark for Unix vendor workstation OS’s, better than Irix (which I think is a pretty good name), NeXTStep and that Alpha’s were pretty dodgy? (I have zero opinion either way, im
Just having fun with SunOS 4.1.3 on a QEMU emulator. Though… @Arbee , is MAME’s SS1 emulator more efficient than QEMU’s?

Solaris and Irix had different strengths; Alphas running VMS were really a completely different beast, and the system was never really finished when DEC ran into problems. I like to think that the Alpha platform would have been the start of something awesome (kind of like Taligent would have been) if it had been allowed to mature -- of all the systems, Solaris was the one that survived long enough to be modernized with access to improved hardware. I think of it as being the Amiga of the server world. Of course, it eventually lost out to Linux and got bought by Oracle who promptly canned it, but Sun had some awesome hardware/software combinations for a while, and even a Mac OS VM (not really an emulator, as it ran 68k Mac code on a 68k Sun workstation).

 

[Arbee]

Though… @Arbee , is MAME’s SS1 emulator more efficient than QEMU’s?

Pretty unlikely. It hasn't gotten a ton of development work. I don't know if QEMU is doing JIT or not for SPARC, which would be the main thing determining how efficient it is.

Solaris was the one that survived long enough to be modernized with access to improved hardware. I think of it as being the Amiga of the server world.

The Amiga realistically lived and died in the form of the original A1000 and A500. All of the "must see" Amiga software runs on those machines, and a lot of it doesn't run on any newer models. On the other had, SunOS went from 68k with the Sun MMU to 68k with the stock Motorola MMU (the sun3x architecture) and then Solaris went from 32-bit SPARC to 64-bit SPARC.

 

[Snial]

Pretty unlikely. It hasn't gotten a ton of development work. I don't know if QEMU is doing JIT or not for SPARC, which would be the main thing determining how efficient it is.

Oh, OK. I'm sure I've seen one page or blog post measuring QEMU for various CPU emulations at about 1:30 to 1:60 native instructions per emulated instruction. That sounds about right for an interpreter. 1:50 wouldn't be fast enough for emulating SPARC on Raspberry PI <3, but even a simple JIT could do much better. And, I think with the kind of RAM you'd get on a PI 3 (1GB) you'd be able to JIT cache the whole of an IPX class Sun workstation's RAM (64MB => 256MB to 512MB of JIT cache tops).

The Amiga realistically lived and died in the form of the original A1000 and A500. All of the "must see" Amiga software runs on those machines, and a lot of it doesn't run on any newer models. On the other had, SunOS went from 68k with the Sun MMU to 68k with the stock Motorola MMU (the sun3x architecture) and then Solaris went from 32-bit SPARC to 64-bit SPARC.

That's a similar path to the other workstation manufacturers, like SGI going from 68K to MIPS32 and MIPS64; though Sun also flirted with Intel. Perhaps @adespoton was thinking of some other aspect of the Amiga that compares well, perhaps the sense in which Sun survived the longest in the Workstation market and Amiga survived the longest in the home computer market?