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
