I'm going to reply below inline. Daniel sysop | Air & Wave BBS finger | [email protected]
On Sun, 1 Feb 2026, B 9 wrote:
On Sun, Feb 1, 2026 at 9:21 PM <[email protected]> wrote: I hope to get my hands on the 5mhz upgrade though. As much as I love writing on my 200, it can get really sluggish after the file gets past 5k in size. I've had to work around this by chopping my files into smaller chunks to get around dit. It would certainly be nice to fill a bank with one file versus a dozen. You mean how the keyboard starts lagging behind your typing when there's a lot of text after your cursor? And there's no delay when you're appending to the end of a long file, right? The sluggishness is so bad that I think even speeding up the processor 2x may not be enough. I think a more fundamental algorithmic change is needed.
Really! That would never have crossed my mind. Makes me wonder how the text editor in CP/M handles large files. Large files in the context of this conversation. You don't think the 5k upgrade would yield much difference?
Journalists must've dealt with this issue during the device's heyday. Makes me wonder if I could poke an address as a hotfix.
There used to be technical documentation for the Kyocera Kyotronic KC-85 in badly translated English which, if I recall correctly, described how files actually get copied to shift them over when you call the OS's MAKEHOLE routine to insert bytes. (I just searched for quite a while and can't find that document anymore). It seems so terribly silly that EDIT would shift the entire document after every keystroke that I'd almost call it a bug, but of course I know it was probably a compromise Bill Gates made intentionally. It's possible the machine simply lacks the space in ROM to do something smarter. However, I have a suspicion it has more to do with needing to release a product quickly and if time was the limiting factor, then there's a chance we folks living in the future could make a patch for EDIT that fixes it. Here's one idea: EDIT could create a hole larger than a single byte when typing and only close the hole when the keyboard buffer is empty. There would be some complications, like how the hole would be displayed before it is filled or how it would word wrap, but those are aesthetic defects which, even if not addressed, would not be anywhere near as bad as not showing what it is being typed. Also, the defects would disappear once typing stopped, which after all is when you want your computer to busy itself doing background chores. —b9 P.S. I once used a text editor which included a changelog "for time-travelers stuck in reverse" that described how the behavior (of the older version) would be to only do processing when the user is typing, which those going backwards in time would surely find a charming change, like a cat finding a sudden interest in sitting on their keyboard as they begin to work.
