Keyboard Buffer and Ctrl/Shift/CBM etc

[SparkyNZ]

I spoke too soon! I can't get '2' to work. I can see that the matrix scan is definitely working - it stores $38 (56) in $cb as expected.. but for some reason number 2 doesn't appear on the screen. All the other letters and numbers work.

Would this have something do with 2 having the double quote symbol when shifted I wonder? Still.. I don't see double quote appearing either.. Oh dear..

[SparkyNZ]

The BASIC interpreter calls CHRIN in the KERNAL to fill the input line buffer from the input. The first call of CHRIN stops the calling program, switches on the cursor and remains in the screen editor until the user enters the line with the RETURN key. Then CHRIN returns with the first character on the line, further calls of CHRIN directly return with all remaining characters until end-of-line is found. CHRIN then returns code 13 (CR) and the next call once again enters the screen editor.

So @Mike I have been taking a bit of a deep dive into the BASIC CHRIN and GETSCRN routines. I thought these routines captures the text from the start of the cursor's current line up to 89 chars until Return is pressed, with the result being stored in the BASIC Input Buffer at $200.

This image shows what I'm seeing for the entry of "10 GOTO 10":



Is the BASIC Input Buffer already tokenised?

Code: Select all

89 20 31 30 00 54 00 20 31 30

I've had a look at this page: https://techtinkering.com/articles/basi ... he-vic-20/
..but I assumed that just related to the storage of a full tokenised BASIC program.

I see GOTO is token $89 and the 31 30 must be the "10" in the input, but what is the $54?

[srowe]

Is the BASIC Input Buffer already tokenised?

It is tokenized by the BASIC main routine that processes program input

Code: Select all

MAIN
	JMP	(IMAIN)			; do BASIC warm start


;***********************************************************************************;
;
; BASIC warm start, the warm start vector is initialised to point here

MAIN2
	JSR	GETLIN			; call for BASIC input
	STX	TXTPTR			; save BASIC execute pointer low byte
	STY	TXTPTR+1		; save BASIC execute pointer high byte
	JSR	CHRGET			; increment and scan memory
	TAX				; copy byte to set flags
	BEQ	MAIN			; loop if no input

; got to interpret input line now ...

	LDX	#$FF			; current line high byte to -1, indicates immediate mode
	STX	CURLIN+1		; set current line number high byte
	BCC	NEWLIN			; if numeric character go handle new BASIC line

					; no line number .. immediate mode
	JSR	CRNCH			; crunch keywords into BASIC tokens
	JMP	LAB_C7E1		; go scan and interpret code

Code: Select all

89 20 31 30 00 54 00 20 31 30

I've had a look at this page: https://techtinkering.com/articles/basi ... he-vic-20/
..but I assumed that just related to the storage of a full tokenised BASIC program.

I see GOTO is token $89 and the 31 30 must be the "10" in the input, but what is the $54?

The line ends at the NUL following the line number, everything after is just part of the original ASCII text before tokenization.

[SparkyNZ]

JSR CRNCH ; crunch keywords into BASIC tokens
JMP LAB_C7E1 ; go scan and interpret code
[/code]

The line ends at the NUL following the line number, everything after is just part of the original ASCII text before tokenization.

Right, so this is the result of the CRNCH routine?

Code: Select all

89 20 31 30 00

Probably pay me to step through that routine and dump that piece of memory as it goes - I get that the $54 is the 'T" from GOTO. I'm just wondering at what point the 'O' disappears and gets written with the second null. I'll have to try 20 GOTO 10 so I can see the actual line number and parameter of the GOTO. I'm guessing the initial (leftmost) line number 10 is pulled out of the buffer first and then the GOTO 10 is a subsequent parse?

I'll check in the morning - doing the 3am insomnia thing here again

[srowe]

Right, so this is the result of the CRNCH routine?

Code: Select all

89 20 31 30 00

Correct.

Probably pay me to step through that routine and dump that piece of memory as it goes

Using the monitor in VICE is a good way of understanding how this all works.

[SparkyNZ]

Using the monitor in VICE is a good way of understanding how this all works.

Or my own app I can see what's happening now:

Code: Select all

0000(0000)  31 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  1...............
0000(0000)  31 30 00 00 00 00 00 00  00 00 00 00 00 00 00 00  10..............
0000(0000)  31 30 20 00 00 00 00 00  00 00 00 00 00 00 00 00  10 .............
0000(0000)  31 30 20 47 00 00 00 00  00 00 00 00 00 00 00 00  10 G............
0000(0000)  31 30 20 47 4f 00 00 00  00 00 00 00 00 00 00 00  10 GO...........
0000(0000)  31 30 20 47 4f 54 00 00  00 00 00 00 00 00 00 00  10 GOT..........
0000(0000)  31 30 20 47 4f 54 4f 00  00 00 00 00 00 00 00 00  10 GOTO.........
0000(0000)  31 30 20 47 4f 54 4f 20  00 00 00 00 00 00 00 00  10 GOTO ........
0000(0000)  31 30 20 47 4f 54 4f 20  32 00 00 00 00 00 00 00  10 GOTO 2.......
0000(0000)  31 30 20 47 4f 54 4f 20  32 30 00 00 00 00 00 00  10 GOTO 20......  (point A)
0000(0000)  31 30 20 47 4f 54 4f 20  32 30 00 00 00 00 00 00  10 GOTO 20......
0000(0000)  89 30 20 47 4f 54 4f 20  32 30 00 00 00 00 00 00  .0 GOTO 20......
0000(0000)  89 20 20 47 4f 54 4f 20  32 30 00 00 00 00 00 00  .  GOTO 20......
0000(0000)  89 20 32 47 4f 54 4f 20  32 30 00 00 00 00 00 00  . 2GOTO 20......
0000(0000)  89 20 32 30 4f 54 4f 20  32 30 00 00 00 00 00 00  . 20OTO 20......
0000(0000)  89 20 32 30 00 54 4f 20  32 30 00 00 00 00 00 00  . 20.TO 20......
0000(0000)  89 20 32 30 00 54 00 20  32 30 00 00 00 00 00 00  . 20.T. 20......

Just dumping the first 16 byte of $200-$20f here. I'm assuming that up to point A, GETSCRN is storing the characters on the screen into the BASIC input buffer. Then the tokenization must begin.