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.