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

Re: 6502 illegal opcodes questions

Michael wrote:

Michael J. Mahon wrote:


The Apple ROM was not significantly changed until the //e, where much
of the actual code was placed in a bank-switched area.  Much of the F8
region became stubs at documented entry points vectoring to the actual
routines.  Updating the F8 region of the ROM was known to be a minefield
of compatibility issues.

The notion of defining the ROM entry points more architecturally was
not widespread at the time the Apple II was designed, and the impact
of the subsequent loss of control over ROM code became a problem.



This is related to another hobby of mine -- the HP48 calculator (which
in a lot of ways, has the same "Apple" feel.)  It had the same problem,
all though it wasn't as bad, since there became known 'entry points' of
the system ROM; i.e. SYSEVAL on the HP28 which exposed the problem to
the general public.  (You know how curious engineers/geeks are when
something has "undocumented" written all over it.  ;-)

I'll agree that it was not widespread, but it was known. The question
is when?
Woz did work at HP -- when did the calculator people come up with a
solution?  And did Woz know about it?


Woz was at HP in the early days of HP calculators, but before the
programmable handheld days.

Entry point vectors were well-known since the earliest days of
computing, but tended to be used only when their benefits were
seen as justifying the cost of the vector in RAM/ROM.

Woz did not envision the widespread popularity of the Apple II, and
so did not avail himself of such protective techniques.

And, of course, it's not really "protection" if you can address
anywhere in the ROM anyway.  So he just published the entry points
he thought were useful and likely to be preserved, assuming that
fellow enthusiasts would take the information to heart.)


(I've always wondered how much "compatibility issues" and how much
"renegotiation issues" factored into the decision to never update
the Applesoft ROMs to fix bugs...)

Later systems used a combination of less documentation and more
complexity to make calls into the middle of ROM less likely.  Still
not an ideal solution, but one well adapted to the Apple II.  ;-)



It certainly looks like everyone was too busy writing their own code,
since the ROM code wasn't all that usefull.


Have you tried writing 80-column scrolling?  ;-)

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."