17 replies to this topic

[Marius1976]

I have something REALLY weird going on in one of my Atari 800XL computers.

I'm beta testing some things for Mr. Atari, and since I am testing pre-releases of a new MyIDE ROM I really wanted to quit erasing my Eproms all the time, so I took one of my 29EE010 eproms, and flashed the OS in it. I made a little adapter to fit this 32 pin IC right in the OS socket, and yes that works great.

But as soon as I connect my blackbox I get real strange disturbance on my screen.

Using the same Atari with a normal OS ROM, or EPROM does not have this effect.

So I thought: hmm probably another Atari suffering from unstable PH2 signals, so I did some fixing on that. But... the problem is still there.

And now the weirdest:

The atari works 100% fine. No issues at all, no locks up, no corrupt data, everthing works great. Except for the disturbance on the screen.

The EEPROM reads the OS ROM also 100% fine after verify. I also tried default XL OS, and Qmeg. All the same: disturbance on the screen, but it works.

I have also 29EE512... this one does not have this problem. Is there a possibility this has something to do with the accestime of the EEPROM?

These are specs:

SST 29EE512 90-4C-PH -> no disturbance, works great

SST 29EE010 150-4C-PH -> disturbance on screen, but works great

The problem only happens when blackbox is connected.

I also tried different PSU's.

I did the two bob puff stabilizing mod's.

Only thing left to try is a 74HCT123 PH2 fix, but I'm out of 33pF capacitors right now, which I need for that.

If anyone has another solution or idea? Please let me know.

I'm really confused by the fact that my computer has all kind of disturbance on the screen (which is NOT a feature!) and still works fine.

Thanks
M.

[Rybags]

I get the same since installing the 32in1 AtariMax OS on my VBXE machine.

It's intermittent, sometimes it'll go away for minutes, but it's there more than it's not.

Also, no crash issues, and I've verified that it also gives invalid data at times to the CPU as well from around the $E000 (character set) area.

[flashjazzcat]

This sounds very similar to the trouble I was experiencing with that 600XL after I socketed Antic. I never got to the bottom of the cause of the screen disturbance, although a new socket fixed the problem. I can only assume, then, that there was incomplete contact somewhere.

[Larry]

Very interesting. Could you post a picture of the screen/disturbance?

