UHRES? Mistery/curiosity - any explanation?

[ross]

Originally Posted by Solo Kazuki

There is method mentioned here to ommit this.

Read better what chb wrote: "The maximum DMA sample rate* is tied to the horizontal frequency"
In the linked document there is a DMA one, other not.
It is not specified in detaill but the only possible way when is written "DMA audio playback is limited to a maximum output rate of 28867 values per channel (PAL: 28837) per second totaling 57674 (PAL: 57734) values per second on each stereo output" is to temporally interleave and synchro two samples from two channels in the same stereo voice.
Not trivial as it sound. and resulting sound can delude you, because how Paula PWM works.
Second method is what Toni already mentioned in this same thread: CPU intensive and non-DMA.

Theoretically Paula can emit sounds at a frequency of 1.77Mhz (PAL) (a bare square wave) but there are two impassable limits:
1) Volume is implemented with PWM technique so for periods less than 64 (possible volume steps available) you are forced to use the maximum volume.
This corresponds to a frequency of 55420Hz (PAL).
2) At output stage it has 2 filters and one cannot be deactivated.
This does not mean that it cannot emit high frequency harmonics but the sound is colored.
And this filter, variable channel frequency and volume PWN are responsible for Paula unique sound

Also it's written here that D-Sam AMOS extension could play samples in 56kHz.

No one doubts that we can play at 56KHz (with different techniques).
But where is technical details?
I seriously doubt there is something new here..

Edit: Anyway, there is only just theory for now that UHRES trick will do this, isn't?

The "UHRES trick" simply makes you available a precise DMA counter.
What you do with it depends on you (and it may also be of no use)

[Retro1234]

for an idiot like myself what is UHRES?

[Rotareneg]

An undocumented feature in ECS Agnus and AGA Alice that is suspected to have been intended to allow a high resolution video output, possibly similar to the A2024 monitor but integrated into the computer. As it stands, there's no hardware to use this feature and it's not clear how it should work, or even if it does actually work as it presumably was meant to.

Does anyone know anything about the history of the Amber chip and rest of the scan doubler? I was just wondering if maybe it was originally intended for this UHRES function and then ended up being cut down to just scan doubling/deinterlacing.

[Retro1234]

Thanks for the explanation

Originally Posted by Rotareneg

An undocumented feature in ECS Agnus and AGA Alice that is suspected to have been intended to allow a high resolution video output, possibly similar to the A2024 monitor but integrated into the computer. As it stands, there's no hardware to use this feature and it's not clear how it should work, or even if it does actually work as it presumably was meant to.

Does anyone know anything about the history of the Amber chip and rest of the scan doubler? I was just wondering if maybe it was originally intended for this UHRES function and then ended up being cut down to just scan doubling/deinterlacing.

[pandy71]

Originally Posted by ross

temporally interleave and synchro two samples from two channels in the same stereo voice.
Not trivial as it sound. and resulting sound can delude you, because how Paula PWM works.

Nobody knows how PWM Paula works (AFAIK nobody made REI on Paula - decap + https://degate.org/ ) - PWM can be applied to DAC reference or to 8 bit register at the DAC input or to analog output (CMOS switch like 1/4 of the 4066) switching between ground and DAC analog output. Multiple ways to get same result.
Also as visible on many Paula die photo - there are 4 DAC's thus no time sample interleaving (weird as die could be half of the current size).

Originally Posted by ross

Second method is what Toni already mentioned in this same thread: CPU intensive and non-DMA.

There is third way - Copper driven no DMA audio (Copper DMA used to feed audio data), also perhaps another way is like set Audio DMA to high refresh rate and feed data trough Copper... many possibilities - one thing is mandatory steady, no jitter data feed.

http://eab.abime.net/showthread.php?t=65348

Originally Posted by ross

Theoretically Paula can emit sounds at a frequency of 1.77Mhz (PAL) (a bare square wave)

Well if you modify audio buffer word frequently then it can be more than two samples (Copper driven Audio DMA?)

Originally Posted by ross

1) Volume is implemented with PWM technique so for periods less than 64 (possible volume steps available) you are forced to use the maximum volume.
This corresponds to a frequency of 55420Hz (PAL).
2) At output stage it has 2 filters and one cannot be deactivated.
This does not mean that it cannot emit high frequency harmonics but the sound is colored.

