'RUN' in a Program Line, XB

[senior_falcon]

XB256 has a subroutine to do what the OP wants:

CALL LINK("RUN",X$) will do exactly what you want.

CALL LINK("RUN1",X$) (might be RUNL1) will load the new XB program and run it starting at the first line without doing a prescan. All variables are preserved from the old program.

[RXB]

XB256 has a subroutine to do what the OP wants:

CALL LINK("RUN",X$) will do exactly what you want.

CALL LINK("RUN1",X$) (might be RUNL1) will load the new XB program and run it starting at the first line without doing a prescan. All variables are preserved from the old program.

 

RXB 2018 already had something that beats that:

 

F$="DSK.VOLUME.FILENAME" :: F=1 :: CALL XB(F$,F) ! String variable device & filename and number of files opened.

 

In normal XB this would be like:

CALL FILES(1)

NEW

RUN 'DSK.VOLUME.FILENAME"

 

(This also works with no 32K RAM from just a Console and RXB cart.)

 

What I really wanted was a change on RUN so you could do this using RUN instead of a CALL XB(string)

I wanted to make a

RUN STRING$,number of files open

[senior_falcon]

RUN	CLR R0
	LI R1,1		first argument in list
	LI R2,BUFFER
	MOV R2,@>832C		adjust XB program pointer so it goes to our dummy line in buffer
	LI R3,>82A9		::RUN  to BUFFER and BUFFER+1
	MOV R3,*R2+
	LI R3,>C720		"" to BUFFER+2 and 32 bytes for file name
	MOV R3,*R2
	INC R2
	BLWP @STRREF		get the file name, length byte after >C7 and then string
	MOVB *R2+,R3		get length of file name
	SRL R3,8		to lsb
	A R3,R2		Now R2 points to next byte after end of string
	MOVB R0,*R2		zero out that byte

	B @>006A

Here is RUN from XB256 if it helps.

[Casey]

Not that this is particularly helpful, but this does work on the 99/8's Extended BASIC II:

100 X$="DSK1.TICTACTOE"::RUN X$

 

It worked even more generally than that:

100 INPUT "DRIVE NUMBER: ":D::INPUT "FILE NAME: ":F$

110 RUN "DSK"&STR$(D)&"."&F$

[RXB]

RUN	CLR R0
	LI R1,1		first argument in list
	LI R2,BUFFER
	MOV R2,@>832C		adjust XB program pointer so it goes to our dummy line in buffer
	LI R3,>82A9		::RUN  to BUFFER and BUFFER+1
	MOV R3,*R2+
	LI R3,>C720		"" to BUFFER+2 and 32 bytes for file name
	MOV R3,*R2
	INC R2
	BLWP @STRREF		get the file name, length byte after >C7 and then string
	MOVB *R2+,R3		get length of file name
	SRL R3,8		to lsb
	A R3,R2		Now R2 points to next byte after end of string
	MOVB R0,*R2		zero out that byte

	B @>006A

Here is RUN from XB256 if it helps.

 

Thanks it does help!

[RXB]

Not that this is particularly helpful, but this does work on the 99/8's Extended BASIC II:

100 X$="DSK1.TICTACTOE"::RUN X$

 

It worked even more generally than that:

100 INPUT "DRIVE NUMBER: ":D::INPUT "FILE NAME: ":F$

110 RUN "DSK"&STR$(D)&"."&F$

 

 

Well have to say this is dead as a project.

 

