RP2040 replacement for IPC ?

[tofro]

It would be fairly simple to implement the Aurora or Q68 graphics in one - easier and cheaper than in an FPGA.

As for Q68 1024x768 highcolour graphics not only "not simple", but likely impossible. Certainly not enough on-chip RAM. Likely lack of bandwidth and too high latencies to an external CPU. Not even enough I/O pins for parallel CPU interface and VGA video DAC. As far as I see, only some relatively low bandwidth DVI stuff with the internal CPU.

Well, there are "graphics card" implementations using middle-tier µCs like the RP2040. But none of them is implementing externally accessible video RAM, simply because that's not exposeable on all of them µCs. Such implementations tend to expose a fast serial interface and graphics intrinsics like "draw a line", "draw a circle", "draw a character", "draw a sprite I previously uploaded". This works well when your OS that wants to do video output is prepared for such a video subsystem - QDOSMQ is not and unlikely to ever be.

[Dave]

I think you’d be surprised at the RP2040 and RP2350 PIO capabilities which include VGA and HDMI output. It has 520K of SRAM which can be expanded.

[tofro]

I think you’d be surprised at the RP2040 and RP2350 PIO capabilities which include VGA and HDMI output. It has 520K of SRAM which can be expanded.

All fine and dandy. But how do you fill that SRAM video memory? From a "QL"? My point is exactly that this SRAM is not accessible from the outside.

[pjw]

<>
Well, there are "graphics card" implementations using middle-tier µCs like the RP2040. But none of them is implementing externally accessible video RAM, simply because that's not exposeable on all of them µCs. Such implementations tend to expose a fast serial interface and graphics intrinsics like "draw a line", "draw a circle", "draw a character", "draw a sprite I previously uploaded". This works well when your OS that wants to do video output is prepared for such a video subsystem - QDOSMQ is not and unlikely to ever be.

But the simplest primitives like draw a block and scroll and pan should be possible. Isnt that what the emulators already do? The traps for (some of?) these operations on QPC2 appear to end in Windows calls, not mc68k code.

[tofro]

<>
Well, there are "graphics card" implementations using middle-tier µCs like the RP2040. But none of them is implementing externally accessible video RAM, simply because that's not exposeable on all of them µCs. Such implementations tend to expose a fast serial interface and graphics intrinsics like "draw a line", "draw a circle", "draw a character", "draw a sprite I previously uploaded". This works well when your OS that wants to do video output is prepared for such a video subsystem - QDOSMQ is not and unlikely to ever be.

But the simplest primitives like draw a block and scroll and pan should be possible. Isnt that what the emulators already do? The traps for (some of?) these operations on QPC2 appear to end in Windows calls, not mc68k code.

Well, you could map some of the screen traps to such graphics primitives. You'd also need to re-write stuff like PE and WMAN, sprite toolkits, SpeedScreen, even programs using custom fonts or loading screens would have to be modified (like, "LBYTES myScreen, 131072" wouldn't work anymore. Even XChange Quill uses direct access to screen memory and wouldn't work any more. There's just too many programs/toolkits that directly access screen memory.

BTW, most emulators I know, (and all of them I use) support direct screen memory access. They emulate video RAM and move the changed part to the host screen. You could try to do something similar, but for that the link to the "graphics card" is typically too slow (it would have to be in the MBits/s range, which a 68k simply can't sustain)

So, possible, like everything, but a lot of work.

[tofro]

<>
Well, there are "graphics card" implementations using middle-tier µCs like the RP2040. But none of them is implementing externally accessible video RAM, simply because that's not exposeable on all of them µCs. Such implementations tend to expose a fast serial interface and graphics intrinsics like "draw a line", "draw a circle", "draw a character", "draw a sprite I previously uploaded". This works well when your OS that wants to do video output is prepared for such a video subsystem - QDOSMQ is not and unlikely to ever be.

But the simplest primitives like draw a block and scroll and pan should be possible. Isnt that what the emulators already do? The traps for (some of?) these operations on QPC2 appear to end in Windows calls, not mc68k code.

Well, you could map some of the screen traps to such graphics primitives. You'd also need to re-write stuff like PE and WMAN, sprite toolkits, SpeedScreen, even programs using custom fonts or loading screens would have to be modified (like, "LBYTES myScreen, 131072" wouldn't work anymore. Even XChange Quill uses direct access to screen memory and wouldn't work any more. There's just too many programs/toolkits that directly access screen memory.

So, possible, like everything, but a lot of work.

[Peter]

I think you’d be surprised at the RP2040 and RP2350 PIO capabilities which include VGA and HDMI output. It has 520K of SRAM which can be expanded.

But it can not provide the necessary video RAM accessible from the 68K CPU - which is the very nature of Q68 graphics.

[Dave]

Funny thing: it absolutely can. Picos are routinely used as memory mapped frame buffers with video output. The output is run by a single PIO engine, not even using a core. The RP2350 has enough GPIO to create an 8 bit data port and 16 or 19 pin address port. Two interrupts can be configured on two more GPIOs to indicate read/write and device select. The code to latch and act on the data would be under 1K.

There are several open source frame buffer/video output packages. There are pre-made VGA and HDMI socks.

If you think the RP2350 doesn’t have the throughput you’d be surprised. I make ZuluSCSIs and they’re emulating SCSI at 18mbytes/sec. A good understanding of the PIO engines’ capabilities is critical to understanding whi the Pico isn’t just a microcontroller.

https://github.com/Memotech-Bill/pico-vga-framebuffer Is a good example but aimed at the RP2040 which has less SRAM and a slower clock.

[Peter]

Funny thing: it absolutely can.

No it can not. We were talking Q68 graphics.

Picos are routinely used as memory mapped frame buffers with video output.

Of course, but mapped to the ARM and not an external CPU, at least not at the required speed.

The RP2350 has enough GPIO to create an 8 bit data port and 16 or 19 pin address port.

Which is insufficient.

I make ZuluSCSIs and they’re emulating SCSI at 18mbytes/sec.

We are talking 160 MBytes/s.

It is amazing, what people squeeze out if these cheap microcontrollers, we have a great example in Oliver's RGB to VGA converter. But they also have their limits.

[Dave]

The RP2350 can pump out 2400Mbits/s+ using PIO to the HSTX interface with 0% CPU involvement or utilization. The B revision has more than enough GPIO with 48 available and three PIO engines that can access any/all of those pins in parallel and can do DMA accesses without CPU involvement. It has an onboard TDMS encoder specifically for digital video output. I have one here displaying 1024x768 4BPP as a terminal with a USB keyboard input and DVI over HDMI output with a 393K frame buffer leaving ~120k free. It would be quite simple to use a spare PIO to define a SRAM chip-style interface. With onboard 8301 register emulation/extension I'm sure it could do a number of low color hi res or hicolor medium res modes. While it is possible to add external RAM to the RP2350B, that RAM is much slower and more contended than the ten internal buckets.

It would also be possible to use the Pico 2350B as an onboard address decoder/ROM emulator that can map at 0x000000 and then map rom to )xA00000 or wherever after a period.

Playing 8042/8049 would be within scope for one Pico, video for one Pico and a decoder/ROM one Pico. Not bad for $5 in chips.

The RP2040 is a little underpowered and lacks the HSTX port, but the RP2350B is an excellent candidate. The big challenge is that using it well involves some pretty arcane Pico/C knowledge.