A500 Startup Problems with A501 memory card

[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

[SpeedGeek]

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

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

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

The ROM overlay function should not be a problem as long a your circuit properly ignores the refresh cycle (That's why I mentioned it).

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.

[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

[psxphill]

Failing that, it might be worthwhile finding out exactly where in the A500 ROM the screen is set to white.

White screen makes me think it's 1.2/1.3, I don't remember the later versions changing to white screen.
 
It also might not be trying to make the screen white, the cpu could be crashing and store a stack frame in chip reg space or some bus corruption.
 
Tracing POST issues is hard on Amiga without an eprom programmer.

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

[Oldsmobile_Mike]

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!

[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