NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/programm/15908

Internet Message Format | 1992-11-16 | 5.4 KB

Path: sparky!uunet!wupost!uwm.edu!rutgers!cbmvax!peter
From: [e-mail] (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: New hardware reference guide?
Message-ID: <[e-mail]>
Date: 16 Nov 92 14:37:23 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Peter Cherna)
Organization: Commodore-Amiga, Inc.  West Chester, PA.
Lines: 99

In article <[e-mail]> [e-mail] (Bjoern Reese) writes:
>In article <[e-mail]> [e-mail] (Chris
>Green) writes:
>> In article <[e-mail]> [e-mail] writes:
>> >Come on now!! How many advanced system software, that was written on a
>> >1.3 A500 with no harddrive will work on a A4000???
>>     A LOT.
>
>Ahhh! But not all? That's interesting.
>
>Does anybody have any info (what software did break, and what
>was the possible cause?)

Sure.  There are lots of reasons stuff that ran under 1.3 on A500's
breaks on the A4000.  Here is a partial list, off the top of my head:

- Breaks under ECS or higher (writing to chip registers that were
  undefined under the original chipset, writing non-zero values
  to reserved bits of existing registers, failing to handle non-zero
  values in reserved bits when reading existing registers)
- Breaks under AA or higher (same basic kinds of reasons, also
  making bad assumptions about the chipset)
- Breaks with fast RAM installed (forgetting to request MEMF_CHIP
  when necessary)
- Breaks on a 1MB chip-RAM system with no fast RAM (assumes if memory
  > 512K, then some MEMF_FAST must be available).
- Breaks on a 2MB chip-RAM system with no fast RAM (eg. A1200).  Same
  reason as above.
- Breaks on 68020 and up, 68030 and up, or 68040 and up.  The usual
  reasons are:
    - Software timing-loops or other processor speed dependencies
    - Use of "MOVE SR" instruction (priviledged on 68010)
    - Self-modifying code fails to work due to presence of caches
      (depending on the code path and cache size, you might work
      on the 020 and 030 but not the 040, for example)
    - Use of high 8 bits of address pointer to store type-data
      (all Amiga pointers must be 32-bit accurate)
    - Has an enforcer hit (this is generally fatal on 68040 and up)
- Breaks due to dependency on undocumented side-effect of the OS.  Some
  examples:
    - Depending on certain registers defined as "trash" actually
      being preserved across a function call.
    - Assuming values of "trash" registers, eg. "noticing" that
      A1 points to the RastPort on the return from a certain
      graphics call.
    - Taking the return code from the wrong register (eg. D1 or A0).
    - Depending on "slowness" of the OS.  New releases often have
      faster routines, and one source of problem is a race condition
      or a missing WaitBlit() that you survive only by virtue of
      having a slower CPU or an older (less optimized) OS.
    - Poking read-only members of structures or private structures
      (eg. writing to IntuitionBase)
    - Passing the wrong flag to a function or a structure.  (The
      best example of this is placing the IDCMP flag ACTIVEWINDOW
      into the NewWindow.Flags field by mistake.  V35 added a NewWindow
      flag with that numeric value.  This caused massive enforcer hits
      and software death -- we put in a kludge to protect against this
      case).
    - Passing non-zero values in reserved fields (eg. BitMap->Pad byte).
- Breaks due to "abuse of system".  Examples include:
    - Incorrectly or incompletely taking over the system
    - Not using system-supplied mechanisms (one application
      "knew" that under 1.3, audio.device was third (or whereever, it
      doesn't matter what the exact position was) on the device list.
      Rather than call OpenDevice(), it just took the third device
      pointer.
    - Assuming the ROM size or location.  (jumping to the start of the
      ROM in order to reset the computer amounts to jumping to middle
      of the ROM now that the ROM is 512K large).
    - We have well-defined requirements on floppies, as far as
      the settle-times, track-to-track times, etc.  Some programmers
      empirically determine that they can shave (say) 3 ms off every
      seek.  Not all drives sold for the Amiga can handle this.
    - Similarly, violating the timing and handshaking requirements
      of the keyboard.

There are plenty of other reasons, but these are a pretty good sampling.
Virtually _all_ of these were addressed in some form or other, even
in the original 1.0 RKMs.

In fairness, you have to add to the list such OS-related problems as:
- Changes in poorly-defined areas of the system.  Occasionally, the
  exact behavior of a function changes due to the fact that we are
  unaware how certain non-documented or under-documented aspects
  have been used in the field.
- Accidental changes in behavior of a system function.  Sometimes
  in extending, enhancing, or speeding up a function, a small behavioral
  aspect might be altered.  If this aspect was part of the function's
  definition, then that would consitute a bug.  If not, then it
  may not technically be a bug, but it can kill software.

>Bjoern Reese                   |     Email: [e-mail]

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    [e-mail]
My opinions do not necessarily represent the opinions of my employer.
"I believe it's bad luck to be superstitious."