Hmm... I found a problem.
I don't know how this version decides how much sound to output, but I found that if the machine has heavy load for a moment, the sound starts breaking and the emulator may even completely forget to produce sound.
I mean, I just ran Shatterhand in the emulator, and started a "make clean" in other console, and the emulator went mute. No sound data was generated anymore. (Not a mixer problem, but really no data was generated to the sound output).
Removing the C3 byte fixed the problem.
Therefore - the famtasia24060.zip has been updated again.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
it seems to me like famtasia has a few running problems, at least in xp pro
the mouse is, i think, emulated by the program, rather then letting windows do it (it wont do middle button mouse click).
it will accept and process keystrokes, even if the window is not the active window.
i also downloaded the .exe posted earlier here, for the 60 fps patch, but that one sucked hard. the mentioned adjusting time i have no problem with, but it continously tries to adjust speed, and acts very oddly and unresponsive... i discarded it and reverted back to the old version.
also it kinda sux that you cant bind speed changes to a key :) i rather run some unavoidable cutscenes at 150% then 50% or 75%... ohwell
btw is that project still being worked on? i noticed the last release was 2003'ish...
oh right, i dont hate everything ;)
i like that quicksave saves the recordpoint while recording, and the bind to restart from the last saved record point :)
btw is that project still being worked on? i noticed the last release was 2003'ish...
Which project?
Famtasia is not developed. The author lost the source code.
We are not affiliated with the Famtasia author. Blip is just a hacker genius :)
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
he lost the source, ouch that sucks
i know you werent, but i was just curious if we were to expect any fixes/updates for the problems idea's i mentioned above... but i guess not, unless the debugger gives you that much power (which i doubt :p)
ohwell
Ill just wait until a final version comes out. The one currently out does not work for me. When I load the game, it goes VERY slow, and I can barely move the mouse. When I put it on 999% it just crashes, even though I have a very good machine. Oh well.
Joined: 4/11/2004
Posts: 155
Location: Fairfax, VA, USA
Bisqwit wrote:
I mean, I just ran Shatterhand in the emulator, and started a "make clean" in other console, and the emulator went mute. No sound data was generated anymore.
Sound has been behind a *lot* of the observed problems. Famtasia has this nasty habit of locking up until a sound buffer has been freed. Therefore it must be very careful to output the exact number of samples per second required, or else it will either glitch (not enough samples written), or lock up (too many samples written). The C3 byte at $30010 disables the routine that Famtasia uses to wait for a free sound buffer, which will avoid lockups but allow sound glitches. To make matters worse, I think different machines behave different ways when sound glitches happen. For example, I can't reproduce your problem on my machine.
This particular problem might be related to this:
sub eax, edx
jg .positive_interval
mov eax, 1
.positive_interval:
Basically, if the timer misses its target, set sets the next timer 1 millisecond away in an attempt to "catch up". Unfortunately, this can cause problems with the sound (too many samples per second).
Bisqwit wrote:
it also includes my patch which should remove the heaviness-problem of 240 scanlines.
I don't think you've mentioned this before... I'm curious; what is it?
Joined: 4/11/2004
Posts: 155
Location: Fairfax, VA, USA
It seems to me the problem is something like this:
On Windows machines, if the c3 byte is not at $30010, then Famtasia is prone to locking up sometimes (for example, trying to run at 999% ExecSpeed with Occupation=1).
On Linux machines, if the c3 byte *is* at $30010, then Famtasia sometimes becomes mute and doesn't recover (for example, if the CPU is too busy).
After thinking about it for a bit, I think this is a solution:
// disable the routine that polls for a free sound buffer
{ 0x30010, 1, "\xc3" },
// check that the sound buffer is free before attempting to play sound
{ 0x2ff6e, 0x16, "\
\x8b\x0d\x3c\x23\x47\x00\x8b\x04\x8d\x40\x24\x47\x00\xb2\x01\x84\x50\x10\x74\x7f\xeb\x1f" },
Bisqwit, would you mind testing this as seeing if it works for you? Like I said, I couldn't reproduce the problem on my machine.
After thinking about it for a bit, I think this is a solution:
// disable the routine that polls for a free sound buffer
{ 0x30010, 1, "\xc3" },
// check that the sound buffer is free before attempting to play sound
{ 0x2ff6e, 0x16, "\
\x8b\x0d\x3c\x23\x47\x00\x8b\x04\x8d\x40\x24\x47\x00\xb2\x01\x84\x50\x10\x74\x7f\xeb\x1f" },
Bisqwit, would you mind testing this as seeing if it works for you? Like I said, I couldn't reproduce the problem on my machine.
On Windows machines, if the c3 byte is not at $30010, then Famtasia is prone to locking up sometimes (for example, trying to run at 999% ExecSpeed with Occupation=1).
I see what you mean. I used a C3-less patch and had mingw compiling on background and tried to run Rockman at 200% speed (occupation=1, 230 MHz laptop). The emulation halted.
So either way, something is screwed.
I'll test the newest solution.
Famtasia is not developed. The author lost the source code.
:( I agree with foxy, that is a saddening day for nesvideo freaks!
I will say though this (seemingly) random byte-patching is a wonderful way to tweak your favorite emu.
Bisqwit wrote:
We are not affiliated with the Famtasia author. Blip is just a hacker genius :)
I concur, Blip is a hero for us all. :)
I'm trying to get ahold of an original Famtasia 5.1 EXE without success.
Also, I'm trying to compile the various hacks and I can't seem to make them patch on winXP. can it be done using the GUI, or does it have to be command-line? I know some byte-patching needs to be done in the latter.
Oh, I forgot... three cheers for Blip.
After thinking about it for a bit, I think this is a solution:
// disable the routine that polls for a free sound buffer
{ 0x30010, 1, "\xc3" },
// check that the sound buffer is free before attempting to play sound
{ 0x2ff6e, 0x16, "\
\x8b\x0d\x3c\x23\x47\x00\x8b\x04\x8d\x40\x24\x47\x00\xb2\x01\x84\x50\x10\x74\x7f\xeb\x1f" },
This one seems to do nothing but crash if I check the "max speed" checkbox and run the game.
I've been using the C3-less patch now for a long time without problems.
I use DrawFrame=1, Occupation=1, AutoFrame=0, Benchmark=0, FullSpeed=0 and vary the ExecSpeed between 5..900 very successfully - no problems.
People at Mkakikomitai (Morimoto's BBS) are apparently complaining of some problems with the patch I use, but I don't understand what problems they are having.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
i'm thinking about creating a whole new emulator with 60fps recording capabilities and better/preciser record and replay options... but its not possible to add support for fmv if i would, is there?
i read something about emulators not being compatible with eachother...
i'm missing options like stepping frame by frame and adding a keypress/release per frame, while playing.
i believe this would be quite helpfull for speedrunners like on this forum, to make perfect runs.
also some better support with playback (not having to run the whole video if you want to continue at the end when restarting the client for instance.)
but anyways, can i make it compatible with fam?
these binary hacks are kind of unreliable without the source... imo (and i mean unreliable in function, not virii or anything)
Joined: 3/21/2004
Posts: 32
Location: the Netherlands
qFox wrote:
i'm thinking about creating a whole new emulator with 60fps recording capabilities and better/preciser record and replay options... but its not possible to add support for fmv if i would, is there?
i read something about emulators not being compatible with eachother...
Well, that's not because they are inherently incompatible. It's just that the authors didn't implement compatibility. If you're going to write your own emu, you can support the format (assuming the format is either straight-forward ,well documented or investigated by blip ;-), though it may require some serious hacking (hence the blip remark ;-).
Writing a proper emulator is one of my short-termish dreams, but I'm still just a beginning programmer and I've only just started learning some assembly (which is rather useful for writing an emu). It's not easy and takes a lot of time, but if you're up to it and actually do it, I'm sure many people here will be more then happy to help you in some way or another.
Creating a movie-compatible emulator requires that you know exactly how the emulator emulates the system.
This means things like number of cycles per screen refresh, number of scanlines, vblanks etc.
I don't know all details but I know they're many and debated.
The actual movie format is insignificant.
Famtasia movie format looks like this:
144 bytes of header; data
Header has: FMV^Z at 0, flags (32 bits) at 4, rerecord count (32 bits) at 8,
emulator name (64 bytes) at 16, movie name (64 bytes) at 80.
Data is: 1 byte per frame. Byte has 8 bits corresponding to the states of 8 buttons: R,L,U,D,B,A,SE,ST, starting from least significant bit.
No savestates, no screenshots, no end tags.
I don't know the flags format or how FDS commands are expressed.
FDS commands (if applicable) and second controller (if applicable) are probably interleaved somehow.
Joined: 4/11/2004
Posts: 155
Location: Fairfax, VA, USA
Bisqwit wrote:
This one seems to do nothing but crash if I check the "max speed" checkbox and run the game.
Then I like Phil's idea of having separate Windows and Linux binaries. The Windows version should have the C3 byte at $30010... I'd like to fix it the "right" way, but I don't have a Linux box available to test against.
Edit: The most I can understand from the Morimoto BBS is that people are complaining about the CPU lock-up on Windows. The C3 byte should fix that.
Joined: 4/11/2004
Posts: 155
Location: Fairfax, VA, USA
qFox wrote:
but anyways, can i make it compatible with fam?
Bisqwit is totally right about the timing needing to be precise. Check my post here. I found that for some games (like Batman), the difference in emulation causes a desync between movies made in Famtasia and VirtuaNES.
Your emulator could have a "Famtasia compatability" mode, where it would copy the emulation used by Famtasia exactly. It would be tough, but you might be able to rip the emulator core directly out of the Famtasia binary and use it as-is.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
well i looked around (google is your friend), and there is ALOT of high detailed information on the NES. take this site for example: http://nesdev.parodius.com/
i was thinking of creating a nes cpu emulator (its a modified 6502) and a frontend GUI. then simply running the code on it as it is in the roms.
sounds very easy when i put it like that, but thats basicly what i had in mind.
oh, the project, would it ever start, would be opensource, but i would focus on a windows-release. anyone can port if he or she desires and i'll give the help i can, but i dont plan on doing double releases myself.
let me make clear that i dont know when i'll start, or if ever at all. i have a ton of work to do already, but i think this community is missing an emulator that allows you easy and precise keypress editing.
oh and btw... my platform would be Forth (thats Forth, not Fortrain!).
well Forth and assembly if i need it.
