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,017
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 online now  
Old 13 September 2019, 19:10   #22
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,017
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 online now  
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,851
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 offline  
Old 14 September 2019, 13:26   #24
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 165
@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,017
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 online now  
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,851
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 offline  
Old 14 September 2019, 14:18   #27
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 165
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,017
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 online now  
Old 14 September 2019, 14:26   #29
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,017
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 online now  
Old 14 September 2019, 14:39   #30
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 165
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: 165
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,851
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 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 08:39.


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