Re: Sudoku puzzle solver for Apple II

["BLuRry" <brendan.robert@gmail.com>]

> What's the point of having a program for a relatively new game for
> a computer that hasn't been made in almost twenty years, but then
> you are assuming the most interest will be in running it on an emulator?

A program is a program...  I write lots of programs that run within a
emulator for a non-existant machine and make good money doing it. ;-)
Applewin + soduku < 1mb of download.  This is still within the realm of
feasibility when you look at how big most games are these days.

> At that point, you aren't talking about some functionality of an old
> computer, you are doing it for no good reason.

Is there ever any "good" reason for playing games?  I do crazy things
with apple //'s because, well, I can.  And because I was frustrated I
couldn't at an earlier age in life when I had a real //.  I'm sure that
others have their own reasons that equally valid.  ;-)

> And once you move away from emulators, you do start limiting the
> computers that can run the program when you use a 65C02.

Well, kind of.  It's easier to find apple //e's and apple //c's on
ebay, and altogether there were more of those produced than older ]['s.
 I agree for the purpose of total nostalgia that you would want
complete portability (which is why I rewrote a2gameserver to support
old ][ computers as well) but ultimately it is harder to find an older,
non 65c02 or 65816 based apple computer than a legacy 6502 machine.

>  In other words, you may be limiting who can run this program on an actual Apple II.

I agree that one should be sensitive to that if there was tangible
penalty for limiting the audience.  Such as, if this were a commercial
product being sold.  But for free, I'll take what I can get!  :-)

> But the question still remains, why is it so important to use
> the few instructions that are unique to the 65C02?  They may be nice
> additions, but lots of people survived without them.

I think that the extended opcodes were used in developing the algorithm
to make it as efficient as possible.  MJ Mahon's page has a pretty
awesome amount of detail around how this thing evolved  TSB was one of
the opcodes used at some point, of which there is no easy equivilant
without storing the accumulator somewhere, loading a value, performing
the bit operations, etc...  Would be pretty messy in 6502, and
definately less optimal.  There are also a lot of table lookups, which
may have been optimized with the extra opcodes (I'm guessing -- I
haven't read thru all the source though it is fascinating work)