RXB 2018 already has CALL XB(files#open,"DSK5.FILENAME") that will do a CALL FILES(file#open) :: NEW :: RUN "DSK5.FILENAME"

 

And you can use F$="DSK5.FILENAME" as a string or string variable.

 

Also CALL XB or OLD XB will restart XB back to default of DSK1.LOAD but of course in RXB you can press any key for that drive.

[RXB]

RUN	CLR R0
	LI R1,1		first argument in list
	LI R2,BUFFER
	MOV R2,@>832C		adjust XB program pointer so it goes to our dummy line in buffer
	LI R3,>82A9		::RUN  to BUFFER and BUFFER+1
	MOV R3,*R2+
	LI R3,>C720		"" to BUFFER+2 and 32 bytes for file name
	MOV R3,*R2
	INC R2
	BLWP @STRREF		get the file name, length byte after >C7 and then string
	MOVB *R2+,R3		get length of file name
	SRL R3,8		to lsb
	A R3,R2		Now R2 points to next byte after end of string
	MOVB R0,*R2		zero out that byte

	B @>006A

Here is RUN from XB256 if it helps.

 

Well have to say the problem with your solution is it will never work without a 32K and a CALL INIT.

 

RXB 2018 solution is CALL XB("DSK.VOLUME.FILENAME") will function from a Cart with no 32K and stand alone Disk Side Cart.

[senior_falcon]

Just wondering, why the NEW? CALL FILES(N) and RUN "DSK5.FILENAME" gives the same results at least in XB.

[RXB]

Just wondering, why the NEW? CALL FILES(N) and RUN "DSK5.FILENAME" gives the same results at least in XB.

I have in RXB 2018 CALL VDPSTACK(address) and CALL FILES(0)

 

So in RXB 2018 you can move the VDPSTACK location and use more VDP memory then any other XB.

 

These are my first steps to making a version of RXB that allows things like 80 column F18 or SAMS RXB.

[senior_falcon]

Well have to say the problem with your solution is it will never work without a 32K and a CALL INIT.

 

RXB 2018 solution is CALL XB("DSK.VOLUME.FILENAME") will function from a Cart with no 32K and stand alone Disk Side Cart.

And the problem with your solution is that it requires a special cartridge. Looks like we both strike out when it comes to running on an unexpanded TI, although I would guess that the XB+32K combo is far more common than the RXB cartridge.

 

Earlier you posted CALL XB(files#open,"DSK5.FILENAME") that will do a CALL FILES(file#open) :: NEW :: RUN "DSK5.FILENAME"

 

Why is there a "NEW" in there? In XB you do not need a NEW for CALL FILES(N) and RUN "DSK5.FILENAME"

[RXB]

And the problem with your solution is that it requires a special cartridge. Looks like we both strike out when it comes to running on an unexpanded TI, although I would guess that the XB+32K combo is far more common than the RXB cartridge.

 

Earlier you posted CALL XB(files#open,"DSK5.FILENAME") that will do a CALL FILES(file#open) :: NEW :: RUN "DSK5.FILENAME"

 

Why is there a "NEW" in there? In XB you do not need a NEW for CALL FILES(N) and RUN "DSK5.FILENAME"

Unlike CALL FILES it does not reset al pointers for VDP, thus the need for a NEW.

 

Go to XB and type in:

SIZE

now type in:

CALL FILES(1)

SIZE

See the problem? Now type in:

NEW

SIZE

Now you see why?

When you type in CALL FILES(1) and then SIZE it does not report the correct size until you then type in NEW

 

This is odd as how can program space remain the same size when that space has increased?

The NEW does something CALL FILES does not do.....UPDATE ALL VDP POINTERS.

 

Also something is assbackwards here, I increased the size of program space at top of memory,

but the bottom of memory VDP STACK size increased???? WTF????

 

This gets even more strange, go OLD DSK1.LOAD and turn on Classic99 debugger and first address the

LOAD program uses is >3BE8 which is the correct address.

 

By the way in RXB 2018 type in:

CALL FILES(0)

SIZE

 

You get this:

13144 Bytes of Stack Free

24488 Bytes of Program Space Free

8192 Bytes of Assembly Space Free

240 Banks of 4K Pages

1024K SAMS

* MEMORY USED *

>3CEF VDP Free

>0958 VDP Stack

>FFE7 Program Free

>A040 Program End

>2000 RAM Free

>4000 RAM End

Edited June 22, 2018 by RXB