switchres support for "VIDEOAMP" (CRT EDID alternative to ATI card & emudriver)

[flybynight]

Bandicoot and njz3 from the French gameoover forums have made this great little device called VIDEOAMP.

It sits between your CRT and graphics card. Any graphics card on any PC. Even a laptop. No test mode or ATI card or emudriver required.

It's compatible with the the custom modeline text file that's generated from vmmaker. The file imports into the VIDEOAMP software and flashes the EDID data.


The problem is, switchres in groovymame always picks the 2560x240 60hz value. There are 15 modelines generated and imported, I see them all listed in the windows settings display resolution drop down but swithcres always picks the same one.  I tried using the old "static" mode with the "Max number of modes" uncapped but I get the same 15x modelines regardless if I choose "dynamic" or "static" (with the mame exe and XML options" selected).

1. Could switchres be configured to dynamically set custom EDID to the VIDEOAMP like it does with emudriver and ATI cards?

2. Is there a bug in vmmaker that the old "static" mode table method no longer works?



With a few tweaks I think this VIDEOAMP device could be a really amazing solution to future proof the CRT, switchres and groovymame ecosystem since it doesn't rely on using a dedicated PC in test mode with older ATI card / older drivers. You plug in the USB/video cable to the VIDEOAMP, connect it up to the CRT as the second screen, add "screen \\.\DISPLAY2" to the mame.ini then run groovymame on your main PC still with your HDMI 4K monitor attached.
I know some people are using groovymister for this same purpose but this is a lot cheaper.

More info if you are interested:
French: https://www.gamoover.net/Forums/index.php?topic=44224.0
English: https://www.arcade-projects.com/threads/vga-video-amplifier-board-for-arcade-monitor-with-sync-filter.24936/

[njz3]

Yes I agree that would be nice to get a switchres support for the board.
The board's firmware uses a simple serial communication protocol to store an EDID: basically set the EDID size in 128bytes blocks (up to 30kbytes), then send a write command with a leading adress value in hexadecimal text and a chunk of 16 bytes encoded also in hexadecimal.
What could be tricky is to perform a re-read of the EDID without restarting the whole graphics stack.

[haynor666]

Never heard of this project. Looks really interesing. Would it work with 2 CRTs? Assuming that I need two VideoAmps.

Is there any site where I can buy this VideoAmp ? I see people are taking straight from bandicoot.

[flybynight]

I sent a PM to njz3 and bought one through paypal. This was a while ago so there may be a web shop now.

It's actually a great little device because I can use my main gaming PC for both CRT emulation and as the main PC gaming.

Before I needed a separate PC for emudriver/CRT because I couldn't do regular gaming on it (once the epicgames loader detected TEST mode in Windows it wouldn't load the PC games, not to mention the R9 380 card was getting a bit old).

[bandicoot]

yes you can contact me or NJZ3

[njz3]

I added more verbose traces for the communication when using the videoampcmd.exe command line tool.
If Calamity reads this topic, maybe he can find this information helpful to add the support for the videoamp into switchres/groovymame.

Here are some outputs of examples commands, all in text format.

Get status from the board at COM4 baudrate 500000:

Code: [Select]

$ ./VideoampCmd.exe -status -verbose
[USBSerial] Opened port COM4 at 500000
[USBSerial] SEND>>U
[USBSerial] RECV<<Mhsy=0 frq=0.00 dip=0 min=0.00 max=0.00 edi=0
[USBSerial] SEND>>F
[USBSerial] RECV<<Mfmi0=14500.00 fma0=16000.00 fen0=0 fmi1=23500.00 fma1=25500.00 fen1=0 fmi2=29000.00 fma2=31500.00 fen2=0 fmi3=0.00 fma3=80000.00 fen3=0
[USBSerial] SEND>>$get edidmode
[USBSerial] RECV<<Medidmode=801
[USBSerial] SEND>>$get edidpid
[USBSerial] RECV<<Medidpid=5
[USBSerial] SEND>>$get edidseg
[USBSerial] RECV<<Medidseg=1
Status:
        Firmware ver.=  0.3.2.24
        Board type=     0x0
        Serial number=  0x0
        Sync active=    0
        Current Freq=   0.00
        DIP switches=   0000
        Min Frequency=  0.00
        Max Frequency=  0.00
        EDID Bus Read=  0
        EDID VideoMode= 0x0801
        EDID ProductID= 0x0005
        EDID Segments=  1
