How do real-time save hardware devices work? I am specifically interested in the GAR.
The world may never know :P
(Seriously though, ask Bung, it's their product :)
(Seriously though, ask Bung, it's their product :)
kyuusaku wrote:
The world may never know 
(Seriously though, ask Bung, it's their product
(Seriously though, ask Bung, it's their product
Well, I assume it must somehow interrupt the NES and check for a specific button combination, if it doesn't find it it returns control back to the game, otherwise it executes something that copies memory and registers into its BBSRAM. So how would it interrupt the cart? It could count the number of accesses to ROM code, and after a fixed amount, it could interrupt things by returning its own code instead of the game's code. If it only did this once every second, and when it interrupts it is very efficient (just check the user input), then it wouldn't have much of an effect on performance.
Does that sound like it might be right?
I don't understand what you mean by counting ROM accesses.
My guess is that the GAR polls the controller waiting for Select/Start and A/B then injects it's own interrupt. However the GAR's key combination is changeable or at least my GAR precursor device is so that changes things a little.
From there, the hardware jumps to the GAR's BIOS and you are greeted with a menu screen. Lots of things are pushed, and the system's RAM is copied to the GAR's BRAM. I'm not sure what happens if you have a NES with 8k of RAM though.
When you load a state, the system loads the RAM, pulls the system status and jumps back into the game. How it keeps track of bankswitching stuff I don't know. I've backed up some of the save state files my device has made before, they're pretty hefty at 20k. Maybe sometime I'll examine them if I ever can fix my setup.
My guess is that the GAR polls the controller waiting for Select/Start and A/B then injects it's own interrupt. However the GAR's key combination is changeable or at least my GAR precursor device is so that changes things a little.
From there, the hardware jumps to the GAR's BIOS and you are greeted with a menu screen. Lots of things are pushed, and the system's RAM is copied to the GAR's BRAM. I'm not sure what happens if you have a NES with 8k of RAM though.
When you load a state, the system loads the RAM, pulls the system status and jumps back into the game. How it keeps track of bankswitching stuff I don't know. I've backed up some of the save state files my device has made before, they're pretty hefty at 20k. Maybe sometime I'll examine them if I ever can fix my setup.
Bump. I fooled around a little with the GAR today and can conclude a few things:
It certainly polls $4016 into a shift reg, once it gets the hotkeys it does it's thing. Games which do not do anything with $4016 (FDS BIOS) will not get you a menu.
I *THINK* the GAR has a hidden bootstrap that does stuff at startup since if I hold the hotkeys at startup with the FDS BIOS, it will appear.
Instead of interrupting after hotkeys, I think it injects a JSR as the next instruction and then switches off the cart's ROM for it's own to get the return address. it also doesn't fumble up with IRQ games.
It detects whether RAM or ROM is in at least $6000-DFFF and whether or not it's CHR-RAM or ROM. The largest real time save file I could make was "44.5K" which was with the FDS BIOS, I think it's composed of 2K WRAM, 32K PRGRAM, 8K CHRRAM, VRAM, OAM and CGRAM and restore data. Some games without CHR RAM or WRAM make only "4.5K" save files, but others with CHR RAM or WRAM can make 16-20K files, I don't see the logic...
GAR must latch internally $2000, $2001, probably $2006 and maybe $2005. What else is necessary to keep a game working even if the restore frame is damaged?
It seems to record writes to $4018-$FFFF in a FIFO to keep track of bankswitching since restoring but not saving the state will usually break an expansion sound song. Does anyone have any info on this?
Does anybody know how the "game type" codes work? There are apparently many routines for different game types to do proper saves. It clearly has trouble detecting games though :)
It certainly polls $4016 into a shift reg, once it gets the hotkeys it does it's thing. Games which do not do anything with $4016 (FDS BIOS) will not get you a menu.
I *THINK* the GAR has a hidden bootstrap that does stuff at startup since if I hold the hotkeys at startup with the FDS BIOS, it will appear.
Instead of interrupting after hotkeys, I think it injects a JSR as the next instruction and then switches off the cart's ROM for it's own to get the return address. it also doesn't fumble up with IRQ games.
It detects whether RAM or ROM is in at least $6000-DFFF and whether or not it's CHR-RAM or ROM. The largest real time save file I could make was "44.5K" which was with the FDS BIOS, I think it's composed of 2K WRAM, 32K PRGRAM, 8K CHRRAM, VRAM, OAM and CGRAM and restore data. Some games without CHR RAM or WRAM make only "4.5K" save files, but others with CHR RAM or WRAM can make 16-20K files, I don't see the logic...
GAR must latch internally $2000, $2001, probably $2006 and maybe $2005. What else is necessary to keep a game working even if the restore frame is damaged?
It seems to record writes to $4018-$FFFF in a FIFO to keep track of bankswitching since restoring but not saving the state will usually break an expansion sound song. Does anyone have any info on this?
Does anybody know how the "game type" codes work? There are apparently many routines for different game types to do proper saves. It clearly has trouble detecting games though :)
kyuusaku wrote:
Bump. I fooled around a little with the GAR today and can conclude a few things:
It certainly polls $4016 into a shift reg, once it gets the hotkeys it does it's thing. Games which do not do anything with $4016 (FDS BIOS) will not get you a menu.
It certainly polls $4016 into a shift reg, once it gets the hotkeys it does it's thing. Games which do not do anything with $4016 (FDS BIOS) will not get you a menu.
Hmm very interesting things about the GAR. I've been wondering for awhile how it detected the mapper type and such, because it seemed to work really well for the games I tried it on (MMC1, MMC3, codemasters, other US games).
It will fully back up 8K of VRAM, since it worked OK on the codemasters games. What I had trouble with (and what will brick your GAR!) is multicarts or any mapper that uses the write address as a bankswitching element. For some reason, the GAR doesn't like it. Examples include multicarts and the action 52 and cheetahmen 2.
I tried tracing through the ROM a ways but it's an absolute mess. I did find where it jumped into RAM though, and that's how I made my GAR fixer/dumper. There's some "locks" on it you have to turn off to make RAM writable, for example.
Also, the stupid thing only has 32K of RAM in it, but was designed to hold up to 256K. I am still wondering how the menu comes up- They must be dual porting that RAM between video (probably only 1K or so for a basic CHR set) and the CPU so they can read stuff and write it to RAM. I'm not sure. Whatever they do, it's insanely complex, especially for the time period.
I suspect that the chip used in the device is designed for a famicom copier of some form, and was most likely one of the last ones to be built/designed.
Speaking of using copier chips, Naki's "gamesaver+" for the SNES is just a bung? copier chip in a device that only does real time saves for SNES. It's pretty neat and basically a simplified SNES copier inside. 256K of DRAM, the copier chip, and little else.
Right, the GMNFC 01 was designed for the Game Master copier which has 256K of DRAM for CHR; I am using this device, not a real GAR. The GAR is the equivalent of the Game Master Boy which is a scaled down Game Master. The motivation behind the real time saving was because in late 1990, copiers didn't have WRAM built in, they used the FDS adapter's DRAM for $6000-7FFF which didn't last a power cycle.
One thing about the GM is that you can use the real time save feature WHILE using the 256K as CHR ROM and 512K PRG ROM. I think the thing was meant to use FDS adapter resources like $8000-DFFF and CHR RAM for saving.
Does the GAR have a socket for another 32K SRAM? The GM BOY does.
One thing about the GM is that you can use the real time save feature WHILE using the 256K as CHR ROM and 512K PRG ROM. I think the thing was meant to use FDS adapter resources like $8000-DFFF and CHR RAM for saving.
Does the GAR have a socket for another 32K SRAM? The GM BOY does.
Does the GAR work with time-sensitive games like Battletoads? Also, how well does the GAR save the APU state?
kevtris wrote:
Speaking of using copier chips, Naki's "gamesaver+" for the SNES is just a bung? copier chip in a device that only does real time saves for SNES. It's pretty neat and basically a simplified SNES copier inside. 256K of DRAM, the copier chip, and little else.
Could such a thing be hacked to run homebrew ROMs?
Jagasian wrote:
kevtris wrote:
Speaking of using copier chips, Naki's "gamesaver+" for the SNES is just a bung? copier chip in a device that only does real time saves for SNES. It's pretty neat and basically a simplified SNES copier inside. 256K of DRAM, the copier chip, and little else.
Could such a thing be hacked to run homebrew ROMs?
Doubt it. You'd be better off buying a real copier. This thing's ROM is designed only for real time saves. One interesting but not unsurprising thing about it is that it doesn't save the SPC-700's RAM data, so music/sound won't be right.
The manual says you should get to the stage in question before restoring to make sure the music is set up properly or something. Been awhile since I read the instructions. It also has a (IMO) useless feature where you can load 6 AA cells in it to keep your game data saved for a couple hours. The manual said this was useful if you wanted to take the backed up game to a friend's house or something.
dvdmth wrote:
Does the GAR work with time-sensitive games like Battletoads? Also, how well does the GAR save the APU state?
Until you press the hotkeys, it's as if the GAR isn't there. Once you do it saves the state and returns to the game. Time sensitive games run without a hitch. It doesn't restore the game to the exact frame state though since it doesn't need to. AFAIK, it doesn't save the APU state at all, just the various RAM and $2000/2001; it just restores things that aren't necessarily upkept by the game every frame.
There are also 3 methods of slow motion which must be software driven, this might break Battletoads but I doubt it.
It has problems with some games at certain areas, but so far those problems have been in restoring CHR bankswitching (Akumajou Densetsu comes to mind), I've never had it lock up a game on me (I haven't tried using a multicart).
One thing it certainly can't simulate is bankswitched WRAM, so games which rely on this can't be saved correctly. Other than that it will work with MMC5 games, I think I have 8 of them and I've only noticed problems with WRAM related stuff.
kyuusaku wrote:
Does the GAR have a socket for another 32K SRAM? The GM BOY does.
Yep it does, I wonder what it would take to get it to use it if one were installed.
I don't think it will take anything, it should detect it.
I have the Game Master Kid--the prototype of the GAR. Kevtris dumped it for me a while back if anyone wants to look at the code. There is no way to access the menu, but it is actually programmed in there when you pick apart the code. Weird...if anyone could figure it out, that'd be pretty cool.
I think only two have been found (iirc, Wilson has the other, of course, heh), but Kevtris said he thinks at least 50 were made, due to the manufacuring process (wave soldering, iirc). Not sure where that logic comes from and I forgot to ask, but if you could explain that, Kev, that'd be cool too.
-Rob
I think only two have been found (iirc, Wilson has the other, of course, heh), but Kevtris said he thinks at least 50 were made, due to the manufacuring process (wave soldering, iirc). Not sure where that logic comes from and I forgot to ask, but if you could explain that, Kev, that'd be cool too.
-Rob