Could you create a loop in direct-mode with BASIC?

Question

Were there any home computers before 1985, on which you could create a loop (finite or infinite) in direct-mode?

And if it was possible on some machines, what may it have been useful for? For example, some sort of program loader from tape or disk.

For example, by typing

    PRINT "TEXT" : RUN

or

    PRINT "TEXT" : GOTO 0

so that it would loop the printing of "TEXT", just as an example.

EDIT - Since I am completely blocked ( due to some unknown problem ) from commenting and now also from posting any answers, I just want to add that it seems that you can use a pre-user-defined function in direct-mode, by first defining the function in a program using line numbers ( e.g. 10 DEF FNADD(X,Y)=X+y ) and then using it in direct-mode, so then trying to do a recursion trick like FNADD(FNADD(X,Y),Y), to try and cause an infinite loop using recursion, would be interesting, and I wonder why pre-user-defined functions can be accessed through direct-mode .

Answer 1

In the Microsoft BASIC variants (Commodore, Atari, Apple, others) you can specify a FOR/NEXT loop with a STEP size of 0, which never increments the loop.

FOR X = 0 TO 1 STEP 0: PRINT "TEXT": NEXT

is how you'd write it as a one-liner.

Now, as to why it would be useful to do such a thing...

Answer 2

In any BASIC variant that allows multiple statements on one line, the multiple statements that are required to implement a FOR-NEXT or REPEAT-UNTIL loop can be provided in immediate mode. Many 8-bit micros of circa 1980 could do this:

REPEAT : PRINT "*"; : UNTIL FALSE

Or this:

X=1 : FOR Y=0 TO 30 : PRINT "2^";Y;" = ";X : X=X+X : NEXT Y

Try these examples in jsBeeb.

By contrast, any looping technique that relies on GOTO would not work, because there is no line number associated with the immediate-mode command. RUN also would not work, because its function is to start a stored program, which the immediate-mode command is not.

Answer 3

Using BASIC+ on RSTS/E you can do this:

Ready

print i%; "Hello!" for i% = 1 to 9
 1 Hello!
 2 Hello!
 3 Hello!
 4 Hello!
 5 Hello!
 6 Hello!
 7 Hello!
 8 Hello!
 9 Hello!

Ready

This has a variety of uses. A trivial one would be to start a long running program then enter print chr$(7) for i%=1 to 20 into the type ahead buffer. The terminal would then beep 20 times when the long-running program completed.

It's also useful for testing code:

Ready

old stuff

Ready

listnh
1000    def fnstuff.happens()
1010        a.number = rnd
1020        print &
         \  print "Working on stuff..."
1030        fnstuff.happens = a.number
1040    fnend
3276    end

Ready

print fnstuff.happens for i = 1 to 3

Working on stuff...
 .204935

Working on stuff...
 .229581

Working on stuff...
 .533074

Ready

Not strictly speaking a "home computer" unless, like me, you used to run a PDP-11 in your spare room. The above output is copied from a RSTS/E V8.0-06 system running under the SIMH PDP-11 emulator.

Answer 4

In Microsoft-based BASIC interpreters, the primary limitation with direct mode was the fact that the same buffer is used for inputting BASIC lines as for input within a program (e.g. the INPUT statement and the GET statement). If one were to perform e.g. INPUT A$ in direct mode, then once the input was complete, the buffer would be left holding the text that was input, rather than the immediate-mode line. I don't think there would have been any particular difficulty designing GET to store the new character someplace else (since it would only be a single byte), but I suspect that INPUT and GET share a routine that takes a string stored in the input buffer and copies it to garbage-collected string space; sharing that routine wouldn't avoid the need to have the GET function set the length to a hard-coded value of 1, but would avoid the need have it include its own code to set the source address. Even with that design, GET could probably have been made to support immediate mode if it did something like:

lda InputBufferStart
pha
jsr handleGet
pla
sta InputBufferStart
rts

but that would made the interpreter 12 bytes bigger for relatively minor benefit.

The FOR loop construct that saves the start-of-loop address doesn't need to use the input buffer, and thus has no difficulty with direct mode. Constructs that would need to GOTO the direct-mode line wouldn't work, of course, but otherwise the only constructs that are problematic in direct mode are those that would use the input buffer.