This seems very cool... if only it was made for the 89 so I could have a chance to try it :)

Oh well anyways very good job on this... I'm sure all the 92 people will enjoy it, with the large library of games they now have access to.

- Jeff

LOL! You manged to get "smashing" in. Way to go ol jolly chap!

Darn right. Its time was due.

--BlueCalx

Confidential to Ed Sim: Got frustum? http://frustum.nickd.org/ does ;)

Now you have to get "choice" in.

amicek

I think he needs to get "darn tootin" in somewhere... It's cooler than "choice" :)

DefconAlpha (:^)

To do:
-----
insolent fop
g0t ph34r?!
antidisestablishmentarianistic
hippomonstrosesquippedaliophobia
uber-hardcore

--BlueCalx

Well that isn't hard compared a to-do list like:

* Make a cool website that gets lots of traffic
* Update it frequently despite large amounts of homework
* Make it a unique site

You have already done that; you lucky person...

amicek

MAAAAAAAANNNNNNNN!!!!!!!!!!!!!!!!!!!!!!!
NO FAIR!!!!!!
I love my TI-86 kuz i can play 86, most 85, 83, adn 82 games....
Now the dumb "SUPER" calculators can play my 85 games!! wah!!!

Pssh, the 86 is still the champion as physics goes.
The steps to do stuff on the 86 are far less cumbersome than on the 89, even though the 89 is much more powerful.

--BlueCalx

86 owners are so stuck up about their ability to play games for other calcs... come on... it's someone else's turn now. :)

- Jeff

I agree

Everything below is me just tring to be funny, nobody take this as an insult, please.

everyone chear, yeay.

<joke>All hail the wize leader that will help fight for the other calculators turns in emulation.
</joke>

something that would make other calculator owners even MORE jealous:

<dreaming>

TI announces the TI-86+, without the 8k limit and 300k total memory

</dreaming>

that WOULD be cool, though :P

There is NO 8K limit! Yees, just use YAS and you'll be able to use any program, even if it doesn't have it's own barrier breaker. And that 86+ isn't going to come, for I believe TI will focus on the 68K for their new calcs. Plus: the 86 already has 384KB total memory: 256KB ROM and 128KB RAM!

Yeah, my math teacher says they're planning on discontinuing the 86... (which might meant the 85 also?).

I don't think YAS would be compatible if TI ever released the 86+; look at the 83+. Besides, the limit thing about YAS is only for running 82 games being over 12k (at least I think thats it), and going around a TI-OS barrier would require a little more doing to get around

No that's not true. YAS can run any program over 12KB, not only 82 and 85 programs. So in fact, it has 86 emulation for the 86....

See, now thats how I felt about ION86

Great, here we go again... :-)

Don't worry. It will never work as well as on the TI-86.

True, if you are saying we would be emulating an emulator (emulating 86 games and using our emulated 86 to play 82 or 83 or something games). But if someone makes another emulator, or if we are just running 86 games, we could be running them faster than the original (sort of like UltraHLE).

- Jeff

Very nice! I've often thought about such a recompiling technique, but never gone as far as this. Why does this work with source code instead of object code? Since it's essentially a direct opcode translation (with minor hardware emulation), parsing through all the Z80 source would add a lot of complexity to the project.

Has the idea of doing it from the object level on-calc been considered? The source could be recompiled before it runs, and if it writes to it's own code space, then it would trap that and dynamically recompile that portion of the code on-the-fly. This would be the same manner that most speed conscious emulators work, such as Mac <-> PC and N64 -> PC.

I thought that an on-calc recompilation system would be too big. It requires the recompilation program itself, as well as all the Z80's data, and the converted code to be in memory. That isn't likely to fit on the TI-92 where you have 70K (84K if you use the stack also).

I don't know how actual dynamic recompilation is implemented, but I'm also concerned about jumps. It seems to me that any jump in the recompiled code would have to look up the address of its target in the converted 68K code. This would take a while unless the size of 68K code was a constant multiple of the Z80, which would likely be big since it needs to account for the largest instructions. The serious implentatios of dynamic recompilation may have a solution to this, but I can't see an obvious one. Also, unless a list of jump targets were maintained, it wouldn't be known whether a section of code can be entered in the middle, like I can do if I trust entry to only be on labels. So some optimizations (that I don't use now anyway) would be harder in that system.

Of course, I do realize the limitations of the system I'm using. Nonetheless, on the TI-85 (where, unlike on the TI-86, people don't move their own code around a lot) I think most programs should be able to work with this system. Self-modifying code is a huge problem, but not an unsolvable one. Usually it's only used on the constant field of an instruction, so all that's needed is to evaluate the addresses, and if they're pointing to the middle of an instruction, to adjust the value accordingly. Of course, jump tables are a slightly bigger problem, and that will be a mess, but I still think it can be done as well.

Jumps are a problem, but it's the same thing as accurately dissassembling code. If a program has data thrown between routines, then it would throw off where the code should be dissassembled and recompiled. Dynamic recompilers that handle this work along the same premises as an emulating dissassembler. Until it has been run, it can't be treated as code, and thus must be treated as undefined. And if it gets written to, then it must go back to being undefined, until it gets run.

When a block of undefined data is hit by the executing code, it gets compiled and executing continues. All jumps to undefined sections return to the recompiler, as they must remain undefined until the target is defined.

Of course, the problem of code jumping into the middle of an instruction must be dealt with as well. This is handled by maintaining a translation table of all recompiled addresses in the original code to the generated code for the host processor. While the data for the instruction will have been defined (compiled), it will not have an address in the translation table because it compiled starting from a different offset.

This method assumes that the machine has a lot of memory to work with, which I realize that the TI-92 does not. However, the TI-89 and TI-92+ do probably have enough RAM to implement this technique, which would be required to run TI-86 programs. Except that ROM calls on the TI-86 would be an absolute nightmare.

There is undoubtly other methods to implement a dynamic recompiler, but this is the only one that I have figured out that will execute any code with complete acuracy.

Maybe this will give someone ideas to work with...