Do you just put the Eeproms into your programmer and reprogram them as part of the reprogramming cycle? (I've never used an Eeprom.)

I've seen color shifting caused by the Black Box before when the contacts are dirty. And last, gently "wiggle" both the power supply plug and then the monitor plugs -- any shifting or disturbance? If so, then likely your power or video jack is worn. Probably not your issue, but worth the simple checking.

-Larry

[Marius1976]

I'll make a picture soon, but it is not that kind of disturbance.

It is probably what rybags describes. "Invalid" data in the characterset ... when a motorcycle drives by or a lawnmower on gasoline is busy next to my screen... that type of disturbance. Very small and very bright little lines. Like stars... it looks rather cool ...

Without blackbox the issue is gone. I'm pretty sure it has something to do with timing / too much bus load.

When I have my 33pF capacitors I'll make a better PH2 circuit, and I'm very curious... will it be gone or not.

I'll make a picture as soon as I get my cameras accu full of energy

Greetz
M.

[Marius1976]

Ok here it is...

This is the Menu this Atari boots with...

All the white small lines are the disturbance.

Rather strange eh?

Greetz
M.

[Marius1976]

Interesting indeed:

Rybags is right. It is disturbance in the Characterset! In the "Graphics 2" top screen the disturbance is showed by bigger lines. It is in the "space" character where the data goes wrong.

It's WEIRD!

Greetz
M.

[Larry]

Hopefully, Bob1200XL will take a look at this thread. This looks similar to something that he was telling me about a couple of years ago. He described this as "birdies" IIRC, and as I remember it was a timing issue of some kind.

-Larry

Marius1976, on Fri Apr 1, 2011 6:21 AM, said:

Interesting indeed:

Rybags is right. It is disturbance in the Characterset! In the "Graphics 2" top screen the disturbance is showed by bigger lines. It is in the "space" character where the data goes wrong.

It's WEIRD!

Greetz
M.

[a8isa1]

Hi,

Did you happen to leave any address lines on the 29EE010 floating?

This would have unpredictable results.

I had some pretty strange and hilarious results when I unknowingly made this mistake with NV SRAM experiments.

[MEtalGuy66]

Do the "bob puff XL/XE stability mod" part 2...

[Marius1976]

a8isa1, on Fri Apr 1, 2011 7:03 AM, said:

Hi,

Did you happen to leave any address lines on the 29EE010 floating?

This would have unpredictable results.

I had some pretty strange and hilarious results when I unknowingly made this mistake with NV SRAM experiments.

After your message I have been re-checking this, but A0 .. A13 are connected like a 27C128 eprom would be. A14, A15 and A16 are connected to +5.

I use the highest 16KB (1C000 - 1FFFF) of this 1Mbit eprom.

Pin 1 is NC ... in the PINOUT Docs I also read pin 1 is not used. I suppose this is right.

/WE (/PGM) is also connected to +5V

An 29EE512 has 100% same pinout (except for pin 2 (A16)
With the 29EE512 it works great.

Without blackbox it works also great.

I think I have to wait for my HCT123 PH2 fix.

Keep you informed.
M.

[Marius1976]

MEtalGuy66, on Fri Apr 1, 2011 7:25 AM, said:

Do the "bob puff XL/XE stability mod" part 2...

In the opening post I wrote I already did mod #1 and #2 ...

here:

Quote

I did the two bob puff stabilizing mod's.

Unfortunately it did not help.

Is there any chance this can be caused of speed? I guess not... since eproms appear to be a lot 'slower' than this eeprom.

Thanks!
m.

Edited by Marius1976, Fri Apr 1, 2011 7:40 AM.

[Beetle]

I exprienced the very same effects after programming 4x OS to
some 27c512 nonwindowed (therefore unerasable) PROMs. These are
also known as OTP-Eproms.

I was guessing timing problems, too. The two computers it affected had
either a BlackBox (my 1250XLD) or a TurboFreezer (my 800XL) inside.
The OTP-EPROMs were also faster than my old usual EPROMs.

In my nonexpanded 600XL, it worke flawlessly, iirc.


Greets,
Beetle

Edited by Beetle, Fri Apr 1, 2011 8:05 AM.

[MEtalGuy66]

Have you tried it WITHOUT the Bob Puff stability mods?

The timing problem is relative..

Have you tried swapping the CPU?

The HCT123 "fix" can not be applied to the entire machine (does not make any sense to do so, and does NOT work). It has to be applied directly to the device experiencing the problem (writes are invalid because of the PHI2 skew relative to the bus timing).. And it only fixes that particular problem on that device. Which is why it shouldnt be called a "PHI2 fix" at all.. It should be called "Write timing compensation for PHI2 variation".

This is not the problem you are experiencing. The problem you are experiencing is exactly indicative of a system-wide PHI2 related issue due to increased bus capicatance/delay pushing the PHI2-bus timing "over the edge" of what works reliably. In fact, that screenshot shows classic symptoms, and the fact that it works fine without the blackbox plugged in further reinforces this.

Try a different EPROM, or try swapping the CPU... And try these with and without the "Bob Puff" Mods..

Edited by MEtalGuy66, Fri Apr 1, 2011 9:39 AM.

[bob1200xl]

Yep - birdies... ANTIC is latching data of $FF at the end of the cycle. Nothing in the Atari is clocked, really. The OS ROM is selected directly by whatever address is on the buss, which leaves you subject to all sorts of slow or ringing address bits. By using a different 'ROM' (EEPROM), the access time, active current drain, output enable, or whatever, is not compatible with the particular characteristics of your ANTIC or CPU, or both.

The Congo Bongo cart has some kind of ROM in it that does the same thing on a 1200XL - you get $FF on a read to certain addresses. You can fix that by de-gating cartridge select in the beginning of the cycle, where the addresses are still jumping around. The CB ROM goes nuts if you send it noisy selects.

Bottom line is that there are a lot of glitches running around in your Atari. (not that an AppleII or Commodore is so much cleaner...) The solution, if you want to be able to just hang anything anywhere, is to gate everything with a master clock and/or use a 4-layer motherboard. Otherwise, you will just be making specific fixes for specific problems.

The 1450XL motherboard is a 1200XL with a whole bunch of hardware added to it. It's a 4-layer board ($) for a reason...

Bob

Larry, on Fri Apr 1, 2011 6:39 AM, said:

Hopefully, Bob1200XL will take a look at this thread. This looks similar to something that he was telling me about a couple of years ago. He described this as "birdies" IIRC, and as I remember it was a timing issue of some kind.

-Larry

Marius1976, on Fri Apr 1, 2011 6:21 AM, said:

Interesting indeed:

Rybags is right. It is disturbance in the Characterset! In the "Graphics 2" top screen the disturbance is showed by bigger lines. It is in the "space" character where the data goes wrong.

It's WEIRD!

Greetz
M.

[flashjazzcat]

bob1200xl, on Fri Apr 1, 2011 9:41 AM, said:

Yep - birdies... ANTIC is latching data of $FF at the end of the cycle.

So it's the same effect you noted on my 600XL, Bob?

[Marius1976]

Thanks for all contributions. I tried anything possible here... and the problem is still there.

So I stick with the 29EE512. In fact it is not really important. I just wanted to know what was going on.

Since I only use these EEProms for beta testing, so I don't have to erase eproms all the time, it will never be a permanent solution for me.

Thanks!

Marius

p.s.
@metalguy

On the site of Bernd (Abbuc) http://www.abbuc.de/~bernd I read something about the PH2 fix for the entire machine. When I read correct, Bernd found a weak or noisy PH2 signal in some Atari's, so he decided to create a PH2 renewal circuit, which results in a 'stronger' (?) / 'better' PH2 signal. Isn't his theory false? Or is he right, but will it not help me?

[MEtalGuy66]

Marius1976, on Fri Apr 1, 2011 2:31 PM, said:

Thanks for all contributions. I tried anything possible here... and the problem is still there.

So I stick with the 29EE512. In fact it is not really important. I just wanted to know what was going on.

Since I only use these EEProms for beta testing, so I don't have to erase eproms all the time, it will never be a permanent solution for me.

Thanks!

Marius

p.s.
@metalguy

On the site of Bernd (Abbuc) http://www.abbuc.de/~bernd I read something about the PH2 fix for the entire machine. When I read correct, Bernd found a weak or noisy PH2 signal in some Atari's, so he decided to create a PH2 renewal circuit, which results in a 'stronger' (?) / 'better' PH2 signal. Isn't his theory false? Or is he right, but will it not help me?

Yeah.. Thats right.. The 74HCT123 doesnt regenerate the PHI2 circuit. It creates ANOTHER signal to be used for write timing on a particular device that is on the end of a bus which suffers from excessively skewed phi2-to-bus timing..

What Berndt did was generate his own PHI2 from PHI0, independant of the CPU.. This does work to correct the problem where the CPU is concerned. .. I have done it.. You dont use a 74HC123 for that.. But to fix this part of the problem, it's alot easier to just replace the CPU with one that has a decent PHI2 circuit..

You have to understand that the PHI2 problems on the atari are the result of 2 things.. 1) not all CPUs are "created equal" where PHI2 generation is concermed.. 2)The more crap you hang off the data bus, the more capacitance you add to the bus, and thus the more delay. The CPU is actually clocked from the PHI0 clock, so if PHI2 is generated with the timing slightly off (or the timing of the bus in relation to PHI2 is delayed significantly), it effects the timing with which every device in the atari reads/writes bus states in relation to the CPU.

The problem you are experiencing is kind of a "part 3".. The device you are using has slower output buffers, which are driving the bus slightly longer than the EPROM (or ROM) would.. This is overlapping into the time when somethign else (such as antic) is trying to read/write to the bus.

So the problem is a CUMULATIVE effect of all 3.. This is why when you plug in the black box, it adds to the problem (part 2 of the problem).. and why if you swap the CPU, apply an alternate PHI2 generation circuit, or "and" PHI0 with PHI2 (bob puff stability mod #1) it can make it(part 1 of the problem) better or worse.

And by the same token, using an EPROM/ROM with faster output buffers brings the timing back into spec just enough to start working reliably again (problem part 3 in your case)..

This is why it's kind of IMPOSSIBLE to have a really heavily expanded atari that will work with ALL comfigurations of anything you could plug into the PBI and CART slot.. Often the best you can do is fine-tune the PHI2 timing to hit the "happy medium" for the devices which you want to use in that configuration, and LEAVE that configuration hooked up.

Not to sound blunt or offensive, but if you don;t understand all this, you really shouldnt be jacking around with your hardware at all.

Last thing I'll say is that while the 74HCT123 "fix" does work for generating reliable writes on the device in which it's implemented, it does nothing to correct the system-wide effects of added bus capacitance, or crappy CPU PHI2 generation.. If the only problem you are experiencing is unreliability on write operations on THAT DEVICE, then the 74HC123 is a well designed solution. If you were to try to employ the 74HC123 solution in this particular situation, you would want the output of the circuit going into the OE (output enable) on the EEPROM, and CE (or CS) still driven by the normal signal from the MMU. You may also have to invert the output of the 74HCT123 circuit before it goes to OE. You will also almost certainly have to adjust the values of the resistor and cap in hias's circuit, in order to get the timing correct for this application. If you dont have a logic analyzer, I would not even attempt this.. Yo are shooting in the dark with way to many variables..

Edited by MEtalGuy66, Sat Apr 2, 2011 7:34 PM.