I've been working on this for a few weeks and I just hit the main
milestone that not only all the normal file access functions work, but
the FDC-mode functions work, including, dumping and restoring a whole
disk works. I just bootstrapped from a restore from a dump of a factory
tpdd1 utility disk.
https://github.com/bkw777/pdd.sh
So, it's now possible to create a TPDD1 Utility Disk from a download,
with no exotic hardware, just the TPDD1 drive itself and serial
connection, and the software, aside from this script itself, is just bash.
And the special challenge I set myself because I just knew it was
possible: It's not only all done just in bash, it's all done right in
the initial single process. No subshells, let alone external programs
like awk etc, not even tr/cp/rm etc, not even other instances of bash
from FOO=$(function... ).
It's all in-memory ops and all in the single initial instance.
Of course every absolute statement has to have exceptions...
It has to call "stty" once at startup, and it has to run "mkfifo" once
at startup if the fifo doesn't happen to be still lyng around from a
previous run. In both cases, the external doesn't constitute much of a
dependency because they are both so standard. I even addressed a pretty
wide range of platform differences for the stty command so it should
work out of the box on all the bsds, osx, as well as linux. And sine
they are just run once at start up, not many times in the middle of some
loop or in an aft-used function, they dont constitute an inefficiency
either.
It was quite a challenge figuring out a way to collect, store,
manipulate, & reproduce binary data including NUL without resorting to
an external utility but there turns out to be a way to do it with read()
and a kind of brute force read-one-byte-at-a-time method where it is
possible to tell the difference between "the variable is empty because
there was no data", vs "the variable is empty because read() ate a nul
byte as a delimiter, by looking at the exit value from read(). That's
enough to let you store the information where the null byte existed,
which is all you need. to re-create it later in a file or tty.
Then there is sleep that actually sleeps not a cpu eater poll, without
/usr/bin/sleep, and generally every bashism in the book.
To be clear, my goal was to leverage bash for all it's worth, not to to
try for something like compatibility with ancient posix sh. The idea is
that bash is no longer new and exotic, and actually has a lot of
powerful tricks available built right in. It's possible to make actually
performant things in bash if you just do it right. Of course "do it
right" is pretty context sensitive. In order to satisfy the goal of
avoiding forks, you have to violate a lot of other good practices like,
this thing is a sea of global state and side effects. Fine, might as
well wallow in it then.
And now that that's working well enough that a restore of the tpdd1 util
disk works, What I really wanted was to see if I could successfully copy
this Disk Power for KC-85 disk I have. This is a TPDD client for KC-85,
that I got a working original disk and tape with an ebay purchase , and
it turns out that it does not include a way to back itself up, and when
you try to back it up some other way using Floppy on a 100 or PDD210.EXE
in dosbox etc, the copy looks fine, but the install doesn't work. You
need both the cassette and the singular irreplaceable original disk to
install it, which is a situation I refuse to accept. ;)
I *believe* I can now make a copy that's thorough enough thanks to the
FDC-mode functions, that the copy would work... and *just* when I
reached this point where I'm finally ready to try it... My KC-85 stops
working!!!! Well it's marginal. Sometimes it comes on and works, but if
I cold-reset, the screen goes blank and stays that way. "beep" doesn't beep.
Here a few pics of the Disk Power disk & tape.
https://photos.app.goo.gl/YvPBJsYnP8N3JffW7
If anyone has a working KC-85 and wants to try it... you can get the
DiskPower disk dump here
https://drive.google.com/drive/folders/1HMZNi7S7O4s6Nn7sUcFVwrBVeVIFXSvA
As well as the install file from the cassette. I think the install
program from the tape isn't as picky as the disk. As long as you get the
file onto the kc-85 by any method and run it while the drive is
connected and has the disk inside, I don't think it works. Not there is
a file with the same name on the disk, but it's a lot smaller and seems
to just be a stub or something.
--
bkw
