Assembly on the 99/4A

[+Vorticon]

Thanks guys. Does accessing the parallel port (both reads and writes)disable interrupts?

For what I have in mind, missing a few 1/60th of a second cycles will not be problematic, as long as PIO access does not affect interrupts. If it does, then I may have to go the 9901 route.

[+Lee Stewart]

Thanks guys. Does accessing the parallel port (both reads and writes)disable interrupts?

For what I have in mind, missing a few 1/60th of a second cycles will not be problematic, as long as PIO access does not affect interrupts. If it does, then I may have to go the 9901 route.

 

PIO uses DSR access and, I believe, all DSRs disable interrupts at some point.

 

...lee

[Willsy]

You can bypass the DSR for serial and paralell (sp?) access and go straight to the hardware, though owners of the new nanoPEB won't thank you for it

 

If you're going direct to the hardware, then I reckon (haven't tested) you can leave interrupts enabled (LIMI 2) - just don't use GPLWS as your workspace, as that is used by the console ISR IIRC.

[Willsy]

Hmm... Thinking about it some more, arrival of a byte at the serial port (dunno about parallel port) I think causes an interrupt. I can't remember now. Recommend a good review of Thierry's pages on the TI RS233 card.

[marc.hull]

Has anyone ever run into problems with the divide instruction giving a larger than possible remainder after execution ?

 

My understanding is that the divide instruction takes two registers and treats that as an unsigned integer in the form of >XXXX XXXX. This is divided by a third value in the form of >XXXX. This should yield a quotient of >XXXX and a remainder of >XXXX (where remainder >XXXX is always less than the divisor.)

 

This weekend when trying to improve my RNG I was dividing larger than 16 bit numbers by the value 768 and was getting remainders much larger than 768. When I cleared the first word of the word pair the remainder came back into range.

 

IE >XXXX XXXX / 768 yielded remainders larger than 768. Whereas >0000 XXXX / 768 yielded remainders smaller than 768.

 

Am I missing something about the significance of the word pair or does the divide instruction have a bug in it ?

[+mizapf]

Well, if you're getting an overflow, the arguments won't be changed. Maybe your remainder is just the original value of the second word?

[marc.hull]

Well, if you're getting an overflow, the arguments won't be changed. Maybe your remainder is just the original value of the second word?

Well that's probably it then.Just to clarify......

 

If the instruction creates a quotient larger than 65536 then it terminates and leaves the word pair unchanged ?

 

Thanks

[+mizapf]

Yes. The arguments remain unchanged. The overflow test can be done before the division process starts; the ALU just has to check whether the divisor is greater than the first word.

[+Lee Stewart]

Well that's probably it then.Just to clarify......

 

If the instruction creates a quotient larger than 65536 then it terminates and leaves the word pair unchanged ?

 

Thanks

 

Not to put too fine a point on it; but, it would be a quotient larger than 65535 (FFFFh).

 

...lee

[+Vorticon]

Hi. What is the best way to slow down KSCAN polling? I tried something along those lines and it broke the key scanning process completely, but I'm not sure why:

KEYINP MOV  R11,@SUBRTN       * SAVE SUBROUTINE RETURN ADDRESS
       LI   R1,>FF00
RESCAN BLWP @KSCAN            * CALL KEYSCAN ROUTINE
DELAY  LI   R10,5000          * DELAY LOOP
       DEC  R10
       JNE  DELAY
       CB   @KEY,R1           * KEY IS ADDRESS OF KEY VALUE RETURNED BY KSCAN
       JEQ  RESCAN            * AN >FF INDICATES NO KEY PRESSED
       MOV  @SUBRTN,R11       * RELOAD RETURN ADDRESS INTO R11
       B    *R11
       

[+Vorticon]

OK I think I'm going to answer my own post. The main need for the delay was to avoid the same key being detected repeatedly. I found this in my Ultimate Planet code, which should do the trick (I must have been a little smarter a couple of years ago )

** KEY INPUT ROUTINE **
KEYINP MOV  R11,@SUBRTN       * SAVE SUBROUTINE RETURN ADDRESS
SCAN   CLR  @GPLSTS           * CLEAR GPL STATUS BYTE
       BLWP @KSCAN            * CALL KEYSCAN ROUTINE
       LIMI 2                 * ENABLE INTERRUPTS
       LIMI 0                 * DISABLE INTERRUPTS
       CB   @ANYKEY,@GPLSTS   * CHECK IF BIT 2 OF GPL STATUS BYTE IS SET
       JNE  SCAN              * RESCAN IF SAME KEY PRESENT IN KEY BUFFER
       MOV  @SUBRTN,R11       * RELOAD RETURN ADDRESS INTO R11
       B    *R11

[Asmusr]

I suggest to move LI R10,5000 outside the delay loop

[+Vorticon]

I suggest to move LI R10,5000 outside the delay loop

Of course No idea how I missed that!!! Excellent suggestion he he... I need more sleep

 

In case anybody is wondering what I'm up to, I finally finished early this morning the basic framework of a robotic arm control program which controls this robotic arm http://www.owirobots.com/store/index.php?l=product_detail&p=110 which was kindly given to me by Jens Eike last year at the Chicago Fair. The arm is purely mechanical with only gears, 5 motors and an LED light without any electronics, sensors or servos, and I have it hooked up to the parallel port through some simple relay circuitry to provide bi-directional control.

As things stand now, I am able to control the arm manually through the TI keyboard. I still want to implement a programming option, but I'm not sure I'll have that finished by Faire time because I still have to move the circuitry off the breadboard and onto a more permanent platform, either a home brew PCB or a perf board tonight.

I should be able to demo the arm at the Faire on Saturday. Fun little project

Edited October 31, 2013 by Vorticon

[Willsy]

Excellent. That's just begging to be done in Forth. TF or fbForth, I don't care, but it's perfect Forth. Imagine just typing commands and watching the arm move, then combining those commands into colon definitions. Just like Logo!

[+Vorticon]

Excellent. That's just begging to be done in Forth. TF or fbForth, I don't care, but it's perfect Forth. Imagine just typing commands and watching the arm move, then combining those commands into colon definitions. Just like Logo!

Definitely something to consider. Embed the assembly code into colon definitions and string them together at will. I assume that there should be no limitations in low level access of the PIO port from within forth.

Edited October 31, 2013 by Vorticon

[Willsy]

None at all. If you load the assembler you can write assembler code and add it to the dictionary like colon defs.

 

E.g. (TF)

 

 

ASM: delay ( n -- )
  *SP+ R1 MOV,   \ pop n to R1
  $FFFF R0 MOV, \ inner delay to R0
  BEGIN,
    BEGIN,
      R0 DEC,  \ decrement r0
    NE REPEAT, \ loop while r0<>0
    R1 DEC, \ decrement outer delay
  NE REPEAT, \ loop while R1 <> 0
;ASM

 

Boom. That's a machine code definition. You can run it right after typing it:

 

5 DELAY

 

No "edit/save/assemble/load" cylce. Just type it in.

[Willsy]

You can even mix Forth and assembly. So, for example, the CRU address of the TI RS232 could be defined as a constant:

 

 

$FACE CONSTANT RS232_CRU  \ (don't know what the cru address is!)
 
ASM: SendToPIO( n -- ) \ send a byte to the PIO
  R12 RS232_CRU LI,  \ load CRU address
  ...
  ...
;ASM

[+Vorticon]

 

You can even mix Forth and assembly. So, for example, the CRU address of the TI RS232 could be defined as a constant:

$FACE CONSTANT RS232_CRU  \ (don't know what the cru address is!)
 
ASM: SendToPIO( n -- ) \ send a byte to the PIO
  R12 RS232_CRU LI,  \ load CRU address
  ...
  ...
;ASM

>1300

Edited October 31, 2013 by Vorticon

[+Vorticon]

None at all. If you load the assembler you can write assembler code and add it to the dictionary like colon defs.

 

E.g. (TF)

ASM: delay ( n -- )
  *SP+ R1 MOV,   \ pop n to R1
  $FFFF R0 MOV, \ inner delay to R0
  BEGIN,
    BEGIN,
      R0 DEC,  \ decrement r0
    NE REPEAT, \ loop while r0<>0
    R1 DEC, \ decrement outer delay
  NE REPEAT, \ loop while R1 <> 0
;ASM

Boom. That's a machine code definition. You can run it right after typing it:

 

5 DELAY

 

No "edit/save/assemble/load" cylce. Just type it in.

Old habits die hard... Frankly I never even considered Forth when I started this project a week ago. The control program is pretty simple because the PIO is so easy to access, so it should be fairly straightforward to port it to TF. I'll have to look at this after the Faire.

[Willsy]

Or, send me your assembly code and I'll port it.

[+Vorticon]

Or, send me your assembly code and I'll port it.

I just might take you up on that offer! I'll send you the source code once it is finalized.

[matthew180]

In case anybody is wondering what I'm up to, I finally finished early this morning the basic framework of a robotic arm control program which controls this robotic arm ...

 

... I should be able to demo the arm at the Faire on Saturday. Fun little project

VERY COOL! I really like robotics and I'll be very interested in seeing your project!

[+Vorticon]

So one of my peeves with the TI Assembler is that one is not allowed labels longer than 6 characters. This becomes a nightmare with large programs as I struggle to come up with unique yet meaningful tags. I noted that the asm994a assembler allows the use of long labels, however the resulting object code will not run and will give the error of ILLEGAL TAG.

Is there a better native assembler out there which allows long labels?

[+Lee Stewart]

So one of my peeves with the TI Assembler is that one is not allowed labels longer than 6 characters. This becomes a nightmare with large programs as I struggle to come up with unique yet meaningful tags. I noted that the asm994a assembler allows the use of long labels, however the resulting object code will not run and will give the error of ILLEGAL TAG.

Is there a better native assembler out there which allows long labels?

 

Works fine for me. Are you using Assm994a v3.010? Post the code so we can look over your shoulder.

 

...lee

[+Vorticon]

 

Works fine for me. Are you using Assm994a v3.010? Post the code so we can look over your shoulder.

 

...lee

 

It's really a very simple test:

                  DEF    START12345678

START12345678     CLR    R1
                  LI     R2,>FF00
                  MOVB   R2,R1
                  END