My original goal was real-time multi-channel streaming at high sample rates, without restricting music timing to VBlank. But obviously if you can do that, it should also be possible to change out samples in RAM during playback. And it would be nice to have a reasonably fast bulk data loader that didn't freeze the game à la SFA2...psycopathicteen wrote:Are you planning on uploading instruments as needed?
I suspect it'll be a while before I'm ready to actually try out this method in the field. By then I may have a better idea, or I may have realized that this one has a fatal flaw or something...
Technically what it said (following on from the part about the CPU being weak) was:rainwarrior wrote:"Citation needed" is for stuff you think is true, but doesn't have a source. I'd say that's just "delete on sight" material, author inserting their own opinion instead of objectively reporting.Revenant wrote:The "Nintendo crippled the CPU in order to make cartridges more expensive" is definitely "[citation needed]" material.
Which could be considered technically true, but gives the wrong impression. I deleted it, and gave the following reason (visible only in page history):This was intentional on the part of Nintendo because it wanted to lower the cost of the system, and it provided connections for cartridges to have their own coprocessors when high performance processing is needed. This naturally drove up the cost of games that required such coprocessors.
But now I'm worried that I may have started an urban legend about coprocessors in N64 cartridges, which is not what I meant. If some dude on some forum starts claiming WDC or Conker or Naboo had an enhancement chip, you know who to blame...This seems to be an unsupported extrapolation. The NES, Genesis and even N64 could and did use special hardware in cartridges; I am unaware of any indication that this feature was related to the choice of CPU in the case of the SNES.
Next up is to try to finesse some of the CPU stuff...