HDTenEightyP/NetNews huggingface dataset:
From: dud@hardy.u.washington.edu (Daniel Aylward)
Newsgroups: comp.sys.atari.st
Subject: Re: TT 1.44 meg floppy help
Date: 14 Dec 92 04:44:50 GMT
Organization: University of Washington

v077l5lx@ubvmsd.cc.buffalo.edu (Guy N Di Piertro) writes:

>Hello!  I have installed TOS 3.06 and the new Atari controller
>for the 1.44 meg floppy in my TT.  I have also flipped the 
>switch to enable the high density format button.  The drive reads
>properly, and even writes acceptably, but for some reason it 
>won't format in high density well.  It worked a few times but
>doesn't anymore.  Any suggestions would be appreciated.
>	I think this discussion came up before but I don't remember
>what the verdict was.  Is the problem in the drive or the 
>controller or TOS?  Thanks!
>						- Guy :-)

I'm not sure what's wrong, but this was my experience...

I bought the 1.44 floppy/AJAX chip/TOS 3.06 package.  I put in the floppy
(with the cord turned upside down), I put in the TOS, and after looking
around for several minutes found the floppy controller chip & replaced it
with the AJAX chip.  I then turned on the computer, which did nothing.  I
turned it on and off several times, and it did nothing.  So I took it back
apart, looked closely at my TOS chips, and found I had put them all in
backwards.  Happy happy, joy joy.  I also noticed that the AJAX chip was
in backwards.  I turned them all around, put it back together, and turned
it on.  Still nothing.  So I'd fried my ROMs.  Well, I took it apart, took
out the TOS 3.06 chips, put the 3.05 chips back in, turned it on and to my
IMMENSE relief it worked.  :/  So, after working up courage, I tried
formatting a disk 1.44 meg, and it seemed to work fine.  I used it for a
few weeks, and then I noticed that it wasn't recognizing the floppy. 
There was no drive A icon on the desktop.  I usually don't use a floppy
anyway... but it would be nice to have a working one on occasion!  Tried
everything, no dice.  Finally, I put the old controller back in, and sure
enough, it worked fine.  So now I have 5 fried chips.  But my drive
formats/reads/writes 1.44 floppies flawlessly on all the old stuff...  If
you still have the old controller, you might want to try putting it in &
see if it works then.  That'll at least tell you if the controller is bad.
If that doesn't help, maybe try putting the old TOS in as well?  If it's
not either of those two things, it may be the drive itself... if you can,
find a friend with a clone with a 1.44 meg floppy on it, plug it in, and
see if it works.  You could also try it with 720K floppies & see if
there's any problem there.  If none of these turn up anything, I don't
know what to say...  :)

Good luck!

(BTW, I'm waiting for TOS 4.0 before I upgrade again.  Hopefully it won't
be long...  Eventually I'll need another AJAX I think.)

Dan Aylward
dud@u.washington.edu
From: abaddon@uk.ac.liverpool.scm.suprenum (Kevin o donovan)
Newsgroups: comp.sys.atari.st
Subject: Re: Piracy of software
Date: 16 Dec 92 11:32:11 GMT
Organization: Centre for Mathematical Software Research, Univ. Liverpool, UK

>>>>> On 9 Dec 92 20:44:42 GMT, aeg03@rrz.uni-koeln.de (Jan T. Kim) said:
> NNTP-Posting-Host: rs1.rrz.uni-koeln.de

> In <1992Dec9.131359.23979@crc.ac.uk> naffara@crc.ac.uk (Dr. N.A. Affara) writes:
> I don't subscribe to this point of  view  at  all.  This  way  of
> looking at things overlooks the central fact that software piracy
> is tightly coupled to software overpricing, and  that  these  two
> form  a  dynamical system (commonly known as a vicious circle  or
> a  catch-22)  in which amplification of one part tends to amplify
> the other part.
Absolute rubbish. Just because you decide something is too expensive
you have the right to steal it? Good one. There's this really nice
video recorder in a shop by mine, but its 600 pounds and I couldn't 
afford to pay that much. Perhaps I should steal a car and drive through
their window and just take it? If they were selling it for 100 pounds
then I wouldn't need to do this, so its their own fault. Then again, it seems
silly to pay 100 pounds when I can get it for nothing...

> The sensible thing to do in order to get out of a vicious  circle
> is  to  get  all  who  are involved to cooperate to develop a new
> concept that is free from the forces on which the vicious  circle
> feeds.  Thus, what everyone can do and should do is to be open to
> such new concepts, to support them, and to contribute ideas.

Yeah, as long as its not too expensive, coz then we'll just have to carry
on ripping them off, won't we?

Kev
Newsgroups: comp.sys.atari.st
From: barothwe@floyd.cca.cr.rockwell.com
Subject: Tax DEDUCTIONS for 1992
Date: Mon, 14 Dec 92 11:52:19 -0600
X-Received: by usenet.pa.dec.com; id AA27268; Mon, 14 Dec 92 09:52:50 -0800
X-Received: by inet-gw-2.pa.dec.com; id AA28238; Mon, 14 Dec 92 09:52:41 -0800
X-Received: by floyd.cca.cr.rockwell.com (5.57/Ultrix3.0-C)
	id AA23602; Mon, 14 Dec 92 11:52:20 -0600
X-To: comp.sys.atari.st.usenet
X-Mts: smtp


		------======<<<<<<(((((     )))))>>>>>>======------

		  You can get TAX DEDUCTIONS on hardware/software
		        if you donate by the end of 1992

		------======<<<<<<(((((     )))))>>>>>>======------

		 Got hardware and software you don't use anymore?

		------======<<<<<<(((((     )))))>>>>>>======------

		Got enough money that you can afford to be generous
		    with that which others can put to good use?

		------======<<<<<<(((((     )))))>>>>>>======------


        I am co-chairman of the "PTF Education Committee" (PTF is
Parent-Teacher-Fellowship) for a private, non-profit, Christian elementary/
middle school in Cedar Rapids, Iowa. We have two known-to-be-working Apples
and one IBM PC. We also have an Apple that I have not looked at yet. The
school's name is Isaac Newton Christian Academy. Money is tight, and
the roof needs repair, so usually fund raising tends to be directed towards
things other than computers. :-(

        We are, right now, working on establishing a "Computer Lab", and have
been talking about soliciting donations.

	We ask that if you have ANY Apple, Atari ST, Amiga or MS-DOS
hardware/ software items, partial systems, or complete systems, you
would SERIOUSLY consider donating these to our school. Even if it is an
item that needs repair, we'd be happy to accept it IF we know the
repair costs involved before it is
shipped to us.

	Even though we will appreciate any donation, here are some specific
	things we are looking for at this time:

		o  EGA graphics card/monitor for an IBM XT
		o  WordPerfect 4.2 for an IBM PC
		o  Educational software for an IBM PC
		o  Additional IBM PC's
		o  Anything to max out an Apple II+
		o  Color monitor for an Apple II+
		o  Educational software for an Apple II+, IIe or //c
		o  Amiga 500 Systems
		o  Atari ST Systems

	REMEMBER... this is a BONA FIDE non-profit organization!

Thank you for your consideration and support,

Bruce Rothwell

===============================================================================
  Bruce Rothwell                            \ /~~~~~~\     Opinions expressed
  barothwe@floyd.cca.cr.rockwell.com         X        )    are mine, but they
  Rockwell Int'l - CCA                      / \______/     might be shared by
  Cedar Rapids, IA                                              multitudes !!
===============================================================================




Newsgroups: comp.sys.atari.st
From: baumer@cs.utwente.nl (Han Baumer)
Subject: Llamatron-resistent joystick
Organization: University of Twente, Dept. of Computer Science
Date: Wed, 16 Dec 1992 19:33:46 GMT

Does anyone know of a joystick that is easy to hold, easy to play and
does not break while playing llamatron? 

Many joysticks are to be stuck on a table: I don't like that because
the joystick always manages to get loose in the middle of the game. I
have seen some very robust joysticks but they are so hard to play (you
have to be a really strong to play llamatron with it). I have used a
joystick that met the first two criteria, however, its microswitches
tend to break very quickly.


Han.


-- 
     ___            Han Baumer                        <baumer@cs.utwente.nl>
 ___/   \________
|   \___/        | Univ. of Twente,  Dept. Computer Science,     TIOS-group
| ___ _   _   __ | P.O. Box 217,     NL-7500 AE  Enschede,  The Netherlands
|  |  |  / \ (_  |                   tel: +31 53 89 3742
|  |  |  \_/ __) |                   tel: +31 53 89 3755 fax: +31 53 333815
|________________|
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st
Subject: Re: NTSC from SVGA
Date: 13 Dec 92 20:22:00 GMT
Article-I.D.: K.A45188
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

n>I don't think that the Mega STe has NTSC or RF outputs, either (at least not
n>the one I looked at).

European Mega STEs have PAL and RF outputs.
Newsgroups: comp.sys.atari.st
From: TOBIAS@cip.physik.uni-stuttgart.de ()
Subject: Q:Neural Net Simulation on the ST ?
Organization: CIP-Pool Physics Dept, University of Stuttgart, FRG
Date: Thu, 17 Dec 1992 14:36:08 GMT
X-News-Reader: VMS NEWS 1.24

I am looking for a NN package (Public Domain or cheap) with
source code for the ST.

I don`t need nice grapics and such things so perhaps a
general C (or whatever) package is also possible.

Any ideas where to get ?

Thanks in advance. Tobias.
From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: *Help*  I need to make a non-standard text file stand
Date: Tue, 15 Dec 1992 00:14:16 MDT
Reply-To: mforget@elfhaven.ersys.edmonton.ab.ca
Organization: Electric Storm
X-Software: HERMES GUS 1.00 Rev. Jan 16 1992

In <71472@cup.portal.com>, Bob_BobR_Retelle@cup.portal.com writes:

>Michel Forget writes about wanting to convert linefeed characters
>to carriage return/linefeed pairs...
> 
>A very simple way to do this is to use a wordprocessor
>(like ST Writer) which has Search and Replace capabilities..
> 
>I often have to do that with files from the Amiga world (for
>whatever reason, their text files are formatted like this, with
>just linefeeds, no CRs), and ST Writer does it just fine.
> 
>I also use the capture buffer in Flash 1.60 which has the same
>capabilities to search and replace text.
> 
>ST Writer is free, and should be available from atari.archive...
>
>BobR

I have received the same answer (word processors) from about seven
different people.  I should have made this more clear, but I meant
I needed to program a way to do this automatically.  If I only wanted
to read the file, I could use a word processor, but I need the program to
read the file (and the file changes each day).

The problem has been solved, though.  Thank you to all of those who
offered help!

-- 
<<  -----------------------------------------  >>
<<    mforget@elfhaven.ersys.edmonton.ab.ca    >>
<<  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  >>
<<               Michel Forget                 >>
<<   The Key:  Spirit over mind over matter.   >>
<<  -----------------------------------------  >>
Newsgroups: comp.sys.atari.st.tech
From: dinolt@wdl1.wdl.loral.com (George W Dinolt)
Subject: SIGIO for MiNT
Organization: Loral Western Development Laboratories
Distribution: comp.sys.atari.st.tech
Date: Tue, 15 Dec 1992 01:12:34 GMT

In my attempts to port (gnu)oleo to my Atarist 1040 under MiNT, I
found I needed to be able to ``handle'' SIGIO.  In the recently
distributed MiNT 96 version 14 (experimental) SIGIO appears in the
list of signals in .../include/signal.h but no mention of it is made in
the source.  After rummaging around for a bit in the source, I made
several small changes, one to proc.c (process initialization) and one to
bios.c (in checkkeys(), which signals SIGIO if there are new and unread
characters in the io record).  

For those who care and don't know, SIGIO is- 
#define	SIGIO	23	/* input/output possible signal */

These changes seem to work well for the keyboard. But they are not the
general solution and don't signal io for any of the other available
file handles. Does anyone have a better, more general approach for
sending SIGIO?  Might this feature be included in future releases of
MiNT?

(Gnu)oleo is a ``spread sheet'' program distributed by the Free
Software Foundation. (Oleo is better than the high priced spread.) As
delivered, it works with either an X or curses interface.  I was able
to port the curses version easily to (my modified) MiNT by adding two
lines of code (long _stksize=-1; binmode(1);) to the appropriate
places. This provides an asynchronous keyboard interface. There is
supposed to be an interface which doesn't require SIGIO, but it
doesn't work and it was easier to fix MiNT than to fix that interface.

Many thanks to Eric Smith and the others who have put MiNT and the
libraries together.  You have provided me with a very fine
environment.
--
Regards,
George Dinolt (dinolt@wdl1.wdl.loral.com, (408) 473-4150)

 
Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Supexec
Organization: SAR Systems Development & Processing, JPL
Date: Tue, 15 Dec 1992 23:03:38 GMT

In article <2b25c6d5@p15.f202.n281.z2.fidonet> p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl writes:
>Well, d0-d2 and a0-a2 certainly will not be guaranteed to work because the
>TOS-routines use (some of) those to determine the address of the
>Supexec-routine. But maybe d3-d7 and a3-a6 will survive because tose are
>always the ones TOS-routines are guaranteed not to be changed.
>But to be on the safe side: pass the arguments via the stack ar a fixed
>paramter block.

I've noticed in at least TOS 1.4 and TOS 1.6 that register a5 is zeroed when
the called routine gets executed. That was rather distressing to discover...
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
From: afsfpel@cid.aes.doe.CA (Yves Pelletier)
Newsgroups: comp.sys.atari.st.tech
Subject: 1.44 meg TT upgrade
Keywords: floppy disk upgrade TT
Date: 12 Dec 92 22:24:06 GMT
Reply-To: afsfpel@cid.aes.doe.CA (Yves Pelletier)
Organization: Environment Canada

I have just received the TOS 3.06/High density floppy drive upgrade kit for my
TT. Rather interestingly, there are no schematics or instructions
included.    I'm pretty sure this has been discussed here in the past,
but I would be
grateful if we could return to that topic for a moment. Here are some specific
questions I have:

1. I anticipate the easiest part will be to upgrade the TOS chips. This should
simply consist of removing the old TOS and putting in the new one, right?

2. The driver chip I will be replacing with the so-called Ajax chip is
socketed, not soldered, right? 

3. There have been reports of upgrades not performing as they should, due to
EM interference. What do I need to do to make sure the upgrade will work? I
seem to recall that a screw has to be removed from the power supply assembly.

4. Will the upgrade have an impact on my machine's ability to run Spectre?

I intend to do the upgrade myself, if at all possible. If need be, I have
relatives, with technical qualifications, who can help. 
 

Thanks in advance,


Yves Pelletier



---------------------------------------------------------------------
Yves Pelletier                               afsfpel@cid.aes.doe.ca
Centre Meteorologique Canadien      "I am resplendent in divergence" 
Dorval, Quebec, Canada                                           D.B.

*********************************************************************
Newsgroups: comp.sys.atari.st.tech
From: paetau@mits.mdata.fi (Rasmus Paetau)
Subject: Re: *Help*  I need to make a non-standard text file standard.
Organization: Microdata Oy, Helsinki, Finland
Date: Fri, 11 Dec 1992 21:50:50 GMT

In article <71472@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes:
>Michel Forget writes about wanting to convert linefeed characters
>to carriage return/linefeed pairs...
> 
>A very simple way to do this is to use a wordprocessor
>(like ST Writer) which has Search and Replace capabilities..
> 
>I often have to do that with files from the Amiga world (for
>whatever reason, their text files are formatted like this, with
>just linefeeds, no CRs), and ST Writer does it just fine.
> 
>I also use the capture buffer in Flash 1.60 which has the same
>capabilities to search and replace text.
> 
>ST Writer is free, and should be available from atari.archive...
>
>BobR

You can do the same by loading the text with only linefeeds to 1st
Word and then saving it immediately, it will be saved with the CR's
added. At least this is the way it happens for me :).


--
-----------------------------------------------------------------------
| Rasmus Paetau (paetau@mits.mdata.fi) | I still believe in Falcon030 |
-----------------------------------------------------------------------
Organization: Ryerson Polytechnical Institute
Date: Thursday, 10 Dec 1992 15:23:56 EST
From: <EENG6826@RyeVm.Ryerson.Ca>
Newsgroups: comp.sys.atari.st.tech
Subject: Re: HPACK 0.78 binaries ?
Distribution: na
 <1g4l2sINNrhm@golem.wcc.govt.nz>

No. HPACK 0.7
Newsgroups: comp.sys.atari.st.tech
From: ersmith@netcom.com (Eric R. Smith)
Subject: Re: XBRA and Memory Protection.
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Thu, 17 Dec 1992 18:46:58 GMT

In article <memo.814282@cix.compulink.co.uk> apelled@cix.compulink.co.uk writes:
>>From: Roine Stenberg
>>To  : Adam Pelled
>>Subj: Re: Xbra on MultiTOS ?

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

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

Of course it has to be done in supervisor mode, since most of the interrupt
vectors are in locations that are only accessible in supervisor mode.

Doing it in supervisor mode solves another problem, too: any program
that changes an interrupt vector must make its memory accessible to
any other program that is in supervisor mode, since otherwise
the interrupt will cause a bus error. Hence, you know that you can
indeed read another program's XBRA structure, as long as you are in
super mode.

NOTES: (1) Avoid trapping into interrupt vectors. If you don't grab
vectors, you don't need XBRA, and the whole thing becomes much easier.
MultiTOS provides a variety of ways to do things without grabbing
vectors; you can even write a debugger that doesn't grab vectors!

(2) If you can't do (1), then use Setexc() to change vectors. If you
do, then MultiTOS will automatically grant supervisor access to other
processes for the memory the vector points to, and everything will
work transparently.

(3) If you don't do (2), users will have to run a utility to change
your program's flags so that it will not be protected against supervisor
access. Users won't like having to do this. So use Setexc(), that's
why it's in the operating system!

Regards,
Eric
From: anneklin@acs.bu.edu (Patricia Anne)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: XBRA
Date: 12 Dec 92 18:40:09 GMT
Organization: Boston University, Boston, MA, USA

In article <Bz0533.AwK@newcastle.ac.uk> Craig.Graham@newcastle.ac.uk (Craig Graham) writes:
>
>XBRA is an inter-application communication protocol. It allows desk-accs and 
>programs to talk to each other and swap data. There are several levels to the
>protocal, etending right up to direct swapping of .GEM/.IMG files (similar to
>MS Windows DDE).

Whoa!  Bogus!  XBRA is a protocol for allowing programs to insert
(and, theoretically, delete) themselves from interrupt and trap
vectors, so that you won't trash another program that has done the
same thing for the same vector.

Unfortunately, it isn't paid attention to by everyone, which is a
shame, since you need just one non-conforming program to screw up the
whole setup.

I am curious as to what protocol you're referring to, though--are you
just talking the normal GEM appl_write/read() pair, or what?

Later,
Newsgroups: comp.sys.atari.st.tech
From: Mike Stramba <stramba@zooid.guild.org>
Subject: Re: MiNT, which way forward...
Organization: The Zoo of Ids
Date: Fri, 18 Dec 1992 04:29:05 GMT

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

>
>Here's a copy of a discussion document I sent to the MiNT mailing list
>earlier today...
>
>---- Start of included message ----
>From reading the comp.sys.atari.st* groups it has become increasingly clear
>that there are two distinct groups of MiNT users, each of which have
>differing priorities for future developments.
>
>The two groups are as follows:-
>
>1) People who are looking for MiNT to provide a multitasking kernel
>	underlaying GEM so as to give the same sorts of functionality as MS
>	Windows, Windows NT or Apple's MultiFinder.
>
>2) People who are looking to use MiNT as the basis for a cheap substitute
>	for Unix as a development environment and possibly as a multiuser
>	service.
>
>Group (1) have the following priorities:-
>
>	(1) compatability with the old Mono-TOS/GEM
>	(2) process protection
>	(3) rudimentry virtual memory (ie monolithic, merely giving the
>		processes in total a machine with a virtually bigger RAM
>		size)
>	(4) networking (virtual drives)
>
>Group (2) have these priiorities:-
>
>	(1) Process protection (including user id access control)
>	(2) Close emulation of Unix at library/OS levels.
>	(3) Internal Unix-like networking stubs (ie sockets, both UNIX and
>		INET Domains). Drivers for networking itself could be loaded
>		at boot time, but the code for inet stuff etc should be in
>		the kernel and multithreaded so as to be able to guarantee
>		as fast a response as possible. The INET loopback device
>		should be in the kernel as standard too.
>	(4) Per-Process, highly efficient virtual memory (giving a process a
>		virtual machine)
>	(5) Shared libraries
>	(6) Mountable file systems (so only those file systems which the
>		operator wants to appear are actually visible, and they can
>		be placed where they are needed)
>	(7) Hardware specific terminal/serial drivers (which can take full
>		advantage of the higher specification hardware available on
>		the Mega STE, TT and Falcon)
>	(8) Multithreaded file systems
>	(9) Less granularity for scheduling. (MiNT currently feels to have
>		very coarse context switching.)
>

I am interested in both groups, at the moment I'm concentrating more on
group 2.

I have not been using MiNt much yet, having only 1 meg and one floppy.

What is the current state of MiNt in regard to the above items?

Mike
From: clausb@hpbbrd.bbn.hp.com (Claus Brod)
Date: Thu, 17 Dec 1992 13:34:43 GMT
Subject: Re: XBRA and Memory Protection.
Organization: HP Mechanical Design Division
Newsgroups: comp.sys.atari.st.tech
X-Newsreader: TIN [version 1.1.8 PL6]

Adam Pelled (apelled@cix.compulink.co.uk) wrote:
> >---------[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)
> >--------------------------------------------------------------------------

Only TSRs should intercept OS vectors, thus effectively becoming a part of
the OS. Now if every TSR has its 'global' flag set (i.e. announces that
all its memory shall be public to other processes), everyone can follow
the vector chain without any memory protection problems.

-- 
--clausb@hpbeo79.bbn.hp.com----------------------------------------------
Claus Brod, MDD, HP Boeblingen   	Things. Take. Time. (Piet Hein)
--#include <std_disclaimer>----------------------------------------------