HDTenEightyP/NetNews huggingface dataset:
From: johnj@echo.philips.nl (John Janssen)
Newsgroups: comp.sys.atari.st
Subject: Re: MIDI file players (WAS : MOD players)
Date: 14 Sep 92 09:55:55 GMT
Organization: Digital Equipment Corporation, E.C.H.O. development department

wrighttj@uhura.aston.ac.uk (Auntie Tim) writes:
>AVRK90@waccvm.corp.mot.com (Kevin Cox) writes:
>: Just wondering if anyone out there has heard of a MOD player that will
>: play MODs at random, say from a given disk.  Is there such a thing?
>Greetings- Personally, I'd like something like this for MIDI files (any
>format) which works as a DA or a background process. That way, I could 
>have real(-ish) music playing whilst word processing, backing up and so
>on. The CodeHead MIDI Spy demo does some of this, but is limited to 
>about 15k files (I'd need 100k plus) and about 10 minutes usage. The full
>version could do it, but I don't need the other facilities, such as 
>permanent recording. All I need is something which churns out data to the
>MIDI ports. Anything like this around?

Hi,

If the beta test version had not that one @#$% last minute bug,
I would have announced the new version of PLAYBACK.PRG right now.

Version 1.0 is already available on several archives (look for: PLAYBACK.ZOO).
Currently beta test version 1.04 is spread around to beta testers and
in two weeks I will spread version 1.1 around.

PLAYBACK is not a DA or background program, but can play standard MIDIFILES,
via the atari ST MIDI out port.

Version 1.1 wil run on all (ROM) TOS versions available,
It will run on all ST/STE/MEGA/TT/FALCON computers (tested at Dusseldorf Messe!),
It will run on all resolution/colours (as long as at least 80 characters can be 
displayed on a single line, and min. 25 lines fit on the screen. Note that it uses 
these sizes to make the program resolution independent while using GEM!)

Version 1 could only load/play/adapt/analyse songs.
The new version also can save the song, do midifile format conversion, and
has a lot of new features to easier adapt the song to your MIDI setup. So it
is pretty efficient to use (I prefer it to use it for trying out MIDIFILES I get
-including adapting these files to my personal MIDI setup-,even though I do own
C-lab's Notator program too).

The program can do much more. It can be installed in the desktop: just double
clicking a *.MID file will startup the program. You even can set the program's
preferences in such a way that it will start playing the song and quit the 
program as soon as the song is over. Or if you prefer a CLI... no problem!

Etc.

So please, two more weeks...

John. 
-- 
John Janssen         Email: johnj@echo.tds.philips.nl
The Netherlands      or:    John.Janssen@atehv.bso.nl
Work: +31 40 756425 
Home: +31 77 513177  Atari Mega STE, PC 386 SX, MIDI, Astrology, C
From: pwp@moose.cs.indiana.edu (Paul Purdom)
Newsgroups: comp.sys.atari.st
Subject: Stores in Altanta?
Date: 15 Sep 92 11:05:18 GMT
Organization: Computer Science, Indiana University

If anyone knowns of Atari stores near Atlanta Georgia and can reply by
September 16, please do so. I am getting ready for a visit there.
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.atari.st
Date: Thu, 10 Sep 1992 17:01:02 -0400 
From: Stefan Monnier <sm86+@andrew.cmu.edu>
Subject: Re: Is Falcon worth buying????
	<1992Sep10.041027.9029@zooid.guild.org>

Excerpts from netnews.comp.sys.atari.st: 10-Sep-92 Re: Is Falcon worth
buying???? Mark Kovarski@zooid.guil (1006)

> You can configure ANYTHING in OS/2 2.0, including what you want to install.
> My swap file doesn't exceed 2 MB. You must be joking when saying, "it feels
> like a 8 mhz ST." Have you really tried it. I see NO speed decreases in OS/2
> at all. As a matter of fact, I am running it on a 486/50 MHz DX with 16MB
> RAM and ATI Graphics Ultra. It is as fast as a TT with NVDI loaded in. The
> screen redraw functions are immediately displayed with no delay at all. On
> slower machines it might be the case but not on mine. Also, it accesses the HD
> since it always updates it. When you reboot it comes to same screen as you
> worked last on. Does it access the HD? Yes, so does every OS. 

Great news !! the 32Mhz 030 of the TT is not that slower than the
50Mhz 486 (even when the 486 has 16MB to deal with)

> Is MultiTOS faster? MultiTOS is a FAR inferiour product and doesn't offer 20%
> of all OS/2 functions. I have received some results that were performed with 
> MultiTOS such as screen redraw routines, VDI functions etc. The results are
> definetely slower. If MultiTOS sells nearly as many as OS/2 2.0 copies please
> let me know...

> Mark K.

Sure, OS/2 is much superior. But it NEEDS a bit more hardware to be
useful ! (I actually think 16MB 486 is a good start)

	Stefan Monnier

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





Newsgroups: comp.sys.atari.st
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Re: IBM Emulators
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Tue, 15 Sep 1992 14:58:02 GMT

In article 7407@oz.plymouth.edu, oddjob@oz.plymouth.edu (Andrew C. Stoffel) writes:

>Does someone have a list of IBM-"emulators" for Atari ST series

Andy, others in this group may add their $.02, but the only PC emulators that I
know as being currently supported are the ICD AT-Speed and PC-Speed units which
are priced around $400 and $200, respectively.  I don't believe the SuperCharger
(sold by Talon?) is supported any longer although you might still find the units
for sale.  And frequently you may find a PC-Ditto II hardware board for sale as
well as the PC-Ditto software only solution (works but very s-l-o-w).

There is not a tremendous market for PC emulators anymore because you may now
buy a standalone PC for not much more than the cost of these emulators.

Anyone know of any other PC emulators?
---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________


Xref: sparky comp.sys.atari.st:13720 rec.audio:12433 sci.skeptic:16357
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.sys.atari.st,rec.audio,sci.skeptic
Subject: Re: sampling and human hearing range (was Re: (none))
Date: 13 Sep 92 10:01:28 GMT
Article-I.D.: andrew.Iegs7sa00awM4HF1Zf
	<y031qB1w165w@tsoft.sf-bay.org>
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.atari.st: 13-Sep-92 Re: sampling and
human hear.. Russel Mar@tsoft.sf-bay. (2461)
> To clarify "a bit" for those unfamialr with DAT's and stuff:

> The standard DAT sample rate is 48KHz, which offers somewhat trivial 
> improvement over the CD standard of 44.1kHz.  However, by implementing 
> a copy restriction flag on commercial CD's, you are disallowed from mak
> ing direct digital-to-digital copies without constraints even if you are 
> able to record at 44.1KHz.  Of course, you cannot make direct digital 
> copies when the data rates don't match. (i.e. playback 44.1k, record at 
> 48k).
> --
> Russel Mar (bbs.ruscal@tsoft.sf-bay.org)


You seem to be informed, maybe you'll be able to finally
answer the typical question:

What's EXACTLY this 'copy restriction flag' ?
How is this protection implemented ?

It seems that without support from the DAT itself, it isn't 
possible to get this kind of protection.

	Stefan Monnier

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.sys.atari.st
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: Falcon Graphics
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Tue, 08 Sep 92 13:10:09 GMT

In <1992Sep6.123221.11986@access.digex.com> jhurwitz@access.digex.com (j. hurwitz) writes:

>The MAC OS was upgraded beause it sucks!. The reason they never had to change
>TOS so much is cause it was reliable. I don't go for a company that won't let 
>it's developers and or users customize their software and computers. Apple 
>wants everything to look the same. Besides, there is a UNIX boycott aginst
>for runnig aroound and slapping everyone with Look-Alike law suits.

>Even the MAC Bible slashes Apple and their lame OS...

Very well said! While the Atari officials may be clowns, as  Mark
K.  sees  it, the Apple guys are much worse. They don't even care
that their lawsuiting almost anyone who does something like a GUI
actually  harms the whole computer community by preventing people
from developing sensible stuff. Everything seems to be all  right
with them as long as it is likely to make them money. And just by
the way, Microsoft doesn't seem any  better  to  me.  What  about
their  "undocumented"  OS  calls? They warned everyone not to use
them, and then it turns out that the  Microsoft  programmers  use
them  all  the  time, because they are the only ones that get the
proper information about the calls and their future support.
So, Atari may be run by fools, but at least they  don't  seem  to
play as unfair as some other companies.

Greetinx, Jan

 +- 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: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st
Subject: Falcon030 vs. Falcon040
Date: 9 Sep 92 23:39:48 GMT
Reply-To: warwick@cs.uq.oz.au

With the price of a Falcon030 at $800, the best option is to buy an 030 as
soon as possible, beef it up with whatever monitor, memory and harddisk you
can afford, then upgrade to an 040 if needed later - you'll only be losing
on the $800 - everything else would be re-usable on the 040 (one would assume).
So, you sell your 030 for $500 to the neighbor to hook up to a TV and play
the cool games (which the brat has been playing ever since you bought
the 030).  $300 loss, max - and who knows, you may find the 16MHz 030 quite
sufficient - after all you've gotten along fine with a machine with one
quarter of the abilities for some time now, probably without a blitter.

I've already bought my hard-disk for the Falcon (okay, so I lose a bit
more, because I had to buy an ICD interface to use it for now on my ST),
so only memory and monitor are concerns (I wish now that I'd bought a
Multi-sync rather than my colour monitor!).


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /      void (if removed)
      v      Brisbane, Australia.        /
