[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple 1 CFFA1 AND FORTH +

On 11/3/2010 4:36 PM, David Schmenk wrote:

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.


The "quick, ship it before we discover it doesn't work" style is a
relatively recent "innovation"--I fondly hope it is short-lived.

Maybe when Moore's "Law" peters out some more, we'll begin to expect
electronics to work for 10-20 years instead of 10-20 months, and
reliable implementations will be more appreciated by the market...


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.


Right.  The astronomical number of configurations in use makes
comprehensive compatibility testing completely impractical these days.


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

;-)



Hardware, software, the only difference is the packaging.


There is (or at least used to be) one other very significant
difference:  hardware/firmware was designed and implemented by
strict, methodical hardware engineers who meticulously designed and
tested hardware/firmware devices of very limited complexity;
while software was designed and implemented by much less formal,
seat-of-the-pants autodidacts who kept changing ridiculously
complex software until it seemed to work.  ;-)

Hardware engineers:  difficulty 4, score 9.
Software engineers:  difficulty 9, score 3.

I never met a hardware engineer who, in response to a particularly
elusive bug, began to suspect errant electrons or quantum fluctuations.
;-)  They are pretty clear that 999 times out of 1000, their logic is
the source of their problem.  (That doesn't mean that very occasionally
something like cosmic ray-induced single-event upsets didn't turn out to be implicated ultimately. ;-) 

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