Distella configuration files

[Omegamatrix]

Asteroids and Boxing completed:

 

[0069]8K Asteroids (1981) (Atari, Brad Stewart - Sears) (CX2649 - 49-75163) [no copyright] ~.bin

[0070]8K Asteroids (1981) (Atari, Brad Stewart - Sears) (CX2649 - 49-75163) ~.bin

[0071]8K Asteroids (1981) (Atari, Brad Stewart) (CX2649, CX2649P) (PAL) [no copyright].bin

[0072]8K Asteroids (1981) (Atari, Brad Stewart) (CX2649, CX2649P) (PAL).bin

[0193]2K Boxen (AKA Boxing) (Videospielkassette - Ariola) (PGP234) (PAL).bin

[0194]2K Boxing (1983) (CCE) (C-861).bin

[0195]2K Boxing (32 in 1) (1988) (Atari) (CX26163P) (PAL).bin

[0196]2K Boxing (Dactari - Milmar).bin

[0197]2K Boxing (Unknown) (PAL).bin

[0198]2K Boxing - Box-Champion (1980) (Activision, Bob Whitehead - Ariola) (EAG-002, EAG-002-04I, PAG-002 - 711 002-715) (PAL).bin

[0199]2K Boxing - La Boxe (1980) (Activision, Bob Whitehead) (AG-002, CAG-002, AG-002-04) ~.bin

 

 

I didn't touch or look at the Boxing in the Smash Hit pack, Nukey. Here's the basic config for Boxing for reference:

 

 

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[0199]2K    Boxing - La Boxe (1980) (Activision, Bob Whitehead) (AG-002, CAG-002, AG-002-04) ~.bin

//Stella.pro: "Boxing (1980) (Activision)"
//MD5: C3EF5C4653212088EDA54DC91D787870
[0]
ORG F000
CODE F000 F3FF
GFX F400 F476 // logo & number gfx stored in a 17 byte wide, 7 byte deep table
CODE F477 F53B
DATA F53C F55E
GFX F55F F5FE
CODE F5FF F64F
DATA F650 F6FB
CODE F6FC F75E
DATA F75F F7FF

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

 

 

I figured the one line comment in the configuration file would be enough information. I could easily have stuck the more detailed breakdown from my disassembly, but I want to keep these configuration files small. If someone ever checked the configuration file, they are probably knowledgeable enough to understand the comment. Putting this in from my disassembly would be overkill IMHO.

 

 

;==============================================================================================================================
;               ALPHA-NUMERIC CHARACTERS AND LOGO GRAPHICS
;==============================================================================================================================
;
;      XXXX  | $3C       XXX   | $38      XXXXX  | $7C       XXXX  | $3C         XX  | $0C      XXXXXX | $7E
;     XX  XX | $66      XXXX   | $78      X   XX | $46      X   XX | $46        XXX  | $1C      XX     | $60
;     XX  XX | $66        XX   | $18          XX | $06          XX | $06       X XX  | $2C      XX     | $60
;     XX  XX | $66        XX   | $18       XXXX  | $3C         XX  | $0C      X  XX  | $4C      XXXXX  | $7C
;     XX  XX | $66        XX   | $18      XX     | $60          XX | $06      XXXXXX | $7E          XX | $06
;     XX  XX | $66        XX   | $18      XX     | $60      X   XX | $46         XX  | $0C      X   XX | $46
;      XXXX  | $3C      XXXXXX | $7E      XXXXXX | $7E       XXXX  | $3C         XX  | $0C      XXXXX  | $7C
;
;                                                                         blank digit           colon          (K)nockout
;      XXXX  | $3C      XXXXXX | $7E       XXXX  | $3C       XXXX  | $3C             | $00             | $00     XX   XX | $C6
;     XX   X | $62      X    X | $42      XX  XX | $66      XX  XX | $66             | $00        XX   | $18     XX  XX  | $CC
;     XX     | $60          XX | $06      XX  XX | $66      XX  XX | $66             | $00        XX   | $18     XX XX   | $D8
;     XXXXX  | $7C         XX  | $0C       XXXX  | $3C       XXXXX | $3E             | $00             | $00     XXXX    | $F0
;     XX  XX | $66        XX   | $18      XX  XX | $66          XX | $06             | $00        XX   | $18     XX XX   | $D8
;     XX  XX | $66        XX   | $18      XX  XX | $66      X   XX | $46             | $00        XX   | $18     XX  XX  | $CC
;      XXXX  | $3C        XX   | $18       XXXX  | $3C       XXXX  | $3C             | $00             | $00     XX   XX | $C6
;
;
;          XXXXXXXX    XXXXXXX
;       X     X   X   XX
;      XXX XX X X X  XX  XXX X XXX X  X
;      X X X  X X X XX X X   X X X XX X
;      XXX X  X X XXX  X XXX X X X XXXX
;      X X X  X X XX   X   X X X X X XX
;      X X XX X X X    X XXX X XXX X  X
;
;
;      logo (A)              logo (B)              logo (C)              logo (D)
;          XXXX  | $0F       XXXX      | $F0       XXXXXXX   | $FE                 | $00
;       X     X  | $41          X   X  | $11       X         | $80                 | $00
;      XXX XX X  | $ED        X X  XX  | $53         XXX X   | $3A       XXX X  X  | $E9
;      X X X  X  | $A9        X X XX   | $56       X X   X   | $A2       X X XX X  | $AD
;      XXX X  X  | $E9        X XXX    | $5C       X XXX X   | $BA       X X XXXX  | $AF
;      X X X  X  | $A9        X XX     | $58       X   X X   | $8A       X X X XX  | $AB
;      X X XX X  | $AD        X X      | $50       X XXX X   | $BA       XXX X  X  | $E9
;
;
;
; These graphics are stored "upside down" and shuffled inside the rom. Using a 17 byte wide table unshuffles the graphics, but
; they still are "upside down" from how they appear above.
;
;                                                               blank digit
;                                                                |
;                                                                |   colon
;                         number(s)                              |    |                logo parts
;                                                                |    |   "K"
;           0    1    2    3    4    5    6    7    8    9       |    |    |       (A)  (B)  (C)  (D)            rom address
;
   .byte $3C, $7E, $7E, $3C, $0C, $7C, $3C, $18, $3C, $3C,     $00, $00, $C6,     $AD, $50, $BA, $E9         ; $F400 - $F410
   .byte $66, $18, $60, $46, $0C, $46, $66, $18, $66, $46,     $00, $18, $CC,     $A9, $58, $8A, $AB         ; $F411 - $F421
   .byte $66, $18, $60, $06, $7E, $06, $66, $18, $66, $06,     $00, $18, $D8,     $E9, $5C, $BA, $AF         ; $F422 - $F432
   .byte $66, $18, $3C, $0C, $4C, $7C, $7C, $0C, $3C, $3E,     $00, $00, $F0,     $A9, $56, $A2, $AD         ; $F433 - $F443
   .byte $66, $18, $06, $06, $2C, $60, $60, $06, $66, $66,     $00, $18, $D8,     $ED, $53, $3A, $E9         ; $F444 - $F454
   .byte $66, $78, $46, $46, $1C, $60, $62, $42, $66, $66,     $00, $18, $CC,     $41, $11, $80, $00         ; $F455 - $F465
   .byte $3C, $38, $7C, $3C, $0C, $7E, $3C, $7E, $3C, $3C,     $00, $00, $C6,     $0F, $F0, $FE, $00         ; $F466 - $F476

;==============================================================================================================================

 

 

In the actual disassembly it is useful, but in the configuration file it's too much information.

[Omegamatrix]

What do we do about roms that share an indentical .cfg?

 

It seems kinda wasteful to create 1:1 copies of a config file for each and every variation of a rom (think of all of those hacks and pirates in the profile database!).

I was planning on making copies of them, and using the unique Stella.pro name for each.

 

 

One thing that strikes me is that if someone searches through the global configuration files, then an entry by the game title (such as the Stella.pro name) seems to be a practicable method. My only concern is if the Stella.pro files get updated and the configuration file doesn't, then you're hooped. In that sense using the MD5 number instead of the game title makes more sense, because the the MD5 number won't change.

 

 

However if I am looking for a particular title and they are all listed by MD5 than that becomes a bitch. I'd have to run the MD5 generator, copy and paste the number, and look up the title that way. Of course the other option is to use the new "listconfig" command in Stella's debugger. The only disadvantage is the comments are gone.

 

 

So I ultimately think the best system is just to duplicate the configuration file, and use the unique Stella.pro names. What do you think, Nukey, Stephena?

[Nukey Shay]

I think that it's wasteful if it's anything beyond a temporary solution.

Seems like something perfectly suited to being in the profile info...such as this:

 

example:

"Cartridge.MD5" "613abf596c304ef6dbd8f3351920c37a"
"Cartridge.Name" "Boring Pac-Man (Hack)"
"Cartridge.Note" "Hack of Pac-Man"
"Cartridge.Rarity" "Hack"
"Display.YStart" "33"
"Disassembly.Parameters" "Pac-Man (1982) (Atari).cfg"
""

Edited September 5, 2010 by Nukey Shay

[+stephena]

Those configure files were meant to be global. If I'm understanding you right:

 

1) Check for a configuration file in the same folder as the rom, with the exact same name as the rom. The extension of course is different. Use this configuration if found.

2) If no local configuration file found, preform a MD5 checksum on the rom, get the Stella.pro name, and then look in the global configuration files for that Stella.pro name. If no configuration file is found use auto disassembly.

 

Is that correct?

Yes, that's what I mean. I'll just add that auto-disassembly is still done, even if a config file is found. Reason being, the config file doesn't necessarily have to cover the entire address space. Of course if it does, the auto-disassembly won't do anything.

 

What do we do about roms that share an indentical .cfg?

 

It seems kinda wasteful to create 1:1 copies of a config file for each and every variation of a rom (think of all of those hacks and pirates in the profile database!).

I was planning on making copies of them, and using the unique Stella.pro name for each.

 

 

One thing that strikes me is that if someone searches through the global configuration files, then an entry by the game title (such as the Stella.pro name) seems to be a practicable method. My only concern is if the Stella.pro files get updated and the configuration file doesn't, then you're hooped. In that sense using the MD5 number instead of the game title makes more sense, because the the MD5 number won't change.

 

However if I am looking for a particular title and they are all listed by MD5 than that becomes a bitch. I'd have to run the MD5 generator, copy and paste the number, and look up the title that way. Of course the other option is to use the new "listconfig" command in Stella's debugger. The only disadvantage is the comments are gone.

 

 

So I ultimately think the best system is just to duplicate the configuration file, and use the unique Stella.pro names. What do you think, Nukey, Stephena?

As for the wastage, it's only a file. Stella is not burdened with loading all the files at once during startup, so there's no speed penalty for having many files. About the only penalty is disk space, which I'd estimate to be at most a few MB (in other words, not worth worrying about). As well, if you have to modify stella.pro with information, that's two places to keep in sync. Much easier (and can be automated) to keep it 1:1. Besides, there may be times you want to add special comments to hacks, which is impossible if it uses the 'base' config file instead.

 

As for the naming, I change the names of ROMs only when RomHunter releases a new collection. And the changes don't happen very often anyway, as he tends to add new ROMs, not very often modify old ones. And I can go through and fix the names of config files as this happens. As for MD5 vs. cart name, I've considered this in the past. Previously, snapshots were named with the MD5 of the ROM, but I changed it to cart names instead. While MD5 is guaranteed not to change, it isn't user-friendly. I ended up considering the latter more important than the former.

[Omegamatrix]

I think that it's wasteful if it's anything beyond a temporary solution.

Seems like something perfectly suited to being in the profile info...such as this:

 

example:

"Cartridge.MD5" "613abf596c304ef6dbd8f3351920c37a"
"Cartridge.Name" "Boring Pac-Man (Hack)"
"Cartridge.Note" "Hack of Pac-Man"
"Cartridge.Rarity" "Hack"
"Display.YStart" "33"
"Disassembly.Parameters" "Pac-Man (1982) (Atari).cfg"
""

 

 

Good suggestion, Nukey. I like that idea because it would cut down on the sheer amount of configuration files. There still is the problem if the Stella.pro name gets updated though. So now I'm thinking maybe it would really be useful to reference the MD5 that holds the particular disassembly inside of the "Disassembly.Parameters" instead of the Stella.pro name. So:

 

"Cartridge.MD5" "613abf596c304ef6dbd8f3351920c37a"
"Cartridge.Name" "Boring Pac-Man (Hack)"
"Cartridge.Note" "Hack of Pac-Man"
"Cartridge.Rarity" "Hack"
"Display.YStart" "33"
"Disassembly.Parameters" "6E372F076FB9586AFF416144F5CFE1CB"
""

 

 

Where "6E372F076FB9586AFF416144F5CFE1CB" is the original Pac-Man, which uses the exact same configuration file needed. With this system it would be up to the user to visit the Stella.pro page to find the game title they want, and then get the "Disassembly.Paramters" (MD5) they need. Once they have it, they could go into the global configuration files and search by the MD5 number. Inside the global configuration folder all the configuration files would be titled as such:

 

 

6E372F076FB9586AFF416144F5CFE1CB.cfg

C3EF5C4653212088EDA54DC91D787870.cfg

 

 

And so on forth... The benefit being of course that when you update a Stella.pro name, the configuration files don't need updating, and it becomes more stable that way. I suppose there could also be a readme file at the top explaining how to effective search these, which would also have the web link. Or you could place the whole Stella.pro page into the text file, and save some time.

 

 

Stephena said the global configuration files would be read only be Stella, so I'll wait to see what he has to say about these ideas. I'm really glad that we're thinking this all out though, before it gets really far ahead. And, I hope Stephena isn't ready to pull his hair out over all this. If he's like me he won't have too much to worry about, because I'm pretty bald ha ha.

[Omegamatrix]

Yes, that's what I mean. I'll just add that auto-disassembly is still done, even if a config file is found. Reason being, the config file doesn't necessarily have to cover the entire address space. Of course if it does, the auto-disassembly won't do anything.

I'm glad you made it this way. This is ideal for games that use tables of overlapped instructions to delay a variable amount of cycles. In such a case I would leave that table out of the configuration, because as you step through the debugger it will continually update itself. To clearly see what I mean, here is Subterranea doing this very thing:

 

 

    iny                          ; 2
   iny                          ; 2
L1332:
   dey                          ; 2
   bpl    L1332                 ; 2³
   jmp.ind ($00F4)              ; 5   jump into the "DelayCycles" table below.



;This table's function is to waste a variable amount of cycles
;before entering the drawing loop for the "HEXUPLEX".

DelayCycles:
   .byte $A9        ; +8 cycles    lda #$A9, lda #$A9, lda $EAA5
   .byte $A9        ; +7 cycles    lda #$A9, lda #$AD, lda $EA
   .byte $A9        ; +6 cycles    lda #$A9, lda $EAA5
   .byte $A9        ; +5 cycles    lda #$AD, lda $EA
   .byte $AD        ; +4 cycles    lda $EAA5
   .byte $A5        ; +3 cycles    lda $EA
   .byte $EA        ; +2 cycles    nop



   ldy    #$0F                  ; 2
L1341:
   ldx    #3                    ; 2
L1343:
   dex                          ; 2
   bpl    L1343                 ; 2³
   lda    $FF                   ; 3
   clc                          ; 2
   adc    L1DF0,Y               ; 4
   sta.w  COLUP0                ; 4
   sta    COLUP1                ; 3
   lda    ($F2),Y               ; 5
   sta    GRP0                  ; 3   drawing the "HEXUPLEX"
   lda    ($F0),Y               ; 5
   sta    GRP1                  ; 3
   lda    ($EE),Y               ; 5

 

 

In such a situation, it's better to let Stella auto-disassemble that table on the fly, because the place you are jumping into continually changes.

 

 

 

Besides, there may be times you want to add special comments to hacks, which is impossible if it uses the 'base' config file instead.

This is a good point. I'm glad we're hashing this all out. I don't really have a problem with making duplicate configuration files with different Stella.pro names. As long as it's not a burden to update I'm happy. And it would be easier to search through them as well.

 

 

Also Nukey, if you are using the same config file multiple times, you could just send me the little reference numbers we made for our list. I'll copy it out for all those pirates over here, no problem.

[Nukey Shay]

IMO it might be a way of getting away from using Distella at all to create cfg files. Shouldn't be causing a problem with games in development, because the cfg is then updatable within the debugger.

Dunno about using the MD number as a name tho. If it supposedly has the ability to seek out a .cfg using the unique name given in the profile, it just makes it more difficult for a user to seek them out manually (supposing they made a new hack and wanted to use the original .cfg for that game). One less step to deal with.

[+stephena]

I'm not really opposed to using MD5 for the names. My main point is that the ROM names change infrequently enough that it's easier to have user-friendly names instead of worrying about it too much.

 

And I'm also not opposed to adding another item to stella.pro that indicates to use a 'base' config file instead of one based on the name of the hack ROM. It doesn't complicate the code too much. I'm just wondering about overthinking and over-engineering the process.

 

BTW, I just implemented loadconfig in the debugger. It correctly loads in the Asteroids and Frostbite config files I have. Yes, I was supposed to be away from the computer all weekend; we can see how that went

[Omegamatrix]

Well, lets keep it simple then. If the Stella.pro names won't be an issue for maintenance then maybe we should just use those.

 

 

I spent a long time on Pete Rose Baseball tonight. Got a lot done, but basically decided to take a break and knocked off Stone Age quite easily. Pete Rose is about as convoluted as it gets. Longest configuration file I've ever done, that's for sure. It started to fry my brain.

 

 

Tomorrow I got to finish a report for work. I hope to do a few more configs tomorrow night though. I'll see how my time goes.

[+stephena]

OK, one final addition to the config file naming.

 

Saving a config file:

 

1) Saving always happens to the same directory the ROM was loaded from. Global config files stored in the cfg folder are never overwritten.

 

2) If a game properties entry exists for the ROM, save the config file with the name from properties, otherwise with the ROM name. For example, if we're dealing with River Raid ROM with MD5 = 393948436d1f4cc3192410bb918f9724, then save the config file as 'River Raid (1982) (Activision).cfg'. If it had instead been a hack named 'rr.a26' not present in the database, the config file will be called 'rr.cfg'.

 

 

Loading a config file:

 

1) Loading is first done from the same directory as the ROM, and then the global one if it isn't found.

 

2) If a game properties entry exists, attempt to load from it first (ie, in the example above, first try 'River Raid (1982) (Activision).cfg').

 

3) If a properties entry doesn't exist, or the filename wasn't found, try loading based on ROM name next (ie, 'rr.cfg').

 

4) Finally, if neither of those exist, try loading from the global directory (based on name stored in properties database).

 

 

My reasoning for using the properties name whenever possible is obvious. Once you save a config file, it can be (externally) moved into the global directory without renaming. The only reason I'm considering names based on the ROM name at all is during iterative development, the ROM won't exist in the properties database, and I don't want to force the user to create properties entry for every single ROM they compile.

 

I might add that this is going to be a $^@#h to document, but it does take care of all cases.

 

 

EDIT: One absolutely final thing. The loadconfig and saveconfig commands in the debugger can accept user-supplied filenames, in which case the above is completely overridden. The logic above is only used in automatic cases, when Stella should decide what filename to use.

 

EDIT2: Damn, I need to get away from the computer. Here's debugging output from 'loadconfig' for the River Raid ROM, which is present in the database and stored in a file named 'rr.a26':

case 1: /home/stephena/src/stella/River Raid (1982) (Activision).cfg
case 2: /home/stephena/src/stella/rr.cfg
case 3: /home/stephena/.stella/cfg/River Raid (1982) (Activision).cfg

Loading is attempting from top to bottom. Saving will address the files in the same order, but of course won't do case 3 (since global files are read-only).

[Omegamatrix]

Stephena, it'll be much easier for me to give feedback when I can actually try a test build out. My style of learning is strongest by doing, so that's when it makes the most sense.

 

 

I'll just keep plugging away at these configuration files in the meantime. A couple of things I noticed about Stella though:

 

 

1) It now accepts commands in the debugger regardless of capitalization. Thank you very much for that. A lot of time I'm flipping back and forth between writing my .cfg in my text editor and Stella. It was a pain to have to write the .cfg in all capitals, and then change back to lowercase for Stella. Now it's all better. By default I'm making all of my .cfg files with capitals like I always have.

 

2) You commented before about the auto-disassembly leaving little gaps between code and data. I know you are aware of the problem and are working on it. I just wanted to say I've only noticed it for JMP commands so far. I'm sure the real problem is not with JMP though. It more likely is that the entry point for the instruction is being used, and the length of the instruction is not being accounted for.

[+stephena]

Stephena, it'll be much easier for me to give feedback when I can actually try a test build out. My style of learning is strongest by doing, so that's when it makes the most sense.

OK, here's another test build. This one has 'loadconfig' and 'saveconfig' implemented, and using the naming logic as described in a previous message.

 

Stella-3.3_test3-windows.zip

 

It now accepts commands in the debugger regardless of capitalization.

Yes, that was included in version 3.2, I believe.

 

You commented before about the auto-disassembly leaving little gaps between code and data.

Not sure exactly what you're talking about, but I suspect (hope?) this will be fixed when I eventually start tracking access to each byte, and marking it as code if it's ever used in an instruction.

[Omegamatrix]

Thanks for the test build! It makes my life a lot easier because I can save a config file and it puts the MD5 and Stella.pro number at the top. I liked how the MD5 was all in lower case. Makes it easier to pick out the letters. I switched all the other ones I did before to match.

 

The debugger is coming along nicely. I can't wait to see the new directives added! Also I right clicked in the editable portion of the the disassembly window and found the switch for changing between hex and binary was there. I think it's a very convenient place. Great job, Stephena!

 

 

I just finished up Stampede. I left the Smash Hit pack and Bit Corp 4in1 cause I didn't know if you did it already. But here's the NTSC config I did if you need it Nukey:

 

 

//Stella.pro: "Stampede (1981) (Activision)"
//MD5: 21d7334e406c2407e69dbddd7cec3583

[0]
ORG F000
CODE F000 F5E5
DATA F5E6 F5FF
GFX F600 F606
DATA F607 F607
GFX F608 F60E
DATA F60F F60F
GFX F610 F616
DATA F617 F617
GFX F618 F61E
DATA F61F F61F
GFX F620 F626
DATA F627 F627
GFX F628 F62E
DATA F62F F62F
GFX F630 F636
DATA F637 F637
GFX F638 F63E
DATA F63F F63F
GFX F640 F646
DATA F647 F647
GFX F648 F64E
DATA F64F F64F
GFX F650 F656
DATA F657 F657
GFX F658 F65E
DATA F65F F65F
GFX F660 F666
DATA F667 F667
GFX F668 F6AB // $F6A7-$F6AB shared
DATA F6AC F6FF
GFX F700 F74D
DATA F74E F7AF
CODE F7B0 F7FB
DATA F7FC F7FF

[Omegamatrix]

Minor update, I've finished these games and all variants (except multi-cart roms):

 

 

Dodge 'em

Donkey Kong

Inca Gold

Karate

Sky Diver

 

 

Big thanks to Dennis Debro for his awesome disassembly of DK. That was beautiful for me to easily identify gfx/data/garbage.

 

 

@Stephena, those gaps between code and gfx are better explained with an example load up Stone Age, go into the debugger, and do a listconfig. Notice that you have:

 

CODE FBF7 FCE1

DATA FCE4 FD1F

 

For the most part the listconfig is bang on. I'm first using saveconfig as a starting point for each configuration file. It's really speeding things up. I think the problem with the output in my above example is that the code ends with a JMP which is 3 bytes in length.

 

 

@Nukey, how are you doing? I've been rethinking the best way to go at this. I think we should tackle roms that are heavily documented first (like TJ's River Raid, or Dennis Debro's Yars' Revenge). Then we could do all the 2K, and work into the 4K. This way we can get the largest majority of it done quickly. What do you think?

[+stephena]

@Stephena, those gaps between code and gfx are better explained with an example load up Stone Age, go into the debugger, and do a listconfig. Notice that you have:

 

CODE FBF7 FCE1

DATA FCE4 FD1F

 

For the most part the listconfig is bang on. I'm first using saveconfig as a starting point for each configuration file. It's really speeding things up. I think the problem with the output in my above example is that the code ends with a JMP which is 3 bytes in length.

OK, this seems to be a bug in generating the directive list. It has nothing to do with the new scheme of (eventually) marking code from the emulation itself. I'll look into it sometime today, if I can. Note that I'm back in full swing at work now, and with it being the beginning of a new Fall semester (I work at a university), I don't have a lot of time. Not to mention that I still partly have a flu for about 3-4 weeks now (it really seems to be kicking my ass). So hopefully I'll get to this soon, but if not, I hope the current version of Stella is sufficient for you for now.

[+stephena]

OK, I just found a few minutes to fix the last reported bug ('holes' in the directive ranges). So here's another test release: Stella-3.3_test4-windows.zip

 

Fixes include:

Make sure directive ranges generated by saveconfig and listconfig are consecutive.
Added 'clearconfig' command, erases all user-defined directives (either by bank or for all banks).  This is useful if you've completely mucked up the directives, and want to start from scratch.
Fixed bug in 'saveconfig'; it was always saving the config file in the current directory, even if the ROM was in a subdirectory.  This of course caused loadconfig to fail later on.

[Nukey Shay]

@Nukey, how are you doing? I've been rethinking the best way to go at this. I think we should tackle roms that are heavily documented first (like TJ's River Raid, or Dennis Debro's Yars' Revenge). Then we could do all the 2K, and work into the 4K. This way we can get the largest majority of it done quickly. What do you think?

 

