New Universal Agnus 8372, 75 etc

[salteadorneo]

Paula's analysis is very interesting. Through the die, you can see all four audio channels. What I am not so clear about is that these are 7 DACs plus a sign, I see three very different blocks and four the same, but it is possible that it is what you say. Anyway, you could try to contact Glenn Keller, Paula's designer, in an interview he clearly says that Paula is 8bits audio, and that he was working with AAA, he spoke highly of Commodore's work on Mary, to answer any questions.

If Paula's scheme is what you say, I understand that more channels and more dacs could be added. If there are 7 plus sign blocks, it could be 15 plus sign blocks for the 16 bits of audio and even a few more blocks. And to the four basic blocks of the audio channels, some more could be added.
One question, could some simple DSP type or simple SIMD unit be added for sound management? It could have compressed audio decoding and audio channel mixing functions.

[nonarkitten]

Originally Posted by Gorf

I did not specify any frequency… this was just a example to illustrate the problem. Your "PCM" signal should be "PWM", I guess?

Yes, typo.

Originally Posted by Gorf

On PDM "zero" or "no output" is a clock signal, that averages to 0.5, that is why I inserted 10101010…
You cannot simply set the signal to 00000000… , since this is a maximum/minimum value in PDM.

No, there's no clock inserted in PDM.

[Gorf]

Originally Posted by nonarkitten

Yes, typo.


No, there's no clock inserted in PDM.

I know.... read as "a clock like signal" alternating between 0 and 1 at max frequency

When we are in the PDM realm and want to get our output signal to the middle (= silence), we need so send something that averages to 0.5
Because after the final D/A step 1111... is positive amplitude and 0000.... is negative amplitude - and 10101010.... is NO amplitude!

[nonarkitten]

Originally Posted by salteadorneo

Paula's analysis is very interesting. Through the die, you can see all four audio channels. What I am not so clear about is that these are 7 DACs plus a sign, I see three very different blocks and four the same, but it is possible that it is what you say.

I think the larger transistors are simply for power loading.

Originally Posted by salteadorneo

Anyway, you could try to contact Glenn Keller, Paula's designer, in an interview he clearly says that Paula is 8bits audio, and that he was working with AAA, he spoke highly of Commodore's work on Mary, to answer any questions.

Well, it's signed 8-bits. So 7-bit positive and 7-bit negative is technically 8-bit, but the literal DAC only has to be 7-bit with the sign inverting the level.

And this isn't about wish fulfillment, fantasy or recreating things that never existed, it's about recreating the original chips. I'm not interesting in more channels, more bit depths, integrated DSPs or any nonsense like that.

[nonarkitten]

Originally Posted by Gorf

I know.... read as "a clock like signal" alternating between 0 and 1 at max frequency

When we are in the PDM realm and want to get our output signal to the middle (= silence), we need so send something that averages to 0.5
Because after the final D/A step 1111... is positive amplitude and 0000.... is negative amplitude - and 10101010.... is NO amplitude!

The level in the "off" state doesn't matter. Current code sets the PWM off time to 0 for simplicity and that's fine. The problem with your example is that the sine wave is operating beyond the PWM frequency which is impossible on an Amiga. You might claim it doesn't matter -- it very much does, you're intentionally exaggerating the impact of the PWM. Yes, on the real Amiga as you approach the 55kHz PWM you will get distortion. We want that same distortion.

[pandy71]

Originally Posted by salteadorneo

Paula's analysis is very interesting. Through the die, you can see all four audio channels. What I am not so clear about is that these are 7 DACs plus a sign, I see three very different blocks and four the same, but it is possible that it is what you say. Anyway, you could try to contact Glenn Keller, Paula's designer, in an interview he clearly says that Paula is 8bits audio, and that he was working with AAA, he spoke highly of Commodore's work on Mary, to answer any questions.

7 bit sign/magnitude DAC is 8 bit DAC so Paula is 8 bit DAC.

Originally Posted by salteadorneo

If Paula's scheme is what you say, I understand that more channels and more dacs could be added. If there are 7 plus sign blocks, it could be 15 plus sign blocks for the 16 bits of audio and even a few more blocks. And to the four basic blocks of the audio channels, some more could be added.
One question, could some simple DSP type or simple SIMD unit be added for sound management? It could have compressed audio decoding and audio channel mixing functions.

Even if there was such plan from Commodore then it was not realized. But i agree - having ADPCM decoder on silicone and some bits to control this will allow Amiga efficiently to double sampling frequency and at the same time provide 16 bit dynamics (as 4 bit ADPCM can be decoded to 16 bit samples).

Originally Posted by nonarkitten

And this isn't about wish fulfillment, fantasy or recreating things that never existed, it's about recreating the original chips. I'm not interesting in more channels, more bit depths, integrated DSPs or any nonsense like that.

Well... you know... we are just poor dreamers refusing to accept reality that Amiga died almost three decades ago...
Anyway ADPCM decoder could be nice feature to be implemented...
And adding true arithmetic mode to Blitter (like multiplier)...

Sorry for all that fuzz above, thank you nonarkitten and kipper2k for all hard work, it is highly appreciated by everyone (i think).

[Gorf]

Originally Posted by nonarkitten

The level in the "off" state doesn't matter. Current code sets the PWM off time to 0 for simplicity and that's fine. The problem with your example is that the sine wave is operating beyond the PWM frequency which is impossible on an Amiga. You might claim it doesn't matter -- it very much does, you're intentionally exaggerating the impact of the PWM. Yes, on the real Amiga as you approach the 55kHz PWM you will get distortion. We want that same distortion.

Ok ... my point of view is from that old 14bit discussion and test and soundbites (some of them are REALLY good), were the limits of Paula were tested ... including using the highest sample frequency possible with DMA.

And while the distortion at lowest volume settings is of course clearly there it is less, than one might expect.

However this is probably not the normal use case anyways.

But still: nulling the PDM signal periodically is quite different, from what Paula does, since Paula pulls the signal back to the middle-line ....

Just for clarification, let's take your example, but using a square-wave as input:

PDM
0000000000000000000000000000000011111111111111111111111111111111000000000000000000000000000000001111
PWM
1111111111111111111111111111111100000000000000000000000000000000111111111111111111111111111111110000
OUT
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Now instead of just lowering the volume, we canceled out the signal completely :-/
This would not happen if we insert a 10101010 pattern instead of zeros:

OUT
0000000000000000000000000000000010101010101010101010101010101010000000000000000000000000000000001010

This gives us a slightly distorted square wave with halve the amplitude ...

Maybe all this does not matter and can not be heard anyways ... so I will stop this now ;-)

[nonarkitten]

Originally Posted by pandy71

Well... you know... we are just poor dreamers refusing to accept reality that Amiga died almost three decades ago...
Anyway ADPCM decoder could be nice feature to be implemented...
And adding true arithmetic mode to Blitter (like multiplier)...

I'm not dead-set against adding features that were present in the Amiga through peripherals or that existed in other systems of the time. Since we have pSRAM and 2X or 4X to all the chips, we can do a lot more, but what fits that's era-correct? Somethings which may "just work": WaveTable/MIDI emulation; deinterlacing; ECSv1 "RTG" emulation; 16-byte UART FIFO; 2x disk speeds for non-modded HD PC drives ... these are, to me, good additions.

Somethings that would just need a tiny utility: channel pan; 56kHz PCM without progressive mode; horizontal soft-filter; scan lines (off, 25%, 50% dimming or constant-brightness mode); fine volume mixing mode (7MHz bit stream); ... these are fine additions as long as it's just a "POKE" to switch or something like that.

The line is having to support NEW development. Anything beyond that has to be REALLY compelling to even be considered.

[nonarkitten]

Originally Posted by Gorf

But still: nulling the PDM signal periodically is quite different, from what Paula does, since Paula pulls the signal back to the middle-line ....

Yes, playing a perfectly phase aligned PCM stream with the PWM frequency will have different outputs as the original PDM was implemented (zeroing PWM). However, 010101 is not correct either, not without doubling the clock (at least). The correct method (as mentioned a FEW times now), is to go high-Z (tristate).

The simple method would be to just high-z on the volume PWM only. So the PDM outputs only 1's and 0's and we high-z that when the volume says to. That's a little abusive to the OpAmp, but it's a LOT closer to real Paula.

The next easiest way is to add one-bit of state to the PDM and only allow a change of one level from last. So it can go from 0->Z, Z->0, 1->Z and Z->1 but not from 1->0 or 0->1. This properly makes zero, zero since really, 0 is -1 since you're always sinking.

The last, and most correct way is to allow 1->0 and 0->1 if and only iff both channels are outputting the same level coincidentally. So if channels 1 and 2 both output a 0 after the last level being a 1 then we allow the zero-crossing.

[Gorf]

Originally Posted by nonarkitten

Yes, playing a perfectly phase aligned PCM stream with the PWM frequency will have different outputs as the original PDM was implemented (zeroing PWM). However, 010101 is not correct either, not without doubling the clock (at least).

Hence my suggestions earlier doing exactly that
(either with 8 clone signals per channel or even 64...)
(yes I know that this is wasteful ...)

The correct method (as mentioned a FEW times now), is to go high-Z (tristate).

The simple method would be to just high-z on the volume PWM only. So the PDM outputs only 1's and 0's and we high-z that when the volume says to. That's a little abusive to the OpAmp, but it's a LOT closer to real Paula.

OK

The next easiest way is to add one-bit of state to the PDM and only allow a change of one level from last. So it can go from 0->Z, Z->0, 1->Z and Z->1 but not from 1->0 or 0->1. This properly makes zero, zero since really, 0 is -1 since you're always sinking.

Yes.

The last, and most correct way is to allow 1->0 and 0->1 if and only iff both channels are outputting the same level coincidentally. So if channels 1 and 2 both output a 0 after the last level being a 1 then we allow the zero-crossing.

Probably unnecessary.

[nonarkitten]

Originally Posted by Gorf

Probably unnecessary.

Agreed. Must follow the KISS rule.

[salteadorneo]

First and foremost to avoid any kind of misunderstanding, I think this project is fantastic and if completed it would be a great milestone in the Amiga world. You have my deepest admiration.

Originally Posted by nonarkitten

Well, it's signed 8-bits. So 7-bit positive and 7-bit negative is technically 8-bit, but the literal DAC only has to be 7-bit with the sign inverting the level.

Obviously, seven bits plus a sign is eight bits, only that part of the discussion seemed a bit strange to me. In addition to a curious way of managing the data, if that is how these blocks act. That's why I suggested that you consult, if is possible, with Paula's creator to clear up any doubts.

Originally Posted by nonarkitten

And this isn't about wish fulfillment, fantasy or recreating things that never existed, it's about recreating the original chips. I'm not interesting in more channels, more bit depths, integrated DSPs or any nonsense like that.

On the other hand, you posted this on page four:

Originally Posted by nonarkitten

What could be done with Willoe alone:
- 16MB chip RAM (2MB addressable from 68K); this could allow Workbench, for example, to have it's screen not take any of the critical base 2MB
- 2x and 4x Blitter speed and Copper prefetch (non blocking)
- Note that the 3000 will use real chip RAM for the base 2MB and will need upgrading to 70ns FPM to support 2x and 4x AGA fetch modes

What could be done with Willoe and Xander (A500/A2000):
- up to 8MB of chip RAM addressable from 68K
- non-blocking CPU cycles for up-to double the CPU bandwidth

What could be done with Willoe and Faith (A500/A2000/A3000):
- AGA 2x and 4x display modes, double playfield and HAM8
- possible side-banding up to 50% of bitplane DMA freeing more cycles
- integrated scan doubler for VGA output

What could be done with Willoe and Harmonie (A500/A2000/A3000):
- Paula 2x and 4x audio and disk speeds
- Support for HD floppy speeds (60kbps)
- Support for either 112kHz 8-bit or 56kHz 16-bit audio

I guess the idea is to first have a working Paula and then evolve into Hermione.

I was simply suggesting adding a CPU-less channel mixing and audio decoding feature to the list of additions you posted previously. These advanced features that you posted seem very good to me and I don't think they change the spirit of Paula.


I find this thread very interesting and I will follow it with great interest. Thank you all for your efforts.

[nonarkitten]

Originally Posted by salteadorneo

First and foremost to avoid any kind of misunderstanding, I think this project is fantastic and if completed it would be a great milestone in the Amiga world. You have my deepest admiration.

Cool, thanks.

Originally Posted by salteadorneo

I guess the idea is to first have a working Paula and then evolve into Hermione.

I was simply suggesting adding a CPU-less channel mixing and audio decoding feature to the list of additions you posted previously. These advanced features that you posted seem very good to me and I don't think they change the spirit of Paula.


I find this thread very interesting and I will follow it with great interest. Thank you all for your efforts.

You're right, I need to dial back my own expectations too.

But let me clarify.

The DMA speed up is required for AGA compatibility and the way we're doing it, adding it to all three devices on all DMA ports and the CPU port costs "nothing." So might as well do it. This solves so much and will really speed up general use.

And as I've said, I'm not dead set against new features beyond base working set, but keep in mind that the iCE chips are tiny. So we need features that give us the most "bang for the buck."

[pandy71]

Originally Posted by nonarkitten

Somethings which may "just work":

WaveTable/MIDI emulation

Will be difficult - wavetable ROM with decent quality samples can be very big, also there can be issue with royalties (if ROM from some company like Roland will be used).
Same functionality can be added externally as it was in first place - today w RPi this is sub 50$ expanditure

Originally Posted by nonarkitten

deinterlacing; ECSv1 "RTG" emulation;

Deinterlacing require full buffer (so worst case scenario more than 5MiB of fast RAM) also tricky for non standard video modes.

Originally Posted by nonarkitten

16-byte UART FIFO

Should be not a problem but question is how it can be used today.

Originally Posted by nonarkitten

; 2x disk speeds for non-modded HD PC drives ... these are, to me, good additions.

HD FDD can be supported for today - only MFM encoder/decoder must be implemented on Paula so current DMA allocation slots can be left not altered.

Originally Posted by nonarkitten

Somethings that would just need a tiny utility: channel pan; 56kHz PCM without progressive mode; horizontal soft-filter; scan lines (off, 25%, 50% dimming or constant-brightness mode); fine volume mixing mode (7MHz bit stream); ... these are fine additions as long as it's just a "POKE" to switch or something like that.

Channel pan can be implemented easily, but going in this direction DDS (NCO) instead currently used divider seem to be more beneficial for audio and for UART. IMHO this is biggest PITA for Paula - instead using NCO as frequency source, regular binary divider was used so final effect is very poor frequency control - this could be appreciated by everyone. But this will fundamental shift paradigm...
Scanlines and CRT simulation is something not worth using HW resources but this is my personal opinion

Originally Posted by nonarkitten

The line is having to support NEW development. Anything beyond that has to be REALLY compelling to even be considered.

I agree and as such this is why i don't expect anything more than already existing functionality... but in future... since long time i think that overall Amiga community (not only EAB) should made some agreement on how to access those new features (create some repository for new bits allocation, addresses etc and coordinate this at some point to avoid conflicts) - this will simplify software developers life - for example UHRES status i feasibility to be used by other functionality (as for example $DFF000 space is limited but it could be nice to use Copper to control old and new features in compatible way).

[salteadorneo]

Right, the first thing is to get Paula to work. Although adding support for HD floppy drives would be nice. We would save ourselves modifying normal floppy drives. :-)

I'm looking at the schematics and prices of the ICEs40. You have the ICE40Up5 (5860 logic gates) at about 11 euros. I also see that this chip has eight DSPs and the ICE40Up3 (7 euros), with 2800 logic gates, has four DSPs. I don't know if they will be usable for this project or if they are elements for internal use of the FPGA. Looking at the specifications sheet, I think they would be usable.

3.1.7 sysDSP
The iCE40 UltraPlus family provides an efficient sysDSP architecture that is very suitable for low-cost Digital Signal
Processing (DSP) functions for mobile applications. Typical functions used in these applications are Multiply,
Accumulate, and Multiply-Accumulate. The block can also be used for simple Add and Subtract functions.
iCE40 UltraPlus sysDSP Architecture Features
The iCE40 UltraPlus sysDSP supports many functions that include the following:
- Single 16-bit x 16-bit Multiplier, or two independent 8-bit x 8-bit Multipliers
- Optional independent pipeline control on Input Register, Output Register, and Intermediate Reg faster clock
performance
- Single 32-bit Accumulator, or two independent 16-bit Accumulators
- Single 32-bit, or two independent 16-bit Adder/Subtracter functions, registered or asynchronous
Cascadable to create wider Accumulator blocks

The iCE40UL-1K does not have any DSP, it is very cheap (barely 4 euros), but it also has few gates. For the small price difference with the 3k, it may be more worth using the 3 or 5.

[pandy71]

Originally Posted by salteadorneo

I'm looking at the schematics and prices of the ICEs40. You have the ICE40Up5 (5860 logic gates) at about 11 euros. I also see that this chip has eight DSPs and the ICE40Up3 (7 euros), with 2800 logic gates, has four DSPs. I don't know if they will be usable for this project or if they are elements for internal use of the FPGA. Looking at the specifications sheet, I think they would be usable.

General rule is take biggest FPGA you can afford as 3..5 Euro difference is not worth wasted time or canceling project. Cost of development and time required to fit design in FPGA is way more costly than FPGA itself.

[kipper2k]

Originally Posted by pandy71

General rule is take biggest FPGA you can afford as 3..5 Euro difference is not worth wasted time or canceling project. Cost of development and time required to fit design in FPGA is way more costly than FPGA itself.

Yah, better to go with the oversized one first, physical size is the same, price not too different and future upgrades could always be an option

[nonarkitten]

Originally Posted by pandy71

Will be difficult - wavetable ROM with decent quality samples can be very big, also there can be issue with royalties (if ROM from some company like Roland will be used).

You know what? Forget I said it.

Originally Posted by pandy71

Deinterlacing require full buffer (so worst case scenario more than 5MiB of fast RAM) also tricky for non standard video modes.

Yeah, you're right, why'd I even put RAM on the board.

Originally Posted by pandy71

Should be not a problem but question is how it can be used today.

Consider it gone.

Originally Posted by pandy71

HD FDD can be supported for today - only MFM encoder/decoder must be implemented on Paula so current DMA allocation slots can be left not altered.

Current DMA only allows 30KB/s so great, off the table.

Originally Posted by pandy71

Channel pan can be implemented easily, but going in this direction DDS (NCO) instead currently used divider seem to be more beneficial for audio and for UART. IMHO this is biggest PITA for Paula - instead using NCO as frequency source, regular binary divider was used so final effect is very poor frequency control - this could be appreciated by everyone. But this will fundamental shift paradigm...

Yeah, I don't have PLL's to burn so not gonna happen.

Originally Posted by pandy71

Scanlines and CRT simulation is something not worth using HW resources but this is my personal opinion

Hey, your personal opinion turfed MIDI, 60KB/s floppy support, the UART FIFO, and scanlines, so keep it up. Hey, since scandoubling looks like ass to me without scanlines, I'll just take that out too.

Originally Posted by pandy71

I agree and as such this is why i don't expect anything more than already existing functionality... but in future... since long time i think that overall Amiga community (not only EAB) should made some agreement on how to access those new features (create some repository for new bits allocation, addresses etc and coordinate this at some point to avoid conflicts) - this will simplify software developers life - for example UHRES status i feasibility to be used by other functionality (as for example $DFF000 space is limited but it could be nice to use Copper to control old and new features in compatible way).

You know what? Have fun with your stock ECS.

[nonarkitten]

Originally Posted by salteadorneo

Right, the first thing is to get Paula to work. Although adding support for HD floppy drives would be nice. We would save ourselves modifying normal floppy drives. :-)

Sorry, paddy71 took that out. I agree it would be nice, but *those people* have to have their way.

Originally Posted by salteadorneo

I'm looking at the schematics and prices of the ICEs40. You have the ICE40Up5 (5860 logic gates) at about 11 euros. I also see that this chip has eight DSPs and the ICE40Up3 (7 euros), with 2800 logic gates, has four DSPs. I don't know if they will be usable for this project or if they are elements for internal use of the FPGA. Looking at the specifications sheet, I think they would be usable.

We cannot use the new iCE40's. Has to be the iCE65 L/P or iCE40 HX. Since we're apparently turfing everything, might as well just stick with the 1K's.

[nonarkitten]

Originally Posted by pandy71

General rule is take biggest FPGA you can afford as 3..5 Euro difference is not worth wasted time or canceling project. Cost of development and time required to fit design in FPGA is way more costly than FPGA itself.

Why? We don't need 8Kb when we're pulling out all the features. Denise fits on a 1K part fine.