6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Oct 31, 2024 11:53 pm

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Thu Nov 12, 2015 9:52 pm 
Offline
User avatar

Joined: Wed May 30, 2012 7:45 pm
Posts: 58
Location: Dallas, TX
I was reviewing a hexdump of the Pitfall! binary...
I've been memorizing opcodes and thought I would try my hand at manual disassembly. Mostly for the heck of it.
Up until now, I've always relied on an assembler to handle everything. However, here's what I find when I do a raw hexdump:

Code:
$ hexdump Pitfall.bin | head
0000000 d878 00a2 00a9 0095 e89a fad0 7520 a2fa
...


The source code indicates that the ROM starts off at $F000 as its a 4K ROM. However, as you can see the very first
opcode is D8, which is the CLD instruction. Here's the dissassembly from what I can gather:

Code:
  CLD
  SEI
  BRK
  LDX #00
  LDA #00
  ...


So far, that all makes sense as these are the things you would do at the beginning of an Atari 2600 ROM. However, I don't
see the memory address $F000 anywhere. What am I missing? Also, if you disassemble further, it seems that some of the bytes
are backwards... for instance, 'fad0'... d0 is 'BNE' and 'FA' is not an opcode. Does this mean that 'FA' is stored little endian or something?
I know that BNE $FA would be "branch backwards 6 bytes". I guess there's more than one question here.

Thanks

_________________
http://www.thestarrlab.com


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 12, 2015 10:01 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
I think that your hunch about 16-bit little-endian display is the likely answer, Johnny. I don't know how to hammer out a quick script to swap them and check to see if it makes more sense, but I'm sure that you or someone like Ed could do it with minimal effort.

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 12, 2015 10:14 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10971
Location: England
Yes, byteswapping seems to help - try
Code:
xxd -e -g2
and you might see
Code:
00000000: 78d8 a200 a900 9500 9ae8 d0fa 2075 faa2  .x..........u ..

This gets rid of the BRK, which makes it much more plausible.

The data in a ROM starts at the beginning of the ROM, so a dump will by default just show it as starting at 0. When the ROM is in a system, the address decoding hardware will place it at some particular address. In your case, you believe the ROM starts at F000. Probably there's an option to xxd to help show that, if needed.

I did a quick disassembly using lib6502(*):
Code:
F000 78     x   sei
F001 D8         cld
F002 A200       ldx #00
F004 A900       lda #00
F006 9500       sta 00,X
F008 9A         txs
F009 E8         inx
F00A D0FA       bne F006
F00C 2075FA  u  jsr FA75
F00F A200       ldx #00
It does look plausible.

Edit: Try this to set an offset in your hex dump:
Code:
xxd -g 2 -e -o $(expr 0xf000)


(*) Using
Code:
./run6502 -l f000 /tmp/x -d f000 f012 -x


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 13, 2015 6:03 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8466
Location: Midwestern USA
Johnny Starr wrote:
I was reviewing a hexdump of the Pitfall! binary...

I see where Ed addressed the endianess issue.

Quote:
However, I don't see the memory address $F000 anywhere.

Assuming $F000 is indeed the address at which that code started, it was the source code, specifically, the .org or *= statement, that told the assembler to begin assembling instructions at $F000.

In creating a ROM, the source code is assembled to start at a specific address, such as $00E000 in my POC unit's ROM, that address set by the first .org or *= statement encountered by the assembler. The resulting object code is then burned into the ROM using an offset to the ROM's first cell, which is at $0000. Exactly what that offset would be would depend on how the ROM has been mapped into processor space. Again, using my POC unit as an example, the ROM is mapped in at $00E000. $00E000 accesses the ROM at $0000, $00F000 accesses the ROM at $1000, and so forth. Or, looking at it the other way, address $0000 in the ROM appears at $00E000 and address $1000 in the ROM appears at $00F000.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 13, 2015 7:27 am 
Offline

Joined: Sun Apr 10, 2011 8:29 am
Posts: 597
Location: Norway/Japan
Johnny Starr wrote:
Code:
$ hexdump Pitfall.bin | head
0000000 d878 00a2 00a9 0095 e89a fad0 7520 a2fa
...

[..]Also, if you disassemble further, it seems that some of the bytes
are backwards... for instance, 'fad0'... d0 is 'BNE' and 'FA' is not an opcode. Does this mean that 'FA' is stored little endian or something?

It's just that when hexdump writes 16-bit words it writes them in 'value' format, so for little-endian architectures like x86 and 6502 the value 32768 would be 0x8000 in hex, so even if it is physically stored as 00 80 it will be output as 8000 if you ask hexdump to output the binary values as 16-bit words. If you instead use hexdump -C (telling hexdump to interpret the values as single bytes) you would see
Code:
00000000 78 d8 a2 00 a9 00 95 00  9a e8 d0 fa 20 75 fa a2
and so on.


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 13, 2015 7:36 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
@Tor: Ahh! Best (and most helpful, IMO) answer yet!

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 13, 2015 10:35 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10971
Location: England
Ah - I wondered about that, after posting. It turns out xxd (my tool of choice) acts as I'd expect, whereas hexdump likes to deal in two-byte words.
Code:
$ echo abcdef | xxd
0000000: 6162 6364 6566 0a                        abcdef.
$ echo abcdef | hexdump
0000000 6261 6463 6665 000a                   
0000007

(In both cases they can be asked to operate the other way.)

If I'd read the original post more carefully, I might have thought of that.


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 13, 2015 3:06 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1745
Location: Sacramento, CA
Johnny Starr wrote:
The source code indicates that the ROM starts off at $F000 as its a 4K ROM.... However, I don't
see the memory address $F000 anywhere. What am I missing?


To verify the code actually starts at $F000, move to address $FFFC ($0FFC in the hex dump, which should be the last 4 bytes at the end). You should see the byte $00. At $FFFD, you should see the byte $F0. This is the 6502 reset vector and contains the jump-to address when the processor is reset. This is likely the only place in the hex dump you will find $F000, unless there is a error catching routine that would send you there.

Hope that answers this question.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


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

All times are UTC


Who is online

Users browsing this forum: No registered users and 14 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: