This morning I fired up the 1130 system to start running through my demonstrations. The first set were the most common ones - booting from the internal disk drive and a real DMS2 cartridge, printing on the real 1132 printer, although using the virtual 1442 card reader.
I successfully ran:
- Boot up of DMS2
- Dump of LET and SLET
- Assemble a program
- Fortran compile and go of square root calculations
- Fortran compile and go of lunar landing game (may change this)
- DCIP dump a sector to printer
Lo and behold, when I tried to load core with the diagnostics, I found the fpga was back to its old tricks of dropping bits on the USB link. It got up to 83 in the garage, too hot to run the system and test further. I will have to continue testing early in the morning tomorrow.
COMPLETING REPLICA COSMETICS
I hauled out the power saws and began cutting the MDF plate parts that will be glued up to act as the console printer and display pedestal base. As well, I had to cut up wood glue strips that will hold the parts together.
My first step was to rip the sheet of MDF into strips of various widths, which I would then cut into shorter lengths using a chopsaw. My table saw is disassembled and stored in a shed to allow the 1130 to sit in my workshop, so I had to improvise with a circular saw, cutting guide and some 2x4s to hold the MDF up.
Now I have 13 pieces of wood to glue up, the first two assemblies are four pieces each. Getting these square and properly clamped, then the glue drying takes a bit of time. I have glue blocks I added to give even more support to the joints. The final glued up wood section will go in the frame position behind the keyboard, where the display pedestal and the console printer sit.
The sheet metal top parts are all installed now. I had enormous problems with the right side that fits under the wood desk. For some reason, none of the drilled holes in the frame lined up close enough to match the holes in the sheet metal.
When it is done and fitted to rest properly on the replica frame, I then have to cut the openings for the display pedestal legs, using a jigsaw, cut down the wood supports that fit in the pedestal legs and test that it all works together before I can mount it all on the frame. The pedestal legs will be screwed in place, allowing disassembly at a later point.
I have having a lot of trouble working out decent bracing for the glued together panels, particularly where the two end sides join the flat bottom upon which the typewriter will rest. I added the bottom braces upon which the assembly stand on the welded frame.
Still had to do is some trimming of the right side of the assembly, to allow it to fit over the frame segment on that side. Now that it sits in the right place, once it is solid enough, it will be time to build the mounts for the display pedestal legs.
 |
| Gluing up the typewriter and display pedestal base (in lieu of sheet metal) |
 |
| Testing the fit of one part of the pedestal base |
 |
| Getting ready to attach faux covers to the replica |
 |
| light gray is sheet metal, dark gray and blue are mdf panels |
Tonight I collected and printed all the wiring information I have for how to hook up the various parts to the fpga board, plus providing the various voltages that are needed by parts of the system. I also hunted down the last good fpga bitstream and loaded it onto my Nexys2 board.
My kitchen island has the display pedestal, power supplies, console bit switch bar, fpga, and what I hope is all the connectors and wiring harnesses. I can see, for instance, that the cabling is done to make use of the rotary mode switch, although the current version of the logic is ignoring that and rerouting some of the signals to the pushbuttons instead.
Therefore, my task is a bit larger than just re-establishing the cabling and hookup of everything. I have to get the correct logic set up and remove any funny testing links I might have in place. Even the simple act of connecting things up is complex - there are several boards, lots of connectors, several cables, and I have to dig through lots of notes and drawings.
First: Wow! What an amazing journey this 1130 and the other projects has been! Thank you so much for sharing it in such detail. There is a lot of really good historical lore being documented, in addition to the ton of work you're doing to preserve the hardware, the software, and the documentation. Now on to my specific comment:
ReplyDeleteIt kind of jumped out at me how the error detection and correction is that you're doing for the USB interface is so very different from all the other error detection and correction you've implemented in the other projects. I remember you taking great care to cook up a SECDED hamming code for the SDLC link between your original ztex FPGA and the early secondary FPGA for fan out. (August 2015) We know that error detection and correction is tailored to the kinds of errors that happen on links. For example, disk errors tend to come in multi-byte dropouts because of surface problems so a block CRC is used. Core and semiconductor memory drops out one word at a time so parity/ECC codes are used.
When VCF is over, and you have time to do some analysis, it seems prudent to investigate the nature of those USB errors. Are they bit errors? Byte errors? Dropouts of blocks? Because right now, this compare and retry (with progressively more elaborate retry logic) seems like it's going to get progressively more messy as more special cases of erorrs that might happen and more special cases of recovery emerge. If more on the nature of the error were known, a simpler, more tailored error detection/correction setup might suggest itself.
Hi William
ReplyDeleteIt looks like single bit errors, although I don't know if any of those shift the frame or just change odd bits. I would have done a more careful design and built better error correction, if I knew I would need it earlier than the week I was prepping for the show.
I think it would be a great idea for me to run a special intensive test of the link where I could definitively answer the questions you pose and understand the types of errors I will face.
This comment has been removed by the author.
ReplyDeleteSetting up such an intensive test (again, AFTER VCF) seems to me a matter of implementing a CRC check (rather than a comparison), and some additional logic on both sides of the link to enable a request for re-transmit and for the PC to log expected and actual data in the event of a CRC error. It does mean that you have a communication wrapper before the FPGA actually acts on what is received, and/or moves on from a send transaction. A CRC error detected by the FPGA on data coming in from the PC signals a special reply to the incoming data that sends back what it got. The FPGA waits for a re-transmit of the packet and keeps asking for a re-transmit until it gets one that passes CRC. Transmitted and received data gets logged on the PC for later review. (Naturally that reply from the FPGA also needs a CRC. If the reply gets a CRC error, the PC should log a double error, and the contents of the logged reply treated with skepticism. A burst of double errors also tells us something.) If a CRC error is detected on the PC side, a new transaction, "Say Again" is sent. Again, expected and actual data, as well as "double error" get logged.
ReplyDelete