Disassembled Smurf

[Captain Cozmos]

I started a small topic in the programing thread where I disassembled Smurf Rescue.

 

I am now proud to share an almost cleaned up source that I have produced with an astounding amount of hard work.

 

I plan to clean up the code further but for now it is 100% working as far as I have found.

Instead of supplying you with a test rom I want you to compile it yourself using TNIASM.

 

All you have to do is drag and drop the source on the TNIASM.EXE and it will produce the Smurf Rescue rom which if you compare with proper software will yield no differences.

If you want to do it manually you open up a shell and type TNIASM Smurf.asm

 

I did this for my own knowledge gain and it was a pain because when I sit there and stare at code I do not leave my chair for hours.

 

There are still a number of Pointers that I have not been able to link with some data.  As long as they don't change location the game will compile and produce an exact copy.

 

Since my last post of the source I have identified the music data which is in decimal format.

Maybe at a later date I will redo it to be more pleasant but for now it is plain data to me.

 

This whole game is based off tables pointing to tables so the data was a bit harder to locate.

 

 

In any case, here is the code.

 

Smurf.asm

Edited July 17, 2022 by Captain Cozmos

[Captain Cozmos]

This will be updated again.

I have identified the collision, joystick and jump routines.

Don't worry, I will be working on this for awhile instead of a new source every few days.
Because I am identifying routines and labeling them.

 

I need to track down the enemies because it points to a routine through a swap in ram that defines where they come out on the screen.

I found the data but I need to link a pointer to it.

Out of around 170 routines I am down to 8 pointers and once I get them linked the source can be altered, expanded or whatever and it should work after being compiled.

Until then all I can do is investigate.

 

Another difference I have found also shares with the Donkey Kong.
If I have it right this is using VRam location $2000 for the pattern table and $0000 for the Color.  This is opposite than what I have been taught which I believe is also in one of the TMS 9918 manuals.  In the long run it doesn't matter when it is just a ram location but meh, I thought I would mention it.
 

As far as Donkey Kong:

The screen is built then separate Animated patterns of Pauline and Donkey Kong are put into place with the PUTOBJ command.
I found those patterns as well.

Edited July 19, 2022 by Captain Cozmos

[Zinister]

It would be neat to see a version of Smurf that you could be holding right on the controller and have the up to jump mapped to a button. 

Currently if you remap the up to jump you can't be holding right when you press the jump button.  (Since you wouldn't be able to hold right an up at the same time.)

If that makes any sense..

[Captain Cozmos]

Glancing through the Code again for my own education on using Objects.
I really, really, really want to master this despite everyone telling me to avoid objects.

 

So asking questions, going through the books and code to learn.

Now in revisiting this code I should write an entire book on this analysis because every time I learn something I want to share.

 

 

Today I have discovered that the screen is divided into roughly 3 parts.

The top most portion is of course lives, health and score which take up the first 3 rows.

 

You have a background like the rolling hills with the clouds.

The Castle which is a 7x7 object, which I have already identified the tables and pattern data, and the grass with the point system.

 

The grass/hills seem to be objects as well that goes through the Random generator.

The Object Castle goes along a track of numbers to the left or right when scrolling by leaving the play area to the next screen.

 

This is pretty much the same for all of the screens.

 

Smurfette uses sprites for the dress, shoes and eyes so they do not bleed into the patterns because of the 2 color limitation of the graphics chip.

 

If you had to break it down this game really only has 4 background play fields

The Forest:          The Start Screen with the mushroom superimposed to the left

The Rolling Hills:   

The Cave:

The Rolling Hills:  Gargamel's Castle Superimposed

The Forrest:

Inside the Castle:

Inside the Castle: Smurfette, Platform and Skull superimposed to the right

 

I honestly would love to rewrite this entire game just to see if I could do it with modern coding techniques but right now I have too much on my plate.

 

 

 

Edited August 8, 2022 by Captain Cozmos

[rietveld]

Has anyone found any cool eastereggs while doing this? 

 

Sometimes I will use a HEX editor to read the. Roms and look for anything hidden in there like a name or place

[Captain Cozmos]

3 hours ago, rietveld said:

Has anyone found any cool eastereggs while doing this? 

 

Sometimes I will use a HEX editor to read the. Roms and look for anything hidden in there like a name or place

So far I have only found headaches.
Right now I am working on Frenzy which is 90% completed to the point you can move things around and it will still compile.

When a binary is set in stone all the pointers will only point to that address on the rom chip.

So, I have the tables that point to where the graphics and sound data are "SET IN STONE"

So what I have to do is put a header like Smurf_balls:
Then in the table I can make a reference to where the Smurf keeps his balls.
Such as

Smurf:

db x

db y

dw Smelly

dw Smurf_balls

 

Without that pointer the program will never find Smurfs smelly balls

If I compile the program without changing anything it compiles Smurfs Smelly Balls where it can be found on the rom chip.

My intent is having a 100% changeable and documented source code in order to learn from.

I have made progress but I am not to the point where I can find those balls.

Edited August 11, 2022 by Captain Cozmos