A TTL approach to the HP-35

[Alejandro Paz(Germany)]

Hello together,

I have started to publish some of the work I have been involved lately (mostly FPGA versions of Woodstocks, Nuts, Saturns and Classics).
This time I want to re build the HP-35 using TTL logic. FPGAs do not cut it anymore :-D. It is a work in progress like everything we do around here. I posted it in the retrobrew forum (people like to post re builds of old machines there) HP-35 in TTL, but it belongs here anyways.
The work in progress is at Classic at github.

My idea is to kind of mimic the functionality of the FPGA version (which is based on a simplified woodstock processor) i.e. it is not bit serial (too many shift-registers) but nibble parallel. I got a handful of very rare 74S189 and some LS189. I have to test them (because of the source, they can be very well repainted, most probably are). I may end up using a 2 Kx8 RAM for the registers, the LS189 are very hard to come by if the ones I got are not real ones. And using '670 (or '170s) means a sea of chips for almost no benefit, ok they have separated read-write ports.

[PANAMATIK]

(05-15-2021 06:40 AM)Alejandro Paz(Germany) Wrote:  This time I want to re build the HP-35 using TTL logic....

Nice idea! Did you already calculate how many gates and flip flops are needed? Next step: only use transistors. only vacuum tubes, only relays, reading the HP-35 ROM code from hard coded 768x10 bit magnetic core memory. I can see the Zuse Alejandro ZA3, the first relays computer with trigonometric and exponential functions.

Bernhard

[Jurgen Keller]

(05-15-2021 07:20 AM)PANAMATIK Wrote:  

(05-15-2021 06:40 AM)Alejandro Paz(Germany) Wrote:  This time I want to re build the HP-35 using TTL logic....

[..] I can see the Zuse Alejandro ZA3, the first relays computer with trigonometric and exponential functions.

My colleague once developed a relay computer, see here. He donated it recently to the ENTER museum located in Solothurn, Switzerland.

[mfleming]

Interesting use of a dot matrix LCD to mimic the 41C display. At first glance I thought you were using a salvaged display. Have you compared your fullnut model to Monte's 41CL implementation? Nice keyboard for the Woodstock project.

Somewhere on the 'net is a description of a TTL implementation of the 6502 that I believe was marketed as a kit. The PCB silkscreen serves to annotate the sections of the chip design (ALU, register file, etc.) I think it even used an image of the decapped chip itself. I'll post a link when I can find it but here are a couple of similar projects that a search turned up. Should provide some inspiration for your own project.

https://c74project.com
http://baltissen.org/newhtm/ttl6502.htm

[teenix]

(05-15-2021 07:20 AM)PANAMATIK Wrote:  

(05-15-2021 06:40 AM)Alejandro Paz(Germany) Wrote:  This time I want to re build the HP-35 using TTL logic....

Nice idea! Did you already calculate how many gates and flip flops are needed? Next step: only use transistors. only vacuum tubes, only relays, reading the HP-35 ROM code from hard coded 768x10 bit magnetic core memory. I can see the Zuse Alejandro ZA3, the first relays computer with trigonometric and exponential functions.

Bernhard

...or diode logic like 9100 series :-)

cheers

Tony

[mfleming]

(05-15-2021 05:00 PM)teenix Wrote:  ...or diode logic like 9100 series :-)

cheers

Tony

DTL! Those were the good old days! All down hill since ECL. Another idea if the old TTL parts turn out to be hard to get:

[PANAMATIK]

(05-15-2021 05:32 PM)mfleming Wrote:  .... Another idea if the old TTL parts turn out to be hard to get:

What!? I'm speechless!

[Alejandro Paz(Germany)]

I have seen those TTL projects, very nice, I thought more on the lines "let's use all these chips you have been collecting" and "the Classic processor should be simpler than a PDP-11" (haha).
Relays may be a way too, bit serial is probably the way to go .
Maybe when I am finished with TTL I'll try something else like ECL it intrigues me, I still have to learn layout IC layout, on the list .

The 14 segment display was developed by a forum member some years ago, I tried to get it working using PWM outputs with poor results. A dot matrix display (like the DOGM132) is what I'll finally use, the board shown in the woodstock project has a large enough FPGA for the Nut processor.

Thanks for the support !

