ROM calls to decode BASIC lines to ASCII and back?

[cpcitor]

I am looking the a project to exercise the C-firmware interface. KM (keyboard) and TXT pack jump blocks are fully covered.
Writing a simple fullscreen BASIC editor (even a proof-of-concept) could be an option.
I mean: some program that allows to edit current BASIC program in RAM with free cursor movement, without duplicating all program in RAM.

Anyway I searched a bit and could not find any (also asked on this forum post).

Interestingly, it could be possible without duplication at all of the BASIC program because the screen area can be read like an ASCII buffer with TXT RD CHAR #BB60. Perhaps that's what BASIC does when editing a line?

But this needs to fetch a line from the program RAM and insert back a line into it. But without rewriting a BASIC line decode/recode routine.

ROM to the rescue

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
* some call to ROM code to insert a line as if it was just types from BASIC prompt.

* Thinking about it some more, ROM has some code to provide one line as ASCII form into a buffer, unless ROM has duplicated code for EDIT command and for ASCII SAVE.
* Symetrically, ROM has some code to insert one line from an ASCII buffer, unless ROM has duplicated code when pressing ENTER and for ASCII LOAD.

Can anyone who knows BASIC ROM very well shed some light?

[Docent]

I am looking the a project to exercise the C-firmware interface. KM (keyboard) and TXT pack jump blocks are fully covered.
Writing a simple fullscreen BASIC editor (even a proof-of-concept) could be an option.
I mean: some program that allows to edit current BASIC program in RAM with free cursor movement, without duplicating all program in RAM.

Anyway I searched a bit and could not find any (also asked on this forum post).

Interestingly, it could be possible without duplication at all of the BASIC program because the screen area can be read like an ASCII buffer with TXT RD CHAR #BB60. Perhaps that's what BASIC does when editing a line?

But this needs to fetch a line from the program RAM and insert back a line into it. But without rewriting a BASIC line decode/recode routine.

ROM to the rescue

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
* some call to ROM code to insert a line as if it was just types from BASIC prompt.

* Thinking about it some more, ROM has some code to provide one line as ASCII form into a buffer, unless ROM has duplicated code for EDIT command and for ASCII SAVE.
* Symetrically, ROM has some code to insert one line from an ASCII buffer, unless ROM has duplicated code when pressing ENTER and for ASCII LOAD.

Can anyone who knows BASIC ROM very well shed some light?

Basic uses TEXT INPUT (&BD5E) which provides full line editing. When you enter for example EDIT 10, 10th line is located and then tokens are converted into text and stored in the buffer at &AC8A, which is used as a parameter in HL in call to BD5E. When you press enter, the text buffer is converted back into tokens.
The function, converting tokens to text in BASIC 1.1 rom is located at &e254. You can call &e259 with bc, containing address of destination buffer and hl, pointing to start of tokenized basic line for example &170.
The function that converts text into tokens is at &e7e5, on entry hl contains the address of a buffer with text. de line number Unfortunately, this routine uses some specific to Basic variables and a buffer at &40, so you'll probably need to be careful using it or find a better entry point.
Please remember that these addresses will vary between different basic versions.

[cpcitor]

Basic uses TEXT INPUT (&BD5E) which provides full line editing.

Interesting! Not a very well known entry point, but mentioned on BIOS Function Summary - CPCWiki

I don't understand very well the comment there:

BD3A BD5B BD5E EDIT  ;io: HL=input buffer, out: CY=0=ESC (also Z=1=ESC)

I guess HL is input there, so "io:" perhaps should be changed to "in". Seems confirmed in Das Schneider CPC Systembuch: Die Firmware des Schneider CPC: Die Basic-Vektoren which has more details.

I still don't understand CY or the syntax "CY=0=ESC (also Z=1=ESC)".
Does it mean "if user aborted edition with ESC, then Carry and Zero flags are on"?

When you enter for example EDIT 10, 10th line is located and then tokens are converted into text and stored in the buffer at &AC8A, which is used as a parameter in HL in call to BD5E. When you press enter, the text buffer is converted back into tokens.

Okay, the TEXT INPUT routine is of general use. I guess the same is used by INPUT command.

The function, converting tokens to text in BASIC 1.1 rom is located at &e254. You can call &e259 with bc, containing address of destination buffer and hl, pointing to start of tokenized basic line for example &170.

Very interesting! Why do you invite to call &e259 and not &e254? I see the latter calls &e23d which (calls &af4a which I can't figure out even after reading) then copies a null-terminated string into buffer at &ac8a.

Extract from @Arnoldemu's http://www.cpctech.org.uk/docs/basic.asm

Code Select Expand

e254 e5        push    hl
e255 cd3de2    call    $e23d
e258 e1        pop     hl
e259 23        inc     hl
e25a 23        inc     hl
e25b 23        inc     hl
e25c 23        inc     hl
e25d 7e        ld      a,(hl)
e25e 02        ld      (bc),a
e25f b7        or      a
e260 c8        ret     z
...


The function that converts text into tokens is at &e7e5, on entry hl contains the address of a buffer with text. de line number

Hmmm. &e7e5 does not look like a possible entry point.

Code Select Expand

e7e0 e1        pop     hl
e7e1 cd5ce8    call    $e85c
e7e4 78        ld      a,b
e7e5 b1        or      c
e7e6 c8        ret     z

e7e7 eb        ex      de,hl
e7e8 cde5f6    call    $f6e5
e7eb c307f6    jp      $f607


&e7a5 maybe?

Unfortunately, this routine uses some specific to Basic variables and a buffer at &40, so you'll probably need to be careful using it or find a better entry point.

Hmm, this looks like it is going to be not-obvious.
Stepping through code in Arnoldemu's debugger, maybe.

Any known doc about this entry point?

Please remember that these addresses will vary between different basic versions.

Looks like there are hints on
http://cpcrulez.fr/coding_fdc-07-routines_annexe__SOSP.htm

Basically: enable upper ROM (call #B900), fetch byte at #DE01. 71 means 464, C9 means 6128. Do you approve this means of checking machine type?

Thanks to you I discovered Amstrad Whole Memory Guide - CPCWiki which while not comprehensive (what is?) is still very interesting!

I asked a lot of questions here, thanks in advance!

[Docent]

Interesting! Not a very well known entry point, but mentioned on BIOS Function Summary - CPCWiki

I don't understand very well the comment there:

I guess HL is input there, so "io:" perhaps should be changed to "in". Seems confirmed in Das Schneider CPC Systembuch: Die Firmware des Schneider CPC: Die Basic-Vektoren which has more details.

I still don't understand CY or the syntax "CY=0=ESC (also Z=1=ESC)".
Does it mean "if user aborted edition with ESC, then Carry and Zero flags are on"?

You can break this function with only two keys: esc or enter. If carry is set, user hit enter, otherwise he hit esc.

Very interesting! Why do you invite to call &e259 and not &e254? I see the latter calls &e23d which (calls &af4a which I can't figure out even after reading) then copies a null-terminated string into buffer at &ac8a.

The code starting from &e254 puts into the buffer line number of the basic code pointed by hl, converted to null terminated string. If you want also line numbers you can call &e254 instead of &e259

Hmmm. &e7e5 does not look like a possible entry point.
&e7a5 maybe?

Yes I meant &e7a5

Basically: enable upper ROM (call #B900), fetch byte at #DE01. 71 means 464, C9 means 6128. Do you approve this means of checking machine type?

Thanks to you I discovered Amstrad Whole Memory Guide - CPCWiki which while not comprehensive (what is?) is still very interesting!

I asked a lot of questions here, thanks in advance!

When you enable upper rom there is no guarantee that it will be basic rom.
I would use KL CURR SELECTION (&B912) to get the current upper rom select address, then use it to call KL PROBE ROM (b915) to confirm that it is a rom with basic (on exit a should contain #80) version 1.1 (l will contain 1, h will contain 2), then I'd use RST 3 to call the function eg.
rst 3
dw addresstocall
db romselectaddress ; set up from result of b912 call

Alternatively, you can just loop  rom select address between 0-252 as an input to KL PROBE ROM until it returns #80, 1,2 as described.

[arnoldemu]

I think TEXT INPUT *may* be described in one of the other SOFT manuals.
It may be in the BASIC technical guide. I may have the information somewhere if it's not available on-line.

[cpcitor]

I think TEXT INPUT *may* be described in one of the other SOFT manuals.
It may be in the BASIC technical guide. I may have the information somewhere if it's not available on-line.

This search in my firmware download directory yields no output:

Code Select Expand

pdfgrep INPUT *pdf


So, not in the following documents:

Code Select Expand

ls -1b *pdf

s158ap08.pdf
s158se01.pdf
s158se02.pdf
s158se13.pdf
s968ap01.pdf
s968ap02.pdf
s968ap03.pdf
s968ap04.pdf
s968ap05.pdf
s968ap07.pdf
s968ap08.pdf
s968ap09.pdf
s968ap10.pdf
s968ap11.pdf
s968ap13.pdf
s968ap14.pdf
s968frnt.pdf
s968pref.pdf
s968se01.pdf
s968se02.pdf
s968se03.pdf
s968se04.pdf
s968se05.pdf
s968se06.pdf
s968se07.pdf
s968se08.pdf
s968se09.pdf
s968se10.pdf
s968se11.pdf
s968se12.pdf
s968se13.pdf
s968se14.pdf
s968se15.pdf
s968se16.pdf
s968se17.pdf
s968se18.pdf
s968se19.pdf
s968se20.pdf


Could not locate BASIC technical guide on
http://www.cpcwiki.eu/index.php/Technical_documentation
or
http://cpctech.cpc-live.com/docs.html

Thanks anyway!