Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Switchres: modeline generator engine  (Read 345422 times)

0 Members and 1 Guest are viewing this topic.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #480 on: December 22, 2010, 04:05:18 pm »
I see, I was doubting if it was the right point to place the function. But is the arcade monitor out of range when testing it? It's using mode number 03h, the standard BIOS text mode, by calling int 10h to set the mode, and after that it's tweaking the crtc stuff to modify it to 15KHz. So if the mode is working, it would be a matter of calling the proc right before the menu options are printed.


I found the right point to run it at, and it runs, but it seems to put the monitor into a state where it's claiming not detected and the background behind the OSD screen saying that has real fuzzy stuff scrolling vertically.  It then seems to not boot or anything from that point, so I'm guessing it's some crash happening.

Here's the patch I have built into an ebuild so far...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #481 on: December 22, 2010, 05:10:20 pm »
Yes, I'm afraid that mode does not work for me either in a dos compile executable I've tested made from that. That code is old and could be newer cards bios modes use different timings as a base, I'm seeing that with jpac not dealing with them as well as with older ATIs. In addition there could be some errors due to syntax so it would be great to have the raw binary produced by the compiler to compare with the dos one to check if there's any bad address or wrong opcodes.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #482 on: December 23, 2010, 09:21:17 pm »
@bitbytebit

I think dmarcum99's question was: are you eventually going to have an app similar to advancecfg, but with a more 'user-friendly' interface?
« Last Edit: December 23, 2010, 09:40:56 pm by Gray_Area »
-Banned-

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #483 on: December 23, 2010, 09:43:21 pm »
@bitbytebit

1. by 'dynamically' you mean the 'generate at run-time' feature in AdvanceMAME, right?

2. I think dmarcum99's question was: are you eventually going to have an app similar to advancecfg, but with a more 'user-friendly' interface?

Yes, it uses the mame information for the resolution of the original game at runtime and generates the modeline according to the monitor specs and applies that modeline to the display monitor.  In theory a person could write an app to run instead of mame in switchres which did the same thing as advance mame had, alter the front/back porches to center the display.  The backend structure is probably all there to support using a tool to take the modeline from switchres, display it have you use the tool to adjust it somehow with a user-friendly interface, then have it write out a range config into switchres.conf for what you adjusted things to.  I've been working on the assumption of a monitor database of the needed settings, so you just have to say h9110 or d9800, ntsc, pal or cga etc.   There could be more monitors added with people looking up the specs and testing them, but understand it's not totally user-friendly although it'll probably take time to gather that information, which will eventually lead to being more user friendly for each monitor type.  For an h9110, d9800, generic CGA monitor it should just make the best decisions and be more user friendly than advance was because you just have to tell it your monitor type in those cases.  No need to fiddle with each game I think, at least I don't, and I think Calamity has a pretty good method of calculation which avoids that as much as possible.  I figure I might not know all cases of course so guessing there's places that need work, so always looking to get feedback and information to fill in those gaps.  I did think about writing some kind of tool to adjust the modelines live, like advance config does, although I'm not really a GUI programmer so it'd be a nice way to learn more about that yet might not be quick at doing it or feel it's going to match advance config anywhere close.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #484 on: December 24, 2010, 08:25:17 am »

I found the right point to run it at, and it runs, but it seems to put the monitor into a state where it's claiming not detected and the background behind the OSD screen saying that has real fuzzy stuff scrolling vertically.  It then seems to not boot or anything from that point, so I'm guessing it's some crash happening.

Here's the patch I have built into an ebuild so far...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD

I could finally do some tests with the arcade mode asm routine in both HD4350 and 9250 and it fails with them. So it definitely doesn't work, either for some error of mine, or it could be that those ports aren't working that way with modern cards... or whatever. It was promising as here I tested it with a pc monitor and it was reporting Hfreq 16.0 KHz, so it's doing something, but it turns out to be completely out of sync. So I'm going to leave this grub thing by now until I have a proper way to test it, and if I eventually have a routine that I'm sure that works here, I'll post it so that you can try to patch grub with it.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #485 on: December 24, 2010, 04:27:48 pm »

I found the right point to run it at, and it runs, but it seems to put the monitor into a state where it's claiming not detected and the background behind the OSD screen saying that has real fuzzy stuff scrolling vertically.  It then seems to not boot or anything from that point, so I'm guessing it's some crash happening.

Here's the patch I have built into an ebuild so far...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=tree;f=overlays/sys-boot/grub/files;h=9f7906280c19b1fb22d421fea3c4bc4df5451ef7;hb=HEAD

I could finally do some tests with the arcade mode asm routine in both HD4350 and 9250 and it fails with them. So it definitely doesn't work, either for some error of mine, or it could be that those ports aren't working that way with modern cards... or whatever. It was promising as here I tested it with a pc monitor and it was reporting Hfreq 16.0 KHz, so it's doing something, but it turns out to be completely out of sync. So I'm going to leave this grub thing by now until I have a proper way to test it, and if I eventually have a routine that I'm sure that works here, I'll post it so that you can try to patch grub with it.


Well at least we have some path into doing this eventually, now that we know where to put something like this into grub.  You might want to look at the newer grub2 sources since I think it can do more vesa bios resolution stuff so might have something to modify off of, guessing that might help. 

Have you been able to test the audio and network with the newest ISO, possibly trying the alsaconf program, I've been looking that that some and hopefully the network issue is fixed.  I'm still looking into the audio but at least have quite a bit better support for setting the right output and unmuting, also have a graphical mixer control now.  My local ISO build is a bit further than the one I have uploaded though, I need to upload a new ISO of what I've got here since have a few more improvements on how it sets up the mixer/sound output.  I now have it writing a .asoundrc file and asks for the audio output to use, might be one fix.  I do have the odd laptop here though still that I can get music to play on but mame is silent on it, it's weird.  I have read that I guess some Alsa drivers in Linux are not so great and there's a bit of issues with Alsa in Linux so that could be part of the issue for your audio.  It seems the audio layer is quite complicated on setting up a Linux distro with it correctly done for all cases, I'm looking at this pulse audio although I don't like the idea because of overhead.  I actually am becoming more in favor of just running wahcade or fvwm with wahcade probably as preferred since the lxde desktop is nice but again there's overhead there and I suspect at least on older systems it's a big waste of memory and could cause some latency. 

Also Alex from AMD seems to be interested in the J-Pac issue we see with OpenGL, which he's guessing somehow it's still not setting up the output for page flip vsync/blank support even though we are forcing it enabled.  It's really a DRM issue most likely he says, makes sense, OpenGL is just trying to use it and it's not ready for that type of interface somehow.  I'll look deeper into that some, and he might just show up with a patch hopefully, I gave him details on J-Pac and how it works and what the issue seems to be.  Any more information that you think would help would be great, since it seems J-Pac is somewhat less than documented fully since it's sort of a specialized thing from Ultimarc and doesn't seem to be a total standard out there but guessing just used by most people.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #486 on: December 25, 2010, 09:37:55 am »
These days I've been having problems with my cab so I couldn't do the last tests. Before that I tested the last iso for a while and I was having a problem, when switching resolutions it was exiting x windows, this happened either from switchres or wahcade, but I didn't test any further to have a proper report. So I still need to go back to it and test more. BTW the vblank environment variable should be already set to 0 in this iso, shouldn't it? I need to get a replacement for my keyboard that has stopped working, then will try it again.

Sounds good that Alex from AMD is having a look at that issue. I'm optimistic at having that eventually solved, as in fact there's no physical limitation for achieving it, it must be a software issue. There're a lot of little things here and there that need to be done to have this working for everybody, but will definitely be worth the effort. I think that solving this jpac issue is a must as it's a very spread interface and many people are using it.

I've been working also on my patched Catalyst drivers, the version based on Catalyst 9.3 is available to download here:

http://postback.geedorah.com/foros/viewtopic.php?id=1424

It admits up to 134 video modes, so we can also start testing it with a decent mode list and Switchres.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #487 on: December 25, 2010, 10:06:45 am »
These days I've been having problems with my cab so I couldn't do the last tests. Before that I tested the last iso for a while and I was having a problem, when switching resolutions it was exiting x windows, this happened either from switchres or wahcade, but I didn't test any further to have a proper report. So I still need to go back to it and test more. BTW the vblank environment variable should be already set to 0 in this iso, shouldn't it? I need to get a replacement for my keyboard that has stopped working, then will try it again.

Sounds good that Alex from AMD is having a look at that issue. I'm optimistic at having that eventually solved, as in fact there's no physical limitation for achieving it, it must be a software issue. There're a lot of little things here and there that need to be done to have this working for everybody, but will definitely be worth the effort. I think that solving this jpac issue is a must as it's a very spread interface and many people are using it.

I've been working also on my patched Catalyst drivers, the version based on Catalyst 9.3 is available to download here:

http://postback.geedorah.com/foros/viewtopic.php?id=1424

It admits up to 134 video modes, so we can also start testing it with a decent mode list and Switchres.



Sounds great, sounds like with that driver we should be able to do about any resolution needed then. 

I'm uploading new ISO's, version 1.204-d0dc486, also have new switchres versions up too and mame builds of 140u3 also with the cabmame patches (finally figured that out).  The switchres version adjusts some for the changeres hack, because I discovered about it.  Seems that it forces a 1 to 1 scale ratio so basically prevents scaling from happening or stretching when enabled.  Which basically you don't want to use changres when you are virtualizing, cases where you aren't trying to get 1 to 1 pixel perfection.  So changeres is sort of dual purpose, it doesn't just do the resolution change stuff but also is doing the part to avoid altering the pixels or stretching them in any way.  I'm not totally sure why, or if it's a side effect or what, I just know from how the code is and seeing the effects that it's doing that.  It basically sets x/y scale to 1 in cleanstretch code, forces it that way, and so in switchres now I turn it off/on according to if we are virtualizing or not.  These new ISO images should hopefully help audio setup, and fix the network connection issues, get them all synced up with my current build here.

It seems more improvements, some maybe relating to the issue with the j-pac issue, are being adding to the newest Linux-Next kernel versions.  Not sure, but at least look like there's even more stuff/features being put in.  So that looks promising, and also I'm going to start digging in there and trying to find where it prevents the setup from happening even when we force the connector enabled. 
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #488 on: December 25, 2010, 02:00:08 pm »
I've finally tested 1.191 and fortunately the network is working again, I've been able to get the logs normally so this will make things easier. I've noticed you've added a login step at startup now. I need to set vblank_mode=0 for things to work, so the error I had seen before was that I hadn't done that. On the audio part, it doesn't work yet, alsaconf program is not recognized (only alsamixer is) and I can see how both audio devices are found, being the hdmi the default one. Have look at the switchres.log I've attached, there's an SDL error there as it does not find an audio device. I'm going to download and test the new one now.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #489 on: December 25, 2010, 02:35:52 pm »
I've finally tested 1.191 and fortunately the network is working again, I've been able to get the logs normally so this will make things easier. I've noticed you've added a login step at startup now. I need to set vblank_mode=0 for things to work, so the error I had seen before was that I hadn't done that. On the audio part, it doesn't work yet, alsaconf program is not recognized (only alsamixer is) and I can see how both audio devices are found, being the hdmi the default one. Have look at the switchres.log I've attached, there's an SDL error there as it does not find an audio device. I'm going to download and test the new one now.

The alsaconf program will need to run as root, running 'sudo -s' should be done first to be able to run it.  Yeah I'm using the gdm display manager now so it makes it easier to have X work right, hopefully the newer ISO will set the audio device order, or basically allow you to do that.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #490 on: December 27, 2010, 02:04:33 pm »
I've been testing the 1.204 one and playing with alsaconf and the new gnome mixer. I still have not sound however. I can see both audio devices, hdmi and VIA integrated audio in the setup menu, I'm selecting card 1 (VIA) and everything is ok. Then I run sudo -s alsaconf and select again the VIA card, it proceeds with it's stuff and says the audio driver is configured ok, updates alsa.conf and exits. But when I run the gnome mixer, then it shows a fuzzy behaviour, I have two tabs there, one for the ATI HDMI and the other for the Realtek VIA, it's this second one where sometimes I have front + surround + back + ... playback/recording stuff with its volume slides, other times it only shows part of it, like the recording controls only, and yet other times its void. I've also seen that the setup menu sometimes only shows the HDMI device (I believe it's when I restart without switching off). So there seems to be a problem recognizing the devices (is it blindly polling some ports there to find things?). In one of my tests everything looked ok, volume was on for the front speakers, but I still couldn't hear anything inside Mame. I've attached the logs in case they can be of help.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #491 on: December 27, 2010, 02:17:57 pm »
I've been testing the 1.204 one and playing with alsaconf and the new gnome mixer. I still have not sound however. I can see both audio devices, hdmi and VIA integrated audio in the setup menu, I'm selecting card 1 (VIA) and everything is ok. Then I run sudo -s alsaconf and select again the VIA card, it proceeds with it's stuff and says the audio driver is configured ok, updates alsa.conf and exits. But when I run the gnome mixer, then it shows a fuzzy behaviour, I have two tabs there, one for the ATI HDMI and the other for the Realtek VIA, it's this second one where sometimes I have front + surround + back + ... playback/recording stuff with its volume slides, other times it only shows part of it, like the recording controls only, and yet other times its void. I've also seen that the setup menu sometimes only shows the HDMI device (I believe it's when I restart without switching off). So there seems to be a problem recognizing the devices (is it blindly polling some ports there to find things?). In one of my tests everything looked ok, volume was on for the front speakers, but I still couldn't hear anything inside Mame. I've attached the logs in case they can be of help.


I have been able to get my laptop working with sound, but I have basically found a few things that possibly allowed this.  I have blacklisted a few sound modules, the pcspeaker and HDMI audio and an Intel Modem audio driver.  On my laptop it may have not been working from the pcspeaker and Intel modem driver being before the real sound card.  For your situation it seems the HDMI audio may be doing the same thing so now I blacklisted it too.  Also an interesting note is that the starfire game has no sound, it was confusing me partly during testing because of that.  I do know the gridlee game has sound, only when shooting the things and hitting them, so at least now know the best test cases on the demo games.  I suspect your either having the issue of HDMI Audio taking over, or it's an Alsa issue with your setup.  I'm not sure because I actually have the same intel-hda audio as I think yours does so seems Alsa should support it, so it points to the HDMI audio module taking over the first port (which I think possibly is where Mame is having issues only knowing about the first dsp device).  Also there's another thing I did, compiling in OSS support to libSDL which might have also helped since oddly seems libSDL needs both Alsa and OSS support enabled to work with Alsa correctly and mame.  If you are able, try playing a sound or movie file (if full version, just running mplayer <FILE> should do this), since that way can see if it's just Mame.  I did find that sometimes just Mame didn't output sound while I could play audio from mplayer, but that might be the OSS support thing again.  So I'll have a new ISO image with my current changes which may fix it.  I have another option too, which I probably am going to do anyways, putting in OSS4 sound support to use instead of Alsa.  It's supposed to be a lot better in handling things, I think have the build able to switch back and forth between the two.  Will get an ISO up later today probably with both available and the other changes which may fix Alsa too. 

SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #492 on: December 27, 2010, 03:21:25 pm »
Unfortunately the one I downloaded was the NoMedia, so next time I'll download the full one. Is there a way to test sounds there without the need of loading media files, having some system sounds activated or something?

I've also done some tests with Switchres in Windows and my hacked drivers. This time I didn't use Soft-15Khz, as I'm using a modified version of my VMMaker app to create the base mode list, as I'm investigating the best method for it. I'm having a problem now with Switchres not being able to modify the modes, just choosing the dummy ones. It's complaining it doesn't find the keys ("Failed getting resolution values from DALDTMCRTBCD184X192X0X60"). But the keys are there indeed. So I'm wondering if it's trying to find something else, like the DADTM... duplicated ones that Soft-15kz uses and are not necessary at all with this Catalyst version.

Code: [Select]
C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
# loht [2] 384x256@55.02 15.2949Khz
     "384x256x55" 7.708626 384 400 440 504 256 258 261 278 -HSync -VSync

DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
Target refresh = 55.017606
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v >switchres.log
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #493 on: December 27, 2010, 03:31:59 pm »
Unfortunately the one I downloaded was the NoMedia, so next time I'll download the full one. Is there a way to test sounds there without the need of loading media files, having some system sounds activated or something?

I've also done some tests with Switchres in Windows and my hacked drivers. This time I didn't use Soft-15Khz, as I'm using a modified version of my VMMaker app to create the base mode list, as I'm investigating the best method for it. I'm having a problem now with Switchres not being able to modify the modes, just choosing the dummy ones. It's complaining it doesn't find the keys ("Failed getting resolution values from DALDTMCRTBCD184X192X0X60"). But the keys are there indeed. So I'm wondering if it's trying to find something else, like the DADTM... duplicated ones that Soft-15kz uses and are not necessary at all with this Catalyst version.

Code: [Select]
C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
# loht [2] 384x256@55.02 15.2949Khz
     "384x256x55" 7.708626 384 400 440 504 256 258 261 278 -HSync -VSync

DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
Target refresh = 55.017606
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

C:\Emuladores\Mame>switchres loht --soft15khz -v-v-v >switchres.log
Mame version 0.131 with [cleanstretch][][redraw][] hacks enabled
[] "loht" horizontal 384x256@55.018 (1.500) --> 384x256@55.018 (1.500)

# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vpad +2 lines | )
DefaultVideo 'System\CurrentControlSet\Control\Video\{4534B163-EB63-466E-90EA-76
F5C53BAD45}\0000'
DALDTMCRTBCD184X192X0X60:
  (63812/68) Modeline 3.890000 184 192 216 248 192 218 221 261
Failed getting resolution values from DALDTMCRTBCD184X192X0X60
Opening  modes file for mode 384x256@55
loht_i8751.mcu NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.


I think it's confused about the X being capitol instead of lower case, DALDTMCRTBCD184X192X0X60, which with Soft15khz they were always DALDTMCRTBCD184x192x0x60 syntax (which the case sensitivity is built into the C Posix stuff  I guess).  That's most likely the issue, not sure why Soft15khz uses lower case, I guess both work for the driver?  I can always add a check for both, is it otherwise pretty much standard though otherwise besides that of what will work for those?

I'll hopefully have a new ISO set up with OSS4 support (which will allow to switch between the two Alsa and it I think) and the newer linux-next tree which might have some chance of fixing the 4350, at least seems there are some interesting changes that might hit that bug.


Update:  uploaded new windows build with the ability to use either X or x in the resolution name
« Last Edit: December 27, 2010, 03:47:26 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #494 on: December 27, 2010, 04:59:53 pm »
It's working ok now, so it was the x/X issue. I'm testing it more deeply now:

- The stretching is not properly set when we are virtualizing, so the game shows in a little box in the middle of the screen (hwstretch should be set to 1, only that option)
- Some games are chopped, for instance Contra is choosing a 344x272 resolution I have there, being 280 lines high, so it's missing some lines up and down. I always assume the original resolution should fit in the target one. In same cases it could be better to loose some lines when the next one is way too big, but I won't allow that to happen by building a good mode table, anyway it could be good to have an option to control that behaviour.
- We always get a little bit below the target vfreq, I believe there's some extra accuracy available there by using some kind of dotclock table as I was doing, however it's rather accurate most of the time (99% or so of the speed) so that can be pretty good for now.

I think we should stablish a standard method for calculating rotated resolutions for vertical games, and allow different variants. I've seen that in your switchres code you're doing game->width = (4.0/3.0) * game->height; That gives good results most of the time though it's not the way it should be done imho. I'm not doing it any better either in my code, I'm using a different approach that produces a highly stretched picture more or less square-shaped. But the really right way should be available at least as an option. This came to my mind now as it's the time to define a good standard mode table, and in case we wanted to include resolutions for rotated vertical games, we should agree the way to create that resolutions or at least be able to tell switchres how we like them so it can choose the right ones.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #495 on: December 27, 2010, 05:20:23 pm »
It's working ok now, so it was the x/X issue. I'm testing it more deeply now:

- The stretching is not properly set when we are virtualizing, so the game shows in a little box in the middle of the screen (hwstretch should be set to 1, only that option)
- Some games are chopped, for instance Contra is choosing a 344x272 resolution I have there, being 280 lines high, so it's missing some lines up and down. I always assume the original resolution should fit in the target one. In same cases it could be better to loose some lines when the next one is way too big, but I won't allow that to happen by building a good mode table, anyway it could be good to have an option to control that behaviour.
- We always get a little bit below the target vfreq, I believe there's some extra accuracy available there by using some kind of dotclock table as I was doing, however it's rather accurate most of the time (99% or so of the speed) so that can be pretty good for now.

I think we should stablish a standard method for calculating rotated resolutions for vertical games, and allow different variants. I've seen that in your switchres code you're doing game->width = (4.0/3.0) * game->height; That gives good results most of the time though it's not the way it should be done imho. I'm not doing it any better either in my code, I'm using a different approach that produces a highly stretched picture more or less square-shaped. But the really right way should be available at least as an option. This came to my mind now as it's the time to define a good standard mode table, and in case we wanted to include resolutions for rotated vertical games, we should agree the way to create that resolutions or at least be able to tell switchres how we like them so it can choose the right ones.


I need to look at the hwstretch, do you know what the exact command line is and what needs to be removed from what it's currently doing?  I know the cabmame hacks bring into play the changeres which I have to check for and turn off else that prevents all stretching (for some reason that patch forces cleanres and inside of that forces scaling to 1x1 instead of what it would have been set to for stretching, at least from what I can tell and have seen testing it).  Which option is it possibly that keeps hwstretch from working?

So there's no 344x280 resolution and it picks that one?  I can see that as being an issue, the horizontal I'm allowing up to 16 pixels extra but for vertical the logic just stops at the total height.  Will need to think of doing that better, it gets tricky to let both go past the original but haven't spent too much time looking into that either.

Yeah the dotclock being slightly inaccurate might just be more of the 1000 alignment in Linux or 10000 in Windows and using your method, since I was thinking if that's the granularity of both systems then it'll be cutoff anyways so might as well see if there's a better value for the dotclock to get closer.  I need to port that code into it for the dotclock like I had in the perl version, will look at that.  Should hopefully be easier actually since Perl was really not easy to do that precise of value checking in while in C it should be quite natural.

Yeah I wondered about the aspect ratio calculation for vertical games and how to do that better, did basically what lrmc and your calculations do (well lrmc did use something slightly different using this calculation...


    if (mode->aspect3x4 == 1)
    {
      mode->hres = mode->hres / 0.5625;
    }


Which was always too wide looking, and I think certain games look too wide with the current one too but others look pretty good compared to the lrmc calculation.  Definitely interested in a better way to calculate it, but everything I've tried seems to not be as good and actually usually make more games look odd, how would we get the right amount to calculate that every time correctly?


Update:

Also seems that the cleanstretch option definitely prevents hwstretch from extending fully, I tried this...

mame <rom> -nochangeres -nocleanstretch -hwstretch -keepaspect

And it works right, while without -nocleanstretch I get bars at the top/bottom still, need keepaspect it seems with hwstretch or else it's too wide on vertical games.
« Last Edit: December 27, 2010, 05:35:21 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #496 on: December 27, 2010, 06:18:16 pm »
Yes, with SDL you need the keepaspect option for vertical games + stretch, with ddraw/d3d you don't. So:

- SDL + vertical games + stretch: unevenstretch 1, keepaspect 1
- DDraw + vertical games + stretch: hwstretch 1 (-[no]hwstretch / -[no]hws)

The cleanstretch is for D3D where hwstretch does not apply as D3D always stretches everything by default, that's why I don't like using it, until DDraw disappears I'll stick with it.

I understand the changeres does not make sense when virtualizing as we are somewhat ignoring resolutions that way, so we are just stretching to the existing one.

On the Contra issue, yes, it's taking that one cause the next one is way wider as I'm precalculating vertical resolutions in a different way. It should only allow a resolution if both xres and yres are >= the ones we need, at least this could be an option so you'll never get chopped pictures.

The key to get consistent results with vertical games is to base xres calculations on original height instead of width. It would be good to have some drawings to explain this but a sample will do I think. Say you have 2 different vertical games, with original resolutions of 256x224 and 256x240. Now we want to display them rotated on our horizontal monitor. So we start by swapping xres and yres values, and we get:

1.- 224x256
2.- 240x256

Both resolutions are 256 lines tall. Now we need to get a wider resolution in order to get side bars and a proper aspect, ok? If you use 4/3 x 256 = 341,33 ->344 ... then you'll be using the same 344x256 for both of the above resolutions, which is not good, as one game will look wider than the other, and what we want is that they both have 3:4 aspect.

So to be consistent we should use the first value as a base for our calculations. We need a resolution so wide that 224 or 240 in each case looks 3/4 as wide as our physical screen height. I think it should be done like this:

height = 4/3 yres
width  = 4/3 height

so width = 4/3 x 4/3 yres = 16/9 yres

So for each of the cases it would be:

1.- 400x256
2.- 432x256

However I've tested this and it looks too narrow, used to the other way, so I would keep the other method as a option (if you look at my code, I was already using original yres as the base for calculations but using 4/3 factor instead of 16/9, which was producing a 3:3 aspect). Anyway the explosions look circles so I think it must be ok. I still have to actually measure on the screen to see if this is working or not.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #497 on: December 27, 2010, 06:59:13 pm »
Yes, with SDL you need the keepaspect option for vertical games + stretch, with ddraw/d3d you don't. So:

- SDL + vertical games + stretch: unevenstretch 1, keepaspect 1
- DDraw + vertical games + stretch: hwstretch 1 (-[no]hwstretch / -[no]hws)

The cleanstretch is for D3D where hwstretch does not apply as D3D always stretches everything by default, that's why I don't like using it, until DDraw disappears I'll stick with it.

I understand the changeres does not make sense when virtualizing as we are somewhat ignoring resolutions that way, so we are just stretching to the existing one.

Ah, ok, so in d3d mode though it seems you still need keepaspect, since I think my quick tests were using that.  Guess it would be best then to force ddraw mode, since else seems we won't know what to do and that actually would be best anyways for arcade monitors (and maybe force opengl in SDL mode too).

On the Contra issue, yes, it's taking that one cause the next one is way wider as I'm precalculating vertical resolutions in a different way. It should only allow a resolution if both xres and yres are >= the ones we need, at least this could be an option so you'll never get chopped pictures.

Yeah, that's I guess where we need the large mode table since I am guessing in both cases the picture won't look right being either squished from side to side (or stretched possibly) and the other it'd be missing some top/bottom.  Would it be possibly work to just treat it as virtualized in these cases where it won't fit vertically without too much horizontal size, since I'm guessing that the other 2 possibilities are not going to look good anyways when trying to not do any stretching/shrinking of it.


The key to get consistent results with vertical games is to base xres calculations on original height instead of width. It would be good to have some drawings to explain this but a sample will do I think. Say you have 2 different vertical games, with original resolutions of 256x224 and 256x240. Now we want to display them rotated on our horizontal monitor. So we start by swapping xres and yres values, and we get:

1.- 224x256
2.- 240x256

Both resolutions are 256 lines tall. Now we need to get a wider resolution in order to get side bars and a proper aspect, ok? If you use 4/3 x 256 = 341,33 ->344 ... then you'll be using the same 344x256 for both of the above resolutions, which is not good, as one game will look wider than the other, and what we want is that they both have 3:4 aspect.

So to be consistent we should use the first value as a base for our calculations. We need a resolution so wide that 224 or 240 in each case looks 3/4 as wide as our physical screen height. I think it should be done like this:

height = 4/3 yres
width  = 4/3 height

so width = 4/3 x 4/3 yres = 16/9 yres

So for each of the cases it would be:

1.- 400x256
2.- 432x256

However I've tested this and it looks too narrow, used to the other way, so I would keep the other method as a option (if you look at my code, I was already using original yres as the base for calculations but using 4/3 factor instead of 16/9, which was producing a 3:3 aspect). Anyway the explosions look circles so I think it must be ok. I still have to actually measure on the screen to see if this is working or not.



Interesting, I hadn't realized that but now makes sense, I'll have to play around with that too.  Sounds like there should be some way to get it working off of that pretty consistent although seems like this issue is a bit more tricky than that from my past experiments.

I'll have a new windows version up in a bit with at least the changes to try and do hwstretch better.  Have one up now but it's still not doing it like your explaining here, am forcing the video now so I can just go with the ddraw method.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #498 on: December 27, 2010, 07:20:34 pm »
Doing some tests, I seem to have found that the original method of lrmc somehow magically gets this where the games do look best, when applied like below to the original "height"  (which in the calculation by this time is transformed into the new width).  I don't know why that .5625 figure works, but suddenly now galaxian and frogger look better and even pacman, it was closer than those were but for some reason this seems to just work?  If I use .75 there or 3/4 it is too skinny like you said, so this game->width = (float)game->width / 0.5625; line is the one that seems to look best to me so far, odd though, I thought the lrmc calculation was always wrong but with your modeline generation logic it now looks quite right.

Code: [Select]
--- a/src/SwitchResC/xml.c
+++ b/src/SwitchResC/xml.c
@@ -209,8 +209,10 @@ int ParseXML(xmlDocPtr xmlbuffer, GameInfo *game, ConfigSettings *cs) {
                                                        game->width = h;
                                                        game->height = w;
                                                        game->orientation = 1;
-                                                       game->width = (4.0/3.0) * game->height;
+                                                       //game->width = (4.0/3.0) * game->height;
+                                                       game->width = (float)game->width / 0.5625;
                                                        //game->width = game->o_aspect * game->height;
+                                                       //game->width = game->width / (game->o_aspect);
                                                        } else {// orientation = horizontal
                                                        game->orientation = 0;
                                                        }

SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #499 on: December 27, 2010, 07:46:28 pm »
 Ok, in 1.220 which I just uploaded I'm trying to fix those three things, which I am not fully sure how it'll act so let me know :) I basically used the fix above for the vertical games width calculation, virtualize the cases where we can't find a resolution to fit into without being extra wide (at least for now), and think I have the stretching better for Windows now.

Also you logs for the 4350 had a thing about DMA not being able to get enabled, I am suspicious of that line since I don't get it so sent that to Alex to look into.  The kernel I just tried unfortunately seems to have gained a latency bug of some sort where pressing the button doesn't always react and seems off.  I'm not sure where this has been introduced but they are doing some changes with the kernel scheduler right now so I probably will revert back or even possibly drop all the way back to the older one I'm using on my main installation.  I'm trying to figure out for sure though about that right now, hopefully can fix the audio though with the Alsa changes (if not OSS4 is the next step to try, but it doesn't enable on the CD and I'll have to probably build either/or versions, can't seem to have both), I think the linux-next kernel has been slightly getting worse about the latency thing and now it's bad enough to notice plus my network connection now has a rythmic time out pause to it so that's also annoying.  I'm hoping the latency thing doesn't have to do with the drm stuff, I'm thinking it isn't but also this linux-next branch is a moving target. 
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #500 on: December 27, 2010, 10:31:16 pm »
Weird, now I realize your calculation is the same as lrmc was doing and it's basically 9/16 and going about it by dividing instead of multiplying.  So maybe this is right, although I'm not sure why it's all based on 16:9 yet results seem nice for the most part.  I agree it seems a slight bit squished but then again might just be used to the other way I guess. I understand using the original actual monitor height, but odd to use HD tv aspect ratios in the calculation with that.  So I must be missing something, because it does look alright that way (well more like I expect, admit the 3/4 calculation seems nice for some games still or might just be what I'm used to).
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #501 on: December 28, 2010, 04:29:56 am »
Uploading LiveCD32-MinimalNoMedia-1.227-7be72c3.iso which should have the newer sound fixes, also I downgraded the kernel to the stable one for now to see how that goes.  I also have new switchres versions up (this iso has them) which have command line options to align to certain HZ values for the dotclock, so ported part of the code just not the predefined table yet.   It's interesting, I've seen some oddities with how the earlier Linux kernel seems a slight bet faster than it should be works better, the newer linux-next versions are slightly behind but have more latency issues it seems.  I think it's in between right now, newer development kernels are showing more accuracy but still slightly unstable, older stable one generally works nice no tearing but may be a little off in the speedy side.  Also have the option to use either the older method of vertical game calculations or newer one, so can play around with those options in Windows and Linux now and see how it works.  Hopefully this one can solve the audio issues, I at least suspect, one oddity was the older kernel named the radeon HDMI audio part a different name so had to add that in to blacklist it too.  Upload should be up in an hour or so.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #502 on: December 28, 2010, 04:45:54 am »
I'll test those when I get home.

Yes, the 16/9 is misleading because we're used to seeing it in the HD context, but it makes sense as it's the product of 4/3 x 4/3 (see the above equations), and the fact that lrmc was using the same factor reinforces this idea.

It's true that I had also got used to the other method (however, notice that I was using 4/3 of the original height, not the original width that is the method you were using), as it somewhat fills the screen more and can be nicer to the eye once you're used to it.



a = 4/3 b
b = 4/3 c

--> a = 16/9 c
« Last Edit: December 28, 2010, 06:47:28 am by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #503 on: December 28, 2010, 11:28:11 am »
In the new version I have these options...

  --vcalc [0|1|2]         Method of calculating width on vertical games (1 is wider than 0)
  --dcalign <HZ>          Align dotclock to Hz (Windows 10000 Linux 1000)

So basically --vcalc 0 (default) is the new correct way, 1 is the old 4/3 way which some people may like even though it's not as accurate.  It's interesting because looking through resolution modelines in the past I've seen both methods and now explains it that there's two methods like this or two types of people I guess (I like the new way best, but can see how the old way has appeal too for me).

In Linux the dotclock align is interesting, I haven't played with it in the 2.6.36.2 kernel (stable one currently) only the in between one I've got running at 2.6.37-rc3.  It doesn't seem to do much there aligning at 1000 to change refresh rate exactness yet 10000 for some reason kind of hits it close but a little over (and pacman gets that extra 313 line from that and breaks 80% of the time again, but runs when it runs almost exactly 100%).  So I'm guessing it's one of those close as you can get things and can't divide up the extra line and fiddle with it any closer, especially when forced down to 1000 granularity. 

In Windows how can it utilize those ones you calculated, since it stores them in alignment to 10000?  Something this has made me start wondering about, or is it the extra lines doing the work to in theory get to that value?  Also I see basically it goes max 5 lines more, mostly think I ported the code right, for at least the align to a value case, but was some difference I think again in C which made it in somewhat different...
Code: [Select]
        if (cs->dcalign) {
                int i;
                int newPclock = 0;
                int vIncr = 0;
                double newDiff = 0, Diff = 0;
                ModeLine newMode;
                memcpy(&newMode, mode, sizeof(struct ModeLine));
                if (cs->verbose > 3)
                        fprintf(stderr, "Vfreq = %f Game Refresh = %f\n", mode->vfreq, game->refresh);
                for (i = 0; i < 5; i++) {
                        /* calculate new horizontal frequency */
                        mode->hfreq = mode->vfreq * (mode->vtotal + i);
                        if (mode->hfreq <= monitor->HfreqMax) {
                                /* Fill horizontal part of modeline */
                                newMode.hfreq = mode->hfreq;
                                newMode.hactive = mode->hactive;
                                ModelineGetLineParams(&newMode, monitor);
                                newMode.pclock = mode->hfreq * newMode.htotal;
                                if (fabs(Normalize(newMode.pclock-cs->dcalign, cs->dcalign)-newMode.pclock) < fabs(Normalize(newMode.pclock, cs->dcalign)-newMode.pclock))
                                        newMode.pclock = Normalize(newMode.pclock, cs->dcalign) - cs->dcalign;
                                else   
                                        newMode.pclock = Normalize(newMode.pclock, cs->dcalign);
                                newMode.vfreq = newMode.pclock / ((mode->vtotal + i) * newMode.htotal);
                                newDiff = fabs(newMode.vfreq - mode->vfreq);
                                if (newDiff < Diff || Diff == 0) {
                                        if (cs->verbose > 3)
                                                fprintf(stderr, "[%d] Pclock: %d newVfreq: %f - Vfreq: %f newDiff = %f < Diff = %f\n",
                                                        i, newMode.pclock, newMode.vfreq, mode->vfreq, newDiff, Diff);
                                        Diff = newDiff;
                                        vIncr = i;
                                        newPclock = newMode.pclock;     
                                        mode->hactive = newMode.hactive;
                                        mode->hbegin = newMode.hbegin;
                                        mode->hend = newMode.hend;
                                        mode->htotal = newMode.htotal;
                                        if (newDiff < 0.01)
                                                break;
                                }
                        }
                }
                if (newPclock) {
                        mode->vtotal += vIncr;
                        mode->pclock = newPclock;
                } else {
                        mode->hfreq = mode->vfreq * mode->vtotal;
                        ModelineGetLineParams(mode, monitor);
                        mode->pclock = mode->htotal * mode->hfreq;
                }
        }

There were some oddities that might need working out, like in some cases had to revert to the default method of calculation and I should probably still align it in that case to retain the extra value the OS would chop off.  Also abs had to be fabs or else it only works with integers in C, and I break out early when newDiff is what seems like small enough else it didn't seem worth possibly 4 more lines to get .0001 precision which it did in the pacman case (and then broke it going above 312 lines).  Also testing that pacman case is interesting, I can also break it by raising the dotclock another 10000 too, without more lines.  So it's not just the lines that triggers the random wideness, but also or maybe more importantly the dotclock bandwidth or perhaps the Hfreq above 18900 that does it (like 18920 can trigger the issue from what I can tell, but 18900 perfect every time).  I'm wondering if I need to make the cutoff that 1100 Hz lower for that range, currently it's 20000. 
   
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #504 on: December 28, 2010, 01:43:38 pm »
Today I won't probably get home till late night so I won't be able to test that yet. I've downloaded and burnt the stuff just in case.

In Windows how can it utilize those ones you calculated, since it stores them in alignment to 10000?  Something this has made me start wondering about, or is it the extra lines doing the work to in theory get to that value?  Also I see basically it goes max 5 lines more, mostly think I ported the code right, for at least the align to a value case, but was some difference I think again in C which made it in somewhat different...

That iterative routine does two things at the same time:

- It uses the dotclock precalcutated values, by picking the aligned to 10000 value that the driver admits, and entering the table to see what will be actually used by the card, to see if we are closer with either that value or the ones right above and below, and...

- Iterates the same calculations with some extra lines, for instance sometimes you can get closer to 60Hz with 263 lines than 262, or say 265, and I wanted to get the best possible combination. However that introduces an incremented hfreq, that has also side effects, that's why I can disable the loop by setting the iterations variable to 0, so the loop is just run once, it still get the right values for the dotclock, but does not iterate.

So you can just forget about iterating but using the right values once. However that (reading the dotclock table, not iterating) could only be interesting in Windows, were we have less accuracy by design, it seems.

