Super Famicast SRAM compatibility
-
- DCEmu Super Poster
- Posts: 1337
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Mon Mar 28, 2005 10:26 am
- Has thanked: 0
- Been thanked: 0
Super Famicast SRAM compatibility
Hi. I'm a complete and humble n00b to these forums.
I wish to make a suggestion for Super Famicast.
Anyway, here goes.
What would be cool is if Super Famicast was compatible with DreamSNES SRAM. that way, those of us who are switching over from DreamSNES wouldn't have to start all over again.
I wish to make a suggestion for Super Famicast.
Anyway, here goes.
What would be cool is if Super Famicast was compatible with DreamSNES SRAM. that way, those of us who are switching over from DreamSNES wouldn't have to start all over again.
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
Nice! I feel that we should be IMing all this but I'm always afraid my boss will come by and catch me.
Of course I'll help you out with the menus. NesterDC SE is on the home stretch, really. I just need a few more solid coding sessions. Of course, that could be a month! Doh. Must focus. Must not play PSP.
Of course I'll help you out with the menus. NesterDC SE is on the home stretch, really. I just need a few more solid coding sessions. Of course, that could be a month! Doh. Must focus. Must not play PSP.
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
There's definitely games that are still screwy. The ones that I wish worked the most are the KOEI games... Nabunaga's Amibition, Romance of the Three Kingdoms, etc.. Those run fine but have horrible graphical problems.
One nice thing about fixing compatibility is that you can do it all via a PC build with real debugging! Whoohoo. I have a VS6 project that uses the same core Nester source files that the DC build does and renders it with SDL. It's how I fixed the compatibility thusfar. I'll give you that if you're really up for it.
One nice thing about fixing compatibility is that you can do it all via a PC build with real debugging! Whoohoo. I have a VS6 project that uses the same core Nester source files that the DC build does and renders it with SDL. It's how I fixed the compatibility thusfar. I'll give you that if you're really up for it.
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
Oh, and there are definitely some open source emus with better compatibility than Nester but just not as fast as the tweaked NesterDC is. I think Nestopia is supposed to have the better compatibility overall, but it's also slow; written all in C++. But it might be perfect for troubleshooting.
The way I debugged it, is I would have two VC++ projects open, the NesterDC one and the latest NesterJJJ one. I would log the CPU state (opcode, registers, and sometimes SRAM) to a file. To make the file smaller and minimize IO, I would make a CRC based on the CPU state. That's what I would log along with the execution count. I would do it for both versions of Nester. Then, using a diff program, I would find at which clock cycle the CRCs started to differ.
Then I'd go back and debug both simultaneously, breaking a clock cycle or two before the troublesome cycle. I would just follow very carefully.
For games that didn't show differences until they got in the game, I would programmatically code controller input so that the start button was pressed at exactly the same time, every time. That helped with fixing Battletoads.
Doing this, I uncovered little bugs in certain opcodes that clearly happened from Takayama's optimizing.
There are probably some games with graphical glitches that I could have fixed with the same method if I generated the CRC from video ram as well. But the KOEI games are also graphically broken in NesterJJJ. So we need to look to other emus. But I know the emulation state matching like I was doing before probably will not go as easily as it did.
Another emu will most likely do something slightly different in one area but achive the same ends. Also, if I was to do the CRC state thing, on stuff like video ram, I'd have to make sure that it's initial contents are the same and things like that.
I never debugged an emu before this and that state matching was the best I could devise without the inner understanding of the NES harware like most emu authors have. I mean, I definitely could not write an emu from scratch at this moment in time.
The way I debugged it, is I would have two VC++ projects open, the NesterDC one and the latest NesterJJJ one. I would log the CPU state (opcode, registers, and sometimes SRAM) to a file. To make the file smaller and minimize IO, I would make a CRC based on the CPU state. That's what I would log along with the execution count. I would do it for both versions of Nester. Then, using a diff program, I would find at which clock cycle the CRCs started to differ.
Then I'd go back and debug both simultaneously, breaking a clock cycle or two before the troublesome cycle. I would just follow very carefully.
For games that didn't show differences until they got in the game, I would programmatically code controller input so that the start button was pressed at exactly the same time, every time. That helped with fixing Battletoads.
Doing this, I uncovered little bugs in certain opcodes that clearly happened from Takayama's optimizing.
There are probably some games with graphical glitches that I could have fixed with the same method if I generated the CRC from video ram as well. But the KOEI games are also graphically broken in NesterJJJ. So we need to look to other emus. But I know the emulation state matching like I was doing before probably will not go as easily as it did.
Another emu will most likely do something slightly different in one area but achive the same ends. Also, if I was to do the CRC state thing, on stuff like video ram, I'd have to make sure that it's initial contents are the same and things like that.
I never debugged an emu before this and that state matching was the best I could devise without the inner understanding of the NES harware like most emu authors have. I mean, I definitely could not write an emu from scratch at this moment in time.
- Syd
- Insane DCEmu
- Posts: 181
- Joined: Tue May 04, 2004 7:45 pm
- Location: Newfoundland, Canada
- Has thanked: 0
- Been thanked: 0
Two words: Mystery Quest! I know I've bugged you enough about it but it's one of my favourite games! It runs perfect in NESten (which was coded in C I believe) and runs good but with some messed up sound in Nestopia (which is written in C++). Right now there are 2 reasons I still have to fire up my NES from time to time: Mystery Quest and light gun games. If you ever fix that then you will be my new god!There's definitely games that are still screwy. The ones that I wish worked the most are the KOEI games... Nabunaga's Amibition, Romance of the Three Kingdoms, etc.. Those run fine but have horrible graphical problems.
- Quzar
- Dream Coder
- Posts: 7497
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 9 times
- Contact:
o_O !!
wow. well, i was thinking more along the lines of skimming through code to find differences in certain routines and making changes then testing them =P. maybe implementing unimplemented mappers or something, i guess i just dont know about working on emulators at that level.
i guess since you know so much bout the debug i could ask you: how would i find out what my program was doing right before a lock? I have a single game that locks up at the same time always, so i was hoping there was a way i could force the DC to tell me the stack atm or something like that. its relatively far in so id rather not have it continuously print debug info.
wow. well, i was thinking more along the lines of skimming through code to find differences in certain routines and making changes then testing them =P. maybe implementing unimplemented mappers or something, i guess i just dont know about working on emulators at that level.
i guess since you know so much bout the debug i could ask you: how would i find out what my program was doing right before a lock? I have a single game that locks up at the same time always, so i was hoping there was a way i could force the DC to tell me the stack atm or something like that. its relatively far in so id rather not have it continuously print debug info.
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man