[A85] Re: Programming for the Ti85
[Prev][Next][Index][Thread]
[A85] Re: Programming for the Ti85
On Fri, 21 Sep 2001, Henk Poley wrote:
I suppose you already know a large portion of what I have written below,
but I'm including everything just to be sure.
> It seems like I didn't comprehend everything...
> Can someboy explain me how to program for Rigel? (or any other Ti85
> 'relocating shell')
There are two kinds of relocation on the TI-85:
1) Static: Simply copying the program to a constant address before running
it. This is the "standard" mechanism used on the other Z80-based
calculators. All this requires you to do (when writing assembly normally)
is put the right .org at the beginning of the program, and then absolute
references (things like "ld hl,stupid_message" and "call
display_stupid_message"). In this case, the assembler knows that your
.org is the beginning address of the program, and the address of
stupid_message and other labels in the program can be determine fairly
easily, so the right code can be generated to access them. This method is
used in PhatOS, and also (to a limited extent) in Rigel.
2) Dynamic: Adjusting absolute addresses when the program is run. This is
what is done in Usgard. There, you would have to (when programming for it
normally) use instructions like "ld hl,&stupid_message". The reason is
that Usgard doesn't move the program to a constant address, so it just
runs from whatever location in memory the string is in. Obviously, if the
program were assembled with a constant address that isn't changed, the
program would fail (unless you are very lucky in that it happens to be at
the place you guessed).
The use of & in Usgard is fairly simple for a normal assembly programmer,
as all you have to do is put an & in front of each absolute reference and
assembly it with the supplied batch file, and there is nothing more to
worry about (with a few exceptions). However, what is done internally is
a bit more confusing. First, a program called "SRCWIZ" is run which
converts the source code a little bit. Basically, it removes the &s and
puts lines starting with R_ in their place. Thus "ld hl,&stupid_message"
would become "R_1: ld hl,stupid_message". Alternatively, you could have
just put the R_ labels in the source code, then SRCWIZ would be unneeded.
After that, the program is assembled (more or less) as usual, but with an
option given to TASM to make it generate a list of labels. Then string85
is run to generate the actual file; it takes the regular assembled output
and puts that into the string, but also examines the list of labels for
labels beginning in R_, and creates a table of where they are that is
attached to the string as well. Then when the program is run, Usgard uses
this table to adjust the absolute references. That way, wherever the
program ends up in memory, all references to address in the program are
adjusted to the correct value.
In the case of Usgard, you would put .org 0 so the assembler generates
code as if the start address is 0. That way it is only necessary to add
the real start address to each place that needs to be relocated when the
program runs, and subtract it to restore the program to the original
condition.
Rigel allows you to use the copying relocation for normal programs, but
also allows Usgard-like relocation (this time using the @ symbol to about
the same thing as &). This is required for "TSR" programs as well as
libraries, which can't always be put at a constant address.
And don't forget:
3) The old-fashioned way, which is no "relocation" at all. Just use
ld hl,stupid_message
ld de,(PROGRAM_ADDR)
add hl,de
> Especialy about the @-things, since I use (a well, the Z88DK uses) Z80ASM,
> I can't get these things to work. How is the Rigel header built-up? And how
> are other Ti85 shell headers built-up?
The @ (or &) sign is not actually processed by the assembler at all, but
rather by some other program that is run first. In the case of Rigel,
this is its 'MAKEHEAD' program. You can run this manually to see exactly
what it outputs. In general, its output is an assembly source code
similar to the original, but with relocation labels added in a way similar
to Usgard. Also, it puts the data structure of both the internal and
library relocation tables at the end of that source file, referencing the
appropriate relocation lables it added before. It also deals with the
@title and other stuff, which isn't very complex. Since the relocation
table is created with MAKEHEAD, the assembler can just assemble it as
normal, and STRING85 can also run in the more or less normal way, with no
extra processing.
The 'headers' (if you mean strictly the stuff at the beginning) are always
rather simple. In general, they just have two bytes at that start of the
string to identify the type of program, and also an indicator of the
length of the title (maybe not for all of them). For most of the shells,
the format should be rather clear from a simple examination of the
program.
> I need to do it in way that nor string85 nor any header-making-program
> is used, it would be nice to handle all the Ti's with one program
> (Bin2Var). Strings created with Bin2Var do show up in the OS. And I've
> already managed to let the program-description show up under Rigel,
> yay! But I think it now crashes on the relocation stuff and the such
> (how can set it up so it doesn't relocate a thing?).
I don't see why using string85 is really that much worse than writing a
new program (or a new component of some other program) to do exactly the
same thing. But in general for the basic headers, it should be simple
nomatter what you do (as it seems you have already done). Adding 3 simple
bytes to the beginning can't be a much worse task than creating the entire
.85s (or .83p or whatever) with all the information the graph-link
software expects in that.
One easy way to do it without any relocation would be to write for PhatOS
instead of Rigel, since that doesn't use any dynamic relocation at all.
Alternatively, you could examine the output of running 'MAKEHEAD' on a
Rigel program with no relocations at all to see what it puts at the end.
References: