IGNORED

# RXB and Integer Variables

## Recommended Posts

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...

##### Share on other sites

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.

##### Share on other sites

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]

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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 ..."

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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
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
3956            * Read data from ERAM to 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.

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.

##### Share on other sites

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.```

##### Share on other sites

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

; 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

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

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

B    *TOPME

SBI		S    *SP+,*SP
B    *TOPME```

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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!

##### Share on other sites

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.

##### Share on other sites

• 1 month later...
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
0844 644A 06C1         SWPB R1
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
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??????

##### Share on other sites

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            ************************************************************```

##### Share on other sites

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

## 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.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.