[A85] Re: Programming for the Ti85
[Prev][Next][Index][Thread]
[A85] Re: Programming for the Ti85
> Van: Patrick Davidson <pad@OCF.Berkeley.EDU>
>
> 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.
Off coarse...
> > 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:
The one I like to have. All other Ti's behave like this.
> This method is used in PhatOS, and also (to a limited extent) in Rigel.
Yes, I've also found out about PhatOS, is that shell used more often than
Rigel?
btw, Rigel is just also compatible with ZShell (and UsGard?), it copies
your program to a fixed point, AND it changes adresses.
> 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).
I knew that...
> 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,
What if you (well the compiler I'm developer of) uses a different
assembler, because of the linking/library capabilities?
> 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.
What if this assembler uses a slightly different syntax... Then I should
add the 'R_' myself, wich would basicaly mean that the assembler needs to
'add' these automaticly/virtually/'not-real' when something points into the
program itself. (And also use ".org 0" as default.
SRCWIZ also adds the ".org 0", isn't it?
> 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.
Some other shells provide a program á la 'makehead', which generates the
header/relocationtable before String85 generates the actual *.85s file...
And, here also, the map file generated by Z80ASM differs from TASM.
> 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
Would be really difficult to implement into a compiler...
> > 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.
But this relocation table (could also be just 0,0,0,$E6) doesn't need to be
at the end of program at all, I have seen.
> 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.
The only refence to some sort of header format was in the Rigel.zip file,
but it is that kind of foggy that I couldn't make sense of it. Now I have
reverse engeneered the headerformat, I slightly understand... (Still don't
know what it is about with the $E6 at the end of the reloc-table, that one
isn't even mentioned in the docs)
You mean I should dive into hexediting *.85s files?
Dissassembler v1.7 is smart enough to hide most of the stuff from the user,
that
'should never be seen' by the user :-(
> > 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
String85 is for WinDOwS... So no: Linux, Amiga, Unix, Solaris (the Z88DK
can run one of these 'giants'), Sparc, etc.
> (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.
Okay, the 'problem' is, from a binary you can't see "what it is", so it
would be nice if you can pump "as much as possible" data about shell into
the binaries. So you can see lateron what shell it compiled was for...
> 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.
I've fixed it for the Rigel shell in this way:
---------------
org $9293 ; Origin to Rigel programs
defb $00,$FC ; This is a Rigel program string
defb enddesc-description
;org $9296 ; Origin to Rigel programs
..description
DEFINE NEED_name
INCLUDE "zcc_opt.def" ; Get namestring from zcc_opt.def
UNDEFINE NEED_name
IF !DEFINED_NEED_name
defm "Z88DK Small C+ Program"
ENDIF
defb $0 ; Termination zero
..enddesc
defb fixup-$9296 ; A relative pointer to the fixup table.
im 1
[some inits + calling _main + return to shell]
..fixup
defb 0,0,0,$E6 ; Why $E6 (#230) ???
---------------
Changing this header to PhatOS (better; adding support for), I would only
need to change "org $9293" to "org $8E57", "defb $00,$FC" to "defb
$00,$50", remove the fixup-table(-pointer) and description-sizebyte, I
guess...
(I'll test a bit)
Henk Poley <><
Follow-Ups: