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 alined 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.
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.