Rasters

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

kheops
Atarian
Atarian
Posts: 9
Joined: Sun Nov 18, 2007 6:37 pm

Rasters

Postby kheops » Sat Feb 02, 2008 2:01 pm

Someone Have Release verticals rasters with timerb on Vbl (only changing colors...)

I'm trying some code but the result in not stable...although it's not be visible in this screenshot :-) (yes i'm using steem)
Steem__001.JPG
You do not have the required permissions to view the files attached to this post.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Rasters

Postby Nyh » Sat Feb 02, 2008 2:35 pm

[quote="kheops"]Someone Have Release verticals rasters with timerb on Vbl (only changing colors...)

I'm trying some code but the result in not stable...although it's not be visible in this screenshot :-) (yes i'm using steem)
/quote]

To get stable rasters you will need to synchronize with the electron beam. With interrupts only you cannot get a stable raster.

Do something like this:

Code: Select all

     move   #$2700,SR
     lea     $FFFF8209.w,A6
     moveq   #0,D0
     moveq   #$40,D7
sync_wait:
     move.b (A6),D0
     beq.s   sync_wait
     sub.w   D0,D7
     lsl.w   D7,D0


BTW: for Atari ST pictures captured by steem use either .PNG or .GIF format. .JPG is ment for photo's and not for low color pictures like Atari ST screens. .PNG will result in smaller filesize with better picture uality.

Hans Wessels

kheops
Atarian
Atarian
Posts: 9
Joined: Sun Nov 18, 2007 6:37 pm

Re: Rasters

Postby kheops » Wed Feb 13, 2008 8:32 pm

Ok it seem to be stable ;->

Steem__001.PNG

[PNG file...]
;------------------------------------
; VBL
;------------------------------------
VBL: movem.l d0-d7/a0-a6,-(sp)

move.w #$2700,sr ; ipl7

lea $ffff8209.w,a0
moveq #0,d0
moveq.w #64,d1
.Syncro: move.b (a0),d0
beq.s .Syncro
sub.w d0,d1
lsl.w d1,d0

move.b #$00,$fffffa1b.w
move.l #TimerB,$120.w
move.b #$01,$fffffa21.w
move.b #$08,$fffffa1b.w

movem.l (sp)+,d0-d7/a0-a6
rte

;------------------------------------
; TIMER_B
;------------------------------------
TimerB:
lea $ffff8240.w,a3 ; 8cycles
lea rastpal,a4 ; 12cycles

rept 34 ; 34
move.w (a4)+,(a3) ; 12cycles
endr

nop ; 4
nop ; 4

rte

Thats all...
You do not have the required permissions to view the files attached to this post.

RA_pdx
Captain Atari
Captain Atari
Posts: 215
Joined: Sun Feb 02, 2003 12:01 pm
Location: Nuernberg/GERMANY

Re: Rasters

Postby RA_pdx » Thu Feb 14, 2008 6:24 pm

Hello Kheops.

Why wasting cycles for a Timer B interrupt? You don´t need it for vertical rasters.

A little bit optimized sync routine: :wink:

Code: Select all

.sync
move.b $FFFF8209.w,d0
beq.s    .sync
not.b    d0
lsr.b     d0,d0
>> > raZen/Paradox < <<

Atari 1040STE, TOS 2.06, 4MB, MC68010, IDE 8GB SSD, Gigafile

kheops
Atarian
Atarian
Posts: 9
Joined: Sun Nov 18, 2007 6:37 pm

Re: Rasters

Postby kheops » Thu Feb 14, 2008 6:55 pm

tb+vbl was an experiment...
I wake up one morning with this idea...

so u know other way to do some more thin horizontal raster?

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Rasters

Postby Dio » Mon Mar 03, 2008 4:51 pm

Nyh wrote:To get stable rasters you will need to synchronize with the electron beam. With interrupts only you cannot get a stable raster.

Wouldn't stop #$2500 work, if all other possible interrupt sources were disabled?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Rasters

Postby Nyh » Tue Mar 04, 2008 8:02 am

Dio wrote:
Nyh wrote:To get stable rasters you will need to synchronize with the electron beam. With interrupts only you cannot get a stable raster.

Wouldn't stop #$2500 work, if all other possible interrupt sources were disabled?

AFAIK no. With stop #$2500 you will still get a jitter of 8 pixels.

Hans Wessels

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Rasters

Postby Dio » Tue Mar 04, 2008 9:21 am

That's odd. I noticed Steem seemed reluctant to go into lockstep on STOP but I'd assumed it was a bug.