Not so fast - you can use volume as sample (so 6 bit PCM) and global level as 2 byte word with high sample rate.
Low pass filter should reconstruct valid samples (PWM*PWM) - problem is probably hidden in relatively slow OPAMP thus at least first stage of this filter should be passive LC design - like in first Amiga a.k.a. Amiga 1000
(or replace current OPAMP with very fast one) btw Copper can be used to keep this synchronized and accurate i.e. low jitter - low jitter is essential to avoid "coloration".

Originally Posted by ross

And this filter, variable channel frequency and volume PWN are responsible for Paula unique sound

Using PWM (or Delta Sigma) to control LPF you can have some form of switched "capacity" filter i.e. variable LPF. CPU intensive but doable.
And for Paula "uniqueness" i would blame too low sample rate of audio samples (too many aliasing) - outcome of small CHIP RAM.

Originally Posted by chb

As the majority of these registers (pointers/modulo/identifiers) was probably never used by anything, and will not be used in the future, there shouldn't be a problem to reuse them in case you'd want to design your next-gen backwards-compatible chipset. AAA would have removed UHRES registers anyway (as per AAA documentation).

Problem is hidden in timing - banging those registers alter chipset timing so not usable.
AAA would be unavoidable fail anyaway. Instead insane AAA complexity, CBM should expose original chipset digital video (as form of overlay like blit bitmap) and use PCI based video card... secure legacy software and open architecture for future.

[ross]

