I'm making backup disk images for my Atari 800. I was wondering if
anyone has the equivlent of Fast Hack Em for the Atari? Also dose
anyone know of a drive emulator for the Apple II?
Charles
On Wed, 25 Nov 1998 Sam Ismail wrote:
>In my experience, sound files do not compress well at all with PKZIP. I
>don't know about WAV files in particular, but I'm lucky if I can squeeze
>10% off the ADPCM files that I work with.
Are you talking about digitised computer tapes or music? I have some digitised
(VOC format) files of ZX Spectrum game tapes. For example, Altered Beast. Not
sure at what rate this was sampled, but:
uncompressed file size = 12,725,061 bytes
compressed file size = 504,546 bytes
Which is a pretty good compression ratio. That is using the lharc archiver; I
imagine zip would give similar or better compression.
There are lossless compression systems designed for audio, but I bet they
weren't designed with computer tapes in mind.
On Wed, 25 Nov 1998 Allison J Parent wrote:
>FYI, protable casette recorders 3db point is 11-14KHz for the better ones
>and they typical ones used 9.5-12.5KHz is more realistic.
>
>Sampling above 20Khz is wasting bandwidth and recording time.
>
>Even the fastest audio formats (sudding and TARBEL187bytes/sec) had
>bandwidths below 5KHz.
Many game tapes for e.g. ZX Spectrum, Commodore 64 used turbo loaders. Not sure
what the highest data rate was, though at least some C64 programs loaded at
3000 baud.
3db point may not be completely relevant; at least for the old ZX Spectrum, you
had to hook up the tape player with volume set at or near the maximum.
For systems which (notionally) record a bilevel signal -- this may include
almost all of them -- it may be that sampling at a very high rate and then
doing some kind of post-processing of the sample to reduce it to 1-bit
resolution would be beneficial; the result could be closer to the original
signal output from the computer when the master tape was created.
On Wed, 25 Nov 1998 Marvin wrote:
>Someone mentioned that there are copy protection schemes for cassette tape,
>and I was curious what these might be and how they might interfere with
>recording the tape onto my HD.
Sure. Tape copy-protection was used by almost all commerical (game) software.
This involved some devious tricks, as well as turbo-loading routines. It was
designed to prevent people from copying games by reading into the computer and
saving out again. It shouldn't have any bearing on sampling the tapes at all.
Some techniques used were auto-run loaders, fast loaders and custom formats in
general, greater-than-RAM-size blocks of data.
-- Mark
It was the ST-1150R. It is an RLL rated version of the ST-1100. These
drives
are both scarce because they were high-capacity ST-506 3.5" drives.
Maxtor
made plenty of 5.25 full height MFM 80+ MB drives, but the Seagate
ST-1100/1150R
was the biggest ST-506 3.5" drive available (if anyone knows of a bigger
3.5",
ST-506 interface drive, I'd like to hear from you).
There are some applications where only such a small drive will fit; and
the use
of an IDE or SCSI drive is not possible, becuase the interfaces aren't
supported.
Jeff
On Wed, 25 Nov 1998 16:57:12 -0500 "PG Manney" <manney(a)lrbcg.com> writes:
>>One was an Everex with a mondo-scarce RLL drive. . .
>
>
>Which one? RLL's aren't _all_ that scarce.
>
>manney
>
>
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
< All that having the wrong azimuth would do is reduce the HF response.
Correction: Having the wrong azimuth would do is reduce the already
terrible HF response.
Also if the motor speed is off that will add to the grief (don't assume it
is!). used to work on portable casettes and 2% error was common and some
were 5%+ wow and flutter from bad casette cases/
< There's no way to tell an original played back on a machine with the
< heads at a different azimuth setting to the recording machine and a copy
< of that recorded and played back on the same tape deck AFAIK. No cassett
< recorder had software-controllable azimuth.
Most all have a trap door for a screw driver. the adjustment compensates
for head wear, mecanical error in the guides, sloppy transport. one set
if the transport is any good it need not be touched. Most portables
of the era were terrible.
Allison
< Many game tapes for e.g. ZX Spectrum, Commodore 64 used turbo loaders. N
< what the highest data rate was, though at least some C64 programs loaded
< 3000 baud.
300 cps, maybe. Sill the bandwidth had to be under 7-9khs as the group
delays in portable cassettes are terrible as you near their upper 3db
point. Still that is only twice the Tarbel data rate.
< 3db point may not be completely relevant; at least for the old ZX Spectr
< had to hook up the tape player with volume set at or near the maximum.
It is relevant as that is the result of the head gap and media
limitations. Most portables a tone at 15khz was usually at least 20db
down if not worse. The HF falloff for casette is poor and portables
of the era terrible!! Most the amplifier chain was easily good for more
than that! A fair number the bias osc for recording was only 35khz so
anything over 17khz would alias till the cows came home but the head
never saw it nor the media as it couldn't do it.
The bulk of audio casettes were on the 30 cps range using 300baud systems
or the later ones used 150-190cps using phase encoding like tarbel, trs80
or cosmac(lots of others too). Most all were most sensitive to:
*Dropouts. short periods of far lower level (or none!).
*Speed variations due to transport not being able to hold
or not being on speed.
*Group delays (phase shifts) from trying to put HF (above 5-6khz)
through the electronics, heads and media.
Compared to CDrom the bandwidth, speed and noise are TERRIBLE and barely
approximate 1/4 the cdrom capability.
Allison
< I don't suppose anyone has any schematics for a "I-can-build-this-front
< panel-computer-out
< of-nothing-but-Radio
< Shack-and-Jameco-parts-sit-it-on-a-shelf-and-say-look-at-that-wow"
< project, now do you? Just something to play around with, that's all.
Like I said last night, Bursky's book _The S100 bus Handbook_ has the
IMSAI and altair front pannels.
There's not a lot of majik but lots of connections and a good handful of
basic TTL.
Allison
>Next: Does anyone know if the M7454 module (Unibus TU80 controller)
>is Unibus only, or can it also be used on QBus systems?
Plug it into a Q-bus backplane, and you'll let the magic smoke out!
If you want a Q-bus tape controller, look for a Emulex TC02/03,
QT13, Dilog DQ132/152, or the like.
Tim.
Hi guys,
Anyone have specs/instructions for these?
I have rescued one I would like to use on my VMS 6.0 box.
It appears to be intact, powers up and prints a self test,
(seems very fast by dot matrix standards) but it's
filthy as hell, I'm trying to clean it up at the moment.
It came from a lead smelter - and looks like it.
But I have no specs, don't even know if it needs a straight cable,
handshaking or
null modem, default baud rate etc.
A list of the dip switch settings or a pointer to some online docs would
be terrific.
Cheers
Geoff Roberts
Computer Systems Manager
Saint Marks College
Port Pirie South Australia.
My ICQ# is 1970476
Ph. 61-411-623-978 (Mobile)
61-8-8633-0619 (Home)
61-8-8633-8834 (Work-Direct)
61-8-8633-0104 (Fax)
I don't suppose anyone has any schematics for a "I-can-build-this-front
panel-computer-out
of-nothing-but-Radio
Shack-and-Jameco-parts-sit-it-on-a-shelf-and-say-look-at-that-wow"
project, now do you? Just something to play around with, that's all.
I'd appreciate any info,
Thanks!
Les
