RXB and Integer Variables

[SteveB]

28 minutes ago, apersson850 said:

Unfortunately my advice is then that you stop right there. Since if you aren't going to do integer math with integer variables, like in the A%=B%+C%, then the main benefit of higher speed is gone. The benefit of requiring less storagae space you can get already as it is, if you use CALL LOAD/CALL PEEK to store and retreive values somewhere in memory. Or you can use characters in a string and use their ASCII code as numeric values.

The good thing with integer math and the TMS 9900 is that it's simple. You have almost everything already in the CPU. Just need sign handling for DIV and MPY.

I think the receiver should determine the operations, i.e.

 

A% = V% / 2   ! Integer

A = V% / 2      ! Float

CALL CHAR(%I+1,"FFAAFF") ! Integer

PRINT SIN(%D / 100) ! Float

PRINT %D / 100   ! Float (as we don't know any better)

 

What do you think? Would this be possible? I agree, the more Integer can be used, the more speed we will gain... 

[+RXB]

1 hour ago, apersson850 said:

Well, that's what I'm asking you? The only point I see with integers, if the math still is with reals, is to save space to store them. Which may have a value by itself, but is a bit short handed.

Then it doesn't make sense, since A%+B% should definitely still be in integer. If you want to PRINT it, then perhaps converting it to a float before printing makes sense, since printing takes quite some time anyway.

You mean the opposite, right, CFI will be implied. Which makes sense, as you don't have integer literal values just like that.

Unfortunately my advice is then that you stop right there. Since if you aren't going to do integer math with integer variables, like in the A%=B%+C%, then the main benefit of higher speed is gone. The benefit of requiring less storagae space you can get already as it is, if you use CALL LOAD/CALL PEEK to store and retreive values somewhere in memory. Or you can use characters in a string and use their ASCII code as numeric values.

The good thing with integer math and the TMS 9900 is that it's simple. You have almost everything already in the CPU. Just need sign handling for DIV and MPY.

Sorry you ignored my original post about GRAPHICS WOULD BE FASTER. 

Why does ROW or COLUMN need to be Floating Point when max row is 24 and column is max 32?

There is no row 2.2 or row 7.6 is there?

So Floating Point in row and column is just a really slow way to compute a location on screen.

Same goes for TI99/4A MEMORY ADDRESS as there is no CALL PEEK(8192.42,X) is there?

Memory can be represented by 32767 to -32768 same as it is internally using Hex.

As there is no 8192.42 address in memory using Floating Point is slow way to locate a memory location.

Now math is already built into the system but is only Floating Point math.

A%=A%+8 will operate faster than A=A+8 as the A's will be in Floating Point format after CFI then computed then return to Floating Point.

Floating Point consumes more time to convert back and forth then INTEGER.

As the 8 is a constant not floating point it never needs to be converted into a Floating-Point value thus will be faster than A=A+8 which is all floating point.

Then we have storage space as a bonus too.

 

Now if you want to create a Library of INTEGER MATH for the TI99/4A XB you can do that as RXB Source GPL & Assembly is always free to all.

[+RXB]

52 minutes ago, SteveB said:

I think the receiver should determine the operations, i.e.

 

A% = V% / 2   ! Integer

A = V% / 2      ! Float

CALL CHAR(%I+1,"FFAAFF") ! Integer

PRINT SIN(%D / 100) ! Float

PRINT %D / 100   ! Float (as we don't know any better)

 

What do you think? Would this be possible? I agree, the more Integer can be used, the more speed we will gain... 

Yes you see the reasons and why this would benefit overall to speed thank you.

 

A% = V% / 2   ! Integer                                              [result is integer in A%]

A = V% / 2      ! Float                                                  [result is Floating Point in A]

CALL CHAR(I%+1,"FFAAFF") ! Integer                           [result is integer in I%]

PRINT SIN(D% / 100) ! Float                                        [PRINT forces it to be in Floating Point]

PRINT D% / 100   ! Float (as we don't know any better) [PRINT forces it to be in Floating Point]

[apersson850]

1 hour ago, RXB said:

Sorry you ignored my original post about GRAPHICS WOULD BE FASTER. 

Why does ROW or COLUMN need to be Floating Point when max row is 24 and column is max 32?

That's one good application. FOR-NEXT loops with integer values and step is another good example.
An application for using a real there is to get implicit rounding. If you increment ROW by 1.1 each time you'll eventually get a jump of two rows, not one. But that's a bit rare.

1 hour ago, RXB said:

Now math is already built into the system but is only Floating Point math.

A%=A%+8 will operate faster than A=A+8 as the A's will be in Floating Point format after CFI then computed then return to Floating Point.

That's all backwards. A will be floating point all the time. A% will need CIF (not CFI) to be converted to a real, then literal 8 is made a real (if all math is floating point), a floating point add is used to compute float(A%)+float(8) and eventually it's converted to an integer, to be able to store in A%.
If this is what you plan there's not much purpose with them. It's far too limited. You need to be able to calculate your ROW and COLUMN with integer math too, not just send them to the graphics routine.

1 hour ago, RXB said:

Now if you want to create a Library of INTEGER MATH for the TI99/4A XB you can do that as RXB Source GPL & Assembly is always free to all.

I've not studied how this is handled by other BASIC interpreters, where integer and real variables are a part from the beginning. Reasonably they must apply different ways of doing "+" and the other stuff depending on what variable types are present. Like a Pascal compiler, which doesn't produce the same code for a+b as for c+d, if a and b are reals but c and d are integers.

[+RXB]

38 minutes ago, apersson850 said:

That's one good application. FOR-NEXT loops with integer values and step is another good example.
An application for using a real there is to get implicit rounding. If you increment ROW by 1.1 each time you'll eventually get a jump of two rows, not one. But that's a bit rare.

That's all backwards. A will be floating point all the time. A% will need CIF (not CFI) to be converted to a real, then literal 8 is made a real (if all math is floating point), a floating point add is used to compute float(A%)+float(8) and eventually it's converted to an integer, to be able to store in A%.
If this is what you plan there's not much purpose with them. It's far too limited. You need to be able to calculate your ROW and COLUMN with integer math too, not just send them to the graphics routine.

I've not studied how this is handled by other BASIC interpreters, where integer and real variables are a part from the beginning. Reasonably they must apply different ways of doing "+" and the other stuff depending on what variable types are present. Like a Pascal compiler, which doesn't produce the same code for a+b as for c+d, if a and b are reals but c and d are integers.

Sorry you clearly do not understand how numbers are stored in XB. All numbers in XB are Floating Point 8 byte values.

A% will be stored ONLY in WORD format of 2 bytes ONLY!

It will only be CIF if needed to be used for a Floating Point format for things like math or display.

Look as long as integers like A% are added or subtracted with other integers or integer constants they will never be converted or used as Floating Point values.

Any divide or multiply will trigger Floating Point values instead and slowdown that operation.

100 FOR X%=1 TO Y% STEP Z% will work fine for GRAPHICS or even some math always being INTEGER values from -32768 to 32767

This alone would speed up a FOR/NEXT loops as it is not using Floating Point.

 

You have to go out of your way to trigger Floating Point by forcing it to revert to Floating Point.

Things line ON A% GOSUB line-number-list would be faster than Floating Point

 

CALL SOUND(A%,B%,C%) will process faster than normal XB as CFI is needed to take the values from Floating Point to INTERGER every single time in normal XB!

I could go on and on for the advantages over your limited arguments.

[apersson850]

12 hours ago, RXB said:

Sorry you clearly do not understand how numbers are stored in XB. All numbers in XB are Floating Point 8 byte values.

A% will be stored ONLY in WORD format of 2 bytes ONLY!

On the contrary, I understand that perfectly. That's why I stated that if you don't do integer math, then this is the only advantage you'll have.

Since you claimed earlier that all math would still be floating point, that would ruin most of the good effect of having integers. Perhaps you didn't mean it that way - I don't know. However, it seems my arguments, limited or not, are put to good use, since now you state this:

12 hours ago, RXB said:

Look as long as integers like A% are added or subtracted with other integers or integer constants they will never be converted or used as Floating Point values.

You just need to rething these two, since you most certainly should implement integer multiplication and division.

12 hours ago, RXB said:

Any divide or multiply will trigger Floating Point values instead and slowdown that operation.

Considering that MPY and DIV are available in the processor, it's too simple to do to avoid it. I can even give you the assembly code to handle the signs, if you want that.

Regarding FOR-NEXT, I should have written "... as long as STEP is an integer ..."

 

[Reciprocating Bill]

I really admire Rich's accomplishment in augmenting Extended Basic.

 

I'd also like to see someone apply GPL chops like his to Cortex BASIC - a project that would be sort of the inverse of what Rich is doing with XB. In that instance the core BASIC is already impressively fast (using integers where possible) - but access to hardware features very limited (no sound or speech support, etc.). It consumes a lot of RAM as is, so there is little memory available for assembly-based improvement. But, given an environment supporting lots of GROM space (e.g. FinalGrom), I'd hope that various GPL calls could be grafted on to provide much of the missing hardware access. 

[+RXB]

8 hours ago, apersson850 said:

On the contrary, I understand that perfectly. That's why I stated that if you don't do integer math, then this is the only advantage you'll have.

Since you claimed earlier that all math would still be floating point, that would ruin most of the good effect of having integers. Perhaps you didn't mean it that way - I don't know. However, it seems my arguments, limited or not, are put to good use, since now you state this:

You just need to rething these two, since you most certainly should implement integer multiplication and division.

Considering that MPY and DIV are available in the processor, it's too simple to do to avoid it. I can even give you the assembly code to handle the signs, if you want that.

Regarding FOR-NEXT, I should have written "... as long as STEP is an integer ..."

 

Ok you write the assembly routines to do this and insert them into XB as you think it is so easy.

Like I said the RXB source code is out there and free to all.

[+RXB]

47 minutes ago, Reciprocating Bill said:

I really admire Rich's accomplishment in augmenting Extended Basic.

 

I'd also like to see someone apply GPL chops like his to Cortex BASIC - a project that would be sort of the inverse of what Rich is doing with XB. In that instance the core BASIC is already impressively fast (using integers where possible) - but access to hardware features very limited (no sound or speech support, etc.). It consumes a lot of RAM as is, so there is little memory available for assembly-based improvement. But, given an environment supporting lots of GROM space (e.g. FinalGrom), I'd hope that various GPL calls could be grafted on to provide much of the missing hardware access. 

Thank you I have only added 1 new 8K ROM page to XB so far but I could add many more ROM pages if needed.

This current link we are talking about I am only removing useless Assembly routines in ROM that do silly things like this:

3942            ************************************************************
  3943 7EA6              AORG >7EA6   

 99/4 ASSEMBLER
GREADS                                                       PAGE 0091
  3945                
  3946            * (RAM to RAM)  
  3947            * Read data from ERAM   
  3948            * @GSRC  : Source address on ERAM   
  3949            * @DEST  : Destination address in CPU   
  3950            *           Where the data stored after read from ERAM  
  3951            * @BCNT3 : byte count   
  3952 7EA6 0203  GREAD1 LI   R3,BCNT3          # of bytes to move  
       7EA8 8356  
  3953 7EAA 0202         LI   R2,GSRC           Source in ERAM  
       7EAC 8354  
  3954 7EAE 0201         LI   R1,DEST           Destination in CPU  
       7EB0 8358  
  3955 7EB2 1006         JMP  GRZ1              Jump to common routine  
  3956            * Read data from ERAM to CPU  
  3957            * @ADDR1 : Source address on ERAM   
  3958            * @ADDR2 : Destination address in CPU   
  3959            *           Where the data stored after read from ERAM  
  3960            * @BCNT1 : byte count   
  3961 7EB4 0203  GREAD  LI   R3,BCNT1          # of bytes to move  
       7EB6 834E  
  3962 7EB8 0202         LI   R2,ADDR1          Source in ERAM  
       7EBA 834C  
  3963 7EBC 0201         LI   R1,ADDR2          Destination in CPU  
       7EBE 8350  
  3964            * Common ERAM to CPU transfer routine   
  3965 7EC0 C112  GRZ1   MOV  *R2,R4  
  3966 7EC2 DC74  GRZ2   MOVB *R4+,*R1+         Move byte from ERAM to CPU  
  3967 7EC4 0613         DEC  *R3               One less to move, done?   
  3968 7EC6 16FD         JNE  GRZ2              No, copy the rest   
  3969 7EC8 045B         RT   
  3970            ************************************************************

GREAD1 only moves 1 byte and it takes 37 bytes in GPL to set up GREAD1 so ROM XML GREAD1 can move 1 byte from RAM or VDP to RAM?

A single line in GPL is faster and less complicated. 

      ST  @0(@FAC10),@FAC14

 

GREAD is the same and only moves 1 byte. Another routine GWITE only moves a maximum of 4 bytes but takes 37 bytes to set up too.

A single GPL command is faster then all that work to set up an Assembly routine to move just 4 bytes.

     MOVE @PAD6,@0(@FAC10),V@FAC14

This single 9 byte line does the same thing but is actually faster. So there are some GPL commands that are faster than some XB ROM routines.

[apersson850]

I did this test program in Pascal. It shows the difference in timing for a loop using integer vs. real loop counter variable.

Not the same environment, sure, but uses the console's floating point math and the quickest possible math for the integer, so somewhat relevant to compare anyway.

 

Integer run reports 50 interrupt ticks, the one with floating point 193. So roughly four times faster with integer math.

 

program testing;

var
  a,b,c,d,e,f,g,h:integer;
  x:integer;
  y:real;
  
begin
  time(a,b);
  x := 0;
  repeat
    x := x+1;
  until x>1000;
  time(c,d);

  time(e,f);
  y := 0;
  repeat
    y := y+1;
  until y>1000;
  time(g,h);

  writeln(a,b);
  writeln(c,d);
  writeln(e,f);
  writeln(g,h);
end.

 

[apersson850]

3 hours ago, RXB said:

Ok you write the assembly routines to do this and insert them into XB as you think it is so easy.

Like I said the RXB source code is out there and free to all.

The code is here for you to use. Patching it into RXB is your task. I'm not saying it's easy, but once you figure out how to determine if you should use floating point or integer math when doing add and subtract, it seems the method would be the same to select the float/integer mode for multiply and divide as well.

I realized that the p-code interpreter (PME) already has the code to do this, so this is a copy from that interpreter. The arguments are picked from the stack, pointed to by register SP, and the result returned to the stack again. The register TOPME contains the address to branch to in order to return to the PME to fetch the next instruction.

Note that although MPY is an unsigned multiplication of two 16 bit values to render a 32 bit result, as long as you stay within the limits of 16 bits, the lower part of the result is the result of a signed multiplication. No overflow error check is done here.

DIV is more complex, as the sign must be managed separately.

Just to compare the complexity, I included the code for integer add and subtract from the PME as well.

Thinking about it a bit further, I realize that to make this worthwhile you do at least need to implement negate and absolute value as well. Fortunately just as simple as the add and subtract instructions in the code snippet below.

 

; Multiply integer
MPI		MOV  *SP+,R1	;Pop argument 1
		MPY  *SP,R2		;Multiply with argument 2
		MOV  R2,*SP		;Result to stack
		B    *TOPME		;Return to PME
		
; Divide integer
DVI		CLR  R0			;Clear sign flags
		CLR  R4
		MOV  *SP+,R3	;Pop divisor
		JEQ  DIVZERO
		JGT  ISPOS1
		SETO R4			;Set divisor negative flag
		ABS  R3
ISPOS1	MOV  *SP,R2		;Fetch dividend
		JEQ  RETPME		;If zero, the result (0) is already at top of stack
		JGT  ISPOS2
		SETO R0			;Set dividend negative flag
		ABS  R2
ISPOS2	CLR  R1
		DIV  R3,R1		;Least 16 bits of R1/R3 is now in R1, but without sign
		XOR  R0,R4		;Compare sign flags
		JEQ  RESULT		;Signs equal -> result is positive
		NEG  R1			;One value negative -> result negative
RESULT	MOV  R1,*SP		;Push result to stack
RETPME  B    *TOPME		;Return to PME

DIVZERO  Branch to run-time error "divide by zero"

; Just to compare, here is the code for add and subtract in the same interpreter

ADI		A    *SP+,*SP
		B    *TOPME

SBI		S    *SP+,*SP
		B    *TOPME

 

[+RXB]

So how are you going to handle errors when you get a overflow or underflow values in integer math?

How would the user know where the error took place in something like:

CALL HCHAR(R%*B%/INT(N)+3,C%*D%/INT(N)+5,55)

 

Starting to see how complicated this can get for the interpreter and then report where it went wrong?

Which variable caused the error? 

R% or B% or C% or D%? Or was it the INT(N) or the Multiply or the Divide?

BAD VALUE ERROR or OVERFLOW ERROR or UNDERFLOW ERROR or OUT OF RANGE ERROR?

 

I may add in multiply and divide later, but just to get a working version not only in my head would be first step.

 

[apersson850]

The only error you typically report from integer arithmetic is divide by zero. The rest you just handle with a "you asked for it, you got it" attitude. An overflow may be intentional, since 28000+12000=40000, however in 2's complement it's -25536. But the user may calculate 28000+12000-24000=16000, and that result will be correct even with the sign. So you just don't care about the overflows or underflows. This makes it a lot simpler, and faster.

If the user prints an integer, the PRINT statement needs to handle integer values. If you use CIF to make them floating point, then print as usual, you'll get -25536 even if the users looks at it like 40000. But that will be up to him to handle.

The more tricky part is to figure out which mode to use (integer or floating point) and when to make an implicit type cast to floating point, like in C%*D%/INT(N)+5,55, when you do math.

 

But your original question, so how are you going to handle errors when you get an overflow or underflow value in integer math has the simplest of all answers: You don't. Except divide by zero, but that's pretty straight forward. The code snippet I showed does detect it.

In your statement stub CALL HCHAR(R%*B%/INT(N)+3,C%*D%/INT(N)+5,55) the error detection is this divide by zero I mentioned (which you need to detect for floating point too) and then it's the normal thing which HCHAR does already, to handle if the arguments for row and column are outside of the screen. But that's all.

Edited March 28 by apersson850

[+RXB]

20 minutes ago, apersson850 said:

The only error you typically report from integer arithmetic is divide by zero. The rest you just handle with a "you asked for it, you got it" attitude. An overflow may be intentional, since 28000+12000=40000, however in 2's complement it's -25536. But the user may calculate 28000+12000-24000=16000, and that result will be correct even with the sign. So you just don't care about the overflows or underflows. This makes it a lot simpler, and faster.

If the user prints an integer, the PRINT statement needs to handle integer values. If you use CIF to make them floating point, then print as usual, you'll get -25536 even if the users looks at it like 40000. But that will be up to him to handle.

The more tricky part is to figure out which mode to use (integer or floating point) and when to make an implicit type cast to floating point, like in C%*D%/INT(N)+5,55, when you do math.

 

But your original question, so how are you going to handle errors when you get an overflow or underflow value in integer math has the simplest of all answers: You don't. Except divide by zero, but that's pretty straight forward. The code snippet I showed does detect it.

In your statement stub CALL HCHAR(R%*B%/INT(N)+3,C%*D%/INT(N)+5,55) the error detection is this divide by zero I mentioned (which you need to detect for floating point too) and then it's the normal thing which HCHAR does already, to handle if the arguments for row and column are outside of the screen. But that's all.

Show me your GPL and Assembly code for XB to make this work.

I know full well how XB works as I have been doing this for RXB for 30 years now.

Problem is what you think and the amount of rewrite of XB is extensive and not easy to pull off.

[apersson850]

Maybe you misunderstood me. I've never had the intention to modify BASIC to handle this. But you have, so I'm trying to help you by giving some hints about how it needs to work to be useful in the BASIC context and how integer arithmetic can be implemented, how it works and what kind of error checks that are needed and what are not.

If you want to implement it or not is up to you. Nearly all programming I've done on the TI 99/4A over the years was with UCSD Pascal, where this whole thing is already included from the start. There I've instead spent time implementing things like bit-mapped graphics and pre-emptive multi tasking. So I'm well aware of the obstacles you run into when you try to make a finished product do something it wasn't designed for.

[+RXB]

7 hours ago, apersson850 said:

Maybe you misunderstood me. I've never had the intention to modify BASIC to handle this. But you have, so I'm trying to help you by giving some hints about how it needs to work to be useful in the BASIC context and how integer arithmetic can be implemented, how it works and what kind of error checks that are needed and what are not.

If you want to implement it or not is up to you. Nearly all programming I've done on the TI 99/4A over the years was with UCSD Pascal, where this whole thing is already included from the start. There I've instead spent time implementing things like bit-mapped graphics and pre-emptive multi tasking. So I'm well aware of the obstacles you run into when you try to make a finished product do something it wasn't designed for.

The main issue I constantly have to deal with is BACKWARDS COMPATABILITY OF XB! 

Other XB variates have these features but suck at backwards compatibility.

 

If you can load a XB program from 30 years ago and it will not run unless major changes are made to that XB program that is not BACKWARDS COMPATABILITY OF XB! 

 

[apersson850]

That's a very important point. That's why I'm of the opinion that the interpreter must handle math in a transparent way, so the user can't tell the difference between if he wrote A+B*C, where all variables contain integer values, or wrote A%+B%*C%. Except for the execution speed, which is noticeable, and the smaller memory footprint. The only difference he'll notice is in A=B/C, compared to A%=B%/C%, when the result isn't an integer.

 

As always, this is much easier to do if you plan for it from the beginning.

[+RXB]

On 3/28/2023 at 11:36 AM, apersson850 said:

That's a very important point. That's why I'm of the opinion that the interpreter must handle math in a transparent way, so the user can't tell the difference between if he wrote A+B*C, where all variables contain integer values, or wrote A%+B%*C%. Except for the execution speed, which is noticeable, and the smaller memory footprint. The only difference he'll notice is in A=B/C, compared to A%=B%/C%, when the result isn't an integer.

 

As always, this is much easier to do if you plan for it from the beginning.

So looking at XB ROM assembly why is there a RT after a RT????

I am curious if this is just a bug in XB ROM source code or that second RT has to be there?

Address >6460 and >6462 both are RT so WHY?

 

Spoiler

  0834            * MOVFAC - copies 8 bytes from VDP(@FAC4) or ERAM(@FAC4)  
  0835            *          to FAC   
  0836 6434 C060        MOVFAC MOV @FAC4,R1           Get pointer to source   
       6436 834E  
  0837 6438 0202         LI  R2,8               8 byte values   
       643A 0008  
  0838 643C 0203         LI  R3,FAC             Destination is FAC  
       643E 834A  
  0839 6440 C020         MOV @RAMTOP,R0         Does ERAM exist?  
       6442 8384  
  0840 6444 160A         JNE MOVFA2             Yes, from ERAM  
  0841            *                             No, from VDP RAM  
  0842 6446 06C1         SWPB R1  
  0843 6448 D7C1         MOVB R1,*R15           Load 2nd byte of address  
  0844 644A 06C1         SWPB R1  
  0845 644C D7C1         MOVB R1,*R15           Load 1st byte of address  
  0846 644E 0205         LI   R5,XVDPRD   
       6450 8800  
  0847 6452 DCD5        MOVF1  MOVB *R5,*R3+          Move a byte   
  0848 6454 0602         DEC  R2                Decrement counter, done?  
  0849 6456 15FD         JGT  MOVF1             No, loop for more   
  0850 6458 045B         RT                     Yes, return to caller   
  0851 645A DCF1         MOVFA2 MOVB *R1+,*R3+   
  0852 645C 0602         DEC  R2  
  0853 645E 16FD         JNE  MOVFA2  
  0854 6460 045B         RT   
  0855 6462 045B         RT                     And return to caller                <<<<<<<<<<<<<<<<<<<<<<<< WTF IS THIS??????

 

[+RXB]

Looking for how to optimize XB ROMs for space to instert INTEGER values as variables anyone see a way to make this section more compact?

 

1835            ************************************************************
  1836 6C9A              AORG >6C9A   
  1838                
  1839            * (VDP to VDP) or (RAM to RAM)  
  1840            * GET,GET1          : Get two bytes of data from VDP  
  1841            *                   : R3 : address in VDP   
  1842            *                   : R1 : where the one byte data stored   
  1843            * PUT1              : Put two bytes of data into VDP  
  1844            *                   : R4 : address on VDP   
  1845            *                   : R1 : data   
  1846            * GETG,GETG2        : Get two bytes of data from ERAM   

 99/4 ASSEMBLER
GETPUTS                                                      PAGE 0041
  1847            *                   : R3 : address on ERAM  
  1848            *                   : R1 : where the two byte data stored   
  1849            * PUTG2             : Put two bytes of data into ERAM   
  1850            *                   : R4 : address on ERAM  
  1851            *                   : R1 : data   
  1852            * PUTVG1            : Put one byte of data into ERAM  
  1853            *                   : R4 : address in ERAM  
  1854            *                   : R1 : data   
  1855                
  1856            * Get two bytes from RAM(R3) into R1  
  1857 6C9A C0FB  GET    MOV  *R11+,R3  
  1858 6C9C C0D3         MOV  *R3,R3  
  1859 6C9E D7E0  GET1   MOVB @R3LB,*R15  
       6CA0 83E7  
  1860 6CA2 D7C3         MOVB R3,*R15   
  1861 6CA4 1000         NOP  
  1862 6CA6 D060         MOVB @XVDPRD,R1  
       6CA8 8800  
  1863 6CAA D820         MOVB @XVDPRD,@R1LB   
       6CAC 8800  
       6CAE 83E3  
  1864 6CB0 045B         RT   
  1865            * Put two bytes from R1 to RAM(R4)  
  1866 6CB2 D7E0  PUT1   MOVB @R4LB,*R15  
       6CB4 83E9  
  1867 6CB6 0264         ORI  R4,WRVDP  
       6CB8 4000  
  1868 6CBA D7C4         MOVB R4,*R15   
  1869 6CBC 1000         NOP  
  1870 6CBE D801         MOVB R1,@XVDPWD  
       6CC0 8C00  
  1871 6CC2 D820         MOVB @R1LB,@XVDPWD   
       6CC4 83E3  
       6CC6 8C00  
  1872 6CC8 045B         RT   
  1873            * Get two bytes from ERAM(R3) to R1   
  1874 6CCA C0FB  GETG   MOV  *R11+,R3  
  1875 6CCC C0D3         MOV  *R3,R3  
  1876      6CCE  GETG2  EQU  $   
  1877 6CCE D073         MOVB *R3+,R1   
  1878 6CD0 D813         MOVB *R3,@R1LB   
       6CD2 83E3  
  1879 6CD4 0603         DEC  R3  
  1880 6CD6 045B         RT   
  1881            * Put two bytes from R1 to ERAM(R4)   
  1882      6CD8  PUTG2  EQU  $   
  1883 6CD8 DD01         MOVB R1,*R4+   
  1884 6CDA D520         MOVB @R1LB,*R4   
       6CDC 83E3  
  1885 6CDE 0604         DEC  R4                Preserve R4   
  1886 6CE0 045B         RT   
  1887            ************************************************************

 

[apersson850]

At least in that piece of code I can't see a reason for dual RT "instructions".