HDTenEightyP/NetNews huggingface dataset:
From: UweKloss@lionbbs.escape.de ( Uwe Kloss )
Newsgroups: comp.sys.atari.st.tech
Organization: The Lion Town BBS, Brunswik, Germany
Subject: Re: MiNT, which way forward...
Reply-To: UweKloss@lionbbs.escape.de
X-Software: HERMES GUS 1.10 Rev. Dec  7 1992
Date: Mon, 14 Dec 1992 00:33:24 MET
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <1992Dec11.185521.26575@bas-a.bcc.ac.uk>, Mr Stephen R Usher writes:

>Networking using INET protocols takes up space which small machines would
>have problems coping with, however, especially if they were on non-68030
>machines with less than 4 megs of RAM. In which case, should there be two
>MiNTs, the normal one and VMMiNT with all the networking and VM stuff in
>there? Or should there be three or four?

Here you should take a look at some more Systems than only unix
and tos.

E.g. OS-9 with its loadable drivers, managers and descriptors.
Loadable WHILE RUNNING the system!
No Kernellinking and rebooting!

IMHO unix is NOT up to date technology in all aspects!

Uwe
-- 
Eliminiere das Unmoegliche. Was immer uebrig bleibt, so
unwahrscheinlich es auch wirkt, muss die Wahrheit sein.
Aber was ist, wenn einmal NICHTS mehr uebrig bleibt?
   (nach: John Brunner - Mehr Dinge zwischen Himmel und Erde)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Uwe Kloss                   UUCP: UweKloss@lionbbs.escape.de
Fasanenstrasse 65           BTX:  0531336908 0001
3300 Braunschweig           FIDO: not connected
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon Video
Date: 11 Dec 92 18:27:00 GMT
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

D>>(Oh, and they also can't do overscan, which IMHO is a big plus for
D>>genlocking or just grabbing some extra pixels).  Now, I believe that
D>
D>This is also not true.

This IS true. On VGA monitors, the beam(s) do not scan the full tube area. On
video monitors or TVs, the beam scans over the entire tube (and a little
over the margins).
Xref: sparky comp.sys.atari.st.tech:6272 comp.sys.atari.st:18411
From: mauritz_c@spcvxb.spc.edu
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Subject: Re: Falcon and Unix Sys V
Date: 15 Dec 92 15:28:01 GMT
Organization: SPC Community Access System

In article <1992Dec14.233528.2386@midway.uchicago.edu>, coonstot@kimbark.uchicago.edu (charles orville onstott) writes:
> Does anyone know if the ST Falcon will be capable of running
> the Unix Sys 5(AT&T or SCO, etc.)?  If not, will it be
> sys V compatible or at least compatible with most Unixs(unlike
> Minix or some scaled-up version of it).
> 
> In particular, I am curious to know if it will conform to 
> Sys V standards, support TCP/IP, NFS, and X-Windows.  (Or should I
> just buy a NeXT? :)  )

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
Newsgroups: comp.sys.atari.st.tech
From: nino@vmars.tuwien.ac.at (Marinos Yannikos)
Subject: Re: MiNT, which way forward...
Organization: TU Wien, Vienna, Austria
Date: Tue, 15 Dec 1992 10:45:47 GMT

I wrote:
: Speaking of MiNT, has anyone tried to write a Unix-like IPC
: library, eg. for arbitrarily sized messages, shared memory
: functions etc.? Having considered this for a while, I couldn't
: come up with a way to 'wait for messages with IDs from 0 to XX'
: except with busy waiting... Will MiNT ever support this, or 
: has anyone else thought about it?
:
Never mind, I just came up with a way... Only a few seconds after
posting this! Next time I'll think a bit longer before I post...
(a few seconds) Sorry for the waste of bandwidth!

-MY
From: Bob_BobR_Retelle@cup.portal.com
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon questions
Date: Tue, 15 Dec 92 16:31:23 PST
Organization: The Portal System (TM)
  <TKLD.92Dec14153627@burns.cogsci.ed.ac.uk>
  <1992Dec15.143728.20568@Informatik.TU-Muenchen.DE>

Ewald Seibert writes:

>|> Does the Falcon's SCSI-2 support `fast SCSI-2' ?

>no it's only a SCSI-2 plug but a SCSI-1 bus (like the NeXT)

Hold the phone...

This is the first I've heard this about the Falcon's SCSI..

What's this all about..?

BobR
Xref: sparky comp.sys.atari.st.tech:6357 comp.sys.atari.st:18685
From: alien@clinet.fi (Risto Juvonen)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Subject: Re: Falcon and Unix Sys V
Date: 20 Dec 1992 11:28:48 +0200
Organization: Clinet, Espoo, Finland.
NNTP-Posting-Host: clinet.fi

neil@cs.hw.ac.uk (Neil Forsyth) writes:
: 
: I am hearing rumours that some people are porting Linux, a free Unix popular
: on the PC, to the ST and Amiga platforms. I doubt it would be up to much on
: a 68000 but on a 68030 in a TT or a Falcon it could be quite neat. I have
: seen it running X on a 486 PC just fine.
: 
 That sounds very good! I was just thinking of gettin 386 for unix,
and you how much I hate PC's. Now I can get another TT to run unix!
Yes! 

       _/_/_/_/    _/        _/   _/_/_/_/     _/      _/
      _/    _/    _/        _/   _/           _/_/    _/
     _/_/_/_/    _/        _/   _/_/_/       _/  _/  _/
    _/    _/    _/        _/   _/           _/    _/_/
   _/    _/    _/_/_/_/  _/   _/_/_/_/     _/      _/
                               VISUAL ART PRODUCTION

Risto Juvonen               Internet: alien@clinet.fi
Merisotilaantori 3 c 26     Fidonet:  @SMACK! (2:220/110.0)
00160 Helsinki, Finland     tel.358-(9)0-654804
------------------- Generation X --------------------------




Newsgroups: comp.sys.atari.st.tech
From: dbshapco@napier.uwaterloo.ca (Brad Shapcott)
Subject: Mac RAM
Organization: University of Waterloo
Date: Wed, 16 Dec 1992 21:22:28 GMT


Quick question.

Anyone know how to homebrew Mac RAM for the Mac II to upgrade an Atari 1040ST?
These are the 256K RAM, and I have four of them pulled out of a Mac II that
was upgraded to the 1 Meg RAMs.


Thanks,

Brad
From: s19184@seb.se (Michael Evans)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Parallel port problems with 1040ST hooked up to HP Deskjet
Date: 20 Dec 92 23:03:45 GMT
Organization: S-E-Banken, Sweden
Nntp-Posting-User: s19184


In article <12428@obelix.icce.rug.nl>, erikjan@icce.rug.nl
                                                  (Erik-Jan Vens) writes:
>   a friend of mine suffers from problems with his 1040STf. This is one of the
> first series and still runs under TOS 1.0. He wants to hook up a HP Deskjet.
> But the output doesn't get through to it. If he hooks up a Star NL-10 (the
> trad. Epson FX lookalike) (and loads the correct driver) everything works just
> fine.

This sounds like the parallel port overload problem, described in ST 
Applications no 2 under the heading "ST Parallel Port Buffer".

The basic problem is that the parallel port output lines are 
unbuffered, and driven directly from the sound chip. Different 
printers draw different loads, with non-Atari lasers and inkjets being 
worse than dot matrix printers.

The solution illustrated in the article is to buffer all outgoing 
lines, using the printer's NOT ERROR line as a power supply. I have 
bought the pieces but never put the buffer together, becuase the laser 
printer landed on a borrowed PC instead of on the ST. (Word Perfect 
does a very good job of font management!)

/Mike
-- 
Michael Evans    Skandinaviska Enskilda Banken (S-E-Banken)
SEB Data R                   Telephone: +46-8-639 33 70
S-106 40  Stockholm                Fax: +46-8-639 37 62
Sweden                        Internet: mike@seb.se
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Supexec
Date: 16 Dec 1992 03:18:05 +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 <A53866@MS.maus.de> Julian_Reschke@ms.maus.de (Julian Reschke) writes:

[...]

>Yes, but it's unused in TOS (ask Johannes_Hill@ms.maus.de (author
>of TempleMon) for details).

Huh? My information may not be up to date, but my TempleMon (a PD
version  once  distributed along with GFA basic 2.x) says it's by
Thomas Tempelmann.

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: bpat@cs.mcgill.ca (Patrick BETREMIEUX)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sending objc_draw to a memory buffer rather than screen
Date: 21 Dec 92 03:36:00 GMT
Organization: SOCS - McGill University, Montreal, Canada

In article <1gpi5cINN1487@rs1.rrz.Uni-Koeln.DE> kim@vax.mpiz-koeln.mpg.dbp.de writes:
>In <1gohmmINN18lg@rs1.rrz.Uni-Koeln.DE> aeg03@rrz.uni-koeln.de (Jan T. Kim) writes:
>
>>I think they can come from (and go to) any rectangular bitmap you
>>choose.  The  bitmaps  must  be  specified  by descriptors called
>>MFDB's. Pointers to the MFDB of the source bitmap and to the MFDB
>>of  the  target  bitmap  are  passed to the vro_cpyfm() function.
>>Among other things, the MFDB contains a  pointer  to  the  actual
>>bitmap, and if this pointer happens to be a NULL pointer, the VDI
>>will use an MFDB of  its  own  that  describes  the  screen,  and
>>therefore blit from/to the screen.
>>The answer to your question is, therefore, the blits come from/go
>>to  any  bitmap  that  you  specify. If you specify the screen by
>>passing a NULL pointer, the blits will come from/go to where  the
>>VDI  thinks  the screen is.
>
>I'd like to correct myself before  others  do...  as  it  can  be
>concluded  from  the first paragraph, the screen is not specified
>by passing a NULL pointer to the  vro_cpyfm()  function,  but  by
>passing a pointer to an MFDB which contains a NULL pointer at the
>location where a pointer to a bitmap is expected.
>
>Just to be exactly precise.
>
>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  >=-----*

If 0 is specified as pointer to the bitmap, then VDI will check the logbase
pointer, and use this as address. So you can change the screen's logical
address and use VDI and AES without any problems (ie, they will both draw
to the place you specified).

					Patrick.
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: MultiTOS
Date: 9 Dec 92 19:11:00 GMT
Article-I.D.: K.A44241
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

d>  What the hell is so new about it?  It's just integrated with TOS?  I can
d>use
d>MiNT for my MEGA now.  So what is the difference?

MultiTOS includes a rewritten AES. It can run multiple GEM programs in
multitasking.
From: rincewind@discworld.oche.de (Rincewind                      alias Michael Schwingen)
Newsgroups: comp.sys.atari.st.tech
Organization: This is the Discworld, which travels through the space on the
	back of four elephants which themselves stand on the shell of Great
	A' Tuin, the sky turtle.
Subject: Re: The internals of the MEGA ST2...
Reply-To: rincewind@discworld.oche.sub.org
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Sun, 13 Dec 1992 20:45:20 MEST

In <HFmHVB1w165w@midiline.la.ca.us>, Luposian Knightwolf writes:
>Can someone look inside their MEGA ST (TOS 1.2), assuming they have one, 
>and list each chip number, the "term" for it (PAL, ACIA, etc.), if any, 
>and the function of that chip?  In other words, I want to know what my ST 
>does on a parts by parts basis.  There are probably a lot of similarities 

You will get problems as far as the central parts, the custom 
chips, are concerned, because these can not be looked at in single 
parts, they only work together. For example, the DMA base/counter 
registers are located somewhere in the MMU, because the DMA does not 
have the necessary address lines, and the same is true for some 
other parts of the DMA/Video/RAM subsystem.

cu
Michael

-- 
Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany   voice: 0241-876165
Univ.: michaels@pool.informatik.rwth-aachen.de    <--- use this for long mails!
Home:  rincewind@discworld.oche.de                 Maus:  Michael Schwingen@AC3
IRC: Rincewind
"Not matter how fast light travels, it finds the darkness has always 
got there first, and is waiting for it." Terry Pratchett, Reaper man
From: dlk0ms9s@umiami.ir.miami.edu
Newsgroups: comp.sys.atari.st.tech
Subject: Flacon IDE Question
Date: 20 Dec 92 17:12:25 EST
Organization: Univ of Miami IR



  Question:

   Lets say someone buys a Falcon030 with one meg and no harddrive.  Will the 
IDE controller still be inside the machine?  I mean is it an extra card
or is the interface built into the motherboard?

Mark Santora
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Newsgroups: comp.sys.atari.st.tech
Subject: Lazy AES (wase: Sending objc_draw to a memory buffer)
Date: 16 Dec 1992 11:41:25 +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 <memo.812189@cix.compulink.co.uk> apelled@cix.compulink.co.uk (Adam Pelled) writes:

>    Incidentally. Has anyone else noticed that when a window is moved back
>into full view that the redaw is for all the work area. A bit lazy of the
>AES methinks.

Yes, I noted that, and it bothers me quite a lot.  I'm  not  that
brilliant  a  programmer  that I can redraw rectangles in a split
second (which could have to do with the stuff I'm  drawing,   too
--  should  I start bitching about having no clean way of drawing
VDI output to a virtual screen from which  I  then  could  blit),
therefore  it  sometimes  can really drive me crazy. The solution
I've done for myself is making redraw routines  interruptible  by
pressing <Esc>, which is, of course, a kludge...
But what's even more foolish about the AES, if there's a  window,
and  only a fraction of a slider is overlapped by another window,
and now the first window is topped, the AES will send the  redraw
event  for the full workspace of that window, although no part of
it needs to be redrawn. I'd really appreciate if  this  could  be
optimized.

>    Also the rectangle list is not exactly optimum. i realise it must be
>recursive and that there must be some kind of inheritance, but it seems a
>shame that it couldn't be merged by the OS and save the overhead for all the
>apps having to redraw too many rectangles. With losts of windows this gets to
>be quite drastic. Try an experiment and draw a box outline in a  multi window
>environment you'll see what i mean.

Do you mean by this that the  AES  should  automatically  restore
window  parts  that  become  uncovered again? It seems to me that
there is  a  justification  for  having  the  programm  redrawing
windows   rather   than  the  AES,  because  the  algorithms  and
information for redrawing the windows must be buried somewhere in
the  program anyway, while the best the AES could do is to create
a bitmap somewhere containing the whole contents  of  the  window
and  blitting  the  visible  parts  from there to the appropriate
rectangles of the window. If VDI output redirection was possible,
one  could  redirect  stuff  to  there  and  write  a library for
displaying such a virtual screen in a window once,  which  would,
from  then  on,  be  just  as  good as if the AES maintained that
screen and took care of the redrawing.

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  >=-----*
Newsgroups: comp.sys.atari.st.tech
From: apelled@cix.compulink.co.uk (Adam Pelled)
Subject: XBRA and Memory Protection.
Reply-To: apelled@cix.compulink.co.uk
Date: Wed, 16 Dec 1992 23:17:00 +0000


    Someone posed what i thought was a good question the other day..

    Reproduced without permission:

>From: Roine Stenberg
>To  : Adam Pelled
>Subj: Re: Xbra on MultiTOS ?
>---------[N_STPROG       ]-----------------------------------------------
>If i want to follow a XBRA structure, i MUST peek inside EVERY program in 
>the XBRA list.
>With MultiTOS/68030 programs will have memory protection, and if my program 
>tries to look into some other programs occupied memory, the MMU of the 
>68030 will generate a BUS ERROR to my program.
>
>The question is - Am i right or wrong about this ??
>-!-
> ! Origin: STacken BBS, Mj|lby, Sweden. +(46)142-19331. (90:1100/110)
>--------------------------------------------------------------------------

    i have been informed that this has to be done in supervisor mode.
What do the panel think ?

    Adam.
From: andrew@minster.york.ac.uk
Newsgroups: comp.sys.atari.st.tech
Subject: Re: ICD Host Adapter
Date: 15 Dec 92 10:24:19 GMT
Organization: Department of Computer Science, University of York, England

Okay, I've had a lot of replies to my plea and it turns out I need the new
ICD software.  (Version 6.) I don't have Modem access to anything so can
someone mail me the address of an anon. ftp site where it exists, and also
the file it is stored in.

Also if anyone has or knows of where I can get more information about SCSI
and the way in which the ICD converts from it to ASCI I'd be grateful.  I
also don't know anything about ASCI.  For instance, how would I send a
command to the DMA port which could eventually tell me the way in which my
SCSI drive is set up?  How does the format program work, in general?

-Andrew
Organization: Penn State University
Date: Thu, 17 Dec 1992 19:02:35 EST
From: <SML108@psuvm.psu.edu>
Newsgroups: comp.sys.atari.st.tech
Subject: Unix and the Falcon and the TT etc...

I personal would buy a Falcon if I knew I could run my X software on it that
I use and develop at work.  I have absolutely no confidence that Atari will
ever develop a unix port, and I see no reason why I should wait for that.
However, if a group of programmers can put together a TCP and X supporting
software package for the PC, how hard can it be to do on the ST?  Certainly,
I could not do this on my own as I don't know nearly enough unix guts
to do this, but sheesh, how about a team effort?  I'll help in whatever
way I can...  If I buy a Falcon, I know what I am getting into, but I'll
be damned if I'm buying a PC or a mac...  I could easily be swayed to a
different platform if one ever comes out, but I'm not holding my
breath for it.  That's not the point here though.  If we do an unix port
ala Linux, then there are no licensing fees to worry about.  I'm mostly
ignorant here, but I would think at least some of the Linux source could
be used to reduce the magnitude of the task...

To the experts out there: just what WOULD it take to write Unix for the ST?
Seriously...

Scott

"What would be your reaction if we sued you for copyright infringement
 for HacMan II" - The Katzenjammer Kids
From: rincewind@discworld.oche.de (Rincewind                      alias Michael Schwingen)
Newsgroups: comp.sys.atari.st.tech
Organization: This is the Discworld, which travels through the space on the
	back of four elephants which themselves stand on the shell of Great
	A' Tuin, the sky turtle.
Subject: Re: AdSCSI Micro Hostadaper trouble
Reply-To: rincewind@discworld.oche.sub.org
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Mon, 14 Dec 1992 13:36:00 MEST

In <1992Dec09.144525.20771@bnr.ca>, Brian Grier writes:
>Well is it EVEN or ODD parity that is enabled? It does make a difference.
>BTW what is suitable? Quantum, Maxtor, Seagate, Conner, and Micropolis
>drives are still all selectable for EVEN, ODD, or NO parity.

That's new to me - I think the SCSI standard specifies which parity 
to use. *All* harddisks which I have seen until now had only 1 
'parity enable' or 'parity disable' jumper, no way to select 'which 
parity'. I own a Conner CP3100 and a Quantum LPS240, and in my 
technical docs for Quantum Prodrive LPS[52|105|120|240]S and Prodrive 
[120|170|210|425]S there is *no* parity type jumper, only on or off. 
I haven't seen one on Seagate drives until now, either, and there 
is no hint that there might be one in my Seagate SCSI drive docs. 
Can You give any drive Manufacturer and type that definitely *has* 
such a jumper ?

>whatever you want. Besides the SCSI spec says that parity mst be selectable.
I don't have the SCSI docs here right now, but this should be true. 
The only reason for not implementing parity in a host adapter is 
price and (most important) board space. The ICD Micro was designed 
to be exactly the size as a 3.5" drive when mounted vertical on 
back of one. Parity generation would have needed at least 1 extra 
IC, and there is no space for that.

>> The other question is about the fact that I have been told that a high 
>> percentage of Micro adapters are faulty out of the box. 
>
>I own three host adapters and the only on I've replaced was the 1987 one 
>that does not have the correct interface drivers for the STe and TT. 
>They all worked right out of the box first time. Now the Micro host
>adapters are only used in MegaSTs, and are not useable on the keyboard
>case ST or any STe or TT, so you may be right.
They are used in large quantities here in Germany, especially in 
MSTEs and Megas, but they can be connected to a 1040ST (I did). I 
have not heard of any problems until now.

cu
Michael

-- 
Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany   voice: 0241-876165
Univ.: michaels@pool.informatik.rwth-aachen.de    <--- use this for long mails!
Home:  rincewind@discworld.oche.de                 Maus:  Michael Schwingen@AC3
IRC: Rincewind
"Not matter how fast light travels, it finds the darkness has always 
got there first, and is waiting for it." Terry Pratchett, Reaper man
From: whitcomb@aurs01.UUCP (Jonathan Whitcomb)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Tec and AdSpeed Problem
Date: 15 Dec 92 21:57:31 GMT
Reply-To: whitcomb@aurxc3.aur.alcatel.com.UUCP (Jonathan Whitcomb)
Organization: Alcatel Network Systems, Raleigh NC

In article <A44242@K.maus.de> Peter_Missel@k.maus.de (Peter Missel) writes:
>  Does anyone have any idea why the TEC board and AdSpeed 16Mhz accelerator
>will not work on a MEGA in ANYFORM?

>I've had the problem several times, as my daily job is at an Atari dealer. We
>tried this combination a few times with different TOS expansion cards and
>several ICD AdSpeed boards. We got one or two machines to run, others wouldn't
>even boot properly with _any_ combination of TECs and AdSpeeds.

This is probably stating the obvious (like in the trouble-shooting
section of a new television manual that tells you to make sure the TV is
plugged in if you don't get a picture), but...

There is a jumper wire that must be soldered between the CPU and the
expansion slot connector when you install AdSpeed ST in a Mega ST.
Since the Mega version of the TEC uses the expansion connector, this
might be a good place to look.  Are you sure that the Mega has this
jumper properly installed?



**********************************************************************
Jonathan Whitcomb                    UUCP:  whitcomb%aurgate@mcnc.org
Alcatel Network Systems              
Raleigh, North Carolina              GEnie: J.WHITCOMB3