Jump to content
ijor

ANTIC decap and reverse engineering

Recommended Posts

This is a continuation of this thread: http://www.atariage.com/forums/topic/136706-internal-antic-and-gtia-schematics/

But I thought it might be better to start a new thread dedicated specifically to ANTIC internals.

 

Attached is a better pic of ANTIC revision E die. Still not full rez, just made to barely fit in the maximum allowed by the forum.

AnticQuadrMosaic.zip

  • Like 3

Share this post


Link to post
Share on other sites

This is a continuation of this thread: http://www.atariage.com/forums/topic/136706-internal-antic-and-gtia-schematics/

But I thought it might be better to start a new thread dedicated specifically to ANTIC internals.

 

Attached is a better pic of ANTIC revision E die. Still not full rez, just made to barely fit in the maximum allowed by the forum.

Thanks for sharing.

Share this post


Link to post
Share on other sites

Quick attempt at drawing apparent ANTIC chip floorplan. Main logic blocks.

 

There is a fair amount of guesswork at this point. There might be some mistakes.

 

post-6585-129022995006_thumb.jpg

Edited by ijor
  • Like 2

Share this post


Link to post
Share on other sites

Looking at this diagram, I think my response to the hardware designer would have been: "Can I trade the light pen registers for something more useful?"

 

I'd be interested in knowing how the playfield shift hardware works -- I still haven't figured out exactly how high HSCROL values mess up IR mode 8 lines, at least not well enough to actually emulate it.

Share this post


Link to post
Share on other sites

My initial reaction was to be amazed about the huge size of the RAM. When you see that, you understand why SRAM was that expensive then, and why they used chips like the 6810 (with just 128 bytes) in the drives.

 

I guess we all agree that the HSCROL/DMA/PF SHIFT combo is the most interesting stuff here, but unfortunately it seems to be the most complex logic in the chip (certainly the less regular). I wasn't aware about an HSCROL issue like you mention. Any pointer to where it is described or it was discussed?

 

One very interesting point is how the Vertical Pla is physically constructed. This logic is mostly a few comparators, that depending on the current Vcount value, they trigger actions such as starting/ending VBL, or VSYNC. It was carefully layed out (the physical shape of the silicon) so to be able to easily change the values, as it is needed of course in the PAL version. All the bits arrive to the comparators, both positive and negated, and it is almost like adding or removing tiny jumpers to select the desired values.

Share this post


Link to post
Share on other sites

Nope, Fox just dropped me an email about the HSCROL bug. This is the repro in BASIC:

POKE 39974,18:POKE 39975,8:POKE 54276,15

 

Basically, a scrolled mode 2 line screws up a non-scrolled mode 8 line after it. To trigger it, you need a IR mode 2-5/D-F line with HSCROL >= 10 or mode 6-7/A-C with HSCROL >= 14, followed by an IR mode 8-9 line, in normal or wide width. It seems to be somehow related to playfield fetch timing extending very late in the scan line. In the screenshot below, it looks like the shift register is being loaded at the correct rate but it is running too fast; with other HSCROL values I've gotten inexplicable garbage.

post-16457-12902880815_thumb.png

  • Like 1

Share this post


Link to post
Share on other sites

candle and Electron were looking into a similar phenonema (changing HSCROL on the fly).

 

One theory is that the DMA sequence gets screwed up and funny things happen:

- DMA slots for things like Missile fetch, DL Instruction fetch get reassigned and fed the wrong data.

- Addresses for two things can get ANDed together, and the entirely wrong data fetched.

 

I've not had time to look into it much myself, but really - the strange behaviour described here as well as what goes on when you change HScrol mid-line is still a bit of a mystery.

Share this post


Link to post
Share on other sites

someone may find that usefull...

 

http://spiflash.org/atari/antic-dma.zip

http://spiflash.org/atari/DMAV.zip

 

This is result of early FPGA Antic implementation, currently all of work is conducted by Electron, my work is marginal at this stage

 

