Started from r3188. @g0me3 please investigate. megaman3.nsf.zip

Screen from VS in debug mode

Someone else was trying to report this several years ago.

Clicking on the Hotkeys window crashes the emulator, making it exit the compiled source or freezing the 2.2.2 version in Software Manager.

R.C. Pro-Am II (U) [!].nes

CRC32: 03DB5562
MD5: F6277E4231D802A928BB72C1DADAD6FC
SHA-1: 8C68582BDAA32FBC8C7CD858991D4E00D3B1569C

Square 1 channel has wrong sound during game title

#51 added features that don't exist in the SDL?. I think the FCEUFILE* FCEUD_OpenArchive defines that were added to src\drivers\win\archive.cpp belong in src\drivers\sdl\sdl.cpp. That resolves my FCEUD_OpenArchiveIndex undefined compilation error but then I get errors in driver.h where candidate expects 3 arguments but 5 are provided.

src/file.o: In function `FCEU_fopen(char const*, char const*, char*, char*, int, char const**, bool*)':
file.cpp:(.text+0x3513): undefined reference to `FCEUD_OpenArchiveIndex(ArchiveScanRecord&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, int, bool*)'
file.cpp:(.text+0x3bb5): undefined reference to `FCEUD_OpenArchive(ArchiveScanRecord&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*)'
file.cpp:(.text+0x3c01): undefined reference to `FCEUD_OpenArchive(ArchiveScanRecord&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*)'

I'm working with software that uses fceux to play/read NSF files and I'm trying to write a CI/bash script to test it. Will I need to compile this program myself or is it available in package managers.

After adding a line, output console is instantly cleared: video

While reviewing the various mappers' WRAM initialization code for this pull request, I noticed that while WRAM seems to always be initialized by a board Init, it is not generally initialized by Power.

I found 3 exceptions, which explicitly initialize WRAM at Power if not battery backed. Not sure if these were motivated by past problems, though they do manage to cover a lot of games between them. There may be more:

1. MMC1: https://github.com/TASVideos/fceux/blob/master/src/boards/mmc1.cpp#L275
2. MMC3: https://github.com/TASVideos/fceux/blob/master/src/boards/mmc3.cpp#L282
3. N106: https://github.com/TASVideos/fceux/blob/master/src/boards/n106.cpp#L403

Since implicit WRAM is pretty common, and it appears that recording a movie from start only does Power, not Init, that it's easy to intentionally produce a divergent WRAM memory state from a movie. (E.g. open Super Mario Bros. and edit some hex values around $6000, record a movie, notice these values aren't kept.)

I don't know how severe this problem is in practice. I'm wondering if the 3 existing examples cover cases where it's come up before?

I am not sure if making movies that record from start Close and re-Init the cart would be appropriate, or if every mapper that has WRAM should explicitly check for no battery and initialize-- this is a lot of cases, but not horribly too much, and it could be an excuse to replace a lot of them with more generic shared WRAM code though.

Other option I guess is just ignore it and maybe it'll never come up, or take a long time to. Games with WRAM and no battery that have relevant lack-of-initialization bugs might be a very small set.

When I use the latest version of Virtua NES to run the B-Wings game in 168-in-1 (including B-Wings SID, etc.), there is no exception, but when I use the latest version of fceux to run it, it only shows the background and only plays BGM all the time.

PS: Non-manual translation.
168-in-1.zip

I have a use case where an automated system needs to process gameplay from an emulator as fast as possible. Is there a clear way to implement this kind of functionality? I've messed around with all the SDL driver code, but can't seem to get the emulator to run any fast than 60FPS.

As topic above

If I copy russian characters from hex editor encoding area while having english keyboard layout selected, I get garbage in my clipboard instead.

In order to get rid of this, I need to change keyboard layout to russian and only then it allows me to copy symbols properly. If I switch back to english layout, then also back to garbage.

It started from r3329

Games dumped off the Famicom Disc System come into two major types:

• .fds format: Most common format. Ubiquitous in ROM sets (GoodSets, No-Intro). Omits some checksum data.
• .qd format (stands for QuickDisk): Only ever used in official Nintendo re-releases. Almost identical to fds, but a full dump with checksum data. May omit padding.

The checksum data in question would be checked at BIOS startup to verify the integrity of the image and whether it was tampered with, in which case it will throw an anti-piracy error. As of now, no NES emulators support the alternate more complete dumps, as well as fudging that check's result to always return a negative. To emulate a .qd image, stripping the checksum data with a custom script is needed.

