6502.org

Thank you Nelson, good to know.

Hi Klaus, I understand that you don't wish to port your functional test suite to any other assembler. May I ask why this is? What feature(s) do you require from as65 that prevent you from considering a different assembler? Thanks for your thoughts.

I am the author of the assembler for the llvm-mos project. It is a GNU-compatible assembler.

There were 2 main reasons to use AS65:

1. I had used another assembler from the same author for some 6805 projects and was familiar with the syntax which the author kept identical over these and many other microprocessors.

2. I had actually looked at some other free 6502 assemblers and found, that their output listings were quirky to say the least. The output listing is the number one debug tool for the functional test and as such should be as readable as possible.

Once I decided to use AS65 I kept it that way simply because it works for me. I am just to lazy to provide a port to other assemblers.

I took a look at the as65 syntax, and it's quirky, but consistent. Perhaps at some point I will get around to making the LLVM-MOS assembler support it as an input format.

I would like to see an assembler supporting indented blocks with pseudo opcodes. For example: IFNE would be defined as a BEQ to the next line with the same indent level, LOOPNE as a BNE to the next previous line with the same indent level. That would get rid of many cryptic labels like XYZ1234.

That can be done with macros, as I show in that section of my website at http://wilsonminesco.com/StructureMacros/ . Most labels are gone. With the program flow control macros, indentation is not obligatory, but should be considered standard practice, for clarity. They are nestable too, with other types or more of the same time, and each branch will go to the right place. I have more-extended examples in the last 40% of the page about simple multitasking methods at http://wilsonminesco.com/multitask/index.html, and more about how their innards work in section 17 of my 6502 stacks treatise at http://wilsonminesco.com/stacks/pgmstruc.html . In the last listing on the page, regarding a CASE structure, you can mouse over the underlined source code parts to get the explanation of the assembler's operation on the particular line. "Stack" there refers to the assembler's stack, not the 6502's stack.

Andrew Jacobs' As65 assembler has program-structure capability built in. See http://www.obelisk.me.uk/dev65/as65.html . Unfortunately he died last November. I don't know if his website will disappear when the DNS registration expires. Hopefully we'll still have the site on archive.org.

Anton Treuenfels' HXA 6502 assembler also has program-structure capability built in. See https://web.archive.org/web/20190208204 ... .net/~hxa/ .

Hi Everyone,

So, after going through a painful debugging process, I found out why Where in the World is Carmen Sandiego was freezing on my Apple II+ Emulator. It turns out it was doing an indirect jmp to $8989 which itself contained $FF (and $898A contained $7C). This should result on a jump to $7CFF. But I had implemented logic on my 6502 emulator to reproduce the indirect jmp bug:

NB:
An original 6502 has does not correctly fetch the target address if the indirect vector falls on a page boundary (e.g. $xxFF where xx is any value from $00 to $FF). In this case fetches the LSB from $xxFF as expected but takes the MSB from $xx00. This is fixed in some later chips like the 65SC02 so for compatibility always ensure the indirect vector is not at the end of the page.

However, my code was buggy. I was taking the MSB from $xx00 when the LSB from the resulting address was $FF (as opposed of doing this when the indirect address, ie, the first operand was $FF). Even worse, I was calculating $xx00 by substracting 0xFF from $8989. So, instead of jumping to $7CFF, I was jumping to $85FF ($85 being the contents of $8890).

This was a tough one.

Anyways, wanted to share once again.

While detecting my mistake does not make sense, IMHO, I believe my code was not behaving properly when the actual bug was hit and the indirect vector finished on $FF, as my code would not properly detect the boundary condition. It would be great if we could update Klaus test to detect and alert of this error as well, making sure that any indirect jmp to an address whose contents is $FF, always takes the MSB from the address $00 on the same page.

Hi Nelson,

I have a JMP indirect page crosser test in the 65C02_extended_opcodes_test. But even that has only 2 landing zones for either the presence of the original 6502 bug or for the fixed JMP() on the 65C02. Your hosed up fix would not result in a simple to debug error condition. Instead an unpredicted landing would cause other tests to fail and the only indication of the origin of the failure would be the test sequence number pointing to the JMP() page crosser test (test_case=$09).

Of course I could implement a test for the special conditions your JMP() failed with. However, I think it is a one in a million bug and therefore not worth the effort.

Keep on debuggin!