Jump to content
IGNORED

Distella configuration files


stephena

Recommended Posts

The Supercharger conversion thread contains many disassemblies of games that have the parameters (relevent to the original games only) pasted right at the top. I'm sure that much of the dedicated hack threads also have such info (all of mine do).

 

-However-

 

A long-running gripe I have with Distella is the application of the GFX and DATA sections. GFX generates a listing with values on their own lines, but does not convert the value to binary. DATA allows you to make the distinction between bitmaps and data, but does not put those values on seperate lines.

Since a program would need to be reverse-engineered just to find out if bitmapped values are also used as non-bitmap data tables, I just used GFX for both.

 

I also used the GFX tag for dealing with imbedded BIT opcodes...that are used to skip over instructions (since Distella would otherwise miss out on disassembling the opcodes that make up the arguments).

Edited by Nukey Shay
Link to comment
Share on other sites

The Supercharger conversion thread contains many disassemblies of games that have the parameters (relevent to the original games only) pasted right at the top. I'm sure that much of the dedicated hack threads also have such info (all of mine do).

OK, thanks, I'll look into those.

 

A long-running gripe I have with Distella is the application of the GFX and DATA sections. GFX generates a listing with values on their own lines, but does not convert the value to binary.

This is easy to fix.

 

DATA allows you to make the distinction between bitmaps and data, but does not put those values on seperate lines.

Since a program would need to be reverse-engineered just to find out if bitmapped values are also used as non-bitmap data tables, I just used GFX for both.

I'm not sure what to make of this latter point until I get into it (modify Distella in Stella and testing the results).

Link to comment
Share on other sites

It would be nice if a configuration that is given like this:

 

ORG F000

GFX F000 F002

DATA F003 F004

OPCODE F005

CODE F006 F008

 

...should produce something like this automatically:

LF000: .byte %11111111 ; $F000 |XXXXXXXX|
      .byte %10000001 ; $F001 |X      X|
      .byte %11111111 ; $F002 |XXXXXXXX|
LF003: .byte $40       ; $F003
      .byte $80       ; $F004
LF005: .byte $C9       ;2 CMP#
LF006: TXA             ;2
      STA    GRP1     ;3

 

A disassembler should have no problems with that...and still use automatic code-detection on any address ranges not given in the cfg.

There's pretty much no good "automatic" solution for shared bytes among sections - other than maybe searching through code to see which values are used specifically for the GRP registers...but it's not really practical that it would be able to decypher all conditions.

 

EDIT: a good one would be to add cycles taken for crossing pages, too. The starting and destination points are both known during disassembly, so it should be no problem to include that in the cycle time shown for branching. Everybody knows that a branch not taken is 2 cycles, so just show the reverse insead...whether it will be 3 or 4 when taken.

Data reads/stores that cross boundries, however, would be difficult/impossible for a disassembler to work out quickly tho (or at all).

Edited by Nukey Shay
Link to comment
Share on other sites

It would be nice if a configuration that is given like this:

 

ORG F000

GFX F000 F002

DATA F003 F004

OPCODE F005

CODE F006 F008

 

...should produce something like this automatically:

LF000: .byte %11111111 ; $F000 |XXXXXXXX|
      .byte %10000001 ; $F001 |X      X|
      .byte %11111111 ; $F002 |XXXXXXXX|
LF003: .byte $40       ; $F003
      .byte $80       ; $F004
LF005: .byte $C9       ;2 CMP#
LF006: TXA             ;2
      STA    GRP1     ;3

 

A disassembler should have no problems with that...and still use automatic code-detection on any address ranges not given in the cfg.

There's pretty much no good "automatic" solution for shared bytes among sections - other than maybe searching through code to see which values are used specifically for the GRP registers...but it's not really practical that it would be able to decypher all conditions.

 

EDIT: a good one would be to add cycles taken for crossing pages, too. The starting and destination points are both known during disassembly, so it should be no problem to include that in the cycle time shown for branching. Everybody knows that a branch not taken is 2 cycles, so just show the reverse insead...whether it will be 3 or 4 when taken.

Data reads/stores that cross boundries, however, would be difficult/impossible for a disassembler to work out quickly tho (or at all).

I can use some of these ideas; others may be more problematic. The output within Stella won't look exactly like that, though. Distella is restricted in its output, since it has to generate syntax compatible with a compiler. The disassembler in Stella, on the other hand, has no such restriction, and should be optimized for the person reading it. In other words, I can easily do the latter, but no so much the former:

   .byte %11111111 ; $F002 |XXXXXXXX|
   .byte %FF  |XXXXXXXX|  $F002    %11111111

The very last value on the previous line will be in an editable textbox, allowing it to be easily changed. Putting the %11111111 right after the .byte is harder to do (ie, there's a reason Distella doesn't do it that way).

Link to comment
Share on other sites

It would be nice if a configuration that is given like this:

 

ORG F000

GFX F000 F002

DATA F003 F004

OPCODE F005

CODE F006 F008

 

...should produce something like this automatically:

LF000: .byte %11111111 ; $F000 |XXXXXXXX|
      .byte %10000001 ; $F001 |X      X|
      .byte %11111111 ; $F002 |XXXXXXXX|
LF003: .byte $40       ; $F003
      .byte $80       ; $F004
LF005: .byte $C9       ;2 CMP#
LF006: TXA             ;2
      STA    GRP1     ;3

 

 

I see what you are saying Nukey, but I really think the current settings should be kept as well. I sometimes have to disassemble code that has a huge block of garbage data and I want to use something like this to save space:

 

    sta    $F8                   ; 3
   jmp    LDFF0                 ; 3

;$DBC6:
   .byte $B4,$5B,$74,$3B,$34,$BB,$44,$BB,$04,$BB,$4B,$B4,$4B,$BE,$4B,$BC   ; garbage
   .byte $4F,$B5,$45,$BA,$44,$BB,$46,$BB,$44,$B9,$B4,$4B,$B4,$4B,$B4,$4B
   .byte $B4,$4B,$B4,$5B,$B4,$DB,$F4,$7B,$B4,$AB,$4F,$BA,$4A,$B5,$44,$B3
   .byte $4C,$BB,$4C,$B9,$44,$BB,$44,$BB,$44,$BB,$BB,$45,$BB,$44,$BB,$44
   .byte $BB,$44,$BB,$49,$BA,$43,$BC,$0B,$F0,$4B,$44,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BB,$44,$BB,$44
   .byte $BB,$44,$BB,$45,$BB,$05,$BA,$57,$B5,$43,$44,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BB,$44,$BB,$44
   .byte $BB,$45,$B9,$47,$B9,$47,$F9,$42,$B8,$4B,$44,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BB,$44,$BA,$47
   .byte $BA,$47,$BF,$47,$B8,$4B,$B4,$43,$B4,$43,$44,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BB,$44,$BB,$44
   .byte $BB,$44,$BB,$46,$B1,$47,$BA,$47,$BE,$44,$44,$BB,$44,$3B,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BA,$47,$BE,$47
   .byte $BF,$4E,$BA,$43,$90,$43,$B4,$1B,$6C,$89,$44,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BB,$44,$BB,$45
   .byte $BA,$47,$B5,$0B,$BC,$4F,$BC,$4B,$B4,$4B,$44,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB,$BB,$44,$BB,$45,$BA,$45
   .byte $BB,$40,$BE,$4F,$B9,$47,$B4,$43,$9C,$5B,$CC,$BB,$44,$BB,$44,$BB
   .byte $44,$BB,$44,$BB,$44,$BB,$44,$BB,$44,$BB

Zero0:
   .byte $E0 ; |XXX     | $DD00

 

 

I also use this block style a lot with code when I disassemble E0 games, but the reason I do is kind of lengthly to write here.

 

 

With the gfx, I would absolutely hate it if it spit it all out in binary and I couldn't change it back to hex. I usually code gfx straight in hex. This is absolutely perfect for me:

 

 

One:
   .byte $00 ; |        | $FF08
   .byte $3C ; |  XXXX  | $FF09
   .byte $18 ; |   XX   | $FF0A
   .byte $18 ; |   XX   | $FF0B
   .byte $18 ; |   XX   | $FF0C
   .byte $18 ; |   XX   | $FF0D
   .byte $38 ; |  XXX   | $FF0E
   .byte $18 ; |   XX   | $FF0F

 

 

However, I can see how others would absolutely hate what I like. What Distella ultimately needs is some more commands. Make GFX spit out binary like you want, and then have a HFX command to spit the HEX gfx like it does now. Have DATA spit out line by line with the address like you want, and another command BDATA to spit out the data in old style blocks. I could see myself using the new DATA style you suggested quite a bit, but I would like BDATA there as an option if need be.

 

 

 

I agree with you 100% on the BIT tests. If the disassemblier detects a jump into the BIT instruction, the default should be like:

 

     .byte $2C ; BIT opcode (skip 2 bytes)
LF045:
    lda    $82
;...code continues

 

Right now Distella would disassemble the BIT instruction as code, and throw the LF045 label at the top of the disassembly.

Link to comment
Share on other sites

I agree with you 100% on the BIT tests. If the disassemblier detects a jump into the BIT instruction, the default should be like:

 

     .byte $2C ; BIT opcode (skip 2 bytes)
LF045:
    lda    $82
;...code continues

 

Right now Distella would disassemble the BIT instruction as code, and throw the LF045 label at the top of the disassembly.

 

No doubt. It's a pain to go back through and search for the tags when it easily could have done it automatically. I took to hacking Distella myself (getting yelled at from all corners in the process) just to get all the opcodes in lower-case and removing those long undefined opcodes so that the file generated isn't massive (replacing them with their Dasm-compatable illegal-opcode names). But it would be nice for an update that includes such switches that a user could toggle...or adding a user-defined tag that generates binary, seperate line data, or whatever wanted.

Link to comment
Share on other sites

No doubt. It's a pain to go back through and search for the tags when it easily could have done it automatically. I took to hacking Distella myself (getting yelled at from all corners in the process) just to get all the opcodes in lower-case and removing those long undefined opcodes so that the file generated isn't massive (replacing them with their Dasm-compatable illegal-opcode names). But it would be nice for an update that includes such switches that a user could toggle...or adding a user-defined tag that generates binary, seperate line data, or whatever wanted.

 

 

Why did they yell at you? I too use a custom personalized version of Distella. In general I like how Distella prints all that garbage for illegal opcodes when you're trying to disassemble data as code. Then you know that section should be gfx or data. Still though, an illegal option should be there. Perhaps an "i" switch to turn on illegal codes would be handy.

 

 

 

In general the hacked version of Distella I use has:

 

1) puts opcodes in lowercase

2) changes all the spacing to the start of the ";". I like my spacing longer.

3) doesn't put any code on the same line as the label (I really like the label on the line by itself)

4) leaves a space after every jmp command (makes it easier to find indirect jumps)

5) change all zero page absolute to remove the leading zeros. That's what the ".w" in DASM is for. I mean I want to see lda.w $83 so it's easy to replace with a name instead of having to hunt through all the lda.w $0083, know what I mean?

 

 

After that I feed the entire output into an excel file which adds "2³" for every branching instruction (makes it easy to search for the branch unconditionally conditions, and "2³+1" when a page boundary is crossed (always useful). Really though, I would like Distella to do this and not have to rely on excel so much. Also a smarter Distella should be able to pick out some obvious always branchs:

 

beq .gotThere

bne .goHere ; always branch

 

99% of the time there will be no indirect jump in between there. Finally something I've been thinking of adding to my hacked version of Distella is naming the ram automatically so it can be separated beforehand from bytes. I.e. "lda $83" would be replaced with lda ram83 which makes it a hella lot easier to change then having to go through all the ".byte $83 ; |X XX|" too. Of course after a while you learn to mass change those .bytes beforehand so they can never mix up and you let your text editor do the rest. It still should be done beforehand by Distella though. Those lda ram83 would also be done for absolute addressing of course (ie lda.w $83)

Link to comment
Share on other sites

Why did they yell at you?
Can't recall exactly. Something along the lines of how Distella was a modern marvel that shouldn't even be looked at by lowly peon hackers such as myself.

 

I had to supress a little "I shouldn't need to hack the shit out of it to make it run the way that I want it to." when it was clear that it was useless to argue about it.

Link to comment
Share on other sites

BTW, are we talking about the disassembly we see in Stella's debugger, Distella, or a new option in Stella to produce an actual .asm file?

This is about improving the output of Distella that's built into Stella. It is definitely not about generating an actual asm file, as that brings a whole load of stuff with it that I don't want to think about right now.

 

As for the suggestions above on how to improve Distella, that will have to wait as well. For the first pass of this, I want Stella to recognize a standard configuration file with just CODE/DATA/GFX sections. Maybe Distella can be extended later, but not right now (at least for Stella).

 

There's only one problem I haven't figured out yet. Distella assumes that a config file contains info for one bank. Which is reasonable, as it only supports one bank. However, how do I make it work with multiple banks? How do I know which bank the config file refers to, and when specifying ranges for different banks, how do I differentiate?? This is most relevant right now, because I can't proceed in Stella until this is worked out. It's easy enough to do it with debugger commands; I just have the directives apply to whichever bank is active when they are issued. But loading directives from a config file will be ambiguous in a multi-bank ROM.

Link to comment
Share on other sites

I guess I don't understand the question. :?

 

If you are trying to encorporate .cfg files into Stella's debugger (so the data is layed out in the debugger window the way that it is used), why couldn't you include all of those parameters? Stella should know which bank it's in...so just have it "look" at the related portion of a .cfg.

 

 

Or are you saying that Stella has the same 4k rom limitation that Distella does? How the heck does it run rom sizes greater than 4k in that case?? :?

Link to comment
Share on other sites

BTW for disassembly, banked roms need to be split into the banked portions before Distella will deal with them...each portion disassembled individually. When a .cfg file is used there, it needs to contain only the parameters relevant to that portion.

OK, I can answer your previous question by referring to this one. This is exactly my point; how to simulate multiple config files with just one. While Distella must have the ROMs split and have separate config files for each bank, Stella has no such restriction. So, say I load a multi-bank ROM and attempt to load a config file. Which one should be loaded? That is is problem I'm having; Distella only works on a single 4K bank (and expects the config file to have the same restriction), while Stella can operate on all of the banks (and ideally, I'd like to create a single config file to hold all the info at once).

 

I guess my main problem is staying compatible with Distella config files. I can go ahead and create my own format that includes all the info I want, but it won't be loadable in the standalone version of Distella directly. Maybe it's better to just go that route ...

Link to comment
Share on other sites

Still having difficulty understanding what the goal is. To tie the Distella program directly to Stella? I thought that Stella had it's own disassembler?

 

As far as what a cfg file contains goes...Distella couldn't care less. Disassembly is only a benefit to a human reading the code. If the wrong parameters are given, Distella will still try to make use of them. So I'd say just to load however many cfg files there are for the banked rom and let the user decide on which part to use and which to ignore. It's not like they occupy much memory or anything.

Link to comment
Share on other sites

Still having difficulty understanding what the goal is.

 

 

I'm running to work. So I have to be quick.

 

I asked Stephena to do this a long time ago, but I wasn't sure what Stephena was trying to do that exactly until I read his last post. Basically I was looking for some way to get Stella to show GFX vs DATA in the debugger, and show the skip BIT instructions like we talked about. Might as well use your own format Stephena.

 

 

With the limited space in the debugger outputting the gfx like Distella does now might be the cleanest. For Data I like your idea Nukey of 1 byte per line.

Link to comment
Share on other sites

To be honest, I only use that method because I don't trust myself. With the GFX tag, every single line comments exactly where it's byte came from. So if I'm shifting memory around by adding and deleting lines, I can ORG data tables to where they originally were if things go to crap when trying to run a hack (obviously, some things still not found and labelled).

 

Good suggestion on the automatic carriage returns...I was just doing that via mass search-and-replace colon-space with colon-return-6 space. But changing it was only a couple of bytes. Where did you find the double-zero placeholder for .word? Edit the 4 spaces following the wildcards to only 2?

Link to comment
Share on other sites

Hell, it ought to be easy to add >4k support...just split the file internally based on a given bankswitch method as the disassembly takes place (the user still has to do .cfg's for it to cross-reference everything...but it's one less step the person has to be subjected to).

 

Something like Distella -pafsf8cGalaxian.cfg Galaxian > Galaxian.asm?

Link to comment
Share on other sites

Stephena, I made a configuration file for Frostbite for you. Normally I would use GFX for all DATA in a game like this, because I like to see the addresses for each byte of data. It makes it a hella lot easier to follow if you're going back and forth trying to compare a byte in Stella's debugger to your own assembly (when searching for a particular color, etc...)

 

 

Frostbite.zip

 

 

 

@Nukey, I took a look and I'm actually converting all those zero page absolutes in my excel file. This really should have been done by Distella though IMHO. I mean for my disassembly to be recompiled by DASM since 99% of Atari 2600 programming is done with it. Distella is already spitting out the .w for DASM, and DASM knows how to recompile it correctly. However, I don't mind seem the absolute zeropage addresses in Stella's debugger.

 

 

Another thing that Distella should do is recognize all the zero page mirrors for the collisions and inputs. I had my excel file doing those for me too. I guess the idea with Distella before was to always have the code 100% reassembled correctly by DASM in any situation. Makes sense then to leave LDA INPT4 as LDA REFP1 when the baseline is $00.

 

 

On the other hand you could have Distella output a TIA_BASE_ADDRESS or whatever the prompt is at the top of the disassembly to correct it. That being said I have found at least one game (don't remember which) that used both a $0C and $3C. This becomes a problem... in this situation how do you deal with 2 of the same mnemonic with different values?

 

 

Again this is a very rare situation, and the convenience of having the inputs renamed is the goal. In this situation I would have Distella default one of operands to the hex value instead of a mnemonic. But I want Distella to be intelligent about which one it choses to use!

 

 

So first Distella adds up the total number of collisions and inputs referenced with $0x vs $3x, and whichever has the most would become the default baseline (for that rom). This is making Distella a little smarter already by forcing it to make an a decision based on a majority rule. Next replace the minority mnemonics with straight hex values in the disassembly (ie LDA $3C). Finally because Distella is so sweet now, it prints out a commented note at the top of your disassembly so you can find the stragglers:

 

TIA_BASE_ADDRESS = $00

 

;alternative baseline found (1) times:

;$3C (INPT4) at $F3CE

 

 

 

Thoughts? Ideas?

Link to comment
Share on other sites

Hell, it ought to be easy to add >4k support...just split the file internally based on a given bankswitch method as the disassembly takes place (the user still has to do .cfg's for it to cross-reference everything...but it's one less step the person has to be subjected to).

 

Something like Distella -pafsf8cGalaxian.cfg Galaxian > Galaxian.asm?

 

 

Thinking about it some more, when I first started using Distella I was also new to computers. I found command line hard and particularly I was stumped for a few days until I figured out:

 

1) The configure file must be WRITTEN IN ALL CAPITAL LETTERS. That took me a couple of days to figure out. Why they didn't just put in a simple function to take either I'll never know. I mean I was brand new to a keyboard. I was still hunting and pecking the keys even... peck peck oops!

 

2) At the top of the disassembly it outputs the commandline. The only thing is it doesn't show you all of it. So that took me a few days to figure out that I had to add a ">" arrow and file name afterward. So I for the most part manually type in the entire commandline in my disassemblies, so that others can figure it out easier. Sometimes I forget though...

 

3) And yeah, I tried clicking on the .exe to get it working. In this day and age why not have a GUI? Especially if Distella can be made to do bankswitched games? Chock the GUI full of minor options like the spacing between opcodes and operands etc... I think more new people would be inclined to use Distella if it had a GUI.

 

 

 

 

Also I run it on Windows 7 no problem, but I'm using a 32 bit environment. I don't know if Distella is compatible with 64 bit?

 

 

Finally if Distella is made to bankswitching games then I hope it can include all the ORG and RORG statements as appropriate. I find the wrong way to decide a banks origin is to look at the RESET vector and use that. A lot of time pirate companies used $F000 for reset in every bank, but each bank will be different ($1000, $D000, $7000, etc...) The key is too look at the jumps (i.e. JMP $xFE4) in that bank and get the origin that way. The JMP's will tell the tale.

 

 

Of course anything that uses slices is on a trip all its own (like E0 bankswitching). I'm really talking about normal Atari bankswitching when looking for these origin address inside the bank itself and not at the RESET vector.

 

 

Sorry to post so much, but Nukey's got me thinking about Distella and I now I'm all riled up and completely lost the plot. :x I just want to say here that I am thankful for having a tool that will disassemble for me, but I think it can be made better. Like Dennis says, it's time for an update.

Link to comment
Share on other sites

