How to use the emulator to investigate (old) applications.

Many old applications no longer run on more modern hardware, and that can have various reasons. Very often the program was crunched in some way, because it the old days space on floppies was very restricted and transfer was slow. Crunching etc. allowed it to fit on one floppie and load faster. For copyrighted software it was also a means to protect it from being copied in unauthorised ways. Often you cannot see what the program was originally, machinecode/BASIC/C. You can only know if you investigate. If the code was BASIC, there is a possibility to run it unchanged on modern-day hardware. Often it is useful to decrunch because the original decrunching overwrites the original program and processors with separate data+code caches cannot handle that.
Stage one, so, is running the program to a state where it is readable, be it BASIC code or ARM-code. Assume you have a program e.g. !Runimage that you want to investigate. If there is a !Run file going alongside, you can often see if execution should start onwards from the normal address, &8000, or a higher-up one. Most of the time it will be &8000, - use address &8000 - , otherwise use the execution address for this:
Drag the file-under-investigation (fui) to an editor in the host environment. E.g.!Zap. When !EmuTrsf is active, this is easy to do. Just drag the file over the windowborder into the editor. In the emulation, don't forget to backup the original !Runimage.

Read the word at the address where execution starts. E.g. it shows:
00008000 &EA00E1AF B &000406C4    the important value here is &EA00E1AF.

Open the Monitor window of !ArchiEmu (by adjust-clicking on the iconbar icon (or choosing the 3rd menu option of the iconbar menu). In the Monitor window you will notice a 'Breakpoint' button at the bottom of the window. Click Menu on this button. A dialogue window opens. At the bottom of it, you will find 'Brkptinstr replaces swi&550BF:& FFFFFFFF' Replace FFFFFFFF by the value in the first-executed line in !Zap, so by the value EA00E1AF in this example.
Click on OK (at the right), the Breakpoint dialoguewindow closes. Close the Monitor window; this has the effect of letting the emulator run again.
In the !Zap editor, replace &EA001AF / B&406C4  by the software interrupt &550BF. This is one of the swi's provided by the RBMemMgr module, and is misused for this purpose. So set the caret on this line (Select-click on the line) and begin to type: SWI &550BF <Return>
When done, save the file back to inside the emulation, replacing the original !Runimage.
Start the application. Most probably you will notice that the emulation freezes; again open the Monitor window and if all went well, the grey line now is at the changed instruction. The old instruction is already substituted back. The emulation is now in singlestep mode. When you Select-click on the NEXT button, one instruction is done. Often you will soon find the emulation in some programloop, and you will see some register increasing or decreasing and sometimes being compared to an other register. These decodings often involve milliomns of instructions so it's time to speed things up: there is a writable icon obove the STOP/NEXT buttons and you can fill in some value, e.g.1000. When you now click Adjust on the NEXT button (ie. right mousebutton) one thousand instructions are done. You can adjust-click a few times until you get near the end-value of the counter-register, reduce the number of instructions-at-a-time and click until the counter runs out. Most of the time you will encounter a few of these long loops in one program, traverse them one by one. Probably at some stage the Program Counter R15 will at some time go to address &8000, or near that value; with some experience you will get a feeling at what point to assume the decrunching is over. You now can save the decrunched program; click Menu on the subpane with the disassembled instructions. Choose the last entry, Load and Save. Drag the 'Data' icon to a disc-location of your liking. Whith !Zap or a similar editor, you can further investigate this file. Perhaps there is a BASIC file in it, if it begins somewhere with &D and ends with &D/&FF. A C-file can be recognised by the header and some C-specific contents such as the branch instructions at the end (the stubs), and some initialisation swi's.
Please note, some harder encoding schemes use a number of crunch operations in succession and do meaningful stuff in between these blocks. Copy these meaningful blocks using the dataload/save dialoguewindow and make a note of the values in the registers before these blocks are executed. In time, you can add this stuff again, and extra register load instructions of your own, to the eventual file.
Often it is also useful to make a tracefile. This is a file with beginvalues of the registers and EOR values+registernumber for the following ones. Click on the Trace button. After some instructions, click Trace again and a save dialoguewindow comes up. The maximum size is 2 G or 4 G (i forgot), ie. 200-400 million instructions. These files can be investigated using a separate program, !Tracer, allowing you to step forward, backward, finding address accesses, registercontents, comparing two tracerfiles to see where they diverge, making small listings of executed instructions etc.
For further tips see the newsgroup posting of Chris Poole in csa.hardware and csa.apps, Fri. 11 Oct 09:19:53 
