New HP-16C "tribute" web site.



#36

I've put together a modest web site to commemorate the HP-16C. It also serves as a distribution point for my (free) 16C simulator.

http://members.optusnet.com.au/~cbpaine/hp-16c/

The simulator software is of "beta" quality but visitors to this museum are welcome to try it out. I have no plans to commercialise it but I will continue its development until I consider it finished. I've been tinkering with it for two-and-a-half years now and I figure it's time to let others have a play with it. Hey, you might even find it useful.

My thanks to Paul Brogger, Luiz Cláudio and Raymond Hellstern for testing earlier versions of the software.

Cameron

PS to David (Hicks): once I get the version number above 1.0 (it's currently 0.211) you will be welcome to a copy for the museum's simulator/emulator page.


#37

#38

excellent! i really like the "classic" mode.

some things i noticed quickly tho' (windows version).
is there a way to use the keyboard for input. 0 ENTER 0 / (what does it give on a real 16c)?, 2 ENT .2 + .2 + .2 + .2 + .2 + 3 - isnt zero.

best of luck with the project!

Edited: 27 Apr 2004, 8:52 p.m.


#39

Cameron,

Great site indeed. Excellent emulator, to say the least. I also like the "classic" look and would like the keyboard input too. Suggestion: there should be some kind of save state mode so if user chooses the "classic" view, it always gets it on the program restart. Other things could be saved too like the window position etc.

To answer Hugh's question 0 ENTER 0 / gives Error 0, just like the emulator. And your arithmetic sequence IS zero if you are in the floating point mode. In decimal (or any other integer mode for that matter) it isn't as it shouldn't be. You really need the manual, as is stated in README file.

I am looking forward to the improvements. Now if someone would just do the same thing for 15C ;)

1234


#40

Thanks for the kind words Miki.

On the subject of keyboard input, perhaps you could read and comment on my reply to Hugh (above).

As for state saving--I sort-of concur. The calculator "engine" is decoupled from the user interface. The engine preserves its state just like the device I'm simulating. Window/scroll position is not something that gets preserved. The engine knows nothing of its UI so it cannot save UI state elements.

I have yet to build any persistence into the UI layer. I do plan to though. To date I've simply hacked the code to make the rendering I prefer the default. Since we have two "votes" for persisting the rendering setting, I think I'll do that next.

This does raise a question though. You don't find the classic rendering consumes too much of your windows display?

I ask because I thought I'd pinch an idea from Warren Furlow's HP-41 emulator and offer small and large classic views. The support for this is in the code--all I have to do is build the smaller bitmaps.

How small would you go? I can't crank it down too far because we'll lose the legibility of the keypad legends (and my artistic ability is too limited to do a convincing job of retouching them). I welcome you suggestions.

Cameron

#41

Thanks Hugh. You don't say what mode you have the calculator in but I'll assume you're familiar with the real thing.

In floating point mode, zero div zero produces an IEEE quiet NaN which I was simply converting for display. This is incorrect behaviour. I had overlooked the fact that this "special" case bypasses the FPU's div-by-zero handling. I'll trap this case in the next release. In integer mode zero div zero produces Error 0 (as does X div 0 in either mode if the dividend is non-zero).

Your 2 ENT .2 + .2 + .2 + .2 + .2 + 3 - calculation intrigues me. In the version you have, the displayed result is zero (in floaring point mode). However the value in X is actually 8.881784-16. You can get a hint that it's not zero if you do [f][PREFIX] while the result is in X.

The simulation (it's not an emulation) uses the IEEE FPU to do the floating point ops. I considered doing my own BCD FLOPS (and I may yet do so) but this would have taken the project in a direction that I haven't had the time or energy for.

I have an experimental routine that rounds out small "errors" in the display while maintaining the real value internally. I think I'm aware of the issues and arguments surrounding BCD vs binary floating point. Although math isn't my game, I understand (some of) the ramifications of binary FP representations and I'm not sure that hiding them is a good idea. However I would like the simulator to come close to the 16C.

Any thoughts? I'd like to know what you (and others) feel about this.

I'll turn the display rounding off in the next release.

Cameron


#42

hi Cameron,

my points were minor as overall the simulator is excellent.
here's how you fix the zero problem without BCD. change the top-level add & subtract routines to perform relative supression as follows:

add(a, b) = a + b or 0 if |a+b| < |a|*2^-k eg k = 40 for 12 digits. similar sub(a, b) = a - b or 0 if |a-b| < |a|*2^-k.
this is what i do, so does the hp9g.

best of luck with the simulator,


#43

Thanks Hugh. I've implemented your algorithm. I like the results. The new version's up on my site. I think that will tide me over until I have a lazy week to incorporate the IBM decNumber BCD routines.

Cameron

PS: did you ever work for infocom?

#44

You (and Miki) touch on a point that has bothered me for a while. On the PPC the keyboard is not an issue which is why I've not implemented anything. However, on the desktop, keyboard input presents a real design challenge.

I figure if you're going to use the keyboard you want to keep your hands on the keys. Therefore, all input keys and functions would need to be mapped to the keyboard. That's about 130 bindings.

I'm interested in your idea of what the mapping would look like. Is the mouse OK for some functions? If so, which functions?

TIA

Cameron


#45

On a previous message posted about a week ago, related to Eric Smith's Nonpareil emulator, I suggested some ideas about basic keyboard mapping for PC usage of HP calculator emulators. My ideas were mostly oriented to 4-level stack models.

Number entry (including decimal point) should work from the numeric keypad.

The four basic arithmetic functions should work from the numeric keypad.

Enter should work from the numeric keypad.

The minus key on the numeric keypad, in combination with shift, should act as change sign (CHS or +/-)

The cursor-down key should work as Roll Down. Optionally, cursor-up may work as Roll Up in appropriate cases.

Cursor-right should work as X<>Y (or SWAP).

Cursor-left may work as CLx. Veli-Pekka Nousianen suggested that the main keyboard Backspace key may be a better choice, and I think he may be correct, depending on individual choices.

The preferable manner to handle these issues is to have an editable "PC keyboard to calculator-key" mapping file, because there may be issues with international PC keyboard layouts (for instance "<" and ">" or "," and "." are some of the keys that change from one layout to another); and there is also a case for notebooks, which do not have a separate numeric keypad.

With these considerations, at least the basic calculations could be handled with little or no mouse usage (with the hands on the keyboard, that is). However, less intuitive assignments or mouse clicking will be needed for specific functions as logs, trigs, stats, etc.


#46

I like these suggestions. In addition, the letters a through F should correspond to the A-F keys on the HP-16C, since hexadecimal input is frequently used.


#47

Thanks for the suggestions Andrés and Victor. They've now been implemented.

Cameron

#48

Hello, Cameron;

based on what you've done to accomplish the excellent emulator, I can only guess your site will succeed as well.

Also, thank you for mentioning my name. It's been a priviledge being one of the Beta testers.

I hope you keep doing the wonderfull job.

Best regards.

Luiz (Brazil)

#49

Very nice website and nice emulator as well, Cameron. I haven't had a chance to play with it much yet, but I plan to.

One thing you might look into is to make the 'views' sticky. I like the "classic" view. Not too much trouble to click a menu to get to it, but I would like for it to default to classic.

Super nice job.

John


#50

Thank you John. I hope you find it useful (or at least amusing ;-).

On the subject of sticky views, you've offered the second "vote" for view persistence. I'll do that for the next release.

Perhaps you could also read my reply to Miki (above) and share your thoughts about the size of the classic rendering.

Cameron


#51

Hi Cameron:

I have a pretty high resolution screen -- 1400 x 1050, so the current classic size is pretty good for me. Having said that, I can see where a slightly smaller version would be useful for screens with less resolution. (Of course with my old eyes larger objects are useful <G>)

John


#52

I have a beautiful screen using Sony F-520 21" monitor in 2048x1536 resolution.

A slightly bigger version would preferable.

[VPN]

#53

Quote:
...you've offered the second "vote" for view persistence. I'll do that for the next release.


so, I will avoid to ask the same thing :-)

Thanks for your work, Cameron.

Raul

#54

Wow,
really great work. I was really missing a HP-16c simulator, now I could leave mine at home (sometimes).

Font
I noticed that the font is not exacly the same. Is there someone that could provide a [even] better one?

Classic view
Could you draw the form without the border and Title?
I have mostly 1024x768 displays and I LIKE classic view. Please make available a 1024x768 version! :)

Emulation
Pressing 'f' function lights the 'f' annunciator, but pressing again should not hide it. Same as above for 'g'.
Am I wrong?

Keyboard
You will use mostly with the mouse, but using the mouse for number entering is slow and weird sometimes.
Just very basic stuff, like '0..9','a..f','.', clx/BSP basic operation and enter. Other bindings could be defined, as long they don't cause problems.

Known issue
Sorry but I don't uderstand what is not fixed, I would rather prefer a single repository.

Your work is really appreciated.


#55

"Emulation Pressing 'f' function lights the 'f' annunciator, but pressing again should not hide it. Same as above for 'g'. Am I wrong?"



Tested on a real HP-16C, the second press on f or g just leaves it on. You may change from f to g or vice versa.

[VPN]


#56

So I found a bug into the emulator...or is the Hp-16C in error? :)

The emulator should follow the original anyway...


#57

Giuseppe and VPN have me laughing out loud. I'll let the source code tell the bulk of the story:

  if (compatible(SHIFT_KEYS_STRICT))
{
// On the real 16C, the shift keys would toggle each other's state
// so you had to use the (gold-shifted) PREFIX function if you
// wanted to clear an inadvertant shift. Assuming that we've got a
// handler for PREFIX installed, that's the behaviour we're modelling
// here.
shiftState.gold = key == KEY_GOLD;
shiftState.blue = key == KEY_BLUE;
}
else
{
// It always puzzled me why an inadvertant shift couldn't simply be
// cancelled by either pressing the same key again, thereby releasing
// the latch, or by pressing the other shift. I guess the latch must
// have been hard-wired in some way, in which case the PREFIX function
// was an ugly kludge. Since this is software, we can be much more
// flexible. Pressing the key toggles the latch. Which introduces a
// different problem: it's then possible for both shifts to be latched
// which we really *do* *not* want. So, to be safe, we toggle the one
// that was pressed and we clear the other.
if (key == KEY_GOLD)
{
shiftState.gold = !shiftState.gold;
shiftState.blue ^= shiftState.blue;
}
else
{
shiftState.blue = !shiftState.blue;
shiftState.gold ^= shiftState.gold;
}
Note the test for SHIFT_KEYS_STRICT? One day there will be a options page that allows you to toggle a small set of behaviours between "strict" (exactly like the real thing) and "loose" (my view of what would be a better way). Until I bind the options to a UI element I have default values that suit me. Developer's privilege ;^)

Now that I have your attention, should I implement the right-scroll bug? (I'll be chuffed if anyone knows what I'm talking about--is that the sound of 100 16C's being slid from their vinyl wallets?)

Cameron

PS: Giuseppe, thanks for noticing. :^)

Edited: 28 Apr 2004, 11:37 a.m.


#58

Cameron,
this is a issue I know for sure deserves many attentions.
On one hand, I do like an emulation as real as possible (BTW, does the battery indicator...joking), on the other hand we are not tied to old problems.
Anyway, I do like emulation because they can revive the real thing, so emulating it, with all the defects, make it a better emulation.
When it make sense, sure improve/fix it, just make it user switchable.

I don't know much about the 16C, but if the right-scroll bug would make a 16c program behave differently, I would like to experiment the same behavior.


#59

Giuseppe, it's funny that you should mention the battery indicator--I flirted with using it on the PPC. I can't find an API that will give me the battery level though. They have one--there's a standard M$ screen that shows the level.

Seriously though, my desire for the sim is to simulate the behaviour of the real thing as closely as possible. From my POV it's a document of the state of technology at a point in history. However the software is a work in progress and I felt like sharing it with people before it was complete. There is also the practical limit of how much time I can spend on it. Originally I hoped to have it complete for the calculator's silver anniversary. The way I'm going it might just be ready for the gold jubilee.

As for the right scroll "bug". I can't think of a way of exploiting it. I surmise that HP used two nybbles for the scroll position counter. They only needed 6 bits but they didn't range-check or mask the result. Consequently there are 256 scrolling positions. If you work at it long enough you can scroll a number off the right side and back on the left.

Should I implement something like that? How about the 68-bit index register. In the real calculator it renders the ISZ instruction next to useless since the wrap-around that causes the skip happens nowhere near where one might expect it to. Should I implement that?

Last week I would have said yes to the index register and no to the scroll behaviour. But several posts in this thread have caused me to re-evaluate my position. I'll continue to do so.

Throughout the code I have comments tagged with COMPATCHECK. Many of these will be turned into a user-configurable option. In this way we have both a document of the past and a tool that is (slightly) more useful today.

Cameron

#60

I agree with you that HP made a mistake with sticky function keys. It is one of the very few things which has annoyed me on my 11C ever since I bought it in 1983.

The HP-71B has toggle function keys - so the designers at HP fixed that 'bug' on their last "super-voyager".

I vote for keeping the functions keys as toggles until the options are implemented.

I like the classic view and a smaller version, linear reduction by about 2/3 would be useful in addition to the one you have now.

Should the ON key turn it off? or close it down like File Exit? I haven't made up my mind.

It is a great piece of work and keep it going...


#61

"Should the ON key turn it off? or close it down like File Exit?"



OFF



Everything should as the real thing!

You could include Options

Reset All
Set All
Scroll Right Fix

Shift Toggle Fix

...



[VPN]

#62

Hello!

The font is rendered using GDI routines. The PPC doesn't support 2D transformations or sideways fonts. It also doesn't have the dot density to do justice to the slightly slanted LCD segments on the real 16C--whether they're rendered with a font or with the GDI. So, I compromised.

Classic view without window decoration (title and menu bar) is in the works. The only thing that's really holding it up (aside from the enemy of us all--time) is the fact that I'm working on the context menus for the PPC. Until I finish the menus I can't afford to get rid of the decoration.

Would you like that 1024x768 version in 24-bit colour? David has a truly beautiful 1627 x 1171 image on the museum CDs. I wonder if he'd let me use it?

As for the shift keys, you're absolutely right. See my response below.

Thanks for your suggestion about the key bindings. That makes sense. Did you ever use the MS-DOS XACT-16C simulator back in the '80s? It had an abomniable mapping that treated a 4 x 10 block of keyboard keys as the calculator keys. It was almost impossible to drive.

Cameron


#63

Cameron,

As for the window size, there are different opinions here depending on the screen resolution people have. I don't think that you should go out of your way and provide 5 different sizes to suit everybody. Your WOFTAM can be spent elsewhere improving this product.

If I may suggest the following key bindings:

Yellow (f) functions to <shift> keys described below, blue (g) to <ctrl> keys.

All the numbers to numbers on PC, A-F also to A-F on PC, same for the 4 basic arithmetic operators as well as for Enter and BSP. HEX, DEC, OCT and BIN to F1-F4 on PC. RDN to down arrow (RUP can go to up arrow), X<>Y to either left or right arrow (or both). STO to S and RCL to R. Now this leaves out GSB, GTO, R/S and SST. In a lack of better suggestion they can go to F5-F8, retaining 'compatibility' with V41 by assigning SST to F6 and R/S to F8.

My 2c worth.

1234

Edited: 28 Apr 2004, 1:06 p.m.

#64

Hi, Luiz Claudio has produced a .ttf file of the Voyager display, I will email it to you if you contact me, I know Luiz would be pleased to have his font included into your simulator, if it can be used.

However this is not a criticism of your existing display which is nice and clear.



Luiz - have you recently changed the Voyager font??


#65

Hi Gordon, folks;

I made som echanges in some existing fonts, but I am quite sure that the Voyager TTF is still the same. I don't remember changing it, and if I did so, I'm sure it was not any structural change. BTW, did you try to download it and found any trouble? Let me know if any.

About using the font in Cameron's emulator: I make Gordon's my own words, and I thank you, Gordon, because you actually got the "spirit": anyone can use them, mostly if good HP related "stuff" is the issue. Anyway, should the font need changes (character dimension, maybe) in order to fit in your emulator's LCD window, just let me know, Cameron. I'd gladly change it as well, my pleasure.

Gordon, I'm posting an answer for you at the new TTF thread, O.K.?

Best regards, folks.

Luiz (Brazil)

Edited: 28 Apr 2004, 11:38 p.m.

#66

"Would you like that 1024x768 version in 24-bit colour? David has a truly beautiful 1627 x 1171 image on the museum CDs. I wonder if he'd let me use it?"



Directly using that 1627 x 1171 image would be great!!

Thank you in advantage..erh..advance
[VPN]

#67

In case anyone's interested: Cameron's emulator works under Linux (using Wine). It looks and works great. I've been wanting something like this for a long time. Thanks, Cameron!


#68

Thanks for trying that and sharing the results with us Wayne. Perhaps you could give the new version a run too? It sounds as if wine may have come a long way since I last looked at it. What do you run it on?

Cameron


#69

Cameron,
take a look at www.codeweavers.com too, you'll be impressed.

#70

I haven't had time to give it a full run-through, but it looks good right now. As far as I can tell the keyboard mapping seems to be working just fine and I haven't found any other problems either.

I'm running it on an IBM ThinkPad 600X with a very old Slackware installation that initally came with kernel 2.2.16. However, I've upgraded bits and pieces of it over the years to get it to kernel 2.4.21-pre1. (At that point I decided that it would be easier to reinstall a whole new version from scratch than to keep upgrading in pieces. Some day I'll get around to that. :-) My version of Wine also is old -- 20020605 -- but I use it only for a very few applications, and I'd need to upgrade some other things before bringing it up to date, so as long as it keeps working for me, I'm satisfied.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Bought a 16C to compensate a little Eelco Rouw 23 2,596 12-07-2013, 01:26 PM
Last Post: Eelco Rouw
  Shiny new 16C! Keith Midson 7 931 10-27-2013, 02:22 AM
Last Post: Keith Midson
  Joys of eBay: HP-32S, HP-32SII, HP-42S, HP-16C, ... Sasu Mattila 7 898 09-23-2013, 04:39 PM
Last Post: Julián Miranda (Spain)
  OT: a math competition site Pier Aiello 0 353 09-16-2013, 06:03 AM
Last Post: Pier Aiello
  WP-34S on German Auction Site Joerg Woerner 3 670 09-08-2013, 04:36 PM
Last Post: Maximilian Hohmann
  EMU71 on a web page! hugh steers 13 1,333 07-14-2013, 12:47 PM
Last Post: Namir
  HP-16C simulator fhub 12 1,264 06-30-2013, 10:14 PM
Last Post: Robert Prosperi
  Jacques Laporte's Fantastic Site BShoring 3 644 06-15-2013, 08:36 AM
Last Post: aj04062
  10C, 11C, 12C logos on The Auction Site Peter Murphy (Livermore) 0 361 06-14-2013, 11:24 PM
Last Post: Peter Murphy (Livermore)
  Program for HP-16c... Leonid 9 1,015 06-07-2013, 08:51 PM
Last Post: David Hayden

Forum Jump: