decoding and understanding BIN files

[space387]

I have entered a few entry addresses at this point and have cleared from 0x3000 to about 0x6000 with 40 entry points. Is this normal or am I doing this the hard way and overlooking something?

At this point I run the disassembler and look for the next data point thats not broken down, add that address as an entry point and re run it. Its not too time consuming but wanted to be sure its the proper way to do this.

[1project2many]

That's the right approach but you can do some sanity checks to ensure the entry point is actually real code. If you find a series of instructions that don't make sense, for example, a series of the same instructions with little code in between, you're probably looking at a data table rather than code.

[space387]

That's the right approach but you can do some sanity checks to ensure the entry point is actually real code. If you find a series of instructions that don't make sense, for example, a series of the same instructions with little code in between, you're probably looking at a data table rather than code.

are there any other instructions to enter for that kind of information? I have also noticed that the use of 00 is turned into test for just about everything, can these just be removed from 0989 - 2fff?

I added where I currently am and changed it to an ASM file so Notepad++ will color everything by the variable type.

[1project2many]

Please note that I realize not all of this is new to you, but I am including it for completeness and for others who may follow.

-------

I wouldn't advise removing the data from the calibration sections below 0x3000. It can be helpful to have the actual values present when working through the code. Your disassembler should have a control file... enter "org 3000 entry 3000" or similar so the origination point is marked and the data at lower addresses is treated as data. Some examples from a control file I created for $6D, also a 7727 calibration:

load 8000 ; Beginning of file

org A000 ; Places label org at 0xA000
entry A000 ; begin disassembly at 0xA000
entry a1fb ; End of a data table
entry a741 ; end of a data table

label 3ff6 IGNTIM ; replaces "3ff6" with "IGNTIM" in all locations in the disassembly
label 400C CPUCOP ; replaces "400C" with "CPUCOP" in all locations in the disassembly

-----------------------

Here's a section of code the disassembler missed:

brset	*L0029,#0x01,LB00D
clra	
clrb	
subd	*L005D		
bra	LB00F
.byte	0x7E,0xB0,0xA1 <-----------------
LB00D:	ldd	*L005D
LB00F:	subd	L801E

It recognized the unconditional branch at 0xB00f. But it skipped code immediately after the branch. But it recognized the code at 0xB00D because there is a conditional branch to that address earlier in the code. Jumps and branches often cause this disassembler to skip bytes. So what to do? I could add an "entry B00A" in the control file and let the disassembler go. But a good sanity check, especilly if there are a large number of skipped bytes, is to grab the instruction set and look up some machine code.

Mnemonic  Operation Addressing               Instruction               Bytes          Cycles
                               Mode         Prebyte  Opcode  Operand
JMP             Jump        EXT             —         7E       hh   ll          3               3

so 7EB0A1 is JMP $B081. Since it's a real piece of code that makes sense I'll go ahead and add "entry b00a" to the control file.

You'll also notice it's common for the disassembler to choke after RTS:

LCA76:	clc	
LCA77:	rts	
	        .byte	0x3D,0xFC,0x3F,0xFA,0x85,0x40,0x27,0x0D
	        .byte	0x14,0x2D,0xC0,0x15,0x2E,0x20,0x13,0x2E
	        .byte	0x40,0x03,0x14,0x2E,0x20,0x85,0x08,0x26
	        .byte	0x18,0x14,0x27,0x80,0x3C,0xCE,0x40,0x02

For these I usually just add another entry into the control file. RTS is a one byte opcode so the entry address will be CA78. Easy as pi. In the file above I find this:

3C8B			bra 	L3C90
3C8D	L3C8D:  	rts 												; CRef: 0x3CDE,0x3CE3,0x3CE8,0x3CEF,0x3CF6
3C8E	L3C8E: 	pulb												; CRef: 0x3C84

After the RTS we have 3C DE 3C E3 3C EF 3C F6
This might be code. It would be "psh x ldx 3C addd 3C LDAB..." This is a tough combination to believe is code imo due to the pattern of the numbers. I'd say its more likely a short table.

[space387]

I was looking to remove the "blank" space between the end of the known stock calibration section of 0x0989 and 0x3000 as there is no known data or referencing at this address range. Oddly enough the definitions I found to add in see to be more a hindrance than a help as without them the calibration section now stays data.

Also for uniformity with other dis files I have found and the memory address I have changed my load address to 8000 and the entry to B000.

[Scorp508]

I just wanted to say thank you for including the full details for "those who come later" as here I am 4 years later and this thread is very helpful as I'm trying to disassemble/document a BIN right now. :) Cheers!