Search results

No need to prove you wrong, I have never said image rotation will take place anywhere but in the gates of the FPGA, You've been assuming that I'm trying to do things I've never suggested. Not doing rotation in VRAM, not in GALs, no rotation will be done ANYWHERE on whatever portion of the board...

Never implied VRAM could do anything like that, data inputs to VRAM were to be captured and run through the FPGA early on in the thread. Waiting for feedback on the viability of snooping GAL outputs for assembled page buffer data. If possible that'd be a convenient wedge. VRAM will definitely...

Makes sense, printing footprint is a major consideration.

LISA 1 with optical drive! The FDD version looks more substantial, thinness is not a feature. Why the 9.7" iPad panel limitation?

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

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

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

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

It's exactly the same as a horizontal scanline 640x480 display. But has 384 additional scanlines making it 640x864 Handy screenshot!

Poor choice of words in that sentence, he's describing the scan line in table above overall, check 24:00. Image is built up exactly the same way a 640x480 is built, just the aspect ratio is higher than wider. It's done in hardware in both cases..

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:

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.

I doubt RGBtoHDMI has the horsepower to do my rotation transform in real time. Started looking at this one: https://texelec.com/product/rgbtohdmi-ttl/ Moved on to FPGA for speed and flexibility for future development.

No reason for it to be done in software and every reason to keep it in hardware. The card's a bog simple hardware/driver setup. Currently looking at VRAM Data -> GAL setup, If it all lines up the way it appears to at first glance, reading output from the four matching GALSs ought to be more...

NEW APPROACH ____________________________________________________ A straight up 1:1 clone of the FPD card in wire wrap in the form factor of a standard SE PDS Card is what I'll start doing. Documenting the schematic one wrap at a time. - cloning the card is pointless, even though it's the only...

Dang, jumped the gun again and in the wrong direction. Got a few days out of town. Guess I'll be buzzing out the entire front end of the card before looking into anything else? I'm trying to eliminate the card entirely as the final step in FPGA development. Treating the front end like it's the...

Not even close to that yet, running out of town for a bit. Knocked together PDF 14 and attached it above, heading all serial related lines toward Pi rather than VRAM input lines, going with alternate approach you guys suggested upthread. edit: looks like tags are a pin too high on the right...

Clean slate. So it goes . . .

Got it, comparison to simple DRAM shook something loose in my noggin, thanks Looking into switching gears to capture serial output of frame redraw to "Back End" of the card. Same carrier board, whole new approach to VRAM I/O. Heading out of town, will be doing my doodling in #2 pencil on paper...