| Author | Comment | ||
|---|---|---|---|
 Kimbett |
Chaining executibles |
Lead | |
|
Posts: 194 (2009-01-22 19:34:26) |
Is there an easy way to have a program launch another program, and then free the memory occupied by the first program?
In good ol' basic, this was using the CHAIN command. Thanks in advance. |
||
|
Lionel Debroux |
|||
|
Posts: 2989 (2009-01-23 08:37:34) Former Admin |
> Is there an easy way to have a program launch another program, and then free the memory occupied by the first program?
I don't remember ever seeing something like this implemented on TI-68k calculators, at least in AMS native mode... It's clear to me that in order to make matters easier, HW3Patch should be installed on HW2/3/4 calculators, so that the stupid RAM execution protection is not a concern. I've made a small proof of concept for a program launching multiple other relocation-less programs communicating through shared memory (adding relocations would not make the launcher program much more complicated) . It requires prior execution of HW3Patch, it bails out if it can't find it. You can download it at http://tict.ticalc.org/do...ds/launchmultiple.tar.bz2 Could you give us some information about what you'd like to do, that may require launching a program from another program and freeing up the memory occupied by the first program ? Is it a new incarnation of your games ? |
||
|
Kevin Kofler |
|||
|
Posts: 6973 (2009-01-24 00:04:44) Admin |
It can be done without HW3Patch: Copy some glue code to 0x5000, which is in the middle of the screen, but at the beginning of the 4 KB which are always
unprotected by AMS, jump to it. That glue code should free the old program if it was a twin symbol, create a twin symbol of the new program if needed, use the
enter_ghost_space hack to unprotect the target memory on AMS 3 or the ghost space on HW2 (on HW2 AMS 3, which exists on the V200, either method works, on HW1
you don't have to unprotect anything), then jump to it.
|
||
|
Kimbett |
|||
|
Posts: 195 (2009-01-24 06:27:08) |
Lionel, Kevin,
I think I like your 'glue' approach Kevin as it doesn't involve the HW3 patch. Here's one possible solution:
Kevin, is there an example of your approach available? Thanks guys. I'm happy to see the scene is still flourishing. -Jeff
|
||
|
Kevin Kofler |
|||
|
Posts: 6974 (2009-01-24 10:39:22) Admin |
You need HW3Patch on the Titanium anyway for the FAT Engine.
On HW2, you can use the ghost space. Your program runs in ghost space anyway when you use the FAT Engine on HW2. So you just have to add 0x40000 to the address of what you're chaining to if (HW_VERSION==2) (HW_VERSION is a pseudo-constant which corresponds to your hardware version as an integer). |
||
|
Lionel Debroux |
|||
|
Posts: 2990 (2009-01-24 17:01:57) Former Admin |
> Lionel, I downloaded your test program, but haven't patched my V200's firmware yet to test it.
You can test it on your favorite emulator without HW3Patching your V200 
For a program that runs on 89T, requiring HW3Patch is not a capital sin, because it's required anyway (for performance reasons) for programs that use an AMS native "DLL" (which FAT-Engine is, although it uses its own code so that users can use another AMS native "DLL"). On other models, the choice is up to you. The main upside of requiring prior install of HW2/3Patch (and making all code execute in the real RAM, not one of its ghost spaces if it exists), is that the trickery to work around TI's stupid protections, i.e. a larger glue code containing enter_ghost_space and optionally made conditional upon the HW model, doesn't take space in every independent chunk of Corridor 99 (either you include it as code in all chunks, or you include code in all chunks to fetch a single external variable that you'll copy at 0x5000, but all independent programs have to use it in a way or another). This additional complexity doesn't yield too much of a size increase (I'd "guesstimate" 100 to 250 bytes per copy), but it's something that you should know, I think
> (or simply save and load from a temporary file) This would certainly require more code than passing a pointer to some data structure, so I wouldn't do that 
> Kevin, is there an example of your approach available? I don't remember whether it's a full implementation (including twin symbol handling, I mean), but I remember seeing some launcher code that uses the 0x5000 range. I'm thinking of Kevin's TitaniK, Iceberg or perhaps an early version of HW3-compatible ttstart. |
||
|
Kevin Kofler |
|||
|
Posts: 6975 (2009-01-24 18:02:12) Admin |
You can test it on your favorite emulator without HW3Patching your V200 You'll have to run HW3Patch in TiEmu or disable the execution protection emulation though. On other models, the choice is up to you. Last I checked, the FAT Engine would error out if the program isn't running in ghost space on HW2, and/or use EXECUTE_IN_GHOST_SPACE which forces it. The main upside of requiring prior install of HW2/3Patch (and making all code execute in the real RAM, not one of its ghost spaces if it exists), is that the trickery to work around TI's stupid protections, i.e. a larger glue code containing enter_ghost_space and optionally made conditional upon the HW model, doesn't take space in every independent chunk of Corridor 99 (either you include it as code in all chunks, or you include code in all chunks to fetch a single external variable that you'll copy at 0x5000, but all independent programs have to use it in a way or another). This additional complexity doesn't yield too much of a size increase (I'd "guesstimate" 100 to 250 bytes per copy), but it's something that you should know, I think I don't think these few bytes will make a real difference here. The code has to be split anyway and then size pressure should no longer be as big a problem. > Kevin, is there an example of your approach available? But that code is all very different from what I suggested doing. These protection bypass algorithms are all very specialized for the current specific need. But they aren't needed here anyway, because the FAT Engine requires a "strong hammer" method (HW3Patch on the Titanium, on HW2, you can get away with the ghost space) anyway. |
||
|
Lionel Debroux |
|||
|
Posts: 2991 (2009-01-25 10:31:41) Former Admin |
> Last I checked, the FAT Engine would error out if the program isn't running in ghost space on HW2, and/or use EXECUTE_IN_GHOST_SPACE which forces it.
Ah ? I didn't even remember. I may want to tweak this behaviour...
Last Edited By: Lionel Debroux
2009-01-25 10:50:57.
Edited 1 times.
|
||
|
Kimbett |
|||
|
Posts: 196 (2009-01-25 20:42:54) |
Gentlemen,
-Jeff
|
||
|
Lionel Debroux |
|||
|
Posts: 2992 (2009-01-25 21:10:56) Former Admin |
The HW2/3 RAM execution protection prevents jumping back and forth between a program and a DLL. On HW2, it's possible to ease the pain by tricking AMS into
unprotecting the last 4K RAM page (which also controls execution protection for the ghost spaces in the 0x40000-0x1FFFFF range), but there's no such thing
on HW3. Therefore:
> It sounds to me like the Corridor 99 module 'glue code' would be identical across all HW versions (assuming the HW3 platform is already patched)? Both HW2 and HW3 need to be HW2/3Patch'ed (HW3Patch works on HW2 as well) so that the code and glue code is identical across all HW versions (everything executed in the real RAM). I have a feeling that many calculators in the field have HW2/3Patch, for two different reasons: * as I wrote above, it's necessary on HW3. Or at least, the ways around it being necessary can suck performance-wise (it could be possible to use some glue code that tricks AMS into unprotecting each chunk as needed, but that would kill performance in some use cases). * some "kernels" and "kernel"-based programs depend on HW2/3Patch being installed ("black bar" if not). Even if that tends to be less important nowadays, since a) PreOS, the only maintained kernel, is fully aware of all HW models & has some fixes built-in for several kernel-based programs and b) the number of 1999-2002 HW2 calculators is decreasing. |
||
|
Kevin Kofler |
|||
|
Posts: 6976 (2009-01-26 00:52:45) Admin |
The correct solution is to:
1. use EXECUTE_IN_GHOST_SPACE in your main program. In fact you should be doing that already for the FAT Engine and 2. add (HW_VERSION==2?0x40000:0) to the address of what you want to run (before the EX_patch - the call to EX_patch also needs both its pointers in the ghost space on HW2). Don't listen to Lionel's excuses for being lazy. It's easy to do the right thing. |
||
|
Lionel Debroux |
|||
|
Posts: 2993 (2009-01-26 09:54:17) Former Admin |
As I mentioned above, what you're calling "excuses for being lazy" are also ways to cut down on the size of a program (though not by much, as I
ALSO wrote above). I can also write that:
* the old HW1&HW2 89&92+ sales have stopped years ago, which leads directly to their presence in the field decreasing; * HW2 V200 has lower sale figures than HW3/HW4 89T, I'm told (and I'm not even sure that the V200 is still on sale in 2009). => as time goes by, it makes less and less sense not to execute in the real RAM, after applying HW3Patch. In the same vein, as time goes by, it makes less and less sense to allocate only one of the two grayplanes on HW1: TI stopped producing HW1s *TEN* years ago. But you and me have already discussed that many times, and none of us has convinced the other to change his mind, so we aren't going to discuss it again, I guess ? See: * there are arguments for doing what you're calling "the right thing" / against doing what you're calling "excuses for being lazy"; * there are arguments against doing what you're calling "the right thing" / for doing what you're calling "excuses for being lazy". Don't be so one-sided when evaluating technical solutions
Anyway, the choice of the method remains to the final programmer (Jeff, in this topic). But the better informed he is of multiple ways to do what he plans on doing, the more sound his choice is. Choosing among a single solution is not a choice. |
||
|
Kimbett |
|||
|
Posts: 197 (2009-01-30 04:56:38) |
Hey guys,
Update: Using some keywords of this topic like EX_patch, and EXECUTE_IN_GHOST_SPACE I found some great info in the TIGCC Documentation. Though... this clearly isn't going to be as easy as I had hoped. Hopefully, this weekend, I'll have tweaked my 'launcher' to allow me to load and unload the C99 modules. So far, I've only succeeded in crashing my calculator when trying to run the launcher on my emulated HW2 TI92+ Does TiEmu emulate these protections? It's amazing how much work has gone into getting around these wierd software and hardware 'protections'. I guess the having a well documented mips cpu like the M68K helps. Thanks for all of your help! -Jeff |
||
|
Lionel Debroux |
|||
|
Posts: 2994 (2009-01-30 06:10:46) Former Admin |
> Does TiEmu emulate these protections?
Yes, unlike VTI (for the most part). |
||
