Windless

Hi, according to 8bitworkshop and stella, the VBLANK bit if set to 1/0 affects the cathod ray 1 TIA Cycle avec it's commited on the bus by the CPU. Is this documented somewhere ? I couldn't find reference to this in the documentations I have. Thanks, Windless. Test code : ldx #64 ScanLoop sta WSYNC SLEEP 20 lda #$aa sta COLUBK lda #$34 sta COLUBK lda #$aa sta COLUBK sta WSYNC SLEEP 20 lda #$aa sta COLUBK lda #%00000010 sta VBLANK lda #%00000000 sta VBLANK sta WSYNC dex bne ScanLoop Result : https://8bitworkshop.com/v3.5.0/embed.html?p=vcs&r=TFpHAAAQAAAAAJFODB%2FcAQMEBQZ42KIAiqjKmkjQ%2B6kChQEGYQCFAgYiqQCFAKIlhQLKBREAhQGiQIUC6gYHqaqFCak0BmEG4QQPEAV%2FBSoFc8sFRaIeBb5MC%2FD%2FBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GDADwAPA%3D

ho,ok. This would be testable with a fast oscilloscope. I'll try with mine (maybe pushing it a bit) when I'm done with the schematic and I can resolderparts andtry to feedthe TIA with a PAL-I signal

Do we have schematic of the PAL TIA ? I couldn't find one so I'm trying to random guess lot of things . Ok I am not sure I understand. My hypothesis was that the color register (left part of sheet 5) contains the same value, but that the bit are XORed before being used to selected the Color Phase Shift Delay cell on odd lines. From what you tell, I think (and it's very likely since it would be simpler and would work) that they probably just delay or NOT the color burst and leave the COL signal the same. But I don't understand how that would explain the need to remove 3 lines of colors nor to loose the possibility to have a 0° color ? On the other hand, some sources say the phase is reversed on odd/even lines, but some indicate (as you do) that they are 90° rotated. With 90° rotation, I can't explain the organisation of the PAL palette.

Something else just came to mind: If the delay is the same on PAL tia as it is on NTSC, then color adjustement potentiometer would only increase delay between the cells of the color phase shift delay. So instead of having e.g. 0°, 15°, 30°, ... for colors $1x, $2x, $3x, ... you could get 0°, 16°, 32°, ... This would work on NTSC, but on PAL if what I guess about the XORing on odd line is true, that means that if you add by adding 1° per cell, colors $Ex would get 13° shift when $1x would only get 1°, which means that the phase shift between them would go from 180° to 193°. Maybe the delay pot works differently (e.g. adjust only the first color) and this has some impact on the possibility to display 0° colors, hence leading to suppression of color $1x and $Ex ? Anyway, this would be a good way to test if the colors are indeed XORed on even lines : either the col adj pot adds the same delay on all cells (and that would partially confirm the hypothesis), or it works as on the NTSW TIA and then adjustment of colors would not be the same for ODD and EVEN lines.

Thank you, I think I now have a better understanding of the shift register (which is my second hypothesis + the delay pot hat I thought added delay but in fact changes the shift speed) I also read this in the meantime which helped. I still don't get something. Imagine I wanted a simple solution for this problem : -I'd reorder the output of the Color Select Decode part of the TIA so color $2x, $4x, $6x, ..., $Cx would cover hues 0..154° and colors $3x, $5, ..., $Dx would cover 180..334°. -I would have a bit that toggle on each line (0 for odd lines and 1 for even lines) and XOR this bit with the first color bit on the Color Select Decode, so every color would get shift +-180° This could also work with another bit of course. The problem would be with $0x (greys) that became $1x (color) and vice versa. Easy solution would be to make $1x color also grey, and the PAL TIA would lose 8 colors. The PAL TIA does lost the $1 colors, but: -Toggling first bit doesn't help anyhow finding the +-180° color in the TIA's palette -It also lost colors $Cx and $Dx Now if we make a graph of the HUE (in °) vs higher nibble of the color, we get something like this (all graphs should be labelled from 0 and not from 1 on X axis): the shape seem to have two different logic: -we have an alternation of growing and shrinking levels -for the first three value, the order seems to be reversed. alternating sizes of the bars tell us that it's not the lower weight bit that is XORed but the higher weigh one, so on odd lines, color 0 is swapped with color 15, 1 with 14, 2 with 13, ... The "reverse order" of the first three bars can be explained if we guess that the hue has just wrapped around the 360°. Let's add 360° to bars for colors $3x and $5x: That seems ok. The HUE for odd values seems to be : (3.5 + Cn) * 14.5° For even line, we toggle bit 15 and add 180, so this becomes 14.5*(BITXOR(15, Cn)+2.5)+180° Where Cn is the higher color nibble (top four bits) of the color number. Color with nibble 0 is swapped with colors with nibble 15, but since it is greyscale it must not change, so colors $Ex need to be replaced with greyscales. Now, why does the yellows ($1x) disappear (together with the pair $Dx) ? What we know from the NTSC TIA schematic is that color $1x don't get any delay from the color phase shift delay. It might be possible that the XORing takes some time and some delay is required. Indeed if I remember correctly, the color $2x on the PAL secam is not yellow (as $1x on NTSC), the first colors ($2x) have nearly the same hue as $2 on the NTSC. It still would be possible to have colors $Ex, but then on even lines they would appear as grey. And if someone use the grey $1x, thy would get the color of $Ex on even lines. So they had to suppress it. Is this model likely to be true ?

Ok. I'm rather slow on making the schematic of my Rev8 board. In the mean time I tried to understand things about the generation of the hue and saturation signals on the TIA COL pin. If I understood correctly: -On the NTSC 2600, the clock on the TIA is the same as the color burst frequency (3.579545MHz) (228 clock per line, 262 lines per frame, 60 frames per second -> 228*262*60=3584160, 0.13% error) -The TIA generates the HUE by outputting the CLOCK input on COL, but it shifts it depending on the hue part of the color number (that is color/16 see color chart). The amount of shift is (7 + hue) * clock_period/16, that means that colors $2x will have a shift of 17.460ns more than $1x We often see this kind of drawing when looking for information about NTSC encoding : But in the case of the NTSC TIA where pixel frequency is the same as the color carrier frequency, it means that we would have only one oscillation on each pixel (or in this picture, we draw five consecutive pixels of each color). And the signal output by the TIA is probably square and not sinus. Now on the PAL TIA, the clock is 3.546894MHz, when the color carrier is 4.43361875MHz. I have two hypothesis here: -if the *16 clock used to shift the clock 16 times per clock to generate the 16 possible outphasing is generated from the the TIA' clock, on the PAL TIA it would give a 56.795104MHz clock. With respect to the 4.43361875Mhz frequency of the PAL color carrier, it would mean the the outphasing would be 0 to 12.8/360°,that would be 12 different hues plus grey. Indeed, with 8 luminance-saturation per hue in the palette, it makes 13*8 = 104 different colors on the PAL 2600 -if the delay for the 16 possible shifts is independent of the clock, and fix at 17.460ns * (color/16), it would range from 0 to 262ns. So the shift would be from 0° to 360*1.1616... out of the 15 possible valued, the 13 first colors would be different, then we would wrap around 360°... that would also give 104 colors. Something I don't understand is why the color are in different order with the PAL TIA. Maybe it is because : -the shift is not 1/16period per color but 9/16 for some reason I don't get (so we have a +180° rotation on each line of the palette) -the inside of the PAL TIA has been weirdly designed where the color<->shift mapping is made* -this is related to the PAL encoding that shifts the phase 180° for each line. On the PAL TIA this shift would be made not only on the odd/even bit of the line number, but on this bit XOR the heavy weight of the color, for some reason I can't understand. Windless. * : seems unlikely. Add they made a different "color select decode" (see sheet 5 on https://atariage.com/2600/archives/schematics_tia/index.html), it would have been easy to match the NTSC palette with at least a good approximation

Ok, I think I spotted something very weird : 10kr between the jack connector and the ground plane. I disoldered the connector and found that the soldering of the pin 1 was very poor : solder didn't reach the front side of the pcb. This + the bent pin on that IC makes me wonder what happened to this 2600 I continue trying to make a schematic. I need some help identifying those two components (they are labelled C-something so must be capacitors, but my DMM can't identify them) : The green one at the bottom reads"J5L 301",and the one just above it which looks like an SMD capacitor inside a diode housing On my other Rev 8 PCB, the green one is replaced with a yellow - purple - brown - black - gold capacitor (470pF 10V 5% ?),and the two green ones transparent ones are like the green ones on this board and shows "CGW 103 M5K"

