Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!cunews!micor!latour!mcr
From: mcr@Sandelman.OCUnix.on.ca (Michael Richardson)
Subject: Re: Source to OS (Was Re: Information on Amiga Technical Reference Ser
Message-ID: <1991Jun18.063407.22794@Sandelman.OCUnix.on.ca>
Organization: Sandelman Software Works, Debugging Department, Ottawa, ON
References: <3034@public.BTR.COM> <91164.020625DXB132@psuvm.psu.edu> <22451@cbmvax.commodore.com>
Date: Tue, 18 Jun 1991 06:34:07 GMT

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.

  While this is good advice generally, it doesn't help you when you
are trying to debug a program with a memory leak/clobber via RomWack after it
has crapped out in an OS routine somewhere. Knowing that 0xfc800a (a
random number) is somewhere in Wait() versus ReplyMsg() is rather valuable.
  To my knowledge, even if I had an MMU equipped machine, I still
can't walk into my dealer and buy Unix. My dealer has started asking
ME for Unix help. 
  I have no source to my 2090's hddisk device (doesn't
autoboot, but neither do my 1.2 roms) -- I'd write a Unix disk driver
for my 2090 if I had a commented source code for hddisk.device. Which
reminds me -- my disassembly of hddisk.device is half done. Will I
have to go through the same song and dance that Markus had to go
through with his 1.2 disassembly?

>on ANY undocumented details, then you make it much harder for
>Commodore to upgrade the OS.

  When will CA= fix the serial.device? OpenDevice/CloseDevice is not
good enough for DTR control given shared mode. Until then, we gotta
hit the hardware to hang the modem up reliably. ASDG went and defined
a number of control options, and documented them. 
  Until we can get better turn-around for feature requests, a good
knowledge of the OS is the only way find the right work-around. (Like
when will I get a reliable System() command? 2.0 doesn't count -- my
dealer doesn't have it, so I can't tell a customer to upgrade in order
to use my program)
  I really wish the ROMs were getting smaller, not bigger.
  
>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.

  If only I could remember all the problems which had no documented
solutions. 
  Here is one: How do I allocate 16 bit (Zorro II accessible) RAM on a
3000? So it might be CHIP ram, that's too bad about the speed, but I
might also have 2 meg of on my DMA data acquisition board.

  Sorry -- but in my impression you belabour the point of following
the RKMs. To those that would listen, it is an old tune. To those that
won't, well, their A500 is just a bigger C-64 to them anyway. Markus
Wandel put a lot effort into that disassembly, and put even more
effort into making it redistributable. I have found it invaluable in
understanding how my Amiga works. 
  I just wish CA= had released that beta of 2.0 that I heard was
almost entirely pure.

-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!