Recent Posts

Well, again, you use CRU here which modifies and adds things to EDID. But still, even if you did, if you use RatRefresh -usecustomedid after using CRU, it will do the same as 0.11, namely only change byte 54 and 55 of the 0 value in the EDID_OVERRIDE key, and value 127 (the last one). 54 and 55 is the pixelclock in 10kHz units (reversed, because why take the easy road). Byte 127 is checksum, which must match else the value is ignored completely.

I don't have the luxury of a HDMI2 screen. I'm interested though in an export of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor instance> for that, to see if there's actually something different. For your info, if you completely reset things (remove from device manager, reboot) you can open the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor id>\Device Parameters key, there is an EDID value. If you open that, the next to last byte (ie. 126, start counting from 0) contains either 0 or 1 - 0 is no extension blocks, 1 is use extension blocks. When you use CRU to create custom resolutions, and there is an extension block active (even default counts), in the EDID_OVERRIDE key it'll create the 0 value (which is the regular EDID value) with bit 126 set to 1. And if that's 1, there will also be a registry value 1, which contains the extension blocks. When it's set to default, so far I've seen it then has value 02 03 00 00 00 00 ....... 00 and then the checksum.

So, if using extension block on a custom resolution, in EDID_OVERRIDE you'll have values 0 and 1. But I don't know where the extensionblocks would be stored when you DON'T use a custom resolution, i.e. your monitors own EDID in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor instance>\Device Parameters is still only 128bytes in total, and I've not seen another value in there. As far as others with the same question I've found, Windows only stores the first EDID block and not the extension blocks. If we need them for some monitors to work, I'll need to find a way to get them from the monitor. CRU can do it (or does it just make some extension block up?), and I have CRU's sources, so I might be able to figure that out, although it'll not be easy.

I tested just removing the detailed resolutions for the original extension block, and this seems to work. For some reason, later versions after .11 replace the original extension block with a 'Default extension block'. This seems to work to prevent issues with the monitor, but for some reason it won't let you see any other resolutions set.

Maybe I'm misunderstanding you, but isn't that exactly what we want? When I start a MAME game from my frontend, which has a certain rereshrate, it runs RatRefresh, and after disable / enable the display driver I am in that refresh rate. Without the need of manually switching to it. That's exactly the intention of the tool, to automate so your game runs at the exact speed it was intended for. It's NOT meant to add multiple resolutions with different refreshrates in order for them so show up in Windows. The deal (or at least my deal ) is to have only ONE resolution in there, so Windows HAS to use that. If you want to setup different ones, then CRU is your buddy, as that's much more versatile for that. Basically, sorry for repeating, RatRefresh changes the pixelclock (ie. byte 54 and 55) and the checksum, and stores that in the EDID_OVERRIDE value. All other options are for trying to get it to work in more configurations. But we should have the same expectation in mind else you might say 'doesn't work' but maybe it actually does

It seems the 'Default' can't be customized and there is also no way to go back to the original block, unless CRU is used to reset it. If it's possible to keep the original instead of the 'Default extension block' this might help with some of the issues from before.

The thing is the Extension block is not in registry. When you run CRU and save a resolution, it creates the EDID_OVERRIDE key and in your case has value 0 and 1, 0 beging the regular EDID block (with customized resolutions if any), and 1 with the extension block. If you remove the complete EDID_OVERRIDE key (ie, RatRefresh -remove would do that) it reverts to the original EDID, which is NEVER changed from RatRefresh. However, I have seen CRU change that, as per some procmon screenshots some posts above here. So that means, if CRU leaves the original EDID alone, removing the EDID_OVERRIDE key should reset everything back to normal.


So what I'm interested in, is a 'clean' registry export of your new monitor, after remove / reboot of everything. If possible the whole registry tree. There should be an EDID value in there. Then, use CRU and edit the default resolution, preferably only the refreshrate. Save that, and there should be a EDID_OVERRIDE key now, with values 0 and 1 (and who knows even more). I'm curious if that 1 value actually holds some data, or if it's just the default 'empty' one I've seen before. Please do an export of the whole monitor registry again, so I can also see if CRU modified your original EDID value.

[edit]
Looking through the CRU sources, I see it uses specific API calls for AMD and NVidia CPU's, but nothing for Intel. I have an old Zotac mini-pc, which has an AMD cpu. And sure enough when I connect the very same Dell monitors on it as I have on my home pc, it shows the CTA-861 extension block with some additional resolutions. Whereas my Intel NUC (with Intel GPU of course) just shows a 'default extension block'.
So I now have another system to test with. If it's really needed I'm sure I can implement the API calls, but I'd absoltely prefer not to do so if it's not needed for the goal of RatRefresh. So what I'll try is fiddle around with extension blocks without resolutions in it, so that way I expect Windows would just use the one resolution / refresh rate that's left.

No registry exports needed anymore for now, as I can do them myself which is obviously quicker. Still interested in answers to my other question - do we expect the same from RatRefresh? Stay tuned :-)

You can't trust the date shown on the NMK games, we've seen multiple cases of completely different builds with the same date, and even different games with the same date.  Either they forgot to update it, or it has some other meaning like the engine date, or project start date, rather than the build date.

Likewise NMK don't seem to do anything to differentiate versions with labels.

The only real way to know is the dump them.

If Yotsuya is willing to dump some ROMs from his PCB, which ROMs are most likely to show if there is a different variant?
- a03 looks promising. (main CPU)
- a08, a09, and a10 might have something relevant. (proms)
- a01, a02, a04, a05, a06 and a07 don't look very promising for the difference noted.  (audio CPU, oki sound chips, tiles, and sprites)

921a03              0524288    maincpu
921a02              0065536    audiocpu
921a01              0131072    fgtile
921a04              2097152    bgtile
921a07              2097152    sprites
921a05              0524288    oki1
921a06              0524288    oki2
921a08              0000256    proms
921a09              0000256    proms
921a10              0000032    proms

Scott

While I can't answer all your question - When I took apart and cleaned my trackball, I added a little 3 in 1 household oil and it seemed to help.

Hi grey,

Thanks for the interest in my project.

At least in my MAME you can hit TAB and see the Windows cursor. You will see that the Windows cursor and MAME crosshair won't match.

Let me polish up a little bit my code and I can send you the source. I did in Python using the https://github.com/TriadSemi/triad_openvr.  But ideally, I should move to another library (libsurvive or OpenXR).

To control the mouse I'm using Arduino but I was also able to use unsigned drivers as well. This one: https://github.com/hedgar2017/loki-hidriver with modifications.

Regards,

Someday I want to add a trackball to my cab but don't think there is enough room inside the CP for a standard one, not even a 2.25".
I was thinking of designing and 3D printing my own trackball setup to fit the available space.  I have an Opti-Wiz and some high end optical encoders in the parts bin.  Have a cue ball for testing, but would buy a red bumper pool ball if things work out.
The issue is that the optical encoders use a 6mm shaft which I also have on hand.

I was ready to order some 6mm ID bearings to play around with and test the encoders, but then started to wonder if they are going to spin freely enough for the smooth ball to turn them.

Do trackball bearings have lighter grease or is anything else different to give them less resistance than a regular generic bearing?

it really is just a standard microswitch.

https://datasheet.octopart.com/AM51610A59-A-Panasonic-datasheet-41394079.pdf

if you are really concerned about button press forces, the other suggested part out there is a AM51661C5.. and it has an actuation force of 3.92 newtons. just find another microswitch from another brand that has the same actuation force and bob's your auntie.

Thanks for supporting The House of the Dead 4 Special boss 

