AUDxPER for maximum playback rate

[Karlos]

Originally Posted by paraj

Yeah, wasn't too bad actually. Had to fiddle a little bit with it, which is why I didn't use your format - wanted to get a normal sample working correctly first, and try a few out different ones and didn't want to encode etc.


One small suggestion - if plain 68000 is on the table - is to store volume as a word. Decode will be then be very easy/fast, e.g.:

.loop:
    move.w (a0)+,(a1)+ ; store volume
    bne.b   .copy
    add.w   #FRAME_SIZE,a2 ; no need to store samples
    bra.b   .iter
.copy:
    rept FRAME_SIZE/4
    move.l  (a0)+,(a2)+  ; samples
    endr
.iter:
    dbf d0,.loop

Though you may already have had that in mind. Happy experimentation, maybe you'll end up with 512 sample frame size

I hadn't fully decided on the frame length tbh. Ultimately mine is an 8 bit sample replay. Obviously shorter frame size is better for quality but you begin to increase the data size to the point were objectively it's a comparable size to 12 bit but lacking the resolution. I picked a frame length of 16 as a starting point because it seemed like it would allow fast enough response to volume transients without adding too much size.

[ross]

Uploaded to the Zone an optimized 'normal' version.

IRQ code:

start_ptr	ds.l	1
end_ptr		ds.l	1    ; do not move
audio_ptr	ds.l	1    ; do not move
...
irq4	movem.l	a0/a1,-(sp)
	lea	$dff09c,a1
	movea.l	(audio_ptr,pc),a0
	move.w	#%0000011110000000,(a1)
	move.w	(a0),($aa-$9c,a1)
	move.w	(a0)+,($ba-$9c,a1)
	lea	(end_ptr,pc),a1
	cmpa.l	(a1)+,a0
	bne.b	.ok
	movea.l	(start_ptr,pc),a0
.ok	move.l	a0,(a1)
	movea.l	(sp)+,a0
	movea.l	(sp)+,a1
	rte

Before anyone grumbles:
- Yes, I want 'start_ptr' and 'end_ptr' as variables;
- Yes, I want it compatible with higher processors;
- Yes, I know that the writing of AUDxDAT can be slightly early;
- No, I do not want to share registers with 'main' code;
- No, I do not want to make the code larger (optimize branch).

~55/56KHz reachable.

[a/b]

Nice bait :P.

;	movem.l	(sp)+,a0/a1
 move.l	(sp)+,a0
 move.l	(sp)+,a1
	rte

You could also save 4 cycles if you place audio_ptr right after end_ptr (end_ptr -> a1, cmpa (a1)+,a0).

[ross]

Originally Posted by a/b

Nice bait :P.

;	movem.l	(sp)+,a0/a1
 move.l	(sp)+,a0
 move.l	(sp)+,a1
	rte

Right
I always forget that

You could also save 4 cycles if you place audio_ptr right after end_ptr (end_ptr -> a1, cmpa (a1)+,a0).

Yeah, it would have been better if I had also wrote the memory location of the variables
I edit the message. Thanks!

[pandy71]

Originally Posted by meynaf

Not without good accelerator board, but why not.

Goal is lowest common denominator - relaxed anyway expectations so 68020 allowed but still - accelerator board is more expensive than sound board

Originally Posted by meynaf

I wasn't serious...

To complex?

Originally Posted by meynaf

If you don't want to kill OS you can still do it under jitted emulation.

Emulation is not funny, is boring, more than disabled multitasking in Amiga.

Originally Posted by meynaf

You can bet on this if you want.

Well - i only expressed my hope that we will be able to live more on this world...

Originally Posted by meynaf

If you want to use their RT ability, i'm afraid i have to tell you they stop at 1khz.

Well this is usual minimal time interval but probably you can have 20..10uS (only this will be insane waste of CPU cycles - ditto Copper can be beneficial).

[Photon]

It's not a burning question for me. Other factors affect sound quality more. Some ideas.

Mind DRAM refresh cycle which cannot be blocked AFAIK + exact #cycles/frame unless aliased to same granularity as IRQ trigger cycles per CPU.

There should also be a tiny delay between 2 same ear channels? Probably difficult to abuse since it should be well above hearing.

[ross]

Originally Posted by Photon

There should also be a tiny delay between 2 same ear channels? Probably difficult to abuse since it should be well above hearing.

Yes, all channels have a small unavoidable phase shift.

[Don_Adan]

Originally Posted by ross

Uploaded to the Zone an optimized 'normal' version.

IRQ code:

start_ptr	ds.l	1
end_ptr		ds.l	1    ; do not move
audio_ptr	ds.l	1    ; do not move
...
irq4	movem.l	a0/a1,-(sp)
	lea	$dff09c,a1
	movea.l	(audio_ptr,pc),a0
	move.w	#%0000011110000000,(a1)
	move.w	(a0),($aa-$9c,a1)
	move.w	(a0)+,($ba-$9c,a1)
	lea	(end_ptr,pc),a1
	cmpa.l	(a1)+,a0
	bne.b	.ok
	movea.l	(start_ptr,pc),a0
.ok	move.l	a0,(a1)
	movea.l	(sp)+,a0
	movea.l	(sp)+,a1
	rte

Before anyone grumbles:
- Yes, I want 'start_ptr' and 'end_ptr' as variables;
- Yes, I want it compatible with higher processors;
- Yes, I know that the writing of AUDxDAT can be slightly early;
- No, I do not want to share registers with 'main' code;
- No, I do not want to make the code larger (optimize branch).

~55/56KHz reachable.

If You will be using SetIntVector, this routine can be shortest, but maybe slowest.

[meynaf]

Originally Posted by pandy71

Goal is lowest common denominator - relaxed anyway expectations so 68020 allowed but still - accelerator board is more expensive than sound board

Yes but accelerator board can serve many purposes where sound board is only for sound.

Originally Posted by pandy71

To complex?

Too slow.

Originally Posted by pandy71

Emulation is not funny, is boring, more than disabled multitasking in Amiga.

Right, but it allows doing things that are otherwise not possible.

Originally Posted by pandy71

Well this is usual minimal time interval but probably you can have 20..10uS (only this will be insane waste of CPU cycles - ditto Copper can be beneficial).

Current "modern" machines routinely waste incredible amounts of cpu cycles (among other things), so where is the problem. These OSes know nothing about Copper anyways.

[pandy71]

Originally Posted by meynaf

Yes but accelerator board can serve many purposes where sound board is only for sound.

Well... many purposes? Web browsing? 1080p movies edition?

Originally Posted by meynaf

Too slow.

This level of slowness?
http://www.visual6502.org/JSSim/index.html

Originally Posted by meynaf

Right, but it allows doing things that are otherwise not possible.

Perhaps... but still it is boring.

Originally Posted by meynaf

Current "modern" machines routinely waste incredible amounts of cpu cycles (among other things), so where is the problem. These OSes know nothing about Copper anyways.

Well, but at the same this is compensated by clocks almost 1000 times higher and multiple cores... For Copper we don't need OS, we need OS for file operations.

[meynaf]

Originally Posted by pandy71

Well... many purposes? Web browsing? 1080p movies edition?

So now i need to prove that accelerator boards are useful. This is becoming preposterous.

Originally Posted by pandy71

This level of slowness?
http://www.visual6502.org/JSSim/index.html

Slowness that makes it useless.

Originally Posted by pandy71

Perhaps... but still it is boring.

Waiting for copper program that will probably never come is boring, too.

Originally Posted by pandy71

Well, but at the same this is compensated by clocks almost 1000 times higher and multiple cores...

Which have to support an OS that does million times more things, on a very poorly designed architecture.

Originally Posted by pandy71

For Copper we don't need OS, we need OS for file operations.

