Not quite... The end of the ROM based PLA for the 64

Other Computers and Game Systems

Moderator: Moderators

Post Reply
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Not quite... The end of the ROM based PLA for the 64

Post by eslapion »

A few years ago, people started to use EPROMs to substitute the PLA chip in the 64 that often fails. This technique can also be used to replace faulty PLA chips in older PET computers.

The solution I have used is posted online here:
http://www.vic20.de/html/eprom_pla_8296_und_c64.html

However, there is a problem. The vast majority of modern EPROM chips made after 2000 are much faster than those used in the early 80s but in fact this is what allows the use of a memory chip as a substitute for a logic chip.

The problem is, these faster chips, when used with the relatively sluggish signals of a C64 or PET have a tendency to have an unstable output (as a result of input incertitude for a few hundreds of ns) and this can cause problems or even, in the long run, damage the machine in which it is used.

There is, however ONE specific brand of EPROM I have used over the last few years as a PLA substitute that does NOT cause this problem. This specific chip, the M27C512-90B6 made by ST is now OUT OF PRODUCTION.

This chip worked well because it does not exhibit the output instability of virtually all other brands of other 27CXXX series of (E)PROMs. With a rating of 90ns, this chip is not only considered slow by modern technology standards, it is also very close to the original rating of 82S100 chips of 80ns. It also has a rather high output impedance which reduces the risk of damage to other chips.

I have about 50 of them left in stock and then its over.

I normally sell my substitute PLAs for 10$ each but I can also sell the chips preprogrammed as is (you have to make the adapter) if anyone wants them, for 3$ each. I also offer a quantity discount of 8.50$ for complete subs and 2.60$ for chips with no adapters on quantities of 10 or more.

Over the years I sold about 200 of these PLA substitutes, used in both the C64 and PET computers and only had ONE european customer indicate to me that he had a compatibility problem in ONE specific machine.

For those in need of a replacement PLA, I suggest you get them before its too late.

PLEASE NOTE:
There is a european hacker who claims the solution I offer causes bus contentions on the 64.

In the coming days, I will post screen captures from a professionnal digital oscilloscope which not only prove my solution causes no such problems but that even original Commodore PLAs do cause bus contentions for brief periods of time.
Last edited by eslapion on Sat Oct 03, 2015 2:57 am, edited 2 times in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

A bit of history
What is the PLA and why does the Commodore 64 need one?

The programmable logic array is a 28 pin configurable logic chip with 16 inputs and an output enable control with 8 outputs.

This kind of legacy chip’s purpose was to replace a number of combinatorial logic circuit such as those of the 74LS family with a single compact integrated device that could be tailor programmed to specific needs.

In the case of the Commodore 64, we’re dealing with a microcomputer that was quite sophisticated for its time. Even though the 64 used a processor capable of addressing 64 kilobytes of address range, in all, the ROM, RAM, IO devices and audio/video registers represented more than 84 kilobytes of address range. Even more could be added externally and various memory maps and organizations were possible and controlled through various IO lines directly connected to the 6510 processor and some more were available on the cartridge port.

Glue logic in the 64, if composed exclusively of standard small format logic chips would have become expensive, oversized and a burden to troubleshoot in case of malfunctions. Commodore therefore decided to integrate dozens of logic chips into a single IC using the 82S100 PLA they had already experience with in their PET series of computers.

Eventually, the C64 became a very popular machine and Commodore decided that it would be less expensive to make their own in-house non-programmable equivalent using the same NMOS technology used for the production of other 65XX series of chips. Only a small minority of early models of the 64 use the original 82S100. The vast majority of 64s produced use the NMOS technology based MOS 906114-01.

What is the problem with the PLA? Why does it fail so often?

The PLA drives the !CS lines of many chips inside the C64 directly as well as the !CAS lines of all eight DRAM chips and changes their values about 2 million times every second. As such, the PLA requires a good amount of power to continually change the electrical value of these lines and so, it produces a good amount of heat for its small size.

This problem is compounded by the type of technology used inside the PLA, NMOS technology, which uses transistors to drive a signal from 5V to 0V but uses a resistor to drive a signal from 0Vto 5V. This means every time the PLA is sending a 0V signal, it does so by shorting a resistor between the ground line and the 5V line, effectively turning it into a small heating element. This also means a signal transition from 0 to 5V will take much more time than a transition from 5V to 0.

Since Commodore is no longer around to manufacture replacement PLAs that fail quite often, solutions had to be found.

What are the solutions? How do they differ from one another?

It would seem obvious that one could replace a programmable logic chip with another but there is a problem with that. Commodore originally built the DRAM management hardware of the C64 around the programmable 82S100 which was a relatively slow chip. Commodore engineers effectively built around the delay of this chip.

There are two types of delays involved in the response speed and behavior of a chip. The first one is the latency or propagation delay. Propagation delay is the amount of time it takes for a chip to notice there has been a change on its inputs and to begin reflecting this change on its outputs. The second parameter is the rise and fall time or transition time. The rise time is the amount of time a chip will take, once it has clearly defined what the new output will be, to change its output from a logical 0 to a logical 1. The fall time is the amount of time it takes for the same chip to change its output from a logical 1 to a logical 0.

Transition times not only depend on the characteristics of the chip driving the signal but also on the input impedance of the chips that will receive the changing signal. That’s because the characteristics of their inputs will determine the amount of current required to change the value of the signal and to keep this signal the way it is. In other words, it depends on both the amount of current the outputting chip can deliver and the amount of current the receiver(s) may need and how many there are.

If a signal is driven by a fast, strong driving chip with only one receiving chip that has high input impedance, the changes will occur fast. If a signal is driven by a slow, lazy driving chip with multiple chips receiving the signal and all of them having a rather low input impedance then changes in the signal will occur slowly and there might even be a slight offset in the voltage of the signal even when there is no change.

Modern programmable logic devices are dozens of times faster than the antiquated 82S100 and so they cause problems with the CASRAM line used in the multiplexing of the addresses and the refreshing of the 64’s DRAM.

The C64 uses a method called RAS ONLY REFRESH to maintain the content of the DRAM chips and I originally believed a faster CASRAM signal interfered with that but other technically knowledgeable people have indicated the problem was with the multiplexer integrated in the VIC-II chip.

Therefore, engineers and technically knowledgeable people who designed modern programmable logic chip solutions to replace the PLA have built-in an intentional delay on the CASRAM output of their substitutes. Usually this is done by adding an even number of inverters to the signal. However, since the delay depends on the exact type of technology used, it is very difficult to accurately predict the exact amount of delay that will result by the addition of these inverters.

Another solution was to use a modern, faster ROM chip with the truth table from the original PLA programmed in it. However, unlike a logic chip, a memory chip is normally allotted a certain amount of time between the inputting of a certain memory address, which in this case corresponds to the input on the 64’s PLA, and the outputting of the value stored at the corresponding address. Technically speaking, a ROM chip could, in theory, have all sorts of strange and even unstable values at the output before this time has passed.

In the digital world, nothing is perfect and a certain amount of tolerance is required for all digital chips to understand each other. Noise is the name of the game and a system which demands 0 volts to recognize a logical zero and 5 volts to recognize a logical one would crash all the time when noise affects electronic equipment. The Commodore 64 uses a mixture of TTL and CMOS logic circuits with different characteristics and so everyone has to talk the same language to work well with each other.

Since it is easy to make CMOS chips that understand TTL signals but very difficult to make TTL circuits that can output true CMOS level signals, designers of the Commodore 64 and of just about every 8 bit computers of that era have elected to define TTL logic levels as the norm. In this environment, anything below 0.8 volts is considered a zero and anything above 2 volts is a considered to represent a one.

TTL chips are expected, in worst cases, to signal a zero below 0.5 volts and signal a one above 2.7 volts. CMOS chips will output 0.33 volts to indicate a logical zero and more than 3.5 volts to indicate a logical one and so everyone can understand each other.
Last edited by eslapion on Sat Dec 10, 2011 1:17 pm, edited 1 time in total.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

What is bus contention? How can it happen?

Since the PLA is used to tell various devices which one has access to the C64’s bus, it could, in theory, tell more than one device to talk on the bus and they might, in turn, apply conflicting values on this bus for a brief period of time. This is called “bus contention".
A block diagram of the bus signals in the C64
A block diagram of the bus signals in the C64
As you can see, all devices except for the color RAM are directly connected to the data bus

Because a ROM chip is expected to have unstable outputs for a brief period of time when there is a change on the inputs, it is considered likely to cause bus contentions if used as a substitute for the 64’s PLA.

However, while a ROM chip used as a PLA could, in theory inadvertently tell many chips to talk simultaneously on the 64’s bus, given the right circumstances and especially because its rise time is longer than its fall time, so could the original Commodore made MOS 906114-01 when two different chips are accessed immediately one after the other. That’s because memory chips “talk” on the bus when their !CS line is close to 0 so the !CS line of a chip may not be quite high enough, even when slowly going back to a logical 1 when the !CS line of another chip is quickly sent down to 0 by the PLA.

Under normal operating circumstances, when the 64 has just been turned on and no program is running, the two most often accessed ROM memory chips in the 64 are the character ROM which needs to be scanned hundreds of thousands of times every second by the VIC-II and the Kernal ROM which is used by the 6510.

Since the Kernal ROM is only used by the 6510 and the character ROM is almost strictly used by the VIC-II, these two chips are accessed on each their own half cycles of the 64’s 1MHz processor clock in an immediate consecutive way thousands of times every second. When that happens, the transition from one chip to the other accessing the 64’s bus is extremely fast. As such, they are perfect candidates to detect the possible occurrence of bus contentions.

If the !CS line of both of these chips are low simultaneously even for a few nanoseconds then there is a possibility of bus contention.

