SRAM problem : decode- related ?

For discussing the 65xx hardware itself or electronics projects.
calculi
Posts: 68
Joined: 19 Oct 2015
Location: France

SRAM problem : decode- related ?

Post by calculi »

Hello,
I have a problem in my homebuilt 65C02 system, in which addresses from $0000 to $7FFF are assigned to RAM. Its first implementation used the address decoding circuit described in the "address decoding section" of Garth's primer (32K RAM + 16K ROM) : /OE and /CS both qualified by PHI2 and /WE directly connected to RW\ from the CPU :

/OE , /CS = NOT (PHI2 AND NOT A15)

That works well with a 70-nS SRAM, up to 9.6 MHz (well beyond specifications). I ran it at 6 MHz clock rate during months without any problem.


Then I decided to go faster : 8 MHz. I ordered 55-nS SRAMs and I changed the decoding circuit after having read about the hard limitation induced by a PHI2-qualified /CS. I used Daryl Rictor's method (SBC-2) : /CS wired to A15, /OE receiving the inverted RW\ signal from the CPU, and finally /WE qualified by PHI2 :

/CS = A15
/OE = NOT RW\
/WE = NOT (PHI2 AND NOT RW\)

Here are the results :

- 1st decoding method / 6 MHz / 55-nS SRAM : NOK, the RAM test reports write errors.
- 2nd decoding method / 6 MHz / 55-nS SRAM : NOK, same test result.
- 2nd decoding method / 6 MHz / 70-nS SRAM : OK :shock:

The 70-nS SRAM works perfectly well even at 8 MHz.. I didn't ramp-up the clock to check the limits, but the RAM test didn't report any error during a 24-h run, and my application also runs OK.

The SRAMS I use are : BSI BS62LV256-70 (https://emu-docs.org/WonderSwan/bs62lv256.pdf) and Alliance AS6C62256-55 (http://www.alliancememory.com/pdf/AS6C62256.pdf). I investigated their data sheets ; at first I wondered if the Alliance VOH, specified to only 3V typical, wasn't the point in my 5-V SBC : no, its VOH actually equals VCC (checked on a test rig).

Then I stumbled upon a note to be found only in the Alliance datasheet, page 6 : "/WE and /CE must be high during all address transitions". So my hypothesis is that when the RAM is selected as soon as A15 gets low, it latches the address bus -but each bit hasn't still fully stabilized (tADS not elapsed).
(as if the internal decoding circuitry was edge-triggered by /CE)

What do you think of all that ? I may wery well be doing so huge a mistake that I don't notice it...

Thank you !
Marc
User avatar
BigDumbDinosaur
Posts: 9426
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: SRAM problem : decode- related ?

Post by BigDumbDinosaur »

calculi wrote:
I investigated their data sheets ; at first I wondered if the Alliance VOH, specified to only 3V typical, wasn't the point in my 5-V SBC : no, its VOH actually equals VCC (checked on a test rig).
It seems all these SRAMs now have TTL-compatible inputs and outputs, but nevertheless do work with the WDC 65C02. Can't vouch for behavior with other manufacturers' 65C02s.
Quote:
...Then I stumbled upon a note to be found only in the Alliance datasheet, page 6 : "/WE and /CE must be high during all address transitions".
If that is the case with the Alliance part then you are going to intentionally need a gate delay from the time when A15 goes low until you assert /CE. Sometimes the prop time introduced by decoding logic actually works in your favor. :o Sticking an OR gate in there would do it. Frankly, I've not read of such a timing constraint in any of the SRAMs I've used (mostly ISSI and Cypress).

BTW, you've verified that nothing else is getting on the data bus when the SRAM is selected, right?
x86?  We ain't got no x86.  We don't NEED no stinking x86!
calculi
Posts: 68
Joined: 19 Oct 2015
Location: France

Re: SRAM problem : decode- related ?

Post by calculi »

Thank you BDD !

Concerning the first point you mention : I actually use a WDC CPU. Next to the second point : apart from adding a delay, which I thought about, I already (theoretically) checked for the bus not being spuriously used by some other device. The circuitry devoted to ROM and I/O is also derived from Garth's primer, here it is :

/ROMSEL is wired to the ROM's /OE and /CE.
/IOSEL is dedicated to the VIA and the ACIA. (each of them has an address line devoted to it, A12 for one, A13 for the other)

/ROMSEL = NOT (A15 AND A14) => ROM is accessed from $C000 to $FFFF.
/IOSEL = NOT (/ROMSEL AND A15) => I/O are accessed from $8000 to $BFFF.

To me, RAM, I/O and ROM selects are mutually exclusive -within the tolerances induced by the propagation delay of the 74HC00 I use.

BTW : that still doesn't explain why the Alliance RAM misbehaves even with the old decoding method (PHI2-gated /CE and /OE) .... ?

Marc
User avatar
BigDumbDinosaur
Posts: 9426
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: SRAM problem : decode- related ?

Post by BigDumbDinosaur »

calculi wrote:
BTW : that still doesn't explain why the Alliance RAM misbehaves even with the old decoding method (PHI2-gated /CE and /OE) .... ?
Have you tried a different SRAM? There's always the slight possibility of a defective part.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
calculi
Posts: 68
Joined: 19 Oct 2015
Location: France

Re: SRAM problem : decode- related ?

Post by calculi »

Yes, I tried other samples of the same Alliance part with the same result -that doesn't exclude the whole batch being defective... Hmmmm, not very likely anyway. Besides that, it becomes more and more difficult in Europe to get parts other than unknown Chinese brands (especially in 600-mil DIP form factor).

Slightly OT : congratulations for POC V2 coming to life ! I wish you much fun.

Marc
User avatar
BigDumbDinosaur
Posts: 9426
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: SRAM problem : decode- related ?

Post by BigDumbDinosaur »

calculi wrote:
Yes, I tried other samples of the same Alliance part with the same result -that doesn't exclude the whole batch being defective... Hmmmm, not very likely anyway.
Do you have an oscilloscope handy? You may need to watch the bus signals to see if the logic voltage levels make sense. One or two bad SRAMs might be a possibility, but it's unlikely that an entire batch is no good. Usually, if memory corruption is an issue I'm quick to look for glue logic errors that violate the data setup and hold times for the device in question. Scoping might help you with this, specifically by observing tWP and tDW for violations (see timing diagram "WRITE CYCLE 1" on page 6 of the data sheet).
Quote:
Besides that, it becomes more and more difficult in Europe to get parts other than unknown Chinese brands (especially in 600-mil DIP form factor).
Too much of that Chinese stuff is dodgy. It's hard enough to get things working without having to fight with out-of-spec parts. Seeing as France is part of the EU I'm a bit surprised that you are having such a hard time procuring good (read: non-Chinese) parts. Are any of the sources in the UK viable for you?
Quote:
Slightly OT : congratulations for POC V2 coming to life ! I wish you much fun.
Thanks. Things would have gotten off to a better start if I weren't working with a part (the NXP 28C94 QUART) whose data sheet could stand some improvement. There is conflicting information in a few cases, plus editing errors and incomplete descriptions of some of the registers. None of NXP's data sheets are all that well written, but this one is pretty bad in some places. :x

It'll take some work to get a usable BIOS up and running. I can reuse a lot of the code from POC V1.1, but the QUART is going to demand a whole new driver, plus changes to the IRQ service routines to handle interrupts coming from four receivers, four transmitters, a counter/timer (which generates the jiffy IRQ for system timing), and the SCSI host adapter. At least I know the core hardware is functional.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
calculi
Posts: 68
Joined: 19 Oct 2015
Location: France

Re: SRAM problem : decode- related ?

Post by calculi »

Quote:
Do you have an oscilloscope handy?
My Beckman scope is limited (20 MHz bandwidth) and the probes aren't very good. I'd better wait for the end of the month, when I visit a well-equipped friend.
Quote:
Seeing as France is part of the EU I'm a bit surprised that you are having such a hard time procuring good (read: non-Chinese) parts. Are any of the sources in the UK viable for you?
I did a quick search today : retailers like Mouser (who ships from USA), Jameco, Farnell, ... don't have much "good" stuff except for... Alliance chips. I need to search further, for example in Germany, as soon as I have spare time. (The 70 nS Brilliance chips I got last year aren't available anymore...) That problem is specific to DIP parts, it's much easier to get SMD parts ; but I'm afraid my hands aren't steady enough :-(
Quote:
Are any of the sources in the UK viable for you?
Please, could you give me some hint ? (provided you don't waste time) Thank you :D

Marc
User avatar
BigDumbDinosaur
Posts: 9426
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: SRAM problem : decode- related ?

Post by BigDumbDinosaur »

calculi wrote:
BigDumbDinosaur wrote:
Are any of the sources in the UK viable for you?
Please, could you give me some hint ? (provided you don't waste time) Thank you :D

Marc
I think there is Farnell, but am not very familiar with UK sources. Perhaps Ed or one of our other British members could help you out. Also, there may be a source in Germany.

As for the DIP SRAMs, I'm afraid those are going the way of the dinosaur. SOIC packages predominate but can be manually soldered. See below, which is the SRAM on POC V2. Garth Wilson soldered those for me, as my vision is too weak to allow me to do such close up work anymore.
SRAM in SOIC
SRAM in SOIC
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Re: SRAM problem : decode- related ?

Post by BigEd »

I'd generally go for one of these suppliers:
http://www.rs-components.com/index.html
http://www.farnell.com/
http://mouser.com/localsites.aspx
http://www.digikey.co.uk/en/resources/international

But I'm fine with buying from Chinese suppliers - they often have free shipping too. Just check reputation, as with any other supplier.
User avatar
GARTHWILSON
Forum Moderator
Posts: 8773
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: SRAM problem : decode- related ?

Post by GARTHWILSON »

BigDumbDinosaur wrote:
As for the DIP SRAMs, I'm afraid those are going the way of the dinosaur.  SOIC packages predominate but can be manually soldered.  See below, which is the SRAM on POC V2.  Garth Wilson soldered those for me, as my vision is too weak to allow me to do such close up work anymore.
I did those with my 30W iron with a 1/8" chisel tip that covers three pins at once.  I didn't use any extra flux, a magnifier, any solderwick, or anything special.  I don't do one pin at a time.  Here's the method:

  • Tack two opposite corners just enough to hold the IC in place.  It doesn't have to look nice yet, but you do need to get the IC straight and centered before continuing.
  • Put some solder on a third corner, at the opposite end of one of the first ones you did.  This will hold the IC in place in the next step.
  • Now go down the other side, starting with the corner which so far got no solder.  Flood that side, making one big bridge all the way down, moving the soldering iron back and forth, making sure all pads get wetted too.
  • Do the same thing to the remaining side which up to now only had the corners soldered.  Now you'll have both sides all bridged, with lots of extra solder.
  • Go back to the first side you flooded.  Hold the board vertically, with that row of pins vertical, and start with the soldering iron at the top of the row, and re-melt and move it down slowly.  The extra solder will come off on the iron.  You might have to shake some off before you get to the bottom of the row, if there's a threat that it will drip onto something it shouldn't.  Continue down the row.  Each pin should be left with the right amount of solder, just perfect, with no bridging, in spite of the large size of the tip.  If I have trouble with an area, I'll put more solder on it again and repeat.
  • Do the other side the same way.


After it's cooled, I chip off most of the rosin with any small tool, preferably one that's not too sharp so it won't scratch the board, then finish with a Q-tip dampened with acetone to get the slight remainder of rosin off.  That way I don't need a vapor degreaser, or to dunk the whole board in solvent, etc..

It may seem very counterintuitive, but the results in the picture speak for themselves.  I don't think I've done finer pitches than .050" this way.  They might require something a little different.

Someone might be afraid that the heat would damage the IC.  Not so.  A couple of jobs ago, in the mid-1980's, I saw transistors actually operating at over 350°C.  They wouldn't last long at that temperature, but it did not instantly destroy them.  The soldering method I'm describing above won't get the die (ie, the actual silicon chip inside the IC) anywhere near that hot, since at a maximum, only one row out of two will have molten solder all over it while the other row is relatively cool, and the die is not right at the pins anyway, but farther in.  60/40 tin/lead solder melts at 183°C and is completely liquid by 190°C, and again, the die won't get that hot.
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
calculi
Posts: 68
Joined: 19 Oct 2015
Location: France

Re: SRAM problem : decode- related ?

Post by calculi »

Thank you for your answers !
Quote:
I'm afraid those are going the way of the dinosaur
Now, I know I'm actually becoming a dinosaur :)
Quote:
SOIC packages predominate but can be manually soldered
Thank you, BDD and Garth, for the detailed method ! I had seen its result in previous posts -but I'm not yet planning a PCB, since my board likely has a problem.
Quote:
I'd generally go for one of these suppliers:
I checked one more time the 4 suppliers you mentioned, BigEd (I forgot about DigiKey) : only found under the "Lyontek" brand, some 55 nS DIP parts. Interestingly their datasheet points out, like Brilliance's, that the high-to-low /CE transition must occur after the address lines have stabilized. I'll try to add, as BDD suggested, some gate delays in the /CE line.


BTW : last year I ordered my WDC parts from the French Mouser site, thinking they have a warehouse in France. Believe it or not, I received them 48 hours later, shipped from... Texas ! Did they resurrect Concorde ? :mrgreen:
User avatar
BigDumbDinosaur
Posts: 9426
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: SRAM problem : Decode-related?

Post by BigDumbDinosaur »

calculi wrote:
Thank you for your answers !
BigDumbDinosaur wrote:
I'm afraid those are going the way of the dinosaur
Now, I know I'm actually becoming a dinosaur :)
Quote:
SOIC packages predominate but can be manually soldered
Thank you, BDD and Garth, for the detailed method ! I had seen its result in previous posts -but I'm not yet planning a PCB, since my board likely has a problem.
You may find this U-Toobe video to be interesting. It describes in some detail the process of soldering fine pitch parts. Before my vision had gone south on me I had successfully solder 128KB SRAMs to POC V1.1 using the techniques described in the video.
Quote:
BTW : last year I ordered my WDC parts from the French Mouser site, thinking they have a warehouse in France. Believe it or not, I received them 48 hours later, shipped from... Texas ! Did they resurrect Concorde ? :mrgreen:
It's about a 10 hour flight from Texas to France on a 747 freighter. The rest of the time would be customs and local handling. It's amazing how far we've come with international shipments. I can recall when a shipment to Europe from the USA or vice versa was a six to eight week process.

Now, if only we could do something about the high customs fees, VAT, etc. :roll:
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Re: SRAM problem : decode- related ?

Post by BigEd »

I roll my eyes, too, BDD, but for completely different reasons.
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: SRAM problem : decode- related ?

Post by Oneironaut »

The SOJ packages are fairly common, and super easy to solder.
SRAMs available from 64K to 512K in this format.

if you don't mind a little monotony, then these can be mounted to DIP sockets as well...

viewtopic.php?f=4&t=3329#p38423

Brad
calculi
Posts: 68
Joined: 19 Oct 2015
Location: France

Re: SRAM problem : decode- related ?

Post by calculi »

Quote:
The rest of the time would be customs and local handling
Yes, I know :wink: 5 years ago, my transistor clock kit was "stalled" a whole week by the customs.
Quote:
You may find this U-Toobe video to be interesting
Impressive, really ! But as I wrote before, my hands aren't quite steady and I don't think it'll get better...

To Oneironaut : I enjoy reading your posts, Brad, very nice work ! How about a whole processor on breadboards ? (of course, running not less than 20 MHz) :D

Marc
Post Reply