EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: GK on June 07, 2014, 09:50:01 am
-
In my "Homebrew analog computer" thread I mentioned a couple of times that I am planning to build a work-alike to the PDP-8 digital computer. My analog computer construction is temporarily on the back burner again as I wait for a batch of PCB's and semiconductors to arrive. In the meanwhile I have been working on an off on the design of the digital machine. I've done a reasonable amount of prototyping on the bench to verify the constructional blocks of the machine and have the complete specification sorted out. Most of the logic flow diagrams are also worked out.
It's going to be a 12-bit machine with 4096 words of 12-bit memory but a reduced version of the PDP-8's instruction set. One of the "building blocks" I am currently working on the the universal bidirectional 12-bit shift register, for the machines accumulator and program counter. With the exception of the computers memory, the circuitry is going to be entirely discrete transistor.
The heart of the register is 12 clocked data-input, edge triggered flop-flops with control and signal steering logic. The data-flop flops themselves are reasonably complex; each flop-flop consisting of coupled slave and master R-S flop-flop with steering logic to give an edge triggering capability to the clock input that is wholly insensitive to propagation delays. The slaved R-S flop-flop forms a memory element for the data present at the instant of the clock edge.
Here is screen shot of the complete simulation I have up and running of the shift register:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96773;image)
And here it is in operation:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96775;image)
At t=1.3mS the serial data input (second trace from the top) goes high for three clock periods. Consequently 3 active-high bits are shifted through the 12 bits of the register at each successive clock interval. At t=2.7mS, one clock cycle before the last bit is shifted out of the register, the shift-left control input is asserted (third trace from the top) and the data bit is shifted through the register in the opposite direction. This shift register is in fact a universal design which is parallel-programmable, with 12 parallel preset inputs (P0 through P11) in addition to the 12 parallel data outputs (D0 through D11). In the simulated case here the P0-P11 inputs are wired to the D0-D11 inputs to give the reverse ("left") shifting capability (Q1 to P0, Q2 to P1, Q3 to P2, Q4 to P3, etc...)
So here you have the mechanism for the micro-instructions RAL and RAR - rotate accumulator left and rotate accumulator right.
One thing to note is that the entire register (as well as nearly all of the rest of the computers logic) is constructed with a 2 basic building blocks - NAND gates and inverters!:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96777;image)
The universal inverter stage is identical to the universal NAND gate, minus an input diode.
Of course all of the above constitutes only a very small part of the project. ATM I am finalizing a PDP-1-like front panel layout for the control console, to send off to Front Panel Express. If there is sufficient interest in such a project I may keep this thread updated as i plod along, perhaps starting next with the machines specification and layout and logic diagram of the shift-resister and the clocked data flip-flops, when I have some more spare time......
-
Very interesting. Did you consider using transparent latches instead (clocking on both positive and negative edges), you may be able to cut the number of components in half.
There's also this circuit for an edge-triggered flipflop (http://en.wikipedia.org/wiki/File:Edge_triggered_D_flip_flop.svg) which has only 6 NAND gates and could also reduce the number of transistors needed.
-
Hmmm... My flop-flop consists of 8 NAND gates plus and inverter. I did experiment with some other arrangements, but I like this one the best because it has a large enough propagation delay safety margin (slave latch timing to the Q output propagating back to the Data input) to be bullet proof assembled from discrete transistor circuitry.
I'm not sure how to simply make a shift register with transparent latches; all instances I've seen with transparent latches are affairs with delay lines and restrictive timing requirements. For example:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96779;image)
Though not the same circuitry my design is topologically (I/O and control) identical to the SN7495, though expanded from 4 stages to 12.
-
Each master-slave flipflop looks like a pair of transparent latches, and one is transparent while the other is latched i.e. one is controlled by the clock, the other by the inverted clock. The signal between these two can also be thought of as storing a bit; so effectively your 12-bit shift register clocked on one edge is a 24-bit shift register clocked on both edges. You only need one (more powerful) inverter to generate an inverted clock for every other latch.
-
Each master-slave flipflop looks like a pair of transparent latches, and one is transparent while the other is latched i.e. one is controlled by the clock, the other by the inverted clock. The signal between these two can also be thought of as storing a bit; so effectively your 12-bit shift register clocked on one edge is a 24-bit shift register clocked on both edges. You only need one (more powerful) inverter to generate an inverted clock for every other latch.
Yes, that is how it works, but the data stored on the slave flip-flops is delayed by a clock cycle, so those 12 "extra" bits are not part of the valid output.
A data flip flop with an edge-triggered clock input is always comprised itself of a master transparent latch and one or more transparent slave latches to provide the clock-edge "instant" memory. However the composite edge-triggered flip-flop thus created (which is the building block for the synchronously-clocked shift register) is not itself transparent. The flip-flops of a synchronous shift register must not be transparent, but edge-triggered for proper operation.
Consider the simplest shift register of them all :) , a 1-bit divide by 2 counter:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96818;image)
At the instant the clock input goes high, the logic state of the NOTQ output, as presented to the D input, is transferred to the Q output. This simple circuit cannot work with a data flip-flop that is transparent. The state of the D input at the rising edge of the clock must be latched into a slave memory before the logic state change has a chance to propagate through to the NOTQ output. In other words, the edge-triggered flip-flop must retain a memory for the previously clocked logic state.
True though that I could perhaps save on inverter stages as currently each of the 12 composite edge-triggered flip-flops has its own inverter for the complementary clock signal, but this was done for reasons not apparent in the SPICE simulation. I have not yet decided upon the exact degree of modularization and interconnection of of the various logical "building blocks".
-
Does anyone know where I can get toggle switches with actuation levers like this from?
http://en.wikipedia.org/wiki/EDUC-8#mediaviewer/File:EDUC-8_Microcomputer.jpg (http://en.wikipedia.org/wiki/EDUC-8#mediaviewer/File:EDUC-8_Microcomputer.jpg)
-
Linked the images directly from their web page (I Know they might disappear and not the proper thing to do, but then the links wouldn't work either)
http://www.tedss.com/2027000895 (http://www.tedss.com/2027000895)
(http://www.tedss.com/stock/images/2027/2027000895.jpg)
http://www.tedss.com/2027000276 (http://www.tedss.com/2027000276)
(http://www.tedss.com/stock/images/1994/1994001742.jpg)
http://www.tedss.com/2027000185 (http://www.tedss.com/2027000185)
(http://www.tedss.com/stock/images/1994/1994000596.jpg)
http://www.tedss.com/2027000459 (http://www.tedss.com/2027000459)
(http://www.tedss.com/stock/images/2027/2027000459.jpg)
http://www.tedss.com/2027000487 (http://www.tedss.com/2027000487)
(http://www.tedss.com/stock/images/2027/2027000487.jpg)
http://www.tedss.com/2027000194 (http://www.tedss.com/2027000194)
(http://www.tedss.com/stock/images/1994/1994000800.jpg)
http://www.tedss.com/2027000195 (http://www.tedss.com/2027000195)
(http://www.tedss.com/stock/images/1994/1994000858.jpg)
http://www.tedss.com/2027000398 (http://www.tedss.com/2027000398)
(http://www.tedss.com/stock/images/2027/2027000398.jpg)
They seem to have miniature ones too:
http://www.tedss.com/MT-SPDT-7101 (http://www.tedss.com/MT-SPDT-7101)
(http://www.tedss.com/stock/images/2027/2027000485.jpg)
http://www.tedss.com/2027000815 (http://www.tedss.com/2027000815)
(http://www.tedss.com/stock/images/1990/1990005686.jpg)
Probably more, there are 34 pages of miniature switches:
http://www.tedss.com/Switches/Browse/toggle-switch-miniature (http://www.tedss.com/Switches/Browse/toggle-switch-miniature)
And 17 pages for full size ones:
http://www.tedss.com/Switches/Browse/toggle-switch-full-size (http://www.tedss.com/Switches/Browse/toggle-switch-full-size)
-
Does anyone know where I can get toggle switches with actuation levers like this from?
http://en.wikipedia.org/wiki/EDUC-8#mediaviewer/File:EDUC-8_Microcomputer.jpg (http://en.wikipedia.org/wiki/EDUC-8#mediaviewer/File:EDUC-8_Microcomputer.jpg)
I think the key term is 'paddle', at least it seemed to be when I was looking for similar for my daft computer project. I settled for some considerably-smaller models from NKK (GW12Lxx, from memory), for space reasons, although they have bigger; I think I also saw some from TE in the sort of size you're probably after, as well as unbranded cheapies on eBay…
(Also going to put my name in the 'certainly interested in this' column, if that helps. Would definitely be good to see how your front panel comes out, as I'm thinking of using Front Panel Express for mine too!)
-
Ah, paddle....... though not on E14's parametric search. I gave up after wading through a few hundred generic toggle and rocker switches.
This series from C&K looks perfect:
(http://www.tedss.com/stock/images/2027/2027000487.jpg)
Thanks...
I'll post up photos of my front panel when it arrives. Of course I need to find the right switches before I can finalize the layout. However reviewing my computers specification and thinking it over the past two evenings I am now procrastinating over whether or not to stick to the current 12-bit "PDP-8" specification or to scrap the current control panel layout and begin again to a 16-bit specification. Of course, with 16-bits it will no longer be a PDP-8 work-alike. The reason I am contemplating shifting to 16 bits is because it means that I can significantly simplify the memory addressing and make a whole machine cycle redundant.
The current specification, as per the PDP-8, uses 3 bits of the 12 bit instruction word (IW) for the instruction code. For memory-reference instructions, of which there are 6, 7 bits address the operand directly. This means that only 128 words of the 4096 word memory is directly addressable. The two remaining bits of the IW, designated I and Z, are used for memory page control. Z=1 concentates the 5 MSB's of the current IW address location with the 7 address bits of the IW to give a 12-bit address number, giving fiddly and limited access to the full 4096 words. I=1 activates indirect addressing, in which the 7 address bits of the IW do not specify the memory location of the operand, but instead point to a memory location containing a 12-bit word specifying the memory location of the operand.
Indirect addressing requires an additional machine cycle and complicates the control logic significantly. In my specification the three machine cycles are fetch, defer and execute. Defer is only enacted for indirect addressing. If I increase my computers bit length to 15-bit, I'd have enough bits in an IW to address the full 4096 words of memory directly. The defer machine cycle and attendant control logic would be rendered redundant. 15-bit is divisible by 3 and is thus nice and neat in octal representation 32767 dec. = 111 111 111 111 111 bin. = 77777 oct. However I think more in hex so I think 16 bits just feels more right.
However with 16 bits I could increase my memory specification from 4096 words to 8192 and still maintain direct addressing of the full memory. I have to spend the rest of my day off now cutting lawns and hedge trimming. I'll ruminate over the decision of 12 or 16 bits a little longer...........
What MCU is basis for your computer project?
-
Might be of interest but several people on the vintage-computer.com forum are building PDP8 look alikes.
Not a machine I know anything much about, but why is it so popular? The PDP11 seems a vastly more elegant design.
-
Depends what you want to do; if you just want to build a working computer then 12 bits (or 8) would be enough. If you go to 16 bits and make it PDP-11 compatible, maybe you could even run an early Unix on it.
-
Yeah, but the PDP-11 came to the market around 10 years later I think. The PDP-8 was the first really successful "minicomputer", so its own special place in history.
I've decided to do my own thing and go the 16-bit route with my design. Some of my switch components have already turned up and attached is a *.pdf of how far I have gotten so far with the new front panel design. There's enough detail on it already to make most of the computers specification clear (including all of the instructions). I don't have the time to collate my books of notes in a presentable form right now though; so just a minor progress update ;)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=97383;image)
-
Oh, and here is the discrete diode-transistor-logic, edge-triggered DFF that I built for evaluation. The scope traces are clock in (negative edge trigger) in yellow and the Q output in blue. The NOTQ output is wired to the D input, so the DFF acts as a divide-by-2 counter. Propagation delay from CLK in to Q out is approx 100nS.
The logic runs from power supply voltages of +15V and -10V while the logic high level is a little under 4V - clamped at 5 Si diode drops. This is a design technique that dates back right to the first bipolar transistor computers - it gives much improves power supply noise/spike immunity. In the high state, the output voltage is diode-clamped, so fluctuations on the positive supply rail are not transmitted to the logic output. Also a negative supply rail is utilized to enable the switching transistor Vbe junctions to be reverse biased in the off state (in the case here by ~1 Si diode drop). This greatly improves the logic gates immunity to ground noise/bounce/spikes/etc. These kind of design details are important when you are dealing with switching logic circuity drawing amperes of current and spread out over large areas due to the physical bulk of all those discrete through-hole components.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=97387;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=97389;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=97391;image)
-
While you are at the design stage why not reinvent the original IC and make a small package scale device that has one or two logic elements on it, sort of like a discrete IC. That way it will be easier to simply have a baseboard with the interconnects and simply solder the mini boards to it, like the original computers did. SMT with a SIL type format will be pretty high packing density, and still easy enough to troubleshoot.
-
I've always admired these kinds of projects. Totally impractical, but just so cool. 8) In a really nerdy kind of way, of course. If I didn't have a hundred (practical) projects on my to-do list, I would love to build a computer from scratch.
BTW, have you ever ordered from FPE? I have a few subwoofer plate amps I've had made from them. They do good work. Gets pricey really quick though, and I really wish they would do silk screening.
-
Yes, I have ordered from FPE before. The only thing in which they have been remiss is packaging. I had to spend half an hour with a rubber mallet and a blanket to straighten my last panel. It was posted just sandwiched between sheets of cardboard.
-
There's also this circuit for an edge-triggered flipflop (http://en.wikipedia.org/wiki/File:Edge_triggered_D_flip_flop.svg) which has only 6 NAND gates and could also reduce the number of transistors needed.
After some further analysis and prototyping, that has become my DFF of choice for this project. Unlike the 8-AND plus 2-INV "Master/Slave" DFF, that one is pure edge-triggered, rather than just edge-triggered, to use the established nomenclature, which is preferable due to the absence of "ones catching" and thus greater noise immunity. It's quite an ingenious circuit. I've done a comprehensive timing analysis and it's virtually immune to race conditions and totally robust even built sloppily with discrete DTL NAND gates.
There is a slight variation of the circuit to transform it into a JK FF, which is is now the basis of my synchronous counters. Asynchronous Set and Clear inputs are also easily added to both D and JK variants without having to add additional gates (just an extra input to several). More details in the not too distant future.....
-
I've spent a lot of time procrastinating over the physical construction of this machine, and here is what I have finally come up with. It's a PCB card frame scheme that I can fabricate with my limited home workshop facilities and works out a great deal cheaper than any commercially available system; eg Eurocard.
My plug-in circuit cards are 300mm X 150mm with DIN41612 connectors. The rear panel of the card frame will form a hardwired backplane. I've managed to construct one of the intermediate card frame shelves so far. This card frame is to be mounted into a 19" relay rack. No use for further words as pictures reveal enough.......
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101028;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101030;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101032;image)
-
Oh, and I've just finished the computers front/control panel design. Here it is. Time for dinner now though. It just needs double checking after a break and then I will send it off to FPE for manufacture.
https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101246 (https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101246)
EDIT: attachment updated
-
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96779;image)
This bibliophile needs to know what book this is.
-
This bibliophile needs to know what book this is.
Pulse, Digital and Switching Waveforms, Millman and Taub.
Also see the chapter on registers and counters in this (now public domain) book (for said building blocks realized with time delays rather than, as yet uninvented, edge-triggered flip flops).
https://ia600304.us.archive.org/20/items/DesignOfTransistorizedCircuitsForDigitalComputers/pressman.djvu
-
Thanks!
-
Here is a question for any old timers out there with PDP experience ;D
Although my computers specification and logic design is already done and I am not going to change it, does anyone know why the micro instructions of the OPR (operate) instruction were not simply binary encoded? I mean, it just seems odd to toggle a specific bit to enable a specific micro instruction. And then of course there isn't enough individual bits for all of the micro instructions, so they are divided up into groups that are selected by toggling 2 other bits.
My computer has 13 micro instructions (well 14 including NOP, which is enabled by setting all free bits 0), but I don't have to worry about grouping as my instruction word is 16-bits, and that gives 13 free bits minus the 3 for the operation code. My priority system for combined micro instructions operates independently of the instruction decoder. However if I was designing a computer with an extended instruction set, such that I did not have enough individual bits to toggle all of my micro instructions, it would seem much more logical to simply binary encode the micro instruction selection rather than dividing them into groups and sticking with bit-toggling.
-
... it just seems odd to toggle a specific bit to enable a specific micro instruction. And then of course there isn't enough individual bits for all of the micro instructions, so they are divided up into groups that are selected by toggling 2 other bits.
... if I was designing a computer with an extended instruction set, such that I did not have enough individual bits to toggle all of my micro instructions, it would seem much more logical to simply binary encode the micro instruction selection rather than dividing them into groups and sticking with bit-toggling.
I assume you mean PDP-8 (e.g. PDP-15 has 18 bit instructions and more opcode bits). The PDP-8 group 1 operate instructions (http://en.wikipedia.org/wiki/PDP-8#Group_1) are bit-encoded both for simplicity of implementation (e.g. big decoders or ROMs would have had to be made out of lots of diodes), and because they can be combined in a single operation to give specific operations or values (e.g. on a PDP-8/I you could combine CLA CLL RTL IAC [7307] to generate the value 4 in the accumulator; I'm told this didn't work on the original /8 because rotating and incrementing the accumulator couldn't be combined). CLA CLL CMA RAR [7350] would set the accumulator to 3777 (the most positive number). CMA IAC [7041] (complement and increment the accumulator) was idiomatic for taking the 2's complement (arithmetic negative) of a value. And so on (http://dustyoldcomputers.com/pdp-common/reference/host/idioms.html).
In the group 2 operate instructions (http://en.wikipedia.org/wiki/PDP-8#Group_2.2C_Or_Group) you can likewise combine the skip bits to put together composite conditions: SMA SZA SNL would skip if any of the conditions SMA (Minus Accumulator: high bit of accumulator is set), SZA (Zero Accumulator), or SNL (Nonzero Link) was true. If you just added two positive values then SMA SNL skips if there is an overflow condition. The AND group bit merely complements the result of the OR group conditions. It's clever and takes few diodes and transistors to implement as compared to making a big decoder. Work it out in terms of gates and you will see how simple a design it is.
-
You can still combine micro instructions with binary encoding, and with even greater flexibility. With binary encoding the micro instructions can be weighted to define their priorities, which does mitigate the extra complexity of the required instruction decoding to some degree, and you're then not confined to being able to only combine micro instructions within a single group, which, upon superficial examination, seems to me the greatest limitation of the PDP8 specification.
At least that is how I drafted it out in block diagram before opting for a slightly reduced instruction set selected in the traditional (albeit ungrouped) way with my 13 bits. I would love to do an extended instruction set with binary encoding and unrestricted, albiet prioritized combination, but I have to rationalize the specification and complexity to some point. I am just a single person with a single soldering iron building something in his free time.
-
The PDP-8 was an outgrowth of the PDP-5, which was intended to be the smallest usable computer that could be built at the time. Programming it was *supposed* to suck >:D .
Lots of things could be done with the basic architecture type represented by the PDP-8. What you have designed sounds more like some of the 18-bit machines that DEC built (PDP-4, PDP-7, PDP-9, PDP-15 (http://simh.trailing-edge.com/docs/architecture18b.pdf) all able to run programs for the earlier machines in this group; they learned how bad incompatibility was when they built the PDP-4 that wouldn't run PDP-1 code). On those, the operate instruction included the skips, clears, complements, rotates, etc. all in one bit-programmed instruction. DEC never did build a 16-bit machine of this type, although they discussed the PDP-X (http://simh.trailing-edge.com/docs/pdpx.pdf). They effectively dropped the single accumulator architecture and built the PDP-11 instead.
Also, keep in mind the level of technology DEC was using when the PDP-5 and (follow-on) PDP-8 (http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/guide.shtml#CPUHalf) were designed and built. Check out these images of PDP-8 modules (http://www.oldcomputers.arcula.co.uk/pdp82.htm) made out of diodes, resistors, and transistors on tiny PC boards laid out by hand. You needed 13 of those R210 module (http://www.computerhistory.org/collections/catalog/102716314)s for the accumulator and link bit. The R211 module (http://www.computerhistory.org/collections/catalog/102618996)s hold a bit each of the memory buffer, memory address, and program counter registers. There were no decoder chips, no ROMs, no programmable logic chips of any kind...
-
The PDP-8 was an outgrowth of the PDP-5, which was intended to be the smallest usable computer that could be built at the time. Programming it was *supposed* to suck >:D .
At least they didn't go to this extreme:
http://en.wikipedia.org/wiki/One_instruction_set_computer (http://en.wikipedia.org/wiki/One_instruction_set_computer)
-
After re-reading the whole thread I have discovered that you appear to have eliminated both zero-page and indirect addressing. I understand that you believe this will simplify the machine substantially. But if JMS works like it does on the PDP-8, PDP-15 etc (i.e. saves the return address at the jump target address and begins executing from the next word), how will you return from a subroutine without an indirect jump? I guess you could make the JMS instruction save a JMP instruction that included the return address, instead of the bare address. I suspect the loss of indirection will greatly reduce the power of the instruction set, since you also have no indexing capability. How do you grab, say, the nth word from a table in a loop? I think you will have to increment the address in an instruction, or something... Of course, if there is more than one access then you have to fix them all.
I want to give an example of how important indirect addressing was on the PDP-8. If I recall correctly, the PDP-8 FORTRAN system called a subroutine by using a JMS instruction followed by a list of pointers to the arguments. So the called routine would first use the address saved by the JMS instruction to locate the address of the first argument, then increment the saved address to point to the address for the next argument, etc. When all argument addresses had been fetched then the saved address had also been updated to point to the next instruction in the calling program. When the subroutine was done it would return by an indirect jump through the updated address saved by the calling JMS instruction. This would have taken a lot of instruction arithmetic and self-modifying code to do without indirect addressing.
-
@GK
How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?
-
After re-reading the whole thread I have discovered that you appear to have eliminated both zero-page and indirect addressing. I understand that you believe this will simplify the machine substantially. But if JMS works like it does on the PDP-8, PDP-15 etc (i.e. saves the return address at the jump target address and begins executing from the next word), how will you return from a subroutine without an indirect jump? I guess you could make the JMS instruction save a JMP instruction that included the return address, instead of the bare address. I suspect the loss of indirection will greatly reduce the power of the instruction set, since you also have no indexing capability. How do you grab, say, the nth word from a table in a loop? I think you will have to increment the address in an instruction, or something... Of course, if there is more than one access then you have to fix them all.
I want to give an example of how important indirect addressing was on the PDP-8. If I recall correctly, the PDP-8 FORTRAN system called a subroutine by using a JMS instruction followed by a list of pointers to the arguments. So the called routine would first use the address saved by the JMS instruction to locate the address of the first argument, then increment the saved address to point to the address for the next argument, etc. When all argument addresses had been fetched then the saved address had also been updated to point to the next instruction in the calling program. When the subroutine was done it would return by an indirect jump through the updated address saved by the calling JMS instruction. This would have taken a lot of instruction arithmetic and self-modifying code to do without indirect addressing.
Yes, you are right. Without indirect addressing there is no point in having the JMS command in addition to the JMP command. The return address stored at the beginning of the subroutine called by JMS cannot be shifted into the program counter register if you can't enact the JMP command with indirect addressing at the conclusion of the subroutine - so you may as well have just JMP-ed to the subroutine in the first place. Without indirect addressing JMS is redundant! I was so consumed in other parts of the hardware design I overlooked this. There is quite a bit to contemplate figuring out the whole computer down to the individual transistor level and its easy when getting thoroughly bogged down in the hardware design to start overlooking even obvious things on the abstract level.
Removing indirect addressing however did not turn out to simplify things an awful lot - just removed a handful of gates and a couple of DFF's to flag to a "defer" state, running an additional machine cycle to perform the additional operand fetch from memory.
Hardware wise, it's really not a big deal at all. I decided last night not to send my front panel design off to FPE just in case something like this comes up - good decision! I will re-implement indirect addressing. I will have to ditch one of my OPR micro instructions however, unfortunately, as I will need a free bit to specify indirect addressing. Then it probably wouldn't make sense to stick with 8192 words of addressable memory, as indirect addressing will give me access to the full 16 bits. That's not a big deal either - it just means 3 more stages to my (currently 13-bit) PC and MA (shift) registers and 6 additional LED's on the front panel (my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).
Which micro instruction would you sacrifice? I'm thinking OSR.
-------------------------------------------------------------------------------------------------
My current memory specification is 8192 words. Words 0 through 511 being R.O.M for peripheral interface firmware (e.g. tape-drive "bootstrap" and program saving subroutines for loading and storing programs.
Words 512 through 519 being dedicated locations for memory-mapped parallel I/O - four ports having 16 dedicated digital inputs and 16 dedicated digital outputs each. Output ports are words 512, 514, 516 and 518, each mapped to an individual output register. These memory locations can be read and written to just like any other location of R.A.M., but when written to data is simultaneously written to the associated output registers. Inputs are words 513, 515, 517 and 519. These memory locations can be written to but not read. Instead of reading from memory the computer reads the status of the digital input lines. This way the computer has comprehensive parallel I/O facilities without the need for any dedicated parallel I/O instructions.
-
@GK
How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?
The first digital computers used bipolar transistors!
-
(my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).
Oh good grief - how did I not know about that machine already? The design I'm working towards is a bit-serial contraption, too, which I knew couldn't exactly be novel - but I hadn't researched it in enough detail to discover DEC had built one...
(Actually that's cheered me up no end - they all said I was mad - well, who's mad now?! I really must get around to typing up some notes on what I'm doing, though, since you did ask earlier in the thread and I haven't had a chance to reply properly yet. Have been running a soak test on my 16x32-bit general-purpose register file for the last 40-odd hours, and it seems to be holding up, so it's time to crack on with building the ALU soon.)
-
@GK
How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?
The first digital computers used bipolar transistors!
I would have thought the first 'digital computers' used vacuum tubes?
-
There is quite a bit to contemplate figuring out the whole computer down to the individual transistor level and its easy when getting thoroughly bogged down in the hardware design to start overlooking even obvious things on the abstract level.
Removing indirect addressing however did not turn out to simplify things an awful lot - just removed a handful of gates and a couple of DFF's to flag to a "defer" state, running an additional machine cycle to perform the additional operand fetch from memory.
Hardware wise, it's really not a big deal at all. I decided last night not to send my front panel design off to FPE just in case something like this comes up - good decision! I will re-implement indirect addressing. I will have to ditch one of my OPR micro instructions however, unfortunately, as I will need a free bit to specify indirect addressing. Then it probably wouldn't make sense to stick with 8192 words of addressable memory, as indirect addressing will give me access to the full 16 bits. That's not a big deal either - it just means 3 more stages to my (currently 13-bit) PC and MA (shift) registers and 6 additional LED's on the front panel (my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).
Which micro instruction would you sacrifice? I'm thinking OSR.
I don't know why you need to change the operate instructions. I think you need an indirect bit in each of the memory reference instructions. Take the bit just right of the opcode for indirect addressing. That would shorten the address part of each memory reference instruction to 12 bits, so I suppose you would just do current page addressing with 4KW pages (i.e. the higher order bits come from the program counter). Here's an exercise that shows why you need indirection: write a subroutine to save 100 temperature readings in a table in memory. Get each reading by calling a subroutine named TEMPRD that returns the latest reading in the accumulator (don't worry about writing that one). You will discover that it is very hard to store values in consecutive memory locations on a machine that doesn't have either indexing through a register or memory indirection.
My current memory specification is 8192 words. Words 0 through 511 being R.O.M for peripheral interface firmware (e.g. tape-drive "bootstrap" and program saving subroutines for loading and storing programs.
ROM is tough on this kind of architecture because you can't save a return address in ROM. That was one of the things that the software people liked about the PDP-11: the implied stack for return addresses means you don't have to modify the program memory area.
The PDP-8 and 4/7/9/15 basically do a JMS to location 0 for an interrupt (http://homepage.cs.uiowa.edu/~jones/pdp8/man/intrupt.html), then you have to save everything else. Will your machine handle interrupts?
Words 512 through 519 being dedicated locations for memory-mapped parallel I/O - four ports having 16 dedicated digital inputs and 16 dedicated digital outputs each. Output ports are words 512, 514, 516 and 518, each mapped to an individual output register. These memory locations can be read and written to just like any other location of R.A.M., but when written to data is simultaneously written to the associated output registers. Inputs are words 513, 515, 517 and 519. These memory locations can be written to but not read. Instead of reading from memory the computer reads the status of the digital input lines. This way the computer has comprehensive parallel I/O facilities without the need for any dedicated parallel I/O instructions.
So if you have these why do you need the IOT instruction?
-
@GK
How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?
The first digital computers used bipolar transistors!
I would have thought the first 'digital computers' used vacuum tubes?
The 1st solid state computers of course
-
I don't know why you need to change the operate instructions. I think you need an indirect bit in each of the memory reference instructions.
Yes, of course. Posting off the cuff at ~ 1am. I will not need to sacrifice a micro instruction as indirect addressing is not used in the OPR instruction.
ROM is tough on this kind of architecture because you can't save a return address in ROM. That was one of the things that the software people liked about the PDP-11: the implied stack for return addresses means you don't have to modify the program memory area.[/i]The PDP-8 and 4/7/9/15 basically do a JMS to location 0 for an interrupt (http://homepage.cs.uiowa.edu/~jones/pdp8/man/intrupt.html), then you have to save everything else. Will your machine handle interrupts?
My RAM for programs starts at location 520. It doesn't matter that return addresses cannot be stored to the ROM locations. The ROM subroutines are not intended to be called by programs being run. They are to be manually run by the user - eg to load or save a program from magnetic tape. Each firmware subroutine terminates with a HLT command. Interrupts are not included in my specification, but if I later decided to add such hardware, an interrupt would jump to location 520.
Words 512 through 519 being dedicated locations for memory-mapped parallel I/O - four ports having 16 dedicated digital inputs and 16 dedicated digital outputs each. Output ports are words 512, 514, 516 and 518, each mapped to an individual output register. These memory locations can be read and written to just like any other location of R.A.M., but when written to data is simultaneously written to the associated output registers. Inputs are words 513, 515, 517 and 519. These memory locations can be written to but not read. Instead of reading from memory the computer reads the status of the digital input lines. This way the computer has comprehensive parallel I/O facilities without the need for any dedicated parallel I/O instructions.
So if you have these why do you need the IOT instruction?
IOT is for serial communications. I have 16 serial IO ports.
-
(my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).
Oh good grief - how did I not know about that machine already? The design I'm working towards is a bit-serial contraption, too, which I knew couldn't exactly be novel - but I hadn't researched it in enough detail to discover DEC had built one...
(Actually that's cheered me up no end - they all said I was mad - well, who's mad now?! I really must get around to typing up some notes on what I'm doing, though, since you did ask earlier in the thread and I haven't had a chance to reply properly yet. Have been running a soak test on my 16x32-bit general-purpose register file for the last 40-odd hours, and it seems to be holding up, so it's time to crack on with building the ALU soon.)
A predominantly serial architecture simplifies the hardware a lot, especially when your computer is 16-bits or more, though the operating speed is of course a lot slower.
Go to the siliconchip.com.au (then:>shop>books&DVDs....) website and search for EDUC-8. They have a scanned book from 1975 which you can buy for ~$20AUD and download.
The EDUC-8 is a complete 8-bit computer with a reduced PDP-8 instruction set. The computer has a serial ALU and is implemented entirely in TTL logic. The book is a compendium of magazine articles from Electronics Australia magazine, giving full technical descriptions and constructional details for the computer and a number of peripheral devices including serial IO hardware such as magnetic tape and paper punch interfaces, keyboard and keypad.
My computer (thus dubbed “EDUC16”) is based on the same basic architecture, but expanded significantly - 16-bit rather than 8-bits, a "Link" AC-carry register to facilitate multiple precision arithmetic, much expanded serial I/O facilities, the addition of memory-mapped parallel I/O, firmware R.O.M, much larger memory, a greater number of micro instructions and expanded combinations, etc, etc....
-
Here's an exercise that shows why you need indirection: write a subroutine to save 100 temperature readings in a table in memory. Get each reading by calling a subroutine named TEMPRD that returns the latest reading in the accumulator (don't worry about writing that one). You will discover that it is very hard to store values in consecutive memory locations on a machine that doesn't have either indexing through a register or memory indirection.
Yes, I am sold on the indirect addressing. It was silly to omit the "defer" machine state used for indirect addressing anyway, as the hadware was simplified only very minimally. Although it is not in my current specification an auto indexing register may also be on the cards in the future. All that needs is an additional 16-bit counter and some minor additional control logic.
-
OK, now I have completed the front panel layout:
https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101246 (https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101246)
I have increased the MA and PC counters from 13-bits to 16-bits as the memory has grown from 8192 words to 65535, adding the 3 additional indicator LEDs for both registers. I have also updated the switch register legend to indicate the indirect bit for the memory-reference instructions. A silly oversight the first time around was to forget the machine state status indicator LEDs. These (run/fetch/defer/execute) have now been added (top right hand corner of the panel).
As mentioned previously, this computer is going to be built into a 19" relay rack. There is going to be a little carpentry involved as the front panel is going to be mounted at an angle of 45 degrees, protruding from the front of the cabinet with a miniature table immediately beneath and in front of. The idea is that you can pull up a chair to the control panel and have a small space for a pen and paper.
-
(my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).
Oh good grief - how did I not know about that machine already? The design I'm working towards is a bit-serial contraption, too, which I knew couldn't exactly be novel - but I hadn't researched it in enough detail to discover DEC had built one...
(Actually that's cheered me up no end - they all said I was mad - well, who's mad now?!
The bad news is that the PDP-8/S did not do well in the marketplace. It was not quite completely capable of running straight 8 programs, and was too slow. In fact, it was so slow that it could not successfully operate certain common DEC mass storage peripherals (e.g. TU-55 DECtape transport).
The Data General Nova, on the other hand, was sold as a 16-bit minicomputer but the original model actually had only a 4-bit ALU which had to cycle 4 times to complete each 16-bit operation. Due to newer technology, It was cheaper and fast emough, and beat the competition on price/performance, so it did OK.
-
On a lighter note a friend of mine, in the 70's acquired an early PDP, 8 I think, which substituted as his room heater.
Ferrite core memory too no less.
-
Each master-slave flipflop looks like a pair of transparent latches, and one is transparent while the other is latched i.e. one is controlled by the clock, the other by the inverted clock. The signal between these two can also be thought of as storing a bit; so effectively your 12-bit shift register clocked on one edge is a 24-bit shift register clocked on both edges. You only need one (more powerful) inverter to generate an inverted clock for every other latch.
Yes, that is how it works, but the data stored on the slave flip-flops is delayed by a clock cycle, so those 12 "extra" bits are not part of the valid output.
A data flip flop with an edge-triggered clock input is always comprised itself of a master transparent latch and one or more transparent slave latches to provide the clock-edge "instant" memory. However the composite edge-triggered flip-flop thus created (which is the building block for the synchronously-clocked shift register) is not itself transparent. The flip-flops of a synchronous shift register must not be transparent, but edge-triggered for proper operation.
Consider the simplest shift register of them all :) , a 1-bit divide by 2 counter:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=96818;image)
At the instant the clock input goes high, the logic state of the NOTQ output, as presented to the D input, is transferred to the Q output. This simple circuit cannot work with a data flip-flop that is transparent. The state of the D input at the rising edge of the clock must be latched into a slave memory before the logic state change has a chance to propagate through to the NOTQ output. In other words, the edge-triggered flip-flop must retain a memory for the previously clocked logic state.
I should correct myself on two points here. Upon further reading the convention appears to be to use the terms "master" and "slave" the opposite way around to what I did. Also the correct name for a DFF is delay flip-flop, not data flip-flop.
Anyway, here is the DTL positive-edge-triggered delay flip-flop with asynchronous preset and clear that I have settled on for the basis of my registers. It is functionally equivalent to the TTL 7474.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101476;image)
To this DTL DFF circuit I have deliberately added a controlled CLK-IN-to-Q-OUT propagation delay by means of R618/R619 and C169/C170, for reasons explained in a bit.
With the addition of 16 NAND gates and 10 inverters, 16 of the DFF building blocks form the complete register of my Program Counter. SR0 through SR15 are the parallel-load inputs from the Switch Resister (the 16 data-input toggle switches on the computers front panel). Parallel outputs PC0 through PC15 are exclusively used for illuminating the PC register LED's on the front panel. The computers architecture is serial, and communication between the PC and other registers is serial. The PC is incremented by circulating the data from the PC through the serial adder of the ALU and then back into the PC while reading the contents of the PC out into the MA (memory address register). A carry input flag for the serial adder is initially set to 1 during this process, thus the PC is re-loaded with its original data + 1.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101478;image)
The clock, preset (now actually parallel-load) and clear control inputs are divvied up with the inverters for fan-out/drive capability reasons. Here is a complete simulation of the register in action:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101480;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101482;image)
At t=0 the CLR.H control input (uppermost trace) is asserted, resetting all of the registers flip-flops. At t=3uS the PRESET.L is asserted, loading the contents of the SR (1000100010001000 bin ) into the register. At t=5uS the clock cycles begin and the data is sequentially shifted out LSB first. In this simulation I have routed the serial data output to the the serial data input, so the loaded 16-bit word just keeps circulating around the register.
The PC register complete is comprised of:
764 diodes
122 transistors
489 resistors
and 139 capacitors (not including bypass).
This is too much to fit onto a single PCB card. The reason I added the increased clock-to-Q propagation to the DFF design is to ensure that the complete logic of the register is robust when built in the real world. The potential issue is that the master clock to the DFF's, which is divvied up into to 4 sets of 4 due to fan-out, may not clock all 16 flip-flops in entire synchronicity. Suppose (just for example) you hang a 1:1 oscilloscope probe off one of the 4 clock lines. The load capacitance from the probe and lead will delay the rising edge of the clock to the associated 4 flip flops of the register. If that clock has been delayed enough such that a logic state change of the Q output (of the DFF immediately preceding the first DFF of the clock-delayed bank) has already propagated through, the first DFF of the delayed bank will latch to an incorrect logic state. Recall that the correct operation of an edge-triggered DFF relies upon the fact that the logic state of the D-input is internally committed to memory before being transmitted to the "slaved" Q (and Not-Q) outputs. There isn't an issue if you're just wiring up a single DFF, with Not-Q wired to D, to act as a divide-by two counter, but things potentially get a little more tricky when wiring up an bunch of DFF's to behave as a shift register as clock skews between DFF's can screw things up.
Adding a clock-to-Q propagation delay to each DFF sufficiently long in duration to accommodate a worse case synchronous clock skew between DFF's solves the issue. The amount of delay I have added with the component values in the presented DFF circuit is conservative. There is ample delay to cope with sever clock skew, which should, in my estimation, make the real-world implementation totally robust.
To experiment in the simulation of the register, I loaded one of the clock lines after the respective inverter with a capacitance (C7):
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101484;image)
Recall that the DFF's are positive-edge triggered. The active positive-edge of the clock is thus delayed by C7 charging through pull-up resistor R487. I have to increase the value of C7 to 450pF before the register can be induced into shifting false logic states.
I hope that is all making sense out there ;D I am about to start the PCB design for the cards of this register.
-
How much effort do you reckon will be needed for test? I'll be finished with the testing of a 16-bit CISC CPU implemented in Verilog this week and the whole testing process was a grind. Testing the individual modules was easy enough but testing each instruction then all of the addressing modes - ooofffff. It seems a third of the 250-odd microinstructions were incorrect. Doing this in Verilog with a simulator was a chore so I can't imagine what it's going to be like for you. More power to your elbow!
-
Could ECL be a simpler choice of logic family? I know it uses more power, but it's much faster and the gates take fewer components; you also get inverters and OR for free. Here's D flip-flop:
(http://what-when-how.com/wp-content/uploads/2012/02/tmpE505_thumb22222.jpg)
-
Could ECL be a simpler choice of logic family? I know it uses more power, but it's much faster and the gates take fewer components; you also get inverters and OR for free. Here's D flip-flop:
(http://what-when-how.com/wp-content/uploads/2012/02/tmpE505_thumb22222.jpg)
I haven't studied that circuit but is it transparent or edge-triggered? The circuit is simplified somewhat. For example the long tail pair current sources need a bias supply and emitter resistance, and the circuit would probably need to be increased in complexity significantly to add preset and clear inputs. Also for a discrete implementation the increased speed over DTL in synchronous circuits is not what you really want. For example the the clock skewing issue I mentioned in my prior post has to be handled by increasing the propagation delay of the DFF. For synchronous circuits such as shift registers the faster the DFF the greater the difficulty with clocking, timing and layout.
As a matter of fact, even in IC form it's an issue! To get around the problem I described designers of ECL IC's actually slowed down their circuits as well - but by limiting the slew rates rather than the internal gate propagation delays. From The Art of Digital Design, second edition, Prosser &Winkel, chapter 12, page 472:
"d. In the most convenient ECL family, the rise time of the gate outputs is purposely made slower than the internal propagation delay. This simplifies the clocking of synchronous circuits and greatly reduces electrical crosstalk."
-
How much effort do you reckon will be needed for test? I'll be finished with the testing of a 16-bit CISC CPU implemented in Verilog this week and the whole testing process was a grind. Testing the individual modules was easy enough but testing each instruction then all of the addressing modes - ooofffff. It seems a third of the 250-odd microinstructions were incorrect. Doing this in Verilog with a simulator was a chore so I can't imagine what it's going to be like for you. More power to your elbow!
Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!
-
Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!
Really? How many instructions then? I thought the PDP-8 had quite a few instructions and if it's a microcoded control unit it would need at least a few microinstructions per instruction and microinstructions for instruction fetch and interrupt polling. How do you get away with so few?
Edit: I've just checked and my microprogrammed GCD machine (http://www.barrywatson.se/dd/dd_microprogrammed_nonprogrammable_control_unit_gcd.html) has 6 microinstructions, nearly half of your CPU.
-
Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!
Really? How many instructions then? I thought the PDP-8 had quite a few instructions and if it's a microcoded control unit it would need at least a few microinstructions per instruction and microinstructions for instruction fetch and interrupt polling. How do you get away with so few?
I have the same 8 instructions of the PDP-8 and an only moderately reduced number of its microinstructions. To correct myself though I actually have 19 microinstructions if those of the IOT (input-output transfer) instruction are included.
Just like the PDP-8, only two of the 8 instructions have microinstructions (OPR and IOT).
The 6 memory reference instructions are:
AND
Logical and between operand and current contents of the accumulator (AC) register. Result stored in AC
TAD
Two's addition. Same as AND instruction, but performs binary addition (2's complement) rather than ANDing
ISZ
Increment and skip if zero. Content of memory location specified transferred into memory buffer (MB) register, then incremented by 1. Result transferred back to specified memory location. If result has become zero, program counter (PC register) incremented to skip next instruction in-line.
DCA
Deposit and clear AC. Stores content of AC in memory location specified, then clears AC
JMS
Jump to subroutine. Contents PC stored in specified memory location. Content of memory location specified then incremented by 1. Result transferred to PC.
JMP
Jump instruction. Content of memory location specified transferred to PC.
The OPR instruction, which does not reference memory has the following microinstructions:
IAC
Increment AC (self explanatory)
CLA
Clear AC (self explanatory)
CMA
Complement AC (self explanatory)
RAL
Rotate accumulator left. Contents of AC bit-shifted one step left. This operation includes the 1-bit Link (L) register, treating it as combined 17-bit register with the AC
RAR
As per RAL but shifts right.
SMA
Skip on minus AC. Tests bit 16 of AC. If =1 (indicating a negative number in 2's complement) PC incremented to skip next in-line instruction.
SZA
Same as SMA but PC incremented only if all bits of AC=0
OSR
Logical OR operation between switch register (SR) and contents of AC. Result stored in AC
CLL
Clear Link (L) bit (self explanatory).
CML
Complement L bit (self explanatory).
SNL
Skip on link bit. PC incremented to skip next in-line instruction if L=1
HLT
Halt (self explanatory).
That's a "RISC ;D" instruction set, but sufficient, with a little coding, to perform just about any major computer operation.
-
I've done a bit of googling and it seems the PDP-8 term "microinstruction" isn't the same as the "microinstruction" term I was using, in the sense of microcoded instructions. Apples and oranges. At least I can say I've learned something today.
-
Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!
Really? How many instructions then? I thought the PDP-8 had quite a few instructions and if it's a microcoded control unit it would need at least a few microinstructions per instruction and microinstructions for instruction fetch and interrupt polling. How do you get away with so few?
Edit: I've just checked and my microprogrammed GCD machine (http://www.barrywatson.se/dd/dd_microprogrammed_nonprogrammable_control_unit_gcd.html) has 6 microinstructions, nearly half of your CPU.
DEC referred to the bit-programmed operate instructions as "microprogrammed". Several bits in the instruction directly control what value gets gated onto the accumulator bus (0, accumulator, complemented accumulator, all 1s), can add 1 to the value, inputs to the shifter for rotating right or left 1 or 2 positions, etc. However, the CPU was implemented in random logic; there was no microprogram in the current sense of the word.
The bit programmed operate instruction concept appears on the DEC PDP-1, but the 1961 user's manual does not use the term "microprogrammed". The 1962 PDP-4 users manual refers to the operations controlled by the individual bits as "micro-instructions", and says that they may be "microprogrammed" together.
DEC didn't build a microprogrammed computer, in the current sense of that word, until around 1972; about 10 years later than the usage for the PDP-4/5/7/8/9/12/15.
-
Here's an interesting article on the first person to build a transistor based computer in Europe (1955).
http://news.slashdot.org/story/14/07/18/0253245/heinz-zemanek-passes-at-94 (http://news.slashdot.org/story/14/07/18/0253245/heinz-zemanek-passes-at-94)
I'd never heard of that one before.
Also wiki article.
http://en.wikipedia.org/wiki/List_of_transistorized_computers (http://en.wikipedia.org/wiki/List_of_transistorized_computers)
-
As promised, photos of the front panel (which arrived this morning). It will look a lot prettier once I have the LED PCBs installed. All switches are Multicomp "snap in" series.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=104521;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=104523;image)
-
Very nice looking!
Greetings,
Chris
-
Wow! Do I detect PDP11 overtones?
-
Love it.
-
Yeah, I was a bit apprehensive about the blue, but it turned out really nice.
-
Finally getting back to this project. Today I completed and tested and tweaked the 1st assembled, plug-in card:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=111830;image)
This is the low frequency "system clock" card. The computers operating (clock) speed is LED-indicated and user-set from the control panel, from 2 uS to 200 mS in discrete 1/2/5 steps. There will also be a high frequency clock source (selected by "EXT") that will operate at the highest frequency permissible (which will be finally determined once the whole computer is operational).
Being able to control the computers speed will be very useful when I'll eventually use the machine to automate processes on my (simultaneously under construction) analog computer.
This card provides 50% duty cycle clocks of 500 kHz (2 uS), 200 kHz (5 uS) and 100 kHz (10 uS). These are all derived from a 2 MHz, heated-crystal oscillator. Here is the schematic:
https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=111834 (https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=111834)
Q1 through Q10 form the calibrated 2 MHz heated-crystal reference (probably got a little carried away here).
Q11 through Q14 form a pair of cascaded toggle flip-flops which divide the 2 MHz down to the 500 kHz reference.
Q15 to Q23 form a three stage ripple counter which is reset on count 5 (decoded by NAND gate Q24) by a triggered reset pule produce by the ~120 nS monostable formed by Q25-Q27. This complete divide-by-five counter derives a 400 kHz clock from the 2 MHz master which is then divided down to 200 kHz and 100 kHz by a pair of further cascaded toggle flip-flops based on Q28 through Q31.
Transistors Q32, Q33 and Q34 are three open-collector-output NAND gates having their outputs commoned to form the actual clock output. Select lines to the NAND gates determine the output clock frequency.
A series of further multiplexed decade divider cards will provide the LF reference clocks for the 20 uS to 200 mS system clock settings. Then in addition to this is the actual selector card comprised of a decimal-decoded 1-or-16 BCD counter, user set by the control panel buttons for selecting the "system clock frequency". That will complete the computers LF clock. These cards are the next in line to be etched...................
I had originally planned to build a linear supply for the computers 15V 20A logic supply. However I eventually decided against this as the heat sinks took up too much rack panel space (and card frame access). I've now designed a switch mode supply for the 15V rail instead. Here is the control board:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=111832;image)
I decided to have a little fun here - this is actually a discrete TL494. The six (identical) TO-126 transistors bolted together are the comparison transistors for the Brokaw-style bandgap 5V reference regulator. 5 of the 6 transistors are connected in parallel to effectively give one transistor of a pair having an "emitter area" five times that of the other. With some heatsink compound between the transistor packages and the bolt through the middle keeping them all in close thermal contact, it actually turned out quite well and more than adequately stable. (about 20 mV drift to the +5V for a 20 deg C change in room temperature).
I'll have the companion power board for the 15V 20A rail loaded and operational once some parts on back-order arrive.
-
Made a start on the decade divider card for the programmable system clock. The 81 transistors and 228 diodes are soldered in place, and a few of the 138 capacitors. There are 5 stages of decade division on this card. Each decade divider consists of a divide-by-5 counter followed by a divide-by-2 toggle flip-flop. This gives decade division with a 50% duty cycle logic signal output. Then there a six individual DTL inverter stages acting as clock-in and clock-out signal buffers. The counter circuitry is a duplicate of that I've already posted for the system clock card. I've retained the high-speed, clamped-logic-level circuitry throughout, to the 200mS clock output, to ensure that all clock signals have the lowest practical jitter. I'm pleased with the component packing density I managed on this card. Tomorrow evening I'll get the 244 resistors soldering in and maybe some of the caps too.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113049;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113051;image)
-
Finally got the decade divider card finished.
The wee-little schematic diagram (the serious logic assembly hasn't started yet) here: https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113615 (https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113615)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113606;image)
Unfortunately I wasn't able to make a decent jitter measurement for the full five decades of division on my Rigol scope. The first stage of decade division triggers on the positive edge of the clock input. These scope photos (with infinite persistence) show the clock input (yellow trace) and the first decade (/10) clock output:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113608;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113610;image)
In both photos I'm triggering on the divider output and in the lower photo viewing the active edge of the clock input. There appears to be ~5nS of peak-peak jitter.
In the following photo I'm viewing the active edge of the clock input again, but this time against the /10,000 clock output. The clock input is 500 kHz and the output therefore 5 Hz (note the delay between the trace clock edges is greater than before as each decade divider has a ~40nS clock in-out delay):
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=113613;image)
The screen is only updating a several times per second due to the low frequency of the divided down output, but I would have though that given enough time, with infinite persistence enabled, I still should have gotten a plot of the net, accumulated peak-peak jitter of the five series-connected stages of decade division. However, as shown in the scope screen photo, no so at all. There should be at least a full horizontal division of peak-peak jitter there. It's getting onto midnight here and I have had a long day, but what am I missing?
-
I'm enjoying following your progress.
On a specific, regarding your 2MHz crystal oscillator, I can understand how most of it works, but could you explain the function of Q7?
-
Q7 is just a cascode that helps mitigate the Miller effect of Q5. It gives the amplifier a little extra bandwidth and less phase shift, although the benefit is only small as the base of Q5 is already driven from a low impedance source (unity gain buffer pair Q1 and Q2).
-
Q7 is just a cascode that helps mitigate the Miller effect of Q5. It gives the amplifier a little extra bandwidth and less phase shift, although the benefit is only small as the base of Q5 is already driven from a low impedance source (unity gain buffer pair Q1 and Q2).
Thanks for the explanation. Does that configuration of oscillator have a name? I usually just use a Colpitts.
-
Pierce oscillator.
-
@GK phase noise is additive only if there is threshold error, supply noise , Non-flat group delay or non-linear phase shift in detector or scope trigger.
Normally synchronous counters add no jitter to output unless skew in rise/fall time.
Whereas impulse harmonic multipliers add phase noise xNth harmonic.
Asynch or ripple counters will accumulate prop delay and jitter however.
-
The bad news is that the PDP-8/S did not do well in the marketplace. It was not quite completely capable of running straight 8 programs, and was too slow. In fact, it was so slow that it could not successfully operate certain common DEC mass storage peripherals (e.g. TU-55 DECtape transport).
The PDP-8/S may not have done well, but there were numerous specialised bit serial machines in the 60s and 70s. There were also massively parallel single bit architectures, like the MPP and ASPRO, which could be extremely effective in certain applications.
-
@GK phase noise is additive only if there is threshold error, supply noise , Non-flat group delay or non-linear phase shift in detector or scope trigger.
Normally synchronous counters add no jitter to output unless skew in rise/fall time.
Whereas impulse harmonic multipliers add phase noise xNth harmonic.
Asynch or ripple counters will accumulate prop delay and jitter however.
OK, but I'm looking at asynchronous ripple counters performing the frequency division. With an infinite persistence display the peak-to-peak clock-in-clock-out jitter through successive stages should roughly add as given enough time there will be coincident peaks, it's just that the DSO appears to mask the effect. I've repeated the tests on a 500 MHz LeCroy scope with the same results. I get ~5nS of p-p displayed jitter for the 1st (decade divider) stage and successively less p-p displayed jitter as I probe down the chain of cascaded decade dividers.
The attempted jitter measurement was just a curiosity, it has no real bearing on the commissioning of the clock circuitry.
-
Another card comes fresh from the etch tank. This is the control card for the programmable frequency system clock. It will look a lot prettier one it is drilled and then buffed up with steel wool prior to lacquering. The card contains a 4-bit binary counter with control logic that is set by the control panel buttons for system clock period/frequency selection. The card contains LED drivers and the 4-bit binary is (1-of-16) decimal decoded for the clock period LED indication on the control panel. The binary counter is also decoded to provided the control signals for the decade divider multiplexers (on another card) and the 1/2/5 multiplexer on the clock card.
Right now I'm laying out the Instruction Register and Decoder card. Then it will be either the bit-serial arithmetic logic unit card or the major state generator. I'm not progressing in any particularly logical order.......
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=115690;image)
-
http://omegataupodcast.net/2014/11/159-analog-computers/ (http://omegataupodcast.net/2014/11/159-analog-computers/)
-
Thanks, that podcast looks interesting, but unfortunately I'm almost out of download quota for the month, so will have to wait a little while.
As for the digital computer project, two additional PCB's emerged from the etch tank this afternoon. One is the instruction register and decoder card and the other is a 3-stage bi-directional, serial-in, serial/parallel-out shift register building block, 5 duplicates of which (plus 2 other cards containing the remaining two register stages plus associated control logic) will form the complete circuitry of the the Accumulator+Link registers.
-
... and the other is a 3-stage bi-directional, serial-in, serial/parallel-out shift register building block, 5 duplicates of which (plus 2 other cards containing the remaining two register stages plus associated control logic) will form the complete circuitry of the the Accumulator+Link registers.
Have that card loaded and tested now:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=119844;image)
The shift register that forms the accumulator register (plus the link bit register - the carry for multiple precision arithmetic) needs to be bi-directional so that both the RAR (rotate accumulator right) and RAL (rotate accumulator left) microinstructions can be executed. Except for the RAL microinstruction, the AC ordinarily operates as a right-shift storage register only.
I still have 4 duplicates of this card and two others to assemble before I have a complete and operational AC+L register, but for testing purposes, for this 3-stage card, I just looped the "right-shift serial output" to the "right-shift serial input" and the "left-shift serial output" to the "left-shift serial input" so that the 3-bits just keep circulating around the loop with a master (synchronous) clock applied.
Prior to applying the continuous clock the register was pre-loaded with binary 1 0 0. Here it is in right-shift mode. The traces from top to bottom are QA (also the left-shift serial output), QB, QC (also the righ-shift serial output) and master clock.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=119846;image)
Here it is in left-shift mode:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=119848;image)
-
Here is a (simplified) logic diagram for the complete Accumulator and Link register. When the RAR.L and RAR.L control signal inputs are both high, the sixteen Q15 through Q0 flip-flops simply act as 16-bit serial-in, serial/parallel-out shift register that operates completely independently of the single bit Link register. In this state the master clock is disconnected from the Link register flip-flop and the Link register has 2 active control inputs independent of the Accumulator register.
The control inputs are complement_link, set_link and clear_link. The link bit is complemented (toggled) by the control circuitry associated with the binary full adder part of the arithmetic logic unit whenever there is a carry after executing a TAD (two's complement addition) instruction. The Link bit is also complemented when the CML microinstruction (of the OPR main instruction) is executed. Microinstruction CLL (clear link bit) resets the Link bit to 0. There is no specific microinstruction to set the Link bit. To set the Link bit CLL and CML are simply programmed/executed in succession. My hand-drawn logic diagram shows a set.L input for the Link flip-flop, but this is not used in the final circuit as it is redundant.
The logic gets a little messy because the bit-shifting operations treat the Link and Accumulator as a single 17-bit register. When the RAR.L control input is asserted low by the instruction register and decoder card during an execute machine state, a clock input will rotate the entire contents Link and Accumulator of the one bit to the right:
Link>Q15
Q15>Q14
Q14>Q13
Q13>Q12
Q12>Q11
Q11>Q10
Q10>Q9
Q9>Q8
Q8>Q7
Q7>Q6
Q6>Q5
Q5>Q4
Q4>Q3
Q3>Q2
Q2>Q1
Q1>Q0
Q0>Link
When the RAL microinstruction is executed the same sequence of events occur, but the steering gates to the individual D-inputs of all 17 flip-flops switch over to the proceeding Q outputs rather than preceding, thus causing the register bit to rotate left instead:
Link>Q0
Q0>Q1
Q1>Q2
Q2>Q3
Q3>Q4
Q4>Q5
Q5>Q6
Q6>Q7
Q7>Q8
Q8>Q9
Q9>Q10
Q10>Q11
Q11>Q12
Q12>Q13
Q13>Q14
Q14>Q15
Q15>Link
The "Type C" circuit card of the AC+L, containing the AC register Q0 flip-flop also carries a 16-inout NOR gate which provides an Accumulator=0 output. This is used to execute the microinstruction SZA (skip on zero Accumulator).
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=119890;image)
EDIT: The forum software shrinks the (much larger than shown) image to fit on screen. You'll have to click the link below and download the file to view it at a readable scale.
-
I believe the way the original single accumulator DEC PDP-4, 7, 9, 15 machines handle operates is as follows: a combinatoric network detects skip conditions, and a multiplexer selects the input to the adder (which is only used to increment the accumulator during operate instructions). The output of the adder enters the shifter. This way the order of the functions is: skips, clears and complements, increment, then rotates. So CLA CLL IAC RTL gives a constant result of 4.
The skips are performed on the original contents of the accumulator and link. Note that these bits and their inverses are available (from the opposite transistors of each flip-flop). SMA should skip if the high order bit of the accumulator is non-zero. SZA can be tested by simply wire-anding the inverse of the accumulator bits together (diodes will do fine): if the result is zero then one of the bits in the accumulator is non-zero (so SZA should not skip). SNL skips if the link is non-zero.
The CLA and CMA bits select one of 4 possible inputs to the adder: CLA=0 CMA=0 gives the accumulator bit; CLA=1 CMA=0 gives zero, CLA=0 CMA=1 gives the inverse of the accumulator bit, CLA=1 CMA=1 gives one. The same thing is done for the link with the CLL and CML control bits.
The adder is fed the AC bits and a zero except that the IAC bit is used as the low-order bit (so 1 is added if IAC is set).
The shifter can perform one of five operations (six in late PDP-8's) based on the 3 control bits RAR RAL <rotate 2>.: pass-through (all 0), rotate right 1 bit (RAR=1, RAL=0, rotate 2=0), rotate right 2 bits (RAR=1, RAL=0, rotate 2=1), rotate left 1 bit (RAR=0, RAL=1, rotate 2=0), rotate left 2 bits (RAR=0, RAL=1, rotate 2=1).
The output of the shifter is clocked back into the accumulator at the end of the cycle.
-
I believe the way the original single accumulator DEC PDP-4, 7, 9, 15 machines handle operates is as follows: a combinatoric network detects skip conditions, and a multiplexer selects the input to the adder (which is only used to increment the accumulator during operate instructions). The output of the adder enters the shifter. This way the order of the functions is: skips, clears and complements, increment, then rotates. So CLA CLL IAC RTL gives a constant result of 4.
The skips are performed on the original contents of the accumulator and link. Note that these bits and their inverses are available (from the opposite transistors of each flip-flop). SMA should skip if the high order bit of the accumulator is non-zero. SZA can be tested by simply wire-anding the inverse of the accumulator bits together (diodes will do fine): if the result is zero then one of the bits in the accumulator is non-zero (so SZA should not skip). SNL skips if the link is non-zero.
The CLA and CMA bits select one of 4 possible inputs to the adder: CLA=0 CMA=0 gives the accumulator bit; CLA=1 CMA=0 gives zero, CLA=0 CMA=1 gives the inverse of the accumulator bit, CLA=1 CMA=1 gives one. The same thing is done for the link with the CLL and CML control bits.
The adder is fed the AC bits and a zero except that the IAC bit is used as the low-order bit (so 1 is added if IAC is set).
The shifter can perform one of five operations (six in late PDP-8's) based on the 3 control bits RAR RAL <rotate 2>.: pass-through (all 0), rotate right 1 bit (RAR=1, RAL=0, rotate 2=0), rotate right 2 bits (RAR=1, RAL=0, rotate 2=1), rotate left 1 bit (RAR=0, RAL=1, rotate 2=0), rotate left 2 bits (RAR=0, RAL=1, rotate 2=1).
The output of the shifter is clocked back into the accumulator at the end of the cycle.
That's basically how my machine works / what I described. The only major exception is that I have a simplified/reduced microinstruction set which only includes two bit-shifting operations: RAR=1 - one bit right, RAL=1 - one bit left. RAR=1 & RAL=1 is invalid. If you want two bit shifts to the right you just have to program two RAR commands in succession.
-
The skips are performed on the original contents of the accumulator and link. Note that these bits and their inverses are available (from the opposite transistors of each flip-flop). SMA should skip if the high order bit of the accumulator is non-zero. SZA can be tested by simply wire-anding the inverse of the accumulator bits together (diodes will do fine):
Oh, BTW, well spotted. I should note that the simplified logic diagram I posted, while still showing the actual logical function, differs from the final design in that the inverses of the AC register outputs are not provided by 16 inverters (with their OC outputs OR-ed) as drawn. I simply used a single 16-input DTL NAND gate which performs an OR function with the NOTQ outputs of the flip-flops.
Since those familiar with the 6-gate master/slave DFF shown and with keen eyes might also notice that I appear to have the Q and NOTQ outputs mixed up, I should point out that this is account for the fact that the D-input steering gates are inverting. In my hand drawn logic diagram the D-input is shown as being active-low.
Four more days at work and then I'm free for 5 whole weeks - then I'll be able to apply myself to this project almost full time. I've already registered a domain name specifically for the projects write up / documentation / exposition. www.educ16.com (http://www.educ16.com) (registered but not yet linked to a host).
EDUC16 = Educational micro computer, 16 bit ; to give due respect to the EDUC8 "Educate" discrete TTL logic computer project described in Electronics Australia magazine, which was mostly the inspiration for this design.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=120338;image)
-
Still loading and soldering bits for the remaining accumulator+link register cards, but in the meanwhile I have gotten the Program Counter register card loaded/tested/verified.
This unlike the AC+L, the 16-bit PC register only needs to be unidirectional (right-shift) and it has a parallel load function. The PC is parallel loaded from the Switch Register (the bank of 16 data-input toggle switches on the control panel).
I manged to fit four stages on a single card, so a total four of these cards make up the PC.
Here is the logical block diagram of the complete register:
https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=122053 (https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=122053)
Here is the schematic diagram:
https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=122054 (https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=122054)
After conducting a series of measurements with prototype discrete DFF's, I found it unnecessary to add the R-C delay networks (that I detailed earlier in this thread) to increase propagation from clock-in to Q-out. SPICE was overly optimistic in the estimation of the MPSH10-based gate turn off (output going high) time and the propagation delay through the DFF is more than long enough to avoid any synchronous clocking issues due to clock skew between cards.
Now I just have another 3 of these cards to etch and assemble and that will take care of the PC register. Here is the card under test, wired to a PIC microcontroller (and yes, the crystal oscillates fine on the breadboard without any additional parallel load capacitance):
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=122055;image)
-
I needed a break from the endless hours of soldering components and I've run out of 1N4148's anyway (silly, I only ordered 2000), so I've gone back to the mechanical construction. To make things a little more manageable I decided to break the card frame into separate units, 3 card rows in height. Here is how far I got with the first unit this afternoon. I've only got 2 shelves attached to the side panels and no back-plane yet, but it's rock solid. The back plane will be open for air flow, made up mostly of 2 horizontal angle extrusions card per level, the full width of the frame, to which the card DIN41612 mating plugs will mount.
My priority now is the finish this card frame unit and get it mounted unto the actual 19" rack, along with the power supply circuitry and the control panel. Then I've be moving straight onto finishing the system clock electronics and the control circuitry for the control panel.
-
Hi,
Yes, I picked that one up over a year ago on Abebooks for $1 plus postage ;D
-
I doubt it is the instructions to build one since it is a textbook.
The PDP-8 clone is developed in a 63 page chapter called "Designing a Minicomputer" using the ASM method:
http://en.wikipedia.org/wiki/Algorithmic_State_Machine (http://en.wikipedia.org/wiki/Algorithmic_State_Machine)
That chapter is then followed by "Building the Minicomputer" which is only 27 pages and gives simplified logic diagrams only of a very limited number of parts and only to give clarity to the description.
It's all there but to build their actual clone design you have to transcribe the ASM to logic yourself.
-
Finally have this 3-shelf section of card frame finished.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=125304;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=125306;image)
Here is the 19" rack frame that it is going to be installed into (tomorrow):
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=125308;image)
-
I can't wait to see the looms on the back of those edge connectors :-)
-
For the most part, there won't be many looms as such, but wires routed in the shortest possible path from one edge connector to another.
-
Finally have this 3-shelf section of card frame finished.
You're a crazy dude, GK, and I like it - much admiration!
-
Absolutely mental in the best way possible ;D
-
For the most part, there won't be many looms as such, but wires routed in the shortest possible path from one edge connector to another.
Like a web of intrigue ?
-
Are you going to wire-wrap the backplane? That was the classic method.
-
Following this project with interest. You must be a bit mad to do this but its brilliant!. Much respect and can't wait to see the thing running. The very best of luck there.
-
The book I got was the original 1980 edition. Your's looks later because the pages you show describe the LD20 where mine is the LD15. I wonder what the differences were. Is there a description of changes in there somewhere? Preface maybe?
Mine is the second edition, dated 1987. Unfortunately the preface lists no differences in the chapters concerned with the PDP8 clone.
-
Finally have this 3-shelf section of card frame finished.
You're a crazy dude, GK, and I like it - much admiration!
Are you going to wire-wrap the backplane? That was the classic method.
Following this project with interest. You must be a bit mad to do this but its brilliant!. Much respect and can't wait to see the thing running. The very best of luck there.
Lol, thanks..... I haven't progressed that much with the mechanical construction. Christmas stuff getting in the way. Have also mostly been busy etching/drilling/loading/soldering circuit cards both for this and my analog computer project - there is just endless hours of work. The backplane won't be wire-wrapped as the sockets aren't suitable. Anyway, as far as the rack goes I have the first part of the card frame installed and the control panel dummy fitted.
As I am progressing steadily with the cards I will soon be able to start wiring the backplane and get the programmable system clock, program counter register and the control logic operational to the extent that I can set the clock frequency from the control panel as well as load the program counter register from the switch register. That will still be far from an operation machine, but will be a psychologically pleasing milestone in the construction to actually see the beginnings of something (functional) come to fruition from the endless hours of soldering discrete components besides the ever increasing stack of completed circuit cards.
I am also very much looking forward to writing my first program on this machine. I think my first demo program will be a "Knight Rider" display on the accumulator register bit indicator LEDs using the left/right bit shifting commands. Eventually my main goal is to put the computer to use processing digital modes and automating my CTM-2K 500kHz (2kW carrier power rating on AM) radio transmitter (the larger unit shown in the picture attached immediately below) on the newly established 630m radio band.
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=126644;image)
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=126646;image)
-
I now have the system clock (4 cards) up and running with the clock frequency programmable from the control panel. Single-sided, un-etched PCB strips serve as power distribution buss bars between card slots. The other 4 card slots on this lowest shelf are going to be soon filled with the cards containing the remaining control panel logic and the Major State Generator. The 8 card slots of the card frame shelf immediately above will be occupied entirely by a 38-stage ring counter; a timing unit from which all operational sequences during the running of a major (machine) state are decoded/derived.
The Fetch state, for example, uses all 38 timing states (designated T0 through T37) of the ring counter. At T0, the Memory Address Register and the Instruction Register are cleared. At T1 the carry flip-flop of the Arithmetic Logic Unit is set. At T2 through T17 the 16 bits of the Program Counter Register are shifted serially into the Memory Address Register, and at the same time circulated back into the PC register via the ALU. Because the ALU full-adder carry flip-flop was set at T1, at the end of the PC>MA data transfer the value stored in the PC is incremented by 1, ready for the next fetch cycle. At T18 the carry flip-flop is cleared. At T20 through T35 the 16 data bits of the addressed memory location (the Instruction Word) is shifted into the Memory Buffer Register. At T36.5 the 3-bit Instruction register is (parallel) loaded with the three MSB's of the IW. At T37 the Defer flag flip-flop is set if the Indirect Addressing bit of the IW is set, meaning the machine will run a Defer state immediately after the Fetch sequence rather than going straight to an Execute state. That completes the T0-T37 Fetch machine state, which is run in the exact same sequence for every single instruction.
The sequence of events during the Execute state, of course, will depend on the specific instruction being executed. But anyway, the timing units is, essentially, the "spine" of the whole computers architecture, so it's my priority now (aside from wiring up the 4-card PC register on the 3rd shelf) to get those cards loaded, installed and wired.
However in the meanwhile I need to buy a bunch of cable ties and P-clamps otherwise things are going to start getting really messy.............
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=127332;image)
-
Here is some fun with hierarchical sub-circuits in LTspice. I spent a lot of time procrastinating over the design of the ring counter section of the computers timing unit. One way of making a ring counter is to make a binary counter and decimal decode it. However this method is fraught with timing glitches in the decoded decimal outputs, which are completely intolerable in this application. In IC logic design this is easily dealt with by making the binary counter feeding the 1-of-n decimal decoder synchronous, but building a glitch-free 1-of-38 decoder and synchronous counter with discrete DTL gates is another matter.
Another way to make a ring counter is with a shift register that continuously circulates a single set bit. This method isn't very economical on components as a single DFF is required for each count, but it is completely immune to the problem of decoding/timing glitches. Due to the latter very important trait, this is how I have elected to build the ring counter. There are simpler ways again to build a discrete ring-counter, but I didn't want to compromise on the speed and noise immunity of my established DTL gate circuitry. The shift register method also has the shortest clock-to-Q-out propagation delay as there is no decoding to ripple through.
So, anyway, a total of 38 DFF's are to be accommodated on 8 circuit cards (currently under assembly). Here is the complete ring-counter (in addition to a minor necessary section of the associated run-time control logic of the Major State Generator) of a few thousand, individual discrete components, simulated in SPICE using sub-circuits for the duplication:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=127629;image)
The three DTL sub-circuits are the DFF, an inverter and an AND gate, represented in the top-level schematic by the linked/associated custom *.asy symbols:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=127631;image)
The simulation simply runs a complete T0 through T37 count sequence as per a Fetch machine state at the trigger of a run command pulse:
(https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=127633;image)
I've been verifying the logic design of a lot of the computers circuitry this way. I just have a library of discrete component sub-circuits and build the top-level simulation schematics with standard logic symbols.
-
I would also suggest getting some multicore phone cable and stripping it for the coloured pairs inside. That way you can organise cables according to function, though you will have a lot of white and red wires extra for some use.
-
Well, I have a bunch of CAT5 cable that I am stripping. That has four pairs of different colours - green/green-white, blue/blue-white, orange/orange-white and brown/brown-white.
-
I come hier back every few weeks hoping to see some new info... I hope you didn't give up ! :-+
-
I come hier back every few weeks hoping to see some new info... I hope you didn't give up ! :-+
On no, definitely not :) I just have many other projects on the go. As a matter of fact I just etched a few more boards for this project last week. Haven't had a chance to start loading them yet. I almost have all of the computers control panel and associated logic completed and operational.
-
I like it!
-
Seems really impressive, although if I were you I would use a whole bunch of CPLDs double side loaded to reduce board size and cost. Programming them and JTAG through them will be tedious though.
-
Well, I could just program any one of a number of modern microcontrollers with some minor additional support hardware to hook up to my control panel, to emulate a PDP, but that would be besides the point.
-
Seems really impressive, although if I were you I would use a whole bunch of CPLDs double side loaded to reduce board size and cost. Programming them and JTAG through them will be tedious though.
hahaha |O