GPLLNK when autorunning assembly

[senior_falcon]

I have come across an interesting problem using GPLLNK. You can see this if you test the program below. If you CALL LOAD the program and then CALL LINK("GTEST") the computer beeps and then gets into an endless loop. (as intended) If you change the END to END GTEST it will run automatically run GTEST as it should. It gets to >7118 which you can see with Classic99's debuger, but then there is no beep and no endless loop. It just returns to BASIC. Is there any way to get this to work properly?

	DEF GTEST
	AORG >7118
	
GTEST	BLWP @>6018
	DATA >0036
ELOOP	LIMI 2
	LIMI 0
	JMP ELOOP
        END
*	END GTEST

[+InsaneMultitasker]

When you perform the LINK versus auto-run, is there a difference in the workspace pointer? Is >6018 using the same WS as the loader, for example?

[senior_falcon]

I wondered that too, but as near as I can tell things are the same. I tried clearing the status byte but that made no difference. Tomorrow I will post debug screens unless some can come up with some insights before then.

[Tursi]

We went through this question a few years ago somewhere, and eventually tracked down what the autorun was not setting, and how to make GPLLNK work in that case.

 

Darned if I remember where we did it - one of the Yahoo groups?

[senior_falcon]

Tursi's answer in post #22 in the thread "GPLLNK issue" tells how to fix this. In MiniMemory the GPL address should be >6917

 

One further question is this: is it necessary to have the delay between the writes to GRMWA?

Edited July 6, 2018 by senior_falcon

[RXB]

 

I have come across an interesting problem using GPLLNK. You can see this if you test the program below. If you CALL LOAD the program and then CALL LINK("GTEST") the computer beeps and then gets into an endless loop. (as intended) If you change the END to END GTEST it will run automatically run GTEST as it should. It gets to >7118 which you can see with Classic99's debuger, but then there is no beep and no endless loop. It just returns to BASIC. Is there any way to get this to work properly?

	DEF GTEST
	AORG >7118
	
GTEST	BLWP @>6018
	DATA >0036
ELOOP	LIMI 2
	LIMI 0
	JMP ELOOP
        END
*	END GTEST

Just currious have you tried RXB:

 

CALL EXECUTE(ADDRESS)

 

This RXB subroutine does not use GPL Workspace but Expects your own.

 

The EXECUTE subprogram directly goes to the cpu-address and

expects to find 4 bytes to be present. The bytes are 1 and 2

define the workspace register address. Bytes 3 and 4 define

the address to start execution at in cpu memory. Programmers

can see this is a BLWP at a cpu-address. The programmer is

responsible for keeping track of the workspace and program

space he is using. Also for any registers while doing a BL or

another context switch. A RTWP will end either a BL or a BLWP

as long as registers set are not changed. By using CALL LOAD

or CALL MOVES the programmer can set up a BLWP routine in the

lower 8K by filling the registers with values first, then

using CALL EXECUTE to directly complete these commands. This

is faster then CALL LINK as no interpretation of the access

or values are checked.

EXECUTE runs a XML link from GPL by moving 12 bytes from the

Fast RAM at HEX 8300 to VDP at HEX 03C0 then moving the value

in FAC passed from XB to HEX 8304 and does a GPL XML >F0

After a RTWP by the Assembly program, it returns VDP HEX 03C0

to Fast RAM HEX 8300 so the 12 bytes are restored. Thus this

allows programmers use of FAC and ARG areas in Fast RAM.

Here is the program loaded into Fast RAM by EXECUTE:

AORG >8300

CPUPGM DATA >8302 First address.

BLWP @>834A Switch context

with FAC as dummy.

CLR @>837C Clear for GPL return.

RTWP Return to GPL.

END

If a programmer absolutely must use Fast RAM for his program

I suggest he set up a buffer for saving HEX 8300 to HEX 83FF

if only so it will not mess up any GPL pointers and don't go

and mess up the 12 bytes at VDP HEX >03C0. Then the only

thing to worry about is messing up something else.

Programs

Line 100 initializes lower 8k | >100 CALL INIT

Line 110 loads the assembly | >110 CALL LOAD(9838,47,0,38,1

program shown below. VMBR | 14,4,32,32,44,3,128)

Line 120 loads registers with | >120 CALL LOAD(12032,0,0,48,0

VDP address, Buffer, Length. | ,2,255)

Line 130 runs line 110 program| >130 CALL EXECUTE(9838)

Line 140 loads the assembly | >140 CALL LOAD(9838,47,0,38,1

program shown below. VMBW | 14,4,32,32,36,3,128)

Line 150 loads registers with | >150 CALL LOAD(12032,0,0,48,0

VDP address, Buffer, Length. | ,2,255)

Line 160 runs line 140 program| >160 CALL EXECUTE(9838)

Line 170 put a command in here| >170 CALL VCHAR(1,1,32,768)

Line 180 loops to line 160 | >180 GOTO 160

HEX ADDRESS|HEX VALUE|ASSEMBLY COMMAND EQUIVALENT

>266E >2F00 DATA >2F00 (workspace area address)

>2670 >2672 DATA >2672 (start execution address)

>2672 >0420 BLWP (first executed command)

>2674 >202C @VMBR (or >2024 VMBW)

>2676 >0380 RTWP

-------------------------------------------------------------

>2F00 >0000 REGISTER 0 (VDP address)

>2F02 >3000 REGISTER 1 (RAM buffer address)

>2F04 >02FF REGISTER 2 (length of text)

Normal XB using LINK.

Initialize for Assembly. | >100 CALL INIT

Load support routine. | >110 CALL LOAD("DSK1.TEST")

LINK to program. | >120 CALL LINK("GO")

RXB EXECUTE EXAMPLE. |

Initialize for Assembly. | >100 CALL INIT

Load support routine. | >110 CALL LOAD("DSK1.TEST")

EXECUTE program address. | >120 CALL EXECUTE(13842)

EXECUTE does no checking so the address must be correct.

The LINK method finds the name and uses the 2 byte address

after the name to run the Assembly. EXECUTE just runs the

address without looking for a name thus faster.

Options.

Dependent on Programmers use and skill.

Edited July 5, 2018 by RXB

[Tursi]

One further question is this: is it necessary to have the delay between the writes to GRMWA?

It's not clear. The Bunyard manual strongly insists that it absolutely is, otherwise you'll randomly crash GROM chips. But I haven't heard of anyone actually doing so, and the GROMs themselves halt the CPU during access to ensure that data transfer itself occurs. I haven't done much GROM access myself, anyone else ever see it?

[senior_falcon]

The reason it matters to me is that I have just enough memory for the code needed to write the two bytes. I will have to be more creative if a NOP or SWPB is needed. Otherwise I'd just do it.

[RXB]

The reason it matters to me is that I have just enough memory for the code needed to write the two bytes. I will have to be more creative if a NOP or SWPB is needed. Otherwise I'd just do it.

LOL CAN SAVE YOU 8 BYTES WITH RXB CALL EXECUTE(ADDRESS) INSTEAD OF CALL LINK('NAME") THAT REQUIRES 8 BYTES.

[apersson850]

My experience is that the recommended delay instruction can be omitted at all times if you run from 8-bit wide RAM. But if your code is in 16-bit RAM without wait states, then you may get issues if you don't use the delay instruction.

[senior_falcon]

My experience is that the recommended delay instruction can be omitted at all times if you run from 8-bit wide RAM. But if your code is in 16-bit RAM without wait states, then you may get issues if you don't use the delay instruction.

Thanks. I found the extra memory I needed. I had this working, then it wasn't. I have to figure out what is different.