Nonpareil status

[brouhaha]

These are notes on the CRC reverse-engineering that Jacques Laporte and I did back in 2007-2008.

The CRC chip (Card Reader Controller) has twelve flags, which we've numbered 0 through 11. Our numbering may not match HP's internal numbering, which we were not privy to. Each flag has a set instruction, and a test-and-clear instruction (like the HP-41C FS?C), except that flag 0 can only be tested. Five of the flags control and monitor the card reader hardware:

* 0 buffer ready
* 7 data valid
* 9 motor enable
* 10 card inserted
* 11 write mode

Four of the flags sense other hardware inputs, of which only one is used in the 67:

* 1 PRGM mode (67/97)
* 2 printer MAN mode (97), unused (67)
* 3 printer NORM mode (97), unused (67)
* 4 keyboard sensing for SST, BST, R/S (97), unused (67)

The other three flags appear to have no dedicated hardware function, and exist for the convenience of the person writing the microcode. The 67/97 use those for:

* 5 MERGE
* 6 PAUSE
* 8 display-related

The octal encodings of the instructions are:

0100 crc fs?c 0
0200 crc sf 1
0300 crc fs?c 1
0400 crc sf 2
0500 crc fs?c 2
0600 crc sf 3
0700 crc fs?c 3
1000 crc sf 4
1100 crc fs?c 4
1200 crc sf 5
1300 crc fs?c 5
1400 crc sf 6
1500 crc fs?c 6
1600 crc sf 7
1700 crc fs?c 7

0060 crc sf 8
0160 crc fs?c 8
0260 crc sf 9
0360 crc fs?c 9
0460 crc sf 10
0560 crc fs?c 10
0660 crc sf 11
0760 crc fs?c 11

[teenix]

CRC 100 from what I determined...

Read Mode: is buffer full? Status[3] = 1 if so
Write Mode: Is buffer empty? Status[3] = 1 if so

I could be wrong, but it also seems to test the head switch state.
Head Switch Closed - Status[3] = 1

It was the only way I could get my code to work properly with the HP microcode.

. . . .

With the HP-97, for some reason the microcode sends out a carriage return as the first print nibble from regC. Normally this enables the motor reverse circuitry and homes the carriage, so it seems an odd place to have that data.

This only occurs when printing a program.

cheers

Tony

[brouhaha]

(10-16-2022 10:15 PM)teenix Wrote:  CRC 100 from what I determined...

Read Mode: is buffer full? Status[3] = 1 if so
Write Mode: Is buffer empty? Status[3] = 1 if so

That's what we meant by "buffer ready", but it's definitely good to document it more explicity.

Quote:I could be wrong, but it also seems to test the head switch state.
Head Switch Closed - Status[3] = 1

It was the only way I could get my code to work properly with the HP microcode.

You found that the 0100 instruction senses that too? Jacques and I didn't find anything like that. Nonpareil seems to support the card reader just fine with 0100 only sensing buffer ready in the way you described.

Maybe the flag doesn't go true unless both the head switch is closed and the buffer is ready?

[teenix]

(10-17-2022 04:16 PM)brouhaha Wrote:  You found that the 0100 instruction senses that too? Jacques and I didn't find anything like that. Nonpareil seems to support the card reader just fine with 0100 only sensing buffer ready in the way you described.

Maybe the flag doesn't go true unless both the head switch is closed and the buffer is ready?

It might merit some more investigation on my part.

The CRC100 and CRC1700 code is also executed during read/write without checking the status flag. I'm still not sure what the CRC is doing in these cases.

Edit:

This is a list of all CRC executions for a card write. Some do not test the s3 flag

Code:



$0087 170  CRC 560      card in test
$0088 0D4  if s3 = 1
$0078 340  CRC 1500
$0079 0D4  if s3 = 1
$007C 0C0  CRC 300
$007D 0D4  if s3 = 1
$0087 170  CRC 560
$0088 0D4  if s3 = 1
$0078 340  CRC 1500
$0079 0D4  if s3 = 1
$007C 0C0  CRC 300
$007D 0D4  if s3 = 1
$0087 170  CRC 560
$0088 0D4  if s3 = 1
$0078 340  CRC 1500
$0079 0D4  if s3 = 1
$007C 0C0  CRC 300
$007D 0D4  if s3 = 1
$0087 170  CRC 560
$0088 0D4  if s3 = 1
$168F 2C0  CRC 1300
$1690 0DC  if s3 = 0
$1693 1F0  CRC 760
$161A 1B0  CRC 660
$16E2 3C0  CRC 1700    <<< no flag test
$16E3 0B0  CRC 260
$16E4 040  CRC 100     <<< no flag test
$16E7 040  CRC 100     <<< no flag test
$167A 040  CRC 100
$167B 0D4  if s3 = 1
$1688 3C0  CRC 1700
$1689 0D4  if s3 = 1
$16ED 040  CRC 100     <<< no flag test
$164C 3C0  CRC 1700    <<< no flag test

