MCE Blaster MDA,CGA,EGA to VGA Adapter Released! (Part 2) 

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.

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.

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.

​@@scrap_computing would Pi Pico 2 get it closer ?

It supports EGA, so yeah it should work.

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.

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.

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.

Sorry, I am not planning on selling them. But they are not particularly hard to put together, especially the through-hole version.

@@scrap_computing agreed! So what would the optimal parameters to get the boards made (or even assembled) by pcbway be?

@@VidaDigital the boards don't require any special parameters, they are very standard 2-layer boards. Just upload the gerber files and should be good to go.

@@scrap_computingso I’ve sourced 5 pcbs from PCBWAY but I’m still missing the 74LVC245. Is the 74LS245 or 74HC245 acceptable?

@@VidaDigital I don't think they will work but if they are pin-compatible you could try, they might work with your card. You do need a 74LVC245 which by the way is widely available and rather affordable.

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!

The Pico 2 will make it even better!

@@scrap_computing Thank you for response. Will the code need to be changed ?

@@cassielam2868 Probably not, but I would have to get one to check.

I am using the Pico's c/c++ sdk

Can you add 640x435 @50Hz 23.9khz R,G,B,H,V TTL signal input?

@@QuangNguyen-r9i It might be possible. What mode is this, is it EGA extension?

@@scrap_computing This signal output from CNC controller, pixel clock 20.445Mhz

@@QuangNguyen-r9i Ah I just realized that the resolution is too high, it won't fit in the Pico's memory. Also the pixel clock is probably too fast for the Pico. I am planning to create a new version of this project using the new Pico 2, which has more memory and is a bit faster. Once I get it working I may experiment with more exotic EGA modes if I find a card that can generate them.

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.

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.

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