It's pretty straightforward if you read his slides. Overall I prefer it to ASM simply because it reduces busywork.
A few bugs:
- The "data" command doesn't accept hex. You have to convert values to decimal if you want to store them in ROM... though I guess you could use assembly and ".dw".
- MMC3.bas doesn't work. Refer to the NESdev wiki to write $8000 / $8001 correctly.
- MMC3.bas functions are poorly-named. Even NESdev doesn't explain bank mapping well. Fortunately Everything2 set me straight: the $A000 memory block is always swappable, and command 7 always points to it. You can set the $8000 block xor the $E000 block to also be swappable.
- Oh yeah, the xor operator (^) doesn't work. This made some bitwise toggling difficult.
- You can't dereference 16-bit pointers. Arrays larger than 256 bytes are not fun.
- Forward Polish notation isn't technically a bug, but it's definitely a mistake.
Actually getting bankswapping to work was confusing, but that's not really an NBasic problem. The iNES format uses 16K PRG banks , so if you declare ".inesprg 2" then you have 32KiB of Program-ROM. However, the ".bank" command uses 8K banks and zero-based numbering, so to put something in the last bank, you'd have to declare ".bank 3". Just to be difficult, BG/sprite data also uses 8K banks, so ".ineschr 2" only gives you 16KiB of Character-ROM. CHR-ROM comes after PRG-ROM, so if you declare ".ineschr 2" and ".inesprg 2", the CHR banks are 4 and 5.
To actually boot a game, you need code in the first bank and three addresses at the end of the last bank . Those addresses are the NMI, RST, and IRQ jumps - the locations the NES jumps to at the start of vblank, when the reset button is pushed, and when an interrupt appears, respectively.