RAM 320XL

[ctirad]

I had a quick look in the 600xl schmatics and must say I didn't get it. The article says connect pin 4 to pin 13, and there I see connected pin 1 and 4 on your picture. Either case don't make much sense to me as it directly connect two output signals.

[spookt]

You need to read the corrections on Mathy's site.

[ctirad]

Still don't get it. Or the schematics I have is buggy.

[flashjazzcat]

Surely pins 1 and 4 of LS08 are both inputs, so basically you're altering the output of pins 3 or 6 by connecting pins 1 and 4 (depending on which output we're trying to change). Pin 13 is an output. I'll give this a try on Dom's Rev B board.

Edited August 17, 2010 by flashjazzcat

[ctirad]

Surely pins 1 and 4 of LS08 are both inputs, so basically you're altering the output of pins 3 or 6 by connecting pins 1 and 4 (depending on which output we're trying to change).

 

The pins 1 and 4 are sure inputs of LS08, but they are connected to output signals O2 and O0 of the CPU and ANTIC. I compared it with the 800xl schematics and it seems, there is swapped pins in my schematics and the correct pin is the one with the pullup (5 on the picture). Then it is electrically correct, but I can't see any relation to the PBI as it just shorts the cycle for the ANTIC.

Edited August 17, 2010 by ctirad

[walter_J64bit]

I'm going to try out this mod out, when I get back home!

[ctirad]

I found the bug. It makes perfect sense now.

 

[+Guitarman]

So, to be clear, we only have to do MOD-1??

[flashjazzcat]

So, to be clear, we only have to do MOD-1??

Looks like it. At first I thought we had to chop pins 5 and 4, but I now realize this is a correction to the pin numbering on the schematic. Gonna try this tonight Dom, if you're watching!

[flashjazzcat]

Good news: I just tried this mod on beamer320i's Rev B 600XL and it works:

 

 

We've been waiting about a month to see that.

Edited August 17, 2010 by flashjazzcat

[Almost Rice]

So, to be clear, we only have to do MOD-1??

Looks like it. At first I thought we had to chop pins 5 and 4, but I now realize this is a correction to the pin numbering on the schematic. Gonna try this tonight Dom, if you're watching!

 

Just remember to use the Mathy corrected Mod-1 instructions for the 600xl.

Edited August 17, 2010 by Almost Rice

[spookt]

Good news: I just tried this mod on beamer320i's Rev B 600XL and it works:

 

 

We've been waiting about a month to see that.

 

Great! As soon as my sockets turn up tomorrow I'll try that on mine. I'm halfway through a Stereo install at the moment and there's no Pokey on my 600XL board.

 

Thanks too to Almost Rice for figuring it out

[Almost Rice]

Thanks too to Almost Rice for figuring it out

 

It was no big deal. I figured it was a timing issue and read Larry's post Are 800XL's less stable than 65/130 XE's? He mentions Bob Puff's stability mod. From there, I googled Bob Puff stability mod and found Mathy's site. Then read the article and Mathy's corrections. When it mentions PBI devices, memory, and phase 2 timing, I figured I was onto something. I looked up the changes I needed and made sure it would not burn up anything and applied it on the 600xl that was having problems.

 

So we can thank Bob, Mathy, Google, and Larry in that order.

[Mathy]

Hello guys

 

I'm glad I helped solve this problem, even if it only was by providing information in a very indirect way.

 

But I have to tell you, that there are better ways to stabilize your Atari then Bob's stabilizer mods. Hias is one of the guys that can tell you more about recreating a decent Phi2 signal. BigBen might be able to help as well, as might mega-hz be.

 

greetings

 

Mathy

[Defender II]

Hello guys

 

I'm glad I helped solve this problem, even if it only was by providing information in a very indirect way.

 

But I have to tell you, that there are better ways to stabilize your Atari then Bob's stabilizer mods. Hias is one of the guys that can tell you more about recreating a decent Phi2 signal. BigBen might be able to help as well, as might mega-hz be.

 

