New tape fileformat (.ort)

Anything related to the tools Tap2Wav, Tap2CD, Tap2Dsk, Sedoric Disc Manager, Tape Header Creator, WriteDsk, and generaly speaking tools related to the management of Oric data files and devices.
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: New tape fileformat (.ort)

Post by Xeron »

Thats weird, it should work. It may be that Oricutron didn't find the corresponding patch file for the ROM you are using...
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: New tape fileformat (.ort)

Post by Dbug »

I used the standard english rom, nothing special :)
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: New tape fileformat (.ort)

Post by Xeron »

did you have turbotape enabled?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: New tape fileformat (.ort)

Post by Dbug »

Not sure? I did not do anything special:
- Started Oricutron
- Booted the DSK file
- Loaded the executable (basic) I wanted to save
- CSAVE "TEST.TAP"
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: New tape fileformat (.ort)

Post by Godzil »

Symoon wrote:
Dbug wrote:Well, what would be a benefit would also if the code that read WAV would support all the variants of WAV, being mono, stereo, 8/16/24 bit per chanel, compressed or not. Because basically right now you can't just record with whatever tool you happen to have and save to whatever WAV format the tool uses by default: In my experience it's not going to work, meaning that archiving oric games is a science requiring years of experience and fiddling :p
I'm afraid this would be very hard to achieve. IIRC Fabrice chose 44kHz because at a lower rate, he wasn't able to decode 100% correctly the signal. The signal from the tape is so distorded and the tape players are using different speed, that it's really complicated sometimes to know how long each level lasts. For instance, that's one of the things that prevented me from finishing my slow speed decoder: I don't recall in detail but it worked with slow WAV files produced by Euphoric, but not with slow files from tapes (which makes it quite useless :? )
Stereo: another challenge, which channel will you use to read the WAV? Some tapes only have one channel recorded, the 2nd one being silent or so low that it can't be read. And belive me: some tapes use the left channel and, of course, other use the right channel :twisted:

It could be fun to store one program on the left channel, and another one on the right ;)
User avatar
waskol
Flight Lieutenant
Posts: 414
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

Re: New tape fileformat (.ort)

Post by waskol »

