Hello, faithful readers. The first thing I would like to do is appoligise for my previous Log. All the <pre> commands must have messed up somewhere, and so the sprite drawings came out all screwy. This volume will cover many things, the first of which being correcting a few things from my first Log. Also, I'll try to explain the commands I missed, and tell you how to write in small text and inverted text. Here goes nothing...

To begin, in my first Log, I told you how to manually edit the OBJ file and convert it into an 83P file. Well, since my readers have bugged me about programs like 83LNK.EXE, I decided to tell you how to use one of these programs. 83LNK is probibly the easiest to use if you are just creating programs that don't run under a SHELL, or don't require SQUISHing. This program (83LNK.EXE) can be found at TiCalc.org. To use it, first you must take the batch file (.BAT) I told you to make in the first Log... The one that looks like this:

tasm -t80 -i -o20 -p60 %1

...and change it so it looks like this:

tasm -t80 -i -o20 -p60 %1.z80
83lnk %1.obj %1.83p %1

Now you have to put the program 83LNK.EXE into the drive and directory ("Folder" for you who are DOS illiterate). Save the .Z80 file you want to assemble in the same directory, and run the batch file (I believe I told you to call it ASM.BAT) with this line:

asm.bat filename

Replace 'filename' with whatever the name of the .Z80 program is, and you are on your way. Remember, do not put in the extention '.Z80'. This will cause an error, and I will explain why. The '%1' in the batch file means the first word typed after the batch file's name will be placed here. '%2' means the second word, '%3' the third, and so on. So if the .Z80 program you wanted to assemble was called TEST.Z80, the command for the batch file would look like this:

asm.bat TEST

And the batch file would execute these commands:

tasm -t80 -i -o20 -p60 TEST.z80
83lnk TEST.obj TEST.83p TEST

83LNK.EXE will automatically make the .83P file and name it whatever you put for '%1'. So, this means if you put TEST in lower case, the program will be named in lower case, and you wouldn't be able to execute it or edit it. That would be a bummer, wouldn't it?

Now, another program that you could use is called DEVPAC83.COM. This program comes with ASHELL83.ZIP if you get it off of TiCalc.org, and is used mainly for programs intended to run with a SHELL. DEVPAC83.COM automatically SQUISHes your programs, so inorder to run them, you will need either ASHELL83, SOS, or ZASMLOAD. If you get DEVPAC83.COM from the ASHELL83.ZIP file, it will already have a batch file with it. Incase you didn't get DEVPAC83.COM from ASHELL83.ZIP, or you lost the batch file that came with it, here's what it looks like:

@echo off
tasm -t80 -b -i %1.z80 %1.bin
if errorlevel 1 goto ERR
devpac83 %1
echo.
del %1.lst
del %1.bin
goto XIT
:ERR
echo.
echo Hey, something is wrong here!
echo.
:XIT

This does the same thing that 83LNK.EXE does, only it SQUISHes the program (as mentioned before) and it also has the added feature of cleaning up all the messy residue from the assembling process. DEVPAC83.COM works with a binary form of the object code, so a .OBJ file is never created. The .LST and .BIN files are deleted via commands from the batch file. This batch file, allong with DEVPAC83.COM should be in the same directory as TASM301.EXE and the .Z80 program that you wish to assemble.

This can also be concidered a correction from the first Log. If you want to display text in the variable width (graph screen) font, you would CALL the routine '_vputs' instead of '_puts'. Also, you would store the possition that you would like to display the string into (pencol) and (penrow). So, if I wanted to display the exact same thing as in volume 1, The commands (starting after the header) would look like this:

	call _clrLCDFull

	ld a,5

	ld (penrow),a

	ld a,6

	ld (pencol),a

	ld hl,STRING_ONE

	call _vputs

	call _grbufcpy_v

	ret

STRING_ONE:

	.db "Hi there!",0

.end

end

The command 'CALL _grbufcpy_v' copies the graph buffer to the home screen. The routine '_vputs' writes to the graph buffer, so in order to see what you write with it, the command 'CALL _grbufcpy_v' needs to be in there. There is also an easier way to select the position using the '(pencol)' variable and some crafty mathmatics. It is known that the TI-83 can only understand 256 columns of pixels. Everything after that is considered the next row of pixels. So, if you put 256 into '(pencol)', you will be at column 1, row 2 (or column 0, row 1, whatever you consider it). So, if you want to be at row 5, column 6, you would enter 5*256+6 (row# * 256 + column#) into '(pencol)'. But, seeing as 'a' can only hold up to 255, you need to store it to 'hl', and then copy 'hl' to '(pencol)', like so:

ld hl,5*256+6

ld (pencol),hl

That should save you some programming space.

Now, let's say you just happened to look at someone else's program and you wondered "Just how do they get their text inversed like that?" By inversed, I mean white text on black background. Well, here's how you do it. The TI-83 has a series of 'flags' that can be set to perform certian functions. There is a 'flag' called 'textinverse' which performs the function of displaying inversed text. This inversed text can either be the normal font, or the variable width font used on the graph buffer. to set these 'flags', you use the 'set' command. As you might have guessed, 'res' resets the 'flags'. The 'flag' 'textinverse' is under the (iy+textflags) series of 'flags' (don't ask me what the iy+ is for, 'cause I have no idea), so to set the 'flag', you would use this command before you CALL the routine '_puts' (or '_vputs'):

	set textinvers, (iy+textflags)

To reset the 'flag', just use this command after the 'CALL _puts (or _vputs)' command:

	res rextinvers, (iy+textflags)

That covers just about everything I missed (and felt like covering) from the first Log, and even from the next two.

Here's a few commands that I have reciently looked up and decided to tell you about. The commands in question are 'and', 'or', and 'xor'. These commands have to do completely with numbers, and, to be more specific, binary numbers. There is no real use for these commands if you are just making a simple game or program, but if you are making SHELLs and SPRITE-based graphics, these come in handy. I won't tell you exactally what to do with these commands to make a SHELL or whatever, but I will tell you what they do.

First is 'and'. This command, like the others, is used almost exclusively with binary numbers. any binarynumber has a 'b' after it, like so:

11001001b

All of these commands ('and', 'or', and 'xor') are used with the register 'a'. Let's say you put a binary number like 11001001b into 'hl', like so:

	ld a,11001001b

Now, if you do the command 'and 10101001b' afterword, the only bits left in the binary byte would be the bits in both 11001001 and 10101001, so the number left in 'a' would be 10001001. If ya' didn't quite get why, I'll explain... the first bit in both bytes is 1, so the output bit is 1 (both the first byte AND the second byte contain 1 as the first bit). The thrid bit in one of the bytes is 1, but in the other byte it's 0, so the output is 0.

The 'or' command works similerly, but instead of both bytes requiering a 1 in the same bit register, only one does. So:

	ld a,11001001b

	or 10101001b

The output in 'a' would be 11101001b.

The 'xor' command is like 'or', only it's eXclusive. Either one of the bits can be 1, the other can be 1, but NOT both in order to output 1. So:

	ld a,11001001b

	xor 10101001b

The output in 'a' would be 01100000b.

I hope you learned something from this long and drawn-out Log. I hope to make more concerning the usages of 'program detection'. Keep an eye out for it. Special thanks goes out to Lindsay Kosmala and Sarah Eisele for keeping me alive this long, Crysta Blondo, Angela Scavone, and Karen Robinson for keeping me sane for as long as I have been, and Ken, for driving me home.

ICQ: 1385910

Thanks for your time, and I'll see you (hopefully) in volume 8! -Phil