Path: utzoo!attcan!uunet!super!udel!rochester!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Need help with ....
Message-ID: <6234@batcomputer.tn.cornell.edu>
Date: 7 Sep 88 18:56:34 GMT
References: <298@lexicon.UUCP>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 67

In article <298@lexicon.UUCP> trh@lexicon.uucp (Tom Hegg) writes:
>1) Lattice 4.0.  I've seen some discussion on the net about the compiler
>defaulting to a 16-bit addressing mode, which was apparently not the
>case in 3.10.  The '-B' flag isn't accepted by LC, but the documentation
>states that the flag '-b0' will turn off base-relative addressing and
>use absolute 32-bit addressing.  In fact, using the -b0 option DOES
>result in a bigger program segment (which is I guess what you would
>expect), but now BLINK gives an error (I think number 512 or 502)
>in reference to the symbol _IntuitionBase.  Can anybody clear this up?

-B is an MSDOS thing only.  -b0 does turn off base-relative addressing
(yes, Lattice 4.0x and 3.10 do have base-relative addressing).  The
problem is that the libraries are compiled with base-relative addressing,
including the ^c handler, which references IntuitionBase so it can
display a requester on ^c.  The solution is to use the SMALLDATA blink
option, which forces all the data into one hunk (so that _IntuitionBase
is addressable by the routines in the library), or use the nb libraries
on disk 4 of the compiler, which are compiled with absolute addressing.
Or you could replace the ^c handler and a few others (the source is on
one of the disks).

>3)  Another Lattice 4.0 question:  the old version of ATOM
>doesn't seem to work with the new compiler - I ran one of
>my files through and ATOM returned with a message saying
>there was an unknown hunk type.  Sorry can't be more exact,
>I'm at work, the Amiga is at home.  Can the compiler really
>be generating newer hunk types than the Amiga Tech Ref Manual
>describes?

Yes.  The original object format doesn't allow for base-relative addressing
or PC relative branches, so Lattice had to introduce new hunks for these.
I believe Lattice has registered these with C-A, so they are somewhat
official now.  I'd suggest using the compiler flags which force loading
of selected hunks into selected types of memory instead of ATOM.

>4)  Would like to find out the names for file system devices
>currently running ("DF0:", "DH0:", "VD0:", etc.).  This is for
>a file requester that hopefully has some smarts and gives you
>buttons for names of devices you actually have.  Is there
>any way to get this information from the operating system?
>(Or maybe a better way to ask this: how does the INFO command
>work?  - could someone point me to some PD code?)

You might look at the routine to show locks, written by Chuck McManis,
or look in the browser code in mg.  The basic code, taken from Chuck's
program, looks something like this:
rn = (struct RootNode *) DOSBase->dl_root;
di = (struct DosInfo *) BADDR(rn->rn_info);
dl = (struct DeviceList *) BADDR(di->di_DevInfo);
and the next one is
dl = (struct DeviceList *) BADDR(dl->dl_next);
The device name is in the DeviceList entry, along with info on the type
of entry, etc...look in dos.h and dosextens.h for details.

>5)  There was some talk a few months back I think about a
>midi.library thingy that someone had written.  I looked,
>but couldn't find it on the Fish disks at the local computer
>store.  Anybody know where I might find it, and is source available?

Fish disk 101.  Source isn't available.  It's a nice library, but he
doesn't have a replacement for the serial.device yet, so it sill has
the timing and data-overrun limitations of the standard serial.device.
I think it was also posted to comp.binaries.amiga a while back, so
you can get it from j.cc.purdue.edu, if you can ftp.

-dan riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet)
-wilson lab, cornell u.