Page Buffer Capture from Radius FPD/SE VRAM Input - First baby step to cloning Card

YMK

Active Tinkerer
Nov 8, 2021
434
361
63
Oh I see. So the GAL is the CPU<->VRAM interface?

If that's the case, you're better off ditching the GAL and coupling the FPGA straight to the system bus with linear addressing.

The row/column interface on the VRAMs isn't just for framebuffer traffic to the CPU, but also for setting up serial output to the RAMDAC each scan line, which doesn't apply to your FPGA.
 

joevt

Tinkerer
Mar 5, 2023
321
127
43
So my question would be why we're examining the output side of things? Will that help in figuring out data input order for the Page Buffer?

Haven't been thinking about anything on the card past VRAM input. That'd be what I'm diverting into FPGA in the final round. Input's entirely between CPU and VRAM over PDS, no? In that case there should be no need to worry about putting GALs, Clocks or related output components into FPGA for cloning at all. The single GAL sitting between PDS, ROM/VRAM will almost certainly need to be in clone V.1 Thinking it'll look something like this, with VRAM data input signals fed straight into FPGA and just three components on board along with HDMI connector and voltage leveling.

Building the Page Buffer in Pi or FPGA is the only thing necessary for my purposes at this point. That's what the Pi Zero 2 W feasibility study would be about.
Random access input and the serial output are both 16 bits wide. Figuring out data order of one will determine the order of the other.

Can you map the PDS data lines to the VRAM input lines? That will tell you the order of the bits. But you said there's a GAL between the PDS and VRAM so probably not.

Serial output happens at 57M pixels/second * 1 cycle/16 pixels = 3.56 MHz. But it outputs pixels in order and there's probably only a single row/address select at the beginning of each line. The pixels are probably output in order from left to right, top to bottom. It might be simpler to handle that then the random access VRAM input.

The 68K CPU can write 32 bits in 8 cycles using the MOVEM instruction. 8M cycles/second x 32 pixels/8 cycles x 1 cycle/16 pixels = 2 MHz.
So random access input is always slower than serial output, but you need to calculate frame buffer position from the address each time.

Are you storing a copy of the 1bpp data on the Pi, or are you converting it to a different format before storing it on the Pi? Does the Pi have graphics acceleration to transform framebuffer data?

VRAM ICs will be pulled from their sockets in the final stages.
The Mac requires the VRAM to exist to do drawing on the screen (setting a single pixel requires reading 16 bits and changing one of the bits). You mean the VRAM will be replaced by an FPGA equivalent?

I'll need to order up that Digital Oscilloscope and learn how to use it? That'll be a much lower learning curve than trying to use Pi. I was planning to learn the Pi end of things during the process of wire wrapping the carrier prototype.
Using the Pi to capture the data might be more fun.

I bought one of these but never got around to using it:
https://www.picotech.com/products/oscilloscope
 

Trash80toG4

Active Tinkerer
Apr 1, 2022
1,393
457
83
Bermuda Triangle, NC USA
Just read my last and it was badly worded. Not cutting off discussion until testing is done, just saying my responses will be delayed and fewer while off to see the GRLF Don't get much time on the forums. Here's a better representation of Rev.1 in SE PDS Card form factor:

Re.1-SE_Format.jpg


Got ahead of myself a bit, still sleepy. V.1 would be the socketed GAL pull from original along with socketed ROMs. Also missing the HDMI or DVI connector