PDA

View Full Version : Maximum speed for CP/M?



Dr_Acula
December 2nd, 2008, 03:44 AM
I wonder what the maximum speed is for CP/M? Certainly on the altair simulator on a 2.4Ghz PC I've seen a simulated speed of 200Mhz. But I wonder what is possible on a real board? I've just paired a N8VEM board with a keyboard, small display and started plugging in xtal modules. I have got up to 8Mhz and it is all working, though a few NOPs were needed when talking to the display as it can't keep up! The other components seem to be keeping up though and none of the cmos chips even seem warm.

Screen shot shows MBASIC running and this takes about 1/10th of a second to load.

Did the common 40 pin Z80s max out at 10Mhz? And did all the vintage computers stop at 4Mhz or did they push it a bit further?

I'm just wondering what the limiting factor would be - the CPU? The support chips? The PCB layout?

NobodyIsHere
December 2nd, 2008, 04:23 AM
Hi! I think I heard one of the N8VEM builders (Ken?) used all high speed low power CMOS chips and jacked the speed up to 16 MHz. Apparently it ran very stable which floored me as it was four times the design point. I recall seeing other 10 Mhz and faster SBCs as well.

I was surprised 8 MHz works as well as it does. I am going to get an 8 MHz oscillator and try it on my own SBC and if it works maybe that should be the default speed. The increased speed simplifies real time response and makes working with 500 kbps disk drives (ie 1.44 MB floppies) a lot easier as the FDC can be polled rather than rely on tricks like INT/WAIT or DRQ/WAIT that 4 MHz requires.

Thanks and have a nice day!

Andrew Lynch

Chuck(G)
December 3rd, 2008, 12:20 PM
Heck, there is at least one CP/M kit running with a 50 MHz Zilog EZ80:

http://www.ez80sbc.com/

Dr_Acula
December 3rd, 2008, 02:09 PM
Great link Chuck. Wow - 50Mhz. Reading through the documentation now. A very impressive project.