greetings

 

Mathy

 

Thanks for all of your work and for a ready reference site.

 

In your correction txt file, you mentioned to use specific unused pins on specific chips on the 600XL. There are several 600XL PCB revisions out there, have you come across any that these corrections may need to be connected to different pins?

 

I hope Hias, BigBen, mega-hz or someone will come up with a comprehensive mod that takes into account all of the stability mods for the 600XL as I am switching to it as my primary Atari 8-bit.

[walter_J64bit]

I did Bob's stabilizer mod to my 600XL runs just fine with AIR BAll cart using the RAM 320XL (jumper on) but it locks ups with my MyIED cart. I haven't used a disk drive with it yet, oh one thing the 600XL won't boot up with the RAM 320XL jumper off! Bob said something about swapping out the 6502, I think I have one from other 600XL that's dead I'll see what that does.

Edited August 18, 2010 by walter_J64bit

[Mathy]

Hello Defender

 

In your correction txt file, you mentioned to use specific unused pins on specific chips on the 600XL. There are several 600XL PCB revisions out there, have you come across any that these corrections may need to be connected to different pins?

I didn't look at the PCB's, I looked at the original schematics from Atari.

 

sincerely

 

Mathy

[HiassofT]

Hi!

 

I guess it's time to setup an Atari PHI2 timing problem FAQ :-)

 

so here we go:

 

Q: Is Bob Puff's Stabilizing mod the solution?

A: Not really. While this mod works for a lot of people it introduces issues with devices like the MyIDE interface. It also changes the read timing which might not be a problem for current hardware but could lead to issues with future (CPU-) expansions. Another drawback is that users have to modify their Atari, so this mod is not an option for plug-and-play expansions.

 

Q: What's the cause of those issues?

A: As Bob correctly wrote the PHI2 signal is staying at a logic hi level too long. This is really bad, as most chips execute write operations on the trailing edge (lo->hi) of their /WE and/or /CE inputs, which is usually derived from the trailing edge (hi->lo) of PHI2. Due to the "late" PHI2 the address and/or data-bus is already in an invalid state which leads to corrupted writes (wrong data and/or wrong address being written). Note that this also affects bankswitching carts etc. Some 20 years ago this was not a big problem as chips usually were a lot slower and they didn't "notice" the data/address change just before the write. But nowadays chips are a lot faster and this is a very common problem.

 

Q: So what can we do about it?

A: There's a really simple solution for most devices (RAM extensions, bankswitching carts etc): shorten the /WE pulse (or the /CLK pulse going to your register). Use a 74HCT123 monoflop, connect the inverted (A) input to GND, the non-inverted (B) input to PHI2, use a 5k6 resistor and a 33pF capacitor, and use the non-inverted (Q) output as a new "PHI2" signal for generating /WE signals. Have a look at http://www.horus.com/~hias/freezer/hardware/schematics-xl.pdf how I did this for the Turbo Freezer 2005 (please note that the 74HCTxxx chips are all wrongly labeled as 74LSxxx, you have to use HCT types).

 

Q: What's the 74HCT123 doing?

A: The '123 is configured as a monoflop which is triggered on the rising edge of PHI2. The resistor and capacitor determine the length of the generated (high) pulse and were chosen in a way that the new pulse ends a little bit (some 50ns) before the original PHI2 signal. Of course the '123 also introduces a delay, so the output of the '123 goes high some 30ns after PHI2 goes high. So the total pulse width is shorter than the original PHI2 pulse width. This is no problem for current RAM/ROM/flash/... chips, which usually have access times lower than 100ns.

 

Q: Are there other possible solutions?

A: Yes, several:

A1: If you have an internal upgrade (like a RAM extension) you can simpliy use PHI0 AND PHI2 for generating /WE signals. This is similar to the original "stabilizing" mod, but only affects the /WE signal.

A2: You may also use PHI0 instead of PHI2 for generating /WE, this works fine with the MyIDE interface (which has big problems if the length of the /WE pulse is shortened), but it may not work with other chips (the BSI RAMs, for example).

A3: If an extension only uses the address lines and if you use a CPLD you may simply latch the address lines during PHI2 = high. Note: this is not an option if you also use the data lines, as on write operations the data lines are valid AFTER the rising edge of PHI2, the address lines are already valid some time BEFORE the rising edge of PHI2.

 

BTW: The Turbo Freezer 2005 uses both the '123 (for fixing RAM and flash access) and input-latches for the address lines in the CPLD. Before I added this modifications I had several timing problems, mainly with XEs, after this mod everything was fine.

 

My 512k SRAM extension uses PHI0 AND PHI2 in the GAL to generate /WE, and I have an internal homebrew MyIDE interface where I just use PHI0 to generate /WE (IOWR) to the IDE drive. Using PHI0 and PHI2 didn't work, I assume the resulting signal was too short (but I didn't investigate this any further).

 

so long,

 

Hias

[+bob1200xl]

OK... a couple of questions.

 

What difference does it make when PHI2 falls? Doesn't everyone hold the address and data valid until PHI2 drops? Even if /WE falls before PHI2, the data and address should still be valid. /CE signals are decoded from the address buss. As long as the address is valid /CE will be OK. Who drops off the buss before PHI2 falls? How is that timed? Only two chips generate /WE - CPU and ANTIC. Is that what you are moving - when /WE falls relative to PHI2?

 

Bob

 

 

 

Hi!

 

I guess it's time to setup an Atari PHI2 timing problem FAQ :-)

 

so here we go:

 

Q: Is Bob Puff's Stabilizing mod the solution?

A: Not really. While this mod works for a lot of people it introduces issues with devices like the MyIDE interface. It also changes the read timing which might not be a problem for current hardware but could lead to issues with future (CPU-) expansions. Another drawback is that users have to modify their Atari, so this mod is not an option for plug-and-play expansions.

 

Q: What's the cause of those issues?

A: As Bob correctly wrote the PHI2 signal is staying at a logic hi level too long. This is really bad, as most chips execute write operations on the trailing edge (lo->hi) of their /WE and/or /CE inputs, which is usually derived from the trailing edge (hi->lo) of PHI2. Due to the "late" PHI2 the address and/or data-bus is already in an invalid state which leads to corrupted writes (wrong data and/or wrong address being written). Note that this also affects bankswitching carts etc. Some 20 years ago this was not a big problem as chips usually were a lot slower and they didn't "notice" the data/address change just before the write. But nowadays chips are a lot faster and this is a very common problem.

 

Q: So what can we do about it?

A: There's a really simple solution for most devices (RAM extensions, bankswitching carts etc): shorten the /WE pulse (or the /CLK pulse going to your register). Use a 74HCT123 monoflop, connect the inverted (A) input to GND, the non-inverted (B) input to PHI2, use a 5k6 resistor and a 33pF capacitor, and use the non-inverted (Q) output as a new "PHI2" signal for generating /WE signals. Have a look at http://www.horus.com/~hias/freezer/hardware/schematics-xl.pdf how I did this for the Turbo Freezer 2005 (please note that the 74HCTxxx chips are all wrongly labeled as 74LSxxx, you have to use HCT types).

 

Q: What's the 74HCT123 doing?

A: The '123 is configured as a monoflop which is triggered on the rising edge of PHI2. The resistor and capacitor determine the length of the generated (high) pulse and were chosen in a way that the new pulse ends a little bit (some 50ns) before the original PHI2 signal. Of course the '123 also introduces a delay, so the output of the '123 goes high some 30ns after PHI2 goes high. So the total pulse width is shorter than the original PHI2 pulse width. This is no problem for current RAM/ROM/flash/... chips, which usually have access times lower than 100ns.

 

Q: Are there other possible solutions?

A: Yes, several:

A1: If you have an internal upgrade (like a RAM extension) you can simpliy use PHI0 AND PHI2 for generating /WE signals. This is similar to the original "stabilizing" mod, but only affects the /WE signal.

A2: You may also use PHI0 instead of PHI2 for generating /WE, this works fine with the MyIDE interface (which has big problems if the length of the /WE pulse is shortened), but it may not work with other chips (the BSI RAMs, for example).

A3: If an extension only uses the address lines and if you use a CPLD you may simply latch the address lines during PHI2 = high. Note: this is not an option if you also use the data lines, as on write operations the data lines are valid AFTER the rising edge of PHI2, the address lines are already valid some time BEFORE the rising edge of PHI2.

 

BTW: The Turbo Freezer 2005 uses both the '123 (for fixing RAM and flash access) and input-latches for the address lines in the CPLD. Before I added this modifications I had several timing problems, mainly with XEs, after this mod everything was fine.

 

My 512k SRAM extension uses PHI0 AND PHI2 in the GAL to generate /WE, and I have an internal homebrew MyIDE interface where I just use PHI0 to generate /WE (IOWR) to the IDE drive. Using PHI0 and PHI2 didn't work, I assume the resulting signal was too short (but I didn't investigate this any further).

 

so long,

 

Hias

[nichtsnutz]

Hello all,

 

I thought ANTIC never generares wirtes.When does ANTIC do a write? As far as I know it is only doing reads or have I missed something?

 

Greetings,

Vassilis

[ctirad]

Q: Are there other possible solutions?

A: Yes, several:

A1: If you have an internal upgrade (like a RAM extension) you can simpliy use PHI0 AND PHI2 for generating /WE signals. This is similar to the original "stabilizing" mod, but only affects the /WE signal.

A2: You may also use PHI0 instead of PHI2 for generating /WE, this works fine with the MyIDE interface (which has big problems if the length of the /WE pulse is shortened), but it may not work with other chips (the BSI RAMs, for example).

A3: If an extension only uses the address lines and if you use a CPLD you may simply latch the address lines during PHI2 = high. Note: this is not an option if you also use the data lines, as on write operations the data lines are valid AFTER the rising edge of PHI2, the address lines are already valid some time BEFORE the rising edge of PHI2.

 

A4: Use an addtional clock source with a multiple frequency of PHI2 and sync it just to rising edge of the PHI2. I definitely will do in the RAM 320 XE case.

[HiassofT]

What difference does it make when PHI2 falls? Doesn't everyone hold the address and data valid until PHI2 drops? Even if /WE falls before PHI2, the data and address should still be valid. /CE signals are decoded from the address buss. As long as the address is valid /CE will be OK. Who drops off the buss before PHI2 falls? How is that timed? Only two chips generate /WE - CPU and ANTIC. Is that what you are moving - when /WE falls relative to PHI2?

OK, I guess I have to elaborate a little bit:

 

Problem occurrs when the CPU writes to some other devices (RAM/flash/ etc.) or when you have some "write-like" logic, like a bank-select register triggered by $D5xx. The crucial point is that all writing/registering etc. occurs on the trailing edge and at this point all address/data lines have to be valid. Depending on the device it may also be necessary that the signals are still valid for some time AFTER the trailing edge (the data/address hold time).

 

According to the Synertek 6502 datasheet the 2MHz 6502 keeps the address lines valid for (min.) 30ns after PHI2 goes low (t_ADH), when writing data lines should be valid for 60ns (t_HW). This is usually plenty of time.

 

Now we have to add the propagation delay of the 74LS08, which is typically 10ns (tPHL) and max. 20ns. This leaves only 10-20ns slack for all the address decoder logic.

 

It gets even worse with some of the crappy CPUs that were built into the later Ataris (especially XEs). If you look at the signals with a scope you see that they look more like sine-waves instead of square-waves and even the high-to-low transistions (the only strength of NMOS logic, low-to-high is usually quite bad) are skewed. Now add some additional capacitance and inductance from the Atari PCB, cables from expansions, input-capacitance of NMOS TTL chips etc. which skew the signal even more.

 

This reduces the slack, to the point where mainly the address- lines are already invalid at the trailing edge of the /WE (or clock) signal at the device.

 

Usually the CE/OE/WE logic looks something like this:

 

/CE = Ax & Ay & /Az ...

/OE = Ax & Ay & /Az ... & PHI2 & RW

/WE = Ax & Ay & /Az ... & PHI2 & /RW

 

One might think that PHI2 shouldn't really matter as /CE, /OE, /WE should go high if the address lines change before the trailing edge of PHI2. But there are two problems involved:

1) Even if your device requires no hold time, and if you could manage to implement the CE/OE/WE logic with 0ns propagation delay, the address lines already are invalid at the (infinitely small) time of the trailing edge of, for example, /WE.

2) Real-world devices always have some propagation delay, for example some 10ns for a standard GAL. So the trailing edge of WE would be some 10ns AFTER the address lines became invalid. Bang....

 

Long story short: you have to make sure the trailing edge of WE or CLK at your device arrives quite some time before any other input signal becomes invalid. The more slack the better, so you have some safety margin, for example at high temperatures when chips get slower.

 

so long,

 

Hias

[HiassofT]

Q: Are there other possible solutions?

A: Yes, several:

A1: If you have an internal upgrade (like a RAM extension) you can simpliy use PHI0 AND PHI2 for generating /WE signals. This is similar to the original "stabilizing" mod, but only affects the /WE signal.

A2: You may also use PHI0 instead of PHI2 for generating /WE, this works fine with the MyIDE interface (which has big problems if the length of the /WE pulse is shortened), but it may not work with other chips (the BSI RAMs, for example).

A3: If an extension only uses the address lines and if you use a CPLD you may simply latch the address lines during PHI2 = high. Note: this is not an option if you also use the data lines, as on write operations the data lines are valid AFTER the rising edge of PHI2, the address lines are already valid some time BEFORE the rising edge of PHI2.

 

A4: Use an addtional clock source with a multiple frequency of PHI2 and sync it just to rising edge of the PHI2. I definitely will do in the RAM 320 XE case.

Sure, this is also a possibility. You can also use any clock source that has a significantly higher frequency than PHI2 (for example 20 or 33 or 50MHz), it doesn't even need to be synchronized to PHI2.

 

You can do all needed synchronization inside the CPLD logic, for example detect the rising edge of PHI2 and then do registering etc. X clock cycles later.

 

I'm sure there are plenty of other nice solutions.

 

so long,

 

Hias

[Defender II]

Q: Are there other possible solutions?

A: Yes, several:

A1: If you have an internal upgrade (like a RAM extension) you can simpliy use PHI0 AND PHI2 for generating /WE signals. This is similar to the original "stabilizing" mod, but only affects the /WE signal.

A2: You may also use PHI0 instead of PHI2 for generating /WE, this works fine with the MyIDE interface (which has big problems if the length of the /WE pulse is shortened), but it may not work with other chips (the BSI RAMs, for example).

A3: If an extension only uses the address lines and if you use a CPLD you may simply latch the address lines during PHI2 = high. Note: this is not an option if you also use the data lines, as on write operations the data lines are valid AFTER the rising edge of PHI2, the address lines are already valid some time BEFORE the rising edge of PHI2.

 

A4: Use an addtional clock source with a multiple frequency of PHI2 and sync it just to rising edge of the PHI2. I definitely will do in the RAM 320 XE case.

 

Thanks HiassofT for all of the information on what should be done in external upgrades to deal with the weak PHI2 of the Mexican CPUs. Is there a modification that can be done on the BlackBox to fix this or is Bob Puff's/Mathey's fix the best way?

 

As it turns out, many of my 600XLs are Rev B and I bought the 320XL because I was wanted a plug and play memory upgrade without having to open them. ctirad, what can we do now to make the 600XL Rev B work with the 320XL and the MyIDE without causing other instabilities? Is there a modification that can be done to the 320XLs? Would replacing the CPU with a non-Mexican one fix the problem or does the 600XL Rev B have other issues?

 

