Full-screen BASIC editor?

[cpcitor]

Hello.

Is there a full-screen editor targeting BASIC programs? I read on https://cpcrulez.fr/applications_coding-maxam_rom.htm?t=VA== that MAXAM has a full-screen editor:

Whilst designed to allow you to enter your assembler program, with useful default Tab settings, etc. you are also encouraged to use it for Basic or text files.

But MAXAM doc says:

The text editor and BASIC
The text editor is compatible with BASIC - editor text and a BASIC program can
be in the memory at the same time. Editing one does not affect the other.
BASIC variables are preserved when the MAXAM main menu is used, but destroyed
when the editor menu is entered.
There is one unavoidable side effect of allowing BASIC and editor text together
which it is as well to be aware of. If a BASIC program Is saved when editor text is
present the editor text will be saved with the BASIC program. When reloaded, however,
the editor text will not be useable.
There are two possible solutions to this problem:
1. Delete the editor text before saving the BASIC program. This can done from
BASIC by typing '|CLEAR'.
2. Save the BASIC program in ASCII format. The editor text is not then saved.
Saving in ASCII has the considerable advantage that the program can then be edited
directly with the editor. The disadvantages are that saving in the ASCII
representation makes the file slightly larger and, for disc users, takes much longer.

So, it's not what I was expecting. I was expecting something like:

Code Select Expand

Ready
|EDIT
(Screen switches to a full-screen editor. Type code, perhaps even without line numbers which would get added later. A key or combo, maybe Esc, would exit the full-screen editor.)
Ready
(The BASIC program in RAM reflects changes in editor. Either continuously during edit, or perhaps only after all edits are done.)


I'm pretty sure such editing feature needs advanced interaction with BASIC ROM, because firmware does not provide RAM-based entry points to interpret an ASCII string like it was just typed from the BASIC prompt, or to features like RENUM. Are there ROM-based entry points that work on all CPC models?

One may argue: just type LIST, interrupt when suitable, EDIT the line number to change, use copy cursor and you're done.

I'm happy with usual workflow, just curious about existing alternatives well integrated with BASIC. Thanks. 

[GUNHED]

You can use the Protext ROM instead.

[cpcitor]

You can use the Protext ROM instead.

Thanks for the tip.
I see from its doc http://cpctech.cpc-live.com/docs/manual/protext.pdf http://www.cpcwiki.eu/imgs/c/c7/Protext_%28Arnor%29_Manual.pdf that Protext is based on Maxam and thus inherits some features.

Page 38:

PROTEXT  is  compatible  with  BASIC  in  that  text  and  a  BASIC  program  can  be  in 
memory  at  the  same  lime.  Editing  one  does  not  affect  the  other.

So, you can't edit your current BASIC program directly.


Yet there are somewhat interesting facts:

* Protext has a "program mode" that can among other things automatically add line numbers to an existing text. "So  BASIC  program  can  be  typed  in  without  typing  the  line  numbers,  and  the  line numbers  added  later." In practice I guess it can be used for a first draft before you add your first GOTO or GOSUB. It lacks the power of the BASIC command RENUM which can adjust existing line number references. (doc mentions Maxam inheritance).
* Protext certainly makes use of the CPC firmware since it explains with great length and examples how to customize it by launching it from a custom BASIC program that redefines keys using KEY DEF, including some macro-like usage.

Page 41:

BASIC  programs  must  be  saved  in  ASCII  format  before  editing  with  PROTEXT  and should be re-saved, after editing, whilst in program mode, for re-use from Basic

Saving to disk is good, but ASCII saving/loading is a little slow for big programs.

Back to initial question, I guess CPC no full-screen editor of the era allowed to edit current BASIC program full-screen with either immediate effect or apply change directly on editor exit.

[Sykobee (Briggsy)]

Yeah, Protext can edit BASIC just fine, but it's not integrated, and you have to save as ASCII.


What you want is something like the BASIC 2 editor on the PC1512?


I think it would require a Firmware/BASIC ROM hack to change the editor to work like Protext, and that likely would be a significant (i.e., a lot of work) change (remove existing, put in full scrolling normal editor).

[andycadley]

I suspect the internal structure of BASIC programs isn't particularly well suited to a continuous editing experience and the CPC doesn't really have the spare memory to hold two versions in RAM at the same time. If you look at the Speccy 128 editor, which is probably a close approximation (given that it's an after the fact full screen editor over an existing tokenized BASIC) you can see how it impacts the general speed of things (and that's ignoring the fact its a tad buggy)

[cpcitor]

