Posted By
JamesD
on 2013-08-01
17:50:32
|  Re: Z80 GUI: SymbOS
"Do you have any speculations why so powerful computer as Thompson MO5 was known only at France? It has very poor page at wiki.  "
Um... I think it's largely culture but I'm not going to go into that.
There was actually an Italian version of one of the Thompson machines, the MO6.
It's a pretty cool machine and it has the more advanced graphics chip that was in the TO8 and TO8D but lacks the 6803 to scan the keyboard. It was marketed under another company's name... Olivetti?
For Thompson machines check out this page and yes it's in French:
http://dcmoto.free.fr/
"It looks like I am only one 6502 man at this forum! IMHO z80 code for the real task can't be less than 3 times slower. The mention above hardware man said that the slowest part of z80 is not its instruction set but the way it connects to video controller. The next data illustrate MHO."
I program the 6502... I've programmed a lot of different CPUs in assembly from 4 bit CPUs on up. I just don't have any personal investment in whether or not the 6502 wins some CPU war. If it makes you feel better, the 6502 is way faster than the Z80 at the same MHz.
Here is what the guy was talking about...
RAM wasn't fast enough back in the day to interleave CPU and video access with a 4MHz clock speed or most designs like the Spectrum took advantage of the built in DRAM controller on the Z80 which can't run the RAM faster than the CPU.
The Spectrum, MSX and many other designs insert wait states if the CPU tries to access video RAM while the screen is being drawn. Buss signal timing of the Z80 may not have made interleaving practical with a simple design either.
There's one problem with his comment. Not all machines are like that.
On the TRS-80's, VZ's, etc... this is not the case. The CPU takes priority over the graphics and a random sparkle can appear on the part of the screen being updated during a CPU access. but the CPU doesn't have any wait states.
A third design approach that nobody seemed to take advantage of due to cost would be to use dual port RAM for video memory which would allow the CPU and video to access video memory at the same time without wait states or sparkles. The video and CPU don't even need the same clock.
A fourth design would be to send all memory access through a custom chip which could interleave the accesses transparent to the video update and CPU and deal with any buss timing issues created by the Z80. FPGA implementations actually do time slicing and maintain original timing and this could be done even with a real Z80 CPU rather than just with an FPGA Z80. This was always possible but timing would have been very critical to get it to work right and some buffering would have had to take place.
None of these designs (except maybe MSX?) incurs any wait states when the CPU is not accessing video RAM or when the video display is not being updated. That's why Spectrum Elite devs chose to render to a buffer and then copy it to the screen during the VBLANK. In spite of the extra work it still performs similar to the C64.
And no, zero page is not like registers.
Page zero is like a memory access with 1 less clock cycle. The CPU must load the one byte direct page address which is an additional cycle over just using the accumulator for example.
Second, you have to load page zero by going through a single accumulator 1 byte at a time and you have to get results from page zero the same way. A register just requires you load it.
Also, when you use a 16 bit index register there is less of a penalty than when you have to access page zero to point to data. This is a key reason why the 6502 slows down whenever you access a set of data larger than 256 bytes. You not only have to use the slower page zero access to index the data, you have to test for crossing a 256 byte boundary in your inner loop and you have to update the page zero pointer whenever you cross a 256 byte page boundary. This makes a huge difference.
This is less noticeable vs the Z80 due to its high clock cycle times but it narrows the speed ratio considerably. It's very obvious vs a 6803 or 6809 which just load a 16 bit index register and they don't have to worry about 8 bit boundaries.
This is also where the difference in code size I mentioned comes from.
BTW I got the 2.6:1 for 16 bit multiply from The Fridge and the 6502 guy wrote the 3D code there. It's the most optimized 3D code you'll find for the C64. And as I said, he left out some things that would reduce that ratio.
You can cherry pick code snippits to get the results you want but if I tell you to sort a block of 200 names of varying lengths up to 25 characters in length using an index table you aren't going to be able to do that. You have to load page zero with indexes into the index table one byte at a time, you have to load indexes for each string into page zero zero one byte at a time, you have account for strings crossing 256 byte boundaries in your string compare, you have to copy pointers back from page zero if a swap occurs one byte at a time...
The Z80 can load or save HD, IX and IY as 16 bit values just fine and never has to worry about crossing a 256 byte boundary.
FWIW, the 6803 would not do so well with this either since the quick sort and others would require shuffling pointers in and out of the single index register, but I think the code would still be smaller than the 6502. If I had specified a bubble sort with fixed length data fields (strings padded to 25 characters with zeros) it would kick butt since you can access both strings with the same index, just use an offset of 25 for the 2nd string.
A comb sort (which is fast anyway) would actually be a better choice for the 6803 since you could use one case for data that is far apart and drop through to another case when pointers are under 230 bytes apart and then use a single pointer and an offset. It would require self modifying code for the offset but I think that would be faster than the register shuffle.
The 65802/65816 would not have to deal with the overhead the 6502 requires if you switch to native mode and only the 6809 would handle it better.
This is part of the reason I suggest a 65816 upgrade. You don't just gain the ability to access more RAM, you get smaller more efficient code and better compiler support.
*edit* (this don't double post thing is getting annoying)
With a 65816 you might be able to talk a certain Atari developer into allowing a port of his GUI *eventually*.
http://atariage.com/forums/topic/154520-new-gui-for-the-atari-8-bit/
|
