Found an issue on instability effects on a 800 XL with Freddie

[+tf_hh]

Hi there,

 

after having a lot of trouble with an Atari 800 XL mainboard using the Freddie-IC (PAL version) I found out an issue and a simple solution.

 

A few months ago I get an Atari 800 XL with the freddie-chip. It works perfectly with all software and so on, no problems - until I want to build in any kind of expansion. First I wanted to build in a VBXE2, it doesn´t work. Second try: a SRAM 512k memory expansion bei mega-hz --> memory failure and hangs. Third try: a DRAM 256k memory-expansion, no boot or self test with RAM errors. All of these expansions has been worked well in other machines, of course.

 

So every time when I have a free timeslot another IC was socketed and tested. Finally all ICs were changed, but the effects still happen.

 

Yesterday I tried again... and found the reason. It was the freddie power supply line, Atari make a little, but expressive failure in the PCB layout of this mainboard. But first take a look on pin 40 (power +5 volts) of the Freddie IC:

 

 

Doesn´t look okay! But ALL other +5 volt paths are clearly and one flat line - except that. So I trace the path and see, that the freddie has it´s seperate power line using the coil L3:

 

 

The bottom of this coil goes to pin 40 of the freddie IC - no other parts are connected to this path. Of the left side of the freddie you will see the usual capacitor for smoothing loading effects from a IC:

 

 

... but... and this is THE error from the layout... this capacitor is not connected to the freddie´s +5 volt path! So this important capacitor is missing and the voltage supply of the freddie is floating. This has an effect to all signals created by the freddie.

 

Now I solder a 100 nF capacitor to ground and pin 40 of the freddie as seen here:

 

 

... and all is working fine! No more problems with any of the expansions namend above, all is working.

 

So if anybody has to do with this mainboard, I prefer to add this a-few-cent-part to avoid any problems.

 

The revision of the mainboard I´ve used has no marking or number/letters on it, but I think, there´s only one PAL reivision with freddie. Don´t know, if this issue also appears on NTSC mainboards.

 

Comments welcome (especially from NTSC users).

 

Regards, Juergen

[porge]

Well spotted, Juergen - I will save this info for future reference.

Cheers,

 

Porge

[Rybags]

While on the subject.

 

Is this the definitive (ie best) method of fixing Phi2 timing problems ?

 

phi2-signalauffrischung.pdf

 

Ever since installing the 32in1 OS on my 800XL I get glitched character graphics if the ROM character set is in use.

 

In testing I can also replicate bad reads of the $E000 area to the CPU (although never have crash issues).

I think the problem is occurring when successive reads occur to the OS ROM area.

Edited July 18, 2011 by Rybags

[HiassofT]

Is this the definitive (ie best) method of fixing Phi2 timing problems ?

 

phi2-signalauffrischung.pdf

Ah, no. Actually, this is a rather bad idea, as the '123 in this configuration (with a small capacitor) isn't actually high-precision and in the worst case you might end up with more problems than before.

 

so long,

 

Hias

[Bryan]

Why not use a precision delay line?

 

http://datasheets.maxim-ic.com/en/ds/DS1100.pdf

[MEtalGuy66]

 

Ever since installing the 32in1 OS on my 800XL I get glitched character graphics if the ROM character set is in use.

 

In testing I can also replicate bad reads of the $E000 area to the CPU (although never have crash issues).

I think the problem is occurring when successive reads occur to the OS ROM area.

 

Have you tried the Bob Puff XL/XE stability mods #1 and/or #2?

[Rybags]

Done nothing yet.

 

I figured since I'm getting the Ultimate 1 Meg which will replace the 32in1 OS, I'll not do anything "permanent" until seeing if the problem persists.

 

Is the Bob Puff mod here the proper one ?

http://www.mathyvannisselroy.nl/blackbox.htm

http://www.mathyvannisselroy.nl/stabiliz.txt

[Mathy]

Hello guys

 

Forget about Bob's stability mods. Bob did a lot of very nice things, but the stability mods are not his best work.

 

Go to the BlackBox page and search for "Isn't there a real solution?". It's the second paragraph from this one.

 

Sincerely

 

Mathy

[MEtalGuy66]

WHat mathy just referenced was an external circuit to take the place of the circuit within the 6502c that generates PHI2.

 

What Bob was talking about in his XL/XE Stability mod #2 is changing the way the ROM is selected based on the speed of the outpuyt buffers on the chip. This is a little more relavent to your specific situation, Rybags.

 

Mathy, if you are going to continue to spout your rediculous oppinion based on your own specific experiences, at least couple it with some understanding of the nature and extent of the problem.

 

I've done my best to explain it to you, Marius, and others in these forums in the past, but in your case, I see that it has not sunk-in.. Maybe Hias or Candle can do better job than I did of educating you..

 

