=========================================================================
 
INFO-ATARI16 Digest         Thu,  1 Mar 90       Volume 90 : Issue  267
 
Today's Topics:
                  40 folder bug [Was: Re: poolfix3]
                         A couple of requests
                  Calling callgulam from TC (2 msgs)
                         Directory Limits??!!
            Folder hierarchy and pathname length (2 msgs)
                    GNU Emacs 18.55 for Atari ST.
                     Mac emulators and Hard disks
                     Needs switch for Atari Mouse
                   Partition size limit in TOS 1.40
                      ST C programming (2 msgs)
                          Turbo C v1.0 bug?
----------------------------------------------------------------------
 
Date: 1 Mar 90 00:38:50 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
Subject: 40 folder bug [Was: Re: poolfix3]
Message-ID: <2060@atari.UUCP>
 
ljdickey@water.waterloo.edu (L.J.Dickey) writes:
 
>In article <2470@castle.ed.ac.uk> aimd@castle.ed.ac.uk (M Davidson) writes:
> | I'd like to have some sort of empirical measure of how long I can muck
> | around with my drive (setting it up etc.) before I should reboot.
 
>It is the number of directories (folders) you visit during a session
>that counts.  I think you will be safe if you set "XXX" in FOLDRXXX
>to be a number greater than the total number of directories on your
>disks.
 
That's true for Original TOS and Mega TOS.  For Rainbow TOS (TOS 1.4),
XXX need only be the number of folders you'll have "active" at once.
"Active" folders are those involved in file searches, open files, etc.
If you open a file, the folder it's in and all the parents of that
folder are "active;" if you open another file in the same directory,
you haven't increased the number of active folders. If you close both
files, those folders aren't "active" any more, and the space they took
up in the pool will be reused when necessary.
 
============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
 
------------------------------
 
Date: 28 Feb 90 22:33:22 GMT
From: tiamat!mjbtn!raider!dlh@uunet.uu.net  (Dana L. Holt)
Subject: A couple of requests
Message-ID: <176@raider.MFEE.TN.US>
 
In article <1990Feb26.162623.437@chinet.chi.il.us>, saj@chinet.chi.il.us
 (Stephen Jacobs) writes:
> I have a couple of requests for information (maybe 3).
>
> Has anyone seen a STacy offered for retail sale in the USA?
>
 
 
        I saw a STacy ad in some magazine (Popular Science maybe, i'm
not sure which one) for a STacy. A single full page article and a picture
of a STacy. Looks pretty nice. Anybody else seen this ad?
 
                                                Dana Holt
                                    dlh@raider.MFEE.TN.US
 
 
 
 
 
 
 
 
 
 
 
 
 
 
------------------------------
 
Date: 1 Mar 90 17:50:45 GMT
From:
 cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!ultra!jimh@tut.cis.ohio-st
 ate.edu  (Jim Hurley)
Subject: Calling callgulam from TC
Message-ID: <1990Mar1.175045.3607@ultra.com>
 
bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes:
 
>In article <11368@etana.tut.fi> av74381@korppi.tut.fi (Vesterinen Arto) writes:
 
>> Unfortunately have not been able to call gulam from a Turbo-C
>> program. I have tried out Michal Jaegermann's method for
>> MWC but it does not work out for TC. If anyone has figured out
>> how to call gulam from TC, please e-mail me how to do it.
 
>       your example is correct. the reason it does'nt work from Turbo C
>is that Turbo C passed the arguements in registers by default, while
>gulam is expecting them to be on the stack (like the normal C stack
>frame conventions). (is there a option in TC to do this??)
 
>       on a related note: .....
 
>--
>bang:   ?any internet host?!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi
>domain: bammi@dsrgsun.ces.CWRU.edu
>GEnie: J.Bammi
 
 
There are some gulam parameters that can be set in a startup file.
They are called, I believe: 'set env_style <style>' where
style can be three separate flavors. (Here my memory is faulty about
the types, but I use 'gulam' style).
 
I don't know quite what this means, I don't recall reading a description
in the docs. Anyone know more about this?
--
Jim Hurley --> jimh@ultra.com  ...!ames!ultra!jimh  (408) 922-0100
Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134
 
------------------------------
 
Date: 1 Mar 90 19:42:15 GMT
From: usenet.ins.cwru.edu!usenet.INS.CWRU.Edu!bammi@tut.cis.ohio-state.edu
 (Jwahar R. Bammi)
Subject: Calling callgulam from TC
Message-ID: <BAMMI.90Mar1144411@curie.ces.CWRU.Edu>
 
In article <1990Mar1.175045.3607@ultra.com> jimh@ultra.com (Jim Hurley) writes:
   >>bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes:
   >>>In article <11368@etana.tut.fi> av74381@korppi.tut.fi (Vesterinen Arto)
 writes:
 
   >>> Unfortunately have not been able to call gulam from a Turbo-C
   >>> program. I have tried out Michal Jaegermann's method for
 
   >>   your example is correct. the reason it does'nt work from Turbo C
   >>is that Turbo C passed the arguements in registers by default, while
 
   >There are some gulam parameters that can be set in a startup file.
   >They are called, I believe: 'set env_style <style>' where
   >style can be three separate flavors. (Here my memory is faulty about
   >the types, but I use 'gulam' style).
 
        env_style has nothing to do with this. env_style determines
how the environment variables are setup, and how  the
command lines/environment programs are setup before a program is lauched
via Pexec(). the possible value are
        'bk'    beckemeyer
        'gu'    gulam
        'mw'    mark williams
gulam.doc talks about what each of these means.
--
bang:   ?any internet host?!dsrgsun.ces.CWRU.edu!bammi  jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie:  J.Bammi
 
------------------------------
 
Date: 1 Mar 90 00:38:25 GMT
From: tiamat!mjbtn!raider!dlh@uunet.uu.net  (Dana L. Holt)
Subject: Directory Limits??!!
Message-ID: <177@raider.MFEE.TN.US>
 
        In reply to the message about floppy file limits. I would like to
add that the GEm desktop only allows 256 files. Just a little interesting
tid bit of info..
                                                Dana Holt
                        dlh@raider.MFEE.TN.US
 
------------------------------
 
Date: 1 Mar 90 16:15:45 GMT
From: jlm@apple.com  (Jeff Morris)
Subject: Folder hierarchy and pathname length
Message-ID: <6978@internal.Apple.COM>
 
In article <3052@sbsvax.cs.uni-sb.de> roeder@sbsvax.cs.uni-sb.de (Edgar Roeder)
 writes:
>In article <2018@laura.UUCP>, klute@heike.informatik.uni-dortmund.de (Rainer
 Klute) writes:
>> Hmm, is that really possible? I once tried out how deep a file
>> could be nested in the file system hierarchy. From the desktop
>> I created a folder "1" in the root directory, then a folder "2"
>> within "1" and so on. I ended with folder "8" and got a message
>> which told me that it is not possible to create a folder so
>> deep in the index structure. To open a file 20 or 40 levels
>> deep in the file system should not be possible.
>...
>> Any comments?
>
>This limit of 8 folder levels only applies to the desktop. The GEMDOS file and
>directory functions have no such limit. You can see this if you try the same
>procedure as above from a shell (eg. gulam).
>
>       - Edgar
>--
>
 
Suppose this could be the window limit of GEM???
 
JLM
#include <disclaim.h>
 
------------------------------
 
Date: 1 Mar 90 08:51:12 GMT
From: usenet.ins.cwru.edu!usenet.INS.CWRU.Edu!bammi@tut.cis.ohio-state.edu
 (Jwahar R. Bammi)
Subject: Folder hierarchy and pathname length
Message-ID: <BAMMI.90Mar1035335@dsrgsun.ces.CWRU.Edu>
 
In article <2056@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
 
> GEMDOS never *constructs* pathnames, so it doesn't have any buffers or
> anything (of limited size or otherwise).  When you do a Dgetpath, *you*
> supply the buffer, and it had better be big enough.  There's no way to
> tell in advance how big is "big enough," but I would choose 128 or 256
> bytes.
 
        huh? Dgetpath/gemdos whoever *does* monkey around in the buffer
you supply. if the buffer supplied to Dgetpath() is shorter than 32
bytes it clobbers stuff outside of it (my guess is that it has someting to do
with the fact that a directory entry is 32 bytes long) (i cant
remember exactly, but maybe you need to s/32/64/g above).
 
        the developers gemdos documentation states that 125 is the max
path length. i guess its either obsolete or incorrect.
 
        on a related note: gemdos(Fsfirst()) still (at T1.4) doesnt
realize that "."  ".."  "\"  or "D:\"  are directories (have attr == 0x10)
(or atleast "." and ".." should be, even if "\" is not considered to
be a subdir).
--
--
bang:   ?any internet host?!dsrgsun.ces.CWRU.edu!bammi  jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie:  J.Bammi
 
------------------------------
 
Date: 28 Feb 90 04:20:48 GMT
From:
 zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!minyos!monu6!ben@tut.cis
 .ohio-state.edu  (Nino Benci)
Subject: GNU Emacs 18.55 for Atari ST.
Message-ID: <1990Feb28.042048.23981@monu6.cc.monash.oz>
 
Has any one out in netland obtained all 27 (or so) parts of GNU Emacs
version 18.55 for the Atari ST. If so could they please mail me parts
6,7,8,9,10 as i have missed them. Much appreciated.
 
Nino Benci
School of Digital Technology
Chisholm Institute of Technology
Victoria, Australia.
 
email: ben@monu6.cc.monash.edu.au@uunet.uu.net (outside oz)
     : ben@monu6.cc.monash.oz (inside oz)
 
------------------------------
 
Date: 1 Mar 90 14:51:43 GMT
From: mcsun!hp4nl!dutrun!hans@uunet.uu.net  (Hans Buurman)
Subject: Mac emulators and Hard disks
Message-ID: <1158@dutrun.UUCP>
 
In article <37544@iuvax.cs.indiana.edu> sl198004@silver.ucs.indiana.edu (Vincent
 Schonau) writes:
>This has made me positively want a good Mac emulator when I get back,
>and a harddrive.  Anybody have any suggestions?
>I have some experience with Aladin, but I haven't heard anything about
>it in (obviously) months.
 
I have Aladin 3.0, and am a very satisfied user. It has the 64k roms.
It supports at least the SH204 and SH205, but also other drives that I
do not know of. It runs the mac software that I need.
 
Unfortunately, the Aladin people were forced out of business by an Apple
lawsuit threat a few months ago. So we won't have the 128k rom upgrade.
 
One of the Aladin people proposed a shareware version in this group,
but hasn't been heard of since.
 
>Anybody have any suggestions? (come out of that hideyhole, Europeans)
 
Here I am. We hear some good things about the Spectre. Try to take one
with you. I suppose they'll be cheaper over there. (Yes, I'm Dutch. So is
Vincent :-)
 
        Hans
 
========================================================================
Hans Buurman               | hans@duttnph.tudelft.nl | hans@duttnph.UUCP
Pattern Recognition Group  | 31-(0)15-78 46 94       |
Faculty of Applied Physics | Delft University of Technology
 
------------------------------
 
Date: 1 Mar 90 19:40:33 GMT
From:
 zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!neat.cs
 .toronto.edu!omicron.cs.fsu.edu!fsucs.cs.fsu.edu!boyd@tut.cis.ohio-state.edu
 (Mickey Boyd)
Subject: Needs switch for Atari Mouse
Message-ID: <9003011921.AA05002@fsucs.cs.fsu.edu>
 
In article <90Feb28.180837est.58129@ugw.utcs.utoronto.ca>,
 FCTY7284@RYERSON.BITNET ("Hiscocks, Peter") writes:
>After years of obedient clicking, my left mouse button has become flaky.
>I bought an Atari replacement, but it would be nice to refurbish the old one.
>Anyone know of a source for the mouse switches?
>Thanks for the help.
>
>                                     Peter
>
>
>   There are no stupid questions.
 
