RoadTest Review: Tektronix PA1000 Power Analyzer

A big thanks to element14 and Tektronix, as always, for sending me this gem for review. It’s been a long four months since I’ve received the Tektronix PA1000 for review, and due to a rather extraordinary set of circumstances, what should have been a two month review process dragged on as I was hesitating on publishing until now. It has been a long wait, but I hope you will agree that it was worth it.

DSC_5833

The PA1000 is a “general purpose” power analyzer which owes its heritage to the Voltech PM1000+. Since Tektronix acquired Voltech’s Power Analyzer IP, they have entered the power analyzer market with a single channel PA1000 and a multi-channel PA4000.

DSC_5681

Very much suited for making single phase power measurements, it is capable of performing standby power testing on most appliances that run from a GPO, as well as testing the load profile, inrush currents and harmonic distortion. It is capable of measuring many mains quality parameters as well, however, it is equally at home working with DC as well. Multiple units can be used with the software to derive efficiency measurements or to add measurement channels, and it is suitable for use with external current transducers for measuring even larger currents or the output from LED current drivers and fluorescent tube ballasts (which are tricky to get right).

The PA1000 is a pretty interesting and amazing piece of hardware, which has ample potential and great specifications compared to its competitors. Its price is definitely the most reasonable of the lot, with good connectivity, dual current measurement shunts and software “bundled in” for IEC 62301 Ed.2 standby energy compliance testing. For this, it makes things almost too-easy!

At the moment, however, I have identified various issues and improvements with both the firmware and the PWRVIEW software which I have communicated to Tektronix. To their credit, they valued my feedback and were committed to implementing fixes and features over the next few firmware and software releases.

Since my RoadTest, one version of PWRVIEW has been released fixing one of the issues I had identified, and another version of software and firmware is scheduled to be released mid-August. I look forward to testing it and noting the improvements.

Read the Full Review at element14!

Posted in Electronics | Tagged , , , , | Leave a comment

Tech Flashback: Fujitsu M2266SA – Part 3 – Transplant & Teardown

Well, as I’m sure you’re aware, my experimentation doesn’t “wait” for a blog posting, instead, things are the other way around. Having made as best of an image as I could of the 1993-model drive, I decided to have a crack at reviving the 1992-model drive.

Brain and Heart Transplant

It’s always nice to have pairs of things, especially when they are built modular. I already disassembled everything “exterior” to the platter chambers of the drive in Part 1, so I know my way around the outsides of the drive.

The first thing I think of when I hear clunking noises is something wrong with the electronics – often something to do with a failed head pre-amp or bad joint that carries the signal from the heads. When there is such a failure, the drive is unable to read critical information it needs to start up.

On relatively modern drives, part of the firmware is stored in the service areas of the drive – non-user-accessible cylinders of the platters reserved for firmware modules and defect lists among other information. Damages to these areas or difficulty in reading these areas are common causes for drives turning up with 0 LBA (i.e. zero size) and with mis-identified drive ID names which reflect the “codename” for the drive series. This drive was presenting literally all of these symptoms.

That being said, it was common for drives of this vintage to have their firmware all in EPROM (we examined this in Part 2), but it seems Fujitsu were well ahead of their time, when we look at this excerpt from the few remaining documents about the drive:

1. When power is turned on, the IDD executes initial self-diag-
nosis.
2. If an error is detected in the initial self-diagnosis, the LED
on the front panel blinks. The spindle motor may or may not
start rotating in this stage.
3. When the LED display requirements are set to “READY status”,
the LED on the front panel lights 20 seconds after power is
turned on. At this time, the LED on the front panel blinks
while the IDD reads “system information” from the system space on the disk.
4. When the LED display requirements are set to “in connection
with SCSI bus”, the LED on the front panel remains off (when
the initiator accesses the IDD via the SCSI bus, the LED
lights). However, the disk drive enters the READY status in 20
seconds after power is turned on. At this time, the IDD reads
“system information” as in step 3.

DSC_7541Alas, the first thing I did was to swap the interface board that goes between the flexible-flat cable from the platter chamber to the rear PCB. I didn’t change the rear PCB at this stage, despite the different revision, because of the EPROM differences which may make a difference. With proprietary hardware like this, companies are not unknown for making subtle changes to their firmware and internal designs in the name of product improvement and this could impact on compatibility.

Unfortunately, with just this board transplanted, the drive still failed to calibrate and came up as FUJITSU NOT READY. Bummer. As I have reason to believe this drive may have been part of a RAID or JBOD array, it is in my interest to get it working as best as I can.

DSC_7531The second stage transplant involves transplanting the rear PCB altogether between drives despite the differences in spindle motors as identified earlier. While it may be risky sometimes, I had nothing to lose. After all, I did already recover as much as practical from the other drive.

With this, I did have some level of success, with the drive actually identifying correctly this time, but instead, it made even worse noises. A much faster staccato sounding seek.

I pushed on. I got my ddrescue running on it, despite the syslog constantly being flooded with Hardware Failure reports from the drive itself, rather than the more innocuous Unrecovered Read Error or Data address mark not found as before.

After a gruelling, noisy, almost hypnotizing 24-hours of grinding away, only a measily 760kiB of data ever turned up. The majority of it was gone. I think, at this point, I have resigned it to the grave. Let it be shown that I did at least try to get something out of it.

From that, I think it’s likely there’s some hardware damage to it. Given it was bought at auction over a decade ago, and it had to survive the postage service to my place, it may have received enough of an impact to cause disk-shift or head damage altogether. There was little point in trying to re-use it, although I should note that trying to fill the drive with zeroes only made the drive even more grumpy until it just spun itself down, likely a sign that it’s really not playing ball with us. There may have been a way to help it with some vendor-specific SCSI commands, but I have no knowledge of it, and it is arguably not worth my time, so lets take a different route.

Drive Dissection

I know this part can be rather heartbreaking for some to watch, so if you’re the sort that is squeamish at seeing old gear being taken apart, look away now (and maybe rejoin us in a later part). For the rest of us, we get to take a look into this behemoth, which is arguably a fantastic paperweight or boat anchor.

DSC_7546

While the majority of the top lid is conveniently secured with Philips head screws, there’s a few always hiding underneath labels. In this case, I did find some relatively unexpected things hiding underneath the warranty seals.

For example, two of the labels seem to be covering up some sort of rubber bung. Now what might that be used to cover? With careful prying with a screwdriver, we see …

DSC_7547

… some very odd fasteners. It almost looks like the fasteners used to hold in the seek arms of modern drives, but they’re not placed where you expect them to be. The slot cut-out in them allow them to be easily undone with a flat blade screwdriver.

DSC_7548

As to their specific purpose and reason for being this shape, that still eludes me at this moment in time. Anyhow, add an Allen key and a small wrench to the list of tools and in no time, we can take the cover right off.

DSC_7566

For the time, the hard disk industry had mostly moved away from the older, slower, less reliable and less track-dense mechanical stepper motor designs into voice coil motors, and this drive is definitely one of those. Another thing that was in motion of the time, was to move away from iron oxide based coatings (i.e. brown, rust-coloured platters) which had lower coercivity (and less bit density and durability) to newer thin film based coatings. This gives the platter its familiar “golden” colour, although, being an earlier thin film drive, the surface uniformity of the platter is less consistent than modern drives (which are a mirror-like finish, whereas this looks like it’s got a nice fine concentric polish).

Looking at the picture itself might deceive you into not understanding just how physically big the drive is. On the screen, everything looks roughly the same size, but if you think of an A4 sheet of paper – this drive has a footprint almost as big.

DSC_7559

