That looks very nice! I don't think I'm making my wires short enough. I don't get that nifty harp effect.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

The trick is to get them just right. If they curve too much then they act like coils and you get inductance apparently. Too tight and they bow the pins and I guess are in danger of breaking at the corners of the pins.

I've made my board three times so I'm getting quite good at it now. It is time consuming and tedious though. I thought it would be really easy to make changes - you can, but anything more than a couple of wires and it gets really hard! Make sure you wire up long runs in the right order. Pins 1-2 3-4 5-6 and then 2-3 4-5. See Garth's primer.

Would I do wire wrap again? I'm glad I did it. But no, I would spend the time to make a PCB. Wire wrap is expensive too.

Congratulation on getting your board to work!

Interesting observation about Alliance chip AS6C62256 as the possible root cause of your earlier problem which okwatts had also shared similar experience. I had used Alliance's AS6c1008 RAM thinking it is similar technology as AS6C62256 and AS6C1008 did work fine. So I'll order some AS6C62256 and see whether it works in my copy of your board design.

Bill

Yes. Exactly. Whilst nothing is proven yet, it is looking increasingly like it might be a problem with Alliance. I wonder if they had a bad batch?
To my eternal shame I didn't pay enough attention to okwatts' post Sorry okwatts!
Thanks for doing an Alliance test plasmo

Thanks Jeff. All good ideas. I'll get some 245s.

Glad you got it working. There will be no problems with those Samsung chips. I'd be very surprised if they are not providing at least 4.3V on their outputs.

The HM62256 RAM is a completely different technology than the AS65C62256. The Alliance technology works from 2.7V to 5.5V the Samsung is from 4.5V to 5.5V. That tells us something is very different about the Alliance chip. The actual memory core is likely deigned to run at the 2.7V - 3.3V range with the 5V being regulated down -- seeing as the specs don't change over the voltage range. It is also only rated for 1mA output source where the Samsung is rated at 4mA.

I suspect if your tester is TTL level tolerant, those AS65C62256 chips will test just fine.

_________________
Bill

BIllO
Thanks for that - but I'm using a KM62256CLP-7L (Samsung) not an HM62256.

I'm looking at the datasheets for it and I can't see much if any difference between it and the Alliance - except that this is a 70ns part and the Alliance is 77ns.

My bad.

However, the KM62256CLP-7L is still a 4.5V to 5.5V design. That's significant as it's not likely relying on a ~3.3 internal voltage to drive the outputs. It does have a 1mA output current though, so in that respect it's similar to the Alliance chip.

In any case, it's working!

_________________
Bill

Hi Adrian,
I received AS6C62256-55PCN from Mouser today. I've also received 74HCT30 from Jameco a few days ago to replace 7430 I used previously. So I believe I now have very similar parts as you do, i.e.
W65C51
W65C02
AS6C62256
AT28C256
74HCT30
74ACT138
74AHC00
2x 1.8432MHz oscillators

Memory diagnostic is loaded in AT28C256 and it works without errors from 5.5V down to 2.2V (the voltage supervisor is disabled). Below 2.2V the test will terminate with "memory test FAILED!" message. Interesting to note at 2.2V the current consumption is about 5mA, rising to 10mA at 2.7V, 15mA at 3.3V, and 44mA at 5.0V.

I let the test run for 10 minutes at 2.2V, 5V, and 5.5V. They all passed.

Bill

PS, it is astonishing that the entire circuit worked down to 2.2V

Indeed, astonishing.
Well, I don't know what is up with my memory. I need to make this memory tester.
Thanks so much for all the time and effort you have put in to this.

After long time of using 6502 emulators (since the many years since I was coding real apple ][ and atari things) I've been enjoying working thru the ben eater videos and digesting Garth's primer etc. Things were fine with the initial ROM-only test programs but as i've started working with more complex things like LCD driver using RAM for storage and stack I've been seeing similar intermittent crash loops where the code works for an indeterminate amount of time (only 1000s of cycles) and then hits BRK in zero'd memory and starts bouncing back and forth on the reset vector (which is also zero'd). I can see happening "live" if I hook up my lcd stack to the high address byte.

occasionally I am lucky and can see the LCD initialize and write startup text (typically only first run after first powerup), but usually (90%) it crashes earlier, often before completing LCD init sequence. the code is very simple and solid in an emulator. was stuck trying to imagine what could be corrupting the stack and causing the crash and eventually discovered this thread. I am using WDC65c02 also and went back to check my parts shopping basket (sourced my own in Canada rather than standard kit), and lo and behold my SRAM chip is ... AS6C62256-55PCN.

I also had little understanding of the 74hc v 74ls distinction when I was starting out; the quad nand gate on the main breadboard is 74HC, but the mux in the clock circuit is SN74LS157 (ignore the specific part number on the labels which were a great discovery for recalling pinouts). That probably explains why my clock output high is close to 2.5V actually?...

I have a bench power supply so will try first just dialling it downwards from 5.0V and see if that helps. Also will add 10K pullups on data-bus. But sounds very much like the same problem that was much discussed here. You can see my layout is super simple and this is still driven by the v slow 555 clock.

It seems like the ultimate solution here was to replace the SRAM with one from a different manufacturer?

Lots of possibilities, but my first question would be about bypass caps - you don't seem to have any on the main board. At least one per chip is a good idea.

Also, more ground wires would probably be a good idea - approximating a grid is a good way to look at it.

But, as your problem is unreliability, and you're on a breadboard, the reliability of connections is another weakness - you need to be sure that every wire and every chip leg is making good contact. If the chips are of an age, then cleaning all four sides of each leg might be worthwhile.

they're hard to see on the top view but there's one at top right and bottom left on the power rails. I can sprinkle more around for sure. all the components were new from supplier within 60d. it definitely seems correlated with this thread since I saw no problems with rom-only code; only when I started using RAM for r/w storage (code still all in rom)

can you elaborate on "more ground wires"? when I have each chip grounded to shared rails which are cross-connected, where can/should I add more? I guess I could also cross-connect rails on the bottom edge. i have done a bunch of continuity testing and haven't found anything. these are the "good" breadboards as recommended also

Good quality breadboard always a good start!

I'd suggest you cross-connect your north-south ground wires two or three times in an east-west direction.

I'd probably also connect at least one more ground between your two main boards: you want a clean clock, and the clock, like everything else, is referenced to ground. So you want a solid ground, in particular the chip driving the clock needs a good (redundant) connection between its ground and the ground of each of the chips receiving the clock.

Of course, I don't know what the actual problem is!

The layout is very neat. I'd be surprised if there was a problem with the layout - assuming the contacts on the breadboards are good enough.

Compare with this:



That's a 6507, 8KB RAM chip (only using 4KB), 32KB EEPROM (only using 4KB), a GAL for glue and a latch for output. Also runs at 2Mhz. Those breadboards are the cheapest I could get from a UK retailer.

So if I can get that big mess of wires to run at 2Mhz then your kHz 555 clock should not be the issue. I think i'd be looking at marginal timings on the RAM side of things. Hard to tell though - have you a 'scope?

Other things to try - try cooling the whole thing down if you're in the northern hemisphere just go outside (at least here is Scotland it's 0°C right now!) Often things that might have marginal timings will work when cooler - every hardware engineer I used to work with back in the 90s had a can of freezer spray handy just for that sort of testing... Also the power supply. Do you trust it? do you have a 2nd meter to check? Try taking it up to 5.2v ... My Ruby 816 board really doesn't like anything < 4.9v for some reason (I think the timing for sending commands to the VIA is marginal, but I don't have good enough test equipment to find out - it works at 5V so that's OK for me).

And try resting your hand on it then gently shaking it - see if it crashes - that's as good indication of a loose wire, or bad breadboard track as any.



-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/