Saturday, December 31, 2016
Friday, December 30, 2016
Testing of disk tool on Alto system Diablo drive highlights remaining issues
ALTO DISK TOOL
I brought the new board, fpga and related objects over to the Alto, hooked it up to the Diablo on that system and read some cartridges for archival purposes. Unfortunately, I was still seeing sectors with errors.
Something is going wrong, leading to errors which we are not experiencing when the Alto reads the same cartridges. Unless the Alto is ignoring errors and never is affected by any incorrectly read sectors, there is something I can improve in my fpga logic.
We did boot up all the other cartridges we had, which all ran well, but that was with the Alto driving the Diablo. The original disk cartridge we received had been cleared by a utility that overwrote the media with a pseudo-random stream of words. This seemed ideal to use to write an archived disk image which had many Alto games.
This was the first time we tried to use the WriteEntireCartridge transaction, which appeared to work. However, when we tried to boot the cartridge on the Alto, we heard it seek and read from two locations but then stop. Clearly the written data was not done well enough to work properly.
My wishful thinking yesterday, that the surface scratching on the cartridge at my house was the sole reason for checksum errors while reading, is proven wrong. I have to keep working until my tool reads my cartridge entirely correctly (and writes sectors properly).
I brought the new board, fpga and related objects over to the Alto, hooked it up to the Diablo on that system and read some cartridges for archival purposes. Unfortunately, I was still seeing sectors with errors.
Something is going wrong, leading to errors which we are not experiencing when the Alto reads the same cartridges. Unless the Alto is ignoring errors and never is affected by any incorrectly read sectors, there is something I can improve in my fpga logic.
We did boot up all the other cartridges we had, which all ran well, but that was with the Alto driving the Diablo. The original disk cartridge we received had been cleared by a utility that overwrote the media with a pseudo-random stream of words. This seemed ideal to use to write an archived disk image which had many Alto games.
This was the first time we tried to use the WriteEntireCartridge transaction, which appeared to work. However, when we tried to boot the cartridge on the Alto, we heard it seek and read from two locations but then stop. Clearly the written data was not done well enough to work properly.
My wishful thinking yesterday, that the surface scratching on the cartridge at my house was the sole reason for checksum errors while reading, is proven wrong. I have to keep working until my tool reads my cartridge entirely correctly (and writes sectors properly).
Validated new board and connectors, ready to be used on the Alto system to archive disk images tomorrow
ALTO DISK TOOL
I set up the testbed and began to check the functionality and signal integrity of the new board and connectors. Seeking was checked to be sure all the address bits were working - but in fact the 4 and 16 lines were not working. I found that the chip pins involved were not well soldered, fixed it and went back to test.
In addition, I have a Digilent Nexys2 FPGA board that was purchased by Al Kossow in order to give him a working disk driver and emulator. It had connectivity problems in the USB connector, with the connector itself bent and some other problems where it was attached. I used my heat gun to remove the connector, bought replacements and will surface mount the new part when it arrives.
The disk drive testing resumed and my seek addresses were all working correctly. Next up is getting the ReadGate and other signals tested. I am emitting '1' to ReadGate which should pull the output of chip U2 side 1 down to ground, thus activating pin 39 on the ribbon cable to signal pin E.
However, when I monitor pin E on the terminator, the line is not going down to ground. I have continuity from the fpga connector pin to chip U2, from the chip output to pin 39 on the connector, and all the way through the cable and drive to the terminator.
I might have a flaw with chip U2 such that it is not working, even though all the connections to and from it are good. I have to do a power-on test and verify the voltage levels at the chip. Watching the scope, I could see that the signal at the terminator changes as I probe the chip pins, indicating I probably have a poor solder contact there.
I decided to remove the chip entirely with my hot air rework gun, then resolder it properly. With that done, I verified good solid behavior, including the Seek, ReadSector and ReadEntireCartridge transactions. I uploaded the contents of the pack, along with the checksum validation array, so that I could check that the data was extracted properly.
The results were just as before, so I now have the production level board tested and ready to use tomorrow on the drive attached to the Alto and the other cartridges we have there.
As I packed up everything for transport, I decided to inspect the disk cartridge surface and the heads. I can see scraping and discoloration at the low cylinder numbers near where I am experiencing almost all of the checksum errors reading that cartridge.
I will tentatively ascribe the errors to the surface condition, thus hope that my tool works well with undamaged cartridges on the other Diablo drive, the one that came with the Alto. We will know more tomorrow after we read and upload all the content.
I set up the testbed and began to check the functionality and signal integrity of the new board and connectors. Seeking was checked to be sure all the address bits were working - but in fact the 4 and 16 lines were not working. I found that the chip pins involved were not well soldered, fixed it and went back to test.
In addition, I have a Digilent Nexys2 FPGA board that was purchased by Al Kossow in order to give him a working disk driver and emulator. It had connectivity problems in the USB connector, with the connector itself bent and some other problems where it was attached. I used my heat gun to remove the connector, bought replacements and will surface mount the new part when it arrives.
The disk drive testing resumed and my seek addresses were all working correctly. Next up is getting the ReadGate and other signals tested. I am emitting '1' to ReadGate which should pull the output of chip U2 side 1 down to ground, thus activating pin 39 on the ribbon cable to signal pin E.
However, when I monitor pin E on the terminator, the line is not going down to ground. I have continuity from the fpga connector pin to chip U2, from the chip output to pin 39 on the connector, and all the way through the cable and drive to the terminator.
I might have a flaw with chip U2 such that it is not working, even though all the connections to and from it are good. I have to do a power-on test and verify the voltage levels at the chip. Watching the scope, I could see that the signal at the terminator changes as I probe the chip pins, indicating I probably have a poor solder contact there.
I decided to remove the chip entirely with my hot air rework gun, then resolder it properly. With that done, I verified good solid behavior, including the Seek, ReadSector and ReadEntireCartridge transactions. I uploaded the contents of the pack, along with the checksum validation array, so that I could check that the data was extracted properly.
The results were just as before, so I now have the production level board tested and ready to use tomorrow on the drive attached to the Alto and the other cartridges we have there.
As I packed up everything for transport, I decided to inspect the disk cartridge surface and the heads. I can see scraping and discoloration at the low cylinder numbers near where I am experiencing almost all of the checksum errors reading that cartridge.
 |
| Surface marking that is probably the cause of my errors reading some sectors |
 |
| Surface marking on the other side of the platter |
Saturday, December 24, 2016
Holiday downtime
Due to the holidays, my test setup is stored away and nothing can be done on the project. Back soon!
Friday, December 23, 2016
Changed emulator board design and sent to fab
ALTO DISK TOOL
My early testing with the Emulator role PCB shows that it is not going to work properly. The signals going from the fpga to the Alto require pull-up and pull-down resistors to give the ribbon cable termination. This should have been placed on the Alto side, but they were not, instead terminating the signals that ran from Diablo to Alto by resistors on the drive side.
I need to expand the PCB to add a pair of resistors per outgoing signal, a total of 22 added resistors. Good thing I only ordered one board for $66, of course with shipping and tax on top, as it is wasted. Time to get to the designing (and to order more components).
I had the 1401 restoration team meeting yesterday and spent quite a bit of time chasing down a flaw that resulted in card reader error stops. Greatly improved now, so that programs which use the read then print instruction can get through hundreds of cards before stopping. It had been failing on the third card pretty regularly.
Thursday morning I changed the emulator card design to add in the termination resistors and decided to send out for a new card through the same fast turnaround service I used previously. Another $100 and should be about two weeks to receive it.
My early testing with the Emulator role PCB shows that it is not going to work properly. The signals going from the fpga to the Alto require pull-up and pull-down resistors to give the ribbon cable termination. This should have been placed on the Alto side, but they were not, instead terminating the signals that ran from Diablo to Alto by resistors on the drive side.
I need to expand the PCB to add a pair of resistors per outgoing signal, a total of 22 added resistors. Good thing I only ordered one board for $66, of course with shipping and tax on top, as it is wasted. Time to get to the designing (and to order more components).
I had the 1401 restoration team meeting yesterday and spent quite a bit of time chasing down a flaw that resulted in card reader error stops. Greatly improved now, so that programs which use the read then print instruction can get through hundreds of cards before stopping. It had been failing on the third card pretty regularly.
Thursday morning I changed the emulator card design to add in the termination resistors and decided to send out for a new card through the same fast turnaround service I used previously. Another $100 and should be about two weeks to receive it.
Tuesday, December 20, 2016
Construction progress on PCBs and cabling, plus more testing
ALTO DISK TOOL
Parts are on order to complete the remaining driver and emulator boards - shipped today but not likely to get here before Xmas due to the heavy volume at all the delivery services. I did put on some of the components I still had - capacitors, IDC connectors and driver chips, for instance - before putting the boards aside.
Testing out the new driver board involved checking a number of items, as listed in yesterday's post. Step 1 was already complete.
Verify that SelectUnit1 is switchable and not permanently on from the fpga- Verify that the terminator has the pull up and pull down resistors installed for all the signal lines I am driving, but none on the lines returning from the Diablo to my fpga.
- Monitor signals incoming to the PCB to validate their correctness
- Monitor signals at the terminator when my PCB is driving the Diablo to validate their correctness.
Steps 2 and 3 were relatively straightforward, as there is easy access to the pins needed to monitor those circuits. Step 4 is more challenging and will require hooking on micrograbbers and multiple cycles of removing and installing the terminator.
I found several of my incoming signals had termination on the sending end, as well as on my board. I clipped off the resistors on those signals. Everything else checked on with termination resistors, allowing me to complete step 2 above.
Step 3 will be done by a simple power up and attaching the scope probes to the tops of the three level shifter mini-boards across the top of my PCB.
I took some time to put the IDC connector on the ribbon cable that attaches to the Alto disk controller card on its other end. This cable is now attached to the emulator board.
Monday, December 19, 2016
Powered on new driver PCB and tested its correct functioning, also mostly build emulator role board
ALTO DISK TOOL
Today I worked on the connector from the ATX PC power supply to the driver board of the disk tool, or alternatively a direct wired cable from the power supply to the board. I went with a modification of the cable I had been connecting via wire nuts, but soldered everything to a 4 pin connector. It has an indicator light, the load power resistor and the connector to fit to my PCB.
Power is good, so I proceeded to power on testing. I had mixed results from the first test, other than it passed the magic smoke and hot component tests. I could set up and accomplish seeks, although this worked with or without the SelectUnit1 line activated which is NOT what should happen.
The drive should ignore all signals unless SelectUnit1 is pulled to ground and while it is ignoring incoming signals, it should not drive any return signals to the PCB. Instead, I see status, sector marks, sector numbers and other signals driven regardless of my Select slide switch.
Seeks worked, but no response to a ReadSector or ReadEntireCartridge transaction. Time to do a few things before I proceed:
- Verify that SelectUnit1 is switchable and not permanently on from the fpga
- Verify that the terminator has the pull up and pull down resistors installed for all the signal lines I am driving, but none on the lines returning from the Diablo to my fpga.
- Monitor signals incoming to the PCB to validate their correctness
- Monitor signals at the terminator when my PCB is driving the Diablo to validate their correctness.
Step 1 yielded the insight that I had changed the logic in the fpga to hold SelectUnit1 on, thus the behavior was what should be expected. Eventually, this will be switched off except for the duration of transactions, but during testing it is easier if I can observe ReadData, ReadClock, SectorMark and other signals all the time.
I began looking at the terminator resistors and cross checking it all to the schematics and design of my board. I didn't complete this before my shipment of the emulator board PCB blank arrived.
In addition, my emulator role PCB arrived today and I began to assemble components on it. It is time consuming due to the small size of the parts. The resistors and capacitors are size 0805, one of which is held in tweezer tips in the photo below, on lined writing pad paper with one line visible for scale.
I ran out of the header strips I need to mount the last two components, each a level shifting mini-board that connects 3.3V and 5V sides for four circuits each. Once these come in, I can test out the wiring of the board prior to firing it up to test the disk emulator role.
As you can see, the disk driver and disk emulator boards are fairly similar in overall appearance, but are quite different in details. They are electronically keyed, using pins 20 and 21 of the fpga, so that when the board is connected, the fpga logic knows whether it is operating in emulator or driver mode by which of the pins are grounded.
I began looking at the terminator resistors and cross checking it all to the schematics and design of my board. I didn't complete this before my shipment of the emulator board PCB blank arrived.
In addition, my emulator role PCB arrived today and I began to assemble components on it. It is time consuming due to the small size of the parts. The resistors and capacitors are size 0805, one of which is held in tweezer tips in the photo below, on lined writing pad paper with one line visible for scale.
 |
| 0805 size component on lined paper, in tweezer tips |
As you can see, the disk driver and disk emulator boards are fairly similar in overall appearance, but are quite different in details. They are electronically keyed, using pins 20 and 21 of the fpga, so that when the board is connected, the fpga logic knows whether it is operating in emulator or driver mode by which of the pins are grounded.
 |
| disk emulator role board, assembled but for two level shifter miniboards |
Sunday, December 18, 2016
Built additional boards and tested them, ready to connect power and run the Diablo
ALTO DISK TOOL
I began to build a second driver board, but after putting on the resistors and preparing to install capacitors, I found the VCC and ground lines were shorted. I couldn't find any spot that seemed to be causing the problem, even after lifting as much solder as I could off the board. I put it aside as a potential bad board.
Taking a third PCB card, I did a full installation of all components, with no signs of shorts or other problems. It still must pass the wiring and correct operation tests, just as the first board I built must. The first board passed all its connectivity tests by mid afternoon, then I went back to the bad board so see what is wrong.
To ensure that it wasn't a solder bridge under one of the resistors or the power connector, I removed them all and used solder braid to wick off as much solder as possible. The board continued to show that all four pins of the power connector were bridged together, thus shorting +5V, +3.3V and ground. It is unusable.
I put the third PCB (2nd is bad) on the test bench. All the connectivity and short circuit tests were passed, visual inspection is good too. All that remains is to power it up and check the function of the drive with the fpga logic.
I mounted the driver PCB board on the extension board and hooked that to the fpga, ready to test as soon as I wire up the main power connector. Instead of wire nuts hooked to the existing power supply connector, I will make up a proper cable which bridges between the PC power supply main connector, that would normally be plugged onto a motherboard, and the four pin connector to drive my PCB.
One wire has to be connected to ground to 'turn on' the supply, and the power resistor you see on the bottom has to provide a load in order for the supply to work, but many of the voltages supplied are unneeded. All it will take to build this is an ATX power supply plug, some heavy wire and a 4 pin Molex plug for the other end.
I began to build a second driver board, but after putting on the resistors and preparing to install capacitors, I found the VCC and ground lines were shorted. I couldn't find any spot that seemed to be causing the problem, even after lifting as much solder as I could off the board. I put it aside as a potential bad board.
Taking a third PCB card, I did a full installation of all components, with no signs of shorts or other problems. It still must pass the wiring and correct operation tests, just as the first board I built must. The first board passed all its connectivity tests by mid afternoon, then I went back to the bad board so see what is wrong.
 |
| Board 1 installed on the extension board |
 |
| Board 2 with shorted power connector pins - unusable |
I put the third PCB (2nd is bad) on the test bench. All the connectivity and short circuit tests were passed, visual inspection is good too. All that remains is to power it up and check the function of the drive with the fpga logic.
 |
| Board 2, in place waiting for power connector hookup |
 |
| Power supply connector |
Building new driver board
ALTO DISK TOOL
The new driver board PCBs arrived and I began soldering components on one of them. Surface mount components are sooooo tiny, it is painfully slow going. When I found my soldering tweezers, which are spring loaded closed, I could hold and maneuver the parts.
Once it was apparently all soldered in place, I had to carefully check every circuit for connectivity and shorts, as well as appropriate resistance. This took the remainder of the day, since I want to be sure that this board is correct.
The 40 pin connector on the right attaches to the cable from the Diablo disk drive. The four pin connector at the left top is the power connector to the board. Another 40 pin connector is at the left, but mounted on the underside of the board. This underside connector attaches to the FPGA and its extension board.
The new driver board PCBs arrived and I began soldering components on one of them. Surface mount components are sooooo tiny, it is painfully slow going. When I found my soldering tweezers, which are spring loaded closed, I could hold and maneuver the parts.
Once it was apparently all soldered in place, I had to carefully check every circuit for connectivity and shorts, as well as appropriate resistance. This took the remainder of the day, since I want to be sure that this board is correct.
 |
| New driver board, assembled and under checkout |
Friday, December 16, 2016
Built PLL, integrating it into the driver logic; PCBs shipped
ALTO DISK TOOL
Today, my driver boards are on their way, That would put the boards in my hand sometime on the 20th. The emulator board also shipped, but that will arrive midweek, a bit after the driver boards.
Monday night, at a dinner meeting with a number of technology enthusiasts that began life decades ago as the Motorola 6800 computer club, we discussed the data separation issues and a number of potential solutions. PLL is the consensus approach. .
I ran a few reads of sectors with repeatable errors and looked at the digital and analog results carefully to draw some conclusions if possible. Slow going. Knowing exactly what fails and why is important to devising a solution, otherwise I am just using brute force enhancements in the hope I hit the target.
I set up a phase locked loop and am doing some experimenting to see how well it does at data separation as a possible replacement for the one built into the Diablo drive. Tedious work to set up various jittery input patterns and read the simulator output to judge its response. Bashed through the day working on it.
Once I had the PLL doing a decent job syncing to the clock bits, I had to modify it to produce a fixed duration pulse of 100 ns, as the PLL produces 50% duty cycle outputs. Once that is done, I need to sort out the separator logic and the startup state which routes the first transition as a clock. This will be tricky.
Today, my driver boards are on their way, That would put the boards in my hand sometime on the 20th. The emulator board also shipped, but that will arrive midweek, a bit after the driver boards.
Monday night, at a dinner meeting with a number of technology enthusiasts that began life decades ago as the Motorola 6800 computer club, we discussed the data separation issues and a number of potential solutions. PLL is the consensus approach. .
I ran a few reads of sectors with repeatable errors and looked at the digital and analog results carefully to draw some conclusions if possible. Slow going. Knowing exactly what fails and why is important to devising a solution, otherwise I am just using brute force enhancements in the hope I hit the target.
I set up a phase locked loop and am doing some experimenting to see how well it does at data separation as a possible replacement for the one built into the Diablo drive. Tedious work to set up various jittery input patterns and read the simulator output to judge its response. Bashed through the day working on it.
Once I had the PLL doing a decent job syncing to the clock bits, I had to modify it to produce a fixed duration pulse of 100 ns, as the PLL produces 50% duty cycle outputs. Once that is done, I need to sort out the separator logic and the startup state which routes the first transition as a clock. This will be tricky.
Monday, December 12, 2016
Waiting on PCBs, refining retry logic while reading cartridges
ALTO DISK TOOL
Final components are on hand, now watching PCB move through the foundries. The driver PCB is currently being plated, presumably the next steps are creating the sandwich of layers and QA inspection before shipping. They estimate shipping by December 15th, with three day shipping in place, which means the boards likely arrive early next week.
The single emulator board is assigned to a large panel to be manufactured. Once the entire 4 layer panel is built and cut apart to the separate boards, mine can be checked and shipped. This board will likely arrive late next week.
Digilent had an online sale, where I picked up both extension boards and FX2 connectors at a very attractive rate. These will allow me to build out all the boards I expect to make in the coming weeks.
I tweaked the ReadEntireCartridge transaction to let me control the number of retries when a checksum error is detected. I can have none, 31 or 62 based on fpga board switch settings. I will run some experiments - seeing the number of error sectors with no retry, then assess the results of 31 or 62.
This afternoon, I ran those tests and see that very few are corrected by retry. Performing a single read across the entire cartridge resulted in 123 sectors with a checksum validation error. Whether retry was done for 31 or 62 times, we had 119 bad sectors. That is, only four sectors had temporary errors that were resolved by rereading. The bad sectors are extremely consistent from run to run, as well.
It is time to study failing sectors in more detail, to discover where the fault happens and the characteristics. If there is a pattern that I can detect and if a more intelligent data separator would avoid the fault, then I will build it.
To do separation, I must first OR together ReadClock and ReadData to give me the original combined pulse stream. That is simple to accomplish. Separating, depending on the full list of errors I find, might be a bit challenging but perfect extraction is the goal.
Final components are on hand, now watching PCB move through the foundries. The driver PCB is currently being plated, presumably the next steps are creating the sandwich of layers and QA inspection before shipping. They estimate shipping by December 15th, with three day shipping in place, which means the boards likely arrive early next week.
 |
| Driver boards in process, arrive early next week |
Digilent had an online sale, where I picked up both extension boards and FX2 connectors at a very attractive rate. These will allow me to build out all the boards I expect to make in the coming weeks.
 |
| Extension boards |
 |
| FX2 connector to use in lieu of extension board |
This afternoon, I ran those tests and see that very few are corrected by retry. Performing a single read across the entire cartridge resulted in 123 sectors with a checksum validation error. Whether retry was done for 31 or 62 times, we had 119 bad sectors. That is, only four sectors had temporary errors that were resolved by rereading. The bad sectors are extremely consistent from run to run, as well.
It is time to study failing sectors in more detail, to discover where the fault happens and the characteristics. If there is a pattern that I can detect and if a more intelligent data separator would avoid the fault, then I will build it.
To do separation, I must first OR together ReadClock and ReadData to give me the original combined pulse stream. That is simple to accomplish. Separating, depending on the full list of errors I find, might be a bit challenging but perfect extraction is the goal.
Working on the drive and fpga to further improve reading accuracy
ALTO DISK TOOL
I bought some 9601 timer chips, the same as used in the Diablo board, in order to experiment with the timing and appropriate component values. The 'long' timer might be running a hair short, hard to say for sure based only on the logic analyzer traces. I tried to set up the scope to get a more precise value.
Using the scope and some calculations, I worked out some fine tuning to get the timers closer to the ideal timing for the Alto, reworked the board and validated the timings afterwards. Resistances increased to make the times a bit longer.
With that change in place, I did another ReadEntireCartridge transaction and uploaded the resulting image and checksum status files for processing. Immediately I saw that I had very long stretches where no errors at all occurred.
I did the postprocessing and analysis on my laptop, running the Python programs I derived from Ken's work, and looked at the success rate of reading this cartridge with the improved board. I am seeing differences in 4% of the sectors and 2.1% of the total words, statistically about the same as before, but actually a lot fewer sectors had errors.
The only checksum validation errors were on cylinders 5-15, 26 and 44, just 12 out of 203 cylinders on the cartridge. with the errors concentrated so that about half the sectors on each cylinder had errors.
I am going to tweak my ReadEntireCartridge logic to support additional retries and make it more robust. At this point, it is possible that there is some corruption on the cartridge on those low cylinders, because I have an exact match between the bitsaver archive image of the cartridge and the contents I read, other than on those 12 low cylinders.
The errors occur sporadically across the cylinders, not bunched together. If it were surface defects or deterioration of the media, I would expect to have errors on all records of the sector and several consecutive sectors, not the pattern I see; there are errors only on the data record and they are well distributed across each head and cylinder.
If I can get the errors down to essentially zero, I will be satisfied. Until then, I want to continue researching and honing the system.
I bought some 9601 timer chips, the same as used in the Diablo board, in order to experiment with the timing and appropriate component values. The 'long' timer might be running a hair short, hard to say for sure based only on the logic analyzer traces. I tried to set up the scope to get a more precise value.
Using the scope and some calculations, I worked out some fine tuning to get the timers closer to the ideal timing for the Alto, reworked the board and validated the timings afterwards. Resistances increased to make the times a bit longer.
With that change in place, I did another ReadEntireCartridge transaction and uploaded the resulting image and checksum status files for processing. Immediately I saw that I had very long stretches where no errors at all occurred.
I did the postprocessing and analysis on my laptop, running the Python programs I derived from Ken's work, and looked at the success rate of reading this cartridge with the improved board. I am seeing differences in 4% of the sectors and 2.1% of the total words, statistically about the same as before, but actually a lot fewer sectors had errors.
The only checksum validation errors were on cylinders 5-15, 26 and 44, just 12 out of 203 cylinders on the cartridge. with the errors concentrated so that about half the sectors on each cylinder had errors.
I am going to tweak my ReadEntireCartridge logic to support additional retries and make it more robust. At this point, it is possible that there is some corruption on the cartridge on those low cylinders, because I have an exact match between the bitsaver archive image of the cartridge and the contents I read, other than on those 12 low cylinders.
The errors occur sporadically across the cylinders, not bunched together. If it were surface defects or deterioration of the media, I would expect to have errors on all records of the sector and several consecutive sectors, not the pattern I see; there are errors only on the data record and they are well distributed across each head and cylinder.
If I can get the errors down to essentially zero, I will be satisfied. Until then, I want to continue researching and honing the system.
Saturday, December 10, 2016
Still investigating the read error cases, plus working on the new PCBs
ALTO DISK TOOL
I am still pondering the best way to handle the data separation for the Diablo drive. Yesterday I was looking at using a phase locked loop, but am now considering other means as alternatives. The point I am set on is the need to reverse the disk drive's separation and then accomplish this myself in the fpga.
The circuit above accomplishes data separation from the signal coming off the disk surface. In other circuitry, not shown here, the flux reversals detected by the disk head are converted into a positive going pulse of fixed duration, somewhere between 50 and 100 ns in duration. Thus, each reversal delivers on pulse to the circuitry above.
We will discuss its behavior proceeding from a point in time just before the arrival of a pulse that represents a clock. The routing flip-flop in the center is initially reset, thus the incoming pulse is routed to the lower right gates to become a ReadClock pulse.
The pulse that is sent as ReadClock will also serve as the clock to the routing flip-flop, which has its D input tied high so when the clock pulse arrives, the flip-flop sets to on. This will continue forever until the timer circuits to the left side switch off, this causing the routing flip-flop to again reset so that new pulses again go out on the ReadClock line.
However, while the routing flip-flop is set and has not yet been reset by the timer expiration, any pulse coming from the heads is routed out the upper gates as ReadData. Thus, from the arrival of a clock pulse until some time duration has elapsed, subsquent pulses are routed as data, but after the time elapses they again are processed as clock pulses.
The timer circuits on the left consist of two different timers, both are started by a ReadClock pulse, but lasting a short or a long duration. Which of the two timers is used depends on the leftmost flipflop, which is set to on when a ReadData pulse is delivered, but reset when the next ReadClock pulse arrives.
Thus, the default state once the ReadClock pulse arrives is that this is a zero bit, enabling the long timer to be used. This enables the long timer chip to produce a negative going output pulse for the duration of its time, kicked off when ReadClock line goes on.
However, when a data pulse arrives during the time interval, it sets the logic to instead use the short timer chip whose negative going output pulse occurs earlier after the clock. This occurs by setting the 'one bit' flipflop on the left. It is not reset until the next clock pulse ends, thus the timer started is based on the prior value at clock rising edge, before the falling edge resets this flipflop.
Our routing flipflop in the center is switched off by either of the timer chips emitting the negative going pulse when it times out, as well as when a ReadData pulse is emitted. It stops looking once it finds a 1 bit transition pulse, or when the timers run out.
When two transitions are close to each other, they seem to be shifted in time relative to each other, compared to the actual flux reversal written onto the media. Thus, this bit shift or pulse shift phenomenon is compensated for by the left side circuitry, If a 1 bit was detected, the routing resets earlier to look for a clock pulse.
The fault I am seeing is the arrival of the subsequent clock pulse early enough that it is routed as a data bit, not a clock bit. This is a fault of a timer that is too long. It happens sporadically and rarely, but causes a checksum validation error since the clock pulse is lost and the deserialization becomes confused.
If the timers are shortened further, there is the risk that a data pulse will appear as a spurious clock pulse, the inverse error to the one I saw. Since Xerox chose to operate the Diablo disk drives outside of their spec, which intends for a 660 ns bit cell time, timing becomes more critical.
Our big enemy is jitter - not just the pulse shifting that is inherent with magnetic reading, but jitter from other sources. The result is that the arrival timing of clock and data pulses is shifting about often, thus solutions such as fixed timing or a PLL are not perfect.
The rotation rate of the disk can vary as much as 1% per specifications, which in practice means that arrival times can be offset by up to 2% in the worst case where the writing drive is 1% off in one sense and the reading drive varies by 1% in the opposite sense. This can give us a jitter from 0 to 12 ns.
The oscillator used to write the disk is an imperfect circuit, thus its nominal rate of 3.33 Mhz can deviate a bit leading to jitter in the pulse timing of a similar amount. This might be as much as 30 ns jitter, although the rate of change is low so the impact won't affect single bit cells.
The clock rate recorded on the surface is totally determined by the writing system, in this case an Alto which wrote to the cartridge many years ago. Variations of the clock frequency are locked into the recorded signal. The receiving system (my fpga) uses the recorded clock not its own, thus it can't contribute any significant jitter.
Still, we have a drive engineered for a 660 ns bit cell operating at 600 ns with jitter than can run to about 45 ns if the worst case of clock rate and drive speed variations were to occur. This gives us a bit cell that could be 555 ns at worst case. Since each pulse produced, for clock or data is 50 to 150 ns in width, we have a window of approximately 405 to 495 to look for the data pulse.
The data separator in the Diablo uses 440 or 460 ns for long or short, which should just squeak by in the worst case. That worst case is a compressed 555 ns bit cell, with the prior cell containing a data value of 1 so that pulse shifting occurs.
Looking at the pulses separated during the anomalous period, I see a set of ReadClock pulses 600 ns apart, then the next clock pulse follows in just 300 ns. The following pulse, 600 ns later, is routed as a ReadData. 600 ns after that and every 600 following we see ReadClock pulses.
The odd issue with that sequence is that a pulse arriving 300 ns after the last clock would be a data pulse, but if it were then the clock following it is missing because the gap is again 600 ns. Something has interrupted the pulse train, chopping 300 ns out of it. I don't understand how this happened.
BUILDING DRIVER AND AND EMULATOR PCBs
I received most of the components on hand that will be used to build the driver and emulator boards, once the PCBs come in. The remaining components arrive on Monday, whereas the PCBs will take another week or so to show up.
I do have to prepare the cable for the emulator role, inserting the 40 pin connector on the cable half that runs to the Alto driver board. This has the metal ground plane bonded to the cable, just as the disk side of the cable had, and must be carefully peeled back in order to install the connector.
I am still pondering the best way to handle the data separation for the Diablo drive. Yesterday I was looking at using a phase locked loop, but am now considering other means as alternatives. The point I am set on is the need to reverse the disk drive's separation and then accomplish this myself in the fpga.
 |
| Data Separator circuit inside Diablo drive |
We will discuss its behavior proceeding from a point in time just before the arrival of a pulse that represents a clock. The routing flip-flop in the center is initially reset, thus the incoming pulse is routed to the lower right gates to become a ReadClock pulse.
The pulse that is sent as ReadClock will also serve as the clock to the routing flip-flop, which has its D input tied high so when the clock pulse arrives, the flip-flop sets to on. This will continue forever until the timer circuits to the left side switch off, this causing the routing flip-flop to again reset so that new pulses again go out on the ReadClock line.
However, while the routing flip-flop is set and has not yet been reset by the timer expiration, any pulse coming from the heads is routed out the upper gates as ReadData. Thus, from the arrival of a clock pulse until some time duration has elapsed, subsquent pulses are routed as data, but after the time elapses they again are processed as clock pulses.
The timer circuits on the left consist of two different timers, both are started by a ReadClock pulse, but lasting a short or a long duration. Which of the two timers is used depends on the leftmost flipflop, which is set to on when a ReadData pulse is delivered, but reset when the next ReadClock pulse arrives.
Thus, the default state once the ReadClock pulse arrives is that this is a zero bit, enabling the long timer to be used. This enables the long timer chip to produce a negative going output pulse for the duration of its time, kicked off when ReadClock line goes on.
However, when a data pulse arrives during the time interval, it sets the logic to instead use the short timer chip whose negative going output pulse occurs earlier after the clock. This occurs by setting the 'one bit' flipflop on the left. It is not reset until the next clock pulse ends, thus the timer started is based on the prior value at clock rising edge, before the falling edge resets this flipflop.
Our routing flipflop in the center is switched off by either of the timer chips emitting the negative going pulse when it times out, as well as when a ReadData pulse is emitted. It stops looking once it finds a 1 bit transition pulse, or when the timers run out.
When two transitions are close to each other, they seem to be shifted in time relative to each other, compared to the actual flux reversal written onto the media. Thus, this bit shift or pulse shift phenomenon is compensated for by the left side circuitry, If a 1 bit was detected, the routing resets earlier to look for a clock pulse.
The fault I am seeing is the arrival of the subsequent clock pulse early enough that it is routed as a data bit, not a clock bit. This is a fault of a timer that is too long. It happens sporadically and rarely, but causes a checksum validation error since the clock pulse is lost and the deserialization becomes confused.
If the timers are shortened further, there is the risk that a data pulse will appear as a spurious clock pulse, the inverse error to the one I saw. Since Xerox chose to operate the Diablo disk drives outside of their spec, which intends for a 660 ns bit cell time, timing becomes more critical.
Our big enemy is jitter - not just the pulse shifting that is inherent with magnetic reading, but jitter from other sources. The result is that the arrival timing of clock and data pulses is shifting about often, thus solutions such as fixed timing or a PLL are not perfect.
The rotation rate of the disk can vary as much as 1% per specifications, which in practice means that arrival times can be offset by up to 2% in the worst case where the writing drive is 1% off in one sense and the reading drive varies by 1% in the opposite sense. This can give us a jitter from 0 to 12 ns.
The oscillator used to write the disk is an imperfect circuit, thus its nominal rate of 3.33 Mhz can deviate a bit leading to jitter in the pulse timing of a similar amount. This might be as much as 30 ns jitter, although the rate of change is low so the impact won't affect single bit cells.
The clock rate recorded on the surface is totally determined by the writing system, in this case an Alto which wrote to the cartridge many years ago. Variations of the clock frequency are locked into the recorded signal. The receiving system (my fpga) uses the recorded clock not its own, thus it can't contribute any significant jitter.
Still, we have a drive engineered for a 660 ns bit cell operating at 600 ns with jitter than can run to about 45 ns if the worst case of clock rate and drive speed variations were to occur. This gives us a bit cell that could be 555 ns at worst case. Since each pulse produced, for clock or data is 50 to 150 ns in width, we have a window of approximately 405 to 495 to look for the data pulse.
The data separator in the Diablo uses 440 or 460 ns for long or short, which should just squeak by in the worst case. That worst case is a compressed 555 ns bit cell, with the prior cell containing a data value of 1 so that pulse shifting occurs.
Looking at the pulses separated during the anomalous period, I see a set of ReadClock pulses 600 ns apart, then the next clock pulse follows in just 300 ns. The following pulse, 600 ns later, is routed as a ReadData. 600 ns after that and every 600 following we see ReadClock pulses.
The odd issue with that sequence is that a pulse arriving 300 ns after the last clock would be a data pulse, but if it were then the clock following it is missing because the gap is again 600 ns. Something has interrupted the pulse train, chopping 300 ns out of it. I don't understand how this happened.
BUILDING DRIVER AND AND EMULATOR PCBs
I received most of the components on hand that will be used to build the driver and emulator boards, once the PCBs come in. The remaining components arrive on Monday, whereas the PCBs will take another week or so to show up.
I do have to prepare the cable for the emulator role, inserting the 40 pin connector on the cable half that runs to the Alto driver board. This has the metal ground plane bonded to the cable, just as the disk side of the cable had, and must be carefully peeled back in order to install the connector.
Friday, December 9, 2016
Contemplating replacing Diablo data separator circuit with fpga based phase locked loop
ALTO DISK TOOL
I developed a watchdog timer in the fpga that will emit a signal if the time between clock pulses is 700ns or longer - this will help me flag spots where the Diablo drive is misidentifying a 0 bit with late clock as a 1 bit and missing clock. I can then reliably trigger both logic analyzer and oscilloscope to see the behavior of interest.
Data is recorded on the disk with a non-return-to-zero encoding (also called frequency modulation which evolved to MFM for the first PC disks), where bit cells of 600 ns are written by reversing the magnetic flux once or twice. At the beginning of each bit cell, the flux is always flipped, which is the clock. In the middle of the cell, if the bit in question is to be a 1, another flux transition occurs, whereas a 0 bit value does not cause a reversal.
This is why disk records start with a long string of zero bits, to help the reading circuitry to synchronize on the clock bit as the start of a bit cell. The clock bits are the only transitions when the data values are all zero.
The start of meaningful data is signalled by a special non-zero pattern, which for the Diablo is a single bit cell with a data value of 1. The reading circuits pass through the flux reversal as a clock pulse and then flip the logic for less than 500 ns so that any reversal in that interval will be passed as a data bit value. This window of time where a flux reversal is a data bit is how the circuit separates clock from data pulses.
I have found spots on the disk where a record gets a checksum error, at least on some read attempts, because the clock pulse is misreported as a data pulse. Specifically, the bit cell is meant to contain a value of 0, so that the flux reversals are the clock at the start and end. In this case, the next reversal which is intended to be the clock is passed along as a data value of 1, because the timer window is still open. The clock pulse arrived a bit early.
Now, when the clock pulse following a 0 value bit cell is misrouted as a 1 data value, and the next bit cell is also a data value of 0, then we will have a longer than usual gap until the next flux reversal. The two 0 bit cells are collapsed together as a single 1 bit.
Out of the data separator circuit, we see the clock pulses skip a beat, with 1200 ns between pulses at this point. The data pulse is also wrong and more sinisterly, the serial train of data bits is compressed with two lost 0 bits reported as only a single 1 bit. This misaligns all the remaining data bits and checksum for the remainder of the record.
It is possible that I could detect and correct for this error, but it would be complex. I would need to establish the bit rate, adjust to stay synchronized with the clock transitions and then look for malformations. One such would be a skipped clock pulse coupled with a 1 data value. I could morph that into a pair of clock pulses representing the two data bits of 0.
I would need to look carefully at all the possible cases - 0 bit cell where this happens followed by a 1 bit cell, as well as other cases where clock and data are misrouted by the data separator circuitry. In essence, I will combine these to produce the flux transitions and separate them myself using more sophistication than a simple timing window.
I can also imagine errors where the pulse is split between data and clock, when the timing window elapses somewhere in the middle of a flux reversal pulse. If I combine the ReadClock and ReadData signals myself to form the original pulse train before the separator does its task, I can bypass the source of these errors and accomplish the detection of bit values correctly.
I need a second order digital phase locked loop to recover the clock properly, then use that to indicate bit cell boundaries and watch for the data 1 pulses. The incoming signal is messy, having timing jitter due to rotational variations on both write and read passes plus bit peak shifting. It may also suffer from minor variations in the media surface and from oscillations of the head heighth.
Beginning with single density floppy disks and PC era hard drives, the written signal was 'pre-compensated' to minimize the shifting of pulses upon reading, but no such technique was used with the Diablo drives.
Floppy disk data separator chips were available but are intended to support the much lower bit rates of the original SD and DD floppy drives, 250Kbps to 500Kbps whereas the Diablo is streaming data bits are 1.67 Mbps. The phase locked loops available on the Spartan 3E fpga chips won't operate at so low a frequency, requiring minimum frequencies in the range of 10Mhz.
Thus, I have to work out a different method. Opencores has a DPLL although I am not certain how good it will be at handling disk signals.The goal is to generate a train of clock outputs that is synchronized to the time averaged clock pulses observed from the head, then use that to cleanly separate transitions that are far enough from the clock to be considered a data bit value of 1.
I will implement this in the fpga, digitally mix the ReadData and ReadClock as an input, create the scaffolding for the data separator based on this, then compare the results of this versus the Diablo separator circuit. This is going to be complex design work.
I developed a watchdog timer in the fpga that will emit a signal if the time between clock pulses is 700ns or longer - this will help me flag spots where the Diablo drive is misidentifying a 0 bit with late clock as a 1 bit and missing clock. I can then reliably trigger both logic analyzer and oscilloscope to see the behavior of interest.
Data is recorded on the disk with a non-return-to-zero encoding (also called frequency modulation which evolved to MFM for the first PC disks), where bit cells of 600 ns are written by reversing the magnetic flux once or twice. At the beginning of each bit cell, the flux is always flipped, which is the clock. In the middle of the cell, if the bit in question is to be a 1, another flux transition occurs, whereas a 0 bit value does not cause a reversal.
This is why disk records start with a long string of zero bits, to help the reading circuitry to synchronize on the clock bit as the start of a bit cell. The clock bits are the only transitions when the data values are all zero.
The start of meaningful data is signalled by a special non-zero pattern, which for the Diablo is a single bit cell with a data value of 1. The reading circuits pass through the flux reversal as a clock pulse and then flip the logic for less than 500 ns so that any reversal in that interval will be passed as a data bit value. This window of time where a flux reversal is a data bit is how the circuit separates clock from data pulses.
I have found spots on the disk where a record gets a checksum error, at least on some read attempts, because the clock pulse is misreported as a data pulse. Specifically, the bit cell is meant to contain a value of 0, so that the flux reversals are the clock at the start and end. In this case, the next reversal which is intended to be the clock is passed along as a data value of 1, because the timer window is still open. The clock pulse arrived a bit early.
Now, when the clock pulse following a 0 value bit cell is misrouted as a 1 data value, and the next bit cell is also a data value of 0, then we will have a longer than usual gap until the next flux reversal. The two 0 bit cells are collapsed together as a single 1 bit.
Out of the data separator circuit, we see the clock pulses skip a beat, with 1200 ns between pulses at this point. The data pulse is also wrong and more sinisterly, the serial train of data bits is compressed with two lost 0 bits reported as only a single 1 bit. This misaligns all the remaining data bits and checksum for the remainder of the record.
It is possible that I could detect and correct for this error, but it would be complex. I would need to establish the bit rate, adjust to stay synchronized with the clock transitions and then look for malformations. One such would be a skipped clock pulse coupled with a 1 data value. I could morph that into a pair of clock pulses representing the two data bits of 0.
I would need to look carefully at all the possible cases - 0 bit cell where this happens followed by a 1 bit cell, as well as other cases where clock and data are misrouted by the data separator circuitry. In essence, I will combine these to produce the flux transitions and separate them myself using more sophistication than a simple timing window.
I can also imagine errors where the pulse is split between data and clock, when the timing window elapses somewhere in the middle of a flux reversal pulse. If I combine the ReadClock and ReadData signals myself to form the original pulse train before the separator does its task, I can bypass the source of these errors and accomplish the detection of bit values correctly.
I need a second order digital phase locked loop to recover the clock properly, then use that to indicate bit cell boundaries and watch for the data 1 pulses. The incoming signal is messy, having timing jitter due to rotational variations on both write and read passes plus bit peak shifting. It may also suffer from minor variations in the media surface and from oscillations of the head heighth.
Beginning with single density floppy disks and PC era hard drives, the written signal was 'pre-compensated' to minimize the shifting of pulses upon reading, but no such technique was used with the Diablo drives.
Floppy disk data separator chips were available but are intended to support the much lower bit rates of the original SD and DD floppy drives, 250Kbps to 500Kbps whereas the Diablo is streaming data bits are 1.67 Mbps. The phase locked loops available on the Spartan 3E fpga chips won't operate at so low a frequency, requiring minimum frequencies in the range of 10Mhz.
Thus, I have to work out a different method. Opencores has a DPLL although I am not certain how good it will be at handling disk signals.The goal is to generate a train of clock outputs that is synchronized to the time averaged clock pulses observed from the head, then use that to cleanly separate transitions that are far enough from the clock to be considered a data bit value of 1.
I will implement this in the fpga, digitally mix the ReadData and ReadClock as an input, create the scaffolding for the data separator based on this, then compare the results of this versus the Diablo separator circuit. This is going to be complex design work.
Thursday, December 8, 2016
Emulator board designed and fabbed out
ALTO DISK TOOL
Today I completed the emulator role board design and shipped it off to a different foundery, pcbunlimited.com, as they would do a quantity one order. I need to be more confident in the correctness of the board before I order more.
The above board is 6" wide by 4" high and has an 2x20 IDC type male shrouded connector on each side. The left one is mounted on the bottom of the board and plugs downward into the female connector on the Digilent FPGA extension board seen below. The right side connector is mounted on the top and accepts the 40 signal ribbon cable that runs to the Alto computer or other system that makes use of a Diablo 31 disk drive.
Below is the multilayer view of the driver board, the same size as the emulator board but with different numbers of input and output circuits and connections as befits its role. It also mounts atop a Digilent extension board that will in turn plug into a Nexys3 fpga board.
Finally, to round out the pictures, here is the Nexys3 board onto which the extension board is connected. A USB connection on the left lower side communicates with a PC in order to load and store disk images.
Today I completed the emulator role board design and shipped it off to a different foundery, pcbunlimited.com, as they would do a quantity one order. I need to be more confident in the correctness of the board before I order more.
 |
| Multilayer view of PCB design for emulator board |
The above board is 6" wide by 4" high and has an 2x20 IDC type male shrouded connector on each side. The left one is mounted on the bottom of the board and plugs downward into the female connector on the Digilent FPGA extension board seen below. The right side connector is mounted on the top and accepts the 40 signal ribbon cable that runs to the Alto computer or other system that makes use of a Diablo 31 disk drive.
 |
| Extension board, fpga plugs to left and driver/emulator board sits on top |
 |
| Multilayer view of PCB design for driver boar |
Finally, to round out the pictures, here is the Nexys3 board onto which the extension board is connected. A USB connection on the left lower side communicates with a PC in order to load and store disk images.
 |
| Nexys3 fpga board hooks to extension board |
Wednesday, December 7, 2016
Driver board released to foundry, beginning on emulator board.
Wednesdays as always I spent most of the day at CHM, meeting with the 1401 restoration team members.
ALTO DISK TOOL
I spent another day iterating with the online free design verification tool associated with the 4PCB foundry and with my design on DesignSpark PCB. I really cleaned up the design substantially, ensured a good silkscreen layer, but had to accept some spurious errors that reflect limitations of the checking software.
Specifically, a metal plated hole through a board is called a 'via' and links a copper trace on one layer to another trace on a different layer. Mostly, these are linking the top and bottom layers of the board, where traces run left to right on the top layer and top to bottom for the bottom layer. Thus, a signal can pass over another using the 'other' layer.
I designed this for a four-layer board, which has two internal layers in addition to the top and bottom. One of the internal layers is ground and the other is the +5V power. If a component is connected to ground or +5V, it has a larger via which is electrically connected to one of the inner layers.
The design review software spots vias when they have signals connected to them on both top and bottom, the typical usage, but if the via is connected internally, the software confuses the plated hole with a hole that a component lead will fill. If a component is attached to the hole, it has to be soldered on.
Any spot where soldering occurs must have an opening on the solder mask layer, all other parts of the circuit board to and bottom are insulated with a thick green coating. Since the software falsely thinks the power or ground via is a solder pad for a through-hole component, it is flagging to me that the solder mask is covering this pad. That would render the pad or component hole un-solderable but in this case, no solder is needed.
I placed the order for four boards, to arrive in a bit more than a week, at a net cost of just under $300 or $75 per board. I should have all the components to attach by the time the boards arrive, thus I can assemble them at that time.
It is time to begin designing the complementary board, for the disk emulator role, which will use the tried and true components and circuit elements, only connecting them in a different order to suit the disk signals going in and out of the Alto computer.
ALTO DISK TOOL
I spent another day iterating with the online free design verification tool associated with the 4PCB foundry and with my design on DesignSpark PCB. I really cleaned up the design substantially, ensured a good silkscreen layer, but had to accept some spurious errors that reflect limitations of the checking software.
Specifically, a metal plated hole through a board is called a 'via' and links a copper trace on one layer to another trace on a different layer. Mostly, these are linking the top and bottom layers of the board, where traces run left to right on the top layer and top to bottom for the bottom layer. Thus, a signal can pass over another using the 'other' layer.
I designed this for a four-layer board, which has two internal layers in addition to the top and bottom. One of the internal layers is ground and the other is the +5V power. If a component is connected to ground or +5V, it has a larger via which is electrically connected to one of the inner layers.
The design review software spots vias when they have signals connected to them on both top and bottom, the typical usage, but if the via is connected internally, the software confuses the plated hole with a hole that a component lead will fill. If a component is attached to the hole, it has to be soldered on.
Any spot where soldering occurs must have an opening on the solder mask layer, all other parts of the circuit board to and bottom are insulated with a thick green coating. Since the software falsely thinks the power or ground via is a solder pad for a through-hole component, it is flagging to me that the solder mask is covering this pad. That would render the pad or component hole un-solderable but in this case, no solder is needed.
I placed the order for four boards, to arrive in a bit more than a week, at a net cost of just under $300 or $75 per board. I should have all the components to attach by the time the boards arrive, thus I can assemble them at that time.
It is time to begin designing the complementary board, for the disk emulator role, which will use the tried and true components and circuit elements, only connecting them in a different order to suit the disk signals going in and out of the Alto computer.
Driver board PCB designed, prepping for manufacturing and components ordered
ALTO DISK TOOL
I did battle most of the day with the DesignSpark PCB tool attempting to get a good quality board designed. A reasonably large board, 4 x 6", less than 40 components, and building it as a four layer board, which shouldn't be challenging. However, I may have to hand route everything.
I finally spotted a problem, that the ground and power planes in the four layer board weren't being used for ground and +5V. That cut down on routing and had the added advantage of handling the fairly beefy current requirements of the peripheral driver chips, which can sink 150ma per signal line when it has a logical 1 value. The worst case is during a seek command, with multiple track lines active plus the strobe.
The next step was some intelligent placement of the components, knowing how they need to be routed, to minimize crossing paths and conflicts. The pull up and pull down resistors that form the terminator for the input signals were the major factor in congestion, thus they were the major focus of my work.
I also moved the filtering capacitors and the peripheral driver chips to make more room for signal paths on the board. The result was a good clean routing with no manufacturing check conditions. With that complete, I produced the outputs needed for board manufacturing - gerber and excelon format files for the various layers and drill holes.
I will order two boards and enough components to build 4 or more boards- connectors, chips, resistors, and capacitors, which will let me complete the boards once everything gets here.
The foundry I chose, 4pcb.com, has a free service to analyze the files for manufacturability issues. I made use of it and found quite a few niggling errors and one significant one that slipped past the design checks of the DesignSpark PCB software. Time to iterate until I get satisfactory results from the foundry's free check software.
I did battle most of the day with the DesignSpark PCB tool attempting to get a good quality board designed. A reasonably large board, 4 x 6", less than 40 components, and building it as a four layer board, which shouldn't be challenging. However, I may have to hand route everything.
I finally spotted a problem, that the ground and power planes in the four layer board weren't being used for ground and +5V. That cut down on routing and had the added advantage of handling the fairly beefy current requirements of the peripheral driver chips, which can sink 150ma per signal line when it has a logical 1 value. The worst case is during a seek command, with multiple track lines active plus the strobe.
The next step was some intelligent placement of the components, knowing how they need to be routed, to minimize crossing paths and conflicts. The pull up and pull down resistors that form the terminator for the input signals were the major factor in congestion, thus they were the major focus of my work.
I also moved the filtering capacitors and the peripheral driver chips to make more room for signal paths on the board. The result was a good clean routing with no manufacturing check conditions. With that complete, I produced the outputs needed for board manufacturing - gerber and excelon format files for the various layers and drill holes.
I will order two boards and enough components to build 4 or more boards- connectors, chips, resistors, and capacitors, which will let me complete the boards once everything gets here.
The foundry I chose, 4pcb.com, has a free service to analyze the files for manufacturability issues. I made use of it and found quite a few niggling errors and one significant one that slipped past the design checks of the DesignSpark PCB software. Time to iterate until I get satisfactory results from the foundry's free check software.
Monday, December 5, 2016
Write sector confirmed to work with new driver board, time to convert it to a PCB
ALTO DISK TOOL
I set up the contents of cyl 0 head 0 sector 7 from the archived disk image, loading it into RAM, and then issued a WriteSector transaction. The sector read back in without checksum errors. I ran the tool to ReadEntireCartridge into RAM and dumped both the RAM and validity check vectors out.
Unfortunately, there is a complication with the Digilent utility that does the upload and download of RAM. It advances the RAM address registers Reg1001, Reg1010 and Reg1011 while it loaded RAM, but does not reset them. Thus, when I thought I had dumped RAM out, I was beginning in RAM at the wrong point, producing garbage. The validity bit vector contents use their own address registers, Reg10001, Reg10010 and Reg10011 so that they worked properly.
I had to fire up the testbed again, ReadEntireCartridge again and then dump this with the RAM address registers at 0. That would allow me to post-process the file and compare the archived disk to the bitsavers image.
I found that the file read from disk was about like the last time and that the sector I had written was retrieved with zero errors, as an exact match. This completes the checkout of the new board, which I can now use in all further activities.
It is time to turn the driver board into a PCB, eliminating any point to point wiring. I will fire up a PCB design tool, draw it out and submit it to a foundry to produce several copies.
Tomorrow it will be time to resume studying the exact conditions under which sectors get a temporary or permanent checksum error - looking for anything that can be mitigated, corrected or anticipated in the pursuit of an even lower error rate.
I set up the contents of cyl 0 head 0 sector 7 from the archived disk image, loading it into RAM, and then issued a WriteSector transaction. The sector read back in without checksum errors. I ran the tool to ReadEntireCartridge into RAM and dumped both the RAM and validity check vectors out.
Unfortunately, there is a complication with the Digilent utility that does the upload and download of RAM. It advances the RAM address registers Reg1001, Reg1010 and Reg1011 while it loaded RAM, but does not reset them. Thus, when I thought I had dumped RAM out, I was beginning in RAM at the wrong point, producing garbage. The validity bit vector contents use their own address registers, Reg10001, Reg10010 and Reg10011 so that they worked properly.
I had to fire up the testbed again, ReadEntireCartridge again and then dump this with the RAM address registers at 0. That would allow me to post-process the file and compare the archived disk to the bitsavers image.
I found that the file read from disk was about like the last time and that the sector I had written was retrieved with zero errors, as an exact match. This completes the checkout of the new board, which I can now use in all further activities.
It is time to turn the driver board into a PCB, eliminating any point to point wiring. I will fire up a PCB design tool, draw it out and submit it to a foundry to produce several copies.
Tomorrow it will be time to resume studying the exact conditions under which sectors get a temporary or permanent checksum error - looking for anything that can be mitigated, corrected or anticipated in the pursuit of an even lower error rate.
New driver board seems to be working properly; built logic to write an entire cartridge in one transaction
ALTO DISK TOOL
Today I switched back to testing the new driver role board, since the logic analyzer connections and setup are mostly intact. The goal is to verify that the unit with the new board still seeks, reads and writes correctly.
I verified that the SelectUnit1 signal works, in that the drive won't turn on FileReady or ReadyToSRW unless I am selecting it, nor will it respond to commands. I also stepped it through the binary powers of cylinder address to verify that each Trackxx signal is correctly wired. I watched the heads move to the commanded values 1, 2, 4 . . . 128
Next up, I did a read of Cylinder 0, Head 0, Sector 0 which completed reporting no detected checksum errors. I also did a ReadEntireCartridge transaction and watched it walk through all the sectors, retrying on those that have problematic signals with intermittent or permanent checksum errors.
All the above looked good and I monitored the WriteGate to be sure we weren't turning this on inadvertently. It is time to capture the cartridge image as a test of the recovered data images, comparing it to the bitsavers archive version and to previous recorded images. If that passes muster, the final test is to write a sector from RAM and verify that it is read back properly; the board will be fully tested.
The captured disk image and checksum information was captured and then compared to the archived versions to see whether we seemed to be more or less reading properly. The results were quite good, similar to what I experienced with the original board.
The final test, therefore, will be to load a specific sector's contents into RAM, write it to the disk, and then read it back to verify that this works. I will undertake this tomorrow.
I did want to create a WriteEntireCartridge function, analogous to the ReadEntireCartridge but that writes an archived pack image downloaded into RAM onto a blank or scratch cartridge. We have various images from archives that it would be great to have on a disk, such as the Smalltalk system.
In most cases, we will just use the disk emulator role and not need a physical cartridge, but there is something satisfying about running the Alto from a real disk. This cartridge writing function will be a tool used only a few times, invoked as transaction code 5. Testing will be difficult, as I need a known blank or sacrificial cartridge.
The logic was completed and synthesized, using the ReadEntireCartridge logic as a template, so that it has decent chances of working correctly on the first try, but can't try it until I have a sacrificial cartridge installed.
Today I switched back to testing the new driver role board, since the logic analyzer connections and setup are mostly intact. The goal is to verify that the unit with the new board still seeks, reads and writes correctly.
I verified that the SelectUnit1 signal works, in that the drive won't turn on FileReady or ReadyToSRW unless I am selecting it, nor will it respond to commands. I also stepped it through the binary powers of cylinder address to verify that each Trackxx signal is correctly wired. I watched the heads move to the commanded values 1, 2, 4 . . . 128
Next up, I did a read of Cylinder 0, Head 0, Sector 0 which completed reporting no detected checksum errors. I also did a ReadEntireCartridge transaction and watched it walk through all the sectors, retrying on those that have problematic signals with intermittent or permanent checksum errors.
All the above looked good and I monitored the WriteGate to be sure we weren't turning this on inadvertently. It is time to capture the cartridge image as a test of the recovered data images, comparing it to the bitsavers archive version and to previous recorded images. If that passes muster, the final test is to write a sector from RAM and verify that it is read back properly; the board will be fully tested.
The captured disk image and checksum information was captured and then compared to the archived versions to see whether we seemed to be more or less reading properly. The results were quite good, similar to what I experienced with the original board.
The final test, therefore, will be to load a specific sector's contents into RAM, write it to the disk, and then read it back to verify that this works. I will undertake this tomorrow.
I did want to create a WriteEntireCartridge function, analogous to the ReadEntireCartridge but that writes an archived pack image downloaded into RAM onto a blank or scratch cartridge. We have various images from archives that it would be great to have on a disk, such as the Smalltalk system.
In most cases, we will just use the disk emulator role and not need a physical cartridge, but there is something satisfying about running the Alto from a real disk. This cartridge writing function will be a tool used only a few times, invoked as transaction code 5. Testing will be difficult, as I need a known blank or sacrificial cartridge.
The logic was completed and synthesized, using the ReadEntireCartridge logic as a template, so that it has decent chances of working correctly on the first try, but can't try it until I have a sacrificial cartridge installed.
Saturday, December 3, 2016
Making progress on emulator role of disk tool
ALTO DISK TOOL
I worked my way through debugging the hangup of the state machines that should be continually 'reading' the contents of the current cylinder and head, making bits available to emit whenever ReadGate is on. I went through several rounds instrumenting the fpga until I found where it was hanging.
Looking at the code, my mistake glared out at me. In one step of the state machine, I wait for the SectorMark to go on, indicating we are at the beginning of a sector to be emitted. It was here I was stalling.
Since this logic supports two roles, a driver of a real disk drive and an emulator that substitutes for a disk drive, it has an incoming and an outgoing version of SectorMark. The emulator version is SectorMarkOut, while the inbound driver version is simply SectorMark. As you may suspect by now, I was waiting on the inbound SectorMark that will never arrive while in emulator mode.
After the usual lengthy run to create a new bitstream, I ran with the state machines hung in a different place, trying to generate the preamble. I needed to reload the serializer for each word, even though the contents didn't change, but I wasn't doing that during the countdowns.
My linkages to the serializer weren't working properly, which held up the state machine that emits ReadClockOut and ReadDataOut signals. Another round of synthesis and I was back to watching the behavior of the emulator.
I am now seeing clock and data pulses emitted, but they don't seem to be in the proper relationship to the SectorMark pulse. Time to work out how to hook up the logic analyzer in order to debug this further.
However, I want to go back to the driver mode, test out the new version of that board I built and make sure the tool is fully ready to read and archive all the cartridges we have on hand, including the personal cartridge of David Boggs which he has loaned us for this purpose.
Getting all the data read and uploaded is a priority of the project, after which we can play around with some packs to install different software images such as Smalltalk.
I worked my way through debugging the hangup of the state machines that should be continually 'reading' the contents of the current cylinder and head, making bits available to emit whenever ReadGate is on. I went through several rounds instrumenting the fpga until I found where it was hanging.
Looking at the code, my mistake glared out at me. In one step of the state machine, I wait for the SectorMark to go on, indicating we are at the beginning of a sector to be emitted. It was here I was stalling.
Since this logic supports two roles, a driver of a real disk drive and an emulator that substitutes for a disk drive, it has an incoming and an outgoing version of SectorMark. The emulator version is SectorMarkOut, while the inbound driver version is simply SectorMark. As you may suspect by now, I was waiting on the inbound SectorMark that will never arrive while in emulator mode.
After the usual lengthy run to create a new bitstream, I ran with the state machines hung in a different place, trying to generate the preamble. I needed to reload the serializer for each word, even though the contents didn't change, but I wasn't doing that during the countdowns.
My linkages to the serializer weren't working properly, which held up the state machine that emits ReadClockOut and ReadDataOut signals. Another round of synthesis and I was back to watching the behavior of the emulator.
I am now seeing clock and data pulses emitted, but they don't seem to be in the proper relationship to the SectorMark pulse. Time to work out how to hook up the logic analyzer in order to debug this further.
However, I want to go back to the driver mode, test out the new version of that board I built and make sure the tool is fully ready to read and archive all the cartridges we have on hand, including the personal cartridge of David Boggs which he has loaned us for this purpose.
Getting all the data read and uploaded is a priority of the project, after which we can play around with some packs to install different software images such as Smalltalk.
Ethernet board working in Alto, optical mouse working as well
XEROX ALTO II RESTORATION SESSION
Today we met to work on the Alto again. We had a guest, David Boggs, who is the co-inventor of Ethernet and the designer of the Alto ethernet controller board, accompanying Ron Crane.
Ethernet efforts
We traced signals and worked on the board. I had brought an Ethernet transceiver, but we don't yet have the cable that connects the transceiver to the controller board. Therefore, we used Ken's testbed for his ethernet bridge, monitoring the packets sent from the system.
By the end of the day, we had good packets, thus only the transceiver and cable needs testing to wrap this up. Of course, we have to test Ken's bridge once it is through development.
Optical mouse efforts
The optical mouse we have came with the wrong connector on the cable, which was incapable to hooking to the Alto. Al Kossow had a broken mouse with the correct cable and connector for the Alto - he donated the PCB and cable from inside.
The broken mouse he had was the Hawley mechanical type, which direct soldered one end of the cable to the PCB, whereas the Lyons optical mouse has a ten pin connector on the mouse end. I unsoldered the cable and Marc soldered the new connector on. When I reassembled the mouse and tested it, it was working properly.
ALTO DISK TOOL
I finally found my working 500K gate fpga board and began to resynthesize my logic so that I could continue testing with that board later today when I returned home. However, events conspired so that I did not get to work on the debugging at all today.
Today we met to work on the Alto again. We had a guest, David Boggs, who is the co-inventor of Ethernet and the designer of the Alto ethernet controller board, accompanying Ron Crane.
Ethernet efforts
We traced signals and worked on the board. I had brought an Ethernet transceiver, but we don't yet have the cable that connects the transceiver to the controller board. Therefore, we used Ken's testbed for his ethernet bridge, monitoring the packets sent from the system.
By the end of the day, we had good packets, thus only the transceiver and cable needs testing to wrap this up. Of course, we have to test Ken's bridge once it is through development.
Optical mouse efforts
The optical mouse we have came with the wrong connector on the cable, which was incapable to hooking to the Alto. Al Kossow had a broken mouse with the correct cable and connector for the Alto - he donated the PCB and cable from inside.
The broken mouse he had was the Hawley mechanical type, which direct soldered one end of the cable to the PCB, whereas the Lyons optical mouse has a ten pin connector on the mouse end. I unsoldered the cable and Marc soldered the new connector on. When I reassembled the mouse and tested it, it was working properly.
ALTO DISK TOOL
I finally found my working 500K gate fpga board and began to resynthesize my logic so that I could continue testing with that board later today when I returned home. However, events conspired so that I did not get to work on the debugging at all today.
Friday, December 2, 2016
Prepping for next Alto restoration session, debugging emulator function of disk tool
ALTO DISK TOOL
I made progress on the emulator role, which is now reliably modeling the rotation of the disk, emitting SectorMark signals and the proper SectorNumber values. However, I am getting nothing from the ReadData and ReadClock lines yet.
I saw a few polarity errors, where I was blocking the outgoing signals on the wrong condition of such states as SelUnit1 and FileReady, which I corrected. I still didn't see the read data emitted, which I traced down to a test bed flaw that was commanding continual seeks. This forces the ReadyToSeekReadWrite line off, blocking the read process.
ALTO II RESTORATION TASKS
I picked up a few items we need for our next stage of work on the Xerox Alto II we restored. One of the mice we have is the optical type, the Lyons mouse, but the cable on it did not match the connector on the Alto. As well, we are early in working on an Ethernet bridge but don't have ethernet working as yet.
Al Kossow had a broken Hawley (mechanical) mouse and donated the PCB with its cable to us. On the Hawley mouse, the cable is directly soldered onto the PCB but uses a ten pin Amp connector to hook the cable to the Lyons mouse.
I desoldered the cable from the PCB, soldered on pins and inserted then into the AMP housing. Hopefully it will work properly when we hook it onto the Lyons mouse tomorrow.
Al also loaned as an Ethernet transceiver, which we did not have, so that it is easier to debug than our attempting to drive the controller card with a BeagleBone developed by Ken. Once we know the board is working and that we can study all the signal timings to make the BeagleBone unit work right.
Tim will bring over another transceiver too, just to be sure we have one that works properly. Both of them are set up to connect to a 75 ohm coaxial cable, the actual ethernet line used with the early 3 Mb LAN. We need a 75 ohm cable of at least a half wavelength and a terminator. Hopefully we will have a cable on hand.
I made progress on the emulator role, which is now reliably modeling the rotation of the disk, emitting SectorMark signals and the proper SectorNumber values. However, I am getting nothing from the ReadData and ReadClock lines yet.
I saw a few polarity errors, where I was blocking the outgoing signals on the wrong condition of such states as SelUnit1 and FileReady, which I corrected. I still didn't see the read data emitted, which I traced down to a test bed flaw that was commanding continual seeks. This forces the ReadyToSeekReadWrite line off, blocking the read process.
ALTO II RESTORATION TASKS
I picked up a few items we need for our next stage of work on the Xerox Alto II we restored. One of the mice we have is the optical type, the Lyons mouse, but the cable on it did not match the connector on the Alto. As well, we are early in working on an Ethernet bridge but don't have ethernet working as yet.
Al Kossow had a broken Hawley (mechanical) mouse and donated the PCB with its cable to us. On the Hawley mouse, the cable is directly soldered onto the PCB but uses a ten pin Amp connector to hook the cable to the Lyons mouse.
I desoldered the cable from the PCB, soldered on pins and inserted then into the AMP housing. Hopefully it will work properly when we hook it onto the Lyons mouse tomorrow.
Al also loaned as an Ethernet transceiver, which we did not have, so that it is easier to debug than our attempting to drive the controller card with a BeagleBone developed by Ken. Once we know the board is working and that we can study all the signal timings to make the BeagleBone unit work right.
Tim will bring over another transceiver too, just to be sure we have one that works properly. Both of them are set up to connect to a 75 ohm coaxial cable, the actual ethernet line used with the early 3 Mb LAN. We need a 75 ohm cable of at least a half wavelength and a terminator. Hopefully we will have a cable on hand.
Thursday, December 1, 2016
Switched over the 1200K fpga board as the other board was unusable
ALTO DISK TOOL
While waiting to find/buy a new USB cable with a better fit to the fpga board, I can't run the disk drive when the fpga is randomly resetting or emitting incorrect signals. I will switch over to debugging of my emulator role in the interim.
Unfortunately, the situation with the connection and the fpga board is bad enough that I couldn't get the board to respond even in emulator mode. I se up a few diagnostic signals and synthesized so that I could look again when I returned from my day with the 1401 restoration team at CHM.
I found another cable and had the same very erratic behavior with the board. Since I have another fpga board, I used that instead but it is the 1200K gate version, not the 500K gate variant. Something is wrong with the USB link on the 500K board.
I had to resynthesize for the 1200K configuration before I could test the new board. This also required some config changes to the UCF file because the 1200K version of the board hooks four of the LEDs to different FPGA signals than with the 500K board.
I began testing the emulator function, slowly working through the logic to get it working. Glad to be moving forward again. I also have a reliable board now which will let me hook up the new driver board and test it out.
While waiting to find/buy a new USB cable with a better fit to the fpga board, I can't run the disk drive when the fpga is randomly resetting or emitting incorrect signals. I will switch over to debugging of my emulator role in the interim.
Unfortunately, the situation with the connection and the fpga board is bad enough that I couldn't get the board to respond even in emulator mode. I se up a few diagnostic signals and synthesized so that I could look again when I returned from my day with the 1401 restoration team at CHM.
I found another cable and had the same very erratic behavior with the board. Since I have another fpga board, I used that instead but it is the 1200K gate version, not the 500K gate variant. Something is wrong with the USB link on the 500K board.
I had to resynthesize for the 1200K configuration before I could test the new board. This also required some config changes to the UCF file because the 1200K version of the board hooks four of the LEDs to different FPGA signals than with the 500K board.
I began testing the emulator function, slowly working through the logic to get it working. Glad to be moving forward again. I also have a reliable board now which will let me hook up the new driver board and test it out.
Subscribe to:
Posts (Atom)