|
k1.spdns.de / Develop / Hardware / K1-Computer / K1-CPU / SSW / |
 Overview
| Control Unit
| Microcode Header
| Arithmetic Unit
| Data Registers
| Address Registers
| Expansion Bus
|
|
|
k1.spdns.de / Develop / Hardware / K1-Computer / K1-CPU / SSW / |
| Overview
| Control Unit
| Microcode Header
| Arithmetic Unit
| Data Registers
| Address Registers
| Expansion Bus
|
Last updated: 2014-08-16
Questions & comments to Kio
2009-01: The control unit, the heart of the K1-16/16 CPU, was designed and manufactured first. The abbreviation "SSW" stands for German "Schrittschaltwerk".
I ordered it from PCB-Pool (voucher). During production i got several scans after the major production steps. They can be found in the Images/ subfolder in the archive below, aside with some scans which i made during soldering.
I got the idea to use 28256 EEproms instead of 27256 Eproms to avoid repeatedly erasing with UV light. Therefore i'd like to add those people to my foe list, who are responsible for the swapped pinning of A14 and /PGM resp. /WE.
Here a view to my soldering frame: Please notice the self-adjusting pressure rig and the so-called CMOS foam from Pollin, a domestic electronics junk goods retailer. It is unusable for tugging in CMOS ICs, but serves perfectly as a form-following pressure spreader. On the other side of the pack is any other board i could find.
I thought a long time whether i should use sockets, last not least because the eproms are located above the rams which adds a stacked socket, and the rams should be replaceable, because they are used – from cannibalized '486 PCs. Finally security won.
The blue sockets are for the 74AC163 counters. I incidentially had 5 of them.
The ablated socket is for the quartz clock generator.
After some final tests i have populated the sockets. The image shows the board without eproms inserted. In addition i have inserted resistor networks into the data and feedback (flag) lines to prevent them from floating. 4 MHz was the slowest clock generator i found in my resources, planned are 16 Mhz, or maybe even more.
Does the reset circuitry work as expected? – no, it doesn't. :-( Power-up reset is wacky and a reset issued by program did not work properly: The resetting register was resetted earlier than most others, resulting in an incomplete reset, but i hope, throttling down ther CPU before resetting will at least fix the latter problem. Probably i'll need a secondary reset circuit.
Does copying the contents of the eproms to the rams work? – yes it does. Fine! :-) This is, historically, the oldest part of the whole project.
2009-02-19: First sigh of life! I powered it up and measured the current consumption, which is approx. 150 mA. Then i increased the clock frequency and looked at some images on my scope. Tomorrow i'll add real contents to the microcode eproms! ;-)
2009-02-20: I have written a first script (in vipsi, which also serves these web pages) to create 3 hex files. With an eprommer from Stager Electronic/Taiwan (not recommendable) burnt into the 3 microcode eproms and tested. Branching (with a wire connecting to the feed back lines) tested ok, only the final step, a blinking LED did not work. After some arithmetics it should blink with 120 Hz. Ok, and that actually it did. (Proven with my scope)
Some more power consumption, running testprogram 'Test1' (yeah!):
4 MHz: Running 185 mA, Halt 160 mA
40 MHz: Running 335 mA, Halt 185 mA
2009-02-22: Re-thinking of the interrupt handling.
Interrupt handling, as currently implemented, originates from a microcode processing model where conditional branches wasted time, which i had dismissed in favour of the current method with two code planes. Rethinking the whole circuit resulted in a 'minor' change to the PCB, which i hoped would improve code loading timing. Here the PCB after the modification:
Advantages: Opcode fetch now improved by 2 GLZ (gate latencies, "GLZ" = German "Gatterlaufzahl") directly resulting in a higher feasable clock frequency. (but: see below...).
1 GLZ time 'added' for microcode copy process.
Disadvantages: The interrupt vector does not change the high-order microcode address bits D12 and D13, therefore interrupt handlers must start at 4 positions in microcode.
An interrupt can also result in a jump to address $0000, the reset vector. This can be remedied by always loading the next assembler opcode with code plane MA14=1. The reset starts in code plane MA14=0.
2009-03-12: I am displeased to announce, that i did not notice the 3-gate path for D14 for the 'clear' inputs of the lower microcode address counters, which renders the PCB operation useless.
A high resolution PDF is available in the archive below.
The control unit is composed of a microcode address counter (CMD.MSB ... CMD.LO1) which addresses the microcode roms (MC.ROM*) and rams (MC.RAM*). Their data is latched into registers (MC.FF*). Their output is decoded 4:16 for data bus output enables (Dx.OE), 4:16 for data bus latch clocks (Dx.CLK), 3:8 for address bus output enables (Ax,OE), 3:8 for address bus latch clocks (Ax.CLK) and 6 lines as multi-purpose option lines, 4 dedicated for the data bus and 2 for the address bus.
6 feed-back lines from various units (ALU and data bus bits D0 and D15) are selected based on 3 microcode data bits, and the resulting line is fed back to form the highest address bit MA14 for the microcode address of the next microcode. The ultimate highest address line MA15 from the microcode address counters is used to toggle from "copy eproms to ram" mode after reset to "microcode execution" mode. The final microcode data bit discriminates between "execute code" and "const data" for the DVAL.* gates, which can be output to the data bus.
Most of the simple gates in the top-left corner of the drawing are for interrupt decoding and were modified with an operation to the PCB.
All the lines originating from the 3:8 decoders, the general purpose option lines and the feed-back lines make up the control bus, which runs vertically through al boards.
The control unit reads data (assembler opcodes) from the data bus and can put data on the data bus via the DVAL.* gates. It makes no use of the address bus.
With each cycle of the master clock CLK the address to the microcode rams increments and they subsequently emit the data of this new address. The data is synchronized with the next clock cycle in the MC.FF* registers. With the next clock cycle it is emitted via the 3:8 decoders to the other boards. So this control unit has a 1 instruction pipeline. Every conditional branch in microcode must live with a 1 instruction latency.
Const data can be output to the data bus via the DVAL.* gates (and latched into the DIV.FF flip flops as shown in the clock circuit PDF) if the microcode data bit !CMD_EN = 1. Since the const data for the IVAL.* gates originates from the first stage of the pipeline (the stage before the MC.FF* synchronizing latches) and the instruction to do so originates from the second stage (after the MC.FF* latches) this is possible. With the next clock cycle the const data moves from stage 1 to stage 2, where it is not executed (due to CMD_EN=1) and this clock cycle is just wasted.
When the const data is in stage 2, this data is latched into the DIV.FF flip flops. Therefore it is neccessary to use a 'safe' value for this register. I suggest to use the '!reset' bit with new value '1' which means 'no'. (Except if the const data is actually meant for the DIV.FF and not the IVAL.* gates, off course.)
During reset the counters are cleared to zero. After reset MA15 = 0 indicates the "after reset" state where the eproms are copied to the rams. The counters count through the whole address range of the eproms (32k = 15 bit) while the eproms are enabled and the rams' /WR is strobed by the main clock. Finally bit MA15 toggles and the eproms are disabled and the rams' /OE is activated to read microcodes from the rams and execute them. There are some implications for the DIV.FF data handling during copying (because the 74*259 has NO reset, only a pin NAMED conditional (!) MASTER (!) reset!) and minor problems for the first microcode processed.
Basically there are two problems: The analog reset circuit, which i have tested, does not work reliably.
It is too slow, thus not elongating very short reset pulses to a minimum width. The major source for a very short reset impulse is a reset generated from microcode: writing '0' into the reset bit of the DIV.FF flip flop. This flip flop is reset in return by the reset impulse itself. And this is faster than for most other flip flops, unluckily. (Or luckily: so i see the problem and can fix it.)
The time of the rising edge is not synchronized with the main clock. Therefore some gates will still 'reset' while others are already working. I was not really aware of this problem, that even the reset had to be synchronized with the main clock.
Eventually all these problems can be fixed with a replacement reset circuit on the IO board.
| Name | Letzte Änderung | Länge | |||
|---|---|---|---|---|---|
 |
first Microcode Test Programs/ | 2019-08-20 05:21 | 8 | ||
|
Images/ | 2019-08-20 05:21 | 15 | ||
 |
Microcode Upload Header/ | 2019-08-22 19:20 | 12 | ||
 |
SSW 5.D - Clock.pdf | 2009-01-28 20:26 | 22803 | ||
|
SSW 5.D - Component Placement.pdf | 2009-02-19 14:02 | 94576 | ||
|
SSW 5.D - Connectors.pdf | 2009-01-28 20:26 | 22180 | ||
|
SSW 5.D - Main.pdf | 2009-01-28 20:26 | 50101 | ||
 |
SSW 5.D - Part List.txt | 2009-10-15 18:05 | 1011 | ||
 |
SSW 5.D.b#1 | 2009-11-03 18:18 | 138371 | ||
 |
SSW 5.D.brd | 2010-01-22 15:22 | 138349 | ||
|
SSW 5.D.s#1 | 2009-11-03 18:18 | 178383 | ||
 |
SSW 5.D.sch | 2010-01-22 15:22 | 178400 | ||
|
SSW 5.D.txt | 2009-01-29 18:00 | 11445 | ||
|
SSW 5.E Errata+Todo.txt | 2009-02-23 17:49 | 654 | ||
|
SSW 5.E.b#1 | 2009-11-03 18:18 | 138326 | ||
|
SSW 5.E.brd | 2010-01-22 15:26 | 138315 | ||
|
SSW 5.E.s#1 | 2009-11-03 18:18 | 184092 | ||
|
SSW 5.E.sch | 2010-01-22 15:26 | 184131 |
powered by vipsi - your friendly VIP Script Interpreter
