HDTenEightyP/NetNews huggingface dataset:
From: aq115@cleveland.Freenet.Edu (Robert C Glover)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Are Ataris really this bad with HD's?
Date: 9 Apr 92 04:34:41 GMT
Article-I.D.: usenet.1992Apr9.043441.19710
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)


Mike:
 
First, there is no such thing as TOS 1.3.  It sounds like you have
1.0 or 1.2.  What you are experiencing is called the Fat Search Bug.
On all TOS's before 1.4, you need a program called FATSPEED.PRG, wich
you should be able to find on atari.archive.  Make this the first
file in your auto folder (it has to be first or it won't install
properly), and it will cure the problem.  I had to use it for three
years, until I got my Mega STE, which doesn't require it.
 
Hope this helps!
 
Rob
-- 
| Robert Glover                               GEnie:  R.GLOVER3 |
| Internet:           rg@turing.acs.virginia.edu                |
| Cleveland Freenet:  aq115@cleveland.freenet.edu               |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: lunnon@qut.edu.au
Newsgroups: comp.sys.atari.st.tech
Subject: Re: ST ANSI.SYS?
Date: 6 Apr 92 17:35:40 GMT
Organization: Queensland University of Technology

In article <55ekiB1w164w@bluemoon.rn.com>, loren@bluemoon.rn.com (Loren Sims) writes:
>   With the demise of the two best Atari BBSs in town, I've been spending
> more time connecting with PC-based boards.  The trend for these folks is
> toward fancier and fancier graphics, assuming that I have a call to
> ANSI.SYS in my CONFIG.SYS file.  I'm using Flash (under TOS 1.0 yet), so
> of course, this is nonsense.
>   
>   What I'm wondering is if there is any facility for interpreting ANSI
> screen codes for the ST, either in a particular comm program or as a
> seperate driver (I don't want to have to use an emulator for tele-
> communications).
>   
>   Alternately, can anyone recommend a good reference of ANSI specs that
> I might use to take a hack at writing something that could serve as an
> ANSI.SYS for the ST?
>                                                           thanks,
>                                                                   -Loren
> 

This is an evolution which I personally deplore. BBS systems should cater
for general connects like all other online services, rather than assuming
all the world owns an IBM PC. Most of your problems stem from the fact
that the STs extended character set is not the same as PCs, thus the PC's
linedrawing characters are not available. This is really a font problem
fortunately STs use exclusively soft fonts, so it aught to be easy to
load an IBM compatible font into your ST in order to get the semi-graphics
printing right (instead of junk coming out). Problem is that no-one seems
to have done much about drawing an IBM compatible font (8 and 16 bit) yet.

Any takers ...





> 
>  This is from
>      loren@bluemoon.rn.com
> who doesn't have their own obnoxious signature yet


	BOB Lunnon
	R.Lunnon@qut.edu.au
Newsgroups: comp.sys.atari.st.tech
From: as666@cleveland.Freenet.Edu (Jonathan Roy)
Subject: Books wanted (Leemon)
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Wed, 15 Apr 92 07:42:07 GMT


I'm trying to locate Atari ST: TOS or/and Atari ST: VDI by Sheldon
Leemon. If anyone knows of a mail order place that still has a few,
please let me know! (Of, if you want to sell one used....)

-- 
  |||  Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu
  |||  -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet --
 / | \ "...make him want to change his name,take him to the cleaners,
 devastate him, wipe him out, humiliate him." -CHESS   GEnie: J.ROY18
From: randyh@hpsad.HP.COM (Randy Hosler)
Date: Thu, 9 Apr 1992 15:50:42 GMT
Subject: Re: help with sozobon getenv()
Organization: HP Signal Analysis Div - Rohnert Park, CA
Newsgroups: comp.sys.atari.st.tech


>If you switch to the MiNT library you'll have a far more ANSI-like setup,
>even though you still can't handle prototypes.
> ---
> Steve Yelvington              Marine on St. Croix, Minnesota, USA 
> steve@thelake.mn.org          umn-cs!thelake!steve 
>----------

   I have the source for the MiNT library but have not had the time, nor
   the know-how to build it.  It would be nice if someone could upload
   a heat-n-serve MiNT lib for sozobon.  

   On another point...
   Why doesn't sozobon put the name of the program in argv[0]?  Everytime
   I try to reference argv[0] all I get is "".  

   main(argc, argv)
   int argc;
   char *argv[];
   {
	printf("%s\n", argv[0]);
   }

   All this program does is print a blank line.


To everyone who has responded,
Thanks for all the help!
Randy Hosler
Organization: Penn State University
Date: Wednesday, 15 Apr 1992 04:39:03 EDT
From: J.J. Lehett <JJL101@psuvm.psu.edu>
Newsgroups: comp.sys.atari.st.tech
Subject: Memory Causing HD errors! (again)

    OK, thanks to a number of folks, I have been able to disable the
upper 2 megs of Ram on my 4 meg upgraded Mega 2 ST.  And it has narrowed
down my problem...
    Once I disable this 2 meg bank of ram (which is on a Xtra Ram board),
I get NONE of the hard drive write errors and subsequent sense 04 messages
that I get when copied the same K of files WITH the ram activated.
These errors only occur with programs that load as much as possibly from
source before writing, such as cheetah, neodesk, vault, etc... never get
the errors straight from the regular desktop, since it does a file at a time.
I have thoroughly checked the memeory chips with different ram testers, and
they appear fine, never got an error...

    Thus, what I am left with is the following, normal programs, ramdisks,
etc are able to use this extra 2 megs of ram just fine, but not the Hard
disk when attempting large writes.  Any idea's?  DMA chip possibly?  How does
it interface with the ram banks?

     Getting closer to solving this bugger of a problem... :)
------------------
J.J. Lehett     : Atari's, puzzles, games, chaos, fractals, math....

  - jjl101@psuvm.psu.edu                 Penn State CAC
  - aa400@cleveland.freenet.edu          Atari 16/32 bit SIG Sysop
  - j.lehett2                            Genie address
Newsgroups: comp.sys.atari.st.tech
From: ivan@erich.triumf.ca (Ivan D. Reid)
Subject: Re: help with sozobon getenv()
News-Software: VAX/VMS VNEWS 1.41    
Organization: TRIUMF: Tri-University Meson Facility
Date: Tue, 7 Apr 1992 02:45:00 GMT

In article <18420015@hpsad.HP.COM>, randyh@hpsad.HP.COM (Randy Hosler) writes...
>I'm trying to compile a program with the ~heat&serve~ sozobon using dlibs.
>In particular the calls to getenv() are not working.  
> 
>main()
>{
>	char *ep;
> 
>	ep = getenv("some_env_var");
>	printf("%s\n", ep);
>}
> 
>When I compile this I get an error:
>	Integral type not allowed - line 5   (or something like that)
> 
>I then change line 5 to:
> 
>	ep = (char *) getenv("some_env_var");
> 
>as it appears that no header file defines the return type of getenv().
> 
>This will now compile but when I run the executable I get a buss error
>from MiNT.
> 
>Can anyone give me some help with this?
> 
	I would think you should have a declaration 
char *getenv();
	somewhere.  Remember that any undeclared functions in C are assumed to
be ints.  Hence the complaint Integral type not allowed.  With the cast you are
really stirring things up.  Assuming that int and pointer are returned from
functions in the same register, the compiler will only take the int value of
the returned value (unless you happen to be using 32-bit ints :-).  Casting
this to (char *) will then sign-extend it to a 32-bit pointer, in essence
losing the higher bits of the address that was originally returned.  If the
return mechanisms are not the same, all bets are off -- you'll just get
garbage.

Ivan Reid, Paul Scherrer Institute, CH.			ivan@cvax.psi.ch
From: goetz_wegner@tbx-2.berlinet.in-berlin.de ()
Newsgroups: comp.sys.atari.st.tech
Subject: Re: help with sozobon getenv()
Reply-To: goetz_wegner@tbx-2.berlinet.in-berlin.de
Date: 11 Apr 92 15:31:00 MET
Distribution: COMP
Organization: Mailbox TBX-2 im Zerberus-Netz
X-Version: ZerUU V6.45c


>    Why doesn't sozobon put the name of the program in argv[0]?  Everytime
>    I try to reference argv[0] all I get is "".

  Just  try the getopt() function from DLibs 1.2. It supports the Unix like
  argument  parsing  with correct argv[0] implementation. It is very simple
  to  use  (have  a  look  at the sources coming with DLibs) and makes your
  programs almost fool proofed.

  Goetz

Newsgroups: comp.sys.atari.st.tech
From: smackinla@cc.curtin.edu.au
Subject: Re: Need help with MSA format
Organization: Curtin University of Technology
Date: Tue, 7 Apr 1992 14:42:57 GMT

> Have you tried putting the MSA file in a RAM Disk?  You could then expand
> to the disk in a: without having to swap...

Unfortunately this is not practical on a machine with 512k! Don't laugh! I will
probably upgrade my machine to a bit more memory at some stage, but that's not
the point. I _should_ be able to unMSA a disk on _any_ ST (with the possible
exception of one with a single sided drive).

Pat -- have a day!
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Are Ataris really this bad with HD's?
Date: 9 Apr 92 08:58:31 GMT
Organization: Department of Philosophy, University of Utrecht, The Netherlands

comptec91006@camins.camosun.bc.ca writes:

>I have a SyQuest hard disk with an ICD controller.  I have a 14 meg Atari
>partition and a 30 meg partition for Spectre GCR (Mac emulator)...
>Whenever a file is written to disk in Atari mode the system locks up for
>about 5 seconds and then suddenly spits the file onto the disk.  Presumably

This locking up means you really can't do anything during 5 seconds? Otherwise
it might be the ICD write cache - try putting it off. (or am I being dumb now?)

--
Hendrik Jan Veenstra - Department of Philosophy
University of Utrecht - The Netherlands
USENET: hjv@phil.ruu.nl   * don't worry about life; it's not permanent *
From: Julian_Reschke@ms.maus.de (Julian Reschke)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line
Message-Id: <A38489@MS.maus.de>
Date: Mon, 06 Apr 92 18:18:00 GMT
Organization: MausNet
X-Gateway: MausGate/News 1.04

Steve Yelvington wrote:

>I'd like to see a real example of where the Line A variables do not work.
>Redirection to a window doesn't qualify. TOS doesn't support it. You can
>perform such redirection by intercepting BIOS output, but if you go to that
>much trouble, why don't you take the extra step and support the Line A
>variables? The only such program that I've seen (Gemini) does so.

This was a hack for backward compatibility. The next version of Gemini
won't do this.

>The MicroEMACS text editor that I use reads the Line A variables to
>determine screen size. I've run it on a couple of large-screen monitors
>(Viking Moniterm and Image Systems). It worked fine.

You can do MUCH better:

(1) If you want to support MiNT, try the new ioctl's for the terminal
    size.
(2) Use termcap or terminfo.

A _very_ easy way:

(3) Use the environment variables ROWS and LINES (if LINES is not set, use
    COLUMNS). This way it already works with the Gemini console window,
    and this is what POSIX propagates.

If all this fails, use the negative Line A vars. This way, every user can
override the possibly wrong Line A values.

>I suppose that somewhere there may be a setup that doesn't support the
>Line A variables, but that doesn't mean someone who has a standard ST
>shouldn't use those variables in his or her personal software.

Yes, but every software that is released to the public, should be as
well behaved as possible. Especially in this case you see, that it's NOT
much work.
Newsgroups: comp.sys.atari.st.tech
From: glens@natinst.com (Glen Sescila)
Subject: I need help joining GENIE!
Organization: National Instruments, Austin, TX
Distribution: usa
Date: Sat, 11 Apr 1992 21:24:52 GMT

	I am a relatively new registerd ST developer and I would like to
join GENIE to read the developer round-tables.  Could somebody please let
me in on how to subscribe to GENIE?  The phone-book here in Austin, TX
has no listing for GENIE anywhere!

Much thanks in advance!  (hopfully I'll see you soon on GENIE)

-----------------------------------------------------------------------------
"Now You're Playing With Power Without The Price!"  Glen Sescila   |||
                                                                  / | \
My opinions do not necessarily reflect those of my employer and probably are
exact opposites.		glens@natinst.com
-----------------------------------------------------------------------------
From: jhenders@jonh.wimsey.bc.ca (John Henders)
Newsgroups: comp.sys.atari.st.tech
Organization:  One of these days.
Subject: Re: ST ANSI.SYS?
Reply-To: jhenders@jonh.wimsey.bc.ca
X-Software: HERMES GUS 1.00 Rev. Jan 16 1992
Date: Tue, 14 Apr 1992 18:44:54 -0600

In <1992Apr6.123541.45787@qut.edu.au>, lunnon@qut.edu.au writes:
.........This is really a font problem
>fortunately STs use exclusively soft fonts, so it aught to be easy to
>load an IBM compatible font into your ST in order to get the semi-graphics
>printing right (instead of junk coming out). Problem is that no-one seems
>to have done much about drawing an IBM compatible font (8 and 16 bit) yet.
>

    Well, you get IBM compatable fonts with Stalker, Trapido, and
Harlekin already, I think another one would be a waste of time.



-- 
There are a lot of intelligent people on the net that will go
ballistic when they are subjected to something stupid.
-- Larry Smith on the rec.arts.manga debate
From: R_Tim_Coslet@cup.portal.com
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line
Date: Thu, 16 Apr 92 21:24:43 PDT
Organization: The Portal System (TM)

William Rosenkranz (rosenkra@convex.com) wrote:
>I thought Physbase, by definition, tells this as does the _v_base_ad sys
>variable? why then do graphics cards break the rules? surely this info must
>be memory mapped somewhere, so that an address can be found, albeit in some
>contorted fashion depending on the sys config.

From what I have seen in VDI, it could even be configured to drive vector
graphics cards (which would have no frame buffer). These devices uses
command/vector lists and X-Y monitors instead of bitmapped RAM and
video monitors. Even if they mapped their command/vector list RAM into
the computer's main memory there would be no easy way to test or write to
individual "pixels" on such systems if you bypassed their driver software.

I have worked with vector graphics systems (used in Avionics) for over 14
years (gad! has it really been THAT long?) and know them quite well.

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
California could REALLY use 40 days and 40 nights of rain right now!
From: R_Tim_Coslet@cup.portal.com
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Floppy drive pulse on the TT
Date: Thu, 16 Apr 92 18:34:38 PDT
Organization: The Portal System (TM)
  <1992Apr10.033159.12438@cdsmn.mn.org>

In article: <1992Apr10.033159.12438@cdsmn.mn.org>
	plate@cdsmn.mn.org (Doug Plate) writes...
>Hey wow!  My guess was right?  I've heard people talking about the "dubious"
>nature of the Atari Media Change implementation, but I don't see the problem.
>I mean even with write protected floppies, unless you can pull that disk out
>and shove another in there in less than 1/60th of a second, the write protect
>status will change, right?  Are there more details I need to know to
>understand?  I figure the checking routine must count more than one pulse in
>order to determine the media change because I've seen that function call that
>returns the "a media change has occurred", "a media change has probably
> occurred", "a media change has definitly not occurred".  Weird!
Well, actually it doesn't count anything. Checking the write protect line is
ONLY used to change from "a media change has definitly not occurred" to
"a media change has probably occurred" state. Atari verifies if it has
actually occured by reading the bootsector and checking the serial number
when an access in attempted in "a media change has probably occurred" state.
If serial numbers match the system returns to "a media change has definitly
not occurred" state. If they don't then the system changes to "a media change
has occurred" state.

This is why switching IBM formatted floppies and writing can corrupt the
directory and FAT of the 2nd floppy placed in the drive.

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
California could REALLY use 40 days and 40 nights of rain right now!
Newsgroups: comp.sys.atari.st.tech
From: plate@cdsmn.mn.org (Doug Plate)
Subject: Re: Flopppy drive question
Reply-To: plate@cdsmn.UUCP (Doug Plate)
Organization: Dicomed Inc, Burnsville, MN.
Date: Fri, 10 Apr 92 13:34:49 GMT

In article <1992Apr5.000559.27320@mailer.cc.fsu.edu> boyd@nu.cs.fsu.edu writes:
>In article <31886@darkstar.ucsc.edu>, choclte@cats.ucsc.edu (Liz Neely) writes:
>>
>>
>>Can anyone tell me if its possible to attatch an IBM floppy drive to the
>>Atari ST? I have a spare IBM 51/4" floppy drive and I'd like to plug
>>it into my drive B spot.  My atari needs a roung plug, which this floppy
>>doesn't have, but is it possible to get an adaptor or something?
>>I want to do this because it would be nice to be able to transfer data
>>between the 2 different sized disks.
>>
>I put a set of instructional files and drivers for such drives on 
>atari.archive.umich.edu, in a file called ibmdrive.lzh.  The ability you 
>desire is relatively easy to accomodate, given that you are willing to 
>bolt some stuff together and make a simple cable.  I had such a device set 
>up in the past, and it worked fine.
>
>    ---------------------------------+-------------------------------------
>             Mickey R. Boyd          |  "Come to your senses professor  
>          FSU Computer Science       |     Fernberg.  You did not transcend 
>        Technical Support Group      |     the time-space continuum.  You  
>       email:  boyd@nu.cs.fsu.edu    |     got drunk in a topless bar."
>    ---------------------------------+-------------------------------------

Mickey, (and anyone else interested)
I have have read your files and they are excellent!  I had an idea to possibly
simplify the process though.  Now, I really should try this before speaking,
but hey, I'm impulsive and irresponsible ;^)

Wouldn't it simplify the process if instead of cutting and modifying the
existing drive B cable (assuming you have one) you opened the case of the 
ST and tapped onto the internal ribbon cable (the one attached to the 
internal floppy) using a daisy chain type thing?  Like:

                                /-------------[]< card edge to external floppy
                                |
         --------[][]------------[]
   Internal Cable ^ ^male end     ^female end to internal floppy

I just say this because ribbon cable is so much easier to work with than just
about anything, just using a vise, pliers, or vise grips to press the ends
into place.  You would then have to change the Drive select jumper on the
external from 1 to 2 (or from 0 to 1 depending on labels used).

One would probably want to hang a ribbon header out the back of the ST case
to allow for disconnection.

Do you think it will work?  

Regards,
Doug
From: randyh@hpsad.HP.COM (Randy Hosler)
Date: Mon, 6 Apr 1992 14:45:22 GMT
Subject: help with sozobon getenv()
Organization: HP Signal Analysis Div - Rohnert Park, CA
Newsgroups: comp.sys.atari.st.tech

I'm trying to compile a program with the ~heat&serve~ sozobon using dlibs.
In particular the calls to getenv() are not working.  

main()
{
	char *ep;

	ep = getenv("some_env_var");
	printf("%s\n", ep);
}

When I compile this I get an error:
	Integral type not allowed - line 5   (or something like that)

I then change line 5 to:

	ep = (char *) getenv("some_env_var");

as it appears that no header file defines the return type of getenv().

This will now compile but when I run the executable I get a buss error
from MiNT.

Can anyone give me some help with this?

-----
Thanks, Randy Hosler
Newsgroups: comp.sys.atari.st.tech
From: rosenkra@convex.com (William Rosenkranz)
Subject: Re: Making the screen one line
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Wed, 15 Apr 1992 04:31:31 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 <1992Apr12.171941.27921@cdsmn.mn.org> plate@cdsmn.UUCP (Doug Plate) writes:
>I have been watching this thread since the beginning now waiting for
>-THE ANSWER- But of course, there has been no one answer.  It seems that
>according to all I've read, there is no "legal" answer.  

there IS a legal answer (just not the one i want to hear :-) and that is
to use GEM (VDI and/or AES). another alternative would appear to be to use
MiNT/MGR. i am now leaning to the latter (tho i still have to look into
pinging individual pixels under MGR) for my own use...

the problem with Physbase and the other "schemes" i was asking about is they
really break under a multitasking environment (like MiNT or its descendent
MultiTOS). this is because this info is global, not local to a "window" or
"task". i understand this. and hindsight is wonderful.

>Or is this just a philosophical discussion and I'm missing the point?

it is philosophical...

-bill
rosenkra@convex.com

-- 
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com
From: tony@microware.co.uk (Tony Mountifield)
Newsgroups: comp.sys.atari.st.tech
Subject: Sozobon 1.33i Heat'n'Serve bugs
Date: 7 Apr 92 12:26:56 GMT
Organization: Microware Systems (UK) Ltd., Winchester, UK.

Hi Folks,

I have been very successfully using the Heat'n'Serve Sozobon C 1.33i
that was posted a while ago. I think it may even be better than the
Lattice C 3.0.4 that I paid real money for some years ago. It's
certainly nicer to use!

I have found a couple of bugs in the header files:

1)      In stdio.h, the definitions of stdprn and stdaux are reversed. I
        wondered why my program wouldn't print, and then discovered the
        characters falling out of the serial port. :-)

2)      In types.h, the types BYTE, WORD and LONG are defined as
        unsigned. I have seen published code which relies on them being
        signed (book: Atari ST Application Programming), and they are
        signed in Lattice 3.0.4. I changed them to the following:

        typedef char BYTE;
        typedef int WORD;
        typedef long LONG;
        typedef unsigned char UBYTE;
        typedef unsigned int UWORD;
        typedef unsigned long ULONG;

3)      Sometimes, when running top, the optimizer, I get a number of
        messages saying something like:

        top: bugchk - filler bytes not equal (doesn't affect codegen)

        Can I safely ignore it - what does it mean? The program in
        question seemed to run OK. Unfortunately, I have now modified
        the program and the message no longer appears. (Well,
        unfortunately for bug-hunting, anyway :-).

Any comments?

Tony.
-- 
Tony Mountifield     (G4CJO)       | Microware Systems (UK) Ltd.
Email:  tony@microware.co.uk       | Colden Common, WINCHESTER, SO21 1TH.
(or:  ...!uknet!mwuk!tony)         | Tel: 0703 601990   Fax: 0703 601991
------------------------------------------------------------------------
** Any opinions are mine, not Microware's - but you knew that anyway. **
------------------------------------------------------------------------