Spent the night disassembling a Smurf

[Captain Cozmos]

It is amazing what you find when you tear things apart.

 

First, I was able to recompile the disassembled code with TNIASM.  No, it did not work completely but I am getting there.

 

Although it will be an exercise to update the code and get it to work in order to improve my skills I did this to learn how the originators did it.

 

I am sure most people know about the pascal labels.  Smurf uses a few in the beginning and then that is about it.

I am also finding that 99% of the game is PUTOBJ and table code.  No tradition NMI on RST 38 either.

This is why I am running into issues because the one who wrote this has everything intertwined.

 

Loading tables then calling timers before executing anything.

 

Anyway,

I'll publish the entire code once I get it working again.

I've already cleaned it up a tad.  JR instead of JP, not using the Pascal entry points.

I'm not going to rewrite it, just seeing if I can.

[Captain Cozmos]

Update:

I have a working reassemble Smurf and learned a lot.

 

Well, not 100% working and has some graphical errors which I think was done because the de-compiler I am using did not get all of the code but as soon as I fix that and clean up the code a bit I will release it and all you will have to do is type in tniasm filename.asm then you will get a working smurf rom.

 

You say I already have a working Smurf Rom, well that is not the point.

 

You can study the code if you want to learn or are just curious.
In all honesty I would love to do this to every single one but this is a real pain separating data from code but not impossible.

 

I have learned a bit about Object manipulation as well as unless the code is updated that it has to use the pascal entry points or it fails.

 

The rom I produced has walking to the right, levels, title screen and all music plus sound effects.

 

A tiny bit of graphics glitch at the top but I went all the way to the end and rescued Smurfette.

 

I have also learned that Smurf also uses the reflect commands which save on sprite pattern data.
So, if you use all the principles in this code you can actually make a cool little game that fits within the unexpanded Colecovision.
After going through 7 Coleco titles, not 3rd party, I have no idea why using BIOS routines get such a bad rap.
 

anyway, I hope that whatever I do here can be added to the official record.

At a minimum be useful to someone other than myself.

Proof of success.rom

Uncleaned Code just compile.zip

Edited July 14, 2022 by Captain Cozmos

[ColecoFan1981]

Good job so far on this project... I wonder if you have disassembled both of the ColecoVision Donkey Kong ROMs (24K early / 16K most) yet?

 

~Ben

[Captain Cozmos]

1 hour ago, ColecoFan1981 said:

Good job so far on this project... I wonder if you have disassembled both of the ColecoVision Donkey Kong ROMs (24K early / 16K most) yet?

 

~Ben

Not yet but I will give it a go.

 

Anything I should focus on?

[ColecoFan1981]

40 minutes ago, Captain Cozmos said:

Not yet but I will give it a go.

 

Anything I should focus on?

My want list:

Timer bonus (differs between versions; 24K has 8000 points maximum while 16K has 99000 points maximum); the 16K ROM version's timer has a bug that allows it to go up to 100,000 points (displayed as 00000, as if Mario had lost a life on time up) and beyond

Score bug on 24K version after you reach roughly 65,535 points (rolls over to 00,040)

Music

Screen 1 broken ladder bug (differs between versions; 24K has Mario disappearing for about 12 seconds before re-emerging on the topmost girder where DK is, while on the 16K version performing the same glitch takes you instantly to the next screen with the remaining time added to your score)

Screen 2 hat collection bug by jumping up toward the girder where the hat is (24K version only)

Screen 3 left elevator bug from Mario's starting position (24K version only)

Skill 1 restart with * key after Game Over that results in only three lives instead of five

 

~Ben

Edited July 14, 2022 by ColecoFan1981

[Captain Cozmos]

No promises but I will see what pops up.

Disassembling Smurf Rescue has turned out to be a real eye opener in the fact that coding practices back then was way different than being organized.

I can understand why especially when they did not have the tools we have now.
 

I have been identifying almost everything in terms of data structures like the Smurfs head, patterns that deal with all backgrounds.

My problem now is that I can't find a pointer to any of the background data as if it sits in rom but there is not one identifiable entry point.
I posted the code so someone with better eyes can look at it

Apparently it moves through the table with IX with a pointer in the PUTOBJ Bios routine or some deal like that.

Non standard timers, non standard NMI but I have a grasp on how it was put together and works.
If it would gain some benefit I would rewrite the whole thing but to what end.  It works as is with maybe one bug moving back and forth between screens.

 

No one is going to make the SGM Smurf advertised in 83?  and even if they did it would be a total rewrite with standardized code.

 

So, I'll disassemble your DK and see whats what but I may call Smurf quits and give what work I have done which is plenty for anyone else to look at and finish to get a clean listing.

As a matter of fact here is my latest disassemble listing.

SMFRSC.asm

Edited July 14, 2022 by Captain Cozmos

[ColecoFan1981]

11 hours ago, Captain Cozmos said:

No promises but I will see what pops up.

Disassembling Smurf Rescue has turned out to be a real eye opener in the fact that coding practices back then was way different than being organized.

I can understand why especially when they did not have the tools we have now.
 

I have been identifying almost everything in terms of data structures like the Smurfs head, patterns that deal with all backgrounds.

My problem now is that I can't find a pointer to any of the background data as if it sits in rom but there is not one identifiable entry point.
I posted the code so someone with better eyes can look at it

Apparently it moves through the table with IX with a pointer in the PUTOBJ Bios routine or some deal like that.

Non standard timers, non standard NMI but I have a grasp on how it was put together and works.
If it would gain some benefit I would rewrite the whole thing but to what end.  It works as is with maybe one bug moving back and forth between screens.

 

No one is going to make the SGM Smurf advertised in 83?  and even if they did it would be a total rewrite with standardized code.

 

So, I'll disassemble your DK and see whats what but I may call Smurf quits and give what work I have done which is plenty for anyone else to look at and finish to get a clean listing.

As a matter of fact here is my latest disassemble listing.

SMFRSC.asm 128.33 kB · 3 downloads

We could [regarding the Smurf Rescue Super Game that never was], but we'd probably get a cease-and-desist from Peyo (the Smurfs' trademark owner) if it was released publicly. But I am among those who would love to see it be released.

 

~Ben

Edited July 14, 2022 by ColecoFan1981

[Captain Cozmos]

I am still working on this.
The more I learn how things function the faster I can work on other Coleco games.

I discovered that recompiling this game shifts data around just a tiny bit.  Most everything stayed in place but there is some data off which gives the graphics glitch at top.

So, after going over the code with a fine tooth comb and swollen eyes I have identified several tables that the disassembler had no way of knowing.

These tables point to the final resting place of graphics or sound data on rom for the last 40 years so I have to give all those areas pointers then add those to the tables.

This investigative work takes time but I am confident.

Now, with modern compilers the data can shift around to anywhere the compiler wants to put them and the game will work.

 

I still have around 20 or so sets of tables and then the game should compile and run as intended.

 

 

What this also means is that I should be able to disassemble, alter then reassemble any Z80 based game within reason and it should run on the Coleco environment.

I found a Z80 based version of Ball Blazer, imagine that on the Colecovision or ADAM.

[Bruce Tomlin]

Definitely fun stuff. I wrote an interactive disassembler (with a Text UI) a few months ago because I got tired of years of picking at things a little at a time. I've got most of the CPUs also supported in my assembler, so I can make sure they re-assemble properly. (I still need to make a proper release of my assembler after all these years, but I've had so many changes in the past few weeks because of finding a lot of bugs with my disassembler!) Getting a good disassembly done is a lot of work, but once you get good at it, it turns days of work into a few hours. Then I have to go back to my piles of weird stuff and dig for more ROMs to disassemble.

 

Having a good disassembly of Girl's Garden around was good luck when a call came to port it, but that was done with my old hard way.

 

A few weeks ago I finished doing a basic disassembly of all the main Coleco ROMs with it. That took me a couple of months, but eventually the fun ended. Smurf Rescue was one of the later ones I did, so it was just a basic pass. But you got me to open it up again and look into some of its data. Holy pointers, Batman. Even interactively it's a lot of work.

 

Anyhow, you should try out my disassembler (see signature line). You do have to compile it yourself, and there's currently no Windows version because I only use Mac and Linux for development. (fyi, it needs the ncurses library too) One nice thing is that I made it possible to share just the files with your disassembly work, and not the ROMs. There's an example in the Programming forum with compiled Linux and Mac versions, and a disassembly of the Coleco Final Test.

Edited July 20, 2022 by Bruce Tomlin

[Tempest]

Anything interesting hidden in the code?  Anything unused?

[Bruce Tomlin]

Nothing obvious that I saw, not that you can't hide something in turns of code. And it looks like the image data has basic RLE compression. But there's less than 70 bytes free at the end, so not exactly a lot of space for hiding things.

[Zak]

On 7/20/2022 at 7:06 PM, Bruce Tomlin said:

Definitely fun stuff. I wrote an interactive disassembler (with a Text UI) a few months ago because I got tired of years of picking at things a little at a time. I've got most of the CPUs also supported in my assembler, so I can make sure they re-assemble properly. (I still need to make a proper release of my assembler after all these years, but I've had so many changes in the past few weeks because of finding a lot of bugs with my disassembler!) Getting a good disassembly done is a lot of work, but once you get good at it, it turns days of work into a few hours. Then I have to go back to my piles of weird stuff and dig for more ROMs to disassemble.

 

Having a good disassembly of Girl's Garden around was good luck when a call came to port it, but that was done with my old hard way.

 

A few weeks ago I finished doing a basic disassembly of all the main Coleco ROMs with it. That took me a couple of months, but eventually the fun ended. Smurf Rescue was one of the later ones I did, so it was just a basic pass. But you got me to open it up again and look into some of its data. Holy pointers, Batman. Even interactively it's a lot of work.

 

Anyhow, you should try out my disassembler (see signature line). You do have to compile it yourself, and there's currently no Windows version because I only use Mac and Linux for development. (fyi, it needs the ncurses library too) One nice thing is that I made it possible to share just the files with your disassembly work, and not the ROMs. There's an example in the Programming forum with compiled Linux and Mac versions, and a disassembly of the Coleco Final Test.

Hi Bruce!   do you have a disassembly of the "Coleco Final Test"  that can be recompiled and work ?  I was just asking Captain Cozmos how to disassemble that rom...