Use a walking out pointer instead of &out[written]. This
simplifies the code by 27 bytes and spares 15% cycles.
Tested with both the unit test and code uncompressing
10kB of data.
Renamed the labels for legibility.
In order to avoid undefined behaviour of programs not aware of 80 column mode, the 80 column firmware deliberately doesn't use CH but OURCH. So in order to be fully interoperable, CONIO needs to do the same. This changes introduces that behavior. So far so good.
But the 80 column firmware can also be active in 40 column mode. This scenario is not detectable with reasonable effort. Therefore the behaviour of CONIO in this scenario is _not_ improved. However, this scenario is supposed to be very uncommon - and a recent update to videomode() makes sure to not activate it anymore ourselves.
Notes:
* If a program wants to be 100% sure to not run in 40 column mode with 80 column firmware active it can call videomode(VIDEOMODE_40COL) to explicitly deactivate a potentially active 80 column firmware. However, this always implicitly clears the screen.
* In 40 column mode (contrast to 80 column mode) the 80 column firmware updates CH to reflect OURCH. So as long as CONIO only reads CH, but doesn't update it, everything works as expected. Interestingly this makes a rather useful scenario of STDIO/CONIO interoperation work: Using STDIO for screen output and CONIO for keyboard input. When cgetc() is called after cursor(1), it has to write to the screen as there's no hardware cursor on the Apple II. Those writes work as expected even in 40 column mode with active 80 column firmware as CH is only read but not written.
Interrupt handlers rather likely access text screen holes. Especially MSLOT is obligatory for every interrupt handler that requires access to an extension ROM ($C800-$CFFE) in order to be able to re-enable the extension ROM that was enabled when the interrupt occured. Those text screen holes only hold valid values in main memory so interrupts must be disabled while the aux memory text screen is mapped.
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.
On a 48k Apple II, the BLTU2 call throws an error,
even when there is nothing to copy in the LC segment.
Add an alternative LC copy, based on memcpy, to an
extra file that the user can link in as with iobuf-0800.
This memcpy-based version allows our programs to run on
Integer ROM apple2. It costs 21 bytes in binary size,
plus memcpy (60 bytes in binary size + RAM use) if it
wasn't already linked in.
The size of the load chunk was calculated incorrectly in exehdr.s
since the INIT segment is no longer being part of the file anymore.
While at it, change atari-cassette.cfg so that order of BSS and INIT
is the same as in the other configs. See 692f96409d4e809d8 why it was
in different order.
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.
This PR is the first 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 first PR extends the sim65 simulator in the following ways:
(1) It provides tracing functionality, i.e., the possibility of printing one line of simulator state information per instruction executed.
(2) It provides a memory mapped "sim65 control" peripheral that allows control of (a) the tracing functionality, and (b) the cpu mode.
(3) It provides command-line options to sim65 to enable the tracing, and to override the CPU mode as specified in the program file header.
More detailed information and some discussion can be found in the discussions with the (now retracted) PRs #2589 and #2590.
This PR provides the technical infrastructure inside the sim65 simulator program itself. Once this PR is accepted, a follow-up PR will be posted that adds C and assembly-language support for the new tracing and peripheral features so they can be easily accessed from the CC65 compiler and the CA65 assembler; some examples; and the documentation for these features. The lack of the latter, in this pull request, will be addressed then.
