nesdev.org

I seem to have a lot of fun doing random stuff with asm6.

Well today I decided to try turning it into an assembler for the snes.

Current features: automatic register size detection (possibly not for all opcodes), 24-bit addressing, basic support for all opcodes except for pei, mvn and mvp afaik.

With the fact that work started on this literally today, there's bound to be bugs and there's most definitely crappy code that can use a rewrite, but this has been a stressful and tiring couple of hours so I'm already itching for some feedback.

Windows users, a 32-bit binary can be found in the repo. Not preferable but easier to keep up with than binaries on here.

https://github.com/nicklausw/asm16

I'm just glad to see you're still around. We can't afford any more losses to the SNES community.

Binary would be helpful.

And example code of a functional SNES template.

Espozo wrote:I'm just glad to see you're still around. We can't afford any more losses to the SNES community.

Yep, I'm alive. thefox's tile tool thing gave me some hope so I'm back!

Binary would be helpful.

And example code of a functional SNES template.

(Insert misunderstanding here)

As for a full template, I plan on doing that today too.

I get the feeling dougeff was asking for a binary of the program and not just general binary support? In any case, I've attached 32 and 64-bit binaries for Windows, compiled with tcc.

edit: these builds correspond to hash 17a4e8c and are now outdated.

Thanks! I feel dumb now.

For now, You can use these macros as a temporary workaround for the missing three opcodes:

EDIT: SEE BELOW FOR UP-TO-DATE MACROS!!!

Added more to the list of temporary 65816 macros,

EDIT- Here is my modified version of the test.s included with ASM16, which was stolen from bass appearently.

Update, cleaned up the repository, added a makefile and an example program that uses a lot of stuff borrowed from tepples. If I clean up the sloppy parts (so everything that was my code), it might end up being a good starting place for some new snes devs.

Also added some opcode aliases from here. I'll start regularly building windows binaries as soon as I figure out how cross-compilation works.

Edit, just added pei, inc a and dec a.

Another edit, added mvn and mvp too. Had to add them as directives, but syntactically they're the same as if they were just opcodes.

PEI.

I'm assuming you also included PEA and PER ?

(Not that I use them.)

dougeff wrote:PEI.

I'm assuming you also included PEA and PER ?

(Not that I use them.)

Yep, the gang's all here. Except WDM (opcode 0x42). If you want that, I recommend a macro but due to asm6's internal design, I need at least one byte that isn't an opcode (but rather can be used to mean "stop looking for addressing modes, this meets none of them") and WDM is the easiest.

The first "real release" is up. Gonna quote the changelog on this one. Say, if I were to implement automatic direct page handling, would it just be a case of tracking the value of A, then switching on TAD? The bigger question, would it even be useful? I'm not sure if it's necessary as most people are willing to use the < operator to rid of the higher byte of their opcodes for DP use, but it just seems like a nice feature to have to handle that for you if need be.

What I mean is that the following code... ...would have the assembler auto-replace the last line with stz $00.

You can't track D in general, but there's a proposal in cc65's GitHub issues to allow setting the direct page base. It arose in the context of HuC6280, which fixes D at $2000 (unlike most 65xx which fix it at $0000). Thus the code might look like this:

tepples wrote:You can't track D in general

Perhaps not with ca65, but "linkerlessness" makes a different story. If you mean what I think you do, anyway.

On its final pass at the latest, asm16 absolutely knows every value that it reads in, assuming that the code has no errors such as a label typo. And so if you say lda #$2100 then tad, it is possible for the program to grab the higher byte of A and set all incoming could-be-direct-page opcodes accordingly...if it tracks A, which just seems like an odd thing to do. Makes the assembler basically double as an interpreter, which I suppose isn't a bad thing. The program already does that with REP and SEP tracking.

Not sure why I felt the need to expand on that so much; I could have just said "it's capable". Whether it's necessary is where I'm still kinda mixed.

Forgive me, if this is already true. I don't see it documented.

There should be a way to cast a value to direct-page, absolute, or absolute long.

Please don't try to guess that the user wants a direct page (based on D values). I would rather that you use direct page if the address (or label) is < 0x100. Absolute if the address is between 0x100 and 0xffff. Long if the address is >= 0x10000.

Then the user can force direct-page by using...

LDA <(label)

And maybe force long (from absolute) if you add or use a vertical bar,pipe | operator

LDA $800000|label
or
LDA $800000+label

How do you have it detect that the user wants LONG addressing?


And, now that I think of it, how would you force a long address back to absolute ? With & operator, maybe ?