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

Re: 6502 illegal opcodes questions

mdj wrote:

Michael J. Mahon wrote:



And, intrestingly, this also returns us to another earlier theme of this
thread--how widespread use of undocumented features can create a barrier
to the creation of new, improved implementations.

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.



Yeah - I used to think the best approach would've been an additional
softswitch and an extra ROM chip, providing absolute compatibility with
the old AutoStart ROM. Considering the cost of manufacture of the IIe,
it would've been a simpler solution.

That said, the engineers that wrote the IIc and enhanced IIe ROMS (I'm
not much of a fan of the original IIe ROM) did a fantastic job.


I agree--it's remarkable how much original behavior they preserved
while making some really fundamental improvements.


The only real issue for me was a hardware issue, in that the IIe and
IIc had a feature that would reenable the ROM on reset, which annoyed
me a great deal. I know it was necessary to implement the warm boot,
but it would have been nice if that hardware feature only worked while
PB0 was active.


I expect the issue was deference to copy protection.  They had to keep
control of the RESET vector to ensure that it was at least "hard" to
break out of a game with all its memory intact.

This did interfere with some straightforward approaches to user-friendly
systems, however.


(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...)



I never really did understand why they licensed a new BASIC from
Microsoft instead of expanding Integer to include the missing features.


It's clear that Woz had considered FP, since he had already written the
routines.

It was probably a case of time pressure, the fact that realistically
only Woz could make such a modification to Integer BASIC, and he was
busy with other needed improvements (like Disk ][).  Couple that
pressure with the _de facto_ success of Microsoft BASIC in the
marketplace and things shake out the way they did.


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.  ;-)



The API based approach used in the IIgs was quite nice, particularly
since it allowed the OS to patch broken ROM code at boot time, although
this in itself caused problems. But then only if one ignored the
explicit directions of Apple to NOT jump to absolute locations in ROM.

But then there were applications that had to be modified to run on
ROM03 IIgs's. Some people never learn ....


In fact, some people prided themselves in programming "to the metal"...

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