(O.K., the denizens of "comp.sys.acorn.misc" could be Archimedes
enthusiasts, but I'm presuming that there are a fair share of Beebers
there as well...)
For the past several years, Speccy enthusiasts using the emulator
"Z80" by Gerton Lunter have had the use of a neat little gadget to
interface the parallel port to a cassette deck for tape loading. (I
think this gadget has been adopted by other emus as well -- the gadget
may also work on other makes of computer, though I haven't heard about
this.)
Recently, it has been proposed on the Sinclair and Oric NGs that this
gadget also be adopted as the tape-loading method for the PC Oric emu,
Euphoric.
I hereby propose that it be adopted as the standard for *anyone*
writing or maintaining an emu for *any* 8-bit machine where transfer
of old tapes to snapshot (and back) is desired, so I've crossposted
this to all the relevant NGs I can think of. If I've missed any, feel
free to repost it.
Now, all we need is for someone to start supplying ready-built ones
again...
N.B. Due to the crap way in which nntp.freeserve.net (mal)functions,
I've had to set follow-ups. Remember to clear them before replying...
--
--------------------------------------------------
Regards, Robert the Eboreg
New? Read the FAQ: http://www.kendalls.demon.co.uk/cssfaq/
Got a binary file to post? Go to alt.binaries.emulators.misc
> For the past several years, Speccy enthusiasts using the emulator
> "Z80" by Gerton Lunter have had the use of a neat little gadget to
> interface the parallel port to a cassette deck for tape loading. (I
> think this gadget has been adopted by other emus as well -- the gadget
> may also work on other makes of computer, though I haven't heard about
> this.)
The Amiga ZXAM one is essentially the same thing, but connects to a
different port.
> Recently, it has been proposed on the Sinclair and Oric NGs that this
> gadget also be adopted as the tape-loading method for the PC Oric emu,
> Euphoric.
>
> I hereby propose that it be adopted as the standard for *anyone*
> writing or maintaining an emu for *any* 8-bit machine where transfer
> of old tapes to snapshot (and back) is desired, so I've crossposted
> this to all the relevant NGs I can think of.
I'd argue that using sound sampling hardware - if already available -
is probably better (or, at least, means that people don't need a new
interface if they already have something capable of converting sound
to data)
Chris
--
+-------------------------------------------+
| Unsatisfactory Software - "because it is" |
| http://www.unsatisfactory.freeserve.co.uk |
| Your Sinclair: A Celebration |
| http://www.bigfoot.com/~ysac |
+------------------------------ICQ:28784166-+
>It would be better to use the sound card, since these outnumber little
>parallel port gadgets by a hundred to one.
Speaking for the Atari 8-bit machines, I wrote a program in 'C'
back in 1997 to read Atari cassettes using a sound card on the PC.
The data is extracted and saved. You can send that data to
the Atari.
The Atari reads the cassette as a 600 baud serial device, so the
data can be sent over the PC's serial port to the Serial IO bus of the
Atari. Only a simple voltage level adapter is needed, as the ones
already in use for the disk drive emulators SIO2PC and APE.
>I think the TZX format is flexible enough to hold other computers'
>formats, have a look at the specs and see if it's suitable. It would
>be quite good to see a common tape format, it would mean the utilities
>for digitising and re-tapifying tapes, could be centralised and have
>much more time put into them, better sampling techniques, etc, so
>everything would be better.
Well, I did not know of this format or these utilities. I looked at
the format specification, and to me it looks very complicated.
Flexible yes, but also very very complicated.
>Can TZX have meta data put in it, so you can store what computer it's
>for and who sampled it etc? I know I could just go look it up but it
>needs bringing up anyway.
I think this is possible. But I do not know why anyone would want
this. Tapes for one system cannot be loaded on another system.
I think it is very confusing to store all sorts of tape files for
different machines in the same format. Like, I have a ton of
diskettes. Some are for the PC. Some for the Atari ST. Some for the
Atari 8-bit machines. Some for macintosh. Some for Wang Classic,
some for Wang VS. And then some for emulator use. Sometimes it is
hard to tell what is what.
The same problem would arise with these emulated cassettes.
If searching for a tape file, you might get confused. The only
advantage is the one you mention, we can share knowledge
and technology, and thus improve the tools. I think we can
accomplish this easily if the developers get in touch with each other.
We do not need to bother the users with this, making life harder for
them.
>Do the current samplers just look for 0 transitions, or something?
>Maybe a bit of low and high-pass filtering could help clean up old
>tapes. etc etc, there must be loads of things to make sound card
>loading more reliable.
My conversion program counts the number of samples between a
high and a low value in the wave file. My program comes with the
documentation and 'C' source code. They only work for the Atari
8-bit, since that is the only system I know about. I have no
technical knowledge of other systems, and I really do not care
about them anyway. I hate tapes. That is why I wrote these
programs. But the signal processing is not too bad.
I did not want to sample in real time, because that adds complexity
to the program. Besides, I know nothing about reading from a
sound card. If you sample to a wave file, you can edit and try
to repair the wave file, if drop-outs and other stuff appear on the
tape.
Begin this year I also wrote a program to convert the data back
to audio, so the wave file can be recorded on a cassette tape
again after cleaning it up.
My programs do not look nice and flashy, but they seem to do
the job. Anyway, I have received very little feedback, which
makes me believe that on the Atari 8-bit machines, almost
everybody is using emulated disk images, not cassette stuff.
I think all stuff that was released for the Atari 8-bit was also
released on disk. It is much easier to get a disk version.
That is why emulators for the Atari do not support the
cassette unit. Nobody needs it. So no need to support
cassette emulation either.
My stuff can be used to recover programs that people
wrote themselves and saved to tape. Anyway, used or not,
my stuff is available free from the Umich archives, and can
also be found on my home-page. If you are interested in
cassette processing software, you can download the
programs, including the 'C' source code from
http://home.planet.nl/~ernest
I only read the comp.sys.atari.8bit news group, although
this is cross posted. Send me an E-mail if you have questions,
or reply in c.s.a.8
Keep those XL's/XE's humming,
Ernest.
> It would be better to use the sound card,
Sound card? Perhaps you should look at where this is crossposted...
--
| Darren Salt anti-UCE | nr. Ashington, | d youmustbejoking,demon,co,uk
| Spectrum +3, Risc PC, | Northumberland | s zap,uk,eu,org
| A3010, BBC Master 128 | Toon Army | @ retrospec,co,uk
| The second RISC OS version of JSW.
Then you must be Don Francisco's sister!
But we're talking about a hardware gadget which connects to the parallel
port on your PC (or whatever it connects to on the Miggy) anyway, so a
sound card *is* the equivalent device.
Phil
--
/ Philip Kendall (pa...@cam.ac.uk pa...@kendalls.demon.co.uk) \
| New? Read the FAQ: http://www.kendalls.demon.co.uk/cssfaq/ |
| The Threat to Spectrum Emulation: |
\ http://www.kendalls.demon.co.uk/pak21/spectrum/threat.html /
IMHO, it's not complicated. You never need to use most of the block
types -- most Speccy games can get by with using just one or two.
(I'll admit that the .tzx format is a bit of a mess in places eg the
fact that the early block types don't have length bytes :-( )
>>Can TZX have meta data put in it, so you can store what computer it's
>>for and who sampled it etc? I know I could just go look it up but it
>>needs bringing up anyway.
>
>I think this is possible. But I do not know why anyone would want
>this. Tapes for one system cannot be loaded on another system.
Yes, they can! It's normally a software problem, not a hardware problem.
There isn't the software built into most machines to allow you to do
this, but that doesn't mean it hasn't been written in the past.
Example 1: There are plenty of *Spectrum* programs which allow you to
load ZX81 tapes on a Spectrum; as there's no fundamental difference in
the hardware, all that is needed for someone to take an old Spectrum
program, run it on their emulator and then start up the ZX81 tape file.
If we were using different tape formats for every machine, this would
not be possible, as it would require rewriting the emulator (or
producing some external utility to do this), which a fair proportion of
emulator users may not be able to do.
Example 2: The Spectrum and Commodore 64 versions of Trivial Pursuit
used the same data format to load extra sets of questions.1
>I think it is very confusing to store all sorts of tape files for
>different machines in the same format. Like, I have a ton of
>diskettes. [...] Sometimes it is hard to tell what is what.
>The same problem would arise with these emulated cassettes.
To be honest, that's more of a organisational problem -- the biggest
Spectrum archive is now running at ~12000 programs, so there are already
some very efficient tools around for dealing with this sort of thing.
> In article <49438B888F%ne...@youmustbejoking.demon.com.uk>, Darren Salt
> <ne...@youmustbejoking.demon.com.uk> wrote
>> In message <37fb8bb7...@news.freeuk.net>
>> gree...@BOLLOCKSyahoo.co.uk wrote:
>>> It would be better to use the sound card,
>> Sound card? Perhaps you should look at where this is crossposted...
> But we're talking about a hardware gadget which connects to the parallel
> port
I'm well aware of that. I have one such device myself...
> on your PC (or whatever it connects to on the Miggy) anyway, so a sound
> card *is* the equivalent device.
Only if you happen to have a machine which needs one for anything other than
simple beeps and to which one can be fitted.
--
| Darren Salt anti-UCE | d youmustbejoking,demon,co,uk | nr. Ashington,
| Spectrum +3, Risc PC, | s zap,uk,eu,org ** anti-UBE | Northumberland
| A3010, BBC Master 128 | @ retrospec,co,uk | Toon Army
| Find a snapshot: <URL:http://drson.vse.cz/snapsearch/>
Apple: "I know! Let's call it the Raincoat."
: But we're talking about a hardware gadget which connects to the parallel
: port on your PC (or whatever it connects to on the Miggy) anyway, so a
: sound card *is* the equivalent device.
The sound input _is_ the simplest way and is easily implemented with
no seperate interface standards getting in the way. The idea that the
parallel port interfaces should be standardised is sound and in no way
creates a threat to sound device loading. It is entirely
complementary.
And a good idea.
--
NT As long as but a hundred of us remain alive, never will we on any
\ \/ /conditions be brought under English rule. It is in truth not for
\ / glory, nor riches, nor honours that we are fighting, but for
/ \ freedom -- for that alone, which no honest man gives up but with
/ /\ \life itself. -- Arbroath, 1320
: >It would be better to use the sound card, since these outnumber little
: >parallel port gadgets by a hundred to one.
The sound card is the best method, but as I state elsewhere, the
additional parallel port interface is an extra that provides further
flexibility and additional compatibilty. Using both methods makes
sense to me.
: >Can TZX have meta data put in it, so you can store what computer it's
: >for and who sampled it etc? I know I could just go look it up but it
: >needs bringing up anyway.
: I think this is possible. But I do not know why anyone would want
: this. Tapes for one system cannot be loaded on another system.
: I think it is very confusing to store all sorts of tape files for
: different machines in the same format. Like, I have a ton of
: diskettes. Some are for the PC. Some for the Atari ST. Some for the
: Atari 8-bit machines. Some for macintosh. Some for Wang Classic,
: some for Wang VS. And then some for emulator use. Sometimes it is
: hard to tell what is what.
: The same problem would arise with these emulated cassettes.
: If searching for a tape file, you might get confused. The only
: advantage is the one you mention, we can share knowledge
: and technology, and thus improve the tools. I think we can
: accomplish this easily if the developers get in touch with each other.
: We do not need to bother the users with this, making life harder for
: them.
Then I'd like to suggest a slight alteration to the implementation of
TZX files. Provide alternative filename extensions for different
machines. The actual encoding could be identical, but the extensions
would allow the user to distinguish between files for different
machines. Say:
TII for Apple II
T80 for ZX80
T81 for ZX81
TBC or TAC for BBC Micro/Acorn Electron
TAM or TPC for Amstrad CPC
etc
(It's a shame some OSes only support 3-letter extensions. It makes
this far too complicated. .T64, for example, already exists for a C64
tape archive.)
Then the emulator/archive program could have the 'files of which type'
options:
TZX for [computer being used] - that would show only files with the
relevant extension.
All TZX files - that would show all files with an
extension accepted by the TZX
standards body.
I believe in that case that it would be possible to have a similar system
for disk drives ?
A standard way of encoding disk datas, that would allow us to have
"writedisk" and
"readdisk" utilities that works for Atari ST, Oric, Spectrum, Apple, etc...
Mike
--------------------
http://www.defence-force.org
mi...@defence-force.org
--
Craig
E-mail:
Crai...@AmsTech.freeserve.co.uk
Crai...@amstech.screaming.net
AmsTech Home Page
http://members.tripod.co.uk/Craigster/index.html
Mickael Pointier <mi...@defence-force.org> wrote in message
news:7sb5v1$jvc$1...@lyon110.dtr.fr...
>The sound input _is_ the simplest way and is easily implemented with
>no seperate interface standards getting in the way. The idea that the
>parallel port interfaces should be standardised is sound and in no way
>creates a threat to sound device loading.
Pun not intended? ;<)
Still, at least you typed "complementary" (supplemental) instead of
"complimentary" (free). Now the latter *would* be something!! ;<)
[Once more, due to use of news.freeserve.crap, FUs set -- remember to
clear before replying...]
--
--------------------------------------------------
Regards, Robert the Eboreg
New? Read the FAQ: http://www.kendalls.demon.co.uk/cssfaq/
The .DSK format scales perfectly well to 80 cylinders; I use it like this
in JOYCE. It would work equally well for PC emulators, or anything else
with a uPD765A controller. Whether it would work for computers with other
FDCs, I'm not sure.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
>I believe in that case that it would be possible to have a similar system
>for disk drives ?
>A standard way of encoding disk datas, that would allow us to have
>"writedisk" and
>"readdisk" utilities that works for Atari ST, Oric, Spectrum, Apple, etc...
For disk images you might want to look at the 2IMG format created for
Apple IIgs emulators. It is a universal disk image format with a
header that contains information about the size of the disk image. It
is currently being used for images of both 5.25" and 3.5" and hard
drive Apple II disks using Apple DOS 3.3, ProDOS and HFS. It might
even work with MS-DOS formatting but I haven't tried it.
It might require some tweaking of the format to make it multi-system
capable as it does assume 512 byte blocks but Apple DOS 3.3 actually
uses 256 byte sectors but they are just paired up in the 512 byte
blocks so the format might work as is. There is a spot that the
program that creates the image can put its own information so it
should be possible to work around any problems using that.
+------------------------------------------------------------------------+
| Jeff Blakeney - Dean of the Apple II University in A2Pro on Delphi |
| Delphi Apple II Forums Web Pages |
| A2: http://www.delphi.com/apple2 A2Pro: http://www.delphi.com/a2pro |
+------------------------------------------------------------------------+
> In article <49438B888F%ne...@youmustbejoking.demon.com.uk>, Darren Salt
> <ne...@youmustbejoking.demon.com.uk> wrote
> >In message <37fb8bb7...@news.freeuk.net>
> > gree...@BOLLOCKSyahoo.co.uk wrote:
> >
> >> It would be better to use the sound card,
> >
> >Sound card? Perhaps you should look at where this is crossposted...
>
> But we're talking about a hardware gadget which connects to the parallel
> port on your PC (or whatever it connects to on the Miggy)
Joystick port. I thought I mentioned that, actually, but looking back
I see I didn't. It essentially toggles the fire button on and off as
sound goes in. It's best not to have joystick emulation switched on
while it's connected, though :-)
1. Soundcard (Midi presumably)
2. Parallel Port
3. Joystick socket
Now I think I will sugest something really wacky (or wacci!!) how about a
hardware SCSI port for tape data transfer!!
;-)
> Ernest R. Schreurs (ern...@wxs.nl) wrote:
[snip]
>> Tapes for one system cannot be loaded on another system. I think it is
>> very confusing to store all sorts of tape files for different machines in
>> the same format. [...]
> Then I'd like to suggest a slight alteration to the implementation of TZX
> files. Provide alternative filename extensions for different machines.
That loses immediately :-)
> The actual encoding could be identical, but the extensions would allow the
> user to distinguish between files for different machines. Say:
> TII for Apple II
> T80 for ZX80
> T81 for ZX81
> TBC or TAC for BBC Micro/Acorn Electron
> TAM or TPC for Amstrad CPC
> etc
> (It's a shame some OSes only support 3-letter extensions. [...]
Hmm. RISC OS doesn't recognise filename extensions at all on Filecore-based
filing systems such as ADFS and provides extension-to-filetype mapping in
DOSFS and CDFS (and 3rd-party FSes of this type), so unless we're going to
allocate yet more filetype numbers...
> Then the emulator/archive program could have the 'files of which type'
> options:
> TZX for [computer being used] - that would show only files with the
> relevant extension.
> All TZX files - that would show all files with an
> extension accepted by the TZX
> standards body.
Fair enough, but why bother when the emulator can multitask and interact with
the Filer? :-)
--
| Darren Salt anti-UCE | d youmustbejoking,demon,co,uk | nr. Ashington,
| Spectrum +3, Risc PC, | s zap,uk,eu,org ** anti-UBE | Northumberland
| A3010, BBC Master 128 | @ retrospec,co,uk | Toon Army
| This space reserved for future expansion
Clones are people two.
: > Ernest R. Schreurs (ern...@wxs.nl) wrote:
: [snip]
: >> Tapes for one system cannot be loaded on another system. I think it is
: >> very confusing to store all sorts of tape files for different machines in
: >> the same format. [...]
: > Then I'd like to suggest a slight alteration to the implementation of TZX
: > files. Provide alternative filename extensions for different machines.
: That loses immediately :-)
: > The actual encoding could be identical, but the extensions would allow the
: > user to distinguish between files for different machines. Say:
: > TII for Apple II
: > T80 for ZX80
: > T81 for ZX81
: > TBC or TAC for BBC Micro/Acorn Electron
: > TAM or TPC for Amstrad CPC
: > etc
: > (It's a shame some OSes only support 3-letter extensions. [...]
: Hmm. RISC OS doesn't recognise filename extensions at all on Filecore-based
: filing systems such as ADFS and provides extension-to-filetype mapping in
: DOSFS and CDFS (and 3rd-party FSes of this type), so unless we're going to
: allocate yet more filetype numbers...
OK, well for the majority of machines, the extension idea should
stick. I'm afraid Arc users may have to settle for a single
filetype. But then that's not a problem, because the multiple
extension standard would really only be required for idiots. The only
idiots I know with RISC PCs and Arcs are school teachers... :)
: > Then the emulator/archive program could have the 'files of which type'
: > options:
: > TZX for [computer being used] - that would show only files with the
: > relevant extension.
: > All TZX files - that would show all files with an
: > extension accepted by the TZX
: > standards body.
: Fair enough, but why bother when the emulator can multitask and interact with
: the Filer? :-)
Because the lure of the dark side is strong. It promises much to those
willing to listen. It fools the unwary and weak willed into believing
it has more power than the light side. You and I both know
differently...
There is much conflict in me. I can feel it. Perhaps one day I can
return to the true path...
: Clones are people two.
OUCH!
> Then I'd like to suggest a slight alteration to the implementation of
> TZX files. Provide alternative filename extensions for different
> machines. The actual encoding could be identical, but the extensions
> would allow the user to distinguish between files for different
> machines. Say:
> TII for Apple II
> T80 for ZX80
> T81 for ZX81
> TBC or TAC for BBC Micro/Acorn Electron
> TAM or TPC for Amstrad CPC
> etc
I don't really see the point. Nobody is going to mix up the files on
their HD, are they? Most likely, the files will be categorised
into directories or subdirectories of the relevant emulator.
Eg.
Tapes/Spectrum/
Tapes/AppleII/
Tapes/ZX80/
> (It's a shame some OSes only support 3-letter extensions. It makes
> this far too complicated. .T64, for example, already exists for a C64
> tape archive.)
Just stick them all under .TZX (or, more accurately, they should be
under ".8BT" (8 bit tape) or ".TPE" or something.)
> > (It's a shame some OSes only support 3-letter extensions. [...]
>
> Hmm. RISC OS doesn't recognise filename extensions at all on Filecore-based
> filing systems such as ADFS and provides extension-to-filetype mapping in
> DOSFS and CDFS (and 3rd-party FSes of this type), so unless we're going to
> allocate yet more filetype numbers...
Agreed. All the formats are identical, so they should have the same
filetype identifier (be it extension, filetype or whatever). Of
course, if you can identify files by actually looking at the first few
bytes, then there's no way to differentiate anyway.
Of course, we might need some "TZX Launchers" that can interpret the
"machine type" field and send the file to the correct emulator on
double-click.
> Hey, we now have claims that 8bit tapes are better transferred by
Er.. I never said it was better...
> 1. Soundcard (Midi presumably)
I fail to see how MIDI is going to help tape transfer.
Oh, or perhaps you were being sarcastic (and I completely failed to
notice, as usual)