Strange Paula quirk allows for infinite playback lengths

[8bitbubsy]

Before I explain this, I just want to mention that this trick doesn't work on WinUAE, so you need a real Amiga for this to work.

I was playing around with a random .mod I found, and I noticed that one specific sample would play random junk at the end every time you played it, even though the length/replen/repeat attributes were sane. I played around a bit with the length and loop length, and suddenly it played infinite data after the sample end, every time it was triggered.

In other words, I found a trick that allows Paula to just keep on playing whatever is in chipmem forever, never caring about the LEN register. This, however, only seems to work if the period is just about too low for the DMA to be stable. This causes cracks/pops every now and then, and doesn't make this trick very useful in practice. Still quite funny though!

I made an example .mod that demonstrates this. Load it up on an Amiga with 2mb chipmem and see the magic. ProTracker is preferred, so you can see that it's just one note trigger. This might not always work, it can playback random junk in memory instead, depending on where the .mod samples end up with the AllocMem() call in the .mod loader. So yeah, maybe play back the song at low volume first and see. Loading up a very small Workbench environment should increase the chances of the .mod sounding perfect.

https://16-bits.org/etc/mod.paulamagic

Maybe it's something Toni should look into regarding WinUAE? Probably not though, but still an interesting quirk.

[Toni Wilen]

There is one possible problem: UAE always has fully cleared memory (unlike real hardware) at cold start, expected sound side-effect most likely can't be heard.
EDIT: also too many unknown variables. Player and everything must be included.

[no9]

Yeah, nice find. It is even more interesting that it doesn't freeze Amiga (does it? I didn't check it myself). Usually such things ended badly to the system.

[8bitbubsy]

Originally Posted by Toni Wilen

There is one possible problem: UAE always has fully cleared memory (unlike real hardware) at cold start, expected sound side-effect most likely can't be heard.
EDIT: also too many unknown variables. Player and everything must be included.

The content of chipmem before loading the .mod doesn't matter at all. The only thing that matters is that the huge sample data is adjoined in chipmem so that Paula plays it from the beginning to end without playing junk inbetween instead. This is only to demonstrate the trick in a more sensible way. In reality it doesn't matter, it will still play everything in chipmem from the starting address, and that shows off the concept already.

I'll create a small program later (w/ asm source) that demonstrates this so that it's a little more understandable and doesn't require ProTracker. I still have no idea what is really happening, but it sounds like some magic LEN/PER values (PER must be so low that the DMA can't keep up) never makes Paula update its internal registers after a read cycle, like it should.

Originally Posted by no9

Yeah, nice find. It is even more interesting that it doesn't freeze Amiga (does it? I didn't check it myself). Usually such things ended badly to the system.

To me it makes sense that it doesn't crash, as this is a hardware read quirk and not a software quirk. Maybe it's a different story if the MMU is enabled and it's reading private/protected areas.

[Toni Wilen]

Assuming it is hardware weirdness (and not some PT player weirdness), can you fit it in 1M chip? (=can use A500 which is much more friendly to logic analyzer checks)

[8bitbubsy]

Yep, I will make a more requirements-friendly test program later today.

Do you need it to play an actual long waveform, or are you okay with it just playing everything that is in chipmem from the starting address? If the latter, then the program will be absolutely tiny and can even be loaded on 512k chip systems.

[Toni Wilen]

The smaller, the better Actual sound data is not important.

[meynaf]

I remember hearing some junk on mods that use notes between 28 and 31 khz. It is not PT player weirdness because some tfmx (from games dragonflight and amberstar) also did this.
But it was random.
Also happened only on my A1200, not on my A600. I suspect it didn't happen on A500 either, otherwise the musicians would have noticed.
Under winuae the mods never fail (well, not in this way).

[8bitbubsy]

Originally Posted by meynaf

I remember hearing some junk on mods that use notes between 28 and 31 khz. It is not PT player weirdness because some tfmx (from games dragonflight and amberstar) also did this.
But it was random.
Also happened only on my A1200, not on my A600. I suspect it didn't happen on A500 either, otherwise the musicians would have noticed.
Under winuae the mods never fail (well, not in this way).

Interesting... This trick works on both my A1200 and A600 btw, tested it. As said, it requires carefully crafted Paula register values, so it's not easy to trigger on accident.

[Toni Wilen]

Is there only single period value that does it? Does every channel have slightly different value that does it?

[roondar]

Fascinating stuff, I'm still amazed that even after all this time new tricks/glitches/etc are found in the Amiga chipset.

[8bitbubsy]

Originally Posted by Toni Wilen

Is there only single period value that does it? Does every channel have slightly different value that does it?

All periods low enough to make the DMA unstable for the channel should work. Somewhere around period 1-123 depending on the channel index.
EDIT: This is apparently not true, I can't trigger it at certain low periods. Around period 114..123 seems more correct.

I just used period 120 (29.5kHz) on all channels to make a safe trigger and to playback a sample without too much pops/cracks.
Maybe it's possible to trigger this with safe periods too by finding other magic LEN1/LEN2 values. That would be amazing, but I doubt it's doable.

I successfully crafted two test programs and included source code:
1) "paulaquirk" will just play everything that is in chipmem after the program itself.
2) "paulaquirk2" plays a 500K sample that is incbin'd after the program, and then whatever comes after the sample in chipmem. This one is useful for quickly checking if the trick works or not in WinUAE.

https://16-bits.org/etc/paulaquirk.zip

Keep in mind that these two will play extremely unsatisfying junk waveforms, so be sure the volume is not loud.

[Toni Wilen]

I did some quick tests with only single channel. Interrupts are still being generated correctly (=AUDxLEN has to count) and DMA transfer is working as expected (=sound is correct = AUDxDR signal must work correctly) which can only mean possible explanation is AUDxDSR signal being inactive when AUDxLEN=1.

Quick emulation checks shows that in "quirk" situation AUDxLEN=1 condition _AND_ next AUDxPER=0 happens in same horizontal position pair every time. (More examination later..). In "non-quirk" situation values are not static.

(AUDxDSR etc stuff is documented in HRM audio state diagram page and previous page)

[8bitbubsy]

That's quite interesting. Since AUDxDSR is supposed to trigger at the same position every time with the specific magic LEN values, maybe it's getting missed because of the underran DMA (too low period)?

[Toni Wilen]

I noticed that the program already works in UAE but for some reason period range is smaller. Test program period 114 to 117 plays in UAE. 114-121 works with real hardware (I used channel 1, not 0)

Min value is always 114, upper range is 120+channel number.

It is really caused by AUDxDSR not being set. AUDxLEN==1 comparison is never true when audio state machine does state 3 to 2 transition.

There is probably some delay in Paula that explains the UAE difference.

[ross]

Originally Posted by Toni Wilen

Min value is always 114, upper range is 120+channel number.

This in some way make sense: 113 is period that doen't fit anymore in a video line (113*2<227).
114 to 120+x is the 'dead zone' between start of line and Audio DMA slots allocation.

How about a line with <227 slots? Do the values for the 'quirk' shift?

[Photon]

A too small period could in some cases prevent the counter from looping. This would be interesting if it could play samples longer than 128K with no artifacts. But in non-musicplayer applications, 128K double-buffered is about what you want to spend if streaming sound so...

The question is if it goes beyond 2MB and if so, what happens. Also, if it prevents DRAM refresh. It shouldn't, but if it does it's obviously unsafe to use.

[ross]

Originally Posted by Photon

The question is if it goes beyond 2MB and if so, what happens.

Nothing strange. Simply the AUxLC DMA pointer rolls, like the others DMA pointers (and the roll point/chip-ram addressable depends of Agnus/Alice A-lines).

Also, if it prevents DRAM refresh. It shouldn't, but if it does it's obviously unsafe to use.

This is impossible. Audio DMA slots are fixed. The only DMA channels that can steal refresh slot are those of Bitplanes DMA, because are dynamically allocable (and the machine usually crash).

[Toni Wilen]

Lets not speculate impossible things. At least without any evidence. Agnus DMA has nothing to do with this, nothing changes. It happens because Paula does not send "reset DMA pointer" signal to Agnus.

It can only happen if period counter counts to zero at least twice/scan line (with exactly right timing condition).

It can only happen repeatedly if AUDxLEN is integer divisible by scanline length (test program 2270/2) = AUDxLEN expires always at same horizontal position.

(I still don't know 100% correct rules, some piece is still missing)

[8bitbubsy]

So any LEN divisible by 227 should trigger the trick (together with too low period)?