How to develop for Nintendo 64 - Where to begin Ok, so here's the scoop. I've got a Partner-N64, and a manual of sorts, which is 100% in Japanese. I'm not quite sure where to begin. I've found a copy of the SDK installer package online, which has been installed, but again, no idea how to use any of the software. Does anyone have any information or leads as to how this all works? Any kind of reading material that would be good to start with? I have a small collection of stuff of material that I've been collecting online, but still have no idea where to begin. Here are the resources I've been collecting: http://level42.ca/projects/nintendo-64-development/ (It's my own site, not sure if there are rules against posting it, please let me know and I will remove the link.)
You seem to have everything needed. Dig into the samples of the Ultra SDK, compile them, then use the Partner N to load the roms on the n64. Easy
Beautiful! You should definitely consider archiving and (hopefully) sharing those floppies with the community. I'm not sure that they've ever been made publicly available before. I wonder if they contain the elusive exegcc compiler.....
I wish I knew what software to use, and how to use said software. Any suggestions? Any reading material I should start with? The software is entirely in Japanese, I'll probably upload the disk's later on, once I understand what they are. I've already got backups of the 4 disk's, because we all know how reliable 1.44" floppies are ... --- Also note, I've built my "Dev" PC on Windows XP, I assumed it would be more then suffice to handle the Win 95/98 software, alternately, would you recommend using Win 95/98, instead of Win XP?
Make sure you make actual disk images of the disks, don't just "backup" the files. You'll need Win 95, 98 or Me. NT based systems won't be able to communicate with the card without a driver, and it seems unlikely one would exist. To use the Japanese software you'll probably even need a Japanese edition of Windows or you'll run into code page issues (Japanese software used SJIS strings). There should be English versions somewhere though. Note the card's hex switches. These control the card's port address decoding and it's up to you to make sure there isn't a conflict--ISA isn't plug and play.
How do I make an image of the disks? I copied the data, and was able to install the software from my "Copy" that I made. I'm going to try and build a Win 98 machine instead. I should be able to get away with an English Windows 98, with Japanese language pack. As for the cards hex switches, I don't even know what to do with them as I have no instructions in english. This is partly what I'm here to try and find out. I've never used ISA devices before.
You can make a floppy disk image with any disk imaging tool (WinImage is a popular one), or "dd" if you have a *nix system. Simply copying the files modifies the file attribute(s) and doesn't preserve the original FAT data of course. It's important to make images when you're archiving media to preserve the historical integrity (DOS disks can effectively be dumped losslessly with a standard PC disk controller), also for determining data integrity (so other people can directly compare their disk images to yours), and because there could be cool hidden data on the disk (such as source code, hidden notes or image data) that is ignored by the OS when you copy files/directories that someone might find. It's good practice to always make images of everything. Re the decoding: check the switch positions, they're probably set to the default I/O address which was chosen to not conflict with other common periperhals at the time. The left switch is the most significant 4 bits, middle is middle 4 bits, right is least significant bits. Together they make a 12-bit address that specifies the base address of the card (or range, some of the bits probably won't be used for decoding). To make sure you don't have a conflict check all devices in the device manager for their "I/O range". Unfortunately you'll need to know which bits are used by the Partner card for decoding. It appears that the high 4 bits aren't (A15-A12), which might means that the card is decoded to EVERY 4 KiB of memory in the (64 KiB) I/O address space, so you could have to check all 16 mirrors for conflicts. You might be able to find some reference to I/O addresses in the Japanese text to get an idea which base is suggested. This could also be important if you have to specify the base address to the communications software; if any bits aren't used you'll probably have to mask them out when giving the address. If you're really serious about N64 dev you probably shouldn't bother with the Partner until you're already comfortable with the platform, if at all (though you might still want to use Nintendo's toolchain immediately). The Partner is nothing more than a simple cart emulator which inconveniently interfaces via an expansion card. The only upside over 3rd party "solutions" is that you'll get some software debug facilities and not have to roll your own, but maintaining a Win 95 machine is probably not even worth that. A more modern machine will give you a much faster build-test cycle, plus emulators give you hardware debugging.
If you wanna develop for the Nintendo 64, I've heard a Doctor V64 is a good alternative to test your work on instead of having to pay for higher development tools or hardware i believe
Exactly how you have it pictured. The board's silkscreen designates the switches A15-0. The card is set to 0320h (or possibly F320h if the disconnected hex switch is pulled up *and* fully decoded--not likely) http://en.wikipedia.org/wiki/Input/...ce_assignments_in_IBM_PC_compatible_computers I don't think it's likely to conflict with anything in a 90s computer.
Not in my experience, at least on the N64. Emulators allow a whole stack of noncompliant behavior like unaligned memory addresses, 32bit instead of 64bit addresses, allowing ROM execution within the exception handler, ignore memory mirroring, etc. Most don't implement the full opcode set (including traps, which you may be using for debugging or certain homebrew toolchains) and implement some hardware addresses as read-only when they are writable. Plus, you'll have to use an LLE RSP plugin as all HLE plugins have known and sometimes serious inaccuracies. Using the PC board allows interaction at runtime and full access to rdram and registers--at least if you're using Nintendo's toolchain or something similar. It's a nice advantage to say the least. Incindentally, Win9x can be upgraded with a kernel extension and other useful tools. Since there is a limit of 512MB(?) ram native that can be used by the OS, most people set any additional memory into ramdrives. You can wind up with a pretty fast system if you know what you're doing.
Sorry guys, just wanted to let you know, I haven't abandoned this thread, but rather, put it on temporary hold. I'm trying to get windows 98 up and running before I continue, but my hardware (NIC and GPU) is giving me issues, I'm currently sussing out some alternate hardware. Will reply soon, Thanks for the help thus far. (Also note, I have an Everdrive 64 as well, but I want to develop using the KMC kit I have)
