On Thu, Mar 2, 2023 at 3:29 PM <[email protected]> wrote: > Regarding Jeff’s comment: “TSDOS does its own thing, like John says, and > really makes a mess of it.”: > > > > Could it be that TSDOS got away with it due to inherent delays in reading > data from a disk? Reading from an SD card should be much faster and not > have those delays. Just speculating… > > >
No.. TS-DOS never got away with it, really. The dysfunction created is insidious. The immediate thing the user may see is that the file inloaded is corrupted. Oh well, you mess around and try again. Maybe you fix the extension. Maybe you don't. The dinner bell interrupts you. You pick it up later. But little do you realize the stage is set for crash/hang/data loss. At this point the RAM in general is corrupted with weird effects and eventually you will have to "cold start" to fully recover. The disconnect will result in making up theories of what happened. Sunspots. Some new CO you used the other day. Maybe an errant poke in Joe's program that you were testing for him. Maybe you blame Microsoft. So I suspect TS-DOS + Desklink avoided blame because users don't always know when or why exactly things go wrong. Or, it got away with it because fundamentally, all said and done, it's truly the user's fault for not following the official naming conventions (which they may or may not understand. Tokenization? Plain text? BASIC ASCII? Tokenized BASIC? Inload? etc). Tap the machine 3 times, proclaim "no whammies!," sacrifice a chicken and move on. -- John.
