trh@lexicon.UUCP (Tom Hegg) (09/07/88)
I have a bunch of questions that I (and some friends not on the net)
have accumulated, hopefully of a technical enough nature for the
c.a.tech group. Please email responses to me if not of general
interest. Sorry if its long, but I'm desparate.
OK, here goes:
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?
2) The above comes up in reference to a program we are working on that
does a lot of calls to AllocRemember(). This program used to run when
compiled under 3.10, but now it crashes after the Nth call to
AllocRemember(). For some reason, after a number of calls, AR()
returns NULL (even though there is plenty of memory); looking up the
chain of Remember structures, it occurs usually right after
allocating memory at a suspiciously low address (0x1980 or so).
(I have 1 Meg of FAST RAM, all allocs don't specify a preference
for CHIP, and all previous allocs DID allocate from FAST RAM.)
The nature of the crash is that the program completes, but
no commands can be executed from the shell (always returns with
"Command Not Found"). Changing the stack size, using CLI
instead of the Dillon CSH has no effect. (Oh, this was using
the default addressing mode in the compiler, coz' remember I
couldn't get the -b0 option to link).
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?
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?)
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?
6) I don't know if anybody can help with this last one, but:
I have a program that fairly regularly adds and deletes lots
of gadgets in a non-resizable SMARTREFRESH window.
After a while, flipping between windows (with the
window-to-back gadgets) produces a rather annoying "rippling"
effect (as I guess long lists of ClipRect's are repainted, I dunno).
This happens really slowly (takes about a full second),
SOMETHING must be wrong, because it happens when flipping
between two full-sized windows, there is no reason to split it
up into all these tiny ClipRects. Huh?
--
Tom Hegg
{ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!lexicon!trhkevin@amdahl.uts.amdahl.com (Kevin Clague) (09/07/88)
In article <298@lexicon.UUCP> trh@lexicon.uucp (Tom Hegg) writes: >I have a bunch of questions that I (and some friends not on the net) >have accumulated, hopefully of a technical enough nature for the >c.a.tech group. I usually just read comp.sys.amiga.tech, but I think I can help with some of these. >1) Lattice 4.0. I've seen some discussion on the net about the compiler >defaulting to a 16-bit addressing mode, I do Manx C, but I'm pretty sure Lattice only supports 32 bit ints no matter what version you own. >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? You can find an example of how to do this on the fish disks. Look on earlier disks than 80. I recommend that you provide a "devs" button on your requester. When the user presses this, list the devices into the same place you would normally list the files. This way you don't have to worry about how much "button" space there is. "Button" space is a concern if a user has a machine with lot's of hard disk partitions. > >6) I don't know if anybody can help with this last one, but: >I have a program that fairly regularly adds and deletes lots >of gadgets in a non-resizable SMARTREFRESH window. >After a while, flipping between windows (with the >window-to-back gadgets) produces a rather annoying "rippling" >effect (as I guess long lists of ClipRect's are repainted, I dunno). For SMARTREFRESH windows, you should set the NOCAREREFRESH flag, and this "rippling" effect will go away. Your program should have a faster user interface. >Tom Hegg >{ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!lexicon!trh -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (09/08/88)
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.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/08/88)
:>1) Lattice 4.0. I've seen some discussion on the net about the compiler :>defaulting to a 16-bit addressing mode, : :I do Manx C, but I'm pretty sure Lattice only supports 32 bit ints no :matter what version you own. I believe the latest Lattice has both modes, just like Aztec. It's kind of silly, though. I for one can't stand using 16 bit ints... it screws up arithmatic computation. When I want something to be a short, I declare it a short and let the compiler optimize out the overhead. :>window-to-back gadgets) produces a rather annoying "rippling" :>effect (as I guess long lists of ClipRect's are repainted, I dunno). : :For SMARTREFRESH windows, you should set the NOCAREREFRESH flag, and :this "rippling" effect will go away. Your program should have a :faster user interface. Yah, a lot faster. It was a year before I knew about that one! *Always* specify NOCAREREFRESH for SMARTREFRESH windows. -Matt
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/08/88)
>In article <298@lexicon.UUCP> trh@lexicon.uucp (Tom Hegg) writes: >>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? > Look at the GetDisks code written by Phillip Lindsay on Fish disk 56. It works great. kev -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
keithd@cadovax.UUCP (Keith Doyle) (09/09/88)
In article <6234@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: >>4) Would like to find out the names for file system devices >>currently running ("DF0:", "DH0:", "VD0:", etc.). This is for >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. I found that if you get to the DeviceList from a FileLock, it won't get you DF0: DF1: VD0: RAM: etc., you get the logical names of the disk that is in the drive, not the physical device names. Haven't tried chasing it from the RootNode though, I guess it could be different. How do you weed out devices like SER: PAR: PIPE: etc? Is it possible to determine the *device* name (not the disk name) from the FileLock in any way? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
andy@cbmvax.UUCP (Andy Finkel) (09/09/88)
In article <298@lexicon.UUCP> trh@lexicon.uucp (Tom Hegg) writes: >3) Another Lattice 4.0 question: the old version of ATOM >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; Lattice came up with some clever new hunk types, passed them by us...they looked fine. We still have some tools to modify though, to handle them. But isn't there a BLINK option to do what atom is trying to do for you ? > >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 I have a program I gave out at Devcon. As Lauren said, the devcon materials will be ready in ~4 weeks. (poof). Hmmm, I guess I could send it to the amiga.sources moderator. >6) I don't know if anybody can help with this last one, but: >I have a program that fairly regularly adds and deletes lots >of gadgets in a non-resizable SMARTREFRESH window. Do you have NOCAREREFRESH set ? -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/09/88)
In article <2241@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > I found that if you get to the DeviceList from a FileLock, it won't get > you DF0: DF1: VD0: RAM: etc., you get the logical names of the disk that > is in the drive, not the physical device names. Haven't tried chasing it > from the RootNode though, I guess it could be different. How do you weed > out devices like SER: PAR: PIPE: etc? Is it possible to determine the > *device* name (not the disk name) from the FileLock in any way? >Keith Doyle Well, you can avoid the "other" devices by first checking for a handler task (disks always have them and devices only sometimes do) and if you find it (the handler) try sending it an ACTION_INFO to see if it thinks it is a disk. The heuristics can get really complicated because the concept of device "type" is not really embodied very well in the system. (Same thing with serial type devices try enumerating them sometime :-)) Anyway, there is a gross way of finding the device from a Volume node, look at the task pointer in the volume field an compare it with the various devices that you found. I am not sure but I think that is how I did it with my "AmigaLife" file requester. I'll check tonight to see. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.