@jorge: does this look like your work?
Attachment 14802
Printable View
@jorge: does this look like your work?
Attachment 14802
What a nightmare.
I've never programmed a DSP so I don't totally understand it, but it seems like they excel at performing simple, repetitive tasks (like audio mixing or decompression) but take a huge hit when you want any kind of branching instructions because you lose any kind of parallelism.
Were you able to use a C compiler for the DSP or was it all going to be done in assembly?
I looked at some code samples for DSPs and the instructions tend to be very complex, nothing like a Z80 or 68k.
A for loop is easily doable but implementing arrays and pointers seems like it could get more problematic.
Seems there is not much room for code either and you have to do a lot of things manually that a processor would have done for you.
Even if you could get the same result on a DSP it looks like it would be a lot more work compared to a general purpose processor.
Wasn't the DSP planned for implementation in project N? They'd found it difficult to code decent music for the SNES so decided to use the same driver as Papirum and make the music purely PCM based?
The decision of adding a unknown processor as a requirement for both Project Y and Project N was beyond stupid and delusional.
Probably it'd be a good time to remind people that apparently you need the extra power of a Sega CD in order to have an AI player ;P
I've worked with similar TI parts to the "Datenmeister" before. If you buy a license for their IDE (Code Composer Studio) you can code in C or C++. If you actually want to use the Signal Processing parts of that DSP though, you typically still have to code that in assembly.
I can understand that wanting additional audio processing led to adding a DSP (and some glue logic in a CPLD). But stubbornness is the only reason why I can understand anyone would still stick with that arrangement after - four main dev board revisions, fighting the Genesis side for memory access timing, potential other bugs that Jorge asked after and never got feedback on, and presumably multiple years of fruitless development (given the fun sprite corruption I suspect is due to the memory access timing issue).
What. A. Mess.
Great video again. It's great to see someone shed light on the whole situation that led Tulio to leave. It's pretty childish the way he behaved all along and it makes very easy to understand Tulio's decision to leave a company that seemed to be on its way to become a great indie dev. And we can finally understand a bit more what happened in the event at Paris: it seems like he never really figured out the proper cart design to run his game. What makes everything weirder is how there are three known dev carts which were never properly tested... I mean, what it is point of creating them if you aren't giving the designer the chance to actually make sure his design works for the intended application? It's pretty sad to see that he is not able to trust his partners.
It's really interesting to hear from the people involved how it went. What a train-wreck...
After watching that video though, the blame is not solely on Fonzie (though it's definitely clear he's the one who doomed WM).
A lot of the people interviewed seemed to be pretty ok with most of the crazy ideas, which should have never left the drawing board.
There was no need to try and "top" Pier Solar in any way other than making a better game.
This is one of the funnier parts to me. Was the decision tree for player 2 so advanced that it took a separate CPU? What a ridiculous idea. It might impress a few people but it means anyone without a Sega CD -- or anyone playing on a Genesis Model 3 or Nomad -- can't even use the feature.
I do not understand the obsession with making every game be the most advanced game on the console. The focus should have been on making it fun and playable. Not a single person buying Sega Genesis games in 2019 is going to care if the cart lacks a 1 Ghz CPU and Bluetooth.
It really is ridiculous. It sounds like all those decisions were taken by kids trying to one-up each other with the most twisted ideas, without considering these ideas may have more downsides than advantages. "Oh yeah? Well, my cart glows in the dark and can order pizza for me!"
Piling up pointless technical achievements does not make a good game. It does not even lead to a game release at all, apparently. I guess just making a Mega Drive / Genesis game was much too simple. It needed an extra chip as well as the ability to connect to your coffee machine and dishwasher, because that's what players expect from a retro beat 'em up.
Fonzie seems like a shortsighted person that wants to add everything in one project, even in late development. And if there weren't problems with Paprium and he got everything he wanted in... how would he top that in the next game, since that seems to be his thing? Why not let the new ideas for the next game, instead of shoehorning them in a complete idea of a game that doesn't need them? At the beginning of Paprium, I think no one could imagine a coprocessor chip, bluetooth integration, 3D capabilities (?), and God knows what else. It seemed like a really good beat 'em up to push Sega Genesis capabilities, in the vein of Pier Solar, and that's all it ever needed to be.
I don't get it either. If Fonzie wants to make a game that's so technically advanced then why not just make the game for a modern system, or at least a slightly more modern system than the one chosen. Its against the spirit of things to make a game that can't even run on the base console, you might as well install a Cray supercomputer inside the cartridge, it gets to the point of not even being an MD/Gen game.
I've probably just delayed Paprium for a few more years as Fonzie could enter negotiations with Cray for a huge processor rack and a fluorinert cooling system inside the cartridge.