QuadraFPGA: HDMI for the 68040 PDS slot

[Jockelill]

The NuBusFPGA should definitely work in there.


Well, now that your IIsiFPGA is working in a IIsi and a SE/30, it might be time to try a bitstream for the IIfx as well I was worried the weird PDS implementation might cause issue, but it is working for the SEthernet/30, so worth a shot probably.

The difference in pins is mostly the clock.

My Linux machine is armed and ready to flash

 

[olePigeon]

A IIfxFPGA would be a nice card. It'd give 99% of the IIfx users out there something to do with their PDS slot. It'd also offer a slotless option for video, leaving the other 6 NuBus slots open.

 

[Jockelill]

A IIfxFPGA would be a nice card. It'd give 99% of the IIfx users out there something to do with their PDS slot. It'd also offer a slotless option for video, leaving the other 6 NuBus slots open.

AND I can finally have 7 screens to my IIfx

 

[Melkhior]

A IIfxFPGA would be a nice card. It'd give 99% of the IIfx users out there something to do with their PDS slot. It'd also offer a slotless option for video, leaving the other 6 NuBus slots open.

At most 5 if using a pseudo-slot design and the 20 MHz half-speed clock, as there's only 6 slot area in the memory map ($9 to $E inclusive).

Using 'slow space' ($6 area) you can use the 20 MHz clock without interfering with the NuBus area. It makes the software abit more complex, but the hardware would be the same.

The 'holy grail" of performance would be to use the 'fast space' ($7 area), where the PDS is run at the full 40 MHz. That would requires some specific hardware support, and software similar to the $6 area. Fastest possible video in a IIfx, II think.

Also I believe in the IIfx, as in Quadras, the PDS is aligned with a NuBus, so there would be physical fitting issue as well. And power issue, potentially. Ir's probably safer to stick to less than 7. Or to do multi-head devices, which is were the market ultimately went.

 

[Powerbase]

What about us with LC-PDS slot Macs? Joking but sorta serious.

 

[LaPorta]

I'd totally take a IIfx option if one was made. No more messing around with adapters....HDMI instead!

 

[Jockelill]

What about us with LC-PDS slot Macs? Joking but sorta serious.

Well, it sort of exists, so far only in beta phase. @Melkhior did a design for it and I did get two boards, but they need some attention before they will be operational. Signal wise it's very similar to IIsiPDS. The biggest issue is that the FPGA will not fit under the lid, so you would have to run the machine open. It could be sorted be creating a complete dedicated card, but that is a whole different level of development

 

[Powerbase]

Well, it sort of exists, so far only in beta phase. @Melkhior did a design for it and I did get two boards, but they need some attention before they will be operational. Signal wise it's very similar to IIsiPDS. The biggest issue is that the FPGA will not fit under the lid, so you would have to run the machine open. It could be sorted be creating a complete dedicated card, but that is a whole different level of development

Would that work on the 040 machines with the LC-PDS slot? Since they didn’t have an 030 wasn’t it an ‘emulated’ pds slot.

Yeah, not a lot of room in them pizza boxes. It would probalby need a fully dedicated card that might be beyond the scope of this.

 

[Jockelill]

Would that work on the 040 machines with the LC-PDS slot? Since they didn’t have an 030 wasn’t it an ‘emulated’ pds slot.

Yeah, not a lot of room in them pizza boxes. It would probalby need a fully dedicated card that might be beyond the scope of this.

Was a bit unclear, it will only work in the the machines with extended LC-slot . We need the 32bit signals. So LC3 (maybe?), 630, 475/605 and 575.

 

[Jockelill]

Would that work on the 040 machines with the LC-PDS slot? Since they didn’t have an 030 wasn’t it an ‘emulated’ pds slot.

Yeah, not a lot of room in them pizza boxes. It would probalby need a fully dedicated card that might be beyond the scope of this.

Here is the card in the machine, you can’t close the lid (by about 10mm). Might be possible to do a cutout, but maybe a bit brutal

 

[eharmon]

Any pointers to the relevant documentation? There DeclROM isn't particularly well documented post-DCDMF3 and I can't find an explicit documentation of the Display Manager, let alone the ROM part of it.
(... some more googling...)
Apparently, from Develop 25 (March '96), you need the "Display Manager Development Kit" from the CD... That seems available, I'll have a look through that. Any other pointers welcome

One trick is to compare a ROM which was updated for 7.5.2+ support, you can see the modifications that add DM2.0 support and what they do. If I remember right, sVidAuxParams controls the names for 7.5.2+, and not sRsrcVidNames.

Is there a build log for the QuadraFPGA or NuBusFPGA? I'd be interesting to see the build process!

Maybe I missed it in the repo, but what speed grade FPGA does this need? Is the (relatively) cheaper 2.13b 1C sufficient?

 

[Bolle]

I wonder if they would work on a 68k Mac...

They do work in 68k Macs as dumb framebuffers. Acceleration only works on PPCs… supposedly VillageTronic was developing a 68k acceleration driver but never finished it before going out of business.

 

[Melkhior]

One trick is to compare a ROM which was updated for 7.5.2+ support, you can see the modifications that add DM2.0 support and what they do. If I remember right, sVidAuxParams controls the names for 7.5.2+, and not sRsrcVidNames.

'sVidAuxParams' isn't awfully well documented... google only finds it in your thread about the Thunder II @ 1600x1200 (which I had forgotten and where you already mentioned this... not getting any younger it seems). It has an entry 123 in the appropriate header (the one you quoted), and that's about it.

I think the answer lies in the "Display Device Driver Guide" technical note, for which I can't find a PDF - just the Apple Doc Viewer document in the Dec'94 developer CD. It does mention a timing directory, but uses the sVidParmDir name (which is a different thing) and the number 123 (sVidParmDir is really 126). The content described matches what I find in the Mac Roms on the internet, that is a single entry to a number. That number is a 'preset' timing entry (this is coherent with @joevt analysis), and in the Mac Rom it maps to reasonable value.

So I don't think I can get arbitrary names from sVidAuxParams, as it only point to predefined stuff as far as I can tell.

Is there a build log for the QuadraFPGA or NuBusFPGA? I'd be interesting to see the build process!

Not sure what you mean by a build log - from the hardware, gateware, software? The hardware was mostly made by JLCPCB so it's just the KiCad project and the generated files (gerbers, CSV for BoM and placement); the gateware is mostly Litex/migen (with just a touch of occasional verilog); the software is essentially the Rom (built with Retro68) and a couple of CodeWarrior-built INIT for acceleration and audio.

If you mean generating the bitstream, it's a bit of a mess to reproduce, as my Litex is quite outdated so using a current version is an unknown. I've put reference version for the 2.12b/2.13a on GitHub.

Maybe I missed it in the repo, but what speed grade FPGA does this need? Is the (relatively) cheaper 2.13b 1C sufficient?

Speed grade 1 is enough, yes. The 2.13b is already overkill in size (50T), the 2.13a (35T) was the primary target but is discontinued. 2.12b is the current replacement for the 2.13a. I've had some issues with mine (which i need to debug further as some of it might have been timing issues with /STERM that I identified later), but @Jockelill seems happy with his - the picture he posted for the LC32FPGA is with a 2.12b (as visible on the silkscreen).

 

[Melkhior]

They do work in 68k Macs as dumb framebuffers. Acceleration only works on PPCs…

Makes sense. Thanks for the confirmation.

supposedly VillageTronic was developing a 68k acceleration driver but never finished it before going out of business.

If that board was released as late as '98, or even in '97 or '96, spending money on acceleration for systems already obsolete twice (CPU first 68k->PPC '94, I/O second NuBus -> PCI '95) and unlikely to cause any additional sales doesn't sound like a great business decision... It was certainly commendable to want to support users though. Too bad all those efforts (by them and others) disappeared. I'd love to get access to the acceleration source code for such devices (68k or PPC), to see where I could improve the support in the *FPGA. We've been lucky enough with ROMs and some drivers, but those didn't include in QD acclereration that I could find (just things like hardware pan&scan, virtual desktops, etc., which are just tricks with addressing the video ram).

 

[uyjulian]

I think the better bet for video acceleration is reversing the ATI drivers and maybe backporting them.

The decompiler situation should be better for PPC (compared to 68k)