[Coco] Color BASIC and "CURLIN" (direct versus in a program)

[William Astle]

Have you considered hooking the line input RAM vector. Then check the 
return address to see if it's $AC7F? If so, you can force CURLIN to 
$FFFF. Then just continue to whatever else may have hooked that RAM 
vector. That will catch immediate mode and also ASCII basic program 
loads. (ASCII program loads just open the file, set DEVNUM to that file, 
then transfer control to immediate mode.)

As a caution: LIST can be executed within a program. It will fall back 
to immediate mode after running, but you may need a way to trap that, 
too. The same thing can happen with SAVE and CSAVE in ASCII mode which 
just open the file, set DEVNUM, and call LIST.

On 2025-10-23 19:00, Allen Huffman via Coco wrote:
> I see that when a program prints the OK prompt, it does this:
> 
> LAC73 JSR LB95C 	MOVE CURSOR TO START OF LINE
> 	LDX #LABE1-1	POINT X TO ‘OK’, CR MESSAGE
> 	JSR LB99C 		PRINT ‘OK’, CR
> 	LAC7C JSR LA390 	GO GET AN INPUT LINE
> 	LDU #FFFF 		THE LINE NUMBER FOR DIRECT MODE IS $FFFF
> 	STU CURLIN 		SAVE IT IN CURLIN
> 
> Tonight I found out that when a program ends, such as hitting BREAK, the CURLIN still contains the last line that was executed. As you type your command, it is not until AFTER the input that the line is set to “direct mode”. This seems odd. The parsing of the line comes later, so it does not appear to be preserving the line in case you type “CONT” or something.
> 
> I have a RAM hook patch I am working on that lets you embed cursor movements in a PRINT command, similar to how they worked on my VIC-20. I wanted to make it NOT do that when LISTing the program or typing the line in. BUT, after a BREAK, that one line will be processing the characters. Any lines typed after that, will not.
> 
> I thought I had a clever way to know when to process the special characters (any time NOT in direct mode) but this bit of ROM code prevents that from working


-- 
William Astle