IIsiFPGA: HDMI for the 68030 PDS slot

[Melkhior]

Hello all,

Following the NuBusFPGA (thread here), here comes the IIsiFPGA, adding the Highly Desirable Macintosh Interface to the Macintosh IIsi.

The IIsiFPGA is the same concept than the NuBusFPGA, uses the same FPGA daughterboard, but is designed to be connected to the 120-pins DIN 41612 connector used by some 68030-based Macintosh, with the Macintosh IIsi the one it was designed for and tested in.

I'm not sure if it will fit mechanically in the SE/30, but should be electrically compatible.
It might also be adapted to work in a IIfx, but with some limitations (the IIfx clock signal uses a different pin than the IIsi or SE/30, and some other weirdness)
I do not own a SE/30 or a IIfx so I'm not going to be able to test either anytime soon.

Currently the full Framebuffer available in the NuBusFPGA is supported, including audio & acceleration. It's much slower than a NuBusFPGA in a Q650, so I suspect the CPU performance is quite important for QuickDraw.

The current goal is to use the unused DDR3 memory as additional memory for the system, but so far the ROM has been resistant to my attempts (I'm using a Flash ROM SIMM and associated programmer, thanks to the designers for creating and sharing such a great way of 'improving' the ROM). For now, I can 'see' my memory from a usercode by enabling it through the TT0 (Transparent Translation) register of the MMU, and the CPU will appropriately use burst if the CI (cache inhibit) bit is not set (burst doesn't work yet but it's a way to debug it). However, I can't just expand the Memory Chunk table, as some parts of the ROM assume a MDU-based system like the IIsi only has two banks, which might be split in three 'pseudo-banks' to accomodate the internal video. I need another bank to be mapped by the MMU, along with appropriately updated globals (such as the total memory size).

The board can be plugged 'vertically' in the PDS slot, but you can't close the case; it is also known to work (and improve the situation!) with my own IIsi PDS adapter, at least the PLCC version. Turns out there's enough clearance to fit the IIsiFPGA parallel to the motherboard with no issue - other than potentially the system overheating.

Like the NuBusFPGA, it's all on GitHub, see the link(s) in the first line of this post.

Edit: let's have a picture

 

[zigzagjoe]

Nice work! Using the spare RAM as system RAM is a particularly fun twist.

Interesting that you find it is majorly slower though. I was under the impression nubus as bottleneck relative to any kind of PDS. Though there is a strong correlation to CPU speed with quickdraw, and that quadra is probably 4x faster than a IIsi. Looks like you are using synchronous transfers so you should be getting as much bandwidth as is possible as long as the FPGA can keep up (kind of doubt that'd be the choke point...)

I'd be curious to see what results you get in Speedometer 4.0 for the various bit depth graphics tests - that'd be an easy comparison to other cards.

I think Z clearance to chassis will be the problem in a SE/30. From PCB to chassis there is around 15mm, maybe you could get enough space by stripping the barrel jack and heatsink from the carrier. Or replace headers with male headers and use flush mount female headers, but that's more than a little cumbersome.

 

[shadedream]

This looks really cool, definitely want to keep an eye on it (I love the IIsi).

Would it be possible for something like this to eventually scale the HDMI output video and "pad" it for modern HDMI TV resolutions? That would be really nice for capturing or streaming the output without needing the extra steps of an external upscale box etc.

 

[Melkhior]

Nice work! Using the spare RAM as system RAM is a particularly fun twist.

Should it ever work The SW side is the issue, That part of the ROM doesn't appear to be in the source code available - they were updated/obsoleted in newer versions, so figuring out what to do isn't easy.

Interesting that you find it is majorly slower though. I was under the impression nubus as bottleneck relative to any kind of PDS.

NuBus is slower than PDS (lower bandwidth, higher latency), but I'm comparing a 20 MHz '030 vs. a 33 MHz '040... I don't have a NuBus adapter for the IIsi, but I suspect the NuBusFPGA would be even slower in the same machine. I do use synchronous bus cycle, but write still have a wait state for now, that could be improved in theory, though it won't help that much.

I'd be curious to see what results you get in Speedometer 4.0 for the various bit depth graphics tests - that'd be an easy comparison to other cards.

What I've run is in the 0.2-0.4 range, depending on depth and whether acceleration is enabled, at max resolution. Which isn't great.

Also it's a IIsi, and mine only has 5 MiB (1+4x1), and with such limited memory I didn't 'optimize' it by expanding the disk cache to move MacOS away from bank A (the one used by the internal video). I should retry with that 'optimization', or without the internal video plugged (I assume that disables it completely), to see how costly it is in performance.

Would it be possible for something like this to eventually scale the HDMI output video and "pad" it for modern HDMI TV resolutions?

The FPGA is already at its limits when running at Full HD (1920x1080) which is my 'default' setting to be compatible with commonly available LCD monitor. Running at lower 'hardware' resolution (or more accurately, lower pixel clock) is easy. The pixel clock required for larger resolution is too high for the FPGA I use. But Full HD should be compatible with HDMI capture I believe.

 

[Phipli]

The current goal is to use the unused DDR3 memory as additional memory for the system, but so far the ROM has been resistant to my attempts (I'm using a Flash ROM SIMM and associated programmer, thanks to the designers for creating and sharing such a great way of 'improving' the ROM). For now, I can 'see' my memory from a usercode by enabling it through the TT0 (Transparent Translation) register of the MMU, and the CPU will appropriately use burst if the CI (cache inhibit) bit is not set (burst doesn't work yet but it's a way to debug it). However, I can't just expand the Memory Chunk table, as some parts of the ROM assume a MDU-based system like the IIsi only has two banks, which might be split in three 'pseudo-banks' to accomodate the internal video. I need another bank to be mapped by the MMU, along with appropriately updated globals (such as the total memory size).

I suspect there is something that makes this not easy to do. The common way this was implemented back in the day was to present RAM on the expansion card as a RAM disk, then use that RAM disk as very fast Virtual Memory. This work around was used by a large number of cards.

 

[Melkhior]

I suspect there is something that makes this not easy to do.

The only way I figured it might be possible involves heavily patching the ROM, so that another physical range is added early on in the process - before the MMU is set up and all the related stuff. Back in the day, they couldn't do that, as I don't think Apple would have let them ship an heavily modified copy of the ROM. Having any third-party ship a ROM legally would have been opening a Pandora's box of clones - there were some clones back in the day (mostly luggable/portable) that expected the user to provide a ROM from a legit Macintosh.

The memory setup happens so early in the process, I don't think there's any other way. Declaration ROM are much too late. But with the willingness to use a Flash ROM SIMM & a modified ROM, then it might be possible - I don't think there's any hardware reason why not, so it's a matter of sorting out the software. Which is the hardest part, but oh well

 

[Phipli]

The only way I figured it might be possible involves heavily patching the ROM, so that another physical range is added early on in the process - before the MMU is set up and all the related stuff. Back in the day, they couldn't do that, as I don't think Apple would have let them ship an heavily modified copy of the ROM. Having any third-party ship a ROM legally would have been opening a Pandora's box of clones - there were some clones back in the day (mostly luggable/portable) that expected the user to provide a ROM from a legit Macintosh.

The memory setup happens so early in the process, I don't think there's any other way. Declaration ROM are much too late. But with the willingness to use a Flash ROM SIMM & a modified ROM, then it might be possible - I don't think there's any hardware reason why not, so it's a matter of sorting out the software. Which is the hardest part, but oh well

The SuperMac SE Accelerators, like the one that @joshc has just sold to @MacOSMonkey quite heavily patched the ROM I think. It was advertised as being able to provide up to 32MB of RAM on a machine with a 24bit ROM... if I remember right.

 

[demik]

That's really cool.

Stupid fallback idea about the memory issue: Does using DDR3 memory as a RAMDisk for virtual memory work ?

 

[Phipli]

The only way I figured it might be possible involves heavily patching the ROM, so that another physical range is added early on in the process - before the MMU is set up and all the related stuff.

@David Cook : what you were talking about here...

12 MB on an LC II and Color Classic?
I think you could create an extension that could check for 10 MB on these types of computers with 4 MB onboard memory. Then it would call SizeMemory with a better table that searched all the way to Addr12MB and then warm reboot. I suspect SizeMemory is only called again at cold start. This would give you 12MB.

Would this extension be possible to implement in @Melkhior's scenario?

 

[Melkhior]

Stupid fallback idea about the memory issue: Does using DDR3 memory as a RAMDisk for virtual memory work ?

It probably would.

The RAM disk is as yet untested on IIsiFPGA, but it should work exactly as in the NuBusFPGA provided the DMA is disabled (the DMA will currently only work on Quadra in the NuBusFPGA anyway, as it uses clock write).

I haven't tried enabling virtual memory on it, but no reason it should work, provided the system is fine with a freshly initialized drive at boot. If it needs to have some persistent stuff in it, then some changes are needed, as currently the RAM disk is always re-initialized in case the DDR3 was corrupted during reboot (the controller reset and is re-configured, so some refresh cycles will be missed and some data could be corrupted). But in theory, none of that is a major issue.

But it won't as fast at if it were dealt with as 'real' memory, as you still need to do page-ins/page-outs between the 'real' memory and the RAM disk. Also, it's not as elegant

Would this extension be possible to implement in @Melkhior's scenario?

I tried fixing the tables (adding an extra 'chunk'), but it apparently doesn't work due to assumptions in the code, such as having only two 'chunks' in the hardware - the function setting up the MMU only create 3 chunks when the internal video is used (bank A split in video/non-video, bank B). And that extra 'chunk' should be ignored by the code handling the memory controller itself. I'm also uncertain the SizeMemory function I see in the ROM is safe to call after boot? Mmmm, re-reading @David Cook explanations, the solution requires a reboot - which would be an acceptable (temporarily at least) workaround. Did anyone work on such an extension (or patched ROM) already?

 

[shadedream]

The FPGA is already at its limits when running at Full HD (1920x1080) which is my 'default' setting to be compatible with commonly available LCD monitor. Running at lower 'hardware' resolution (or more accurately, lower pixel clock) is easy. The pixel clock required for larger resolution is too high for the FPGA I use. But Full HD should be compatible with HDMI capture I believe.

Yep that sounds like more or less what I was asking. I've used VGA to HDMI converters and they generally 1:1 convert the resolution which capture cards do not like at all, so I was largely asking about it feeding 720p or 1080p out. Thanks!

 

[Melkhior]

The current goal is to use the unused DDR3 memory as additional memory for the system, but so far the ROM has been resistant to my attempts (I'm using a Flash ROM SIMM and associated programmer, thanks to the designers for creating and sharing such a great way of 'improving' the ROM).

Well, very very little testing so far, but at last System 7 is now booting with a reasonable amount of memory in my IIsi:


Almost 133 MiB of memory : 1 MiB from soldered bank A (minus the internal video), 4x1 MiB from SIMMs, and 128 MiB mapped in the DDR3 of the IIsiFPGA Boot is extremely long due to memory testing, but then the machine doesn't feel any slower than before. I did implement burst mode using a dedicated port to the DDR3, so read shouldn't be too terrible, but the latency is still likely higher than the 'real' memory. I haven't had time to do any benchmarking.

Just in time too before I have to leave for some vacations ;-) I will have to see how far I can push the ROM, there's still another 120 MiB I could use (256 MiB total DDR3 minus the 8 MiB for the framebuffer), and then share some code on the GitHub for those interested (but this will have to wait for my return of vacations).

I suspect any '030 machine compatible with a IIsi ROM & with a '030 PDS or cache slot _should_ be amenable to a similar patch of the ROM to enable some additional bank(s?) of memory.

Also it could be worth investigating solutions to use SDRAM as expansion memory for '030 systems, with the SDRAM chips directly connected to the '030 bus (so likely faster than my very indirect solution through the FPGA). I know of two public implementations using FPGA already, both targeted at Amigas (here and here).

Anyway, I'm quite happy with that result

 

[Phipli]

Well, very very little testing so far, but at last System 7 is now booting with a reasonable amount of memory in my IIsi:

View attachment 59716
Almost 133 MiB of memory : 1 MiB from soldered bank A (minus the internal video), 4x1 MiB from SIMMs, and 128 MiB mapped in the DDR3 of the IIsiFPGA Boot is extremely long due to memory testing, but then the machine doesn't feel any slower than before. I did implement burst mode using a dedicated port to the DDR3, so read shouldn't be too terrible, but the latency is still likely higher than the 'real' memory. I haven't had time to do any benchmarking.

Just in time too before I have to leave for some vacations ;-) I will have to see how far I can push the ROM, there's still another 120 MiB I could use (256 MiB total DDR3 minus the 8 MiB for the framebuffer), and then share some code on the GitHub for those interested (but this will have to wait for my return of vacations).

I suspect any '030 machine compatible with a IIsi ROM & with a '030 PDS or cache slot _should_ be amenable to a similar patch of the ROM to enable some additional bank(s?) of memory.

Also it could be worth investigating solutions to use SDRAM as expansion memory for '030 systems, with the SDRAM chips directly connected to the '030 bus (so likely faster than my very indirect solution through the FPGA). I know of two public implementations using FPGA already, both targeted at Amigas (here and here).

Anyway, I'm quite happy with that result

Good work

 

[cheesestraws]

Oh, well done!

 

[Melkhior]

I will have to see how far I can push the ROM, there's still another 120 MiB I could use

Turns out, it seems the ROM doesn't mind banks with non-consecutive reserved addresses after all and it doesn't mind non-power-of-2 banks (I think provided they are fully loaded) either. So simply moving my extra bank from 128MiB@0x08000000 to 240MiB@0x20000000 just works the way I patch the ROM, and I get ~245 MiB available in System 7.

Also, a loooooooooooooong boot

 

[Phipli]

Turns out, it seems the ROM doesn't mind banks with non-consecutive reserved addresses after all and it doesn't mind non-power-of-2 banks (I think provided they are fully loaded) either. So simply moving my extra bank from 128MiB@0x08000000 to 240MiB@0x20000000 just works the way I patch the ROM, and I get ~245 MiB available in System 7.

Also, a loooooooooooooong boot

If you put a BMOW ROMinator 2 in the IIsi it will skip the memory test, although I suspect in your case you probably need the RAM test!

 

[Melkhior]

If you put a BMOW ROMinator 2 in the IIsi it will skip the memory test, although I suspect in your case you probably need the RAM test!

I tried such a ROM in my IIsi before my experiments, but it wouldn't work "properly". It seemed to conflict with the installed operating system somehow, so crashed before boot finished. I went back to a 'clean' IIsi ROM as the baseline, with just the checksum checks disabled as per instructions I found about the ROMinator 2.

I should try to disable the memtest now for faster boot, but as you suspected, for my use case having some RAM tests during development is a *good* thing Even if they take several mjnutes - stressful minutes when you don't know if things are slow or completely hung!.

 

[Phipli]

I should try to disable the memtest now for faster boot, but as you suspected, for my use case having some RAM tests during development is a *good* thing Even if they take several mjnutes - stressful minutes when you don't know if things are slow or completely hung!.

Off the top of my head, the warm boot memory test just tests 1k of memory instead of a full test - might it be possible / useful to bump that up into your memory range and use just that, instead of the full test?

Probably not worth the effort just for speeding up debug.

 

[Melkhior]

Off the top of my head, the warm boot memory test just tests 1k of memory instead of a full test

Hadn't actually try a warm reboot, flashing the ROM (or changing the FPGA bitstream) requires a lot of cold boots instead

You're right about a reboot cutting down the tests - reboot is as fast as before the IIsiFPGA, seconds instead of minutes.

 

[SophieRose]

Wow what a fab project.. super interested in this.