Jump to content

Photo

Internal ANTIC and GTIA schematics


183 replies to this topic

#76 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Sat Jan 10, 2009 9:09 AM

I'm no electronics expert but I'd put it down to the externals, and not inside GTIA. Maybe a little time lag in the voltage ramping up?
With 0111 you have the biggest voltage off, and full output on the smaller ones.
1000 has the biggest voltage coming on and no output on the smaller ones.


GTIA/CTIA outputs are open-drain, raising edge is slower than falling edge. In addition, the buffer between CTIA/GTIA and the resistor ladder that makes the LUMA DAC has rather assymetric transition times; again raising edges are slower.

#77 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sat Jan 10, 2009 1:09 PM

I crashed the machine yesterday and it coldstarted so I lost the code that had the luma change which (seemingly) might have simulated part of the VBlank pulses.
It was a fairly short bit of code and a bit crude, so I intend to do another version that works a bit better anyway.

Getting the colour burst to show on display is easy although I think it's probably dependant on individual TVs and how they handle whatever it is that's going on.

Just change the DMA mode from narrow/std/wide and you should get different effects.

e.g. (first setup the distorted screen):

5 GRAPHICS 0
10 DL=PEEK(560)+PEEK(561)*256:POKE DL-3,112:POKE DL-2,112:POKE DL-1,112
20 POKE 560,PEEK(560)-3

then just try Poking values 21, 22 or 23 in SDMCTL (559).


Another thing that I have seen incompletely documented is ANTIC register 54286/54287 bit 5 (RESET). It doesn't mask the reset even on Atari 400/800 where the RESET is suppose to be a NMI like DLI/VBI. You can't lock it out like the BREAK key unless you corrupt the stack or some other extreme measure.

#78 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Sat Jan 10, 2009 7:18 PM

It's non-maskable since it's a mechanical user operation that Antic can't mask out.

But... I suspect that if you had a modded 400/800 with 64K that mapped the extra RAM over the OS like the XL/XE does, you might be able do the trick like on the C-64 that masks out the Restore key.

It would be of oddity value only and mightn't even work... have a VBlank NMI occur, but don't reset the NMI Status (STA $D40F).
In theory that should leave the NMI line pulled low, masking out further NMIs.

But, that means no more VBlank or DLIs either. And it mightn't work.

The documentation is wrong re Antic NMIs - you don't need to store to NMIRES for DLIs, Antic detriggers them itself. Unsure if it's the same case for VBlanks.

#79 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sun Jan 11, 2009 4:21 PM

It's non-maskable since it's a mechanical user operation that Antic can't mask out.

But... I suspect that if you had a modded 400/800 with 64K that mapped the extra RAM over the OS like the XL/XE does, you might be able do the trick like on the C-64 that masks out the Restore key.

It would be of oddity value only and mightn't even work... have a VBlank NMI occur, but don't reset the NMI Status (STA $D40F).
In theory that should leave the NMI line pulled low, masking out further NMIs.

But, that means no more VBlank or DLIs either. And it mightn't work.

The documentation is wrong re Antic NMIs - you don't need to store to NMIRES for DLIs, Antic detriggers them itself. Unsure if it's the same case for VBlanks.


It's maskable on Atari 400/800 without modifying hardware or replacing ROM cartridge. Here's one method from BASIC that locks out the RESET key (this one corrupts the stack):

1 POKE 54286,0
10 POKE 1536,96:POKE 546,0:POKE 547,6
20 POKE 54286,64

I have one method I did a long time ago that locks it out without corrupting stack... but requires cycle exactness (like stable DLIs).

#80 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Sun Jan 11, 2009 5:17 PM

That's just changing the VBI vector.

Probably masks the Reset key because it just does an RTI... without pulling the registers... which would result in a crash fairly quickly.
Since 400/800 doesn't have a Hard Reset, it becomes an unrecoverable lockup.

Trust me - there's absolutely no way to disable the System Reset key on a standard 400/800 without modding the machine itself, or without crashing the machine.

I remember one funny old trick to cause Reset to give an unusable machine without crashing it - set APPMHI ($E,F) to a value above where the screen starts. It means that the E: device can't open when you press Reset - doesn't work on XL as they discovered the bug by then and fixed it.

#81 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sun Jan 11, 2009 7:13 PM

That's just changing the VBI vector.

Probably masks the Reset key because it just does an RTI... without pulling the registers... which would result in a crash fairly quickly.
Since 400/800 doesn't have a Hard Reset, it becomes an unrecoverable lockup.

Trust me - there's absolutely no way to disable the System Reset key on a standard 400/800 without modding the machine itself, or without crashing the machine.

I remember one funny old trick to cause Reset to give an unusable machine without crashing it - set APPMHI ($E,F) to a value above where the screen starts. It means that the E: device can't open when you press Reset - doesn't work on XL as they discovered the bug by then and fixed it.



It's still useful if you wanted to show an image on the screen and disallow anyone coming and hitting the reset.

I'll try to dig up the one that allows you to execute code and disallow the reset.

That APPMHI would still execute code when RESET is pressed so it wouldn't be a complete lockout.

#82 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Sun Jan 11, 2009 7:39 PM

But all you seem to be doing is crashing the machine - so no good for something that needs DLIs for colour changes.

You'd get the same thing by just executing a "$02" instruction.

#83 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Mon Jan 12, 2009 9:01 AM

Another thing that I have seen incompletely documented is ANTIC register 54286/54287 bit 5 (RESET). It doesn't mask the reset even on Atari 400/800 where the RESET is suppose to be a NMI like DLI/VBI. You can't lock it out like the BREAK key unless you corrupt the stack or some other extreme measure.

I don't have the hardware reference in front of me, but I don't think Antic ever supported disabling the reset NMI. On the XL's, they quit using that feature- probably because it couldn't get you out of a serious lock-up. Now the reset button causes a hardware reset rather than an OS generated one.

#84 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Mon Jan 12, 2009 1:54 PM

But all you seem to be doing is crashing the machine - so no good for something that needs DLIs for colour changes.

You'd get the same thing by just executing a "$02" instruction.



Actually, the example I made was for color changes and disallowing system reset. It was a color rainbow effect....

You can also freeze the machine by executing a 255 but that piece of code led me to investigate further and find a way to execute code and mask a non-maskable warm reset on Atari 400/800.

#85 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Mon Jan 12, 2009 1:55 PM

Another thing that I have seen incompletely documented is ANTIC register 54286/54287 bit 5 (RESET). It doesn't mask the reset even on Atari 400/800 where the RESET is suppose to be a NMI like DLI/VBI. You can't lock it out like the BREAK key unless you corrupt the stack or some other extreme measure.

I don't have the hardware reference in front of me, but I don't think Antic ever supported disabling the reset NMI. On the XL's, they quit using that feature- probably because it couldn't get you out of a serious lock-up. Now the reset button causes a hardware reset rather than an OS generated one.


On XLs, you can't mask it, but on Atari 400/800 you can lock it out. I don't think it's documented just like some of the IRQ stuff isn't documented either.

#86 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Mon Jan 12, 2009 3:37 PM

Maybe it's like the "Ignore NMI if IRQ occurs on the same cycle" bug of the 6502?

But I don't think that applies if IRQs occur but they're masked with SEI. We could probably cause IRQs nearly every cycle with Pokey Timers but no way to service them all.

Maybe a 240 scanline DList with DLI set on all of them. DLIs still get flagged in NMIST if you have them set but don't enable them. Although still that doesn't cover the entire screen.

Don't have any 400/800 here so no way I can try anything like that out.

#87 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Tue Jan 13, 2009 5:37 AM

Maybe it's like the "Ignore NMI if IRQ occurs on the same cycle" bug of the 6502?

But I don't think that applies if IRQs occur but they're masked with SEI. We could probably cause IRQs nearly every cycle with Pokey Timers but no way to service them all.

Maybe a 240 scanline DList with DLI set on all of them. DLIs still get flagged in NMIST if you have them set but don't enable them. Although still that doesn't cover the entire screen.

Don't have any 400/800 here so no way I can try anything like that out.


It's just some code running in the background and IRQ timer setting the colors for the background code. It does not involve the scanline 240 bug. Reset can be pressed at any time by user so it would be hard to do a "ignore NMI if IRQ occurs on same cycle".

#88 JAC! OFFLINE  

JAC!

    Stargunner

  • Topic Starter
  • 1,814 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Tue Jan 13, 2009 11:20 AM

I worked out some of the GTIA logic some time ago.
Here is a picture of the last page of the GTIA schematics with some captions explaining it.


Hello Perry, this GTIA schema picture/analysis is awesome for me! I going to print is out right now to pin it to my wall.
Maybe I'll send you some very very bad scan of the human DNA, so you can reverse engineer it just for fun :-).

Regards, Peter.

#89 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Thu Jan 15, 2009 11:54 AM

I think I might have this interlaced control worked out...

more to come later.

#90 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Thu Jan 15, 2009 4:20 PM

I think I might have this interlaced control worked out...

more to come later.


I just tried out that line 240 bug code you posted. It does give a whole bunch of white lines from end of display to top of display, but you have to play around with the vertical sync control with the monitor to see it.

#91 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Thu Jan 15, 2009 9:08 PM

I've just got to verify my work - I was entering character set data by hand in the early morning and kept getting stuff wrong.

Also having fun and games trying to get a decent photo.

I'll get back to it later and put up some pics if/when I have success.

#92 Curt Vendel OFFLINE  

Curt Vendel

    River Patroller

  • 4,786 posts
  • Location:Carmel, New York

Posted Sun Jan 18, 2009 8:41 AM

Those files originally came from me from www.atarimuseum.com The scans are low res and not of the best quality.

I've been meaning to do newer updated scans of all of the chip docs and repost them. I'm in the hospital right now, but if someone would kindly remind me in 2-3 weeks I'll start loading them back on the scanner and replacing them on atarimuseum.com with higher resolution pdf's that are more readable and usable for everyone.



Curt


Hi there,

I am looking for the internal schematics of the ANTIC and GTIA. There are scans of them in ftp://ftp.pigwa.net/stuff/collections/nir...20Info/GTIA.PDF but they are not readable at all. Maybe somebody knows where these scan are from or who created them.

Best regards, Peter / JAC!



#93 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Sun Jan 18, 2009 12:06 PM

I've been meaning to do newer updated scans of all of the chip docs and repost them. I'm in the hospital right now, but if someone would kindly remind me in 2-3 weeks I'll start loading them back on the scanner and replacing them on atarimuseum.com with higher resolution pdf's that are more readable and usable for everyone.


That would be great!

Will you include schematics of Antic as well (they were not included in the datasheets you posted)? And could you include CTIA (not just GTIA) as well, I believe you mentioned here that you have them both?

Get well (from whatever the reason you are in the hospital).

#94 JAC! OFFLINE  

JAC!

    Stargunner

  • Topic Starter
  • 1,814 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Mon Jan 19, 2009 7:28 AM

Hi Curt,

This is great news!
I've put some dozens of reminders in all my calendars ;-)
So I hope you will be doing fine by that time. :thumbsup:

Good luck, Peter.

#95 Curt Vendel OFFLINE  

Curt Vendel

    River Patroller

  • 4,786 posts
  • Location:Carmel, New York

Posted Mon Jan 19, 2009 8:24 AM

I've got a few surprises in store for everyone, besides the technical document manuals I have the original pencil drawn schematics of the most of the chips, plus I also have the actual photoplots of every Atari chip that Atari ever designed, from Harold Lee's original Pong on a Chip to the GTIA to the CGIA to even AMY and Rainbow, plus there are a dozen or so "Skunkworks" chips which I have yet to identify such as ICY, MTV, STEPHANIE and many others, so with a little time I found a way to scan in these massive 8' X 8' plots by using a method that the arcade side art guys use, and I'm pretty certain I can get these photoplots digitized...


Curt


I've been meaning to do newer updated scans of all of the chip docs and repost them. I'm in the hospital right now, but if someone would kindly remind me in 2-3 weeks I'll start loading them back on the scanner and replacing them on atarimuseum.com with higher resolution pdf's that are more readable and usable for everyone.


That would be great!

Will you include schematics of Antic as well (they were not included in the datasheets you posted)? And could you include CTIA (not just GTIA) as well, I believe you mentioned here that you have them both?

Get well (from whatever the reason you are in the hospital).



#96 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,998 posts
  • Location:Australia

Posted Mon Jan 19, 2009 8:36 AM

Great stuff.

My scanner stopped working ages ago... but I've found that you can get good results by just taking digital photos with the right lighting. Then just put into photoshop, adjust the levels, posteurise etc.

#97 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Mon Jan 19, 2009 1:25 PM

That's just changing the VBI vector.

Probably masks the Reset key because it just does an RTI... without pulling the registers... which would result in a crash fairly quickly.
Since 400/800 doesn't have a Hard Reset, it becomes an unrecoverable lockup.

Trust me - there's absolutely no way to disable the System Reset key on a standard 400/800 without modding the machine itself, or without crashing the machine.

I remember one funny old trick to cause Reset to give an unusable machine without crashing it - set APPMHI ($E,F) to a value above where the screen starts. It means that the E: device can't open when you press Reset - doesn't work on XL as they discovered the bug by then and fixed it.



It's still useful if you wanted to show an image on the screen and disallow anyone coming and hitting the reset.

I'll try to dig up the one that allows you to execute code and disallow the reset.

That APPMHI would still execute code when RESET is pressed so it wouldn't be a complete lockout.


Here's the code I dug up for complete SYSTEM RESET lockout on Atari 400/800 (this compiles to a boot disk of 242 bytes):

;*** ATIRQ400.asm: Atari Timer IRQ measured to exact cycles so no WSYNC is required by Krishna Software Inc.
;*** This plays music on voice #1 and uses IRQ timer interrupt on timer #4. Voice #0 is for constant tone.
;*** There are three CLKs which can be used by either 8 or 16 bit divisors as controlled by 53768.
;*** The 15.6999Khz CLK and 63.921Khz CLK can be turned off via 53775 but 1.78979Mhz CLK is always on.
;*** The 15.6999Khz CLK is 1.78979Mhz/114 and gives the scanline interrupt at end of scanline.
;*** The 63.921Khz CLK is 1.78979Mhz/28 and does not divide evenly into 29868 cycles/frame so cannot be used
;*** for color clock accurate or scanline accurate interrupts. This program also attempts to write IRQ vector
;*** directly at 65534/65535 by disabling ROM for XL/XE series (should have no effect on Atari 400/800).
;*** This program locks out SYSTEM RESET on Atari 400/800 where it's a NMI.
TIMERFREQLSB = 53760
TIMERFREQMSB = 53762
WSYNC = 54282
VCOUNT = 54283

DOSVEC = 10
CASINI = 2
WARMSTART = 58484
VMIRQ = 534 ;hardware irq ptr

ORG = 600h
;DW 0FFFFh
;DW StartAdr
;DW LastOffset-1
DB 0,3 ;# of sectors to load 1..255
DW ORG
DW StartAdr
Rts
StartAdr: Lda #MyReset,L
Sta CASINI
Lda #MyReset,H
Sta CASINI+1
Lda #0
Sta 580
Lda #2
Sta 9
Jmp WARMSTART
MyReset: Lda #2
Sta 9
Lda #MyReset,L
Sta CASINI
Lda #MyReset,H
Sta CASINI+1
Sei
Lda #0 ;no VBIs nor DLIs for maximum performance
Sta 54286
Sta 53774 ;disable all IRQs
Sta 54272 ;turn off screen
Sta 54017 ;disable ROM and BASIC for XL/XE series via PORTB
Lda #TimerTwoIRQ,L ;general IRQ routine but we use only for timer #2
Sta VMIRQ
Ldy #TimerTwoIRQ,H
Sty VMIRQ+1
Sta 65534
Sty 65535
Cpy 65535
Beq ROMVectorSet
Lda #IdleLoop,L
Sta SelfModifyThis+1 ;Remove 5 cycles from background task (for Jmp [534])
Lda #IdleLoop,H
Sta SelfModifyThis+2
ROMVectorSet: Lda #40 ;+40 for join channels 3,4; +80 for channels 1+2 @1.79Mhz
Sta 53768 ;join channels at 1.79 Mhz
Lda #160
Sta 53760
Lda #143
Sta 53761
Lda #175
Sta 53763
Lda #114-7 ;lsb 114-7 or 57-7 for two irqs/scanline
Sta 53764 ;timer #2 freq = 1789790/[A+1]
Lda #0 ;msb for rate divisor A
Sta 53766
Lda #4 ;1,2,4=timer interrupts
Sta 53774 ;enable IRQ #2
Lda #128
;Sta 53248 ;unrem to show sprite using 0 CPU cycles and 0 DMA cycles
Lda #144
;Sta 53249
Lda #255
Sta 53261
Sta 53262
Sta 53256
Sta 53257
Lda #32
Sta 53275
Lda #10
Sta 53266
Lda #12
Sta 53267
Ldx #0
Ldy #4 ;load ack parameters
Lda #65
NotMidScr: Cmp VCOUNT
Bne NotMidScr ;CF=1 when A=65
Sta WSYNC
Nop
;Nop
CLI
Sta 53769 ;start timer counter
;CLI
;Nop
;Nop
;Nop
;Nop
;Lda #34
;Sta 54272
IdleLoop: ;(29868 cycles in NTSC frame - 9*262 for Refresh = 27510 cycles so to keep the IRQ
; stable, cycles must be aligned to 27510 including IRQ routine). For PAL frame, use
; 312*114 = 35568 - 312*9 = 32760 cycles.)
;(27510 factors to 2*5*7*3*131)

Lda #0
Sta 53274
Lda 1535
;Lda 53770 ;No longer random if bits 0,1 of 53775 = 0
ROL
Sta 53274
;Rol
Sta 53762 ;make construction site noise
Lda #48
Sta 53274
Lda #64 ;which of these two instruction to rem out depends on IRQ routine total cycles
;Sta 53274
Lda #96
Sta 53274
Lda #128
Sta 53274
Lda #144
Sta 53274
Lda #160
Sta 53274
Lda #176
Sta 53274
SelfModifyThis: Jmp Idle1 ;For Atari 400/800, this jmp and following NOP (5 cycles) will be removed since ROM vector not used
Idle1: Nop
Jmp IdleLoop

;*** H/W does jmp [65534] (7 cycles) and XL/XE OS does a CLD and JMP [534] for 2+5 = 7 cycles.
;*** Below routine 32 cycles+7+5 = 44 cycles on old OS (like on Atari 400/800).
;*** Optimized by using X/Y registers and not using it in main routine so PHA/PLA not needed.
TimerTwoIRQ: ;Pha ;3 cycles
;Lda #255
;Sta 53771 ;POTGO
;Nop
Inc 53274 ;change register (like color for example)
;Lda #0
;Sta 53774
;Lda #4
;Sta 53774 ;send ack to timer irq (optimized with Inc = 6 cycles)
Stx 53774
Sty 53774 ;do ack
Inc 1535
;Nop
;Lda #96
Ror 53274 ;change register (like color for example)
;Pla ;4 cycles
Rti ;6 cycles

;LastOffset: DW 2e0h,2e1h,ORG

#98 UNIXcoffee928 OFFLINE  

UNIXcoffee928

    Stargunner

  • 1,177 posts
  • Location:Sosaria, USA

Posted Mon Jan 19, 2009 3:32 PM

Hi, I know that this is out of the blue, but after developing some methods to clean up the Official Atari Schematics for the 600XL (See latest post in the "Atari on a Breadboard" thread for the updated 600XL image), I decided to help out here, by getting started in the restoration of the GTIA schematic documents.

This will take a while, as I am doing it largely by hand, and using some advanced imaging techniques... but it can be done.

You will find the preliminary GTIA schematics attached to this post. They are much better than what's out there. As time permits, I will do further image processing, until they are of a high quality... but for now, these images are way better than what you are working with, even though they are far from done. Consider them 'Alpha'... ha... but they are stitched, hi-res, contrast enhanced, line enhanced by one pixel, and de-speckled... So, they look pretty kickass when comparing them to the older images.

Perhaps some kind souls can do some napkin-sketches of what they think may be missing at the edges in the center of the following images. If so, I will draw them into the images, once we have a consensus.

Have fun!

Attached Thumbnails

  • GTIA_FULL_View_00.jpg
  • GTIA_FULL_View_01.jpg
  • GTIA_FULL_View_02.jpg
  • GTIA_FULL_View_03.jpg
  • GTIA_FULL_View_04.jpg


#99 UNIXcoffee928 OFFLINE  

UNIXcoffee928

    Stargunner

  • 1,177 posts
  • Location:Sosaria, USA

Posted Mon Jan 19, 2009 7:55 PM

Here is an updated View 02 image.

This one is cleaner, and reveals some of the less obvious stuff in the original. Some of the hidden symbols have been recovered through pixel by pixel "Bit Archeology".

This image, mod_01, supersedes the previous image, please update your notes.

Attached Thumbnails

  • GTIA_FULL_View_02_mod_01.jpg


#100 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Mon Jan 19, 2009 8:54 PM

Perhaps some kind souls can do some napkin-sketches of what they think may be missing at the edges in the center of the following images. If so, I will draw them into the images, once we have a consensus.


I figured out most of the missing sections, but did you read what Curt just said? He has the full-size original schematics and he is going to publish them shortly. Are you sure is it worth to invest a lot of work on this?

You did a great job enhancing the unreadable schematics. But no offense, in some sense (and only in some sense) they are worse. The main traces and blocks are now far more easier to read. But the "fine printing", seems harder to read now. This is probably a consequence of increasing the contrast. More contrast decreases resolution, the same way that you use shades for virtually increasing a resolution.

Anyway, IMHO, this is the wrong approach for these cases. We are not decrypting a document from something that we don't know anything about it. Quite the contrary, we know a lot. Hence it is faster and easier to analyze what is readable and understand the main logic. Then, the unreadable (at least most of it) becomes obvious by simple deduction.

e.g: In some cases it is unreadable if the clock coupler number is a "2" or a "1". But this is a piece of cake to deduce once you realize where the signal comes and where it goes. Same goes for a couple of signal names. See the image posted by Perry at the start of this thread. There is a signal that is unclear if it stands for "NOR" (normal), or "NGM" (no GTIA mode). Doesn't really matter, as it is obvious the conceptual purpose of the signal.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users