1 (edited by WoS 2013-09-07 15:39:25)

Topic: sysclk -> vidclk sync for arcade video

Mike,

I did quite a lot different experiments to set up the game using sysclk (matching the clock of the board to emulate) and the video/osd interface using vidclk (to re-use the video_pack timing definitions).

Basically using the idea of sampling the original board timing with vid_clk and regenerate the signals there.
I can't find a reliable solution using a single line buffer - and I am not sure there is one because of the synchronisation issues between arbitrary frequences of sys and vid and involved sync/pixel jitter...

I see these ways out:

a) using (a multiple of) sysclk from the game also for video-out (as bascially done on Phoenix for now)
   --> by this the replay_lib/video_pack definitions can't be used, DVI-D/HDMI may not work on "odd" timings
b) using (a fixed divider of) vidclk for the game as well
   --> the game will use some imperfect clock and the gaming experience may be different
   --> still issues with different pixels/line and lines/frame to video_pack definitions
c) setting vidclk/sysclk to a synchronous value
   --> similar to above either like a) or like b), but maybe better clock distribution
d) Instead of linebuffering: going for a full, dual-port framebuffer approach as you mentioned.
   --> Writing from game will happen based on sysclk, reading to video-out will happens with vidclk
   --> May allow frame rotation for upright/portrait arcade games for Jim ;-)
   --> in principle, any output rate can be used independent of the game frame rate

So I started to investigate the buffering over the dram, but it seems the existing HS interface using single reads (default setup from loader example) is not fast enough to allow continuous reads with 27MS/s for the video out...(?)

Do you have an example for a burst read using your interface? Then I could use a FF based double-line buffer - and first read the dram in one step to this buffer, before sending it to the video DAC. By that any latency from system access can be buffered somehow. Or maybe you did already something in this direction, then I'd like to avoid doing it again...?

Cheers,

/WoS

Re: sysclk -> vidclk sync for arcade video

Here, here!  We need some type of rotation capability.  smile

A frame buffer would allow us to use the normal DVI-D output, eliminating the issue with the various games that use odd frequencies.

Re: sysclk -> vidclk sync for arcade video

Hi Wolfgang,
I have a version of the DRAM interface with burst read - I need to finish simulating it. I am working on this as part of the RTG Amiga core.

One thought. How about cheating a little and setting the vid_clk to be exactly lined with sys_clk.

As in number of sys_clk/game_clock_per_line = vid_clk/hmdi clock per line.
The clock generator has large dividers, so it should be possible to get them exactly in lock step?

What's the sys_clk and line length (active / total) for Phoenix ?
Using a DRAM frame buffer is the most universal solution (and allows rotation) but at the cost of a frame delay and potential tearing.
Best,
MikeJ

4 (edited by WoS 2013-09-07 20:53:34)

Re: sysclk -> vidclk sync for arcade video

Yes, thats what I meant with version c) to distribute the clocks to two domains. Unfortunately - as you can see - even this two games I am initially look at produce completely different video timing:

H/V Video counters:

Phoenix    eff. CLK:    11,0   MHz  (eff. pixclk is half of it)  
         cnt      ms       Hz
    H    704    0,064    15625,0
    V    256    16,384   61,04
                
Galaga    eff. CLK:    6,144    MHz  (equals eff. pixclk) 
         cnt      ms        Hz
    H    384    0,0625    16000,0
    V    264    16,5      60,61

My concerns are the general compatibility of displays with such timing. On VGA using a scan-doubler seems to be ok (as shown on Phoenix), but DVI-D simply does not sync... And using the native (not doubled) timing makes troubles when passed to composite out. Maybe it depends also how picky the TV set is, mine (LCD TV) does not get a clean sync (flickers sometimes).

If you have a minute left, maybe you can take a look at the generated Video DAC signals of my Phoenix test setup I checked in. Could be that my problem is something completely different (why VGA works but DVI-D and composite fails). If yes, I'd stay on this (initial) concept and clean it up with a separate converter block.

I could check in the actual Phoenix design if you need the sources for this. That code is still quite a hack on core_top level though - but at least it works somehow ;-)

/WoS

Re: sysclk -> vidclk sync for arcade video

Wow, Galaga is well off on linescan frequency - may need to slow that one down a tiny bit to sync up.

