Distella configuration files

[Omegamatrix]

My plan was that the config files are named exactly as Stella would name the ROM in its internal database, but would end in .cfg instead. The reason being, it's then very easy to load a file. I don't need to load a directory and scan for for certain MD5. I can simply take the internal name, remove the ending and append .cfg, and then attempt to load it. When I said you guys should discuss the naming, I meant the naming of the new directives within the config file, not the name of the file itself. So I'll have to insist on the naming from Stella, since it makes things much easier on my end. Note that the names won't be too different from ROMs v5 collection, since I base the internal names in Stella on his naming scheme. For reference, you can get the latest stella.pro file here. If you prefer, there's also a C-style array containing the same info here. Each of these contain all the naming info you need.

This is the information we needed. We weren't sure of how these individual roms were being named in Stella. Now that we know, we will make the final versions of the configuration files the same as the Stella.pro file.

 

The directory was never meant to be the final item that Stella used, it's just a means for us to centralize all the information in the time being. It becomes convenient when configuration files are coming from multiple people.

 

We've discussed the naming of the directives too. So far I'm tentatively calling data spread horizontally "BLOCK", and defining the directive to jump over a byte or two as "SKIP". With all the configuration files in 1 text file, I can mass edit the directive names before they are put into individual configuration files.

 

As for the comments, it's fine to use '//'. I'll treat those lines as comments, where anything after them is ignored. However, adding comments to files created with the 'saveconfig' command will be more difficult. So for now, if you add comments and later edit and save the config file, they will be stripped. Probably better for comments to be added only to the final version of the file.

It's good to know comments are possible. I had no vision for them being used or seen in the debugger. I just saw them being used by people poking around in the global configuration file folder. So as far as I'm concerned everything is perfect.

[Nukey Shay]

No...nobody is talking about reworking Stella's filename method...just trying to figure out a means of matching .cfg info to files so that contributions are valid. The profile list (pardon me for saying so) is rather messy and difficult to follow. Perhaps if the "working" directory had the MD# from the profile inserted beside the filename found in V5? That way, we can be sure that we are disassembling the correct rom to gather cfg info.

[Nukey Shay]

Thx Omega...that was a better way of describing the issue. AFAIK, there is no "Stella collection" of romfiles. The main point is to get everyone who contributes working with the same list/directory to minimize or eliminate the chance that manual labor is needlessly duplicated.

Edited September 4, 2010 by Nukey Shay

[Omegamatrix]

Thx Omega...that was a better way of describing the issue. AFAIK, there is no "Stella collection" of romfiles. The main point is to get everyone who contributes working with the same list/directory to minimize or eliminate the chance that manual labor is needlessly duplicated.

Yep, better to lay a solid foundation and then start building. I'm getting close to the end of adding all the "DUP's" note to the directory list. Once that is completed I will post it.

 

 

I would like to get feedback from anyone on the directive names. Basically in Distella you have:

 

CODE

GFX

DATA

 

Now we are thinking of making DATA display each byte on a separate line. The benefit is the address will be printed beside the byte making it easy to check in the debugger.

 

That being said the old style of having all the bytes displayed horizontally in the debugger will not be lost. It will just have a different name, which I'm hoping you people have some good ideas for. Basically CODE, GFX, and DATA are all easy to understand, so I'm hoping this new directive can be too.

 

I envision this directive being used alot for garbage data. If you by displaying it horizontally it takes up way less space. However, it might be used for other situations, so I don't want to just call it GARBAGE. I think a description name of its function is more appropriate. It's function is to display bytes horizontally instead of vertically. These bytes could be unused code or random acts of God. Originally I was thinking of BDATA for block data, but there has to be a better name then that.

 

The other directive is to handle cases of BIT, CMP, and NOP operands being used to skip a byte or two. Anyone who has disassembled a few roms will have seen obvious cases where BIT is used to skip over a byte or two. A lot of roms use BIT to skip bytes in some places and actually test data in the other! So the idea is to distinguish the two so that in Stella's debugger you could look at one section and see:

 

 

BIT $8E

BVC LF45A

 

Here BIT is obviously influencing the branch. It should appear in the debugger exactly as above. Now the other case:

 

;top of disassembly

LF87E    = $F87E 


  ORG $F000
....code goes for a while

  LDA $A4
  BPL LF87E
  BIT $17A0
  LDA #$23
  BIT $A5

 

What the heck is happening here? The first bit instruction seems to be loading from a location different to the other addresses, and the bit instruction has no effect, because another bit is used before a branching condition occurs. It becomes clear disassembled as:

 

    LDA $A4
  BPL LF87E
  .byte $24 ; BIT, skip 2 bytes
LF87E:
  LDY #$17
  LDA #$23
  BIT $A5

 

 

BIT is clearly being used to skip the next instruction. With an explicit representation like ".byte $24 ; BIT, skip 2 bytes" it is hoped the user can interpret this BIT instruction is being used for this expressed purpose only. This is a big deal because many roms do this interchangeably with normal usage for BIT.

 

However, BIT is not the only instruction being used to skip bytes like this. Illegal NOP's are often used by modern homebrewers to skip bytes while preserving all of the status register flags. I have also seen roms use CMP to skip bytes.

 

What is needed is a directive to distinguish these "skipping bytes" purpose situations. The directive name I've been thinking of to this point is simply called "SKIP".

 

 

You would use SKIP like this in Distella:

 

CODE F4ED F872

SKIP F873 F873

CODE F874 F9E2

 

"SKIP" would pull that opcode and length (-1) and return this in the disassembly:

 

   .byte $24 ; BIT, skip 2 bytes
LF87E:
  LDY #$17

 

Where the BIT instruction here is 3 bytes long, the (-1) makes it print "skip 2 bytes". If this was a NOP opcode that would have been returned instead of a BIT opcode.

 

 

 

So what should we call "SKIP", and "BLOCK" or "BDATA"? This is the real question in this post.

[Nukey Shay]

Not really a pressing issue concerning the specific names, however (because as you said, they could be renamed en masse once a compilation is put together). But BDATA, BLOCK, and SKIP would work for me.

 

At the moment, the proposed BDATA directive works the same as Distella's DATA already does - so it doesn't matter as far as default configuration is concerned. It would be user's preference whether to display data values on individual lines or in groups of 8/16 per line.

 

I'd give BLOCK to bitmaps...any range of bitmap values that are not used sequentially (not appearing in the rom in the order that they are displayed). I suppose it could be called BGFX?

 

