A500 Startup Problems with A501 memory card

[kamiga]

Some of you might know that I'm designing (designed?) a new A501 replacement memory card using SRAM instead of DRAM.

I have some custom logic that glues the RAS/CASs to the CE of the SRAM chip.

The prototype PCB has been produced, and I've done literally billions(!) of test-accesses using both my own assembly routines, and normal off-the-shelf memory software available from aminet.  These tests all pass without error! (which I'm pretty happy about)

The one issue that remains is that on startup, the amiga hangs on a WHITE screen.  Occasionally(say, 1 in 5 cold starts), the amiga boots fine, recognizes the new memory card, and all is kosher.

If I temporarily disable the memory card, boot, re-enable the card, use the "addmem" command, then everything is also kosher.

Now I've looked at the descriptions of the POST, and even looked at the EXEC disassembly that's available online.  Nothing jumps out at me --- normal accesses to the few locations (slightly under every 256k block during detection phase) should function fine.  I've provably tested that reads/writes to these exact locations pass with flying colors.

I'm doing proper filtering on the +5v power supply(10uf), and decouple at each IC (.1uf).  I doubt it's noise because there's billions of reads/writes done back to back (including interleaving with internal memory reads/writes) without an issue.  I'm aware of the heavy duty factory shielding and other DIY attempts that have required such shielding to function --- but it's my firm belief that a (non-RF) design that requires shielding to operate normally hasn't been designed very well. Now for FCC certification, this is another matter.

As most of you probably know, the internal memory and my new SRAM card share the databus, and if my SRAM is active at ANY TIME the internal memory is, it will cause a conflict, and the 68K will latch corrupted data.  I haven't spent much time yet looking at this, but that's my current plan for detecting the corruption.

My hopes is that the hanging white screen is a tell-tale symptom that someone recognizes.  Note that this isn't simply a failure to recognize the memory --- this is characterized by the machine booting, but no fast ram being inserted into the memory pool. There are also things that can cause a guru crash, but that's not happening either.

Any help would be appreciated.

Thanks

P.S. This project is detailed at http://techtravels.org , and is completely open source/hardware.

[kamiga]

You know, I haven't done this.

I tested this on a Rev 5, serial number 380xxx.

I have limited access to any other A500s -- the other one I have needs cleaned up, and tested before it would be worthwhile to use.

I could use another one or two that were in decent operating order.

Thanks
kamiga

[kamiga]

Southwestern Pennsylvania, USA.

[kamiga]

The one thing you didn't mention anything about was how your custom logic handles a refresh cycle (which it should properly ignore). Also, does your custom logic use multiplexed or non-multiplexed address decoding?

Thanks for the question.

The RAS-only refreshes are handled and ignored.

The board must see RAS1 (pin 38) low and one of the CASs low, and then it will assert /CE to the SRAM.  If CAS goes high (as it does at the end of a cycle), then /CE is disabled.

If RAS1 goes low with no associated CAS (whenever a refresh occurs), /CE isn't brought active.

I've checked the timing (and propagation delays) and watched the amiga's latches in relation to make sure that the card is behaving as it should. (ie made sure data is stable and held for the appropriate durations)

Regarding the addressing, the SRAM uses a full address bus, but the one coming from the amiga is multiplexed.  So, I latch the row address (first 9 bits) upon a falling edge of /RAS1, and latch the second 9 bits on a falling edge of either CAS.

I know I glossed over this earlier.  Don't forget I've done billions of error free memory accesses in a row without even a single error.  

Thanks

[kamiga]

If this problem is only happening during cold boot as you say, it may be an issue with startup time of the SRAM.  All of these devices have a specified time between when power is first applied and the device is ready for use.  See what the SRAM datasheet says.  It may be that the Amiga chip memory write/read tests are in progress just as the SRAM is entering a ready to use state.

Thanks much for replying. I definitely value your input.

It was a good idea to check the SRAM datasheet[1] for a startup time, but heck if I can find one on there.  It looks like stable voltage on OE(grounded permanently) and CE might be the deciding factor?

I checked the datasheet for the actual SHARP chips used in the amiga, and they are 500us + 8 refresh cycles.

Surely the SRAM would be faster than this?

Last but not least, the RAS-before-CAS time difference is around 180ns+, and so the chip should be ready by the time the CAS triggers my logic to drop /CE.

I've already looked at the propagation delays on my CAS-to-/CE --- there is plenty of access time while CAS is still low to fetch the data. (and for the amiga to latch it)

I've gotta get my logic analyzer hooked up again and start really watching that startup.

Thanks
kamiga

[1] I'm using IS61C25616AS-25TI. Datasheet is here http://www.issi.com/WW/pdf/61-64C25616AL-AS.pdf

[kamiga]

In my experience, memory problems trigger a guru.
 
Do you know if kickstart has disabled the rom at $0 when it dies?
 
You might want to patch a copy of kickstart to output more of an indication where it's up to.

My amiga is hanging on a white screen. Resetting the amiga just brings it back to a white screen.

How can I tell? How would I patch kickstart? Burn a new rom chip? I Don't currently have that capability.

Thanks

[kamiga]

I've got some results but heck if I know exactly what to make of it, yet.

Holding /RESET low (I was using pin 18 on the 68k) and tieing it to ground (I used pin 16 on the 68k) had some positive effect, but nothing super reproducible. It didn't make a huge difference.

I was trying to make it fail, and of course murphy's law kicked in, and it was working nearly 100% of the time!@#  Now I couldn't make it fail any longer.

Long story short is that having the logic analyzer attached to the address leads and ground, and the thing boots 100% of the time.  As soon as I remove the ground, it refuses to boot.  If I replace the ground, but remove the address leads, it also refuses to boot.

If I place all address leads back on the jumpers, and place the ground connection back where I had it, it boots nearly 100% of the time.

I've gotta figure out what's going on.

Thanks Castellen and others for the help

P.S. I've read about logic analyzer probes loading the circuit, and it affecting by increasing or slowing the rise times. I'm using mostly 74ACT logic here, but the amiga is primarily 74LS based.  I swear I've read that the rise times can be too fast, and older logic could have problems with it.

[kamiga]

Have you had a look at any of the data or address lines using a high speed (100MHz+) digital storage scope?

Not yet, but I can do that.  Am I looking for overshooting and ringing? And generally healthy square waves?

Preferably connecting with a high impedance differental probe so that connecting the probe doesn't hide the issue you're looking for.

I don't own any differential probes. I'm pretty sure they are fairly expensive, especially for a hobbyist.  Any idea how much decent ones cost?

Could you post a link to your design schematic?

I'll see what I can do.  The current schematics aren't 100% up to date, given minor problems seen in the prototype.

In comparison, you'll see the A501 has 27 Ohm series resistors to slow edge rates which limits overshoot and ringing.  Does your design include something similar?

Yes, I've included 33-ohm series resistors on the data lines, but not on the address or control lines.

Thanks

[kamiga]

I wasn't aware that Fat Agnus was performing a RAS only refresh. Did you confirm this with your logic analyzer?

Yeah, definitely. Take a look at my main project page where I include logic analyzer traces.

http://www.techtravels.org/amiga/amigablog/?page_id=942

Look at the top diagram.  You can see the RAS only pulses, one for both the internal memory and external memory, with constantly increasing row addresses.

This is Agnus refreshing each row of the DRAMs.

There's no pin-1 refresh available on these chips and I've definitely not seen CAS-before-RAS in any of my work so far.

Since your de-multiplexing the address' then you need to delay your SRAM CE long enough for the SRAM address inputs to be stable.

The setup time for reading appears to be 0ns with the hold time being 3ns.  For writing, the setup time is specified as 0ns and hold time is 0ns.

There was a chance I was asserting CE BEFORE the latch outputs stabilized on the input, so I slowed the gate-logic down by switching from ACT to LS on the chip responsible, and now I'm measuring 9ns timing margin between address stabilization and falling edge of CE.  This should be sufficient given the datasheet.

The normal time it takes to reset a 7 MHz 68000 and then execute some Kickstart code before a Chipmem access should be more than enough time to meet the start-up time requirements of the slowest SRAM.

Yup, my thoughts were that there's plenty of time for the SRAM to come online before it needs to start performing.

Logic probe loading may correct a problem with address' (or data) being stable at latching time. Some low value in-series resistors or high value pull downs may help here but a delay in latch timing may also solve the problem. So you might want to check your SRAM CE timing again.

I'm going to take a look at the lines on a DSO today.  I do have series resistors on the data lines.  I can always delay the /CE more, but I think that if I consistently measure 9ns setup and the actual setup time requirement is 0ns, then I'm probably safe here.

Thanks
kamiga

[kamiga]

I tried it on another good known-working amiga, and it boots up fine without error.

I also managed to check a much larger portion of the memory than I've been able to before, and all of those pass without error as well!

Thanks for the help.

[kamiga]

Also, for what it's worth, I've got to continue to the testing on more amigas.  I have very few data points: it works on one, but not on another.  Not exactly a convincing argument!

[kamiga]

Keep testing, glad you got it working on the one!  It's a bit of a drive but check out the thread on here about our Baltimore/Washington meetup group, if you were ever able to come down I could bring at least my A500 for you to test on (it's pretty heavily expanded, so might make a good test platform).  Good work!

Thanks much OM!

For what it's worth, I've also identified the problems with the first Amiga I had tested with.  I had a test fixture on Agnus, and while I wasn't using it, it definitely affected something.

Here's my associated blog post about it.

http://www.techtravels.org/amiga/amigablog/?p=1251

If it was well attended, Baltimore isn't too far for me to come now and again. Let me know the next time the meetup is happening.

Thanks