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.