— Emulation General Wiki

See this script for more information:
https://gist.github.com/einstein95/6545066905680466cdf200c4cc8ca4f0

There have been no new releases since 2.2.2 while there are over 600 commits.

Any plan to push new releases (or just tags..)?

Thanks

If I get a breakpoint hit in debugger, or if I pause the game by pressing "step into" button in it, I'm not able to unpause emulator using "pause" hotkey after clicking at the main window. Something in this fe64ca3 version corrupts its function. The rest hotkeys seems to be ok, like "frame advance" or "open rom".

CHR-RAM should be write-protected on this board in bank modes 0 and 3

http://wiki.nesdev.com/w/index.php/INES_Mapper_015#Control_.28.248000-.24FFFF.29

so im using Linux Mint 19.1
I tried to install fceux2.2.3 but when i type in the command "scons" (as said in the README-SDL)
it states:
scons: Reading SConscript files ... platform: posix Checking for C library dw... no Checking for C function asprintf()... yes Checking for inflate in C library z... yes Checking for C library SDL... no Did not find libSDL or SDL.lib, exiting!

How do i fix that?

it works you can google up the error

If you try to add breakpoint and type "NMI" etc. this no longer works. It seems like someone was trying to be helpful and add character entry restrictions to these fields, but that breaks this once very useful feature.

Don't know when it happened, but will probably dig around later to find the change.

ok, now all updates just fine as usual. but then I'd like to request more, sorry ;)
is it possible to keep windows updating while "TURBO" is pressed?
this one is make me mad me sometimes. need to release turbo button to see if something changed and there are a lot of this sometimes. (also that reminds me that I must have been put another feature request about to make turbo button togglable not only pushable).

Beginning of Level 3, Jackal NES, $907C reads as $20 in the trace logger, but it is really $B0. stepping through confirms this, as well mesen's output is correct.

There is no Lua command to change frameskip at runtime. At least I could not find it in documentation nor in source code. I'm running some AI experiments and I'd like to add frameskip while in nothrottle mode and set it to 0 while in normal speed.

Environment: Windows 10 x64

Steps to reproduce:

1. Clear any existing files in the sav folder.
2. Launch FCEUX.
3. Open Legend of Zelda (may happen with other games, this just what I saw it on).
4. Open any other ROM file.

In the sav folder, a sav file (for LoZ) will be created under the name of the ROM from step 4.

The next time you load the game from step 3, it won't be able to locate the correct sav for that game because it was saved under the wrong filename.

I see this issue happens on build 0.0.0.116 (and later) but not on 0.0.0.115.

The behaviour of palette at $3F10, $3F14, $3F18, $3F1C and mirrors seems odd. They seem to be constantly full of $00 in the PPU memory view, and apparently can even be output to the screen by setting the PPU address to one of them while $2001 rendering is disabled.

These 4 should rightly be mirrors of $3F00, $3F04, $3F08, $3F0C. Not sure if the FCEUX behaviour currently has unique storage in these 4 locations, or if $4/8/C are mirroring $3F00?

Anyway, just making a note that this should be fixed. I might do it myself a little bit later. Does anyone see any potential problem with fixing it? AFAIK some PPU revisions don't even allow reading back palettes, so games are unlikely to rely on it (if this happens to affect reads and not just rendering / hexedit memory view), otherwise the change should be purely visual, I'd hope?

did you moved to new location ?

What does work:
Calling memory.writebyte(0x6878, 0xff); works just fine in an MMC1 title like vanilla Metroid.

What does not work:
Calling memory.writebyte(0x6878, 0xff); does not work in an SXROM-based variant of the game, the Zelda 1 / Metroid 1 Crossover Randomizer. The write (and others in the same range) simply fail silently.

It's possible the way the PRG-RAM banks are loaded/swapped somehow affect FCEUX's cheat engine.

I guessed at a fix which did work, but I am hesitant to create a pull request as I have no idea if my solution would have unintended side effects as I am unfamiliar with the codebase.

Where:
Function void FCEU_CheatSetByte(uint32 A, uint8 V) in src/cheat.cpp

Working change:

The check for the address A being in the CPU address space was copied to the top of the method to run first.

void FCEU_CheatSetByte(uint32 A, uint8 V) {
	if(A < 0x10000) {
		BWrite[A](A, V);
		return;
	}

   if(CheatRPtrs[A>>10])
    CheatRPtrs[A>>10][A]=V;
   else if(A < 0x10000)
    BWrite[A](A, V);
}

If you've heard of the Catalina Wine Mixer, macOS 10.15 is the Catalina Wine Killer.

macOS 10.15, due for release in September or October, will drop multiarch and instead run only 64-bit executables. As I understand it, Wine on a 64-bit-only system can run only those Windows executables that are compiled for x64 (x86-64, AMD64), not x86. How hard would it be to build FCEUX (debugging version) for 64-bit Windows? Or will it become recommended to debug games running in FCEUX SDL by debugging FCEUX SDL itself?

In the windows builds, I am able to open 7z archives and select the rom or fds image from a list. Why can't we do this on the linux builds too?

https://github.com/TASVideos/fceux/blob/a6219f50069c3632c2ae24bfdf43fb3d4e527ad7/src/boards/mmc3.cpp#L1118
https://github.com/TASVideos/fceux/blob/a6219f50069c3632c2ae24bfdf43fb3d4e527ad7/src/boards/mmc3.cpp#L1119

I'm having an issue with mapper 035, the nesdev wiki says it is a duplicate of mapper 209, but its not letting me use certain registers.

1: unable to set PRG-ROM bank type with register $D000, it's always set to 8kb chunks even if I set $D000 to either 8kb/16kb/32kb, it's always 8kb.
2: unable to swap out hard wired bank using register $8003.
3: unable to use register $D003 to access1 additional 512k PRG-ROM. It looks like because of the PRG-ROM only using 8kb chunks, it's unavailable?

I havent even begun to mess with the CHR, because I want to make sure everything else is working properly as i advance in learning the mapper usage. But if the nesdev wiki says 35 is a duplicate of 209, then i feel the FCEUX build i have (2.2.3) has mapper 35 functioning incorrectly.

-infidelity
NES rom hacker

I don't know how to write in c++, and I wanted to know if there is a way to have a modified version of mapper 209, to allow for wram usage? $D000's leftmost bit allows you to use $6000-$7FFF as ROM if the bit is set, but I would like to use it as WRAM/SRAM with that bit as 0. If I knew how to accomplish this on my own I would, this is the only feature I wish would work. I'm not looking to make/create repro carts, I simply want to use this for emulation. Thank you.

Hi,

The current FCEUX build (ver - 2.2.3) is using lua version 5.1.

Can we have support for latest lua version 5.3.5 ?

I tried replacing the lua5.1.dll and lua51.dll in the install directory of FCEUX, with the available lua53.dll, but not working (it keep on asking for lua51.dll).

Tried a clone and build for the first time since the migration to Git, and I ran into some problems (Windows).

1. Will not build until there is an scmrev.h in the vc/defaultconfig folder.

I discovered the make_scmrev.js script. When first running it, it crashed because I did not have a global install of Git in my path. After installing Git, I tried running it again, but it crashed again because I was running it from the wrong folder. Eventually discovered I had to run it from vc/ not from vc/defaultconfig/. After going through all these steps I was able to build FCEUX.

Could we maybe have a default scmrev.h already in the repository? Having to install Git globally (or at least manually creating a path for it) seems a very siginficant requirement for what looks like an unnecessary feature for anyone not trying to produce a public build with a revision stamp on it.

2. The build step runs BizHawk.Built.Tool.Exe which will crash because vc/svnrev_template.h is missing.

As far as I can tell, the result of this tool produces vc/svnrev.h which is not required by the build. The crash does not cause the build to fail, but produces a popup window with an error and some spam in the output on every build.

I was able to suppress the crash by copying svnrev_template.h over from a previous SVN repo I had on my hard drive, but it seems like this is a vestigial thing that has no function anyway? Should it be removed from the build step so it doesn't get in the way when it fails?

After addressing these two problems I was up and running. I tried to find documentation that might explain what to do early on but couldn't find any. (Previously with SVN I was always able to just download and build with no additional setup.) Not sure if this would need documentation if svmrev.h had a fallback, and if svnrev_template.h wasn't really required at all though.

NES Mapper 087 (found in datalatch.cpp) has no bus conflicts. However, after loading state, the bus_conflict variable suddenly is 1 instead of 0, breaking the mapper.

Edit:

Seems to happen only if:

• You played the US version of City Connection previously (CNROM Mapper with Bus Conflicts), and saved state, saving a 'BUSC' value of 1 into the savestate
• You loaded that state while playing the Japanese version of City Connection (overwriting the mapper's bus_conflict variable to the savestate's value of 1)
• You see the game crash, reset the game, play the game, and make savestates.

Came up with a workaround:

In file datalatch.cpp:

static void StateRestore(int version) {
	if (WSync != CNROMSync)
	{
		bus_conflict = 0;
	}
	WSync();
}

This forces bus_conflict to be correct and to disregard whatever value it read from the savestate.

edit again: Should the "Bus Conflict" flag even be in the savestate in the first place?

How can I convert .fm2 file subtitles to a .srt file that could be toggled easily?
.fm2 subtitles look like this:
subtitle 13000 I'm fond of the color-a-dinosaur running gag
subtitle 13300 So it was obligatory for this run
subtitle 13600 Human can use controller to color realtime

I want to translate fceux into Chinese , but I don't know how to do .

Thanks for the awesome emulator...

I am trying to control FCEUX externally (preferably from MATLAB), and the closest thing I was able to find is sending keystrokes to the emulator (for loading ROM, changing game speed etc.)
I searched the documentation and not able to find anywhere regarding my doubts -

1. Does FCEUX implements any COM interface via which I can control it through another program
2. Does FCEUS have any activeX control interface

I have posted a question on stackoverflow also - https://stackoverflow.com/questions/53664513/sending-control-signals-to-fceux-emulator-from-matlab

System info:
Alienware 17 r4
Intel Core i7 7820HK @2.9 GHz
16 GB RAM
Nvidia GeForce GTX 1070
Windows 10 1809

FCEUX versions affected:
2.2.2
2.2.3
latest git build

Within the last few days, I've begun having a problem with fceux, where as soon as I double-click on the fceux.exe to start the emulator, the fceux window opens, then it immediately closes. It didn't previously do this at all; it was working just fine, no problems at all. I don't recall having changed anything that might mess with it, and even the latest clean git build was having the same problem. Other emulators I have in the same parent directory all work fine, including jnes, which points to NES ROMs from the same directory that fceux points to. So I'm guessing it's not my ROM collection that's the problem here either. Am I missing something here that might shed light on this problem?

If I make a comment right after RTS line in debugger, and its length is 28 or more symbols in "name" field, trace logger really hates it. Took me a while to figure out what's wrong with my .nl files.

Here is a video with demonstration https://youtu.be/8FUcUsp20NU

Tested on current a84ccfe version.

Emulator freezes if it meets some specific conditions.

You need to add a symbolic debug name, which has exactly 28 symbols in "name" field and at least 1 symbol in "comment" field. Also you add some code above this comment. And then you scroll debugger up.

Here is a video with demonstration - https://youtu.be/Cs140Sir5iw

Tested on current version 388e10b too

I have some questions about the lua related libraries in FCEUX:

1. What is luaperks.lib and how is it obtained/built? Additionally, would it be better placed somewhere like src/drivers/win/lua/win32/ rather than vc/? Is there a 64-bit version?

2. Are the lua libraries in src/drivers/win/lua/ custom built, or are these from an official lua release?

