Assembler for Super FX?

[93143]

I've been using WLA DX for programming the 5A22, and I've had some success with simple mockups and such. The Super FX is not listed among the supported processors, but there seems to be some talk of a Super FX backend...? I've also heard of an extension to ca65 called casfx, and I'm probably not too far along in the learning process to switch to ca65 if there's a good reason to, but I don't have a clear idea of the tradeoffs involved in doing so.

How do people program this chip?

[Kannagi]

I answer just to say it interests me to program the Super FX.

[ARM9]

I dabbled a bit in superfx programming last year, I wrote casfx due to the lack of assemblers, you can find it here along with some very messy sample code: https://github.com/ARM9/casfx

Lately I started using bass instead of ca65, mostly because of its simplicity (I like one-shot assemblers). I added superfx support because I wanted to start programming it again, fork here: https://github.com/ARM9/bass

I tried to add helpful error messages in casfx, so it should be a lot more user friendly in general than bass, besides ca65 isn't really that much different from wla so that's what I'd recommend to get started.
The main problem with bass is that there are no utilities for making useful error messages so you're expected to know what you're doing, not very beginner friendly. On the other hand getting something to assemble with bass is extremely simple.

I've only found one other standalone assembler with superfx support and it was mostly broken.

[Near]

I do have warning and error messages in bass, but it's hard for me to know what makes sense to others.

I don't jump through hoops, so if you say "lda #3+6+", it'll say "expression error" and not "you forgot the number after the last + sign", but ... it prints the expression so if you just look at it, it'll be obvious.

Open to reasonable feedback, although right now I still need to update bass to use my newer string library updates before I can make any code changes.

[Sik]

Dunno, that error message seems reasonable to me (although the filename and line number are more significant than the line itself to me, although having both is nice I suppose).

[ARM9]

I meant for custom tables. For example there's currently no simple way to make "and r0" an invalid instruction (r1-r15 are valid operands), it'll silently assemble into a merge opcode, and there are more convoluted examples than that. That's my only gripe with it, well, that and unmatched { or } errors not displaying line numbers.
For example:

Code: Select all

macro foo(){ // should be () {
}

Sorry for not being more clear.

[93143]

I dabbled a bit in superfx programming last year, I wrote casfx due to the lack of assemblers, you can find it here along with some very messy sample code: https://github.com/ARM9/casfx

Lately I started using bass instead of ca65, mostly because of its simplicity (I like one-shot assemblers). I added superfx support because I wanted to start programming it again, fork here: https://github.com/ARM9/bass

I tried to add helpful error messages in casfx, so it should be a lot more user friendly in general than bass, besides ca65 isn't really that much different from wla so that's what I'd recommend to get started.

Cool; thanks!

Not a crowded field, is it? I'm glad someone's been here before me...

The reason I asked is that the game I'm planning to port seems to require a coprocessor to organize and render a rather busy 2D object layer, and I think my best option is the Super FX in high-speed mode. But the requirements, on paper, are broadly similar to the capabilities of the chip, so I figure I should do some algorithm testing sooner rather than later...

[ARM9]

The reason I asked is that the game I'm planning to port seems to require a coprocessor to organize and render a rather busy 2D object layer, and I think my best option is the Super FX in high-speed mode. But the requirements, on paper, are broadly similar to the capabilities of the chip, so I figure I should do some algorithm testing sooner rather than later...

Sounds like fun, what game are you porting?

[93143]

Sounds like fun, what game are you porting?

I've, uh, been trying to keep that under my hat. Partly because it's early days yet, and I don't want to hype something up and then not be able to pull it off, and partly because even if I do pull it off I have very little idea how long it will take. For one thing, I'm a numerical physics guy, not a hacker or game programmer, so I have virtually no relevant experience...

It certainly is fun, though. I haven't had to rein myself in like this on a hobby in a long time...

I will say this (since I've said it before in other threads) - it's a vertical-scrolling bullet hell game. There can be several hundred enemy bullets onscreen, so discrete sprite manipulation is unfeasible. Enter the Super FX chip and its PLOT opcode. With a 144x192 playfield plus borders, I should have enough DMA bandwidth for 30 fps at 4bpp or 60 at 2bpp. This is of course assuming the GSU can keep up, and my preliminary calculations indicate that it could be tight...