Jump to content

Photo

ANTIC decap and reverse engineering


93 replies to this topic

#76 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Sun Jan 9, 2011 7:33 PM

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!

Yeah, I was hoping to have one and here I have two. Back in the '80s they'd think me mad for being excited about CTIA. :) I suppose it's still a little pathetic today, but it's like an archeological dig. :D

What I want to know is if CTIA contains GTIA circuitry with the register bits disabled. That would confirm that CTIA was only shipped because GTIA was behind schedule.

#77 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Sun Jan 9, 2011 9:15 PM

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.


Phaeron,

My (very personal) opinion is that emulation should be as accurate as possible, disregarding how useful a particular emulated feature is. The ultimate goal should be that software won't be able to distinguish between emulator and real hardware.

Of course that there is a consideration of how much effort it is worth. And in this case it is certainly your call. But it seems to me that, if you are going for all the trouble of somehow emulating the "DMA clock" and the HSCROL/DMA tricks, then this particular issue of multiple concurrent DMA doesn't look the hardest part.

#78 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,670 posts
  • Location:Bay Area, CA, USA

Posted Sun Jan 9, 2011 9:34 PM

My (very personal) opinion is that emulation should be as accurate as possible, disregarding how useful a particular emulated feature is. The ultimate goal should be that software won't be able to distinguish between emulator and real hardware.


You and I totally agree on this point. That's part of the reason I started Acid800 -- it was clear that the hardware behaviors I was starting to look at weren't intentionally used by anyone and were going to be hard to verify just through software testing. However, even if they aren't worth using, they're work emulating just so people know if they're doing something wrong before it gets tested on real hardware.

Of course that there is a consideration of how much effort it is worth. And in this case it is certainly your call. But it seems to me that, if you are going for all the trouble of somehow emulating the "DMA clock" and the HSCROL/DMA tricks, then this particular issue of multiple concurrent DMA doesn't look the hardest part.


I do want to eventually emulate all of this, but I have to get a better idea of the exact trigger conditions and what portions of the existing ANTIC code I have to rewrite. I think the first priority is to emulate the playfield scan address getting skewed by writes to HSCROL just after HBLANK, as that's one that's actually screwed people up in the wild. To do that, I need to write some tests to figure out the critical cycle for writing HSCROL on a wide fetch line. After that, it'll probably be mode 2-7->8-9 corruption, then image-exact output (since it's program visible via GTIA collisions).

The hard part implementation-wise is trying to keep as much as possible out of the per-cycle loop. Altirra's primary performance bottleneck is the main cycle loop between ANTIC and the 6502, both of which are running single cycle interleaved in order to support things like cycle-exact mid-screen writes to playfield memory. Anything I put in there noticeably slows down the emulation, which means I have to be pretty creative at times.

#79 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Sun Jan 9, 2011 9:44 PM

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.


Very nice, and I am willing to accept a CTIA unit for decapping. But it would be a pitty to "spoil" a CTIA considering they are so rare. May be we should make a last attempt asking Curt to release the original CTIA schematics. Curt, are you reading this?

What I want to know is if CTIA contains GTIA circuitry with the register bits disabled. That would confirm that CTIA was only shipped because GTIA was behind schedule.


So are you saying that you suspect that CTIA already had "GTIA" functionality, but it didn't work correctly and then it was disabled ?

May be, but I'm not so sure. When I checked the GTIA (barely readable) schematics, I had the feeling that the "GTIA" functionality was mostly a quick patch. Hinting that initially there were schematics for a chip without GTIA functionality.

#80 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Mon Jan 10, 2011 6:15 AM

Very nice, and I am willing to accept a CTIA unit for decapping. But it would be a pitty to "spoil" a CTIA considering they are so rare. May be we should make a last attempt asking Curt to release the original CTIA schematics. Curt, are you reading this?


Well, I'll keep my CTIA's around in case we need them.

So are you saying that you suspect that CTIA already had "GTIA" functionality, but it didn't work correctly and then it was disabled ?


Yeah, the question is did CTIA exist first, or was GTIA the target all along. If none of the GTIA stuff is present in CTIA, then it would suggest that CTIA is an earlier completed design and GTIA is a reworking of CTIA. If CTIA contains traces of GTIA features, then it would suggest that CTIA is just an incomplete GTIA.

May be, but I'm not so sure. When I checked the GTIA (barely readable) schematics, I had the feeling that the "GTIA" functionality was mostly a quick patch. Hinting that initially there were schematics for a chip without GTIA functionality.


In that case, I wonder if the reason for releasing GTIA was because Atari wanted the new modes out there or if they were mainly concerned about fixing other CTIA issues (like pixel alignment) and the GTIA modes were just a nice bonus George McLeod had added.

#81 tomal OFFLINE  

tomal

    Combat Commando

  • 1 posts

Posted Sun Jan 16, 2011 12:52 PM

Fascinating thread!

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:


I wanted to implement 8-bit Atari in FPGA few years ago:

http://repo.or.cz/w/AtosmChip.git

Quite a lot of the logic seems implemented, but most of that is untested. I'm sure there is lots of small and bigger bugs.

It's in Verilog and was mostly an exercise for me to implement something in this language. I simulated this code with Icarus Verilog, I've never tried to synthesize it for a real FPGA chip. The chips were not supposed to be replacements for the original ones. They are not compatible with the original bus, I used Wishbone instead:

http://opencores.org...ncores,wishbone

Maybe I'll continue this project some time this year, but I can't say anything for sure now.

#82 Keith Howell OFFLINE  

Keith Howell

    Combat Commando

  • 4 posts

Posted Sun Jan 16, 2011 8:41 PM

Fascinating thread!

I wanted to implement 8-bit Atari in FPGA few years ago:

http://repo.or.cz/w/AtosmChip.git

Quite a lot of the logic seems implemented, but most of that is untested. I'm sure there is lots of small and bigger bugs.


Aye, there's the rub.

A lot of projects get mostly done, but not completely done.
I heard some guys got most of the BBC micro done, but that was a decade ago and still nobody has done it completely.
It is a bit like doing a crossword. We can quickly get all the easiest bits done, then the last clues take most of the time and effort.

#83 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Tue Jan 18, 2011 10:31 AM

Another thought about CTIA...

There are apparently a few games that have trouble on CTIA machines (problems not related to the GTIA features). Has anyone determined what the compatibility issue is?

#84 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,670 posts
  • Location:Bay Area, CA, USA

Posted Fri Apr 20, 2012 12:09 AM

I've been doing some research into ANTIC's unstopped playfield DMA bug, and I have a question about the logic not covered by the schematic: are the addresses fully decoded for all of the line buffer RAM cells? I would have thought that about a third of the cells would be partially decoded, but after running a test app it looks like cell addresses 48-62 are unresponsive on the internal data bus. The test app is showing a solid band of color in the middle that indicates the 6-bit address LFSR is cycling through a full 63 address sequence and that about a quarter of it is coming back $FF no matter what I load into the line buffer. I assume this also means that any writes to those addresses would be dropped as well.

This also makes me wonder why they bothered to add the 48th RAM cell since as far as I can tell the timing only ever allows it to display garbage.

#85 Rybags OFFLINE  

Rybags

    Gridrunner

  • 15,990 posts
  • Location:Australia

Posted Fri Apr 20, 2012 12:19 AM

How does the memory scan update @ end of scanline though... does it rely on DMA incrementing it or is it <previous line start + 32/40/48> type of thing?

I guess regardless of method, 48 is a nice round number for programming purposes - not a power of 2 but more program friendly in some cases.

#86 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,670 posts
  • Location:Bay Area, CA, USA

Posted Fri Apr 20, 2012 9:41 AM

That one I do know: the memory scan counter increments with each DMA cycle or where each DMA cycle would be. There is at least one game that has a scanline where the playfield width is different at the start and end resulting in an unusual memory scan length (Aztec Challenge).

#87 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Fri Apr 20, 2012 10:17 PM

I've been doing some research into ANTIC's unstopped playfield DMA bug, and I have a question about the logic not covered by the schematic: are the addresses fully decoded for all of the line buffer RAM cells?


Yes, internal RAM address is always fully decoded. Each RAM row (one byte) is selected by a single address only. As implied (but you are right, not explicitely enough) by the schematics, each row is selected by a wide NOR that is activated by a single and unique combination of the address signals.

The test app is showing a solid band of color in the middle that indicates the 6-bit address LFSR is cycling through a full 63 address sequence...


Yes, the LFSR logic has a full 63 stages sequence. Under "normal" ANTIC operation, the LFSR is reset at the start of the line, and it would never advance past the 48th stage. Each one of the first 48 stages (after LFSR reset) of the LFSR selects one RAM row, the other 15 stages (there is no stage with all bits zero) don't select any RAM row.

So if ANTIC, for some reason, attempts to access (read or write) internal RAM at any of the 15 last stages of the LFSR, no actual RAM would be selected.

I admit I was a bit lazy on that part of the schematics. I would need somehow to make this more clear and explicit.

#88 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,670 posts
  • Location:Bay Area, CA, USA

Posted Fri Apr 20, 2012 11:39 PM

Hardly anyone could look at this schematic and think of you as lazy. :)

I've attached the test app I used to check this. Here's what it looks like on a real Atari (it does not work on any emulator... yet):

antic-linebuffer.png

This program loads the line buffer using a wide mode E line which has a single $FF byte sweeping across it, then changes HSCROL mid-way through to activate the DMA bug for the next mode line. Playfield DMA is disabled for the first scanline to prevent ANTIC from reloading the line buffer, and then vertical scrolling is used to stretch the mode line so it is visible. Because ANTIC is reading at double rate here (every cycle), it runs through the line buffer about a third of the way across. The yellow line is the 48th cell which contains bus data, and after that are the 15 unassigned entries. After that, the addressing sequence repeats and a double appears on the right side. Thus there are two animating bars sweeping across the lower line. The program was meant to eventually decode the aliased address mappings for the tail of the address sequence, but with this behavior that turned out to be unnecessary.

I assume based on the stability of the bar and its independence from the 48th cell that the internal bus is not floating during that time.

Sadly, I haven't been able to think of a practical use for this bug. It takes up way too much memory bus time and the existing modes already max out bandwidth over the ANx bus, relegating it to the "stupid hardware tricks" category.

Attached Files



#89 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Fri Apr 29, 2016 8:02 AM

After some time I am trying to reconnect with my Atari activities ...

 

Antic high resolution die image mosaic.

WARNING. ~160MB download. Intentionally posted like this, you have to join the domain and the path below:

 

http://vapi.fxatari.com/
Decap/AnticMosaicFull.png
 

Will upload some more stuff shortly.



#90 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Fri Apr 29, 2016 9:11 PM

ANTIC re digitized die layout, in simple PNG format.

 

This is a simple picture format with all the layers combined. This is nice for looking, but not the most useful format for performing an actual work. I'll upload a vector format (SVG), with separated layers shortly.

 

http://vapi.fxatari....AnticLayout.png



#91 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Sat Apr 30, 2016 2:44 PM

I uploaded a zip file with all the stuff except the huge high rez image:

 

http://vapi.fxatari....SchemLayout.zip

 

It includes:

- Updated schematics (just minor cosmetic updates)

- Floorplan

- Re digitized Layout in PNG format (single layer)

- Re digitized Layout in SVG format

 

The SVG file has separated layers and shapes. It can be rendered by most modern browsers, but it is meant to be used with illustration software, like Inkscape, Corel Draw or Adobe Illustrator.

 

The high rez full die is still available separately as posted in a previous message.

 



#92 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Sun May 1, 2016 8:30 AM

I assume based on the stability of the bar and its independence from the 48th cell that the internal bus is not floating during that time.

 

I just see that I never answered that. It is precharged, it should be stable.

 

Btw, you made me realize I made a small mistake in the schematic. It doesn't affect functionality, just that ram write wouldn't work reliably like that ...

 

The wiring of the output enable of the ram write drivers (the tristate inverters that drive the ram columns when writing) is wrong. The output enable is the same, it is actually RamWe, for both the positive and the inverted drivers.



#93 Stephen OFFLINE  

Stephen

    Quadrunner

  • 7,459 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Sun May 1, 2016 6:01 PM

After some time I am trying to reconnect with my Atari activities ...

 

Antic high resolution die image mosaic.

WARNING. ~160MB download. Intentionally posted like this, you have to join the domain and the path below:

 

http://vapi.fxatari.com/
Decap/AnticMosaicFull.png
 

Will upload some more stuff shortly.

Bueatiful image.  Real shame about the small hole in the top.  Was the chip damaged while de-capping?

 

P.S.

I have a 4k 28" Samsung monitor.  Text is WAY too small at that res, but for these images I cranked the monitor to the max (I usually have to run it at 2560*1440).  3840*2160 is killer for these kinds of shots!



#94 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,166 posts

Posted Sun May 1, 2016 7:53 PM

Bueatiful image.  Real shame about the small hole in the top.  Was the chip damaged while de-capping?

 

No. The image is a composite mosaic (stitch, panorama if you want). It is composed of about 50 individual shots. A couple of shots were taken a little bit too far from their neighbor ones, creating this hole in the mosaic.

 

Fortunately the missing area is simple and not very dense. It was easy to fetch the missing pieces from the low rez images (see the one at the top of this thread).

 

Yeah, I realize it ruins the artistic aspect of the image. Sorry about that :)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users