Yup, much you have written are possible (I've simplified for a pretty standard usage or better "relatively" advanced).
EDIT: and yes Paula PWM is a mistery but
http://eab.abime.net/showpost.php?p=...8&postcount=81

I seem to have read the thread of which you posted the link, very interesting.

In the distant past I made a replayer through Copper so I know that's possible, I've simply omitted it

I did not understand this passage though:
Well if you modify audio buffer word frequently then it can be more than two samples (Copper driven Audio DMA?)
Can you elaborate? There is enough time to feed Paula for a frequency >1.7Mhz?

[chb]

Originally Posted by pandy71

Using PWM (or Delta Sigma) to control LPF you can have some form of switched "capacity" filter i.e. variable LPF. CPU intensive but doable.

Modulation of the LPF is something I was thinking of also. The output however may be a bit hard to predict (and varying between models). Best thing to check probably would be either an Amiga with an oscilloscope/frequency analyzer hooked up to the audio out or a simulation of the filter circuit using PSpice or the like. The filter bit is however on the CIA and its slow E-clock, unfortunately, which limits the achievable PWM rate.

Originally Posted by pandy71

Problem is hidden in timing - banging those registers alter chipset timing so not usable.

Banging those registers I mentioned (UHRES specific pointers/modulos/identifiers) should not alter chipset timing at all. You can try it yourself it you've got a real ECS/AGA Amiga around. Anyway, I still don't see the point why it matters for compatibility to change registers no one ever used.

[chb]

Maybe not strictly UHRES related, but as it concerns ECS and may (or not) give some clues about UHRES, I'll post it here:
I noticed something interesting when having a look with the UAE debugger at the A2024 JumpStart disk, which is a special WB disk containing kick 1.4-beta code (exec v35.6, graphics 35.15, intution 35.45) to support the A2024 monitor and it's higher resolution. It is from 1988.

Now what's interesting about it? It reads VPOSR for the Agnus revision, but also DENISEID. The latter register was only introduced with the ECS Denise. It checks for value 0xfc (ECS Denise 8373) and 0xfe (according to this document, also from 1988 btw., a prototype Denise numbered 8369). Both values result in the same operation (bit set in memory, probably some structure like GfxBase->ChipRevBits0), so one could speculate that they were largely functional identical.

I only had a brief look, and my 68000 assembler skills are really rusty, so atm I could not see what it's used for. At least I do not see any writes to the UHRES related registers. But there may still be a chance that something is burried in some code that they failed to remove and that is never executed. It may be, of course, just contain some support for the known ECS enhancements or nothing at all.

It's rather stunning that Commodore had the ECS Agnus and Denise already in 1988 and maybe even a bit earlier, judging from the 8369 prototype mentioned in the above doc, and did not release it officially until mid-1990 with the A3000...

[pandy71]

Originally Posted by ross

I did not understand this passage though:
Well if you modify audio buffer word frequently then it can be more than two samples (Copper driven Audio DMA?)
Can you elaborate? There is enough time to feed Paula for a frequency >1.7Mhz?

Based on HRM if Audio DMA can't feed sufficiently fast new data to AUDxDAT then state machine repeat last word (i.e. 2 bytes/samples). So with proper cycle interleaving and perhaps some trick to cheat state machine Copper could be source for missing word feed to the AUDxDAT creating pseud-DMA mode (once again low jitter is crucial to audio quality and Paula lacks real FIFO).

Personally i would design Paula in different way, use NCO instead counter (so provide very fine AUDxPER even for 16 bit tuning word - assuming 20 - 24 bit NCO with few low and perhaps high bits hardwired), i would do only 2 physical DAC's and use time sharing (interleaving) to support 4 channels on those DAC's, perhaps add some PANorama register (as such provide source location between L and R channel)...

Anyway Paula was breakthrough in computer world - i think good example how Amiga (and Paula) inspired artist is music of the Susumu Hirasawa
[ Show youtube player ]
or
[ Show youtube player ]
btw This is last time He used A4000 with Bars & Pipes (so not only Paula but also MIDI).

Originally Posted by chb

Modulation of the LPF is something I was thinking of also. The output however may be a bit hard to predict (and varying between models). Best thing to check probably would be either an Amiga with an oscilloscope/frequency analyzer hooked up to the audio out or a simulation of the filter circuit using PSpice or the like. The filter bit is however on the CIA and its slow E-clock, unfortunately, which limits the achievable PWM rate.

White noise in loop and PC with audio line input will be perfect tool to analyse this. After averaging spectrum analyzer should show exact LPF characteristic.
Yes, software PWM will be slow but also response of filter will be limited due capacitance so i assume few hundred Hz should be sufficient to control LPF.

Originally Posted by chb

Banging those registers I mentioned (UHRES specific pointers/modulos/identifiers) should not alter chipset timing at all. You can try it yourself it you've got a real ECS/AGA Amiga around. Anyway, I still don't see the point why it matters for compatibility to change registers no one ever used.

For 2 - 3 oncoming years i will be unable to access my HW - need to finish construction of my home.

[ross]

Originally Posted by pandy71

Based on HRM if Audio DMA can't feed sufficiently fast new data to AUDxDAT then state machine repeat last word (i.e. 2 bytes/samples). So with proper cycle interleaving and perhaps some trick to cheat state machine Copper could be source for missing word feed to the AUDxDAT creating pseud-DMA mode (once again low jitter is crucial to audio quality and Paula lacks real FIFO).

mmh, transition betwheen states (for the data output ) occurs whenever the period counter counts down to one.
How you can force this transition and reload AUDxDAT on the very bandwidth limited internal bus and also reset the IRQ?
I don't think it's possible but I'd be happy to be denied

Personally i would design Paula in different way, use NCO instead counter (so provide very fine AUDxPER even for 16 bit tuning word - assuming 20 - 24 bit NCO with few low and perhaps high bits hardwired), i would do only 2 physical DAC's and use time sharing (interleaving) to support 4 channels on those DAC's, perhaps add some PANorama register (as such provide source location between L and R channel)...

Yes, PAN is a lack

Anyway Paula was breakthrough in computer world

[pandy71]

Originally Posted by ross

mmh, transition betwheen states (for the data output ) occurs whenever the period counter counts down to one.
How you can force this transition and reload AUDxDAT on the very bandwidth limited internal bus and also reset the IRQ?
I don't think it's possible but I'd be happy to be denied

Re-arm Audio DMA with Copper? - place word in AUDxDAT then arm audio DMA? or in opposite way? first trig Audio DMA with single word length in AUDxLEN and sample placed in AUDxDAT - key to high quality audio is stable sample timing - such regular timing can be provided only trough DMA

I think on other approach - using two channel but in special pattern - sample sequence split on odd and even samples, form word made from odd byte + 0 (null) on one channel and on second channel even sample + 0 - sequence will be like 0;odd;0;even;0;odd;0;even;0;odd;0;even...

Originally Posted by ross

Yes, PAN is a lack

PAN and NCO - for N bit NCO frequency resolution uniformly distributed across whole frequency range will be:

@N=16 bit (fit in current register map 1:1) - 54.1213226318359Hz
@N=20 bit 3.38258266448975Hz
@N=24 bit 0.211411416530609Hz
This means no problem with CD audio playout (44.1/22.05kHz vs Amiga AUDxPER)

btw same rule for UART...

[Rotareneg]

Alice schematics have shown up online and include logic for the UHRES mode on page 8: http://eab.abime.net/showthread.php?p=1444496

[Toni Wilen]

It confirms what we have already found. Dual switches between normal hpos counter and separate hhpos counter. Has 2 DMA channels (BPLHDAT and SPRHDAT), priority above copper but below bitplanes etc..