Yeah, Protext can edit BASIC just fine, but it's not integrated, and you have to save as ASCII.

What you want is something like the BASIC 2 editor on the PC1512?

I didn't know there was such an editor in PC1512 (I had one and used it with DOS).

Can't find any confirmation on the web, and the few videos I see of the PC1512 don't show a full-screen editor.


https://youtu.be/S8OgFwT1Rqw?t=34

https://youtu.be/N_DC37VrcQs?t=20

Can anyone provide references?

I think it would require a Firmware/BASIC ROM hack to change the editor to work like Protext, and that likely would be a significant (i.e., a lot of work) change (remove existing, put in full scrolling normal editor).

Actually, the reason why I asked this question is I am looking the a project to exercise the C-firmware interface. Writing a simple editor could be an option.

In its simplest integration form, this would need two entry points:
* some call to ROM code to LIST part of a program (say, n lines starting with X) to a buffer (that's not how firmware works).
* some call to ROM code to insert a line as if it was just types from BASIC prompt.

I have no real hope for the former (fallback would be to decode BASIC program from RAM to text, perhaps with the help of some low-level ROM functions).
Regarding the latter, well, such a call might exist in ROM.

Perhaps this should continue on the programming forum, then.

[GUNHED]

The last BASIC program I wrote I used the MAXAM editor for. 

[cpcitor]

Thank you @GUNHED @andycadley @Sykobee for your replies.

The firmware-related questions belong to programming and are continued on ROM calls to decode BASIC lines to ASCII and back?

[Morri]

I use CPC BASIC 3 on PC for creating and editing my BASIC programs. It scrolls though the entire program, edit by line number, RENUM etc...
Once finished I copy / paste into WinAPE autotype and test from there.

I find it quite helpful once the program starts to get too big.

[cpcitor]

I use CPC BASIC 3 on PC for creating and editing my BASIC programs. It scrolls though the entire program, edit by line number, RENUM etc...
Once finished I copy / paste into WinAPE autotype and test from there.

I find it quite helpful once the program starts to get too big.

This looks interesting. I would have feared autotype to be too slow (it is slow in arnoldemu) and/or CPC BASIC 3 to be not compatible enough (see CPC Basic Differences Locomotive Basic). If it works, then great!

[Morri]

This looks interesting. I would have feared autotype to be too slow (it is slow in arnoldemu) and/or CPC BASIC 3 to be not compatible enough (see CPC Basic Differences Locomotive Basic). If it works, then great!

Yes, autotype is slow on normal settings, so my trick is to set the speed in WinApe to 1000%, much better!

Regarding compatibility, you are correct. You cannot RUN the program from within CPCBASIC3 as it will attempt to compile it. I use it purely as an editor then transfer it to WinApe for testing.

[Johnny Olsen]

Years ago Tasteful MrShip told me another way to put basic program in WinApe.

Insert a dsk.

For access Drive A - Press shift+CTRL+F1
For access Drive B - Press shift+CTRL+F2

Now Drag and drop your file.

The file is now on the dsk saved as an Unknown ASCII/Binary file.

Load the file and save it again - save"File2"

Now it't a basic file on dsk.



To do it the opposite way.
--------------------------------
Load a basic file and save it as ASCII file save"file.txt",a

Now drag and drop the file in a pc map.

It is now possible to read the file using Notesblok or whatever program you want.

One drawback is the garbage in the last line we has to delete.

E.g

3810 PEN 1:LET bonusd=bonusd-1:IF bonusd=0 THEN LET bonusd=1
3820 RETURN
3830 DATA 60,53,47,45,60,0,45,47,45,40,53,0,53,47,45,36,40,40,45,45,47,53,47,60,9999,9999
Â
M ½
¡   íï ú   m²ï ë » 
©   ø,  ù
¿ ÿ(ø)
©   ø,  ùõ
¿ ÿ(ù)
»  1 Â
¡ ÿ|( ö

[FloppySoftware]

I didn't know there was such an editor in PC1512 (I had one and used it with DOS).

Can't find any confirmation on the web, and the few videos I see of the PC1512 don't show a full-screen editor.


https://youtu.be/S8OgFwT1Rqw?t=34

https://youtu.be/N_DC37VrcQs?t=20

Can anyone provide references?

Locomotive Basic2 is an interpreter that runs under GEM, the GUI from Digital Research:


https://www.youtube.com/watch?v=EH0BGEVYNYk

[cpcitor]

Interesting variant! This must be faster.

One drawback is the garbage in the last line we has to delete.

I guess the last garbage line is a bug. Is @Executioner WinAPE author aware of that?

[Johnny Olsen]

I do not know, but I haven't talked to him about it

[Executioner]

I guess the last garbage line is a bug. Is @Executioner WinAPE author aware of that?

Well, not exactly a bug. It's a side effect of how you're converting the file. The last part of the sector contains random data rather than an EOF character (26) which is required by AMSDOS for ASCII files. Have you tried "Add/Remove AMSDOS Header" when doing it?

[cpcitor]

Well, not exactly a bug. It's a side effect of how you're converting the file. The last part of the sector contains random data rather than an EOF character (26) which is required by AMSDOS for ASCII files. Have you tried "Add/Remove AMSDOS Header" when doing it?

I don't do anything. Actually i don't even use WinAPE because it's Windows only. 

Johnny Olsen reported the issue earlier in this thread:

Load a basic file and save it as ASCII file save"file.txt",a

Now drag and drop the file in a pc map.

This should be enough to reproduce the case, shouldn't it?

[SRS]

Well, not exactly a bug. It's a side effect of how you're converting the file. The last part of the sector contains random data rather than an EOF character (26) which is required by AMSDOS for ASCII files. Have you tried "Add/Remove AMSDOS Header" when doing it?

I tried it today with my "$.bas", and this is what I get if I save it as "$",A ...

Code Select Expand

10 MODE 2:INK 0,13:INK 1,0:PEN 1:PAPER 0:BORDER 13:FOR a=4089 TO 4115:READ b$:b=VAL("&"+b$):POKE a,b:NEXT a:CALL &1000:DATA cd,60,bb,32,c2,b,c9,21,a,10,df,7,10,c9,d,c6,7,23,0,c8,0,1,1,a,0,3,0:CAT
11 PRINT SPC(13);:CALL &BB9C:PRINT"ENTER=RUN f1=CAT f2=USER f3=ERA f4=A/B f5=REN f6=SHOW":CALL &BB9C:m=VPOS(#0)
12 LOCATE 1,m+1:IF NOT INKEY(0)THEN y=MAX(0,y-1) ELSE IF NOT INKEY(2)THEN y=MIN(y+1,m) ELSE IF NOT INKEY(8)THEN x=MAX(0,x-20) ELSE IF NOT INKEY(1)THEN x=MIN(60,x+20) ELSE IF NOT INKEY(18)AND NOT n$=STRING$(12,32) THEN RUN n$ ELSE IF NOT INKEY(13)THEN RUN
13 IF NOT INKEY(14)THEN 15 ELSE IF NOT INKEY(5)THEN |ERA,@n$:RUN ELSE IF NOT INKEY(20)THEN 17 ELSE IF NOT INKEY(12)THEN 16 ELSE IF NOT INKEY(4)THEN OPENIN n$:CLS:WHILE NOT EOF:LINE INPUT#9,a$:PRINT a$:WEND:RUN
14 n$="":FOR c=1 TO 12:LOCATE x+c,y+4:CALL 4089:n$=n$+CHR$(PEEK(3010)):NEXT c:CALL &BB9C:LOCATE x+1,y+4:PRINT n$:CALL &BB18:CALL &BB9C:LOCATE x+1,y+4:PRINT n$:GOTO 12
15 INPUT"0-FF";u:IF u<0 OR u>255 THEN PRINT CHR$(7):GOTO 15 ELSE POKE &A701,u:RUN
16 INPUT"in";u$:|REN,@u$,@n$:RUN
:BORDER 13:FOR a=4089 TO 4115:READ b$:b=VAL("&"+b$):POKE a,b:NEXT a:CALL &1000:DATA cd,6

So the last "Line" is garbage.

[cpcitor]

Code Select Expand


16 INPUT"in";u$:|REN,@u$,@n$:RUN
:BORDER 13:FOR a=4089 TO 4115:READ b$:b=VAL("&"+b$):POKE a,b:NEXT a:CALL &1000:DATA cd,6[attachimg=1]

So the last "Line" is garbage.

Interestingly, although the last line showed up here starting with ":BORDER 13", when I copy-pasted it into emacs it revealed that that line starts with a character 26 (hexa 1A).

And while I type, the quoted text shows a square with 0 0 1 A, typical of a unicode character which has no regular representation.

The last part of the sector contains random data rather than an EOF character (26) which is required by AMSDOS for ASCII files. Have you tried "Add/Remove AMSDOS Header" when doing it?

Since it looks like character 26 is indeed there, is there another reason why processing does not stop at it?

Regards.