Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!stanford.edu!neon.Stanford.EDU!ibis.Stanford.EDU!espie
From: espie@ibis.Stanford.EDU (Marc Espie)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Source to OS (Was Re: Information on Amiga Technical Reference Ser
Message-ID: <1991Jun14.211748.10468@neon.Stanford.EDU>
Date: 14 Jun 91 21:17:48 GMT
Article-I.D.: neon.1991Jun14.211748.10468
References: <3034@public.BTR.COM> <91164.020625DXB132@psuvm.psu.edu> <22451@cbmvax.commodore.com>
Sender: news@neon.Stanford.EDU (USENET News System)
Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France)
Lines: 45

In article <22451@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes:
>>In article <3034@public.BTR.COM>, valentin@btr.BTR.COM says:
>>>I recommend to everybody to seek out Markus Wandel's disassembly of the Exec
>>>if they wish to understand the inner workings of the OS.
>>
>>I second this recommendation!
>>-- Dan Babcock
>
>I would like to recommend that you ignore any disassembly of the ROM,
>throw away your hardware manuals and treat the OS as a black box.
>I know this is not possible in some cases, but doing so will provide
>maximum compatibility with future versions of the OS.  If you rely
>on ANY undocumented details, then you make it much harder for
>Commodore to upgrade the OS.
>
>Please follow the documentation.  Don't assume what unused bits do.
>Don't test values to see what happens.  If you have a problem which has
>no documented solution, ask!  If you find a bug in the RKMs, report it.
>-- 
>Ken Farinsky - CATS - Commodore Business Machines

Something I would like to see in the next release of the manuals is a
deeper emphasis on overhead issues, for instance how much time does it
take to get through a given interrupt server ? Will that break in the
future, or can we expect the overhead to stay the same ?
Some time-critical applications (like music playing) are for
now very difficult to do in an unbreakable way.


I would also appreciate to get more caveats related to that problem.
For instance, explain that relying on interrupts will probably break any
serial communication program running at high speed. Right now, it's
impossible to know what will happen except by running the program, which is
not very easy unless you happen to have a high-speed serial line available...

Some other solutions to typical problems should be in the manuals. My
feeling is that some hardware hackers refer to the hardware manual because
there is a lot of guesswork in the current RKMs. For instance: stealing the
mouse from intuition requires playing with the input.device. This should be
documented in the intuition part of the manual (like a ``getting rid of
intuition'' paragraph), not as a sidenote in the input.device chapter.
Then people wouldn't bang the hardware directly in such cases. (I know, 
I'm dreaming...)
----
     Marc Espie (espie@flamingo.stanford.edu)