TI assembly tutorials

[samishal]

Hello,

 

I'm learning TI assembly at the moment, so far i have had relativly good progress with it but i was wondering if there were any TI asm tutorials out there.

 

-Sam

[RXB]

Quite a few and some videos. The best help I ever got was all the tons of source code.

This is especially helpful if it contains comments that explain what is being done step by step.

 

You have come to the correct site as most here are very good at Assembly or some other languages.

[jacquesg]

Go to pergrem.com/tibooks

 

This site contains 4 or 5 books useful to anyone wanting to learn assembly.

 

The Compute! book by Lottrup, shown as a recent addition, is considered by many as their first choice, and the Molesworth book, "Introduction to Assembly Language for the Ti Home Computer" is also favoured by many.

 

Years ago I found a two disk set of tutorials put out by the Chicago TI Users Group, but now I cannot remember where I got it. The nice thing about this set was that each lesson was first done in XB and then the assembly code to do the same thing was presented. It had about 15 lessons and was presented as a series in the CTIUG newsletter.

 

I am still very much a student of assembly.

 

Jacques

[airernie]

Something that was recommended to me, and I found useful, was start with converting some of the BASIC programs contained in the User's Reference Manual that came with the 99/4A. It's amazing how much you'll learn.

 

Ernie

[matthew180]

I started a thread on assembly. It was going good while people were asking questions. If you want a specific tutorial, make a request...

 

http://www.atariage.com/forums/topic/162941-assembly-on-the-994a/

[idflyfish]

I started a thread on assembly. It was going good while people were asking questions. If you want a specific tutorial, make a request...

 

http://www.atariage....ly-on-the-994a/

 

Well we wanted to give you a break so you can crank out F18A's for the rest of us.

[+Vorticon]

OK so here's a very basic question for you. As I started delving into the code of Ultimate Planet, I realized that I had used the LWPI instruction in all of my previous assembly programs to created an alternate register workspace. Why? Because that's what it said in the book that taught me assembly on the TI (Introduction to Assembly Language for the TI Home Computer by Ralph Molesworth -- An fantastically easy book for anyone wanting to learn assembly).

Is this really necessary? Does the TI automatically assign a register workspace when a program is run? If it does, where does it reside by default?

Again I apologize if this seems rather elementary, but I can't seem to find a satisfying answer in my references, including the EA manual, and it's high time I asked the question

[marc.hull]

OK so here's a very basic question for you. As I started delving into the code of Ultimate Planet, I realized that I had used the LWPI instruction in all of my previous assembly programs to created an alternate register workspace. Why? Because that's what it said in the book that taught me assembly on the TI (Introduction to Assembly Language for the TI Home Computer by Ralph Molesworth -- An fantastically easy book for anyone wanting to learn assembly).

Is this really necessary? Does the TI automatically assign a register workspace when a program is run? If it does, where does it reside by default?

Again I apologize if this seems rather elementary, but I can't seem to find a satisfying answer in my references, including the EA manual, and it's high time I asked the question

 

The register set is defined by the loader or caller (presumably.) If you do not change it it will remain the same. I imagine the use of LWPI in the texts is to insure comparability with BASIC ET AL. You don't want to trounce any registers if you are going to return. Long story short.... You don't have to provided your code is stand alone and won't booger up a callers register space.

[senior_falcon]

If the "Quit" key is pressed the console ROM at >0A80 does a BLWP @>0000. That address (>0000) contains:

0000 DATA >83E0

0002 DATA >0024

So pressing the quit key sets the workspace to >83E0 and then executes code starting at >0024.

 

As the A/L code runs other LWPI's may be executed and then if your code is called it will begin with whatever the current workspace is. Since >83E0 is the GPL workspace you probably wouldn't want to use that anyway, as that would complicate using GPLLNK and other console routines. I think it is good practice to use LWPI because then you don't have to wonder where your workspace is.

 

If you running out of E/A or don't care about returning to XB then >8300 and >8320 (and maybe more) look safe to use if you want to use the faster 16 bit scratchpad ram as a workspace.

[RXB]

OK so here's a very basic question for you. As I started delving into the code of Ultimate Planet, I realized that I had used the LWPI instruction in all of my previous assembly programs to created an alternate register workspace. Why? Because that's what it said in the book that taught me assembly on the TI (Introduction to Assembly Language for the TI Home Computer by Ralph Molesworth -- An fantastically easy book for anyone wanting to learn assembly).

Is this really necessary? Does the TI automatically assign a register workspace when a program is run? If it does, where does it reside by default?

Again I apologize if this seems rather elementary, but I can't seem to find a satisfying answer in my references, including the EA manual, and it's high time I asked the question

 

I used a BLWP @ADDRESS in RXB for the CALL EXECUTE(ADDRESS) so the GPL pointers were never at risk.

My logic went this way. CALL LINK needs 6 bytes for the name and 2 bytes for the address of the routine.

 

CALL LINK("name")

1. The name is in VDP string space so it pushes the name onto the vdp stack.

2. Find the name then the address, the more names the more time is needed.

3. When done check for errors and pop name off stack or report error with name on vdp stack.

4. If you do not clear CLR @>837C the program crashes.

Advantages are error checking and ease of use.

Disadvantages are slower and not flexable.

 

RXB

CALL EXECUTE(ADDRESS)

1. Move the VDP 2 byte address into FAC.

2 BLWP @address

 

Advantages depending on how many LINK names RXB EXECUTE can be 5 times faster..

CALL PEEK and CALL POKE are more useful as you can use them to change the program access without additional names like CALL LINK needs.

X=address :: CALL EXECUTE(X) ! Can be modified unlike CALL LINK("NAME") and takes much less memory or time to do.

EXAMPLE:

1450 IF C>15 THEN Z=-12284 ELSE IF C<17 THEN Z=-12288

1460 CALL EXECUTE(Z) :: CALL PEEK(-11884,G,Z,Z,K) ! Peeks the Registers used R1,R2

Embedded Assembly does not need Lower 8K support to work so no CALL INIT is ever needed, this also makes it much more easy to use with the SAMS.

Disadvantages are no error checking is done or errors are returned. (Better become a better programmer)

Edited June 30, 2013 by RXB

[matthew180]

It depends. If you don't care about coexisting with an environment like XB or returning to the E/A menus, then setting the workspace to point to 16-bit scratchpad is critical, IMO. I like >8300 personally. But, the WP (workspace pointer) in the 9900 will always be set to some address that is RAM, otherwise the CPU won't get very far in executing a program.

 

I have also seen some assembly books recommend the bad practice of reserving 32 bytes for your workspace with BSS, then setting the WP to that address. The problem with this is that the reserved memory, on the 99/4A, will be in 8-bit RAM and will be very slow for register access.

 

You always want your workspace to be in the fast 16-bit RAM, and the best way to make sure is to set it yourself.

[+Vorticon]

 

I have also seen some assembly books recommend the bad practice of reserving 32 bytes for your workspace with BSS, then setting the WP to that address. The problem with this is that the reserved memory, on the 99/4A, will be in 8-bit RAM and will be very slow for register access.

 

You always want your workspace to be in the fast 16-bit RAM, and the best way to make sure is to set it yourself.

 

Yup, that is exactly what the Molesworth book instructed... I will follow your advice and use the scratchpad >8300 address instead. Thanks for the tip

[+Vorticon]

If the "Quit" key is pressed the console ROM at >0A80 does a BLWP @>0000. That address (>0000) contains:

0000 DATA >83E0

0002 DATA >0024

So pressing the quit key sets the workspace to >83E0 and then executes code starting at >0024.

 

The register set is defined by the loader or caller (presumably.) If you do not change it it will remain the same. I imagine the use of LWPI in the texts is to insure comparability with BASIC ET AL. You don't want to trounce any registers if you are going to return. Long story short.... You don't have to provided your code is stand alone and won't booger up a callers register space.

 

It sounds like it's not truly needed then unless the GPL console routines are needed, but probably recommended as good programming practice. Well at least now I know! Thanks

[+InsaneMultitasker]

It sounds like it's not truly needed then unless the GPL console routines are needed, but probably recommended as good programming practice. Well at least now I know! Thanks

The register set is defined by the loader or caller (presumably.) If you do not change it it will remain the same. I imagine the use of LWPI in the texts is to insure comparability with BASIC ET AL. You don't want to trounce any registers if you are going to return. Long story short.... You don't have to provided your code is stand alone and won't booger up a callers register space.

Often you don't know what the loader used as its workspace. This is when setting your workspace and turning off interrupts (if desired) at the start of your program is often most valuable - to give you a known starting point.

[RXB]

It depends. If you don't care about coexisting with an environment like XB or returning to the E/A menus, then setting the workspace to point to 16-bit scratchpad is critical, IMO. I like >8300 personally. But, the WP (workspace pointer) in the 9900 will always be set to some address that is RAM, otherwise the CPU won't get very far in executing a program.

 

I have also seen some assembly books recommend the bad practice of reserving 32 bytes for your workspace with BSS, then setting the WP to that address. The problem with this is that the reserved memory, on the 99/4A, will be in 8-bit RAM and will be very slow for register access.

 

You always want your workspace to be in the fast 16-bit RAM, and the best way to make sure is to set it yourself.

 

So how much speed do you give up?

[+mizapf]

I have also seen some assembly books recommend the bad practice of reserving 32 bytes for your workspace with BSS, then setting the WP to that address. The problem with this is that the reserved memory, on the 99/4A, will be in 8-bit RAM and will be very slow for register access.

 

Not really bad practice, but rather a way to get a modular software design. This way you can write code modules to be linked together, each one with its own workspace, without bothering about which memory location to use, so you can later call it with BLWP. You're certainly right that this means a significant slowdown if you do not use the console-internal 16 bit mod.

[senior_falcon]

Using the scratchpad RAM for your registers is always good practice. But a problem arises when you want to write subroutines that interface with XB and then return to it. XB uses pretty much all the scratch pad RAM so to use the scratchpad means storing the 32 bytes of the scratchpad in a buffer, then setting the workspace, running the routine, then restoring the contents of the scratchpad before returning. Depending on the length of the routine you have written, this process might take more time then the slowdown from using slow RAM for your registers.

As I recall, benchmark programs I tested back in the day ran in about 60% of the time using 16 bit memory as compared to running everything in the 8 bit memory. Having just the registers in fast memory vs. slow memory while leaving the program in slow memory let programs run in about 80% of the time. So there is a benefit, but it isn't the difference between a tortoise and a hare.

[+InsaneMultitasker]

Using the scratchpad RAM for your registers is always good practice. But a problem arises when you want to write subroutines that interface with XB and then return to it. XB uses pretty much all the scratch pad RAM so to use the scratchpad means storing the 32 bytes of the scratchpad in a buffer, then setting the workspace, running the routine, then restoring the contents of the scratchpad before returning. Depending on the length of the routine you have written, this process might take more time then the slowdown from using slow RAM for your registers.

As I recall, benchmark programs I tested back in the day ran in about 60% of the time using 16 bit memory as compared to running everything in the 8 bit memory. Having just the registers in fast memory vs. slow memory while leaving the program in slow memory let programs run in about 80% of the time. So there is a benefit, but it isn't the difference between a tortoise and a hare.

Much of my BBS assembly code uses the GPL workspace though there are limitations. IIRC, I use only R0-R5, R11, and R12 with various variables located in the lower 8k. The only time I end up saving scratchpad (and VDP) is during file transfers, where I need space for DSR routines. To make space for file transfer buffer, I save 8K of VDP to disk before the file transfer and restore it from disk upon completion. I also use memory from A000 to about A200 for inter-program communication and settings, since XB doesn't stomp on that area when loading different programs.

[matthew180]

Not really bad practice, but rather a way to get a modular software design.

 

Not a bad practice for modularity at all, which is why I said "it depends" to answer Vorticon. It depends on what you are doing and if you need complete modularity and intend to use BLWP a lot (but BLWP itself is a slow instruction). If all the RAM in the 99/4A was 16-bit 0-wait-state like the scratchpad, then the BSS way of reserving your own workspace would a defacto methodology to use. But for software that you want to run as fast as possible, as a general rule put the workspace in scratchpad and avoid BLWP.

 

Having just the registers in fast memory vs. slow memory while leaving the program in slow memory let programs run in about 80% of the time. So there is a benefit, but it isn't the difference between a tortoise and a hare.

So how much speed do you give up?

 

There was some benchmarking that was done in this forum, but I can't remember when or who did it. 8-bit RAM access causes 4-wait-states per memory access, so add cycles to your counts accordingly. Again, it depends on what you are doing, and for something like games it can make a significant difference.

[sometimes99er]

As I recall, benchmark programs I tested back in the day ran in about 60% of the time using 16 bit memory as compared to running everything in the 8 bit memory. Having just the registers in fast memory vs. slow memory while leaving the program in slow memory let programs run in about 80% of the time. So there is a benefit, but it isn't the difference between a tortoise and a hare.

 

Fits nicely with an article in an early eighties computer magazine where Paul Urbanus estimated a 20 percent gain for Parsec moving the scroll to scratch-pad.

 

[+mizapf]

In my Fractals program which I wrote for the Geneve with its 9995, I designed some fixed point mathematics with 1 word integer and 3 word fraction part and managed to put the whole addition and multiplication routine into the 256 byte on-chip RAM, together with a workspace. Yes, THAT was a speed-up, you bet.

[RXB]

Fits nicely with an article in an early eighties computer magazine where Paul Urbanus estimated a 20 percent gain for Parsec moving the scroll to scratch-pad.

 

 

Well from XB CALL LINKs or RXB CALL EXECUTE a 20% speed increase would only be useful if it spends 80% of the time in the Assembly section.

But then why even use XB at all at that point?

 

(Not to mention the hassle of managing all the memory so you could pull this off without messing up XB when it returns.)

[+InsaneMultitasker]

Well from XB CALL LINKs or RXB CALL EXECUTE a 20% speed increase would only be useful if it spends 80% of the time in the Assembly section.

But then why even use XB at all at that point?

 

(Not to mention the hassle of managing all the memory so you could pull this off without messing up XB when it returns.)

Dial out to Richard Bell's BBS or telnet to heatwavebbs.com? XB and assembly. With many reasons to use both.