Hell, it ought to be easy to add >4k support...just split the file internally based on a given bankswitch method as the disassembly takes place (the user still has to do .cfg's for it to cross-reference everything...but it's one less step the person has to be subjected to).

 

Something like Distella -pafsf8cGalaxian.cfg Galaxian > Galaxian.asm?

 

 

Thinking about it some more, when I first started using Distella I was also new to computers. I found command line hard and particularly I was stumped for a few days until I figured out ...

You know, many of the updates you'd like to see have been (or can easily be) added to the Distella code built into Stella. I've already converted the code to C++, getting rid of all compile warnings, fixing a few bugs along the way, and adding a few things (like differentiating between read vs. write TIA addresses). Granted, I've completely stripped all A7800 support, but at this point it would be easier to work from this code (adding back what I've removed) rather than starting from scratch on the old code.

 

Another improvement I made was to move from old printf statements to C++ streams. The nice thing about this if something is generated and need to go back to it, you can just go backwards in the stream. For the old Distella code, stuff was written to the screen, and if you want to go backwards, tough :)

 

Anyway, it's just another option I'm throwing out here. I don't really have the time to take over an updated C++ port of Distella, but the option is there for someone who does. Oh, and BTW, the new code is completely clean in 32 and 64-bit mode, without any compile warnings.

 

EDIT: After reading through several of your requests, it really seems like an interesting project to take on. But I know if I start it, I won't get back to Stella again for about 3 months or so. For almost every one of your suggestions, I can see how to code it relatively easily. I just need the time. Must resist the urge ... :)

Link to comment
Share on other sites

OK, I've made some progress on parsing Distella config 'directives' in Stella. I've added 'code', 'data' and 'gfx' commands to the debugger prompt, which can directly modify the disassembly. So my main question is, how do you guys see yourself using this functionality?

 

I've already mentioned the problems with config files being for one bank only, so I'll have to create my own format to include info for multiple banks. But assuming I had that format complete, how would you use Stella in your disassembly work? My thinking is that experimentation could be done in Stella quickly, which would then generate a config file that can be split and fed to Distella externally. One particularly useful trick is to use 'gfx f000 ffff', making it pretty easy for graphics to stand out.

 

Do you have any other ideas? I don't want to spend a lot of time on this if nobody will be using it, so now's the time to speak up.

 

EDIT: Just to be clear, I want to narrow down exactly what the purpose of this functionality will be. Is it meant to simply read config files that are generated externally, just so that the disassembly in Stella looks nicer? Or is it for experimentation in Stella, to generate the config files and feed them to Distella externally? BTW, if it's the latter, it's only a small step from that to have Stella generate a complete ASM file directly.

Link to comment
Share on other sites

Must resist the urge ... :)

 

 

It's tempting isn't!! I'd hate to steal you away from Stella though. A lot more people use Stella then Distella, and 3 months would be huge. But if you ever get bored with Stella and want to switch it up for a bit...;)

 

 

 

As for passing the configuration files... my original idea long, long ago, in a galaxy far, far away was to "lock" some old era games into an accurate disassembly. It will clearly show me the gfx, data, and code that I told it to in the configure file, and it would look somewhat like how a Distella output would.

 

At this stage I've already made a rough disassembly that I'm working from in my text editor with Distella. What I'm actually doing is comparing my disassembly to what's happening in the debugger as I hit STEP, SCANLINE, etc... So I'm trying to make notes and that gets awfully hard if the debugger is just showing a big block of data when it is actually supposed to code.

 

 

For the homebrewers (or hackers), it helps to have the address printed right after the data or gfx byte in the debugger. With that you can quickly pinpoint and determine if you program is loading the byte you want or (one above/below in the table, oops!!). If the GFX command can be used to make the graphics look like it does in Distella, then visually it would help you locate where you are in the code quicker by separating it from DATA. Plus it looks better and helps all those graphics hackers too.

 

 

I was especially going to use the configuration file to take care of the BIT, NOP, or CMP instructions that are just being used to skip a byte or two since Stella couldn't handle it at that time. If you want to know how bad these can be, take a look at the last bank of Pete Rose Baseball. That is by far the longest configuration file I've ever done, and it was mostly due to all the BIT instructions in there. When you are trying to follow the logic in the debugger it is a real mess because the code keeps jumping into those BIT instructions, etc...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...