6502.org

i have been using the 32 KB SRAM cache chips for my 6502 circuit's memory. i get them from old 386 and 486 motherboards i have stashed away. there are a few different manufacturers' chips that i've been using but all have identical pinouts to the Alliance AS7C256-PC model.

these chips do work on the circuit, my monitor firmware boots when i have the chips installed (it makes use of the stack, so if the RAM didn't work it would not run correctly)

the problem is when i put one of these SRAM chips on the circuit, they work fine for maybe an hour, then then, everytime, they invariably start getting destroyed, corrupting data, etc. and the damage is permanent.

any idea what might be happening here? my power source always reads a consistent 5.05 volts, so no problem there. they way i've got it hooked up is:

chip enable (CE) pin - connects to the RAM's correct memory space selector from an LS139 2-to-4 decoder.

write enable (WE) pin - connects directly to the 6502's R/W pin

output enable (OE) pin - connects to the inverted output of the 6502's R/W pin

the address and data lines, like the ROM chip and the two LS373 latches for parallel I/O communication with my laptop, directly connected to the appropriate pins on the RAM.

what am i missing here? could this somehow be caused by the connection to the laptop's parallel port? has anybody else ever run into this problem?

any ideas off the top of your collective heads, let me know please -- but in the mean time i'm going to create an actual schematic of the circuit so everything is more clear.

It's a common mistake. Write-enable (or, alternately, the chip-enable) must be qualified by phase 2. It's not negociable. The address is not guaranteed to be valid and stable before R/W\ goes down; so you can write to wrong addresses as well as the intended one, unless you prohibit writing until phase 2 rises. Even if it appeared to be working for awhile because the wrong addresses written to were not getting used yet, or even if it actually did work completely initially, it would have been right on the edge, and a small change in temperature can push it over.

ah, of course! that makes sense. and i guess the "damage" wasn't permanent. i am now using one i thought went bad but it's working just fine. i assumed they went bad because even after turning it off and on or resetting a few times, the errors kept happening until i tried a different chip.

i added some code to my monitor that'll run a continuous memory burn-in stress test and make sure it can run a few hours (and again probably overnight before i go to bed) without running into an error.

now i can get to work on my video circuit, i don't really like using a laptop to do the I/O with it. i cannibalized one of my (many) old monochrome display cards. (i used a clone, not a genuine IBM as i would feel bad doing it to a true blue!) i nabbed the MC6845P off of it, as well as the 16.257 MHz oscillator.

from what i understand, getting it going it a simple matter of giving it some memory, a character ROM, and tie it's "display enabled" line into the 6502's ready/busy line so it can have the address/data bus to itself during screen refreshes. then i just have my firmware init with the correct parameters. (a table for which i've already taken from the source code to a generic 8088/V20 BIOS)

did i get that right? thanks for the help, garth!

I have no idea if you got the video right since the only video I've fooled with is my simple analog oscilloscope raster graphics circuit, but you're welcome about the memory thing of course. I have a lot of tips at viewtopic.php?t=342 .

A lot of the later SRAM cache chips were 3.3v parts, like the Aliance AS7C3256. While most will tolerate 5v as an absolute maximum, they might not run at that very well or for very long. They do, however, seem to work fine in a 5v circuit if powered through a diode. This gives them about 4v and they seem to tolerate that just fine as well as tolerate the address and data bus signals.

This of course may not be the problem you are having, but just a thought.

interesting, i double checked the datasheet for the AS7C256 just now since you brought that up. this says that the model i'm using does handle an absolute maximum of 7 volts, so i'm good there.

i'm confident i've got it fixed from garth's info on the phase 2 qualification. i've been running this RAM test code i threw into my firmware for over 36 hours now without any errors, i'll let it go for 48 hours before shutting it down just for good measure.

i've got this continuously checking every bit from $0200 to $7FFF.

on a side note, this and the rest of my monitor ROM is the first actual program i've written in 6502 assembly. i've been familiar with it from writing an emulator, but actually sitting down to write something semi-complex in it makes me realize what a big step-up the 8086 was as far as features! i've written an 8086/V20 emulator as well. that was a few months of hell, but i ended up with a pretty good little PC emulator! (including floppy/hard drive, adlib support and other stuff.. ethernet emulation!)

You'll get a small step up from the 6502 to the 65c02, and a much bigger step up from there to the 65816. Even a 6502 outperforms an 8086 though in the Sieve of Eratosthenes benchmark in cycles required to finish the job though, and all the more an 8088. For completing ten iterations of the Sieve: IOW, a 4MHz 65816 did it faster than an 8MHz 8086, yet none of the production 65816's available off the shelf today are rated for any less than 14MHz. I also find the '816 much easier to program than the 6502. (See an example here. It has more instructions and addressing modes, and features that make it far better suited for code relocation, multitasking, and a lot of other things where the 6502 is either clumsy or totally inept.

The 65C02 is also fairly zen-like and elegant in the small and tight opcode architecture compared to other architectures. It makes for a helluva small die.

by the way, I have a small and clumsy differing address routine in the codes submitted on here that gets past the possible open address bit issue that would cause the regular AA/55 test to pass while still being incorrect.

One little hint by the way for using the RAM, CHECK THE RAM SPEED. I found 70 nS works out great for a 4 MHz 65C02, I had slower ones that ran my self testing code ok but would crash and burn on running the main program. So that is one small caveat I found from fun experience.

Incidentally, in your the CPY #0 is not needed. It is an automatic implied part of the INY, and STA does not change the status register. (Even if it did, you could do the STA before the INY since INY does not affect the STA.)

The result comparison to 0 is automatic in all load, increment, decrement, addition, subtraction, AND, OR, EOR, rotate, shift, and stack-pull instructions. (Hopefully I got it all.)

Hmmm... on second look, I don't think you meant to always store $AA to burnptr there, did you? That's what you have, with $AA left in A from the memory location test.