Hello Everyone,

First I would like to Thank Mr. Klaus Dormann for publishing his 6502 functional test. It has been instrumental towards the development of my 6502 emulator.

At this point my code seems to emulate the 6502 pretty well. I still need to perform some optimizations and clean up the code though. Since I am not interested in emulating the Decimal mode, it is currently failing in the Decimal ADC/SBC instruction tests. I am wondering if I can assume that my emulator passed all tests (except for decimal tests) at this point?

I guess I would not be asking this question if I could assemble the source. I have been unsuccessful downloading the required assembler. All links to the download seem to be dead.

Any suggestions?

Welcome! Indeed, I think it's true that the decimal ADC/SBC are the very last tests.

The official upstream sources are in Klaus' repository here:
https://github.com/Klaus2m5/6502_65C02_functional_tests

Within the repo, together with the sources and the binaries, you will find a listing, which might well help you:
https://github.com/Klaus2m5/6502_65C02_ ... lst#L13193

There's a copy of AS65 by Frank Kingswood (or maybe Frank Vorstenbosch) here:
https://github.com/hculpan/h6502/tree/master/as65
which is, I think the latest. There's an archive of the original page here:
http://web.archive.org/web/201903011236 ... ssemblers/

(There's another, unrelated, AS65, by Andrew Jacobs, in his Dev65 package. There's also an as65 in the cc65 distribution, again unrelated.)

Thank you very much for the information!

I was able to download version 1.42 from the archive. I unziped and tried to assemble the functional test and everything went smoothly without syntax errors or anything. However, the program is starting at 0x3F6 instead of 0x400 as expected. I tried adjusting my emulator to start at that address and everything fails badly within the first few instructions. I guess this is expected given the offset. See the attached picture. I assembled by running the following command: as65 code.asm

I also made a listing file by running: as65 -l -h0 code.asm
and the listing says the code segment starts at 0x400. Am I doing something wrong here?

It might be that you need to build differently. Perhaps experiment with this setting:



Edit: perhaps see this previous thread:
viewtopic.php?f=8&t=2495&start=15#p32656

No dice. I wonder if it has anything to do with the fact that I am running win10 64-bit. I will try the DOS version with dosbox.

Thanks a lot Ed.

You definitely have some sort of offset in the object code. This is what the official build shows at $0400, preceded by a block of $FF bytes:

That's right. I tried the DOS version of the assembler and the result is the same. It is offset by 0xA bytes. The ORG directive is pretty straight forward. If code_segment is defined at $400 the code should start there. For some reason it is not.


I already tried all possible configuration combinations. The composition of the file definitely change with some configuration options.

I will write a little program to see if I can duplicate this behaviour.

What happens if you include: …or whatever equivalent works in that assembler? That should force the image to start at address zero.

Chromatix, it seemed very strange to me that Klaus' first defined segment was at $A and the assembled code was offset exactly by this amount. As you mentioned, I added an org 0 directive to force the assembler to output the remaining bytes and everything is working perfectly now.

I disabled the decimal tests and my code gets trapped at the success infinite loop.

I guess the the file was originally assembled using a switch that does just that. I dont see it in the manual though!
It's funny that the listing file generated is correct even without the padding. sounds like a bug?

Anyways, thanks to everyone for the help!

I guess now I will just clean up my code some more. and keep playing with an emulator I want to build.

Generally an assembler is designed to produce a program that *doesn't* start at address zero. This is especially true on the 6502, which treats addresses $0000 to $01FF specially. ROM images, in particular, will start at some high address like $8000 or $C000, and it makes sense to emit a 16KB image to fit a 16KB device (or a pair of 8KB devices) rather than fitting the entire 64KB address space.

So it sounds like it's taking the lowest address specifically defined in the listing as the start of the binary image. Klaus' test suite is simply unusual in terms of which bits of memory it pre-fills.

Text-based object files may not appear to suffer this problem, because they usually specify the addresses for each line of data explicitly. It is then straightforward for a loader running on the target device (or an in-circuit-emulator device wrapped around it) to interpret each record and put its data in the correct place.