Very good!

Very Nice :)

Wow, this looks very good. And it must have taken a lot of skill to creat this program, but what is a hex editor exactly used for anyway? Sure, you can use it to lie about a high score, but I don't see anything else.

-Expressing my lack of knowledge, I am W-

It can be used for billions of things. No kidding.

Like if you want to study ti's rpn format. A coupls of times I've been able to debug something before i got home by looking at some ram.



The one and only Cheerio:
-Samuel

Hi Greg thanks for the nice Christmas present, maybe I'll update Hail as well ;)

The documentation seems broken as what looks like it should be a link to the liscense page does not go anywhere?

Also why is the htoesi.jpg an AMS bug? I searched the folder but could not find any html that uses this picture. (Aside from it being horible asm code that uses a1 without need.)


The one and only Cheerio:
-Samuel

I'll try to fix that asap :) Its a leftover from the old documentation... there is no "license" anymore its just freeware unless someone feels like making donations ;)

as far as htoesi, its not an ams bug... i didn't intend to include that with the documentation either (along with the license bit)... it was part of what I told TI about your ti-basic bug... Here is part of what i wrote to them:

After a few key presses (using Crash Guard), it becomes very clear that the instruction move.w (a0),d0 caused the address error. This conclusion is backed up by the link port transmission which I logged with HyperTerminal and my gray graphlink cable. According to the error log, the register A0 contained the value 0xffffffff which is an odd number! Furthermore, we can also determine that we are viewing the disassembly for the rom call HToESI (this requires the presence of the romcall database). This suggests to me that the TI-BASIC interpreter passed a H_NULL or otherwise invalid HANDLE to HToESI. My final conclusion is that the crash is an accepted behavior of HToESI, and the bug probably lies within the code which called the HToESI rom call with an invalid handle.

Yah thanks for putting up with my constant nit-picking.

About the basic bug. That was my assuption a long time ago too. That somewhere a null handle was being dereferenced.



The one and only cheerio:
-Samuel

<waves hand over head>ZOOM!

Same here... I only know z80 ASM. I can't believe people think 68k is really easier.

How much effort have you put into 68k asm?

A big obstacle to learning asm is that registers = variables. but when there are more variables then registers a newbie often gives up. On the 68k calcs having 8 data registers and 7 address registers should be enough to cover 95% of the algorithms a newbie might think up.

The 68k instruction set is general purpose. I think that the instructions on the z80 that dec bc while incrimenting hl and de are more confusing (but not much so)

How about spilling registers to the stack if you run out of registers? Everyone wanting to program in assembly should better know how to do that...

Even *I've* learned how to store local variables on the stack. It's not that difficult, really.

Those "dec bc, inc hl, and inc de" instructions actually are pretty easy to use:

ldir

Copies bc bytes of data from (hl) to (de), going "forwards" in memory

lddr

Copies bc bytes of data from (hl) to (de), going "backwards" in memory

Not really much at all because there was always C, so I never had to learn 68k asm. On the other hand, for the TI-82, there were two options- BASIC or ASM, so I learned it because of that. The only thing that I found confusing when learning z80 was the concept of the flags and how certain instructions would affect certain flags, but that's clear now.

#define USE_TI89
#define USE_TI92PLUS
#define USE_V200
#define OPTIMIZE_ROM_CALLS
#define MIN_AMS 100
#define SET_FILE_IN_USE_BIT
#define SAVE_SCREEN
#include <tigcclib.h>
void _main (void)
{
printf ("Go Learn C");
printf ("It works on 68K");
printf ("Download TIGCC from ticalc.org");
ngetchx ();
}

DrawStr() is better. it is smaller, and it allows you to place anywhere on the screen. Not to mention, you can puy "/n" to start a new line.

-W-

If you are going to save the previous screen, then at least clear it.

I do know C. And BTW, what's with all the #define stuff at the beginning of your program!? You certainly don't need all of that. Plus, I don't like to use multiple printf() statements. \n is easier to use than a whole new line. Also, printf() takes up a sick amount of space in your programs.

Use TI-89, TI-92 Plus, and Voyage 200; optimize ROM calls, use AMS 1.00 or higher; preserve the screen contents; and prevent crashes by setting the system variables as "in use."

I was just trying to make a point! This is a garbage program! I know it!

the following basic code will result in an address error:

prgm
local x
fill 0,x
endprgm

In the above paragraph Greg gives specific details.

Well, that there is just bad programming anyway. If you are going to use the "fill" command, you have to first give x demsions, or it will continue to fill until it returns an error.

-W-

It makes just as much sense that if x is not a list or if x is a list with no dimensions then fill 0,x should do nothing.


The one and only Cheerio:
-Samuel S

Exactly, so why would anyone want to do it, and then get mad when they get an address error?

-W_

There could be a typo in your program? TI-BASIC is supposed to catch little errors like this, not give fatal errors like an address error.

Becasue tibasic should never fatally crash the calc.

also the origional program it was found in was more like

local x

//--20 lines of basic--

fill 0,x