In antic-dma.zip directory You'll find sources for test program that was used to log data for HSCROLLx.DAT files (AN4.ASM), and whole rest (AT3.ASM)

 

naming convention is as follows:

NA - NArrow field

WI - WIde field

NO - NOrmal field

SD0 - horizontal Scrolling Disabled

ESx - horizontal Scrolling Enabled, x is value of HSCRL register

 

 

single cell is representing 16 bit of data (big endian), each line has 114 words and always starts from display list fetch

there is 312 lines in file (PAL)

 

legend :

0000 = CPU cycle, masked so it would not distract from antic related data

1xxx - access to DL, where xxx is 12 bit address (A11 to A0)

2xxx - access to playfiled data - xxx is as above

3xxx - character data, see above

4xxx - PMG

5000 - refresh cycle

6xyy - read from Antic's registers, X=0xd40X, yy data read

7xyy - write to Antic registers, see above

80ab - NMI (A) and RDY (B) signal status

when A or B is equal to:

1 - signal was low when phi2 was rising

2 signal was low when phi2 was falling

3 signal was low on both edges

Fxxx - bogus DMA cycle, should not occour, but appearently it did, xxx is as for 1xxx

 

Colors in Visual Aid were choosen to match Altirra documentation

 

Cheers,

Sebastian (Candle'O'Sin)

 

Edited by candle

Share this post


Link to post
Share on other sites

Not so interesting as the HSCROL/DMA stuff, but in the meantime, some unconfirmed small NMI info:

 

The hardware manual claims the following about the 3 NMI types:

These NMI interrupt functions are each separated in time (to prevent overlaps) and ...

 

This seems to be blatantly wrong. NMI is trigerred always as the same point in the scan line (we already knew this about DLI and VBI). Furthermore, the Reset Key (800 only) NMI seems to happen together with VBLANK NMI.

 

NMIST bits 6 and 7 are set and reset together. When one bit is set, the other is reset. Bit 5 is independent, and reset only through NMIRES. Interesting, there is a problem if both NMI and VBI happens at the same time (not 100% sure this can happen, but I think so). If so, the two latches for NMIST bits 6 and 7, might get an unknown state.

 

This makes NMIRES almost a total waste in the XL.

 

Btw, there is some claim that if DL DMA is disabled in DMACTL, Antic keeps the old IR value but resets bit 7 (DLI bit). Again, I'm still far from being sure, but I don't see that this bit is being cleared. Anybody tested/confirmed this?

  • Like 1

Share this post


Link to post
Share on other sites

I think what the manual should say is that the NMI's happen far enough apart that they don't interfere with each other. That is, you won't get multiple NMI's on top of each other before you can clear one.

 

The best use for NMIRES is checking for lost NMI's during IRQ routines. If you start your IRQ routine with a quick check of NMIST, you can determine if there's one that hasn't been serviced. Then you can clear it so the next IRQ won't see it. The best thing to do is LDA NMIST AND NMIST to make sure you don't view an NMI on the instruction before it would have been serviced anyway. You can also make NMI's trigger IRQ's so there's only one maskable entry point for both. I created real IRQ's once by setting a bit in the PIA with one of the input IRQ's enabled... don't remember the details, though.

Edited by Bryan

Share this post


Link to post
Share on other sites

I hope all this research is bringing us closer to a production run of replacement ANTIC, and hopefully in the future, GTIA chips. All these old Atari's are going to die eventually if the old chips aren't put back in production.

Share this post


Link to post
Share on other sites

NMIST bits 6 and 7 are set and reset together. When one bit is set, the other is reset. Bit 5 is independent, and reset only through NMIRES. Interesting, there is a problem if both NMI and VBI happens at the same time (not 100% sure this can happen, but I think so). If so, the two latches for NMIST bits 6 and 7, might get an unknown state.

 

This makes NMIRES almost a total waste in the XL.

 

I can confirm the VBI/DLI behavior -- I modified Acid800 to test this last week. I couldn't test bit 5 since I only have XL/XE machines. And yes, there is almost no reason to ever write NMIRES, except to make it easier to catch the system reset NMI or a disabled/masked VBI/DLI.

 

Btw, there is some claim that if DL DMA is disabled in DMACTL, Antic keeps the old IR value but resets bit 7 (DLI bit). Again, I'm still far from being sure, but I don't see that this bit is being cleared. Anybody tested/confirmed this?

 

Pretty sure this is wrong. Acid800's display list wrapping test has a sub-test where it stops display list DMA in the middle of a $F0 instruction with DLIs disabled, waits for vertical blank, re-enables DLIs in the middle of the next frame, and checks that a DLI fires (DL DMA is still disabled). I forget which one it was, but I added this sub-test because one of the emulators was clearing the IR DLI bit as you describe.

  • Like 1

Share this post


Link to post
Share on other sites

I've tested the Mode repeat, but not extensively and don't remember the DLI results. Also worth trying LMS if it's not been done before.

 

Looking at the 400/800 OS, it makes sense that the NMIs always hit on the same cycle - the code specifically tests the Reset bit as second priority, where if the cycle was different it'd be more memory and time efficient to just test the VBI bit first.

 

 bit nmist
 bpl test_reset
 jmp ($200)   ; do DLI
test_reset
 pha
 and #$20
 beq VBlank
 jmp $e474
VBlank 
 txa
 pha   ; VBlank ... etc

 

If the cycle was different then it would have just made sense to have bit nmist, bpl test_reset, then simply use bvc/bvs to branch based on whether it's a VBI or not.

 

 

A plugin replacement for both chips - I had a think about this, the possibilities could be pretty exciting:

- extend the ANx bus by a bit or two (would require board/wiring between chips), or simply extend the current one by having one SYNC command followed by a parameter, which would free up 2 combinations, allowing 7 Playfield colours (including COLBAK).

 

- 80 byte per line bitmap modes (160x in 16 colours, 80x in 256 colours, 320x in 4 colours maybe).

 

- implement PAL type colour mixing in NTSC by buffering alternating scanlines of hue and luma data

 

- new graphics and text modes.

 

- Programmable attribute maps.

 

- 15 lumas in all modes, "Saturation" bits for colour registers.

 

- "Copper" function for Antic with memory write capability.

Edited by Rybags
  • Like 1

Share this post


Link to post
Share on other sites

A plugin replacement for both chips - I had a think about this, the possibilities could be pretty exciting:

- extend the ANx bus by a bit or two (would require board/wiring between chips), or simply extend the current one by having one SYNC command followed by a parameter, which would free up 2 combinations, allowing 7 Playfield colours (including COLBAK).

 

- 80 byte per line bitmap modes (160x in 16 colours, 80x in 256 colours, 320x in 4 colours maybe).

 

- implement PAL type colour mixing in NTSC by buffering alternating scanlines of hue and luma data

 

- new graphics and text modes.

 

- Programmable attribute maps.

 

- 15 lumas in all modes, "Saturation" bits for colour registers.

 

- "Copper" function for Antic with memory write capability.

 

You could have modes where you fetched characters as if you were in an alpha mode but linear data for the display. The alpha fetch would be a color look-up for cell-based coloring of bitmap modes. You could also have modes similar to GTIA modes where two lines are buffered in to create one doubled line for a 160x100x16 screen.

 

Neither of these modes would require faster DMA than we have now.

Share this post


Link to post
Share on other sites

I suppose it'd all come down to cost and how many people would want it. Plus it'd be another new standard in addition to VBXE.

 

But, just something like a new GTIA would be good - put it on a board and give it scan-doubling and RGB output.

Share this post


Link to post
Share on other sites
Basically, a scrolled mode 2 line screws up a non-scrolled mode 8 line after it.

 

I reached the point, where I think I can see the bug. But seems to me that the bug should happen regardless of the mode 8/9 line having HSCROL enabled or not (although the exact effect might be slightly different). Can you, or somebody else, confirm if the bug is restricted to the next line being not scrolled.

Share this post


Link to post
Share on other sites
Basically, a scrolled mode 2 line screws up a non-scrolled mode 8 line after it.

 

I reached the point, where I think I can see the bug. But seems to me that the bug should happen regardless of the mode 8/9 line having HSCROL enabled or not (although the exact effect might be slightly different). Can you, or somebody else, confirm if the bug is restricted to the next line being not scrolled.

 

You are correct, a horizontally scrolled mode 8/9 line can also be corrupted.

Share this post


Link to post
Share on other sites
You are correct, a horizontally scrolled mode 8/9 line can also be corrupted.

 

Ah, ok, thanks phaeron.

 

I'll try to post a more detailed description later, or during the weekend in the worst case. In the meantime, it seems that the bug happens when one line that has late PF processing, is followed by a line with the slow DMA clock.

Share this post


Link to post
Share on other sites

The diagram below is a simplified schematics of the DMA clock logic. DMA clock in this context is the frequency that ANTIC process a byte worth of Playfield, not necessarily an actual DMA cycle. Depending on the current mode, ANTIC uses one of three different DMA clocks.

 

A circular shift register is used. A three to one mux selects the length of the shift register corresponding to two, four or eight cycles. This sets the current DMA clock. The register is initialized once per scan line at the cycle that Plafield starts, and it is cleared when Playfield ends. The playfield start/end control signals are generated somewhere else, they are active only one clock cycle per scan line. The exact cycle depending on the Playfield width (DMACTL bits 0 and 1), horizontal scroll being enabled, and if so the value of the HSCROL register.

 

The HSCROL bug happens when Playfield ends very late on the line (high HSCROL values), and the next line uses the slow DMA clock. This happens because when using the faster DMA clocks, there are more than just a single bit rotating through the shift register. When a bit reaches the fast clock mux it rotates to the start, but it also continues trough the rest of the shift register. This is normally completely harmless because the rest of the shift register is unused and the output is discarded.

 

And the problem is that by the time the end signal is active, there are still more bits that aren't being cleared, and were not yet discarded. If we then change soon enough to the slower DMA clock, bingo, there is a bit on the loose. And because the muxes change as soon as the new Display List value is read (very early on the scan), it might be close enough to the playfield end signal.

 

Btw, the logic also explains the wierd behavior that might happen if HSCROL, or Playfield width is changed on the fly.

post-6585-129082458509_thumb.jpg

Edited by ijor
  • Like 2

Share this post


Link to post
Share on other sites

Very interesting and thorough! This reminds me of the sprite width logic in GTIA.

 

This definitely seems to explain some of the odd patterns I'm seeing at HSCROL=$A. I'm not sure it explains the garbage I was seeing at $E and $F, which didn't seem to correspond to any playfield data, but I'll probably need to do more experimentation on that.

 

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.

Share this post


Link to post
Share on other sites

And they keep lying to us ...

 

The hardware manual claims that CHACTL bit 2 (reflect, upside down bit) is latched at the start of each line. And it makes this claim only for bit 2, suggesting that the other CHACTL bits are not latched. But the manual is wrong again. I don't see that bit 2 is latched at all. Seems any change takes effect (almost) immediately, even in the middle of a scan line. And on the other hand, CHACTL bit 0 seems to be latched. Untested.

 

The apparent reason that bit 0 is latched, is because the same latch is used for blanking the unused lines in Antic mode 3.

 

Edit: Added that the latching according to the manual was happening at the start of each line.

Edited by ijor

Share this post


Link to post
Share on other sites

In all likelihood, wouldn't the "upside down" bit just decide whether or not to flip all the Delta Counter bits WRT actual fetching of character bitmap data.

 

e.g. normal sequence in Mode 2 is 000 001 010 011 100 (0,1,2,3,4) etc.

Flipped bits would give 111 110 101 100 011 (7,6,5,4,3) etc.

Share this post


Link to post
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.

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...