HDTenEightyP/NetNews huggingface dataset:
From: vicb@clark.edu (Victor Bruhn)
Subject: How to get fastest text output?
Organization: Clark College, Vancouver, Wa.  USA
Distribution: na
Date: Sat, 9 Jan 1993 05:40:49 GMT

Well, the title pretty much says what I need to know.  

I need the fastest method for printing text to a virtual workstation from C.

Having lots of options doesn't really matter; usually I use v_gtext for
the job, but is this the fastest method?  Any help or insight would be
appreciated; I'm fairly ignorant on such matters.  I've not had to worry
about speed with VDI calls yet, as I only need one of them to be fast, and
it is (thanks to the blitter); all the rest of my screen layouts only need
to be done once (I'm working on a game and need the fastest way to update
scores.)

Thanks in advance,
Victor Bruhn
vicb@clark.edu
From: dxo@cs.bham.ac.uk (David Oakley)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Changing Drive in Sozobon
Date: 8 Jan 93 16:40:36 GMT
Organization: University of Birmingham

I can't see any postings in reply, so the GEMDOS call to change drive is

dsetdrive(number);

where number is 0 (A:), 1 (B:) etc.

I think it's dsetdrive... look in OSBIND.H...

I hope I'm not talking jibberish, so if I am someone please correct me!

David.
From: subiaagb@w350zrz.zrz.tu-berlin.de (Andre Pareis)
Newsgroups: comp.sys.atari.st.tech
Subject: VDI 'load fonts' question
Date: 8 Jan 1993 16:09:41 GMT
Organization: Dept. of CS, Techn. University of Berlin
Distribution: world
Reply-To: pareis@cs.tu-berlin.de
NNTP-Posting-Host: w350zrz.zrz.tu-berlin.de

Hello,

I have a problem with the VDI routine 'load fonts'. Does the
workstation handle have to be a physical or a virtual one?
And, if it may be a virtual handle, do I need to load the fonts
for every new virtual workstation or is one time enough?

How many virtual workstations are possible? Fixed number or not?

-- 
			+-----------------------------------------------+
			| Andr'e Pareis |  Techn. University of Berlin	|
			|-----------------------------------------------|
			| e-mail:    pareis@cs.tu-berlin.de		|
			|	     subiaagb@w350zrz.zrz.tu-berlin.de	|
			| NeXT-mail: subiaagb@w271zrz.zrz.tu-berlin.de  |
			+-----------------------------------------------+
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: VDI 'load fonts' question
Date: 10 Jan 93 16:39:00 GMT
Article-I.D.: K.A52792
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.16/hb

p>I have a problem with the VDI routine 'load fonts'. Does the
p>workstation handle have to be a physical or a virtual one?

Generally spoken, use the handle of the workstation you want to use the fonts
on. For the screen, it's a virtual one, for other devices, it's physical.

p>And, if it may be a virtual handle, do I need to load the fonts
p>for every new virtual workstation or is one time enough?

You have to load them for every workstation, since resolutions will differ on
different devices.
p>
p>How many virtual workstations are possible? Fixed number or not?

No docs on this topic... You can open workstations as long as v_opnvwk()
doesn't return an error condition :-)
Newsgroups: comp.sys.atari.st.tech
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Re: UNIX/Terminal Programs
Organization: Dept. of Computer Science, University of Ottawa
Date: Thu, 7 Jan 93 16:15:11 GMT


Uniterm isn't particularly "more UNIX compatible"; it is specifically
"more VT100 compatible."  (or VT102 or VT200, as you prefer)

Most of the terminal programs that CLAIM to be VT100 compatible aren't
terribly compatible.  If you compare them to a REAL VT100 terminal,
you'll find some differences.

The UNIX "termcap" system allows you to hook almost ANYTHING up, and
use MOST of its capabilities.

If you "lie" about which terminal you're using, termcap won't know
that, and it'll happily send control sequences to the terminal that
your terminal (or terminal emulator) can't handle.

When you use Uniterm, there aren't any "lies".  There are a few ways
in which it doesn't conform with a "real" VT100; it's mostly in
dealing with special commands for creating customized character sets.
That's something that termcap doesn't know about, or use.

