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 692f96409d why it was
in different order.
This patch provides a temporary fix for the issue where the fgets()
function did not use the target-specific newline character to
decide if it has reached the end of the line. It defaulted to the
value $0a, which is the newline character on only some targets.
The Atari, for example, has newline character $9b instead.
This patch is ugly, because the ca65 assembler that is used for
fgets doesn't currently accept C-type character escape sequences
as values. Ideally we'd be able to write:
cmp #'\n'
And this would end up being translated to a compare-immediate
to the target-specific newline character.
Since that is impossible, this patch substitutes the equivalent,
but ugly, code:
.byte $c9, "\n"
This works because $c9 is the opcode for cmp #imm, and the "\n"
string /is/ translated to the platform-specific newline character,
at least when the 'string_escapes' feature is enabled.
- When the underlying clock_gettime function returned an error, the value
returned via *timep was wrong.
- Reduced code size by 7 bytes.
- Don't suck in ldeaxi.
