6502 code

[dwight]

I'm not that much into learning how to use an emulator.

I'll admit for something like this it might be fine but I find

that most are not well written for things like I/O connections,

timed events or random events.

Sometimes that is needed.

I have three volunteers so far. That should be fine.

Dwight


________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Fred Cisin <cisin at xenosoft.com>
Sent: Tuesday, December 13, 2016 9:21:04 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: 6502 code

>>   If you have a modern system, you could always download a 6502
>> emulator and test it on that.  Such a tactic wasn't even unheard of in
>> the day---if I recall correctly, that's how Gates & Co. tested their
>> first BASIC---on an emulated 8080.

On Tue, 13 Dec 2016, drlegendre . wrote:
> I was wondering the same, but perhaps he needs physical hardware for some
> specific purposes, like timing and so forth?

Creating the code, certainly.

But TESTING must be done on the real thing!

Even bug for bug emulation is never certain.

In XenoSoft, I often used faster clones for writing code, but always
tested on REAL IBM hardware.

One of the problems with Microsoft software has traditionally been that
they developed their exception handlers by simulating the conditions, but
did NOT test on actual flaky hardware.  Such as the 64K DMA boundary
isssue that caused FORMAT to fail with certain combinations of device
drivers loaded.  (FORMAT would consistently fail in track 0, but removing
or adding ANY device driver would fix it!)
Or the gross mismanagement of testing that created the SMARTDRV debacle!
A disk write error in Windoze 3.10 installation crashed the
installation and the machine.  And any disk write error was unrecoverable
data loss with write cacheing!   They had to do FREE "stepup"/"update"
from DOS 6.00 to DOS 6.2x because of it, and irreparably damaged their
reputation.   It only needed ONE encounter with a disk write error during
the windoze 3.10 installation to find and recognize the problem!
Telephone support of their Beta testers blew it off whenever it was
reported as being "your hardware, not OUR problem", ignoring protestations
that the OS should gracefully report the problem, not lock up.

MOST of Microsoft's faults would have been fixed if they were to have done
their testing with the same level of hardware as what their users had!
"software that is too slow is YOUR fault for not upgrading your hardware
in the last six months!"


Cross development is wonderful.  But testing MUST be done on exactly the
same hardware and software environment as the users!


Having software work on the real thing but fail on clones (XenoCopy
1.000 aka "XenoPhobe : The Acid Test"), is embarrassing.  But working on
clones but failing on the real thing is inexcusable!


--
Grumpy Ol' Fred                  cisin at xenosoft.com