[comp.sys.apple] Some ProDOS Triva and Help needed on clock driver

nazgul@apollo.uucp (Kee Hinckley) (05/08/87)

...

---First the problem---
Okay, before I go totally nuts.

I have an SMT No-Slot Clock Chip.  The thing works just as advertised, and
comes with a ProDOS patch that makes everything come out just right - almost.
(Actually, there's a physical problem too, my Rana disk controller doesn't
quite fit over the new raised CD Rom, so I can't close the cover to my Apple,
but I can live with that.)  What's the almost?  Well, I'm trying to run a
program that wants the seconds - this isn't available directly from ProDOS,
but it is available from the Thunderclock and compatables, it gets stashed
in $200 along with some other info.  The No-Slot Clock puts info there too,
but it's still in binary form, not Ascii.  No problem, I wrote a new driver 
(well, actually I wrote two drivers, one that takes the existing info and
makes it Ascii, and one that does everything from scratch - thank God for
disassemblers - the documentation was no help).

So here's the problem.  Where do I put it?  The No-Slot stuff gets installed
through a bizzare combination of Basic and self-relocatable assembly, and I
can't figure out what it does to make it all work.  I'm running ProDOS 8, and
my Beneath ProDOS is way out of date (and full of errors as well, regardless
of the out-of-date-ness).  It hardly mentions clocks.  My ProDOS technical
manual, also somewhat out of date, simply tells me that the only safe place
to put the driver is at location $300, which is cute, but hardly compatable
across multiple .system programs, not to mention that the program I'm running
uses that location for other things.  (The program, by the way is the ProLine
bulletin board system (some of you may remember me asking about BBSs recently)
about which I cannot say enough good things - I'll post more information 
concerning access and the like as soon as I get this damn clock driver installed.)
I could allocate buffer space directly from ProDOS, (which would stash it
right around $BE00) but I'm not entirely sure about the integrity of that across
.system programs.  What I really want to do is put it in ProDOS.  Does anyone
have a list of safe spaces (for ProDOS 8) and where they are in the binary
and or running object module?

---then the trivia---

Now the trivia.  While attempting to find this information for myself, I
came across the following code in ProDOS.  This may or may not be documented,
if I knew that I'd probably know where to put the clock routine.  After
ProDOS has booted, but before it runs the .system file, it looks on your
disk (top directory) for a file called ATINIT.  This file has to have the
type $E2 and be less than or equal to $9800 in size.  If it exists and
matches these criteria (if it exists and doesn't then ProDOS won't continue
and you'll have to boot off another disk) the program is loaded at $2000
(thus the size restriction) and executed.  Presumably this is to initialize
the Apple Talk hardware or some such, but it strikes me as a nifty way to
load patches on the fly.

---one more piece of trivia---
If you ever do something stupid that trashes a directory header (like
modifying ProDOS (did I do that?  No!)) and you want to try and put things
back together you can use a good disk zapper to find missing subdirectories
by searching for the string HUSTON! on the disk.  It's always stored in
directory headers, and it's very handy.  (Does anyone know *why* that's the
string that's stored there?)  Then you can "just" patch the trashed header
to include references to the directory.  If I keep doing stupid things like
this maybe I'll write a program to do this automatically for me.

                                                    -kee

UUCP:   ...{mit-erl,mit-eddie,yale,uw-beaver,decvax!wanginst}!apollo!nazgul
USPS:          Apollo Computer, Chelmsford MA.  (617) 256-6600 x7587
          or  Apt #1, 102 Gloucester St., Arlington MA.  (617) 641-3805
ARPA:                      apollo!nazgul@eddie.mit.edu
and...     (Coming soon, to an internet near you!) nazgul@apollo.com

I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.