unknown opcode in Voyager ROM



#9

In the course of trying to get Voyager ROMs running on
http://nonpareil.brouhaha.com/, I've found one unknown opcode, 030 hex (0060 octal).

The Voyager calculators use a mask variant of the same 1LF5 CPU as used in the HP-41C family. (Earlier 41Cs used the 1LA5, and later Voyagers use the 1LM2 or more integrated parts). Since this opcode is not defined in the 1LF5 specification, I suspect that it is implemented by the 1LE2 or 1LH1 "R2D2" chips (RAM/ROM/Display Driver). But I haven't yet figured out what it does.

Anyone out there have the inside scoop? Anonymous contributions of tips or documents gladly accepted. :-)


#10

Hi, Eric;

can you give us an idea about "when" does this code "happen to appear"? I mean, RAM/ROM reading, keyboard scanning, LCD "drawing", etc. I'd not dare guessing this is some new feature available with Voyagers, instead some feature not used in other models. Sort of a "hidden" code that was not mentioned before because it was not yet used. Maybe the context under which it appears may help reasoning about what is it for.

My 2¢ (I'd like to know enough to go further...)

Cheers.

#11

If I recall right, in an article from Tom Revere (7/14/81) he states that the only difference from 1LF5-0301 and 1LF5-0002 are in the metal mask 7 (CMOSV) of the chip regarding only the VCI, VCO circuit [voltage control in/out], the Power On circuit and possibly on the keyboard scanning circuit.

I'm not too familiar with the ML of the NUT CPU, is there any other "related" instruction (same class)? Or it is some coprocessor instruction? On what ROM did you discovered it?

Best regards,

Nelson

#12

This instruction is KEY=C. It causes digits C[4:3] to be
placed in the keycode register. It must be followed by a
NOP becasue the transfer is not direct. Rather, the
instruction causes the key correspdonding to the keycode
to be pulled Low by the CPU for one instruction cycle,
which then is read into the keycode register in the
normal fashion. This information is from Appendix XI of
"Inside the HP-41" by Dodin.


#13

Thanks for the pointer to chapter XI of "Inside the HP-41", it's fascinating. I must confess that I'm somewhat skeptical of the claim that the processor runs code while in deep sleep mode; in deep sleep the processor clock is completely stopped. The author indicates that this information was provided by HP; I wonder whether it might not have been part of an emulation system used by HP engineers for development, rather than the actual Nut CPU chip. The fact that none of the instructions described in that chapter are listed in the 1LF5 specification

In the HP-16C ROM, this instruction occurs in the code sequenct that displays the flashing "running" during self test. The code does a bc ex w to save the C register, c=0 w, a series of lc (load constant digit), and write to register 9, followed by a similar sequence writing a different constant to register 10. These are the display registers, and the constants are the segment maps that form the "running". Then the code does another bc ex w to restore the original C register, the mysterious 0060 (octal) instruction, then a return.

For thousands of following cycles, there is no reference to the keyboard, and eventually when the keyboard flag is tested, it is not set. Thus I don't believe the 0060 is behaving as KEY=C. Instead, I think it is turning on the display blink mode. There's no corresponding mystery instruction to turn the blink off, so I suspect that is done by either the display off or display toggle instructions, as when the self-test is completed they do a sequency of those two instructions even though the display is already on.

Since the display blink is under user control on the HP-15C (flag 9), I should be able to confirm whether this is really what the 0060 instruction is doing the next time I have an HP-15C hooked up to the probulator.

Thanks!
Eric


#14

The assertion that the "boot code" listed in the appendix runs while in deep sleep mode is obviously incorrect, because as you say, there is no clock present. I think that the code may actually be present in the CPU and is executed on start-up to determine what kind of wake-up actually occurred, as described in the text. Since this code has to be switched out during normal operation it is always possible that the few special instructions executed there might only be enabled during this boot operation. The way to tell would be to capture the clock cycles on startup to determine if it looks like the CPU is executing something internal. Unfortunately I don't have the means to do this, so I have assumed that the description is correct and have implemented this in my clone of the NUT processor. Implementing the KEY=C instruction was a pain because teh row outputs now have to be I/O instead of just inputs and the timing is messy too. If this instruction is present but is switched out except during bootstrap it could very well be used by the display.


#15

Quote:
I think that the code may actually be present in the CPU and is executed on start-up to determine what kind of wake-up actually occurred, as described in the text.

I won't say that it's impossible, but it seems quite unlikely. If it does run the Appendix XI code, the hardware has to know what kind of wakeup it is anyhow, in order for the ?WKUP instruction to work. The Appendix XI code doesn't do anything that the hardware couldn't do more easily by simply setting the carry flag directly, which is what I'm pretty sure that it does. The only use for the Appendix XI code appears to be for emulating the power off/deep sleep state on a processor that doesn't actually go to sleep.

Quote:
The way to tell would be to capture the clock cycles on startup to determine if it looks like the CPU is executing something internal.

By capturing traces, I have verified that the 1LF5-0301 CPU used in the Voyager calculators does not do anything mysterious between power-up and starting to execute external ROM code from address zero. The 1LF5 specification enumerates the differences between the -0002 version used in the 41C family and the -0301 version used in the Voyagers, and there is no mention of any difference in code execution at startup. It's remotely possible that the earlier 1LA5 or later 1LM2 processors could behave differently.

On the 16C (using the 1LF5-0301 CPU), the 0060 octal (030 hex) instruction definitely does not perform a KEYS=C operation.

Best regards,

Eric


#16

Eric, thank you. Time to rip a few things out of my design.

Best regards,
Monte


Possibly Related Threads...
Thread Author Replies Views Last Post
  Voyager keyboard issue John Richards 2 237 09-27-2013, 07:43 PM
Last Post: John Richards
  Concern about Voyager keyboard test Matt Agajanian 2 266 08-30-2013, 07:56 PM
Last Post: Matt Agajanian
  [OT] Unknown Olivetti calculator? Cristian Arezzini 4 308 05-24-2013, 01:17 PM
Last Post: Thomas Klemm
  Voyager Self Test Mike (Stgt) 5 335 05-16-2013, 03:28 PM
Last Post: Mike (Stgt)
  HP85 Programmable ROM cardtridge 82929A-service ROM not working- inaki 2 259 04-25-2013, 08:08 AM
Last Post: inaki
  Voyager reproduction logos ? John Robinson 2 208 02-25-2013, 05:19 PM
Last Post: John Robinson
  shelf life time of a ROM, EEPROM, EPROM vs Mask Rom Guido (Canada) 6 395 01-11-2013, 04:09 PM
Last Post: Thomas Falk
  Swiss clones of the HP Voyager series WaltMaken 10 511 11-30-2012, 11:40 AM
Last Post: Harald
  Big ROM - 41 System DEMO ROM Ángel Martin 5 405 10-16-2012, 05:28 AM
Last Post: Ángel Martin
  DM-1xC vs. HP Voyager KINOMI Csaba Tizedes (Hungary) 4 330 10-10-2012, 07:25 PM
Last Post: uhmgawa

Forum Jump: