This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NESASM

NESASM
by on (#76804)
I've been modifying the source code to PCEAS to add more functionality. I realized that NESASM is part of that source code and the changes I've made apply when I build NESASM with the internal switch.

So that point, if people still use NESASM - anything you would like to see added? Mind you, I'm not a professional level C programmer. I normally just write support utilities for my console programming needs. And while PCEAS/NESASM source code is a headache and a half, I've been getting fairly familiar with it in the short time I've been debugging/tracing through it.

What I changed/added so far:

- No more 8k opcodes greater than 1 byte crossing errors. I completely uncapped the range, incremented the page and bank registers. So don't have to worry about instructions giving errors on page crosses for 16k bank setups. The banks are still 8k in size, so you still need to take care/track of the numbering system on your side.

- Added ".DWL" and ".DWH". No more manually having to tell the DB defined data to use the LSB or MSB on each entry. These do it automatically.

- Modified the macro naming rules. You can now use the dot '.' character in the macro name. This was driving me nuts for a while. Makes the macros look cleaner: move.b #$12, label or move.w #1234, label or etc.

I have plans to add a bank alignment function and some sort of define bank value for a label, like .DB/DB/DWL/DWH do. For those tri-split tables for when you need longer pointer arrays.

Any suggestions/comments/complaints? Is it worth it? Or does NESASM just need to die and I can just concentrate on PCEAS?

by on (#76805)
Perhaps you could make some sort of hybrid of ASM6 and NESASM/PCEAS.

by on (#76806)
16K BANKS. My only complaint.

by on (#76807)
Someone brought up the whole [] vs () indirect symbol thing on an IRC channel. But I'm not so sure that's an easy thing to fix. I'm used to using [] from PCEAS, so it doesn't bother me.

Adding a switch to the command line to use 16k banking is possible. I'll add that to the list. Or just an internal #define (I did modification/function addition stuff like that for HuC. A C compiler that builds asm code for PCEAS. Passing symbols directly to the assembler).


Quote:
Perhaps you could make some sort of hybrid of ASM6 and NESASM/PCEAS.


PCEAS and NESASM share the same macro system AFAIK. And IMO it's pretty damn powerful macro system. What are some of the strengths of ASM6?

by on (#76809)
Maybe default the bank size to 8KB but if you skip a bank, the last bank will be assigned a 16KB range.


And also, why not use both? Not like it hurts. I like [], but seems like () is standard. Oh well.

And I though ASM6 would be better to write games with for the + - system for labels, that needs to be added. But everything about ASM6 sucks to me. Not fun to set up banks and everything, but the + - branching system is amazing.

by on (#76810)
Didn't bunnyboy already do something very similar?
As far as I know, he took the nesasm 2.51 source and fixed it up a little. He removed the [] and () issue for indexed addressing for example.
He called it NESASM 3 and his nerdy nights tutorials are based on it.
I never used it much , so I can't tell you if it really makes the whole thing worth a try.
Or is PCEAS something completely different than the just nesasm from the magickit?
Sounds like PC-Engine assembler to me...

by on (#76812)
Yeah, adding +/- local labels should be doable. I kind of like them too. But I hate when people go waaaay over bard with them. When you start seeing them stacked as -- / ++ and ---- / ++++. Makes code less readable. If you need more then just one +/- in an area, the ".local" label is much cleaner and easier to follow.

Another thing I like, is redefinable symbols. I only had to use them once, and for another system/cpu (68k based) - but it was kinda cool. The idea of actually implementing it sounds like a pain though.

The problem with using () is that the parsing logic uses it for higher level logic. The way the parser detects whether a higher level assemble time calculation is inside those brackets if fairly complex. At least to me. But I'll look into it.

by on (#76813)
Quote:
Or is PCEAS something completely different than the just nesasm from the magickit?
Sounds like PC-Engine assembler to me...


It is. PCEAS is built from NESASM. And the version from Mkit pretty much just changes a few things between the two EXE builds (they share the same source code). I wasn't aware of bunnyboy's version. Although the version that comes with HuC, which has the newest Mkit source code, labels PCEAS and NESASM as 3.21 Denki release builds. That's the folk I'm using (HuC's included AS kit, not Mkit from MagicEngine site).

by on (#76814)
Okay, cool. Yeah, that sounds kinda hard, but if you can make it detect the variables/labels/whatever inside the opcodes, shouldn't you be able to "filter out" what is being done there possibly? And it's not like you can multiply with those, seems like if you were you'd probably just better write some better assembly. :P


If you do this....you'll like be my savior. XD

by on (#76815)
tomaitheous wrote:
But I'm not so sure that's an easy thing to fix.


It wasn't "easy" to fix, no. I fixed it in my assembler that uses flex/yacc. I had to add a couple of disambiguation rules to the grammar to cover the cases where the one-symbol look-ahead of the parser couldn't otherwise disambiguate the meaning of the '(' token in the stream.

The parser code is here.

Obviously yacc takes LALR(1) grammars and turns them into C code so there might be some way to take what I did and translate it into your C code [I assume you're using C].

Figuring that part out was one of the most fun parts of writing my own assembler. 8)

by on (#76819)
tomaitheous wrote:
just changes a few things between the two EXE builds (they share the same source code). I wasn't aware of bunnyboy's version. Although the version that comes with HuC, which has the newest Mkit source code, labels PCEAS and NESASM as 3.21 Denki release builds. That's the folk I'm using (HuC's included AS kit, not Mkit from MagicEngine site).


Oh, that thing is still under development :o
I thought that project was abandoned years ago.
The version that I have here on my laptop is with nesasm 2.51 (as I said) and as far as I know that's from 2003 or something.
"NESASM 3.21 Denki release builds"
Never heard of these...doesn't sound like they were made by the same people as the old versions...

by on (#76822)
I found this: http://www.nespowerpak.com/nesasm/

Which has this: http://www.nespowerpak.com/nesasm/NESASM3.zip
and the source code: http://www.nespowerpak.com/nesasm/nesasmsrc.zip

I looked at main.c and it still has the same 8k page instruction boundary error/check.

http://pastebin.com/TTZkBFjW

If that is bunnyboy's build, the identification string has been removed from defs.h. It also looks like it was modified from an older source file set than from the Mkit AS source files used in HuC. Because all the PCE references are still in there, but older style (looks like Mkit 2.51 CD references). Though the exe reports 3.1 IIRC.

I did some text compare and little has been changed between the source, so I still haven't found what he changed for [] to ().


cpow: Yeah, if I was writing this from scratch - I think it'd be a little easier in some respects. It's not much fun trying to figure out someone else mess, let alone my own ;)


3gengames: Would -/+ labels as .- and .+ be ok?

Like:

.-
rol zp1
bcs .+
dez zp
bne .-
.+

You could stack them too like: .--- .+++, etc. From what I've seen in other assemblers, they still have to obey the same rules as local labels, right? Or are they even sub level regular local labels? As in, you can redefine then again in between local labels (and not global labels)?

by on (#76823)
tomaitheous wrote:
I did some text compare and little has been changed between the source, so I still haven't found what he changed for [] to ().

I don't think that was fixed/changed in bunny's version.

by on (#76825)
Grumskiz wrote:
Oh, that thing is still under development :o
I thought that project was abandoned years ago.
The version that I have here on my laptop is with nesasm 2.51 (as I said) and as far as I know that's from 2003 or something.
"NESASM 3.21 Denki release builds"
Never heard of these...doesn't sound like they were made by the same people as the old versions...


Nah, same people. Dave Shadoff, David Micheal (sp?) and Zeograd (he modified some ancient 6502 C compiler from the 80's and turned it into HuC compiler layer to build the ASM layer for Mkit, to assemble the code eventually into rom or CD). I'm the only one that did anything with it in the past few years. I didn't care for using C myself for these old consoles, but I thought it would have been great for beginners or people not that serious to get something up and running on their console.

I worked on the back end library for a couple of years. 2008 or so. The library is all written in ASM, so it made it easy to add C level functions, Pragma_fastcall was an awesome function for defining C functions that passed directly to the assembler (avoiding using the slow as crap software stack) and argument overload too (I think PROCs already do this, so maybe it was just pass through for PROCs). But no one ended up using it, save for a few people that made some demos. I added SuperGrafx support and Arcade Card support too. But meh, it doesn't natively support 24bit pointers so it makes any serious coding/projects almost worthless.

by on (#76837)
Why not do ++: and --:? Thats fine if you can't do that, but the . would be a little weird. Oh well, whatever you choose. Just tell me how to use it. XD

by on (#76843)
What's the use of having :-, :--, :+++ etc as the label names anyways? CA65 just has one unnamed label, ":".

E.g.
Code:
    bne :++
:
    jmp :-
:

by on (#76845)
thefox wrote:
What's the use of having :-, :--, :+++ etc as the label names anyways? CA65 just has one unnamed label, ":".

I see advantages to both methods. The second way looks cleaner, but if by any chance you need to add another ":" in a block, you'll need to revise all branches and fix the number of +/-. If the multiple +/- are in the label instead, even if you add/remove more labels the references won't be screwed up.

by on (#76855)
3gengames wrote:
Why not do ++: and --:? Thats fine if you can't do that, but the . would be a little weird. Oh well, whatever you choose. Just tell me how to use it. XD


":" is used for global labels. You don't particularly need it, but it signifies the end of a global label.

"+" and "-" are not allowed in any of the symbol hashing routines. But for some reason that you did, +: would be a global label. And if you tried to use it again - you'd get a multiple label usage error.

In nesasm, putting a '.' before any label for an address marker, makes it local. Meaning you can reuse it. I could modify the string to hash routine if it knows in advance that this a local label, to accept those to character values. "." in nesasm is the same as "@" local symbol in other assemblers.

For my usage of - and +, I've always just done generic names with numbers after them, in local label format. Like .loop1 or .skip1, etc. I can always reuse all those label names anywhere else since they're local. But I think anyone coding for 65x assembler probably already knows about the general rules of local labels.

But anyways, yeah. That's why I would precede them with the local dot operator.

I guess I could try and added a new/alt local symbol hash routine if whitespace=0 and starting char = - or +. I guess I'll do this next/today.

On a related note: In nesasm/pceas you can assign/equate a local label tp a global symbol, as long as you're inside the local labels domain. This makes it easy for two things: If you have a routine that might have multiple entry points, but you want all the labels inside the routine to be local to avoid making unique labels (if you're done this, you know exactly what I'm talking about). The second is for self modifying code. I.e. code that sits in ram and you want to modify the operand of an instruction or the instruction itself. You can use local labels for these entry points, then inside the code equate that to a gobal symbol (and adding the offset if it's just the operand an not the opcode).

by on (#76857)
In my opinion, heavy reliance on anonymous labels just makes the code harder to follow, and in some cases, harder to maintain; If you add an anonymous label in the middle of an anonymous-rich block of code, you'll be tasked to update all of your branches, and there's a lot of room for error with that.

It just feels dirty, and I don't know where everyone gets the conception that it's a good idea.

by on (#76891)
I implemented .- and .+ labels, but there's a problem.

The higher level operation parser assumes such characters are reserved for operators. I added an additional test logic that if the starting label uses a local dot operator '.' then these characters are ok and don't fail the string test.

The problem is this:

.--test

john_doe = .--test+$10

The parser assumes .--test+ is the string and not .--test. This causes a fail to identify the symbol and thus and unidentified symbol error.

This would fix it:

john_doe = .--test + $10

But that breaks compatibility older 65x source that uses compact writing for the operator logic (like I tend to do: http://pastebin.com/KewPeR0b ).

I know the point is - / + support. But adding via local label also breaks it even if you didn't start the local label with -'s or +'s.

I'll see if I can just reserve the exception of using - and + for label local label definition and branch only instructions. So using it for anything else will not work (you wouldn't need it anyway).

If I have to write a whole 'nother duplicate routine for this and more test code, I think I'll just write in the support for it directly as - and + without the local operator. It's turning out to be much more work than I had originally thought.

by on (#76893)
Drag wrote:
It just feels dirty, and I don't know where everyone gets the conception that it's a good idea.


Same point of view here. I just opt for local labels instead since it make more sense to me. But I guess everyone has the right to his own opinion regarding this concept.

by on (#76894)
Local labels are worthless in ASM6, because they can't cross any non-local labels, not even +/- labels.

by on (#76897)
Dwedit wrote:
Local labels are worthless in ASM6, because they can't cross any non-local labels, not even +/- labels.

Exactly. I thought it was great that local labels were added a while ago, but once I realized they can't get past +/- labels I concluded they weren't useful at all.