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.

Messages - pimpinelephant

Pages: [1] 2 3 4 5 6 ... 10
RPG Maker 2, and yes, SROM Tool says it's 64kB SRAM, but as I said, I have no idea what to do. :/

Hmm, RPG Tsukuru 2 also appears to be a Satellaview game as well.
I can go ahead and take a look at it in the future.
See if I'm knowledgeable enough to even fix it.

For now though, I'm going to try and solve Ganbare! Daiku no Gen-san, so apologies for the wait.

Does anybody know what the issue with RPG Maker is? I got it to run smoothly with some help on the SNES9x core, but if I try on Canoe, all I get is a black Loading... screen; only when I press RESET does it give me a C7 error. I'm a newbie, so I've no idea what to do.

Which RPG Maker, Super Dante or 2?

I haven't tested myself but from a quick look, RPG Maker 2 is 64kb SRAM! :o
Canoe doesn't like that.

I remember Sluffy worked around it for a couple of games that also used 64kb SRAM.
I think he consolidated the data into a smaller SRAM size if I'm not mistaken.

Either way, my hands are currently full with Ganbare! Daiku no Gen-san at the moment.
This game is proving to be a real pain...

The big issue is that I can't trace log Canoe like I can with PC emulators. :(
So I'm literally just guessing, like trying to look for a needle in a haystack.

I'll keep trying though, since I know WHERE the issue is occurring... Just not WHY it's occurring. >:(

A little update for Ganbare! Daiku no Gen-san.

Progress is being made!

I've been able to pinpoint what exactly is causing the game to get stuck after the IREM logo.
It's an APU timing issue, which Sluffy already knew and tried to fix with previous patches.
But it's not like ActRaiser 2, where switching to slowROM fixed it.
This is the part that I'm going to need to figure out. Ugh!

I removed the timing check in the APU uploader so that the game only uploads once and moves on.
This prevents the hold-up after IREM logo and the game itself plays perfectly fine, but distorts the sound, obviously.
I don't know too much about how the APU works though, so I will have to do some research.

Thanks, I assume you mean this post?

I've made a lot of individual threads and posts over the years, here are some of them:

This is some amazing stuff!

I'm particularly enjoying the warning messages.
Loving those risqué images. ;) Talking about Ai Chou Aniki of course.


Just... Amazing.

Personal Projects / Re: Chrono Trigger Bugfix and Uncensoring Patch
« on: June 07, 2018, 02:43:12 pm »
ctfix_1a (update6)

Two whole bytes! :P

Always happy to help! :)

Ah got it, didn't know sluffy had increased the size.

So the top racer patch has the same fixes as the top gear patch?  Because as far as I can remember, he only worked on the Top Gear one and never really updated the Top Racer one with those fixes.

Yeah, he was only able to finish work on Top Gear.

I just applied the same changes onto Top Racer.
They are extremely similar games with only slight differences between the ROMs.

So I just had to slightly edit the fixes to properly point to the correct spot on the Top Racer ROM.

pimpinelephant can you post the Top Racer patch you made that fixes the issues, but that does not include the thing about reducing the rom size? Peronsally I want to leave games with their default official size and just apply the fixes.

Oh, the 3b patches are the correct sized ROMs.
Official = 512 KB
Sluffy = 1 MB

I'm extremely confident that Sluffy only did that to quickly test it and planned to move it back into original 512 KB, before he had to quit all of this.
Especially since the internal ROM size was still listed as 512 KB with Sluffy's patch.

I just moved the tiny bit of code from the added-on 512 KB space into the original 512 KB space.

Wait a second, don't you have a SNESC? You can fix and test yourself :P

Or do you just want people to double check?

Oh no! They're onto me! :laugh:

Yeah, I really should do the testing myself, but... well... I'm lazy! :P
But yeah, I do some testing myself, but it really starts to become tiring going back/forth from the TV to the PC.
Especially with the amount of attempts I try for each fix.

I've realized that certain PC emulators are very close to Canoe.
So the majority of my testing actually happens right on the PC.

But yeah, you're right. :laugh:
I really should test these things myself, so I apologize for forcing that upon you guys. :P

For me the game now works fine, no blue lines at top or bottom, no black ocean or no zooming slowdowns. :thumbsup:
Maybe some one more familiariced with this game than me can test it better, i have recorded a video to show:

Woohoo! :woot!:
ActRaiser 2 is officially 100% fixed! :crazy:

Thank you SupaSAIAN!



While changing the backdrop color, I realized something.
The ocean tiles are, well, gone. They are never displayed.
This was one of Sluffy's fixes.
It made the ocean color a single uniform color (backdrop), instead of ever-so-slightly different when the ocean tiles stop and becomes the backdrop color.
This was also required since Canoe completely and utterly fails to properly emulate $211A's fill-outside-space-with-tile $00.

I tried turning the backdrop color black during the world map view, but since ocean tiles aren't included in VRAM, it just displayed the black backdrop for the ocean.
So backdrop editing is a no-go.

BUT! There was still one option left to go.
HDMA! Damn, this thing is amazing!
HDMA = Allows editing of PPU registers on each SCANLINE! That's right, each scanline!
This is how ActRaiser 2 accomplishes a mode 7 layer in mode 1 ($2105).
Anyways, luckily for us, ActRaiser 2 only uses 7 of the 8 available DMA channels during the world map view.
That leaves us one left over for us to use.

Created an HDMA routine that forces brightness to 0, or black, ($2100 bits 2-0) for the first scanline as well as the 224th scanline.
All other scanlines display full brightness.
BUT! We need to specify to enable this HDMA only during the world map view.
Simple solution, create a comparison check to verify which screen we are looking at.

Compare the current value of $212C (enables/disables main screen layers) to the value it contains when displaying the world map.
If true, enable channel 8 HDMA. If false, disable channel 8 HDMA.

And viola! No more backdrop color seeping through the top and bottom scanlines when on the world map view!

Personal Projects / Re: Chrono Trigger Bugfix and Uncensoring Patch
« on: June 06, 2018, 10:57:30 am »
Apologies for the long delay!

ctfix_1a (update5)

Hopefully I got everything. :)

ActRaiser 2 (USA)

Things to look for:
- Top/bottom lines on world map.
- If everything else is working correctly as well.

If this works, I'll explain why in my next comment.
Hoping it works! :)

This patch changes the ocean color to black (, this is how it looks the same screen with previous patch act2_1a.ips (

Noooo!!!!!!! :laugh:

I think I already know what the issue is, let me try again.

Thanks for all of the testing SupaSAIAN, I promise I will get to Ganbare... eventually! :laugh:

ActRaiser 2 (USA)
act2_2 (1a + top/bottom lines)

Things to look for:
- Top and bottom lines when on world map.
- Anything else.

AAAHHHH!!!!! :banghead:
Please, for goodness sake, PLEASE tell me this works! :laugh:
So... Many... Attempts... Hopefully this is the one!

Again, I apologize SupaSAIAN! :laugh:
I will start testing on Ganbare! Daiku no Gen-san.


Top and bottom lines are real hardware.
Side effect of how they did the world map.
World map = mode 1 with mode 7 layer on BG1. WTF???

This mode 7 layer can't fill the very top and bottom scanlines.
So BG1 appears for those lines instead.

But BG1 is nothing because it just uses the mode 7 layer.
This means BG1 = transparent.
Which means that backdrop appears instead.

Removing BG1 removes mode 7 layer as well, so can't touch BG1.
Backdrop needs to be ocean blue for Sanctuary view.

BUT! Backdrop doesn't need to be ocean blue when on world map!

When on world map, change backdrop color to black.
When on Sanctuary, change backdrop color back to ocean blue.


0x200 bytes beginning from $7F:0700 in WRAM is written to CGRAM.
CGRAM = 0x200 bytes.
Backdrop character data is located at $00 and $01 in CGRAM.
Change $7F:0701 in WRAM to 0x00.
$7F:0700 is already 0x00.
0x0000 = Black.
Revert changes when in Sanctuary view.

Alright, I did a couple of tests with ActRaiser 2.
It appears that the top and bottom lines also occur on real hardware, or at least on Higan.
So probably real hardware?

It's just that the backdrop color is darker on vanilla so it's harder to see, but it's definitely still there.


Vanilla backdrop color:

Patch backdrop color:

Probably the reason why Sluffy never dealt with them?


Register $211A controls some mode 7 settings.
It's set to fill outside extra space with tile $00, which is the tile for the ocean on the world map.

For some reason, Canoe doesn't do this.
It just fills with transparency, thus the backdrop appearing in the outside extra space.

Sluffy's fix was to change the color of the backdrop to the same color as the ocean.
This caused the top and bottom lines to become brighter (ocean blue vs dark blue).

I can think of some ways to "bugfix" it, but I am definitely not good enough to actually be able to accomplish it, unfortunately.
Maybe in the future someday? :P

Can you make an all in one patch for Act 2 or is you patch already an AIO?

And the top/bottom line issue is still present, correct? Any chance you could fix that too?

Yup! The act2_1a patch is all-in-one, Sluffy's latest act2-0c patch as well as my fastROM fix.
I think Bosco82 made a patch that also included the slowROM fix (which was needed at the time), this act2_1a patch doesn't contain that.
It's got fastROM enabled from the start. :)

And double yes! The top and bottom lines are still there.
I did a very quick test, the top/bottom lines appear to be caused by Sluffy's patch.

I'll take a look and see if I'm able to do anything about it.
Try not to get your hopes up though! :P
Sluffy was way, way, way more smarter than me. :laugh:

Yeah, that looks fine to me! :)

You can see the slowROM/fastROM difference during the world map transitions by comparing Arkiokin's video:

Your video appears to show correct fastROM speeds!
Woohoo! :woot!:

Let's see if I can figure out Ganbare! Daiku no Gen-san now. ;)

LOL! I am SOOO dumb! :laugh:
I looked over ActRaiser 2 again... I made a dumb mistake in my code... which was breaking ActRaiser 2. :banghead:
I told you I'm really bad at ROM hacking! :laugh:

ActRaiser 2 (USA)
act2_1a (Sluffy's act2-0c + FastROM)

Things to look for:
- Transition speed on world map.
- Anything else. :P

Now for some Ganbare! Daiku no Gen-san testing! :)

ActRaiser 2 (USA)
act2_1 (Sluffy's act2-0c + FastROM)

- Should fix all slowROM related issues. But...
- Needs confirmation that it's actually running in fastROM, I don't really know the exact differences to compare. :-[
- Top and bottom line issues are from act2-0c patch.

I'm not sure if anybody remembers, but Sluffy made a brief attempt at circumventing the slowROM check, unfortunately it didn't work.
BUT! He figured that it was due to APU timings. And he was absolutely on the right track!
This was proven when I completely stopped communication between APU and CPU (shut off sound).
The game loaded and played perfectly fine in fastROM with no black screens, albeit with no sound. :laugh:

I know little about ROM hacking, and even less about the APU. But I believe the APU uses an uploader that is very timing specific if I'm not mistaken.
Anyways, long story short, APU timings = slowROM check for ActRaiser 2. :P

Like I said, I'm not very good at ANY of this, so I tried to think of a work-around for this issue.
I spent DAYS trying all sorts of different things, until I thought of something a bit different (and much more simple).
What I did was turn OFF fastROM right before APU communication, and then turn fastROM back ON right after APU communication completes.
To my surprise, it actually worked in Canoe! :o

Now, I don't really know the exact differences between ActRaiser 2 in fastROM compared to slowROM, so testing is required to confirm all of this.
Although, PC emulators state that the exact same ROM is running in fastROM (3.58 MHz) so it should be doing the same in Canoe.

And my apologies SupaSAIAN, I've been spending most of my free time working on ActRaiser 2, so I've only done a couple of tests so far with Ganbare! Daiku no Gen-san.
But I'll start spending some more time with that game now. :)


After a bit more testing, looks like that "work-around" is a no-go at the moment. Back to the drawing board I guess. :'(

I'll forget about ActRaiser 2 for now though, and start doing some testing on Ganbare! Daiku no Gen-san.

Looks like the Snes9x issue has already been fixed in the latest commits on GitHub.

Sorry to ask this here, but how do I apply the bps patches?

I tried with beat and I get an error, and I tried with floating ips and I get this message: "This patch is not intended for this ROM."

I am trying to apply the Dragon Quest III and Tales of Phantasia patches.

I just tested both patches myself, and both of them worked correctly.

DQIII - No header + v1.1 translation
ToP - Yes header + v1.2 translation, TOP_DX2L

For .bps patches, it will ignore the header altogether if one is present, so no need to worry about headers with .bps patches.
One of the reasons why I prefer .bps over .ips, not to mention that .bps won't run into legal issues like a .ips can sometimes do. ;)

Alright, I took a look at ActRaiser 2 to see if I could somehow get around the slowROM check and force it to run in fastROM.

I disabled fastROM on boot-up (current canoe fix), but then turned fastROM back on after it finishes the Enix logo screen.
Nope... I was dumb to think the game only does its slowROM check once.
It would get to the menu screen, but there was zero sound and then black screen after choosing New Game. (slowROM check failed)

I'm thinking the game does its slowROM check on every NMI, but I'm not sure on anything yet.
I'll definitely keep looking into this.

Pimpinelephant could you take a look to Gambare Daiku No Gen-San??
I really want to finish that game but I can't deal with Retroarch's input-lag.  :banghead:

I can definitely try, but I'm not very good at this kind of stuff. :laugh:

I know that Sluffy tried working on Ganbare! Daiku no Gen-san for a little bit, but wasn't able to figure out the cause.
The issue with simple black screens is that the cause could be anything.
Will have to look around trace logs and see if it does anything different after Irem logo.

Personal Projects / Re: Chrono Trigger Bugfix and Uncensoring Patch
« on: May 29, 2018, 07:45:24 pm »
ctfix_1a (update4)

I also just wanted to mention that the Preset ID is incorrect in the ReadMe.
It currently says
I have been told that Preset ID 100B + 03 is the way you want to get this to work natively.

It should be 110B instead of 100B.

Not a big deal at all, but just wanted to mention it just in case anybody got confused. :)

I don't think so. I think they should be fine.
Nothing was actually changed, so everything should still be working the exact same as the 3a patches. :)

Pages: [1] 2 3 4 5 6 ... 10