HDTenEightyP/NetNews huggingface dataset:
From: ersmith@netcom.com (Eric R. Smith)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
Date: 13 Jan 93 03:00:29 GMT
Article-I.D.: netcom.1993Jan13.030029.1407
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <1iv954INN1geq@rs1.rrz.Uni-Koeln.DE> kim@vax.mpiz-koeln.mpg.dbp.de writes:
>In <1993Jan8.183133.12773@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:
>
>>The answer is quite simple: use malloc() and free(). This has 3 advantages:
>
>>(1) It will work in accessories, if your library is sensible (most are).
>>    The OS Malloc() function cannot be called from accessories at all.
>
>I have a question about this. From what  I  understand,  malloc()
>manages memory that is in turn allocated by Malloc() from the OS.

This is generally true, but a clever library will detect whether the
program is running as an accessory or an application and adjust malloc()
to behave accordingly; for accessories, if the amount of memory requested
would exhaust the initial 'pool' of memory that the accessory allocated
when it was starting up, then the malloc() call will fail. For applications,
the library malloc can of course call the OS Malloc to obtain more
memory.

(So whether malloc() is safe to use in an accessory depends on which
library you're using. The GNU C and MiNT libraries certainly
give the correct behaviour for accessories; I can't vouch for
any others, but I'm sure some do.)

>Two comments on this: Firstly, I have never  understood  why  TOS
>won't  let  accessories  Malloc() their own memory, but considers
>memory Malloc()'ed by accessories to belong to the  main  process
>running  at  the  time  the  Malloc()  occurs. Does anyone know a
>sensible reason why that is? Secondly,  this  silly  problem  may
>become  increasingly  irrelevant  when  MultiTOS  finally becomes
>available...

GEMDOS is a single tasking OS. That means that as far as GEMDOS is
concerned, only one application is active at a time. GEM does some
tricks to make it look to the user like accessories can also be
active; but GEMDOS doesn't know about these tricks, all it knows about
is its 1 main application. So every system call (including Malloc,
and also including Fopen and other file calls) made to GEMDOS occurs
in the context of the 1 GEMDOS program running, i.e. the "main"
application.

MultiTOS of course will change this. Actually, the whole concept of
an "accessory" becomes rather irrelevant with MultiTOS (since there's
no need for accessories, you can just write applications that stay
around as long as the user wants). Of course MultiTOS does load
accessories (for compatibility) and in fact every accessory becomes
a separate MiNT process (so they can Malloc if they want to; but
an accessory that takes advantage of this feature wouldn't work
under old TOS, and as I said there's really no reason to write
a MultiTOS-only accessory since they can't do anything normal
applications can't do. Applications can even make a menu_register
call to change the way their names appear in the "Desk" menu!)

Regards,
Eric
From: pyr579@oz.plymouth.edu (Technoid)
Newsgroups: comp.sys.atari.st.tech
Subject: Changing Drive in Sozobon
Date: 6 Jan 93 02:33:52 GMT
Reply-To: pyr579@oz.plymouth.edu (Technoid)
Organization: Plymouth State College - Plymouth, N.H.

Hello,

	I recently made a post concerning the chdir() command in
Sozobon C 1.33i and because I made a slight error in my reading of
the docs I mostly received responses telling me that I was mistaken.
I do not mean to complain, and thanks to those who did try to help,
but wouldn't it have been just as easy to tell me how to change the
drive rather than simply informing me that I wasn't using the 
chdir() command correctly? OK, anyways, can someone please
tell me, or show me code in which the current drive is changed?
I only really have the dlibs text and Cmanship Complete to work
with, neither of which have this information. Even if you do
not use Sozobon, but know how to change the drive, please
respond, Sozobon is suppossed to be Alycon compatible, and I
assume there is a GEMDOS convention for doing this task.

Stephan


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  pyr579@oz.plymouth.edu      Stephan R. Cleaves      Salamanders Are Slick...
  	       Newts Are Neato-van...    Chameleons Are Cool...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
From: marco@sys6626.bison.mb.ca (John Perry)
Newsgroups: comp.sys.atari.st.tech
Subject: What terminal program should I use to call a UNIX machine from my ST
Date: Tue, 05 Jan 93 22:05:29 CST
Organization: System 6626 BBS, Winnipeg Manitoba Canada

I was wondering if anyone could recommend a modem/terminal program to use 
when I dial-up UNIX machines?

Thanks in advance.

    *********************************************************************
    *   John Perry, Winnipeg, Manitoba    |       GEnie: J.PERRY13      *
    * INTERNET: marco@sys6626.bison.mb.ca | Data Phone: (204) 772-7349  *
    *********************************************************************
From: pf21@unix.brighton.ac.uk (Paul)
Newsgroups: comp.sys.atari.st.tech
Subject: ATSpeed on a STE
Date: 7 Jan 93 14:05:47 GMT
Organization: University of Brighton, UK

I have recently purchased the ATSpeed 8Mhz emulator for intended use on my STE,
at the time the guy behind the counter said he only had the new STE adapter
with room for the new TOS chips on him (of which were extra), he said the normal adapter was at home and he would simply post it on!

Here I am 8 weeks later, still waiting after phoneing 3 times!!.

Now, apprently the plain adapter is sold seperatly.

So, what really is the situation ?  Surely everything would come complete ?

  	 
-- 

        Paul Finch - Leader of the WIMPs forever organisation
        pf21@uk.ac.bton.unix      or      pf21@unix.bton.ac.uk
 "ADA was invented to give Basic programmers, something to look down to"
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: What use is the AP_TERM messag
Date: 3 Jan 93 12:58:00 GMT
Article-I.D.: K.A50525
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

Vincent,

p>I had a chance to have a look at MultiTOS at a friend who is an official
p>MultiTOS beta-tester and I was very impressed by it.
p>While I was there I had a look at some of the very interesting
p>documentation that goes with it and a saw in GEM.DOC that there are some
p>new events: WM_UNTOPPED, WM_ONTOP, AP_TERM and some others.

all the developers out there who are registered with Atari have signed a
"Non Disclosure Agreement" (as I have, too), so you'll have to wait for answers
until MTOS is finished and available to the public.
The behaviour of the new stuff in MTOS is still subject to change, since MTOS
itself is in beta state.

- Peter -
From: mjl-b@minster.york.ac.uk
Newsgroups: comp.sys.atari.st.tech
Subject: What is user activity?
Date: 12 Jan 93 15:20:20 GMT
Organization: Department of Computer Science, University of York, England

Having posted my screen blanker to c.b.a.st and the Atari archive, I got
some new feedback about it and screen blankers in general.

As well as pointing out bugs, the problem of detecting user activity was
raised. My screen blanker detects user activity in two ways.

It hooks in an IKBD interrupt handler and hence detects key depression (and
release) and mouse movements. It also has a hook into the BIOS trap, so that
any output via the BIOS bcon*() routines is regarded as "activity" --
something is happening.

The problem comes with those programs that install their own IKBD handler
and that also do not do any BIOS output. There aren't many of these programs
around, but it would be nice to have a consistent way of detecting user
activity that worked with everything.

Jwahar Bammi suggested watching for VDI blits (i.e. calls to vro_copyfm). I
don't like this because an additional GEM/AES handler will make the already
slow VDI and AES even slower. I also have a gut feeling that there may be
programs out there that blit stuff around even when nothing's happening.
There's also the problem of those programs that use their own blit code for
speed (such as Tempus and That's Write).

So, what do people think are good ways of detecting user activity? What
about multiple applications under MultiTOS? Is watching for blit operations
a good idea?

Mat

| Mathew Lodge                      | "What think you, my lord, of... Love?" |
| mjl-b@minster.york.ac.uk          | "You mean rumpy-pumpy?"                |
| Langwith College, Uni of York, UK |  -- Blackadder II                      |
Newsgroups: comp.sys.atari.st.tech
From: ersmith@netcom.com (Eric R. Smith)
Subject: Re: How do you write a CPX
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Sun, 10 Jan 1993 22:31:53 GMT

In article <H.ea.0zo_0ptziBA@semprini.tdkcs.waterloo.on.ca> cherborth@semprini.tdkcs.waterloo.on.ca writes:
>In <1993Jan8.163112@cs.bham.ac.uk>, David Oakley writes:
>> 1. The best way to find out about CPXs is to buy DocSupport II. Not that I've
>> managed to write one... Anyone have CPX code for Lattice C?

>Do you require Pure C/Turbo C to write a CPX?  I was under that
>impression (the _only_ CPX sample code I've ever seen was Turbo C
>code)...

No, of course not. The Atari developer's kit comes with CPX documentation
and sample code. I can't remember off-hand if it compiles with Lattice C
as is, but I'm sure that HiSoft could help registered Lattice C owners
out with Lattice specific CPX code.

Regards,
Eric
From: michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: drop down menus in GEM
Organization: Fidonet. Gate admin is fido@socs.uts.edu.au
Date: 26 Dec 92 11:40:08 GMT

Original to: hohmuth@freia.inf.tu-dresden.de
In a message of <10 Dec 92 12:16:14>, hohmuth@freia.inf.tu-dresden.de
(3:713/602) writes:

 >> When using drop down menus how do you get the chech marks to work?
 >> 
 >> Have tried using the AES routine MENU_ICHECK but this does not seem to
 >> make any difference. Have tried changing the status of the object in
 >> the tree using OBJC_CHANGE but this doesn`t effect it either.
 h> 
 h> menu_icheck should do the job. (objc_change should also, but this is not
 h> documented and will probably not work with MultiTOS).

Hey? Are you saying objc_change() is totally 'undocumented'? or just that
using it on menu items is?  I thought it was a really useful function... 8)

 h> Michael

\`miff`                                                       /|\

--- ScanMail 0.68 X0501
 * Origin: That Which Is Not, ST in SA. 61-8-232-5722 (3:800/842)
From: Bob_BobR_Retelle@cup.portal.com
Newsgroups: comp.sys.atari.st.tech
Subject: Re: TT VME Interrupt help needed!
Date: Sat,  9 Jan 93 01:40:13 PST
Organization: The Portal System (TM)

Tony Mountifield asked about the VME implementation on the TT.
 
You've just discovered the joys of dealing with non-standard
implementations of "standards".
 
The "AVME" slot on the TT is only a partial implementation of
the VME standard, similar to the way the "ACSI" port was a
crippled SCSI implementation.
 
The Atari implementation of the AVME port does *not* have any
provisions for bus-mastering, which it sounds like the Ethernet
card assumes is available.
 
The only useful cards for the TT are passive devices like
graphics cards, which do not need to take control of the bus.
 
This leaves out a very large percentage of the "hundreds and
hundreds of VME cards" we often hear about...
 
As Alan Pratt said, "maybe next time"...
 
BobR
From: jornmoe@fredrik.atari.no (Joern Moe)
Newsgroups: comp.sys.atari.st.tech
Organization: None
Subject: Re: Mercury UUCP for the ST
Reply-To: jornmoe@fredrik.atari.no
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Sun, 10 Jan 1993 22:13:22 MET

In <yDm5wB4w165w@status.gen.nz>, Jon Clarke writes:
>Hello again,
> 
>The other day I request information on the Mercury UUCP "paths" file
>structure.  I have had no replies which suprised me.
> 
>Does anyone out there use Mercury at all?
> 
>If you do can you email me a copy of your PATHS file (\mercury\paths)
>as some of my users are unable to post mail back to this site without
>it.

I think most poeple are using HERMES. Try looking for latest release of
HERMES!


-- 
  _______________________________________________________
 / Joern F. Moe /  All above is my own personal opinion! \
/ Oslo, Norway /  Any lack of opinion above is also mine! \
-----------------------------------------------------------
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
Date: 12 Jan 1993 21:19:48 +0100
Organization: Regional Computing Center, University of Cologne
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
NNTP-Posting-Host: rs1.rrz.uni-koeln.de

In <1993Jan8.183133.12773@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:

>The answer is quite simple: use malloc() and free(). This has 3 advantages:

>(1) It will work in accessories, if your library is sensible (most are).
>    The OS Malloc() function cannot be called from accessories at all.

I have a question about this. From what  I  understand,  malloc()
manages memory that is in turn allocated by Malloc() from the OS.
The advantage is that memory is allocated in larger  chunks  from
the  OS.  In  other  words,  a  malloc() call will give rise to a
Malloc() call if the malloc() function cannot find a sufficiently
large  chunk  of  memory  within  the memory already owned by the
process. I conclude from this that it may not be entirely safe to
use  malloc()  in accessories. Rather, it must somehow be ensured
that the amount of  malloc()'ed  memory  in  an  accessory  never
exceeds  the  amount of memory which is initially reserved by the
accessory and managed by the accessorie's malloc()  function.  Is
this line of reasoning correct?

Two comments on this: Firstly, I have never  understood  why  TOS
won't  let  accessories  Malloc() their own memory, but considers
memory Malloc()'ed by accessories to belong to the  main  process
running  at  the  time  the  Malloc()  occurs. Does anyone know a
sensible reason why that is? Secondly,  this  silly  problem  may
become  increasingly  irrelevant  when  MultiTOS  finally becomes
available...

Greetinx, Jan

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
From: ekrimen@wet.UUCP (Ed Krimen)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon Monitors (?)
Date: 11 Jan 93 19:15:55 GMT
Organization: Wetware Diversions, San Francisco

In article <C0oLvD.Bsp@cck.coventry.ac.uk> jat@cch.coventry.ac.uk (STBW) writes:
>
>	What I need to know is what sort of monitor will I need to buy, so that
>I can display all the Falcon modes upto the 768x480 'True colour' 
>(Over-scanned) without interlace, and still be able to use it on my STe in
>Low, Med and High reses ?

Using the monitor on your STE in all three resolutions will limit your choices.
I'd recommend an NEC 3D, Princeton 1400 Ultra, or Sony 1302.  All three are
available from different places and they'll all work on the Falcon and STE
(with a switchbox on the STE).  They should be available for around $400.

To be honest though, I don't quite understand all the graphics modes of the 
Falcon, and I'm not sure if these monitors will work in that 768x480 
non-interlaced true-color mode that you want.  The monitors will work with
the Falcon, but I'm not sure in that particular mode.

-- 
   |||    Ed Krimen
   |||    ekrimen@wet.uucp
  / | \   E.KRIMEN (GEnie)
From: wmtwen@rw8.urc.tue.nl (Erlend Nagel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
Date: 8 Jan 93 12:59:45 GMT
Reply-To: wmtwen@urc.tue.nl

Well after reading quite of lot of posts on what to use Malloc or
malloc en Mfree or mfree I am a bit confused...
I have just begun programming under GEM and am trying to write a decent
wordprocessor (Oh my god... not another wordprocessor...). Now I need
stacks of 32K each (just an arbitrary number I chose, so that the
blocks would be not too small but would not use up too much memory
either). These stacks will be used until so much has been deleted that
the last one can be freed or until the text has been closed.
At the moment I decided to use Malloc and Mfree, because these are OS
primitives and I thought that my programs would at least remain
compatible with new OS releases that have different memory allocation.
And also it seems to me that using Malloc saves a bit of memory because
the malloc function does not have to be linked.

Question:
Did I do wrong?

Erlend.
From: Vincent_Partington@p15.f202.n281.z2.fidonet
Newsgroups: comp.sys.atari.st.tech
Subject: Re: What use is the AP_TERM message?
Date: Sun,  3 Jan 93 09:01:38 +0100
Reply-To: p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl
Distribution: world
X-FSC-PID: LED 1.00

In a message of <Sat  2 Jan 93 09:25>, Uwe Seimet (2:281/202.0) writes:

 US> It works exactly as defined and does make sense. ALL program active
 US> when changing the resolution from the desktop have to know AP_TERM.

Yeah, but the funny thing was that the resolution only got changed when you
quit the desktop itself by deleting it's file from U:\PROC

 US> If you are interested in it you should register yourself as
 US> developer. You can't expect
 US> to get details concerning MTOS in the net because of non-disclosure
 US> agreements.

You've got a point there. So how do I become a registered developer without
having a big firm behind me? Do I just write a letter to Atari Benelux (for
Holland, where I live) and ask them?

Ta!
    Vincent

--- MARSmail v1.20/4D
 * Origin: GigaMusic, the best music player money doesn't need to buy (2:281/202.15)
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: A Printer Question.
Date: 10 Jan 93 16:37:00 GMT
Article-I.D.: K.A52791
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.16/hb

r>epsom timings (as opposed to centronics timings - is this right?) I can
r>transmit characters to the printer, and, they do actually appear on the
r>paper, but generally there's two of each.  Sometimes three.  Occasionally
r>I'm lucky and just get the one character.

You'll have to add a TTL driver logic into the STROBE line, since the Atari ST
strobe output is too weak for old printers.
Newsgroups: comp.sys.atari.st.tech
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Re: GFA Basic 4.0
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Mon, 4 Jan 1993 23:08:07 GMT

In article 6187@dcs.warwick.ac.uk, leo@dcs.warwick.ac.uk (Leo Hendry) writes:
>In article <2b4556b3@p15.f202.n281.z2.fidonet> 
>>Will this also include structs or records? I had heard a rumour that it
>>would and that would be a first: a basic with structs..
>
>....Apart from most BASICs on PCs which have had them for at least 4 years and
>Helix BASIC on the Arc.

Uh, _which_ BASICs on PCs support real structs and records?  I rather thought
that most BASICs did not... or have I been missing something?

Anyway, the thread is about GFA for the Atari, not PCs.
---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________


Newsgroups: comp.sys.atari.st.tech
From: heraud@boole (HERAUD pascal)
Subject: Re: U Mich FTP address?
Organization: University of Grenoble (France)
Date: Wed, 6 Jan 1993 17:29:10 GMT

marco@sys6626.bison.mb.ca (John Perry) writes:

>Could someone pleae mail me the address for the ftp at the University of 
>Michigan?

>Thanks.

>    *********************************************************************
>    *   John Perry, Winnipeg, Manitoba    |       GEnie: J.PERRY13      *
>    * INTERNET: marco@sys6626.bison.mb.ca | Data Phone: (204) 772-7349  *
>    ********************************************************************* 

write to atari.archive.umich.edu


-- 
////HERAUD|SELDON|CAPTAIN BUG//heraud@ufrima.imag.fr////
Game over..Insert coins
From: at731@cleveland.Freenet.Edu (Troy L. Nothnagel)
Newsgroups: comp.sys.atari.st.tech
Subject: How to change text in free strings?
Date: 6 Jan 1993 10:57:07 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: at731@cleveland.Freenet.Edu (Troy L. Nothnagel)
NNTP-Posting-Host: hela.ins.cwru.edu


Could I have an example of how, exactly to change the text in a free
string under MW's C?  I've been trying to use rsrc_gaddr but haven't
been able to get it right.
 
Many thanks...

Newsgroups: comp.sys.atari.st.tech
From: marcob@ull.research.ptt.nl (Blom M.A.)
Subject: Re: Porting UNIX Code to the ST
Organization: PTT Research
Date: Fri, 8 Jan 1993 12:30:49 GMT

In article <1993Jan7.124324.27805@its.bt.co.uk> jvt@its.bt.co.uk (John Trickey) writes:
>In article <1993Jan5.214420.8268@sae.com> malay@sae.com writes:
>>
>>I have some code that generates a binary file - I compiled it with GCC 2.3.1
>>and ran it on the ST - it works fine, it generates a binary file; however, the
>>print statements seem to be outputting a CNTRL-M (^M) - I don't need these
>>extra characters what should I do to get rid of them???
>
>
>The problem you have encountered is that Unix treats all files alike while
>DOS, TOS etc do not. In Unix the open is fopen(filename,mode) where mode is
>a char * of "a","r","w","r+","w+","a+". In TOS these are for text files with
>CRLF being converted to LF on input and LF being converted to CRLF on output.
>Note CR is ^M.
>To switch this off you need to open the file in binary mode. These modes
>are "ab","rb","wb","rb+","wb+","ab+". The format "r+b" etc is also acceptable.
>

Actually, in the Mint library there is a function for this called _binmode().

Quote from the source of _binmode():
 *      if called with TRUE, then subsequently all fopens have _IOBIN
 *      by default  on open. This will make life much easier for
 *      people who have been using the Gnu lib (any my job with the compiler
 *      much easier too, don't have to go hunting for fopens())

In other words, _binmode(TRUE) makes sure that all calls to fopen()
automatically open files in binary mode.

Unfortunately, this doesn't solve the problem for programs that use stdout
to write (binary) results to a file, i.e. programs that simply use printf()
and rely on IO-redirection from within a shell. Many Unix programs do this
(pbmplus, cjpeg, djpeg, etc.) The problem with this is that stdout is
already open, and NOT in binary mode. There doesn't seem to be a (legal) way
to set stdout to binary mode. Still, there is a trick, but it only works with
gcc (I still use version 1.39 or so) and the MiNT library. It may NOT even work
with future versions of the MiNT libraries. OK, now for the trick:
In main(), before any output is sent to stdout, I add this to the code:

stdout -> _flag |= _IOBIN;

This sets stdout to binary mode. It relies on how the MiNT library internally
represents and deals with files. I've successfully compiled djpeg en cjepg
(version 4) with this trick without changing anything else in the code.
I also used it to compile the previous (=old) version of pbmplus.

Perhaps someone working on the MiNT library could add a function to the library
that sets stdout to binary. This would make porting Unix programs somewhat
easier. And it would turn this trick into a feature :-)

Marco Blom.
Newsgroups: comp.sys.atari.st.tech