It may have been a speed problem (Fluke pods supposedly have "the
fastest version of processor available" which, for the 6502 would be the
6502B which would give the RAM more time), or it could be an addressing
problem the Fluke didn't catch but the game did.
Chris Loggans wrote:
>Thanks to David Fish for sending me the data sheet on
>the SCM21C14-4 RAM. Unfortunately, that didn't
>provide the smoking gun I was hoping for. Maybe
>someone here could provide a little more insight into
>the problem I was having.
>
>Problem: Asteroids Deluxe board. Reporting a bad
>program RAM in self test. When tested with a Fluke
>9100, it tested fine. Swapped out said RAM and the
>board now works. The only conclusion that I could
>draw from this was that the RAM was too slow for this
>application. Unfortunately, from the data sheet that
>David sent, it shows that the RAM was a -200 ns part,
>which should be more than sufficient for this
>application.
>
>Any thoughts on why this particular RAM wouldn't work
>on an Asteroids Deluxe board? The only thing that
>caught my attention on the data sheet was a statement
>that says: "For NMOS 2114 replacement applications,
>note the timing differences for /CE; where /CE access
>is required to be faster than address access, use the
>SCM2114AL." However, I don't think this would apply
>to the Ast Dlx board since the address lines are
>already stable before the /CE is triggered (by the
>address lines). I'm stummped.
>
>Thanks,
>-Chris
>
>
>
---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to vectorlist-owner@synthcom.com.
Received on Sat Aug 24 13:53:26 2002
This archive was generated by hypermail 2.1.8 : Fri Aug 01 2003 - 00:33:38 EDT