I have seen a friend of mine do it.  He bought the part over the counter at
an electronics supply house.  I believe Best Electronics has this part (and
others for the ST).  If anyone has the address for this company, please post
it (I was told that they sell a cable kit for hooking a 5.25" drive to the ST).
 
--
 
    -----------------------------------------------------------------------
    ---------------------------------+-------------------------------------
              Mickey Boyd            |    "Nobody can be exactly like me.
         FSU Computer Science        |      Even I have trouble doing it."
      mail:  boyd@fsucs.cs.fsu.edu   |              - Tallulah Bankhead
    ---------------------------------+-------------------------------------
    -----------------------------------------------------------------------
 
------------------------------
 
Date: 1 Mar 90 15:42:32 GMT
From: matthews@umd5.umd.edu  (Mike Matthews)
Subject: Partition size limit in TOS 1.40
Message-ID: <6189@umd5.umd.edu>
 
In article <1990Feb28.004225.3023@ultra.com> jimh@ultra.com (Jim Hurley) writes:
>I just upgraded to TOS 1.4 and was wondering if I can
>now have a partition size greater than 16Meg. My SUPRA
>utilities will let me make one, but complain that GEMDOS won't
>support it. Thanks in advance.
>
>? grumble, you call this a RELEASE note, grumble... ?
>
>--
>Jim Hurley --> jimh@ultra.com  ...!ames!ultra!jimh  (408) 922-0100
>Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134
 
TOS 1.4 will directly support 32M partitions; Supra's formatter probably
was written long before TOS 1.4 was.  I have formatted 20 meg partitions with
Supra's formatter (because HDX 3.02 does not like something about my system,
and I strongly thing it's my DMA chip) no problems.
 
HDX 3.01/2 will let any Atari support reeeal big partitions.
 
While I'm here, can anyone tell me <again?> what the cutoff point for 512 byte
sectors is using HDX?  A friend of mine formatted his Seagate 296N with his ICD
utilities (he has an ICD HA, of course), and used HDXPREP and then HDX to
partition the drive into four 20 meg partitions.  His sector size is 1024 bytes.
Someone else said that the sector size stays at 512 bytes 'til you reach the
32M+1 region.
 
Mike
 
------------------------------
 
Date: 1 Mar 90 10:33:20 GMT
From: mcsun!ukc!newcastle.ac.uk!turing!q1k2c@uunet.uu.net  (R.A.W. McGuigan)
Subject: ST C programming
Message-ID: <1990Mar1.103320.7542@newcastle.ac.uk>
 
>covertr@force.UUCP (Richard E. Covert) writes:
>
>>Are there any other C ST programmers out there on the net who would like
>>to see more C code posted??  I am interested in such code myself.
>>Well, what say folks??
>
Mmm....definitely. Its hard finding good C source code for such GEM
applications. I don't know about its distribution in the US but the UK "ST
World" magazine has a "Programmer's Clinic" section each month, usually with a
fair amount of C in it. It might be worth looking at that.
 
How would this C source be made available? A new group? FTP? ??
No matter to me - I'd be interested in whatever form it takes.
 
Andy
 
--------------------------------------------------------------------------------
Andy McGuigan,  Microelectronics and Software Engineering
                University of Newcastle upon Tyne
JANET:          R.A.W.McGuigan@uk.ac.newcastle
--------------------------------------------------------------------------------
 
------------------------------
 
Date: 28 Feb 90 15:54:15 GMT
From: njin!jvnca!njitgw!mars!mg5184@rutgers.edu  (Michael Gaines)
Subject: ST C programming
Message-ID: <1091@njitgw.njit.edu>
 
Rich,
        Sounds like one of the files I put up there.
 
                                                Mike Gaines
 
====================================================================
| "Please don't be compelled to tell |                             |
|  me the story of the boy who cried |    mg5184@mars.njit.edu     |
|  Worf."                            |                             |
====================================================================
 
------------------------------
 
Date: 1 Mar 90 17:48:14 GMT
From: zaphod.mps.ohio-state.edu!rpi!uupsi!rodan!jfbruno@tut.cis.ohio-state.edu
 (John F. Bruno)
Subject: Turbo C v1.0 bug?
Message-ID: <2300@rodan.acs.syr.edu>
 
In article <870@tnosoes.UUCP> joep@tnosoes.UUCP (Joep Mathijssen) writes:
>||   #include <stdio.h>
>||   long tab[9000];
>||   main()
>||   ?
>||       int i;
>||       long j;
>||       i = 0x2000;      /* 0x2000 = 8192 */
>||       j = 0x2000L;
>||       fprintf(stderr, "%lx, %lx\n", &(tab[i]), &(tab[j]));
>||   ?
>RESULT:
>||   561b2, 661b2
>Can anybody explain the difference in the result when using an 'int' or
>'long int' as array-index?
>Joep,
>PS: don't tell me this is a feature!
 
The first thing that comes to mind here is that the compiler is not
converting j to an int before placing i and j on the stack.  If this is
the case, and assuming i and j get put on the stack first, the stack would
look like this:
 
           0x2000 (lsw of j)
           0x0000 (msw of j)
           0x2000 (i)
 
Then, when it goes to pull two ints off the stack, it gets 0x2000 (which
gets substituted for j) and 0x0000 (which gets substituted for i. Now, we have:
 
    fprintf(stderr,"%lx, %lx\n", &(tab[0x0000]), &(tab[0x2000]) );
 
Now we have two different addresses that are offset by 0x2000 x sizeof(long)
if sizeof(long) == 8, that would explain the difference you got, but I thought
a long was 4 bytes... But this is how you could get different results by
passing the wrong size object, anyway.  If you want to use a long as an
array index, try this:
 
#define tab(X) (*(tab + sizeof(long)*X))
 
Then you can do things like:
 
tab(100000L)=4567L;
printf("ADDR=%lx, VALUE=%ld\n",&tab(10000L),tab(10000L));
 
---jb
 
P.S. - I highly recommend turning on every warning that the compiler
supports, this will usually catch things like using longs as array
indeces, and other nasty litte oversights.
 
------------------------------
 
End of INFO-ATARI16 Digest V90 Issue #267
*****************************************