Pretty cool stuff Brian. Do you see any roadblocks to full directory support for ts dos?
Is it tolerant to different extensions? Could you redirect a TCP port to an instance of this? On Saturday, August 21, 2021, Brian White <[email protected]> wrote: > 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 >>> >>