I could see no trace of previous unsoldering on the chip, but it is possible indeed.

Ok, weird thing number one: The is exactly one 74ls138n. It is labelled A212, and probably serve the same purpose as the Z212 on your schematic. The thing is that thought there IS a track to pin 3, this pin was bent under the 74ls138n and not soldered. This is not the case on my other V8 secam board. Three possible reasons I can think of : -This 2600 has been tempered with -The people who did the original soldering job had a problem with the chip and forces it into the holes -The though the revision of the board is the same, some change were included on the board (the 6507 and the TIA aren't the same)

Approximativately getting there Most places look like this: Top right corner is poorly aligned but usable: Now is time to install Kicad.

ok, I'll try, and probably learn a lot Did you desolder all / most / some chips to do your schematic ?

Hi ChildOfCv, I missed this post. Very nice job Maybe it's not worth doing the work again with my rev 8 that seems very similar. Another option is to try to fix mine, and then used the previously-no-worknig one to try the PAL or NTSC conversion

Thank you. This is approximatively what I guessed I would do it's good to know it's correct. Also you made me think of setting the proper size in the drawing if, e.g., someone wants to make new PCBs one day. One question I have is about the tracks that goes under the components : -Some will be easy to track by looking under the components (e.g. the one under resistors) -Some will be impossible (ICs needs to be desoldered to make sure they dont hide any T track I guess ?) -Some may look like they can be tracked easily but lead to errors What strategy do you suggest ? Remove all components ? At That would help reading the silkscreen to get all component original nomenclature, but take a lot of time.

I made a cheapo lightbox, it's a bit better though I don't have a stand and I'm not sure I can superpose the pictures of both side of the PCB to follow traces without any error. (picture is flipped, as if seen from above the 2600 through the fiberglass)

Pictures of the PCB before any desoldering. I'll probably need to build a better setup to take pictures (any suggestion ?) I tryed puttin the PCB in my scanner for the backside, but the result is mostly blurry. Maybe desoldering every component can solve the problem ? Windless.

Hi, I bought a second Atari 2600. My two 2600s are SECAM, both have a PCB which is marked CO17890 REV8 on the backside and CAO17883 (REV field unfilled) on the front side. The second one is not working, instead of trying to fix it I will desolder the components I need in order to have a public and usable schematic of the ATARI 2600 Secam since it apparently is not available. I wil need your help Windless. As an experiment, if people want to financially contribute to this project, they can donate to https://www.paypal.me/ftregan . I do not need this money to eat or pay my rent, so please do not donate if you do. The cost for this project for me will be 20€ (15€ for the 2600 and 5€ for a solder pump). If more money is received, I'll spend it on other community, free, open source and open hardware 2600 related projects.

Hi, Just a quick update to say that: -I'm done with my other over-timeconsuming occupations, and can now work again on this subject -I've bought another 2600 : after inspection, it's not working but is SECAM and has the same revision of the same PCB as my other one. Perfect candidat for a complete teardown and PCB scan ! Windless.

Yes, I did. If you want me o try getting it from the crystal or test something else, jut ask. Thank you for all the help you provide Windless.

Ok, sorry I haven't been clear let me try to fix that : -I first measured with a disconnected 2600 between TIA 3.54The MHz clock input and the clock input of the 74LS174 so i thought they my be connected though a resistor or something. Then I tryed to follow the track from the 74LS174 clock pin,and found it reached the NAND gate -the weak clock signal,yellow in the fist two picture of my previous message,is the TIA clock pin -the clean (but a bit overshooting) clock in the last picture is taken at the clock pin of 74ls174 and comes from the output of the NAND gate. I didn't follow the entry of this gate but since the output is same frequency and inverted when compared to the TIA clock, I guess that is where is comes from. That's what I expected to find, but manually digging through the first 50.000 points I recorded, I didn't see that happen.

the NAND gate is used to generate a clock signal that is the inverse of the TIA clock : if we look at how the LUM signal rises after the TIA clock,we see it is not completely ready when the clock rises : With respect to the inverted clock from the NAND gate, on the other hand, it is more reliable : Ok, so I have a clan LUM signal I can use, but it is half a (TIA) clock delayed compared to COL and SYNC.

I've found he datasheet of the SGS T74L1741B,the exact same one that is on my 2600 here. In the meantime, I also stopped confusing D-flipflops and T-flipflops, and now can tell : the T74LS174B1 has the same role as the CD4050 : it buffers the LUMx signals (only LUM on the SECAM) in addition, it is clocked with a 280ns (this is the 3.54...MHz used by the TIA but it does not share the track with it : the signals comes from a SN74LS00N quadrulple NAND gate - maybe the TIA also gets its clock from there but with a DMM I find a 2kR resistance between T74LS174B1 clock and TIA clock - maybe the clock is delayed to wait for the TIA to output on its LUM pin before the flipflop clocks it ?) !MR (reset) of the T74LS174B1 doesn't seem to be used. So I apparently could take the LUM signals from the hex flipflop.

ok, apparently the T74LS174B1 is not a T74LS174. It seems to be just a buffer like the 4050 : the T74LS174 as a !MR (master reset ?) but the datasheet says it set output to 0 whatever Qx is, so maybe they are just different components ? I have a 2x12Mpts record (12MB once compressed) if someone wants to have a look.

The PAL version of the field manual gives some answer : The cheapest 8MHz crystal on mouser has a 25ppm precision, we can hope the crystal on bluepills is not more than 400 times that, so +-0.04MHz s really possible Now the 4.43MHz clock will have to be derived from the 72MHz bluepill. The period of the PWM signal generated by the timer can be adjusted with a one cycle precision. We need 6.5% precision and we have 1/72.000.000 precision Conclusion : precision is not an issue. Output level might be if the clock signal should not oscillate between 0 and 3.3V, but if there is a bluepill anyway, adapting the outputwill still be easyer / cheaper than making a complete clock. Synch with the 900kHz signal from PAL-S can still be an issue thought.

Some guy sells 2 dead motherboard for 15€ in france, but he is on the other side of France and do no want to ship them to me

Ok, there is definitively something I don't understand : if the part that are connected to pin 7 of the DB9 port and stady +5V, and pin 8 stay at GND, then I see no way out for the audio signal : Is the schematic missing some connection, maybe from the left part of R210 to the RF module ?