[USBSerial] Closing port COM4
Now more explanations on the text commands we can see:
- the board wait for a first character that is either a command by itself, or a "long" command starting with a special "$" character.
- the board replies with messages starting by letter "M" (for Message)
- "U" command returns : hsync (hsy) enable (1) or not (0), current measured hsync frequency (frq), Dip switch position (dip), current filter range (min)/(max), number of reads of the EDID performed by the computer (edi)
- "F" command returns the 4 filter banks parameters: min (fmi0), max (fma0), always enabled (fen0)
- "$get edidmode" long command to get EDID mode of the board (reserved for internal use).
- "$get edidpid" long command to get EDID product ID (reserved for internal use).
- "$get edidset" long command to get EDID buffer size expressed in 128-bytes segments.

Set a 128 bytes EDID from a file "generic_15.bin" (obtained from switchres) into the board's eprom, still at COM4 baudrate 500000:

Code: [Select]

$ ./VideoampCmd.exe -edid generic_15.bin -verbose
[USBSerial] Opened port COM4 at 500000
Set EDID mode to external
[USBSerial] SEND>>$set edidmode=0801
[USBSerial] RECV<<MSet uint16 edidmode to 0x801
EDID to write:
0x0000: 00 FF FF FF FF FF FF 00 4E F2 00 00 00 00 00 00
0x0010: 05 1F 01 03 6D 30 24 78 0A 5E C0 A4 59 4A 98 25
0x0020: 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
0x0030: 01 01 01 01 01 01 8B 02 40 60 10 F0 15 00 0D 1F
0x0040: 23 00 E5 6C 11 00 00 18 00 00 00 FF 00 53 77 69
0x0050: 74 63 68 72 65 73 32 30 30 0A 00 00 00 FD 00 31
0x0060: 41 0F 0F FF 00 0A 20 20 20 20 20 20 00 00 00 FC
0x0070: 00 67 65 6E 65 72 69 63 5F 31 35 00 00 0A 00 05
Number of 128-bytes segments: 1
[USBSerial] SEND>>$set edidseg=0001
[USBSerial] RECV<<MSet uint8 edidseg to 0x1
[USBSerial] SEND>>$setedid 0000 00 FF FF FF FF FF FF 00 4E F2 00 00 00 00 00 00
[USBSerial] RECV<<MEDID set at 0x0000: 00 FF FF FF FF FF FF 00 4E F2 00 00 00 00 00 00
[USBSerial] SEND>>$setedid 0010 05 1F 01 03 6D 30 24 78 0A 5E C0 A4 59 4A 98 25
[USBSerial] RECV<<MEDID set at 0x0010: 05 1F 01 03 6D 30 24 78 0A 5E C0 A4 59 4A 98 25
[USBSerial] SEND>>$setedid 0020 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[USBSerial] RECV<<MEDID set at 0x0020: 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[USBSerial] SEND>>$setedid 0030 01 01 01 01 01 01 8B 02 40 60 10 F0 15 00 0D 1F
[USBSerial] RECV<<MEDID set at 0x0030: 01 01 01 01 01 01 8B 02 40 60 10 F0 15 00 0D 1F
[USBSerial] SEND>>$setedid 0040 23 00 E5 6C 11 00 00 18 00 00 00 FF 00 53 77 69
[USBSerial] RECV<<MEDID set at 0x0040: 23 00 E5 6C 11 00 00 18 00 00 00 FF 00 53 77 69
[USBSerial] SEND>>$setedid 0050 74 63 68 72 65 73 32 30 30 0A 00 00 00 FD 00 31
[USBSerial] RECV<<MEDID set at 0x0050: 74 63 68 72 65 73 32 30 30 0A 00 00 00 FD 00 31
[USBSerial] SEND>>$setedid 0060 41 0F 0F FF 00 0A 20 20 20 20 20 20 00 00 00 FC
[USBSerial] RECV<<MEDID set at 0x0060: 41 0F 0F FF 00 0A 20 20 20 20 20 20 00 00 00 FC
[USBSerial] SEND>>$setedid 0070 00 67 65 6E 65 72 69 63 5F 31 35 00 00 0A 00 05
[USBSerial] RECV<<MEDID set at 0x0070: 00 67 65 6E 65 72 69 63 5F 31 35 00 00 0A 00 05
[USBSerial] SEND>>$savecfg
[USBSerial] Closing port COM4
Here are the explanations:
- the protocol always expects unsigned hex digits (2/4/8 depending on the integer) or float32 values.
- to set a value, a long command using "$" is needed.
- to set the EDID data, many chunks of 16 bytes in hex is used.
- "$set edidmode=0801" long command set the edidmode value to hex 0801 (external binary EDID).
- "$set edidseg=0001" long command set the number of 128bytes segments for the EDID to hex 0001 (1 segment of 128 bytes).
- "$setedid 0000 00 FF FF FF FF FF FF 00 4E F2 00 00 00 00 00 00" long command set 16 bytes of the EDID binary buffer at offset 0x0000 to the bytes 00 FF FF FF FF FF FF 00 4E F2 00 00 00 00 00 00.
- "$savecfg" save the current edid configuration (mode and segment number) to internal eprom.

