Short hiatus attending to other tasks

DISTRACTIONS AND OUTSIDE PROJECTS

I have been completely tied up with several non-computer projects. I had my driveway and walkway replaced with pavers, a flagstone patio added and stone veneers added across the bottom 2' of the front of my home. In addition, I am building the 16' Pirate Ship bar and other props for a fundraiser in October. 

Display repaired for Digibarn Alto, first test of disk emulator tool

DIABLO EMULATOR VERSION OF ALTO DISK TOOL

I hooked the emulator up to the Alto but it did not boot from the virtual disk. We did this very late in the test session, when there was not enough time to start scoping signals. Therefore I have no idea what may be going wrong - whether it is electrical, a chip malfunction on my daughter card, a logic flaw in the FPGA or something else.

I have to wait for the next session, which Marc may not be able to schedule for a few weeks as he attends to other projects. Since our Alto is in his basement, no work can proceed except when he can host us.

RESTORATION WORK ON DIGIBARN ALTO

At our last session, we found that the Display for the Alto owned by Bruce Damer/Digibarn was displaying black but seemed to have scan and an image in the instant when it is powered down. My suspicion was that one or more of the three grids had a potential that was blocking the electron stream, but as various capacitors discharged during power-down the stream could temporarily make it through.

The three grids have potentials of up to 1000V so we proceeded carefully in our testing! I have an old vacuum tube voltmeter with a probe good to 30,000V (implements a large voltage divider and has an impressive plastic shield to keep hands away from high tension). It showed zero volts on all three grids.

Studying the schematic gave us a few places to probe between the flyback transformer winding that delivers 600V as short pulses during each horizontal retrace and the other circuitry, some that doubles up to about 1000V and others that generate -100. We found that a small incandescent bulb on the PCB was the fault!

The design routes the short retrace pulses of 600V through this bulb, a 28V 40ma mini lamp, depending on the shift in resistance of the filament from cold to warm to provide a kind of current regulation. The bulb had a lead cracked off where it entered the glass envelope.

Marc was able to reattach a lead to it, using his binocular microscope, a soldering iron and lots of patience. With it installed the monitor worked beautifully.

We then installed the four power supplies into the Alto and began inserting cards into the backplane. Unfortunately, the machine lacked one card, the memory address terminator board, and needs several cables that run between various boards. We didn't have time to proceed any further on this machine.

Small mod to the disk emulator board and work on the pirate ship bar

DIABLO EMULATOR VERSION OF ALTO DISK TOOL

Well, I discovered that the emulator board I built has a defect. It does NOT ground pin 21 of the FPGA connector, which it should to indicate to the logic that this is the emulator daughter board. I will add a short wire to fix the board.

Jumper added to ground pin 21, identifying this as an emulator board

I went through the logic and removed all the instrumentation/test related code from the VHDL - the buttons to trigger updates or writes from the test generator and the use of the sense switches to set seek addresses. A bit of other cleanup as well and it was ready to produce the version I will use for testing tomorrow on the Alto.

FUNDRAISER PROP - PIRATE SHIP BAR

I worked a bit on my gimmicks for the prop. I plan to have a lifesize photo of Johnny Depp's head as Cap Jack Sparrow pop up from behind the ship facade and bob back out of sight. I have the actuator and just received my 'head'.

Cardboard head to pop up (actually a flat mask

The cannons will flash with a 1200 lumen high intensity LED, which I tested at almost full power using my current limiting bench power supply. It is plenty bright even for daylight, mounted inside the cannon, and should be spectacular at night time when most of the fundraiser occurs.

My high intensity LED operating at about 70% of full power

I also received the fog generating fluid to put in the fog machine, which I fired up as a quick test of the volume and quality of the fog produced. It seems okay, but I am still figuring out the machine, whose output was a bit erratic. I will do more testing once the ship is built.

Cable and board completed for Diablo emulator disk tool for Alto

DIABLO EMULATOR VERSION OF ALTO DISK TOOL

I have to finish the cable that will hook between the Xerox Alto and my emulator, verify all the wiring and function on the emulator daughter card, then I will be ready to haul this over and use it with our Alto.

Cable that attaches to Alto disk controller card

Other cable end, after ground plane peeled off, before connector attached

The IDC header connector, two rows of 20 pins, will clamp onto the cable end and plugs into my daughter card. That card converts the +5V input signals from the Alto controller to the 3.3V levels used with the Digilent Nexys2 FPGA board. It also takes 3.3V outputs from the FPGA board and drives relatively high current at TTL levels to the controller card. Finally, it implements the end of cable termination with resistor pairs that match the Diablo drive terminator plugs.

Daughter card to do level translations and terminate the cable

I verified that the pins on my board match the cable signal lines 1 - 40 and the connector at the far end. This means that once I have the IDC connector installed and my board is electrically traced for its validation, I should be ready to cable up to an Alto.

By dinnertime, the connector was installed on the cable and checked out. All that remained was to trace each signal line between the IDC connector and support chips, then each line between the FPGA input connector and the chips.

Cable attached to emulator daughter card

The IDC to chip links were all proven good by 8PM, when I turned to checking the FPGA connector to chip lines. By bedtime I completed that task too. I believe this is ready to test on a real Alto, probably this Friday.

Diablo disk emulator testing completed, plus pirate ship design and fabrication begins

DIABLO EMULATOR VERSION OF ALTO DISK TOOL

My explorations this morning proved that the test generator is outputting the correct stream of bits. I then moved on to the logic that produces the WriteDataClock signal, to determine what stream comes out of it and compare to the test stream. Each such step requires re-synthesis thus incurs a 20-30 minute delay.

The WriteDataClock signal looks wonky, although the testgenerator values seem right. I made some tweaks to the logic that converts the testgenerator bits into the NRZI encoded signal and synthesized once again. I could then see that the WriteDataClock signal is correct but the recovered bittrain is wrong.

Onward I moved to instrument the logic that entrains on the clock pulses of the WriteDataClock signal and extracts data values from the spaces in between. After a suitable pause to synthesize I was ready to run the next experiment.

I can see the logic incorrectly detecting data bit values, but it will take a careful listing of the timing of all the signals and state machines before I can determine the flaw and repair it. The key is in the two state machines - one entraining and tracking clock pulse, the other detecting data pulses. One of these, or their interaction, is misbehaving.

I found it! A window vulnerability that would extend the time in the data extraction FSM in certain circumstances to cause it to misregister spurious 1 data values. With that repaired, the logic handled the updates perfectly, both to alter just the data record and to alter both label and data record. I think the checksum testing worked properly as well, but to be certain, I prepared some signals to watch with the logic analyzer.

Also, I tweaked the testgenerator to put in some different values, particularly for the header record, so that I could do a test where the entire sector is written. The synthesis took a while, but I was pretty confident in the outcome.

The results were perfect. My update logic works fine for any time the WriteGate logic is turned on somewhere in the space between the records (or in the preamble for the first - header - record). As far as I can tell without hooking this to an Alto, it seems ready to provide an emulated disk drive.

FUNDRAISER PIRATE SHIP DEVELOPMENT

My wife and I are building props for a fundraising event at Villa Siena; this year's theme is Pirates & the Caribbean. The bar will be a 16' long pirate ship, 4-8' high not counting the mast/sail. It will be a facade, not three dimensional, but I will have several 'cannons' protruding from the side.

Inside the cannons will be bright LEDs to simulate cannon fire, along with a continuous performance of the song from the disney theme ride. Too, I will have a pirate head peeking above the deck and smoke from the cannons and down low as 'water'.

I have most of the gear on hand and began working out my wiring design. I will use a constant current power supply set to .7A to deliver the voltage to each LED. These will be wired through a bank of relays, one per cannon, that I can activate with an Arduino program. The program will also produce the cannon fire sound, independent of the song playing through another small MP3 device.

There are a host of other props, including pier pylons with ropes, palm trees, treasure chests and barnacles. We also found a life sized skeleton that we can sit on a bench and dress with a bandanna, eyepatch and pirate hat. Atop its shoulder is a correctly proportioned parrot skeleton that will also be clad in hat, bandanna and patch.

Before hats, eyepatches and bandannas

Debugging the update/write logic for the Diablo disk emulator for the Alto

DISK EMULATOR VERSION OF ALTO DISK TOOL

I found and cleaned up a couple of places where the various FSMs could be stepping on each other for memory access. With that repaired, I retested. The flaw uploading memory to the file was fixed. I also verified that when I pushed the buttons, I would "rewrite" the label+data or just data records.

Unfortunately, I didn't get the data bit values I expected from the updates. Further, the logic reported checksum validation issues, which totally makes sense. It left the header records alone and when I used the button to update only the data records, the label records were also untouched.

I have to work out the best diagnostic traces to emit, to pick up a hint with the logic analyzer as to why I am not correctly detecting the words I expect. The data patterns don't look like the result of an error in the deserializer that shifts the bits around. The patterns are consistent across runs.

For example, the last word of the data record should be x5462, the output of the test generator, but I see xE440 instead. I need to watch the entrainment and sync process, then the deserialization, to found out whether I am picking out the bits properly.

The logic analyzer was wired, configured and the board set up for testing. Right away, I saw the deserializer tossing out words (that matched what was written into memory), but having no relationship to what I was emitting out of the test generator.

I made some tweaks to look at other signals and gave the logic a quick lookover. I can see that the deserializer is telling my UpdateRecord machine that it has accumulated a word after achieving sync. The word it presents is the same value xE440 that I see in memory.

This points me at the deserializer operation as the malfunctioning process. I did a dig through the logic analyzer traces to see whether I could spot the problem. It jumped out at me, particularly when I set up the scope to trigger on my update of the data record and display the WriteDataClock signal I was producing.

My test generator is not producing good output. Specifically, it is generating the sync bit followed by xE440 which is exactly what my deserializer picks up. The fault is in the test generator. Now I can focus on that logic and do some simulations to find the bug.

Test generator installed in disk emulator version of disk tool, starting to debug

DISK EMULATOR VERSION OF ALTO DISK TOOL

I updated my built-in test generator, which had been built to create input for the ReadClock and ReadData lines while I was testing the disk driver version. It now produces input for the WriteDataClock line.

I also added logic that will turn on the WriteGate signal for a portion of each sector when I push either of two buttons on the fpga board. One button will begin writing only for the data record, while the other will write during both the label and data records.

I wired these generated signals to the inputs they will drive and began some testing. I first loaded the board with the XMSMALL disk image, ran without any updates and verified that the image in memory remained untouched. Second, I would triggered an update of the data records of sectors, uploaded the memory image and checked to see if I had altered just the intended words.

The file upload from the memory is not working properly. I can see the ReadClock and ReadData produced by the disk drive, which match the image I downloaded, but when I upload I get zeroes. I can see the WriteGate condition flick on when I push the buttons, but without a way to pull the memory up to a file, I can't determine whether it worked properly.

I did make changes to the logic involved in memory access in order to add in the sector updating/writing logic, so that is the first place to look. I might need to organize some diagnostic output that can be captured on the logic analyzer if I don't see anything obvious.