Baby Steps

[matthew180]

Pretty cool how small the object code is. =) I wonder if there's anyone who can read this and tell what it does... without seeing source. =)

 

Yes. Well, kind of. When I was working on my assembler I could read the object code pretty well. In the "blob" format it is a bit of a pain in the ass, but if you make it a list, i.e. one instruction per line, it is somewhat easier.

 

Matthew

[jchase1970]

Thanks sometimes!! Question...

 

Screen boundaries... Should I place a different character value around the edge and check for that particular ASCII value? Kind of a GCHAR sort of thing... Its all I can think to do for the right and left sides of the screen--- top and bottom wouldn't be so difficult... But I think this method might be the most efficient (the method of putting a different ASCII on the edges)

 

top, you put a compare to see if the location is less then 0 if it is add 32 back to it.

bottom, you put a compare to see if the address is higher then 768, if it is sub 32 from it.

 

left and right wont overflow it will just screen jump to the opposite side of the screen but 1 row up/down.

to have top/bottom screen jump do something like for top overflow if>0 then add 768 to it, bottom overflow would be -768 of course.

 

to stop it left and right at the screen edge, I would calculate the x screen location and do a compare against 0 or 32 before allowing the move.

[matthew180]

 

3. Personally I'm opposed to the VSBW and company routines, but using them now can help make your code *look* smaller. Just keep in mind that at some point you will need to learn what they do and replace them. Also, remember they *drastically* slow down your program.

 

4. Comment you code. Typically most people comment every line in assembly. I find this a *little* helpful sometimes, but what is more useful is a block comment that describes what the following code does. Use comments of individual instructions to explain why you are using a certain value or memory address.

 

 

I keep hearing about how slow the internal VDP routines are, but quite honestly they fit the bill for the vast majority of the time for most projects. I suggest you stick with them until you hit an unacceptable performance point. Test your program with them, and if you are happy then everything is cool. Otherwise, replace them (not too hard to do). I know the purists here are probably pulling their hair out by now and clamoring for my lynching, but I am a simple guy that does not need to complicate his life unnecessarily

 

Have you *seen* the internal routines?? They were written to save space only. My biggest problems with them are:

 

1. They are slow, slow, and slower.

2. They use an 8-bit workspace.

3. Not only do they require a slow BLWP, but internally each one uses at least one BL as well.

4. They REQUIRE the XB or E/A cart, which means you can't use them if you are making your own cart.

5. There is no Single-Byte-Multiple-Write.

6. Because of #5, the VDP's auto-increment addressing is ignored when doing block initialization (like clearing the screen.)

 

Also, the routines don't make the code any smaller at runtime, they still have to be in RAM (copied there by CALL INIT or the E/A cart.) I'm not suggesting people quit using routines for doing the VDP stuff, just write your own routines (or use mine or someone else's). They are not that hard, and you can even modify them to use BLWP if you really want to (but that is hardly necessary since they only mess with / destroy R0, R1, and R2).

 

Of all the VDP stuff to "understand", writing data to it is not really that big of a deal. Also, using the built-in routines can easily confuse people (like it did me for years and years), or make them think it is hard or taboo to do such a thing yourself directly. Direct hardware access to the machine is one of the main reasons we are even using assembly to being with.

 

Granted, assembly is usually so fast that you don't need to worry, however a good size game can easily require such speed ups. FlyGuy II was starting to push the speed limit of the machine, and I had not even added sound yet!

 

Matthew

[jchase1970]

I like the way Matthew tracks the x,y and converts it to a address, better then the way I suggested.

[+adamantyr]

For border checking, a 2-coordinate system is best.

 

I've tried out the idea of a single index value tracking on a 2-axis data set... it's possible to do, but not really worth the effort because of the math involved.

 

Adamantyr

[Opry99er]

Cool--- I will try to implement something tonight. Still not 100% sure how yet... I'm assuming the only thing I need to do to initialize a variable is place a value after a label and update it with INC, DEC, and the like. It's just a value at the address symbolically called "P1X" right?

[matthew180]

Yes, but remember, INC and DEC operate on WORDS (16-bit) values only! If you have this:

 

P1X    BYTE 16
P1Y    BYTE 12
.
.
.
      INC  @P1X     ; Increments the 16-bit value at P1X
      INC  @P1Y     ; Increments the 16-bit value at P1X, again

 

In this case you would end up incrementing the Y value twice. The INC would not affect the MSB until the LSB got to a value where the LSB was greater than 255.

 

So, you have a tradeoff. You can set up your variables always as 16-bit values so you can use the convenient instructions like INC and DEC on them, but waste a byte for each variable. Or you can use BYTE when your variable will fit in a byte, but have to do some shuffling here and there to manipulate the data (i.e. there is no SB (subtract byte) so you have to add negative values, etc.) That's why I used AB (add byte) and also why I defined the numbers -1, 0, and 1, since there is no AI (add immediate) for bytes.

 

You must understand the difference between the 16-bit WORDS (defined with DATA) and the BYTE data. Also the instructions that operate on bytes vs. words. Last, how bytes form 16-bit words and why the MSB is always at an even address. All this has been covered in this form, either by me or others, so do a review if necessary, it is critical you understand. If you can't find the answers or are still confused about it, ask questions.

 

This very thing was probably my biggest confusion when I was learning, and I very *lucky* my code worked. When I look at code I wrote back in my first few years I cringe at how I lucked out with what I was doing.

 

Matthew

Edited November 15, 2010 by matthew180

[Opry99er]

Gotcha!! It makes sense that INC and DEC are 16 bit-only operations... My first inclination is to not care about the extra byte in the odd address--- but I'm a newbie. AB makes perfect sense... I need to be familiar with all the directives and operands and not get stuck using "comfortable" conventions. Thanks again Matthew. I'm going to go through your assembly thread all the way through before I type in any more code.

 

Also started looking through "The Art of Assembly" by Bruce Harrison. Brilliant stuff there as well.

[+adamantyr]

Gotcha!! It makes sense that INC and DEC are 16 bit-only operations... My first inclination is to not care about the extra byte in the odd address--- but I'm a newbie. AB makes perfect sense... I need to be familiar with all the directives and operands and not get stuck using "comfortable" conventions. Thanks again Matthew. I'm going to go through your assembly thread all the way through before I type in any more code.

 

For my own part, I stick with data words over bytes for variables unless I really REALLY need to save space. Trust me, it's easier. If you have a more-or-less static workspace, you can access either byte by using static addressing, use a shift to move it into position, or a swap. (The first is probably best in most situations.)

 

Also started looking through "The Art of Assembly" by Bruce Harrison. Brilliant stuff there as well.

 

Yes, VERY good articles. A great starting point is his "This is a Football" article, which is where he steps back and tries to explain assembly to the average lay-man.

 

Adamantyr

[matthew180]

Yeah, AoA is a good piece of work (RIP Bruce Harrison.)

 

All the byte instructions end in 'B', so it is easy to know when you are using one. There are also not very many of them. Let me see, I can probably remember them all without looking: AB, CB, MOVB, SOCB, SWPB.

 

Bytes really come more into play when you are dealing with text and data tables (like the VDP tables, map data, etc.) The space savings really depends on what you need to do with the variable or data. For example, when making a game and you only have 256 bytes of RAM, using 16 WORD size variables vs. 16 BYTE size variables is a difference of 6.25% of your available RAM!! So for a cartridge based game where you have a lot more room for code (which will be in the ROM) vs. variables, you need to be careful about your variable use. If you are going to stick with needing the 32K and a PEB, then you can probably just stick with word based variables (until you need to track values greater than 65535.. )

 

Matthew

[sometimes99er]

1. They are slow, slow, and slower.

2. They use an 8-bit workspace.

3. Not only do they require a slow BLWP, but internally each one uses at least one BL as well.

4. They REQUIRE the XB or E/A cart, which means you can't use them if you are making your own cart.

5. There is no Single-Byte-Multiple-Write.

6. Because of #5, the VDP's auto-increment addressing is ignored when doing block initialization (like clearing the screen.)

That's a very good run down. Off my head I didn't know it was all that bad. You can use them, but they are bad.

 

Granted, assembly is usually so fast that you don't need to worry, however a good size game can easily require such speed ups. FlyGuy II was starting to push the speed limit of the machine, and I had not even added sound yet!

From what I've seen of FlyGuy II, I have a hard time believing it's pushing anything - and we are of course talking main game loop, not some maze rendering taking more than one or two frames !?

 

[matthew180]

Okay, let me quantify "pushing the machine" in FlyGuy II. When I started writing it, I was limiting the movement to keep it at "human speed". As I added more code, features, etc., my speed limitations got less and less, to the point now where I can not make the players movement any "faster" while still moving one tile at a time.

 

I also realize that I need to do some restructuring, but that code was very much a hack and I was testing a lot of ideas.

 

My point being, everything about the 99/4A is limited, so when speed matters (as it *always* does in games), it makes sense to replace the stock VDP routines which were designed for the single purpose of saving bytes.

 

Matthew

[sometimes99er]

Okay, I understand. Thanks.

[Opry99er]

X,Y coordinate system working great!!! What a cool and easy way to set boundaries!

[acme]

Hello guys,

sorry for bumping this old thread, but this thread's topic ('baby steps' ) seems the best place for my question. I've been reading this forum now for days and am very very impressed! I'm trying to write TMS9900 assembler, but never done this before. Ralf (FinalGROM99) pointed me to this place here. Thanks a lot - it's a gold mine with an impressive Guru concentration. ** OMG - I'm not worthy **

Few minutes ago I finally managed to run my first assembly program
It's being started from the XB2.7 Suite -> Writer/Assembler and does nothing meaningful and is still a bit buggy.
I just wanted to check the speed of the TMS9918A by throwing chars into its memory - Awesome!

But here's my question: How can I link my object file now in order to get an executable - so I can start it from a disk via a load command?

Here's the code:

DEF  START
* VDP Memory Map
*
VDPRD  EQU  >8800
VDPSTA EQU  >8802
VDPWD  EQU  >8C00
VDPWA  EQU  >8C02
 
* Workspace
WRKSP  EQU  >8300
R0LB   EQU  WRKSP+1
 
* Program execution starts here
START  LIMI 0
       LWPI WRKSP
 
RSTR   CLR  R4
       LI   R4,>0020
       LI   R1,>4000
 
LOOP   LI   R2,768
       CLR  R0
       MOVB @R0LB,@VDPWA
       ORI  R0,>4000
       MOVB R0,@VDPWA
       SWPB R4
       AB   R4,R1
       SWPB R4
CLS    MOVB R1,@VDPWD
       DEC  R2
       JNE  CLS
       DEC  R4
       JNE  LOOP
       LIMI 2
       JMP  RSTR
 
       END

In general I would also like to know, what the best "IDE" would be for developing in assembly language?

I would really appreciate any help. Thanks a lot!

 

[EDIT] I'm using Classic99 and waiting for my nanoPEB to arrive

 

Regards

 

Andreas

Edited January 22, 2017 by acme

[+Lee Stewart]

Welcome aboard, Andreas! Pretty much no such thing as a necro thread on this forum.

 

In answer to your first question, the object file output from the assembly of your source code is executable by the Editor/Assembler (E/A) cartridge as well as the Writer/Assembler option of the XB2.7 Suite cartridge you have already used in emulation. I presume you LOADed it with Option 4 (LOAD AND RUN) of Writer/Assembler, which is Option 3 of the E/A cartridge.

 

If you also put START in the operand field of the END statement, your program will autostart after you select the “LOAD AND RUN” option.

 

Re the best IDE, I use Classic99 to test my programs before running them on real iron. I use Notepad++ as my editor. There is a user plugin in the Development thread (scroll down to “Editors”) for syntax-highlighting your code. I use Cory Burr's Asm994a v3.010 to assemble my code. It is part of Cory's Win994a simulator package. Unfortunately, Cory is no longer supporting the package. I say, “unfortunately,” because there are a few minor bugs in the Assembler that would be nice to be rid of, but I have used it to successfully build a 32KiB cartridge for my fbForth 2.0. There are other packages you can use, as well. A very nice one by Ralph Benzinger is discussed in xdt99: New TI 99 cross-development tools available. It has the advantage of current support. I have not got around to using it yet, but I intend to do so soon. Several folks on this forum are using it.

 

Hope this helps a little.

 

...lee

[acme]

...

Hope this helps a little.

Lee, thank You very much for your reply. I have to admit, my posting here has been a little premature. I did some more reading and also followed the links You've posted.

Your answers were perfect, at least You've tried hard, because my questions arose from my still almost infinite ignorance regarding the basics of the TI-99/4A design, so You couldn't done it any better. Sorry for that.

A bit of an eye-opener was this page here: Link

My respect is now even bigger regarding the restrictions you all have to overcome by dealing with this 'interesting' - well - peculiar hardware design.

I'll do some more research and reading before I'm going to post here again. So you guys don't have to guess, what I might want to know

 

Thanks again

 

Regards and see You

 

Andreas

Edited January 24, 2017 by acme

[Asmusr]

In general I would also like to know, what the best "IDE" would be for developing in assembly language?

 

In my opinion the best IDE is IntelliJ IDEA with the plugin from the xdt99 tools.