https://github.com/EvilJagaGenius/jagoombacolor
which is capable of making the Crystal ROM usable.
Jagoombacolor works well with any Crystal localization, including the Italian one, but it is not able to make saving work on a rewritable Chinese cartridge.
Then there is this other version:
https://github.com/lesserkuma/goombacolor/tree/main
which instead is able to make "batteryless saving" work for Chinese cartridges, but it lacks the solution for the graphical glitches of Crystal. Would it somehow be possible to compile a version of Jagoombacolor that also has the ability to perform "batteryless saving"?
I suppose so, but I don't have the skills to do it hahaha
Thank you very much in advance to anyone who can help :)
You're probably used to much more powerful hardware, where your program draws pixels onto a surface, then you can draw that surface again at a larger size. The GBA is not like that at all.
I see, thanks anyway
]]>The GBA cartridge bus isn't compatible with a GBC at all. When entering GBC mode, a GBA becomes a GBC. It won't talk to GBA cartridges anymore.
Its a shame to have GBC hardware in my GBASP that I never utilize with my flash cart.
Of course, I can always plug in the original cart, but I really love not having to take all my carts with me.
Thank you.
I will probably add a GB/GBC flash cart to my travel pack.
For the GBA cartridge, it might be dumping the whole thing properly (as long as it's 32MB or smaller), but emulators may not support the bank switching method used by the flash cartridge, so you'll only see the menu working.
As far as I know, only one emulator ever supported flash cartridge features, and that was a custom build of VisualBoyAdvance SDL that was built to support the features of the Flash2Advance cartridge. This multicart is probably not using the same flash cartridge type.
In order to figure out the bankswitching method, you'd need to use a GBA debugger, and see what sequence of writes it performs in the ROM area to select a different bank.
--
As for the GBC cartridge, no idea. Might need to figure out what mapper it is using, and send the proper bankswitching commands to the mapper.
Thank you, I will check it if I can emulate those roms propperly.
Regards! :)
]]>I've tried copying to RAM before I load up the game and also not doing that. Doesn't work
]]>For an Android phone, I'd just skip the GBA emulation part entirely and just run a real NES emulator using RetroArch. If you really want to test out PocketNES specifically, you can use one of the GBA emulators within RetroArch. But I find that touchscreen controls generally suck. For instance, I was trying out Street Fighter II (SNES) recently, and could only successfully do a fireball 1/20th of the time.
In terms of emulation accuracy, I'd put the Classic NES Emulator higher than PocketNES in terms of sound emulation. The Classic NES series emulator actually synthesizes the noise channel, rather than trying to approximate it using the built-in GBA noise channel. For a simple game like Metroid which does not use complicated features of the NES or mappers, the Classic NES Emulator is perfectly fine. It just doesn't have savestates or cheats.
]]>And also, is there a way to remove palette options? I was going to make a separate Goomba file for each game so this would make it easier to immediately turn on the palettes I want rather than scrolling through a list
]]>@----------------------------------------------------------------------------
run: @r0=0 to return after frame
@----------------------------------------------------------------------------
tst r0,#1
stmeqfd sp!,{gb_flg-gb_pc,globalptr,r11,lr}
ldr globalptr,=GLOBAL_PTR_BASE
strb_ r0,dontstop_
mov r1,#0
strb_ r1,novblankwait_
b_long line0x
Commenting out
strb r0,[r1]
does allow the palette that's saved in the SRAM to get used. It breaks the whole GBC palette detector, though, which is obvious now that I think about it. I tried adding
cmp r1,#0
before that line thinking that this might make it only do the strb if no palette is stored in palettebank because it's the first time the game was booted. It doesn't work, either because I have no idea how to do conditionals in ASM (I don't!) or because palettebank is occupied even the first time a game is booted. It does seem to default to B&W when the GBC palette detection isn't done.
Anyway, I'm very satisfied with defaulting to B&W, but saving and loading a prefered palette. I see now that the palette saved is not per game, but per save file, so this wouldn't be such a good solution for people who append multiple ROMs and use the menu, but I always just do one ROM per file anyway, so it's perfect.
]]>welp I tried to compile but get this error:
rgbasm -L -Weverything -o audio.o audio.asm make: rgbasm: No such file or directory
not sure if this board is still active but ¯\_(ツ)_/¯
UPDATE
I got it to work!
All you gotta do is go to the RGBDS directory and rename each executable file to where it has no extension (see image below)
UPDATE 2
I made an xdelta patch from both versions (1.0 & 1.1) for easier access to people that may be struggling to build this
(There is an exsisting pack on RHDN but it uses ips which is an inferior patching format and I had issues using the roms patched using the ips patches)
]]>Is there anything I can do or any information I can give that can help out? I'm not really a programmer, but since I (and a couple friends) have the flash cart I can at least provide some data, I hope. I can say that all ESV files and the backup saves are 64k, but the flash cart menu doesn't provide any way to modify or control this and only has extra boot options for GBA specifically, not NES and not GB(C). Checking a HEX editor through some ESV files, it looks like the one for FFII definitely has information for about 20% of the file, and then very sporadic amounts near the end. The rest is just empty (00). I'd have to boot up some other RPGs or save-heavy games and play a bit to compare, if that's important.
EDIT: Apparently through the magic of being meticulous, I actually have started getting the SRAM to stick... through the process of using each of the game's four save slots at once, savestating (and taking one overworld step) between each save, getting into one battle, then repeating this process once, then powering down. I've tried doing half of this procedure, and other stuff like spamming save on just one slot, and nothing, but making the game use every save in sequence and doing the other stuff seems to make it behave. I thought maybe it was struggling to overwrite the part of the save block that already had something in it, which is why I started testing using alternative in-game slots, but then this started working and I was surprised. Yeah never mind, this only lasted about 10-12 saves...
]]>