Using Pulse Density Modulation for 8-bit PCM

[NRV]

mmlv6_pal_rh sounds pretty impressive on real hardware: just tested it on the 1088XEL using my Ultimate Cart. I'll try to record it through the capture dongle if I get time, since the camera hasn't really been doing these things justice. Background noise is pretty low.

Any chance of some raw stereo files for the IDE player or some code samples? I doubt I can do better than 44KHz per channel, so stereo on the IDE player may require the bitrate to be chopped in half on each channel.

My examples are for 15.7 KHz approx. and 8 bit depth, don't know if that works for you?

That's one sample per scanline, using wsync.

I also interleaved the data, first a 4K block for the left channel and then a 4K block for the right channel, for every cart bank.

I would clean the code and put it here later.

 

Edit: here is the source:

clean.zip

 

Would you say that there is more noise than what we get in Altirra?

 

Hello guys

How do I load a file into Altirra? I'm running a bottled version on my iMac.

Sincerely

Mathy

I don't have any experience with the mac version, but I assume that drag and drop or "Attach cartridge.." don't work?

Here are my last examples in .car format:

 

Atari.zip

 

(the _rh versions, ntsc and pal)

Edited May 27, 2018 by NRV

[Mathy]

Hello NRV

 

There is no Mac version. Wine lets you run Windows software on the Mac. "Bottled" means you somehow rap Wine around a piece of PC software.

 

"Drag and drop" doesn't seem to work. And when I try to load a piece of software from within Altirra, it shows me a map structure similar to a PC. Without the files I have on my Mac.

 

Thanks for Atari.zip. Just listened to both files (PAL versions). I really like "Strings". It really shows what PDM can do.

 

Sincerely

 

Mathy

[+MrFish]

I really like "Strings". It really shows what PDM can do.

 

I'll name the tune, since nobody else has so far. It's Bach, of course, and the first section of his

Partita III for solo violin in E - Gavotte en Rondeau (BWV 1006).

 

I know it well, since I've been playing it from about the age of 22 or so.

[phaeron]

Finally got a chance to spend some more quality time with the Atari and the scope.

These are the raw digital outputs from POKEY pin 37 with the PDM calibration program on 12/14, 12/15, and 12/16:



It appears that the high-pass takes effect about a half cycle off from the output flip/flop. That's why we had to lower the period from 16 cycles to about 8 on real hardware: the pulse is half of what we had expected. At this low amplitude with just the low-order nibble the audio output is just noise, but as we've seen it does make a difference when combined with the high nibble output. I ran into some trouble getting a stable trigger on some of the settings from a quarter cycle jitter I can't explain.

There is a difference between POKEY's digital signal and the final audio output, but not as much as expected:



This is two triangle waves being played first on channel 1 only and again on all four channels simultaneously, with the scope chopping between POKEY pin 37 and the RCA audio output. Time scale is two scanlines (228 cycles) per volume step. For a single channel the output is actually pretty linear, though there is noticeable step size error from the different bit outputs not quite adding up right. With all four channels blasting, though, there is noticeable saturation effect as the total volume rises above 32. It's also symmetrical, so it is not a time-dependent RC effect like you can see from the audio output on top. I'm guessing that the saturation effect isn't significant for PDM, though the uneven steps might be. Still need to measure the time constant for the RC effect on the audio output, though it looks too gradual to have any real effect on audio quality.

If you look really closely at the audio output, though, you can see that a couple of steps from POKEY's output are reflected in the audio output. This is a closer effect at what's happening:

 

Notice the clamped steps after high peaks. Essentially, it looks like whenever POKEY produces high volume for a long enough period of time, it swings an internal reference in the amplifier far enough that the output clamps when the signals drops back to a low value. Not sure what the exact rules for this are; I would have expected the four-channel wave to clamp out about as much as after the marker peak at the beginning, but it didn't.

 

[+Stephen]

Nice - I see better PoKey emulation in the near future! Maybe closer to an FPGA replacement too.

[ijor]

These are the raw digital outputs from POKEY pin 37 with the PDM calibration program on 12/14, 12/15, and 12/16:

...

There is a difference between POKEY's digital signal and the final audio output, but not as much as expected:

 

 

Great research, as always .. But not sure what you mean by "digital", it is certainly analog and not digital.

[phaeron]

 

Great research, as always .. But not sure what you mean by "digital", it is certainly analog and not digital.

 

Alright, fine, be that way.

[phaeron]

Old player I wrote for a couple of Faery Tale Adventure songs, converted to PDM. Start/Select/Option changes playback mode.

faerytale-pdm.zip

Edited June 4, 2018 by phaeron

[ivop]

Old player I wrote for a couple of Faery Tale Adventure songs, converted to PDM. Start/Select/Option changes playback mode.

 

Thanks for including the source code! By glancing over it, it just occurred to me (well, I saw you doing it) that the "inc irqen" trick can also be used on timer 4. I was mistakenly thinking it could not and hence hinder my conversion of 'atarsid' to PDM. I really have to look into that as soon as I have some spare time

[+Stephen]

 

Thanks for including the source code! By glancing over it, it just occurred to me (well, I saw you doing it) that the "inc irqen" trick can also be used on timer 4. I was mistakenly thinking it could not and hence hinder my conversion of 'atarsid' to PDM. I really have to look into that as soon as I have some spare time

Oh man! If you can get your SID player using PDM - I wonder how close to an original SID it would be?

[a8isa1]

It's a five minute job to compile builds for MYIDE, XEL, etc. Got side-tracked with a firmware bug.

 

Will upload the other builds tomorrow.

I've recently been accused of "always wanting more!", so here is the "more" for this time...

 

In addition to a MyIDE build of your player how about variants of players that play from APT partitions. I personally wouldn't need it to play from the SD File System only from the partition. I think this mode would have the advantage of just needing to pass the starting (and ending?) LBA sector number to the player.

 

The above request leads to even more "more"...

 

Now that I know your current PDM player has the ability to read files from a FAT32 partition independently from U1MB can we expect an SDX driver that can copy files from said partition to the SD File Systems, Yes, without the reliance on U1MB?

 

-SteveS

Edited June 6, 2018 by a8isa1

[Jetboot Jack]

Hello NRV

 

There is no Mac version. Wine lets you run Windows software on the Mac. "Bottled" means you somehow rap Wine around a piece of PC software.

 

"Drag and drop" doesn't seem to work. And when I try to load a piece of software from within Altirra, it shows me a map structure similar to a PC. Without the files I have on my Mac.

 

Thanks for Atari.zip. Just listened to both files (PAL versions). I really like "Strings". It really shows what PDM can do.

 

Sincerely

 

Mathy

 

 

If you create your wine wrapped version with the latest version of PlayOn for mac you can get drag and drop and associate files with the bottled app (altirra in this case).

 

PlayOn seems a better solution for bottling that crossover or wine bottler on High Sierra.

 

sTeVE

[flashjazzcat]

In addition to a MyIDE build of your player how about variants of players that play from APT partitions. I personally wouldn't need it to play from the SD File System only from the partition. I think this mode would have the advantage of just needing to pass the starting (and ending?) LBA sector number to the player.

The player already reads information from partitions, and MBR partitions can be linked to the APT (as external entries) so that they appear as regular partitions with drive numbers, so it seems to me the player already does pretty much what you want. There is no advantage whatsoever to hosting the file in one partition type over another, and unfortunately the starting LBA sector number is entirely insufficient to facilitate PDM playback. The problem here is that once playback begins, we do not have time to parse sector maps or FAT links. We must - regardless of the file system - build a table of sector numbers which can be efficiently traversed while we're in a tight playback loop, and for this we require information such as the physical starting sector of the target partition's FAT, the physical location of the first data cluster, the cluster size, etc. On top of this, we still need to read the data from the drive at the same time we're playing it back, and the player as it stands is gobbling up sector numbers (one entry per cluster) from the table and buffering streamed sample data to avoid inter-sector or inter-cluster (were we to use multi-sector reads) gaps.

 

As for SDFS: it's limited to 32MB volumes. That's like 2-3 tunes and your partition is full. So vast (by A8 standards) is the volume of information being processed here, that it makes more sense to me to target FAT, since FAT partitions can hold hundreds or even thousands of huge PDM files.

 

Now that I know your current PDM player has the ability to read files from a FAT32 partition independently from U1MB can we expect an SDX driver that can copy files from said partition to the SD File Systems, Yes, without the reliance on U1MB?

The SIDE loader has been able to read files from FAT for years, as has the FATFS.SYS file system driver belonging to SpartaDOS X, which doesn't rely on U1MB at all (it'll work with the SIDE driver). There's nothing stopping anyone installing FATFS.SYS and doing a COPY *.* from a FAT partition to a SDFS partition. But the aforementioned volume size limitation of SDFS is worth bearing in mind before you attempt to copy PDM files into a SpartaDOS volume. For this reason I think making the player support anything but FAT is a complete waste of time at the moment.

Edited June 6, 2018 by flashjazzcat

[a8isa1]

The player already reads information from partitions, and MBR partitions can be linked to the APT (as external entries) so that they appear as regular partitions with drive numbers, so it seems to me the player already does pretty much what you want. There is no advantage whatsoever to hosting the file in one partition type over another, and unfortunately the starting LBA sector number is entirely insufficient to facilitate PDM playback. The problem here is that once playback begins, we do not have time to parse sector maps or FAT links. We must - regardless of the file system - build a table of sector numbers which can be efficiently traversed while we're in a tight playback loop, and for this we require information such as the physical starting sector of the target partition's FAT, the physical location of the first data cluster, the cluster size, etc. On top of this, we still need to read the data from the drive at the same time we're playing it back, and the player as it stands is gobbling up sector numbers (one entry per cluster) from the table and buffering streamed sample data to avoid inter-sector or inter-cluster (were we to use multi-sector reads) gaps.

 

As for SDFS: it's limited to 32MB volumes. That's like 2-3 tunes and your partition is full. So vast (by A8 standards) is the volume of information being processed here, that it makes more sense to me to target FAT, since FAT partitions can hold hundreds or even thousands of huge PDM files.

 

The SIDE loader has been able to read files from FAT for years, as has the FATFS.SYS file system driver belonging to SpartaDOS X, which doesn't rely on U1MB at all (it'll work with the SIDE driver). There's nothing stopping anyone installing FATFS.SYS and doing a COPY *.* from a FAT partition to a SDFS partition. But the aforementioned volume size limitation of SDFS is worth bearing in mind before you attempt to copy PDM files into a SpartaDOS volume. For this reason I think making the player support anything but FAT is a complete waste of time at the moment.

Sorry, I thought internal volumes of APT consisted of sequential LBA sectors and not even part of a file system such as FAT32. I thought it was a helpful idea to use a volume in 'raw mode' so to speak. Disregard my request.

 

Regarding a FAT32 driver, sorry again. I seem to recall FATFS.SYS being limited to FAT32 partitions 32MB or smaller because of limitations within SDX. I needed a partition larger than this so I guess I didn't even try using the driver. I will give it a try shortly.

[flashjazzcat]

No: APT isn't a file system but a partitioning scheme. Think of it like GPT. It even has an (optional) protective MBR. You can format APT partitions with any file system you please, although the convention is that external partitions are FAT formatted, since their purpose is providing large volume storage accessible by both the Atari and the PC. The native APT partitions, meanwhile, are hidden behind the protective MBR and never seen by the PC operating system (and thus protected against corruption).

 

I believe the public release version of FATFS.SYS is still limited to FAT16, although I was told of some private beta copy which supports FAT32. Nevertheless, FAT16 will get you a long way and I think 4GB volumes or similar are supported by the release version of the driver.

 

While current iterations of SDFS are limited to 16-bit sector addresses, SDX itself is not, since it can take advantage of the XDCB supported by U1MB/SIDE, IDE Plus, Incognito, etc. The XDCB provides 32-bit wide sector addresses (practically speaking, 28-bits with IDE devices) accessed via the DCB at $300, so a FAT32 driver for SDX is a perfectly workable proposition. The SIDE loader and PDM player themselves already support 128GB disks and volumes as large as FAT32 will allow.

[AtariNerd]

Have any experiments been tried using lower-resolution sampling, for sound-effects or voice, which might not need as high of resolution to be passable, as you can cut the frequency range quite a bit. Might be interesting if one can squish a chapter of a book, use a narrative voice or have a few small triggerable samples. Not that they could be used easily in other programs, without some screen-blanking (maybe a simple one or two - line text display?) , but it might make a nice transition effect.

