6502.org

...and making those changes gives me this: ...which I think is what you are looking for. If not, well, more changes can be made!

Of course, to even cause that bug to occur means the ".cpu" statement had to have been changed. Oops! But I'm a little surprised the string octets (which would not have been affected by the bug in "i6502.a") didn't come out in the order you wanted after that, since they certainly do for me.

Great - the patch to i6502.a works a treat!

I didn't look too closely before, because once the operand length to one opcode was different I wasn't able to compare the output so easily - everything looked different.

Sorry for my rambling denial about byte order - I'd forgotten that internally to HXA you're treating the octets within a 16-bit byte as being in the other order, so when the listing says '00 A9' it looks right but internally the A9 is the MSB. So long as the loader does the right thing with packing octets into bytes, we'll be fine. The string constants now land with the same octet ordering as the opcodes, which is what we need, and HXA now produces the same output as BitWise's tool.

Cheers
Ed

My assembler uses prefixes for number bases (e.g. $ for hex, @ for octal and % for binary).

Make it lda #%00011111 and it should work fine.

Ah, indeed so.

The two assemblers now agree on everything!

Cheers
Ed

sorry posted to wrong thread!

Hi Teamtempest
Just stumbled across an oddity in your assembler: lazily relying on errors to help me port Bruce's pi program from 65816 to 65Org16, the assembler correctly rejected the PHY and PLY opcodes, but silently ignores the PHX and PLX opcodes.

It's not immediately obvious to me where the problem lies, but hopefully it's a small one.

Cheers
Ed

Odd. If you're using the "i6502.a" macro versions of the instruction set with the HXA_T version of the assembler, I don't believe PHX and PLX are even defined.

Hmm. If they aren't interpreted as pseudo ops (nope, none with those names), operators (HXA_T doesn't recognize any) or defined macros (shouldn't be), the only possibility left is that they are interpreted as labels.

This possibility is increased because PHX and PLX don't take arguments, so they can look like labels sitting by themselves on a line (and thus get assigned the current value of the program counter).

Still, HXA should complain the second time either of these appear because presumably the program counter will have a different value, and HXA doesn't permit that for non-variable labels (which these would be).

So without seeing the code you're trying to convert (I don't see it in the source respository here), my best guess is that PHX and PLX both appear on a line by themselves and only once in the program (but PHY and PLY do appear more than once, and it's the second and any successive appearance that triggers any error).

Or if more than once, then in only one section that's actually assembled (as opposed to sections skipped over due to some source condition turning off assembly for a while).

Or they appear more than once but assembly stops before reaching them the second time because the error count limit is reached first.

If none of these is the case, then clearly I need to see exactly what code is failing to generate a proper error message. I've actually learned quite a bit when HXA fails to generate the error I expect. This may be an opportunity to learn even more.

Hi TT
Ah, I think that explains it! Thanks!

I just started with Bruce's program posted here and dealt with each error spotted by your assembler.

PHY appears on a line with a label, so does give rise to an error. Also, I'd spotted that one myself, so was expecting to deal with it, and of course was already on the lookout for the matching PLY.

As you say, PHX and PLX are just taken as labels - they appear only once. (I suppose if the syntax demanded left-justified labels, or a period or colon marker, then there would be no issue. But I'm not complaining!)

Cheers
Ed

Hi Ed,

Well I'm glad that worked out. I've had a couple of other thoughts you might consider trying in an effort to get HXA to help you translate things.

Those opcodes defined for the 65c02 and other variant instruction sets, for instance. One idea is to define macros that implement them:
Of course this doesn't exactly duplicate PHX because the A register is trashed, which could be A Bad Thing (OTOH, what else can easily be done?).

Another idea, still using macros, is to make such instructions explicitly illegal as a tip that Something Needs To Change Here:
The error message that pops up should show the offending source line, which therefore shows the PHX (or whatever), so all bad instructions could reference the same macro:
Which would at least save writing out the same error message every time. If you didn't want to stop assembly at each bad instruction, you could change "fatal" to "error".

New instructions which accept or require arguments are no problem because there's no requirement they actually be used in the body of the macro:
This handles both "STZ addr" and "STZ addr,x" forms by using a default argument in case "X" is not specified (it could just as well be a null string as "@", and in some ways it would be simpler to do so if it was actually going to be used, but it's an idiom I developed before HXA could handle null strings).

New address modes on old instructions would be trickier, and most likely would require re-writing the existing instruction macros to recognize and reject the new mode, but it could be done.

As things now stand, I believe the ADC macro accepts "ADC (addr)" as "ADC addr" because the value of an expression enclosed in parentheses is the same as the value of the same expression without parentheses. That is, expression evaluation ignores them, so for them to be "meaningful" they have to be noticed and acted on before evaluation takes place. The 6502 instruction macros do pay attention if they also see a ",Y", but otherwise I don't think they care.

This method also has the advantage that macro names can be preceeded by labels, so the error happens whether or not there is a label on the same source line.

Thanks - I think a few .fatal macros might be a help, if one were likely to see code from broader instruction sets. It might not be a real problem now that I'm once bitten.

Interesting difficulty in ruling out the unindexed indirect mode though - probably best to leave that as another thing to debug. After all, the machine is never going to be source compatible, due to 8-bit assumptions not holding.

Do you think it's worth adding a label syntax, such as leading dot or trailing colon? As an option?

Cheers
Ed

Trailing colons on labels are already allowed, mainly to make it easier to port source that requires them. They're not really meaningful at this point, though. If HXA sees one it just gets stripped off before anything is done with the label. (BTW, a leading period on pseudo ops is also optional and is treated the same way. But it does help set them off from processor instructions, doesn't it?)

Offhand, I think the code changes necessary to make colons required on labels as an option would be relatively minor, but that's without looking at all the source. It'd also need a flag somewhere to tell HXA to use those changes instead of the default. Maybe the next version will have that.

The way things are set up now, that'd be much easier than, say, requiring labels to start in column one. I didn't actually want that because I didn't care for "anonymous" labels in that position in listings. It's kind of a moot point now that listing margins can be altered, but it took me a while to get around to making that possible.

I very much prefer a colon after a label. Otherwise when you do a search in your source code, you get lots of references to it before you find the label itself. There needs to be a way to say, "This is the label," as opposed to, "This refers to the label."

Hi TT
That's what I meant to say: making the optional required, optionally(!) - but certainly not a priority. As Garth says, it helps for searching too.

(I can't say how pleased I was to discover that on linux I did and by happening to have WINE installed it "just worked" - your assembler is cross-platform after all.)

Cheers
Ed

I see your point. Sorry if I wasn't clear. You as programmer can already use a trailing colon on any label you like. So if you want to mark all labels that lead source lines with trailing colons, go right ahead.

Internally for its own purposes HXA "normalizes" labels to a common format before using them for anything, so there's no confusion between labels leading source lines and the same labels in expressions. However the only place you as programmer will ever notice this is in a listing, where label names (if listed at all) are shown in their normalized form.