I'm trying to learn SNESdev. I've loaded palettes, tile data, and nametable data into VRAM, and scrolled the screen based on the controller. The next two things to attack are sprites and sound. Eventually I want to share the music sequence interpretation code between my NES and Super NES music engines, which probably means I should write the music engine in 6502 code and use SPC700 assembly with 6502-style mnemonics. Ideally, the only code that would differ would be the instrument handling stuff. I reimplemented the 6502 instruction set with macros as a proof of concept for eventually implementing the SPC700 instruction set with macros, but I ran into a snag: ca65 offers no way to test whether a label is zero page (.importzp) or not (.import). The new .addrsize(label) function, prototyped by Movax12 in a fork of the ca65 repo, is one way to solve this.
In #nesdev, another method was suggested: add support for SPC700-in-6502-drag directly to the instruction encoder of ca65. This way we'd end up with a starting point to get away from WLA-DX and the like. But I imagine that even though this approach might work for SPC700, it might not work so well for far-less-6502-like coprocessors such as SM83 (Sharp's 8080-like CPU core in the LR35902 SoC of Game Boy and Super Game Boy) and Super FX. That's where macro packages come in.
Whether SPC700 is implemented as a macro package or as a modification to ca65 itself, testing it would need these deliverables:
In #nesdev, another method was suggested: add support for SPC700-in-6502-drag directly to the instruction encoder of ca65. This way we'd end up with a starting point to get away from WLA-DX and the like. But I imagine that even though this approach might work for SPC700, it might not work so well for far-less-6502-like coprocessors such as SM83 (Sharp's 8080-like CPU core in the LR35902 SoC of Game Boy and Super Game Boy) and Super FX. That's where macro packages come in.
In this post, slobu wrote:
Most experience newbies (ha!) start by hacking the provided examples and work there way towards original code.
Whether SPC700 is implemented as a macro package or as a modification to ca65 itself, testing it would need these deliverables:
- A test case that exercises all instructions, with the source code and the expected binary. In the other thread I made such a test case for 6502 that has all instructions in opcode order, with the operand being a nibble-swapped version of the opcode, and I verified it by inspecting ca65's listing. For example, on 6502/65816, JMP $C4C4 would produce 4C C4 C4 in the listing's object code column. On SPC700, that line would be LSR $C4C4 instead.
- A program that runs on a SPC700 that just plays a chord. This needs a bit of SPC700+DSP programming experience.
- A program for the Super NES that loads this program and runs it.