Main Line Commodore Users Group Newsletter

Supporting : Amiga - C64/128 - PC/Linux

**** OCTOBER 1998 ***************************** ISSUE #197 ****





Our hopes were high that we would avoid local hazards at VU. But, a combination of the VU Homecoming weekend, plus some local parades that closed Lancaster Avenue, messed up the meeting access. Some folks got turned away when the campus entrance was closed - we're sorry they could not make the meeting. See Pete's report on p.3 to fill in.

MAIN LINE 64/128/PC USERS - Room 110

Hopefully, we'll get back on track - no access problems and folks turning out in droves! Following announcements and feedback from attendees, we'll have our Commodore Q & A. Our 8-bit using members are very much urged to bring their needs to the meeting where more than one mind can be applied to easing one's way.

The main meeting emphasis will be on-line systems - with, barring no major Murphy visits, our first MLCUG/MLAUG BBS demo since 1997! Due to some hardware acquisitions by member Charles Curran, we expect to be able to show off the BBS - for both 8-bit and PC users - and, time permitting, a some Internet stuff via the VU ethernet system.

(continued on page 3)


For October we will continue our review of ImageFX through the use of the Catalyzer video training tape, watching a section of the tape and then replicating the presentation on the Amiga 1200. We will continue our comparison of the latest version of ImageFX, version 3.0, to the previous version, version 2.6.

By the way, if you don't know what ImageFX is, then you're not a real Amiga user. Really, ImageFX is one of the best graphix manipulation software packages on the Amiga today. With it, you can even compile animations.

[This month's Amiga article focuses on the Year 2000 date problem. Turn to p.5 for a full article on how the Amiga is affected].


With the purchase of Tech Media, CMD not only gained a large product inventory, but also took over responsibility for some of the vast backlog of unfilled orders created mostly through mismanagement by the order fulfillment company employed by Tech Media. The major portion of the backlog was for GEOS and GEOS application software produced by Geoworks (formerly Berkeley Softworks). CMD immediately contacted Geoworks, placing large orders for GEOS products. It was CMD's continued success at selling large quantities of GEOS products that eventually led Geoworks to grant CMD full production and distribution rights to the English-language versions of Geoworks' Commodore product line.

Two more CMD products began shipping in 1993. CMD Utilities offered a selection of disk utilities and copiers useful to CMD device owners as well as other Commodore users. On the hardware front, CMD began shipping a new 3- button mouse at the end of 1993. The "SmartMouse" offered full backwards-compatibility with Commodore's 1351 mouse while adding an extra button, new GEOS drivers, and a built-in real-time clock.

In 1994, CMD bought the rights to Skyles Electric Works' 2+1 cartridge port expander, and began offering this product. With the demise of another print magazine (Compute) at the end of 1993, CMD decided it was time to enter the publishing business. In late April of 1994, CMD shipped the first issue of Commodore World magazine. In August, CMD released "SmartTrack", a trackball with compatibility and features identical to that of their SmartMouse. By year's end CMD had released "geoCable II" for printing from GEOS, began providing computer and disk drive servicing, and started to offer both new and refurbished Commodore computers, drives and monitors. As 1995 began CMD launched the EX3 cartridge port expander, replacing the 2+1 which had turned out to be too expensive to produce and market effectively. The EX3, however, lacked the horizontal expansion port of the 2+1, so in May CMD released a modified version of the EX3 with this feature -- the EX2+1.

While this brings us up to the present, the story is far from over. CMD has forged its reputation on creativity, compatibility, and dedication to the Commodore market. As you read this, they're hard at work developing more new products for Commodore users, and formulating new ideas for the future. While any new plans must remain secret for now, you can be sure that the brief history given here is far from being over.

The document you are reading and all information contained herein are Copyright (C); 1995 by Creative Micro Designs, Inc.

This completes the short summary history of the Creative Micro Designs company. It has been (and is) one of the most important assets that the Commodore community has ever had. Without their continued presence, the Commodore 8-bit world would be essentially stagnant and offer very little opportunity for entrepreneurs like Maurice Randall (aka Wheels!).

This history summary was republished from the CMD website at:
Check it out!


Meetings in the St. Augustine Center at Villanova University. The 8- bit and PC sessions will be in Room 110 and the AMIGA meeting in Room 210.

Enter from the ITHAN AVENUE main gate, then proceed to the 2-level parking building adjacent to St. Augustine, on the Ithan Avenue side.

NOTE: maps on our webpage -

64/128/PC/Amiga Meetings  1998  Steering Committee Meetings
                     November 07                       November 11
                     December 05                       December 09
     * = second Saturday     ** = third Wednesday
 EDITOR: Emil J. Volcheck, Jr.   1046 General Allen Lane
                                 West Chester, PA 19382-8030
(Produced with C-128/SCPU 128, RAMlink, HD-40/85, 1571, FD-4000, THE
WRITE STUFF 128, XETEC Super Grafix, Canon BJ-200ex, Swiftlink and
Motorola 288 modem)

           MLCUG BBS: 610-828-1359 (300 --> 28800 bps), 24 hr/day
           PUBLICITY: Robyn Josephs 565-4058
         DISK ORDERS: Charlie Curran 446-5239; Bill Bacon 441-5908
   VILLANOVA SPONSOR: Prof. Frank Maloney, Dept. of Astronomy

           PRESIDENT: Emil Volcheck     388-1581
           SECRETARY: Charles Curran    446-5239
   TREASURER/MEMBERS: Dewitt Stewart    623-5145
     AMIGA SIG/SYSOP: John Deker        828-7897
            INTERNET: Peter Whinnery    284-5234
            DATABASE: Layton Fireng     688-2080
            AT LARGE: Tom Johnson       525-3440


IT'S THAT TIME OF YEAR! - yes, another year has rolled around and the dues renewal period has arrived! Since we are managing to keep a reasonable bank balance - and the costs for the newsletter have held about the same - we should be able to hold the dues at the $15 level. That will be true if we GET ENOUGH RENEWALS; so turn to page 10 - fill out the renewal form and send it along with your check to Stew Stewart!

BUY/SELL/SWAP??? - with the continued construction in Mendel Hall, we will NOT have sufficient meeting space for any kind of flea market meeting. We'll re-visit the idea next spring, when our meetings may again be in the refurbished Mendel. If you have stuff to sell (or need to buy), bring it to the meetings (IF NOT A LOT!). Or send, or email, the info to Emil for the Trading Post.


"Yesterday it worked Today it is not working Windows is like that"


The following www listings were taken from a presentation given by Jim Templin at the July 1998 meeting of the Exton PC Club. He showed each of these sites during the talk.

Finding People:


Finding Places:

Finding Things:

Note: all the above URLs should be proceeded by "http://www.", as usual.


FOR SALE: MLCUG has a lot of hardware and software that is available for you to purchase at very attractive prices! By the time you get this newsletter, the listing should be updated and POSTED on both our BBS and our webpage. This new listing has ALL items priced. Check out either of the site postings. For items, you can contact Charles Curran to make arrangements to purchase (610-446-5239).


The September meeting was attended by 10 members in the 8-bit/PC section and only 1.5 members in the Amiga section (1 member had to leave early so John Deker joined the 8-bit group). After the usual announcements we fielded a few questions from the group - some we were able to help, others not (we keep trying).

Murphy made a couple of visits and affected the hardware setup. Though we were able to get the Windows95 desktop to show up on the big TV we had no luck in getting a plain old text screen to display. We also could not get a text console under Linux to display. As there were only a handful present we made due by gathering around the monitor on the table. The X-window GUI under Linux also failed to display on the TV. The club PC mouse also has a problem with X-windows in the Linux demo. We should consider getting another one.

Beyond these problems, the LINUX introduction/installation demo went well and seemed to be well received by those present. I got through all I had planned and was able to show off a couple of Applications and X-Windows. Meeting adjourned around 1:00 and 4 of us made the monthly trek to the Diner for lunch. [Peter Whinnery].


"Stay the patient course Of little worth is your ire The network is down"


[by Emil Volcheck]

Well, back in the August issue of the newsletter, I described one of those circumstances where a serious system mess-up was corrected by the use of a "rescue" disk. As promised then, here is the followup - aimed to provide you with some tips or suggestions on how to get yourself in a position to recover from a serious problem.

We'll begin with enabling you to re-install your WINDOWS 95 operating system, when nothing else has worked.

1. Windows 95 StartUp Disk:

The first step is to create what Win95 calls a "startup disk". The process is as follows - where you'll click or double-click with your mouse, as appropriate:

    - START
    - Add/Remove Control Panel
    - Tab - StartUp Disk
    - Button - Create Disk
Then, you will be asked to insert a blank disk in drive A: (It should be one with no good files on it). You may also need to have your Win95 install disks or CD-ROM available, as it might be requested during disk creation.

A STARTUP disk will be created that contains these files:

ATTRIB   EXE    15,252 08-24-96  11:11a
CHKDSK   EXE    28,096 08-24-96  11:11a
COMMAND  COM    93,812 08-24-96  11:11a
CONFIG   SYS        20 11-09-97   3:56p
DEBUG    EXE    20,554 08-24-96  11:11a
DRVSPACE BIN    65,271 08-24-96  11:11a
EDIT     COM    69,886 08-24-96  11:11a
FDISK    EXE    63,116 08-24-96  11:11a
FORMAT   COM    49,543 08-24-96  11:11a
HIMEM    SYS    33,191 08-24-96  11:11a
REGEDIT  EXE   105,984 08-24-96  11:11a
SCANDISK EXE   142,353 08-24-96  11:11a
SCANDISK INI     7,332 08-24-96  11:11a
SYS      COM    18,967 08-24-96  11:11a
UNINSTAL EXE    76,496 08-24-96  11:11a
NOTE! This disk will NOT allow you to use your mouse, a CD-ROM (including the Win95 CD) or a Zip drive or other such external drive. So, if you have to re-install Win95 because it is not working (properly), this disk may not be enough to get you back up and going!

2. Fixing Up Win95's StartUp Disk:

- copy the following files to the disk

BTCCDROM SYS    15,792 07-04-96  10:41a
 (or your CD-ROM driver, if different)
MSCDEX   EXE    25,473 08-24-96  11:11a
MOUSE    EXE    99,676 10-31-95   7:00a
MOUSEDRV INI     1,348 03-26-98   9:13p
- create the files


rem - the following line is the real
   mode device driver for your CDROM
rem - This file is necessary for
   Win95 to identify your CDROM drive
rem - during an AutoDetect of hardware,
   MSDOS mode also requires this file

DEVICE=btccdrom.sys /D:MSCD000


rem - To be able to access your CD-ROM,
   remove the "REM " portion of the
rem - comments below to load the driver
   for the Mouse, and for a
rem - CD-ROM drive letter. If you want
   a different drive letter than D:
rem - for your CD-ROM, change the letter
   of the /L: parameter below.

mscdex.exe /D:MSCD000 /L:D
This upgraded StartUp disk will enable your CD-ROM drive and mouse.

NOW, you have a respectable boot or startup disk - that will put you in the position of being able to get your PC going and to re-install the Win95 OS.

[to be continued next issue]


"Three things are certain: Death, taxes, and lost data. Guess which has occurred"

   _   __      _  <>_  __      _
  /\\   |\    /|| ||  /  `    /\\
 /__\\  | \  / || || || ___  /__\\
/    \\_|  \/  ||_||_ \__//_/    \\_
By John Deker, AMIGA SIG Leader


If you have either software or hardware for your Amiga that has taken your fancy, please bring it to our attention. I'm sure your specific interests will be of interest to others. Let me know if this is the case at the next meeting, or leave me email on our BBS. Remember, a user group is only as rewarding as the sum of the efforts of its individual members.


"The Year 2000 problem and the Amiga"

To make a long story short, the Amiga in general does not suffer from the Year 2000 problem in the context known to the PC world. However, the Amiga faces three distinct date problems and a single, specific Year 2000 problem with limited scope which will be described below.

1. Scope of this document

The following text refers to Amiga desktop computers built between 1986 and 1997 and only covers computer hardware configurations designed and built by Commodore-Amiga, Inc. This specifically excludes 3rd party hardware extensions, such as the Microbotics "StarBoard" which among other features offered a battery backed up clock, but it includes Amiga computers built by Amiga Technologies GmbH and Amiga, Inc.

2. How the Amiga handles date and time

The Amiga operating system has always followed the Unix model in measuring time as the number of seconds that have elapsed since a fixed point of time. Under AmigaOS that fixed point of time (also known as `epoch') is 00:00:00 of January 1, 1978 (Unix uses 00:00:00 GMT, January 1, 1970). The operating system manages time and date through a central component known as timer.device. This component reads and stores date and time information using a data structure known as timeval which, in `C' language notation, is shown below:

   struct timeval
      ULONG tv_secs;
      ULONG tv_micro;

In this context an ULONG refers to an unsigned 32 bit quantity. The tv_secs structure member holds the number of seconds that have elapsed since the AmigaOS epoch and the tv_micro member denotes the number of microseconds (the 10-9th part of a second) that have elapsed since the last second has passed.

Until AmigaOS 2.0 was introduced in 1989/1990 the operating system only provided the methods for time keeping but did not offer any means to convert the number of seconds elapsed since the AmigaOS epoch into human readable format. This work was left to application software developers who implemented different conversion algorithms with varying success.

2.1 The AmigaDOS date and time handling is special

"AmigaDOS" and "AmigaOS" are not two names for the same thing. Exactly the opposite is true: AmigaDOS is (in a nutshell) the name of the AmigaOS layer which implements filing systems and their actions, the command line interpreter and which handles loading and relocation of executable binary files. AmigaDOS is more or less a port of the Cambridge University TRIPOS 32 bit kernel. It has its own peculiar data structures, including its own version of the timeval structure described above. The AmigaDOS flavour is known as DateStamp, as shown below:

   struct DateStamp
      LONG ds_Days;
      LONG ds_Minute;
      LONG ds_Tick;

In this context a LONG refers to a signed 32 bit quantity. The ds_Days member contains the number of days (each day consists of exactly 24 hours) that have passed since the AmigaOS epoch. The ds_Minute member denotes the number of minutes that have passed since midnight (00:00:00) of the given day and the ds_Tick member contains the number of "ticks" that have passed since the last minute. A minute consist of 3,000 "ticks", i.e. there are 50 ticks in a second.

AmigaDOS uses DateStamps to describe file and volume creation dates, and all shell commands follow the same model, i.e. if the system date is set through the shell Date command, it will calculate time and date in DateStamp format.

2.2 Local time vs GMT

The Amiga operating system never knew the concept of local and global time. While the AmigaOS 2.1 update (1992) introduced a locale preferences editor that allowed for the time zone to be selected, the operating system itself never put this feature to use or encouraged application software developers to use it. One might argue that with this background, the AmigaOS was always tuned to local time.

2.3 How the Amiga maintains its system time

The early Amiga computer models did not support a battery backed up real time clock that would keep on ticking and maintaining local time even until after the machine was switched off. For example, the first Amiga computer ever (later christened the Amiga 1000) did not offer a battery backed up clock. For the Amiga 500 the battery backed up clock was an extra hardware feature one had to buy separately with a memory expansion. The Amiga 2000 and (with the exception of the Amiga 600 and Amiga 500+ models) all models to follow did feature a built-in battery backed up clock.

On machines without battery backed up clocks, the Amiga sets its system time according to the modification date of the boot volume. In other words, the point of time the last file was modified or created on a disk would determine the system time. As this was by no means accurate, the AmigaOS boot process would suggest and prompt you to adjust the system date once the system had booted (as pictured below).

[The shell window prompting you to adjust the time]

With machines that featured battery backed up clocks, the system time was read during the boot process. As of AmigaOS versions 1.2 and 1.3 a special program, called SetClock, was responsible for reading the current clock settings and setting the system time accordingly. Starting with AmigaOS version 2.0 that functionality was integrated into the ROM operating system, making the SetClock utility at least in part redundant.

If the system starts up without being able to set its system time, it defaults to 00:00:00 January 1, 1978.

3. Setting and reading the time

The Amiga offers both a command line interface and a graphical user interface. Both went through a number of changes over the years as will be described below.

3.1 The command line interface

There are two shell commands which deal with the system date, these being SetClock and Date. The Date command is for reading and setting the current system date whereas the SetClock command deals with the battery backed up clock, it reads and stores the current system time from/in it. The Date command is of particular interest due to the human readable date format it uses by default. Today you might invoke the Date command and receive the following output:


As one can see, the year number is limited to two digits only. Even if a different locale is used (e.g. french), the year will always be displayed with its two last decimals only. Luckily, this numbering is consistent with the following rule:

To set the system time to any year beyond 1999, you reverse the rule, i.e. entering date 01-jan-01 will set the time to 1 January, 2001.

All versions of the AmigaDOS Date command (version 1.1 through version 37.1) display and parse the data format in the same fashion. They behave consistently and predictably throughout all Amiga operating system revisions.

3.2 The graphical user interface

The system time is set through the preferences editor which in AmigaOS versions 1.0-1.3 used to be a single, monolithic program as pictured below:

[The Workbench 1.1 Preferences editor]

The controls for setting the system time are located in the top left corner of the window. They allow the last two digits of the year to be adjusted; the model follows the AmigaDOS Date command in that a year number smaller than 78 denotes a year in the range 2000..2077 and all other settings refer to a year in the range 1978..1999.

With the introduction of AmigaOS 2.0, the time preferences editor was moved into a single program named Time as pictured below:

[The Workbench 2.0 Time Preferences editor]

In this editor, the year can be entered as a four digit number. However, the range is limited to the years 1978..2113.

When the AmigaOS 2.1 update was released, the time preferences editor was revised, as can be seen below:

[The Workbench 2.1 Time Preferences editor]

Just like with its predecessor, the year can be entered as a four digit number. In this case, the range is limited to the years 1991..2099.

4. The problems

As far as is known today, the Amiga faces four date problems. Two are design problems caused by numeric overflow, one is caused by hardware limitations and one is a real bug that will strike in the year 2000.

4.1 Negative time

As was outlined above, the Amiga measures time in seconds. As it turns out, the number of seconds to accumulate until 19 January, 2046, 03:14:07 will form the largest value a signed 32 bit integer number will hold. This is not a problem for the time keeping module (timer.device), but application software and other operating system components which treat the number of seconds as a signed quantity will get into trouble one second later: the number of seconds will rise to 2,147,483,648 which in two's complement format represents the negative number -2,147,483,648. AmigaDOS, which always treats time as a signed quantity, will consider this date to be invalid because it is negative. Worse, the ROM date conversion routines exhibit a bug which, once the date is later than 19 January, 2046, 03:14:07, causes all subsequent date operations to be inaccurate. The immediate effect this has is that calculations on dates can be off by more than two years.

This behaviour is consistent through all AmigaOS versions. A fix is not available yet, but research is in progress to investigate whether this bug may be fixed by updating several AmigaOS modules (locale.library, dos.library). After all, this bug is "just" a side- effect of treating an unsigned quantity as signed.

4.2 Time rolling over

An unsigned 32 bit integer can hold a maximum value of 4,294,967,295. When the Amiga has accumulated that many seconds, it will be 7 February, 2114, 06:28:15. One second later the seconds counter will roll over and restart at 0. In other words, on 7 February, 2114, 06:28:16 the Amiga will believe that it is midnight on 1 January, 1978.

No fix is available yet.

4.3 The battery backed up clock can count only to 99

Amiga computers that feature a battery backed up real time clock use one of two different hardware designs: either the Oki MSM6242RS (A500, A2000) or the Ricoh RP5C01 (A3000, A1200, A4000) chip. As is common with clock chips of that type, the year counter is implemented as a two digit BCD number. Once it reaches the year 99, the counter will roll over and start again with 00.

Starting with Amiga operating system version 2.0, the boot process will read the battery backed up clock time and set the system time accordingly. Because the year number covers only 2 digits, the same algorithm as used by the AmigaDOS Date command is employed. The consequence is that the Amiga system date set at system startup will always be in the range 1978..2077. While the system clock will keep on ticking beyond 31 December, 2077 a system reset will set the clock back to 1 January, 1978.

No fix is available yet.

4.4 SetClock stops working in year 2000

The SetClock program shipped with the Amiga Workbench disk revisions 1.2 and 1.3 exhibits a bug which causes it to miscalculate the battery backed up clock time starting with the year 2000. It is accurate only for the years 1978..1999. Once the year counter rolls over to 00, SetClock will believe that the year is 1978 until the year 2079 is reached; that's when it will believe that the year is 1979 -- which is not necessarily an improvement.

Please note that only the SetClock program found on the AmigaOS 1.2 and 1.3 Workbench disks suffers from this problem. Several versions of this program were distributed, each between 4,000 and 7,000 bytes in size. To tell whether you have a version that works or not, check the file size; if it is less than 1,000 bytes in size you will probably have the properly working version. If it is larger than 4,000 bytes, you probably have the faulty version.

A fix is provided in this archive. Download it, unpack it, then read the enclosed SetClock_ReadMe file.
[by Olaf Barthel (C) 1998 Amiga, Inc.]