Problems appear to stem from the Program Counter and Adder card

VERIFYING THE DECODER CARD PRODUCES THE RIGHT OUTPUT

I tacked wires on the motherboard pins for all the outputs from the decoder and verified that every instruction is properly decoded. There are eight major instructions (AND, TAD, DCA, IOT, OPR, ISZ, JMP and JMS). The OPR (Operate) instruction has subtypes which are decoded and I validated that these were correctly produced for all the combinations of five bits in the OPR instruction. 

ASIDE ON ODD OCTAL NOTATION

All the documentation for this machine, based as it was on the PDP-8, uses octal rather than hexadecimal. With eight bits, not an even multiple of 3, one has to decide how to express the numbers. With most octal machines, one presumes there is a high bit of 0 which lets us write octal ranging from 000 to 377 to cover all eight bits. 

Not so with the EDUC-8. Its 'down under' notation presumes a bit of 0 inserted between the third and fourth bits. Thus if we have binary 10110111 it is written as 527, distinct from the more usual practice of rending that binary number as 267. 

PROBLEM COULD HAVE COME FROM ACCUMULATOR OR PC-ADDER CARD

Since I tested with four boards inserted (timing, decoder, pc-adder and accumulator) and have verified the correct operation of the timing and decoder cards, I wanted to determine which of the other two boards were causing my issues.

I pulled the Accumulator board and the odd behavior remained. This points the finger at the PC-Adder card. 

ODD INDICATIONS AND BEHAVIORS

When I load the program counter with the address 000, it sets correctly as I hold down the Load Address switch but then the high bit turns on as I release the switch. This could either be a failure in the parallel load of the shift registers forming the PC, or a spurious injection of a 1 bit at the end. 

When I push the Exam switch, it should increment the PC by one, but I see bizarre incrementing patterns. 000 goes to 004, then jumps to bigger patterns of 1 and 0 bits with succeeding presses of the switch. 

When the Accumulator card is in the stack and I do operations that add to the AC, I see similar strange patterns. An increment by 1 operation will jump from 000 to 004, same as the PC. In fact both the PC and AC move in concert, which they shouldn't. 

I don't (yet) have an extender card for the machine thus I have challenges getting probes onto the chip pins or I/O connector fingers since this card is sandwiched between the decoder and accumulator cards. I have been tacking wires to motherboard pins and may also tack to chip pins on the board as I debug this in the coming days. 

Comments

Post a Comment

Popular posts from this blog

Bizarre behavior detected in a Raspberry Pi Pico based design and partially understood

ORIENTATION OF THE PRODUCT CAN CAUSE THE PI TO FREEZE AT STARTUP This particular product with a Raspberry Pi Pico would not boot up when sitting flat on the table in its normal orientation, but if tilted or turned it would come right up. When I hooked up a USB serial connection to the debug header, it worked fine even flat on the table.  INVESTIGATION BY DESIGNER AS WELL AS ME I first assumed that I had introduced this problem in the product, but happened to describe it to the maker who was able to reproduce it reliably. I continued to try variations to determine whether it was pressure on a board or component that caused it. I also searched the web for any reports that might cause Pi Picos to fail to boot based on orientation, but found nothing.  The designer found signals introduced on a serial connection trace when sitting in the normal (failing) orientation but not injected when rotated or otherwise turned. Traces were routed from the UART0 on the Pico to a header, for use...
Read more

Incompetent coders - the frustration of using Vivado to build FPGA designs

IDIOT SOFTWARE MUST BE RESTARTED CONSTANTLY TO SEE INPUT FILE CHANGES When I update a source file, often Vivado is somehow working from a cached copy and never notices the changes. It is highly frustrating to fix an issue, rerun a Linter or Synthesis and get the same old errors. The only solution is to shut Vivado down and restart. I remember hitting this many times in past years as I worked with the toolchain, but it has changed from sporadic to nearly constant failure to see the changed timestamp. I can't be the only person running the toolchain under Windows, yet this kind of bumbling misperformance has been a feature for years. 
Read more

Found correct mod for the Arduino Mega 2560 to avoid powering it from USB

Image
USB HANDLING CIRCUITS IN THE MICROPROCESSOR REQUIRE USB VCC TO RUN The reason my first attempt failed, simply removing the poly (resettable) fuse, is that the fuse is between the USB connector and the microchip which needs the USB VCC connected. I had to reinstall the fuse.  BETTER CHANGE IS TO REMOVE A MOSFET THAT ROUTES POWER The Arduino uses a power mosfet and a comparator to decide when the external power is adequate to run the board, disconnecting the USB VCC from the board. It does leave that wire connected to the USB circuitry in the chip, however. With the transistor removed, the USB power never gets to the board so it is always powered by the external (1130) power. This means the board powers up and down with the main system, whether or not a USB cable is connected to anything else. When the board is powered up, the cable is active as a serial connection, exactly what I wanted to happen.  In the picture below, the green circle shows the reinstalled polyfuse. The red c...
Read more