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.