Switchres: modeline generator engine

[bitbytebit]

I've been investigating the Linux kernel more and trying to find why the J-Pac setup doesn't seem to work with vblank/page flip interrupt setup of the Radeon DRM driver.  From what I can tell, the reason my d9800 works with the force option, or any arcade monitor would, is because it does do the DDC part although gives a basic empty EDID full of 0xFFFFFFFF or all ones.  Yet it does output an EDID, and in your logs (Calamity) I see no EDID seen at all compared with how mine just complains it's an invalid one (with the 4350, I'm assuming the AVGA actually does give an invalid EDID too, maybe this is another vbios change of the AVGA to do this even on a J-Pac?).  I think I am getting close to seeing something interesting, basically the DDC check may be what we need to short circuit and just create a invalid EDID full of ones and let the DRM layer of Linux pass that to the radeon and have it be happy with the j-pac after that (at least enable interrupts for the pageflip and vblank). The main interesting part of the logs, are that it never gets to even trying to check the EDID at all, which points to the first i2c transfer check for the DDC and getting the EDID data is where the failure must be happening and force-on/enable option isn't properly honored after that.  The only other possible thing I can see is that it actually is giving a valid EDID that isn't really right and so it's not saying any messages about a bad EDID, and yet that EDID doesn't allow interrupts and vblank (Which I am pretty sure this is not the case, seems like then we wouldn't need to force the output on at all for the first DVI port).

[Calamity]

I see what you mean and makes a lot of sense. If you are able to find that point in the code then maybe it could be modified for the case when we're forcing outputs so we fed it with a fake edid, that would be great. It's a very promising approach, and could be interesting to have a door for future testing with valid custom edids.

It seems videocards are not able to sense the jpac board in the same way they do with a monitor, I remember SailorSat mentioning that:
http://forum.arcadecontrols.com/index.php?topic=66402.msg982901#msg982901

So it could be that the videocard just doesn't go on with checking for the edid as it does not detect any monitor. I don't know if this feature has always been there or only the newer ones are affected. So maybe my ArcadeVGA only works because it's based on an older card (I'll try to get some logs with this one if I have the chance).

[SailorSat]

VGA cards usualy detect presence of a monitor by 75ohms resistance on the RGB pins.
The J-PAC doens't have any.
Another way of detection is a connection between pin 5 and 11, but most modern cards don't use that method.

[bitbytebit]

Calamity,

After doing more testing, I have found something interesting.  I am starting to wonder if the lack of vblank interrupts has some other cause than the J-Pac, seeing that the AVGA cab is on J-Pac and from the results of my tests.  I basically did some changes and forced EDID's, that doesn't seem to be a problem, so then bypassed the path taken for the lack of DDC, and oddly that doesn't make a difference (just makes every output say it's connected all the time, but still things work fine too when that's done).  The key though is that I started booting without any monitor connected and did see the same messages output you see, no EDID check and pretty much the same.  It still does vblank interrupts, page flipping, that way.  So from what I can tell, that is the most close to a J-Pac because there's nothing connected according to the hardware/kernel and still the interrupts happen here.  So there's this message though in your dmesg output:


Jan  6 12:14:24 GroovyArcade kernel: [    1.570616] radeon 0000:02:00.0: PCI: Disallowing DAC for device
Jan  6 12:14:24 GroovyArcade kernel: [    1.570678] radeon: No suitable DMA available.


Which is definitely a bit odd, and even though Alex Deucher didn't think that mattered I am starting to think it is the key.  That there's something different about Linux supporting your motherboard/processor and the Radeon iommu possibly.  That it essentially is refusing to run DMA and any kind of interrupts/transfers to that card, odd, my setup is a 4350 too, but if not the ATI card branding/setup difference it's something else probably. 

So we might not have a generic J-Pac issue, it may just be a non-supported hardware combination for advanced OpenGL/DRM vblank from the hardware and interrupts from the video card. 

I do have a test version you can try, I don't think it'll help but might at least be interesting and get past any possibility of it being something really that we can fix in the radeon driver code.  Otherwise this might be some completely different Linux kernel issue :/.

There's a test LiveCD version uploading in the LiveCD/Incoming/ folder right now, a Mini build so it's smaller, and when it appears in a few hours you can try it when you have time and see what the messages look like from it.  I'm still not sure if this is a good change, only if it helps this problem probably, else it's really kinda odd because it forces every arcade monitor to act more like mine with the d9800 and sees a false DDC but gets a NULL EDID (seems most likely my d9800 is just NULL/not there, but DDC is there still just doesn't find an EDID so it's in between J-Pac and a normal EDID monitor).

This will be the test version when it's uploaded :  LiveCD32-Mini-NMO-1.282-b299821.iso

Good news is the newer ISO I uploaded today has all the Multitasking + vsync support and on the 32 bit CD now I can use virtua racer with 130% cpu usage (both CPU's) and still get perfect vsync, so it's definitely no longer limited to the single CPU with that option after our patches to Mame for that.  I think running in that mode has probably made the waitvsync option feel a lot better, since it's now threading the two processes still, and also looks like it can really utilize both CPU's too.

[Calamity]

Here are the logs testing you new LiveCD32-Mini-NMO-1.282-b299821.iso, hope they help.

glxgears still shows a black screen so the issue is still there. I've turned debug messages on to get some info anyway.

It's interesting what you've tested by switching the monitor's cable off, it actually seems to point somewhere else now
And as you say, that DMA message might be the key.

[bitbytebit]

Here are the logs testing you new LiveCD32-Mini-NMO-1.282-b299821.iso, hope they help.

glxgears still shows a black screen so the issue is still there. I've turned debug messages on to get some info anyway.

It's interesting what you've tested by switching the monitor's cable off, it actually seems to point somewhere else now
And as you say, that DMA message might be the key.

Ah those logs are not from the new cd ...

[    0.000000] Linux version 2.6.36.2+ (root@arcade) (gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) ) #1 SMP Wed Dec 29 14:02:10 CST 2010

