Jump to content
IGNORED

New ANTIC timing diagram


dmlloyd

Recommended Posts

After a frustrating day at work, I took some time to do something I've had on my list for a long time: I made a new version of an ANTIC horizontal line timing chart that I believe was posted here many years ago. The original chart was very complete but also unfortunately rendered at quite a low resolution, making it very difficult to read. I augmented the chart with a couple bits of data from the ANTIC data sheet, and, well, here it is. I have an SVG version of it too, but AA won't let me upload it.

 

The drawing was made with the WaveDrom editor.

 

Anyway, I would appreciate it if any experts might check it over for errors.

post-15480-0-78211000-1432732591_thumb.png

  • Like 1
Link to comment
Share on other sites

Sorry for the dumb question, but (1) what does it all mean, and (2) how does one read it (is there a key)? Like, I know LMS is Load Memory Scan, so it seems at that point (X axis = "clk" aka a measurement of time), in the particular mode one's looking at, is when ANTIC does, uh, what it does during an LMS? :)

 

My thought is that a diagram like this would help me design the most optimal Display List Interrupts (e.g., if it's going to do something with Player/Missile Graphics and the playfield, do the PMG first since ANTIC does it earliest). Or am I totally confused? :)

 

Sorry, I'm super naive when it comes to how the hardware works.

Link to comment
Share on other sites

Sorry for the dumb question, but (1) what does it all mean, and (2) how does one read it (is there a key)? Like, I know LMS is Load Memory Scan, so it seems at that point (X axis = "clk" aka a measurement of time), in the particular mode one's looking at, is when ANTIC does, uh, what it does during an LMS? icon_smile.gif

 

My thought is that a diagram like this would help me design the most optimal Display List Interrupts (e.g., if it's going to do something with Player/Missile Graphics and the playfield, do the PMG first since ANTIC does it earliest). Or am I totally confused? icon_smile.gif

 

Sorry, I'm super naive when it comes to how the hardware works.

 

Not dumb questions at all. Unfortunately the tool I used doesn't have a "legend" function (AFAIK anyway).

 

So here's the translation:

  • The orange "R" boxes are memory refresh cycles; CPU is halted but it's a refresh address on the bus, not a graphical data address.
  • The yellow "M" and "P0".."P3" boxes represent memory fetch for player-missle graphics, if enabled.
  • Boxes labelled "C#" are memory fetches for characters.
  • Boxes labelled "D#" are memory fetches for graphic or character set data.
  • The top/bottom numbers are the horizontal cycle count.
  • The transition on the WSYNC line represents when ANTIC "releases" the CPU after it writes to the WSYNC register.
  • The HSYNC/HBLANK lines correspond to the display signals of the same name.
  • The "memory fetch" lines represent which cycles correspond to which playfield widths.

As an aside, I did notice that the refresh cycles on the first couple rows are wrong, and there's a spacing problem, so I will fix that for rev 2.

Link to comment
Share on other sites

Playfield widths should be 128 color cycles (64 machine cycles) for narrow, 160 color cycles (80 machine cycles) for normal, and 192 color cycles (96 machine cycles) fetched / 188 color cycles (94 machine cycles) for wide. The timing of display enables doesn't make sense because the chart shows the normal playfield starting display before fetch begins.

 

Missile DMA is too early by one cycle. It should be immediately before the display list fetch. When fully enabled, P/M and display list DMA take 8 back to back cycles.

 

For a wide playfield, the first character name fetch should be two cycles after the second LMS fetch, not five cycles.The relative placement you have from C0 -> D0 for both character and bitmap modes is correct, though (+2 and +3 cycles, respectively).

 

Refresh DMA cycles are always four cycles apart when they don't conflict with other DMA cycles, not two cycles as you have for mode 2-5. For missile DMA on cycle 0, the first refresh cycle is on cycle 25 unless it conflicts with playfield DMA.

 

IR mode 3 doesn't skip character data cycles on any scan line. It fetches cycles even for blanked descender portions.

 

WSYNC is way too early. If missile DMA is at cycle 0, the CPU's first cycle after resuming is cycle 105.

 

Wide playfields at the fastest DMA rate (IR modes 2-5 or D-F) don't perform all DMA cycles because playfield DMA cycles are blocked after the WSYNC point. Any playfield DMA cycles that would happen on cycle 106 or later is suppressed and are available for either refresh DMA or the CPU, but ANTIC still fetches data from the bus. In particular, this means that the 48th byte in the line buffer is never fetched normally.

 

Attached is an excerpt from my hardware manual showing the ANTIC DMA patterns. It has been verified against real hardware by test programs and a logic analyzer.

 

anticdma.pdf

  • Like 1
Link to comment
Share on other sites

Nice diagram! Thanks for sharing.

 

Svg version would be cool to have (or some custom wavedrom file if its saved like that) so we could work our own remarks into it.

You can compress to zip any file and send it here.

 

Here is Antic timings text file that I use for years and still haven't found serious bugs (Think it's from one of older topics on AA).

 

Antic_Timings.txt

Link to comment
Share on other sites

Nice diagram! Thanks for sharing.

 

Svg version would be cool to have (or some custom wavedrom file if its saved like that) so we could work our own remarks into it.

You can compress to zip any file and send it here.

 

Here is Antic timings text file that I use for years and still haven't found serious bugs (Think it's from one of older topics on AA).

 

 

Cool, I didn't think of adding HSCROL offsets on there. Maybe I'll see how hard that is to do.

 

Next rev I'll export SVG and put it in a zip, thanks for the idea.

Link to comment
Share on other sites

Playfield widths should be 128 color cycles (64 machine cycles) for narrow, 160 color cycles (80 machine cycles) for normal, and 192 color cycles (96 machine cycles) fetched / 188 color cycles (94 machine cycles) for wide.

 

The diagram I am working off of (Julie Solomon, 9/19/1983) shows 176 color cycles / 88 machine cycles displayed for wide. I haven't tested it first hand though; I just assumed that the diagram was accurate.

 

 

Missile DMA is too early by one cycle. It should be immediately before the display list fetch. When fully enabled, P/M and display list DMA take 8 back to back cycles.

 

Ah that one is definitely a mistake on my part.

 

For a wide playfield, the first character name fetch should be two cycles after the second LMS fetch, not five cycles.The relative placement you have from C0 -> D0 for both character and bitmap modes is correct, though (+2 and +3 cycles, respectively).

 

Hmm again the diagram I have shows four gaps between the last LMS fetch and the first character fetch.

 

 

Refresh DMA cycles are always four cycles apart when they don't conflict with other DMA cycles, not two cycles as you have for mode 2-5.

 

Fixed that one in rev 2, I don't know why I did it that way.

 

 

For missile DMA on cycle 0, the first refresh cycle is on cycle 25 unless it conflicts with playfield DMA.

 

Hmmm. No hint of that in my original here. I'll look into this.

 

 

IR mode 3 doesn't skip character data cycles on any scan line. It fetches cycles even for blanked descender portions.

 

Good to know... again, this original diagram...

 

WSYNC is way too early. If missile DMA is at cycle 0, the CPU's first cycle after resuming is cycle 105.

 

Ah I must have counted wrong, will fix that one.

 

 

Wide playfields at the fastest DMA rate (IR modes 2-5 or D-F) don't perform all DMA cycles because playfield DMA cycles are blocked after the WSYNC point. Any playfield DMA cycles that would happen on cycle 106 or later is suppressed and are available for either refresh DMA or the CPU, but ANTIC still fetches data from the bus. In particular, this means that the 48th byte in the line buffer is never fetched normally.

 

Interesting!

 

 

Attached is an excerpt from my hardware manual showing the ANTIC DMA patterns. It has been verified against real hardware by test programs and a logic analyzer.

 

Nice, that's much better than mine. :) I guess I will continue to fix this one up though, because, well, I've gone this far... It's interesting that this original diagram is so inaccurate (my mistakes aside). I wonder if any games/programs were designed with this inaccurate information, and then exhibited inexplicable bugs as a result. I never was able to figure out who Julie Solomon was, or where she worked.

 

Thanks for the great feedback.

Link to comment
Share on other sites

The diagram I am working off of (Julie Solomon, 9/19/1983) shows 176 color cycles / 88 machine cycles displayed for wide. I haven't tested it first hand though; I just assumed that the diagram was accurate.

 

Whoops, sorry, yes, 188 color cycles is P/M graphics, wide playfield is narrower due to display cropping on the left. It's 178 color cycles (89 machine cycles), $2C-DD. The discrepancy is because the last two color cycles are garbage in an IR mode 2/F screen unless horizontal scrolling is used. They count, though, because you can get collisions....

 

Hmm again the diagram I have shows four gaps between the last LMS fetch and the first character fetch.

 

Nope, that's wrong. For a wide playfield, it's 4 cycles in between for bitmap modes, two cycles for character modes. Normal playfield starts 8 cycles later. The Solomon chart appears to have playfield DMA cycles two cycles too late -- the refresh cycles and WSYNC are placed correctly relative to P/M graphics and display list DMA.

 

For a second source, see the chart at line 313 on antic.c in the Atari800 emulator, which was independently derived:

http://atari800.cvs.sourceforge.net/viewvc/atari800/atari800/src/antic.c?revision=1.80&view=markup

 

I never was able to figure out who Julie Solomon was, or where she worked.

Apparently she worked at Atari in the Corporate Research CAD/CAM group:

http://www.leiterman.com/atari.html

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...