What's the cause? According to the 68k documentation, stop should halt on a 4-cycle boundary and any interrupt should immediately begin exception processing. Does it alternate between 0 and 8, or do you get 4 as well? I suppose the implementation for stop could be an 8-cycle loop of nop; if (no_interrupt) pc-=2 which would give a granularity of 8, but I'd have thought that would be documented (and that the nop wouldn't be necessary, although maybe the branch back implies a refilling of the prefetch queue).

Does it affect the VBL and HBL as well, or could the jitter be some timing effect on the MFP latency chain?

(Yeah, I should pull the machine out and test it myself :D )

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Rasters

Postby Nyh » Tue Mar 04, 2008 10:40 am

Dio wrote:What's the cause? According to the 68k documentation, stop should halt on a 4-cycle boundary and any interrupt should immediately begin exception processing. Does it alternate between 0 and 8, or do you get 4 as well? I suppose the implementation for stop could be an 8-cycle loop of nop; if (no_interrupt) pc-=2 which would give a granularity of 8, but I'd have thought that would be documented (and that the nop wouldn't be necessary, although maybe the branch back implies a refilling of the prefetch queue).

Does it affect the VBL and HBL as well, or could the jitter be some timing effect on the MFP latency chain?

I don't know. But I am pretty sure using the STOP instruction is not accurate enough for stable rasters and overscan. You need always to synchronize with the electron beam.

If you want to know the exact effects please do some experimenting on real hardware and report back.

Hans Wessels

ijor
Hardware Guru
Hardware Guru
Posts: 3148
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Rasters

Postby ijor » Tue Mar 04, 2008 2:43 pm

Nyh wrote:I don't know. But I am pretty sure using the STOP instruction is not accurate enough for stable rasters and overscan. You need always to synchronize with the electron beam.


It is possible to use STOP and keep synced, we (Paulo and me) did it some time ago. Check the "long" 68000 thread for more info.

But you need to be synced with the electronic beam beforehand, you can't use STOP for the very first syncing.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Rasters

Postby Dio » Tue Mar 04, 2008 3:45 pm

That's fascinating. Looks like there's some completely undocumented substructure inside the STOP instruction that I need to work out - it's probably doing a variant on nop; bra -2 or something...

ijor
Hardware Guru
Hardware Guru
Posts: 3148
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Rasters

Postby ijor » Tue Mar 04, 2008 5:02 pm

Dio wrote:That's fascinating. Looks like there's some completely undocumented substructure inside the STOP instruction that I need to work out - it's probably doing a variant on nop; bra -2 or something...


No, this has no (direct) relation with STOP. You get the same jitter with or without STOP. And STOP, internally, has no NOP or BRA.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Rasters

Postby Dio » Tue Mar 04, 2008 9:50 pm

So it's the interrupts themselves that are being delayed?

I should have most of tomorrow evening free - I'll get an ST set up and try the screen timer on it, been meaning to do that for weeks anyway.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Rasters

Postby Dio » Wed Mar 05, 2008 9:31 pm

How odd. It looks like first screencurrent tick to VBL and HBL are indeed a constant number of cycles, but VBL to VBL, HBL to HBL and VBL to Timer B are all over the shop. Screencurrent to Timer B also has slight variation, although on average each timer B pulse is occurring after the correct hp.

None of the obvious hypotheses I've come up with so far seem to explain this:
- If the timing code was junk, sc to vbl should vary
- if something was delaying the interrupt (or there were certain phases on which the 68k couldn't be interrupted), all the 'sc to *' numbers would vary
- if there was a delay in the first part of the frame, hbl to hbl should still be a constant

But clearly there can't be anything magical about syncing to screencurrent.

Looks like the STeem guys worked most of the rules out though, as the timing program gives pretty similar results there as it does on a real STe.

Best I can come up with so far:
- The vertical period (in cycles) is not a constant
- The vbl interrupt is synced to the same clock that manages vertical display enable - therefore, the phase relationship of vbl to screencurrent is constant, but each is not constant with the next frame

Further work
- write a test to demonstrate that screencurrent tick is constant line-to-line
- write a test that checks if screencurrent tick exact start drifts from frame-to-frame
- explain why hbl / screencurrent are fixed phase but hbl to hbl can still vary
- explain why tb / screencurrent are not in fixed phase

ijor
Hardware Guru
Hardware Guru
Posts: 3148
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Rasters

Postby ijor » Thu Mar 06, 2008 3:33 pm

Dio wrote:How odd. It looks like first screencurrent tick to VBL and HBL are indeed a constant number of cycles, but VBL to VBL, HBL to HBL and VBL to Timer B are all over the shop. Screencurrent to Timer B also has slight variation, although on average each timer B pulse is occurring after the correct hp.


You are obviously measuring wrong, or misinterpreting the results, because the conclusions are non-sensical.

But clearly there can't be anything magical about syncing to screencurrent.


Of course not. Again, check the "long" thread. We explained there how to do it, we explained "the rules" (as you call them), and we explained also the why.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Rasters

Postby Dio » Thu Mar 06, 2008 4:38 pm

If that's the 11-page one, it seems thin on the ground for actual explanations in there (although the discovery that only the RAM, Shifter and MMU are contended is a superlative one and I take my hat off). But that's probably just me being slow as usual :D.

Ah well, I guess this extreme accuracy stuff can probably hold off until after I've got the thing out of the door - most things except a few syncscrollers appear to be working anyway, so I should concentrate on some of the more structural issues for now :D.

junosix
Captain Atari
Captain Atari
Posts: 223
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

Re: Rasters

Postby junosix » Sat Jan 16, 2010 12:53 pm

RalfZenker wrote:Hello Kheops.

Why wasting cycles for a Timer B interrupt? You don´t need it for vertical rasters.

A little bit optimized sync routine: :wink:

Code: Select all

.sync
move.b $FFFF8209.w,d0
beq.s    .sync
not.b    d0
lsr.b     d0,d0

I've seen the above routine on quite a few searches I've done. Is there any disadvantage using:

Code: Select all

vsync    move.w $468.w,d0
wait     cmp.w $468.w,d0
         beq.s wait

That eliminates the need to not/lsr. Seems simpler but wondering why the not/lsr version seems prevalent?

Kalms
Retro freak
Retro freak
Posts: 13
Joined: Sat Oct 28, 2006 10:18 am
Location: Linkoping, Sweden
Contact:

Re: Rasters

Postby Kalms » Mon Jan 18, 2010 12:03 am

They sync against different things.

The not/lsr code synchronizes the CPU against the raster beam horizontally (so if you knew the approximate location of the raster beam (within say 200 pixels), you would know the exact location after running that code sequence). The code sequence looks at the lowest byte of the video hardware's pixel-data-read-pointer and performs a computation that takes a different amount of time depending on the value in that byte.

The cmp/bne code synchronizes the CPU against the raster beam vertically -- that is, it waits for the raster beam to begin vertical retrace, at which point it triggers a VBL interrupt, and the OS has a handler for that, and one of the things that handler does is to increase the value at $468.w. And then your code will detect that $468.w has changed, and break out of the loop.

junosix
Captain Atari
Captain Atari
Posts: 223
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

Re: Rasters

Postby junosix » Mon Jan 18, 2010 12:21 am

Thanks for the answer - I was being totally daft and thinking both were checking for vertical sync (was searching the forum for vsync code and only skim-read this post)!

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: Rasters

Postby larsbrinkhoff » Tue Mar 29, 2016 10:56 am

ijor wrote:It is possible to use STOP and keep synced, we (Paulo and me) did it some time ago. Check the "long" 68000 thread for more info.


Sorry, I'm late to the party. Which thread is that?

User avatar
troed
Atari God
Atari God
Posts: 1213
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Rasters

Postby troed » Tue Mar 29, 2016 11:18 am

larsbrinkhoff wrote:
ijor wrote:It is possible to use STOP and keep synced, we (Paulo and me) did it some time ago. Check the "long" 68000 thread for more info.


Sorry, I'm late to the party. Which thread is that?


It's the same as the 2006 wakestate discussion. I implemented the research by Ijor and Paulo on HBL-dejittering in Closure (which allows you to "gain" one scanline when doing a top-of-the-screen sync scroll).

Read from this post until the end of the thread: viewtopic.php?f=68&t=9527&start=147

There is actually one caveat not mentioned (or known?) from that thread which you'll run into if you try to implement this in a demo. Which i did for Closure ;) Not all wakestates are the same when doing HBL dejittering ...

/Troed

ijor
Hardware Guru
Hardware Guru
Posts: 3148
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Rasters

Postby ijor » Tue Mar 29, 2016 4:24 pm

STOP and syncing have two separate issues.

One is interrupt jitter. Video (GLUE) interrupt jitter is predictable because it is based on the E clock. Syncing with MFP timers interrupt is not possible (or at least, much more difficult).

There is also an issue of pairing with STOP and interrupts. I don't remember the details.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1983
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Rasters

Postby Steven Seagal » Tue Mar 29, 2016 4:58 pm

A new insight we took from WinUAE is that STOP won't unstop before 8 cycles, apparently based on hardware tests.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Rasters

Postby npomarede » Tue Mar 29, 2016 6:46 pm

Steven Seagal wrote:A new insight we took from WinUAE is that STOP won't unstop before 8 cycles, apparently based on hardware tests.

In that specific case, that's something that came from Hatari and that I reported to Toni.
And it was already known and measurable on ST in fact : if you do a "STOP #2100" while an HBL int is already pending, you will see that the total time for stop + interrupt + E clock jitter will never go below 8+56+0 (I have such a test program that synclocks with ff8209, do a stop, then read ff8209 after ; with this you can compute the time that was taken by stop (assuming you have the correct time for interrupt processing))

Nicolas

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Rasters

Postby npomarede » Tue Mar 29, 2016 6:55 pm

ijor wrote:There is also an issue of pairing with STOP and interrupts. I don't remember the details.

I measured on my STF that interrupt exception can pair with the previous instruction (if usual pairing requirements are met), but I don't remember I saw a pairing between stop and the interrupt exception ; this would require stop to take 6 cycles for example, instead of 4n cycles and if I recall correctly I didn't see a case like this (but maybe doing EXG + STOP + interrupt happening during STOP would "exit" stop after 6 cycles instead of 8, I didn't try this case)

Nicolas


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 3 guests