Subject: H89 disk transfer program

From: "Dwight K. Elvey" <[email-masked]>
Date: Tue Apr 15 21:31:08 2003

Hi
 I've started looking at how to make a H89 disk
transfer program that would allow one to make images
of the hard sectored disk into a DOS file. I've
had my H89 powered up and thought I'd pass on one
of the first problems I came across ( other than
one of the tantalums popping ). The belts on the
floppy drives have all stretched. Only about half
of my floppies would read. Since I don't have the
original full height drive, the drives I do have
had no adjustment for belt tension( they were ALPS
single sided drives, half height ). I had to file the
motor mount holes to get the drives to work well with the
pile of disk I have. Anyway, this is something to
watch for in the older drives.
 Now, onto the more useful stuff. I've written some
bootstrap code that allows me to pass a program
into the H89 from a serial port. The code to do this
take a reasonable amount of space because of the need
to initialize the serial port. It currently takes
about 40H+ of code to enter ( in octal for Heath monitor ).
I might find some code in the ROMs that does this
part for me. This is a little long but there is not much
I can do about it. I am using the LP serial port of the H89
since it runs with a 1:1 wiring of a PC serial port ;)
 The idea is that the first 4 bytes will contain
the address and count to load. The rest will be
the actual code. When it finishes the counted bytes,
it will automatically switch to the down loaded code.
This next code is expected to perform the functions of
format, disk image write and disk image read.
This will be used as the next level of bootstrapping.
 I've got notes on all of the entry points to control
the H17 disk controller so I can do the various disk
operations. There is one problem I have now and that
is that the HDOS disk all have a thing called 'Volume
Number'. I expect that this was so that one could avoid
trashing other disk ( HDOS uses a mount/dismount system ).
The difficulty is that the first track is always volume
0 and the others are the particular volume number selected
for that disk. In order to read or write, one needs to
know the volume number for that disk. This is encoded on
the disk, similar to things like sector number and
track number. I haven't figured out how HDOS knows
what volume the disk is by looking at the first track.
I suppose it is someplace there. I suspect that
I may want to format the disk as I write the image so
that I can pass the volume number along. I'm not sure
if it is a good idea or not to keep the original
volume number. One might want to have new volume numbers
for each disk in their collection.
 Still, I am making progress. Hopefully, this will
make sending and archiving HDOS disk easier. Any
suggestions on things I might want to add?
Dwight

---

From: "Patrick Rigney" <[email-masked]>
Date: Tue Apr 15 21:31:17 2003

> It currently takes
> I can do about it.

> Any suggestions on things I might want to add?
> Dwight

Dwight,

Hmmm... interesting. I have an idea... How about borrowing a concept from
bootloaders in general? Shorten the program that you have to key in by hand
to just a short bootstrap loader that reads bytes from the serial port and
stuffs memory.  The PC-side program's job, then, is to *first* send the
*real* larger downloader down the line before the disk image data, which the
bootloader stuffs into memory and then executes to read the image data that
then follows.  I'm not sure how much shorter the bootloader could be than
40H, but I have to imagine a good bit since no disk I/O is needed at that
stage, and it would certainly facilitate the bigger duplicator app being
much larger without much hassle to the operator.

Patrick