Of course, but the OS will not let you touch the hardware so easily - provided it even works on a copper-equiped machine.

[Karlos]

Has anyone else lost the plot of this thread? Or is it just me?

[pandy71]

Originally Posted by meynaf

So now i need to prove that accelerator boards are useful. This is becoming preposterous.

you don't need to prove anything but simple accelerators are dead end and solutions like PIStorm are not considered by some people as accelerators but rather emulators - semantic from my perspective but still shows real limitations.

Originally Posted by meynaf

Slowness that makes it useless.

Sorry but don't share your view, having some HDL description of Agnus, Paula should provide neat way to simulate exactly and quite fast such situation also probably doing Copper audio should be easier...
Currently very complex logic is simulated in reasonable time thanks to modern HW so i think this is not slowness but complexity and lack of details preventing such simulator (WinUAE has embedded some general overview of DMA cycles so some work was already done on this)

Originally Posted by meynaf

Waiting for copper program that will probably never come is boring, too.

real life... i'm waiting one year for guys to finish my roof tiling... I can wait longer than year for Copper audio - trust me... no rush on Copper audio from my side.

Originally Posted by meynaf

Which have to support an OS that does million times more things, on a very poorly designed architecture.

I agree but still millions and millions are quite happy with results...

Originally Posted by meynaf

Of course, but the OS will not let you touch the hardware so easily - provided it even works on a copper-equiped machine.

You told me earlier that 'the OS' is not aware of Copper so this is bit contradictory...

[paraj]

Originally Posted by Karlos

Has anyone else lost the plot of this thread? Or is it just me?

It's a coming of age story. The young man (Ross) wants to prove himself by showing his father (Meynaf) that he can make a name for himself by creating copper driven audio, but first he has to overcome some challenges/distractions doing CPU driven audio to show his worth. It's one of those artsy movies where it's OK to skip to the third act if you're bored.

[meynaf]

Originally Posted by pandy71

you don't need to prove anything but simple accelerators are dead end and solutions like PIStorm are not considered by some people as accelerators but rather emulators - semantic from my perspective but still shows real limitations.

Being limited does not make them useless.

Originally Posted by pandy71

Sorry but don't share your view, having some HDL description of Agnus, Paula should provide neat way to simulate exactly and quite fast such situation also probably doing Copper audio should be easier...
Currently very complex logic is simulated in reasonable time thanks to modern HW so i think this is not slowness but complexity and lack of details preventing such simulator (WinUAE has embedded some general overview of DMA cycles so some work was already done on this)

The point was about 68000, not about modern HW.

Originally Posted by pandy71

real life... i'm waiting one year for guys to finish my roof tiling... I can wait longer than year for Copper audio - trust me... no rush on Copper audio from my side.

Does not make it less boring.

Originally Posted by pandy71

I agree but still millions and millions are quite happy with results...

I don't think so.

Originally Posted by pandy71

You told me earlier that 'the OS' is not aware of Copper so this is bit contradictory...

These OSes do not know anything about Copper. They will not let you access hardware. They probably don't even run on hardware that has a copper. Nothing contradictory here.

[pandy71]

Originally Posted by paraj

It's a coming of age story. The young man (Ross) wants to prove himself by showing his father (Meynaf) that he can make a name for himself by creating copper driven audio, but first he has to overcome some challenges/distractions doing CPU driven audio to show his worth. It's one of those artsy movies where it's OK to skip to the third act if you're bored.

Good one, remains script for Shrek - but perhaps this will be more dramatic:

"Ross, you can destroy the Paula AUDxPER limitations. Jay has foreseen this. Join me and together we can rule the galaxy as father and son."



Sorry, can't resist...

[pandy71]

Originally Posted by meynaf

Being limited does not make them useless.

Never said such thing... but simply there is no real accelerator capable to decode mp3, resample it with sane quality (let say -76dBFS i.e. 12 bit quality in Paula 14 bit mode) and play it in CPU mode to Paula offering at the same time some limited multitasking so you can pretend to working.

Originally Posted by meynaf

The point was about 68000, not about modern HW.

I'm talking about HDL simulator using code proven on physical device (for example replacing original Paula, Agnus) and similar for MC68000 - they are accurate MC68000 emulators also clock perfect HDL descriptions. And HDL simulators are reasonably fast so probably whole A500 (nowadays it is not so complex project) probably could be simulated with decent speed.

Originally Posted by meynaf

Does not make it less boring.

Waiting IS boring but i hope you not suffer from onychophagia.

Originally Posted by meynaf

I don't think so.

Microsoft profits shows something opposite but if you say so...

Originally Posted by meynaf

These OSes do not know anything about Copper. They will not let you access hardware. They probably don't even run on hardware that has a copper. Nothing contradictory here.

They can't block access to memory address if they are not forbidden to be accessed (this is my impression but i can be wrong on this)

[Karlos]

Can we get a TLDR on:

1. What is copper audio?
2. What are the proposed advantages of copper audio over regular Paula/DMA or AHI?

Somewhere in all the back and forth I lost it.

[meynaf]

Originally Posted by pandy71

Never said such thing... but simply there is no real accelerator capable to decode mp3, resample it with sane quality (let say -76dBFS i.e. 12 bit quality in Paula 14 bit mode) and play it in CPU mode to Paula offering at the same time some limited multitasking so you can pretend to working.

By itself mp3 is bad enough so that you don't need perfect sound system to play it.
Anyway, vampires (68080) are supposed to have higher audio dma limits and 16-bit sound.

Originally Posted by pandy71

I'm talking about HDL simulator using code proven on physical device (for example replacing original Paula, Agnus) and similar for MC68000 - they are accurate MC68000 emulators also clock perfect HDL descriptions. And HDL simulators are reasonably fast so probably whole A500 (nowadays it is not so complex project) probably could be simulated with decent speed.

I hope this is a misunderstanding.
The point has never been to emulate a 68000. It was about the 68000 itself doing clock-by-clock simulation ! (Which is obviously impossible.)

Originally Posted by pandy71

Waiting IS boring but i hope you not suffer from onychophagia.

It's you who are waiting, not me.

Originally Posted by pandy71

Microsoft profits shows something opposite but if you say so...

You know full well that superior marketing beats out superior products.
Btw. Didn't they have to fire quite a few people recently ?

Originally Posted by pandy71

They can't block access to memory address if they are not forbidden to be accessed (this is my impression but i can be wrong on this)

They probably require working mmu so yes they can forbid anything.

Originally Posted by Karlos

1. What is copper audio?

It is about sending audio data to D/A with the copper rather than regular audio DMA (or cpu).

Originally Posted by Karlos

2. What are the proposed advantages of copper audio over regular Paula/DMA or AHI?

Well, other people may answer this 'better' because for me it has none

[paraj]

Originally Posted by Karlos

Can we get a TLDR on:

1. What is copper audio?
2. What are the proposed advantages of copper audio over regular Paula/DMA or AHI?

Somewhere in all the back and forth I lost it.

Goal is to play samples at a rate higher than DMA mode allows (way back from start this was set at period ~124/28Khz).
To do that you need to play audio in non-DMA mode, which requires 1) clearing interrupt request bit (in INTREQ) 2) feeding new sample(to AUDxDAT) in time for audio state machine to not exit play loop (see HRM).

Normal way: Setup level 4 interrupt handler to clear interrupt bit(s) and feed new data (latest code by Ross does this). Alternatively just poll interrupt bit instead of having IRQ routine (my last code in this thread does this).
Copper audio: Kill OS and figure out when interrupt needs to be cleared (by write to INTREQ) and write AUDxDAT using copper.

Advantage of copper audio (supposedly): CPU and blitter can be used freely (if you use pure CPU method you run into the issues discussed previously).
Disadvantage: Hasn't been done before, needs Ross to (supposedly) do it, and copper list has to be extremely exact.