[Substring]

I can't understand the need of setting on the fly an EDID for modeswitching. That is almost absurd : you need to trigger a read of the EDID at OS level. This is slow, has got a massive impact on the OS. So why ?

[flybynight]

Is it not needed for the random dynamic resolutions in mame.ini:
monitor custom
Otherwise it's stuck with the 10x or so pre-set hard coded resolutions?

[haynor666]

yes you can contact me or NJZ3

I would interested but if this work on two CRT setup ?

[njz3]

You need one video output port per monitor on your computer video adapter, and 1xvideoamp per monitor.
What would be your use case?

[haynor666]

I have videocard with DVI-I output (via VGA to DVI modules) and VGA. I'm using one CRT for vertical games ans second for horizontal games but pictures are independent so CRT horizontal is DISPLAY1 and vertical is DISPLAY2 so I assume I need two videoamps.

But there is plan to use two videocards (more powerfull - needed for flycast and other "hungry" emulators), each with one DVI-I or VGA.

[njz3]

It should work given you have 2 analog outputs.
Each monitor will appear as a "standard" monitor for your OS.

[haynor666]

Ok, I think I order two. Shipping will be to Poland.

Now, some questions:

I understand that I still need groovymame, VMMaker and custom resolutions added. Only crt emudriver is skipped and test mode, right ?

[antoniomauro]

Where it can be bought?

[haynor666]

Directly here from NJZ3 or bandicoot

I'm also interested but before I buy I would like to know a bit more about setting and hardware req.

[njz3]

Ok, I think I order two. Shipping will be to Poland.

ok thanks. You may have contacted directly Bandicoot as I do not see any message from you.

Now, some questions:
I understand that I still need groovymame, VMMaker and custom resolutions added. Only crt emudriver is skipped and test mode, right ?

Yes, but depending on your expectations you might find it cumbersome to setup for now, or not giving you the "pixel perfect" you were looking for as only the resolutions you will store in the board will be available to GroovyMAME (or whatever else emulator you use). In this case you may have to stay with crt emudriver.

To explain maybe more in details what flybynight does with VMMaker and the VideoAmp:
- first you basically generate with VMMaker a list of say 20x or 30x modelines that covers 99% of what MAME needs, or your other emulators expect (super-resolution and rounding to multiples of 4 vertical lines and integer refresh rates will allow to reduce massively the number of needed modelines).
- then you import this list of modelines to the internal memory of the VideoAmp in what is called an EDID (a display identification data that makes your computer to generate the "right" video signals for your monitor). This is done with a few click using the companion software (sorry, Windows only..).
- next you either plug the VGA between your computer and your VideoAmp or perform a software restart of the graphics driver of your computer to force your operating system to automatically detect those resolutions/modelines.
- finally when you launch a game in GroovyMAME, it will try to find the closest resolution and frequency for your game and will dynamically switch the current videomode to the one that is the closest to the game's videomode. This is transparent and done by your operating system indenpendantly of your GPU brand, meaning you can use Intel or NVidia gpu as well as AMD.

You can see it has an evolved Soft15kHz dongle that would be easy to configure and that can store many detailled resolutions. Or a "hardware-based" equivalent to Custom Resolution Utility if you know the tool from ToastyX.

Worth to note that the first goal of the VideoAmp was to be an adapter board that takes VGA video signal as an input, and output a combined sync with amplified output video to ScartRGB or RGBS (arcade monitor), which is closer to a UMSA++.
The software that runs on the board perform hsync measurement and can disable the output in case the sync is out of range. This is mainly to protect your CRT chassis against too high frequency that would cause overheating and maybe broke your CRT electronics. The additional thing I added is the automatic detection by your PC graphics adapter and the advanced EDID emulation that the board can provide to help people quickly get a running 15kHz or 24kHz setup.

I do not want to do advertising, but we have a 1 sheet page to summarize what it does.

