Questions about 14 bit audio playback

[xxxxx]

An experiment I am considering is based on 14 bit audio playback, but without hardware testing capabilities, it's hard to verify that things are actually correct, so I have a few questions:
1. If you are trying to do 14 bit audio (DMA driven, with 2 channels - one at volume 64 and one at volume 1), it's super important that the 2 channels are fully in sync, right?. But is it precise enough to just turn the DMA on for the 2 channels at the same time? Will they be fully in phase? Are there any internal counters to worry about being off?
2. Specifically, do each of the channels wait for the DMA to actually return the word before the channel's period counter starts ticking - or do they start simply when the DMA is enabled?
3. Are there any edge cases to worry about? such as the period of the previous sounds, or at what time the DMA is turned on.
4. Is there any definitive code sample that people look at for how to start the buffers correctly?
5. Writing to AUDxDAT resets the volume counter - is that also true in DMA driven audio whenever the DMA delivers a new word? if so, should the period be a multiple of 64 for a volume of 1 to actually be 1/64th of the volume of 64? Or, put another way, if you put the period as 129, would it be on 3 of every 129 cycles (on for 1 cycle, off for 63, on for 1, off for 63, on for 1, repeat) rather than 1 of every 64 cycles (on for 1 cycle, off for 63, repeat)

[Toni Wilen]

Originally Posted by xxxxx

1. If you are trying to do 14 bit audio (DMA driven, with 2 channels - one at volume 64 and one at volume 1), it's super important that the 2 channels are fully in sync, right?. But is it precise enough to just turn the DMA on for the 2 channels at the same time? Will they be fully in phase? Are there any internal counters to worry about being off?

They should be in phase.

2. Specifically, do each of the channels wait for the DMA to actually return the word before the channel's period counter starts ticking - or do they start simply when the DMA is enabled?

Period counting starts when sample gets moved from AUDxDAT to 8-bit output buffer. "percntrld" in audio state diagram. DMA enable vs first word going to AUDxDAT can take more than 1 scanline.

3. Are there any edge cases to worry about? such as the period of the previous sounds, or at what time the DMA is turned on.

Should not be any. DMA is not 100% directly related to period/volume counting. It is also not possible to "delay" or "miss" some channel's DMA startup by one scanline by writing to DMACON in "bad" horizontal position. (Which would have been really annoying.. Some other DMA channels can have this problem)

5. Writing to AUDxDAT resets the volume counter - is that also true in DMA driven audio whenever the DMA delivers a new word? if so, should the period be a multiple of 64 for a volume of 1 to actually be 1/64th of the volume of 64? Or, put another way, if you put the period as 129, would it be on 3 of every 129 cycles (on for 1 cycle, off for 63, on for 1, off for 63, on for 1, repeat) rather than 1 of every 64 cycles (on for 1 cycle, off for 63, repeat)

According to audio state diagram it is only reset when first DMA word or CPU word comes. ("volcntrld" in audio state diagram). And I think I confirmed this in my oscilloscope tests some time ago.

Audio state diagram in HRM explains nearly everything, it really only lacks description of Agnus/Paula DMA request interface.

[Mrs Beanbag]

i was wondering lately about the possibility of putting them *deliberately* out of sync in order to "fake" a doubled sample frequency.

[xxxxx]

Thank you for the detailed answers Toni. I looked at the audio state diagram already, but I don't know how to read it properly. This sounds pretty straightforward, then :-)

Yeah, I was also considering the doubled sample frequency idea, after reading the thread about it. If they were playing in two channels (one with the odd samples and one with the even samples), with a period of 124, and were offset 62 clock cycles, then it may be an improvement. Then it would always overlap two samples at a time:
cycle 0-61: sample 1+2
cycle 62-123: sample 2+3
cycle 124-185: sample 3+4
Not as good as a true double frequency, but probably an improvement. Maybe it is possible to do some filtering to improve it further?

I was also wondering if it was possible instead to benefit from the idea of playing at half volume, due to way the volume control works on amiga. If, say, you run at a period of 128 (conveniently a multiple of 64), volume of 32, and you have the second channel offset by 32, it would be
cycle 0-31 sample 1
cycle 32-63 sample 2
cycle 64-95 sample 1
cycle 96-127 sample 2
cycle 128-159 sample 3
cycle 160-193 sample 4
This may also be an improvement?

[mc6809e]

Originally Posted by Mrs Beanbag

i was wondering lately about the possibility of putting them *deliberately* out of sync in order to "fake" a doubled sample frequency.

http://eab.abime.net/showthread.php?...la+audio+phase

[Vot]

Originally Posted by mc6809e

http://eab.abime.net/showthread.php?...la+audio+phase

Seriously every time I read threads with conjecture like that about the inner workings of the chips I wonder why the Amiga community doesn't get together to fundraise to have the chipset decapped and photographed.

[Hewitson]

Probably because we already understand enough about the chip to be able to enable almost 100% compatible emulation. If the Amiga community was going to contribute a large amount of money to a project, this wouldn't be the most beneficial one.

[Vot]

Originally Posted by Hewitson

Probably because we already understand enough about the chip to be able to enable almost 100% compatible emulation. If the Amiga community was going to contribute a large amount of money to a project, this wouldn't be the most beneficial one.

I didn't mean just paula, hence I said chipset.,and the decapping and photographing is probably not as expensive as you think.

[Thorham]

Originally Posted by Hewitson

If the Amiga community was going to contribute a large amount of money to a project, this wouldn't be the most beneficial one.

It would be if the whole chipset would be reverse engineered. With those printable chips we're going to have in the near future, we would be able to print Amiga chips!

[Hewitson]

Originally Posted by Thorham

It would be if the whole chipset would be reverse engineered. With those printable chips we're going to have in the near future, we would be able to print Amiga chips!

There would be little demand for that as they rarely fail and there's already a decent supply of most of them.

Surely reproducing the 060 would be a far more beneficial project.

[mc6809e]

Originally Posted by Hewitson

There would be little demand for that as they rarely fail and there's already a decent supply of most of them.

Surely reproducing the 060 would be a far more beneficial project.

It would be nice to see how the blitter is designed, though.

There may even been some some new tricks made possible by knowing what happens when switching modes, channel use, etc while the blitter is running.

For example, there is one situation known where D channel writes can occur back-to-back. It happens at the conclusion of a sequence that uses all channels.

Perhaps there's some way by timing a mode switch just right to get a full speed clear.

It's difficult to know if that's possible, though, without a better characterization of the blitter's internal logic.

[Thorham]

Originally Posted by Hewitson

There would be little demand for that as they rarely fail and there's already a decent supply of most of them.

Except for the fact we'd be able to produce new Amigas. New REAL Amigas.

[pandy71]

So anyone to set kickstarter/other fundraising?
I will put money as current way of emulation doesn't solve all problems (like GCR mode in Paula, Line mode in blitter etc), there is plenty we don't know about Amiga HW, side to this decapping 68060 have no sense, better target is 68020 as there is full MB68k ISA representative (bitfield instructions removed after 020) - 030,040,060 are 020 after castration and on steroids (cache, pipeline etc).

All them use should be relatively easy to map to schematics as none of them (AFAIK) use anything bellow 600nm so visible light is sufficient.

Then one chip ASIC can be created (with improved for example RAM bus thus 50+ old CHIP bandwidth).

http://www.degate.org/

btw 8520 is already available... http://siliconpr0n.org/map/mos/8520/top_metal_mit20x/

[Toni Wilen]

I am only interested with Agnus internals: blitter, bitplane and copper state machines (in order of importance).

Some little interest also in Denise's bitplane/sprite priority logic. (Why invalid priority values do that strange color selection effect, used for example in SWIV)

I also don't see point in decapping higher CPU models. You only need to know internal logic if you want to make 100% timing compatible CPU and that kind of compatibility is only needed for something like basic A1200. Hardware or emulation.

[Vot]

Originally Posted by pandy71

So anyone to set kickstarter/other fundraising?
I will put money as current way of emulation doesn't solve all problems (like GCR mode in Paula, Line mode in blitter etc), there is plenty we don't know about Amiga HW, side to this decapping 68060 have no sense, better target is 68020 as there is full MB68k ISA representative (bitfield instructions removed after 020) - 030,040,060 are 020 after castration and on steroids (cache, pipeline etc).

All them use should be relatively easy to map to schematics as none of them (AFAIK) use anything bellow 600nm so visible light is sufficient.

Then one chip ASIC can be created (with improved for example RAM bus thus 50+ old CHIP bandwidth).

http://www.degate.org/

btw 8520 is already available... http://siliconpr0n.org/map/mos/8520/top_metal_mit20x/

I personally would put some cash into such a project, it would be great for you guys to get the final pieces of the puzzle to help fix those last few winuae bugs, and for others to do all sorts of crazy asic's/fpga's projects.

It might be interesting asking guru from (http://members.iinet.net.au/~lantra9...cap/index.html) if he would be interested in sharing his contact for decapping as he gets good rates. (Not that other places don't do it). He might want a copy of the die shots as he seems to have the keyboard encoders for decapping already.

He however seems a bit of a prickly pear to deal with any email could have you added to his stupid email list lol.

[Hewitson]

Originally Posted by Thorham

Except for the fact we'd be able to produce new Amigas. New REAL Amigas.

For the chip decapping, chip design and manufacturing, case manufacturing, and other costs, youd be looking at several hundred thousand dollars.

[pandy71]

Originally Posted by Hewitson

For the chip decapping, chip design and manufacturing, case manufacturing, and other costs, youd be looking at several hundred thousand dollars.

Perhaps less but everything depends how many high quality work can be performed voluntarily.

Example prices are for example on: http://cmp.imag.fr/products/ic/?p=prices

Seem that 180 - 130nm are reasonable priced and should allow to design 68060 like with clock around 1GHz.

It should be possible to decap and collect photo for each layer for most of Amiga custom chips well bellow 10 - 20k E. With such pictures real schematics can be achieved relatively easy, partially automatic way.

It must be clear to everyone that achieving clocks for FPGA 68060 like implementation higher than 300 - 500MHz probably will be not possible.

CPU ASIC can be interesting not only for Amiga community but i assume Atari and perhaps Mac's. IP of Motorola need to be also solved.

Most challenging task is design verification...