The new one should have this..
[    0.000000] Linux version 2.6.36.2+ (root@GroovyArcade) (gcc version 4.4.4 (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) ) #1 SMP Sun Jan 16 17:17:56 CST 2011

Mainly the Jan 16th timestamp

Guessing it got mixed up possibly, also checking on the cd the version.txt file for:
GroovyArcade Mini-NMO-1.282-b299821 32bit 01-16-2011_17:58:23
To help figure out if it's the right one, might be the logs.rar file was an older one from the last version posted there (downloaded it a few times and getting the same older logs ).

[Calamity]

Oh, let me check, I might have mixed the cds...

Checked the version.txt file: GroovyArcade Full-O-1.282-b299821 32bit 01-15-2011_22:03:46

So it's an old one isn't it? I'll download the right one later.

[bitbytebit]

Oh, let me check, I might have mixed the cds...

Checked the version.txt file: GroovyArcade Full-O-1.282-b299821 32bit 01-15-2011_22:03:46

So it's an old one isn't it? I'll download the right one later.

Yeah, that's the current Full version but not the test version in the LiveCD/Incoming/ folder .  Also Alex got back about this and sees that it's probably more of a pci issue or platform issue rather than a radeon issue.  He recommends adding this "pci=nomsi" kernel command line option when booting on your system and see if that fixes it (but not something generally we'd want to do, since it's only to fix that specific hardware and work around for now).  Also recommends reporting the issue upstream, after we test that and see if it fixes the issue.  Have you been able to edit the grub command line in the boot menu?   It's pretty easy, just have to press 'e', here's some instructions I found that may explain it better (how to remove the splash thing below, just basically add that pci=nomsi option somewhere in this line below)...

To modify the boot options within the grub menu, highlight the operating system you want to edit and press 'e'.  You may also want to highlight the 'kernel' line press 'e' to edit and remove the word 'splash' from the end of the line.
After making any necessary modifications you can press 'b' to boot that operating system.
These modifications will not persist across reboots.


Basically change this:

kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot CGADVI video=DVI-I-1:640x480ec

To this:
kernel /boot/vmlinuz real_root=/dev/loop0 looptype=squashfs loop=/livecd.squashfs initrd udev nodevfs cdroot pci=nomsi CGADVI video=DVI-I-1:640x480ec


Try with that change, and without it, using that test Live/Mini ISO (or even try this change with the one your using, since shouldn't matter which ISO this test is tried on).  I'm pretty sure this is more of a possible working change, while the test ISO might be interesting but I suspect it'll still not help the issue.

Here's an excerpt and the URL for the MSI info, basically if this works you'll need the output of 'lspci -v' (as root, sudo -s) and send it to them:

Code: [Select]

5.1. Disabling MSIs globally
298
299 Some host chipsets simply don't support MSIs properly.  If we're
300 lucky, the manufacturer knows this and has indicated it in the ACPI
301 FADT table.  In this case, Linux will automatically disable MSIs.
302 Some boards don't include this information in the table and so we have
303 to detect them ourselves.  The complete list of these is found near the
304 quirk_disable_all_msi() function in drivers/pci/quirks.c.
305
306 If you have a board which has problems with MSIs, you can pass pci=nomsi
307 on the kernel command line to disable MSIs on all devices.  It would be
308 in your best interests to report the problem to linux-pci@vger.kernel.org
309 including a full 'lspci -v' so we can add the quirks to the kernel.

The entire MSI howto: http://www.mjmwired.net/kernel/Documentation/PCI/MSI-HOWTO.txt

[Calamity]

I'll try to do that, however it's going to be difficult as I'm nearly blind during the grub part (jpac is not able to show a readable picture with this card). I'll let you know.

[bitbytebit]

I'll try to do that, however it's going to be difficult as I'm nearly blind during the grub part (jpac is not able to show a readable picture with this card). I'll let you know.

One way to do it, if you can open the ISO as files and edit the boot/grub.conf and boot/menu.lst files on there and do that to both of them, could be done that way.  I could make an ISO with that option too pretty easily.

[bitbytebit]

I'll try to do that, however it's going to be difficult as I'm nearly blind during the grub part (jpac is not able to show a readable picture with this card). I'll let you know.

One way to do it, if you can open the ISO as files and edit the boot/grub.conf and boot/menu.lst files on there and do that to both of them, could be done that way.  I could make an ISO with that option too pretty easily.

I am adding the nomsi option as the last option in Grub to choose, so you can test with that ISO hopefully.  Do you think that'll be able to get chosen with the monitor like it looks?  I think it'll be good to have it in there for cases like this, to be an option if the interrupts fail.  Hopefully it works that way, looks like it's not terrible to use that way, just automatically does it usually for certain motherboards and your most likely is one that needs this.  Seems that the others are also VIA ones and suspect no ones reported it yet.  At least the other test ISO should be interesting to see logs from and should have a new ISO with this kernel option up later today.

[Calamity]

Oh great if you can add that option, I'll be able to select it, it's readable to that point so I know where the text lines are but text itself is terribly distorted to the right and moving to the sides, specially the upper part. I'll test the Mini iso anyway to get the logs.

[bitbytebit]

Oh great if you can add that option, I'll be able to select it, it's readable to that point so I know where the text lines are but text itself is terribly distorted to the right and moving to the sides, specially the upper part. I'll test the Mini iso anyway to get the logs.

This version LiveCD32-Mini-NMO-1.283-1fd9849.iso should appear in the Incoming folder in a few hours, it'll have the nomsi option as the last choice in the Grub menu.

[Calamity]

I've finally tested LiveCD32-Mini-NMO-1.282-b299821.iso, logs attached.

The issue is still there. However there's something odd now, the desktop mode is doublescanned + interlaced, so I can only see the upper part. So adding that fake edid there seems to be having some unexpected effect.

I'll test the new one as soon as I can.

[bitbytebit]

I've finally tested LiveCD32-Mini-NMO-1.282-b299821.iso, logs attached.

The issue is still there. However there's something odd now, the desktop mode is doublescanned + interlaced, so I can only see the upper part. So adding that fake edid there seems to be having some unexpected effect.

I'll test the new one as soon as I can.

Yeah it actually doesn't use an EDID but just fakes the DDC so every interface is seen as 'connected'.  Makes sense sort of it does that odd doublescan/interlace thing since that's what happened in X Windows when we forced all interfaces on there too.  Hopefully the nomsi option fixes things for the interrupts, seems promising.  At least we know in general things should work fine for J-Pac, and now looks like you just have that one motherboard which is one of the lucky ones with a broken MSI and doesn't tell the system about it (I'm guessing in Windows they have it masked probably and so know to disable MSI, interestingly that motherboard was sold with the intent for Windows Vista support).  If we can confirm the MSI issue, then we'll be able to help the Linux kernel by submitting the bug about it and they can mask it in the kernel.  The others masked are similar VIA sounding models, so seems to make sense, just hopefully this is the source of the vblank bug.  The ISO should be done uploading in the next hour, so will be ready for you to test when you can.

[Calamity]

Sounds good, will keep an eye on it. It's been completely impossible to edit the grub line on my screen, hopefuly some day I have time to get back to that asm patch for it.

[Calamity]

       

It's working! Using this new grub option all is finally PERFECT! I can see glxgears running and vsynced, and I've been launching games with wahcade, all of them run at perfect 100% with on their correct resolutions. I'm eager to mount some drive to test all games, and hopefully install this on the hardrive soon. I'm happy you managed to figure this out, there have been so many obstacles in the way and this final one is finally beaten.

So it was that, I'm the lucky owner of one the problematic motherboards and it's a kernel issue. Hopefully they might do a fix for it, but at least with this boot option the problem is totally bypassed.

UPDATE: I've added the lspci -v output.

[bitbytebit]

     

It's working! Using this new grub option all is finally PERFECT! I can see glxgears running and vsynced, and I've been launching games with wahcade, all of them run at perfect 100% with on their correct resolutions. I'm eager to mount some drive to test all games, and hopefully install this on the hardrive soon. I'm happy you managed to figure this out, there have been so many obstacles in the way and this final one is finally beaten.

So it was that, I'm the lucky owner of one the problematic motherboards and it's a kernel issue. Hopefully they might do a fix for it, but at least with this boot option the problem is totally bypassed.

UPDATE: I've added the lspci -v output.

Great, that definitely is amazing that it took that to make it work and was just the msi issue.  I'll have to file a bug report at the kernel bugtracker website, so hopefully eventually won't be necessary to pick the other option.  Sounds like a good thing to have there for people to use in cases like these. 

Interested to see how it all works with different games on the CGA monitor, I'm actually looking to get a basic 19" and Jpac to have a some sort of cocktail test station to play around with the actual analog monitor like that and real Jamma connection.  Might get those 60n1 board vertical games and the 19n1 horizontal PCB too, would be interesting to have a test setup where I can run both originals and mame emulations one after another on the same monitor/setup.  Of course that is looking like a few months probably of saving/working on it gathering the stuff and figuring out about how to aquire or build the structure to hold it.  Sounds fun to actually see how this all looks on the true 19" standard CGA curved screen monitor in vertical and horizontal positions.  I think I've found one that is cheap, used with slight burnin and a Wells Gardner from around 2005, at least at the price around 150 US dollars w/shipping seems like a deal.

[dmarcum99]

Hi Guys!

I'm playing with switchres and I like it a lot.  Sorry I've been in and out of the thread, but I'm mostly lurking though.  I saved up all my new questions for one more post and hopefully it's the last.

A page or two back, it was mentioned that we could use the genres.pl script to generate more modelines in windows and use them in soft15khz.  How would I go about doing this?  I mean, what program do I need to run the script...what syntax do I use, etc.....  I'm really slow at this stuff sometimes.

Also, it really never sunk in about setting up a custom config file for my monitor.  What name do I give the file and what do I need to include?  I have a NEC XM2950 so with it being able to do the whole range (15-50khz), I'm a little confused on what timings I should provide.  Could one of you guys help me out with that again?  I read the readme, but it was a little deeper than the kiddie pool for me.   

Lastly, with all the changes that have been made since the inception, I am a little unsure what type of settings I'll get if I don't use any special switches.  Things like....is triple buffer off by default?  If not, does the triple buffer that switchres implements not have the sound synch issue?

[bitbytebit]

Hi Guys!

I'm playing with switchres and I like it a lot.  Sorry I've been in and out of the thread, but I'm mostly lurking though.  I saved up all my new questions for one more post and hopefully it's the last.

A page or two back, it was mentioned that we could use the genres.pl script to generate more modelines in windows and use them in soft15khz.  How would I go about doing this?  I mean, what program do I need to run the script...what syntax do I use, etc.....  I'm really slow at this stuff sometimes.

Also, it really never sunk in about setting up a custom config file for my monitor.  What name do I give the file and what do I need to include?  I have a NEC XM2950 so with it being able to do the whole range (15-50khz), I'm a little confused on what timings I should provide.  Could one of you guys help me out with that again?  I read the readme, but it was a little deeper than the kiddie pool for me.  

Lastly, with all the changes that have been made since the inception, I am a little unsure what type of settings I'll get if I don't use any special switches.  Things like....is triple buffer off by default?  If not, does the triple buffer that switchres implements not have the sound synch issue?

The genres.pl program uses perl, basically you'll get the same output as me and your monitor should work good with the same settings as a d9800.  So here's the basic output you probably could use that it would output with the ATI Catalyst driver Calamity has hacked, so it can use these ~130 custom modes (this is probably better too because I use |sort -n in Linux and in Windows there isn't a sort command to order these better.  I need to improve the generation of these or have some files for each type of monitor, although this list should be fine for anybody/anymonitor really)...

genres.pl -x mame.xml -m d9800

(Note that these modelines only are using the HxW part, the refresh rate is dynamically altered by switchres and the rest of the modeline too, so they are all just set to 60HZ yet won't be that when used by switchres).

Code: [Select]

ModeLine "1024x512@60" 40.907520 1024 1048 1200 1272 512 513 516 536 -HSync -VSync
ModeLine "1024x544@60" 23.990400 1024 1072 1184 1344 544 551 558 595 -HSync -VSync interlace
ModeLine "1280x592@60" 29.706600 1280 1344 1480 1680 592 599 606 643 -HSync -VSync interlace
ModeLine "240x192@60" 4.773600 240 256 280 312 192 216 219 255 -HSync -VSync
ModeLine "240x224@60" 4.773600 240 256 280 312 224 232 235 255 -HSync -VSync
ModeLine "240x240@60" 4.758000 240 256 280 312 240 265 268 305 -HSync -VSync
ModeLine "248x224@60" 4.896000 248 264 288 320 224 232 235 255 -HSync -VSync
ModeLine "248x240@60" 4.889705 248 264 288 320 240 245 248 266 -HSync -VSync
ModeLine "256x192@60" 5.140800 256 272 296 336 192 216 219 255 -HSync -VSync
ModeLine "256x224@60" 5.131636 256 272 296 336 224 230 233 252 -HSync -VSync
ModeLine "256x240@60" 5.281920 256 272 296 336 240 243 246 262 -HSync -VSync
ModeLine "256x256@60" 5.758560 256 272 304 344 256 259 262 279 -HSync -VSync
ModeLine "264x224@60" 5.263987 264 280 304 344 224 233 236 257 -HSync -VSync
ModeLine "264x240@60" 5.533440 264 280 312 352 240 243 246 262 -HSync -VSync
ModeLine "272x224@60" 5.498181 272 288 320 360 224 230 233 252 -HSync -VSync
ModeLine "272x240@60" 5.659200 272 288 320 360 240 243 246 262 -HSync -VSync
ModeLine "280x224@60" 5.623150 280 296 328 368 224 232 235 255 -HSync -VSync
ModeLine "280x240@60" 5.784960 280 296 328 368 240 243 246 262 -HSync -VSync
ModeLine "288x224@60" 5.742545 288 304 336 376 224 230 233 252 -HSync -VSync
ModeLine "288x240@60" 5.910720 288 304 336 376 240 243 246 262 -HSync -VSync
ModeLine "296x224@60" 5.875200 296 312 344 384 224 232 235 255 -HSync -VSync
ModeLine "296x240@60" 6.046153 296 312 344 384 240 243 246 262 -HSync -VSync
ModeLine "304x224@60" 5.997600 304 320 352 392 224 232 235 255 -HSync -VSync
ModeLine "304x240@60" 6.288000 304 320 352 400 240 243 246 262 -HSync -VSync
ModeLine "304x256@60" 6.584400 304 320 352 400 256 259 262 279 -HSync -VSync
ModeLine "312x288@60" 7.937280 312 328 368 424 288 291 295 312 -HSync -VSync
ModeLine "320x192@60" 6.364800 320 336 368 416 192 216 219 255 -HSync -VSync
ModeLine "320x224@60" 6.364800 320 336 368 416 224 232 235 255 -HSync -VSync
ModeLine "320x240@60" 6.354816 320 336 368 416 240 246 249 268 -HSync -VSync
ModeLine "320x256@60" 6.963840 320 336 368 416 256 259 262 279 -HSync -VSync
ModeLine "328x224@60" 6.487200 328 344 376 424 224 232 235 255 -HSync -VSync
ModeLine "328x240@60" 6.467696 328 344 376 424 240 244 247 263 -HSync -VSync
ModeLine "328x256@60" 7.519531 328 344 384 440 256 259 262 280 -HSync -VSync
ModeLine "336x224@60" 6.589647 336 352 384 432 224 231 234 254 -HSync -VSync
ModeLine "336x240@60" 6.782362 336 352 384 432 240 243 246 262 -HSync -VSync
ModeLine "336x256@60" 7.499520 336 352 392 448 256 259 262 279 -HSync -VSync
ModeLine "344x240@60" 6.916800 344 360 392 440 240 243 246 262 -HSync -VSync
ModeLine "352x224@60" 6.854400 352 368 400 448 224 232 235 255 -HSync -VSync
ModeLine "352x240@60" 7.048949 352 368 400 448 240 243 246 262 -HSync -VSync
ModeLine "352x256@60" 7.767360 352 368 408 464 256 259 262 279 -HSync -VSync
ModeLine "360x224@60" 6.976800 360 376 408 456 224 232 235 255 -HSync -VSync
ModeLine "360x240@60" 6.965856 360 376 408 456 240 246 249 268 -HSync -VSync
ModeLine "360x256@60" 7.352544 360 376 416 464 256 259 262 278 -HSync -VSync
ModeLine "368x224@60" 7.099200 368 384 416 464 224 232 235 255 -HSync -VSync
ModeLine "368x240@60" 7.545600 368 384 424 480 240 243 246 262 -HSync -VSync
ModeLine "368x256@60" 8.035200 368 384 424 480 256 259 262 279 -HSync -VSync
ModeLine "376x224@60" 7.329545 376 392 432 480 224 233 236 258 -HSync -VSync
ModeLine "376x240@60" 7.671360 376 392 432 488 240 243 246 262 -HSync -VSync
ModeLine "376x256@60" 8.218625 376 400 440 496 256 259 262 279 -HSync -VSync
ModeLine "384x192@60" 7.588800 384 400 440 496 192 216 219 255 -HSync -VSync
ModeLine "384x224@60" 7.588800 384 400 440 496 224 232 235 255 -HSync -VSync
ModeLine "384x240@60" 7.797120 384 400 440 496 240 243 246 262 -HSync -VSync
ModeLine "384x256@60" 7.583840 384 400 440 496 256 259 262 278 -HSync -VSync
ModeLine "384x288@60" 9.734400 384 408 456 520 288 291 295 312 -HSync -VSync
ModeLine "384x384@60" 13.527360 384 424 464 528 384 396 400 427 -HSync -VSync
ModeLine "392x224@60" 7.711200 392 408 448 504 224 232 235 255 -HSync -VSync
ModeLine "400x224@60" 7.833600 400 416 456 512 224 232 235 255 -HSync -VSync
ModeLine "400x240@60" 8.048640 400 416 456 512 240 243 246 262 -HSync -VSync
ModeLine "400x256@60" 8.191560 400 424 464 520 256 259 262 278 -HSync -VSync
ModeLine "400x288@60" 7.936000 400 416 456 512 288 291 294 310 -HSync -VSync
ModeLine "400x384@60" 13.555347 400 440 480 544 384 395 399 425 -HSync -VSync
ModeLine "408x256@60" 7.952584 408 424 464 520 256 260 263 279 -HSync -VSync
ModeLine "416x224@60" 8.200800 416 440 480 536 224 232 235 255 -HSync -VSync
ModeLine "416x256@60" 9.240480 416 440 488 552 256 259 262 279 -HSync -VSync
ModeLine "424x256@60" 9.374400 424 448 496 560 256 259 262 279 -HSync -VSync
ModeLine "432x224@60" 8.435112 432 456 496 552 224 234 237 259 -HSync -VSync
ModeLine "432x256@60" 9.508320 432 456 504 568 256 259 262 279 -HSync -VSync
ModeLine "432x384@60" 11.732000 432 464 504 560 384 393 396 419 -HSync -VSync
ModeLine "440x256@60" 9.127296 440 464 512 576 256 259 262 278 -HSync -VSync
ModeLine "448x224@60" 8.812800 448 472 512 576 224 232 235 255 -HSync -VSync
ModeLine "448x240@60" 9.180480 448 472 520 584 240 243 246 262 -HSync -VSync
ModeLine "448x288@60" 11.381760 448 472 528 608 288 291 295 312 -HSync -VSync
ModeLine "448x512@60" 18.009600 448 456 528 560 512 513 516 536 -HSync -VSync
ModeLine "464x224@60" 9.180000 464 488 536 600 224 232 235 255 -HSync -VSync
ModeLine "464x256@60" 10.177920 464 488 536 608 256 259 262 279 -HSync -VSync
ModeLine "480x192@60" 9.424800 480 504 552 616 192 216 219 255 -HSync -VSync
ModeLine "480x224@60" 9.424800 480 504 552 616 224 232 235 255 -HSync -VSync
ModeLine "480x240@60" 9.538267 480 504 552 616 240 243 246 262 -HSync -VSync
ModeLine "480x464@60" 18.044160 480 488 560 592 464 474 476 508 -HSync -VSync
ModeLine "480x480@60" 19.152000 480 496 568 608 480 490 492 525 -HSync -VSync
ModeLine "488x384@60" 16.170400 488 536 584 656 384 395 399 425 -HSync -VSync
ModeLine "496x224@60" 9.669600 496 520 568 632 224 232 235 255 -HSync -VSync
ModeLine "496x240@60" 10.060800 496 520 568 640 240 243 246 262 -HSync -VSync
ModeLine "496x384@60" 16.233317 496 544 592 664 384 395 399 425 -HSync -VSync
ModeLine "496x480@60" 19.656000 496 512 584 624 480 490 492 525 -HSync -VSync
ModeLine "504x384@60" 13.575600 504 544 584 648 384 393 396 419 -HSync -VSync
ModeLine "512x192@60" 10.036800 512 536 584 656 192 216 219 255 -HSync -VSync
ModeLine "512x224@60" 10.036800 512 536 584 656 224 232 235 255 -HSync -VSync
ModeLine "512x240@60" 10.312320 512 536 584 656 240 243 246 262 -HSync -VSync
ModeLine "512x256@60" 11.249280 512 536 592 672 256 259 262 279 -HSync -VSync
ModeLine "512x288@60" 13.096699 512 544 608 696 288 291 295 312 -HSync -VSync
ModeLine "512x384@60" 18.036480 512 568 624 704 384 396 400 427 -HSync -VSync
ModeLine "512x400@60" 18.754560 512 568 624 704 400 412 416 444 -HSync -VSync
ModeLine "512x432@60" 21.196800 512 576 640 736 432 445 450 480 -HSync -VSync
ModeLine "512x448@60" 18.345600 512 520 592 624 448 457 459 490 -HSync -VSync
ModeLine "512x480@60" 20.412000 512 528 608 648 480 490 492 525 -HSync -VSync
ModeLine "512x512@60" 20.839680 512 528 608 648 512 513 516 536 -HSync -VSync
ModeLine "520x384@60" 13.935569 520 560 600 664 384 393 396 419 -HSync -VSync
ModeLine "520x408@60" 16.961013 520 568 616 688 408 419 423 449 -HSync -VSync
ModeLine "520x480@60" 20.664000 520 536 616 656 480 490 492 525 -HSync -VSync
ModeLine "544x224@60" 10.526400 544 568 616 688 224 232 235 255 -HSync -VSync
ModeLine "544x256@60" 11.769785 544 568 624 704 256 259 262 279 -HSync -VSync
ModeLine "544x480@60" 21.420000 544 560 640 680 480 490 492 525 -HSync -VSync
ModeLine "576x224@60" 11.238636 576 600 656 736 224 233 236 258 -HSync -VSync
ModeLine "576x400@60" 21.313363 576 640 704 800 400 412 416 444 -HSync -VSync
ModeLine "576x432@60" 23.500800 576 640 712 816 432 445 450 480 -HSync -VSync
ModeLine "624x384@60" 16.618947 624 672 720 792 384 393 396 419 -HSync -VSync
ModeLine "640x224@60" 12.607200 640 672 736 824 224 232 235 255 -HSync -VSync
ModeLine "640x240@60" 12.953280 640 672 736 824 240 243 246 262 -HSync -VSync
ModeLine "640x256@60" 13.927680 640 672 736 832 256 259 262 279 -HSync -VSync
ModeLine "640x384@60" 22.135680 640 704 768 864 384 396 400 427 -HSync -VSync
ModeLine "640x480@60" 25.200000 640 656 752 800 480 490 492 525 -HSync -VSync
ModeLine "648x240@60" 13.079040 648 680 744 832 240 243 246 262 -HSync -VSync
ModeLine "648x448@60" 23.284800 648 664 752 792 448 457 459 490 -HSync -VSync
ModeLine "672x240@60" 13.438993 672 704 768 856 240 243 246 262 -HSync -VSync
ModeLine "680x224@60" 13.218539 680 712 776 864 224 232 235 255 -HSync -VSync
ModeLine "680x288@60" 13.392000 680 712 776 864 288 291 294 310 -HSync -VSync
ModeLine "680x512@60" 27.271680 680 696 800 848 512 513 516 536 -HSync -VSync
ModeLine "704x240@60" 14.097899 704 736 800 896 240 243 246 262 -HSync -VSync
ModeLine "704x480@60" 27.440554 704 720 824 872 480 490 492 525 -HSync -VSync
ModeLine "712x288@60" 14.012000 712 744 808 904 288 291 294 310 -HSync -VSync
ModeLine "720x480@60" 27.972000 720 736 840 888 480 490 492 525 -HSync -VSync
ModeLine "736x264@60" 16.727040 736 776 856 968 264 267 270 288 -HSync -VSync
ModeLine "768x224@60" 14.906181 768 800 872 976 224 230 233 252 -HSync -VSync
ModeLine "800x600@60" 38.885760 800 832 952 1032 600 601 605 628 -HSync -VSync


You really should be able to use the --monitor d9800 option for your monitor, basically that should create the most optimal modelines that in theory will work with it the best (and here I've found does just about perfect for every single game).  I think that any kind of custom settings for the monitor range would just include the 40-50KHz range and that really isn't necessary for any game Mame emulates.

Switchres really should detect everything you need, if your using cabmame or my builds of mame with the cabmame patches the most you'll need is to add the soundsync=1 and ff=1 to the switchres.conf file under c:\etc\switchres.conf.  Those are the only ones that aren't autodetected at the command line unless the name of the executable has 'cabmame' in it, then they are enabled.  So it mostly autodetects what to do now for the mame your running.  By default it's using triple buffer, but you probably don't need it and with my builds can use these settings to use vsync instead (Calamity may have better details since he has tested this all under Windows actually)...

http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/

# Put into C:\etc\switchres.conf
mon=d9800
soft15khz=1
soundsync=1
ff=1
triplebuffer=0
threads=1

Without my build, you won't want to mess with threads (and similarly remove the ff/soundsync options if it's not a cabmame based version of mame), basically the above enables the soundsync/frogger hacks disables triple buffer and uses waitvsync instead, and enables threads with waitvsync (which only works with the builds I have, even with cabmame normally that won't work since we don't use throttle and there's a patch in the build I have that fixes that problem).

You also may want to play around with the above triplebuffer option too and see how it acts either way if it doesn't work great with the above settings, would be good to have more feedback about how it works in different setups.

Also here's a  somewhat ok example of the config file and monitor settings, although probably not necessary...
http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=src/SwitchResC/extra/switchres.conf;hb=HEAD

Here's where Perl can be gotten for Windows, although probably would get the same output as above unless you used custom monitor settings...
http://www.activestate.com/activeperl/downloads

[dapsaille]

May be a little off topic ...

 But .. could you propose a cabmame 0.141 build for windows in your repository (i've only found gentoo ebuilds, and that's great ^^) ?

[newmanfamilyvlogs]

A 64bit build would be nice too. I don't recall seeing one. Please correct me if I am wrong.

[SailorSat]

I'll upload the new builds later this day.

[dapsaille]

I'll upload the new builds later this day.

 Many thanks SailorSat 

[bitbytebit]

I'll upload the new builds later this day.

Great, also you may want to look at adding this patch, it's submitted to mame but not sure if it'll get in and it's not in 0141.  It allows switchres to do a little more magic when able to utilize the waitvsync option and not need triple buffer, if the monitor is able to run at the original refresh rate.

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=overlays/games-emulation/mame/files/vsync_mt_fix.diff;h=30898fa427573500b2679a91ebaa5fb23648042b;hb=HEAD

Basically this is what allows the waitvsync and multithreading to work with nothrottle, fixes what seems to be some sort of bug in the way  mame does the multithreading and locking while waiting for the vblank.  Calamity wrote the Windows part of the patch, which of course is all the cabmame build needs of yours, also great to get 64 bit versions up since I only have 0141 in 32 bit mame/mess versions. 

The patch of mine that made the changes for 0141 to your cabmame patches are here (and added Linux support) since there were some painful parts changed by mame over 0140-0140u2 turning the machine into a class structure or something like that...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=overlays/games-emulation/mame/files/groovyarcade-0141.patch;h=7c7e64a2c6f2e74d57355adb2c6f9a1e99373bce;hb=HEAD

[SailorSat]

I'll take a look into it
Turned out my "inputlag fix" didn't help at all xD

[dapsaille]

With your combined works, we're near to the "Perfect Mame"(tm) setup 

 I'm really impressed 

[Calamity]

It would be nice to gather a brief txt with the basic config for using switchres with most popular frontends. I only use AdvanceMenu, but if anyone had success using Mala, HyperSpin, etc. + switchres please let us know your config.

On the default Mame config stuff, if you use the 0.141 binary with cabmame patches on built by bitbytebit: (http://sourceforge.net/projects/groovyarcade/files/Mame_Windows_Builds/) it's already using the best config by default. So for what I've seen looking through the code and testing, triplebuffer (wait + flip) is the right option we should use in Windows for vsyncing, being waitvsync and syncrefresh (wait only) somehow deprecated (even if one can patch the code to restore their original function it seems triplebuffer is the way intended by mame devs to do this stuff, and I can't see any lag produced by it compared to the other methods). Of course in this context we're always using Mame versions with the soundsync hack, for cases where we can't match the original game refresh (i.e. Pacman, cga monitor, set horizontally).

[newmanfamilyvlogs]

I have been attempting to get switchres to work within Hyperspin for a while now and have yet to have success. I need to take it to the official hyperspin forums, but have not do so yet.

At the moment, on my machine, when I set it to launch switchres as it's default mame executable with the argument of --soft15khz, it successfully launches switchres, and switchres successfully launches mame, however switchres has some failure of reading the settings from for the rom, thus it sets it runs it at whatever the desktop resolution already was. It also usually does not throttle the game either.

I am assuming this is some kind of path issue; Hyperspin launches the game either as a complete path (eg: "c:\mame\switchres.exe" "romname") or as a relative path (eg: "..\mame\switchres.exe" "romname" or ".\mame\switchres.exe" "romname"). On a whim I set my mame, and rom directories up in the %PATH% variable, but I either did something wrong, or that didn't work anyway.

Getting this working would be wonderful.

[bitbytebit]

I have been attempting to get switchres to work within Hyperspin for a while now and have yet to have success. I need to take it to the official hyperspin forums, but have not do so yet.

At the moment, on my machine, when I set it to launch switchres as it's default mame executable with the argument of --soft15khz, it successfully launches switchres, and switchres successfully launches mame, however switchres has some failure of reading the settings from for the rom, thus it sets it runs it at whatever the desktop resolution already was. It also usually does not throttle the game either.

I am assuming this is some kind of path issue; Hyperspin launches the game either as a complete path (eg: "c:\mame\switchres.exe" "romname") or as a relative path (eg: "..\mame\switchres.exe" "romname" or ".\mame\switchres.exe" "romname"). On a whim I set my mame, and rom directories up in the %PATH% variable, but I either did something wrong, or that didn't work anyway.

Getting this working would be wonderful.

It does sound like switchres can't find the mame executable, try putting the mame.exe (maybe rename it to that, or use --emulator <name_of_mame_executable>) in the same directory switchres is in, or in a very common windows path possibly.  I wonder if possibly Hyperspin is launching mame in an environment that doesn't allow it to find the mame executable, or another possibility is it's trying to add extra arguments but doesn't seem like that's happening.

[newmanfamilyvlogs]

I've named it to mame.exe and it's in the same folder.

What I'm confused about is how switchres is able to launch the mame executable but unable to use it to find the display information. Is mame called as a function of the current working directory? Maybe an absolute path to the mame executable and rom directory could be set up as a config variable?

[bitbytebit]

I've named it to mame.exe and it's in the same folder.

What I'm confused about is how switchres is able to launch the mame executable but unable to use it to find the display information. Is mame called as a function of the current working directory? Maybe an absolute path to the mame executable and rom directory could be set up as a config variable?

Is it the newest switchres?  One thing I did have to do awhile back was change some things on how it gets the XML information when launching the mame executable.  Basically it uses mame to check for the games information first, so that execution is failing or it can't get the file output it uses.  In Windows I'm having to write the xml info out to a file and read it in from that, doesn't allow me for some reason to easily redirect the mame output to read it into switchres in a stream like I can in Linux (even in Cygwin, it's an issue with posix compliance I guess).  So maybe that file output is failing, so it can't get the information most likely from mame on what resolution the game should be.  I am guessing the way that Hyperspin is launching switchres is either having the current working directory in a non-writable place or some other form of launching it that doesn't allow the method of writing out a file and reading it back in to work.

[bitbytebit]

I've named it to mame.exe and it's in the same folder.

What I'm confused about is how switchres is able to launch the mame executable but unable to use it to find the display information. Is mame called as a function of the current working directory? Maybe an absolute path to the mame executable and rom directory could be set up as a config variable?

Not sure if you've seen this, seems like maybe this could help or at least give insight into what is going on...

http://www.hyperspin-fe.com/forum/downloads.php?do=file&id=3603

HyperLaunch is a compiled script that handles the launching of emulators via HyperSpin. The Official compiles of HyperLaunch include the compiled (HyperLaunch.exe) and the raw HyperLaunch.ahk. Just place the HyperLaunch.exe into your HyperSpin directory and overwrite your old one. The .ahk file is included for you to edit and compile your own version using AutoHotKey.

[newmanfamilyvlogs]

I have not used the most recent switchres. I will do that as soon as I can and report back. If it's compiling it's own .xml now then I bet that will help resolve the issue. Any chance we could get a -v -v -v -v etc log dump option?

As for Hyperlaunch, I am not using it. It's current behavior is to force-quit programs to return to the FE, doing so prevents mame from outputting nvram updates, hiscores, or configuration changes.

[Calamity]

I was having a similar problem with AdvanceMenu, the params passed by Switchres weren't working because rom names were passed as "romname.zip" instead of "romname". However the right game was actually loaded, but Mame was using its default settings. It got fixed by using %s param instead of %f, like this:

emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"

Is there a similar param available in HyperSpin? If it's missing and that was the problem, maybe Switchres could be changed to always rip the romname string in order to get the plain "romname" when launching Mame.

[bitbytebit]

I have not used the most recent switchres. I will do that as soon as I can and report back. If it's compiling it's own .xml now then I bet that will help resolve the issue. Any chance we could get a -v -v -v -v etc log dump option?

As for Hyperlaunch, I am not using it. It's current behavior is to force-quit programs to return to the FE, doing so prevents mame from outputting nvram updates, hiscores, or configuration changes.

Yeah hopefully that's the issue, will see if my work to fix issues reading that xml output in windows worked or not.  The dynamic reading from mame is nice because it's fast from not having to open a large 40+ Meg XML file and search through it, process it with the XML reader, could see how that would be a bit slower.  Yeah I should be able to output to a file all the details, will need to look at that and having my info messages write to a file instead of stderr.  

That does sound bad with Hyperlaunch, if it forced switchres to quit would probably be a bit nasty (I think), wonder why it does that for.

[bitbytebit]

I was having a similar problem with AdvanceMenu, the params passed by Switchres weren't working because rom names were passed as "romname.zip" instead of "romname". It got fixed by using %s param instead of %f, like this:

emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"

Is there a similar param available in HyperSpin? If it's missing and that was the problem, maybe Switchres could be changed to always rip the romname string in order to get the plain "romname" when launching Mame.

Nope, I already do that in switchres , it strips off any extension to the rom name given, changes all case to lower case, so shouldn't be an issue.

[dapsaille]

for Malafe you need to edit mala.ini and replace Exe=Mame.exe by Exe=SwitchRes.exe ....

 if you try to do it by the gui, gui will crash 

[Calamity]

Nope, I already do that in switchres , it strips off any extension to the rom name given, changes all case to lower case, so shouldn't be an issue.

Ah it was already there! nice to know  

[bitbytebit]

I should have a build for Windows/Linux up in a bit that will write out to a file all the information output if the config file has an file specified to write logs to.  So hopefully that can help get to the bottom of what's going on when launching from Hyperspin.