Emulator cycles

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

Post Reply
User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed

Emulator cycles

Post by Steven Seagal »

I wrote another little article exploring an interesting question, here:

http://ataristeven.t15.org/doc.htm/Emul ... cycles.htm

and duplicated here (v1.0):

Emulator cycles

Emulator cycles are a reckoning common to Steem and Hatari that is handy
to reference Shifter tricks.

For example "switching the frequency to 60hz at cycle 376 removes the right
border of a 50hz line".

They are also called "line cycles" because they're reset for each scanline.

There's a simple relation between emulator cycles and 'position' in Alien's

Emulator cycles = position * 4

Telling what "cycle 0" precisely means isn't so easy!

Notice that in his article Alien said that he did not determine the exact
moment the HBL interrupt takes place, and therefore a constant should be added
to his numbers. Similarly, for the timing of HSYNC.

Here is an attempt at making the link between emulator cycles and GLUE events
on the STF, based on "Atari Monitor Summary Specifications" by Shiraz Shivji,
May 14, 1986.

Graphics are for 60hz (US standard).


Absolute precision isn't claimed (off by 4?).
Notice that we consider a Shifter latency of 28 cycles (16 prefetch and 12
"other") between 'Display Enable' (DE) and actual display of the pixel.

Code: Select all

Emulator        60HZ            Emulator        50HZ
cycle                           cycle
0/508   HBI pending             0/512   HBI pending
32      End of HBLANK           32      End of HBLANK
52      Start of DE             56      Start of DE
80      Display first pixels    84      Display first pixels
372     End of DE               376     End of DE
400     Start right border      404     Start right border
456     Start of HBLANK         460     Start of HBLANK
464     Start of HSYNC          468     Start of HSYNC
504     End of HSYNC            508     End of HSYNC

Strangely, the HBLANK interrupt (HBI) is triggered by the system (GLUE) only
after the HSYNC signal has been sent. Because of the time needed by
the system (MC68000 + MC68901) to process the interrupt itself, 56 cycles,
the interrupt code starts executing when the cathode ray is in the left
border. This makes the HBI almost useless for anything related to display.
One wonders why it doesn't start at the start of HBLANK instead, 48
cycles earlier.

The Monitor Specification for vertical timing may also help us to locate
emulator cycles of the VBI.


Before the VBI, the video counter is reloaded with the base value. We know
that because some programs depend on this behaviour.
The time between those 2 events, about 1544 cycles, is equivalent to the
0.19 ms timing given in the graphic as VSYNC duration. So apparently
the video counter is reloaded just before VSYNC and the VBI is set pending
just after.

The indicated cycles are relative to the HBI = cycle 0 reference.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm

Re: Emulator cycles

Post by AtariZoll »

Very useful informations.
I observed that video counter base value loading timing too. Not really good. Should be at end of Vblank, so changes done in Vblank routine would have effect immediately, and not after next Vsync. In case of Falcon it is corrected.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Emulator cycles

Post by Dio »

You can also see this in the timing diagrams I stuck up.

Exactly what the 'right' implementation for cycle 0 depends on the internal implementation. Where does the H counter get reset? When does the V counter increment? I thought I had a solid handle on this based on the vsync timing (much as you derive above) but unfortunately it falls apart as soon as you start looking at the 70Hz timing, and that's also indicated by the ability to generate the double-hsync.

What we really need is the Glue schematics. I don't know if they're in the material at the Computer History Museum in Sunnyvale - when I get there with work I plan to go and find out, but while I used to be in the valley at least once a year I'm not travelling there much nowadays.

Post Reply

Return to “Development”