Recording to cassette using SIOV, IRG duration

[baktra]

I am working on a program - Tape Self-Extractor. 

 

This self-extractor is a binary load file that holds a collection of data blocks. After pressing START, all blocks will be written to tape.

There is also a block table, for each block, it holds the following information:

1. Block buffer range (2 16-bit addresses)

2. Block flags byte - the bits indicate how long the IRG before the block is to be - 20s, 3s, or 250ms.

 

To write a block, I would like to use the following code (SIOV)

;Now prepare the SIO call
                   lda #$60               ;Cassette
                   sta DDEVIC
                   lda #0                 
                   sta DUNIT              ;Zero unit
                   sta DCOMND             ;No command
                   sta DUNUSE             ;Zero unused byte
                   sta DAUX1              ;Zero AUX1 byte
          
                   lda #$80               ;Indicate Write
                   sta DSTATS
           
                   lda ZP_SIO_BUFRLO     ;Set buffer address
                   sta DBUFLO
                   lda ZP_SIO_BUFRHI
                   sta DBUFHI
          
                   lda ZP_SIO_LENLO      ;Set buffer length
                   sta DBYTLO
                   lda ZP_SIO_LENHI
                   sta DBYTHI
          
                   lda #$00               ;Short gaps between records
                   sta DAUX2
          
                   jsr SIOV               ;Call SIO 

I observed that:

For DAUX2==$00, I will get 3 seconds IRG

For DAUX2==$80, I will get 250 ms IRG

 

Unfortunately, I have no idea, how to tell SIOV to generate 20 s IRG for a block. Is that even possible? Or will I have to copy/paste more OS ROM code to get 20s IRG?

 

P.S, I cannot use CIO, it is inflexible for my needs.

 

 

 

 

 

Edited April 26 by baktra

[Rybags]

You will usually only get a long IRG at the start of file (leader tone) when using CIO.

 

When you write a record, the SIO output at the end should be logic 1 which is the same as the tone for IRG.

You should be able to get a longer IRG by just having a delay between SIOV calls, and there should be no disruption in the leader tone.

But don't use long IRG mode since it stops the cassette motor at the end of each write.

 

Also since you're using SIOV you have the flexibility in that you can write out practically any record size that you want (I'm guessing you're probably already planning to do that)

I used it in the day before I had a 1050 to create a fast loading AsmEd image - it had a loader that was a few blocks long then the entire 8K cart image was written as a single block.

Also I used a VBI when writing it to increase the baud rate.

[baktra]

That's not very good news, because the long IRG can be needed for any data block.

It seems, I will have to do the following:

 

1. Set up the POKEY for cassette output - two-tone mode, appropriate values in AUDCx and AUDFx, baud rate.

2. Start motor.

 

For each block

3. If the intended IRG time is > 250 ms, then force POKEY to output 1 for the desired time, minus 250 ms. 

4. Call SIOV with DAUX2=$80 to get the remaining 250 ms of IRG and record the data block.

End for

 

5. Stop motor.

6. Reset the POKEY for normal operation.

 

For 1 and 3, I will need to copy/paste and modify code from the Altirra OS.

Doable, but still a somehow disappointing. One has to ask why the IRG duration cannot be specified in DTIMLO of the DCB... I guess I am 2024-1979=45 years late.

 

 

 

[phaeron]

Short IRG mode with a delay between SIOV calls should be enough -- it should already be writing continuous mark tone (1) after the end of each block.

 

[baktra]

I have put together a prototype TSFX

https://drive.google.com/file/d/1l9gL1GcJeyux22BeBfZmhPIDAZG8CGlt/view?usp=sharing

 

Once loaded, after pressing START, it will record the ALIEN AMBUSH game to tape (first a cassette-oriented binary loader, then the game), using the standard tape records.

 

In case someone would want to peek:

https://github.com/baktragh/a8_tape_loaders_and_utils/blob/feat_tsfx_standard/tape_sfx_skeletons/standard/standard_sfx_skeleton.asm

 

Yes, it was not written for saving every possible byte. Especially, the IRG duration setting code is not one of the most efficient ones.

 

Edited April 30 by baktra

[baktra]

With latest commits, I've improved the code. Tests with real hardware indicate the TSFXes work. God bless AltirraOS and its author.

 

Still, it is unfortunate the tape support wasn't done better for the 8-bit computers. Two items I miss the most - file names and wider range of baud rates, up to 2400 bps. SIO would have been flexible enough to support improved recorders.

 

[Rybags]

Filenames maybe - depends how it's done.  It sort of breaks the CIO device independence philosophy if not done right.

There's nothing stopping implementing a Basic CSAVE that requires a filename which gets written before the program itself.

But to be fully useful, the program name should be echoed to the screen when it's found.

A potential problem here is that the user could presss Ctrl-1 to pause screen output which if the tape keeps running would cause a load fail.

Not sure if you can have a tape file that has long IRG for the 1st 2 records then switches to short IRG after those?

 

Also, skipping a wrong file name would be problematic - as we all know if you have noise or excessive leader on an Atari tape it can cause a read error.

Possibly the tape SIO could have had more smarts such as assuming 5 seconds of pure clean "1" input to be a clean leader where it would attempt to read the next file.

[baktra]

With the file name, it is correct. Calling CIO from CIO is somehow... deadly and making CIO reentrant for the sake of the C device would be complex and impractical. Only a special, non-CIO, E device function call would solve the problem. And that would be a misfit for CIO.

[Rybags]

As it happens, the program name actually does get included in the file if you use the SAVE command.

Problem is, SAVE to tape will use long IRG, and the name gets included at the end of the file - also it's not displayed and probably not retrievable once the program has loaded.

This occurs due to a slight Basic bug - commands in immediate mode are stored in a dummy line at the end of the program and are included in the saved file.

 

Devices have the "Put character" vector - possibly it could avoid the re-entrancy problem.

Though that was a kludge to begin with supposedly to allow Basic to be developed with an incomplete OS at the time.

But realistically on Atari the way to do it would be via the application or language - I think the long followed by short IRG method could allow the required pause but unsure if a mode change can be done (at least in a "legal" programming sort of way)

Edited May 7 by Rybags