Recreating a HP-25

[Alejandro Paz(Germany)]

Hello,

I wanted to tell about one of the projects I'm working on: recreating a HP-25. Of course there is a couple of emulators, but having the calc on one's hand is something else, I think.
I decided, because I like FPGAs, to use a small MachXO2 device to recreate the chipset of the calc.
Being a work in progress means that it doesn't yet exists outside a simulator, but it seems to runs the microcode . I still have to compare the output to a trace of the java emulator.
If anyone wants to peek into the HDL, I posted it here: HDL and Testbench

The testbench works with icarus verilog and should still work with Aldec's Active HDL simulator (installed with Lattice Diamond).

A circuit is in the works , I have to relearn KiCad again

[walter b]

PANAMATIK should be a great help in this matter, I assume.

d:-)

[Thomas Radtke]

(06-09-2016 07:33 AM)Alejandro Paz(Germany) Wrote:  [...] there is a couple of emulators, but having the calc on one's hand is something else, I think.

And I agree. Care to sell a replacement kit for Woodstocks with rotten innards? :-)

[PANAMATIK]

(06-09-2016 07:33 AM)Alejandro Paz(Germany) Wrote:  [...] there is a couple of emulators, but having the calc on one's hand is something else, I think.

Hi Alejandro

Now I have a real competitor

I had a look into your HDL code. It's absolutely amazing, that you coded everything in hardware without using an embedded processor. Your HP-25 will be very very fast! You have to prolong the PAUSE and key response. If you need any help, you are welcome.

It would be interesting to compare, how efficient the original HP hardware was between the modern HDL approach, compared by number of gates.

(06-09-2016 10:41 AM)Thomas Radtke Wrote:  And I agree. Care to sell a replacement kit for Woodstocks with rotten innards? :-)

Now, I have to reveal that I am building a new replacement kit for woodstocks in addition to the repair kit, which revives the calculator even if only the PCB is present and all chips and power supply are damaged or removed. It will be the Low Power Version of the new ACT, because it will consume only between 10-40mA. Battery life time will be weeks in standby mode.

Bernhard

[Alejandro Paz(Germany)]

Thanks !

Elaborating a bit on the inner workings, the first I can say is that it is not HW-compatible.

* Arithmetic/data operations are nibble-based: opcodes that work on all 14 nibbles take 33 cycles.
* Two cycles to access registers, it simplifies things. Registers are in a dual-ported RAM. (2-phase clocks in FPGAs are... not the best approach).
* Microcode resides in a ROM.
* Decoding is done using behavioral constructs, no single gates. (Using single gates could reduce gate count).
* ADD/SUB is done using behavioral models, no ROM-based ALU (like the original, ROMs were easy and fast).
* A couple of opcodes are still missing .
* The display works differently, in my case it has access to A&B simultaneously.

If you have GTKWave handy, you could load dump.vcd, and see (pretty signals) how it works

The keyboard module is not there yet. I was thinking on doing hw-debouncing, it is going to need some counters, one per key would be ideal..., scanning slowly like at 50 Hz or so reduces the number of bits in the counters, maybe I can get aways with 2 bits...

Regarding speed... it can do 20 MHz on this low power part... Amazing what HP did with like 300 kHz

Here is the output of Diamond's mapper:
---------------------------------

Design Information

Command line: map -a MachXO2 -p LCMXO2-1200ZE -t TQFP144 -s 1 -oc Industrial
WS_WS.ngd -o WS_WS_map.ncd -pr WS_WS.prf -mp WS_WS.mrp
C:/02_Elektronik/084_Woodstock/05_Lattice/WS.lpf -c 0 -gui
Target Vendor: LATTICE
Target Device: LCMXO2-1200ZETQFP144
Target Performance: 1
Mapper: xo2c00, version: Diamond (64-bit) 3.5.1.302
Mapped on: 06/09/16 13:57:02


Design Summary
Number of registers: 210 out of 1604 (13%)
PFU registers: 210 out of 1280 (16%)
PIO registers: 0 out of 324 (0%)
Number of SLICEs: 368 out of 640 (58%)
SLICEs as Logic/ROM: 368 out of 640 (58%)
SLICEs as RAM: 0 out of 480 (0%)
SLICEs as Carry: 32 out of 640 (5%)
Number of LUT4s: 732 out of 1280 (57%)
Number of logic LUTs: 668
Number of distributed RAM: 0 (0 LUT4s)
Number of ripple logic: 32 (64 LUT4s)
Number of shift registers: 0
Number of PIO sites used: 43 + 4(JTAG) out of 108 (44%)
Number of block RAMs: 4 out of 7 (57%)
Number of GSRs: 0 out of 1 (0%)
EFB used : No
JTAG used : No
Readback used : No
Oscillator used : No
Startup used : No
POR : On
Bandgap : On
Number of Power Controller: 0 out of 1 (0%)
Number of Dynamic Bank Controller (BCINRD): 0 out of 4 (0%)
Number of Dynamic Bank Controller (BCLVDSO): 0 out of 1 (0%)
Number of DCCA: 0 out of 8 (0%)
Number of DCMA: 0 out of 2 (0%)
Number of PLLs: 0 out of 1 (0%)
Number of DQSDLLs: 0 out of 2 (0%)
Number of CLKDIVC: 0 out of 4 (0%)
Number of ECLKSYNCA: 0 out of 4 (0%)
Number of ECLKBRIDGECS: 0 out of 2 (0%)


Preference Summary

FREQUENCY NET "clk_in_c" 36.380000 MHz (4096 errors)

4096 items scored, 4096 timing errors detected.
Warning: 20.929MHz is the maximum frequency for this preference.

[Thomas Radtke]

(06-09-2016 11:37 AM)PANAMATIK Wrote:  Now, I have to reveal that I am building a new replacement kit for woodstocks in addition to the repair kit, which revives the calculator even if only the PCB is present and all chips and power supply are damaged or removed.

My PCB is rotten, too. Still, a lot of people have been and will be very happy about your work, I'm sure.

Edit: Well, just forgot I'd received a replacement PCB w/o chips! I'm not getting old, I *am* old.

[Guenter Schink]

(06-09-2016 07:33 AM)Alejandro Paz(Germany) Wrote:  Hello,

I wanted to tell about one of the projects I'm working on: recreating a HP-25. Of course there is a couple of emulators, but having the calc on one's hand is something else, I think.
I decided, because I like FPGAs, to use a small MachXO2 device to recreate the chipset of the calc.
Being a work in progress means that it doesn't yet exists outside a simulator, but it seems to runs the microcode . I still have to compare the output to a trace of the java emulator.
If anyone wants to peek into the HDL, I posted it here: HDL and Testbench

The testbench works with icarus verilog and should still work with Aldec's Active HDL simulator (installed with Lattice Diamond).

A circuit is in the works , I have to relearn KiCad again

You should consider to join the Alschwill (next to Basel,CH) meeting in October. You'd certainly have an interested audience.

Günter

[Alejandro Paz(Germany)]

Quote:You should consider to join the Alschwill (next to Basel,CH) meeting in October. You'd certainly have an interested audience.

Günter

That would be great !... it is like... 70 km from where I live... They were asking who is going to go some months ago. (Corrected, as I mixed it with HHC).

[Guenter Schink]

(06-10-2016 04:59 AM)Alejandro Paz(Germany) Wrote:  

Quote:You should consider to join the Alschwill (next to Basel,CH) meeting in October. You'd certainly have an interested audience.

Günter

That would be great !... it is like... 70 km from where I live... They were asking who is going to go some months ago. (Corrected, as I mixed it with HHC).

Great. I'll be there also, only listening to those who have to present something.

Günter

PS: Need to remember it's Allschwil not Alschwill

[Alejandro Paz(Germany)]

I've been working lately on the code quite a bit and on a prototype board with keys and 7-segment displays. The code runs till the entry loop at 0742..0745. I have to implement keyboard scanning now. Debouncing seems to happen entirely on hw. If this where some microprocessor, I'd just use some software counters to scan the matrix and store key changes. I'd like to avoid using one counter per key, because I don't think that it was done like that. There is enough logic in this chip, I just think that is a waste of logic to do it like that....
I had some problems with the carry. It gets set and cleared in the same instruction, not a behaviour I have to reproduce,... on the 1LF2 I used an extra register for the comparison result. Here I used the carry, but it resulted in awkward code. There is a bit to improve. I follow the principle: make it work, make it fast, make it good . The 1LF2 has hw registers and the ws has memory-mapped registers, there is not enough logic for all the muxes one needs in a 8x64 bits register file with two access ports. Two R/W ports are not really needed, they are just convenient. It is a behavioural model after all, not a gate-level model (one could also do this but... why ?).
The code posted to github is up-to-date. There is a stream of serial data, pc, opcode and P register coming out of the FPGA (numbers in octal except P). I'm using a MachXO2-1200ZE breakout board, it has a TTL33 to USB adapter built in. It is clocked from the internal 2.08 MHz clock, serial data is output at 500 kbps, no problems for the FT2232, they can also have 2 Mbps .
I'll post a couple of pictures of the prototype once I've finished soldering the keys to the connectors, and the displays... quite a bit of wiring going on.

If you study a bit the code, there is another surprise there , it only needs another row of keys .

Code:


0000 1173 0
0236 1160 0
0237 1260 0
0240 0756 0
0241 0752 0
0242 0762 0
0243 0572 0
0244 0410 0
0245 0432 0
0246 0610 0
0247 0310 0
0250 1410 0
0251 0072 0
0252 0032 0
0253 1710 0
0254 1605 0
0341 0032 0
0342 0662 0
0343 1672 0
0344 0662 0
0345 0662 0
0346 0136 0
0347 1610 0
0350 1474 0
0351 1102 0
0352 1157 0
0353 0116 0
0354 0056 0
0355 1020 0
0255 0510 0
0256 0256 0
0257 0012 0
0260 0264 0
0261 1017 0
1203 1614 0
1204 1152 0
1205 1053 0
1212 1152 0
1213 1427 0
1305 0710 0
1306 0516 0
1307 1504 0
1310 1705 0
1361 0774 0
1362 0656 C
1363 1673 C
1356 1116 C
1357 1657 C
1353 0344 C
1355 0620 C
1356 1116 B
1357 1657 B
1353 0344 B
1355 0620 B
1356 1116 A
1357 1657 A
1353 0344 A
1355 0620 A
1356 1116 9
1357 1657 9
1360 1723 9
1364 0032 9
1365 0246 9
1366 0526 9
1367 1773 9
1376 0156 9
1377 1020 9
1311 1512 9
1313 1401 9
1300 0420 9
1301 0006 9
1302 1106 9
1303 1410 9
1304 1020 9
1314 0116 9
1315 1074 9
1316 1502 1
1320 1116 1
1321 1527 1
1322 0016 1
1323 0116 1
1324 1247 1
1251 0262 1
1252 0110 1
1253 0514 1
1254 0524 1
0274 0134 1
0072 0334 1
0074 0164 1
0075 0727 1
0565 1114 1
0566 1214 1
0567 1353 1
0672 1614 1
0673 1645 1
0751 0210 1
0752 0341 1
0470 1714 1
0471 0274 1
0472 0620 7
0473 1354 6
0472 0620 6
0473 1354 5
0472 0620 5
0473 1354 4
0472 0620 4
0473 1354 3
0472 0620 3
0473 1354 2
0472 0620 2
0473 1354 1
0472 0620 1
0473 1354 0
0475 1724 0
0477 1020 0
0753 1760 0
0754 0324 0
0742 0314 0
0743 0334 0
0745 1734 0
0742 0314 0
0743 0334 0
0745 1734 0
0742 0314 0

[PANAMATIK]

>>If you study a bit the code, there is another surprise there , it only needs another row of keys .

Your listing shows the HP-25 initialization program flow. But where is the surprise?

Bernhard

[Alejandro Paz(Germany)]

Oops, I didn't mean the trace but the verilog code .

[Alejandro Paz(Germany)]

These last days I was able to get to work again on the core, and to iron out those bugs that prevented STO/RCL and the block-memory based register file to work. I ended, as I suspected, having to add a couple extra cycles to account for the block ram latency. Now, it works as a real 25 would do but much faster. Sadly a bit late for the meeting .

Now I have a question, is the firmware of the 25C different from the regular non-C model ?

[PANAMATIK]

(10-26-2016 07:21 PM)Alejandro Paz(Germany) Wrote:  These last days I was able to get to work again on the core, and to iron out those bugs that prevented STO/RCL and the block-memory based register file to work. I ended, as I suspected, having to add a couple extra cycles to account for the block ram latency. Now, it works as a real 25 would do but much faster. Sadly a bit late for the meeting .

Now I have a question, is the firmware of the 25C different from the regular non-C model ?

Congratulations for having the STO RCL issue fixed!

Your prototype didn't seem to have a PRGM/RUN switch. I couldn't enter program steps. Pressing SST or R/S button didn't show the next program step when hold down. Did you fix that too? You just have to set status bit s 15 every instruction as long as any key is hold down.

HP-25 and HP-25C have the same firmware, the only difference in behaviour occurs as the RAMs of the C model doesn't clear its contents when "clear data regs" is executed.

Bernhard

[Alejandro Paz(Germany)]

Yes, there was no switch, I added "features" as the HDL-code needed them. It is now due.