charcole
commented
3 years ago Hey Migry,
Thanks for your kind comments.
Glad you liked the splash screen. It was just a bit of fun as the FPGA had plenty of gates still availble. I'm a games programmer professionally so had done a few shaders in my time. I think I prototyped it using shadertoy.com then once I had something I liked I implemented it in Verilog. Had to do a bit of a hacky inaccurate atan approximation which means it warps a bit but it's almost cool enough that someone could think it's intentional. I only shared it in the middle of this video and it's very much blink and you miss it https://youtu.be/StK0cLoE1lk?t=230. It pleased me though.
I definitely struggled to get the audio working and spent many hours reading the HDMI spec over and over. Luckily I used a PC monitor which was pretty forgiving and when the audio wasn't correct it would show that part of the frame on screen which was actually pretty useful for debugging. Afterwards to get it working on my TV required the Neo Geo to be overclocked as it was so picky about the pixel clock frequency. It was at this point the project changed from using the Neo Geo's clock to sync the output to using the FPGA to clock the Neo Geo. It might potentially be useful to look back at those versions possibly if you aren't clocking the ST yourself.
I couldn't remember much about the sync signal but I've had a quick look over the code, documentation (what there is) and the Neo Geo schematics. So I think I actually using the blanking signal instead of an actual sync (although the signals are very similar). The video output is run through a couple of latches and it's the clear input on these latches which I was using as the sync. Schematic is hard to read but I think it was from a 74LS273 which would make the sync pulses active low (to blank the output). It also looks like the two MVS boards I used produced this signal differently. With OLD_SYNC, it seems to be only a vertical sync while if OLD_SYNC is not defined it's a composite sync.
Anyway, hope that helps at least a little. Let me know how you get on. Digital output for an Atari ST sounds great.
Charlie
This appears to be the only way to contact the original author.
Colour me well impressed with this project. I have been aware of this code for some time. Yesterday I compiled the HDMIDirect.v module on my homebrew CycloneII board having added the extra PLL, ROM and RAM modules. I emulate the NeoGeo with a simple VGA generator module (no doubt derived some time ago from the excellent work by Mike Field a.k.a. HamsterNZ) It didn't take too long to get the project to compile.
I was blown away when I first saw the splash screen!!! Where on earth did that come from??? I get the "bad sync" message, which in itself I would have been impressed with if that was all there was, although the ROM used for the font was a clue.
My interest in this code was the audio data island generation. I was already working on a project to convert the internal Atari ST "shifter" digital outputs to HDMI (UK 50Hz 576p). This was working successfully, and my aim was to add sound. I recently ordered a cheap board from China to convert stereo analogue audio to I2S. I will read the I2S and inject the samples into the HDMI data stream. The problem I faced was finding clear information as to how to form the audio packets. I have made some progress and having the NeoGeo code has helped confirm which bits go where in the packet. For the Atari STe variant I can inject a 32MHz "video" clock. It is generated from PLL1 while PLL2 generates the 54MHz TDMS clock (and 270MHz clock needed for the serialiser). Luckily the numbers work out and I get 100% lock between Atari syncs and FPGA generated "HDMI" syncs.
Today I have tried changing the numbers to generate a 50Hz 576p frame, the same as I already use for the Atari. I still get the sync error message, and I see a "sort of" desktop in the background, but I need to do more debugging.
Just one question. I assume that the "sync" from the NeoGeo is some kind of composite sync. This type of sync varies from computer to computer. Are the sync pulses active high or low? Assuming active high vsync and hsync, should I OR or XOR them to get the sync expected by your code?
Anyway Charlie, I take my hat off to you!