So would this run on a raspberry pi? I would guess so?
On Friday, August 20, 2021, Brian K. White <[email protected]> wrote: > > 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 >
