This is just theory, I haven't actually put it into action.
The use of the SFX in that HDMA topic made me think about offloading some routines from the S-CPU to an SA-1. The nauseating slowdown when too many sprites are on screen might be done away with if the sprite routines were to run on the SA-1 end and the results were sent back to the SNES RAM on completion.
I chose the SA-1 because the code can be mostly reused with almost identical CPU's (some extra code ofcourse has to bring it all together). And unlike the SuperFX which hoards the ROM for itself, the SA-1 can access RAM/ROM together with the S-CPU. The former running at 5.37Mhz and the latter at SloROM speed. It pales to 21Mhz but it makes the implementation so much smoother.
The initial thought I have of this working out is to:
-Start of frame, S-CPU IRQ's SA-1 and signals a new frame. S-CPU DMA's sprite data to 'BW-RAM', sources would be 7E:14C8 and such. Might just do a big block copy (7E:0000-7E:1FFF) to include controller data and what-not. S-RAM is a big issue since the data for say, OAM ($0300) shares ranges with it. Might just scrap the 'integrity check'(?) and just load/store backup data elsewhere.
E: Forgot...Can just set the DB reg to 71f / 41h and forget about backup data altogether.
Probably wouldn't be too hard, I've stepped through most of it. Seems that the other data can be accessed with the data bank being set to BW-RAM (for 16bit addresses). 24bit addresses and SNES reg writes would cause some problems...At any rate, routines would most likely have to be written with the coprocessor in mind.
-For each run of a sprite routine, S-CPU writes PC location of sprite routine to somewhere in I-RAM and IRQ's SA-1 for action. S-CPU just returns and moves onto the next, while SA-1 works on sprite routine.
-Upon completion of the routine, SA-1 writes a certain part of I-RAM checked by the SNES when it finishes processing for the frame.
-SNES DMA's the BW-RAM initially used in the sprite routines back to the SNES and the S-CPU allows NMI to progress / move onto the next frame.
Any thoughts? I've 'equipped' a copy of SMW with an SA-1 and the memory map doesn't conflict with the original one of SMW. LM doesn't seem to mind either. S-RAM and all works fine (just that it also appears at bank 40+). So, I'd like to ask:
-how feasible do you think this is?
-is there anything else taxing on the SNES that could also be offloaded?
-does LM significantly change the sprite routine system?
I'm just thinking out loud here, so I'm not sure if there's a horrible flaw in this plan.
The use of the SFX in that HDMA topic made me think about offloading some routines from the S-CPU to an SA-1. The nauseating slowdown when too many sprites are on screen might be done away with if the sprite routines were to run on the SA-1 end and the results were sent back to the SNES RAM on completion.
I chose the SA-1 because the code can be mostly reused with almost identical CPU's (some extra code ofcourse has to bring it all together). And unlike the SuperFX which hoards the ROM for itself, the SA-1 can access RAM/ROM together with the S-CPU. The former running at 5.37Mhz and the latter at SloROM speed. It pales to 21Mhz but it makes the implementation so much smoother.
The initial thought I have of this working out is to:
-Start of frame, S-CPU IRQ's SA-1 and signals a new frame. S-CPU DMA's sprite data to 'BW-RAM', sources would be 7E:14C8 and such. Might just do a big block copy (7E:0000-7E:1FFF) to include controller data and what-not. S-RAM is a big issue since the data for say, OAM ($0300) shares ranges with it. Might just scrap the 'integrity check'(?) and just load/store backup data elsewhere.
E: Forgot...Can just set the DB reg to 71f / 41h and forget about backup data altogether.
Probably wouldn't be too hard, I've stepped through most of it. Seems that the other data can be accessed with the data bank being set to BW-RAM (for 16bit addresses). 24bit addresses and SNES reg writes would cause some problems...At any rate, routines would most likely have to be written with the coprocessor in mind.
-For each run of a sprite routine, S-CPU writes PC location of sprite routine to somewhere in I-RAM and IRQ's SA-1 for action. S-CPU just returns and moves onto the next, while SA-1 works on sprite routine.
-Upon completion of the routine, SA-1 writes a certain part of I-RAM checked by the SNES when it finishes processing for the frame.
-SNES DMA's the BW-RAM initially used in the sprite routines back to the SNES and the S-CPU allows NMI to progress / move onto the next frame.
Any thoughts? I've 'equipped' a copy of SMW with an SA-1 and the memory map doesn't conflict with the original one of SMW. LM doesn't seem to mind either. S-RAM and all works fine (just that it also appears at bank 40+). So, I'd like to ask:
-how feasible do you think this is?
-is there anything else taxing on the SNES that could also be offloaded?
-does LM significantly change the sprite routine system?
I'm just thinking out loud here, so I'm not sure if there's a horrible flaw in this plan.