You had mentioned...

That's AWESOME!!! Thank you very much Almost Rice for this find. Now it's clear that there is really something wrong with some ataris and it it is related to a particular CPU fitted rather than a revision of the motherboard.

 

I hope this will work for the other "bad" XLs.

In meantime I prepared an alternative firmware with slightly modified timing, but it looks it won't be necessary.

Would this firmware update fix it?

 

Will your next run of 320XLs have this fix as you plan for the 320XE?

Edited August 18, 2010 by Defender II

[+bob1200xl]

It looks like /WE falls during the handoff from ANTIC to CPU - about 50ns after PHI2 falls. The CPU picks up /WE about 10ns later, so the /WE transition is always PHI2+50ns or so. There is this big, active write pulse right in the middle of all the addresses setting up, but nobody should be looking at the buss during that time. The addresses are certainly going to be invalid. That's why PHI2 is the edge-trigger. Anything after PHI2 is invalid.

 

Are you saying that it needs to be?

 

Bob

 

 

 

What difference does it make when PHI2 falls? Doesn't everyone hold the address and data valid until PHI2 drops? Even if /WE falls before PHI2, the data and address should still be valid. /CE signals are decoded from the address buss. As long as the address is valid /CE will be OK. Who drops off the buss before PHI2 falls? How is that timed? Only two chips generate /WE - CPU and ANTIC. Is that what you are moving - when /WE falls relative to PHI2?

OK, I guess I have to elaborate a little bit:

 

Problem occurrs when the CPU writes to some other devices (RAM/flash/ etc.) or when you have some "write-like" logic, like a bank-select register triggered by $D5xx. The crucial point is that all writing/registering etc. occurs on the trailing edge and at this point all address/data lines have to be valid. Depending on the device it may also be necessary that the signals are still valid for some time AFTER the trailing edge (the data/address hold time).

 

According to the Synertek 6502 datasheet the 2MHz 6502 keeps the address lines valid for (min.) 30ns after PHI2 goes low (t_ADH), when writing data lines should be valid for 60ns (t_HW). This is usually plenty of time.

 

Now we have to add the propagation delay of the 74LS08, which is typically 10ns (tPHL) and max. 20ns. This leaves only 10-20ns slack for all the address decoder logic.

 

It gets even worse with some of the crappy CPUs that were built into the later Ataris (especially XEs). If you look at the signals with a scope you see that they look more like sine-waves instead of square-waves and even the high-to-low transistions (the only strength of NMOS logic, low-to-high is usually quite bad) are skewed. Now add some additional capacitance and inductance from the Atari PCB, cables from expansions, input-capacitance of NMOS TTL chips etc. which skew the signal even more.

 

This reduces the slack, to the point where mainly the address- lines are already invalid at the trailing edge of the /WE (or clock) signal at the device.

 

Usually the CE/OE/WE logic looks something like this:

 

/CE = Ax & Ay & /Az ...

/OE = Ax & Ay & /Az ... & PHI2 & RW

/WE = Ax & Ay & /Az ... & PHI2 & /RW

 

One might think that PHI2 shouldn't really matter as /CE, /OE, /WE should go high if the address lines change before the trailing edge of PHI2. But there are two problems involved:

1) Even if your device requires no hold time, and if you could manage to implement the CE/OE/WE logic with 0ns propagation delay, the address lines already are invalid at the (infinitely small) time of the trailing edge of, for example, /WE.

2) Real-world devices always have some propagation delay, for example some 10ns for a standard GAL. So the trailing edge of WE would be some 10ns AFTER the address lines became invalid. Bang....

 

Long story short: you have to make sure the trailing edge of WE or CLK at your device arrives quite some time before any other input signal becomes invalid. The more slack the better, so you have some safety margin, for example at high temperatures when chips get slower.

 

so long,

 

Hias