Re: A85: Tyrant ports


[Prev][Next][Index][Thread]

Re: A85: Tyrant ports




>On the ROM part, you supply the addresses for the ROM routines inside your
>program, and it patches them for you (depending on which ROM version you
>have), so they are immediately useable.

I see. I thought you wanted to do it by using one addr (like ROM_CALL). The
only problem I can see with this is the size. wont a program become quite
big if it uses a lot of ROM functions ?

>In actuality, if you look at the positions of routines in the ROM, they
>follow a specific pattern, that could be calculated, given 3.0A, and 9.0
>addresses.  I haven't taken advantage of that fact yet, but maybee in a
>later version...  With my system, you could use ROM routines in pages other
>than 0, but you'd have to handle switching pages on your own.  The shell
>doesn't do it.

Each ROM function would require 7*2 bytes, and 1 or 2 two per call to it
right ? This could make programs quite big. I know the pattern, but it seems
a bit to complicated to include in a general ROM_CALL function (it would
make the function too slow). However if you a program uses a lot of
ROM_CALLs this could reduce the size quite a bit.

>My TSR system (which has already been tested) keeps them in a pseudo ZShell
>type of format.  It searches for the TSR variable each time an interrupt
>occurs.  It works quite well, and if it doesn't detect the variable, in
>case its been erased, etc. it kills the interrupt system, and switches it
>back to interrupt mode 1.  Interrupts would need to be disabled during
>relocation, however, or it wouldn't be able to detect the TSR's variable
>correctly, and it will shut itself down.  I haven't noticed a single
>problem with it so far.  I haven't even seen a noticable speed decrease.

Wouldn't it be faster to store a pointer to the VAT entry, and check that
every time ? So instead of searching all VAT entries from the begining to
the var you are using, you would just check to see if the VAT entry was in
the same place, if so then just call the function. If it is not in the same
place, then do a search and store the new location.

>The method of relocation you describe works.  I used it on Summit BETA 1-3.
> I noticed that it leaves the system a little unstable afterwards.  I used
>a strange form of delocation: I just left the variable right after the
>shell.  I screws with the TI-OS.  I don't know why.  It seems to work fine
>for a while, then it just crashes suddenly, usually when it does an APD
>shutdown.  Go figure.

The RAM contains a lot of pointers that has to be updated correctly,
otherwise the system might crash. Leaving the variable right after the shell
should not be a problem, on the TI85 since the OS doesn't use any special
order for vars. There are several locations in the RAM which are only used
on APD, and you might be having problems with one of those. Which functions
did you use to move the var ? Did you write them your self or use the ROM
functions ? IF you wrote them your self, you are probably not updating all
the pointers in the system, which could cause problems.
>
>Problem is, I wrote that relocation routine a while ago (several months).
> I don't understand it anymore.  UGH.  I want to try a new method anyway.
> Do you know how Usgard does it's relocation?  Does it just remap
>everything?

Basically usgard just adds PROGRAM_ADDR to all absolute calls before
executing a program, nothing really fancy. IF you don't mind I would love to
see you relocation routine.

Dines