https://drive.google.com/file/d/1H0GvW21lrLlSddq1vHD5RBfbbFss4pTk/view?usp=drive_link

[haynor666]

I'm using super resolutions so I think resolutions like 2560x240 pixel perfect horizontally is not important (really hard to notice).

I was thinking about exact (or very close to) frequency. When I put custom resolutions like 2560x256 at 55 Hz in EDID but game needs for example 56 Hz will be possible to output in mame 56 Hz ? Right now groovymame can modify existing resolutions on the fly means edit 2560x256 at 55 Hz to 56 Hz (or very close) before starting game.

Meaning is the device will remove need of use custom crt emudriver and test mode but will it allow to work groovymame just like when I use Radeon card with it's emu driver and test mode?

If this EDID emulation does not allow groovymame to edit resolutions on the fly and it's a bit a downfall. From I can read here it does not work like I imagined.

Option would be put a lots of modelines with variety of frequncies but again a problem - frequncies could not be to close to each other, at least 1 Hz should differ. Putting lots of modes could slow down whole driver/ process of switching. Putting in EDID mode 2560x256@55 will not allow mode 2560x256@55,4 for example.


I think everything would work like years ago with Soft5Khz program when I had to calculate custom resolutions and then generate resolutions into driver so mame can only choose and nothing more meaing that game that is intended to work at 256x256@55,4 Hz will be force to use 256x256@55 Hz a it will be a bit slower.

[njz3]

On the fly generation of modelines for the VideoAmp is not supported with current switchres/groovymame. That's the subject of the current topic.

In your case where you want frequency perfect signal, I guess you should better keep crt emudriver.
The VideoAmp can still be useful as an UMSA++ replacement with out of range frequency filtering.

[haynor666]

Ok, I understand fully now. After all switchres is a part of groovymame.

[Zebidee]

On the fly generation of modelines for the VideoAmp is not supported with current switchres/groovymame. That's the subject of the current topic.

Am I understanding correctly that this is really just a software/firmware matter? So we can just download updates as they become available? Reprogram the VideoAmp via the Windows utility?

In any case, being able to plug-and-play with 10-20 programmable video modes is pretty awesome. As you say, a lot cheaper than a GroovyMister setup.

I'm looking forward to your next batch coming out, and PM'd you and Bandicoot to put my name on the list already. Please let me know when ready, I want to test with GreenAntz RGB to Component/YPbPr transcoders.

[abispac]

How much are this thing? i wouldlike to test them out as well.

[njz3]

Am I understanding correctly that this is really just a software/firmware matter? So we can just download updates as they become available? Reprogram the VideoAmp via the Windows utility?

I am not sure I can answer to this, as the work to be done for on-the-fly reload is mainly on the computer side and as said before, it may have a massive impact on the OS to reload the EDID even if it has only a few modelines.
On Windows 11, it takes a few seconds to reload an EDID with a few videomodes. I can't tell for Linux and MacOS.
On the other hand, once Windows has loaded the modelines, changing resolutions is rather quick.

In any case, being able to plug-and-play with 10-20 programmable video modes is pretty awesome. As you say, a lot cheaper than a GroovyMister setup.

It maybe cheaper and easier to use, but be more limited than crt emudriver or the groovymister (I can't tell since I do not own a groovymister).
Regarding the number of videomodes. The board can actually store a lot of modelines, but unfortunatly the OS and the GPU driver may not handle all of them.
On Windows 11 with an RTX2060 for example, I cannot get more than 50 modelines to be read (interlaced resolutions are not accepted).

Depending on your use case, this may be enough. Let's say you plan to play a PS2 emulator and preload an EDID with the needed videomodes for PS2 (maybe 20x including interlaced) that covers all games, then you may load this into the videoamp and perform an EDID reload just before loading the emulator. And if the emulator supports it, you could even dynamically switch between progressive and interlaced video modes in game, in a second.
Something tested in the first post is to prepare a list of 30-50 modelines to cover arcade 15kHz MAME games. Then you load this into the VideoAmp before starting GroovyMAME. Unfortunatly it seems like GroovyMAME/swtichres does not know how to switch dynamically between available monitor resolutions in Windows and pick only the currently used.

I'm looking forward to your next batch coming out, and PM'd you and Bandicoot to put my name on the list already. Please let me know when ready, I want to test with GreenAntz RGB to Component/YPbPr transcoders.

Confirm you are on the list for next batch.

Also, there is a very interesting pages that you can read:
https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlacing/
https://www.geocities.ws/podernixie/htpc/modes-en.html