Chuck(G)
December 3rd, 2008, 03:15 PM
There are also more than a few implementations of the Z80 in FPGA. In particular, ZXGATE (http://zxgate.sourceforge.net/) has a tie-in to the vintage aspect.

Dr_Acula
December 3rd, 2008, 08:38 PM
More great links - thanks! I've never really understood these FGPAs - I gather there are z80 cores but are there cores for other chips, eg uarts, big memory (like 512k) etc? And how does it work with copyright - do you pay a licence fee for certain chips or is this stuff in the free domain?

Chuck(G)
December 4th, 2008, 01:34 PM
More great links - thanks! I've never really understood these FGPAs - I gather there are z80 cores but are there cores for other chips, eg uarts, big memory (like 512k) etc? And how does it work with copyright - do you pay a licence fee for certain chips or is this stuff in the free domain?

There is a large body of open source code, but there are also licensed designs, which tend to be a bit more specialized in function.

The link I gave is all open-source.

CP/M User
December 4th, 2008, 08:25 PM
I guess whatever is the fastest IBM Compatible floating around at the moment is what CP/M will run at! :-D

But maybe a iMac can run CP/M too! And maybe faster again! :-o

Of course in order for CP/M to work it needs a Floppy Disk Drive to run off - 1.44Mb will be fine! :-D This maybe a hindrance though!

wmmullaney
December 5th, 2008, 08:21 AM
Someone did it in virtual PC once, bet that was fast, about 800mHz

Terry Yager
December 5th, 2008, 01:10 PM
From some of the stuff I've seen, I'm inclined to believe that CP/M itself has no speed limitation. I see no reason why it shouldn't go as fast as any hardware it can be run upon. (Anybody have access to a Cray, etc. to test the theory).

--T

CP/M User
December 5th, 2008, 03:50 PM
Terry Yager wrote:

From some of the stuff I've seen, I'm inclined to believe that CP/M itself has no speed limitation. I see no reason why it shouldn't go as fast as any hardware it can be run upon. (Anybody have access to a Cray, etc. to test the theory).

I guess the big question is has anyone ported CP/M to a Cray?

On an IBM based platform, CP/M (as a bootable Operating System) has to run in Real Mode, it only reconises a small area of Hard Disk (is restricted in terms of how big an hard disk is), will only reconise the first 640kb, though 3rd Party Software can access Extended memory (upto 16Mb I believe) for use as a RAM Disk for example. Originally the CP/M made for the IBM PC/XT was restricted to those platforms, to run it on a 286 or greater a patch needed to be applied to CPM.SYS for it to work, generally speaking though many downloads are available now where the patch has been applied to work on faster systems.

There's no real reason why CP/M cannot run on the fastest thing with all other limitating hardware facets addressed - I guess a old Hard Disk will work on a Fast System?

Chuck(G)
December 5th, 2008, 06:37 PM
Which CP/M? CP/M 1.4? 2.2? 3.0? CP/M-86? CP/M 68K? Concurrent CP/M 86?

Given that CP/M is little more than a primitive file management system and an interface to user- or vendor-written I/O routines, it's kind of meaningless to talk about how "fast" it is--the answer is that it's slightly slower than the customer-supplied I/O.

In most 8-bit CP/Ms, disk I/O is performed 128 bytes at a time; that is, if a user wants to read 1K, the user must issue 8 system calls to do it. That's not very fast compared to most operating systems. Console I/O is dribbled through a byte at a time--not very efficient either.

CP/M is what it is--a very simple way to organize physical I/O and organize mass storage into a file system of sorts. A few very basic utilities thrown in completes the picture.

MP/M is a notch above CP/M and actually manages allocation of CPU time slots. GEM provides a nice graphical interface and is closer to what we think of as an operating system today.

CP/M User
December 6th, 2008, 01:23 AM
Chuck(G) wrote:

MP/M is a notch above CP/M and actually manages allocation of CPU time slots. GEM provides a nice graphical interface and is closer to what we think of as an operating system today.

I hardly call GEM anything closer to an Operating System - quite the opposite since it replies heavily on the exterior, just like any Windows system in every regard.

Chuck(G)
December 6th, 2008, 08:49 AM
Chuck(G) wrote:

MP/M is a notch above CP/M and actually manages allocation of CPU time slots. GEM provides a nice graphical interface and is closer to what we think of as an operating system today.

I hardly call GEM anything closer to an Operating System - quite the opposite since it replies heavily on the exterior, just like any Windows system in every regard.

Windows contains support for all of the x86 common peripherals (i.e. DMA controller, clocks) as well as an integrated layered driver structure that would be difficult to separate from the OS without destroying it. It really is meaningful to talk about the "speed" of a version of Windows (or *nix)--i.e., 2K is faster than XP is faster than Vista.

GEM, at least as realized on some platforms such as the Atari ST, is far closer to Windows or Linux than CP/M 2.2 is.

I'm not maligning CP/M--I've used it since 1.3 (on an IMSAI) and probably still have a couple of 1.4 boot disks kicking around. But to talk of it as an operating system in the same sense as what we view as an operating system today is misleading.

To talk about speed that comes about mostly because of a lack of functionality is also misleading. If Windows or Linux or (fill in your favorite operating system) were to do all of its disk I/O in 128-byte chunks to a flat filesystem, like CP/M it'd be glacially slow for the type of tasks most of us do today. Recall also, that CP/M searched the single directory on a disk serially--how fast do you think that opening a file would be today when disks contain tens and hundreds of thousands of files megabytes and gigabytes long?

Sharkonwheels
December 7th, 2008, 02:12 AM
GEM on the CP/M platform, was just an add-on, like how windows was for years.
Up until 2K, they were separable. Even then, and now, you CAN get to GUI-less MS os's.
Try the safe-mode cmd only, and nowadays, the recovery console is a good example.

Granted, CP/M was not as advanced as the OS's of today, but then again, that was 20-30 years ago.

I'm sure there's a way to fire up a cmd-only windows nowadays.

As well, keep in mind we'll be saying the SAME thing about 2K/XP/Vista in 20-30 years.


T

chuckcmagee
December 7th, 2008, 03:11 AM
Hmm, I doubt I will be saying anything in 30 years, unless the reincarnation guys are right!

Chuck(G)
December 7th, 2008, 08:29 AM
GEM on the CP/M platform, was just an add-on, like how windows was for years.

Yes, but there were also closely-OS-integrated versions of GEM, such as on the Atari ST. The underlying OS interface looked more like MS-DOS than CP/M.

CP/M User
December 8th, 2008, 06:52 PM
Chuck(G) wrote:

Yes, but there were also closely-OS-integrated versions of GEM, such as on the Atari ST. The underlying OS interface looked more like MS-DOS than CP/M.

Er yes, GEM on an Atari ST is perhaps closer to an Operating System, I was merely referring to the PC version which has the proper Operating System running behind it - same applies to Windows!

The way you refer to the way CP/M operates is another story if you want to talk about how it accesses it's data in small chunks and it's responce to input! I was on the lines of talking about how quick CP/M is on a CPU which focuses on sheer speed!

Chuck(G)
December 8th, 2008, 08:42 PM
The way you refer to the way CP/M operates is another story if you want to talk about how it accesses it's data in small chunks and it's responce to input! I was on the lines of talking about how quick CP/M is on a CPU which focuses on sheer speed!

Just trying to do an apples-to-apples comparison.

Okay, let's toss out disk access and directory management from the comparison, since CP/M will undoubtedly lose to even (gasp!) Windows as disks get larger and directories get longer.

So, what's left? Well, there's character I/O, but that's one system call per character, which isn't really any faster than MS-DOS and probably slower than Windows (since windows does direct screen drawing).

There's CCP, I suppose, but that's just a very basic command interpreter. MS-DOS's COMMAND.COM embeds more commands in itself, so COPY happens immediately without a load and execute of PIP, for example. MS-DOS will work its way through a batch file much faster than SUBMIT, since all of the batch code is resident and it doesn't have to copy each line to a $$$.SUB file like CP/M does.

My point is that CP/M is no faster and can be slower than other operating systems of the same vintage.

Is there some particular area in which CP/M is faster than anything else?

CP/M User
December 8th, 2008, 10:11 PM
Chuck(G) wrote:


There's CCP, I suppose, but that's just a very basic command interpreter. MS-DOS's COMMAND.COM embeds more commands in itself, so COPY happens immediately without a load and execute of PIP, for example. MS-DOS will work its way through a batch file much faster than SUBMIT, since all of the batch code is resident and it doesn't have to copy each line to a $$$.SUB file like CP/M does.

It's difficult to judge how quickly a DOS Batch file will be when compared to a CP/M submit file - I couldn't say for sure since every Driver has it's own Setup time to process and once it's done it goes back to the next line in each file. A CP/M Submit file can be executed at bootup time just like a batch file as well as having a series of programs to execute within that bootup. -All- operating systems or Operating Environments go through that phase, though Operating Systems like DOS or CP/M work quicker due to programs being smaller or fewer! However DOS is slightly setback because of extra commands built-in, CP/M has fewer however if things like PIP were used frequently the quickest way to run them would be from an RAM drive! :-D (Obviously some time would have to be compromised Copying PIP from a hard disk to RAM drive though), DOS TYPE command AFAIK needs DOSKEY to stop the text I presume? CP/M allows you to CTRL-S to stop the text - perhaps it's a good thing that the text is output slower in CP/M than DOS?! :-D

My point is that CP/M is no faster and can be slower than other operating systems of the same vintage.

Is there some particular area in which CP/M is faster than anything else?

On a PC based system it's handy to have Hardware Interrupts, CP/M v2.2 on a 8bit system doesn't allow FIDDs compared to it's 16bit counterpart (CP/M-86 v1.1), which assists in making programs more modern for such an old Operating System. Setbacks are obviously appartent in High Level programming languages such as Turbo Pascal 3 which throw in unnecessarily code into programs (hence longer loading times), FIDD based programs are very quick - equivalent to DOS TSR based programs.

MikeS
December 8th, 2008, 10:57 PM
CP/M using the first 640K? Misplaced decimal?
Drivers in .BAT files? Usually only in autoexec, if at all.
BATs definitely faster than Submit, probably even in RAMdisk.
DOSKEY to pause TYPE? No PAUSE key on your keyboard?
What's a FIDD?

Chuck(G)
December 9th, 2008, 09:41 AM
I have to admit that I'm having a little problem following this one. Are we talking about CP/M-80 or CP/M-86 or CP/M-68K? The internals of the products are very different; all use a common flat filesystem with multiple directory entries used to extend file size.

As a matter of fact, PC-DOS 1.0 is much closer to CP/M-80 than is CP/M-86, at least in details of system interface. (The filesystem is different, but the system calls related to it and the FCB are dead ringers for CP/M-80.)

Did you know that even in the latest version of Vista, I can write:



mov cl,2
mov dl,7
call 5

to sound a beep in a 16-bit .COM file? Not much difference between this and the 8-bit CP/M-80 version:



mvi c,2
mvi d,7
call 5

Dr_Acula
December 9th, 2008, 01:51 PM
Q: "Is there some particular area in which CP/M is faster than anything else?"

A most interesting point. There is one area where CP/M wins hands down, and that is with boot up times. With a ram chip based disk and an 8Mhz CPU and a small autoexec program, I've got a CP/M machine going from switch on to "ready to use" wordstar or mbasic in one second.

The 2.4Ghz laptop I'm writing this on right now takes 4 minutes - what with all the antivirus software and firewalls and all the other things that need to load first.

I am rediscovering the joys of fast reboots!

CP/M User
December 9th, 2008, 11:48 PM
No, CP/M-86 v1.1 reconises 640k. It's 8bit equivalent CP/M-80 or CP/M v2.2 runs only in 64k.

Yeah I see what you mean - I can run a Mouse.exe program from my autoexec.bat file though - which slows it down!

No, BATs definitely not faster than a CP/M-86 SUBmit file - they appear identical in bootime.

Try pressing the Pause button on a Laptop! :-p

A CP/M-86 equivalent of a DOS TSR. Because CP/M-86 v1.1 was far more advanced than DOS in 1983, a FIDD actually predates DOS TSRs - how long I'm uncertain as I can see no support for TSRs in DOS v2. Theorically a CP/M-86 FIDD maybe the solution to provide more internal functions in CP/M-86, programs can simply be written to run in the background and be come into action when needed - I like the RAMdrive approach personally! :-D

Dr_Acula
December 10th, 2008, 04:21 AM
This evening I've just put together 7 CP/M boards. Running CP/M2.2 with 64k ram and 448k of battery backed 'disk ram'. Clock speeds varied depending on the actual Z80's I had in the parts drawer and vary from 3Mhz to 8Mhz. Baud rate to a terminal is 38k. 32k EPROM has a format program and xmodem - this is the minimum needed to get the ram disk formatted and talking to a PC to download more files. Drive A is the ram disk and drive B is the eprom disk.

I must say, (having started this thread I know), that the speed of the CPU clock is not really a big factor. The two things that I found much more important when debugging all these boards and downloading software was the bootup time, and the baud rate for data transfer.