Making premade gamelist.xml with xtra media collections

[Used2BeRX]

@edmaul69 Well... at least I know that the L/R defaults won't screw the game up by letting you eject the disk on accident. As long as that works, I probably won't even bother re-mapping it for now since I use a XBox 360 style controller.

I'm thinking more for my brother who is making one for his in-laws and he showed me the NES style USB pads he bought for it. No L/R buttons on that. Then again, I guess my solution wouldn't work for that case either since there wouldn't be any buttons that I programmed.

I guess for now I'll just have to ask him to borrow one of those controllers too so I can set it up properly for him.

In the mean time, if anybody reads this who knows about changing hotkeys on an emulator/console basis that works, I'd love to hear how it's done.

I don't know if the method on the RetroPie github is outdated or just broken, but the instructions on the following link do not work now.

https://retropie.github.io/RetroPie-Docs/RetroArch-Configuration/#example-per-system-control-override-retroarchcfg

[Used2BeRX]

@edmaul69 So.... I've got a problem here. Maybe two problems.

When I'm using nestopia, there is no indication on my screen at all when I eject/insert or flip a disk. It will work, but you're just randomly doing it until it says it's loading. Unfortunately because of this, I have no way of testing whether or not I'm able to eject the disk when it doesn't ask for it in Nestopia.

When I'm using Fceumm, I get the notification for the eject/insert actions and everything works as it should. The problem I'm facing here is that you are able to eject the disk at any point in time in fceumm.

What is your experience with this, edmaul69?

I'm going to post a topic asking about this, but I wanted to see what you had to say first since you're probably one of a handful of people who's even used the FDS on the Pi.

[edmaul69]

@used2berx ok. So it appears neither use hotkeys anymore. Nestopia is the better emulator based on disk flipping and not screwing anything up. Here is an explanation of how the 2 work.

So in fceumm it doesnt use hotkeys. L1 is side a/b. R1 is eject/insert. Ejecting can cause issues.

In nestopia all you do is hit L1 to load. However if it gets an “a b disk side error” at the loading screen or the flip disk screen, because you hit L1 at any point you need to press L1. It doesnt affect your game. It only gives you an error during the now loading screen and at the flip disk screen. So it does not affect the gameplay in any way.

So to fix your buddies controller for nestopia (you can do this in yours if you wanted too as its how mine is now setup) so if you open up your file /opt/retropie/configs/fds/retroarch.cfg add these two lines

input_player1_select_btn = 
input_player1_l_btn =

And put the number that is his select button number to this L1 and select button. Now he can switch disks with his select button.

[Used2BeRX]

@edmaul69 Unfortunately, the controller fix you put won't work man. And that's because of the wild inconsistancies of how both emulators handle FDS. It's not a matter of choice when it comes to which emulator to use, but a matter of compatibility. The very first game alphabetically on my list, a translated version of "19 Neunzehn", will only work in fceumm.

This is really bad news about how each emulator does their own thing handling FDS disks. Is there anybody we can talk to that could sync up the functions for both emulators?

[edmaul69]

Deleted. New post.

[edmaul69]

Deleted. New post.

[edmaul69]

@used2berx so to fix your problem would you be willing to convert your .fds roms to .nes to use like other nes roms? If so there is this tool to do that:

http://www.romhacking.net/utilities/662/

[Used2BeRX]

@edmaul69

I can't remember exactly what you're first two questions were, but I think they were something like this.

1. The problem with mapping buttons is because both emulators treat stuff very differently, and because I'm including over 100 FDS roms and not all of them work in Nestopia, probably quite a few of them will need Fceumm to run and no matter whether I'm using the default buttons or I figure out a good way to re-map stuff it will behave differently based off of which emulator is selected. I, personally, will know the difference when I see the games loading up. My brother and his in-laws, especially the kids, won't have a clue what is going on. It's already complicated running FDS games as-is, but when the two emulators have different methods for doing so it becomes needlessly complex.

2. I do have a few FDS conversions in teh set, such as the SMB2 one. There aren't a whole lot of them out there though, especially none that I know of for the 34 currently included FDS translations.

so to fix your problem would you be willing to convert your .fds roms to .nes to use like other nes roms? If so there is this tool to do that:
http://www.romhacking.net/utilities/662/

I would be if there are good instructions to do so. I'm not a rom hacker. I've opened some roms in HxD before and manipulated some headers for mirroring when directed to, but even with that tool I wouldn't have a clue how to convert games from FDS to NES. That would actually be awesome to do, but I suspect that it would be above my pay grade.

EDIT: At the end of the day, I think it would be a lot easier if somebody just got both emulators behaving the same way when it comes to flipping disks. I don't see any reason why somebody would change the coding for one to be so completely different than the other, especially when one of them won't play all of the games and you would need both for maximum compatibility.

