DiStella and 8k+ files

[Cupcakus]

I know it has been discussed many times before, but the only step by step solution given is in this thread

 

http://www.atariage.com/forums/viewtopic.php?t=3214

 

I'm not sure what you are getting at here Thomas... Here is where I'm at, can anyone help me along?

 

Just for laughs I chose the Frogger2 bin to attempt this. I split the file into two 4k bits, no problem.

 

I discovered the correct ORG address for the first file and dissasembelled it... no problem.

 

Now I have another 4k file, I found the ORG address for this file and dissasembelled it. Now I have two disassembelled files that seem fine. No strange code, no BRK opcodes.

 

In File #1 I replaced the ORG line with an RORG line, then directly above it I put a ORG $0000 line.

 

In File #2 I replaced the ORG line with an RORG line, then directly above it I put a ORG $1000 line.

 

I deleted everything above the ORG line in file #2 (I left that data in-tact for file #1) and then copied everything from from file #2 to the end of file #1.

 

When I compile I get several errors:

Mostly "Label Mismatch" and "Branch out of Range"

 

What am I missing?

[Thomas Jentzsch]

You will probably have two START labels (one in each bank). You should rename one of them.

 

And a lot of definitions at the top of file #2 will have been defined in file #1 already.

 

You should delete all defintions that are lower than $1000 and add

include "vcs.h" (if you have that file!) instead.

 

BTW: I would start my ORGs at $1000 to avoid confusing with TIA register addresses and to force the assembler to use non ZP-adresses when accessing the ROM.

[Cupcakus]

It's worse than that. DiStella names it's labels after the address of the line of code. So the instruction at $F55E is labeled LF55E, the problem is that there are about 30 or so labels in both files with the same address, thus the same label in each file. When I put the two together I get mismatch errors. How can I configure DiStella to give each file a different kind of label?

 

DiStella(ing) an 8k+ file doesn't seem feasable. If anyone has accomplished this, shoot me the source file you ended up with that compiled. I will most likely be able to compare it to my source and correct the issues.

 

Thanks!

[Cybergoth]

It's worse than that.  DiStella names it's labels after the address of the line of code.  So the instruction at $F55E is labeled LF55E, the problem is that there are about 30 or so labels in both files with the same address, thus the same label in each file.  When I put the two together I get mismatch errors.  How can I configure DiStella to give each file a different kind of label?

 

Maybe that's too easy a solution, but how about Search & Replace "LF" with "LD" in one of the files for example?

 

Greetings,

Manuel

[Cupcakus]

OK.. (shrug) I came to the conclusion that DiStella can't do Frogger2. If someone can prove me wrong here, I would love it!

 

I successfully disassembelled, assembelled and ran Joust, Raiders of the Lost Ark, and DK Jr. So I know my methods were right, it just seems I can't get Frogger2 to give a valid output on the first file, no matter what ORG i give it.

[Thomas Jentzsch]

It's worse than that.  DiStella names it's labels after the address of the line of code.  So the instruction at $F55E is labeled LF55E, the problem is that there are about 30 or so labels in both files with the same address, thus the same label in each file.  When I put the two together I get mismatch errors.  How can I configure DiStella to give each file a different kind of label?

You must use two configuration files for DiStella that use different ORG adresses. Hope that helps.

 

 

DiStella(ing) an 8k+ file doesn't seem feasable.

No, it is possible with DiStella. I had to do this for my 8 and 16K PAL to NTSC conversions. It wasn't fun, but it worked.

[Thomas Jentzsch]

Update:

I just did some disassembling with Frogger II myself. The ORG for the first part is definitely $d000.

 

I think the main problem is the a bit more complicated bankswitching method (four 1K slices) that Parker uses. Therefore you have access to the last, fixed 1K ($fc00-$ffff) slice in both parts.

 

Here is my .cfg-file for the 1st part:

ORG d000

CODE d000 d08c

CODE d09d d102

CODE d10b d14f

CODE d158 d19f

CODE d1b0 d200

CODE d203 d319

CODE d31c d328

CODE d32b d33b

CODE d33e d3c3

CODE d3c6 d3d1

CODE d3d6 d47a

CODE d481 d58d

CODE d590 d66f

CODE d672 da3f

CODE da42 dab4

CODE dab7 dbff

CODE dc72 dcf9

CODE dd02 dd72

CODE dd7b dfde

 

After disassembling you can remove all output before ORG (those addresses pointing at $dxxx are really missing labels inside other slices) and include vcs.h.

 

BTW: The BRK instructions are a very clever way for jumping into a subroutine using the break vector ($fd82)

[Cupcakus]

Thanks a lot Thomas. A couple more things though.

 

#1. I used $D000 myself however there are several JMP's to $BXXX range that surface, this could just be my inexperience talking but why isn't it $B000?

 

#2. How did you come about getting every little segment for the CFG file. I tried that and could not figure it out.

 

Your help has been greatly appreciated!

[Thomas Jentzsch]

#1.  I used $D000 myself however there are several JMP's to $BXXX range that surface, this could just be my inexperience talking but why isn't it $B000?

I'm not sure, maybe there are slices that are 'orged' at $b000.

You should check, if there is a certain range in those addresses or if they are all valid adresses inside a part with different ORGs. In the end there should be a clear and perfect pattern, but finding that requires some try and error. And there is a good chance that those $bxxx addresses are just lazy coded $dxxx addresses.

 

#2.  How did you come about getting every little segment for the CFG file.  I tried that and could not figure it out.

Mainly by looking a the code and some try and error. Start with defining the whole file as CODE.

 

If you get code that doesn't make sense or includes a lot of 'illegal' opcodes, it's most likely part of a table. Then you have to find the start and end of that table and redefine your CODE ranges.

 

With some experience non-code will become very obvious and the whole process will become much faster.

 

BTW: Using the trace mode of z26 helps finding the last details too.