The purpose of this document is to:
1. Show that actual Commodore made MOS 906114-01 and programmed 82S100 chips from early revisions of the 64 do cause bus contentions to begin with.
2. To show that there are ROM based PLA substitutes which do not suffer this problem
3. To demonstrate that modern CMOS based solutions actually contribute to prolong the lifespan of legacy Commodore hardware by eliminating problems with the original 64’s PLA such as asymmetric response speeds and thermal dissipation.
Last edited by eslapion on Sat May 25, 2019 1:21 pm, edited 3 times in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

The test bed
The architecture used in this research project will be a Commodore 64 with NTSC video standard and main board no. 250407. The original PLA installed in this machine was an MOS 906114-01 manufactured on the 39th week of 1983. The VIC-II which is responsible for DRAM refresh and management is a 6567R8 manufactured on the 37th week of 1983.

This microcomputer is powered by a modified legacy PC/AT power supply rated for 130 watts along with a 9Vac 1A wallwart transformer.

This specific machine has seen thousands of hours of operation at the hands of its previous owner, technician Jean-Claude Lachapelle who has used it as a personal computer for more than a decade and as a test bed to fix other 64s and related equipments. Almost all of its integrated circuits have been put on sockets to make them easier to remove and diagnose, including ordinary 74LS glue logic chips.

Image
The tested Commodore 64 with board 250407 and installed probes
Note the signature of the previous owner on the cartridge port’s cowling.

The measuring instruments used for this project consist of a Tektronix TDS 1002 digital storage oscilloscope and a Meterman 37XR digital True RMS multimeter. The TDS 1002 is powered through a 30 watts mains isolation transformer to prevent damage to tested equipment. Both of these instruments were originally purchased in 2003 and have received NIST traceable calibrations prior to purchasing. The serial number for the calibration of the TDS 1002 is C014125.

The TDS 1002 is used with a pair of 10x compensated probes rated for 100MHz.

Image
The Tektronix TDS 1002 digital storage oscilloscope

Image
The Meterman 37XR digital true RMS multimeter
Last edited by eslapion on Sat Dec 10, 2011 8:56 pm, edited 1 time in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

The testing methods and procedures
As we suspect the most often consecutively addressed ROM chips who’s outputs are controlled by the PLA are respectively the character generator ROM and the Kernal ROM, we shall monitor the control of their respective !CS lines using the TDS 1002.

If both of these lines are pulled low simultaneously at any given time then we can clearly conclude there is a contention on the Commodore 64’s data bus.

We shall first examine these signals individually to understand their behavior and later examine their relative behavior, compared to each other.

Image
Two random digital signals captured on the TDS 1002

On the TDS 1002, we shall perform a mathematical adding of these signal’s values to understand their time wise relative activity. If the sum of these two signals is between 6 and 10 volts then both signals represent a logic 1 and are considered as signaled high. If that sum is between 3 and 5 volts then one signal is a logic 1 (high) and the other is a logic 0 (low). We then know one of the two monitored ROM chips is signaling on the 64’s data bus.

Image
The summing of the above signals by the TDS 1002

However, if the sum of these two signals is lower than 3v, it is then possible that both signals could be considered low and therein resides the possibility of a bus contention.

Another possible method for detecting a contention involves using a simple logical NOR logic gate circuit. However, we shall need a circuit that is considerably faster than legacy logic ICs of the same type used in the 64 to cover the possibility of a bus contention resulting from a faster ROM memory circuit having being installed as a kernal replacement.

Texas Instruments specifies a 74LS02 with typical load will have a total propagation delay and transition time of 10ns typically and 15ns at most. These circuits have a speed of operation similar to the fastest circuits found in Commodore 8 bit computers.

Fairchild specifies a 74F02 should, on the other hand have a total propagation delay and rise time of 4.4ns typically and 5.5ns at most. This circuit is even faster on a falling transition with a total propagation delay and fall time of 3.2ns typically and 4.3ns at most. If there is a bus contention, then a 74F02 will definitely be able to signal it.

Image
Truth table and equivalent circuit of the 2-input NOR gate
Last edited by eslapion on Mon Dec 12, 2011 1:13 am, edited 1 time in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

Once upon a time, there was the MOS 906114-01
The MOS 906114-01 is Commodore’s own copy of a programmed 82S100 with the logic equations perfectly equivalent to those programmed in early PLAs used in the first generation of Commodore 64s to hit store shelves.

This revision of the PLA is examined first not because it’s the first version of the 64’s PLA, in fact it is not, but rather because it is the one most widely available and since it is a form of improvement over the original PLA, it works well with just about every revision of the Commodore 64 ever made, except, of course, the 64c which uses a completely different chip.

The MOS 906114-01, works well with both PAL and NTSC machines. These machines are both compatible with the same type of PLA and use identical logic equations.

This clone is so close to the original thing that even though the PLA’s output control line is permanently tied to the ground in the 64, thereby making the output continuous, the output control line of the MOS 906114-01 does work and it would disable the output if tied to 5V or any valid TTL level logic 1 signal. This control line is pin 19 on the PLA.

