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

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.
 
Trash80toG4 said:
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.
Click to expand...
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?

Trash80toG4 said:
VRAM ICs will be pulled from their sockets in the final stages.
Click to expand...
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?

Trash80toG4 said:
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.
Click to expand...
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
 
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
 
joevt said:
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.
Click to expand...
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.

joevt said:
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?
Click to expand...
Yep, equivalent of VRAM page buffer inputs will be in the FPGA. If anything else is required, the full PDS bus is available.

joevt said:
Using the Pi to capture the data might be more fun.
Click to expand...
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!

joevt said:
I bought one of these but never got around to using it:
https://www.picotech.com/products/oscilloscope
Click to expand...
Hoping to put off learning oscilloscope/electronics until retirement. This stuff is all just electron plumbing to me.
 
Last edited:
YMK said:
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.
Click to expand...
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?
 
Trash80toG4 said:
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?
Click to expand...

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.
 
Last edited:
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. :oops:


So it goes . . .
 
Trash80toG4 said:
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. :oops:
Click to expand...
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.
 
Trash80toG4 said:
CPU reading data back from VRAM makes no sense at all to me, by what mechanism is that accomplished?
Click to expand...

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:

1783230520870.png
 
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.
 
joevt said:
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.
Click to expand...
Disconnecting data bits is one way to determine order of the bits.
We know the order of the bits as seen by the Mac CPU side: big endian with the most significant bit being the left most pixel.
Disconnect a bit on the VRAM. Try to set or clear all the bits. Read back the result. The stuck bit is the bit that was disconnected.
 
Not even close to that yet, running out of town for a bit. Knocked together PDF 14 and attached it above, heading all serial related lines toward Pi rather than VRAM input lines, going with alternate approach you guys suggested upthread.


edit: looks like tags are a pin too high on the right side of the VRAM chip. OOPSIE!
 
I didn't suggest doing that. The serial lines are probably the most difficult place to get anything meaningful.

The serialized raster output (one line) might be combined with a pixel clock as a SPI input that you can capture with a Pi.

Still, the system bus is probably easiest and won't disrupt the card's operation or require modifying it.
 
Dang, jumped the gun again and in the wrong direction. Got a few days out of town. Guess I'll be buzzing out the entire front end of the card before looking into anything else?

I'm trying to eliminate the card entirely as the final step in FPGA development. Treating the front end like it's the only thing in existence would be the way to proceed, however which way we go.

At that point build as little of the card as possible on a stock SE PDS card with Pi of some kind.
Then go to FPGA in its place if that works out?

After that's up and running we (read someone competent) cram the balance of the card into FPGA.
 
NEW APPROACH ____________________________________________________

A straight up 1:1 clone of the FPD card in wire wrap in the form factor of a standard SE PDS Card is what I'll start doing. Documenting the schematic one wrap at a time.

- cloning the card is pointless, even though it's the only card capable of being cloned
- without development of image rotation capability a clone would be worthless
- during schematic capture we may discover where to stop somewhere between VRAM and output connector?

Worst possible scenario from my point of view would be having an FPGA Development Board installed on a full !:1 clone with just the cable inputs connected to it for rotation transform and output on its HDMI Connector.

Could do that in an external adapter, but there aren't enough boards in the wild to bother with and the price point for those would then go up anyway. So it's on to cloning the card 1:1 as the only way I can go. That I can manage to do. Hopefully schematic development during the build will give you enough information to tell me where I might be able to stop!

Full PDS will be hooked up to the FPGA for some master of this little retro-verse to build the Radius16 Accelerator into it! :sneaky:
 
No reason for it to be done in software and every reason to keep it in hardware. The card's a bog simple hardware/driver setup.

Currently looking at VRAM Data -> GAL setup, If it all lines up the way it appears to at first glance, reading output from the four matching GALSs ought to be more straightforward than my VRAM input (or output) approach.

If monitoring GALs turns out to be the way to go, carrier board would plug into those sockets with GALs installed in sockets on carrier. KISS! :)

Also breaking MagicBus Card connections out to a full SE PDS to see what's going on.
 
You must log in or register to reply here.
Top Bottom
Back