15 Mar
2001
15 Mar
'01
3:24 p.m.
From: Sean 'Captain Napalm' Conner <spc(a)conman.org>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Thursday, March 15, 2001 7:54 PM
Subject: Re: The DOS 10 Commandments (fwd)
allocated
space
would
It's really a hardware thing. Dos and most other OSs all see it and
have an option to do what they care to. The real point is that RESET
became the defacto solution for flakey code most of it outside DOS.
It was thus said that the Great Peter Joules once
stated:
> 3)
> Thy hard disk shall never have more than 1024 sectors. You don't need
that
much space
anyway.
That's a BIOS limitation; talk to IBM about that one---they only 10 bits for sector number in the INT 13h disk IO call.
Wrong. 1024 was a hardware limitation of the early MFM controller cards
and the bios honored it. FYI it was CYLINDERS not sectors. 1024 sectors
would have only been 512k!
> 4)
> Thy application program and data shall all fit in 640K of RAM. After
all,
> it's ten times what you had on a CP/M machine.
Keep holy this 640K of
RAM,
> and clutter it not with device drivers, memory
managers, or other
things
that might
make thy computer useful.
Again, IBM is to fault for that one---the IBM PC reserved the memory above $A0000 for video and BIOS extentions. There have
been
PCompatibles
running MS-DOS that had more memory available, but only
programs that
used
MS-DOS exclusively would work on those machines.
Other non -PC hardware such as Rainbow went out to 896k and some of the
S100
based machines did the full meg using shadow rom.
> 5)
> Thou shall use the one true slash character to separate thy directory
path.
Thou shall
learn and love this character, even though it appears on no
typewriter keyboard, and is unfamiliar. Standardization on where that
character is located on a computer keyboard is right out .
While COMMAND.COM would only accept `\' as a path separator, MS-DOS internally use both `/' and `\' for path
separators. There is an MS-DOS
call to change the option character (from the default of `/') but I
don't
remember what it was off the top of my head.
The other choise is the unix / or VMS [.....] form.
> 10)
> Learn well the Vulcan Nerve Pinch (ctrl-alt-del) for it shall be thy
saviour
> on many an occasion. Believe in thy heart that
everyone reboots their
OS to
solve problems
that shouldn't occur in the first place.
Isn't that more of a Windows thing than an MS-DOS thing? -spc (Doesn't remember MS-DOS crashing quite so
much ... )
DOS being unprotected could crash, usually after the application
wiped it from memory like CP/M! Any unprotected OS would be
vunerable to being smashed by a runaway app.
Experience with DOS 3.11 and 5.0 is that for an unprotected OS
it was fairly solid and not inclined to kill itself. I have two systems
that live as DOS with uptimes measured in months.
Allison
15 Mar
15 Mar
2:15 p.m.
From: "ajp166"
<ajp166(a)bellatlantic.net>
To: <classiccmp(a)classiccmp.org>
Subject: Re: The DOS 10 Commandments (fwd)
Date: Thu, 15 Mar 2001 21:24:13 -0500
Reply-to: classiccmp(a)classiccmp.org
From: Sean 'Captain Napalm' Conner
<spc(a)conman.org>
>It was thus said that the Great Peter Joules once stated:
>> 3)
snip
That's a
BIOS limitation; talk to IBM about that one---they only
allocated
10 bits for sector number in the INT 13h disk IO
call.
Wrong. 1024 was a hardware limitation of the early MFM controller cards
and the bios honored it. FYI it was CYLINDERS not sectors. 1024 sectors
would have only been 512k! > 4)
> Thy application program and data shall all fit in 640K of RAM. After
all,
Other non -PC hardware such as Rainbow went out to 896k and some of the
S100
based machines did the full meg using shadow rom.
Don't forget the >640K hack on many Zenith XT machines.
> 10)
> Learn well the Vulcan Nerve Pinch (ctrl-alt-del) for it shall be thy
saviour
> on many an occasion. Believe in thy heart
that everyone reboots their
OS to
>> solve problems that shouldn't occur in the first place.
>
> Isn't that more of a Windows thing than an MS-DOS thing? DOS being unprotected could crash, usually after the
application
wiped it from memory like CP/M! Any unprotected OS would be
vunerable to being smashed by a runaway app.
Correct. Even I can lock up that Eazy PC with one of own DOS command
found in that dos directory, remember those / by 0 error in 40
columns due to quirky V40 cpu in that thing.
Experience with DOS 3.11 and 5.0 is that for an
unprotected OS
it was fairly solid and not inclined to kill itself. I have two systems
that live as DOS with uptimes measured in months.
Correct again, when programs is done to quality standards, DOS is
utterly stable.
Allison
Wizard (old dos user)
8:55 p.m.
It was thus said that the Great jpero(a)sympatico.ca once stated:
Odd, that actually sounds like the program is jumping through a NULL
long pointer. On the Intel x86 platform, the first interrupt vector is the
Divide by 0 trap, and on the 8086/8088/80186, the vector table resides in
the first 1K of memory, so an address of $0000:0000 (or $00000 depending
upon how you write it) so jumping to that address gives the indication of a
divide by zero exception.
-spc (Remembers way more than he wants to 8-)
DOS being unprotected could crash, usually after
the application
wiped it from memory like CP/M! Any unprotected OS would be
vunerable to being smashed by a runaway app.
Correct. Even I can lock up that Eazy PC with one of own DOS command
found in that dos directory, remember those / by 0 error in 40
columns due to quirky V40 cpu in that thing. 
4:03 p.m.
Other non -PC hardware such as Rainbow went out to 896k
and some of the
S100
based machines did the full meg using shadow rom.
Two Tandy products that come to mind that could be take up to
768k are the Model 2000 and the 1000HX. The only real benefit for
doing it on either of them was for RAM disks though. Like the PCjr,
the 1000HX used part of it's RAM for the video adapter as well. Both
shipped with thier own specific versions of DOS 2.11.
Jeff
--
Collector of Classic Microcomputers and Video Game Systems:
Home of the TRS-80 Model 2000 FAQ File
http://www.geocities.com/siliconvalley/lakes/6757
16 Mar
16 Mar
3:29 a.m.
>Other non -PC hardware such as Rainbow went out to
896k and some of the
>S100 based machines did the full meg using shadow rom.
Two Tandy products that come to mind that could be
take up to
768k are the Model 2000 and the 1000HX. The only real benefit for
doing it on either of them was for RAM disks though. Like the PCjr,
the 1000HX used part of it's RAM for the video adapter as well. Both
shipped with thier own specific versions of DOS 2.11.
The eternal Siemens PC-D has up to 960 K continious DOS Mem (992 with
B&W Bios) ... ad 1024 K when using an inofficial Version and the
Character Grafics Adaptor (which was in fact an enhanced VT 220 on a
slot board :).
Gruss
H.
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
18 Mar
18 Mar
7:03 a.m.
At 10:03 PM 3/15/01 -0500, you wrote:
MOST of the non-IBM MS DOS machines could take up to 768k of RAM. The
Sanyo 550 and Zenith Z-100s both did. AFIK there's no limitations on using
that memory. I used the 768k in my Sanyo as normal RAM with no problems.
Both the Z-100 and Sanyo also had vendor specific MS-DOS and went to at
least version 2.11. I think they both went to DOS 3.1 or so but I'm not
positive about that. The Z-100 had separate video memory but the Sanyo used
part of it main RAM for video. That was one of the biggest reasons that it
wasn't IBM compatible. However Sanyo later came out with a plug in video
card that made the 550 video compatible with the IBM. You had to load a
device driver to re-direct the video to the card and you could then get
video output from both the standard video port and the port on the vdeo card.
Joe
Other non -PC
hardware such as Rainbow went out to 896k and some of the
S100
based machines did the full meg using shadow rom.
Two Tandy products that come to mind that could be take up to
768k are the Model 2000 and the 1000HX. The only real benefit for
doing it on either of them was for RAM disks though. Like the PCjr,
the 1000HX used part of it's RAM for the video adapter as well. Both
shipped with thier own specific versions of DOS 2.11. 
7:23 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1222 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20010318/f0a48b38/at…
8:08 a.m.
The DEC Rainbow could (officially) take 896K of RAM
(128K on the
motherboard and a memory expanison card with 3 banks of 256K chips). The
oriiginal Apricot could be pushed to 960K -- actually, there was 1Mbytes
worth of chips on the board but the last 64K was taken up with the
boot/BIOS ROM and the video memory.
The TRS-80 Model 2000 could be pushed to 896k but it wasn't
an official Tandy upgrade. Someone figured out how to rewire the
256k RAM expansion card to hold a full 640k. I don't believe anyone
ever did much with this other than use it as a RAM disk though.
Jeff
--
Collector of Classic Microcomputers and Video Game Systems:
Home of the TRS-80 Model 2000 FAQ File
http://www.geocities.com/siliconvalley/lakes/6757
15 Mar
15 Mar
4:31 p.m.
It was thus said that the Great ajp166 once stated:
allocated
Ah, that's what I get for not double checking the reference material. In
looking over it, it is indeed 10 bits for cylinder and six bits for sector
number.
I know all about that---I used to write code under MS-DOS (And the Tandy
Color Computer and AmigaOS, all unprotected (memory wise) systems).
Assembly code, no less.
It was thus said that the Great Peter Joules once
stated:
> 3)
> Thy hard disk shall never have more than 1024 sectors. You don't need
that
much
space anyway.
That's a BIOS limitation; talk to IBM about that one---they only 10 bits for sector number in the INT 13h disk IO
call.
Wrong. 1024 was a hardware limitation of the early MFM controller cards
and the bios honored it. FYI it was CYLINDERS not sectors. 1024 sectors
would have only been 512k! -spc
(Doesn't remember MS-DOS crashing quite so much ... )
DOS being unprotected could crash, usually after the application
wiped it from memory like CP/M! Any unprotected OS would be
vunerable to being smashed by a runaway app. Experience with DOS 3.11 and 5.0 is that for an
unprotected OS
it was fairly solid and not inclined to kill itself. I have two systems
that live as DOS with uptimes measured in months.
-spc (I never had any real problems with 2.11 either ... )
7:23 p.m.
On Thu, 15 Mar 2001, ajp166 wrote:
Experience with DOS 3.11 and 5.0 is that for an
unprotected OS
it was fairly solid and not inclined to kill itself. I have two systems
that live as DOS with uptimes measured in months.
It's all a matter of clean applications. The voicemail/auto-attendant
system (DOS-based) I use at home is one I designed, and there isn't a
single memory leak or null pointer write bug in it. It's completed and
totally debugged and never crashes. It stays up for months, and only gets
disturbed when I take it down to look in logs.
I built automated collect call systems (DOS based) in my previous life and
they were completely debugged as well. The only time the system ever went
down is when we took it down for PM. I think the record was 4 months
running, and it would've been longer but we took it down for PM. This was
a complex application too, doing voice processing, serial communications,
network datagrams over NetBIOS, etc.
DOS has always been solid, as long as your applications were debugged. It
was a good base upon which to build intensive system apps. You surely
can't say the same about Windows.
You can say the same about Linux :) My server has an uptime of 253 days.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
16 Mar
16 Mar
3:40 a.m.
> Experience with DOS 3.11 and 5.0 is that for an
unprotected OS
> it was fairly solid and not inclined to kill itself. I have two systems
> that live as DOS with uptimes measured in months.
It's all a matter of clean applications. The
voicemail/auto-attendant
system (DOS-based) I use at home is one I designed, and there isn't a
single memory leak or null pointer write bug in it. It's completed and
totally debugged and never crashes. It stays up for months, and only gets
disturbed when I take it down to look in logs.
[...] I think the record was 4 months
running, and it would've been longer but we took it down for PM. This was
a complex application too, doing voice processing, serial communications,
network datagrams over NetBIOS, etc.
You can say the same about Linux :) My server has an
uptime of 253 days.
Well, I did a dial in system for a fiels servis application - up
to 32 modem ports, where the laptop (8085 based Tandy M100, Nec
or Olivetti, later PCs) did some kind of APPC with one or more
main frame application - I had to do add a small multi tasking
system atop of DOS, and this baby did run quite fine on a 286
System .... maximum Uptime of one of the systems (they where
installed in several European countries) was a bit more than
THREE YEARS. And this machine in particular (in Spain) has only
been shutdown to be replaced by a new Unix system .... They needed
a 17,000 $ Hardware to replace my 3,000$ Sytem :))) and ... well,
communication was slower and a bit more line drops :))
Anyway, Dos can be a quite stable base.
Gruss
H.
P.S.: One of the features I still like most was the self debugging
version for 485/25 CPUs ... The app did singlestep itself in
real time. So I got finaly great traces wehn anything went
wrong - a feature known from some aminframe systems which I
still miss a lot in actual PC systems.
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
4:57 a.m.
New subject: VCF Question
Sam,
Last weekend I acquired from Eric Smith a VAX-785. What are the chances of
getting three-phase power at the upcoming VCF, and do you have a ball park
figure on cost? Moving the VAX again would be a huge pain, but I thought I'd
at least ask the most important gating question on exhibiting it (running of
course, why bother otherwise) at VCF.
BTW - you know Dag is leaving the History Center? :-(
Lee Courtney
President
Monterey Software Group Inc.
1350 Pear Avenue, Suite J
Mountain View, California 94043-1302 U.S.A.
650-964-7052 voice
650-964-6735 fax
Advanced Authentication, Audit, and Access Control Tools and Consulting for
HP3000 Business Servers
http://www.editcorp.com/Businesses/MontereySoftware
6:05 a.m.
New subject: Dag leaving? (was Re: VCF Question)
On Fri, 16 Mar 2001, Lee Courtney wrote:
BTW - you know Dag is leaving the History Center? :-(
Ummm... say what?!?!?!
-jim
---
jimw(a)agora.rdrop.com
The Computer Garage - http://www.rdrop.com/~jimw
Computer Garage Fax - (503) 646-0174
Note: the 'computergarage.org' domain is currently offline. The original
'Garage' site (URL above) is still out there and is currently being updated.
8:34 a.m.
New subject: SDI cabling question
Can someone enlighten me regarding DEC SDI cabling? Here's
what I have:
RA81 disk drive with two big black cables coming out of it, one for
each port (A/B). The cables terminate at the drive on one end and
at a small metal box on the other end. The small metal box has
two sockets on it (denoted with "*" in the picture below):
Small metal box
/
+----------+ "A" cable /
| RA81 |------------[]*
| Drive |------------[]*
+----------+ "B" cable
UDA50 controller in 11/44 with four sets of orange cables coming out
of it and terminating in a four-port socket set (denoted "*" in picture
below) in a larger metal box at the back of the cabinet:
Larger metal box
/
/
*[]_________
*[]_________\
*[]_________\\ <- Four (4) Cable groups
*[]_________\\\
\\\\
----------
| UDA50 |
| |
----------
What I have tried:
I unscrewed the black cables from the small metal box
and plugged one of them directly into one of the ports on
the larger metal box:
+----------+ "A" cable
| RA81 |----------------|
| Drive |----------[]* |
+----------+ "B" cable |
/ Larger metal box
/ /
| /
|-*[]_________
*[]_________\
*[]_________\\ <- Four (4) Cable groups
*[]_________\\\
\\\\
----------
| UDA50 |
| |
----------
That didn't work (I tried it with two different drives and cable sets).
The operating system (2.11BSD) sees the UDA50 but does not see the drive
(which is spun up and "ready").
I did a little searching on the internet and found a couple of
cryptic discussions. What I surmised from the discussions was that you
cannot directly connect the drive cable to the bulkhead box on the
computer cabinet. It seems you need a third cable to act as an
intermediary as such:
Small metal box
/
+----------+ "A" cable /
| RA81 |----------[]*---|
| Drive |----------[]* | <--- New THIRD ("external?") cable
+----------+ "B" cable |
/ Larger metal box
/ /
| /
|-*[]_________
*[]_________\
*[]_________\\ <- Four (4) Cable groups
*[]_________\\\
\\\\
----------
| UDA50 |
| |
----------
Is that right? If so, where can I find one of these external cables and/or
is it possible to manufacture one from a bit of ribbon cable an a
couple of commonly available plugs? The sockets denoted by "*" appear to
be AMD bastardizations of common PC board plugs like the ones one would
find connecting a console port plug.
Thanks!
greg
Gregory Travis
Cornerstone Information Systems ATS
greg(a)ciswired.com
812 330 4361 ext. 18
18 Mar
18 Mar
12:08 p.m.
New subject: SDI cabling question
"Gregory R. Travis" wrote:
Can someone enlighten me regarding DEC SDI cabling? Here's
what I have:
RA81 disk drive with two big black cables coming out of it, one for
Went thru a similar install last year, an RA72 array to a UDA50, and
had to use DEC BA26V cables between the boxes.
I picked another set of 4 BA26v-12's for my home Qbus system, project
I've since abandoned. If you need some or all of these let me know.
I can post some pix of the cable if you want to verify the connector
type ( i love digital cameras!)
nick oliviero
19 Mar
19 Mar
9:06 a.m.
New subject: SDI cabling question
----- Original Message -----
From: "no" <oliv555(a)arrl.net>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, March 18, 2001 6:08 PM
Subject: Re: SDI cabling question
"Gregory R. Travis" wrote:
While on this thread, just out of curiousity, can anyone enlighten me as to
how one is supposed to go about connecting RAxx disks to a KDA50
controller in the same cabinet (internally)? I have no idea how the cabling
is supposed to work for SDI drives, as I've never worked with them
before.
I've got an old MicroVAX III that I stuck four RA72 drives in, but I don't
have any SDI cabling, nor any idea on how to go about acquiring or making
the requisite cables to hook all the drives up. Help!
Thanks,
--Sean Caron (root(a)diablonet.net) | http://www.diablonet.net
Can someone enlighten me regarding DEC SDI cabling? Here's
what I have:
RA81 disk drive with two big black cables coming out of it, one for
Went thru a similar install last year, an RA72 array to a UDA50, and
had to use DEC BA26V cables between the boxes.
I picked another set of 4 BA26v-12's for my home Qbus system, project
I've since abandoned. If you need some or all of these let me know.
I can post some pix of the cable if you want to verify the connector
type ( i love digital cameras!)
nick oliviero
11:03 a.m.
New subject: SDI cabling question
While on this thread, just out of curiousity, can
anyone enlighten me as to
how one is supposed to go about connecting RAxx disks to a KDA50
controller in the same cabinet (internally)? I have no idea how the cabling
is supposed to work for SDI drives, as I've never worked with them
before.
On the "inside" its pretty straight-forward. There is a harness that
connects to the kda50 and has four black cables extending from it that end
in 8 pin connectors I believe. (Mine's in storage at the moment) These
connect to the matching connector on the RA7x disk unit.
--Chuck
8527
days inactive
8531
days old
16 comments
14 participants
participants (14)
-
ajp166＠bellatlantic.net -
ard＠p850ug1.demon.co.uk -
cmcmanis＠mcmanis.com -
foo＠siconic.com -
greg＠ciswired.com -
Hans.Franke＠mch20.sbs.de -
jhellige＠earthlink.net -
jimw＠agora.rdrop.com -
jpero＠sympatico.ca -
leec＠slip.net -
oliv555＠arrl.net -
rigdonj＠intellistar.net -
sean＠techcare.com -
spc＠conman.org