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

[Trash80toHP_Mini]

Some folks have been wondering about what I've been posting a related thread over on TD. I've been using that as a Development Notebook, so here goes the first release of the project:

Developing a carrier board to interface with the first gen Radius FPD/SE's four VRAM Chips. They'll be de-soldered and then inserted into wire wrap sockets installed in their place. From those pins, wire wrap makes all the connections on this prototype carrier board. Ask about details if interested. Right now I'm wondering if anyone can decipher the two approaches to Pi GPIO input I'm aiming to do from these flow chart diagrams:

First, I need to determine in what order the data lines need to be hooked up to GPIO so the 16bit word (register/whatever) makes sense. So attempting to use parallel inputs as a sort of logic analyzer setup to determine ordering of the sixteen lines in the first step:



When I can figure out which lines need to be hooked up to which pins on the DeMux IC and then switched to outputs leading into the PISO chip it will convert the sixteen parallel inputs to a single serial input and on to a single GPIO pin of the Pi Zero 2 W.



So the overall, inscrutable carrier board logic flow chart/diagram looks like this . . . craziest pic for last:



Assumption is that things like CAS, RAS and other signals on the VRAM will need to head into the Pi GPIO pins at some point? Serial input on a single line frees up 15 GPIO inputs for such fun and games!

Please comment on this:
- does the visual presentation make any kind of sense?
- If so, does my approach to the data line ordering problem make any kind of sense?
- traditional schematic development will be notated one wire wrap connection at a time . . . it's a prototype!

Aim at the moment is to get the same image output via Pi's HDMI output as I get from the Card itself, comparing one screen to the other. After that, image rotation will be simple enough, if slow with dropped frames on Pi. Project is aimed at implementation in FPGA and eventual cloning of the card therein. Titans of FPGA development have said "the project seems 100% viable."

So I'll need a lot of of help . . .

 

[joevt]

Radius FPD/SE is 640x864, 1 bit per pixel, 51 MHz pixel clock. Is that correct, or near correct?

Are you capturing writes to VRAM, or reads from VRAM? Are you capturing reads from CPU or the reads from the display output side?
You said "VRAM input" so that probably means you are capturing writes to VRAM.

Why not capture the stream from the display output side? You wouldn't need a PISO in that case. How fast can the Pi GPIO serial input be?

Maybe you are capturing writes to VRAM to save processing time? How fast can writes to VRAM happen? The Radius FPD/SE is a PDS card so the writes are probably CPU bound and also not limited by a slower bus such as NuBus.

Does the card have any acceleration? If it did, then there would be writes from the card's controller.

For the visual presentation, you could make more clear that the 16-bit 1-2 Demux is controlled by the Serial/Parallel GPIO switch.

 

[joevt]

Explain why there's only 8 address lines?
640x864 1bpp = 69120 bytes.

Does the display have 1024x864 hardware panning?
1024x864 1bpp = 110592 byte.

What does VRAM 4x64 mean? You have a photo of the Radius FPD/SE at:
https://tinkerdifferent.com/threads/radius-macintosh-se-full-page-display-pictures.4893/
Are those NEC D41264C-12 DRAM chips?
64Kbits x 4 = 256 Kbits.
256Kb x 4 = 128 KB which is the minimum required for 640x864 and 1024x864 1bpp.

The datasheet for the D41264C shows 8 address lines. I guess they're used for both column and row select to address the full range.
The datasheet shows 256 rows, 1024 columns (256x4). That fully utilizes the 8 address bits (2^8 = 256) for both row and column select.

The -12 in the part number means 120ns which is the row access time. The serial access time is 40ns.

 

[Trash80toHP_Mini]

Radius FPD/SE is 640x864, 1 bit per pixel, 51 MHz pixel clock. Is that correct, or near correct?

Close enough I guess?

Are you capturing writes to VRAM, or reads from VRAM? Are you capturing reads from CPU or the reads from the display output side?
You said "VRAM input" so that probably means you are capturing writes to VRAM.

Capturing full Page Buffer from Data Inputs to VRAM.

Why not capture the stream from the display output side? You wouldn't need a PISO in that case. How fast can the Pi GPIO serial input be?

Output side's wonky, Page Buffer capture from VRAM input keeps everything in the digital realm for output via HDMI->DVI conversion pigtail connection to obsolete Displays lacking HDMI inputs.

Maybe you are capturing writes to VRAM to save processing time? How fast can writes to VRAM happen? The Radius FPD/SE is a PDS card so the writes are probably CPU bound and also not limited by a slower bus such as NuBus.

Dunno, 16bit at 8MHz PDS vs 32Bit Nubus at 10MHz seems close to a wash to me?

Does the card have any acceleration? If it did, then there would be writes from the card's controller.

No acceleration in first gen VidCards for the B&W only Compacts, so no worries.

For the visual presentation, you could make more clear that the 16-bit 1-2 Demux is controlled by the Serial/Parallel GPIO switch.

Nap, simple three header jumper selection does the down and dirty in hardware, no Pi involvement whatsoever. KISS!


edit: one program on the Pi will determine data line load order from parallel inputs. After that everything goes thru the SIPO to free up 15 GPIO Lines for fun & games.

 

[Trash80toHP_Mini]

Explain why there's only 8 address lines?
640x864 1bpp = 69120 bytes.

That's from the VRAM pinout, board buzzing looks like this:




