2010-04-05: During Easter holydays i made a great leap and put it all together!
Off course, there were problems. E.g. when my highly valued power supply unit did only deliver 4.4 instead of 5.1 Volts. And became quite warm. First i had problems to measure the current drawn by the CPU, because the PSU always switched off when i cramped the amperemeter into the fuse socket. Measure leads too high impedance... But i was lucky to revive an old pair of leads and see: 3.2 ampere. Off limit for the PSU. Why? Hu hu hu. Some explorations later: i had connected the ALU data registers in reverse direction in the circuit drawing. Impressive what they can survive! I made a dead-cockroach-type operation to both of them. (100 points for those who know what i'm citing! :-))
|The ALU Registers [on the left] after Operation|
But still the power drawn is a little bit suspicious. The CPU now draws 350mA when stopped and up to 1.3A when running at full speed. But at some points the power consumption rises from 0.5A to 1.0A and above while slowly idling through some random microcode found in the eproms. No explanation yet, but i decided to finish the frontpanel's debugger and start from there. If there is some cause to draw more than 0.5A unexpectedly there will be some error. Hopefully.
So, as said, i worked on the debugger. I implemented routines to read in the sensor ring, which provides information on all three busses (data, address and control). And a preliminary single stepper. Occasionally i could alredy verify that the address incrementer seems to work. Yeah. Tomorrow more...
2010-04-08: It seems that i have more problems with the assembler than with the CPU now. B-) Slowly but shurely i am writing test routines for registers and functions and so far they all work. Except if the assembler fails to generate correct code. Data registers, ALU functions, shift registers, address registers and address increment/decrement up and running. Ram test ok! And on we go...
tst $0008 : z jp 1,errorjumped to error sometimes, but when i uploaded hundreds of tests into the microcode rams it always failed at the same microcode address, if it failed, which was different for every special code mix. What was going wrong here?
Nothing. It was ok. I will have to put a wait cycle here (or eventually it works when i replace the condition selector, a 74HC151 by it's AC counterpart.) The 'error' was the impression, that the immediate value came from the 'ival' registers on the control unit. But these are no registers, but drivers. And they put the data from the microcode rams on the bus, thus i had to add the latency from the microcode rams to the total round-trip time and – alas! – that was tight. VERY tight...
For the records: Power drawn by the CPU is ~350mA@5V when halted and ~800mA@5V when running at 16MHz.
2010-04-11 to 2010-04-15: Webside down, because iMac down. PSU failure.
2010-04-16: Resuming testing.