cp/m and new computers
flo...@gmail.com
budget) and was wondering if it was possible to run CP/M on a modern
machine. Is this possible, or would special hardware be required?
Randy McLaughlin
news:1108926469.1...@c13g2000cwb.googlegroups.com...
> I'm planning on building a computer over the summer (on a limited
> budget) and was wondering if it was possible to run CP/M on a modern
> machine. Is this possible, or would special hardware be required?
If you want to run CP/M-86 that runs on new computers. If you want to run
CP/M-80 then you can:
a) Emulate it on a new PC.
b) Buy a eZ80 based sytem (from $99 + $20 to hook up MMC).
c) Roll your own.
I'm doing the first two, my website has a couple of good emulators and links
to others. If you decide to use an emulator you need to decide what your
goal is.
Randy
www.s100-manuals.com
flo...@gmail.com
so emulating seems like the best option.
nos...@nouce.bellatlantic.net
wrote:
>I'm planning on building a computer over the summer (on a limited
>budget) and was wondering if it was possible to run CP/M on a modern
>machine. Is this possible, or would special hardware be required?
By modern I believe you mean using PC hardware.
To that end under Windows or Linux are a number of Z80 and CP/M-80
emulators for CP/M-80 versions of the OS. I happen to use MyZ80
under Win/nt for a number of things.
There is CP/M-86 that should run directly (it's 8086 native).
If your hardware bent, Z80s and other chips to build hardware system
are still available. Using commonly available static memory and
EEproms would make the task straightforward. The hardest part is
one of deciding what kind of IO (serial to a terminal emulator on PC
is easiest) and Storage (floppy, IDE disk, or one of the large flash
ram devices).
An the TI-83 is a z80 system in a small package and could likely run
CP/M-80 and certainly Z80 programs!
I'd say the hard part is deciding what path you'd like to persue given
all the possible avenues.
Allison
Moll
Assuming you mean a PC, *CP/M-86* is certainly possible as-is. CP/M-80,
only through emulation unless you have special hardware.
Moll.
Randy McLaughlin
message news:eAnSd.31895$s16.22291@trndny02...
As I already posted CP/M-80 on a new machine is easy, Zilog is still selling
Z80 based computers (eZ80). CP/M-80 runs on it using a digital camera
memory card (SD or MMC).
Randy
www.s100-manuals.com
ruediger
> There is CP/M-86 that should run directly (it's 8086 native).
>
10 GB are out of scope of CP/M-86, it can only use 8 MB....
I use the Bochs-Emulator: a 8086-Emu(!!!) on Win95 and newer...
it works very well with Disk-Images
(Hint: you must turn off boot disk checking)
rüdiger
French Luser
> 10 GB are out of scope of CP/M-86, it can only use 8 MB....
Of course, since CP/M-86 is as simple a 8086 implementation
as possible of CP/M 2.2. So, it has the same limitations.
However, MP/M II (multi-user) and CP/M Plus (single user)
both used BDOS 3, which allows files up to 32 MegaBytes
and Hard Disks up to 512 Megabytes...
And 16 drives * 512 MB = 8 GigaBytes...
So, you decide if you prefer to stay with CP/M 2.2,
or join the CP/M Plus band! (Available in 8086
version as CP/M-86 Plus or DOS Plus (with
a MS-DOS v2 emulation layer). Both are single user.
Concurrent CP/M 3.1 is the multi-user version.)
Yours Sincerely,
"French Luser"
nos...@nouce.bellatlantic.net
>>
>> There is CP/M-86 that should run directly (it's 8086 native).
>>
>With 3.5 Disk it works well but the trouble is the harddisk:
>10 GB are out of scope of CP/M-86, it can only use 8 MB....
Two solutions:
Multiple partitions of 8mb.
Or one 32mb! CP/M-86 went to 32mb on hard disks.
>I use the Bochs-Emulator: a 8086-Emu(!!!) on Win95 and newer...
>it works very well with Disk-Images
>(Hint: you must turn off boot disk checking)
Thats the emulation route and also a fun way to go.
Allison
Moll
Random but on-topic. XD;
I've enjoyed writing emulators of my own, though I haven't had the luck
some have had, to actually get CP/M fully operational on a homemade
emulator.
It's something I'm still trying to do though. XD
Moll.
nos...@nouce.bellatlantic.net
<Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>Random but on-topic. XD;
>
>I've enjoyed writing emulators of my own, though I haven't had the luck
>some have had, to actually get CP/M fully operational on a homemade
>emulator.
>
>It's something I'm still trying to do though. XD
The problems are many. First you have to emulate the target CPU, Z80
being popular for CP/M-80. The next step is a boot debug environment
(pseudo front pannel). Then you have to emulate a hardware
environment namly Terminal IO, Disk and maybe printer though thee can
be translated and handled by the host OS to a device stub. Then you
write a BIOS for the proposed CP/M system in the native CPU form to
interface CP/M to the IO infrastructure. The rest configuring the
pseudo disk (establishing it's base format when erased) and copying
the OS to it. Thats the overview for a CP/M system and I've left
out detail but doing it in an emulator is about the same as real
hardwware. Usually the hardware version is harder as getting any
software/firmware in it requires either a front pannel or a monitor
program burnt into Eprom with the first hardware bring up debug
cycle(s) in there. I've done this more than a few times and consider
it the most exciting part.
Allison
Moll
> The problems are many. First you have to emulate the target CPU, Z80
> being popular for CP/M-80.
Easy enough, and I use an existing core for that.
> The next step is a boot debug environment
> (pseudo front pannel).
I've always hardwired the boot process, though, adding a debugger isn't
impossible.
> Then you have to emulate a hardware
> environment namly Terminal IO, Disk and maybe printer though thee can
> be translated and handled by the host OS to a device stub.
This is the easy part. I can bang that out in a few minutes.
> Then you
> write a BIOS for the proposed CP/M system in the native CPU form to
> interface CP/M to the IO infrastructure. The rest configuring the
> pseudo disk (establishing it's base format when erased) and copying
> the OS to it. Thats the overview for a CP/M system and I've left
> out detail but doing it in an emulator is about the same as real
> hardwware. Usually the hardware version is harder as getting any
> software/firmware in it requires either a front pannel or a monitor
> program burnt into Eprom with the first hardware bring up debug
> cycle(s) in there. I've done this more than a few times and consider
> it the most exciting part.
>
> Allison
These parts are more difficult :( and I haven't quite gotten it all
working. (Can't seem to grok TFM, but I'm a bit of a n00b at all of this.)
Obviously the methodology of rolling a "realistic" emulation of a
CP/M-80 based micro is the same or similar to that of building a custom
Z80 box to run CP/M on, and it's a heck of a lot cheaper for someone on
a fixed income.
I like seeing my code work. :) That's the fun part of coding emulators,
and why I've coded Apple ][, CBM3032/4032/8032 and SYM-1 emulators - and
why I've wanted to code a custom CP/M-80 emulator. It's as close as I
can hope to get to the real thing, and I can make it even closer. :)
Moll.
Randy McLaughlin
message news:WlMSd.78676$QS5.51746@trndny06...
<snip>
> These parts are more difficult :( and I haven't quite gotten it all
> working. (Can't seem to grok TFM, but I'm a bit of a n00b at all of
> this.)
>
> Obviously the methodology of rolling a "realistic" emulation of a CP/M-80
> based micro is the same or similar to that of building a custom Z80 box to
> run CP/M on, and it's a heck of a lot cheaper for someone on a fixed
> income.
>
> I like seeing my code work. :) That's the fun part of coding emulators,
> and why I've coded Apple ][, CBM3032/4032/8032 and SYM-1 emulators - and
> why I've wanted to code a custom CP/M-80 emulator. It's as close as I can
> hope to get to the real thing, and I can make it even closer. :)
>
> Moll.
If you used a CP/M system in the past you liked do us all a favor and
emulate it, especially if it is one not being emulated now.
Right off the top of my head there are emulators for (excluding the MESS
mess):
Altair
http://www.parse.com/~ddunfield/museum/index.html
http://highgate.comm.sfu.ca/~rcini/classiccmp/Altair32.htm
http://simh.trailing-edge.com/
Horizon
www.s100-manuals.net/dunfield
RadioShack Model 4
http://www.vavasour.ca/jeff/trs80.html
http://www.tim-mann.org/xtrs.html
http://www.arrowweb.com/mkr/
SOL-20
http://www.thebattles.net/sol20/sol.html
Soon to come (hopefully):
Cromemco
Maybe other can chime in and expand the list, please note I am not listing
the variety of generic CP/M emulators (MyZ80 etc).
Randy
www.s100-manuals.com
Dave Dunfield
Horizon which boots and runs all N* os's that I've found so far, including about
4-5 different versions of CP/M - It's not up on my site yet, but Randy has given
me some space on s100-manuals.net at the link he mentions below - As the
primary purpose of the emulator is as a bootstrap tool, I only include N* DOS
with it, however I've also posted about 65 disk images including several
flavors of CP/M, N* DOS, UCSD Pascal, and even my own OS (from a long
time ago :-)
Btw, Allison - if the other guy does not take that spare N* DD controller that
you have, I would be very interested in it - I'm gettng a Horizon backplane,
and hope to build up a completely functional (if not pretty) Horizon system
for ongoing testing and maintenance (I don't have an actual Horizon - the
main reason I wrote the sim was so that I could boot and modify the standard
Horizon distributions so that I could use them on my other systems -- Give
the simulator the /V switch and it will come up in the configuration of my
Vector-1 which is the closest I have at the moment).
>Right off the top of my head there are emulators for (excluding the MESS
>mess):
>Altair
>http://www.parse.com/~ddunfield/museum/index.html
Actually, I don't have CP/M running on my Altair (or the emulation of it)
because it has only the Single-Density NorthStar controller installed.
Although I've heard from a couple of reliable sources that there was a
CP/M done for the SD controller, I've never seen it ... If anyone has any
version of CP/M for the single-density NorthStar controller, I would very
much like to hear from you.
>Horizon
>www.s100-manuals.net/dunfield
This is the one described above.
Regards,
Dave
--
Dunfield Development Systems http://www.dunfield.com
Low cost software development tools for embedded systems
Software/firmware development services Fax:613-256-5821
nos...@nouce.bellatlantic.net
Dave.D...@use.techsupport.link.on.my.website (Dave Dunfield)
wrote:
>I've just (within the last couple of weeks) done an emulator for the NorthStar
>Horizon which boots and runs all N* os's that I've found so far, including about
>4-5 different versions of CP/M - It's not up on my site yet, but Randy has given
Cool beans! The only thing that truely made the NS* distinct was the
base IO tended to be standardized as all Horizons had the same
backplane with IO and of course the MDS floppy that was near bullet
proof relaible. There wer several features of the NS* cpu card and
backplane IO such as vectored interrupts on the cpu card and ability
to generate and mask interrups of the IO as well as a user
configureable heartbeat interrupt. All of the MDS (SD or DD) based
CP/M versions I had would crash if they were jumpered and interrupts
were enabled as they had no interrupt processing Same for NS* dos as
late as V5.2.
Did you do the multiuser version of NS*dos?
>Btw, Allison - if the other guy does not take that spare N* DD controller that
>you have, I would be very interested in it - I'm gettng a Horizon backplane,
Its on it's way to him.
>and hope to build up a completely functional (if not pretty) Horizon system
>for ongoing testing and maintenance (I don't have an actual Horizon - the
>main reason I wrote the sim was so that I could boot and modify the standard
>Horizon distributions so that I could use them on my other systems -- Give
>the simulator the /V switch and it will come up in the configuration of my
>Vector-1 which is the closest I have at the moment).
When you get the horizon let me know. I can be reached at KB1GMX at
ARRL dot NET.
I still have two of them. One I plan to use and one as spare but
missing a chip or two (socketed). I keep them for historical
reasons as it was one of the things that blocked mainstream software
progress for me early on being hard sectored which lead to me doing
all sorts of smart subsystems and networking to get around it. Since
then I've gone to 765 and DMA based floppy systems as I worked for
NEC back then and still have gobs of them.
Allison
nos...@nouce.bellatlantic.net
<Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>I've always hardwired the boot process, though, adding a debugger isn't
>impossible.
Not unreasonable. However creating a debug environment allows youto
see where and what the emulated cpu is up to.
>These parts are more difficult :( and I haven't quite gotten it all
>working. (Can't seem to grok TFM, but I'm a bit of a n00b at all of this.)
TFM???
>Obviously the methodology of rolling a "realistic" emulation of a
>CP/M-80 based micro is the same or similar to that of building a custom
>Z80 box to run CP/M on, and it's a heck of a lot cheaper for someone on
>a fixed income.
Verry true. There is one difference, software is easier to change
than hardware. ;)
Good luck.
Allison
John Elliott
: Maybe other can chime in and expand the list, please note I am not listing
There are various emulators which can do the Amstrad CPC series and
the Sinclair Spectrum +3, both of which could run CP/M+.
My own JOYCE <http://www.seasip.demon.co.uk/Unix/Joyce/> can do all models
of Amstrad PCW, and they could all run CP/M+.
--
------------- 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
:-------------------------------------------------------------------------)
Dave Dunfield
>base IO tended to be standardized as all Horizons had the same
>backplane with IO and of course the MDS floppy that was near bullet
>proof relaible. There wer several features of the NS* cpu card and
>backplane IO such as vectored interrupts on the cpu card and ability
>to generate and mask interrups of the IO as well as a user
>configureable heartbeat interrupt. All of the MDS (SD or DD) based
>CP/M versions I had would crash if they were jumpered and interrupts
>were enabled as they had no interrupt processing Same for NS* dos as
>late as V5.2.
As far as I know, there was no version of N* DOS which loaded at 0000,
and would have had access to the interrupt vectors (I loaded my debugger
down there to have access to them however!)
In the archives on Randy's site, I have a pile of N* images, including
DOS 5.0(D), 5.1(S), 5.2(DQ) and INSUA 2.1.1 (replaced 5.2, and is possibly
the last version of NorthStar DOS). I've also just recreated a bootable
N* DOS 2 by assembling a DOS 2 disassembly that Barry W. did and
injecting it into a blank disk image.
FYI, included with the simulator are tools to manipulate the image files
(import/export files to the PC etc.) and another tool to transfer images
to and from real disks via serial link to the N* system.
Would be very interested in images of os versions and applications
not already in the archive.
re: "All of the MDS (SD or DD) based CP/M versions I had"
- do you have a version of CP/M for the SD controller?
>Did you do the multiuser version of NS*dos?
Another one I've not heard of before - I was unaware that there ever was a
multi-user version of N* DOS ... More infomation please?
I currently do no have disk and console interrupts implemented on my
simulator (never saw them used), however I certainly could do so...
>>Btw, Allison - if the other guy does not take that spare N* DD controller that
>>you have, I would be very interested in it - I'm gettng a Horizon backplane,
>Its on it's way to him.
Thats good - he needs it more than I do right now - I've been working with him
on and off for a few weeks to try and get his system running, but it's been hard
to do so remotely - anyone in WI that can help, please step up!
Once we get him up and running, I'll see if I can get the left over controller
from him - once nice thing about N* controllers - they are easy to fix!
>When you get the horizon let me know. I can be reached at KB1GMX at
>ARRL dot NET.
>I still have two of them. One I plan to use and one as spare but
>missing a chip or two (socketed). I keep them for historical
>reasons as it was one of the things that blocked mainstream software
>progress for me early on being hard sectored which lead to me doing
>all sorts of smart subsystems and networking to get around it. Since
>then I've gone to 765 and DMA based floppy systems as I worked for
>NEC back then and still have gobs of them.
Will do - I still hope to find a complete Horizon, as I did have and use one
a lot years ago, and I would like to have one in the collection (see link
below - I'm a bit weird when it comes to old computers)...
I too went to a 765 based system, which I used in my D6809 homebuilt -
lots of photos, documents, source code and a simulator are available on
my site if you want to check out that one...
Regards,
Dave
--
dave04a@ Collector of classic pre-PC computer systems.
dunfield. If you have an old 8/16 bit non-PC system in need of a good
com home, please contact me at email address on the left, or
via contact link of this web site:
http://www.parse.com/~ddunfield/museum/index.html
Moll
> On Tue, 22 Feb 2005 20:11:34 GMT, Moll
> <Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>
>>These parts are more difficult :( and I haven't quite gotten it all
>>working. (Can't seem to grok TFM, but I'm a bit of a n00b at all of this.)
>
> TFM???
The fscking manual... lol
Moll.
nos...@nouce.bellatlantic.net
<Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>>>These parts are more difficult :( and I haven't quite gotten it all
>>>working. (Can't seem to grok TFM, but I'm a bit of a n00b at all of this.)
>>
>> TFM???
>
>The fscking manual... lol
Ah a unix-ism. ;)
I'll gladly answer questions about CP/M bios here.
Allison
nos...@nouce.bellatlantic.net
Dave.D...@use.techsupport.link.on.my.website (Dave Dunfield)
wrote:
>As far as I know, there was no version of N* DOS which loaded at 0000,
>and would have had access to the interrupt vectors (I loaded my debugger
>down there to have access to them however!)
;-) There was one. I created it by disassembly and relocation.
Still had a boot to 2000h. However there was never a commercial
version from NS* for 0000h.
>Would be very interested in images of os versions and applications
>not already in the archive.
I'll look and see If there are any I have that you don't.
>re: "All of the MDS (SD or DD) based CP/M versions I had"
>- do you have a version of CP/M for the SD controller?
Yes, Lifeboat, V1.4 of cpm. sucky version( 4k bios!). It's been 25
years since I last booted that version. I used it long enough to get
into CP/M on the NS* and used ASM to create new BIOS for the 765
controller under CP/MV2.2.
My MDS-a was a early one I assembled in late '77 so it was SD and
never had a NS* DD controller in it as I went Soft sector before
considering buying that.
>>Did you do the multiuser version of NS*dos?
>
>Another one I've not heard of before - I was unaware that there ever was a
>multi-user version of N* DOS ... More infomation please?
I've seen it never had a copy to use.
>I currently do no have disk and console interrupts implemented on my
>simulator (never saw them used), however I certainly could do so...
Exactly the common case. The hardware was there but rarely if ever
used.
>Thats good - he needs it more than I do right now - I've been working with him
>on and off for a few weeks to try and get his system running, but it's been hard
>to do so remotely - anyone in WI that can help, please step up!
>Once we get him up and running, I'll see if I can get the left over controller
>from him - once nice thing about N* controllers - they are easy to fix!
We can talk later on the incomplete one.
>Will do - I still hope to find a complete Horizon, as I did have and use one
>a lot years ago, and I would like to have one in the collection (see link
>below - I'm a bit weird when it comes to old computers)...
Heavy beast to ship. You haven't seen my collection!
>I too went to a 765 based system, which I used in my D6809 homebuilt -
>lots of photos, documents, source code and a simulator are available on
>my site if you want to check out that one...
I've seen it.
Allison
Moll
Well, I've at least gotten a "core system" though it has no OS as of
yet, I can prolly dig up everything I need...
I am not familiar with ASM outside of the (Apple //e's) 65C02, so I'm
rather lost when it comes to coding a BIOS, which needs to be written in
8080 ASM. :(
I did create a virtual system with a simple monitor (dump memory, write
byte, read raw binary file to address) and port addresses to access the
TTY, DMA for disk access, and drive A: - this is very simplistic.
my pseudocode to set the DTA (sorry, I'm used to MS-DOS terminology lol)
to $0080 would be something like
out 1, 80H
out 2, 00H
simple enough to read a sector: "in" on port 3. it'll return 0 for
success, 1 for warnings, anything else is an error. to write a sector,
"out" on port 3 (no warnings there, but I just wanted to get the
simplest setup running). the A: drive is actually the REAL A: drive, so
has 2880 sectors of 512 bytes.
Last time I tried to put together a system like this, I failed
miserably. :( Hopefully this time it will work. :)
Moll.
Dave Dunfield
>>and would have had access to the interrupt vectors (I loaded my debugger
>>down there to have access to them however!)
> ;-) There was one. I created it by disassembly and relocation.
>Still had a boot to 2000h. However there was never a commercial
>version from NS* for 0000h.
N* has to boot to 2000 - thats hardwired into the controller ROM - even
later "relocatable" versions like 5.2 or INSUA still bring in the boot
sector at 2000 - also, if you are not running at 2000, you can't use
the read routine built into the DC (after booting) because it has hard
wired variables in the 2000 page.
I rolled my own OS, which loaded an application interface block
at 0000-00FF, and the rest in the F000-FFFF block above the
disk controller. This gave me max contiguous memory...
I also implemented an "NSTAR" command, which loaded at 2000
and translated the N* DOS calls to my system - I stored the N* files
with a type of #xx where xx was the northstar type, for example, I
stored N* BASIC as BASIC.#01, which you could run under my
system with ".NSTAR BASIC"
>I'll look and see If there are any I have that you don't.
>>re: "All of the MDS (SD or DD) based CP/M versions I had"
>>- do you have a version of CP/M for the SD controller?
>Yes, Lifeboat, V1.4 of cpm. sucky version( 4k bios!). It's been 25
>years since I last booted that version. I used it long enough to get
>into CP/M on the NS* and used ASM to create new BIOS for the 765
>controller under CP/MV2.2.
I would very much like to get a copy of that disk - if you have a working
NorthStar system (either SD or DD controller), then you could use my
NST program to transfer the image to a file. ... please?
I have a Lifeboat version 1.4, however it is configured for the DD
controller. I don't have any release of N* CP/M that was intended
for the SD controller.
nos...@nouce.bellatlantic.net
Dave.D...@use.techsupport.link.on.my.website (Dave Dunfield)
wrote:
>N* has to boot to 2000 - thats hardwired into the controller ROM - even
>later "relocatable" versions like 5.2 or INSUA still bring in the boot
>sector at 2000 - also, if you are not running at 2000, you can't use
>the read routine built into the DC (after booting) because it has hard
>wired variables in the 2000 page.
Yes. However the boot is a trivial peice of code in PROM, new proms.
Same for the prom that carries the addres decode for the board.
It was experiemental to load NS*dos at 000 and have the controller at
f800h. Gave a bigger useable memory map.
>I rolled my own OS, which loaded an application interface block
>at 0000-00FF, and the rest in the F000-FFFF block above the
>disk controller. This gave me max contiguous memory...
Same game here basically. I did a version of NS* dos as a derivitive
work that used the same directory structure (it's pretty simple). The
IO and the rest of the code was fairly different in layout.
Interesting experiment but, CP/M had something I wanted, the ability
to reuse erased blocks and the ability to have fragmented files.
>>Yes, Lifeboat, V1.4 of cpm. sucky version( 4k bios!). It's been 25
>>years since I last booted that version. I used it long enough to get
>>into CP/M on the NS* and used ASM to create new BIOS for the 765
>>controller under CP/MV2.2.
>
>I would very much like to get a copy of that disk - if you have a working
>NorthStar system (either SD or DD controller), then you could use my
>NST program to transfer the image to a file. ... please?
Currently yes to having working system componenets but, no to having
the SD controller running in it. All systems with floppy are both
soft sector and have 3.5" drives. I did that in the early 90s when I
got tired of a bunch of different size and type medias that didn't
interchange with each other. I'd have to assemble and configure a
working system then add the IO module. The Lifeboat version I have
was not personalized for NS* horizon (or any machine IO) as it was
purchased when I was still using the Altair (early 76). it expected
the standard Sd controller but serial and printer ports were bare.
I'll look into it but it's time consuming to break down the NS* crate
from it's current config and reconfigure with 5.25 and MDS plus
disable the interrupts. Then I can boot NSdos and do all the software
steps. For your emulator it would have to have standard NS* IO added
or it would not communicate at all.
>I have a Lifeboat version 1.4, however it is configured for the DD
>controller. I don't have any release of N* CP/M that was intended
>for the SD controller.
Ah, much later version disk IO. V1.4 is 1.4 otherwise and the only
value to having it for SD controller is to create a bootable image for
that actual hardware. One good reason not to was a NS* 1.4 SD
floppy was only 82k of useable space. It took a three drive system
edit and assemble a basic 765 based bios for CP/M 2.2! Just getting
CP/M-V2.2 into the first system was an exercise as it was a multistage
transfer from 8"SSSD to Eprom (Three 2716s for the CCP and BDOS)
then via an Eprom card to the first cut of a working FDC in NS*
chassis using a specialized console monitor under NSdos. Very
painful process.
I also have a copy of NS* UCSD Pascal for that SD MDS, same problem
that you really needed 4 drives to do useful work. The hardware only
supported three.
For those reading this, MDS single density controller and all
supporting software only supported 3 drives and single sided in
hardware and the boot and supporting NSdos, UCSD pascal and early
Lifeboat CPM assumed only 35 track drives. Enough disk space was
a major issue. The first time I had the soft sector controller
running CP/M 2.2 it was with a SA800, 241k(SSSD 8") of space on one
drive! I could have most of my utilities on the boot disk and still
have space for a small program or three. I also was finally able to
make use of the CP/M standard media (8" SSSD). The next step was
double sided, 80track double density 5.25" nearly 782k of disk space,
luxury. This for CP/M users was one of the primary issues of the
late 70s till about the early 80s, disk space. It would drive the
move to DSQD (80 cylinder double sided double density.) storing
about 800k eventually.
Allison
nos...@nouce.bellatlantic.net
<Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>I am not familiar with ASM outside of the (Apple //e's) 65C02, so I'm
>rather lost when it comes to coding a BIOS, which needs to be written in
>8080 ASM. :(
CP/M was one of the first to do an abstraction from a standard
software interface (the bdos) to a standard hardware interface (the
bios) where the hardware details could be hid behind a conforming
set of calls.
The CP/M Alteration guide has an example BIOS (for the Intel MDS) and
also a skeleton version. The latter has stubs where you need to
provide IO to the host system. You can find the manuals on line and
also a good chance of finding the code examples too. A good place to
check is the Unofficial CP/M archive at Gabys site. It's at:
If you dont find it there let me know as I may have it, maybe.
>I did create a virtual system with a simple monitor (dump memory, write
>byte, read raw binary file to address) and port addresses to access the
>TTY, DMA for disk access, and drive A: - this is very simplistic.
Ah, thats the first step to a bios and basically has the needed parts.
>Last time I tried to put together a system like this, I failed
>miserably. :( Hopefully this time it will work. :)
Reminder that CP/M-80 disk IO is based on a sector of 128bytes and
disk sizes are maxed to 65536*128=8mb. So all disk IO will be
expected to be in 128 byte chunks from and to a logical track and
sector. You can cheat a bit there and make the number of sectors per
track 256 and the number of tracks equal to 256 for a total of 66536-1
sectors. Translation and skew are not needed (unless emulating a
specific hardware).
Hope this helps.
Allison
Moll
> On Wed, 23 Feb 2005 00:50:16 GMT, Moll
> <Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>
>>I am not familiar with ASM outside of the (Apple //e's) 65C02, so I'm
>>rather lost when it comes to coding a BIOS, which needs to be written in
>>8080 ASM. :(
>
> also a skeleton version. The latter has stubs where you need to
> provide IO to the host system. You can find the manuals on line and
> also a good chance of finding the code examples too. A good place to
> check is the Unofficial CP/M archive at Gabys site. It's at:
>
> http://www.cpm.z80.de/
>
> If you dont find it there let me know as I may have it, maybe.
It is that "manual" that I was referring to, actually.
>>I did create a virtual system with a simple monitor (dump memory, write
>>byte, read raw binary file to address) and port addresses to access the
>>TTY, DMA for disk access, and drive A: - this is very simplistic.
>
> Ah, thats the first step to a bios and basically has the needed parts.
>
>>Last time I tried to put together a system like this, I failed
>>miserably. :( Hopefully this time it will work. :)
>
> Reminder that CP/M-80 disk IO is based on a sector of 128bytes and
> disk sizes are maxed to 65536*128=8mb. So all disk IO will be
> expected to be in 128 byte chunks from and to a logical track and
> sector. You can cheat a bit there and make the number of sectors per
> track 256 and the number of tracks equal to 256 for a total of 66536-1
> sectors. Translation and skew are not needed (unless emulating a
> specific hardware).
Which means I may need to use a 512-byte buffer at the top of RAM and
convert between 128-byte records and 512-byte sectors, since I'm
raw-reading a device that uses 512-byte sectors already. The code
already handles sectors as a single track, and translates to CHS as
necessary.
This makes writing the code a LOT more complicated...
The other option would be to do this in the *emulator* (let the BIOS see
128-byte sectors). I'd actually rather keep the C part out of things as
much as possible, and let the "Z80" take care of it, but I can write C
code to split the sector before blitting it into the DTA, much more
easily than leaving it to the CP/M BIOS.
Moll.
Jay Maynard
> The other option would be to do this in the *emulator* (let the BIOS see
> 128-byte sectors). I'd actually rather keep the C part out of things as
> much as possible, and let the "Z80" take care of it, but I can write C
> code to split the sector before blitting it into the DTA, much more
> easily than leaving it to the CP/M BIOS.
The advantage to doing this kind of thing in the emulator rather than the
BIOS is that you're not doing the conversion at the speed of the emulated
CPU, but rather the speed of the host system. This saves a LOT of overhead,
as well as making more memory available for CP/M applications.
If you don't care about emulating specific hardware for your disk
controller, then you can get away with having the select, seek, set sector,
and set DMA routines pass parameters to the emulator, and having read and
write simply use those parameters and drop the data into, or get it out of,
emulated memory directly. This minimizes the coding needed in the BIOS,
where you aren't familiar with the machine, and moves it to more easily
debuggable C.
I'd implement this as having your emulated disk controller occupy one I/O
port, and accept a command and parameters, and provide status and error
responses, over that port. For example, select could be command code 1, with
one byte of parameter (the drive to be selected). This turns the select
routine into (approximately, since I don't have the book open in front of
me):
LD A,1 ;select command code
OUT DISK,A ;send it to the emulator
LD A,C ;get drive to be selected
OUT DISK,A ;select the drive
IN A,DISK ;get the status reply
OR A ;is there a problem?
RET Z ;we're in good shape, go back to BDOS
ERROR: ... ;handle the error, usually by printing a
;message and allowing the user to accept, retry,
;or ignore
The others are similar. The read routine would send the read command to the
emulator, then check status and return if no error, with the data magically
appearing in the buffer set by a previous set DMA call (which the BDOS
guarantees will be issued).
Dave Dunfield
>>NorthStar system (either SD or DD controller), then you could use my
>>NST program to transfer the image to a file. ... please?
>Currently yes to having working system componenets but, no to having
>the SD controller running in it. All systems with floppy are both
>soft sector and have 3.5" drives. I did that in the early 90s when I
>got tired of a bunch of different size and type medias that didn't
>interchange with each other. I'd have to assemble and configure a
>working system then add the IO module. The Lifeboat version I have
>was not personalized for NS* horizon (or any machine IO) as it was
>purchased when I was still using the Altair (early 76). it expected
>the standard Sd controller but serial and printer ports were bare.
>I'll look into it but it's time consuming to break down the NS* crate
>from it's current config and reconfigure with 5.25 and MDS plus
>disable the interrupts. Then I can boot NSdos and do all the software
>steps. For your emulator it would have to have standard NS* IO added
>or it would not communicate at all.
I don't need the disk configured - I'm happy to do that, and it's very
easy with the simulator (handy being able to halt the CPU, have a
full debug "front panel" with the ability to load/save download format
files).
If you can get a version of N* DOS running, then you can very easily
load my client (NST will type it in via the NorthStar Monitor) and
use it to pull off the disk image "as is" - that would be fine for what
I want, as I can customize it to the Horizon I/O later.
I'm in no big rush, but if you could try and do this at some point, it
would be much appreciated.
>>I have a Lifeboat version 1.4, however it is configured for the DD
>>controller. I don't have any release of N* CP/M that was intended
>>for the SD controller.
>Ah, much later version disk IO. V1.4 is 1.4 otherwise and the only
>value to having it for SD controller is to create a bootable image for
>that actual hardware. One good reason not to was a NS* 1.4 SD
>floppy was only 82k of useable space. It took a three drive system
>edit and assemble a basic 765 based bios for CP/M 2.2! Just getting
>CP/M-V2.2 into the first system was an exercise as it was a multistage
>transfer from 8"SSSD to Eprom (Three 2716s for the CCP and BDOS)
>then via an Eprom card to the first cut of a working FDC in NS*
>chassis using a specialized console monitor under NSdos. Very
>painful process.
Agreed that it's not terribly useful - I have two reasons for wanting it:
1) I am trying to build an archive preserving as much N* software as
can be found, and SD CP/M seems relatively rare, and 2) It would
be nice to configure a disk to boot up on my Altair which has the SD
controller, and never had CP/M - I used N* DOS and later my own,
but never had CP/M on that machine - not that I plan to actually use
it much, but it's nice to be able to boot it up and show that it runs.
>I also have a copy of NS* UCSD Pascal for that SD MDS, same problem
>that you really needed 4 drives to do useful work. The hardware only
>supported three.
I would also be interested in images of these disks - same reasons.
nos...@nouce.bellatlantic.net
>It is that "manual" that I was referring to, actually.
Yep, I can assist with the decode as I've done many bios.
>Which means I may need to use a 512-byte buffer at the top of RAM and
>convert between 128-byte records and 512-byte sectors, since I'm
>raw-reading a device that uses 512-byte sectors already. The code
>already handles sectors as a single track, and translates to CHS as
>necessary.
It's called deblocking, there is info and sample code for that too in
the book.
>This makes writing the code a LOT more complicated...
A tiny bit, the part that requires care is that when you read you knly
need to track if the desired sector is in the buffer. When you write
you need to know if the right sector is in the buffer and if after
writing it needs to be flushed back to disk.
>The other option would be to do this in the *emulator* (let the BIOS see
>128-byte sectors). I'd actually rather keep the C part out of things as
>much as possible, and let the "Z80" take care of it, but I can write C
>code to split the sector before blitting it into the DTA, much more
>easily than leaving it to the CP/M BIOS.
Thats an alternate way. From an emulation point of view the
difference is if the emulated disk hardware actually used 128byte
sectors or some larger multiple. Most single density systems
used 128 byte buffers (that came from the IBM single density 8" media)
however most enhanced systems used 256, 512 ot 1024 to get better
storage efficientcy.
Having your emulated disk look like 128 byte sectors makes the bios
very simple and easy to follow. Deblocking is more complicated.
Allison
nos...@nouce.bellatlantic.net
<jmay...@thebrain.conmicro.cx> wrote:
>The advantage to doing this kind of thing in the emulator rather than the
>BIOS is that you're not doing the conversion at the speed of the emulated
>CPU, but rather the speed of the host system. This saves a LOT of overhead,
>as well as making more memory available for CP/M applications.
It does. However, in real systems the advantage was still in favor of
deblocking as the code overhead was easily offset by the reduced
number of reads and writes. The space needed was less than 1k of
code and buffer space.
>I'd implement this as having your emulated disk controller occupy one I/O
>port, and accept a command and parameters, and provide status and error
>responses, over that port. For example, select could be command code 1, with
>one byte of parameter (the drive to be selected). This turns the select
>routine into (approximately, since I don't have the book open in front of
>me):
This is very close the Intel MDS bios IO as their controller was port
oriented.
The alternate is reserve a small part of ram and write a parameter
list there including a dma address and make a system software
interrupt call to x86 code that will read the parameter list do the IO
and return status in the status area of the list having done a pseudo
DMA to the desired spot in emulated cpu memory space. This would be
similar to some of the controllers that looked like an intelligent DMA
device.
Both are valid though the first was more common to real hardware.
there were controllers such as IMS, Compupro and Jade that did a
mixture of both.
Allison
Moll
I'm actually trying to point the disk hardware accesses directly into
the PC BIOS, which is why I wanted to do as little interpretation of the
disk format as possible in the emulator itself. A: really is A:. It's
easier to interpret the disk as a bunch of 512-byte sectors, because in
fact it is exactly that, as far as biosdisk() can tell.
Emulating a decent terminal, at least in the eyes of CP/M software, will
come later, though, letting DOS take care of it is fine. I always keep
ANSI.SYS installed. ~.^ This would at least let me test MBASIC once
CP/M is up; I can copypaste a program into the emulation and run it, and
I have a program that I think used ANSI escape codes (I ran it under
MBASIC-86 in the Lopushinsky emulator). It draws a US flag (which is
how I know it couldn't have been some other terminal emulation). I
think I have some code to process ADM3A terminal escapes...
Moll.
CBFalconer
> Moll <Mollyz...@Spam.BettyKate.Spam.Spam.Spam.Dosius.Com> wrote:
>
>> The other option would be to do this in the *emulator* (let the
>> BIOS see 128-byte sectors). I'd actually rather keep the C part
>> out of things as much as possible, and let the "Z80" take care of
>> it, but I can write C code to split the sector before blitting it
>> into the DTA, much more easily than leaving it to the CP/M BIOS.
>
> The advantage to doing this kind of thing in the emulator rather
> than the BIOS is that you're not doing the conversion at the speed
> of the emulated CPU, but rather the speed of the host system. This
> saves a LOT of overhead, as well as making more memory available
> for CP/M applications.
>
> If you don't care about emulating specific hardware for your disk
> controller, then you can get away with having the select, seek,
> set sector, and set DMA routines pass parameters to the emulator,
> and having read and write simply use those parameters and drop the
> data into, or get it out of, emulated memory directly. This
> minimizes the coding needed in the BIOS, where you aren't familiar
> with the machine, and moves it to more easily debuggable C.
What many people don't realize is that CP/M 2.2 had provisions for
user interception and handling of various errors. The ability was
virtually never used in applications, but my DOSPLUS 2.5 carefully
preserved the hooks, and their locations. I also built some
software to make using these fairly convenient. An excerpt from
the DOSPLUS source code follows, showing the linkage involved and
its relationship to the bdos entry point.
;
; Start of BDOS module
serial: ds 6,0; Serial number not implemented
;
; Linkage for function calls
start: jmp entry; To location 11, for DOSfinders
;
; Error trap vector. Programs can alter error traps here
stbdsc: dw badsec; Bad sector
stsel: dw selerr; Select error
stro: dw rdonly; Drive read only
sfilro: dw filro; File read only
;
; Connector so DOSfinder routines work. The jump at location
; bdos+6 must be to bdos+11h. The above error vector must not
; be moved or programs that trap BDOS errors will fail.
entry: jmp dos
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Peter Smith
> If you used a CP/M system in the past you liked do us all a favor and
> emulate it, especially if it is one not being emulated now.
>
> Right off the top of my head there are emulators for (excluding the MESS
> mess):
>
> Horizon [...]
> RadioShack Model 4 [...]
> SOL-20 [...]
> Soon to come (hopefully):
>
> Cromemco
Randy,
may be you know an Osborne 1 Emulator (CP/M) also ?
Regards
Peter
Randy McLaughlin
news:383ui5F...@individual.net...
None that I am aware of.
Randy
dgr...@cs.csbuak.edu
> I'm planning on building a computer over the summer (on a limited
> budget) and was wondering if it was possible to run CP/M on a modern
> machine. Is this possible, or would special hardware be required?
FWIW, one of my next mad projects might be a Z80 computer, the circuit
board for which can be made from a board-etching kit available from Radio
Shack and some toner transfer paper. The idea is that I distribute only
the foil patterns.
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
Randy McLaughlin
news:605Td.619$ia4.3...@okeanos.csu.net...
Look into small professional board runs, they are cheap and easy. Drilling
a few hundred holes by hand can be a pain.
If you have to drill by hand you are not likely to include a bus.
With a professional board you can go with a Z180 or better yet an F91, it
would be close to impossible to do either of these by drilling the holes by
hand.
Randy
Holger Petersen
>It's called deblocking, there is info and sample code for that too in
>the book.
There was even an errate-sheet for CP/M 2.2 which corrected an error.
IIRC it had to be done in the BIOS...
just remembering old days, Holger
dgr...@cs.csbuak.edu
> Look into small professional board runs, they are cheap and easy. Drilling
> a few hundred holes by hand can be a pain.
PCB Express was quite a nice deal.
> If you have to drill by hand you are not likely to include a bus.
> With a professional board you can go with a Z180 or better yet an F91, it
> would be close to impossible to do either of these by drilling the holes by
> hand.
I know... I know... The idea is to put a foil pattern out there for
people who have no problem with drilling.
Barry Watzman
doing homebrew boards is really pretty horrific for the environment in
terms of the chemicals used that will end up on the ground or in the
public sewers. There are now very, very good short-run pc board houses,
with excellent quality, low prices and features (like plated through
holes or even gold plated edge fingers, if that matters) that you can't
do yourself on a "one-off" basis. You might want to reconsider your plans.
Barry Watzman
full tracks of the floppy were read. Any LSI based controller can read
a single track in a single revolution with zero interleave. You can
achieve hard-disk speeds if you do this right. [The Z-100 had the
benefit of running CP/M in a dual processor system with an 8088 and at
least 192k of memory (to as much as 768k), so it was possible to have
multiple full-track buffers without worrying about the impact on the TPA
size.]
nos...@nouce.bellatlantic.net
<Watzma...@neo.rr.com> wrote:
>In the systems I did for the Z-100, I used full-track buffering; only
>full tracks of the floppy were read. Any LSI based controller can read
>a single track in a single revolution with zero interleave. You can
>achieve hard-disk speeds if you do this right. [The Z-100 had the
>benefit of running CP/M in a dual processor system with an 8088 and at
>least 192k of memory (to as much as 768k), so it was possible to have
>multiple full-track buffers without worrying about the impact on the TPA
>size.]
Z100 was a good design.
I've done same with Z80, the difference was the track buffer was in
mapped memory with a mmu to allow access to it. Performance was
very good. The trick to making it happen was a controller that could
DMA to anywhere in linear memory (Compupro and IMS are two I have
that can do that). However, rather than a commercial controller I'd
used a design of my own. It did make it much easier to treat the
disk as contigious addressable sectors.
But that goes way beyond what the initial question was.
Allison
nos...@nouce.bellatlantic.net
>PCB Express was quite a nice deal.
It is and good qc.
>I know... I know... The idea is to put a foil pattern out there for
>people who have no problem with drilling.
I've done that back when and it wasnt fun, as it's really
easy to break those small bits. Also single sided means
jumpers, lot of them. It's also hard to get a good power
gridding with single sided or double sided without through
holes.
A real find would be a 2 or more layer through hole board
that takes a Z80, 32k sram and 24/28 pin Eprom/eeprom
with a buffered bus. The only logic is buffering and that
needed to map in the rom to 000h for boot and on software
command. With a buffered bus, IO is now the user project
and can have such ususal things for a CP/M system as SIO
and FDC or some flash media. or go totally unusual. Just
about every Z80 based system I've done had that part as
a stock design starting point.
Allison
s_dub...@yahoo.com
It is humorous to me that I recognized the above code structure because
I was just going thru the loader bdos code for MP/M-86, from the file
on Gaby's site - mpm862sr.zip, this is what is in LDBDOSENT.A86 ->
"
;******************** BDOS entry module ********************
;
; Perform branching, error handling and special
; 8086 stuff.
;
;
cseg cpmsegment
org bdosoffset
;
db 0,0,0,0,0,0
;
; enter here from the user's program with function number in cl,
; and information address in dx
;
JMP bdose ;past parameter block
;
; ************************************************
; *** relative locations 0009 - 000e ***
; ************************************************
pererr dw persub ;permanent error subroutine
seler dw selsub ;select error subroutine
roderr dw rodsub ;ro disk error subroutine
rofer dw rofsub ;ro file error subroutine
;
;
bdose: ;arrive here from user progs
mov axsave,ax ;switch stack segment
mov SS_save,ss
mov SP_save,sp
.....
"
The MP/M-86 & CCP/M-86 style bootstrap loader is a condensed version of
the full OS, setting up int 224 even before loading the full .SYS file.
This is different than the IBM PC CP/M-86 class loaders, in which int
224 setup is postponed till the init: routine in the IBM PC CP/M-86 SYS
file. The IBM PC CP/M-86 differs in the placement of the above
vectors. Instead of being inline with the code, as above, the vectors
are in the congregated data area.
Perhaps you folks can clarify for me, was MP/M-86 released first for
the Compupro S-100 before even the IBM PC came to market? Was MP/M-86
ever released for the IBM PC?
Randy once asked if anyone had found the original source to the CP/M-86
CCP or BDOS, but got no reply that I know of. Well, the above code
snippet compares closely between the cp/m-80 bdos and the mp/m-86
loader bdos [which itself is a close subset of the full mp/m-86 bdos].
I wonder if, as an early development step, the 8080 code was run thru
an 8080 to 8086 translator and then modified by hand. What I did do
was run the cp/m-80 CCP thru XLT-86 to get an 8086 version. This 8086
XLT version of the CCP compares very closely with the IBM PC cp/m-86
CCP, even including the S/N check between the CCP S/N and the BDOS S/N,
and the similar routines are the same relative ordering. It is hard to
draw the same conclusion about the BDOS however, because the address
modes of the x86 would require alot more hand modification of the XLT
translated 8080 coding.
The file LDMPM.A86 in the above zip claims:
"
title 'MP /M-86 Loader'
; The MPMLDR consists of this module along with the
; LDBDOS and LDBIOS. The LDBDOS is the same as for
; for CP/M-86, and the LDBIOS has only the login message
; changed.
"
If the LDBDOS is a subset of the full BDOS, then here is a good portion
of the BDOS source for CP/M-86 as well.
Also, this style of bootstrap loader would be for CP/M-86 as well,
_other_than_the_IBM-PC_CP/M-86_.
I would need someone with an S-100 version of CP/M-86 to confirm this,
if anyone gets around to it.
Steve
Lee Hart
> You can't do plated through holes on a homebrew board.
True; but you can solder component leads top and bottom. Or, insert
pieces of wire or eyelets, and solder them in.
Or, I just noticed Electronic Goldmine www.goldmine-elec.com is selling
loose socket pins at 20 for $1. They press into a 0.037" hole on a PC
board and make that hole become an IC socket 9and incidentally connect
the top and bottom traces like a plate-thru hole).
> Also, fwiw, doing homebrew boards is really pretty horrific for
> the environment in terms of the chemicals used that will end up
> on the ground or in the public sewers.
It's not *that* bad! Ferric chloride is relatively nontoxic (but stains
horribly), and a little will etch a lot of boards. I see making your own
PC boards as kind of like developing your own film. It's fun,
interesting, and educational.
But as you say, you can buy better boards from the short-run PCB houses
than you can make yourself.
--
"Never doubt that the work of a small group of thoughtful, committed
citizens can change the world. Indeed, it's the only thing that ever
has!" -- Margaret Mead
--
Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net
Lee Hart
> A real find would be a 2 or more layer through hole board
> that takes a Z80, 32k sram and 24/28 pin Eprom/eeprom
> with a buffered bus. The only logic is buffering and that
> needed to map in the rom to 000h for boot and on software
> command. With a buffered bus, IO is now the user project
> and can have such ususal things for a CP/M system as SIO
> and FDC or some flash media. or go totally unusual. Just
> about every Z80 based system I've done had that part as
> a stock design starting point.
I have my "Databug" boards, discussed on this forum a year or so ago. It
is a 6.25" x 2.5" PC board with a Z80, two bytewide memory sockets,
logic to address up to 1 megabyte of memory, two serial ports, one
parallel port, 3-channel A/D converter, real-time clock, and switching
power supply. It's a very inexpensive design, using only thru-hole
generic parts. I'd be happy to sell a bare board or parts kit if anyone
is interested.
Lee Hart
>
> Randy McLaughlin <ra...@nospam.com> wrote:
>
> > Look into small professional board runs, they are cheap and easy. Drilling
> > a few hundred holes by hand can be a pain.
>
> PCB Express was quite a nice deal.
>
> > If you have to drill by hand you are not likely to include a bus.
>
> > With a professional board you can go with a Z180 or better yet an F91, it
> > would be close to impossible to do either of these by drilling the holes by
> > hand.
>
> I know... I know... The idea is to put a foil pattern out there for
> people who have no problem with drilling.
There is an even easier way if you want to make your own board for a
really simple Z80 system.
About 10 years ago I designed a *very* simple Z80 single board computer.
It has the Z80, a RAM, an EPROM, a 74HC132, and a few discrete resistors
and capacitors. That's it! It had 1 bit input and 1 bit output for
bit-banger serial I/O.
The PC board was SINGLE sided, and the spacings were very large. No
traces ran between pads, for example. This was so I could etch it myself
with very simple equipment.
The chips were soldered directly to the foil side of the board,
surface-mount style. No holes to drill!
It was done in this quick-and-dirty style so I could build half a dozen
in time to give them as Christmas presents. I programmed them to play
Christmas music to a speaker connected to the serial output. It was a
fun project that friends still remember fondly.
nos...@nouce.bellatlantic.net
wrote:
>I have my "Databug" boards, discussed on this forum a year or so ago. It
>is a 6.25" x 2.5" PC board with a Z80, two bytewide memory sockets,
>logic to address up to 1 megabyte of memory, two serial ports, one
>parallel port, 3-channel A/D converter, real-time clock, and switching
>power supply. It's a very inexpensive design, using only thru-hole
>generic parts. I'd be happy to sell a bare board or parts kit if anyone
>is interested.
I'm curious, I'd like to know more. Email at kb1gmx at arrl dot net.
It still has stuff I'm not interested like A/D but thats minor.
Allison
Barry Watzman
"Compupro" product, nor was there, FROM DR'S PERSPECTIVE, a "Compupro"
version. The target hardware for the generic product was, as always, an
Intel development system. Compupro did their own customization for the
Compupro hardware, as I did the customization (including the
implmentation of dual processors and the ability to run 8-bit CP/M-80
programs) for the Zenith Z-100.
It was never released for the IBM-PC as far as I know, although
"Concurrent" was.
I don't remember the exact timeline for MP/M-86, but I'm pretty sure
that it didn't arrive until at least 1982, which was subsequent to the
IBM-PC.
nos...@nouce.bellatlantic.net
>Perhaps you folks can clarify for me, was MP/M-86 released first for
>the Compupro S-100 before even the IBM PC came to market? Was MP/M-86
>ever released for the IBM PC?
CP/M-86 preceeded the IBM pc just barely. MPM-86 was later.
I believe that MPM-86 was implemted on non-pc hardware before it
was made available on the PC.
Allison
Randy McLaughlin
news:sqkq11hd53bf27b6j...@4ax.com...
I never heard of MP/M-86 on a PC, I have several versions including the
source for my CompuPro. Concurrent CP/M (a MP/M-86 derivative) was
available on both PC & non-PC systems.
Randy
www.s100-manuals.com
Randy McLaughlin
news:421D53E5...@neo.rr.com...
> MP/M-86 was a generic product. It was not, from DR's perspective, a
> "Compupro" product, nor was there, FROM DR'S PERSPECTIVE, a "Compupro"
> version. The target hardware for the generic product was, as always, an
> Intel development system. Compupro did their own customization for the
> Compupro hardware, as I did the customization (including the implmentation
> of dual processors and the ability to run 8-bit CP/M-80 programs) for the
> Zenith Z-100.
>
> It was never released for the IBM-PC as far as I know, although
> "Concurrent" was.
>
> I don't remember the exact timeline for MP/M-86, but I'm pretty sure that
> it didn't arrive until at least 1982, which was subsequent to the IBM-PC.
MP/M-86 was developed on CompuPro's (and a VAX for cross compiling PLM-86
code). I have many of the original MP/M-86 developement disks, even some
intermediate disks where just small pieces of code were being fine-tuned.
Some of the disks I have use pre-printed labels many though are hand
written, even a few hand written notes from the employees.
DR worked with Gifford & CompuPro to fine tune the details of MP/M-86.
Randy
www.s100-manuals.com
Randy McLaughlin
news:HxcTd.15148$hd6....@bignews1.bellsouth.net...
I forgot to mention that Concurrent CP/M was also developed on CompuPro's as
well as PC's at the same time. The DRI Concurrent CP/M source disks include
XIOS's for both systems.
Randy
www.s100-manuals.com
Barry Watzman
PC by Digital Research. I did the MP/M-86 implementation for the Z-100
in 1983, I beleive that it was actually shipping in 1982.
Barry Watzman
hardware was an Intel SBC 204, and the copyright date (which I'm sure
represents development work, not final shipping product) is 1980. DR
probably did work with Gifford and CompuPro on customization, but I
still maintain that the CompuPro version was preceeded by a generic
version on Intel hardware.
Randy McLaughlin
>I just checked my original 8" distribution disks from DR. The target
>hardware was an Intel SBC 204, and the copyright date (which I'm sure
>represents development work, not final shipping product) is 1980. DR
>probably did work with Gifford and CompuPro on customization, but I still
>maintain that the CompuPro version was preceeded by a generic version on
>Intel hardware.
The disks I have are v2.0 & v2.1, I'll have to check the dates.
Many of the loose disks I have are where the v2.0 is being upgraded into
v2.1, 100% of that was on the CompuPro (with cross compilation on a VAX).
One half of the source distribution were compiled with the VAX PLM-86 cross
compiler the other half were assembled on the native 8086 DRI assembler.
The first version of MP/M-86 may have been created on a multi-bus system but
not after that. DRI used CompuPro's in house. I have original boot disks
from DRI employees specifying who it was for and what hardware was in their
computers.
Randy
www.s100-manuals.com
CBFalconer
Barry Watzman wrote:
> Randy McLaughlin wrote:
>> "Barry Watzman" <Watzma...@neo.rr.com> wrote in message
>>
>>> a "Compupro" product, nor was there, FROM DR'S PERSPECTIVE, a
>>> "Compupro" version. The target hardware for the generic product
>>> was, as always, an Intel development system. Compupro did their
>>> own customization for the Compupro hardware, as I did the
>>> customization (including the implmentation of dual processors and
>>> the ability to run 8-bit CP/M-80 programs) for the Zenith Z-100.
>>>
>>> It was never released for the IBM-PC as far as I know, although
>>> "Concurrent" was.
>>>
>>> I don't remember the exact timeline for MP/M-86, but I'm pretty
>>> sure that it didn't arrive until at least 1982, which was
>>> subsequent to the IBM-PC.
>>
>> <snip>
>>
>> MP/M-86 was developed on CompuPro's (and a VAX for cross compiling
>> PLM-86 code). I have many of the original MP/M-86 developement
>> disks, even some intermediate disks where just small pieces of
>> code were being fine-tuned. Some of the disks I have use
>> pre-printed labels many though are hand written, even a few hand
>> written notes from the employees.
>>
>> DR worked with Gifford & CompuPro to fine tune the details of
>> MP/M-86.
>
> target hardware was an Intel SBC 204, and the copyright date (which
> I'm sure represents development work, not final shipping product)
> is 1980. DR probably did work with Gifford and CompuPro on
> customization, but I still maintain that the CompuPro version was
> preceeded by a generic version on Intel hardware.
The Compupro bios may well have been proprietary to Compupro, and
should not have affected the work on the fundamental system apart
from testing portability. We had a Compupro boat anchor system
using the blindingly fast 10 MHz 8086 and monstrous 5 or 10 Meg
drives.
Please don't toppost.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Robert J. Stevens
Randy;
I have a Compu-Pro with a Q540 HD.
I am looking for the Loader that will allow the HD to boot directly.
I have a Disk1A and a Disk3 in the box.
I didn't get the Install Floppies for the CCP/M-86 that I have on the A:
drive of the Q540.
Can you supply
Bob in Wisconsin
nos...@nouce.bellatlantic.net
<Watzma...@neo.rr.com> wrote:
>I don't think that MP/M-86 was ever released by DR "ready to run" on the
>PC by Digital Research. I did the MP/M-86 implementation for the Z-100
>in 1983, I beleive that it was actually shipping in 1982.
Your right DRI never supplied it for the PC. That didn't mean a
generic version could not be installed on a PC with Xios to bios
code. The last place I was at had one that way, shame the xios
sources were badly munged. I'd have liked to capture that one.
Whats forgotten is in the early to mid '80s (post PC introduction)
is that PC-dos was available to port to non-pc hardware. Along with
a lot of other stuff already on non PC hardware being moved to
existing and often far more powerful S100 and multibus hardware.
I was frequently amazed that in '85 people would buy a 4.77mhz PC
or maybe an 8mhz clone when there were non-PC machines running
8086 (not the narrow bus 8088 that was slower for the same clock)
at 12mhz with larger and faster disks.
There was a lot of I want what they have, only put it on my PC.
Allison
Barry Watzman
The bottom line here is that if you have Compupro disks, you can't rely
on version numbers, copyright dates, etc., because they may represent
Compupro work rather than DR work.
Indeed, Compupro could even have obtained sources from DR and
recompiled. What I have is pure DR generic stuff.
Randy McLaughlin
> Ah, but is that "DR version {whatever}" or "COMPUPRO version {whatever}"?
>
> The bottom line here is that if you have Compupro disks, you can't rely
> on version numbers, copyright dates, etc., because they may represent
> Compupro work rather than DR work.
>
> Indeed, Compupro could even have obtained sources from DR and
> recompiled. What I have is pure DR generic stuff.
I have DRI disks obtained from an ex-DRI employee.
CompuPro took the results and created products like MP/M-816.
DRI and CompuPro worked together for mutual gain. The CompuPro hardware was
much better than anyone else's and CompuPro had better marketing.
As I said I have original DRI labels on many disks including Concurrent CP/M
on 5.25" DD disks intended for PC development yet they also have the
CompuPro XIOS included. I have never even heard of Concurrent CP/M running
on a multi-bus system. To me this infers DRI was happy with the CompuPro
hardware. For development the CompuPro is so much faster than either
multi-bus or PC.
Randy
www.s100-manuals.com
s_dub...@yahoo.com
I came late to the party, and I missed the [software] introductions ;)
After all, didn't Seattle Computer use a S-100 system with an 8086 card
to translate cp/m-80 into qdos? And they got their hands on one of the
first 8086 S-100 cards?
At that time there was only cp/m-80 and mp/m-80 and cp/net-80, I take
it. So cp/m-86 and mp/m-86 are ports from the 8080 versions as the
8086 cpu cards came available which was still prior to the IBM PC
introduction?
I don't take for granted that cp/m-86 was developed before mp/m-86, so
I ask for recollections. It could be that the mp/m port was started
first to target the expanded addressing and potential memory of the
x86, hence the 1980 copyright date on mp/m-86 loader.
Steve
s_dub...@yahoo.com
It would be great if you could make all that stuff available, even the
seemingly redundant and fragmented stuff. For instance, the
mpm862sr.zip has the source for LDBDOS which is only supplied as an
.H86 file in other sources. mpm862sr.zip seems complete yet it lacks
the linkage editor, GENSYS to combine the modules. However there is a
GENSYS in mpm86-21.zip. Computer Innovations C86 is required to build
the genccpm.c from ccpm8620.zip, but it is not included, nor is
genccpm.cmd. There is a version of Computer Innovations C86 included
in the DRI sources tree from Gene Buckle's site however. Reading the
comments from ccpm8620's genccpm.c ->
"
* G E N C C P M - generates an operating system
*
* Written by Bill Fitler Nov. 1982
*
* GENCCPM is designed to edit the system image for the operating
system
* and construct an initialized, loadable image for execution.
* GENCCPM was originally designed for Concurrent CP/M-86 v2.0, and was
* modelled after the old GENSYS.
*
"
gives the note that this is a successor to the old GENSYS.
etc..you get the idea, something you have may open new doors.
Steve
Randy McLaughlin
news:1109291494.9...@o13g2000cwo.googlegroups.com...
<snip>
> It would be great if you could make all that stuff available, even the
> seemingly redundant and fragmented stuff. For instance, the
> mpm862sr.zip has the source for LDBDOS which is only supplied as an
> .H86 file in other sources. mpm862sr.zip seems complete yet it lacks
> the linkage editor, GENSYS to combine the modules. However there is a
> GENSYS in mpm86-21.zip. Computer Innovations C86 is required to build
> the genccpm.c from ccpm8620.zip, but it is not included, nor is
> genccpm.cmd. There is a version of Computer Innovations C86 included
> in the DRI sources tree from Gene Buckle's site however. Reading the
> comments from ccpm8620's genccpm.c ->
> "
> * G E N C C P M - generates an operating system
> *
> * Written by Bill Fitler Nov. 1982
> *
> * GENCCPM is designed to edit the system image for the operating
> system
> * and construct an initialized, loadable image for execution.
> * GENCCPM was originally designed for Concurrent CP/M-86 v2.0, and was
> * modelled after the old GENSYS.
> *
> "
> gives the note that this is a successor to the old GENSYS.
>
> etc..you get the idea, something you have may open new doors.
>
> Steve
Quite some time ago I sent the full disk packages to Gaby, she has posted
them. I'll see about doing the same with everything else. I'll include
scans of the hand written disk labels and any other notes.
Randy
Randy McLaughlin
news:1109289106.1...@f14g2000cwb.googlegroups.com...
Quite often the Copyright dates refer to pieces of code written before the
total package was even envisioned.
Randy
www.s100-manuals.com
Hans Bus
<snip>
> Maybe other can chime in and expand the list, please note I am not listing
> the variety of generic CP/M emulators (MyZ80 etc).
>
>
> Randy
> www.s100-manuals.com
>
>
Philips P2000 (although it did NOT originally run CP/M)
Uses micro cassettes i.s.o. floppies, and ROM cartridges
for BASIC and other programs
Versions for Unix, Linux and DOS.
(Windows version under test)
Written by Marc de Kogel.
Regards,
Hans Bus
Wild Bill
That was because that was how IBM wanted it.
DRI attempted to sell MP/M-86 to the people from IBM
Stories that, to the contrary, it was CP/M-86 that DRI
tried to sel that fateful day of the alleged 'flying' incident
are false. DRI pitched MP/M-86.
IBM wanted none of it, because it too directly conflicted
with their mini-computer business offerings (at far
higher prices, and far higher profits). According to
Bill Sigmond, limiting functionality was pretty much
the only reason for using the 8088 instead of the 8086.
Sigmond, for those who don't know, was one of the
team of 13 who came up with the PC in Boca Raton.
Having decided they couldn't afford to take the risk
of doing business with DRI (who was intent on
building products that were more than IBM wanted
for it's personal computer division) they then arranged
or conspired with ms to supply a much more limited
functionality, and barely useful, OS.
86-DOS, prior to msDOS, supported hard drives
and partitions to maybe a gigabyte. msDOS didn't.
Many (ignorant) people continue to refer to some
Q-DOS. Maybe they mean Queer-DOS. It may
be that Seattle Computer and IBM 'queered' the
86-DOS product to make it more acceptable to IBM.
Bill
s_dub...@yahoo.com
My misunderstanding then. So 86-DOS was the product SCP offered for
the 8086 on the S-100 buss. Did it use the FAT or FCB's? Did the
ibm/microsoft Dos V.1.0 use the FAT or FCB's?
Thxs, Steve.
Moll
> My misunderstanding then. So 86-DOS was the product SCP offered for
> the 8086 on the S-100 buss. Did it use the FAT or FCB's? Did the
> ibm/microsoft Dos V.1.0 use the FAT or FCB's?
>
> Thxs, Steve.
>
At least IBM DOS 1.1 and MS-DOS 1.25 used FAT internally and FCBs
externally.
Moll.
CBFalconer
> Wild Bill wrote:
>
... snip ...
>>
>> 86-DOS, prior to msDOS, supported hard drives
>> and partitions to maybe a gigabyte. msDOS didn't.
>>
>> Many (ignorant) people continue to refer to some
>> Q-DOS. Maybe they mean Queer-DOS. It may
>> be that Seattle Computer and IBM 'queered' the
>> 86-DOS product to make it more acceptable to IBM.
>
> for the 8086 on the S-100 buss. Did it use the FAT or FCB's?
> Did the ibm/microsoft Dos V.1.0 use the FAT or FCB's?
The FAT is just a different way of keeping track of disk space.
Early MsDos used FAT and FCBs. In fact, it misused FCBs, since it
could no longer keep track of the name of an erased file, nor have
sparse files, both of which the CP/M file system could handle. Nor
could MsDos protect against disk media changes with open files.
The later MsDos 2 file system brought directories and file handles
in place of FCBs. The handles meant an end to unrestricted file
open counts, and thus weird failures requiring file closures.
At any rate, don't confuse the purpose of the FAT with the use of
FCBs.
Anonymous Guy
On 2005-03-31 Wild Bill <bi...@sunsouthwest.com> said:
If we could just quickly recap here, Wild Bill:
About DOS:
We know that 86-DOS existed, because Seattle Computer Products
advertised and sold it (in several different version numbers)
for use on its 'Gazelle' computer system. This is documented
fact; easily proved, and beyond dispute.
You're saying that the 16-bit O.S. which Gates optioned from
Seattle Computer Products -was- 86-DOS -- but because it was
too sophisticated, and could present a possible threat to IBM's
mainframe business, it was 'dumbed down' for presentation to
IBM as a possible O.S. for the new IBM PC.
If it's true that 86-DOS had these sophisticated abilities, then
this should be relatively easy to verify; either by looking at the
original 1981 descriptive literature for 86-DOS, or by examining
the original 86-DOS binaries.
Could you please point me to where I can find the original 86-DOS
literature or binaries? I'd like to have a first-hand look at'em.
About MP/M-86:
We know that IBM reps came to DRI for the purpose of potentially
negotiating a licensing agreement to use a DRI O.S. on the IBM PC.
This is documented fact; easily proved, and beyond dispute.
Of the persons who were personally present at that meeting, and
who've made public statements about it, all of them have stated
that CP/M-86 was the object of the negotiation.
If you have evidence that this information is incorrect, I'd be
most grateful if you would either post it here, or provide a web
link where the evidence can be examined.
Many thanks.
Robert J. Stevens
Anonymous Guy wrote:
> snipped
> We know that 86-DOS existed, because Seattle Computer Products
> advertised and sold it (in several different version numbers)
> for use on its 'Gazelle' computer system. This is documented
> fact; easily proved, and beyond dispute.
>
> You're saying that the 16-bit O.S. which Gates optioned from
> Seattle Computer Products -was- 86-DOS -- but because it was
> too sophisticated, and could present a possible threat to IBM's
> mainframe business, it was 'dumbed down' for presentation to
> IBM as a possible O.S. for the new IBM PC.
>
> If it's true that 86-DOS had these sophisticated abilities, then
> this should be relatively easy to verify; either by looking at the
> original 1981 descriptive literature for 86-DOS, or by examining
> the original 86-DOS binaries.
>
> Could you please point me to where I can find the original 86-DOS
> literature or binaries? I'd like to have a first-hand look at'em.
I have a set of the Seattle Computer Disk's
SCP 86 DOS Cromemco format
MS DOS v2.0 Disk 1 & 2
I can make copies for anyone interested but you'll need to send me three
SSSD IBM 3740 formated floppies.
I am also in contact wiith a fellow who is trying to get his GAZELLE to
run.
Bob in Wisconsin
Robert J. Stevens
N89 W15687 Cleveland Ave
Menomonee Falls, WI 53051
United States
nos...@nouce.bellatlantic.net
<m...@privacy.net> wrote:
>
>If we could just quickly recap here, Wild Bill:
>
>About DOS:
>
>We know that 86-DOS existed, because Seattle Computer Products
>advertised and sold it (in several different version numbers)
>for use on its 'Gazelle' computer system. This is documented
>fact; easily proved, and beyond dispute.
The first versions were CP/M 1.4 lofted to 8086 instruction set.
it was ttles Quickdos (qdos) because it was quickly produced.
From what I've found it predated CP/M-86 as SCP needed a 16bit
OS that ran on the '86. As a result that was not a better OS then
even CP/M2.2.
CP/M86 was a market response.
pc dos 1.0 was Qdos (with incidental DRI copyright code).
MPM-86 was later, after MPM-80.
All thats needed to follow this is byte and kilobaud for the years
1979 through 83. Since most of the ads and press releases
fall in that region.
Allison
Anonymous Guy
On 2005-04-01 Bob S. said:
> I have a set of the Seattle Computer Disk's
> SCP 86 DOS Cromemco format
> ...
> I can make copies for anyone interested but you'll need to
> send me three SSSD IBM 3740 formated floppies.
>
> I am also in contact wiith a fellow who is trying to get his
> GAZELLE to run.
Bob, would it be possible for you to make a disk image of
the SCP 86-DOS disks, using RAWREAD or some other disk-
imaging utility?
Anonymous Guy
On 2005-04-01 Allison P <nos...@nouce.bellatlantic.net> said:
> The first versions were CP/M 1.4 lofted to 8086 instruction set.
> it was ttles Quickdos (qdos) because it was quickly produced.
>
> From what I've found it predated CP/M-86 as SCP needed a 16bit
> OS that ran on the '86. As a result that was not a better OS then
> even CP/M2.2.
>
> CP/M86 was a market response.
>
> pc dos 1.0 was Qdos (with incidental DRI copyright code).
>
> MPM-86 was later, after MPM-80.
>
> All thats needed to follow this is byte and kilobaud for the years
> 1979 through 83. Since most of the ads and press releases
> fall in that region.
>
> Allison
Yes; you've just outlined the conventional thinking on the subject.
However, Wild Bill has always maintained that the term 'Q-DOS' is
a fake; a fraud; a red herring that was cooked up after the fact
for nefarious, conspiratorial reasons.
You must admit, none of the ads or press releases in your 1979 to
1983 'Byte' and 'Kilobaud' magazines ever mention 'Q-DOS.'
The term appears in a few -articles,- but only after the release of
IBM PC-DOS.
In his latest message, Wild Bill alleges that 86-DOS was much MORE
than a quick-and-dirty 16-bit port of CP/M. He says:
WB> 86-DOS, prior to msDOS, supported hard drives
WB> and partitions to maybe a gigabyte. msDOS didn't.
Wild Bill claims that 86-DOS was 'dumbed down,' so that it -- and
the IBM PC -- wouldn't appear as a threat to IBM's mainframe busi-
ness.
It's well-known, and historically verifiable, that after Gates
bought the option on 86-DOS, he then hired Tim Paterson (the nominal
'author' of 86-DOS, who was working for Seattle Computer Products
at the time).
Paterson went to work at Mikro$loth ostensibly for the purpose of
'polishing up' the O.S. for presentation to IBM. Paterson was at
M$ for at least 8 months; maybe longer.
So here are the fundamental questions:
Is Wild Bill onto something? Was there a conspiracy to hold back
technology for self-serving corporate financial reasons?
Did the original 86-DOS contain capabilities and functions that were
deliberately left out of IBM PC-DOS?
Was the term 'Q-DOS' invented after the fact...possibly to distinguish
the dumbed-down 'polished' product that eventually became PC-DOS
from its much more capable progenitor, 86-DOS?
Or,
Is the conventional thinking correct, and Wild Bill merely a wacko
'conspiracy theory' nut-job, who should be put into a rubber room
and force-fed psychotropic medication?
We report. You decide.
Barry Watzman
crock.
None of these OS' either do or don't. The physical implemlentation is
in the BIOS, which is completely customizeable in both CP/M-86 and
MS-DOS / 86-DOS / Q-DOS.
The only support, and the only limitiations, are in the file system.
CP/M at the time supported, I believe, up to 8 megabyte drives. MS-DOS
(whatever you want to call it) started out with FAT-12, then later with
version 2.0 went to FAT-32.
Quarter of a gigabyte drives in 1981? You've got to be kidding. The
biggest hard drives reasonably available for PCs (e.g. 5.25" form
factor) was 10 MEGABYTES. The $15,000 CDC Hawk, the size of a
refrigerator, was, I think, 10 fixed and 10 removeable. No one was
thinking gigabytes. Mainframes didn't have gigabytes.
By the way, at the time I was the Product Line Director for Heathkit and
Zenith Data Systems and I knew both Gary Kildall and Bill Gates
personally. And I had -- and still have -- every version of 86-DOS from
0.33 on to MS-DOS 2.0. Supplied by Seattle Computer Products, on 8"
diskettes, for an S-100 system (the SCP board set used in the "Gazelle"
with a Tarbell double density disk controller). And while I was not
present at or privy to the IBM negotiations (although I did discuss them
with the principles "after the fact" -- more than a year later), I think
that the idea that the main "pitch" was for MP/M-86 is hogwash. MP/M-86
may have been suggested as a future possibility, but I'm satisfied that
the main discussion was about CP/M-86.
Roger Ivie
> Quarter of a gigabyte drives in 1981? You've got to be kidding. The
> biggest hard drives reasonably available for PCs (e.g. 5.25" form
> factor) was 10 MEGABYTES. The $15,000 CDC Hawk, the size of a
> refrigerator, was, I think, 10 fixed and 10 removeable. No one was
> thinking gigabytes. Mainframes didn't have gigabytes.
Starting Jan '84, I had a VAX-11/780 all to myself with a 1G of disk
composed of four RM05 disk pack drives. I'm not certain precisely when
the RM05 happened, but I'm pretty sure it was well before '84.
Ah; a /780 all to myself. Those were the days...
--
Roger Ivie
ri...@ridgenet.net
http://anachronda.webhop.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------
Jay Maynard
correcting:
On 2005-04-02, Barry Watzman <Watzma...@neo.rr.com> wrote:
> No one was thinking gigabytes. Mainframes didn't have gigabytes.
They did, just not in one drive yat. The IBM 3350, introduced in 1976, had a
little over 300 MB per spindle, and you could string 8 drives on one
controller. The small shop I started doing systems work on in 1981 had 20 of
them, or 6 GB of storage.
The 3380, introduced in 1981, had 1.2 GB per volume (two volumes on a
spindle). Those didn't become common for a few years after that.
Robert J. Stevens
NOPE;
The only machine I have that will see the Disks is My CompuPro. But
maybe someone else on the list can. I can send them copies if you send
me three SSSD 8"errs
Bob
nos...@nouce.bellatlantic.net
wrote:
>Starting Jan '84, I had a VAX-11/780 all to myself with a 1G of disk
>composed of four RM05 disk pack drives. I'm not certain precisely when
>the RM05 happened, but I'm pretty sure it was well before '84.
In '82 the largest drive was in the 200mb region, cost about 50,000
dollars and the size of a washing machine. RM05s were 1983 and
were being phased out by '86 in favor of the RA-8x series.
The largest drive in the 8" or 5.25" formats were in the 30mb range.
though if you wanted a less than 1000$ disk system in 1981 it was
going to be 5mb.
There is a fair amount of time compression and confusion from about
1975 to 1985 events. Some of it is also misreporting on the various
sites.
Allison
Jay Maynard
> In '82 the largest drive was in the 200mb region, cost about 50,000
> dollars and the size of a washing machine. RM05s were 1983 and
> were being phased out by '86 in favor of the RA-8x series.
It took DEC that long? The IBM 3350 was washing-machine sized, 300 MB, and,
according to IBM's web site, as released in 1976. The IBM 3380 was released
in 1980 (not 1981, as I posted last night). Surely other manufacturers
weren't that slow to keep up...
nos...@nouce.bellatlantic.net
<jmay...@thebrain.conmicro.cx> wrote:
>
>It took DEC that long? The IBM 3350 was washing-machine sized, 300 MB, and,
>according to IBM's web site, as released in 1976. The IBM 3380 was released
>in 1980 (not 1981, as I posted last night). Surely other manufacturers
>weren't that slow to keep up...
I may be off by a year. However it depends on what the disk was
interfaced to. Also DEC didn't develop all their drives, early on
they were dependent on others. The RM05 was a non dec and
I think it came from CDC though. Some on the system interfaces werent
even DEC. So there was a dely from when the technology existed and
when companies like DEC inplemented it and had software support in
the OS.
I'd add the first real disk farm I'd seen was at DEC and it was
something larger than 300gb in 1986. By 1991 the term terabyte was
being used and not in the future tense.
Allison
Richard Brady
Given IBMs consisent unwillingness to compete against itself (See Big
Blues : The unmaking of IBM by Paul Carroll) Wild Bill's position makes
absolute sense. Similar to GM and the Banshee.
Richard
Randy McLaughlin
news:P1F3e.505975$w62....@bgtnsc05-news.ops.worldnet.att.net...
I hate not snipping such a long post but the truth is simple:
The PC especially the first PC was extremely dumbed down, that is a fact.
That said had CP/M-86 been ready they probably would have gone that route
then maybe onto MP/M-86. 86-DOS was based on Copyright infringement (double
speak for theft) but IBM was told "It's ready" so they closed their eyes and
followed Willy boy.
MP/M-86 came later and was never a question of IBM decision making. There
was by that time problems between DRI & IBM plus MP/M-86 is happier with
better hardware than a brain dead 8088. CompuPro was a much better example
of a better 8088 implementation. Anyone that has worked with a 20mb drive
on a Disk 2 running MP/M-816 (CompuPro's implementation of MP/M-86) can
appreciate it.
Randy
www.s100-manuals.com
nos...@nouce.bellatlantic.net
<ra...@nospam.com> wrote:
>>> > The first versions were CP/M 1.4 lofted to 8086 instruction set.
>>> > it was ttles Quickdos (qdos) because it was quickly produced.
>>> > All thats needed to follow this is byte and kilobaud for the years
>>> > 1979 through 83. Since most of the ads and press releases
>>> > fall in that region.
>>> >
>>> > Allison
>>>
>>> Yes; you've just outlined the conventional thinking on the subject.
>>>
>>> However, Wild Bill has always maintained that the term 'Q-DOS' is
>>> a fake; a fraud; a red herring that was cooked up after the fact
>>> for nefarious, conspiratorial reasons.
True q-dos was never sold as Qdos, it was an SCP product and carried
the 86-dos name. However it was queer in that its really cp/1.4 run
through an 8080->8086 translator and then hand tweeked for operation.
>>> You must admit, none of the ads or press releases in your 1979 to
>>> 1983 'Byte' and 'Kilobaud' magazines ever mention 'Q-DOS.'
See above.
>I hate not snipping such a long post but the truth is simple:
>
>The PC especially the first PC was extremely dumbed down, that is a fact.
No question about it. I was running a CP/M86 system at 8mhz on
multibus writh more ramspace and more ram plus nice 1mb 8" disks and
a 5mb st506. made the IBM PC at introduction look pathetic.
>MP/M-86 came later and was never a question of IBM decision making. There
>was by that time problems between DRI & IBM plus MP/M-86 is happier with
>better hardware than a brain dead 8088. CompuPro was a much better example
>of a better 8088 implementation. Anyone that has worked with a 20mb drive
>on a Disk 2 running MP/M-816 (CompuPro's implementation of MP/M-86) can
>appreciate it.
Having said box with 85/88 cpu and a quantum 31mb and a full meg of
ram it really sings. Compared to PCs of the time it would hold it's
own until the 386 era started to hit 20+ mhz.
Allison
Barry Watzman
The utilities are all totally different. There is no PIP, no DDT, ED
and Edit are totally different, etc. So the utilities were not "run
through a translator". They were ALL new (or, at the very least,
plagerized from another source).
The file system is different. I mean totally different; it's FAT and
not FCB's (although there is some FCB support). So the BDOS is totally
different; not "CP/M 1.4 run through a translator".
The BIOS was hardware unique no matter what. So just what was run
through a translator, a list of Jump instructions? Ok, I'll give you
that one :-)
What's left? The CCP? It's all different also.
And the biggest difference, the 8086 (or 88) has a totally different
architecture from the 8080, and even the early versions of 86-DOS were
not limited to a single 64K segment. You don't get management of
segment registers -- not only in the OS itself but in the applications
software that it loads and runs -- from a code translator.
Conceptually, at some level, 86-DOS may have been based on CP/M 1.4.
But to say that "ts really cp/1.4 run through an 8080->8086 translator
and then hand tweeked for operation" is to make a statement that defies
logic and grossly oversimplifies the situation.
Randy McLaughlin
>I don't buy the "its really cp/1.4 run through an 8080->8086 translator and
>then hand tweeked for operation."
>
> The utilities are all totally different. There is no PIP, no DDT, ED and
> Edit are totally different, etc. So the utilities were not "run through a
> translator". They were ALL new (or, at the very least, plagerized from
> another source).
>
> The file system is different. I mean totally different; it's FAT and not
> FCB's (although there is some FCB support). So the BDOS is totally
> different; not "CP/M 1.4 run through a translator".
>
> The BIOS was hardware unique no matter what. So just what was run through
> a translator, a list of Jump instructions? Ok, I'll give you that one :-)
>
> What's left? The CCP? It's all different also.
>
> And the biggest difference, the 8086 (or 88) has a totally different
> architecture from the 8080, and even the early versions of 86-DOS were not
> limited to a single 64K segment. You don't get management of segment
> registers -- not only in the OS itself but in the applications software
> that it loads and runs -- from a code translator.
>
> Conceptually, at some level, 86-DOS may have been based on CP/M 1.4. But
> to say that "ts really cp/1.4 run through an 8080->8086 translator and
> then hand tweeked for operation" is to make a statement that defies logic
> and grossly oversimplifies the situation.
It was a small company and could not afford to do a double blind
development. The idea was simple the 8086/8088 needed an OS and no one had
one. CP/M had long since been available in many disassembled versions.
What was missing was unassembled DDT, PIP, ED, ASM, etc.
Using an 8080->8086 makes sense on what was available, I can not say that is
exactly what was done but I can say the BDOS & CCP core of 86-DOS did come
from CP/M. I say this not out of personal knowledge but by the fact a court
decided this.
The fact that 86-DOS uses the exact same structure to do BDOS calls but the
convention of source vs. destination of pip compared to copy shows one was a
direct copy while the later was a different mindset of Gary's work.
The fact that there were many changes like putting copy in the CCP makes
sense, it was easier than re-writing an entire separate utility. Added to
that the memory contraints of the 8080/Z80 were gone.
Randy
www.s100-manuals.com
Barry Watzman
That statement strikes me as absurd. How can anyone say that the BDOS
core of 86-DOS, which uses FAT file system, came from CP/M 1.4, which
used an FCB file system. The two operating systems allocate space
totally differently. I'm not saying that 86-DOS wasn't an "adaptation"
of CP/M, but one has to view that more as in the sense of "inspiration"
than at the level of actual CP/M code being used, because the
differences between the two OS' are so great that the code, translated
or not, could not have been used.
Randy McLaughlin
You snipped my explanation: "Using an 8080->8086 makes sense on what was
available, I can not say that is exactly what was done but I can say the
BDOS & CCP core of 86-DOS did come from CP/M. I say this not out of
personal knowledge but by the fact a court decided this."
It is already a proven fact (by the courts) that 86-DOS was stolen from DRI,
exactly how is unknown to me. I pointed out that the utilities did not
appear to be stolen which is very significant considering that the CP/M CCP
& BDOS were much better known than the utilities.
There are lots of incorrect statements about easter eggs where a secret
keystroke brings up a hidden message from Gary. I have a complete CP/M
source listing directly from DRI and know that's not true. What is not
wrong is that the courts found in favor of DRI's lawsuit.
Randy
www.s100-manuals.com
nos...@nouce.bellatlantic.net
<ra...@nospam.com> wrote:
>It is already a proven fact (by the courts) that 86-DOS was stolen from DRI,
>exactly how is unknown to me. I pointed out that the utilities did not
>appear to be stolen which is very significant considering that the CP/M CCP
>& BDOS were much better known than the utilities.
Randy, Once you have the OS writing a copy program or other utility is
considerably simplified and opens room for improvement.
>There are lots of incorrect statements about easter eggs where a secret
>keystroke brings up a hidden message from Gary. I have a complete CP/M
>source listing directly from DRI and know that's not true. What is not
>wrong is that the courts found in favor of DRI's lawsuit.
I know of no easter egg either. Thats a winders thing. I do know if
you dump the CCP/BDOS (V1.3-->3.0) using good old DDT at some
point you will find an ascii string that says COPYRIGHT DRI. Its my
understanding this was the oops bomb found in dos 1.x that made
creating V2 using virgin programmers a necessity for MS.
Allison
Randy McLaughlin
news:hsq051tukbeovmr8p...@4ax.com...
I've heard that it was a copyright notice that is the ultimate proof but I
never have had a copy of 86-DOS, I guess I could look at my PC-DOS.
Randy
nos...@nouce.bellatlantic.net
It has to be a very early like 1.0 version. I think by 1.1 or 1.2 it
was "fixed".
Allison
s_dub...@yahoo.com
cpm86 v1.1 for the ibm pc and xt, the floppy bootstrap. IIRC you get
it by pressing the question mark key repeatedly as the system loads
from floppy. But this one true fact doesn't validate others, also it
came later after cp/m-86 v1. I'm satisfied that I think DRI did run
their cp/m-80 CCP thru XLT86 to get cp/m-86's CCP started, did SCP - I
don't know. That's why I originally asked about 86-Dos & Dos 1.0
filesystem, whether it used FCB's, or fat. Sounds like they supported
fcb's but used fat's from the beginning.
>
> Randy
> www.s100-manuals.com
Randy McLaughlin
news:1112585125.4...@g14g2000cwa.googlegroups.com...
<snip>
> But there is an easter egg msg from Dean Ballard in the bootstrap of
> cpm86 v1.1 for the ibm pc and xt, the floppy bootstrap. IIRC you get
> it by pressing the question mark key repeatedly as the system loads
> from floppy. But this one true fact doesn't validate others, also it
> came later after cp/m-86 v1. I'm satisfied that I think DRI did run
> their cp/m-80 CCP thru XLT86 to get cp/m-86's CCP started, did SCP - I
> don't know. That's why I originally asked about 86-Dos & Dos 1.0
> filesystem, whether it used FCB's, or fat. Sounds like they supported
> fcb's but used fat's from the beginning.
I'll look into the CP/M-86 easter egg, it would have been PC specific. It's
not in the generic CP/M-86.
FCB's refer to how a program accesses a file, the file-system (FAT) is a
different issue. I have never heard the CP/M file-system referred to as
anything but "CP/M disk". FCB's were even used to access networked files on
both CP/NET & MS-DOS networked systems.
The original source to CP/M is in PL/M-80, DRI used PL/M-86 for CP/M-86
there was no need for an 8080->8086 translator.
On the other-hand there were several disassemblies of CP/M around that may
have been used for 86-DOS.
Randy
www.s100-manuals.com
Anonymous Guy
On 2005-04-03 ra...@nospam.com said:
> I'll look into the CP/M-86 easter egg, it would have been PC
> specific. It's not in the generic CP/M-86.
Yep. The 'egg' is specific to 'CP/M-86 For The IBM, Version 1.1'
BTW, it's encrypted; you won't find it by looking with a binary
file browser.
> The original source to CP/M is in PL/M-80, DRI used PL/M-86 for
> CP/M-86 there was no need for an 8080->8086 translator.
> On the other-hand there were several disassemblies of CP/M around
> that may have been used for 86-DOS.
>
> Randy
As a Digital Research licensee in the late 1970s, Seattle Computer
Products would most likely have had access to at least some -- if
not all -- of the CP/M source code. That was pretty much SOP at
the time.
nos...@nouce.bellatlantic.net
<ra...@nospam.com> wrote:
>FCB's refer to how a program accesses a file, the file-system (FAT) is a
>different issue. I have never heard the CP/M file-system referred to as
>anything but "CP/M disk". FCB's were even used to access networked files on
>both CP/NET & MS-DOS networked systems.
FCB --> FILE Control Block an in memory table of data to access a
CP/M file.
FAT --> File allocation table a table of bits used to manage the on
disk storage allocation. (what disk blocks are in use).
CP/M used allocation blocks, these are groups of sectors (1k or 8 for
SSSD 8") used in the driestory to name the specific groups of sectors
in use. The problem with this is you have to scan the directory (log
in a disk) to see whats in use and whats not) and build a table of
bits in ram. That location is in the bios ALLOC is the typical name
and it's a 1 bit per block map in an area of contigious bytes. (32
bytes for a SSSD 8"). Used allocation blocks are marked with a 1
and unused are a 0.
I've never worked with FAT but it's my understanding that FAT is the
roughly same as the in memory CP/M allocation table. Save for it's on
disk to aid storage allocation. I suspect thats maybe a bit
elementary and I've left out some details but, close enough.
From all I've seen SCP 86dos used FCB to access files and the disk
level file system was CP/M.
>The original source to CP/M is in PL/M-80, DRI used PL/M-86 for CP/M-86
>there was no need for an 8080->8086 translator.
Maybe, but it's my uderstanding V1.4 was used not 2.x that was
current.
>On the other-hand there were several disassemblies of CP/M around that may
>have been used for 86-DOS.
Indeed there were. It was a trivial task to take DDT and look inside.
Allison
Stephen Bendzick
>
> The idea that 86-DOS or Q-DOS supported hard drives and CP/M didn't is a
> crock.
>
> None of these OS' either do or don't. The physical implemlentation is
> in the BIOS, which is completely customizeable in both CP/M-86 and
> MS-DOS / 86-DOS / Q-DOS.
>
> The only support, and the only limitiations, are in the file system.
> CP/M at the time supported, I believe, up to 8 megabyte drives. MS-DOS
> (whatever you want to call it) started out with FAT-12, then later with
> version 2.0 went to FAT-32.
No, MS-DOS 3.0 introduced FAT-16. MS-DOS 2.0 introduced a lot of
things, including the hierarchical (UNIX-like) file system, file
handles, and native support for fixed disks, but still had only FAT-12.
Until MS-DOS 4.0 (or 3.31), fixed disk partitions were still limited to
32 MB even though FAT-16 with large clusters could go much higher; I
think this was due to an internal limitation in the representation of
sector numbers. FAT-32 was introduced with Windows 95 or Windows 98 (to
support partitions larger than 2 GB).
> Quarter of a gigabyte drives in 1981? You've got to be kidding. The
> biggest hard drives reasonably available for PCs (e.g. 5.25" form
> factor) was 10 MEGABYTES. The $15,000 CDC Hawk, the size of a
> refrigerator, was, I think, 10 fixed and 10 removeable. No one was
> thinking gigabytes. Mainframes didn't have gigabytes.
Not to contradict you personally, a refrigerator sized hard drive with
only 20 MB total capacity in 1981 doesn't make sense to me (even
disregarding the testimony of others about physically large mainframe
devices of that time with capacities of hundreds of MB). The extremely
common Seagate ST-225 5.25" half-height hard drive was 20 MB; twelve of
those would give 240 MB in the space of six 5.25" full-height drives.
Add a logic board about the size of a PC motherboard to integrate them
to function as one drive and to provide a controller, and add a power
supply, and you have an easily imaginable single device with almost 1/4
GB capacity that is about the size of 2 IBM AT system units. Granted,
it would have been extremely expensive (I'll wildly guess
$20,000-$50,000), but the technology was available. I can't imagine
that mainframe designers couldn't do better, but even if they couldn't,
they could have done it this way.
In addition, just because nobody was thinking gigabytes in the (then)
present doesn't mean no one was providing for future expansion.
However, I must admit that looking at what was actually produced prior
to the 1990s, I see that most engineers in the computer industry weren't
providing for the future. (The Y2K issue is one good example.)
> By the way, at the time I was the Product Line Director for Heathkit and
> Zenith Data Systems and I knew both Gary Kildall and Bill Gates
> personally. And I had -- and still have -- every version of 86-DOS from
> 0.33 on to MS-DOS 2.0. Supplied by Seattle Computer Products, on 8"
> diskettes, for an S-100 system (the SCP board set used in the "Gazelle"
> with a Tarbell double density disk controller). And while I was not
> present at or privy to the IBM negotiations (although I did discuss them
> with the principles "after the fact" -- more than a year later),
Way cool--all of that! :) Though it's not strictly relevant to mention,
I still use a ZDS Z-Station 450XEn (80486DX-50) to this day. I love the
built in ROM monitor on the ZDS PC systems.
> I think
> that the idea that the main "pitch" was for MP/M-86 is hogwash. MP/M-86
> may have been suggested as a future possibility, but I'm satisfied that
> the main discussion was about CP/M-86.
I'm no expert on these matters, but I too am highly skeptical of the
MP/M story.
As for QDOS, The MS-DOS Encyclopedia (Microsoft press, ed. by Ray
Duncan, 1988, ISBN 1-55615-049-0) gives what I consider Microsoft's
official position. For those interested, here's a summary of what it
says:
Tim Paterson designed an S-100 8086 CPU card at Seattle Computer
Products, getting it working by late spring 1979. He took his system to
Microsoft and got MS Stand-alone BASIC running on it. Around this time,
Digital Research called Paterson asking to borrow one of these CPU
boards to develop CP/M-86, and Paterson learned that CP/M-86 was due to
be ready in December 1979. The encyclopedia quotes from Paterson's
diary, "we'll have to live with Stand-alone BASIC for a few months after
we start shipping the CPU, but then we'll be able to switch to a real
operating system." Later, in June, Paterson attended the National
Computer Conference in New York, where he was introduced to Microsoft's
FAT file system. In the following months, Paterson did more work on the
8086 board, and SCP started shipping it with a BASIC option by the end
of 1979.
After CP/M-86 failed to arrive by April 1980, SCP decided to develop its
own 16-bit OS. The Encyclopedia states, "Originally, three operating
systems were planned: a single-user system, a multiuser version, and a
small interim product soon informally christened QDOS (for Quick and
Dirty Operating System) by Paterson." Paterson, it says, was the
individual who decided to make CP/M compatibility a major goal, since
CP/M had become the standard on 8-bit machines and since programs for
the 8080 could be mechanically translated to 8086 machine code.
[Presumably, this is regarding QDOS, since one would expect "a small
interim product" to be developed first.] Paterson also was the one who
decided to integrate FAT into his OS. [Aside: Here's a clear example of
the absence of ideas like software patents in the culture of the early
computer industry.] After four months, "Paterson had a functioning 6 KB
operating system, officially renamed 86-DOS". In September 1980 he
asked MS to write a version of BASIC for 86-DOS.
The Encyclopedia goes on to describe how an IBM group headed by Jack
Sams visited MS on August 21, 1980 to discuss having a ROM BASIC written
for an 8-bit IBM microcomputer based on hardware products from other
manufacturers (an early concept of the IBM PC). Microsoft said yes, but
suggested that IBM build a 16-bit computer based on the 8086 instead;
Sams returned to IBM and proposed a "low-end, 16-bit business
workstation". [It seems likely to me that MS is taking more credit here
than it deserves.] Sams returned a month later asking for FORTRAN,
Pascal, and COBOL in addition to BASIC, and MS said they'd need an OS
for those, because only MS's BASIC was designed to be stand-alone.
[This explains why early PCs had ROM BASIC and never ROM COBOL. :)]
Bill Gates suggested CP/M-86, which was still under development at DR,
and made the initial contact for IBM, but DR and IBM did not come to an
agreement. [Makes MS sound too good, doesn't it?]
MS still wanted to write the 400 KB of language code for IBM, but needed
a committed OS to meet IBM's 6-month schedule. Bill Gates, Paul Allen,
and Kay Nishi (a VP at MS) decided to add a low-end OS (of about 20 KB)
to the 400 KB of languages, assembler, and linker that IBM wanted MS to
write. Paul Allen contacted SCP and told them that MS wanted to
"develop and market SCP's operating system and that [MS] had an OEM
customer for it." SCP, not a software marketer, agreed to license
86-DOS to MS, later selling it outright in exchange for "$50,000,
favorable language licenses, and a license back from Microsoft to use
86-DOS on its own machines." Then "In October 1980, with 86-DOS in
hand, Microsoft submitted another proposal to IBM." The proposal
included both an OS and the languages. [Obviously noteworthy is the
fact that here MS claims that they already had 86-DOS before pitching an
OS to IBM, contradicting the popular version of the story.]
The Encyclopedia goes on to describe vaguely how 86-DOS was ported to
the prototype IBM PC, integrating it with the [ROM?] BIOS, which MS "was
helping IBM to write." One interesting item is a reproduction of a
technical sketch by Bob O'Rear illustrating the process of moving 86-DOS
to the IBM prototype. According to the sketch, it started with an 8"
source disk "Written for Absolute Assembler" in 86-DOS format. This was
loaded onto an "86DOS Development System" running Absolute Assembler
where "modifications & additions" were made "to meet IBM's
requirements", producing a "binary assembly of 86DOS" with "BIOS calls
to fixed locations" on 8" disk, still in 86-DOS format. Using two BASIC
programs running on the 86-DOS development system, the binary file was
converted to an Intel ASCII Hex file and then transmitted via RS-232
serial line to a DEC 2020 system. The [DOS(?)] BIOS was developed on
the DEC 2020 with a "relocatable assembler", cross-assembled there to
8086 machine code, and converted to Intel ASCII Hex. Next, both Hex
files on the DEC 2020 were uploaded to an Intel system running ISIS,
written to ISIS-format 8" disk, and carried into the "IBM Room" in the
disk. There, a different Intel machine running ISIS had two connections
to the IBM prototype: RS-232 serial and an ICE88 in-circuit emulator,
and the IBM prototype ran an Intel Hex loader and a binary disk write
program to produce a 5.25" MS-DOS format disk with binary MS-DOS and
BIOS files. O'Rear's notes on the sketch indicate that it was drawn up
after the fact (he uses the past tense) and that programs to transmit
files between the two ISIS systems were written later, so that disks no
longer had to be walked from room to room.
The really interesting thing, for this discussion, is that on the sketch
the source disk is labeled " 8" Disk source QDOS(86DOS)". Everywhere
else on the sketch, only the name "86DOS" is used. (The other
interesting thing to me is that the 8" ISIS disk that is walked into the
IBM Room is still called 86DOS, but the 5.25" disk written out by the
IBM prototype is called MS-DOS. This is the only place on the sketch
that the name MS-DOS is mentioned.)
Tim Paterson continued to work on 86-DOS at SCP, improving its logical
device independence on his own (things like multiple sector and record
read and write functions, and variable record length) and making changes
requested by MS. In May 1981, he moved from SCP to Microsoft and for
the first time learned the OEM's name (IBM) and saw the prototypes.
And that's what Microsoft says about all that.
All of this clear clearly presents QDOS as just an inside (slang) name
for 86-DOS. That was what I'd heard previously, so I think it's
probably true. Therefore, I wouldn't expect "Q-DOS" to appear in any
public documentation or advertising, as Anonymous Guy brought up. Might
the term Q-DOS have been invented after MS-DOS 1.0 was already in the
works or later, for someone's propaganda purpose? I know of no evidence
to disprove this, but I don't know whose or what purpose; it doesn't
seem to support any purpose Microsoft had when the name QDOS first
appeared.
Here's a question: If 86-DOS originally had the finished ability to
handle disks up to about 1 GB, why did it take until version 4 (or 3.31)
for support for hard disks over 32 MB to reappear in MS-DOS? MS bought
86-DOS outright, and only MS dealt with IBM, so surely MS had the code
if it existed. Even assuming that IBM was suppressing capabilities, why
would it allow MS to add all the networking and file locking
capabilities introduced with MS-DOS 3.0 and 3.1 in 1984, and
partitioning support in DOS 3.3 in 1987, but still not allow MS to add
support for fixed disks larger than 32 MB? And is it even possible that
IBM still held enough sway over MS in 1987 to dictate any such
limitation? Doubtful on all counts. In fact, the MS-DOS Encyclopedia
states that IBM itself commissioned the networking support in DOS 3.x
for the IBM AT. Then there's the aftermarket to consider--IBM developed
the PC as an open architecture, so if IBM didn't provide something that
users wanted, some third party vendor would. It seems to me that if
86-DOS originally had large disk support, MS was free to reintroduce it
before 1987.
I'd be interested in seeing any other evidence on this issue,
particularly any proven facts not already mentioned that corroborate or
contradict parts of this history according to Microsoft.
Stephen
Barry Watzman
code from disassembly was available in the 1970's, in the CP/M user's group.
Barry Watzman
nos...@nouce.bellatlantic.net
<step...@catholicexchange.com> wrote:
>Not to contradict you personally, a refrigerator sized hard drive with
>only 20 MB total capacity in 1981 doesn't make sense to me (even
>disregarding the testimony of others about physically large mainframe
>devices of that time with capacities of hundreds of MB). The extremely
>common Seagate ST-225 5.25" half-height hard drive was 20 MB; twelve of
>those would give 240 MB in the space of six 5.25" full-height drives.
The st225 was not available until late 1983, maybe later. I'd not
seen any commonly around until the PC AT had been out for a while.
The largest 5.25" drive you could by in the fall of 1981 (pc
introduction) was 10mb and it would be easily a year before 20/30mb
drives appeared. There were 8" SMD drives that were larger but not
5.25.
>In addition, just because nobody was thinking gigabytes in the (then)
>present doesn't mean no one was providing for future expansion.
>However, I must admit that looking at what was actually produced prior
>to the 1990s, I see that most engineers in the computer industry weren't
>providing for the future. (The Y2K issue is one good example.)
Huh??? The designer of the DEC alpha developed a 64bit machine
for just that reason, more address space. That was 1991ish.
>I'm no expert on these matters, but I too am highly skeptical of the
>MP/M story.
the summer of 1981 was too early for MP/M-86 and even MP/M was
not yet.
To me there were a few things I do know well of the era.
MS was a language house. DRI was an OS house and some languages.
Most of the market was shared as a result. All of the best CP/M
software was third party to both (Dbase, VISICALC, EDITORS).
I was watching hardware closely during the 1979 through '84 timeframe,
It was what I was doing. However, all the hardware was tied to
microprocesors and 8085/z80 were already midlife heading for trailing
edge with 8086, Z8000 and 68000 starting to bang heads. The 8086/88
was already on multibus and S100 by 1980 and those looking forward
know an OS was needed as the hardware expolsion was only a short
time away. Who would have ever thought the clunky slow IBM PC would
be a dominant element in the spring of 1982. I can say that I'd have
never believed that. The rest is revsionist history written by the
apparent winner.
Allison