By shooting with light reflected off a white sheet of paper, you get the “advertisement” style photo of the drive platters and its light brown gradated colouration. The drive itself features automatic head parking to the centre landing zone, and an impressive eight platters and sixteen heads. Needless to say, I don’t think we make drives with any more than six platters at the most, and most commonly the limit is four to five for consumer drives.

DSC_7553

The concentric polish sort of surface finish is more visible in this photo – it’s actually fairly common for drives of the 1990′s to have this sort of surface finish. Reducing variations in surface finish is one of the advances which allowed magnetic heads to ride closer to the surface, improve signal levels and reduce recording sizes to improve density. It is also the reason why we have problems with stiction sometimes – where the heads which are smooth “weld” to the very smooth disk surface with enough force that it stops the spindle motor from being able to rotate the disk.

DSC_7569

A look at the centre bearing portion of the head arm assembly seems to show something I’ve never seen before – there’s a physical spring in there. That’s quite interesting, as it probably is used for either one or two things – maybe it’s used to provide some counteracting force against the voice coil motor itself (similar to how the return spring in a D’arsonval meter works), or maybe it’s there to ensure that on loss of power, the heads are returned to the landing zone, thus “auto parked”.

DSC_7568

A look at the head stack shows heads populated on both sides of every surface. Most of the wires leading to the heads are sheathed in white plastic, except one. Can you guess why this is the case? I’ll come back to this point later on.

DSC_7567

Here, we can see the head signals and two chips which handle them and pass them through to the front PCB on the outside. While I thought the head preamps were external, this probably contradicts my assumption, and it seems maybe there is both the preamps, drivers and some level of multiplexing going on here before the signals are sent out of the chamber.

DSC_7582 DSC_7583

Inside the drive is also an air filter unit from Cambridge Filter Japan Ltd. The lot number looks awfully like a date code to me, and if it is, then this was made April Fool’s Day 1992.

Before I break it apart further, I decided to get a few nice shots of the heads resting on the very shiny surface.

DSC_7578 DSC_7574 DSC_7572

The Point of No Return

Some may have been convinced that I had passed the point of no return as soon as I opened the chamber, and while that might be true, the drives can remain partially functioning as long as the contamination isn’t too bad.

Instead, the drive is being truly and utterly violated by having its parts removed. For one, here’s the whole head-stack assembly:

DSC_7587

The rear of the assembly is connected to a very heavy duty voice coil motor.

DSC_7585

It is constructed in a way I haven’t seen before. The top and bottom segments with glue dimples are the actual magnets whereas the centre leg is part of the “core” loop that keeps the flux in. The lack piece of plastic is actually a coil former, where the enameled copper wire is wound, forming the motor.

DSC_7638

Getting the magnets apart to get to this stage was very tough.

DSC_7624

Removal of the platter clamp allowed the disks to “roam free”, and undoing the screws behind let the spindle motor roam free of the casing too. It’s a pretty large spindle motor unit, from a company who is very famous even today for making motors.

DSC_7636 DSC_7635

After all of that, we are left with the bare carcass of the drive. Its sacrifice was documented in the name of “science” and “education”.

DSC_7645

But Wait! There’s More!

In what was a rather serendipitous discovery, while getting some nice close-ups of the heads (they’re only about 2mm x 3mm), I saw something …

DSC_7590

enhance!

DSC_7607

As you can see, each head chip has two contacts which are wire-bonded (probably by hand) and then epoxy sealed. This one is a special head-set – the set of platter four (from the top). Notice the etchings on the head chip itself … I couldn’t read it with my eye, but my camera could resolve it with a macro lens.

Already, from this view, we can see the heads themselves, it’s just right of the wire bonds of the top head facing down where there’s this sort of D shape with a gap in it. That’s the head gap!

DSC_7642

Aerodynamically, it’s nothing special – just the “standard” head slider assembly of the time. Later models had interesting patterns on the face which controlled the fly height very precisely.

But not only that, I then discovered that the platters were serially etched as well.

DSC_7584

Through a process of careful disassembly and photography, I spent almost an hour very carefully focusing and trying to capture the etched serials. At long last, they read out as follows:

Heads - From TOP to BOTTOM
20 10 EM1132
42 18 EM1132
25 06 EM1132
43 06 EM1132
25 18 EM1132
24 17 EM1132
25 05 EM1132
43 02 EM1132
30 11 M12232
42 11 EM1132
25 17 EM1132
42 06 EM1132
25 02 EM1132
42 16 EM1132
25 10 EM1132
45 05 EM1132

Platters - From TOP to BOTTOM
4K2313G21811
4K2313G21804
4K2313G21802
4K2313G21719
4K2313G11715
4K2313G21713
4K2313G21711
4K2313G21710

It is interesting to note that the heads are probably chosen based on their test parameters, and the first two numbers may have something to do with the test results. Note how most but not all top-surface heads have 20-something values for the first column and most but not all bottom-surface heads have 40-something values for the first column, with the exception mainly being the heads for the third and fifth platters.

Also worthy of note is that for the fifth platter’s top surface, the coding on the head is different, as is the serial coding of the fifth platter.

It seems that there is truth to the drive geometry data in stating that this is a fifteen head drive, as despite it having sixteen physical heads, one of them is clearly distinguished in such a way that it appears to be a dedicated servo surface. In other words, the top side of the fifth platter from the top likely only contains positioning information. As a result, it likely uses optimized heads for that purpose. This coincides with the brown-coloured sheathing on the wires to this head.

It’s also rather interesting to me that the platters are not serial-sequential. Maybe this is a sign of some careful head to platter matching or the number of defects which may have been encountered during manufacturing putting the platters out of the defect-specification.

The use of dedicated servo is confirmed by this excerpt:

Since the IDD has the automatic readjustment function of positi-
oning (seek) control, it automatically executes the adjustment
operations with seek at specific intervals from power on (first
adjustment: 2 minutes after power on). When the LED display requirements are set to “READY status”, the LED on the front panel blinks during the adjustment.

This is one of the biggest disadvantages of the dedicated servo – due to differential expansion, and temperature variations affecting performance, the drive periodically re-calibrates itself which causes a loss of performance periodically. For systems where continuous throughput is necessary, recalibration may interrupt the data flow long enough to cause dropped frames in video capture/playback, or ruined CDs in the case of buffer under-run.

Conclusion

Despite trying my best, I couldn’t bring it back to life, so instead, it was reduced to parts for our education and entertainment. The drive itself used fairly advanced technology for its time – service area cylinders, voice coil motors, electronic servo, thin film media with a very large number of platters.

What was discovered indicates the use of a dedicated platter servo system, which is now considered archaic, and carefully etched serials on components which allude to its existence. Also discovered was the use of a “return spring” mechanism on the voice coil motor, a feature I have not seen anywhere else, and a beefy and unusual voice coil motor design.

At this point, I’m not sure if a Part 4 will be coming … but if it is, it will be a look at the recovered data. Unfortunately, I won’t be able to give away too many juicy bits, so expect it to be a “short” finale to an otherwise very interesting exploration.

Posted in Computing, Tech Flashback | Tagged , , , | Leave a comment

Tech Flashback: Fujitsu M2266SA – Part 2 – Pulling Data in More Ways than One

Old hardware often presents challenges and opportunities to those who love to tinker. It can be a whole load of fun. Since receiving the drives on 14th July, I have been tinkering with them right up till today. That’s a whole load of fun … so what did I get up to?

Recovering the Data

For the one so-called functioning drive, what I really wanted to know was in what condition is it in, and what was its history? Seeing that it was in my hands now, and it’s technically all mine, I decided to go and recover all the data I could.

For that, I decided to use the trusty ddrescue (package gddrescue) under Lubuntu on an old machine with a SCSI card to do the recovery. It’s a pretty-much automated recovery program that seeks to make a complete disk image by reading forwards, backwards, and retrying/splitting failed areas. It’s pretty robust, with logging so it can be resumed on any interruption.

Already, as the recovery started, the drive itself was complaining. The drive worked about as well as an elderly person with arthritis doing the weekly shopping …

It was having quite a bit of difficulty finding the data. The back and forth seeks are the automated hardware retries which are performed by firmware to try and attempt reading data again in the hope that it would be corrected.

As a result, the recovery started on the 15th July, with a flurry of messages flooding the syslog:

[10202.155302] sd 0:0:4:0: [sdb] Unhandled sense code
[10202.155307] sd 0:0:4:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
[10202.155311] sd 0:0:4:0: [sdb]  Sense Key : Medium Error [current] 
[10202.155316] Info fld=0x18348
[10202.155318] sd 0:0:4:0: [sdb]  Add. Sense: Unrecovered read error
[10202.155323] sd 0:0:4:0: [sdb] CDB: Read(10): 28 00 00 01 83 48 00 00 08 00
[10202.155332] end_request: critical target error, dev sdb, sector 99144
[10202.155337] Buffer I/O error on device sdb, logical block 12393

[10226.678189] sd 0:0:4:0: [sdb] Unhandled sense code
[10226.678194] sd 0:0:4:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
[10226.678199] sd 0:0:4:0: [sdb]  Sense Key : Medium Error [current] 
[10226.678203] Info fld=0x18378
[10226.678206] sd 0:0:4:0: [sdb]  Add. Sense: Address mark not found for data field
[10226.678211] sd 0:0:4:0: [sdb] CDB: Read(10): 28 00 00 01 83 78 00 00 08 00
[10226.678220] end_request: critical target error, dev sdb, sector 99192
[10226.678225] Buffer I/O error on device sdb, logical block 12399

[10263.776138] sd 0:0:4:0: [sdb] Unhandled sense code
[10263.776144] sd 0:0:4:0: [sdb]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[10263.776148] sd 0:0:4:0: [sdb]  Sense Key : Medium Error [current] 
[10263.776153] Info fld=0x18850
[10263.776155] sd 0:0:4:0: [sdb]  Add. Sense: Id CRC or ECC error
[10263.776160] sd 0:0:4:0: [sdb] CDB: Read(10): 28 00 00 01 88 50 00 00 08 00
[10263.776168] end_request: I/O error, dev sdb, sector 100432
[10263.776174] Buffer I/O error on device sdb, logical block 12554

As you can see, I’ve excerpted several variety of errors above, but I also had parity errors initially which was tracked down to a dodgey SCSI connection somewhere. There was also Hardware Error in one rare case.

In all, it’s a clear sign of a drive which is informing us how badly damaged it is. Unrecoverable read errors suggest a readout which doesn’t pass ECC checking and cannot be repaired, whereas data address mark errors suggest serious read issues where the factory drive formatting is questionable. ID CRC or ECC errors are also a sign of this, which suggests that the sector ID may be damaged. It’s quite nice to see the drive being quite descriptive of its issues … but there’s more to it than that.

The recovery process never fully completed, but early on, thanks to the ddrescueview tool, interesting patterns were emerging.

badlist

If you size the window just right, as I have, it is clear that there’s a periodicity to the existence of bad blocks. The number of bands seems to be because of the way the window is sized, but the periodicity itself implies that one of the surfaces or heads may be problematic.

Initially the data in the bands was quite lost, and leaving it to run over about two weeks, it slowly started to clear somewhat …

badlist2 badlist3 badlist4 badlist5

Instead, the bands took on a barber pole striation. This was also an interesting occurrence, as the drive would often find data if asked enough times to retrieve a given sector! This implies the data was written, but there is some difficulty in retrieving it.

The fact that the periodicity is straight throughout the drive surface seems to suggest this drive is not using zoned-bit-recording. As a result, the number of sectors per track remains constant from the inside to the outside. This type of recording is relatively old-fashioned and inefficient.

