It is currently Mon Dec 18, 2017 2:17 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: My emu ^^
PostPosted: Tue May 31, 2005 11:03 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
I just thought some of you might like to take a peek at my emu ^^. I haven't 'officially' released it (and I actually requested that people not redistribute it) because, let's face it, there's a million emus out there already. But it was great fun making it and I figured some of you guys might be interested in checking it out and providing some feedback =)

http://www.geocities.com/disch_/SchpuneBeta.zip --- Binary (win32)

http://www.geocities.com/disch_/NESEmu_src.zip --- Source (a bit more recent than the binary -- but not by much)

Copy/paste of basic features:

Basic feature lists:
- savestate support (typical 10 slot system like most emus have)
- basic fastforwarding capabilites (with configurable hotkey -- put it on your gamepad!)
- soft IPS patching on file load
- .pal files can be associated with individual roms
- sound channel panning/inversion techniques similar to those found in NotSo Fatso
- sound channel options can be saved as presets and can be associated with individual roms
- not crappy movie support. Savestates can be saved/loaded during movie recording to record cheatish movies. movies won't lose sync (I don't know why some emus have a real hard time with that)
- various graphics filters (Hq2x, 2xSai, Super Eagle, Super2xSai)


Supported Mappers (with some example games)
0 (Super Mario Bros. - Ice Climber - Balloon Fight)
1 (Final Fantasy - Legend of Zelda - Castlevania 2 - Megaman 2)
2 (Castlevania - Megaman)
3 (Solomon's Key)
4 (Super Mario Bros 2, 3 - Megaman 3-6 - Crystalis - a million other games)
5 (Castlevania 3 - Just Breed - Uchuu Keibitai SDF)
7 (Battletoads - Marble Madness)
9 (Mike Tyson's Punch Out)
10 (Fire Emblem)
11 (Crystal Mines)
24 (Akumajou Densetsu)
26 (Madara - Esper Dream 2)
66 (Dragon Power)
69 (Gimmick! - Batman: Return of the Joker)
71 (Mig 29 Soviet Fighter - Fire Hawk)

FME-07 sound supported (Gimmick!)
MMC5 sound supported (Just Breed)
VRC6 sound supported (Akumajou Densetsu, Madara, Esper Dream 2)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 01, 2005 7:44 am 
Offline

Joined: Wed Feb 09, 2005 9:31 am
Posts: 418
On the advanced movie support, I was wondering if it would be possible to not have save states, but instead just have really accurate and flexible movie support which basically always records a redo-able and undo-able computation log. Save states would just be indices into a log. Such a thing would allow for seemless modes; play, fast-forward, rewind (undo the log, one instruction at a time), and pause. Play and fast-forward would have both non-interactive and interactive modes so you could play a movie and press an action button at anytime to start interactively playing at that point in the movie.

So you could unify movies, save states, movie fast-forward, and speed throttle, while at the same time adding new features such as a "Prince of Persian Sands of Time" rewind. Not to mention the fact that having a computation log that can be rewinded would be great for debugging. Rewind to a few seconds before bug, then interactively play, then rewind again, etc... until you figure out exactly what is happenning in your ROM. Of course, to be really useful there would have to be a way to manage branches in the log, because rewinding and then interactively playing or interactively fast-forwarding would make new log data. You could overwrite the old stuff that comes after that point, but to have the same power as save states you would need managable log branching.

Besides the complexity of implementing this, there is also the problem of keeping the log data small enough that it can be written to disk during play without interrupting performance. Also, log data would always grow, so it would either have to have such a low bit rate that hours and hours of log data was just a few megs on disk.

Another interesting option would be to only automatically keep a computation log of the past 10 minutes of gameplay and keep a computation state (save state) at the beginning of that 10 minute window. That would make for a far more flexible save state mechanism from the gamer's point of view. It would be the end of the circular queue of quick-saves, as effectively the emulator is automatically quick-saving after every instruction, with a circular queue big enough to record the last 10 minutes of gameplay. Your emulator wouldn't necessarily have to support computation "undo"-ing, as long as it was fast enough to redo all instructions in the log from the last save state 10 minutes ago up until the N - k instruction where k is the rewind parameter. But it would have to be really fast to get a smooth rewind feature because rewinding N instructions would take on the order of N^2 time: ( N - k ) + ( N - (k-1) ) + ...

Or you could just have an emulation core that supported undo-ing, which would make for the smoothest rewinding even for extremely large logs.

If you have ever played the new Prince of Persia games, the ones with the sands of time, you can imagine what such a log system would be like. If you muck up something in the game, just rewind it until a point that lets you do it right. Such a save state system is far more user-friendly and fun than the traditional discrete save state system. The speed demo community would love such a feature :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 01, 2005 11:56 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7320
Location: Chexbres, VD, Switzerland
Had you try Final Fantasy ? When I tried it, it usually didn't start at all, and when it starts, all the sprites are messed up. But, the BG is okay, and the $2001 effect you'll get when you light an orb is correctly emulated, congrats !

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 01, 2005 12:10 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
I've tried both "Final Fantasy (U).nes" and "Final Fantasy (J).nes" several times and had zero problems. Perhaps you've got a wacky ROM dump? (it would have to be pretty wacky though).


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 01, 2005 12:42 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7320
Location: Chexbres, VD, Switzerland
Ah, actually I hacked it to use mapper 2 instead so I could gain PRG space to insert my own routines instead. So this could be the reason why it wouldn't works (do you emulate SRAM on mapper 2 ?). But that's not the whole problem because the hacked FF2 witch uses mapper 2 works fine.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 01, 2005 1:36 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Bregalad wrote:
Ah, actually I hacked it to use mapper 2 instead so I could gain PRG space to insert my own routines instead.


Mapper 2 (UNROM / UOROM) is capped at 256k PRG (at least that's my undestanding). If you expand, my emu will still swap in the last 16k of PRG to $C000, but when you swap PRG, it will only take in the low 4 bits of the value written (so you won't be able to swap to anything above the 256k mark).

Also -- I dont' check for bus conflicts like I should. Try running your hack in Nintendulator and see what kind of errors it spits at you -- it'll probably complain a lot (something tells me you're not swapping properly -- call it a hunch).

So yeah -- it just sounds like your hack broke the ROM =/. Doesn't seem to be a problem with my emu.

Quote:
(do you emulate SRAM on mapper 2 ?)


I was really torn because I don't think there is SRAM on UNROM/UOROM -- but I ended up putting it there anyway -- mainly because of that stupid FF2 hack (though I'm seriously considering going back and removing it). Currently, the only mapper which lacks SRAM on my emu is mapper 0.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 02, 2005 3:54 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Why not let the iNES header battery bit decide whether you enable SRAM or not ? I mean for mappers that normally don't use WRAM.

Jagasian: rewinding like in Prince of Persia would be very cool indeed, but I think the NES is too complex for that to implement easily. An array of savestates made each second would be more feasable than real-time (per instruction) rewind. I'll give that a try in my test emulator (the very 'simplex' chip8 ;p )


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 02, 2005 10:24 am 
Offline

Joined: Wed Feb 09, 2005 9:31 am
Posts: 418
hap wrote:
Jagasian: rewinding like in Prince of Persia would be very cool indeed, but I think the NES is too complex for that to implement easily. An array of savestates made each second would be more feasable than real-time (per instruction) rewind. I'll give that a try in my test emulator (the very 'simplex' chip8 ;p )


You could use save state deltas. Let me post the rest of this discussion in a separate thread, so that I don't steal this current thread:
http://nesdev.com/bbs/viewtopic.php?p=2213
Suffice it to say, if you want something to set your emulator apart from the rest, this might be the killer feature :wink: Other emulators try to include unique features. For example, there are emulators that make the high scores non-volatile for many games. I remember being disappointed that my high score was lost whenever I turned off Paperboy. Again, that feature is also just another intelligent use of state recording.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 02, 2005 2:12 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
I was looking the DirectX sound stuff... WHOA, quite confusing! :( I'm years far of that... :|

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 03, 2005 10:34 pm 
Offline

Joined: Thu Jun 02, 2005 11:44 pm
Posts: 10
Location: Wisconsin, USA
Will check it out, thanks

edit:

Not sure why, but it doesn't seem to want to play nice with my PlayStation controller unless I turn on the analog feature. Otherwise the control config goes all goofey on me.

I've gone through reboots and recalibrations in control panel etc, and can't seem to resolve the issue


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 04, 2005 8:32 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
some PSX adaptors have weirdness with the Z-axis when you push a button. Someone on IRC was having a similar problem. I've been meaning to redo the input config anyway... maybe make it so you can have several buttons mapped to one controller button.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 04, 2005 11:06 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7320
Location: Chexbres, VD, Switzerland
Yeah, my hack doesn't run fine on nintendulator, beacause SRAM is not emulated at all on mapper 2 (the modified FF2 doen't work too), but the intro and the "new game/continue" screens shows proprely, after that, it will show the generic again and again. Also, the sprites are correctly shown. I thing emulating SRAM on mapper 2 is needed, just because of this modified FF2. If anyone try to play to FF2 with your emulator, it'll just delete it because it wouldn't work 8) . Personnaly I did this just to gain many PRG space in order to insert my own routines (sta $fff9, lda #$00, rts; is shorter than sta $fff9, lsr A, sta $fff9, lsr A, sta $fff9, lsr A, sta $fff9, lsr A, sta $fff9, rts. Also, the others MMC1 regs initialisation isn't needed (they're just initialised once in Final Fantasy, so I changed the init code a bit, and it may be why it doen't start on your emulator). May be odd, but I did just that to entertain myself and not to publish my hack or something.

I think that Hap's idea isn't bad. When mapper 2 is detected, check for the SRAM bit. If clear, emulate UNROM / UOROM with bus conflics and witout SRAM. If set emulate a pseudo-MMC1 that would be able to run FF2, witout bus conflics and with SRAM.
By the way, I noted that there is also a hacked Hanjuku Hero with mapper 2 instead of MMC1, but the games does change the mirroring when you summon an egg monster (so it's not compatible with mapper 2). Also, the japaneese Dragon Quest 2 uses mapper 2, and the US Dragon Warrior 2 uses MMC1. I ask myself if it's also a hack, or if the japaneese is an actual UOROM board (because SRAM bit is clear).

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 04, 2005 11:54 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Well, see my position is I'd rather not break my emulator to play broken games. Little hacks to get broken games working (like hap's idea) is a really big 'no-no' in my book. As far as I'm concerned, if the ROM dump is bad, I'm not going to waste time messing up my emu to work around the problem -- I just won't use the bad ROM. If all emus were strict, there wouldn't be all these problematic broken ROMs floating around -- but since most emus let ROMs get away with little cheats like this, it makes emus which do things properly not look so hot. So I'll try to resist the problem rather than add to it.

From that standpoint -- adding SRAM to mapper 2 in the emu is seeming more and more like a bogus idea -- especially because of only one ROM which is already broken (I doubt it keeps bus conflict in mind when PRG swapping). I probably will take it out of my emu when I start working on it again. There is a working, MMC1 FF2 translation floating around which does everything proper. If people want to play FF2 they can use the good ROM. I don't want to break my emu so that they can use a broken ROM. =P

I checked DQ2 and it does in fact appear to be a legit UNROM game. No SRAM; it uses a password system rather than saving data (that must suck for playing, those passwords are huge).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 04, 2005 12:08 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7320
Location: Chexbres, VD, Switzerland
If you want it so.
That's right, there is also a translation "Final Fantasy 2 (J) [T-Eng].nes" instead of "Final Fantasy 2 (J) [hM02][T-Eng].nes", the [hm02] looks like to mean that the mapper 1 has been turned into a mapper 2. Does someone know what does this [hM02] mean ? Dragon Quest 2 is definitely a true UNROM game, is uses VERY large passwords, (his info is confirmed on http://www.dqshrine.com). But, there is apperently also a hM02-ed version of Dragon Quest 3, wich is MMC1 (I'll check it out). I understand now why Dragon Quest 3 was mentionned at the bottom of the "mapper 2" part of the FireBug's doccumentation, with Final Fantasy 2.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 04, 2005 2:18 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
Disch wrote:
Little hacks to get broken games working (like hap's idea) is a really big 'no-no' in my book.

Then would the following mapper work (call it "FF2E-UNROM" for UNIF)?

Start with UNROM
plus circuitry to avoid bus conflicts (like the difference between AMROM and ANROM)
plus SRAM support

Or should only mappers that have been realized in a piece of extant hardware receive a UNIF board name? On that note, how hard would it be to hack SRAM and bus conflict cleanness into an existing 74*161 based board?

And yes, "hM02" in GoodNES means "hacked to run on a board whose bankswitch logic resembles UNROM". The various "hFFE" mean "hacked to run on a Front board".


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group