It's interesting what you're seeing with pacman, it could turn out to be hfreq the critical factor for your monitor's decisions after all, it would be nice to know that for sure. If just increasing the dotclock is causing that, it really seems it's hfreq the value your monitor is measuring (and that can explain the fuzzy behaviour, as it's not easy to measure that with accuracy in real time).
« Last Edit: December 28, 2010, 01:47:58 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #505 on: December 28, 2010, 04:51:06 pm »
I'm wondering about tuning the PLL clocks better, possibly that is why I'm seeing the slight lower refresh rate happen past 2.6.36.2, seems to have started right after that when they started doing more calculations for the PLL stuff.  There is a min and max, for both out and in, are there optimal values that you know for each of those.  Alex mentioned that basically your tuning the performance for a range, so wouldn't we even benefit from a lower max.  Also what out the input ones, do those need alternate settings possibly?   Besides that there's memory and a few other PLL clocks, curious if you have ideas of values for these and any information on setting up a PLL for ATI video cards.

These seem to be the basic defaults (currently, lowered the min from 12500) for a card greater than an r400...

Code: [Select]
               p1pll->pll_in_min = 100;
                p1pll->pll_in_max = 1350;
                p1pll->pll_out_min = 3000;
                p1pll->pll_out_max = 50000;

The other defaults normally (this is done if card doesn't have preferences)
                p1pll->min_post_div = 2;
                p1pll->max_post_div = 0x7f;
                p1pll->min_frac_feedback_div = 0;
                p1pll->max_frac_feedback_div = 9;


                                p1pll->reference_freq = 2700;
                                p2pll->reference_freq = 2700;
                                spll->reference_freq = 2700;
                                mpll->reference_freq = 2700;

        /* dcpll is DCE4 only */
        dcpll->min_post_div = 2;
        dcpll->max_post_div = 0x7f;
        dcpll->min_frac_feedback_div = 0;
        dcpll->max_frac_feedback_div = 9;
        dcpll->min_ref_div = 2;
        dcpll->max_ref_div = 0x3ff;
        dcpll->min_feedback_div = 4;
        dcpll->max_feedback_div = 0xfff;
        dcpll->best_vco = 0;

        p1pll->min_ref_div = 2;
        p1pll->max_ref_div = 0x3ff;
        p1pll->min_feedback_div = 4;
        p1pll->max_feedback_div = 0x7ff;
        p1pll->best_vco = 0;

        p2pll->min_ref_div = 2;
        p2pll->max_ref_div = 0x3ff;
        p2pll->min_feedback_div = 4;
        p2pll->max_feedback_div = 0x7ff;
        p2pll->best_vco = 0;

        /* system clock */
        spll->min_post_div = 1;
        spll->max_post_div = 1;
        spll->min_ref_div = 2;
        spll->max_ref_div = 0xff;
        spll->min_feedback_div = 4;
        spll->max_feedback_div = 0xff;
        spll->best_vco = 0;

        /* memory clock */
        mpll->min_post_div = 1;
        mpll->max_post_div = 1;
        mpll->min_ref_div = 2;
        mpll->max_ref_div = 0xff;
        mpll->min_feedback_div = 4;
        mpll->max_feedback_div = 0xff;
        mpll->best_vco = 0;

And this part seems like if it's less than 15 it does one thing, but what about lower since they are expecting only down to 12 usually...

Code: [Select]
       if (req_clock < 15000) {
                *post_div = 8;
                req_clock *= 8;
        } else if (req_clock < 30000) {
                *post_div = 4;
                req_clock *= 4;
        } else if (req_clock < 60000) {
                *post_div = 2;
                req_clock *= 2;
        } else
                *post_div = 1;

        req_clock *= ref_div;
        req_clock += spll->reference_freq;
        req_clock /= (2 * spll->reference_freq);

        *fb_div = req_clock & 0xff;

        req_clock = (req_clock & 0xffff) << 1;
        req_clock *= spll->reference_freq;
        req_clock /= ref_div;
        req_clock /= *post_div;



What I've been seeing is basically games run at 100.13% speed in 2.6.36.2 while after that they are around 97-99 depending on the game, so one overshoots slightly then after that they are undershooting quite a bit more sometimes.  They might run smoother though on the later kernel but slower, although that's where if I use 10000 increment alignments of the pixel clock suddenly they run at exactly 100% but then that kills pacman almost always.  I don't know why 10000 is working, when in the kernel code everything is at 1000 granularity, seems strange and suspicious like they are loosing that much more now somewhere.
« Last Edit: December 28, 2010, 04:56:16 pm by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #506 on: December 29, 2010, 07:55:01 am »
That part where the clocks are calculated looks interesting and must have the clue for the granularity we're seeing, if we could understand what's being done I believe I could even guess which values are being used in Windows that are behind the results I have in that table, and would be great to be able to calculate those instead of having a table. However that C syntax is sticky and a pain for me, that way of writting stuff like += *= /= can be handy but is hiding the actual equations logic, I'll have a look anyway. Where's the 'ref_div' value defined?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #507 on: December 29, 2010, 10:59:07 am »
That part where the clocks are calculated looks interesting and must have the clue for the granularity we're seeing, if we could understand what's being done I believe I could even guess which values are being used in Windows that are behind the results I have in that table, and would be great to be able to calculate those instead of having a table. However that C syntax is sticky and a pain for me, that way of writting stuff like += *= /= can be handy but is hiding the actual equations logic, I'll have a look anyway. Where's the 'ref_div' value defined?

It looks like it most of the time comes from the bios itself, this value of reference_div below is what gets set to ref_div or else it also again checks the bios for it.   Here you can see though if they can't get it from the bios, or it's below 2, then it set to 12.  So 12 seems like the default for it.

Code: [Select]
               if (p1pll->reference_div < 2) {
                        if (!ASIC_IS_AVIVO(rdev)) {
                                u32 tmp = RREG32_PLL(RADEON_PPLL_REF_DIV);
                                if (ASIC_IS_R300(rdev))
                                        p1pll->reference_div =
                                                (tmp & R300_PPLL_REF_DIV_ACC_MASK) >> R300_PPLL_REF_DIV_ACC_SHIFT;
                                else
                                        p1pll->reference_div = tmp & RADEON_PPLL_REF_DIV_MASK;
                                if (p1pll->reference_div < 2)
                                        p1pll->reference_div = 12;
                        } else
                                p1pll->reference_div = 12;
                }
                if (p2pll->reference_div < 2)
                        p2pll->reference_div = 12;
                if (rdev->family < CHIP_RS600) {
                        if (spll->reference_div < 2)
                                spll->reference_div =
                                        RREG32_PLL(RADEON_M_SPLL_REF_FB_DIV) &
                                        RADEON_M_SPLL_REF_DIV_MASK;
                }
                if (mpll->reference_div < 2)
                        mpll->reference_div = spll->reference_div;



Also interesting that I've found the newest linux-next drm code seems to actually be getting exactly the right refresh rate and game speed, but there's a problem.  For some reason it takes up just a bit more CPU than before, although I'm hoping it's the rest of the kernel doing that part.  Basically it runs fine for most games, but for virtua racer it hits the CPU top (for me) of one of my dual cores and really wants 120% CPU where before it used about 90% max.  So there's a bit more CPU usage, not out of control, but everything looks to be a little heavier load.  I'm going to test the newer DRM put into the stable kernel (just figured out I could pull the DRM code out and replace it into older kernels), since if that CPU issue goes away it looks really good.  Also the latency of button pushing I saw, was my switch in my button, cheap zippy switch in there seems to have already gotten slow and a new one fixed the issue.  Ordered some of those micro leaf ones, just glad that really wasn't the issue I thought since that was really starting to become a vague problem I had no idea how to go about fixing :/.

The main file all that code is in is the radeon_clocks.c file:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=radeon/radeon_clocks.c;h=5249af8931e60549e01362102f9c8ca941ba0d24;hb=HEAD

Also it references the radeon_atombios.c file for getting values from the bios (about line 1079 this is where it starts getting interesting):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=radeon/radeon_atombios.c;h=bc5a2c3382d92fbd10efca3f29f69a927e381fc0;hb=HEAD
« Last Edit: December 29, 2010, 11:12:10 am by bitbytebit »
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #508 on: December 29, 2010, 11:34:13 am »
Thanks a lot for the references, I'll have a look. Also today I'll hopefully test the other stuff, new iso and switchres, I'm eager to see it dealing with vertical games.

That CPU usage increase... could it be due to the way it's performing vsync now? In that case it would come from the new drm part...
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #509 on: December 29, 2010, 12:02:34 pm »
Thanks a lot for the references, I'll have a look. Also today I'll hopefully test the other stuff, new iso and switchres, I'm eager to see it dealing with vertical games.

That CPU usage increase... could it be due to the way it's performing vsync now? In that case it would come from the new drm part...

Yeah that's what I kinda thought too could be a possibility.  They just put in a bunch of stuff that can do exact timestamping of each vblank, fully know what line it's on at all times I guess.  Could be now that things are really pushing out every single frame/line in time that games like virtua racer just need more CPU to do that.  Everything looks great and virtua racer plays great, just a choppy audio running at 90% or so (if I had a bigger CPU, it's 1.8Ghz each core, or if vsyncwait worked with multithreading in mame, things would be fine).  That's one thing I'm wondering too, why must multi threading be turned off for vsyncwait, is it a hard limitation or is it just being lazy and could be coded to handle more processors in mame.  That would really improve the vsync stuff, but can see too where it might just go against the whole way that works too for multiple threads to be used unless there was a way to time them together.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #510 on: December 29, 2010, 12:28:20 pm »
Yeah that's what I kinda thought too could be a possibility.  They just put in a bunch of stuff that can do exact timestamping of each vblank, fully know what line it's on at all times I guess.  Could be now that things are really pushing out every single frame/line in time that games like virtua racer just need more CPU to do that.  Everything looks great and virtua racer plays great, just a choppy audio running at 90% or so (if I had a bigger CPU, it's 1.8Ghz each core, or if vsyncwait worked with multithreading in mame, things would be fine).  That's one thing I'm wondering too, why must multi threading be turned off for vsyncwait, is it a hard limitation or is it just being lazy and could be coded to handle more processors in mame.  That would really improve the vsync stuff, but can see too where it might just go against the whole way that works too for multiple threads to be used unless there was a way to time them together.

That's interesting, I didn't know that multithreading had to be turned off for vsyncwait. I was thinking that when you request the system for vsync, it must start a thread somewhere to keep an eye on the hardware ports that return the retrace state. Depending on how that's done, that loop could eat all the cpu cycles in the worst case (it's not that simple). For instance, in my experience, triplebuffer is much lighter for cpu that a normal waitvsync, as the cpu can start working with the next frame right after it dispatches the previous one.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #511 on: December 29, 2010, 05:41:52 pm »
I wanted to test the latest iso but the damned machine does not read the cd (I'm using a cd-rw as I run out of cds, so I'll try again with a normal one).

So I've been testing Switchres for Windows, with the new stuff for vertical games and 120 modes. This thing is really impressive now. Even in the good old times of AdvanceMame this was never achieved. This is the mode table I'm using now, it still needs some optimization however, some of them could be redundant:

Code: [Select]
Modeline "184x192_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 192 218 221 261 -hsync -vsync
Modeline "184x208_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 208 226 229 261 -hsync -vsync
Modeline "192x208_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 208 226 229 261 -hsync -vsync
Modeline "192x224_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 224 234 237 261 -hsync -vsync
Modeline "208x208_60 15.67KHz 60.04Hz" 4.380 208 216 240 280 208 226 229 261 -hsync -vsync
Modeline "216x224_60 15.68KHz 60.07Hz" 4.640 216 232 256 296 224 234 237 261 -hsync -vsync
Modeline "224x240_60 15.67KHz 60.05Hz" 4.760 224 240 264 304 240 242 245 261 -hsync -vsync
Modeline "232x224_60 15.68KHz 60.09Hz" 4.890 232 248 272 312 224 234 237 261 -hsync -vsync
Modeline "240x192_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 192 218 221 261 -hsync -vsync
Modeline "240x224_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 224 234 237 261 -hsync -vsync
Modeline "240x240_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 240 242 245 261 -hsync -vsync
Modeline "240x256_60 16.65KHz 60.12Hz" 5.590 240 256 288 336 256 257 260 277 -hsync -vsync
Modeline "248x224_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 224 234 237 261 -hsync -vsync
Modeline "248x240_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 240 242 245 261 -hsync -vsync
Modeline "248x256_60 16.64KHz 60.06Hz" 5.720 248 264 296 344 256 257 260 277 -hsync -vsync
Modeline "256x192_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 192 218 221 261 -hsync -vsync
Modeline "256x208_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 208 226 229 261 -hsync -vsync
Modeline "256x224_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x240_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "256x256_60 16.65KHz 60.12Hz" 5.860 256 272 304 352 256 257 260 277 -hsync -vsync
Modeline "256x288_54 16.68KHz 53.99Hz" 5.870 256 272 304 352 288 289 292 309 -hsync -vsync
Modeline "256x512_60 16.65KHz 60.01Hz" 5.860 256 272 304 352 512 514 519 555 interlace -hsync -vsync
Modeline "264x224_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 224 234 237 261 -hsync -vsync
Modeline "264x240_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 240 242 245 261 -hsync -vsync
Modeline "272x224_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 224 234 237 261 -hsync -vsync
Modeline "272x240_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 240 242 245 261 -hsync -vsync
Modeline "280x224_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 224 234 237 261 -hsync -vsync
Modeline "280x240_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 240 242 245 261 -hsync -vsync
Modeline "288x208_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 208 226 229 261 -hsync -vsync
Modeline "288x224_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 224 234 237 261 -hsync -vsync
Modeline "288x240_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 240 242 245 261 -hsync -vsync
Modeline "296x224_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 224 234 237 261 -hsync -vsync
Modeline "296x240_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 240 242 245 261 -hsync -vsync
Modeline "304x224_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 224 234 237 261 -hsync -vsync
Modeline "304x240_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 240 242 245 261 -hsync -vsync
Modeline "320x192_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 192 218 221 261 -hsync -vsync
Modeline "320x208_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 208 226 229 261 -hsync -vsync
Modeline "320x224_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 240 242 245 261 -hsync -vsync
Modeline "320x256_60 16.62KHz 60.01Hz" 7.040 320 336 368 424 256 257 260 277 -hsync -vsync
Modeline "328x224_60 15.72KHz 60.21Hz" 6.780 328 344 376 432 224 234 237 261 -hsync -vsync
Modeline "328x256_60 16.64KHz 60.06Hz" 7.450 328 344 384 448 256 257 260 277 -hsync -vsync
Modeline "336x240_60 15.66KHz 60.00Hz" 6.890 336 352 384 440 240 242 245 261 -hsync -vsync
Modeline "336x256_60 16.65KHz 60.12Hz" 7.580 336 352 392 456 256 257 260 277 -hsync -vsync
Modeline "344x240_60 15.66KHz 60.01Hz" 7.010 344 360 392 448 240 242 245 261 -hsync -vsync
Modeline "344x256_60 16.63KHz 60.02Hz" 7.710 344 360 400 464 256 257 260 277 -hsync -vsync
Modeline "352x224_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 224 234 237 261 -hsync -vsync
Modeline "352x240_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 240 242 245 261 -hsync -vsync
Modeline "352x256_60 16.63KHz 60.04Hz" 7.850 352 368 408 472 256 257 260 277 -hsync -vsync
Modeline "360x224_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 224 234 237 261 -hsync -vsync
Modeline "360x240_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 240 242 245 261 -hsync -vsync
Modeline "368x240_60 15.66KHz 60.01Hz" 7.640 368 384 424 488 240 242 245 261 -hsync -vsync
Modeline "368x256_60 16.66KHz 60.15Hz" 8.130 368 384 424 488 256 257 260 277 -hsync -vsync
Modeline "368x448_60 15.65KHz 60.08Hz" 7.630 368 384 424 488 448 466 471 521 interlace -hsync -vsync
Modeline "376x240_60 15.68KHz 60.07Hz" 7.770 376 392 432 496 240 242 245 261 -hsync -vsync
Modeline "376x256_60 16.63KHz 60.03Hz" 8.390 376 392 432 504 256 257 260 277 -hsync -vsync
Modeline "376x272_57 16.74KHz 57.14Hz" 8.430 376 392 432 504 272 273 276 293 -hsync -vsync
Modeline "384x224_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 224 234 237 261 -hsync -vsync
Modeline "384x240_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 240 242 245 261 -hsync -vsync
Modeline "384x256_60 16.64KHz 60.06Hz" 8.500 384 400 440 512 256 257 260 277 -hsync -vsync
Modeline "384x288_54 16.67KHz 53.96Hz" 8.520 384 400 440 512 288 289 292 309 -hsync -vsync
Modeline "400x224_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 224 234 237 261 -hsync -vsync
Modeline "400x240_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 240 242 245 261 -hsync -vsync
Modeline "400x248_60 16.15KHz 60.03Hz" 8.510 400 416 456 528 248 250 253 269 -hsync -vsync
Modeline "400x256_60 16.66KHz 60.16Hz" 8.790 400 416 456 528 256 257 260 277 -hsync -vsync
Modeline "400x264_59 16.69KHz 58.56Hz" 8.810 400 416 456 528 264 265 268 285 -hsync -vsync
Modeline "400x272_57 16.69KHz 56.96Hz" 8.810 400 416 456 528 272 273 276 293 -hsync -vsync
Modeline "400x280_55 16.69KHz 55.45Hz" 8.810 400 416 456 528 280 281 284 301 -hsync -vsync
Modeline "400x288_54 16.69KHz 54.01Hz" 8.810 400 416 456 528 288 289 292 309 -hsync -vsync
Modeline "416x208_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 208 226 229 261 -hsync -vsync
Modeline "416x224_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 224 234 237 261 -hsync -vsync
Modeline "416x256_60 16.64KHz 60.06Hz" 9.450 416 440 488 568 256 257 260 277 -hsync -vsync
Modeline "432x224_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 224 234 237 261 -hsync -vsync
Modeline "432x240_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 240 242 245 261 -hsync -vsync
Modeline "432x248_60 16.18KHz 60.15Hz" 9.450 432 456 504 584 248 250 253 269 -hsync -vsync
Modeline "432x256_60 16.67KHz 60.18Hz" 9.720 432 456 504 584 256 257 260 277 -hsync -vsync
Modeline "432x264_58 16.67KHz 58.49Hz" 9.720 432 456 504 584 264 265 268 285 -hsync -vsync
Modeline "432x272_57 16.67KHz 56.89Hz" 9.720 432 456 504 584 272 273 276 293 -hsync -vsync
Modeline "432x280_55 16.67KHz 55.38Hz" 9.720 432 456 504 584 280 281 284 301 -hsync -vsync
Modeline "448x224_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 224 234 237 261 -hsync -vsync
Modeline "448x240_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 240 242 245 261 -hsync -vsync
Modeline "456x240_60 15.66KHz 60.01Hz" 9.530 456 480 528 608 240 242 245 261 -hsync -vsync
Modeline "456x256_60 16.65KHz 60.12Hz" 10.110 456 480 528 608 256 257 260 277 -hsync -vsync
Modeline "464x224_60 15.69KHz 60.11Hz" 9.660 464 488 536 616 224 234 237 261 -hsync -vsync
Modeline "464x256_60 16.63KHz 60.04Hz" 10.230 464 488 536 616 256 257 260 277 -hsync -vsync
Modeline "480x224_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 224 234 237 261 -hsync -vsync
Modeline "480x240_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 240 242 245 261 -hsync -vsync
Modeline "480x464_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 464 474 479 521 interlace -hsync -vsync
Modeline "480x480_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 480 482 487 521 interlace -hsync -vsync
Modeline "496x224_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 224 234 237 261 -hsync -vsync
Modeline "496x240_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 240 242 245 261 -hsync -vsync
Modeline "496x480_60 15.69KHz 60.24Hz" 10.150 496 520 568 648 480 482 487 521 interlace -hsync -vsync
Modeline "512x224_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 224 234 237 261 -hsync -vsync
Modeline "512x240_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 240 242 245 261 -hsync -vsync
Modeline "512x256_60 16.62KHz 60.01Hz" 11.420 512 536 592 688 256 257 260 277 -hsync -vsync
Modeline "512x288_54 16.68KHz 53.98Hz" 11.470 512 536 592 688 288 289 292 309 -hsync -vsync
Modeline "512x448_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 448 466 471 521 interlace -hsync -vsync
Modeline "512x480_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 480 482 487 521 interlace -hsync -vsync
Modeline "512x512_60 16.68KHz 60.10Hz" 11.470 512 536 592 688 512 514 519 555 interlace -hsync -vsync
Modeline "544x256_60 16.64KHz 60.07Hz" 11.980 544 568 624 720 256 257 260 277 -hsync -vsync
Modeline "544x480_60 15.64KHz 60.05Hz" 11.130 544 568 624 712 480 482 487 521 interlace -hsync -vsync
Modeline "640x208_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 208 226 229 261 -hsync -vsync
Modeline "640x240_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 240 242 245 261 -hsync -vsync
Modeline "640x256_60 16.64KHz 60.08Hz" 14.100 640 672 736 848 256 257 260 277 -hsync -vsync
Modeline "640x480_60 15.65KHz 60.06Hz" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "672x224_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 224 234 237 261 -hsync -vsync
Modeline "672x240_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 240 242 245 261 -hsync -vsync
Modeline "672x272_57 16.68KHz 56.93Hz" 14.940 672 704 776 896 272 273 276 293 -hsync -vsync
Modeline "688x512_60 16.65KHz 60.01Hz" 15.160 688 720 792 912 512 514 519 555 interlace -hsync -vsync
Modeline "704x240_60 15.68KHz 60.09Hz" 14.540 704 736 808 928 240 242 245 261 -hsync -vsync
Modeline "704x480_60 15.64KHz 60.03Hz" 14.500 704 736 808 928 480 482 487 521 interlace -hsync -vsync
Modeline "704x512_60 16.68KHz 60.09Hz" 15.590 704 736 808 936 512 514 519 555 interlace -hsync -vsync
Modeline "712x512_60 16.68KHz 60.12Hz" 15.730 712 744 816 944 512 514 519 555 interlace -hsync -vsync
Modeline "720x512_60 16.66KHz 60.04Hz" 15.850 720 752 824 952 512 514 519 555 interlace -hsync -vsync
Modeline "768x224_60 15.67KHz 60.04Hz" 15.640 768 800 872 1000 224 234 237 261 -hsync -vsync
Modeline "768x480_60 15.65KHz 60.07Hz" 15.630 768 800 872 1000 480 482 487 521 interlace -hsync -vsync
Modeline "800x512_60 16.66KHz 60.05Hz" 17.600 800 832 912 1056 512 514 519 555 interlace -hsync -vsync
Modeline "856x512_60 16.67KHz 60.07Hz" 18.940 856 896 984 1136 512 514 519 555 interlace -hsync -vsync
Modeline "912x512_60 16.66KHz 60.02Hz" 20.160 912 952 1048 1208 512 514 519 555 interlace -hsync -vsync
Modeline "1024x480_60 15.67KHz 60.16Hz" 20.770 1024 1064 1160 1328 480 482 487 521 interlace -hsync -vsync
Modeline "1024x512_60 16.66KHz 60.04Hz" 22.660 1024 1072 1176 1360 512 514 519 555 interlace -hsync -vsync

I'm using --vcalc 0, anyway I can't see any difference among 0 and 2 (1 is wider). Virtualized resolutions look ok now, filling the screen when needed. I'd like to figure out a way to precalculate some virtualized modes for Swichres to use, maybe it could be good to reserve 10 modes to cover 50-60Hz, by 0.1Hz steps, so that they could be tweaked later to fine tune them just a bit. That way I could fully benefit from the higher resolution available for lower vfreqs.

I've managed to config AdvanceMenu to launch Switchres instead of Mame, using this lines:

Code: [Select]
emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"
emulator_roms "mame_switchres" "c:\Roms\Mame\"
emulator_roms_filter "mame_switchres" "*.zip
emulator_flyers "mame_switchres" "c:\Snaps\Mame\"

(the only disadvantage is that I get the zip names instead of full names in the menu)

Some games which video mode was dropped for being rare when using a static mode table are running now at their native resolution and vfreq, this is very cool.

Something we should add at some point is an option for playing vertical games on full screen, not in a rotated frame. I know people that physically rotate their crts when playing vertical games, they look and feel so much better that way. We should have a way to make that possible (using 'ror 1' and the native resolution).

It would be helpful also to have with the -v option which parameters are being passed to Mame.
« Last Edit: December 29, 2010, 05:44:03 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #512 on: December 29, 2010, 06:41:45 pm »
I wanted to test the latest iso but the damned machine does not read the cd (I'm using a cd-rw as I run out of cds, so I'll try again with a normal one).

So I've been testing Switchres for Windows, with the new stuff for vertical games and 120 modes. This thing is really impressive now. Even in the good old times of AdvanceMame this was never achieved. This is the mode table I'm using now, it still needs some optimization however, some of them could be redundant:

Code: [Select]
Modeline "184x192_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 192 218 221 261 -hsync -vsync
Modeline "184x208_60 15.70KHz 60.16Hz" 3.890 184 192 216 248 208 226 229 261 -hsync -vsync
Modeline "192x208_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 208 226 229 261 -hsync -vsync
Modeline "192x224_60 15.69KHz 60.13Hz" 4.010 192 200 224 256 224 234 237 261 -hsync -vsync
Modeline "208x208_60 15.67KHz 60.04Hz" 4.380 208 216 240 280 208 226 229 261 -hsync -vsync
Modeline "216x224_60 15.68KHz 60.07Hz" 4.640 216 232 256 296 224 234 237 261 -hsync -vsync
Modeline "224x240_60 15.67KHz 60.05Hz" 4.760 224 240 264 304 240 242 245 261 -hsync -vsync
Modeline "232x224_60 15.68KHz 60.09Hz" 4.890 232 248 272 312 224 234 237 261 -hsync -vsync
Modeline "240x192_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 192 218 221 261 -hsync -vsync
Modeline "240x224_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 224 234 237 261 -hsync -vsync
Modeline "240x240_60 15.66KHz 60.00Hz" 5.010 240 256 280 320 240 242 245 261 -hsync -vsync
Modeline "240x256_60 16.65KHz 60.12Hz" 5.590 240 256 288 336 256 257 260 277 -hsync -vsync
Modeline "248x224_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 224 234 237 261 -hsync -vsync
Modeline "248x240_60 15.69KHz 60.13Hz" 5.270 248 264 288 336 240 242 245 261 -hsync -vsync
Modeline "248x256_60 16.64KHz 60.06Hz" 5.720 248 264 296 344 256 257 260 277 -hsync -vsync
Modeline "256x192_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 192 218 221 261 -hsync -vsync
Modeline "256x208_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 208 226 229 261 -hsync -vsync
Modeline "256x224_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x240_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "256x256_60 16.65KHz 60.12Hz" 5.860 256 272 304 352 256 257 260 277 -hsync -vsync
Modeline "256x288_54 16.68KHz 53.99Hz" 5.870 256 272 304 352 288 289 292 309 -hsync -vsync
Modeline "256x512_60 16.65KHz 60.01Hz" 5.860 256 272 304 352 512 514 519 555 interlace -hsync -vsync
Modeline "264x224_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 224 234 237 261 -hsync -vsync
Modeline "264x240_60 15.67KHz 60.02Hz" 5.630 264 280 312 360 240 242 245 261 -hsync -vsync
Modeline "272x224_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 224 234 237 261 -hsync -vsync
Modeline "272x240_60 15.67KHz 60.03Hz" 5.760 272 288 320 368 240 242 245 261 -hsync -vsync
Modeline "280x224_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 224 234 237 261 -hsync -vsync
Modeline "280x240_60 15.71KHz 60.18Hz" 5.890 280 296 328 376 240 242 245 261 -hsync -vsync
Modeline "288x208_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 208 226 229 261 -hsync -vsync
Modeline "288x224_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 224 234 237 261 -hsync -vsync
Modeline "288x240_60 15.69KHz 60.13Hz" 6.020 288 304 336 384 240 242 245 261 -hsync -vsync
Modeline "296x224_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 224 234 237 261 -hsync -vsync
Modeline "296x240_60 15.68KHz 60.08Hz" 6.140 296 312 344 392 240 242 245 261 -hsync -vsync
Modeline "304x224_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 224 234 237 261 -hsync -vsync
Modeline "304x240_60 15.67KHz 60.05Hz" 6.390 304 320 352 408 240 242 245 261 -hsync -vsync
Modeline "320x192_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 192 218 221 261 -hsync -vsync
Modeline "320x208_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 208 226 229 261 -hsync -vsync
Modeline "320x224_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_60 15.67KHz 60.04Hz" 6.640 320 336 368 424 240 242 245 261 -hsync -vsync
Modeline "320x256_60 16.62KHz 60.01Hz" 7.040 320 336 368 424 256 257 260 277 -hsync -vsync
Modeline "328x224_60 15.72KHz 60.21Hz" 6.780 328 344 376 432 224 234 237 261 -hsync -vsync
Modeline "328x256_60 16.64KHz 60.06Hz" 7.450 328 344 384 448 256 257 260 277 -hsync -vsync
Modeline "336x240_60 15.66KHz 60.00Hz" 6.890 336 352 384 440 240 242 245 261 -hsync -vsync
Modeline "336x256_60 16.65KHz 60.12Hz" 7.580 336 352 392 456 256 257 260 277 -hsync -vsync
Modeline "344x240_60 15.66KHz 60.01Hz" 7.010 344 360 392 448 240 242 245 261 -hsync -vsync
Modeline "344x256_60 16.63KHz 60.02Hz" 7.710 344 360 400 464 256 257 260 277 -hsync -vsync
Modeline "352x224_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 224 234 237 261 -hsync -vsync
Modeline "352x240_60 15.68KHz 60.06Hz" 7.390 352 368 408 472 240 242 245 261 -hsync -vsync
Modeline "352x256_60 16.63KHz 60.04Hz" 7.850 352 368 408 472 256 257 260 277 -hsync -vsync
Modeline "360x224_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 224 234 237 261 -hsync -vsync
Modeline "360x240_60 15.66KHz 60.00Hz" 7.510 360 376 416 480 240 242 245 261 -hsync -vsync
Modeline "368x240_60 15.66KHz 60.01Hz" 7.640 368 384 424 488 240 242 245 261 -hsync -vsync
Modeline "368x256_60 16.66KHz 60.15Hz" 8.130 368 384 424 488 256 257 260 277 -hsync -vsync
Modeline "368x448_60 15.65KHz 60.08Hz" 7.630 368 384 424 488 448 466 471 521 interlace -hsync -vsync
Modeline "376x240_60 15.68KHz 60.07Hz" 7.770 376 392 432 496 240 242 245 261 -hsync -vsync
Modeline "376x256_60 16.63KHz 60.03Hz" 8.390 376 392 432 504 256 257 260 277 -hsync -vsync
Modeline "376x272_57 16.74KHz 57.14Hz" 8.430 376 392 432 504 272 273 276 293 -hsync -vsync
Modeline "384x224_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 224 234 237 261 -hsync -vsync
Modeline "384x240_60 15.67KHz 60.04Hz" 7.890 384 400 440 504 240 242 245 261 -hsync -vsync
Modeline "384x256_60 16.64KHz 60.06Hz" 8.500 384 400 440 512 256 257 260 277 -hsync -vsync
Modeline "384x288_54 16.67KHz 53.96Hz" 8.520 384 400 440 512 288 289 292 309 -hsync -vsync
Modeline "400x224_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 224 234 237 261 -hsync -vsync
Modeline "400x240_60 15.68KHz 60.09Hz" 8.150 400 416 456 520 240 242 245 261 -hsync -vsync
Modeline "400x248_60 16.15KHz 60.03Hz" 8.510 400 416 456 528 248 250 253 269 -hsync -vsync
Modeline "400x256_60 16.66KHz 60.16Hz" 8.790 400 416 456 528 256 257 260 277 -hsync -vsync
Modeline "400x264_59 16.69KHz 58.56Hz" 8.810 400 416 456 528 264 265 268 285 -hsync -vsync
Modeline "400x272_57 16.69KHz 56.96Hz" 8.810 400 416 456 528 272 273 276 293 -hsync -vsync
Modeline "400x280_55 16.69KHz 55.45Hz" 8.810 400 416 456 528 280 281 284 301 -hsync -vsync
Modeline "400x288_54 16.69KHz 54.01Hz" 8.810 400 416 456 528 288 289 292 309 -hsync -vsync
Modeline "416x208_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 208 226 229 261 -hsync -vsync
Modeline "416x224_60 15.67KHz 60.05Hz" 8.510 416 432 472 544 224 234 237 261 -hsync -vsync
Modeline "416x256_60 16.64KHz 60.06Hz" 9.450 416 440 488 568 256 257 260 277 -hsync -vsync
Modeline "432x224_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 224 234 237 261 -hsync -vsync
Modeline "432x240_60 15.67KHz 60.04Hz" 8.760 432 448 488 560 240 242 245 261 -hsync -vsync
Modeline "432x248_60 16.18KHz 60.15Hz" 9.450 432 456 504 584 248 250 253 269 -hsync -vsync
Modeline "432x256_60 16.67KHz 60.18Hz" 9.720 432 456 504 584 256 257 260 277 -hsync -vsync
Modeline "432x264_58 16.67KHz 58.49Hz" 9.720 432 456 504 584 264 265 268 285 -hsync -vsync
Modeline "432x272_57 16.67KHz 56.89Hz" 9.720 432 456 504 584 272 273 276 293 -hsync -vsync
Modeline "432x280_55 16.67KHz 55.38Hz" 9.720 432 456 504 584 280 281 284 301 -hsync -vsync
Modeline "448x224_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 224 234 237 261 -hsync -vsync
Modeline "448x240_60 15.67KHz 60.04Hz" 9.400 448 472 520 600 240 242 245 261 -hsync -vsync
Modeline "456x240_60 15.66KHz 60.01Hz" 9.530 456 480 528 608 240 242 245 261 -hsync -vsync
Modeline "456x256_60 16.65KHz 60.12Hz" 10.110 456 480 528 608 256 257 260 277 -hsync -vsync
Modeline "464x224_60 15.69KHz 60.11Hz" 9.660 464 488 536 616 224 234 237 261 -hsync -vsync
Modeline "464x256_60 16.63KHz 60.04Hz" 10.230 464 488 536 616 256 257 260 277 -hsync -vsync
Modeline "480x224_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 224 234 237 261 -hsync -vsync
Modeline "480x240_60 15.69KHz 60.10Hz" 9.910 480 504 552 632 240 242 245 261 -hsync -vsync
Modeline "480x464_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 464 474 479 521 interlace -hsync -vsync
Modeline "480x480_60 15.64KHz 60.03Hz" 9.880 480 504 552 632 480 482 487 521 interlace -hsync -vsync
Modeline "496x224_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 224 234 237 261 -hsync -vsync
Modeline "496x240_60 15.69KHz 60.13Hz" 10.150 496 520 568 648 240 242 245 261 -hsync -vsync
Modeline "496x480_60 15.69KHz 60.24Hz" 10.150 496 520 568 648 480 482 487 521 interlace -hsync -vsync
Modeline "512x224_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 224 234 237 261 -hsync -vsync
Modeline "512x240_60 15.69KHz 60.13Hz" 10.530 512 536 584 672 240 242 245 261 -hsync -vsync
Modeline "512x256_60 16.62KHz 60.01Hz" 11.420 512 536 592 688 256 257 260 277 -hsync -vsync
Modeline "512x288_54 16.68KHz 53.98Hz" 11.470 512 536 592 688 288 289 292 309 -hsync -vsync
Modeline "512x448_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 448 466 471 521 interlace -hsync -vsync
Modeline "512x480_60 15.65KHz 60.06Hz" 10.520 512 536 584 672 480 482 487 521 interlace -hsync -vsync
Modeline "512x512_60 16.68KHz 60.10Hz" 11.470 512 536 592 688 512 514 519 555 interlace -hsync -vsync
Modeline "544x256_60 16.64KHz 60.07Hz" 11.980 544 568 624 720 256 257 260 277 -hsync -vsync
Modeline "544x480_60 15.64KHz 60.05Hz" 11.130 544 568 624 712 480 482 487 521 interlace -hsync -vsync
Modeline "640x208_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 208 226 229 261 -hsync -vsync
Modeline "640x240_60 15.67KHz 60.05Hz" 13.040 640 664 728 832 240 242 245 261 -hsync -vsync
Modeline "640x256_60 16.64KHz 60.08Hz" 14.100 640 672 736 848 256 257 260 277 -hsync -vsync
Modeline "640x480_60 15.65KHz 60.06Hz" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "672x224_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 224 234 237 261 -hsync -vsync
Modeline "672x240_60 15.66KHz 60.00Hz" 13.770 672 704 768 880 240 242 245 261 -hsync -vsync
Modeline "672x272_57 16.68KHz 56.93Hz" 14.940 672 704 776 896 272 273 276 293 -hsync -vsync
Modeline "688x512_60 16.65KHz 60.01Hz" 15.160 688 720 792 912 512 514 519 555 interlace -hsync -vsync
Modeline "704x240_60 15.68KHz 60.09Hz" 14.540 704 736 808 928 240 242 245 261 -hsync -vsync
Modeline "704x480_60 15.64KHz 60.03Hz" 14.500 704 736 808 928 480 482 487 521 interlace -hsync -vsync
Modeline "704x512_60 16.68KHz 60.09Hz" 15.590 704 736 808 936 512 514 519 555 interlace -hsync -vsync
Modeline "712x512_60 16.68KHz 60.12Hz" 15.730 712 744 816 944 512 514 519 555 interlace -hsync -vsync
Modeline "720x512_60 16.66KHz 60.04Hz" 15.850 720 752 824 952 512 514 519 555 interlace -hsync -vsync
Modeline "768x224_60 15.67KHz 60.04Hz" 15.640 768 800 872 1000 224 234 237 261 -hsync -vsync
Modeline "768x480_60 15.65KHz 60.07Hz" 15.630 768 800 872 1000 480 482 487 521 interlace -hsync -vsync
Modeline "800x512_60 16.66KHz 60.05Hz" 17.600 800 832 912 1056 512 514 519 555 interlace -hsync -vsync
Modeline "856x512_60 16.67KHz 60.07Hz" 18.940 856 896 984 1136 512 514 519 555 interlace -hsync -vsync
Modeline "912x512_60 16.66KHz 60.02Hz" 20.160 912 952 1048 1208 512 514 519 555 interlace -hsync -vsync
Modeline "1024x480_60 15.67KHz 60.16Hz" 20.770 1024 1064 1160 1328 480 482 487 521 interlace -hsync -vsync
Modeline "1024x512_60 16.66KHz 60.04Hz" 22.660 1024 1072 1176 1360 512 514 519 555 interlace -hsync -vsync

I'm using --vcalc 0, anyway I can't see any difference among 0 and 2 (1 is wider). Virtualized resolutions look ok now, filling the screen when needed. I'd like to figure out a way to precalculate some virtualized modes for Swichres to use, maybe it could be good to reserve 10 modes to cover 50-60Hz, by 0.1Hz steps, so that they could be tweaked later to fine tune them just a bit. That way I could fully benefit from the higher resolution available for lower vfreqs.

I've managed to config AdvanceMenu to launch Switchres instead of Mame, using this lines:

Code: [Select]
emulator "mame_switchres" generic "c:\Emuladores\Mame\switchres.exe" "%s  --soft15khz --monitor h9110"
emulator_roms "mame_switchres" "c:\Roms\Mame\"
emulator_roms_filter "mame_switchres" "*.zip
emulator_flyers "mame_switchres" "c:\Snaps\Mame\"

(the only disadvantage is that I get the zip names instead of full names in the menu)

Some games which video mode was dropped for being rare when using a static mode table are running now at their native resolution and vfreq, this is very cool.

Something we should add at some point is an option for playing vertical games on full screen, not in a rotated frame. I know people that physically rotate their crts when playing vertical games, they look and feel so much better that way. We should have a way to make that possible (using 'ror 1' and the native resolution).

It would be helpful also to have with the -v option which parameters are being passed to Mame.


The 2 option for vcalc is really just hardcoded like lrmc did it, 0 is doing it the way you did instead so it's more dynamic but most likely always the same.  If you use 3, well then it won't actually change the width at all, I'm not sure but that might somewhat help the vertical monitor case?  I figure there's more checks involved, had thought about getting that eventually figured out.

If you use the -v option 2-3 times (-v -v -v) or more, it should show the exact mame command line it's using. 

Sounds like the issue your seeing on the 4350 has something to do with this...
https://bugs.freedesktop.org/show_bug.cgi?id=28410
Alex sent that to me, and said he hasn't had time to look closer but needs to find where it's most likely getting outputs confused listening to the vblank interrupts on the wrong output and so never gets them in your case where the monitor isn't detected.

Also I have proven the CPU usage speed up is in the DRM code, put the newest DRM into the stable kernel and it runs the same with the extra CPU, so I mentioned that to Alex to see what he says.  Would be nice to figure out how to do the multithreading in mame better, if possible, so it still could do vsync waiting and  use multi threading.  I looked at that code some, will probably take awhile for me to figure out how it exactly works, seems confusing.  It'll be interesting to see if this really is just overhead for how exact it seems to be working now, definitely hitting it at 100% exactly or if anything 100.1% but it's quite small compared to the .13 or close to 3% in the stable vs. the other kernels before the newest -next version.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #513 on: December 30, 2010, 05:45:05 am »
Feature request/Bugfix!

I've been tinkering with this on my cab. So far it's worked great.... from the command line. It's almost a direct drop in to use in my front end, Hyperspin with one caveat: Hyperspin wants to pass the romname as ROM.zip and there appears to be no way to have it not send the .zip part. Specifiying no extension still passes the . at the end. Switchres fails to identify the game (eg: "puckman.") and passes it straight on to mame in this format, but mame seems to figure it out and load anyway, however at that point switchres has passed on a bogus resolution (in my case, 640x480@60).

So if you can just have it ignore anything after a . in the rom argument I think works. I don't think there are any characters in official rom names that are outside of a-z.

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #514 on: December 30, 2010, 11:37:00 am »
Feature request/Bugfix!

I've been tinkering with this on my cab. So far it's worked great.... from the command line. It's almost a direct drop in to use in my front end, Hyperspin with one caveat: Hyperspin wants to pass the romname as ROM.zip and there appears to be no way to have it not send the .zip part. Specifiying no extension still passes the . at the end. Switchres fails to identify the game (eg: "puckman.") and passes it straight on to mame in this format, but mame seems to figure it out and load anyway, however at that point switchres has passed on a bogus resolution (in my case, 640x480@60).

So if you can just have it ignore anything after a . in the rom argument I think works. I don't think there are any characters in official rom names that are outside of a-z.

I just uploaded new binary versions, SwitchResWin-1.240-014952b.7z, which fixes this and removes anything after the main rom name.

Also note that this version no longer needs any extra .dll files besides the cygwin1.dll, it's now statically compiled with the others in the switchres.exe (should slightly improve run time speed in theory too, very small though probably in microseconds increase).

Thanks for the bug report and glad it's working good for you so far.
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization

newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #515 on: December 30, 2010, 11:47:31 am »
Feature request/Bugfix!

I've been tinkering with this on my cab. So far it's worked great.... from the command line. It's almost a direct drop in to use in my front end, Hyperspin with one caveat: Hyperspin wants to pass the romname as ROM.zip and there appears to be no way to have it not send the .zip part. Specifiying no extension still passes the . at the end. Switchres fails to identify the game (eg: "puckman.") and passes it straight on to mame in this format, but mame seems to figure it out and load anyway, however at that point switchres has passed on a bogus resolution (in my case, 640x480@60).

So if you can just have it ignore anything after a . in the rom argument I think works. I don't think there are any characters in official rom names that are outside of a-z.

I just uploaded new binary versions, SwitchResWin-1.240-014952b.7z, which fixes this and removes anything after the main rom name.

Also note that this version no longer needs any extra .dll files besides the cygwin1.dll, it's now statically compiled with the others in the switchres.exe (should slightly improve run time speed in theory too, very small though probably in microseconds increase).

Thanks for the bug report and glad it's working good for you so far.

Thanks for the quick fix. I'll be giving it a try at my earliest convenience.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #516 on: December 30, 2010, 12:48:26 pm »
The 2 option for vcalc is really just hardcoded like lrmc did it, 0 is doing it the way you did instead so it's more dynamic but most likely always the same.  If you use 3, well then it won't actually change the width at all, I'm not sure but that might somewhat help the vertical monitor case?  I figure there's more checks involved, had thought about getting that eventually figured out.

If you use the -v option 2-3 times (-v -v -v) or more, it should show the exact mame command line it's using.  

Sounds like the issue your seeing on the 4350 has something to do with this...
https://bugs.freedesktop.org/show_bug.cgi?id=28410
Alex sent that to me, and said he hasn't had time to look closer but needs to find where it's most likely getting outputs confused listening to the vblank interrupts on the wrong output and so never gets them in your case where the monitor isn't detected.

Also I have proven the CPU usage speed up is in the DRM code, put the newest DRM into the stable kernel and it runs the same with the extra CPU, so I mentioned that to Alex to see what he says.  Would be nice to figure out how to do the multithreading in mame better, if possible, so it still could do vsync waiting and  use multi threading.  I looked at that code some, will probably take awhile for me to figure out how it exactly works, seems confusing.  It'll be interesting to see if this really is just overhead for how exact it seems to be working now, definitely hitting it at 100% exactly or if anything 100.1% but it's quite small compared to the .13 or close to 3% in the stable vs. the other kernels before the newest -next version.

I'll try adding -v but I was already using 3 of them for sure, and remember to have seen those Mame params in earlier versions, that's why I thought you had removed it.

I'll have a look at the vertical options. The rotating monitor option should have two special cases, one is when you rotate the monitor but not the desktop, then you have to use the resolution values as if it was a horizontal game (not swapping them) but add the -ror 1 param to instruct Mame to render the frame portrait oriented. Second case is for people who rotate the monitor and the desktop at the same time, so you have to keep the original h/w values as before but now you don't have to pass the -ror 1 param as Mame already takes the portrait orientation from the desktop when it's run.

If we want to respect the user's preference for vertical games both for the normal or virtualized case, we need to explicitly pass Mame the aspect ratio we want for the virtualized case. For the -vcalc 0 case, it would be -aspect 3:4 (it's the default, so it's not necessary; with SDL keepaspect has the same effect). But for 'wider' ratios then you need to pass, i.e. -aspect 3:3 (square), etc.

That OpenGL bug definitely has something to do with what I'm seeing, and seems to be out there for some months already. Hopefully someone can figure out how to solve it.

I've done some multithreading programming in the past, but only targeted on a single processor. This is just a thought, haven't seen the code at all, but the problem I see with multithreading on multiple processors in an emulator like Mame, is that you really don't want to have two frames rendered in paralell or something like that. What is important when doing vsync, is to be able to render the frame as quick as you can because to have to do it all between two vblanks, if you want to keep your input synced with the action. However, in the real hardware there are chips and processors actually working in paralell, i.e the audio chips, so performance could be improved having different hardware parts being emulated by different processors while mantaining the 1 frame at a time way. I don't know what the actual approach they are using in Mame.

Good news that we only have a dll there now! It was damned fast already before that, but dependencies are always ugly.
« Last Edit: December 30, 2010, 12:51:30 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #517 on: December 30, 2010, 02:03:22 pm »
I had a moment to play with it while at lunch and it initially did not launch properly from Hyperspin. I'll have to look more closely at my configuration to see what's going wrong. I'm thinking that there must be some other mame INI being read also when launched from the front end, as it also did not throttle the game.


I attempted to run Crystal Castles (ccastles.zip) from the command line and it threw a Direct Draw error. I didn't have time to catch the resolution it was attempting to run it at; but maws has it listed at 319x255. I'll look into that later.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #518 on: December 30, 2010, 04:04:52 pm »
I finally could test the 1.127 iso, I can see there's just an audio card available in the setup menu (VIA audio), I select that one, but I don't have sound yet in Mame. I've run alsaconf, and the gnome alsa mixer, and it's interesting that I can only see the capture tab of this card:



There's still an ATI tab but it's empty.

I've attached the logs. Mame log is saying there's no audio device available.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 896
  • Last login:August 02, 2019, 11:07:16 am
    • The Groovy Organization
Re: Switchres arcade monitor modeline generator and mame wrapper
« Reply #519 on: December 30, 2010, 05:06:02 pm »
I finally could test the 1.127 iso, I can see there's just an audio card available in the setup menu (VIA audio), I select that one, but I don't have sound yet in Mame. I've run alsaconf, and the gnome alsa mixer, and it's interesting that I can only see the capture tab of this card:
...

There's still an ATI tab but it's empty.

I've attached the logs. Mame log is saying there's no audio device available.

Seems others have an issue with that card, looks like either it interacts badly with the ATI HDMI audio and/or just has issues with Alsa drivers.

I have some drivers I'm looking at from the manufacturer Realtek that seem interesting, possibly could be better to use them.  Also of course OSS4 might do better too, although I need to figure out how to run it right on the liveCD since it tries some odd things writing to /usr/lib/oss/etc/ which we can't on the liveCD (I think I fixed it but haven't tested, then also I have to blacklist all alsa modules to enable it correctly, probably will only be able to boot either OSS or Alsa I think, so not able to switch back and forth).

Here's something to try on the 4350 to get some good debug information, best to do this command, run glxgears, then use 0x00 to turn off debugging.  That way while glxgears is stuck you will get only the log information up to the issue...

echo 0xffff > /sys/module/drm/parameters/debug

<run glxgears here>

echo 0      > /sys/module/drm/parameters/debug


It should produce a ton of messages, so don't run it for too long or the logs will be very large :)



Good news though, besides the increased CPU usage with the newest DRM code, it does run at exactly 100% or 99.9% at worst case.  So seems like the exactness is there with the refresh rate and running mame, and it plays very nice and smooth. It seems to me like this possibly could be the side effect of page flipping perfectly, but waiting for Alex to confirm that since still seems odd to close to double CPU usage from that (even glxgears does so it's outside of mame).
SwitchRes / GroovyMame - http://arcade.groovy.org
Modeline Generator and Mame Wrapper for Windows or Linux
LiveCD of Groovy Arcade Linux for Arcade Monitors
GroovyMame - generate arcade resolutions like advancemame
--
The Groovy Organization