A86: Re: Re: ASM Clear-Up
[Prev][Next][Index][Thread]
A86: Re: Re: ASM Clear-Up
I'm sorry.
-----Original Message-----
From: David Phillips <david@acz.org>
To: assembly-86@lists.ticalc.org <assembly-86@lists.ticalc.org>
Date: Friday, January 22, 1999 10:34 PM
Subject: 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/
>
>