A86: Re: ASM Clear-Up


[Prev][Next][Index][Thread]

A86: Re: ASM Clear-Up




Please don't send HTML mail messages!

----- Original Message -----
From: Chris Flanigan
To: 86 Assembly
Sent: Friday, January 22, 1999 5:46 PM
Subject: A86: ASM Clear-Up


>Many of you advanced ASM programmers may think I'm ignorant, and I am, to
the ASM >language. I'm unclear on bit rotation, incrementing and
decrementing.
 >
>If I have %00000000 and increment it, what do I have? Is it %00000001?
>
>If I have %00000000 and decrement it, what do I have? Is it %11111110?

Incrementing/decrementing of binary numbers is just like inc/dec of a normal
number.  Just think of it as adding or subtracting a decimal number, then
convert it to binary.  To the processor, all number types are the same.

For example, DEC %000 = %111.  It "rolls over" or "carries".  INC %000 =
%001.

>If I use my on-calc hex converter and I convert 10 to hex I get Ah. I
understand
>that A=10, B=11, C=12, D=13, E=14 and F=15. The $ takes place of the h
right? So >Ah really equals $10 right. But if I convert 16 to hex I get 10h.
How? Do binary >numbers come into play?  Some examples in a fair tutorial I
read were that 59=3bh >and thus equals $ff
 >

A '$' in front of a number tells the assembler that the number should be
treated as a hex number instead of a decimal number (remember, to the
calculator, all numbers are the same...they're just bytes when assembled).
This is the same as a '%' tells the assembler to treat it as a binary
number.  A 'h' at the end of a number also means treat it as hex.  A number
with no pre/postfixes is assumed to be decimal.

>Does anyone actually know the ASCII code for the TI calculators? I'm
familiar >with that of the PC because I've been programming in Q-BASIC for
around 3 years. >(I got bored.) For example, is A still 65, B 66, C 67. I
know the syntax is not >the same (in QB PRINT CHR$(ascii-code).

The calculator uses the same standard ASCII character set for characters
32-127.  All characters above/below that range are special.  The only
control character is 214 ($D6), which causes a colon (:) and a newline to be
printed.  All other characters are "printable" (for example, with _putc).

You can find a list (with pictures) of all the characters in the Assembly
Studio 86 help file.  I believe that viewing the TI-86 Font (get it from
TI's website or with the Graph Link software) in Character Map will show you
what they look like as well.

>This is the first coding I tried. I compile it with Assembly Studio 86. It
>compiled correctly but it didn't work correctly on the calc. It didn't
print the >text. I then compile it with make86p and it worked. Does anyone
know why?
 >
>#include "asm86.h"                        ; include file
>#include "ti86asm.inc"                    ; include file
>.org _asm_exec_ram                      ; .org $d748 (in ti886asm.inc)
>call_clrLCD                                   ; calls the clrLCD ?rom?
function
>ld hl, $00                                     ; stores $00 in h, $00 in l
>ld (_curRow),hl                             ; stores 0 in _curRow, 0 in
_curCol
>ld hl,string                                   ; loads string into the HL
>register
>call_puts                                     ; puts "This is example
text." on >the screen
>ret                                             ; returns to TI-OS or a
shell
>string:                                        ; label for string
>.db "This is example text.",0            ; actual string text
>.end                                           ; end of program
>From what I understand of ASM this should work. But I don't know why it
doesn't. >This little bit of code is basically what is in Dux Gregis'
tutorial. I figured I >should give him a little credit for his time.
>

 The code looks correct to me.  It _should_ work correctly on the calc.
Btw, with Assembly Studio 86, asm86.h does not need to be included unless
you need the _getky equates.  The new ACZ included files have all known
ram/rom included with one file (ti86asm.inc).  No more remembering to
include ti86ops.inc or ti86abs.inc or whatever.  Get it at www.acz.org!

>What does the ',0' mean after the string text? I see it often but don't
actually >know the point.

The makes the string "null-terminated", meaning that there is a zero-byte at
the end (the 0 is actually a byte value of 0 and not the character '0',
which has a value [ascii] of 48).  _puts and _vputs print zero-terminated
strings.  In other words, they continue printing until they reach a
zero-byte.  If you forget the ",0", then they'll keep printing forever (or
at least you'll probably think so because you'll see pages of junk appear).

>I've been experimenting with the TI-BASIC Sprites and I sort of understand
the >concept but I don't quite get it. I guess with a little practice I
will. I wonder >why TI didn't include some sort of way (like the TI-85) to
find the correct pixel >that you need. I think the syntax is something like
call_nextpixel. (Mind you >that I'm not sure at all and I'm very new to ASM.
If it's wrong, ignore it.)
>

A routine called a "Find Pixel" routine is used to calculate the correct
offset and mask for a pixel (remember that video memory is formatted 8
pixels per byte).  A few hours ago I posted Dux's totally amazing 105
t-state _Fastest_ FindPixel routine.  It works like this:

   ld bc,$3020    ; find pixel at coords (48, 32)
   call FindPixel ; calc offset and mask
                  ; hl now points to the address of the pixel
                  ; a is now the "mask for the pixel, meaning
                  ; the bit for the pixel is set, all other
                  ; bits are clear

Now, to set a pixel (all examples follow the above code):

  or (hl)         ; set the bit by ORing the mask and the video byte
  ld (hl),a       ; write the byte back to video memory

Or to clear the pixel:
  cpl             ; invert the mask, so the pixel's bit is clear
                  ; and all other bits are set
  and (hl)        ; clear by ANDing the pixel's bit with a clear bit
                  ; which will clear it, since both won't be set
                  ; all other bits are set in the inverted mask, so
                  ; if the other bits in video memory are set, they
                  ; will stay set, and if they are clear, they will
                  ; stay clear, since that's what AND does ;-)
  ld (hl),a       ; z80 only does stuff with the accumulator...dumb z80

To invert the pixel:
  xor (hl)        ; flip the bit by XORing (eXclusive ORing) it
  ld (hl),a       ; again, if this was x86, hehe

Be sure to check both of the Sprite sections at 86 Central, along with the
Display section.

I hope this helps, I don't have time tonight to further explain.  For more
information, check out 86 Central and read ALL of the tutorials on asm
(http://ti86.acz.org/).  Later!

--
David Phillips <david@acz.org>
http://www.acz.org/