Post Reply 
A TTL approach to the HP-35
05-15-2021, 06:40 AM
Post: #1
A TTL approach to the HP-35
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.
Find all posts by this user
Quote this message in a reply
05-15-2021, 07:20 AM (This post was last modified: 05-15-2021 07:20 AM by PANAMATIK.)
Post: #2
RE: A TTL approach to the HP-35
(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. Smile

Bernhard

That's one small step for a man - one giant leap for mankind.
Find all posts by this user
Quote this message in a reply
05-15-2021, 02:34 PM (This post was last modified: 05-15-2021 02:34 PM by Jurgen Keller.)
Post: #3
RE: A TTL approach to the HP-35
(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. Smile

My colleague once developed a relay computer, see here. He donated it recently to the ENTER museum located in Solothurn, Switzerland.
Find all posts by this user
Quote this message in a reply
05-15-2021, 02:42 PM
Post: #4
RE: A TTL approach to the HP-35
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

Remember kids, "In a democracy, you get the government you deserve."
Find all posts by this user
Quote this message in a reply
05-15-2021, 05:00 PM
Post: #5
RE: A TTL approach to the HP-35
(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. Smile

Bernhard

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

cheers

Tony
Find all posts by this user
Quote this message in a reply
05-15-2021, 05:32 PM
Post: #6
RE: A TTL approach to the HP-35
(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:




Remember kids, "In a democracy, you get the government you deserve."
Find all posts by this user
Quote this message in a reply
05-15-2021, 10:55 PM
Post: #7
RE: A TTL approach to the HP-35
(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!

That's one small step for a man - one giant leap for mankind.
Find all posts by this user
Quote this message in a reply
05-16-2021, 05:58 AM (This post was last modified: 05-16-2021 06:16 AM by Alejandro Paz(Germany).)
Post: #8
RE: A TTL approach to the HP-35
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" Smile (haha).
Relays may be a way too, bit serial is probably the way to go Smile.
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 Smile.

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.
Find all posts by this user
Quote this message in a reply
05-16-2021, 02:01 PM
Post: #9
RE: A TTL approach to the HP-35
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 Smile

Remember kids, "In a democracy, you get the government you deserve."
Find all posts by this user
Quote this message in a reply
06-03-2021, 07:31 AM (This post was last modified: 06-03-2021 07:35 AM by Alejandro Paz(Germany).)
Post: #10
RE: A TTL approach to the HP-35
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.
Find all posts by this user
Quote this message in a reply
06-03-2021, 12:03 PM (This post was last modified: 06-03-2021 12:05 PM by teenix.)
Post: #11
RE: A TTL approach to the HP-35
(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
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)