Posted By
JamesD
on 2013-08-01
11:47:27
|  Re: Z80 GUI: SymbOS
I think the best option is to create a small 65816 plug in board with some cache, 1MB or so RAM and a programmable device that can be configured for a +4 or C64. Then you have a larger potential market.
*edit*
MMS@
"well, i think next to system benchmark tools the best are the 3d games with a lot of (floating point?) calculations behind, like Elite, Castle Master,etc. bitmap gfx is similar hires with similar colormap approach, no major sprite activity. It really shows CPU power, gfx processor does not help too much."
Any time you compare games you potentially run into different levels of optimization.
If one game uses a strait Bresenham line routine and the other uses special cases for horizontal, vertical, less than 45 degree angle, 45 degree angle and greater than 45 degree lines, there can be a noticeable difference in performance based on that alone.
A whole group of people joined in to try to optimize the line drawing routine used by the Oric game '1337' (hacker speak for Elite).
You'd be surprised how much the discussions upped the frame rate of the test routines and the author had spent a lot of time optimizing before other people contributed.
Unless you know what went into the code and know they are doing the same thing, you really can't be sure it's a fair comparison.
1337 videos:
http://www.youtube.com/watch?v=62lJQJy-v6w
http://www.youtube.com/watch?v=DlVW4r2w8y0
Notice the frame rate without flashing and that's a 1MHz 6502.
*edit*
I looked through a head to head challenge some people had between the 6502 and Z80 last night. It was pretty much run by a C64 group but some Spectrum guys were doing the Z80 code.
The 6502 guys claimed a 3:1 or better ratio between the cpus and in some cases they got it.
But I saw a little problem with how they did it.
When manipulating strings they kept the strings to 256 bytes or less.
I wrote a Mockingboard music player and as long as songs were under 256 bytes it shaved a lot off the code. If I had to play songs over 256 bytes the code size and speed changed dramatically. How do you keep strings under 256 bytes in a word processor? You can't. The results were biased towards the 6502. Don't get me wrong, you can manipulate many things to favor the 6502 when you are coding, but it doesn't work for everything.
Now what I think was the key benchmark.
The 16 bit multiply ratio was 2.6:1 according to the results. However for one thing I'm not sure the Z80 math was fully optimized. I saw at least 4 different 16 bit multiply routines and none were the same as I've seen elsewhere claiming to be the fastest. So that's problem number one. Also, how do you keep data for dozens of 3D points all on the 6502's page zero? You don't. The 2.6:1 was strictly for a single multiply with the data already on page zero rather than dozens of points. The 6502 code didn't include the code to move data in and out of page zero for the high speed math routine in the 6502 code. The Z80 code operated anywhere in RAM and suffered no additional penalty. And if you are dealing with a block of points that have to move in different directions and they don't fit in 256 bytes you have to deal with 16 bit pointers and things suddenly look very different for the 6502 and clearly the ratio of 2.6:1 isn't realistic and the ratio in real life ultimately ends up somewhere around 2.2:1, maybe slightly more but pretty close.
|
