inst182@tuvie (Inst.f.Techn.Informatik) (02/09/90)
In article <364@images1.Waterloo.NCR.COM> john.Latala@Waterloo.NCR.COM writes: >It would be nice to get the functionality of the HP28s only with a >larger screen, let's say on a PC.... I am writing a program which emulates the HP28. It will be released to the public domain when it has reached a reasonable stage. I have, however, little time, so it could take a long time. So, how if I posted the skeleton that exists already, so that everybody could try it out and find out what functionality he/she/it needs most. Some volunteers could then help me implementing it. By the way: I use Turbo C 2.0, but I think I have not used any `special features' yet (except prototyping and in two functions used for debugging) > >-- >john.Latala@Waterloo.NCR.COM _______________________________________________________________ | __ | Peter J. Holzer | | | | \ | Technische Universitaet Wien | | |___|__/ | | | | | | hp@honey.tuwien.ac.at hp@vmars.uucp | | | | | ...!uunet!mcsun!tuvie!asupa!honey!hp | | ____/ |--------------------------------------------------| | | Think of it as evolution in action -- Tony Rand | |____________|__________________________________________________|
inst182@tuvie (Inst.f.Techn.Informatik) (02/27/90)
Hi, everybody! About two weeks ago I posted to comp.sys.handhelds that I am writing a HP28 emulator. I got some replies by now and this article is an answer to all of them. First of all, the term "emulator" I used seems to have promised too much. I am NOT emulating the saturn CPU but the high level features of the HP28. This has of course the disadvantage that all the fancy sysevals won't work (they aren't the same on the different models anyway), but you get a larger screen, better graphics, more memory, more speed (I doubt that a CPU emulator would be as fast as the HP28 even on a fast AT)... The main reason for not writing a CPU emulator (I considered it before I started) is that either every user would have to load the entire ROM of the HP28 (128k!) into his PC (not everybody has an IR receiver on his PC) or the ROM had to be distributed with the emulator (I am not sure if HP would like this). The next question was, how much of the program does exist by now? The interpreter is finished, so all the normal programming features (IF, loops, local variables, calling other programs) work. The data types implemented by now are real (IEEE double, not BCD), complex, binary (only 32 bit) with some of the operations. Strings and lists exist, too, but they aren't of much use yet. Arrays will be added next. No algebraic types yet, sorry. I have not even decided how to represent them (Just the same as programs, just with a different magic number, would be best, I think). User interface: The current UI is a rather ugly command line interface. I plan three windows (Stack, output, edit) and a menu bar so that the commands most often needed can be selected by function keys or mouse. Portability: I am not sure how portable my code is. I tried porting it to UNIX, which didn't work without greater changes (cc does not like the prototypes (It does not complain about them, but ignores them) and gcc misses many include files and the math library), but it should work with a properly installed ANSI compiler (except for some debugging routines). After adding the UI, however, there will be a lot of Turbo-Cisms (graphics) and hardware-dependency (mouse) in it. I will now fix up a few things, write a short documentation and then post everything to comp.sources.misc, so that you folks can play around with it and tell me your opinion. greetings, Peter. PS: PLEASE, if you send me mail, do NOT REPLY to the address in the header (tuvie!inst182, which is our institute's account on the newsserver, and our sysop doesn't like guessing who the mail could be for (although he is good at it :-) but to one of the addresses below (I don't know which of them work :-() _______________________________________________________________ | __ | Peter J. Holzer | | | | \ | Technische Universitaet Wien | | |___|__/ | | | | | | hp@honey.tuwien.ac.at hp@vmars.uucp | | | | | ...!uunet!mcsun!tuvie!asupa!honey!hp | | ____/ |--------------------------------------------------| | | Think of it as evolution in action -- Tony Rand | |____________|__________________________________________________|
alonzo@microsoft.UUCP (Alonzo GARIEPY) (03/06/90)
In article <1143@tuvie> inst182@tuvie.UUCP (Inst.f.Techn.Informatik) writes: > (I doubt that a CPU emulator would be as fast as the HP28 even on a > fast AT)... You could build a Saturn emulator that would blow the socks off the HP28. They call it a 1MHz machine, but that doesn't say much about the instruction timing. Someone recently claimed that the 28 has a one bit memory bus, which I am inclined to believe. At best, it has a 4 bit memory bus and a 4 bit register bus. With a 16 bit 286 running at 16 MHz, you would have 64 times the speed. That is easily enough to emulate the Saturn at several times the speed of the 28. I have been thinking about doing this. For one thing, it would greatly ease the task of understanding how the hardware (interrupts, display, etc.) works. You are right about the copyright problems with the ROM, but you could get into the same waters by duplicating the look and feel. Since a CPU doesn't have a look and feel, a Saturn emulator allows anyone who owns a 28 to run the software on their PC by downloading the ROM. I look forward to seeing your program. alonzo
daver@guille.ECE.ORST.EDU (Dave Rabinowitz) (03/07/90)
>> (I doubt that a CPU emulator would be as fast as the HP28 even on a >> fast AT)... > >You could build a Saturn emulator that would blow the socks off the >HP28. They call it a 1MHz machine, but that doesn't say much about >the instruction timing. Someone recently claimed that the 28 has a >one bit memory bus, which I am inclined to believe. At best, it has >a 4 bit memory bus and a 4 bit register bus. With a 16 bit 286 running >at 16 MHz, you would have 64 times the speed. That is easily enough >to emulate the Saturn at several times the speed of the 28. It might help to compare apples to apples. The "1MHz" number refers to bus operation speed, not system clock speed. If I remember correctly, the CPU clock on a "1MHz" Saturn processor runs at 8MHz (alternately, a 16MHz 286 machine typically gets 2 bus cycles/microsecond), so the raw clock speed differs by only about 2:1. The fastest Saturn instruction takes 2 bus cycles and the slowest takes fewer than 25 and manipulates a large number of bytes of data in its execution, so you're not likely to get much if any speed advantage emulating the processor on the fastest 286 system. When the CPU architecture was first defined a software emulator was written to allow programmers to play with the architecture, develop basic algorithms and come up with suggestions for change before the design was frozen in silicon. The emulator ran on an HP-1000 system, a 16-bit minicomputer with a 1.2usec instruction time, and was much slower than the first CPU chip, which had a 2usec bus cycle.
alonzo@microsoft.UUCP (Alonzo GARIEPY) (03/08/90)
In article <52051@microsoft.UUCP> I wrote: > With a 16 bit 286 running at 16 MHz, you would have 64 times the > speed. That is easily enough to emulate the Saturn at several > times the speed of the 28. I was not suggesting that the *emulator* would run 64 times faster than the 28, just several times faster, on average. Portable C would be nice, but hand-optimized assembler is probably the only way to go. I would appreciate a look at the source code of any existing Saturn emulators. We have a virtual cpu emulator here at Microsoft that uses some very clever tricks to get optimal performance. I have no doubt there is room for some of the same in emulating the Saturn. The suggestion that each field variant of an instruction might require separate emulation is well taken. The best approach may be to generate the code for all these variants mechanically. Alonzo Gariepy alonzo@microsoft