If TOS needs to be changed to work with the 56301, how would compatibility with games and demos be?
I wonder that too. But on the other hand, the performance benefit is really high, someone might be tempted to write a new code for it. (I know what you are probably saying now :wink: )
I haven't read the whole DSP56301 UM yet. ;-) It's object code compatible, so that's a very good news (compare with the FireBee/CF situation...). I'm sure stuff like resetting the DSP, loading the bootstrap code, CPU/DSP sync issues will needs some attention. But then again, DSP XBIOS has been already patched for the sync issues and some minor bootstrapping differences are easy to solve.
So as far as games/demos go, if they don't rely on some dirty practices (like writing beyond RAM space relying on the fact it's mirrored or overflowing the stack -- ask Hatari guys!), they should be fine.
In my very humble opinion, you should be fine to get away with a patched TOS instead of the original TOS 4.04 only. CT60TOS literally begs to be used here as the base for the modifications. Compatibility would be naturally much higher than with the CT60.
mpattonm wrote:Anyway, could _this_ be it?
Looks good to me. Only time (or first implementation ;)) will tell whether that VID32 really needs to be multiplexed. Maybe it's fine to have 32.08... there in all cases without any multiplexing.
Ha, look at this: You can also configure it to operate in a special sixteen-bit compatibility mode that allows the chip to use DSP56000 object code without any change; this can result in higher performance of existing code for applications that do not require a larger address space.
The bad news is that you have to set this bit manually, it's not by default (understandably).