Version 1.017 (windows build only) is out.
ChangeLog:
1. Added Dendy support as requested by Eugene.S. May not be perfect, but at least the comparison examples he provided seemed correct. Feedback welcome.
2. Fixed square channel sweep emulation bug pointed out by Jarhmander. Thanks!
3. Reduced threading overhead. Emulation engine now stops mid-frame if enough APU samples have been accumulated, rather than going to the end of the current frame.
Thank you. Dendy timing is correct.
But the APU behavior is so strange.
Journey to Silius (U) - i don't hear DPCM
Battletoads & D.D (U), Alien 3 (U), Choujin Sentai - Jetman (J), etc - incorrect noise and squares
Overlord (U) also has "interrupted squares" in all modes.
Version 1.018 (windows build only) is out.
ChangeLog:
1. Fixed Dendy mode Noise and DMC LUTs.
Still looking for the root cause of this one:
Overlord (U) also has "interrupted squares" in all modes.
I believe it has to do with the method I'm using to down-sample from 1.789MHz to 22050KHz. My method may be madness.
I think new LUTs are correct.
You may look at nestopia src:
viewtopic.php?p=91333#p91333
Version 1.019 (windows build only) is out.
ChangeLog:
1. Fixed bug reported by Eugene.S:
Bucky O'Hare [MMC3/mapper4] is not working in all modes (GreenScreen)
Version 1.020 (windows build only) is out.
ChangeLog:
1. Fixed bug reported by Eugene.S:
Overlord (U) also has "interrupted squares" in all modes.
[quote="cpow"]
Version 1.021 (windows build only) is out.
ChangeLog:
1. Finished support for template projects in the New Project dialog. Currently there's only "NROM Hello World" template but I'm hoping to add many more. Selecting the template will add the source and graphics files to your project necessary to generate a ROM that prints "HELLO WORLD" on the screen. Tepples...I used your russian roulette code as basis--left your comment header in place.
2. Made changes to try to get better APU downsampling. It's not perfect...yet.
Cpow: Can you make the next version come with a few versions of ''Hello World'' with the following effects:
Text1.ASM: Uploads Plain Text.
Text2.ASM: Uploads Text, One Letter per Frame.
Text3.ASM: Same as Text2, But extends it with Hebereke-Style NPC Faces, Box, and Routines
I really admit the lack of good text routines to use for my games and hacks! and I will suggest to use the ''Do What The F*** You Want To'' license for these example ASM files, since a few ROM Hackers use this for parts of thier project:
http://en.wikipedia.org/wiki/WTFPL
Hamtaro126 wrote:
Cpow: Can you make the next version come with a few versions of ''Hello World'' with the following effects:
Text1.ASM: Uploads Plain Text.
Text2.ASM: Uploads Text, One Letter per Frame.
Text3.ASM: Same as Text2, But extends it with Hebereke-Style NPC Faces, Box, and Routines
I really admit the lack of good text routines to use for my games and hacks! and I will suggest to use the ''Do What The F*** You Want To'' license for these example ASM files, since a few ROM Hackers use this for parts of thier project:
http://en.wikipedia.org/wiki/WTFPLAre you asking me to code up the suggestions or were you intending to provide them?
cpow wrote:
Hamtaro126 wrote:
Cpow: Can you make the next version come with a few versions of ''Hello World'' with the following effects:
Text1.ASM: Uploads Plain Text.
Text2.ASM: Uploads Text, One Letter per Frame.
Text3.ASM: Same as Text2, But extends it with Hebereke-Style NPC Faces, Box, and Routines
I really admit the lack of good text routines to use for my games and hacks! and I will suggest to use the ''Do What The F*** You Want To'' license for these example ASM files, since a few ROM Hackers use this for parts of thier project:
http://en.wikipedia.org/wiki/WTFPLAre you asking me to code up the suggestions or were you intending to provide them?
They are not requests, nor would I say it is, I plan to code them to test out my knowlage in a simple way, so this will take some time off for me...
Does not need to be in the next version, just need to look if you would like the concept...
HINT: The ONLY request was to help convert it for NESICIDE with few modifications, That is pretty much it...
Hamtaro126 wrote:
They are not requests, nor would I say it is, I plan to code them to test out my knowlage in a simple way, so this will take some time off for me...
Does not need to be in the next version, just need to look if you would like the concept...
HINT: The ONLY request was to help convert it for NESICIDE with few modifications, That is pretty much it...
I am working on a way for templates to be shared online and available in the tool. So with that, yes, I'd love for other template examples to be created.
Note: templates will not be limited to whole projects but could include pieces of projects.
Version 1.022 (windows build only) is out.
ChangeLog:
1. Added full support for mapper 28, Tepples' Multi Discrete Mapper.
2. Fixed a bug in mapper 34's NINA-001 registers - they weren't being set so Impossible Mission 2 didn't work.
3. Reorganized internal CHR mapping to support > 8KB CHR RAM.
4. Started porting controller input logger from old NESICIDE.
5. Other crap I'm forgetting because it's been so long.
Current version of "nes-emulator.exe" don't remember last scaling factor.
Try to set it from "1x" to "2x", then close emulator and open it again. Emulator restarts with "1x" scaler. But you will see "2x" in preferences.
Version 1.023 (windows build only) is out.
ChangeLog:
1. Fixed APU period bug for square and triangle channels. Streemerz now sounds like it should. Thanks thefox for the report!
2. Fixes for MMC5. Not there yet by any measure, but runs Castlevania III better than it used to.
By the way, for those with performance concerns, if you un-check the bug icon in the toolbar it'll disable many of the processor-intensive debuggers. It's useful for a "I just want to run and play for a while" sort of mode. I'm still working on bettering the performance...
Eugene.S: The scale works as it should here. If I recall you're on WinXP? I'll have to install an XP VM and try it.
Yes, i'm using WinXP for now.
A lot of APU bugs has been fixed, thank you cpow:
Eugene.S wrote:
I've found the APU bugs - Power Blade, sector 2. Strange Hi-freqs:
http://www.fileden.com/files/2012/4/10/ ... de_bug.rarSector 5: Pitch of squares and triangle sweeps during tune (especially intro and ending):
http://www.fileden.com/files/2012/4/10/ ... ector5.rarNinja Gaiden 3 - level 1 (something strange with squares)
http://www.fileden.com/files/2012/4/10/ ... level1.rarBug in Power Blade 2 - level 3
I've heard very strong crackling and pitch sweeps also:
http://www.fileden.com/files/2012/4/10/ ... _2_bug.mp3But Alien 3 - tune 2 (in the soundcheck mode) still has Incorrect APU behavior:
http://www.fileden.com/files/2012/4/10/ ... n3_bug.rarAudio-channels checkboxes also has problems:
Try to disable "square 1" and "square 2", for example. Then close emulator and open it again.
Emulator restarts with disabled checkboxes. But you will hear all channels enabled.
Eugene.S wrote:
Yes, i'm using WinXP for now.
A lot of APU bugs has been fixed, thank you cpow:
Eugene.S wrote:
...
If you're saying all those in the first list are fixed that's great!
Eugene.S wrote:
But Alien 3 - tune 2 (in the soundcheck mode) still have Incorrect APU behavior:
http://www.fileden.com/files/2012/4/10/ ... n3_bug.rarAudio-channels checkboxes also has problems:
Try to disable "square 1" and "square 2", for example. Then close emulator and open it again.
Emulator restarts with disabled checkboxes. But you will hear all channels enabled.
I am in a coffee shop and listened to the two Aline 3 recordings and they sound the same. I'll try again when I'm in a quieter location.
Regarding the sound disabling, yes, I am aware that is broken. I will fix it. Thanks!
cpow wrote:
If you're saying all those in the first list are fixed that's great!
Yes, all those crap are fixed.
cpow wrote:
I've listened to the two Alien 3 recordings and they sound the same. I'll try again when I'm in a quieter location.
Here is this bug:
On 1.022 it sounds slightly different than on older versions.
1.021 and older1.022 and 1.023And i've found a new APU bugs.
1)
Aladdin (unl) - stage 1 (i think it has the same problem as Alien 3)
2)
Bucky O'Hare - Green planet (and intro also). Squares are incorrect. DPCM is too "dirty".
3)
Castlevania 2 - simon's quest, stage 1. Squares are missing sometimes. I've disabled DPCM on third loop to hear this bug more clearly.
If you want, you may add a DPCM pop-reducer like
FHorse does.
Just listen the same
Castlevania 2 track, for example. DPCM is much more clear.
cpow wrote:
Eugene.S: The scale works as it should here. If I recall you're on WinXP? I'll have to install an XP VM and try it.
I see the same problem on Windows 7.
Version 1.024 (windows build only) is out.
ChangeLog:
1. Fixed mirroring support in the Multi Discrete Mapper (mapper 28).
2. Added mapper 13 (Videomation).
3. Fixed APU period bug the right way.
tepples wrote:
I see the same problem on Windows 7.
And
org also confirmed this bug on Windows 7
All APU bugs in my post are gone.
But channel-mixer, Noise and DPCM are totally broken in 1.024 (in all games)
I've don't hear Noise everywhere (or it reduced very strong).
Try to listen DPCM-bassline in "Journey to Silius" or "Gremlins 2" from Sunsoft.
And try to disable
all channels in mixer. What are you hear?
Yeah, I know you don't have phone support at
1-800-NESICIDE (or
1-800-KIRBYCIDE for that matter), but yesterday morning I tried working entirely in NESICIDE for the first time. I had previously been using generic text editors (Notepad++ on Windows or Gedit on Ubuntu), and I couldn't figure out how to do these inside NESICIDE:
- Add a dependency on running a program that converts data into something that gets .incbin'd into one of the .s files. In my current setup using GNU Make, I have certain .o files depending on compressed tile data, and the makefile specifies how to call a Python program to rebuild it.
- Add a dependency on running a program that takes the final assembled and linked .nes file and runs a transformation on it. In a test ROM for a new mapper, I have to make 15, 31, 63, or 127 copies of the first 16K bank and 1 copy of the last bank, with the byte at offset $3FF8 changed to the 16K bank number. This way I can detect powering on in the wrong bank, and I can detect which bank has been switched into a given area. Again, I wrote a Python program to do this, and my current makefile automatically calls it.
- Press Ctrl+F to find something without having to make the window wide enough that the find box in the toolbar is visible. Firefox and Chrome, for example, hide the find box until the user presses Ctrl+F.
- Preserve $0A newlines, as opposed to NESICIDE converting newlines to $0D $0A in any file that it edits.
I also seem to remember having run into a problem with the sprite address ($2004) apparently being reset to 0 during an OAM DMA ($4014) that extends through the end of the pre-render scanline, even if the DMA is performed during forced-blank ($2001=#$00). I noticed this when the sprite 0 wait in my test ROM wasn't triggering, and a bit of time with the execution inspector revealed that OAM data (including sprite 0) was being overwritten.
tepples wrote:
- Add a dependency on running a program that converts data into something that gets .incbin'd into one of the .s files. In my current setup using GNU Make, I have certain .o files depending on compressed tile data, and the makefile specifies how to call a Python program to rebuild it.
- Add a dependency on running a program that takes the final assembled and linked .nes file and runs a transformation on it. In a test ROM for a new mapper, I have to make 15, 31, 63, or 127 copies of the first 16K bank and 1 copy of the last bank, with the byte at offset $3FF8 changed to the 16K bank number. This way I can detect powering on in the wrong bank, and I can detect which bank has been switched into a given area. Again, I wrote a Python program to do this, and my current makefile automatically calls it.
- Press Ctrl+F to find something without having to make the window wide enough that the find box in the toolbar is visible. Firefox and Chrome, for example, hide the find box until the user presses Ctrl+F.
- Preserve $0A newlines, as opposed to NESICIDE converting newlines to $0D $0A in any file that it edits.
I haven't added support for custom makefile rules yet. I keep stumbling into platform-dependent crap. Like...on Linux the rule would just call out the name of the external python script and everything would work fine. But on Windows...well...that's where I get stuck. So...I can add the *infrastructure* for being able to add custom rules to the makefile, no big deal...but worrying about all the horrors of what happens when GNU Make can't find/execute/whatever the thing in the custom rule just made me put it off... Maybe I'll just add the infrastructure and we can work out whatever else needs to be worked out one that's in place.
RE the find box, I know about that issue but I haven't found a way to force it visible. Qt is great but sometimes seems to be lacking.
tepples wrote:
I also seem to remember having run into a problem with the sprite address ($2004) apparently being reset to 0 during an OAM DMA ($4014) that extends through the end of the pre-render scanline, even if the DMA is performed during forced-blank ($2001=#$00). I noticed this when the sprite 0 wait in my test ROM wasn't triggering, and a bit of time with the execution inspector revealed that OAM data (including sprite 0) was being overwritten.
I'll check. I think you're right I just unconditionally clear $2004. I hadn't read anything that stated it only happened if rendering is enabled.
1-800-NESICIDE haha. I do have
nesicide@hotmail.com. I should add that to the About box.
Version 1.025 (windows build only) is out.
ChangeLog:
1. Fixed implementations of mappers 9 and 10.
2. Fixed APU period bug for the last time, hopefully. [I think this is the mixer problem Eugene.S referred to. An accident in my last changes caused the periods for noise and DPCM to become 0 and stay 0.]
3. Fixed OAM address clearing bug [thanks, tepples!]
4. Moved search bar widget from toolbar to bottom of central editor window to make it more accessible in small-screen environs. Made search bar openable by Ctrl-F and closeable by a close button or by ESCape key. Made search bar highlight current content on Ctrl-F.
Up next:
1. Work on tepples' other suggestions:
a. Line-ending mode.
b. Custom makefile rule infrastructure.
2. Implement more mappers!
3. Add internal info pages for more mappers (that need them).
4. Fix scaling reversion bug.
Since you support C64 as well, You might try to revamp the IDE into something more universal, Here are my suggestions:
Can you also make an option to select Plugins and Regular Programs to customize the IDE more?
Executable examples: YY-CHR, Programmer's Notepad 2, Any Program to Edit Data, etc.
Plugin examples: Video (GPU/PPU/VDP), (Co)Processors, Sound, Mappers, etc.
And Is it possible to make a better assembler with table support in?
(Needs to be GPL compatible AND compatible with normal ''Merlin'' syntax like CA65 and ASM6.)
And If you do this, Please try to change the name to something better if you can.
I really like where it's going, But these are really helpful for other developers too, Hope this isn't too bad of an Idea...
Hamtaro126 wrote:
Since you support C64 as well, You might try to revamp the IDE into something more universal, Here are my suggestions:
Have you loaded a .c64 file? If you have you'll notice that the NES elements are gone, replaced with C=64 elements. I haven't spent much effort on C=64 because it was kind of a flash-in-the-pan in the first place. Turns out the one VICE user that was interested had some kind of falling out with the VICE community and vanished...
Hamtaro126 wrote:
Can you also make an option to select Plugins and Regular Programs to customize the IDE more?
Executable examples: YY-CHR, Programmer's Notepad 2, Any Program to Edit Data, etc.
Plugin examples: Video (GPU/PPU/VDP), (Co)Processors, Sound, Mappers, etc.
I'm confused...are the examples you cite plugins you'd like to plug in to NESICIDE or examples you think I should look at for how to implement plugin methodologies?
Hamtaro126 wrote:
And Is it possible to make a better assembler with table support in?
(Needs to be GPL compatible AND compatible with normal ''Merlin'' syntax like CA65 and ASM6.)
If someone makes it, yes. I spent a good deal of time working on an assembler of my own but junked it when I realized that supporting the CC65 toolchain would be more mainstream.
Hamtaro126 wrote:
And If you do this, Please try to change the name to something better if you can.
I really like where it's going, But these are really helpful for other developers too, Hope this isn't too bad of an Idea...
The name stays. Yes, I originally chose it because I originally wanted to provide a tool specific to developing games on the NES. But since I've added support for C=64 using VICE, and plan to add support for other iconic 8-bit targets, the name is what it is and I don't think it needs to change.
2 cpow:
Mixer is totally broken in 1.025. Checkboxes are also broken.
You can listen only Square 1 + 1 another channel simultaneously.
see PM
cpow wrote:
Have you loaded a .c64 file? If you have you'll notice that the NES elements are gone, replaced with C=64 elements. I haven't spent much effort on C=64 because it was kind of a flash-in-the-pan in the first place. Turns out the one VICE user that was interested had some kind of falling out with the VICE community and vanished...
Yes, and True, but SNES support can be easy to implent this way
cpow wrote:
I'm confused...are the examples you cite plugins you'd like to plug in to NESICIDE or examples you think I should look at for how to implement plugin methodologies?
Yep, Plugins, as well as other programs specific to tasks like Character editing (Again, I use YY-CHR)
cpow wrote:
IIf someone makes it, yes. I spent a good deal of time working on an assembler of my own but junked it when I realized that supporting the CC65 toolchain would be more mainstream.
That's OK, then...
Thanks for your thoughts!
Version 1.026 (windows build only) is out.
Finally figured out what Eugene.S was talking about...so this build only fixes the APU "mixer" [which is referring to the APU channel enables in the Emulator->Audio menu, not the currently-unimplemented equalizer sliders in Emulator Preferences Audio tab.
ChangeLog:
1. Fixed APU sound channel enables.
EDIT: Google upload failed so I had to re-do it.
Thank you. It works fine now.
Version 1.027 (windows build only) is out.
ChangeLog:
1. Support in Environment Settings dialog (Code Editor page) for Line-ending styles. I tried it. It seems to work. Feedback, please!
2. support in Project Properties (Custom Rules page) for raw-entry of custom makefile rules. WIP...but seems to be useable. Feedback, please!
I will start updating the product version in the installer builder [when I can remember!] so hopefully that should make the installation process not require uninstallation of prior version.
Note, also, I changed the name of the installer since setup.exe is silly.
Regarding bundled installers for CC65 and GNU Make, I would do this but it makes the installer too large to put up on my google project page. I'm not ready yet to switch back to my domain to serve files from there -- google projects are just too convenient!
cpow wrote:
Regarding bundled installers for CC65 and GNU Make, I would do this but it makes the installer too large to put up on my google project page.
How so? The CC65 binaries total about 1 MB, and GnuWin32 make together with the required DLLs (2 as far as I know) is about 1 MB as well, should be able to fit that under the 20 MB (?) size limit. Anyway, if you're thinking of running external installers for CC65/make, I wouldn't do that, just throw the binaries in there.
Version 1.028 (windows build only) is out.
ChangeLog:
1. Installations (not installers) of GNU Make and CC65 are now delivered alongside the NESICIDE executables and libraries by the installer.
2. Settings are now stored .INI-style either in the platform-native location for such (%APPDATA%/CSPSoftware/NESICIDE.ini in Windows, etc.) or in the local directory of the installation. If you install to, and run from, a memory stick, for example, the NESICIDE.ini will be taken from the memory stick. Builds from now on will ignore any Windows registry debris left by earlier versions.
Unfortunately, for now, this requires external modification of the PATH environment variable so NESICIDE can find the GNU Make and CC65 tools. I'm hoping to find a way to get around this, but it may be as clunky as specifying full paths on all subprocess invocations. If you've installed GNU Make and CC65 yourself and they are already in your PATH, NESICIDE will just use those ones.
I added a bit of text to the Environment Settings, general page that shows where NESICIDE is currently retrieving its .INI file from.
I re-released the 1.028 installer. This one comes with a batch file, nesicide-portable.bat that, when launched, will set up the PATH appropriately so NESICIDE can find the GNU Make and CC65 installs properly.
cpow wrote:
I re-released the 1.028 installer. This one comes with a batch file, nesicide-portable.bat that, when launched, will set up the PATH appropriately so NESICIDE can find the GNU Make and CC65 installs properly.
Bah! Make that:
Version 1.029 is out. Silly bugs!
ChangeLog:
Fixed broken Emulator Preferences menu item.
Cpow,
Can you make something like this?
1) Intermediate screen sizes, like 2.5x, 3.5x.
2) TV-aspect ratio option.
3) Simply interpolation option:
to solve stretching problem.
And quick access to video options, of course.
I tried compiling the hello world template with the latest version and got this:
Code:
ca65 --create-dep obj/nes/main.d -t nes -g --debug-info -o obj/nes/main.o src/main.s
src/main.s(10): Error: Cannot open include file `src/nes.h': No such file or directory
make: *** [obj/nes/main.o] Error 255
(Working directory not set properly?)P.S. It's somewhat annoying that it's only possible to copy one line at a time from the build log. And the right click context menu option "Log to file" doesn't do anything but clears the log.
BTW, I specifically removed my old CC65 and MAKE directories from the PATH to try out the bundled versions, at least that part seems to be working.
EDIT: Actually the problem is in main.s:
.include "src/nes.h" even though the path should be relative to the directory where the source file is (get rid of "src/"). Can't understand why it would have been working for you at any point, though.
EDIT #2: And now that I fixed the above problem in the source, it's complaining about not finding "nes.lib". So you should use -L or set LD65_LIB.
And after fixing that (pointing to the nes.lib in NESICIDE's cc65-snapshot directory):
Code:
ld65.exe: Error: Object file `add.o' in library `../cc65-snapshot/lib/nes.lib' has wrong version
And after copying a newer version of nes.lib in there, it finally works... hooray.
Thanks for the feedback thefox, I'll take a look at it.
Version 1.030 is out.
ChangeLog:
1. Requests from Eugene.S:
a) Intermediate screen sizes, like 2.5x, 3.5x.
Ctrl+1 through Ctrl+5 cycle 1x, 1.5x, 2x, 2.5x and 3x.
b) TV-aspect ratio option.
Ctrl+0 switches between 4:3 and 1:1.
c) Simply interpolation option: to solve stretching problem.
Ctrl+9 switches between nearest neighbor and linear interpolation.
d) And quick access to video options, of course.
Quick access key shortcuts, menu options, and emulator preferences settings.
2. Requests/bugs from thefox:
a) P.S. It's somewhat annoying that it's only possible to copy one line at a time from the build log.
Fixed. Double click will now jump to line of code if an error/warning line is double-clicked on or a search result is double-clicked on, instead of single click. All text is selectable.
b)EDIT #2: And now that I fixed the above problem in the source, it's complaining about not finding "nes.lib". So you should use -L or set LD65_LIB.
I added setting LD65_LIB in nesicide-portable.bat. Works here.
c)EDIT: Actually the problem is in main.s:
.include "src/nes.h" even though the path should be relative to the directory where the source file is (get rid of "src/"). Can't understand why it would have been working for you at any point, though.
Not sure what happened here. It works for me...on a laptop that's running NESICIDE from a thumb drive.
cpow wrote:
b)EDIT #2: And now that I fixed the above problem in the source, it's complaining about not finding "nes.lib". So you should use -L or set LD65_LIB.
I added setting LD65_LIB in nesicide-portable.bat. Works here.
What about people who are not using nesicide-portable.bat?
Quote:
c)EDIT: Actually the problem is in main.s:
.include "src/nes.h" even though the path should be relative to the directory where the source file is (get rid of "src/"). Can't understand why it would have been working for you at any point, though.
Not sure what happened here. It works for me...on a laptop that's running NESICIDE from a thumb drive.
I'm not using a thumb drive or "nesicide-portable.bat". The fact that it finds "src/nes.h" must mean that the current working directory in your case is the directory of the project. In my case that doesn't seem to be the case.
Actually, now that I reopen the project, even if I modify it to "src/nes.h" it works, so NESICIDE probably set the working directory now for some reason, but didn't do it before.
Try this: remove nesicide.ini and reinstall NESICIDE. Remove CC65 and make from PATH. Create a new project based on the Hello World template, and try compiling it.
Whatever turns out to be the reason, doing .include "src/nes.h" is not the "right thing".
EDIT: I don't know what is going on, but the Makefile/"Compile Project" is also not working correctly. Even if I modify main.s, it doesn't recompile the project when I press "Compile Project".
Thank you cpow. New video options is very good.
Scalers bug is also gone.
Eugene.S wrote:
Thank you cpow. New video options is very good.
Scalers bug is also gone.
I released it last night before coming to work this morning to try it on my WinXP box. Thankfully my results there were good (RE scaling bug)... Thanks for the suggestions. I love the interpolation and 1.5x scale.
Just to clarify what I believe is the correct way to fix the problem I'm having with hello world template:
- Set the current working directory to the project directory (the directory where the .nesproject file is) before calling make.
- Set LD65_LIB environment variable for make's calling environment (hopefully Qt allows this, in Win32 it's the lpEnvironment parameter of CreateProcess).
- Change the .include "src/nes.h" line to .include "nes.h" in the template (the search path for includes is the directory of the source file, i.e. this is the Right Thing).
thefox wrote:
Just to clarify what I believe is the correct way to fix the problem I'm having with hello world template:
- Set the current working directory to the project directory (the directory where the .nesproject file is) before calling make.
- Set LD65_LIB environment variable for make's calling environment (hopefully Qt allows this, in Win32 it's the lpEnvironment parameter of CreateProcess).
- Change the .include "src/nes.h" line to .include "nes.h" in the template (the search path for includes is the directory of the source file, i.e. this is the Right Thing).
Yep I have fixes for all this I'll make a release sometime soon. I finally found the way to change the application's environment internally.
RE the include pathing I guess we'll have to agree to disagree.
cpow wrote:
RE the include pathing I guess we'll have to agree to disagree.
What do we disagree about? I say it's more logical to use source file relative paths when including files, you say it's better to use working directory relative paths. I know tepples' original source uses "src/nes.h" too, but that was probably made for an old version of CA65 where that was a requirement (you can find many threads about include search path behavior on CC65's mailing list).
Actually, it seems like the search path behavior has changed recently when compared to the CC65 snapshot included in NESICIDE, the latest version doesn't seem to be searching the working directory at all, so "src/nes.h" doesn't work with it no matter what.
thefox wrote:
cpow wrote:
RE the include pathing I guess we'll have to agree to disagree.
What do we disagree about? I say it's more logical to use source file relative paths when including files, you say it's better to use working directory relative paths. I know tepples' original source uses "src/nes.h" too, but that was probably made for an old version of CA65 where that was a requirement (you can find many threads about include search path behavior on CC65's mailing list).
Actually, it seems like the search path behavior has changed recently when compared to the CC65 snapshot included in NESICIDE, the latest version doesn't seem to be searching the working directory at all, so "src/nes.h" doesn't work with it no matter what.
I'm not saying either is better.
I see your point. I only meant disagreement in that I don't believe code should be written with one particular search path list in mind over another. Both
Code:
#include "src/nes.h"
and
Code:
#include "nes.h"
are valid statements and will resolve to the right file if a)the compiler's search path already contains the base path or b)has been amended with the appropriate base path via
-I directives.
NESICIDE can only go so far in guaranteeing that a particular project will work with a particular version of the compiler. That is why there was a push to get the compiler bundled to begin with. If a power user wants to use his own version, said power user should also be able to resolve any strange behaviors brought about by use [or misuse] of compiler directives that behave differently between compiler versions.
OK, now we can agree to disagree.
how do I create a simple game?
FLAVIO wrote:
how do I create a simple game?
You can start with the NROM Hello World template. Select Project->New Project. In the Template combo box select "NROM Hello World", pick a path for where you want the project created, and click OK. That autopopulates a project for you with all that's necessary to get a simple project compiled that prints HELLO WORLD to the NES screen.
I'll be releasing version 1.031 within hours that should alleviate some of the pathing and tooling concerns brought up in this thread.
nesicide 1 or 2 which I download?
Most Windows users will be downloading nesicide-win32.msi from the
Google product page.
ok
and now what do I do more?
and now what do I do more?
to create a simple game?
Have you ever made a simple game for the PC or Mac before?
Just a heads up, I'm still using NESICIDE, cpow!
So far there really has been only one thing that keeps bothering me.
Is there an option to sort the file listing in the project viewer by name?
Jsolo wrote:
Just a heads up, I'm still using NESICIDE, cpow!
So far there really has been only one thing that keeps bothering me.
Is there an option to sort the file listing in the project viewer by name?
There isn't, but I'll add it to the list. Thanks for the heads up!
Version 1.031 (windows build only) is out.
ChangeLog:
1. Fixed portability issues. CC65, and GNU Make are added to the path automatically. Removed the obsoleted batch file.
2. Included CC65 libraries for C=64 and NES, and the CC65 default source that is used to build them. When stepping if your NESICIDE project hasn't yet been set up to find those source files you it'll ask you to point to them and it'll remember where they are.
3. Fixed bugs reported by Eugene.S:
nes-emulator.exe remembers ROM path most recently used.
open-with in Windows Explorer context menu now works as expected.
4. Added a NROM Hello World C-language template project to the New Project options. It's not the best example, but it seems to work. I'll take any comments or suggestions for improvement.
5. Fixed problem that made the register binary-view debuggers not editable.
6. Fixed problem causing the cursor position text to overwrite the other widgets [instead of being thrown down to the status bar] in the Cartridge CHR Memory inspector.
I forgot I also:
ChangeLog:
1. Added support for soft versus hard emulator resets. Emulator now passes mapper 28 automated tests entirely.
2. Updated Code Editor to QScintilla 2.6.3 snapshot.
Problems:
There is an issue with the Scintilla editor regarding annotations and the vertical scrollbar. Mixed-mode C source files do not display proper scrollbar. If you're working on a C project it's recommended [for now] to turn off mixed-mode annotations. I upgraded to the latest QScintilla but this problem is still present.
White borders in fullscreen-mode also fixed.
But i have serious problems with 1.031:
http://youtu.be/27smzoCodRw
Eugene.S wrote:
White borders in fullscreen-mode also fixed.
But i have serious problems with 1.031:
http://youtu.be/27smzoCodRwSorry Eugene.S. I'm not understanding what the problem is. I tried Bucky O'Hare (E).nes and it seems to work. Unfortunately I'm not familiar with Bucky O'Hare so I can't tell if you're showing that the game locks up the emulator at some point [if so, which stage/point?], or if you're showing something else?
When I tried the game I had to sit through five minutes of dialogue. Did you enter a passcode to skip that? If so, what passcode?
I have two problems with 1.031
1) Very quick flickering in fullscreen mode, like:
only much faster
2) emulator
window hangs when i exit fullscreen-mode.
I need to kill the "nes-emulator" process in task manager.
I've Windows XP x64 and Intel <G41> GMA4500. Driver version = 6.14.10.5402 (23.02.2012)
But it works fine under Wine (Mint 9) on the same machine.
I had similar flicker problems back when I used an Intel GMA chipset; the Intel GMA doesn't automatically clear the video memory when a new framebuffer is created. Thus, if the program doesn't initialize its framebuffer before it starts using it, you get flickering garbage as part as your double buffer.
So, fixing the flicker should hopefully be easy. The window hanging when you exit fullscreen, I have no idea.
1.030 (and older) works fine.
Drag wrote:
I had similar flicker problems back when I used an Intel GMA chipset; the Intel GMA doesn't automatically clear the video memory when a new framebuffer is created. Thus, if the program doesn't initialize its framebuffer before it starts using it, you get flickering garbage as part as your double buffer.
Early homebrew programs to manipulate the Game Boy border on the Nintendo DS had a similar problem. The DS hardware doesn't blank the 16 lines on the top and bottom and 8 pixels on the left and right of the GBA screen; that's the responsibility of the boot menu. So the firmware has to put the same border graphic in both of the frame buffers that the GBA-compatibility graphics core renders to.
Version 1.032 (windows build only) is out.
ChangeLog:
1. Added suggested work-around for flickering border problem.
2. Added "mapper memory" inspector information for all supported mappers. Values displayed are values written to mapper registers.
3. Fixed four-screen mode. Rad Racer 2 now works properly.
4. Fixed Sunsoft 4 mapper mirroring modes.
Did you break the Execution Visualizer some updates ago? It always shows "IN PROGRESS" regardless of being in a loop or not.
Jsolo wrote:
Did you break the Execution Visualizer some updates ago? It always shows "IN PROGRESS" regardless of being in a loop or not.
Can you provide a simple example? I took a look at it and the only odd thing I saw is that when I set a marked region while paused the marker shows as IN PROGRESS. But then when I run through it it goes to COMPLETE. Is it possible you're marking a region that can't ever get to its END mark?
Well, I just created a new NROM asm template and...it works as expected.
It doesn't work for my project created with an older version, though. I tried recreating the project just now, but to no avail.
I'm trying to whip up a smaller example and report back.
Edit: On an unrelated note, the NROM template trashes the stack by doing
Code:
mainLoop:
jsr mainLoop
if I'm not mistaken.
After some digging I believe it is related to one's mapper choice.
I converted the NROM example to UNROM like my project is. I also deleted all the graphics and nearly all code.
I then marked the code
Code:
lda #0
sta $00
with the right click options "Set Visualization START/END Marker here" and compiled/ran the application. After pressing the Pause button, the execution visualizer still shows "IN PROGRESS" even though the PC points to the endless loop.
I prepared the project in question in the attachement.
Jsolo wrote:
Well, I just created a new NROM asm template and...it works as expected.
It doesn't work for my project created with an older version, though. I tried recreating the project just now, but to no avail.
I'm trying to whip up a smaller example and report back.
Edit: On an unrelated note, the NROM template trashes the stack by doing
Code:
mainLoop:
jsr mainLoop
if I'm not mistaken.
Yes, it should be jmp. Guess my fingers got ahead of me there. It'll be fixed next release.
Jsolo wrote:
I prepared the project in question in the attachement.
Thanks. I'll take a look and release an update when I've figured it out.
Version 1.033 (windows build only) is out.
ChangeLog:
1. Fixed JSR mainLoop issue in NROM Hello World template. [Thanks Jsolo].
2. Fixed Execution Visualizer [and Code/Data Logger] issues brought on by mapper improvements that changed some of the logging architecture.
Jsolo: Your UNROM test project was very helpful, thanks! I discovered there's no removal of or invalidation of markers that have become obfuscated by code changes. When I added a string of NOP instructions before 0E:001A-0E:001B and restarted NESICIDE the marked region showed back up. I haven't fixed this problem yet but at least I know what went wrong.
If you "Clear all markers" and re-apply the marker it should work.
Eugene.S: I still haven't figured out why the emulator locks up when you exit fullscreen. Kind of hard since it doesn't happen here. I'll PM you if I come up with a fix to try.
It's working again, thanks a lot
Here's another thing I've noted. The editor's line endings are inconsistent. Every time I open a file in Notepad++, for example, it places an empty line between consecutive lines of text. After inspecting it with "Show line endings" it is revealed that line endings actually are
CR CR LF, which is interpreted by notepad++ as
CR
CR LF,
so two line endings. Usually it detects windows line endings but fails to do so here. I'm not even sure CR CR LF is a valid line ending
I've attached an screenshot showing an example with line endings enabled.
Jsolo wrote:
CR
CR LF,
That's really strange...what do you have set for End-of-Line style in Environment Settings->Code Editor->Whitespace. Do you have "Force consistent" set?
If the text box returns the text with CR+LF, and then it's saved to a file opened in text mode, the LF will get converted to CR+LF on Windows, resulting in CR+CR+LF.
cpow wrote:
That's really strange...what do you have set for End-of-Line style in Environment Settings->Code Editor->Whitespace. Do you have "Force consistent" set?
Yep, it is set. I never changed a thing in that menu.
tepples wrote:
Have you ever made a simple game for the PC or Mac before?
not
FLAVIO wrote:
tepples wrote:
Have you ever made a simple game for the PC or Mac before?
not
make examples of a simple game to learn.
Version 1.035 (windows build only) is out.
ChangeLog:
1. Added mappers 21, 22, 23, 24, 25, and 26. No extra sound support yet on 24 or 26, although the registers are viewable in the Mapper Memory inspector.
2. Added turbo controller support. Thanks Eugene.S for the suggestion and OGR for the graphic.
3. Made an attempt at CR+LF line-ending correction based on Jsolo's bug report. This might need more work but I'm waiting on a new snapshot build from Phil to correct the problem with annotations and scrollbar height.
Depending on how quick things go in, next release will have sound support for mappers 24 and 26, and hopefully mapper 85 [VRC7].
cpow wrote:
Depending on how quick things go in, next release will have sound support for mappers 24 and 26, and hopefully mapper 85 [VRC7].
Dang...already got the VRC6 audio working. Akumajou Densetsu sounds awesome as hell!
That was easy. Oh well. I guess I'll wait 'til at least tomorrow to make sure the Qscintilla annotation and CR+LF bugs get fixed before doing 1.036.
Version 1.036 (windows build only) is out.
Also, I hear hyarion is able once again to make OSX builds...
ChangeLog:
1. Added mappers 18, 19, 210.
2. Added sound to mappers 24, 26, and 19.
3. Fixed turbo controller issues reported by Eugene.S.
4. Updated to latest Qscintilla2 snapshot which fixes the annotations vs. scroll-bar height problem in mixed-mode C source files.
Just a general note...while implementing mapper 19 I thought I'd start implementing deep internal state inspection for things like the sound channels so the internal state of the sound channels could be seen. But then I decided that I'd hold off on that, since I don't know but I'd guess that nobody uses mapper 19 [Namco 106] as a homebrew dev platform. So, as a more general note I think what I'll do with the remaining mapper implementations -- the ones I don't even support yet, but I'm adding as time goes by -- is add support for viewing their *register* internal state [Debugger->Cartridge->Mapper Memory] but not necessarily their deep internal state. For an example of what I mean, load any MMC1, MMC2, or MMC3 game [or, indeed, tepples' mapper 28], open the Debugger->Cartridge->Information debugger, and select the "Internals" tab.
I'll gladly take requests for mapper support or deep internal state inspector capabilities for any mapper that anyone is using as a homebrew dev platform that I don't currently support or have deep internal state inspection for.
Let me know, here or in PM. Thanks.
cpow wrote:
I'd guess that nobody uses mapper 19 [Namco 106] as a homebrew dev platform.
A bunch of Japanese NSF composers apparently do, if by "106" you mean the common misnomer for 163. But then it's hypothesized that all of a channel's state is stored in the mapper's 128-byte SRAM.
(Side note: 128 byte SRAM? Was it prototyped with a
RIOT pulled from an Atari 2600 out of frustration over the bad Pac-Man port? I wonder how many macrocells it'd take to implement N163 audio on a CPLD + SRAM.)
tepples wrote:
cpow wrote:
I'd guess that nobody uses mapper 19 [Namco 106] as a homebrew dev platform.
A bunch of Japanese NSF composers apparently do, if by "106" you mean the common misnomer for 163. But then it's hypothesized that all of a channel's state is stored in the mapper's 128-byte SRAM.
(Side note: 128 byte SRAM? Was it prototyped with a
RIOT pulled from an Atari 2600 out of frustration over the bad Pac-Man port? I wonder how many macrocells it'd take to implement N163 audio on a CPLD + SRAM.)
Disch's mapper docs, 019.txt wrote:
========================
= Mapper 019 =
= + 210 =
========================
aka
--------------------------
Namcot 106
N106
That's what I mean...not sure where N163 comes from.
You are correct all the internal state is in the 128 byte SRAM. I was just saying that I hadn't yet put anything in NESICIDE to show that SRAM. If there's a user that wants it I'll add it.
You bring up a good point, though. I don't support NSF...yet. Nobody's asked.
I think the actual chip is marked 163, and 106 might have been a typo that got spread far and wide. Can anyone dig up the old forum discussion about 106 vs. 163?
tepples wrote:
I think the actual chip is marked 163, and 106 might have been a typo that got spread far and wide. Can anyone dig up the old forum discussion about 106 vs. 163?
I'll check my rolling thunder!
Aww.
Which carts aren't glop-tops?
None of the N163-class ICs found in BootGod's database mention "106" at all. AFAICT, it's most likely entirely spurious, or maybe an internal code name that somehow leaked.
NesCartDB's PCB viewer:
N163,
N175,
N340
Happy Holidays! Enjoy this preview release of hopefully many more UI and project management enhancements to come, thanks mostly to contributions from JSolo [both in actual code and in feedback/idea exchanges].
Version 1.037 (windows build only) is out.
ChangeLog:
1. Updated to QScintilla2 version 2.7.0 release.
2. The UI is now "mode based". There is a "Coding mode" and a "Debugging mode". Coding mode is intended to free up the majority of the UI for space for code documents. Debugging mode is intended to remember the prior state of debugger windows. Coding mode is sort of like "show desktop" in Windows, I guess.
3. Project Browser now has an Open Items section for easier context switching.
4. Search (Ctrl+Shift+F) dialog has been moved into the Output Pane. Output Pane is hidden unless explicitly opened (with buttons accessible in the status bar), as opposed to having it annoyingly pop open.
5. Search bar (Ctrl+F) now includes replace functionality.
6. Files can be syntax highlighted as C or assembly based on their extension.
7. Double clicking on a symbol in the symbol watch window will open a memory window to its address.
8. Context menus for Project Browser redone.
9. Breakpoints can have an exclusive/inclusive mask set on the address and data fields. Exclusive is non-one-mask bits must be zero. Inclusive is non-one-mask bits are don't care.
10. Added EEPROM support to mapper 16.
bunnyboy on #nesdev asked for a feature to breakpoint whenever an APU channel DAC hits a specified value.
NESICIDE v1.038 windows installer.NESICIDE dependencies windows installer.I had to split the package in two to fit google project page's 20MB upload limit...but it made a bit of sense to do so anyway because the dependencies don't change that much.
The breakpoint feature [not sure if anyone else will find it useful] is accessed selecting "APU Event" as the breakpoint type when adding a breakpoint, then selecting one of the events for DAC value, then providing the DAC value you are wanting to break on.
Please note...this build includes a Windows version of the Qt FamiTracker port that I've been working on. It is not yet properly integrated into NESICIDE thus the menu bar, tool bar, and status bar are a bit gunked up.
Tepples...if you're so inclined perhaps you could try the Windows FamiTracker Qt build in WINE? See if you get the same performance...
PESTER THE AUTHOR OF
THIS EMULATOR TO PROPERLY
SUPPORT THE NES 2.0
EXTENSION TO THE INES
FORMAT
Do you plan on supporting SXROM any time soon to run PR8 (
download) and the
two Japanese games that use this board?
tepples wrote:
PESTER THE AUTHOR OF
THIS EMULATOR TO PROPERLY
SUPPORT THE NES 2.0
EXTENSION TO THE INES
FORMAT
Do you plan on supporting SXROM any time soon to run PR8 (
download) and the
two Japanese games that use this board?
Sorry tepples...completely missed this. I'll look into it.
NESICIDE version 1.0.039 is out.
NESICIDE v1.039 windows installer.NESICIDE dependencies windows installer.[/quote]
This version:
1. Addresses the
issue identified in this thread. All projects should now compile - with the exception of Russian Roulette...I need to figure out why the Python build step is complaining about missing PIL. I don't recall it doing that before...but I know it's not a NESICIDE "bug".
2. Completely and more properly encapsulates Qt FamiTracker 0.4.1.1 into NESICIDE. The menu, tool bar, and status bar are no longer polluted with FamiTracker's debris. Instead, the entire FamiTracker application is contained within the tabbed editors area. Qt FamiTracker is also still [and always will be] provided as a stand-alone executable.
3. Includes latest updates to Qt FamiTracker, including bug fixes, support for MRU lists, and [forever and ever] on-going incremental updating on the path to a final formalized Qt FamiTracker release.
4. Includes updates and bug-fixes to the VICE integration, which is not yet perfect, but getting better.
5. Includes a source search path project properties setting to specify where to find source for the project for debugging. It autopopulates with relevant source paths to the CC65 toolchain library source files included in the install.
6. Addresses issues provided in PMs from bananmos and Jahrmander.
- The source navigator toolbar widget is no longer disabled on a failed compile. This means the file/symbol information in those lists could be a tad outdated but it does its best in allowing you to navigate to the files included in your project or indirectly included in it by inspection of the debug information file.
- The mixed-mode C/assembly view was found to have a limitation where it could cause a segfault. This has been fixed.
- The UI correctly prompts due to detection of external file modifications *only once* per affected file.
7. Fixes object destructors to prevent crashes on application close.
8. Fixes program lock-up on project closure.
9. Fixes program crash at start-up [was an uninitialized variable in the original FamiTracker source that was causing occasional divide-by-zero errors].
As usual, bug reports, enhancement requests, always welcome.
Won't support for iNES 2.0 effect like 0.00001% of ROMs?
At least these games are directly affected by lack of NES 2.0 support:
- Holy Diver uses one of two mirroring types for mapper number 78. This mirroring type (H/V switch) uses submapper 3.
- Uchuusen: Cosmo Carrier uses the other mirroring type. This mirroring type (single-screen nametable switch, like AOROM) uses submapper 1.
- StarTropics uses a different PRG RAM enable method compared to standard MMC3.
- Zoda's Revenge: StarTropics II uses the same method as StarTropics.
- Nobunaga's Ambition uses SOROM, which uses a spare CHR bank bit to switch between two PRG RAM chips.
- So does Genghis Khan.
- So does Romance of the Three Kingdoms.
- Final Fantasy I+II uses SXROM, which uses two spare CHR bank bit to switch among 4 banks of a larger PRG RAM chip.
- So does The Best Play Pro Yakyuu Special.
- So does PR8.
- Bandit Kings of Ancient China uses ETROM, which uses an MMC5 register to switch between two PRG RAM chips.
- So does L'Empereur.
- So does Ishin no Arashi.
- So does Nobunaga's Ambition II: Tales of the Sengoku Warlords.
- So does Uncharted Waters.
- Romance of the Three Kingdoms II uses EWROM, which uses an MMC5 register to switch among 4 banks of a larger PRG RAM chip.
- So does Nobunaga no Yabou: Bushou Fuuunroku (that is, Record of Generals in Turbulent Times; released outside Japan on Super NES and Sega Genesis as Nobunaga's Ambition: Lord of Darkness).
- So does Aoki Ookami to Shiroki Mejika: Genchou Hishi (released outside Japan on Super NES as Genghis Khan II: Clan of the Gray Wolf).
- Games that don't exist yet (but might if NESICIDE supports it) run on boards sold by infiniteneslives that contain a clone of the MMC3 or FME-7 and 32 KiB CHR RAM.
In order for NES 2.0 support to affect only one out of ten million NES games, as you suggest, there'd have to be at least 180 million NES games in existence.
In addition,
- The MC-ACC MMC3 clone has an incompatible IRQ, so all of Acclaim's games that use it:
- Alien³
- George Foreman's KO Boxing
- The Incredible Crash Dummies
- Mickey's Safari in Letterland
- Roger Clemens' MVP Baseball
- Rollerblade Racer
- The Simpsons: Bart vs. The World
- The Simpsons: Bartman Meets Radioactive Man
- Spider-Man: Return of the Sinister Six
- T&C Surf Designs 2: Thrilla's Surfari
- T2: Terminator 2: Judgment Day
- WWF King of the Ring
- WWF WrestleMania: Steel Cage Challenge
- Fire Hawk
- All of the games that use the Namco 175 and 340:
- Famista '91
- Family Circuit '91
- Chibi Maruko-chan: Uki Uki Shopping
- Heisei Tensai Bakabon / Genius Bakabon
- Famista '92
- Top Striker
- Famista '93
- Famista '94
- Splatterhouse
- Wagyan Land 2
- Dream Master
- Wagyan Land 3
- The one mapper 185 game that doesn't comply with the heuristic: Seicross (J) release 2
- Major League (J)
- Nantettatte!! Baseball
- Every Vs. System game
It's closer to 5%.
NESICIDE version 1.0.040 is out.
NESICIDE v1.040 windows installer.NESICIDE dependencies windows installer.This version:
1. Updates to latest CC65 version 2.14.0 available on GitHub - requested by Payton Byrd on cc65 mailing list for C=64 support.
2. Fixed issue causing multiple breakpoints to be created for the same line of code.
I also updated the NES AlterEgo project to include the FamiTracker modules in the NESICIDE project. One step closer to automating the song creation/inclusion steps in the IDE.
As usual, bug reports, enhancement requests, always welcome.[/quote]
WedNESday wrote:
Won't support for iNES 2.0 effect like 0.00001% of ROMs?
Think people are either being a bit tongue-in-cheek or they've taken me a bit too literally.
I'm not saying that the extra header info isn't needed, just isn't there for most ROMs that people own.
Could you add "Palette Window" which would you show NES palette and could copy HEX value of specific color? Would be useful when managing palettes in code.
Also "Show in explorer"/open with default program options for binary files, so I can execute e.g. MS PAINT or gimp for png file, etc.
//edit: Plus MMC3 template would be cool.
I think I've detected bug in NESICIDE's emulator: When game is running, there is some farting noise, similar to one when nes boots playing on like each frame. I've tested ROM with Nestopia and puNES and farting wasn't there so it is problem with your emulator. I'm giving you ROM in question to allow debugging.
darkhog wrote:
I think I've detected bug in NESICIDE's emulator: When game is running, there is some farting noise, similar to one when nes boots playing on like each frame. I've tested ROM with Nestopia and puNES and farting wasn't there so it is problem with your emulator. I'm giving you ROM in question to allow debugging.
Thanks for the colorful description. I am aware of the issue but for me it wasn't so much a fart as a high-pitched occasional chirp - it appears to be because of the FamiTracker integration and the two different SDL audio configurations.
As for palette window and "open with..", sure, I can add that...
Well, for me it seems to be low chirp (100-300hz range, I think), so essentially fart. Anyway I'd be happy if all examples (alter ego,etc) would be converted into templates and bundled in. Also some macro library, perhaps as part of nes.h that would do most of the things for dev (loading nametables, etc.) so less experienced devs would have headstart until they are able to write their own, optimized functions.
Furthermore, I think there is need for some middle-ground template between totally blank game and hello world template. Only boot code and .procs for nmi/irq/reset vectors without anything like drawing hello world, any game logic.
Sorry for double post, but NESICIDE is crashing upon exiting (hitting X). It isn't constant either, I'd say it crashes 60% of the time. It isn't when using critical feature, so I think it can wait for the fix. I'm just making this thread "lit up" so you'll know.
//edit: About "show in explorer" feature. I'd like it work like similar feature in Unity. You basically right-click some file, use this feature and it opens Explorer with folder containing that file opened. Very useful when you want quickly open this folder, because you want either to add some things there, delete or modify.
darkhog wrote:
Sorry for double post, but NESICIDE is crashing upon exiting (hitting X). It isn't constant either, I'd say it crashes 60% of the time. It isn't when using critical feature, so I think it can wait for the fix. I'm just making this thread "lit up" so you'll know.
Thanks for the report. You can put a message on GitHub if you want...might be better that way. Easier to track, at least.
darkhog wrote:
//edit: About "show in explorer" feature. I'd like it work like similar feature in Unity. You basically right-click some file, use this feature and it opens Explorer with folder containing that file opened. Very useful when you want quickly open this folder, because you want either to add some things there, delete or modify.
So what you really want is a "Open containing folder..." option as in FireFox's downloads pane?
Yeah, that would be enough.
//edit: Also two things:
- Being able to use regular .CHR files for graphics (unless it can be done already)
- "Tools" menu where you can set path to exe and caption of tool to execute (and of course add/remove items). I prefer using YY-CHR for graphics and NES Screen Tool for nametables. There isn't anything wrong with your tools, it's just my personal preference, that's all.
NESICIDE version 1.0.041 is out.
NESICIDE v1.041 windows installer.NESICIDE dependencies windows installer.This version:
1. Stability fixes to address crashes on app exit or project closure. Most turned out to be related to shutting down threads handling debuggers.
2. Fix for choppy 'farting' audio caused by inclusion of FT in NESICIDE and inappropriate SDL buffer sizing.
3. Inclusion of qbradq's uc65 tool and a NROM template project for it, accessible via Project->New Project. Create, build, run, and debug step/breakpoint through your UC65 project.4. Fixed focus problem on Ctrl+Shift+F - now focuses in search text entry field so you can start typing text to search for immediately as you'd expect to be able to.
Unfortunately I didn't get to the enhancement requests yet [palette picker, open with...]
As usual, bug reports, enhancement requests, always welcome.
Good work on the "Go Button"!
I think the reason I got confused with my first attempt with NESICIDE is that I didn't realize the way to open a simple hello world project was to just create a project under that template. That and I spent a lot of time clicking around on your site looking for the download not realizing it was here.
You sure do have all kinds of bells and whistles on this thing cpow. I knew you had a lot going on with your IDE, but wowzers there's hardly nothing that you're unable to monitor and/or visualize. Great work on this project, the debugging capabilities you've got here are truly unparalleled.
So is it about time to reward yourself for the hardwork on this project and get some use with it to create a game of your own???
infiniteneslives wrote:
Good work on the "Go Button"!
Thanks! Hoping people find it helpful.
infiniteneslives wrote:
I think the reason I got confused with my first attempt with NESICIDE is that I didn't realize the way to open a simple hello world project was to just create a project under that template. That and I spent a lot of time clicking around on your site looking for the download not realizing it was here.
My site was horked for a while, yeah. Should be fixed now though.
infiniteneslives wrote:
You sure do have all kinds of bells and whistles on this thing cpow. I knew you had a lot going on with your IDE, but wowzers there's hardly nothing that you're unable to monitor and/or visualize. Great work on this project, the debugging capabilities you've got here are truly unparalleled.
Thanks, again! Let me know if there's anything you'd love to have that's not there. I'm going to focus for a bit on the requests already made in this thread.
infiniteneslives wrote:
So is it about time to reward yourself for the hardwork on this project and get some use with it to create a game of your own???
I'm afraid what will happen if I do that is -- again -- my "tool man disease" will flare up at the slightest "oh if only NESICIDE could do...", and I'd -- again -- get sidetracked. However, trying to create simple games to start might be a good way to get some tutorials online [if I can find time to breathe my Wiki back to life].
Thanks for the feedback!
infiniteneslives wrote:
So is it about time to reward yourself for the hardwork on this project and get some use with it to create a game of your own???
I think one reason for "tool man disease" is that tools require comparatively less
art.
cpow wrote:
However, trying to create simple games to start might be a good way to get some tutorials online [if I can find time to breathe my Wiki back to life].
Reminder: I'm still willing to help you configure an
ABUSE filter on a MediaWiki site that you operate.
tepples wrote:
I think one reason for "tool man disease" is that tools require comparatively less
art.
Yep, that'd be my main mental hurdle. I know...I know...with an idea one should be able to create the entire game using "stand in" borrowed or thrown-together art. That's where my "perfectionist disease" kicks in.
tepples wrote:
Reminder: I'm still willing to help you configure an
ABUSE filter on a MediaWiki site that you operate.
Thanks for the reminder, tepples! I will need to completely re-create the Wiki as I simply blew away its SQL database when godaddy started complaining about its size. Not that there was any content on it other than garbage from trolls.
Hi. I'm new to these forums & I have a question regarding NESICIDE.
I have downloaded & installed the program & know what it is capable of, but am wondering when it says sound designers - does that include sound effects as well as music?
Just thought I would inquire on that.
Thx.
phirobe wrote:
Hi. I'm new to these forums & I have a question regarding NESICIDE.
I have downloaded & installed the program & know what it is capable of, but am wondering when it says sound designers - does that include sound effects as well as music?
Just thought I would inquire on that.
Thx.
It has been my goal to include a sound-effect designer, yes. At the moment I am porting FamiTracker to Qt -- and if you create a Music object you'll see that FamiTracker is embedded in NESICIDE. You should be able to drag/drop an existing FTM onto NESICIDE and it'll add it to your project. I had thought a "sound designer" might look something like the SoundMaker in Garry Kitchens' GameMaker for the Commodore 64. But having seen what FamiTracker is capable of and seen what people like Shiru have done with it in using it to create sound effects, I'm thinking that FamiTracker could serve both music and sound effect purpose.
At present the FamiTracker re-implementation is not 100% complete but it is at least slightly useable for creating and playing back things.
cpow wrote:
phirobe wrote:
Hi. I'm new to these forums & I have a question regarding NESICIDE.
I have downloaded & installed the program & know what it is capable of, but am wondering when it says sound designers - does that include sound effects as well as music?
Just thought I would inquire on that.
Thx.
It has been my goal to include a sound-effect designer, yes. At the moment I am porting FamiTracker to Qt -- and if you create a Music object you'll see that FamiTracker is embedded in NESICIDE. You should be able to drag/drop an existing FTM onto NESICIDE and it'll add it to your project. I had thought a "sound designer" might look something like the SoundMaker in Garry Kitchens' GameMaker for the Commodore 64. But having seen what FamiTracker is capable of and seen what people like Shiru have done with it in using it to create sound effects, I'm thinking that FamiTracker could serve both music and sound effect purpose.
At present the FamiTracker re-implementation is not 100% complete but it is at least slightly useable for creating and playing back things.
ok. Hopefully the FamiTracker re-implementation is a focus for the next release. The only other thing that is an issue is the load startup on the application itself. I'm using Windows 8, have 12GB RAM & an AMD 8-Core Processor.. still takes about 2 seconds longer to finish that it should. But, other than that.. keep the fixes & improvements coming.
phirobe wrote:
ok. Hopefully the FamiTracker re-implementation is a focus for the next release. The only other thing that is an issue is the load startup on the application itself. I'm using Windows 8, have 12GB RAM & an AMD 8-Core Processor.. still takes about 2 seconds longer to finish that it should. But, other than that.. keep the fixes & improvements coming.
It is a focus, yes. Slowly and surely coming more into focus than not.
I don't have access to Windows 8 so I can't comment on start times. I am curious, though, what your expectation is? "2 seconds longer than it should"? How long *should* it take? It does load a plethora of DLLs during start-up.
EDIT: Welcome to the forum, by the way.
cpow wrote:
phirobe wrote:
ok. Hopefully the FamiTracker re-implementation is a focus for the next release. The only other thing that is an issue is the load startup on the application itself. I'm using Windows 8, have 12GB RAM & an AMD 8-Core Processor.. still takes about 2 seconds longer to finish that it should. But, other than that.. keep the fixes & improvements coming.
It is a focus, yes. Slowly and surely coming more into focus than not.
I don't have access to Windows 8 so I can't comment on start times. I am curious, though, what your expectation is? "2 seconds longer than it should"? How long *should* it take? It does load a plethora of DLLs during start-up.
EDIT: Welcome to the forum, by the way.
Well, if it takes that long to load due to having to load a lot of DLL's.. couldn't you just go back to using the old model? MFC?
I dunno.. You might be good with Qt4, but the old MFC App - probably saved a lot of startup load time.
Again, I am looking forward to the next release-update & thx for the welcome. Keep up the good work... hopefully you could implement SNES Development with NESICIDE? lol
phirobe wrote:
Well, if it takes that long to load due to having to load a lot of DLL's.. couldn't you just go back to using the old model? MFC?
I dunno.. You might be good with Qt4, but the old MFC App - probably saved a lot of startup load time.
Again, I am looking forward to the next release-update & thx for the welcome. Keep up the good work... hopefully you could implement SNES Development with NESICIDE? lol
This message is too damn funny having read
viewtopic.php?p=125171#p125171 just a day before.
phirobe wrote:
Well, if it takes that long to load due to having to load a lot of DLL's.. couldn't you just go back to using the old model? MFC?
Anybody who thinks MFC is the way forward is full of MFC (Mother Fcuking Crap).
But seriously, cpow abandoned MFC because MFC works only on Windows, and depending on whom you talk to, OS X and */Linux are each beating Windows 8 in usage share.
thefox wrote:
phirobe wrote:
Well, if it takes that long to load due to having to load a lot of DLL's.. couldn't you just go back to using the old model? MFC?
I dunno.. You might be good with Qt4, but the old MFC App - probably saved a lot of startup load time.
Again, I am looking forward to the next release-update & thx for the welcome. Keep up the good work... hopefully you could implement SNES Development with NESICIDE? lol
This message is too damn funny having read
viewtopic.php?p=125171#p125171 just a day before.
What makes it even funnier is that I was just thinking how cool it was that NESICIDE is drawing people here. But the suggestion to go back to MFC makes me wonder if I just got botted.
If so, damn these bots are gettin sophisticated!
phirobe wrote:
Well, if it takes that long to load due to having to load a lot of DLL's.. couldn't you just go back to using the old model? MFC?
I dunno.. You might be good with Qt4, but the old MFC App - probably saved a lot of startup load time.
Again, I am looking forward to the next release-update & thx for the welcome. Keep up the good work... hopefully you could implement SNES Development with NESICIDE? lol
phirobe: I would like to be helpful but I haven't got anything quantifiable from your concern other than vague statements about how long NESICIDE takes to start up in Win8. How long, exactly, does it take? How long, exactly, do you think it should take? The reality is I probably won't be able to meet your expectation but your report that it is taking too long is probably not ungrounded, so I am trying to understand where we're at.
As for going back to MFC. No. I am trying to be helpful to others beyond "just run my shit in Wine, yo". I do have a special place in my heart for MFC. But I think of it fondly as a memory, not as a desire to ever go back.
cpow wrote:
I am trying to be helpful to others beyond "just run my shit in Wine, yo".
On the other hand, that approach can be refined. The FCEUX team has handled my reports of crash bugs in the debugger under Wine, and game developers using TransGaming's Cider say "we've tested our stuff on Wine, at least the version included in the game's installer."
v2.0.0 is out. This includes Windows, Linux, and OSX distributions. For the meanwhile they are temporarily stored on my server until I can get Travis/AppVeyor configured properly.
DownloadAs for features, not much new. Just getting back into it a bit. I have plans for a few things:
1. Better support for VICE C=64 integration. Loading/debugging via D64 disk images. Less 'buggy' remote monitor integration.
2. Solution-esque setup a la MSVS with multiple projects per solution.
This comes up when you try to run the program:
Attachment:
printsupport.PNG [ 8.88 KiB | Viewed 4181 times ]
I tried stealing the DLL from my Dropbox installation, but I think it's a different version, it gives me another error regarding the entry point to a procedure.
Sumez wrote:
This comes up when you try to run the program:
Attachment:
printsupport.PNG
I tried stealing the DLL from my Dropbox installation, but I think it's a different version, it gives me another error regarding the entry point to a procedure.
Strange that windeployqt didn't pick that up. Hmmm.
Sumez wrote:
...
Try now. (Same link...)
Seems to be working
I'll let you know if I run into any other issues.
For the record, the emulator is as slow as it's always been (if not even slower?). I don't know what the issue is, but I'm getting the assumption that you prefer working with the Linux version yourself, so the problem could be specific to Windows
Sumez wrote:
Seems to be working
I'll let you know if I run into any other issues.
For the record, the emulator is as slow as it's always been (if not even slower?). I don't know what the issue is, but I'm getting the assumption that you prefer working with the Linux version yourself, so the problem could be specific to Windows
What are your machine specs? I'll try on my native Win7 sometime today.
Windows 8 64-bit on a laptop computer with a 1.90GHz Radeon R6.
Sumez wrote:
Windows 8 64-bit on a laptop computer with a 1.90GHz Radeon R6.
Strange. It works fine with debugging enabled at update on pause on my Win7 laptop.
8GB RAM, dual i5 @2.6GHz
I know my emu isn't snappy especially when it's being debug-inspected more often than just "update on pause" but it should at least work without audio artifacts on a reasonable computer.
I wonder if it's a Windows 7/8 thing? Do you have access to any other Windows machines you can try it on? I'll check my work computer but even that is still Win7.
I've been using it on a Windows 10 computer with the same issue, but that's it. I'll see if I can find Windows 7 somewhere to see if it makes a difference.
As for audio artifacts, that's actually a big issue too
It keeps making a clicking noise, but I always figured that's related.