f



CP/M, CP/M+, PCP/M, MP/M, & Z-System

Please excuse my inexcuseable ignorance, but could someone please tell
me *exactly* what CP/M+ & PCP/M do that CP/M 2.2 doesn't?

I know CP/M+ can handle tons of ram, but how much, and is it really
faster?

Is PCP/M really just menu driven CP/M+?

What does Z-System add?

Is MP/M an OS by it's self, or can it be added to CP/M+ or PCP/M?

Can any of these multitask?

I would also like some detailed info about T/Maker III, supposedly a
combination word proceccor, database & spreadsheet, and "Write Hand
Man" (I may not have the name write) a set of memory resident
accessories.
0
puritan_2076 (115)
9/10/2003 1:04:17 AM
comp.os.cpm 3422 articles. 0 followers. Post Follow

160 Replies
2555 Views

Similar Articles

[PageSpeed] 0

CP/M+ has quite a few features that CP/M does not.  Whether it's faster 
is an implementation issue; the features CAN be used to increase speed 
(sometimes dramatically), but it's up to the implementor to use them 
that way, it's not automatic.

The features include the ability to support larger files and devices, 
the ability to do bank-switched memory, time and date stamping, 
additional user interface features, ability to have a larger TPA by 
bank-switching out part of the operating sytem itself, and support for 
disk buffering and deblocking in the Operating system.  There's more, 
but that memory is over 20 years old.

MP/M and MP/M-86 are separate complete OS', they are not "add-ons" to to 
the single user systems.  These systems do multitask.

Right-hand Man was a competitor to my Perks program, which was basically 
a sidekick-type program (Borland) for non-PC environments (although I 
did a version of Perks for the PC in addition to the version for the 
Zenith Z-100 systems).  It contained functions like a calculator, a 
small text editor, a modem program, a calendar, and ASCII code chart, etc.




Leon Howell wrote:

> Please excuse my inexcuseable ignorance, but could someone please tell
> me *exactly* what CP/M+ & PCP/M do that CP/M 2.2 doesn't?
> 
> I know CP/M+ can handle tons of ram, but how much, and is it really
> faster?
> 
> Is PCP/M really just menu driven CP/M+?
> 
> What does Z-System add?
> 
> Is MP/M an OS by it's self, or can it be added to CP/M+ or PCP/M?
> 
> Can any of these multitask?
> 
> I would also like some detailed info about T/Maker III, supposedly a
> combination word proceccor, database & spreadsheet, and "Write Hand
> Man" (I may not have the name write) a set of memory resident
> accessories.

0
Watzman (133)
9/10/2003 3:39:56 AM
Hello, Leon!

Well, you ask quite a lot of questions in one time...
I am in hurry in this cybercafe, so excuse my short answers.

> Please excuse my inexcuseable ignorance, but could someone please
> tell me *exactly* what CP/M+ & PCP/M do that CP/M 2.2 doesn't?

CP/M 2.2 is now known as the "standard" version of CP/M.
However, you can spot CP/M Old Timers when they notice that
some ways of programming are no longer CP/M 1.4 compatible...
That  means that, for them, CP/M 1.4 was the standard...
(In fact, the only "standard" CP/M disk format was the 8"...)

From your question, it seems that, for you, CP/M 2.2 was the
"standard". So, let us summarizes in one paragraph the differences:

- CP/M+ (usually known as "CP/M Plus") was made specifically
for hard disks and a faster CPU that Zilog never made: the Z-800.
With this powerfuller CPU, it was planned that CP/M Plus would
be still single-tasking, but with the ability of running 3 "background
tasks" (not showing on screen, like spool printing of files, etc).

- PCP/M (usually known as "Personal CP/M") was a counter-attack
from Digital Research against the wave of MSX computers made
by Microsoft and a Japanese society. It is "standard" CP/M 2.2,
but rewritten so has to boot from ROM, and with lots of program
menu-driven (rather than using "command lines" like the famous
"A>command filename.typ").

> I know CP/M+ can handle tons of ram, but how much, and is it really
> faster?

"tons of RAM" is maybe an exaggeration. By separating many,
many things in the BDOS and BIOS into 2 separate parts, called
the "Resident" and "Banked" (BDOS and BIOS), the usage of
top memory (known as FDOS to us, Old Timers) is much reduced.
It also depends on the number of "devices" supported.

You will be interested to know that the CP/M computer providing
the biggest TPA (63 KB) is not a CP/M Plus system, but a custom
version of CP/M 2.2, known as MultiFont CP/M 2.2, which was sold
in Europe by Epson for their Epson QX-10, the best Z-80 CP/M
micro ever made, in my opinion. (On the same QX-10, CP/M
Plus provides 61 KB of TPA.) (On the Amstrad PCW8256, CP/M
Plus provides 60 KB of TPA.)

"Is it really faster?" It depends from the implementations, but,
in general, I would say: YES. The reason is that, everytime
something is read from a disk, a copy is kept in RAM (usually
in one "Banked" area). Example: as long as you don't change
the disk in the drive, CP/M Plus scans the Directory NOT ON
THE DISK, BUT IN RAM!!! If you have the slightest idea of the
difference of speed between a disk access and a memory
access, you will instantly understand that, properly done, CP/M
Plus can "do circles" around a "standard" CP/M 2.2 implmentation
(even on the same hardware: it is only the OS that is different.
CP/M Plus was designed was huge directories used on hard disks).

> Is PCP/M really just menu driven CP/M+?

No. It is booting from ROM and is not copied from CP/M Plus,
but from CP/M 2.2 (althought it has additional BDOS calls,
but that another story, since it was written after Digital Research
had made so much things that you do not mention (like GSX
and CP/NET)).

> What does Z-System add?

The Z-System was a bastard of Unix and CP/M, exactly the same
as MS-DOS 2+ is a bastard of Unix and CP/M. (Technically,
MS-DOS v1 was a clone of CP/M...) Unix fans dismiss it.
CP/M fans find it repulsive. Only those who have not known the
originals can find them attractive.

> Is MP/M an OS by it's self, or can it be added to CP/M+ or PCP/M?

MP/M is a CP/M-compatible multi-user multi-tasking OS.
In my opinion, it is the most impressive piece of software
ever developed on an 8-bit CPU. It could run 4 people
on a single Z-80 at 4 MHz...

(No, it cannot be added to CP/M Plus or Personal CP/M,
which are other (single-user) OSes.)

> Can any of these multitask?

MP/M: yes. There was a 8086 version called MP/M-86,
then the name was changed to "Concurrent CP/M".
Most of the files that can be found on the Internet were
released from archives. The last owner of the rights to CP/M
says that most stuff was lost when Novell was the owner
of CP/M. Also, since Concurrent CP/M was running
on the IBM PC, they refused to release anything that
could still be used inside the last version (called DR DOS).

> I would also like some detailed info about T/Maker III, supposedly a
> combination word proceccor, database & spreadsheet, and "Write Hand
> Man" (I may not have the name write) a set of memory resident
> accessories.

- T/Maker III was, as you said, a combination. But I would said that
it was more a combination of spreadsheet and database. The
problem is that it was not very good nor impressive. Since the
programs doing only one task could contain more data, it faded
into obscurity. Its programmer continued to sold it privately during
many years. It was programmed in C, hence probably its slowness.

- Write Hand Man (WHM) is a mini-root staying in upper TPA.
When you press your system-dependent combination of keys,
you get a menu of some small utilities. (Personally, for a clock,
I prefer to have a clock next to my computer, and as for ASCII
table, I prefer to have it printed on paper...)
(Lee Hart mentioned WHM a short while ago. Maybe he could
provide you with more information, if you ask.)

Wew!

Yours Sincerely,
"French Luser"



0
9/10/2003 12:46:43 PM
Leon Howell <puritan_2076@yahoo.com> wrote:
: Please excuse my inexcuseable ignorance, but could someone please tell
: me *exactly* what CP/M+ & PCP/M do that CP/M 2.2 doesn't?

: I know CP/M+ can handle tons of ram, but how much, and is it really
: faster?

  CP/M Plus supports the use of more than 64k. In theory it could use up
to about 15Mb or so (depending on how you set up the memory paging); most 
implementations give it 128-160k and use whatever else they have as a
RAMdisk.
  The extra memory gets used for disc buffers, so if the buffers are
allocated wisely it can improve disc access times.
  The extra memory allows the use of a bigger BDOS than CP/M 2, with
features such as:
* Date/time stamps.
* Passwords.
* The System Control Block - an area of memory containing internal BDOS/CCP
  settings. Some of these have their own BDOS calls to set/reset them;
  others have to be accessed directly. 
  
  Similarly, the CCP is usually kept in memory rather than loaded in from
disc; it is also bigger than the CP/M 2 version and has features such as 
conditional command execution, based on the return code from previous
programs [I improved this slightly in the Y2000 fixed version]. 

  CP/M Plus also allows programs to remain resident in memory (RSXs) and
uses this to do I/O redirection and to implement the SAVE command.

: Is PCP/M really just menu driven CP/M+?

  No. PCP/M-80 is a version of CP/M 2.2 (it reports version 2.8) with a few 
of the extra BDOS calls from CP/M Plus, and a couple more of its own. It 
requires a Z80 CPU (unlike the earlier versions which also work on the 8080) 
and is designed so that it can be loaded from ROM.   

: What does Z-System add?

  Z-System was mainly for CP/M 2 systems. It consisted of a replacement CCP 
(usually accompanied by a replacement BDOS) which could load additional 
modules with more functionality. These usually included named directories
(ie, giving a drive/user area a title); flow control (conditional execution
of commands); execution of programs from within LBR files; etc. 
  There are a couple of Z-Systems for CP/M Plus, as well. 

: Is MP/M an OS by it's self, or can it be added to CP/M+ or PCP/M?

  MP/M is an OS. There are two versions for 8-bit systems - MP/M I and II. 
They were written between CP/M 2.2 and Plus, and have some of the Plus
features and a further set all of their very own (nearly all the BDOS calls 
numbered 128 and up). 

: Can any of these multitask?

  That's what MP/M does. 

-- 
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)
0
jce (444)
9/10/2003 4:25:41 PM
> Well, you ask quite a lot of questions in one time...

I am in a hurry here at the library.

> I am in hurry in this cybercafe, so excuse my short answers.

I understand.
 
> The Z-System was a <XXX> of Unix and CP/M, exactly the same
> as MS-DOS 2+ is a <XXX> of Unix and CP/M. (Technically,
> MS-DOS v1 was a clone of CP/M...) Unix fans dismiss it.
> CP/M fans find it repulsive. Only those who have not known the
> originals can find them attractive.

Judging by what I've read here and in the Computer Journal, You'd
better leave town for a while...
 
> MP/M is a CP/M-compatible multi-user multi-tasking OS.

That's what I want. Where can I get a copy for my Bondwell Model 2?

> In my opinion, it is the most impressive piece of software ever developed on
> an 8-bit CPU.

You should read about OS-9. It's my other second favorite os. (My
first favorite is Basic.)

> It could run 4 people on a single Z-80 at 4 MHz...

OS-9 does that on a 2 Mhz 6809. It's a lot of fun. How many tasks can
each user run under MP/M? (If it matters, The Bondwell I'm looking for
has 512k and one RS-232C port for a terminal)

> > Can any of these multitask?
> 
> MP/M: yes. There was a 8086 version called MP/M-86,

I think I've had about enough of the i80x86/8. Can MP/M-80 multitask?

Here's some I forgot about: What are RP/M and RCP/M? Is CP/Net as os
or an upgrade? What network protocols does it use?
0
puritan_2076 (115)
9/10/2003 8:39:09 PM
Leon Howell <puritan_2076@yahoo.com> wrote:
> > It could run 4 people on a single Z-80 at 4 MHz...
>
> OS-9 does that on a 2 Mhz 6809. It's a lot of fun.

IIRC, 2Mhz 6809 has at least as much processing horsepower as a 4Mhz Z80.

-- 
Nate Edel					http://www.nkedel.com/
"This is not a humorous tagline."
0
archmage (306)
9/10/2003 11:19:09 PM
> > > It could run 4 people on a single Z-80 at 4 MHz...

> > OS-9 does that on a 2 Mhz 6809. It's a lot of fun.
> 
> IIRC, 2Mhz 6809 has at least as much processing horsepower as a 4Mhz Z80.

I think the 6800, which was developed after the 8080,  is supposed to
have a more efficient instruction set.(Hey look what *intel* did! Of
course we can do better than that...) Naturaly it's not compatible.
The 6809 has a 16-bit execution unit, so it's even faster. Zilog
apparently wanted to be compatible with the 8080, which was more
popular because it was there first. The Z80 is a good chip, especialy
considering what it had to be compatible with. I understand the i8080
was pretty slow compared to most others.

I think for what I want to do, the 4 Mhz Z80 is just as good as the 2
Mhz 6809. I just wish I could find that Bondwell Model 2. Anybody?
0
puritan_2076 (115)
9/12/2003 1:12:11 AM
> > MP/M is a CP/M-compatible multi-user multi-tasking OS.
>
> That's what I want. Where can I get a copy for my Bondwell Model 2?

All the MP/Ms (8-bit and 16-bit) use terminals connected
via PHYSICAL links. So, the first question is: "How much
serial lines can be connected to your computer?" This will
give you (almost) the number of users that will be able to
use MP/M on your system. I am not familiar with the Bondwell,
but I am afraid that it was not designed to handle several
serial interfaces (or has not the ability to receive several
cards, one for each additional user).

By the way, one of the regular of the comp.os.cpm Newsgroup,
"Bruce", want to design and build a small batch of MP/M II
systems... If you really want a MP/M II system, you could
add yourself to his customer list, and ready your money.
(For details, read the "New Z80182 System Progress" thread.)

(Else, the only way will be to find one old MP/M II system
still in working condition... Good Luck!)

> > In my opinion, it is the most impressive piece of software ever
> > developed on an 8-bit CPU.
>
> You should read about OS-9.

I know about the OS-9. But it does not run CP/M...

> Here's some I forgot about: What are RP/M and RCP/M? Is CP/Net
> an OS or an upgrade? What network protocols does it use?

You really ask lots of questions!

RP/M: I don't know. I know a TP/M, which was a clone of CP/M
on the Epson QX-10, but don't remember a RP/M.

As far as I know, "RCP/M" stands for "Remote CP/M system".
It was a CP/M-based bulleting board that you accessed with
XMODEM (typically), and left with BYE.

CP/NET is a Local Area Network (LAN) Operating System.
It is a set of subroutines that loads high in the TPA, and adds
new BDOS functions (dealing with the Network) to a CP/M 2.2
computer. It is also provided with a set of program to set up
the Network, "attach to the network", "detach", and send mail
to another "node" of the CP/NET (or DR NET) Network.
(But it dates from 1983, and its protocol (more or less based
on the Intel HEX file format) is almost certainly not recognized
by current Network hardware or software running under
Windows and Unixes.)

Wew!

When will it be your turn to say anything?

For example, about your Bondwell...

Yours Sincerely,
"French Luser"



0
9/12/2003 10:55:46 AM
Leon Howell <puritan_2076@yahoo.com> wrote:
> course we can do better than that...) Naturaly it's not compatible.
> The 6809 has a 16-bit execution unit, so it's even faster.
>
> Zilog apparently wanted to be compatible with the 8080, which was more
> popular because it was there first.

Didn't the original Zilog engineers come from Intel?  Or is that apocrypha? 
In any case, 8080 done better seems to have been the Z80s reason for being
(and it did a much better job of it than the 8085, from my memory.)

> I think for what I want to do, the 4 Mhz Z80 is just as good as the 2
> Mhz 6809. I just wish I could find that Bondwell Model 2. Anybody?

I never used the 6809, just read about it, but the big advantage to the Z80
is the amount of software already written for it.  And writing in assembly
was a lot easier in the Z80 than the 6502 which has a _really_ minimal
register set.  I can't remember how the 6800 or 6809 were, since I never
worked with aseembly for either.

-- 
Nate Edel					http://www.nkedel.com/
"This is not a humorous tagline."
0
archmage (306)
9/12/2003 9:15:43 PM
Nate Edel wrote:
> 
>         [snip...]        [snip...]         [snip...]
> 
> I never used the 6809, just read about it, but the big advantage to the Z80
> is the amount of software already written for it.  And writing in assembly
> was a lot easier in the Z80 than the 6502 which has a _really_ minimal
> register set.  I can't remember how the 6800 or 6809 were, since I never
> worked with aseembly for either.
> 
IMHO the 6809 had a wonderful instruction set...especially
compared to the Z80 or 6502...or even the 6800. I encourage
you to Google the "MC6809" and read up on it...

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+
0
richmond (35)
9/13/2003 5:47:41 AM
archmage@sfchat.org (Nate Edel) wrote in message news:<vkp931-l3o.ln1@mail.sfchat.org>...
> I never used the 6809, just read about it, but the big advantage to the Z80
> is the amount of software already written for it.  And writing in assembly
> was a lot easier in the Z80 than the 6502 which has a _really_ minimal
> register set.  I can't remember how the 6800 or 6809 were, since I never
> worked with aseembly for either.

6502 was a 6800 clone IIRC.

-uso.
0
steve92 (61)
9/13/2003 11:56:43 AM
Leon Howell wrote:
> I would also like some detailed info about T/Maker III, supposedly a
> combination word proceccor, database & spreadsheet

I have "T/Maker" for CP/M-80, and used it for years. T/Maker for PC-DOS
was called "T/Master". It doesn't appear that they marketed versions
with different suffixes (I, II, III etc.), but they did sell variations
of the program for other computers, giving it various names (REPO,
GemWriter, and Tsitsuga, to name a few).

TM (for short) is a very interesting program. It is perhaps the very
first "integrated" program that combined an editor, word processor,
spreadsheet, spellchecker, database, etc. into a single package that had
logical consistent rules throughout.

The heart of TM is a text editor. Like Wordstar, HTML etc. it has a rich
array of special strings of characters that you put in your text that
tell TM what you want done with the file. Then, there are dozens of
'report generators' that read your text file, perform the desired
operations, and produce an output text file that you can print, do
further editing on, etc.

If you need more information, manuals, a demo, or the software itself,
email me directly.

> and "Write Hand Man" (I may not have the name write) a set of
> memory resident accessories.

Yes, you have the name right. It was written by Alan Bomberger at Poor
Person Software. I considerably enhanced it for the Heath/Zenith
H8/H19/H89 family of computers. Others did the same thing for Kaypros,
Osbornes, etc.

WHM (for short) is basically a 'Sidekick' clone for CP/M-80 computers.
It is a little TSR (terminate and stay resident) program that creates a
tiny reserved space in memory (about 5k) and then lives in it.

The memory-resident portion of WHM watches all keyboard input for a
'hot' key. When you type it, even while any other program is running,
WHM saves the state of the BDOS, and displays a menu of little utility
programs. There are utilities for a notepad, phonebook with dialler,
calculator, disk directory, etc. When you're done using these utilities,
WHM restores the BDOS and resumes executing whatever program was
running.

So (for example) I can be running Wordstar, and realize I need your
address. I hit the BREAK key (the 'hot' key on my H89), and the WHM menu
pops up. Press 4 for the PHONEBOOK utility, and I get what looks like a
Rolodex file on the screen. Press the FIND key and your name, and it
jumps to the page with your name. Press the COPY key to copy the address
to a clipboard. Now press ESCAPE to exit WHM, and I'm right back in
Wordstar, right where I left off. Press the PASTE key and the string of
text with your address is 'typed' in automatically; Wordstar inserts it
just as if I typed it on the keyboard.

I have WHM too, in case anyone is interested.
-- 
Lee A. Hart                Ring the bells that still can ring
814 8th Ave. N.            Forget your perfect offering
Sartell, MN 56377 USA      There is a crack in everything
leeahart_at_earthlink.net  That's how the light gets in - Leonard Cohen


0
leeahart (232)
9/13/2003 9:08:46 PM
Nate Edel wrote:
> Didn't the original Zilog engineers come from Intel?

Yes. Federico Faggin was a lead engineer at Intel on the design of the
4004 thru 8080. Intel had (and still does have) a habit of always trying
to 'fire the first shot'; rush to release a chip that isn't really
perfected yet, just to grab the market.

Faggin figured this was stupid; it condemns you to always have the worst
chip on the market, and others will always take the market away from you
as soon as they get their product out. He couldn't convince Intel to
change, so he quit and started Zilog in 1974, taking a number of
engineers with him. The idea was to create a chip that was well enough
designed to have 'staying power' in the market. He succeeded; the Z80 is
the only CPU of that age that is still in mass production.

>> I think for what I want to do, the 4 Mhz Z80 is just as good as the
>> 2 Mhz 6809.

It's hard to compare clock speeds of various CPUs. The Z80 to divide its
clock by about 4 ('about' because bus cycles can be 3,4,5 or more clock
cycles). The 6800/6502/6809 generally divide their clocks by 1 (though
some versions divide it by 4). So a "4 MHz" Z80 is roughly the same
speed as a "1 MHz" 6800/6502, because they are runnning at about the
same actual rate of instructions per second.
-- 
Lee A. Hart                Ring the bells that still can ring
814 8th Ave. N.            Forget your perfect offering
Sartell, MN 56377 USA      There is a crack in everything
leeahart_at_earthlink.net  That's how the light gets in - Leonard Cohen


0
leeahart (232)
9/13/2003 9:08:48 PM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote in message news:<bjs867$v39$1@news-reader5.wanadoo.fr>...
> RP/M: I don't know. I know a TP/M, which was a clone of CP/M
> on the Epson QX-10, but don't remember a RP/M.

RP/M was a hack of CP/M and a Z80/Z280 emulator to run it on a PC. 
ISTR it being available from www.cpm.z80.de.  I don't know if this is
what he's referring to, but I would suspect it might be.

-uso.
0
steve92 (61)
9/14/2003 6:53:38 AM
"Lee Hart" wrote:

> I have "T/Maker" for CP/M-80, and used it for years. (snip)
>
> TM (for short) is a very interesting program. It is perhaps the very
> first "integrated" program that combined an editor, word processor,
> spreadsheet, spellchecker, database, etc. into a single package that had
> logical consistent rules throughout.

Lee, why not find its author, and ask him if he would mind releasing
its source code, or making a CP/M-86 version?

(It is funny how somebody who loves a software (like you)
can make it interesting... You should set up a Web page
dealing with it and your tricks!)

Yours Sincerely,
"French Luser"



0
9/16/2003 1:00:28 PM
> > All the MP/Ms (8-bit and 16-bit) use terminals connected
> > via PHYSICAL links.
>
> Does the built-in display & Keyboard count as a "physical" link?

No. This is what was implied by my use of the word "terminal"
(or "console", if you prefer). It must be able to display the characters
that it receives, and able to send back your commands. The
advantage of the teletype is that it leaves a trail of everything
displayed/typed on paper. The MP/M system can have its
own terminal but, usually, this is just one of the available terminals.
A reliable MP/M system can perfectly runs without a terminal,
just with terminals connected to it (for example, from another room).

> (...) What's MP/M II?

Version 2 of MP/M.

> > CP/NET is a Local Area Network (LAN) Operating System.
> > It is a set of subroutines that loads high in the TPA, and adds
> > new BDOS functions (dealing with the Network) to a CP/M 2.2
> > computer.
>
> Can it be added to MP/M?

Yes, of course. As a matter of fact, CP/M 2.2 "nodes" can only
be "requesters". Only a MP/M system can be a "server".

The last version of CP/Net, Version 1.2, is compatible with
DR Net, so one Linux box running DR Net could be a
gateway to the Internet for a Network of CP/M 2.2 systems...

Yours Sincerely,
"French Luser"



0
9/17/2003 12:03:09 PM
> No. This is what was implied by my use of the word "terminal"
> (or "console", if you prefer

So is it even possible to run MP/M on, for example, a Kaypro or
Bondwell with enough ram but no terminal connected?
0
puritan_2076 (115)
9/17/2003 6:53:00 PM
Excuse me, Leon, but why are you insisting so much on
using a Bondwell 2?

I finally had a look to it on the Internet.

From what I have read, this is just a portable.

It is very far from the standard CP/M systems based
on the S-100 Bus standard (which would allow you
to easily add as much terminals as you want).

The only reasonable use I can think of your Bondwell 2
would be as a serial terminal running CP/NET v1.2
under CP/M 2.2, not as a MP/M II server.

(As far as I know, the company which built the biggest
number of MP/M systems is ALTOS. If I were you,
I would hunt for one of them in the USA.)

(By the way, if you are so much interested in MP/M,
you could open a Web site specialized in it... As far
as I know, the MP/M II guides are not online on the
Internet. However, CP/NET v1.2 is, along with CP/M 2.2,
on the Web pages of Roger Ivie. You will notice that
all the CP/NET doc mentions S-100 Bus cards...)

(I have heard that the company selling "Imsai mark 2"
systems would like to add a MP/M and CP/NET options
to its range of products (maybe this could interest you).
But they are probably much more expensive than a
second-hand ALTOS. However, they should run faster.)

Yours Sincerely,
"French Luser"



0
9/19/2003 10:41:32 AM
On Sat, 13 Sep 2003 21:08:48 GMT, Lee Hart <leeahart@earthlink.net>
wrote:


>Faggin .........................................
> ....................................................... started Zilog in 1974, taking a number of
>engineers with him. The idea was to create a chip that was well enough
>designed to have 'staying power' in the market. He succeeded; the Z80 is
>the only CPU of that age that is still in mass production.

Lee;

Seems to me the RCA/Hughes 1802 is still being made/used, too,

And fur sure, as that's a CMOS part, that's the chip technology
we're all using these days; any idea what the first Intel parts
were? BTW I recently came across some 6502 CMOS parts.

I know I had some 8088 parts in CMOS, but wasn't that an NMOS
part originally? Maybe some NEC parts were also CMOS in the
early x86 line.

Check your Z80 references - I'd bet there aren't any 'current'
ones still being made in NMOS. Or PMOS. Or whatever.

Bill

0
Bill3039 (326)
9/20/2003 5:26:06 AM
> Excuse me, Leon, but why are you insisting so much on
> using a Bondwell 2?
> 
> I finally had a look to it on the Internet.
> 
> From what I have read, this is just a portable.
> 
> It is very far from the standard CP/M systems based
> on the S-100 Bus standard (which would allow you
> to easily add as much terminals as you want).

I don't need that many terminals, I just want to try it with one or
two. Mostly I want the multitasking.

First I need a good laptop. I like the Bondwell 2, Tandy Model 200,
and NEC PC-8500. They all have similar features, exept that the B2 has
nothing in rom. But it's expandable to 512k! In a laptop! And since it
runs CP/M, you can really *use* that 512k! True, other CP/M, Basic,
and OS-9 computers are expandable to 512 or more, but do they run on
batteries? Can you hold them in one hand and type with the other? I
doubt it, but if so, tell me about them. While you're at it, tell me
about this JONOS you like. I can't find anything about it on the
internet.

So, is it possible to run MP/M on a Bondwell, Kaypro, NEC, TRS-80,
etc., using the main console, no terminals, just multitasking?
0
puritan_2076 (115)
9/20/2003 10:39:04 PM
Salle Arobase wrote:
> > I have "T/Maker" for CP/M-80, and used it for years. (snip)

> Lee, why not find its author, and ask him if he would mind releasing
> its source code, or making a CP/M-86 version?
> 
> (It is funny how somebody who loves a software (like you)
> can make it interesting... You should set up a Web page
> dealing with it and your tricks!)

Yes, I did enjoy using T/Maker. It did a lot of very clever tricks, and
really was powerful and easy to use once you figured out how it did
things.

Remember the discussions a while back on whether HTML or Wordstar files
was a 'language' or not? Well, T/Maker files looked like and acted like
plain old ASCII text files; but they *were* certainly a programming
language! 

As to why not find the author, or create a web page... well, it's simply
not worth my time. I can write this email in a few minutes, but it would
take hours to try to find the authors, and days to set up any kind of
web page for it.
-- 
Lee A. Hart                Ring the bells that still can ring
814 8th Ave. N.            Forget your perfect offering
Sartell, MN 56377 USA      There is a crack in everything
leeahart_at_earthlink.net  That's how the light gets in - Leonard Cohen


0
leeahart (232)
9/21/2003 7:47:20 AM
> I think I've had about enough of the i80x86/8.

On the other hand,I can't afford international shipping, but I do have
a Tandy 1400LT, with a V20 and 768k. How much ram do CP/M-86,
PCP/M-86, CP/M-86+, and MP/M-86 take? What about DR-DOS (a.k.a.
Concurrent CP/M-86) & GEM, (especialy an early version from before
Apple sued DR) or IBM PC/IX?

How many applications can these multitask? Will the OS and a good
application package fit on a 720k floppy?
0
puritan_2076 (115)
9/22/2003 11:52:16 PM
ALTOS.TXT
---------

"Multi-user microcomputer"
 Interface Age, October 1981, p.134

(Retyped by Emmanuel ROCHE.)

The Altos ACS 8000-10 combines 10M bytes of hard-disk storage
with floppy disk or magnetic tape back-up media. The Zilog
Z-80-based system integrates the Altos single-board computer and
DMA controller with an 8-in. hard disk into a compact unit.
Mounted in a standard 19-in. rack, the system has 208K bytes of
internal RAM, giving enough power to accomodate up to four users
and expand with the needs of the small business. The system has
six programmable serial ports, an RS-432 communication port and
handles network data rates at up to 800K baud. It is based on
CP/M and MP/M operating systems, making the computer compatible
with most end-user (application) software. Price: $8,500 with
single-sided floppy disk, $9,500 with double-sided floppy disk
and $10,990 with magnetic tape cassette. Altos Computer Systems.


"Suppliers of multiprocessor equipment"
 Interface Age, June 1982, p.92

For personal computers and multiprocessor systems operating in
the CP/M and MP/M environment, Digital Research has developed
several network-oriented operating systems: CP/NET and three
related systems, CP/NOS, MP/NET, and MP/NOS.

CP/NET allows microcomputers to share and transfer disk files,
to share printers and consoles, and to share programs and data
bases. It consists of masters running on MP/M and slaves running
on CP/M. The masters are hosts that manage the shared resources
that can be accessed by the network slaves.

CP/NOS is a diskless CP/M that can be stored in solid state ROM
-- operating with a console, memory, and network interface.

MP/NET is a complete MP/M system with an embedded network
interface. Like CP/NET, it allows local devices to be
re-assigned to the network. MP/NET configurations allow MP/M
systems as both requesters and servers with CP/M requesters.

MP/NOS contains the real-time portion (RTM) of MP/M without
local disk facilities. Like CP/NOS, MP/NOS performs all disk
functions through the network.

A unique operating system configuration, MP/M-8/16 by G&G
Engineering (San Leandro, CA) is a proprietary implementation of
Digital Research's MP/M-86. It allows for simultaneous running
of both 8- and 16-bit processors in a multiuser, multiprocessing
environment. The system is used in conjunction with the
8085/8088 CPU board by Godbout (Oakland, CA).


EOF



0
toto7481 (3)
9/23/2003 1:47:48 PM
ALTOS.TXT
---------

"Multi-user microcomputer"
 Interface Age, October 1981, p.134

(Retyped by Emmanuel ROCHE.)

The Altos ACS 8000-10 combines 10M bytes of hard-disk storage
with floppy disk or magnetic tape back-up media. The Zilog
Z-80-based system integrates the Altos single-board computer and
DMA controller with an 8-in. hard disk into a compact unit.
Mounted in a standard 19-in. rack, the system has 208K bytes of
internal RAM, giving enough power to accomodate up to four users
and expand with the needs of the small business. The system has
six programmable serial ports, an RS-432 communication port and
handles network data rates at up to 800K baud. It is based on
CP/M and MP/M operating systems, making the computer compatible
with most end-user (application) software. Price: $8,500 with
single-sided floppy disk, $9,500 with double-sided floppy disk
and $10,990 with magnetic tape cassette. Altos Computer Systems.


"Suppliers of multiprocessor equipment"
 Interface Age, June 1982, p.92

For personal computers and multiprocessor systems operating in
the CP/M and MP/M environment, Digital Research has developed
several network-oriented operating systems: CP/NET and three
related systems, CP/NOS, MP/NET, and MP/NOS.

CP/NET allows microcomputers to share and transfer disk files,
to share printers and consoles, and to share programs and data
bases. It consists of masters running on MP/M and slaves running
on CP/M. The masters are hosts that manage the shared resources
that can be accessed by the network slaves.

CP/NOS is a diskless CP/M that can be stored in solid state ROM
-- operating with a console, memory, and network interface.

MP/NET is a complete MP/M system with an embedded network
interface. Like CP/NET, it allows local devices to be
re-assigned to the network. MP/NET configurations allow MP/M
systems as both requesters and servers with CP/M requesters.

MP/NOS contains the real-time portion (RTM) of MP/M without
local disk facilities. Like CP/NOS, MP/NOS performs all disk
functions through the network.

A unique operating system configuration, MP/M-8/16 by G&G
Engineering (San Leandro, CA) is a proprietary implementation of
Digital Research's MP/M-86. It allows for simultaneous running
of both 8- and 16-bit processors in a multiuser, multiprocessing
environment. The system is used in conjunction with the
8085/8088 CPU board by Godbout (Oakland, CA).


EOF



0
toto7481 (3)
9/23/2003 1:51:15 PM
> > > All the MP/Ms (8-bit and 16-bit) use terminals connected
> > > via PHYSICAL links.
> >
> > Does the built-in display & Keyboard count as a "physical" link?
> 
> No. 

So It's impossible to use MP/M-86 on a Tandy 1400LT with no serial
terminal? Isn't there any kind of patch? (Stupid question:Would GSX
help?) I only need one "terminal", It's the multitasking I really
want.
0
10/17/2003 1:37:56 AM
> > > > All the MP/Ms (8-bit and 16-bit) use terminals connected
> > > > via PHYSICAL links.
> > >
> > > Does the built-in display & Keyboard count as a "physical" link?
> >
> > No.
>
> So It's impossible to use MP/M-86 on a Tandy 1400LT with no serial
> terminal? Isn't there any kind of patch? (Stupid question:Would GSX
> help?) I only need one "terminal", It's the multitasking I really
> want.

In this case, Digital Research made a later version of MP/M-86
named Concurrent CP/M, whose main difference (at the
beginning) was that it provided "virtual consoles" (instead of
"physical consoles"). (This was done because of the limitations
of the hardware of the IBM Clown.)

That is to say: Typing Alt-1 would display the screen of console #1,
Alt-2 would display the screen of console #2, etc, up to Alt-4.

Unfortunately, no copies of the binaries of the files of Concurrent
CP/M Release 3.1 for the IBM PC have been found, so far.

Maybe this thread will produce something?

(The best Operating System is useless without good software.
Me, what I would like to find is WS4 for CP/M-86...)

(GSX would not help, since its only purpose is to provide
a PORTABLE graphics system.)

Yours Sincerely,
"French Luser"



0
10/17/2003 10:47:01 AM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote

> In this case, Digital Research made a later version of MP/M-86
> named Concurrent CP/M, 

While CCP/M derived from MP/M it wasn't a 'version' of it.

> whose main difference (at the
> beginning) was that it provided "virtual consoles" (instead of
> "physical consoles"). 

No. Wrong.  CCP/M-86 version 1 was intended as a multi-tasking
replacement for CP/M-86 and was single user, that was a significant
difference too.  Later they added back multi-user.

> (This was done because of the limitations
> of the hardware of the IBM Clown.)

There was nothing about the 'limitations' of the IBM PC.  In fact the
memory mapped display aided the implementation of the virtual screens.
 Screens could be changed by simply copying 4kb from the virtual
screen to the video card.  On other machines the whole sequence of
serial terminal escapes would have had to be done.  This was too slow
and complicated.  Most CCP/M-86 machines ( eg ICL Quattro and DRS300)
used semi-intellegent serial terminal that supported holding the
virtual screens in the terminal for fast switching.
 
> That is to say: Typing Alt-1 would display the screen of console #1,
> Alt-2 would display the screen of console #2, etc, up to Alt-4.

MP/M-86 also had the ability to multi-task by switching between
sessions on a single console with Ctrl-D.

> Unfortunately, no copies of the binaries of the files of Concurrent
> CP/M Release 3.1 for the IBM PC have been found, so far.

What's your point ?  CCP/M-86 started at release 1.x and went up to
6.2 for the IBM PC-XT.  3.1 was the last version before the name
changed to Concurrent-DOS.  Why do you think it is in any way
'special' ?

CCP/M-86 was developed into CDOS-386 with several significant
improvements, and was renamed as DR-Multiuser-DOS 5 (to benefit from
DR-DOS name).  VAR versions were System Manager from DataPac and
Real/32 from IMS.

> Maybe this thread will produce something?
> 
> (The best Operating System is useless without good software.
> Me, what I would like to find is WS4 for CP/M-86...)

The developers of WordStar left where the corp decided to concentrate
on WS-2000. They formed NewWord and developed what was intended to be
the next 'normal' WordStar.  WS2000 failed and WS bought the NewWord
company and released NewWord as WordStar 4 for the IBM.  NewWord is
WS4 for CCP/M-86, there is almost no difference at all.

> (GSX would not help, since its only purpose is to provide
> a PORTABLE graphics system.)
0
riplin (4127)
10/19/2003 6:54:47 PM
puritan_1620@yahoo.com (Leon Howell) wrote 

> > > > All the MP/Ms (8-bit and 16-bit) use terminals connected
> > > > via PHYSICAL links.
> > >
> > > Does the built-in display & Keyboard count as a "physical" link?
> > 
> > No. 

That depends entirely on the implementation.  MP/M-86 on the IBM-PC
used the memory mapped display as a terminal.
 
> So It's impossible to use MP/M-86 on a Tandy 1400LT with no serial
> terminal? Isn't there any kind of patch? (Stupid question:Would GSX
> help?) I only need one "terminal", It's the multitasking I really
> want.

You would need a version tailored to the machine, or write your own
XIOS. MP/M-86 does do multitasking at one screen, but poorly.  Ctrl-D
gives a new comnmand prompt and allows switching back to the original,
but doesn't stop displays from any of the programs being intermixed on
the screen.  It is useful for background tasks, but needs multiple
terminals to run multiple foreground tasks effectively.  This is why
Concurrent-CP/M-86 is such an improvement.
0
riplin (4127)
10/19/2003 7:03:39 PM
> > In this case, Digital Research made a later version of MP/M-86
> > named Concurrent CP/M,
>
> While CCP/M derived from MP/M it wasn't a 'version' of it.
>
> > whose main difference (at the
> > beginning) was that it provided "virtual consoles" (instead of
> > "physical consoles").
>
> No. Wrong.  CCP/M-86 version 1 was intended as a multi-tasking
> replacement for CP/M-86 and was single user, that was a significant
> difference too.  Later they added back multi-user.

No. Wrong. Do you want me to copy the paragraphs in the CCP/M 3.1
doc? CCP/M cannot be "a multi-tasking replacement for CP/M-86",
since they do not have the same BDOS...

In case you do not know, CP/M-86 was as straight as possible a
8086 implementation of CP/M 2.2, down to its BDOS (ver 2)
(modifying a single-user OS to become a muti-tasking multi-use
OS is a not trivial thing. MP/M II already existed: they made a
8086 version; they never tried to "improve" CP/M-86).

BDOS 3, that I met under CP/M Plus, is the son of the MP/M BDOS,
and was ported to the 8086 (MP/M-86, which used PHYSICAL
consoles, and later Concurrent CP/M, which used VIRTUAL consoles).

I don't know if you know it, but Digital Research decided to develop
Concurrent CP/M, not CP/M-86, when MS-DOS was adopted by
most IBM Clown users.

As far as I know, CP/M-86 was never maintained nor updated by
Digital Research.

In contrast, Concurrent CP/M (son of MP/M-86) certainly was...

Yours Sincerely,
"French Luser"



0
10/21/2003 3:11:04 PM
This is getting very interesting. There may be hope for the pee see
after all.

What are the system requirements of CCP/M-86? How much ram does it
use, and how much do some popular applications take? Is there a good
integrated application package? If so, can I run the whole thing in
640k-768k?
0
10/21/2003 6:34:35 PM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote

> > No. Wrong.  CCP/M-86 version 1 was intended as a multi-tasking
> > replacement for CP/M-86 and was single user, that was a significant
> > difference too.  Later they added back multi-user.
> 
> No. Wrong. Do you want me to copy the paragraphs in the CCP/M 3.1
> doc? 

I suspect that I have far more 'CCP/M' docs than you do, including
references to the version 1 which was single-user.

By the time 3.1 came around it added back the multi-user capability to
be a replacement for MP/M-86 as well.

> CCP/M cannot be "a multi-tasking replacement for CP/M-86",
> since they do not have the same BDOS...

Perhaps you fail to understand what the word 'replacement' means.  All
the CP/M-86 BDOS functionality is in CCP/M-86.
 
> In case you do not know, CP/M-86 was as straight as possible a
> 8086 implementation of CP/M 2.2, down to its BDOS (ver 2)

Geez, do you think I may not know this ?

> (modifying a single-user OS to become a muti-tasking multi-use
> OS is a not trivial thing. MP/M II already existed: they made a
> 8086 version; they never tried to "improve" CP/M-86).

Which is why the word 'replacement' was used rather than the word
'improvement'.

> I don't know if you know it, but Digital Research decided to develop
> Concurrent CP/M, not CP/M-86, when MS-DOS was adopted by
> most IBM Clown users.

Actually, DRI was developing CCP/M-86 well before IBM Clones with
MS-DOS existed. Version 1 was released in Sept 1982, prior to
PC-DOS/MS-DOS version 2 and over a year before any clones were
delivered.

""At the West Coast Computer Faire in March 1982, DRI previewed
Concurrent CP/M-86. [this] allows a _single_user_ to run several
programs simultaneously on the PC, using virtual terminals. ...""
 
> As far as I know, CP/M-86 was never maintained nor updated by
> Digital Research.

The DRI releases of generic CP/M-86 were:

        1.0    January 1981
        1.1    'early' 1982

1.0 lacked DIRS and HELP commands, could not run SYS files in user 0
from other areas and PIP lacked the [G] option.

In what way was the change from 1.0 to 1.1 not 'maintain and update' ?

For the IBM PC the IBM release was March 1982 and this was never
updated or maintained by anyone.  However, because IBM kept the price
at $250, DRI developed its own CP/M-86 for the IBM PC and released it
for $60 in March 1983 incorporating many improvements and updates,
such as GSX, CONFIG, DSKMAINT, FUNCTION and PRINT commands. It later
released an updated version in 'mid' 1983 for the XT.  Both were
called version 1.1, the latter added 'for PC XT'.

Interestingly the DRI version for the PC could only use 544 Kb of RAM
while the XT version could use 640Kb.  The XT version could access the
IBM PC XT hard disks while earlier versions could access hard disks on
the IBM PC using a Xebec controller only.  PC-DOS 1 could not access
hard disks at all.

In what way were these not 'update and maintain' ?

I don't fully understand why only 544Kb RAM could be used.  It may be
that this was not actually a limit of CP/M-86 itself but was all that
an IBM PC could use at the time CP/M-86 was released.  Original IBM
PCs (Model As) were physically limited to 256Kb max even with several
RAM cards due to bus designs.  The Model B (which I have here) used a
different planar layout to allow full addressing of RAM, but perhaps
it could only be fitted with 544Kb using contemporary mamory cards in
the number of slots available.

> In contrast, Concurrent CP/M (son of MP/M-86) certainly was...

Exactly, that is the nature of a 'replacement'.

Concurrent-CP/M-86 version 1.0 also received a 'for XT' version around
the same time as CP/M-86 in mid 83.  But it moved on to version 2.0 in
Feb 84, still single user, then to version 3.x which brought the
multi-user features back to replace MP/M-86 2.1 too.
0
riplin (4127)
10/21/2003 7:46:44 PM
Re: "Unfortunately, no copies of the binaries of the files of 
ConcurrentCP/M Release 3.1 for the IBM PC have been found, so far."

I have a complete, full retail package of CCP/M 3.1 for the IBM-PC with 
both manuals and 5.25" diskettes in essentially new condition.  I don't 
know if the diskettes are readable at this point or not.  The package is 
obviously about 20 years old, has either never been used or only used 
once or twice, it's been in my possession since new.

Barry Watzman

0
WatzmanNOSPAM (5711)
10/22/2003 3:58:46 AM
> What are the system requirements of CCP/M-86? How much ram does it
> use, and how much do some popular applications take? Is there a good
> integrated application package? If so, can I run the whole thing in
> 640k-768k?

System requirements: The LOADER checks for 160 KB.

How much RAM: about 140 KB.

How much RAM used by "some popular applications": The length of
their CMD files (minus the "Header Record").

Good Integrated: None known, so far.

Can I run it in 640 KB?: Yes, it is a 8086 program: it has no idea that
RAM can exist above that.

All you need is disassemble a 55 KB SYS file of 8086 code,
then you have your own Operating System running on an
IBM Clown.

This is what have been working on a few persons of this
Newsgroup, since 2000, when CP/M-86 Plus was found.

Yours Sincerely,
"French Luser"



0
10/22/2003 1:24:03 PM
"Richard" wrote:

> I suspect that I have far more 'CCP/M' docs than you do, including
> references to the version 1 which was single-user.

Then, what are waiting for?

Waiting for the water to boil in your empty unplugged electric teapot?

"French Luser"



0
10/22/2003 1:31:15 PM
Barry Watzman <WatzmanNOSPAM@neo.rr.com> wrote in message news:<3F95FE55.9090509@neo.rr.com>...
> Re: "Unfortunately, no copies of the binaries of the files of 
> ConcurrentCP/M Release 3.1 for the IBM PC have been found, so far."
> 
> I have a complete, full retail package of CCP/M 3.1 for the IBM-PC with 
> both manuals and 5.25" diskettes in essentially new condition.  I don't 
> know if the diskettes are readable at this point or not.  The package is 
> obviously about 20 years old, has either never been used or only used 
> once or twice, it's been in my possession since new.
> 
> Barry Watzman

It would be nice of you to donate the disk images to Gaby's site, if
you could.  The source is there, but to have original disk images
there would be useful to check the boot loader scheme and to compare a
build for the sources against your originals.
0
s_dubrovich (395)
10/22/2003 4:25:27 PM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote 

> How much RAM used by "some popular applications": The length of
> their CMD files (minus the "Header Record").

No. Wrong.  While CP/M and MS-DOS .COM files are simply binary images
that are stream loaded into memory and thus roughly equate to memory
usage, CP/M-86 .CMD are structured files that contain loadable
segments that may or may not relate to memory requirements.  In 8080
(tiny) and small memory models there may be a rough equivalence
between file size and memory usage.  In other memory models there may
be no direct relationship, especially when the program is overlayed
from the .CMD file.

> Can I run it in 640 KB?: Yes, it is a 8086 program: it has no idea that
> RAM can exist above that.

Well, _you_ may have no idea that RAM can exist above 640Kb, the 8086
thinks it can go all the way up to 1 MByte.
0
riplin (4127)
10/22/2003 6:57:44 PM
> > How much RAM used by "some popular applications"

Ok, specificaly, can I (usualy) run four at a time in 640k/768k?

<snip technical stuff that's still over my big fat empty head>

> Well, _you_ may have no idea that RAM can exist above 640Kb, the 8086
> thinks it can go all the way up to 1 MByte.

You know that, and I know that, but does the *bios* know that?
0
10/22/2003 8:42:22 PM
> How much RAM: about 140 KB.

Is that hoe much the *OS* uses!?
 
> Good Integrated: None known, so far.

Can it run mess-dos programs?
0
10/22/2003 8:56:07 PM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote 

> Then, what are waiting for?

I am waiting for Nicolas Chauvin to exit stage left.
0
riplin (4127)
10/22/2003 10:32:57 PM
puritan_1620@yahoo.com (Leon Howell) wrote 

> Ok, specificaly, can I (usualy) run four at a time in 640k/768k?

Using Concurrent-CP/M-86 an IBM PC XT with 640Kb can run four programs
at a time as long as they will fit into the available memory, and this
depends on the actual programs.  For example WordStar for CP/M-86
version 3.3 takes 112Kb on my system here.  VFiler uses 64Kb.

> > Well, _you_ may have no idea that RAM can exist above 640Kb, the 8086
> > thinks it can go all the way up to 1 MByte.
> 
> You know that, and I know that, but does the *bios* know that?

Many machines are not IBM PCs or clones, even 8086 ones.  The ICL PC2s
and Quattros, Compupros, Altos, for example, can use the full
addressable 1024 Kb for OS and programs.

Now in respect of the IBM BIOS, there is nothing in that to prevent
programs using the full 1 megabyte of address space.  Of course many
types of access will fail if the locations are missing or read-only.
0
riplin (4127)
10/23/2003 2:33:36 AM
As usual, you are off topic.

I wrote about your strange behavior, and you answer talking
about jingoism.

1) Years after years, you have told us that you have many
interesting/lost things for the people reading this comp.os.cpm
Newsgroup.

Example: your message where you say that you have 2 copies
of the Personal BASIC doc. "Gaby" asked you to scan them.
2 years later, no doc for Personal BASIC can be found
anywhere...

Several people (who publish frequently) are working on
recreating the source code of Concurrent CP/M.

You boasted many, many times that you have almost
all the versions.

Yet, mysteriously, you never seem to have read those
messages, that everybody else has read...

Recently, I needed to transfer some ICL Quattro floppies.

One more time, you said publicly that you had the program.

My box of floppies is still not transferred.

Etc, etc.

2) On the other hand, years after years, you have bored us
telling (advertising? Many times I have thought that your
only work what to lobby us into buying your OS) that you
were using a totally unknown operating system(s) still
able to run CP/M-86 ComManD files.

Of course, you never failed to mention that they were able
to run MeSsy-DOS or Windows!!!

Should I tell you what is the name of this Newsgroup?

Should I tell you where you can put your stuff?

If you don't want to share what CP/M stuff you have with us,
leave us alone, and go play with the others people using
your non-CP/M Dead Operating Systems.

You are clearly, obviously, categorically, unequivocally
the "bore" of  this Newsgroup.

From now on, I will call you Richard "I have it" Plinston.

"French Luser"



0
10/24/2003 12:13:31 PM
On Tue, 21 Oct 2003 17:11:04 +0200, "Salle Arobase"
<salle.arobase@ville-rochefort.fr> wrote:

>> > In this case, Digital Research made a later version of MP/M-86
>> > named Concurrent CP/M,
>>
>> While CCP/M derived from MP/M it wasn't a 'version' of it.

>I don't know if you know it, but Digital Research decided to develop
>Concurrent CP/M, not CP/M-86, when MS-DOS was adopted by
>most IBM Clown users.
>
>As far as I know, CP/M-86 was never maintained nor updated by
>Digital Research.

>In contrast, Concurrent CP/M (son of MP/M-86) certainly was...

Seems to me, there were different AUTHORS involved in the
various ''versions'' of DRI operating systems. Seems to me,
Rolander had a lot to do with MP/M86. Don't remember ever
hearing who did most of the CP/M86 work, but don't think it
was him. I'd guess whoever it was (CP/M86) moved on to
something completely different. Didn't Kildall do most of the
MP/M80 coding? Then pass off MP/M86 to Rolander?

Concurrent was WRITTEN to be able to run MSDOS stuffs.
I think from the ground up. Don't think it was something
tacked onto existing anything.

Could be I remember some things wrong.

Bill

0
Bill3039 (326)
10/24/2003 4:50:57 PM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote

> Recently, I needed to transfer some ICL Quattro floppies.

> One more time, you said publicly that you had the program.

Here is what I _actually_ said:

"""I don't have any non-commercial programs that will read ICL
PC2/Quattro
disks.  That is not normally a problem because the machines will
read/write
IBM PC 360Kb diskettes (requires PC-MODE installed when CCP/M 3.1)."""
 
> My box of floppies is still not transferred.

I am still waiting for them to turn up in the post, or were you
expecting me to bring my machine to you ?

> only work what to lobby us into buying your OS) that you
> were using a totally unknown operating system(s) still
> able to run CP/M-86 ComManD files.

It is relevant because it is DRI, it is part of the family of CP/M. I
was changing it from the state of 'totally unknown' into 'aware'.  If
you don't like it then don't read it and continue to ramble on about
your own causes.

> Of course, you never failed to mention that they were able
> to run MeSsy-DOS or Windows!!!

When asked.
 
> Should I tell you where you can put your stuff?

I am sorry, but I think that you should know that is _not_ the way to
get co-operation from anyone. You rant about how no one rushes out to
do what _you_ want and attempt to 'motivate' by insulting them.

Perhaps that is just the French character.
0
riplin (4127)
10/24/2003 6:59:08 PM
wild bill <bill@sunsouthwest.com> wrote 

> Concurrent was WRITTEN to be able to run MSDOS stuffs.
> I think from the ground up. Don't think it was something
> tacked onto existing anything.

No. Concurrent CP/M-86 versions 1, 2 and 3.1 could do nothing with
MS-DOS programs or disks.  At some point between 3.1 and 3.2 an add-in
module called PCMODE could be configured into the OS to give MS-DOS
1.x emulation.  On the ICL PC2 and Quattro CCP/M-86 this had to be
configured in specifically.  As well as running MS-DOS .COM files (all
that MS-DOS 1.x ran) it also allowed access to IBM-PC 360 Kb disks
(and 160, 180 and 320).  I suspect that this was specific to ICL as it
had to double step the 80 track 720Kb drives used by these machines.
It was supposed to be read-only access, but it could write to freshly
formatted disks without too much problems.

You should note that when Concurrent-CP/M-86 was released, MS-DOS 1.x
was just a CP/M clone for the 8086 but had no hard drive support, no
directories and no user areas.  Programs were just .COM binary images.
 Running 'MS-DOS stuff' was a trivial recompile and most software was
available on both MS-DOS and CP/M-86.

CCP/M-86 issue 3.2 included PCMODE in the distribution.  The next
version was changed to the name Concurrent-DOS 4.1 as it incorporated
an enchanced DOS emulation module including support for FAT hard disk
partitions and directories and MS-DOS 2.x programs including .EXEs.

Eventually CDOS 6.x and -386 became IBM PC only and access to CP/M
media became an add-on.
0
riplin (4127)
10/24/2003 10:07:36 PM
Richard "I have it" Plinston wrote:

> I have these manuals:
> Personal BASIC Language - Reference Manual - April 1983
> Personal BASIC Language - Tutorial - 1983
> Personal BASIC Additional Documentation - August 1983
> I seem to have 2 sets.

Richard "I have it", how do you call the behavior of someone
who accumulate and accumulate stuff without ever sharing
anything (not even a photocopy) with anybody else?

How do you call the behavior of someone who says over
and over "I have it", yet never provide the slightest information
about some of the most sought after stuff?

How do you call the behavior of someone who says over
and over that some totally unknown non-CP/M Dead
Operating System can still run CP/M-86 ComManD
files, while some of the most active members of this
comp.os.cpm Newsgroup are working very hard to
understand and maintain CP/M-86, CP/M-86 Plus,
Concurrent CP/M Release 3.1, and DOS Plus?
(Telling us, in addition, that he has all the release versions,
all the doc, and all the binary files, yet never even
copying one of them for us!)

Are you sure that you are not suffering from a mental illness?

According to Sigmund Freud, the people who exhibit
this kind of behavior had a problem during their youth
related to their anal sphyncter...

"French Luser"



0
10/28/2003 1:41:34 PM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote 

> (Telling us, in addition, that he has all the release versions,
> all the doc, and all the binary files, yet never even
> copying one of them for us!)

No, I don't think that I ever said 'all', just some.
 
> According to Sigmund Freud, the people who exhibit
> this kind of behavior had a problem during their youth
> related to their anal sphyncter...

The problem I have is with the French Arsehole who seems to think, in
a typically gaullic way, that insults are better than polite requests.
0
riplin (4127)
10/28/2003 6:09:25 PM
> > How much RAM: about 140 KB.
> 
> Is that how much the *OS* uses!?
>  
> > Good Integrated: None known, so far.
> 
> Can it run mess-dos programs?

Sorry if that was taken as rude or insulting; I'm shure ms-dos
programs are a little unpopular here. But there's an integrated
application package called "Framework" that fits on a 720k floppy with
ms-dos, and I was hoping I could use it with a good os. Does anyone
here know anything about Framework? I would appriceate *any*
information, espesialy where to get it.
0
10/28/2003 7:20:43 PM
> Does anyone
> here know anything about Framework? I would appriceate *any*
> information, espesialy where to get it.

Or better yet, Enable. It has a word proccessor, database,
spreadsheet, terminal, and graphics, and up to 8 windows, even on an
XT.

Good grief, it must have been written by an OS-9 user or something.
But it's for dos, so I was thinking how much fun it would be to
experiment with something that powerfull under an os like CCP/M. Could
I really run 4 apps at a time out of *32* in memory? Task switching
and multitasking at the same time?

Of course that would require a big ram upgrade, but JDR user to sell
some pretty big 8-bit ram cards. Not for the 1400LT though :(

Comments?
0
10/29/2003 9:32:49 PM
Richard <riplin@azonic.co.nz> wrote:
: I don't fully understand why only 544Kb RAM could be used. It may be
: that this was not actually a limit of CP/M-86 itself but was all that
: an IBM PC could use at the time CP/M-86 was released. 

  The original PC BIOS wouldn't support more than 544K memory. This was 
fixed in the 10/27/82 version.
<http://cma.zdnet.com/book/upgraderepair/ch23/ch23.htm#Heading6>

  I don't know if this is the cause of the CP/M-86 limitation or just a 
coincidence.

-- 
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)
0
jce (444)
10/30/2003 10:06:40 PM
By the way, could you stay on topic?

Richard "I have it" Plinston wrote:

> I have these manuals:
> Personal BASIC Language - Reference Manual - April 1983
> Personal BASIC Language - Tutorial - 1983
> Personal BASIC Additional Documentation - August 1983
> I seem to have 2 sets.

"French Luser"



0
10/31/2003 11:29:34 AM
"Salle Arobase" <salle.arobase@ville-rochefort.fr> wrote 

> By the way, could you stay on topic?

> > Personal BASIC Language - Reference Manual - April 1983
> > Personal BASIC Language - Tutorial - 1983
> > Personal BASIC Additional Documentation - August 1983

ROFL, you are the complete fool.  In this topic it is only you that
has posted these lines, and you now claim they are 'off topic'.

In the original topic they were in, they were a specific answer to a
question from you about these documents.

It seems that you are getting desparately irrational.
0
riplin (4127)
10/31/2003 11:54:26 PM
"Richard" wrote in message...

> > By the way, could you stay on topic?

> > > Personal BASIC Language - Reference Manual - April 1983
> > > Personal BASIC Language - Tutorial - 1983
> > > Personal BASIC Additional Documentation - August 1983

> ROFL, you are the complete fool.  In this topic it is only you that
> has posted these lines, and you now claim they are 'off topic'.

I agree with you, Personal BASIC should be exceptable discussion to discuss
here. It could be discussed in comp.lang.basic.misc, but you may get the
wrong responce back though some people here I think do read that group as
well.

However, there are people who send their machine specific problems here
because they don't know where else they can go, but they could get the right
group of people.

> In the original topic they were in, they were a specific answer to a
> question from you about these documents.

I think my point above seems to be of more concern (to people who are
worrying about off-topic discussion), though it doesn't seem to worry me or
anybody else around here!

Cheers,
Ross.


0
11/1/2003 2:24:10 AM
> I agree with you, Personal BASIC should be exceptable discussion to discuss
> here.

I also think MBasic should be acceptable. (Note the spelling of
acceptable. Don't you have SpellStar? :)

> It could be discussed in comp.lang.basic.misc,

Is that group about real Basic, like MBasic, C= Basic 7.0, Tandy DECB,
etc., or is it really about pascal, like S-Basic, Q-Basic, Basic-09,
or Visual Basic?

I really get sick of reading something about Basic (Remember the
"Basic Stamp" microcontrollers?) only to find that it's really Pascal.
Pascal is fine, but it's not Basic. Basic is flexible-no forced
structure-so the casual programmer can play with it, or the serious
proffessional can structure his program any way he wants, even in
Pascal's rigid style. Even Logo is closer to Basic than S-Basic.
0
puritan_2076 (115)
11/7/2003 2:21:49 AM
"Leon Howell" wrote in message...

> > I agree with you, Personal BASIC should be exceptable
> > discussion to discuss here.

> I also think MBasic should be acceptable. (Note the spelling of
> acceptable. Don't you have SpellStar? :)

Well that's just not exceptable! ;-)

> > It could be discussed in comp.lang.basic.misc,

> Is that group about real Basic, like MBasic, C= Basic 7.0, Tandy DECB,
> etc., or is it really about pascal, like S-Basic, Q-Basic, Basic-09,
> or Visual Basic?

It's a discussion on just about every concievable BASIC known, but mainly
discussed is the Visual BASIC, Q-BASIC & Power BASIC, the first 2 have their
own groups, so it beats me why they go there. Haven't noticed a group for
Power BASIC, unless this is it! :-)

> I really get sick of reading something about Basic (Remember the
> "Basic Stamp" microcontrollers?) only to find that it's really Pascal.

They aren't supposed to be related, however it's been discussed that Turbo
Pascal isn't Pascal, which in theory looks correct! :-) But 'am not about to
turn it into some BASIC lookalike which is full of horrible GOTOs!

> Pascal is fine, but it's not Basic. Basic is flexible-no forced
> structure-so the casual programmer can play with it, or the serious
> proffessional can structure his program any way he wants, even in
> Pascal's rigid style. Even Logo is closer to Basic than S-Basic.

If you have (or had) a look at the Moonrock compiler & you'll think it's
based on C (well maybe SmallC! :-), they do compile a high-level looking
code into Assembly for which the Assembler needs to compile, in order to get
some working code! :-)

Cheers,
Ross.


0
11/7/2003 7:49:05 AM
> 
> It's a discussion on just about every concievable BASIC known, but mainly
> discussed is the Visual BASIC, Q-BASIC & Power BASIC, the first 2 have their
> own groups, so it beats me why they go there. Haven't noticed a group for
> Power BASIC, unless this is it! :-)
> 
> > I really get sick of reading something about Basic (Remember the
> > "Basic Stamp" microcontrollers?) only to find that it's really Pascal.
> 
> They aren't supposed to be related, 

According to the reveiws and manuals for many of these versions of
Pascal that call themselves Basic, they *are* related to Pascal, even
thogh they still claim to be basic.

> however it's been discussed that Turbo
> Pascal isn't Pascal, which in theory looks correct! :-) 

I an not familiar with that argument. I'm not a pascal fan, and I have
very little experience with it.

Ok, let me explain what makes Basic Basic. It is *extremely* flexible,
and it has:

***AN IMEDIATE MODE***!!! !!! !!!

If there are no line numbers, then I don't care what the copywrighted
name is, it's not Basic.

One of the biggest advantages of Basic is that it can be used as an
operating system. CP/M is an OS, but not a language. You can program
in it with submit files, (I've heard the're like dos batch files) like
but there's that forced structure again.
0
11/8/2003 11:47:23 PM
Hey, wait a minute! Is there a CCP/M-80?
0
11/8/2003 11:49:47 PM
"Leon Howell" <puritan_1620@yahoo.com> wrote in message
news:bfc4e250.0311081549.4743001b@posting.google.com...
> Hey, wait a minute! Is there a CCP/M-80?

No.


0
randy482 (428)
11/9/2003 12:20:17 AM
"Leon Howell" <puritan_1620@yahoo.com> wrote in message
news:bfc4e250.0311081547.41b301a1@posting.google.com...
> >
> > It's a discussion on just about every concievable BASIC known, but
mainly
> > discussed is the Visual BASIC, Q-BASIC & Power BASIC, the first 2 have
their
> > own groups, so it beats me why they go there. Haven't noticed a group
for
> > Power BASIC, unless this is it! :-)
> >
> > > I really get sick of reading something about Basic (Remember the
> > > "Basic Stamp" microcontrollers?) only to find that it's really Pascal.
> >
> > They aren't supposed to be related,
>
> According to the reveiws and manuals for many of these versions of
> Pascal that call themselves Basic, they *are* related to Pascal, even
> thogh they still claim to be basic.
>
> > however it's been discussed that Turbo
> > Pascal isn't Pascal, which in theory looks correct! :-)
>
> I an not familiar with that argument. I'm not a pascal fan, and I have
> very little experience with it.
>
> Ok, let me explain what makes Basic Basic. It is *extremely* flexible,
> and it has:
>
> ***AN IMEDIATE MODE***!!! !!! !!!

The first basic was a compiler.

>
> If there are no line numbers, then I don't care what the copywrighted
> name is, it's not Basic.

The reason that the first basics had line numbers was for editing on
teletypes.  Without line numbers editing a program in memory is difficult
and expensive without a VDT.  Most basic programs were originally written on
TTY's and saved to PTP's.  Fortran and Cobol normally used punch cards
(without the hanging chad).

>
> One of the biggest advantages of Basic is that it can be used as an
> operating system. CP/M is an OS, but not a language. You can program
> in it with submit files, (I've heard the're like dos batch files) like
> but there's that forced structure again.


0
randy482 (428)
11/9/2003 12:26:45 AM
"Leon Howell" wrote in message...

> According to the reviews and manuals for many of these versions of
> Pascal that call themselves Basic, they *are* related to Pascal, even
> thogh they still claim to be basic.

Well, when I take out my sheet which talks about Computer Languages &
Decendants (if you can call it that), then the only which links these 2
languages up is Algol 60 (which simply only had Algol 58 & Fortran I
decending it).
If it was looked at as a family tree, then I would say they were distant
cousins! :-)

The 1964 edition of BASIC has more of the Fortran side about it with a
hint of Algol 60! :-) Where's PASCAL originally consentrated on the
Algol side more.

The confusing side about all of this, is when you start discussing the
offset's of BASIC. The newer languages like Visual BASIC do exceed the
point in terms of the way it performs, where's older BASIC found in
microcomputers (of the '80s) showed the basic foundations of the
language.

> > however it's been discussed that Turbo Pascal isn't Pascal, which
> > in theory looks correct! :-)

> I an not familiar with that argument. I'm not a pascal fan, and I have
> very little experience with it.

Well it's basically like what I was discussing about BASIC (being
modified & customed for a computer system). Turbo Pascal takes it's
elements from the PASCAL side of things & pretties things it up, but it
also has it's standard (which I don't follow or understand too well), so
I just use the language & write whatever code based on whatever machine
I'm using). The downside is the portability.

> Ok, let me explain what makes Basic Basic. It is *extremely* flexible,
> and it has:

As is Turbo Pascal is flexible, the IBM PC version has it's own set of
goodies (features), which makes it different from the CP/M-80, CP/M-86 &
MS-DOS version! ;-)

> ***AN IMEDIATE MODE***!!! !!! !!!

> If there are no line numbers, then I don't care what the copywrighted
> name is, it's not Basic.

Not even CBASIC? (It can have line numbers in it's programs - but
doesn't need to! :-)

> One of the biggest advantages of Basic is that it can be used as an
> operating system. CP/M is an OS, but not a language. You can program
> in it with submit files, (I've heard the're like dos batch files) like
> but there's that forced structure again.

Don't believe CP/M submit files are as flexible as DOS batch files, I've
seen some fairly complicated Batch Files & they aren't you're basic
autoexec.bat file either! ;-) You can even write DOS '.com' files out of
batch files.

Cheers,
Ross.


0
11/9/2003 3:25:46 AM
Leon Howell wrote:
> 
> Ok, let me explain what makes Basic Basic. It is *extremely* flexible,
> and it has:
> 
> ***AN IMEDIATE MODE***!!! !!! !!!

  None of the Microsoft BASIC non-visual compilers has an immediate mode.  Their
later DOS versions came bundled with a development environment based on their
QBASIC interpreter, but their CP/M versions most definately did not.  

> If there are no line numbers, then I don't care what the copywrighted
> name is, it's not Basic.

  Lots of BASICs allow you to dispense with line numbers and use labels for
statement references.

  What you are probably trying to say is that you prefer the older style BASIC
interpreters which use a line editor and hence require some way to refer to each
and every line in the program.

  Nothing wrong with that, I agree it's especially useful when you are doing
some custom interface prototyping and need a way to twiddle a port or memory
location without having to go through the bother of editing, compiling, and then
running the test program.

> One of the biggest advantages of Basic is that it can be used as an
> operating system.

  Well, now, that's not true and the reason why you may think it is so is
because many machines came with BASIC in ROM and would start up as the default
program.  In reality, there is an operating system which is also in ROM which
starts the machine and provides services to the BASIC interpreter which is also
in ROM.  The operating system is very simple (basically, initialize the machine,
set up the service routines, and start the interpreter), usually occupies less
than 1024 bytes of memory and has no command line interface of its own.  Such
services include handling the console input and output as well as mass storage
such as cassette tape.  These things are not intrinsic to the BASIC interpreter.

  Ever started up a TRS-80 Model III without disk drives?  The requests for
"Cass?" and "Memory Size?" come from the operating system in ROM.  The first one
sets up the cassette port for a particular operating speed, and the second one
requests the highest memory address to be used by the BASIC interpreter.  This
value is passed to BASIC which uses it as its MAXRAM ceiling.  This operating
system provides numerous machine services by way of subroutines at fixed memory
addresses.  I think 0033H was the console output routine, but it's been many
years.

  Another example - the Apple II machines when equipped with a Disk II drive
loaded an operating system from disk but otherwise operated in a similar fashion
to the same machine without disks.  There is no "DOS command line" in the Apple
II disk operating system - the BASIC interpreter is the user interface and the
operating system provides the machine services which the interpreter uses to
carry out the users requests.

  You can do this with many other languages such as Pascal or C or Forth. 
However, BASIC was the easiest to learn and there was a common implementation
already on the market back in the late 70s/early 80s.  One computer called the
Jupiter ACE came with Forth in ROM rather than BASIC.

>                     CP/M is an OS, but not a language. You can program
> in it with submit files, (I've heard the're like dos batch files) like
> but there's that forced structure again.

  The SUBMIT facility in CP/M was never meant to be a programming language per
se.  Rather it was meant to be a way to automate specific operations as a
convenience to the user.  The MSDOS batch facility was much the same thing but
then had lots of other things grafted onto it to try to make it competitive to
the shell scripts available in most Unix shells.
0
dumpster34 (24)
11/9/2003 5:41:39 AM
puritan_1620@yahoo.com (Leon Howell) wrote 

> Hey, wait a minute! Is there a CCP/M-80?

No, but there is MP/M (-80).
0
riplin (4127)
11/9/2003 5:44:20 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311082144.66f42d58@posting.google.com...
> puritan_1620@yahoo.com (Leon Howell) wrote
>
> > Hey, wait a minute! Is there a CCP/M-80?
>
> No, but there is MP/M (-80).

MP/M was available in at least three different DR versions.  CCP/M & MP/M
are distinct, they have totally different goals.  MP/M was phased out by DR.
It seams that networking was seen as the way to get the most out of the
hardware.


0
randy482 (428)
11/9/2003 6:25:33 AM
Richard wrote:
> 
> Interestingly the DRI version for the PC could only use 544 Kb of RAM
> while the XT version could use 640Kb.  The XT version could access the
> IBM PC XT hard disks while earlier versions could access hard disks on
> the IBM PC using a Xebec controller only.  PC-DOS 1 could not access
> hard disks at all.
> 
> In what way were these not 'update and maintain' ?
> 
> I don't fully understand why only 544Kb RAM could be used.  It may be
> that this was not actually a limit of CP/M-86 itself but was all that
> an IBM PC could use at the time CP/M-86 was released.  Original IBM
> PCs (Model As) were physically limited to 256Kb max even with several
> RAM cards due to bus designs.  The Model B (which I have here) used a
> different planar layout to allow full addressing of RAM, but perhaps
> it could only be fitted with 544Kb using contemporary mamory cards in
> the number of slots available.

  The 544K number is sorta erroneous, the original IBM 5150 Personal Computer
had the memory map of the 8088 split right down the middle, the lower 512k for
RAM and the upper 512k for the system, which includes ROM and video memory.

  Now, remember this was in 1981 and the thought of a desktop machine have that
much RAM was a luxury beyond the grasp of many computer owners of the time.  The
business standard was a Z80 with a max of 64K of memory.  The base price of an
IBM PC with 64K and one disk drive was $3000.  This memory map seemed like an
appropriate approach at the time.  Today it looks different.  Apple Computer
would do something similar in 2 years time with the Macintosh, but in that case
they split the 68K memory map into four equal pieces, with RAM in the lowest 4
megabytes only.

  While the original 5150 PC had a design limit of 512K RAM and provisions on
the main logic board for 64K (in 4 banks of 16K) there really wasn't anything
keeping you from putting in more memory on the expansion bus, with one
exception.  The POST (power on self test) memory validation program in the
startup portion of the BIOS ROM would report in the BIOS data segment (located
above the interrupt table, absolute address 0400H) that the machine had 544K if
it had more than 512K of RAM.  That's where the 544K "limit" came from.

  Incidentally, there was a DIP switch which was set to indicate maximum memory
in 32K increments.  This switch is read by the BIOS during POST and is used as
the limit to search for RAM.  Setting this switch to indicate more than 512K
would result in the BIOS reporting 544K.

  Since this was early in the product cycle of the IBM PC, software developers
outside of IBM were initially loath to retouch the maximum RAM parameter because
IBM told them not to.  As some users began filling their machines with memory,
they started running up against the limit.  A look through IBM's technical
literature on the BIOS showed where this value was stored, and a few seconds
with DEBUG would allow programs that checked this value to access memory all the
way up to 704K if it was present.  (704K is the start of the monochrome frame
buffer.)  After that, IBM modified the BIOS to allow 640K of RAM as a
compromise.

  You can still alter this value as long as your machine has RAM in the A0000H
to AFFFFH region and end up with 704K of conventional memory.  The bytes in
question are 0040:0013H and 0040:0014H which indicate in Intel little-endian
form the number of kilobytes of conventional memory.  With an MDA card you can
use 02C0H (704K) and with a CGA card and 32K more RAM you can use 02E0 (736K.)
0
dumpster34 (24)
11/9/2003 7:28:22 AM
Phil Dumpster <dumpster34@yahoo.com> writes:

>  Ever started up a TRS-80 Model III without disk drives?  The requests for
>"Cass?" and "Memory Size?" come from the operating system in ROM.

And you could load a Chess-game (SARGON if I remember).
It was one of the first copy-protected programms...

remembering old debug-sessions, Holger
0
hp1 (160)
11/9/2003 2:55:46 PM
"Phil Dumpster" <dumpster34@yahoo.com> wrote in message
news:3FADD5EB.BBB1B511@yahoo.com...
> Leon Howell wrote:
<snip>
> > One of the biggest advantages of Basic is that it can be used as an
> > operating system.
>
>   Well, now, that's not true and the reason why you may think it is so is
> because many machines came with BASIC in ROM and would start up as the
default
> program.  In reality, there is an operating system which is also in ROM
which
> starts the machine and provides services to the BASIC interpreter which is
also
> in ROM.  The operating system is very simple (basically, initialize the
machine,
> set up the service routines, and start the interpreter), usually occupies
less
> than 1024 bytes of memory and has no command line interface of its own.
Such
> services include handling the console input and output as well as mass
storage
> such as cassette tape.  These things are not intrinsic to the BASIC
interpreter.
>
>   Ever started up a TRS-80 Model III without disk drives?  The requests
for
> "Cass?" and "Memory Size?" come from the operating system in ROM.  The
first one
> sets up the cassette port for a particular operating speed, and the second
one
> requests the highest memory address to be used by the BASIC interpreter.
This
> value is passed to BASIC which uses it as its MAXRAM ceiling.  This
operating
> system provides numerous machine services by way of subroutines at fixed
memory
> addresses.  I think 0033H was the console output routine, but it's been
many
> years.
>
>   Another example - the Apple II machines when equipped with a Disk II
drive
> loaded an operating system from disk but otherwise operated in a similar
fashion
> to the same machine without disks.  There is no "DOS command line" in the
Apple
> II disk operating system - the BASIC interpreter is the user interface and
the
> operating system provides the machine services which the interpreter uses
to
> carry out the users requests.
>
>   You can do this with many other languages such as Pascal or C or Forth.
> However, BASIC was the easiest to learn and there was a common
implementation
> already on the market back in the late 70s/early 80s.  One computer called
the
> Jupiter ACE came with Forth in ROM rather than BASIC.
<snip>

You obviously do not understand that the OS used by many systems is an
extended Basic.

Any language can have enough extensions in it to be an OS.  Assemblers like
ALS8 and some versions of Forth are examples of languages that were extended
to be an OS.  An OS just needs to be able to load and execute another
program, it often has the ability to allow the loaded programs to call
routines in the OS (especially I/O or file operations) but that is not
required.

Some computers had a Basic in ROM with a separate boot routine ROM (not an
OS), an easy example is the IBM PC class which used a basic in ROM when no
disk was found.  The Basic had an OS integrated into it (a cassette OS), the
BIOS ROM did not.  By the way the OS in BIOS does not stand for Operating
System, it stands for Basic Input Output System which is used by the OS it
contained the I/O routines for Basic & PC-DOS.

The fact that the IBM BIOS would check for different OS's and boot them in a
particular order (floppy, HD, ROM) makes it an OS only on the most technical
way.  Basic, Forth, Assemblers such as ALS8, etc. allow for more
sophisticated control as an OS.


0
randy482 (428)
11/9/2003 3:44:36 PM

Phil Dumpster wrote:
> Richard wrote:
> 
>>Interestingly the DRI version for the PC could only use 544 Kb of RAM
>>while the XT version could use 640Kb.  The XT version could access the
>>IBM PC XT hard disks while earlier versions could access hard disks on
>>the IBM PC using a Xebec controller only.  PC-DOS 1 could not access
>>hard disks at all.
>>
>>In what way were these not 'update and maintain' ?
>>
>>I don't fully understand why only 544Kb RAM could be used.  It may be
>>that this was not actually a limit of CP/M-86 itself but was all that
>>an IBM PC could use at the time CP/M-86 was released.  Original IBM
>>PCs (Model As) were physically limited to 256Kb max even with several
>>RAM cards due to bus designs.  The Model B (which I have here) used a
>>different planar layout to allow full addressing of RAM, but perhaps
>>it could only be fitted with 544Kb using contemporary mamory cards in
>>the number of slots available.
> 
> 
>   The 544K number is sorta erroneous, the original IBM 5150 Personal Computer
> had the memory map of the 8088 split right down the middle, the lower 512k for
> RAM and the upper 512k for the system, which includes ROM and video memory.
> 
>   Now, remember this was in 1981 and the thought of a desktop machine have that
> much RAM was a luxury beyond the grasp of many computer owners of the time.  The
> business standard was a Z80 with a max of 64K of memory.  The base price of an
> IBM PC with 64K and one disk drive was $3000.  This memory map seemed like an
> appropriate approach at the time.  Today it looks different.  Apple Computer
> would do something similar in 2 years time with the Macintosh, but in that case
> they split the 68K memory map into four equal pieces, with RAM in the lowest 4
> megabytes only.
> 
>   While the original 5150 PC had a design limit of 512K RAM and provisions on
> the main logic board for 64K (in 4 banks of 16K) there really wasn't anything
> keeping you from putting in more memory on the expansion bus, with one
> exception.  The POST (power on self test) memory validation program in the
> startup portion of the BIOS ROM would report in the BIOS data segment (located
> above the interrupt table, absolute address 0400H) that the machine had 544K if
> it had more than 512K of RAM.  That's where the 544K "limit" came from.
> 
>   Incidentally, there was a DIP switch which was set to indicate maximum memory
> in 32K increments.  This switch is read by the BIOS during POST and is used as
> the limit to search for RAM.  Setting this switch to indicate more than 512K
> would result in the BIOS reporting 544K.
> 
>   Since this was early in the product cycle of the IBM PC, software developers
> outside of IBM were initially loath to retouch the maximum RAM parameter because
> IBM told them not to.  As some users began filling their machines with memory,
> they started running up against the limit.  A look through IBM's technical
> literature on the BIOS showed where this value was stored, and a few seconds
> with DEBUG would allow programs that checked this value to access memory all the
> way up to 704K if it was present.  (704K is the start of the monochrome frame
> buffer.)  After that, IBM modified the BIOS to allow 640K of RAM as a
> compromise.
> 
>   You can still alter this value as long as your machine has RAM in the A0000H
> to AFFFFH region and end up with 704K of conventional memory.  The bytes in
> question are 0040:0013H and 0040:0014H which indicate in Intel little-endian
> form the number of kilobytes of conventional memory.  With an MDA card you can
> use 02C0H (704K) and with a CGA card and 32K more RAM you can use 02E0 (736K.)

Not to dispute you, but some think the "640K barrier" had something to 
do with DOS. DOS could access up to one meg of RAM. DOS would access all 
RAM until it ran into the video memory, which was located where you 
stated above.

Roy



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----
0
millers (188)
11/9/2003 6:34:45 PM

Randy McLaughlin wrote:

> "Phil Dumpster" <dumpster34@yahoo.com> wrote in message
> news:3FADD5EB.BBB1B511@yahoo.com...
> 
>>Leon Howell wrote:
> 
> <snip>
> 
>>>One of the biggest advantages of Basic is that it can be used as an
>>>operating system.
>>
>>  Well, now, that's not true and the reason why you may think it is so is
>>because many machines came with BASIC in ROM and would start up as the
> 
> default
> 
>>program.  In reality, there is an operating system which is also in ROM
> 
> which
> 
>>starts the machine and provides services to the BASIC interpreter which is
> 
> also
> 
>>in ROM.  The operating system is very simple (basically, initialize the
> 
> machine,
> 
>>set up the service routines, and start the interpreter), usually occupies
> 
> less
> 
>>than 1024 bytes of memory and has no command line interface of its own.
> 
> Such
> 
>>services include handling the console input and output as well as mass
> 
> storage
> 
>>such as cassette tape.  These things are not intrinsic to the BASIC
> 
> interpreter.
> 
>>  Ever started up a TRS-80 Model III without disk drives?  The requests
> 
> for
> 
>>"Cass?" and "Memory Size?" come from the operating system in ROM.  The
> 
> first one
> 
>>sets up the cassette port for a particular operating speed, and the second
> 
> one
> 
>>requests the highest memory address to be used by the BASIC interpreter.
> 
> This
> 
>>value is passed to BASIC which uses it as its MAXRAM ceiling.  This
> 
> operating
> 
>>system provides numerous machine services by way of subroutines at fixed
> 
> memory
> 
>>addresses.  I think 0033H was the console output routine, but it's been
> 
> many
> 
>>years.
>>
>>  Another example - the Apple II machines when equipped with a Disk II
> 
> drive
> 
>>loaded an operating system from disk but otherwise operated in a similar
> 
> fashion
> 
>>to the same machine without disks.  There is no "DOS command line" in the
> 
> Apple
> 
>>II disk operating system - the BASIC interpreter is the user interface and
> 
> the
> 
>>operating system provides the machine services which the interpreter uses
> 
> to
> 
>>carry out the users requests.
>>
>>  You can do this with many other languages such as Pascal or C or Forth.
>>However, BASIC was the easiest to learn and there was a common
> 
> implementation
> 
>>already on the market back in the late 70s/early 80s.  One computer called
> 
> the
> 
>>Jupiter ACE came with Forth in ROM rather than BASIC.
> 
> <snip>
> 
> You obviously do not understand that the OS used by many systems is an
> extended Basic.
> 
> Any language can have enough extensions in it to be an OS.  Assemblers like
> ALS8 and some versions of Forth are examples of languages that were extended
> to be an OS.  An OS just needs to be able to load and execute another
> program, it often has the ability to allow the loaded programs to call
> routines in the OS (especially I/O or file operations) but that is not
> required.
> 
> Some computers had a Basic in ROM with a separate boot routine ROM (not an
> OS), an easy example is the IBM PC class which used a basic in ROM when no
> disk was found.  The Basic had an OS integrated into it (a cassette OS), the
> BIOS ROM did not.  By the way the OS in BIOS does not stand for Operating
> System, it stands for Basic Input Output System which is used by the OS it
> contained the I/O routines for Basic & PC-DOS.
> 
> The fact that the IBM BIOS would check for different OS's and boot them in a
> particular order (floppy, HD, ROM) makes it an OS only on the most technical
> way.  Basic, Forth, Assemblers such as ALS8, etc. allow for more
> sophisticated control as an OS.

But that doesn't make the "Cassette BASIC" of a PC an "OS", as much of 
it's "OS" was the BIOS!

As stated by Phil, both IBM's "Cassette BASIC" and Apple II's BASIC were 
user interfaces to the OS. Perhaps part of that was built into the 
BASIC, but certainly not all of it.

And with IBM's BASICA and MS's GWBASIC, the OS was DOS, which was 
accessed by the BASIC, or, if you exited BASIC, the Command.com. Apple 
IIs, to my knowledge, never had a Command Processor like CP/M or DOS.

Roy
> 
> 



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----
0
millers (188)
11/9/2003 6:40:48 PM
"Exegete" <millers@noneofyourbusiness.com> wrote in message
news:3fae8a35$1_5@corp.newsgroups.com...
>
>
> Randy McLaughlin wrote:
<snip>
> > You obviously do not understand that the OS used by many systems is an
> > extended Basic.
> >
> > Any language can have enough extensions in it to be an OS.  Assemblers
like
> > ALS8 and some versions of Forth are examples of languages that were
extended
> > to be an OS.  An OS just needs to be able to load and execute another
> > program, it often has the ability to allow the loaded programs to call
> > routines in the OS (especially I/O or file operations) but that is not
> > required.
> >
> > Some computers had a Basic in ROM with a separate boot routine ROM (not
an
> > OS), an easy example is the IBM PC class which used a basic in ROM when
no
> > disk was found.  The Basic had an OS integrated into it (a cassette OS),
the
> > BIOS ROM did not.  By the way the OS in BIOS does not stand for
Operating
> > System, it stands for Basic Input Output System which is used by the OS
it
> > contained the I/O routines for Basic & PC-DOS.
> >
> > The fact that the IBM BIOS would check for different OS's and boot them
in a
> > particular order (floppy, HD, ROM) makes it an OS only on the most
technical
> > way.  Basic, Forth, Assemblers such as ALS8, etc. allow for more
> > sophisticated control as an OS.
>
> But that doesn't make the "Cassette BASIC" of a PC an "OS", as much of
> it's "OS" was the BIOS!
>
> As stated by Phil, both IBM's "Cassette BASIC" and Apple II's BASIC were
> user interfaces to the OS. Perhaps part of that was built into the
> BASIC, but certainly not all of it.
>
> And with IBM's BASICA and MS's GWBASIC, the OS was DOS, which was
> accessed by the BASIC, or, if you exited BASIC, the Command.com. Apple
> IIs, to my knowledge, never had a Command Processor like CP/M or DOS.
>
> Roy

You totally misunderstand the Micro$loth Basics that have OS's integrated
in.

IBM's BIOS DOES NOT understand files/programs.

BASICA tied into the ROM Basic (GeeWhizBASIC did not) it was loaded from
disk, but then had access to the cassette OS built into the ROM Basic.

Micro$loth first wrote a basic that loaded from PTR and cassette.  It's file
handling OS was not a separate program, it was the basic that was/is the OS.
They also had a disk basic that was a disk OS, sometimes called stand-alone
disk basic.

The basic was/is the command processor.  All of the standard commands for an
OS was available.  The disk Basic could list directory, delete, rename,
execute binary programs, etc.  The tape/ROM version had commands appropriate
to the hardware.

The Apple II's DID have a command processor, it was called Basic.

A more interesting system to look for the OS is the Commie line (the OS was
kept in the disk drive, not the CPU).


0
randy482 (428)
11/9/2003 7:42:49 PM
"Exegete" <millers@noneofyourbusiness.com> wrote in message
news:3fae88ca$1_5@corp.newsgroups.com...

<snip>

> Not to dispute you, but some think the "640K barrier" had something to
> do with DOS. DOS could access up to one meg of RAM. DOS would access all
> RAM until it ran into the video memory, which was located where you
> stated above.
>
> Roy

You do not understand.  DOS does not check memory, it just asks the BIOS for
top of memory.

The 640K barrier was stupid and DOS on "nonstandard" was not a limit.  DOS
on S1000 systems would handle one meg.

DOS does not require a memory mapped video.


0
randy482 (428)
11/9/2003 7:48:18 PM
"Randy McLaughlin" <randy482@nospam.com> wrote

> > > One of the biggest advantages of Basic is that it can be used as an
> > > operating system.

> You obviously do not understand that the OS used by many systems is an
> extended Basic.

That is a purely semantic argument.  There may be commands in the ROM
that can be used in an 'OS like way' and these may be used by BASIC
programs.  This does not mean that 'BASIC is an OS'.
 
It is also arguable whether a few keywords can be usefully called an
'OS', some even argue that MS-DOS can barely be called an OS, it is
just a loader with some utility programs.

> Any language can have enough extensions in it to be an OS. 

Just because they are in the same ROM as the language does not make
them part of the language.

> Assemblers like
> ALS8 and some versions of Forth are examples of languages that were extended
> to be an OS.  

And UCSD Pascal.

> An OS just needs to be able to load and execute another
> program, it often has the ability to allow the loaded programs to call
> routines in the OS (especially I/O or file operations) but that is not
> required.

Well if you degrade the term OS down to that level then just about
anything could be made into being an 'Operating System', even a ROM
monitor can do that.
0
riplin (4127)
11/9/2003 11:03:21 PM
"Randy McLaughlin" <randy482@nospam.com> wrote

> > > Hey, wait a minute! Is there a CCP/M-80?
> >
> > No, but there is MP/M (-80).
> 
> MP/M was available in at least three different DR versions.  

MP/M, MP/M II were for 8 bit systems.
MP/M-86 was 16 bit.

> CCP/M & MP/M are distinct, they have totally different goals.  

Crap. CCP/M derived from and was the replacement for MP/M-86.  While
they originally implemented CCP/M 1.x on the IBM PC as a single-user
system, this was mainly due to lack of multiuser hardware.  With
'StarNet' (serial card) it was multiuser, even on very early versions.
 All CCP/M s on other machines, such as ICL, Compupro, Altos etc, were
multiuser and were direct replacements and upgrade for MP/M-86.

> MP/M was phased out by DR.

Because it was superceeded by CCP/M-86 multiuser.

> It seams that networking was seen as the way to get the most out of the
> hardware.

Did you not know that MP/M was initially designed to act as a network
server ? Later it was mainly used in multiuser systems, CCP/M-86 just
carried on that process to give a better mechanism for multi-tasking
for each user.
0
riplin (4127)
11/9/2003 11:30:47 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311091503.19c794f9@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > > One of the biggest advantages of Basic is that it can be used as an
> > > > operating system.
>
> > You obviously do not understand that the OS used by many systems is an
> > extended Basic.
>
> That is a purely semantic argument.  There may be commands in the ROM
> that can be used in an 'OS like way' and these may be used by BASIC
> programs.  This does not mean that 'BASIC is an OS'.
>
> It is also arguable whether a few keywords can be usefully called an
> 'OS', some even argue that MS-DOS can barely be called an OS, it is
> just a loader with some utility programs.
>
> > Any language can have enough extensions in it to be an OS.
>
> Just because they are in the same ROM as the language does not make
> them part of the language.
>
> > Assemblers like
> > ALS8 and some versions of Forth are examples of languages that were
extended
> > to be an OS.
>
> And UCSD Pascal.

UCSD Pascal was NOT an OS, it was/is a language.  The OS is written in
Pascal, the OS is called the p-system.

>
> > An OS just needs to be able to load and execute another
> > program, it often has the ability to allow the loaded programs to call
> > routines in the OS (especially I/O or file operations) but that is not
> > required.
>
> Well if you degrade the term OS down to that level then just about
> anything could be made into being an 'Operating System', even a ROM
> monitor can do that.

You obviously have a definition of what an OS is that is not used on this
planet.  Please share with us poor idiots your definition of what a real OS
must have to be an OS.  I must assume that if MS-DOS falls short then CP/M
has no chance of being an OS and NS-DOS being even simpler is who knows
what.

An OS needs to be no more than a monitor that allows the user to select what
program to execute.  It does not matter whether the programs are in ROM,
tape, disk, etc.  There is no definition that requires any particular magic
words (such as NS-DOS go), just typing the program name, using a mouse, or
even flipping sense switches.

If a Basic interpreter is used as a base for an OS it simplifies development
since it already has a parser, etc.


0
randy482 (428)
11/9/2003 11:39:35 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311091530.5bc994ce@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > > Hey, wait a minute! Is there a CCP/M-80?
> > >
> > > No, but there is MP/M (-80).
> >
> > MP/M was available in at least three different DR versions.
>
> MP/M, MP/M II were for 8 bit systems.
> MP/M-86 was 16 bit.
>
> > CCP/M & MP/M are distinct, they have totally different goals.
>
> Crap. CCP/M derived from and was the replacement for MP/M-86.  While
> they originally implemented CCP/M 1.x on the IBM PC as a single-user
> system, this was mainly due to lack of multiuser hardware.  With
> 'StarNet' (serial card) it was multiuser, even on very early versions.
>  All CCP/M s on other machines, such as ICL, Compupro, Altos etc, were
> multiuser and were direct replacements and upgrade for MP/M-86.
>
> > MP/M was phased out by DR.
>
> Because it was superceeded by CCP/M-86 multiuser.
>
> > It seams that networking was seen as the way to get the most out of the
> > hardware.
>
> Did you not know that MP/M was initially designed to act as a network
> server ? Later it was mainly used in multiuser systems, CCP/M-86 just
> carried on that process to give a better mechanism for multi-tasking
> for each user.

MP/M was intended as a multi-user system, networking came later (CP/NET), it
was NOT originally intended as a network server.

CCP/M was intended as a multi-tasking system that allows multiuser.  MP/M
was intended as a multi-user system that did multi-tasking.  The change in
emphasis is significant in understanding how the OS grew.  One can
definitely say that CCP/M started out as MP/M III(86), but you must
understand the direction changed especially toward CC-DOS.

I had several clients running on Compupro 816's running MP/M 8/16, when
their software changed from CP/M-80 to DOS all I did was change their OS to
CC-DOS 8/16.  I am very aware of what CCP/M & CC/DOS did and I also
understand the thinking behind the OS's goals.

MP/M would let you start programs in the background while CCP/M always had
VT's.  VT's made it easier especially for people who were not computer
geeks.  Running programs in background on MP/M left it up to the user to
keep things straight.


0
randy482 (428)
11/9/2003 11:56:40 PM

Randy McLaughlin wrote:
> "Exegete" <millers@noneofyourbusiness.com> wrote in message
> news:3fae88ca$1_5@corp.newsgroups.com...
> 
> <snip>
> 
>>Not to dispute you, but some think the "640K barrier" had something to
>>do with DOS. DOS could access up to one meg of RAM. DOS would access all
>>RAM until it ran into the video memory, which was located where you
>>stated above.
>>
>>Roy
> 
> 
> You do not understand.  DOS does not check memory, it just asks the BIOS for
> top of memory.

I'm not so sure that you understand. DOS required contiguous memory. 
IBM's hardware design prevented DOS from having a one meg contiguous 
address space.
> 
> The 640K barrier was stupid and DOS on "nonstandard" was not a limit.  

You're right. I don't understand. That last phrase at least!

DOS
> on S1000 systems would handle one meg.

Umm, I said that. See above.

> 
> DOS does not require a memory mapped video.

I never said it did. IBM's hardware design is what prevented DOS from 
accessing a full meg of RAM.

Roy

> 
> 



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----
0
millers (188)
11/10/2003 3:04:13 AM
"Exegete" <millers@noneofyourbusiness.com> wrote in message
news:3faf0034$1_5@corp.newsgroups.com...
>
>
> Randy McLaughlin wrote:
> > "Exegete" <millers@noneofyourbusiness.com> wrote in message
> > news:3fae88ca$1_5@corp.newsgroups.com...
> >
> > <snip>
> >
> >>Not to dispute you, but some think the "640K barrier" had something to
> >>do with DOS. DOS could access up to one meg of RAM. DOS would access all
> >>RAM until it ran into the video memory, which was located where you
> >>stated above.
> >>
> >>Roy
> >
> >
> > You do not understand.  DOS does not check memory, it just asks the BIOS
for
> > top of memory.
>
> I'm not so sure that you understand. DOS required contiguous memory.
> IBM's hardware design prevented DOS from having a one meg contiguous
> address space.
> >
> > The 640K barrier was stupid and DOS on "nonstandard" was not a limit.
>
> You're right. I don't understand. That last phrase at least!
>
> DOS
> > on S100 systems would handle one meg.
>
> Umm, I said that. See above.
>
> >
> > DOS does not require a memory mapped video.
>
> I never said it did. IBM's hardware design is what prevented DOS from
> accessing a full meg of RAM.
>
> Roy

Actually you said:

"DOS would access all RAM until it ran into the video memory".

As I stated DOS does not check for memory, DOS does not access video memory,
DOS does not care about video memory.  Even the CLS function does not access
the video memory, except through the BIOS.

My point is that you stated that DOS cares about video memory, the point may
seem technical but you made it appear that DOS does something that it does
not do.  I agree that IBM's design limited the address space.


0
randy482 (428)
11/10/2003 3:35:34 AM
"Randy McLaughlin" <randy482@nospam.com> wrote in message news:<TdArb.72121$un.58377@bignews6.bellsouth.net>...
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:217e491a.0311091503.19c794f9@posting.google.com...
> > "Randy McLaughlin" <randy482@nospam.com> wrote
> > > Assemblers like
> > > ALS8 and some versions of Forth are examples of languages that were
>  extended
> > > to be an OS.
> >
> > And UCSD Pascal.
> 
> UCSD Pascal was NOT an OS, it was/is a language.  The OS is written in
> Pascal, the OS is called the p-system.

Apple's OS for the ][ based on UCSD Pascal was called Apple Pascal
(according to their own system disks, which supported the Pascal OS).

-uso.
0
steve92 (61)
11/10/2003 5:49:07 AM
"Dosius" <steve@dosius.zzn.com> wrote in message
news:9307085f.0311092149.242fcd50@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote in message
news:<TdArb.72121$un.58377@bignews6.bellsouth.net>...
> > "Richard" <riplin@Azonic.co.nz> wrote in message
> > news:217e491a.0311091503.19c794f9@posting.google.com...
> > > "Randy McLaughlin" <randy482@nospam.com> wrote
> > > > Assemblers like
> > > > ALS8 and some versions of Forth are examples of languages that were
> >  extended
> > > > to be an OS.
> > >
> > > And UCSD Pascal.
> >
> > UCSD Pascal was NOT an OS, it was/is a language.  The OS is written in
> > Pascal, the OS is called the p-system.
>
> Apple's OS for the ][ based on UCSD Pascal was called Apple Pascal
> (according to their own system disks, which supported the Pascal OS).
>
> -uso.

Again UCSD (even as Apple Pascal) provided an OS called the p-system.  Its
command processor used single letter commands.  The Pascal compiler was
optional (as was fortran).  The OS was not Pascal (not even Apple Pascal).

The p-system is a very interesting system.  It did not run on a 6502, it did
not run on a 8080/z80, it did not even run on the PDP system it was
developed on.  Like JAVA the p-system ran on a virtual CPU, strangely enough
later a CPU was built to run pcode directly (WD's pascal engine).

To get back on topic I have never heard of any OS that was an extension of
Pascal.


0
randy482 (428)
11/10/2003 6:22:58 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> > > Assemblers like
> > > ALS8 and some versions of Forth are examples of languages that were
>  extended
> > > to be an OS.
> >
> > And UCSD Pascal.
> 
> UCSD Pascal was NOT an OS, it was/is a language.  The OS is written in
> Pascal, the OS is called the p-system.

So you have it that 'languages are extended to be an OS', yet that is
_not_ the case with UCSD.
 
> > Well if you degrade the term OS down to that level then just about
> > anything could be made into being an 'Operating System', even a ROM
> > monitor can do that.
> 
> You obviously have a definition of what an OS is that is not used on this
> planet. 

Do I ?  You seem to have a definition that leads to almost anything on
the planet can be one.

> Please share with us poor idiots your definition of what a real OS
> must have to be an OS.  

Well here is one definition that _some_ on this planet _do_ use:

"""Operating System (OS) - A big complicated computer program that
lets multiple simultaneously executing big complicated computer
programs coexist peacefully on one physical computer. The operating
system is also responsible for hiding the details of the computer
hardware from the application programmers, e.g., letting a programmer
say "I want to write ABC into a file named XYZ" without the programmer
having to know how many disk drives the computer has or what company
manufactured those drives. Examples of operating systems are Unix and
Windows NT. Examples of things that try to be operating systems but
mostly fail to fulfill the "coexist peacefully" condition are Windows
and the Macintosh OS."""

> I must assume that if MS-DOS falls short then CP/M
> has no chance of being an OS and NS-DOS being even simpler is who knows
> what.

Exactly, see you _can_ learn things.
0
riplin (4127)
11/10/2003 8:46:29 AM
"Randy McLaughlin" <randy482@nospam.com> wrote

> CCP/M was intended as a multi-tasking system that allows multiuser.  MP/M
> was intended as a multi-user system that did multi-tasking.  The change in
> emphasis is significant in understanding how the OS grew.

What crap.  MP/M had limited usefulness for multi-tasking due to lack
of virtualised screens.  Concurrent added virtual consoles to MP/M-86.

>  One can
> definitely say that CCP/M started out as MP/M III(86), but you must
> understand the direction changed especially toward CC-DOS.

The DOS emulation feature was an add on module called PC-MODE in
CCP/M-86 version 3.1 and this was emhanced and permanently configured
in on CDOS 4.1 and beyond.

It is simplay a matter of continuous development, adding features to
meet user needs of the time.
 
> I had several clients running on Compupro 816's running MP/M 8/16, when
> their software changed from CP/M-80 to DOS all I did was change their OS to
> CC-DOS 8/16.  I am very aware of what CCP/M & CC/DOS did and I also
> understand the thinking behind the OS's goals.

Not only did I also work with MP/M (and some of its competitors such
as Turbo-DOS) I also used CCP/M and CDOS, CDOS-386, DR-MDOS, System
Manager, Real/32 and still have clients that run these.
 
> MP/M would let you start programs in the background while CCP/M always had
> VT's.  VT's made it easier especially for people who were not computer
> geeks.  Running programs in background on MP/M left it up to the user to
> keep things straight.

Exactly, CCP/M was a better MP/M.  CDOS-386 was better again because
it virtualised the direct screen write buffers.
0
riplin (4127)
11/10/2003 9:01:02 AM
Randy McLaughlin wrote:
> 
> "Phil Dumpster" <dumpster34@yahoo.com> wrote in message
> news:3FADD5EB.BBB1B511@yahoo.com...
> >   Ever started up a TRS-80 Model III without disk drives?  The requests
> for
> > "Cass?" and "Memory Size?" come from the operating system in ROM.  The
> first one
> > sets up the cassette port for a particular operating speed, and the second
> one
> > requests the highest memory address to be used by the BASIC interpreter.
> This
> > value is passed to BASIC which uses it as its MAXRAM ceiling.  This
> operating
> > system provides numerous machine services by way of subroutines at fixed
> memory
> > addresses.  I think 0033H was the console output routine, but it's been
> many
> > years.
> >   You can do this with many other languages such as Pascal or C or Forth.
> > However, BASIC was the easiest to learn and there was a common
> implementation
> > already on the market back in the late 70s/early 80s.  One computer called
> the
> > Jupiter ACE came with Forth in ROM rather than BASIC.
> <snip>
> 
> You obviously do not understand that the OS used by many systems is an
> extended Basic.


  Randy, I'm not even going to respond to your insult by getting into an
arguement with you on something so fundamental in the evolution of
microcomputers and yet so insignificant in the grand scheme of the universe. 
Your knowledge of computer science is so beneath mine and your attitude towards
people who have more knowledge on this subject than you do makes trying to tell
you anything a complete waste of time.
0
dumpster34 (24)
11/10/2003 12:07:18 PM

Randy McLaughlin wrote:

> "Exegete" <millers@noneofyourbusiness.com> wrote in message
> news:3faf0034$1_5@corp.newsgroups.com...
> 
>>
>>Randy McLaughlin wrote:
>>
>>>"Exegete" <millers@noneofyourbusiness.com> wrote in message
>>>news:3fae88ca$1_5@corp.newsgroups.com...
>>>
>>><snip>
>>>
>>>>Not to dispute you, but some think the "640K barrier" had something to
>>>>do with DOS. DOS could access up to one meg of RAM. DOS would access all
>>>>RAM until it ran into the video memory, which was located where you
>>>>stated above.
>>>>
>>>>Roy
>>>
>>>
>>>You do not understand.  DOS does not check memory, it just asks the BIOS
> 
> for
> 
>>>top of memory.
>>
>>I'm not so sure that you understand. DOS required contiguous memory.
>>IBM's hardware design prevented DOS from having a one meg contiguous
>>address space.
>>
>>>The 640K barrier was stupid and DOS on "nonstandard" was not a limit.
>>
>>You're right. I don't understand. That last phrase at least!
>>
>>DOS
>>
>>>on S100 systems would handle one meg.
>>
>>Umm, I said that. See above.
>>
>>
>>>DOS does not require a memory mapped video.
>>
>>I never said it did. IBM's hardware design is what prevented DOS from
>>accessing a full meg of RAM.
>>
>>Roy
> 
> 
> Actually you said:
> 
> "DOS would access all RAM until it ran into the video memory".
> 
> As I stated DOS does not check for memory, DOS does not access video memory,

No shit buckwheat. I DID NOT say that DOS checked for memory, did I? YOU 
did. I said that DOS accessed all the RAM until there was a break. That 
break is the IBM video RAM, which is not contiguous with the "user" RAM.

Sheesh. Learn to read if you wish to dispute with people. There's 
nothing wrong with disagreeing with what someone says, but you look 
really dumb disagreeing with something that someone DID NOT say.

Roy

> DOS does not care about video memory.  Even the CLS function does not access
> the video memory, except through the BIOS.
> 
> My point is that you stated that DOS cares about video memory, the point may
> seem technical but you made it appear that DOS does something that it does
> not do.  I agree that IBM's design limited the address space.
> 
> 



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----
0
millers (188)
11/10/2003 1:53:11 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311100101.5e19f6@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > CCP/M was intended as a multi-tasking system that allows multiuser.
MP/M
> > was intended as a multi-user system that did multi-tasking.  The change
in
> > emphasis is significant in understanding how the OS grew.
>
> What crap.  MP/M had limited usefulness for multi-tasking due to lack
> of virtualised screens.  Concurrent added virtual consoles to MP/M-86.
>
> >  One can
> > definitely say that CCP/M started out as MP/M III(86), but you must
> > understand the direction changed especially toward CC-DOS.
>
> The DOS emulation feature was an add on module called PC-MODE in
> CCP/M-86 version 3.1 and this was emhanced and permanently configured
> in on CDOS 4.1 and beyond.
>
> It is simplay a matter of continuous development, adding features to
> meet user needs of the time.
>
> > I had several clients running on Compupro 816's running MP/M 8/16, when
> > their software changed from CP/M-80 to DOS all I did was change their OS
to
> > CC-DOS 8/16.  I am very aware of what CCP/M & CC/DOS did and I also
> > understand the thinking behind the OS's goals.
>
> Not only did I also work with MP/M (and some of its competitors such
> as Turbo-DOS) I also used CCP/M and CDOS, CDOS-386, DR-MDOS, System
> Manager, Real/32 and still have clients that run these.
>
> > MP/M would let you start programs in the background while CCP/M always
had
> > VT's.  VT's made it easier especially for people who were not computer
> > geeks.  Running programs in background on MP/M left it up to the user to
> > keep things straight.
>
> Exactly, CCP/M was a better MP/M.  CDOS-386 was better again because
> it virtualised the direct screen write buffers.

You missed two points:

Turbo-Dos (which I also developed for) was NOT an MP/M competitor.  It was
not a multiuser system.  It did NOT allow multiple people to use one
computer.  It did NOT allow one user to run multiple tasks on one computer.
It was a great OS that was a competitor to serveral other OS's, but not
MP/M.

Second when DR came out with a multitasking system with VT's they obviously
understood that it was no longer MP/M.  It was an upgrade path from MP/M,
but they knew it was exactly what they called it CCP/M.  An OS that changed
direction.  It changed direction because something had changed in the
hardware world.  Money and power, all of the IBM clones were cheap and CPU
speed was jumping.  The computers were competitive in price to dumb
terminals so it was no longer as smart an idea to hang terminals off of one
CPU.  It did make since to use one computer to do multiple things for one
user.

DR called it CCP/M.  That says it all, the direction had changed.


0
randy482 (428)
11/10/2003 4:51:11 PM
"Randy McLaughlin" <randy482@nospam.com> wrote

> > But that doesn't make the "Cassette BASIC" of a PC an "OS", as much of
> > it's "OS" was the BIOS!

> You totally misunderstand the Micro$loth Basics that have OS's integrated
> in.
> 
> IBM's BIOS DOES NOT understand files/programs.

Irrelevant. With CP/M and MS-DOS the 'Operating System' consists of
the CCP, the BDOS and the BIOS plus utilities.  It just happens that
IBM put a generalised BIOS in ROM and that PC-DOS only needs a small
interface to this.  On many other machines the MS-DOS BIOS needs to be
as extensive as it is in CP/M and the hardware only has a small Boot
Loader and perhaps a Monitor.

This means that much of the 'Operating System built into BASIC' is
simply references to the BIOS routines which actually do the work.

Your reference to BIOS not understanding files is irrelevant and
misleading.  Nor does the BASIC ROM.  ROM BASIC can't access 'files'
for the simple reason that the BIOS doesn't understand them. Nor does
the ROM BASIC understand 'programs' except as ASCII text source or
tokenised source.

> BASICA tied into the ROM Basic (GeeWhizBASIC did not) it was loaded from
> disk, but then had access to the cassette OS built into the ROM Basic.

BASICA used the ROM on a line-by-line basis for executing the code. 
The disk and file BASIC language element routines were in the
BASICA.COM program and this interfaced to MS-DOS for file access.  The
Cassette routines still used the BIOS to access the tapes.

> Micro$loth first wrote a basic that loaded from PTR and cassette.  It's file
> handling OS was not a separate program, it was the basic that was/is the OS.

There was an MS OS that had BASIC and file handling built in.  It was
'Stand-Alone BASIC' for an NCR machine (7600?).  MS BASIC for the 8080
did not have 'file handling'.  AppleSoft BASIC used the Apple ROM OS
routines for file handling.  IBM ROM BASIC did not have file handling.

> They also had a disk basic that was a disk OS, sometimes called stand-alone
> disk basic.

They had an OS with integrated BASIC called 'stand-alone BASIC'.
 
> The basic was/is the command processor.  All of the standard commands for an
> OS was available.  The disk Basic could list directory, delete, rename,
> execute binary programs, etc.  

If by Disk BASIC you mean AppleSoft or BASICA.COM, then no.  The
'standard commands' were not done by the 'ROM-BASIC OS' at all, but by
BASICA passing the command to DOS.

> The tape/ROM version had commands appropriate
> to the hardware.

Name one !!  They could do a LOAD or a SAVE, for which the BIOS
actually did the work.
 
> The Apple II's DID have a command processor, it was called Basic.

No.  It actually had a command processor.  The Apple II could use
IntegerBASIC, or AppleSoft BASIC or LOGO or Forth as its language
system, or none of these.  The system OS was separate.

I can see how someone could be confused over this though, as it would
appear to be the same thing.
 
> A more interesting system to look for the OS is the Commie line (the OS was
> kept in the disk drive, not the CPU).

And so this was 'part of BASIC' in what way ?
0
riplin (4127)
11/10/2003 5:56:32 PM
"Randy McLaughlin" <randy482@nospam.com> wrote

> To get back on topic I have never heard of any OS that was an extension of
> Pascal.

No, but then you seem to have very concrete and fixed ideas about what
is, or is not, 'an extension', 'integrated', or 'built-in', and seem
to be able to proclaim exactly whether it is or is not.

In fact with MS 'Stand Alone BASIC' and with Apple ][ with AppleSoft
BASIC the distinction between the OS and the BASIC is almost exactly
as it is between the p-system routines and the language (originally
and usually Pascal).

Yet with one you proclaim them as being 'OS in the BASIC' and the
other you proclaim as being entirely distinct.

Being adament does not make you right.
0
riplin (4127)
11/10/2003 6:12:05 PM
riplin@Azonic.co.nz (Richard) wrote:
>>  AppleSoft BASIC used the Apple ROM OS routines for file handling.

Richard,

Soory, but I don't fully agree with that )or is it just a typo?).

When accessing files on cassette tape, Applesoft Basic calls the Apple ROM
routines.

When accessing files on diskette/harddisk files, all handling is done by Apple
DOS or Prodos or the UCSD P-System - but not by the Apple ][ ROM.

The Apple ][ ROM is - in this point - very much like the IBM PC ROMs: they both
don't know anything about files, directories etc. These details are left to the
OS (AppleDos or ProDos or P-System c.q. Dos or CP/M-86).

Regards,
Freek.


email: f.heite at hccnet.nl
0
me4 (19624)
11/10/2003 6:28:57 PM
"Randy McLaughlin" <randy482@nospam.com> wrote

> You obviously do not understand that the OS used by many systems is an
> extended Basic.

Or perhaps it is you that cannot understand that a so-called 'OS' may
appear to be part of a separate language ROM.
 
> Any language can have enough extensions in it to be an OS.  

Any 'monitor' can have links into a language interpreter so that it
appears to be part of that language, to the naiive.

> An OS just needs to be able to load and execute another
> program, 

No. That is just a 'monitor' that some would like to call an 'OS'.

If a car 'only needed to have 4 wheels' then you would call a
skateboard a car.

> The fact that the IBM BIOS would check for different OS's and boot them in a
> particular order (floppy, HD, ROM) makes it an OS only on the most technical
> way.  

No. You are actually wrong.  The BIOS does not 'check for different
OS's' at all.  It neither knows nor cares what it is booting.  It only
checks to see if there is bootable code and then loads it.  This may
be a program (eg a diagnostic) or a language interpreter, or a simple
Control Program/Monitor (eg CP/M or a derivite such as MS-DOS) or it
may actually be an Operating System.
0
riplin (4127)
11/10/2003 7:05:42 PM
"Freek Heite" <me@privacy.net> wrote in message
news:3fafd6cb.6314038@News.CIS.DFN.DE...
> riplin@Azonic.co.nz (Richard) wrote:
> >>  AppleSoft BASIC used the Apple ROM OS routines for file handling.
>
> Richard,
>
> Soory, but I don't fully agree with that )or is it just a typo?).
>
> When accessing files on cassette tape, Applesoft Basic calls the Apple ROM
> routines.
>
> When accessing files on diskette/harddisk files, all handling is done by
Apple
> DOS or Prodos or the UCSD P-System - but not by the Apple ][ ROM.
>
> The Apple ][ ROM is - in this point - very much like the IBM PC ROMs: they
both
> don't know anything about files, directories etc. These details are left
to the
> OS (AppleDos or ProDos or P-System c.q. Dos or CP/M-86).
>
> Regards,
> Freek.
>
>
> email: f.heite at hccnet.nl

It is useless to communicate with the Troll.  He appears to believe that a
file only exists on disk.  The Apple II like the IBM PC came with a cassette
port.  The disk controller was an option.  When I referred to the OS in ROM
I was referring to the ability to have cassette files.  The Apple and many
other computers of the time (up to and including the PC) had cassette OS's
built in.  Other systems like Intel's Basic-52 (for the 8052 processor) use
files in memory.

The point is it does not matter if the Basic with integrated OS is a disk
based, cassette based, or even a memory based file OS; Basic can be an OS.


0
randy482 (428)
11/10/2003 8:09:20 PM
> > Hey, wait a minute! Is there a CCP/M-80?
> 
> No.

Ok, is it possible to have the features of OS-9 Level 2 or NorthStar
DOS(multiuser, multitasking) on a non-NorthStar Z80 computer that has
a console instead of terminals?
0
11/10/2003 9:13:10 PM
Richard wrote:
> 
.... snip ...
> 
> Being adament does not make you right.

Please tell that to women in general :-)

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
11/10/2003 10:36:41 PM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> You missed two points:
> 
> Turbo-Dos (which I also developed for) was NOT an MP/M competitor.  

Yes it was.  

> It was not a multiuser system.

Yes it was.  Multiple users on dumb serial terminals could access one
computer system box and share hard drive files. Exactly as MP/M except
TurboDOS used memory + CPU while MP/M used memory + bank switching.

> It did NOT allow multiple people to use one computer.

Yes it did.  That computer did need to have multiple processor boards.

> It did NOT allow one user to run multiple tasks on one computer.

Actually they could, by using multiple processor boards. Not much
different to MP/M in fact which was not much use unless the background
task kept quiet.

> It was a great OS that was a competitor to serveral other OS's, but not
> MP/M.

I worked with several systems that ran on MP/M or Turbo-DOS in much
the same way (and on Oasys and Unix/Xenix).

> Second when DR came out with a multitasking system with VT's they obviously
> understood that it was no longer MP/M.  It was an upgrade path from MP/M,

Yes, it was a better MP/M-86, a newer and upgraded system.  It still
was 'MP/M' in that it still ran existing MP/M-86 programs, it still
had the same BDOS as MP/M-86 (plus additional VC related functions)
and still had the same underlying task scheduler.

> but they knew it was exactly what they called it CCP/M.

So you think that the marketing department naming of it controlled the
development 'thinking'.  How naieve.

> An OS that changed 
> direction.  It changed direction because something had changed in the
> hardware world.  Money and power, all of the IBM clones were cheap and CPU
> speed was jumping.  The computers were competitive in price to dumb
> terminals so it was no longer as smart an idea to hang terminals off of one
> CPU.  It did make since to use one computer to do multiple things for one
> user.

Well Duh.

How come then that the _vast_majority_ of Concurrent_CP/M and CDOS
sales were on machines that had serial terminals running from them ?

ICL PC-2, ICL Quattro, ICL Quattro-XM, ICL DRS-300, Altos, Compupro,
all were basic box computers with 8 or more serial ports for dumb
terminals.  Typically the ICL amachines used ICL 6402 terminals that
were ADM-31 clones with paged memory to give 4 VCs on dumb terminals.

Concurrent-CP/M, on an IBM or clone was typically fitted with an Arnet
or Digi serial card to run Wyse 60s running in PCMODE which gave 4 VCs
to the serial terminal.

> Money and power, all of the IBM clones were cheap and CPU
> speed was jumping.  

I remember 'Turbo' clones that ran at 8 or 10 MHz compared to the 4.7
of IBM. That _really_ made a difference.

> The computers were competitive in price to dumb terminals 

What crap.  For a multiuser system in the mid 80s one required a
Novell server plus a handfull of diskless stations and the total was
more than twice that of, say, an ICL Quattro-XM plus terminals, and
the Novell solution was slower and had no multi-tasking.

> so it was no longer as smart an idea to hang terminals off of one
> CPU. 

By the time 386 and 486 machines came along we were using those as
servers.  For multiuser applications the processor speed was _never_
the issue, it was the file access speed and a multiuser box was always
faster than dragging the disk blocks over slow networks for the local
doskless workstation to use.

> It did make since to use one computer to do multiple things for one
> user.

Seeing as how multiple users could do multiple things on serial
terminals using CCP/M and CDOS then your 'alternate view' is
irrelevant.

> DR called it CCP/M.  That says it all, the direction had changed.

You seem to make up a lot from the name and your complete ignorance.
0
riplin (4127)
11/10/2003 10:44:11 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311100046.1374b0c4@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > > Assemblers like
> > > > ALS8 and some versions of Forth are examples of languages that were
> >  extended
> > > > to be an OS.
> > >
> > > And UCSD Pascal.
> >
> > UCSD Pascal was NOT an OS, it was/is a language.  The OS is written in
> > Pascal, the OS is called the p-system.
>
> So you have it that 'languages are extended to be an OS', yet that is
> _not_ the case with UCSD.
>
> > > Well if you degrade the term OS down to that level then just about
> > > anything could be made into being an 'Operating System', even a ROM
> > > monitor can do that.
> >
> > You obviously have a definition of what an OS is that is not used on
this
> > planet.
>
> Do I ?  You seem to have a definition that leads to almost anything on
> the planet can be one.
>
> > Please share with us poor idiots your definition of what a real OS
> > must have to be an OS.
>
> Well here is one definition that _some_ on this planet _do_ use:
>
> """Operating System (OS) - A big complicated computer program that
> lets multiple simultaneously executing big complicated computer
> programs coexist peacefully on one physical computer. The operating
> system is also responsible for hiding the details of the computer
> hardware from the application programmers, e.g., letting a programmer
> say "I want to write ABC into a file named XYZ" without the programmer
> having to know how many disk drives the computer has or what company
> manufactured those drives. Examples of operating systems are Unix and
> Windows NT. Examples of things that try to be operating systems but
> mostly fail to fulfill the "coexist peacefully" condition are Windows
> and the Macintosh OS."""
>
> > I must assume that if MS-DOS falls short then CP/M
> > has no chance of being an OS and NS-DOS being even simpler is who knows
> > what.
>
> Exactly, see you _can_ learn things.

Some idiots like to show how deep ignorance can reach.

We all now know:

 """Operating System (OS) - A big complicated computer program that lets
multiple simultaneously executing big complicated computer programs coexist
peacefully on one physical computer.

Sorry, I still believe that CP/M is an OS BTW what does comp.os.cpm stand
for?


0
randy482 (428)
11/10/2003 11:02:27 PM
"Randy McLaughlin" <randy482@nospam.com> wrote


> DR called it CCP/M.  That says it all, the direction had changed.

If your brilliant insights into DRIs 'direction' are true, then why
did DRI produce StarLink that turned an IBM PC with Concurrent-CP/M-86
into a multiuser system with serial terminals ?

Another direction change perhaps ? a reversal ? Or is it just that
you've been researching your keyboard ?
0
riplin (4127)
11/10/2003 11:10:41 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101444.763c2921@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > You missed two points:
> >
> > Turbo-Dos (which I also developed for) was NOT an MP/M competitor.
>
> Yes it was.
>
> > It was not a multiuser system.
>
> Yes it was.  Multiple users on dumb serial terminals could access one
> computer system box and share hard drive files. Exactly as MP/M except
> TurboDOS used memory + CPU while MP/M used memory + bank switching.
>
> > It did NOT allow multiple people to use one computer.
>
> Yes it did.  That computer did need to have multiple processor boards.
>
> > It did NOT allow one user to run multiple tasks on one computer.
>
> Actually they could, by using multiple processor boards. Not much
> different to MP/M in fact which was not much use unless the background
> task kept quiet.
>
> > It was a great OS that was a competitor to serveral other OS's, but not
> > MP/M.
>
> I worked with several systems that ran on MP/M or Turbo-DOS in much
> the same way (and on Oasys and Unix/Xenix).
>
> > Second when DR came out with a multitasking system with VT's they
obviously
> > understood that it was no longer MP/M.  It was an upgrade path from
MP/M,
>
> Yes, it was a better MP/M-86, a newer and upgraded system.  It still
> was 'MP/M' in that it still ran existing MP/M-86 programs, it still
> had the same BDOS as MP/M-86 (plus additional VC related functions)
> and still had the same underlying task scheduler.
>
> > but they knew it was exactly what they called it CCP/M.
>
> So you think that the marketing department naming of it controlled the
> development 'thinking'.  How naieve.
>
> > An OS that changed
> > direction.  It changed direction because something had changed in the
> > hardware world.  Money and power, all of the IBM clones were cheap and
CPU
> > speed was jumping.  The computers were competitive in price to dumb
> > terminals so it was no longer as smart an idea to hang terminals off of
one
> > CPU.  It did make since to use one computer to do multiple things for
one
> > user.
>
> Well Duh.
>
> How come then that the _vast_majority_ of Concurrent_CP/M and CDOS
> sales were on machines that had serial terminals running from them ?
>
> ICL PC-2, ICL Quattro, ICL Quattro-XM, ICL DRS-300, Altos, Compupro,
> all were basic box computers with 8 or more serial ports for dumb
> terminals.  Typically the ICL amachines used ICL 6402 terminals that
> were ADM-31 clones with paged memory to give 4 VCs on dumb terminals.
>
> Concurrent-CP/M, on an IBM or clone was typically fitted with an Arnet
> or Digi serial card to run Wyse 60s running in PCMODE which gave 4 VCs
> to the serial terminal.
>
> > Money and power, all of the IBM clones were cheap and CPU
> > speed was jumping.
>
> I remember 'Turbo' clones that ran at 8 or 10 MHz compared to the 4.7
> of IBM. That _really_ made a difference.
>
> > The computers were competitive in price to dumb terminals
>
> What crap.  For a multiuser system in the mid 80s one required a
> Novell server plus a handfull of diskless stations and the total was
> more than twice that of, say, an ICL Quattro-XM plus terminals, and
> the Novell solution was slower and had no multi-tasking.
>
> > so it was no longer as smart an idea to hang terminals off of one
> > CPU.
>
> By the time 386 and 486 machines came along we were using those as
> servers.  For multiuser applications the processor speed was _never_
> the issue, it was the file access speed and a multiuser box was always
> faster than dragging the disk blocks over slow networks for the local
> doskless workstation to use.
>
> > It did make since to use one computer to do multiple things for one
> > user.
>
> Seeing as how multiple users could do multiple things on serial
> terminals using CCP/M and CDOS then your 'alternate view' is
> irrelevant.
>
> > DR called it CCP/M.  That says it all, the direction had changed.
>
> You seem to make up a lot from the name and your complete ignorance.

Turbo-Dos is a great networking OS.  It does not do multitasking.

Turbo-Dos does allow sharing of drives and printers, but that was the only
resources shared.  On each processor only one task can be run.

MP/M was an OS with a totally different goal.  Both were good OS's but the
overhead on MP/M was very high making programs run slower even if it was the
only thing running.

Turbo-Dos used one processor as a master processor much as novell uses a
server reducing the user processor overhead.

When running many tasks under both MP/M and Turbo-Dos MP/M always ran
slower.  MP/M based systems were available first and usually had a much
lower ticket price than Turbo-Dos.

While they both would allow multiple people to share resources they targeted
different markets, as such they were not "competitors".


0
randy482 (428)
11/10/2003 11:14:32 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101510.63bc5ad5@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
>
> > DR called it CCP/M.  That says it all, the direction had changed.
>
> If your brilliant insights into DRIs 'direction' are true, then why
> did DRI produce StarLink that turned an IBM PC with Concurrent-CP/M-86
> into a multiuser system with serial terminals ?
>
> Another direction change perhaps ? a reversal ? Or is it just that
> you've been researching your keyboard ?

Just as CP/M lead to MP/M, MP/M-86 lead to CCP/M.  MP/M did not prevent
users from running CP/M programs and CCP/M did not prevent users from adding
terminals.  To my knowledge CCP/M did everything MP/M did, but MP/M did not
do everything CCP/M did.

There was no reversal, DR just continued along a well established branch on
their tree of products.

No one would ever say that CB80/86 was the same as Cbasic/Cbasic86.  Just
another branch.


0
randy482 (428)
11/10/2003 11:24:21 PM
>> > I must assume that if MS-DOS falls short then CP/M
>> > has no chance of being an OS and NS-DOS being even simpler is who knows
>> > what.

There is NO requirement to allow multitasking or multiuser.  However I
would maintain that CP/M is  a rudimentary OS that is one step above a
file system.  However even that is suspect, there are multiuser and/or
multitasking cp/m systems (MPM and CCPM) so the simplistic answer is
problematic.

FYI: back in the 80s I did a multicpu multitasking system that used
CP/M as the kernal.  CP/M mostly was not about what it could not do
but what it allowed you to do by not being in the way.

I'd also agree the file system of NSdos was unsophisticated but again
that did not prohibit extensions nor multitasking/multiuser systems
based on it.  The weak point for NSdos was lack of dynamic file
allocation and space recovery plus the user interface was a  primitive
"monitor" syle.  On the upside it was very compact.

I'd offer that a complete definition of OS must include the following:

	1)Device abstraction- to get the programmer away from the 
	 I/O iron.
	2)File system to manage whatever mass storage there may be.
	3)A defined set of system services that are callable in a
                     standardized way.
	4)User interface to allow managing files , starting jobs ,
	  stopping jobs plus any other housekeeping.

In CP/M those requirements are met with a:

	BIOS for item 1
	Bdos provides the facility for both 2 and 3
	CCP (or improved ZCPR) for 4


Allison
0
nospam74 (614)
11/11/2003 1:04:14 AM
<nospam@nouce.bellatlantic.net> wrote in message
news:3fb03160.103817431@news.bellatlantic.net...
>
> >> > I must assume that if MS-DOS falls short then CP/M
> >> > has no chance of being an OS and NS-DOS being even simpler is who
knows
> >> > what.
>
> There is NO requirement to allow multitasking or multiuser.  However I
> would maintain that CP/M is  a rudimentary OS that is one step above a
> file system.  However even that is suspect, there are multiuser and/or
> multitasking cp/m systems (MPM and CCPM) so the simplistic answer is
> problematic.
>
> FYI: back in the 80s I did a multicpu multitasking system that used
> CP/M as the kernal.  CP/M mostly was not about what it could not do
> but what it allowed you to do by not being in the way.
>
> I'd also agree the file system of NSdos was unsophisticated but again
> that did not prohibit extensions nor multitasking/multiuser systems
> based on it.  The weak point for NSdos was lack of dynamic file
> allocation and space recovery plus the user interface was a  primitive
> "monitor" syle.  On the upside it was very compact.
>
> I'd offer that a complete definition of OS must include the following:
>
> 1)Device abstraction- to get the programmer away from the
> I/O iron.
> 2)File system to manage whatever mass storage there may be.
> 3)A defined set of system services that are callable in a
>                      standardized way.
> 4)User interface to allow managing files , starting jobs ,
>   stopping jobs plus any other housekeeping.
>
> In CP/M those requirements are met with a:
>
> BIOS for item 1
> Bdos provides the facility for both 2 and 3
> CCP (or improved ZCPR) for 4
>
>
> Allison

You missed the point.  I made a new topic to show an idiot as an idiot.
CP/M is a good OS.  It was not intended to browse the internet.  It was an
8K OS that allowed people with at least 24K of ram to run standardized
software.

Many programmers did many things with it.  It was even just used as a loader
for other OS's.

I agree with only two of the four functions you mention:  It should do items
2 & 4.

An OS needs to do no more than select another program to run.  It does not
even require a keyboard or mouse.  When I switched from mainframes to
micro's my first 8080 OS was Cutter.  I had a CUTS board with both Cutter &
ALS8.  Cutter was a cassette OS.  It was a full OS that could do a directory
of its media (list the files on tape), load a file into RAM, or load &
execute programs.  It was a great 2K OS.


0
randy482 (428)
11/11/2003 1:43:57 AM
"Randy McLaughlin" <randy482@nospam.com> wrote

> It is useless to communicate with the Troll.  He appears to believe that a
> file only exists on disk.  The Apple II like the IBM PC came with a cassette
> port.  The disk controller was an option.  When I referred to the OS in ROM
> I was referring to the ability to have cassette files.  

It is arguable whether a cassette tape is a 'file' or is merely a
series of byte values that can be read and interpreted in any way one
pleases.

You seem to want to call a tape a 'file' just so that you can 'prove'
that ROM BASIC can handle 'files'.  A purely semantic argument.

In fact all that can be done with cassetes is start/stop/read/write. 
This does not count as 'files'.

> The point is it does not matter if the Basic with integrated OS is a disk
> based, cassette based, or even a memory based file OS; Basic can be an OS.

Not in your mind, no.  But then it seems that anything not in your
mind doesn't matter.

The real point is that when running BASICA.COM it is _not_ BASIC that
is the OS, it is MS-DOS.  It is _not_ ROM BASIC that is doing any OS
function, it is BASICA that is asking MS-DOS to do it.

When running IBM ROM BASIC there is no 'OS' functionality at all
beyond the BIOS routines of starting and stopping the cassette tape
and putting characters on the screen.
0
riplin (4127)
11/11/2003 1:57:22 AM
"Randy McLaughlin" <randy482@nospam.com> wrote


> Sorry, I still believe that CP/M is an OS BTW what does comp.os.cpm stand
> for?

ROFL.  CP/M stands for Control Program/Monitor.  Gary knew better than
to try to call it an Operating System.  Apparently you do not.
0
riplin (4127)
11/11/2003 2:04:15 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101757.41aa8f2f@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > It is useless to communicate with the Troll.  He appears to believe that
a
> > file only exists on disk.  The Apple II like the IBM PC came with a
cassette
> > port.  The disk controller was an option.  When I referred to the OS in
ROM
> > I was referring to the ability to have cassette files.
>
> It is arguable whether a cassette tape is a 'file' or is merely a
> series of byte values that can be read and interpreted in any way one
> pleases.
>
> You seem to want to call a tape a 'file' just so that you can 'prove'
> that ROM BASIC can handle 'files'.  A purely semantic argument.
>
> In fact all that can be done with cassetes is start/stop/read/write.
> This does not count as 'files'.
>
> > The point is it does not matter if the Basic with integrated OS is a
disk
> > based, cassette based, or even a memory based file OS; Basic can be an
OS.
>
> Not in your mind, no.  But then it seems that anything not in your
> mind doesn't matter.
>
> The real point is that when running BASICA.COM it is _not_ BASIC that
> is the OS, it is MS-DOS.  It is _not_ ROM BASIC that is doing any OS
> function, it is BASICA that is asking MS-DOS to do it.
>
> When running IBM ROM BASIC there is no 'OS' functionality at all
> beyond the BIOS routines of starting and stopping the cassette tape
> and putting characters on the screen.

Tape files are well documented.  My first experience was 9-track 800 bpi
tape files on a mainframe (SDS Sigma-5 using wang drives).  Please remember
tape files are even used on PC's (ever heard of TAR).

Many early computers did not even have disk drives, the only mass storage
was tape.  In college the computer I used in a fortran class had no disk
drive.  It was a honeywell computer with two tape drives, a 029 card reader,
a teletype, and a printer.

Below is a link to an early 8080 audio cassette tape based OS:

http://www.thebattles.net/sol20/sol.html

It documents it's tape files.  There were many tape OS's, some based on
audio cassettes some based on digital tapes.

You like many others are so used to thinking of disks you do not think of
what other media formats there are.

I agree that basica.com is not an OS, but the PC's ROM basic does not
require PC-DOS to run and it does handle cassette files.


0
randy482 (428)
11/11/2003 2:14:47 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101804.695da7cc@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
>
> > Sorry, I still believe that CP/M is an OS BTW what does comp.os.cpm
stand
> > for?
>
> ROFL.  CP/M stands for Control Program/Monitor.  Gary knew better than
> to try to call it an Operating System.  Apparently you do not.

Apparently whoever created the group thought it was on OS also :-).


0
randy482 (428)
11/11/2003 2:17:47 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> > > It was not a multiuser system.
 
> Turbo-Dos is a great networking OS.  It does not do multitasking.

Turbo-DOS _is_ a multi-user system.  There was no claim that it needed
to do multi-tasking to achieve this.  The way that the various
processes communicate is irrelevant.

You were wrong when you claimed it was not a competitor to MP/M, you
were wrong when you claimed it was not a multiuser system.

Saying that it 'networked' [sic] and did not multitask on each
processor is irrelevant.  In fact, technically, it wasn't a networking
OS either.  It used bus arbitration to communicate.
 
> Turbo-Dos does allow sharing of drives and printers, but that was the only
> resources shared.  On each processor only one task can be run.

Actually it shared the power supply and the bus and the cabinet work
beacuse it was one computer system.

Many computer systems have multiple processors. Turbo-DOS just happens
to use them in one particular way.

> MP/M was an OS with a totally different goal.  

No. They were both multiuser systems for small business users.  They
used different hardware but ran the same applications and the same
user terminals.

> Both were good OS's but the
> overhead on MP/M was very high making programs run slower even if it was the
> only thing running.

The 'overhead' on MP/M was remarkably low.  Even when running 3 users
in business applications (byte coded Cobol) there was always free CPU
cycles available.
 
> Turbo-Dos used one processor as a master processor much as novell uses a
> server reducing the user processor overhead.

Much as you wish to draw a parallel between Turbo-DOS and a real
network this just highlights the inefficiencies of the clients in both
cases.

With Turbo-DOS if a client process requested a disk access that whole
program and CPU was blocked awaiting the completion of that request
(just as it would be in CP/M and MS-DOS).  All the CPU cycles were
wasted. The same happened when a MS-DOS client program made a request
to the Novell Server - all CPU cycles were lost.

With MP/M and all derivitives on appropriate hardware, the disk
request from a program initiated the disk controller, blocked the
requesting process, and then got on with other tasks.  When the
controller started transferring data it did cycle stealing to put the
bytes in memory.  When the transfer completed the blocked task was put
back on the scheduler queue for its priority and so it continued to be
run.

While Turbo-DOS _wasted_ its CPU power, MP/M recovered it.  Certainly
Turbo-DOS could outperform MP/M systems when running several CPU
intensive programs, but it fell behind on business systems which were
disk intensive.

(Based on actual performance measuring when comparing several systems
running the same business applications).

> When running many tasks under both MP/M and Turbo-Dos MP/M always ran
> slower.  

Not true, it depended entirely on the actual hardware specs and on
what the application was doing.

> MP/M based systems were available first and usually had a much
> lower ticket price than Turbo-Dos.
 
Depending on specification, of course, and that affected performance. 
If you spent more you got a faster system.

> While they both would allow multiple people to share resources they targeted
> different markets, 

How different is 'small business multiuser' from 'small business
multiuser' ?

> as such they were not "competitors".

Yeah, right, and Toyotas are not competitors to Fords.
0
riplin (4127)
11/11/2003 2:39:27 AM
"Randy McLaughlin" <randy482@nospam.com> wrote

> > "Randy McLaughlin" <randy482@nospam.com> wrote
> > > DR called it CCP/M.  That says it all, the direction had changed.

> Just as CP/M lead to MP/M, MP/M-86 lead to CCP/M.  MP/M did not prevent
> users from running CP/M programs and CCP/M did not prevent users from adding
> terminals.  To my knowledge CCP/M did everything MP/M did, but MP/M did not
> do everything CCP/M did.

Normal progression then, so where was 'the direction had changed'
claim ?
 
> There was no reversal, 

There was no 'reversal' with StarLink because there was no 'direction
change' with Concurrent CP/M-86.

> DR just continued along a well established branch on
> their tree of products.

Exactly.  MP/M -> MP/M II -> MP/M-86 -> Multiuser CCP/M-86 / Starlink
-> CDOS -> CDOS-386 -> DR-Multiuser-DOS.

So where was this 'direction had changed' claim that no one else saw
and now seems to have disappeared ?

BTW there was no MP/M III that you claimed.  MP/M-86 was an
implementation of MP/M II.

Of course this was just one branch of their tree of products.  It
spouted twigs such as DOS Plus (a derivitive of CDOS, not of CP/M-86),
DR-DOS 3.x, DR-DOS 5 and beyond.

Another branch was the FlexOS range.
 
> No one would ever say that CB80/86 was the same as Cbasic/Cbasic86.  Just
> another branch.

The relevence being ?
0
riplin (4127)
11/11/2003 2:51:33 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101851.5dc5da25@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > "Randy McLaughlin" <randy482@nospam.com> wrote
> > > > DR called it CCP/M.  That says it all, the direction had changed.
>
> > Just as CP/M lead to MP/M, MP/M-86 lead to CCP/M.  MP/M did not prevent
> > users from running CP/M programs and CCP/M did not prevent users from
adding
> > terminals.  To my knowledge CCP/M did everything MP/M did, but MP/M did
not
> > do everything CCP/M did.
>
> Normal progression then, so where was 'the direction had changed'
> claim ?
>
> > There was no reversal,
>
> There was no 'reversal' with StarLink because there was no 'direction
> change' with Concurrent CP/M-86.
>
> > DR just continued along a well established branch on
> > their tree of products.
>
> Exactly.  MP/M -> MP/M II -> MP/M-86 -> Multiuser CCP/M-86 / Starlink
> -> CDOS -> CDOS-386 -> DR-Multiuser-DOS.
>
> So where was this 'direction had changed' claim that no one else saw
> and now seems to have disappeared ?
>
> BTW there was no MP/M III that you claimed.  MP/M-86 was an
> implementation of MP/M II.
>
> Of course this was just one branch of their tree of products.  It
> spouted twigs such as DOS Plus (a derivitive of CDOS, not of CP/M-86),
> DR-DOS 3.x, DR-DOS 5 and beyond.
>
> Another branch was the FlexOS range.
>
> > No one would ever say that CB80/86 was the same as Cbasic/Cbasic86.
Just
> > another branch.
>
> The relevence being ?

I'm tired of such a stupid troll, so here is the final post on this subject.

CCP/M changed direction by adding virtual termainals.  Just as when MP/M
added so much over CP/M the ability for average PC users to switch to a
different tasks was close to a miracle at the time.  This allowed any office
worker such as a secretary to have multiple programs running long before
windows.  With MP/M the average user could not use multitasking.

The big change was in changing the emphasis from multiuser to multitasking.
Of course it did not eliminate the ability to be a multiuser program.

Mentioning DR's compiler basics was to show that DR followed logical paths
from product to product.  Cbasic was a good basic that unlike Micro$loth
could actually add one plus one and come up with two.  Later they came out
with CB80, it was an upwards compatable compiler; but when DR came out with
CP/M-86 they came out with both Cbasic-86 and CB86.  They came out with
Cbasic-86 mainly to support the thousands of programs already running in the
eight bit Cbasic.

Remember that DR dropped products when they came out with newer versions of
the same software. DR continued to sell CP/M-86 & MP/M-86 even after coming
out with CCP/M-86, just like they continued to sell Cbasic after coming out
with a better compiler (CB80/CB86).  That alone shows that DR considered
CCP/M a separate product.


0
randy482 (428)
11/11/2003 4:10:27 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101839.32c963cb@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > > It was not a multiuser system.
>
> > Turbo-Dos is a great networking OS.  It does not do multitasking.
>
> Turbo-DOS _is_ a multi-user system.  There was no claim that it needed
> to do multi-tasking to achieve this.  The way that the various
> processes communicate is irrelevant.
>
> You were wrong when you claimed it was not a competitor to MP/M, you
> were wrong when you claimed it was not a multiuser system.
>
> Saying that it 'networked' [sic] and did not multitask on each
> processor is irrelevant.  In fact, technically, it wasn't a networking
> OS either.  It used bus arbitration to communicate.

It was a networking OS, it did NOT use bus arbitration.  The way that the
network was implimented varied some used different cabling systems varying
from RS-422 to Arcnet and most used S100 single board computers that
networked by acting as I/O ports on the bus (not through arbitration at
all).  BTW Novell could also be networked via ISA single board computers
plugged into a Novel server.

>
> > Turbo-Dos does allow sharing of drives and printers, but that was the
only
> > resources shared.  On each processor only one task can be run.
>
> Actually it shared the power supply and the bus and the cabinet work
> beacuse it was one computer system.

Ask anyone that ran Turbo-Dos on their Televideo TS800 or TS1600 series
systems as well as any using Arcnet and you will find that you know very
little about Turbo-Dos.

>
> Many computer systems have multiple processors. Turbo-DOS just happens
> to use them in one particular way.
>
> > MP/M was an OS with a totally different goal.
>
> No. They were both multiuser systems for small business users.  They
> used different hardware but ran the same applications and the same
> user terminals.

Both were for small bussinesses usually running CP/M compatable software but
Turbo-Dos could run 8 bit CP/M software on some computers, CP/M-86 on other
computers, and PC-DOS software on others very efficiently.  CompuPro had a
modified MP/M-86 that could run both CP/M-80 & CP/M-86 software on the same
terminal, but much slower than a Turbo-Dos system.  The CompuPro was
appropriate if the users needed to run both 8 bit & 16 bit software on the
same terminal and Turbo-Dos was better when each user could use homogenuus
software and the budget was bigger.

The decision to use either MP/M or Turbo-Dos was made early since the market
was different for each.

>
> > Both were good OS's but the
> > overhead on MP/M was very high making programs run slower even if it was
the
> > only thing running.
>
> The 'overhead' on MP/M was remarkably low.  Even when running 3 users
> in business applications (byte coded Cobol) there was always free CPU
> cycles available.

The question is not whether there were free CPU cycles, the point is that if
multi-user and multi-tasking is not needed would the program run faster on
CP/M.  The answer is yes, always; that it strictly because of the overhead
of MP/M.

>
> > Turbo-Dos used one processor as a master processor much as novell uses a
> > server reducing the user processor overhead.
>
> Much as you wish to draw a parallel between Turbo-DOS and a real
> network this just highlights the inefficiencies of the clients in both
> cases.
>
> With Turbo-DOS if a client process requested a disk access that whole
> program and CPU was blocked awaiting the completion of that request
> (just as it would be in CP/M and MS-DOS).  All the CPU cycles were
> wasted. The same happened when a MS-DOS client program made a request
> to the Novell Server - all CPU cycles were lost.

Wrong, Turbo-Dos would continue to do other things during disk I/O.  The
print spooler would continue to print while disk I/O was taking place and
disk writed did not need to complete for the slave computer to continue.

>
> With MP/M and all derivitives on appropriate hardware, the disk
> request from a program initiated the disk controller, blocked the
> requesting process, and then got on with other tasks.  When the
> controller started transferring data it did cycle stealing to put the
> bytes in memory.  When the transfer completed the blocked task was put
> back on the scheduler queue for its priority and so it continued to be
> run.
>
> While Turbo-DOS _wasted_ its CPU power, MP/M recovered it.  Certainly
> Turbo-DOS could outperform MP/M systems when running several CPU
> intensive programs, but it fell behind on business systems which were
> disk intensive.

Turbo-Dos was much more efficient at file processing than MP/M.  At no time
would MP/M run as fast as Turbo-Dos when the compared systems had similiar
speed hardware (CPU and disk).

>
> (Based on actual performance measuring when comparing several systems
> running the same business applications).
>
> > When running many tasks under both MP/M and Turbo-Dos MP/M always ran
> > slower.
>
> Not true, it depended entirely on the actual hardware specs and on
> what the application was doing.
>
> > MP/M based systems were available first and usually had a much
> > lower ticket price than Turbo-Dos.
>
> Depending on specification, of course, and that affected performance.
> If you spent more you got a faster system.
>
> > While they both would allow multiple people to share resources they
targeted
> > different markets,
>
> How different is 'small business multiuser' from 'small business
> multiuser' ?
>
> > as such they were not "competitors".
>
> Yeah, right, and Toyotas are not competitors to Fords.

Toyota Celica's are not competitors to Ford F350's.

MP/M was a multiuser OS that has advantages over networking OS's.  Turbo-Dos
as a networking OS has advantages over multiuser OS's.  It all depends on
the needs of the customer.


0
randy482 (428)
11/11/2003 4:46:59 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311101105.5fbac98a@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > You obviously do not understand that the OS used by many systems is an
> > extended Basic.
>
> Or perhaps it is you that cannot understand that a so-called 'OS' may
> appear to be part of a separate language ROM.
>
> > Any language can have enough extensions in it to be an OS.
>
> Any 'monitor' can have links into a language interpreter so that it
> appears to be part of that language, to the naiive.
>
> > An OS just needs to be able to load and execute another
> > program,
>
> No. That is just a 'monitor' that some would like to call an 'OS'.
>
> If a car 'only needed to have 4 wheels' then you would call a
> skateboard a car.
>
> > The fact that the IBM BIOS would check for different OS's and boot them
in a
> > particular order (floppy, HD, ROM) makes it an OS only on the most
technical
> > way.
>
> No. You are actually wrong.  The BIOS does not 'check for different
> OS's' at all.  It neither knows nor cares what it is booting.  It only
> checks to see if there is bootable code and then loads it.  This may
> be a program (eg a diagnostic) or a language interpreter, or a simple
> Control Program/Monitor (eg CP/M or a derivite such as MS-DOS) or it
> may actually be an Operating System.

Look up some different OS's like SOLOS (a nice 2K OS).

The BIOS checked for OS's depending on hardware:  If there is a diskette in
the "A" drive the OS on that drive will load, if there is no diskette loaded
and there is a hard drive the OS marked to boot on it will load, if none of
the above then ROM basic would load.


0
randy482 (428)
11/11/2003 5:00:17 AM
Richard wrote:
> 
.... snip ...
> 
> It is arguable whether a cassette tape is a 'file' or is merely a
> series of byte values that can be read and interpreted in any way
> one pleases.
> 
> You seem to want to call a tape a 'file' just so that you can
> 'prove' that ROM BASIC can handle 'files'.  A purely semantic
> argument.
> 
> In fact all that can be done with cassetes is
> start/stop/read/write. This does not count as 'files'.

And all that can be done with hard disks (or floppies) is to
read/write/seek.  Both can be used as the basis for a file
system.  Tapes and cassettes do not have a random access
attribute, and algorithms need to be designed accordingly.  For an
outstanding example look up polyphase mergesort some time.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


0
cbfalconer (19194)
11/11/2003 5:16:46 AM
CBFalconer wrote:
> 
> Richard wrote:
> >
> ... snip ...
> >
> > Being adament does not make you right.
> 
> Please tell that to women in general :-)
 

    ROTFLMAO!!
0
dumpster34 (24)
11/11/2003 5:34:26 AM
"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:3FB06A70.EE863264@yahoo.com...
> Richard wrote:
> >
> ... snip ...
> >
> > It is arguable whether a cassette tape is a 'file' or is merely a
> > series of byte values that can be read and interpreted in any way
> > one pleases.
> >
> > You seem to want to call a tape a 'file' just so that you can
> > 'prove' that ROM BASIC can handle 'files'.  A purely semantic
> > argument.
> >
> > In fact all that can be done with cassetes is
> > start/stop/read/write. This does not count as 'files'.
>
> And all that can be done with hard disks (or floppies) is to
> read/write/seek.  Both can be used as the basis for a file
> system.  Tapes and cassettes do not have a random access
> attribute, and algorithms need to be designed accordingly.  For an
> outstanding example look up polyphase mergesort some time.
>
> -- 
> Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
>    Available for consulting/temporary embedded and systems.
>    <http://cbfalconer.home.att.net>  USE worldnet address!

I agree except some tape drives do allow random access, not that random
access is needed for something to be called a file.

Files have no more limitation than the programmer, whether the file is kept
on disk, tape, ROM (and derivatives), or what ever.

File systems like CUTS allow multiple files on a tape accessed by name, file
systems like that used by Basic-52 (8052 control basic) access files in ROM
by number.


0
randy482 (428)
11/11/2003 5:51:58 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> > When running IBM ROM BASIC there is no 'OS' functionality at all
> > beyond the BIOS routines of starting and stopping the cassette tape
> > and putting characters on the screen.
> 
> Tape files are well documented.  My first experience was 9-track 800 bpi
> tape files on a mainframe (SDS Sigma-5 using wang drives).  Please remember
> tape files are even used on PC's (ever heard of TAR).

Cassettes have no similarity at all to Tape file on real computers. 
You appear to think that because they are both magnetic tapes that
therefore the ROM BASIC is like IBM's TOS.
 
> Many early computers did not even have disk drives, the only mass storage
> was tape.  In college the computer I used in a fortran class had no disk
> drive.  It was a honeywell computer with two tape drives, a 029 card reader,
> a teletype, and a printer.

An 029 is not a 'card reader' it is a card punch unit and was not
connected to the computer.

> You like many others are so used to thinking of disks you do not think of
> what other media formats there are.

I can probably still load an ICL 1971 Tape deck blindfolded, just as I
did in the 60s.

> I agree that basica.com is not an OS, but the PC's ROM basic does not
> require PC-DOS to run and it does handle cassette files.

No. It doesn't handle 'files'.  Unlike real tape drives the cassette
tape could just read or write a stream of bytes with interblock gaps. 
Now the Epson PX-80 had a real tape deck that supported files, with
names and everything.  Not the IBM cassttte deck.  But I doubt that
you even used one of either anyway.
0
riplin (4127)
11/11/2003 8:49:49 AM
"Randy McLaughlin" <randy482@nospam.com> wrote

> > ROFL.  CP/M stands for Control Program/Monitor.  Gary knew better than
> > to try to call it an Operating System.  Apparently you do not.
> 
> Apparently whoever created the group thought it was on OS also :-).

You do seem to place rather an undue relevance to the names of things.

Do you put oats into the grill of a Mustang ?
0
riplin (4127)
11/11/2003 8:52:04 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311110049.1879a53d@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > When running IBM ROM BASIC there is no 'OS' functionality at all
> > > beyond the BIOS routines of starting and stopping the cassette tape
> > > and putting characters on the screen.
> >
> > Tape files are well documented.  My first experience was 9-track 800 bpi
> > tape files on a mainframe (SDS Sigma-5 using wang drives).  Please
remember
> > tape files are even used on PC's (ever heard of TAR).
>
> Cassettes have no similarity at all to Tape file on real computers.
> You appear to think that because they are both magnetic tapes that
> therefore the ROM BASIC is like IBM's TOS.

Please continue to show your ignorance and explain which of the tape formats
are real and which are not.  Is it what color plastic the case is made of by
any chance?

>
> > Many early computers did not even have disk drives, the only mass
storage
> > was tape.  In college the computer I used in a fortran class had no disk
> > drive.  It was a honeywell computer with two tape drives, a 029 card
reader,
> > a teletype, and a printer.
>
> An 029 is not a 'card reader' it is a card punch unit and was not
> connected to the computer.

Actually anyone that ever used a card punch is aware that IBM had two
standards for 80 column cards, name 026 & 029.  Their cards had a few
differences in mapping punches to their respective holerith code (EBCIDIC)
so anyone that ever used punch cards always refered to which punch format
was used, in the above reader it was an 029 format reader.  Some card
readers had switches to select the format, but usually if you had a deck of
the wrong format it was easiest to copy them to tape converting the
individual code as they were read.

>
> > You like many others are so used to thinking of disks you do not think
of
> > what other media formats there are.
>
> I can probably still load an ICL 1971 Tape deck blindfolded, just as I
> did in the 60s.
>
> > I agree that basica.com is not an OS, but the PC's ROM basic does not
> > require PC-DOS to run and it does handle cassette files.
>
> No. It doesn't handle 'files'.  Unlike real tape drives the cassette
> tape could just read or write a stream of bytes with interblock gaps.
> Now the Epson PX-80 had a real tape deck that supported files, with
> names and everything.  Not the IBM cassttte deck.  But I doubt that
> you even used one of either anyway.

Actually it handles files as files.  Actually like most trives used today
the PC uses a stream of bits not bytes.  They do have names and everything
(which is not a requirement of being a file), they have structure, and most
importantly the computer strings the bits into an stream of data.


0
randy482 (428)
11/11/2003 4:32:35 PM
>>
>> > Sorry, I still believe that CP/M is an OS BTW what does comp.os.cpm
> stand
>> > for?
>>
>> ROFL.  CP/M stands for Control Program/Monitor.  Gary knew better than
>> to try to call it an Operating System.  Apparently you do not.
> 
> Apparently whoever created the group thought it was on OS also :-).
>
I second the fact Gary first called CP/M "Control Program/Monitor", and
later renamed the M for "for Microcomputers". I've seen it in some
litterature.

However, no matter the name, CP/M is certainly a true OS. In fact, anything
that boots a computer, mini, or micro-computer and interprets your commands
is an OS.
If you have old games on diskettes that boot the PC, say like Digger,
Moon Patrol, etc... These boot the PC, so they're considered as true OSs
as well, because they don't need something else (some other OS like CP/M
or DOS) to function. It's standalone. IBM ROM BASIC (Cassette BASIC) is
also an OS, but limited to the ROM and Cassette player and is not designed
(to my knowledge) to drive other disks.

However, I'm not so sure Windows 95/98/ME is a true OS as people who didn't know
DOS or CP/M might think. When you load Windows, DOS comes first (even
though Microsoft wants to hide it), and when you quit Windows, the
option "Restart in MS-DOS mode" means closing Windows and return to DOS
W/O rebooting. So Windows is an application for DOS, just like LOTUS 1-2-3
or the old WordPerfect 5.1.
Newer WIndows might be true OS, if they base on NT, but I can't say for sure.

Louis-Luc
 
0
leguerri (14)
11/11/2003 4:47:54 PM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> I'm tired of such a stupid troll, so here is the final post on this subject.

ROFL.
 
> CCP/M changed direction by adding virtual termainals.  
> The big change was in changing the emphasis from multiuser to multitasking.

> to show that DR followed logical paths from product to product.

I agree that DRI followed logical paths for its products.  I see a
logical path through from MP/M to DR-MDOS.

There is just no 'changed direction'.

Your 'change' appeared to be based on changing to single-user
multi-tasking, which never happened. In fact you probably never knew
that VCs could be done on serial terminals, and that was where
CCP/M-86 had its market.

> Remember that DR dropped products when they came out with newer versions of
> the same software. DR continued to sell CP/M-86 & MP/M-86 even after coming
> out with CCP/M-86,

Actually they didn't.  _Compupro_ continued to sell MP/M-816 products
after DRI released CCP/M-86, but that is because the only significant
change in the product could not be implemented until serial terminals
with appropriate features could be incorporated.
0
riplin (4127)
11/11/2003 5:29:20 PM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> It was a networking OS, it did NOT use bus arbitration.

8 bit TurboDOS (the one that ran CP/M software and competed with MP/M)
was a slave processor system.  Each computer running TurboDOS had a
master processor and several slave processor cards.  Each slave had a
serial terminal for a user.  The master processor controlled access to
the disk drive, printers and other devices.

Later there was a 16 bit TurboDOS that used the same architecture.

"""The TurboDOS operating system is a product of Software 2000, Inc.,
....
 we have used TurboDOS in conjunction with various slave processor
boards to construct a wide variety of S-100 based computer systems,
ranging from two to over sixty users"""

> The way that the
> network was implimented varied some used different cabling systems varying
> from RS-422 to Arcnet and most used S100 single board computers that
> networked by acting as I/O ports on the bus (not through arbitration at
> all). 

Now as it happens, TurboDOS can _also_ be networked with masters
sending requests to other masters thereby sharing disk drives between
multiple multiuser machines.  But then so can DRI multiuser systems be
networked together using CP/NET or DR-NET.

I have a stack of ICL DRS300s here which ran CDOS (and/or Unix) using
SCSI to connect several processors, disk drives, etc and used
'microNet' for the terminals.  It ran DR-NET over both carriers.

> Both were for small bussinesses usually running CP/M compatable software but
> Turbo-Dos could run 8 bit CP/M software on some computers, CP/M-86 on other
> computers, and PC-DOS software on others very efficiently.

You have a strange view of 'efficiently'.  The CPU was wasted
everytime the program went to get disk blocks.

> The decision to use either MP/M or Turbo-Dos was made early since the market
> was different for each.

Yeah, right.  You seem to have a definition of 'market' that is
unique.  You seem to be selling the same software but choosing to
offer MP/M for the 2-4 users and TurboDOS for the 4-10 users, or ones
with bigger budgets.

That's like saying that 'families with 2 cars' is a completely
different market than 'families with 3 cars'.
 
> The question is not whether there were free CPU cycles, the point is that if
> multi-user and multi-tasking is not needed would the program run faster on
> CP/M.  The answer is yes, always; that it strictly because of the overhead
> of MP/M.

Actually you are talking complete crap.  I doubt that you ever
bothered to measure it.

With CP/M (2.2) there was only 64Kb available.  With MP/M the program
ran in one bank and MP/M in another, or others.  This allowed the
system to use RAM for extra buffering.  While there was a small loss
of CPU cycles if the program only did calculations (around 5%), there
was a gain if the program did real work such as disk accesses or
printing (this is small business market) because of the buffering
saving disk transfers.

As it was a multiuser system, then claiming anything about single user
performance is irrelevant anyway.

> Wrong, Turbo-Dos would continue to do other things during disk I/O.  

The master processor would, the slave processors would, but client
processors waiting for disk transfers would block waiting for
completion.

> The
> print spooler would continue to print while disk I/O was taking place 

Well it wasn't completely useless then  ;-)

> disk writed did not need to complete for the slave computer to continue.

Maybe not (I suspect that was a later 16 bit change), but slave
processors that had queued transfers waiting to even start still
blocked.

> Turbo-Dos was much more efficient at file processing than MP/M.  At no time
> would MP/M run as fast as Turbo-Dos when the compared systems had similiar
> speed hardware (CPU and disk).

Of course the TuboDOS was more expensive and had more hardware for the
same number of users.  Given the same _cost_ the MP/M system could
outperform the TurboDOS one.  Of course more expensive machines gave
more performance.

> MP/M was a multiuser OS that has advantages over networking OS's.  Turbo-Dos
> as a networking OS has advantages over multiuser OS's.  It all depends on
> the needs of the customer.

Both were multi-user systems that could be networked.
0
riplin (4127)
11/11/2003 6:23:19 PM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> Apparently whoever created the group thought it was on OS also :-).

No. Whoever created the comp.os.cpm group did not think it worthwhile
to bother creating a comp.not_quite_an_os. hierarchy.

You may also want to note that there _isn't_ a comp.os.basic (of
either meaning). Are we to conclude from this that therefore no one
with two clues to rub together ever considered that BASIC was an OS ?

Well, yes, actually     ;-)
0
riplin (4127)
11/11/2003 8:26:50 PM
Richard <riplin@azonic.co.nz> wrote:
> "Randy McLaughlin" <randy482@nospam.com> wrote 
> 
>> Apparently whoever created the group thought it was on OS also :-).
> 
> No. Whoever created the comp.os.cpm group did not think it worthwhile
> to bother creating a comp.not_quite_an_os. hierarchy.
>
What makes you think CP/M is not quite an OS? I'm sure BASIC is an OS
when it boots the machine (either from disk, tape or ROM, or even
punched cards...)

And if CP/M is not an OS, then there must be something else on top of which
it runs.

Louis-Luc 
0
leguerri (14)
11/11/2003 8:36:14 PM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> It was a networking OS, it did NOT use bus arbitration.  The way that the
> network was implimented varied some used different cabling systems varying
> from RS-422 to Arcnet and most used S100 single board computers that
> networked by acting as I/O ports on the bus (not through arbitration at
> all).  

When computers are connected using ethernet they ensure that only one
talks at a time using collision detection.  With arcnet this is
ensured by using token passing.

When several slave processors are in the same S100 or ISA bus as the
master is and they are sending messages to each other via the bus they
ensure that only one is talking at one time by using ..... ?

(Extra points granted for naming each S-100 bus pin).
0
riplin (4127)
11/11/2003 9:08:38 PM
> In fact, anything that boots a computer, mini, or micro-computer
> and interprets your commands is an OS.

What's your take on pSOS or RTOS, which are used in imbedded systems and
generally don't have command interpreters, file systems or hardware
isolation?

At least in the applicaitons I worked on, we used these for their message
passing, task scheduling and resource managmenet capabilities.

    - Bill


0
Bill_Leary (360)
11/11/2003 9:38:59 PM
Richard wrote in message...

> > Sorry, I still believe that CP/M is an OS BTW what does comp.os.cpm stand
> > for?
 
> ROFL.  CP/M stands for Control Program/Monitor.  Gary knew better than
> to try to call it an Operating System.  Apparently you do not.

We have a lot of OSes for our computer, some of which have been
branded as xDOS (the x can be whatever the rest of the name is),
because they provide new disk formats to support newer disk formats.

The one thing plan vanilla CP/M doesn't do on our Amstrad is create
other disk formats, but still it would be stupid to have AMSDOS (the
OS at switch on) & CP/M doing this!

It has been shown though that other disk formats are possible to
develop under CP/M, since one of the copies I have of it is used to
access more drives & differently formatted disks.

So what's this thing I hear now which states that CP/M isn't an OS?

If CP/M isn't a OS, then DOS isn't either! ;-)

But of course I could be mistaken, since Alley Cat is a game which
runs itself from Bootup.

Cheers,
Ross.
0
11/11/2003 9:46:20 PM
"Randy McLaughlin" wrote in message...

> I agree except some tape drives do allow random access, not that random
> access is needed for something to be called a file.

Yeah, but what is random, Randy? 

Is it something for which we cannot perdict & that in time, algorithms
may make them seem so perdictable! ;-)
 
Cheers,
Ross.
0
11/11/2003 9:54:04 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311111308.330ce5ac@posting.google.com...
>
> When several slave processors are in the same S100 or ISA bus as the
> master is and they are sending messages to each other via the bus they
> ensure that only one is talking at one time by using ..... ?
>
If the slave board is acting as a bus master then it would request bus
access by asserting its priority on the four TMA pins.  If the TMA
arbitration granted it access then it would perform a DMA operation (pHOLD,
pHLDA), disable the master processor's address, status and control lines,
assert its own bus signals, perform the DMA cycle (8 or 16 bit), and then
release the bus.  If necessary completion interrupt is sent to one of the VI
pins.  No different than a disk controller.

It was a little more complicated than the XT/AT bus in that there were 16
priority levels encoded in four open collector pins.  The XT/AT just put the
individual DMA request lines from the 8237 on the bus and handled
arbitration on chip.

DMA is arbitrated on either bus in hardware, so there are no conflicts
unless the cards are misconfigured to use the same DMA level.  These days
it's handled in the chipset but the basics are the same.


0
peacock (183)
11/11/2003 11:21:59 PM
On Mon, 10 Nov 2003 19:43:57 -0600, "Randy McLaughlin"
<randy482@nospam.com> wrote:

>> 1)Device abstraction- to get the programmer away from the
>> I/O iron.
>> 2)File system to manage whatever mass storage there may be.
>> 3)A defined set of system services that are callable in a
>>     standardized way.
>> 4)User interface to allow managing files , starting jobs ,
>>   stopping jobs plus any other housekeeping.

>You missed the point.  I made a new topic to show an idiot as an idiot.

;) the point was fragged over three different threads, easy to lose.

>CP/M is a good OS.  It was not intended to browse the internet.  It was an

If you looking for an arguement I have enough postings on the net for
the last 10+ years that says you are not getting a big arguement with
me around CP/M.  ;)

However CP/m is not a limiter to browsing the internet, connectivity
may be.

>8K OS that allowed people with at least 24K of ram to run standardized
>software.

Actually it grew some over time, it was 20k for CP/M 1.4 and 16k for
1.3... I was there.  For V2.2 the standard build was 24k but smaller
was easily do able though possibly pointless.

>Many programmers did many things with it.  It was even just used as a loader
>for other OS's.

I was one that did a lot of those including loading a version of of
the pascal Psystem from CP/M. Talk about an environment switch.
Made a good embedded file system too.  Took me a while to figure out
how to get a heirarchal file system going but the basic CP/M flat
filesystem was still the engine to mechanize it. 

>I agree with only two of the four functions you mention:  It should do items
>2 & 4.

What it needs to do and what makes for a refined environment may be
subtle.  By providing device abstraction via BIOS meant the programmer
for a cpm system had standard calls that worked in a predicitable way
despite what the hardware had to do.  Item three is a formalized
statement of what 1 and 2 do plus things like printing a string or
allocating a file are there too.

>An OS needs to do no more than select another program to run.  It does not
>even require a keyboard or mouse.  When I switched from mainframes to
>micro's my first 8080 OS was Cutter.  I had a CUTS board with both Cutter &
>ALS8.  Cutter was a cassette OS.  It was a full OS that could do a directory
>of its media (list the files on tape), load a file into RAM, or load &
>execute programs.  It was a great 2K OS.

I'd argue that CUTS/Cutter (ran that too) were system monitors and
fell short on the OS scale.   Not that they werent good but,
unsophisticated. Keyboard or mouse are simply IO and if there is
interaction the device is incidental.  What seperates CP/M as a
landmark from many of the "monitors" was the configureability for 
a range of hardware.  The only OS that made that task relatively easy
was OS/8 (PDP-8) as the device drivers had a structure that was easily
created and installed.

One thing I feel is missing from CP/M and is easily added is process
scheduling.


Allison


0
nospam74 (614)
11/12/2003 12:55:03 AM
CBFalconer <cbfalconer@yahoo.com> wrote

> > In fact all that can be done with cassetes is
> > start/stop/read/write. This does not count as 'files'.
> 
> And all that can be done with hard disks (or floppies) is to
> read/write/seek.  Both can be used as the basis for a file
> system.  

Quite right, and this is done with an operating system such as PC-DOS,
or Unix or many others.  Some systems can write file systems onto
tapes, too.  eg CP/M on Epson PX-80.

ROM BASIC does not create a 'file system' on the cassette tape.  It
would be possible to write a BASIC program to simulate this in some
ways, but BASIC does no more than hand off cassette tape requests to
the BIOS INT 15h.

> Tapes and cassettes do not have a random access
> attribute, and algorithms need to be designed accordingly.  

Well exactly.  And ROM BASIC has none of them, while CP/M for the
Epson PX-80 does.  It can take a directory listing, delete a file, add
a file, and programs can open individual files and read them, or write
new files. _That_ is a file system.

What can ROM BASIC do ?  It allows a program to display a message
telling the user to rewind the tape.  The _program_ can then read or
write data blocks.  That is no more a 'file system' than a printer
has.

If several different sets of data are required to be on a tape the
_user_ has to wind the tape to a particular counter position before
starting the program and manually keep records of what data is at
which counter positions on which tapes.  The _operator_ provides the
'file system' not any claimed 'OS'.

> For an outstanding example look up polyphase mergesort some time.

Actually I did study the methods used by those while running them back
in the 60s.  On the machines we used then there was plenty of time for
reading.
0
riplin (4127)
11/12/2003 1:33:15 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> Ask anyone that ran Turbo-Dos on their Televideo TS800 or TS1600 series
> systems as well as any using Arcnet and you will find that you know very
> little about Turbo-Dos.

I have a 1984 ad here for a TS804: """it's a multi-user micro in one
single desktop unit ... it's standard MP/M II operating system ..."""

""" ... up to four users via any ASCII terminal."""

Just 2 pages away is an ad for a S100 'SBC II Two user slave board'.

"""Any combination of SBC Is and SBC IIs can be supported by TurboDOS
within a single multi-user system."""


Televideo did have a specific derivitive system of TurboDOS that
merged the MMMost networking with the TurboDOS core system.  This was
not a standard TurboDOS which was based on a master plus slave
processor boards in one computer, eg an S100 box.

I will accept that you were unaware that TeleVideo's system was quite
non-standard, or how standard TurboDOS worked.
0
riplin (4127)
11/12/2003 6:12:42 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> > Cassettes have no similarity at all to Tape file on real computers.
> > You appear to think that because they are both magnetic tapes that
> > therefore the ROM BASIC is like IBM's TOS.
> 
> Please continue to show your ignorance and explain which of the tape formats
> are real and which are not. 

Please continue to show your inability to read correctly.  It was
'real computers' not 'real tape formats'.

But tapes on mainframes do actually have formats and framing data that
make them a 'file system' while cassette tapes on IBMs are just
bunches of beeps.

> Is it what color plastic the case is made of by any chance?

That is the sort of superficiality that I would expect from you.

> Actually it handles files as files. 

No. ROM BASIC had no concept of 'files' on cassette tapes.

> Actually like most trives used today the PC uses a stream of bits not bytes.  

No. Wrong.  Bytes are the unit of transfer and bytes are checked by
additional parity bits.  Bytes are indivisble.  On Drives you cannot
have a 'stream of bits' that is not an integral number of bytes.
0
riplin (4127)
11/12/2003 7:43:49 AM
Richard wrote:
> "Randy McLaughlin" <randy482@nospam.com> wrote
> 
.... snip ...
> 
> No. ROM BASIC had no concept of 'files' on cassette tapes.
> 
> > Actually like most trives used today the PC uses a stream of
> > bits not bytes.
> 
> No. Wrong.  Bytes are the unit of transfer and bytes are checked by
> additional parity bits.  Bytes are indivisble.  On Drives you cannot
> have a 'stream of bits' that is not an integral number of bytes.

Funny thing.  Both tape drives and disk drives depend on heads,
which have the amazing habit of reading (and writing) one bit at a
time to or from some form of magnetic media.  Everything after
that is governed by some form of protocol, including parity bits,
crc checks, error correction, gaps, whatever.  The primary
difference between the media is the speed involved in seeking a
particular spot to read or write.

You can build a filing system out of almost anything, including
scraps of toilet paper and baked clay tablets

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

0
cbfalconer (19194)
11/12/2003 7:04:16 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311112343.7ca8523e@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > > Cassettes have no similarity at all to Tape file on real computers.
> > > You appear to think that because they are both magnetic tapes that
> > > therefore the ROM BASIC is like IBM's TOS.
> >
> > Please continue to show your ignorance and explain which of the tape
formats
> > are real and which are not.
>
> Please continue to show your inability to read correctly.  It was
> 'real computers' not 'real tape formats'.
>
> But tapes on mainframes do actually have formats and framing data that
> make them a 'file system' while cassette tapes on IBMs are just
> bunches of beeps.

Actually mainframes also have used audio cassettes.  The beeps heard on
audio cassette recordings is a function of the fact that the recorders are
designed to record and playback sound in the human hearing range.  As such
audio tones are used to represent logical on and off just as digital
recorders use magnetic north and south.  Notice I used the terms on and off
not 0's and 1's, that is because the encoding of 0's and 1's to on and off
was complicated by things like bit drift, saturation and a host other
technical problems.

>
> > Is it what color plastic the case is made of by any chance?
>
> That is the sort of superficiality that I would expect from you.
>
> > Actually it handles files as files.
>
> No. ROM BASIC had no concept of 'files' on cassette tapes.

ROM basic allows for multiple file types including machine language files
that had information about where in RAM it should load and what address to
execute after loading, basic programs, data files.  The IBM PC limited the
data files to being sequential (hardware limitation).

>
> > Actually like most drives used today the PC uses a stream of bits not
bytes.
>
> No. Wrong.  Bytes are the unit of transfer and bytes are checked by
> additional parity bits.  Bytes are indivisble.  On Drives you cannot
> have a 'stream of bits' that is not an integral number of bytes.

You are absolutely wrong.  It is a stream of bits not bytes.  The stream has
a much more complicated format than simply taking a byte and serially
sending it to tape.  Anyone trying to read a tape recorded like that would
have to start the tape on the exact starting bit and run the tape at the
exact speed read as recorded.  In fact just like tapes written on Linux or
Windoze today and 9-track tapes of years past (and even a few today) it
starts with a stream of zeros to allow the controller (either a smart
controller or the CPU) to get in sync.  Next come bits (1 at a time for
single track drives like audio cassettes, 9 at a time for 9-track drives,
more or less for other drives) that tell the controller to start reading.
The following bits often can then be serialized into bytes.  These bytes are
usually not the data from the file, but more header information for the file
system.  This header information may contain encoding information, file
name, file type, file size, etc.  Only after all of that comes bits that
actually contain the file data (using a variety of encoding technologies).
Lastly usually comes a footer record that contains more checksums info
beyond any CRC info that may have been part of the data encoding.

It is not worthwhile to explain to someone such as you that has no more
understanding of hardware how all magnetic media data is formatted.  If
anyone who is smart enough is interested there are plenty of white papers
available on the net, anyone particularly interested in at least one audio
cassette format can check the Solos/Cutter source code on the SOL-20 home
page.


0
randy482 (428)
11/12/2003 7:13:27 PM
Hi!

> You may also want to note that there _isn't_ a comp.os.basic (of
> either meaning). Are we to conclude from this that therefore no one
> with two clues to rub together ever considered that BASIC was an OS ?

No, the fact is that BASIC as an OS (e.g. Rocky Mountain BASIC for the
HP 9000 series, for me an example of an highly sophisticated OS!) is
normally grouped with the appropiate hardware. The different BASIC
OS's (and their users) are too different to be put together in one
discussion group.

Bye, Gaby

-- 
Mrs. Gaby Chaudry
http://www.gaby.de
mailto:gaby@gaby.de
0
chaudry (58)
11/12/2003 7:42:23 PM
Louis-Luc,

> However, I'm not so sure Windows 95/98/ME is a true OS 

It's not. Though Microsoft even talks about "The Windows 3.11
Operating System", all these DOS-based Windows are just GUIs with some
extra features.

> Newer WIndows might be true OS, if they base on NT, but I can't say for sure.

Like you said. NT is an OS and so are 2K and XP. No DOS mode to return
to when you're lost... DOS is only emulated on these systems, but it
doesn't rule the machine.

Bye, Gaby

-- 
Mrs. Gaby Chaudry
http://www.gaby.de http://www.win31.de
mailto:gaby@gaby.de
0
chaudry (58)
11/12/2003 7:48:48 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311112212.448e9044@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > Ask anyone that ran Turbo-Dos on their Televideo TS800 or TS1600 series
> > systems as well as any using Arcnet and you will find that you know very
> > little about Turbo-Dos.
>
> I have a 1984 ad here for a TS804: """it's a multi-user micro in one
> single desktop unit ... it's standard MP/M II operating system ..."""

Here you finally said something true, the TS804 could be used as a standard
MP/M system.  The ad you are reading is probably from when Televideo dropped
the line and dumped their systems.  Many people picked them up and loaded
MP/M making really cheap multi-user systems.

>
> """ ... up to four users via any ASCII terminal."""
>
> Just 2 pages away is an ad for a S100 'SBC II Two user slave board'.
>
> """Any combination of SBC Is and SBC IIs can be supported by TurboDOS
> within a single multi-user system."""
>
>
> Televideo did have a specific derivitive system of TurboDOS that
> merged the MMMost networking with the TurboDOS core system.  This was
> not a standard TurboDOS which was based on a master plus slave
> processor boards in one computer, eg an S100 box.
>
> I will accept that you were unaware that TeleVideo's system was quite
> non-standard, or how standard TurboDOS worked.

I currently own a Turbo-Dos system and have set up numerous ones.

You spend too much time reading ads.  Televideo had a whole series of TS800
& TS1600 computers.  The TS800 was available in two basic versions: with
built in terminal and without.  The TS804 was the smallest without a
terminal (4 serial ports, TS806 had 6, etc.)  It could run a variety of
software including CP/M, CP/M plus, MP/M, MMMOST, Turbo-Dos, etc.  It was
usually refered to as a master computer.

The TS802 was a dual floppy based computer with a builtin terminal and a
"high" speed networking port.  Televideo sold bundled packages where a
master computer running MMMost would network to the slave compters
(diskless, dual floppy, or harddrive based).  Smarter people installed
Turbo-Dos and had a reliable networking system.  It was a star based network
(running on a RS-422 backbone).

It was a structure that was extremely standard for Turbo-Dos.

Turbo-Dos's only standard is the software.  Most Turbo-Dos systems were S100
based with S100 slave computers plugged into the same box.  When the slave
was an S100 card the master processor had to constantly poll each slave
board to see if one needed to transfer a packet.  On other systems this
could be done via interrupts, all were "standard".  I several S100 slave
processors from a variety of manufacturers, all are communicated with via
polling; none use bus-arbitration.

Turbo-Dos is as much as a multi-user system as Novell.  It is multi-user in
the fact that multiple-people can use their own individual computer to share
data over a intranet (mini-internet for the troll "Richard").

Below is a slave gen file from Turbo-Dos, you may notice the 1st line it
declares the slave to be a networked slave.  You may or may not be aware
that every terminal attached had to have a separate computer to plug in (one
could be attached to the master, but usually not).  In the above SBC-II two
separate computers are put on one S100 card (I have three dual processor
slaves).

STDSLAVE ;STANDARD NETWORKING SLAVE
CPMSUP  ;CP/M FUNCTION SUPPORT MODULE
HDWINIT  ;HARDWARE INITIALIZATION
SSMPINIT ;SUPER SLAVE MEMORY PARITY INITIALIZATION
SSINT  ;SUPER SLAVE INTERRUPT CONTROLLER
SQCON  ;SUPER QUAD & SUPER SLAVE CONSOLE DRIVER
;LSTCTS  ;PRINTER DRIVER FOR 9600 BAUD, CTS HANDSHAKING
;LSTPAR  ;PARALLEL PRINTER DRIVER
;LSTETX  ;PRINTER DRIVER FOR ETX/ACK HANDSHAKE
;LSTXON  ;PRINTER DRIVER FOR XON/XOF HANDSHAKE
SQSERIAL ;STANDARD SERIAL MULTIPLEX DRIVER
SSSIO  ;SUPER SLAVE SERIAL I/O DRIVERS
;SSPIO  ;SUPER SLAVE PARALLEL I/O DRIVER
SSCKTDR  ;SUPER SLAVE CIRCUIT DRIVER
SSRESET  ;SUPER SLAVE RESET DETECTION
SSRTC  ;SUPER SLAVE REAL TIME CLOCK
SSSOM  ;SUPER SLAVE SIGN ON MESSAGE
;
; THE FOLLOWING FILES ARE USED FOR A LOCAL PRINTER
; THAT IS SPOOLED AND ACCESSABLE THRU THE NETWORK
;
;NETSVC  ;NETWORK REQUEST SERVICE PROCESS
;DSPOOL  ;DESPOOLER


0
randy482 (428)
11/12/2003 8:35:13 PM
CBFalconer <cbfalconer@yahoo.com> wrote 

> Funny thing.  Both tape drives and disk drives depend on heads,
> which have the amazing habit of reading (and writing) one bit at a
> time to or from some form of magnetic media.  

Actually with 9 track tapes the heads write one byte at a time.  While
single head drives do need to serialise the bits, they still write the
data in bytes of (usually) 8bits plus parity.

> Everything after
> that is governed by some form of protocol, including parity bits,
> crc checks, error correction, gaps, whatever.  

Certainly it all needs to fit into some framework, but this is not
seen on the computer side of the interface, which only sees a stream
of bytes.
 
> You can build a filing system out of almost anything, including
> scraps of toilet paper and baked clay tablets

And that is exactly how ROM BASIC does it   ;-)
0
riplin (4127)
11/12/2003 11:09:52 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311110929.424b59fa@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > I'm tired of such a stupid troll, so here is the final post on this
subject.
>
> ROFL.
>
> > CCP/M changed direction by adding virtual termainals.
> > The big change was in changing the emphasis from multiuser to
multitasking.
>
> > to show that DR followed logical paths from product to product.
>
> I agree that DRI followed logical paths for its products.  I see a
> logical path through from MP/M to DR-MDOS.
>
> There is just no 'changed direction'.
>
> Your 'change' appeared to be based on changing to single-user
> multi-tasking, which never happened. In fact you probably never knew
> that VCs could be done on serial terminals, and that was where
> CCP/M-86 had its market.
>
> > Remember that DR dropped products when they came out with newer versions
of
> > the same software. DR continued to sell CP/M-86 & MP/M-86 even after
coming
> > out with CCP/M-86,
>
> Actually they didn't.  _Compupro_ continued to sell MP/M-816 products
> after DRI released CCP/M-86, but that is because the only significant
> change in the product could not be implemented until serial terminals
> with appropriate features could be incorporated.

CCP/M did not need any special functions for its terminals.  If you really
want to know more about MP/M or CCP/M check out Gaby's site where many of
the sources are available.

MP/M-86 source is still lost, but the 8 bit sources are there as well as a
CCP/M v2 & CCP/M v3.1 (which I donated).

MP/M faded simply because CCP/M did what most of us wanted and there was no
need to sell down to MP/M. Everyone knew that MP/M development was over and
DR was shaping the software to match the future.  The future was the PC and
most of us knew it, CCP/M was much better suited to the PC environment than
MP/M.  Many of us also knew that the PC implementation had many limitation
built in but you can not hold back the ocean.


0
randy482 (428)
11/12/2003 11:16:59 PM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> Actually mainframes also have used audio cassettes.

Which _mainframes_ have used _audio_ cassettes ? and what for exactly.

Certainly they used digital cassettes frequently.  Some may even look
similar to a typical audio cassette, but aren't.

> As such
> audio tones are used to represent logical on and off just as digital
> recorders use magnetic north and south.

In what way do audio magnetic tapes _not_ use 'magnetic north and
south' ?

Audio tapes are not recounding 'sound', they are recording magnetic
changes used to _represent_ sound.

> Notice I used the terms on and off
> not 0's and 1's, that is because the encoding of 0's and 1's to on and off
> was complicated by things like bit drift, saturation and a host other
> technical problems.

In what way is the 'on/off' analogy different from a '1/0' analogy ?

I do understand how digital recording is done on tapes, there is no
need for you to try to seem technically savvy.
 
> > No. ROM BASIC had no concept of 'files' on cassette tapes.
> 
> ROM basic allows for multiple file types including machine language files

ROM BASIC _allows_ for any program to write whatever it likes, and to
read it back as whatever it wishes.  It does not _do_ anything to
assist or prevent anything being done by the user or his program. 
That is why it is _not_ an OS.

> that had information about where in RAM it should load and what address to
> execute after loading, basic programs, data files.  The IBM PC limited the
> data files to being sequential (hardware limitation).

The only thing that the _BIOS_ (not ROM BASIC) could do at its INT 15h
entry was 'start motor' 'stop motor' 'read' 'write'.  It entirely up
to the _user_ to set the tape to the correct position and to write
bits of paper about what is where on which tapes.  No 'OS'
functionality there.

There was nothing in the system anywhere to distinguish between
different blocks of data on the tapes.  If you wrote a program to
output a bunch of data to tape and then told BASIC to read it back as
a program it didn't care, it just did that.  No 'OS' functionality
there.

> > No. Wrong.  Bytes are the unit of transfer and bytes are checked by
> > additional parity bits.  Bytes are indivisble.  On Drives you cannot
> > have a 'stream of bits' that is not an integral number of bytes.
> 
> You are absolutely wrong.  It is a stream of bits not bytes.  The stream has
> a much more complicated format than simply taking a byte and serially
> sending it to tape.  

It is a stream of indivisable bytes being written to the drive
interface.  On the tape they are not a series of 'bits', they are a
series of magnetic reversals.

> Anyone trying to read a tape recorded like that would
> have to start the tape on the exact starting bit and run the tape at the
> exact speed read as recorded.  

> In fact just like tapes written on Linux or
> Windoze today and 9-track tapes of years past (and even a few today) it
> starts with a stream of zeros to allow the controller (either a smart
> controller or the CPU) to get in sync.  Next come bits (1 at a time for
> single track drives like audio cassettes, 9 at a time for 9-track drives,
> more or less for other drives) that tell the controller to start reading.

I do like the way that you argue '9 at a time' is not 'bytes' when of
course it is 8 data bits plus a parity.  If anything is _exactly_ a
'stream of bytes' it is a 9 track tape.

Of course there are synchonising bytes in the block frame.  You seem
to be ranting for rant's sake.  Just another of your trolls ?

> It is not worthwhile to explain to someone such as you that has no more
> understanding of hardware how all magnetic media data is formatted.  

You are a real joke.  I was doing all this in the 60s.

> If
> anyone who is smart enough is interested there are plenty of white papers
> available on the net, 

You've obviously been trying to research all this furiously over the
last day or two.  How much of your message is just cut'n'paste ?

> anyone particularly interested in at least one audio
> cassette format can check the Solos/Cutter source code on the SOL-20 home
> page.

Is the SOL-20 an IBM-PC ?  Is SOL-20 BASIC the same as IBM PC ROM
BASIC ?

While it is perfectly true that a file system _can_ be on an audio
tape (eg PX-80 tape drive) that is completely irrelevant because IBM
ROM BASIC _does_not_do_that_.
0
riplin (4127)
11/12/2003 11:17:57 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311121517.39f365e1@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > Actually mainframes also have used audio cassettes.
>
> Which _mainframes_ have used _audio_ cassettes ? and what for exactly.
>
> Certainly they used digital cassettes frequently.  Some may even look
> similar to a typical audio cassette, but aren't.
>
> > As such
> > audio tones are used to represent logical on and off just as digital
> > recorders use magnetic north and south.
>
> In what way do audio magnetic tapes _not_ use 'magnetic north and
> south' ?

Actually if you had any knowledge of recorders you would know that "digital"
recording uses non-return-to-zero, where the tape is saturated either north
or south (all recording is a curve, but digital recording has a very steep
curve between north and south pulses).  Audio recordings used for data
storage do not use saturation (it is aimed for mid saturation/volume)
instead it uses a shift of sinusoidal frequency to mark a change from on to
off.

>
> Audio tapes are not recounding 'sound', they are recording magnetic
> changes used to _represent_ sound.
>
> > Notice I used the terms on and off
> > not 0's and 1's, that is because the encoding of 0's and 1's to on and
off
> > was complicated by things like bit drift, saturation and a host other
> > technical problems.
>
> In what way is the 'on/off' analogy different from a '1/0' analogy ?

To understand you would need to know more about computers than you obviously
do.  The on/off flux to 0/1 data for dummies answer is that in "digital"
recording the mag substrate (tape in this case) is saturated either north or
south to make magnetic "bubbles".  These "bubbles" follow the same rules of
magnetism everyone learned in school, like charges repel, unlike charges are
attracted.  To increase bit density without bit drift a map of what sequence
of polar charges (what I described as on/off vs frequency shift in analog
mode) is mapped to 0's and 1's.  There are several maps available from least
efficient to most efficient: FM, MFM, & RLL.  Look them up.

>
> I do understand how digital recording is done on tapes, there is no
> need for you to try to seem technically savvy.

If you understood how digital recordings is done on tapes you would not have
had to ask the previous question.

>
> > > No. ROM BASIC had no concept of 'files' on cassette tapes.
> >
> > ROM basic allows for multiple file types including machine language
files
>
> ROM BASIC _allows_ for any program to write whatever it likes, and to
> read it back as whatever it wishes.  It does not _do_ anything to
> assist or prevent anything being done by the user or his program.
> That is why it is _not_ an OS.

Actually most OS's allow programs to modify anything they want (given proper
privileges).  That is how computer worms were done back in the 60's and how
many computer virus's work today.

>
> > that had information about where in RAM it should load and what address
to
> > execute after loading, basic programs, data files.  The IBM PC limited
the
> > data files to being sequential (hardware limitation).
>
> The only thing that the _BIOS_ (not ROM BASIC) could do at its INT 15h
> entry was 'start motor' 'stop motor' 'read' 'write'.  It entirely up
> to the _user_ to set the tape to the correct position and to write
> bits of paper about what is where on which tapes.  No 'OS'
> functionality there.
>
> There was nothing in the system anywhere to distinguish between
> different blocks of data on the tapes.  If you wrote a program to
> output a bunch of data to tape and then told BASIC to read it back as
> a program it didn't care, it just did that.  No 'OS' functionality
> there.
>
> > > No. Wrong.  Bytes are the unit of transfer and bytes are checked by
> > > additional parity bits.  Bytes are indivisble.  On Drives you cannot
> > > have a 'stream of bits' that is not an integral number of bytes.
> >
> > You are absolutely wrong.  It is a stream of bits not bytes.  The stream
has
> > a much more complicated format than simply taking a byte and serially
> > sending it to tape.
>
> It is a stream of indivisable bytes being written to the drive
> interface.  On the tape they are not a series of 'bits', they are a
> series of magnetic reversals.

Neither audio nor most digital tapes have a direct map between magnetic
reversals and bits (only digital FM recordings from decades ago had a one to
one map).

>
> > Anyone trying to read a tape recorded like that would
> > have to start the tape on the exact starting bit and run the tape at the
> > exact speed read as recorded.
>
> > In fact just like tapes written on Linux or
> > Windoze today and 9-track tapes of years past (and even a few today) it
> > starts with a stream of zeros to allow the controller (either a smart
> > controller or the CPU) to get in sync.  Next come bits (1 at a time for
> > single track drives like audio cassettes, 9 at a time for 9-track
drives,
> > more or less for other drives) that tell the controller to start
reading.
>
> I do like the way that you argue '9 at a time' is not 'bytes' when of
> course it is 8 data bits plus a parity.  If anything is _exactly_ a
> 'stream of bytes' it is a 9 track tape.

If you knew anything of mainframe mage tapes you would know that there were
many formats (I have used up to 21 track digital drive, yes the same basic
truck used in the audio world for years) .  The 9th bit on mainframes was
originally used as an FM clock, later it was used as a parity bit.

>
> Of course there are synchonising bytes in the block frame.  You seem
> to be ranting for rant's sake.  Just another of your trolls ?
>
> > It is not worthwhile to explain to someone such as you that has no more
> > understanding of hardware how all magnetic media data is formatted.
>
> You are a real joke.  I was doing all this in the 60s.
>
> > If
> > anyone who is smart enough is interested there are plenty of white
papers
> > available on the net,
>
> You've obviously been trying to research all this furiously over the
> last day or two.  How much of your message is just cut'n'paste ?
>
> > anyone particularly interested in at least one audio
> > cassette format can check the Solos/Cutter source code on the SOL-20
home
> > page.
>
> Is the SOL-20 an IBM-PC ?  Is SOL-20 BASIC the same as IBM PC ROM
> BASIC ?
>
> While it is perfectly true that a file system _can_ be on an audio
> tape (eg PX-80 tape drive) that is completely irrelevant because IBM
> ROM BASIC _does_not_do_that_.

The SOL-20's Solos was mentioned because the format is similar (in basic
terms) to the IBM PC and the source is available and easily read and
understood.

While I am getting older and the years between when I used this knowledge
and today is long I wrote from memory.  Going from memory I am sure there
are some technical mistakes, luckily I am sure you don't have enough
personal knowledge in the field to find them.


0
randy482 (428)
11/13/2003 12:12:05 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> Most Turbo-Dos systems were S100
> based with S100 slave computers plugged into the same box.

Thank you for finally agreeing with me on this.

> Turbo-Dos is as much as a multi-user system as Novell.  It is multi-user in
> the fact that multiple-people can use their own individual computer to share
> data over a intranet (mini-internet for the troll "Richard").

No. That is not true.  With Novell the Netware system is only the
server, The clients run system software that is not entirely supplied
by the Novell Netware.

With a TurbosDOS system using S100 master and slaves the whole OS is
TurboDOS both on the master and the slave making it one box that is a
multiuser system.

The fact that each user has its own microprocessor within the one box
is irrelevant to it being multi-user and relevant to it being
multi-processing.  Many systems have multiple processors,
 
Now if it is in several boxes then it is a distributed
multi-processing system.
0
riplin (4127)
11/13/2003 5:00:36 AM

Randy McLaughlin wrote:
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:217e491a.0311121517.39f365e1@posting.google.com...
> 
>>"Randy McLaughlin" <randy482@nospam.com> wrote
>>
>>
>>>Actually mainframes also have used audio cassettes.
>>
>>Which _mainframes_ have used _audio_ cassettes ? and what for exactly.
>>
>>Certainly they used digital cassettes frequently.  Some may even look
>>similar to a typical audio cassette, but aren't.
>>
>>
>>>As such
>>>audio tones are used to represent logical on and off just as digital
>>>recorders use magnetic north and south.
>>
>>In what way do audio magnetic tapes _not_ use 'magnetic north and
>>south' ?
> 
> 
> Actually if you had any knowledge of recorders you would know that "digital"
> recording uses non-return-to-zero, where the tape is saturated either north
> or south (all recording is a curve, but digital recording has a very steep
> curve between north and south pulses).  Audio recordings used for data
> storage do not use saturation (it is aimed for mid saturation/volume)
> instead it uses a shift of sinusoidal frequency to mark a change from on to
> off.
> 
> 
>>Audio tapes are not recounding 'sound', they are recording magnetic
>>changes used to _represent_ sound.
>>
>>
>>>Notice I used the terms on and off
>>>not 0's and 1's, that is because the encoding of 0's and 1's to on and
> 
> off
> 
>>>was complicated by things like bit drift, saturation and a host other
>>>technical problems.
>>
>>In what way is the 'on/off' analogy different from a '1/0' analogy ?
> 
> 
> To understand you would need to know more about computers than you obviously
> do.  The on/off flux to 0/1 data for dummies answer is that in "digital"
> recording the mag substrate (tape in this case) is saturated either north or
> south to make magnetic "bubbles".  These "bubbles" follow the same rules of
> magnetism everyone learned in school, like charges repel, unlike charges are
> attracted.  To increase bit density without bit drift a map of what sequence
> of polar charges (what I described as on/off vs frequency shift in analog
> mode) is mapped to 0's and 1's.  There are several maps available from least
> efficient to most efficient: FM, MFM, & RLL.  Look them up.
> 
> 
>>I do understand how digital recording is done on tapes, there is no
>>need for you to try to seem technically savvy.
> 
> 
> If you understood how digital recordings is done on tapes you would not have
> had to ask the previous question.
> 
> 
>>>>No. ROM BASIC had no concept of 'files' on cassette tapes.
>>>
>>>ROM basic allows for multiple file types including machine language
> 
> files
> 
>>ROM BASIC _allows_ for any program to write whatever it likes, and to
>>read it back as whatever it wishes.  It does not _do_ anything to
>>assist or prevent anything being done by the user or his program.
>>That is why it is _not_ an OS.
> 
> 
> Actually most OS's allow programs to modify anything they want (given proper
> privileges).  That is how computer worms were done back in the 60's and how
> many computer virus's work today.
> 
> 
>>>that had information about where in RAM it should load and what address
> 
> to
> 
>>>execute after loading, basic programs, data files.  The IBM PC limited
> 
> the
> 
>>>data files to being sequential (hardware limitation).
>>
>>The only thing that the _BIOS_ (not ROM BASIC) could do at its INT 15h
>>entry was 'start motor' 'stop motor' 'read' 'write'.  It entirely up
>>to the _user_ to set the tape to the correct position and to write
>>bits of paper about what is where on which tapes.  No 'OS'
>>functionality there.
>>
>>There was nothing in the system anywhere to distinguish between
>>different blocks of data on the tapes.  If you wrote a program to
>>output a bunch of data to tape and then told BASIC to read it back as
>>a program it didn't care, it just did that.  No 'OS' functionality
>>there.
>>
>>
>>>>No. Wrong.  Bytes are the unit of transfer and bytes are checked by
>>>>additional parity bits.  Bytes are indivisble.  On Drives you cannot
>>>>have a 'stream of bits' that is not an integral number of bytes.
>>>
>>>You are absolutely wrong.  It is a stream of bits not bytes.  The stream
> 
> has
> 
>>>a much more complicated format than simply taking a byte and serially
>>>sending it to tape.
>>
>>It is a stream of indivisable bytes being written to the drive
>>interface.  On the tape they are not a series of 'bits', they are a
>>series of magnetic reversals.
> 
> 
> Neither audio nor most digital tapes have a direct map between magnetic
> reversals and bits (only digital FM recordings from decades ago had a one to
> one map).
> 
> 
>>>Anyone trying to read a tape recorded like that would
>>>have to start the tape on the exact starting bit and run the tape at the
>>>exact speed read as recorded.
>>
>>>In fact just like tapes written on Linux or
>>>Windoze today and 9-track tapes of years past (and even a few today) it
>>>starts with a stream of zeros to allow the controller (either a smart
>>>controller or the CPU) to get in sync.  Next come bits (1 at a time for
>>>single track drives like audio cassettes, 9 at a time for 9-track
> 
> drives,
> 
>>>more or less for other drives) that tell the controller to start
> 
> reading.
> 
>>I do like the way that you argue '9 at a time' is not 'bytes' when of
>>course it is 8 data bits plus a parity.  If anything is _exactly_ a
>>'stream of bytes' it is a 9 track tape.
> 
> 
> If you knew anything of mainframe mage tapes you would know that there were
> many formats (I have used up to 21 track digital drive, yes the same basic
> truck used in the audio world for years) .  The 9th bit on mainframes was
> originally used as an FM clock, later it was used as a parity bit.
> 
> 
>>Of course there are synchonising bytes in the block frame.  You seem
>>to be ranting for rant's sake.  Just another of your trolls ?
>>
>>
>>>It is not worthwhile to explain to someone such as you that has no more
>>>understanding of hardware how all magnetic media data is formatted.
>>
>>You are a real joke.  I was doing all this in the 60s.
>>
>>
>>>If
>>>anyone who is smart enough is interested there are plenty of white
> 
> papers
> 
>>>available on the net,
>>
>>You've obviously been trying to research all this furiously over the
>>last day or two.  How much of your message is just cut'n'paste ?
>>
>>
>>>anyone particularly interested in at least one audio
>>>cassette format can check the Solos/Cutter source code on the SOL-20
> 
> home
> 
>>>page.
>>
>>Is the SOL-20 an IBM-PC ?  Is SOL-20 BASIC the same as IBM PC ROM
>>BASIC ?
>>
>>While it is perfectly true that a file system _can_ be on an audio
>>tape (eg PX-80 tape drive) that is completely irrelevant because IBM
>>ROM BASIC _does_not_do_that_.
> 
> 
> The SOL-20's Solos was mentioned because the format is similar (in basic
> terms) to the IBM PC and the source is available and easily read and
> understood.
> 
> While I am getting older and the years between when I used this knowledge
> and today is long I wrote from memory.  Going from memory I am sure there
> are some technical mistakes, luckily I am sure you don't have enough
> personal knowledge in the field to find them.
> 
> 

<Yawn>
Yak, yak, yak.

Obviously some people have no lives.

People, give it a rest already!

Roy



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----
0
millers (188)
11/13/2003 5:21:08 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311122100.4efce86f@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote
>
> > Most Turbo-Dos systems were S100
> > based with S100 slave computers plugged into the same box.
>
> Thank you for finally agreeing with me on this.

You cut part of my post out without even ackoleging your editing.  You said:

"I will accept that you were unaware that TeleVideo's system was quite
non-standard, or how standard TurboDOS worked."

The important part of my post you edited out was:

"Turbo-Dos's only standard is the software.  Most Turbo-Dos systems were
S100 based with S100 slave computers plugged into the same box.  When the
slave was an S100 card the master processor had to constantly poll each
slave board to see if one needed to transfer a packet.  On other systems
this could be done via interrupts, all were "standard"."

>
> > Turbo-Dos is as much as a multi-user system as Novell.  It is multi-user
in
> > the fact that multiple-people can use their own individual computer to
share
> > data over a intranet (mini-internet for the troll "Richard").
>
> No. That is not true.  With Novell the Netware system is only the
> server, The clients run system software that is not entirely supplied
> by the Novell Netware.
>
> With a TurbosDOS system using S100 master and slaves the whole OS is
> TurboDOS both on the master and the slave making it one box that is a
> multiuser system.
>
> The fact that each user has its own microprocessor within the one box
> is irrelevant to it being multi-user and relevant to it being
> multi-processing.  Many systems have multiple processors,
>
> Now if it is in several boxes then it is a distributed
> multi-processing system.

Again you are completely wrong.

Turbo-Dos had four versions of their OS broken down into two different slave
OS's and two different master user OS's (8 bit master, 16 bit master, 8 bit
slave, 16 bit slave).  The master OS could run without the slave OS being
just a CP/M compatible OS, the slave OS required the master OS.  I am aware
of some shells that expanded the 16 bit shell to be DOS compatible.  There
was no great motivation to tie other OS's to the network for a couple of
good reasons:  The 8 bit slave OS was extremely efficient Z80 code that ran
faster and left a smaller foot-print than CP/M & CP/NET.  Secondly Novell
servers took over the 16 bit market.

You are wrong about Novell not having their own OS for the slaves, they did
(they bought DR and had DR-DOS).

You are wrong that Novell required separate boxes for the slaves, there were
quite a few manufacturers that made ISA cards that were slave computers.
Where it was common for Turbo-Dos to network in one box it was not required,
where it was common for Novell to network with separate computer boxes
networked by cable it was not required.

You keep referring to current multiprocessor systems (SMP) here the
processors are running one coherent system sharing resources directly
whereas OS's like Turbo-Dos & Novell have separate CPU & other system
resources for each individual user.

Stop editing out parts of my post that show how stupid you are without at
least using proper netiquette (since you may not know any better when you
cut text replace it with "<snip>").


0
randy482 (428)
11/13/2003 6:05:50 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

> (all recording is a curve, but digital recording has a very steep
> curve between north and south pulses).  

Exactly.  They both use 'North and South' (unlike your original).

> > > Notice I used the terms on and off
> > > not 0's and 1's, that is because the encoding of 0's and 1's to on and
>  off
> > > was complicated by things like bit drift, saturation and a host other
> > > technical problems.
> >
> > In what way is the 'on/off' analogy different from a '1/0' analogy ?
> 
> To understand you would need to know more about computers

Blah, blah, blah.  On/off is an analogy. 1/0 is an analogy.  Both are
analogies for the same thing in the same way.  1 == on, 0 == off. 
Neither represent what actually happens on tape.

> There are several maps available from least
> efficient to most efficient: FM, MFM, & RLL.  Look them up.

Been cut and pasting as you search the internet again is it ?

> > ROM BASIC _allows_ for any program to write whatever it likes, and to
> > read it back as whatever it wishes.  It does not _do_ anything to
> > assist or prevent anything being done by the user or his program.
> > That is why it is _not_ an OS.
> 
> Actually most OS's allow programs to modify anything they want (given proper
> privileges).  That is how computer worms were done back in the 60's and how
> many computer virus's work today.

You really are at a stretch on this.

What logic is it that has: "most OSes allow programs to bypass".  "IBM
ROM BASIC forces the program to bypass (because it has nothing to
offer)".  Therefore IBM ROM BASIC is the equal of 'most OSes' ?

> Neither audio nor most digital tapes have a direct map between magnetic
> reversals and bits (only digital FM recordings from decades ago had a one to
> one map).

So now you claim that you were _wrong_ when you said 'a stream of
bits'.

But can we get back.  How the heads change the magnetic domains is
exactly and completely _irrelevant_.  The mapping between data bytes
on the computer side of the interface and flux strength in iron oxide
has _never_ been a function of any operating system.

When the BIOS INT 15h is activated then what is written is a stream of
_bytes_, it doesn't matter if is done by pigeon pecking holes in bits
of paper, as long as when it is read back it once again becomes a
stream of _bytes_.

Wandering off into areas that I last cared about 30 years ago doesn't
earn you any brownie points.

> > I do like the way that you argue '9 at a time' is not 'bytes' when of
> > course it is 8 data bits plus a parity.  If anything is _exactly_ a
> > 'stream of bytes' it is a 9 track tape.

> The 9th bit on mainframes was
> originally used as an FM clock, later it was used as a parity bit.

But they were still _bytes_ right ?
 
> > Is the SOL-20 an IBM-PC ?  Is SOL-20 BASIC the same as IBM PC ROM
> > BASIC ?
> >
> > While it is perfectly true that a file system _can_ be on an audio
> > tape (eg PX-80 tape drive) that is completely irrelevant because IBM
> > ROM BASIC _does_not_do_that_.
> 
> The SOL-20's Solos was mentioned because the format is similar (in basic
> terms) to the IBM PC and the source is available and easily read and
> understood.

So, you are saying that a file system can be on a PC tape if the user
writes programs (or converts the Sol-20 ones) to do all this.  This
make ROM BASIC an 'OS' in what way ?

If you hadn't noticed it is usual for an OS to relieve the programmer
of having to do those 'operational' things, not the other way around.
 
> While I am getting older and the years between when I used this knowledge
> and today is long I wrote from memory.  Going from memory I am sure there
> are some technical mistakes, 

No shit ?

Well you certainly got some of the cut'n'paste done almost right.
0
riplin (4127)
11/13/2003 6:50:42 AM
"Randy McLaughlin" <randy482@nospam.com> wrote 

>>> I'm tired of such a stupid troll, 

I was glad that you finally admitted you were making a troll.

>>> so here is the final post on this subject.

I just knew it wouldn't be.

> CCP/M did not need any special functions for its terminals.  

The systems that I used had terminals that had paged mode so that the
switch was instant.  While a memory mapped display, such as an IBM PC
main screen, could be memory copied out and back to recreate the
original screen when switching, this was often not possible to do to
refresh serial terminals on VC change.  Mode changes may be, and
usually are, embedded in the serial data sent to the terminal.  This
is extremely difficult to keep track of when a screen needs to be
recreated.

With paged memory terminal, such as ICL 6402G and Wyse 60 in PCMODE,
the terminal saves its complete state when the CCP/M system sends the
VC switch command, and thus there is no problem at all in recreating
its state on reverting.

It is true that CCP/M did not _need_ any special function, but it did
need these if it was to implement virtual terminals effectively on the
serial terminals.

> If you really
> want to know more about MP/M or CCP/M check out Gaby's site where many of
> the sources are available.

I'm not sure that I have any need to know more, there isn't much more
for me to learn.

> MP/M faded simply because CCP/M did what most of us wanted and there was no
> need to sell down to MP/M. 

MP/M-86 didn't 'fade', it was developed into Concurrent-CP/M-86 3.x.

The only thing that faded was the non-standard 8/16 ability to run 8
bit programs.  These had become irrelevant.

> Everyone knew that MP/M development was over and
> DR was shaping the software to match the future.  

CCP/M _was_ MP/M development.

> The future was the PC and
> most of us knew it, CCP/M was much better suited to the PC environment than
> MP/M.  

CCP/M was a better MP/M.  PC or not is irrelevant.

In fact the IBM PC was an extremely poor environment for
Concurrent-CP/M-86 until the 386 made it usable around 10 years after
its first release.

Concurrent-CP/M-86 was first announced in March 1981, well before the
IBM PC and therefore not related to it.  CCP/M was developed from
MP/M-86 regardless of the IBM PC.

The PC did not have hard drives (except for aftermarket Xebec
controllers).

The 640Kb limit was very restrictive on memory when other 8086
machines could use a full megabyte.

While CDOS XM 5.x and above could use expanded memory using, say, an
AST RAMPage the 640Kb limit at the top of the addressability range and
the restriction of requiring backfill of at least 256Kb at the bottom
end left a maximum 'bank' size of 400Kb on XTs and ATs.  On other
machines the 'bank' size could be 750Kb with memory managedment on
8086 or 80286 machines.

It wasn't until the 386 machines with CDOS-386 that PCs became as good
as other machines being used for Concurrent.

Of course PC-DOS never helped either.  It was relatively easy to
enforce mechanisms in CCP/M-86 programs that could have meant that the
286 could have been used as intended as a protected mode system.  In
fact FlexOS-286 the other range of OSes from DRI did do this.  While
the programs were very like normal CCP.M-86 programs the system used
up to 16Mbyte directly in 286 mode.

By the time the 286 AT had arrived, however, the rot had set in in
PC-DOS programs and Concurrent-DOS was committed to running these. 
Poor PC-DOS facilities and slow DOS and BIOS screen displays made it
quite normal for PC-DOS programs to be written in ways that would
never work on 286 protected mode.

The 386 finally gave enough features to allow real mode and protected
mode to run together.

The poor PC-DOS programs also defeated MS's attempt at a 286 protected
mode MS-DOS which started, briefly as the real mode multi-tasking
MS-DOS 4.0 and 4.1 (not to be confused with the much later 4.01).

> Many of us also knew that the PC implementation had many limitation
> built in but you can not hold back the ocean.

It took 10 years for the PC to become the 'future' of Concurrent. 
Meanwhile we got on with better systems.
0
riplin (4127)
11/13/2003 6:52:06 AM
"Randy McLaughlin" <randy482@nospam.com> wrote

> Most Turbo-Dos systems were
> S100 based with S100 slave computers plugged into the same box.  

Thank you for finally agreeing with me.

> You are wrong about Novell not having their own OS for the slaves, they did
> (they bought DR and had DR-DOS).

Read more carefully, I used the trademark Netware, which was the name
of the server OS not just the name of the company.

DR-DOS is not Netware.  When one bought Netware one only got the
server OS.

> You are wrong that Novell required separate boxes for the slaves, there were
> quite a few manufacturers that made ISA cards that were slave computers.

The software components required by the slave computers were not by
Novell and were not part of Netware.

> You keep referring to current multiprocessor systems (SMP) here the
> processors are running one coherent system sharing resources 

No. I never referred to SMP at all anywhere, or even 'current'
multi-processor systems.

I did refer to computers having several processors.  These may be
video controllers or disk controllers or different types of processor
entirely.

> whereas OS's like Turbo-Dos & Novell have separate CPU & other system
> resources for each individual user.

And I have used systems from 20 years ago (and still have some here)
where each user had at least 3 8085 processors and could have several
more, some of different types such as 80188 or an AMD bit-slice.

> Stop editing out parts of my post that show how stupid I am without at
> least using proper netiquette (since I may not know any better when you
> cut text replace it with "<shit>").
0
riplin (4127)
11/13/2003 5:39:30 PM
"Randy McLaughlin" <randy482@nospam.com> wrote in message news:<kgZrb.56346$BX.13455@bignews5.bellsouth.net>...
> 
> CCP/M changed direction by adding virtual termainals.  Just as when MP/M
> added so much over CP/M the ability for average PC users to switch to a
> different tasks was close to a miracle at the time.  This allowed any office
> worker such as a secretary to have multiple programs running long before
> windows.  With MP/M the average user could not use multitasking.
> 
> The big change was in changing the emphasis from multiuser to multitasking.
> Of course it did not eliminate the ability to be a multiuser program.
>

This is from start.a86 in the Dri C package, FWIW.  It is Circa
iAPX-286, from other statements in the file for stack alignment.  On
Gaby's site is the code for building ccp/m, in it is an equ for
setting a mp/m build as well.  There are some differences in
file-operation code.  This code snippet claims: "CCP/M-86 lacks
multiuser of MP/M.", however I don't believe this is accurate because
elsewhere I've read that ccp/m _could_ be built as multiuser, like
you've said.

 
;
;ACF	end
;ACF	Name			'M.INIT.OS'
;ACF	Title			'M.INIT.OS'
;ACF	Pagesize 75
;
;	File name:		MINITOS.A86
;
;	Module name:		M.INIT.OS
;
;	Arguments:		None.
;
;	Return value:		_os_version	= 0 (unrecognized OS)
;						= 1 - 21h (non-CP/M OS's)
;						= 22h (CP/M-86 v. 2.2)
;						= 23h (MP/M-86 v. 3.0)
;						= 24h (CCP/M-86 v. 3.0)
;
;				_os_ability	= inclusive OR of:
;						8000h (multi-user)
;						4000h (multi-tasking)
;						2000h (multi-sect I/O)
;						1000h (date/time)
;						0800h (networking)
;						0400h (cmd name available)
;						0200h (8087 is present)
;
;	Entry Point		Arguments
;	-----------		---------
;	m.init.os		None
;
;	Function:		To determine the OS version and capabilities.
;
;	Algorithm:		Call the operating to obtain the OS
;				type/version and the date/time, if present.
;
;	Attributes:		OSIF (O/S interface routine)
;
	eject
;ACF	include	clear			; Get CLEAR definitions.
;
version		equ	12		; BDOS call to return version.
date.time	equ	105		; BDOS call to return date/time.
;
***[snip]***
;
m.init.os.notime:
;
;	Get the O/S version
;
	push	ax
	SYS	version			; Get the O/S version in BX
	pop	ax
	cmp	bx,22h			; Is the version less than 22h ?
	jb	m.init.os.found		; Yes.
;
;	Determine whether the operating system supports networking.
;
	test	bh,2			; Is networking available ?
	jz	m.init.os.nonet		; No.
	or	ax,networking		; Yes, set its capability bit.
	xor	bh,2			; Turn networking bit off.
;
m.init.os.nonet:
	mov	cx,0022h		; Start with CP/M-86 BDOS version 2.2
	or	ax,cmdname		; CP/M has cmdname capability
	test	bh,bh			; CP/M-86 ?
	jz	m.init.os.found		; Yes.
	xor	ax,cmdname		; But MP/M and CCP/M do not.
	inc	cl			; No, try for MP/M-86.
	or	ax,multiuser+multitasking+multisector	; Yes, set MP/M-86
capabilities.
	cmp	bh,1			; MP/M-86 ?
	je	m.init.os.found		; Yes.
	inc	cl			; Try for CCP/M-86 (CX = 24h).
	xor	ax,multiuser		; CCP/M-86 lacks multiuser of MP/M.
	cmp	bh,14h			; CCP/M-86 ?
	je	m.init.os.found		; Yes.
	sub	cx,cx			; Unrecognized operating system.
;	jmps	m.init.os.found		; Join common code.
;
m.init.os.found:
	mov	_os_version,cl		; Store O/S version byte.
	mov	_os_ability,ax		; Store O/S ability word.
	ret				; Return.
;
-----EOMyT-----
0
s_dubrovich (395)
11/16/2003 12:10:32 AM
"Steve Dubrovich" <s_dubrovich@yahoo.com> wrote in message
news:3fddc08d.0311151610.2bda9f74@posting.google.com...
> "Randy McLaughlin" <randy482@nospam.com> wrote in message
news:<kgZrb.56346$BX.13455@bignews5.bellsouth.net>...
> >
> > CCP/M changed direction by adding virtual termainals.  Just as when MP/M
> > added so much over CP/M the ability for average PC users to switch to a
> > different tasks was close to a miracle at the time.  This allowed any
office
> > worker such as a secretary to have multiple programs running long before
> > windows.  With MP/M the average user could not use multitasking.
> >
> > The big change was in changing the emphasis from multiuser to
multitasking.
> > Of course it did not eliminate the ability to be a multiuser program.
> >
>
> This is from start.a86 in the Dri C package, FWIW.  It is Circa
> iAPX-286, from other statements in the file for stack alignment.  On
> Gaby's site is the code for building ccp/m, in it is an equ for
> setting a mp/m build as well.  There are some differences in
> file-operation code.  This code snippet claims: "CCP/M-86 lacks
> multiuser of MP/M.", however I don't believe this is accurate because
> elsewhere I've read that ccp/m _could_ be built as multiuser, like
> you've said.
>
>
> ;
> ;ACF end
> ;ACF Name 'M.INIT.OS'
> ;ACF Title 'M.INIT.OS'
> ;ACF Pagesize 75
> ;
> ; File name: MINITOS.A86
> ;
> ; Module name: M.INIT.OS
> ;
> ; Arguments: None.
> ;
> ; Return value: _os_version = 0 (unrecognized OS)
> ; = 1 - 21h (non-CP/M OS's)
> ; = 22h (CP/M-86 v. 2.2)
> ; = 23h (MP/M-86 v. 3.0)
> ; = 24h (CCP/M-86 v. 3.0)
> ;
> ; _os_ability = inclusive OR of:
> ; 8000h (multi-user)
> ; 4000h (multi-tasking)
> ; 2000h (multi-sect I/O)
> ; 1000h (date/time)
> ; 0800h (networking)
> ; 0400h (cmd name available)
> ; 0200h (8087 is present)
> ;
> ; Entry Point Arguments
> ; ----------- ---------
> ; m.init.os None
> ;
> ; Function: To determine the OS version and capabilities.
> ;
> ; Algorithm: Call the operating to obtain the OS
> ; type/version and the date/time, if present.
> ;
> ; Attributes: OSIF (O/S interface routine)
> ;
> eject
> ;ACF include clear ; Get CLEAR definitions.
> ;
> version equ 12 ; BDOS call to return version.
> date.time equ 105 ; BDOS call to return date/time.
> ;
> ***[snip]***
> ;
> m.init.os.notime:
> ;
> ; Get the O/S version
> ;
> push ax
> SYS version ; Get the O/S version in BX
> pop ax
> cmp bx,22h ; Is the version less than 22h ?
> jb m.init.os.found ; Yes.
> ;
> ; Determine whether the operating system supports networking.
> ;
> test bh,2 ; Is networking available ?
> jz m.init.os.nonet ; No.
> or ax,networking ; Yes, set its capability bit.
> xor bh,2 ; Turn networking bit off.
> ;
> m.init.os.nonet:
> mov cx,0022h ; Start with CP/M-86 BDOS version 2.2
> or ax,cmdname ; CP/M has cmdname capability
> test bh,bh ; CP/M-86 ?
> jz m.init.os.found ; Yes.
> xor ax,cmdname ; But MP/M and CCP/M do not.
> inc cl ; No, try for MP/M-86.
> or ax,multiuser+multitasking+multisector ; Yes, set MP/M-86
> capabilities.
> cmp bh,1 ; MP/M-86 ?
> je m.init.os.found ; Yes.
> inc cl ; Try for CCP/M-86 (CX = 24h).
> xor ax,multiuser ; CCP/M-86 lacks multiuser of MP/M.
> cmp bh,14h ; CCP/M-86 ?
> je m.init.os.found ; Yes.
> sub cx,cx ; Unrecognized operating system.
> ; jmps m.init.os.found ; Join common code.
> ;
> m.init.os.found:
> mov _os_version,cl ; Store O/S version byte.
> mov _os_ability,ax ; Store O/S ability word.
> ret ; Return.
> ;
> -----EOMyT-----


Originally there could have been a marketing decision to sell CCP/M as
single user then later decided to just drop MP/M.


I am sure that if you check the source for MP/M (also available on Gaby's
site) you will probably find snippets of CP/M v1 (aka FDOS).

My biggest problem with CCP/M source is that it was built on what appears to
be an unavailable PL/M compiler for the VAX.  Has anyone been able to
compile CCP/M?  I have original DR source disks, but they are useless
without the right environment (yes I sent Gaby copies of the disks which she
has kindly posted).

Is there a public domain PL/M-86 compiler available?


0
randy482 (428)
11/16/2003 12:30:36 AM
s_dubrovich@yahoo.com (Steve Dubrovich) wrote 

> This code snippet claims: "CCP/M-86 lacks
> multiuser of MP/M.", however I don't believe this is accurate because
> elsewhere I've read that ccp/m _could_ be built as multiuser, like
> you've said.

> 	xor	ax,multiuser		; CCP/M-86 lacks multiuser of MP/M.

CCP/M-86 versions 1.0 for IBM PC and later for XT were not built with
multi-user.  This is because the support for virtual consoles was
built on an IBM-PC and swapped the video buffer in and out to change
VCs. The IBM PC 8250 serial ports were rather poor being unbuffered
and paged mode terminals were unavailable until some time later.

Until there were ISA multiport serial cards (Starlink, AST and Arnet)
and paged terminals it wasn't effective to build multiuser Concurrent
for the IBM PC, well it wouldn't be concurrent at all except on the
main screen.

The IBM PC also was limited to 544Kb which was rather restrictive for
multi-user compared to the 1 Mbyte on Compupros.

Versions 1.0 also didn't support DR/NET, so they weren't networking
clients either.

The next release for IBM PC was Jan 84, and was based on 3.1 and this
was multiuser.  The Generic release 3.1 was released in Feb 84
(according to Osborne). By that time OEMs were developing paged mode
terminals and upgrading their MP/M boxes to take 8086 or 8088 CPUs.
0
riplin (4127)
11/16/2003 8:07:50 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0311160007.6a4bc72e@posting.google.com...
> s_dubrovich@yahoo.com (Steve Dubrovich) wrote
>
> > This code snippet claims: "CCP/M-86 lacks
> > multiuser of MP/M.", however I don't believe this is accurate because
> > elsewhere I've read that ccp/m _could_ be built as multiuser, like
> > you've said.
>
> > xor ax,multiuser ; CCP/M-86 lacks multiuser of MP/M.
>
> CCP/M-86 versions 1.0 for IBM PC and later for XT were not built with
> multi-user.  This is because the support for virtual consoles was
> built on an IBM-PC and swapped the video buffer in and out to change
> VCs. The IBM PC 8250 serial ports were rather poor being unbuffered
> and paged mode terminals were unavailable until some time later.
>
> Until there were ISA multiport serial cards (Starlink, AST and Arnet)
> and paged terminals it wasn't effective to build multiuser Concurrent
> for the IBM PC, well it wouldn't be concurrent at all except on the
> main screen.
>
> The IBM PC also was limited to 544Kb which was rather restrictive for
> multi-user compared to the 1 Mbyte on Compupros.
>
> Versions 1.0 also didn't support DR/NET, so they weren't networking
> clients either.
>
> The next release for IBM PC was Jan 84, and was based on 3.1 and this
> was multiuser.  The Generic release 3.1 was released in Feb 84
> (according to Osborne). By that time OEMs were developing paged mode
> terminals and upgrading their MP/M boxes to take 8086 or 8088 CPUs.

Cheap paging terminals were available long before CCP/M was even a dream (I
used a Televideo 950), as I have stated before page mode terminals are not
required by DR products.  As far as having 16 byte FIFO's in serial ports it
really helps take the load off the CPU.  I wish CompuPro and others had them
it would have made their systems better in the multi-user world (even
without it they still ran).

As far as 544Kb was concerned CCP/M came out long after that barrier was
given up.  Bigger barriers included CPU speed, hard drive speed, and
available applications.

Using Novell (available at the same time) people were able to better use
their CPU's and run standard DOS apps.

I found that Concurrent PC-DOS really helped support existing CompuPro
customers keep their hardware and still run most DOS software.  Please note
most of the people I supported did not have page mode terminals, but CCDOS
ran just fine.


0
randy482 (428)
11/16/2003 6:26:43 PM
> Ok, is it possible to have the features of OS-9 Level 2 or NorthStar
> DOS(multiuser, multitasking) on a non-NorthStar Z80 computer that has
> a console instead of terminals?

Specificaly, multitasking, and, if available, multi-user, not that I
know anyone else who wants to use my laptop. I guess to me the
multiuser thing is mostly just a novelty. I don't need it, it's just
fun to play with.

The point is, if I'm going to have a computer with tons of ram, I want
to be able to use all that ram.

Can CP/M+ task switch? Can Z-System do real multitasking like OS-9?
0
puritan_2076 (115)
11/16/2003 11:15:03 PM
"Leon Howell" <puritan_2076@yahoo.com> wrote in message
news:ae64f04a.0311161515.72f69fe6@posting.google.com...
> > Ok, is it possible to have the features of OS-9 Level 2 or NorthStar
> > DOS(multiuser, multitasking) on a non-NorthStar Z80 computer that has
> > a console instead of terminals?
>
> Specificaly, multitasking, and, if available, multi-user, not that I
> know anyone else who wants to use my laptop. I guess to me the
> multiuser thing is mostly just a novelty. I don't need it, it's just
> fun to play with.
>
> The point is, if I'm going to have a computer with tons of ram, I want
> to be able to use all that ram.
>
> Can CP/M+ task switch? Can Z-System do real multitasking like OS-9?

In all of the cases mentioned the OS does not care if you are on a terminal
or not.  OS-9 Level 2 is based on a 6809/6309 CPU.  Please note that the
source is available, but translating to another CPU is not practical.

Try MP/M-II available for download from link provided below.

The problem is many people think of OS's like DOS that run on a standardized
environment, where MP/M is not a trivial task to get running from scratch.

This assumes you are referring to an 8080/8085/Z80 based laptop (I saw your
post on another group) and do have a mass storage device (ROM-disk,
diskette, HD, etc).

http://www.cpm.z80.de/


0
randy482 (428)
11/16/2003 11:56:01 PM
Why didn't I look this up earlier? There's a Z80 version of Unix
called "Uzi". Tell me about it. How do I impliment it on a Bondwell
Model 2, Jonos Escourt, etc.?

I read about another Z80 version of Unix that sounded a lot like OS-9
Level 2 in a 1983 or 1984 Microsystems magazine. It might have been
the Cromemco version. What about it?
0
puritan_2076 (115)
11/16/2003 11:56:35 PM
"Leon Howell" <puritan_2076@yahoo.com> wrote in message
news:ae64f04a.0311161556.3d12431a@posting.google.com...
> Why didn't I look this up earlier? There's a Z80 version of Unix
> called "Uzi". Tell me about it. How do I impliment it on a Bondwell
> Model 2, Jonos Escourt, etc.?
>
> I read about another Z80 version of Unix that sounded a lot like OS-9
> Level 2 in a 1983 or 1984 Microsystems magazine. It might have been
> the Cromemco version. What about it?

Cromix, I was given a copy of the 68K source, but it was on tape and the
tape was no longer readable.

The problem is getting the OS, then modifying it for your hardware.  I
mentioned MP/M since it is easily available and is well documented, all
available via free downloads.


0
randy482 (428)
11/17/2003 12:50:31 AM
On 16 Nov 2003, Leon Howell wrote:

> Why didn't I look this up earlier? There's a Z80 version of Unix
> called "Uzi". Tell me about it. How do I impliment it on a Bondwell
> Model 2, Jonos Escourt, etc.?
> 
> I read about another Z80 version of Unix that sounded a lot like OS-9
> Level 2 in a 1983 or 1984 Microsystems magazine. It might have been
> the Cromemco version. What about it?
> 

I know only that it evolved into UZIX, a *x for the MSX (which comes with 
an MSX-DOS emulator, and MSX-DOS is in fact compatible with CP/M 2.2, so 
perhaps CP/M 2.2 software can be run on UZIX).

-uso.

0
usotsuki (69)
11/17/2003 2:03:35 AM
"Randy McLaughlin" <randy482@nospam.com> wrote

> Cheap paging terminals were available long before CCP/M was even a dream (I
> used a Televideo 950), 

While the Wyse 60 had been available prior to CCP/M version 1, the
paged mode version of this with the optional ROM to provide PCMODE did
not come available until around 1984.

> as I have stated before page mode terminals are not
> required by DR products.  

MP/M never used them, no.  In fact CCP/M, CDOS and derivitives could
use any old serial terminal, as long as you only wanted one session. 
If you wanted to run Lotus on a terminal it needed to have PCMODE (and
CDOS-386 to virtualise it).  If you wanted fast VC switching it needed
to be paged mode.

> As far as having 16 byte FIFO's in serial ports it
> really helps take the load off the CPU.  I wish CompuPro and others had them
> it would have made their systems better in the multi-user world (even
> without it they still ran).

I don't think that Compupro used 8250s either.  While they did use
non-FIFO they didn't just have bare 8250s for their serial devices.
 
> As far as 544Kb was concerned CCP/M came out long after that barrier was
> given up.  

No, that is not true.  CCP/M version 1.0 for the PC was released in
September 1982.  The March 1983 release of CP/M-86 version 1.1 still
specifies the 544Kb limit.  The 544Kb limit was removed for both in
the 'for the PC XT' release in mid '83.

> Bigger barriers included CPU speed, hard drive speed, 

Or more specifically 'lack of Hard Drive' until the 'for the PC XT'
version.

> I found that Concurrent PC-DOS really helped support existing CompuPro
> customers keep their hardware and still run most DOS software.  Please note

There is a distinction between 'MS-DOS' software and 'IBM PC-DOS'
software.  For example Turbo Pascal 3 was available in several
versions: CP/M, CP/M-86, Mac, PC-DOS and MS-DOS.  The PC-DOS version
required an IBM-PC, the MS-DOS version could be configured for a
serial terminal which may have been an IBM-PC screen with ANSI.SYS or
could be an ADM-3A or VT-100.

Increasingly, less DOS software was runnable on dumb terminals. eg
Turbo-Pascal 4 simply could not be run using CDOS except on the main
screen of an IBM until CDOS-386 and PCMODE terminals.  Actually there
were some patches that could be used such as 'Soft PC' which actually
changed the loaded code of, say, Lotus, to stop it doing direct screen
writes.  These were version specific so it was all a bit of a waste
anyway.

> most of the people I supported did not have page mode terminals, but CCDOS
> ran just fine.

Without the 'Concurrent' no doubt.
0
riplin (4127)
11/17/2003 3:38:56 AM
puritan_2076@yahoo.com (Leon Howell) wrote 

> Why didn't I look this up earlier? There's a Z80 version of Unix
> called "Uzi". Tell me about it. How do I impliment it on a Bondwell
> Model 2, Jonos Escourt, etc.?

Note that 'Uzi' is _not_ 'a version of Unix'.  It is a set of programs
that make a Z80 look like, and somewhat operate like, a Unix command
line and is single user and single tasking.
 
> I read about another Z80 version of Unix that sounded a lot like OS-9
> Level 2 in a 1983 or 1984 Microsystems magazine. It might have been
> the Cromemco version. What about it?

At the start of the 80s there were several message passing OSes that
distributed the OS over several processors.  This overcame some of the
limitations of low power and small memory address space of 8bit
processors.  Many of these were proprietry such as ICL's DRX which
required at least 3 8085s for a client machine: workstation processor,
network processor, application processor.  The server required several
more such as file processor, communications processor.  Additional
application processors could be added to each machine, such as an
80188 board to run Concurrent-DOS or an AMD bit-slice to run 'legacy'
ICL 1500 applications.  CP/M could be run or native DRX programs on
each 8085 Application processor.
0
riplin (4127)
11/17/2003 4:46:14 AM
On 16 Nov 2003 20:46:14 -0800
riplin@Azonic.co.nz (Richard) wrote:

> puritan_2076@yahoo.com (Leon Howell) wrote 
> 
> > Why didn't I look this up earlier? There's a Z80 version of Unix
> > called "Uzi". Tell me about it. How do I impliment it on a Bondwell
> > Model 2, Jonos Escourt, etc.?
> 
> Note that 'Uzi' is _not_ 'a version of Unix'.  It is a set of programs
> that make a Z80 look like, and somewhat operate like, a Unix command
> line and is single user and single tasking.

Incorrect.  UZI (Uniz Z80 Implementation) started as an effort to graft
a Unix file system into CP/M and wound up being a Unix Edition 7 minimal
system.  It is multiuser/multitasking.  At least two ports of the system
have been made, Uzi280 and my UZI180 (available at
http://home.att.net/~halbower).

Hal
0
halbower (35)
11/17/2003 9:29:40 AM
> In all of the cases mentioned the OS does not care if you are on a terminal
> or not. 

Huh? I'm foncused. Is MP/M-II one of the cases mentioned?

> OS-9 Level 2 is based on a 6809/6309 CPU.  Please note that the
> source is available, but translating to another CPU is not practical.

I was refering to my desktop, a Tady CoCo 3. My whole reason for
anoying everyone here so much is that having a CoCo 3, I know what an
old computer should be capable of, and I want the same power from a
laptop.
 
> Try MP/M-II available for download from link provided below.

I will.
 
> The problem is many people think of OS's like DOS that run on a standardized
> environment, where MP/M is not a trivial task to get running from scratch.

Maybe I'm not as think as I confused I am, or maybe more, but it seems
like a matter of copying the CP/M bios routines to the right place in
MP/M. Oh yeah, then there's the extra memory...
 
> This assumes you are referring to an 8080/8085/Z80 based laptop (I saw your
> post on another group) and do have a mass storage device (ROM-disk,
> diskette, HD, etc).

I'm quite close to getting a Bondwell Model 2. Z80, 64k-512k ram, 360k
3.5" FDD, 80X24 LCD, ect.
0
puritan_2076 (115)
11/18/2003 3:32:55 AM
"Randy McLaughlin" <randy482@nospam.com> wrote in message news:<%Pztb.3923$a7.938@bignews3.bellsouth.net>...

> 
> I am sure that if you check the source for MP/M (also available on Gaby's
> site) you will probably find snippets of CP/M v1 (aka FDOS).
> 
> My biggest problem with CCP/M source is that it was built on what appears to
> be an unavailable PL/M compiler for the VAX.  Has anyone been able to
> compile CCP/M?  I have original DR source disks, but they are useless
> without the right environment (yes I sent Gaby copies of the disks which she
> has kindly posted).
>
But the kernal of ccp/m is in asm86 .a86 source.  Regarding the
original v2.1 ccp/m on Gaby's site, I did a build of that.  I don't
have my notes at hand, but there were a couple of difficulties.  Some
of the .a86 sources lacked the proper NL line termination, so I had to
convert those.  Then the submit files had to be edited to remove the
vax references.  Obviously the vax was the build enviornment, but that
can be eliminated since the tools are now native to the pc.  I didn't
have proper documentation at the time, I used a generic mp/m-86 manual
for the build process, still I got a compile without errors.  I did
this all on a hard drive using Freek Heite's Virtual Volumes Feature. 
Then, I had a problem finding the proper genccpm program that would
work at all, the genccpm builds the final image from the
sub-components, and user preferences.  I finally did find a version,
but I lost traceability of were it came from.  I think it was from
Gene Buckle's site, the Dri directory, but there are several there for
several computer makes.  The v2.1 directory on Gaby's site, has
genccpm in C source only, for Computer Inovations C Compiler.  But I
just checked the more recent ccpm code deposit [v3] and it has the C
source for the Dri C compiler instead.  Anyway, I did get genccpm to
generate a default image.  But there I stopped, until I get the chance
to do more research for the XIOS.  I see tonight that the v3 disks
have an IBM XT xios, written by Dean Ballard in late '83.  Dean
Ballard was the fellow who wrote the pc&xt boot strap, for the 5 1/4
diskettes.  That boot strap will load ccpm.sys if it finds it instead
of cpm.sys, on the diskette.  But anyway, all that it just a first
step to building a working ccpm.
> 
> Is there a PL/M-86 compiler available?

see Gaby's site:
MISC. UTILITIES : 196K Some more CP/M-86 programmers utilities

I've compiled ddt86 v1.1 with it from the pl/m src, that pl/m86 has a
directive to output an asm listing, which was what I was after. I
didn't have luck completely rebuilding asm86 because of the linker, it
didn't understand the link format that is in the batch file for
building it.
0
s_dubrovich (395)
11/18/2003 4:43:53 AM
"Leon Howell" <puritan_2076@yahoo.com> wrote in message
news:ae64f04a.0311171932.1221fcb@posting.google.com...

> > The problem is many people think of OS's like DOS that run on a
standardized
> > environment, where MP/M is not a trivial task to get running from
scratch.
>
> Maybe I'm not as think as I confused I am, or maybe more, but it seems
> like a matter of copying the CP/M bios routines to the right place in
> MP/M. Oh yeah, then there's the extra memory...
>
Well, not exactly.  MP/M works best with an interrupt driven BIOS, while
CP/M (pre v3) was primarily not interrupt driven as supplied by most
vendors.  At a minimum you'd have to add some sort of timebase interrupt to
get time slices for the processes.

MP/M had support for interrupt semaphores, allowing asyncronous I/O: the
XIOS (MP/M BIOS) routine set up the I/O conditions and then waited for a
completion flag.  The interrupt routine set the completion flag.  The
timebase interrupt triggered the task dispatcher.  None of that is in CP/M,
which was set up for synchronous I/O: the BIOS routine did not exit until
the I/O operation was complete, no interrupts or task dispatching.
   Jack Peacock


0
peacock (183)
11/18/2003 9:34:17 PM
"Jack Peacock" <peacock@simconv.com> wrote in message
news:VoWdnd0fFYfHDSei4p2dnA@mpowercom.net...
> "Leon Howell" <puritan_2076@yahoo.com> wrote in message
> news:ae64f04a.0311171932.1221fcb@posting.google.com...
>
> > > The problem is many people think of OS's like DOS that run on a
> standardized
> > > environment, where MP/M is not a trivial task to get running from
> scratch.
> >
> > Maybe I'm not as think as I confused I am, or maybe more, but it seems
> > like a matter of copying the CP/M bios routines to the right place in
> > MP/M. Oh yeah, then there's the extra memory...
> >
> Well, not exactly.  MP/M works best with an interrupt driven BIOS, while
> CP/M (pre v3) was primarily not interrupt driven as supplied by most
> vendors.  At a minimum you'd have to add some sort of timebase interrupt
to
> get time slices for the processes.
>
> MP/M had support for interrupt semaphores, allowing asyncronous I/O: the
> XIOS (MP/M BIOS) routine set up the I/O conditions and then waited for a
> completion flag.  The interrupt routine set the completion flag.  The
> timebase interrupt triggered the task dispatcher.  None of that is in
CP/M,
> which was set up for synchronous I/O: the BIOS routine did not exit until
> the I/O operation was complete, no interrupts or task dispatching.
>    Jack Peacock

Many systems do not already have a clock that you can use.

Most Laptops do have them (used for time-out into a sleep mode to save
batteries).

As I stated bringing up MP/M is not trivial.  You should start by either
finding technical information on your system.  Do not plan on having it
running MP/M for a while even if you have technical information.

Gaby's site has all of the software you need (MP/M-II & a sample XIOS).  You
can also see if she has the MP/M manuals.


0
randy482 (428)
11/18/2003 10:13:58 PM
s_dubrovich@yahoo.com (Steve Dubrovich) wrote:
>> I see tonight that the v3 disks
>> have an IBM XT xios, written by Dean Ballard in late '83.  Dean
>> Ballard was the fellow who wrote the pc&xt boot strap, for the 5 1/4
>> diskettes.  That boot strap will load ccpm.sys if it finds it instead
>> of cpm.sys, on the diskette.

Did you also notice that this CCPM XIOS has a few remarks about FIDD's? 
FIDDs are the Field Installable Device Drivers we already know from "CP/M-86 for
the IBM PC/XT, version 1.1".

Freek.
email: f.heite at hccnet.nl
0
me4 (19624)
11/18/2003 11:29:22 PM
me@privacy.net (Freek Heite) wrote in message news:<3fbaaab6.1196124@News.CIS.DFN.DE>...
> s_dubrovich@yahoo.com (Steve Dubrovich) wrote:
> >> I see tonight that the v3 disks
> >> have an IBM XT xios, written by Dean Ballard in late '83.  Dean
> >> Ballard was the fellow who wrote the pc&xt boot strap, for the 5 1/4
> >> diskettes.  That boot strap will load ccpm.sys if it finds it instead
> >> of cpm.sys, on the diskette.

-sorry, the boot strap for cp/m-86, that is.-

> 
> Did you also notice that this CCPM XIOS has a few remarks about FIDD's? 
> FIDDs are the Field Installable Device Drivers we already know from "CP/M-86 for
> the IBM PC/XT, version 1.1".
> 

Yes, also, from xinit.lib in D4 :

os_interrupt		equ	224		; normal CCP/M-86 entry
debugger_interrupt	equ	225		; debugger entry to O.S.
flag_interrupt		equ	228		; to get an unused flag
fidds_interrupt		equ	229		; for attachamatic drives
xios_interrupt		equ	230		; for ver 1.0 back door

Any idea what a 'attachamatic' drive is?
0
s_dubrovich (395)
11/19/2003 3:04:04 AM
I'm not quite ready for all that assembly language programming yet.
What about Z-System? I've heard it can do limited multitasking, but
how limited? Can a 512k CP/M 2.2 computer with Z-System task switch?
0
puritan_2076 (115)
11/25/2003 6:19:16 PM
Richard wrote:
> Which _mainframes_ have used _audio_ cassettes ? and what for exactly.

I don't know about mainframes, but we used a Texas Instruments "Silent
700" series terminal, which had two cassette drives, as the only form of
mass storage on a Data General 1200 minicomputer.

The Silent 700 had a thermal printer, ASCII keyboard, and two cassette
drives that used pretty much ordinary audio cassettes. TI specified that
cassettes with an extra notch cut in them should be used (certified for
digital use). But in fact, high quality audio cassettes worked just as
well.

The computer could send commands to the cassettes to select one or the
other, and play, record, fast-forward, or rewind them. A complete file
system ran on them, just like a disk with one track and thousands of
sectors.

This system was used in products sent to thousands of customers. New
software was sent out on cassettes, and loaded and run, and customers
maintained and edited their data files on them, exactly like disk
drives. The only drawback was that they were slower than disks.

> Certainly they used digital cassettes frequently.  Some may even look
> similar to a typical audio cassette, but aren't.

Basically, the digital cassettes were audio casettes with an extra notch
and higher-quality tape. You have to remember that many audio casettes
of the time were near-junk quality, intended for dictation and toys.
Today's audio casettes are basically the same as the digital-grade
cassettes back then.

> ROM BASIC _allows_ for any program to write whatever it likes, and
> to read it back as whatever it wishes. It does not _do_ anything to
> assist or prevent anything being done by the user or his program.
> That is why it is _not_ an OS.

I've never used the PC's cassette system. But I *have* used cassette
storage systems on many of the early computers. Pretty much all of them
had a file structure, so you could have multiple named files on a tape,
and the computer had control of the cassettes's motors so it could
randomly access the files you wanted.

In most cases, the code in ROM just loaded and executed the first file
on the tape. This file was a program that had the rest of the tape
operating system on it (just like booting from a disk).

So, it would not surprise me at all if there is a tape-based operating
system for the PC. It would use the ROMs to 'boot' it, then run a BASIC
program that created the file structure and all the needed commands to
load, save, delete, etc. files on the tape.

> Is the SOL-20 an IBM-PC ?  Is SOL-20 BASIC the same as IBM PC ROM
> BASIC ?

No, of course not. But the Commodore 64 used Microsoft BASIC in ROM, and
so did the PC. I would not be surprised if someone rewrote the C64
cassette operating system to run on his PC.
-- 
Lee A. Hart                Ring the bells that still can ring
814 8th Ave. N.            Forget your perfect offering
Sartell, MN 56377 USA      There is a crack in everything
leeahart_at_earthlink.net  That's how the light gets in - Leonard Cohen


0
leeahart (232)
1/6/2004 12:30:30 AM
In article <3FF9EC24.39CC@earthlink.net>, Lee Hart wrote:
> Richard wrote:
>> Which _mainframes_ have used _audio_ cassettes ? and what for exactly.
> 
> I don't know about mainframes, but we used a Texas Instruments "Silent
> 700" series terminal, which had two cassette drives, as the only form of
> mass storage on a Data General 1200 minicomputer.

I once worked on a Burroughs B800 minicomputer that had cassette drives.
Primary storage involved disks that looked remarkably similar to the
RK05; the system booted from an RK05-F equivalent (except the cartridge
had been removed) and data storage was on the system disk and a pair of
RK05-J equivalents. The cassettes weren't used for much by the time I
worked on the system (early '80s).

> Basically, the digital cassettes were audio casettes with an extra notch
> and higher-quality tape.

The tapes used on the Burroughs were of this type.

-- 
Roger Ivie
rivie@ridgenet.net
(Rated a 10 on the Fox Scale of Forth-Hatred)
0
rivie (670)
1/6/2004 3:13:56 AM
Reply:

Similar Artilces:

M times M = M?
Suppose M is a finite state machine. Is the product of M times M always equal to M? Yes, because if L is the lanaguage of M then the question becomes "L intersect L = L?". But is there other ways to prove this? >Yes, because if L is the lanaguage of M then the question becomes "L >intersect L = L?". But is there other ways to prove this? I believe what you're looking for is the notion of isomorphism. You can try to map the states and transitions of M to those of MxM in such a way that the transitions between the mapped states are exactly the mappings of the transitions between their originals. -- Reinier ...

CP/M Before CP/M 1.4
I have received 2 messages from one of my correspondents. Since they are historical, I am publishing some excerpts below. (Note: CP/M was announced to the public in 1976, in an advertisement publis= hed in "Dr. Dobb's Journal", and a demonstration made to the "Homebrew Comp= uter Club". IMSAI CP/M Version 1.33 was offered the 20 July 1977. Finally, = CP/M 1.4, the last 8" version, was released in 1978. Those were 2 hectic ye= ars. I have often wondered why nobody has thought of scanning those very fi= rst advertisements, since there are collectors of early microcomputer magaz= ines? Alas, the infamous "Erik S. Klein" does not answer my messages: yet, = he seems to have a good collection of those... What a pity!) Yours Sincerely, Mr. Emmanuel Roche, France I do remember a very few things from the very early days. CP/M 1.0 was prototypical. That is, it was never used on anything but a few= prototype 8080 machines. It was very buggy. CP/M 1.1 was basically a bug fix and was never officially released. CP/M 1.2 was again a bug fix, but was released by Gary to a few select indi= viduals as a beta. I was lucky enough to be among them. The actual version = I had was 1.21. This version was stable (sort of) but had no real BIOS asso= ciated with it. The 36 i/o steps at boot time made the computer smart enoug= h to access the paper tape reader in r/o mode only. The paper tape then loa= ded the BIOS into RAM, wh...

Any Televideo CP/M or C128 CP/M users here?
Hello! First post to this ng for me. I am a long time C= owner and have dabbled with the 128's CP/M mode in the 80's, but as a kid back then I had no exposure to any usable software for this mode. As an adult now I am revisitng it a bit. I've also bought a decent Televideo system that runs with the replacement HD I put in it, but crashes after it gets warm. I suspect I need to replace dried out capacitors. What's nice about the televideo is it came with the original manuals:-) Just curious if there are many CP/M(Z80) users here. Reading back a little bit looks like most here a...

ODE solvers location (rk2fixed.m, rk4fixed.m, rk8fixed.m, ode23.m, ode45.m, ode78.m)
As of May 2005 the link below locates several ODE solvers, at least 6 of which will work in both Octave and Matlab. <http://octave.sourceforge.net/index/calculus.html#Ordinarydifferentialequations> The six (described below) were maintained as a package and kept at two sites that are now no longer working. The octave.sourceforge.net location will serve as the home for the latest and greatest versions. The original Readme.txt for the solver package is pasted below for reference. ----------------------------------------------- This is the Readme.txt file for Octave m-file ordinary diffe...

Inform interpreter for Z80 CP/M? (CP/M 3.0)
Is there an Inform interpreter available for CP/M 2.2 or CP/M 3.0? It would be really sweet to play .Z5 or .Z8 games on the CP/M mode of the C-128 (especially in 80 column mode). Paul In article <1120335064.819790.69100@g44g2000cwa.googlegroups.com>, <dunric@yahoo.com> wrote: >Is there an Inform interpreter available for CP/M 2.2 or CP/M 3.0? > First, there is no such thing as an "Inform interpreter." Inform is a development system for generating binaries for the Z-machine. If you want to run those binaries, you need an implementation of the Z-machine. Suc...

CP/M Software Library from the CP/M User Group (UK) ?
Hi all! It's the CP/M Software Library from the CP/M User Group (UK), available somewhere? Thanks. Floppy Software wrote: > Hi all! > > It's the CP/M Software Library from the CP/M User Group (UK), available somewhere? > > Thanks. Recently searched for this myself without luck. Only found catalog listings online. They had stuff that was unique such as STOIC support and programs. >>> Is the CP/M Software Library from the CP/M User Group (UK), available >>> somewhere? I once found an archive of the Dutch CP/M User Group. Se...

Can cp/m 86 run cp/m 80 software ??
just wondering if the cp/m for the 8086 can run software for the 8080 and z80 computers ?? On Sun, 10 Jul 2005 01:21:57 -0000, in <42cfeb58$1@news.rivernet.com.au>, "molla barzani" <bsdstar@hotmail.com> wrote: >just wondering if the cp/m for the 8086 can run software for the 8080 and >z80 computers ?? Nope. On Sun, 10 Jul 2005, molla barzani wrote: > just wondering if the cp/m for the 8086 can run software for the 8080 and > z80 computers ?? No. It is however much more trivial to code a CP/M-80 emulator for CP/M-86 (and if you're running one of ...

Robot PD: CP/M software / Sprite Routines in CP/M v2.2
Hi Folks, I'm interested in Acquiring the following: Arcade games including Tetris clone Quatris, Pacman, Tornado, and Maze Chase. Some not CP/M 2.2: Tornado CP/M 2.2 only It's mentioned in here: ftp://ftp.barnyard.co.uk/robot-pd/index.html though isn't in the directory. At least if it's not available can someone tell me about those games? I'm trying to incorporate some sprites into my programs. On my website (http:// turpas3.angelfire.com/) I'm trying to improve my Bouncy Ball routine (BOUNCY.PAS) which simply Plots the Image onscreen (kind of works a ...

CP/M Items on eBay (CP/M Plus, Wordstar, DBPlus, DBASE II, CBASIC)
I've listed several interesting items on eBay that this community may be interested in. CP/M Plus http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=130886596269&ssPageName=STRK:MESE:IT DBASE II http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=130886598254&ssPageName=STRK:MESE:IT DBPlus http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140952388139&ssPageName=STRK:MESE:IT Wordstar http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140952384292&ssPageName=STRK:MESE:IT CBASIC Compiler http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140952379954&ssPageName=STRK:MESE:IT CP/AM 5.1.1 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140952377100&ssPageName=STRK:MESE:IT If anyone has a good way to test these disks without a CP/M card I'm all ears. I know the CP/M Plus and CP/AM disks told me that there was no CP/M card present in my machine, so I'm sure those work but have no idea how to validate the others. Cheers, Jesse On 4/9/13 5:25 PM, Jesse wrote: > If anyone has a good way to test these disks without a CP/M card I'm all > ears. Use ADTPro to make images of the disks. You can use cpmtools to check the directory structure of the disks/extract contents and/or use an emulator with Apple II z80 support (e.g. Virtual ][ for the Mac). On 2013-04-09 21:51:09 +0000, Egan Ford said: > Use ADTPro to make images of the disks. You ca...

5 1/4 Compupro boot disk for CP/M-86 and CP/M 2.2
Help, please! Anybody have a 5 1/4 boot disk for Compupro CP/M-86 and 2.2? If not, ideas on where I can get them? Thanks! Rich >Anybody have a 5 1/4 boot disk for Compupro CP/M-86 and 2.2? If not, >ideas on where I can get them? Hi Rich, I have an original 2-disk set of Compupro CP/M-86 on 8" disks. Unfortunately I don't have a 5.25" set, however is it possible to configure a dual-drive type system and make a 5.25" boot disk after booting from the 8"? I would be interested in any Compupro CP/M-86 copies you dig up, either 5.25" or 8" - I have a System with the CPU 86/87, Disk-1A, Interfacer-4 and RAM - with the boards configured exactly as described in the "how to get going in 5mins" section, the system goes through all the motions of booting (recalibrates to track-0, reads a bit, steps to track-1, reads a bit and then seeks out to the middle of the disk). As far as I can tell, it is actually booting, however I do not get any serial data activity on any of the Interfacer-4 ports. I do note that the RS-232 control signals RTS/DTR do come up at the point where the system steps out to track-1, so it would appear that something is initializing the ports. I haven't had a chance to look at it in detail yet, but I'd guess that either I have a problem with the Interfacer-4, or the CP/M disks that I have are configured for a non-default address (the disks didn't come from the same source as the system). It would ...

PL/M sources for old CP/M?
Somewhere among the recent discussion threads, was some discussion about the old PL/M sources of an early version of CP/M which was apparently released, and then removed, from the CPMUG disk library many years ago. This has been discussed before in comp.os.cpm, and I put some of those notes on my DRI Web site. After further Web work and discussion with Udo Munk, I've updated those notes: http://www.retrotechnology.com/dri/dri_public.html Bottom line: online copies of CPMUG disk #5 don't have these old PLM files, and other copies online of these files are missing or corrupt. If anyone...

M&M VI
When I first played Might and Magic VI: The Mandate of Heaven the music was an allegro theme with multiple violins and a few cellos thrown in, but then I tried to stream it (and failed) and not I have the "correct" audio (I did not know until I checked secondary sources). What I want to know is, have any of you had any experience with a different M&M VI OST? Andres <BeefEatingRobot@gmail.com> wrote: >When I first played Might and Magic VI: The Mandate of Heaven the music was >an allegro theme with multiple violins and a few cellos thrown in, but then &...

Wanted CP/M for an LSI M-THREE computer
Hi, I've recently restored an early 1980s British built Z80 computer, an LSI M-= THREE/250. The 250 denotes it as the duel DS DD 8" drive model. I've got = some pics of it here: https://goo.gl/photos/tMza3ootuxB6FYF38 Now, this is a bit of a long shot, but I wonder if there is anyone out ther= e that may have any OS diskettes for this beast. I won't hold my breath her= e! =20 I've already disassembled and commented most of the boot/bios prom and base= d on what I've learned from it have written a monitor prom. I've included = an Intel hex file ...

;M@M@MMMMB
:i. , 2BBMM: 7@;ZMMMMMa MM XiMMM ZMM0 ,r: M , MMZ BM7, MM; 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0M0 0 0 .: 0 0 0 0 .,i 1 40 ZM 0 0 rMW 0 0 0 0 0 0 .MMM 0 0 0 0 0 0 0 0 0 0 0 0 0 0 .MM. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8MMX @MM BMMWMMMMZWM0MXi. rMMi : M7 ,.M, rri:ZMM@MX MM 7MZMa .. MMa;MMM@MM. :M:, .MMM MMMMMM.:@MMMMMMBBM MMSM :BMB iMZ XMM: r@WM0WMX XMM@M MMr..MMM BMi :M,:MMMMMM2WM :@MMWMMM0M MM0M0 8MM 7Mi iMMXMWWMW .MM;M@M@MMMMBMM rMMMB...

what's the difference between a^M and a.^M, where M is a matrix?
I know how a.^M operates, but don't know what a^M means. On 26/01/11 12:03 PM, Ha wrote: > > I know how a.^M operates, but don't know what a^M means. a^2 is a*a which is linear algebraic matrix multiplication "Think blue, count two." <roberson@hushmail.com> wrote in message <KGZ%o.53285$T87.16755@newsfe01.iad>... > On 26/01/11 12:03 PM, Ha wrote: > > > > I know how a.^M operates, but don't know what a^M means. > > a^2 is a*a which is linear algebraic matrix multiplication M is a NxN matrix, rather than a scalar. ...

GraphEdit.m & JavaGraphics.m
What are the packages GraphEdit.m and JavaGraphics.m that I find in the directory ToFileName[{$InstallationDirectory,"SystemFiles","Graphics","Packages"}] of Mathematica 5.1? Are they part of the Mathematica 5.1 distribution? Or from some 3rd party Add-on? -- Murray Eisenberg murray@math.umass.edu Mathematics & Statistics Dept. Lederle Graduate Research Tower phone 413 549-1020 (H) University of Massachusetts 413 545-2859 (W) 710 North Pleasant Street fax 413 545-1801 Amherst, MA 0100...

Are CCP/M and MP/M 86 the same?
I don't know much about cp/m, I've only used it on my AppleII. Now I would like to put on a multi-user system on a old PC-XT clone, just for fun, but I don't know which system should I use: CCP/M or MP/M-86. Somewhere on the net I found that they should be the same thing, elsewhere they say they are different systems... can you clear this up? Igor "wanji" <ikanja@despam....com> wrote in message news:xn0di9x9w8ypnh005@powernews.libero.it... > I don't know much about cp/m, I've only used it on my AppleII. Now I > would like to put on a multi-user syste...

M&M logo font
Does anyone know where I could (free, hopefully) download the logo font or something similar to that used by m&m's? Help appreciated Lance -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <bv5ihp$ca0$1@ctb-nnrp2.saix.net>, "Istari" <istari_6@hotmail.com> wrote: > Does anyone know where I could (free, hopefully) download the logo > font or something similar to that used by m&m's? The font, Rockwell Condensed by Monotype, is illustrated at <http://www.smackbomb.com/famousfonts/fonts/mms.html>, but it isn't available for down...

Pentium M & Celeron M
Hi, Does anyone know where I can possibly buy Pentium M or Celeron M processors between the range of 900 MHz to 1.1 GHz. I tried looking at several websites and called many of them, none of them had any in stock. any help is greatly appreciated, Thanks hk g0000gler@yahoo.com (hk) wrote in message news:<79daf10c.0406091318.32d83928@posting.google.com>... > Hi, > > Does anyone know where I can possibly buy Pentium M or Celeron M > processors between the range of 900 MHz to 1.1 GHz. > I tried looking at several websites and called many of them, none of > them ...

ALGOL/M 1.1 for CP/M by LT Mark Moranville
Hi folks, I was trying to do some casual programming using ALGOL/M just to see what I could do with it, anyway I came across this one since it's got a bit of documentation for it with it, though unfortunately I couldn't find out if it has some support for Assembly code, so I presume that this one doesn't have any support for it. The other issue I encountered was with one of the programs which comes with it, called LUNAR.ALG. Here's the original program: BEGIN COMMENT UPDATED LUNAR LANDER FROM KILOBAUD AUGUST 78; DECIMAL F,V,D,B,C; INTEGER A; WRITE(TAB 8,"LUNAR LANDER MKII"); WRITE(TAB 8,"+++++++++++++++++"); WRITE(" "); WRITE("WOULD YOU LIKE INSTRUCTIONS?"); WRITE("1=YES 0=NO"); READ(A); IF A=1 THEN BEGIN WRITE("YOU HAVE 120 LBS OF FUEL"); WRITE("YOU ARE APPROACHING THE LUNAR"); WRITE("SURFACE AT 50 FT/SEC, AND"); WRITE("ARE CURRENTLY 500 FT FROM"); WRITE("THE SURFACE, TO CANCEL"); WRITE("GRAVITY BURN 5 LB FUEL"); END; A:=1; WHILE A=1 DO BEGIN WRITE("HAPPY LANDINGS!!!!"); F:= 120.0; V:=50.0; D:=500.0; FUEL:WRITE("FUEL ", F); WRITE("SPEED ",V); WRITE("DISTANCE ",D); INPUTBURN:WRITE("ENTER YOUR BURN"); READ(B); IF B>F THEN GOTO INPUTBURN; F:=F-B; C:=B-5.0; D:=D-V+C/2.0; V:=V-C; IF D>0 THEN GO TO FUEL; IF V>=5.0 THEN BEGIN WRITE("****!!!CRASH!!!****");...

obsolete Matlab functions (year.m, month.m, day.m)
I recently obtained Matlab 2009a -- 7.8.0.347 (R2009a). I found that my scripts that call the simple functions year.m, month.m, and day.m do not work. The reason for this is that they are not available, from what I can tell (type "help year"). But they are available in 2008ab, so I can simply save the m-files from 2008ab and use them in 2009a. But this has led to three questions. 1. Are year.m, month.m, day.m obsolete in 2009a? 2. Is there a list of functions that become obsolete from one version to the next? 3. Is there a "master" function reference that would incl...

Running M&M Classic under XP
When dusting off old discs, I found my M&M 6 disc with all the prior M&Ms on it. I remembered I'd never come close to finishing World of Xeen, and thought I'd give it a go. It launches find under XP, but, when I try to sign in at the inn, it freezes up. Any ideas? *----------------------------------------------------* Evolution doesn't take prisoners:Lizard "I've heard of this thing men call 'empathy', but I've never once been afflicted with it, thanks the Gods." Bruno The Bandit http://www.mrlizard.com Lizard <lizard@mrlizard.com> writes:...

Dark Messiah of M&M demo is out!
And it's a whopping 1415MB file! It's out on Fileshack, 3D gamers, Boomtown, fileplanet and many more. Bob Loblaw wrote: > And it's a whopping 1415MB file! > > It's out on Fileshack, 3D gamers, Boomtown, fileplanet and many more. Isn't that like Heretics/Hexen? i.e. a standard shooter but fireballs instead of rockets? Awsome http://grispernmix.googlepages.com/darkmessiahofmight%26magic Wolfing wrote: > Bob Loblaw wrote: > > And it's a whopping 1415MB file! > > > > It's out on Fileshack, 3D gamers, Boomtown, fileplanet and m...

SCKSERV1.m & SCKCLI.m scripts: where are they ?
Hi, I've been desperately looking for these files, to no avail, unless the page http://www.vmth.ucdavis.edu/m/gtm/GTM_sockets.html contains everything (if I gather together the lines overlined in blue) ?? I'm also looking for a clear-cut and detaild procedure as to how to run a GT.M server process that I would connect to through TCP. Has it been described (with a full example of a client connection too) somewhere ?? Thanks a lot in advance... Seb On 30 =A7=F1=A7=DF=A7=D3, 03:48, S=A8=A6bastien de Mapias <sglrig...@gmail.= com> wrote: > Hi, > I've been desperately looking for these files, to no avail, unless > the pagehttp://www.vmth.ucdavis.edu/m/gtm/GTM_sockets.html > contains everything (if I gather together the lines overlined in > blue) ?? > > I'm also looking for a clear-cut and detaild procedure as to how > to run a GT.M server process that I would connect to through > TCP. Has it been described (with a full example of a client connection > too) somewhere ?? > > Thanks a lot in advance... > Seb I founded these examples (%socketserv*.m and %socketcli*.m) in the archives on http://sourceforge.net among the other GT.M products. Also if You are going to organize the connection through the TCP ports You should take into account the fact of blocking this device by the Apache for own needs. The good helper for this is the GT.M documentation (the part of the Programmer's guide for opening/use external devi...

Web resources about - CP/M, CP/M+, PCP/M, MP/M, & Z-System - comp.os.cpm

Sony Ericsson Z-System: the PlayStation Phone's gaming platform?
A bumper crop of circumstantial evidence surrounding the Android-based PlayStation Phone is starting to come together today when it rains, it ...

Open Directory - Computers: Software: Operating Systems: CPM
Z-Node 51 - Downloads and information for CP/M, Z-systems and Z80 computers. Includes a collection of articles and manuals, too. ZCN - Operating ...

Eagle Computer - Wikipedia, the free encyclopedia
Eagle Computer of Los Gatos, California , was an early microcomputer manufacturing company. Spun off from Audio-Visual Laboratories (AVL), it ...

Sony Ericsson » 4/7 »
Android Apps and News Accessories Bluetooth Car Cases Chargers Docks Android apps Arcade & Action Arcade and Action Books & Reference Brain & ...

List of Private Companies Worldwide, Letter Z - Businessweek
Browse the Private Company Directory with over 300,000 companies worldwide. Find a list of private companies letter Z by business name, industry ...

List of Private Companies Worldwide, Letter Z - Businessweek Businessweek - Business News, Stock Market ...
Browse the Private Company Directory with over 300,000 companies worldwide. Find a list of private companies letter Z by business name, industry ...

GEnie C128 CPM Listing
This site is all about Commodore files for serious Commodore users

Posts tagged PlayStationPhone at Engadget
Engadget for iPad - get the app now! AOL MAIL Engadget Classic Mobile HD ALT ENGADGET U.S. ESPAGÑOL ???? ???? ??? ???? DEUTCHLAND FEATURES: DVR ...

Playstation Phone: the rumor that won't die
All week long the Playstation Phone (as well as the PSP2) has been in the news. Let's recap the story and see if we've learned anything new. ...

Sony Ericsson Xperia X12 "Anzu" image leaked
Details leak on the Sony Ericsoon Xperia X12, codenamed "Anzu"

Resources last updated: 3/26/2016 7:10:35 AM