HP emulator

Chris wrote.... Well, sort of. I haven't found enough of the missing parts I need (called "round-tuit's") to finish off the hpemu project ;) It has been in that state for a long time. However, I can assure you it is not dead, someday I will definitely get around to finishing it off. Since I haven't touched it in so long I don't remember the exact state of where I left it. As I recall, there were two things left to finish - the doubleword floating point multiply/divide (FMP/FDV) instructions, and a few more peripheral devices. I just don't get binary floating point math, I have to think way too hard for it. Often much more complex things in the coding I can grasp with ease, but there's something about binary floating point math that joest doesn't click with me. I can do it, but it takes eons. I know there are easy ways to accomplish this, like mapping the HP format to IEEE, doing the operations, then converting back... but you lose the bug-for-bug identical nature of what I've been able to adhere to so far. As a result, I spend lots of time pouring over microcode and diagnostic source to make painfully sure my code produces all possible results identically. The diagnostics are the definitive test, and I can say with pride that HPEMU currently passes all standard HP diagnostics except the unimplemented FMP/FDV stuff. I can even pass the HP power-fail auto-restart test and the memory parity error test. How's THAT for going to extremes to code in exactly identical behaviour? One of the recurring themes in my code is that I do not do things necessarily in the most straightforward way, I go to great lengths to do them the same way the hardware does it. Despite this, parts of the code are exceedingly fast, other parts are rather slow. I think many purists will eventually look at my code and say "this is going WAY too far just for the sake of having the code execute the same way the real hardware does". I realize that, but for me it's a labor of love and a way of learning the machine completely. The biggest thing that caused me a huge delay in this project was fully gnu-izing it. I hadn't built anything complex using automake, autoconf, libtool, texi, etc. That was a huge learning curve. I decided to implement custom microcode (and HP microcode for that matter) as dynamic loadable code via ltdl. Many would consider this overkill but it seemed a very logical way to do it. That was another learning curve. As I'm sure many will attest, learning autotools & friends from scratch can be a daunting process! Not to mention the fact that every time I turn around, the autotools go through dramatic changes. I follow the autotools mailing lists and they keep changing fast the past year or two. I tried a time or two to get additional developers to help, but no one really stepped up to the plate so I just worked on it when I could. Ok, now you have me interested in it again, maybe it's time to dust it off...... Jay West PS - I don't recall talking about HPEMU much besides here, where did you hear about it?