Jump to content

Photo

GPLLNK when autorunning assembly


10 replies to this topic

#1 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,177 posts
  • Location:Lansing, NY, USA

Posted Wed Jul 4, 2018 7:03 PM

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


#2 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,122 posts

Posted Wed Jul 4, 2018 7:35 PM

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?  



#3 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,177 posts
  • Location:Lansing, NY, USA

Posted Wed Jul 4, 2018 9:10 PM

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.



#4 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,128 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Jul 4, 2018 11:21 PM

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?

#5 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,177 posts
  • Location:Lansing, NY, USA

Posted Thu Jul 5, 2018 5:33 AM

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 by senior_falcon, Fri Jul 6, 2018 10:47 AM.


#6 RXB OFFLINE  

RXB

    River Patroller

  • 3,167 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jul 5, 2018 10:11 AM

 

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 by RXB, Thu Jul 5, 2018 10:14 AM.


#7 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,128 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Jul 5, 2018 10:20 AM

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?

#8 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,177 posts
  • Location:Lansing, NY, USA

Posted Thu Jul 5, 2018 10:33 AM

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 likes this

#9 RXB OFFLINE  

RXB

    River Patroller

  • 3,167 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jul 5, 2018 1:42 PM

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.



#10 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 491 posts

Posted Wed Jul 11, 2018 7:01 AM

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.



#11 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,177 posts
  • Location:Lansing, NY, USA

Posted Wed Jul 11, 2018 7:58 AM

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.






1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users