The striations themselves, I hypothesize,indicate some sort of radial damage to one surface somehow. Maybe there’s some out-gassing or a scratch on the platter surface radially. That would affect one sector per revolution (for example). But as many drives are formatted with a given sector slip (i.e. sector 1 isn’t always at the same angular position, and is instead rotated by a specific amount on subsequent tracks to allow for faster access by accounting for head positioning time), the errored sector also “slips”.

The amount of data being discovered later on got very very low, and eventually, a whole 12 hours passed with no new data discovered. All in all, about 24Mb of data from a 1079Mb drive was lost, in around 3000-separate chunks. It’s like swiss cheese, but it should make for some delicious data-archaeology.

Another Sort of Data Worth Pulling?

It’s a funny thing, because this drive finally inspired me to do something I had wanted to do for a long time – dump an EPROM. I’ve always been conscious in my mind that it is possible to dump an EPROM using an Arduino, a breadboard and some wires, but I never actually had an incentive to do it until now. After all, this drive had a pretty juicy EPROM.

The first thing was to look up the model number (MBM27C1024-15) and find the datasheet. A 40-pin DIP chip isn’t something for most beginners to play with, but I thought it would be fine for me.

It turns out it is a 1Mbit (128kByte) device with a 16-bit wide parallel output, and a 16-bit address bus. These things are pretty “dumb” and simple, which is great news – you give it an address bit and out pops the data 150ns later, provided you have the rest of the lines hooked up correctly. For reading, that would be Vcc=Vpp=5v, GND=0v, /OE=/CE=0v, /PGM=5v.

Then you need to write a quick program to do it. I’m sure someone else has a more elegant program, maybe even one that works generally, but it’s not hard to knock something up. I used the MEGA’s array of dual-in-line pins to interface with the EPROM and it proved just to be sufficient.

From memory, I assigned Pin 22 = A15 … Pin 37 = A0 and Pin 38 = D0 .. Pin 53 = D15. It might seem a strange assignment, but I did it without thinking … just like I wrote this program:

void setup () {
  int count=22;
  while(count<=37) {
    pinMode(count,OUTPUT);
    digitalWrite(count,0);
    count++;
  }
  while(count<=53) {
    pinMode(count,INPUT);
    count++;
  }
  pinMode(13,OUTPUT);
  Serial.begin(9600);
}

void loop() {
  long address = 0;
  int byte1 = 0;
  int byte2 = 0;
  int count = 0;
  int bits = 0;
  char tstring[5] = {0};
  while (address <= 0xFFFF) {
    count=22;
    bits=15;
    while(count<=37) {
      digitalWrite(count,(address&(1<<bits))>>bits);
      count++;
      bits--;
    }
    delay(1);
    byte1=0;
    count=53;
    while(count >=46) {
      byte1 = byte1<<1 | digitalRead(count);
      count--;
    }
    byte2=0;
    while(count >=38) {
      byte2 = byte2<<1 | digitalRead(count);
      count--;
    }
    sprintf(tstring,"%02x%02x",byte1,byte2);
    Serial.print(tstring);
    address++;
  }
  while(1) {
    digitalWrite(13,HIGH);
    delay(250);
    digitalWrite(13,LOW);
    delay(250);
  }
}

Afterwards, it was a painstaking test of patience to wire it up, start up a terminal emulator and capture the hex characters flow out of it. After seeing multiple 0×00 and 0xFF results, and no visible “looping”, I was fairly confident all the connections were working. After three dumps of identical results, I was confident that no data was being mangled by the serial nature of the output (no error checking).

DSC_7397

It’s quite interesting what happens when I get desperate. So what did I discover? Well, for one, the EPROMs from both drives had some differences and mostly similarities. By converting each byte into a one-pixel greyscale 8-bit value, and animating between the two ROMs, you can visually compare the differences:

1993EPROMOr if you would prefer I just use a difference between layers in Photoshop, well here’s that:

eeprom-difference

