Doing a video capture when 'machine=cga' is set in the release version of dosbox 0.65 produces a 70fps file. This is wrong; CGA runs at 60hz (actually closer to 59.94Hz but I'd settle for 60).
Is there a graceful way to correct this (like something in dosbox.conf) or do I need to patch the code? If the latter, what would be the most graceful way to patch it?
weird. I thought the video creation was linked directly to the videocard emulation which runs at 60 hz for cga as far as I know.
I'll ask harekiet about.
Water flows down the stream
How to ask questions the smart way!
hmm dunno how accurate the timing is, but when capturing say paratrooper with the latest cvs i get a 61.6 hz file, so that should be fairly close. But if you modify the source you can just force certain values at 60hz if you want.
I'll double check; I may be mistaken. Still, 61.6 isn't correct; if I can research the exact rate, can I report it here to be included into CVS?
First of all try some debugger-enabled build of dosbox, on mode changes
you'll see additional information like this:
VGA:H total 56, V Total 260 VGA:H D End 40, V D End 200 VGA:Width 320, Height 200, fps 61.461952 VGA:double width, double height […]
VGA:H total 56, V Total 260
VGA:H D End 40, V D End 200
VGA:Width 320, Height 200, fps 61.461952
VGA:double width, double height aspect 1.200000
The fps calculation (which seems to be used later for the avi as well)
is in vga_draw.cpp:
LOG(LOG_VGA,LOG_NORMAL)("H total %d, V Total %d",htotal,vtotal);
LOG(LOG_VGA,LOG_NORMAL)("H D End %d, V D End %d",hdispend,vdispend);
fps=(float)clock/(vtotal*htotal);
No idea if the clock value is correct, or what else causes the difference
from the values reported, but you can try to force an arbitrary fps
value there.
Also you might want to have a look at hardware.cpp (avi writing).
Looks like the totals are wrong: they should be 57 and 262 respectively. The htotal problem is pretty simple - the actual value is one more than the programmed value so it just needs a +1 in there somewhere. I'm not sure where the 260 comes from though.
The values written to the registers during int10 modeswitches are in
int10_modes.cpp, table ModeList_OTHER.
When the graphics system sets up a new mode (vga_draw.cpp) it uses
the following htotal/vtotal:
vga.draw.address_line_total=vga.other.max_scanline+1;
htotal=vga.other.htotal;
vtotal=vga.draw.address_line_total*vga.other.vtotal+vga.other.vadjust;
So htotal should just be +1 and vtotal +2? Maybe Harekiet has some
idea if this would be fine.
In the case above address_line_total is 127, and vadjust 6 (fixed)
which gives the 260.
didn't one of the patches of hal play with these values as well ?
Water flows down the stream
How to ask questions the smart way!
when machine=cga?? dunno
For graphics modes in CGA, address_line_total should be 2 and vtotal should be 128 (one more than the programmed value of 127) giving a total number of scanlines of 2*(127+1)+6 = 262. So the fix is again to add a +1, this time to vtotal before the multiplication by address_line_total.
Ok, thanks. Maybe Harekiet kicks in some time 😀 Don't know if the
other machine types should be changed the same way, if.
Should have the correct htotal/vtotal values now, thanks again!
