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.