From: baffoni@aludra.usc.edu (Juxtaposer)
Newsgroups: comp.sys.atari.st
Subject: Re: 68040 accelerator board?
Date: 7 Sep 1992 22:03:29 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

In article <H.NB0mn1ZPbEM@fredrik.atari.no> jornmoe@fredrik.atari.no writes:
>>	From the descriptions so far, it is a stand alone (a tower?) from
>>the main Mega ST (only so far) that houses a 66MHz 68040 (way over-driven
>>IMHO, put perhaps bearable if it has some INDUSTRIAL STRENGTH heat sinks
>>and one heck of a fan - maybe liquid cooled :).  Perhaps more busses (I hope)
>>and memory.  Supposedly runs at about 24MIPs.  I wonder if it uses a cache
>>(outside of the onboard of the '040)?  Would really Haul A** with a decent
>>(ie: 256k+) cache...
>>
>This make no sence! The 25Mhz version of the 040 does 20MIPS. If a cklock
>frequency more than two times higher only yields 25% increase, I'd be 
>realy disapointed.

	Hmm.  What source are you quoting for the 20mip@25MHz?  Motorola?
If so, don't forget that they don't take into consideration real-world
problems like a) slow internal memory, b) OS overhead/ineffieciency, c) 
interrupts, etc.  Motorola uses an optomised test program (that does nothing
but execute no-ops or something similarly useless - maybe it just increments
a counter ... in a register ....) for those figures.

	However, if your MIP reading is a real-world figure, then yes, I would
say that is sad performance.  Even the Intel DX2 chips reported on real systems
were found to have a 50-70% increase over base system speed (more cache the
better).  This could mean that the Mega '040 thing is really inefficient and
probably has no cache (outside of the onchip 8 (16?)k.  Then again, it is
probably having to deal with slow (120ns) memory of the MegaST which is
further limited by a time-slice arrangement with the video.  If that is the
case (that it doesn't have its own memory), then I am REALLY impressed that
they could get 24MIPS out of it.

	Remember, it still has to use/communicate with the ST bus/architecture,
and there is likely to be a WHOLE lot of time eaten for I/O between busses.

>No, the thing is that this processor actually runs at 33MHz, but it has a
>onboard clock-doubler wich make the internal clock 66MHz. This is the same
>trick as done on the Intel DXII processors!

	A thousand pardons for not specifying that it used a slower 33MHz
bus.  BTW, if it is using a 33MHz bus, it is not using the MegaST's - if so,
it's bus must a) exist, b) have more than a CPU hooked to it, c) not reside
in the MegaST.  So the question becomes:  What is on the bus with the CPU?
However, like I said, there should be more than a measely 25% improvement
(unless I am not taking something into consideration that I should).

>  _______________________________________________________
> / Joern F. Moe /  All above is my own personal opinion! \
>/ Oslo, Norway /  Any lack of opinion above is also mine! \
>-----------------------------------------------------------

-Mike


Xref: sparky comp.sys.atari.st:13740 rec.audio:12445 sci.skeptic:16377
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.sys.atari.st,rec.audio,sci.skeptic
Subject: Re: sampling and human hearing range (was Re: (none))
Date: 14 Sep 92 05:34:05 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <1992Sep14.030459.8914@rosevax.rosemount.com> grante@aquarius.rosemount.com (Grant Edwards) writes:
>I thought that they reduced the sampling rate from 48KHz to 44.1 KHz
>so that the 9th symphony would fit on a single disk.  Can't let that
>legend die, can we?

Seems like almost the same thing either way - they could have increased the
sampling rate if they could have made the marks on the disk smaller; or they
could have made the disks bigger; or they could have ...  meaning I don't
think you can answer the question without talking about how all the
parameter values were selected.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
From: chan@pyramid.unr.edu (Kaho Chan)
Newsgroups: comp.sys.atari.st
Subject: MOD players (again?! *:)*)
Date: 13 Sep 92 09:15:54 GMT
Followup-To: chan@cs.unr.edu (Kaho Chan)
Distribution: na
Organization: University of Nevada, Reno

Well, I've just tried CDPLAYER.PRG and I like it very much.
Features:
	1)  graphical presentation of MOD files played (LED displays)
	2)  STE compatible (stereo/4 channel/2 left/2 right)
	3)  32 track capability (explain later)
	4)  ease of use

Okay.  It is a player of MOD files (if you haven't figured it out yet).
IT is NOT an editor, just a player (NoizeTracker, eg is an editor/player).

It is called CD PLAYER because the layout resembles a CD system (amp/controls/
l/r/etc).

32 track capability means:  if you have CDPLAYER.PRG in, for example, D:\MUSIC\
MOD\, you can have 32 MOD files in that specific directory (and that's the 
limit).  You know how you go through a CD's tracks... well you use the arrow
(l & r) to go through 32 MOD files...
Since I have about 55 MOD files right now... I split the files into 2 
directories and have a copy of CDPLAYER.PRG in each directory...
(I have 2 depictions (icons) on my NEODesk)...

Ability to cycle through the 32 files.

It plays songs a lit'l slow but it's nice...

Its at ftp terminator.cc.umich.edu (aka atari.archive.umich.edu) under:
cd atari/sound/players
bin
get CDPLAYER.(was it .ZOO or .LZH?)...

Anyway, check it out... it may suit ya!

Others:

	Jukebox player v1.2 (ste/nice lit'l player (lotsa choices/no graphics)

	NoizeTracker (mono/demo/quicker in playing songs)

HEY BRIAN T, I'll send ya a copy to your bbs!!!!!!!!!


     __________                   _______ 
    / ________()  Kaho Chan(man) /      /
   / /\______    University of  /*     /
  / /_/_____()  Nevada, Reno    \     /
 /_________    Internet:         \   /
 L________()  chan@cs.unr.edu     \/^
From: baffoni@aludra.usc.edu (Juxtaposer)
Newsgroups: comp.sys.atari.st
Subject: Re: Falcon Graphics
Date: 7 Sep 1992 21:14:29 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

In article <10174@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:
>and I was editting a program, then accessed a disk from a friend.  He took
>the disk away, then a little later the machine INSISTED that I insert that
>disk.  The only escape was rebooting - losing all my program.  The Mac gets
>very fascist when it comes to floppy disks.

	This is what I used to think before a mac-guru friend of mine showed
me a trick:  If you press command-"." (command is the clover-key) when it
asks for a disk, it stops asking for it.

	Of course it would've been nice if they put that kind of info in the
request-for-disk dialogue.   (You know, insert foobar disk, or press 
command-".")

>Warwick
>--
>  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
> /     * <-- Computer Science Department,  /  
> \_.-._/     University of Queensland,    /      void (if removed)
>      v      Brisbane, Australia.        /  

-Mike
From: joeadato@tcpbbs.pcn.org (Joseph Adato)
Newsgroups: comp.sys.atari.st
Subject: Re: FTP Sites?
Date: Thu, 10 Sep 92 23:00:10 EDT
Organization: TCP BBS, Cleveland, Ohio

> By and large, all IBM emulators for the Atari run relatively slowly since
> the 680x0 processor must do all the 80x86 translations.  That's a lot of
> work, indeed.  About the best speed you could hope for is that of an 8MHz
> 80286 AT class machine.  Of course, a faster Atari will help but with the

Not so!!! AT-Speed C16 (an internal IBM emulator) is running inside my
MegaST 4 at 12.9 Mhz.  There are speed test one can run to find oute
exactly how fact their system is running.  There is also a 386
emulator available for the ST.  Since AT-Speed C16 is a 286 emulator I
would expect the 386 emulator (also made by the people who make AT-Speed)
runs even faster.
Newsgroups: comp.sys.atari.st
From: saj@chinet.chi.il.us (Stephen Jacobs)
Subject: Re: Buying a Falcon (was: Falcon Graphics)
Summary: My usual request for store sightings
Keywords: Falcon retail
Organization: Chinet - Public Access UNIX
Date: Tue, 8 Sep 1992 17:24:30 GMT

Will anyone who sees a Falcon offered for sale (and in stock--mail order
deals of the we'll take your money now and send it when we can type don't
count) please let us know.  This should be happening in Germany right about
now, if what Mr Sam said on Genie was accurate.
                                          Steve    saj@chinet.chi.il.us
From: clint@artech.UUCP (Clinton Keith)
Newsgroups: comp.sys.atari.st
Subject: 1.44 Floppy problem
Keywords: 1.44,floppy,TT
Date: 13 Sep 92 21:16:39 GMT
Organization: Applied Remote Tech., San Diego


   I just installed TOS 3.06, the AJAX controller and a 1.44 (Epson) 
floppy drive in my TT.  Dip switch 7 in on.  It works fine by itself 
on the TT, but when I take a TT FORMATTED HD floppy over to a PC, the
PC has problems with the files stored on the disk (bad crc's on ARC files
etc), but not the FAT.  If the HD floppy is formated on the PC, both can 
read it fine.

   Any ideas about what the problem is.  I believe it's either an Ajax or
drive problem.  Any similar experiences?


-- 
Clinton N. Keith                       ... Speaking for himself.
Applied Remote Tecnology               
crash!hp-sdd!artech!clint              
artech!clint@hp-sdd.sdd.hp.com
From: jornmoe@fredrik.atari.no (Joern Moe)
Newsgroups: comp.sys.atari.st
Organization: Atari Corp. Scand. AB (Norway)
Subject: Re: More TT030 help...
	<1992Sep07.102416.24050@bas-a.bcc.ac.uk>
	<H.dKKAgDnyXzY@fredrik.atari.no>
Reply-To: jornmoe@fredrik.atari.no
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Thu, 10 Sep 1992 18:51:38 MET

In <H.dKKAgDnyXzY@fredrik.atari.no>, Joern Moe writes:

>I didn't specify it, but yes, it seems to run in TT-Ram. But, and it is a big 
>BUT, most dialogs that need keyboard input will not be accessable and/or make
>Calamus crash. I've sometimes loaded Calmus to TT-ram on a 6 MB TT to be able
>to print on the Atari lasers (SLMxxx), but it is virtually impossible to do
>real woork in Calamus when loaded into TT-ram!
>
Oh, I just realized I goofed it here... I know that going for TT ram makes it
impossible for the dma (acsi) hardware to accsess the page-immage that Calmus 
build up to send to the laserprinter. 
But setting Calmus  to load to TT ram, and malloc from ST RAM fixes that 
problem!
-- 
  _______________________________________________________
 / Joern F. Moe /  All above is my own personal opinion! \
/ Oslo, Norway /  Any lack of opinion above is also mine! \
-----------------------------------------------------------