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.

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.)

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.

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

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.

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.

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.

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.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum