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

Re: 6502 illegal opcodes questions



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.

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

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