Windows MSI here.
OSX build hopefully coming soon.
What's new this time?
0. Emulator can now be run both internally to the IDE and as a stand-alone external application.
1. IDE is completely integrated with CC65 toolchain. Needs external installation available in PATH. Requires at least version 2.13.9 for debug information files. Version information can be seen in Help->About NESICIDE.
2. IDE is completely integrated with make, generates makefiles and uses them to build/clean projects. No "custom build step" support yet, but coming soon.
3. Integrated text editor is now based on Scintilla. Most useful text editor features are available in Scintilla and have been or will be soon made available in NESICIDE. Currently implemented: line-numbering; customizable syntax highlighting; breakpoint markings, source execution step point markings, "Execution Visualizer" markers, and compile error markings identified in margins; context-menu additions for additional features; hover-over tooltips for known symbols (name, address, value displayed) or for 6502 mnemonics (manual text for mnemonic displayed); draggable text to breakpoint window or symbol watch window instantiates a new breakpoint or watched symbol. Click in the editor margin to set/disable/clear a breakpoint (only after a compile has been done for now...)
4. Debug capabilities enhanced. Including: source-level and assembly-level debug stepping; symbol address/value watching with ability to modify symbol value if it is in volatile space.
5. Projects built outside NESICIDE that have valid .nes and debug-info (usually .dbg) files and source located where the debug info file says it should be can now be debugged in NESICIDE using the full debugger capability without the necessary .nesproject overhead.
6. Improved project management. All source and included binary files are managed as their own files, not within the XML project file. Project elements that are modified have appropriate modified markings in the MDI tabbed window area (a "*" postfix).
7. Improved UI experience. The application will now open up the most recently opened project if the tracking of such things is enabled in the Environment Settings. Projects keep track of set breakpoints and watched symbols and re-populate the appropriate debuggers when the project is loaded. Note, at the moment you need to hit Ctrl+Shift+S to ensure the project is saved after adding things like this that you want the project to keep. The size and position of the main window and all dockable windows is now remembered and restored correctly at application close/reopen.
8. Controller configuration preferences now remembers controller configurations. =] Controller configuration is shared between the IDE and the standalone emulator.
9. Test suite executive. This one I created so I could fully automate the process of running 180+ test ROMs in the emulator to check my progress while implementing changes to the emulator core. However, I realized very quickly that it could perhaps be useful for regression testing during development of a new NES ROM. It is XML-based. Currently the UI doesn't have the capability to add items to be tested (you have to hand modify a bit of XML), but that will change *very* soon. The test suite executive works on a list of test cases specified in some XML file, like this, which is a snippet of the 180-test-rom XML file I use:
* Note, I removed much of the CDATA content to make it briefer!
What this all means is NESICIDE can do the following:
For each <test> node, do:
1. Load the ROM (filename attribute).
2. Set up the NES console appropriately (system attribute).
3. Run the ROM for some frames (runframes attribute).
4. Do either:
a. Provide pre-recorded controller inputs to the test run during execution (the recordedinput element if present), or
b. Record inputs during the test run to be stored if desired.
5. Capture a SHA-1 representation of the NES video output at the end of the test run (the tvsha1 element).
6. Compare the captured data from the run with the previously stored SHA-1 and determine pass (or fail) if equivalent (the testresult attribute).
7. Ask if the test passed or failed and record the user input (the testresult attribute) if the SHA-1 does not match.
8. Capture and record notes and failure comments from the user when appropriate.
For regression testing you could set up a number of test cases in an XML file, each with different recorded inputs and video capture. Click "Run Tests" in the test suite executive, and get an answer as to whether something you changed in your game broke something you're testing. It is much easier than trying to remember controller input sequences that generate some weird behavior and trying to replicate them manually and exactly!
I have now reached the point where I can execute 180 test roms with just a few mouse clicks. As you can see above, some of those test cases are merely runs of the same test ROM with different controller inputs to generate different paths through the ROM and check the result.
I think that's it. I'm still alive!
OSX build hopefully coming soon.
What's new this time?
0. Emulator can now be run both internally to the IDE and as a stand-alone external application.
1. IDE is completely integrated with CC65 toolchain. Needs external installation available in PATH. Requires at least version 2.13.9 for debug information files. Version information can be seen in Help->About NESICIDE.
2. IDE is completely integrated with make, generates makefiles and uses them to build/clean projects. No "custom build step" support yet, but coming soon.
3. Integrated text editor is now based on Scintilla. Most useful text editor features are available in Scintilla and have been or will be soon made available in NESICIDE. Currently implemented: line-numbering; customizable syntax highlighting; breakpoint markings, source execution step point markings, "Execution Visualizer" markers, and compile error markings identified in margins; context-menu additions for additional features; hover-over tooltips for known symbols (name, address, value displayed) or for 6502 mnemonics (manual text for mnemonic displayed); draggable text to breakpoint window or symbol watch window instantiates a new breakpoint or watched symbol. Click in the editor margin to set/disable/clear a breakpoint (only after a compile has been done for now...)
4. Debug capabilities enhanced. Including: source-level and assembly-level debug stepping; symbol address/value watching with ability to modify symbol value if it is in volatile space.
5. Projects built outside NESICIDE that have valid .nes and debug-info (usually .dbg) files and source located where the debug info file says it should be can now be debugged in NESICIDE using the full debugger capability without the necessary .nesproject overhead.
6. Improved project management. All source and included binary files are managed as their own files, not within the XML project file. Project elements that are modified have appropriate modified markings in the MDI tabbed window area (a "*" postfix).
7. Improved UI experience. The application will now open up the most recently opened project if the tracking of such things is enabled in the Environment Settings. Projects keep track of set breakpoints and watched symbols and re-populate the appropriate debuggers when the project is loaded. Note, at the moment you need to hit Ctrl+Shift+S to ensure the project is saved after adding things like this that you want the project to keep. The size and position of the main window and all dockable windows is now remembered and restored correctly at application close/reopen.
8. Controller configuration preferences now remembers controller configurations. =] Controller configuration is shared between the IDE and the standalone emulator.
9. Test suite executive. This one I created so I could fully automate the process of running 180+ test ROMs in the emulator to check my progress while implementing changes to the emulator core. However, I realized very quickly that it could perhaps be useful for regression testing during development of a new NES ROM. It is XML-based. Currently the UI doesn't have the capability to add items to be tested (you have to hand modify a bit of XML), but that will change *very* soon. The test suite executive works on a list of test cases specified in some XML file, like this, which is a snippet of the 180-test-rom XML file I use:
Code:
<?xml version='1.0' encoding='UTF-8'?>
<testsuite>
<test runframes="660" failcomment="" testnotes="No inputs -- official only" testresult="pass" filename="cpu_timing_test6\cpu_timing_test.nes" system="ntsc">
<tvsha1><![CDATA[qiCw5Tc02sYX/zr58+sSEm2thAY=]]></tvsha1>
<recordedinput><![CDATA[]]></recordedinput>
</test>
<test runframes="780" failcomment="" testnotes="A pressed -- official + NOP" testresult="pass" filename="cpu_timing_test6\cpu_timing_test.nes" system="ntsc">
<tvsha1><![CDATA[fpbbQbbXCLSJiqSqKtGpjfhQ/Gc=]]></tvsha1>
<recordedinput><![CDATA[CAAAAABUdAAA...]]></recordedinput>
</test>
<test runframes="1020" failcomment="" testnotes="B pressed -- official + undoc" testresult="pass" filename="cpu_timing_test6\cpu_timing_test.nes" system="ntsc">
<tvsha1><![CDATA[pxjbcfJBNDWLLRn+1n1PARRTKAo=]]></tvsha1>
<recordedinput><![CDATA[CAAAAABUdAAA...]]></recordedinput>
</test>
</testsuite>
<testsuite>
<test runframes="660" failcomment="" testnotes="No inputs -- official only" testresult="pass" filename="cpu_timing_test6\cpu_timing_test.nes" system="ntsc">
<tvsha1><![CDATA[qiCw5Tc02sYX/zr58+sSEm2thAY=]]></tvsha1>
<recordedinput><![CDATA[]]></recordedinput>
</test>
<test runframes="780" failcomment="" testnotes="A pressed -- official + NOP" testresult="pass" filename="cpu_timing_test6\cpu_timing_test.nes" system="ntsc">
<tvsha1><![CDATA[fpbbQbbXCLSJiqSqKtGpjfhQ/Gc=]]></tvsha1>
<recordedinput><![CDATA[CAAAAABUdAAA...]]></recordedinput>
</test>
<test runframes="1020" failcomment="" testnotes="B pressed -- official + undoc" testresult="pass" filename="cpu_timing_test6\cpu_timing_test.nes" system="ntsc">
<tvsha1><![CDATA[pxjbcfJBNDWLLRn+1n1PARRTKAo=]]></tvsha1>
<recordedinput><![CDATA[CAAAAABUdAAA...]]></recordedinput>
</test>
</testsuite>
* Note, I removed much of the CDATA content to make it briefer!
What this all means is NESICIDE can do the following:
For each <test> node, do:
1. Load the ROM (filename attribute).
2. Set up the NES console appropriately (system attribute).
3. Run the ROM for some frames (runframes attribute).
4. Do either:
a. Provide pre-recorded controller inputs to the test run during execution (the recordedinput element if present), or
b. Record inputs during the test run to be stored if desired.
5. Capture a SHA-1 representation of the NES video output at the end of the test run (the tvsha1 element).
6. Compare the captured data from the run with the previously stored SHA-1 and determine pass (or fail) if equivalent (the testresult attribute).
7. Ask if the test passed or failed and record the user input (the testresult attribute) if the SHA-1 does not match.
8. Capture and record notes and failure comments from the user when appropriate.
For regression testing you could set up a number of test cases in an XML file, each with different recorded inputs and video capture. Click "Run Tests" in the test suite executive, and get an answer as to whether something you changed in your game broke something you're testing. It is much easier than trying to remember controller input sequences that generate some weird behavior and trying to replicate them manually and exactly!
I have now reached the point where I can execute 180 test roms with just a few mouse clicks. As you can see above, some of those test cases are merely runs of the same test ROM with different controller inputs to generate different paths through the ROM and check the result.
I think that's it. I'm still alive!