@nwgalloway So you had the es_systems.cfg in /home/pi/.emulationstation?

If you do, any new system you add will not get added to that file. Just an FYI.

@dziubak how did you transfer your roms?

@morrisav10 you can also try lr-vice from experimental packages. It works great for me.

@josephzink said in system not reading nes or snes files:

Not sure where to start.

Here: https://retropie.org.uk/docs/First-Installation/

@jester83
I found the problem doing the xbox one bluetooth connect linux trick causes input issues in emulation station

@jonnykesh I thought that as well. I was able to access them on my firestick though, so it is still an issue with the pi3 kodi connection.

@meleu said in Powering off via UI while using a Mausberry Circuit:

Do all the steps I showed on that topic and try to reboot your system. Describe here what happens.

And then perform this command: sudo systemctl disable killes; sudo systemctl stop killes and reboot your system. Describe here what happens.

SO, for starters, I have already done what you prescribed in the other thread to build the service and the killes.sh. Mine is till in the ~/bin folder, which is fine by me for now. After setting the killes.sh as executable, it works great! That is to say, I can do a software shutdown from command line for instance, and it definitely saves my metadata. Favorites and custom collections are awesome. Moreover, my additional line which triggers the NPN transistor does indeed let the Mausberry circuit know that a shutdown is imminent and it properly notices the drop on the GPIO it is monitoring and it cuts power. I really like this clever solution.

It also cuts power when I initiate a reboot. That makes sense to me, and for now I am willing to live with it. The point is that software shutdown requests properly exit ES and no longer lock up my Mausberry circuit.

Seems to me, the improvement to this would be to set a conditional statement before my GPIO command to trigger the transistor such that it checks to see if this is a shutdown/poweroff or if this is a reboot. I just don't know what to check to verify one way or the other--yet.

As for your command above, I initiated the command as you suggested and the system immediately did a shutdown, mausberry circuit powered off.

I emailed them. They told me it may got bent. Looked at it the card got bent, don't even know how it got bent. Sigh. Ohh well i gotta get a new card now sigh.

Could someone suggest to me a plug that is 5.1v and at least 3a?
I am having a hard time finding one that is good enough.

@djaay Like the issue says, you could configure it to unzip them in /tmpor in a memory backed folder. In Debian, /tmp is written in memory, so there is no writing to the disk.
As for the other aspect - RAM - I don't think it makes any difference: unzipping an archive to obtain the original ROM file would lead to the same memory used by the uncompressed ROM. The only - extra - memory would be taken by the internal unzipping routine, which should be easily reclaimed by the process once is finished.

@caver01 Thanks for responding!

caver01 "It does beg the question, so I will write it before someone else does: why not consider the libretro version of mame4all for those titles that require the bezel, since most of the work has been done for you?"

My reasons for staying with mame4all are:

I have a known good working set for mame4all The set works great on a non-OC'ed RaspberryPi 3 I haven't managed to get any of the libretro settings to correspond to my default old iPac2. A major issue for me. I don't like to have to spend hours re-configuring if I can help it. I like majority of the roms on my arcade cab to be listed under one menu. I know that you can use the arcade folder but lets face it re-configuring 800+ roms one at a time to work with the best emulator is a pain when mame4all just works.

That is how my mind deals with it. I would love to use the Libretro set but I haven't been able to get the key mappings right.

I was hoping that there would be a default bezel that mame4all could see and know to auto use it but I didd't think that there would be something so simple.

Thanks again!
BC

@caver01

I know it is suggested in the link above, but it looks like you missed the part about deleting the config first. After you delete default.cfg, a new one gets created the next time you launch, and that can restore the ability to use TAB.

yes.. this was exactly my original intention - disregard my second post :) if tab isn't working, delete the default.cfg as the link suggests

@lyle_jp then you need to make this argument on the github tracker for prosystem and convince them - arguing it here will do nothing as we don't develop the emulator. I'm not convinced but perhaps it could be a core option to switch for those that prefer the saturated palette.

It is my understanding that the ecm format is for psx games only. The ecm format is designed to remove a lot of information from the psx image because of how the anti- piracy was baked into the disc and bios. Sony write the disc with errors that way when you tried to copy it your drive (at the time) would try to correct them automatically...the psx bios sees a "fixed disc" and thus will not boot the disc.
Thus doing this makes it smaller..and then compressing it makes it even smaller.

Anyway what I am saying is that you may have a psx image NOT a sega cd image. I could be wrong. HurruicaneFan is correct though. it is all over the web out how to do this. When you get it unpacked and have a clean bin file and if it still will not load try it as a psx game and see it it loads..I'm thinking it will.

@jonbeazles
Did you configure the controls in attract mode? You can do that by pressing "TAB" button on your keyboard.

All that I can suggest is to connect another device to the network port of the PC to see if the network connection is shared to that device correctly.
Then at least you know if the Pi or PC is to blame.

personally, when things like this take too long I give up, in this case I would just conenct the Pi directly to the router.