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.
Of course, that won't work full speed with the standard
IRQ-based RX. But that will allow users to setup the port
at this speed without duplicating the setup part of the
code. Up to them to add hooks to disable IRQs and read
directly in a tight asm loop.
Of course, that won't work full speed with the
standard IRQ-based RX. But that will allow users
to setup the port at this speed without duplicating
the setup part of the code. Up to them to add hooks
to disable IRQs and read directly in a tight asm
loop.
Using mliparam at this time could lead to corruption at the
start of the new executed program if BSS is real full and
mliparam is over $BB00.
The fix is to open the file from the loader stub instead of doing
it before the C library shutdown.
The Pascal Firmware Protocol Bytes ID are not enough to differentiate an SSC card from a IIgs serial firmware:
http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.08.html
Loading a2(e).ssc.ser on a IIgs succeeds, then goes to limbo when one tries to use the serial port.
Check first byte on the slot's firmware in addition to the four existing ones, as it's supposed to be $2C (BIT instruction) on an SSC card, and $EF (65C816 SEP instruction) on the IIgs' serial firmware (ROM revisions 0, 1, 3).
