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.
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.
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.