Regarding garbage, there are 3 types (garbage code, garbage gfx, or values that don't specifically fall in either catagory - such as filler for spacing/ram/hotspots)...but I dunno if anybody else is interested in documenting them.

 

Hmm...

What about preceding directives with the letter "I" (for indirect), and "G" (for garbage)? Such as ICODE instead of SKIP, since you'd be arriving at a destination indirectly by reusing an opcode as an argument?

 

So in that way, you'd end up with three sets of directives all named basically the same:

CODE, ICODE, and GCODE

DATA, IDATA, and GDATA

GFX, IGFX, and GGFX

 

Might be easier to remember that way?

 

BDATA shouldn't matter, because it should be user choice which way to display data lines by default.

[Omegamatrix]

Here is a master list built off of a directory of Rom Hunters V5 Collection!

 

ConfigMaster(v1.0).zip

 

What's nice about this list is every rom has a number (duplicates excuded) and the rom size. The Supercharger games really jump out at you now because I left them in there size in bytes, not kilobytes. 111 duplicate roms have been noted, and they all have one tag number in common.

 

 

 

How I purpose we use this list is as such... Look at what games haven't been done, make a list and post of what you're going to do, and post it here. That way there is no duplication. Once you're done post the configuration files. I'll add it into the master file, and post updates of the master file periodically.

 

 

 

Any rom configuration file is appreciated. There are sometimes many roms that are very similar (like a pirate company that just erased a logo). In such a case the same configuration file can often be used. If you take up the challenge of trying to do the original plus all pirate versions (or PAL versions too), then a good strategy is to just do a search on the romset and find all the other related roms. Rom Hunter has labeled many if not all pirates with their original names starting wiht "AKA" (as known as). Alternatively you can look up the rom on Atarimania and see its "also known as" titles too.

 

 

 

For the configuration files themselves, choose GFX for all gfx, CODE for all code, and DATA for data. Any garbage code label "BLOCK" for now until a agreement is reached. Using "BLOCK" will make it easy to mass change later. Likewise use "SKIP" for all the BIT instructions being used to skip a byte or two. Finally please post any "Weird" situations here if you're not sure what directive to use. Then we can all talk about it.

 

 

 

@Nukey, I'm hoping some more people give input for the names on these directives. I'd hate it if me and you choose something, and then someone had a kick ass good idea that everyone wanted to use (but the course was already set). Lets hear some more feedback and start the disassembles in the meantime.

[Omegamatrix]

Nukey, I'm going to start with these (and all the variants of each). If you happen to have a good disassembly for any of them let me know! I just went through and listed off some of the folders I have on my hard drive. Most of these I've disassembled, but a few didn't have more than a basic run done.

 

 

 

 

Air Raid

Airlock

Asteroids

Astroblast

Berstain Bears

Blueprint

Bobby is Going Home

Boxing

Bridge

Care Bears

Challenge

Circus Atari

Coke Wins

Commando

Custer's Revenge

Dancing Plate

Datatech Unknown Game

Death Trap

Diagnostic test cart

Dig Dug

Dodge 'Em

Donkey Kong

Double Dragon

Forest

Frostbite

Game Screen (208 in 1 multicart)

Gamma Attack

General Retreat

Glib

H.E.R.O.

Inca Gold

Indy 500

Jr. Pac-Man

Jungle Hunt

Kaboom

Karate

Krull

Kung Fu Master

Mangia

Mega Force

Millipede (Atari)

Millipede (GCC)

Mission 3000AD

Mission Survive

Moon Patrol

Motorodeo

My Golf

No Escape

Othello

Pete Rose Baseball

Playaround Demo

Pressure Cooker

Qbert Qubes

Quadrun

Sea Hawk

Sea Monster

Shooting Arcade

Sky Diver

Smurfs Save the Day

Solar Fox

Solaris

Space Tunnel

SpaceMaster X7

Spitfire

Stampede

Star Wars Empire Strikes Back

Stone Age

Subterranea

Tank Wars

Tapper

Telepathy

Texas Chainsaw Massacre

Time Warp

Tomarc the Barbarian

WaterWorld

Words Attack

X'Mission

[Nukey Shay]

No...as I've posted before, I've always labelled non-program areas as GFX to isolate values on their own lines. I've got to revisit configs that I've done and change them to seperate data from gfx (and any further breakdowns decided upon). Some of the above have been fully reverse-engineered by others IIRC (Asteroids and Donkey Kong sound familiar...tho maybe I'm remembering wrong and they were only partially done?).

 

But hold up a moment...is the above list going to work for Stephen by either including those bracketed numbers in an edited profile database or something? Or are you going to just build a file with all cfg's with the bracketed number (and Stella's MD#) as part of the cfg? Or seperate cfg's for each file? Need to know exactly what is going to work and what is not.

[Omegamatrix]

No...as I've posted before, I've always labelled non-program areas as GFX to isolate values on their own lines. I've got to revisit configs that I've done and change them to seperate data from gfx (and any further breakdowns decided upon). Some of the above have been fully reverse-engineered by others IIRC (Asteroids and Donkey Kong sound familiar...tho maybe I'm remembering wrong and they were only partially done?).

 

All of my disassembles where done using GFX like you did, for the same reason. I have to change all of mine too. If anyone has disassembled the rom before though, they might have made notes that this is a color table, hmove table etc... in the disassembly. That would be extremely useful too.

 

But hold up a moment...is the above list going to work for Stephen by either including those bracketed numbers in an edited profile database or something? Or are you going to just build a file with all cfg's with the bracketed number (and Stella's MD#) as part of the cfg? Or seperate cfg's for each file? Need to know exactly what is going to work and what is not.

 

In the end Stephena will receive individual files with the Stella.pro names. My plan right now is to just leave them all plastered in 1 big text file, and copy and past them out later. The bracketed numbers will be gone. They are only for our reference at the moment.

 

With the MD5 number, I'm thinking about having that as a comment at the top of the individual configuration files. It seems like good information to have in case something gets badly pooched.

 

 

 

Also the master file might get quite large as time goes on. I might break into more pieces at that time, like A-F, G-R, S-Z for example. Most likely I will also let it get to a certain point, and at that time remove & send off all the completed configuration files to Stephena, and then put up a V2 master list which is what is left to be done. How does that sound?

[Nukey Shay]

It's perfectly fine by me...but I was mostly interested in how Stephen felt about it (he's the one that's going to have to encorporate it all eventually). It wouldn't be good to begin something that is unworkable for him without a huge amount of hassle. Maybe look at something simple and post an example to kick it off?

 

But check yer mail. To avoid cluttering up the thread with stuff that (mostly) isn't going to be used, I PM'ed you the disassemblies that I worked with for some of the above titles. Some have comments about how the stuff works in them, but many do not (I'd guess 90% of the Supercharger files are very rough ones done in a couple of edits just to get junk off the hotspots). Some of them will be of no use beyond providing the original cfg pasted at the top due to extensive hacking. Undoubtedly, some have better versions that are completely or mostly R.E.'ed (but none by me...I quit hacking 'em long before figuring all of it out!). But it's a starting point if you've got nothing on 'em.

[Nukey Shay]

BTW I'm starting right at the top of your list if you prefer with all of the 2 pack HES stuff.

[Omegamatrix]

BTW I'm starting right at the top of your list if you prefer with all of the 2 pack HES stuff.

 

That sounds good, Nukey. I can't remember if one of those use Frostbite or not, but here is the first entry I have made in the Master list:

 

 

[0596]8K    Front Line (1984) (Coleco, Ed Temple) (2665) ~.bin
[****]2K    Frontline (AKA Combat) (Zellers).bin
Dup of [0295]
[0598]4K    Frostbite (1983) (Activision, Steve Cartwright) (AX-031) ~.bin

//Stella.pro: "Frostbite (1983) (Activision)"
//MD5: 4CA73EB959299471788F0B685C3BA0B5
[0]
ORG F000
CODE F000 FBFF
GFX FC00 FC38
DATA FC39 FC5F
GFX FC60 FCA9
DATA FCAA FCE9
CODE FCEA FCFB
DATA FCFC FD11
GFX FD12 FD4D
DATA FD4E FD5D
GFX FD5E FDC1
DATA FDC2 FDEF
CODE FDF0 FEE6
DATA FEE7 FEF2
GFX FEF3 FEFE
BLOCK FEFF FEFF // "NOP" space filler
GFX FF00 FF5A
CODE FF5B FF67
GFX FF68 FFBF
DATA FFC0 FFCF
CODE FFD0 FFE8
GFX FFE9 FFF8
DATA FFF9 FFFA
BLOCK FFFB FFFB // "NOP" space filler
DATA FFFC FFFF

[0599]4K    Frostbite (1983) (Digitel).bin
[0600]4K    Frostbite (1983) (Video Mania).bin

 

 

I chose Frostbite because I disassembled it a lot in the past, and I know very accurately what parts are GFX vs Data. Now I'm going to look at all the PAL and pirate versions and knock those off. I love it when I just find the logo changed. Makes life a lot easier.

 

 

So basically we got this big list built off of Rom's V5 collection. I start out by taking that MD5 generator I showed you and running it on the specific rom I want in the V5 collection. It spits out the MD5 number and I copy paste it above the config file as a comment. Then I go to the webpage Stephena posted with the current Stella.pro listings. Since the MD5 number is already queued up for me to paste, I just do a little Cntrl-F, Cntrl-V, Enter, and I'm on the exact entry I need. I then copy the Stella.pro name above the MD5 (for now), and when it comes time to make individual configuration files it'll be easy assign the correct Stella.pro name.

 

 

This method of correlating Rom's V5 collection to the Stella.pro file through MD5 searches seems to be the way to go. I don't think that webpage is sorted alphabetically IIRC. It's a stronger condition to search by MD5 anyway, so I'm happy about it.

[Nukey Shay]

Problem is, I'm stuck typing that MD number by hand because the old Win98-compatable version of Stella doesn't allow highlighting in the game properties window. Or does anyone know of a Win98/Dos workaround which works similar to the incompatable generator program (which crashes right out in Win98)?. Just looking in the profile text file and highlighting it there is an option, but there's too much risk of copying incorrect info that is specific to an alternate version of the game...so I feel safer calling up the game in Stella's game selection and looking at it onscreen. Little extra work, but I'll get it done.

[Nukey Shay]

BTW Frostbite is on the "Rad Action Pak" (not one that I'm currently doing)...but .cfg info has a chance of being different from Activision's version anyway (because of sticking it on a banked cart-that GFX at the tail end you listed is a giveaway that the layout would differ at least slightly in the HES version).

[Omegamatrix]

Problem is, I'm stuck typing that MD number by hand because the old Win98-compatable version of Stella doesn't allow highlighting in the game properties window. Or does anyone know of a Win98/Dos workaround which works similar to the incompatable generator program (which crashes right out in Win98)?. Just looking in the profile text file and highlighting it there is an option, but there's too much risk of copying incorrect info that is specific to an alternate version of the game...so I feel safer calling up the game in Stella's game selection and looking at it onscreen. Little extra work, but I'll get it done.

I could run the MD5 generator and do that part if you want to bundled each rom with a particular config file. It's pretty quick for me, and would save you a lot of time. Typing in by hand is just asking for trouble. I always screw up those 'B' and '8' for example.

 

Stella doesn't let me highlight the MD5 number either. I'm just highlighting the number my little MD5 generator spits out.

[Omegamatrix]

BTW Frostbite is on the "Rad Action Pak" (not one that I'm currently doing)...but .cfg info has a chance of being different from Activision's version anyway (because of sticking it on a banked cart-that GFX at the tail end you listed is a giveaway that the layout would differ at least slightly in the HES version).

 

Yep, but it might serve as a good guide. Better yet, I'll send you my Frostbite disassembly.

[Nukey Shay]

I could run the MD5 generator and do that part if you want to bundled each rom with a particular config file. It's pretty quick for me, and would save you a lot of time. Typing in by hand is just asking for trouble. I always screw up those 'B' and '8' for example.

Not much of an advantage...because it's increasing the stuff moving back and forth and requiring an additional edit. Things that should be avoided if possible...more workload in the end. Better to check the database for verification (which I just realized is pretty quick to do) rather than pass even more unfinished stuff around IMO. Nevermind

[Omegamatrix]

Okay, I just finished:

 

[0401]4K Der kleine Baer (AKA Frostbite) (1983) (Quelle) (685.640 5) (PAL).bin

[0598]4K Frostbite (1983) (Activision, Steve Cartwright) (AX-031) ~.bin

[0599]4K Frostbite (1983) (Digitel).bin

[0600]4K Frostbite (1983) (Video Mania).bin

[0601]4K Frostbite (CCE).bin

[0602]4K Frostbite (Digivision).bin

[0603]4K Frostbite (Hack) (Unknown) (PAL).bin

[0604]4K Frostbite (Unknown) (PAL).bin

[0605]4K Frostbite - Expedition ins Eis (1983) (Activision, Steve Cartwright - Ariola) (EAX-031, EAX-031-04B - 711 031-717) (PAL).bin

 

 

My job was made easy because most of the hacks had minor changes to the logo, so the same configuration file could be applied. I left that Frostbite from the Rad Action pack though Nukey. I'll let you look at it. I did find one primary difference between the NTSC and PAL files. In the NTSC there is and unused NOP at $FCFB. It looks like it is space filler for doing the PAL conversion, because in the PAL version the table begins at $FCFB instead of $FCFC.

 

 

As a side note, the Quelle (PAL) rom is actually a hack of the NTSC Frostbite. They didn't use the PAL version.

 

 

I'm going to start with Asteroids next I think. I'll reference Thomas's disassembly because he noted the garbage code very well. My plan is to keep carpet bombing the romset like this. Work with the roms I know the most about and try to tackle all the variants. The pirates for the most part will be easy. There are so many River Raid, Enduro, Fishing Derby, etc... roms that basically just have a new logo hacked in.

 

 

BTW Nukey, I'm handling the situation of an erased logo as still calling it GFX. It makes sense to me because it is still getting loaded into the player registers, even if the value is zero. It helps identify where the logo originally was.

[Nukey Shay]

A zero value loaded and stored to a GR or PF register is still gfx. There should be no change in .cfg unless the routine itself was edited to skip storing it.

[Nukey Shay]

A zero value loaded and stored to a GR or PF register is still gfx. There should be no change in .cfg unless the routine itself was edited to skip storing it.

[+stephena]

Just checking in again to see your progress. I fixed a few bugs from the last test release, so here's another one: Stella-3.3_test2-windows.zip with the following fixes:

GFX data is now shown in either binary (default) or hex.  This is controlled with the 'gfxformat' commandline argument, and as a right-mouse-click option in the disassembly view.

The disassembly doesn't snap back to the PC after modifying it; it only snaps back when the PC actually changes.  You can still press 'Space' to snap to PC, of course.

Added 'jump' debugger prompt command, which will scroll the disassembly to the specified address (or thereabouts, if it doesn't exist).

The disassembly list and RAM edit areas now accept entry of the '\' character, which is the required prefix for binary input (if the edit field isn't already defaulting to binary).

 

Also, please forward a finished config file for Frostbite, with comments and new directive names. I want to test the parser to make sure if skips comments and ignores directives it doesn't understand.

[Omegamatrix]

Here's a sample copy. I used "BLOCK" in both configuration files. I haven't used the "SKIP" directive yet.

 

 

Sample.zip

[+stephena]

Oops, sorry guys, but I made a mistake in the naming scheme of config files. For user files that are located in the same directory as the ROM, the .cfg should be named exactly as the ROM name as it exists in the filesystem. If this fails, it will fall back to using the name given in the stella.pro file, and stored in a global directory. So to illustrate:

 

1) Assume a global folder named $HOME/.stella/cfg and a ROM named 'frostbite.a26'

 

2) First, Stella tries to load 'frostbite.cfg' from the same directory as the ROM. The reasoning for this is that otherwise, it would force a homebrew developer to adopt the naming scheme of stella.pro for their own ROMs during iterative development.

 

3) If the user cfg file doesn't exist, Stella looks at the ROM MD5 and attempts to load based on the filename of the ROM in the stella.pro properties database. Assuming the standard version of Frostbite, it will then try to load from '$HOME/.stella/cfg/Frostbite (1983) (Activision).cfg'. The reasoning for this is, once a config file is placed in the global config folder, we assume it is for the final iteration of the ROM, and will have a stella.pro entry.

[Omegamatrix]

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?

[Nukey Shay]

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!).