| Posted By
MMS
on 2013-07-06
12:42:01
 |  Z80 GUI: SymbOS
just as it shocked me a little: I always wondered, if the Z80 processor in C128,and still available c64 cards has any use as CP/M is really outdated. Also, there was a discussion, if more Ram, mouse and IDE interface/SDcard would be available for Plussy, there is no access to them, even with GEOS.
Today the first day i hear about SymbOS, that is a multitasking GUI with own kernal for Z80 machines. I checked on youtube, how fast it works on a CPC6128 machine,and i was shocked how close the speed and user experience to win95 on a modern PC, even video playback on 4MHz machine! Amazing!
http://www.symbos.de/facts.htm
On the same day a read a blog about Sam Coupe revival project. The complete 20MHz Z80 based stuff with 1MB RAM on Pcb would cost <30Euro without connectors.
http://comments.gmane.org/gmane.comp.systems.sam-coupe/27915
Very active guy on Speccy with nice HW projects:
http://velesoft.speccy.cz/
Maybe the final extension cartridge for Plus/4 could be a limited 20Mhz Z80 PC with 512Kb, double SD slot, IDE and Rs232 port with the port of SYMBOS? That would overkill any c64 project! 
only problem is the limited number of applications and low progress since 2007, and how much we could call it plussy any more, but palette-wise it is better for video playback than CPC, and that project (HW) would not cost that much as SuperCPU+REU (with the involvement of such experienced guy) and no need for special applications to be written.
|
|
Posted By
Litwr
on 2013-07-06
15:43:11
| Re: Z80 GUI: SymbOS
Did you try to use z80 assember? 6502 has clearer style of fast and simple machine language which is similar to modern ARM CPU. 20MHz SuperCPU is 3-4 times faster than 20MHz z80. IMHO If SymOS is Open Source then it is easier to port it to 6502. It is curious will GEOS sources be opened sometime? Why are they still closed?
BTW ez80 can be clocked up to 50 MHz.
Again IMHO z80 at C128 was a great mistake of CBM. If they put two 8502 instead then it was much better decision.
|
|
Posted By
MMS
on 2013-07-06
16:54:46
| Re: Z80 GUI: SymbOS
yeah, initially i learned from a book 6502 assembly at secondary school (hard work...), later at the university we had to program in i8080 assembler. As i remember, z80 has a slightly improved 8080 code. It was not so straightfordard as C=, sometimes 3 commands instead of 2. But i did not hate it so much.
yeah, with 128 they wanted to address serious customers too, CP/M needed z80. Who could know that DOS will kick the ass of Cp/m, that ruled business world? If Cp/m would have been chosen by IBM, then C=128 would have been an IBM PC compatible machine, weird, no?
From GUI point of view the VDC in 128 is better,higher resolution better fits for this task. 160x200 is useless for GUI.
Worst part is that unfortunately the 1bit/pixel color depth of HIRES does not allow such nice screens as seen on CPC.
SuperCPU is a nice project, but the price...
|
|
Posted By
SVS
on 2013-07-07
14:59:10
 | Re: Z80 GUI: SymbOS
