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_at_bellatlantic.net>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, October 04, 2000 4:38 PM
Subject: Re: console multiplexor
> From: Chuck McManis <cmcmanis_at_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 "_at_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="_at_who.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
>
>
>
>
Received on Wed Oct 04 2000 - 20:33:01 BST