[edmaul69]

This post is deleted!

[edmaul69]

@used2berx i will try it out and see how hard it is to convert them.

[Used2BeRX]

@edmaul69 Yeah.... I did see the utility. The readme says this:

Save as NES

FDS Explorer can now convert FDS disks to .NES fileformat. However it's
quite restricted. FDSExplorer examines the current disk-side and check it if
may properly convert to a .NES file. The conditions are that the disc
must have a 32K PRG-file and a 8K CHR-file. If so, the file is exported
with a NES header.
Notice that FDS Explorer only exports the data to a .NES file. You manually
have to change the mapper-number and perhaps "hack" the ROM to make it
run on NES-emulators.
Ideas on how to enhance this feature in the future is very welcome.

Just by reading that, I would probably be able to convert some of them, but not all of them. I know that a few of the games are a single side of a single disk, and others such as BodyConQuest are 2 disks with 2 sides.

Also, it kind of scares me that it's not completely automatic. When it says "you might have to change the mapper number and "hack" the rom", I'm totally going to fail at that.

I'm going to try this out on a few though and see what happens. I didn't realize that there were some basic instructions in the readme. If I can get a majority of them running this way it would be ideal, even if we can get somebody to re-code Nestopia and Fceumm to behave the same way.

[Used2BeRX]

@edmaul69 I don't know what you're seeing on your end, but it looks to me like 100% of the time so far the only games that it will convert are 64kb games like "All Night Nippon SMB" and Clu Clu Land (Think the black-box era of very early NES titles).

These seem to be the only games that have a 32k PRG rom. The others vary wildly in many cases but most seem to have a 16k PRG rom.

All in all, I'd say that about 90% of the games in the collection are 128kb and will not be able to be converted with this tool. :(

[Used2BeRX]

@edmaul69 I just talked with somebody who is very knowledgable with FDS hacking and they told me that this would be a major task and nobody would likely ever try to convert the FDS roms to NES since pretty much every NES emulator will play them. This issue is going to have to be corrected on the emulation side.

A consolidated version of the reply I recieved:

The way the FDS works, it has a BIOS for loading from disks, unlike the NES which doesn't need one. Some games will just load the entire game into RAM at the beginning. Others use both sides and have data for each level in different files, which are all transferred into RAM at the same point, overwriting each other. The files can be any size, and can be written to wherever you like in RAM.

This is very different from a ROM using bank switching. MMCs switch banks in certain specific amounts, and it happens instantly. Whereas a file could only be under a kilobyte, a bank has to be at least 4kb, usually more, and is a set size, so often you'll get wasted space.

Not to mention in all this that instructions in the games will point to different locations if you changed to a ROM. It could take a lot of reprogramming to make a larger FDS game work in ROM format, and require one of the more advanced mappers.

At which point you realize that every emulator can play them so you wonder what's the point.

[meleu]

@used2berx yo! I think I'll have some free time today. Can you take a look at our discussion here?

Cheers.

[Used2BeRX]

@meleu Hey buddy. Awesome!

Sorry... I was napping a bit after work, but I got up and saw you had replied. :)

The "gamelist-to-synopsis" feature will be pretty easy to implement.

Great! Man... if @mitu can reverse the direction of his gamelist.xml to spreadsheet and you can do this, that will make future synopsis work about 10 times easier for me in the future. Maybe even 100 times easier! No more having to edit individual text files, and I'll be able to finally sort by any tag for super easy editing of things like Genre.

Platform: Nintendo Entertainment System and Platform: Famicom Disk System entries in the synopsis.txt files located in /Media/nes/Synopsis/ folder will treat these entries as if they were NES and not FDS games and look for roms and all media in the /nes/ folders instead. (This should not occur if the synopsis, media and roms are located in the /Media/fds/ directory though).

Can you confirm if you still want exactly what you're describing above?

Yes. This is what I want. All of my FDS roms are in the NES roms folders, in the following directories (and all of the media is just in the corrosponding nes media folders):

/home/pi/RetroPie/roms/nes/(4) Famicom Disk System/(4_1) Translated FDS/
/home/pi/RetroPie/roms/nes/(4) Famicom Disk System/(4_2) Untranslated FDS/
/home/pi/RetroPie/roms/nes/(4) Famicom Disk System/(4_3) Update Hacks FDS/

The thing is, maybe somebody wants to use your script down the line that actually wants to separate the FDS system from the NES system. I just didn't want to "break" our script for them by simply not allowing this. So that's why I suggested that this only work for us when the FDS media/roms are in the /nes/ folders, and for somebody who was running the script from the /fds/ folder, it would work normally.

PLEASE let me know if that's still not clear. I'm doing my best to describe the situation, but I know that I tend to over-explain things and make them more complicated than they need to be. :)

[meleu]

@used2berx can you say all the possible Platforms you have on your Synopsis files? This info will be useful to implement the gamelist.xml to synopsis.txt feature.

[Used2BeRX]

@meleu Sure. These are only the ones that were done years ago. My hope is to add more console/handheld systems in time. I don't think I'll be adding any computer based systems though since they require a lot of individual controller configurations and would be a monsterous project on its own. Although I have done some work with DOSBox myself and I know another guy who is also working on that, and there has been an amazing Commodore 64 collection with the controller configs, but that would be a LONG way down the road.

Here's the current list:
Atari 2600
Atari 5200
Atari 7800
Atari 800 * See note below
Atari Lynx
Bandai Wonderswan
ColecoVision
Magnavox Odyssey2
Neo Geo Pocket
Neo Geo Pocket Color
Nintendo 64
Nintendo Entertainment System
Nintendo Game Boy
Nintendo Game Boy Advance
Nintendo Game Boy Color
Nintendo Virtual Boy
TurboGrafx-16 / PC Engine * I didn't separate the CD games for some reason... I will in the future.
Sega 32X
Sega CD / Mega CD
Sega Game Gear
Sega Genesis / Mega Drive
Sega Master System
Sega SG-1000
Sony Playstation
Super Nintendo Entertainment System
Watara Supervision

I believe that's all of them that I had done in the past. There were a few other meaningless ones like the Dreamcast VMU unit and Pokemon Mini games that aren't even emulated on the Pi that I probably wouldn't bother with.

BTW... With the Atari 800, could you do the same thing we're doing with the NES/FDS systems, so that if the Atari 800 stuff is located where the Atari 5200 stuff is it will work with the 5200? I have no interest in doing all the work on the Atari 800 computer since I never owned one and it would be a ton of controller configs to make, but I figured I'd probably put a smaller collection of 800 games in there that I found that were quite enjoyable that I've added to the XBox set years back. This way if anybody were to do the Atari 800 themselves someday this script could still work for them.

[Used2BeRX]

Also, I was wondering if we could add something else to the to-do list. I wanted to know if we could add a tag that is the synopsis.txt file name without the extension (txt). We could just make the tag <filename></filename>.

This might have several uses down the road since this is the exact file name of all of the associated media for every game. Right now it would be great for when I'm working on the spreadsheet as a way of alphabetizing stuff. When we get all the tags in our script with the FULL command, I hope to talk to @mitu about an option in his own script that would transfer over all of the tags that we're using. Otherwise, when we go through the process of turning the spreadsheets all the way back to text files there will be a lot of missing information.

BTW... I'm also going to try to see if somebody on the team here could add more image tags for us to use. And even possibly implement something where you could press a certain button on the controller to scroll through the existing image types. I think it would be awesome if we could have a video preview and an image box that you could scroll through the Boxart, Cart art and Title screen of all of the games.

Right now we only have the <image> and <marquee> tags. If we were to have tags for the tags you've already added like <boxart> to your script, it would eliminate the need to be able to change which image type is the <image> and not require a re-run of the script just to change the image type in the romlist.

Thanks again man! Excited to see you're back in any capacity. :)

[meleu]

@used2berx When a tag in gamelist.xml is empty or inexistent, what do you want to put on the synopsis.txt file?

Example: if there's no <originaltitle> in the gamelist.xml, do you want an empty Original Title: on synopsis.txt or simply skip this info?

[Used2BeRX]

@meleu Good question. Thanks for asking since I didn't think of that before. :)

Any empty tags should just not be put in the synopsis.txt files. This is because on the XBox they are displayed "as-is", so if there were a bunch of empty fields it would look messy and would take more scrolling to get through the whole thing.

You probably also thought of it, but any media tags we make for the locations in the gamelist.xml file should also not make their way back into the synopsis files. (No artwork, videos, gamefaqs, etc.)

Essentially, the only tags that should make their way back into the synopsis are the ones that were there originally. The only exception would be data/information tags that had information that I added in the spreadsheet before converting back to the gamelist.xml. For instance, if I realized in the spreadsheet that a game was missing the Publisher: information and I filled it in the spreadsheet, then that information would then make it back into the synopsis file.

Now that I think about it, I'm wondering if we should make a separate tag for the synopsis cited website at the end of the <desc> tag? This way we could still have that information in the synopsis.txt, gamelist.xml and the spreadsheet, but we don't have to take extra steps to remove it so it doesn't show up in the RetroPie romlists. The only thing we'd need to do is make sure that they get placed back at the end of the <desc> after two line breaks when it's covnerted back to the synopsis.txt.

Maybe call it <citation>?