Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 006
INFO-ATARI16 Digest Wed, 3 Jan 90 Volume 90 : Issue 6
Today's Topics:
EZ Score Plus file formats
Genlock inquiry
LHARC takes over? Sure hope not!
Need help w/5 1/4" drive
New Picture Formats List
Omikron-Compiler instructions ??
STEs
Turtle 3.0's archive option
----------------------------------------------------------------------
Date: 3 Jan 90 17:31:14 GMT
From: ncrlnk!ncrcam!system!mike@uunet.uu.net (mike reiss)
Subject: EZ Score Plus file formats
Message-ID: <559@system.Cambridge.NCR.COM>
I sure hope someone out there can help me with this one, I have no idea.
For Christmas my son got EZ Score Plus. He says it uses SCO(?) format.
At high school he uses another midi program for a Music Theory course.
He would like to be able to move files back and forth between these two
programs. He would like a program to convert files between the EZ Score
format and MIDI Standard (which the PC program can use). Does anyone
have a program like this? If all else fails, does anyone know what these
formats are? We can write the programs.
thanks from both of us,
mike and joe
------------------------------
Date: 2 Jan 90 15:13:06 GMT
From: ccavax!lmrc!hassinger@uunet.uu.net
Subject: Genlock inquiry
Message-ID: <3228@lmrc.uucp>
In article <678@alias.UUCP>, rhardock@alias.UUCP (Ron Hardock) writes:
> I am interested in trying out some desktop video on
> either an Amiga, or an Atari TT (or an Atari ATW).
...
> Secondly, it would also be nice if such a system could
> mix two video signals (from two VCR's) into one.
> The computer could perhaps control how the mixing is done.
I think in general you are going to find this one is hard, assuming you mean
mixing the signals as opposed to grabbing a frame. The outputs of the two VCRs
need to be synchronized before they can be combined the same way the Amiga has
to be synchronized with an external video signal before its output can be
combined with it (e.g. Genlock). The customary way to do this with two VCR
signals is with TBCs (Time Base Correctors) which still tend to be expensive
devices. The lower cost ones I have used also tend to require relatively
expensive VCRs that include the capability to accept an advanced sync signal
that is feed back from the TBC.
Logically it would seem that you should be able to get away with one TBC to
sync one VCR with another one that was free running but generally you find that
in practice both VCRs have to be equipped with TBCs. This setup is often
referred to as "A B Roll" in editing systems.
> I am also unsure of what computer platform to choose.
> Beside the Amiga, other choices I can see are:
> - Atari STE/TT (provides a color palette of 4096),
> - Atari ATW (provides 16 million simultaneous colors),
> - Mac II (provides 16 million simultaneous colors).
Can't comment on Atari. I think doing video from a Mac II is going to be
expensive 1) because the Mac with 16 million color capability is itself
expensive when compared to the Amiga, and 2) I believe the output from the Mac
is not at standard NTSC video rates so it is incompatible for video production
work and requires addition equipment to convert to suitable signals.
The Amiga on the other hand was designed from the ground up to produce NTSC
standard video. It also has a built-in capability to synchronize to an
external signal, thus making genlocks much easier and cheaper to build. Yes,
there are limits on what the Amiga can do in terms of number of colors and so
on, but nothing can come within a mile of it in terms of *cost effectiveness*
in video production applications, and its price/performance point is at a
*very* useful level of functionality for what a great many of us want to do.
It is not suitable for broadcast network production, but it costs a few percent
of what the networks do use.
It depends on how much you want to spend. The Amiga is cheap enough compared
to the alternatives that you can buy it, get your feet wet, and then if you
really want to spend the big bucks later your Amiga investment will only be a
drop in the bucket. And it will still be useful for a dozen other
applications.
------------------------------
Date: 3 Jan 90 16:33:33 GMT
From:
zaphod.mps.ohio-state.edu!uwm.edu!mrsvr.UUCP!jupiter.uucp!krieg@tut.cis.ohio-st
ate.edu (Andrew Krieg)
Subject: LHARC takes over? Sure hope not!
Message-ID: <1788@mrsvr.UUCP>
In article <1860@laura.UUCP> klute@heike.informatik.uni-dortmund.de (Rainer
Klute) writes:
>And another reason to use ZOO or ARC: There is ARCGSH
>available, a program that lets you work with ZOO, ARC and other
>programs from a GEM environment. Check the archives at
>panarthea or terminator and get version 2.1! (Older versions do
>not support ZOO.)
I am quite happy with LHARC. I had 36 back-up disks that were using Arc. I
rebacked them up using LHARC and only needed 24 disks. Clayton Walnum's
Arcshell supports LHARC, although it is quite easy to use by itself (It gives
you a full screen of help information). Sure it's slow right now, but that's
because it was written in GFA Basic. As soon as someone ports it to C or
Assembly, it should be a lot faster.
My only gripe with it is that it creates a timestamp of when you are
performing the archive, and assigns it to the arc file. Arc would always
assign the timestamp of the latest file touched in the archive. I like that
better, since I can tell how old sources are. It's a nit, but I hope they
fix it in later versions.
--
=========================================================================
= Andrew Krieg The Marvel Historian =
= G.E. Medical Systems - CT - New Berlin, WI =
= USENET: krieg@jupiter.med.ge.com =
=========================================================================
= "Maybe Christmas," he thought, "doesn't come from store." =
= "Maybe Christmas...perhaps...means a little bit more!" - The Grinch =
=========================================================================
------------------------------
Date: 3 Jan 90 18:15:26 GMT
From: shlump.nac.dec.com!engage.enet.dec.com!oldtmr!wallace@decwrl.dec.com (Ray
Wallace)
Subject: Need help w/5 1/4" drive
Message-ID: <1407@engage.enet.dec.com>
In article <1732@cod.NOSC.MIL>, jensen@cod.NOSC.MIL (Layne K. Jensen) writes...
>I have been trying to install a 5 1/4" floppy drive on my 1040ST. I think
....
>able to read existing files written on other machines, but does not reliably
>write or format a disk.
You need to slow down the seek rate for the 5 1/4" drive in order for it to
work properly. There are a few programs available for doing this, try looking
in the panarthea archives. I beleive DCformat can do this as well as SCHIZO.
---
Ray Wallace
(INTERNET,UUCP) wallace@oldtmr.enet.dec.com
(UUCP) ...!decwrl!oldtmr.enet!wallace
(INTERNET) wallace%oldtmr.enet@decwrl.dec.com
---
------------------------------
Date: 3 Jan 90 18:34:42 GMT
From: sdcc6!sdcc10!cs161fca@ucsd.edu ( )
Subject: New Picture Formats List
Message-ID: <5876@sdcc6.ucsd.edu>
Well, this list has everything except GEM metafiles. Can someone
post the format of .GEM files as well?
------------------------------
Date: Wed, 3 Jan 90 18:01:10 GMT
From: a_kowald%NIMR.MRC.AC.UK@Forsythe.Stanford.EDU (Axel Kowald)
Subject: Omikron-Compiler instructions ??
Message-ID: <9001031801.AA23113@nimsn41.>
Hello everybody !
I started to work with Omikron Basic for the AtariST and recognized that my
compiled programs need the file 'BASLIB' which obviously contains library
routines and which will be loaded by the compiled program.
I am now pretty sure that there is a way to tell the compiler to produce a
program which contains already this library routines, but I have no idea how.
I will be very thankful for any suggestions.
Axel
Thanks,
____________________________________________________________________________
Axel Kowald JANET: a-kowald@uk.ac.mrc.nimr
Div. Mathematical Biology UUCP:
Nat. Inst. Medical Research DARPA: a-kowald%mrc.nimr@nss.cs.ucl.ac.uk
The Ridgeway
Mill Hill
LONDON NW7 1AA Tel: (+44) 01-959 3666
U.K. ext. 2396
____________________________________________________________________________
------------------------------
Date: 3 Jan 90 18:33:31 GMT
From: mcsun!sunic!lth.se!newsuser@uunet.uu.net (Ralph Haglund)
Subject: STEs
Message-ID: <1990Jan3.183331.17370@lth.se>
As I quickly got "famous" for revealing secrets about ataris (nope, still
got no secrets from Atari, and no excuse from Alan Pratt) here's some new
ones:
In the STE there are four SIMM sockets. So what to be found there? Well:
Looking at the photos in ST World, Nov. '89 (an English magazine) all
four slots are full, on each card there are 8 Korean 100ns chips,
marked KM41C1000A3-10, thus one megabit chips.
I recently opened up one 1040STE and one 520STE, and found in the 1040STE:
4 cards, two 256 kx4 chips on each
In the 520STE
2 cards, 8 256kx1 chips on each.
This means the 520 must be easier to upgrade, right. And it is MUCH cheaper...
Then, as noone asked me to go on refereeing the German magazines I won't,
but I can comment that in one of the January issues they told about 6 patches
to do in the TOS 1.4 chips. This includes the software patches you put in the
AUTO folder. Also something about the MEGA clock chip, to read the boot device
nd a couple of things besides.
Oh yeah, they also told how you simply could use 1.44Mb drives etc.
------------------------------
Date: 3 Jan 90 14:37:48 GMT
From: usc!srhqla!quad1!ttidca!woodside@ucsd.edu (George Woodside)
Subject: Turtle 3.0's archive option
Message-ID: <8811@ttidca.TTI.COM>
In article <891227.19144827.002918@SFA.CP6> Z4648252@SFAUSTIN.BITNET (Z4648252)
writes:
> I have TOS 1.4 and was hoping that the setting of the bit would
>allow me to use the archive option to back up only the files that have been
>added to or modified since my last backup.
Your problem is simple: timing.
I haven't had time to do a new version yet.
TOS 1.4 reverses the significance of the Archive bit from the prior
TOS versions. Turtle has to be modified to deal with the Archive bit
properly, for whatever version of TOS you are running. It will be as
soon as I get past a few other, higher priority items.
Meanwhile, there is a more frequently occurring problem dealing with
directory create failures in the RAMdisk, which I've been trying to
re-create. When I can get that to occur reliably, I can deal with
it and the archive bit.
Both problems, however, take a back seat to the current work on the
Virus Killer. Which, in turn, is slightly behind an even more critical
hard disk failure problem.
If anyone has a few 300 day weeks they can spare, I could use them. :~).
Working for a living sure cuts into my day.
--
*George R. Woodside - Citicorp/TTI - Santa Monica, CA
*Path: ..!?philabs|csun|psivax?!ttidca!woodside
------------------------------
End of INFO-ATARI16 Digest V90 Issue #6
***************************************
