1200XL RESET problems

[+bob1200xl]

Atari designed the 400/800 RESET operation to be what we call a warm start or a cold start. A cold start erases everything in memory and starts you from the beginning. A warm start only initializes a partial field of memory, allowing you to continue where you left off. On the 400/800 the RESET key just branches you into the OS, where code will determine how to proceed. Note, there is no hardware RESET, just the interrupt.

 

Fine...

 

Along comes the 1200XL...

 

The 1200XL has a RESET key that actually pulls down the RESET line in the hardware. From there, the OS determines the type of RESET being called. Seems reasonable. This allows you to RESET the hardware and the OS without relying on an interrupt.

 

Only problem is that this RESET line needs to be 'clean' if you expect the process to succeed. Many 1200XLs are deficient in that respect. When you are sitting in BASIC and you hit RESET, you should get a warm start. Whatever program you had in memory should still be there. If the RESET circuits deal you a cold start, all your data will be lost. Not good...

 

This is a common problem in 1200XLs. Hitting RESET is a crap shoot. Why? The RESET circuit becomes active at 0.6v or so when you release the key. This is an indeterminate space for a TTL circuit, ripe for noise corruption from the ground plane. If you replace the 74LS14 with a 74HC14, the active input sits up over 2 volts, a much stabler place to be.

 

If you replace the LS14 with an HC14 (I'll try an AC14 when I get some), the R/C time constant is stretched out quite a bit. You can fix that by replacing C7 with a 15-22ufd capacitor. 12 volts or better, aluminum electrolytic. I don't bother with this, but you all may not like the delay in RESET.

 

Try this on your 1200XLs and let me know how you make out!

 

Bob

 

[Rybags]

I've not powered mine (or most of my old gear) on for some time now.

 

The problem is also partly software - there's a "feature" where Page 3 of RAM gets cleared but there's a slight delay before the 3 magic numbers that ensure a warmstart get populated again.  So if you hit the key twice with the right timing (which seems reasonably easy once you work it out) or as you describe, the circuit is a bit dodgy, then you can get that inadvertant cold-start.

 

What they needed to have done was considerably shorten the delay in setting the magic numbers - it's only a fraction of a frame but with a bit of extra code overhead could have been done better.

 

[+kheller2]

Isn’t that what OS rev 11 addressed with reset?

[flashjazzcat]

This is, I think, the exact problem which frequently necessitates a cap between RST and GND on U1MBs installed in 1200XLs. The U1MB would get an additional 'echo' reset signal which was not sufficient to reset the actual base machine a second time. This resulted in the default U1MB 'unlocked' state being triggered after the user had already entered the U1MB setup menu with HELP+RESET. The firmware had enabled RAM under the hardware registers, etc, but then along came multiple reset pulses sufficient for the CPLD to reset the board without the 6502 (or the U1MB firmware itself) knowing anything had happened. Result: screen full of garbage.

 

[+bob1200xl]

The first thing the r10 OS does is check the validation numbers. If they are present, the machine warmstarts. If not, coldstart. The r11 code runs a do-nothing delay loop first, then checks the validation numbers.

[+kheller2]

1 hour ago, bob1200xl said:

The first thing the r10 OS does is check the validation numbers. If they are present, the machine warmstarts. If not, coldstart. The r11 code runs a do-nothing delay loop first, then checks the validation numbers.

Is the 800XL OS that different, or is the RESET hardware also different?

[+bob1200xl]

The 800XL RESET hardware is the same. The OS code is the same as r11 on the 1200XL.

 

The comment in the OS listing says '.1sec delay for RESET bounce'

 

Bob

[flashjazzcat]

That's interesting, then, and presents the question: why does the U1MB 'noisy reset' problem almost exclusively affect 1200XLs when the OS cannot possibly be a factor (since the U1MB firmware maps to the OS ROM space the moment reset is pressed)?

[Rybags]

It's somewhat more than .1 second, I'd put it closer to to 1 second.

But yeah, I deduced way back that it was probably a debounce thing.  I think having no delay would make accidental coldstarts a lot more likely.

 

On the other hand - looking at the code for 800XL - the delay between clear and set of the numbers isn't very long.  But I used to be able to get a coldstart from about 1 in 10 attempts.

Could it be something else?  Maybe Reset affects GTIA and you get a different TRIG value which makes it think a cartridge change has occurred.

[_The Doctor__]

I can still get a cold reset on XE's and XL's by tickling the reset key in an erratic and frantic manor, I'd suspect everyone can.. I've performed that method when I don't want to lose what connected to the Atari and the Atari appears locked up... warm reset still locked, device is powered by the Atari... so tickle the reset key a few different times until it cold starts... then save it off or do what I need to. I had thought about purposely making the reset type select-able via hardware... never bothered though...

Edited January 26, 2022 by _The Doctor__

[Rybags]

XE seems to just pulse Reset on release of the key - in my experience still possible but not as easy as XL to force the coldstart.

[+bob1200xl]

FJC: If RESET maps the OS, is that to the 1200XL OS?

 

I would expect that changing the logic physics (swap IC types) would take timing events out of the picture. i.e. the RESET level would need to be >2v in order to be active. Otherwise, the timing is irrelevant since it is below threshold.

 

Can anyone try a 1200XL with a new 74HC14?

 

Bob

 

 

[flashjazzcat]

1 minute ago, bob1200xl said:

FJC: If RESET maps the OS, is that to the 1200XL OS?

No: when U1MB is present, the firmware ROM immediately gets mapped to the OS ROM address space (U1MB having completely replaced the OS ROM). The firmware has a stabilisation delay which works everywhere but on the problem 1200XLs.

[+bob1200xl]

OK - I bought some 74HC14s from Jameco. They were all BAD - like broke the 1200XL. I don't have a problem with Jameco, been buying from them for 50 or 60 yeras. But, be aware, they are thin on some things.

 

Got some 74AC14s from Digikey. They work great! So far...

 

Anybody that needs just one 74AC14, I can drop one in the mail.

 

We can ship 50 or so over to Europe if someone wants to manage this. ( or order directly from Digikey)

 

Bob

[ACML]

On 1/29/2022 at 6:35 PM, bob1200xl said:

OK - I bought some 74HC14s from Jameco. They were all BAD - like broke the 1200XL. I don't have a problem with Jameco, been buying from them for 50 or 60 yeras. But, be aware, they are thin on some things.

 

Got some 74AC14s from Digikey. They work great! So far...

 

Anybody that needs just one 74AC14, I can drop one in the mail.

 

We can ship 50 or so over to Europe if someone wants to manage this. ( or order directly from Digikey)

 

Bob

After reading this thread I was curious if my 1200XLs had this cold start in BASIC feature (i.e. you lose the code in memory on RESET).  Not a wanted "feature".  I run both the 600/800XL OS and the Omniview XE OS in my 1200XLs.  

 

1) When using the the 600/800XL OS, a press of the RESET key retains the BASIC program in memory. This is good!

 

2) When using the Omniview OS, which is based on the 400/800 OSb, a press of the RESET key yields a cold start and you lose your program in memory.  Not Cool !

 

I bought some SN74AC14Ns and swapped out the SN74LS14N.

 

1)  There is a noticeable prolonger "One MISSISSIPPI" pause before its returns a result.  I guess Bob is saying that if you change C7 from 47uF to 22uF, it reduces the delay, but it does fix the RESET issue using Omniview.

 

2) The 600/800XL acts the same with the addition of the new "One MISSISSIPPI" delay.  Program in BASIC is intact!

 

Conclusion:  The 1200XL Rev 10 OS and other OSs using the 400/800 OSb (like Omniview) will provide an unwanted cold start on the 1200XL with the OEM SN74LS14N.  Replacing the LS14 with an AC14 will fix the issue!  Or you could go to Rev 11 1200XL OS or 600/800XL OSS to remedy as well.

 

Thanks Bob.  You learn something new every day!  Has anyone tried replacing C7 from a 47uF to a 22uF capacitor yet?

 

 

  

Edited April 3, 2022 by ACML

[ACML]

Looks like I need to amend my conclusions.  A sample of one is not exactly sufficient.  Pulled out three more 1200XLs configured exactly the same as the one previously mentioned.  Even with the Omniview OS, the cold start feature is not present.  A press of the RESET key on the next three all kept the BASIC program intact.  So what's the independent variable here?  Only thing I can surmise is that the one board with the unwanted feature has the really glossy shiny finish on the PCB.  The other three have PCBs that are a dull flat green without the glossy sheen.  Different lots for sure, but are there differences in the component sourcing inside these lots that make the glossy one different?  Then there is also the coincidence, maybe not, that this glossy motherboard 1200XL also has the intermittent lock up problem when using a Defender cartridge in extended DEMO mode.  The other three do not.  So maybe the RESET issue is not universal to the 1200XLs, but only ones with certain lot number motherboards.  My guess is the high gloss ones were early runs and the majority do not have this high gloss sheen.  Also, in my experience of doing many ClearPic 2002 mods, the ones with the glossy shine motherboard for some reason have a more pronounced jailbar issue than the ones with dull and flat PCBs (same video cables).  Again, if the traces are the same, is there a component sourcing selection issue on some lots that make them more prone to issues?

