Assembly on the 99/4A

[Opry99er]

Bumping this thread... Jeez, we need this at the top, man! =)

[Opry99er]

Question... I've been messing with the ability to store two byte variables... If I am planning to use a word for storage, would the proper way to access them be through loading the word into a register and using SWPB to access the LSB? I know on the baby steps thread we talked about the ups and downs of using BYTE functions verus the 16 bit instructions, but I am trying to be as tight as I can.. To get into that practice anyway.

 

I would like to use the 16 bit instructions and still be stingy with space I guess.

[Opry99er]

R0LB looks good here too... Could it be used on any all purpose register?

[matthew180]

How you access the LSB or odd-address bytes depends on what you are doing. For registers I highly recommend you use some EQUates to set up your workspace and give you the addresses of the register's odd bytes:

 

WS1    EQU  >8300

R0LB   EQU  WS1+1
R1LB   EQU  WS1+3
R2LB   EQU  WS1+5
.
.
.
R15LB  EQU  WS1+31

START
      LIMI 0
      LWPI WS1
.
.
.
      MOVB R0,@R1LB      ; Move the MSB of R0 to the LSB of R1
      MOVB @R1LB,@R2LB   ; Move the LSB of R1 to the LSB of R2

 

The only think you need to remember is that the addresses RxLB point to BYTES, so you have to use the byte operations with those addresses. You can also set up LSB access to your 16-bit variables by making sure they are aligned and then using two BYTE directives, or you can use DATA and an EQUate:

 

      EVEN
P1X    BYTE >00      ; P1X MSB
P1X_LB BYTE >01      ; P1X LSB

P1Y    DATA >0001    ; 16-bit variable, will be word aligned
P1Y_LB EQU  P1Y+1    ; Address of P1Y LSB
.
.
.
      MOVB @P1X_LB,@R1LB   ; Move the LSB of P1X to the LSB of R1
      MOVB @P1Y_LB,R0      ; Move the LSB of P1Y to the MSB of R0

      INC  @P1X            ; Increment the 16-bit P1X variable
      INC  @P1Y            ; Increment the 16-bit P1X variable

 

Matthew

[Opry99er]

Thanks... I read your source from the other thread and it makes alot of sense. I suppose I was just looking for multiple ways to skin a cat. =)

 

I was actually wanting to store variables that are two types of "items" on a map. 16 red dots, 16 blue dots. When all are "collected" the word should read ">0F0F".

 

I realize there are other ways to do this, but I am experimenting with various ways to accomplish the same task... It's fun, really... =) Thanks for your help, Matthew.

Edited November 16, 2010 by Opry99er

[RXB]

Actually, Lottrup relies on the ROM routines as well, the architecture of the Mini-Memory system has them loaded into an area of the 4k ROM. What Matt's talking about is writing your own routines that do everything. The video routines are pretty simple to set up; KSCAN a bit more tricky if you want to not rely on the SCAN routine in the ROM; XMLLNK, DSRLNK and GPLLNK are all very nasty. (I've only done DSRLNK myself, using Travis Watford's version with some modifications.)

 

For my own programming, I still like using BLWP to access them because of the convenience of swapped registers. If I have something that is speed-critical then I just use the direct read/write ports in the base code. That way I get both the convenience and the speed when I need it.

 

Adamantyr

 

I tend to agree. The video routines will usually provide the most gain in performance and need very little work to setup. I am not sure it is worthwhile to spend a huge amount of time on the other ones except when they impact performance significantly, which is pretty rare for most programs. I have to admit though that the floating point routines included in the E/A cartridge are horribly slow, and I would have loved to replace them when I wrote Skychart (it takes about 15 minutes to calculate the sky configuration!), but I doubt I had (or even currently have) the skills to do it.

 

If you take a page from the Forth guys and use nothing but the math they use which is nothing but fractions that are accurate to 7 decimal places instead of Floating point you would get a 4 fold increase in speed.

Look under Scaled Integer Math vs Floating Point, Scaled math requires very little processor time compared to Floating Point.

http://home.iae.nl/users/mhx/sf5/sf5.html

 

Shows a hole bunch of math in Scaled Integer math that avoids using Floating point.. Most like in the Source code write

LI R1,(355/113) this is the factional equivilent to Pi

 

The assembler will put in the value of Pi into R1 and be totally accurate enough for Plotting in Bit mapped mode.

I found this one perfect for the TI:

http://books.google.com/books?id=kqW8Lrp7NRYC&pg=PA113&lpg=PA113&dq=scaled+integer+math+examples&source=bl&ots=MKWYOkHWLw&sig=B82HVVFWZG9Op8xR5I9vbdqXqFM&hl=en&ei=MfWLTajjGIXWtQP2wYyWCQ&sa=X&oi=book_result&ct=result&resnum=7&ved=0CDYQ6AEwBjg8#v=onepage&q&f=false

 

It is by Jack W. Crenshaw, just beats the heck out of Floating point.

[+retroclouds]

The assembler will put in the value of Pi into R1 and be totally accurate enough for Plotting in Bit mapped mode.

I found this one perfect for the TI:

http://books.google....epage&q&f=false

 

It is by Jack W. Crenshaw, just beats the heck out of Floating point.

 

Thanks for the pointer. I never used Google books until now.

It seems some chapters are missing. Anyone know if there's a specific reason for that ?

I browsed some more books and they also have some chapters missing.

[RXB]

The assembler will put in the value of Pi into R1 and be totally accurate enough for Plotting in Bit mapped mode.

I found this one perfect for the TI:

http://books.google....epage&q&f=false

 

It is by Jack W. Crenshaw, just beats the heck out of Floating point.

 

Thanks for the pointer. I never used Google books until now.

It seems some chapters are missing. Anyone know if there's a specific reason for that ?

I browsed some more books and they also have some chapters missing.

 

Yea copyrights, they have to exclude the real book to make you buy the real one, but once you know the book you want you can find a copy online somewhere most of the time.

[sometimes99er]

Most like in the Source code write

LI R1,(355/113) this is the factional equivilent to Pi

 

The assembler will put in the value of Pi into R1 and be totally accurate enough for Plotting in Bit mapped mode.

About the "totally accurate" bit, I guess it always depends on what you're doing.

 

I don't want to read ~books~ about this ( haven't got the time right now ), but just tested if I could do the above, more or less, just like that ...

 

In Asm994a (part of Win994a) the instruction

 

LI R1,(355/113)

returns Error #1: Line #28: Undefined symbol: (355

 

LI R1,355/113

compiles fine, and Classic99 Debugger shows this disassembly

 

> 601E  0201  li   R1,>0003              
       0003

much as I suspected.

 

[RXB]

Most like in the Source code write

LI R1,(355/113) this is the factional equivilent to Pi

 

The assembler will put in the value of Pi into R1 and be totally accurate enough for Plotting in Bit mapped mode.

About the "totally accurate" bit, I guess it always depends on what you're doing.

 

I don't want to read ~books~ about this ( haven't got the time right now ), but just tested if I could do the above, more or less, just like that ...

 

In Asm994a (part of Win994a) the instruction

 

LI R1,(355/113)

returns Error #1: Line #28: Undefined symbol: (355

 

LI R1,355/113

compiles fine, and Classic99 Debugger shows this disassembly

 

> 601E  0201  li   R1,>0003              
       0003

much as I suspected.

 

 

I was using Forth for some time and have to admit that Assembly is crap for helping you porgram compared to the Forth compiler. In GPL I ussually use look up tables as that speeds things up.

You would think using Binary in Assembly most of the time or HEX then Integer math would be something included. Stuffing Floating point into Assembly is like having rocket shoes, but that space shuttle tank on your back also.

[Tursi]

Assembly is all integer based, that's why.

 

If you want the assembler to give you fixed point values, then just apply the shift yourself. For instance, if you want that divide to give you an 8.8 fixed point, you can try 355*256/115

[sometimes99er]

If you want the assembler to give you fixed point values, then just apply the shift yourself. For instance, if you want that divide to give you an 8.8 fixed point, you can try 355*256/115

Thanks. Think I did exactly that for a demo back in 2006. Guess you could say that the ISR sprite control system use 8.8 fixed point IIRC. - Did not use the ISR for the demo.

 

 

Edited March 25, 2011 by sometimes99er

[+hloberg]

I totally liked Matthews tutorial on his way to learn and speed up assembly. So I created a .pdf of all the post to make for easier reading. I did some very,very minor cleaning up and added some of the side information into the document.

thanks for the great tutorial Matthew.

here's the .pdf if anyone else would like to use it.

Advanced high speed game assembly programming.pdf

Edited November 28, 2011 by hloberg

[sometimes99er]

Very nice.

[idflyfish]

Yes..nice job on compiling this info. I really think the resources we have in this forum in the form of people are much more valuable than books.

[matthew180]

Thanks hloberg, much appreciated!

 

If anyone wants a tutorial or explanation about something, just ask. Personally I do better with specific requests, and the thread was primarily driven by Owen's questions, as well as a few others here and there. I think I try to give too much information sometimes, and I've been thinking about a few tutorials that are more focused on getting things done, rather than all the detailed background (which you pick up more slowly over time.)

 

[+hloberg]

Thanks hloberg, much appreciated!

 

If anyone wants a tutorial or explanation about something, just ask. Personally I do better with specific requests, and the thread was primarily driven by Owen's questions, as well as a few others here and there. I think I try to give too much information sometimes, and I've been thinking about a few tutorials that are more focused on getting things done, rather than all the detailed background (which you pick up more slowly over time.)

 

How about your thoughts on when and if GPL or GROM reads are ever needed in Assembler.

[matthew180]

Personally I'm not a big fan of GPL. It is slow, and like many things TI did back in the day, they didn't make information about GPL available. Like the GROM, GPL is just another attempt to control software for the 99/4A. I suppose GPL has its place, and there are some people on the forum who enjoy GPL very much, it is just not my "thing". But hey, to each their own. I like assembly and working directly with the hardware, and I tend to resist any layers between my code and the metal.

 

As for GROM, I dislike them all together, and the only thing you can do with them is store GPL byte-code or maybe sound / graphic data. Since they were never standard or made generally available, there is no way to burn your own GROMs like you can burn an EPROM, so you have to use extra hardware (or software emulation these days) to roll your own.

 

I'm not sure when (or why) you would want to use GROM from assembly, other than to maybe execute some system GPL routine. Again, something I never had much of an interest in, so I never used GLP from assembly. I like to reinvent the wheel because I like to know how the wheel works, so anything in GLP that I might have needed I would have written myself in assembly.

Edited November 29, 2011 by matthew180

[+hloberg]

As we say here in the south; there ya go.

Thanks for the insight. I was leaning in your direction on avoiding GROM calls (unless necessary) anyway.

After I finish my current XB project I'm going to start re-learning TI99 assembler.

I have a few projects in mind that I was toying with writing in C99 (I know C) but have decided to go straight to assembler as that's where I'm going to eventually end up anyway. I can always go back to C99 later if need be.

[Willsy]

You'll want to lean on GPL if you ever need to do any floating-point math such as square roots, SINs, COSs, TANs etc - those are all encoded in the GROM within the console.

 

Other routines, such as floating-point add, multiply, subtract, divide are in ROM (not GROM) and can be called with XMLLNK (a little machine code utility which accesses ROM routines via a look-up table of addresses).

 

Other than that, I guess I would use GROM itself only for storage of data. It could have uses in a multi-banked cartridge environment where you want access to a large amount of data (graphics and speech) but either;

• Don't want to use ROM space
  
• Don't want to page data pages in/out of ROM space
  

Then it's useful, for sure.

 

The issue, for us cartridge freaks, is that there is (currently) no hardware that can allow us to leverage GROM storage. But I understand that a project is under way to address that. I'll leave it to the project participants however to comment on that, as I haven't heard much about it in a while.

[RXB]

Personally I'm not a big fan of GPL. It is slow, and like many things TI did back in the day, they didn't make information about GPL available. Like the GROM, GPL is just another attempt to control software for the 99/4A. I suppose GPL has its place, and there are some people on the forum who enjoy GPL very much, it is just not my "thing". But hey, to each their own. I like assembly and working directly with the hardware, and I tend to resist any layers between my code and the metal.

 

As for GROM, I dislike them all together, and the only thing you can do with them is store GPL byte-code or maybe sound / graphic data. Since they were never standard or made generally available, there is no way to burn your own GROMs like you can burn an EPROM, so you have to use extra hardware (or software emulation these days) to roll your own.

 

I'm not sure when (or why) you would want to use GROM from assembly, other than to maybe execute some system GPL routine. Again, something I never had much of an interest in, so I never used GLP from assembly. I like to reinvent the wheel because I like to know how the wheel works, so anything in GLP that I might have needed I would have written myself in assembly.

 

Oddly one of the best examples of GPL and Assembly is RXB and the AMS together. As GPL can set up, control and use the AMS with GPL or Assembly from XB.

That is the main bug in Assembly you only have one place to load and run the AMS from and that is the Cartridge space. So you could imbed 39K of Assembly into GROM and run the AMS.

Like write a entire Assembly 32K program and put it into GROM. That is one heck of alot faster then having to load of disk or hard drive. GROM and GPL has it's uses.

 

You may not like it but it is much faster then disk as it just moves from one kind of memory to another with no buffers to use.

[RXB]

You'll want to lean on GPL if you ever need to do any floating-point math such as square roots, SINs, COSs, TANs etc - those are all encoded in the GROM within the console.

 

Other routines, such as floating-point add, multiply, subtract, divide are in ROM (not GROM) and can be called with XMLLNK (a little machine code utility which accesses ROM routines via a look-up table of addresses).

 

Other than that, I guess I would use GROM itself only for storage of data. It could have uses in a multi-banked cartridge environment where you want access to a large amount of data (graphics and speech) but either;

• Don't want to use ROM space
  
• Don't want to page data pages in/out of ROM space
  

Then it's useful, for sure.

 

The issue, for us cartridge freaks, is that there is (currently) no hardware that can allow us to leverage GROM storage. But I understand that a project is under way to address that. I'll leave it to the project participants however to comment on that, as I haven't heard much about it in a while.

 

 

No devices? PGRAM, GRANDRAM, GRAMULATOR, GRAMKRACKER, HSGPL CARD, and GRAMCART. I might have missed some others, but no one can say that this has not been addressed since 1983 many times.

[Willsy]

Indeed. Sorry, I should have been more clear! I meant in terms of distributing cartridges with GROM data inside them. For example, TurboForth is a 16K ROM application. It would have been nice to have GROM in there too, but it's just not possible yet from a technical standpoint; the cartridge PCB with the GROM/GRAM emulation doesn't exist yet.

 

WHT had a board years ago, but it was apparently never finished.

[RXB]

Indeed. Sorry, I should have been more clear! I meant in terms of distributing cartridges with GROM data inside them. For example, TurboForth is a 16K ROM application. It would have been nice to have GROM in there too, but it's just not possible yet from a technical standpoint; the cartridge PCB with the GROM/GRAM emulation doesn't exist yet.

 

WHT had a board years ago, but it was apparently never finished.

 

OPA had the POP cart design and Competition Computer put out a version with multiple carts inside.

In Micropendium they had aticles on how to make a cartridge with ROM/GROM using EPROMs. These were not emulators.

With TurboForth you could include 40K of subroutines in a library and use it on demand, or even use the entire 640Kof GROM space by using 40K per page.

[Willsy]

Do you have the issue numbers for the Micropendium articles? I'd like to have a read of those articles...