Trying to figure out where all of this is going. With the number of differing binaries out there (approaching 10k AFAIK), this is not going to be a quick task - especially if only a couple people are working on it - the thread doesn't seem to be generating much interest...if it is, it's been invisible as far as I can tell. Those that need configuration breakdowns the most are those that are already familiar enough with the disassembly process that they could make their own in minutes (for anything that doesn't already exist as a disassembly - the majority of which being the most popular/common games that become hacks).

 

This is not to say that I feel that it's something that is not a good addition to Stella's debugger...it is (anything that makes the feature more accurate is not a bad thing). And it's a step in moving away from the outdated Distella program. But what it the point if nobody is going to use it?

[Omegamatrix]

Got the latest build, thanks! Hope you're getting over that flu. Sounds pretty nasty if it sticks with you for so long. I understand time constraints too. I have this gap of a couple of months before I have to go back to school, so I'm going to try to get as much done as I can. These configuration files will be an on-going project over a few versions of Stella, but a huge bulk will be done quite quickly. I'm already up to 57 configs, and that's because a lot of games have very similar roms between PAL/Pirate versions.

 

 

So I do the NTSC config, open up HOM3 and compare a pirate. Then I look at the changes. If there are only 2 bytes different, it usually the values loaded into the timers for overscan and vblank (basically a lazy PAL conversion). Otherwise it usually is differences only in the part where the logo gfx are, or some colors. In that case I just reuse the NTSC config with the appropriate MD5 and Stella.pro info. Very easy to do.

 

 

With Karate, There is a hidden, unused Bit Co (Bit Corp?) logo. I left the logo defined as GFX even though it is garbage data. I felt it was significant for the user. All the garbage code I left as BLOCK. In Karate's case the garbage code is code that is found in other places of the rom.

 

 

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[0768]4K    Karate (1982) (Ultravision) ~.bin

//Stella.pro: "Karate (1987) (Froggo)"
//MD5: cedbd67d1ff321c996051eec843f8716

[0]
ORG F000
CODE F000 F5B8
BLOCK F5B9 F5B9 // "RTS" never used
CODE F5BA FB2C
BLOCK FB2D FB2F
GFX FB30 FBEF
BLOCK FBF0 FBF2
CODE FBF3 FC2F
GFX FC30 FC8F
BLOCK FC90 FC9F
CODE FCA0 FCBA
BLOCK FCBB FCFF
GFX FD00 FD57
BLOCK FD58 FD72
GFX FD73 FD7A
BLOCK FD7B FD80
GFX FD81 FDA0   // Hidden Bit Corp? logo (unused)
BLOCK FDA1 FDFF // $FDA1-$FDD7 garbage code
CODE FE00 FE7B
GFX FE7C FE9B   // Erased logo
BLOCK FE9C FFFB // $FF00-$FFFB garbage code
DATA FFFC FFFF

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

 

 

I think I'll do this for other hidden logos in roms. Off hand I can think of a Funvision logo in HES Challenge, a Home Vision logo in Words Attack, etc...

 

 

In words attack there is a whole pile of data that no one has ever deciphered. I'll leave it all as BLOCK with a comment in the configuration file, but the logo I'll display as gfx.

 

 

I think I'm going to switch gears like I suggested to Nukey, and I'm going to do River Raid next.

[Omegamatrix]

With the number of differing binaries out there (approaching 10k AFAIK), this is not going to be a quick task - especially if only a couple people are working on it - the thread doesn't seem to be generating much interest...if it is, it's been invisible as far as I can tell. Those that need configuration breakdowns the most are those that are already familiar enough with the disassembly process that they could make their own in minutes (for anything that doesn't already exist as a disassembly - the majority of which being the most popular/common games that become hacks).

 

This is not to say that I feel that it's something that is not a good addition to Stella's debugger...it is (anything that makes the feature more accurate is not a bad thing). And it's a step in moving away from the outdated Distella program. But what it the point if nobody is going to use it?

 

I often set breakpoints in the debugger. When a breakpoint trips the debugger opens. At that point I often find there is a huge block of data above the breakpoint which actually is code. With the hard coded config, it'll be a lot easier to look at the instructions leading up to the breakpoint. It's too bad rewind didn't work to back track instructions leading up to the break point... that would be the ultimate.

 

 

So I see these config files being used by anyone who is just looking at a game in the debugger. They are really aimed at helping the code window in the debugger being really user friendly. This maybe a gfx hacker using it or a homebrewer trying to figure out a routine in an old era rom that they want to adapt, etc... For the gfx hacker they often open HOM3 to see where the gfx lie. But HOM3 won't tell them what parts of the rom are code/data. So a side effect of making the debugger really accurate for the purpose of clearly seeing code/data/gfx is that this will be useful for them too. Also they can directly edit the gfx in Stella now!

 

 

As for the number of roms, I'm just sticking with those that are in V5. I don't care about all the bad dumps, PD roms, homebrews (unless an author would like it done), etc...

 

 

From Rom Hunters V5 I got a count of:

 

1801 roms

- 111 (IIRC) dups

- 57 roms I already done

 

 

We have 1633 left. This number will come down quickly in the beginning. River Raid for example has about twenty or so hacks that are mostly logo hacks.

 

I agree this will take a while. I was thinking of it as an ongoing project. For the first bit I'm really going to focus on bulk. My plan is to

release an updated master list (V2) with the completed roms removed. So it is essentially the list you and I started with, and it has less files.

 

 

Then I take my old V1 list, mass edit it, and make the separate config files. I repeat the process for your old V1 list. I won't mess around trying to merge your V1 list with mine. I'll just work with them separately, and create the new V2 list by deleting the entries we already completed.

[+stephena]

Trying to figure out where all of this is going. With the number of differing binaries out there (approaching 10k AFAIK), this is not going to be a quick task - especially if only a couple people are working on it - the thread doesn't seem to be generating much interest...if it is, it's been invisible as far as I can tell.

Maybe the title is misleading, or maybe people looked at the first few comments and then decided it wasn't of interest to them. Remember, this started out with me asking a question of how to format Distella config files, and only later turned into collecting config files for all ROMs. The first part is somewhat esoteric and doesn't apply to most people (developers included). The second part is much more interesting. Perhaps a new thread can be created??

 

This is not to say that I feel that it's something that is not a good addition to Stella's debugger...it is (anything that makes the feature more accurate is not a bad thing). And it's a step in moving away from the outdated Distella program. But what it the point if nobody is going to use it?

Well, the work I've done so far is just that; done. Even if you guys stopped right now and didn't do any more config files, the functionality in Stella is already there, and I won't be removing it. So from my POV, I'm almost done I guess what I'm trying to say is, I'm willing to take this as far as you are.

[Omegamatrix]

Well, the work I've done so far is just that; done. Even if you guys stopped right now and didn't do any more config files, the functionality in Stella is already there, and I won't be removing it. So from my POV, I'm almost done I guess what I'm trying to say is, I'm willing to take this as far as you are.

 

I'm personally loving everything that has been done in the debugger. Nukey, I wish you could see the new debugger because it's just a world of difference. I love seeing gfx clearly in the debugger, and I love knowing all of the code is disassembled.

 

 

I'm hoping SKIP, BLOCK, and DATA (line by line) will be incorporated into the debugger soon. That way I can check my .cfg as I go. Right now if I screwed up and spelled BLOCK as BL0CK by mistake I wouldn't know, because Stella will just ignore that command anyhow. My bigger worry is making overlapping ranges, and I wouldn't know they overlap because these new commands are ignored. Plus I want to see how the new DATA format will stand out visually from the GFX areas. It should really be sweet.

 

 

I never realized how beneficial it would be to have a .cfg file auto-produced. It saves a lot of time over doing the whole thing from scratch. I just finished River Raid and all it's variants. I used TRAPREAD quite a bit to determine if gfx areas in the Bermuda hacks were being used. Stephena, I was wondering if there was any way to use TRAPREAD over a range of values? I mean I wanted to know if $FC00 - $FC12 were being read for example. Is there a tracelog or something?

[+stephena]

Well, the work I've done so far is just that; done. Even if you guys stopped right now and didn't do any more config files, the functionality in Stella is already there, and I won't be removing it. So from my POV, I'm almost done I guess what I'm trying to say is, I'm willing to take this as far as you are.

 

I'm personally loving everything that has been done in the debugger. Nukey, I wish you could see the new debugger because it's just a world of difference. I love seeing gfx clearly in the debugger, and I love knowing all of the code is disassembled.

 

 

I'm hoping SKIP, BLOCK, and DATA (line by line) will be incorporated into the debugger soon. That way I can check my .cfg as I go. Right now if I screwed up and spelled BLOCK as BL0CK by mistake I wouldn't know, because Stella will just ignore that command anyhow. My bigger worry is making overlapping ranges, and I wouldn't know they overlap because these new commands are ignored. Plus I want to see how the new DATA format will stand out visually from the GFX areas. It should really be sweet.

I may be able to find a block of time (no pun intended) in the next few weeks to look over this. But I guess you guys should specify exactly how you want the output to look for SKIP/BLOCK/DATA. I think it'll be relatively easy to add support, depending on how you want it to look.

 

I never realized how beneficial it would be to have a .cfg file auto-produced. It saves a lot of time over doing the whole thing from scratch. I just finished River Raid and all it's variants. I used TRAPREAD quite a bit to determine if gfx areas in the Bermuda hacks were being used. Stephena, I was wondering if there was any way to use TRAPREAD over a range of values? I mean I wanted to know if $FC00 - $FC12 were being read for example. Is there a tracelog or something?

Just a reminder that the auto-generation of config files isn't completely comprehensive yet. There are still cases where CODE are marked as DATA, since they haven't been referenced within the debugger as such (remember that for now, only code actually discovered while in the debugger is marked as CODE). But even with that limitation, I agree that it's much easier than tracking things down by hand.

 

As for the range for trapxxx, no, it can't be done right now. But I realized that such functionality is very useful a few days ago, so I'll look into adding this soon. Conceptually it's very easy, as you can currently trap on one address. So we just need to do that for every address in the range.

[Omegamatrix]

Version 2 of this project. The new sheet simply has the completed entries from V1 deleted. I also include my completed V1 sheet in the zip.

 

 

ConfigMaster(v2.0).zip

[+stephena]

Just wondering on the status of this stuff. There was a flurry of posting back and forth, and now no comments for two weeks. On my end, I'm still working on improving the output from Distella, and having the emulation automatically track whether an address is accessed as code, even outside the debugger.

 

My main question right now is, what do you want the SKIP and BLOCK directives to do? How should the output look?? A small sample showing the differences between SKIP/BLOCK/DATA and CODE would be beneficial ...

[Omegamatrix]

I did about another 30 config files, and then started playing around with the old Distella myself, seeing what it can do. I got some pretty sweet ideas, but I'd like to take a couple of weeks to hammer them out before presenting them.

 

 

With the global config files, I honestly don't know how many more I'll make. It just takes time away from my normal programming and hacking. However that being said, I do believe I will come back to them from time to time and add a bunch. Makes sense to me to leave it as an on-going project that anyone can contribute to. The real meat and potatoes is in Stella being able to have these passed to it, so an individual user can make one for themselves.

 

 

I've been thinking of renaming 'BLOCK' to 'ROW'. The directive name 'SKIP' I'm quite happy with.

 

 

As for output (in Stella):

 

$DF30-$DF33 is GFX

$DF34-$DF3F is ROW

$DF40-$DF49 is DATA

 

A 'SKIP' should be displayed as such in Stella for a BIT skipping 2 bytes:

 

.byte $2C (BIT, skip 2 bytes)

 

likewise:

.byte $0C (NOP, skip 2 bytes)

.byte $24 (BIT, skip 1 byte)

 

and so on...