Kagemusha
Guest
|
 |
« on: December 26, 2010, 09:26:20 pm » |
|
I'm venturing into new territory here and was hoping I get some direction. I have a hard-wired bank with some unused space for code and text that I'm going to move elsewhere spread throughout the 16K bank. Now what I'd like to do is dump the code from that particular section and shuffle things around and put it back into the ROM. What exactly would I be looking for?
|
|
|
|
|
RedComet
Guest
|
|
« Reply #1 on: December 27, 2010, 01:54:59 am » |
|
You're gonna have to be more specific. Do you want to move *all* of the code in that bank around or what? You're gonna have to track down all the code in the other banks that call the code being moved and fix them if you do move the code.
|
|
|
|
|
Kagemusha
Guest
|
|
« Reply #2 on: December 27, 2010, 02:38:03 am » |
|
Yeah, pretty much all the code in the bank. What I want is for there to be an accumulation of free space at the end of the bank. That will give me the space I need for new code so I won't have to put a bunch of JMP's in my routines.
|
|
|
|
|
rmco2003
Guest
|
|
« Reply #3 on: December 27, 2010, 03:54:39 am » |
|
Won't you run into the issue of the ips no longer being legal since if you move things around it'll include them in the patch file?
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #4 on: December 27, 2010, 04:12:08 am » |
|
He could use an xdelta patch. >_>
|
|
|
|
|
rmco2003
Guest
|
|
« Reply #5 on: December 27, 2010, 04:47:18 am » |
|
Ah I didn't realise xdelta supported relocation
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #6 on: December 27, 2010, 04:50:23 am » |
|
I'm pretty sure it does. It was recommended to me for making DS patches, which will need relocation if you change file sizes.
|
|
|
|
|
I.S.T.
Guest
|
|
« Reply #7 on: December 27, 2010, 05:12:27 am » |
|
Won't you run into the issue of the ips no longer being legal since if you move things around it'll include them in the patch file?
To be fair, no translation patch ever is legal unless it was for a game whose license allowed for such things. |
|
|
|
|
Gil Galad
Guest
|
|
« Reply #8 on: December 28, 2010, 01:19:12 pm » |
|
Relocating code can be difficult and tedious, especially when you want to shuffle the contents of an entire bank around. Which is why I usually only move small chunks of code around and adjusting entry points as needed.
I have a personally modified version of NESrev where I can disassemble various size of banks from 8KB - 32KB. What I do is carefully block off any references to other banks and then disassemble. Each piece of code will have a label based on it's address. L8000 ($8000), for example. I then convert it to assemble with ASM6 and then assemble. You'll have to make many other edits to make the code relocatable. After I am done, I restore those references to other banks by usually inputting a regular address. You also have to adjust many other places in the code so that everything lines up right.
It's usually not worth the effort to move everything around in this way. I'd recommend expanding the ROM and moving any data you need more space for there.
|
|
|
|
|
Kagemusha
Guest
|
|
« Reply #9 on: December 28, 2010, 02:27:03 pm » |
|
I know it seems a bit impractical, but I don't think expansion is the answer. The obstacle that I have to overcome is that the main text block and pointers take up about 90-95% of the 16K bank. With DTE I've inserted around 90% and I have my DTE table in the same bank as the text. I need to increase the compression, but I need some room for the code and tables.
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #10 on: December 28, 2010, 02:54:26 pm » |
|
The space savings you'd get from moving to dictionary on the text should exceed the space needed for implementation by quite a bit. It's only a handful of extra code lines to move to dictionary from DTE. The only other thing you need is the table, but each entry of the table takes up the same space (plus string end) as one occurrence in text. The idea would be it would replace many occurrences in text, so you should have significant net space savings. Your proposed solution does not seem practical or necessary to me.
|
|
|
|
|
Gil Galad
Guest
|
|
« Reply #11 on: December 28, 2010, 03:08:45 pm » |
|
If you have to, I'd put the extra code and the table in the same bank as well. With DTE you'll only get about 33% savings, and dictionary maybe about 40%. Both combined will get you close to 50% which is about the best you'll get with encoded type compressions. Some will argue that DTE and MTE is not compression at all, even though they save a great deal of space and use tables like other advanced compression schemes do. In Dracula II, I'm using sub-string, dictionary and DTE for example.
But yeah, I am all too familiar with no space in the hardwired bank. You'll just have to get creative in dealing with it.
|
|
|
|
|
RedComet
Guest
|
|
« Reply #12 on: December 28, 2010, 03:31:13 pm » |
|
You could always use free space in another bank. I did that with DBZ Gaiden. I implemented extra dictionary compression and stored the table in a separate bank from the hardwired one. It worked out really well.
|
|
|
|
|
Kagemusha
Guest
|
|
« Reply #13 on: December 29, 2010, 03:54:42 pm » |
|
Perhaps I wrong in my approach. I did some hypothetical tests with Scriptcrunch and Atlas which ended up failing in fitting the script in. It appears DTE plus dictionary isn't enough. I'm thinking of either trying Huffman or moving the script overflow to another bank.
So after a few hours of work, I think might've fully-hacked the game. I ended up caving in and expanded the ROM, which was the easy part. The hard or at least tricky part was figuring out how to split the text banks. It took me a while to figure out that I had the wrong approach and now I think I got it working perfectly.
|
|
|
|
« Last Edit: December 31, 2010, 02:33:51 am by Pennywise »
|
|
|
|
RHDN Forum Archive
Author