Just thinking aloud here...
For Phoenix if we generate a vid clock of 11MHz/704 * 1716 we get 26.8125 MHz exactly (rather than the usual 27MHz). We can synthesis this spot on.
This would give us line lock for HDMI 480i 60Hz  such that we could resample each line and have the correct pixel count for the HDMI decoder in the TV.

Vertically we still need to produce 240 lines per field (525 total).
HDMI at this frequency would give a field rate of 59.52..  not 61.04 - so it's not going to work.

If we look at clocks per frame,
Phoenix is 704x256x2  11 MHz
HDMI 480i is 1716 x 525

so running the vid clock at 27.493... would give us frame lock. The clock generator would need to be programmed with the exact dividers 900900 / 360448 x pheonix sys clock

We would then need to lock the HDMI flywheel such that the first output active line is below the Phoenix first active line - we are going to receive the input lines at a slightly different rate to the output.
If you are using the Replay video timing generator, it has an input i_SOF.
Whack this at a selectable point in Pheonix's frame. As there is a clock change here we need some lock/not locked window so we only whack it if it's more than x clocks out. Once the generator is synced it will stay locked.

Then write phoenix active video data only into the CDC FIFO, and read it out only during the output video active period.
You should then get a stable picture, but some of the picture will be missing due to the FIFO overflowing or running dry.
Then we just tweak it so it doesn't smile
We may still require the DRAM as a long FIFO, but we will get only a few lines delay and no tearing... in theory.
/Mike

6 (edited by WoS 2013-09-07 23:27:42)

Re: sysclk -> vidclk sync for arcade video

Ok, if I got you right is tweaking vidclk and running the game directly with vidclk (instead of sysclk).

I think I initially tried this and I got some problems with the clock tree (it got too large which made problems with the timing at P&R). But I am not sure, have to try again. Could be that it was with sysclk...

I'll try to further tweak the timing based on your proposal.

Regarding the full frame buffer approach:

I would try to avoid tearing with a triple frame ring buffer (maybe  - as there is enough memory - for simplicity of counting even a quadruple buffer):
- The first is read & sent to the DAC based on the standard video timing.
- The second is written by the game (optional even with rotation by an address mapping).
- As soon as the second is filled by the game, it continues on the third, then it continues with the first. If the read is too slow and the next frame is still blocked for display, the actual frame is overwritten.
- As soon as first frame is shown it switches the read to the second (otherwise it stays on the first/same frame another cycle if the game is not fast enough with writing).

/WoS

Re: sysclk -> vidclk sync for arcade video

wolfgang wrote:

Ok, if I got you right is tweaking vidclk and running the game directly with vidclk (instead of sysclk)..

No, the game runs on sysclk still but vidclk is tweaked. I'll try and have a look at this and send you a mail.
/Mike

8 (edited by WoS 2013-09-08 20:07:31)

Re: sysclk -> vidclk sync for arcade video

I did improve the Phoenix sources and checked them in.

The core runs on sysclk (132MHz) which is divided by 4 in the lib,
on replay top I do a clock gating with divider 3 --> 11MHz eff. board clock.

So compared to the previous early binary version I had, the ARM SPI clock is again default 24MHz.

A double-scanline-buffer generates VGA compatible signals  (which can be of course bypassed for arcade mode). There happens the transition to vidclk as well, which runs on the default 27MHz.

I moved the test binaries to a subdirectory "sdcard" with an ini file. Still behaves like the initial version (on VGA - also syncs w/o doublescan on an arcade monitor - just OSD needs to be fixed there).

I tried playing with the clocks (as they are quite decoupled by HW), didn't help to get a lock on HDMI.

/WoS

Re: sysclk -> vidclk sync for arcade video

Great, I'll have a play as well.
/Mike

10 (edited by WoS 2013-09-11 10:04:58)

Re: sysclk -> vidclk sync for arcade video

admin wrote:

We would then need to lock the HDMI flywheel such that the first output active line is below the Phoenix first active line - we are going to receive the input lines at a slightly different rate to the output.
If you are using the Replay video timing generator, it has an input i_SOF.

Aaaahhh - I think I got you now your proposal. Sorry, took a little longer... roll

It basically means I take your loader setup including the video generation and try to replace just the generation (of the white frame and red/green cross) by rgb pixel "lines" from the original game using some (few) line buffers and moving them somehow at the right location.

