USB-DVG Users support thread

I contacted Andy Warne at Ultimarc, he said another user has also reported that "something has changed with the Pi 5" and recommended this fix:

sudo -E rpi-eeprom-config --edit

In the resulting config file, add:

NET_INSTALL_ENABLED=0

... and reboot. I tried it this morning and it did not fix the issue (got an uncommanded exit after about 20 minutes), but the rationale behind it made sense to me: this is the Github description of that config command, turning off that option is related to USB detection of keyboard devices:

NET_INSTALL_ENABLED
When network install is enabled, the bootloader displays the network install screen on boot if it detects a keyboard.
To enable network install, add NET_INSTALL_ENABLED=1, or to disable network install add NET_INSTALL_ENABLED=0.
This setting is ignored and network install is disabled if DISABLE_HDMI=1 is set.
In order to detect the keyboard, network install must initialise the USB controller and enumerate devices. This increases boot time by approximately 1 second so it may be advantageous to disable network install in some embedded applications.
Default: 1 on Flagship models since Raspberry Pi 4B and Keyboard models; 0 on Compute Modules since CM4 (including CM4S).

... so maybe that's worth looking into, I passed it on to Mario.

Link to Pi documentation: https://github.com/.../raspberry-pi/eeprom-bootloader.adoc
 
I think I may have identified a work-around.

If I assign a mouse click to Cancel_UI in MAME, the uncommanded quits go away. I have an Opti-Pac installed in the cab, so I can easily wire my Menu button on the cab to a mouse click post there (assuming, of course, that the Opti-Pac doesn't have the same Pi 5 configuration issue as the I-Pac--we'll have to see, but when I did a test with the mouse click assigned in MAME and the Opti-Pac and I-Pac connected in the USB chain, no issues).

