That was an interesting and informative tour. Thank you. You do raise some points.
-- bkw On Fri, Feb 15, 2019, 12:26 PM John R. Hogerhuis <[email protected] wrote: > > > On Fri, Feb 15, 2019 at 1:29 AM Brian White <[email protected]> wrote: > >> Since when does a disk drive decide what is and is not supposed to be >> treated as text vs binary data? The application author who decides which >> flags to use with open() does that, or the ftp client user does that by >> using the bin option *which exists*. The the drive subsystem never ever >> decides that. >> >> > I've variously called LaddieAlpha.EXE a "tpdd service" "tpdd emulator" > "drive service" "file service". it is a "disk service" but because it runs > on foreign systems > > But all versions have to "map" files to the Model T machines. Filenames, > and to various degrees, content. For example, if there is a file in the > directory that LaddieAlpha is serving with a .txt extension, it will > present in TS-DOS as a .D? file, since that is is the only way TS-DOS will > allow loading the file as a text file. > > So in that way, LaddieAlpha is not just a disk drive, it is providing the > service of creating a mapping to the files on a foreign system. And, it > must do it all of this automatically because LaddieAlpha is effectively > "headless". mComm has a GUI, but it also can't put TS-DOS on hold while it > pops a dialog. All TPDD services must respond in real time > > CO and BA files (binary files) are not modified. DLPilot had a feature > that allowed macro expansion of DO files. LaddieAlpha never has. I do > believe filtering evil NUL and EOF bytes is the first editing that Laddie > series has acquired. > > >> No one answered the question about the sewing machines which also used >> these drives. >> >> > Well. When you talk about "these drives" you need to understand that there > are 2 different drives, and 3 protocols and various tpdd services > implementing various protocols. > > In short, the protocol that LaddieAlpha implements is not the same > protocol that the sewing machines use. > > There is > > a) The Brother FB-100 /The Purple Computing Drive The Tandy Portable Disk > Drive > b) The Tandy Portable Disk Drive 2 > > Protocols: > > a) The FB100/TPDD-1 sector access protocol > b) The FB100/TPDD-1 file access protocol > c) The TPDD-2 sector access protocol > > A nod to The Known Extensions: > > a) Desklink Extensions > b) Ken Pettit and John Hogerhuis extensions > > The Brother FB-100, Purple Computing and Tandy Portable Disk Drive are > really all the same drive to my understanding. > The TPDD-2 is the only one that implements its sector access protocol. > AFAIK the only applications that use it are the ones that came with the > drive. > > The Brother sewing machines access the drive at a sector level, not a file > system level and read/write hex formatted sector images via the FB100 > sector access protol. There are FB100 sector access protocol emulators for > use with the sewing machines. AFAIK there is no overlap in use of emulators > between the Brother sewing community and Model Ts, because of this reason. > > That said I believe mComm does implement the FB100 sector access protocol > because it is needed to use the spellcheck dictionary. Maybe that would > make it usable with the sewing machines, but it seems ill advised, as there > are dedicated applications that are supported for that community. > > I guess if you're trying to find something other than a contrived scenario > where EOF and NUL removal is harmful you need to look for those using TPDD > emulators with other vintage computers. For example, I understand there is > a TPDD client for the Cambridge Z88 and maybe some other machines. > > I doubt any other machines use our specific .D* extension filenames. They > probably use 3 character extensions. But who knows. > > I haven't been contacted by anyone using LaddieAlpha with any other > machine than the Model Ts or WP-2. But it's possible. > > "AFAIK "good programming practices and principles" are suggestions and >> recommendations, not laws." >> Indeed. >> 1) I never said anything else. >> 2) Why is a "good practice" good in the first place? For a reason, not >> because god said so or something. Something is good or bad because of the >> harm it lessens or increases. >> > > And something I've learned in my career of 25 years as a programmer is > that those rules balance goods and bads, not just avoid harms. The rules of > thumb/principles interact with each other, with use cases and with > requirements, and interaction issues with systems you cannot control. > > A good programmer seeks a balance. > > -- John. >
