Nonpareil status

[Mark H. Shin]

(11-01-2022 01:27 AM)brouhaha Wrote:  The 12C self-test issue was definitely the C<>G instruction when pointer=13, as m-stgt commented in the issue on Github. I've changed Nonpareil to handle the pointer=13 case in the way the David Assembler ROM describes it, for the case where the pointer wasn't changed to 13 in the immediately previous cycle, and that seems to have fixed it.

Excellent!

(11-01-2022 01:27 AM)brouhaha Wrote:  There was a second problem with self-test, in the ON-divide keyboard and LCD test. Extraneous segments were being turned on.

(Edited) Keyboard test on nonpareil 12C (Bartosiak release based on Nonpareil 0.77) fully functioning as expected with display segments for each key conforming to the real 12C exactly. No extra annunciators.

P.S. If you should require a 12C, I have an extra which I would donate to the cause...

[brouhaha]

I went back to Nonpareil 0.78 and verified that the 12C self-test passed without showing extra segments and without changing the BEGIN and D.MY indicators. Particularly interesting is that the old code appears to have had the low six bits of both LCD bitmap registers as read/write, with the low 6 bits not having been dealt with in any special way, and that the C<>G operation does not seem to occur with a pointer value of 13. Clearly I need to do further analysis of what's going on. I reopened the issue on Github.

[brouhaha]

As part of adding more Topcat models (91 and 92) to Nonpareil, I've revisited the graphics I used for the 97, which I wasn't very happy with. The new and old graphics are the fourth and fifth images in this album of Flickr (click on them to see them at "actual size"):
[EDIT 2022-11-17 - the old Noppareil 97 graphics is no longer in the album]

https://www.flickr.com/photos/_brouhaha_...0303041763

The new graphics could still use some tweaking, especially for the positioning of the shifted function legends for the big keys, but I think it's an improvement. This sort of pixel-pushing really isn't my forte. Ideally Nonpareil should use SVG files instead of bitmaps, to allow sizing the window as one pleases, but I'm even less good at that..

The printer and paper advance button are not show in the main window, because there's a separate printer window. Although the printer window doesn't look very pretty, it can be resized and scrolled, and allows the printout to be saved as a .png image.

[brouhaha]

I completed the 91 graphics. I also fixed the problems with trace mode on the 19C and (in development) 92, which also affected the 91 if the angle mode was GRAD. I'd forgotten to have the S0 flag output drive the KE input of the ACT key scanner, which the hardware uses to ensure that there's always a pseudo-keystroke available when the slide switches are read. This also fixed a problem where a financial calculation example on page 30 of the 92 owner's handbook was hanging.
The updates are in the github repo.
I need to do the graphics for the 92, and then it may be time for a new Nonpareil release.

[brouhaha]

As I inch toward a new release of Nonpareil, the github repository now contains the graphics for the 92, as well as improvements to the graphics for the 19C, 21, 22, 25/25C, 27, and 29C.

Nonpareil currently does not build for Windows, because I switched from the deeprecated glib GTimeVal to using POSIX CLOCK_MONOTONIC for simulation timing. I'll try to address that in the near future; there's a Windows API to provide equivalent functionality, QueryPerformanceCounter in profileapi.h. Once it builds and works on Windows again, I'll probably release it as Nonpareil 0.80.

I've been experimenting with implementing a subset of Nonpareil in C++ using Qt, and the first hurdle was creating a suitable push-button widget, as the standard Qt QPushButton and QToolButton didn't really meet the requirements of Nonpareil. (That was the case with the standard GTK2 button also.) Fortunately Qt has a QAbstractButton that I was able to subclass to get most of the behavior I wanted. While I think that I'll eventually base a future release of Nonpareeil on this rewrite, that's pretty far out on the horizon. In the mean time, I might release an experimental program that only simulates one calculator, possibly 25C or 29C.

I'm also working on using scalable graphics (SVG) instead of bitmaps, to allow arbitrary resizing of the window, but that's probably a bit further out, and I expect the first test for that will be the 12C.

[Didier Lachieze]

Thanks. Great to see progress toward a new release of Nonpareil !

[brouhaha]

The new graphics for the 19C, 91 and 92, and the latest versions of several others, can be seen in this flickr album:
https://www.flickr.com/photos/_brouhaha_...0303041763

[rprosperi]

(11-16-2022 06:33 AM)brouhaha Wrote:  The new graphics for the 19C, 91 and 92, and the latest versions of several others, can be seen in this flickr album:
https://www.flickr.com/photos/_brouhaha_...0303041763

You may not like pixel pushing, but I'd say the results are rather nice. That includes a very nice rendition of a not so great original, the HP-70! While I can't go all the way to ugly, seeing this version makes it soo clear just how stark the original color 'scheme' (if you can call it that...) was. Looking forward to the release when it's ready. Thanks Eric!

[brouhaha]

(11-16-2022 02:07 PM)rprosperi Wrote:  You may not like pixel pushing, but I'd say the results are rather nice.

Thanks! Much of the credit for that should go to Maciej Bartosiak, who ported Nonpareil to MacOS, and contributed graphics in this style. Originally Dave Hicks made his photographs available for me to use in earlier releases of Nonpareil, and I was and am grateful for that, but I feel that stylized illustrations are generally better suited for simulation.

I have since made derivatives of Maciej's graphics for additional calculator models, including the 10C, 19C, 31E, 70, 91, 92, and 97.

[Mark H. Shin]

I noticed in your GitHub repository, you've create 10c.ncd.tmpl file showing the segment mappings for the 10C.

Were able to determine the actual mapping (reg/bit) for the unused annunciators?

They would need to have a mapping since all are displayed after self-test.

[brouhaha]

(11-19-2022 04:19 PM)Mark H. Shin Wrote:  Were able to determine the actual mapping (reg/bit) for the unused annunciators?

No, I haven't done that yet. I don't have a 10C. A friend in California has a 10C which, years ago, he was willing to make available for ROM dump, but it was the original flex-circuit-and ESD-film version which is hard (at least for me) to probe. Since someone has since dumped the 10C ROM, that's no longer necessary, but that was also how I was going to figure out the display mapping.

If someone shot a video of the HP-10C keyboard/LCD test, so we could see the segments active at each step, we might be able to figure it out non-invasively.

If the LCD self-test for the 10C uses the same register bit patterns as that for the 12C, then it doesn't cover register 9 bit 6 and register 10 bit 6. On the other Voyagers, those are BEGIN and RAD. On the 10C, those appear to be the "G" annunciator (not "g"), or whatever the 10C has in its place, and the middle segment of the third digit from the left (not counting the leftmost negative sign). We should be able to identify the bit positions of all other segments, through.

Perhaps also someone with a 10C could take a photo of the all-segments-on display at the end of the ON-multiply self-test.

[Didier Lachieze]

Here is a video showing the ON-divide keyboard self test executed on a well battered HP-10C, it shows also the low-battery asterisk flashing at the bottom left of the display: https://youtu.be/HZhkCVnKF_g

[Mark H. Shin]

(11-20-2022 03:01 PM)Didier Lachieze Wrote:  Here is a video showing the ON-divide keyboard self test

Thank you for the video...

Unused Annunciator Mapping for 10C:

Code:


ANNUNCIATOR    (REG, NIBBLE, BITMASK)
---------------+----------------------
USER               (10,12, 4)
g                  (10, 4, 4)
BEGIN              (10, 5, 1)
D.MY               ( 9, 2, 4)
C                  ( 9, 3, 4)

[brouhaha]

I'm planning to convert Nonpareil to using SVG graphics for arbitrary scaling, but that's still a way off. I recently learned of Iván Izaguirre adding a "--big" command line option to scale up the Nonpareil graphics by a factor of two for HiDPI displays. I'd been thinking about hacking that up myself, because my main monitor is HiDPI, but hadn't gotten around to it, so it was a pleasant suprise to find that Iván had laready done it.

I've adapted that in the main Nonpareil Github repository as "--scale <n>", for n from 1 to 4,

[brouhaha]

There's been a long-standing bug in Nonpareil, with use of memory on the HP-55 not working properly. I haven't looked at it since 2005, but it's been bugging me. I just discovered that Greg Sydney-Smith analyzed the problem and came up with a fix for his own simulator in 2018:

https://www.sydneysmith.com/wordpress/20...lator-bug/

I've updated Nonpareil and the 55 registers and statistics seem to work properly now.

It seems very odd that the 55 uses a mix of one-digit and two-digit addressing, distinguished by C[0]. The secondary ("dot") registers R.0 through R.9 are RAM addresses 0 through 9, and are addressed using BOTH methods at different points in the microcde. Apparently the RAM chip (1820-1393, possibly also the earlier 1820-0993) were designed to do both. Now I'm curious as to whether the 45, 46, 65, 70, and 81, which AFAIK do not use two-digit addressing, always select RAM with C[0] = 0. That's not something I'm going to study right now. Nonpareil implements this only for calculators which are defined (in the .ncd compressed XML file) with arch="Classic" and arch_variant="1", which is only the case for the 55.

[teenix]

I recall having problems with the HP-55 code listing and the (dot) addresses, but I still use (regC[12] * 10) + regC[11] as the RAM address calculation.

Some time ago, I found errors in the HP-55 and HP-65 microcode listings and modified them to run in the Teenix emulator, but I cannot recall what I did. I do remember I needed 5 instructions to solve the 65 problem, and funnily enough there were 5 spare ROM locations that I could use.

cheers

Tony

[brouhaha]

I can't say with absolute certainty that Greg's analysis of the problem is correct, but his solution seems to good results in Nonpareil. It's possible that this is compensating for some other flaw, such as an incorrect ROM listing.

I'll add to my long list of research projects:

• dumping the 55 ROMs, to compare with the patent listing
• capturing logic analyzer traces of the 55 doing RCL/STO operations on regular and "dot" registers, Sigma+, and program step entry.
  

[brouhaha]

Christine Hall, @BrideOfLinux@mastodon.opencloud.lu, tooted a link to an article 10 Best Free Linux Calculators. When I saw the toot, i was ready to flippantly reply that I may be biased, but Nonpareil is the best calculator for Linux. It's a good thing I read the article first, because Nonpareil was actually listed as number 10!

I really need to update the README and build instructions. Nonpareil supports quite a few more calculator models than it used to.

[agarza]

(01-08-2023 10:24 PM)brouhaha Wrote:  It's a good thing I read the article first, because Nonpareil was actually listed as number 10!

Nonpareil is my #1 calculator on my linux machine!

[brouhaha]

I'm not sure whether I'll build a new release of the current Nonpareil code base. I've been very frustrated with the bitmap (PNG) graphics, which don't scale up well other than by integer multiples. I've long wanted to use SVG (Scalable Vector Graphics) files instead. I also wanted to switch to using the Qt6 toolkit (which has some SVG support), instead of GTK+ 2. Updating to GTK+ 4 is harder than I expected, and I don't want to put time into that. Of course, using Qt6 generally requires programming in C++ or Python, so in order to make this all happen, I embarked on a major rewrite in C++, which will eventually be Nonpareil 2.0.

I've worked on two separate parts, the simulation core and the user interface, but so far I don't have them actually tied together, as I've been debugging them independently. At first I reimplemented the bitmap graphics user interface, and had that working with Qt6, but since I'm not satisfied with bitmaps, I started working on redoing it using SVG. Eventually I'll have to write the glue layer that interfaces between the simulation core and the user interface.

The most difficult part of the user interface so far has been that, while an SVG file is XML, and while the QSvgRenderer loads the XML into memory in something basically like a DOM, Qt6 doesn't provide any interface whatsoever for the client to modify, or even examine, the DOM.. I expected to do automatic color value adjustments to lighten keys for mouse hover, and darken them for mouse click, like in my GTK+ and now Qt6 bitmap interfaces, but I thought I'd just be able to tweak an attribute in the already-resident DOM and call update(), and that's not possible. (Short of hacking Qt6 itself, which is a recipe for disaster.)

I wasted some time trying to use a QGraphicsEffect, which can apply effects to painting, which is the low-level operation that all Qt rendering, including QSvgRenderer, goes through. There's an underlying QPixmapFilter class to do transformation like convolutions on the pixel data. Unfortunately the QPixmapFilter class was public in Qt 4.8, but is private in Qt 5 and later. Also QGraphicsEffect doesn't publicly expose the ability to install a QPixMap filter. This seems awful. Nevertheless, I wrote my own subclass of QGraphicsEffect, and had it almost working.

If I use one of the standard effects Qt6 provides, like QGraphicsBlurEffect, it seems to work correctly even with the QSvgGraphicsItem. but if I use my own custom QGraphicsEffect, the rendering of the "source" pixmap for the filter (from the SVG) is at lower resolution than the display. There are choices for device coordinates or source coordinates, but neither seem to do the right thing.

Anyhow, I've set that aside and taken another approach. Previously I had the QSvgRenderer load the SVG file for the whole calculator, and then I use that same QSvgRenderer for all QGraphicsSvgItems. You can tell a QGraphicsSvgItem to render only a particular subtree of the SVG file, so I have subtrees for the base, overlay, all the keys, and various display elements, and all were using the same QSvgRenderer from the same XML file.

I've changed it so that I read the SVG file into a buffer, then load it into an XML file, and update the button style attributes for the different colors, and write SVG back to two more buffers, which then get loaded into two new QSvgRenderers, one for hovered-upon buttons and one for clicked buttons.

Now the code that changes the button state just changes the button's QSvgRenderer and calls update().

Geez, this has been a huge amount of work, but I've finally getting somewhere.

I still have more work on the display in SVG, and in making a halfway-decent looking SVG file. Last year I paid an artist to produce a good 12C SVG file for me, but we got into a dispute over the contract terms regarding the license of the work, so now I can't use it and am just out the money, which fortunately wasn't a huge amount. So now I'm trying to put together my own, which won't be quite as pretty, but should be at least as good as the old Nonpareil bitmaps.

Oh, and I still have some work to do to get it to render text in the font I want. I can't depend on particular fonts being present on the user's computer, and I don't want to install fonts, so I want them embedded in the SVG. But QSvgRenderer does not support embedded fonts, so I have to do another bit of manipulation on the SVG loaded into memory, extract the font, and hand it off to the QFontDatabase.

I hope to have in a few weeks a UI prototype ready to offer to folks that might want to try it. The simulation won't be hooked up.

Once I have working SVG files for all of the supported calculators, I plan to remove the bitmap (PNG) support entirely.