d9200 and matrox g400 [RESOLVED!!]

[whammoed]

I am using advance mame to run a wells gardner d9200 with a matrox g400.  For some reason I cannot seem to get the 15K resolutions to work right.  for example 15khz and 60hz is requested but the measured value is around 18khz and 73hz...I would think this would give me an out of range display on the monitor???  I confirmed the rates by hitting "mode" on the monitors adjustment board.
Question:  Is it because the matrox g400 cannot do a pclock below 7 (i read that somewhere)?I checked some resolutions with a pclock above 7 and did achieve the proper 15Khz refresh.
I have a trident blade 64, should I try that?(using gentoo linux which seems to have a driver for trident now.

HELP

anyone else using a d9200 with advancemame?  if so, what video card are you using???
Maybe i should get an arcadevga and be done with it...but i'm really liking linux

[uepa]

I started out using the G400, and it worked well for the most part.  A few 15khz games gave me problems (flashing screen), namely the neo-geo games, so I'd have to tweak the modes a bit.  I ended up switching to a T64, which was great at first!  Games looked better than the G400, but the card was awful in Windows, even though I only used Windows on rare occasion, for networking and updating, etc.

However as newer versions of Advancemame came out, the device_video auto setting didn't work with the T64 anymore.  So, upon Desmatic's reccomendation, I switched to a PNY Verto geforce4 ti 4600.  I'm glad I did!  Man, this card rocks totally!  Advancemame, Windows, whatever.  To me, the Advancemame images are BETTER than the T64 and you can use device_video auto again.

If you are stuck with Advancemame, I recommend you check out Desmatic's site.  His info will get you up and running.

http://easymamecab.mameworld.net/

[whammoed]

That card works great in dos it seems, but in linux you can't use pclock lower than 8, which would give me the same problem.  What I am looking for is a perfect card for linux that would give me a pclock down to 5.  We mostly like those old very low res games at my house like pacman and donkey kong which require the very low pclock.  If I can't get those to emulate perfectly I will probably choose a different option than linux.  I have visited that site quite a bit but it doesn't seem as if there is a card for linux listed that will do the low pclock.  Maybe I'm incorrect on this, is there a way to contact Desmatic?

[uepa]

Send him a PM, he frequents this forum.  Hunt down a PNY Verto geforce4 ti 4600.  It can do the low pclocks and is great in linux.  If you find one new, they can be upwards of $200!  Try ebay for a used one, got mine for $80.  Well worth it.

[whammoed]

according to his website that card only does low pclock in dos, in linux it is only good for 8 and higher

[desmatic]

I am using advance mame to run a wells gardner d9200 with a matrox g400.  For some reason I cannot seem to get the 15K resolutions to work right.  for example 15khz and 60hz is requested but the measured value is around 18khz and 73hz...I would think this would give me an out of range display on the monitor???  I confirmed the rates by hitting "mode" on the monitors adjustment board.
Question:  Is it because the matrox g400 cannot do a pclock below 7 (i read that somewhere)?I checked some resolutions with a pclock above 7 and did achieve the proper 15Khz refresh.
I have a trident blade 64, should I try that?(using gentoo linux which seems to have a driver for trident now.



HELP

anyone else using a d9200 with advancemame?  if so, what video card are you using???
Maybe i should get an arcadevga and be done with it...but i'm really liking linux

Hey uepa, glad that PNY card worked out for ya.  But  whammoed, I don't think it's your video cards pclock that's hurting you.  It sounds like a configuration issue, though it could be a driver issue as well.  As far as the config stuff goes, just try my config and see if it helps.  I imagine it will solve most of your problems.

If you think it's a driver issue, post your kernel version, mameversion, and advmame.rc file and we can nail down the problem.

For the D9200 use the following lines in your advmame.rc config (don't use the advcfg.exe utility unless you're feeling adventurous).


display_adjust generate_yclock
device_video_interlace no
device_video_pclock 5-90
device_video_hclock 15-16.75, 24-26, 31-32.5
device_video_vclock 50-85
display_restore no
vector/device_video_hclock 31-32.5
192x256/device_video_hclock 15-16.75
208x248/device_video_hclock 15-16.75
208x256/device_video_hclock 15-16.75
216x288/device_video_hclock 15-16.75
224x248/device_video_hclock 15-16.75
224x256/device_video_hclock 15-16.75
224x264/device_video_hclock 15-16.75
224x272/device_video_hclock 15-16.75
224x280/device_video_hclock 15-16.75
224x288/device_video_hclock 15-16.75
232x264/device_video_hclock 15-16.75
234x256/device_video_hclock 15-16.75
236x272/device_video_hclock 15-16.75
240x256/device_video_hclock 15-16.75
240x280/device_video_hclock 15-16.75
248x256/device_video_hclock 15-16.75
256x256/device_video_hclock 15-16.75
device_video_format 15750 0.780488 0.0487805 0.0731707 0.097561 0.885496 0.0381679 0.0114504 0.0648855
display_color bgr16
misc_quiet yes

The rest is just default (i.e. advmame -default)

[whammoed]

desmatic,

thanks, i will try it today.  I guess I am confused though.  On your web site it states the g400 is only good for pclock down to 7.  It seems that the low resolutions at 15Khz require lower pclock than that.  Is this not true?

[uepa]

No, in fact I haven't seen too many games (if any) use a pclock lower than 8 at 15khz.  Try using advcfg for fun, and you will see what I mean.  Basically, you don't need such a low pclock to run games at 15khz.

[whammoed]

desmatic, i tried your configuration and have the same problem.  For example when i run rallyx and hit mode on my monitors controls it displays 20.9Khz 83Hz
I am running advmame 0.83.0
kernel version is 2.6.5 and have the frame buffer support configured in the kernel

uepa, i looked into advcfg and advv and when I choose the low resolutions it always shows pclocks in the 5 range.
If we don't need low pclocks why don't we set
device_video_pclock 8-90
instead of
device_video_pclock 5-90 ??



I hate to add more grief to this thread but I also can't get advmame to recognize a mouse.  I have event interface compiled in kernel.  I have event(s) in /dev/input.  When i cat the event and move the mouse I get junk on the screen like I should.  in advmam.rc i have device_mouse event
when I use advm it says it unable to initialize the mouse driver.  the errors are:
event: no mouse found
raw: no mouse found
I have kde installed, and I noticed advmame does not work unless i install kde first.  I suppose it needs something that gets installed when I emerge kde.  Gave some oslang error before i installed it.  Don't know if this helps but I thought i'd mention it.

[desmatic]

desmatic, i tried your configuration and have the same problem.  For example when i run rallyx and hit mode on my monitors controls it displays 20.9Khz 83Hz
I am running advmame 0.83.0
kernel version is 2.6.5 and have the frame buffer support configured in the kernel

uepa, i looked into advcfg and advv and when I choose the low resolutions it always shows pclocks in the 5 range.
If we don't need low pclocks why don't we set
device_video_pclock 8-90
instead of
device_video_pclock 5-90 ??



I hate to add more grief to this thread but I also can't get advmame to recognize a mouse.  I have event interface compiled in kernel.  I have event(s) in /dev/input.  When i cat the event and move the mouse I get junk on the screen like I should.  in advmam.rc i have device_mouse event
when I use advm it says it unable to initialize the mouse driver.  the errors are:
event: no mouse found
raw: no mouse found
I have kde installed, and I noticed advmame does not work unless i install kde first.  I suppose it needs something that gets installed when I emerge kde.  Gave some oslang error before i installed it.  Don't know if this helps but I thought i'd mention it.

It sounds like a driver issue to me.  You might want to try an earlier kernel version or advancemame version.  The last kernel I tested with a Matrox card was 2.6.1 (been slack about testing the latest kernels).  2.6.1 worked well for me, but there has been a large number of regressions reguarding fb support in 2.6.x kernels.  I'll try and test your setup and see what I come up with.  I wouldn't be surprised if its the fb driver.  The 2.4.22 (and most likely the 2.4.6) kernels have the most stable fb drivers.  Use andrea's patches from advancecd for best results.  As far as the mouse is concerned, I wouldn't know where to start, as I don't use a mouse on my setup.  Actually, I don't even use linux on my setup for that matter.  Not yet at least. Got tired of the fb troubles.  My MAME cab is the only surviving windows box I own.

Try AdvanceCD and see if your mouse works with it.  If it does, then it's a configuration issue or something equally silly.  I think advancemame uses the kernels console input drivers, but I can't really recollect to tell you the truth.

As far as KDE, I suspect its installing SLANG, NASM, SDL, or ZLIB.  Those are the only dependancies that I know of.  Most likely it's SDL.

I forgot to mention, you need to disable DRI for your card in the kernel config.  The DRI drivers can goof up the fb drivers.

[whammoed]

desmatic, i will try that, but could you explain this pclock thing?  
from your website:
Arcade monitors usually run at around 7mHz (though some resolutions go a little lower, all the way down to 5mHz for very low resolutions). This is why arcade monitor setups require a video card that can handle very low pclocks. From my personal experience, ATI cards and Trident's Blade T64 can handle pclocks as low as 5 (possibly lower, though it doesn't matter), Matrox's G400 can safely go down to 7, and Nvidia cards can go down to 8 in Linux and 5 in Win9x (DOS). If your running AdvanceMAME on a 15 kHz monitor you really should get a card that supports a pclock of at least 7, as anything 8 or higher could be restricting.

when I use advv and look at the pclock required for say pac man resolution it says 5.something

Am I looking at this wrong?

[wpcmame]

desmatic, i will try that, but could you explain this pclock thing?  
from your website:
Arcade monitors usually run at around 7mHz (though some resolutions go a little lower, all the way down to 5mHz for very low resolutions).

The beam travels from left to right on the monitor with a constant speed. This means that the higher the pixel clock, the "shorter" each pixel will be (i.e. more pixels can fit on one line).
You generally use the pclock to get the correct pixel aspect ratio for the game.

This is why arcade monitor setups require a video card that can handle very low pclocks.

That is not true. Monitors are analog equipment and knows nothing about pixels.
If your graphic card can't handle low pclocks, just double the horizontal resolution and let the card send each pixel twice.

when I use advv and look at the pclock required for say pac man resolution it says 5.something

That depends on how your monitor is set up. My monitor is setup so that 7.3MHz gives square pixels (should be a common setting). That means that a pclock of 5 would give pixels that are much longer than high (lower pclock=longer pixels). If I remember correctly, pacman should  have almost square pixels so a pclock of 5 seem wrong to me.

[desmatic]

desmatic, i will try that, but could you explain this pclock thing?  
from your website:
Arcade monitors usually run at around 7mHz (though some resolutions go a little lower, all the way down to 5mHz for very low resolutions).

The beam travels from left to right on the monitor with a constant speed.

Yes, this is true, assuming the monitor is fixed frequency like an arcade monitor.

This means that the higher the pixel clock, the "shorter" each pixel will be (i.e. more pixels can fit on one line).

It also affect the refresh rate, depending upon how you look at it.  On a fixed freqency monitor a high pclock means either a fast refresh rate, or a large resolution.

You generally use the pclock to get the correct pixel aspect ratio for the game.

Yes.

This is why arcade monitor setups require a video card that can handle very low pclocks.

Arcade monitors require low pclocks video cards because they run small resolutions at low refresh rates.  240x240X60 is around 7mHz (give or take a few mHz, depending upon your monitor configuration)

That is not true. Monitors are analog equipment and knows nothing about pixels.

I understand what you are saying here, but you're forgetting about the electron gun.  The pclock affects the speed of the CRTs electron gun and also affects the blanking time for your monitor.  If you send to many pixels per second to your monitor you could easily destroy it / shorten its life.  You might also not be able to get your image to fit your screen.
 
If your graphic card can't handle low pclocks, just double the horizontal resolution and let the card send each pixel twice.

This works beautifully if your monitor safely supports the higher pclock.  In fact, its generally better to double the horizontal res whenever possible.  A high pclock reduces the 8 dot mutiple rounding error so your modes will have better centering.  It also has absolutely no affect on the quality of the image rendered.  You can always scretch horizontally, its when you strech vertically that things go astray (.i.e wrong scanlines).

when I use advv and look at the pclock required for say pac man resolution it says 5.something

That depends on how your monitor is set up. My monitor is setup so that 7.3MHz gives square pixels (should be a common setting). That means that a pclock of 5 would give pixels that are much longer than high (lower pclock=longer pixels). If I remember correctly, pacman should  have almost square pixels so a pclock of 5 seem wrong to me.

Don't focus on the shape of the pixel.  The math is too messy, aspect ratios of aspect ratios of aspect ratios, it gets involved.  Just use the formula's on my site or use your eyes / tape measure.  Image's should always be 4 parts wide to 3 parts tall.

No one seems to follow me here, which I'm sure is my fault, but here goes a more elaborate explanation.  When you setup advancemame on a monitor you must do two things.  You must configure your video card for a certain blanking time (the advcfg.exe utlity) and you must configure your monitor for a certain blanking time (arcade monitor controls).  If they don't match, then the image doesn't take up the whole screen or it overscans.  Naturally on a good quality arcade monitor there is alot of slop here, especially on modern ones like the D9200.  On cheap monitors, theres not much slop here at all (TVs, for example).  This means that if you have a problematic monitor that doesn't have that much slop then you pretty much have to run games between 5-8mHz, as that's the only bandwidth it can handle.

If you were to throw caution to the wind to search for the highest pclock your configuration could run at, then all you'd have to do is enlarge your screen as much as possible using your monitor controls,and then decrease the horizontal resolution in the advcfg.exe utility until it fits the screen.  That's it.  Any higher and the image is underscanned  The difference between the largest image you can get and the smallest image you can get to fit the screen basically defines the slop in your setup.  So for a Matrox card in linux, for example, you'd decrease the horizontal res in the advcfg.exe utility until you got to around 8, then you'd center your screen using your arcade monitor controls.  Now all your games will run at a higher pclock.  On the D9200 this is no big deal.  On a cheapo TV, good luck.  Becasue the whole issue with a large pclock video card is that if you configure your monitor to run 240x240@60 at 8mHz (aside from possibly destroying it) is that you won't be able to get your images to take up the full screen.


...and that's the rest of the story.  I'll have to add to my site.  Your not the only one who's having problems understanding my garbled writings.  Hope I didn't confuse you more here.

[whammoed]

Hmmm, ok, maybe I see what you are saying...
lets look at RallyX as an example:
resolution = 288 x 224 @ 60Hz
so I would increase from 288 to something like 400 x 224 @60Hz and then adjust the monitors controls so the game itself fills the screen?
Do you know of a card for linux that does low pclocks so this isn't necessary?

thanks again,

[wpcmame]

Hmmm, ok, maybe I see what you are saying...
lets look at RallyX as an example:
resolution = 288 x 224 @ 60Hz
so I would increase from 288 to something like 400 x 224 @60Hz and then adjust the monitors controls so the game itself fills the screen?

No, you select a resolution of 576x224@60Hz and then let advmame double the game horizontally.

[whammoed]

Thanks, wpcmame, I actually understood your suggestion already and I will give it a try.  I appreciate the posts, learning a lot i think.
I should have been more specific, I am trying to see if I understand Desmatic correctly or not.
I am most interested in Arcade Perfect resolutions for all games (except vector of course).  Don't care if I have to buy a different video card.  If it can't be done in linux, then it can't.  Thought I would give it a go.

[wpcmame]

Don't focus on the shape of the pixel.  The math is too messy, aspect ratios of aspect ratios of aspect ratios, it gets involved.  Just use the formula's on my site or use your eyes / tape measure.  Image's should always be 4 parts wide to 3 parts tall.

I know we will never agree on this but I think the pixel aspect ratio is the most important thing when you want an "arcade perfect" display. (Don't  understand why so many people think that if they just use the same resolution as the game got the display is "perfect")
I always calculate the pixel aspect ratio the game originally used which gives me the pixel clock to use.

With the pclock (and refresh rate) it is easy to create a modeline that works with my monitor. (resolution is unimportant as long as the game display fits)

Example:
RallyX 288x224x60.6Hz
Pixel aspect ratio: 28:27 (224*4/(288*3))
Pixelclock: 7.375*27/28=7.112 (7.375MHz is where my monitor got 1:1 pixels)

7.112MHz/15750kHz=>448 pixels/line (rounded to nearest 8 )
7.112Mhz/448/60.6=>262 lines/frame

Modeline will look like
7.112 288 hsync 448 224 vsync 262

I use advv to find the hsync anc vsync values so that the display is stable and centered on the monitor.

[whammoed]

Modeline will look like
7.112 288 hsync 448 224 vsync 262

So how do you make it fill the screen?  Adjust with monitor controls?  Or just leave the black borders?

[desmatic]

Hmmm, ok, maybe I see what you are saying...
lets look at RallyX as an example:
resolution = 288 x 224 @ 60Hz
so I would increase from 288 to something like 400 x 224 @60Hz and then adjust the monitors controls so the game itself fills the screen?
Do you know of a card for linux that does low pclocks so this isn't necessary?

thanks again,

Yes, that's correct.  You have the right idea, its just that you want to do this in the advcfg.exe utlity.  You need to understand that you can only set the blanking time for your monitor once.  This is what the advcfg.exe utlity is for, setting the blanking time.  So you would launch the advcfg.exe utility, shrink your screen using your key board until you reach 8 or something (it should start out near 5), and then center your screen using your arcade monitor controls until the screen fits perfectly.  The only thing you normally don't want to adjust in the advcfg.exe utlity is the height (not unless you really know what you are doing).  Unfortunately, this fine tuning is required for the D9200 to perfectly emulate all games. What makes the D9200 so tricky is need to use a wierdo blanking time, to take advantage of the monitors full horizontal range. So this is how the D9200 setup would go for linux and a matrox g400 card.

launch the advcfg.exe utility, select Arcade Standard CGA Resolution (15kHz), then select custom and enter

pclock 5-90
hclock 15.72
vclock 50-60

and press enter.  Now here comes the real magic.  Decrease the width of the screen using your keyboard until you have 8mHz.  Then decrease the height of your screen using your keyboard until you get 230 lines.  Save and exit.

Now edit your advmame.rc file and change
device_video_pclock pclock 5-90
device_video_hclock hclock 15.72
device_video_vclock vclock 50-60

to

device_video_pclock 5-90
device_video_hclock 15-16.75, 24-26, 31-32.5
device_video_vclock 50-85
vector/device_video_hclock 31-32.5
192x256/device_video_hclock 15-16.75
208x248/device_video_hclock 15-16.75
208x256/device_video_hclock 15-16.75
216x288/device_video_hclock 15-16.75
224x248/device_video_hclock 15-16.75
224x256/device_video_hclock 15-16.75
224x264/device_video_hclock 15-16.75
224x272/device_video_hclock 15-16.75
224x280/device_video_hclock 15-16.75
224x288/device_video_hclock 15-16.75
232x264/device_video_hclock 15-16.75
234x256/device_video_hclock 15-16.75
236x272/device_video_hclock 15-16.75
240x256/device_video_hclock 15-16.75
240x280/device_video_hclock 15-16.75
248x256/device_video_hclock 15-16.75
256x256/device_video_hclock 15-16.75

Then for simplicty sake, center the following games Gauntlet, 720 Degrees, and Asteroids using your arcade monitor controls.  That's it.  Perfect emulation!  If a game is slightly off center or slightly overscanned/underscanned, its due to rounding error.  There is always a small amount due to the 8 dot multiple.

If the above doesn't work then your kernel's video card driver is goofed (or possibly the advancemame version).  The above worked for me on 2.6.1, and I know it works perfectly with 2.4.22 (and probably 2.4.6).  This was all some time ago, on advancemame .78 or something.

If you give me a day or two, I'll create the perfect device_video_format for your setup and post it.  But the above is how I would do it.  I did it on LFS 5.0 and it worked beautifully.  

As wpcmame points out, you could just double the hres for all the games below something like 240, but it's lot of damn work.  The method above will do it for you all automatically, meaning you won't have to create a single modeline.

I just finished my LFS 5.1 system.  As soons as it's tweaked I'll post the source along with some device_video_formats better suited for Linux boxes.  Maybe it's time to kill the only windows box left in the house?

[desmatic]

Don't focus on the shape of the pixel.  The math is too messy, aspect ratios of aspect ratios of aspect ratios, it gets involved.  Just use the formula's on my site or use your eyes / tape measure.  Image's should always be 4 parts wide to 3 parts tall.

I know we will never agree on this but I think the pixel aspect ratio is the most important thing when you want an "arcade perfect" display. (Don't  understand why so many people think that if they just use the same resolution as the game got the display is "perfect")
I always calculate the pixel aspect ratio the game originally used which gives me the pixel clock to use.

With the pclock (and refresh rate) it is easy to create a modeline that works with my monitor. (resolution is unimportant as long as the game display fits)

Example:
RallyX 288x224x60.6Hz
Pixel aspect ratio: 28:27 (224*4/(288*3))
Pixelclock: 7.375*27/28=7.112 (7.375MHz is where my monitor got 1:1 pixels)

7.112MHz/15750kHz=>448 pixels/line (rounded to nearest 8 )
7.112Mhz/448/60.6=>262 lines/frame

Modeline will look like
7.112 288 hsync 448 224 vsync 262

I use advv to find the hsync anc vsync values so that the display is stable and centered on the monitor.

I don't quite follow you here,

7.112 288 hsync 448 224 vsync 262

I need your device video format to tell if your method is accurate.  Otherwise I don't know the default blanking time for your setup.  My calculations would have you at 304 active horizontal pixels, not 288, but maybe I don't follow your modeline above.



I calculate the xres for the modeline using the xres and yres of the game and the modeline's number of lines, usually this would be 240.  The whole idea behind this madness is, of course, to play a game in vsync with border instead of out of vsync with no border (which by the way is how ArcadeVGA works, though it only applies the borders to the top and bottom, slightly skewing the image)

 x_crt = (y_crt * x_game) / y_game

since you know y_game and x_game and you know the number of lines for your monitor, 240 on the standard setup this method is very easy and it always works regardless of the device_video_format/monitor's blanking configuration.

So I get

304 = (240*288) / 224

so in the advv.exe utlity you would enter in

304x240@60

Then configure rally x to use that modeline.

so you'd have a 7% border around your game but it would be in vsync

224/240 = 288/304 = 93%

[desmatic]

Don't focus on the shape of the pixel.  The math is too messy, aspect ratios of aspect ratios of aspect ratios, it gets involved.  Just use the formula's on my site or use your eyes / tape measure.  Image's should always be 4 parts wide to 3 parts tall.

I know we will never agree on this but I think the pixel aspect ratio is the most important thing when you want an "arcade perfect" display. (Don't  understand why so many people think that if they just use the same resolution as the game got the display is "perfect")
I always calculate the pixel aspect ratio the game originally used which gives me the pixel clock to use.

With the pclock (and refresh rate) it is easy to create a modeline that works with my monitor. (resolution is unimportant as long as the game display fits)

Example:
RallyX 288x224x60.6Hz
Pixel aspect ratio: 28:27 (224*4/(288*3))
Pixelclock: 7.375*27/28=7.112 (7.375MHz is where my monitor got 1:1 pixels)

7.112MHz/15750kHz=>448 pixels/line (rounded to nearest 8 )
7.112Mhz/448/60.6=>262 lines/frame

Modeline will look like
7.112 288 hsync 448 224 vsync 262

I use advv to find the hsync anc vsync values so that the display is stable and centered on the monitor.

I don't quite follow you here,

7.112 288 hsync 448 224 vsync 262

I need your device video format to tell if your method is accurate.  Otherwise I don't know the default blanking time for your setup.  My calculations would have you at 304 active horizontal pixels, not 288, but maybe I don't follow your modeline above.



I calculate the xres for the modeline using the xres and yres of the game and the modeline's number of lines, usually this would be 240.  The whole idea behind this madness is, of course, to play a game in vsync with border instead of out of vsync with no border (which by the way is how ArcadeVGA works, though it only applies the borders to the top and bottom, slightly skewing the image)

 x_crt = (y_crt * x_game) / y_game

since you know y_game and x_game and you know the number of lines for your monitor, 240 on the standard setup this method is very easy and it always works regardless of the device_video_format/monitor's blanking configuration.

So I get

304 = (240*288) / 224

so in the advv.exe utlity you would enter in

304x240@60

Then configure rally x to use that modeline.

so you'd have a 7% border around your game but it would be in vsync

224/240 = 288/304 = 93%

Holly molly, I think I understand what you are doing.  It's very clever, but boy is that the hard way.  You really have to make sure your little boxes are square.  You'd probably be better off just calculating the whole thing, as opposed to reverse engineering it.  But if your eye is good, and your happy with your method, groovy.  It's certainly interesting.  Normally the active time is just that, active, but I think what you are doing is simply increasing the inactive time so that the image gets smaller, if I understand you correctly.  It's really hard to say, as I'd need to see your device_video_format and one of your adjusted modelines to verify your results mathematically.

[wpcmame]

I don't quite follow you here,

7.112 288 hsync 448 224 vsync 262

I need your device video format to tell if your method is accurate.  Otherwise I don't know the default blanking time for your setup.

Why do you need that? Anyway here it is:
Monitor retrace time: 12us = 85 pixels (88)
HSync 3.8us = 27 pixels (32)

This means that the horizontal sync must start the latest at 448-88-32=328 but lets start at 320 to be safe. The horizontal modeline would then be

288 320 352 448

Monitor blanking time 1ms = 16 lines
VSync 64us = 1 line

The vertical sync must start the latest at 262-16-1=245 but lets say 240 to be safe
The complete modeline would then be

7.112 288 320 352 448 224 240 241 262

I might still need to center the picture with advv

My calculations would have you at 304 active horizontal pixels, not 288, but maybe I don't follow your modeline above.

Huh, the number of active pixels are unimportant (as long as it is above 288 ofcourse). The game only uses 288 pixels so all others will be black anyway. What is the difference between a black pixel and an inactive? The monitor don't care.

...
so in the advv.exe utlity you would enter in

304x240@60

Then configure rally x to use that modeline.

so you'd have a 7% border around your game but it would be in vsync

224/240 = 288/304 = 93%

So you set up a resolution of 304x240 that fills the entire monitor. The pixel aspect ratio will then be 20:19 which is not what the game originally used (close but not exact)

[desmatic]

I don't quite follow you here,

7.112 288 hsync 448 224 vsync 262

I need your device video format to tell if your method is accurate.  Otherwise I don't know the default blanking time for your setup.

Why do you need that? Anyway here it is:
Monitor retrace time: 12us = 85 pixels (88)
HSync 3.8us = 27 pixels (32)

This means that the horizontal sync must start the latest at 448-88-32=328 but lets start at 320 to be safe. The horizontal modeline would then be

288 320 352 448

Monitor blanking time 1ms = 16 lines
VSync 64us = 1 line

The vertical sync must start the latest at 262-16-1=245 but lets say 240 to be safe
The complete modeline would then be

7.112 288 320 352 448 224 240 241 262

I might still need to center the picture with advv

My calculations would have you at 304 active horizontal pixels, not 288, but maybe I don't follow your modeline above.

Huh, the number of active pixels are unimportant (as long as it is above 288 ofcourse). The game only uses 288 pixels so all others will be black anyway. What is the difference between a black pixel and an inactive? The monitor don't care.

...
so in the advv.exe utlity you would enter in

304x240@60

Then configure rally x to use that modeline.

so you'd have a 7% border around your game but it would be in vsync

224/240 = 288/304 = 93%

So you set up a resolution of 304x240 that fills the entire monitor. The pixel aspect ratio will then be 20:19 which is not what the game originally used (close but not exact)

With out your device_video_format it's really impossible to say what's going on, but at 288/448 = 64% this is quite low.  If I assume you've set up a typical 80% active, and you're only supposed to have a 7% border then you should have a total active time of around 75% (7% of 80%), which is not what you have, so something must be wrong.  I don't know what to tell you.  You'd have to have a setup of 68% active for your method to be on.  Which I'd guess is unlikely but without the device_video_format, I can only guess.

My method is mathematically perfect.  The only error is due to rounding (as the xres has to be a factor of 8 ).

308.571428571428 = (240*288) / 224

224/240=.933333333333333
288/308.571428571428=.9333333333333335

since your must round to a factor of 8, i simply chose 304 (but for the extra .04% you could as easily round up to 312).

224/240=.933333333333333
288/304=.947364210526316

Unless you feel like doubling the xres, this is as accurate as you can get.

[wpcmame]

With out your device_video_format it's really impossible to say what's going on, but at 288/448 = 64% this is quite low.  If I assume you've set up a typical 80% active, and you're only supposed to have a 7% border then you should have a total active time of around 75% (7% of 80%), which is not what you have, so something must be wrong.  

My monitor requires 12us retrace + ~4us sync and that is independent of the pixelclock and resolution. The strange thing is that advmame requires these values to be a precentage of the resolution.
With a pclock of 7Mhz it means that at least 112 pixels must be inactive which is 25% with 448 pixel lines. Your monitor might have shorter retrace and sync requirements so it works with less inactive pixels but I don't understand why it matters in this case.

And once again, the number of active pixels doesn't matter. I can create modelines with 288, 296, 304, 320... active pixels and the display will look exatly the same as long as I don't change the pclock and display end values. I think it is easier to understand that a 288x224 game use a 288x224 mode instead of 304x240.

My modelines for vertical games got only 40% active pixels for the same reason.

[desmatic]

My monitor requires 12us retrace + ~4us sync and that is independent of the pixelclock and resolution.

This isn't correct.  You seem to be really confused about what the pixel is and what it's used for and how it affects the retrace, sync of your monitor.

The strange thing is that advmame requires these values to be a precentage of the resolution.

It's not just AdvanceMAME, X11, fbset, Windows, VESA (Geneneral Timing Formula) similarly use percentages.

With a pclock of 7Mhz it means that at least 112 pixels must be inactive which is 25% with 448 pixel lines. Your monitor might have shorter retrace and sync requirements so it works with less inactive pixels but I don't understand why it matters in this case.

I don't follow you here at all.

And once again, the number of active pixels doesn't matter. I can create modelines with 288, 296, 304, 320... active pixels and the display will look exatly the same as long as I don't change the pclock and display end values.

I don't really follow you here either, but you do have to increase the pixel clock of the original mode inorder for it to display correctly (this is what causes the border).  

I think it is easier to understand that a 288x224 game use a 288x224 mode instead of 304x240.

Ya, maybe.  But when you say 288x224, it could mean anything, as you're manually modifed the blanking times.  So your 288x224 won't be the same on anyone elses setup.  In fact without the whole modeline and the device_video_format, 288x224 doesn't really mean anything.

My modelines for vertical games got only 40% active pixels for the same reason.

Again, I don't understand you here.  How do you get 40%?  Active pixels for vertical games should be 56.25%.

[wpcmame]

My monitor requires 12us retrace + ~4us sync and that is independent of the pixelclock and resolution.

This isn't correct.  You seem to be really confused about what the pixel is and what it's used for and how it affects the retrace, sync of your monitor.

Is my monitor manual incorrect?

The monitor don't know what a pixelclock is. How can the pixelclock affect retrace, sync and blanking which are analog circuits within the monitor?

You seem to lack some fundamental understanding on how the monitor controls the beam.

And once again, the number of active pixels doesn't matter. I can create modelines with 288, 296, 304, 320... active pixels and the display will look exatly the same as long as I don't change the pclock and display end values.

I don't really follow you here either, but you do have to increase the pixel clock of the original mode inorder for it to display correctly (this is what causes the border).  

So you mean that the following modelines will not all look exactly the same on the monitor when playing a game.

288x224x606 7.112 288 320 352 448 224 240 241 262
296x228x606 7.112 296 320 352 448 228 240 241 262
304x232x606 7.112 304 320 352 448 232 240 241 262
312x236x606 7.112 312 320 352 448 236 240 241 262

[desmatic]

Is my monitor manual incorrect?

The monitor don't know what a pixelclock is. How can the pixelclock affect retrace, sync and blanking which are analog circuits within the monitor?

The pixel clock is what is used to time the placement of the sync and its duration.

pixelclock x (h_sync_end - h_sync_start) = micorseconds for sync
pixelclock x (h_total - h_active) = microseconds for retrace

CRTs are dumb devices.  Like speakers, they only do what you tell them to do.  The specifications for a CRT only tell you the bounds for what it is capable of handling.  Just like a set of speakers will list what they are capable of, watts, distortion, THX, etc.  So even while my speakers may say THX, that doesn't mean I get THX sound when I hook them up to my sister's ipod.  Same goes for when a CRT says 15.75kHz, that doesn't mean that's that's the speed it runs at, it means that that's the speed it was designed to run at.  There's a difference.  The video signal decides what speed a CRT runs at, which is why when you hook up a video card that is sending the wrong signal, say 31kHz, you'll end up with a garbled display / broken monitor.

So you mean that the following modelines will not all look exactly the same on the monitor when playing a game.

288x224x606 7.112 288 320 352 448 224 240 241 262
296x228x606 7.112 296 320 352 448 228 240 241 262
304x232x606 7.112 304 320 352 448 232 240 241 262
312x236x606 7.112 312 320 352 448 236 240 241 262

Yes, that's what I mean.  The screens here are getting progressively larger.

[wpcmame]

The pixel clock is what is used to time the placement of the sync and its duration.

Yes, but that is because the graphics card works with pixels, not microseconds.

pixelclock x (h_sync_end - h_sync_start) = micorseconds for sync
pixelclock x (h_total - h_active) = microseconds for retrace

That is wrong. Retrace is the time it takes for the beam to return to the left edge (12us on my monitor). The retrace starts when the monitor detects the sync pulse (which got nothing to do with the active pixels). Once the beam has moved back to the left edge it starts moving to the right again. That is how you control the centering. If you have a long time between the sync pulse and h_total the image will be moved to the right. I thought you covered this on your website.

So you mean that the following modelines will not all look exactly the same on the monitor when playing a game.

288x224x606 7.112 288 320 352 448 224 240 241 262
296x228x606 7.112 296 320 352 448 228 240 241 262
304x232x606 7.112 304 320 352 448 232 240 241 262
312x236x606 7.112 312 320 352 448 236 240 241 262

Yes, that's what I mean.  The screens here are getting progressively larger.

Try it and you will be surprised.  The pixelclock is the same so the pixels are the same size in all modes (i.e. the game display will also be the same szie). In advv the grid will be larger since it alwys fills the entire active area but advmame just blanks the extra pixels (above 288x224) so  the image will look exactly the same.

[desmatic]

Yes, but that is because the graphics card works with pixels, not microseconds.

That is wrong. Retrace is the time it takes for the beam to return to the left edge (12us on my monitor).

The retrace starts when the monitor detects the sync pulse (which got nothing to do with the active pixels).

Ya, you're technically right, the front porch usually isn't included, but I didn't feel like reexplaning 2 pages of details I've already covered in my tutorial.  And besides the front porch is so small that it typcially doesn't matter.  The front porch hasn't mattered much for a very long time, like since before I was born.

Once the beam has moved back to the left edge it starts moving to the right again. That is how you control the centering. If you have a long time between the sync pulse and h_total the image will be moved to the right. I thought you covered this on your website.

The syncstart is how you control the centering.  And it's not covered in my tutorial (I know, because I've been meaning to add it).  The rest don't directly affect centering, they affect the size of the visible display and wheather or not it works (or is garbled or there's a visible retrace, etc).

Try it and you will be surprised.  The pixelclock is the same so the pixels are the same size in all modes (i.e. the game display will also be the same szie). In advv the grid will be larger since it alwys fills the entire active area but advmame just blanks the extra pixels (above 288x224) so  the image will look exactly the same.

The pixels are the same size because you're not recentering your screen after you've changed the blanking times, which is down right wierd.  If it can't be displayed, I hardly consider it an active pixel.  The way you use active pixels is confusing and doesn't make any sense.

I finally know what I've needed to know for quite some time now, and that's your device_video_format.   You've obviously chosen the first mode as your reference mode (you've centered it with your monitor controls).  The rest of the modes are simply overscanned that's why the pixels look the same.  Any ya as long as you only display less than 288x224 you won't see it, but that's just because it's off the screen.  As soon as you display a game larger than 288x224 the effect is obvious.  This whole method is wierd, doesn't follow nomenclature, and I don't understand the  reasoning behind it.  What in gods name are you trying to accomplish? If you're using this method to create all your modes, you are deffinitely doing things the hard way.  It'd be easier to manufacture gold fusing hydrogen.

[uepa]

Is it just me, or has this become way more difficult than it has to be?

[whammoed]

Desmatic,
I tried what you said, and it "worked".  at a pclock of ~ 7.67 I achieve 15.7Khz as read by the monitor.  However the screen is shrunk so far horizontally I cannot make the game fill the screen with the monitors controls:

[whammoed]

Here is a picture of the game maxed out:
Any other ideas? I tried a Radeon 7000 today as well and it was much worse.  Should I give good ole andy some more of my business and go with avga on Windblows XP?  I really don't want to waste a hyperthreading p4 on Dos. Still haven't got the trackballs working either.  Spending too much time on this.

[desmatic]

Ok I tried it out, and maxed out at 6 like you did.  So there isn't as much slop as I'd hoped there'd be.  I then tried the following

pclock 6-90
hclock 15.75
vclock 50-60

in the advcfg.exe utility and managed to get my pclock up to 7.5 which should be enough.  This mean's that any resolution below 320x240 will require doubling, which is pretty anoying if you ask me, but doable.  Right now I don't think Linux is such a great choice.  But tonight I'll test out the 2.4.6 kernel and see if andrea's patches make any diffference and I'll test both my matrox card and my nvidia card to see if there is any hope.  There is also svgalib, which I haven't played around with in a while but it's been patched to work on 2.6 kernels, so there is that also.

You could get an arcadevga if you want winxp, but you'll always have a border on 224 line games, and you'll loose 25kHz games.  I guess it depends on what you're up for.  You could also use a dual boot system.

[desmatic]

ok here are the results of some tinkering

2.4.26 with andrea's linux-2.4.22-rivafb-0.9.4c.diff patch
all of this was on a pure LFS 5.1.1 / BLFS 5.1 system with advancemame .83.1

PNY Geforce TI 4600 was a no go at all on gcc 3.3.3 kernel, but on gcc a 2.95.3 kernel I got a little something.  I could at least make it through the advcfg.exe utlity using

pclock of 8-90
hclock 15.75
vclock 50-60

But for the most part this card was useless.  I remember it working in 2.4.22 kernels, so I dunno what's happened since.

With the matrox g400 (gcc 2.95.3 kernel) I got great results, however, the lowest possible pclock I could get to work was 7.  I got 5 to work occasionally, but anything between 5-7 was unpredictable/unreliable.

Tomorrow I'll test the svgalib driver.  I'm hoping that it works just as well in linux as it does in dos.  Give me another day or two before you give up on linux.  I didn't try very hard earlier to get a Linux setup running, but now I'm a little more deturmined to make it work.  

[wpcmame]

Is it just me, or has this become way more difficult than it has to be?

Yes it did and the funny thing is that we are both doing the same thing.

Desmatic thinks the best way to get correct proportions is to increase the resolution and then lower the pclock to fit the new resolution on the screen.
 
I think it is easier to keep the original resolution and calculate what the correct pixelclock should be but that seem to be against desmatic's religion or something
"This whole method is wierd, doesn't follow nomenclature, and I don't understand the  reasoning behind it."

The other discussion where he says that the pixelsclock (or resolution) affects the speed of the beam, monitor retrace and blanking time is just so strange that I couldn't resist pointing it out.

Desmatic and I will never agree on how arcade monitors work. This whole thing reminds me of an email discussion we had about a year ago. Desmatic then tried to convince me that I could change the distance between the lines on the monitor by altering the refreshrate (maybe he still think it is possible).

[uepa]

I have never used Linux myself, but it's obviously far more challenging to get advancemame up and running with it.  Do you have a aversion to using DOS?  My cab works perfect using DOS, Advancemame/Advancemenu, D9200, and also have used a G400, T64, and a TI 4600.  All of them have been up and working perfectly at one point or another.

[whammoed]

uepa,
The hardware I have would be wasted in DOS.  Plus my input devices are usb.

[desmatic]

Is it just me, or has this become way more difficult than it has to be?

Yes it did and the funny thing is that we are both doing the same thing.

Desmatic thinks the best way to get correct proportions is to increase the resolution and then lower the pclock to fit the new resolution on the screen.
 
I think it is easier to keep the original resolution and calculate what the correct pixelclock should be but that seem to be against desmatic's religion or something
"This whole method is wierd, doesn't follow nomenclature, and I don't understand the  reasoning behind it."

The other discussion where he says that the pixelsclock (or resolution) affects the speed of the beam, monitor retrace and blanking time is just so strange that I couldn't resist pointing it out.

Desmatic and I will never agree on how arcade monitors work. This whole thing reminds me of an email discussion we had about a year ago. Desmatic then tried to convince me that I could change the distance between the lines on the monitor by altering the refreshrate (maybe he still think it is possible).

You're killing me, man.  If the lines aren't adjusted between displays of different vclocks then why would the Video Electronics Standard Association publish methods for adjusting the number of lines your monitor displays using the vclock as in the General Timing Formula, why would advancemame do something similar, how would Ultimarc's ArcadeVGA display 256 lines at 53.2 Hz for mk games?  Perhaps they're wrong?  Maybe my puckman game isn't at 50Hz fullscreen?  Maybe it's all an illusion and I just need a new set of glasses or something.  I just don't understand where you are getting this stuff.

I'm also curious as to what the pixel clock affects.  I mean it doesn't seem to affect the sync, the retrace, or the speed at which the electron gun operates, what does it affect?

And I'm not lowering the pclock to display a game correctly.  I'm simply running a smaller resolution game in a larger resolution modeline.  Kinda like what happens when you open up real player which is running at 800x600 pixels in a 1280 x 1024 pixel resolution.  It's not such a novel idea, I mean every imaging program in a windows environment does it.

[desmatic]

holly #@$!, I think i've got it.  It took me a bit of reading and some tinkering, but with svgalib, Linux support should be as good as DOS.  I didn't test it extensively, but everything I did test worked great.  I'll try to post the source/howto tonight but here's the basics of my config

PNY Geforce4 TI 4600 (I'll test the matrox shortly)
LFS 5.1.1 kernel 2.4.26 (gcc 2.95.3)
advancemame 0.82.0 from source (gcc 3.3.3)
svgalib 1.9.19 with advancemame .83 contrib patches (gcc 2.95.3)

advmame.rc parameters
device_video svgalib slang
device_video_pclock 5-90
device_video_hclock 15.75
device_video_vclock 50-60

I couldn't get the advcfg.exe utlity to work, but the advv.exe utility seemed to work fine.  I tested all the default resolutions, especially the low res ones and they all looked beautiful.

Hang in there whammoed, I'll have a linux advancemame setup running better than dos by tomorrow.

[whammoed]

Cool, sounds good.  As I have said, if I have to buy a different card, so be it.  Quick question though:  what are these contrib patches you are talking about.  Where are they? What are they?  What do i do with them.  Thanks in advance.