Problem is, as far as I can tell there's no way to tell VMMENU to take a mouse click as the k_exit command. I sent Chad an email asking if he thought it could be done, we'll see what he says, but I guess I could wire both a key post on the I-Pac and a mouse click post on the Opti-Pac to the same button. That *should* open up functionality in both applications, and if the I-Pac does continue to throw spurious Cancel_UI keystrokes (I've never noticed any odd behavior in actual gameplay, just in the uncommanded quits), MAME ought to ignore them.

Haven't wired any of that up yet, going to try a few other ideas first, but I *think* that would work.
 
Last edited:
Well.

I decided to try and see if this problem was isolated to advmame, so I started up a Vectrex game that wouldn't burn in (All Good Things) and let it run. Ran for an hour on the Pi 5, no problem. "Aha! I said. It is an advmame thing! Doesn't happen on advmess!"

So just as a proof of concept, I started up Major Havoc and let it run, expecting a crash in 10-15 minutes.

It ran for an hour.

I have no idea now exactly what's going on here. Did I stumble into the right combination of connections and settings, or just hit a lucky streak? Hellifino, but I do know the First Law of KLOV: "If it works... leave it alone!"
 
Well.

I decided to try and see if this problem was isolated to advmame, so I started up a Vectrex game that wouldn't burn in (All Good Things) and let it run. Ran for an hour on the Pi 5, no problem. "Aha! I said. It is an advmame thing! Doesn't happen on advmess!"

So just as a proof of concept, I started up Major Havoc and let it run, expecting a crash in 10-15 minutes.

It ran for an hour.

I have no idea now exactly what's going on here. Did I stumble into the right combination of connections and settings, or just hit a lucky streak? Hellifino, but I do know the First Law of KLOV: "If it works... leave it alone!"

... aaaand after further review, it doesn't actually work.

I've had enough of chasing my tail on this, I'm going to try a different keyboard interface.
 
I think I may have identified a work-around.

If I assign a mouse click to Cancel_UI in MAME, the uncommanded quits go away. I have an Opti-Pac installed in the cab, so I can easily wire my Menu button on the cab to a mouse click post there (assuming, of course, that the Opti-Pac doesn't have the same Pi 5 configuration issue as the I-Pac--we'll have to see, but when I did a test with the mouse click assigned in MAME and the Opti-Pac and I-Pac connected in the USB chain, no issues).

Problem is, as far as I can tell there's no way to tell VMMENU to take a mouse click as the k_exit command. I sent Chad an email asking if he thought it could be done, we'll see what he says, but I guess I could wire both a key post on the I-Pac and a mouse click post on the Opti-Pac to the same button. That *should* open up functionality in both applications, and if the I-Pac does continue to throw spurious Cancel_UI keystrokes (I've never noticed any odd behavior in actual gameplay, just in the uncommanded quits), MAME ought to ignore them.

Haven't wired any of that up yet, going to try a few other ideas first, but I *think* that would work.

After a LOT of back and forth and trying out other options, I went with this work-around, and it appears to fix the MAME uncommanded quit problem. I finally realized that exiting from the VMMENU is something that only I am going to want to do (and in fact I wouldn't want a casual player to keep mashing a button and wind up exiting to a CLI that isn't even visible on the vector screen), so I just moved that command in vmmenu.cfg to one of the player 2 buttons.

So far so good.
 
After a LOT of back and forth and trying out other options, I went with this work-around, and it appears to fix the MAME uncommanded quit problem. I finally realized that exiting from the VMMENU is something that only I am going to want to do (and in fact I wouldn't want a casual player to keep mashing a button and wind up exiting to a CLI that isn't even visible on the vector screen), so I just moved that command in vmmenu.cfg to one of the player 2 buttons.

So far so good.

Just a thought: if anybody else is running into this issue, you don't really need an Opti-Pac to execute this work-around: the circuit board from any generic USB mouse should be fine. Just run a couple of wires to the terminals of any of its buttons to your 'game exit' button on the build, and plug the USB end of the mouse's cord into your Pi's chain.
 
A bit of follow-up (this is a cross-reference to my build tread post for a drop-in trackball for Quantum that I added to my multi-vector cab): It turns out that the more USB mouse devices you have connected, the more the Pi and/or AdvMAME get confused. I also found out that it's best to have all your USB devices connected to the same hub, and then plugging that hub into the Pi.

After a lot of thrashing (among other problems, Quantum would crash on launch with the trackball connected, and it was a real crash, not a control glitch), I wound up removing the Opti-Pac and replacing the Atari optical board on the spinner with one of @ArcadeJason's modified units (available here: https://mikesarcade.com/cgi-bin/store.pl?sku=ADOPTO ) and connecting that board to the spinner posts on the I-Pac2. For my mouse click game exit hack (see above), I just took apart an old mouse, removed one of the buttons, and wired that up to my Menu volcano button. With that configuration, everything is now working nicely (knock wood).
 
This might be interesting and/or useful: current users, please post a pic of your USB-DVG settings page.

Here's mine... this shouldn't be considered definitive or anything like it, these settings are probably going to vary with different chassis and tubes and tastes, but after a lot of tweaking, this works well for my setup. Took a while to weed out most of the flicker in the really vector-taxing games (TESB and Cosmic Chasm in particular):

IMG_4502.jpg
 
Making these changes to /home/pi/.advance/advmess.rc significantly improves Vectrex boot and gameplay speeds. Would still like to get the boot screen going a little faster, but this is much better than the defaults:

display_framskip {auto} 0.65
sound_samplerate {22050} 11025

Characters in {these brackets} are the defaults.
 
HEADS UP TO ALL USB-DVG USERS:

Mario has been working on an update to the USB-DVG firmware; I've been beta-testing it for the last couple of weeks. It's not 100% yet, but it's a major improvement for complex color games like Star Wars, TESB and Cosmic Chasm.

From Mario:

New USB-DVG Firmware v1.14B5 Released

Both the normal and arcade control editions are now available.
Highlights of this update:
✅ Optimized rendering pipeline
✅ Increased CPU frequency for faster vector drawing
✅ Finer rendering in games with low vector count
✅ Simpler DVG settings page — fewer options, easier to use

If you're using USB-DVG, give this version a try and let me know if you run into any new issues or bugs. You may have to tweak the settings.

Standard version:
https://drive.google.com/.../1YQfmAvWarThY0OpeyI9.../view...
Arcade Control version: [this is for use if you have one of the prebuilt adapters for specific games; Space Duel, Tempest, Asteroids, etc.]
https://drive.google.com/.../1yEdhD0VkznL5hhbUGMu.../view...

--------------------------------------------------------------

Any and all feedback is welcome, I'll be happy to FW on to Mario.
 
I've been VERY out of the loop for a bit but this is welcome news!
Great work as always keeping at this stuff Will.
I'll look forward to trying it as soon as I can get past a few other "have to" things at the homestead.
 
I finally had a chance to test the latest Beta (1.14B7), and IYAM it's the best version yet. Vastly-improved picture and gameplay in the complex color vector games (SW, TESB, Cosmic Chasm, Major Havoc). Only quibble is that the USB-DVG splash screen (now animated, which is cool) goes away after a few minutes for me, I have a black screen when leaving a game for VMMENU or starting another game. Anybody else seeing that?

Not a big deal as far as I'm concerned, but worth noting...
 
Almost cleared the workshop out enough to have another go at this!

I also see that Mario has made it up to v1.14B7 at this point too.
Time to get my butt in gear.

Wasn't sure what you were referring to when you said the AC hex was for prebuilt adapters...?
As in an Ultimarc, GGG, or likewise interface board?

How's your Vectorama doin?
I'm excited to get back as my machines here.
 
Arcade Control version: [this is for use if you have one of the prebuilt adapters for specific games; Space Duel, Tempest, Asteroids, etc.]
Can you elaborate on this? Did I miss reference to these earlier in the thread? Please direct me to the post or link that contains info on these "prebuilt adapters for specific games"

Thank you!
Dylan
 
Can you elaborate on this? Did I miss reference to these earlier in the thread? Please direct me to the post or link that contains info on these "prebuilt adapters for specific games"

Thank you!
Dylan
A few years back, Barry Shilmover sold some adapter boards that let you drop a USB-DVG into particular cabs and use their unmodified wiring harnesses. If you don't already own one of those, you should use the standard version of the firmware.

 
Appreciate that clarity Will.
Barry is still off the map though, hunh?
Stoked Mario has still been at it at least.

Loading a new Pi5 image right now (and about to learn if I need to go through my notes and still make all the previously necessary line changes to make controllers behave!)
 
New USBDVG owner with a dumb question, does anybody have a manual that shows the video and interface_bus connectors pinout? I just bought it and want to make sure it works.
Thanks,
John
 
Back
Top Bottom