Thanks! This gets stranger.
Originally I was using a MicroSD Adapter to read the card on a built-in SD card reader in an HP Elitebook 2540P I5 laptop running Windows 10. Today, I used a different micro SD card reader (a USB version this time "T-flash USB") - didn't even know I had one, but found it by chance when I was going through my USB drives in order to install gpartLIVE as bootable drive) on the same laptop. When I looked at the micro SD card using this USB reader, disk manager showed the 256MB partition, another space of several gigs, and a large unallocated space (albeit TOO large). I wiped out the partitions (using Diskpart I believe). Then I saw a capacity of 2TB of unallocated space (on a 128GB card!!!). I got gpart to run on my other Retropie SD Card (never actually needed the USB drive) and using the same USB reader, it too reported 2TB for total capacity. Other Linux utilites reported the same capacity. I tried a different SD card in this USB reader and that reader always shows SIZE 2TB, but it does show the correct partition sizes. Now I had the opposite issue - too much space reported. Various partitioning and formating utilities choked b/c I think they were trying to read/write beyond the actual capacity of the drive. On a whim, I put the card back in the original Micro SD card adapter and disk manager showed 116GB unallocated. I created a simple volume and it worked. I imaged the card and the Pi booted. Almost 24 hours later and I'm almost back to where I started. I thought these adapters were just devices which passed the connection through pin for pin with no 'smarts' in-between. Maybe the built-in card reader had an issue? Dunno. In any case, thanks for all of your help.
I’m not angry at anyone here. But this does further solidify my anger with the vendor. I see now that this is a topic discussed often here.
I find it interesting that the company is willing to sell “kits” with pre-loaded RetroPie but their contact number explicitly states that they don’t support 3rd party products.
I’m sure there are many people who buy these thinking they are basically plug ‘n plays as that is how they are advertised, essentially. That’s why I initially purchased a 60-in-1 JAMMA board, as I was intimidated by the apparent complexity of working with a Raspberry Pi, having only basic computer knowledge.
I will consider just reinstalling the actual RetroPie image, but will need to chat with my friend to see if he will be able to assist me. I will probably save the few ROMs I want to keep, as there is a lot of useless stuff I don’t care about. Thanks!
@whoremoan I believe your post describes an issue I have also been struggling with for some time, but recently made some headway in diagnosing. One thing, though - you included ADVMAME in your list...I haven't encountered the problem with that emulator, but have with the Libretro emulators (LR-MAME2003, etc).
In the mean time, one thing you can try (again, this would only be for the Libretro emulators) is to enable the "Game Focus" after entering a game, which usually defaults to the Scroll Lock key (yes, a keyboard would be needed, though I believe you can remap the key within the Retroarch on-screen menus).
EDIT: Though enabling Game Focus can be used as a workaround, after further testing / playing I discovered that using the "Grab Mouse Toggle" instead is often all that is needed (Game Focus locks down keyboard inputs, which may be too restrictive depending on the hardware). The Grab Mouse Toggle defaults to F11 (+ hotkey), but can be redefined in the retroarch.cfg file (input_grab_mouse_toggle = "j", is what I'm using). Grab Mouse does what it advertises, and makes the OS mouse pointer 'disappear' and not interfere with the game's mouse pointer.
I could not remember which of the two screens contained the mouse axis. I think my suggestion for remaps would only apply to items in the Quick Menu -> Controls. Since the mouse axis isn't in there it must be the override that is supposed to save it.
I think there have been reports of some settings not saving correctly as expected. I read someone was able to save settings by opening the retroarch menu from within Emulation Station and therefore no ROM was loaded. Might be worth a try if you haven't already.
EDIT: I can confirm that neither overrides nor remaps will save a mouse index setting for me either.
You can check by looking at the RetroArch's debug log and by running cat /proc/bus/input/devices.
Remembering your first RetroArch debug log, my guess is that RetroArch counts twice a mouse device as both /dev/input/mouseX and /dev/input/eventY. You can check this theory by adding a mouse (so you have 3 devices) and using indexes 0, 2 and 4 to see if each device is detected and working.
Okay. I can see that now, with access to the computer again. (Remember, it's in a different place than my desktop, that I use for posting.) Thanks!
Now I have the primary Mini PAC set in Keyboard Mode and I see that it recognizes the Mini PACs as devices, but also recognizes the devices on them separately. It looks like keyboard in the Mini PAC gets an event node. Interestingly, the Ultimarc SpinTrak (the spinner) gets Event 5, not 6. When I test with cat /dev/input/event6 I get input from the spinner and I don't with event5.
But this shows me that some of the devices are broken down into multiple devices and explains why something else is "in between" the trackball and the spinner.
As a side note, even though this is a built in function for RetroArch, I've now done what the manufacturer claims can't be done. Xtensions claims that, in D Input Mode, you can only have one mouse device, so you can have the trackball (somehow that always ends up as the one to take priority) but not the spinner in that mode. I'll be writing them about that!
When I have all my questions worked out, I'm going to either write up a few blog pages or make a few videos for others with the same issues. I'm hoping that they will use the so their other customers can get this working, too.