3. What is lua51.dll? Official releases only seem to have lua5.1.dll. (Edit: for future reference, lua51.dll is in standard lua distribution only for up to vc12 but not vc14 or vc15, which was why I couldn't find its source.)

4. What is src/lua/ used for? There is a vcproj in there that seems to build a lua.lib, but it doesn't seem to be used? The source files here are included in the VC build, it seems, but are excluded from the build.

5. There's also auxlib.lib, which is mentioned in the main README but it doesn't seem to be included in the build. Does this have any current function? (Edit: I guess I meant auxlib.lua, there is no lib. Disregard.)

Is there anything else important to know about the lua stuff?

Three of the oversized TNROM games, namely:

• Final Fantasy X1 (Ch)[!]
• Final Fantasy X2 (Ch)[!]
• Final Fantasy X3 (Ch)[!] — this one uses another name for ROM

Those, on the latest git, show garbled graphics along with a grey screen. This is happening since the implementation of the hack for KT-008 Jncota games on MMC3.

The solution here is to use Mapper 224 code from libretro's fork of FCEUX (labeled as fceumm) and either use it as separate mapper or as a clone of MMC3 merged into the original code, but without mixing it with Mapper 4 code via hacks. This way, KT-008 based games will run on Mapper 224 and the three games above might return to their working state.

/bin/ld: src/fceu.o: in function FCEUI_LoadGameVirtual(char const*, int, bool)': /mnt/data/dev/fceux/src/fceu.cpp:421: undefined reference to archiveManuallyCanceled'
collect2: error: ld returned 1 exit status
scons: *** [src/fceux] Error 1
scons: building terminated because of errors.

issue started here: 5eb6cc3#diff-87958eb3baaa0d33eb8a1fcf168572a4

seem like archiveManuallyCanceled was something done for the windows gui only...

Playing on Windows 7 and happens with any game.
Sometimes I use the turbo option and when I release the button, the games freeze very briefly, but it doesn't happens every time.
I noticed that it happens less on Turbo Toggle but I not sure.
And is not just a millisecond thing, I would say it's at the two seconds mark, around that.

When dumping AVI with New PPU, messages such as "AVI recording started." and "Power On" appear in the AVI file. This occurs even if "Disable messages recording" is checked in File -> AVI/Wav. The message about movie playback ending does not appear in the AVI, however.

The message appears briefly after the encoder logo in this encode. Here's a screenshot from that encode that shows the problem.

step 1. play Kunio-kun no Nekketsu Soccer League (Japan)
step 2. play something on a rom that sets CartBW on 0x6000 but doesnt set up any PRG ram memory to map there (maybe a buggy mapper)
outcome: WRAM works
expected outcome: WRAM doesnt work.
explanation: PRG ram registers arent cleared between rom loads
possibly relevant note: step 2 was a NES 2.0 rom

I used latest fceux autobuild and tried to run simple lua script:

savestate.load(savestate.create(2))

It doesn't do anything (I created savestates in all slots for testing).

If you Load State while the emulator is paused due to a debug breakpoint, or using the Step command, the CPU Cycles displayed in the debugger and PPU position will be incorrect after the state is loaded, leading to incorrect behavior once the game resumes.

Old PPU immediately displays the scanline number that it was at when the state was loaded.

New PPU behaves slightly differently, it will display the correct scanline in the debugger right after the state is loaded, but will change to the wrong scanline once enough cycles have passed.

Edit: More specifically, it's not related to debugging, just related to loading state at a timestamp different than the beginning of a frame. The debugger is the usually way to get to a different timestamp.

It started from r3362. And I'm not talking about Forbit breakpoints.

A breakpoint blocks triggers of other breakpoints if all these are true:
1 - it is located above them in the list
2 - it is enabled
3 - its condition is not met
4 - its triggering CPU address includes an address where breakpoint below should trigger

An example:
I have a test ROM which loops infinitely in $8000-$FFF7 range.
dummy.zip

At $8010 I add an LDA $0100 instruction.
Then I add an Execute breakpoint for $8000-$8100 range with A==#10 condition. This breakpoint never triggers because its condition never meets.
Then I add a Read breakpoint for $0100.

Read breakpoint should trigger all the time because of the infinite loop, however that Execute breakpoint blocks the trigger while being enabled. If I disable Execute, then Read breakpoint triggers normally.

In versions older then r3362, there could be several triggers on the same instruction at the same time, for example if you add 2 Read breakpoints for $0100 and press Run after 1st triggers, then the 2nd one also pauses emulator instead of moving on with emulation.

Starting from r3362, only 1 beakpoint can be triggered at a time. I actually don't know which one is better. When several can be triggered, it shows you which one from the list have their condition met, but it can be annoying sometimes as well.

Also, r3363 contains an additional bugfix for 790 issue. I can't say if it important for my current issue (because I'm not a programmer), like will it still keep working independently if you revert r3362 or something, so check it out.

So i installed FCEUX normally, there were no errors.
the commands i used:
scons scons install
Since the rest is just optionall.
Now if i go and search for FCEUX i find a programm but when i try to open it nothing works.
Im on Linux Mint 19.1

Adding multiline comments via .nl file messes up text color below, and the first symbol doesn't appear in lower lines. I'm using latest build.

Building on ubuntu 18.04, witih g++, after commit fb1d489 I get the following error when running scons.

src/fceu.cpp: In function 'void FCEU_CloseGame()':
src/fceu.cpp:195:5: error: 'AskSaveCheat' was not declared in this scope
     AskSaveCheat();
     ^~~~~~~~~~~~
src/fceu.cpp:195:5: note: suggested alternative: 'savecheats'
     AskSaveCheat();
     ^~~~~~~~~~~~
     savecheats