My nubus pipe dream

[Jockelill]

wow this is insane =)

does these support 1280x1024 also or only hdmi spec?

Yes, I'm running with the non HDMI version in my machines, I can live without audio since I have more usage for the other resolutions . I actually have a spare Nubusboard here if you are interested. Shot me a PM. They are still very much "beta", but also very useful! My "main" 650 is running since more than a year with this.

 

[Joopmac]

Will be really nice!! is this 1280x1024 supported? What kind of output connector is it real HDMI?

I want to run in my duo Dock or 650/700

 

[Jockelill]

Will be really nice!! is this 1280x1024 supported? What kind of output connector is it real HDMI?

I want to run in my duo Dock or 650/700

Yes, it’s a real HDMI and it does 1280x1024 in 32 bit color. With The duo dock I had some issues, let me pull mine out and test again, in 700/650 it works without any issues (other than the bugs mention by Melkhior)

 

[olePigeon]

@Jockelill Any idea if it'll eventually support 8- & 4-bit color and B&W?

 

[zigzagjoe]

@Jockelill Any idea if it'll eventually support 8- & 4-bit color and B&W?

All of @Melkhior's FPGA platforms supports 1/2/4/16/32 bits-per-pixel. I traded @Jockelill for a QuadraFPGA (040 PDS version) which works quite nicely on the fast 040 bus. 33mhz is the max system clock supported currently, it will not work at 40.

 

[Jockelill]

@Jockelill Any idea if it'll eventually support 8- & 4-bit color and B&W?

This is basically all that is supported. The first occurrence of each resolution will give you a window boxed (it’s running 1080p then), the second is “true” resolution.

Two known bugs:
* Sometimes the lower resolutions are not perfectly centered. If you change to another resolution this usually fixes the problem.

*Sometimes the screen goes black when you change to 640x480. Restart is only solution. I’m guessing this issue is only related to my monitor.

 

[jajan547]

View attachment 80973View attachment 80974


This is basically all that is supported. The first occurrence of each resolution will give you a window boxed (it’s running 1080p then), the second is “true” resolution.

Two known bugs:
* Sometimes the lower resolutions are not perfectly centered. If you change to another resolution this usually fixes the problem.

*Sometimes the screen goes black when you change to 640x480. Restart is only solution. I’m guessing this issue is only related to my monitor.

This is awesome @Jockelill, following to see how it goes.

 

[eharmon]

Those are awesome, but eyewateringly expensive with the FPGA board.

I've wondered for a bit how bad a dumb framebuffer dumping to HDMI with a bare metal Pi would be as a low-cost solution?

Basically take RGBtoHDMI and modify to bang NuBus with a level shifter just enough to map framebuffer memory for the HDMI side to consume. You could build a board + pi for $40, theoretically.

Maybe it's stupid. Obviously no acceleration with a really basic solution, too.

 

[uyjulian]

I wonder if it is possible to do host-side framebuffer memory instead of needing to map the whole framebuffer memory over nubus, then transfer damaged regions to nubus as needed. Could possibly reduce requirements for the nubus side of things in that manner

 

[eharmon]

I wonder if it is possible to do host-side framebuffer memory instead of needing to map the whole framebuffer memory over nubus, then transfer damaged regions to nubus as needed. Could possibly reduce requirements for the nubus side of things in that manner

You're basically describing QuickDraw acceleration .

(It's reversed though: the card maintains a framebuffer and the host publishes updates like "scroll this region 10 pixels left".)

 

[zigzagjoe]

Those are awesome, but eyewateringly expensive with the FPGA board.

I've wondered for a bit how bad a dumb framebuffer dumping to HDMI with a bare metal Pi would be as a low-cost solution?

Basically take RGBtoHDMI and modify to bang NuBus with a level shifter just enough to map framebuffer memory for the HDMI side to consume. You could build a board + pi for $40, theoretically.

Maybe it's stupid. Obviously no acceleration with a really basic solution, too.

Not quite that easy. Lack of IO and RAM to use as a frame buffer is a major stumbling block, further complicated by nubus being fast enough to be annoying. Definitely won't be bit banging it easily.

Using a more reasonably sized FPGA is probably the best path forward along with compromise on goals, like dropping 1080p.

I wonder if it is possible to do host-side framebuffer memory instead of needing to map the whole framebuffer memory over nubus, then transfer damaged regions to nubus as needed. Could possibly reduce requirements for the nubus side of things in that manner

No way to get notified of screen updates in anything resembling a graceful manner. The mac vnc server ends up hashing each line, and the scsi video cards just always blast the entire frame buffer over scsi. It's terrible at 640x480 and only gets exponentially worse at higher bitdepths/resolutions.

 

[eharmon]

Not quite that easy. Lack of IO and RAM to use as a frame buffer is a major stumbling block, further complicated by nubus being fast enough to be annoying. Definitely won't be bit banging it easily.

I would have thought that at first but the PiStorm manages to bang the 68k bus at a pretty high freq. For memory constraints are you thinking about a pico? I’m thinking more along the lines of a zero 2.

 

[zigzagjoe]

I would have thought that at first but the PiStorm manages to bang the 68k bus at a pretty high freq. For memory constraints are you thinking about a pico? I’m thinking more along the lines of a zero 2.

Ah. I was thinking RGB2HDMI which uses a Pico. Pistorm uses a large CPLD/small FPGA to handle all the timing-sensitive bits, an approach like that would be needed here. Not my cup of tea but it is a potentially workable approach.

 

[eharmon]

Ah. I was thinking RGB2HDMI which uses a Pico. Pistorm uses a large CPLD/small FPGA to handle all the timing-sensitive bits, an approach like that would be needed here. Not my cup of tea but it is a potentially workable approach.

It’s so confusing…I constantly search the wrong one.

Normally I hate a full Pi for this sort of thing but I’ve been convinced by bare metal boot times being reasonable.

 

[Melkhior]

Bit-banging NuBus might be possible, but stuff from that era are already somewhat fast and sensitive to timings. Using dedicated hardware through a FPGA or CPLD is likely to be a lot easier and much more reliable. One in a billion cycles with the wrong timings is already a crashing error every few minutes or so for NuBus...

@uyjulian NuBus is way too slow to transfer video data reliably for display, unless using very low resolution. Even 640x480@256 colors is nearly 20 MiB/s of read bandwidth from the video-storing RAM to the DAC. That's why all NuBus devices have local memory for the framebuffer, and why vampire videos were slowing the system down measurably.

@zigzagjoe Yep, a cheaper FPGA would do the tricks, provided (a) it can have "fast enough" memory for the target resolution/depth (b) it can do 3.3V signaling (which with newer FPGA isn't a given) to avoid complex/slow level shifting solution (b) it can do TMDS signaling to support HDMI without too many tricks. The issues are that you either need a FPGA board with enough I/O pins and the appropriate memory, or you need a the skill to design a NuBus board with the FPGA integrated - and that will be 6+ layers so quite expensive...

If someoe really wanted to think about a cheaper version, a Spartan-7 with DDR2 is likely enough (giving up on acceleration) to get up to Full HD @ 256 colors, with Millions at 800x600 or less (targeting 120-150 MB/s usable for the FB and at least double for the raw bandwidth, so cheap 16-bits DDR2 @ 150-200 MHz would already be more than enough). Using something other than a Spartan-7 or Artix-7 will require a lot more changes to the gateware (the clock in particular are highly device-dependent, in particular when changed on the fly to support alternate resolutions). Beware than HDMI uses few I/O pins (but at high speed), and that using an analog output instead (such as VGA) would require a lot more pins to the external DAC (and those aren't cheap when using a proper one).

 

[uyjulian]

I was thinking about a hybrid/bridged system. Maybe a CPLD/FPGA that has Nubus and just enough RAM to saturate transfer bandwidth as a bounce buffer, then one of e.g. PCIe/USB3.0/CSI output, then interface with maybe a Raspberry Pi CM4 or CM5 which can interface with PCIe and also output through HDMI. The main framebuffer would be on the Pi instead of the CPLD/FPGA side, which would only use the RAM for transfer purposes. This should allow even dual 4K HDMI display output without needing to use a higher speced FPGA.

Also with MMU for situations with host memory access is needed it could be possible to detect that e.g. map a page as r-x, on fault, sync last page, set it as r-x, then map the new page as rwx. On vsync set all pages to r-x and sync last modified one.

 

[eharmon]

Yeah, that's basically how PiStorm is setup, and you're right without the CPLD or FPGA for the bus, NuBus is probably tight at 10MHz...I forget that's slow but not THAT slow. RGBtoHDMI gets away with banging digital RGB since it's slow...but even the non-CPLD versions of those struggle with timing.

It'd be fun if they made a Zero with a RP2350 on board. Mostly because I'd love to play with PIO for something like this, while having the full ARM core for managing output.