[Guest]

edit. wrong thread

Edited June 6, 2018 by Guest

[Xuel]

Have any experiments been tried using lower-resolution sampling, for sound-effects or voice, which might not need as high of resolution to be passable, as you can cut the frequency range quite a bit. Might be interesting if one can squish a chapter of a book, use a narrative voice or have a few small triggerable samples. Not that they could be used easily in other programs, without some screen-blanking (maybe a simple one or two - line text display?) , but it might make a nice transition effect.

I've tried lower frequencies and it sounds about how you would expect. Lower frequency sounds sound fine. High frequencies are eliminated. Noisy sounds like share drums sound crackly. You can use FujiConvert to experiment with frequencies as low as 8kHz.

[mono]

Gentlemen. What do you think about playing two full 4+4 independent samples on one POKEY? And force all channels to run with 1.77MHz.

I took Xuel's thecart.car file from post 3 of this thread and made experiment with following POKEY settings:

2220: A9 7E     LDA #$7E
2222: 8D 08 D2  STA $D208   ;AUDCTL
...
2243: A2 09     LDX #$09
2245: 8E 00 D2  STX $D200   ;AUDF1
2248: A9 0A     LDA #$0A
224A: 8D 04 D2  STA $D204   ;AUDF3

I've left rest of code unchanged (music is played by channels 1 and 2, however channels 1 and 3 can be used for this purpose as I mentioned in the past):

2265: BE 00 A0  LDX $A000,Y
2268: BD 00 21  LDA $2100,X
226B: 8D 05 D2  STA $D205   ;AUDC3
226E: BD 00 20  LDA $2000,X
2271: 8D 01 D2  STA $D201   ;AUDC1
2274: 8E 00 D0  STX $D000   ;HPOSP0

In short words:

1. 1+2 and 3+4 are both 16-bit channels and work with 1.77 MHz.

2. 1 and 2 are "hi pass filter" channels controlled by 3 and 4 respectivelly and generate 1/16 PDM.

3. All channels are reloaded with 16-cycles period (because they are 16-bit and underflow/reload occurs at the same moment for both channels in pair).

 

Of course if you setup playing routine to use channels 2 and 4:

2265: BE 00 A0  LDX $A000,Y
2268: BD 00 21  LDA $2100,X
226B: 8D 07 D2  STA $D207   ;AUDC4
226E: BD 00 20  LDA $2000,X
2271: 8D 03 D2  STA $D203   ;AUDC2
2274: 8E 00 D0  STX $D000   ;HPOSP0

music is still playing correctly.

 

This is the way to setup all frequency timers to run with 1.77 MHz, so we can theoretically use two full 4+4 channels: 1(lo)+3(hi) and 2(lo)+4(hi).

 

Unfortunatelly it's only idea because I need some help to confirm if it works on real Atari (I have no possibility to check it on real hardware and tested it on Atari800 and Altirra emulators only).

Edited June 30, 2018 by mono

[+Stephen]

Gentlemen. What do you think about playing two full 4+4 independent samples on one POKEY? And force all channels to run with 1.77MHz.

I took Xuel's thecart.car file from post 3 of this thread and made experiment with following POKEY settings:

2220: A9 7E     LDA #$7E
2222: 8D 08 D2  STA $D208   ;AUDCTL
...
2243: A2 09     LDX #$09
2245: 8E 00 D2  STX $D200   ;AUDF1
2248: A9 0A     LDA #$0A
224A: 8D 04 D2  STA $D204   ;AUDF3

I've left rest of code unchanged (music is played by channels 1 and 2, however channels 1 and 3 can be used for this purpose as I mentioned in the past):

2265: BE 00 A0  LDX $A000,Y
2268: BD 00 21  LDA $2100,X
226B: 8D 05 D2  STA $D205   ;AUDC3
226E: BD 00 20  LDA $2000,X
2271: 8D 01 D2  STA $D201   ;AUDC1
2274: 8E 00 D0  STX $D000   ;HPOSP0

In short words:

1. 1+2 and 3+4 are both 16-bit channels and work with 1.77 MHz.

2. 1 and 2 are "hi pass filter" channels controlled by 3 and 4 respectivelly and generate 1/16 PDM.

3. All channels are reloaded with 16-cycles period (because they are 16-bit and underflow/reload occurs at the same moment for both channels in pair).

 

Of course if you setup playing routine to use channels 2 and 4:

2265: BE 00 A0  LDX $A000,Y
2268: BD 00 21  LDA $2100,X
226B: 8D 07 D2  STA $D207   ;AUDC4
226E: BD 00 20  LDA $2000,X
2271: 8D 03 D2  STA $D203   ;AUDC2
2274: 8E 00 D0  STX $D000   ;HPOSP0

music is still playing correctly.

 

This is the way to setup all frequency timers to run with 1.77 MHz, so we can theoretically use two full 4+4 channels: 1(lo)+3(hi) and 2(lo)+4(hi).

 

Unfortunatelly it's only idea because I need some help to confirm if it works on real Atari (I have no possibility to check it on real hardware and tested it on Atari800 and Altirra emulators only).

Do you have a file I can test? I have a PAL machine abd several ways of playing PDMs on it.

[mono]

I changed Xuel's code loaded from .car file directly in emulator. I'll prepare modified .car files tomorrow.

[Kyle22]

I sure hope we find a way for Incognito users to enjoy this... I just got another WinXP laptop (that works), so I can use RespeQt again.

[Mathy]

Hello Mono

 

As usual I don't have a clue what you guys are saying. But after listening to 94 songs converted by FujiConvert, all 15 seconds long (because my only means of playing them is via the Ultimate Cart) I'm convinced that I absolutely need STEREO.

 

Sincerely

 

Mathy

[Sheddy]

Gentlemen. What do you think about playing two full 4+4 independent samples on one POKEY? And force all channels to run with 1.77MHz.

I took Xuel's thecart.car file from post 3 of this thread and made experiment with following POKEY settings:

2220: A9 7E     LDA #$7E
2222: 8D 08 D2  STA $D208   ;AUDCTL
...
2243: A2 09     LDX #$09
2245: 8E 00 D2  STX $D200   ;AUDF1
2248: A9 0A     LDA #$0A
224A: 8D 04 D2  STA $D204   ;AUDF3

I've left rest of code unchanged (music is played by channels 1 and 2, however channels 1 and 3 can be used for this purpose as I mentioned in the past):

2265: BE 00 A0  LDX $A000,Y
2268: BD 00 21  LDA $2100,X
226B: 8D 05 D2  STA $D205   ;AUDC3
226E: BD 00 20  LDA $2000,X
2271: 8D 01 D2  STA $D201   ;AUDC1
2274: 8E 00 D0  STX $D000   ;HPOSP0

In short words:

1. 1+2 and 3+4 are both 16-bit channels and work with 1.77 MHz.

2. 1 and 2 are "hi pass filter" channels controlled by 3 and 4 respectivelly and generate 1/16 PDM.

3. All channels are reloaded with 16-cycles period (because they are 16-bit and underflow/reload occurs at the same moment for both channels in pair).

 

Of course if you setup playing routine to use channels 2 and 4:

2265: BE 00 A0  LDX $A000,Y
2268: BD 00 21  LDA $2100,X
226B: 8D 07 D2  STA $D207   ;AUDC4
226E: BD 00 20  LDA $2000,X
2271: 8D 03 D2  STA $D203   ;AUDC2
2274: 8E 00 D0  STX $D000   ;HPOSP0

music is still playing correctly.

 

This is the way to setup all frequency timers to run with 1.77 MHz, so we can theoretically use two full 4+4 channels: 1(lo)+3(hi) and 2(lo)+4(hi).

 

Unfortunatelly it's only idea because I need some help to confirm if it works on real Atari (I have no possibility to check it on real hardware and tested it on Atari800 and Altirra emulators only).

Interesting experiment, but hard to think of benefits. Obvious idea of stereo not any good with just one pokey

[mono]

Modified thecart.car files:

- lower uses only lower half of 16-bit registers (channels 1 and 3)

- upper uses upper half of them (channels 2 and 4)

 

Interesting experiment, but hard to think of benefits. Obvious idea of stereo not any good with just one pokey

I think about improvement of NEOTracker made by Epi.

Edited July 1, 2018 by mono