Rasters

All 680x0 related coding posts in this section please.

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

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

Re: Rasters

Postby Steven Seagal » Tue Mar 29, 2016 7:40 pm

npomarede wrote:
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.


Well as it wasn't mentioned I credited WinUAE instead of Hatari...
Thought it was directly measured on the CPU.

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


And assuming there's no strange interaction between STOP and interrupt process timing.

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 7:47 pm

Steven Seagal wrote:
npomarede wrote:
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.


Well as it wasn't mentioned I credited WinUAE instead of Hatari...
Thought it was directly measured on the CPU.

That's both in fact : I measured it on my STF with some custom programs, but when getting different results with winuae cpu core under Hatari, I reported it to Toni which confirmed it after using a logic analyzer to monitor the bus access.

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


And assuming there's no strange interaction between STOP and interrupt process timing.

With this method of measuring, I get a minimum time of 8 cycles for stop. If pairing could happen, maybe it would be 6 cycles. But in all cases, I never reached 4 cycles for STOP.

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

Re: Rasters

Postby ijor » Wed Mar 30, 2016 2:29 am

I used to live and breath 68K instruction timing. But that was almost a decade ago ... so caveat emptor ...

npomarede wrote: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


That is correct. For reasons that are not completely clear to me, it takes a minimum of 8 cycles, and always it's a multiple of 4. And that's unrelated to the ST rounding up to 4 issue. It is intrinsic to the CPU.

npomarede wrote: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)


Yes, STOP can (kinda) pair with the previous instruction. It's not a pairing in the strict sense. STOP would always take a multiple of 4 cycles. But STOP is transparent (because it doesn't perform any bus access) in terms of pairing to the previous instruction.

So EXG+STOP+INTR does pair, because EXG and INTR pair.

Btw, Nicolas, did you see what I asked in the other thread about writing 0x3 to the REZ register? Do we know what SHIFTER does and what is seen in the display? GLUE I already know it mostly ignores bit 0.

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

Re: Rasters

Postby npomarede » Wed Mar 30, 2016 8:30 am

ijor wrote:Btw, Nicolas, did you see what I asked in the other thread about writing 0x3 to the REZ register? Do we know what SHIFTER does and what is seen in the display? GLUE I already know it mostly ignores bit 0.

Hi
yes, I saw this thread about 0x3 into res ; in fact that's a question I asked here a long time ago (at a time when my STF was packed and I couldn't test it myself). Since then, I remembered I made a quick test of writing 0x3 to ff8260 and as you suggested this resulted in what looked like hi res line on a color monitor.
One thing I wanted to do, but forgot/had no time since, would be to check if video counter increases at the same speed as a hi res line in that case (another way would be to use a logic analyzer and see if the timings for a video line with res=0x3 is the same that with a regular res=0x2 line).
But for now, I would say bit 0 is not used in that case and only bit 1 makes a decision for hi res versus low/med res (and then timings from ff820a will apply)

Nicolas

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

Re: Rasters

Postby npomarede » Wed Mar 30, 2016 8:40 am

ijor wrote:That is correct. For reasons that are not completely clear to me, it takes a minimum of 8 cycles, and always it's a multiple of 4. And that's unrelated to the ST rounding up to 4 issue. It is intrinsic to the CPU.

IIRC I have a test program that "delays" the HBL int by 4n+2 cycles to measure if IPL changes are processed at cycles 4n or 2n, and in that case the interrupt exception doesn't trigger at cycle 4n+2 (after current instruction) but 4n+4 (after the next instruction). So I had the feeling that in the case of level 2/4/6 interrupts they are only visible to the cpu every 4 cycles ; as those signal are provided to the cpu by glue, maybe there's an internal glue logic that rounds IPL changes to the next 4 cycles ? (from discussion with Toni/WinUAE, he had the feeling STOP could exit every 2 cycles (but not fully measured) ; so maybe the 68000 can STOP every 2 cycles after a minimum of 8, but that the visibility of the IPL is only every 4 cycles on the ST ?)

Nicolas

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

Re: Rasters

Postby ijor » Wed Mar 30, 2016 12:14 pm

npomarede wrote:One thing I wanted to do, but forgot/had no time since, would be to check if video counter increases at the same speed as a hi res line in that case (another way would be to use a logic analyzer and see if the timings for a video line with res=0x3 is the same that with a regular res=0x2 line).


I'm pretty sure GLUE doesn't care about bit 0 at all. So from the programmer's point of view 0x03 at the REZ register should be the same as 0x02. That includes timing, sync signals, borders, MMU counters, etc.

I'm just not so sure about the SHIFTER behavior. But that should affect the display only. Not anything that you can test by software.

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

Re: Rasters

Postby ijor » Wed Mar 30, 2016 12:49 pm

npomarede wrote:IIRC I have a test program that "delays" the HBL int by 4n+2 cycles to measure if IPL changes are processed at cycles 4n or 2n, and in that case the interrupt exception doesn't trigger at cycle 4n+2 (after current instruction) but 4n+4 (after the next instruction). So I had the feeling that in the case of level 2/4/6 interrupts they are only visible to the cpu every 4 cycles ; as those signal are provided to the cpu by glue, maybe there's an internal glue logic that rounds IPL changes to the next 4 cycles ? (from discussion with Toni/WinUAE, he had the feeling STOP could exit every 2 cycles (but not fully measured) ; so maybe the 68000 can STOP every 2 cycles after a minimum of 8, but that the visibility of the IPL is only every 4 cycles on the ST ?)


GLUE's interrupt logic doesn't perform any kind of synchronization or cycle alignment. There is a small delay, of course, but it is only combinatorial (which means, in the same cycle). Any incoming interrupt is reflected immediately to the IPL signals.

So, MFP interrupts are definitely not aligned to any 4 cycles boundary. HSYNC/VSYNC interrupts are different, because they are part of GLUE's video logic that is clocked internally (before reaching the interrupt logic) by the 2 MHz clock.

So HBL/VBL interrupts would happen only every 4 cycles. However, the alignment of these 4 cycles to the CPU depends on the wakeup! Then, if STOP could process interrupts every 2 cycles, in some wakeups STOP would take 2+4n cycles (exactly the opposite that you see).

Furthermore, I think (I really don't remember for sure) I made tests delaying STOP by 2 cycles using pairing. I do admit I don't have a theoretical explanation for this, yet. That's the only reason I cannot say I am 100% confident about this.

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

Re: Rasters

Postby ijor » Wed Mar 30, 2016 1:46 pm

ijor wrote:So HBL/VBL interrupts would happen only every 4 cycles.


Minor correction to myself ...

HBL/VBL (which btw, they are actually HSYNC and VSYNC, not really BLANK time, as in other systems) will reach the interrupt logic only every 4 cycles, as I said. But, some conditions might defer an interrupt, and not only internals to the CPU, but also by GLUE and then at the IPL signals. If say, a MFP or VBL interrupt is pending, an HBL one would be deferred. And at that stage it is not synchronized to the video 2 MHz clock anymore ...

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

Re: Rasters

Postby larsbrinkhoff » Thu Mar 31, 2016 5:12 am

npomarede wrote: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


Do those 8 cycles include reading two words for the STOP instruction? (Or prefetching the next...)

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

Re: Rasters

Postby npomarede » Thu Mar 31, 2016 9:07 am

larsbrinkhoff wrote:
npomarede wrote: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


Do those 8 cycles include reading two words for the STOP instruction? (Or prefetching the next...)

When STOP completes, it will trigger an exception for the corresponding interrupt, so prefetching will happen at this time when the new PC is loaded with the exception's vector number ; there would be no point to prefetch 1 or 2 words following the STOP instruction as they would never be executed anyway (ie not before the exception is executed first). (note : that's my interpretation and I think it's correct, but I haven't check bus usage to see if STOP really doesn't prefetch anything)

Nicolas

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

Re: Rasters

Postby ijor » Thu Mar 31, 2016 11:54 am

larsbrinkhoff wrote:Do those 8 cycles include reading two words for the STOP instruction? (Or prefetching the next...)


STOP doesn't perform any bus access whatsoever. The two words for the STOP instruction were already PREfetched.

Get the official Motorola documentation. For some reason it has bad reputation among Atari coders. But it is very accurate and invaluable.

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

Re: Rasters

Postby troed » Thu Mar 31, 2016 11:58 am

... or yacht.txt - which is based on not only Motorola's documentation but also some reversing :)

viewtopic.php?f=68&t=24710#p227267

/Troed

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

Re: Rasters

Postby ijor » Sun Oct 08, 2017 1:51 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.


npomarede wrote: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 ... (from discussion with Toni/WinUAE, he had the feeling STOP could exit every 2 cycles (but not fully measured) ; so maybe the 68000 can STOP every 2 cycles after a minimum of 8, but that the visibility of the IPL is only every 4 cycles on the ST ?)


Finally I think I can give a detailed answer to the STOP exact behavior:

STOP always takes a multiple of 4 cycles. It can never take 4*n+2 cycles (well, except by a hardware RESET). This is generic for the 68000, nothing specific to the ST. The reason is how the microcode works. STOP operates like a regular instruction that takes 4 cycles. The only thing special about STOP is that no prefetch is being performed. So the same instruction is executed again and again until interrupted.

This is very different than the mechanism when the 68000 performs a bus access and it waits for the peripheral being ready. When performing a bus access any wait states would delay the CPU for any number of cycles, it is in effect "STOPPED" here. But in our case, when executing the STOP instruction it is really not stopped.

STOP would keep executing and iterating until interrupted (or reset). But interrupts are triggered only at instructions borders, they don't stop instructions at the middle. So this could only happen at a multiple of 4 cycles because each STOP "iteration" takes 4 cycles.

Regarding a minimum of 8 cycles. That is not 100% accurate. If the interrupt was pending before but masked by the status register, and it is being triggered only as a consequence of the STOP instruction lowering the interrupt mask, then yes, it would take 8 cycles. This is because the CPU takes some time to update the status register. By the time the interrupt mask is updated and checked, it is already too late to interrupt the first STOP iteration, it would interrupt the second one and then it would take 8 cycles.

However, if the interrupt mask on the previous instruction was already low enough to accept the interrupt, but it didn't actually trigger because the interrupt reached the CPU too late by the end of the previous instruction, then STOP would take 4 cycles only. In this case the delay to update the interrupt mask is obviously not relevant, and then STOP would be interrupted at its first iteration.

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

Re: Rasters

Postby Steven Seagal » Sun Oct 08, 2017 4:00 pm

ijor wrote: This is because the CPU takes some time to update the status register. By the time the interrupt mask is updated and checked, it is already too late to interrupt the first STOP iteration, it would interrupt the second one and then it would take 8 cycles.


That's horrible and hard to believe! After all, it's a register.
Is there such a delay for other instructions updating SR?
EDIT:
Probably not as those instructions contain some "mysterious" cycles latency after the read, then refill the prefetch queue.

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

Re: Rasters

Postby ijor » Mon Oct 09, 2017 10:40 am

Steven Seagal wrote:Is there such a delay for other instructions updating SR?


The delay should be the same for all instructions that update the SR. But STOP is the only one that doesn't prefetch after the update. That means that the others have several more cycles between the update and the end of the instruction.

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

Re: Rasters

Postby Steven Seagal » Mon Oct 09, 2017 5:51 pm

ijor wrote:The delay should be the same for all instructions that update the SR. But STOP is the only one that doesn't prefetch after the update. That means that the others have several more cycles between the update and the end of the instruction.


Fortunately. For a while I panicked. :)


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 1 guest