[sebhc] H-8-IDE board - HDOS 3.0

[Jack Rubin]

Don't forget that we have full HDOS 2.0 and 3.0 source
available. 3.0 is in the archives and I'll be glad to
scan and post any part of 2.0 on an as-needed basis
since the full listing is a foot-high printout. I also
have HDOS 3.0.x on disk and hope to have images
available shortly (??). In the meantime, I could
provide copies on disk for development purposes.

Walt - I just got a couple H47 and H67 subsystems;
hopefully I'll have something running in the near
future. At least the units power up without smoking
and there isn't too much rodent residue involved. But,
man, those things are heavy!

Jack

--- Walter Moore <waltm22 at comcast.net> wrote:
> 
> >Soon as I get it built will write a small program
> to write test data to the
> >drive. After verifying the board works (reliably),
> will write a device
> >driver for it. If all goes well the drive should be
> able to store 65535 x
> >512 = 33,553,920 or 33.5 mega-bytes. Due to the way
> HDOS 2.0 (don't know if
> >3.0 is different) allocates files it will only
> store 400 files per disk
> >(including system and directory files). The neat
> thing is we may be able to
> >create SY0 through SY9 (10) disks on one hard
> drive. That will make up for
> >the limited number of files. The device driver will
> do the mapping between
> >drives. Due to memory restrictions I think HDOS
> only allows 3 or 4 drives to
> >be mounted at any one time so some creative drive
> management may be in
> >order.
> 
> Are you certain about the 400 files?  I haven't
> given the source code a 
> good look in a long time, but I thought that the
> limit was about 250 
> files.  I seem to recall that the allocation tables
> were all 8-bit, and 
> 0xFF and 0xFE were taken.
> 
> You might only get 16M of file space.  The H-47
> driver had to do some work 
> to make 128 bytes sectors work under HDOS - HDOS
> really wanted 256 byte 
> sectors.  The file system tracked group (8-bit
> number) and sector within 
> group  (8-bit).  Everything was assumed to be 256
> bytes.  (Remember that 
> Reagan was just starting his first term when I
> really last looked at this!)
> 
> With the size of current drives and slowness of the
> H8 and small memory, I 
> would consider throwing away half of every sector so
> that I didn't get into 
> read/modify/write for short sectors and having to
> allocate extra memory for 
> the RMW.  This is just a thought.  The performance
> trade-off might not be 
> worth it.  (Can you low-level format an IDE drive
> for 256 byte sectors?)
> 
> I also believe that 8 units is the max (bit flags in
> a byte are used).  I 
> don't recall any restriction on number of mounted
> drives.  The buffers and 
> allocation tables were dynamically allocated, but
> then I never had a chance 
> to use a device with 8 units so maybe there is a
> limit I missed.
> 
> I wanted to write a driver where you could change
> the number of units, but 
> ended up deciding that this could not be easily
> done.  The number of units 
> and capabilities mask were part of the device driver
> preamble which was not 
> written back out to disk.  Darn.  I guess this is
> why they never fully 
> implemented it for the H-47 driver.  A good idea
> might be to use the set 
> command to map unit number to "partition" and have a
> couple of the unit 
> numbers be set for read-only.
> This mapping might only apply on boot, I don't know
> if they can be 
> dynamically changed for a directory device.
> 
> I had a friend who added a Corvus 10M hard drive to
> his H8 back around 
> '82.  It screamed.  I believe he made each unit 2M. 
> It was a lot faster 
> under HDOS than CP/M because CP/M always wanted to
> check to see if the disk 
> had been swapped while HDOS relied on the "Mount"
> command (he wasn't a CP/M 
> expert and my have missed something that would have
> allowed it to be faster).
> 
> Anyway, if I can get back up and running sometime
> soon, I'd be willing to 
> help out with the device driver.
> 
> ..walt 
> 
> 
> --
> Delivered by the SEBHC Mailing List
> sebhc-request at sebhc.org.
> 

--
Delivered by the SEBHC Mailing List