SAP TYPE R, recording (Turbo) Basic tunes to SAP

[ivop]

Hi,

 

I was wondering if there's a SAP player that supports TYPE R (timed Pokey registers dump)? I was thinking about adding 'SAP Recording' to atari800 (the emulator), mostly to record (turbo) basic tunes and maybe songs from games where it is hard to separate the audio player from the actual game. But if there's no player for TYPE R, I have to rethink this.

 

Regards,

Ivo

 

[pirx]

Hello Ivo,

 

Please do the Type R recorder even if there is no player now.

Please

[576XE]

Oh, boys...

 

I only need stereo 'Sygnus-Lyrae' composition of Fred Brooker.

It's really dramathic. And it's a COMPOSITION!

 

Thank you, Good Old Filip Oščádal !

 

I mean that šč is щ in Russian?

[miker]

IIRC there's no need to create R-type SAP, just main task is to make engine using B or D-type one (because of compatibility reasons - there is too much players to patch).

[ivop]

@miker, the problem with tunes from basic programs is that there's no such thing as an engine

 

@pirx, I'll look into it. At least a periodic register dump to a file will be a useful feature for an emulator anyway. Perhaps with some simple RLE compression of each channel's values (i.e. consider each register as a separate stream of values) several minutes might fit the memory of a stock 48kB Atari, including a native player. Afterwards, it'll be trivial to convert that to a TYPE B SAP file.

[pirx]

with exomizer it could get shorter than cmc files :]

[miker]

In fact - some RLE compression should do the thing, and you can decompress it "on the fly" (correct me if I'm wrong).

[ivop]

Yes, I think RLE should be enough. The problem with Exomizer or LZ4 or any other 'sliding window' method is that you'll have to keep large parts of the already decompressed and played stream of bytes in memory because a back reference might come up later. RLE is simply decompress 9 bytes, play and discard.

 

This pokey register recorder might also come in handy if a demo screen or game has very limited time left for music. One can compose a song in their favorite tracker, play it and record it and use that recording. A native player will probably take less than one scan line.

 

BTW recorder is done. I'll post the code to the atari800 mailing list shortly. It also supports recording stereo pokey songs.

[miker]

@ivop: any progress?

[ivop]

Yes, I have posted a patch to the atari800 mailinglist.

 

http://sourceforge.net/p/atari800/mailman/atari800-users/?viewmonth=201509

 

No native RLE compressed player yet, but I'm actually hoping on ASAP supporting Type R files

Edited September 29, 2015 by ivop

[phaeron]

I've some experiments with SAP type R recording that show that just RLE coding isn't enough to bring down music to reasonable size.

 

Attached is a .zip file with some type R recordings. There wasn't a player available, so I winged it with regard to the format. One problem is that the SAP format doesn't seem to require an identifiable terminator before the binary data, so I used a blank line for that. The files are:

• test.sap: Archon intro (26.5s)
• test2.sap: First part of Numen (2:44.9s)
• test3.sap: Sweet Voice MSX (digital channel lost due to low sampling rate) (2:01.8s)
• test4.sap: Run for the Money title screen (59.7s)
• test5.sap: Ray of Hope display list section (59.9s)
• test.xex: Atari player version of test2.sap

The Numen track was nasty -- it changes at least one POKEY register practically every frame and so the RLE compression was ineffective. Delta compression wasn't quite enough to pull it down to 48K and some additional compact encodings were needed to bring it below that. Unfortunately, this means that the playback is a lot more than just copying 9 values to registers. These are the encoded sizes for all the tracks:

 

• test.sap: $1000-1AB6 (2743 bytes) -- 1.72 bytes/frame, or 104 bytes/second
• test2.sap: $1000-97D3 (34772 bytes) -- 4.23 bytes/frame, or 212 bytes/second
• test3.sap: $1000-80A9 (28842 bytes) -- 4.75 bytes/frame, or 238 bytes/second
• test4.sap: $1000-3A0D (10766 bytes) -- 3.01 bytes/frame, or 181 bytes/second
• test5.sap: $1000-2FB6 (8119 bytes) -- 2.72 bytes/frame, or 136 bytes/second

Pattern-based compression to reuse sections would probably be more effective, but a lot more complex to encode.

 

saptest.zip

[pirx]

delta with 9 separate streams would help, maybe?

But I guess you did just that.

Edited October 5, 2015 by pirx

[miker]

But as I said. Native TYPE R is very unreliable. Ie, you can't attach raw data compressed without making changes in player itself.

 

But there is TYPE D present. Made mainly for songs with samples but also for some uncommon players like AMS or AMP.

 

Ivop made such a player (http://sourceforge.net/p/atari800/mailman/message/34458219/) which I've used to make SAP TYPE D from data obtained from latest beta of Altirra.

 

Attached two saps in zip. One from Supersynthesizer by KE-Soft ("Das Tor des Monats"), and second one is that Numen tune from compressed xex by Phareon (sorry, nothing "unnecessary" was ripped).

 

Should work on any of SAP players which support SAPs TYPE D.

 

Enjoy.

saps.zip

Edited October 8, 2015 by miker