a2fpga
apple IIGS super high graphics
Hi, never seen that before. Can you provide steps to reproduce? Is that the only app that does that?
hi, sure, I have a bunch of super high rez images I like to run through a couple of sliders, you can see them in folders on the attached HDV disk image , I am running a IIGS ROM 03 , OS 6.0.4 8 megs of ram.
alternatively you can get the hdv image form my google drove here is the link (I tried uploading here)
https://drive.google.com/file/d/15uTPIPbyrxf8IB3pp21_VKpt6SLhNQOz/view?usp=sharing
If you could instead just provide a single app and image that demonstrates the bug on an empty disk. No .hdv files please.
Actually, looking at the screencap you provided, my assumption is that you are using the SHR View app to display Super Hi-Res 3200 color images. This graphics technique involves changing the color palette on every scan line but as the A2FPGA is not locked to the GS internal timing (because HDMI timing is different than composite timing), the color palette updates are synchronized, resulting in palette distortion. We hope at some point to figure out some way to emulate that, we've yet to figure out that. Many emulators such as Crossrunner also have problems with 3200 color images.
yes you are correct, oddly enough if you let SHRview cycle through, once in a while it will "lock in" and show the true image for a second.
bellow is link to my google drive 800k image, highG.po it has SHRvew and a sample of images.
https://drive.google.com/file/d/1ZN9t3YnSxFDWR-dc8_iUzaVTk7IOqEf-/view?usp=sharing
regards.
The IIgs specifically has a Mega II register that can be read to determine which scanline is being drawn. I know the VidHD uses several techniques depending on the model of the Apple II, and spends some time "locking on" to the beam after reset. I'm pretty sure John Brooks has talked about these techniques on Slack; here's one simplified overview: https://apple2infinitum.slack.com/archives/C1J89GVL4/p1646845788437779
We can in fact track which scanline is being drawn on the Apple side. The complication comes from one of the few places where we have to diverge from the Apple’s original timing: the rate at which we output HDMI video. The A2FPGA’s video scanner mimics the behavior of the Apple II’s, fetching a byte from our mirrored video memory, converting it into color, and outputting it, in our case via HDMI instead of composite. The problem is that the A2FPGA’s video scanner runs at a different pixel clock than the Apple’s, so over time its scanline position drifts relative to the GS’s. This desynchronization breaks beam racing techniques like real-time palette changes or sprite multiplexing that depend on cycle-accurate alignment with the video beam. The best way to fix this is to double-buffer the rendering pipeline: render each frame from video memory into an intermediate framebuffer at Apple timing, then scan that framebuffer out to HDMI at HDMI timing. This would keep everything visually in sync and preserve compatibility with timing-sensitive tricks. I expect that this is what VidHD did. This currently seems a bit tricky to manage in terms of memory bandwidth. It's not out of the question, but a lot of work.
The VidHD enjoys all the benefits of a stripped-down Linux distro, including a framebuffer and HDMI drivers, and 1080P-capable hardware; but also significant power usage and reliance on extraordinary software to handle timing constraints, which results in total lack of audio support. I'd rather have clean audio than 3200-mode or race-the-beam support.
yes, but the images converted to computer (they were a new thing for computers) capture the spirit of the time.... I would rather the images. anyway, if a fix is not possible no worries, I will have to sell my first born for a VidHD.