However, close doesn’t mean perfectly identical to the point you couldn’t make the difference. For one thing, since the 82S100 is rated for 80ns, on most of its outputs, the MOS 906114-01 reveals, with its much faster response, that it uses a different kind of technology.

Image
The MOS 906114-01 dated 3983

Lets make our first oscilloscope capture on the !CS lines of the CG and kernal ROMs and make sure we do so during the time the VIC-II is busy scanning the character generator to display a video scanline of text. During such an interval, the VIC-II has to gather data from the CG exactly 40 times in a row.

Care has to be taken not to stumble on a scanline where the VIC-II also has to scan the RAM for the screen codes map located at $0400. This map tells the VIC-II what character to display and the VIC-II then gathers the actual bit value of each pixel from the CG. There are such scanlines 25 times for every screen refresh or once every 8 scanlines at the start of each row of text.

That’s because in order to scan both the RAM and the character generator during the same scanline, the VIC-II steals half cycles from the 6510 and there will be no access to the kernal for 40 cycles making the attempt at finding bus contentions just about pointless.

The VIC-II essentially caches the value of the 40 characters to display the first time it scans the RAM then uses that cache for the 7 following scanlines and only gathers data from the character generator, leaving the 6510 free to access the RAM or any other device on the bus, such as the kernal ROM until the beginning of the next row of text.

Care also has to be taken to avoid the period of time between the bottom of one display refresh and top border of the following one, which includes the vertical blanking interval because there will be no access to the character generator as the VIC-II will not need any data for the display then. During this period of time, the VIC-II accesses the RAM strictly for the purpose of refreshing it, it reads no data from RAM or the CG.

To make a long story short, only 7 out of 8 scanlines and only those with text to display are of interest. Lets connect channel 1 of the TDS 1002 to the !CS of the kernal ROM and channel 2 to the !CS line of the CG.

I first set the scope to detect low pulses of 400ns or more on channel 2 and nothing came up on the screen! Excuse my naivety but aren’t the half cycles of the CPU and VIC-II supposed to last about 500ns each? As I reduce the length of the negative trigger impulse on the scope, eventually, I do manage to capture something when the trigger impulse is down to 346ns. What an unpleasant surprise comes before my eyes!

Image
Stutters on the character generator’s !CS

The low pulses on the kernal ROM’s !CS are okay but what garbage is this on the character generator’s !CS? There are negative stutters on cycles where the kernal ROM is accessed and positive ones on cycles where the 6510 is turned off. Since the kernal ROM is no longer accessed on multiple cycles after the trigger point then this is clearly the beginning of a scanline where the VIC-II steals cycles from the CPU. I tried capturing again with the same settings and the positive stutters were gone but the negative ones are consistent.

With such irregular signal on the CG’s !CS, no wonder the scope didn’t trigger until I reduced the pulse width setting. I couldn’t believe my eyes so I tested another 64, one with PCB 250466 and got exactly the same result. The only explanation I was offered by another hacker is that the 6567 uses multiplexed addresses while the CG has standard address lines and the demultiplexing trips in its own feet as !VA14 has a constant value generated by a CIA but VA12 and VA13 both come directly into the PLA without any demultiplexing and so they truly represent A4 and A5 for a portion of the 6567’s half cycle.

But the question is: Do we have bus contentions because of these stutters?

Image
Summing the CG’s and the kernal’s !CS lines: No contentions here…

The sum of both !CS signals never really goes below 4V and I know the little downward spike on the left is caused by ringing on the kernal’s !CS, not because the CG’s !CS was low too for a short burst. Definitely, the stutters don’t cause bus contentions. However, the stutters are the reason why I couldn’t trigger the scope properly at first. Lets keep going down with the pulse width setting and see if I can finally capture one of these scanlines with no CPU freeze.

I hit the jackpot once I reduced the pulse width trigger setting to 313ns. I captured 5 consecutive cycles where both the CG and kernal are accessed alternatingly by the CPU and VIC-II.

Image
Five cycles in a row toggling between the CG and kernal

The positive stutters on the CG’s !CS are still present and much more pronounced but they don’t show up on every cycle. I assume A4 and A5 don’t always have the values that could cause the stutter to appear. Nonetheless, it is clear to me that what we have here is the cause of the sparkle bug that plagued early slower character generators and that resulted in the 64’s dark/light blue startup colors. Engineers selected these colors to make the bug less apparent the very first times the 64 was exhibited at shows.

Now lets add the signals and see if we’ve finally managed to have a bus contention.

Image
Mr. Tramiel, your PLA sucks!

Ouch! If what’s here is correct, not only do we have bus contentions with the original PLA, we get one on every consecutive cycles where the CG and kernal are accessed alternatingly. It occurs when switching from the CG to the kernal but not the other way around. Lets zoom this. Seeing the amplitude of the downward spikes this is definitely not only caused by the ringing on channel 1.

Image
A very short contention indeed

As expected, the slower rise time, more than double the fall time, is part of the problem. The time span between the 2 vertical cursors is 5.2ns and for that period of time, both signals are below 2 volts and could represent a bus contention. It would have been easy to build in the equations a positive static hazard that lasts a few ns to prevent this but they didn’t do it.

Knowing the reaction speed of circuits from that era, we know there is very little chance this could pose serious problems. I did dozens of captures of this specific transition interval and always got nearly identical results.

However, this brings a very interesting caveat if the kernal ROM has been replaced by a faster chip. Many people have made their own clones of JiffyDOS. If the ROM replacement they have used to make this clone is a modern chip with response speeds possibly as fast as 45ns, nearly 10 times faster than legacy chips, then there is a great deal of chance the new kernal ROM will start signaling on the bus long before the character generator, a much slower reacting chip comparatively, has stopped signaling.

Most definitely, in this specific case, newer is far from better. I feel reassured when I think of all the clones I made back around 2007 to 2008. I have used legacy 27128 chips with 200ns response speeds or more on all the 64 and SX-64 JiffyDOS chips I ever built. They came from antiquated 8-bit ISA SCSI adapters for PCs.
Last edited by eslapion on Mon Dec 12, 2011 1:13 am, edited 1 time in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

Senior Trend!
As said earlier, the Commodore made PLA is a clone of something that existed before. It is simply improved over the original and is about twice faster. If the improved version does cause nearly insignificant bus contentions that could only become problematic with very fast kernal replacements then how does the original fare? Undoubtedly, with even slower rise times there is a great deal of chance the bus contention will last much longer.

The chip examined here will be an 82S100 from a very early 64 with 5 pin video. It will simply be plugged in the test bed 64 for consistency. This chip has been manufactured on the 31st week of 1982 making it the oldest chip I have in my collection that is designed for use in a 64. I wrote the part no. 906114-01 with a special pen on it to clearly indicate what it is as the 82S100 is also used in PET computers and 1551 drives with different logic equations programmed in them.

Image
The original PLA for the 64, the programmed 82S100

Lets first look at those !CS lines for the CS and kernal.

Image
Five cycles in a row toggling between the CG and kernal with the 82S100

The transition times are inaccurate at this scale but the fall time appears similar. The signal is generally identical to what you’d see with the MOS chip. Lets zoom on this.

Image
Confirmed contention for sure!

Although the fall time on this chip is actually shorter, the rise time balloons to 19ns which results in a guaranteed bus contention. The interval where both signals are below 2v lasts about 13ns which is well within the reaction time of slower logic circuits and for a few ns, the signals are even both below 0.8v which is certain to trigger both ROM chips signaling at the same time on the bus.

Still, there is no positive static hazard to prevent this from happening.

BTW, this chip which is actually from Commodore didn’t work well on a 64 with board rev. 250466 and even if it did work well on the test bed 64, it caused problems with the B.I.80 display adapter (Hey that’s a legacy cart!). Strangely, it worked just fine with the 1541 Ultimate Plus.

I guess that’s why Commodore people were in a hurry to get a better version of this chip and only very early 64s have them. This is a serious mess. The kernal replacement chip potential problem mentioned with the MOS chip will most definitely get far worst with a PLA like that.

Using the chip for a few minutes, I couldn’t help but check the kernal ROM and it did get considerably warmer than normal. I suspect this PLA will cause bus contentions with just about every fast transition it performs, not just those from CG to kernal.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

The new kid on the block
The M27C512-90B6 was the last programmable parallel bus PROM memory chip on the market with an officially advertised response speed slower than 80ns. It was also the last chip of this kind ever made by ST. But there is a catch.

If you closely examine this circuit’s behavior when used as an ordinary ROM, it has a very short propagation delay followed by a rather long transition time. This chip behaves as if a company made a very fast chip then purposely slowed down its output. They gave it a “lazy output”, nearly identical to those of legacy ROM chips.

Another property of this circuit is that is uses CMOS technology all the way and therefore its output will have a greater amplitude as the output rises to a near 5V instead of roofing at about 4V like the Commodore made PLAs and 82S100 do when signaling a logic 1 because they use NMOS or TTL technology.
The M27C512-90B6
The M27C512-90B6
M27C512_nofreeze.gif (5.03 KiB) Viewed 6915 times
The first thing I notice is the stutters with the CG’s !CS are still very much present. Clearly this is something caused by the signals fed into the PLA and not the PLA itself. As the old saying says… caca in – caca out.

The fall time is similar to the other chips at 6.5ns but the rise time appears slow at 15.3ns but, this is for a transition going all the way to 5V. Going from a logic 0 to a valid logic 1 at 2v really takes about 6ns. Let’s look at the math channel and see if we’ve got potential contentions.
Summing the kernal and CG’s !CS lines with the M27C512-90B6
Summing the kernal and CG’s !CS lines with the M27C512-90B6
M27C512_math.gif (4.33 KiB) Viewed 6915 times
Now even though we’ve got downward spikes, they are much less significant but there’s something new. Now they appear both at the transition from the kernal to the CG and the other way around. We have to inspect both occurrences.
The transition from CG to kernal with the M27C512-90B6
The transition from CG to kernal with the M27C512-90B6
M27C512_zoom.gif (4.42 KiB) Viewed 6915 times
At close inspection, the transition times appear nearly identical to those of the MOS 906114-01 but in fact, the switching is a little faster because this chip signals a logic 1 with one more volt than the previous chips. The transition from logic 1 to logic 0 and vice versa is actually faster. But there is something far more important here.

What is the duration of the contention? Well, there isn’t any! Both signals begin to switch at the very same time and the falling of the kernal’s !CS is slightly faster than the rising of the CG’s !CS but it now starts to fall from 5V instead of 4V and so they cross value at about 2V.

At no point in time are both signals below 2V and as such, unless you combine a very fast kernal with the slow original CG, the possibility of a bus contention is just plain non existent using this type of IC as a PLA for the Commodore 64.

Now let’s examine the transition from kernal to CG which also appeared to pose a problem on the math signal.
The transition from kernal to CG with the M27C512-90B6
The transition from kernal to CG with the M27C512-90B6
M27C512_zoom2.gif (4.39 KiB) Viewed 6915 times
Now, we do have a period of time where both signals are below 2v. The scope indicates a duration of 400picosecond. That’s 0.4ns. This is so short it can’t be accurate with this type of scope and is completely irrelevant considering the speed of reaction inherent to legacy chips.

The math channel indicated the lowest sum for both channels is 3.2 volts and this means both channels should have a value about 1.6 volts, well above the threshold of 0.8 volts to represent a logic 0 that would trigger a legacy ROM chip to start signaling.

A bus contention here is still absolutely impossible. Its not voodoo electronics, its simple technology doing what it is supposed to do.

The only way you could have a bus contention here is if the CG is much faster than the kernal. Have you ever heard of failing CGs replaced by new and faster chips? I have not.

I am absolutely certain there are many other brands of PROMs, probably even some still available today, that produce absolutely no bus contentions when used as a substitute for the 64’s PLA but they may not work as well as the M27C512-90B6 because of the delay required on the CASRAM line for proper operation. After all, the M27C512-90B6 is rated for a response speed of 90ns.

Perhaps adding a capacitor on the CASRAM output of these chips to increase the transition time could do the job of delaying the signal. Perhaps combining them with a slow 74LS14 inverter connected in a cascade configuration could do the job. Six inverters placed in a row could delay a logic signal by as much as 90ns and even more if some filtering is used.

Claims that PROMs and EPROMs will systematically cause bus contentions when used as substitutes to the Commodore 64’s original PLA are just plain falsehood.

I have a good collection of carts for the 64 including the 1541 Ultimate, B.I.80, Super Snapshot V4 and V5.22 and the 1750 REU. All these carts work perfectly well with the M27C512-90B6 on 3 different 64s tested with this chip as a PLA. They have boards 250407, 250466 and 250425. Other people have also tested it in the SX-64 which is plagued by failing PLAs. (Please note I no longer have the 64 with board 250425)

The B.I.80, specifically which caused problems with the 82S100 and works well with the other PLAs still crashed every now and then with the MOS 906114-01 after an hour or two of running. I left it on the test bed 64 running for more than 6 hours and couldn’t manage to generate a crash.

But that’s not the end of the story. I left my 64 on for about 2 hours during the scope captures and couldn’t help but notice the kernal chip isn’t as warm as with the original PLAs. The 6510 produces less heat with the M27C512-90B6, so does the CG and the DRAM chips. The DRAM chips and the kernal are the chips on which I noticed the biggest difference. Could the 64 actually consume less power when using this chip as a PLA?

Sure enough, when measuring the 5Vdc load on the PSU, it shows a healthy 1.25A when using the MOS 906114-01. It rises to 1.32A with the 82S100. However, the M27C512-90B6 turns the 64 into a lean machine at only 1.12A.

This chip does not CAUSE bus contentions in the 64, it REMOVES them therefore contributing to increase the lifespan of the machine in which it is installed.
Last edited by eslapion on Sat May 25, 2019 1:43 pm, edited 3 times in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

Other findings
Among the many weird things I also found during the span of this investigation…

For one thing, the negative stutters on the CG’s !CS that appear when the CG is not accessed by the VIC-II also show up on the kernal’s !CS when the 6510 is running by accessing something other than the kernal such as RAM or IO.

This is rather troublesome as they last more than 100ns. Looking at other signals from the PLA when these stutters occur, they don’t seem to cause any more bus contentions than transitions from the kernal to the CG.

Here’s a snapshot with the kernal’s !CS on channel 1 and CASRAM on channel 2. The 3 notches on the CASRAM line indicate the CPU simply accessed the RAM instead of the kernal ROM for this one specific cycle. That’s exactly when the stutter on the kernal’s !CS occurs.

Image
The kernal’s !CS stutter with CASRAM on channel 2