Hello !
A few years ago I suggested the use of such a new tap format ( http://forum.defence-force.org/viewtopic.php?f=22&t=365 ) in order to digitalize certain (protected ?) programs that could not be converted to a tap file, for instance : Side B of Tyrann, Cobra (snake game from Norsoft),

My idea was to be make it "readable" and editable by a real human too and easily readable by any emulator/tool since it was a text file of "0" and "1" put together by pairs.

May be it can be interesting to see it in Oricutron ?
User avatar
kamelito
Flying Officer
Posts: 182
Joined: Sun Jan 08, 2006 6:34 pm
Location: Nantes, France

Re: New tape fileformat (.ort)

Post by kamelito »

waskol wrote:Hello !
A few years ago I suggested the use of such a new tap format ( http://forum.defence-force.org/viewtopic.php?f=22&t=365 ) in order to digitalize certain (protected ?) programs that could not be converted to a tap file, for instance : Side B of Tyrann, Cobra (snake game from Norsoft),

My idea was to be make it "readable" and editable by a real human too and easily readable by any emulator/tool since it was a text file of "0" and "1" put together by pairs.

May be it can be interesting to see it in Oricutron ?
Maybe off topic, back in the day 2 friends of mine wrote a program for the Oric, it was the ultimate tape copier.
It read the bit flow from the tape drive, stored it in memory then wrote it back to tape.
I think they only found one game that didn't work because it was too long to store in RAM.
They send it to Hebdogiciel back then but IIRC Hebdogiciel died before printing it too bad :(

Kamelito
/kml
skype pseudo : kamelitoloveless
User avatar
waskol
Flight Lieutenant
Posts: 414
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

Re: New tape fileformat (.ort)

Post by waskol »

Yes, that's a little bit the point kamelito...
The .tap format is designed to be a "byte-by-byte" encoding, that suits well for major oric tape recordings.
But the .tap format fails for some recordings that were done with some custom recording methods that do not use any header like those that are explained in various books (see for instance Geof Phillips : http://home.btconnect.com/geffers/files/chap4.htm )
User avatar
ibisum
Wing Commander
Posts: 1643
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: New tape fileformat (.ort)

Post by ibisum »

One thing I really want to learn is how to take a tape and save it on floppy .. I never understood this, but I guess I'm overlooking some tools/utilities to do it?
User avatar
retroric
Pilot Officer
Posts: 125
Joined: Sun Nov 22, 2009 4:33 pm
Location: Paris, France

Re: New tape fileformat (.ort)

Post by retroric »

Xeron wrote:I have created a new format for Oric tape files.
(...)
ORT (Oric Raw Tape) files can contain raw square wave data for the tape input, as well as decoded bytes, and it can interleave the two.
(...)
I will also make a converter that can read .tap/.wav/.ort and save out .tap/.wav/.ort (any combination).
Hi Xeron,
I know I'm digging a 3-year old post and maybe you've moved on to other things by now, but I wanted to know whether you eventually managed to come up with the converter tool you mentioned that would be able to convert to and from between .tap, .wav and .ort ?

If so, can you please provide any links as to documentation or utilities that are available ??

The reason I ask is I use Oricutron a lot, unfortunately I'm not sure I really understand your .ort format well enough to be able to code an .ort to .tap converter myself.
Therefore I'd be very grateful if you could provide such a converter (Note: as to converting from .tap to .ort, in my view this has little value, as is providing a .tap to .wav converter since this is already catered for in Euphoric tools).

Cheers,

Laurent
flag_fr RetrOric, aka laurentd75 flag_uk
            GitHub - RetrOric
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: New tape fileformat (.ort)

Post by ThomH »

It's even later now, but re: "the following bytes are encoded as standard Oric loader format" — to be complete, shouldn't a format at least specify fast versus slow encoding?
User avatar
Xeron
Emulation expert
Posts: 426
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: New tape fileformat (.ort)

Post by Xeron »

No, it doesn't need to encode that.

Normal Oric data is stored in decoded bytes (same as .tap), so the fast/slow encoding has been stripped off. You could re-encode it as fast or slow if you like.

Other data is encoded as a waveform, so again no "fast" or "slow" really applies to the format.
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: New tape fileformat (.ort)

Post by ThomH »

Xeron wrote:No, it doesn't need to encode that.

Normal Oric data is stored in decoded bytes (same as .tap), so the fast/slow encoding has been stripped off. You could re-encode it as fast or slow if you like.
Then any encoding scheme which relies on time passed won't work in .ort. But I'm splitting hairs. The file format can encode any square wave so clearly can handle anything an Oric can. It just would be an inefficient use of space were there ever an encoding that relied upon the one versus the other.

At the very least, would you be willing to say that it is always decoded as fast data, so that it's clear when a conversion tool would have to do something else?
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: New tape fileformat (.ort)

Post by Symoon »

Not sure I understand all the questions, but some facts (and personal opinions):
- the "real" Oric tape routines headers do not store fast/slow flags, it is the user that decides if he wants to load fast or slow (,S), based on what the tape label (of his trained ears) says
- each emulator has its way to manage tape loading. Euphoric IIRC, with a TAP file intercepts ROM calls. If bytes decoding is called, then it loads bytes from the TAP file, whatever the speed. If bit loading is called, then it loads bits from the TAP file.
- fast or slow loading have no meaning in a TAP/ORT file where the bytes are already stored as bytes. Because emulator routines override the ROM routines.

But that doesn't mean it would be useless. I can see the following useful things in storing a fast/slow flag:
- let an emulator author choose if he wants the ORT file to load slower when "stored as slow" (a bit extreme as this can already be done using WAV files)
- indicate if the source of the ORT file was a slow or fast version on the original tape (this can be useful occasionnaly)
- prevent or warn the user of a multipart ORT file when converting it back into a FAST WAV, as the program may try to CLOAD"",S which will fail

But if an emulator tries to reproduce the exact real behaviour, beware that some users may not understand why, when they type CLOAD"", the (slow!) ORT file does not load. With TAP/ORT files, you have no more tape label or sound indication that the speed is slow or fast!
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: New tape fileformat (.ort)

Post by ThomH »

In response I'll also state my starting presumptions: a tape file format is a way of encoding an audio signal efficiently. The Oric senses only high or low so it's a one-bit signal. Most of the time the format is likely to hold data the ROM saved. In that case an efficient description is to list the bytes the ROM saved, making at least five out of thirteen implicit.

If you come at it from the efficient contextual storage of a square wave angle, it makes sense to differentiate between fast and slow encodings. This prompted the question.

I guess the mistake was in my assumption. The format is not intended to be an encoding of an audio signal — it's fine if different tools replaying the thing produce very different outputs. It's a way of interspersing segments of genuine audio within an emulator byte capture. It's about how to archive the software, not about how to archive the actual tapes.
Post Reply