Highly experimental draft assembler and linker.

http://www.obelisk.demon.co.uk/files/65016.zip

Unzip and open a command prompt in the directory then use NMAKE to assemler boot.asm and link into output files. Linux lovers will need to tweak the Makefile a little. Needs a java 1.6 JRE/JDK installed on the command path. (Type java -version to check for one).

The binary and hex file outputs from the linker look OK but need more testing. The S19 output is bugged.

I'm off for some sleep

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

My plan at this point is to go back and make sure none of the changes has messed up anything else. A test suite is so helpful with that , but I think I'm going to add something new that verifies identical behavior with the existing version where tests haven't changed between versions. Just checking for matching error/non-error behavior has let little things slip through before.

If that doesn't turn up anything horrible then I want to document HXA as it now exists and post it as v0.180. With any luck, should be available this weekend. It's miserably hot in the workroom today (no A/C and a heat index over 100), so there might not be much progress before then.

Well...that turned out to be 36K lines of differences, mainly because I modified file listings. Hardly "identical". I only looked at the first 6K, found a couple of things I didn't like, and changed them.

Anyway, version 0.180 is up at

http://home.earthlink.net/~hxa

The only lapse is that the on-line copies of the test programs are not properly updated due to alphabetic case issues and the sheer number of changes I have yet to make (god I hate case-sensitivity). All the rest of the on-line documentation should be okay, and the various *.ZIP downloads should be fine.

TT, Bitwise - thanks for the updated assemblers. I managed very little technical stuff over the weekend, but I do plan to port the hex loader to both syntaxes (unless a single syntax suits both)

I did get a listing from BitWise's assembler, from which I might have tried to extract a hex dump, but of course some of the hex is still zero at that point, so probably not worthwhile. I did that by using cpp to process the #defines, but really I'd want to rewrite them as labels.

Cheers
Ed

It's probably already occurred to you, but it's just occurred to me (slow learner, right?) that the 16/16 address format of an Intel 32-bit address works out really nicely as a 6502-style 2-byte pointer: record type '4's data field is just the high "byte" of the address, and record type '0's offset field is just the low "byte". They're even in the proper order as far as internal octets go, if I understand that correctly. Read 'em and store. Nothing to it! Set the Y-register to zero and you're all set to read and store data octets.

Or, hmm, set the low "byte" of the pointer to zero and set the Y-register to the offset. The only hazards would be the possibility of the offset + data bytes running over a 64K boundary, or the offset "wrapping" at that point. Those should never happen, but you never know when you'll run into a badly formed record.

We need not go into how I know about badly-formed records...

If you use .ORG (or *=) to set an origin within the .CODE section then the assembler will generate absolute address (as in the example boot ROM). You still need to link to convert the .OBJ output into a binary or hex file.

You only get zeros in the listing when expressions are not resolvable without linking.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Ah, top tip. I shall perform the comparison!

TT: I immediately notice that the
directive is packing characters in a big-endian fashion, unlike .byte:


Because I'll be talking to an 8-bit peripheral connected to the LSByte, I will be needing my strings to be little-end justified, which is what BitWise does. Is this something I can fix in source, or is this a bug report?!

(BitWise's tool will allow a string argument to a .byte directive:
but I think HXA does not.
)

Thanks to both of you, of course - I could use either tool as-is, if I had to, and both are a step up from the previous one.

Cheers
Ed

Here's a curious one for you Bitwise: the loading of some binary constants isn't coming out as expected:

(It's very handy having two tools to compare!)

".string' is actually doing what I told it to (and as documented), so if there's a bug it's a failure of my imagination. The sequence to me looks little-endian; it's the ".byte" sequence that looks big-endian.

I assume you initialized with a sequence like this:



Try this instead:



That should swap the order of octets in string characters. BIT16 (aka ".byte") will "naturally" have octet order 10 in an MSB-first machine, so it doesn't have to be changed. BIT32 (aka ".word") will "naturally" have octet order 3210, so it does have to be changed. If you never plan to use reversed order words you don't need the BIT32R assumption, but it's there for completeness (and won't hurt anything if present).

But it never occurred to me that ".string" should be affected by byte sequence changes. If strings are considered sequences of bytes, perhaps it should have.



True. OTOH, ".string" arguments can be either string or numeric expressions (which will get cut down to the least significant octet).

Hi TT
I tried changing the assume statements, but it changed the output code very significantly. As things stood, your tool and BitWise's are identical apart from the .string behaviour (and the binary constant.)

(This is parenthetical, because I think it's a diversion...) The first divergence is that
changes from
to

To revisit the string behaviour: a string constant in the source is a series of octets, and we want it assembled into a series of (padded) 16-bit bytes. BitWise places the input octet into the LSB, and HXA presently places the input octet into the MSB.

That is, HXA produces:
where I expect to see
because when I load from 0000F81F, I expect to load 0053, an 'S'

That is, I don't think there's any word-order problem here, so no need to change the assume statement.

Cheers
Ed

Okay, two separate issues.



Good but not enough. The ".cpu" statement changes as well, from

to


Changing from LSB to MSB is what swaps the octet order in string characters, as HXA will put the character octet in the least-significant postition and zero-fill the rest. For an 16-bit "byte" LSB descriptor that becomes "XX 00", and for an MSB that becomes "00 XX".

Tested that again; works as described.

Now for an LSB descriptor HXA by default extracts octets in the order 0->01->012->0123, for 8-, 16-, 24- and 32-bit quantities respectively. For 16-bit values you want the order "10" and for 32-bit quantities the order "1032", which is why the ".assume" is used to specify those. Reversed 32-bit quantities should come out "3210", but they already do by default, so there's no need to change that.

For an MSB descriptor the default extractions are 0->10->210->3210. The 16-bit value is in the the proper order, but the 32-bit values, normal and reversed, are not, so they need to be changed via ".assume".

That should take care of the first issue.



Actually it's not. It's a bug of sorts. In the file "i6502.a" there is this:



Look at the listing. "abs_mask" has the value $FFFFFF00, because changing the descriptor from "_L16" to "_M16" causes the match to be false and so "abs_mask" gets the second value, not the first.

Thus the address $0000FF00 becomes non-zero when masked, and is taken as absolute, rather than zero page.

Changing the code to this:



should be one way to make the match succeed and the proper value given to "abs_mask".

...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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs