Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 153
Info-Atari16 Digest Tue, 19 Mar 91 Volume 91 : Issue 153
Today's Topics:
40 folder problem
CAD 3-D fonts
DSKCHR33.LZH
Looking for Logo for ST
lynx (2 msgs)
Midi file format (Used by several midi programs). (2 msgs)
New standards for MiNT programs? (2 msgs)
oops
Printer redirection (again?)
Setting Floppy Seek Rate in all TOS versions
Welcome to the Info-Atari16 Digest. The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out. Please send notifications about broken digests or bogus messages
to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list
instead of the moderators are likely to be lost or ignored.
If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------
Date: 19 Mar 91 12:02:03 GMT
From:
arizona.edu!cerritos.edu!nic.csu.net!usc!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!
shamash!timbuk!uktriton.cray.com!fields@arizona.edu (Mike Fields)
Subject: 40 folder problem
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
Does anybody know whether the famous '40 folder problem' is fixed in later
version of TOS ??
I have a 4Meg STe with a 40M FA.ST Hard drive, with about 100 folders.
Occasionally
files get corrupted, different files get into the middle of files..It
looks very much
like the problems when, with my 1040, I encountered the 40 folder
problem.
I have tried with foldr150.prg but that didn't seem to change anything,
but it could
be because the problem has already happened and until I ZERO the
partition it
will continue regardless.
Anybody any ideas ??
Thanks
Mike Fields
fields@uk.cray.com
------------------------------
Date: 18 Mar 91 07:58:48 GMT
From:
arizona.edu!cerritos.edu!nic.csu.net!usc!rpi!uupsi!cci632!ritcsh!ultb!drp9500@a
rizona.edu (D.R. Paradis )
Subject: CAD 3-D fonts
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
I need help!!!!!!!!
I am using my ST and CAD-3D to generated an animation that is for a
school project. The animation NEEDS to have animated text!
I do not have Cyberpaint, and I cannot do this in DEGAS...it MUST be
in 3D!!
I have scanned the ENTIRE GeNIE libraries and just about every FTP
site I can find to get ahold of a font for CAD-3D.
If ANYONE of you have a font, or know of where I can get one PLEASE
let me know!!!!
I tried making one and it looked like shit....
Again, this is for a school animation project and I am running out of
time....please help....
Newsgroups: rec.arts.movies
Subject: Re: A good reason to avoid Blockbuster
Summary:
Expires:
References: <1991Mar12.032023.20999@pixar.uucp> <6407@oasys.dt.navy.mil>
Sender:
Followup-To:
Distribution:
Organization: Rochester Institute of Technology
Keywords:
The reason that I hate them is thus....
I work at a video store during the summer called Movies Unlimited.
They are a 5 store chain based in Philadelphia. While I was working
there (before I started college) word got out that Blockbuster was
coming to the Philly area, but we didn't know where. We found out.
Right across the street!
They opened Christmas day!
[flaws begin]
They (blockbuster) say they have over 10,000 movies.......
reality- if they have 50 copies of BTTF3 then that is 50 movies,
etc...
M.U.: (the store I worked at) carries aprox. 19,000 TITLES!!!
(if we have 20 copies of a movie it counts as ONE TITLE!!)
( the catalog has over 23,000 TITLES!! see pg 127 of April
Premiere mag)
The staff at BB doesn't know sh*t about movies!!!
I asked them for movies that I KNOW were available and that M.U.
carried, they (BB) were clueless!!
(we did spying on them to see what danger we were in....NONE!)
When BB first came in, we did see a drop in new members. About a month
later we saw an INCREASE in new members. BB does mass mailings to
canvas the neighbourhood. People would come to see BB and then notice
across the street and see us and come in and join.
MU runs it like this....
membership is $19.95
you get...
4 free 2 night rentals
free catalogs (reg & adult)
rental freebie card (stamped for each title paid for
reguardless of when returned)
10% discount on ALL purchases (blank tapes, vids or LDs)
a VERY movie-wise staff
and free popcorn
in other words...........
IT'S A REAL VIDEO STORE!!!!!
--
************************************************************************
* Just because I'm a film major | < Net-address > *
* doesn't mean I'm a Spielber-wanna-be....| *
* I'm a Lynch-wanna-be! | drp9500@ultb.isc.rit.edu *
------------------------------
Date: 19 Mar 91 04:31:08 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!jarthur!petunia!csuchico.edu!ekrimen@arizona.e
du (Ed Krimen)
Subject: DSKCHR33.LZH
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
Just sent DiskChart 3.3 to atari.archive. It has a few more useful features
than version 3.0. For example, when you click on the line of drives at
the bottom of the screen, it finds the free space on each drive.
--
Ed Krimen ...............................................
||| Video Production Major, California State University, Chico
||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661
/ | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
------------------------------
Date: 19 Mar 91 07:58:08 GMT
From:
arizona.edu!cerritos.edu!nic.csu.net!usc!sdd.hp.com!mips!cs.uoregon.edu!ogicse!
milton!blake.u.washington.edu!black@arizona.edu (Jim Black)
Subject: Looking for Logo for ST
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
I'm looking for a copy of Logo for the ST (520).
Unfortunately Atari apparently doesn't ship it anymore.
Can anyone help me track down any (Atari, 3rd-party-vendor, or public domain)
logo implementations for the ST? (Public domain with C source would be
the answer to a prayer, but any of the above would be great for now.)
Thanks for any help...
--
Jim Black (black@blake.u.washington.edu)
------------------------------
Date: 19 Mar 91 02:40:21 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!chaph.usc.edu!aludra.usc.edu!jjung@arizona.edu
(Robert Jung)
Subject: lynx
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
In article <269@eliza.edvvie.at> schweigl@edvvie.at (Johnny Schweigl/2113674)
writes:
>From article <7868@crash.cts.com>, by chuckie@pro-odyssey.cts.com (Chuck
Schul):
>> anyone know much on the atari lynx and how it is doing worldwide?
>
>Hmm. Nice thing, color, sound, could have been a success. If not Nintendo
>had thrown it's GameBoy into the market. No Color, a little less sound,
>but astonishingly small, much cheaper (that's what impresses the kids,
>i think)
No, Nintendo hype (reenforced with NINTENDO POWER magazine) influences the
kids. As for being more competitive, you can now buy a Lynx base package
for $99 here in the 'States (versus $89 for the Gameboy).
Portable game system market so far:
Nintendo Gameboy $89 B&W, 1-2 players
Atari Lynx $99/$149 Color, 1-8-??? players
Sega Game Gear $149 Color, 1-2 players
NEC TurboExpress $300+ Color, 1-2 players, accepts
TurboGraphix-16 games
I don't know nothin' about economics, but it looks like Atari can turn
this into a major rout and kick every other system out of the market. It
all depends on getting more games and good advertising, IMO.
--R.J.
B-)
//////////////////////////////////////|\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Send whatevers to jjung@nunki.usc.edu | If it has pixels, I'm for it.
--------------------------------------+----------------------------Lynx me up!
"If it moves, shoot it. If it doesn't move, shoot it anyway."
------------------------------
Date: 19 Mar 91 04:34:06 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!cs.utexas.edu!uwm.edu!psuvax1!psuvm!sml108@ari
zona.edu (Scott the Great)
Subject: lynx
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
In article <15926@chaph.usc.edu>, jjung@aludra.usc.edu (Robert Jung) says:
> No, Nintendo hype (reenforced with NINTENDO POWER magazine) influences the
>kids. As for being more competitive, you can now buy a Lynx base package
>for $99 here in the 'States (versus $89 for the Gameboy).
>
> Portable game system market so far:
>
> Nintendo Gameboy $89 B&W, 1-2 players
> Atari Lynx $99/$149 Color, 1-8-??? players
> Sega Game Gear $149 Color, 1-2 players
> NEC TurboExpress $300+ Color, 1-2 players, accepts
> TurboGraphix-16 games
>
> I don't know nothin' about economics, but it looks like Atari can turn
>this into a major rout and kick every other system out of the market. It
>all depends on getting more games and good advertising, IMO.
As usual, Atari has all the good games it needs for the thing. It's
an amazing toy, but they don't seem to care whether they sell any...
They've survived up to now on word of mouth, so why not continue
the trend? Who needs big sales anyways?
A pity, it would otherwise be worth developing games for it...
At least the Portfolio is doing well..
I give up on the TT for now...
Scott Le Grand
------------------------------
Date: 19 Mar 91 02:35:43 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pi
tt!speedy.cs.pitt.edu!bogdan@arizona.edu (Bodgan Kosanovic)
Subject: Midi file format (Used by several midi programs).
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
In article <1482@ahds.UUCP> geert@ahds.UUCP (Geert W.T. Jonkheer CCS/TS) writes:
>...
>I am writing a midi program for the atari ST. As many other programs,
>I would like to use the standard Midi file format to store
>midi data on disk. However, I don't know what the terms on this
>format are. Where can I find information about the midi file format?
>... etc.
Thank you on asking that question. I have started a year ago interesting
project (see below), not supported from any institution (as in majority of
computer music projects), which led me to the similar questions.
Problem of STANDARDS in Computer Music. MIDI standard is not enough.
Every day we can see hundreds of new "Music" products whose only purpose
is to take your money out of your pocket. Manufacturers are not thinking
of standards, they need FAST production and large profit.
I don't think that there exists a Standard MIDI File Format. It is also
important to define what kinds of information you would like to see
in such file (multitrack recording of MIDI events, MIDI dump of patch
parameters, music scores of composition, live performance protocol file,
etc., etc.)
As far as I know MIDI Sample Dump Standard is THE only standard which can
be related to 'files' (although it doesn't imply usage of files). It is
more like MIDI Sample Dump Packet Protocol Description.
If you thought of MIDI events recording, and file containing such
informations, I'm afraid that widely accpeted standard DOES NOT exist.
>The information i would like to get is:
>
>1) Are the parameters in the standard midi file machine independant.
> Can all parameters be used on every midi instrument?
>
They should be ! Particular music device drivers should hide all
characteristics of particular instrument. (Layered approach).
Some MIDI instruments, however, are less powerful, so one cannot
expect of all instruments to respond to all possible events.
(Such events should be skipped or mapped into others when possible).
>2) How are the parameters orded in the midi file.
>
Again, I am not sure what 'parameters' are you talking about ?
If you think of MIDI composer/recorder, some hierarchy in file
definition should be higly welcomed, as well as modularity, in
order to minimize duplicate information (repetition of events or
bars or groups of bars).
If you think of patch dump files. Ordering doesn't matter.
>3) Can machine dependant data (for example midi exclusive data) also be
> stored in the midi file, or must i use my own format to store these
> data.
>
This was a project I've mentioned above. I've started writing a
tool which could provide MIDI programmers with a possibility of
producing MIDI applications capable of controlling ANY type of
MIDI device by using Object Oriented definition of Exclusive Data.
To simplify, my Universal Device Driver Code Generator should produce
driver code in plain C language if given simple ASCII file containing
definition of any MIDI instrument. Once you have your application
working with one relatively complex instrument you can be positive
that it should work WITHOUT change with ANY other instrument.
The only thing you should do after purchasing NEW instrument would
be to enter your favorite editor and type in the definition of
your NEW instrument's system exclusives using META language designed
for such operations.
Actual application would use STANDARD library calls like in GKS,
GEM or similar graphic standard libraries (open_virtual_workstation,
send (handle, data), receive(handle, data), ... where handle is
music device ID opened at the beginning of application (or later)).
The answer on your question is YES, but again I am not sure that
there exists a standard (world wide). Unfortunately, I didn't
complete my project, because nobody wanted to pay me, and on the
other side people who are paying me expect from me to do other
things. (I completed parser for META language, and started
code generation, I also defined "standard" formats, all known
exclusive messages should fit in, and I also started to think of
mechanism which could provide you to include in definition file
even new system exclusive message formats which are likely to
appear in the future).
I would like one day to see this or similar system working and
to see happy faces of all music people after purchasing new
instrument and configuring it after just a couple of minutes.
Why should we purchase new device drivers from the manufacturers
when we could define new one in 10 minutes !!!
>4) Many midi music programs are using the standard control commands
> for manipulating the music (such as bender, hold etc.)
> I have not seen a program use control commands that are
> particularly for a midi instrument (such as sound effectors which
> are not descriped in the midi standard).
> Programs must use the standard control commands and the
> 'user defined' control commands for manipulating music
> (i think) to get the most flexibility.
> Is there a program on the market that uses this concept?
>
I hope one day we shall be able to purchase Real-Time Music
Workstation capable of Music/Sound/Image processing. I hope
it will cost less than 2000$ US dollars and will fit size of
my desk. Some simple sound processing control can be implemented
and IS implemented on some Digital Sound Processors. It is often
just simple preset/effect change which is useless in 99% percent
of real life situations. What I would like to see (as well as you)
is real time change in reverberation or delay characteristics
possibly controlled from the external source (joystick or similar
controller). In a year or two Digital Signal Processing technology
will be capable (I hope) of doing such things in real time and for
less than 2000$ dollars.
The problem is when the manufacturers are going to lower their
extremely high prices. (Why some manufacturers of sampling keyboards
are selling hard disk drives (40MB, extremely slow) for 900$ (!!!)
when such drive can be purchased for as low as 200-300$ ?)
I would also like to easily control tempo changes, dynamics,
timbral characteristics (all in real-time and possibly from the
external sources). AND I WOULD LIKE TO SEE A SOFTWARE PRODUCT WITH
ALL THESE CAPABILITIES WHICH I CAN UNDERSTAND IN ONE DAY, WITHOUT
PAIN of READING 100s of MANUAL PAGES WRITTEN WITH THE ONLY PURPOSE
OF justifying WRONG DECISSIONS THEY MADE DURING DESIGN & IMPLEMENTA-
TION.
That would be all for know. Please forgive me on length of a text.
Bogdan R. Kosanovic
4705 Fifth Ave, Apt 1-L
Pittsburgh, PA 15213
U.S.A.
(412)-681-2019
E-Mail: bogdan@neuronet.pitt.edu (please use this address)
------------------------------
Date: 19 Mar 91 04:44:17 GMT
From: stanford.edu!neon.Stanford.EDU!dalgic@decwrl.dec.com (Ismail Dalgic)
Subject: Midi file format (Used by several midi programs).
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
In article <10189@pitt.UUCP> bogdan@neuronet.pitt.edu (Bogdan Kosanovic) writes:
>In article <1482@ahds.UUCP> geert@ahds.UUCP (Geert W.T. Jonkheer CCS/TS)
writes:
>>...
>>I am writing a midi program for the atari ST. As many other programs,
>>I would like to use the standard Midi file format to store
>>midi data on disk. However, I don't know what the terms on this
>>format are. Where can I find information about the midi file format?
>>... etc.
>
>Thank you on asking that question. I have started a year ago interesting
>project (see below), not supported from any institution (as in majority of
>computer music projects), which led me to the similar questions.
>
>Problem of STANDARDS in Computer Music. MIDI standard is not enough.
>Every day we can see hundreds of new "Music" products whose only purpose
>is to take your money out of your pocket. Manufacturers are not thinking
>of standards, they need FAST production and large profit.
>
>I don't think that there exists a Standard MIDI File Format. It is also
>important to define what kinds of information you would like to see
>in such file (multitrack recording of MIDI events, MIDI dump of patch
>parameters, music scores of composition, live performance protocol file,
>etc., etc.)
>
>As far as I know MIDI Sample Dump Standard is THE only standard which can
>be related to 'files' (although it doesn't imply usage of files). It is
>more like MIDI Sample Dump Packet Protocol Description.
>
>If you thought of MIDI events recording, and file containing such
>informations, I'm afraid that widely accpeted standard DOES NOT exist.
I'm afraid that what you are saying is wrong. A MIDI file format for
storing the MIDI event sequences DOES exist, and it is currently being
used by many commercial programs. You can get its specs via anonymous
ftp from ucsd.edu. Unfortunately the specs there are pre - version
1.0 (i.e., before it was approved by the MIDI Manufacturers'
Association), but I don't think there is a big difference. Also,
check your favorite MIDI BBS for utilities to convert between
the MFF files and several other commercial sequence formats such as
Cakewalk files.
--Ismail Dalgic
dalgic@neon.stanford.edu
------------------------------
Date: 19 Mar 91 20:03:19 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!brolga!bunyi
p.cc.uq.oz.au!qut.edu.au!lunnon@arizona.edu
Subject: New standards for MiNT programs?
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
In article <1991Mar18.140901.1919@doe.utoronto.ca>, david@doe.utoronto.ca (David
Megginson) writes:
>
> It's time for us to start designing programs and libraries which will
> run under future versions of MiNT which support bigger and better
> file systems. A good idea might be to include some dummy system calls
> which MiNT-aware programs can use to replace Fsfirst(), Fsnext() etc.
> The new system calls should work the same for now, but require a much
> larger buffer for the program name. That way, in the future when MiNT
> supports better file systems, MiNT programs will not have to be recompiled
> to be able to support names like Nethack.Source.tar.Z. If we just put
> all of the calls in place now, our work will be easier in a year or two.
>
> Comments? Perhaps we should write a spec sheet for what programs/libraries
> should do to be upwards compatible with future MiNT versions. This is
> something that we can do together on the net, and all Eric would have
> to do is approve it and include it in the distribution.
>
Huh, why not use dirent ??? This seems reasonably capable and is portable
to boot ???
>
> --
> ////////////////////////////////////////////////////////////////////////
> / David Megginson david@doe.utoronto.ca /
> / Centre for Medieval Studies meggin@vm.epas.utoronto.ca /
> ////////////////////////////////////////////////////////////////////////
------------------------------
Date: 19 Mar 91 10:51:39 GMT
From: noao!asuvax!ncar!elroy.jpl.nasa.gov!jato!hanauma!hyc@arizona.edu (Howard
Chu)
Subject: New standards for MiNT programs?
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
In article <1991Mar19.150319.25547@qut.edu.au> lunnon@qut.edu.au writes:
>Huh, why not use dirent ??? This seems reasonably capable and is portable
>to boot ???
I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and
use the Unix *dir routines instead. (This seems reasonable, given MiNT's
apparent intent to provide as much BSD functionality as possible...)
--
-- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
Disclaimer: How would I know, I just got here!
------------------------------
Date: 18 Mar 91 08:17:58 GMT
From:
arizona.edu!cerritos.edu!nic.csu.net!usc!rpi!uupsi!cci632!ritcsh!ultb!drp9500@a
rizona.edu (D.R. Paradis )
Subject: oops
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
oops...please ignore the part about Blockbuster Video.
I didn't realize that the article was not posted and got appended to
my dead.article file.
I still need help with the CAD 3-D fonts though....
--
************************************************************************
* Just because I'm a film major | < Net-address > *
* doesn't mean I'm a Spielber-wanna-be....| *
* I'm a Lynch-wanna-be! | drp9500@ultb.isc.rit.edu *
------------------------------
Date: 19 Mar 91 07:51:56 GMT
From: mcsun!hp4nl!rivm!rivm39!mtvfb@uunet.uu.net (Fokke de Boer)
Subject: Printer redirection (again?)
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
Hello netlanders,
Some time ago there was a thread on ** PRINTER REDIRECTION ** on c.s.a.st.
I didn't follow it back then, because I had no need for redirection.
But as always, nothing changes as much as the human mind :-) so now
I **AM** interested.
Sofar I have tried the program BARREL from atari.archive, but it doesn't
fill my needs. I have some programs capable of printing, but since I don't
have a fine printer I want to use the printer at work, but I don't want
to bring my ST every time.
These programs don't react to BARREL being resident: the print option is
still disabled. And printing from WordPerfect running under DOS (PC-Speed)
reports the printer being not ready.
So, what I need is a program that makes the Atari think a printer is
connected, although there isn't. Printer output should be redirected to
a file (and not to a buffer that has to be transferred manually to file).
Ideally, this program runs from the AUTO folder, and thereafter I "have
a software-printer" .
Any input appreciated, preferably by e-mail!
Fokke de Boer (mtvfb@rivm39.rivm.nl)
------------------------------
Date: 19 Mar 91 04:44:54 GMT
From: noao!ncar!elroy.jpl.nasa.gov!jato!vsnyder@arizona.edu (Van Snyder)
Subject: Setting Floppy Seek Rate in all TOS versions
To: Info-Atari16@NAUCSE.CSE.NAU.EDU
Here's the poop on setting the seek step rate for floppies, from page 60
of the Rainbow TOS distribution:
"Floprate: - Floprate, XBIOS function 41, checks or sets the seek
rate for a floppy drive. This is new; the seek rate
must be set with (previously) undocumented variables
on earlier versions of TOS.
Floprate example.
int devno, newrate;
oldrate = Floprate(devno,newrate);
This returns the current seek rate if newrate is -1,
otherwise sets the seek rate to newrate. For doing this
with previous versions of TOS, the seekrate byte
locations for drive A and B are:
OS Version Drive A Drive B
---------- ------- -------
0x0100 $A09 $A0D
0x0102 $A4F $A53
In either case valid seek rate byte values are:
Value Rate
----- ----
00 6 ms
01 12 ms
02 2 ms
03 3 ms
This call does not range check the drive ID or new seek
rate. If devno is zero, it assumes drive A:, if
nonzero, drive B:." That's 41 decimal.
You can get the TOS version from offset 02.w from the place pointed at
by 0x4F2.L (_sysbase).
--
vsnyder@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsnyder@jato.uucp
------------------------------
End of Info-Atari16 Digest
******************************
