English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 13 September 2019, 18:58   #21
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,112
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 is offline  
Old 13 September 2019, 19:10   #22
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,112
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.

Last edited by Toni Wilen; 13 September 2019 at 19:19.
Toni Wilen is offline  
Old 13 September 2019, 20:03   #23
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,986
Quote:
Originally Posted by Toni Wilen View Post
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..).

Last edited by ross; 13 September 2019 at 20:18.
ross is online now  
Old 14 September 2019, 13:26   #24
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
@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?

Last edited by chb; 14 September 2019 at 13:38.
chb is offline  
Old 14 September 2019, 13:46   #25
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,112
Quote:
Originally Posted by chb View Post
@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..

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

Quote:
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..

Quote:
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.

Last edited by Toni Wilen; 14 September 2019 at 14:14.
Toni Wilen is offline  
Old 14 September 2019, 13:49   #26
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,986
Quote:
Originally Posted by chb View Post
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).
ross is online now  
Old 14 September 2019, 14:18   #27
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by Toni Wilen View Post
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?

Quote:
Originally Posted by Toni Wilen View Post
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.

Quote:
Originally Posted by Toni Wilen View Post
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:
Quote:
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.
chb is offline  
Old 14 September 2019, 14:21   #28
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,112
Quote:
Originally Posted by ross View Post
, 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 is offline  
Old 14 September 2019, 14:26   #29
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,112
Quote:
Originally Posted by chb View Post
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..)

Quote:
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)

Last edited by Toni Wilen; 14 September 2019 at 15:03.
Toni Wilen is offline  
Old 14 September 2019, 14:39   #30
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by ross View Post
, 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 is offline  
Old 14 September 2019, 14:53   #31
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by Toni Wilen View Post
Data only, don't want to touch my "logic analyzer a500" too much..
Right, I think UHRES is not that important!
Quote:
Originally Posted by Toni Wilen View Post
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:
Quote:
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.
chb is offline  
Old 14 September 2019, 15:37   #32
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,986
Quote:
Originally Posted by Toni Wilen View Post
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..

Last edited by ross; 14 September 2019 at 15:58.
ross is online now  
Old 23 September 2019, 21:31   #33
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,685
Quote:
Originally Posted by Gorf View Post
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.
pandy71 is offline  
Old 24 September 2019, 02:37   #34
turrican3
Moon 1969 = amiga 1985

turrican3's Avatar
 
Join Date: Apr 2007
Location: belgium
Age: 43
Posts: 3,571
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.
turrican3 is offline  
Old 24 September 2019, 09:46   #35
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by pandy71 View Post
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).

Quote:
Originally Posted by turrican3 View Post
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.
chb is offline  
Old 24 September 2019, 09:57   #36
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 596
Quote:
Originally Posted by chb View Post
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.
Solo Kazuki is offline  
Old 24 September 2019, 10:04   #37
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,986
Quote:
Originally Posted by Solo Kazuki View Post
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


Quote:
Originally Posted by pandy71 View Post
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)

Last edited by ross; 24 September 2019 at 10:57. Reason: some additions
ross is online now  
Old 24 September 2019, 11:30   #38
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 596
Quote:
Originally Posted by ross View Post
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.
Solo Kazuki is offline  
Old 24 September 2019, 12:17   #39
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 171
Quote:
Originally Posted by Solo Kazuki View Post
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.:
Quote:
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
chb is offline  
Old 24 September 2019, 13:18   #40
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 596
Quote:
Originally Posted by chb View Post
The maximum DMA sample rate* is tied to the horizontal frequency
There is method mentioned here to ommit this.

Quote:
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.

Quote:
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?
Solo Kazuki is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Curiosity tygre support.Hardware 5 08 June 2011 09:27
Error explanation?? ORSM T support.Hardware 7 01 June 2007 07:36
code explanation BippyM Coders. General 19 01 May 2007 14:12
Microcosm CD32 curiosity Ian support.WinUAE 12 12 April 2007 16:03
A combination of boredom and curiosity! Mick_AKA Retrogaming General Discussion 21 03 July 2003 11:46

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08844 seconds with 15 queries