Yeah I will give it a try. My only concern is the IC, not sure there is an equivalent through-hole part, but there should be some compatible alternatives.

Thanks! It could have been a lot nicer if the Pico had slightly faster main cores. For example the brown color fix is currently handled in the VGA PIo because the main core isn't fast enough to handle an additional if (Color == Dark Yellow) { Color = Brown: }.

Please make a video only about the sw!

@@alexloktionoff6833 I will try to add details in the README, because things will change as the firmware matures.

Oops good catch! I am indeed using the 74LVC245, but I couldn't find the right entry for it on kicad, so I used the LS part instead. I will update the BOM.

@@scrap_computingRP pico inputs are 5v tolerant in practice, just you need to guarantee you will never setup them as outputs even temporary

I think they have the same pinout so you could use a female connector too. But I think the cable has to be quite short otherwise the signal does not get picked up properly.

@@scrap_computing Usually the pins are reversed left-to-right between the male and female connectors, which is why I mention maybe soldering it on the other side of the PCB, if there is clearance and the pins line up.

@@SanguineBrah It should fit fine. The only component that is close is the IC, but I think there is enough clearance.

It should be possible to output a more modern digital video signal straight from the Pico. DVI or DP should be possible, I have not looked into them in detail. The biggest challenge is the TTL sampling part, but once this is taken care of I think making a variant that can output a digital signal is the next step.

Yeah I think line-doubling should fix the issue. It's already doing this in CGA mode, so it should work fine.

Actually, it is these specific games that look strange in Hercules mode, because they don't actually support proper Hercules mode. Instead they will produce this stretched image, and they expect the user to fix the aspect ratio on the CRT monitor (see @alexloktionoff6833 's comments). Hercules mode text actually looks all right.

Yes, adjusting the Pico's clock should remove the artifacts if you can't get rid of them any other way. I could add a button combination that allows you to tune that too.

​@@scrap_computing The pico supports some frequencies that are close to integer multiples of the EGA pixel clock. In particular 260.0 is 0.112 off and 178.8 is just 0.027. Perhaps the 260.0 one is fast enough for this software and will allow improving the sampling. In other word using DPICO_FREQ=260000 in the cmake command.

There may be a way, but I think it won't be very easy because the pixel clock frequency is quite comparable to the state machine frequency. So you may need multiple state machines running at different frequencies etc. But yeah, that would be really cool!

Yes, line-doubling should do it. CGA is already doing the line-doubling so it should work fine on Hercules too.

Actually, it is these specific games that look stretched in Hercules mode, because they don't actually support proper Hercules mode. Instead they will produce this stretched image, and they expect the user to fix the aspect ratio on the CRT monitor (see @alexloktionoff6833 's comments). Hercules mode text actually looks fine.

(edited) Although I believe the above works in theory, it does require pixel values to be available, which they don't appear to be due to the nature of VGA? It's not clear to me if something similar would be possible with the VGA line logic. Perhaps a Running Variance can be computed across all lines for a couple of frames (8 perhaps), and that value is then minimized over the different pixel clock values. More specifically, could the value of X in pio_sm_put_blocking(VGAPio, VGASM, X) be used to compute the Running Variance? A rough pseudo code can be: display an image, set a candidate pixel clock, for some short time (say 250ms), compute the Running Variance in the line writing logic and store it. After the variance is stored for all candidates, choose the candidate with lowest numerical value for the Running Variance as the optimal candidate. A potential speedup is to use a binary search. An additional speedup is to first use large steps and after some iterations with the binary search use small steps.

The issue is that the fastest detection loop in a PIO takes 2 instructions, one `jmp pin` and one `jmp x--`, this is already 7.2ns. So if we try to measure the time a pixel is found "ON" our measurement will be a multiple of 7.2ns. But what we need is a resolution of about 0.001ns.

I am not sure I fully understand what you are describing. The pixel clock detection is for the TTL side, not the VGA side. On the VGA side we just generate the expected VGA pixel clock and we are done.

@@scrap_computing Oh, I didn't take that into account. In those terms it would be like we set a candidate clock for the TTL side then measure on the VGA side how good it is, and not necessarily output any VGA signal while measuring. The TTL side then runs at normal speed and the VGA side is not doing significantly more than before, just aggregating some numbers. It would sort of be replacing the VGA side with a "instrumentation side"while determining the best candidate clock. Possibly a "please wait" banner or so could be displayed while this logic runs.

Ah OK I think I got it now. But how would you reliably measure how good the pixels "look"? The adapter can't tell if the noise is coming from bad sampling or from the actual input. Anyway, adjusting the pixel clock is not such a big deal. As long as you don't constantly swap cards you would only need to adjust it once per mode.

That's quite interesting, though it's a bit more tricky for a couple of reasons: (i) The ADCs on the Pico are not fast enough for VGA, so you would need an external ADC chip, like the TVP7002. (ii) Then you would have to reduce the color bits a bit because you would run out of GPIOs on the Pico. But other than that it shouldn't need too many changes on the firmware side.

Just in case BreakOut game from Poland can use native HGC resolution

I was not aware of this, thanks for sharing. I will try out some genuine HGC games.

Could this be why the image in these games looks so stretched? Monochrome text looks fine, but the games themselves look like they need line-doubling.

@@scrap_computing exactly, this is tweaking HGC to ease and kinda share graphics routines and bitmaps. They make hgc output 80 bytes per row and 200 lines, users had to use hor/vert knobs of monitor to stretch video full screen.

@@alexloktionoff6833 Ah, makes sense, thanks for clarifying. So there is no point in trying to fix how these games look with firmware tricks.