HDTenEightyP/NetNews huggingface dataset:
From: hubert@nebula.sni.de (Hubert)
Newsgroups: comp.sys.atari.st.tech
Subject: Floppy streamer <-> ATARI ST
Summary: asking for info on floppystreamer for ATARI
Keywords: streamer, floppy, controller
Date: 15 Apr 92 05:46:04 GMT
Reply-To: baum.pad@sni.de
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany


Has anybody connected a Colorada floppy streamer to the ST?

Or has anybody information on the protocoll that the floppystreamer is using?

Where can I get this information?


 +--------------------------------------------------------------------+
 |  Hubert Baum                             Tel.: int 49 5251 8 31862 |
 |  Siemens Nixdorf Informationsysteme AG   Fax:  int 49 5251 8 31869 |
 |  AP 333                                                            |
 |  Riemekestr 160                Email:  (uucp)                      |
 |  D-4790 Paderborn              from   USA: baum.pad@sni-usa.com    |
 |                                form other: baum.pad@sni.de         |
 +--------------------------------------------------------------------+
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: Wed, 8 Apr 1992 02:14:16 GMT

In article <1992Apr7.121005.1@lapis.labmed.umn.edu>, davidli@lapis.labmed.umn.edu writes:
> In article <1992Apr7.234257.1@cc.curtin.edu.au>, smackinla@cc.curtin.edu.au writes:
>> I _should_ be able to unMSA a disk on _any_ ST (with the possible
>> exception of one with a single sided drive).
> 
> You have, of course, the (relatively) tedious option of using the 'pseudo-B'
> drive on a 1-drive system.  Run the SHADOW program (the unMSA program, not the
> background downloader... :) ), locate the .MSA file on the =B= drive, and let
> the unMSA program write to the =A= drive.
> 
> BTW, I don't know of any of the MSA-ed demos on the atari.archive server which
> do not require a double-sided disk drive...

I'm afraid that you must have missed the original posting. The whole idea was
to get away from doing the hundred odd disk swaps required to unMSA the file
using the psuedo disk drive.

Pat -- have a day!

PS: Why do people write programs like this in the first place!?! You would think
they would have learnt from all the versions of TOS < 1.4 how tedious it was
with a single drive!
From: vspicer@ccu.umanitoba.ca
Newsgroups: comp.sys.atari.st.tech
Subject: DMA with SCSI on TT030??
Date: 8 Apr 92 20:55:22 GMT
Organization: University of Manitoba, Winnipeg, Manitoba, Canada

hello. we are having some problems with SCSI DMA transfers on our TT030.
we have previously developed code to talk to an exabyte 8200 tape drive
via the SCSI port, but the code handshakes the bytes across using
software control.

the TT tech manual explains the process of setting up the SCSI DMA, including
the odd-byte addressing in the pointer and counter addresses. this is
not a problem. our previous code does all the SCSI dirty-work of getting
to the point where the DMA transfer can take place (target shifting into
data transfer phase).

i am consfused about what programming is needed on the 5380 SCSI control
chip. the process right now is: 
	1- set up DMA base address and byte count
	2- set DMA for "read" in control register
	3- program 5380 to be in DMA mode, but not block DMA
	   (mode register bit 1 set, 7 masked)
	4- assert data bus on 5380
	   (initiator register, bit 0 set)
	5- set data mode on 5380 (in this case a READ from TAPE to RAM)
	   (dma target receive register, any write)
	6- start DMA process 
	   (control register, bit 1 set)

this returns a busy-error on the SCSI bus status register, and nothing
is transfered. does anyone have a working method for doing DMA transfer
to and from a SCSI device?
From: hojo@cbnewsb.cb.att.com (HC Johnson)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: How to use the cartridge port?
Summary: borrow a spectre cartridge
Date: 9 Apr 92 20:49:23 GMT
Organization: AT&T

In article <31465@sdcc12.ucsd.edu>, cs163wfj@sdcc8.ucsd.edu (Dennis Lou) writes:
> 
> A friend of mine has asked me to do some data acquisition work
> on his Atari ST.  Unfortunately, I know IBM's and I know Amiga's
> but I don't know ST's.  I would like to read 512k-1024k of data
> from either EPROMs or SRAM cartridges and be able to store it to disk.
> 
> 
> How is the cartridge port addressed?  How do the ROM select lines work?
> Does the system automatically pass control the cartridge on power
> up?  Does anyone else have any better ideas on how to read
> information off of an EPROM or SRAM cartridge?
> 
The easy way to do this is to find someone with a MagicSAC or Spectre
cartridge holder.
(Magic sac for 64 K roms only)

The Spectre allow you to read the roms FA0000-FBFFFF; FC0000-FDffff

The only problem is the five bits are scrambled a bit:  sort of like:

15 14 13 12 11 10 09   8 7 6 5 4 3 2 1 0    ROM
reads in as
15 14 13 12 10 09 11   8 7 6 5 4 3 2 0 1    ROM

This may not be exact (but close).  I have the facts and a copy program
at home.

Remember that 1 ROM has either all the even bytes or all the odd bytes.
Thence FC0000, FC0002, ... FDFFFE is on one ROM
and    FC0001, FC0003, ... FDFFFF is on the other ROM

Howard Johnson
ATT BELL LABS
att!mtgzy!hcj
hcj@mtgzy.att.com
From: jhenders@jonh.wimsey.bc.ca (John Henders)
Newsgroups: comp.sys.atari.st.tech
Organization:  One of these days.
Subject: Re: Making the screen one line
	<A38834@MS.maus.de>
Reply-To: jhenders@jonh.wimsey.bc.ca
X-Software: HERMES GUS 1.00 Rev. Jan 16 1992
Date: Mon, 13 Apr 1992 09:53:54 -0600

In <1992Apr12.191837.24409@convex.com>, William Rosenkranz writes:
>
>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.
>
    I think many of the graphic driver writers, having appearantly no 
clear guidelines from Atari, are leaving the Physbase and _v_base_ad 
stuff alone to allow developers to develop 2 monitor applications. 
This is a handy feature, where menu screens don't cover what is being 
worked on in the other monitor. 
    Why don't you just bite the bullet and write you application as a vdi
application? It's really not that much harder, and one extended inquire
should return everything you need to know. You don't have to use the aes
to use the vdi and if you're careful about keeping text byte aligned, it's 
not that slow. I agree that losing one line is a real pain in the butt,
especially if your using a dial up and you have to change your term info 
on every system you call to get a -more- scroll done right, but, though I
haven't tried it yet, I think a vdi screen doesn't ahve the menu bar 
problem. 
    There are also fairly quick ways of changing the font characteristics
with the vdi, even if the vdi vt52 stuff is broken. Of course, this means 
tweeking your vdi calls in assembly, but if you want fast....


-- 
       John Henders      jhenders@jonh.wimsey.bc.ca
    I think your "evolutionary scale" needs an adjustment.  Either 
      that, or you've got your thumb on it. -> (lefty@apple.com)
From: steve@thelake.mn.org (Steve Yelvington)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: help with sozobon getenv()
Date: 8 Apr 92 16:48:52 GMT
Article-I.D.: thelake.A1578768520


[In article <18420016@hpsad.HP.COM>,
     randyh@hpsad.HP.COM (Randy Hosler) writes ... ]

 >   Still, I don't understand why dlibs doesn't have a header to declare
 >   getenv().  Maybe I'm missing something.  I grepped my include directory
 >   and found no reference to getenv().

No, you're not missing anything, it's jut not there. I think the reason is
simply that dLibs predates ANSI. Dale Schumacher created the library as a
replacement for the Alcyon C library long before Sozobon existed. Over the
years it has gained some ANSI-like properties, but it isn't there yet. For
his Heat and Serve 1.33i package, Ian Lepore added a pseudo-stdlib.h file
but didn't include a declaration for getenv.

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 
Newsgroups: comp.sys.atari.st.tech
From: subiaagb@w350zrz.zrz.tu-berlin.de (Andre Pareis)
Subject: Re: 2 HD's on MSTe Host Adapter
Organization: ZRZ der TU-Berlin
Date: Tue, 14 Apr 1992 15:09:06 GMT

In article <8394@bnr-rsc.UUCP>, Anthony Paul writes:
|> 
|> So I'd like someone to try flipping one of the end dip switches (if one
|> 	doesn't work, try the other) and trying to hook 2 drives with the rev 5.x
|> software.
|> 


I'd try it, but I have rev. 4.xx of Atari's HDX only.

Q:  Where can I get the new rev. 5 ?
From: ralph@laas.fr (Ralph P. Sobek)
Newsgroups: comp.sys.atari.st.tech
Subject: Media Change Questions
Date: 8 Apr 92 10:42:22 GMT
Distribution: comp
Organization: LAAS-CNRS France

I am curious as how to properly handle Media Changes in my software,
both wanted and unwanted occurences.  I am doing this on a Mega 4
running under TOS 1.2.

As I understand it, when MediaCh() goes from 0 to 1 or 2, on the next
read or write [I use Rwabs()] I will get E_CHNG or -14 as the return
code from Rwabs():

	Rwabs(0,...), ChangeDisk, Rwabs(0,...) gives -14.

Furthermore, other calls to the program after this keep giving -14 as
a return code for Rwabs().

	Rwabs(0,...), ChangeDisk, Rwabs(2,...) executes properly.

But the state of the ST is left at -14 if I call the program again.
Even the following works properly:

Rwabs(0,...), ChangeDisk, Rwabs(2,...), Rwabs(0,...) executes properly.

But the state is left at -14 as concerns GEMDOS, etc.

A friend passed me his Lattice C documentation, and it stated that
Get_BPB() resets the MediaCh() flag to 0.  Now the following works:

	Rwabs(0,...), ChangeDisk, Get_BPB(), Rwabs(0,...) executes properly.

Unfortunately, they state that a Media Change should be forced before
calling Get_BPB() since the latter may cause system buffers to be
lost.

In this case, how does one *force* a Media Change such that GEMDOS and
BIOS recognize it?  

Maybe it is the same question, but how does one force GEMDOS, etc. to
flush its internal buffers for a device?  Does a *Forced* Media Change
take care of this.

Thanks to all, in advance.

--
Ralph P. Sobek			  Disclaimer: The above ruminations are my own.
Ralph.Sobek@laas.fr			   Addresses are ordered by importance.
ralph@laas.fr						If all else fails, try:
ralph@laas.uucp, or ...!uunet!laas!ralph	      sobek@eclair.Berkeley.EDU
Phone: (+33-)61-33-62-66  FAX-1: (+33-)61-33-64-55  FAX-2: (+33-)61-55-35-77
===============================================================================
Got a Mega 4 ST. Wish it was a Mega STe? :-|  Do I *really* want a TT/Next? ;~#
From: JOKHC@CUNYVM.BITNET (Joshua Kronengold)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: ST ANSI.SYS?
Date: 9 Apr 92 19:09:21 GMT
Article-I.D.: CUNYVM.92100.150921JOKHC
Organization: City University of New York/ University Computer Center

In article <1992Apr6.123541.45787@qut.edu.au>, lunnon@qut.edu.au says:
>
>In article <55ekiB1w164w@bluemoon.rn.com>, loren@bluemoon.rn.com (Loren Sims)
>writes:
>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.
>
Well all you have to do is get a copy of the latest version of FZT...
From: plate@cdsmn.mn.org (Doug Plate)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line
Date: 12 Apr 92 17:19:41 GMT
Reply-To: plate@cdsmn.UUCP (Doug Plate)
Organization: Dicomed Inc, Burnsville, MN.


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.  But wouldn't one 
solution be to include with the software, TOS or machine specific driver(s)
that can be chosen either automatically by a system "sensing" routine or
chosen from a setup menu?  I mean this is how some PC applications approach
different VGA card usage.  In fact most device specific PC applications
require some type of driver software.  Why should ST/STe/Mega/TT/Falcon/Etc,
be any different?  This way you can make the screen a line shorter any way
the programmer chooses, then additional drivers can be added as needed for
different machines, frame buffers of TOS versions.  I mean come on!  I'm not
allowed to write any software unless I buy one of each type of frame buffer,
screen accelerator and platform that exists to test for compatibility?

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

Regards,
Doug
Organisation: Westfaelische Wilhelms-Universitaet, Muenster, Germany
Date: Wednesday, 15 Apr 1992 10:54:05 MES
From: <ONM07@DMSWWU1A.BITNET>
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line
 <1992Apr12.171941.27921@cdsmn.mn.org>

In article <1992Apr12.171941.27921@cdsmn.mn.org>, plate@cdsmn.mn.org (Doug
Plate) says:
>
>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.  But wouldn't one
>solution be to include with the software, TOS or machine specific driver(s)
>that can be chosen either automatically by a system "sensing" routine or
>chosen from a setup menu?  I mean this is how some PC applications approach
>different VGA card usage.  In fact most device specific PC applications
>require some type of driver software.  Why should ST/STe/Mega/TT/Falcon/Etc,
>be any different?  This way you can make the screen a line shorter any way
>the programmer chooses, then additional drivers can be added as needed for
>different machines, frame buffers of TOS versions.  I mean come on!  I'm not
>allowed to write any software unless I buy one of each type of frame buffer,
>screen accelerator and platform that exists to test for compatibility?
>
>Or is this just a philosophical discussion and I'm missing the point?
>
>Regards,
>Doug

