Return to index

Disc Dialogs

drifting into memory refresh

A partial index there is more, pretty much in time sequence, top is most recent

Bit Timing of Alto vs Diablo 31 disc drive
Modifying Diablo 31 drive to handle Alto out of spec disk timing
from Carl Claunch - Oct 21, 2016
The Diablo 31 I am testing with is a stock Diablo, while the Xerox systems folk would modify any Diablo used on an Alto to accommodate the faster data rate than the factory specification or design.

It reduces the duration of two timers, used to detect a data bit, one used when the prior bit was a zero and the other used when the prior bit was a one. This adjusts for a magnetic phenomenon that affects all NRZ systems called bit shift.

The Diablo was designed to operate with clock pulses separated by 660 ns, interleaving another pulse if the data bit for that cell is one. The Alto squeezes the clock down to 600 ns.

The testing I have been doing with the XMSMALL cartridge loaned to me by Al exhibits checksum errors on slightly more than 6% of all sectors. We think this may be due to the lack of the timing modification.

After I pick up resistors to retime the Diablo, I will retest and we shall see how much this matters.

Carl

--------------------------
From: Josh Dersch
Date: Sat, Jul 09, 2016 8:13 pm
Once I got to the point with my emulator where I had the display and cursor mostly working, I was seeing the same behavior as with Salto -- a jumpy, unstable cursor.

This is from memory, but I believe the solution (or at least part of it) was given away by a comment in the microcode:

;
; This version assumes MRTACT is cleared by BLOCK, not MAR<- R37
MRTACT is the wakeup signal for the Memory Refresh Task.
In previous hardware and uCode revisions, the MRT was put back to sleep by an instruction containing MAR><-R37; in the last revision a BLOCK did the trick. Since the MRT deals with loading the cursor at the appropriate scanline, this ended up affecting positioning, randomly based on how busy other tasks were (due to the wakeup behavior). I'd make sure that Salto is doing that appropriately.

(Note that when I added Alto I support, I had to change the behavior back to MAR><-R37.)

I've no idea if that's the problem Salto/MAME has, but it's what I ended up having to fix.

- Josh

---------------
From: Josh Dersch < JoshD@LivingComputerMuseum.org >
Date: Sat, Jul 09, 2016 8:06 pm
I'll add that I have created a version of the Alto II XM microcode sources (the ones on bitsavers) with the uCode addresses annotated in; using this you can easily determine what the Alto's actually executing and what task's running at any given time. (This assumes you have the same uCode revision, which is fairly likely. You should verify the uCode PROMs at some point anyway...) I can share this with anyone who's interested.

The emulator (which I sent to Ken) uses this annotated listing to allow single-stepping through the uCode while tracing through the source listing. This may also be useful for confirming the real machine's behavior.

- Josh

----------------------------
From: Al Kossow
Date: Sat, Jul 09, 2016 8:03 pm
On 7/9/16, 7:52 PM, "Josh Dersch" wrote:
>
>I believe the Cursor task will run as well, once per horizontal retrace
>(but I'll have to check my notes, which are at work.). This is the
>shortest task, being two instructions long.
What is the interaction between the cursor and memory refresh task that you ran into in the simulator? I guess I¹ll have to look at that in either Salto or MAME to try to fix it since I don¹t seem to be able to get anyone else interested.

----------------------------
From: Josh Dersch < JoshD@LivingComputerMuseum.org >
Date: Sat, Jul 09, 2016 7:52 pm
Actually, quite a few tasks will be running:

At reset, the Emulator task will start off setting up a Disk Control Block for the boot block (or alternately setting up the Ethernet interface to netboot, if the BS key is held down at reset), after which it will start executing Nova instructions at address 1 (which, until the boot block is loaded contains a JMP 1 instruction, handily enough). Once the boot block is read in, address 1 will contain real code and off we go...

The Disk Sector task will run once every time a new sector comes around on the disk (I'm unsure whether this is true if a disk is not actually loaded. I do know that the Disk Sector task runs at least once at reset, regardless. The Disk Word task will not run until a pack is loaded, the initial Disk Control Block is set up by the Emulator task, and the appropriate sector comes around on the disk.

The Display Vertical, Display Horizontal, and Display Word tasks will run, though they won't have much to do since nothing is set up for them to display yet, just a white raster.

The Memory Refresh task will kick in once per horizontal retrace.

I believe the Cursor task will run as well, once per horizontal retrace (but I'll have to check my notes, which are at work.). This is the shortest task, being two instructions long.

- Josh


From: Al Kossow
Date: Sat, Jul 09, 2016 7:28 pm
Everything looks reasonable. Josh mentioned the disk block being written backwards. When you get to the point of needing one, I have lots of spare alto disk cables that you can cannibalize for the Winchester connector.

The microcode ends up looking that way because of branches being implemented as wire-ors which are fixed up by the microcode assembler, so the code flow gets scattered.

Josh, I assume that the main thing they’ll see if they put a logic analyzer on the micro address before booting is it idling in task 0 with the occasional memory refresh task? (that is, if it gets through all the initialization..)

-----------------------------------
From: Ken Shirriff
Date: Sat, Jul 09, 2016 6:58 pm
I believe a single 1 is enough to sync up the preamble.

The HWRef doc describes the command:
WFFO = 0 holds the disk bit counter at -1 until a 1-bit is read.
This matches the schematic, where the WDDONE (word done) counter is forced to -1 until a flip flop is cleared by HIORDBIT, which means a 1 bit from the disk gets shifted all the way through the 16-bit shift register and out the other side.

I think what that means is when the sync 1 gets shifted all the way through and triggers the word done counter, the next word will be loaded into the shift register all ready to go.

There are 34 words of 0 preamble written, while reads wait for 21 words of preamble before looking for a sync bit. Any 1 bit after that interval will sync the read.

Let me know if you want more details (where this happens in the schematic, microcode, etc).

Ken

--------------------------------------
Carl Claunch
On Sat, Jul 9, 2016 at 3:45 PM,
Hi Ken

Excellent! To borrow a compliment from another discipline - You, sir, are a steely eyed missile man!

This is essentially the complete set of specifications needed for building the emulator and driver functions. In addition to the format of a sector, which tells how many words of preamble to write, the constants tell me how long to wait before attempting to read.

One item that isn't clear from your writeup concerns the minimum number of preamble words (0s) that must be seen before the synchronization word (1) is recognized. For example, after the sector pulse is detected, the microcode waits 21 word times before it starts reading, while the preamble is ideally 34 words total from when the sector was last written. However, variations occur which is why we look for the preamble plus sync pattern. If the task waited 21 word times then immediately say a 1 word (sync), is that success or a disk error? If it sees just one preamble 0 plus sync is it good? For most disk controllers, there is a minimum string of preambles that must be seen before it triggers on the sync word.

Carl


--------------------------------
preamble
sector detail from reading the microcode -
from Ken - Sat, Jul 09, 2016 2:55 pm
I've been studying the disk microcode (word task), and I've figured out most of what's going on. The microcode is pretty hairy, but fortunately my brain hasn't exploded yet. This email probably has more detail than most of you care about, so feel free to ignore it :-)

Each sector has a 2 word header, a 8 word label, and 256 words of data, stored as three independent blocks in the sector.

The exact format of a sector is:
34 words preamble (length defined as the constant MFR0BL)
1 word synchronization (the value 1, i.e. 0000...0001)
2 words record 0 (header)
1 word checksum
5 words postamble (0s, length defined as MWPAL)

3 words preamble (0s, MIR0BL)
1 word synchronization
8 words record 1 (label)
1 word checksum
5 words postamble

3 words preamble
1 word synchronization
256 words data
1 word checksum
5 words postamble
The checksum is the disk address XOR (all the data words XORed together).

A word is written starting with bit 0 (which confusingly is the highest-order bit on the Alto).

Data buffers are apparently written backwards, i.e. starting with the last word in the buffer and ending with the first word.

Notes on the microcode:
The microcode is tricky to understand. It's basically spaghetti code where each instruction branches to another instruction, often a conditional branch based on a condition one instruction earlier. The comments explain where the branches go, if you understand what is happening. Basically, various microcode addresses are set up carefully, and then the disk interface card sets various low-order address bits on request to cause branches based on the disk state.

Since registers are scarce, registers are often used for two unrelated things, without changing the symbolic name.
E.g. CKSUMR stores the checksum as it is computed. But it also stores the length of the inter record gap. So it gets very confusing if you don't realize the change in meaning.

In order to understand how the microcode works, you need to piece together information from multiple documents, which I will list here (mainly in case I need to find them in the future).

The microcode itself is here - search for DISK WORD TASK.
This file also defines register names, e.g. $CKSUMR $R32;
It also defines operations implemented by the interface hardware, e.g. $RWC $L024011,000000,000000

To understand the microcode, you'll also need the constants file, which defines things such as the preamble lengths:

$MFRRDL		$177757;	DISK HEADER READ DELAY IS 21 WORDS
$MFR0BL		$177744;	DISK HEADER PREAMBLE IS 34 WORDS
$MIRRDL		$177774;	DISK INTERRECORD READ DELAY IS 4 WORDS
$MIR0BL		$177775;	DISK INTERRECORD PREAMBLE IS 3 WORDS
$MRPAL		$177775;	DISK READ POSTAMBLE LENGTH IS 3 WORDS
$MWPAL		$177773;	DISK WRITE POSTAMBLE LENGTH IS 5 WORDS
To understand the microcode architecture, see the hardware reference section 2.

The microcode syntax is explained in the assembler manual here, page 82.

The Alto disk system is explained in detail in the hardware reference section 6. This explains the word and sector tasks, as well as the hardware functions performed by the disk interface board.

Finally, the disk interface schematic is here.

A few hardware things of interest with the disk interface, relevant to making a disk emulator:

Looking at the Diablo connector, pins H, M, P, S, V, Y, HH, and UU are unused by the Alto interface (these are things like write protect and the index mark).
The outputs from the interface card to the Diablo disk all go through 7437 chips (TTL high-current NAND buffers) to drive the lines.
The inputs to the interface card go into normal TTL chips without any termination, except 330 ohm pullups on U (file ready) and W (sector mark).
All the connections to the Diablo are also available on the backplane. This will make debugging easier, since the signals are easy to access.
The Diablo signals are complemented (active low).

I don't guarantee any of the above information, so check before you do anything critical based on it :-)

Ken


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 11:57 am

Getting the alto packs archived would be a good thing, especially the Notetaker disks, since the folks working on MAME have a simulation but no software other than the boot proms I read from the machine CHM has.


--------------------------------
From: < Tim.Curley@parc.com >
Date: Wed, Jul 06, 2016 11:04 am

Ken,

I just located these items with the help of facilities (three cabinets full of platters, one cabinet has two boxes of boards). We're gathering up some extra taps just in case we want to network two Alto machines together sometime in the future. { see docs/CurleyTim2016-07-06PARC-AltoInventory.pdf }

PARC has only two Alto computers on premise (display units). All the rest of the heavy iron parts went to the Xerox archives on the East Coast. I'll reach out to them to let them know we've got a restoration project that may require spare parts/pieces.

Talk soon,

Tim


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 9:58 am
Just checked and they used 7437’s which are totem-pole output.


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 9:51 am
I’ve attached the disk section from one of my binders that probably isn’t on bitsavers with the mods. The Alto also uses a modified disk terminator with most of the resistors removed (I guess they didn’t use OC drivers). Most of the signals going to the drive are only read when you’re moving to a new cylinder, so if you’re really tight on I/Os you could send them out serially into something like a 74HCT595.

{see docs/Kossow2016-07-06-disk.pdf }

re:


From: Ken Shirriff
Date: Wednesday, July 6, 2016 at 8:47 AM
Probably the easiest way to figure out the open issues would be to attach an oscilloscope to the drive and take a look at what's coming off the disk.


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 9:25 am
I want to suggest AGAIN that you don’t plunge in ignorantly trying to get the system to come up off of the disk. Wait until you can get the ethernet stuff from LCM and bring up net bootable diagnostics. This is from decades of experience bringing up them without a known working set of boards. Keeping a disk bootable when the machine isn’t stable is not going to happen, and making new images of packs isn’t anything anyone down here can do right now, since I haven’t had time to get my machine running again. If you scrog your pack right now, I’m NOT going to give you one of mine until I can clone them again.

re:


From: Ken Shirriff
Date: Wednesday, July 6, 2016 at 8:47 AM

Probably the easiest way to figure out the open issues would be to attach an oscilloscope to the drive and take a look at what's coming off the disk.


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 9:17 am
The format is almost identical to the DEC RK05 and the bit order is the same.

I remember being surprised that I got somewhat recognizable sector data off of a DEC-formatted pack that I tried reading with tdisk, the main difference being the tag bytes on the front of an Alto sector.

The only difference between a stock 200tpi Diablo drive and the ones used in the alto is different write delay, which is documented somewhere in the service binders I have.

re:


From: Ken Shirriff
Date: Wednesday, July 6, 2016 at 8:47 AM

Probably the easiest way to figure out the open issues would be to attach an oscilloscope to the drive and take a look at what's coming off the disk.


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 8:51 am
Use a BeagleBone


--------------------------------
From: Ken Shirriff >
Date: Wednesday, July 6, 2016 at 8:47 AM
So, I think a disk emulator is doable, but not as trivial as wiring up some control lines to an Arduino


--------------------------------
From: Al Kossow
Date: Wed, Jul 06, 2016 8:49 am
http://bitsavers.org/pdf/xerox/alto/microcode

; THE DISK CONTROLLER

; ITS REGISTERS:
$DCBR $R34;
$KNMAR $R33;
$CKSUMR $R32;
$KWDCT $R31;
$KNMARW $R33;
$CKSUMRW $R32;
$KWDCTW $R31;

I would suggest making a list of what is already scanned on bitsavers before blindly stumbing through PARC’s archive.


--------------------------------
From: Carl Claunch
Date: Wednesday, July 6, 2016 at 7:01 AM

Al - are the microcode source listings included or is it just code for the emulated pseudo-Nova and the stack above?


--------------------------------
From: Ken Shirriff
Date: Wed, Jul 06, 2016 8:47 am
Probably the easiest way to figure out the open issues would be to attach an oscilloscope to the drive and take a look at what's coming off the disk.

The microcode is here. Task 4 (KSEC) is the disk sector task (page 37 of microcode) and task 16 (KWD) is the disk word task (page 40 of microcode). I only partially understand the microcode. It looks like the checksum is an XOR, not a CRC (but I don't guarantee this).

I've been studying the disk drive circuitry, and I mostly understand how the drive works. One interesting feature is the circuit that to change tracks. It computes the difference between the desired track and the current track, and counts tracks to get there. The servo has 4 speeds, so it starts the seek off fast, and then slows down as it gets closer. (This isn't particularly relevant to anything we're doing, but I wasn't expecting this degree of complexity.)

Another interesting but mostly irrelevant circuit is the motor speed control. It starts the motor at high speed (to run the fan fast and purge the disk). After 1024 index marks (i.e. the double sector slots), the motor goes to regular speed and the the disk slows down to running speed. To keep the rotation speed constant, the drive has a 50kHz clock, and counts how many clocks between index marks. If there are more than 2000 counts, the disk is too slow and it kicks the motor up to high speed again until the count gets back below 2000. (The motor only has two speeds but apparently inertia keeps the rotational speed from fluctuating too much from one rotation to the next.)

The drive circuits use 730-series DTL logic, which predates TTL. Hopefully we don't have any bad chips, because it will be hard to find replacements.

Building a disk drive emulator is something I've been thinking about. First, for reliability issues, especially if the Alto is going to be running for long periods of time. Second, because the ability to run multiple disk images without having the physical disk would be convenient. (There are various Alto disk images online.)

A few things complicate the potential disk emulator: The disk has about 40 control lines, which is more I/O than a basic Arduino has. The lines have DTL voltages and need termination, which makes them a bit inconvenient for interfacing to a microcontroller, probably requiring 80 resistors. The read/write bit streams are at 3 megabits per second (1.5 megabit clock interleaved with 1.5 megabit data), so it will require at least a moderately powerful microcontroller Will probably need an SD card to hold the disk image. Or else communicate with a host computer (laptop? Raspberry pi?) via USB or WiFi to get the disk blocks.

So, I think a disk emulator is doable, but not as trivial as wiring up some control lines to an Arduino (which is what I hoped would work). It's unclear to me what microcontroller would be best.

Ken


--------------------------------
From: < Tim.Curley@parc.com >
Date: Wed, Jul 06, 2016 7:08 am
Ken will be dropping by PARC today to help me dig through the archives – we’ll see what we can come up with.

Tim


--------------------------------
From: Carl Claunch
Date: Wed, Jul 06, 2016 7:01 am
I researched other sources of information and came across a document written by Thacker, McCreight, Lampson and others in 1979 that allowed me to resolve a number of the open questions I had listed as needed in order to create an emulator for the Alto. Here are the details already resolved:
  • Length and pattern of the preamble (usually zeroes but how long a burst of zeroes) - pattern is stream of 0s,
  • Pattern of the sync pattern at the end of the preamble - single 1 bit
  • Word order (is word 1 of the header sent then word 2, or do we start at word N and work back to 1) - backwards order
  • Does each field have its own CRC or is there one CRC at the end - CRC on each field
The open issues are:
  • Time delay from Sector pulse until we start writing or reading the preamble
  • Length of the preamble (usually zeroes but how long a burst of zeroes)
  • Number of preamble bits that must be read before the sync pattern to successfully sync
  • Serialization order (sent from LSB or MSB)
  • What is the gap timing after the end of each field (and its CRC if it has one) and the preamble for the next field
  • What is the scope that the CRC checksum covers? Does it start with the sync pattern or first data bit, all fields or just one, . . .
  • What CRC algorithm is used
  • Is the CRC written LSB first or MSB first
The answers to many of the remaining are in the code for the word task in the Alto, which establishes the timing of the preambles/gaps and does the checksum control. CHM has arranged with PARC to share the source code of the Alto online, which hopefully contains the microcode listing for the word task. Al - are the microcode source listings included or is it just code for the emulated pseudo-Nova and the stack above?

Carl


--------------------------------
From: Carl Claunch
Date: Tue, Jul 05, 2016 4:43 pm
If there is an existing disk emulator, that would be the priority approach. All I was aware existed is the Alto emulator(s), not an emulator for a disk drive that could be hooked to the controller cable. Good news.

Carl


--------------------------------
From: Sam Altman
Date: Tue, Jul 05, 2016 4:39 pm
Well, that would certainly be an amazing achievement!

I'll get the existing emulator if possible as a backup.

re:

On Tue, Jul 5, 2016 at 10:08 AM, Carl Claunch wrote:

I have had good results with disk drives and cartridges from this era - Diablo, IBM, Pertec and others - being able to restore the drive and successfully read decades old media in most cases.


--------------------------------
From: Carl Claunch erred Sender)
Date: Tue, Jul 05, 2016 3:51 pm
Here are the details to be resolved in order to hook an emulator on the Diablo cable to the disk controller card and read/write data as the Alto expects:
  • Time delay from Sector pulse until we start writing or reading the preamble
  • Length and pattern of the preamble (usually zeroes but how long a burst of zeroes)
  • Pattern of the sync pattern at the end of the preamble
  • Number of preamble bits that must be read before the sync pattern to successfully sync
  • Serialization order (sent from LSB or MSB)
  • Word order (is word 1 of the header sent then word 2, or do we start at word N and work back to 1)
  • Does each field have its own CRC or is there one CRC at the end
  • What is the gap timing after the end of each field (and its CRC if it has one) and the preamble for the next field
  • What is the scope that the CRC checksum covers? Does it start with the sync pattern or first data bit, all fields or just one, . . .
  • What CRC algorithm is used
  • Is the CRC written LSB first or MSB first
Our Diablo manuals only describe generic examples, they don't define this specifically for the Alto implementation.

The Alto manuals tell us there are three fields in a sector, 2 word header, 8 word label and 256 word data. It also tells us that writing can begin at any of the three fields, switching from reading the prior fields. This would force the layout to include a gap between fields to allow time for the erase and write heads to energize between the field being read and the subsequent fields that are written.

We know that part of the disk controller function is software - embodied in the sector task and the word task - thus we can't just read the schematics of the controller card to resolve everything. If we can examine the microcode for those two tasks, along with the controller card hardware, more of the questions could be resolved. The word task implements the delays, sync pattern and similar details. It also appears that the data words are stored from high address to low address as the word count is decremented, which implies that words are pushed on disk in reverse order (the last word of a field is written first).

The discussion in the HW manual, section 6 does not make clear whether there is a discrete CRC for each field or only at the end of the data field. Further, it doesn't define what data is summed.

Carl


--------------------------------
From: "Marc Verdiell"
Date: Tue, Jul 05, 2016 1:43 pm
I think Alan probably means that discs are prone to crashing, but that’s because people don’t clean them properly like we do. In my experience, the data on magnetic media holds up very well, even on fragile tape, and discs should be much better. This platter was pristine. We don’t know what’s on it though! The major advantage of an emulated disc is that you can load it with any image file you want. Great way to transfer data to a non-internet connected machine. Would be nice to use our Trident interface for an emulated disc, then we could copy data on Diablo platters to create the disc images we need. Anyone knows of a Tricon/Trident emulator?

Marc


--------------------------------
From: Carl Claunch
Date: Tue, Jul 05, 2016 10:08 am
I have had good results with disk drives and cartridges from this era - Diablo, IBM, Pertec and others - being able to restore the drive and successfully read decades old media in most cases.

Emulation is certainly a possibility, although we would need to do some research to garner sufficient detail on the serial stream that would be delivered to the disk controller card.

The existing documentation is not sufficiently detailed, but we should be able to capture enough from a few sectors of an existing cartridge, by monitoring the Read Data and Read Clock lines from the interface, to recreate the needed specs.

Alternatively, if we have the microcode listings for the sector task, word task and the controller schematics we can probably reverse engineer the specs.

If an existing emulator is available that hooks to the Diablo interface and produces Alto compatible data streams, that would save some development time but it is certainly feasible even if built from scratch.

Carl


--------------------------------------------------------------------

Sam Altman wrote: On Tue, Jul 5, 2016 at 8:34 AM
FWIW, Alan Kay once said that the disks almost always fail. He recommended we try to emulate the disk rather than repair it, but that may be too pessimistic...

I'm sure he'd be happy to talk to any of you about if you'd like.


--------------------------------
From: "Marc Verdiell"
Date: Mon, Jul 04, 2016 1:20 am To: "'Ken Shirriff'"
I'm looking into what signals we can check from the backplane. We can see what microcode tasks are running which will show if anything is happening. I'd also like to see if the disk is sending any data. I'm going through the schematics and documentation to see how we can trace the reset and what happens after that.

That is great. If you can identify the signals we can check with a 4 channel scope for signs of health. Actually I have 3 fast scopes so we could have more channels in a pinch. Nothing can replace the Logic Analyzer to eventually chase failing logic (I have one with 136 channels + 32 bit pattern generator), but setup times are measured in hours and days.

Picture of the display board with big red switch attached.

Marc


--------------------------------
From: Ken Shirriff
Date: Sun, Jul 03, 2016 11:14 pm
I'm looking into what signals we can check from the backplane. We can see what microcode tasks are running which will show if anything is happening. I'd also like to see if the disk is sending any data. I'm going through the schematics and documentation to see how we can trace the reset and what happens after that.

Marc, would you have time to take a photo of the display board before you go to Japan? I discovered I don't have a photo of it, and it's the board that generates the clock. It's in slot 13. I think it has a clock internal/external switch, so I'd like to see what position the switch is in.


--------------------------------
From: Marc Verdiell
Date: Sun, Jul 03, 2016 10:57 pm
Let's just say the crt was brighter. Still not great. We are now going to badly need an extender board to hook up the logic analyzer to debug the boars in the CPU. My inclination would be to start monitoring simple things: program counter, address access... It could also be that the computer is not jumpered properly to load from this disc, that the disc is not bootable, that the microcode PROMs have issues, that the keyboard is not recognized properly, that the video signal is not generated, etc...

Marc


--------------------------------
From: Ken Shirriff
Date: Sun, Jul 03, 2016 9:46 pm
Sounds like a lot of progress! Interesting that the screen is bright - do you think the picture tube is okay? But if nothing is happening at boot, I guess the real debugging will start. I guess we can start looking at logic signals and disk signals and see if anything is happening. This is when it would be nice to have a working system so we can swap things around and figure out what works and what doesn't.


-------------------------------------
From: Marc Verdiell
Date: Sun, Jul 03, 2016 7:00 pm
We cleaned the disc drive and disc pack, removed decaying foam, rebuild a seal, and progressively got to the point where it loaded the disc pack, spun it up, and dropped the heads in position on track zero. No head crash. We then tried an "all up" power up with everything connected. The monitor came up full page white, quite brighter than on the exerciser. The disc spun up, dropped the heads, spun down to its servoed RPM, and the ready light came on. We pressed the red button on the back of the keyboard to boot and... nothing happened. We decided to call it a day and try again with someone that actually read the documentation. That means you, Ken :-)

Marc