1
0
mirror of https://github.com/cc65/cc65.git synced 2024-11-18 00:07:21 +00:00
cc65/include/apple2enh.h

126 lines
4.6 KiB
C
Raw Normal View History

/*****************************************************************************/
/* */
/* apple2enh.h */
/* */
/* enhanced Apple //e system specific definitions */
/* */
/* */
/* */
/* (C) 2004 Oliver Schmidt, <ol.sc@web.de> */
/* */
/* */
/* This software is provided 'as-is', without any expressed or implied */
/* warranty. In no event will the authors be held liable for any damages */
/* arising from the use of this software. */
/* */
/* Permission is granted to anyone to use this software for any purpose, */
/* including commercial applications, and to alter it and redistribute it */
/* freely, subject to the following restrictions: */
/* */
/* 1. The origin of this software must not be misrepresented; you must not */
/* claim that you wrote the original software. If you use this software */
/* in a product, an acknowledgment in the product documentation would be */
/* appreciated but is not required. */
/* 2. Altered source versions must be plainly marked as such, and must not */
/* be misrepresented as being the original software. */
/* 3. This notice may not be removed or altered from any source */
/* distribution. */
/* */
/*****************************************************************************/
#ifndef _APPLE2ENH_H
#define _APPLE2ENH_H
/* Check for errors */
#if !defined(__APPLE2ENH__)
# error This module may only be used when compiling for the enhanced Apple //e!
#endif
#include <apple2.h>
/*****************************************************************************/
/* Data */
/*****************************************************************************/
/* Characters codes */
Made Apple II CONIO more flexible. Originally the Apple II had a 64 char set and used the upper two bits to control inverse and blinking. The Apple //e brought then an alternate char set without blinking but more individual chars. However, it does _not_ contain 128 chars and use the upper bit to control inverse as one would assume. Rather it contains more than 128 chars - the MouseText chars. And because Apple wanted to provide as much backward compatibility as possible with the original char set, the alternate char set has a rather weird layout for chars > 128 with the inverse lowercase chars _not_ at (normal lowercase char + 128). So far the Apple II CONIO implementation mapped chars 128-255 to chars 0-127 (with the exception of \r and \n). It made use of alternate chars > 128 transparently for the user via reverse(1). The user didn't have direct access to the MouseText chars, they were only used interally for things like chline() and cvline(). Now the mapping of chars 128-255 to 0-127 is removed. Using chars > 128 gives the user direct access to the "raw" alternate chars > 128. This especially give the use direct access to the MouseText chars. But this clashes with the exsisting (and still desirable) revers(1) logic. Combining reverse(1) with chars > 128 just doesn't result in anything usable! What motivated this change? When I worked on the VT100 line drawing support for Telnet65 on the Apple //e (not using CONIO at all) I finally understood how MouseText is intended to be used to draw arbitrary grids with just three chars: A special "L" type char, the underscore and a vertical bar at the left side of the char box. I notice that with those chars it is possible to follow the CONIO approach to boxes and grids: Combining chline()/cvline() with special CH_... char constants for edges and intersections. But in order to actually do so I needed to be able to define CH_... constants that when fed into the ordinary cputc() pipeline end up as MouseText chars. The obvious approach was to allow chars > 128 to directly access MouseText chars :-) Now that the native CONIO box/grid approach works I deleted the Apple //e proprietary textframe() function that I added as replacement quite some years ago. Again: Please note that chline()/cvline() and the CH... constants don't work with reverse(1)!
2018-08-19 21:40:50 +00:00
#define CH_DEL 0x7F
#define CH_CURS_UP 0x0B
#define CH_CURS_DOWN 0x0A
#define CH_HLINE 0x5F
#define CH_VLINE 0xDF
#define CH_ULCORNER 0x5F
#define CH_URCORNER 0x20
#define CH_LLCORNER 0xD4
#define CH_LRCORNER 0xDF
#define CH_TTEE 0x5F
#define CH_BTEE 0xD4
#define CH_LTEE 0xD4
#define CH_RTEE 0xDF
#define CH_CROSS 0xD4
/* These are defined to be OpenApple + NumberKey */
#define CH_F1 0xB1
#define CH_F2 0xB2
#define CH_F3 0xB3
#define CH_F4 0xB4
#define CH_F5 0xB5
#define CH_F6 0xB6
#define CH_F7 0xB7
#define CH_F8 0xB8
#define CH_F9 0xB9
#define CH_F10 0xB0
/* Video modes */
Made Apple II CONIO more flexible. Originally the Apple II had a 64 char set and used the upper two bits to control inverse and blinking. The Apple //e brought then an alternate char set without blinking but more individual chars. However, it does _not_ contain 128 chars and use the upper bit to control inverse as one would assume. Rather it contains more than 128 chars - the MouseText chars. And because Apple wanted to provide as much backward compatibility as possible with the original char set, the alternate char set has a rather weird layout for chars > 128 with the inverse lowercase chars _not_ at (normal lowercase char + 128). So far the Apple II CONIO implementation mapped chars 128-255 to chars 0-127 (with the exception of \r and \n). It made use of alternate chars > 128 transparently for the user via reverse(1). The user didn't have direct access to the MouseText chars, they were only used interally for things like chline() and cvline(). Now the mapping of chars 128-255 to 0-127 is removed. Using chars > 128 gives the user direct access to the "raw" alternate chars > 128. This especially give the use direct access to the MouseText chars. But this clashes with the exsisting (and still desirable) revers(1) logic. Combining reverse(1) with chars > 128 just doesn't result in anything usable! What motivated this change? When I worked on the VT100 line drawing support for Telnet65 on the Apple //e (not using CONIO at all) I finally understood how MouseText is intended to be used to draw arbitrary grids with just three chars: A special "L" type char, the underscore and a vertical bar at the left side of the char box. I notice that with those chars it is possible to follow the CONIO approach to boxes and grids: Combining chline()/cvline() with special CH_... char constants for edges and intersections. But in order to actually do so I needed to be able to define CH_... constants that when fed into the ordinary cputc() pipeline end up as MouseText chars. The obvious approach was to allow chars > 128 to directly access MouseText chars :-) Now that the native CONIO box/grid approach works I deleted the Apple //e proprietary textframe() function that I added as replacement quite some years ago. Again: Please note that chline()/cvline() and the CH... constants don't work with reverse(1)!
2018-08-19 21:40:50 +00:00
#define VIDEOMODE_40x24 0x0011
#define VIDEOMODE_80x24 0x0012
#define VIDEOMODE_40COL VIDEOMODE_40x24
#define VIDEOMODE_80COL VIDEOMODE_80x24
/*****************************************************************************/
/* Variables */
/*****************************************************************************/
/* The addresses of the static drivers */
extern void a2e_auxmem_emd[];
extern void a2e_stdjoy_joy[]; /* Referred to by joy_static_stddrv[] */
extern void a2e_stdmou_mou[]; /* Referred to by mouse_static_stddrv[] */
extern void a2e_ssc_ser[];
extern void a2e_hi_tgi[]; /* Referred to by tgi_static_stddrv[] */
extern void a2e_lo_tgi[];
/*****************************************************************************/
/* Code */
/*****************************************************************************/
unsigned __fastcall__ videomode (unsigned mode);
/* Set the video mode, return the old mode. Call with one of the VIDEOMODE_xx
** constants.
*/
void waitvsync (void);
/* Wait for start of next frame */
/* End of apple2enh.h */
#endif