Jump to content

Photo

ANTIC decap and reverse engineering


93 replies to this topic

#1 ijor OFFLINE  

ijor

    Stargunner

  • 1,949 posts

Posted Wed Nov 17, 2010 2:24 PM

This is a continuation of this thread: http://www.atariage....tia-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.

Attached Files



#2 Stephen OFFLINE  

Stephen

    Quadrunner

  • 6,636 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Wed Nov 17, 2010 3:58 PM

This is a continuation of this thread: http://www.atariage....tia-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.

#3 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Fri Nov 19, 2010 11:13 PM

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.

AnticFloor.jpg

Edited by ijor, Fri Nov 19, 2010 11:16 PM.


#4 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,346 posts
  • Location:Australia

Posted Fri Nov 19, 2010 11:16 PM

Cool.

When you break it down like that, it just seems a lot less complex.

#5 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,342 posts
  • Location:USA

Posted Sat Nov 20, 2010 2:36 AM

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.

#6 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Sat Nov 20, 2010 1:42 PM

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.

#7 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,342 posts
  • Location:USA

Posted Sat Nov 20, 2010 3:30 PM

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.

Attached Thumbnails

  • atari-hscrolbug.png


#8 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,346 posts
  • Location:Australia

Posted Sat Nov 20, 2010 7:49 PM

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.

#9 perry_m OFFLINE  

perry_m

    Star Raider

  • 61 posts

Posted Sun Nov 21, 2010 1:06 AM

Have you see this page? They listed Atari 400/800 on their wish list and have completed the TIA and made a 2600 simulation:
http://visual6502.org/

I guess things have come a long way since that Hungarian work on the 6502.

#10 candle OFFLINE  

candle

    River Patroller

  • 2,793 posts
  • Location:Lublin, Poland

Posted Sun Nov 21, 2010 2:08 AM

someone may find that usefull...

http://spiflash.org/...i/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, Sun Nov 21, 2010 2:09 AM.


#11 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Sun Nov 21, 2010 12:35 PM

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?

#12 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,782 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Sun Nov 21, 2010 2:19 PM

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, Sun Nov 21, 2010 2:30 PM.


#13 OldAtarian OFFLINE  

OldAtarian

    Stargunner

  • 1,599 posts

Posted Sun Nov 21, 2010 2:43 PM

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.

#14 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,342 posts
  • Location:USA

Posted Sun Nov 21, 2010 3:03 PM

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.

#15 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,346 posts
  • Location:Australia

Posted Sun Nov 21, 2010 3:49 PM

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, Sun Nov 21, 2010 3:50 PM.


#16 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,782 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Sun Nov 21, 2010 4:13 PM

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.

#17 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,346 posts
  • Location:Australia

Posted Sun Nov 21, 2010 4:17 PM

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.

#18 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Fri Nov 26, 2010 3:19 PM

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.

#19 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,342 posts
  • Location:USA

Posted Fri Nov 26, 2010 3:41 PM

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.

#20 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Fri Nov 26, 2010 4:08 PM

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.

#21 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Fri Nov 26, 2010 8:24 PM

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.

Attached Thumbnails

  • AnticDmaClk.jpg

Edited by ijor, Fri Nov 26, 2010 8:26 PM.


#22 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,342 posts
  • Location:USA

Posted Fri Nov 26, 2010 11:17 PM

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.

#23 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Sat Nov 27, 2010 9:08 AM

By the way, does this clock affect the memory scan (playfield) address counter?


Can't yet confirm that, but I think it does.

#24 ijor OFFLINE  

ijor

    Stargunner

  • Topic Starter
  • 1,949 posts

Posted Fri Dec 3, 2010 8:01 PM

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, Fri Dec 3, 2010 8:23 PM.


#25 Rybags ONLINE  

Rybags

    Quadrunner

  • 15,346 posts
  • Location:Australia

Posted Fri Dec 3, 2010 8:57 PM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users