Re: Apple 1 CFFA1 AND FORTH +

[David Schmenk <dschmenk@gmail.com>]

On Nov 3, 12:59 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> On 11/2/2010 5:39 PM, David Schmenk wrote:
>
>
>
>
>
> > On Nov 2, 4:25 pm, mwillegal<m...@willegal.net>  wrote:
> >> On Nov 2, 12:53 pm, David Schmenk<dschm...@gmail.com>  wrote:
>
> >>> On Nov 2, 4:03 am, mwillegal<m...@willegal.net>  wrote:
>
> >>>> DRAM refresh suspends the CPU clock, so should have no effect on reads
> >>>> or writes on a real Apple 1, Obtronix or Mimeo.
> >>>> I'm heavily engaged in another project at this time, but I'll try this
> >>>> Forth port on a Mimeo, as soon as I get a chance.
> >>>> In the meantime, a while back, I have put up a page with a memory test
> >>>> that could be used to test the memory on any of these systems.
>
> >>>>http://www.willegal.net/appleii/6502mem.htm
>
> >>>> Regards,
> >>>> Mike Willegal
>
> >>> HI Mike-
>
> >>> I did use your memory test on my Obtronix.  It passed (actually it did
> >>> fail once, but ran for a day afterward).  However, I wouldn't put too
> >>> much faith in the test.  It checks to see if the value written is the
> >>> one read back, but there aren't any checks for secondary effects such
> >>> as other memory locations being affected by the one being tested (at
> >>> least that I could find).  I'm not saying that the refresh is
> >>> definitely the culprit.  I have no real diagnostic tools so I'm just
> >>> speculating as I can't think of any other differences in the way the
> >>> CPU, memory, and code interact at this point.  Rich and I went back
> >>> and forth (ha) over the best way to track down the failure.  He wanted
> >>> me to probe the address the CPU was at after it locked up and I wanted
> >>> to run the trace code to see *why* it failed.   The age old hardware
> >>> guy vs software guy debugging argument.  I would love to hear your
> >>> results on the Mimeo.  More data is good.  If it works, save me a
> >>> Mimeo and I'll order one ;-)
>
> >>> Dave...
>
> >> Actually checking that writing one location doesn't affect another
> >> location
> >> is exactly what the address in address tests do.  I believe I pulled
> >> up an address pin on a ram chip  at one point during development
> >> of this test tool to make sure the test would properly find the fault,
> >> which it did.
>
> > OK, good.  I mustn't have looked hard enough.
>
> >> Trying this software out is pretty high on the list of things to do.
> >> I really
> >> don't expect different results from the Obtronix, but maybe I'll be
> >> able
> >> to find root cause of the problem.
>
> > Thanks.  I can't completely rule out a software bug - I've been burned
> > by that before.  As a friend of mine once said: "the logic analyzer
> > doesn't lie" after he tracked down a software bug of mine in an IRQ
> > handler that I swore was hardware.
>
> ;-)
>
> The best rule for *all* programmers is to assume that there are no
> hardware bugs--that ensures the correct level of effort to find the
> software bug(s).
>
> One time in your life it may turn out to actually *be* a hardware
> bug, and when it is, you'll have a story you can tell for the rest
> of your life!  ;-)
>

Uh oh, I must have multiple lives.  Probably more to do with the
nature of hardware I've dealt with.  "Fix it in software!" has been
the answer more times than I care to remember.  Usually, the hardware
failure would be quite obvious i.e. something just plain didn't work.

> Quite seriously, suspecting hardware invites a kind of superstition
> that is an "easy out" for hard-to-find software problems.  In my own
> experience, it has never been a hardware problem--even on a prototype
> processor.  (Oh, there were hardware problems, but I didn't find
> them with *my* programs!)
>

Actually, the phrase "It works on *my* computer." from a developer
used to drive me crazy.  As if their computer was the only one it had
to work on.

> BTW, I knew someone who actually found a hardware problem on a 7094.
> He found that on this particular machine, floating-point multiply
> was not commutative!  It took him a couple of days to get the CEs
> to believe him sufficiently to write test programs to prove it, then
> they found the defective gate and fixed it.
>
>  From that day forward, this math professor always began his FORTRAN
> programs with the statement:
>
>     IF 2.0 * 0.5 .NE. 0.5 * 2.0 THEN STOP
>
> ;-)
>
> -michael
>
> NadaNet 3.1 for Apple II parallel computing!
> Home page:  http://home.comcast.net/~mjmahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."

Hardware, software, the only difference is the packaging.

Dave...