Organization of Roms and Revisions

[Prizrak]

Not sure, makes sense. The great thing is PlusCart is what we make it. I do hope tagging tied with Stella stuff makes things smoother for the backend and sorting the large amount of data we have.

Sent from my SM-N960U using Tapatalk

[Prizrak]

@Omegamatrix where do you want new hacks put? I've dropped 2 new ones in the alphabetical area _J-P for example.

 

[Prizrak]

@Omegamatrix GFVH makes those unusual games like outuns lair and now has King Solomon's Mines. I temporarily put his folder in My Roms area for lack of what to do with it and I want to know where under homebrew do you think I should put it. He has so many so I felt he deserved his old folder. What do you think

[Omegamatrix]

Great questions! With the new hacks it makes sense to file them, but maybe there could be a transition folder to identify new ones. Just an idea but maybe have a folder for 2020 hacks and at the end of the year they transistion into the other folders like _J-P. That would make the future maintainence of tagging more manageable. The existing _J-P folder and so on could be worked on for tagging, and then it's just the new roms to do, but at least at that point it's more systematic. What do you think?

 

I don't know GFVH but yeah absolutely if you want to group them as a highlight than lets do it. Maybe the Homebrew Spotlight folder could transistion into this purpose? Just needs a new name like Author Spotlight, or something like that.

 

Overall I really like your ideas and we are catching a lot of momentum now. I just hope I don't lose steam ha ha.

 

 

As a total side note I tried the Pink Panther Rom last night and it is incompatible. So I might move it somewhere or just remove it. Without thinking I had posted the version that Batari converted to run on Harmony, but format doesn't work on the pluscart.

[Prizrak]

The new hacks I've posted I'll move to a 2020 folder until we gets everything situated. Want to do the same thing with homebrews?

[Omegamatrix]

1 hour ago, Prizrak said:

The new hacks I've posted I'll move to a 2020 folder until we gets everything situated. Want to do the same thing with homebrews?

Yeah seems reasonable to do both that way.

[+Al_Nafuur]

8 hours ago, Omegamatrix said:

As a total side note I tried the Pink Panther Rom last night and it is incompatible. So I might move it somewhere or just remove it. Without thinking I had posted the version that Batari converted to run on Harmony, but format doesn't work on the pluscart.

Pink Panther should work on the UnoCart and the PlusCart @DirtyHairy implemented the bankswitching scheme.
Which VCS version are you using?

[Thomas Jentzsch]

There exists a fixed version of PP, the original dump had a few extra bytes.

[Bomberman94]

Original Prototype version (NTSC version) works with PlusCart - checked on my Atari 6switch PAL console. 

[Omegamatrix]

I was using the fix. I will remove it and use the original in this case.

[Thomas Jentzsch]

Hm, actually it would be better if the code for Plus- and UnoCart would be corrected to work with the fixed dump.

 

@DirtyHairy Can you give some feedback here?

[+Al_Nafuur]

21 hours ago, Thomas Jentzsch said:

Hm, actually it would be better if the code for Plus- and UnoCart would be corrected to work with the fixed dump.

 

@DirtyHairy Can you give some feedback here?

I just check the code. Detection in UnoCart and PlusCart is:

image_size == 8*1024 + 3

see:

https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/STM32firmware/PlusCart/Src/main.c#L637

https://github.com/DirtyHairy/UnoCart-2600/blob/master/source/STM32firmware/Atari2600Cart/src/main.c#L540

 

what is the size of the fixed dump (8*1024) ?

 

[Thomas Jentzsch]

Correct. The 3 extra bytes are superfluous. Also correct the bank order is different.

 

See CartWD class in Stella.

Pursuit of the Pink Panther (Probe) (Prototype) [fixed].bin

Edited October 23, 2020 by Thomas Jentzsch

[+Andrew Davie]

Didn't @Thomas Jentzsch have a tool that could check the similarity/genesis of a ROM, providing some sort of measure for comparing ROMs?

If so, could this be used for providing some linkage/origin/organisation in grouping hacks with their original source?

 

[Thomas Jentzsch]

1 minute ago, Andrew Davie said:

Didn't @Thomas Jentzsch have a tool that could check the similarity/genesis of a ROM, providing some sort of measure for comparing ROMs?

If so, could this be used for providing some linkage/origin/organisation in grouping hacks with their original source?

CloneSpy

[+batari]

Can someone direct me to the technical details of how to modify ROMs for HSC, and submission guidelines? I see there is no search feature in this club, so I haven't been able to find it

[+batari]

On 10/21/2020 at 2:55 AM, Thomas Jentzsch said:

There exists a fixed version of PP, the original dump had a few extra bytes.

PP was originally dumped in 2010, but not released due to request by the cart owner. The Harmony version was created in 2010 but only distributed privately, also upon request. When someone else dumped and released the game, I felt I was free to release the Harmony version too.

 

The 3 bytes are there because the original cart sometimes had just these 3 bytes swapped out of the 4k memory space. That, and the unique file size helped with cart detection when the scheme was originally added to Stella in around 2014-5 (not sure exactly when this happened.) I suppose it could work without the 3 bytes as I don't know what they were meant for, but I kept them in just to be sure as I have never seen such strange behavior from a cart!

[+Al_Nafuur]

1 hour ago, batari said:

Can someone direct me to the technical details of how to modify ROMs for HSC, and submission guidelines? I see there is no search feature in this club, so I haven't been able to find it

To modify a ROM you have to use the PlusROM functions to send the game variation, the score bytes ( BCD values ?) and the game ID to the high score API. The transformation of these bytes to a score and game variation must be setup in the database (and of course the game ID) before these values can be send.

 

You can find some example code for the HSC in the PlusCart repository (look for the "PLUSROM" switch) :
https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/examples/Turmoil HighScore.asm#L2595

 

If you want to contribute/modify a game for the HSC you should send a PM to @Omegamatrix and me, so we can define the transformation that is necessary in the backend and give you a game ID.

 

 

Edited January 16, 2021 by Al_Nafuur
more info

[Thomas Jentzsch]

8 hours ago, batari said:

PP was originally dumped in 2010, but not released due to request by the cart owner. The Harmony version was created in 2010 but only distributed privately, also upon request. When someone else dumped and released the game, I felt I was free to release the Harmony version too.

 

The 3 bytes are there because the original cart sometimes had just these 3 bytes swapped out of the 4k memory space. That, and the unique file size helped with cart detection when the scheme was originally added to Stella in around 2014-5 (not sure exactly when this happened.) I suppose it could work without the 3 bytes as I don't know what they were meant for, but I kept them in just to be sure as I have never seen such strange behavior from a cart!

Not sure where these 3 bytes came from, but they are definitely not used by the game. Maybe some dumping or developing artifacts?

 

Anyway, we released a fixed version without these 3 bytes and a slightly changed bank order.

[+batari]

On 1/16/2021 at 1:55 AM, Thomas Jentzsch said:

Not sure where these 3 bytes came from, but they are definitely not used by the game. Maybe some dumping or developing artifacts?

 

Anyway, we released a fixed version without these 3 bytes and a slightly changed bank order.

I don't think they are dumping artifacts as they were consistent and they were located at the reset vector. I could be wrong I suppose but it didn't seem coincidental that these three bytes were consistently swapped out of this space.

 

I didn't find any logical organization to the bank order, but I was hoping someone would eventually and reorganize them in a way that made sense.

 

These are my original findings, which I contributed in 2014 so that Stella could support the game. I think nobody noticed that the support was there for 5 years before the game was released publicly.

The binary is nominally 8k, but three bytes may be switched in at location 0x3FC-0x3FE in the last 1k bank in the 4k space, so the three bytes are placed and the end of the 8k binary and the size will be 8195 bytes (also makes it very easy to detect.)

It has 64 bytes of RAM on the cart - the read port is $1000-$103F and the write port is from $1040-$107F.

The ROM is organized as eight 1k chunks, and can be placed in different 1k slots in the 4k memory space (somewhat similar to Parker Bros. bankswitching, but with key differences as the bank organization is available only in certain combinations. There may be a pattern that makes more sense and can be encoded easier as the bank numbers were chosen arbitrarily, but I haven't been able to figure it out.)

There are 16 hotspots that are located at $0030 to $003F.

When a chunk is placed in the first 1k slot, you can't use the first 128 bytes of it due to the RAM read/write addresses.

When a hotspot is hit, it doesn't switch banks right away - the bankswitch is delayed by three cycles (or perhaps three address changes, but I think either will work. I think I used address changes.)

The organization of 1k chunks for each of the 16 hotspots is weird. I numbered the 1k chunks 0-7, with a * after the hotspots that swap in the 3 bytes near the end of the bank:

$0030: 0,0,1,2
$0031: 0,1,3,2
$0032: 4,5,6,7
$0033: 7,4,3,2
$0034: 0,0,6,7
$0035: 0,1,7,6
$0036: 3,2,4,5
$0037: 6,0,5,1
$0038: 0,0,1,2
$0039: 0,1,3,2
$003A: 4,5,6,8
$003B: 7,4,3,2
$003C: 0,0,6,7*
$003D: 0,1,7,6*
$003E: 3,2,4,5*
$003F: 6,0,5,1*

As you can see, banks 8-F are almost the same as banks 0-7. The only difference is the 3 bytes in the 4th chunk of banks C-F.

[Thomas Jentzsch]

When they are not resulting, then they are probably used for development.

 

I also tried to find a pattern in the bank organization, with little success too. I only swapped banks 2 and 3 of the dump, after analyzing the code.

[Prizrak]

Currently when a new binary is released for a game in development I'll make a previous builds folder to put the old one and create a history for that development. Question that hit me today is do we want to be a repository for the history of such content or just offer the latest version of that game. A only current copy might make us feel more like a standard store, wether that be app store or online game store. Just looking for some thoughts before I get a hair to go and start deleting/moving stuff.

[Thomas Jentzsch]

As long as you keep the old versions separated, no one should complain. But it seems like a lot of work to keep track of all the games.

[Prizrak]

I think so too, keeping most recent version of said binary might be the best course long haul.

[Prizrak]

Updating some binarys lately and realized there's a ton of WIP games. Some authors don't denote when a game is a final version. Take Sisyphus for example, may never have another update to it and as far as we know it may be complete. Yet some games go years before getting another update. At what point do we move something from WIP to completed without author consent? Can we move a game to completed and then pull it back to WIP if need be? Also when I try and move some files I get a message saying it's locked.