Sik wrote:The 68000 is not that slow, its biggest problem is pumping out all that data in the first place (its memory accesses are awful and doing anything that would involve many accesses per byte is crazy, which is why the effort should be focused in optimizing that).
MintyTheCat wrote:Are we talking about a general custom-MD cart here or the WiFi cart in particular just so we do not misunderstand each other.
Just saying how I'd make it if it was up to me.
These things are all relative, Sik, but the 68K cannot compete against even a modestly powerful RISC uC. It was the late 70s when the 68K appeared and we have witnessed improvements since that time. What has improved is pipe-lining now much more so on the RISC machines compared to the CISC machines. The best way to gauge this is to run various tests but essentially it boils down to MIPS vs. power consumption with the power consumption being related to the frequency that the processor is clocked at.
We had discussed mapping pages into the 68K's space for the custom-cart rather like how existing hardware such as UMDK and the Action-Replay function so there would not be much need to "pump out all that data", Sik.
If you look into parallel processing and such you will see how these types of processing problems are categorised:
https://en.wikipedia.org/wiki/Parallel_ ... s_taxonomy
Essentially, you want the custom-cart to handle the heavy actions. You can imagine a table being passed to the custom-cart, it calculating results and the 68K merely acting on the results returned.
I recall the programmer who wrote Tesla Punk asking me "how does the MD handle angles and such?". After I had stopped laughing at him I told him how the MD can only approximate
angles and such using often tables.
In order to determine what would improve the MD's lot I first looked at what the SNES as a comparable piece of hardware had by way of extra hardware. But having graphical transforms, fixed-point maths, trigonometry and such and a set of frame-buffers all made good sense.
This, however, requires someone who can handle the hardware design though to make this happen. I have not designed any hardware since leaving University so I would not trust my decisions wrt hardware
It would be an excellent project someone who is not afraid of doing some good work though.
Edit: I have been trying to find some kind of comparison between 68K CISC and modern typical RISC processors but cannot much more than university course notes. This will have to do:
https://en.wikipedia.org/wiki/Instructions_per_second
Processor / System Dhrystone MIPS / MIPS D IPS / clock cycles per second D IPS / clock cycles per second / cores per die Year
Hitachi-Motorola 68HC000 3.5 MIPS at 20 MHz 0.175 0.175 1985
ARM Cortex-M0 45 MIPS at 50 MHz 0.9 0.9 2009
Given that the modern RISC uCs consume substantially less power there is also less need to drive them at high clock rates.
MIP for MIP it is substantially cheaper to run a RISC than the 68K as a CISC.
Essentially, the 68K was very good for its time but as more applications were found and insight came about it did not take too long for RISC to beat the old CISC machines hands down.
The interesting cross-over is to find something that would improve the MD's undertaking without adding to much to the BOM for a commercial release and as such we elected a modern RISC based uC as a CPLD and FPGA were too costly.
This of course will change in time as devices are improved. Already, it has been fairly common offer devices with both uC and DSP cores on the same device. There are now CPLD, uC devices available too - we live in interesting times