🚀 go-pugleaf

Addendum to Pal Jr. problem:
      Yes Andy, you are exactly right... I was not running the FFS.  I guess
that's what happens when you use the machine daily and hurriedly try to
backup, reformat, and restore your hard disk.  Anyway, I thought there might
be someone out there who might also learn from my experience.  The key to my
problem was that when I did the original reformatting I didn't realize that
the first disk partition had to be AmigaDos.  In my case, I had difficulty
setting up multiple partitions.  This is partly due to the fact that Byte by
Byte did not distribute prep with their version of the 2090 controller.
Instead they distributed a program called hdtest.  In some ways hdtest is
actually better than prep.  For one thing prep does not seem to work (or maybe
works irratically) for disks that have had no low level formatting.  Once your
disk has low level formatting then prep can be used easily to change
partitions.  I found out (trial ... much trial, and error) that you can muck
with the mountlist entry all you want and if partition information is on the
disk, the mountlist will be ignored.  In my case I had to tell hdtest to
rewrite disk parameters in order to properly set the end of the first
partition.  On at least one attempt I created overlapping partitions - an
AmigaDos partition named dh0: which was the entire disk and an FFS partition
that was the disk less the first twenty cylinders.  By the way, I didn't
realize that dh0: was a "majic" device name.  I think it might be a
requirement that the first partition on the disk be called dh0: since
binddrivers will mount this automatically.  I tried calling the FFS partition
dh0: in one trial and it didn't like that.
      Also, any other Pal or Pal, Jr. owners who might use hdtest should
beware.  If you decide to redo the low level formatting... hdtest does not
read the current bad block list from the disk.  You MUST enter it in manually
and I recommend several read/write/compare scans to discover marginal blocks
that should also be entered in manually. To verify that the bad block list has
been correctly saved and recognized, you should notice additional seeks while
formatting at the dos level (sys:system/format) for those cylinders containing
bad blocks.  If you can't hear this then your bad block list has probably
become corrupted or isn't there.
      So what did I get from this exercise.  Well, besides taking up two
evenings, I did get a lot of unused junk off my hard disk and performance as
measured by dperf (32K block reads) went from 50K/sec to 270K/sec.  All in all
a very profitable exercise.  Thanks for the help!