BASIC input buffer $0200 - $0258

[Victim_RLSH]

This seems a fairly decent amount of space, could I use this in an ML program that was started with a BASIC stub without screwing anything up?

[srowe]

As long as you don't call any BASIC routines related to input from your program you should be fine.

[Mike]

Yes, the buffer is fair game as long as your ML program runs and you started it with a BASIC stub + RUN. Note though, that if you started the ML program with a SYS in direct mode, TXTPTR still points into the input buffer and this might lead to ?SYNTAX errors or similar upon return from the ML program as the interpreter then continues behind the SYS command.

[chysn]

If you store machine code in BASIC memory and use the null-terminated string print routine ($cb1e) to print a string in Page 2, your code in BASIC memory may get overwritten by the string you've printed (see VIC-20 disassembly at http://www.fox-ts.co.uk/shared/vic20ker ... l#LAB_D4B5). I'm passing this along because it drove me mad for a while before I tracked it down.

[Victim_RLSH]

Thanks for the warning, I am actually doing just that!

[Mike]

My main concern would be that if the program ever was to return to direct mode (either normally or in case of an error), the BASIC input line will thrash whatever is in that buffer, making debugging (with simple PRINTPEEK(...) statements, for example) unnecessarily difficult.

Under normal circumstances I'd regard that buffer only as a last resort measure, and only in the case the program does not need to hold permanent state there.

My own ML monitor happens to use that buffer for its own command line, but the line is shortened to 64 characters. That keeps 25 bytes of the buffer as workspace for the currently executed monitor command. The monitor does not call any routines in the BASIC interpreter (except on exit to BASIC), so the buffer is save in that regard. And with the first two points noted above, I think the use of $0200..$0258 by my monitor is unlikely to tread on anyone else's shoes.