I'd like feedback for this beta testing. It should be the public (final) version, but I must be sure there are no unexpected things.
Please, DO NOT spread it to the public domain!
Last update was on april 3rd 2015.
Code:
News for Release Candidate 4 (4/3/2015)
========================================
- iNES header info box is resized based on the board title string length.
- Rollback to Allegro 4.4.2 and recompiled.
News for Release Candidate 3 (3/31/2015)
========================================
- Added mapper 140 (Jaleco JF-11 and JF-14).
- Fixed mappers 9(MMC2),10(MMC4),79(NINA-03),113(NINA-06/SACHEN).
- Fixed upscaler 3x - scanlined and pixelated modes.
- Compiled with -static-libgcc -static-libstdc++ for compatibility.
- More cleanups and minor fixes.
TODO list:
* enable triple buffering in fullscreen without restarting the emulator;
* a bigger font for the GUI;
* switching the blitter shouldn't "flash" the screen;
* add more mappers..?
* ???
News for Release Candidate 2 (3/29/2015)
========================================
- Fixed mappers 9 (hack removed), 93.
- Fixed WRAM init/reset ($6000-$7FFF).
- Fixed custom palette loading.
- Fixed a couple of wrong argument types in header files.
- Fixed/updated color style selection in the GUI.
- Improved MMC3 IRQs (Mickey in Letter/Numberland ok).
- Adjusted mapper 64 IRQ (fixes Skull & Crossbones).
- Added MMC6 support (Startropics 1 and 2).
- Added PPU CHR open bus reads.
- Added option for disabling dirty header detection (DiskDude).
- By request, settings are now saved if you click "OK" in General settings.
- New color styles: Game Boy green/alt + shades, Navy Blue (Crayola).
- Reenabled detection of unofficial opcodes, instead of skipping them.
- Minor cleanups.
What's new for version 5.20 32bit (3/22/2015)
---------------------------------------------
- Removed all those gfx modes, prior to AUTO windowed or fullscreen modes.
- Removed video resolution setting from config file, now fullscreen mode always
use the desktop resolution, unless you change it in the GUI.
- Removed sprite evaluation at pre-scanline.
- Added screen blitter 4x size with interlaced mode.
- Added screen blitter 3x upscaler scanlined, pixelated and interlaced.
- Added video vertical retrace sync, _much_ smoother.
- Added various color effects like sepia, black&white, GameBoy and more!
- Added an option for signed or unsigned APU sound samples.
- Fixed mapper 69 for CHR RAM games.
- Fixed motion blur effect, no more stains in the game screen.
- Fixed VS palette setup.
- Fixed a bug assigning joystick buttons.
- Fixed PPU $2007 register, fixes the scorebar in Burai Fighter (U).
- Fixed WAV stereo sound recording (files had half size).
- Fixed palette selection/startup.
- Fixed palette entries $10,$20,$30 in #nesdev palette.
- Fixed a bug in the NMI timing.
- Fixed an obscure bug in the sprite evaluation code (overflow).
- Fixed OAM rotation (Sachen games/Tatakai no Banka (J)).
- Fixed file closing, another obscure bug.
- Option "Set savestate slot to 0 on RESET" is now saved in the config file.
- Optimized PPU bankswitching and pixel color generation.
- General fixes and minor revision in the CPU instruction set.
- Revised config file parsing in order to avoid a potential crash.
- Improved RAMBO-1 PPU IRQ (mapper 64).
- A few GUI and config changes, old rocknes.ini file is NOT recommended.
- Code cleanups, lots of partial rewrites, adjustments and usual optimizations.
Save state, then load state if frozen.
Zepper wrote:
Save state, then load state if frozen.
Level 2 frozen on me. There's no menu. So, I wasn't sure how to save/load. Also, I noticed a band of color on the left:
In addition, I hit Alt+Enter to go to full screen mode. It took over the entire screen, but the image stayed the same size, centered with black margins on all sides.
Any chance of a 32-bit build? I could test on XP (if you still support that -- if not, I understand!).
zeroone wrote:
Zepper wrote:
Save state, then load state if frozen.
Level 2 frozen on me. There's no menu. So, I wasn't sure how to save/load. Also, I noticed a band of color on the left:
In addition, I hit Alt+Enter to go to full screen mode. It took over the entire screen, but the image stayed the same size, centered with black margins on all sides.
You didn't read the docs. Oh well... give a try -
rocknes.txt has everything.
Sometimes I love to mix up the things... ^_^;; I can change the background and the sprite color styles, separately! Very cool.
What kind of feedback do you need? Accuracy, campatibility, usability, special features, something else?
When I ran the 32bit (i686) version on my Windows XP I got the following message:
RockNES.exe - Unable To Locate Component
This application has failed to start because libgcc_s_dw2-1.dll was not found. Re-installing the application may fix this problem.
OK
Maybe X and C should be the default buttons. Those keys are located on the same position on most keyboards around the world. This is not true of Z and X.
Bavi_H wrote:
When I ran the 32bit (i686) version on my Windows XP I got the following message:
RockNES.exe - Unable To Locate Component
This application has failed to start because libgcc_s_dw2-1.dll was not found. Re-installing the application may fix this problem.
OK
Points to
koitsu.
http://stackoverflow.com/questions/4702 ... is-missing
Shanghai displays some strange text behind the tiles:
Uh... could you be more specific?
Zepper wrote:
Uh... could you be more specific?
Except for the menu at the bottom, all that white text is not supposed to be there. The table top should be solid green.
Mapper 93. I had this info:
Code:
$8000-FFFF: [PPPP ...M]
P = PRG Reg (16k @ $8000)
M = Mirroring:
0 = Vert
1 = Horz
According to the wiki, it's "wrong"..??
Mapper 93 (Sunsoft-2 on 3R) definitely never supported H/V switchable mirroring...
Tried a bunch of ROMs with it, here's a few thoughts:
- program is always using 100% of a CPU core for me (does it never have an opportunity to sleep?)
- disksys.rom has to be placed in program folder, consider searching in the same directory as .fds file for it.
- lagrange point english patched version crashes program (regular lagrange point runs OK, without the extra sound)
- PAL battletoads doesn't appear to work (is there any PAL support?)
- consider saving settings to file immediately, rather than just on exit, in case of crash
- Startropics does not run properly (looks like the usual
write protected RAM issue)
- Of all the Famicom expansion audio chips, only VRC6 is working (this is the only one implemented so far, right?)
- often when I pause with Esc and switch to other windows, the NES image ends up disappearing (just becomes black), so it's hard to tell what I was paused on
Also, seeing the Allegro UI for the first time in many years brings back some memories. (I used to use Allegro around 1998 or so with DJGPP.)
rainwarrior wrote:
Tried a bunch of ROMs with it, here's a few thoughts
Here we go... ^_^;;
Quote:
- program is always using 100% of a CPU core for me (does it never have an opportunity to sleep?)
True, since Allegro's vsync() has no sleeping at all. I could modify it.
Quote:
- disksys.rom has to be placed in program folder, consider searching in the same directory as .fds file for it.
Ok. Next...
Quote:
- lagrange point english patched version crashes program (regular lagrange point runs OK, without the extra sound)
Only VRC6 is supported as extra sound. Hmm, I need to try out such version and debug it.
Quote:
- PAL battletoads doesn't appear to work (is there any PAL support?)
No PAL support, since official timing info is very vague and unsure in most of its context.
Quote:
- consider saving settings to file immediately, rather than just on exit, in case of crash
Good.
Next...
Quote:
- Startropics does not run properly (looks like the usual
write protected RAM issue)
Hmm... I'll check this out.
Quote:
- Of all the Famicom expansion audio chips, only VRC6 is working (this is the only one implemented so far, right?)
Yup, only VRC6 as expansion sound.
Quote:
- often when I pause with Esc and switch to other windows, the NES image ends up disappearing (just becomes black), so it's hard to tell what I was paused on
The program title bar brings such state info.
Thanks for the feedback.
It's nice release.
I have a couple requests:
- option to 2x/3x GUI size. GUI looks very small on native HD resolution.
- take back manual screen resolution selector in INI-file:
Force 640x480 resolution with 512x384 blitter looks interpolated on HD display.
Uncomfortable to select it manually every time.
I don't know how to load a bigger font in Allegro.
I request the autofire turbo buttons, of course.
z - B
x - A
a - turbo B
s - turbo A
Zepper wrote:
No PAL support, since official timing info is very vague and unsure in most of its context.
Vblank is lines 241 through 310 instead of 241 through 260, 3.2 dots per CPU cycle instead of 3, OAM not writable outside lines 241-260 even if rendering is disabled, different tables for noise and DMC periods (which are listed on the wiki). What else is unclear? Is it just the APU Frame Counter?
Quote:
Quote:
- Startropics does not run properly (looks like the usual
write protected RAM issue)
Hmm... I'll check this out.
When
NES 2.0 RAM size is 1024 bytes, or the mapper is 4 and the PRG hash matches StarTropics or StarTropics 2, emulate MMC6.
Zepper wrote:
I don't know how to load a bigger font in Allegro.
Try TTF2PCX and Allegro Grabber and Google
allegro 4 font. Should I dig up my old Allegro programs to show you?
Zepper wrote:
Quote:
- often when I pause with Esc and switch to other windows, the NES image ends up disappearing (just becomes black), so it's hard to tell what I was paused on
The program title bar brings such state info.
Not sure what you mean about the program title bar, but I couldn't see the NES screen, which makes it difficult to know what you're jumping into when you unpause. I can't seem to make this happen again today, though, I'm not sure what triggered the black screen before. Kind of strange, because it was happening to me a lot yesterday.
Also:
- Uchuu Keibitai SDF has corrupt graphics, probably something about MMC5 CHR is not emulated?
- in the file selection dialog, it would be nice if the letter keys could be used to navigate (e.g. B cycles through files starting with B)
- program often loses keyboard focus when using ALT+ENTER to return from fullscreen, seems to have something to do with whether I use the mouse when in fullscreen?
- managed to get the program to hang (i.e. unresponsive, but not crashed) while using the Esc menu, not yet able to duplicate (just something to watch for, maybe)
- items in ? menu appear in a native pop-up dialog, rather than an allegro dialog like everything else
- Esc menu has underlined letters indicating keyboard commands, but they only work if the mouse is over the menu itself (which overrides the keyboard command 1 frame later)
Uchuu Keibitai SDF is the only game that uses Split Screen, not emulated. -_-;;
I think the screen going black thing was just what happens after some of the dialogs close. Like, using the input config dialog blacks the screen when it finishes, not sure if anything else does it. Anyway, I think it was that, rather than something to do with switching windows. (Might have only been the input config?)
Oh, also is there a way to crop the top and bottom 8 pixels? A lot of NTSC games have junk at the edges that you wouldn't normally see on a TV.
Problems with Fire Emblem (MMC4):
To correct this issue, read VRAM, use the address to set the latches if necessary and then return the read value.
You appear to be setting the latches based on the address just prior to reading from VRAM.
zeroone wrote:
To correct this issue, read VRAM, use the address to set the latches if necessary and then return the read value.
You appear to be setting the latches based on the address just prior to reading from VRAM.
Uh... what? I didn't get it.
Zepper wrote:
Uh... what? I didn't get it.
The latches are potentially set based on the read VRAM address. But, a modified latch should only affect subsequent reads. Your emulator appears to modify the latches based on the address and then it applies the modified latches to the current VRAM read.
No clue. Here's some source code. Well, ppu->refresh is loopy_v, ppu->inc is the increment (1 or 32).
Code:
(...)
case 0x2007:
tempaddr = ppu->refresh & 0x3FFF;
if( ppu_is_rendering() ) {
_clock_y();
_clock_x();
} else {
ppu->refresh = (ppu->refresh + ppu->inc) & 0x7FFF;
}
if(tempaddr >= 0x3F00)
{
ppu->ReadLatch2007 = _ppubank_name_read((tempaddr>>10)&3,tempaddr&0x3FF);
return (*(ram_color+(tempaddr & 0x1F)) & ppu->set_bw_mode) | (ppu->Latch & 0xC0);
}
else
{
ppu->Latch = ppu->ReadLatch2007;
if(tempaddr < 0x2000) {
ppu->ReadLatch2007 = read_ppu(tempaddr>>10,tempaddr&0x3FF);
} else {
ppu->ReadLatch2007 = _ppubank_name_read((tempaddr>>10)&3,tempaddr&0x3FF);
}
}
} return ppu->Latch;
For MMC2/MMC4, read_ppu() should first read the current bank and then examine the address for trigger addresses ($0FD8-$0FDF, $0FE8-$0FEF, $1FD8-$1FDF, or $1FE8-$1FEF).
Why are read_ppu() and _ppubank_name_read() separate functions? Sunsoft Mapper 4 (
#68,
After Burner) and Konami VRC6 (
#24 and #26,
Akumajou Densetsu aka
CV3J) can map CHR ROM into nametables ($2000-$2FFF), and Namco 163 (
#19) and the
Magic Floor mapper (
#218) can map the nametable RAM in the Control Deck into pattern table space ($0000-$1FFF).
tepples wrote:
For MMC2/MMC4, read_ppu() should first read the current bank and then examine the address for trigger addresses ($0FD8-$0FDF, $0FE8-$0FEF, $1FD8-$1FDF, or $1FE8-$1FEF).
Why are read_ppu() and _ppubank_name_read() separate functions? Sunsoft Mapper 4 (
#68,
After Burner) and Konami VRC6 (
#24 and #26,
Akumajou Densetsu aka
CV3J) can map CHR ROM into nametables ($2000-$2FFF), and Namco 163 (
#19) and the
Magic Floor mapper (
#218) can map the nametable RAM in the Control Deck into pattern table space ($0000-$1FFF).
Because of my way of coding.
All those games you mentioned are supported & playable. So, the bug report relies in the mapper code, not the PPU code directly.
Problem with RAMBO-1 interrupts. See Klax (U) below.
The blue region shakes.
@zeroone
I didn't notice any shaking with Klax.
Mind you to share your PPU $2007 reads source?
EDIT: hmm... I fixed mapper 9 and PunchOut works fine. I can notice the difference of swapping banks before/after the tile fetching, but nothing regarding mapper 10. Yup, I fixed it based on the wiki info... but still glitched at right in dialog boxes.
Zepper wrote:
@zeroone
I didn't notice any shaking with Klax.
Mind you to share your PPU $2007 reads source?
I'm not sure what you are asking for exactly. Unfortunately, I'm not able to capture a video of the issue, but there appears to be an issue with the mapper.
In Skull & Crossbones (RAMBO-1), the player appears to float above the platforms (the feet should be in contact with the ground) and there are occasional horizontal lines that appear in various parts of the screen (such as the black line that passes through the clock and status bar at the bottom):
New version. Thanks a lot for the feedback!
Unfortunately, I couldn't fix mapper 10 (MMC4).
The method of latching/bankswitching seems to be different. PunchOut is much sensible if I do a certain change in the code; Fire Emblem no.
EDIT: found the problem with Fire Emblem. It's a limitation in my gfx engine. The bankswitching should occur only when PPU cycle AND 7 is 7 (at cycles 7, 14, 21, 28...). Otherwise, it occurs at every pixel.
Problem with mapper 079. See Double Strike below:
Also, I think either
the wiki for mapper 079 omits information or the rom files that I am testing with specify the wrong nametable mirroring. Just like mapper 113, I found that 0 = Horz and 1 = Vert. I'll do further testing to find out.
Edit: For the nametable mirroring, it looks like more recent dumps fix the issue. But, neither rom works properly in your emulator (see screenshot above).
Press F12 to take a screenshot.
Looks like another outdated mapper info... from the same source: Disch' docs.
Actually, the info I had is from mapper 113.
I fixed the mapper.
zeroone wrote:
Just like mapper 113, I found that 0 = Horz and 1 = Vert.
Double Strike's PCB does not support switchable mirroring:
http://bootgod.dyndns.org:7777/profile.php?id=1044
Zepper wrote:
If you don't want to have to distribute those libraries you'll need to compile it with: -static-libgcc -static-libstdc++
Zepper wrote:
Quote:
- often when I pause with Esc and switch to other windows, the NES image ends up disappearing (just becomes black), so it's hard to tell what I was paused on
The program title bar brings such state info.
I think he means it's hard to tell what he was paused on
in game. In other words, had Mario just landed right next to a Koopa, or is he safe?
cpow wrote:
Zepper wrote:
If you don't want to have to distribute those libraries you'll need to compile it with: -static-libgcc -static-libstdc++
Any other OS than Windows XP for such "special" version?
Yeah, I'd suggest just including the DLL in the archive (or give me a link to the one that I should be using that your program uses -- don't just link me some random DLL off the Internet!). You may need to include source code for it, however, I forget what the license is for that binary.
I'd honestly just suggest the emulator .zip/.rar/whatever having subdirs in it: x86 (for 32-bit) and x64 (for 64-bit). You could drop the DLL in x86, but maybe not needed in x64.
Sorry to make your life annoying, but there are still
a substantial number of us using 32-bit Windows OSes (I'm assuming "Windows XP" there is all 32-bit; 64-bit XP is quite uncommon). Don't let Tepples try to convince you otherwise. ;-)
I'm no more supporting the x64 version - too many problems with Allegro. So, I'll continue with the 32bit x86 at anyways. ^_^;;
Release Candidate 3 is out. Thanks a lot for the feedback! ^_^;;
Check the 1st post/page.
I tried Release Candidate 3, but I still got this error on my Windows XP:
Bavi_H wrote:
RockNES.exe - Unable To Locate Component
This application has failed to start because libgcc_s_dw2-1.dll was not found. Re-installing the application may fix this problem.
OK
I read online that this DLL is part of MinGW. I happen to have MinGW installed, but I don't have any of its folders in my PATH environment variable. I can get these errors about missing DLLs to go away by doing either of the following:
- Add the MinGW bin folder to my PATH environment variable.
OR- Copy libgcc_s_dw2-1.dll and zlib1.dll from the MinGW bin folder into the RockNES folder.
But this feels like something normal users shouldn't have to do.
I was surprised no one else is getting this error. Does everyone else already have these MinGW DLLs installed and in their PATH?
That's odd. Those 2 flags
should remove gcc DLLs, but they're not. Hmm, even zlib requests ZLIB1.DLL. Linker has the "-lz" flag.
Waiting for some help...
Zepper wrote:
That's odd. Those 2 flags should remove gcc DLLs, but they're not.
What are these flags you using? And what version of GCC ("gcc --version")?
EDIT: how do you compile your files (makefile)? Notice that ''-static-libgcc" and "-static-libstdc++" flag should be passed when linking, not when compling different *.c/*.cpp files:
Code:
g++ -c test.cpp
g++ -c test2.cpp
g++ -static-libgcc -static-libstdc++ test.o test2.o
Zepper wrote:
Hmm, even zlib requests ZLIB1.DLL. Linker has the "-lz" flag.
Try "-static -lz" instead
Code:
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I use
Orwell's Dev-Cpp++ to compile my emulator + MinGW gcc. Yup, those flags (-static-libgcc -static-libstdc++) are used in the linker.
I installed Dev-C++ to test and when I selected compiler (MinGW), it automatically enabled these options in Tools -> Compiler Options (see pic). Do you have the same settings?
Yes.
Regarding the ZLIB1.DLL, I believe that "-llibz" is the static library (libz.a).
I have two versions:
- v1 (w/ icon in the program bar) was compiled with Dev-Cpp.
- v2 (no icon in the program bar) was compiled using the command line prompt.
Tell me the differences, please. ^_^;;
Zepper wrote:
I have two versions: [...]
Tell me the differences, please. ^_^;;
On my Windows XP, both v1 and v2 say libgcc_s_dw2-1.dll was not found.
Does anyone else have the same problem? If I'm the only one with the problem, could there be something wrong on my computer?
Is there any chance you downloaded the MinGW build of Allegro 4.4 instead of the MSVC build?
I don't care what compiler flags you're using -- the reality is that the resulting executable is still dynamically linked to certain DLLs by name. Things like -llibz are the wrong syntax anyway (you meant to say -lz -- the "lib" part you do not specify).
As for real-world experience:
1. RockNESv1.exe dynamically links to alleg44.dll (which is available in the .rar on the first page), and also to zlib1.dll (which I do not have). Therefore the program does not run for me due to missing DLLs. The application icon for this binary appears as the earth/world.
2. RockNESv2.exe dynamically linked to alleg44.dll (which is available in the .rar on the first page), and also to zlib1.dll (which I do not have). Therefore the program does not run for me due to missing DLLs. The application icon for this binary does not appear.
None of these DLLs should be installed system-wide for an emulator. They should function just fine if placed into the same directory as the executable.
Get familiar with *IX tools like ldd or dumpbin /imports for Win32 (this is a Visual Studio utility) or "Dependency Walker" from Microsoft (a.k.a. depends.exe).
The syntax of link-time commands I've been seeing spit out in this thread so far look wrong (for example during link time I do not see any sort of executable being referenced with -o). Please do not "play around" with "random compiler/linker flags" unless you know exactly what they do and what your intended goal is.
PLEASE REMEMBER: there is nothing wrong with a program referencing DLLs vs. including everything statically. Instead, you simply have to provide the DLLs with your program (e.g. how alleg44.dll is included). However, you need to make sure that the license of the software the DLLs use permit being distributed in a pure binary form -- some which are GPL, for example, require that you include the source code with them, or that you print somewhere visibly every time the program is run where the person can download the source code (not necessarily to your entire program, but just to that binary/DLL).
- The Allegro library is under the "Giftware" license, a non-copyleft license that I understand to be equivalent in effect to the license of zlib.
- libgcc and libstdc++ are under GPLv3 + GCC Runtime Library Exception, which weakens the copyright so long as GCC itself was not modified in a GPL-incompatible way.
And zlib1? I believe zlib itself has different licenses depending on which version you're using. The "1" does not necessarily tell me jack squat about what version is being used.
Are we going to sit here and do this, one DLL at a time? That seems like a time vacuum.
koitsu wrote:
And zlib1? I believe zlib itself has different licenses depending on which version you're using.
Source?
My source says nothing about the use of different licenses for different versions of the software.
Quote:
The "1" does not necessarily tell me jack squat about what version is being used.
The "1" means it exposes version 1 of the API.
Well,
v1 was compiled with Dev-Cpp and
v2 out of Dev-Cpp environment. Both versions use
-static-libgcc -static-libstdc++, which are
NOT fixing the missing DLL problem. Now, an easy question -
is this problem still in previous versions, like 5.14???Regarding the copyright part, I don't mind
as far as I'm NOT modifying the original source. If there's a problem, let me know and I will give you the sources... if that's the case.
Ay anyway, please, let's get focused on the DLL problem - no copyright discussion for now, or we have to get a cup of tea, staying in my chair.
I cannot confirm that either of those flags are fixing anything because I'm missing non-libgcc-related DLLs.
Bavi_H states that he gets libgcc-related DLL errors, but, quote: "Does anyone else have the same problem? If I'm the only one with the problem, could there be something wrong on my computer?"
I'd like to try and verify his problem on my own XP workstation, but cannot until the zlib1.dll situation is rectified. So, where is the zlib1.dll that was used alongside RockNESv1.exe and RockNESv2.exe?
And in the meantime, what does depends.exe list for dependent runtime DLLs for both of those executables? (That is for Zepper to deal with, not us)
I just looked, and RockNES.exe actually
doesn't need libgcc_s_dw2-1.dll, it's alleg44.dll that request it (Note that zlib1.dll that comes with MinGW also needs libgcc_s_dw2-1.dll).
You can download allegro dll that doesn't require libgcc_s_dw2-1.dll here:
https://www.allegro.cc/files/?v=4.4. In the archive, there are 'md' versions of dll that require it, and 'mt' that not. Allegro-4.4.2-mt.dll renamed to alleg44.dll seems to work fine.
Actually, I suggest you to go easy way and just include libgcc_s_dw2-1.dll and zlib1.dll with RockNES.
EDIT: By the way, bug report: RockNES seems to crash on my PC randomly (Error at 0x77C372E3 - that's memmove function in msvcrt.dll, and it's trying to read/write incorrect memory)
1. Testing on YueFeiZhuan
When load the game, your emu only show the cursor.
nintendulator0970bin_unicode.png is right.
rnes520i686RC3.png is what your emu display.
FC87_SDL-0.1.2-Windows_x86(Unreleased).png is what I emu display.
2. Ask for advice
I am very curious about your MENU(or UI) 's implement. Today, I still don't find a way to
add menu to libSDL.
As you seen, FC87_SDL-0.1.2-Windows_x86(Unreleased).png is no menu.
P.S. YueFeiZhuan Mapper is 15. Details see
http://wiki.nesdev.com/w/index.php/INES_Mapper_015
koitsu wrote:
Bavi_H states that he gets libgcc-related DLL errors, but, quote: "Does anyone else have the same problem? If I'm the only one with the problem, could there be something wrong on my computer?"
I'd like to try and verify his problem on my own XP workstation, but cannot until the zlib1.dll situation is rectified. So, where is the zlib1.dll that was used alongside RockNESv1.exe and RockNESv2.exe?
Just to clarify: I was beginning to get concerned because others were happily reporting bugs with various NES games in RockNES, and nobody else was saying anything about having to manually copy DLLs into their RockNES folder to get RockNES to even run. Now that Koitsu has said he's also getting error messages about DLLs not being found I'm no longer worried it's a problem on just my computer.
All of the RockNES versions posted in this thread that I've tested* have the same DLL problems on my Windows XP computer. I need both libgcc_s_dw2-1.dll and zlib1.dll to get RockNES to run:
1. When I extract the RockNES files and run the RockNES exe, I get an error that libgcc_s_dw2-1.dll isn't found.
2. If I add libgcc_s_dw2-1.dll to the RockNES folder, then I get an error that zlib1.dll isn't found.
3. Once I also add zlib1.dll to the RockNES folder, then RockNES will run.
I'm copying the DLLs from my MinGW bin folder. (I already had MinGW installed for a previous project.)
* Here are the versions I've tested from this thread:
Code:
Download Title bar
================== ======================================
rnes520i686.rar 5.20 32bit - Mar 22 2015, 11:43:20
rnes520i686RC2.rar 5.20 RC2 32bit - Mar 29 2015, 18:32:50
rnes520i686RC3.rar 5.20 RC3 32bit - Mar 31 2015, 23:17:18
RockNESv1.rar 5.20 RC3 32bit - Apr 1 2015, 20:28:16
RockNESv2.rar 5.20 RC3 32bit - Apr 1 2015, 18:48:57
Zepper wrote:
Well, v1 was compiled with Dev-Cpp and v2 out of Dev-Cpp environment. Both versions use -static-libgcc -static-libstdc++, which are NOT fixing the missing DLL problem. Now, an easy question - is this problem still in previous versions, like 5.14???
I just found your website now. I tried the two most recent versions on your site, RockNES 5.142 and RockNES 5.13d, and they have no missing DLL error messages.
Please, get alleg44.dll from RockNES 5.142 and see if there's still DLL errors.
Code:
Filename Source Verison
=========== ================== ======================================
A. RockNES.exe rnes5142.zip 5.142 - Jun 2 2014, 00:27:15
B. RockNES.exe rnes520i686RC3.rar 5.20 RC3 32bit - Mar 31 2015, 23:17:18
X. alleg44.dll rnes5142.zip 4.4.2.0 (from File Properties)
Y. alleg44.dll rnes520i686RC3.rar 4.4.3.0 (from File Properties)
A + X: No missing DLL errors.
B + X: Missing zlib1.dll first. Missing libgcc_s_dw2-1.dll second.
A + Y: Missing libgcc_s_dw2-1.dll.
B + Y: Missing libgcc_s_dw2-1.dll first. Missing zlib1.dll second.
Zepper wrote:
Please, get alleg44.dll from RockNES 5.142 and see if there's still DLL errors.
That version of alleg44.dll is working fine and doesn't require libgcc_s_dw2-1.dll.
Some other notices:
1. alleg44.dll you providing (both versions) seems to be debug version (it's about 3 megabytes), which only needed for debugging purposes. For end-user, you can supply non-debug version of dll, which is smaller (about one megabyte). By the way, where did you get that alleg44.dll which is version 4.4.3.0?
2. Use Dependecy Walker (
http://www.dependencywalker.com/) so you can see dependencies of dll and exe files.
3. If you do not want to use zlib1.dll, you need static version of libz.a. Download zlib source code here:
http://zlib.net/zlib128.zip, then compile it (unpack it to some folder, then in command prompt, change directory to that folder and type '
mingw32-make -fwin32/Makefile.gcc'). You will get 'libz.a' and 'libz.dll.a' files compiled. Delete 'libz.dll.a' - it's version that uses zlib1.dll. The other file - 'libz.a' is static library that you need for linking. You should put it into directory where your old zlib library was and
delete all other zlib files that was there, so linker don't accidentally use old files.
4. I mentioned that RockNES crashes randomly on my system (while calling 'memmove' function). That seems to be happening only sometimes when I move mouse. When mouse is still, everything is fine and there are no crashes. Perhaps there are some bugs involved with mouse moving or mouse cursor displaying code in RockNES?
Firstly, thanks A LOT for your feedback.
The problem
is Allegro 4.4.3 (SWN version), which I modified it to compile with gcc x64 (yup, the original developers have my modifications), but for some reason, I had problems. The solution is to go back to Allegro 4.4 public version and recompile everything in x86 (32-bit).
It wasn't so easy, but I guess I did it. I had to include -static-libgcc -static-libstdc+ in a file named links.txt in order to remove that DLL dependancy from Allegro library.
I can confirm your changes work for me: RockNES RC4 opens without any missing DLL errors on my Windows XP.
About that crashing issue (when moving mouse) I described earlier - it turns out that it's bug in Allegro and/or DirectDraw, not in RockNES.
deeplinks wrote:
About that crashing issue (when moving mouse) I described earlier - it turns out that it's bug in Allegro and/or DirectDraw, not in RockNES.
I rollback to Allegro 4.4.2 in order to avoid all my changes in 4.4.3 (SWN) - as I said, I had problems with 64bit compiler ~ the mouse was much much slower if the program had crashed.
Well... waiting for feedback of annoyances or broken mappers. Thanks guys.
I gave this a quick try and my first question is, is there a reason you have this "DOS-look" of your menus and filerequester?
Personally I find it pretty confusing with a program that uses a design that differs alot from the OS that I'm running.
oRBIT2002 wrote:
is there a reason you have this "DOS-look" of your menus and filerequester?
The look was inherited from GEM on the Atari ST. Allegro was originally for the ST until it was ported to DOS and then other platforms.
Well, it's stated in the main page of the wiki:
Quote:
Before considering developing your own NES emulator, ask yourself if your efforts may be better spent helping out those who already have emulators in development!
About the menu, well...
a) I'm too lazy for DirectX programming.
b) Allegro library is my reference (and it'll always be).
c) Nobody has offered help to improve my emulator.
d) ...?
For some reason, the menu style is a huge problem. It keeps away a lot of people just because it's not a Windows-looking-standard (is this correct, tepples?).
One thing you can do to fix up the look of your menus is to load a proportional font and install that as Allegro's system font.
Personally I am a little bothered with GUI's that doesn't meet modern guidelines (for sometimes no obvious reasons) but hey, that's just me.
If I was limited in this aspect, not being able to use the standard Windows-look-and-feel I would perhaps go for a totally different kind of GUI that enriched the experience in some other way to attract users.
Anyway, cool to see that you're still active coding on your emulator. You've been doing it for quite a few years now? I started A/NES (for AmigaOS) in 1997 and I'm still checking out the code from the time to time, I'm starting to feel pretty old..
oRBIT2002 wrote:
Personally I am a little bothered with GUI's that doesn't meet modern guidelines (for sometimes no obvious reasons) but hey, that's just me.
If I was limited in this aspect, not being able to use the standard Windows-look-and-feel I would perhaps go for a totally different kind of GUI that enriched the experience in some other way to attract users.
Anyway, cool to see that you're still active coding on your emulator. You've been doing it for quite a few years now? I started A/NES (for AmigaOS) in 1997 and I'm still checking out the code from the time to time, I'm starting to feel pretty old..
I'm active since 1998, or 17 years for this emulator. ^_^;; Well, I don't mind about the GUI, but what matters is the emulation accuracy.
Mapper 090 issues:
Zepper wrote:
@Zepper I'm also experiencing difficulty implementing mapper 090. Can you describe how you are using the nametable registers?
Edit: Nevermind. I think I solved it. Thanks anyway.
I added TURBO mode for the 4 buttons. ^_^;; It was hard to figure out a effective method, but I guess it's ok. Just a note: you can enable/disable turbo for a certain buttom, but NOT mapping a separate key for it.
Now moving to the next task - triple buffering without having to restart the emulator. It's possible, since the gfx mode already brings a flag indicating if triple buffering is supported. So, the setup occurs after the gfx mode, and not before it.
It's already fixed, thanks.
The status bar at the bottom of the screens in Flintstones, The - The Surprise at Dinosaur Peak! (USA) shakes.
1. Bug in GUI:
Rocknes 5.20RC4 doesn't remember "Vertical Retrace Sync" option selected by GUI.
You must set "-use_vertical_retrace 1(0)" manually in RockNES.ini to enable(disable) it.
2. Custom resolutions request:
Forced 640x480 resolution with original blitter 2 (unstretched 512x480) looks
VERY NICE on 16:9 displays.
I've tested it on 1366x768 laptop and 1920x1080 desktop.
The display does interpolation with stretch (like TV), so output image looks better than any existing rocknes blitters.
So, you need to select *insert your preferred resolution* again and again in GUI. This is really uncomfortable.
Or you need to change RockNES.exe properties via Windows compatibility menu to force 640x480 mode.
This is better, but only 640x480 is avaliable.
