Page Buffer Capture from Radius FPD/SE VRAM Input - First baby step to cloning Card
- Thread starter Trash80toG4
- Start date
I doubt RGBtoHDMI has the horsepower to do my rotation transform in real time. Started looking at this one:
RGBtoHDMI - 6-bit TTL Edition - TexElec
The RGBtoHDMI is an excellent open project created by Hoglet67 (David Banks) and IanB (Ian Bradbury). The purpose of the RGBtoHDMI is to convert many different TTL and analog video signals from vintage systems to a modern HDMI or DVI compatible output. It uses a Raspberry Pi Zero along with a...
texelec.com
Moved on to FPGA for speed and flexibility for future development.
Last edited:
21:45 "It's literally outputting scanlines less wide than they are tall."
That means there's no rotation.
That means there's no rotation.
I suppose one could take a video of the display to see if the raster is horizontal or not.
It must be horizontal according to the timing info posted at
https://68kmla.org/bb/threads/page-...t-baby-step-to-cloning-card.52646/post-594899
57.283 MHz = 17.4571862 ns
68.85 kHz = 14524.3282 ns
75 Hz = 13333333.3 ns
width = 14524.3282 / 17.4571862 = 832 pixels. (less than the active vertical height of 864 lines so this must be horizontal)
height = 13333333.3 / 14524.3282 = 918 lines.
Last edited:
The image scans as I've illustrated it.
from start, scans across 640 pixels, doubles back, drops one row . . . repeats 800+ times.
RGBtoHDMI centers the output mid-screen just as does my Extron Scaler. Neither setup supports rotation to get practical use of FPD 640x800+ output.
from start, scans across 640 pixels, doubles back, drops one row . . . repeats 800+ times.
RGBtoHDMI centers the output mid-screen just as does my Extron Scaler. Neither setup supports rotation to get practical use of FPD 640x800+ output.
832 pixels wide = Front Porch (x pixels) - 640 Pixels - Back Porch (y pixels)
918 Lines = Vertical Start Blank (x lines) - 864 Lines - Vertical End Blank (y lines)
edit:
Last edited:
It's exactly the same as a horizontal scanline 640x480 display. But has 384 additional scanlines making it 640x864
Handy screenshot!
Handy screenshot!
Last edited:
Up until my last post, you were convinced the card performed rotation in hardware, and were ready to tear into your card under that assumption.
This is why I suggested dumping the frame buffer. If you get into the weeds without a high-level understanding of what's going on, you'll go down some expensive and tedious dead ends.
Rotation of a ~70KB frame buffer is trivial for even the slowest of PIs, but it's awkward to do in hardware. 1-bit graphics, VRAM serial data and monitor rasters are all row (not column) oriented.
This is why I suggested dumping the frame buffer. If you get into the weeds without a high-level understanding of what's going on, you'll go down some expensive and tedious dead ends.
Rotation of a ~70KB frame buffer is trivial for even the slowest of PIs, but it's awkward to do in hardware. 1-bit graphics, VRAM serial data and monitor rasters are all row (not column) oriented.
Last edited:
No, I've been saying all along that the card performs no rotation at all. It builds a standard horizontal scan 640x864 image that needs to be rotated to be useful on the target displays.
At present, there are no solutions for rotating the image outside of very high end systems. cloning with built-in rotation is the only option.
At present, there are no solutions for rotating the image outside of very high end systems. cloning with built-in rotation is the only option.
Ok, so what you want to build is not a faithful reproduction of the original card, but a replacement that will drive modern displays?
If so, then forget about the VRAMs, which are bound to generating raster output in one orientation.
They're probably also not easy to source anymore.
I still don't have a clear definition of what your final goal is. The intermediate steps you've laid out (like the Pi) might not be useful toward it.
If you want to build a work-alike card with HDMI output, start with an HDMI dev/eval board.
It will already have enough internal memory to make VRAMs redundant. Also, the organization of the internal memory doesn't have the same constraints as VRAM and will lend itself more easily to rotation.
Also, Radius has used software rotation: https://www.macintoshrepository.org/17294-soft-pivot-3-2-1-for-radius-pivot-display
Though software rotation on a 68000 is doing it no favors.
If so, then forget about the VRAMs, which are bound to generating raster output in one orientation.
They're probably also not easy to source anymore.
I still don't have a clear definition of what your final goal is. The intermediate steps you've laid out (like the Pi) might not be useful toward it.
If you want to build a work-alike card with HDMI output, start with an HDMI dev/eval board.
It will already have enough internal memory to make VRAMs redundant. Also, the organization of the internal memory doesn't have the same constraints as VRAM and will lend itself more easily to rotation.
Also, Radius has used software rotation: https://www.macintoshrepository.org/17294-soft-pivot-3-2-1-for-radius-pivot-display
Though software rotation on a 68000 is doing it no favors.
Exactly. We have existing drivers known to be good thru System 7.1 with version 4.4 ROMs for a VidCard that can be cloned.
Drivers are in ROM with a tiny INIT installed in the System Folder.
VRAM capture approach was bounced off our two gurus of FPGA. They strongly suggested putting GALs and logic in the FPGA Dev. Board. The entire card can be cloned in FPGA set up to use existing drivers.
I'm doing proof of concept for that. Looks like I need to clone as much of the input side (Front End) board as necessary to hijack output. Diverting it to FPGA as opposed to the card's "Back End" using Pi
Currently buzzing the board for schematic capture as I'm wire wrapping a prototype. That'll need to be done eventually for cloning the card. At this point I'm hoping output from the four GALs would be the place to do screen capture. I'm concentrating on VRAM to GAL connections. If all I need is output from four GALs aligned with VRAM, so much the better. I could move the carrier board topside and plug it into the GAL sockets, moving them onto the carrier.
So far so good. View is solder side, need to square up ground pins.Note the curious ground line connection (Green) between VRAM and GAL. Best WAG for that would be grounding the sense line on the video connector, testing monitor connected case? Dunno . . . it's a mystery.
edit: No mystery there hadn't mirrored the pinout. The green trace is from pin 1, not ground. OOPSIE.
Last edited:
Exactly.
Hence, the rotation transform mostly filling a DVI display at 1024x768, rotated to portrait orientation.
Was told to rework card when I proposed the project many moons ago, for me impossibru.
Indeed, Radius 64KHz FPD card is the only one of which I'm aware that can be cloned for SE PDS.
The epitome of 68000 Compact Mac DTP (or CAD in my case) workstations in 1987 was Radius FPD/Radius 16 Accelerator combo.
Never got the FPD, but obsessed with it to this day.
Rework it how exactly? Rotating graphic data at the bit level cannot be done by VRAMs.
If you can't work out how that's supposed to happen on paper, designing hardware is jumping the gun.
Not at all, he said the approach to take was reworking the formulas in the GALs. Figured that would require new drivers in ROM. Dropped out as it would require work far, far above my pay grade. I've been searching for that thread to post his reply.
Searched high and low for an available solution for image rotation at that point and came up short at the $200 range.
Not doing anything on the cloned section of the card. Frame buffer capture in its native form from somewhere on the card is rotated in the FPGA and signal goes out its HDMI/DVI. Don't really care how much of the card itself needs to be cloned to hijack signals for that. Anything short of the cable connector pins will be a win.
Designing a frame buffer capture board on a carrier, not a VidCard. I'm buzzing the board for schematic capture at present. Hoping GAL output will be the wedge I need for that at this ATM. If GALs are the way to go, carrier board prototype implementation is simplified by an order of magnitude.
Worked out the rotation transform, that's what kicked off the current edition of the project. Undoubtedly requires more horsepower than any available SBC. All I need is page buffer data capture in the top left frame.
Pi Zero 2 W is on the carrier for capturing what'll amount to every Nth frame if it even has the bandwidth/power to do the capture at all. Not sure Pi 5 can do that, much less run the rotation transform in real time. Hence, FPGA approach.
FPGA Dev. Board suggestions hover in the $100 range. FPGA itself will need to be integrated on the clone PCB if things work out.
Last edited:
The VRAMs cannot be made to rotate video.
The entire point of the GALs is to drive the VRAMs.
The VRAMs will not be a part of the final design, therefore the GALs are pointless and a waste of time. They cannot be reworked to do what you want.
The Pi also doesn't help you get any closer to the final product. It's not an intermediate step, but a dead end.
The entire point of the GALs is to drive the VRAMs.
The VRAMs will not be a part of the final design, therefore the GALs are pointless and a waste of time. They cannot be reworked to do what you want.
The Pi also doesn't help you get any closer to the final product. It's not an intermediate step, but a dead end.