Since this occurs within the CPU’s half cycle, I can only guess this happens because the CPU’s address bus offers invalid values for a short period of time. Once more, at this scale, the transition times displayed by the scope aren’t valid. Just in case somebody wants to blame the PROM based PLA, they all do exactly the same.

Just for the fun of it, I placed a probe on a line from the PLA that shouldn’t be used often during normal operation, the !IO line (pin 12). This line, I guess, is only used when the CPU scans the keyboard. Remember we’re talking about a 64 that’s only turned on and does nothing else here. What I found, as expected, are very clean 450ns low pulses and absolutely nothing else. However, the stutters on the kernal’s !CS are still present.

This indicates, beyond the shadow of a doubt, that changing inputs, by themselves, cannot cause this specific ROM based PLA to ever have unstable outputs that could trigger devices to start signaling on the 64’s bus at undesirable moments. Any and all spurious output variations that appear on the ROM based PLA substitute also show up with Commodore made PLAs and 82S100 chips. They simply show up cleaner with a good CMOS chip.

Image
The kernal stutter with !IO on channel2

So, the next time somebody tells you the ROM chips cause bus contentions because a group of people got together and decided so, tell them just because a group of people got together and decided the earth is flat doesn’t make it so.

I have read countless totally fallacious claims with regards to ROM based PLA substitutes and bus contentions including:
if its an eprom, then it will. no way around it really

by principle, anything that is not a logic chip exhibits this problem

the problem with bus contention has been explained more than enough, by various people, in various threads. there is nothing to prove. all that is left are people who think who know it all better and who think that the laws of physics do not apply to them.
==FOLLOWING TEXT WAS MISSING==
Stating that “by principle” a memory circuit designed decades after the Commodore 64 was out of production and for completely different purposes will invariably cause bus contentions in the 64 is pure invention. One of the most important reason being that various programmable memory circuits available on the market today and since the mid 1980s use totally different principles of operation and have greatly varying types of technology built inside of them.

Clearly, if the problem does exist and it “exhibits” simply because it’s not a logic chip then it would have been possible to detect it. What was found here is the complete opposite. The device studied does not “exhibit” a problem, it actually RESOLVES it.

What was presented above IS the results of the laws of physics and it does represent technical facts as studied by professional electrical engineering instruments.

If anyone ever denies the validity of this data then there is only one person who can convince them otherwise and it’s not an engineer… it’s a psychiatrist.

If you’re not happy with these findings then don’t blame me. Do just like Duran Duran and Blame the machines.
Last edited by eslapion on Thu Jun 04, 2015 10:02 am, edited 1 time in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

The CAStrating issue…
The big problem that has plagued both PROM based as well as logic circuit based PLA substitutes has something to do with CASRAM.

For some reason, this line has to be delayed by a few ns for the PLA substitutes to operate properly. I will explain here why this particular line poses a problem and how memory access works in the 64.

Page mode dynamic RAM uses a pair of signals called row address strobe and column address strobe that are used for multiplexing address lines as well as control the refresh circuitry.

Since we’ve already said the 64 uses RAS only refresh, we know there are times when only the RAS line will be used. This happens every half cycle the VIC-II or 6510 doesn’t access the RAM. But even if you placed the VIC-II in bitmap mode with tons of sprites and the CPU running ML in RAM only with disabled IRQs to maximize RAM accesses, this would still leave the VIC-II half cycles during the display of the top and bottom borders as well as the ones during the left and right borders where it is possible to refresh DRAM and there would be no problem.

==FOLLOWING TEXT WAS MISSING==
And, oh by the way… Simply accessing a byte in DRAM refreshes an entire “row” of memory. Pulling RAS low does that automatically and the low addresses expressed at that moment tells the DRAM chips what row to refresh. As such, if your ML program happens to access 256 consecutive bytes, then you’ve just refreshed the whole 64’s DRAM.

Since the 6510 uses a standard address bus, the addresses provided by the CPU have to be multiplexed to address RAM and the registers of the 6567. This is done with a pair of 74LS257 multiplexers.

These multiplexers take the address represented by the 6510 and present it to the DRAM in a multiplexed form at every CPU half cycle but there is a catch. The 6510’s memory map is not always filled with RAM only. As such, the PLA has to decide whether or not the request to access a specific memory location should be forwarded to RAM or somewhere else.

When the selected memory map indicates the selected address is in DRAM, the CAS signal input into the PLA is then reflected on the line called CASRAM which is tied to the CAS inputs of the DRAM chips but not of those of the multiplexers. On cycles where the CPU decides to access something not mapped as RAM, the RAS signal still makes its way to the DRAM chips but the CASRAM line is kept high and this triggers a refresh cycle.

Access to DRAM is signified by first pulling RAS low which tells the DRAM and multiplexers that the information present on the multiplexed bus represents the lower address lines A0 to A7. However, the trigger on the multiplexers that told them to start signaling the lower addresses came earlier from the !AEC line which indicates this is a valid CPU half cycle and so the multiplexed bus already contains valid information when RAS is pulled low.

About 80ns later, the CAS line is also pulled low too to tell the DRAM chips that addresses A8 to A15 are now on the multiplexed bus. RAS and CAS are kept low until the end of the access.

Problems with excessively fast PLAs occur when the CAS line coming from the VIC-II is pulled low. This line tells the multiplexers to begin exhibiting the upper addresses from the 6510 on the multiplexed bus. If it was directly tied to the DRAM chips it would also tell the DRAM that the upper addresses are valid RIGHT NOW! This is not true because the multiplexers are still busy shifting the multiplexed bus from the lower to the upper addresses.

In 64s with board revisions prior to 250466, there are 8 DRAM chips to receive the multiplexed signals along with 33 ohm resistors to prevent overloading these multiplexers and that means the transition from low addresses to high addresses on the multiplexed bus takes a bit of time. This bit of time, with problematic PLA subs, is more than the delay between CAS being signaled to the PLA and the PLA reflecting it on CASRAM and so DRAM chips are told to read the value of upper addresses which are still in the process of shifting.

Since board rev 250466 has only 2 DRAM chips, the transition is much faster with this board and it will tolerate just about any PROM based PLA substitutes. Even Atmel’s AT27C512 chips rated for 45ns work perfectly well on almost all of these boards.

On the 82S100, when the CPU accesses the RAM, there is a 40ns delay between CAS being pulled low on the input of the PLA and the CASRAM output reflecting this change. This delay falls to 28ns on the MOS 906114-01, the chip which is said to work with all 64s. The M27C512-90B6 takes 24ns to reflect the same change.

Using a pair of inverters from a legacy 74LS14 will add a 26 ns delay to a TTL digital signal. A pair of inverters from a modern 74HCT14 chip will add 22ns. A simple chip like that added to a PROM based solution is just about guaranteed to fix the problem caused by faster chips.

If we come back to boards rev 250466, they have a very particular characteristic. Looking at the CASRAM line coming from a PROM based PLA reveals a very interesting phenomenon. The rise and fall times just explode to a whopping 91ns and 46ns. This can only indicate a serious impedance load on that line that no other previous 64s has.

Inspecting the board with the multimeter reveals the CASRAM signal from the PLA, unlike on previous revisions of the main board, is not directly connected to the DRAM chips. The signal, instead, goes through an RC filter composed of R42 (82 ohms) and capacitor C204 (150pf). On this specific board, Commodore engineers intentionally built a way to slow down the CASRAM signal.

On the scope, comparing the CAS signal coming from the 6567 and the resulting CASRAM signal coming from the PLA makes the filtering effect obvious.
CAS and CASRAM on the 250466
CAS and CASRAM on the 250466
250466_CASFILTR.gif (4.56 KiB) Viewed 6944 times
The signal that actually reaches the DRAM chips is even more sluggish as it is the output of the RC filter described above.
CAS and filtered CASRAM on the 250466
CAS and filtered CASRAM on the 250466
250466_CASFILTR2.gif (4.59 KiB) Viewed 6944 times
Filtered like this, the CASRAM from any PLA substitute will be acceptable. It delays the 2V falling threshold by about 50 ns. Transition times become ridiculous at 70ns and 110ns.
Last edited by eslapion on Sat May 25, 2019 1:54 pm, edited 2 times in total.
Be normal.
PhilRanger
Vic 20 Hobbyist
Posts: 143
Joined: Thu Aug 25, 2011 10:04 am

Post by PhilRanger »

Very complete topic coverage, hats off and thanks Eslapion!
Phil Ranger
-------------
"Don't eat the trees 2" for the VIC 20 : http://www.box.net/shared/u398kj0nr0lkauzm1k67
on line: http://www.mdawson.net/vic20chrome/vic2 ... otrees.prg
User avatar
e5frog
Vic 20 Nerd
Posts: 551
Joined: Sat Feb 17, 2007 5:46 pm
Website: http://channelf.se
Location: Sweden
Occupation: Service Engineer

Post by e5frog »

Very interesting, would be interesting to hear what the protesters think about this investigation and if there are any evidence against it.
My other interest: http://channelf.se
User avatar
RobertBe
Vic 20 Elite
Posts: 2304
Joined: Sat Jul 14, 2007 2:48 pm

Post by RobertBe »

e5frog wrote:...would be interesting to hear what the protesters think about this investigation...
Ah, the Occupy protesters... ;)

Wall Street, San Francisco, Oakland, Los Angeles, etc.,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
User avatar
e5frog
Vic 20 Nerd
Posts: 551
Joined: Sat Feb 17, 2007 5:46 pm
Website: http://channelf.se
Location: Sweden
Occupation: Service Engineer

Post by e5frog »

No these:
http://www2.pictures.zimbio.com/fp/Prot ... MwPGLl.jpg


:-)

I meant the ones that are the reason for this investigation to take place at all.
My other interest: http://channelf.se
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Post by eslapion »

e5frog wrote:I meant the ones that are the reason for this investigation to take place at all.
I guess they're too busy chatting with the psychiatrist and discussing the change in medication.
Be normal.
Post Reply