Search results

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

Incremental updates I understand, Data in VRAM iis refreshed when it's accessed, so it remains the same until actively changed by the CPU and not everything needs to be changed for every frame. CPU reading data back from VRAM makes no sense at all to me, by what mechanism is that accomplished...

Don't understand why feedback is required for scrolling, pointer movement and such. CPU knows it's scrolling and feeds the next frame to VRAM accordingly, no?

Hoping it will. Thinking at work today, I've decided to map the card from the PDS connector on the MagicBus Card, pretending that four row monstrosity is not even there. So I'll be modeling FPGA Card V.1 and markup/schematic takeoff will be a lot simpler task. Also will breakout any PDS signals...

Just read my last and it was badly worded. Not cutting off discussion until testing is done, just saying my responses will be delayed and fewer while off to see the GRLF Don't get much time on the forums. Here's a better representation of Rev.1 in SE PDS Card form factor: Got ahead of myself...