In principle, you should be able to write termcap entries for any
particular terminal/terminal emulator, and if it's customized well
enough, it should work perfectly.  That's something I don't feel like
getting into.

-- 
Christopher Browne                |     PGP 2.0 key available
cbbrowne@csi.uottawa.ca           |======================================
University of Ottawa              | Genius may have its limitations, but
Master of System Science Program  | stupidity is not thus handicapped.
Newsgroups: comp.sys.atari.st.tech
From: davidli@simvax.labmed.umn.edu
Subject: Re: help me with GNU c please.. i don't know what files to get.
Reply-To: davidli@simvax.labmed.umn.edu
Organization: Health Computer Sciences, U of MN, Mpls
Distribution: na
Date: Mon, 11 Jan 1993 19:59:17 GMT

In article <C0nM1x.BE8@rahul.net>, wilsont@rahul.net (Timothy Wilson) writes:
>I'd like to use GnuC. 
>I've gotten the files out of /Gnustuff/Tos/gcc 
>but there is no linker, ar, or docs.
>I also got the lib and include files.

They should be found in the ../Gnustuff/Tos/Util.

The latest versions are in the file 'utlbin33.zoo'.

-- DPZ
Newsgroups: comp.sys.atari.st.tech
From: rosenkra@convex.com (William Rosenkranz)
Subject: Re: Porting UNIX Code to the ST
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Fri, 08 Jan 1993 06:02:47 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <ENTROPY.93Jan7224017@kropotkin.gnu.ai.mit.edu> entropy@gnu.ai.mit.edu (maximum entropy) writes:
>Alternatively, the call:
>
>  _binmode(1);
>
>somewhere at the beginning of a program will cause all fopen()s to
>default to binary mode (you can then force text mode with the "t"
>modifier in the mode specifier.)  It's much easier, (and cleaner,
>IMHO) to make this one small hack than to hunt down all the file mode
>arguments all over a large program.

unfortunately, this does not effect stdin/stdout/stderr (which are set
in the startup code). to make them binary, you have to set a global
(which at the moment escapes me, something like int default_mode). i
find setting the global even easier than using binmode(). for example
i have made a binary cat, od, etc.

-bill
rosenkra@convex.com

-- 
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com
From: rossin@hpfcso.FC.HP.COM (Ted Rossin)
Date: Mon, 4 Jan 1993 17:01:40 GMT
Subject: TOS 2.06 + $1 works in 1040ST
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.sys.atari.st.tech

I got TOS 2.06 to work in my 1040ST with 3 TTL chips (<$1).  If anyone is
interested in how to do it send me email and I send the current version of
a document that I have been working on.  Also, Can someone tell me how to 
upload to the archive?


			Thanks

				Ted Rossin
Newsgroups: comp.sys.atari.st.tech
From: ersmith@netcom.com (Eric R. Smith)
Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Wed, 6 Jan 1993 22:49:37 GMT

In article <1993Jan4.203951.6091@dcs.warwick.ac.uk> leo@dcs.warwick.ac.uk (Leo Hendry) writes:
>In article <1993Jan3.035343.15539@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:
>>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.

>Do you know of any librarys that will Mfree() blocks once all parts of them
>have been free()ed though?  If none do then we have know choice but to use
>Malloc() directly in a multi-tasking system or else the user will have to
>shut down applications and restart them to free "lost" memory.

Yes, some libraries do Mfree() blocks. Most do not. There are advantages
and disadvantages both ways (the advantage of *not* freeing the memory
is speed; if your program needs to malloc() again and the block *is*
freed, then there is an overhead of 2 system calls (Mfree and then another
Malloc).

It is possible that a program will need to do a very large malloc(), free
the memory, and then never need that much memory again. In this case
there could be "lost" memory. I still recommend using your C library
malloc() function, though, because this kind of situation is relatively
rare (and easily special-cased around, i.e. you can use Malloc/Mfree
for specific large blocks of memory that you know you will never need
again).

Programs that use Malloc and Mfree for general purpose memory management
(i.e. that have lots of calls like "foo = Malloc(100L)") are already
slower than they need to be, and will definitely consume far more
memory than necessary under memory protection/virtual memory versions
of MultiTOS or TOS.

Finally, the other advantage of malloc() and free() is portability;
these are standard C functions and so are available in every library
and on every platform, not just the Atari. (I know, that's often not
a concern if you're only writing for the Atari ST, but it never hurts
to make your software easy to port to other machines or operating
systems.)

Eric Smith	ersmith@netcom.com
Opinions expressed above are my own; Atari has their own opinions, I'm sure.
From: marco@sys6626.bison.mb.ca (John Perry)
Newsgroups: comp.sys.atari.st.tech
Subject: U Mich FTP address?
Date: Sun, 03 Jan 93 20:15:22 CST
Organization: System 6626 BBS, Winnipeg Manitoba Canada

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  *
    ********************************************************************* 
Newsgroups: comp.sys.atari.st.tech
From: mh1@irz213.inf.tu-dresden.de (Michael Hohmuth)
Subject: Re: drop down menus in GEM
Keywords: AES, GEM
Reply-To: hohmuth@freia.inf.tu-dresden.de
Organization: Dept. of Computer Science, TU Dresden, Germany
Date: Tue, 5 Jan 1993 14:22:17 GMT


In article <3_800_842_fidonet2b3c36c4@Kralizec.fido.zeta.org.au>, michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith) 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)

The effects arising when using it on menu items are not documented.
Yes, objc_change is still a useful function. :)

Michael
--
Internet: hohmuth@freia.inf.tu-dresden.de
Newsgroups: comp.sys.atari.st.tech
From: rosenkra@convex.com (William Rosenkranz)
Subject: nroff 1.21 src posted
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Fri, 08 Jan 1993 23:27:17 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.


i finally got 'round to posting the src for nroff 1.2pl1 (aka 1.21).
it is nroff121s.zoo on atari.archive. this corresponds to the binary
only post of a few months ago (nroff121b.zoo, which also had binaries
for man and manpager). this post should satisfy several requests by
people.

this src compiles with gcc 1.40 and MiNT libs at pl 19. no doubt it will
compile with libs pl 25 and more than likely with gcc 2.2 or 2.3. i just
have not tried this.

enjoy...

-bill
rosenkra@convex.com

-- 
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com
From: michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Info about IDE-bus wanted.
Organization: Fidonet. Gate admin is fido@socs.uts.edu.au
Date: 26 Dec 92 11:27:32 GMT

Original to: epklel@kaepk.ericsson.se
In a message of <10 Dec 92 13:11:57>, epklel@kaepk.ericsson.se (3:713/602)
writes:

 e> I need information about the IDE-bus:

I can give you some general information, but I should warn you - to the best
of my knowledge, there was only ever a draft specification produced, which
bears only a superficial resemblance to the interface as it stands. 

 e> - Pinouts of the port.
 e> - Signal timing diagram.

Sorry, can't help there. (I had the info, but having determined that the
ST's parallel port couldn't drive it, unlike a PC's, I threw it out)

 e> - How does it work:
 e>   - Is it a sort of protcol used or
 e>   - does it use register map (like an ordinary periferal)?

The IDE interface emulates very closely the register map and operation
principles of the standard ISA bus harddisk controllers.

To talk to them you'll need a 16-bit wide bidirectional databus (although
some can be convinced to talk 8 bits wide, and all commands are only 8bits
wide)

If you intend to talk to it with any speed, you'll need to provide
appropriate DMA-type signals, otherwise you can just read a sector at a time
out of the sector buffer.  

From memory, you'll also need about 5 outgoing control lines, and 3 incoming
ones.

Sorry I can't be more specific - if you still need the details after the
summary, I'll see if my source can get the data again.

 e> Lennart

\`miff`                                                       /|\

--- ScanMail 0.68 X0501
 * Origin: That Which Is Not, ST in SA. 61-8-232-5722 (3:800/842)
Organization: Penn State University
Date: Wed, 13 Jan 1993 00:35:40 EST
From: <SML108@psuvm.psu.edu>
Newsgroups: comp.sys.atari.st.tech
Subject: 2 chip vs. 6 chip ROMS

How are the TOS ROMs laid out on 2 chip versus 6 chip ROMs? Is it the the exact
same data but with the first 3 chips on 1 ROM and the next three on the second
or something more insidious?

Scott
From: stigj@dhhalden.no (STIG JORGENSEN)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
Date: 9 Jan 93 15:00:56 GMT
Organization: Ostfold College

In article <1993Jan3.035343.15539@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:
>From: ersmith@netcom.com (Eric R. Smith)
>Subject: Malloc (Was: Sending objc_draw to a buffer)
>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
>

I was just wondering if Pure C has this built in in its library. I am 
writing a little program that checks if there are any duplicates on the 
harddisk. Here I use a linked list and make a Malloc() call for every member 
of the list. There hasn't been any proglems yet. Do you know if Pure Chas 
this built in?
From: berrah@montblanc.cica.fr (K.Berrah)
Newsgroups: comp.sys.atari.st.tech
Subject: GCC problems too ...
Keywords: GCC, documentation.zoo
Date: 5 Jan 93 12:55:08 GMT
Organization: Telecom Paris, France

I've downloaded a version of GCC from terminator.cc.umich.edu
one year later, and I've finally decided to install it on my 
STe, it's a 1040 upgraded to 4 Megs. I unfortunaly don't have
the documentation.zoo file (missed ?). I use the Gulam shell,
followed the "README" instructions but still can't compile
a single "printf("Hello world\n");" program. A compile
command gives me a "-1 exit command". 

It seems that the terminator.cc.umich.edu don't have anymore
atari programs. Can anyone give me another atari server address?

Thanks.


P.S :
	Good year !!
 
+---------------------------------------------------------------+
| Berrah Karim                   | E-mail:			| 	
| Eurecom Institute              |      			|
| C.I.C.A, 2229 Route des Cretes |      berrah@eurecom.cica.fr	|
| Sophia Antipolis               |	berrah@disuns2.epfl.ch	|
| 06560 VALBONNE  FRANCE    	 |	berrah@eldi.epfl.ch	|
+---------------------------------------------------------------+
From: michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith)
Newsgroups: comp.sys.atari.st.tech
Subject: TT video memory organisation...
Organization: Fidonet. Gate admin is fido@socs.uts.edu.au
Date: 09 Jan 93 10:52:22 GMT


G'day again - this time I'm after anyone who has info on the layout of the
bitplanes in the TT resolutions : most particularly TT medium.

I'm working on some code that is fairly graphically intensive, and I want to
compare the VDI with my own function-specific code.

I'd like to use the VDI, coz then it would be portable to different screen
sizes, but time will tell...

\`miff`                                                       /|\

--- ScanMail 0.68 X0501
 * Origin: That Which Is Not, ST in SA. 61-8-276-4415 (3:800/842)
Newsgroups: comp.sys.atari.st.tech
From: leo@dcs.warwick.ac.uk (Leo Hendry)
Subject: Re: chdir in sozobon
Organization: Department of Computer Science, Warwick University, England
Date: Mon, 4 Jan 1993 20:51:15 GMT

In article <1993Jan4.015926.26383@oz.plymouth.edu> pyr579@oz.plymouth.edu (Technoid) writes:
>Hello,
>
>	I am having difficulty with chdir() is Sozobon 1.33i ( Heat N
>Serve ). It won't change drives. According to the dlibs text file,
>chdir() will change the drive if a drive letter is given to it. I assume
>this means that if I enter "d:\telecomm" for a string, it will ( with
>the proper end slashes added. ) change the current drive to D: and then
>change the directory to \telecomm. The problem is, it does not do this.
>I'm only trying to implement a simple cd command for a mini TOS shell
>and I've got most of the other commands finished. This one, that should
>be easy, doesn't want to work. Any help would be great or if you have a
>working cd command implemented, I'd love to see your code.

I've never heard of a chdir() function with this behavior (I had to write
another function to do what you describe) and this is not how a normal cd
command behaves anyway.  Perhaps you read the documentation wrong.
  Note that if you write a separate program that changes the directory it will
appear to do nothing because when you run a program the current directory is
first saved and then restored after the program has run (the same with the
rest of the environment).

- Leo
Newsgroups: comp.sys.atari.st.tech
From: hohmuth@freia.sax.de (Michael Hohmuth)
Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
Reply-To: hohmuth@freia.inf.tu-dresden.de
Organization: Dept. of Computer Science, TU Dresden, Germany
Date: Fri, 8 Jan 1993 16:49:51 GMT

In article <wmtwen.726497985@rw8.urc.tue.nl>, wmtwen@rw8.urc.tue.nl (Erlend Nagel) writes:

> Question:
> Did I do wrong?

No, you didn't.

Now for the details:

> [...] 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.

It's OK to use Malloc() here. You do exactly what was proposed earlier in this
discussion: You allocate large chunks of memory from the system and manage
them yourself.

However, malloc() and free() are of course compatible to new OS releases, too, 
because they internally use the OS function Malloc().

> And also it seems to me that using Malloc saves a bit of memory because
> the malloc function does not have to be linked.

malloc()'s code should not consume too much memory (less 1 K).

Michael
-- 
Internet: hohmuth@freia.inf.tu-dresden.de
From: aj743@cleveland.Freenet.Edu (Steven D. Hardy)
Newsgroups: comp.sys.atari.st.tech
Subject: Atari ST system 4 sale...
Date: 10 Jan 1993 05:39:47 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu



I have an Atari 520ST system for sale.  Every thing is in great
condition and has been treated with loving care.  I have recently
moved on to a new system and would like to find a home for my
Atari.  I am asking $400.00 or best offer for everything plus
shipping.  If you have any questions please send E-mail...
 
HARDWARE:
 
Atari 520ST
- 68000 16bit CPU at 8MHz
- 512k RAM
- RF modulator for connecting to your TV
- Atari two button mouse
- TOS operating system with GEM graphical user interface
- Two joysticks
- Connector to add two joysticks for four players
 
Two Atari SF354
- Single sided disk drives
- Uses 3.5" disks
- Will format to 360k
 
Master 3S
- Double sided disk drive
- Will format to 720k
- Teac mechanism
 
Rio Datel Disk Drive
- Double sided disk drive
- Will format to 720k
- Teac mechanism
 
Atari SMM804
- 9 pin printer
- Cable
- Paper
 
 
SOFTWARE:
 
All software is like new and includes manuals...
 
-APPLICATIONS-
 
Flash
Shadow
WordPerfect
 
-GAMES-
 
Advanced Dungeons & Dragons: Heroes of the Lance
Better Dead Than Alien
Alien Syndrome
Barbarian
Batman: The Caped Crusader
Dungeon Master
Chessmaster 2000
Exolon
Falcon: The F-16 Fighter Simulation
Formula 1 Grand Prix
Gauntlet
Gauntlet II
Hitchhiker's Guide to the Galaxy
King's Quest III
Leader Board
Leather Goddesses of Phobos
Leatherneck
Outrun
Hyperdome
Moon Patrol
The Pawn
Phantasie
Phantasie II
Phantasie III
Test Drive
Star Fleet I: The War Begins
Sundog
Thrust
Starglider
Star Wars
Space Quest
Star Trek: The Rebel Universe
Thunder Blade
Time Bandit
Ultima II
Exodus: Ultima III
Ultima IV: Quest of the Avatar
Plutos
Vectorball
Xevious
Uridium
Robotron: 2084
Warhawk
Wizard's Crown
 
 
OTHER:
 
Lots and lots of Atari ST specific magazines...
 



-- 
//////// / TAYLOR 23 / //////////////////////////////////////////////
6820 N.W. 31st                InterNet:   aj743@cleveland.Freenet.Edu
Bethany, Oklahoma           Compu$erve:   70233,3101
73008-4006                       GEnie:   S.HARDY3
Newsgroups: comp.sys.atari.st.tech