Add a machinetype identifier to help us quickly identify
Apple //e (bit 7) and //e enhanced (bit 6).
Use it in conio functions for 80-columns code instead of
relying entirely on the __APPLE2ENH__ target.
Move videomode() to the apple2 target, and have it return
an error if 80-columns hardware is not available - this
is a lie for now, it is considered available on //e enhanced,
which may not be true, and not available on //e, which
may also be not true. An ulterior patch will make that
check correctly.
Adapt the box/line drawing characters so that one can use
MouseText on the apple2 target if it is available, by
defining DYN_DRAW_BOX. No change by default: MouseText is
considered available on apple2enh and not available on
apple2.
get_tv() will return TV_NTSC or TV_PAL for any Apple II model
with a way of checking vblank. For Apple ][ and ][+ it will
return TV_OTHER and let the user figure it out in another way.
The //e 80 column firmware allows to switch between 80 and 40 clumns without clearing the screen. So far, I made that feature available via videomode(). However thinking about it once more, I don't see a C program making use of it. A C program rather benefits from the consistent behavior of videomode() always clearing the screen.
Apart from that, the (default) 40 column display and the 40 column display with 80 column firmware active, behave differently (CH vs. OURCH) which causes subtile issues. Those issues can be avoid altogether by simply always deactivating the 80 column firmware when switching from 80 column display to 40 column display.
Of course, those issues are also relevant, if the 40 column display with 80 column firmware is already active when the C program starts. However, I have reasons to believe that running the Apple II in that mode was/is very unpopular.
This PR is the second of two PRs that replaces earlier PRs #2589 and #2590. Due to a git branching mishap it was decided to re-partition the new functionality in two sequential PRs that offer self-contained, new functionality to sim65.
The functionality in this second and last PR provides the following things in relation to the new "peripheral" support:
* C support: there is now an include/sim65.h that can be included from C. It provides access to the memory-mapped peripheral addresses.
* Asm support: there is now an asminc/sim65.inc that can be included from assembly. It provides symbolic labels for the memory-mapped peripheral addresses.
Note: the two items above are implemented by adding a "_peripherals" symbol to cfg/sim6502.cfg and cfg/sim65c02.cfg, with the fixed base address of the peripherals memory aperture (0xffc0).
* Updated the sim65 documentation to describe the peripherals in some detail, with examples that show to use the new features from within C.
* Some examples in the new samples/sim5/ directory. These are currently not integrated in the build system (in other words, there's no Makefile there), because I don't know how to do that. I will happily implement that after #2582 is taken care of.
If that is not acceptable, the next best thing will be for somebody else (who understands how the Makefiles are set up) to take care of this.
If that's not going to happen, and we don't want examples that are not properly integrated with the build system, there's always the option of removing these samples from the PR.
