Getting started with N64 development? by breadcrust at 7:26 PM EDT on June 5, 2005
hello all, i stumbled onto this site while checking websites of users online at ZMD. :-)
Anyway, Ive been interested in developing some stuff for N64 for a while now, and found Neon64 here, decided that seems pretty cool, so you guys must [hopefully] know what your doing(? ^^)
So, where should I get started with this? What software is available (prefably that works on Linux). What hardware should I try and get? I've had a quick look at Dextrose and some other sites, but I'd like to hear it from you guys.
My programming skills: lots of experience with Tcl (and *shivers*, BASIC), a little bit with C and PHP. (Also XHTML/CSS/Javascript, but that doesnt count). My hardware: A PAL N64, which I may or may not overclock soon. A couple of computers ;-) (Hopefully a Passport III soon too).
All the real development I've ever done for the N64 has been in assembly. I've never gotten any of the free compilers to work to my satisfaction. While I haven't used anything but my own assembler for a while, I first learned N64 programming by studying and modifying CZN's trainer intros. (Here and here are some you can make without any effort, just type "make" at a DOS prompt. It was with these in mind that I built my own assembler's demo which will work right out of the box. I learned how to use the RSP by examining Destop's Heavy64 source and disassembling the ucode it came with. My assembler's demo includes code that runs on the RSP so you can look through them if that interests you. I am certain that you can use a GNU MIPS assembler to build N64 ROMs, all you need to do is affix the proper headers and calculate the checksum (my favorite is Checksum 64 which includes source). If you use the header file contained in the aforementioned CZN demos set your origin to 0x80000400 and simply concatenate your code onto the header, then compute the checksum (assuming you have less than 0x100000 bytes of code+data, otherwise you'll have to manually DMA stuff out of ROM, the header will only load the first 0x100000 bytes). The thing to know is how to use all the hardware registers to get your way. If you're feeling ambitious check out my sources for Neon64, as I use just about everything (VI, AI, ROM and controller (both joystick and controller pack) RSP, RDP (to some extent)) more or less correctly. Or you could look through this collection. N64OPS#H.TXT gives a full breakdown of the registers, and the opcode lists are what I used to write my assembler (before I finally went and bought the MIPS R4000 user manual).
If you want to do development in a higher level language such as C you probably can, I just don't know myself how to configure compilers to generate chunks of code as are needed. Most real N64 development was done in C using GCC or SN Systems' compiler, to my knowledge. You might want to write your own libraries for hardware access (it's fun!) or you could try to use the official libraries if you can find them (which a good many "public domain" demos do, shame on them).
Good luck and feel free to ask for further clarification or help.
i think ill look into a GNU MIPS assembler, and then into compling with GCC for N64.
I'm very much a high level language person, and have barely touched any asm, so I'm not too sure what I'll be like there, I'll just have to try it out and see. (its not that i havent tryed low[ish] level languages, i just prefer the flexibility of scripting languages)
i also need some hardware to transfer the rom from my PC to the N64. theres nothing i could use on ebay.com.au. the only place i found backup units in australia is at http://www.blade.cc/. anyway, what would you recommend i try and get?
If you want to go through a lot of trouble you can try loading programs with a Game Shark via the method I pioneered, but it makes the testing cycle so much longer that I feel it isn't worth it. I'd be glad to give you some direction if you want to give it a try, though, as I've wanted to make this a valid alternative for a while. I need to get back to work on my GSCC2k replacement... Personally I use a 512 mbit Dr V64 Jr. I bought it because I wanted the flexibility of being able to play absolutely any game, not because of its convenience for development, though it has served me very well over the past fiveish years. I bought it from someone I found on gametz.com. Check out Nintendo 64 Tech for info on various devices for guidance; I can't give you anything from first-hand experience. Your best bet is to get one used, and the Dextrose forums are probably the best place for that. eBay is useless for backup units, they remove the listings for them as soon as they can find them. Before my current v64jr I bought a 256 mbit version from eBay and it broke within a week.
If you do want to learn assembly MIPS is a good choice, as it is RISC and thus has few instructions to learn.
I'm having some luck with GCC and binutils, though building a MIPS cross compiler has proven to be a pain (I've had to refer to three different web sites on the subject to get all the info I needed). When I'm confident this is working well I'll post instructions and my makefile.
Whew, I was about to complain about how inefficient GCC generates code compared to my hand-written assembly (which I thought was odd because I'd heard a lot about how efficient MIPS compilers are), but then I remembered to throw in the -O2 flag. Now completely readable C code is as good as what I've written, without the need to write loops in freaky ways and explicitly make every variable a register.
If you've never witnessed it before (as I haven't) it's a thing to behold. Consider this simple function:
void fillscreen1(unsigned short int color) { unsigned int c; for (c=0; c < sizeof(scrbuffer)/2; c++) scrbuffer[c]=color; }
fillscreen1: andi $a0, 0xFFFF daddu $a2, $0, $0 li $v1, 0x257FF la $a1, scrbuffer loc_CC: sh $a0, 0($a1) addiu $a2, 1 sltu $v0, $v1, $a2 beqz $v0, loc_CC addiu $a1, 2 jr $ra nop
The only way I could think of making this better (other than writing in units bigger than halfwords) is to reverse the order of the loop so it ends when the counter == zero, that way you could save the sltu instruction. Cool stuff. And it's all running nicely on the N64. I'm going to work on writing some basic libraries, hopefully something more useful than my assembler's demos or g0dev (which is a very similar project that never achieved it's potential) will come out of this. Unlike g0dev I'm only using the GNU tools (with the exception of chksum64, which is open source in portable C) so this can all be used on any GNU system (cygwin for me at the moment).
A word of warning regarding the GNU MIPS binutils: type in elf32-mips.c. I don't know what version this persists until but it was present in mine which is well after the date on this post.