HDTenEightyP/NetNews huggingface dataset:
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: .*rc: addition
Organization: PTT Research
Date: Fri, 16 Oct 1992 13:14:32 GMT


There's one thing I forgot to mention in my article about the data/resource
partitioning of files:

Apart from the TABS example a FOLD chunk for use with folding text editors 
could be defined. Another idea is a NOTE chunk with a small clarifying text
about the file (cf. Amiga and Mac).

-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: marc@targon.UUCP (Marc Dierikx)
Newsgroups: comp.sys.atari.st.tech
Subject: DMA i/o
Keywords: dma, mfp
Date: 13 Oct 92 07:17:48 GMT
Organization: Siemens Nixdorf Computer bv., SWZ, Vianen, The Netherlands


Hi netland,

I'm looking for information on how to program in- and output from/to
the st's dma port. I guess it has something to do with programming
the mfp chip. Can anyone help?

Marc

BTW: reply by email please.

+-------------------------------------------------------------+
|Marc Dierikx,                                                |
|marc@targon.UUCP  dierikx.via@sni.de  dierikx.via@sni-usa.com|
+-------------------------------------------------------------+
From: Martin_Koehling@un.maus.de (Martin Koehling)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Detecting the closing of a
Date: 13 Oct 92 23:18:00 GMT
Article-I.D.: UN.A15417
Organization: MausNet
X-Gateway: MausGate/News 1.14

>>How would I go about detecting if an accessory was closed (after it had
>>been opened, of course) while a GEM application was running?  The message
>>pipe never seems to return AC_CLOSE (or AC_OPEN), which, as I'm told, are
>>only received by accessories.  I tried WM_NEWTOP and no go (What the hell
>>is WM_NEWTOP anyway? Never seems to be sent to my APP at all).  Any
>>ideas?
>
>My (not completely blind) guess would be that this is not possible, but I
>could be mistaken (if so, please let someone correct me). According to
>the 'Atari Profibuch' WM_NEWTOP is the same as WM_TOPPED.

Sorry, you're mistaken.
A very old copy of DRIs GEM documentation says:

> WM_TOPPED
>  GEM AES uses this message to tell the application that the user has
>  requested its window or another applcation's window be moved to the
>  top (made active).

(i.e.: the user clicked on one of the application's windows that is NOT
currently on top)

(BTW: I think the "another application's window" part may be obsolete...)

> WM_NEWTOP
>  GEM AES uses this message to tell the application that its window has
>  just been placed on top (made active)

(...possibly by some external event, like another APP/ACC closing one of its
windows...)

As you can see, these are completely different things; and, unfortunately,
no released Atari GEM version I know of (including the GEM in TOS 3.06) ever
sends WM_NEWTOP!
Many APPs simply use a timer event (500 milliseconds or so) to periodically
check if their window is still on top, wich is (IMHO) a somewhat inelegant
solution (and may cause trouble when the program tries to detect double
clicks).

Martin_Koehling @ un.maus.de
Newsgroups: comp.sys.atari.st.tech
From: annius@nanna.research.ptt.nl (Annius Groenink)
Subject: Changing Mouse Forms in MultiTOS
Organization: PTT Research
Date: Wed, 14 Oct 1992 17:14:48 GMT


Does anybody know how MultiTOS works/should work with mouse forms? When
an accessory changes the mouse form and someone elses window is topped by a
keyboard command the mouse form isn't reset to an arrow form. This problem only
occurs with programs that don't implement rectangle events and are hence only
using the arrow and busy bee mouse forms. I think MultiTOS should keep track of
the last mouse form set by each application and take care of that. I don't see
a way for the program that has just been put on the background to change the
mouse back because 1) it doesn't know to what form it should be set and 2)
programs don't get a message when a window of another application is topped.



-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: mjl-b@minster.york.ac.uk
Newsgroups: comp.sys.atari.st.tech
Subject: Re: XBIOS say() in MultiTOS :)
Date: 14 Oct 92 10:45:39 GMT
Organization: Department of Computer Science, University of York, England

In article <2s2VRB1w165w@ersys.edmonton.ab.ca> mforget@ersys.edmonton.ab.ca (Michel Forget) writes:
>Actually, a say() function would be a good idea if the voice would be of better
>quality than is usual.  I remember a program called STSPEECH.TOS that would say
>whatever you typed (and could be made to stay resident and be tweaked by other
>programs to say what THEY want it to say) but the voice it spoke with was
>awful.  It was the voice commonly associated with computers.  Grating.
>
>Is it possible to get better quality phonetics, or at least generate more
>human-sounding sounds?

Yes, it is, but there's a catch (as ever!): You need a _lot_ of processing
power, and ideally a DSP (Falcon, anyone? :-)). A friend is working on high
quality speech synthesis system:

"Real Time Synthesis of High Quality Speech", R Mortimer, MEng 3rd year
Project Report, University of York, UK.


><<        mforget@ersys.edmonton.ab.ca          >>

Regards,

Mat

| Mathew Lodge                      | "A conversation with you, Baldrick,     |
| mjl-b@minster.york.ac.uk          |  and somehow death loses its sting..."  |
| Langwith College, Uni of York, UK |  -- Blackadder II                       |
Xref: sparky comp.sys.atari.st.tech:5209 comp.sys.atari.st:15241
From: ekrimen@wet.UUCP (Ed Krimen)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Subject: Re: Falcon and Hard Drives
Date: 15 Oct 92 16:59:57 GMT
Followup-To: comp.sys.atari.st.tech
Organization: Wetware Diversions, San Francisco

In article <1992Oct14.184929.26547@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes:
>I'm still quite perplexed as to why there is an IDE port at all, it would
>have been more consistent to jus tuse the SCSI bus both internally and
>externally. So it goes.

Could it be cost of the drives?  Are 2.5" IDE drives less expensive for the
consumer than 2.5" SCSI drives (if there are any around)?  Perhaps Atari
wanted to provide an inexpensive hard drive solution for the Falcon and IDE
was it.
-- 
   |||    Ed Krimen
   |||    ekrimen@wet.uucp   Contributing Editor, Atari Explorer Online
  / | \   E.KRIMEN (GEnie)            Vice-President, ABACUS User Group
From: andi@gmd.de (Andreas Rohrschneider)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: What makes the Screen Scroll *UP* ???
Date: 14 Oct 92 13:03:29 GMT
Organization: GMD, Sankt Augustin, Germany


In <1992Oct10.190032.26611@ms.uky.edu> thomasc@ms.uky.edu (Thomas Campbell) writes:

>Ok, between Kevin and Michel I've gotten a good start towards wehre
>I need to go but, I still haven't quite gotten it.  Michel suggested
>that I ues the Line-A function but, he suggested it in Pascal.  I
>should have said before that I'm using C.  I looked thru my libraries
>on Line-A functions and I didn't find *anything* on how to shorten
>the screen which is what I'm trying to do.   Let me try and explain
>waht I'm trying to do a little better.  Whenever there is input on
>line 20 I want it to be on line 20, when input comes in for the next
>line (line 21) I want the screen to scroll up and have the input displayed
>on line 20 again and so on and so on.  I'm using Laser C and as I've
>said I've looked thru all my functions twice over.  Michel I think 
>suggested that I Peek and Poke a location but, I don't think I can do
>that in C... any suggestiosn will be greatly appreciated.

>Alex


Why don't you just try the curses.arc package available at a.a in directory
/pub/atari/Programming ? It includes a C-Program with various functions to
define and manipulate text windows. Also included is a detailled documentation.

I looked at it and actually found a function for scrolling text upwards in a 
specified window. So this might be a solution to your problem. It seems to use
BIOS and XBIOS functions only, so there is a chance it is safe.

Just try it.


Greetings, Andreas



--------------------------------------------------------------------------------
Andreas Rohrschneider
GMD - I5.SKS
German National Research Center for Computer Science
Schloss Birlinghoven             		    phone: (+49 2241) 14-2242
D-5205 Sankt Augustin 1, FRG     		    email: rohrschneider@gmd.de 
--------------------------------------------------------------------------------
From: jvt@its.bt.co.uk (John Trickey)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: sm124 - 4meters - atari
Keywords: long monitor cable
Date: 16 Oct 92 12:00:23 GMT
Organization: BT Group Computing Services, Birmingham, UK

In article <1992Oct15.154212.16077@phys-chemie.uni-wuerzburg.dbp.de> kruel@phys-chemie.uni-wuerzburg.dbp.de (Thomas-Martin Kruel) writes:
>In article <9210111750@jacom.UUCP> jac@jacom.UUCP (Joerg Conradt) writes:
>> [complains about problems with long monitor cables]
>> [attributes it to the weakness of the shifter]
>
>Well, I have a 6m additional cable between my Mega ST2 (with blitter) and
>the monitor. It works quite fine, except that the focus is a bit worse.
>
>I have a cable with 7 wires which are shielded INDIVIDUALLY. This may cause
>the difference: cables with a single shielding only give bad results, i.e.
>the phenomena you have described.

Screening is vital but so is impedance. Your video signal is sent along a
transmission line but, while the distances are short, you may be able to
get away with just about any wire. The longer the distance, the more essential
it is to use the right cable. The wrong cable will slow down the transitions
and so you will lose detail in the image. Not only that, you can get reflections
from the joins which will cause ghosts a short distance from the real image.

The right cable is 75 ohm co-ax, as long as atari have kept to the standard.
There is a type especially made for video (RG159 I think, but don't hold me
to it as I don't have the references here).

John
-- 
John Trickey <jvt@its.bt.co.uk>
       Voice: +44 21 524 8200     Fax: +44 21 553 6120
(Home) <john@its.bt.co.uk> || <john@g4rev.ampr.org> || G4REV @ GB7FLG
       +44 21 308 8892
Newsgroups: comp.sys.atari.st.tech
From: pbh@pandora.cs.wayne.edu (Patrick B. Haggood)
Subject: Anyone know Karsten's (overscan et al) email address?
Organization: Wayne State University, Detroit, MI
Date: Fri, 9 Oct 1992 20:14:33 GMT


I am looking to write him about his audio drivers for MiNT.  Can you 
send me address?  Thanks heaps.

-- 
Kadidjri Lahab
Wayne State University
Physics '94

Newsgroups: comp.sys.atari.st.tech
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: Re: VDI colors: Which ones should one leave alone?
Organization: PTT Research
Date: Thu, 15 Oct 1992 08:51:57 GMT

aeg03@rrz.uni-koeln.de (Jan T. Kim) writes:

>Hi fellow Atarians,

>menu, at least if there are 16 or even more colors. Therefore,  I
>figure  it  would  be a good idea to leave some of the VDI colors
>unchanged, at least colors 0 and 1. Do you think I  should  leave
>more colors unchanged?

I'd say at least 16. That'll give you 0 colours on an ST(E)! That should be
enough :) But really, we should hear a TT owner about this.

>BTW, how does MultiTOS deal with this? Will the palette always be
>switched  to  the  one  set  by  the process that owns the active
>(topmost) window?

That's what I am hoping as well, and there are a lot more things that
should be relative to a process. Let's hope they'll think of these things in
the very first version, and avoid a phenomenon similar to TOS 1.4, which made
all the previous TOSes kind of rediculous. (Call it MultiTOS 1.4 :)

>Thanx in advance,

-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: rgoseweh@digi.lonestar.org (Roy Gosewehr)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Using RBG/Sync monitors with ST
Summary: Monitor Master not for multisyncs
Keywords: Omniswitch, multisync switch, Monitor Master
Date: 15 Oct 92 13:14:12 GMT
Organization: DSC Communications Corp, Plano, TX

In article <1992Oct14.151427.4434@bmerh85.bnr.ca> shiv@bnr.ca (Shiv Naimpally) writes:
>There is a box called Monitor Master by Practical Solutions that
>will allow hook up of a multi-sync monitor to the ST and allows
>changing resolutions. There are people in Netland who may be 
>interested in selling you one. 

Sorry, not true.  Monitor Master only allows you to switch between an
Atari monochrome (SM124, etc.) and an Atari color (SC1224, etc) monitor.
It has no provisions for mulitsync connections.

For mulitsyncs, you need the Omniswitch, the IB Multisync switchbox, or
the switcher made by Omnimon Peripherals ( I can't remember the name),
depending on your connection requirements.

Roy C. Gosewehr
-- 
 ------------------------------------------------------------------------
| GEnie: R.C.Gosewehr | rgoseweh@digi.lonestar.org | uunet!digi!rgoseweh |
 ------------------------------------------------------------------------
From: sheppard_r@kosmos.wcc.govt.nz
Newsgroups: comp.sys.atari.st.tech
Subject: Re: HD-trouble, DMA-IC?
Date: 15 Oct 1992 07:38:38 GMT
Organization: Wellington City Council (Public Access), Wgtn, Nz
Reply-To: sheppard_r@kosmos.wcc.govt.nz
NNTP-Posting-Host: kosmos.wcc.govt.nz

In article <1992Oct14.154058.13819@eua.ericsson.se>, eualty@eua.ericsson.se (Torgny Lindberg) writes:
>
>Well what do I need HELP from the net with? I remember a diskussion a
>while ago on the net about faulty DMA-ICs. I think the symptom of these
>faulty ICs where as described above. Can someone please tell me if this
>is correct?
>
>My next question is what IC on the PCB is the DMA. I have figured out
>that it must be one of the Atari-specific ICs, but which one?
>
>The program that came with the MEGAFILE 30 was AHDI 3.0. 
>
>Torgny Lindberg
>Torgny.Lindberg@eua.ericsson.se


For one thing Please get a copy of AHDI 3.1, your version is very badly stuffed
ans should be never used...

If your STE has this IC C025913-38, then you have the bad DMA chip, 40 pin
chip under the disk drive..

The good IC is C398739-001A, also the AHDI 3.0 can cause the same kind of
problems..

The New replacment IC C398739-001A is free, but there could be a charge
in fitting it ..



Roger................              sheppard_r@kosmos.wcc.govt.nz

Newsgroups: comp.sys.atari.st.tech
From: boyd@shmop.cs.fsu.edu (Mickey Boyd)
Subject: Re: Upgrading Megafile 20
Reply-To: boyd@nu.cs.fsu.edu
Organization: Florida State University Computer Science Department
Date: Wed, 7 Oct 92 05:08:36 GMT

In article <1992Oct2.131032.17843@ryn.mro4.dec.com>, rost@rgb.dec.com (My name is Brian Rost) writes:
>
>Is it possible to expand a Megafile 20 by simply replacing the 20Mb mechanism
>with a larger one and reformatting?
>

In theory, yes.  However, I would personally recommend getting an ICD host 
adaptor (to replace Atari's), and a standard SCSI mechanism.  They should 
fit in the case, and I am sure you will be much happier with the speed and 
nice software.  Host adaptor should cost about $80, SCSI's are pretty cheap.

-- 
  ****************************************************************************
  *                              Mickey Boyd                                 *
  *                         Systems Administrator                            *
  *          Florida State University Computer Science Department            *
  * email:  boyd@cs.fsu.edu  Office:  (904) 644-7339  Pager:  (904) 657-6425 *
  ****************************************************************************
Newsgroups: comp.sys.atari.st.tech
From: boyd@shmop.cs.fsu.edu (Mickey Boyd)
Subject: Re: floppy media change problem
Reply-To: boyd@nu.cs.fsu.edu
Organization: Florida State University Computer Science Department
Date: Wed, 7 Oct 92 05:05:48 GMT

In article <1992Oct1.144351.25@bra.isnet.inmos.co.uk>, svrobins@bra.isnet.inmos.co.uk writes:
>I have a TEAC 3.5" 720K floppy drive hooked up to my Mega 2 as drive B, 
>and have a problem with the ST not detecting when I've changed the disk 
>in the drive. I don't have the model number here, but I can get it if
>its important.

Strange, the TEAC's are supposed to work with no problems.  I put an arc 
file containing a bunch of floppy related hardware how-to's on atari.archive
a couple of years ago.  It was probably called ibmfloppy.arc, or something 
like that.  Also, there is a software solution in fmc.arc (or lzh, stands 
for Force Media Change).  Good luck.

-- 
  ****************************************************************************
  *                              Mickey Boyd                                 *
  *                         Systems Administrator                            *
  *          Florida State University Computer Science Department            *
  * email:  boyd@cs.fsu.edu  Office:  (904) 644-7339  Pager:  (904) 657-6425 *
  ****************************************************************************
From: abaddon@uk.ac.liverpool.scm.suprenum (Kevin o donovan)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Line-A variables and a status Line
Date: 15 Oct 92 11:33:55 GMT
Organization: Centre for Mathematical Software Research, Univ. Liverpool, UK

>>>>> On 14 Oct 92 01:15:10 GMT, thomasc@ms.uky.edu (Thomas Campbell) said:

> Ok, I've seen a dozen or so people say don't use Line-A vars don't use
> Line-A vars blah blah blah.  Ok fine! I won't use them but, how about
> a suggestion on what to do *instead*.  I know that it can be done...
> most of us use Uniterm right?  That's all I want.  When information is
> coming in over the modem I want it to scroll up at line 20 instead of line
> 23. 

OK, how about the following bit of code (not guaranteed to work, since its off 
the top of my head, but it should give you the basics). ScreenLines is a 
variable containing the number of lines on screen, input_line is the line 
you've just got from the modem. I've split the printf()s into multiple calls
to make commenting easier - do them all as one really:

This is for a two line (Emacs-like) status line.
---------
		/* save cursor position (if necessary) */
printf("\033j");
		/* Position cursor at bottom of screen */
printf("\033Y%c ",ScreenLines-1+32);
		/* Scroll the screen up */
printf("\n");
		/* Position cursor at start of status line */
printf("\033Y%c ",ScreenLines-3+32);
		/* Insert a blank line (is this the right code??) */
printf("\033L");
		/* Print your input line -  make sure it doesn't have a
		   newline character in it beforehand */
printf("%s",input_line);
		/* restore cursor position (again, if necessary) */
printf("\033k");

---------
Wrap all this up in a nice little routine, and bob's your uncle. In fact, make
it a #define, since it simplifies to a single line of code.

Is that any help?

Kev
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.atari.st.tech
Date: Fri,  9 Oct 1992 02:41:30 -0400 
From: Stefan Monnier <osoelgaultier+@CMU.EDU>
Subject: Re: Are 100ns DRAMs too slow for an 1040ST ?

Excerpts from netnews.comp.sys.atari.st.tech: 7-Oct-92 Re: Are 100ns
DRAMs too slo.. Brian Grier@bnr.ca (626)

> I've heard of this problem before. If memory serves me the problem
> is with your MMU chip and/or the 5vdc power supply. Some early MMUs
> can not drive 32 chips. Also if your 5vdc is below 4.7 volts some
> memories seem to balk.

> My 520ST is upgraded to 2.5meg with a Z-ram board using 100ns chips.
> The only time I had a problem was when I also tried to use a Spectre
> GCR. The system sometimes wouldn't even come up. I replaced the
> power supply and everything works great now.

> I would call BEST Electronics and ask them. They sell MMUs and better
> power supplies. I do not have their phone number here. I'll check at
> home.

> Brian


The access time shouldn't be a problem:
I have one original 512K 150ns bank and one 2M 70ns bank

When I installed my 2M bank (with off-the-shelf parts like SIMMS
and simm-sockets), I've had similar problems although the MMU
wasn't the problem.

In fact, the problem was power supply, and particularly cables.
Don't try do save money limiting cable size (diameter) and number
for power. It's much safer to have 2 GND and 2 Vcc cables !!

Since I added that second pair of power cables, I haven't had any more 
problems !

	Stefan

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------





Newsgroups: comp.sys.atari.st.tech
From: nino@vmars.tuwien.ac.at (Marinos Yannikos)
Subject: Re: Line-A variables and a status Line
Organization: TU Wien, Vienna, Austria
Date: Wed, 14 Oct 1992 10:57:01 GMT

thomasc@ms.uky.edu (Thomas Campbell) writes:
: In article <1992Oct12.185911.21702@debug.cuc.ab.ca> Cford@debug.cuc.ab.ca (Conan Ford) writes:
: >Someone here was talking about the Line-A variables.  First of all, I'd
: >not suggest using the Line-A variables; if you do your programs will not
: >run on a 68020 or better.
: 
: Ok, I've seen a dozen or so people say don't use Line-A vars don't use
: Line-A vars blah blah blah.  Ok fine! I won't use them but, how about
: a suggestion on what to do *instead*.  I know that it can be done...
: most of us use Uniterm right?  That's all I want.  When information is
: coming in over the modem I want it to scroll up at line 20 instead of line
: 23.  I'm really not asking for *that* much am I?  I know it's easy to 
: do on the 8bit machine it's a snap!  Are we going to roll over and
: say that our 8 bit is better than our 16 bit?????????????????? 
: 
: Alex

Well... you can always write your own VT52 emulator, and I suppose that's what
they did in Uniterm - after all they probably had to write VT100 emulations
etc. anyway! (I don't know, I don't use it)
I'd suggest that you use windows instead, using the info line as a status line.

M.Yannikos
From: hrs@aber.ac.uk (Herbert Martin Sauro)
Newsgroups: comp.sys.atari.st.tech
Subject: XHDI (5.0)
Date: 12 Oct 92 18:14:49 GMT
Organization: University of Wales, Aberystwyth

I was under the impression that the 'new' atari disk software 5.00 supported
the XHDI protocol and I also thought that it deposited a cookie called
'XHDI'. Trouble is when I boot with version 5.0 no cookie is installed
and I can't get hold of the routines pointed to by the supposed cookie.
Am I doing something very worng, perhaps wrong program?

Herb
-- 
/******************************************************************************
Herbert Sauro                                   e-mail: hrs@aber.ac.uk
Biological Sciences                              phone: +44 970 622353
Univesity College of Wales