Rational/R1000s400/Logbook

Fra DDHFwiki
Spring til navigation Spring til søgning

2021-01-01 Our first Rosetta Stones

A brute-force text-search at all bit-positions of all heap-segments, we have found our first "Rosetta Stones":

[⟦a564c4d78⟧ Numeric_Primitives'spec]

[⟦c5cdc1bc4⟧ Numeric_Primitives'body]

[⟦cb8e43375⟧ Numeric_Primitives'code]

and

[⟦05ee57b6d⟧ Trig_Lib'spec]

[⟦1329b5ea7⟧ Trig_Lib'body]

[⟦85b414c73⟧ Trig_Lib'code]

Both of them are very simple, and that has enabled us to unravel the basic Float and Discrete mathematical operators, as well as some comparison and flow-control operations.

Happy New Year

/phk

2020-12-30 A pile of PostScript

My continued digging through the backup-tape has uncovered a pile of postscript files:

   ⟦0035e76eb⟧ Remote Compilation Facility - Release Information - Release_1_0_3
   ⟦05988f7ca⟧ Insight - Installation Procedure - Release_1_0_1
   ⟦07d905c09⟧ Rational Insight - Release Information - Rev1_3_0
   ⟦0d71b57c2⟧ Rational Access Description - 0.8.0 Release
   ⟦17d276e59⟧ Rational Environment Release Information - Release D_12_7_3
   ⟦2024a9fe1⟧ Remote Compilation Facility - Release Information - Release_1_2_2
   ⟦23a53e39b⟧ Rationale for the Proposed Standard for a Generic Package of Primitive Functions for Ada
   ⟦3def193b1⟧ Rational Compilation Integrator - Release Information - Release 2_0_5
   ⟦3e2ba7e34⟧ Rational Access - Quick-Reference Guid - Version 0.8.0
   ⟦4734617e8⟧ Remote Compilation Facility - IBM RISC System/6000 Extension - Release Information - Release 1_1_0
   ⟦4a1330c8b⟧ Guide to Machine Initilization - Release D_12_6_5
   ⟦4b29253db⟧ "Usage" besked, titel: "!TOOLS.DOCUMENT_FORMAT"
   ⟦526cacf42⟧ Beskadiget
   ⟦5606b9f32⟧ Rational Style Guide - 0.5.0 Draft
   ⟦56ef92f1d⟧ Beskrivelse af analyse facilitet
   ⟦5717463c9⟧ Remote Compilation Facility - IBM RISC System/6000 - Release 1_0_2
   ⟦68d16b503⟧ grafisk plot af kodestruktur
   ⟦6b572a63f⟧ Rational Compilation Integrator - IBM RISC System/6000 Extension - Release 2_0_2
   ⟦6c03d64ae⟧ Rational Environment Release Information - D_10_20_2 Release
   ⟦6f08c03d9⟧ grafisk plot af kodestruktur
   ⟦74abeabc7⟧ Rational Compilation Integrator - Alsys i386 LynxOS Extension - Release information - Release 2_0_2
   ⟦7af8d1531⟧ Proposed Standard for a Generic Package of Elementary Functions for Ada - Draft 1.2
   ⟦83ca2b315⟧ Rational Environment - Rational Access - X Windows Interface - Revision 0.3.0
   ⟦87a275cc6⟧ Rational X Library: Ada/C Interface Differences
   ⟦89aa031be⟧ Trunkeret
   ⟦8ba0d59a4⟧ Trunkeret
   ⟦91f816da9⟧ Command and Function Description - Alpha Draft
   ⟦944c90873⟧ Rational X Interface Release Information - Rev10_7_2 Release
   ⟦96d5ccb79⟧ Rational Access - Information Plan - Review Draft
   ⟦9893505e2⟧ Proposed Standard for a Generic Package of Primitive Functions for Ada - Draft 1.0
   ⟦99c4458da⟧ Rational Environment Release Information - D_12_1_1 Release
   ⟦9b096c96a⟧ Rational Environment Release Information - D_12_2_4 Release
   ⟦9f8116908⟧ Rational X Library - Release Information - Rev6_0_0 Release
   ⟦a7b6d3dd8⟧ Rational TestMate - Release Information - Rev2_2_0 Release
   ⟦abf32a77e⟧ grafisk plot af kodestruktur
   ⟦b81506409⟧ Rational Environment Release Information - D_12_6_5 Release
   ⟦bde810949⟧ Rationale for the Proposed Standard for a Generic Package of Elemntary Functions for Ada
   ⟦d39cd8235⟧ Del af keyboard template ?
   ⟦d4766a43e⟧ grafisk plot af kodestruktur
   ⟦db6de3cc4⟧ grafisk plot af kodestruktur
   ⟦f404e5d35⟧ Rational Environment Release Information - D_12_5_0 Release
   ⟦f46a1a629⟧ Rational Access - Release Information - Release 1_0_1
   ⟦fdf4d8787⟧ Kun ordet "Information"

The "weird" non-links on the left are identifiers in the AutoArchaeologist excavation of the backup tape.

Archaeologically ⟦96d5ccb79⟧ is probably the most interesting, Fil:Rational Access Information Plan.pdf.

/phk

2020-12-17 You are in a creepy maze of objects, none of them byte-aligned

The R1000 card-cage contains a total of 7 printed circuit boards:

Slot Board Description
1 Mem2 Memory 2 (32 meg)
2 Mem0 Memory 0 (32 meg)
3 FIU Field Isolation Unit
4 SEQ Sequencer
5 TYP Type
6 VAL Value
7 IOC I/O Controller

(From R1000 Hardware Overview)

The Ada language was originally designed for embedded systems, in particular for embedded systems in, around and in control of military weapons, and it dates back where state-of-the-art in radiation-hardened microcomputers was the RCA1802 and a few kilobytes of ROM and RAM was the norm, so being parsimonious with memory space is deeply embedded in the genes of Ada.

For instance, when you define:

   subtype MISSILE_NUMBER is INTEGER range 1 .. 8;

The Ada compiler will know that only three bits will be needed to store that type.

And five bits saved here and four bits saved there, it adds up.

The R1000 is a true-blooded Ada computer, so the fundamental unit of addressing is a bit, and just because your field may happen to be 16 bits wide, does not mean that it is going to be aligned at a 16-bit boundary. (There is a notable exception: Instructions are 16 bit wide and must be aligned to 16 bit boundaries.)

This is where the FIU comes into the picture: When an instruction requires 27 bits starting at a particular address, the FIU carves them out of however many 128 bit hardware words they may span.

This is a complication when reverse-engineering the R1000, both as a mental exercise and a practical matter.

Take for instance this object, which lives in block# 0xd4852:

   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   
   0002360000001581843521480400000000000000000205100000001000000400
   0001ea000000001000000a24001180d485440000201fe6040000201fd6240000
   202002540000201fcde4001160d2bca4001160d2bcb4001160d2bcc400002020
   4c94001160d2bcd4001160d22e940000201faf34001160d2bce4000020204e34
   001160d2bd540000201fb6f4000020204f84001160d2bd640000202002e40000
   202002a4001160d2a6540000201fef9400002020508400002020511400002020
   56b40000202056e40000202004740000202004440000202057f4000020205814
   0000202005540000202059040000202059840000201fedc40000201fd6c40000
   20205a540000201fef24000020205db4001160d2bd74001160d2bd84001160d2
   bd940000201fd5d4000020206074001160d2bda4001160d184a4000020206ce4
   001160d2980400088015b524001160d2bdd40000201fefd40000202070e40011
   60d27864001160d2bde4001160d2bdf40000201f92a4001160d2be040000201f
   f8240000202071c40000202075c4000020207614001160d286b4000020208394
   001160d2b7d40000202084740000202084840000202084940000201fd6140000
   202084f4001160d1b4440000201fc454001160d2be14001160d22c0400002020
   85740000201f90540000202004040000201f9bc40000202085b40000201ff774
   001160d22eb40000202085f40000202086040000202086740000202086840000
   202086940000202086b4001180d488140000202087140000201fd75400002020
   87340000201ff7d40000201fdb54000020208774001060571ea400106049f734
   00106049aab400106049aad4001060675fd4001080be6514001080be65340010
   80be1dd4001080c02cc4001080be6554001160cbef14001160cbf7d4001160cc
   2f24001160cbece4001160cbeb04001160ccb04000000000[…]

If you squint a little bit, it is quite obvious that there are structural diagonal stripes.

One way to fiddle around with such structure is to join the lines to a single long unbroken line, look at that in a window which wraps the line, and then adjust the width of the window with the mouse.

If one does that here, a window 36 characters wide show the pattern clearly as three distinct columns

   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌
   000236000000158184352148040000000000    
   00000002051000000010000004000001ea00    
   0000001000000a24001180d485440000201f    
   e6040000201fd6240000202002540000201f
   cde4001160d2bca4001160d2bcb4001160d2    
   bcc4000020204c94001160d2bcd4001160d2    
   2e940000201faf34001160d2bce400002020    
   4e34001160d2bd540000201fb6f400002020    
   4f84001160d2bd640000202002e400002020    
   02a4001160d2a6540000201fef9400002020    
   50840000202051140000202056b400002020
   56e400002020047400002020044400002020
   […]

36 characters × 4 bits per character / 3 columns = 48 bits per column

Most right-thinking computer people would expect that to be 16+32 bits or possibly 3×16 bits or even 6 bytes, but no, it is actually 28+20 bits.

For now take my word that the array starts 316 bits into the data structure:

   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌   ┌
   000236000000158184352148040000000000    
   00000002051000000010000004000001ea00    
   0000001000000a2 
   4001180 d4854
   4000020 1fe60
   4000020 1fd62
   4000020 20025
   4000020 1fcde
   4001160 d2bca
   4001160 d2bcb
   4001160 d2bcc
   […]

That wasn't too bad, so what about the first 316 bits ? Here is my guess:

Field #Bits Value
hdr0 1 0x0
objid 64 0x46c0000002b03
diskvol 5 0x1
hdr1 4 0x0
blockno 20 0xd4852
hdr2 8 0x1
hdr3 56 0x0
hdr4 32 0x8144
hdr5 28 0x0
indir_level 2 0x1
hdr6 64 0x4000001ea0
hdr7 32 0x1
nblocks 32 0xa2

Notice how neither the value of the `objid` nor the `blockno` fields appear in the hexdump above.

If you look carefully, you might notice that 2×0x236 = 0x46c, this is essentially the first 1-bit wide field "dividing" the `objid` by two:

   0x46c0000002b03 << 3 = 0x23600000015818

The `blockno` on the other hand is shifted two bits:

   0xd4852 << 2 = 0x352148

Full disclosure: All the fields named `hdr%d` are white spots on the map. I have no idea if have assigned the right widths, or for that matter what they mean.

They have these precise values in all instances of this particular structure I have found yet.

My theory is that they may actually be a type-descriptor, because the last two, 0x1 and 0xa2, would describe the index range for the array of 162 elements, each 48 bit wide which follows.

Of those 48 bits, I have no idea what the first 28 bit means, but I the last 20 bit is a block number.

This is going to take some time, and I'm going to become a LOT better at mental hexadecimal arithmetic before we are done.

/phk

2020-12-12 Things to do in Covid-19 Lockdown

Try as we will, realistically we cannot keep our R1000 machine running forever, which puts us under a tacit obligation to write a "software-R1000" to keep the "Environment" alive when its hardware eventually gives up the ghost.

By now I have lost track of how many different computers I have written more or less comprehensive emulations of, and the general recipe has always been to start with the "Programmers Reference Manual" or whatever it happens to be called.

It is not obvious to what extent such a manual ever existed for the R1000, we certainly do not have it. What we do have is an abstract Ada description of the instruction, and a pair of example printouts, containing some kind of assembly listing of two trivial Ada programs, in the Guru Course 01 slides.

Try as I might, I cannot get the Ada description to deliver the actual bit-patterns of the instructions, if this description is authentic and not just for example, there must be one or more pieces of (Ada-)code which translates this description into 16 bit instruction-words.

Nonetheless, the Ada description helps a lot, in that it gives the names of all the instructions and the sizes of many of the argument fields in them, so for instance when it tells us (p36 right bottom):

   [...]
   type PC_Offset is new Integer range -2 ** 10 .. 2 ** 10 -1;
   [...]

and (p38 left bottom):

   [...]
   when Jump [...] =>
       Relative : Pc_Offset
   [...]

and one of the listings (p88, top right) tells us:

   [...]
   35 0023: 7801  JUMP    1
   [...]

Then it is a good guess that the Programmers Reference manual would have described the JUMP instruction as:

                   ┌───────┬───────┬───────┬───────┐
   JUMP    pcrel   │0 1 1 1│1 X X X│X X X X│X X X X│
                   └───────┴───────┴───────┴───────┘

Various bits of evidence indicates that the listings in the Guru Course are produced by the Ada compiler during compilation. If so, we should be able tease out the encoding of a lot of instructions by writing and compiling Ada programs that causes the compiler to emit the instructions in question.

But right now the R1000 and the rest of our collection is inaccessible, due to the Covid-19 lockdown.

So I sit at home, and try to wring as much information and as many clues as possible out of the documentation we have, and try it out on the code segments on the data media in our bitarchive.

One thing I have found out is that the listings in the Guru Course are not comprehensive, for instance on p43 left top:

   [...]
   27 001B: 4800  SHORT_LITERAL    0
   28 001C: 0093  EXTENSION    147
   29 001D: 0033  EXTENSION     6,  3       ;;; push full address of a location in
                                                               current code segment
   [...]

Try as I might, I cannot puzzle an instruction which pushes an absolute address in the code-segment out of the Ada specification.

The fact that the compiler also does not know the name of this instruction makes me suspect that it has been added to the microcode and compiler, as an optimization, at such a late date, that nobody felt like recompiling everything from scratch, leaving the Ada description out of date.

/phk

2020 08-20

Broken piece of plastic from the Facit Twist 20200813 Facit Broken Plastic.jpg

Replicated piece of plastic for the Facit Twist 20200815 Facit Replicated Plastic.jpg

Facit can Twist again.

2020 08-13

Per opened the Facit Twist, found a broken piece of plastic and saw it as an excuse to use his 3D-printer.

2020-08-07

Booted the R1000 yesterday, came up fine, but the Facit showed the "landscape" in both orientations.

2019-12-11

SCSI command 0x0d seems to be explained now:

Søren Roug has spotted SASI command 0x0d in the manual for the Xebec S1410 diskcontroller:

It returns the length of burst errors corrected with ECC.

That matches the CMD_CORRECTION Tollef found.

Thanks everybody!

2019-12-08

About that 0x0d SCSI command...

My good friend Tollef Fog Heen replied on twitter that this source file on github calls the command CMD_CORRECTION.

That github repository contains a NeXT Station emulation.

The NeXT Station had a Magneto-Optical drive.

The first two pages of this bunch of papers that came with the machine, marked "aflasting" ("off-loading"), are jumper settings for Fujitsu's M2512A MO drive.

So the best theory now is that 0x0D is a way to probe for a MO drive configured as a disk drive.

I'll leave it at that for now, but I'm still interested to hear from anybody who spots 0x0d in old documents.

/phk

2019-12-07

Now it works!

My hacked up SCSI2SD firmware provided a log of all SCSI commands during boot and the two crucial ones turns out to be:

   1a 00 03 00 24 00
   1a 00 04 00 20 00

Those are "MODE SENSE(6)" commands, asking for page 3 and 4 respectively.

Page 3 is "Format Device" and the FUJITSU M2266 returns:

   00 0f 00 00 00 00 00 2d 00 2d 04 00 00 01 00 05 00 0b 40 00 00 00
   
   Tracks per Zone:  15
   Alternate Sectors per Zone:  0
   Alternate Tracks per Zone:  0
   Alternate Tracks per Logical Unit:  45
   Sectors per Track:  45
   Data Bytes per Physical Sector:  1024
   Interleave:  1
   Track Skew Factor:  5
   Cylinder Skew Factor:  11
   SSEC:  0
   HSEC:  1
   RMB:  0
   SURF:  0

Page 4 is "Rigid Disk Geometry" where the FUJITSU M2266 returns:

   00 06 7a 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   
   Number of Cylinders:  1658
   Number of Heads:  15
   Starting Cylinder-Write Precompensation:  0
   Starting Cylinder-Reduced Write Current:  0
   Drive Step Rate:  0
   Landing Zone Cylinder:  0
   RPL:  0
   Rotational Offset:  0
   Medium Rotation Rate:  0

After I hacked the SCSI2SD firmware to return those values, the R1000 booted flawlessly on the saved disk-images from PAM's machine.

Conclusion: The IOC bootstrap uses "modern SCSI" with linear block-numbers, the real system works in terms of Cylinders, Heads and Sectors.

/phk

2019-12-05

A little bit more SCSI2SD progress today.

I compiled a custom firmware for the SCSI2SD to get more logging, still sampling, but it should capture all failing commands now.

The picture from the log is the following:

First some SCSI READ(10) commands, which are compatible with the loading of KERNEL, FS and PROGRAM.

Then a SCSI command 0x0d, which is unknown everywhere I have looked. This command sets a flag in the KERNEL if successful, I have not investigated that flag further.

Next a SCSI MODE SENSE (RIGID DISK GEOMETRY)

Finally SCSI READ(6) commands which are past the DFS filesystem.

At the same time the console shows this:

   Disk  0 is ONLINE and WRITE ENABLED
   Disk  1 is ONLINE and WRITE ENABLED
   IOP Kernel is initialized
   Initializing diagnostic file system ... File does not exist ERROR_LOG
   [OK]

Working theory right now is that the R1000 uses the RIGID DISK GEOMETRY data to calculate disk access, and what the SCSI2SD returns does not work for this.

I queried one of the blank Fujitsu disks we got from Terma in our "dumper machine" and it returns:

   00 06 7a 0f 00 00 00 00
   00 00 00 00 00 00 00 00
   00 00 00 00 00 00
   
   Number of Cylinders:  1658
   Number of Heads:  15
   Starting Cylinder-Write Precompensation:  0
   Starting Cylinder-Reduced Write Current:  0
   Drive Step Rate:  0
   Landing Zone Cylinder:  0
   RPL:  0
   Rotational Offset:  0
   Medium Rotation Rate:  0

Whereas the SCSI2SD seems to return:

   00 38 30 06 00 00 00 00
   00 00 00 00 00 00 00 00
   00 00 1c 05 00 00
   
   Number of Cylinders:  14384
   Number of Heads:  6
   Starting Cylinder-Write Precompensation:  0
   Starting Cylinder-Reduced Write Current:  0
   Drive Step Rate:  0
   Landing Zone Cylinder:  0
   RPL:  0
   Rotational Offset:  0
   Medium Rotation Rate:  7173

My next experiment will be to make the SCSI2SD firmware emit the same RIGID GEOMETRY as the Fujitsu disk.

2019-11-20

I made a DFS backup from PAM's Fujitsu disks, and read the remaining 8mm tapes.

/phk

2019-11-14

Got a bit further with the SCSI2SD: 1024 byte sector size helps, still get a DFS kernel panic though:

   Initializing M400S I/O Processor Kernel 4_2_18
   Disk  0 is ONLINE and WRITE ENABLED
   Disk  1 is ONLINE and WRITE ENABLED
   IOP Kernel is initialized
   Initializing diagnostic file system ... File does not exist ERROR_LOG
   [OK]

   I/O Processor Kernel Crash: error 0614 (hex) at PC=0000849E
   ************************************************

Next, tried to restore the backup of PAM's disks onto the Seagate disks, looks like success:

   --- Booting the R1000 Environment ---
     Loading from file M207_44.M200_UCODE  bound on November 5, 1992 at 6:08:17 PM
     Loading Register Files .... [OK]
   Loading : KAB.11.0.1.MLOAD
   Loading : KMI.11.0.0.MLOAD
   Loading : KKDIO.11.0.3.MLOAD
   Loading : KKD.11.0.0S.MLOAD
   Loading : KK.11.5.9K.MLOAD
   Loading : EEDB.11.2.0D.MLOAD
   Loading : UOSU.11.3.0D.MLOAD
   Loading : UED.10.0.0R.MLOAD
   Loading : UM.11.1.5D.MLOAD
   Loading : UAT.11.2.2D.MLOAD
   851/1529 wired/total pages loaded.
       The use of this system is subject to the software license terms and
       conditions agreed upon between Rational and the Customer.
   
                            Copyright 1992 by Rational.
   
                             RESTRICTED RIGHTS LEGEND
   
       Use, duplication, or disclosure by the Government is subject to
       restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
       Technical Data and Computer Software clause at DoD FAR Supplement
       252.227-7013.
   
                   Rational
                   3320 Scott Blvd.
                   Santa Clara, California 95054-3197
   
   Starting R1000 Environment - it now owns this console.
   
   ====>> Kernel.11.5.8 <<====
   Kernel: CHANGE_GHOST_LOGGING
   WANT TRACING: FALSE
   WANT LOGGING: FALSE
   Kernel: START_VIRTUAL_MEMORY
   ALLOW PAGE FAULTS: YES
   
   ====>> ERROR_LOG <<====
   22:55:05 --- TCP_IP_Driver.Worker.Finalized
   
   ====>> CONFIGURATOR <<====
   starting diagnosis of configuration
   recovery is needed
   WANT TO BUILD NEW SYSTEM (YES/NO): yes
   starting creation of new system
   VOLUME NAME FOR unit 0: volume 1
   VOLUME NAME FOR unit 1: volume 2
   creating root volume: 1
   adding volume 2 to virtual memory system
   creation of new system is complete
   starting virtual memory system
   the virtual memory system is up
   
   ====>> Kernel.11.5.8 <<====
   Kernel: START_NETWORK_IO
   Kernel: START_ENVIRONMENT
   TRACE LEVEL: INFORMATIVE
   Kernel:
   
   ====>> Environment Elaborator <<====
   Elaborating subsystem:  ENVIRONMENT_DEBUGGER
   Elaborating subsystem:  ABSTRACT_TYPES
   Elaborating subsystem:  MISCELLANEOUS
   Elaborating subsystem:  OS_UTILITIES
   
   ====>> Recovery <<====
   Recovery Is Needed, Should I fake it? no
   Please tell me Volume Id for the Backup Index Tape:
   
   ====>> SYSTEM % RECOVERY <<====
   
   Please Load Tape
     (Kind of Tape    => CHAINED_ANSI,
      Direction       => READING)
   Is Tape mounted and ready to read labels? yes
   Info on tape mounted on drive 0 is:
     (Kind of Tape    => CHAINED_ANSI,
      Writeable       => FALSE,
      Volume Id       => 028600,
      Volume Set Name => BACKUP, 09-MAR-01 16:01:45 3)
   OK to read volume? [YES]
   
   ====>> Recovery <<====
   Positioning tape to Backup Index
   Processing Backup Index
      Processing Tape File: Vol Info
      Processing Tape File: VP Info
      Processing Tape File: DB Backups
      Processing Tape File: DB Processors
      Processing Tape File: DB Disk Volumes
      Processing Tape File: DB Tape Volumes
   Positioning tape to Backup Data
   Processing Backup Data
      Processing Tape File: Space Info Vol 1
      Processing Tape File: Block Info Vol 1
      Processing Tape File: Block Data Vol 1
      Processing Tape File: Space Info Vol 2
      Processing Tape File: Block Info Vol 2
      Processing Tape File: Block Data Vol 2
   
   ====>> SYSTEM % RECOVERY <<====
   
   Please Dismount Tape on Drive 0
     (Kind of Tape    => CHAINED_ANSI,
      Volume Id       => 028600,
      Volume Set Name => BACKUP, 09-MAR-01 16:01:45 3)
   
   ====>> Recovery <<====
   Tape Processing Complete.
   Restoring Data
   Restoring Spaces
   Taking 1st snapshot
   
   ====>> CONFIGURATOR <<====
   starting snapshot
   snapshot is finished
   
   ====>> Recovery <<====
   Updating Databases
   Taking 2nd snapshot
   
   ====>> CONFIGURATOR <<====
   starting snapshot
   snapshot is finished
   
   ====>> Recovery <<====
   Recovery Is Complete
   Garbage Collection can't run until the machine is rebooted
   Rebooting to enable Garbage Collection
   
   ====>> CONFIGURATOR <<====
   starting virtual memory shutdown
   starting snapshot
   snapshot is finished
   virtual memory shutdown at ( 3, 26-MAR-01 04:22:46)
   system shutdown is complete
   
   ***************************************
   Sequencer has detected a machine check.
   
   ************************************************
   Booting R1000 IOP after R1000 Halt or Machine Check detected
     Boot Reason code = 0C, from PC 0001ADA2
   
   Restarting R1000-400S March 26th, 1901 at 04:23:01
   
   OPERATOR MODE MENU - options are:
       1 => Change BOOT/CRASH/MAINTENANCE options
       2 => Change IOP CONFIGURATION
       3 => Enable manual crash debugging (EXPERTS ONLY)
       4 => Boot IOP, prompting for tape or disk
       5 => Boot SYSTEM
   
   Enter option [Boot SYSTEM] :

The disks were formatted yesterday, so I do not have a total time for the restore, but reading the backup tape took 7 hours.

2019-11-13

Tried if the R1000 would accept a SCSI2S without much luck.

The RESHA EEPROM issues the usual terse style error message saying simply "SCSI Error", giving no usable details.

Formatted the Seagate disks so they are ready for an attempt to restore from the Backup-Tape.

If the SCSI2SD is in the machine along with disks, some DFS operations work, but since no defect list can be read, preparing the disk fails.

The two Fujitsu disks with the working image was never powered up today.

/phk

2019-10-29

R1000-400 with Facit.jpg

R1000-400 with Facit A-4600 terminal showing the Rational Environment. Note the keyboard overlay that extends a couple of inches beyond the keyboard.


Keyboard Overlay.jpg

Keyboard overlay for the Rational Environment.


R1000-400 Front plate.jpg

The front plate of a running R1000-400. ==

2019-10-28

The world has a running Rational R1000/400 computer again:

R1000 runs.png

Thanks a LOT to Pierre-Alain Muller for driving all the way here to help make this happen!

2019-10-24

On suggestion by Pierre-Alain todays aim was an FRU diagnostics.

First the faulty Fujitsu disk was removed and the Seagate promoted to SCSI ID 0.

Then we got a "File does not exist HARDWARE.M200_CONFIG". M200, hmm... - We did the following:

  OPERATOR MODE MENU - options are:
      1 => Change BOOT/CRASH/MAINTENANCE options
      2 => Change IOP CONFIGURATION
      3 => Enable manual crash debugging (EXPERTS ONLY)
      4 => Boot IOP, prompting for tape or disk
      5 => Boot SYSTEM
  
  Enter option [Boot SYSTEM] : 1
  Enable Modem DIALOUT [N] ? 
  Enable Modem ANSWER [N] ? 
  Enable IOP (IOC 68K) Auto Boot [N] ? y
  Enable R1000 CPU Auto Boot [N] ? n
  Enable AUTO CRASH RECOVERY [N] ? y
  Enable CONSOLE BREAK KEY [N] ? y
  Are these new defaults [N] ? y

then

  CLI/CRASH MENU - options are:
    1 => enter CLI
    2 => make a CRASHDUMP tape
    3 => display CRASH INFO
    4 => Boot DDC configuration
    5 => Boot EEDB configuration
    6 => Boot STANDARD configuration
  Enter option [Boot EEDB configuration] : 1
  CLI> x cedit
  Change hardware configuration [N] ? y
  File does not exist HARDWARE.M200_CONFIG
  Does this processor have 32 MB memory boards [Y] ? 
  NOTE: 32 MB boards must be installed as MEM 0 or MEM 2 only.
        8 MB boards cannot be in the same CPU as 32 MB boards.
  Does memory board 0 exist [Y] ? y
  Does memory board 2 exist [Y] ? n
  CLI> x expmon
  0  32MB MEMORY BOARDS IN PROCESSOR - TOTAL OF 0 MEGABYTES. 
  EM> bye
  CLI> quit

At this point we rebooted, but the memory board was still not detected. We then decided to take all 8 boards out of the machine starting with the two MEM 0/2 boards, photographing and then re-seating them. The 2 memory boards looked identical, so we switched their position. At the following boot we got: "Memory 2 exists but is not in configuration. Board will not be used.", so we changed the HW config again and included both MEM boards. We don't believe the changed positions did anything, but perhaps the power-cycle was needed to get them detected right?!

At this point we attempted the FRU-diagnostics:

  CLI> x expmon
  2  32MB MEMORY BOARDS IN PROCESSOR - TOTAL OF 64 MEGABYTES. 
  EM> rd
  ...
  EM> poll_all
  NO MACHINE CHECKS DETECTED 
  EM> poll_all
  SEQ HAS DETECTED A MACHINE CHECK 
  EM> sm
  ...
  UCODE HALT AT 0102 
  ...
  EM> bye
  CLI> 
  CLI> x rdiag
  ...
  DIAG> test/3 all
  Running FRU P1DCOMM
  Running FRU P1IOC
  Running FRU P1VAL
  Running FRU P1TYP
  Running FRU P1SEQ
  Running FRU P1FIU
  Running FRU P1MEM
  Running FRU P1SF
  Running FRU P2IOC
  Running FRU P2VAL
    Loading from file PHASE2_MULT_TEST.M200_UCODE  bound on July 16, 1986  14:31:44
    Loading Register Files and Dispatch Rams .... [OK]
    Loading Control Store  [OK]
  Running FRU P2TYP
  Running FRU P2SEQ
  Running FRU P2FIU
  Running FRU P2MEM
  Running FRU P2UADR
  Running FRU P2FP
    Loading from file FPTEST.M200_UCODE  bound on January 29, 1990 17:26:52
    Loading Register Files and Dispatch Rams .... [OK]
    Loading Control Store  [OK]
  Running FRU P2EVNT
  Running FRU P2STOP
  Running FRU P2ABUS
    Loading from file ABUS_TEST.M200_UCODE  bound on July 22, 1986  13:27:21
    Loading Register Files and Dispatch Rams .... [OK]
    Loading Control Store  [OK]
  Running FRU P2CSA
  Running FRU P2MM
  Running FRU P2COND
  Running FRU P2UCODE
    Loading from file P2UCODE.M200_UCODE  bound on August 6, 1986  16:16:27
    Loading Register Files and Dispatch Rams .... [OK]
    Loading Control Store .......... [OK]
  Running FRU P3RAMS
  Running FRU P3UCODE
    Loading from file P3UCODE.M200_UCODE  bound on August 6, 1986  13:50:42
    Loading Register Files and Dispatch Rams .... [OK]
    Loading Control Store . [OK]
  PASSED

"PASSED"!!!

And a bit later the following line:

  Starting R1000 Environment - it now owns this console.

Cleaned up log from the most interesting part of the session: Fil:20191024 1915 R1000.pdf

2019-10-17

Peter has returned with a working PSU :-) - The R1000 is now up and running again drawing 155 amps.

Almost full log of the session: Fil:20191017 1954 R1000.pdf

The Fujitsu 2266 disk appears to be faulty, R1000 complains about disk errors (our old acquaintance General Error?):

  Options are:                                                                          
      0 => Exit                                                                         
      1 => Initialize disk (for experts only)
      2 => Initialize disk, drop USR defects (internal use only)
      3 => Show MFG and USR bad block locations
      4 => Show only USR bad block locations
      5 => Install new DFS only
      6 => Show bad block count and DOS limits
  Enter option : 3
  Enter unit number of disk to format/build/scan (usually 0) : 0
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=4038 CS2=0040 DS=11C0 ER1=0000 ER2=0000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  CS1=0038 CS2=0040 DS=11C0 ER1=0100 ER2=4000 EC1=0000 EC2=0000 DC=0000 DA=0005
  ** ABORT: Can't retrieve labels due to disk errors.

A Seagate ST41200N is now installed as DISK 1, the Fujitsu remains as DISK 0 for now. R1000 recognizes the Seagate but wants to format it:

  Initializing M400S I/O Processor Kernel 4_2_16
  Spinning up disk 1
  Spinning up disk 0
  Disk  1 is ONLINE and WRITE ENABLED
  IOP Kernel is initialized
  Enable line printer for console output [N] ? 
      RECOVERY 14.04 92/09/17 10:00:00\
  Options are:
      0 => Exit
      1 => Initialize disk (for experts only)
      2 => Initialize disk, drop USR defects (internal use only)
      3 => Show MFG and USR bad block locations
      4 => Show only USR bad block locations
      5 => Install new DFS only
      6 => Show bad block count and DOS limits
  Enter option : 3
  Enter unit number of disk to format/build/scan (usually 0) : 1
  ** ABORT: Disk has no labels.
  Options are:
      0 => Exit
      1 => Initialize disk (for experts only)
      2 => Initialize disk, drop USR defects (internal use only)
      3 => Show MFG and USR bad block locations
      4 => Show only USR bad block locations
      5 => Install new DFS only
      6 => Show bad block count and DOS limits
  Enter option : 1
  Enter unit number of disk to format/build/scan (usually 0) : 1
  Disk has no labels.
  Drive types are:
      1 - Fujitsu 2263
      2 - Fujitsu 2266
      3 - SEGATE ST41200N
      0 - Other
  Enter drive type : 3
  Enter HDA serial number : TJ617458
  Disk must be formated.
  Formatting the drive will take about 35 minutes.
  Elapsed time is 00:32:32
  Writing bad block information.
  Writing boot label.
  Writing DFS label.
  Do you want to build a diagnostic file system on this unit [Y] ? 
  Enter last cylinder to be used by the DFS [ Hint => 76 ]:76
  Enter first cylinder to be used for read/write diagnostics [ Hint => 1889 ]:1889
  Writing shared label.
  Constructing free list.
  Writing free list.
  Allocating and initializing directory.
  Creating predefined files.
  KERNEL_0.M200
  KERNEL_1.M200
  KERNEL_2.M200
  FS_0.M200
  FS_1.M200
  FS_2.M200
  PROGRAM_0.M200
  PROGRAM_1.M200
  PROGRAM_2.M200
  DFS_BOOTSTRAP.M200
  ERROR_LOG
  Do you want to load files into the DFS on this unit [Y] ? y
  Tape drive unit number : 0
  Do you want to display filenames as they are loaded [Y] ? y
  Reading -> DFS_BOOTSTRAP.M200
  Reading -> KERNEL_0.M200
  ... 3160 files later ...
  Reading -> DDC.M200_CONFIG
  Elapsed time is 00:10:40
  Options are:
      0 => Exit
      1 => Initialize disk (for experts only)
      2 => Initialize disk, drop USR defects (internal use only)
      3 => Show MFG and USR bad block locations
      4 => Show only USR bad block locations
      5 => Install new DFS only
      6 => Show bad block count and DOS limits
  Enter option : 0
  Boot disk has been rebuilt or the IOP was booted from tape.
  You must crash the machine to exit.

Next week, boot from disk and see how far we get. PSU got *hot*, but survived the 1½ hour session.

2019-10-03

After rumaging through our entire workshop, it transpires that we have no solder-iron with sufficient power to unsolder the capacitors from the thick copper on the PCB.

One of our members, Peter, has offered to attempt the repair in his own workshop, and he picked it up tonight.

2019-09-12

PSU dismantled, and the visible defective Electrolyte has been soldered out together with two Tantalum. Unfortunately, when mounted, the leads were pinched and cut, making them difficult to pull through the PCB today since the holes are almost exactly the size of the leads. The insulation on the wires to the transformer has deteriorated quite a bit and will need some repair.

Some better images of the PSU as a whole:

R1000 PSU Overview.jpg

Overview


R1000 PSU Side 1.jpg

One half of the PSU


R1000 PSU Side 2.jpg

Other half of the PSU


R1000 PSU degraded isolation.jpg

Defect insulation on some wires


R1000 PSU capacitor side.jpg

One of the two capacitor boards on the 5V rails.


R1000 PSU capacitor PCB.jpg

Backside of PCB carrying the damaged capacitor.



Each of the two PCBs carry: 5 Tantalum capacitors 15µF, and 5 6800µF SXF 30mm x 18mm, lead spacing 7.5mm

2019-09-05

Arriving today, expecting a fight, armed with various debugging plans, the Rational just started, booted and were happy as could be?!? - After some configuration, and booting the kernel "M400S_KERNEL_0.M200" (thanks to Pierre-Alain for supplying that information), the R1000 now responds with:

   R1000-400 IOC SELFTEST 1.3.2 
      512 KB memory ... [OK]
      Memory parity ... [OK]
      I/O bus control ... [OK]
      I/O bus map ... [OK]
      I/O bus map parity ... [OK]
      I/O bus transactions ... [OK]
      PIT ... [OK]
      Modem DUART channel ... [OK]
      Diagnostic DUART channel ... [OK]
      Clock / Calendar ... [OK]
  Checking for RESHA board
      RESHA EEProm Interface ... [OK]
  Downloading RESHA EEProm 0 - TEST
  Downloading RESHA EEProm 1 - LANCE 
  Downloading RESHA EEProm 2 - DISK  
  Downloading RESHA EEProm 3 - TAPE  
      DIAGNOSTIC MODEM ... DISABLED
      RESHA VME sub-tests ... [OK]
      LANCE chip Selftest ... [OK]
      RESHA DISK SCSI sub-tests ... [OK]
      RESHA TAPE SCSI sub-tests ... [OK]
      Local interrupts ... [OK]
      Illegal reference protection ... [OK]
      I/O bus parity ... [OK]
      I/O bus spurious interrupts ... [OK]
      Temperature sensors ... [OK]
      IOC diagnostic processor ... [OK]
      Power margining ... [OK]
      Clock margining ... [OK]
  Selftest passed
  
  Restarting R1000-400S January 14th, 1901 at 22:56:43
  
  OPERATOR MODE MENU - options are:
      1 => Change BOOT/CRASH/MAINTENANCE options
      2 => Change IOP CONFIGURATION
      3 => Enable manual crash debugging (EXPERTS ONLY)
      4 => Boot IOP, prompting for tape or disk
      5 => Boot SYSTEM
  
  Enter option [Boot SYSTEM] : 5
  
  Logical tape drive 0 is an 8mm cartridge tape drive.
  Logical tape drive 1 is declared non-existent.
  Logical tape drive 2 is declared non-existent.
  Logical tape drive 3 is declared non-existent.
  Booting I/O Processor with Bootstrap version 0.4
  
  Boot from (Tn or Dn)  [D0] : T0
  
  Tape_Boot_1.2.0  920401
  Waiting for tape unit ready.
  Strike any key to abort.....................
  End of Tape Reached.rewinding
  
  Select files to boot [D=DEFAULT, O=OPERATOR_SUPPLIED] : [D]
  Skipping..
  Loading FS_0.M200
  
  Loading RECOVERY.M200
  Skipping.................
  Loading M400S_KERNEL_0.M200
  
  Initializing M400S I/O Processor Kernel 4_2_16
  Spinning up disk 0
  IOP Kernel is initialized
  Enable line printer for console output [N] ? 
      RECOVERY 14.04 92/09/17 10:00:00\
  Options are:
      0 => Exit
      1 => Initialize disk (for experts only)
      2 => Initialize disk, drop USR defects (internal use only)
      3 => Show MFG and USR bad block locations
      4 => Show only USR bad block locations
      5 => Install new DFS only
      6 => Show bad block count and DOS limits
  Enter option : 
  *** AC power is L

The last line is probably from the time where I cut the power after seeing significant white-gray smoke coming up from the machine...

The following smell-test suggested that the PSU should be checked:

R1000 PSU Broken Cap.jpg

The capacitors are located between the 5V power rails (the two black blocks on each side of the cap).

Next job: Acquire and exchange 10 x 6800µF 6.3V capacitors (L<31, D<=18)

2019-08-29

Disappointment! - We had hoped to get further in the boot process, but met an "unwilling" machine that didn't even presented itself. The PSU powered up with its fan, but that was it - No lights, no 5V, -12V or +12V. During power-off, these lights turned for a very short period, indicating the PSU is capable but unwilling (Inhibit line active?). We are not completely sure of the reason, but we will debug the issue next week, starting with checking the RESHA diagrams, followed up by checking the IOC RTC-battery (which were replaced last week).

2019-08-22

After further tests we finally took the leap and grabbed the cutter and solder iron, and replaced the three suspected memory chips. Boot sequence with the original BIOS now gives:

   R1000-400 IOC SELFTEST 1.3.2 
      512 KB memory ... [OK]
      Memory parity ... [OK]
      I/O bus control ... [OK]
      I/O bus map ... [OK]
      I/O bus map parity ... [OK]
      I/O bus transactions ... [OK]
      PIT ... [OK]
      Modem DUART channel ... [OK]
      Diagnostic DUART channel ... [OK]
      Clock / Calendar ... [OK]
  Checking for RESHA board
    --  Bench mode (ID 7) detected Skipping RESHA tests
      Local interrupts ... [OK]
      Illegal reference protection ... [OK]
      I/O bus parity ... [OK]
      I/O bus spurious interrupts ... [OK]
      Temperature sensors ... [OK]
      IOC diagnostic processor ... [OK]
      Power margining ... [OK]
      Clock margining ... [OK]
  Selftest passed
  
  Restarting R1000-400S January 1st, 1901 at 00:03:56
  
  Logical tape drive 0 is an 8mm cartridge tape drive.
  Logical tape drive 1 is declared non-existent.
  Logical tape drive 2 is declared non-existent.
  Logical tape drive 3 is declared non-existent.
  Booting I/O Processor with Bootstrap version 0.4
  
  Boot from (Tn or Dn)  [D0] : 

Success!

Next step: Mount the board into its rightful place and see how far it gets now...

2019-06-06

Decided to make further measurements with the oscilloscope in order to rule out other causes. Probing all pins on a good and a bad RAM chip did not reveal anything.

Tried to piggyback H11 with a new RAM-chip, and the questionable bit went mid between VCC and GND. It could be that the good chip tried to pull down while the bad chip pulled up. Double-checked chip-select on H3, the only other identified chip that may drive the same data line (D30), and chip-select is completely passive during the troublesome period.

Previous tests went between [0x00000000..0x00040000[ and [0x00040000..0x00080000[. Now tried to run the tests between [0x00001000..0x00021000[ and [0x00041000..0x00061000[ as well as between [0x00001200..0x00021200[ and [0x00041200..0x00061200[ to test whether run-length could be a factor. The exact same failing addresses indicate run-length is not a factor.

Tried a reverse scan, Set(addr), Clr(addr), Set(addr) then Get(addr-4). The same data bits are affected in both banks, but the failing addresses are not identical. Some patterns are similar, and some other patterns appears.

Tried another test with: Set(addr), Clr(addr), Set(addr), Get(addr+4), branch-test delay, then another Get(addr+4) - The second Get reads out correctly. this indicates that the chip does have the right value, but that it is incorrectly read out in some circumstances.

2019-05-23

Previous software tests indicated problems with certain bits at some address patterns: Bits 7 and 23 in the low bank and bit 30 in the high bank showed issues. The fault manifests itself at some addresses when the following memory accesses are done in quick succession: Set(addr), Clr(addr), Set(addr) then Get(addr+4) - The Get(addr+4) returns incorrect values only on these bits.

Today all RAM chips were checked with oscilloscope to verify and possibly identify the problem. H11, G10 and G41 showed different behavior on the oscilloscope, and these chips happens to map to the exact bits identified at the software test.

H40 did show a little flickering on the DC levels, but the flanks seemed OK.

The above input to the RAM-chips looks like this:

R1000 RAM Input.jpg

The output of a healthy chip looks like this:

R1000 RAM Output Healthy.jpg

The output of the sick chips looks like this:

R1000 RAM Output Sick.jpg


Next step will be to replace them. We have replacements ready, so stay tuned...

2019-03-07

Tried to patch the EEPROM in various ways, and learned a lot more.

If we skip the offending memory check, (and the EEPROM checksum because we're lazy) we get all the way to the boot device prompt (tape/disk).

We got two-way serial connection to the console port: TX is TTL level, RX is RS-232 level.

In trivial homebrew tests, the RAM does not fail, but what we call "ramtest_5" repeatedly does.

Big discovery of the night: The two top address bits of the EEPROM are swapped on the PCB, so the middle two quarters are swapped in the image we try to reverse-engineer. After fixing that, the contents make a lot more sense.

2019-02-28

Managed to power up the IOC board stand-alone. 5V @ 35A required (30A didn't seem to be quite enough).

Procedure:

  1. 5V @ 35A connected to 3 Capacitors at edge (to distribute load).
  2. Reset (GB113) to Ground (page 23 of R1000_SCHEM_IOC.pdf).
  3. CTS# (GB055) to 5V (page 25)
  4. Power On
  5. Release Reset (GB113)

TTL Serial output read from CPDRV0 @N1 (pin 2 or 3).

As expected output is still:

  R1000-400 IOC SELFTEST 1.3.2 
     512 KB memory ... * * * * * * * FAILED

EEPROM 28256 is not compatible with EPROM 27256!

2013-06-27

More email exchanges with Greg Bek and Michael Druke, both ex-Rational people.

Our IOC board does actually have 72 64K*1 DRAM chips, four banks of 18 chips.

Read the EEPROM from the IOC board, and have started disassembling the self-test code, to find out what it actually does.

Powered up with only IOC and RESHA boards seated, same result, which at least means that we can test in that config.

Also tried powering the IOC board up out of the cage, but our +5V supply can only deliver 7 Ampere, and that's not enough.


2013-06-20

Greg Bek replied to email and told me I was looking at the wrong 68k processor: The daughterboard on the RESHA is just for TCP/IP.

The failing RAM test is the 68k on the IOC board.

Opened the cardcage and where this label greets you:

R1000 Cardcage Label.png

Visual inspection of the IOC revealed nothing of notice.

Changed the Lithium battery which is used for the RTC.

Gently reseated all socketed chips on the IOC.

Gently reseated all the other cards in the card cage.

Still fails RAM test.

The IOC Schematic manual mentions a low-level debugger, but it seems to require RAM test to pass before you can enter it.

ID-information on the IOC:

R1000 IOC ID1.png R1000 IOC ID2.png R1000 IOC ID3.png

2013-06-13

Finally!

Our workshop area has been rearranged, the GIER computer moved and I could finally uncrate the R1000s400.

After a visual inspection, I did "the smoke-test" and can happily report that the smoke stayed inside.

Unfortunately, we don't get very far in the boot sequence:

  R1000-400 IOC SELFTEST 1.3.2 
     512 KB memory ... * * * * * * * FAILED

This is 512KB DRAM memory on a small daughterboard on a CMC ENP100 VME board mounted on the RESHA board:

R1000 RESHA.png

I have tried various obvious remedies, reseating connectors etc, but to no avail.

2013-04-05

A few small details have to fall into place before I can start to power up the machine: Our new workshop area is done now, and the last missing bit is the rearranging the power-circuits.

In the meantime scanning of documentation progresses about a binder per week or so, and should be complete before summer.

2012-09-27

Scanned in the "Guru Course" material while hosting COMAL kickoff meeting. Sheet-feeding scanners are a good thing.

I have started a new wiki page for the documentation: Rational/R1000s400/Documentation

2012-08-30

The 8200 Ole brought was from an IBM RS/6000, and either because of special firmware/settings or fault on that drive, it refused to do anything more advanced than a SCSI Inquiry and Test-Unit-Ready.

In the end I wrote a set of tapes on the known-suspect 8200 drive, and test-read them on the known-good 8505 drive with success.

I have now, finally, convinced myself that I have written good copies of Pierre-Alains tapes, and more importantly, that I can do so again, if the Exabyte drive in the R1000 cannot read them for reasons of alignment etc.

Received email from Grek Bek with answers to a lot of my questions, so now next thing on the program is to find a corner with power and space to set up the machine. This probably involves moving other stuff out of the way, so it may take some weeks.

2012-08-16

Read Pierre-Alains original tapes on the EXB-8505 drive, and got the exact same result as the read on the EXB-8200 drive, so now the originals can go back to Pierre-Alain.

Failed utterly to make 8200 read a tape written on the 8505.

Ole has promised to bring in a known good 8200 drive, that will be next attempt.

2012-08-09

Spent tonight trying to write copies of the tapes I read last thursday.

The Exabyte 8200 drive I have used has clearly shown itself to be faulty, or at the very least flakey.

Tried using a 8505 drive instead, but worry that it may have used compression while writing the tapes.

Plan:

1. Re-read Pierre-Alains tapes with 8505 to check that on-disk copy is a good read. I have no reason to doubt this, based on my analysis, but I want to be 100% sure before I return the tapes to Pierre-Alain.

2. Try to read the tapes I wrote tonight with flakey 8200 drive. If it can read (some of) them, they are not compressed.

2012-08-02

Tonight I set up a FreeBSD computer with an ExaByte 8200 tapedrive, and used it to read the three tapes Pierre-Alain Muller mailed me last month.

The tapes have a rather complex block structure, and I have read them in using a program which also stores the information about block-sizes, tape-marks etc, so that it should be possible to write exact copies of the tapes to install from.

The result are three files:

 -rw-r--r--  1 phk   wheel  41837637 Aug  2 18:19 20120802_R1000_CATALOG
 -rw-r--r--  1 phk   wheel  13141316 Aug  2 18:20 20120802_R1000_DFS
 -rw-r--r--  1 phk   wheel  78362000 Aug  2 18:23 20120802_R1000_ENVIRONMENT
 MD5 (20120802_R1000_CATALOG) = 6102fb4c10fa580af4fb0e508cfd4127
 MD5 (20120802_R1000_DFS) = 5e61879f066484cacdd1e895cea65b41
 MD5 (20120802_R1000_ENVIRONMENT) = dce495e2b575e8aeae3da79e9fce8074

Many thanks to

  • Erlo Haugen
  • Grady Booch
  • Grek Bek
  • Pierre-Alain Muller
  • Pascal Leroy