Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <GfqdnShMo7JOFRnZnZ2dnUVZ_tKdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Paul Schlyter wrote:
>> In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
>> mdj <mdj.mdj@gmail.com> wrote:
>> 
>> 
>>>Paul Schlyter wrote:
>>>
>>>
>>>>I fully agree with that!  The API is the specification, not the
>>>>implementation.  There might be some parts of the library which
>>>>can be called by outside code but wasn't intended to be called in
>>>>that way - they're not part of the API, even though they're part of
>>>>the library!
>>>
>>>Of course, if you use features of a library that aren't part of it's
>>>documented interface you'll eventually be cursed by almost everybody.
>>>
>>>Hey, we're almost back on topic, considering this was supposed to be
>>>about 'undocumented opcodes' :-) Of course, my feelings on using
>>>undocumented library calls is much the same as my feelings on
>>>undocumented opcodes. They are very similar problems.
>> 
>> In the Apple II world we had other similar situations: calling Monitor
>> ROM routines at some fixed address.  Or calling routines in the Applesoft
>> Basic ROM's.
> 
> 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.
> 
> (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.  ;-)
> 
> -michael

IBM learnt from these mistakes by providing entry points to their ROM
BIOS in another way: instead of using fixed addresses, they reserved
16 of the 256 possible interrupts as documented entry points for the
ROM BIOS.  Early PC's came with as much technical documentation as
the Apple II did, including full schematics and assembly source code
listing of the ROM BIOS.

Using soft interrupts as entry points on the Apple II would have been
infeasible -- but Apple could have used a JMP table instead, positioned
near the beginning or the end of the ROM address space.  CP/M used that
method for entry points to its BIOS: a series of JMP operations at the
very beginning of the memory block used by the CP/M BIOS.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/