The Year 2000 problem and the Amiga

Written by Olaf Barthel

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. Still, the Amiga faces three distinct date problems and a single, specific Year 2000 problem with limited scope which will be described in this paper.

This document will show you how to find out if your Amiga might have a Year 2000 problem and will then go into detail, explaining the technical aspects of the problems and how they may be addressed.

(This is a revised version of the document of the same name which appeared on September 20, 1998, on the Amiga, Inc. web site).

1. How to tell if an Amiga is Year 2000 compliant?

The Amiga runs under control of an operating system called AmigaOS which, depending on the operating system version, is either fully Year 2000 compliant or may have a problem in the Year 2000. To tell which operating system an Amiga is running you can perform a simple test. The test works by invoking an operating system feature that is unavailable in the operating system versions that may have a problem in the Year 2000.

For this test, hold down both the leftmost and the rightmost mouse buttons before you switch on the computer and keep holding down both buttons until a picture appears on your monitor.

The picture to appear should look like one of the three illustrations shown below. Please see the description for each illustration to find out what the pictures mean.

Figure 1: The Amiga 3000 Kickstart menu

This is a picture of the Amiga 3000 computer prompting you to choose the operating system to use. Two principal choices are possible, you can either use the older Kickstart version 1.3 or the newer version 2.x. On this machine, either choice will pick an operating system version that is Year 2000 compliant (the Amiga 3000 is not vulnerable to the SetClock problem described in this paper since it uses a special version of that utility). If a picture like this appears, it means that your Amiga is Year 2000 compliant.

Please note that the picture you will see on your screen need not be completely identical to Figure 1.

Figure 2: The AmigaOS 2.0/2.1 boot menu

This picture shows an Amiga prompting you to choose the device to bootstrap from. If a picture like this appears, it means that your Amiga is Year 2000 compliant.

Please note that the picture you will see on your screen need not be completely identical to Figure 2.

Figure 3: The AmigaOS 3.0/3.1 boot menu

This picture shows an Amiga prompting you to choose an early startup option to change. If a picture like this appears, it means that your Amiga is Year 2000 compliant.

Please note that the picture you will see on your screen need not be completely identical to Figure 3.

If the picture to appear does not look like any of the three illustrations shown above, then your Amiga is probably not entirely Year 2000 compliant. To find out how to address the problems, see section 5 of this document.

1.1 Is the software written for the Amiga Year 2000 compliant?

Software written for the Amiga computer is not automatically Year 2000 compliant. While the Amiga operating system provides time and date keeping services which are Year 2000 compliant, it was always left to the individual software developers to use them properly. Amiga, Inc. neither supports nor maintains 3^rd party application software.

2. Scope of this document

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

It should be noted that, as far as the ROM operating system and Amiga software is concerned, this document only covers the features and/or shortcomings of the Amiga operating system as designed and implemented by Commodore-Amiga, Inc. 3^rd party application software designed to run under control of the Amiga operating system may not show the same behaviour as the operating system itself. It may show bugs which AmigaOS does not exhibit, and the other way round.

3. 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 module known as timer.device. This module 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. The tv_micro member denotes the number of microseconds (the 10^-6th part of a second) that have elapsed since the last second has passed.

3.1 The AmigaDOS date and time handling is special

"AmigaDOS" and "AmigaOS" are not two names for the same thing. AmigaDOS is (in a nutshell) the name of the AmigaOS layer which implements filing systems and their actions, the command line interpreter, and the means to load and relocate 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 variant 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. 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 exactly 50 ticks in a second.

The term "tick" is often confused with the "tick" signals which the Amiga hardware can generate either through the power supply or the custom chip set. The frequency at which the hardware generates "tick" signals is controlled by the power supply frequency (50 Hz or 60 Hz) or the jumper settings on the main board (PAL = 50 Hz, NTSC = 60 Hz). There is no relation between the hardware "tick" signals and the "tick" quantities used in the context of the DateStamp data structure. For the DateStamp ds_Tick member, there are always 50 ticks in a second, regardless of the power supply frequency or the main board jumper settings.

AmigaDOS uses DateStamps to describe file and volume creation dates. 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.

3.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.

3.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 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 could buy separately with a memory expansion.

Amiga computer models without battery backed up clock hardware include:

• Amiga 500
• Amiga 600
• Amiga 1000
• Amiga 1200 (note: only a few early machines were built with battery backed up clock hardware)

Amiga computer models with battery backed up clock hardware include:

• Amiga 500+ (this is a variant of the Amiga 500)
• Amiga 2000
• Amiga 2500 (this is a variant of the Amiga 2000)
• Amiga 3000
• Amiga 3000T; also known as "Amiga 3000 Tower" or "Amiga 3000, floor standing model" (this is a variant of the Amiga 3000)
• Amiga 3500 (this is the precursor of the Amiga 3000T; only few of these machines were built)
• Amiga 4000
• Amiga 4000T; also known as "Amiga 4000 Tower" or "Amiga 4000, floor standing model" (this is a variant of the Amiga 4000)

These two lists do not mention the CDTV and CD³² devices since these machine types do not really count as desktop computers.

On machines without battery backed up clock hardware, 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).

Figure 4: The shell window prompting you to adjust the date

On machines equipped with battery backed up clock hardware 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.

4. 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.

4.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:

   19-Sep-98

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:

• If the number is greater than or equal to 78, the year number is 1900 plus the number given (i.e. numbers 78..99 indicate years 1978..1999).
• If the number is less than 78, the year number is 2000 plus the number given (i.e. numbers 00..77 indicate years 2000..2077).

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. The same holds true for the other two Shell commands that deal with dates, namely SetDate and List (the List command can list files and drawers created/modified since a specific date).

4.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:

Figure 5: 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 less 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:

Figure 6: 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:

Figure 7: The Workbench 2.1 Time Preferences editor

Just like with the previous version of the Time Preferences editor, the year can be entered as a four digit number. In this case, the range is limited to the years 1991..2099.

5. 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.

5.1 SetClock stops working in the year 2000

The Amiga Workbench disk revisions 1.2 and 1.3 would ship with a program by the name of SetClock which was responsible for reading the battery backed up clock time upon system startup. The SetClock program suffers from 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 (and not one of the older versions). If it is larger than 4,000 bytes, you probably have the faulty version. Size isn't everything, though. Some 3^rd party hardware extensions would use their own versions of the SetClock program. They went by the same name, but read the system time from a different hardware location. Do not replace these custom versions. You will probably be using such a custom version if your real time clock is hooked up to a mouse port or the keyboard connector.

A fix for this problem is provided in this archive. Download it and unpack it, then read the enclosed SetClock_ReadMe file!

5.2 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 can hold. This is not a problem for the time keeping module (timer.device). However, 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 could 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.

5.3 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 for this problem is available yet.

5.4 The battery backed up clock can count only to 99

Amiga computers equipped with battery backed up real time clock hardware 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 at 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. This takes place every time the Amiga is reset. Because the year number covers only two digits, the same algorithm as used by the AmigaDOS Date command is employed. Consequently, the Amiga system date set at system startup time will always be in the range 1978..2077. While the system clock will keep ticking beyond 31 December, 2077 a system reset will set the clock back to 1 January, 1978.

No fix for this problem is available yet.

6. Other hazards

The following section covers topics which are related to time keeping, but not quite in the same context as was discussed in the previous sections.

6.1 In a version tag a year only has two digits

The AmigaDOS Version command (which was introduced in AmigaOS 2.0) can extract the version and revision numbers and the creation time of any file which includes a string like this:

   $VER: version 40.1 (9.2.93)

A string like this is called a "version tag". The date, as it appears in brackets, consist of a day, a month and a year number (exactly in that order), none of which may contain more than two digits. This was not such a big problem with versions 37 and 38 of the Version command, which extracted the string and printed it verbatim. However, starting with version 39 of the Version command, the date extracted was converted and printed using the default locale. The conversion process involved has a major flaw in that it always takes the year number, adds 1900 and prints the date. This is not consistent with how the Date command treats year numbers beyond 99. In fact, in order to print properly, the year 2000 would have to show up as the year 100 in a version tag (which is guaranteed to cause some confusion).

The problem described above exists only in version 39.1 and 40.1 of the Version command. To find out which version of this command you have, open a Shell window and enter the following command:

   version c:version full

A fix for the date parsing problem in the Version program is provided in this archive. Download it and unpack it, then read the enclosed Version_ReadMe file!

6.2 Leaking clock batteries

A battery provides the necessary power to keep the battery backed up clock hardware ticking while the Amiga computer is switched off. As time passes and the clock hardware keeps ticking, the batteries age: some must be more than ten years old by now. Old batteries can leak acid, causing great damage to the Amiga motherboard hardware. Often such leakages go unnoticed until critical parts of the Amiga hardware begin to fail. Of course, once you notice it, it is probably already too late...

It has been recommended to replace the clock batteries on every Amiga main board that is more than three years old. The batteries are small, barrel-shaped objects about 18mm long and 15mm in diameter. They look as if they were being held between two clamps (they are not; the batteries are soldered) and have a blue or red plastic covering. The covering is often labeled with the name of the manufacturer (e.g. GP or Varta) and the battery properties (3.6V, 60mAh). Also, the anode ("plus pole") should be marked clearly.

Where is that battery? Try looking for it: the battery may look like a capacitor on first glance, but it is unique in that it appears to be held between clamps. It is larger than any capacitor on the main board and the labeling should be unique. Here are some hints on finding the battery:

• Amiga 2000: under the drive bridge, where the floppy disk drives are mounted
• Amiga 3000: near the left edge, right in the middle of the main board
• Amiga 3000T: right below the power supply, next to the two Kickstart ROM chips
• Amiga 4000: left side of the main board, near the mouse ports; note that only older Amiga 4000 boards use the barrel-shaped nickel cadmium storage batteries, the newer boards use disk-shaped lithium batteries

You should really start worrying if corrosive salts are covering the metal casing of the battery: it should be replaced as soon as possible. Do not attempt to replace the battery on your own. You should consult a specialist, such as your nearest Amiga technical support centre.

BurnIt_Drivers.lha   biz/titan  159K+BurnItMasterdrivers V1.12 (26.03.99)
EDoomMovie_07.lha    biz/titan  2.4M+EvilsDoom Movie Part 7 of 18
ShadowGVP.lha        biz/titan   71K+Shadow 3rd Moon GVP, SX32 fix
AWBNetbt.lha         comm/www     7K+Netscape4 Style buttons for AWebII 3.x
dcs-neb.lha          demo/aga   2.7M+Nebula by Dual Crew - Shining (2nd at TG
dcs-phef.lha         demo/aga   4.3M+Phenomenon(final) by Dual Crew - Shining
GenderBender.lha     demo/aga   6.2M+GenderBender - TotalVision (PPC & 68k & 
GenderBender_F.lha   demo/aga   859K+GenderBender - Fixed PPC Version
ltx-epilepsy.lha     demo/aga   2.6M+Latex: Epilesy. Third place at CSX.
ltx-rubber.lha       demo/aga   837K+Rubber Mania. Latex first demo.
wpz-frozen11.lha     demo/aga   541K+Frozen Pack#11 - Mekka & Symposium Party
wpz-frozen12.lha     demo/aga   691K+Frozen Pack#12 - Mekka & Symposium Party
dcs-2cb.lha          demo/intro  60K+4-BROMO-2,5-DIMETHOXYPHENETHYLAMINE by D
ltx-ascii.lha        demo/intro 124K+Latex: Ascii Attack. First place at CSX
ltx-jul.lha          demo/intro 114K+Latex presents: Jul. (suprice compo)
2b_RDBArc18.lha      disk/misc   61K+Simpliest way to backup your HD's RDB, v
RecoverRDB_src.lha   disk/salv   16K+Helps to recover deleted RDB - source
F1GP_1999.lha        game/data    8K+1999 F1 season data for F1GP-Ed (7-Mar-9
fu_smht.lha          game/misc  1.9M+German indoor championships (football ma
ltx-stuntcar.lha     game/patch 300K+Stuntcar Racer Fix
TaskForce.lha        game/think 303K+Tactical combat game & editor (V0.34; lo
SvIIFix831.lha       gfx/misc     6K+*Fix* for SViewII V8.30 (9.4.99)
Spitfire.lha         hard/drivr 185K+A Palm Desktop for the AmigaOS!
imdbDiff990402.lha   misc/imdb  1.3M+Diffs for the Internet MovieDatabase
ms99-sid.lha         mods/chip   81K+MekkaSymp99 SIDs as PSID-files.
smokebomb_mod.lha    mods/demo  535K+Mod from SmokeBomb demo by Ozone
lnsR6_water.lha      mods/jungl 336K+Out in the water - jungle remix
lnsR9_boy.lha        mods/jungl 185K+The boy from bronx - triphop remix
A2-M4chn_2.lha       mods/misc  2.4M+Astrosyn`2 - 4 channel music compo entri
lns31_technoEp.lha   mods/techn 111K+Techno ep p2 - calling pilot
lnsR10_ecua.lha      mods/tranc 191K+Ecuador - acidtrance remix
lnsR11_chil.lha      mods/tranc 160K+Children - minimal trance remix
lnsR12_Xfile.lha     mods/tranc 169K+X-files - trance remix
lnsR13_flo.lha       mods/tranc 683K+Flotasion - trance remix
lnsR7_dick1.lha      mods/tranc 492K+Dick Turpin Crusade 1 - trance remix
lnsR8_dick2.lha      mods/tranc 384K+Dick Turpin Crusade 2 - dance trance rem
FALCONER-Icons.lha   pix/mwb    473K+Many Cool Icons & More 4 MWB
glowiconsaddon.lha   pix/nicon   93K+57 new icons in GlowIcons' style
glowiconspack.lha    pix/nicon   78K+48 more icons in GlowIcons' style
ohnomoreglow.lha     pix/nicon   74K+Even more icons in GlowIcons' style
wordpadv1.lha        text/edit  132K+MUI Based TextEditor v1
Esplit.lha           text/misc    8K+Splits japanese EDICT into PN & normal
EsplitX.lha          text/misc    8K+Splits japanese EDICT into rude/normal
JChar.lha            text/misc   29K+Generates various japanese charsets
JCode.lha            text/misc   22K+Print japanese codes out of a text
JConv.lha            text/misc   25K+Converts japanese codes between texts
KDFilt.lha           text/misc    7K+Filter for KanjiDic
dos2amiga.lha        util/cli    20K+Converts DOS 8.3 filename to long Win95 
2b_CAF.lha           util/misc   19K+CAF - Collect Aminet Files (with source)
Gurus99_15O4.lha     util/wb    469K+Shows infos about Gurus (German + Engl.)

AE30-dansk.lha       biz/haage   12K+ArtEffect 3.0 - Dansk locale
Calendario1999.lha   biz/misc     4K+Italian calendar made with TurboCalc
gemsylk.lha          biz/misc   163K+Business Chart.WB 1.3+. Version A.0 beta
BurnIT_Eguide.lha    biz/titan   30K+Burnit new english guide
FDreamsFrench.lha    biz/titan  313K+French Guide for FantasticDreams
DLG1_27.lha          comm/dlg   1.1M+DLG 1.27 Free Upgrade
S5-Trans.lha         comm/misc  116K+Copy files to and from Psion S5 (V0.1b)
TTimeDeluxe.lha      comm/misc  556K+Displays Phonecosts online (Germany only
uprc.lha             comm/misc   66K+Generates Aminet upload readme files
jldyndns.lha         comm/tcp     2K+ARexx script to update the justlinux.com
PortalOpening2.lha   comm/tcp   181K+Remote administration tool for Amiga
autoindex2g.lha      comm/www    63K+Generates html doc to view pictures with
Eph-Flux.lha         demo/aga   1.4M+Flux - 2nd in the demo compo at TG'99
NCE-VEND.lha         demo/aga   1.8M+4th place at MS99 by NUANCE
wpz-frozen10.lha     demo/aga   476K+Frozen Pack#1o -  The Gathering Party Ed
DKG-2998z.lha        demo/intro  30K+4th place at Mekka/Symposium'99 Amiga 40
jrm-sund.lha         demo/sound  62K+DA JoRMaS: Sundance (2nd at The Gatherin
GuiGFXLib.lha        dev/misc   230K+Application layer for pixel graphics
ukbbslis6.txt        docs/lists  77K+List of UK BBSes - Version 6 - APRIL 99
saku28d1.lha         docs/mags  451K+Saku #28 (2/99). Finnish diskmag. 1/2
saku28d2.lha         docs/mags  499K+Saku #28 (2/99). Finnish diskmag. 2/2

• QNX, Kooperationspartner von AMIGA, nimmt mit seinem Kernel Neutrino RTOS 2.0 an der Preisverleihung "EDN's Innovator and Innovation of the Year" im Bereich "Embedded Development" als Finalist teil. Ueber den Sieger abgestimmt werden kann auf http://www.ednmag.com/innovators/scripts/common/main.cfm?CFID=2585418&CFTOKEN=2152 .
• Per Umfrage wird ueber den Namen des kuenftigen Newsletters der Amiga-Usergroups entschieden. Drei Alternativen stehen zur Wahl. Die Teilnahme ist auf http://www.amiga.org/poll/poll.cgi moeglich.
• Steffen Haeuser schreibt zur Umfrageaktion "Tornado3D fuer WarpUp":
  
  "Hi!
  
  Leider hatte die BBS auf der die Umfrageergebnisse gesammelt werden einen Plattencrash, was zum Totalverlust aller bisher gesammelten Umfragedaten fuehrte. Ich habe den User nun neu eingerichtet, aber leider muessen alle Leute, die bereits eine Mail geschickt haben, diese nochmal schicken.
  
  Ich weiss, das ist unprofessionell so, aber was will ich tun ? Die Daten sind leider vollkommen weg... (Mein persoenlicher email-Account wurde nicht betroffen, nur der Umfrage-Account sowie einige andere Daten der letzten 2 Wochen - da noch ein Backup von vor 2 Wochen existierte)
  
  Steffen Haeuser"

fwml9903.lha         biz/swood   20K+Messages about FW during March 1999
Hurl.lha             comm/mail   26K+The Ultimate URL integrator for TCP Clie
PalmBackup.lha       comm/misc  176K+1.3 - Backup/Restore/Install for PalmPil
RScript_online.lha   comm/misc    4K+Online/offline support with Miami
sshnote.txt          comm/net     0K+Note regarding comm/net/SSH.lha.
jldyndns.lha         comm/tcp     2K+ARexx script to update the justlinux.com
smokebomb.lha        demo/aga   3.1M+Smoke bomb by ozone. 3th place at ms99!
StatsFuncs.lha       dev/basic   47K+MORE statements and functions for Blitz!
ubbinstall.lha       dev/basic    3K+Fixed install script for Blitz 2 (from U
gtlayout.lha         dev/gui    376K+Gtlayout.library V45.1
SCSIFormat.lha       disk/misc   18K+Lowlevel format SCSI drives
SCSISnoop.lha        disk/moni    6K+Snoops accesses to SCSI devices and othe
SCL_DreamCars.lha    game/2play  41K+SCL! - 32k game at Symposium'99   -exe- 
sol_dt.lha           game/board  62K+*Inofficial* German exe for Solitaire v1
VideoEasel.lha       gfx/misc   630K+THE flexible Cellular Automata (LIFE...)
FastFibo.lha         misc/math    5K+Calculates Fibonacci numbers
SCL_Infinity.lha     mods/atmos 778K+SCL! - Mod.DCC_Infinity   -pt-
SCL_Mermaids2.lha    mods/atmos 543K+SCL! - Mod.TRN_Mermaids-2000   -pt-
SCL_InABox.lha       mods/demo   92K+SCL! - Mod.MRV_InABox  -pt-
Landing.mpg          pix/anim   2.0M+The Landing Animation by Tobias Richter 
SCL_LandOfMagx.lha   pix/illu    79K+SCL! - Handpixeled pic at Symposium'99  
3emars.jpg           pix/trace  303K+3eFighters in the orbit of Mars
mad-MysticMira.lha   pix/trace  701K+MysticMiracle by Madbart/Appendix
SCL_QuakerFace.lha   pix/trace   41K+SCL! - Raytraced pic at Symposium'99   -
sliner.jpg           pix/trace  311K+A Space Liner at Mars
WarpUpSettings.lha   util/misc   10K+Set WarpUp-Env-Vars with GUI
FWCalendar.lha       util/rexx   44K+THE calendar creator for FW & Pagestream
vht-vg27.lha         util/virus  78K+VirusWarning.Guide v2.7 (VHT-DK)

KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 27th March 1999

Number: 014

Mailing List: kosh-general

In the mailing list this week, the following items were discussed. Please do
not email the scribe regarding any of these topics, it is not his job to answer
these questions but merely to report  the topics of conversation. If you have
any queries about this summary, please email ben@kosh.net, stating the Summary
Number, and Mailing List Name, and he will try to answer your queries.

a)

Subject: Cymraeg, Gaelic, Cornish and other local languages

Summary of debate: It would be inclusive and a positive step for the Kommunity
                   of Koshans to include support for languages that are
                   normally missed out in mainstream systems. This could be
                   done via the KOSH localisation system.

                   Suggested that we contact relevant local organisations
                   sometime soon about this.

                   There was (and still is??) an Amiga Translator's
                   organisation. Perhaps we could contact them to see if they
                   would do KOSH work too? - Does anyone have the contact
                   details? Suggested contact is Gary Peake who was apparently
                   in contact with them sometime earlier on this mailing list.


b)

Subject: Colour clash and dithering

Summary of debate: It was noted that certain colours on certain coloured
                   backgrounds (eg: red on blue, black on red) can be
                   difficult to view by a large number of people. Further,
                   dithering and patterns such as checks with text on top can
                   also present difficulties. Therefore in KOSH documentation
                   we should avoid such designs.

                   It was also suggested that where possible we so not use
                   dithering in KOSH as a whole, particularly as we are looking
                   at supporting new fast 24bit+ graphics cards (admittedly AGA
                   256 colour dithering will be needed). All of this obviously
                   only applies to full colour KOSH systems.


c)

Subject: KOSH documentation formats

Summary of debate: It was asked what sort of documentation KOSHans would like.

                   A printed manual or manuals would be liked as online
                   documentation is often difficult to use at the same time as
                   the software it refers to - both being on the same system.

                   As well as this, online (HTML?) documentation that
                   configures itself to represent the settings that the user
                   has setup (as mentioned in a previous summary).


d)

Subject: Functional languages

Summary of debate: It was suggested on the subject of what computer languages
                   to use with KOSH that a functional language that includes
                   complex computations could be used.

                   However functional languages are not very straightforward as
                   they often have bizarre syntax.


e)

Subject: Application generators

Summary of debate: Traditionally application generators are always tailored for
                   a specific type of application. However, as the UI in KOSH
                   will have personalities the applications for it will not
                   have to be constant. We could have a KOSH-Script builder
                   with another layer on top that changes with the personality.

                   An applications generator that produced KOSH scripts could
                   come in different versions, each specialized for one type of
                   work.


f)

Subject: More COMAL

Summary of debate: See:
                   http://www.macharsoft.demon.co.uk/unicomal/aboutcml.html
                   Macharsoft produces unicomal, a current COMAL implementation
                   which they claim incorporates OO concepts. NB: the whole
                   site is dedicated to COMAL.


g)

Subject: Structured summaries

Summary of debate: Marcus Peterson has gone through the summaries and
                   restructured them according to categories instead of summary
                   dates.

                   Having both date and subject-based summary formats available
                   will make locating particular information easier.


h)

Subject: Wider world survey

Summary of debate: Greg Webb, greg@gpwebb.freeserve.co.uk would like help with
                   conducting a survey of the wider world beyond us Koshans to
                   see what the computer world at large would like in something
                   like KOSH. If you can help (particularly but not exclusively
                   if you have experience with statistical analysis) then
                   please email Greg directly.


i)

Subject: KOSH programming and semicolons

Summary of debate: It was pointed out that C brings up an error when it is
                   missing a semicolon but then pinpoints the exact location
                   that the semicolon should have been placed at. Therefore it
                   was implied that KOSH should be able to automatically insert
                   such characters.


j)

Subject: One KOSH programming language for all / A KOSHan beginners language

Summary of debate: It was suggested that one global KOSH programming language
                   could be designed (possibly based on existing languages)
                   that was suitable for beginners to programming all the way
                   up to experts in OOP and structured programming.

                   An opinion was expressed against BASIC for something like
                   this in that it can make structured programming difficult.
                   However it was noted by another scribe-e that this may only
                   apply to some versions of BASIC.

                   Such a language could ship with KOSH and be used to
                   encourage people to program. However this may only teach them
                   how to program in the cosy well thought out world of KOSH
                   which could limit their ability to program with other
                   systems.

                   Was suggested that the critical features and design
                   decisions that must be made for a beginners language are:
                   1) Garbage collection - this may be too complex for a
                   beginner. The language must support garbage collection.
                   2) No traditional C-style pointers thereby eliminating a
                   possible memory leak, and making implementing garbage
                   collection easier.
                   3) Run-time array bounds checking or unbounded arrays to
                   protect against inaccurate writes to memory.

                   It was mentioned that eliminating pointers eliminates a lot
                   of power and convenience.

                   It was noted that Java almost fits these criteria except
                   that it doesn't actually support run-time bounds checking
                   but uses a theorem prover instead.

                   Suggested goals for a programming language for beginners
                   are that the system should be protected from accidental
                   damage, the language should be immediately effective with
                   something visible after only a short amount of work and the
                   language should help teach better habits, possibly by
                   requiring the syntax to be commented although this latter
                   suggestion may make the language wordy.

                   A language for KOSH should aim to reduce the gap between
                   having ideas and being able to implement them in a computer
                   language.


k)

Subject: ISO Modula-2 compiler

Summary of debate: Suggested that in the fullness of time we could look at
                   created a ISO Modula-2 compiler for KOSH.


l)

Subject: Installing KOSH

Summary of debate: Proposed that the KOSH v1 installation (on CD?) should
                   include a setup routine to install a base version of Linux
                   as well, with options available for a number of platforms.
                   This would allow those who own platforms on which a hosted
                   version of KOSH has yet to be written to use it, via the
                   Linux hosted version.

                   The complete install could be available as an FTP directory
                   located somewhere.


m)

Subject: Terminology WG

Summary of debate: Could anyone interested in joining the above named Working
                   Group for KOSH please email Ruward F. Leenstra at
                   uart@xs4all.nl


n)

Subject: Loading and coping with older versions of objects

Summary of debate: The following questions were posed: what happens if you have
                   have software which has a number of objects that contain
                   data and when the next version is released, these objects
                   have changed? How should this be handled?  How would older
                   versions of objects be loaded?

                   Old versions should be loadable. It should be possible to
                   just plug the old objects into the new handles or use an
                   adaptor for this.


o)

Subject: Sharing computer experiences

Summary of debate: A way to share experiences of the various computer systems
                   that we all use (including Mac, BeOS, Amiga, Linux, Unix,
                   BSD, NeXTStep, Windows, OS/2 and many others) could be
                   useful. This could take the form of a large section on the
                   web site available (to members only it was suggested) for
                   downloading in parts that would contain emulators, trial
                   versions and other relevant software to allow people to try
                   other systems.

                   The same area could also contain languages like COMAL and
                   Delphi that people could try out.

                   Jason Radford the administrator for the server that the KOSH
                   web site is on agreed that some of the 4gig of drive space
                   available for KOSH could be used for this purpose. He
                   suggested that if enough interest and ideas came forward
                   that ftp.kosh.net could be created.


p)

Subject: Case-insensitive KOSH

Summary of debate: Suggested that throughout KOSH an Amiga-style system where
                   case is stored but operations are case-insensitive is used.


q)

Subject: Standardized diagram construction package

Summary of debate: It was suggested that we try to find a standardized
                   package to construct diagrams for KOSH. A set of brushes
                   that could be used would be useful.


r)

Subject: Executive Scheduler

Summary of debate: KOSH could implement a scheduler similar to the Amiga's
                   scheduler.

                   Further suggested that this should be a separate object. The
                   basic system could ship with a scheduler that does the basic
                   round-robin scheduling.