Sounds simple, just need to add an address-out and rgb-in to the existing video generator you prepared and add these two alignment functions to match each of the large V counters to a few addresses for the multiple line buffers. wink

Tried to scetch the general idea with ascii art, hope it works:

===== runs on sysclk======                                       ======runs on vidclk===========

Arcade video sync -> H/V counter    --(frame retrigger)-->  Replay video generator H/V counter & sync
                          |                                                    |
                       aligment                                                |
                          |                      ,---------------- aligment ---|
                          V                     V                              |
Arcade video rgb   --> ######(few) linebuffers######  ---> video rgb --> Replay video interface  
                    (sync. write)     (async. read)                            |
                                                                               V
                                                                    DVI-A/VGA  &  DVI-D/HDMI

What is left is to ensure the frame frequency of the video generator exactly matches the frame rate of the game as you scetched already.

So what I try first is what happens if I take your video generator and modify the vidclk to achieve a 1..2Hz higher frame rate if this still will produce a stable picture on HDMI. Thus I just need to find some PLL settings with the actual bin file of your loader. If this works, I can modify the loader as shown above.

/WoS

11

Re: sysclk -> vidclk sync for arcade video

+/-10% pixelclock variation (thus frame rate variation) seems to be fine - HDMI stays stable. So I am one step further  smile

You are right, some more lines need to be buffered, but these should easily fit in a single block RAM (if I did right calculations). Next is the set up.

I'll check in some initial test project soon and continue working on it there. Just found some issue with the sof_i input as you mentioned, it does only partly reset the generator which should not be a general issue but makes simulation much longer (to wait for another frame to fully sync in).

/WoS

Re: sysclk -> vidclk sync for arcade video

Great. This fits with my experience in that the monitors are normally quite relaxed about frequency but not frame format.
Cheers,
Mike

13 (edited by WoS 2013-09-11 22:17:47)

Re: sysclk -> vidclk sync for arcade video

Just did a check-in of the "arcade_frame" core using my video test module to replace a complex arcade game.  Simulates so far and acts as starting point (both video timings are running in parallel), but I did not "connect" them them yet (TODO as placeholder inserted). Will be a weekend task smile

/WoS

14 (edited by WoS 2013-09-14 06:46:26)

Re: sysclk -> vidclk sync for arcade video

So close I couldn't wait for the weekend. wink

This is the picture of a test picture using the Phoenix arcade timing (512x208 @ 61Hz, 11MHz Pixclk) plus the Replay OSD on my monitor.

May I draw your attention to the characters drawn by the monitor in the upper left corner?  cool

http://pin4.at/tmp/Video_512x208_61Hz_on_HDMI.png

Yesssss....!
Bye, bye, VGA cables - thanks to Mike for his proposal big_smile

I checked in this version on SVN as backup of this state. What is left now putting the code in an own converter module and doing some useful generic configuration.  Most is detected by the module itself, but the line buffer size and picture location has to be manual configured for synthesis. I think it can be easily used by the other cores as well now. I'll check it by myself trying it out for some "real"game cores next...

Edit: I'll also prepare a document showing how to calculate the required module parameters and PLL frequencies to synchronize between the both "worlds" - this will be a quite important setup step...

/WoS

Re: sysclk -> vidclk sync for arcade video

So, are you using a DVI to HDMI cable?

16

Re: sysclk -> vidclk sync for arcade video

Yes (DVI/HDMI Adapter + Cable) , but DVI direct should work as well...

/WoS

Re: sysclk -> vidclk sync for arcade video

I have two new Asus 27" monitors coming to me, and I was a little shocked initially to see that they are HDMI only inputs on them, but they include a simple cable to convert DVI->HDMI.  I thought that some sort of hardware adapter was required to do the conversion, but apparently not?!?

Re: sysclk -> vidclk sync for arcade video

They are about the same, but different shape and sound / no sound.

My software: [url]https://github.com/m6502[/url]
My music: [url]https://soundcloud.com/m6502[/url]
My work: [url]http://www.linkedin.com/in/manuelmontoto[/url]

Re: sysclk -> vidclk sync for arcade video

And DVI can contain analog RGB too.

