Stephen: I'm not familiar with CP/M or its editors. Were the sectors on the disk used as a form of virtual memory pages? If so, it would seem that having 16K sectors might be a disadvantage as only four could fit in memory at a time. Does REXCPM let you tweak the sector size? How big is the "disk" REXCPM offers?
Ken: That is an amazing write up of how EDIT manages memory. Is all that documented somewhere or did you figure it out yourself? (Virtual T continues to astonish me with hidden uses.) Everyone: I stumbled upon a blog of someone who was writing an 8-bit text editor <https://workdad.dev/posts/building-a-text-editor-the-gap-buffer/> and, like us, he found that inserting characters at the beginning of a 10K file was too slow — even though his Z80 is running seven times faster than our processors, at a whopping 18 MHz! He has a helpful tip to use "gap buffers" to avoid shifting the entire document. Gap buffers do surprisingly well <https://coredumped.dev/2023/08/09/text-showdown-gap-buffers-vs-ropes/> when compared to fancy-dancey high-tech data structures like Ropes and Piece Tables. They also have very little memory overhead and are dead simple to implement. I have no idea how difficult it would be to modify EDIT to use gap buffers. Probably, *very*. Gap buffers also don't address the most common complaint: slowness from word-wrapping. However, it's something to think about as it would allow folks to edit large text files on their Model T's. Stephen: Since REXCPM is replacing the entire 64K address space, could I use it to boot into and test a modified version of the main system ROM? Or is there something different that would be better for that? —b9 On Wed, Feb 4, 2026 at 7:48 AM Kenneth Pettit <[email protected]> wrote: > Hi Steve, > > This is close to what goes on. But actually the ROM doesn't move every > other file up by one byte. > > When you edit a file, the ROM will: > > 1. First move ALL .DO and .CO files that are higher in RAM address all the > way to the top of free memory. > 2. Fill in the region between the end of the file being edited and the > next highest file (now moved to the top of memory minus the size of all the > files moved) with zeros. This allows the ROM to know where the actual end > of the file being edited is located. > 3. As you are typing new data into the edited file somewhere other than > the end, the ROM moves only the text from that insertion point to the first > zero (i.e. the end of the current file) up one location via memory move. > 4. Insert the newly typed character. > 5. Call the routine to calculate word wrap and display redraw based on > word wrapping. > > Then when you are done editing a file, the ROM will: > > 1. Determine the end of the edited file by looking for the first zero byte. > 2. Move all files now sitting in high memory (above the big block of > zeros) down to the proper location, right after the end of the file being > edited). > 3. Update the directory listing with new file addresses, etc. > > You can verify this in VirtualT by starting from a cold boot (i.e no > files), opening the Memory Editor window and performing the following: > > 1. Launch TEXT and give a new filename like A or something. > 2. Type "123456789" and watch as the ROM updates the memory via the > Memory Editor window. > 3. Hit F8 to stop editing the file. > 4. Go to TEXT again and specify a different filename like B. > 5. Watch the Memory Editor window ... the "123456789" disappear because > they were moved to HIGH RAM and get replaced by zeros. > 6. Type some text like "abcdef". > 7. Hit F8 and watch the "A" file text be relocated back to low memory, > > Ken > > On 2/4/26 6:29 AM, Stephen Adolph wrote: > > hi all, > I think what all modelT computers do when they edit, is that they > > 1) create a "hole" in the ram file of 1 character size > 2) insert the character in the ram file > > For a .DO file, this means moving all the files stored in RAM that are > ABOVE the text entry point up by 1 byte. > That is a lot of memory moving to do, if there are a lot of bytes stored. > Certainly the case with a single large file, but also the case with many > files stored above. Luckily .DO files are stored above .BA files. And .CO > files, which are rarely use and are typically small, may not have a large > impact even though they are above .DO files. > > If CP/M editors are using disk space to hold the file ( I think they do) > then the I/O speed is a big factor but the block of data is limited to the > sector size on the disk ( I think). There is probably some clever method > to use disk blocks in a nice way to make editing faster. > > REXCPM has the advantage that disk IO runs at RAM speed, but the disk > sector is large at 16kb. > So, I don't know relatively how a text editor in REXCPM / CP/M 2.2 would > fare? But a worthy experiment! > > Steve > > > On Wed, Feb 4, 2026 at 9:03 AM bput <[email protected]> wrote: > >> On Mon, 2026-02-02 at 07:24 -0800, [email protected] wrote: >> > > 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? >> > > >> >> My Kaypro (runs CP/M 2.2) handles large files quite slowly but not due >> to memory; that is due to slow operation of the 5.25inch floppy disk. >> The Z80 CPU in that machine runs at 4 MHz. >> >> The only text editor that I'm aware of that allows editing of files >> larger than free memory is WordStar; it writes out pieces of the >> document (or text file) to disk to let you focus on the "current" page. >> That causes it to slow down quite a bit. >> >> There are several text editors around that do not do this, but keep the >> entire document in memory. That makes the editor lightning fast but >> restricts you to document size no larger than free memory (on a 64K >> machine, probably around 50K or so). Of course, when you needed to >> save that document to the floppy disk, you may as well get you a cup of >> coffee while you waited for that to complete LOL >> >> I have not tried it on REXCPM but I'm quite sure we will see the same >> results. REXCPM likely has better I/O performance so I think that >> would make it faster. >> >> >> Regards, Bert >> >> >> >> >
