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

[Trash80toG4]

Some folks have been wondering about what I've been posting in another thread I've been using as a Development Notebook, so here goes:

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 socketsinstalled in their place. 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:

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:



When I can figure out which lines need to be hooked up to which pins on the GPIO lines of the Pi Zero 2 W, I can then convert the sixteen parallel inputs to serial input on a single GPIO pin:



So the overall, inscrutable carrier board logic 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 problem make any kind of sense?
- traditional schematic development will be notated one wire wrap connection at a time.

Aim at the moment is to get the same image output via HDMI 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 . . .

 

[Trash80toG4]

Need some advice from you digital circuit design guys.

GPIO advice would be much appreciated as well. Will divining the load order of the Data lines be practical in the parallel input mode? They're related to the addressing inputs, but that seems like a lot more programming if possible at all.

Meanwhile, here's the image rotation setup that available VGA adapters seem to be incapable of handling:



If Zero 2 W is too slow to do rotation in real time, a low end Pi 5 CPU is Quad Core and 4.4x faster then Zero's Single Core.
After that, FPGA should do it easily. Double buffered, the lag time will be a single page buffer load/draw cycle.

 

[Trash80toG4]

I guess I should explain the point of the overly complicated wire wrap prototype. Aiming toward doing a PCB set up like so.

To run the adapter sans VRAM, only the sense line on the board's connector needs to be shorted. Likely will need to be shorted to run output from the connector/cable through the Extron Scaler to anyway.

Journey started in previous thread I began using as a development notebook.

https://tinkerdifferent.com/threads/radius-full-page-display-for-macintosh-512ke-plus-cloning-project-possibilities.4326/post-47960

 

[joevt]

I had some comments/questions in the corresponding 68kMLA thread but it's not been accessible the past couple of days...

I guess I'll re-ask one of the questions here. Why is SO0 of the 4 VRAM chips tied together?
https://tinkerdifferent.com/threads...cloning-project-possibilities.4326/post-48246
It's supposed to be an output.

 

[YMK]

What's the higher level description of what you're trying to do?

Get the card's framebuffer into the Pi, rotate it on the Pi and show it on the HDMI output?

 

[Trash80toG4]

I'll give it a shot:

That's pretty much it, butPi Zero 2 W will probably only do "every so often frames" which may or not be rotated. Pi 5 with 4x Cores/2.4x Clock might be able to do it?

Ultimate goal is taking the project to FPGA, much as in the PCB Representation I just did. In that full size flow chart, substitute FPGA for GPIO Header and that'd be about it for the first step. Next step will be socketing the rest of the logic and doing a schematic takeoff of the entire VidCard.

The Titans of FPGA were strongly recommending I put the GALs and logic into FPGA. I'd love the FPGA to swallow the card whole, but we all know that's far beyond my ken.

Stretch goal is to roll Radius FPD and Radius16 Accelerator together into FPGA. The Accelerator is also fairly low hanging fruit in the Cloning orchard. That combo was the dream machine of 1987 Desktop Publishing.

 

[Trash80toG4]

I guess I'll re-ask one of the questions here. Why is SO0 of the 4 VRAM chips tied together?

Bad news just got worse from the serial output point of view, but maybe a whole lot better from mine?

Pretty much verified the confusing first findings and buzzed out another mystery after poking at the lines you asked about. SOE is tied together as well! Guessed I'd be finding something like that to be the case. Read your question again at work tonight, thought about it and light bulb glowed dimly.

WAG would be that everything having to do with serial output is tied high or low to keep the lines from floating. There's no intelligence on the VidCard. Such would be required for requesting/interpreting/using serial outputs from VRAM, no? I have a feeling this board is about as simple as these things can get.

 

[YMK]

Unless you're doing bare metal on the Pi, I doubt it would be a good stand-in for an FPGA.

If the goal was just to capture the framebuffer, I'd try to do it from the serial end as a SPI input.

Are the pin 5s on the VRAMs also tied together?

 

[Trash80toG4]

Pi Zero's been approved as a good proof of concept platform.
Just checked, Pin 5 is a data line and not tied together. Wouldn't expect them to be. Haven't looked at data lines yet, why do you ask?

As a first step, I want to use Pi in parallel input mode to sort out data line load order for PISO. Then switch to serial input for Pi. I'm an utter n00b in that element, I see GPIO lines 7-11 noted as SPI, which one might be best and why?

 

[YMK]

Just checked, Pin 5 is a data line and not tied together. Haven't looked at the four data lines yet, why do you ask?

I assume it's the random access counterpart to SO0?

 

[joevt]

Pretty much verified the confusing first findings and buzzed out another mystery after poking at the lines you asked about. SOE is tied together as well! Guessed I'd be finding something like that to be the case. Read your question again at work tonight, thought about it and light bulb glowed dimly.

WAG would be that everything having to do with serial output is tied high or low to keep the lines from floating. There's no intelligence on the VidCard. Such would be required for requesting/interpreting/using serial outputs from VRAM, no? I have a feeling this board is about as simple as these things can get.

I expect SOE to be tied together - that's an input.
SO0 - SO3 are outputs and are probably used for the output raster. That's how most VRAM works - there's a random access port from the CPU and a serial read port for rasterizing. Or do you think rasterizing is using normal read cycles interleaved between CPU read/write cycles like the Apple II?

I think we need more than a buzzing out.
Can you see the traces?
Use a digital oscilloscope (or your Pi) to see if all the SO0 outputs are always the same?

 

[Trash80toG4]

Can't see the traces yet. I need to test this card, the one I got recently was listed as tested good and will be set up first with output running through the Extron Scaler. Then on to the original board. After it tests good, I'll be de-soldering VRAM. I'll get a good pic of the traces under there before installing Wire Wrap Sockets.

I hadn't figured on looking at the output side of things other than comparing screens while noodling out VRAM load order. Guessing that mapping connections between VRAM and GALs might tell the tale? I can whip that up in AI and develop a schematic if we need to look at output.

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.

VRAM ICs will be pulled from their sockets in the final stages. If Zero can't handle putting every Nth, un-rotated frame onscreen, heading into more horsepower in Pi5 might be the next step? Rotation waits for FPGA to do the IF/THEN table rotation in gates rather than in software. Sidestepping rotation entirely until un-rotated FPGA V.1 works out. At that point we roll the rotation mechanism into FPGA.

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.







edit: Clone V.1 will be in standard SE PDS Card configuration with all lines heading into FPGA. MagicBus is a large sub-set of PDS. When that's working, someone even crazier than I am will have to take a look at implementing the Radius 16 Accelerator in the FPGA!