[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:
>
> > > 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.
Okay, all Z80 Ti's... M68k asm is automaticaly 'relocatable' (as far as I
know). Since this processor is "more grown up", it has all kind of stuff
like the higher processors we use nowadays in our PC's.
> > 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.
hmmm...
> 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).
Adresses? What adresses?
(and what format? The header-format?)
> 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.
Indeed PhatOS (says it) doesn't have the ROM_CALL() feature. This thing is
basicaly the same as on the Ti82, I hope? There they just add an offset
value to the ROM-adress, so it actually points to get right stuff, and then
calls/jumps to it.
> 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.
Yes, ZShell seemed like 'the grandfather of all Ti85 shells' to me. Every
shellmaker references to it.
> > 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.
It's not my choise... And the format isn't that different that it would be
impossible to overcome, I guess SRCWIZ only searches for the @ or & and
changes it to R_. The main problem is linking... Which would basicaly mean
that it would be easier to hack the assembler to generate a
relocation-table. Ss far as I know Z80ASM has already a built-in option to
generate a auto-relocational-executable for the Z88.
Basicly it's just collection the position all JP's and CALL's and making a
table that points to them (oh, and don't forget adress-tables)...
> 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).
& is one of the boolians... but anyways it doesn't matter that much...
> 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 &.
Uhm, do you know that 'the compiler itself' isn't the major part of 'a
compiler'? Libs (can be handwritten assembly) are much more important...
Normaly the 'compiler itself' doesn't even touch the libraries.
> For Usgard, .org 0 has to be put in by the user, though this might not be
> the case with Rigel.
You can do both (..but not at the same time..), org 0 and org $9296. With
org 0 you will need use the & stuff or adress+PROGRAM_ADDR.
> 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.
Indeed I think that's the way to follow if somebody is willing to spend
some time on it (I should be that person, I know).
> > > 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.
Oh yes, but if you have a working one, then reshaping it is more difficult
then trying to find another solution.
> 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.
Currently I've got Rigel working, and UsGard is that 'far away' that I
haven't even looked (thoroughly) at that shell...
> > 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?
BTW, It does (incorrectly dissasembled) show the relocation-pointer, and
relocationtable itself. Only the 'real-header' (header bytes/word and
description-size) are removed. The rest stays. I think that IS confusing...
> > 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.
Oh, yes and we could also use Perl and Tcl/Tk scripts or reprogram the
compiler in Java. That would make everybody use it (..not..), since they
would need to download 'hunderds' of megabytes of libs and executables to
get the thing to work.
The entier Z88DK (source included) is now about 6MB. A fully working
binary-distribution would be aprox. 2.5MB. It is already irritating that
they use 'make' to compile the libs. I know I can get this to work on my
Windows (don't bother me about that) machine by downloading a 30MB CygWin
distro. I won't download it, it far to big for that bit of support I get, I
can also just wait a week till someone puts newely compiled libs into CVS.
> > 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.
Now the difference between binaries (the *.BIN or *.OBJ files) and
strings/programs/executables (in this case *.85S)???
> > 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.
It needs to remain...
> 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.
Uhm, yes...
But how could it then possibly work (it does work)?
> 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.
I'll check around...
BTW: I still haven't seen anything like some decent header description(s).
Henk Poley <><
Follow-Ups: