Re: "Replay_VideoConverter" added to support library

You should see in the boot log from the ARM where it sets up the CODER?

27 (edited by foft 2014-03-21 21:23:49)

Re: "Replay_VideoConverter" added to support library

It says 'Coder: Fitted'. Is that good?

edit: Looked at source code - I don't see the 'CODER: PAL Y trap.', though perhaps I need to enable log level 2?

edit2: I see its a #define so I'd need to rebuild... (which is fine but I've not tried flashing yet:-))

28

Re: "Replay_VideoConverter" added to support library

What is your clock setup?
You can check the log file
DBG:  PLL clock outputs :
DBG:   0 : ~  ...
DBG:   1 : ~  <whats here> KHz
...

Just to consolidate...

The sync signals are all generated with the video converter, but you need for PAL:

FPGA:
- a 50Hz interlaced video parameter set for g_Vid_Param_SD on the converter
   e.g. c_Vidparam_720x576i_50
- i_HD_Mode signal on the converter needs to be '0'
- the signal chain from converter to the DAC outputs can be seen e.g. on Galaga, Phoenix, VIC20, C64,
  and other cores - they (should) look all the same

INI-File:
- proper video clock (usually 27MHz +/- a few percent to sync to the core)
- a 14318 kHz clock on the coder
- video coder enabled

NTSC mode needs 60Hz setup and a different colour clock. This makes it also not possible to do a dynamic switching via OSD menu, currently you have to set up two INI files (one for PAL, one for NTSC).

/WoS

Re: "Replay_VideoConverter" added to support library

I see these. I took VIC20 and just changed 0 and 4 - I thought. 0&4 are as I intended.

0 : ~113860 KHz
1 : ~17734 KHz
2 : ~49656 KHz
3 :  OFF
4 : ~27010 KHz
5: OFF

So the coder is clock 1? Looks like I'm using 17KHz rather than 14KHz...

My core:
#SYSCLK=7116310Hz, Nsys=1729, Msys=205, Psys=2 ... VIDCLK=27010289HZ, Nvid=2625, Mvid=328, Pvid=8
CLOCK =    328,2625, 205,1729,  46, 423,  2,  4,  4,  0,  1,  0,  2, 14,  5,  1,  8,  1,  1,  1,  1,  0,  1,  0

VIC20 core:
CLOCK =   284,2275, 300,1183,  46, 423,  2,  4,  4,  0,  1,  0,  1, 14,  5,  1,  8,  1,  1,  1,  1,  0,  1,  0

i.e. I changed nsys,mays and psys (pd0 I thought) only.

Guess I'd better change clock 1. So I guess VIC20 has the same problem?

Re: "Replay_VideoConverter" added to support library

~17MHz is correct for PAL, ~14MHz for NTSC.

31 (edited by foft 2014-03-23 21:07:20)

Re: "Replay_VideoConverter" added to support library

Ah, then its something else. I just checked the composite out on the scope and there is no signal. So it appears disabled rather than slightly the wrong frequency.

Surprising svideo works and composite fails. I thought they are based on the same timings form the same chip (AD723)? Perhaps I should go read the data sheet :-)

edit: Now wondering if its a bad connection of some kind. I've not read the data sheet in total, but it appears the CV output is a sum of the chroma and luma outputs (which work). I see its on the bottom of the board - I'll try measuring directly on the chip...

edit2: Nothing on pin 20 of the actual chip. High resistance to ground. I tried the VIC20 to see if its my core or the board - I need to flash the firmware, have to work that out another night.

Re: "Replay_VideoConverter" added to support library

Quick point, the outputs are automatically turned off if no load is detected - this caught me out before.
The composite output is tested as part of the test spec, so it should have worked at one point.

/MikeJ

33

Re: "Replay_VideoConverter" added to support library

MikeJ wrote:

~17MHz is correct for PAL, ~14MHz for NTSC.

Uh, yes - sorry.

MikeJ wrote:

Quick point, the outputs are automatically turned off if no load is detected - this caught me out before.

Good point - I had exactly the same problem, took me a while to figure it out smile 
A 50 Ohms load resistor is needed on the output when measuring with an DSO (as long as the DSO does not have a 50 Ohms input as well). Something with 47 Ohms or 56 Ohms should be still fine to enable it.

/WoS

Re: "Replay_VideoConverter" added to support library

Well I updated the firmware and ran the latest loader. I can confirm its not just my core... I wonder if my monitor has too little load to activate composite out. I'll try with a resistor and the scope later as suggested.

Curious - can someone try composite out on the a8 core? Need to select sd mode on the osd.

Re: "Replay_VideoConverter" added to support library

I've run out of time tonight, but I'll send you a copy of the product test binary which outputs composite. Loader by default is 480P I think.
/Mike

36 (edited by WoS 2014-03-25 19:57:28)

Re: "Replay_VideoConverter" added to support library

Just tried your latest version on SVN, works nicely in HD/SD mode via HDMI and in SD mode on composite out (well detected as PAL video). So your code is totally fine.

Your can temporarely connect a 47...56 Ohm resistor in parallel to the composite out (you can see the leads on the back of the connector of the replay board - just touch them with the resistor leads) to enable it that way. But it is definitely cleaner with a cinch connector with a soldered resistor and an oscilloscope wink

I also saw you define the whole keyboard map as DATA lines in the INI, this crashes the INI reader - so I had to comment it out to get the core initialized on the board to check the video stuff.

The only quick fix for now is to you use the "c_empty_kb_map" setup for the keymapper in your core and only define the DATA lines with actual keys defined (where data != 0xFF), this (hopefully) keeps this setup in the INI small enough.

I'll have a look where the bottleneck is (very likely a memory overflow as the FW keeps the whole INI content for later backup storage, the way it is currently done is not very efficient).

/WoS

Re: "Replay_VideoConverter" added to support library

Thanks Wolfgang. Foft, you could also check R136/R140 which are between composite out (pin 23), cset (24) and analog ground. Can't think of anything else which would break the composite output if the SVHS is working fine.

If everything looks ok we have to assume the chip has been zapped and we'll sort out an IC swap
/Mike

Re: "Replay_VideoConverter" added to support library

Many thanks Wolfgang (and Mike).

I wish I'd seen your post earlier yesterday Wolfgang :-) I'm changing the core to use c_800xl_kb_map, locally defined in my core. Which should shrink the ini file massively. I guess the backup feature was added since Nov/Dec last year, since that is the firmware I upgraded from (which worked). I knew the million 'DATA = ' statements wasn't optimal but I thought they'd be read/processed in series... :-)

Afraid I don't have time to connect up the scope (+resistor) tonight, but will have a go tomorrow. I wonder if my monitor (PVM 14L5) just doesn't put enough load on to activate it.

39 (edited by foft 2014-03-30 20:30:28)

Re: "Replay_VideoConverter" added to support library

Sorry for the slow test here... I've had guests staying and no FPGA time.

Managed to find time to get hold of a 56ohm resistor. As soon as I connect the load I see a trace on the scope. If I then connect it to my monitor I get a picture. So the conclusion is that my monitor does not load it enough to enable the output... (picture disappears without the resistor)

Looks more 'authentic' over composite on the CRT:-) Though I need to disable interlace, since the Atari XL does not use interlace.

Re: "Replay_VideoConverter" added to support library

Hey Wolfgang, some questions..

wolfgang wrote:

INPUT VIDEO/CLOCK:
- the first clock domain clk_sys as used by the (arcade) core generating the video input to this block

You mean the core's pixel clock, not the core's system clock right? (pixel clock will most likely be a divide-down of the system clock)

wolfgang wrote:

    g_Match_Line    : integer := 0;  -- input line used for frame sync

Input line at which the frame-sync of the video generator is set to synchronize input to output. Depends if the input lines are shorter than the output lines, the frame is synced on the top lines, if the input lines are longer than the output lines, the input needs to be buffered up first and the frames need to be aligned on the bottom lines of the video frames. With this parameter the alignment can be achieved.

Not quite sure what this means.. can you explain more? Since output is HD (DVI) and input is some very low-resolution wouldn't input lines always be lower than output lines?
Also wouldn't you always want this to be 0? If it's > 0 then does that mean the first few lines will be lost?

wolfgang wrote:

    g_Vadr_Width    : integer := 3;  -- buffer vertical address width
    g_Hadr_Width    : integer := 9;  -- buffer horizontal address width

These defines the video buffers. In this example 2^9=512 pixel by 2^3 =8 lines max. buffer size. Synthesis will then be able to select FF for small amounts of will infer a RAMB if it grows larger.

How can we calculate how many lines of buffer we will need for a given application?

wolfgang wrote:

    g_Voffset       : integer := 18; -- vertical buffer offset on output
    g_Hoffset       : integer := 104 -- horizontal buffer offset on output

Sets the starting point where the video buffer is positioned on the output video signal.
So the first output pixel starts where hpix counter of the output minus this hoffset is zero and the lines starts where vpix counter of the output minus this voffset is zero.

I take it this positions the frame?  For example if we have some lower resolution like 256x256 that could easily fit anywhere within an HD display, these values indicate were in the HD frame to position the 256x256 frame?

wolfgang wrote:

    g_Loffset       : integer := 2;  -- buffer line offset on output

When reading the video buffer at the output a offset correction is needed to align the first line written in the video buffer to the first line read from the buffer. It could be for sure calculated somehow in the code, but I found it easier to start a simulation and check where it actually starts to readout and set the required difference to this parameter.

Not quite sure how to read this. Do you mean the distance between the read and write pointers of the buffer?

Thanks!!

-Adam
==============
www.onecircuit.com
==============

41

Re: "Replay_VideoConverter" added to support library

> You mean the core's pixel clock, not the core's system clock right? (pixel clock will most likely be a divide-down of the system clock)

yes, and the calculator calculates the proper PLL parameter for sys_clk and vid_clk for setting up the properly scaled (and phase-locked) frequencies
http://www.fpgaarcade.com/punbb/viewtopic.php?id=148

> about the questions for
> g_Match_Line    : integer := 0;  -- input line used for frame sync
> g_Vadr_Width    : integer := 3;  -- buffer vertical address width
> g_Hadr_Width    : integer := 9;  -- buffer horizontal address width

The lines per frame will rarely match the selected video mode. Either you have more lines or less lines. As there is no vertical scaling, you need to decide how to align the lines of both formats, which also have a different pixel count / line.

This also means that the timing of one line differs from input to output - as it is for both the (common) frame-time divided by the individual lines/frame. So you may need a buffer and start reading the core video first and start with the video output later or vice versa. Furthermore, depending on the pixel clock and line duration, the buffer per line may vary.
This three parameters define the size of the buffer and at which position (from the input frame) to align both video lines (from input and output). So you have to check the timing of the core and compare it with the timing of the desired video mode, the line difference between them (or timing difference divided by the time for a line and round up to the next full line) you have to ensure proper buffering. As a w.c. you can set the buffer as the line difference between input and output, as long as the lines do not need to be "shifted" up or down between input to output frame (this you can control with the first parameter, which just defines where the converter starts with the line count on input side).

> about
> g_Voffset       : integer := 18; -- vertical buffer offset on output
> g_Hoffset       : integer := 104 -- horizontal buffer offset on output
> g_Loffset       : integer := 2;  -- buffer line offset on output

Yes, the first two are just used for centering the picture on the output (and relate to the output coordinates). The last one is needed to align again with the buffer address to read, I don't really like it. For now I just start simulation and check where the read address should be and what read address I got. I didn't take too much efforts now, but I am sure it could be directly derived from the other parameters as well.


The easiest way to understand what is does is probably to look at one of the implementations like Phoenix or VIC-20, simulate it and look at the signals of the converter block.

/WoS

42

Re: "Replay_VideoConverter" added to support library

wolfgang wrote:
spotUP wrote:

scanlines FTW!

Year, can do - as soon as the basic things work well.  wink

Scanlines added to converter module. Can be set in 3 levels and also switched off.
Also implemented/used on latest C64, VIC-20, Phoenix and Galaga cores.

NOTE: If one is using the converter be aware the build is broken until you add the scanline_lvl input (!)
--> You may set it to "00" which simply disables the scanlines (then behaves like the previous converter version).

/WoS

43 (edited by ost 2014-06-26 21:04:03)

Re: "Replay_VideoConverter" added to support library

My experience is that video timing is critical for alot of monitors, even at the vsync edge. I guess it dates back to the crt monitor age, where a break in the horizontal scan rate at end of frame would cause a tilt of the top of a screen, because the horizontal pll was kicked out of its rate and took some lines to recover.

There is also a lot of PLL stuff in modern ADC's and even digital ones, so in general when I make video signals, I am very strict to keep the phase, even when framelocking. Also I choose an edge for both syncs to work with and align h/v to their working edge.

My dell 3008WFP seems to be very critical about this glitch currently made. Not because it needs to, but because it's fw suck (as many sink's do; they often use same video verification sw for digital as for analog inputs).

On the other side, a lot of video sources suck here too, so it's hard to support all, but I think its better to tweak the weird ones, than the proper ones.

I suggest to enable a "auto timing" mode, where you track source timing, then copy/double the vertical timing, match the horizontal timing so that Htotal*Vtotal*effectivePixelrate is the same on both sides. This will make a perfect framelock without horizontal glitches for any timing.

As long as the source signal made for TV rates, it ought to work on composite too. (You may even throw in a auto refreshrate detector to autoset composite parameters?)

For now, I guess I have to make a custom timing for the A2600, but I'm afraid it won't fit all games, since timing is generated in each game.

EDIT:WTF is a scanline anyway? tongue You mean you can pad extra lines to the timing?

44

Re: "Replay_VideoConverter" added to support library

ost wrote:

I suggest to enable a "auto timing" mode, where you track source timing, then copy/double the vertical timing, match the horizontal timing so that Htotal*Vtotal*effectivePixelrate is the same on both sides. This will make a perfect framelock without horizontal glitches for any timing.

As long as the source signal made for TV rates, it ought to work on composite too. (You may even throw in a auto refreshrate detector to autoset composite parameters?)

Exactly this is done by the video converter. The biggest issue is not at all VGA, but DVI and HDMI. There it is not only the timing, but keeping a certain amount of pixel clock cycles right for the chosen format and this monitors can be really picky, much more than VGA monitors. And here you have the transition from any odd pixel frequency to e.g. 27MHz or similar used by these standards.

The only difference for the actual converter is not to spend a lot of efforts for an auto detect, because it is only required to calculate and optimize once (and enter as generic),  including proper video scaling due to different pixel clocks (which exists on LCD/flat monitors also with VGA, but simply not well controlled due to the analogue signal compared to digital inputs). Finally centering the picture is nevertheless a manual task, even with auto-detect.

And you will see to translate to a HDMI scheme, it is required to tweak the clock of the core and the video (usually just by a few percent or less) to have a perfect multiple of pixel clocks per frame between both domains (not even nearly perfect is enough, even 1 pixel clock off is a problem). For this we have also an own PLL clock optimizer.

By the way, this setup allows the video converter to generate signals working on all video outputs of the Replay: VGA, DVI, HDMI and also composite out and VGA-to-SCART adapters (when disabling scandoubling, of course). And with the original frame timing, which might be already trouble enough for some monitors (as none of these implementations I made up to now use either 100% correct PAL nor NTC nor any other well defined timing)...

ost wrote:

For now, I guess I have to make a custom timing for the A2600, but I'm afraid it won't fit all games, since timing is generated in each game.

"Full" dynamic video is not supported by the converter (due to the mentioned approach), just switching between two pre-configured modes (usually interlaced w/o scandoubling or progressive /w scandoubling).

But is really the whole video timing different (other frame/line frequencies) or just some different active areas? For the first an auto-detect is probably the only proper solution, I agree. But this will make it very hard to support DVI/HDMI. If just the active area changes it might be possible to add a kind of auto mode to center the picture somehow.

ost wrote:

EDIT:WTF is a scanline anyway? tongue You mean you can pad extra lines to the timing?

This means to emulate the visual scan line effect of a good old CRT monitors (which have a limited "pixel height" due to the ray scanning the tube), especially when using a progressive (double-scan) output on a modern monitor. This term "scanline" was introduced by different software emulators. The simplest way is just to double the last line with less brightness (as the video converter does). You can check it out with my cores, they use this feature and you can change the scanline effect by menu (and also switch it off, which I do because I simply love my eyes more than a correct "bad" picture...  big_smile ).

/WoS

45

Re: "Replay_VideoConverter" added to support library

But is really the whole video timing different (other frame/line frequencies) or just some different active areas? For the first an auto-detect is probably the only proper solution, I agree. But this will make it very hard to support DVI/HDMI. If just the active area changes it might be possible to add a kind of auto mode to center the picture somehow.

Tbh, I dont know (yet) how much control there is. I suspect the horizontal freq may be constant and maybe the starting edge, but I'm noob at the TIA chip.. Im going to try a few programming examples and study it.. Even the simplest examples seems to fail, so it should be debuggable. Vsync width and blank surely looks programmable. Apparently you poke to start sync, poke to stop it, and poke to start/stop blanking. So you need to keep track of what line you are on. Horizontally I suspect you work with an edge of starting image, and almost decide where you want the graphics from there (you have to load all the single line objects for each line)

Those programs that do give me an image, has sync issues (double hsync at vsync edge), so they keep falling out. Some just gives a wild sync (I suspect vsync, but not really verified). Lets hope a constant hfreq will keep the workload down..

46

Re: "Replay_VideoConverter" added to support library

Had a brief look at this (pg. 1).

http://atarihq.com/danb/files/stella.pdf

This gave me the same impression (and as you stated) that the horizontal timing is fixed, but the vertical timing (especially VSYNC) is given by the CPU. Bah, yes this may cause some troubles   sad

One way out could be to actually check the V timing and use then one of a set of predefined settings for the converter. Still the problem that it might be required to adopt the video clock for a perfect frame match for the digital video formats, so the core needs to feed back the setting to the ARM for updating the PLL settings providing this clock.

But this would need some additional calculations/investigations first, maybe (hopefully) it is not needed, as - if I am right - it can be only differ in amount of HW defined scan lines the core triggers vsync. So the HW syncs e.g. some line earlier or later for a new frame (wild guess...); this would mean that the frame duration is still given by a fixed count of scan lines, which can't be too far off otherwise the frame frequency won't be within the 60Hz required for a NTSC standard picture. Not sure if it would even work to be one scan line off (each line more/less will change the frame frequency by roughly ~0.1Hz or so)...?

/WoS

47

Re: "Replay_VideoConverter" added to support library

If the hor timing is constant, I will find a way to dynamically tune the vertical blanking. I just have to find the rates that match the 228x3.58Mhz clks to the output side. If I use the 28M for video output, it should be possible.

48 (edited by ost 2014-06-27 21:23:37)

Re: "Replay_VideoConverter" added to support library

At toplevel, I tried to change:
  clk_sys <= clk_ctl;
  rst_sys <= rst_ctl;
into
  clk_sys <= clk_vid;
  rst_sys <= rst_vid;
..in a hope to get video and the 2600 to work on a related clk (where I could find a htotal that matched), but it crashed badly and the loader threw out the fpga bitfile.. Do you see any reason why that should happen?

They are 28.64 vs 27Mhz, right?

49

Re: "Replay_VideoConverter" added to support library

Yes, the idea of the converter is because the clocks are not the same between clk_vid (=27MHz for most standard modes also supported by DVI/HDMI) and clk_sys (whatever, but often not 27MHz). If it would be the same, a converter would be not needed (or better: useless) and the problem would be quite easy (at least if you just want to support VGA)...

You may check out this thread, which was the base for the module discussed here. It also explains the general problem for using odd video modes of most vintage computers or arcade setups (you have exactly the same problem, just different values  wink )   http://www.fpgaarcade.com/punbb/viewtopic.php?id=129

And thus the tool for calculating a PLL settings for vidclk/sysclk as explained in the howto for this converter:
http://www.fpgaarcade.com/punbb/viewtopic.php?id=148

/WoS

50

Re: "Replay_VideoConverter" added to support library

By analyzing the div factors on the different clk, I found a very close pll settings that match. I get stable img now, but my dell only sees the replay when running splitscreen (PBP) mode tongue Go figure! (I'd love to shake those fw authors up a bit wink )