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 . . .
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 . . .
Last edited:
