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. I'm sidestepping rotation entirely until un-rotated FPGA V.1 works out. At that point we roll rotation into FPGA hardware.

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!

 

[YMK]

Will that help in figuring out data input order for the Page Buffer?

It seems a lot easier to just dump the framebuffer on the Mac side and examine its contents.

 

[Trash80toG4]

Interesting, but the Page Buffer is built up in VRAM sequentially in alternating cycles split with other CPU activity. AFAIK it never exists as a whole on the system board, that's what VRAM is for after all. Not sure you'd be able to capture the Page Buffer from a Vampire Video subsystem on the logic board either. The same limitation would apply there as well, no? In IIsi/IIci, I'd put money on the CPU/Video Subsystem flushing page buffer segments into RAMDAC as quickly as possible before the entire buffer is loaded anywhere.

Picking the signals up from CPU writes to the Page Buffer in VRAM would seem to be the only available wedge to my way of thinking.

 

[YMK]

Interesting, but the Page Buffer is built up in VRAM sequentially in alternating cycles split with other CPU activity. AFAIK it never exists as a whole on the system board, that's what VRAM is for after all.

Unless this card is doing something strange, the framebuffer in VRAM should be mapped to some segment of address space.

The order and timing of the access doesn't matter. The picture persists in VRAM for as long as it's on the screen. Writing it out serially to the RAMDAC isn't destructive.

 

[Trash80toG4]

Unless this card is doing something strange, the framebuffer in VRAM should be mapped to some segment of address space.

Yep it's mapped to the PDS Slot's address space, but the buffer data will be in VRAM and inaccessible to the CPU for all practical purposes, no? VRAM outputs don't head back to the CPU, no need for that at all on a VidCard.

The order and timing of the access doesn't matter. The picture persists in VRAM for as long as it's on the screen. Writing it out serially to the RAMDAC isn't destructive.

Indeed, I just grayed out the extraneous bit about Vampire Video and RAMDAC. It was a silly parallel to draw for the sake of discussion, way OT. Sorry about the unfortunate tangential interruption.

I've got the address lines heading into Pi in case they're needed for determining bit order of the words as they're fed into VRAM. By the time this goes to FPGA, address lines will be extraneous. The structure of input data captured stands on its own once deciphered. At this point everything boils down to figuring which data bit of the word goes where on the input legs of the PISO IC. After that figuring which word lands where on the display will be loads of fun.

 

[YMK]

It's mapped to the PDS Slot's address space, but the buffer data will be in VRAM and inaccessible to the CPU for all practical purposes, no?

No, the whole point of VRAM is it presents a flat, linear, highly-available window of memory to the CPU.

The details of juggling bus access and timing are handled by chips like GLUE, MEMCjr, ect and are hidden from the CPU.

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.

You should be able to poke at that window with MacsBug and put pixels on the screen.

 

[Trash80toG4]

COOL! Didn't know that'd be possible. I've been wondering about doing something on the order of a MacPaint program with a full screen 864x640 canvas to play around with mapping pixels. Doing it visually, comparing baseline screen output with what the Pi is doing might be fun for a bit and then really tedious. MacsBug seems like it may be worse?

Visions of Joshua playing tic-tac-toe at warp speed won't let me quit wondering about detecting where the pixels fall in software?


edit: War Games movie reference, italics added.

 

[YMK]

COOL! Didn't know that'd be possible. I've been wondering about doing something on the order of a MacPaint program with a full screen 864x640 canvas to play around with mapping pixels.

You could do that. Plenty of full-screen games write to the FB directly for best performance, where the resolution and color depth is fixed.

In cloning a video card, the only things that matter are the format and address of the framebuffer and control registers (CPU interface) and the electrical and timing details of the output (monitor interface).

Everything in between is up to you and there's no need to duplicate the same VRAM timings or row/column addressing. You're not forced to use the same obsolete VRAMs.

If your FPGA of choice has enough internal RAM, you might do without any VRAMs at all. Your card might then offer zero-wait reads and writes with no contention, outperforming the original.

If you haven't already, running a tool like TattleTech or ROM Fiend on the card might tell you about supported modes, addresses, and formats.

 

[Trash80toG4]

Not cloning the card actually, just the first few parts of its front end that feed Page Buffer data input to FPGA in place of VRAM. No need for VRAM at all, just ROMs and probably that one GAL will be on the Rev.1 board as in the diagram above.

The point would be using the existing Radius drivers and DeclROM to have the CPU output the one single resolution available at the 1bit color level available to the inputs where VRAM would be on the original card. FPGA replaces VRAM entirely and takes it from there thru the IF/THEN rotation gating and out via HDMI/DVI/Whatever. As in your full screen gaming example, resolution and color depth are absolutely fixed at 864x640/1bit.

Thanks for the lead on ROM Fiend, I will absolutely be looking at that one.


edit; gonna be out of town for a few days and when I get back I have to get set up for testing the cards.