6502 Assemblers

[bartleph]

I wonder if someone might be able to help here. I have an assembly source file kindly supplied by another forum user many many years ago. I rekindled a 6502 project I had in mind and wanted to use this code. It is actually for OSI's Assembler which I want to relocate. I believe it may have been meant to be built using A65. I have come across some errors where the author has wanted to store Hi byte and Lo Byte values of an address pointed to by a label. Easy to use .Word or .DByte etc. In this code the values are not stored in adjoining memory locations but apart therefore it appears to want something like: .BYTE Low(label) or .BYTE High(label). How do I reference individually the High or Low bytes of an address label? I cant see an option in A65.

I might be missing the obvious here but it is some 30yrs since i did any serious 6502 assembly!!

Thanks

link to source is here:- http://www.decayaitch.co.uk/source.txt

[BitWise]

Try .BYTE <Label and .BYTE >Label

[BigEd]

Edit: oops, crossed in post.

I see this

Quote:

10440 ADDRLO .BYTE OP00,OP01,OP02,OP03
10450 .BYTE OP04,OP05,OP06,OP07
...
10550 ADDRHI .BYTE OP00/256,OP01/256
10560 .BYTE OP02/256,OP03/256

And with some assemblers I would expect that to work: putting a value into a byte will truncate it to the LSB, and if you first divide by 256 then you'll get the MSB.

But every assembler is different. I see A65 is the name of a disk-to-disk assembler for Atari - is that the one you have in mind? Ideally you'd be using an assembler that you have the source for, and it would always be possible to find out what it understands. But it might not be possible to do what you want.

If the problem is with the low byte, just possibly

Code: Select all

ADDRLO .BYTE OP00-OP00/256*256

would do it.

What error do you get?

[bartleph]

Hi BigEd,
Well that solved the Hi Byte Lo Byte issue. Thank you. I now have *Error* Invalid operand Field and it occurs in 8 lines where we have .BYTE and a label with a ? preceding it. Nothing in the A65 manual mentions a specific case for a label with a question mark at the beginning.... Line 867 L112A .BYTE DCIN,ASMOPT,?CMDERR-*

[BigEd]

Looks like it could be an error of the disassembler which produced this - my inclination would be to get hold of the corresponding binary ROM (the OSI assembler/editor) and see what bytes are in that area, and see how they might be expressed.

Edit: aha, I see we have the ROM from a previous thread here:
viewtopic.php?p=37966#p37966

[rwiker]

bartleph wrote:

Hi BigEd,
Well that solved the Hi Byte Lo Byte issue. Thank you. I now have *Error* Invalid operand Field and it occurs in 8 lines where we have .BYTE and a label with a ? preceding it. Nothing in the A65 manual mentions a specific case for a label with a question mark at the beginning.... Line 867 L112A .BYTE DCIN,ASMOPT,?CMDERR-*

Maybe it means the low byte of CMDERR minus the current address? (Since CMDERR-* looks like the difference between two addresses, and .BYTE indicates that we're looking for byte-sized data.)

[BigEd]

... so, we can see what byte values are needed from
http://www.decayaitch.co.uk/listing.txt
and we can see from the source that they are relative (because * is subtracted) but I can't say I know what's going on. (I've only looked at the two ?CMDERR cases... hmm, does everything just work if you omit the problematic ? characters?)

Edit: crossed in post again - yes, maybe ? is a low byte directive, which perhaps we don't need in this case.

[bartleph]

Thanks again guys. Managed to get a clean Pass 1 then Oh dear...425 Errors..Mainly Sync errors and I think they are just where lots of .BYTE Lines are not generating code. They are failing on 2nd Pass as *Error* Operand field size error, so I guess we are back to our Low/High byte issue. Taking out the question mark doesn't throw any obvious errors but I guess they could be contributing to the large number of sync errors. BTW OP00-OP00/256*256 shows as 00 in the listing so far.

[BigEd]

Hmm, maybe try
-OP00/256*256+OP00
or if parentheses are allowed
OP00-(OP00/256*256)

[White Flame]

The question marks might also be a character encoding error. Did the platform this comes from have a nonstandard character set?

BigEd's link showing the byte values is hard to trace through, because the labels don't match the addresses anymore. However, we can see that when * is used, it's from the address of the current byte being assembled, not the beginning of the line, as I tend to be used to:

Code: Select all

 9420 06E8 00             .BYTE NXLN,L06E8-*
 9420 06E9 01
 9430 06EA FD      L06E8  .BYTE $FD ;JMP TO L0620

L06E8 = the address 06EA, and the subtraction yields the byte 01, so it's subtracting 06E9 (the address of the 2nd byte of the line), not 06E8 (the beginning of the line).

Here's a reverse reference, from the last line up:

Code: Select all

 9610 0719 16      L0718  .BYTE COPY,$1C,DRTYPE
 9610 071A 1C    
 9610 071B 1E    
 9620 071C 11             .BYTE RETN
 9630 071D 3D      L071C  .BYTE CHK6+'-,L0729-*
 9630 071E 09    
 9640 071F EB38           .DBYTE L073B+OFFSET
 9650 0721 3D      L0721  .BYTE CHK6+'-,L0729-* ;GO TO L0729 IF DAS
 9650 0722 05    
 9660 0723 3C             .BYTE CHK6+',,L0718-* ;GO TO L0718 IF COM
 9660 0724 F5    

So even though it's negative, the F5 signed delta from 0724 (where the F5 itself is) does point back to 0719 (where L0718 is).

Now, where the question mark is used, forward references for ?IMMADR-*/?INDADR-* and backward reference for ?A2OUT-* seem to work the same, so it doesn't appear to have any effect. But all uses of * need to be carefully scrutinized if your assembler assumes that * starts elsewhere than the location of the currently processed byte.

[BigEd]

Could ? be a low-byte operator?

[White Flame]

I seriously doubt it. Label1-* and ?Label2-* appear to do the same thing, and .BYTE on its own is clearly extracting only the low byte without complaint, for both positive and negative numbers.

[BigEd]

Mmm, somehow ? is both legal and optional, would you say, for whichever assembler was originally being used?

[White Flame]

Again, I have a suspicion it could be a character encoding error. However, the fact that it only appears on label subtraction is odd. I could go through and check all cases, but it doesn't seem to affect the final byte calculation at all, compared to non-? label subtraction.

[BigEd]

That's why I suggested a low byte operator - not quite needed, and having no discernible effect. And if there's a low byte operator, maybe there's a high byte operator. Could be worth trying each non-alphanumeric character to see what happens. ! might be one to try.