How about CP/M 2001?
belinda
What I was thinking was adding a multitasking table, semaphore table,
device table, graphics table, multimedia table, and have it work with
old CP/M programs and new ones 16MB (with the z280 or new designs)... I
have some things sketched out...
Give the world another operating alternative, command based to windows
based similar to what is done with linux going to X.
What do you think?
Douglas Beattie Jr.
> How about a CP/M 2001?
>
> What I was thinking was adding a multitasking table, semaphore table,
> device table, graphics table, multimedia table, and have it work with
> old CP/M programs and new ones 16MB (with the z280 or new designs)...
>
> I have some things sketched out...
Tell me more. I have some things sketched out too. It's a great idea,
but the hardware to support these kinds of features is scarce, and what
few systems which do exist are far too costly to ever become popular.
> Give the world another operating alternative, command-based to
> Windows-based similar to what is done with Linux going to X.
>
> What do you think?
How many CP/M systems have graphics cards and color monitors? What
kind of standard will provide for I/O subsystem compatiblity? But I
do appreciate what you're saying. Linux loads modules to support
hardware, and module linking often accepts parameters for I/O address
and interrupts.
Let's use a (cheap) 16-color VGA card, for example. It's really just
a 'black box' with signals to control its features.
With the appropriate interface, Video RAM on the card could also be
accessed using I/O instead. Almost all peripheral cards can be thought
of this way -- simplay a "black box."
Now, how would you write a device driver to accomodate the card? Which
comes first, the hardware or the device driver? And where is the
hardware (implementation thereof).?
Just some food for thought... I'd really like to see X-windows run
on a Z180 some day. And remember: paged memory can give you literally
GIGABYTES of RAM... just like EMS on modern PCs.
--
Douglas Beattie Jr. http://www2.whidbey.net/~beattidp/
anon...@bogus_address.con
On 1999-12-30 dkan...@acronet.net said:
>How about a CP/M 2001?
>What I was thinking was adding a multitasking table, semaphore
>table, device table, graphics table, multimedia table, and have it
>work with old CP/M programs and new ones 16MB (with the z280 or new
>designs)... I have some things sketched out...
>Give the world another operating alternative, command based to
>windows based similar to what is done with linux going to X.
>What do you think?
I think your efforts would be better spent in re-working CP/M-86 or
some other O.S. designed for the i86 architecture.
Like it or not, the x86 is the prevailing processor out there today.
What's more, the IBM clone is standardized, unlike all those dozens
of various and sundry CP/M-80 boxes...each with its own proprietary
stuff.
Forget the Z280. What's the point of designing an O.S. for hardware
that's literally non-existent?
The IBM clone is the currently-installed hardware base you have to
work with. GO for it!
IMHO
Jack Peacock
news:386BBB92...@acronet.net...
> How about a CP/M 2001?
>
> What I was thinking was adding a multitasking table, semaphore table,
> device table, graphics table, multimedia table, and have it work with
> old CP/M programs and new ones 16MB (with the z280 or new designs)...
I
> have some things sketched out...
>
version) and later Concurrent DOS (386 version), all from Digital
Research, though C-DOS was sold off to some small company by Novell,
can'[t remember the name.
Jack Peacock
Barry Watzman
require one). There was also MP/M II and MP/M-86.
Richard Plinston
B
:> I think some of that has already been done...it's called MP/M (Z80
:> version) and later Concurrent DOS (386 version), all from Digital
MP/M was 8080 code, it used bank swithching of, say, 256Kb to give
several TPAs of 48Kb.
MP/M-86, Concurrent-CP/M-86 and Concurrent-DOS were 8086 (or 8088)
code and could run on an IBM-PC or XT with 640Kb, or preferably a
non-IBM-PC with an 8086 CPU and 1Mbyte of RAM such as an ICL-PC
or Quattro or DRS300 or an Altos.
CDOS-XM could utilise EEMS memory (not EMS) to allow several
MBytes to be used via a form of bank switching.
CDOS-386 was equivalent to CDOS version 6 and was the first
386 coded CDOS.
:> Research, though C-DOS was sold off to some small company by Novell,
:> can'[t remember the name.
:> Jack Peacock
It was initially sold by Novell to Caldera. However DRI had
appointed 3 VARs (Value Added Resellers) of Concurrent-DOS, at
least one of which continue to use their licence to develop and
sell derivitives of CDOS - see www.imsltd.com
I understand that CDOS and DR-Multiuser-DOS were sold by Caldera,
but they never said to whom.
--
Thorsten Franke
beattidp # whidbey.net@2:24/600.77 meinte am Freitag (31.12.99)
zum Thema "Re: How about CP/M 2001?":
DBJ> > How about a CP/M 2001?
DBJ> > What I was thinking was adding a multitasking table, semaphore table,
DBJ> > device table, graphics table, multimedia table, and have it work with
DBJ> > old CP/M programs and new ones 16MB (with the z280 or new designs)...
DBJ> > I have some things sketched out...
DBJ> Tell me more. I have some things sketched out too. It's a great idea,
DBJ> but the hardware to support these kinds of features is scarce, and what
DBJ> few systems which do exist are far too costly to ever become popular.
Why not using CP/M86 as a basis? Then the problem with the hardware is
small and it will be a real alternative. 'cause you need a hardware
platform that is common.
** Greetings **
EMail : ap...@gmx.de ICQ : 49933812
WWW : http://diverse.freepage.de/apas/ & babylon5/
--- CrossPoint v3.12c
* Origin: "Heffer, du hast ja Kreuze statt Augen..." (Rocko) (2:2448/615.2)
SEEN-BY: 24/600 2448/600 615
Steve Dubrovich
Where would you go with cp/m-86??
just update the bios and keep the ccp & bdos or,
major change in memory usage, object file design??
Steve
anon...@bogus_address.con
On 2000-01-08 sjdub...@internetni.com said:
>Where would you go with cp/m-86??
>just update the bios and keep the ccp & bdos or,
>major change in memory usage, object file design??
The CP/M-86 BIOS would certainly have to be updated, and extended BDOS
functions wouldn't hurt, either. Ability to use upper memory? Hmmmm...
Well, I guess that when one considers all the ramifications of such a
CP/M-86 update, it would just be easier and much more efficient to run
DR-DOS 7.x on an i86-based machine! <g>
So okay, let's leave CP/M-86 the way it is...with the possible exception
of higher floppy disk capacity.
Instead, perhaps we could concentrate on generating a bit more needed
=software= for CP/M-86.
The past six years have already brought some tremendous software advances
to CP/M-86...including the ready availability of at least 6 different
proprietary programming language compilers, 4 proprietary text editors,
a freeware byte-level binary file editor, 3 different freeware graphics
file viewers, Y2K-compliant system time/date software, and over 100 new
useful utilities (from screen-savers to text-file viewers to phone dialers).
Of course, the crowning achievement was Richard Kanarek's now-classic 'AT
patch' from 1995, which allows CP/M-86 For The IBM to run on =any= Intel
x86-based machine...up to and including the latest, fastest leading-edge
processors.
Now we need to fill in some remaining gaps in the CP/M-86 software reper-
toire. Here's a sample 'wish list:'
* ZIP/UNZIP FOR CP/M-86
A couple of possibilities here. The complete InfoZIP GPL source code
for DOS is available in C. Michael Mefford's DOS .ASM source code for
an UNzipper is also available. With a lot of hand-crafting, either one
of these programs could be ported to CP/M-86. Not an easy job, but
perhaps easier than starting totally from scratch.
* DEDICATED 'NET AGENTS WITH =INTERNAL= PPP SUPPORT
Mail, news, FTP, HTTP...any of these with built-in Point to Point
Protocol support would make accessing the 'Net from CP/M-86 =much=
simpler and more convenient. Think it'll ever happen?
* FULL FIDD DOCUMENTATION
Knowing how to write, compile and load a CP/M-86 FIDD would certainly
open up a lot of possibilities for the O.S. However, this information
seems to be lost in antiquity. If any 'lurker' in this newsgroup has
the original IBM FIDD app notes, or the DRI CP/M-86 Programmers
Reference covering FIDDs, please speak up. Don't be shy! You're
among friends here, and the information is sorely needed.
* ACCESS TO EXTENDED MEMORY
Theoretically, this should be achievable without a DOS-style memory
manager in one of two ways:
1. Using enhanced functions of ROM BIOS Interrupt 15h, or...
2. Setting the processor (386 and above) to 'unreal' mode (also
called 'big real' mode or 'flat real' mode).
In either case, the programmer would need to manually 'manage' the
upper memory accesses from within the particular program he's writing.
But since CP/M-86 is a real-mode, single-user, single-tasking O.S.,
this manual 'management' should be fairly trivial.
Anyone want to volunteer to tackle one of these???
Richard Plinston
: On 2000-01-08 sjdub...@internetni.com said:
: >Where would you go with cp/m-86??
: >just update the bios and keep the ccp & bdos or,
: >major change in memory usage, object file design??
: The CP/M-86 BIOS would certainly have to be updated, and extended BDOS
: functions wouldn't hurt, either. Ability to use upper memory? Hmmmm...
The CP/M-86 API (ie BDOS functions) have already been specified
and implemented for memory, interprocess communication (queues),
subdirectory, and many more. See the CP/M-86 pBDOS for Concurren-CP/M-86
and DOS-Plus. This is still available in the latest versions from
IMS's Real/32 (ie CP/M-86 .CMD files will run on Real/32 alongside
MS Windows, Windows servers and Web servers - see www.imsltd.com).
: Well, I guess that when one considers all the ramifications of such a
: CP/M-86 update, it would just be easier and much more efficient to run
: DR-DOS 7.x on an i86-based machine! <g>
DR-DOS 7 doesn't run .CMD CPM/-86 programs, whereas Real/32 and
Datapac.s System Manager do.
: * ACCESS TO EXTENDED MEMORY
: Theoretically, this should be achievable without a DOS-style memory
: manager in one of two ways:
: 1. Using enhanced functions of ROM BIOS Interrupt 15h, or...
: 2. Setting the processor (386 and above) to 'unreal' mode (also
: called 'big real' mode or 'flat real' mode).
: In either case, the programmer would need to manually 'manage' the
: upper memory accesses from within the particular program he's writing.
: But since CP/M-86 is a real-mode, single-user, single-tasking O.S.,
: this manual 'management' should be fairly trivial.
If you do any work in this are then it would be sensible to follow
the DOS-Plus/CCP/M-86/Real-32 mechanisms so that you could
potentially run programs designed for these and/or have new
programs also run on later systems.
Brown & Kyle's PC Interrupts (book or downloadable text files)
has a section on DR-Multiuser-DOS (renamed Concurrent-DOS).
There is also a good reference to DOS-Plus 'Master 512 Technical
Guide' by Robin Burton, Dabs Press, ISBN 1-870336-80-1. This
describes the DOS-Plus implementation on the 8086 add-on card
for the BBC Master computer and covers the BDOS functions quite
adequately.
--
John Elliott
>There is also a good reference to DOS-Plus 'Master 512 Technical
>Guide' by Robin Burton, Dabs Press, ISBN 1-870336-80-1. This
>describes the DOS-Plus implementation on the 8086 add-on card
>for the BBC Master computer and covers the BDOS functions quite
>adequately.
I believe that's DOSPLUS 2.x. Does anyone know if DOSPLUS 2.x exists on
the Net?
------------- 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
:-------------------------------------------------------------------------)
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:859r0e$m7e$1...@q.seanet.com...
>
> On 2000-01-08 sjdub...@internetni.com said:
>
> >Where would you go with cp/m-86??
> >just update the bios and keep the ccp & bdos or,
> >major change in memory usage, object file design??
>
> The CP/M-86 BIOS would certainly have to be updated, and extended BDOS
> functions wouldn't hurt, either. Ability to use upper memory? Hmmmm...
>
> CP/M-86 update, it would just be easier and much more efficient to run
> DR-DOS 7.x on an i86-based machine! <g>
>
> of higher floppy disk capacity.
>
least read the B> drive in a higher native capacity. need a format program
to properly format it...
> * ACCESS TO EXTENDED MEMORY
> Theoretically, this should be achievable without a DOS-style memory
> manager in one of two ways:
> 1. Using enhanced functions of ROM BIOS Interrupt 15h, or...
> 2. Setting the processor (386 and above) to 'unreal' mode (also
> called 'big real' mode or 'flat real' mode).
> In either case, the programmer would need to manually 'manage' the
> upper memory accesses from within the particular program he's writing.
> But since CP/M-86 is a real-mode, single-user, single-tasking O.S.,
> this manual 'management' should be fairly trivial.
>
> Anyone want to volunteer to tackle one of these???
Further software dev. should await modernization of a cBIOS and some of the
memory strategy that Richard has pointed out.
Steve
Steve Dubrovich
THX Richard...
"Richard Plinston" <rip...@kcbbs.gen.nz> wrote in message
news:85aot3$sko$1...@aklobs.kc.net.nz...
> anonymous@bogus_address.con wrote:
>
> : On 2000-01-08 sjdub...@internetni.com said:
>
> : >Where would you go with cp/m-86??
> : >just update the bios and keep the ccp & bdos or,
> : >major change in memory usage, object file design??
>
> : The CP/M-86 BIOS would certainly have to be updated, and extended BDOS
> : functions wouldn't hurt, either. Ability to use upper memory? Hmmmm...
>
> The CP/M-86 API (ie BDOS functions) have already been specified
> and implemented for memory, interprocess communication (queues),
> subdirectory, and many more. See the CP/M-86 pBDOS for Concurren-CP/M-86
> and DOS-Plus. This is still available in the latest versions from
> IMS's Real/32 (ie CP/M-86 .CMD files will run on Real/32 alongside
> MS Windows, Windows servers and Web servers - see www.imsltd.com).
>
Qwik link:
http://development.imsltd.com/calls/mc_max.html
I've some more looking to do here.
> : Well, I guess that when one considers all the ramifications of such a
> : CP/M-86 update, it would just be easier and much more efficient to run
> : DR-DOS 7.x on an i86-based machine! <g>
>
> DR-DOS 7 doesn't run .CMD CPM/-86 programs, whereas Real/32 and
> Datapac.s System Manager do.
>
> : * ACCESS TO EXTENDED MEMORY
> : Theoretically, this should be achievable without a DOS-style memory
> : manager in one of two ways:
> : 1. Using enhanced functions of ROM BIOS Interrupt 15h, or...
> : 2. Setting the processor (386 and above) to 'unreal' mode (also
> : called 'big real' mode or 'flat real' mode).
> : In either case, the programmer would need to manually 'manage' the
> : upper memory accesses from within the particular program he's
writing.
> : But since CP/M-86 is a real-mode, single-user, single-tasking O.S.,
> : this manual 'management' should be fairly trivial.
>
> If you do any work in this are then it would be sensible to follow
> the DOS-Plus/CCP/M-86/Real-32 mechanisms so that you could
> potentially run programs designed for these and/or have new
> programs also run on later systems.
>
> Brown & Kyle's PC Interrupts (book or downloadable text files)
> has a section on DR-Multiuser-DOS (renamed Concurrent-DOS).
>
> There is also a good reference to DOS-Plus 'Master 512 Technical
> Guide' by Robin Burton, Dabs Press, ISBN 1-870336-80-1. This
> describes the DOS-Plus implementation on the 8086 add-on card
> for the BBC Master computer and covers the BDOS functions quite
> adequately.
>
Hmm, seems like the best route, only the cbios needs the primary update.
Steve
anon...@bogus_address.con
On 2000-01-09 rip...@kcbbs.gen.nz said:
>The CP/M-86 API (ie BDOS functions) have already been specified
>and implemented for memory, interprocess communication (queues),
>subdirectory, and many more. See the CP/M-86 pBDOS for
>Concurrent-CP/M-86 and DOS-Plus. This is still available in the
>latest versions from IMS's Real/32...
Thing is, CP/M-86 version 1.1 For The IBM is a =predecessor= of those
later OSes, and doesn't contain the functions you mention. Adding them
in at this late date seems like a striving after wind. Read on:
>DR-DOS 7 doesn't run .CMD CP/M-86 programs, whereas Real/32 and
>Datapac.s System Manager do.
This is an insignificant 'advantage.' If you took every bit of soft-
ware ever written for CP/M-86 1.1 and dropped it off a pier, it wouldn't
even make a SMALL splash. So backwards compatibility is, IMHO, a non-issue.
Besides, there are a couple of excellent freeware CP/M-86 emulators
available for DOS if one =really= wants to run CP/M-86 software
under another OS.
>If you do any work in this are then it would be sensible to follow
>the DOS-Plus/CCP/M-86/Real-32 mechanisms so that you could
>potentially run programs designed for these and/or have new
>programs also run on later systems...
Well, I disagree. Why go to all the trouble to re-write CP/M-86 1.1,
only to duplicate features that already exist in later incarnations?
If one =wants= those features, one can simply switch to any of those
other OSes.
I rather like CP/M-86 1.1 the way it is; it's intuitive, familiar in
look-and-feel to experienced CP/M-ers, and easy to use.
Wouldn't mind adding in a couple of extra capabilites, if they didn't
change the basic look, feel and operation of version 1.1.
But Concurrent CP/M-86 is a major change from CP/M-86 1.1, and frankly
I don't much care for it. It's quite convoluted and non-intuitive.
And BTW, virtually =no= user software was ever produced that could
take advantage of Concurrent's capabilities.
anon...@bogus_address.con
On 2000-01-09 sjdub...@internetni.com said:
>Further software dev. should await modernization of a cBIOS and
>some of the memory strategy that Richard has pointed out.
Don't think so, Steve. Lots of good, contemporary software has been
produced for CP/M-86 Version 1.1 For The IBM within the past couple
of years...including graphics file viewers, and even some 'moused'
software (using direct hardware access; no driver required).
None of this software required any O.S. 'modernization.'
Anyway, why go to all the trouble of re-inventing the O.S. 'wheel?'
If someone wants the additional capabilities that Richard mentioned,
all they have to do is switch to one of the later operating systems
which already =has'em.=
Other than 'tacking on' a few extra capabilities to CP/M-86 1.1 --
such as higher floppy disk capacity -- I'm ambivalent about making
major alterations. It's already a good, stable, single-user real-mode
operating system.
There's not much of any real importance that can't be done with
CP/M-86 1.1 the way it currently is.
john dubrovich
I see what you mean. I agree, a couple of extra capabilities is what I
orginally had in mind also. The higher disk capacity recognition and
better support for the modern rombios time/date features. The
distrbuted cp/m-86 v1.1 has cBIOS support for a lightpen, for example,
as best unneeded, at worse?? The distributed version seems circa '286
in its rombios usage.
Steve
Steve Dubrovich
Will generic cp/m-86 programs run on a Concurrent cp/m-86 system??
The cp/m80 v3 filesystem is backward compatible with cp/m80 v2 files. Would
extending the v3 xfcb structure to cp/m-86 be going too far for you? For
that matter, would extending the cp/m-86 to adoption of the cp/m80 v3 schema
[SCB Sytem Control Block, for example, and some implementation of RSX's] be
going too far??
I'm curious as to where the boundary should be set.
Steve
anon...@bogus_address.con
On 2000-01-10 jdubr...@mediaone.net said:
> > Other than 'tacking on' a few extra capabilities to CP/M-86 1.1 --
> > such as higher floppy disk capacity -- I'm ambivalent about making
> > major alterations. It's already a good, stable, single-user
> > real-mode operating system.
> >
> > There's not much of any real importance that can't be done with
> > CP/M-86 1.1 the way it currently is.
>
>I see what you mean. I agree, a couple of extra capabilities is
>what I orginally had in mind also. The higher disk capacity
>recognition and better support for the modern rombios time/date
>features.
Automatically setting the =system= time/date is easily done, using
third-party software. If you don't yet have that software, leave a
message in this newsgroup and I'll e-mail it to you. Specify what
type of machine you're running (PC/XT, or 286-and-up), and whether
or not you've already made the 'Y2K patch' to your system file.
Adding a time/date stamp to disk files is a bit more problematic.
>The distrbuted cp/m-86 v1.1 has cBIOS support for a lightpen, for
>example, as best unneeded, at worse??
Yes, the light pen support could probably be expunged, and replaced by
something more useful.
>The distributed version seems circa '286 in its rombios usage.
Earlier than that: 8086/8088-based PC- and XT-class only. But since
we're using real mode, it's not =too= big a deal.
As far as using the newer, extended ROM BIOS functions, that's not a
problem when it comes to programming your own apps.
Unlike WIN-DOZE or LINUX, in CP/M-86 you're perfectly free to =directly=
call any ROM BIOS function from within your program. You're not limited
to using only the O.S.'s pre-defined functions.
That's one major advantage of a real-mode, single-tasking operating
system! :)
If we were limited to using =only= CP/M-86's BDOS or BIOS functions, then
we might be in a world of hurt. Happily, there's no such limitation.
anon...@bogus_address.con
On 2000-01-10 sjdub...@internetni.com said:
>Will generic cp/m-86 programs run on a Concurrent cp/m-86 system??
Some will, some won't; depends on what's going on 'under the hood' in a
particular program. Many CP/M-86 low-level utilities will often error out
under Concurrent CP/M-86. A CP/M-86 application program will =sometimes=
run okay.
But not always. And you can see why.
In the arena of 'multi-tasking' or 'multi-user' -- and Concurrent CP/M-86
is definitely in that arena -- an O.S. must, of necessity, 'manage' most
or all accesses to system resources through itself.
The principle's much the same (but more complicated) in Mikro$loth Win-
Blows. That's why you can't call interrupts, or directly access most
port addresses, from within a WinBlows-specific program.
>The cp/m80 v3 filesystem is backward compatible with cp/m80 v2
>files. Would extending the v3 xfcb structure to cp/m-86 be going
>too far for you?
Uhhh...I might be able to live with it. But my opinion's irrelevant.
>For that matter, would extending the cp/m-86 to
>adoption of the cp/m80 v3 schema [SCB System Control Block, for
>example, and some implementation of RSX's] be going too far??
>I'm curious as to where the boundary should be set.
Well, RSX is already possible to some extent under CP/M-86 1.1 For
The IBM. The D.R.I. 'C' language package for CP/M-86 includes a
stand-alone relocating assembly language compiler and linker (RSX86
and LINK86).
As for the rest: do you feel that the potential pay-off would justify
the time and trouble involved in making the changes? If so, go for it!
I volunteer to be an Alpha tester. :)
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:85ele8$21v$2...@q.seanet.com...
>
> On 2000-01-10 sjdub...@internetni.com said:
>
> >Will generic cp/m-86 programs run on a Concurrent cp/m-86 system??
>
> Some will, some won't; depends on what's going on 'under the hood' in a
> particular program. Many CP/M-86 low-level utilities will often error out
> under Concurrent CP/M-86. A CP/M-86 application program will =sometimes=
> run okay.
>
> But not always. And you can see why.
>
> In the arena of 'multi-tasking' or 'multi-user' -- and Concurrent CP/M-86
> is definitely in that arena -- an O.S. must, of necessity, 'manage' most
> or all accesses to system resources through itself.
>
> The principle's much the same (but more complicated) in Mikro$loth Win-
> Blows. That's why you can't call interrupts, or directly access most
> port addresses, from within a WinBlows-specific program.
>
I suspected as much...
Tho, on win95, you can run debug in an dos window, and can call at least
some interrupts. But I know what your getting at.
No, I don't really don't want to mess with multitasking. I want a simple
sytem to mess with.
> >The cp/m80 v3 filesystem is backward compatible with cp/m80 v2
> >files. Would extending the v3 xfcb structure to cp/m-86 be going
> >too far for you?
>
> Uhhh...I might be able to live with it. But my opinion's irrelevant.
>
> >For that matter, would extending the cp/m-86 to
> >adoption of the cp/m80 v3 schema [SCB System Control Block, for
> >example, and some implementation of RSX's] be going too far??
> >I'm curious as to where the boundary should be set.
>
It sounds like 'Personal CP/M-86' has that covered, no need to go there.
> Well, RSX is already possible to some extent under CP/M-86 1.1 For
> The IBM. The D.R.I. 'C' language package for CP/M-86 includes a
> stand-alone relocating assembly language compiler and linker (RSX86
> and LINK86).
>
Are those packages on the Commercial CP/M software website, or is that
taboo?? Perhaps you mean RASM86, which is with the programmers utilities on
the Unofficial CP/M mirror sites.
> As for the rest: do you feel that the potential pay-off would justify
> the time and trouble involved in making the changes? If so, go for it!
>
Absolutely Not! The only way I could justify the time and effort is as
entertainment and personal satisfaction! Hey, some folks do crossword
puzzles! Yes I'm going for it, tho.
> I volunteer to be an Alpha tester. :)
>
Don't hold your breath. I've yet to finish disassembling the boot loader,
part II, to my satisfaction, as well as the remainder of the distributed
cBIOS. Once I have the cBios source refined enough to rebuild the system
along with the CCP and Bdos, then I'll feel like doing an updated generic
Bios. Early on will be support for higher disk capacities.
>Automatically setting the =system= time/date is easily done, using
>third-party software. If you don't yet have that software, leave a
>message in this newsgroup and I'll e-mail it to you. Specify what
>type of machine you're running (PC/XT, or 286-and-up), and whether
>or not you've already made the 'Y2K patch' to your system file.
Is that software on the unofficial cp/m mirror sites? I may have it
already. I do the developement on a spare '486. I've still got an XT clone
turbo, an ST they called it in those days with a V20 cpu, but it won't boot
up into CP/M-86, the POST just continues to loop, even tho I have a bootable
HD, I haven't figured that one out, besides the '486 is faster.
> >The distributed version seems circa '286 in its rombios usage.
>Earlier than that: 8086/8088-based PC- and XT-class only. But since
>we're using real mode, it's not =too= big a deal.
Well, the cpm.sys that is in circulation calls one of the 'equipment list'
bios interrupts that, I had the impression, is only valid on a '286. So I
assumed that the cpm.sys is an OEM version developed for clone '286. This
warrants futher inspection. If the cBIOS is for a slightly unique clone, it
may not be stable on current systems.
Anyway, thanks for the feedback. I'm satisfied in what my next couple of
steps should be. I could use some feedback on a strategy for auto-detection
of cp/m disk density tho.
Steve
anon...@bogus_address.con
On 2000-01-11 sjdub...@internetni.com said:
>I suspected as much...
>Tho, on win95, you can run debug in a dos window, and can call at
>least some interrupts. But I know what your getting at.
In a DOS window, you're in a 'virtual 86 machine'...so yes, interrupts
can be called there.
From within an actual Win-Doze Ninety-X program, interrupts =can't= be
used; only API function calls.
>Perhaps you mean RASM86, which is with the programmers utilities
>on the Unofficial CP/M mirror sites.
Yes, you're right. That's what I meant.
>Is that software on the unofficial cp/m mirror sites?
Yes, the Y2K-compliant version of the CP/M-86 system time/date-setting
software is available on the mirrors. But it doesn't work correctly if
you've made the permanent 'Y2K patch' to your CPM.SYS system file.
>Well, the cpm.sys that is in circulation calls one of the
>'equipment list' bios interrupts that, I had the impression, is
>only valid on a '286. So I assumed that the cpm.sys is an OEM
>version developed for clone '286. This warrants futher inspection.
>If the cBIOS is for a slightly unique clone, it may not be stable
>on current systems.
If you're talking about Interrupt 11h, it's not 286-specific. All
ROM BIOS interrupts from 00h to 19h are universally compatible among
all IBM clones, even back as far as the original PC.
Indeed, 'CP/M-86 For The IBM, Version 1.1' won't run on 286-and-up
machines without Richard Kanarek's 'AT patch.'
>Anyway, thanks for the feedback. I'm satisfied in what my next
>couple of steps should be. I could use some feedback on a strategy
>for auto-detection of cp/m disk density tho.
Since no standards exist, you're pretty much free to develop your own
method. Might consider putting a DOS-style disk ID byte in an unused
sector. Have fun! :)
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:85h5nf$6se$1...@q.seanet.com...
>
> >Well, the cpm.sys that is in circulation calls one of the
> >'equipment list' bios interrupts that, I had the impression, is
> >only valid on a '286. So I assumed that the cpm.sys is an OEM
> >version developed for clone '286. This warrants futher inspection.
> >If the cBIOS is for a slightly unique clone, it may not be stable
> >on current systems.
>
> If you're talking about Interrupt 11h, it's not 286-specific. All
> ROM BIOS interrupts from 00h to 19h are universally compatible among
> all IBM clones, even back as far as the original PC.
>
available on the AT class.
11DC:3C05 CALL 3E9C ;;subr-c
11DC:3C08 MOV AH,08
11DC:3C0A MOV DL,80
11DC:3C0C INT 13 ;;bios int13 serv8, return fixed disk drive
parameters.
11DC:3C0E MOV AL,DL ;; [AT computers], if CY, AH holds stat bits
|dl=#consecutive drives
11DC:3C10 POP DX
--from the offset 2500, bios jmp table
> Indeed, 'CP/M-86 For The IBM, Version 1.1' won't run on 286-and-up
> machines without Richard Kanarek's 'AT patch.'
>
> >Anyway, thanks for the feedback. I'm satisfied in what my next
> >couple of steps should be. I could use some feedback on a strategy
> >for auto-detection of cp/m disk density tho.
>
> Since no standards exist, you're pretty much free to develop your own
> method. Might consider putting a DOS-style disk ID byte in an unused
> sector. Have fun! :)
>
I think there's a media byte at the end of the first sector which
distinguishes between SS and DS media --ref. John Elliot's website.
Steve
anon...@bogus_address.con
On 2000-01-15 sjdub...@internetni.com said:
>Umm, Int 13 fn 8...return disk drive para. -- as I understand is
>only available on the AT class.
Not entirely true. Interrupt 13h, Function 8 is supported on all IBM-
compatibles from the XT upwards. The original PC ROM BIOS is the only
one that doesn't support it at all.
The only part of Function 8 that's AT-specific is 'return floppy drive
type' (in BL)...which isn't used in CP/M-86, anyway.
>11DC:3C05 CALL 3E9C ;;subr-c
>11DC:3C08 MOV AH,08
>11DC:3C0A MOV DL,80
>11DC:3C0C INT 13 ;;bios int13 serv8, return fixed disk drive
>parameters.
>11DC:3C0E MOV AL,DL ;; [AT computers], if CY, AH holds stat bits
>|dl=#consecutive drives
>11DC:3C10 POP DX
>--from the offset 2500, bios jmp table
I believe you'll find that this code snippet is merely checking to see
if a hard drive is =present= in the system. CP/M-86 doesn't really
care about the parameters of the hard disk.
>I think there's a media byte at the end of the first sector which
>distinguishes between SS and DS media --ref. John Elliot's website.
Then I suppose you could choose a different but adjacent location on
the floppy to use as =your= media byte to indicate high density.
Or you could just not bother with it at all.
During boot-up, you could check to see if you're dealing with a 286 or
higher processor...and if so, call INT 13h, FUNC 17h (this call =is=
AT-specific). The call returns the floppy drive parameters, which you
would then pass to the O.S.
Of course, if a 286-or-higher processor were =not= found, you'd simply
assume you were dealing with a PC/XT class machine, and use the existing
CP/M-86 code.
The only contingency this wouldn't cover is the extremely rare PC or XT
with high-density floppy drives. It =is= possible to install high
density floppies in a PC and XT, but it's a most unusual aftermarket
hardware 'tweak'...and probably rare enough that it could be ignored.
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:85s0hk$rk8$2...@q.seanet.com...
>
> On 2000-01-15 sjdub...@internetni.com said:
>
> >Umm, Int 13 fn 8...return disk drive para. -- as I understand is
> >only available on the AT class.
>
> Not entirely true. Interrupt 13h, Function 8 is supported on all IBM-
> compatibles from the XT upwards. The original PC ROM BIOS is the only
> one that doesn't support it at all.
>
> The only part of Function 8 that's AT-specific is 'return floppy drive
> type' (in BL)...which isn't used in CP/M-86, anyway.
>
> >I think there's a media byte at the end of the first sector which
> >distinguishes between SS and DS media --ref. John Elliot's website.
>
> Then I suppose you could choose a different but adjacent location on
> the floppy to use as =your= media byte to indicate high density.
>
> Or you could just not bother with it at all.
>
> During boot-up, you could check to see if you're dealing with a 286 or
> higher processor...and if so, call INT 13h, FUNC 17h (this call =is=
> AT-specific). The call returns the floppy drive parameters, which you
> would then pass to the O.S.
>
> Of course, if a 286-or-higher processor were =not= found, you'd simply
> assume you were dealing with a PC/XT class machine, and use the existing
> CP/M-86 code.
>
> The only contingency this wouldn't cover is the extremely rare PC or XT
> with high-density floppy drives. It =is= possible to install high
> density floppies in a PC and XT, but it's a most unusual aftermarket
> hardware 'tweak'...and probably rare enough that it could be ignored.
>
I think this is the best avenue to pursue. I'll have to research this
further. The odds are getting remote of finding a pre '486 computer still
in service.
The cp/m-86 bootloader presumes the diskette having 8- 512 byte physical
sectors on the 1st, reserved, track [track zero].
Thanks,
Steve
anon...@bogus_address.con
On 2000-01-20 sjdub...@internetni.com said:
>Thanks for the info.
No sweat.
>I think this is the best avenue to pursue. I'll have to research
>this further. The odds are getting remote of finding a pre '486
>computer still in service.
You might be surprised. I think you'll find that there are =still=
millions of functional 386s out there. :)
>The cp/m-86 bootloader presumes the diskette having 8- 512 byte
>physical sectors on the 1st, reserved, track [track zero].
That may or may not present a problem. But you might need a custom
high-capacity floppy disk formatter.
I don't recall if the IBM permutation of DSKMAINT.CMD has the disk
parameters hard-coded, or if it picks up that info from the O.S.
Maybe one of the former D.R.I. guys who lurk this newsgroup might
remember.
Steve Dubrovich
> >The cp/m-86 bootloader presumes the diskette having 8- 512 byte
> >physical sectors on the 1st, reserved, track [track zero].
>
> That may or may not present a problem. But you might need a custom
> high-capacity floppy disk formatter.
>
it's finicky about the presents of a BPB on the diskette.
> I don't recall if the IBM permutation of DSKMAINT.CMD has the disk
> parameters hard-coded, or if it picks up that info from the O.S.
>
> Maybe one of the former D.R.I. guys who lurk this newsgroup might
> remember.
>
Would you happen to know where the line is between the rombios recognition
of diskette media and the requirement for the msdos BPB on a msdos
diskette??
From what I've read, cpm-86 has the benefit of a default media structure
embedded in the rombios and I wonder if any other disk densities are
available thru the rombios other than using the msdos BPB structure on the
msdos boot record itself.
BTW, any idea who Dean Ballard is??
A funny thing happened on the way to the disassembly today.
I found that the secondary bootstrap traps for a question mark in the
keyboard buffer, so I tried booting cp/m86 while tapping in the question
mark on the keyboard several times, near the end of the POST routine and
just up until cp/m86 is read off the diskette. Lo and behold, there is a
nice little message from Dean Ballard that pops on the screen!
Steve
anon...@bogus_address.con
On 2000-01-21 sjdub...@internetni.com said:
>I think I maybe able to use messydos's debug to do the initial few,
>unless it's finicky about the presence of a BPB on the diskette.
If necessary, you could always zap the disk.
>Would you happen to know where the line is between the rombios
>recognition of diskette media and the requirement for the msdos BPB
>on a msdos diskette??
Not certain I fully understand your question. The ROM BIOS doesn't
recognize =media= at all; only hardware.
AT-class machines (286 and up) store the CMOS set-up information, in-
cluding the floppy drive parameters, in the bytes at addresses 40:10h
and 40:13h.
But this info is obtained by the BIOS during the Power-On Self Test
(POST); it's not hard-coded in ROM.
>From what I've read, cpm-86 has the benefit of a default media
>structure embedded in the rombios...
Ummm...better double-check this info.
First of all, I can find no references to 'media structure' being con-
tained anywhere in the ROM BIOS.
Secondly, as you know, CP/M-86 For The IBM Version 1.1 was designed
strictly for use on PC- and XT-class machines...which used only 40-track,
5.25-inch double-density drives.
>...and I wonder if any other disk
>densities are available thru the rombios other than using the msdos
>BPB structure on the msdos boot record itself.
The byte at address 40:8Fh tells you the number of tracks (40 or 80) of
drives A: and B:. The four bytes at address 40:90h show the data transfer
rates for the floppy drives.
From this info, you can infer that a certain drive is 360k, 1.2M, etc.
Not sure if this is really helpful to you, though.
>BTW, any idea who Dean Ballard is??
>A funny thing happened on the way to the disassembly today.
>I found that the secondary bootstrap traps for a question mark in
>the keyboard buffer, so I tried booting cp/m86 while tapping in the
>question mark on the keyboard several times, near the end of the
>POST routine and just up until cp/m86 is read off the diskette. Lo
>and behold, there is a nice little message from Dean Ballard that
>pops on the screen!
Heh! I'd forgotten about that little 'Easter egg' in CP/M-86. :)
Ballard was undoubtedly a Digital Research code jockey.
Another bit of trivia: that 'Easter egg' is only accessible when booting
from the CP/M-86 =floppy= disk; it's not in the hard disk boot code.
Steve Dubrovich
> >Would you happen to know where the line is between the rombios
> >recognition of diskette media and the requirement for the msdos BPB
> >on a msdos diskette??
>
> Not certain I fully understand your question. The ROM BIOS doesn't
> recognize =media= at all; only hardware.
>
msDos's
file system. hmm, so I don't need to be concerned for it for cp/m86 on
higher disk densities.
> AT-class machines (286 and up) store the CMOS set-up information, in-
> cluding the floppy drive parameters, in the bytes at addresses 40:10h
> and 40:13h.
>
> But this info is obtained by the BIOS during the Power-On Self Test
> (POST); it's not hard-coded in ROM.
>
> >From what I've read, cpm-86 has the benefit of a default media
> >structure embedded in the rombios...
>
> Ummm...better double-check this info.
Yes, what i've read was misleading on this, per further research.
>
> First of all, I can find no references to 'media structure' being con-
> tained anywhere in the ROM BIOS.
>
> Secondly, as you know, CP/M-86 For The IBM Version 1.1 was designed
> strictly for use on PC- and XT-class machines...which used only 40-track,
> 5.25-inch double-density drives.
>
> >...and I wonder if any other disk
> >densities are available thru the rombios other than using the msdos
> >BPB structure on the msdos boot record itself.
>
> The byte at address 40:8Fh tells you the number of tracks (40 or 80) of
> drives A: and B:. The four bytes at address 40:90h show the data transfer
> rates for the floppy drives.
>
> From this info, you can infer that a certain drive is 360k, 1.2M, etc.
> Not sure if this is really helpful to you, though.
>
Thanks, I was confused about how that all worked, and I didn't phrase my
question well - It's been along time since I've had a look at that stuff.
I've refreshed my memory with some reference material, and I see that each
disk sector, when it is formatted, receives a sector header on the disk at
the beginning of each sector data area, by the format program, that includes
such stuff as that records' logical address, bytes per sector, CRC check,
etc. And the bios has basically enough info off of that to decipher reading
the disk, as to sector interleave, and such. And the controller hardware
can tell from the drive itself, the drive's maximum characteristics, which
the bios is able to query from the controller hardware. But there doesn't
seem to be an automatic way to tell if a recently inserted disk is of a
lower capacity, that seems to be left up to the programmer decipher [on the
5 1/4, the 3 1/2 has the media hole in the diskette case]. I was able to
use ms debug today to read in off a cpm86 disk, the boot sector off track0,
and test reading of a 9th sector per track, which of course is non-existant,
and hense returns an error, one way to test for a specific sized disk in the
drive. I used the bios routines to do this so I think I've got those issues
framed, enough of a handle on them anyway, for now.
Thanks
> >BTW, any idea who Dean Ballard is??
> >A funny thing happened on the way to the disassembly today.
> >I found that the secondary bootstrap traps for a question mark in
> >the keyboard buffer, so I tried booting cp/m86 while tapping in the
> >question mark on the keyboard several times, near the end of the
> >POST routine and just up until cp/m86 is read off the diskette. Lo
> >and behold, there is a nice little message from Dean Ballard that
> >pops on the screen!
>
> Heh! I'd forgotten about that little 'Easter egg' in CP/M-86. :)
> Ballard was undoubtedly a Digital Research code jockey.
>
> Another bit of trivia: that 'Easter egg' is only accessible when booting
> from the CP/M-86 =floppy= disk; it's not in the hard disk boot code.
>
Is HDMAINT.cmd geared toward a certain sized hard drive??
Steve
anon...@bogus_address.con
On 2000-01-23 sjdub...@internetni.com said:
>And I see the Bios has nothing much to with the BPB, its a creature
>of msDos's file system. hmm, so I don't need to be concerned for it
>for cp/m86 on higher disk densities.
Correct. You can disregard anything related to DOS; it won't be
relevant.
>Thanks, I was confused about how that all worked, and I didn't
>phrase my question well - It's been along time since I've had a
>look at that stuff. I've refreshed my memory with some reference
>material, and I see that each disk sector, when it is formatted,
>receives a sector header on the disk at the beginning of each
>sector data area, by the format program, that includes such stuff
>as that records' logical address, bytes per sector, CRC check, etc.
>And the bios has basically enough info off of that to decipher
>reading the disk, as to sector interleave, and such. And the
>controller hardware can tell from the drive itself, the drive's
>maximum characteristics, which the bios is able to query from the
>controller hardware. But there doesn't seem to be an automatic way
>to tell if a recently inserted disk is of a lower capacity, that
>seems to be left up to the programmer decipher [on the 5 1/4...
That's one of the reasons why the media ID byte is there in DOS. :)
>...the 3 1/2 has the media hole in the diskette case]. I was able to
>use ms debug today to read in off a cpm86 disk, the boot sector off
>track0, and test reading of a 9th sector per track, which of course
>is non-existant, and hense returns an error, one way to test for a
>specific sized disk in the drive. I used the bios routines to do
>this so I think I've got those issues framed, enough of a handle on
>them anyway, for now.
Okay, just remember that CP/M-86 formats -- and uses -- a floppy disk
in a manner that's different from DOS.
DOS alternates disk sides with each track (Side 0, Trk 0; Side 1, Trk 0,
etc.). CP/M-86 doesn't.
CP/M-86 starts with Side 0, Track 0 and uses all tracks consecutively on
Side 0...=then= goes to Side 1, Track 0, and uses all tracks consecutively
on Side 1.
>Is HDMAINT.cmd geared toward a certain sized hard drive??
The size of the hard drive is pretty much immaterial to CP/M-86. It's the
=partition= side that's relevant.
CP/M-86 For The IBM supports a maximum partition size of 8192k (8 megabytes).
The minimum partition size it supports is 10 cylinders.
HDMAINT.CMD enforces these O.S. parameters, and won't let you create a
partition that doesn't conform to those specs.
One potential problem: the fancy track-and-sector translation that's done
in the hardware on some of the super-huge contemporary hard disks can
sometimes confuse CP/M-86, and prevent a CP/M-86 partition from being
created. I've run into several cases of this. It's not REAL common yet,
but it =can= happen.
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:86gs7r$c64$1...@q.seanet.com...
> That's one of the reasons why the media ID byte is there in DOS. :)
>
> >...the 3 1/2 has the media hole in the diskette case]. I was able to
> >use ms debug today to read in off a cpm86 disk, the boot sector off
> >track0, and test reading of a 9th sector per track, which of course
> >is non-existant, and hense returns an error, one way to test for a
The sector is non-existant because the disk was formatted for cp/m86, tho
the actual capacity of that 3 1/2 disk is 18 sectors per track, a 1.44
floppy, 15 SPT on a 1.2 m 5 1/4, I meant to mention for clarification.
> >specific sized disk in the drive. I used the bios routines to do
> >this so I think I've got those issues framed, enough of a handle on
> >them anyway, for now.
>
> Okay, just remember that CP/M-86 formats -- and uses -- a floppy disk
> in a manner that's different from DOS.
>
> DOS alternates disk sides with each track (Side 0, Trk 0; Side 1, Trk 0,
> etc.). CP/M-86 doesn't.
That seems like it should be more efficient because, on the face of it, it
would seem that the heads would not be moving [tracking] as much.
>
> CP/M-86 starts with Side 0, Track 0 and uses all tracks consecutively on
> Side 0...=then= goes to Side 1, Track 0, and uses all tracks consecutively
> on Side 1.
>
actually it seems, from what I've gathered from the secondary bootloader
disassembly, that cpm reads from side 0, outermost track toward the
innermost, the switches to side 1, reading from the current innermost track
and continues back toward the outermost track.
> >Is HDMAINT.cmd geared toward a certain sized hard drive??
>
> The size of the hard drive is pretty much immaterial to CP/M-86. It's the
> =partition= side that's relevant.
>
> CP/M-86 For The IBM supports a maximum partition size of 8192k (8
Megabytes).
> The minimum partition size it supports is 10 cylinders.
>
> HDMAINT.CMD enforces these O.S. parameters, and won't let you create a
partition
> that doesn't conform to those specs.
>
But can you create an 8meg partition each for [cpm's] C:, D: and for an E:
drive, and so on, as well?
> One potential problem: the fancy track-and-sector translation that's done
> in the hardware on some of the super-huge contemporary hard disks can
> sometimes confuse CP/M-86, and prevent a CP/M-86 partition from being
> created. I've run into several cases of this. It's not REAL common yet,
> but it =can= happen.
>
If I create a non-dos partition, will HDMAINT recognize it and format it, I
don't have any documentation for how HDMAINT works, or what I have to do to
prepare, to prepare to use it.
Perhaps some boot manager utility would be required to manage dual booting.
Steve
anon...@bogus_address.con
On 2000-01-24 sjdub...@internetni.com said:
>But can you create an 8meg partition each for [cpm's] C:, D: and
>for an E: drive, and so on, as well?
If you're speaking of =extended= partitions on the same PHYSICAL hard
disk, then the answer is no. CP/M-86 For The IBM Version 1.1 doesn't
know about extended partitions.
If you're speaking of separate physical hard disks, then the answer is
a qualified yes. CP/M-86 can recognize, and create a usable partition
on, up to =2= different physical hard disks. But not more than 2.
>If I create a non-dos partition, will HDMAINT recognize it and
>format it...
No. The CP/M-86 partition must be created by HDMAINT.CMD itself.
>...I don't have any documentation for how HDMAINT works, or
>what I have to do to prepare, to prepare to use it.
No preparation required. Just invoke HDMAINT.CMD, and go for it.
HDMAINT.CMD is menu-driven and interactive. It's also extremely
intuitive; it won't present you with any on-screen options that
aren't applicable to your system's particular situation.
Of course, you MUST have some =unallocated= space available on the
hard disk. If you've already allocated all available HD space to
another O.S. partition, then you're naturally not gonna be able
to create a CP/M-86 partition! :)
When setting up a CP/M-86 partition, I prefer to start with a "clean"
(empty) hard disk, and make CP/M-86 the first partition on the disk.
Using HDMAINT, I create the CP/M-86 partition, make it active, format
the partition, and copy all the O.S. files to User 0 of the hard disk.
Then I boot from a floppy disk into the next desired O.S., and use its
native tools to create another bootable HD partition.
>Perhaps some boot manager utility would be required to manage dual
>booting.
No, that's not necessary. You can change the active bootable partition
using the native utility for whatever O.S. is currently running (in DOS,
you'd use FDISK; in CP/M-86, you'd use HDMAINT).
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:86imb9$f6d$1...@q.seanet.com...
>
> On 2000-01-24 sjdub...@internetni.com said:
>
> >But can you create an 8meg partition each for [cpm's] C:, D: and
> >for an E: drive, and so on, as well?
>
> If you're speaking of =extended= partitions on the same PHYSICAL hard
> disk, then the answer is no. CP/M-86 For The IBM Version 1.1 doesn't
> know about extended partitions.
>
> If you're speaking of separate physical hard disks, then the answer is
> a qualified yes. CP/M-86 can recognize, and create a usable partition
> on, up to =2= different physical hard disks. But not more than 2.
>
As it turns out, the 486 I'm using for this development has two physical
drives.
> >If I create a non-dos partition, will HDMAINT recognize it and
> >format it...
>
> No. The CP/M-86 partition must be created by HDMAINT.CMD itself.
>
> >...I don't have any documentation for how HDMAINT works, or
> >what I have to do to prepare, to prepare to use it.
>
> No preparation required. Just invoke HDMAINT.CMD, and go for it.
> HDMAINT.CMD is menu-driven and interactive. It's also extremely
> intuitive; it won't present you with any on-screen options that
> aren't applicable to your system's particular situation.
>
> Of course, you MUST have some =unallocated= space available on the
> hard disk. If you've already allocated all available HD space to
> another O.S. partition, then you're naturally not gonna be able
> to create a CP/M-86 partition! :)
>
One thing I never liked about how Dos handled that 2 drive system was to
make drive 0 the C: drive, drive 1 the D: drive following the rest of the
drive designations from the extended partitions first from drive 0, then
drive 1.
> When setting up a CP/M-86 partition, I prefer to start with a "clean"
> (empty) hard disk, and make CP/M-86 the first partition on the disk.
> Using HDMAINT, I create the CP/M-86 partition, make it active, format
> the partition, and copy all the O.S. files to User 0 of the hard disk.
>
> Then I boot from a floppy disk into the next desired O.S., and use its
> native tools to create another bootable HD partition.
>
> >Perhaps some boot manager utility would be required to manage dual
> >booting.
>
> No, that's not necessary. You can change the active bootable partition
> using the native utility for whatever O.S. is currently running (in DOS,
> you'd use FDISK; in CP/M-86, you'd use HDMAINT).
>
Good points, all.
The only caveat, I think, is the system is an EISA buss system with SCSI
controller and 2 SCSI drives, something HDMAINT probably isn't prepared
for?? It is not set up as a RAID storage system, er never was, tho I think
the Adaptec controller is capable of it.
Have you had any luck setting up cp/m86 on a system such as this??
I'd mostly want to set up cp/m86 on the second drive only, anyhow.
Thanks for the good info.
Steve
anon...@bogus_address.con
On 2000-01-24 sjdub...@internetni.com said:
>The only caveat, I think, is the system is an EISA buss system with
>SCSI controller and 2 SCSI drives, something HDMAINT probably isn't
>prepared for??
It doesn't care much about such things. HDMAINT.CMD uses ROM BIOS calls
to access the hard disk. If the disk can be successfully approached in
that manner, then HDMAINT should be able to create and format a partition.
And CP/M-86 will use it happily.
>It is not set up as a RAID storage system, er never was, tho I think
>the Adaptec controller is capable of it. Have you had any luck setting
>up cp/m86 on a system such as this??
Sure, as long as the hardware track/sector translation that's occurring
isn't too far out to lunch. I've created CP/M-86 partitions on MFM, RLL,
IDE, EIDE and SCSI hard disks with rarely a problem.
The odd problems I've encountered have invariably been caused by those few
highly proprietary, oh-boy hot-stuff new-and-now controllers that are doing
really weird, non-standard things with the hard disk.
If your Adaptec is one of those problematic controllers, HDMAINT will let
you know by failing to create the partition.
>I'd mostly want to set up cp/m86 on the second drive only, anyhow.
That's a problem. CP/M-86 will only =boot= from the first physical hard disk.
Still, you could boot from a floppy disk...and once the system has booted,
you could then access a CP/M-86 partition on the second hard disk.
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:86jati$gst$1...@q.seanet.com...
>
> >I'd mostly want to set up cp/m86 on the second drive only, anyhow.
>
> That's a problem. CP/M-86 will only =boot= from the first physical hard
disk.
>
> Still, you could boot from a floppy disk...and once the system has booted,
> you could then access a CP/M-86 partition on the second hard disk.
>
That's a reasonable solution. Time to some HD housecleaning, perhaps I can
give this a try this weekend.
Thanks again,
Steve
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:86gs7r$c64$1...@q.seanet.com...
> >Is HDMAINT.cmd geared toward a certain sized hard drive??
>
> The size of the hard drive is pretty much immaterial to CP/M-86. It's the
> =partition= side that's relevant.
>
> CP/M-86 For The IBM supports a maximum partition size of 8192k (8
megabytes).
> The minimum partition size it supports is 10 cylinders.
>
> HDMAINT.CMD enforces these O.S. parameters, and won't let you create a
> partition that doesn't conform to those specs.
>
> One potential problem: the fancy track-and-sector translation that's done
> in the hardware on some of the super-huge contemporary hard disks can
> sometimes confuse CP/M-86, and prevent a CP/M-86 partition from being
> created. I've run into several cases of this. It's not REAL common yet,
> but it =can= happen.
>
I've run into a snag here. My scsi HD 0 is 521cylinders. My scsi HD 1 is
1035 cylinders, a 1 gig drive. HDMAINT sees the 521 cylinders of HD 0, but
reports only 132 cylinders of HD 1, my first clue of a problem. Worse,
HDMAINT, in trying to create a cpm86 volume on HD 1, mentions the 10
cylinder minimum requirement, but calculates a maximum limit of 5 cylinders
for its maximum size warning for a cpm86 volume, a second clue of a problem.
No matter what number I pick for # of cylinders to use; 10, 5, 1, or
inbetween, I get one of three results; the drive isn't recognized at all
when cpm boots, or a bootup msg that the cpm volume is too large, or a
divide by zero error from 91EF:1417. HDMAINT will create those volumes but
cpm86 chokes on it somewhere in its' cbios recognition and
initialization. -I guess another reason to update [modify] the cBIOS.
I've had moderate success with HD 0. HDMAINT correctly sees the number of
cylinders, and I've successfully created a 10 cylinder cpm86 volume. I was
also able to pip cpm.sys over to it as the first file, and use HDMAINT to
mark the cpm86 volume as bootable, and it'll bootup! The weird problem I
have is this: no .CMD program will run from the HD! Not pip, hdmaint, asm86,
stat, -nothing-, they attempt to load and then just hang!! After i've
pip'ed them over I've checked them with stat from floppy drive A, and they
seem to be all OK. I can pip over text files OK, I've TYPEd them out OK. I
can use ASM86 off of drive A: with the source on the HD and the result files
to the HD with no problem, I just can't run any executables off the HD,
except cpm.sys obviously loads and executes. [Hmm, as I'm writing this, I'm
getting suspicious of a EOF problem with the executables - hmm, is the cpm
volume properly formated??].
---------
re: track 0, sector 1 - initial boot loader
I see it is still resident after coldbooting and running DDT86 right away,
and can be found by DDT at 0000:07c0, the rombios load point. The last 5
bytes before the data messages area are the far jmp address to the secondary
loader [4 bytes] 00 01 00 9E and the disk read retry count [1 byte], FWIW.
Steve
anon...@bogus_address.con
On 2000-01-29 sjdub...@internetni.com said:
>I've run into a snag here. My scsi HD 0 is 521cylinders. My scsi
>HD 1 is 1035 cylinders, a 1 gig drive. HDMAINT sees the 521
>cylinders of HD 0, but reports only 132 cylinders of HD 1, my first
>clue of a problem. Worse, HDMAINT, in trying to create a cpm86
>volume on HD 1, mentions the 10 cylinder minimum requirement, but
>calculates a maximum limit of 5 cylinders for its maximum size
>warning for a cpm86 volume, a second clue of a problem. No matter
>what number I pick for # of cylinders to use; 10, 5, 1, or
>inbetween, I get one of three results; the drive isn't recognized
>at all when cpm boots, or a bootup msg that the cpm volume is too
>large, or a divide by zero error from 91EF:1417. HDMAINT will
>create those volumes but cpm86 chokes on it somewhere in its' cbios
>recognition and initialization.
Okay, then that's probably one of those hard drives I previously
mentioned...where the hardware sector/track translation is simply
beyond the ken of HDMAINT.
Which is understandable. After all, CP/M-86 For The IBM version 1.1
was released in 1983. It was designed to use hard disks which had a
maximum size of, maybe, 120 megs!
>I've had moderate success with HD 0. HDMAINT
>correctly sees the number of cylinders, and I've successfully
>created a 10 cylinder cpm86 volume. I was also able to pip cpm.sys
>over to it as the first file, and use HDMAINT to mark the cpm86
>volume as bootable, and it'll bootup! The weird problem I have is
>this: no .CMD program will run from the HD! Not pip, hdmaint, asm86,
>stat, -nothing-, they attempt to load and then just hang!! After
>i've pip'ed them over I've checked them with stat from floppy drive
>A, and they seem to be all OK. I can pip over text files OK, I've
>TYPEd them out OK. I can use ASM86 off of drive A: with the source
>on the HD and the result files to the HD with no problem, I just
>can't run any executables off the HD, except cpm.sys obviously
>loads and executes.
That's mighty weird. Have never encountered that problem of hang-on-
execution, and have no idea what might be going on.
>[Hmm, as I'm writing this, I'm getting
>suspicious of a EOF problem with the executables - hmm, is the cpm
>volume properly formated??]. ---------
I'm e-mailing you a diagnostic that will help you determine that. Use
it to look at an executable file at the byte level on the hard disk, to
see if the file is all there. Compare it with a known-good copy of the
same file on a floppy disk.
>re: track 0, sector 1 - initial boot loader
>I see it is still resident after coldbooting and running DDT86
>right away, and can be found by DDT at 0000:07c0, the rombios load
>point. The last 5 bytes before the data messages area are the far
>jmp address to the secondary loader [4 bytes] 00 01 00 9E and the
>disk read retry count [1 byte], FWIW.
When a program that you try to execute from the hard disk 'hangs,' does
the time-of-day clock on the status line freeze, or does it keep running?
If the time-of-day freezes, you're dead. But if the seconds keep ticking,
you should be able to recover. What happens when you press CTRL-BREAK?
Steve Dubrovich
<anonymous@bogus_address.con> wrote in message
news:86vja0$avt$1...@q.seanet.com...
Okay, then that's probably one of those hard drives I previously
> mentioned...where the hardware sector/track translation is simply
> beyond the ken of HDMAINT.
>
> Which is understandable. After all, CP/M-86 For The IBM version 1.1
> was released in 1983. It was designed to use hard disks which had a
> maximum size of, maybe, 120 megs!
>
increases.
> That's mighty weird. Have never encountered that problem of hang-on-
> execution, and have no idea what might be going on.
>
> >[Hmm, as I'm writing this, I'm getting
> >suspicious of a EOF problem with the executables - hmm, is the cpm
> >volume properly formated??]. ---------
>
> I'm e-mailing you a diagnostic that will help you determine that. Use
> it to look at an executable file at the byte level on the hard disk, to
> see if the file is all there. Compare it with a known-good copy of the
> same file on a floppy disk.
>
Thanks, received it ok. Using Stat again as the test, FV shows file
integrity between a:stat and HD c:stat . I also found DU-V75A.CMD off the
Oak Software Lib and was able to do abit with it, it's hard to use but at
least I know the unwritten areas on the HD outer tracks hold the E5 filler
byte so I figure the format was done properly. So an EOF problem seems less
likely. It's rather tedious to use to locate exactly where a certain file
should end on a given track and sector, hmmm.
>
> When a program that you try to execute from the hard disk 'hangs,' does
> the time-of-day clock on the status line freeze, or does it keep running?
>
I keeps on running. When I type a command, say c:stat <cr> the cursor goes
to the beginning of the next line, then nothing more happens.
> If the time-of-day freezes, you're dead. But if the seconds keep ticking,
> you should be able to recover. What happens when you press CTRL-BREAK?
>
You're right! I get the : *** User Program Break *** msg in the status line
and am able to recover! Thanks for that tip. [CTRL] - [PAUSE/break] keys.
Hmm, I'm running out of time I can devote to this for awhile. I guess this
problem goes to the back burner. At least I can use the HD to store data
files which is an improvement over being limited to just two floppies.
Thanks again, I've learned alot and covered quite abit of new ground.
Steve
anon...@bogus_address.con
On 2000-01-29 sjdub...@internetni.com said:
>Thanks, received it ok. Using Stat again as the test, FV shows file
>integrity between a:stat and HD c:stat . I also found DU-V75A.CMD
>off the Oak Software Lib and was able to do abit with it, it's hard
>to use but at least I know the unwritten areas on the HD outer
>tracks hold the E5 filler byte so I figure the format was done
>properly. So an EOF problem seems less likely.
Yes; I doubt that it's an EOF problem. Something else is going on.
>It's rather tedious to use to locate exactly where a certain file
>should end on a given track and sector, hmmm.
Yeah, DU is extremely cumbersome. But FileView is quite handy. It's
a 'Norton Utilities' for CP/M-86, and lets you quickly examine (and
edit) a file at the byte level. It was fairly recently put into the
public domain by the author, and is a most valuable addition to the
growing body of third-party CP/M-86 software.
>You're right! I get the : *** User Program Break *** msg in the
>status line and am able to recover! Thanks for that tip. [CTRL] -
>[PAUSE/break] keys.
Good. At least you won't have to reboot every time a program 'hangs.' :)
>Hmm, I'm running out of time I can devote to this for awhile. I
>guess this problem goes to the back burner. At least I can use the
>HD to store data files which is an improvement over being limited
>to just two floppies.
>Thanks again, I've learned alot and covered quite abit of new
>ground.
Okay. Well, let us know when you're ready to dive back into it. With a
little more research, we can undoubtedly come up with a solution to your
problem. I'm convinced it's probably something very simple. Have fun!
bru...@hotmail.com
than 128K in CP/M-86? I've got the source code to CP/M-86, but I don't
know where to go from there...this is the IBM PC version.
Alan
Sent via Deja.com http://www.deja.com/
Before you buy.
anon...@bogus_address.con
On 2000-02-19 bru...@hotmail.com said:
>Hello, is there a patch to increase the amount of available memory
>more than 128K in CP/M-86? I've got the source code to CP/M-86,
>but I don't know where to go from there...this is the IBM PC
>version.
>Alan
CP/M-86 For The IBM Version 1.1 recognizes and uses all low memory
up to 640k, when run on a conventional IBM or clone.
Digital Research never released the complete source for the IBM
version of CP/M-86, so what you have is probably a later disassembly.
If the problem you're having is with a rendition that you compiled
yourself from this "source," the code may be defective.
However, if you're using an original DRI compilation of CP/M-86, and
it's still only recognizing 128k, something else might be going on.
What exactly does the sign-on message say when you first boot the O.S.?
If, indeed, the message says "CP/M-86 For The IBM PC and PC XT Version
1.1," then you might begin to suspect a hardware problem.
Tell us about the machine you're attempting to run it on.
But if what you're running is "Concurrent CP/M-86," "Personal CP/M-86,"
or a non-IBM version, that's an entirely different kettle of fish.
Let us know =precisely= what you have. Be absolutely specific. We can
undoubtedly help you, but need =exact= information.
Barry Watzman
I like that.
The doctors are in.
Barry A. Watzman, C.M.D. (computer M.D.)
has a nice ring to it, but the pay sucks
anon...@bogus_address.con
On 2000-02-22 Wat...@neo.rr.com said:
>"We can undoubtedly help you, but need =exact= information."
>I like that.
>The doctors are in.
>Barry A. Watzman, C.M.D. (computer M.D.)
>has a nice ring to it, but the pay sucks
Heh! THAT'S the truth. <g>
But hey...with all the new CP/M-86 software developments that have
occurred over the past six years (such as the AT patch, a civilized
DOS-style text editor, graphical file viewers, 'mouse-able' software,
the Y2K patch, etc.), =somebody= has to help keep CP/M-86 alive! :)
When the rest of the world has ultimately crashed under The Blue Screen
Of Death, and DOS has been lost to antiquity, we'll still be putzin' along
..doing our thing in =real= mode.