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

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

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.


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. 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!

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

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!

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

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).


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?


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.

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!

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.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
Please, could you give me some hint ? (provided you don't waste time) Thank you

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

_________________
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?

Thank you for your answers !
Now, I know I'm actually becoming a dinosaur

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.

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 ?

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.


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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I roll my eyes, too, BDD, but for completely different reasons.

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...

http://forum.6502.org/viewtopic.php?f=4&t=3329#p38423

Brad

Yes, I know 5 years ago, my transistor clock kit was "stalled" a whole week by the customs.
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)

Marc