15 bit 44 khz audio idea.

[yaqube]

Originally Posted by pandy71

im curious that using fast CPU for example - can we create something like 1 low res or even 1 hires directly putting data - or access to register can't be made more frequent than for example 1 CCK ( or 1/8 SYSCLK)

The CPU can write COLOR0 register (or any other custom register) every 2 CCKs (4 lowres pixels). The DMA could write COLOR0 register every CCK cycle (2 lowres pixels). With simple register address transcoding for Denise (mapping BPLxDAT registers to COLOR0) we can have 12-bit highcolour chunky (interleaved) display mode with nominal resolution of 160 pixels per line.

[pandy71]

Thx Kalms, Yaqube,

So hardware overlay is not possible (with using Denise) - with some additional logic, inject data to one of the color registers and create video only on one particular color - it must be done outside Denise maybe with using ZD.

[Thorham]

Originally Posted by yaqube

The CPU can write COLOR0 register (or any other custom register) every 2 CCKs (4 lowres pixels). The DMA could write COLOR0 register every CCK cycle (2 lowres pixels). With simple register address transcoding for Denise (mapping BPLxDAT registers to COLOR0) we can have 12-bit highcolour chunky (interleaved) display mode with nominal resolution of 160 pixels per line.

I never knew this, sounds interesting. Can this be used in combination with normal bitplanes?

[yaqube]

Originally Posted by Thorham

I never knew this, sounds interesting. Can this be used in combination with normal bitplanes?

I hope you realize you need a hardware modification to achieve this.

[Thorham]

Originally Posted by yaqube

I hope you realize you need a hardware modification to achieve this.

No, I didn't Perhaps I should have read the posts more carefully Thanks for clearing that up

[pandy71]

Accordingly to programmers - there is possible to do copper chunky 2x1 - 160 independent 12 bit pix on screen in 1 line - without any hardware modifications.

My question was bit different - external buffer, logic and inject buffer data as a color value to the Denise register - buffer outside CHIP bus - using only D0-D15, RGA1-RGA8 and some strobes etc

[yaqube]

Originally Posted by pandy71

Accordingly to programmers - there is possible to do copper chunky 2x1 - 160 independent 12 bit pix on screen in 1 line - without any hardware modifications.

According to hardware designers: that's impossible.

My question was bit different - external buffer, logic and inject buffer data as a color value to the Denise register - buffer outside CHIP bus - using only D0-D15, RGA1-RGA8 and some strobes etc

The answer is still the same: the COLOR0 register can be altered at CCK rate, so no faster than every 2 lowres pixels.

[pandy71]

Yaqube - not directly by changing color register value but with clever manipulation of pixels and color registers - probably also interlace is used (i suppose as a vertical oversampling) - limitations of the copper are known and i don't argue with this.

[spoUP]

any news chaps? if the c64 can get 8-bit sound the amiga should get fancy sound too!

[Thorham]

Originally Posted by spoUP

any news chaps? if the c64 can get 8-bit sound the amiga should get fancy sound too!

For Amigas it's quite simple: You can do 14 bit stereo in 28khz using DMA, or 56khz if you use a double scan screen mode (this doubles the speed of the audio DMA for some reason).

I play CD quality WAV files on my A1200 in 44 khz (I always use a double scan mode), and they sound great.

Other than standard DMA audio playback, it might be possible to do playback with the copper if it can control the right audio registers, but then you have a limited number of screen colors available.

Simply using audio DMA is probably the most useful, and produces good quality.

[pandy71]

Originally Posted by spoUP

any news chaps? if the c64 can get 8-bit sound the amiga should get fancy sound too!

why not 16 bit? With Delta Sigma or with MASH, C64 should be able to produce 16 bit sound on 2 - 3 bits

[AlexBruger]

Originally Posted by yaqube

This maximum sampling frequency is determinated by the DMA request logic from Paula to Agnus. On the first refresh slot the 4 pairs of AUDxDR and AUDxDSR signals are latched in the internal shift register. Then it's transmitted with a delay (TDM) on the DMAL line to the Agnus. [you can find more info in the Minimig's sources].

Very interesting is the fact that the maximum sampling frequency isn't the same for every audio channel. It depends on the delay from the first refresh slot to the moment the sample data is transmitted.

The minimum sampling periods for the audio channels:
#0 : 120 (121)
#1 : 121 (122)
#2 : 122 (123)
#3 : 123 (124)
In the parenthesis is the minimal value when the DSR (dma pointer reload from location register) request is transmitted (typical case when the sample length is 1).

Sorry for resurrecting such an old thread, but I was wondering if someone could explain how the AUDxDSR has influence on the sampling rate.
I get the explanation for the sampling rates without AUDxDSR but would have assumed they are the same with the AUDxDSR sent simultaneously.

My understanding is that the DMA pointer will only be updated by Agnus after the word has already been fetched, and since the next word is earliest fetched 227 cycles later (PAL) I can't see how it can have an impact.
The word is still written to AUDxDAT in the usual DMA cycles i.e. 13 for channel 0 or isn't it?

[Toni Wilen]

Originally Posted by AlexBruger

Sorry for resurrecting such an old thread, but I was wondering if someone could explain how the AUDxDSR has influence on the sampling rate.
I get the explanation for the sampling rates without AUDxDSR but would have assumed they are the same with the AUDxDSR sent simultaneously.

My understanding is that the DMA pointer will only be updated by Agnus after the word has already been fetched, and since the next word is earliest fetched 227 cycles later (PAL) I can't see how it can have an impact.
The word is still written to AUDxDAT in the usual DMA cycles i.e. 13 for channel 0 or isn't it?

Later answer. I was finally testing this and looked at old threads if there was something I had already forgotten..

It seems to be Paula feature (As you already said, Agnus can't cause the delay).

If internal sample length counter == 1: counter is reloaded (1 cycle delay) and then AUDxDSR DMAL bit is generated. If internal sample counter != 1: AUDxDR bit is immediately generated.

This logic matches real hardware behavior in UAE. (Of course I can't be 100% sure this is exactly what happens inside Paula but it probably is close enough in

[AlexBruger]

OK, I think I understand.
Just for clarification (all statements for PAL Amigas):

We have this steps in Agnus for sample counter != 1:

• Paula realizes it needs another DMA Word (transition from state 011 to 010) and signals Paula internally AUDxDR.
• At DMA Cycle 0 it copies AUDxDR to Paula internal Shift Register
• At DMA Cycle 13 Paula signals to Agnus that it needs a DMA word

So the worst case is when Paula transitions back from 011 to 010 at exactly the DMA Cycle 0.
Then it takes 227 cycles until the buffered signal is latched to the internal shift register and another 13 cycles until it is signaled to Agnus.
That gives us 227+13 = 240 cycles or a minimum sample period of 120.

And this steps in Agnus for sample counter = 1:

• Paula realizes it needs another DMA Word (transition from state 011 to 010) and first reloads the length counter and one cycle later signals Paula internally AUDxDSR and AUDxDR.
• At DMA Cycle 0 it copies AUDxDR to Paula internal Shift Register
• At DMA Cycle 13 Paula signals to Agnus that it needs a DMA word

So the worst case is when Paula transitions back from 011 to 010 at exactly the DMA Cycle -1 = 227.
Then it takes 228 cyles until the buffered AUDxDR signal is latched to the internal shift register and another 13 cycles until it is signaled to Agnus.
That gives us 228+13 = 241 cycles or a minimum sample period of 120.5 => 121.

Is that correct?