Re: [M100] TPDD Client in pure bash
On 8/21/21 8:38 PM, Ken Pettit wrote: On 8/21/21 3:04 PM, Brian K. White wrote: One thing I haven't tested yet is WP-2 compatibility. If WP-2 pads/un-pads it's filenames the same way, then I'll need to adjust that to encompass 8.2 or 8.3 or whatever WP-2 does. Plus WP-2 adds an opcode extension for "Previous Directory Entry" that must be supported for it to work correctly. Ken It's a client not a server s the WP-2 compatibility it needs to worry about is reading filenames from a disk written by a WP-2, and writing filenames to a disk that a WP-2 might try to read. -- bkw
[M100] Model 100 folding Leg Extensions (3D Printable)
Been playing with my 3D Printer too much… I’ve used pencils, plastic coat hangers and other materials to make let extensions for my Model 100. I designed a folding leg extension. This allows me to keep the legs on the computer when I store it in its plastic slip case. No more lost peg legs for me. They open and lock at around 40mm (1.5 inches). Pictures are on the site below. Remember this is a work in progress. Since the object is fairly small it may take more tweaking to work with every printer and filament type. Comment and Remixes are welcome. This is fun project for me! Here is a link: TRS-80 Model 100 Custom Folding Leg Extensions by dgrissom - Thingiverse Please excuse if I get multiple posts. Been have email woes today David Grissom Sent from Mail for Windows
Re: [M100] TPDD Client in pure bash
On 8/21/21 8:44 PM, John R. Hogerhuis wrote: " Plus WP-2 adds an opcode extension for "Previous Directory Entry"" The WP-2 works with a real TPDD so that's not an extension :-) But you're right, you have to implement that for WP-2 to work, along with 8.2 names. -- John. I was working from the software manual which does not mention that. Maybe it's just TPDD2 ? I do have a WP-2 and a TPDD2 so I can test all this so the wondering is just idle. Strangely that same software manual that says 26-3808 on the front and has the S-Record bootstrap and dip switches and 100K format in it, actually flubs and calls it the "Portable Disk Drive 2" once on the page about the space management table. It's like maybe they wrote both manuals at the same time or at least wrote the tpdd1 manual after the 2 was out or at least in the works. -- bkw
Re: [M100] TPDD Client in pure bash
On 8/21/21 5:44 PM, John R. Hogerhuis wrote: The WP-2 works with a real TPDD so that's not an extension :-) Ahh, good point, I guess I have to admit that you are right. :) I hadn't thought about it that way. Ken
Re: [M100] TPDD Client in pure bash
" Plus WP-2 adds an opcode extension for "Previous Directory Entry"" The WP-2 works with a real TPDD so that's not an extension :-) But you're right, you have to implement that for WP-2 to work, along with 8.2 names. -- John.
Re: [M100] TPDD Client in pure bash
On 8/21/21 3:04 PM, Brian K. White wrote: One thing I haven't tested yet is WP-2 compatibility. If WP-2 pads/un-pads it's filenames the same way, then I'll need to adjust that to encompass 8.2 or 8.3 or whatever WP-2 does. Plus WP-2 adds an opcode extension for "Previous Directory Entry" that must be supported for it to work correctly. Ken
Re: [M100] TPDD Client in pure bash
On 8/21/21 1:01 PM, Stephen Adolph wrote: Pretty cool stuff Brian. Do you see any roadblocks to full directory support for ts dos? Nope. Easy. Is it tolerant to different extensions? It doesn't care about the filenames at all except for the minimum necessary to be compatible with "Floppy" (and thus, all other dos's which themselves all had to be compatible with "Floppy") The drive just has a 24 byte field and it doesn't care what you put in there except the first byte can't be nul. But "Floppy" writes filenames in a padded 6.2 form, and expects to read filenames in that form, and only because of that, all other dos's and clients that wish to be compatible with "Floppy" must also do that. So this does that too. But it's only a default which can be disabled, and even while enabled it only applies to any filenames that already fit within 6.2. So, if it see's "A.BA" it will pad that when writing to the disk, and un-pad it when reading back from the disk. But if it sees A_long_name.v1.2.tar.gz it doesn't change it other than to clip it down to 24 bytes if it was longer. One thing I haven't tested yet is WP-2 compatibility. If WP-2 pads/un-pads it's filenames the same way, then I'll need to adjust that to encompass 8.2 or 8.3 or whatever WP-2 does. An option to care even more about the names, even munge the data in some cases like Laddie does might not be a bad idea. But only as an option and probably not enabled by default. I also just discovered I'm not handling the filenames well enough and it's currently impossible to for the user to enter a filename with spaces in it. It's because of the cheap trick I used to allow multiple commands on one commandline separated by ";". But I'll fix that shortly. Could you redirect a TCP port to an instance of this? That is worded like you mean the connection to the user, which makes no sense to me, so I'm going to pretend you meant the connection to the drive. Let's try it... $ socat TCP-LISTEN:35000,fork /dev/ttyUSB0,raw & [1] 409576 $ $ socat pty,link=ttyV0,raw tcp:localhost:35000 & [2] 409578 $ ./pdd ttyV0 TPDD(opr)> ls -- Directory Listing -- Floppy_SYS11520 SETRAM.BA 208 --- 88320 bytes free TPDD(opr)> Yes. ;) (Ok I cheated a little. I did have to make a change to allow specifying a tty device outside of /dev, otherwise you'd have had to run the 2nd socat as root so that you could create "/dev/ttyV0" instead of just "ttyV0". So once you re-download, you can do this example too.) The first socat provides a tcp server listening on port 35000, connected to the real drive. The second socat provides a virtual serial tty "ttyV0" in the current directory, connected to host:35000 as a client. Finally I told pdd to use "ttyV0" instead of searching for /dev/ttyUSB* Another option, ksh or zsh can do tcp natively, without needing socat or netcat etc. But the code would need a little adjusting for other shells. ksh and zsh are both advanced shells that support all the same fancy stuff I'm using in here, so most of it is fine, but there are some differences in the details so it wouldn't work out of the box without a little fiddling. -- bkw
Re: [M100] TPDD Client in pure bash
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 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 > wrote: > >> So would this run on a raspberry pi? I would guess so? >> >> >> On Friday, August 20, 2021, Brian K. White 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 >>>
Re: [M100] TPDD Client in pure bash
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 wrote: > So would this run on a raspberry pi? I would guess so? > > > On Friday, August 20, 2021, Brian K. White 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. >>
Re: [M100] TPDD Client in pure bash
So would this run on a raspberry pi? I would guess so? On Friday, August 20, 2021, Brian K. White 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 >
Re: [M100] TPDD Client in pure bash
This is very cool, love the effort on all of this to not use anything external but mostly I love the animations. Thanks! Brian On Fri, Aug 20, 2021 at 9:38 PM Brian K. White 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 >
