While looking for a way to make full use of 128 kilobyte SRAM of an EMS 64MB cart for multiple saves (most games have 8 kb save and some 32 kb), i found an old program which does exactly the thing i want.
The program is called EMSMenu. it stores the saves into the last 96 kb of SRAM, and copies the save of the game you want to play into the first 32 kb of SRAM, so the game sees the save. So you can use 3 saves on one cart even more in version 2.1 as it takes into account which games use 8 kb.
it additionally lets to choose custom pallettes for bw gameboy games.
Unfortunately this program is written for old versions of EMS carts and it doesn't work on new EMS 64MB cart. The source code is released too. so i thought posting it here might be a good idea, in hope that it might get someone's attention, as it is a too good project to let die.
the main page is here.
http://www.personal.triticom.com/~erm/f ... m/GameBoy/some more info from the author about the project:
http://www.personal.triticom.com/~erm/f ... _Works.txt
I approve of this message.
I did some research and multiple game saves on the cartridge at the same time will be possible with some restrictions. I patched the menu program to be able to do this. Details should follow in the future. All I will say for now (as I am in a hurry) is that during my testing I was able to have Final Fantasy Adventure, Kirby's Dreamland 2, and Mega Man Xtreme all have their saves maintained on the cartridge at the same time. I can switch between the games as I please and their save data is never bothered by any other game. Details on what the restrictions will be explained when the menu patch is released.
Nice work, MottZilla. Let me know if there's anything I can do, but I haven't done GB dev in many years. When it's done, I can put it up on that
http://www.personal.triticom.com/~erm/f ... m/GameBoy/ page.
How hard would it be to compress the saves with run-length encoding or Huffman or the like?
I haven't a clue. The cartridge contains 128 Kbytes of SRAM which is enough for 13 games the way I have it setup. Given the limit of how much ROM you have to store games and even though you have two 4 megabyte pages the SRAM is shared and there is no software way to detect which page you are on so I don't think compression is worth looking into for me personally. But if you want to give it a shot feel free. You might need to poke around to find free room in the 32kbyte menu program.
So far testing has gone well. As I mentioned there are restrictions with what games you can put on the cartridge at once. First, you can only have 1 game that uses 32 kbytes of SRAM at a time, for example Pokemon. You can have 12 other games that use 8 kbytes of SRAM. However some games, probably mostly newer MBC5 games that use 8 kbytes may initialize the RAM Bank Register and end up using the same SRAM that 32Kbyte games use. These will have to be avoided being used together or a patch can be made for the 8kbyte game.
If anyone can think of various Gameboy games that use SRAM data backup please mention them in a list. I know of these so far.
Super Mario Land 2: 6 Golden Coins
Super Mario Land 3: Wario Land
Wario Land 2
Metroid II
Mega Man Xtreme
Mega Man Xtreme 2
Final Fantasy Adventure
Kirby's Dreamland 2
Crystalis
Kaeruno Tameni
Pokemon - Series
Legend of Zelda - Link's Awakening + DX Version
Legend of Zelda - Oracle of Ages & Seasons
I can't test them all but a variety is good.
thanks for the research. Some more SRAM gameboy games (i am not including GBC games, there are a lot of GBC sram games)
Mario's Picross
Mario's Picross 2
Sword of Hope 2
Game Boy Camera (but that probably doesn't count because its mapper has a sensor)
LSDJ
Tetris DX
Donkey Kong (1994)
Donkey Kong Land series
Kirby Star Stacker
Thanks for the mentions so far. Some games will need save fix patches for the multi sram menu to work with them. Older games tend not to interfere with the menu but newer games sometimes do, and all greater than 8Kbyte games will. Mario Picross for example is only 8K save but it sets the RAM Bank to 0, which I suspect a number of games will. Basically games that write to the RAM bank register but only have 8K of SRAM will all work with the menu's multi sram feature as long as we patch them. So it should be possible to have 1 32kb save game + 12 8kb save games on the cart at once. Either way it is an improvement.
Testing continues.
tepples wrote:
Game Boy Camera (but that probably doesn't count because its mapper has a sensor)
Not to mention that it has 1 Mbit SRAM.
I have updated my
website with the MultiSRAM menu and some new fixes and some save game fixes.
the link doesn't work unfortunately. 404 error.
edit: i meant the file link, sc_flasher.zip gives error, not the homepage.
few more battery save games (again only bw gb games):
final fantasy legend i and ii
golf
F-1 race
Nobunaga's ambition
personal organizer
torpedo range
ultima:the runes of virtue
Sorry about that. Somehow the file didn't get uploaded. It's there now.
I had a look at the patch. So, the patch is removing the code which calculates a value to be written as the upper nibble of the value that is being written to $7000. The lower nibble apparently limits the ROM size that's visible to the program, whereas the upper nibble is probably meant to limit the visible size of RAM. Your patch makes it always write 0 as the upper nibble which would make all 128 kB of RAM always visible. Did you research this and conclude that this functionality is broken in the FPGA?
From what the menu writes to the upper nibble I assume it might be RAM Bank limiting. It may indeed be fully functional. That *could* be useful if you were to store data in banks beyond what you set the limit to to prevent anything from writing those banks. But I see no reason to do that. It would be more useful if the upper nibble was like the ROM page select of the lower nibble and could isolate a section for you.
Since you've looked at the patch you've probably seen it's pretty simple. Remove the possible SRAM limiting as we need to control the whole chip. Then it just selects the desired bank before transferring execution to the game. Most games don't initialize the register since there is no need but some games do and ofcourse games with 32 kilobytes of RAM will be constantly writing it. But they shouldn't disturb the upper banks.
If I were to list improvements to be made to the SmartCard they would be:
$7000 Register Write Protection
SRAM Bank Limiting
MBC1/2/3 ROM Bank Register Mode ($2000-$3FFF rather than $2000-$2FFF with $3000-$3FFF for 9th bit)
With all of those it would pretty much eliminate the need for patches.
Perhaps the intended use was that the menu would copy (or decompress) the save data from storage banks ($04-$0F) to the working banks ($00-$03), unmount storage by enabling bank limiting, run the game, disable bank limiting, and then copy (or compress) it back.
tepples wrote:
Perhaps the intended use was that the menu would copy (or decompress) the save data from storage banks ($04-$0F) to the working banks ($00-$03), unmount storage by enabling bank limiting, run the game, disable bank limiting, and then copy (or compress) it back.
that is what the EMSMenu (the program i mentioned in the first post) does (except compressing). it might not be possible in the new EMS 64 MB usb cart though. Detailed info on master registers of EMS cart is needed and so far i haven't found it on net.
that is why what MottZilla accomplished is a great thing and could be accomplished by reverse engineering(or debugging).
it would be great if EMS would publish the use of master registers. Their flashing program is buggy and under-featured and this hurts the potential of their flash cart.
I'm not sure how much we need exact details on the Master Bank register. I suppose if you wanted to totally rewrite a new menu that would help. With some experimenting or careful reading of the code you could probably figure out what the lower nibble of the value means exactly. I might investigate it at some point.
I'm not too interested in save game compression because what happens if you have a number of save games compressed and then some change in the data causes the save to get bigger and now you don't have room anymore?
Though you did make me think with some SRAM management in a new menu you could support multiple 32Kbyte saves by using the Menu to manually copy data between slots. The current patch works pretty well, but actually the need for "save fixes" could also be avoided if the save banks were always copied to banks 0-3 before starting the game. So that is a good idea, but you potentially lose some save slots. I'd say you'd have 88Kbytes or 11 Banks to save data. That's 2 less games than the current setup which isn't so bad I guess. You could then manage to fit 5 games that save at once with two of those being 32kbytes in size.
Another thought is if you add SRAM management to a new menu, the bank reserved for the Menu could hold also custom save game titles. Then when you change games on your cartridge you could use the read SRAM option and then use a tool to see the contents of your SRAM to extract the saves you want. Although if you make it so after choosing a game you choose SRAM slots that could work too without you having to worry about using a PC tool to manage SRAM. So there is potential for a new menu to improve.
MottZilla wrote:
I'm not too interested in save game compression because what happens if you have a number of save games compressed and then some change in the data causes the save to get bigger and now you don't have room anymore?
Don't allow starting a game if compressed_size + free_space < uncompressed_size.
Another thing you could do to increase capacity is identify what ranges a particular game actually uses for saving (as opposed to scratch space) and zero out the rest before compression.
While that works in theory, we can't know or assume what space a game uses. The menu is just expected to work by all users. We can't ask them to know technical details of how their game works.
About the first point, so if we can't compress the save to fit into free space your idea is to not allow starting any other game until you free enough space or play the game again and get SRAM manipulated into a more compression friendly state? While again that makes sense as an idea, I think the end user would not appreciate this. Usually most users just want it to work reliability and easily.
128 kilobytes = 16 x 8kb that means 16 slots
reserve the first 4 slot for the current game
reserve the last slot for save game info (save the header of the game and which slots that game use)
11 slots is still plenty, it gives you 2 32 kb save games and 3 8 kb save games or 11 8 kb save games.
that is (with an automated system) what EMSMenu 1.2 does and i think it is very efficient
i do not think there is need for compression which might cause several issues in the long run
MottZilla wrote:
While that works in theory, we can't know or assume what space a game uses. The menu is just expected to work by all users. We can't ask them to know technical details of how their game works.
I was thinking of including a database of zeroable regions for those games that 1. are popular among end users (e.g. Pokemon) and 2. are fairly well understood by ROM hackers (e.g. Pokemon), especially if they 3. normally allow only one save per cartridge (e.g. Pokemon).
Quote:
so if we can't compress the save to fit into free space your idea is to not allow starting any other game until you free enough space or play the game again and get SRAM manipulated into a more compression friendly state? While again that makes sense as an idea, I think the end user would not appreciate this. Usually most users just want it to work reliability and easily.
One way to is to put a percentage of used space on the game select screen (e.g. 53% full). When the space runs out:
Code:
This card's save
memory is 100% full.
Which save data do
you want to delete?
Well with enough time and rom space for the menu you could probably add such features to maximize the amount of saves you could store. I'm not really that comfortable with the Gameboy to anything that extravagant right now.
List of US Gameboy (not including Color) Game Paks with Battery Backed RAM :
Bomberman GB
Donkey Kong
Donkey Kong Land
Donkey Kong Land 2
Donkey Kong Land III$
F-1 Race*
Fastest Lap*
Final Fantasy Adventure* (Mystic Quest in Europe)
The Final Fantasy Legend*
Final Fantasy Legend II
Final Fantasy Legend III
Go! Go! Tank
Golf*
Great Greed
Harvest Moon GB
InfoGenius Systems Personal Organizer
International Superstar Soccer
James Bond 007
Ken Griffey Jr. Presents Major League Baseball
Kid Icarus - Of Myths and Monsters*
Kirby's Block Ball
Kirby's Dream Land 2
Kirby's Pinball Land*
Kirby's Star Stacker
Lazlos' Leap*
Legend of the River King GB
The Legend of Zelda - Link's Awakening
Mario's Picross
Metroid II - Return of Samus
Mole Mania
Ninja Taro*
Nobunaga's Ambition
Pokemon Blue#$
Pokemon Red#$
Rolan's Curse II*
The Sword of Hope II
Super Mario Land 2 - 6 Golden Coins$
Tamagotchi
Tetris Plus
Top Rank Tennis*
Torpedo Range*
Ultima - Runes of Virtue*
Ultima - Runes of Virtue II*
Ultra Golf* (Konami Golf in Europe)
Vegas Stakes
Wario Land - Super Mario Land 3
Wario Land II#
Wave Race*
* - MCB2, 512bytes S-RAM
# - MCB3, 32Kbytes S-RAM
$ - Fix Required
European Exclusives :
Lucle
World Cup USA '94
Oodles of MCB5 Paks, intended for the Gameboy Color use battery backed S-RAM.
A question about the menu patch : will a 32K S-RAM game work with other, smaller games in a ROM page? As I understand it, the first partition reserves 32K of the 128K of S-RAM in the Multicart. But the menu program arranges ROMs by size, so the 32K S-RAM game will not likely be in the first game slot. But in the 2nd through 13th slot, it is apparently allocated only 8K of SRAM. Will the game take the next three 8K partitions?
Basically any 32K game is going to set the RAM Bank register itself. So it doesn't matter which slot it goes in at all. Games that only have 1 bank and don't write the ram bank register will use whatever the menu set for it, which is based on which slot it is in.
Thanks for the list. Is that a complete list by chance? Also I'm looking to write a new menu to manage SRAM in a different way.
Again the first 32K of the SRAM will be reserved for the game running. The last 8K will be reserved for the Menu program, leaving 88K for save storage. The idea would be to manage saves independently of the slots they are stored by using the title string as an identifier. Basically when saving the menu would try to match the name of the game being saved to one of the existing records. If no record is found then it would try to find space to make a new record. If it can't it'll inform you that the data couldn't be saved and that you need to free more room. There would be a menu for managing your records. And ofcourse when loading a game that has battery backup it would automatically search your list of records for a title string match and if found it would load your data. The reserved bank would also hold variables to know if the last game launched needs to be saved the next time the menu runs, to avoid requiring the user to manually backup data before playing another game.
I think it'll work out, even though you will lose some save slots compared to the current menu you will have more control over your save data and if you choose to change the games on your cartridge you won't lose your saves. A simple PC tool could be made to manage the 128KB extracted saves on your computer if for some reason you needed to backup individual saves. This would be easier with the new idea than the current menu since the program would have an idea of what data is in what bank.
By the way what do you mean Fix required? Fix to run on the SmartCard right? Link's Awakening requires a fix or else it will crash if you press A+B+Select+Start and use the Save & Quit option.
Yeah, Fix means it requires an IPS patch to work with the Flash Cart.
The list above should be all of games with a battery backed S-RAM that were released in the USA. It does not include Gameboy Color games (including Pokemon Yellow), Japanese exclusives, Unlicensed titles (if any) or peripherals like the Gameboy Camera.
This list will be helpful for testing. I've got a new menu written that should work for loading games, when I get the chance I'll work on the SRAM features.
Does your new menu have GB mode and GBC mode versions? The standard menu for the cart runs games in GBC mode even if you are using it for GB games. In order to get it to run games in GB mode (and thus have the same palette-selection features as a GB game) I had to upload games with a menu, download the games+menu as if it was a single game, hex edit it to get the GB mode flag correct, and upload it again.
arromdee wrote:
Does your new menu have GB mode and GBC mode versions? The standard menu for the cart runs games in GBC mode even if you are using it for GB games. In order to get it to run games in GB mode (and thus have the same palette-selection features as a GB game) I had to upload games with a menu, download the games+menu as if it was a single game, hex edit it to get the GB mode flag correct, and upload it again.
yes download the the new multi-sram menu program at MottZilla's home page which already solved this issue (and i am currently using it) or wait for some time as MottZilla is now writing a new program which has much better SRAM management capabilities and will surely include this fix too.
Even as the menu program is now, it is still a vast improvement on the official limitation of one save game per card with overwriting. Gives the card a new lease on life as far as I am concerned for games with battery backed saves.
Well I have a beta now that offers a SRAM Manager / Record System. As described previously, you get 11 Record slots for saving games. Everything is pretty much automatic to the point that all you have to do is delete data if you need more room. The first time you run it you'll probably need to delete all the records as the table is not initialized. It's recommended to do this. Having garbage in the record table alongside valid records could result in record loss.
Once you have a fresh table you just play your games as you would normally. It's important if you use both 32M ROM Pages to know that both pages should use the menu unless one of the pages has a single game that DOESN'T use SRAM. If you use the menu on both pages there is no problem. When you launch a game that saves data, the next time you power up to the menu it will automatically try to save your data to long term storage. If there is no enough free space, it will prompt you that you need to delete something to be able to save the game. If this happens you should as it suggests delete something, and then power off and back on so it will attempt to save the game data again. Deleting data is very simple, just look for the name of the game who's save data you wish to delete and press the button. It will ask you to confirm to avoid potential accidents.
With the new menu, once released, it will no longer matter if you change games on your cartridge around. Unlike the current patch to the original menu, the slot the game is in doesn't matter. More than one 32 kilobyte save at a time is possible. It should be possible to make a PC based tool to extract and inject game saves into your 128kb SRAM image that you can read and write to the card.
Hopefully testing will go well. Additional handy features might be implemented as there is alot of free ROM space unlike the original menu. One idea is CGB palettes from the CGB bootstrap could be implemented, both user selectable and auto detected game specific. Another idea is having a database of "game requires fix" warnings. So if a user attempts to load a game requiring a fix to operate on the SmartCard the game could be read at various addresses to determine a fixed or non-fixed version of the game and prompt the user that the game may not function properly without a fix. Another idea for standard GB games running on a CGB system would be "force overclock". Basically set the CGB into the high speed mode before launching the standard GB program. In some games it could reduce or eliminate slowdowns.
MottZilla wrote:
One idea is CGB palettes from the CGB bootstrap could be implemented, both user selectable and auto detected game specific.
Hey, I was going to suggest that.
And another suggestion: Although the CGB bootstrap palettes are implemented on the GBA, the GBA's screen doesn't respond the same as the GBC's screen. For instance, if you use the all gray palette on a GBA, the screen makes the grays darker than if you were to do it on a GBC. So my suggestion is to have an additional palette "all gray palette, but modified so that when run on a GBA, it looks like the original one would have looked on a GBC".
(Although how dark the GBC looks seems to depend on viewing angle as well. It's darker at a steeper angle.)
arromdee wrote:
MottZilla wrote:
One idea is CGB palettes from the CGB bootstrap could be implemented, both user selectable and auto detected game specific.
Hey, I was going to suggest that.
And another suggestion: Although the CGB bootstrap palettes are implemented on the GBA, the GBA's screen doesn't respond the same as the GBC's screen. For instance, if you use the all gray palette on a GBA, the screen makes the grays darker than if you were to do it on a GBC. So my suggestion is to have an additional palette "all gray palette, but modified so that when run on a GBA, it looks like the original one would have looked on a GBC".
(Although how dark the GBC looks seems to depend on viewing angle as well. It's darker at a steeper angle.)
i know what you mean. some games detect if they are running on GBA and use a different palette (like zelda). there are some problems though.
you can run EMS cart on gameboy color(without a light), gameboy advance(without a light), gameboy advance sp AGS 001(without light or front light user selectable) or gameboy advance sp AGS 101(backlit, 2 brightness level, selectable)
do you get what i mean? although you can do the GBC GBA difference on software side, there is no way for the software to understand if it is run on a backlit,frontlit or no light screen. so there is no universal selection
CGB bootstrap palettes' RGB codes are known, a custom menu can let the user enter r,g,b levels manually gathered from these codes by adding,subtracting values etc. or anyone can post his/her own palette codes.
Testing of the menu has gone well. Found bugs were fixed. The menu now works on the Color Gameboy as well. I'm hoping to add support for a database that can detect the games the CGB BIOS would apply a custom palette to as well as detect known problem games that need a fix to warn unsuspecting users that they need a fix for the game to work. For games without custom palettes, atleast 3 user selectable palettes will be available. CGB default (for any game that has no hash match), a gray scale palette, and a green to black scale palette.
With the addition of handling the CGB, there should be no problem mixing CGB and non CGB games on the cartridge at once. Once the database feature and the user selectable palettes are done I'll make a public release.
Update: The database functionality is implemented and I added to test games. Alleyway and Super Mario Land 2. Both games when played will have their CGB special palettes applied. Super Mario Land 2 is also checked to see if the ROM has been patched, if it isn't it will warn the user that the game requires a fix.
Once it's tested more, I'll look into adding all the games the CGB normally has palettes for when detected, plus some user selectable ones to choose from. And ofcourse I'll add all known games needing fixes.
Quote:
For games without custom palettes, atleast 3 user selectable palettes will be available. CGB default (for any game that has no hash match), a gray scale palette, and a green to black scale palette.
Is it possible to do this without interfering with the ability to select various palettes using directions and buttons like a GB game played on a GBC/GBA normally has?
Well if you load the menu in monochrome mode, then the GBC can select a palette by pressing buttons. But then you cannot play Color Gameboy games, so you can't mix color and mono games together.
The eventual goal is to allow palette selection (every button combination) within the menu. And also to add all or most of the games with custom palettes as well.
To detail the problem a bit. When the CGB starts up it first checks the Color compatibility flag, then checks for the game's license and calculates a checksum based on the title to see if a custom palette should be used. You can also pretty the buttons to force a palette. But the color compatibility flag if its not set, while you can choose a palette it also causes GBC features to be locked down and GBC software can't run. If the Color flag is set, then you can't choose a palette.
So again, the goal is to have in the menu support for choosing a palette, or using a custom palette stored in the database which will hopefully contain all the games Nintendo set custom palettes for. By doing this, we can eliminate any need for having both a "Color" version and a Mono version of the menu. Instead it'll just work on either system, if the system is CGB then it will support Color software just fine. Any comments or suggestions or questions are welcome.
Well unless someone knows some trick, I'm dropping the idea of having both CGB and DMG (mono) games on the same rom page. The reason being that the CGB Bootstrap checks the Color flag and if it's clear then the bootstrap will set the CGB into some kind of DMG compatibility mode. If this isn't done and you try to run DMG software in Color mode you could have alot of problems. First the CGB uses different OAM sprite bits than the DMG. So any sprites trying to use OBJ PAL1 will still use the same palette as OBJ PAL0. And other graphics/coloring related issues come up.
So in short, you *have* to set DMG compatibility mode for full compatibility. But you can't, because it appears that the special registers that do this are only writable while the bootstrap rom is enabled. And you can't re-enable the bootstrap rom. And so I've scrapped all plans of running DMG software in CGB mode. It'll be like the old menu where you specify if the page is Color or non-Color games. However you can use one page for DMG and the other for CGB software, and your save data will still all coexist between pages. So that's still a nice improvement.
So while the SRAM management has been tested and gone well already, the only thing holding back a release right now is adding to the database *fix required* warnings. Basically while originally it was going to be for applying custom palettes and checking for fixes, it now is just a databasr for fix checking. I changed it so now it will compare ROM (first bank only) and see if certain bytes have been modified. If they match the original values it will warn you that a fix may be needed. This works great for old games that write to $3000 instead of $2000 or $2100, such as Super Mario Land 2.
So that's what is going on now. I will add all the existing fixes to the search database and then post a release. The database isn't terribly important but it's a good idea to warn users if possible so they don't wonder why the game doesn't work.
Quote:
So in short, you *have* to set DMG compatibility mode for full compatibility. But you can't, because it appears that the special registers that do this are only writable while the bootstrap rom is enabled. And you can't re-enable the bootstrap rom.
Is it possible to set the color palettes while in GB mode? If not it sounds like it would be impossible to use Nintendo-defined game-specific palettes at all (unless you wanted torun the game in GBC mode and set them only for cases where OBJ0 and OBJ1 use the same colors).
The CGB always starts in CGB mode. It then sets a compatibility mode. I don't think the color registers are available while in DMG mode, but that would be something to test out. Maybe someone knows. If that works then I could re-implement that feature.
Now that I think about it, you could be right. It could be that in DMG Compatibility mode you can set the palette, as I think the lock out register writes occur before the palette writes. I'll have to give it a shot.
Well I took a look, trying to write the CGB color registers in DMG Compatibility mode ( Cart ROM $143 equal $00 ) did nothing at all. I have a feeling that only the bootstrap itself can set colors for DMG compatibility mode. I've pretty much given up on worrying about palettes.
The SRAM management works fine. The fix required detection works well enough. I'll add all current fixes to the fix database and then release the menu.
I have
released the new menu. All current fixes are in the fix needed database. The SRAM Management system works well. Give it a try, it should be superior to the original menu and hopefully won't have any problems.
Update: I forgot to add the Battletoads 2 (Ragnarok's World) to the database, so it won't warn users about that one. It will get added later on I suppose.
thanks for the new menu. it is a great improvement over the stock one. finally we can benefit from that huge 1 mbit SRAM of the EMS cart.
I agree, it is a very nice improvement.
I have added Mario's Picross to my set of fixes on my website. Reprep told me about this game needing a fix. The fix isn't tested on real hardware but it should do the job.
Observation: I have a 64 in 1 Chinese multicart. You boot it up, it provides a menu (in GBC mode), and it lets you pick a game, most if not all of which are GB games. After you pick a game, it then brings you back to the Gameboy Color bootup screen. You can use buttons/directions to pick palettes, and Nintendo-preset palettes for games work.
Is this something which only works because the cart has special hardware or is it a possible avenue for doing palettes on the EMS card?
Likely Cartridge pin /RESET is tied into the multi-cart and resets the CPU. You could do a mod to add a reset switch to either your system or cartridge. When you see that Gameboy bootscreen, that's the bootstrap which controls if the system is in CGB or DMG Compatibility mode. By reseting the CPU but still having the cartridge configured for the selected game, you can ensure the correct mode is used.
I hope that makes sense.