Groups | Search | Server Info | Login | Register
Re: I could use a hand locating hardware bits and pieces and/or technical documentation for repair.

Newsgroups	comp.sys.3b1
Date	2015-12-23 05:30 -0800
References	(1 earlier) <54468d59-7b83-4211-8f4c-5d8dd4be215b@googlegroups.com> <f6403a08-7703-4361-be99-91ffe9aa5de0@googlegroups.com> <slrnn7hgfe.lon.BPdnicholsBP@Katana.d-and-d.com> <aaa27f8d-040f-457e-8110-820a7668ff44@googlegroups.com> <slrnn7k4au.4ih.BPdnicholsBP@Katana.d-and-d.com>
Message-ID	<3a23c091-ca01-4720-90fd-c7230d20a3aa@googlegroups.com> (permalink)
Subject	Re: I could use a hand locating hardware bits and pieces and/or technical documentation for repair.
From	Peter Schmidt <peterhschmidt@gmail.com>
Show all headers | View raw
Sorry I don't have it handy to paste in right now, but I wrote a shell script to set the date semi-automatically.  

The trick is, the system is perfectly happy to roll the date over from 1999-12-31-23:59 to 2000-01-01-00:00, and to do that again from 2000-12-31-23:59 to 2001-01-01-00:00, etc.  And, you can change the date within a given year by not specifying the year value.  

So the shell script takes a single argument, an integer which is the last two digits of the current year in the 21st century, sets the date to 1999-12-31:23:59, sleeps for 62 seconds to ensure the rollover (since the 3.51m date command doesn't allow specifying the seconds), and then loops through the process of setting the date to the last minute of the year, sleeping for 62s, and doing it again until we get to the current year.

Whereupon I manually set the current day and time.

Someday I'll put a new RTC battery in it...

--Peter

On Tuesday, December 22, 2015 at 10:13:53 PM UTC-5, DoN. Nichols wrote:
> On 2015-12-22, Chris Smith <protheus@byteorder.net> wrote:
> > On Monday, December 21, 2015 at 9:23:28 PM UTC-6, DoN. Nichols wrote:
> 
> 	[ ... ]
> 
> >> 	To do the SMDs I would suggest that the things to have would be
> >> at a minimum a stereo-zoom microscope (7X to 30X) and a good
> >> well-regulated soldering iron with a tiny tip.
> 
> > I'd be tempted to try it myself, depending on the surface mount parts.
> > I'm not terrible at hand-soldering surface mount parts.  Best I've done
> > so far is 28 pins at .65mm pitch... on the soldering station at home,
> > which has a not-too-small wedge tip.  I'll probably buy something a bit
> > higher precision for it at some point.
> 
> 	O.K.  One benefit of the stereo zoom microscope would be the
> ability to examine for solder bridges between adjacent pins.
> 
> >> 	It looks as though the earlier version of the board was tested
> >> with a 3B1 with the standard WD-1010 chip in it -- but no idea about the
> >> modified ones with the WD-2010, which allows drives with more than eight
> >> heads and more than 1024 cylinders to be used.  My 3B1s have that
> >> modification plus the modification to allow a second drive to be
> >> connected externally.  This takes the maximum drive size from something
> >> like 67 MB (as seen by the 3B1) to IIRC 190 MB or so. (the biggest MFM
> >> Maxtor and a Piram drive with the same parameters.)
> 
> > I wasn't aware that these modifications existed.  My system has been
> > worked on before I got it, so I suppose I can't be absolutely sure
> > whether it is modified in that respect.
> 
> 	The first thing to check would be the chip in the socket for the
> WD-1010.  If it is a WD-2010, then the board has at least been modified
> to allow more than 1024 cylinders (a limitation on the WD-1010 chip).
> If there are also extra wires in the area near where the data and
> control cables plug in from the hard drive, then it is likely that it
> was also modified to allow more than 8 heads, and a second drive.  (Look
> for the ICUS modification data in the download sources to find out how,
> but details can vary from system to system.  I avoided using a board
> with extra parts, and instead located a spare 20-pin socket layout on
> the board (different locations with different versions of the board),
> and with a bit of trace surgery was able to use the existing
> differential driver and receiver chips for data to/from the second
> drive.  (I also did a bit of other tricky work to get both data paths
> through a single ribbon cable, and put both drives in an external
> housing (originally for a 3B2 computer, so the color scheme matched).
> Also a little tricky bit to use the 5V for the internal drive to turn on
> the power supply in the external housing, so I did not have to switch it
> separately.  Obviously, for systems modified the way I did it, the
> location of the spare 20-pin socket lead layout would be somewhat
> different for different versions of the motherboard.
> 
> >                                          I think the cooling fans were
> > replaced, though,
> 
> 	Different versions of the machine (at least different between
> the 7300 and the 3B1 (half-height vs full-height hard drive) have
> different fan setups.  IIRC, the 7300 came with two fans, and the 3B1
> had one fan replaced with a block of foam rubber.
> 
> >                   and since you mention it -- I didn't double check when
> > I had the system open the other day -- I also think there was a battery
> > holder.
> 
> 	That makes life easier.  Of course, the existing date(1)
> program would not allow setting the date to beyond the last day of 1999.
> My work-around when I had to deal with it for a while after that period
> (helping recover data from someone else's failing disk drives) was to
> write two simple programs -- one on a Sun workstation which printed the
> date in the numeric format (the 32-bit number which keeps the number of
> seconds since the first moment of 1970 GMT), and the other on the 3B1
> which sets the time by force-feeding it that same number.
> 
> 	The first one is run like this:
> 
>  ======================================================================
> Katana:csu 21:50:27 # ./int-date
> 1450839186
>  ======================================================================
> 
> and the second wants the number from the first on the command line to
> set it in the 3B1.
> 
> The first looks like this:
> 
>  ======================================================================
> /* print the date in raw integer format */
> #include <stdio.h>
> #include <sys/types.h>
> #include <time.h>
>           
> main ()
> {
> 
>    time_t   now,
>             time();
> 
>    time(&now);
> 
>    printf ("%d\n", now);
> 
> }
>  ======================================================================
> 
> and the second, like this:
> 
>  ======================================================================
> /*
>  * program to set the system time from an integer string from the time
> of
>  * another system until I can build a date command on this ancient
> system
>  * which understands Y2K values. 
>  *
>  * DoN. -- Sun May 13 21:29:45 EDT 2007
>  */
> 
> #include <stdio.h>
> int     stime();
> 
> main (argc, argv)
> int     argc;
> char    *argv[];
> {
>         long    newtime,
>                 *tp,
>                 resultcode;
> 
>         tp = &newtime;
> 
>         if ( argc < 2 ) {
>                 fprintf( stderr,  "I need a time integer string\!\n");
>                 exit (-1);
>         }
> 
>         resultcode = sscanf (argv[1], "%d", tp);
>         if (resultcode == 1) {
>                 stime (tp);
>         } else {
>                 fprintf (stderr, "Conversion failed\!");
>                 exit (1);
>         }
> }
>  ======================================================================
> 
> 	These allow you to set the current time onto the system, even
> though you are well into Y2K.  However, the libraries will have things
> like the start and end of DAT wrong, since they have been changed at
> least twice since the system was made. :-)
> 
> 	An older version of the "localtime" libraries could be compiled
> on the 3B1 and used to fix all locally-compiled programs.  To fix the
> rest would require re-building the shared libs to include the new
> routines.  I seem to remember that more recent versions of the
> localtime libs would not compile on the 3B1, but the old ones would.
> THe ones which I have a copy of are from 1991, and would need updating
> in the database, but otherwise should work.
> 
> 	And -- since it was purely on an internal net, I was willing to
> enable rsh and the like on the 3B1, so this script would set the time:
> 
>  ======================================================================
> #!/bin/zsh
> #
> # First -- compile idate on the 3B1, and install it in the
> /usr/local/bin
> # directory -- or elsewhere with proper adjustment to the command line.
> #
> # Second -- compile int-date on the time donor system, and put it somewhere
> #       in your path.  (Sources for both are present here.)
> #
> # Third -- make sure that the donor system and user are in /.rhosts
> #       on the 3B1.
> #
> echo -n "The old date on Feis is: "
> rsh feis date
> #
> # Then execute the following script to set the correct date/time on the
> #       3B1:
> rsh feis /usr/local/bin/idate `int-date`
> #
> # And the following (optional) command to verify that the date took correctly.
> #
> echo -n "The new date on Feis is: "
> rsh feis date
> #
> # And this one (on the local system to show how much time skew there is
> #       from leapseconds treatment and such.
> #
> echo -n "And the current date on the current host is: "
> date
>  ======================================================================
> 
> 	Note, BTW, that there is no way to compile the "ping" command to
> work on the 3B1, even if you have the ethernet board and software.
> There is no micro-time call in the system, and that is needed for ping
> to work :-(
> 
> 	Good Luck,
> 		DoN.
> 
> -- 
>                   Remove oil spill source from e-mail
> Email: <BPdnicholsBP@d-and-d.com> | (KV4PH) Voice (all times): (703) 938-4564
>    (too) near Washington D.C.     | http://www.d-and-d.com/dnichols/DoN.html
>            --- Black Holes are where God is dividing by zero ---
Back to comp.sys.3b1 | Previous | Next — Previous in thread | Next in thread | Find similar
Thread

csiph-web