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
>
>
>
>

Reply via email to