Should. It has nothing in it that cares what the cpu architecture is, and a pi running the standard raspian it comes with has bash.
It's cavalier with ram, but even that is nothing today, even on a pi zero (512M) and might not even be noticeably slower. I'll probably do a few things to reduce the ram usage sooner or later just on principle, like walk the image file in chunks instead of loading the whole thing, contiguous strings instead of arrays, less copying of large things just to get small effects as a byproduct. But the hex pairs and arrays are very convenient to work with and easy to conceptualize how they map to the binary data. It reduces the mysteries a lot while debugging. -- bkw On Sat, Aug 21, 2021, 10:02 AM Stephen Adolph <[email protected]> wrote: > 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 >> >
