6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 5:59 pm

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Tue Sep 03, 2019 3:18 am 
Offline

Joined: Tue Sep 03, 2019 3:10 am
Posts: 5
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?


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 6:14 am 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 1:50 pm 
Offline

Joined: Tue Sep 03, 2019 3:10 am
Posts: 5
BigEd wrote:
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?
:-|


Attachments:
File comment: Screenshot
possibleBugMistake.PNG
possibleBugMistake.PNG [ 28.89 KiB | Viewed 1888 times ]
Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 2:27 pm 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
It might be that you need to build differently. Perhaps experiment with this setting:

Code:
                        ;load_data_direct (0=move from code segment, 1=load directly)
                        ;loading directly is preferred but may not be supported by your platform
                        ;0 produces only consecutive object code, 1 is not suitable for a binary image
0001 =                  load_data_direct = 1


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


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 3:28 pm 
Offline

Joined: Tue Sep 03, 2019 3:10 am
Posts: 5
BigEd wrote:
It might be that you need to build differently. Perhaps experiment with this setting:

Code:
                        ;load_data_direct (0=move from code segment, 1=load directly)
                        ;loading directly is preferred but may not be supported by your platform
                        ;0 produces only consecutive object code, 1 is not suitable for a binary image
0001 =                  load_data_direct = 1


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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 9:13 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
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:
Code:
00000400  d8 a2 ff 9a a9 00 8d 00  02 a2 05 4c 33 04 a0 05  |...........L3...|


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 11:06 pm 
Offline

Joined: Tue Sep 03, 2019 3:10 am
Posts: 5
Chromatix wrote:
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:
Code:
00000400  d8 a2 ff 9a a9 00 8d 00  02 a2 05 4c 33 04 a0 05  |...........L3...|


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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2019 11:37 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
What happens if you include:
Code:
ORG 0
 DB 0
…or whatever equivalent works in that assembler? That should force the image to start at address zero.


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 04, 2019 12:36 am 
Offline

Joined: Tue Sep 03, 2019 3:10 am
Posts: 5
Chromatix wrote:
What happens if you include:
Code:
ORG 0
 DB 0
…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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 04, 2019 2:17 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 16 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: