Diagnosing ROM problems?

sleve_mcdichael

@iandaemon said in Diagnosing ROM problems?:

@colstar I mean the specific error may be logged in /dev/shm/runcommand.log.

https://retropie.org.uk/docs/Runcommand/

Don't forget to launch with verbose logging enabled for the detailed report.

The log file location is not accessible via the network share. To access it more easily, plug a keyboard into the Pi and press F4 to exit EmulationStation, or connect via SSH (Windows has a built-in SSH client; from a command prompt, use ssh pi@retropie.local or, if your network doesn't recognize host names, you can use ssh pi@<your.pi's.ip.address>. The default password, if you haven't changed it previously, is raspberry.) Then copy the file to your roms folder with the command:

cp /dev/shm/runcommand.log /home/pi/RetroPie/roms

This will put a copy of the log file in your roms folder where it can easily be accessed via the network share.

Colstar

@iandaemon said in Diagnosing ROM problems?:

@colstar I mean the specific error may be logged in /dev/shm/runcommand.log.

https://retropie.org.uk/docs/Runcommand/

Ah thanks, I have never delved into any of this as yet. May have to take a look!

IanDaemon

@sleve_mcdichael After I posted and walked away I thought "I should have said something about verbose logging." And for the location...Couldn't you just use a symbolic link to the file?

jamrom2

@colstar even without the verbose logging, you'll be able to see where the emulator is failing.

As for the MAME roms... you have to match them to the correct version. Which version of MAME did you load?

Each version we can run on Retropie correlates to a specific version number of MAME. So they're not the same.

As for Atari 5200... it's a bitch to configure... but start with a good BIOS and .a52 roms. They can be zipped, but make sure they are not .atr/.atx roms. Those are for the Atari 800.

To setup A5200 and Atari 800 properly.. follow this... we found a problem with the Atari 800 loading script at the end and I think rkoster was going to edit it. If it's not, and it doesn't work... let me know. I helped him with it. I know how to fix it. He did a rock-solid job and everything works better than any other guide I've tried in the past 5 years.

https://retropie.org.uk/forum/topic/22392/lr-atari800-5200-artifacting-basic-and-other-guidance/44?_=1619483254571

best,

Jam

sleve_mcdichael

@iandaemon said in Diagnosing ROM problems?:

And for the location...Couldn't you just use a symbolic link to the file?

(Edit: ~~Yeah, that didn't work.~~ Doesn't work without some additional configuration. See @mitu's post #20 below.)

~~I suppose you could, yeah. Then it would always just "be there" and you wouldn't have to re-copy it every time you needed it. So instead of cp you would use ln -s:~~

ln -s /dev/shm/runcommand.log /home/pi/RetroPie/roms

This link will act like a pointer, like a Windows "shortcut," that always points to the most recent version of the log file, instead of a copy which is just a snapshot in time of what the file looked like when you copied it.

jamrom2

@sleve_mcdichael lol... I was thinking the same thing... you have a really good idea though, so much better than hunting for it every time via WinSCP. With that link you can just open the ROMS folder on your desktop and view it that way.

IanDaemon

I thought of a possible issue. If Windows "can't see" a Linux partition, may the symbolic link be pointed to a location the Windows machine "couldn't see"? (Windows machines aren't the Kwisatz Haderach.)

So symbolic links may be A solution, but they definitely are not THE solution.

sleve_mcdichael

@iandaemon Windows can "see" the roms folder just fine over the network, though. Isn't that already on the Linux partition? That's why we have to use WiFi or a USB stick and can't just add roms directly to the SD card, right?

IanDaemon

@sleve_mcdichael There are multiple Linux partitions on a RetroPie SD card. The ROMs are just on one that a Windows machine can see. (e.g. accessing over network not ssh) If your Windows computer is on the same network as your Pi you may be able to type \\RETROPIE in Windows Explorer or Internet Explorer and get to the partition that the ROMs are stored via Samba-Shares.

You can see more details here: https://retropie.org.uk/docs/Transferring-Roms/

sleve_mcdichael

@iandaemon you're right it doesn't work. I just tried it just now and when I tried to open the file or copy it to another location it failed, and said I needed permission from the system's administrator.

IanDaemon

@sleve_mcdichael Did you rename your Pi? I have two so on my Windows laptop I go to \\THINCOCKTAIL and \\GOLDENTEE2005. I believe the login information is by default Raspberry and Pi.

https://retropie.org.uk/docs/Transferring-Roms/#samba-shares

You can't access every file via Samba Shares, but I find it really useful. Is Samba Shares turned on?

jamrom2

@iandaemon opposite... pi is the user, raspberry is the password by default

sleve_mcdichael

@iandaemon no, Samba is working fine. I just mean that, as you suggested earlier might be the case, linking the runcommand.log file in the roms directory does in fact not work (no bueno) to make the file always accessible via the network share. I can see that there is a runcommand.log file in the roms folder on the network, but I cannot open it or copy it or move it.

mitu

@sleve_mcdichael Symlinks are not 'followed' on Samba file shares when they point outside the shared folder, it's a security configuration enabled by default - https://unix.stackexchange.com/questions/5120/how-do-you-make-samba-follow-symlink-outside-the-shared-path.

YFZdude

@mitu
Is this a situation where you could create a hard link to create access to the file without denying the original from operating properly?

mitu

@yfzdude Not sure I understand what you mean, but this is about symbolic links (symlink) and not hard links (which work differently, but wouldn't work in this case since /dev/shm is on a different fileystem).

YFZdude

@mitu
Ah ok.
Yes I meant simply a hard link but didn't realize it wouldn't work due to crossing over to a separate filesystem.