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 (http://www.cpcwiki.eu/forum/applications/full-screen-basic-editor)).
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?
Quote from: cpcitor on 21:03, 19 December 17
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 (http://www.cpcwiki.eu/forum/applications/full-screen-basic-editor)).
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.
Quote from: Docent on 04:34, 20 December 17
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 (http://www.cpcwiki.eu/index.php/BIOS_Function_Summary)
I don't understand very well the comment there:
QuoteBD3A 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 (https://k1.spdns.de/Vintage/Schneider%20CPC/Das%20Schneider%20CPC%20Systembuch/z167.htm) 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"?
Quote from: Docent on 04:34, 20 December 17
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.
Quote from: Docent on 04:34, 20 December 17
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
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
...
Quote from: Docent on 04:34, 20 December 17
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.
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?
Quote from: Docent on 04:34, 20 December 17
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?
Quote from: Docent on 04:34, 20 December 17
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 (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 (http://www.cpcwiki.eu/index.php/Amstrad_Whole_Memory_Guide) which while not comprehensive (what is?) is still very interesting!
I asked a lot of questions here, thanks in advance!
Quote from: cpcitor on 10:32, 20 December 17
Interesting! Not a very well known entry point, but mentioned on BIOS Function Summary - CPCWiki (http://www.cpcwiki.eu/index.php/BIOS_Function_Summary)
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 (https://k1.spdns.de/Vintage/Schneider%20CPC/Das%20Schneider%20CPC%20Systembuch/z167.htm) 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.
Quote from: cpcitor on 10:32, 20 December 17
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
Quote from: cpcitor on 10:32, 20 December 17
Hmmm. &e7e5 does not look like a possible entry point.
&e7a5 maybe?
Yes I meant &e7a5
Quote from: cpcitor on 10:32, 20 December 17
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 (http://www.cpcwiki.eu/index.php/Amstrad_Whole_Memory_Guide) 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.
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.
Quote from: arnoldemu on 12:50, 24 December 17
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:
pdfgrep INPUT *pdf
So, not in the following documents:
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!