English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 12 January 2019, 23:51   #1
MarkW
Registered User

 
Join Date: Jan 2019
Location: Malmö / Sweden
Posts: 4
Cycle-exact

Hi y'all

Thank's for a great board. I'm just learning Amiga assembly and I'm puzzled about cycle-exact in WinUAE.

I have this program
Code:
move.w    #$4000, $DFF09A
move.w    #$03A0, $DFF096
loop:
move.w    $DFF006, $DFF180  ; Set background color to VHPOSR
btst      #6, $BFE001       ; Check left mouse button 
bne.s     loop              ; If not pressed go to loop
move.w    #$83A0, $DFF096
move.w    #$C000, $DFF09A
rts
The program produces the output shown below. The background color changes, because the VHPOSR is written into $DFF180 - color table 0, which is the background color.



When I turn on cycle-exact, the background starts to flicker, and I wonder why that is - Any ideas?



It's run on an Amiga 500 - kickstart 1.3 - in WinUAE of course ;-). The resolution is hires PAL. (640x512?) and the clock frequency is 7.14 MHz, so it's around 23 cycles per pixel. If that's roughly 23 instructions pr pixel, then there should be plenty of time to push VHPOSR into DFF180 in the loop. Should the flickering not be avoided then?

Last edited by MarkW; 12 January 2019 at 23:57.
MarkW is offline  
Old 13 January 2019, 00:08   #2
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,314
Quote:
Originally Posted by MarkW View Post
Hi y'all

Thank's for a great board. I'm just learning Amiga assembly and I'm puzzled about cycle-exact in WinUAE.

I have this program
Code:
move.w    #$4000, $DFF09A
move.w    #$03A0, $DFF096
loop:
move.w    $DFF006, $DFF180  ; Set background color to VHPOSR
btst      #6, $BFE001       ; Check left mouse button 
bne.s     loop              ; If not pressed go to loop
move.w    #$83A0, $DFF096
move.w    #$C000, $DFF09A
rts
The program produces the output shown below. The background color changes, because the VHPOSR is written into $DFF180 - color table 0, which is the background color.



When I turn on cycle-exact, the background starts to flicker, and I wonder why that is - Any ideas?



It's run on an Amiga 500 - kickstart 1.3 - in WinUAE of course ;-). The resolution is hires PAL. (640x512?) and the clock frequency is 7.14 MHz, so it's around 23 cycles per pixel. If that's roughly 23 instructions pr pixel, then there should be plenty of time to push VHPOSR into DFF180 in the loop. Should the flickering not be avoided then?
If you're in 640x512 mode you must be in Hires Interlace, and the flickering is probably as it switches over to another copperlist to display the alternating interlace display.
Galahad/FLT is offline  
Old 13 January 2019, 00:50   #3
MarkW
Registered User

 
Join Date: Jan 2019
Location: Malmö / Sweden
Posts: 4
Thanks!

So by going interlaced, we have different copper lists for even and odd lines?

My best guess is that I'm in 640x512. I'm just starting out here ;-)...

I've attached the WinUAE conf file. and here's a screenshot of the display settings.



Problem is that if I go down to lowress, the background is still flickering. I guess there should be no interlace in that mode, and hence no flickering? Unless the flickering source is something completely different...
Attached Files
File Type: uae Amiga500.uae (11.4 KB, 39 views)
MarkW is offline  
Old 13 January 2019, 01:25   #4
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,356
If you're using a default Amiga Kickstart/Workbench 1.3 (or 1.2) environment the Amiga should not be running in interlaced mode. It will only do so if you've specifically set it up to do so using the Workbench preferences.

That said, I do have a hypothesis as to why your program acts like it does. In fact, I think it'd do the same on a real Amiga (interlaced or not). See, the write action you do with the move.w $DFF006, $DFF180 will execute at whatever cycle is available. And the code you've written probably doesn't fully align on DMA cycle boundaries. Which can cause the position of the colour change to shift from frame to fram.

Or to put it in a different way: the timing of the code you've written might not be 'good enough' for a stable display. The non-cycle exact mode might simply be more 'relaxed' on this front and thus work as you want.

If you want stable timing for colour changes etc, I'd recommend getting to grips with the Copper. Using the Copper guarantees the raster location of register changes. Which is much harder to do with the CPU.

Note: this is an untested hypothesis, I may be wrong

Last edited by roondar; 13 January 2019 at 01:36.
roondar is offline  
Old 13 January 2019, 10:25   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,244
Yeah, cycles used by code isn't integer divisible by cycles available in one frame. There is also CIA access which is not slowed down by DMA and is not in sync with DMA cycles.

Only cycle-exact mode emulates DMA stealing cycles from CPU. This is not normally a problem because almost all programs use copper which is accurate in all modes.
Toni Wilen is offline  
Old 13 January 2019, 14:55   #6
MarkW
Registered User

 
Join Date: Jan 2019
Location: Malmö / Sweden
Posts: 4
Thanks for taking the time to answer! Very much appreciated.

I guess the DMA cycle boundaries mentioned, is the DMA time slot allocation mentioned in the Amiga Hardware Manual.

Code:
4 cycles for memory refresh 
3 cycles for disk DMA
4 cycles for audio DMA
16 cycles for sprite DMA
80 cycles for bitplane DMA
So this little program is in a way a great motivation for learning to use the copper.

I guess I could rewrite the program, using a copperlist, and make a loop in the copper, that did the same thing? Anyways, I'm going out on a tangent here. I got the answer for cycle-exact - thanks again
MarkW is offline  
Old 14 January 2019, 08:46   #7
MarkW
Registered User

 
Join Date: Jan 2019
Location: Malmö / Sweden
Posts: 4
Just to wrap things up here - for future reference.

The reply of Galahad/FLT is out in the woods. I have done some pixel counting and it's very clear that A500 hires resolution is not 640x512, but 640x256. So there should be no interlacing.

Here are the images:


Cut out of the windowed area is 640x512, but the pixel height is two pixels - look at the trashcan. So it's effective 640x256.


As roondar mentioned, it's just a working hypothesis that the CPU loop is not aligned with DMA cycle boundaries - and that's good enough for me.

But, as with any hypothesis, it could be cool to test this on a real A500. I would do it myself, if I had the hardware...
MarkW 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
More cycle-exact speeds Leandro Jardim request.UAE Wishlist 5 28 June 2013 09:44
cycle-exact or not? brolly support.WinUAE 10 27 March 2012 17:18
Cycle-Exact and A1200 Another World New to Emulation or Amiga scene 2 15 December 2008 21:38
Cycle-Exact tim_calladine support.WinUAE 1 24 October 2008 16:57

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


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