#83396 - Natso - Tue May 16, 2006 3:24 am
Ok, I'm working on this game, and before I had multiboot it was able to access the save memory(SRAM i believe) and I could restart the cartridge and the save data would still be there. Once I made it be multiboot, where it totally copies itself to the client(s), it can no longer access the SRAM.
Is there a known way to fix this, or do I just need to scrap the multiboot(saving is essential to the game)?
Thanks
- Natso
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)
#83398 - Dwedit - Tue May 16, 2006 3:42 am
If you use multiboot, you have to assume that no cartridge is inserted, otherwise you'll overwrite the SRAM of whatever cartridge is inserted. If you want to assume a cartridge is inserted, you can still use multiboot, but you need to check that the cartridge is indeed the one you want to write to before writing there.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#83420 - tepples - Tue May 16, 2006 5:44 am
"Multiboot" has become an overloaded term.
In a true Single-Pak Multiplayer configuration (not a GBA Movie Player configuration), clients should send their data back to the server, which stores it on the cart's SRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#83438 - Natso - Tue May 16, 2006 12:35 pm
I'm talking about the single-pak multiplayer configuration... but the thing is that the Host can run without the pak, just like the Client can. This was a side-effect of me changing the game to be multiboot, but it also prevents the host from accessing the SRAM.
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)
#83558 - phonymike - Tue May 16, 2006 11:38 pm
if there's a cartridge inserted into the gba, and is a standard sram, then any program running on the gba can access its sram by reading 0xE000000.
if you want all programs running to be able to save, then you must have each one detect if there's a cartridge inserted, and if not, have the next gba check, and down the line. sram is like a register, all gbas cannot access the sram in one cartridge by accessing the register, you have to incorporate code that makes all gbas send sram data to the gba with a cart plugged in.
maybe the cart plugged in doesn't have sram, it may have flash or eeprom and shit. in which case you need to know which kind it is so your code can access it with certain protocols.
#83568 - tepples - Wed May 17, 2006 12:07 am
Unless the problem is that the emulator doesn't make a .sav file for multiboot programs. In that case, you need to make your program a .mb.gba, which will be loaded as a GBA ROM but is copied to EWRAM upon startup.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#83575 - Natso - Wed May 17, 2006 1:39 am
okay; all my multiboot stuff is tested on real GBAs (Actually a GBA and GBA SP), where the host always has the flash cart. I think my problem is that it IS a flash cart, and so the save positioning & such doesn't work like a normal cart.
Out of curiosity, if I made the host and client connect and replaced the flash cart with my Pokemon Ruby cart(the host and client don't freeze), and try to write tot he save data, will it work properly?(for my program, not pkm ruby)
Thanks
- Natso
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)
#83576 - chishm - Wed May 17, 2006 1:48 am
No, Pokemon Ruby (and Sapphire) use 128KB of Flash ROM for saving, so you cannot write to it in the same way as SRAM.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#83644 - thegamefreak0134 - Wed May 17, 2006 5:20 pm
I think I see the problem. Are you making the host a multiboot program as well? (like, doing a multiboot transfer rather than writing to the cart?) I think if the host is multiboot, it won't be able to write to the cart, seeing as how the GBA treats it like a cart isn't there. What you'll need to do then is make a regular gba game (write it to the cart and everything) and have that game act as the host. Then, have it send the multiboot program to the other GBAs, but run a separate part of itself that behaves like the multoboot programs. Then, this "host version" should have saving rights.
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83664 - tepples - Wed May 17, 2006 7:24 pm
| thegamefreak0134 wrote: |
| I think I see the problem. Are you making the host a multiboot program as well? (like, doing a multiboot transfer rather than writing to the cart?) I think if the host is multiboot, it won't be able to write to the cart, seeing as how the GBA treats it like a cart isn't there. |
O rly? Does the hardware lock out the ROM and SRAM when running a program that has been loaded into EWRAM? That's not what I have observed, especially given that 1. the Flash2Advance USB linker can read and write the cart inside the GBA, GBA SP, or Game Boy Player, and 2. "SRAM cannibalism" builds of PocketNES worked even before the GBA Movie Player became the most popular method of running mb.gba programs.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#83676 - thegamefreak0134 - Wed May 17, 2006 8:33 pm
...I guess you have a valid point. Shutting up now, and cowering in my corner. (Sorry, just seemed logical to me.)
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83710 - phonymike - Thu May 18, 2006 12:02 am
how about you write a program that writes to sram, making sure it works on your cart. then make a client rom that sends data to a server program, in which the server saves the data. I can't believe you're having trouble with sram access yet got gba comms working.