Until then, stop misleading people... Fact is that you dont KNOW what will or wont work better or worse in any given situation, where bus timing is concerned on the atari because the problems that the system is plagued with are completely relative in nature. There are many variables (I wont bother to explain them YET AGAIN here.)

 

If the ENTIRE EXTENT of the problem on your specific machine happens to be that your CPU's PHI2 generation characteristics are so far out-of-whack that it's causing problems, then what you said above may hold true in that particular circumstance, on that particular machine. You'd accomplish the same thing by simply swapping the CPU for a part that has better PHI2 generation tolerances.

 

The 74HCT123 based circuit addition that Hias came up with, (and has become customary on many recent expansion hardware designs) is the only FOR SURE correction for phi2 related bus timing issues and it is implemented on a per-device basis, not system-wide. And that is REALLY THE TRUTH about where the PHI2 issue currently stands, folks.

 

Rybags: good idea waiting until you have the final configuration in place before you try to change anything timing-wise.

[+bob1200xl]

Very nice!

 

Whether they are applicable to PH02 timing or not, (I'm not getting into that discussion...) they would be very useful in any number of circumstances. I'm going to order some...

 

Thanks!

 

Bob

 

 

Why not use a precision delay line?

 

http://datasheets.maxim-ic.com/en/ds/DS1100.pdf

[Bryan]

Glad to be of service!

[Mathy]

Hello Ken

 

I recently asked Hias which one was better, the 123 solution or the 74 solution. He told me the latter was better.

 

Sincerely

 

Mathy

[HiassofT]

Just a few remarks to the PHI2 issue (I don't want to derail this thread):

 

Basically, all of you are (partially) right.

 

Mathy's suggestion comes closest to the mess Atari originally created (creating PHI1 and PHI2 from PHI0, independently of the PHI2 output of the CPU).

 

But then, one could also just create PHI2 from a delayed PHI0 (the big question here is: how long has the delay to be?).

 

So far I don't know of a reliable solution inside the Atari that doesn't have the chance to break something.

 

So, the best solution for now is just to be aware of the problem(s) and take care of it in the upgrades. This also doesn't require any modifications inside the Atari.

 

so long,

 

Hias

[MEtalGuy66]

Mathy, the 74HC123 solution alters the duty cycle of phase 2 to make a "compensated phase 2" for use with write timings on a specific device. It doesnt "fix the problem" system wide. When implemented correctly, it does make a device operate correctly that could otherwise experience timing issues when The falling edge of PHI2 no longer coincides with the "data valid" time interval on the bus, due to one of MANY POSSIBLE/CUMULATIVE CAUSES..

 

What you are calling "the 74 solution" is just rebuilding the PHI2 generation circuits outide the CPU, using discrete logic, and then bypassing the internal ones. This only "fixes" the part of the problem which may or may not lie with the CPU, on any given machine.

 

The problem Rybags is talking about could very well be remedied by changing the "rom select" scheme, as BOB PUFF suggested in his article. Or, depending on the exact nature of the (above referenced MANY POSSIBLE/CUMULATIVE) causes of the timing discrepancy, it may not.

 

Here is the point.. As Hias just said, there is no definite universal, system-wide fix for PHI2 timing issues. Each machine has to be evaluated on an individual basis, depending on the nature of the issue in that machine, and with whatever expansions happen to be installed.

[+remowilliams]

Have you tried the Bob Puff XL/XE stability mods #1 and/or #2?

 

I worked on a machine with similar issues that I did Bob's #1 PHI mod on, and it seemed to do the trick for it.

[GoodByteXL]

Well done, Jürgen

 

Just went into the archive, that PAL XLF have an error in the pcb layout, where SECAM XLF seems to have none.

 

What about NTSC machines? Have there been any NTSC XLF machines? It seems unlikely to me that ATARI produced those just for Europe.

 

Hi there,

 

after having a lot of trouble with an Atari 800 XL mainboard using the Freddie-IC (PAL version) I found out an issue and a simple solution.

 

A few months ago I get an Atari 800 XL with the freddie-chip. It works perfectly with all software and so on, no problems - until I want to build in any kind of expansion. First I wanted to build in a VBXE2, it doesn´t work. Second try: a SRAM 512k memory expansion bei mega-hz --> memory failure and hangs. Third try: a DRAM 256k memory-expansion, no boot or self test with RAM errors. All of these expansions has been worked well in other machines, of course.

 

So every time when I have a free timeslot another IC was socketed and tested. Finally all ICs were changed, but the effects still happen.

 

Yesterday I tried again... and found the reason. It was the freddie power supply line, Atari make a little, but expressive failure in the PCB layout of this mainboard. But first take a look on pin 40 (power +5 volts) of the Freddie IC:

 

 

Doesn´t look okay! But ALL other +5 volt paths are clearly and one flat line - except that. So I trace the path and see, that the freddie has it´s seperate power line using the coil L3:

 

 

The bottom of this coil goes to pin 40 of the freddie IC - no other parts are connected to this path. Of the left side of the freddie you will see the usual capacitor for smoothing loading effects from a IC:

 

 

... but... and this is THE error from the layout... this capacitor is not connected to the freddie´s +5 volt path! So this important capacitor is missing and the voltage supply of the freddie is floating. This has an effect to all signals created by the freddie.

 

Now I solder a 100 nF capacitor to ground and pin 40 of the freddie as seen here:

 

 

... and all is working fine! No more problems with any of the expansions namend above, all is working.

 

So if anybody has to do with this mainboard, I prefer to add this a-few-cent-part to avoid any problems.

 

The revision of the mainboard I´ve used has no marking or number/letters on it, but I think, there´s only one PAL reivision with freddie. Don´t know, if this issue also appears on NTSC mainboards.

 

Comments welcome (especially from NTSC users).

 

Regards, Juergen

[Kr0tki]

The revision of the mainboard I´ve used has no marking or number/letters on it, but I think, there´s only one PAL reivision with freddie.

 

The Atari 8-bit FAQ mentions two PAL 800XLF versions - the earlier with chroma signal missing from the monitor port, the later with the signal present. I don't know if there are any other differences.

 

What about NTSC machines? Have there been any NTSC XLF machines? It seems unlikely to me that ATARI produced those just for Europe.

Unlikely, but apparently true. Only PAL and SECAM XLFs were produced; the 8-bit FAQ claims they were all produced after Tramiel's takeover.

Edited July 21, 2011 by Kr0tki

[ijor]

Interesting thread.

 

Mathy's suggestion comes closest to the mess Atari originally created (creating PHI1 and PHI2 from PHI0, independently of the PHI2 output of the CPU).

 

If you allow me, Hias, I'm not so sure I'd blame Atari. I think that it was MOS who started the mess. It wasn't really a good idea to incorporate the clock generation inside the 6502 CPU.

[HiassofT]

Mathy's suggestion comes closest to the mess Atari originally created (creating PHI1 and PHI2 from PHI0, independently of the PHI2 output of the CPU).

If you allow me, Hias, I'm not so sure I'd blame Atari. I think that it was MOS who started the mess. It wasn't really a good idea to incorporate the clock generation inside the 6502 CPU.

Sure, this is a very valid point you made. But I'd still like to blame Atari, too

 

AFAIK the MOS and Rockwell datasheets didn't specify any exact relation between PHI0 and PHI1/2. The Synertek datasheet lists a delay of 5-65ns from PHI0 to PHI2 (which is quite a big range, IMHO).

 

OTOH the MOS hardware manual states in section 1.4.2.2:

For data transfers to be properly

carried out between the processor and the various support chips in the sys-

tems, the timing of the clocks controlling the internal processor opera-

tions must be very close to that of the phase two clock out of pin 39 of

the processor with no more than two TTL delays for clock buffering. It is

important in systems which drive the clock generators with a TTL square

wave that this input waveform not be used to control the peripheral chips

unless care is taken to assure proper timing of the phase two clock being

used in these support chips.

In combination with the unspecified relationship between PHI0 and PHI2 I understand this basically as "use the CPU PHI2 output for system timing, or you are doomed".

 

Well, I guess both MOS and Atari have to be blamed for this mess...

 

so long,

 

Hias

[kurtm]

Interesting thread.

 

Mathy's suggestion comes closest to the mess Atari originally created (creating PHI1 and PHI2 from PHI0, independently of the PHI2 output of the CPU).

 

If you allow me, Hias, I'm not so sure I'd blame Atari. I think that it was MOS who started the mess. It wasn't really a good idea to incorporate the clock generation inside the 6502 CPU.

 

It's easy to say that now, when most parts are cheap cheap cheap. But back when the 6502 came out, that was a big advantage. Less support chips == affordable.

[ijor]

Sure, this is a very valid point you made. But I'd still like to blame Atari, too

...

In combination with the unspecified relationship between PHI0 and PHI2 I understand this basically as "use the CPU PHI2 output for system timing, or you are doomed".

 

Yeah But I'm not sure Atari could have made much better, not without too much pain. They couldn't use PHI2 from the CPU, because DMA would turn off PHI0 (and then PHI2, of course). So there is no real clean solution unless you want to sacrifice DMA.

 

Yes, Kurtm, it is always much easier to speak now. But not only because components are cheaper. We are all wiser after the fact.

[flashjazzcat]

And suddenly, over eight years later, this thread saves the day:

 

 

Many thanks again to Jurgen for his tremendous know-how.