HP Forums

Full Version: Another microcode simulation in development
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I've just gotten the microcode of the HP-25 sort of limping along on an experimental version of my microcode simulator. This has been more challenging than my previous efforts because there is no publicly available documentation on the Woodstock instruction set other than an HP Journal article giving a brief overview of how it compares to the Classic architecture, and a snippet of the HP-25 ROM listing in a US patent. Neither source has sufficient details.

Most of the calculator functions do not yet work correctly. But the PRGM/RUN switch works, and SST and BST in program mode step throught the default "GTO 00" instructions correctly. Pressing the f or g shifts in program mode show the prefix keycode. But instructions can't actually be entered correctly.

R/S in RUN mode displays the correct step number and GTO 00 instruction when held down, and executes it when released. Other than that, in RUN mode almost nothing works correctly.

Low battery detect works, although since there's not much point to having low batteries in a simulator, I've now hard-coded the battery status to good.

In either mode, many operations cause a hang.

I suspect that there are fairly minor bugs in the simulation code that are causing these problems, but it may take some time to track them down. Once it is working, a new release of the simulator will be made available, although under a new name rather than CASMSIM.

A screenshot of two instances of the simulator running simultaneously, one in run mode and one in program mode showing step 01, may be seen here:
http://www.brouhaha.com/~eric/software/casmsim/experimental/hp25_screenshot.png

Warning, the image is about half a megabyte in size.

Hi Eric,

Congrats on your forward progress so far. Even if your HP25 can't add or subtract, you've still made a big step :)

A few questions:

1. Do you have the ability to hardware-emulate

an HP Woodstock serial ROM?

2. Can you capture/track ROM address flow for each

function or keypress?

3. For the unknown Woodstock instructions, do you

know which are opcodes vs. operands/arguments??

Tweaking the hardware ROM emulation to jump to/'bank in'/ somehow introduce-into-code-flow some register & status dump patch code after an unknown opcode might be quite helpful to find out what gets disturbed...

If you've answered "yes" to question #3 above, you might be able to use some opcode frequency charts to see if any statistical correspondences btwn Classic & Woodstock opcodes exist.

I am wondering if backing up and working on emulating the HP21 (first Woodstock) might be useful - smaller/simpler than that of HP25, perhaps there are some similarities to HP35/45 firmware organization.

Regards,

Bill Wiese

San Jose CA

I've done some more debugging. Now everything seems to work except the logarithmic and exponential functions (including y^x).

Bill writes:

Quote:
1. Do you have the ability to hardware-emulate
an HP Woodstock serial ROM?

Not yet. Soon.

Quote:
2. Can you capture/track ROM address flow for each
function or keypress?

I can capture traces from the simulator. I'll be able
to capture traces from the real hardware soon.

Quote:
3. For the unknown Woodstock instructions, do you
know which are opcodes vs. operands/arguments??

All ACT instructions are a single word except for ten conditional test instructions, for which all ten bits of the second word are the branch target (within the current 1K of ROM space). I do have the encodings for those. As with the Nut processor used in the HP-41 and Voyager families, the ACT processor does not assert SYNC during the second word of a two-word instruction.

There are three ACT instructions for which I don't know the encodings. None of them are used in the HP-25. One is used to switch from 12-digit to 14-digit display mode. One loads a key code into the A register (the HP-25 uses a direct keys->rom address branch instead), and one rotates the entire C register left by one digit. I believe that these are opcodes 0120, 0320, and 0520 octal, not necessarily in that order.

There are seven instructions implemented by the PIK chip for printer control in the HP-91, HP-92, HP-95C, HP-97, and HP-19C. I believe those are xx20 opcodes from 1120 through 1720 octal.

I expect that there are other instructions used by the CRC chip (card reader control) in the HP-67 and HP-97, but I don't have any information on them.

The HP-19C, HP-67, HP-92, HP-95C, and HP-97 use bank-switching of ROMs. I believe the instruction 1060 octal is used; certainly that's the instruction used on the Spice series. I don't know exactly how it works. It might be as simple as toggling the ROM bank for the current PC address.

The Spice series seems to use basically the same instruction set, with the addition of the ROM checksum instruction (1460 octal) used by the self-test. However, there may be other new instructions. And there may be other architectural differences; for instance, perhaps they've increased the depth of the subroutine stack. There is even less published information about Spice internals than about Woodstock.

Eric

Hi!
Has someone ever tried to run a simulator in Hardware?
I am currently rebuilding a HP 67 Calculator using a PIC MICROCHIP 16f877 which reads the keys of a keyboar similar to the original and executes Instructions.
So far displaying the stack works and all the floating point ops work (these come with the c compiler I am using).

Once my calculator works, the floating point single precision must be improved, perhaps with bcd-arithmet.

But it would be great if one could simply write a Microcode simulator, load it on the microchip, and provide all Functions in external EPROM.

Could that possibly work?

Greetings!

Yes, I think is possible. I'm trying to do the same, and to build a *new* calculator using *old* case/display/keyboard configurations (from HP-12C perhaps).

I have tried some keyboard/display routines on my PIC16F628 with success, but I don't have an emulator yet. I was thinking of a NUT CPU emulator or a Saturn one.

The emulation can be executed on a PIC, is only a matter of "stuffing" it on the very small amount of FLASH of it. The speed will be similar or a little slower than the original calculator speed.

If you need help I can contribute, but I only program PICs in assembler ;)

Best regards,

Nelson

Edited: 6 Apr 2004, 11:05 a.m.

Quote:
Has someone ever tried to run a simulator in Hardware?

Yes, I had the HP-45 microcode simulated on a PIC back in 1995. It was just a proof-of-concept, and was not 100% completed.

Since so many people have Woodstock calculators with bad
chips (due mainly to the terrible power supply design), I've been considering selling replacement logic boards for those. The main stumbling block is fabricating equivalents to the bifurcated contacts used for solderless connections to the display and keyboard PCB. I suspect that they are stamped beryllium copper with gold plating. I have not been able to find a commercial equivalent, and am not sure what it will cost to have them made.

Quote:
I am currently rebuilding a HP 67 Calculator using a PIC MICROCHIP 16f877

As you're no doubt aware, that uses the same ACT processor as the Woodstocks. Simulating it should be easy as long as you don't need the card reader to work.

Quote:
But it would be great if one could simply write a Microcode simulator, load it on the microchip, and provide all Functions in external EPROM.

Why wouldn't you just put the microcode in the flash memory of the microcontroller? I don't see any value to having it in a separate chip.

Hi,

Let´s just work together in order to awake long-dead HP Calcs to life.

I think it would be the best to communicate via email,
anyone who wants to help mail to :
khi1981@web.de

But please, do not leave us out of the loop here. Report back from time to time with news of your progress--there are many lurkers here who look forward to hearing what the superbrains are managing to do!


Best of luck with the project,


regards,

Bill

I am with Bill on this.

Please keep us informed and if anything becomes available I would willingly pay something for a copy.

Keep up the great work!

Hi to all interested!

This thread gets quite a lot of response. If anyone could provide webspace, I could publish my Hardware design and my Program for 32 bit float-precision (Still incomplete, but math works).
I can only speak for myself, but if the Microcode emulator should work, we could perhaps publish that too (If that's OK with everyone).

Klaus,

Thanks, but 32-bit floats are NOT as good as even a cheapie calc offers today, and most all of us expect a calc to deliver proper BCD math results: 10, [1/x], 10, [X] should give 10, not 9.999999999, which often happens even in higher-precision binary FP implementations!

Also 32-bit float likely has 24 bit mantissa w/implied sign; we have 3.322 bits per BCD digit (that is, 1/log(2)) so we have 32/3.322 = 7.2 digits of precision. Log/trig transcendentals using these functions even for range reduction will likely have problems too.

This is why many BASIC interpreters of the past on 8-bit machines (Commodore, Atari, Apple, etc.) used 5-byte floating point: 32-bit mantissa + an exponent byte: this allowed about 9.6 digits, which is somewhat better.

I'm much more comfortable w/HP's 10-digit BCD math, along with CORDIC transcendentals: very comfortable behavior.

I think if we start "updating" an HP calc w/new innards, we should emulate its instruction set/microcode. Any existing bugs can be trapped/fixed and we won't introduce new ones (if there were a problem in an emulator, it will not likely be a spot error but would most likely systemically affect use of an instruction(s), making the error readily apparent.)

Remember, the people who wrote the math routines knew a LOT about calculations, accuracy, error propagation and roundoff issues. And we have much more simulation horsepower available (they had to grab time on an IBM mainframe). Let's not throw that away - otherwise we're no better than HP + Carly + Fred Valdez + Kinpo.

Bill Wiese

San Jose CA

I suggest you use a PIC18f.. series chip, not a PIC16f...

The 18's a faster, have more low power modes and are much better to program. Banking/Paging no longer is a problem, and there are 3 file select registers.

I agreee on this: we should (at first) use an emulation of some CPU (Saturn) and use the well-tested routines for it (ripped from ...HP-42S??) to prove the concept, and IF we manage to build some decent calculator THEN we can optimize its code (non-emulation native 16 or 32 bits code???).

I was thinking in create a "new" CPU based on the best of the NUT, Saturn, Capricorn on an emulator, and using more register space (more precision, 16 digits? 18 digits internal?). This is not difficult, the worst part will be creating software for it (compiler, for a start). BUT it can be at first implemented on emulation and after the concept proved, implemented on FPGA or similar chip (full speed and power!!).

This are just my thoughts... I'll appreciate other ideas!

Best regards,

Nelson

Quote:
I agreee on this: we should (at first) use an emulation of some CPU (Saturn) and use the well-tested routines for it (ripped from ...HP-42S??) to prove the concept, and IF we manage to build some decent calculator THEN we can optimize its code (non-emulation native 16 or 32 bits code???).

I was thinking in create a "new" CPU based on the best of the NUT, Saturn, Capricorn on an emulator, and using more register space (more precision, 16 digits? 18 digits internal?).


Hah! Yes, it'd be fun to have HP41/42 features & routines inside a Woodstock case ;)

I don't think speed's too much of an issue anymore. With a TI MSP430 running at a reasonable clockrate (6-8 MHz), emulation of Nut, etc instructions should take only a relatively few clocks.

No need for FPGA. Besides, this allows us to use other kinds of memory w/software 'drivers' patched into interp.


Bill Wiese

San Jose

Hi to all HP-fans!

There were already some attempts to rebuild/create a better Calculator, but it seemed most ended in discussion on the forum.
I think we should do the following to begin with the project:

-Collect and read information about the technical issues and the general architecture
-Decide what we want to build
-Decide which hardware we want to use
-Start implementation!

If we differ in any point, we could split up in groups that exchange information. I think, we will never see any result if we keep discussing the hardware we want to use. Instead we could implement the Microcode Interpreter in Pseudo-Code (or C or PASCAL, whatever) and then groups could implement that high-level code on different hardware.
Anyway, before choosing a hardware, I would like to get an overview of all the possibilities that piece of hardware provides. Perhaps everyone should give a brief description of his favorite platform (Price, needed hardware, clock speed, interesting features).


I think, together we have a very big knowledge base, we only have to exchange our ideas and skills.

Let's start the project!

Greetings to all! Klaus

I agree, trying to recreate HP algorithms would require recreating the work of people like Prof. Kahan. I have deep respect for the technical expertise of this community, and think their energy would provide better results if applied to other areas (HW, emulation).
Having said that, I can say that an arbitrary precision FP library on a handheld calculator would be an interesting step beyond what has been done before by HP - see:
http://www.hpl.hp.com/personal/Hans_Boehm/crcalc/CRCalc.html


Oh God, it is a HP employee work....

Renato
(1234)

Yes, arbitrary precision is nice, but for a calculator it's much better to use decimal floating point rather than binary.

http://www2.hursley.ibm.com/decimal/

The actual IBM implementation can be downloaded but costs money for commercial use. The specifications are useful.

It yelds exactly 0 to 9-asin(acos(atan(tan(cos(sin(9))))))


Why would it matter if the implementation is binary or decimal ?


Renato
1234

Hi,

There are some decimal numbers (like 0.1) that cannot be represented by a finite binary numer.
But since any operation on non-integer values is inexact, the user should know the error and live with it.

Greetings, Klaus

Klaus,

Please try 1/3 * 3 on the constructive reals calculator.

Renato

Well, the user should trust no machines but use them only while using his mind too.

Of course bcd-calculations cannot be beaten by flp. But while people are constantly discussing details of projects I have a calc that is nearly finished. It can do sqrt, log, ln, e**x, pow, sin, cos, tan, arcsin,acos, atan, sinh, cosh, tanh, +,- *,/.
It will take half a year for me to do numerical approx. for all the functions, and I will do that after I have build my floating point calc, because I want to see some results of my work. Besides, I will have working key and display routines for the Bcd-calc.

If someoune had bcd-Routines for that functions or is willing to do some for me, we can start the bcd-calc immediately.

I really don't like all the discussion. We could build a machine doing all the calculation together, and then anyone could add his own display and key Routines.

I really hate these endless discussions about details without having started the Project. That doesn't get us any further.

I don't just tell anyone of building a calculator, but I do build one, and then I will improve it.

Only GOD can judge me and my Calc!


Salut! Klaus

Warning: This is just my opinion, I don't want to insult anyone !

Hi Klaus!


You are right though---making rather than dreaming is more fulfilling---will you send all of us dreamers photos of your proud accomplishments. That way, we can vicariously enjoy making real things, too! (And it is just that much more FUN to see a real project).


Best regards,

Bill


http://plattdesign.net

Hi Bill, Hi all,

Anyone who wants photo send me an email. After a close look over the Internet, I have decided that decimal arithmetic might not be so hard to deal with I first thought it would be. CORDIC seems to be a magic word. In the archives, there were almost no articles about that algorithms used in HP Calculators, but I would like to hear to hear some opinions about that.
http://my.execpc.com/~geezer/embed/cordic.htm

Greeting, Klaus