HDTenEightyP/NetNews huggingface dataset:
From: Christof_Stadler@s.maus.de (Christof Stadler)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Problem with GCC
Date: 23 Dec 92 18:11:00 GMT
Article-I.D.: S.A7094
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

h>I downloaded GCC 2.3.1 recently, and ran into a problem trying it. The
h>preprocessor, gcc-cpp bombs immediately after starting it (address
h>error). I also tried version 2.2.2, which behaves in the same way.
h>However, GCC 1.37 works ok.

Maybe it's a 68030-only version?

Christof
Xref: sparky comp.sys.atari.st.tech:6450 de.comp.sys.st:2054 maus.sys.atari.software:204
From: wpv@wvoel0.han.de (Wolfgang Voelker)
Newsgroups: comp.sys.atari.st.tech,de.comp.sys.st,maus.sys.atari.software
Subject: Clean Up Directory Tool without GEM
Distribution: world
Date: 3 Jan 93 16:08:38 GMT
Organization: IN - Individual Network e.V.: Private Site in Hannover/Germany/EEC


Hello!

I'm seeking for a command line driven tool to compress, or to use the
name Atari's checkdisk3 is using, to clean up directories. It is not
necessary that this tool compress a whole disk or partion.

The program should clean up a single directory or a whole path and,
perhaps as an additional feature, should perfom a mediachange. BGMs and
other types of non-GEM but from GEMDOS used partition must be no
obstacle. 

Yes, and of course the program must be MiNT-friendly and has to be able
to work as an background process.

All hints are very wellcomed.

regards, Wolfgang
_________________________________________________________________________
Wolfgang Voelker    | E-Mail: wpv @ wvoel0.han.DE           (preferred)
Im Krummen Sieke 42 |    and: Wolfgang_Voelker @ H.maus.DE
D-3000 Hannover 21  | Tel.  : ++49-511-748818        Fax: ++49-511-722963
  Germany           |
From: rossin@hpfcso.FC.HP.COM (Ted Rossin)
Date: Mon, 21 Dec 1992 16:11:08 GMT
Subject: Re: Address space for TOS 2.06
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.sys.atari.st.tech

I asked the same question about a month ago.  Tos 2.06 starts at 0xE00000
This is very different from the location of TOS 1.00 which starts at 
0xFC0000.  I forget where it is exactly but I the deal is that in the days
of the 1040ST, TOS lived in a space that was 196K, TOS 2.06 needs more space
so they threw it at 0xE00000.  The total byte count of the TOS 2.06 ROMs is 
256K which would overlap into I/O space in the ST if placed at 0xFC0000.  
In summary, I believe the following is true.  I'm sure someone will yell if 
I am wrong:

			TOS 2.06 start: 0xE00000
			TOS 2.06 end  : 0xE3FFFF

This should be 256K if I can do the hex to decimal thing correctly.


			Ted Rossin.

P.S.  My TOS 2.06 ROMs came in and I have finished an adapter board for my
      external bus of my 1040ST to map the ROMs into the above address space. 
      I'll give it a wirl after Christmas.
Newsgroups: comp.sys.atari.st.tech
From: y0000028@rzab0.rz.tu-bs.de (Kielhorn)
Subject: Re: the pcmcia standard
Followup-To: comp.sys.atari.st.tech
Organization: TU Braunschweig, Informatik, Bueltenweg, Germany
Distribution: comp
Date: Mon, 21 Dec 1992 15:26:28 GMT

In the last issue oc c't, a german computer magazine, they
tested some Ethrnet-boards, one of them used the PCMCIA Port
of a Laptop (or Notebook?) and it seems to be pretty fast
compared to the ISA-Slot. Well, that does *not* mean much,
but it looks like a new low-cost-standart. :-)

BTW, where will I get software to connect these Eternet-tranceiver
to my STe? I would like to build a VME to PCMCIA converter. It can't be
difficult because the PC-people have already PCMCIA ports.

Axel Kielhorn
The last Atarian at TU-Braunschweig
Newsgroups: comp.sys.atari.st.tech
From: ersmith@netcom.com (Eric R. Smith)
Subject: Malloc (Was: Sending objc_draw to a buffer)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Sun, 3 Jan 1993 03:53:43 GMT

In article <2b3de6cf@p15.f202.n281.z2.fidonet> p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl writes:
>In a message of <Fri 25 Dec 92 20:52>, Conan Ford (2:281/202.0) writes:
>
> CF>  one and set up some pointers to each "page".  This is because of
> CF>  the problems GEMDOS has when you use MALLOC for more than 20
> CF>  seperate buffers (e.g. system crash :-)  ).
> CF>  (Though you probably know :-)   )
>
>Let's just hope this BUG has been fixed in MiNT. There it would REALLY be
>annoying. It's annoying now, you have to allocate memory and manage it
>yourself but of course TOS should do that for you.

The 20 Malloc per program limit was removed a long time ago (certainly
it was gone in TOS 1.4). And, of course, MiNT has no such limit.

Managing memory "yourself" (i.e. by asking the operating system for
large blocks of memory, and having your own malloc() function split
those large blocks up for your program) is still a good idea, for 2
reasons:

(1) it's faster (entering the OS is always going to add overhead), and
(2) it may save memory: on a virtual memory or memory protected system,
    the OS must manage memory in pages; so even if you ask for 1 byte,
    an entire page (4K or 8K) must be used by the OS for your block
    of memory.

Most libraries' malloc() functions will handle everything automatically,
allocating memory in large chunks (4K or 8K or even 32K) from the OS
and then splitting those chunks up as necessary. See for example the
MiNT or GNU C library malloc()/sbrk() code. All the programmer has to
remember is to use the standard C malloc()/free() functions instead
of the Atari specific Malloc()/Mfree() functions.

Eric Smith	ersmith@netcom.com	ersmith@atari.uucp
From: Vincent_Partington@p15.f202.n281.z2.fidonet
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sending objc_draw to a buffer
Date: 27 Dec 92 17:24:22 GMT
Reply-To: p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl
X-FSC-PID: LED 1.00

In a message of <Fri 25 Dec 92 20:52>, Conan Ford (2:281/202.0) writes:

 CF>  one and set up some pointers to each "page".  This is because of
 CF>  the problems GEMDOS has when you use MALLOC for more than 20
 CF>  seperate buffers (e.g. system crash :-)  ).
 CF>  (Though you probably know :-)   )

Let's just hope this BUG has been fixed in MiNT. There it would REALLY be
annoying. It's annoying now, you have to allocate memory and manage it
yourself but of course TOS should do that for you.
BTW, is that 20 blocks per program or totally?

Ta!
    Vincent

FidoNet : 2:281/202.15
NeST    : 90:500/202.15 <-- NEW ADDRESS!!!
Usenet  : vincent@nextjk.wlink.nl

--- MARSmail v1.20/4D
 * Origin: For a pager with brilliant music, use Jekyll (2:281/202.15)
Newsgroups: comp.sys.atari.st.tech
From: trek@cbnewse.cb.att.com (wayne.a.booth)
Subject: Re: file transfers
Organization: AT&T
Date: Tue, 29 Dec 1992 14:31:03 GMT
Followup-To: comp.sys.atari.st.tech
Summary: MacSee is what you need

In article <BzzMqp.64u@mentor.cc.purdue.edu> wayne@bragg.bio.purdue.edu writes:
>Hello to all,
>	Our lab needs to transfer files from Atari ST
>(STe) machines to Mac II ci.  The files are large and 
>are on 44MB syquest drives (250 -300 MB worth of info), 
... other options deleted

A third option is to use MacSee sold by Compu-Seller West (Don Bahr,
proprietor) (220 1/2 West Main Street; St. Charles, Il. 60174)
(708) 513-5220.  It will do just the trick allowing one to read or
write MacIntosh volumes (HFS or MFS) with your Atari ST or TT.

Atari Explorer On-Line Issue 12 (8/29/92) had a review claiming it
worked flawlessly during testing and was as fast as ST/TT floppy
or harddisk copies respectively.  GEM interface, no fuss, no mess,
no strain.  It also mentioned it works great with Syquests.

				Happy computing,   Wayne Booth
(only a Happy customer of Compu-Seller West and always interested
in supporting our local dealers.)
Newsgroups: comp.sys.atari.st.tech
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Subject: Re: drop down menus in GEM
Organization: Department of Philosophy, University of Utrecht, The Netherlands
Date: Wed, 23 Dec 1992 19:05:15 GMT

kuehn@math.uni-muenster.de (Ulrich Kuehn) writes:

>In article 724944923@groucho.phil.ruu.nl, hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
>>hohmuth@freia.inf.tu-dresden.de (Michael Hohmuth) writes:
>>>
>>
>Have you thought of a networking extension to GEM? Who do you think will draw
>a menu, when the used screen is on another machine somewhere over the net?
>The screenmanager there must at least have a copy of the objects to draw,
>so changing simply the object's flags is not enough, you have to set up the
>menu again by menu_bar, or use menu_icheck at all.

Uhuh... guess I just never thought about this kind of applications et.al.
Of course y're right -- point taken :).  And thanks for the explanation.

--
Hendrik Jan Veenstra    hjv@phil.ruu.nl  *  How can I save my dreams
Dept. of Philosophy                      *  in the nightmare, in the flood
University of Utrecht                    *  But I try.
The Netherlands                          *
Newsgroups: comp.sys.atari.st.tech
From: seimet@rhrk.uni-kl.de (Uwe Seimet)
Subject: Re: Unix ASV
Organization: University of Kaiserslautern, Germany
Distribution: eunet
Date: Sun, 27 Dec 1992 22:39:36 GMT

chuck@cpg.trs.reuter.com (Chuck Menard) writes:

>I'm planning on going to Germany soon.  I'm interested in looking at 
>software, and especially ASV, for the TT.  What Atari dealers should
>I visit?
I'm quite sure that there is no dealer for the ASV at all. You have to
contact Atari directly for it.

***************************************
*        Uwe Seimet                   *
*        seimet@rhrk.uni-kl.de        *
*        seimet@chemie.uni-kl.de      *
*-------------------------------------*
* I really hate this damned machine,  *
*     I wish that they would sell it. *
* It never does that what I mean      *
*     but only what I tell it.        *
***************************************
From: rdo@kynes.bison.mb.ca (Russell Ochocki)
Newsgroups: comp.sys.atari.st.tech
Subject: How do you set a disk's volume label?
Date: Thu, 31 Dec 1992 11:24:26 CST
Reply-To: rdo@kynes.bison.mb.ca
Organization: Private Site, Winnipeg, Manitoba, Canada
X-Software: HERMES GUS 1.04 Rev. Sep  5 1992

Using the following code, I can find the volume label on a disk:

#include <stdio.h>
#include <string.h>
#include <osbind.h>
#include <ostruct.h>

/* Get disk vol for specified drive */
char *
getvol(char drive)
{
	_DTA	*dta;
	char	path[8];
	char	*vol = NULL;

	path[0] = '/';
	path[1] = drive;
	path[2] = '\0';
	chdir(path);
	Fsfirst("*.*", FA_LABEL);
	do {
		dta = (_DTA *)Fgetdta();
		printf("name: %s\n", dta->dta_name);
		if (dta->dta_attribute == FA_LABEL) {
			vol = strdup(dta->dta_name);
			break;
		}
	} while (Fsnext() == 0);

	if (vol != NULL)
		return vol;
	else
		return NULL;	
}

Now, what I'd like to do is be able to change an existing label.  Or, if one
doesn't exist, I'd like to create it.

Any ideas?
-- 
____________________________________________________________________________
| _   /|  |  Russell Ochocki
| \`o.0'  |  rdo@kynes.bison.mb.ca
| =(___)= |-----------------------------------------------------------------
|    U    |  A closed mouth gathers no foot.
|_________|_________________________________________________________________
Xref: sparky comp.sys.atari.st.tech:6363 comp.sys.atari.st:18716
From: wenzel@marsu.tynet.sub.org (Markus Wenzel)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Organization: Palumbian Networks Ltd.
Subject: Re: Falcon and Unix Sys V
Summary: Not for Falcon 030, but F040
	<1992Dec15.102801.4670@spcvxb.spc.edu>
	<1992Dec15.220634.26821@cc.umontreal.ca>
Reply-To: wenzel@marsu.tynet.sub.org
X-Software: HERMES GUS 1.04 Rev. Sep  5 1992
Date: Sun, 20 Dec 1992 13:55:04 MET

In <1992Dec15.220634.26821@cc.umontreal.ca>, Kosmatos Odisseas writes:
> In article <1992Dec15.102801.4670@spcvxb.spc.edu> mauritz_c@spcvxb.spc.edu writes:
> 
> >I haven't heard if Atari's system V port will run on the Falcon.
> >Does it?  If it does, you can go take a mortgage out and purchase
> >it from Atari (if they are still selling it).  There is not another
> >unix port for Atari products.  You are stuck with whatever Atari
> >churns out.
> >
> >Chris
> 
> At the Atari Messe, When someone asked about whether ASV would run on
> the Falcon030, an Atari rep. said NO. But they also said that it would
> run on their higher end machine they were working on. (Which I got the
> strong impression they meant the Falcon 040.)

If you want Unix, you should not think of Atari as a hardware basis.
Atari Sys V will not be available for the F030, is - as far as I know -
still a developer's release for the TT which is horribly overpriced in
comparison with other proprietary Unix implementations.
Atari dropped further development in ASV, because they finally figured
out that "Unix is no market for Atari". ASV is said to be very stable, but
has an extremly low performance (especially when moving the mouse ;-) !
If they don't improve their device drivers and make a reasonable price,
then ASV is IMHO not at all interesting even for the expected F040.

If you want Unix, better get a 386/486 with Linux or BSD386, or simply
buy a NeXT or Sun Sparc Workstation. There are quite cheap 2nd hand
or clone computers.

Regards, Markus.


-- 
/dev                Markus Wenzel, University of Stuttgart
/usr/spool/mail     wenzel@marsu.tynet.sub.org / @rus.uni-stuttgart.de
~/.ircrc/nick       Marsu

### check this out with users you don't like:
cat >> ~luser/.cshrc
alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z;mv -f ~/.z ~/.cshrc'
^D

Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Falcon BUS..
Organization: SAR Systems Development & Processing, JPL
Date: Fri, 25 Dec 1992 06:10:52 GMT

In article <1hdrk0INNevm@golem.wcc.govt.nz> wells_s@kosmos.wcc.govt.nz writes:
>What did all those numbers actually mean!?

Sorry, I figured it was obvious from the posting that I had followed-up.
Those numbers are bytes per second.
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

There's a narrow border between genius and insanity, but I'm a dual citizen.
Newsgroups: comp.sys.atari.st.tech
Subject: Utility needed to read Amiga disks.
From: ajmex@brt.deakin.edu.au
Date: 3 Jan 93 15:31:41 EST
Organization: Deakin University, Melbourne

I have some files on an amiga formatted diskette that I want to read on
an atari. Is there any ultility that will enable this?

Thanks in advance,
Alister Miller.
From: cal@otter.hpl.hp.com (Colin Low)
Date: Fri, 1 Jan 1993 22:02:35 GMT
Subject: A Bomb in the Post 
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.sys.atari.st.tech

I have a problem which might appeal to the older Atari user. It is a
bug which has been driving me nuts for years, and if I don't get a
fix I'm going to fill my hard disk full of gunpowder and mail it to
Atari.

First, the system. It is one of the "black brick" 520s with external
power and an external floppy. It has been upgraded to 1 Mbyte. It has
been completely, utterly reliable in every respect EXCEPT for the

Atari SH204 Hard Disk which I have had for several years, but rarely use
because there is a bug in the system software which results in a partition
being completely buggered on a regular basis. The symptom is that
all the filenames become something like "zzzzzzzz.zzz", and most
of the files are completely filled with garbage. I have to zero the
partition to resume. It has happened on all my partitions at one time or
another. It has happened three times today. 

I am using the Atari supplied AHDI Hard Disk driver, dated 16th. June
1986. Is this the well known 40 folder problem? I am using an Atari
supplied utility to add an additional 100 folders, and despite taking
reasonable precautions to avoid encountering folders, I still get this bloody
bug.

If this stirs a flicker of a memory, and you know of a fix, please let
me know, and I'll donate some money to Greenpeace ;-)

Colin Low
From: ak354@cleveland.Freenet.Edu (Dennis Mc Guire)
Newsgroups: comp.sys.atari.st.tech
Subject: 1.44 meg Floppy
Date: 25 Dec 1992 16:08:32 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


   I have an new 1.44 meg Epson drive connected to my ST as 

Drive A:.  It will read and write disks which have been formatted

on it fine. But I can't read the disks which it has formatted on 

other drives and if I write to a disk whcich was formatted on a

different drive, it will no longer be readable.



   The jumpers are set as follows:



    | G | A | A | T | T | 0 | X | 1 |

    ---------------------------------

    | H | X | L | S | X | 2 | X | 3 |



   It is jumpered as low density (720K).  Is the 3 ms step rate

correct?
From: Vincent_Partington@p15.f202.n281.z2.fidonet
Newsgroups: comp.sys.atari.st.tech
Subject: What use is the AP_TERM message?
Date: 1 Jan 93 13:48:50 GMT
Reply-To: p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl
X-FSC-PID: LED 1.00

Hi everyone,

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

I thought AP_TERM was very interesting until I tried it out; I had my own
program catch that event and respond appropiately by quitting, AFTER
cleaning up some stuff.
But I found out that an AP_TERM message nearly never gets delivered, Mint
just gives you a signal when you're supposed to quit (for example if the
user deletes your process from U:\PROC\) and because my program didn't
catch signals it was just terminated without getting an opportunity to
clean up some things. Now I don't mind catching the signals but I was just
wondering what the use of AP_TERM is if you never get it....

According to the documentation you get it when the system shuts down or
when the resolution changes. However, the resolution only changes when all
programs have already quit (just try changing the resolution from the
desktop, you'll see what I mean) and there's no way (yet) to shut down the
machine. So what use is AP_TERM??

Ta!
    Vincent

--- MARSmail v1.20/4D
 * Origin: GigaMusic, the best music player money doesn't need to buy (2:281/202.15)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st,comp.sys.amiga.advocacy
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Falcon BUS..
Followup-To: comp.sys.atari.st.tech
Organization: SAR Systems Development & Processing, JPL
Date: Thu, 24 Dec 1992 23:49:10 GMT

Well, I finally got around to compiling this with GNU C. Here are some
numbers for the Falcon in a couple different graphics modes:

Test		640x480x2	640x480x256	320x240x16

16 bit read	6206061		3413333		5610959
16 bit write	16384000	6400000		14124138
32 bit read	6301538		3442017		5688889
32 bit write	31507692	7876923		24094118

Here's a comparison from my Mega with Turbo16:

		640x200x4

16 bit read	7876923
16 bit write	2884587
32 bit read	7876923
32 bit write	2884587

First, looking at the Mega-ST, the numbers clearly agree with the fact that
the ST has only a 16 bit bus. The read numbers appear exaggerated to me,
probably due to how the Turbo-16 cache works.

The numbers for the Falcon are a little less clear, but I'd figure that the
read speeds for 16 and 32 bit cases indicate a 16 bit bus, with the slightly
higher speed in the 32 bit case due to having to execute one fewer instruction
in the actual test loop. (Well, it's still the same instruction count, but does
a NOP really consume as much time as a post-increment?) The write speeds again
show the effect of caching, which makes this test a little suspect. As you
can see in the 640x480x2 case, the video doesn't slow down the processor at
all in the 16 bit write case, the write speed is the maximum achievable on
a 16 MHz processor with a 2 cycle write. Or rather, the 68030 cache is able
to make up for any delay that might be present. But for the 32 bit case,
the impact of the video becomes noticeable, being about 4% slower than the
theoretical maximum.

This test program only used a 2K data set, so the cache effects are too
significant in these results. I guess I should try it again with a 64K
data set, to override the Turbo-16's 32K cache and the 68030's on-chip
caches...

In the meantime, I'd be curious to see the results of this program run on
an Amiga, since we've been bandying around so much stuff about all this ...
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

There's a narrow border between genius and insanity, but I'm a dual citizen.
Newsgroups: comp.sys.atari.st.tech
From: brad@tazboy.jpl.nasa.gov (Brad Pickering)
Subject: Sozobon C for the mac?
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Wed, 30 Dec 1992 17:54:44 GMT

The following was a follow up to a message that was cross posted to
comp.sys.atari.st.tech and comp.sys.mac.programmer concerning the
posibility of porting Sozobon C to the mac.  I wanted to see if
this would generate some interest from some atari people.

basically I would really like too hear from people who know a bit
about TOS, MiNT, and/or Sozobon C, and who wouldn't mind getting
questions from a mac person.

Thanks,
  Brad Pickering (brad@tazboy.jpl.nasa.gov)

---
Newsgroups: comp.sys.mac.programmer
From: brad@tazboy.jpl.nasa.gov (Brad Pickering)
Subject: Re: Sozobon C - a free C for the Mac, too?
Followup-To: comp.sys.mac.programmer
Organization: Jet Propulsion Laboratory, Pasadena, CA
Distribution: comp
Date: Tue, 29 Dec 1992 19:27:39 GMT

I think this is a great idea.  In fact, this is sort of what I have been
playing with for the past couple of weeks.  What I want to do is emulate
TOS (the atari OS) on the mac so that all of the atari tools can work
on the mac with no changes.  I started with the source to MiNT and
compiled it under Think C tweeking it quite a bit so that it wouldn't
trample the mac os.  So far I have been able to run some very simple
programs like 'echo' and 'cp'.  I still have lots of problems with
more complicated programs like 'sh'.  I am especially having difficulty
with the fork calls.  It has something to do with the code I modified
so that all processes would run in supervisor mode.  Any way, I just
ordered a book on the 68040 so that I could investigate running user
level code on my mac.

Assuming we got something like this running, we could use the same sort
of techniques that MacMINIX uses to write mac code useing a regular
K&R compiler.  In mac minix, mac traps are interfaced by code that loads
the appropriate a5 from a global variable before calling the trap.
Instead of pc relative code generation like most mac compilers, atari
compilers generate relocation information so that it can be relocated
at execution time.  On the mac, we could have the first routine be
a pc relative routine that loads and relocates the TOS formatted exectable
from a resource.  One of the biggest problems with this is in debugging.
Macsbug expects the names of routines to be imbedded into the code at
the end of each routine.  Sozobon C doesn't put this information in
the code, so bugs are much more difficult to track down.

My opinion is that the goal of getting Sozobon C generating Mac Programs
is very doable.  I am very curious about what the atari people think
about this.  Are there any atari people out there who know a bit about
TOS, MiNT, and/or Sozobon C who wouldn't mind a few questions from
some mac people.

Anyway, theres my comments.  I would certainly like to see this discussion
continue.

Brad Pickering