English Amiga Board


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

 
 
Thread Tools
Old 24 April 2020, 20:30   #1
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 220
timer.device:GetSysTime:UNIT_VBLANK not recognized

I'm trying to do some profiling of my 3D engine and need a detailed breakdown of all pipeline stages.


For that, historically, on Jaguar, I've used a method of drawing over 1,000 vblanks (16.6 seconds) which is more than enough precision for my purposes. Unlike cycle counters, this approach shows a stable&reliable value across a gameplay-significant portion of time, so all the system-level spikes are averaged out.


On Jaguar, I already had an interrupt, where I simply incremented FrameCounter variable.


At this moment, I don't wish to indulge in Amiga's idiosyncrasies in IRQ handling, so I figured using timer.device should be safer and easier, given that I already have a working OS calls routines. Right?




Well, it wasn't, but after about a day of troubleshooting, I got the GetSysTime initialized and now I have a GetSysTime () working.


However, changing UNIT_MICROHZ into UNIT_VBLANK during initialization didn't accomplish anything. In fact, nothing changed and the timeval struct (which the docs say is still to be used for UNIT_VBLANK) still returns elapsed time in seconds.




As per the documentation, UNIT_VBLANK (register d0 prior to jsr _LVOOpenDevice (a6) ) doesn't need my own IRQ but relies on power supply strobe mechanism. Might not be implemented on WinUAE, perhaps ?




Potential workarounds, sorted by level of WTF-ness:
1. Utterly Ridiculous: Screw timer.device and implement IRQ (FrameCounter++)
2. Stupidly Ridiculous: Convert timeval.seconds/microseconds into vblank count
3. Plain Ridiculous: Start sending builds for external testing to see if it maybe works on real HW already


Is there anything I have apparently missed in docs with regards to UNIT_VBLANK behavior/set-up ? It appears that I should just do move.l #UNIT_VBLANK,d0 prior to jsr _LVOOpenDevice(a6)


Maybe I need to enable something in the WinUAE ?
VladR is offline  
Old 24 April 2020, 21:20   #2
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,876
IIRC the UNIT settings do not change the unit used by the result, but only the accuracy.
Winuae certainly has nothing to do with that.

Your solution #1 looks quite acceptable.
There is no need to do direct interrupt handling though, just using AddIntServer to add your code to the system's vblank server list is enough.
meynaf is offline  
Old 24 April 2020, 21:39   #3
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 220
Quote:
Originally Posted by meynaf View Post
IIRC the UNIT settings do not change the unit used by the result, but only the accuracy.
Winuae certainly has nothing to do with that.
So, the GetSysTime can really only return time in a single supported unit, despite timer supporting 5 units ? It certainly doesn't mention that in the docs.


That sucks, but I couldn't have known. At least I know I didn't do anything wrong.


The docs say the following:


Quote:

UNIT_VBLANK


This unit uses a strobe from the power supply to keep track of its time or the "E" clock on machines without power supply strobes. It is very stable over time, but only has a resolution of that of the vertical blank interrupt. This unit is very cheap to use, and should be used by those who are waiting for long periods of time (typically 1/2 second or more). This unit uses a timeval in its timerequest

So, there is no reason to believe it wouldn't return number of elapsed vblanks in the timeval.


But, at least I can move on and stop burning time on this thing. Thanks !
VladR is offline  
Old 24 April 2020, 23:10   #4
grond
Banned

 
Join Date: Jun 2015
Location: Germany
Posts: 780
Power supply strobes are only implemented in big box Amigas and thus in the vast minority of Amigas. Implementing a VBL server and adding it is a matter of a few lines of code and best suited for what you want.
grond is offline  
Old 25 April 2020, 00:15   #5
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 220
I'm sure it is. But from experience with interrupts across about ~dozen platforms, I'd like to avoid a scenario where I have to remotely debug why IRQ on some end-user's box is crashing/hanging and burning a week on that.

