John, You have described the issues and the resulting frustration quite accurately, and in the most entertaining method I've witnessed to date. Bravo!
Gary On Thu, Mar 2, 2023 at 4:45 PM John R. Hogerhuis <jho...@pobox.com> wrote: > > > On Thu, Mar 2, 2023 at 3:29 PM <lloydel...@comcast.net> 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. >