Well there IS such a driver mechanism. It's called VDI. That's what VDI
drivers are fore, and that's why one should to all screen output with
VDI functions.
From: mforget@ersys.edmonton.ab.ca (Michel Forget)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line shorter (at the bottom) -- How?
Date: Thu, 09 Apr 92 11:58:20 MDT
Organization: Edmonton Remote Systems, Edmonton, AB, Canada

micro@imada.ou.dk (Klaus Pedersen) writes:

> There have been some discustion about how to make the screen 1 line shorter,
> but DON'T USE THE LINE A VARIABLES. IT WILL NOT WORK!!!!
> 
> Consider what happens when if you have redirected console output to a window,
> will it work?? -NO!
> 
> Consider what happens if the program terminates "uncontrolled", How many line
> will the next programs have? 
> 
> Consider what what happens when you put the program in the background (under
> MiNT) and start an editor, that expects a full screen...
> 
> 
> DON'T DO IT! WE HAVE ENOUGH BAD PROGRAMS ALLREADY.
> 
> 
> -Klaus


Do you have an alternative?

Your points are valid, but they do little to solve the problem.  Making a 
status bar that does not flicker is not a simple matter without the 
Line-A.  Most people that use MiNT will also use a terminal emulator that 
they can run in the background as well, since that would allow them to 
have background file transfers.  One way to solve the problem would be to 
make the status bar an option.  You can have it or, if you are using MiNT 
and need to avoid conflicts, you can not have it.  As for an uncontrolled 
termination, that should never happen within the program.  The only time 
it could happen would be at start-up or when another program is spawned.  
Both situations are easy enough to avoid.  If you are multi-tasking the 
problem becomes more serious.  Another task might bomb-out, leaving you 
in the lurch.  Still, that is a possability that cannot be avoided.  As 
for re-direction, you can't re-direct this program.  It is GEM, not TOS.

Anyway, if you have an alternative, I would be glad to listen to it.


<<  ------------------------------------------  >>
<<        mforget@ersys.edmonton.ab.ca          >>
<<     ersys!mforget@nro.cs.athabascau.ca       >>
<<               Michel Forget                  >>
<<  "This offer is valid on absolutely ANY day  >>
<<           of the year, except...."           >>
<<  ------------------------------------------  >>

Newsgroups: comp.sys.atari.st.tech
From: comptec91006@camins.camosun.bc.ca
Subject: Are Ataris really this bad with HD's?
Organization: Camosun College
Date: Wed, 8 Apr 1992 19:17:45 GMT

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
it is reading the directory and FAT during this delay.  I know the drive is
reasonably fast - in Mac mode it will write files instantly.  It seems that
the Atari operating system is very slow when dealing with anything bigger than
a floppy disk (which doesn't surprise me).  Does anyone else have this problem?
I have TOS 1.3...  Do the new versions of TOS have the same problem?
                                                     /\/\ike
Newsgroups: comp.sys.atari.st.tech
From: cummins@a.cs.okstate.edu (CUMMINS JOHN WILLI)
Subject: FAST spice needed!  (68030/copressor) Probe too!
Organization: Oklahoma State University, Computer Science, Stillwater
Date: Mon, 13 Apr 92 22:05:15 GMT
From: timg@ncsa.uiuc.edu (Tim Gallivan)
Newsgroups: comp.sys.atari.st.tech
Subject: 'gem' prefix for tcsh?
Keywords: MiNT, tcsh
Date: 17 Apr 92 04:44:39 GMT
Organization: University of Texas Center for Relativity

Hi,

Can anyone tell me if a program exists for generic shells which
imitates the 'gem' prefix of gulam?Gem programs started from
bash and tcsh are generally mouseless (useless), and often do not
properly fill the desktop. If no such program exists, does anyone
have any suggestions for writing one?

I presume that such a program would save the screen, do the proper
things with the background and the mouse (what gem functions), exec the
desired program, and restore the screen in the end. Could such a thing
be made to work with MW2 running under mint? I have heard that more
than one gem program at a time is problematic.

Thanks,

Tim Gallivan
timg@landau.ph.utexas.edu
From: hojo@cbnewsb.cb.att.com (HC Johnson)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: How to use the cartridge port?
Summary: borrow a spectre cartridge
Date: 9 Apr 92 20:52:44 GMT
Organization: AT&T

In article <31465@sdcc12.ucsd.edu>, cs163wfj@sdcc8.ucsd.edu (Dennis Lou) writes:
> 
> A friend of mine has asked me to do some data acquisition work
> on his Atari ST.  Unfortunately, I know IBM's and I know Amiga's
> but I don't know ST's.  I would like to read 512k-1024k of data
> from either EPROMs or SRAM cartridges and be able to store it to disk.
> 
> 
> How is the cartridge port addressed?  How do the ROM select lines work?
> Does the system automatically pass control the cartridge on power
> up?  Does anyone else have any better ideas on how to read
> information off of an EPROM or SRAM cartridge?
> 
The easy way to do this is to find someone with a MagicSAC or Spectre
cartridge holder.
(Magic sac for 64 K roms only)

The Spectre allow you to read the roms FA0000-FBFFFF; FC0000-FDffff

The only problem is the five bits are scrambled a bit:  sort of like:

15 14 13 12 11 10 09 08   7 6 5 4 3 2 1 0    ROM
reads in as
15 14 13 12 11 09 08 10   7 6 5 4 3 2 0 1    ROM

This may not be exact (but close).  I have the facts and a copy program
at home.

Remember that 1 ROM has either all the even bytes or all the odd bytes.
Thence FC0000, FC0002, ... FDFFFE is on one ROM
and    FC0001, FC0003, ... FDFFFF is on the other ROM

Howard Johnson
ATT BELL LABS
att!mtgzy!hcj
hcj@mtgzy.att.com
Newsgroups: comp.sys.atari.st.tech
From: comptec91006@camins.camosun.bc.ca (Michael Botten)
Subject: Re: Are Ataris really this bad with HD's?
Organization: Camosun College
Date: Fri, 10 Apr 1992 01:26:29 GMT

In article <hjv.702809911@groucho.phil.ruu.nl>, hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
> 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?)

Well, I can move the mouse while I'm waiting, but I can't do anything else.
The problem is just in Atari's FAT search routine - it is very slow with 
anything bigger than a floppy disk.  Several people have told me to get a
utility called "FatSpeed" which will fix the problem...
_______________________________________________________________________________
               __    __   __ ___ ___  __
 /\  /\  o |/ |_    |__/ |  | |   |  |_  |\ | (Well, isn't this special...)
/  \/  \ I |\ |__   |__\ |__| |   |  |__ | \| CompTec91006@Camins.Camosun.BC.CA
_______________________________________________________________________________

From: freds@hpcc01.corp.hp.com (Fred Saavedra)
Date: Tue, 7 Apr 1992 16:04:58 GMT
Subject: Re: ST mouse flaky; easy fix?
Organization: the HP Corporate notes server
Newsgroups: comp.sys.atari.st.tech


I just fixed my son's mouse last week by blowing the dust away from th optics.
The mouse works like new now.

Newsgroups: comp.sys.atari.st.tech
From: mattw@picasso.cssc-syd.tansu.oz.au (Matthew Watson)
Subject: Re: How to use the cartridge port?
Organization: Telecom Australia
Date: Thu, 9 Apr 92 00:02:14 GMT

cs163wfj@sdcc8.ucsd.edu (Dennis Lou) writes:


>A friend of mine has asked me to do some data acquisition work
>on his Atari ST.  Unfortunately, I know IBM's and I know Amiga's
>but I don't know ST's.  I would like to read 512k-1024k of data
>from either EPROMs or SRAM cartridges and be able to store it to disk.
>After looking at the connector pinouts of various ports on the 
>back of the ST, I was thinking that the cartridge port would
>be well suited to the task.


>How is the cartridge port addressed?  How do the ROM select lines work?
>Does the system automatically pass control the cartridge on power
>up?  Does anyone else have any better ideas on how to read
>information off of an EPROM or SRAM cartridge?

>E-mail responses preferred.

If you install  a new disk icon giving it the letter "c" (small), when you
click on it the window comes up with the title "cartridge"!

Maybe the cartridge can be accessed as a filesystem!?

>-- 
>Dennis Lou             || "But Yossarian, what if everyone thought that way?"
>dlou@ucsd.edu          || "Then I'd be crazy to think any other way!"
>[backbone]!ucsd!dlou   |+====================================================
>dlou@ucsd.BITNET       |Steve Jobs and Steve Wozniak went to my high school.
-------------------------------------------------------------------------------
     -  Matthew Watson -  	   | MHSnet: mattw@cssc-syd.tansu.oz.au
     Australian and Overseas	   |
  Telecommunications Corporation   | Snail : 9th Floor, 320 Pitt Street
         Network Services	   |        Sydney, Australia 2000.
  Customised Software Solutions    |  or 115 Mitchell Rd Alexandria 2015.