Craziness at bottom in purple/green drove me nuts until I realized the VRAM ICs were "upside down" and addressing on lines above became clear thereafter.

Does the display have 1024x864 hardware panning?

1024x864 1bpp = 110592 byte.

Display's a solid 864x640, no panning involved. @trag ran the numbers and VRAM on board has more than enough capacity to store the entire frame buffer. VRAM overage would be a function of getting enough space to do the job.

What does VRAM 4x64 mean? You have a photo of the Radius FPD/SE at:
https://tinkerdifferent.com/threads/radius-macintosh-se-full-page-display-pictures.4893/

Here's a much better pic:

Are those NEC D41264C-12 DRAM chips?
64Kbits x 4 = 256 Kbits.
256Kb x 4 = 128 KB which is the minimum required for 640x864 and 1024x864 1bpp.

The datasheet for the D41264C shows 8 address lines. I guess they're used for both column and row select to address the full range.
The datasheet shows 256 rows, 1024 columns (256x4). That fully utilizes the 8 address bits (2^8 = 256) for both row and column select.

The -12 in the part number means 120ns which is the row access time. The serial access time is 40ns.

Yep, all of the above, but there are CAS and RAS pins on the chips, dunno how they might be involved?

Figuring writes to VRAM would be the wedge I need to crack this wide open? In the eventual FPGA iteration, the inputs will be double buffered in FPGA, so lag time should be limited to just one screen draw period. When that part's done, the FPGA will swallow the rest of the card whole.

 

[Trash80toHP_Mini]

Here's where I made my breakthru. None of the SBC based VGA boards are up to doing image rotation, so I came up with this plan:



Zero 2 W will almost certainly be too slow to do rotation in real time. A low end Pi 5 CPU is Quad Core and 4.4x faster than the Zero's Single Core, so it just might do the job? After that, FPGA will do it easily in real time.

At present, determining the data line load order for PISO input would be the goal.

 

[joevt]

Close enough I guess?

Ok, between 51.270 MHz and 57.283 MHz.

Output side's wonky, Page Buffer capture from VRAM input keeps everything in the digital realm for output via HDMI->DVI conversion pigtail connection to obsolete Displays lacking HDMI inputs.

HDMI->DVI is a nothing burger. Same pins. Same signals.

For the Output side, you have the serial read port of the VRAM which is probably what gets used for the display output (and also for DRAM refresh?). Those are digital.
57.283 MHz / 16 = 3.5801875 MHz = 279 ns. Could the Pi handle that?

Dunno, 16bit at 8MHz PDS vs 32Bit Nubus at 10MHz seems close to a wash to me?

8 MHz is 125 ns. So it might be better to read from the serial read port of the VRAM?

How fast can the SE write a line of pixels? The 68K MOVEM instruction can do half a scan line (320 pixels) using 10 registers. 4 cycles per register is 2 MHz or 500 ns. A normal MOVE instruction is 12 cycles.
So it might be better to read from VRAM input (as you have currently planned) if you can't handle 3.5801875 MHz from the serial read port.

With serial read port you might take advantage of the fact that the bits are read in order from left to right, top to bottom, where as VRAM input is random access.

Nap, simple three header jumper selection does the down and dirty in hardware, no Pi involvement whatsoever. KISS!

I didn't mean that the PI was involved. I meant that the three header jumper is used to tell the DeMux where to send the 16 bits.

That's from the VRAM pinout, board buzzing looks like this:

I don't understand why S0 on the 4 chips would be tied together. I would double check that.

Here's a much better pic:

That is indeed a much better picture.

Yep, all of the above, but there are CAS and RAS pins on the chips, dunno how they might be involved?

Each VRAM chip addresses 64K of data that is 4 bits wide. addressing 64K of anything requires 16 address bits but the chip only has 8 address bits. The address is divided between rows and columns. When /RAS goes low (falling edge), the 8 address bits select a row. When /CAS goes low, the 8 address bits select a column in the row. A column is 4 bits wide. A row is 256 columns, 1024 bits total.

The timing diagrams show the different types of accesses. You can access multiple columns in a row without having to update the row address (i.e. every /CAS does not need to be preceded by a /RAS).

Figuring writes to VRAM would be the wedge I need to crack this wide open? In the eventual FPGA iteration, the inputs will be double buffered in FPGA, so lag time should be limited to just one screen draw period. When that part's done, the FPGA will swallow the rest of the card whole.

I guess you need to be able to capture the info described by the writing timing diagrams. It appears that you can capture write data when /WB/WE goes low with a few exceptions:
- Hidden Refresh cycle: when /CAS is low
- Page Read Cycle: when /RAS is low (except this looks a lot like the Page Early and Late Write cycles and Page Read-Modify-Write cycle ...)
I guess you need to find out if those exceptions happen in order to decide if you need to detect them.

The datasheet describes each cycle type. The description for a cycle type should explain how to detect that cycle type if the timing diagram doesn't make that clear enough.

Here's where I made my breakthru. None of the SBC based VGA boards are up to doing image rotation, so I came up with this plan:

Zero 2 W will almost certainly be too slow to do rotation in real time. A low end Pi 5 CPU is Quad Core and 4.4x faster than the Zero's Single Core, so it just might do the job? After that, FPGA will do it easily in real time.

At present, determining the data line load order for PISO input would be the goal.

First need to worry about if the Zero 2 W is fast enough to read the row and column and data of every write cycle.