$167A 040  CRC 100     <<< write STATUS
$167B 0D4  if s3 = 1
$1688 3C0  CRC 1700
$1689 0D4  if s3 = 1

Write Card Data x 32
  $1682 040  CRC 100
  $1683 0DC  if s3 = 0
  $1688 3C0  CRC 1700
  $1689 0D4  if s3 = 1


$167A 040  CRC 100     <<< write CHECKSUM
$167B 0D4  if s3 = 1
$1688 3C0  CRC 1700
$1689 0D4  if s3 = 1

$1688 3C0  CRC 1700   unsure what this last one does
$1689 0D4  if s3 = 1
$17A7 0CC  0 -> s3
$17A8 3C0  CRC 1700    <<< no flag test, interesting that the following CRC 560 flag is not affected 
                                         as this CRC 1700 does not seem to affect s3 which was cleared
$17A9 170  CRC 560    card out test
$17AA 0D4  if s3 = 1
$17AC 0F0  CRC 360
$17AD 040  CRC 100     <<< no flag test

cheers

Tony

[brouhaha]

After a lot more redesign, coding, and debugging than I expected, Nonpareil has support for a row of the PICK-scanned keyboard in the 19C and 97 to also drive either a row line of the ACT keyboard scanner (19C) or one of the card reader controller external flag inputs (97). That's how HP implemented the feature that holding SST, BST, or R/S pressed shows the program line. The PICK chip doesn't have a way to sense that a key is still held down, so they had to do this weird hardware hack. The programmable calculators that don't use the PICK chip (25, 25C, 29C, 67) don't need the hardware hack as the ACT keyboard scanner does allow sensing key still down.

This is also used on the 19C for the paper advance to keep going while the key is held.

I have the 92 mostly working, though I don't yet have suitable graphics for it. However, some financial calculations crash the calculator, including the example on page 30 of the Owner's Handbook.

I'm not yet ready to do another Nonpareil release, but it's in the Github repo for those feeling adventurous.

The 19C display formatting is wrong, which seems surprising since I thought it worked the same as Topcat models (and unlike the 29C, which works like the other Woodstock models).

There's long been a known bug with the HP-55 "dot" registers. I found a general problem with the Classic series in how RAM is handled that I think explains that, but I haven't fixed it yet. There's something wrong with the 45, because after reloading a saved state (e.g., after exiting Nonpareil and restarting), the display does weird flikering and it has to be reset. Perhaps some state is being saved incorrectly, or there's some necessary state that isn't being saved at all.

[teenix]

(10-17-2022 04:16 PM)brouhaha Wrote:  You found that the 0100 instruction senses that too? Jacques and I didn't find anything like that. Nonpareil seems to support the card reader just fine with 0100 only sensing buffer ready in the way you described.

Maybe the flag doesn't go true unless both the head switch is closed and the buffer is ready?

It might make sense this way. For whatever reason, if the HDS was no long shorted during a card operation, then after a CRC100, s3 stays LO and would cause an error, the card would be ejected, and the process would stop.

Only conjecture.

cheers

Tony

[teenix]

I was just going over old notes and matching up the HP code flow with scope traces and the following seems logical, but not 100%

Code:



crc 560                 Function: Is card inserted?
                        Yes, s3 = 1
Prep code
CRC 1700                Function: Flush Out Buffer ???
                        no s3 test
CRC 260                 Motor ON 
CRC 100                 Function: Reset Logic ???
                        no s3 test

45 instruction loop     14mS delay
CRC 100                 Function: Flag next CRC100 waits for HDS ???
                                  Flag next CRC1700 tests for WPS ???
                                  no s3 test
CRC 100                 loop and wait for HDS to close
                        when closed, s3 = 1
CRC 1700                if write protected, s3 = 1

37 instruction loop     12mS delay
CRC 100                 Function: Set Start bit on WA WB
                                  Set CRC100 CRC1700 to write mode
                                  no s3 test
80 instruction loop     25mS delay
CRC 1700                Function: Flush Out Buffer ???
                        no s3 test

84 instruction loop     25mS delay
start writing status data checksum

cheers

Tony

[brouhaha]

I've just pushed the 19C display formatting fix to the repo, along with some internal changes for the 55.

What took much longer than that was the pixel pushing for the new 55 user interface files similar to those used for the 35 and 45. I'm not great at editing images. Here's what the 55 looks like now:
Nonpareil 55 image

I first made the slide switch legends black, closer to the real calculator, but the contrast sucked so bad (though not unlike the real calculator) that I decided to make them white instead.

Note that the slide switches in Nonpareil (for all models) act as toggles; the three-way switches cycle through the three settings. Thus where you click on them doesn't matter, and sometimes you have to click twice to get to the setting you want. When I implemented the slide switches many years ago, I was too lazy to give them separate sensitive areas for the two or three settings. I've gotten used to it, but I suspect others will find it non-intuitive, so I probably should fix that.

It seems that the code for state save and restore for the Classic series isn't working correctly, as the 45 and 55 often are in a different state or not functional when reloaded. Until I debug this, one can either delete the 55.nst file from the state directory (in Linux, ~/.nonpareil), or use "Hard reset" on the Debug menu.

AFAICT, the Woodstock, 41, and Voyager state save and restore are working correctly.

[brouhaha]

I just added the 70, along with new graphics for the 80.

I'd forgotten just how hideously ugly the 70 was.

[Mike T.]

(10-20-2022 05:28 AM)brouhaha Wrote:  I'd forgotten just how hideously ugly the 70 was.

LOL

I've never seen one in real life but when I got the HP70 to work in x11-calc I thought really hard about changing the button colours but in the end I just toned things down a bit instead.

[Thomas Okken]

The HP-70's color scheme is certainly unique! I like it, though.

[Mark H. Shin]

Since it appears you are revisiting unfinished business with regard to Nonpareil...

I though I might mention some odd behavior I have noticed specifically for the 12C.

After running a self test, regardless of previous annunciator state, the D.MY flag is always set, and the compound flag C is always cleared.

Initial display:

Display after self test:

Display after clearing self test state:


This behavior was observed using 12C ROM contained in the nonpareil 0.77 (Windows) release. And also observed utilizing the so called "original" 12C ROM from the HHC 2021 USB drive.

As far as I can tell, the 12C is the only Voyager series that displays the behavior of altering any annunciator state.

[brouhaha]

(10-20-2022 10:53 PM)Mark H. Shin Wrote:  After running a self test, regardless of previous annunciator state, the D.MY flag is always set, and the compound flag C is always cleared.

I probably won't research it any time soon, but I've put this issue into the issue tracker in the Github repository.

[brouhaha]

I fixed the problem with invalid state save for the Classic series, which was due to a poor implementation of the "delayed select rom" and "delayed select group" instructions. The 35, 45, 55, 70, and 80 now work correctly, as far as I know. The fix is in the github repo, for those feeling adventurous.

I'm not quite ready to make an "official" release. I'm trying to get the 91 and 92 into the next release, along with graphics changes for the 97.

[eshazen]

Hey Eric-
Eric here. You might possibly remember me as the guy who build a Z80-based replica of the HP-25 and presented it at HPCC a couple of years ago. I've been distracted by other things but back to calculator hacking.

I was excited to see the updated code for nonpareil! I'm having a small issue getting it to build though... I get an undefined reference to "classic_disassemble" which the comments hit should be defined in dis_classic.c which is nowhere to be found. Possibly you forgot to push it to git?

Otherwise so far so good on building on Ubuntu 22.04 Linux after a couple of small tweaks. Once I get it running I'll post exactly what I had to do.

Best,
Eric

Code:

scons: Reading SConscript files ...
['calcdef.c', 'chip.c', 'proc.c', 'glib_async_queue_source.c', 'digit_ops.c', 'proc_classic.c', 'proc_woodstock.c', 'crc.c', 'pick.c', 'proc_nut.c', 'coconut_lcd.c', 'phineas.c', 'helios.c', 'helios_chargen.c', 'hepax.c', 'voyager_lcd.c', 'mod1_file.c']
scons: done reading SConscript files.
scons: Building targets ...
scons: `src/build_ncd' is up to date.
scons: `src/uasm' is up to date.
gcc -o src/nonpareil -pthread src/nonpareil_title_png.o src/rgoose_png.o src/lgoose_png.o src/canada_goose_wav.o src/gpl_v2_txt.o src/csim.o src/about.o src/goose.o src/calc_chooser.o src/sound.o src/endian.o src/display.o src/printer.o src/card_reader.o src/keyboard.o src/scancode.o src/slide_switch.o src/cbutton.o src/kml_l.o src/kml_y.o src/kml.o src/util.o src/xmlutil.o src/arch.o src/platform.o src/pixbuf_util.o src/release.o src/calcdef.o src/chip.o src/proc.o src/glib_async_queue_source.o src/digit_ops.o src/proc_classic.o src/proc_woodstock.o src/crc.o src/pick.o src/proc_nut.o src/coconut_lcd.o src/phineas.o src/helios.o src/helios_chargen.o src/hepax.o src/voyager_lcd.o src/mod1_file.o src/elapsed_time_us_posix.o src/state_write.o src/state_read.o src/dis_woodstock.o src/dis_nut.o -lgsf-1 -lxml2 -lpng -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfontconfig -lfreetype -lgdk-x11-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lgdk_pixbuf-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lSDL -lm
/bin/ld: src/proc_classic.o:(.data.rel+0x5a0): undefined reference to `classic_disassemble'
collect2: error: ld returned 1 exit status
scons: *** [src/nonpareil] Error 1
scons: building terminated because of errors.
hazen@eric-x22 nonpareil (main) $

[brouhaha]

(10-23-2022 07:40 PM)eshazen Wrote:  I get an undefined reference to "classic_disassemble" which the comments hit should be defined in dis_classic.c which is nowhere to be found. Possibly you forgot to push it to git?

Sorry, that's not ready. I just pushed a change to use the old, fake disassembler for now.

Since I'm not ready to cut a "release", I'm not being careful about making sure the top of the tree works, but I welcome reports of breakage.

[eshazen]

No problem! Thanks for the quick reply, and I understand that this isn't a release.

I also got it to compile by just creating a dummy function. Works well under Ubuntu 22.04. I had to comment out the 91 ncd and the 15c-192 nui in SConstruct but otherwise it was just a matter of satisfying a bunch of dependencies for scons.

Next I think I may revive my plan to port at least the woodstock simulator to Z80 assembly, as my compiled C code is a bit slow.

(10-24-2022 05:18 AM)brouhaha Wrote:  

(10-23-2022 07:40 PM)eshazen Wrote:  I get an undefined reference to "classic_disassemble" which the comments hit should be defined in dis_classic.c which is nowhere to be found. Possibly you forgot to push it to git?

Sorry, that's not ready. I just pushed a change to use the old, fake disassembler for now.

Since I'm not ready to cut a "release", I'm not being careful about making sure the top of the tree works, but I welcome reports of breakage.

[brouhaha]

(10-24-2022 04:53 PM)eshazen Wrote:  Next I think I may revive my plan to port at least the woodstock simulator to Z80 assembly, as my compiled C code is a bit slow.

I'm not surprised. When Rich Ottosen and I were building calculator prototypes, we initially used Microchip PIC16 and PIC18 8-bit processors. At that time (mid to late 1990s), the available C compilers produced code that was far too slow, so we did that all in assembly. More recent PIC compilers are better, though for Microchip XC8 one unfortunately must buy a license or subscription to get full optimization. I think it would make sense with that to keep most of the simulation in C, but recode portions of it (especially the arithmetic instructions that work on a range of digits within a word) in assembly. That might also make sense for other 8-bit micros, including the Z80.

Around 2010 we switched from PIC microcontrollers to ARM Cortex-M3, specifically the Energy Micro (now Silicon Labs) EFM32 Gecko and Giant Gecko, and used C code exclusively. At the time, those were the only ARM microcontrollers that had decent memory size and very very low power consumption. (The Atmel AT91SAM7L128 used in the first ARM-based version of the HP-12C was low power, but only had 2K of battery powered RAM.) Rich was pretty skeptical of the low-power claims Energy Micro was making, so before he was willing to lay out a board, I bought the EFM32DK board, which was a rather fancy development board that had built-in current profiling with a graphical LCD display, and was quickly able to demonstrate that the power consumption of our calculators using an EFM32 would be very similar to those using the "XLP" PIC microcontrollers.

Now there are a lot more choices for low-power ARM microcontrollers, including the ATSAM4LC2CA used in the newer HP-12C and the STM32L476 used in recent Swiss Micros calculators. However, I understand the appeal of building projects using old-school microprocessors, as I do a lot of such projects myself.

[brouhaha]

I added the 31E and 33E to Nonpareil, and in the process noticed that the self-test was no longer working for any of the Spice models. I tracked that down to fixes to how the external flags work in the Woodstock, Topcat, 19C, and 67, whcih are not relevant to Spice, so I've changed that to restore the old behavior for F1 (s 5) in Spice.

That mostly fixed self-test, but then I noticed that the self-test pass display was not showing the leading minus sign and digit grouping separators (commas in US). And then I noticed that the digit grouping separators weren't working at all. That turned out to be omission of the "i" display segment from the character generator table in the .ncd files for the Spice models. That was an easy fix, but they're still not displayed in the self-test pass result.

[brouhaha]

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.

There was a second problem with self-test, in the ON-divide keyboard and LCD test. Extraneous segments were being turned on. When I was first working on Voyager emulation in 2005, someone told me that in the display bitmap registers, which only have 50 bits rather than 56, that the low six bits read as the complement of bit 7 (though I'm not sure if they were counting from 0 or 1), and I put that in the Nonpareil code. Now I suspect that was not correct, as the display is wrong, but it's right if I have bits 0-5 always read as zero.

I'd like to hack a Voyager to execute my own code to investigate the bitmap register issue further, and also to understand the hardware register 8 behavior, but I'm not sure when I'll find time to do that.