Closed rharke closed 1 year ago
It should be applied automatically so it's likely a bug. The main problem is that I don't have an Apple IIGs myself which makes it difficult to track down such issues. Do you have a USB to TTL serial adapter as that might be useful to monitor the debug messages on the Pi serial port. (You can also view the log using the save log option but it is sometimes better to monitor it live at the time the mode changes)
The Vsync signal is connected to 'Flip 6' which is an address bit invert signal that can be used to infer if 14 or 16 Mhz modes are in use and maybe that detection has been broken in some way.
Can you try Beta33 - Beta40 as that was the time that IIGS support was added and tweaked If some or all of those versions work then by progressing through the versions to the current release you might be able to find when it got broken. (If the early versions don't work either then maybe it never worked properly or only on some IIGS board revisions)
NOTE you will have downgrade the firmware to V9.3 on at least some of the above in order to run them.
https://github.com/IanSB/RGBtoHDMI/releases?page=3 https://github.com/IanSB/RGBtoHDMI/releases?page=2
I do have a serial adapter, yes. I'll try to give it some testing - I do feel like this worked on an earlier version but I could be wrong. I built a little board to capture all the right signals, which I'm pretty sure worked without any issues when I originally tested it last year. I believe I compiled from source at that point in time so perhaps something changed.
Fair warning that I may not be able to do the testing quickly as I have a number of things on my plate right now but I will keep you posted.
@rharke
I think I found and fixed the problem but can't fully test it so can you test beta54: https://github.com/IanSB/RGBtoHDMI/releases
Thanks! I can confirm that beta 54 fixes the issue (tested 53 and 54, 53 doesn't switch automatically, 54 works fine)
When using the RGBtoHDMI with an Apple IIGS, there are two video clocks that you have to deal with, the 14.xMHz clock and the 16.xMHz clock. I'm very pleased to see that RGBtoHDMI has handling for this!
However, there's one issue I've observed- each clock may need its own sampling phase. In fact, you can run calibration in each mode, and the two phases (along with the rest of the sampling parameters) are indeed serialized, stored, and restored separately and correctly to/from disk when you save. But, when the mode switches, the appropriate sampling phase does not appear to be put into effect. Opening and closing the OSD (without actually making any changes) fixes the issue.
Since the machine boots up into a 14MHz video mode, if you're booting into GS/OS, then the display goes wobbly until you frob the menu button so that the 16MHz sampling phase is picked up.
Any chance this could be applied automatically?