MOVE G*?

[ralphb]

Is the addressing mode G*>xxxx a valid GS argument in a MOVE statement?

 

AFAIK, the official GPL documentation doesn't mention it, but it can be inferred from combining MOVE bits I and C. In fact, assembling this program

.

        GROM >6000

        DATA >AA01
        DATA >0000
        DATA >0000
        DATA MENU
        DATA 0,0,0,0
MENU    DATA 0
        DATA START
        BYTE 7
        TEXT 'G* TEST'

VAL     TEXT 'HI'
START   DST  VAL,@>8300
        MOVE 2,G@VAL,V@170
        MOVE 2,G*>8300,V@180
        B    $

.

with the Ryte Data GPL assembler yields this byte code for the second MOVE statement:

.

(MOVE) 37 (Count) 00 02 (GD) a0 b4 (GS) 90 00

.

The GS byte code stands for 2 byte address indirect 0 or >8300. But when I execute above program in MESS, only one "HI" is shown.

 

I've tried changing "9000" to "00", "8000", "FF0000", "FF8300", but none of them work.

 

So, is G* for real?

 

[+Lee Stewart]

Is the addressing mode G*>xxxx a valid GS argument in a MOVE statement?

 

AFAIK, the official GPL documentation doesn't mention it, but it can be inferred from combining MOVE bits I and C. In fact, assembling this program

.

        GROM >6000

        DATA >AA01
        DATA >0000
        DATA >0000
        DATA MENU
        DATA 0,0,0,0
MENU    DATA 0
        DATA START
        BYTE 7
        TEXT 'G* TEST'

VAL     TEXT 'HI'
START   DST  VAL,@>8300
        MOVE 2,G@VAL,V@170
        MOVE 2,G*>8300,V@180
        B    $

.

with the Ryte Data GPL assembler yields this byte code for the second MOVE statement:

.

(MOVE) 37 (Count) 00 02 (GD) a0 b4 (GS) 90 00

.

The GS byte code stands for 2 byte address indirect 0 or >8300. But when I execute above program in MESS, only one "HI" is shown.

 

I've tried changing "9000" to "00", "8000", "FF0000", "FF8300", but none of them work.

 

So, is G* for real?

 

 

A couple of GPL Assembler manuals I've perused use it. You must have forgotten that ‘*’ indicates indirection, so the 'HI' in >8300 would yield a GROM address of >4849 (not what you intended for “G*>8300”). I am not sure what GPL would do with that address—look for it in GROM #2, perhaps? I suppose that MOVE would stash what it found there into VRAM at >0180. OOPS! Your code is correct! Sorry.

 

...lee

Edited August 12, 2017 by Lee Stewart

[RXB]

Look at RXB GPL source code for how TI used MOVE and my code on how I use MOVE.

 

 

TABLE DATA >0001,>0002,>0003,>0004,>0005,>0006,>0007,>0008

LABEL MOVE 16,G@TABLE,V@180

 

This is normally how I move GROM to someplace.

 

But you can also do this:

 

TABLE DATA >0001,>0002,>0003,>0004,>0005,>0006,>0007,>0008

DST TABLE,@>8300

MOVE 16,G*>8300,V@180

 

Or

 

TABLE DATA >0001,>0002,>0003,>0004,>0005,>0006,>0007,>0008

DST TABLE,@>8300

MOVE 16,G@>0000(@>8300),V@180

 

This adds >0000 + TABLE as a GROM address.

 

TABLE DATA >0001,>0002,>0003,>0004,>0005,>0006,>0007,>0008

DST TABLE,@>8300

MOVE 16,G*>8300+>0000,V@180

 

GPL IS VERY VERY FLEXIBLE.

Edited August 12, 2017 by RXB

[ralphb]

OK, but then why is my program not working? What is the byte code for "MOVE 2,G*>8300,V@180"?

[RXB]

OK, but then why is my program not working? What is the byte code for "MOVE 2,G*>8300,V@180"?

Hmm I got it to work fine in Classic99?

 

Other then it locks up with a loud sound I would change the B $ into JMP START

 

What GPL Assembler are you using as I use the Ryte Data GPL Assembler and Classic99 and it works fine, of course you have to have GPL*LOADER to make it load into GRAM.

[ralphb]

Does that mean you're using the GPL simulator?

 

Here's my BIN file assembled with Ryte Data, that works as a cartridge:

 

gstarg.bin

 

It shows only one "HI" instead of two in MESS, in Classic 99 (assuming I did it right) and with the FinalGROM 99.

 

Can you post your file that is working?

[ralphb]

Addendum: I did some further experimenting, and G*>8300 is not interpreted as *>8300 or @>8300!

[ralphb]

Looking at my test cases, I found a remark that G* would not work with the RAG assembler, so I checked again:

 

 

Also, when you look at the address formats for G@>xxxx and G@>xxxx(@>xx), then the Ryte Data bytecode for G*>xxxx really sticks out as alien.

 

I would conclude that G* is an invention of Ryte Data that was implemented in their assembler and in their simulator, but the TI GPL interpreter does not understand it.

 

[RXB]

Miller Graphics used the Ryte Data GPL Assembler.

 

Also If you look at the TI 990 they use the same G* or V* or *address as the TI99/4A so I do not get your objection.

 

Page 3-7 from the Texas Instruments GPL Manual by Texas Instruments shows *LOC or RAM*LOC (Which is VDP) so no Ryte Data did it correctly.

 

The only major change from Ryte Data is RAM is VDP not real RAM and G is GROM not G# like TI did it.

 

Yea some changes were made but I agree with Miller Graphics as the TI versions are confusing as hell.

Edited August 13, 2017 by RXB

[ralphb]

You're right, page 3-7 does show indirect GROM addressing. Then why does my program not work, or can you post your working (from cartridge) program?

[RXB]

You're right, page 3-7 does show indirect GROM addressing. Then why does my program not work, or can you post your working (from cartridge) program?

You know I was wrong it does ASSEMBLE, but does not work.

I get the "HI" at 180 but not at 170, so it does assemble but fails to work.

 

So G* just does not work, which explains why in GPL instead I have always used G@number(@LABEL) instead of G*NUMBER or G*ADDRESS or G*LABEL

 

Anyway this is the LIST file from the Ryte Data GPL Assembler:

99/4 GPL-ASSEMBLER (Pass 2) correct                                   PAGE 0001 
Version 2.0 (Weiand 1985)     Options : LCSFPF#########                         
[0001]                       GROM >6000
[0002]              
[0003] 6000 AA,01            DATA >AA01
[0004] 6002 00,00            DATA >0000
[0005] 6004 00,00            DATA >0000
[0006] 6006 60,10            DATA MENU
[0007] 6008 00,00,00         DATA 0,0,0,0
       600B 00,00,00
       600E 00,00
[0008]              
[0009] 6010 00,00    MENU    DATA 0
[0010] 6012 60,1E            DATA START
[0011] 6014 07               BYTE 7
[0012] 6015 47,2A,20         TEXT 'G* TEST'
       6018 54,45,53
       601B 54
[0013]              
[0014] 601C 48,49    VAL     TEXT 'HI'
[0015]              
[0016] 601E BF,00,60 START   DST  VAL,@>8300
       6021 1C
[0017]              
[0018] 6022 37,00,02         MOVE 2,G*VAL,V@170
       6025 A0,AA,9F
       6028 DD,1C
[0019]              
[0020] 602A 33,00,02         MOVE 2,G@0(@>8300),V@180
       602D A0,B4,00
       6030 00,00
[0021]                       
.
99/4 GPL-ASSEMBLER (Pass 2) correct                                   PAGE 0002 
Version 2.0 (Weiand 1985)     Options : LCSFPF#########                         
Symbol Table #1 (New,alpha)  
6010 MENU       601E START      601C VAL        
.
99/4 GPL-ASSEMBLER (Pass 2) correct                                   PAGE 0003 
Version 2.0 (Weiand 1985)     Options : LCSFPF#########                         
Symbol Table #2 (New,value)  
6010 MENU       601C VAL        601E START      
.
99/4 GPL-ASSEMBLER (Pass 2) correct                                   PAGE 0004 
Version 2.0 (Weiand 1985)     Options : LCSFPF#########                         
Symbol Table #4 (Def,alpha)  
0034 ACCTON     835C ARG        0032 ATN        0036 BADTON     003B BITREV     
0012 CFI        0014 CNS        002C COS        0010 CSN        8372 DATSTK     
0001 DIVZER     0003 ERRIOV     0006 ERRLOG     0005 ERRNIP     0002 ERRSNN     
0004 ERRSQR     0028 EXP        834A FAC        0006 FADD       000A FCOMP      
0009 FDIV       0008 FMUL       836C FPERAD     0007 FSUB       0038 GETSPACE   
0022 INT        0010 LINK       0018 LOCASE     002A LOG        8370 MEMSIZ     
003D NAMLNK     8300 PAD        0024 PWR        0012 RETURN     000B SADD       
000F SCOMP      000E SDIV       8375 SGN        002E SIN        000D SMUL       
8400 SOUND      0026 SQR        000C SSUB       837C STATUS     0016 STCASE     
8373 SUBSTK     0030 TAN        0007 TRIGER     004A UPCASE     836E VSPTR      
0001 WRNOV      837F XPT        837E YPT        
.
99/4 GPL-ASSEMBLER (Pass 2) correct                                   PAGE 0005 
Version 2.0 (Weiand 1985)     Options : LCSFPF#########                         
Symbol Table #8 (Def,value)  
0001 DIVZER     0001 WRNOV      0002 ERRSNN     0003 ERRIOV     0004 ERRSQR     
0005 ERRNIP     0006 ERRLOG     0006 FADD       0007 FSUB       0007 TRIGER     
0008 FMUL       0009 FDIV       000A FCOMP      000B SADD       000C SSUB       
000D SMUL       000E SDIV       000F SCOMP      0010 CSN        0010 LINK       
0012 CFI        0012 RETURN     0014 CNS        0016 STCASE     0018 LOCASE     
0022 INT        0024 PWR        0026 SQR        0028 EXP        002A LOG        
002C COS        002E SIN        0030 TAN        0032 ATN        0034 ACCTON     
0036 BADTON     0038 GETSPACE   003B BITREV     003D NAMLNK     004A UPCASE     
8300 PAD        834A FAC        835C ARG        836C FPERAD     836E VSPTR      
8370 MEMSIZ     8372 DATSTK     8373 SUBSTK     8375 SGN        837C STATUS     
837E YPT        837F XPT        8400 SOUND      

[ralphb]

Thanks for your confirmation, Rich. It's weird that they didn't implement a documented feature, and I still don't know what actually happens when the G* MOVE is executed.

 

Your workaround using g@0(>83xx) is great, thanks!