"If Cp/m would have been chosen by IBM, then C=128 would have been an IBM PC compatible machine, weird, no?"
Indeed they did! It is said that two high IBM bosses went to CP/M author home. He left them on hold for 2 hours because he was busy with his preferred hobby (to play remote-controlled model planes). After this, they decided to ask Microsoft... 
PS - Z80 code is much better then 8080 IMO!
|
|
Posted By
Litwr
on 2013-07-08
10:49:09
| Re: Z80 GUI: SymbOS
>Z80 code is much better then 8080
Yes, but 6502 is much better than both. CBM produced it without major modification during almost 20 years! 6502 was the revolution which CBM stopped and sold for low price. z80 is only one evolution step from 8080. BTW 8080 was the base of hundreds thousands of SU home made microcomputers - z80 and 6502 were too difficult for SU chip industry.
IMHO it was the big stupidity or the good conspiracy with 8-bit computer development. Sinclair overran himself with QL, Commodore ignored c64/+4/128 development, Acorn was confused with US speculators, ... What if C65 appeared at 1987?... And C+5 at 1988?
|
|
Posted By
MMS
on 2013-07-08
17:22:51
| Re: Z80 GUI: SymbOS
Well, interesting, that you mentioned the C65. Just on this week I watched some youtube movies about a working C65 machine.
With an updated GEOS (hi-res Gfx was in place to support it with 640x400x16) and faster floppy, it could a PC killer machine, capable to do even proper home office job with a Centronics printer + modem.
In 1991 it was still a little open thing, Win95 (and Plug&Play) was not in place, Win3.1 started in 1992. Wiundows 3.0 was rather bad for serious use. Amiga was too expensive and complicated for the masses. (questionmark, how much the C65 would have been cost).
Commodore +5?  Nice idea. Though extra to the missing numeric keyboard I do not see any improvement points +4 (OK, just kidding faster floppy, more memory, HW sprite, and a little more sophisticated sound. A SuperMULTI mode (with double colormap) would have been great to better utilize the color palette (4 free colors per character) and would make games and soft-sprite a fun instead of a suffer
Maybe an integrated GUI into ROM? though running SW from ROM is typically slower than RAM)
|
|
Posted By
MMS
on 2013-07-09
03:54:41
| Re: Z80 GUI: SymbOS
I read a little about the eZ80, and it is a SHOCKING GOOD processor! On the same frequency upto 4 times faster than original Z80,compatible with it, can address 16MB ram, and the 50Mhz version has the speed of a 200MHz Z80!
http://en.m.wikipedia.org/wiki/Zilog_eZ80
Btw I remember, at the university we had to design on paper a working Z80 machine. How the hell i could forget So much knowledge i could use today!
|
|
Posted By
Litwr
on 2013-07-09
09:02:43
| Re: Z80 GUI: SymbOS
IMHO The weakest point of all CBM computers is dependency of CPU clock with video chip clock. If TED had 16 KB of video RAM then it would made CPU about 50% faster and made possible to use faster CPU. The faster CPU could emulate sprites.
BTW Spektrum clones are still produced by enthusiasts at Russia. They may use FPGA or z380 unstead of Z80 clocked up to 28 MHz. I don't know why they missed ez80.
|
|
Posted By
gerliczer
on 2013-07-09
09:10:47
| Re: Z80 GUI: SymbOS
Hi guys,
AFAIK the greatest problem with eZ80 is being an "embedded controller" therefore having a lot of hardware not necessary for a Spectrum type machine. Furthermore the embedded peripherals having port addresses that clearly "collide" with Spectrum peripheral port addresses therefore ruining compatibility with existing software and hardware.
|
|
Posted By
JamesD
on 2013-07-30
13:35:41
| Re: Z80 GUI: SymbOS
"Today the first day i hear about SymbOS, that is a multitasking GUI with own kernal for Z80 machines. I checked on youtube, how fast it works on a CPC6128 machine,and i was shocked how close the speed and user experience to win95 on a modern PC, even video playback on 4MHz machine! Amazing! "
Just keep in mind that that video was converted to a format that is fairly easy to play back on that machine and decent video playback has been done on the Atari and CoCo; probably other 8 bit machines as well.
Did you see SymbOS running on the CPC TREX? That's an FPGA based CPC clone that runs at around 24MHz. It also runs really fast on an MSX Turbo R.
Both are scary fast for a Z80 type machine.
"Did you try to use z80 assember? 6502 has clearer style of fast and simple machine language which is similar to modern ARM CPU. 20MHz SuperCPU is 3-4 times faster than 20MHz z80. "
Z80 assembler isn't bad. You just have to learn which registers to use for certain instructions. Whenever I write Z80 code and haven't used it for a while I have to keep a Z80 book next to me though. The 6502 isn't quite so bad but it has it's share of special cases as well. It's not like X and Y registers are identical. The 6502 also requires a little more code than the Z80 to do the same thing. I think in my own code there was a 10% difference in size between the two but it can be more or less depending on what you are doing.
To be honest, I'll take programming the Motorola 6803 or 6809 over either of those. The code is almost 1/3 the size of 6502 code that does the same thing and it takes less time to write because of the 16 bit support and fewer special cases (which are mostly on the 6803). The multiply instruction doesn't hurt either.
Let me just say that the ARM and 6502 are *not* alike.
I'm not trying to sound cranky here, just stating some facts.
ARM uses a load and store architecture. The 6502 doesn't.
ARM has a large number of 32 bit (or 64 bit now) internal general purpose registers. The 6502 doesn't.
ARM has a multi-stage pipelined architecture. The 6502 doesn't.
ARM has a simple easy to decode 32 bit orthogonal instruction set. The 6502 doesn't.
All those things I listed are what RISC is.
The 6502 is somewhat simple by CISC standards but not in the same way and it's instruction set is very different.
"BTW ez80 can be clocked up to 50 MHz. "
People have mentioned incompatibilities with the Z80 but since the original poster is talking about adding a Z80 to the +4 and you aren't trying to interface the ez80 with an existing Z80 machine, it doesn't matter. The problem you run into is the 6502 to Z80 interface. Video is either like the Amiga Bridge board where the host CPU displays the Z80 output (slow) or you need to pass the +4 video through your add on board like the old Trackstar Apple II boards for the PC.
Either approach works but has it's own issues.
You'd need a customized CP/M or SymbOS kernal and a rather complex board to implement it. It's cheaper to make a stand alone machine than to interface to the +4.
The easiest approach would probably be to use some dual port RAM for the eZ80 video and have the +4 CPU copy it to the +4 display RAM.
I think a better project would be a 65816 accelerator or Zip Chip like accelerator.
Then you can run existing software faster and with the 65816, you can address a lot of RAM in native mode.
Frankly, once you pass 8MHz on an 8 bitter, the software feels more like a 16 bit machine from the 80s. At 20+ MHz you can run BASIC that is as fast or faster than assembly.
I know the FPGA CoCo 3 running at 25MHz runs BASIC at assembly like speeds.
You can clearly see the speed improvement in the video below:
https://www.youtube.com/watch?v=E7982JhI5Kc
|
|
Posted By
Litwr
on 2013-07-30
15:55:38
| Re: Z80 GUI: SymbOS
I'll take programming the Motorola 6803 or 6809 over either of those.
They are very rare in the microcomputers. It's curious what were the systems based on these CPU?
Z80 assembler isn't bad.
I only wrote that 6502 assembler is much easier. z80 is the obvious CISC but 6502 provides only base operations like RISC.
Let me just say that the ARM and 6502 are *not* alike.
Let's see my points:
1. 6502, 6809, ARM don't waste cycles like i8080, z80
2. http://en.wikipedia.org/wiki/ARM_architecture#History - ARM was developed by 6502 men for 6502 replacement
SymbOS looks impossible for 4MHz z80 but 1.8MHz C+4 or 2MHz C128 should be faster! Why they don't publish the sources? GEOS sources are still unpublished too. IMHO It is very odd.
|
|
Posted By
MMS
on 2013-07-30
19:14:57
| Re: Z80 GUI: SymbOS
Thanks for the lot of interesting and useful information!
BTW Z80s boards for C64 for CP/M DO exist for C64 (I ithink at least 4-5 brands available).
So, the problem highlighted seems to be not so complex, and the circuit diagrams does not look too complex. Available here:
http://www.baltissen.org/newhtm/c64_cpm.htm
http://www.z80.eu/c64.html
Fortunately the 6502 allows the complete shut-down of CPU (with or without NMI)
Upgrading this ready concept to a newer HW + Symb OS could be a very nice project.
So mapping the gfx seems done by the system previously too, though I read that only 1MHz Z80 CPU was used
|
|
Posted By
JamesD
on 2013-07-31
01:35:50
| Re: Z80 GUI: SymbOS
>> I'll take programming the Motorola 6803 or 6809 over either of those.
>They are very rare in the microcomputers. It's curious what were the systems based on these CPU?
The Tandy Color Computers and Thompson MO series machines use the 6809 and there were also multi-user systems running OS-9 or Flex. Flex is kinda like CP/M and OS/9 is more Unix like.
The Tandy MC-10 and Matra Alice series use the 6803. I read another machine did as well. I think the other was an early laptop and I *think* it looks like the one used as a prop in 'Air Wolf'' but I'm not sure if it's the same one. The 6803 is also used for a keyboard controller in the Thomson MO7 and as the ADAMNET controller on the ADAM.
FWIW, the 6803 *should* be able to run a version of Flex as well if there are no conflicts with the internal hardware.
>> Z80 assembler isn't bad.
>I only wrote that 6502 assembler is much easier. z80 is the obvious CISC but 6502 provides only base operations like RISC.
>
>> Let me just say that the ARM and 6502 are *not* alike.
>Let's see my points:
1. 6502, 6809, ARM don't waste cycles like i8080, z80
>2. http://en.wikipedia.org/wiki/ARM_architecture#History - ARM was developed by 6502 men for 6502 replacement
The 6502 was a 6800 like architecture reduced mostly to 8 bits to cut the die size to improve yield and lower costs. It also had some optimizations. But it has little to do with the reasons behind RISC.
RISC arouse out of a series of papers published back and forth between some professors from Stanford, Berkely, and another university in 1980.
The topic was whether to ad instructions to CPUs that support compilers better, or to simplify the instruction set to make it easy for compilers to generate code and to pipeline the beast and run it faster to make up for the larger code. Compiler optimization technology was still mostly peephole optimization at the time and many hardware concepts that are common now didn't exist yet.
RISC 1, MIPS, and an IBM CPU (I forget the name) were the first RISC chips, the first two were built in university labs at Berkely and Stanford. This was in 1981.
ARM came out of some guys from another university (Cambridge?) reading the articles published by the other guys and their chip came a few years later (85?) based on the RISC concept. Yeah, ARM was to replace the 6502 but the CPU was not based on the 6502 at all.
Wiki huh? Well, I happen to have a computer architecture book here written by a couple of the guys that wrote some of those papers on RISC and built one of the first RISC CPUs.
I think at least three early chapters mention RISC in the "Historical perspective" at the end of the chapters which is where I got my info.
The book is called "Computer Architecture A Quantitative Approach" and the authors are Hennessy and Patterson. Major University libraries should have a copy but I wouldn't buy a copy unless you plan on designing a CPU yourself or want to know more about computer architecture than any sane person should.
>SymbOS looks impossible for 4MHz z80 but 1.8MHz C+4 or 2MHz C128 should be faster! >Why they don't publish the sources? GEOS sources are still unpublished too. IMHO It is very odd.
SymbOS runs fine on a 4MHz Z80 and that's where it originated; it's just not crazy fast like the 20+MHz machines.
There is about a 2.2 times speed difference between the 6502 and Z80 from the benchmarks I've seen. As to which is faster, it depends on how many wait states you are getting rather than just clock speed.
BTW, the 6809 was used heavily in video games. Williams games like Defender, Joust, Robotron, etc...
The 6809 and 6803 were used in many pinball machines, Bally is one manufacturer that used them.
@MMS
"Fortunately the 6502 allows the complete shut-down of CPU (with or without NMI)
Upgrading this ready concept to a newer HW + Symb OS could be a very nice project.
So mapping the gfx seems done by the system previously too, though I read that only 1MHz Z80 CPU was used"
If the signals are available on the +4 expansion port to halt the CPU and take over the computer then I suppose that's even easier. I knew there were Z80 carts but I didn't know how they worked.
If you have to run at the host system buss speed it might be better to see if the eZ80, pipelined Kawasaki copy of the Z80, or other pipelined derivative of the Z80 has compatible buss signals for those other designs. Then it could run at 1 instruction per cycle even at the slower clock speed. That might make the plug in cart faster than the 4MHz Z80 machines from back in the day. It won't be as fast as the FPGA or Turbo R but it wouldn't be a slouch my any means.
|
|
Posted By
gerliczer
on 2013-07-31
02:53:31
| Re: Z80 GUI: SymbOS
Hi guys,
You came up with a lot of things about processors, OSes and computers. I try to add my 2 cents to some of the topics as a complete hardware amateur. First, I have to tell that having a Z80 connected to the plus/4 or it running GUI OSes seems to be superfluous to me. As someone's pet project it is OK, but beyond that what for?
The CP/M cartridges for the plus/4 cannot be built as the ones for C=64, because there is no externally available mechanism to disable the CPU in the 264 series machines. It would need hardware modifications which are probably not impossible as there are unused pins in the expansion port and next to the CPU there is an 74 series logic IC identical to the one in the 64 with the necessary two gates available. The problem is the port connector and how the unused pins are handled in the available cartridges. Under unfortunate conditions (e.g. unused pins are grounded) the modded machine may lose compatibility with them. Once I was having a message exchange with BSZ about this topic. He said that there _may_ be another way but as he too is busy with his real life I don't think there will be any developments.
If a Z80 is eventually gets connected to a 65XX based machine it won't necessarily must be run on the system clock. If its clock is derived (multiplied) from the system clock then it should be relatively simple to buffer the memory accesses. The Z80 does not turn to the memory in every clock cycle contrary to the 65XX and in a newly designed expansion its control and wait signals are obviously available. Actual Z80 systems like the CPC and Enterprise utilize this feature in various ways.
|
|
Posted By
MMS
on 2013-07-31
09:15:55
| Re: Z80 GUI: SymbOS
thanx for the lot of useful info.
The basic idea came from the problem that there is no working mouse on plussy that may work with Geos. As i know, geos works only with 1551 only, that is 2.4x faster than 1541, but very few people may have 2 working one, and still not blazing fast. There is no REU (ram expansion unit) that may work with Geos, and all available one need a lot of internal job, less and less people can do. --> there is no GUI exists on plus/4 that may give the feeling that is fast and responsive like newer Geos on an expanded c64 or SymbOS on CPC.
|
|
Posted By
Litwr
on 2013-07-31
14:11:43
| Re: Z80 GUI: SymbOS
JamesD >There is about a 2.2 times speed difference between the 6502 and Z80
IMHO This factor (2.2) is disputable. I have evidence from a man experienced with 6502 and z80 that this factor maybe up to 4 or even 5. IMHO it is about 3-3.5 because we can see the same games for 3.5MHz Spectrum and 1 MHz C64 where C64 used more advanced graphics and sound.
|
|
Posted By
gerliczer
on 2013-07-31
14:32:39
| Re: Z80 GUI: SymbOS
Hi Litwr,
That 2.2 times speed difference is a misconception. Just because a computer which is more suited to run action packed games than the other runs these programs quicker it cannot be said that its processor is faster. The Commodore hardware with its fine scrolling capabilities, hardware sprites and a very exploitable video chip is more suited to run games and thats all. Should you pair the Z80 with hardware similarly capable it'd very likely produce equally or maybe even faster running games.
|
|
Posted By
JamesD
on 2013-07-31
16:36:00
| Re: Z80 GUI: SymbOS
@Litwr
"IMHO This factor (2.2) is disputable. I have evidence from a man experienced with 6502 and z80 that this factor maybe up to 4 or even 5. IMHO it is about 3-3.5 because we can see the same games for 3.5MHz Spectrum and 1 MHz C64 where C64 used more advanced graphics and sound."
It's disputable if you compare instruction by instruction. But the benchmarks I've seen don't reflect that. If the 6502 even has to touch 16 bits (and it always does) the individual instruction advantage goes right out the window.
Compare compiler output and the 6502 really sucks.
The problem with comparisons between programs is usually apples and oranges since the CPUs aren't doing the same work. Since the Spectrum drives everything in software you have to be careful what you compare if the goal is comparing processors.
Elite should be a great comparison tool because it involves a lot of math, drawing lines, etc... right?
So compare Elite between the Spectrum and the C64. Yeah, it's a similar frame rate at a glance but the Spectrum doesn't flash lines like the C64. You know why? Because it's rendering to a buffer and then copying the buffer to the display on VBLANK. The Speccy is doing a LOT more work than the C64 and rendering at a similar frame rate. It's also delaying to a VBLANK rather than rendering every frame as soon as possible. That kinda throws out the "they run about the same speed and the C64 CPU is about 1/4 the MHz" argument. Apples and oranges.
Sort an array, draw a line with the same algorithm, move some memory around, draw some text rendered in software on a hi-res bitmap, etc... and then you are doing the same work... as long as the computer hardware isn't adding wait states for the CPU anyway because then results are system specific rather than CPU specific.
@gerliczer
The 2.2 speed difference is something that Spectrum users generally admit to.
In reality, it depends on what you are doing. Some things will be faster than others.
|
|
Posted By
MMS
on 2013-07-31
17:04:55
| Re: Z80 GUI: SymbOS
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.
Back to the topic (previously i lost some hundred words by pressing a wrong button,ah!):
i see zero chance to have Supercpu or Reu like project for this small scene,would be too expensive, hundreds of euros.
I have a small project (originated from a more talented HW guy) on hold till october (new house ready), RS232 mouse on user port. Testing, Resident Sw (for BASIC) finetuning and geos driver to be made. I want to use it in my slowly progressing adventure too. Then all the doku would be available (board together with mouse may cost 10-15€)
but this is still only the mouse. And then what about c16 and c116?
Reading few revival project (Sam, Speccy 2010,etc) i saw a lot of new projects, but they still look like an emulator, just in Hw, not PC Software
then how we may rocket our machine next to "übermachine 8bit beasts" to provide XXI. century performance with keeping most of key parameters?
The modification and direct linkage via cartridge of an almost ready fast Z80 (eZ80?) based machine may give us a lot: blazing fast speed, Rs232 for mouse, big memory, Sd card support, even internet access. With SymbOS it would be a beast on low price. Take it as a part of symbOS, and NOT as C+5. Ready eZ80 boards may cost 60-80€, but we need no HDMI and GPU, and 256Kb+SD would be enough, and card pribe could be below 50€ despite low volume (as using standard cheap components). Keeping TED would keep the essentials (gfx, sound), SymbOS would run,feel and taste as a Plussy on steroids. Though the running of original plus/4 code would be impossible(like in GEOS!), it would open a new possibility: running all ZX Spectrum games on this extended machine in emulation, as Plussy can easily show speccy pictures, emu of speccy sound is easy with TED.
If the Cpu switch off signal does not exist on plussy expansion port,like on c64, then all the aboves (and any cpu upgrade project) are impossible.
|
|
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.
|
|
Posted By
Litwr
on 2013-08-01
16:01:06
| Re: Z80 GUI: SymbOS
@JamesD
Do you have any speculations why so powerful computer as Thompson MO5 was known only at France? It has very poor page at wiki. :-(
[***edit] Could you give a link to page with 6502 vs z80 codes?
@MMS
http://www.ebay.com/itm/Amiga-USB-Mouse-Adapter-PS-2-USB-Brand-New-/120777266394? - look at price
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.
| 6502 | z80 |
|
|---|
| bit zp | 3 | 8 | 1:2.67
| | lda/sta abs | 4 | 13 | 1:3.25
| | lda/adc/and/eor/or im | 2 | 7 | 1:3.5
| | jsr abs | 6 | 17 | 1:2.83
| | jmp abs | 3 | 10 | 1:3.33
| | bcc/... rel | 2/3 | 7/12 | 1:3.5/1:4
|
Jumps and calls are the same at any CPU and can't be replaced.
z80 has no instruction like LDA ABS,Y which has the same speed as LDA ABS.
6502 zeropage speed is like z80 registers.
|
|
Posted By
MMS
on 2013-08-01
17:35:54
| Re: Z80 GUI: SymbOS
Litwr, you look a little depressed!
Well, I am with 6502, but
- I was a big fan of SAM Coupe (though it has few design flaws) since I read about it in Spectrum Vilag (=World) and really impressed by the Russian ZX Spectrum clones, like Pentagon too.
- The turbo versions of the 6502 (like 65816) look pretty complex to manage, seems rather picky on RAM and the speed of supporting compontents. Also, it is backward compatible with 6502, but in 8bit mode seems rather limited, it should be switched to 16bit, if I understood well. It works in practice with C64 and in Apple IIGS, but both were
eZ80 seems to be faster, better equipped, and 8bit mode is the only one it needs. Not to mention, that for 6502 the GEOS (and maybe Contiki) are the most advanced GUIs, while SymbOS is Z80 originated, and already has MP3 and Video playback capabilities, can be well suited for the HW capabilities. SymbOS looks a much more "modern" system, than BGEOS, though no DTP or Word processors exists yet, as I see.
The RS232 Mouse to User port is an easy thing, and worked well during the short tests.
It is based on the Max232, and you can easily buy a ready TTL-RS232 converter board, you just need a User port (maybe the most expensive part of the circuitry).
PS2 and USB need much higher speed than RS232, and without a much more advanced (=more expensive) circuitry you cannot implement it on 8bit machines, as I see.
BTW in a previous post I wanted to say, that asking the GUI to be fully given with Source-Code it a request only since Linux exists.
I am not aware of any previous OS that comes with fully documented source code.
Maybe we -as users- have too high expectations?
JamesD,
The project looks pretty nice, and runs really smooth on ORIC. :-)
|
|
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/
|
|
Posted By
Litwr
on 2013-08-02
13:13:58
| Re: Z80 GUI: SymbOS
Hi, JamesD. Thank you very much for your information. However I have the intention to discover truth! I like any CPU so I have to know all about them. I really want to find more data about speed comparison. Sorry I am only skilled with 6502 and i80x86 assemblers. My dream is to find true speed relationship between 6502, z80, and K1801VM1 (it used at first SU home PC https://en.wikipedia.org/wiki/Electronika_BK). I've just made two algorithms for 6502:
- general addition and assignment of n-byte numbers (n - constant, n < 256), it realizes v3 := v1 + v2 assignment operator;
- the comparison of two n-byte zero-terminated strings (n - variable, any value in range 0..65535).
Algorithm1
| the call | cycles | bytes
|
|---|
| lda #>v1 | 2 | 2
| | sta bigadd.arg1 + 2 | 4 | 4
| | lda #<v1 | 2 | 2
| | sta bigadd.arg1 + 1 | 4 | 4
| | lda #>v2 | 2 | 2
| | sta bigadd.arg2 + 2 | 4 | 4
| | lda #<v2 | 2 | 2
| | sta bigadd.arg2 + 1 | 4 | 4
| | lda #>v3 | 2 | 2
| | sta bigadd.arg3 + 2 | 4 | 4
| | lda #<v3 | 2 | 2
| | sta bigadd.arg3 + 1 | 4 | 4
| | jsr bigadd | 6 | 3
| | | 42 | 39
|
| |
| the subroutine | cycles | bytes
|
|---|
| bigadd | clc | 2 | 1
| | ldx #0 | 2 | 2
| | bigadd.arg1 | lda 0,x | 4 | 3
| | bigadd.arg2 | adc 0,x | 4 | 3
| | bigadd.arg3 | sta 0,x | 5 | 3
| | inx | 2 | 1
| | cpx #n | 2 | 2
| | bne bigadd.arg1 | 3/2 | 2
| | rts | 6 | 1
| | | 20n+9 | 18
|
|
Algorithm2 (edited)
| the call | cycles | bytes
|
|---|
| lda #>s1 | 2 | 2
| | sta strcmp.arg1 + 2 | 4 | 4
| | lda #<s1 | 2 | 2
| | sta strcmp.arg1 + 1 | 4 | 4
| | lda #>s2 | 2 | 2
| | sta strcmp.arg2 + 2 | 4 | 4
| | lda #<s2 | 2 | 2
| | sta strcmp.arg2 + 1 | 4 | 4
| | jsr strcmp | 6 | 3
| | | 30 | 27
|
| |
| the subroutine | cycles | bytes
|
|---|
| strcmp | ldx #0 | 2 | 2
| | strcmp.arg1 | lda 0,x | 4 | 3
| | strcmp.arg2 | cmp 0,x | 4 | 3
| | bne l2 | 2/3 | 2
| | cmp #0 | 2 | 2
| | beq l2 | 2/3 | 2
| | inx | 2 | 1
| | bne strcmp.arg1 | 3/2 | 2
| | inc strcmp.arg1 + 2 | 5 | 3
| | inc strcmp.arg2 + 2 | 5 | 3
| | bne strcmp.arg1 | 3 | 2
| | l2 | rts | 6 | 1
| | | 19n+4 if s1=s2 | 28
| | | 19(n+1) if s1≠s2 but first n chars are matched
|
|
Could anybody provide codes or links to the functionally equivalent codes for z80? I'm ready to calculate cycles and bytes by myself.  Thanks in advance.
[**edit**] I've just find code for the strings comparison at http://sources.cosam.org/cgi-bin/viewvc.cgi/z80/string.s?view=markup - it gives for the subroutine 57n+50 cycles and 14 bytes, for the call 37 cycles and 9 bytes. So z80 exactly 3 times slower here but the code for it is about 3 times shorter. So we need at least 256K for C+4's SymbOS but it should be at least 50% faster than at CPC!
|
|
Posted By
JamesD
on 2013-08-02
07:32:42
| Re: Z80 GUI: SymbOS
@Litwr
Are you optimizing for size or speed?
If you have short strings you could unroll the loop.
If you have strings longer than 256 bytes or they might cross a 256 byte boundary, does your 6502 code handle that? (I didn't even look)
|
|
Posted By
Litwr
on 2013-08-02
13:28:26
| Re: Z80 GUI: SymbOS
I'm not optimizing compiler! I've just made proof that z80 is 3 times slower with strings (up to 65534 chars) compare. The page boundary crossings will add about 1 cycles and this may reduce ratio to 1:2.85 but they maybe avoided by passing proper initial x and y values to the subroutine. Sorry I wrote more 6502 code than I should - 4 lines are excessive - we do not need to increase low byte of string address - this reduces code by 10 bytes. So z80 code will be only 2 times shorter now!
IMHO the code with addition for z80 will be at least 4 times slower.
[***edit] Sorry, this 1 cycle cannot be removed. So finally we have 1:2.85 ratio.
|
|
Posted By
JamesD
on 2013-08-02
15:13:57
| Re: Z80 GUI: SymbOS
"I'm not optimizing compiler! I've just made proof that z80 is 3 times slower with string (up to 65534 chars) compare."
In your string compare... where do you test the 2nd string for a zero terminator?
Won't that string compare fail if the 2nd string is shorter than the first?
Wouldn't that add 6 clock cycles?
*edit*
The first compare will deal with it because they are different. Answered my own question.
"The page boundary crossings will add about 1 cycles"
Perhaps you were thinking of the code crossing a 256 byte boundary and not the strings crossing a 256 byte boundary?
BTW, I said before I only found something like a 10% difference in code size but now that I think about it, it was closer to 15%. But then that was based on two simple music player interrupt routines minus the extra overhead the 6502 code needed to handle the VIA interface to the AY chip.
I was able to optimize the 6502 code a little when I moved it to the Apple II and when you use songs that don't cross 256 byte boundaries I guessed it would be about 10% but I never counted bytes. I suppose if I spend more time on the Z80 code I could optimize it as well but it was based on someone else's code to begin with so I think some optimization may have already taken place before I changed the code to an interrupt driven player.
|
|
Posted By
gerliczer
on 2013-08-02
15:28:58
| Re: Z80 GUI: SymbOS
Litwr,
I think the first page at Z80 vs. 6502 - Classic Computing - AtariAge Forums tells everything that must be known about the performance of the two processors. Read the posts of especially JamesD, TMR and Rybags. With this cycle counting you are making a disservice to yourself. You should understand that these processors not exist and work in an imaginary comparison test environment but in reality as parts of different computer systems with very different specifications.
|
|
Posted By
Litwr
on 2013-08-02
16:12:05
| Re: Z80 GUI: SymbOS
s1 and s2 are addresses of strings. I don't see any problem with this algorithm if a string will cross page boundaries.
BTW if we transfer proper X to subroutine than we get only average 0.5 of cycle. This makes z80:6502 speed ratio to 1:2.92 and code size ratio to 1:1.86.
If you have z80 code sample less than 32 bytes then I may try to write its 6502 equivalent.
[***edit]
gerliczer, thank you very much for the link. I've just read all 6 pages. However it contains theoretical discussion about old prices, definitions of CISC and RISC, ... I could also find very useful link about z80 wait states there. :-) My position is close to [youki] who wrote "I have to say that in that i don't like program in Z80. Not for technical reason , because Z80 is more or less as good than a 6502. But the RISC of the 6502 is more comfortable and more pleasant than the CISC of the Z80. That's purely subjective." I can't say that I don't like program in Z80 though - I am only seeking truth. :-)
So if we will count wait states (like at MSX, CPC, Spektrum, ...) then z80 code will require 67 cycles and this makes speed ration 1:3.2-3.4! Wow!
BTW I will also be happy if I can find information that z80 is even faster than 6502. What is wrong with small exercise of cycle counting for this computer forum for the entertainment? BTW I have Holidays. :-)
|
|
Posted By
MMS
on 2013-08-02
16:19:17
| Re: Z80 GUI: SymbOS
@gerliczer
"First, I have to tell that having a Z80 connected to the plus/4 or it running GUI OSes seems to be superfluous to me. As someone's pet project it is OK, but beyond that what for?"
Some possibilities may move Plus/4 from an older hobby machine to something more up-to-date:
-Fluent Video playback (just for fun)
-Music Player for CPC formats, Tracker formats can be easily played.
MP3 playback is a questionmark.
With 24MHz Z80 CPC Trex machine it was not possible, but eZ80 is much much faster.
(see my comments below)
-Internet as possiiblity via eZ80 (to be checked, how)
-Norton like file manager
-Task Manager
-Minesweeper (I know we already have few)
-From HW side SD card and mouse RS232 connection ()
I remember, my PI had troubles with MP3 under Windows Millenium.
eZ80 has 80MIPS at 50MHz, could be just enough. MP3 decoding is complex, from raw power 40-50MIPs needed for that.
Interestingly, the first Cray has 160 MIPS, Intel 486DX has 54 MIPS.
Amiga500's 68000 at 8MHz has 1 MIPS.
So eZ80 at 50MHz is THAT strong (80x an Amiga500, though without special custom chips), paired with efficient and compact 8bit code.
Check this out! SymbOS in multitasking action on a 24MHz CPC TREX (FPGA based):
http://www.symbos.de/videos/trexsymbos1.zip
|
|
Posted By
gerliczer
on 2013-08-02
17:33:35
| Re: Z80 GUI: SymbOS
Hi MMS,
You say that having a Z80 connected to the plus/4 would make it more up-to-date. It may be so but still would be superfluous. The things you listed can be done much better in today's hardware. Do whatever updates you want to an early to middle 80s machine it will never be more than an old hobby machine.
As for the possibilities:
- Fluent video playback does not require a Z80 CPU but quick mass storage preferably with DMA. Look for IDE64 and 16MB REU based videos for the 64.
- CPC music requires AY extension and rewritten player.
- MP3 can be played on the C64 with a hardware decoder - well, actually I seem to remember a demo that even does some realtime effect processing - that is a plug-in for another expansion card (MMC Replay?).
- Internet would first need an Ethernet card, besides Contiki (look it up) has a text browser AFAIR.
- Norton like file manager? I think that siz converted a tool for SD2IEC that has similar arrangement.
- Task manager? WTF?
- Minesweeper. After a quick check, we have at least 5.
- For SD cards use SD2IEC. It is now manufactured in case colour harmonising with 264 series. And connect a 1351 mouse or a PS/2|USB one via Micromys to the SID card.
Anyways, no matter how you slice it, the plus/4 will not replace any modern computer however you upgrade it. As someone's hobby it is cool but beyond that there is no sense to it.
|
|
Posted By
JamesD
on 2013-08-02
18:12:52
| Re: Z80 GUI: SymbOS
@MMSZ
MIPS on processor A <> MIPS on processor B unless they are a similar architecture.
Remember RISC requires more instructions to do the same thing as CISC so counting how many million instructions per second isn't going to give an accurate speed comparison.
And attaching a 50MHz eZ80 to a <2HMz 6502 buss is going to be real interesting to say the least. I was suggesting just using the +4 clock and letting the eZ80 optimizations make up for the slow clock speed.
The Trex machine uses a CPU core with Z80 timings so I'm not surprised about the MP3 playback. The 24MHz Trex is a very different beast than the 25MHz CoCo 3. If they switched cores to the pipelined Z80 I mentioned then it would run much faster. Still not sure about MP3.
@Litwr
Every Z80 machine you mentioned in your last post has different wait states. But if you compare to that, you are comparing to a specific machine, not just the Z80.
As for the s1,s2, I was relating to my earlier post where I was talking about previous benchmarks I'd seen, not your code sample. You said a difference of 1 clock cycle but you weren't talking about the same thing I had been talking about. You didn't take as many shortcuts on this benchmark as some of the previous ones I had seen.
FWIW, RISC isn't very comfortable for a human. It involves moving simple instructions around to prevent pipeline stalls and it's a bit tedious. For an embeded system I worked on we generated code for the DSP with a compiler and then did some hand optimization. Compiler optimisers weren't that great yet. A decent peephole optimizer could have done the same thing in seconds.
gerliczer@
I'm familiar with that Z80 vs 6502 thread. It was more about WHY the 6502, Z80 or other CPU and not bragging rights over benchmarks.
|
|
Posted By
MMS
on 2013-08-02
18:51:04
| Re: Z80 GUI: SymbOS
OK, I see your points, though some of them is just a question of programming.
(AY playback: SID wave digi player (without SID card) was possible with much less powerful CPU too
You are right on the Internet. As all available eZ80 boards support it, I thought it comes natively from eZ80 (provides hardware MAC address), but I was wrong, it is made by a IC has DMA access, controlled via I2C bus, though eZ80 supports a TCP/IP stack.
Why all those FPGA based machines made, including C-One and the others developped? Why IDE interfaces, REU and CPU boosters made? All those efforts are pointless?
The point is, that those speed and possibilities may be available 60€-100€, while SuperCPU may cost >400€ (I saw on eBay for more too). I think it makes a difference. But as you pointed out previously, the missing pins from the Extension port may make this discussion completely useless.
You are right, it would be only a pet project on our beloved small machine to better utilize eg. it's colors (video playback), and while we show it's potentials, it may increase interest on the scene and may involve more people to develop on Plus/4.
Everyone knows, that a C64 will never be a Pentium.
I am writing it certainly on an Intel i5 machine, not on Plussy.
But while I am interested all other 8bit and early 16bit machines (and I learn about more and more), this is the only machine I really like, not because it is the most competent of all systems of the time, but because I have some warm feelings related to my childhood, and time spent with this machine. I know it is pointless in the XXI.century when we all have internet where we can spend all of our time
|
|
Posted By
JamesD
on 2013-08-02
20:27:49
| Re: Z80 GUI: SymbOS
There is absolutely nothing wrong with pet projects. I do hardware stuff for myself mostly. I've posted some stuff for other machines to gauge interest and had zero response from people.
If you want to try something in software, I remember seeing someone playing video on the Atari 8 bit. The +4 should be able to do that with a decent speed drive interface.
|
|
Posted By
gerliczer
on 2013-08-03
03:56:37
| Re: Z80 GUI: SymbOS
@JamesD: Somehow, who knows why, I expected you to be familiar with that forum thread. My whole point was to show Litwr that people who know what they are talking about and frequenting this forum too already had this discussion and have the conclusion, so he is just wasting his time with these cycle counting experiments, trying to compare apples to pears.
Regarding the Atari video playback Algorithm/Algotech^Onslaught comes to my mind who plays short video sequences decompressed from RAM with audio streamed from a 1541 in his demos.
@MMS: You raise valid points but let's view them from a different angle.
Wave converters are a terrible waste of CPU resources for questionable results. Back in the days when the great old ones like Mucsi or CSM were still in the scene it was already considered not a worthy effort to have a picture or logo with a scroll and a wave converted music playing in a demo part. The technical limitations do not let to have much more or only through insane efforts which could be put to better use doing some more spectacular visuals. Now, call up in your mind the recent successes of TEK and Bauknecht demos. Did those use anything beyond native TED music?
Next, Internet. Yes, PHY circuitry seldom is a part of microcontrollers. But why would you restrict yourself to a limited to the unusablity experience? It can be done, people already prove it. What would be the point in a me too implementation? Although, if you do it yourself to learn or have fun then it's OK.
Now, REU and CPU cards are generally frowned upon in the C64 scene. IDE64 and 1541Ultimate is considered useful oddities, but you are better off not using its hardware accelerating features in any products or you will be looked down with pitying eyes. Those guys consider that kind of "purity" a virtue. The FPGA based machines usually try to recreate in modern components the exact same operation of the original machine. This may be considered as an escape route from the failing original hardware, although I think the retro computer scenes will die with the dying breaths of the last working machines. Building specialized hardware in extremely low quantities is costly. Those things you mentioned are built, I think, in the low hundreds. Imagine what would similar expansions cost for plus/4 based on that BSZ sold altogether 30 pieces of SID cards and needing unavoidable hardware modifications. And the final bonus is the unprocurable expansion port connector without which you cannot connect the already existing 1551 drives and expansions to the new iron.
Finally, the 264 series machines take a special spot in the hearts of most of us. That's why we come here frequently to have some conversation about those computers. Unfortunately, being mostly the same as a C64 but with much less capabilities it will never really attract people. We should give thank to the powers above that some extreme challenge seekers like Bauknecht, Cosine, Krill, Shadow/Noice, carrion and Grass (sorry if I forgot to mention someone) found the plus/4 or C16 interesting enough to spend some little time with it.
|
|
Posted By
MMS
on 2013-08-03
07:23:47
| Re: Z80 GUI: SymbOS
hi Gerliczer,
thanks for the detailed answer, and i agree that you are right in most of the points. Please do not take it wrong, just few more ideas (i am absolutely do not feel bad if i am wrong ):
-with the finally available JiffyDOS, an 1541 and 1571 can easily outperform the 1551. As 1551s slowly die (too brittle plastic,etc), 264 machines should depend more and more the 20x available 1541/x drives,that can be 5x faster too with Jiffy. Compatibility with fastloaders? Dunno
-External SD drive is still a little slow on IEC bus (JiffyDOS?, questionmark), but what if SD connected to memory bus directly?
-i remember how much i wished an Amiga, but i could own one only for 4months, then had to switch to PC 286. With 16Mhz it had the raw power to play multichannel Amiga MOD music on speaker, later on the self-built 8Bit COVOX card in a very nice quality. it was my top experience on that monoVGA machine. Sampling frequency is a key to playback quality, and that is mainly depends on Cpu raw power. Digi converters eat to much Cpu power to do anything extra, but what if Plus/4 would have 2x or 3x more power? Then both nice music and nice visuals may work together. BTW PC Engine had 5bit music channels, and it does not sound bad at all (used short samples stored in memory like Gravis)
|
|
Posted By
JamesD
on 2013-08-03
10:11:33
| Re: Z80 GUI: SymbOS
Anytime you bypass the standard drive interfaces you run the risk of loosing compatibility with something.
But the only way to surpass the speed of those interfaces is to do just that.
Just remember that SD/MMC is a more difficult to implement interface than CF. CF requires a simple buffer (if you want a 16 bit interface), buss logic and address decoding. SD also requires serial shift registers and a separate clock signal.
The complexity of the timing for SD pretty much requires a programmable device but CF can be done with simple TTL parts.
Both would require a custom DOS
Given the market for such a board I think cheaper would be better.
FWIW, I have seen SD done with TTL parts but it was pretty ugly.
(I'm talking about directly tying the interface to the CPU buss)
|
|
Posted By
gerliczer
on 2013-08-04
03:33:31
| Re: Z80 GUI: SymbOS
Hi MMS,
This starts to diverge from the original topic very much but I made in YAPE a simple comparison of 1541 and 1551 disk turbos. I made a disk image with The Star Commander, copied into it Ninja Is Back (214 blocks) and first loaded it with TSS3 DiskTurbo in 1541 emulation, then tried a couple of 1551 disk turbos of which I found the Fastload 1551 V3.5 best. Measurement was done manually with the stopwatch of my phone. I made three attempts and tried my best to measure from screen blanking to the appearance of READY. The loading time for 1541 was around 9.9~10 secs and for the 1551 was around 4.5 secs. Unless there is a significantly faster disk speeder for 1541 on plus/4 I conclude that 1551 still wins. Although it has to be said that one would expect larger difference due to the parallel nature of the '51.
The latest builds of SD2IEC firmware usually support JiffyDOS (and quite a good amount of other disk speeders like Krill's loader) therefore if the C16 or plus/4 has JD ROM then it wouldn't be too shabby. It is a bit faster than any drive in plain IEC mode anyway because it does not have to wait for disk rotation.
Edit: Well, probably I am an idiot. The emulation of drives in YAPE is complete, AFAIK, therefore the measured times include the at least 10 track changes which can take 1-2 secs. This changes the picture of transfer speeds quite a bit.
|
|
Posted By
JamesD
on 2013-08-03
18:13:27
| Re: Z80 GUI: SymbOS
The 1551 has to wait on the rotation speed of the drive even to load another sector even if it doesn't have to change tracks. And then there is the data encoding on the disk. CF or SD directly attached would be significantly faster even if it has to deal with the drive format.
|
|
Posted By
MMS
on 2013-08-03
18:55:46
| Re: Z80 GUI: SymbOS
Hi JamesD,
I checked the ATARI GUI project thread. Alhough it really looks very promising, but seems far behind SymbOS or GEOS. As I see, it needs extra 2 years to become a comfortable system, though running natively on 6502 on 64K is a big advantage.
|
|
Posted By
gerliczer
on 2013-08-04
03:33:05
| Re: Z80 GUI: SymbOS
Hi JamesD,
The rotation issue also affects the 1541. But it does not count, in the sense that the drive has to wait for the proper sector to load, in the case of track loaders. These load the whole track and the computer will put the content of the sectors into the proper order. Obviously, when an SD based drive reads data it is not slowed down at all by mechanical (as rotation and track steppig) or software (lengthy GCR decoding) performance drawbacks.
Hi MMS,
Could you give us a link to the Atari GUI project? I'm too lazy to Google it up now.
|
|
Posted By
MMS
on 2013-08-04
06:26:41
| Re: Z80 GUI: SymbOS
Helllo
Here is the link, provided by JamesD previously.
As far as I see, at the current state it is more a file-manager testing the windowing possibililites of the system.
http://atariage.com/forums/topic/154520-new-gui-for-the-atari-8-bit/
Interestingly, there is a video on Page86 about Apple IIe with 128KB (with 65C02 run on 1.023MHz) that run the Apple DesktopII 1.1 with a rather blazing speed. (OK, i know that ApppleII peripherials were much faster than Commodore had. Only RAM and 1551 speed is our limit to reach that level with GEOS?)
|
|
Posted By
Litwr
on 2013-08-04
09:41:11
| Re: Z80 GUI: SymbOS
IMHO the quality of the best 1541's turbo are higher than for the 1551's because much more ppl worked with 1541. IMHO the perfect 1551 turbo must be 4 times faster than 1541 turbo. The best 1541 turbo use 2 lines to send data.
[Apple II] I've found nothing about disk speed at http://en.wikipedia.org/wiki/Disk_II - so it should be not too fast. However the article at Russian wiki (seek paragraph with word RWTS) contains information that Apple 2 drives are very slow and have only 140 KB free space. It also contains information about new RWTS (disk BIOS) invented at SU for 840 KB drives. It can read one track + one sector for one disk rotation! The original Apple BIOS requires 16 rotations for this. This invention was later used by USA drive producers. So if we change 1551 ROM in the mentioned way then we may significantly increase speed. I know man who may provide more information about AGAT drive bios... BTW IMHO Apple IIe is much worse than C+4. It has only one sound channel, 16 colors palette, 1MHz CPU, 140x192 graphics, 140 K drive - very poor... All Apples don't support hardware sprites. However Apple had better software and advertising.
|
|
Posted By
JamesD
on 2013-08-04
14:17:46
| Re: Z80 GUI: SymbOS
@Litwr
https://en.wikipedia.org/wiki/Apple_DOS
http://apple2history.org/history/ah15/
|
|
Posted By
MMS
on 2013-08-04
18:18:09
| Re: Z80 GUI: SymbOS
the resolution did not look so bad on that video. I suppose they used the 280x192 6color mode. Unfortunately plussy does not have the possibility to upgrade with a card to 80column display, with double horizontal resolution.
I am happy to hear that 1551 won
Maybe i am wrong, but as i remember, 1551 does not use paralel 8 bits for data transfer, so the 4x speed difference technically not there.
|
|
Posted By
Litwr
on 2013-08-05
07:44:07
| Re: Z80 GUI: SymbOS
1551 uses 8 bits for transfer data - I emulated these things in my 'plus4forever?'.
[Apple II] It is still very closed system. Both articles mentioned by JamesD miss information about data transfer speed and even filename length! Apple according to wiki may use 280x192 graphics but only for bw pictures (the mentioned at 86th page demo shows only bw at OS GUI). 80 chars screen is a big advantage but it is not the feature of the base system - http://en.wikipedia.org/wiki/Apple_80-Column_Text_Card - Commodore might release card with functionality of C128 80 chars mode.
|
|
Posted By
JamesD
on 2013-08-05
13:17:07
| Re: Z80 GUI: SymbOS
Apple II a closed system? Say what? It was documented inside and out even down to the hardware logic. The first Apple II came with schematics and even some assembly listings.
Did you try to download a manual for any DOS listed on those pages?
The numbers will vary by DOS version for one thing.
If you can't find numbers anywhere, you can take another approach.
What is the rotation speed of the disk?
How many sectors are on a track and how much does a sector hold?
Do some math and you'll have an estimate of the data transfer rate.
After transfer the CPU has to deal with the data. Look at the info on interleave and you should be able to figure out how long it takes to decode a sector. This will let you calculate throughput... which the articles pretty much stated was different for every DOS version so stick with what people actually use, DOS 3.3 or ProDOS.
The decoding is actually faster than that but it's a moot point since the DOS won't read anything before the start of next available sector after it's done decoding.
That will give you an estimate but it doesn't account for alternate DOS versions, DOS speedup patches, etc... and yes, those do exist but not everyone used them. Patches were listed in magazines, newsletters, etc...
Clearly, any floppy numbers you get are strictly worst case with standard DOS and you are comparing VS fast loaders on the +4. Hardly a fair comparison.
Consider this...
Apples weren't all 1MHz. The IIc+, IIgs, Laser 128 or even machines with a Zip chip could all use a patched DOS to use a different interleave and high speed cpu during decoding.
Apples had hard drives attached to them before the +4 even existed and you have different transfer rates. Early drives used custom DOS but later things with through Apple's DOS. Stuff loads almost instantly from my CFFA board using DOS 3.3 or ProDOS.
|
|
Posted By
Litwr
on 2013-08-05
14:37:22
| Re: Z80 GUI: SymbOS
Thank you! However your message illustrates the way in which Apple II is closed. What is the disk drive speed?! Look at wiki articles for 1541 or 1551 Commodore drives - they provide us with information. I looked at hundreds of lines of Apple II drives texts and found nothing! So I used book in Russian about Apple clone to find that drive rotation speed is 5 per sec. This gives theoretical maximum 1280 bytes per second and this allows to make the conclusion that speed should be close to C1551 but it is only speculation. You mentioned different drives models but... What are their speeds? It looks like a magic mystery. IBM PC compatible computers always give us tons of benchmarks...
|
|
Posted By
MMS
on 2013-08-05
16:12:33
| Re: Z80 GUI: SymbOS
It is an interesting offtopic.
what kind of speed we should expect, if no SD media involved?
so 1551 (without fastloader) should not be treated a slow one? As i remember 1541 has ~400 byte/second continious read, and it was treated snail speed. 1551 should have 1000 byte/sec. Really faster, but still not cheetah
what i saw on the Apple video seems much faster (load and save), and as i see no Hdd involved. theoretically should have the same speed as 1551.
btw one thing i do not get. It was told, that the slow floppy reading of c64 caused by a hw bug (design issue), and some data encoding done from SW, not from hw. With correct hw speed would have been 4x faster on c64 with 1541. Questions:
-if it is such a simple issue, why it was not solved in Plus/4,if they already designed a TED?
-without fastloader 1541 uses 1 data line, 1551 uses 8 paralelly. So what made so wrong, that 1551 ONLY 2.5x faster?
|
|
Posted By
gerliczer
on 2013-08-06
02:19:11
| Re: Z80 GUI: SymbOS
Hi MMS,
The hardware issue you talking about came up on the drive side therefore whatever they would've done on the computer side it wouldn't have helped. I remember something about the serial transfer portion of VIA 6522 not being reliable and sometimes omitting the last bit of data to be transferred.
I think that your assumptions about theoretical speeds of various drives are too simplistic. Regarding the Commodore drives, you could do similar test I described in one of my previous posts. plus4emu or YAPE do quite thorough job with drive and system emulation. Although a complete test would involve placing files into the disk images at different track ranges with different sector interleaves which consume significant time. If you are not willing to spend yours you should try to find someone who already done this. The Internet covers vast amount of knowledge on every imaginable and unimaginable subjects.
|
|
Posted By
Litwr
on 2013-08-06
09:55:15
| Re: Z80 GUI: SymbOS
400 bytes per second is the ideal case for C1541 like as with 64hdd. The average C1541 speed is about 300-350 bytes/sec. IMHO the only way to know why C1551 is much slower than it should be is to ask somebody from the Commodore +4 developers' team (Bill Herd, ...). It also curios why CBM stopped to produce their excellent for capacity and speed 8050 and 8250 drives - IMHO it can be easily adapted for C+4 IEC interface.
|
|
Posted By
JamesD
on 2013-08-07
06:22:49
| Re: Z80 GUI: SymbOS
@Litwr
It doesn't mean the system is closed, it just means you didn't do the math
Drives rotate at 300rpm
300 / 60 = 5 revolutions per second
DOS 3.1 and 3.2 have 13 sectors per track
DOS 3.3 has 16 sectors per track
Sectors are 256 bytes
13 * 256 = 3328 bytes per track for DOS 3.1 and DOS 3.2
16 * 256 = 4096 bytes per track for DOS 3.3
5 * 3328 = 16640 bytes per second transfer rate
5 * 4096 = 20480 bytes per second transfer rate
etc...
But it's easy from there if you bothered to read the DOS wiki (which I posted a link to) you would find this:
"DOS's RWTS routine could read or write a track in two revolutions with proper interleaving"
20480 / 2 = 10240 bytes per second
*edit*
That's if you don't have to step the head and I didn't screw up the math operating on too little sleep
|
|
Posted By
Litwr
on 2013-08-07
07:59:25
| Re: Z80 GUI: SymbOS
All this math is only pure speculation. Where are benchmark results? The mentioned wiki page contains also the words "Speedups in the LOAD command of three to five times were typical". This information should be also used along with other parameters to get exact math. I gave earlier information that Drive II can read only one sector per revolution. So wiki may give information for other drive or for modernized Drive II.
C1541 has internal transfer rate 40 KB/s (http://www.commodore.ca/manuals/commodore_1541_4040_8050_8250_comparison.htm). Commodore +4 can also use many of type of hard disk drives - http://members.optusnet.com.au/spacetaxi64/HD-HISTORY/C64HD-HISTORY.html
|
|
Posted By
JamesD
on 2013-08-08
11:36:08
| Re: Z80 GUI: SymbOS
There is no speculation, those are the numbers unless you can find an error in my math.
The rotation speed is constant, the amount of data a track can store is fixed for each DOS version and the number of revolutions required to read a track isn't changing except from one DOS to another. I'm assuming that is the optimized DOS btw since everything I've read seems to indicate standard DOS 3.3 or less may only read 1 sector per revolution. Differences in benchmarks after that would involve reducing the head settle time delay before reading again and/or changing allocation of sectors to reduce the number of steps between tracks for a file.
The Wiki is giving the speed for a standard DISK II drive. There are no other floppy drives and hard disks are mentioned separately. My math is also based on floppy specs, not those of a hard drive.
As for modern storage devices...
I have a CFFA compact flash interface and loads are a fraction of what the floppy interface requires. Without the complex encoding/decoding of data, timing data I/O, near instantaneous seek times and almost no delays required between sectors, the I/O routines are much smaller and faster. The driver even lets you take advantage of the 65C02 that comes in later Apple models to speed it up.
The CFFA3000 (which I also have) can use DMA which can transfer a byte every clock cycle which is 1MHz. The CFFA driver hasn't been updated to support DMA yet though... updates have mostly been small optimizations and bug fixes, hopefully DMA will be added soon. The driver supports 65C02 and 65816 optimizations.
FWIW, hard drive interfaces from back in the day could also use DMA. Those require longer seek times than compact flash and some delay between sectors but there is no chance in hell you are going to beat that transfer rate of DMA using the CPU to move data.
*edit*
As for the C64 drive info...
40K / sec huh? Lets do the math and see if that is the case.
300rpm
256 bytes per block
There are 35 tracks
17-21 sectors per track
664 free blocks
Problem one with the info. Blocks and sectors are the same but that's minor.
Problem two... the math doesn't add up.
17 * 256 = 4352 bytes min/track
21 * 256 = 5376 bytes max/track
I'm guessing the 1541 uses a drive controller chip to encode/decode data on the disk so it could read an entire track in one revolution.
Since the rotation speed is the same as the Apple II there are still 5 revolutions per second
5376 * 5 = 26880 bytes or 26K per second MAX for a single track.
4352 * 5 = 21760 bytes or 21K per second MIN for a single track.
There are only two ways the drive could handle 40K / sec internally.
If they count bits used to encode the data on the disk or they are doing a memcopy.
We could do the math for a memcopy but I think it's the first option since the 2nd would be pretty misleading.
I'm not even going to think about calculating bits for MFM or GCR encoding; I dealt with that once on the Amiga to transfer CoCo disks to the Amiga and it's ugly. But I believe the patterns were based on 2 or 3 pulses per bit. 2 * 21K = 42000 so the math is close enough. It's transferring that much data but it's not user data, it's encoded data.
Even at 26K per second, that's not to the computer, it's just to the drive's internal RAM.
Problem number three.
If what I read is correct, the 1541 only has 2K of RAM and you can't even read 1 track of data before transferring it to the main system. It does let you load several sectors though and with the right software (which will take up RAM) it can attempt to always preload the next sectors of a file to maintain peak throughput between the computer and the drive.
*edit*
BTW, I did not include any of the track or sector headers in my calculations.
Disk formats may vary, some systems use the index hole on the disk and some don't, but all of the ones I've looked at use some sort of marker bit pattern at the start of tracks or sectors. Manufacturers might include that in their calculations as well but I only counted user data.
*edit*
Some info on that closed system the Apple II.
The first two links are about Apple DOS and disk formats. It's not for the feint of heart.
http://www.scribd.com/doc/200679/beneath-apple-dos-by-don-worth-and-pieter-lechner
http://www.apple-iigs.info/doc/fichiers/beneathprodos.pdf
Misc documentation
http://www.apple-iigs.info/docaccessoires.php
|
|
Posted By
Litwr
on 2013-08-08
14:07:29
| Re: Z80 GUI: SymbOS
Wow! I dare to repeat words from wikipedia "Speedups in the LOAD command of three to five times were typical". These words mean that you should divide your results at least on 5 to get the standard speed. So you can see that without real data the math is the pure speculation only. BTW we should also think about speed of 1MHz 6502 RWTS routines... Commodore data transfer from disk uses two CPU...
The mentioned earlier hardware man who worked with hundreds of Apples insists that the theoretical maximum for the best Apple II turbo loader is 5 KB/sec. This looks good. C1541 maximum is about 3 KB/s.
I've just checked C1551 theoretical maximum. C+4 can get data at rate about 4 KB/s via standard ROM subroutines through parallel interface. I used emulators in the fast IEC mode to get this result. However if we are using special turbo subroutines then the speed may be much better. As I wrote earlier it may be more than 12 KB/s - it is only MHO.
I didn't write that Apple II has little documentation - I wrote that all huge Apple II documentation contains *holes* for the key information. The disk drive data transfer rate (access time, track to track time, ... - did you use these parameters in your math?) is the key information to the description of such kind of hardware. So Apple II is still closed system in this way .
|
|
Posted By
JamesD
on 2013-08-08
14:28:05
| Re: Z80 GUI: SymbOS
Litwr
By your standard a 1541 would be slower than the cassette port on my CoCo. No speedups on the Apple... no speedups on the 1541. Fair is fair. And ProDOS included optimizations so the argument is total BS anyway.
You are being a total troll.
I didn't say you said the Apple II has little documentation. That's a straw man argument.
You didn't say there were holes, you claimed the Apple II was a closed system. Your exact words troll boy.
FWIW, the drive transfer rate you posted for the 1541 was total BS so it didn't have real drive speed info either. Troll
And I flat out stated my figures didn't include changing tracks so don't try to accuse me of misleading people. I didn't include track changes on either drive.
Once you start shifting from track to track you have to start taking into account worst case situations like having to move the head from track 0 all the way to track 35. You also have to take in to account fragmentation, etc...
Unless your precious benchmarks account for such situations they aren't worth crap anyway. TROLL
BTW, you just pulled a speed estimate right out of your rectum with no mathematical basis whatsoever while accusing me of "speculation" even though I showed my math and you had every opportunity to show me where my mistake was. Guess what? You haven't done that. Also, how about naming this Apple expert you are referencing? How do we know you didn't pull that out of your rectum as well?
TROLL
I'm done wasting my time on you.
|
|
Posted By
Litwr
on 2013-08-09
13:53:01
| Re: Z80 GUI: SymbOS
Thank you again! However I dare again to repeat that 1MHz 6502 can't handle 10 KB/s. Let's see a simple math 1000000/10000=100 cycles or about 30-40 CPU codes for one byte. The code should handle hardware communication, perform decoding, test checksum, put bytes in the proper memory location... I hope that this information may enjoy you. I don't use the word "speculation" this time... I can give you email of the Apple II's expert. Should I? I can give you link to the interesting site made by him - it contains the video at the end of page which demonstrates the Apple II disk reader attached to PC with max speed 10 KB/s but it uses special hardware which allows to read a track by one revolution.
**edit** I don't want to accuse. I am only seeking truth. It is just a discussion. It's helped me to better understand Apple ][ world. However if I can't find obvious system information which is available for other systems then this system is closed for me. I didn't say that it is closed for you.
**edit #2** I've just checked the standard 1551 speed with GEOS. It is close to 4 KB/s.
|
|
Posted By
MMS
on 2013-08-09
18:06:23
| Re: Z80 GUI: SymbOS
wow, i am sorry that this topic become so serious.
about speed. It does not help too much if you have an extreme fast device, but your pc can utilize only 1% of it due to slow interconnection between them.
JamesD, I am pretty sure, that you know more about the systems than me. But calculating theoretical reading speed may completely misleading us from real life performance. 1541 was a good example: based on rotation and track calculations it may read 20000byte/sec, but real life performance is only 400.
If you connect the exactly same SATA3 HDD to a sata1,sata2 or sata3 controller, you may notice completely different reading speeds, though the RPM of the drive is exactly the same! THAT important is the interface, you just neglect to take care, pushing to use the rotation speed calculation.
The same way it is not expected to get 1000mb/s tranfer speed from a hdd connected to a c64 via IEC,just because it has 5400RPM. the handshaking,flag, etc handling too much of the CPU time. With DMA it is different, That's why i found SD (or CF) card connected to eZ80 so interesting.
It is too bad, that Commodore put speed into real focus only after 128&1571.
I know that 1551 was faster, but NOT that much faster as it should be with 8 data lines.
why they did not apply an existing IEE488 interface to Plus/4? More and bigger drives, no additional development cost, same or better speed, compatibility. Anyone who is familiar with development knows how much more it cost to develop and validate something completely new compared to modify something that already exists(in PET range)
|
|
Posted By
JamesD
on 2013-08-10
01:14:30
| Re: Z80 GUI: SymbOS
The problem here is that you guys think the rate is theoretical. It's not. Bits are written and read at a constant speed and the disk turns at a constant speed. That is a fact.
The only way it can be wrong is if:
A) The disk rotations speed is wrong (I confirmed it off an apple ii faq though the 3.5" disks vary rotation speed by track)
B) The sector size is wrong. (it's not though I don't count leading/trailing bytes)
C) The number of sectors per track is wrong (this depends on the DOS version anyway and I confirmed it)
D) The Wiki comment about being able to read a track in two revolutions is wrong.
How fast an Apple can read a file (not just a track) on an Apple II is going to depend on:
A) File size
B) Whether the DOS has to constantly look at the file allocation info on the disk.
This will create additional seeks.
C) How many track seeks must take place and how far those seeks move the drive head.
D) Fragmentation
E) Number of file buffers allocated
F) The sector interleave.
If the info on the Wiki is correct, the Apple II can read a raw sector, decode it while the disk passes the next sector and it will be ready to read the next sector when it gets there. Hence the two rotations of the disk. One to read even sectors (0,2,4,6,7...) and one to read odd sectors (1,3,5,7,9...). I'm talking physical order, not logical.
(this might get confusing)
With 16 sectors per track, the physical order of the logical sectors would be 0,8,1,9,2,10,3,11,4,12,5,13,6,14,7,15.
If it took passing 2 physical sectors to decode 1 sector you would interleave the logical sectors 0,6,11,1,7,12,2,8,13,3,9,14,4,10,15,5 and it would require 3 rotations to read the data of an entire track.
(assuming 16 sectors per track)
If one DOS version can only read one sector per rotation then you divide the max transfer rate per track I listed by 16. If it can only read two sectors per rotation then you divide the transfer rate by 8. Etc... I divided by two since they claimed it could be done in 2 rotations.
At 5 revolutions per second it takes 1/5 of a second to rotate past an entire track or .2 seconds which matches the FAQ.
This section of the FAQ compares loading a game on several DOS versions:
http://www.faqs.org/faqs/apple2/faq/part6/
This section talks about how much defragmenting files speeds up disks.
http://www.faqs.org/faqs/apple2/faq/part7/
And how fast a PC can transfer a file probably won't match how fast an Apple can transfer a file and there is no guarantee the PC will be faster. But you'll notice the Apple manages about 10K per second before adding track stepping, moving data from buffers to their final address, etc...
Given the fact that it only takes .2 seconds for a disk rotation and stepping will be slow, the PC shouldn't be a lot faster than the Apple II. If you have to read an entire 35 track disk you are only adding 35 * .2 or 7 seconds. It's not going to be anywhere near as slow as loading it with one CPU and then transferring it to another over a serial link.
If you compare the Apple vs a computer with a hardware interface that can read the entire track in one rotation, the Apple will clearly be slower but for 64K you are talking 3.2 seconds so it's not very noticeable.
FWIW, the 1551 should be faster than the Apple II Disk II but it doesn't look like the DOS is very optimized based on the Wiki numbers. It may only read one sector per revolution or something.
|
|
Posted By
MMS
on 2013-08-10
01:36:07
| Re: Z80 GUI: SymbOS
@JamesD
Many thanks for the details! It looks rather complex, and I see your point now. As I see,this calculation may be very exaxt on Apple II, but not on Commodore, as it has smart devices, can make data transfer independ from RPM
|
|
Posted By
Litwr
on 2013-08-11
13:35:13
| Re: Z80 GUI: SymbOS
@JamesD
You eventually got a fact - [http://www.faqs.org/faqs/apple2/faq/part6/]. I've just downloaded DOS 3.3 System Master disk and by a2tools got MUFFIN. Its size is 27 sectors or 6397 bytes. So the speed according to the given link is 718 bytes/sec for standard DOS (50% slower than C1551 standard speed) or 2782 bytes/sec for enhanced EsDOS (this is slower that C1541 turbo mode).
It is the real speed - it is not just math speculation! So I have to say that Apple II is not so closed as I thought earlier. :-)
Let's try to calculate maximum speed for 1MHz 6502. If we want to have 10 KB/s data flow then we should get 100 KBit/s of raw GCR-data. It gives us 9 cycles per bit (10 cycles are reserved to the whole byte processing). 9 CPU cycles mean 2-4 CPU instructions which should distinguish 0 from 1 and pack bit into byte. Please make you own conclusion.
Thank you again!
@MMS
I have to repeat that I am astonished by Commodore 8250 drive. It can use 1.1 MB per double density floppy! The gigantic IBM could make 1.2 MB at 1984 only and only for expensive high density media. IBM hardware allows to use only about 800KB for double density disk. So Commodore disk hardware were very advanced for 1980. It is mystery why they stopped to develop and even to use so good technology.
**edit @JamesD
Apple IIc plus has 4MHz CPU. It theoretically allows to read a track per one revolution and got 20 KB/s but the real transfer rate maybe lower. It is very difficult to get real numbers about Apple worlds. :-( Apple IIc plus uses special disk controller so CPU doesn't have to make all things but wiki says that this controller is not necessity for 4MHz mode. Such calculation for C128 2MHz mode should get 10 KB/s but C1571 burst mode gives only 3 KB/s. :-(
|
|
Posted By
MMS
on 2013-08-10
09:24:16
| Re: Z80 GUI: SymbOS
oohh, I though that 1571 burst mode is much faster. As read below, with Geos (i mean with a proper driver) 1551 was faster.
8250: i checked it: looks to big and ugly SFD-1001 is much closer to my taste, and can be connected to IEC and IEE 488 too. Although i am sure that with IEC it is slow
|
|
Posted By
SVS
on 2013-08-10
15:18:37
| Re: Z80 GUI: SymbOS
I have GEOS with 2 1551s (eh eh). Not so fast, sorry MMS
If I well remember the dedicated driver is just a fastloader for 1551 (but I'm not 100% sure). And do not forget that Geos uses VLIR files.
|
|
Posted By
JamesD
on 2013-08-10
16:32:26
| Re: Z80 GUI: SymbOS
Check the speed comparison for loading a game using different DOS versions from the FAQ:
Std DOS 3.3**- 8.9 sec
DavidDOS- 2.8 sec
DiversiDOS- 2.9 sec
EsDOS- 2.3 sec
ProntoDOS v1- 3.0 sec
ProntoDOS v2- 3.0 sec
Even the slowest alternative DOS is almost 3 times faster than DOS 3.3 and the fastest is almost 4 times as fast in that benchmark.
Your benchmark doesn't mention what interleave was used on the disk. With the wrong interleave you can force only 1 sector to be read a rotation which will minimize the disk transfer rate.
Did you copy files to a new disk to make sure the disk wasn't fragmented?
Etc...
As for your 6502 cycles numbers...
Do the math based on your clock cycle estimates. Figure out how many clock cycles you think would be required to read bits from the disk. Now calculate how many bits could be stored on a track with your estimated data rate using the known rotation time of the disk. Is that enough to hold 16 sectors containing 256 bytes each? If the answer is no then your speculation is wrong and something else must be going on.
You appear to be counting cycles per bit. That assumes the CPU is reading bits. It isn't. The Disk II uses a ROM that automatically encodes/decodes the bit stream. This was the ingenious part of Woz's design. It was buried in some of the info on one of the links I posted.
BTW, GCR encoding requires 5 bits for every nibble.
After the last bit of research, I believe the time between reading sectors isn't for decoding, it's for moving the data from the DOS buffer to the destination address.
That implies that wiith a custom DOS that directly reads to consecutive 256 byte memory pages rather than a buffer, you *might* be able to read a track in a single rotation. It wouldn't be very useful for general I/O purposes but for reading in a large block of data in a fixed memory range it could be twice as fast. But that *is* speculation since I haven't looked at the existing DOS code.
|
|
Posted By
MMS
on 2013-08-10
16:46:51
| Re: Z80 GUI: SymbOS
if we talk about speed, it seems 1551 is our best option or 1541/1571 with jiffydos. If we look for newer devices, sd2iec with jiffy look rather promising. From stranger devices the big 3.5" CMD FD-2000 with 1.6MB also works with Plussy (it should be fast as supports Jiffy). Finally the SFD-1001 (1MB capacity 5.25") should work too, as with a special cable can connect to slow IEC.
As option B I found an IEEE488 to IEC adapter that should work, called INTERPOD from Oxford Computer System. But it will be as slow as 1541, though 1MB capacity. So even bulky 8250 may run, theoretically the D9060 Hdd too (although just 5MB, so Sd2iec is better)!
|
|
Posted By
Litwr
on 2013-08-11
13:37:12
| Re: Z80 GUI: SymbOS
@JamesD
Thank to you I'll become an Apple ][ expert soon. You are right I missed disk controller. I was sure that CPU makes all job like at Commodore 1541/1551. So my mathematical speculation proves nothing for Apple ][ drive speed.
@MMS This gives us why C1541/1551 is limited to 4 KB/s. I'm not 100% sure about this result. We should ask disk drive guru (Gaia, IstavanV, Krill, ...) to know truth.
However the facts give us Apple ][ drive speed below 3KB/s. The file MUFFIN is at the distribution disk and can't be severe fragmented.
The interleave may speed up the specific DOS only. The interleave means nothing for an advanced DOS. IMHO EsDOS or DavidDOS are advanced ones. The advanced DOS may read sectors in any order. If sectors 1, 2, 3 were requested, for example, then this DOS may read sector 1, then 3, then 2. This DOS may calculate proper place for each sector in the memory. So it may place the last read sector to the start of data in the memory and the first read sector to the end.
The wiki article about Apple DOS contains the next phrase. ''The Apple IIGS operating system, GS/OS, would eventually employ an even more efficient "scatter read" technique that would read any sector that happened to be passing under the read head if it was needed for the file being read.'' It illustrates the idea given above.
My intention was to know the standard speed with the standard DOS. It is below 800 KB/s - it was good for earlier 80s. So our discussion is about maximum speed to load file. The facts give about 3 KB/s. Any theory without facts is speculation or an exercise of power.
|
|
Posted By
JamesD
on 2013-08-14
15:35:09
| Re: Z80 GUI: SymbOS
I'm not sure I'd refer to them as advanced DOSs. More optimized would be more accurate. I'm guessing they are basically DOS 3.3 with patches and some code moved around at the core. Franklin DOS was basically an Apple DOS with faster read/write routines. Beagle Bros just sold a patch for DOS 3.3. I know one DOS was a series of patches that showed up in some articles. I think it was part of 'Apple Assembly Lines'. I remember several patches were published over time that fixed various bugs. I don't think any pre-GS/OS DOS used scatter reads because it requires the faster clocked 65816 and 16 bit registers.
*edit*
I'm not sure what optimizations ProDOS uses but ProDOS pretty much replaced DOS 3.3 for any applications that were compatible.
Logical sector order does matter for DOS 3.3 based DOSs. You have to order it so the next logical sector arrives right after the DOS is done with the previous logical sector for the shortest delay between sectors.
You can read any interleave on any DOS, it will just impact performance.
This is just a hypothetical example but if DOS 3.3 requires an interleave of 4 and you read that on a faster DOS, it will read at the same speed as DOS 3.3. If a faster DOS requires an interleave of 2 and you try to read it under DOS 3.3, it will run slower because the disk has to rotate all the way around before it can see the next logical sector.
If I remember right, you could also skew tracks. Instead of starting them along the same radius of the disk you could have tracks start part of the way through the rotation. This would allow you to read quicker after a track step since the disk wouldn't have to rotate all the way around to start reading the next track. I'm not sure this will work on other drives.
*edit*
FWIW, I don't think any standard DOS used this. It was used more for copy protection than anything but with a custom loader you could use it as a speedup. I *think* I remember there being a format utility that could create such disks though. I don't know for sure, that was a long time ago.
GS/OS is a standard DOS, and so was DOS 2.
If you want the minimum speed, you need to go with something pre-DOS 3.3 that has fewer sectors per track.
If you want to know what the interface is capable of on a 6502 machine you need to go with a modified DOS.
If you want to know what that hardware is really capable of, you need to use GS/OS.
It certainly wouldn't hurt to know the difference in speed between DOS versions.
*edit*
At the very least you should check ProDOS because it pretty much became the standard from 1983 on and came out before the +4 and the 1551 which you are comparing against.
BTW, I found this comment in a section about ProDOS:
"Another problem with DOS was speed. Since each byte read from the disk was copied between memory buffers three times, much of the disk access time was spent in moving things around in memory."
So transfer speed isn't all you are measuring in DOS 3.3 when you benchmark it, you are measuring 3 memory copies.
FWIW, your "fact" is one benchmark loading one file from a disk with an unknown interleave, with unknown fragmentation and I'm guessing it's hand timed. Not exactly very scientific.
With the Apple II, all you have to do to switch DOS versions is swap disks, it's not like swapping ROMs like JiffyDOS on the Commodore machines. There were fast loader carts but some didn't support high speed writes and they didn't work with all programs.
I do remember a fast loader appearing in a magazine and they had versions for C64, VIC20 and I believe someone ported it to the +4. It's big drawback was that you had to load it from disk before you could use it and it only works on serial drives. The Apple II bootstraps DOS as well but it's over a faster parallel connection.
The 1551 should be able to top 4KB/sec but it's driver is in ROM making it impossible to patch unless you can move it to RAM. Part of the limit on Commodore machines may be that DOS is separated into the computer layer and the drive layer. The 1551 should be able to skip some of the overhead but I'm not familiar enough with Commodore machines insides to really know.
FWIW, if you want higher speeds there are several options.
A drive supporting double sided disks can alternate reading between disk sides and will step less between tracks. A simple bit of logic is usually all that is required to select between disk sides. It only requires setting one signal to select between sides of a disk. Sadly, the only times I saw it used was as a 2nd drive. The CoCo commonly used a drive select line to select sides.
CoCo disk controllers have been modded with faster clocks and some additional logic to support high density. It also requires a custom DOS ROM or people just use OS-9. High density has a higher transfer rate. The more common mod is to use 3.5" disks to get more storage space because it's a simple mod requiring patching the max number of tracks.
Another way to speed up drives in software is disk cache or RAM drive. There were several Apple II programs that used the language card memory or other memory expansions for this. It's not very useful for speeding up loading a single small program but for a lot of reading and writing it offers a considerable speedup. There were custom drivers for various memory cards from different manufacturers or the Apple IIe memory expanders.
Someone even replaced the 4116 RAM chips on an Apple II clone motherboard with 4164's and added some additional logic. The circuit should work with most Apple II/II+ and clone machines. They published code for a RAM disk driver. I'm sure similar things were done or could be done with the +4. It would certainly have more to gain with serial drives but you loose the benefit of caching the directory info. The 1541 itself could cache if it had enough RAM but with the serial connection I'm not sure there would be as much benefit. The 1551 would certainly benefit.
Since the +4 BASIC uses all 64K I think you'd want at least 128K to use cache and you'd want to put the driver in ROM similar to JiffyDOS. For a RAM drive you'd probably want even more RAM.
The Apple IIgs actually includes a RAM drive which is very handy for files that are read or written a lot. I use it for include files and parts of the compiler when I'm using my C compiler on the machine. Due to the number of small files and seeks/reads on a disk drive the performance gain is huge. It requires time to load the drive but once loaded it's very fast. Since buying the CF interface I haven't bothered but the RAM drive should still be still faster. My IIgs has a 4GB RAM expansion card on top of the normal system RAM so I have plenty of RAM.
@MMS,
The 1571 boost mode is actually the original speed Commodore drives were intended to communicate at. Drives would have started up at that speed if it weren't for the VIC hardware bug. Too bad the +4 didn't support it. It's actually the drive I use with my +4.
I've always wondered why they didn't include it as an option all along for future machines.
*edit*
The book 'Beneath Apple ProDOS' says that ProDOS can transfer diskette data at the rate of up to 8K per second.
|
|
Posted By
MMS
on 2013-08-22
16:26:36
| Re: Z80 GUI: SymbOS
Interpod IEEE488 interface on IEC
No SW or ROM modification needed, just plug in SFD1001 or 8250. But it will be as slow as 1541. JiffyDOS for Interpod?
http://mikenaberezny.com/hardware/c64-128/interpod-ieee-488-interface/
I will try to get one working piece and an SFD1001 (maybe repach into nice 1571 housing )
|
|
Posted By
MMS
on 2013-08-22
16:31:47
| Re: Z80 GUI: SymbOS
Ahh, sorry, double posting
Interpod Instruction Manual:
http://www.bombjack.org/commodore/hardware/Interpod_End_User_Manual.pdf
(BTW: how the hell I reached IEEE high capacity disc on IEC from a GUI+ RS232 mouse topic? strange...)
|
|
Posted By
gerliczer
on 2013-08-23
08:28:49
| Reaching strange topics
Hi MMS,
I think it was a community effort. Obviously, committed people can do wonders.
|
|
Posted By
Litwr
on 2013-08-26
07:45:43
| Re: Z80 GUI: SymbOS
@mms
I have to repeat that 8250, 8250lp, sfd-1001 are the best pieces of Commodore hardware. They are the best double density drives forever for our world! If they gave them proper interface (for +4, 128, and even Amiga) and DOS upgrade then these drives might become superpopular. I can imagine that the developer of these masterpieces left Commodore at 1980...
Do you still want SymbOS for our +4? How do you see possibility to use graphics on TED without open sources?
@JamesD
The mentioned Apple ][ expert performed several measurements. He's assured me that the best possible speed during program load is about 5.5 KB/s - this requires the ideal drive and disk conditions, proper DOS and disk interleave. He also reported that it is possible to reach 7 KB/s with the track copier Locksmith.
BTW I had never opportunity to use Apple IIgs - It is very interesting computer too good for our world (like C65) which overwhelming "security reasons" for IT is the real sign of its flaw nature.
|
|
Posted By
MMS
on 2013-08-27
19:03:27
| Re: Z80 GUI: SymbOS
May happen that the TED gfx mode implementation is just the question of a proper $ motivation to an expert, if open source code not available.
BTW I forgot, that SFD-1001 can work with IEC too, if a proper cable used. (I am not sure, but if I remember well, I read it somewhere)
Correction: I was wrong. C64 Wiki says:
"There are a lot of options for connecting a SFD-1001 to a C64 /C128 /C16...
-Different cartridges with IEEE-488 connector.
-Interport for connection on IEC Bus.
-IEC-IEEE488 (firm NLQ)"
Although C64 Wiki had no link, Google helped to find the documentation on a cheap IEC-IEEE488 interface.
If you are interested, it is told to be compatible with JiffyDOS protocol, the only question, which IEEE488 drive is compatible with it?
http://www.zimmers.net/anonftp/pub/cbm/documents/projects/ieee-488/ajni2blt.txt
@ by Jochen Adler NLQ
pictures about the stuff:
http://www.nlq.de/
Ahh, yes, and we should provide the 5V from somewhere else than Joy-port, as it may kill the TED...
Also, you need a C64 to set up the interface (flash the microcontroller and calibrate oscillator).
So, 1MB/disk is on the go :-)
Only the rare availabability of SFD-1001 limits us.
SFD-1001 needs JiffyDOS EPROM for fast transfer :-) Does it exist?
|
|
Posted By
Litwr
on 2013-08-27
11:40:17
| Re: Z80 GUI: SymbOS
The big cash for an expert may allow even z80->6502 code translation. It is also good to realize 320x248 graphics.
|
|
Posted By
JamesD
on 2013-08-27
15:53:01
| Re: Z80 GUI: SymbOS
@Litwr
Funny how your Apple II "expert" story has been amended to include a higher speed for Locksmith now.
You accuse me of speculation but if you look at my math and the 'Beneath Apple ProDOS' book claims, you should notice that when you add a little overhead to the calculated ~10K per second you could very easily end up at 8K per second.
BTW, I think I'll trust the author of that book ahead of your mystery expert. Anyone that looks at the content of that book can clearly see the author knows pretty much everything about ProDOS which I believe makes him an Expert.
|
|
Posted By
MMS
on 2013-08-28
01:39:28
| Re: Z80 GUI: SymbOS
if the expert is an expert only in Z80, it will be hard to get the 6502 solution, though Sabre Wulf prooves it is possible.
i want to get involved two expert: a Hw one for the Z80 card, that may realize Sd or CF card too, also would be nice the iec2iee to get few pieces.
sw to get SymbOS on the ready Z80 card. Gfx, sound and especially file transfer protocol is enough task, i think
|
|
Posted By
Litwr
on 2014-08-27
03:34:58
| Re: Z80 GUI: SymbOS
@JamesD My latest Xlife project shows 1:2.6-2.7 z80:6502 speed ratio. Xlife works with up to 40 KB of data at every its cycle.
@MMS SymbOS is updated at 2014 but for the MSX only. The web browser looks fantastic - much better than one for c64. I've played with CPC6128 SymbOS. It is the great work with the astonishing interface (the disk directories are supported!) but it missed GeoWrite, GeoCalc, ... I can also add that 128 KB RAM allows to launch only several simple SymbOS applications.
EDIT. There are the final results produced by Xlife-8 speed tests.
Commodore +4 at the normal screen mode is close to Amstrad CPC6128 with 3.6 MHz
Commodore +4 at the screen blank mode is close to Amstrad CPC6128 with 5.4 MHz
Commodore +4 at normal NTSC screen blank mode is close to Amstrad CPC6128 with 6.7 MHz
Commodore 64 at normal screen mode is close to Amstrad CPC6128 with 3 MHz
Commodore 128 at 2 MHz mode with 80 columns screen is close to Amstrad CPC6128 with 6.3 MHz
The standard z80 frequency at Amstrad CPC6128 is 4 MHz. So if we will count z80 wait states we give 3.15:1 6502:z80 speed ratio.
|
|
Posted By
JamesD
on 2014-08-29
17:11:52
| Re: Z80 GUI: SymbOS
Thanks for the update.
*edit*
One question, what kind of wait states does the Amstrad have for video RAM access?
I know the Spectrum can have up to 6. The CPU gets access 1 out of every 7 cycles during refresh or something like that.
I have no idea on the Amstrad.
|
|
Posted By
Litwr
on 2014-10-28
01:39:41
| Re: Z80 GUI: SymbOS
Dear JamesD, I am very sorry - I noted you edit lines only today.
Amstrad CPC and PCW wait states system is very easy. It rounds all the instructions time to the upper 4*n states. So JP NNNN will take 12 states, LD A,B - 4 states, etc. The every raster line provides 256 states (64 NOPs - *EDIT*) for CPU. Amstrad CPC has one of the best for the 8-bit world video system with 16 KB RAM. The speed of the video RAM is the same as other RAM or ROM.
Xlife-8 project makes some changes in the Amstrad CPC world - It caused the appearance of the Yagol -
http://www.cpcwiki.eu/forum/news-events/xlife-8-for-cpc6128-is-released/msg86121/#msg86121
http://www.cpcwiki.eu/forum/applications/yagol4cpc-alpha-release/msg88036/#msg88036 :-)
BTW the close work with z80 shows that you are right: the 6502:z80 speed ratio for the updated Xlife-8 is close to 2.4:1 (or 3:1 with Amstrad's wait states). So Commodore 64 Xlife-8's performance is close to Amstrad CPC at 2.8 MHz, Commodore+4 - 3.4 MHz, Commodore+4 with blank screen - 5.1 MHz, Commodore-128 - 6 MHz, PAL Commodore +4 at the NTSC mode - 6.4 MHz.
I have also a question for you. Do you know any reason why the best 8 bit CPU 6809 was so underclocked (only 0.89MHz at the Dragon-32/64 and TRS-80 Color)?
|
|
|
|
Posted By
Litwr
on 2016-08-21
12:14:31
| Re: Z80 GUI: SymbOS
A kind of SymbOS is available for 6502 too.
http://atari8.co.uk/gui/
IMHO it is easy to convert it to +4.
|
|
Posted By
gerliczer
on 2016-08-21
13:04:16
| Re: Z80 GUI: SymbOS
@Litwr Easy to convert? I don't think so. Did you read what the minimum requirements are? Did you read that the author only hopes that one day it will be ready to run on 64k Ataris?
|
|
Posted By
MMS
on 2016-08-21
19:07:35
| Re: Z80 GUI: SymbOS
Thanks for the info!
OFF
I still follow the SymbOS topic, and recently a new project emerged, the ZX Spectrum NEXT with even 7Mhz CPU speed, full backwards compatibility, and will seems to support new GFX modes (bitplane or chunky mode is a great questionmark, but BW (no attribute) 512x192 could do the job required by a GUI or text writer) and native SD card and mouse support.
SymbOS would be a perfect combination with this machine.
Unfortunately the NEXT suffers from the same problem as mentioned: memory. CPCs have a special memory management, and till the time the memory switching is not what the SymbOS can support, the SymbOS will see only 48K, and it is far far less what is required for a modern GUI (even if CPU speed, resolution and mass storage are all OK).
BTW, if someone will able to create bigger external memory upgrade with NO internal modification for C16 and Plussy, it would be a game changer. GEOS (REU) compatibility would be great,
Actually such C16 64K cartridges were available (I went through historical paper magazines, but only the internal)
I do remember, that MIKE mentioned in his blog, that he added a big SRAM via expansion port to Plus/4 was much easier and simplier than he though.
It was back in 2007, but did NOT appear here, althoug SOLDER also confirmed in a a commetns, that it could work.
http://dailly.blogspot.hu/2007/01/plus4-memory.html
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
