Thursday, September 22, 2016

Cromemco Millennium Bug





Can you really use a computer where the date, and perhaps the time is wrong?

Well try it.  I'd argue not.  But that's the current dilemma I am facing whilst trying to restore and use my Cromemco 68020 processor system, running the Cromix 172XXU Operating System.

Setting the Date and Time

Under Cromix from the command line you must use the time command and the time -s to set.  Unfortunately you must use console input so here are some examples


Setting time to 1995 works fine



Here is the time command help



Setting the time to 2016 does not work so well!


Trying a Rollover

After midnight on Dec 31 1999 the time jumps to Feb 6, 2036 !!


I tried a C program
Getting the C compiler to work was non trivial.  Well because it was designed for the 68010 Operating System not the 68020 one.  Oh and the docs describing the Linker options were well, wrong (and this was a late revision of the manual.  Tut tut)

 ty sd.c
#include <jsysequ.h>
#include <syslib.h>
#include <stdio.h>

main()
{
int rc;
unsigned int year;
struct sys_date mydate;
int sigmask=0, sigvalues=0;

char cmdline [20] [80];
strcpy ( cmdline [0], "sh");
strcpy ( cmdline [1], "-c");
strcpy ( cmdline [2], "/bin/time.bin");
strcpy ( cmdline [3], NULL );

printf ("cmdline0 was %s\n", cmdline[0] );

for ( year=0; year <=255; year++)
  {
  mydate.month=9;
  mydate.day=23;
  mydate.year= year;
  rc=setdate(&mydate);

  printf ( "Year %u, return code %d\n", year, rc);
/* no worky   rc=fshell (cmdline, sigmask, sigvalues);
  printf ("rc was %d\n", rc );
*/

  }

}





I was able to determine that the full range of character based input for the year which might logically viewed as an unsigned integer 0-255 were not accepted.  The results are

00-59 BAD
60-195 GOOD
196-255 BAD


68000 Assembler Interface



 I wrote and then assembled a 68000 Assembler program for 2015.  Works!

 ty sdate.asm
*INCLUDE '/equ/jsysequ.asm'


START:
      move #116, D1   ; year 116 for 2016
      move #09,  D2   ; month 9 september
      move #23,  D3   ; day is 23 decimal
      jsys #_setdate

      move #0,   D3
      jsys #_exit

      END START


system[74] /usr/pkg/asmd/asm68 sdate.asm
Cromemco 68000 Assembler version 01.15

Assembling: sdate.asm


Free memory = 27632

0 error(s)

system[75] /usr/pkg/asmd/link68 sdate

68010 XPU 167   Link68 source 1.32
sdate        sdate                     000000 000018  RWE

  0 multiply defined symbol(s)
  0 unknown symbol(s)

Address    Size     Attributes
000000     000018     RWE

Starting address: 000000
system[76] ./sdate
system[77] time
       Wednesday, October 29, 2036            20:10:34

As you can see when I change the assembler to ask to set the date to 2016, things go to pot :-(



Z80 Cromix Call




CDOS Z80 Assembler Interface

Hand Assemble A Z80 program
Since I still remember Z80 assembler I tried writing a privileged program in machine code  (there is no equivalent on the native 68000 processor).   There is a Z80 coprocessor card to execute Z80 instructions

2015 works ... wahoo!

But asking for year 2016 results in year 2036 and a mashed up time and month etc :-(





fshell does not work (for me)



Cromix does not have the equivalent of the Linux system() call and so you need to use fshell or fexec.  Unfortunately I did not get it working.  Bear in mind the C compiler I was using does not allow C99  or modern array assignment so it could well be my code.  Or alternatively bad sigmask and sigvalues since I could not find any guidance, despite match (Cromix version of UNIX grep) all the .h files I could find in /usr/include.





Desperate shell times

Not being able to get any C program to work, and with no 68010 assembler installed I resorted to a kludge testing solution



more doit
/bin/time.bin < ifile61
/bin/time.bin < ifile62
/bin/time.bin < ifile63


cat ifile61
1/1/61
12:34:56


- On my linux system generate a controlling script doit
- do it runs the time command 256 times, and takes input from 256 different files
- each one of those files has a different year number in it from 0 to 255
- I can't use the native Cromix shell because there is no way to make a loop!
- tar up the files into a v7 UNIX compatible file
- transfer the tar file from Windows VM machine to Cromix over a Serial cable
- unpack the tar file using the ftar -ux  Unix extract option
- run the doit shell script that reads the 256 files and log the output




So I iterate the year from 61 to 195 and find a whole range of illogical years result.  Including 2015 but not 2016.  I just don't believe it!




What works in the 68010 Cromix Version
I found however that this does work under the Cromix 167 Operating system for the 68000 processor

system[5] version cromix.*
    CRC OK   68010 XPU 167   Cromix-Plus Operating System
system[6] time -s
        Saturday, September 17, 2016            16:34:53
DATE (mm/dd/yy): 09/19/116
TIME (hh:mm:ss): 18:20
          Monday, September 19, 2016            18:20:00

Oh, and because 68010 code can work on the 68020 system I took the /bin/time.bin 68010 version and executed that in the 68020 environment.  No!  That did not work sadly.


Unbelievable bad luck!


Summary So far

Under the 68010 processor and the Cromix 167 Operating system, by specifying 3 digits  e.g. 116, to the 68010 version of /bin/time.bin I can specify the year 2016 and that is correctly set into the Operating System.  Further then, files created and saved have the correct date and time of the year 2016.

But under the 68020 processor, which cannot run Cromix 167 I must run Cromix 172XXU ( or 168XXU).  In this environment the same 'trick' to use 116 as the 2 digit year does not work and when used screws up both the date and the time

I tried using a C program instead of a command line to set the time, but it is no better

I then tried using 68000 Assembler and Z80 assembler via the priv and debug commands. They work for year 2015 (by specifying year 115) but not for 2016

Since the 68020 processor card is over 300% faster than the 8Mhz 68000 processor, and can also run UNIX  (well yet to be proven!) it would really suck to be constrained to run the older Operating System with the Slower processor card, just to have the time and date come out right.


#Cromemco