The TE text editor on 512 KB RAM

[ladislau szilagyi]

Hi all,

I asked some weeks ago a question : “which is the best CP/M text editor?”.

Phillip Stevens responded : te (Miguel Garcia’s text editor).

Yes, it was fast, elegant, user-friendly, Miguel had done a very good job!

But, it had a major limitation : it could not handle large files ("te" limits the number of text rows to 512, and because all the editing is done in the RAM memory, also the size of the file is limited to 20KB).

It was a frustrating reality for me, because at the time I needed a quick editor capable to handle large files... eventually, I used WordStar, but it was a disappointing experience because the slow text search/browse performance of WordStar. It kept ON continuously the CF board leds...

A week ago, I needed again to edit a large file...but, this time, I preferred to build my own text editor.

I was lucky to have a 512 KB RAM + 512 KB ROM memory board.

An idea hit me: What if I could use this huge 512 KB RAM to “store” the text ? 

I started to work on this...

First, I made CP/M run with the 512KB board. Not ROMWBW's CP/M, but the “usual” CP/M. 

Basically, I wrote a “CP/M booter”, burned-it into the module’s EPROM, and used my "large-TPA" CP/M that loads at 0D000H.

So, now I have the following configuration : SC112 backplane + SC108 CPU (without ROM, RAM) + SC110 (SIO) + 64 MB CF board + 512KB memory board (with the EPROM containing the CP/M booter).

Then, I took my dynamic memory allocator from RTM/Z80 and modified-it to be able to “manage” the 512KB RAM space. Practically, I used the last 28 slices of RAM (each of 16KB) to do this. The (8000H-C000H) "local" 16KB memory area is used as a “buffer” to access the 512KB RAM's slices.

The next step : I moved the “te” text editor source files to CP/M and adapted/changed them in order to be able to compile and link them using the HiTech C tools. Tricky business... but it eventually worked.