I just wanted to add an update on the extension block issue that I noticed yesterday. I recently got a new 1440p 144hz monitor and ran into issues with it when using the new delete extension block parameter on my new monitor. On my older monitor, I don't think I needed to have the extension blocks present but it seems to be needed for HDMI 2.0 monitor functionality(higher refresh rate, HDR, etc.) I haven't had a chance to test your new release but just wanted to update you after realizing this. I noticed version .11 doesn't reset to a 'Default extension block', but keeps the original extension block. I think this is why it worked for .11 but is giving issues in later versions. I don't know if it's a CRU bug, but it won't display any other refresh rate to select in the display settings, if a new 'Default extension block' is set or overwrites the original extension block. It seems like one of the original resolutions/refresh rate values is being overwritten from the EDID in one of these original blocks, which might be why the default block is just a standard copy of the original but isn't modifiable. If the original extension block remains, there shouldn't be any issue. I tested just removing the detailed resolutions for the original extension block, and this seems to work. For some reason, later versions after .11 replace the original extension block with a 'Default extension block'. This seems to work to prevent issues with the monitor, but for some reason it won't let you see any other resolutions set. If you keep the original block there, with the data blocks present, but just delete the detailed resolutions, it seems to still keep the new refresh rate set. I haven't had a chance to test your new release, but if this hasn't been made, would it be possible to prevent RatRefresh from replacing the original extension block with a 'Default extension block' each time -refresh is run? Also, it might be a good idea to have a parameter or command added to delete all of the original extension blocks's detailed resolutions, but keep the extension block's data blocks. Maybe this or another parameter could globally delete all the refresh rates in CRU other than the new refresh rate set by RatRefresh, so only the new resolution set is selectable from the display settings. I'm not sure if there is a way to preserve the original extension block after it's deleted, but if it could, it might be useful to add some individual commands to delete all of the present refresh rates and resolutions, and maybe another command to restore them to the original value if possible. This might be useful in case people who don't have CRU want to reset to the original extension block and original settings before RatRefresh was used. It might be easy to just incorporate or call CRU's reset-all.exe file to reset to the original values. This probably won't work if CRU isn't installed though, but maybe similar functionality could be added that does something similar. The 'Default extension block' set seems to be useless for setting new refresh rates, since you can't seem to select any new refresh rates set from the display settings. Here are some screenshots of the original and default extension blocks, on both my old and new monitor.





After using -refresh with .11, the original extension block still remains.



Every time -refresh is run on later versions, it seems to delete the contents in extension blocks and overwrites with a 'Default extension block'. On my new monitor, it won't work without this Default extension block or the original extension block present, which makes sense, since they seem to be the same thing, but the Default extension block seems to have some issues. It seems the 'Default' can't be customized and there is also no way to go back to the original block, unless CRU is used to reset it. If it's possible to keep the original instead of the 'Default extension block' this might help with some of the issues from before.

 

Version 0.15b7

Guys, I did some more research on those Extension blocks. They might give some unexpected issues indeed. I still have two systems on which I occasionally have issues. One is my work NUC (intel) and one is a AMD system with three screens attached. Still working on what's wrong there.
Anyway, I added some fields that are reported with the monitor properties, like it tries to detect the connection used, might be handy to identify the correct display if multiple are used. But also, I now use the 'correct' way to make it use no extension blocks. Rather than what CRU actually does, which is create an empty extension block, there is a bit that can be set in the main EDID value, to disable extension blocks.

So, again, for those who have issues, try the link above. And for those that still have issues, please use device manager to remove BOTH all your monitors and all your display adapaters, and reboot , and DON'T use 'Scan for hardware changes' to redetect the hardware. After that run RatRefresh -setup, and then use RatRefresh -Refresh <something> -removeextensionblock
If your screen has extensionblocks, and you don't use -usecustomedid, you will have to use -removeextensionblock every time, as then the original EDID value has the 'use extension block' set to 1. Please don't use CRU before testing as that seems to mess up things.

And if it doens't work, please export the whole HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor ID> tree including subtrees, so I can see if it makes any sense. If feel it's giving less issues when I disable the use of extensionblocks period, so if that turns out to work better, I'll probably make that default.

[edit]
Meanwhile I've been browsing through the CRU source, and while that's written in Borland C++ or something, it's less difficult for me to read than I thought. The extended EDID seems to be read through API calls, which is only implemented for NVidia GPU's through nvapi.dll, and on AMD GPU's through atiadlxx.dll or atiadlxy.dll" if the first is not available. Intel is not implemented in CRU. I have a very old Zotac mini-pc, which has a AMD videocard of some sort. And sure enough, when I plugin the same Dell screen I have on my normal home-pc, it shows CTA-861 as extension, just as on your screenshot, whereas when I use the same screen on my Intel NUC (with Intel GPU of course) it just shows a 'default extension block'. So I now have another system I can test things on.
While I'm sure I'm able to impelement AMD / NVidia API calls, that would take time. And id it's needed I'll do it. But if it turns out RatRefresh's goal can be achieved without it, at this point I don't think I'll invest the time. We'll see :-)

any lower it will have to be moved to the Free Items - Official Thread