I'm sure there's 10+ scenarios where a certain combo of Amiga OS/libraries/versions/drivers will result in non-standard IRQ behavior and my routine will either not get called in the chain, or I will have to hack it for a specific remote use case or something entirely different will happen. After burning a week on debugging it...

It even looks like I might get away without using IRQ for audio as I'll be using final 44.1kHz mix and no real-time mixer will be thus needed.

Regardless, it only took about an hour to add the functionality of waiting till the microseconds are zero and auto-normalizing the timestamp at the start-up, so I'm now working only with relative values (of seconds), starting nice and clean from 0.

So, after each benchmark test, I now have two values (sec,miccrosec) to store instead of one (vblCount), so it's not a huge deal - though having just a single value would have been preferred.
VladR is offline  
Old 25 April 2020, 09:50   #6
grond
Banned

 
Join Date: Jun 2015
Location: Germany
Posts: 780
Vertical blanking interrupts are a fundamental mechanism of Amigas and there are no problems with it across the entire platform except for NTSC vs. PAL or 60 Hz vs. 50 Hz which can be dealt with easily. Installing an VBLirq is as easy as calling the corresponding OS function.
grond is offline  
Old 25 April 2020, 14:38   #7
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 505
Quote:
Originally Posted by kamelito View Post
However, changing UNIT_MICROHZ into UNIT_VBLANK during initialization didn't accomplish anything. In fact, nothing changed and the timeval struct (which the docs say is still to be used for UNIT_VBLANK) still returns elapsed time in seconds.
That is the purpose of the call, the time unit is, ehem, device unit independent.




Quote:
Originally Posted by kamelito View Post
As per the documentation, UNIT_VBLANK (register d0 prior to jsr _LVOOpenDevice (a6) ) doesn't need my own IRQ but relies on power supply strobe mechanism. Might not be implemented on WinUAE, perhaps ?
No, it means that it is very properly implemented. UNIT_VBLANK can be driven by two sources, the power supply strobe (prefered, as very stable and not monitor dependent) or the vertical blank (to be avoided, as less stable and monitor dependent).


Quote:
Originally Posted by kamelito View Post
Potential workarounds, sorted by level of WTF-ness:
1. Utterly Ridiculous: Screw timer.device and implement IRQ (FrameCounter++)
If you need a frame counter, and not a time, then implement a frame counter. The timer device gives you a time basis, not a frame basis. The latter is monitor dependent, the time is not.


Quote:
Originally Posted by kamelito View Post
2. Stupidly Ridiculous: Convert timeval.seconds/microseconds into vblank count
If you need a vblank count, then this is not a robust alternative as the time basis is not necessarily related to the monitor.




Quote:
Originally Posted by kamelito View Post
3. Plain Ridiculous: Start sending builds for external testing to see if it maybe works on real HW already
That is hardware dependent, as already said by others. The time source of the VBLANK unit differs upon models. It is a (coarse) time source, not a frame synchronization mechanism.
Thomas Richter is offline  
Old 25 April 2020, 23:18   #8
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 220
How exactly did kamelito get into your copy-pasted quote header ?
VladR is offline  
Old 26 April 2020, 12:44   #9
grond
Banned

 
Join Date: Jun 2015
Location: Germany
Posts: 780
Quote:
Originally Posted by Thomas Richter View Post
the vertical blank (to be avoided, as less stable and monitor dependent).
When you say "monitor dependent", you mean "screenmode dependent", right?
grond 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
GetSysTime() fails to find TimerBase TCH Coders. General 2 02 November 2019 22:41
[blitz] timer device + window IDCMP_INTUITICS = trouble peceha Coders. Blitz Basic 6 20 October 2019 22:02
Device type in ATAPI tape IDENTIFY DEVICE data mark_k support.WinUAE 0 17 March 2019 22:21
Using timer.device in C (VBCC) DBAlex Coders. General 2 28 June 2011 22:10
uaehf.device and HDToolbox: Error 224 reading device description Ebster support.WinUAE 3 16 September 2008 09:24

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 11:17.


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