Correct. HDMI is a superset of DVI.
The Replay board outputs DVI which will be accepted by a DVI input, or HDMI with a DVI to HDMI cable (or passive adapter) - assuming the format is recognized and supported by the monitor.
This is why we are working on a line scan converter for HDMI so we output standard formats which everything should accept...
/MikeJ

20 (edited by meneerbeer 2015-03-17 13:11:10)

Re: sysclk -> vidclk sync for arcade video

I am interested in generating HDMI for old video game sytems. Most of these have a weird pixel clock, but usually the refresh rate is close enough to the HDMI spec. So in that case it is a matter of generating a special vidclk as well. This is one of the few webpages I could find that discusses this matter and I have a question about this:

so running the vid clock at 27.493... would give us frame lock. The clock generator would need to be programmed with the exact dividers 900900 / 360448 x pheonix sys clock

Does the PLL you use really support this high definition for the dividers? I believe you use a CDCE925. When I look at the datasheet it seems N is only 12 bits and M is 9 bits. How do you get such an exact division with such high numbers (900900 / 360448) from your PLL?

Re: sysclk -> vidclk sync for arcade video

Hi,
Wolfgang is a bit sick at the moment, so I'll jump in.
Correct. The trick is to jiggle the numbers around so you find a lower common denominator.
You may end up running the original game fractionally off it's normal speed as well to make it work.

I'll getting close to getting some public stuff up on the server, then you can have a play.
/Mike
p.s. wanna buy a board ? More HDMI output games are always good wink

22 (edited by WoS 2015-03-18 22:35:44)

Re: sysclk -> vidclk sync for arcade video

Thanks, yes - still in bed most of the time... sad

Btw, Mike provided some initial algo for this and I made a small Android app to find values for a few HDMI modes (have this running on my tablet and keeps my workstation free for coding). The frame rates as mentioned (of HDMI generator and original game) need to be _exactly_ the same and not only quite close to each other (so no residual error allowed, this would accumulate and you would loose a frame here and there - after seconds or maybe minutes). This it is possible with this dividers for all cores I actually work(ed) on.

This Android code can be also made public - but neither the code nor its GUI is really nice to look at (quick and dirty), so you have been warned... smile   http://www.fpgaarcade.com/punbb/viewtopic.php?id=148

/WoS

Re: sysclk -> vidclk sync for arcade video

MikeJ wrote:

p.s. wanna buy a board ? More HDMI output games are always good wink

I am more interested in later systems (N64, Gamecube, Dreamcast). I want to try to generate HDMI for them by tapping signals that go to the video DAC.  Your board does look really nice though.

WoS wrote:

This Android code can be also made public - but neither the code nor its GUI is really nice to look at (quick and dirty), so you have been warned... smile   http://www.fpgaarcade.com/punbb/viewtopic.php?id=148

I would be very interested in this program/the source code for it. At the moment I really do not see how to simplify 900900 / 360448, so it fits in the PLL.

p.s. I hope you will soon be better. sad

Re: sysclk -> vidclk sync for arcade video

Ah, in this case you have a different problem.

You need to match the frame rate exactly, so work out the number of pixels per source frame, and then the closest valid HDMI format, number of pixels per frame and this will let you calculate the dividers for your dest clock PLL.

As you are stuck with the source clock, you may need large dividers....
/MikeJ

Re: sysclk -> vidclk sync for arcade video

MikeJ wrote:

You need to match the frame rate exactly, so work out the number of pixels per source frame, and then the closest valid HDMI format, number of pixels per frame and this will let you calculate the dividers for your dest clock PLL.
/MikeJ

Does that really make that much of a difference? I understand in your case you are also generating the sysclk yourself, but the vidclk still needs to be sysclk * (#pixels_frame_system/#pixels_frame_hdmi), I think.

I currently have a board with VGA hooked up to an N64. In order to lock the input and output framerate I calculate the VGA clock (~25 MHz) using a much higher clock. Obviously this will give some jitter. To get rid of some of the jitter I calculated the VGA clock/2 and then ran it through a PLL to multiply it by 2 again. The PLL filters some of the jitter. I am interested in having a precise external PLL, so the jitter will be less and perhaps I can then also generate higher pixel clocks, so I can also generate 720p/1080p signals instead of 480p.

As far as I understand, the SVN is not public right now, but you are planning to make it public? I would be very interested in the PLL calculation algorithm, as soon as it is public. smile