Bon Jovi's "Living on a prayer"

[Yautja]

Hi,

 

Nobody has found Bon Jovi's clip in his archives?

 

Also, how were these audios digitized for Atari XL/XE?

 

- Y -

[Mclaneinc]

Apart from it playing Bon Jovi is there anything you can remember about the disk itself, who made it, a logo, anything...

 

The number of files to search through makes it a huge task...

 

What about a year when you heard it?

 

I have to say I don't recall it myself, given the number of disks I collected and had access to I find it odd I don't remember that one, the Kinks, Star Trekkin etc I remember very clearly but although I do know the actual song I can't recall a sampled version.

[+Stephen]

I don't recall ever hearing a Bon Jovi sample. I kept everything I ever downloaded.

[+warerat]

You mean this?

 

BONJOVI.XEX

[Xuel]

For fun, here are some full-length versions that will only work in Altirra:

 

digi.zip

 

I used sox to resample. pcm.xex plays 4-bit samples at 15.6KHz. pwm.xex plays ~7-bit samples at 15.6KHz using pulse-width-modulation. Source on github.

[Xuel]

It might be fun to make a tool to make audio cartridge images. For example, a 4M cart could hold around 4 1/2 minutes of PWM audio or 9 minutes of PCM audio. I did a quick Google for Atari cart formats but couldn't find any specs for the file formats. Does anyone have a pointer?

[+Stephen]

It might be fun to make a tool to make audio cartridge images. For example, a 4M cart could hold around 4 1/2 minutes of PWM audio or 9 minutes of PCM audio. I did a quick Google for Atari cart formats but couldn't find any specs for the file formats. Does anyone have a pointer?

Why a cart when so many now have GB hard drives

[+Stephen]

For fun, here are some full-length versions that will only work in Altirra:

 

digi.zip

 

I used sox to resample. pcm.xex plays 4-bit samples at 15.6KHz. pwm.xex plays ~7-bit samples at 15.6KHz using pulse-width-modulation. Source on github.

That pwm example is unbelievable!

[Xuel]

Why a cart when so many now have GB hard drives

 

Good point! I was thinking that the low latency that ROM provides would be needed but phaeron has already shown that you can stream audio AND video off of a SIDE2 cart. SIDE2 and other IDE drives appear to be capable of responding with new bytes at least every other cycle, e.g. 1.79Mhz/2. The caveat though is that phaeron's player issues raw IDE sector reads instead of going through a file system. Perhaps audio alone would be low enough bandwidth to work through a file system, e.g. SDX. The only issue I see is making sure that the audio can keep playing smoothly out of a buffer while the file system is fetching more data. This would require that the file system be tolerant of high frequency interrupt handler.

[emkay]

That pwm example is unbelievable!

As PWM mostly describes, what the POKEY "filters" do "technically", when you control the timing offset. It could get more and more interesting , to use that feature, together with frequency calculations, for playing digis with rather low CPU usage.

[Yautja]

You mean this?

 

BONJOVI.XEX

Precisely! It's been a travel into the past. Thanks!

[Yautja]

For fun, here are some full-length versions that will only work in Altirra:

 

digi.zip

 

I used sox to resample. pcm.xex plays 4-bit samples at 15.6KHz. pwm.xex plays ~7-bit samples at 15.6KHz using pulse-width-modulation. Source on github.

Just tested them and work fine in Atari800WinPLus as well.

[Mclaneinc]

Blimey, never saw / heard that demo in my life... Love the high quality one, very nice..

 

Another person gets a bit of the past back thanks to AtariAge, nice one warerat...

 

I'd love to checkout your collection of Atari stuff in case there's some other rare games or demo's, maybe one day you could post it or pass it on to Atarimania?

 

There's always someone who has a bit that no one else has..

Edited September 16, 2014 by Mclaneinc

[Yautja]

For fun, here are some full-length versions that will only work in Altirra:

 

digi.zip

 

I used sox to resample. pcm.xex plays 4-bit samples at 15.6KHz. pwm.xex plays ~7-bit samples at 15.6KHz using pulse-width-modulation. Source on github.

 

Hi Lyren,

 

Could you p.l.e.a.s.e. explain in detail how to convert mp3 files to this audio format for Atari?

 

Regards,

 

- Y -

[shanti77]

How in sox make ~ 7-bit sample?

[Xuel]

Hi Lyren,

 

Could you p.l.e.a.s.e. explain in detail how to convert mp3 files to this audio format for Atari?

 

Regards,

 

- Y -

I used sox and a custom Perl script. You can see the sox command-line on my github page in my Makefile and the Perl code is in raw2audf and raw2audc. I'm working on updating the repo to work with the latest version of sox. Basically you just need to replace -u with -e unsigned-integer.

 

How in sox make ~ 7-bit sample?

That is just to say that the values you use for AUDF should not exceed the number of clock cycles on a scan line, i.e. 114, or probably a bit less to account for STIMER counter reset cycles. I say ~7 bits because 114 is almost 127 which is the highest value that fits into 7 bits. You're definitely getting less than 7 bits of fidelity. The moral of the story is that you just need to play with the attenuation in sox until it doesn't clip too badly. Storage still requires 8-bits per sample because the samples are stored as bytes in the Atari's memory.

[shanti77]

Ok thx, one more question.Why you use in audc values from 0x78 to 0x87, why not 4*lsr?

[Xuel]

Ok thx, one more question.Why you use in audc values from 0x78 to 0x87, why not 4*lsr?

 

The raw unsigned 8-bit values range from 0 to $FF with $80 representing the speaker at rest. raw2audc expects the volume to already have been lowered such that the effective range is only from $78 to $87. It then converts values in this range to AUDC values in the range $10 to $1F.

 

I could have left the volume at 100% in the raw samples. Then I could have reduced the volume in raw2audc. But I figured I'd let sox reduce the volume because I wasn't sure how about the math for minimizing quantization noise. I could also then let it dither the samples if desired. Basically by reducing the volume, I'm effectively forcing sox to produce ready-made 4-bit samples instead of 8-bit samples that I would then have to convert to 4-bit samples.

[Xuel]

Ok thx, one more question.Why you use in audc values from 0x78 to 0x87, why not 4*lsr?

 

Oh, I just realized I think I misunderstood your question. I think you are proposing packing two 4-bit samples into one byte and using masking and shifting to separate them on-the-fly. That is definitely possible. The only reason I didn't do that for this demo is laziness.

[shanti77]

No I ask why you convert 8-bit sample in this way? I convert 8-bit sample in this way:

SAMPLE div 16

[Xuel]

No I ask why you convert 8-bit sample in this way? I convert 8-bit sample in this way:

SAMPLE div 16

 

That's probably good enough. There are more elaborate ways to do it like deliberately adding noise to hide the quantization error. See the "dither" option of sox (graphs). I tried the default dither and it mostly just sounds like background hiss. Maybe it's only useful when you can shift the noise into inaudible frequencies but that's not possible when playing back at only 15KHz. Another consideration is whether the steps of the POKEY "DAC" are linear. Maybe tailoring the quantization to the measured levels of the DAC would produce better results? Even further consideration is the behavior of the amplifier circuit. There are probably things you could do to massage the signal for the particular circuit. That's way beyond my knowledge though so I'm just guessing.

[shanti77]

Thx for your answer, maybe I can use it someday.