wav2cas utility

[phsstpok]

The program is failing at direct reads of the tape. These are in the form of GET #U3, variable (U3 being itself a variable for the file number). The program is doing these reads in a For..Next loop. I would think timing for this would be critical. Difficult using a real tape never mind simulating it on a virtual tape..

Ah, I think I understand what is going on.

First, the (possible) solution, then the explanation. I assume you can recover all three parts successfully. You will need to increase the inter-record-gap on all the blocks of the second part. The inter-record-gap (IRG) is the pause (gap) between each record. You can use a WAVE editor to patch the WAV, or an hex editor to patch the CAS file.

What happens is the following: The Atari OS has two different modes for reading/writing cassettes. One is with a short IRG, other with long IRG. When you load/save a basic file with CLOAD/CSAVE you select the short/fast mode. When you use LOAD “C:”/SAVE “C:” you select the long/slow mode. The slow mode doesn’t just increase the IRG, it actually pauses the tape between each record. Actually the long IRG is done only for the purpose of allowing the stop/start of the tape.

When loading a file recorded with fast mode, everything must be done fast enough. This is because the tape is not stopped. But when using the slow mode you have all the time of the world. After the OS reads a full record, is stops the tape and save the record in a memory buffer. In the meantime, there is no rush, the tape is stopped.

If you try to read a file byte by byte in BASIC, using “GET,#”, this is very slow. It must be done in slow mode. The problem you are seeing, is again, the lack of the motor control signal on the SIO2PC interface. Because the PC never pauses the tape, the slow basic program has no chance to read anything except the first record (of the second part).

So what you must do is to artificially make a very long IRG. The idea is to give enough time for the BASIC program, as if the tape would have been stopped. The long gap must be added before each record of the second part. I can’t say how long this gap must be, probably a couple of seconds.

Now, patching the file manually will probably be not so easy …

Again, the problem is related only to the SIO2PC interface. It won’t happen in real hardware. And if the emulator properly supports the motor control signal, then it shouldn’t be a problem either.

Real hardware won’t have a problem because the second part was surely recorded using slow/long mode. SIO2PC needs extra long gaps to compensate for not pausing the tape.

This is what I figured.

I don't know if the CAS format allows for adjustable IRGs (beyond the defaults for long and short) but it does allow for pauses. I've seen it in APE for Windows, messages like, "17 second pause". Don't know if a normal record (CAS record not tape record) has an adjustable duration value but I'll invesitgate. If not I can try inserting pause records instead.

The hex dump of the WAV2CAS process only shows two errors for my best conversion. Both errors appear to be at the end of each of two stages of the load. The errors don't necessarily mean corruption of the real data, only extraneous data.

What I mean is I think I have a good CAS file which hopefully only needs some careful patching to address the problem with the data records.

Thanks for another reasonable explanation, ijor.


Phsstpok

[phsstpok]

Edited for typographical errors

The program is failing at direct reads of the tape. These are in the form of GET #U3, variable (U3 being itself a variable for the file number). The program is doing these reads in a For..Next loop. I would think timing for this would be critical. Difficult using a real tape never mind simulating it on a virtual tape..

Ah, I think I understand what is going on.

First, the (possible) solution, then the explanation. I assume you can recover all three parts successfully. You will need to increase the inter-record-gap on all the blocks of the second part. The inter-record-gap (IRG) is the pause (gap) between each record. You can use a WAVE editor to patch the WAV, or an hex editor to patch the CAS file.

What happens is the following: The Atari OS has two different modes for reading/writing cassettes. One is with a short IRG, other with long IRG. When you load/save a basic file with CLOAD/CSAVE you select the short/fast mode. When you use LOAD “C:”/SAVE “C:” you select the long/slow mode. The slow mode doesn’t just increase the IRG, it actually pauses the tape between each record. Actually the long IRG is done only for the purpose of allowing the stop/start of the tape.

When loading a file recorded with fast mode, everything must be done fast enough. This is because the tape is not stopped. But when using the slow mode you have all the time of the world. After the OS reads a full record, is stops the tape and save the record in a memory buffer. In the meantime, there is no rush, the tape is stopped.

If you try to read a file byte by byte in BASIC, using “GET,#”, this is very slow. It must be done in slow mode. The problem you are seeing, is again, the lack of the motor control signal on the SIO2PC interface. Because the PC never pauses the tape, the slow basic program has no chance to read anything except the first record (of the second part).

So what you must do is to artificially make a very long IRG. The idea is to give enough time for the BASIC program, as if the tape would have been stopped. The long gap must be added before each record of the second part. I can’t say how long this gap must be, probably a couple of seconds.

Now, patching the file manually will probably be not so easy …

Again, the problem is related only to the SIO2PC interface. It won’t happen in real hardware. And if the emulator properly supports the motor control signal, then it shouldn’t be a problem either.

Real hardware won’t have a problem because the second part was surely recorded using slow/long mode. SIO2PC needs extra long gaps to compensate for not pausing the tape.

OK, I have a little better understanding of what is going on.

There are four tape files not three as I had originally thought.

The first file is a CSAVEd program. It is just a title page plus animation. It's loaded by typing CLOAD.

The second file is a data file for the first program. Data is read with GET statements. Long Record Gaps are used (typically 4062 milliseconds average). The data always loads in the emulator but I can't tell if it is corrupted or not because nothing is displayed. I can see cursor movement and I can hear the sounds but the screen remains blank. This part of the program runs and looks fine on the 800.

On the Atari success seems to be dependent on the timing the virtual tape with with executing the RUN command, which is done manually.

After the CLOAD there is a long pause on the tape. Pauses are duplicated by WAV2CAS emulation. I believe this particular pause runs for about 17 seconds. (I can check later and explain in a moment). This is where the timing aspect is involved. If I start the RUN command between about the 7 and 12 second marks then the data usually loads intact. If I enter the RUN command too soon or too late audible errors occur (bad records) and the textures are always corrupted, if they load at all, or an error message is generated and the program stops. Error - 146, I think.

After the title animation completes the program runs a CLOAD command having first POKEd a value into memory so that no keypress is necessary to start the tape. (Same was true for data file earlier). An error is always generated at this point.

If I then manually type CLOAD and enter twice, on the second instance the main program loads and seems intact. This appears to be like another problem with the tape emulation. Same results on emulator and real Atari.

The program fails at the GET statements in the main program.

I haven't reached this point very often with the real Atari. Too much time involved with slow tape loads. However, this failure cannot be easily overcome because the program attempts to start the tape on it's own, so it's not a user timing issue in this time..

[addenda]

I may try to take out the POKE so that I have some control over tape timing.

[/addenda]


Ernest Schreurs' built-in hex dump feature for WAV2CAS turned out to be extremely useful.

The dump displays records in the following format

- Record gap duration in milliseconds (displayed in decimal)

- Record length (also in decimal) minus 8 bytes [edit - probably original tape record length].

- Data bytes.

- and finally record conversion status, "OK" or "BAD"

The records in the actual CAS file are very similar.

- first byte is the record length. It's the same value as in the dump but in binary.

- second byte is either part of the IRG duration or is always just 0 (zero).

- third and fourth bytes form the IRG duration number, simple integer, low-order/high-order. Tape pauses are just padded with zeros. Short record gaps are typically around 240 milliseconds. Long record gaps are typically 4000 milliseconds. Actual values vary about 2% for each gap type.

- Data bytes

- checksum?

- text string, "data"


The CAS file has a header as follows (as best as I can tell)

- 4 bytes, text string "FUJI"

- 1 byte containing comment length

- 3 bytes, unknown usually all 0 (zero).

- Text comment (length varies).

- 4 bytes, literal "baud"

- 2 bytes unknown (seems always zero)

- 2 bytes, LSB/MSB, baud rate (usually 600)

- 4 bytes, text string "data"


Not sure what goes on at the end of the files but there is some additional data there.


Not much luck editing. I think I can fix the CAS file but what I don't have is a good working hex editor.

I was using Hextreme to look at files but discovered the trial version of this software only allows me to change bytes, not insert or delete bytes.

[deathtrappomegranate]

You've put a lot of work into this!

It's a pity that you don't have a real Atari cassette deck, because it would be interesting to see what happened in that case.

I'm having a few problems with some German cassettes at the moment, too.

[phsstpok]

You've put a lot of work into this!

It's a pity that you don't have a real Atari cassette deck, because it would be interesting to see what happened in that case.

Much time, yes, mostly spent recording the tape. Much work, not really. I've spent more effort typing messages. LOL!

I too am a little bit curious how well the tape would work in a real tape drive but I don't think I'll be buying one just to find out. I don't really have a use for the tape player.


Phsstpok

[phsstpok]

Not much luck with these hybrid (BASIC + data) tapes.

I managed to break up the tape into four separate files (using Hexplorer). I am pretty sure all the files are intact. I can now run the title screen program. I can also load the main program. What I can't do is get the timing right with the final data file.

Something is going wrong with the timing. After the main program loads it prompts for user input then starts to load data from the tape, then asks for more input, then loads more data. It's at this stage the program has trouble.

I can't be sure what the trouble is but I think it tried to stop the tape. This isn't possible with the real Atari plus tape emulation so it fails. The virtual tape runs on past where it was supposed to stop (my guess).

I can't even insert a long tape delay because I have no easy way to determine where in the data file that the trouble is occuring.

I'm not sure why the program fails in Atari800win plus which is able to stop virtual tapes.

I either have a second problem or my first "guess" is wrong.


I'm having similar problems with another tape, Analog Software's, "Shooting Gallery". This tape is also a BASIC program with a data file but is very unusual. It seems to have immediate mode commands at the beginning the tape.

The tape is started by booting to BASIC and then typing RUN "C:". (LOAD and CLOAD doesn't work!) After the program loads (very slow) a title screen appears then the program displays a message, something to the effect of, "Loading machine code". The virtual tape seems to skip past a few data records but seems to read the remaining data records. Finally, the program just ends without error. Displays the "READY" prompt and BASIC program has vanished.

I mentioned that the tape seems to have "immediate mode" commands. That's just a guess. If I type CLOAD or LOAD "C:" instead of RUN "C:" the program seems to load but no lines of BASIC code are available to review. If I type any BASIC commands, RUN, LIST etc. the Atari just crashes. I have no way to examine the BASIC code. Doesn't matter whether I "RUN" the program or "LOAD" it.

I get the same results in emulator or real Atari. (Click below to see screen captures).

http://home.ripway.com/2004-11/205181/S ... index.html


Altering the delay at that the start of the data file (machine code) does not cure the problem.