Strictly speaking, a TPDD is not just a "disk drive" either, it is also a file server that translates and converts RS-232 commands into disk drive "commands" such as 'direction', 'step', 'write enable' etc., calculates checksums, converts raw sectors into blocks of 8-bit data and vice versa, etc.
If we modified the TPDD firmware to match Laddie and handle diskettes created by a foreign system, would that also violate the 'principle' the way that agitates Brian so? Should raw sector data including checksums, track & sector number etc. be sent to the host to add to processing overhead or does it make more sense to let the drive strip off this information and just send the client the data that it has requested? Finally, when the M100 and TPDD were created they were a closed system and you didn't have to worry about CR/LF, EOF, NUL etc. because the Model T's were the only source of diskette data and they would handle them correctly. Once you open the same interface to transfer files created by who-knows-what system, it makes sense to take into account any incompatibilities (as TELCOM does to some extent). ----- Original Message ----- From: John R. Hogerhuis To: [email protected] Sent: Friday, February 15, 2019 12:25 PM Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version) 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.
