[A85] Re: Programming for the Ti85
[Prev][Next][Index][Thread]
[A85] Re: Programming for the Ti85
On Fri, 21 Sep 2001, Henk Poley wrote:
> > 1) Static:
>
> The one I like to have. All other Ti's behave like this.
Actually, dynamic relocation is standard on the TI-89, TI-92, and TI-92
Plus. Not to mention that the state of assembly programming on the other
Z80 calculators at the time Usgard was released was not to great.
> 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.
Rigel and PhatOS both can run programs for ZShell, but neither can run
programs for each other or for Usgard. Even though Rigel does use both
methods of relocation, it isn't compatible because it doesn't have the
exact same format as the others (not to mention that the addresses are
probably different). I also think that PhatOS doesn't allow calling ROM
routines by just calling into its jump table (as Usgard does, and ZShell
allows but doesn't document) which might make a few ZShell programs fail.
As far as frequency of use, I don't think any TI-85 shell is used often
these days. However, I would think that neither Rigel nor PhatOS is among
the most used. Most older TI-85 programs were written for ZShell, and
many newer ones were written for Usgard, with very few programs for Rigel
or PhatOS, almost all of which had versions for ZShell or Usgard. So I
would tend to guess that the most common shells would be ZShell (and
similar ones like OShell, CShell-NT, etc. that don't have separate
formats) and Usgard.
> > The use of & in Usgard is fairly simple for a normal assembly programme=
r,
> > as all you have to do is put an & in front of each absolute reference a=
nd
> > 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 an=
d
> > puts lines starting with R_ in their place. Thus "ld hl,&stupid_messag=
e"
> > would become "R_1: ld hl,stupid_message". Alternatively, you could hav=
e
> > just put the R_ labels in the source code, then SRCWIZ would be unneede=
d.
>
> What if this assembler uses a slightly different syntax... Then I should
> add the 'R_' myself, wich would basicaly mean that the assembler needs t=
o
> 'add' these automaticly/virtually/'not-real' when something points into t=
he
> program itself. (And also use ".org 0" as default.
>
> SRCWIZ also adds the ".org 0", isn't it?
If you do that, then you have chosen an assembler which will supply you
with a great deal of extra difficulty.
However, these particular issues are not that much of a problem. The &
symbol for relocation is not part of the TASM syntax, but rather something
handled by SRCWIZ, so it has the same effect nomatter what assembler is
used (provided your assembler doesn't require you to use "add &a,&a"
whenever you mean "add a,a" or something like that). However, if the
assembly source is generated by a compiler, it would probably be just as
easy to put in the R_ directly as to put the &.
However, the trouble will come in with trying to find the addresses of the
R_ labels if your assembler does not generate a table in the same way. Of
course, if you are not using STRING85 anyway, you could use something else
to find the labels (by looking through a listing file or something).
For Usgard, .org 0 has to be put in by the user, though this might not be
the case with Rigel.
Of course, if the assembler you are using is any good (like those normally
used for calculators like the TI-89) it should be able to generate
relocatable code itself with no extra work on the user's part; that is,
create a relocation table along with assembling without needing any
special symbols for 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 string=
85
> > is run to generate the actual file; it takes the regular assembled outp=
ut
> > 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 =E1 la 'makehead', which generates th=
e
> header/relocationtable before String85 generates the actual *.85s file...
>
> And, here also, the map file generated by Z80ASM differs from TASM.
If you were using a makehead-like thing, then it shouldn't matter, as
building the string doesn't require reading anything but the object code
in that case.
> > 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...
I would tend to think that there are much more difficult tasks involved in
a compiler.
> > The @ (or &) sign is not actually processed by the assembler at all, bu=
t
> > 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 exact=
ly
> > 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 intern=
al
> > and library relocation tables at the end of that source file, referenci=
ng
> > 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.
Nonetheless, that is the 'normal' position of it. Also, it might happen
that Usgard does expect it to be there even when Rigel doesn't.
> 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 on=
e
> 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 use=
r,
> that 'should never be seen' by the user :-(
In general, it would be a good thing for a disassembler to do that. After
all, a disassembler should disassemble your program itself, not the
details of the executable file format. Since those things weren't part of
the original assembly source, why should they be in the disassembly?
Hexediting the files might be useful if you wanted to see what the header
looks like. Though I don't know why it would be called "hex" editing, as
even though a "hex" editor lets you view and edit in hex, it shows them as
characters also, and may allow you to get decimal values of numbers and
other stuff.
> String85 is for WinDOwS... So no: Linux, Amiga, Unix, Solaris (the Z88DK
> can run one of these 'giants'), Sparc, etc.
OK, I suppose that is a good reason. Though string85 could be run under
emulation on most, if not all, of those systems. And I'd think that the
number of people who want to develop TI-85 programs on those is quite
small, to say the least. Ports of at least the ZShell string85 are out
there.
> > (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...
I don't really understand what this problem is. Clearly, the string files
do have information identifying the shell, in the form of the initial 2
bytes that come before the code itself.
> > One easy way to do it without any relocation would be to write for Phat=
OS
> > 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=
=2E
>
> I've fixed it for the Rigel shell in this way:
> ---------------
> =09org=09$9293=09=09; Origin to Rigel programs
> =09defb=09$00,$FC=09=09; This is a Rigel program string
> =09defb=09enddesc-description
> =09;org=09$9296=09=09; Origin to Rigel programs
> ..description
> =09DEFINE NEED_name
> =09INCLUDE=09"zcc_opt.def"=09; Get namestring from zcc_opt.def
> =09UNDEFINE NEED_name
> IF !DEFINED_NEED_name
> =09defm=09"Z88DK Small C+ Program"
> ENDIF
> =09defb=09$0=09=09; Termination zero
> ..enddesc
> =09defb=09fixup-$9296=09; A relative pointer to the fixup table.
> =09im=091
>
> =09[some inits + calling _main + return to shell]
>
> ..fixup
> =09defb=090,0,0,$E6=09; 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)
Something like that. Though I think the description size byte probably
would need to remain, but I'm not realy sure. Also, this source looks
kind of worrying to me that you used 'defb' for the distance from fixup to
the beginning of the program, as that seems to me like something to define
a byte, when a distance within the program would be stored as a word
value.
While I'm not sure what the $E6 is sure, I have to wonder if it is really
a part of the string data itself, or something that is just part of the
various data outside the string itself that the .85s file format uses.
References: