HDTenEightyP/NetNews huggingface dataset:
From: boris@sys6626.bison.mb.ca (boris)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: 520 ST problem
Date: Sun, 23 Aug 92 02:42:06 CST
Organization: system 6626 BBS, Winnipeg MB

jeffh@oakhill.sps.mot.com (Jeff Hunsinger-MUX_Tech) writes:

> Over the weekend, I picked up a 520 ST. When I turn it on, the screen flashes
> white for a fraction of a second, then goes black. The computer doesn't seem
> to be looking at the drive (looking for a boot disk), so I assume TOS exists
> in ROM (this is my first experience with an ST.) Shouldn't I get some sort
> of display here? I opened the case and checked all the voltages. Everything
> checks out. I noticed a bunch of empty sockets off to the right. There were
> 2 ROM (?) chips installed, but I suspect there may be more necessary (?)
> 
To help we probably need more info.
  Ie, do you have an internal or external disk drive?
      What kind of monitor are you using?
      can you hear the drive at all?
      Put a formatted disk in before you turn the machine on,
        hold your finger just touching the disk. Can you feel the drive 
        vibrate?
      Hav you checked all the trivial little things, like connections
       the monitor brightness dial at the back, etc.?
      What exactly does it say just above your numeric keypad?
     
If you have just 520st over the keypad, And an external disk drive then 
it's one of the earlier machines and may need tos on disk to run. 
  There should be a label on the underside of the 520. What does it say 
as far as the model number goes?
  Did you get a grey labeled disk with the machine with the word "TOS" on 
it?  if so you need to boot with that.
  If the label underneath says 520STm then you can hook it up to your TV 
with a connoector like those that came with the old 'Pong' games. Try 
that. Maybe the monitor is fried.

 Give full details of your system when posting messages for help.
 
good luck.
boris

;--- (boris) a user of sys6626, running waffle 1.64
;E-mail: boris@sys6626.bison.mb.ca
;system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8
From: ugafence@ubvmsd.cc.buffalo.edu (UB FENCING CLUB)
Newsgroups: comp.sys.atari.st.tech
Subject: is it possible to change the font in hi res?
Date: 19 Aug 92 20:09:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

Ok, now I don't really know what I'm talking about here, so bear with me...

  I'm fond of my mono monitor, BUT, the font sucks.  Plain and simple.  Is
there any way to change it to something a little bit smoother around the 
corners?  I'm primarily using wordwriter & flash.

  Any help would be greatly appreciated, thanks..

.Philip
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Continuing 1.44 Drive Woes
From: sheppard_r@kosmos.wcc.govt.nz
Date: Thu, 13 Aug 1992 12:06:54 GMT
Reply-To: sheppard_r@kosmos.wcc.govt.nz
Organization: Wellington City Council, Wgtn, NZ

In article <92225.143240JJL101@psuvm.psu.edu>, J.J. Lehett <JJL101@psuvm.psu.edu> writes:
>In article <4228@wet.UUCP>, ekrimen@wet.UUCP (Ed Krimen) says:
>>
>>In article <1992Aug11.005337.4789@usenet.ins.cwru.edu>
>>as423@cleveland.Freenet.Edu (Kenneth A. Wallace) writes:
>>>
>>
>>>    I find myself in the same situation as J.J. Lehett, a
>>>worthless 1.44 Disk Drive.
>>
>>Exactly which situation is that?  Do you have an old Mega STE?  Below
>>you say you know not to buy an Ajax chip (or am I missing or forgetting
>>something)?  You need an Ajax chip for the 1.44meg drive to work.
>>
>
>     I would assume that the situation he is referring to (J.J.'s = me)
>is that I have a TOS 2.05 MSTe that came with a 1.44 drive.  It didn't
>work, and I posted about this a time or two.  I upgraded to TOS 2.06, and
>even replaced the Ajax chip thinking it could be defective, so... with these
>improvements I 'in essance' should have a reliable 1.44 drive.  This is not
>the case.  I have pulled the power supply screw, I have unhooked the Hard Drive
>from the power supply to avoid any interference from the power lines, and
>I continue to always get a error upon formatting at track 45 when in HD mode.
>Yes, I have tried numerous high quality HD disks.
>     I have been able to on occasion format a disk on an IBM and bring it
>home and read all 1.44 megs succesfully... but never get a successful format
>from the desktop.
>     I have been told that its really sound like an interference problem,
>but with the error occuring at track 45 on formatting no matter what disk
>I am using, this doesn't sound like it could be random interfernce, not to
>mention that I have as I said pulled the power to the Hard Drive to reduce
>the interfernce and still the same repeatable error.  Diamond Format reports
>the error as a cannot seek track error (I think that was it).  Once it hits
>track 45, you can hear the head going back and forth attempting to 'seek' the
>track to no avail, and then it errors out.
>     Always on the lookout for more things to try, I have tried just about
>everything that has been suggested so far, and I do not have another MSTe
>available to try to swap mechs unfortunately.
>------------------
>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
>  GEnie: JLEHETT2                        Delphi: JLEHETT@delphi.com

From what I have read, you also have to replace the GALL chip, and add a wire on
the older Mega STE's, is this the case..??

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

Newsgroups: comp.sys.atari.st.tech
From: r0mill01@ulkyvx.louisville.edu (Robert Delius Royar)
Subject: Re: Using Setexec() [a bit of help needed]
Reply-To: r0mill01@ulkyvx.louisville.edu
Organization: University of Louisville
Date: Tue, 18 Aug 1992 10:22:46 GMT

In article <1992Aug17.175736.7804@pbhya.PacBell.COM>, dbsuthe@pbhya.PacBell.COM (Daniel B. Suthers) writes:
>execute under any C compiler.  The name of a function evaluates to the
>address of the function just like the name of an array does.
>
>
>   void (*jumpto)();		/* A pointer to a function. */
>   void sec_on();		/* Declare that the sec_on function exists. */
>
>   jumpto = sec_on;	/* Set the pointer to the address of the function*/
>   jumpto();		/* Execute the function that's at the address
>			 * pointed to by the pointer.
>			 */
>Daniel B. Suthers,  CCP
>Technology Consultant, PCS & IN Development Lab,        Pac*Bell
>Voice: (510) 671-1325               UUCP:  pacbell!pbeos!dbsuthe
>================================================================================
>=  Commit unexpected kindness and senseless acts of beauty.                    =
>================================================================================

If jumpto is a pointer to a function, won't the call jumpto() cause a "bad 
indirection" error in the compiler?  Shouldn't it be called by
 (*jumpto)();  ?

r. royar (NYIT no address from here)
From: bnell@siemens.com. (Bill Nell)
Newsgroups: comp.sys.atari.st.tech
Subject: format of object files in gcc
Date: 18 Aug 92 17:40:59 GMT

Can anyone tell me where to find the format of the .o files used by gcc?
I don't feel like wading through the source or anything like that.  I would
prefer some simple docs.  I want to write a program to convert them to DRI
or GST format so I can link them with object files from my assembler (and
yes I know gcc can do inline asm but I hate the syntax).  Also, I guess I
should ask if anyone has already made such a program already to save myself
the trouble. 


						Thanks,
						Bill

--
bnell@ferrari.siemens.com    | Quote of the Day:
Siemens Corporate Research   |   Those who are wise to the words are wise
755 College Road East        |   to those for whom words are sufficient.
Princeton, NJ 08540          |                         - Scott Surowiec
From: afsfpel@cidsv03.cid.aes.doe.CA (Yves Pelletier)
Newsgroups: comp.sys.atari.st.tech
Subject: set vs setenv
Date: 15 Aug 92 06:13:40 GMT
Reply-To: afsfpel@cidsv03.cid.aes.doe.CA (Yves Pelletier)
Organization: Environment Canada

I've been experimenting with some of the CLIs that are available for
the ST/TT, and now I have a little question someone here could probably
help me with:

What exactly is the difference between the commands 'set' and 'setenv'?
I know what a variable is, and also what an environment variable is.
I'm asking because the shell I have almost decided upon (Tomshell), 
doesn't have a 'setenv' (just 'set'). Other shells, notably gulam, have
both 'set' and 'setenv'.

Does the lack of a setenv command in Tomshell mean it simply cannot set
environment variables at all?


Yves Pelletier afsfpel@cid.aes.doe.ca
From: RESCHKE@DMSWWU1A.UNI-MUENSTER.DE (Julian F. Reschke)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Trapping ^C
Date: 14 Aug 92 11:40:33 GMT
Organisation: Westfaelische Wilhelms-Universitaet, Muenster, Germany

In article <1992Aug14.071027.24659@mnemosyne.cs.du.edu>, ilepore@nyx.cs.du.edu
(Ian Lepore) says:
>
> What's a good method of trapping a ^C from within a program and ignoring
>it?  I've tried using the terminate handler (vector 0x0102) but that gets
>control on *any* type of program exit (ie, even if you called exit()).  I
>can't find anything in the atari docs that says how to tell if the terminate
>handler was invoked by a detection of ^C in DOS, but (oddly enough) they
>call that vector the ^C handler in the docs.
>
> (Actually, leave out the "and ignoring it" part of that question.  I can
>handle that part of it with a longjmp, I just need to be sure it's a ^C
>termination and not a normal program exit.)

According to the official documentation, you are not allowed to to
further GEMDOS calls from within the terminate handler. This means, that
all current 'solutions' that *do* catch CTRL-C this way are doing
something unofficial (note that it's easy when you are using MiNT...).

>
> (Also, suggestions like "uninstall your 0x0102 handler in the exit()
>routine" are Not An Option for me -- the program could have done a Pterm()
>or a gemdos(0) or something else that I can't catch at all.)

The terminate handler is called *BY* the Pterm*() functions -- you can rely
on that to remove your handler.
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: access to the screen using C?
Date: 22 Aug 92 04:40:31 GMT
Organization: Carnegie Mellon, Pittsburgh, PA

> how would I get a pointer to (or suitable handle) to allow direct 
> writing to the screen?
> i'm using sozobon, are there books on this subject?

Just never try to access screen directly: it is not compatible to new
machines and it is not nice (comfortable) to do. Finally, you never take
profit of all the work of OS programmers (or better of NVDI programmers)
!

VDI is here to be used ! it may not be the fastest way to draw something
but it is convenient !

	Stefan Monier


-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
From: boris@sys6626.bison.mb.ca (boris)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Continuing 1.44 Drive Woes
Date: Thu, 20 Aug 92 01:43:40 CST
Organization: system 6626 BBS, Winnipeg MB

baffoni@aludra.usc.edu (Juxtaposer) writes:

> 	Hi,
> 
> 	I've been watching the problems with the 1.44 drive in a MSTe, and
> I was wondering if anyone tried replacing the floppy drive, and if they
> tried the connecting-all-grounds-to-earth-ground trick that someone posted?
> 
> 	-Mike
> 
> 


 Also I recieved this in reply to one of my suggestions. I assume th 
author doesn't want his name know or he would have posted this himself.

   From:??????@eos.ncsu.edu
To: boris@sys6626.bison.mb.ca
Subject: Continuing 1.44 Drive Woes
Date: Tue, 18 Aug 92 10:26:53 EDT


In order to use 2MB drives you will need:

1.  A 2MB drive
2.  The new floppy controller chip (not the 1774)
3.  Dip switch 7 turned on (in the drive bay, near front of machine)
4.  TOS 2.06 (or 3.06 if you have a TT030)
5.  Space between your monitor and your floppy drive (a monitor stand 
will
    suffice) because of interference.
6.  The removal of the central screw (near transformer) in power supply
    to reduce monitor jaggies (this is not really necessary, but helps)

I have set up many systems for customers of Computer STudio (Asheville, 
NC)
and have a MegaSTe myself with a HD upgrade.

---------

Hope it helps.

;--- (boris) a user of sys6626, running waffle 1.64
;E-mail: boris@sys6626.bison.mb.ca
;system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8
From: benz@infko.uni-koblenz.de (Hartmut Benz)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Utterly bizarre idea for Atari
Date: 17 Aug 92 10:42:32 GMT
Organization: Universitaet Koblenz (FB Informatik)

Eric S Johansson writes
> it is not as surreal/unreal as you think.  I suggest you look into
> andy tannenbaum's amoeba system and see how close you came to
> reinventing the wheel.

And besides: How do you think ATARI would implement a system as smart as  
amoeba on this hypothetical computer? They are still in training camp to  
get a single user/single (and a half) tasking os running without bugs at a  
moderate speed :-)!
_______________________________________
Hartmut Benz                          | benz@infko.uni-koblenz.de
D-5400 Koblenz, Germany               |       (NeXTmail ok)
From: JJL101@psuvm.psu.edu (J.J. Lehett)
Newsgroups: comp.sys.atari.st.tech
Subject: Update on MSTe SCSI 1 id
Date: 21 Aug 92 22:46:43 GMT
Organization: Penn State University


    OK, well in adding another drive to the SCSI chain, I have found it
impossible (now I know exactly which jumpers to set for the HD's for proper
SCSI ID's) to get anything recognized as other that ID 0 on the onboard
SCSI adaptor in the MSTe.  Has anyone had success with this?  Once again,
I added a SCSI 2 way cable to to the adaptor board inside the MSTe, and added
the conner in that line, but irrelevant of that, neither the Seagate nor
the Conner when appropraitely jumpered will be recogized unless it is at
SCSI 0. Is it impossible to actually use 2 'internal' drives this way in the
MSTe without resorting to using the DMA port?
------------------
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
  GEnie: J.LEHETT2                       Delphi: JLEHETT@delphi.com
From: baffoni@aludra.usc.edu (Juxtaposer)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon 030 ?  nah wait the 040 !
Date: 21 Aug 1992 10:02:47 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

In article <1992Aug21.083142.16355@prl.dec.com> amos@prl.dec.com (Samos) writes:
>I think there is a large step between the 68030 and the 040, 
>the programmation is being more interesting, and I even could
>say that the 040 is a microprocessor half CISC half RISC..
>and to buy a falcon at 16Mhz 030 is to buy an 'under-TT device'..
>so wait for the high technology, and buy the falcon 040 !

	I don't think this is such a good idea, for several reasons.

	First, not everyone needs a high-speed machine.  You don't need more 
than say an 8MHz 68k to do basic WP.  Musicians all over the world seem to have
been quite happy with the slow ST for quite some time - and the falcon offers
more speed and certainly more features than any ST has had.

	Second, not everyone could afford a higher-speed machine.  The Falcon
offers a LOT of good features that make it more than just a ST replacement -its
more like getting a slightly slower TT but with special cards already installed
(ie sound, video, SCSI-2).  Not to mention multi-TOS.  And the Falcon is cheap - especially when you consider that you won't have to buy another monitor to
make it run (but is recommended) unless all you have is a mono monitor.

	Third, Atari has put a lot of money into producing and developing this
product.  If it doesn't sell, what makes you think they will put more 
development money into an '040 machine?  What makes you think they would have
the cash to do so, even if they wanted to?  By urging other not to buy and thus
reduce revenues would cause them to be tighter with the cash - and who wants
them to skimp when designing an '040 version?  Not me!!!

	Besides, you are assuming that an '040 version will be out anytime 
soon.  Maybe some of those people need a computer in the next few months, not
the next couple of years.

	I am not saying that an '040 version would not be right for you, and
you may be able to wait, but I don't think you should neccessarily say that
it is not right for someone else.  I know that if I was serious into the 
music business, I'd jump at the deal.  Even though I'm not, if I didn't have
a TT, I would seriously have considered buying it anyway.

>Samos.

-Mike




Newsgroups: comp.sys.atari.st.tech
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Subject: Re: Can a TSR Malloc()?
Organization: University of Western Ont, London
Date: Thu, 13 Aug 1992 00:16:05 GMT

In article <1992Aug12.181935.11706@mnemosyne.cs.du.edu>, ilepore@nyx.cs.du.edu (Ian Lepore) writes:
>  I've always thought it should be possible to temporarily change TOS's _run
> variable temporarily so that it points to the TSR's basepage during the 
> Malloc() then gets set back to the proper value.

Aack! No, don't do this (it's precisely this "trick" that I warned you
would break!). I think this is exactly why Atari warned people not
to change _run. (If you're interested: MiNT doesn't use _run at all for
memory management, because MiNT doesn't care about basepages, only
about process id's -- this allows for funky things like fork() and
vfork().)

>  Seriously, though...it would be nice to have an alternate form of Malloc()
> usable by TSRs and desk accessories...something where you could pass a  
> pointer to the basepage of the process that should own the memory.

There's a much better solution -- don't TSR! If your program is
running under MultiTOS or MiNT, it doesn't have to terminate in order
to stay resident; it can just run in the background. It can then do
Malloc or file calls with no problems. If it wants to install some
code in a vector that other processes can use, that code should use
one of the (many) inter-process communication methods to send the
Malloc request over to the "main" application which is hanging around
in the background.

The Ptermres() call was a rather ugly hack that Microsoft invented to
make up for the lack of multitasking in MS-DOS. I think it's outlived
its usefulness.
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario

Newsgroups: comp.sys.atari.st.tech
From: amos@prl.dec.com (Samos)
Subject: Falcon 030 ?  nah wait the 040 !
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 21 Aug 1992 08:31:42 GMT

I think there is a large step between the 68030 and the 040, 
the programmation is being more interesting, and I even could
say that the 040 is a microprocessor half CISC half RISC..
and to buy a falcon at 16Mhz 030 is to buy an 'under-TT device'..
so wait for the high technology, and buy the falcon 040 !

Samos.



Newsgroups: comp.sys.atari.st.tech
From: mfg@gmd.de (Martin Gergeleit)
Subject: Re: Reopen an ACCs window
Organization: GMD, Sankt Augustin, Germany
Date: Tue, 18 Aug 1992 06:07:38 GMT

In <BAMMI.92Aug13222840@acae127.cadence.com> bammi@acae127.cadence.com (Jwahar R. Bammi) writes:

>	why waste your time and creative juices. help stamp out ACC's !!
>man, go get MiNT and be happy :-)

>IM(not so humble)O: Acc's is/was one of the worst ideas on the St. Its
>implementation in AES sucks even worse.

I AM using MiNT and it is fine, but as long as there is no MultiTOS available
I _have_ to use ACCs in order to get a sensible Window-System with terminals.
BTW even Eric Smith uses TOSWIN._ACC_ to use terminal sessions and GEM-
applications at the same time. I know, MultiTOS is "comming soon"*, but
who knows about the quality of the implementation of Multi-AES ??

cheers,
Martin Gergeleit <mfg@gmd.de>

*"comming soon" is a trademark of ATARI

Newsgroups: comp.sys.atari.st.tech
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: is it possible to change the font in hi res?
Keywords: mono, font, hi-res, warp9, acc
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Thu, 20 Aug 92 21:29:10 GMT

In <1992Aug20.141753.6428@digi.lonestar.org> rgoseweh@digi.lonestar.org (Roy Gosewehr) writes:

>In article <Bt8vvD.4G@acsu.buffalo.edu> ugafence@ubvmsd.cc.buffalo.edu (UB FENCING CLUB) writes:
>>
>>  I'm fond of my mono monitor, BUT, the font sucks.  Plain and simple.  Is
>>there any way to change it to something a little bit smoother around the 
>>corners?  I'm primarily using wordwriter & flash.

>The Warp 9 Control Panel (accessory) allows you to load any font you
>want (and it comes with a lot of them).  I just received my Warp 9 the
>other day and happened to be playing with this last night.  (Actually,
>the 3270 font looks nice :-)  But since I just started using this
>package (used to use Turbo ST), I can't point out any caveats, etc..

Another possibility is to get NVDI. The GDOS integrated into NVDI
has  a  special  feature,  namely  that the names of fonts in the
ASSIGN.SYS file may be preceded by an s, in which case the system
font  is  replaced  with  that  GDOS  font.  NVDI comes with some
alternate fonts, and if you don't like any of them  you  can  use
any GDOS font.

 +- 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: mpark@milton.u.washington.edu (Michael Park)
Newsgroups: comp.sys.atari.st.tech
Subject: How to steal a vector?
Date: 21 Aug 92 17:04:12 GMT
Reply-To: mpark@u.washington.edu
Organization: University of Washington, Seattle

Is there a "correct" way to replace, for instance, a BIOS routine
with one of my own?  If so, please describe it.

Many thanks in advance.


-- 
Ciao-abunga!           +-------------------------------------+
Michael Park           | This space intentionally left blank |
mpark@u.washington.edu +-------------------------------------+
Newsgroups: comp.sys.atari.st.tech