[sebhc] Re: Re-creating actual floppies from archive

[Dwight Elvey]

>From: "Robin England" <robin.england at dial.pipex.com>
>
>Hi Dwight
>
>Thanks (again) for your valuable assistance! BTW I hope you are feeling
>better now.
>
---snip---
>
>The cause of the lack of serial comms was actually that the 8250 itself was
>faulty. Talk about bad luck; I had originally discounted the serial card
>having a hardware fault because I tried swapped serial cards between my two
>H89s and this had not fixed the fault. As it turns out, BOTH the serial
>cards had duff 8250s in the LP port circuit !

Hi Robin
 They may have failed in another position and the fellow just swapped them
as you have. It may also just be that you could reseat them in the
sockets and they'd work fine. I use some silicone grease, like DowCorning
#4 on the pins if I suspect sockets. Also, some of the sockets with
the folded, stamped, pins tend to fail with oxygen starved corrosion.
The platting gets tiny breaks that let a little moisture through.
Over time the springiness goes away and the socket become flakey.
Replacing with good machined pin sockets is the best solution.

---snip---
>
>There was one other problem that's worth mentioning for those who also want
>to use your H89TRANS. On my pure DOS machine I have Windows 3.1 installed
>and as is usual with Win3.1 installations, I also have SmartDrive installed.
>When I initially got your loader program communicating I found that at some
>random point during the transfer of data between the H89 and the DOS PC, the
>communication would suddenly stop. However, when using the floppy drive (on
>the DOS PC) as the source or destination, the problem did not occur. I found
>that not loading SMARTDRV.SYS on the DOS PC fixed this and allowed the data
>transfer to complete successfully.

 I guess smartdrv is using too much time and I get an overrun error.
I don't take advantage of any fifos that the newer serial parts have
so it might be just a matter of not keeping up with the serial
port. I may add a feature to enable the fifos but that'll need to
wait until I can spend some time on it this summer.

---snip---
>
>I've only two disks that came with the machines, both are HDOS with INIT,
>SYSGEN and one has BASIC, so I'm looking forward to playing with some of the
>images that are now in the archive.

See if these contain any versions we don't already have.

---snip---
>
>BTW, another approach I thought about trying was to use a different serial
>port in your loader program by changing the base address (0xE0) but I can't
>find a map of I/O addresses for devices in the H89, is there a definitive
>list somewhere?

 I think the I/O ports are listed in one of the manuals that are online.
It seems like I saw it someplace. I chose the LP port because that
was the one that used a normal 1 to 1 cable without the need of
a null modem. I could specify patch addresses so that one could
change which port on the H8/89 end. I'll give it some thought.

>
>Also, can you (or anyone) explain the significance of the volume number to
>me? Your program allows you to set (override) a volume number or take it
>from a disk image. I assume that this is the 'unique volume number' that you
>are asked to input (from 1 - 255) when INITialising a disk. What is the
>importance of this (i.e. will setting the wrong volume number when creating
>an actual disk mean that the disk won't work?).

 HDOS puts the volume number into the header for each sector. That way,
if one swaps a disk in the drive, HDOS will recognize that it isn't
the original disk and over write something it shouldn't. It uses the
volume number on each track except track 0. It uses this track to
boot from. I puts the track number in the data field of sector 9
( tenth sector ) on track 0. This way, HDOS can figure what the other
tracks are without having to look.
 It seems that CP/M always formats the disk as having volume 0
in the sector headers but the value on sector 9 may not match the
volume number used on the headers of the other tracks.
 This is also true for the FIG Forth that I sent to the archives.
It only uses headers with 0 as the volume number in the sector
header but I know that the volume number on sector 9 is
not 0.
 This is why I have the override. If it was just HDOS, I'd have
no issue. The h8d format is just the sector data and doesn't
include anything about the sector headers that would have the
volume number. As I said, for HDOS disk, finding the correct
volume number is simply looking in the right place in the data
fields. For non-HDOS, it is more of a problem.
 I should also note that the save routine that I have for the
loader is minimal and doesn't format the entire disk. It
only formats enough to load its program and can't be copied as
an image with my program. It can be recreated by the commands
in the menu so I didn't think this was an issue. I suspect
that if the disk was preformatted as a volume 0 it would work
but I've never tried this.
Dwight


--
Delivered by the SEBHC Mailing List