ANTIC decap and reverse engineering

[ijor]

In all likelihood, wouldn't the "upside down" bit just decide whether or not to flip all the Delta Counter bits...

 

Yes, that's exactly what this CHACTL bit does. It selects between the negated or not negated Delta Counter bits.

 

But the hardware manual claims that the CHACTL bit is sampled only once per character line. And actually it uses the current, updated value of CHACTL each time font data is fetched. According to the manual, you wouldn't be able to change the behavior in the middle of a scan line, but you can if you want.

[ijor]

About the (in)famous ANTIC 240 lines bug. This is mostly a confirmation of what we already knew:

 

The bug is because ANTIC doesn't expect to have a hires mode in its IR (instruction register) during vertical vsync, or even vblank. A hirez mode will force AN2 to be set when the horizontal display is on, this is regardless of the vertical position. If ANTIC is currently in vblank or vsync, it will set AN1 and AN0 accordingly, but not AN2. It expects AN2 to be zero as a natural consequence of the graphic logic trying to display background. This would be normally true expect in hirez modes.

 

Note that ANTIC never clears the IR, and it stops fetching instructions during vertical blank.

 

So AN2 would be set during vblank when horizontal display is on. This would mess with both Vblank and Vsync encoding to GTIA. The former might be not fatal, but the latter would corrupt the actual Vsync signaling.

 

If in addition we play tricks with the horizontal dma timing, we could further affect AN signals during horizontal blank. This is what Rybags does in his seudo interlaced implementation.

[Rybags]

Actually, we could probably say there is no "VBlank" as such from GTIA's POV, Antic normally just holds the HSync command for all the scanlines before and after VSync. Actual numbers vary depending if a PAL or NTSC system.

 

As we (probably you) found before, GTIA can autonomously generate it's own HSync according to it's timings (and obviously, Antic can override those at any time).

 

And of course, we can also utilize the Scanline 240 bug so that we can display PMGs and PF1 colour in that normally "always black" area of the screen.

 

The scope of generating the extra HSync signals is a bit limited - you can only do it within what would be a "wide" display, ie about 176 colour-clocks of the total 228.

 

But still, to generate Interlace, you only need the one pulse spaced about halfway between 2 normal HSyncs.

[+Spancho]

Maybe a stupid question, but is there a chance to distinguish an Antic "Refresh Cycle" DMA from others?

I mean if we used only SRAM in the Atari we could eliminate these DMAs, if it were possible to identify them.

 

spancho

Edited December 5, 2010 by Spancho

[Bryan]

Maybe a stupid question, but is there a chance to distinguish an Antic "Refresh Cycle" DMA from others?

I mean if we used only SRAM in the Atari we could eliminate these DMAs, if it were possible to identify them.

 

spancho

 

Yeah, there's a refresh line but you'd have to isolate Antic from the rest of the bus as well on those cycles.

[+Spancho]

Maybe a stupid question, but is there a chance to distinguish an Antic "Refresh Cycle" DMA from others?

I mean if we used only SRAM in the Atari we could eliminate these DMAs, if it were possible to identify them.

 

spancho

 

Yeah, there's a refresh line but you'd have to isolate Antic from the rest of the bus as well on those cycles.

 

This could be acomplished with 74245 and 74244 and some logic ???

[Rybags]

You'd probably end up with just as much complexity as a 7.2 MHz or other "turbo CPU" upgrade in doing so.

 

And only for a <10% performance gain (and making it incompatible with lots of software).

 

Probably not worth the effort.

[ijor]

I completed circuit extraction, it was faster than I anticipated. I need now to translate the circuit to a more usable form, schematics and/or simulation model.

 

The chip has 8100 transistors. The 48x8 RAM alone takes more than 2500.

[+Stephen]

I completed circuit extraction, it was faster than I anticipated. I need now to translate the circuit to a more usable form, schematics and/or simulation model.

 

The chip has 8100 transistors. The 48x8 RAM alone takes more than 2500.

You're making pretty fast progress! What a complex little beast for back then! The 6502 only has 4000.

[ijor]

What a complex little beast for back then! The 6502 only has 4000.

 

It was indeed pretty big in terms of number of transistors. But that doesn't necessarily translate to complexity. I would guess that at the schematics level, it doesn't look more complex than a 6502.

[Bryan]

What a complex little beast for back then! The 6502 only has 4000.

 

It was indeed pretty big in terms of number of transistors. But that doesn't necessarily translate to complexity. I would guess that at the schematics level, it doesn't look more complex than a 6502.

 

True. Structures like RAM can consume a bunch of space, but can be viewed as a unit. Thanks for all the work you're doing. This is really exciting stuff.

[ijor]

By the way, does this clock affect the memory scan (playfield) address counter? IIRC, the mode 8/9 bug doesn't affect the scan counter, but changing HSCROL mid-line does -- it seems to inhibit the logic that normally stops the counter at the end of the playfield line.

 

I think I can give a better answer now.

 

Yes, this clock definitely controls mem scan counter. Normally, every pulse coming out of this clock during the first line, represents one increment of the counter. HSCROL doesn't stop the mem scan directly. It actually stops this clock.

 

But note again that mem scan is enabled during the first line only. And the "first line" logic doesn't depend on HSCROL or PF width. Also note that, obviously, not every mem scan increment would trigger an actual DMA bus cycle.

 

For actually reproducing the effect you are missing yet another clock. The "Playfield Shift" clock. This is similar, but not exactly, to the DMA clock above.

[Rybags]

Maybe part of the logic used is a discrete compare at given times during a scanline.

 

And, like the C64 and ST with their "remove side border" tricks, if you happen to change the values such that it causes the compare not to match, you get some sort of "runaway" condition.

[ijor]

Simplified diagram of the "Playfield Graphic Shift Clock" logic:

 

 

PF-Reset is a latch. It is active for 8 cycles that ANTIC assigns to the "other stuff" (Display List and PM DMA). It depens on the current value of the Horizontal Counter only.

 

PF-LOAD is a pulse derived from the "DMA Clock" logic as we shown in the previous diagram.

 

We have again, a circular shift register. It is initialized for each byte loaded (from internal or external RAM) according to the DMA clock. In this case, the length of the shift is fixed at 4 cycles. Further logic at the bottom selectively masks the desired positions in the shift register. If the current mode is ANTIC 8, then 3 positions are masked and only one is allowed to come out (slowest shift frequency). If the mode is 9 or A, only two positions are masked (medium frequency). Otherwise, for the other ANTIC modes, a shift is produced every cycle.

 

The output produces a shift in the loaded Graphic Register. The shift is one or two bits, again depending on the current Antic mode.

[ijor]

Reverse engineered ANTIC schematics (preliminary version)

 

This is quite dirty and disorganized. It would welcome a good cosmetic touch up. If somebody has talent for this kind of drawing, please let me know.

I am also having some issues converting the drawing to PDF. In the meantime, it is in image/jpg format. The problem with this format is that you can't search for text.

Hopefully not, but there might be mistakes. It was done, more or less, using the schematics style I've seen in GTIA, POKEY, and TIA.

The most interesting stuff is probably in page 5.

 

Enjoy

AnticReSchem-jpg-1-3.zip

AnticReSchem-jpg-4-6.zip

[ijor]

Same as previous message but now in PDF (with searchable text) format:

AnticReSchem.pdf

 

... considering going for the other chips now, Pokey and/or Gtia? Or are we sure enough about what we "see" in the low rez scans of the original schematics we have?

Older ANTIC, PAL ANTIC? Anyone willing to donate a CTIA to be destroyed?

[Bryan]

I think it makes the most sense to follow with a GTIA.

[Rybags]

GTIA, yes.

 

Maybe some reverse-engineering will help out with that elusive Graphics 9 half-pixel shift that's alleged to exist.

 

Pokey - there's likely some goodies to be found in there too, but I think Pokey's secrets are probably all known anyway.

[phaeron]

Same as previous message but now in PDF (with searchable text) format:

 

 

This goes into my archive. Awesome work.

 

I'll definitely have to study this in detail, as it'll probably answer a lot of questions I have about specific ANTIC behaviors. BTW, am I correct in interpreting page 3 as that ANTIC has binary addressable playfield memory, but the addressing counter that drives it is a polynomial counter? I was a bit confused by the "RAM LSFR" designation -- normally I see this written as LFSR (linear feedback shift register).

 

The portions of the GTIA and POKEY schematics that are hardest to read in the existing schematics, IMO, are the serial port region of POKEY and the sprite portion of GTIA. The audio portion of POKEY is well documented in the Hardware manual, POKEY keyboard is documented in the PAM package, and I was able to decode a lot of the GTIA ANx decoding, priority, and color logic.

[ijor]

BTW, am I correct in interpreting page 3 as that ANTIC has binary addressable playfield memory, but the addressing counter that drives it is a polynomial counter? I was a bit confused by the "RAM LSFR" designation -- normally I see this written as LFSR (linear feedback shift register).

 

Yeah, the internal RAM address counter is a LFSR (small typo there, sorry about that). As long as you don't need a binary output, a LFSR is more efficient.

[Rybags]

So, the "place and pick" is a psuedo-random thing? And that doesn't matter because the pick will correspond to the correct place.

[Bryan]

GTIA, yes.

 

Maybe some reverse-engineering will help out with that elusive Graphics 9 half-pixel shift that's alleged to exist.

 

Pokey - there's likely some goodies to be found in there too, but I think Pokey's secrets are probably all known anyway.

 

My guess is you won't actually see it in logic. It seems to be related to excessive propagation delays and on some chips I was able to shift the alignment of the GTIA modes under certain circumstances by heating them (it's a long story but I thought I had discovered a new graphics mode when one of my GTIA's behaved differently than all the others, allowing me to shift mode 9 back and forth by half a pixel. I got another chip or two to do it if I got them hot enough).

Edited December 16, 2010 by Bryan

[ijor]

So, the "place and pick" is a psuedo-random thing? And that doesn't matter because the pick will correspond to the correct place.

 

Sort of. If the RAM was a "whole" 64 bytes (power of two), then you could indeed ignore the fact that the ordering is non-binary (seudo random). But here it wouldn't work because of the 6 missing bytes (from 64). So in this case the row select logic is aware about the exact ordering of the LFSR. But it takes the same amount of logic (the wide NOR at the left of the row) to decode a binary or a LFSR counter.

[Rybags]

6 missing?

 

I thought there was just 48 in total - or is some reserved for DList address, memory scan etc?

[ijor]

6 missing? I thought there was just 48 in total - or is some reserved for DList address, memory scan etc?

 

They are 48 total. I meant that there are 6 missing bytes for reaching a power of two (64) number of bytes. And the point is that this is important for the RAM decode logic.

 

If it was 64 bytes, then the row select logic (that's the logic that takes the output of the counter and selects an individual byte of RAM) could ignore the fact that the counter is not binary. It would use a non-binary order, but as you are saying, it doesn't matter. As long as you use the same physical location for a specific output of the counter, then it is good enough.

 

However, this wouldn't work here because the LFSR counter outputs values higher than 47 (48-63). In other words, the first 48 and last 6 values of a binary and a LFSR counter are, obviously different. And the decode logic must then be ready to map these values correctly to one of the 48 physical available rows.