TNX to Matthias for his organization and to all attendees of this meeting. I was glad to meet so many people personally.
Following the concept script of my demonstration.
Allschwil Meeting 2008
2 years gone, what's happen in last two years.
Of course the emulators got the normal bugfixes, so I will only pick up some highlights.
Version 2004 Version 2006 Version 2008
Emu10 v0.92 v0.92
Emu32 v0.75 v0.77
Emu28 v1.05 v1.12 v1.16
Emu42 v1.01 v1.08 v1.10
Emu48 v1.35 v1.42 v1.47
Emu42PPC v1.01 v1.07 v1.09
Emu48PPC v1.00 v1.11 v1.16
1) In summer 2007 I changed my internet provider, because of this I was offline for some weeks. Because private homepages at the new provider had too many restrictions and I hadn't published some of my packages because of memory and bandwith limitations, I decided to order a web space package independent from my internet provider.
My new homepage is at [url:giesselink.com], the HP related stuff is at [url:hp.giesselink.com]. So all programs from my two provider hompages moved to this location. One homepage is dead now, on the other http://privat.swol.de/ChristophGiesselink/ is only a forwarder to the new location. If not done so far, update your bookmarks please.
2) Emu48 got an improved serial device selector. Versions before v1.44 could only use COM1 to COM255, actual versions can use any device name. In past ist was very difficult to load program on emulated HP38/39/40 calculators. You needed two PC's with one COM port or one PC with two COM ports and a Null-Modem cable. Or a commercial Null-Modem driver. Since 2005 there's the freeware solution com0com which works perfect in combination with Emu48.
Another big improvement was adding a MRU file list, which makes it easier to handle different state files. With this revision I changed the behavior of the LastDocument saving. Now it works like most one expected saving the name of the last state file at program exit.
3) I published a small document about the Emu48 settings at http://hp.giesselink.com/Emu48/Emu48Ini.zip which also discribe some hidden features.
4) In 2007 was the 10th anniversary of Emu48. I made a page on my HP website at [url:hp.giesselink.com] describing some highlights of the last ten years of development.
5) In fall 2007 Emu48 for Pocket PC won a software award from pocketpcmag for the best calculator emulator on a Pocket PC. Emu42 for Pocket PC was on the second place. I was very astonished by this, because the installation of Emu48 for Pocket v1.15 and earlier was more than cruel for a beginner. So I decided in fall 2007 to create an installer version of Emu48 for Pocket PC. I divided the work into three steps.
a) Looking and sorting the KML files of Emu48CE for usability. I adjusted and optimized them for the use on Emu48 for Pocket PC. To safe memory on the mobile device I converted all 256 color and below bitmaps into a compressed one. Last I the created the packaging with old ond new KML files and the configuration files for the cabinet file builder.
b) To safe maximum memory I wanted to use packed ROM image files. On the calculator emulation with a real ROM this worked quite a long time before, but the flash ROM of the HP49G had to be in the unpacked file format. I rewrote the ROM image loader code. Another positive side effect on the HP49G is, that the emulator program start time emulating a HP49G shrinked from 2.5 to 1.5 seconds. But don't ask me why, I haven't planned this. Emu48 for Pocket PC v1.16 is also working with StrongARM Pocket PC 2000 devices. I know that it's working but the official compatibility support begins with Pocket PC 2002.
c) I generated the installer script base on my Emu42 for Pocket PC one, but with some minor improvements.
I publish the new mobile version on spring 2008. BTW, Emu48 for PPC won the same award in 2008, Emu42 for PPC was on second. But this year only four programs where nominated. :(
6) In summer this year I thought about a RPL debugger in my emulator family. One basic for this a working RPL object decoder. For a successful decoding you must have an entry point table translating the object pointer into a name.
Here a big thank to J.-F. Garnier for his HP28S entry point list from Dec. 1996. His list has had ~780 entries which was a great base for my addition. My current published one from Sep. 2008 has ~1630 entries and the actual one I'm using in the following demonstration has ~1930 entries. The big step forwards in the last month mainly base on the following work.
a) First I made some thoughts about the format of the entry point table. We have more or less three possibilties. First we could use the original assembler file. The disadvantage is, that such file could contain relative addresses which can point to another relatives which finally point to an absolute address. Calculating the absolute for each relative address is normally done by the assembler of the HPTOOLS package. When using this file format my application had to do this work. The Debug4x application (development system for the HP48/49) solved this by it's own way. Debug4x use a "Cross Reference Table" ASCII file, which is an additional output file from the assembler run of the assembler source file. I used a third way, why not use the resulting object file from the assembler run directly. I have these object files already on my computer, because I need them to write own programs for the calculators on my PC. The disadvantages of this format are, you can't easily modify them for example for eliminating additional names of the same object and the output format of the assembler is version and manufacturer specific. My first version of loading such a file and searching for the name of an address was too slow in some cases. Meanwhile I'm using an improved version which i much faster.
b) The next step was creating an object decoder. RPL programs consists of objects. Each object has normally a length of 5 nibbles (20 bit). Some of these objects are a prologue of a data type. Valid data types are Real Number, Complex Number, Array, String, Binary Integer, List, ...
The basic problem I had is, that these prologue addresses are calculator specific. So I can't use the same prologue address for a Real Number object in the HP28 and in the HP48. This is a problem why it's so difficult or impossible to use Voyager from Derek S. Nickel or SAD/SADHP from Jan Brittenson for decoding a HP28 ROM. I solved this by using the object prologue name from the entry point table. So I can use the same RPL decoder for each calculator where I have a entry point table from. These names are constant, because the are hard coded in the RPLCOMP compiler of HP.
I recently published the RPL viewer engine in a seperate program. The progam UNRPL can be found at http://hp.giesselink.com/Pcuti/UNRPL.ZIP.
The viewer is at the moment part of an Alpha version of Emu42. At the moment I don't know if the viewer get part of a normal distribution.
c) Third I made a derivation of the work on the RPL object viewer. The disassember in the debugger don't know symbolic names, but with integrating the entry point table this information is now available. So on first step, I prepared the disassembler engine by integrating symbolic names for known entries. Because the debugger windows isn't wide enough I can show only the symbolic name and not the absolut address. To minimize this problem, the context help items "Go to address..." in the code and memory view accept sybolic entry names also now. With the modification of the disassembler engine the difference long/show view output between the external disassember and the debugger has gone. There's only the short view output any more. There's one side effect where I don't know if I fix it. The entry points are only known when the debugger is open, so the external disassembler works only in symbolic mode when debugger window is open and the symbol view is activated. If the debugger window is closed, the external disassembler works only in the numeric mode.
At adding also symbol labels to the debugger code view I realized that it make sense to decode PCO (Primitive Code Objects) in the debugger. In the current distributions PCO's are decoded as normal CPU opcode, so the following disassembly is always wrong. By detecting PCO code the following disassembly is also correct now. Only in some rare cases it might be possible I show a PCO instead of a correct CPU opcode.
The symbolic debugger extentions are part of all emulators in beta stage. So new versions of the IA32 emulators will contain this feature.