Re: A83: Wait...


Re: A83: Wait...

>Ian your program uses, WTF is ZASMLOAD?  I see it a lot, but
>I've never known what it does.  It must be custom for each program as well,
>right?  Perhaps that's why my interrupt program isn't working.  I just call
>it the standard way, and it isn't compressed or anything.

ok this is a complicated subject so prepare yourself. first and foremost
you must understand "SQUISH" and "ZASMLOAD"".


when you compile a program using tasm.exe and link it using 83lnk.exe it
produces an .83p file. this file contains z80 opcodes in hexadecimal.
that means that 1 opcode is made up of 2 characters (or bytes). ex:

"C9" is the z80 opcode for "ret". if you type this into your calculator
you are actually entering 2 bytes, the character 'C' and the character

on the other hand if you compile a program using tasm.exe and link it
using it produces a "squished" .83p file. ex:

"C9" is the z80 opcode for "ret". if you send a this squished program to
your calculator, instead of it being the 2 characters 'C' and '9' it is
the byte C9.

what does this mean to you? think of it like this... if you send a "non
squished" program to your to your calculator each byte takes up 2 bytes.
but if you send a "squished" program to your calculator each byte takes
up one byte. that means that "squished" data is exactly half the size of
it's "un squished" counterpart (this is of course excluding the size of
the program's symbol table entry).


there are 2 ways to "squish" a program. the first, and easiest way, is
to use devpac83.exe. to use devpac83 follow these steps:

1) get devpac83.exe from

2) unzip devpac83.exe into the same directory as tasm.

3) in this same directory create a new batch file named zasm.bat, and
copy this into it.

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

if you prefer a .asm extension for your source files, change the ".z80"
on line 2 to ".asm".

4) compile your programs by typing

zasm [progname]

where [progname] is the name of your source file minus the extension.
the output is a squished .83p file. this file must be sent to your
calculator using a link, it cannot be typed in.


the second way to squish a program is to use squish.83p. to use squish
follow these steps:

1) get squish.83p from

2) unzip squish anywhere you want.

3) after you compile your program, send it to your calculator.

4) send squish.83p to your calculator.

5) create a new program named anything you want and type this into it:


where [progname] is the name of your program.

6) run this program to squish your program.


now that you have your squished program on your calculator you can run
it. this is where zasmload comes in handy. to run your newly squished
program follow these steps:

1) create a new program with a name relevant to your program. a common
convention is to name this program whatever you want, and name the
squished program the same thing, but with a leading "Z". ex:


2) in this new program type


where [progname] is the name of your squished program

3) run this new program just like you would any other basic program


to have an even better understanding you should also know how zasmload
works. when you run a non squished program on the ti-83 you type
Send(9prgmSOMEPROG. when you hit enter the program is squished and
written to the location 9327h. the only difference between this and
using squish.83p is that every time you run SOMPROG it has to be
squished, unlike using squish.83p which is permanent. having your
program squished saves time and space.

every time you run a squished program using zasmload, zasmload has to be
squished and copied to 9327h. squishing zasmload is very quick though,
because is it such a small program. after zasmload is squished and
copied it looks up your program. it then copies your already squished
data to 9327h and executes it.


wow! i hope that gave you a good understanding of squished programs. now
that you understand squishing, i can explain to you what's wrong with
your interrupt program. don't worry though its ALMOST perfect.


the first problem isn't in your coding, its the fact that your program
isn't squished.

when your program is run it checks the state byte (pointed to by the
label "state") to see if the interrupt is currently installed. if this
byte is 1, that means it is already installed. if this byte is 0 that
means it is not installed. if the interrupt is installed it displays
"Status: Off." and uninstalls it. if the interrupt isn't installed it
displays "Status: On." and installs it.

after the interrupt is (un)installed, the new state has to be saved.
this is done by calling the subroutine "store_state". store_state looks
up your program (in this case "ZTRIG") in the symbol table and writes
the new state directly to the to it, modifying the actual program. a
problem arises if if the program is not squished, because un-squished
data is stored as 2 hex characters. if you try to write back to an
un-squished program, you will only write over the first hex char,
instead of the entire byte. but don't worry, this can easily be solved
by squishing your program


your second problem is that you are calling _puts from your interrupt
routine. one thing you must always remember is that your interrupt
routine cannot make any changes to the registers or memory. this pretty
much means that you cannot make any romcalls from your interrupt. in
your case, you called _vputs. besides all the subtle changes that _vputs
may make to certain locations in memory, you yourself changed penrow and
pencol. who knows what was loaded into those locations before your
interrupt was called, and when your interrupt routine returns that
change could cause unexpected effects (most likely lockup the
calculator). one other thing to remember is keep your interrupt routines
small and fast. if your interrupt routine takes more than a second to
execute the calculator may get bitchy and decide to lockup for no

you may wonder how the hell you are going to display the mode if you
can't use _puts. there only way is to access the lcd directly. my
suggestion would be to have 2 8x8 sprites, one a "D" for degrees and one
a "R" for radians. you can then draw these to the bottom left corner of
the screen (the least used part of the screen) by speaking directly to
the lcd controller. if that sounds too complicated give me a holler, and
i can help you out.


one last thing! i noticed that you built your program up from capture83,
which is really cool! i was kind of disappointed that i hadn't seen any
interrupt programs poping up. that was my whole reason for writing

Follow-Ups: References: