ANTIC decap and reverse engineering

[phaeron]

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.

 

I wonder if this explains the two color clocks of garbage that appear at the right side of a wide scrolled playfield. AFAIK no emulator currently emulates this.

[Rybags]

IIRC I did some experimentation relating to that.

 

Didn't really delve too deep, but I think it might have been a case of Antic grabbing whatever happened to be on the data bus at the time.

 

It's easy enough to check out, if you have a capture card or LCD monitor that happens to display the entire area.

[phaeron]

Didn't really delve too deep, but I think it might have been a case of Antic grabbing whatever happened to be on the data bus at the time.

 

Ugh, I really hope it isn't that. I already had to support that for the GRACTL-without-DMACTL case, and it involved slowing down the CPU path for several clocks at the beginning of a scanline.

[Rybags]

It's more an annoyance than an "exploitable bug" anyway.

 

I can't really think of any case where you'd want to use it, plus it's totally invisible for most people anyway.

 

Additional to that, I think you also get stuff displayed that you wouldn't otherwise want on the left if using Wide DMA + HSCROL, plus certain HSCROL values will make the stuff on the right go away.

Edited December 17, 2010 by Rybags

[ijor]

I wonder if this explains the two color clocks of garbage that appear at the right side of a wide scrolled playfield. AFAIK no emulator currently emulates this.

 

I don't think they are related.

 

The two color clocks of garbage are (more or less) explained in the CGIA datasheet (section 4.2 on pages 42/43). The hardware manual is misleading about ANTIC displaying 176 color clocks, it displays actually 178 color clocks. This can be seen in the schematics, page 6 top left, the logic for the signal I called nDisplEn. The five cycles delay are the minimum (more if not on wide PF) 10 color clocks of extra horizontal border (besides the horizontal blank, which is 40 color clocks). Then the simple math is 228-40-10=178.

 

But the two last color clocks don't trigger a DMA cycle. So ANTIC reads correctly, only 176 color clocks. And I think Rybags is right, because according to the schematics it seems that ANTIC still latches whatever is present in the bus. See the DMA logic on the right on page 5. The signal "nHzDmaEn" inhibits DMA cycles at the far right no matter what, but it doesn't inhibit anything else. The RAM logic would still fetch regardless.

 

It's more an annoyance than an "exploitable bug" anyway. I can't really think of any case where you'd want to use it, plus it's totally invisible for most people anyway.

 

Oh well, I'm afraid it is "exploitable" not in the sense that is very useful, but yes in the sense that it can be detected by software (using collision).

 

Phaeron, I didn't check, but I think that there are several other cases where ANTIC might fetch the bus without an actual DMA cycle.

[Rybags]

That's a thought... might be a cheap and easy "Emulation detection" method.

 

I knew already about the 178 colour-clock thing... worked that out with 'scope measurements while doing the Interlace stuff.

[ijor]

Btw, some other thread here reminded me about the issue of the NMI pulse being two cycles. That can be seen in the schematics as following. There is a signal "Hrz-1415", coming from the "horizontal" PLA that conditions all the NMI trigerring. This signal is the result of a comparator of the current value of the horizontal counter, but ignoring bit 0.

 

One of the "interesting" consequences, is that you could do such things as trigger a single cycle NMI pulse (by enabling/disabling NMIEN at the right time). In turn, this could be relevant for the CPU bug that misses an NMI during IRQ

[phaeron]

Acid800 currently does cycle-exact checks for NMIEN changes (VBI and DLI), and so far I haven't had to put in one-cycle tolerances for it for different machines or temperatures like I have for POKEY IRQs. Part of the reason is likely that if you are changing NMIEN with the CPU, the timing of instruction boundaries relative to the write is known and stable.

[ijor]

Acid800 currently does cycle-exact checks for NMIEN changes (VBI and DLI), and so far I haven't had to put in one-cycle tolerances for it for different machines or temperatures like I have for POKEY IRQs.

 

I wasn't expecting differences across machines as with POKEY, at least not for this reason . This is because POKEY and ANTIC use different phases of the clock for the IRQ/NMI output.

 

What I expect is a one cycle difference in the timing for enabling vs. disabling NMI in NMIEN. This is assuming that a single cycle NMI pulse would effectively trigger an NMI at the CPU (I think it should, but I didn't test it). To disable an NMI "completely" you need to write before the first (of the two) cycles of the NMI pulse. But for enabling the NMI, it is enough to do it in the second cycle.

 

And as I said in the previous message, in theory this might be relevant for the CPU bug of the missed NMI during IRQ/BRK. It could be relevant because the window of missing an NMI is expanded when the pulse is just one cycle long. But I'm not sure it is actually possible to perform this combination (single cycle NMI during IRQ); because you can't write to NMIEN once the CPU started the IRQ/BRK processing.

Edited January 5, 2011 by ijor

[phaeron]

What I expect is a one cycle difference in the timing for enabling vs. disabling NMI in NMIEN. This is assuming that a single cycle NMI pulse would effectively trigger an NMI at the CPU (I think it should, but I didn't test it). To disable an NMI "completely" you need to write before the first (of the two) cycles of the NMI pulse. But for enabling the NMI, it is enough to do it in the second cycle.

 

This expectation is consistent with my tests. Enabling writes are effective through cycle 6, but disabling writes only up to 5.

 

And as I said in the previous message, in theory this might be relevant for the CPU bug of the missed NMI during IRQ/BRK. It could be relevant because the window of missing an NMI is expanded when the pulse is just one cycle long. But I'm not sure it is actually possible to perform this combination (single cycle NMI during IRQ); because you can't write to NMIEN once the CPU started the IRQ/BRK processing.

 

Yeah, I can't think of how to do this with standard 800 or 5200 hardware. The only way to write during the sequence would be with the stack, and you can't remap that to ANTIC. A 65C816 could do it.

[phaeron]

I was studying the re-schematic some more to figure out how to emulate HSCROL-related glitches, and I spotted something weird about the timing logic. The horizontal timing PLA on page 5 masks playfield DMA at count 111 and special DMA at count 14-15, but they're both enabled at 6-7. Normally this is OK since the earliest that playfield DMA will start is at count 16, but it look like the bits that are left flying around the DMA shifter could cause playfield DMA to trigger on top of the special DMA slots. I don't see cross-disables between the DMA enables. Am I correct in thinking that this could cause ANTIC to fetch from the logical AND of the fetch two addresses?

 

If true, this would be a PITA to emulate, but I wonder if it would make possible arbitrary DMA addresses for players.

[Rybags]

Sounds about right.

 

Electron and candle were working on some tests and gave me similar info a few months back. I've not looked into it, but maybe they've got more data since then.

[ijor]

I don't see cross-disables between the DMA enables. Am I correct in thinking that this could cause ANTIC to fetch from the logical AND of the fetch two addresses?

 

Yes, if multiple "sources" attempt to set the DMA address, then the address bus would get the logical AND of them.

 

This can happen in the case you mention, and possibly others as well. e.g., seems like extra bits in the DMA clock could make ANTIC to fetch both character name and font data in the same cycle.

[phaeron]

I did a test, and it does look like you can DMA into the players from the playfield. I'm not sure what to do with this besides trying to emulate it -- you can only DMA into 2 players + missiles at most, and the highest DMA rate interferes with LMS instructions -- but maybe someone can figure out a creative use for it in a demo.

dmabug.zip

[candle]

I did a test, and it does look like you can DMA into the players from the playfield. I'm not sure what to do with this besides trying to emulate it -- you can only DMA into 2 players + missiles at most, and the highest DMA rate interferes with LMS instructions -- but maybe someone can figure out a creative use for it in a demo.

 

hopefully not! i would rather not implement any errors currently present in the design

[andym00]

I did a test, and it does look like you can DMA into the players from the playfield. I'm not sure what to do with this besides trying to emulate it -- you can only DMA into 2 players + missiles at most, and the highest DMA rate interferes with LMS instructions -- but maybe someone can figure out a creative use for it in a demo.

 

Now that's very interesting indeed

[NRV]

I did a test, and it does look like you can DMA into the players from the playfield. I'm not sure what to do with this besides trying to emulate it -- you can only DMA into 2 players + missiles at most, and the highest DMA rate interferes with LMS instructions -- but maybe someone can figure out a creative use for it in a demo.

 

Please! an explanation!

 

I suppose it doesn't make sense to run that in Altirra..

From what I get.. you can show players with data that doesn't come from the normal player base area?

What kind of "LMS interference"?

 

Regards.

[phaeron]

I did a test, and it does look like you can DMA into the players from the playfield. I'm not sure what to do with this besides trying to emulate it -- you can only DMA into 2 players + missiles at most, and the highest DMA rate interferes with LMS instructions -- but maybe someone can figure out a creative use for it in a demo.

 

Please! an explanation!

 

I suppose it doesn't make sense to run that in Altirra..

From what I get.. you can show players with data that doesn't come from the normal player base area?

What kind of "LMS interference"?

 

The trick has to do with the way that GTIA and ANTIC coordinate player/missile DMA. The way it works is that GTIA waits for the first DMA cycle during horizontal blank, then starts reading in P/M data according to the bits enabled in GRACTL. ANTIC DMA during horizontal blank looks like this:

 

MIPPPPII (M = missile, I = display list, P = player)

 

This is why turning on player DMA in DMACTL also implicitly turns on missile DMA: the missile DMA cycle has to occur for GTIA to know where the player DMA cycles are. However, you can trick GTIA if you turn on DMA only in GRACTL, because in that case it will see the display list fetch as a missile fetch and then fetch later cycles as players. This will either fetch LMS instruction bytes from the display list as player data, or even read the 6502's bus activity. Altirra 1.8 does emulate this.

 

What it doesn't emulate (yet) is extending the playfield data into this region. This happens if you change HSCROL to certain values before the point where the playfield memory scan counter stops incrementing. Basically, if you modify HSCROL so that the end of the fetch no longer falls on where the next fetch would have been based on the fetch pattern and offset established by the start of the playfield, ANTIC fails to stop the memory counter and it keeps going through horizontal blank. In the test app I posted, this is done by shifting between even and odd fetch timing in the middle of the first scanline. Actual playfield DMA is masked at cycle 105, so the scan counter keeps going but no playfield DMA happens until the missile DMA slot. At this point playfield DMA resumes and is picked up by GTIA as the missile DMA cycle, and subsequent fetches are picked up as the player DMA cycles:

 

MIPPPPII

F F F F F F...

 

The result is that playfield scan is extended from 48 bytes to 57 bytes (114/2) and some of the extra bytes are used as P/M graphics, meaning you can load and scroll those along with the playfield. One problem is that any other DMA that is enabled in that region will conflict and AND the two addresses together; this is unavoidable with LMS and the highest playfield DMA rate as both of the LMS cycles are next to each other. The other problem is that I think this particular case will cause double DMA overhead during the next scan lines, as if they were all badlines. As a result this costs so many cycles that I'm not sure you could do anything that wouldn't be better done just by moving the P/M data as usual.

[carmel_andrews]

All this 'decapping' of the antic chip, will someone have the knowhow to do an fpga version of this chip (due to the fact that there isn't a plentiful supply of antic i.c's like there were years ago)

 

and while they are at it, an fpga version of the other atari chips (pokey and gtia)

Edited January 8, 2011 by carmel_andrews

[Keith Howell]

Hi guys! I haven't had much free time since I started working 12-hour days five years ago, but a workmate recently pointed out the Visual 6502 project where they photographed a 6502 die and reverse engineered a transistor-level model. They also did the TIA, which led me to this ANTIC recreation thread.

 

I guess getting a chip exposed and photographed is now commercially available and affordable by amateurs like us.

 

I see there has been discussion about the Atari data sheets. I downloaded them from Curt's website ages ago, converted them into HTML pages, and put them on my website. Alas that went offline in 2007 when I moved out of my cable service's range. Actually, they are just not spending on new cable to new homes :-<

 

I converted quite a few Atari documents into HTML, as they original scans were fairly shabby and hard to read.

 

I've taken the liberty of adding your ANTIC die photo to the ANTIC data sheet, and the TIA die photo to the TIA manual.

 

Since people are still interested in Atari stuff, and AtariAge seems to be their main meeting place, I think I should make my stuff available again.

So I've just joined AtariAge to get involved with retrocomputing.

Is there any place I can upload them and edit them to correct any errors that get spotted?

 

Incidentally, I am interested in cloning the Atari 800XL in FPGA. This needs many things to be working before one even gets a boot-up screen, so I started by cloning the simpler Acorn Atom. I deliberately designed the basic video timing to match the Atari, so that I would not need to start from scratch. See:

 

Acorn Atom in an FPGA

Polymorph computer in an FPGA

 

Since I designed the video circuitry, it is easier for me to modify than if I had created a transistor model from a die photo.

 

I already have a POKEY model in VHDL from MikeJ's FPGA Arcade. I had the Atom programming the VHDL POKEY and getting sounds out of it.

I've not used an Atari keyboard matrix scanner, but I have written VHDL code to get a PS/2 keyboard manipulating bits in a virtual keyboard matrix.

 

My VHDL video modules output RGB so they can easily interface to a video DAC or LCD.

Outputting perfect colour means Atari colour artefacts won't appear.

 

The original ANTIC/GTIA work together in a cunning way to implement player-missile graphics (sprites).

I've already implemented a cursor in hardware, so sprites can be easily implemented with the same code.

Simply add more cursors and program them to look like space invaders instead of an arrow.

This isn't as frugal as the Atari method, but these days one doesn't have to be.

Edited January 9, 2011 by Keith Howell

[popmilo]

...

Incidentally, I am interested in cloning the Atari 800XL in FPGA. This needs many things to be working before one even gets a boot-up screen, so I started by cloning the simpler Acorn Atom. I deliberately designed the basic video timing to match the Atari, so that I would not need to start from scratch. See:

 

Acorn Atom in an FPGA

Polymorph computer in an FPGA

 

...

I can only say

 

My 800xl is still working, but in few years - who knows...

[Bryan]

Hey, Guess what! I have a CTIA in one of my 400's (POKE 623,64 does nothing!). I'd be willing to donate it if someone wants to decap it for comparison with GTIA.

[Bryan]

Woohoo! I just discovered one of my 800's also has a CTIA, so I can definitely spare one. I've bought a few machines on ebay recently and hadn't checked them out thoroughly.

[Keith Howell]

My 800xl is still working, but in few years - who knows...

 

Oxidisation of socket contacts and dried-out electrolytic caps are the main failure mode in old machines.

My XL only has the a few chips socketed, and always works perfectly.

The BBC micro had most chips socketed, and as they aged they tended to need hitting to restore contacts.

If your machine starts failing, it should be repairable.

[+Stephen]

Woohoo! I just discovered one of my 800's also has a CTIA, so I can definitely spare one. I've bought a few machines on ebay recently and hadn't checked them out thoroughly.

Nice find!