On 11/26/23 11:21, Scott McDonnell wrote:
So, I ended up buying a Brother FB100 disk drive because I stumbled on
one for a good price. I already have the backpack drive, so a real TPDD
wasn't a necessary item for the price they are selling for. I replaced
the belt, cleaned the head, and installed the DIP switch on the bottom
that appears to be necessary to bootstrap the drive on the TRS-80 Model 100.
I have yet to actually try it, yet, though. I actually took the plunge
because it is also used by another of the computers I have been
collecting, the Husky Hunter. This drive was apparently rebranded as the
Husky Oracle Drive. (That probably means the backpack drive should work
with it...)
I think I could have misunderstood some posts I had found about this,
though. The Husky Hunter 16 is a DOS compatible system, but the older
Husky computers were Z80 based. I think the Brother drive was actually
used with those. I have not found a DOS driver for the drive.
Anyway, has anyone actually ever gotten this drive working with a TRS-80
Model 100? Is there anything else I should know?
The FB-100 works fine with any TPDD1 client software. That means on any
platform, including Model 100 but there is nothing special about the 100
either. There is TPDD client software for MS-DOS and CP/M and several
other platforms and they all work equally the same on the TPDD1 or
FB-100 or KnitKing FDD19 or Purple Computing D103.
I've collected all I can find so far here: http://tandy.wiki/TPDD_client
The drive is like a little FTP server that you talk to over serial, so
maybe like a little dialup BBS. Any kind of machine can connect and
issue the same commands.
The Tandy version of the drive isn't really any different in how it
works (strictly TPDD1 here, TPDD2 is different).
To use the FB-100 with a Model 100, just install any of the available
TPDD clients like TS-DOS or TEENY or DSKMGR using any method you like.
IE, I use dl2 github.com/bkw777/dl2 (I did a bunch of work on dlplus
over the last few years and recently renamed it to dl2 to avoid
confusion with the old versions) and it's tpdd2-style bootstrap function
which uses specially prepared BASIC installers.
The Backpack and PDDuino (and TPDD2) work the same way.
But there are other options. There is an mp3 to install TS-DOS via the
cassette port. If you have a phone that still has a headphone jack and
if it outputs at a high enough level, you just plug the casette cable
into the headphone jack, CLOAD, and play the mp3. Or the best is to get
a REX# and use the option rom version of TS-DOS. You could even say,
restore a TBACK full ram image from a machine that had previously
bootstrapped the TPDD1 disk. The point is just to get any form of tpdd
client software installed, by any method of installing software, and
they all work the same with any FB-100 or re-badge drive.
The deal with the TPDD1 bootstrap procedure is it's just a particular
way to get a particular TPDD1 client software installed onto a
particular platform, by sending machine code directly to the mcu in the
drive to tell it to start reading & executing code from the disk. You
don't need to use that particular client software (a program called
"Floppy") and you don't need to use that particular method of getting a
piece of software installed onto the 100.
Depending on how compatible the hardware and MS-DOS environment actually
is, possibly one of the ordinary MS-DOS tpdd clients will work on the
Husky Hunter.
On the Atari Portfolio they use all 3 of PDD1.EXE, PDD2.EXE, and
PDD210.EXE for example, which are just generic MS-DOS apps that work on
any normal x86 dos machine. But some versions of MS-DOS on some
platforms are different enough that not everything works.
Maybe "HCOM" (I just googled Husky Oracle Drive) is really just another
TPDD client? Would be interesting to find out.
Anyway, even though you don't ever need to do the TPDD1 bootstrap nor
use the TPDD1 util disk, another reason to install the dip switch is so
you can have access to all the available baud rates instead of being
locked to 9600, and have access to all drive functions.
There is not *really* any practical use today, but it's academically
neat to be able to set the drive into one of the boots-into-FDC-mode
modes and maybe have some software or firmware of some project that
wants to use the drive as raw sector space, or the special bootstrap
modes that lets you send S-Records to the mcu. I have played with these
a little with pdd.sh just enough to see that they work. I can set the
jumpers so that it powers-up into FDC mode, or 38400 baud etc, and
successfully operate the drive from pdd.sh configured to make the same
assumptions. But haven't actually used any of the other modes for
anything. Remember the drive was actually originally designed to be used
by firmware from another hardware device, not really by users on and
general purpose OSs, so those other boot modes make sense when the drive
is integrated as part of a system like a CNC machine or of course the
Brother sewing/knitting machines or something. Today no one needs a
drive like that to do that job, so the only thing that ever touches one
of these drives is the many tpdd clients that all had to maintain
compatibility with what Tandy shipped with the TPDD1 as a de-facto
standard. They don't actually make full use of the drive's available
features, like the full 24 bytes of filename or the attribute byte, and
they all write their filenames in annoying fixed length 6.2 format with
embedded spaces simply because that's what Floppy does, and they had to
be compatible with Floppy.
--
bkw