ACT available

[PANAMATIK]

(02-17-2015 06:47 PM)PANAMATIK Wrote:  

(02-17-2015 06:16 PM)Nigel (UK) Wrote:  Any ideas? What sort of fault could leave the original ACT working (to an extent) but cause the replacement to fail in this way? I know it's rather hard to diagnose things like this over the internet but it's worth asking!

Thank you in advance for your help.

Nigel (UK)

Im sure we can fix this problem soon. I will write a PM with more details.

Bernhard

I found the reason for the problem, which was an interaction of a protection diode and the sensibility of the display driver chips.

There are ten repairs made now and all of them are working. Can I hope that this percentage of success can increase somehow in the future?

Bernhard

[PANAMATIK]

Today was a day I was waiting for:

The new ACT is now fully approved for the complete "Woodstock" model series.

HP-21, HP-22, HP-25, HP-25C, HP-27, and HP-29C

The last open issue was finding the reason, why the registers of the HP-29C were always cleared at power up and not saved in "Continuous Memory". The reason was: The HP firmware was prepared for different assembly variants and contained a "Clear all Register" opcode for compatibility with PMOS RAMs. However the finally used CMOS RAMs, who retain their contents, just ignore this instruction. I had to change the emulator not to perform this opcode. Now it behaves exactly like the original and all 30 registers and additionally the X register, LastX register and display format are saved in "Continuous Memory", and of course the 98 program steps.

This was an issue that was very easy to correct when found, but was not very easy to find.

Now I'm glad to have this complete.

Bernhard

[brouhaha]

I'm not convinced that you have an accurate model of how the instruction works.

My understanding based both on hardware experimentation and on study of the firmware of various models is that the clear data regs instruction (octal 1260) always clears all of the data registers in the selected 16-register group (i.e., all registers whose address ignoring the low four bits is equal to the selected address. It works that way whether the chip is PMOS, NMOS, or CMOS. It definitely does not clear all the registers when there are multiple 16-register chips; it only clears the selected one. Two details I'm not entirely certain of:

• Does the 1260 instruction clear a complete 16 registers-group when they are implemented in two 8-register chips?
• Does the 1260 instruction clear all 32-registers of a 32-register group? I'm fairly certain that it does not.
  

In the 29C, the firmware at address 6331 explicitly does a clear with address 0x10 selected, if it has detected that the cold-start constant (BCD 34934284) is not present in the status register (0x2e). I believe this clears only the registers from 0x10 through 0x1f. If the instruction was incorrectly implemented and cleared all RAM, or cleared the entire CMOS RAM chip (0x10 through 0x2f), it would wipe out the cold-start constant that it has just written (at address 6324) into the status register, which is why it would clear that RAM at every power-up.

On the other hand, if the instruction was implemented to not EVER clear the CMOS RAM chip, it would cause problems on a true cold start, leaving garbage behind. (Possibly not causing any actual problem in your simulation code if you zero all registers on a true cold start.)

[PANAMATIK]

(03-08-2015 08:35 AM)brouhaha Wrote:  I'm not convinced that you have an accurate model of how the instruction works.

My understanding based both on hardware experimentation and on study of the firmware of various models is that the clear data regs instruction (octal 1260) always clears all of the data registers in the selected 16-register group (i.e., all registers whose address ignoring the low four bits is equal to the selected address. It works that way whether the chip is PMOS, NMOS, or CMOS. It definitely does not clear all the registers when there are multiple 16-register chips; it only clears the selected one. Two details I'm not entirely certain of:

• Does the 1260 instruction clear a complete 16 registers-group when they are implemented in two 8-register chips?
• Does the 1260 instruction clear all 32-registers of a 32-register group? I'm fairly certain that it does not.
  

In the 29C, the firmware at address 6331 explicitly does a clear with address 0x10 selected, if it has detected that the cold-start constant (BCD 34934284) is not present in the status register (0x2e). I believe this clears only the registers from 0x10 through 0x1f. If the instruction was incorrectly implemented and cleared all RAM, or cleared the entire CMOS RAM chip (0x10 through 0x2f), it would wipe out the cold-start constant that it has just written (at address 6324) into the status register, which is why it would clear that RAM at every power-up.

On the other hand, if the instruction was implemented to not EVER clear the CMOS RAM chip, it would cause problems on a true cold start, leaving garbage behind. (Possibly not causing any actual problem in your simulation code if you zero all registers on a true cold start.)

When I started the ACT project, I didn't want to dig much into the ACT instructions. The nonpareil emulator was already so perfect for HP25 and HP-21, and as I know now also for HP-22 and HP-27. So I didn't study the HP firmware and the emulator very much. But curiosity led me to the idea that there could be some secrets lifted and when I decided to buy a defective HP-29C I did it with the intention to repair it and make this calculator repairable for others. Soon I understood that the very best way to find out how some unknown instructions behave could only be solved by a ROM emulator and a sophisticated sequence of instructions, that reveal, what the original ACT does in response to these instructions. Till today I never came so far to make a ROM emulator. It is still ahead although the hardware is already there and it is not too difficult to implement. But as lazy as I am, I reduced my work to the aim, just to make the HP-29C firmware running by making assumptions, guessing and the try and error method.

I admit and agree totally, that my implementation, which made the HP-29C firmware finally running, is not necessarily an accurate model of the real ACT. As an example, imagine that the emulator doesn't do anything with the instruction xxxx and the HP-29C doesn't use the instruction xxxx in its whole 4k ROM code, then it will emulate perfectly well, but is not an accurate model of the real ACT. If another firmware uses the xxxx instruction, the emulator will fail.

The Clear Registers instruction 1260 is used only once in the HP29C 4k ROM code at address 6331. In my ACT all RAM registers will be loaded from Flash memory prior to act_reset() and I don't want to have them cleared, so my easy solution for the HP-29C was to ignore this single instruction. Well it works well, but I cannot be very proud. I would liked to have the time to build a ROM emulator and writing software for it and find out the exact behaviour of the Clear Register instruction in any contexts. I plan to do that in the future.

I made the observation, that 1260 with ramaddr set to 0x10 cleared register 0-31, but not registers 32-47, which contained the 98 program steps.

Your implementation does exactly what you describe in words, it clears 16 registers and works for HP-25. Since the HP-25 only has 16 registers ram_addr never will be >=0x10.

Code:

static void op_clear_data_regs ()
{
  int base;
  int i, j;

  base = act_reg->ram_addr & ~ 017;
  for (i = base; i <= base + 15; i++)
    for (j = 0; j < WSIZE; j++)
      act_reg->ram [i] [j] = 0;
}

The HP29C uses clear register at ram_addr 0x10, but I observe the lower ram 0x00-0x0F is also cleared at the same time, the upper RAM is not cleared. Keep in mind that the 1260 instruction is not performed by the ACT, it only issues the opcode on the bus, it is decoded and performed by the RAM chips itself. Therefore I assumed, that the RAM chips (which always contain a 16 register RAM group but I'm not sure), could be designed different, some of them perform the clear instructions, others don't. And the CMOS type don't. This would raise the question why ram_addr is loaded with 0x10 before. So I may be wrong. But it could explain, why you needed to implemented base = act_reg->ram_addr & ~ 017 statement.

My assumption and it is only an assumption: The clear instruction is independent from ram_addr and clears those RAMs, that are listening to this command.

I really need to build a ROM emulator to get from assumptions to knowledge. It would be the best scope for real instruction analyzing.

But at least making assumptions and prove whether they can withstand the experiments is the real scientific method. I have repaired two HP-29C now, and they really like the emulator model as it is at the moment.

But I know there is still lot of work to do for the HP-97 etc.

Bernhard

[Nigel (UK)]

(03-03-2015 11:22 AM)PANAMATIK Wrote:  

(02-17-2015 06:47 PM)PANAMATIK Wrote:  Im sure we can fix this problem soon. I will write a PM with more details.

Bernhard

I found the reason for the problem, which was an interaction of a protection diode and the sensibility of the display driver chips.

There are ten repairs made now and all of them are working. Can I hope that this percentage of success can increase somehow in the future?

Bernhard

I've just received my HP-25 back from Bernhard - fully functional! From the outset Bernhard has been consistently helpful with lots of debugging suggestions, fast replies to messages, and finally an offer to examine the calculator himself when he could not diagnose the problem remotely. Thank you again for all your help.

Nigel (UK)

HP-25E rules ok!

[PANAMATIK]

(03-09-2015 11:49 AM)Nigel (UK) Wrote:  HP-25E rules ok!

Thank you Nigel. It is a pleasure to hear that everything is ok!

Last week I had a more difficult repair of an HP-29C, which I bought as defective from a well known platform. This time it was really defective. It turned out that the ACT didn't work (of course), three of the four ROMs were not responding, one of the RAM chips pulled the ISA line low, so I had to remove them, and last not least the anode driver STR line showed only 1V amplitude and the display was not working.

It was easy to replace the ACT. But I had to remove all the RAMs and to cut the STR line, which connects anode and cathode driver and made changes of the ACT software to generate the STR strobe instead by myself. Then I soldered a wire connection between the new ACT STR pin and the cathode driver. After some timing adjustments and running the HP-29C firmware from internal ROM I have a fully functional HP-29C calculator, not distinguishable from the original. I was lucky that the cathode display driver was not damaged more, otherwise I had to build a replacement for the display driver too.

Additionally I started to add the extended features for the HP29C, however with reduced storage space for programs, because the firmware has double the size of the HP-25s. Stopwatch and Functions and many other features are already implemented and only minor problems remain. One problem is the missing letter F and P, which cannot be displayed in HP-29. How can I display memory usage "Pr.10 88 FrEE" now? Any suggestions?

Bernhard

[N4TVC]

I am delighted to report that my ACT Replacement arrived in Virginia USA today. I had purchased a faulty HP-25 to use to play with this ACT Replacement as I didn't really want to remove a good ACT from my functional HP-25. The faulty HP-25 was so bad off, there were no indications, at all. No LEDs or segments would light. I was worried that the anode or cathode drivers might be bad, in addition to the ACT being faulty. It was a cosmetically near-perfect unit, however. When I replaced the ACT with my new ACT Replacement, I was greeted with "HELLO AI." and then "HP-25E". I am, obviously, very happy. Now I get to play with all the awesome features of this new and greatly improved calculator. Thank you, Bernhard. Great work on the ACT Replacement and the Manual.

Randy
N4TVC
Virginia
USA

[PANAMATIK]

(02-15-2015 09:37 PM)Mark Hardman Wrote:  Will you be making Bruce Lee's HP-27 ROM dump available on your downloads page soon? If so, I'll start working on a KLM package for it in Nonpareil.

Did anybody make progress in this matter? If there is an HP-22 or HP-27 emulator for MacOSX or IOS already put together, please let me know.

Bernhard

[Mark Hardman]

(03-09-2015 09:41 PM)PANAMATIK Wrote:  

(02-15-2015 09:37 PM)Mark Hardman Wrote:  Will you be making Bruce Lee's HP-27 ROM dump available on your downloads page soon? If so, I'll start working on a KLM package for it in Nonpareil.

Did anybody make progress in this matter? If there is an HP-22 or HP-27 emulator for MacOSX or IOS already put together, please let me know.

Bernhard

I've held off in hope that Eric would update Nonpareil's source tar ball so that I could work on the HP-27 and HP-29C KLMs together.

I've sent an email to Olivier De Smet with links to your extracted ROM images and encouraged him to add a go22c and go27c to his line of Android emulators.

[brouhaha]

(03-08-2015 07:42 PM)PANAMATIK Wrote:  Therefore I assumed, that the RAM chips (which always contain a 16 register RAM group but I'm not sure),

There are also 8-register and 32-register RAM chips. (And 10-register for the Classic series, not including the HP-67 which is electrically a Woodstock.)

I wasn't trying to suggest that there was anything wrong with your solution to getting the 29C running. My point was just that your description doesn't match what the actual hardware does. The end result in the case of the 29C is apparently the same, but it won't be for all models.

[brouhaha]

(03-08-2015 07:42 PM)PANAMATIK Wrote:  Your implementation does exactly what you describe in words, it clears 16 registers and works for HP-25. Since the HP-25 only has 16 registers ram_addr never will be >=0x10.

My implementation works correctly in Nonpareil for the 19C, 22, 25, 25C, 27, 29C, 32E, 34C, 37E, 38C, 38E, 67, 97, and 97S. I don't yet know if works for the 33E, 91, 92, and 95C, but I'm expecting that it will. On a few of those models the behavior was actually verified by driving the RAM chips directly, with the ACT ISA and DATA lines disconnected from the rest of the calculator. I no longer have records for exactly which models I did that, though the 19C and 97 were among them.

[PANAMATIK]

(03-10-2015 07:19 AM)brouhaha Wrote:  My implementation works correctly in Nonpareil for the 19C, 22, 25, 25C, 27, 29C, 32E, 34C, 37E, 38C, 38E, 67, 97, and 97S.

And 21! This is an impressing list and a fantastic work.

What is the reason that the latest nonpareil 0.79 doesn't include this implementation?

Bernhard

[brouhaha]

(03-10-2015 07:27 AM)PANAMATIK Wrote:  

(03-10-2015 07:19 AM)brouhaha Wrote:  My implementation works correctly in Nonpareil for the 19C, 22, 25, 25C, 27, 29C, 32E, 34C, 37E, 38C, 38E, 67, 97, and 97S.

And 21! This is an impressing list and a fantastic work.

I was only listing the models that actually use the 1260 instruction. The 21 and 33C do not. I don't have ROM dumps from the 31E and 33E.

Quote:
What is the reason that the latest nonpareil 0.79 doesn't include this implementation?

The technical reason is that I went down a path of redesigning the internals and ran into some issues which I haven't yet resolved.

The non-technical reason is that I lost a lot of motivation when I discovered multiple people selling mobile apps using my code (verified with some difficulty, as they tried to obfuscate it, and the apps are normally encrypted) without honoring the GPL terms or even contacting me about it. (I'm not talking about anyone who participates in this forum, to the best of my knowledge.)

At this point I'd like to finish it up and have another release, but I won't have time to work on it for at least several more months.

[Denis CAMUS]

And why it is impossible to downoad a Windows .exe version ?

[brouhaha]

(03-10-2015 10:38 PM)Denis CAMUS Wrote:  And why it is impossible to downoad a Windows .exe version ?

Because I don't have either time or interest to try to build a version for Windows. I did it once, it was difficult and tedious, and an all-round unpleasant experience. Which is what I pretty much find all Windows software development to be; I am often forced to do that for my day job so it's the last thing I want to do in my copious free time. There are people who actually *like* doing software development on Windows, and I can't understand why, but more power to them. It's entirely possible that those people find development on open-source operating systems just as unpleasant as I find development on Windows.

It's open source, so anyone who does have the time and interest to port it to Windows is quite welcome to do so.

Sorry.

[brouhaha]

When I resume Nonpareil development, it is my intention to redo the GUI using Qt 5.x instead of GTK+ 2.x. Cross-platform support in GTK+ has always been a bastard stepchild, while the Qt developers actually work hard to make Qt usable on many platforms. I've been resisting switching over to Qt for years, because I dislike the C++ programming language. Hmm... maybe I should just rewrite it in Python!

Once it's converted to use Qt, having a Windows version should be much easier. However, given the glacial pace that development has had for the last few years, I'd strongly advise everyone against holding their breath.

[PANAMATIK]

(03-10-2015 07:21 PM)brouhaha Wrote:  The non-technical reason is that I lost a lot of motivation when I discovered multiple people selling mobile apps using my code (verified with some difficulty, as they tried to obfuscate it, and the apps are normally encrypted) without honoring the GPL terms or even contacting me about it.

About one year ago, before I had any idea, that I will be involved in HP calculators, I bought a very nicely looking HP-11C iPhone App just for fun. But although it was calculating perfectly, it was not a good deal, it turned out to be a bad experience. The App had a very loud key click and by no means it was possible to switch it off, nor to reduce the loudness not even with the dedicated volume control buttons of my phone. For this reason it was practically unusable for calculations. There was no contact to the developer possible for complaining, at least I didn't get any answer. I couldn't believe that it was impossible to switch off this very loud annoying key clicks and tried to find out the reason. I never did. In my imagination I thought this must be a tacked together software by some north korean or chinese hackers. Obviously they abused the nonpareil emulator for their apps to get some profit.

But still I don't understand, why they designed the software especially for profoundly deaf users.

Bernhard

[rprosperi]

(03-10-2015 07:21 PM)brouhaha Wrote:  I don't have ROM dumps from the 31E and 33E.

Eric - I'm happy to lend you the machines if that's what held you up, and as long as they continue to work after dumping.

[PANAMATIK]

(03-11-2015 12:18 AM)rprosperi Wrote:  

(03-10-2015 07:21 PM)brouhaha Wrote:  I don't have ROM dumps from the 31E and 33E.

Eric - I'm happy to lend you the machines if that's what held you up, and as long as they continue to work after dumping.

I will try to read the ROMs next weekend. I have both calculators.

Bernhard

[PANAMATIK]

(03-10-2015 07:21 PM)brouhaha Wrote:  I don't have ROM dumps from the 31E and 33E.

I read the 33E 4k ROM chips 1MA10003 1MA10004 today. You will find the ROM dump it in your mail.

Bernhard