Friday, October 14, 2016

All apps and diagnostics workign on Xerox Alto II, redesigning key component of disk tool


We spent the morning working on the Alto. The machine, as we received it, had a 1K CRAM (RAM for microcode) board and a 2K/3K Control board attached to it. The Alto can be configured with 1K of microcode ROM, 1K of ROM and 1K of RAM, 2K of ROM and 1K of RAM, or 1K of ROM and 3K of RAM.

With the Control board wired for 3K, but a 1K board we had incompatibilities including one address control line that was hooked directly to ground, making the 1K of RAM inoperative. If the control board was only a 2K or 1K control board, it would have been compatible with the 1K RAM board.

We switched the original boards for a pair of boards we received, a 3K control board and a 3K CRAM board. Everything worked perfectly, we could run the diagnostics and all the applications with no failures.

With that fixed, the two remaining bits of hardware to work on were the ethernet board and the mouse. The optical mouse seemed in good shape, but the Alto didn't detect any movements or clicks. We disconnected the mouse cable from its connector on keyboard and checked for availability of +5V and ground.

Immediately, we saw the problem. The connector on the mouse cable is a DB-9 which has a row of 5 pins over a row of 4 pins. The female connector on the keyboard is a DE-19, which has a top row of 6 receptacle pins, a middle row of 7 and a bottom row of 6 pins. Even though the connectors mated physically and could be screwed together, the pins didn't line up properly.

We will need to do some work to make the mouse work, with several possible approaches:

  1. Get our hands on an Alto mouse with the proper DE19 connector
  2. Make a cable converter to connect the 9 active wires from the DB9 to the DE19
  3. Add a secondary connector to the keyboard, a DB9 one, to use the original mouse
  4. Find a DE19 connector and rewire the mouse
  5. Replace the DE19 connector on the keyboard with a female DB9


The steps while reading a sector must be verified, with completed steps in gray:
  1. Readsector logic is waiting for a sector match
  2. Indexmarker occurs, signalling that next sector mark is for sector 0
  3. Sectormark occurs, thus we are in sector 0 now
  4. Gotsector is emitted to indicate we have a match
  5. Readsector logic moves on to setup for record 1 of the sector
  6. Readfield logic is triggered
  7. Readfield waits for approximate 200 us preamble before looking at incoming data
  8. Roughly 120 us of zero data bits are seen
  9. A 1 data bit completes the sync word
  10. the logic recognizes the synced state
  11. Two words of the header record are deserialized, extracted and saved
  12. The checksum is calculated correctly for the two words of the header record
  13. The next word is deserialized, extracted and used as a checksum
  14. The checksum verification test occurs properly
  15. The readfield logic completes
  16. The deserializer goes to the unsynchronized state
  17. The readfield logic for the next record, label, begins
  18. The appropriate preamble is passed before we look for sync
  19. Enough zero bits are read to properly set up sync logic
  20. A 1 bit is read and the sync condition is attained
  21. Eight words of the label record are deserialized, extracted and saved
  22. The checksum is properly calculated for the 8 label words
  23. The next word is deserialized, extracted and used as a checksum
  24. The checksum verification test is done correctly
  25. The readfield logic ends
  26. Sync is dropped
  27. The readfield logic is entered for the data record
  28. A suitable preamble is passed before attempting sync
  29. Enough zeroes are read for the sync engine to work properly
  30. A 1 bit arrives and we attain the sync condition
  31. 256 words are deserialized, extracted and saved as the data record
  32. The checksum is properly calculated
  33. The next word is deserialized, extracted and saved as the checksum
  34. The final checksum test is done properly
  35. Readfield logic ends
  36. Sync is dropped
  37. The readsector logic completes
  38. Appropriate completion status is set in Reg0001
  39. The next sectormark does not occur until after step 36
To complete step 11, I need to redesign the deserializer function, since it is sometimes detecting 1 bits when they did not occur in the incoming data stream. This is a problem with glitching/bouncing of the incoming line, which did not occur when I generated a perfectly spaced test pattern but happens with the real-life signals and their associated jitter. 

No comments:

Post a Comment