UHRES? Mistery/curiosity - any explanation?

[Toni Wilen]

DMACON was set because I had normal bitplane active when testing.

And I mixed $78/$7a, retested and fixed.. Also noticed that if only sprite or bitplane is active, unused cycle(s) are free.

[Toni Wilen]

DUAL tested. It also works.

If BEAMCON0 DUAL is set, HTOTAL becomes max horizontal length for UHRES, if it is smaller than current custom chipset mode, 7A/78/7A sequence happen every HTOTAL cycles. (=not anymore synced to normal scan lines)

In this case 7A/78/7A can happen without extra cycle(s) between them because there is no refresh cycles that have higher priority.

It still can steal copper cycles but not normal bitplane cycles.

EDIT: Easy to test without logic analyzer, just set DUAL, HTOTAL=0 and enable UHRES. Copper loses almost all cycles

EDIT2: HHPOSR appears to count all the time, even when DUAL or UHRES is disabled. Interesting programmable DMA cycle synced counter, just set DUAL without UHRES and change HTOTAL to adjust max count before wrap around. Without affecting normal display. Unfortunately range is only 0 to 255.

[ross]

Originally Posted by Toni Wilen

EDIT2: HHPOSR appears to count all the time, even when DUAL or UHRES is disabled. Interesting programmable DMA cycle synced counter, just set DUAL without UHRES and change HTOTAL to adjust max count before wrap around. Without affecting normal display. Unfortunately range is only 0 to 255.

Intriguing, this can be used for some hard CPU synced effects, independent from processor speed, but only on AGA (normally OCS and ECS go in pairs, so..).



EDIT:
Not that you can't do even on OCS with other methods, but it would be more complicated on fast processors.
See for example Lionheart where the programmers have released a later version just to solve video/CPU synchronization problems (without settling down completely..).

[chb]

@Toni: Great find! To me from your investigation it looks like UHRES is fully implemented and works like documented so far.

Funny how long it has been sitting there without ever being used...

BTW, not really UHRES related, but if you'd enable VARVBEN in BEAMCON0, and setting HTOTAL to some small value, couldn't you then get higher frequency dma audio? With a minimum value of probably $16 you'd get ~325 kHz. Display of course completely disabled, and video syncs messed up, unless you can somehow run them from the non-variable beam counter - from the description it looks a bit like CSCBEN could do that?

EDIT: Interesting question also: from which beam counter do the copper and sprite (non-UHRES) comperators run? The fixed primary one or HHPOS?

[Toni Wilen]

Originally Posted by chb

@Toni: Great find! To me from your investigation it looks like UHRES is fully implemented and works like documented so far.

Except what UHRES bitplane and sprite pointers do? I assumed content would appear in data bus but data bus is idle (but there is only one bitplane cycle so where the other half of address would go?)

Why would Agnus internally do modulo addition if nothing sees the address?

EDIT: Perhaps it comes out of Agnus address bus? It would be the most logical option. Unfortunately I don't have enough probes to check it and I really don't want to move them around..

Funny how long it has been sitting there without ever being used...

I always assumed it didn't exist. Would have been really easy to confirm that there is something by simply polling HHPOSR.. (which mirrors normal HSYNC counter by default).

BTW, not really UHRES related, but if you'd enable VARVBEN in BEAMCON0, and setting HTOTAL to some small value, couldn't you then get higher frequency dma audio? With a minimum value of probably $16 you'd get ~325 kHz. Display of course completely disabled, and video syncs messed up, unless you can somehow run them from the non-variable beam counter - from the description it looks a bit like CSCBEN could do that?

I think it would work but I am not sure about CSCBEN. BEAMCON0 has so many never used bit combinations and documentation is not very clear..

Interesting question also: from which beam counter do the copper and sprite (non-UHRES) comperators run? The fixed primary one or HHPOS?

Normal primary. HHPOS seems to be only used for UHRES. Chipset display was perfectly normal even when HTOTAL in DUAL mode was zero or one.

[ross]

Originally Posted by chb

BTW, not really UHRES related, but if you'd enable VARVBEN in BEAMCON0, and setting HTOTAL to some small value, couldn't you then get higher frequency dma audio?

, this is the usual way to break-up 29 Khz max frequency.

Audio applications are the first thing that came to my mind when I read Toni's post.
With the 'new' DMA counter you can feed manually AUDxDAT for a very consistent high frequency play.

But you wouldn't have time to do anything else since the counter should be polled .. (well, probably some copper effects).

[chb]

Originally Posted by Toni Wilen

Except what UHRES bitplane and sprite pointers do? I assumed content would appear in data bus but data bus is idle (but there is only one bitplane cycle so where the other half of address would go?)

Why would Agnus internally do modulo addition if nothing sees the address?

AFAIU, data bus content is not needed, only the DRAM address bus value if it works like Gorf assumed. RGA value triggers the transfer mode of the VRAM, the address tells the VRAM with ROW to transfer to SAM, (for bpl, for sprite it seems improbable that they read two complete ROWs every scanline, no idea how it would work). I suppose it doesn't matter what is on the data bus during that operation.

Did you also check address bus value or only the data bus?

Originally Posted by Toni Wilen

I think it would work but I am not sure about CSCBEN. BEAMCON0 has so many never used bit combinations and documentation is not very clear..

Yep, it reads like being written by someone who likes good riddles.

Originally Posted by Toni Wilen

Normal primary. HHPOS seems to be only used for UHRES. Chipset display was perfectly normal even when HTOTAL in DUAL mode was zero or one.

Ah, I was thinking that AGA/ECS modes with non-standard timing (Productivity or Euro36/72, maybe also dblPAL/NTSC) also run from the variable beam counter. But I think I misread the BEAMCON0 documentation:

VARBEAMEN
Enables the variable beam counter comparators to operate
(allowing different beam counter total values) on the main horiz
counter. It also disables hard display stops on both horizontal
and vertical.

It probably means it uses HSSTRT etc. on the primary beam counter, not the secondary counter for the main display. But then, how does it work with e.g. Euo72 (24 kHz) mode, if the beam counter is quite out of sync with the actual display? Very confusing.

[Toni Wilen]

Originally Posted by ross

, this is the usual way to break-up 29 Khz max frequency.

Audio applications are the first thing that came to my mind when I read Toni's post.
With the 'new' DMA counter you can feed manually AUDxDAT for a very consistent high frequency play.

But you wouldn't have time to do anything else since the counter should be polled .. (well, probably some copper effects).

Non-DMA audio does not need external sync, just poll INTREQR, when audio interrupt is set, clear it in INTREQ (which is needed anyway, AUDxDAT write does nothing if intreq bit is already set), then write to AUDxDAT. Repeat.

It works without glitches (as long as CPU is fast enough) because interrupt comes when first sample of AUDxDAT goes to DAC. You have 2xperiod cycles to update next AUDxDAT.

[Toni Wilen]

Originally Posted by chb

Did you also check address bus value or only the data bus?

Data only, don't want to touch my "logic analyzer a500" too much..
But address bus makes sense (I forgot about it completely..)

Ah, I was thinking that AGA/ECS modes with non-standard timing (Productivity or Euro36/72, maybe also dblPAL/NTSC) also run from the variable beam counter. But I think I misread the BEAMCON0 documentation:

It probably means it uses HSSTRT etc. on the primary beam counter, not the secondary counter for the main display. But then, how does it work with e.g. Euo72 (24 kHz) mode, if the beam counter is quite out of sync with the actual display? Very confusing.

Programmed mode use HSSTRT, HTOTAL etc.. BEAMCON0 VARHSYEN switches to ECS only horizontal position registers, VARVSYEN is same for vertical.

