Greetings, I am one of the developers of the coming FCEUX2.0 release. FCEUX is the official FCE Ultra project. The release merges all the tools/features of the FCEU rerecording branch (FCEU.28) and FCEUXDSP.1.07 as well as some brand new features.
The problem is that none of us use the debugging tools of FCEUXDSP, so no one is testing/bug fixing/enhancing features. So, I am asking if anyone here is interested in testing/coding. If so, throw me a PM (or post here).
Also, I am very interested in any ideas/features/bug fixes related to debugging tools and/or that would help with ROM Hacking.
Hell yeah! New FCEUXDSP/Rerecording goodness! Now I won't need to keep both files sitting on my hard drive.
Oh yeah, when I hit my laptop's volume control keys, FCEU Rerecording gets confused, and treats it as if a bunch of emulator controlling keys were pressed, pauses playback, then outputs very choppy sound for the rest of the time it runs. Maybe it needs better code to ignore certain shift combinations.
Don't forget "FCEUXDSP CE", the version for people who want a 'text hooker' like feature to autotranslate Japanese games.
Dwedit wrote:
Don't forget "FCEUXDSP CE", the version for people who want a 'text hooker' like feature
"Text hooker"? Is that a
call girl who uses
SMS?
Hmm, volume key messes with emulator, I'll try to look into that.
FCEUXDSP CE? acronym overkill. But no, I had never heard of it. I'll check that out.
I won't even touch "text hooker"
EDIT: the text hooker looks pretty neat, that would be a cool thing to merge.
I couldn't find the src though. Can I get a link?
one thing i'd like to see is have breakpoints take 24bit addresses so you don't get hits on every address that happens to map to the same spot.
never-obsolete wrote:
one thing i'd like to see is have breakpoints take 24bit addresses so you don't get hits on every address that happens to map to the same spot.
We already fixed the debugger to display the bank that is mapped into the address. I like your suggestion and sounds like a good next step.
But NES CPU addresses are 16bit long, not 24... ^_^;; 0000-FFFF
When you set a breakpoint, you may want it to trigger only when a particular page is mapped into memory at that address.
You also need to consider whether the memory is ROM or not, and if the memory is bankswitchable. If you're hacking some hypothetical game that has bankswitchable SRAM and stores code there, you'd need to be able to have the breakpoint target the correct memory.
I think the fceux internals are a bit jumbled and mapped rom banks is all that is easily achievable!
Dwedit wrote:
When you set a breakpoint, you may want it to trigger only when a particular page is mapped into memory at that address.
YES. You have no idea how long I've wanted a feature like that. It seems half the time I set a breakpoint, it ends up triggering in the wrong ROM bank every single frame, or worse. >_<
Being able to set a breakpoint directly in the .NES file would be super-duper awesome.
Fx3 wrote:
But NES CPU addresses are 16bit long, not 24... ^_^;; 0000-FFFF
...which is why bankswitching exists in the first place. He's proposing the 24-bit breakpoints exactly because different banks can be mapped to the same addressable space (not at the same time), but you most likely only want a breakpoint for one of them. Breakpoint addresses accompanied by a bank number, or NES file breakpoints would allow that.
BMF54123 wrote:
Being able to set a breakpoint directly in the .NES file would be super-duper awesome.
What if the debugger could dump and reload its list of breakpoints? Would that be satisfactory?
What if you could name each breakpoint, to remember what it is there for?
Not satisfactory enough, When you stick a breakpoint at one palace, then hit Run, you don't want it to stop at some other bank. I've seen it happen a LOT.
Oh. Perhaps he meant to set the breakpoint in terms of the .nes file address. That's more or less what it is going to be, but it displays it in terms of 16k chunks.
I thought he meant to save the list of breakpoints into the nes file or something bizarre like that.
Quote:
But NES CPU addresses are 16bit long, not 24... ^_^;; 0000-FFFF
alright then a 16bit address with an 8bit bank index. is it pronounced
tomato or tomato? it's all the same to me.
-multiple hex editor windows open at the same time
-being able to set breakpoints on a certain scanline/pixel
Games may switch PRG in sizes of 8K instead of 16K, how can you be sure it will work correctly for those games?
That is an interesting question. I am open to suggestions. What do you think is the best way to address banks? Are there any mappers that can switch in both 8k and 16k? If not, then I could pick based on the mapper. But would that be confusing?
Do you think it would be better always to address banks in 8k blocks? Therefore something that mapped .NES address 0x004000 to CPU 0x8000 (maybe 8k bank 2; or maybe 16k bank 1) would show addresses like
02:8000
02:9FFF
03:A000 (.NES address = 3*0x002000 = 0x006000)
Then you would have the same display and addressing system for every NES game, but the banks would no longer correlate to how the mapper is being operated.
Is it more important to you to have data reflect the mapper/logical bank settings, or to reflect the .NES file address?
I suppose you could also have this, if you didnt mind the verbosity:
//shows the corresponding .NES address for every CPU address
[004000]:8000
[004001]:8001
or
//shows the corresponding bank address for every CPU address
//this way we dont have to make a rule for converting bank addresses to bank numbers
[004000]:8000
[004000]:8001
[006000]:A000 //because this game uses 8k banks
FCEUX2.0.1 released. Like mentioned before, this is a combining of FCEUXDSP1.07 and FCEU.28 rerecording.
It offers the functionality of XDSP with numerous enhancements.
Improvements over XDSP:
*Ability to pause emulation via a mappable hotkey
*Frame advance (especially useful for use with debugger)
*RAM Filter - double clicking a possibilty will send it to Memory Watch
*Memory Watch - a dialog for monitoring several disjunct ram addresses (and save to a file).
*Input movie recording
*Input display
*Lag Counter (monitors when the game is polling for input)
It also breaks mapper 3 games with huge CHR ROM sizes.
Dwedit wrote:
It also breaks mapper 3 games with huge CHR ROM sizes.
Do you mean huge as in 64-128 KiB (Panesian games), or bigger than the biggest commercial CNROM clone?
I specifically mean mapper #3 Lolicatgirls.nes with 1024KB of CHR ROM. I can clearly see that it's capping mapper 3 to 32KB of CHR ROM.
this will be fixed for 2.0.2.
Thanks for reporting this; however, I am more likely to fix bugs if you post them through official channels to ensure that I find out about them.
Also, as far as I know, FCEU has always had this problem with its cnrom mapper. In general, FCEU codebase has many limits which put caps on rom sizes which represent the limits on known commercial roms. However, since we want to encourage FCEUX's personality as the hacker's choice technical emulator: I am finding these limits as they are reported, documenting them, and removing them.
FCUEXDSP never had any problems with CNROM games with huge CHR size, only the new FCEUX.
(now there's an acronym-filled post that nobody outside this board can read!)
You are right; i stand corrected. It would seem that the XD fceus have different mapper code than the other branches; which is different still than what FCEUX has (perhaps FCEU-mm made some architectural changes to the mapper system and that is what we're using, since FCEU-mm has tons of active development going on within the mapper code)
The lineage of the FCEUX mapper code is hard to trace sometimes. I have no clue where some of it came from. Whats there now seems pretty good to me, though, generally, so if anyone ever doubts that we've chosen the right branch of mapper code then let's talk about it.
I think mapper 163 is buggy.
"San Guo Wu Shuang - Meng Jiang Zhuan" resets to the title screen during gameplay.
The crash is fixed for 2.0.2 by upgrading to cah4e3's latest code.
There is graphical corruption in the title screen and intro cutscene due to issues with these mappers which havent yet been resolved.
I'm curious, does anybody still use this here?
I've found the Lua scripting ability can have some uses:
However, I seem to recall some people from here (?) disliking it, so...
When it stops making my computer explode when I change my laptop volume, I'll use FCEUX more often.
Eh. Audio in general is kind of buggy, I've noticed. Hopefully they fix it soon.
YouTube video of my Valkyrie no Bouken script in action
I probably should've enabled the "HP auto-refills" segment when I recorded that. Whoops...
Enabling Vsync makes the sound all fuzzy on my system. Changing the latency might fix it, but they disabled that option "until config system change"...
So, I guess they're redoing the config system, but why'd they have to break the existing one in the meantime?
BMF54123 wrote:
Enabling Vsync makes the sound all fuzzy on my system. Changing the latency might fix it, but they disabled that option "until config system change"...
So, I guess they're redoing the config system, but why'd they have to break the existing one in the meantime?
This question could be not on topic but I would like to know if that emulator had issues while trying to set it in full screen mode?
I was trying to test it in full screen and it never worked properly. Was it working before or it was always like that?
I don't recall ever having issues with FCEU's fullscreen mode, except when I tried to set an ancient video mode that my fancy new video card couldn't handle (usually 8bpp). I haven't tried it with FCEUX yet, though.
BMF54123 wrote:
I don't recall ever having issues with FCEU's fullscreen mode, except when I tried to set an ancient video mode that my fancy new video card couldn't handle (usually 8bpp). I haven't tried it with FCEUX yet, though.
ok. Hmmm... Could be my settings then. I tried to be in full screen mode but it was not working 100%. Since I have to write some japanese, I always have the IME active. The IME was always on top and some other windows too.
I was playing with the code just to see if I could have done some kind of screen saver out of it (message from another thread, I find the idea cool I would love to have one).
Right now I'm blocking with the direct-x code so I don't know if it's the way they made it that make the IME shows or not. I may decide to try to do that screen saver project some day with another emulator if I can't find the solution.
For now that's a very low priority project so I don't mind much
Thanks for the info.