Introduction

You see, back when I started development on Dual BASIC, it was a fairly small project. I could pour into it lines of code after lines of code, and not worry about bugs that weren't self-evident or required little time to analyze. Things changed drastically however, when I started working on the expression evaluator that is the core of the language in it.

Since it was my decision to implement 100% of the project by myself, I used my own code... and of course, it started giving all the wrong results, all over the place. In the end, I understood that it would not be possible for me anymore to continue coding unless I had some way to visually debug the code.

Thus I started coding a new Windows C++/CLI application, with Visual C++ Express (2008), that would let me debug the algorithms I placed on Dual BASIC... but, somehow, I got carried away, and started to think how this "test bed" application could provide an environment closer to the Nintendo DS hardware than just a simple Form with C++ code. And, somehow, I just liked how things were going with it.

So, here it is.

---

  
Downloads

devkitARM r23b, libnds 20071023:

Visual C++ Express 2008 project: NDSWinTestBed.zip
Latest update: 2008-09-12

The project is available, free of charge, under MIT-style licensing terms.

What's implemented:

• Touchscreen & keys
• VBLANK Interrupt, VCOUNT value
• Mode 0 BG0 - BG3 rendering with priorities
• VRAM_A - VRAM_I banks physically available
• Console output (stdio & stderr), iprintf
• Named hardware registers for most of the above

What's not (yet) implemented:

• Assigning VRAM banks other than A for top screen, C to bottom screen to BGs.
• Modes 1 to 6 rendering (including all forms of rot/scale & bitmap modes)
• Video OBJs
• Extended palettes
• 3D. Still need to figure a way to emulate the registers the way 3D hardware needs.
• File I/O. Mindboggling, huh? Of course, this only applies to fatInitDefault(); you will strangely notice that, in spite of it returning false, most stdio functions work properly.
• Custom ARM7 code
• Sound
• WiFi
• All other things not mentioned on this section.

What's unlikely to be implemented:

• Hard-coded, numeric DS-specific RAM addresses. Seriously, do I have to explain why? Important: libnds provides "named registers" for most of these (0x04000000 -> DISPLAY_CR), these ones *will* be supported, if present.
• fat:/, fat0:/ - fat3:/ path recognition. Unfortunately, I'm not knowledgeable enough of the Windows platform to perform this trick natively.

---

  
Usage guidelines


Copy the single folder you will see in the .zip file you just downloaded in the root of your project. I'm assuming your project's folder follows the recommended structure laid out by the template NDS projects in the /examples folders. Believe me, it's easier that way.

Please be absolutely sure your original project compiles, and generates a valid .nds file just fine. This is vital, especially if you have "binary" files linked to your project via bin2s.

Double-click the .vcproj file. This Visual C++ project is based on the "Windows Forms Application" template project, with the following changes:

• The "Header Files" & "Source Files" folders each have two new subfolders, "NDS" & "source". "NDS" contains the files required for libnds emulation, as well as other things missing from Windows, that devkitARM actually contains. "source" is the folder destined to reference your own .cpp / .h files from your project.

• "Resource Files" contains an additional "ASCII.bin" containing the BG data from the default font used in libnds applications.

• There is an "app.config" file containing the application settings for this test bed, including key mappings, the temporary files for console output redirection, and various timing values for VBLANK, among other stuff.

• [Properties] - [Configuration Properties] - [C/C++] - [General] - [Additional Include Directories] contains the following: "$(ProjectDir)\NDS";"$(ProjectDir)\..\source";"$(ProjectDir)\..\build", pointing to the places the project will give priority when looking for header files. Keep an eye on the two last ones.

• [Properties] - [Configuration Properties] - [C/C++] - [Preprocessor] - [Preprocessor Definitions] contains two new macros: _CRT_SECURE_NO_WARNINGS, to shut off the compiler when it complains of you using most of the stdio - string libraries, and NDS_WIN_TESTBED, the macro that tells your project the test bed project is the one being compiled. Keep an eye on this macro too.

• [Properties] - [Configuration Properties] - [C/C++] - [Advanced] - [Force Includes] contains "NDS\nds_missing.h". Yes, this is evil, evil beyond any other form of conceivable evil. It is, also, the only way I could manage to provide functions that, for devkitARM / libnds, should be present in the standard C files (like, say, iprintf).

• [Properties] - [Configuration Properties] - [Build Events] - [Pre-Build Event] - [Command Line] contains "$(ProjectDir)bin2c $(ProjectDir)ASCII.bin $(ProjectDir)ASCII_bin.cpp". This command will build the ASCII table in the form of a .cpp file so it can be included as an array. You will notice bin2c, the tool in use here, serves the same purpose as the bin2s tool in libnds makefiles. Remember this.

• Finally, [Properties] - [Configuration Properties] - [Build Events] - [Post-Build Event] - [Command Line] contains "copy app.config "$(TargetPath).config". This is just to be sure that the app.config file will be in the same folder as the final executable.

Place a reference to all of your .h / .c / .cpp files in the "Header Files\source" and "Source Files\source" folders, respectively. If required, edit your [Additional Include Directories] line so it references the appropiate folders inside your project; just be sure to let "$(ProjectDir)\NDS" as the very first item on it, or it won't find the sources to emulate libnds.

Later, when you compile the project, you might find an error message from the compiler, saying you can't compile .c files inside a project with /clr option enabled. There are 3 possibilities:

1. Rename your .c file to .cpp . BEWARE: There are subtle, and sometimes important, differences between a "pure" C source file and a C source file compiled as a C++ source file. Ask a C++ expert, and he will tell you about them.
2. Right-click the .c file, go to [Properties] - [Configuration Properties] - [C/C++] - [Advanced], and switch the [Compile As] option to "Compile as C++ code (/TP)". BEWARE: The same advice as given above applies here.
3. Rework your .c file so it becomes a real, full-fledged .cpp file. This is the recommended approach, if it is feasible for your project.

If your libnds project uses bin2s to link binary files to the executable, please be sure that the [Additional Include Directory] contains "$(ProjectDir)\..\build" (again, this is assuming your project structure matches the template libnds projects, and you placed the NDSWinTestBed folder in the root of your project), and/or edit it so it references the .h files your libnds project generated for you.

Then, edit the [Pre-Build Event] text and append the following:

• $(ProjectDir)bin2c $(ProjectDir)..\Path\To\Your\Binary\File1.bin $(ProjectDir)File1_bin.cpp
• $(ProjectDir)bin2c $(ProjectDir)..\Path\To\Your\Binary\File2.bin $(ProjectDir)File2_bin.cpp
• $(ProjectDir)bin2c $(ProjectDir)..\Path\To\Your\Binary\File3.bin $(ProjectDir)File3_bin.cpp

and so on, for each binary file linked to your original project.

Finally, locate your main() entry point. Replace it with the following:

#ifdef NDS_WIN_TESTBED
int nds_main(int argc, char* argv[])
#else
int main(int argc, char* argv[]) /* or whatever is your original main() */
#endif


Whew! It was hard. But, that's it. You should now be able to visually debug your code inside a Windows application attempting to match as much of a Nintendo DS device as it is possible.

If you find that the test bed doesn't emulate something you need, but a Windows alternative can be provided, use the NDS_WIN_TESTBED macro to control the access to them. And, please, by all means, drop me a line telling me so I can provide it for the next iteration of the project, will you?

I, honestly, sincerely hope that Dual BASIC becomes the development tool of choice of millions of people around the world. But, alas, if it can't be, I hope you can find this libnds test bed for Windows project useful for your debugging needs.

---

Contact us

Comments, suggestions, critics, all of them are welcome. If you have any of those, please write us at heribertod@gmail.com. Just one detail: we cannot provide instructions for installing and/or running homebrew applications in hardware, since the methods are many and varied; we don't have any particular preference for any particular method.