7 Sep
2020
7 Sep
'20
8:59 a.m.
On 9/7/20 2:26 AM, Veit, Holger wrote:
Could this be a PGC card clone?
https://en.wikipedia.org/wiki/Professional_Graphics_Controller
That had crossed my mind at one point, but there's no horsepower to this
card at all - it's just TTL, RAM, BIOS and the 6845.
The color output *appears* to be TTL level - or, at least, that's what it's
using at power-on. It's not impossible, I suppose, for it to be switchable
to some kind of analog mode, thereby giving more color depth.
I'm wondering if it doesn't have some form of high-resolution bitmap mode
for visualization, i.e. display construction would be processor-intensive
and intended for static images/diagrams. I don't know if that really makes
sense though because it would also imply having to switch the monitor -
i.e. starting the machine with a CGA type display plugged in, then
physically moving to something else later.
On the back of that, I just found this thread too which refers to an
identical board:
http://www.vcfed.org/forum/showthread.php?48718-3-Weird-Video-Cards-any-ide…
... nothing there really "helps", but someone's comment about the medical
field and a higher-resolution display via the RCA jack is interesting -
that would at least get around the need to switch monitors (well, unless
there was some special autodetecting analog/digital monitor that was sold
to go with the hardware, I suppose).
It's a shame that the hard disk in the machine is either snafu or has been
wiped - the contents would have helped shed light on things. There's an
EPROM as part of the video hardware; anyone know of a DOS-based util to
poke at the contents and/or snarf them into a file on disk? It's possible I
suppose that there might be some useful strings hidden away in there.
cheers
Jules
7 Sep
7 Sep
11:04 a.m.
On Mon, 7 Sep 2020, Jules Richardson via cctalk wrote:
It's a shame that the hard disk in the machine is
either snafu or has been
wiped - the contents would have helped shed light on things. There's an EPROM
as part of the video hardware; anyone know of a DOS-based util to poke at the
contents and/or snarf them into a file on disk? It's possible I suppose that
there might be some useful strings hidden away in there.
"DOS based utility program to poke at the contents and/or snarf the int a
file on disk"?
DEBUG.COM
Present since PC-DOS/MS-DOS 1.0
STILL there.
As it got more bloated, it eventually became a .EXE file, but still
FALSELY named .COM (DOS didn't care which of the two extensions, but
looked for "MZ" in first two bytes of the header.)
The character generator ROM might not be accessible in the memory map.
OR, the ROM could be a BIOS extension.
There did exist some CGA-like boards with more RAM. I had one (from
Plantronics??) that was a double board, with 640 x 400, and 640 x 200 with
more colors. It was NOT the same as yours, in at least trivial ways - it
did not have an RCA, but had composite on an RF modulator (4 pin)
connector.
The Vogons page
https://www.vogons.org/viewtopic.php?t=57843
while very useful, is immediately suspect, by starting out with saying
"100% compatible". It was NOT. Compatible enough for MOST stuff, but of
course, it did not have the IBM BASIC ROMs, and therefore came with
GW-BASIC.
My buddy had a few Sperry 5160-like machines, as well as some PBM-1000's
(Micropro CP/M machine). They were dumpstered immediately when he died 5
years ago.
--
Grumpy Ol' Fred cisin at xenosoft.com
11:54 a.m.
On 9/7/20 1:04 PM, Fred Cisin via cctalk wrote:
"DOS based utility program to poke at the
contents and/or snarf the int a
file on disk"?
DEBUG.COM
Funny, I've only ever used it for quick bits of assembly (just a couple of
days ago, in fact), and to do things such as kicking off the formatter
embedded in the ROM on some controllers. It didn't even occur to me that it
probably has some dumping/loading abilities too! I'll dig some docs out...
My buddy had a few Sperry 5160-like machines, as well
as some PBM-1000's
(Micropro CP/M machine).? They were dumpstered immediately when he died 5
years ago.
Honestly I've always been a bit indifferent about the PC stuff (which is
probably why I've had these for around a decade and am only now really
looking at them) - I'd still rather save them when I see them, though (at
least up until the point where I run out of space - but "early x86 PC"
seems to have quite a following these days).
cheers
Jules
1:30 p.m.
"DOS
based utility program to poke at the contents and/or snarf the int a
file on disk"?
DEBUG.COM
Funny, I've only ever used it for quick bits of
assembly (just a couple of
days ago, in fact), and to do things such as kicking off the formatter
embedded in the ROM on some controllers. It didn't even occur to me that it
probably has some dumping/loading abilities too! I'll dig some docs out...
1) If the drive is larger than 32MB, then boot with DOs 3.31 or newer.
Although even with the older ones, you can still do quite a bit. 3.31 is
the first where DOS supports a partition larger than 32MB
MS-DOS 5.00 is first where debug commands have a "/?" option to get a
short reminder of usage.
If running DEBUG gives you an "INCORRECT DOS VERSION" error, then find the
right one, OR (DOS 5.00 or above), figure out what DOS version that copy
of DEBUG is demanding, and use SETVER.
L 100 2 0 1
will load into DS:100, the contents of drive 2 (C:), first sector, 1
sector (which happens to be the Master Boot Record and Partition Table)
D ; will display it.
D [address] ; will let you look at other areas in the segment.
R ; see register contents
N [filename] ; select filename
R CX
200 ; set CX to 512; make sure BX is 0
W ; write BX:CX bytes from DS:100 to the file
To write 8K from c800:0 to file "TMPCX.DAT":
R DS
C7EO ; compensate for offset 100
R CX
2000 ;8K
N A:TMPCX.DAT
W
The offset :100 is a carryover from the PSP and TPA of CP/M.
Q ; the absolutely most important DEBUG command to know
Finding the errors in the above from my aging unrefreshed dynamic wetware
is left as an exercise for the reader.
There are MANY people on this list that have plentiful experience and
better memories.
8 Sep
8 Sep
3:46 p.m.
On Tue, 8 Sep 2020 at 06:47, Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
1) If the drive is larger than 32MB, then boot with DOs 3.31 or newer.
Although even with the older ones, you can still do quite a bit. 3.31 is
the first where DOS supports a partition larger than 32MB
MS-DOS 5.00 is first where debug commands have a "/?" option to get a
short reminder of usage.
Agreed. (Like I'd dare to differ with Fred.)
My 2?'s worth is just: for an XT, if you want to fit a CF card or
something, try DR-DOS 3.41. It's out there in various places. RAM
usage as small as MS-DOS 3.3 but offers most of the benefits of MS-DOS
4 and some of MS-DOS 5 (both of which take a *lot* more RAM on an
XT-class machine.)
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
7 Sep
7 Sep
11:17 a.m.
BTW, XT compatibles with the Xebec (and Xebec-like) hard disk controllers
would not give a "COMMAND ERROR" message for a Low-level-formatted/wiped
hard disk. Probably a "1701" error.
NOTE: for the 5170 (AT), IBM switched from the Xebec controller to a
Western Digital one.
There were many models of Xebec controller, and numerous other brands.
The specific model Xebec that IBM used had 4 pairs of solder pads near the
center of the board for selecting drive type for 2 drives. all open was
10MB. other supported sizes (could be over-ridden by loading software at
boot) were 5MB, 16M and 26MB?
And, even if it were somehow "compatible" with a completely different hard
disk controller, "COMMAND ERROR" doesn't sound like anybody's error
message for a wiped drive. More likely to be a generic "READ ERROR"
If DOS were booted from floppy, the MS-DOS error message for a wiped HDD
(address mark not found) would be "General Failure"
--
Grumpy Ol' Fred cisin at xenosoft.com
12:22 p.m.
On 9/7/20 1:17 PM, Fred Cisin via cctalk wrote:
BTW, XT compatibles with the Xebec (and Xebec-like)
hard disk controllers
would not give a "COMMAND ERROR" message for a Low-level-formatted/wiped
hard disk.?? Probably a "1701" error.
This one's a Xebec, almost identical to one of the branded variants that
IBM used, actually. It's got the four jumpers lower-right for selecting
different drive types, but it also has jumpers for ROM and I/O address
selection, which I don't think I recall seeing before on the boards that
IBM used.
One of the ROMs is labeled as "104833A", which isn't too inconsistent with
what I've seen on IBM ones (they generally seem to have a 10483xx format).
The other ROM has a Mitsubishi Electric sticker though, labeled as "FXD
J12" and "213". One of the functions is presumably to hold custom drive
parameters, selected via the four board jumpers, but I don't know what
other stuff might typically be in that ROM - I didn't want to automatically
rule out it being the source of the "command error" (where other responses
might be issued for the same underlying error by other firmware)
The hard drive in the system is a Miniscribe M3425; at power-on it spins
up, runs the heads in and back out, then blinks its LED once - which I
believe is normal, "all is well" behavior, and if there were a significant
fault with the spindle speed or positioning then it would start blinking
out an error code.
And, even if it were somehow "compatible"
with a completely different hard
disk controller, "COMMAND ERROR" doesn't sound like anybody's error
message
for a wiped drive.? More likely to be a generic "READ ERROR"
I agree "read error" would seem more sensible, but this thing's quirky
enough that I wouldn't rule anything out right now. I didn't actually try
starting the system with the hard disk controller in place but the drive
not attached - maybe I'll do that just to see if there's any change in
behavior.
Jules
3:34 p.m.
On 9/7/20 2:22 PM, Jules Richardson via cctalk wrote:
Progress! I started looking everything over again, picking stuff apart,
reassembling etc. - eventually happening to notice quite by chance how
rough the very end of the hard disk control cable felt as I pushed the
connector back onto the drive. Out with the loupe, and sure enough - the
cable cut wasn't particularly clean across the entire width, and there was
a single strand of wire just long enough to bridge across two of the
conductors.
Now I'm getting "system file not found or disk read error", which although
disappointing is at least far more sane. I'll have to rustle up a floppy
boot disk and see if I can get any access that way.
I have no idea of this machine's history - I don't even know where I got
it. Maybe those are factory cables, maybe not. Maybe previous owners goofed
around with the system over the years, maybe the drive itself is
non-original even (and contains nothing relevant to the video board, even
if it was bootable). After doing an initial PSU test the other day, I did
strip it down to bare minimum - just system board and video - so it's
possible the drive cable wasn't shorted prior to my disturbing things.
cheers
Jules
And, even if
it were somehow "compatible" with a completely different
hard disk controller, "COMMAND ERROR" doesn't sound like anybody's
error
message for a wiped drive.? More likely to be a generic "READ ERROR"
I agree "read error" would seem more sensible, but this thing's quirky
enough that I wouldn't rule anything out right now.
4:18 p.m.
On Mon, 7 Sep 2020, Jules Richardson via cctalk wrote:
Progress! I started looking everything over again,
picking stuff apart,
reassembling etc. - eventually happening to notice quite by chance how rough
the very end of the hard disk control cable felt as I pushed the connector
back onto the drive. Out with the loupe, and sure enough - the cable cut
wasn't particularly clean across the entire width, and there was a single
strand of wire just long enough to bridge across two of the conductors.
Now I'm getting "system file not found or disk read error", which although
disappointing is at least far more sane. I'll have to rustle up a floppy boot
disk and see if I can get any access that way.
I have no idea of this machine's history - I don't even know where I got it.
Maybe those are factory cables, maybe not. Maybe previous owners goofed
around with the system over the years, maybe the drive itself is non-original
even (and contains nothing relevant to the video board, even if it was
bootable). After doing an initial PSU test the other day, I did strip it down
to bare minimum - just system board and video - so it's possible the drive
cable wasn't shorted prior to my disturbing things.
Yep!
Floppy boot seems like the next step.
Got an IBM "Advanced Diagnostics" floppy to try?
Just to add to the confusion and misery, . . .
If the controller is bad, . . .
XT controllers tended to NOT be interchangeable, even between various OEMs
of Xebec!
Some HDDs would not work when connected to a different controller.
You would expect that a drive LLF with one controller would work with
another, or at least another one from same OEM, without redoing the LLF.
I don't know what the incompatability was. Possibly different sector
numbering? That MIGHT be solvable by swapping the ROM?
That was mostly fixed by the time of the 5170/AT WD controllers.
8 Sep
8 Sep
2:12 p.m.
On 9/7/20 6:18 PM, Fred Cisin via cctalk wrote:
Floppy boot seems like the next step.
OK, it boots off a DOS 3.3 floppy if that floppy is inserted before it
attempts to boot from the hard disk. If I wait for it to do its "system
file not found" bit, followed by a subsequent prompt to insert boot media
and press a key, it attempts to access the floppy drive but then goes off
into la-la land. Odd.
But anyway, taking the successful floppy boot route, I can certainly access
the hard disk in terms of bringing up directory listings and TYPEing files
to the display. So far, attempts to run anything from the drive just result
in a lock-up (keyboard immediately unresponsive, hard reset required).
There appear to be DOS utils on the drive, and command.com, but I've not
checked for hidden system files yet. fdisk shows the partition as active.
Got an IBM "Advanced Diagnostics" floppy to
try?
No, but I see that the minuszerodegrees site has an image, so I'll write
that out and see what happens.
Looking at the drive contents, incidentally, I didn't see anything that
explains (or interacts with) that unusual video hardware - it basically
just holds DOS and a bunch of documents written by the original owner.
Maybe they got suckered into buying this fancy graphics hardware without
having any actual need for it, and then of course EGA and VGA came along
and rendered it obsolete anyway.
XT controllers tended to NOT be interchangeable, even
between various OEMs
of Xebec!
Yes - something that people often seem to forget, too. I've run into that
quite often, where someone will hang onto an old drive because of the
contents, but they'll dump the controller that it was formatted against.
I don't know what the incompatability was.
I don't think there was any kind of standard at all for what the low level
looked like - vendors were free to do what they wanted in terms of what
values they used for flags and how they actually ordered things within the
sector header. I suppose there were some tweaks made over time for
optimization or reliability (or at least, recovery) reasons, too, which is
why even a single vendor had a few different incompatible formats.
I expect it was the same in the SCSI and IDE worlds, but of course with
those "the controller" which handles formatting is really part of the
package, so it wasn't an issue.
Jules
4:04 p.m.
On Tue, 8 Sep 2020, Jules Richardson via cctalk wrote:
NOT a big deal. It's merely the only method directly from IBM for doing
low level format.
In most cases, Speedstor is more useful for LLF.
It always seemed counter-intuitive that makers of HDD hardware for XT
didn't slavishly mimic IBM's XT HDD. And especially counter-intuitive
that different vendor Xebec controllers didn't always interchange.
--
Grumpy Ol' Fred cisin at xenosoft.com
OK, it boots off a DOS 3.3 floppy if that floppy is
inserted before it
attempts to boot from the hard disk. If I wait for it to do its "system file
not found" bit, followed by a subsequent prompt to insert boot media and
press a key, it attempts to access the floppy drive but then goes off into
la-la land. Odd.
How large is the drive?
If it is over 32MB, then try to find DOS 3.31 or newer.
MY preference is MS-DOS 6.22
But anyway, taking the successful floppy boot route, I
can certainly access
the hard disk in terms of bringing up directory listings and TYPEing files to
the display. So far, attempts to run anything from the drive just result in a
lock-up (keyboard immediately unresponsive, hard reset required). There
appear to be DOS utils on the drive, and command.com, but I've not checked
for hidden system files yet. fdisk shows the partition as active.
Date and time of Command.com and any other DOS files will identify the
version number.
DIR /A or
DIR /A:H
will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS
had IBMBIO.COM and IBMDOS.COM instead)
Can you COPY files from the HDD to floppy?
Being able to access contents of files, but not RUN them seems odd.
IF the DOS on the floppy misunderstands the partition table, then root
directory might look OK, but sub-directories might not be where it thinks
they are, . . .
Got an IBM
"Advanced Diagnostics" floppy to try?
No, but I see that the
minuszerodegrees site has an image, so I'll write that
out and see what happens. Looking at the drive contents, incidentally, I
didn't see anything that
explains (or interacts with) that unusual video hardware - it basically just
holds DOS and a bunch of documents written by the original owner. Maybe they
got suckered into buying this fancy graphics hardware without having any
actual need for it, and then of course EGA and VGA came along and rendered it
obsolete anyway.
It is probably completely CGA compatible, unless you invoke of of its
other modes.
The ROM on the video card may be a BIOS extension, in which case access to
extended modes may be handled internally in various programs. For
instance Windows 3.x, PC PAint, Pagemaker, and Xerox Ventura let you
configure for a variety of video hardware.
Otherwise, check to see if CONFIG.SYS has DEVICE commands to load any
device drivers, usually .SYS, although sometimes .COM
XT controllers
tended to NOT be interchangeable, even between various OEMs
of Xebec!
Yes - something that people often seem to forget, too. I've run into
that
quite often, where someone will hang onto an old drive because of the
contents, but they'll dump the controller that it was formatted against. 
4:16 p.m.
I recall some of the high end cards in the CGA / EGA era had adon boards
that were connected with a 20 or 36 pin jumper cable across the top of the
boards - They also ran more than 64K or ram, such as the ATI Wonder
boards. Maybe it's like that - the ATI boards had 256K so they could page.
Kindest regards,
Doug Jackson
em: doug at doughq.com
ph: 0414 986878
Check out my awesome clocks at www.dougswordclocks.com
Follow my amateur radio adventures at vk1zdj.net
-----------------------------------------------------------
Just like an old fashioned letter, this email and any files transmitted
with it should probably be treated as confidential and intended solely for
your own use.
Please note that any interesting spelling is usually my own and may have
been caused by fat thumbs on a tiny tiny keyboard.
Should any part of this message prove to be useful in the event of the
imminent Zombie Apocalypse then the sender bears no personal, legal, or
moral responsibility for any outcome resulting from its usage unless the
result of said usage is the unlikely defeat of the Zombie Hordes in which
case the sender takes full credit without any theoretical or actual legal
liability. :-)
Be nice to your parents.
Go outside and do something awesome - Draw, paint, walk, setup a
radio station, go fishing or sailing - just do something that makes you
happy.
^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally
sing ^G ^G ^G ^G ^G ^G ^G ^G
On Wed, Sep 9, 2020 at 9:04 AM Fred Cisin via cctalk <cctalk at classiccmp.org>
wrote:
On Tue, 8 Sep 2020, Jules Richardson via cctalk
wrote:
that
that
OK, it boots off a DOS 3.3 floppy if that floppy
is inserted before it
attempts to boot from the hard disk. If I wait for it to do its "system
file
not found" bit, followed by a subsequent
prompt to insert boot media and
press a key, it attempts to access the floppy drive but then goes off
into
la-la land. Odd.
How large is the drive?
If it is over 32MB, then try to find DOS 3.31 or newer.
MY preference is MS-DOS 6.22
But anyway, taking the successful floppy boot
route, I can certainly
access
the hard disk in terms of bringing up directory
listings and TYPEing
files to
the display. So far, attempts to run anything
from the drive just result
in a
lock-up (keyboard immediately unresponsive, hard
reset required). There
appear to be DOS utils on the drive, and command.com, but I've not
checked
for hidden system files yet. fdisk shows the
partition as active.
Date and time of Command.com and any other DOS files will identify the
version number.
DIR /A or
DIR /A:H
will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS
had IBMBIO.COM and IBMDOS.COM instead)
Can you COPY files from the HDD to floppy?
Being able to access contents of files, but not RUN them seems odd.
IF the DOS on the floppy misunderstands the partition table, then root
directory might look OK, but sub-directories might not be where it thinks
they are, . . .
Got an
IBM "Advanced Diagnostics" floppy to try?
No, but I see that the
minuszerodegrees site has an image, so I'll write out and see what happens.
NOT a big deal. It's merely the only method directly from IBM for doing
low level format.
In most cases, Speedstor is more useful for LLF.
Looking at the drive contents, incidentally, I
didn't see anything that
explains (or interacts with) that unusual video hardware - it basically
just
holds DOS and a bunch of documents written by the
original owner. Maybe
they
got suckered into buying this fancy graphics
hardware without having any
actual need for it, and then of course EGA and VGA came along and
rendered it
obsolete anyway.
It is probably completely CGA compatible, unless you invoke of of its
other modes.
The ROM on the video card may be a BIOS extension, in which case access to
extended modes may be handled internally in various programs. For
instance Windows 3.x, PC PAint, Pagemaker, and Xerox Ventura let you
configure for a variety of video hardware.
Otherwise, check to see if CONFIG.SYS has DEVICE commands to load any
device drivers, usually .SYS, although sometimes .COM
> XT controllers tended to NOT be
interchangeable, even between various
OEMs
of Xebec!
Yes - something that people often seem to forget, too. I've run into quite often, where someone will hang onto an old
drive because of the
contents, but they'll dump the controller that it was formatted against.
It always seemed counter-intuitive that makers of HDD hardware for XT
didn't slavishly mimic IBM's XT HDD. And especially counter-intuitive
that different vendor Xebec controllers didn't always interchange.
--
Grumpy Ol' Fred cisin at xenosoft.com
4:28 p.m.
On Wed, 9 Sep 2020, Doug Jackson wrote:
I recall some of the high end cards in the CGA / EGA
era had adon boards
that were connected with a 20 or 36 pin jumper cable across the top of the
boards - They also ran more than 64K or ram, such as the ATI Wonder
boards. Maybe it's like that - the ATI boards had 256K so they could page.
I had a CGA "double board" that did 640x400 or 640x200 by more colors.
It was not the same as this one, but might have been internally similar.
But I don't remember ATI premium CGA.
ATI had some interesting EGA boards, including one that had an add-on
that included the mid-board connector for Compaq luggable internal video!
Otherwise, you were stuck with Compaq CGA or Compaq EGA.
9 Sep
9 Sep
9:56 a.m.
On 9/8/20 6:04 PM, Fred Cisin via cctalk wrote:
Maybe. Assuming that the hard drive's directory contents are intact, and
therefore there's nothing too unusual on the drive, I've perhaps got
nothing to lose by reformatting - the only issue is that MIO.SYS, how it
differs from Microsoft's, whether it's corrupt or not, and how - if it is
intact - I can migrate it over post-install.
Of course maybe speed disk (if that is even the cause of my problems) has
some kind of backup / undo aspect, but I doubt it.
Date and time of Command.com and any other DOS files
will identify the
version number.
I've got 11/26/85 on command.com.
DIR /A? or
DIR /A:H
will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS
had IBMBIO.COM and IBMDOS.COM instead)
The /a switch isn't part of the dir command in whatever 3.3 version I have.
However, I just wrote a DOS 6.22 boot disk and that shows three hidden
files on the hard disk:
MSDOS.SYS (11/18/85)
MIO.SYS (11/18/85)
SD.INI
I'm guessing that the 'M' in MIO.SYS is "Mitsubishi" and the OS is
tailored
in some way to the machine.
TYPEing "sd.ini" indicates that it's related to Norton Speed Disk - not a
program I'm familiar with, but as that appears to be a defragmenter, it
might hint at why my drive isn't bootable and seems to be having problems
with various executables - I wonder if the directory structure "looks
sane", but file contents have been completely mangled.
Can you COPY files from the HDD to floppy?
Just filling up a few 360K disks with files at random so far, yes. But
difficult to say if the file contents are correct.
Looking at the
drive contents, incidentally, I didn't see anything that
explains (or interacts with) that unusual video hardware - it basically
just holds DOS and a bunch of documents written by the original owner.
Maybe they got suckered into buying this fancy graphics hardware without
having any actual need for it, and then of course EGA and VGA came along
and rendered it obsolete anyway.
It is probably completely CGA compatible, unless you invoke of of its other
modes.
10:19 a.m.
On Wed, 9 Sep 2020 at 18:56, Jules Richardson via cctalk
<cctalk at classiccmp.org> wrote:
On 9/8/20 6:04 PM, Fred Cisin via cctalk wrote:
> Date and time of Command.com and any other DOS files will identify the
> version number.
Only after DOS 5 or so, I fear.
I've got 11/26/85 on command.com.
Yup. `ATTRIB *.*` might work in 3.3 though.
DIR /A or
DIR /A:H
will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS
had IBMBIO.COM and IBMDOS.COM instead)
The /a switch isn't part of the dir command in whatever 3.3 version I have. However, I just wrote a DOS 6.22 boot disk and that
shows three hidden
files on the hard disk:
MSDOS.SYS (11/18/85)
MIO.SYS (11/18/85)
SD.INI
I'm guessing that the 'M' in MIO.SYS is "Mitsubishi" and the OS is
tailored
in some way to the machine.
Uhoh. Danger, Will Robinson.
TYPEing "sd.ini" indicates that it's related to Norton Speed Disk - not a
program I'm familiar with, but as that appears to be a defragmenter, it
might hint at why my drive isn't bootable and seems to be having problems
with various executables - I wonder if the directory structure "looks
sane", but file contents have been completely mangled.
Oh dear, yes. If the machine is not totally vanilla but close enough
to boot vanilla DOS, then it's possible that SPEEDISK could have run
but incorrectly and mangled stuff. Similarly running DOS defraggers on
a VFAT disk with LFNs would mangle them, in the Win95 era.
TBH, though, I'm surprised -- later versions of DOS (such as 6.22)
didn't run on DOS compatible machines, because they'd died out by
then. It was IBM compatible or nothing by the DOS 6 era, IIRC. So I'd
expect a later-era machine to be compatible enough that Norton etc.
would have no problem.
I ran things like PKARC and PKZIP successfully on DOS-compatibles in
the late '80s, because they only did legal file access and wrote plain
text to the screen. I wouldn't expect SPEEDISK to run on an early
Apricot or something.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
12:59 p.m.
>> Date and time of Command.com and any other DOS
files will identify the
>> version number.
On Wed, 9 Sep 2020, Liam Proven via cctalk wrote:
Only after DOS 5 or so, I fear.
By lookup of the date prior to 5.00; starting with 5.00, visible instead
of accurate dates
Oh dear, yes. If the machine is not totally vanilla
but close enough
to boot vanilla DOS, then it's possible that SPEEDISK could have run
but incorrectly and mangled stuff. Similarly running DOS defraggers on
a VFAT disk with LFNs would mangle them, in the Win95 era.
That is very worrisome.
TBH, though, I'm surprised -- later versions of
DOS (such as 6.22)
didn't run on DOS compatible machines, because they'd died out by
then. It was IBM compatible or nothing by the DOS 6 era, IIRC. So I'd
expect a later-era machine to be compatible enough that Norton etc.
would have no problem.
various levels of "IBM compatible".
PCWorld (1983?) did a test of "compatibles", and misused Xenocopy as "the
acid test", using a very early "REAL IBM PC ONLY" version of the program
that my publisher (may they rot in pieces) had insisted on for trying to
peddle to IBM. By the time of the PCWorld article, RELEASE VERSIONS of
XenoCopy ran on anything that had reasonable INT13h, INT1EH, and INT10h
compatibility.
12:40 p.m.
> Date and time of Command.com and any other DOS
files will identify the
> version number.
On Wed, 9 Sep 2020, Jules Richardson via cctalk wrote:
I've got 11/26/85 on command.com.
That would be MS-DOS version 3.10
Best known for having the "network redirector"? (which was also the
loophole that permitted MSCDEX to have CD-ROM (bigger than 32MB, BUT DOS
didn't know that it was local - thought that it was on a network
somewhere))
1.00 August 1981
1.10 May 1982 double sided drives
1.25 MS-DOS
2.00 March 1983 HDDs, hierarchical directories, file handle API
2.10 October 1983 slowed down disk access for the PCJr Qumetrak 142
2.11 MS-DOS heavily customized by OEMs
3.00 August 1984 AT/5170, 1.2MB floppy,
3.10 Nov 1985 network redirector?
3.20 January 1986 included PC-DOS 720K 3.5" floppy (some OEM MS-DOS
versions had 3.5" since MS-DOS 2.11)
3.30 April 1987 PS/2
3.31 MS-DOS heavily customized by OEMs, >32MB HDD
4.00 PC-DOS HDD >32MB "not compatible with Norton"
4.01
5.00 May 1991 DOS version in the displayed date
6.00 March 1993 massive inclusion of aftermarket add-ons
6.10 IBM's Version
6.20 October 1993 reliability improvements! (such as changing SMARTDRV)
6.21 removal of infringing compression
6.22 addition of non-infringing compression
DIR /A? or
DIR /A:H
will let you see the hidden files (presumably IO.SYS and MSDOS.SYS; PC-DOS
had IBMBIO.COM and IBMDOS.COM instead)
The /a switch isn't part of the dir
command in whatever 3.3 version I have. However, I just wrote a DOS 6.22 boot disk and that
shows three hidden files
on the hard disk:
MSDOS.SYS (11/18/85)
MIO.SYS (11/18/85)
SD.INI
I'm guessing that the 'M' in MIO.SYS is "Mitsubishi" and the OS is
tailored
in some way to the machine.
TYPEing "sd.ini" indicates that it's related to Norton Speed Disk - not a
program I'm familiar with, but as that appears to be a defragmenter, it might
hint at why my drive isn't bootable and seems to be having problems with
various executables - I wonder if the directory structure "looks sane", but
file contents have been completely mangled.
COULD BE.
HOPE NOT.
Just like, . . .
when DOS 1.10/1.25 came out, there were disasters when people ran CHKDSK
1.0 on a 1.10 disk, even if running the CHKDSK on DOS 1.10. Chkdsk
proceeded to "FIX" the disk (cf. Merck Veterinary manual)
THAT disaster resulted in later versions:
1) CHKDSK beagan to require "/F" ("fix"), AND requiring confirmation
before "repairs"
2) DOS utilities ("External commands") wouldn't run on any version of DOS
other than what they were bundled with.
THAT resulted eventuaally in release (V5.00?) of SETVER.
In my assembly language class, I showed them how to use DEBUG to patch
LINK and EXE2BIN to stop caring about DOS version, and assigned them to go
home and do it. (comment out the conditional jump after Int21h, Fn 30h)
Ah, but another classic example, . . .
Norton fUtilities wasn't compatible with DOS 4.00 or 4.01 >32MB HDD.
It needed changes to comply with the 3.31 and newer changes to HDD
The press didn't phrase it that way!
They said, "DOS 4 is broken, it isn't compatible with Norton! DOS needs
to be fixed to work with Norton!"
Obviously, a new version of Norton fUtilities was called for to go with
the new OS.
MICROS~1 learned the hard way that major changes called for meeting with
certain software vendors and giving them advanced warning, so that they
could come out with new versions at same time as new OS release.
It is probably
completely CGA compatible, unless you invoke of of its other
modes.
Maybe. Assuming that the hard drive's directory contents are intact,
and
therefore there's nothing too unusual on the drive, I've perhaps got nothing
to lose by reformatting - the only issue is that MIO.SYS, how it differs from
Microsoft's, whether it's corrupt or not, and how - if it is intact - I can
migrate it over post-install. Of course maybe speed disk (if that is even the cause
of my problems) has
some kind of backup / undo aspect, but I doubt it.
"and UNDO the
IMPROVEMENTS??!?"
--
Grumpy Ol' Fred cisin at xenosoft.com
2:09 p.m.
Fred Cisin via cctalk:
(...')
Got an IBM "Advanced Diagnostics" floppy to
try?
If you want to do a ll-format, you only need debug:
A>DEBUG
-
-I 322 # reads dip-switches (don't think this is needed)
-I 321 # read status
-O 322 0 # select the controller
-I 321 # read status
-O 320 04 # ll-format instruction
-O 320 00 # 00 for drive C, 20 for drive D
-O 320 00
-O 320 00
-O 320 05
-O 320 07
the six "O 320" issue the "low-level format" instruction directly to
the
controller. Bit 5 in 2nd byte represents the drive.
Do not expect any feedback, this is not a program, this is a direct
communication with the controller via in/out instructions. The ll-format
process is done in the controller's firmware and the Xebec-controllers
are very slow.
--
Martin Peters
martin at shackspace.de
1570
days inactive
1572
days old
17 comments
5 participants
participants (5)
-
cisin＠xenosoft.com -
doug＠doughq.com -
jules.richardson99＠gmail.com -
lproven＠gmail.com -
martin＠shackspace.de