About using Static RAM: the C16 expansion case

[MCes]

Chapter 1

I'll try to explain it in simple words, I'll using some exemplification, where it will be possible.

Some information is needed about how the 65XX CPUs use the BUS,
and I found interesting this link ("How the CPU Interacts With the Outside World"):
http://laughtonelectronics.com/Arcana/V ... iming.html

A valid reference document for general D-Ram could be
https://compas.cs.stonybrook.edu/~nhona ... dramop.pdf
but a simplified explanation is good too:

Static-Ram is less complicated:
in a READ cycle (R/W=H), when RAM is enabled, the data linked to the address will be put on the output (after an ACCESS time) and DATAout will remain valid until address remain valid and the RAM remain selected.
WRITE procedure will be correctly performed only during the R/W=L and the RAM is selected, during this time the DATA and the address has to be always valid.

So during a WRITE activity a great difference between D-RAM and S-RAM is that when D-RAM will be enabled by lowering /CAS the D-RAM will use the falling edge of /CAS line to "sample" the Column address, the input data, and the R/W=L status: after a specified time of nS the "data" and the "address" lines could be not valid without corrupting the write activity.
This is not acceptable by S-RAM that need valid data and address for all write activity time.

-If you are here and this base informations are (almost) clear it will be possible to find the core of the problem....

The '264 machines (C16, PLUS4,....) use a video chip called "TED" that is the master of the board generating a lot of timings signal, also the CLOCK that feed the CPU (PH0), MUX (used for D-Ram address multiplexing), /RAS,/CAS and others...

The specifics of the CPU can be found (since 2009) here:
http://www.zimmers.net/anonftp/pub/cbm/ ... index.html

A simplified version (about a WRITE cycle):

The /RAS-MUX-/CAS signals become H synchronously and then fall to L in the sequence /RAS-MUX-/CAS
(/CAS will fall only if a RAM access is needed).

The /CAS=L select the RAM and after the PH0 falling edge the /CAS remain L for min 60 nS and max 110 nS, but the data stable are guaranteed for not more than 60nS, this fact can be not important if you are using D-RAM, but if you are using S-RAM the WRITE procedure is corrupted: the solution don't match the time specs.

To avoid the problem: only the write cycle has to be shortened, and the natural time point is the falling edge of PH0, so the R/W line has to be ORed with PH0 to generate a "deselecting" line that will limit only the WRITE time (but not the READ time) to the PH0 falling edge.

My "64kxC16" expansion was developed with these concepts in mind, because it's an original project (not copied/adapted from similar one) that , as all serious project has to be, was started by studying the specifications and technical documentation of the systems in which it is to be positioned and the devices used.

This timings are the reasons because my expansion project is stable and wellworking since june 2019 and SARUMAN-TED could be stable and wellworking only since christmas 2019.

I hope this post is a sufficiently clear answer to Eslapion's hypothesis that my "64kxC16" is a copy of his SARUMAN-TED.
http://sleepingelephant.com/ipw-web/bul ... 81#p107028

[MCes]

Chapter 2

Read "Chaper 1":
for the same reason each S-RAM that uses only / CAS (/ RAS) signals for chip selection cannot correspond to the times of the specifications,
therefore SARUMAN for C64 cannot be used correctly in a PLUS4 as suggested.

[eslapion]

This timings are the reasons because my expansion project is stable and wellworking since june 2019 and SARUMAN-TED could be stable and wellworking only since christmas 2019.

I hope this post is a sufficiently clear answer to Eslapion's hypothesis that my "64kxC16" is a copy of his SARUMAN-TED.
http://sleepingelephant.com/ipw-web/bul ... 81#p107028

Well, I studied this problem with an oscilloscope and a logic analyzer, not just documents from historical datasheets.

The /CAS=L select the RAM and after the PH0 falling edge the /CAS remain L for min 60 nS and max 110 nS, but the data stable are guaranteed for not more than 60nS, this fact can be not important if you are using D-RAM, but if you are using S-RAM the WRITE procedure is corrupted: the solution don't match the time specs.

If you check the databus with a logic analyzer, you will realize the data is still valid up past the rising edge of CAS so the timing graphic you posted is incorrect in this regard. THW > 110ns.

The problem really occurs only during a CPU write cycle AND ONLY IF IT IS FOLLOWED BY A REFRESH CYCLE. The addresses will also normally start to shift AFTER the rising edge of CAS. However, this is not true when the TED performs a refresh cycle and addresses A0-A7 ONLY will change at THA.

This is a discrepancy between the strict theory of operation and empirically verifiable behavior of the bus of TED machines. In fact, this was very difficult to check and I found out about it only because I made a wire wrap version of Saruman-TED and attached 32 probes to it.

Otherwise, as far as I know everything you said above is true and exact.

There is no problem with DRAM because on early write cycles, there is a latching of the address bus. If somebody was to use a Saruman-64 in a C16 or Plus/4, the product is equipped with... 74HCT573 which happens to be an octal latch.

If you believe there is any problem using a Saruman-64 with a Plus/4 then ask Ray Carlsen why it works perfectly fine.

To avoid the problem: only the write cycle has to be shortened, and the natural time point is the falling edge of PH0, so the R/W line has to be ORed with PH0 to generate a "deselecting" line that will limit only the WRITE time (but not the READ time) to the PH0 falling edge.

I had tried another solution using an XNOR gate and an RC high pass filter which shortens ALL access cycles, read or write and it worked too. Of course it's really necessary only with write accesses but if you do both read and write, it'll work just fine too.

[MCes]

Well, I studied this problem with an oscilloscope and a logic analyzer, not just documents from historical datasheets.

And you demonstrated to have bad studied/used all of them.
Otherwise all your saruman-TED versions was well working, and it's not true.

If you check the databus with a logic analyzer, you will realize the data is still valid up past the rising edge of CAS so the timing graphic you posted is incorrect in this regard. THW > 110ns.

A) the graphic that I posted is the original spec of the CHIPs by Commodore, not a my opinion.
B) your reading is not in contrast with the original spec, but you gamble on what is not guaranteed,
and this make evident that you are not able to develop a project:
a developer has to respect the chips/boards manufacturer data so that the project will be well working with all chips/boards produced,
not only with chips that you measured inside yours specific C16:
"SARUMANTED 1.2 work well on my C16 that I measured, but nobody can guarantee that it will be working on your C16"
Do you call this designing?

GOOD LUCK to you and to who believe in yours mumbles

[MCes]

I had tried another solution using an XNOR gate and an RC high pass filter which shortens ALL access cycles, read or write and it worked too. Of course it's really necessary only with write accesses but if you do both read and write, it'll work just fine too.

I read this part of your post only now.....
I can't stop laughing..... please a moment.....

Another time you demonstrated your ignorance about how a 65xx work....

"I had tried another solution(...)" Remember that you are who is telling that the problem don't exist: so a solution for what?

My friend, I already told you: you are your worst slanderer

If you have the force of your idea: realize it and public the results, also on oscilloscope...
I'm already laughing.....

[eslapion]

Hi Ray,
The Plus/4 and C16 are dependent on a specific functionality of DRAM called 'Early Write Cycle'. This latches the address and databus as soon as CAS falls low.

As such, in theory, using Saruman-64 on a Plus/4 should cause problems. However, you indicated there is no problem.

Could you please type the following commands on your Plus/4:

?FRE(0) - this should display the number of bytes free

GRAPHIC 1,1 - this should give you a white screen with a blue border but there will be garbage on screen if there is a problem.

Thank you,
Francois

Response...

> ?FRE(0) - this should display the number of bytes free

That shows 60669 BYTES FREE

> GRAPHIC 1,1 - this should give you a white screen with a blue border > but there will be garbage on screen if there is a problem.

It flashes a garbage screen and immediately goes to white with blue border.

Ray

A) the graphic that I posted is the original spec of the CHIPs by Commodore, not a my opinion.
B) your reading is not in contrast with the original spec, but you gamble on what is not guaranteed,
and this make evident that you are not able to develop a project:
a developer has to respect the chips/boards manufacturer data so that the project will be well working with all chips/boards produced,
not only with chips that you measured inside yours specific C16:

A) I have noted more than once Commodore posted inaccurate or incomplete information on many of their official documents. Did Commodore openly admit they put bad chemistry in the first C64 PLAs they made ? Of course not. Did they post anywhere the actual response latency required for proper functioning ? Nope! I relied on what I found for myself concerning the C64 PLA and made a product much better than what they did.

B) I gamble nothing. I checked my own machine, of course but, as noted above, I asked other people to check. In Canada, USA and Finland.

GOOD LUCK to you and to who believe in yours mumbles
...
My friend, I already told you: you are your worst slanderer
...
If you have the force of your idea: realize it and public the results, also on oscilloscope...
I'm already laughing.....

You need to learn to write legible (intelligible) English and good manners too.

... I didn't know it was possible to 'mumble' written text. Well, whadaya know...

[MCes]

Another time you have demonstrated nothing...
FREE(0) doesn't check anything....
try 24h with DIAG264 if the SPECIFIC PLUS4 that has on board the SARUMAN for C64 is working fine,
and remember that if it's ok you can only tell:
"SARUMAN-C64 work well on PLUS4 NUMBER xxxxx , but nobody can guarantee that it will be working on your PLUS4"
because it don't match the Commodore spec of the Commodore chips."
Otherwise all your saruman-TED versions was well working, and it's not true.

A) I have noted more than once Commodore posted inaccurate or incomplete information on many of their official documents. Did Commodore openly admit they put bad chemistry in the first C64 PLAs they made ? Of course not. Did they post anywhere the actual response latency required for proper functioning ? Nope! I relied on what I found for myself concerning the C64 PLA and made a product much better than what they did.

The delay by "multiplex address" command to /CAS that Commodore decided to be right is cleary wrote on TED spec, but you decide what exist and what not...

B) I gamble nothing. I checked my own machine, of course but, as noted above, I asked other people to check. In Canada, USA and Finland.

And they told you that:
SARUMAN-TED 1.2 don't work (but it match with timings of yours C16 ),
SARUMAN-TED 1.4 don't work (but it match with timings of yours C16 ),
SARUMAN-TED 1.4 + "OR gate" is working (I hope...)

Another time you are ridiculizing yourself: in the practice you are declaring that I am on right

[eslapion]

The delay by "multiplex address" command to /CAS that Commodore decided to be right is cleary wrote on TED spec, but you decide what exist and what not...

Another time you are ridiculizing yourself

Do you even know what the word 'latch' means? The way the TED accesses DRAM takes advantage of the 'Early Write Cycle' feature of DRAM because DRAM will LATCH information on the bus so Saruman-64 is equipped with a LATCH logic IC... what is it you don't understand buddy ?

The delay by "multiplex address" command to /CAS that Commodore decided to be right is cleary wrote on TED spec, but you decide what exist and what not...

A 500 MHz logic analyzer is more accurate than Commodore's antiquated paperwork... they were almost nonexistent back in 1984.

SARUMAN-TED 1.4 don't work (but it match with timings of yours C16 ),

From what planet did you get that ?

http://www.amibay.com/showthread.php?10 ... C116/page4

Please read the 2 first posts.

BTW, If V1.1 worked fine but not V1.2 because somebody else decided what I added wasn't necessary. Guess what it was...

[MCes]

Read it:
https://www.melon64.com/forum/viewtopic ... ari#p14547
"There is something incredibly fishy about the way TED machines access RAM and it causes weird problems."
"A genuinely stupid way of working"
Your surprise at the oscilloscope picture, that represent a chipset inside the Commodore spec, put on evidence that you never seen the spec before: a superficiality from a delirium of omnipotence...
It happen when a projet was "pasted and copyed" from others machine, and from projets of other (german) person...

[eslapion]

"A genuinely stupid way of working"

YES! Relying on DRAM's early write cycle is just plain stupid! They also cut A14-A15 going to the multiplexers and these 2 combined makes it incredibly difficult to add RAM to a C16 needlessly. It's as if this machine was designed specifically to be impossible to expand.

Did you check how much RAM is left on a standard C16 if you use the graphic mode ? About 4Kbytes !! This is ridiculous.

...

Anyways, to answer what you posted above...

Theory:

But... in reality...

Sidenote: If everything you find in Commodore's documents were true, the VSP bug wouldn't exist. Only one among so many other stuff that some German guy can tell you about. He's a prime expert on this junk.

It happen when a projet was "pasted and copyed" from others machine, and from projets of other (german) person...

What the f*ck are you insinuating here ?

Added edit:
No, I had no checked the 7501/8501 timing charts. The TED is responsible for generating the /RAS and /CAS signals and I didn't find anything there that would explain why latching the address bus was necessary. I relied on modern instruments and they revealed the culprit. They provided more accurate and more complete information than Commodore's paperwork. Just as good for me.

Incidentally, this is also proof I didn't steal anyone's ideas. I started FROM SCRATCH. I developed my products strictly from basic engineering knowledge, not even from information coming from Commodore. Exactly as I did for PLAnkton.

It doesn't warrant ANY of the flurry of insults you posted above. I choose to only post civilized stuff. I suggest you do the same.

[eslapion]

This is such a fine place to come and discuss technical stuff about old computers. I get a flurry of insults because I approached a technical problem from a different perspective. Makes you want to exchange about it all day long... doesn't it ?

Such a friendly place.

[MCes]

(..)I approached a technical problem from a different perspective.(..)

Yes, the problem is that: one approach can be right, yours one is surely wrong....



But why having a discussion?
Real world told us that the SARUMAN-TED that is based on your convincements doesn't work:
SARUMAN-TED 1.2 don't work
SARUMAN-TED 1.4 first design (before Christmas 2019), don't work
SARUMAN-TED 1.4 + "OR gate" (after Christmas 2019)is working but... it's based on my (and Commodore engineers ) analysis of the spec in opposition at what you are telling....

(SMD) 64KxC16 is well working since first shot, and now I can admit:
the old not-SMD version is the ALFA test of my project (a prototype), but it was working so well that I simply recorded the ALPHA test PCB as definitive pcb.....(no BETA needed, it was never modify.....)

SARUMAN?
look the year of Gerrit project:
https://www.forum64.de/index.php?thread ... -auf-sram/

In this thread there are also a pair of Eslapion post, and Gerrit post it's project:
https://www.lemon64.com/forum/viewtopic ... 01&start=0

In the previous linked thread there are also a link to:
https://github.com/jamarju/c64-sram

It's strange, now I'm remembering a question that eslapion done to me:

This vaguely resembles a product I have seen elsewhere. Are you sure you're not reproducing a product created by somebody else ?

[eslapion]

Yes, the problem is that: one approach can be right, yours one is surely wrong....

So reading the Commodore documents and following it like an automaton is right and checking with more modern instruments for less obvious details is wrong ? Wow! what a stroke of luck 2500 PLAnktons work just fine... duh!

But why having a discussion?
Real world told us that the SARUMAN-TED that is based on your convincements doesn't work:
SARUMAN-TED 1.2 don't work
SARUMAN-TED 1.4 first design (before Christmas 2019), don't work
SARUMAN-TED 1.4 + "OR gate" (after Christmas 2019)is working but... it's based on my (and Commodore engineers ) analysis of the spec in opposition at what you are telling....

Ok, well, you find me a single Saruman-TED V1.4 which is faulty...

It's NOT based on anything from you, other than 'nagging' me saying you didn't understand how it could work. It's based on what came out of my TDS3014B and the work I did along with Sylvain Brisebois which happends to be the VHDL coder for GandALF and the PCB designer for TOLB.

(SMD) 64KxC16 is well working since first shot, and now I can admit:
the old not-SMD version is the ALFA test of my project (a prototype), but it was working so well that I simply recorded the ALPHA test PCB as definitive pcb.....(no BETA needed, it was never modify.....)

Good for you, the same happened to me with TOLB and GandALF. I didn't have such luck with PLAnkton, I still have a few manually modded prototypes.

SARUMAN?
look the year of Gerrit project:
https://www.forum64.de/index.php?thread ... -auf-sram/

In this thread there are also a pair of Eslapion post, and Gerrit post it's project:
https://www.lemon64.com/forum/viewtopic ... 01&start=0

In the previous linked thread there are also a link to:
https://github.com/jamarju/c64-sram

1. I don't read German so I had no idea of the very existence of Gerrit4's project.

2. I was no longer on Lemon64 in 2017 and I had no idea this had been posted. Saruman-64 came to existence in 2019. Looking at Gerrit4's project, I can tell you right away he's using the wrong type of technology. He should not use 74Fxx logic ICs for that.

More than one person can come to the same conclusion. Also, why didn't he use this trick for making C128 VDC RAM expansions ? It's almost the same schematic.

This reminds me of that time when you found photos of clones of the Behr-Bonz cartridge and used them to accuse me of making these carts with no gold plating.

It's strange, now I'm remembering a question that eslapion done to me:

This vaguely resembles a product I have seen elsewhere. Are you sure you're not reproducing a product created by somebody else ?

Get a life...

Sarumen-TED doesn't require adding a socket underneath to have the correct pin thickness...

Sidenote: If you're truly convinced Saruman-64 will cause problems on a Plus/4, this product is available at a bunch of various distributors in Europe. Unlike you, I don't turn away customers and refund them just because they happen to know people I don't like. Yes, I have heard of what you did on Amibay. You have such a talent to get people to like you...

[eslapion]

This will also work. Can you tell how it works ?

Don't think you can...

Look mommy! No R/W ... makes no sens huh ? Analog parts? What's going on ?

How can this be ??

[Gyro Gearloose]

Gentlemen,