Then, in the editor source files, I changed all the "malloc" and "free calls, substituting them with my 512KB dynamic memory allocator calls"(and all the stuff neede to "switch" between the 512's 16KB slices). 

Testing-it was difficult...but now it works.

At last, I have a “custom” TE.COM which can handle large files. Of course, it runs only with the 512KB module, but it can edit any file that fits into 512KB RAM, with up to 8000 lines.

And, it’s fast! The search/browse is quick (all happens in memory, without disk I/O...).

The only annoying thing is that, at TE.COM launch, I must wait until all the text file is loaded in RAM... it takes some time...

I used-it recently to edit my BDOS+BIOS file (bdosbios.z80 : 168 KB, 4633 rows).

regards,

Ladislau

[floppys...@gmail.com]

Good work Ladiuslau, I'm happy if you are happy with TE. :)

Just a couple of comments:

> But, it had a major limitation : it could not handle large files ("te" limits the number of text rows to 512, and because all the editing is done in the RAM memory, also the size of the file is limited to 20KB).

As documented in the TE.CF file, TE could be configured to manage upto 4096 lines with TECF:

> # How many lines can edit: 256..4096 -- each
> # empty line occupies 2 bytes of RAM
> editor.maxLines = 512

The size of the file TE is able to edit depends of the CP/M TPA.

In my Amstrad PCW with CP/M Plus the TPA is around 61 KB, so TE is able to edit a file of around 40 KB.

Some CP/M emulators have even a bigger TPA.

[Phillip Stevens]

Ladislau wrote:

I asked some weeks ago a question : “which is the best CP/M text editor?”.

te (Miguel Garcia’s text editor).

Yes, it was fast, elegant, user-friendly, Miguel had done a very good job!

But, it had a major limitation : it could not handle large files.

I was lucky to have a 512 KB RAM + 512 KB ROM memory board.

An idea hit me: What if I could use this huge 512 KB RAM to “store” the text ?

That's a great application, and solution to a real issue using more RAM.

So, now I have the following configuration : SC112 backplane + SC108 CPU (without ROM, RAM) + SC110 (SIO) + 64 MB CF board + 512KB memory board (with the EPROM containing the CP/M booter).

Then, I took my dynamic memory allocator from RTM/Z80 and modified-it to be able to “manage” the 512KB RAM space. Practically, I used the last 28 slices of RAM (each of 16KB) to do this. The (8000H-C000H) "local" 16KB memory area is used as a “buffer” to access the 512KB RAM's slices.

Do you think that you would have enough additional RAM for TE using the 128kB RAM  in the SC108, SC114, and PickledDog RAM/ROM products?

If it was sufficient to use TE with an additional 64kB of shadow RAM, on top of a normal CP/M TPA, then it would be good test of a "big" RAM application on the cheaper 128kB RAM / 32kB ROM solutions.

Some time ago I wrote a little RAM copy stub (32 Bytes) to use the extra RAM, and integrated it into the z88dk RC2014 crt0 startup.  But, after a while I disabled it by default, when I realised there are actually no applications available in CP/M or otherwise to my knowledge that need more than ~48kB of RAM.  If any old style CP/M application needed more, it just used disk based overlays.

Looking at the code now, I'd probably add an indirection address to enable the stub to be relocated to anywhere in the address space.  Since it can copy RAM from any address to any address, it doesn't matter where it is stashed.

There's a reserved CP/M location at $003B-C. Perhaps that is a good place to put the current location of the RAM copy stub?

At last, I have a “custom” TE.COM which can handle large files. Of course, it runs only with the 512KB module, but it can edit any file that fits into 512KB RAM, with up to 8000 lines.

What do you think, would an additional 64kB on top of your normal TPA be useful?

Cheers, Phillip

[Phillip Stevens]

Phillip  wrote:

Looking at the code now, I'd probably add an indirection address to enable the stub to be relocated to anywhere in the address space.  Since it can copy RAM from any address to any address, it doesn't matter where it is stashed.

There's a reserved CP/M location at $003B-C. Perhaps that is a good place to put the current location of the RAM copy stub?

Actually, thinking for a second, $003B would be bad for 8085 based CP/M, as there's a conflict with IRQ7.5.

Much better would be $0058-9 as the fixed address location. Its also reserved in CP/M, and likely to be unused everywhere.

[Bill Shen]

Ladislau,
That's great work.  As you know, a commented assembly program can easily exceed 20K, so an editor with 100K+ capacity is a practical requirement.  Is your modified TE.COM available for testing?  I have a small Z80 SBC, ZRC, with 14.7MHz Z80, 2 meg RAM, emulated 6850 serial and CF disk.  It was designed to run ROMWBW, but all software (other than the 64-byte bootstrap) is stored in CF disk so a different operating environment can be created easily by change out a different CF disk.  Even while running ROMWBW, it still has 1 meg of spare RAM that I don't know what to do with.  This board is my next candidate to port RTM-Z80 because the CPLD has extra logic for 5mS timer and mode 2 interrupt.  I'm interested to try your modified TE.COM if you tell me what modification is needed.

  Bill

PS, an application I thought about now and then is the "Bad Apple!" video that can be stored in the 2meg RAM and play back on a 128x64 OLED display.  Sigh, there are so many projects I like to do...

[ladislau szilagyi]

Hi Phillip,

I will think how to adapt TE also for SC108 and other configurations that have 128KB RAM. 

It will be difficult, because these configurations switch the full 64 KB RAM, not only 16KB "slices", as the 512 KB module does...

regards,

Ladislau

[ladislau szilagyi]

Hi Miguel,

yes, you're right, TE can be configured to accept 4096 lines... but, with an average line "size" of 20 bytes, that will be an 80KB file, too big for any TPA.

How do you recommend me to proceed for publishing the "512KB TE"? 

Should I simply add a folder in my RTM/Z80 GitHub page?

I would prefer to let you add a branch in your TE GitHub page and populate-it with my version...what do you think?

Ladislau

[ladislau szilagyi]

Hi all,

for those who want to try the TE on 512KB RAM, let's make the first step: boot the CP/M for a configuration that has the 512KB RAM+ROM module and a SIO/2 board (e.g. SC110).

For this:

1. Those who have an 128MB CF, please download from my RTM/Z80 GitHub page the file CPM/BOOT/ CPM_boot_512_SIO_CF128.hex and burn-it on the memory module's EPROM.

2. Those who have an 64MB CF, please download from my RTM/Z80 GitHub page the file CPM/PutSys/ SIO_PutSys_CF64_CPM_DA00H.hex , execute it to store an extended TPA CP/M on your CF, then download from my RTM/Z80 GitHub page the file CPM/BOOT/ CPM_boot_512_SIO_CF64.hex and burn-it on the memory module's EPROM.

Then try to boot RC2014, CP/M will start, you will have the A> prompt.

If it works, you have set-up the stage to execute my "512KB TE".

regards,

Ladislau

[Richard Deane]

How about implementing a version for cpm3 using rsx and the associated bank switching support, then it would be portable across systems. 

Richard 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/18cbfc7c-07b4-48e4-aa79-d03183bc976dn%40googlegroups.com.

[Alan Cox]

On Tue, 2 Nov 2021 at 07:52, Richard Deane <rwd...@gmail.com> wrote:

How about implementing a version for cpm3 using rsx and the associated bank switching support, then it would be portable across systems.

CP/M 3 doesn't expose the bank switching to the application, nor the information needed to use it (address range, number of banks, interrupt safety, allocation and free). It even tries to block you from using the BIOS call in question via the BDOS interface.

In fact no CP/M operating system proper provided a bank switching interface or even a block get/put interface beyond a RAMdisc via the file system. ROMWBW does sort of provide one, but it's also not one that an application can use in any useful fashion, it's merely sufficient for a certain class of controlling OS type applications.

Alan

[floppys...@gmail.com]

Hi Ladislau,

I think adding a branch to the TE repository with your modifications would be a mess, having into account that you have done changes to the sources in order to port it to the HiTech C compiler.

I think the best option should be doing a fork and add your changes.

[Richard Deane]

Alan,

Thank you for the explanation, I had obviously over-assumed the functionality of RSX, read about them on Amstrad, and used trivial ones like vt100dyn.

Richard

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAK9X0%2Bs_%2B5YMd7uHx_LW4gZPtKvJk7EnMEgUgv2oNCRJeSPZ%2Bw%40mail.gmail.com.

[Phillip Stevens]

Hi Ladislau,

Ladislau wrote:

I will think how to adapt TE also for SC108 and other configurations that have 128KB RAM. 

It will be difficult, because these configurations switch the full 64 KB RAM, not only 16KB "slices", as the 512 KB module does...

The only way I can think of is to build some 8kB or 16kb pages, and then swap them to a working space. If your memory manager can do that then it should be fairly simple.

 

Phillip  wrote:

Looking at the code now, I'd probably add an indirection address to enable the stub to be relocated to anywhere in the address space.  Since it can copy RAM from any address to any address, it doesn't matter where it is stashed.  Much better would be $0058-9 as the fixed address location. Its also reserved in CP/M, and likely to be unused everywhere.

I've updated the z88dk RC2014 RAM driver code to support the $0058 base address, and indirect calling via this address. Unfortunately, I can't make the initial writing of the asm_shadow_copy function address into the $0058 location automatic, as the ROM builds don't toggle themselves out during their crt0 process. So the initialisation will need to be completed in a CP/M bios boot process, for example. But, then copying to and from shadow RAM is easy at any size up to 64kB, and the asm_shadow_copy function can also be relocated anywhere in RAM you feel like.

When I've dug myself out of another math hole I find myself lost in, I'll look into what you've done with TE and try to help out.

Cheers, Phillip

[ladislau szilagyi]

Hi Phillip,

I think I have found a solution to build a "custom" TE editor for any RC2014 hardware conformant to SC108's 128KB RAM.

I'm working on it. 

Unfortunately, it will work only for my "custom" CP/M, with optimized TPA space for the 64MB CF's. 

I will explain why.

This version of CP/M (which, by the way, was published on my GitHub page some time ago) has also the vital advantage of having a small (60H) area, just below FFFEH, not filled with BIOS code.

It is there, on top of the 64KB RAM, where I will store the "shadow" code that will allow accessing the upper 64KB RAM.

This way, I will have the usual "malloc" area in the TPA (which, by the way, is 2KB and half larger than the "classic" RC2014'CP/M) plus the upper 64KB (60H less) handled by my new "custom" allocator (the allocation protocol will be: try first malloc, and if fails, use the "new" allocator to get a buffer in the upper 64KB RAM) .

I hope this trick will allow 80-100KB files to be handled by this 128KB TE. 

It will work for any hardware conformant to the memory mapping mechanism of SC108.

But, I have now to write & test the "shadow" code, then my new "allocator", then to modify/adapt the TE code, and then, at last, test the whole stuff...wish me good luck!

regards,

Ladislau

[Phillip Stevens]

I think I have found a solution to build a "custom" TE editor for any RC2014 hardware conformant to SC108's 128KB RAM. 

This version of CP/M (which, by the way, was published on my GitHub page some time ago) has also the vital advantage of having a small (60H) area, just below FFFEH, not filled with BIOS code.

It is there, on top of the 64KB RAM, where I will store the "shadow" code that will allow accessing the upper 64KB RAM.

This way, I will have the usual "malloc" area in the TPA (which, by the way, is 2KB and half larger than the "classic" RC2014'CP/M) plus the upper 64KB (60H less) handled by my new "custom" allocator (the allocation protocol will be: try first malloc, and if fails, use the "new" allocator to get a buffer in the upper 64KB RAM) .

But, I have now to write & test the "shadow" code,

Welcome to look at this asm_shadow_copy code, that allows copy from anywhere to anywhere with up to 64kB per copy. Works the same as ldir, with the Carry flag signifying copy direction.

The C interfaces assume that that the address of asm_shadow_copy code is stored in $0058, and jump to it where ever it is actually stored, for example just below $FFFE as you require.

 

then my new "allocator", then to modify/adapt the TE code, and then, at last, test the whole stuff...wish me good luck!

Always the most time consuming part... ;-).

Good luck.

P.

[floppys...@gmail.com]

Hi guys,

I'm amazed with your work around my humble TE!

Wow, lets roll the ball!

[ladislau szilagyi]

Hi all,

I uploaded on my GitHub site ( https://github.com/Laci1953/RTM-Z80 ) , on the folder CPM/te , the TE editor versions for SC108 128KB (te128.hex) and for the 512KB RAM + 512KB ROM memory module (te512.hex)

See the readme.txt

Ladislau

[ladislau szilagyi]

Hi all,

here are some details about these new TE editor versions:

Settings:

128KB - up to 2048 lines, 50x120 screen, VT100 compatible, with WordStar style keyboard

512KB - up to 8192 lines, 50x120 screen, VT100 compatible, with WordStar style keyboard

Design details and some constraints:

1. For the 512KB version: 

To handle the memory allocation requests, a new memory allocator was written. 

How it works:

The 512KB RAM module uses 32 16KB "virtual" RAM pages, mapped to one of 4 "physical" pages 0000-3FFF, 4000-7FFF, 8000-BFFF and C000-FFFF. Any virtual page can be mapped to any physical page.

The memory physical area from 8000H to BFFFH (let's name-it "work area") is used to load one of the 32 "virtual" 16KB pages from the 512KB RAM, and the memory allocator returns a pointer to the available buffer and a byte containing the index of the 16KB page that contains this buffer (let's name-it "page index"). 

When that buffer needs to be accessed for read/write operations, the 16KB RAM page must be first loaded into the "work area", using a function call with the "page index" as parameter.

Of course, to "free" the allocated buffer, this "page index" must be provided too.

Text files up to 350KB can be edited.

The 521KB version can be run on any CP/M version, regardless of its TPA area size.

2. For the 128KB version: 

To handle the memory allocation requests, a new memory allocator was written. 

How it works:

The 128KB RAM is divided into 2 "virtual" 64KB banks: the lower and the upper bank. A port selects which "virtual" 64KB RAM bank is mapped to the physical 64KB RAM.

In order to execute code that switches from the lower to the upper bank (and back...), that piece of code must be present at the same physical address in both of banks (the so called "shadow code)". It is impossible to store shadow code in the upper bank using only programs resident in RAM, for this only ROM-based code may help; my version of SCM contains an API function ( $2B ) which moves a byte to a given address of the upper RAM bank. This API call is not documented (it cannot be found in the SCM manual), I've found-it by browsing through the SCM source code... 

Therefore, by using this $2B SCM API call, the shadow code can be moved to the upper RAM bank.

But, for the memory allocator, we have also another important constraint: the shadow code must be stored in top of the physical 64KB RAM, in order to offer as much possible RAM available to be allocated (storing at the bottom of the physical 64KB RAM is out of question, we have there the 100H BIOS buffers area). There is only one possible solution: storing a small shadow code on top of CP/M's BIOS. My shadow code is less than 40H. 

Now, studying the "classic" RC2014 CP/M that is currently used with 64/128MB CF's, I discovered that the BIOS "eats" practically all the space to FFFF ! There was no room for my shadow code! 

But, I remembered that I built recently a "custom" CP/M for RC2014 systems that use a 64MB CF. This version of CP/M loads its BDOS at DA00, and has also the advantage of having a small "free" RAM area on top of the BIOS (around 40H ! ). This was a perfect match, I stored there (FFA0 - FFFF) the shadow code. This allows also having (almost) 64KB RAM available to be allocated in the upper RAM bank! 

If the usual call to malloc fails, the new allocator accesses the upper 64KB RAM bank and allocates there the buffer. 

Besides the address of the buffer, a byte containing the RAM bank index is returned too (0=lower 64KB RAM, 1=upper 64KB RAM).

To access a buffer reserved in the upper 64KB RAM bank, special functions must be used to read/write a byte, a word, or a string.

 

Text files up to 70KB can be edited. 

But, this comes with a cost: when opening a file to be edited, the editor reads all the text and store this text in the dynamic memory, and this takes time, because every single byte that has to be moved to the upper RAM bank is not simply moved, as in case of the lower bank, but is passed to the shadow code in order to be stored in the upper RAM bank. Also, a buffer for every new text line that is read must be allocated, and this allocation means also accessing the shadow code, in order to manage (read/write) the data structures that handle the available memory pool.  

Once the file is read, the browse/search operations prove to be quick (compared for example with the performance of WordStar), because no more file read operations are needed, all the text is in the memory.

As a conclusion:

 

- The TE editor 128KB version will work only for RC2014 systems provided with 64MB CF

- The TE editor 128KB version will NOT work with the "classic" RC2014's CP/M, my "custom" large TPA CP/M must be used (use CPM/PutSys/SIO_PutSys_CF64_CPM_DA00H.hex)

- The TE editor 128KB version will work only with SC108 boards (or compatible) provided with a SCM version containing the (undocumented) API function $2B (write A to address DE on Upper 64KB RAM). I received my SCM EPROM in July this year, an it contains this function. I hope that also older versions of SCM contain this function.

Comparing the two versions of TE (128KB vs. 512KB), the 512KB version is by far the best. 

First, the size of files that can be edited is larger.

Then, the initial file opening when starting the editor is faster.

But, I consider both versions of the TE editor as a step forward in the right direction, allowing larger files to be edited in memory, with an elegant an efficient user interface.

regards,

Ladislau

  

[ladislau szilagyi]

Hi all,

for those of you who prefer using the "arrows" keys instead CTRL S, CTRL D, CTRL E and CTRL X, I uploaded the te128_arrows.hex and te512_arrows.hex files on my GitHub page https://github.com/Laci1953/RTM-Z80/tree/main/CPM/te .

Perhaps now I can hope that someone will eventually test these versions of the TE editor on RC2014...

I also hope that Miguel will agree to publish these source files...

regards,

Ladislau

[ladislau szilagyi]

Hi Phillip,

I just uploaded on my GitHub page ( https://github.com/Laci1953/RTM-Z80/tree/main/CPM/te  ) a version of TE customized for your 32KB ROM + 128KB RAM memory module (MM).

I tested it on the following configuration: SC112 + SC108(without EPROM and RAM) + SC110 + MM(with my CP/M boot EPROM) + 64MB CF

It accepts also the "arrow" keys, besides the "normal" CTRL_S,X,E,D.

I edited text files up to 80KB.

You may find my CP/M boot EPROM (  CPM_boot_MM_SIO_CF64.hex ) in https://github.com/Laci1953/RTM-Z80/tree/main/CPM/BOOT 

For all those who want to use the 128KB version of TE, I prepared CP/M boot EPROMS ( in in https://github.com/Laci1953/RTM-Z80/tree/main/CPM/BOOT ) containing also the necessary code to setup the "shadow" code.

Therefore, TE-128 & TE-MM will work on any RC2014 configuration that contains SC108 or MM using this EPROM, but will work also on SC108 with SCM versions accepting the $2B API call.

regards,

Ladislau

[ladislau szilagyi]

Hi all,

I just published the source files ( https://github.com/Laci1953/RC2014-CPM/tree/main/te/SOURCES )

Ladislau

[ladislau szilagyi]

Hi all,

I made an improvement for the TE editor.

In the old TE version, the TAB characters were automatically transformed to BLANKS. 

That resulted in poor usability (the TAB indentation was lost).

I fixed this, now the TABs are handled appropriately, and the text indentation is conserved.

You may choose between two TAB indentations (4 or 8 chars), in the command line: >TE file.ext [ 4 | 8 ] ; default is 8.

I published the updated versions (sources and executables: TE128 & TE512) on GitHub ( https://github.com/Laci1953/RC2014-CPM/tree/main/te ).

Ladislau

[ladislau szilagyi]

Hi all,

I published in https://github.com/Laci1953/RC2014-CPM/tree/main/PutSys a CP/M version (putsys.hex files) that allows TE128 being executed also on systems with 128MB CF.

This version of CP/M does not use interrupts; the RAM space gained (the BIOS "top area") was used to host the "shadow" code used to move bytes from/to lower/upper 64KB banks.

In the folder you will find CP/M systems configured for all combinations of (CF64, CF128, SIO, KIO, ACIA).

Ladislau

[ladislau szilagyi]

Hi,

I published here https://github.com/Laci1953/RC2014-CPM/tree/main/te , a file named "How to install", describing the details of installing the TE text editor on 128KB/512KB RAM Z80 computers.

Here is the contents of this file:

----------------------------------------------

Here are the necessary 3 steps, depending on your specific Z80 computer's hardware:

1. The boot (E)EPROM

This is a mandatory step only for computers provided with the 512KB ROM + 512KB RAM board.
(For computers provided with Steve Cousins SCM, e.g. SC108, this step is not mandatory, you can boot CP/M from SCM, so go to step 2)

For computers provided with 512KB RAM, you need to boot CP/M at power ON, in order to use the enhanced HiTech C compiler.
Why? Running CP/M from ROMWBW will not allow the TE editor to be executed !

Choose the appropriate .hex file (according to your RC2014's serial type & CF size), and burn-it to an (E)EPROM, then insert the EPROM to your 512KB RAM + 512KB ROM board.
Example: you have a Z80 computer with 512KB RAM, an ACIA serial and 64MB CF. You will choose the CPM_boot_512_ACIA_CF64.hex file.
Now, at power ON, the CP/M directly boots.

2. The smaller CP/M (for 128KB RAM Z80 computers)

This step is mandatory only for 128KB RAM computers.
(For computers provided with 512KB RAM + 512KB ROM boards, you may use the "original" CP/M, go to step 3, but read also the final NOTE)

Why is this needed? The RC2014 "original" CP/M is too "fat", it consumes all the RAM space till 0FFFFH, and because of that, there is no space, at the top of RAM memory, to store the "shadow" routines, needed to move bytes between the two 64KB RAM banks.

To change your CP/M with the smaller CP/M, to be able to run the TE editor for 128KB RAM Z80 computers, you need to
paste on the terminal the appropriate .hex file, from https://github.com/Laci1953/RC2014-CPM/tree/main/PutSys.
Example: you have an 128KB RAM Z80 computer with an ACIA serial and 64MB CF. You will choose the ACIA_PutSys_CF64_CPM_DA00H.hex file.

Then:
*g8000<CR>

Now, the CF contains a smaller CP/M.

3. Creating the TE editor executable

This step is mandatory for all computers.

You need to copy the appropriate .HEX file (according to your hardware), here I will use the "generic" name, then execute:

LOAD TE

Now, you have the TE text editor installed.

-----------------------------------

Ladislau

[ladislau szilagyi]

Hi,

I published here https://github.com/Laci1953/RC2014-CPM/tree/main/te , a version of the TE editor adapted for SC114.

Ladislau

[ladislau szilagyi]

Hi,

The basic idea of the TE editor is to work directly with text files stored in the RAM memory; the advantage is the high processing speed ( e.g. when using the "next page" command repeatedly ). 

The problem is the long time taken until the complete loading of the text file from the disk.

Until now, the user had to wait until the file was completely loaded from disk to memory, to be able to start navigating through the text and editing the text.

So I tried to somehow solve the problem.

Now, in the new version of the TE editor, when opening a file, after reading a number of lines that fit on the screen (usually 24 lines... but depending also on the settings used in the command line), the user is free to start editing the file; during this time, in the "background", reading the file will continue, until the end of the file.

The user is warned that he can start editing, as the first text screen has been filled with records read from the text file. 

Then, after the last record has been read, the user will be notified again (the notification messages are typed on the last line of the screen, outside the space provided for editing).

Therefore, while the file is being read, the user may browse trough the already loaded part of the file, or even delete/add text.

When the user wants to save the edited file back to the disk, a counter representing the number of lines already written will be displayed on the last line of the screen, while writing continues.

A 60KB text file takes about a minute to load on a system provided with SC108.

On a system provided with 512KB RAM, it takes less, only about 15 seconds, but still disturbing...

So this improvement may prove useful for these systems...

On Z80ALL, the same file takes only 5 seconds to load, therefore it does not make sense to implement this improvement also on Z80ALL.

This improvement for the TE text editor is implemented for versions running on systems with 2 x 64 KB RAM or with 512 KB RAM.

Ladislau

[Bill Shen]

The new TE is very cool!  I ran it on Simple80 which has 14.7MHz clock and it displayed the file on screen immediately, then loaded the remaining file in the background while I can edit the displayed content.  For 63K file, it took 9 seconds to load the entire file in the background.  I think having the file displayed immediately is very important because it starts the thought process about what needed to be done which can easily take many seconds to get going.  By contrast, staring at a blank screen and waiting is just annoying and discouraging after a while.

I'll write a separate post on how to get Simple80 to run improved HiTech C and then use that improved capability to compile the new TE on Simple80.  The new TE is too large to compile with the original HiTech C.  It needs the 2nd bank of 64K RAM which the improved HiTech C can access.  New TE can also access the 2nd bank of 64K RAM so it can edit a file up to 80K.   All these new capabilities are thanks to Ladislau with whom I've corresponded for a week on the topic of improving HiTech C for Simple80.
  Bill

[ladislau szilagyi]

Hi,

I published here: https://github.com/Laci1953/RC2014-CPM/tree/main/System/te%20text%20editor ,

the TE editor adapted to be used on RC2014 computers running RomWBW (file TEWBW.HEX). 

You must use RomWBW version 3.5.0 or later.

TE edits the files in the RAM memory, therefore the size of the files that can be edited depends on the specific RomWBW configuration (more exactly on the number of RAM banks available for apps). For example, if installing RCZ80_std.rom on a RC2014 provided with 512KB ROM + 512KB RAM, we get 3 x 32KB = 96KB available to store the files.

If TE is started without any parameters, a quick help is provided :

-----------

c>te TE text editor Copyright (c) 2015-2021 Miguel Garcia / FloppySoftware Adapted for RomWBW by Ladislau Szilagyi Use: >TE [options] [filename] where options (lowercase or uppercase) are: -Tn (n = 4 or 8) sets the tabs to n spaces, default is 8 -Hnn sets the screen height (up to 99, default is 24) -Wnnn sets the screen width (up to 200, default is 80) Continue? (N/n = quit) : ------------

Some improvements (compared with the original TE version) :

- customizable TABs (multiple of 4 or 8)

- adjustable screen size (up to 99 x 200)

- moving the cursor is accessible also using arrow keys(up, down, left, right), plus pgup, pgdn, home, end

- text lines are not constrained to be smaller that the screen width, this version of TE behaves like WordStar when displaying pages containing 'truncated' lines (a '+' in the last column indicates that only part of the current line is displayed, but you can access the missing 'part' by moving the cursor to the right).

Some limitations of this TE version :

-Files with up to 4096 lines are accepted. 

-The maximum allowed text line size is 145 characters.

-Up to 512 text lines can be selected with ^KB ^KK (to be copied, moved, deleted, ...)

Ladislau

[Wayne Warthen]

On Tuesday, April 1, 2025 at 9:59:19 AM UTC-7 ladislau szilagyi wrote:

I published here: https://github.com/Laci1953/RC2014-CPM/tree/main/System/te%20text%20editor ,

the TE editor adapted to be used on RC2014 computers running RomWBW (file TEWBW.HEX). 

You must use RomWBW version 3.5.0 or later.

Thanks Ladislau.  I have included it in the upcoming RomWBW v3.5 Release.

-Wayne