Jump to content
IGNORED

Internal ANTIC and GTIA schematics


JAC!

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

post-7682-1232400523_thumb.jpg

post-7682-1232400554_thumb.jpg

post-7682-1232400583_thumb.jpg

post-7682-1232400620_thumb.jpg

post-7682-1232400650_thumb.jpg

Link to comment
Share on other sites

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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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