EDIT: VARBEAMEN enables hsync and vsync HTOTAL/VTOTAL comparisons against normal counters (instead of using PAL/NTSC hard stops).

VARVHSYEN and VARVSYEN enables output of variable hsync and vsync signals (including blanking).

No idea about VARVBEN. (HARDDIS, LPENDIS, LOLDIS, VARVSYEN, VARHSYEN, VARBEAMEN, DUAL, PAL are known)

EDIT2: VARVBEN is known, it simply switches Agnus strobe register generation to use variable vsync values (instead of PAL/NTSC built-in)

[chb]

Originally Posted by ross

, this is the usual way to break-up 29 Khz max frequency.

Audio applications are the first thing that came to my mind when I read Toni's post.
With the 'new' DMA counter you can feed manually AUDxDAT for a very consistent high frequency play.

But you wouldn't have time to do anything else since the counter should be polled .. (well, probably some copper effects).

Yeah, I know, but I did not realize that it's not limited to 56 kHz. And that it may not be hardwired to display sync if there is a possibility to use the standard sync timing regardless of HTOTAL. But the method you propose is surely more useful than what I wrote which would be messing up the display totally as collateral damage.

[chb]

Originally Posted by Toni Wilen

Data only, don't want to touch my "logic analyzer a500" too much..

Right, I think UHRES is not that important!

Originally Posted by Toni Wilen

No idea about VARVBEN. (HARDDIS, LPENDIS, LOLDIS, VARVSYEN, VARHSYEN, VARBEAMEN, DUAL, PAL are known)

From the documentation it seems to me like it triggers a vblank somewhere in the middle of the standard display, to allow higher display refresh rates than 50/60 Hz:

VARVBEN
Use the comparator generated vertical blank (from VBSTRT, VBSTOP)
to run the internal chip stuff-sending RGA signals to Denise,
starting sprites,resetting light pen. It also disables the hard
stop on the vertical display window.

So it should be always set for non-standard (31 kHz) screens?

Oh, and i misread it the whole time - I assumed it is about horizontal blank, so scrap everything I wrote about VARVBEN in the posts before.

[ross]

Originally Posted by Toni Wilen

Non-DMA audio does not need external sync, just poll INTREQR, when audio interrupt is set, clear it in INTREQ (which is needed anyway, AUDxDAT write does nothing if intreq bit is already set), then write to AUDxDAT. Repeat.

It works without glitches (as long as CPU is fast enough) because interrupt comes when first sample of AUDxDAT goes to DAC. You have 2xperiod cycles to update next AUDxDAT.

How about a mixed DMA/non-DMA setup?
Suppose a normal AUDxLC and AUDxLEN but AUDxPER=62 and a standard PAL/NTSC video, then start Audio DMA.
If you feed AUDxDAT exactly every 248DMA periods (62x4) with the CPU, can you effectively double the frequency? (PAL 57,2Khz in this case)
Obviusly with interleaved audio data.

Actually there is a 'drift' due to 227/228 DMA cycles/line vs 248 but you can 'adjust' a CPU write when needed.

Post-lunch talks

EDIT:
Only an academic question, it is certainly not something to be implemented..

[pandy71]

Originally Posted by Gorf

I don’t think the color registers in VRAM are working as a CLUT ... at least I can not imagine how this should work...

Edit:
Yes it is like the description says: these "color registers" are just a fancy fill mode ... 4-bit wide pattern of any kind, not just color.

See datasheet for the 44C251:
https://img.ozdisan.com/ETicaret_Dosya/8560_3213072.pdf

But as said before: I think to remember some videochips being able to load their clut entries via vram automatically...

True, i was wrong - this feature can be used to emulate CLUT but it is not real CLUT, AFAIR it can be used by TMS340x0 family together with external Truecolor RAMDAC - need to dig on this - should have some datasheet/application note somewhere.

After reading Toni discoveries i must say overall fact that UHRES is implemented mean register address can't be used by something else... bad news. Seem indirect addressing is only way to add more registers and provide backward compatibility.

[turrican3]

And for a non coder where all of this goes ??
Or how it could be use in a game or an application ???
What could be done with it that none coders can ear or see ??
I try to understand but without the knowledge it's impossible for a vanilla human.

[chb]

Originally Posted by pandy71

T
After reading Toni discoveries i must say overall fact that UHRES is implemented mean register address can't be used by something else... bad news. Seem indirect addressing is only way to add more registers and provide backward compatibility.

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).

Originally Posted by turrican3

And for a non coder where all of this goes ??
Or how it could be use in a game or an application ???
What could be done with it that none coders can ear or see ??
I try to understand but without the knowledge it's impossible for a vanilla human.

Let's see; I don't think we will see a lot of things using it. Maybe, as Ross pointed out, the additional beam counter can be used for audio playback at higher/more flexible sample rates or some demo effects that need exact synchronisation between CPU and display. The other features seem to be rather pointless without the additional hardware they were supposed to use, but there might be some creative programmer to prove me wrong.

[Solo Kazuki]

Originally Posted by chb

Maybe, as Ross pointed out, the additional beam counter can be used for audio playback at higher/more flexible sample rates

That's already done. You can use up to about 56kHz (x2 of 28kHz limit) playback with using 30kHz screen modes (DblPAL/DblNTSC etc) or using this patch.

[ross]

Originally Posted by Solo Kazuki

That's already done. You can use up to about 56kHz (x2 of 28kHz limit) playback with using 30kHz screen modes (DblPAL/DblNTSC etc) or using this patch.

The purpose is to use 15khz screens.

About Cyber56khz, from the .readme:

Requirements
------------
CyberGraphX V3

Originally Posted by pandy71

After reading Toni discoveries i must say overall fact that UHRES is implemented mean register address can't be used by something else... bad news. Seem indirect addressing is only way to add more registers and provide backward compatibility.

I've no idea what your project and relative limitations are, but can't you maybe add RGA lines?

EDIT: hmm, and you have to find a way to solve mirror zones incompatibilities
(a register in the old mapping that tells you if you can use the new ones, so you can fork code)

[Solo Kazuki]

Originally Posted by ross

About Cyber56khz, from the .readme:

Requirements
------------
CyberGraphX V3

That's not the problem, at least for AGA. But not tested if it works with both patches as it should.

[chb]

Originally Posted by Solo Kazuki

That's not the problem, at least for AGA. But not tested if it works with both patches as it should.

This won't work, how could it? The maximum DMA sample rate* is tied to the horizontal frequency (max. two samples per channel are loaded at the beginning of each scanline). The first patch you linked sets the horizontal frequency of the internal display to a higher value when CGX uses an external graphics card, e.g. when the internal display is not used. When you use the internal display in 15 kHz modes, it cannot work. Documentation of Cyber56khz mentions this btw.:

Ok , all that takes place is the little proggie sets the NOPASSTHROUGH
enviroment variable briefly , opens then closes a MULTISCAN:PRODUCTIVITY
screenmode.

It then resets the NOPASSTHROUGH variable leaving the AGA DMA channels
intact. They stay this way until a native Amiga display is opened again.

*without considering hypothetical hacks that may be or may be not possible by mis-using the UHRES DUAL mode

[Solo Kazuki]

Originally Posted by chb

The maximum DMA sample rate* is tied to the horizontal frequency

There is method mentioned here to ommit this.

Alternately, Paula may signal the CPU to load a new sample into any of the four audio output buffers by generating an interrupt when a new sample is needed; this allows for output rates that exceed 57 kHz per channel and increases the number of possible voices (simultaneous sounds) through software mixing.

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

Unlike AMOS, which can only handle samples at rates of up to 29 KHz, D-Sam can play back samples at a maximum of 56 KHz which - believe it or not - is a higher sampling rate than even a CD player can handle.

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