sundogak

It says right in the error you posted you are missing files. You don't have a complete romset and/or you are not pointing to your full arcade MAME rom set within your MAME.ini. Edit: If you are using a MAME merged set the files will be here: If you are using a MAME split set the files will be here: But again, your repeated issue based on errors above is that you are moving roms around rather than just pointing to your main MAME arcade roms directory with full set of correct roms or you do not have a complete set to begin with.

List yes, but nothing with screenshot. You would have to convert the text file output to PDF if you want that. Two options, for the second scroll down thread as they made updates later to script.

I had typo in command above. Should be: apple2gsr1 Also do not rename any MAME roms. The Apple2GS.zip is all that is needed.

For #2 question, that game looks to have system files (ProDos and System folder) so should boot without a system disk. At least for me, if you run with MAME and get a blue screen with "Error=$ 002E" then you need to switch the Apple IIGS Rom from 3.0 to 1.0. To do this, where you have this in your custom command line apple2gs change that to apple2gsr1 When it boots up the blue screen should say "ROM 1.0" on bottom instead of 3.0 Note you won't be able to play this game to control ball as it required a special "Future Pad" controller. There is a hack version of the game floating about that bypasses it and uses keyboard (the Exo Apple IIGS pack has it). For #3 question, that is limitation of IIGS just like a real computer of the time. The IIGS by default has two 5.25" drives (-flop1 and -flop2) and two 3.5" drives (-flop3 and -flop4). Thus, you have to use the MAME interface to swap out Game Disk1 in Flop4 with Game Disk 2 and then let it load. More than likely it will ask for Game Disk 1 again and have to load that back into MAME interface. An alternative is to use a hard drive image with system files to boot instead of a floppy image. Then the two floppy drives are available. You can search for a HD image if do Google search for "System 6.0.1 Hard Drive Image ~13.3meg". It will have a "HDV" extension. For hard drive images you have to change the command to run MAME with hard drive to: apple2gs -sl7 cffa2 -noautosave -gameio joy -ramsize 8M -hard1

As stated in other thread, you shouldn’t be moving any BIOS files. You point your Mame.ini to the full set Mame Roms directory which if a full set will have all the needed files.

Did you change the view options? Check what key you have assigned via Options, Controller Mapping, Switch View.

Looks like the Nostalgia video set by Viking

The sound is just MAME simulating the sound of the floppy drive reading the disk. This command works fine for me which is basically what you are telling LB: mame apple2gs -flop3 "path_to_your_disk\System.DiskIIGS_604.po" -flop4 "path_to_your_disk\Dueltris.2mg" The loading process will go to the blue screen, then eventually to the loading screen to the Systems 6.04 (approximately 60 seconds to get to screen). You should also delete any saved states for your games in your ..\MAME\sta\apple2gs\ if you are having issues as may be corrupted. Beyond that, if you are crashing at loading window then you should check you have a complete rom set for MAME as the bios files are in the full Arcade set.

eXo's IIGS set is using MAME, GSPort and GSPlus depending on game and if want it "all setup" that is advantage with his packages as he addresses things like needing ProDos operating system to play or eases multi disk games (Bard's Tale as example). MAME is the way to go for most part if not using eXo setup. See this thread on MAME setup. The issue is like with most computer emulation is more complicated than cartridge setups. Many of the other emulators besides MAME like KEGS haven't been updated in many years.

Only the parameters in the associated platform for RA are added to run command. As to why RA isn't managed differently, I do not know. I have never run into it as issue as anything RA wide I use the Retroarch.cfg (e.g., fullscreen or default shaders) and specific flags have to go with the associated core entry.

LB is basically a launcher taking your inputs and creating a command line to launch the emulator. The flags you are trying to pass are specific to a RA core. RA base executable + core [and any switch/parameters] = emulation. The first example you give is trying to give a switch/parameter to the base retroarch.exe before a core is loaded. RA doesn't know what to do with it so ignores it. The second screen works because RA now knows which core to run and LB adds those additional parameters to RA + the core at that point.

Retroarch has cores you can download that provide emulator code. LB has no issues with RA or their associated cores.

https://answers.microsoft.com/en-us/windows/forum/all/how-to-remove-windows-11-password-login-i-want-to/182a06be-263f-4e7d-9be6-9d21c7f6f6f2

DirectX SDK, and depending on Windows version NET library components LB runs on top of. Simplistically, rerun the installer and point to same path as original setup, any settings specific will not be overwritten but any missing base files will be installed.