[+kheller2]

56 minutes ago, ACML said:

Different lots for sure, but are there differences in the component sourcing inside these lots that make the glossy one different?

It has been a while since I looked at the 1200XL revisions, but I thought the glossy vs matte boards were different revisions.  

[+bob1200xl]

Some 1200XLs need a new C7 (only tried a 47ufd - a 22ufd will probably be OK) cap as well as a 74AC14.

 

The Defender bug is a CPU problem as far as I can tell. Put any kind of 65816 in there and Defender is happy again.

 

Bob

 

[ACML]

I guess the best way to quickly tell if your 1200XL has a reset problem is to do the following:

 

1) Boot 1200XL with just BASIC.

 

2) Type in simple program:

    10 PRINT "HELLO WORLD",

    20 GOTO 10

    RUN

 

3) While the program is printing to the screen, press the RESET button.

 

4)  Type LIST and if the program is still in memory, repeat hitting RESET about a half dozen times and checking the program each time using the LIST command.

 

5) If the program is still in memory, you don't seem to have the issue.  If however the program is lost (erased), you likely have a cold RESET problem when you should get a warm RESET.

 

If your 1200XL dumps the memory and you lose your BASIC program, you can remedy this by swapping the SN74LS14N for a SN74AC14N.

 

   

Edited April 4, 2022 by ACML

[Rybags]

Or - simple colour change to green that will indicate it's a warmstart.

 

10 FOR A=1536 TO 1541:READ D:POKE A,D:NEXT A
20 POKE 2,0:POKE 3,6:POKE 9,2
30 DATA 169,196,141,198,2,96

[ACML]

I replaced the C7 (47uF axial) capacitor with a 15uF axial like Bob suggested in the hope of reducing the "one Mississippi" delay on reset when you swap the 74LS14 with a 74AC14.  It worked great!  The delay is imperceptible to the original 1200XL reset behavior.  The delay went from 1 second (C7=47uF) to 1/4 second (C7=15uF) with a 74AC14 installed.  The program in BASIC reliably stays in memory after RESET like it should.  

 

Thanks again Bob!  

 

 

[ACML]

On 4/3/2022 at 7:15 PM, bob1200xl said:

Some 1200XLs need a new C7 (only tried a 47ufd - a 22ufd will probably be OK) cap as well as a 74AC14.

 

The Defender bug is a CPU problem as far as I can tell. Put any kind of 65816 in there and Defender is happy again.

 

Bob

 

Bob,

 

I tried the 15uF instead of the 22uF to replace the original 47uF and it worked great. I used a 15uF 35v axial alum electrolytic.

 

I know what you're saying about the Defender bug, but try this out.  When I replaced C7 from 47uF to 15uF, the Defender crashing on demo bug seems to have been cured as well.  With the original 47uF at C7, I could never get the Defender demo not to crash before 700,000 points.  With the 15uF at C7, not only did it reduce the delay time on reset, I got the Defender demo to 1.4 million twice and it was still trucking.  No more lock ups.  Maybe today's two extended runs were just that, two good runs, but I could never achieve this before on this board let alone twice in a row.  Go figure.

 

P.S.  The Defender demo crash only happens when you are using the cartridge version.  Loading a CAR or XEX won't have an issue.  Must be hardware related to cartridge port.

 

 

 

 

 

Edited April 13, 2022 by ACML

[_The Doctor__]

looks like one to add to the 1200XL fix compendium!

[+bob1200xl]

Interesting....

 

RESET is active at .6v on any 1200XL with any NMOS CPU. (all the 6502s are NMOS) If you use a CMOS CPU (65816), it is active at 2.0v. I can't see any direct connection between RESET and the CART port, but I'll bet there is fierce cross-talk in the vicinity of RESET. Anything you do to clean up RESET may then have results CART.

 

I'll have to try that.

 

Bob

 

 

[ACML]

Just to follow up on farther testing of the 15uF C7 replacement WRT the Defender lock up issue.  This weekend I achieved over 1.5 million twice with no lock ups.  Can't explain why, but this seems to have cured that issue too.  Maybe also fixes the 1200XL and 1MB Ultimate reset issue too.  

Edited January 3, 2023 by ACML