mos6507's Blog

I will try and clarify the situation a bit. First off I am using an RF 6 switch that is on its last leg. I get rolling noise and the colors wash out cyclically, lots of issues, even with normal carts. So one of the problems is I cant really be the best judge of noise.

 

The second issue is that the Chimera cart feeds noise back to the VCS, mostly on the data lines, no surprise there. There is some resonance caused by the carts operation and the VCS's RF unit is most susceptible. Normally I would just throw a large resistance in the data lines to squelch the noise, 10K or so. As long as the electrical characteristics are maintained it works great. This becomes a double issue when using magic writes.

 

First, a brief explaination of how magic writes work. When the VCS places an address on the address bus that is in the normal cart range, the cart fetches the required data and drives the data bus with it for the entire time the VCS maintains the current address. Thats how it works normally. When magic writes are active, the cart fetches the needed data and only drives the bus with it for half a VCS cycle, then it releases the data bus. The VCS also has the data bus released at this point. The CPLD has a feature called the bus hold. This feature is describe here on page 12:

 

http://direct.xilinx.com/bvdocs/publications/ds054.pdf

 

Basicly the bus hold circuit maintains the last value placed on the bus. So we are halfway through that last cycle and the cart has released the data bus, but the CPLD is maintaining that data on the bus. If the VCS writes, it will drive the data bus with its own data. At the end of the VCS cycle the cart then writes this new data from the VCS to the SRAM. Now if the VCS reads, the write still happens, but the data is the same value it read a half cycle earlier, effectively writing the same value over. This works great.

 

The problem is that with magic writes, its now double the amount of accesses to the SRAM, a read and a write every VCS cycle, so that means a large increase in noise. The bus hold uses a very large resistance to keep its weak hold on the bus, 50K. If I Add much more resistance on top of that to squelch the newly created noise, I start to violate the electrical characteristics of the 6507.

 

I can go up to about 3.3K and that seems to do a whole lot for me. Glenn doesnt get any noise because he is using an A/V mod, no RF issues with him. I get the noise, but its hard to tell what portion is from the cart and what is from my crappy system.

 

I hope that is a suitable explanation of whats going on, but I am not sure what information Glenn is specifically asking the community about though. Comment away

 

Vern

 

P.S. - Thank John (Supercat) for the magic write idea, its all his.

The problem is that with magic writes, its now double the amount of accesses to the SRAM, a read and a write every VCS cycle, so that means a large increase in noise. The bus hold uses a very large resistance to keep its weak hold on the bus, 50K. If I Add much more resistance on top of that to squelch the newly created noise, I start to violate the electrical characteristics of the 6507.

 

Does the CPLD output any data of its own, or is its only "output" function the bus hold?

 

If the CPLD doesn't output any data of its own, I would suggest that you have the CPLD data pins tied directly to the 2600 side, and have resistors between the CPLD and the memory chips that will be putting data on the bus. The memory chips should output very strong highs/lows, so the balance will be purely between the CPLD hold circuit and the resistors. Since the VCS will be tied directly to the CPLD, its attempt to "pull" the bus won't have to battle the resistors. If there were a way to enable the bus hold function only part of the time, you could disable it during the portion of each cycle when you're just starting to read data from memory; in that case you could get by with fairly large resistors. The 9500XL series doesn't offer such a function, though.

 

If you really wanted to make things nice from a noise perspective, you would have two sets of data pins on the CPLD--one connected to the VCS and one connected to the memory, with 10K-47K resistors connecting them. If you did that, you wouldn't need the CPLD's bus-hold function; instead, for the part of the cycle where you would use it you would program the CPLD's outputs (on the memory side) to follow its inputs (on the VCS side). Alternatively, you could build a bus-hold circuit from a 74HC373. As before it would only output during the appropriate part of the cycle.

Does the CPLD output any data of its own, or is its only "output" function the bus hold?

Yes, the CPLD data lines feed right to the VCS.

 

If you really wanted to make things nice from a noise perspective, you would have two sets of data pins on the CPLD--one connected to the VCS and one connected to the memory, with 10K-47K resistors connecting them.

This is exactly how the previous version worked. But we moved from an 8 bit bus to a 17 bit bus between the MCU and the CPLD to speed up throughput. That used up those extra pins. I called that 'active bus hold'. I am calling this current way 'passive bus hold'. I could add an external octal register outside the CPLD, that would solve all the issues. But I am trying to avoid that. I will wait until I hear back from beta testers with RF systems to see if anything more needs to be done.

 

If the cuttle cart has some noise and people have been fine with it, this shouldnt be a problem at all.

 

Vern

Does the CPLD output any data of its own, or is its only "output" function the bus hold?

Yes, the CPLD data lines feed right to the VCS.

 

Is it only when you're using queues or other such goodies that that happens? Or does the CPLD insert itself between the memory data bus and the 2600? In 4A50, the CPLD itself never puts anything on the data bus--anything that gets there is put there via the RAM or flash (or by the 2600 itself). If your CPLD has a full set of address and control lines, you could probably avoid having it output anything on the data bus itself if it simply read from a memory chip containing a 256-byte table of values 0-255.

 

If you really wanted to make things nice from a noise perspective, you would have two sets of data pins on the CPLD--one connected to the VCS and one connected to the memory, with 10K-47K resistors connecting them.

This is exactly how the previous version worked. But we moved from an 8 bit bus to a 17 bit bus between the MCU and the CPLD to speed up throughput. That used up those extra pins. I called that 'active bus hold'. I am calling this current way 'passive bus hold'. I could add an external octal register outside the CPLD, that would solve all the issues. But I am trying to avoid that. I will wait until I hear back from beta testers with RF systems to see if anything more needs to be done.

 

If the cuttle cart has some noise and people have been fine with it, this shouldnt be a problem at all.

 

Sometime I'll have to find out how 4A50 is in that regard. My only RF-related measure was a resistor between the 14.31818MHz oscillator module and the CPLD.

 

BTW, are you running a nice multiple of 3.579545MHz? I think you'll need to be accurate within 1% for reliable operation if a STA WSYNC is run from cartridge RAM.

BTW, I forgot to mention: magic writes shouldn't have any particular effect on data-line RF emissions except when data is written to the RAM since data will be put on the lines during one part of the cycle and remain there during the other part; to someone watching the data lines with a scope, each cycle would "look" like one cycle. To be sure, if data in the RAM is written with a different value, the old value will appear on the bus during half the cycle and the new value for the other half, but most code does a lot more reads than writes.

BTW, I forgot to mention: magic writes shouldn't have any particular effect on data-line RF emissions except when data is written to the RAM since data will be put on the lines during one part of the cycle and remain there during the other part; to someone watching the data lines with a scope, each cycle would "look" like one cycle. To be sure, if data in the RAM is written with a different value, the old value will appear on the bus during half the cycle and the new value for the other half, but most code does a lot more reads than writes.

Logically there is no difference, but when I run defender with magic writes on, I see a huge increase in noise.

 

Vern

Logically there is no difference, but when I run defender with magic writes on, I see a huge increase in noise.

 

Curious. If you have magic writes off, but the bus-keeper enabled, what happens? Perhaps the bus keeper is adding noise by increasing the current flow and sharpening the transitions on the data bus (for all cycles, including TIA and RIOT ones), but I wouldn't think the effects would be too bad.

 

BTW, just to clarify, are you saying that you're using Defender II/Stargate with magic writes at $1000-$107F? Is the noise concentrated on any particular part of the display? What parts of the system are running at five volts vs. 3.3?

Curious. If you have magic writes off, but the bus-keeper enabled, what happens? Perhaps the bus keeper is adding noise by increasing the current flow and sharpening the transitions on the data bus (for all cycles, including TIA and RIOT ones), but I wouldn't think the effects would be too bad.

I am not sure since I have never tried running without the keepers active, its the default setting. Adding the extra SRAM access every cycle for the magic writes definitely adds noise though. I have tried running in standard macrocell power and low macrocell power, no noise difference. I also tried using the fast and slow slew rates, but I visually get the same noise also.

 

BTW, just to clarify, are you saying that you're using Defender II/Stargate with magic writes at $1000-$107F? Is the noise concentrated on any particular part of the display? What parts of the system are running at five volts vs. 3.3?

Just normal defender, with writes active across the entire address range. The noise is heaviest in a vertical column around the ship, but still heavy all over the screen.

 

Vern

Just normal defender, with writes active across the entire address range. The noise is heaviest in a vertical column around the ship, but still heavy all over the screen.

 

So you're running all of the code from RAM in either case, but in one case you're holding /OE for the whole cycle and in the other case you're holding /OE for only part of the cycle and then /WE for the other part, while the address does not change? Do you have good bypass caps everywhere?

 

What parts of the cart are at five volts and what parts are at 3.3?

So you're running all of the code from RAM in either case, but in one case you're holding /OE for the whole cycle and in the other case you're holding /OE for only part of the cycle and then /WE for the other part, while the address does not change? Do you have good bypass caps everywhere?

Correct about WE and OE. Bypass caps are everywhere. I was getting noise on some of my first carts ever and all they did was go through a small CPLD and straight to a flash chip. It didnt get much more simple, but still got the noise.

 

What parts of the cart are at five volts and what parts are at 3.3?

The only 5V trace is the one coming in from the VCS, it goes into a big electrolytic cap and then into a 3.3V regulator.

 

Vern

Have you considered trying RF shielding? Not necessarily ugly sheet metal, more like conductive paint on the inside of the cart shell, such as this product.

 

I've never worried about RF interference in any of my projects, so I don't know if it would work or not.

The only 5V trace is the one coming in from the VCS, it goes into a big electrolytic cap and then into a 3.3V regulator.

 

FWIW, the 4A50 design is mostly at +5 except for the CPLD which is 3.3.

 

If your RAM is running off 3.3 volts, switching from read to write mode shouldn't put any noise (or cause any change whatsoever) on the data lines, but may cause a momentary increase in current draw. Perhaps that's what you're seeing? I might suggest trying an inductor between the VCS supply and the cap feeding the regulator. A cap alone can only do so much; adding an inducator can help a lot, especially in cases where you can afford some instantaneous voltage drop.