Yes, it is portable if you have the base files needed to run LB. Otherwise you have to run the installer one time on the new PC setup. However, each specific emulator will vary on their ability to be portable.

That was never a built in emulator to LB. Somewhere along the line you installed EpicFail's ScummVM Launcher. Batrunner.exe is just the the plugin's renamed ScummVMimport.dll. There have been lots of changes to that launcher. I used to use it but do not any longer. Most recent user written instructions are here.

You will get a variety of opinions but I think for cartridge based systems RA is easy to get working and performs well on those emulators. Plus there are a variety of cores to pick from if prefer a different emulator base. For majority of the older CD based systems like Nintendo 64, NEC Turbografx CD those also tend to be easiest to setup in RA. When you get to "newer" systems like Wii, WiiU and PS3 "on up" then tends to be less beneficial and/or no cores. The other issue is RA cores can lag behind their stand alone emulator base which usually isn't a big deal for the older cart systems. The advantage to RA is once you get it figured out then other systems are pretty similar to setup. However, MAME and computer systems are main areas I avoid using RA as it adds another layer for troubleshooting particularly if trying to also use via LB.

rompath defaults to where the executable is launched as base path. So when you have just "Roms" in the ROMPath then assumption is MAMEUI.exe\ROMs is where things are located. Similar with CHDs. If you are executing via MAMEUI.EXE then the paths and roms should be like this: MAMEUI.EXE\ROMS MAMEUI.EXE\ROMS\CHDS You MAME.ini would then be rompath roms;roms\CHDS You shouldn't need to put in the full path and in many cases causes issues later. You also shouldn't have to move anything as that is whole point of the rompath variable to point to correct pathing. Just make sure your logic and names are correct for both.

You re-import the full set. Note you will lose any customization as re-import uses the MAME data for things like genre and player type as they will revert to MAME way of things. If only interested in a specific game in the update you can drag and drop the ROM into LB Arcade window and install that way and that way doesn't mess with any customization. LB isn't an emulator, so there is nothing to enable. LB will launch the emulator with whatever settings you have setup. For regular MAME those settings are determined via MAME.INI (or command line). There is really no reason (in my view) to use MAMEUI if using LB as front-end. Don't move the CHD folders as that is way needs to be setup with folder name and CHD inside that folder. In LB it should point to the the kinst.zip file. Your CHD should then be here using what you described: ROMS\CHDS\kinst\kinst.chd More than likely if not launching you have a path/setting issue. Does it work with MAME directly? If you try launching from command window (outside LB) what error does it give you?) Make sure your path to CHDs is specified in the MAME.ini for rompath (in your case would be called "CHDs"). For regular MAME you set the settings such as bi-linear filter, HSL and GSL here:

Yes, you can do that and most people do it that way. MAME for arcade and other emulators such as RA for other platforms. Each platform (e.g., NES, SNES) can uses it's own emulator. You can even use a specific emulator on per game basis if it is capable of running that game type via Edit Game Window and choosing which emulator to use:

MAME ROM Software sets do not have cartridge headers that indicate to the emulator the type of cartridge, size, and mapper information. They are the game ROM data only. The MAME emulator doesn't need this header on the ROM file as it deals with this by including this data in the HASH file XML for each cart system (if applicable). For example, if you look at "NES.XML" in your MAME Hash directory you will see information on the header data. MAME matches the ROM checksum looks to the XML for mapper data and the emulator knows how to run the cartridge. For archive purposes the non-headered are preferred or if you are going to do patches for hacks as you need to match specific checksums or the patch will fail (or make corrupted ROM). Some non-MAME emulators get around all this with built in databases within the emulator so will work with either type ROM. Other emulators need the header in the ROM file or will just not run (as you experienced). Others yet, may stop and ask for the header information which is annoying if on a Big Box type view (some Atari 800/5200 emulators). There are various utilities to add headers to things to non-headered roms like here for NES https://www.romhacking.net/utilities/1352/ But for emulation, best to pick a ROM set that works with your emulator so don't have to get into that gory level of detail.

LB DB is one image at time for users. There was an old plugin that had some bulk ability on per game basis to upload to DB but hasn't worked in awhile. It was fiddly even when it did work. Plus it created other issues in that the approval queue would get large as people uploaded all kinds of files (many times not always better) that reviewer had to wade through. Then there is the problem of no way to know a better version was uploaded (other than manually looking). I am always a bit hesitant to mindlessly have LB blind overwrite media in mass.