Best text editor in CP/M

[Crazyboss]

Hi.
I search a good CP/M text editor, e.g for edit pascal files. I am not looking for WordStart or so.

I found one, which should be fine, called ZDE16, is the Memotech CP/M under Memu compatible with any known terminals ?

Or is there another better text editor.?

[Martin A]

I always used Newword in non document mode for creating assembler files.

It came with the system and is a heck of a lot more friendly than the CPM editor ED.COM.

[AndyKey]

I’d also vote for NewWord in non-document mode.

Also, there is a copy patched for 56x24 mode (N56.COM), and a copy patched for 48x80 mode (N48.COM).

[Bill B]

I also use Newword on MTX.

However, if using MEMU, why not use your Linux or Windows editor of choice and use Andy's CP/M file system interfaces CPMFuse or CPMCBFS to open and save the files to your CP/M image?

[stephen_usher]

You know, what would be really interesting and useful would be a non-native BASIC program editor.

Being able to write MTX BASIC programs on a machine with a larger display (width and height) with a full screen editor and then save them so that the real machine can run them would make things far more convenient.

I'd imagine that this would be quite a big job, unless you just have a program which converts the file into a text file and then another to re-tokenize the text file and recreate the BASIC binary.

P.S. I see that there is a program for extracting text from MTX BASIC files on Primrosebank (written by Paul Daniels). Maybe that can be used as a basis of generating a new BASIC file.

[Bill B]

You can write Basic programs in a text file and then use Andy's auto-type feature to import them into MEMU. The import process is a bit slow.

To do the reverse, use the -prn-file option in MEMU and then LLIST the file.

[Bill B]

Thinking about it, one neat solution would be an MTX command to load a program from a text file.

It should be fairly simple:

• * Read a line from file into keyboard buffer.
  * Call ROM routine to process line.
  * Repeat.

If the lines don't start with line numbers then they would be executed immediately, which could also be useful.
This would be much faster than auto-type as there would be no waiting for the keyboard scanning routine.

I think I have too much else on at the moment It sounds like something Martin could do in an evening

[Martin A]

something like a USER EXEC "filename" for CFX/CFX-II looks reasonably doable.

Looking at the rom sources

Code: Select all

.basic
LD   SP,(SSTACK)
XOR  A
LD   (PAGE),A
OUT  (&00),A
LD   (PRORPL),A
RST  &10       ; output routine
DB   &A3      ; send 3 bytes to the screen
DB   &1B
DS   "V"
DB   &FF
DB   &6F      ; select VS7 and clear
DB   &A5      ; send 5 bytes to the screen
DS   "Ready"
DB   &68      ; select VS0 and clear
DB   &1E      ; send 30 to the screen
.nexkey
CALL kbd
JR   Z,nexkey
CP   &03
JR   Z,nexkey
RST  &10       ; output routine
DB   &6F      ; select VS7 and clear
DB   &40      ; select VS0
CALL edit1
.prog
RST  &28       ; Utility routine
DB   &AA       ; call EDEND    (&1148)
JR   Z,endedit
LD   HL,(KBDBUF)
PUSH HL
CALL syn
RST  &10       ; output routine
DB   &61      ; select VS1
DB   &23      ; send 3 to the screen
DB   &20      ; send 0 to the screen
DB   &12      ; send 18 to the screen
POP  HL
PUSH HL
CALL ol1
POP  DE
LD   HL,(COMMAND)
CALL run8
LD   BC,(AUTOIN)
LD   A,B
OR   C
JR   Z,basic2
RST  &10       ; output routine
DB   &6F      ; select VS7 and clear
DB   &68      ; select VS0 and clear
DB   &1E      ; send 30 to the screen
LD   HL,(AUTOST)
ADD  HL,BC
LD   B,H
LD   C,L
LD   (AUTOST),HL
CALL bcdec
CALL strout
RST  &10       ; output routine
DB   &81      ; send 1 bytes to the screen
DS   " "
JP   nexkey

Looking at that, duplicating the code, replacing the call to KBD, with a call to the disc GET byte routine might be all that's needed.

Other than that, patching USERIO at #FD51 to intercept the keyboard read code might be possible too, but that's not reset proof and not rom-able as the setup code pages in page rom 0 immediately before making the call.