1301 and Colossus (was Re: Hardware Hobbyists vs. Emulator Enthusiasts vs Replica Recreators)

[Ray Arachelian]

Roger Holmes wrote:
>
> The ICT 1301 dating from 1962. It is possibly unique in not having a
> program counter. Of course there is a way to get the next pair of
> instructions or a double length instruction. If you think of it as a
> three instruction pipeline which (in normal operation) always contain
> an instruction to do the instruction fetch that gives you the idea.
> The fetch instruction is an absolute jump, so contains the address.
> After execution it re-enters the pipeline with one added. There can of
> course be more than one absolute jump in the pipeline, it can even be
> all jumps, and the jump instruction can be used to jump to a
> subroutine which saves some of the pipeline in memory as its first
> instruction.
The wikipedia article on it http://en.wikipedia.org/wiki/ICT_1301 and
this page http://ict1301.co.uk/13010310.htm, are quite impressive.  So
it states upto 2000 48 bit words.  So that shouldn't be any problem to
emulate.

Punch cards and paper tape might be fun to simulate on the web page. 
I'd say get some scanned in and maybe get some javascript or something
to allow the end user to click on the various positions of the cards to
punch a hole, and maybe make the same sound as a hole puncher would
make.  Ditto for paper tape.  And maybe if they make a mistake, the card
could be thrown away and a they'd need to start over.

While authentic, that would be fun for about 10 minutes or so before
patience runs out, so an alternate method, such as typing it into a text
box and having the javascript punch the cards for the user would be a
good alternate. :-)


> My machine has no microcode its all hard wired logic. Confusingly
> there are two instructions, the multiply and the block move which
> proceed in small steps in what the manuals micro instructions but
> there is no memory of any sort they are read from, no micro
> instruction set, just logic which decides if the multiplier, or word
> count has reached zero and if a (decimal) digit is more or less than
> five to decide to subtract or add the multiplier.

> For ordinary visitors we don't have contact beforehand. We could
> possibly have days in the same way as preserved steam railways have
> days when they sell people the experience of being a steam engine
> driver, under strict supervision of course. Car racing tracks have
> days when you are taught the safety rules and the allowed to drive
> around the track in a fast car accompanied by a professional racing
> driver. This costs a lot of money of course. For computers maybe
> something could be done on the web for free with emulation. This could
> be worldwide all year around. Any local people could arrange to come
> and run their programs on the real hardware in the warmer months.
Sure.  I guess for general visitors, perhaps some sort of demo program
can be shown, feeding in punch cards and producing some result or other.

>
>> I don't think several hundred visitors a day would write code, they
>> might just want to see it in action, but maybe a few dozen would like to
>> get deeper.
>
> Maybe I could ask people this year if they would like to do that. Too
> soon for this year anyway, 12th July is too soon to do anything much.
Well, pick whatever day is convenient for you.

> Hmm, I suppose I am falling into the same trap as the people who
> scrapped the mainframes, assuming that because things are no longer
> useful they have no reason to exist.
Useful as in modern day, probably not.  Useful as in historical, or
learning classic computer architecture, absolutely.


>
> Yes, before they become teenagers and have no patience.
:-)  Indeed.  It's hard enough to get the older one to want to read.  He
mostly just wants to play, or watch cartoons.

>
>> Right, a logic simulator could be used to model this, and later you
>> could change the emulator around to match the proposed change.  Gate
>> level emulation is very difficult.  Not so much difficult to write, but
>> its going to require a lot of processing power, and the timing aspects
>> will be very hard to get right.
>
> Fortunately I have a very slow machine to model, the faster
> instruction takes 12 microseconds. There are about 4000 PCBs, 1000 of
> which are JK flip-flops. The other 3000 have at most 4 And gates on
> each, plus wire-or so I would guess about 15,000 gates and 1000
> flip-flops. I have scanned the 'Address Book' which lists all the
> interconnections in the machine. I want to OCR it and then write a
> program which generates C code to recursively process all changes in
> logic level for that clock cycle and then latch the data into the
> flip-flops at the end of the clock pulse. As there are so few logic
> levels which change on each clock cycle I would think that could be
> done in real time, after all a modern machine has a clock speed about
> 2000 times greater my 1301's 1MHz clock.
This is true, however each gate will take a bit of work in order to
evaluate its state.  This is non trivial.  The JK flipflops are easier,
just pretend that they're storage instead of two gates feeding each
other.  It's a cheat, sure, but if you go about it the proper way, it
will eat a lot of host CPU for little gain.  For that sized gate count
(excluding the flops), it can absolutely be done in real time.
Mmm, I think you can even reduce this to the equivalent of a
spreadsheet, which each "cell" being a gate with a variable holding the
state as its output and a list of pointers to the input states, then for
each instruction cycle, recalculate all of the states of the gates.

I don't think I've actually seen any emulator that goes about it this
way, it would certainly be very unique.

Hardware output would have to be emulated as well.  For the drums you
could have an index into the current position of the drum and a very
large two dimensional array for the actual data.
You'd update the index every clock cycle, or every Xth clock cycle to
move the data into view of the r/w heads.

>
>> It has been done in the past, mainly to help designers test out their
>> designs, but they typically run several thousand times slower than the
>> actual machine.
>
> Presumably someone designing a new computer would be designing
> something faster than what already exists so the simulation would be
> often be running on a slower machine in the first place.
A straightforward way to emulate this, would normally be to just to
implement the instruction set in C (or some other language) and have it
do exactly what the hardware would do without simulating the gates. 
Ditto for the I/O hardware.  That would be fairly trivial for a machine
of this speed.


>
> Now we have been appointed as the '1301 working group' of the CCS, the
> other half of the team gets a seat on the CCS committee (I'm too busy
> earning a living to keep going up to London every few months) so
> perhaps he can see if that is a possibility.
If you could get in touch with the Colossus guys, and ask them to put
their emulator back online, as well as details about the replica, that
would be wonderful.

> I think you need a knowledge of basic cryptography to make much sense
> of what the plug-able 'menus' do, knowledge I don't have.
>

I've got that down from my days as a cypherpunk :-) however, the
Colossus (Colossus: The Secrets of Bletchley Park's Codebreaking
Computers by B. Jack Copeland et al) book does have a nice introduction
to it.  It does include some descriptions of the electronics and how
they simulated rotors using vacuum tubes as a large rotary shift
register, but nowhere near enough to actually build an emulator or a
replicate of the machine.  You could build something similar, but it
wouldn't be accurate at all.

Most of that good book is a wonderful historical recounting of various
codes and code machines, well worth a read.  But sorry, no full
schematic of the Colossus. :-)  It does however go fairly deep into the
theory of how it cracked messages.