ALTTP Fastrom
Zeldix :: Zelda III Hacking :: Patches :: Others
Page 1 of 1
20150221
ALTTP Fastrom
Author: Wiiqwertyuiop
Information: this patch makes ALTTP run in fastrom mode, this should prevent slowdowns, which are encountered in case too many sprites are on screen
Rom: expanded (min 1.5 MB) NATIVE ALTTP (US), without Header
Note!
This is the native code by wiiqwertyuiop for the native expanded rom. The all-in rom as well as the complete items patch already have the code adjusted and merged. Only apply this patch in case you play the native rom, but NOT if you use the all-in or the complete items code (they are already merged with the fastrom code, thus your rom will automatically be in fastrom mode when applying one of these patches).
Ips Patch and ASM file: http://bszelda.zeldalegends.net/stuff/Con/alttp_fastrom.zip
The fastrom_new.ips already has some bugfixes by Conn; also it does not expand the rom anymore, so that existing data beyond 1 MB get overwritten (check the readme). You find wiiq's old files in a subfolder.
Additional Information:
The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $008000 and $808000, $008001 and
$808001, $008002 and $808002 etc... all access the same locations.
When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
So all you have to do is assemble your program so that it
starts at $808000, make sure you set the programming and
data banks to $80 (K and D) and set bit 0 of $420D. You'll
also need to mask off the bank part of the run/reset vector
and vertical blank interrupt locations.
Information: this patch makes ALTTP run in fastrom mode, this should prevent slowdowns, which are encountered in case too many sprites are on screen
Rom: expanded (min 1.5 MB) NATIVE ALTTP (US), without Header
Note!
This is the native code by wiiqwertyuiop for the native expanded rom. The all-in rom as well as the complete items patch already have the code adjusted and merged. Only apply this patch in case you play the native rom, but NOT if you use the all-in or the complete items code (they are already merged with the fastrom code, thus your rom will automatically be in fastrom mode when applying one of these patches).
Ips Patch and ASM file: http://bszelda.zeldalegends.net/stuff/Con/alttp_fastrom.zip
The fastrom_new.ips already has some bugfixes by Conn; also it does not expand the rom anymore, so that existing data beyond 1 MB get overwritten (check the readme). You find wiiq's old files in a subfolder.
Additional Information:
The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $008000 and $808000, $008001 and
$808001, $008002 and $808002 etc... all access the same locations.
When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
So all you have to do is assemble your program so that it
starts at $808000, make sure you set the programming and
data banks to $80 (K and D) and set bit 0 of $420D. You'll
also need to mask off the bank part of the run/reset vector
and vertical blank interrupt locations.
Last edited by Conn on Fri 30 Oct 2015 - 22:25; edited 3 times in total
Conn
- Since : 2013-06-30
Share this post on:
ALTTP Fastrom :: Comments
Fri 30 Oct 2015 - 18:13 by Conn
I moved this incredible patch here (where the topic) fits better. Also I made a new version of the ips which doesn't expand the rom anymore and thus overwrites existing data beyond 1 MB (be sure you apply this patch on a rom with min. 1.5 MB size).
Also I merged the bugfixes I made with this patch.
EVERYBODY who is in a project, apply this hack to prevent slowdowns
If you use the all-in or the complete items patch, do not use this fastrom patch, as it is already merged with both the all-in and the complete items hack!
Last edited by Conn on Fri 30 Oct 2015 - 22:24; edited 1 time in total
Also I merged the bugfixes I made with this patch.
EVERYBODY who is in a project, apply this hack to prevent slowdowns
If you use the all-in or the complete items patch, do not use this fastrom patch, as it is already merged with both the all-in and the complete items hack!Last edited by Conn on Fri 30 Oct 2015 - 22:24; edited 1 time in total
Fri 30 Oct 2015 - 18:37 by SunGodPortal
I'm curious, wouldn't this make a game crash on real hardware? I'm assuming that these sort of restrictions are put in place to prevent the console components from being overloaded.
Fri 30 Oct 2015 - 19:00 by Founder
Myself included? Just asking because you usually send me emails when such things happens in case I forget to apply them ^_^Conn wrote:EVERYBODY who is in a project
Fri 30 Oct 2015 - 21:29 by Conn
SGP: I'm not into the speed things, but all consoles can run lorom, fastrom and hirom flawlessly. This won't help here.
SePH: No worries, your rom already is fastrom and everything is alright with your rom, do you remember this?
For all wondering: this shows the fastrom effect (don't care about the messed up sprites, look at the sheer amount...: no slowdowns at all!).
If bugs are found that affect your rom, I of course continue to send you adjusted patches for PU
btw: when do I need to fix that msu and 3 option text bug?
SePH: No worries, your rom already is fastrom and everything is alright with your rom, do you remember this?
For all wondering: this shows the fastrom effect (don't care about the messed up sprites, look at the sheer amount...: no slowdowns at all!).
If bugs are found that affect your rom, I of course continue to send you adjusted patches for PU
btw: when do I need to fix that msu and 3 option text bug?
Fri 30 Oct 2015 - 21:34 by Founder
Yes I do! Just thought it was a patch update or something... hadn't read properly!Conn wrote:Do you remember?
Fri 30 Oct 2015 - 22:23 by Conn
Yes, I made it also more clear in the original post that also the all-in and the complete items patch will enhance fastrom, so this patch must not be applied when using one of these patches.
Thu 28 Apr 2016 - 14:17 by qwertymodo
Hey Conn, I figured out the issue that I mentioned in the DX patch thread. You managed to mostly fix it, but missed one byte in the process. It's this bug from your fastrom_new notes:
This fixes the issue, but misses the cause. What's really going on there is that in JSL.asm, you have
and then in tables.asm
the address of the table is off by one, which is shifting all of the addresses over and writing over top of the high byte of the JSL address. Just change that org $0288D1 to org $0288D2, then you'll get the $80 at $0288D1 (from the JSL at $0288CE), and all of the addresses in the table will be in the right spot.
Your fix essentially did the same thing, except you missed the last byte at $0288DD, $02->$82
- Code:
bug:
pc 01/08d0:
87 3a b6 82 d9 b6 82 7a b7 82 1c b8 82
to
87 80 3a b6 82 d9 b6 82 7a b7 82 1c b8
(move the last Byte 82 in this row before 3a and Change it to 80; game crashes othewise at some places)
This fixes the issue, but misses the cause. What's really going on there is that in JSL.asm, you have
- Code:
org $0288CE : JSL $00879C|$800000
and then in tables.asm
- Code:
org $0288D1
dl $02B63A|$800000
dl $02B6D9|$800000
dl $02B77A|$800000
dl $02B81C|$800000
the address of the table is off by one, which is shifting all of the addresses over and writing over top of the high byte of the JSL address. Just change that org $0288D1 to org $0288D2, then you'll get the $80 at $0288D1 (from the JSL at $0288CE), and all of the addresses in the table will be in the right spot.
Your fix essentially did the same thing, except you missed the last byte at $0288DD, $02->$82
Thu 28 Apr 2016 - 15:08 by Conn
Your message is a bit confusing. Do I have to change anything in my patch or does it still cause a bug...
...so in short, do I have to change in my patch just
pc 01/08dd: 02->82
and all is good? Or do I need to make more like
...so in short, do I have to change in my patch just
pc 01/08dd: 02->82
and all is good? Or do I need to make more like
Just change that org $0288D1 to org $0288D2, then you'll get the $80 at $0288D1 (from the JSL at $0288CE), and all of the addresses in the table will be in the right spot.
Thu 28 Apr 2016 - 16:44 by qwertymodo
Conn wrote:...so in short, do I have to change in my patch just
pc 01/08dd: 02->82
and all is good?
Basically, yes. And even without it, you probably won't have a crash, because it just means that last address is using SlowROM ($0282B8). However, to help explain what's going on to somebody like me who wants to look at the original asm code, I would change your explanation in fastrom_new.txt
bug:
pc 01/08d0:
87 3a b6 82 d9 b6 82 7a b7 82 1c b8 82
to
87 80 3a b6 82 d9 b6 82 7a b7 82 1c b8
(move the last Byte 82 in this row before 3a and Change it to 80; game crashes othewise at some places)
To something like
bug:
Incorrect table offset in tables.asm, line 23
org $0288D1 -> org $0288D2
pc 01/08d0:
87 3a b6 82 d9 b6 82 7a b7 82 1c b8 82 02 ad 12
to
87 80 3a b6 82 d9 b6 82 7a b7 82 1c b8 82 ad 12
Just change that org $0288D1 to org $0288D2, then you'll get the $80 at $0288D1 (from the JSL at $0288CE), and all of the addresses in the table will be in the right spot.
This is how you fix the original asm file if you wanted to apply the patch using xkas (which is what I did). You could make that edit in the .asm file before you upload if you wanted to, but if you're just manually hex editing the fix in, it won't make any difference (the final binary output will be the same either way).
Thu 28 Apr 2016 - 19:46 by Conn
ok, thanks, corrected and updated both the patch and all-in.
This isn't much necessary, it does not have so much influence if one JSL is still 02/ instead 82/ as long as the major routines are all on fastrom bank.
This isn't much necessary, it does not have so much influence if one JSL is still 02/ instead 82/ as long as the major routines are all on fastrom bank.
Thu 28 Apr 2016 - 19:59 by qwertymodo
Right, the one missing 02 wasn't a big deal. The only reason it became an issue in my case was because I didn't understand that one change you made, so when I tried to recreate that change into the original .asm so that I could combine it with other asm patches, I did it incorrectly. Fixing the original typo makes everything work, whether you use the .ips or the .asm.
Thu 28 Apr 2016 - 20:41 by Conn
Great, took some effort to hunt all fastrom bugs but I think it was worth it
If a bank >= $80 is executed, the codes automatically are executed in fastrom, if a bank is <$80 in normal mode. With all additional hacks we have a mixture and I think the cpu switches between low and fast all time, but this didn't result in a problem.
If a bank >= $80 is executed, the codes automatically are executed in fastrom, if a bank is <$80 in normal mode. With all additional hacks we have a mixture and I think the cpu switches between low and fast all time, but this didn't result in a problem.
Thu 28 Apr 2016 - 20:58 by qwertymodo
I'm actually running all of the new patches in FastROM (except one of the MSU-1 subroutines which causes the title screen glitches to reappear), and am trying to hunt down the rest of the new jsl/jml's in PW 1.1 vs aLttP to convert those as well. It may very well prove to be a fool's errand, but we'll see...
Mon 13 Jun 2016 - 2:45 by qwertymodo
I found another buggy jsl that should be reverted to SlowROM. It works fine in the original aLttP, but in PW, when you place a bomb onto a bush, it causes Link to pick up the bush instead of destroying it. YMMV depending on your hack, might just be better safe than sorry.
See @2:33
- Code:
0x0DC1CB: 86->06
See @2:33
Tue 14 Jun 2016 - 3:35 by Conn
That's strange, in my patch
http://bszelda.zeldalegends.net/stuff/Con/alttp_fastrom.zip
this address is already 06. Maybe I already fixed it and forgot to document. Strange however, that you have it in PW. Either you use an old version of my patch where I didn't fix that yet or you converted more banks than I did.
http://bszelda.zeldalegends.net/stuff/Con/alttp_fastrom.zip
this address is already 06. Maybe I already fixed it and forgot to document. Strange however, that you have it in PW. Either you use an old version of my patch where I didn't fix that yet or you converted more banks than I did.
Tue 14 Jun 2016 - 4:24 by qwertymodo
Interesting. It's also possible that you fixed it, I accidentally "un-fixed" it, and then realized my mistake. I did have a weird snapshot issue in my working directory a week or two ago, so I've had some weird issues since then. At the very least, both of us coming to the same independent conclusion is nice for verification purposes.
Similar topics» Original ALTTP bug fixes
» Zelda alttp HD
» Alttp Chaos
» ALttP Hacking History
» New aLttP PCM pack in the works
» Zelda alttp HD
» Alttp Chaos
» ALttP Hacking History
» New aLttP PCM pack in the works
Permissions in this forum:
You cannot reply to topics in this forum