senior_falcon Posted July 5, 2018 Share Posted July 5, 2018 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 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 5, 2018 Share Posted July 5, 2018 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 5, 2018 Author Share Posted July 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 5, 2018 Share Posted July 5, 2018 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 5, 2018 Author Share Posted July 5, 2018 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 5, 2018 Share Posted July 5, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 5, 2018 Share Posted July 5, 2018 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 5, 2018 Author Share Posted July 5, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 5, 2018 Share Posted July 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted July 11, 2018 Share Posted July 11, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 11, 2018 Author Share Posted July 11, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.