In other words, the core of the code is the same, but a few bits and pieces had changed in some parts, and bulk segments towards the end had changed significantly. Why is this the case? Well it’s because that’s where each of the modules that perform certain sorts of control are held, and as the firmware is rebuilt, these modules can be relocated depending on their size and linker ordering, so maybe there are more similarities if we account for code relocation.

Right now you’re probably thinking I’m pulling stuff out of my proverbial ass but hold on a sec … the firmware speaks. By this, I mean, lets analyze it for human readable strings.

Fujitsu-Not-Ready

For example, here seems to lay the ID in case something goes critically wrong with the service cylinders, as per the 1992-drive. Nothing too exciting, you might say … but the other discoveries are a little more intriguing.

Humming 6S 80196 Micro Program

For example, this snippet which says Humming – 6S 80196 Micro Program Copyright (C) FUJUTSU LIMITED 1989-1990. Interesting that Fujitsu is spelt incorrectly. I wonder what Humming is – is that their codename for this drive? It might make sense, maybe after Hummingbird, as the Seagate competitors were named Wren, another sort of bird. It also reveals the program as being for the 80196, which is the Intel microcontroller.

Config-V007

This might be the configuration module, version 8, dated 15th June 1989. Interestingly there is a scattering of attribution text, such as made by O. Yoshida and S. Saito. It would be pretty cool to know your name was being burnt onto ROMs being distributed with every drive, although it consumes memory (which is often limited) and serves no programmatic purpose.

Base V0010

It seems to be made with base module version 10, dated 21st February 1990.

HM-5 SCSI TYPE-001

Then, there is this perplexing text which says HM-5 SCSI TYPE-001 VERS-1.0 dated 29th September 1989 (note the different date format) MECHA V03L06 COPYRIGHT (C) 1989. FUJITSU LTD. I wonder if this is representative of code re-use? Maybe there was a Humming-5 series drive, hence the HM-5 designation, whose firmware base was “reused”.

Module-Difference

Now we get into the areas where the firmware differs – with the 1993 dump on top and the 1992 dump on the bottom. Note how this segment begins with the Read/Write V04B0 module dated 12th October 1989, whereas the other segment begins with Motor Control V00L00 dated 13th October 1989 by Kikuchi and Yoshida. This is where I base my suspicion that these are relocatable code segments (i.e. functions) which are linked in different locations.

Motor-Control

There is also a format module by Shigeru Saito and Takashi Mochiduki from October 1989 to July 1990. Then it seems, there’s some version control dating mixups …

Diag-Program

There’s a diagnostic module programer by S. Saito, dated 1988-1989 (inconsistent date formats everywhere).

Address Transfer

This is followed by the Address Transfer V00L00 module dated 13th October 1989 by Kikuchi and Aoyagi.

FPU

And finally, an FPU module, version 10, dated 21st February 1990.

It seems that pulling data from the EPROM has yielded many easter eggs. These strings of text are unlikely to be used by the actual program that’s running, but are visible to anyone who dumps the contents of the EPROM. That’s pretty amazing, as we have identified both dates, and people involved in the production of the firmware. It was my expectation that that would not be ordinarily found as many EPROMs are limited in size and the number of bytes available are quite precious.

It seems that Shigeru Saito had a big hand in coding most of the modules …

Further analysis of the firmware routines could be possible by passing the dump through IDA Pro and doing some disassembly, however, that would require someone who is experienced enough in 80196 architecture and assembly coding to fully understand what the code is doing.

Conclusion

Recovery of the drive was only partially successful, and analysis of the data contained within is a job for a future posting. However, dumping of the EPROM was highly successful, and fairly easily accomplished provided one has the patience to wire it up by hand and wait for it to dump. It revealed quite a few easter eggs – so maybe people might be more inspired to dump any random EPROM they might have access to just to see what happens.

More to come in the next part where we take a look at the insides of the non-functioning drive …

Posted in Computing, Tech Flashback | Tagged , , | 6 Comments