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

[YMK]

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]

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

 

[joevt]

Does the Radius FPD/SE provide a vertical blanking interrupt?

 

[Trash80toG4]

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:

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

 

[Trash80toG4]

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.

Hoping it will. Thinking at work today, I've decided to map the card from the PDS connector on the MagicBus Card, pretending that four row monstrosity is not even there. So I'll be modeling FPGA Card V.1 and markup/schematic takeoff will be a lot simpler task. Also will breakout any PDS signals the MagicBus connector doesn't feed their VidCards.

Dunno if I'll have time to do anything on that after work, gotta pack for the road trip.

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?

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?

Yep, equivalent of VRAM page buffer inputs will be in the FPGA. If anything else is required, the full PDS bus is available.

Using the Pi to capture the data might be more fun.

Still well outta my wheelhouse, I've had the CM4 setup on hand for over two years and haven't fired it up yet. I've had an OrangePi sitting here in another project box for going on 20 years!

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

Hoping to put off learning oscilloscope/electronics until retirement. This stuff is all just electron plumbing to me.

 

[Trash80toG4]

The CPU addresses the VRAM in a linear, 1D address space. The VRAM controller breaks that down into 2D (row/column) address space, just like a DRAM controller does. The CPU needs direct R/W access to the framebuffer, or operations like scrolling wouldn't be possible.

Don't understand why feedback is required for scrolling, pointer movement and such. CPU knows it's scrolling and feeds the next frame to VRAM accordingly, no?

 

[YMK]

Don't understand why feedback is required for scrolling, pointer movement and such. CPU knows it's scrolling and feeds the next frame to VRAM accordingly, no?

No. CPU reads a section of already drawn VRAM and writes it elsewhere to scroll. Outside of full screen games, the CPU rarely feeds entire frames to VRAM, just incremental updates.

If you're not cloning the card, then I'd leave the card entirely stock and put the FPGA right on the system bus. From there, you can passively snoop on all of the traffic going to and from the card, including the entire framebuffer.

If you choose to intercept or replace VRAM traffic at the GAL, you also have to produce what's in VRAM when the CPU demands it. That's much more difficult.

 

[Trash80toG4]

Incremental updates I understand, Data in VRAM iis refreshed when it's accessed, so it remains the same until actively changed by the CPU and not everything needs to be changed for every frame. CPU reading data back from VRAM makes no sense at all to me, by what mechanism is that accomplished?

Looks like I'll be buzzing the board and doing a schematic of the front end before anything else just to see what's what.


So it goes . . .

 

[joevt]

Incremental updates I understand, Data in VRAM iis refreshed when it's accessed, so it remains the same until actively changed by the CPU and not everything needs to be changed for every frame. CPU reading data back from VRAM makes no sense at all to me, by what mechanism is that accomplished?

Looks like I'll be buzzing the board and doing a schematic of the front end before anything else just to see what's what.

The CPU is a 68K CPU. QuickDraw will use 68K CPU instructions such as MOVE or MOVEM to read and write pixels from and to VRAM for scrolling, or for drawing icons or windows and the mouse cursor.

Are you thinking that the Mac has a framebuffer that is separate from the framebuffer of the Radius FPD/SE? You can test this by breaking one of the data bits of the VRAM and reading from the framebuffer in MacsBug or in a test program.

 

[YMK]

CPU reading data back from VRAM makes no sense at all to me, by what mechanism is that accomplished?

Pretty much the same way it reads back from DRAM. The CPU requests a read, then the controller breaks the address up into rows and columns, and completes the transaction.

VRAM is DRAM with some extra signals to handle the functions of the serial interface. Note that it's possible to read and write from either interface, though on most video cards, the serial end is only read from:

 

[Trash80toG4]

Got it, comparison to simple DRAM shook something loose in my noggin, thanks

Looking into switching gears to capture serial output of frame redraw to "Back End" of the card. Same carrier board, whole new approach to VRAM I/O. Heading out of town, will be doing my doodling in #2 pencil on paper for a few days.

 

[Trash80toG4]

Clean slate.

So it goes . . .