4 Oct
2000
4 Oct
'00
1:33 p.m.
Hi Allison!
For some time, I've pondered what it might take to divine the various format
features from a CP/M boot disk. It seems to me that if one has a bootable
disk, it has to have sufficient information on the boot tracks to allow one
to find a copy of the BDOS, which, so long as it's the right version of
CP/M, should disclose the details of what formatting has been used for those
tracks. What's more, given that one can find the BDOS, byte for byte, one
should also be able to find enough of a BIOS to make it possible to extract
the necessary disk parameters used to boot the system. If a second-tier
system is loade, one should be able to find that by examining the autcmd.
That should then yield the data necessary to read the diskette in its
entirety.
Have you ever run into a utility that handles this? I'd think someone would
have done this by now.
Another item I've wanted for some time to automate is the setup of a hard
disk BIOS. Since it's dependent not so much on CP/M quirks but often more
on decisions made on the basis of folklore, I thought it might be
interesting to examine the process as a candidate for automation.
What do you think?
regards,
Dick
----- Original Message -----
From: ajp166 <ajp166(a)bellatlantic.net>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, October 04, 2000 4:38 PM
Subject: Re: console multiplexor
From: Chuck McManis <cmcmanis(a)mcmanis.com>
Clearly the simplest solution is a 6PnT rotary
switch, some cables wired
up
with MMJ plugs crimped on their ends. I'm
planning to build one of these
as
I have all the parts and that will get the console
going on the
micro-cluster.
That would work if you assert RxD to spacing on disconnect.
Me, I cheat. I don't bother connecting a tube (unless required like
during initial install)
and when needed I use the VT1200 to connect via the net once that is up.
However, if you're willing to be really clever
then you can do much
better
than this. I've got a nice color terminal (the
Link MC70 although its
color
is a bit unstable these days :-() or I could use a
DEC VT340 (probably
the
actual version for display) and you could, with a
bit of smarts and some
buffering take output from the RS-423 lines, and prior to forwarding
them
on to the terminal you could inject ANSI color
codes on/off. This would
make the output from each console a different color. (keeping them
straight
is of course the challenge) If you are really
clever you don't allow one
console to interrupt another mid-line either. I've got an old single
board
Z80 system that could probably do this, or I could
wimp out and use a
CPLD
feeding a Scenix chip.
Could be done with Vt125 or better yet....
Like I used to do with a Vt320, the system write a status line (25th) in
response to a simple request "@who" which runs a DCL script. the
request was stored as the "respones line" on the terminal or as a
simple "w" [set W*ho="(a)who.com".com". Also other defined commands
terminate with a call to who. The status line also has current
directory
and account. the switch box was a LQPX2-SW and MMJ to DB/P25
cabling.
Allison