For those who are interested, this is where I've set up my "fork" of the Java AGI interpreter:
https://github.com/lanceewing/jagiMy current work is under this feature branch:
https://github.com/lanceewing/jagi/tree/feature-appleii-kq2The first commit was pretty much exactly what was in the sourceforge CVS repo. I say pretty much because I stripped out some native bits and pieces for Mac and Win32 that weren't really needed for what I'm doing. I've worded the project description such that it is focused on the pre-AGIv2 investigation work at this stage. As I go along, I'll probably end up fixing things in the Interpreter code as well (since its not really that playable at present), but for the time being I'm working mainly in the viewer/decompiler/debugger parts.
It has been very useful actually. I've been bringing up each of the LOGIC scripts in the Apple II KQ2 game and wherever it falls over during the decompilation, it is usually due to encountering a test or action command that I haven't yet identified and mapped. So I try to work out what it is at that point. Half the time I can identify what it should be, but the other half I end up assigning an "unknown" action to it. I have defined various unknown test and action commands, one for each number of parameters. This allows the decompilation to continue and ends up displaying something like "unknown(8, 30);" or whatever at that point in the code. Once the end of the script is reached, I can compare it with the AGI v2 version of KQ2 to see if I can work out what the unknown command might be. The scripts are hardly ever the same between the two versions, the AGI v2 version usually having more code in it, but they're similar enough to be able to help with working things out.
I have noticed a number of scripts where the decompiler code gets itself confused with jumps and ends up falling over. Quite often this is due to a stack over flow error, where it calls the decompile method recursively and never seems to be able to get out of it. It looks like this happens in some of the logic that processes the 0xFE goto/else opcode. I think if it encounters such an unconditional jump in the middle of a block of code that happens to be wrapped in an IF/ELSE structure (but not placed such that it forms part of that structure), and if that jump is to code outside of the IF/ELSE block, then it goes in to a bit of a panic. Such a "goto" scenario is fairly common in AGI scripts, which is why it seems more likely that "goto" was a keyword in the original language rather than all jumps being part of a loop or if/else structure. The Java AGI interpreter's decompiler attempts to identify "for", "while", and "do..while", but I think this might be futile. It is probably best that it does what AGI Studio does, which is that any jump that can't be matched to an if/else structure is output as a goto. - When I get a chance, I'm going to rewrite it's decompile code to make it a bit simpler and to essentially do what AGI Studio does.