I just found out about this patch and would really like to use it in my hack if possible. I hope it is still under development. Reading through this thread Vitor talked at one point about releasing the next version in a few days, but it was never released.
I have been doing some testing with this patch and the various tools that work with it, most recently the manual custom block inserter, and I was encountering crashes when a sprite touches a custom block, just like King Dedede a few pages back:
I'm pretty sure the reason for the crash is that the patch uses SNES multiplication registers that will only work when executing on the SNES cpu and not on the SA-1 cpu, and when a sprite touches a block the custom block code will be executed on SA-1 because sprites run on SA-1.
To fix it the patch needs to be modified to use the SA-1 multiplication registers if executing on SA-1. Is there an easy way to check if we are currently executing on SA-1 or SNES? If there isn't then I'll just have to manually set some flag in the SpriteV and SpriteH cases of the patch and use that instead.
On a different note, how can you do a trace of code that is executing on SA-1? It seems that in the Snes9x debugger breakpoints only work for code executing on SNES and not on SA-1. I know this because when I was looking at the custom block inserter crash I tried putting a breakpoint at the start of the patch code and it was crashing without reaching the breakpoint, which was making me think for a while that the crash was happening before it reached the patch code, when in reality it was just not triggering the breakpoint.
It's too bad that there is no addressing mode for DP indirect indexed by x, otherwise you could just store the addresses of the new sprite tables where the old tables were and then just change the addressing mode. Currently this would only work in cases where the tables are indexed by y.
I can't think of a good solution for expanding those tables that doesn't involve doing something stupid like putting a JMP in every place that the tables are accessed.
I was confused by this too when I first read it but I think I understand how all the memory mapping works now. As far as I know this is saying that previously all addresses of the form $YY:0000-$YY:00FF (for YY in the range $00-$3F or $80-$BF or $7E) accessed the same data, and now that data is instead accessed through addresses of the form $XX:3000-$XX:30FF (for XX in the range $00-$3F or $80-$BF). The same thing for the second line, except there is a mistake and it should say "$YY:0100-$YY:1FFF to $XX:6100-$XX:7FFF".
The SNES DEV book linked to at the end of the readme had some very helpful images on pages 1-3-1 and 1-3-2 of book 2 that helped clarify things for me.
I have been doing some testing with this patch and the various tools that work with it, most recently the manual custom block inserter, and I was encountering crashes when a sprite touches a custom block, just like King Dedede a few pages back:
Originally posted by King Dedede
Eh... There's a problem with the SA-1 version of the Manual Custom Block Inserter patch. Whenever a sprite touches a block from the custom block pages, the game crashes. It happens even if there is no code for the block.
I'm pretty sure the reason for the crash is that the patch uses SNES multiplication registers that will only work when executing on the SNES cpu and not on the SA-1 cpu, and when a sprite touches a block the custom block code will be executed on SA-1 because sprites run on SA-1.
To fix it the patch needs to be modified to use the SA-1 multiplication registers if executing on SA-1. Is there an easy way to check if we are currently executing on SA-1 or SNES? If there isn't then I'll just have to manually set some flag in the SpriteV and SpriteH cases of the patch and use that instead.
On a different note, how can you do a trace of code that is executing on SA-1? It seems that in the Snes9x debugger breakpoints only work for code executing on SNES and not on SA-1. I know this because when I was looking at the custom block inserter crash I tried putting a breakpoint at the start of the patch code and it was crashing without reaching the breakpoint, which was making me think for a while that the crash was happening before it reached the patch code, when in reality it was just not triggering the breakpoint.
Originally posted by Vitor Vilela
Some days I had a idea of expanding the maximum number of sprites on screen to 30 (instead of 10), but this require moving all sprite related RAMs to another place, but it's impossible to find free ram on Direct Page for 6 sprite addresses.... So, should I find a workaround for this or better I give up?
It's too bad that there is no addressing mode for DP indirect indexed by x, otherwise you could just store the addresses of the new sprite tables where the old tables were and then just change the addressing mode. Currently this would only work in cases where the tables are indexed by y.
I can't think of a good solution for expanding those tables that doesn't involve doing something stupid like putting a JMP in every place that the tables are accessed.
Originally posted by jesus
I'm not sure if I'm just being dumb, but I don't get what you mean by this. Are you just saying that for those banks ($00-$3F, $7E, and $80-$BF) all addresses $0000-$00FF are mapped to $3000-$30FF? In other words, the bank is NOT changing?
Originally posted by Vitor Viela
Code
(assuming that XX is in the $00-$3F or $80-$BF range and YY equals either XX or $7E) $YY:0000-$YY:00FF to $XX:3000-$XX:30FF. $YY:0100-$YY:1FFF to $XX:0100-$XX:1FFF.
I'm not sure if I'm just being dumb, but I don't get what you mean by this. Are you just saying that for those banks ($00-$3F, $7E, and $80-$BF) all addresses $0000-$00FF are mapped to $3000-$30FF? In other words, the bank is NOT changing?
I was confused by this too when I first read it but I think I understand how all the memory mapping works now. As far as I know this is saying that previously all addresses of the form $YY:0000-$YY:00FF (for YY in the range $00-$3F or $80-$BF or $7E) accessed the same data, and now that data is instead accessed through addresses of the form $XX:3000-$XX:30FF (for XX in the range $00-$3F or $80-$BF). The same thing for the second line, except there is a mistake and it should say "$YY:0100-$YY:1FFF to $XX:6100-$XX:7FFF".
The SNES DEV book linked to at the end of the readme had some very helpful images on pages 1-3-1 and 1-3-2 of book 2 that helped clarify things for me.