News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - RetroRain

Pages: [1] 2 3
Would you buy a new console that is 8-bit, and puts out brand new retro games, and that's not made by Atari?

It's a one-question survey.

It's a simple question with a simple answer to choose from: Yes/No/Maybe

Would you buy it?

Programming / NES Question - Best Method for Sprite Engine?
« on: August 22, 2017, 11:48:57 am »
I know how sprites work (Ycoor, TileID, Pal/Rot, Xcoor), and how to get them to the screen.

Most tutorials and documents tell you how to handle sprites, but there is very little information when it comes to game logic, in coding a sprite engine.

Most games are not a singe 8x8 sprite tile.  Characters and enemies are made up of a bunch of 8x8 sprite tiles.  This is where it becomes difficult for me.

Let's say I have this routine, which is only executed once when the player object is created:

Code: [Select]
; initialize player object

lda #$60
sta player_xpos
lda #$50
sta player_ypos

; simply set the player's x and y position on the screen

Simple enough, right?

I know how to draw all of the sprites for the player, but I don't know how to do it in the most efficient way.  So far, most of the ways I have done it, use up a ton of code.

Let's say my player objects consists of 9 sprite tiles (Megaman, for example, while he is standing, is 9 8x8 sprite tiles)

I have this routine, which is executed every frame:

Code: [Select]
; player handler

; draw player - method 1

; The X and Y coordinates are the center origin of the player, so that if the player has to be mirrored, he'll be mirrored smoothly

; ***
; ***
; ***

; These asterisks represent the 9 8x8 sprite tiles

; One way I have done it, is start in the middle, and draw from there

; ***
; *+*
; ***

So, the plus sign represents the x and y position

lda player_ypos
sbc #$08
sta $200

; store the y for the first tile

lda player_xpos
sbc #$08
sta $203

; store the x for the first tile

; Then draw the tile and pal/rot values

lda #$00
sta $201

lda #$00
sta $202

When ROM hacking, I've seen games keep a table of the tile ID and pal/rot value right next to each other, so I tried programming that way too.  That way seems very difficult as well.  I'm manually programming every single sprite to the screen.  There has to be a more efficient way of doing things.  I just can't wrap my head around the logic.

Mirroring is a pain, because depending on which direction (left or right) the sprite is facing, the tiles that were supposed to be on the left side, now have to be on the right, but the middle can stay the same.

There are a few different ways that I have used to get a player sprite to appear, but the coding is intensive.  Is there a way to efficiently create a sprite engine, so that no matter what sprite you want to display, you can display all of the tiles, and correctly depending on the mirroring?

I have even tried making the xpos and ypos the top-left corner of the player, but then when it comes time to mirroring, it doesn't look right.  Unless I were to simply change the x/y positions when mirroring occurs.

I'm going to do some more studying of ROMs to see how the sprite engines are handled, but if anyone has any suggestions, that would be of great help.


Programming / C++ Enumeration error in switch statement
« on: July 22, 2017, 10:47:18 am »
I have this code (it's not really a lot as it looks) that, when run, is showing these compiler errors:

Code: [Select]
In function `void logic()':
`left' undeclared (first use this function)
(Each undeclared identifier is reported only once for each function it appears in.)
`right' undeclared (first use this function)

The problem is, I can't figure out why it is producing this compiler error.

I have a switch statement in the function below, called void logic(), and it checks stop, up, down, left and right.  There is no problem with the first three enumerators, but it has a problem with left and right.  If I comment left and right (so it doesn't execute), the program runs fine.

I don't get it, because the enumators are all declared.  Why is there a problem with left and right?

If it helps any, I am coding with Dev-CPP.

Code: [Select]
#include <iostream>
#include <conio.h>
using namespace std;

void setup();
void draw();
void logic();

enum direction {stop, up, down, left, right};
direction dir;

int snakeX, snakeY, snakeLength, lives, score;
int roomLength, roomHeight, appleX, appleY, i, j;

int main()
    return 0;

void setup()
    roomLength = 40;
    roomHeight = 20;
    snakeX = roomLength / 2;
    snakeY = roomHeight / 2;
    appleX = rand() % roomLength;
    appleY = rand() % roomHeight;
    snakeLength = 1;
    lives = 3;
    score = 0;
    dir = stop;

void draw()
    //first row
    for (i = 0; i < roomLength; i++)
        cout << "+";
    cout << endl;
    //the middle rows
    for (j = 1; j < roomHeight-1; j++)
        cout << "+";
        for (i = 1; i < roomLength-1; i++)
            if (i == snakeX && j == snakeY) cout << "O";
            else if (i == appleX && j == appleY) cout << "A";
            else cout << " ";
        cout << "+" << endl;
    //last row
    for (i = 0; i < roomLength; i++)
        cout << "+";

void logic()
    switch (dir)
        case stop:
        case up:
        case down:
        case left:
        case right:

Right where case left and case right are, is where the errors are being pointed out.  Yet I can see no error at all.  There are no typos at all.  You can copy and paste this code yourself in any IDE, and see for yourself.  The header file conio is just for keyboard input that I haven't gotten to yet, so it doesn't matter if it is there or not.

If anyone can tell me why it is producing this error, you can have a giant cookie!


Okay, so I did some searching.  This article tells you that the compiler will give you errors if one of the enumerators is not handled properly (

So that got me thinking... I tried using single quotes on my enumerator, and the program ran.

Code: [Select]
void logic()
    switch (Edir)
        case stop:
        case up:
        case down:
        case 'left':
        case 'right':

I just had to put left and right in single quotes for it to run.  I most likely have to do that for other three as well, but I honestly didn't know that you had to do that.

ROM Hacking Discussion / Mega Man Remastered
« on: May 28, 2017, 04:39:09 pm »
Celebrating the 30th Anniversary of the Mega Man series with a remaster of the first game that started it all!

Mega Man Remastered (formerly known as the Upgrade Patch) is a patch for the first Mega Man game, which enhances it in so many ways, without modifying the levels or graphics (minor graphics and palette changes, which are listed below).  To those that are familiar with the Upgrade Patch, you could consider this Version 1.7 of it.

Here is a list of all of the new changes made since Upgrade Patch Version 1.6:

· Mega Man's face on the titlescreen has been fixed.  It was missing two pieces on the right side of his face.

· Continue is now New Game, and Erase Data is now Continue, and they function as such.  Data is no longer erased.  If you want to start a fresh game, select New Game.  If you want to load a previously saved game, select Continue.  Remember, the game is saved after the completion of a stage, and when you obtain the special weapon in Elec Man's stage.  The Wily stages are the only stages that are not saved.  This allows you the ability to play through all of the stages in the game.

· The gameover screen now looks more like Mega Man 2's.  It was too bland before.

· The cursors for the titlescreen and gameover screens have been updated.

· My credits: 2014 RetroRain is now 2017 RetroRain.

· Dr. Wily has been fixed on the stage select screen.  His face was all black.  This has now been remedied.

· Besides the select button, the up and down keys can also move the cursor on the titlescreen and gameover screen.

· The Ready text at the beginning of a stage now flashes.

· If you fall down a pit or on spikes, your health meter will now show empty.  It didn't do that in the original game.

· You can now toggle obtained weapons with the select button.  As such, the pause feature has been removed.  But this is not a big deal, as the inventory screen doubles as a pause feature.

· The score balls have been removed completely.

· Newly designed Remastered logo for the titlescreen.

Here is a TOTAL list of all of the changes that Mega Man Remastered has made from the original game.  This list can also be found in the readme:

· Converted to Mapper 4: MMC3.
· Graphics format converted to CHR-ROM.
· PRG and CHR ROM expanded to the new mapper's maximum limit.
· The game now has the ability to save and load your progress.
· All-new titlescreen.
· Updated font for stage select and boss-preview screens.
· Updated cursors for titlescreen and gameover screen.
· Stage select screen has a new palette.
· Boss-preview screen is now like Mega Man 2's, with the preceding flash to it removed.
· Gameover screen has been updated to look more like Mega Man 2's.
· Updated palettes for Cut Man and Elec Man stages.
· Score and score balls have been removed from the game.
· Mega Man palette updates for three weapons: Ice Slasher, Elec Beam and Bombs.
· Boss energy bars moved over to the right side of the screen.
· Updated health and weapon capsule graphics to match those of the later Mega Man games.
· Ready text has been updated: It now flashes, has a new font, and the time it is displayed for has been cut in half.
· Up, down and select can move the cursor on the titlescreen and gameover screen up and down.
· Falling down a pit or on spikes will display your health meter empty.
· Select button toggles between obtained weapons (hence removing the pause feature).

This patch is to be applied to the English version, Mega Man, not the Japanese version, Rock Man.  This ROM was tested to work on FCEUX 2.2.2.  I have not tested it on other emulators.  You may use this patch as a base for your Mega Man hacks, just please give credit if you do.


Enjoy! :)

I have this code, where I want to change the palettes of PPU addresses $3F11 and $3F12.

Originally I had it where I set $2006 to $3F11, and then I did two writes to $2007.

However, for whatever reason (and I tried playing around with clearing and setting Carry), at some points, it will jump to $3F13 and write a value there.  And I don't know why it does it.

So I tried separating $3F11 and $3F12, and it is still doing it.  At some random point, it will write a value to $3F13, even though there is clearly no code making that happen.

I know that the register $2007 has a quirk to it, so I was wondering if that is what is causing the problem.

If it helps any, the code is when you press a button, it changes the palette of the character.

(I don't have it shown in the code, but just before the code, I have a LDA $2002 and a BPL (wait for Vblank), and after the code a LDA #$20 and #$00 written to $2006 to reset the PPU)

Code: [Select]
   :61E3:A9 3F     LDA #$3F
   :61E5:8D 06 20  STA $2006 = #$13
   :61E8:A9 11     LDA #$11
   :61EA:8D 06 20  STA $2006 = #$13

   :61ED:A6 5F     LDX $005F = #$02
   :61EF:BD 10 62  LDA $6210,X @ $6212 = #$30
   :61F2:8D 07 20  STA $2007 = #$20

   :61F5:A9 3F     LDA #$3F
   :61F7:8D 06 20  STA $2006 = #$13
   :61FA:A9 12     LDA #$12
   :61FC:8D 06 20  STA $2006 = #$13

   :61FF:BD 18 62  LDA $6218,X @ $621A = #$2C
   :6202:8D 07 20  STA $2007 = #$20

If anyone has any ideas, feel free to let me know.  Thanks.

SMB2: SMP = Super Mario Bros. 2: Standard Mario Patch

Yes, it's not making me any money, but I had some free time off, and I felt like doing what I enjoyed.  That, and I really wanted to finish this hack.  So here it is.

For those who don't know what the SMP is, it is a patch that makes SMB2 more like the other Mario games, like replacing the cherries with coins, making the turtle shells bounce on collision instead of disappearing, and updating some things such as character palettes, the health meter graphics, and adding coin counters to the pause screen.


The readme lists all of the changes.

Download (Updated to Version 1.2)

Enjoy! :)

ROM Hacking Discussion / Megaman Engine Homebrew Demo Released
« on: January 12, 2017, 10:59:29 am »
Think of it as a late Christmas present. ;)

I haven't had a lot of time to work on this project, so I am releasing what I have done so far.


Enjoy! :)

I know how to modify palettes, even the attributes for sprites (which palette set it uses), but how do you do that for background objects?  In other words, I have an object that doesn't use sprites for its graphics, it uses background tiles, but I don't want to modify the palettes, I simply want to change the palette set it uses, like you can with the sprite attribute byte.  I haven't done that before, and doing some searching hasn't yielded many results.  I don't imagine it would be that hard to do.  I just need to know what I should look for.

Any help would be appreciated.

Thanks. :)


The only bit of information I was able to find has to do with the NES' attribute tables.  There are some RAM addresses which store the level's attribute table data, and then I guess are written to the PPU.

But does the attribute tile data for the whole level have to be changed, or is there a way to change the object's palette set?

I'm making this topic because I care, to put it simply.  I was going to put this in the General Discussion forum, but I'm putting it in here because it is aimed at those who do ROM hacking and/or game development of any kind.  So moderators, please read this and consider before deciding to move my topic.

For the past 2-3 years, I have developed some really bad eye-strain.  I have been ROM hacking since 1999, but it has been the last few years where the eye-strain has been really bad, and I have gotten major discomfort because of it.

It has gotten so bad that I honestly thought I would never be able to do anything computer-related anymore.  That I'd have to live a computer-free life.

I bought polarized glasses a few years ago, and have been using them the last several months, but they really aren't meant for computer use.  The reason I wasn't using them all this time is because they make everything too dark.  I honestly had no idea that they made glasses specifically for the computer.  I only recently just found out about them, and I ordered a pair.

I purchased Pixel Eyewear.

Their website is here:

The ones I purchased were $70, but there's that old saying "You get what you pay for," and $70 is a small price to pay for glasses that would filter out blue light and greatly reduce eye-strain from computer use.

What I have for my laptop, is a privacy screen (a thin piece of plastic which filters out some of the glare, and only allows you to see the screen by looking directly at it), the brightness turned down to zero, and now I'm using the computer glasses.  So now, with all three things, I hope to greatly reduce my eye-strain, and be able to continue doing the computer projects I very much love to do, without destroying my health in the process.

And it is for that reason I am making this post.  I don't want anyone to have to go through what I went through.  It got really bad the last couple of years.  Where I had weird pain sensations, that I thought I was going to have some kind of stroke.  And this happened on more than one occassion.  It's really scary.  It felt like the brain itself, was trembling.  Literally.  I honestly wanted to check myself into a hospital because I was afraid something would happen to me.  That is why I took long breaks from ROM hacking, and tried to distance myself from the computer.

But it is really hard to give up something completely, that is a life passion.  It is like telling a painter who LOVES to paint, that he can never paint ever again.

All I have to say, is that I am thankful that there are companies out there that make glasses designed specifically for computer use.  Protection from the computer screen is EXTEMELY IMPORTANT.  I can't emphasize that enough.  Your health is very important.

If you love ROM hacking and Game Development, or just doing computer projects in general, please take care of your health, through your eyes.  Get yourself a pair of computer glasses.

Granted tonight is my first night using them, and I still have to give it some time to tell if they are really working for me, but I am confident that they will, especially in conjuction with the other two things, the privacy screen and the brightness turned all the way down.

The comptuer screens give off artificial blue light, that is not only bad for your eyes, but it messes with your internal body settings.  It releases serotonin which can keep you up at night.  I came across this while doing a little bit of research.

I'm merely strongly recommending that if you love ROM hacking, love making computer games, that if you are going to sit for hours in front of the computer screen, that you protect your eyes and your health, and get a pair of glasses that will protect you.

Another site that has computer glasses is Gunnar:

You can also obviously do some research yourself on Google.

But that is all I wanted to say.

I love ROM hacking and game development as I hobby, and now with these glasses, I hope to be able to continue to do what I love to do, without all of the pain and suffering that comes with the computer usage.

Thanks for reading, and happy ROM hacking! :)



As an added thought, anyone who uses the the computer long-term should wear computer glasses, so I suppose I should have posted this in the General Discussion forum afterall, but my intent was to support people who do ROM hacking and game development, because both of those things require long-term computer usage.  I didn't want to come off as a jerk who only cared about ROM hackers and game developers.  It's just that I'm making this post on a ROM hacking forum.

ROM Hacking Discussion / SMB2 Cherries-to-Coins Hack now in the works
« on: October 22, 2016, 05:02:55 pm »
Several years ago, DahrkDaiz made a Super Mario Bros. 2 (USA) hack, in which he changed all the cherries to coins, to behave more like the other Mario games.

Apparently, from what people have said, the hack is no longer around.  So, unless someone who has it comes forth with it, it is one of those "lost" hacks.

I had someone requesting me to remake it, and I believe there are a few others that have an interest in this kind of hack.

I'm in the beginning phases of my next project, but I suppose I could postpone it and do this hack, since I don't imagine it would take too long, or be that hard to do.

However, I need some input.

How should I do this?

For instance, in the original game, I think it was 7 cherries that gave you a star.  If I turn the cherries to coins, then I would no longer make the coins give you a star.  Instead, I would make 100 coins give you a 1-up, like in other Mario games.

- However, since there are not going to be anywhere near 100 cherries in a level, I would have to come down on that number.  More like between 10-20 coins (cherries) would give you a 1-up.

- And if I do that, how would you get the star?

- Also, would the new coins be allowed to be used for the bonus chance game?  Or would they be seperate from the coins you collect from the ground?

- Or do I decide to let the 7 coins still give you a star, not make them count towards the bonus chance, and simply have beween 10-20 of them give you a 1up?

I don't know how DahrkDaiz did this back then (I don't even remember playing it to be honest with you), but if I'm going to re-create it, I could use some feedback on how it should be.

Also, do you guys mind if I tag this hack with a title (adding text, my name, and year on the titlescreen), or do you prefer this to just be a simple patch that does a simple conversion, so you can use this as a base for your hacks?

I need your feedback.  And the higher the quantity of people that want this hack, makes it more feasable for me to do.  If only one or two people want this hack, I'd rather not waste my time, since I have other projects to do, and my time is limited as it is.

Your thoughts?


Finally, a SaveRAM hack for a game that desperately needed it!  One of the hardest NES games finally has a Save Feature!  Whenever you complete an area, the game will automatically save everything for you--your health, continues, the area, the score, special weapons and their quantities, etc.


Whenever you want to continue a previous game, just hold the A button when you press start on the titlescreen, and the game will load the beginning of the area you made it up to.

Download (Version 1.1)

Have fun! :)

If you happen to find any bugs, please let me know.

I think I might have a hard time putting this in words, but I'll try.  I want to be able to put in my pointer, the address of data that I want to be read.  But I'm using an assembler for my code.  So naturally, you wouldn't know the exact address of your code until it was assembled.  So, I want to change the table so that it reads the location of my data instead of the address.

For instance:

Code: [Select]
table: $C0, $40, $D1, $50

lda #<table
sta pointer
lda #>table
sta pointer + 1

$C040    (Data1)

Data to be read here at $C040

$D150    (Data2)

Data to be read here are $D150

So instead of that, I want it to be:

Code: [Select]
table: Data1, Data2

lda #<table
sta pointer
lda #>table
sta pointer + 1


Data to be read here


Data to be read here

I just don't know if I'm doing the table line right.  I don't care about the address obviously, since I just want the data that is located at the label.  I want to read the address AT the label, without actually reading the address itself, since obviously the address changes the more you program and add things.

I hope that made sense.


ROM Hacking Discussion / NES Development Problems, with NMI
« on: August 14, 2016, 03:19:06 am »
I'm programming a ROM from scratch, and everything has been going pretty smooth.  As soon as I enabled NMIs, that is when the problems started.

When I enabled NMIs with $2000, all of my PPU tile writing routines became garbage.  The screens become messed up.  And when I call my controller write routine from the NMI, my game freezes on the titlescreen when I press one of the controller keys.

And a question -- I know how to wait for vblank, by LDA $2002, followed by a BPL back to the LDA $2002, but why do some games, like Megaman for instance, have simply a LDA $2002, and then LDA some other address immediately afterwards?  What is the point to LDA $2002 if you're not going to BPL right afterwards?  What does LDA $2002 do on its own?

Here is some code from my ROM:

The routine to draw my startup text.  Worked perfectly fine until I enabled NMI.
Code: [Select]

jsr wait_for_vblank
ldy #$00
lda #<startuptext
sta pointer
lda #>startuptext
sta pointer + 1

lda #$21
sta draw_coordinate1
lda #$62
sta draw_coordinate2
jsr draw_handler

Here is what is in my NMI:

Code: [Select]

inc frame_counter
jsr write_joypads
jsr write_spriteRAM
jsr prg_bankswitch
jsr chr_bankswitch

The reason I'm using the NMI is because I need all of the things that are in the NMI, to be checked constantly.  And all commercial NES games have a frame counter, which from what I've seen, is incremented in the NMI.

I had 6 rows of text written to the startup screen, only for when I enabled NMIs, I could only at best get 2 lines to show up without a problem, and sometimes 3 lines being a repeat of the first line.  Otherwise, displaying all 6 rows of ppu tiles makes the screen messed up.  And even when I clear the screen, the NMI makes it so that it doesn't even work.

I tried disabling NMI, right before I write my ppu tiles, and then enabling them again right afterwards, but that created problems also.  For instance, after drawing the titlescreen, and enabling the NMI again, the whole screen went blank, and my game crashed.

So, how do I have the stuff in my NMI run constantly without running into problems, and how do I write my graphics?  If I disable the NMI, I can write my graphics, but then I don't have a frame counter.

I tried having the NMI use the draw handler, but I ran into problems with that too.

What are the answers to this problem?

Thanks for any help you can give.

Here is some code to illustrate what I'm talking about.

Code: [Select]
; Code to be assembled with ASM6
; This is a routine which will handle all of my text writing.


jsr wait_for_vblank

lda text_coordinate1
sta $2006

lda text_coordinate2
sta $2006

ldx #$00
- lda __, x   ; this line is what I need help with.
cmp #$ff      ; ff is a line terminator.  When ff is reached, the text line is finished.
beq +
sta $2007
jmp -
+ rts

db $00,$16,$0e,$10,$0a,$16,$0a,$17,$00,$12,$1c,$00,$0a,$00,$0c,$18,$19,$22,$1b,$12,$10,$11,$1d,$00,$18,$0f,$00,$00,$00,$ff

db $0c,$0a,$19,$0c,$18,$16,$24,$00,$1d,$11,$12,$1c,$00,$12,$1c,$00,$0a,$00,$17,$18,$17,$25,$19,$1b,$18,$0f,$12,$1d,$00,$ff

Is there a way I can make the LDA __,X above have an address that changes, so it will read a given line when I set it to it?

The only thing I can think of are the LDA Indirect opcodes, but I researched them, and I wasn't sure if they would do the trick.  I know that I can read a value that is stored in an address, and get output that way, but I was just wondering if it is possible to change the table address that is read by the LDA, so I can use this routine for any line of text?

For instance, if I have:

LDA text_line1, x

Later on, I want to change that text_line1 to text_line2.  Can that be done using the indirect LDA?


I was just curious.  I gave up computer work completely, not just ROM hacking, but any kind of programming, game development, and design.  I got really bad eye-strain, but it is more than that.

I believe, although I can't say for certain, that the computer can actually mess up your brain.  No joke.  I "feel" differently as a result of my strong focus on the computer.  And I have heard that the computer can mess you up quite a bit.

It just drives me nuts that I have to give up stuff that I enjoy, but my health is more important to me.

I'm going to see an eye doctor next week, and maybe I'll see a neurologist.

Mind you that when I was hacking, I also used a screen filter, which stops the glare, and protects your privacy.

So, how many hours a day do you hack?  And if so, how many in one sitting?

All I ask is that you guys be careful, and take care of yourselves.  It is so easy to sit there for hours and just hack and program.  I'd say no more than an hour or two at time, every 4-6 hours.

I'm retired from computer work for health reasons, but I still have a strong interest in this stuff (ROM hacking and game development).  If I can provide any useful ideas, I will.

First Idea

One of my ideas was based on the fact that people want to make ROM hacking easier.  And having done my share of ASM hacking for the NES, I can tell you right now that one way to make NES hacking easier is by making a better debugger.

I propose a new version of FCEUX.  Version 2.2.3.

This version will show every single offset in the debugger, hence, showing every single line of code of the game, so that you may look at and edit ANY point of the game at ANY time, without having to wait for a particular bank to be swapped in, and cutting down on the workload.

Those dots in the debugger are just meant to symbolize the offsets in-between the other offsets shown (they're etc.'s)  They're not really going to be there in the actual debugger.

Every offset and line of code are shown, but obviously if they are not loaded into the NES' banks, they don't show an address, because they can't.  Instead, it simply says "Not Loaded".  I didn't show the header offsets and RAM addresses, but they'd be there too, and even the CHR-ROM offsets if the game has it.

(Click on the image to magnify it)

This is but one way to make NES hacking faster and easier.

So, what do you think?  Yay or Nay?

My second idea

An new mapper - an expansion of MMC5.  This will allow the NES to have 2 more rows of palettes to choose from, one for the backgrounds and one for the sprites.  I noticed that when you write to the palette addresses, they get mirrored into the other addresses ($3F21 and onward).  Couldn't we, in theory, simply make those extra palettes to choose from?

And if this new mapper was implemented, we'd need an update for FCEUX to show the new palette rows in the PPU Viewer.

Like so:

(Quickly put-together rough design - click to magnify)

Also, while we're at it, we could update the PPU Viewer to show another pattern table, if the mapper is MMC5, since in 8x16 sprite mode of MMC5, both sides can be used for sprites, and the third one would be for backgrounds.

So, what do you guys think?

ROM Hacking Discussion / Two hack releases, and some story
« on: April 04, 2016, 02:12:16 pm »
I wanted to have my Zelda hack released on April 1st, but unfortunately that didn't happen, because I came down with a really bad eye-strain.  I have decided to get away from computer work altogether, because even though I love ROM hacking and everything game design, I care more about my health.

Unfortunately, Teenage Mutant Ninja Turtles: Cowabunga Edition (SaveRAM hack) will not be released.  It is 55% complete, but it is still incomplete, and the save functionality still wasn't implemented yet.

However, I am releasing the mapper conversion patch for TMNT, which I planned on releasing AFTER my SaveRAM hack got released, and I am releasing (even though it is incomplete) my Zelda hack which I got inspired to do over a week ago.

Zelda 3D

Please read the readme, before playing.  Zelda 3D was inspired by the 3D effect used in Rad Racer.  I wanted to implement it in LOZ, and call it Zelda 3D.  Yeah, it was gimmicky, but I thought it was cool.  Just incase you are wondering, I did not get the eye-strain from the 3D effect, but from the many hours of focusing on the hack.  I spent sometimes 6 hours straight on the project, because I wanted to get it done as fast as I could.

The select button toggles the unfinished (it's not even real 3D) 3D effect.


And here is the TMNT MMC5 patch.

It is complete with documentation, even how to show you how to convert it manually if you wish.


So yeah, this is most likely the end for my computer projects.  I hope you enjoyed my work.


ROM Hacking Discussion / Coming Soon... Hopefully April 18th
« on: March 19, 2016, 12:31:58 pm »
My next SaveRAM hack, the one I hinted at 3 weeks ago on board2 (, is Teenage Mutant Ninja Turtles: Cowabunga Edition.

Most of the work that has went into this hack thus far, has been mostly prep work.  The TMNT ROM is a real pain in the ass to work with --> bad enough that the actual game itself is a pain in the ass because of its difficulty. :laugh:

But yes, a SaveRAM hack for a game that I felt really needed it badly.

Once this has been released, I'm seriously considering doing a SaveRAM hack of Megaman 3, before getting back to my Super Mario Bros. 2 Two-player hack.

Have fun guys! :)

Bearing in mind, we're talking about the NES here.

Let's say I switch to bank 05, and I jump to $8000.

Then, at $8000, I have this code:

JMP $8000

This produces an infinite loop.

Apparently, with the Teenage Mutant Ninja Turtles ROM, having observed the code in the trace logger (from what I could observe, as the trace logger doesn't log "skipped" lines), it executes that JMP $8000, but then continues to carry on other game code.

In other words, my JMP $8000 is not producing the infinite loop that I want (I want it for testing purposes).

I remember seeing in the Super Mario Bros. disassembly that there is an Infinite Loop in the code.  The loop seems to be infinite, and yet all of the other code of the game is executed.

The only thing that could cause these things to happen in both Teenage Mutant Ninja Turtles and Super Mario Bros. are Interrupts correct?

And if not in the case of TMNT, what is causing my Infinite Loop to simply be executed once and then bypassed?  When tested with other ROMs, such as Super Mario Bros. 2 (USA) for instance, when I switch a bank and then execute an infinite loop (to make sure the proper bank is loaded), it executes the infinite loop, and doesn't bypass it, which is what I want.

In TMNT, in the hardwired bank ($C000 - $FFFF), I load a random bank in, from 0 to 6 for instance, and then jump to the beginning of that bank ($8000), and then execute an infinite loop at that point (JMP $8000), and yet it is executing that instruction, and then bypassing it.  Logically, it should not be doing that.  Unless of course logically speaking I'm not taking into consideration that there is some other factor that is causing that, such as Interrupts.

The way TMNT handles things is very different from the way other ROMs do things, as I'm observing first-hand.

Having done a lot of testing, it seems that the bank switching that I thought wasn't happening, actually does happen, but is then bypassed, which gives the illusion that the bankswitch never happened, because the switching happens so fast.  But the fact that bank switching happens regardless of an infinite loop puzzles me.

So, if all of this is indeed because of interrupts, how do I go about using that to my advantage?  In other words, how do I get the game to not bypass my infinite loop, for instance?

This is very important to me in figuring out why some ROMs work the way they do, and would help me greatly in my current project that is on ice because of this dilemma.  I have to switch to a bank that has free space, and KEEP that bank there until my code is done being executed, and then any other switching can happen.

Thank you for reading and for any information you could provide.

If you go and try to switch a bank in, let's say for example:

; Put bank 06 into $8000 - $BFFF
LDA #$06

And then immediately jump to that bank, it creates problems.  It loads a different bank instead.  And this happens regardless of the mapper you are using, and regardless if you expand the ROM or not.

I can replace the beginning of a switchable bank with JMP $8000 (simply loop at $8000 constantly for testing purposes) and jump to that $8000 right after loading that bank in, and it won't take me there.  It will load a different bank, crash the ROM, and move the Program Counter elsewhere.

I never had this problem with any of the ROMs I have hacked in the past.  I did notice that the ROM has a lot of RTIs and things of that nature.  Maybe the ROM runs in a different manner?

Just thought I'd bring it up incase anyone wants to hack this game.  It really is a hard game to hack because of the lack of free space, and the problems with the bankswitching.

What could be the problem?

Pages: [1] 2 3