PS: I do not know how many gates I'll need. The P register as it is needs 6 gates chips (AND, OR, XOR) two MUXES '153, an ADDER '283 and the '175 as register. I also have some very rare '281, this could replace most of the logic (a '193 can also and is easier to get).
The ALU/REGS block needs the RAM for the registers (either 7 '189 or one 2048x8), two ADDERS, two '175s, two MUXES '153 a '74, a '244 some assorted gates and a couple of '138s to sequence the read/latch/write cycles. Still working on this.

[mfleming]

This may sound a bit recursive but I remember a project (on Hackaday I think) where someone put an FPGA on a PCB the size of a 16-pin DIP. The FPGA could be programmed to mimic any desired SSI chip. A lot easier than building a fab in your garage

[Alejandro Paz(Germany)]

I have been working on and off for the last days and more or less I have an idea how the alu & the registers should work and look like, even if I haven't finalized it yet.
The central questions are how is the program going to be stored and executed ? which opcodes does the processor understands ?, for me just one question.

The original 10 bit opcodes are too compact, I think they need too much logic to be decoded, think about the field storage for example, you need a kind of look up table. An expanded version where the source, destination and field start and end are explicitly stored sounds cheaper in logic terms to me, just route these signals to the respective registers, counters. An opcode then would be a series of enable signals plus the fields. I think that this is much more workable than the 10 bit compact form.

This only solves part of the problem. Opcodes like stack push, pop and rotate need extra sequencers, unless they are encoded as a series of opcodes, meaning the original program needs some tweaking besides opcode replacement. I haven't thought it through yet. I'm still concentrated on the alu/regs block and that it performs the basic register-register operations by itself.
The question remains, one could assign say 8 micro opcodes per 10 bit opcode, memory is cheap nowadays... as one German saying goes "Es gibt immer einen Hacken", something along the lines "nothing is free". Either I microcode the opcodes or I microcode the program. I think the second approach seems easier on logic.

My FPGA version decodes the 10 bit opcodes and has a big look up table and a sequencer or two, for decoding and controlling the data flow and a true dual port register file, this makes exchanges a breeze and the other operations too. One do not think on how many chips maybe needed for some feature. Feeding P into the field start or end is also a small concern becuase it needs another mux and a special treatment.

[teenix]

(06-03-2021 07:31 AM)Alejandro Paz(Germany) Wrote:  I have been working on and off for the last days and more or less I have an idea how the alu & the registers should work and look like, even if I haven't finalized it yet.
The central questions are how is the program going to be stored and executed ? which opcodes does the processor understands ?, for me just one question.

The original 10 bit opcodes are too compact, I think they need too much logic to be decoded, think about the field storage for example, you need a kind of look up table. An expanded version where the source, destination and field start and end are explicitly stored sounds cheaper in logic terms to me, just route these signals to the respective registers, counters. An opcode then would be a series of enable signals plus the fields. I think that this is much more workable than the 10 bit compact form.

This only solves part of the problem. Opcodes like stack push, pop and rotate need extra sequencers, unless they are encoded as a series of opcodes, meaning the original program needs some tweaking besides opcode replacement. I haven't thought it through yet. I'm still concentrated on the alu/regs block and that it performs the basic register-register operations by itself.
The question remains, one could assign say 8 micro opcodes per 10 bit opcode, memory is cheap nowadays... as one German saying goes "Es gibt immer einen Hacken", something along the lines "nothing is free". Either I microcode the opcodes or I microcode the program. I think the second approach seems easier on logic.

My FPGA version decodes the 10 bit opcodes and has a big look up table and a sequencer or two, for decoding and controlling the data flow and a true dual port register file, this makes exchanges a breeze and the other operations too. One do not think on how many chips maybe needed for some feature. Feeding P into the field start or end is also a small concern becuase it needs another mux and a special treatment.

I changed the original opcodes in my PIC emulator as it was much easier to implement in lookup tables for the decoding. I also did the same on my EDUC-8 to PIC emulator for the same reason. The EDUC-8 is a serial 8 bit computer made only from TTL and is a horrible (er challenging) thing to program.

Stack operations are encoded as opcodes which makes manipulation easier from a coding point.

The P register has a few methods of decoding, from logic in the ROM chips and from instructions in the ARC, which deal with word select operations.

I suppose the original chips having around 6000 transistors may give an idea of the complexity. You probably already know, but there are some basic logic diagrams in the HP-45 patent document which may help out.

cheers

Tony