Re: A82: Game Wizard v2.0 bug discovered!!!

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

Re: A82: Game Wizard v2.0 bug discovered!!!


At 08:58 PM 2/8/98 +0100, you wrote:
<snip>
>Block -> GRAPH_MEM = 500
>Mem down = 24000
>GRAPH_MEM -> block = 500
>Total = 25000 bytes
>
>If you need the last program stored in mem you have to move it app 24000
>bytes = 48 blocks. This means you have to move 48*25000 bytes = 1200000
>bytes. An LDDR takes 10.5 micros/byte @ 2 MHz, so lets assume that the
>TI82 uses 3 micros. This means the relocation would take 1.2*3 s = 3.6 s!
>I think that more than 3 secs to relocate a program is way too much.

I have already addressed this problem.  Most ASH programs tend to be near
the beginning of the memory (which means faster relocation), so it doesn't
really matter as long as the programs stay together in one piece.  3
seconds isn't that bad actually since the memory would be full at that
point and most users would be expecting relocation to be kind of slow.
Besides, I don't think you can really brag about simpel relocation that
much since my method will also take care of program sizes > 13K and will
still keep the programs all together in one piece.

>Besides that there are a few other problems with your method.
>
>1. How do you locate another variable in your program ?
>2. It wont be possible to use the VAR routines.
>3. It wont be possible to use the FP Stack for FP math 
>4. How would you make it possible to use KEY_HAND ?

1)  What are you talking about?  This method moves the program to the
specified address that is in the documentation.  In this case, it would be
the same as ASH's location of the start of a program.

2)  Who needs the VAR routines in the first place inside the shell?

3)  Who needs the SLOW FP math routines in the first place...you are
running games, not math proggies?

4)  See my previous response to this.

How about if I said my routine should also update the VAT.  Would that make
you happy.  Of course it wouldn't because when you returned to the shell,
the programs would be all out of order and that would tick some people off
if their programs constantly moved around.  So, you should fix these four
problems but store the VAT someplace so the programs will be restored to
their original locations when you exit different programs.  You also have
these problems with simpel relocation, so I don't see how you can complain
about these problems to me when you haven't fixed them yourself.  I didn't
say I was the author of a shell, I was just giving hints on a method that
would keep the programs in one piece:  Block Relocation is that method, and
it works just fine.

>Also there is another problem which moght be hard to solve. If a new
>version of the shell is released (minor bug fixes, but the old programs
>should work otherwise), and it is larger then the old version. If you used
>your method the last part of the shell would be moved to another place in
>the mem, where it would be place bewteen to vars. If you have pieces of
>code like this in wierd places in the mem, finding external veriables will
>become a lot harder.

What are you talking about?  The shell is located in ONE piece just like
Game Wizard should be but isn't because of simpel relocation.  Block
relocation makes sure all the programs stay together in one piece rather
than split using simpel relocation.

>Another question, how would you locate Game Wizard, if another program was
>relocate at the time ?  

Exactly what ASH does with simpel relocation (it splits the program up into
pieces and moves it to another location where the interrupt routine finds
the checksum and calculates where the start of Game Wizard should be but
really isn't there a lot of the time because of simpel relocation).  I have
already solved this problem in my interrupt routine.  I even created
special JUMP_() and CALL_() routines to allow my program to do it's thing
without it being required to be at a specific location.  It is just that
Game Wizard is split into pieces when another program is run because of
simpel relocation.  Use block relocation instead to correct this problem
and keep the programs together in one piece.

>As far as i can see Simpel relocation is a lot better than this (with
>a minor bug fix in Ash, all programs would work (except for Game
>Wizard, but if you inserted the 10 lines of code there would be no
>problem)).

Again I ask...what 10 lines of code?  You keep talking over and over and
over and over about this but haven't released these 10 lines of code that I
seem to need so badly.


                 Thomas J. Hruska -- thruska@tir.com
Shining Light Productions -- "Meeting the needs of fellow programmers"
         http://www.geocities.com/SiliconValley/Heights/8504
                    http://shinelight.home.ml.org

  Spam-Fighter code is:  14806560   (New technique to fighting spam)
  Enter "Spam-Fighter:  XXXXXXXX" in the body of a personal message
  to thruska@tir.com.  Otherwise the message will be filtered as spam.
Follow-Ups: References: