Printable View
I made a ROM hack of Sonic 1 for the Genesis which I suspect fits within 6 megabits but the ROM padder only pads to 4 or 8 megabits, and won't pad to 6. Any idea how I could remedy this problem and pad it to 6? I know for a fact that there were some 6 megabit cartridges for the Genny so it's gotta be possible somehow
That's odd...What sort of things did you do to the hack? Sometimes re-formating the PCM "SEGA" voice can cut down a lot of space. Did you use SonED 2 for any of this or did you do most of it by hand? Also what would be the problem with adding "junk" to the end of the ROM to make it 8 megabits? I know it's not the most efficient way but I can't see how it would overly hurt it unless you were trying to burn it to an eprom on a pre-made cart.
If it were me, I'd just remove 256 kilobytes of the padding from the end of the compiled ROM manually in a hex editor.
I do question why you want it to be 6 megabits though, unless you're planning on burning this into exactly 768kb of ROM chips or something.
Most rom hacks simply get distributed as ... well ROM files. :p A few people probably play them via flash carts, but even thenm padding to 8Mb (1MB) should be fine. (and even someone using PROMs/EPROMs -cheaper for someone with a rudimentary homebrew socketed cart board- should be fine unless they want to deal with 3x 256 kB chips for some reason)
I used the ROM disassembly of Sonic 1 and applied several bugfixes from SonicRetro's wiki. Namely, I implemented the following:
Fixed the Spike Bug
Fixed the Hidden Points Bug
Fixed the Walk-Jump Bug
Restored the "Press Start Button" prompt on the title screen
Corrected the Level Order in the Level Select Menu
Removed the Speed Cap
Ported the REV 01 background effects
and last but not least, I fixed the SEGA sound.
I think it's that second-to-last one that pushed the ROM size above the 4 megabit size of the original Sonic 1 ROM. As for why I want to trim off the final padded 256K (unless this ROM turns out to actually be over 6 Megabits) is that I have OCD about wasted space. And wouldn't just manually clipping out the padding with a hex editor break the checksum test?
Man...The only thing I can even see that might save a little space is by making the zones have one deform method instead of the cascade they have going ex. Deform GHZ 0-9
But that would only work if there are no other dependencies on the individual deform calls. When Sonic looks up and down it may call one section of it, I haven't analyzed the assembly too much. At first glance combining those may save you a little bit of space...but even so it probably wouldn't be significant enough to make a difference. Actually now that I look at it, it's not an exactly linear cascade through the subroutines so that might not even work.
As for the checksum It probably would break it, of course if you ran a checksum fixer it'd probably just re-pad the rom right back again. I may look into the disassembly some more later as this has me interested now!
I would not want to hear anything about padding ROMs... I manually unpad them so I'd have to wait less for them to burn to my cart...
If I sent you my hacked Sonic 1 ROM, TmEE, could you unpad it for me?
I could.
Quote:
Originally Posted by StevieC
Wow, all that and you still missed the most important glitch of all.
However, it bears mentioning that the sonic ROM hacking community is still working on figuring out HOW to fix that one, as far as I've heard.
No, that one has been fixed over a year ago.
There should be a guide somewhere, I do recall performing it a while back.
That's a fault with the original game, right, not just with the speed cap removed? (is it green hill only, a speficic part of the level only, or the whole game) I seem to remember this happening to me and being baffled.Quote:
Originally Posted by Flygon
It only happens with that particular S-curve, it's caused by the fact that the game takes you below what would ordinarily be the bottom of the level at that point. It uses a scripted vertical scroll to deal with this. However, it's possible to travel faster than the screen is scrolling and reach its bottom edge, which causes you to die just the same as if you'd fallen into a bottomless pit.Quote:
Originally Posted by kool kitty89
I wrote a small utility for binary insertion. It wasn't specifically meant to pad a file, but if you give it an offset that's beyond the size of a file - it will pad up until that point to where it adds that file in. I do this for ISO files I'm working on. I inject a file that's 1 byte long to an offset I need to pad the source file to the correct size. I can give you the util if you want (though I've sure there are a hundred of these type of utils already out there). Curious though, why would you want to cut the file size instead of just padding it? TmEE has a special case scenario, but you? Almost everybody else just expands to the next segmented size. That's one thing that pisses me off with SNASM68k. Normally with an assembler, you just define an ORG address and single byte or word define (at the end of your main source file). But on snasm68k, this doesn't do anything.
Some of the spike pits have a problem kind of liek that too, if you fall/jump into them near full speed and fall towards the far edge, it acts liek a bottomless pit rather than a spike pit. (you die rather than getting pricked)Quote:
Originally Posted by roundwars
another thing that always bothered me about those spike pits is when you bounce off them from being hit the first time you can land back on them again and die and you have no control over it :(
That's one of the things that I fixed in my hack.Quote:
Originally Posted by Defolto
I don't think I've ever heard of a glitch like that, though there is one area in Green Hill Zone Act 2 that comes to mind. It has spikes alternating with bottomless pits, and it's very easy to hit the bottom of the screen in that area without realizing it. Does that sound like it could be what's going on?Quote:
Originally Posted by kool kitty89
Probably. ;)Quote:
Originally Posted by roundwars