aman@xroads.UUCP (Chris Minshall) (05/07/89)
I am going to write an Atari ST emulator for the Amiga. I have never written
a hardware emulator before and have been "brain-storming" as to how to go
about accomplishing the task. I am NOT a novice or intermediate programmer
but rather consider myself a semi-pro! So, I am wondering if anyone out
there has written hardware emulators and could give me some tips as to where
to begin. I own both an Amiga 1000 and Atari 1040ST. I am debateing as to
whether or not I will incorporate a hardware device for the rom chips (ala
the macintosh emulators available on both the ST and Amiga) or to take a copy
of the TOS roms from the ST and make it internal to the emulator program. I
am wondering how to go about the actual emulation of some of the "special"
chips inside the ST. Specifically, how to write an disk driver for reading
ST disks and emulation of the video controller, dma chip, disk controller?
Then, how to incorporate the emulation of those chips (or should I say the
various registers within the chips?) into the execution of an application
running on the emulator (i.e. trapping an ST application that tries to read
or write to a memory location that one of the special chips is mapped to and
re-routing the application to the proper emulation of that register)? Well,
I hope there is enough software engineers out there that might be able to
help me out on this. I don't really intend to ever market this sucker
commercially (unless someone offers to buy it!) but rather to offer it in the
"shareware" variety! Please, anyone who can help me, please leave me some
mail!!! Thanks.
Chris Minshall
--
\ / C r o s s r o a d s C o m m u n i c a t i o n s
/\ (602) 941-2005 300|1200 Baud 24 hrs/day
/ \ hplabs!hp-sdd!crash!xroads!amanmp1u+@andrew.cmu.edu (Michael Portuesi) (05/08/89)
aman@xroads.UUCP (Chris Minshall) writes: > I am going to write an Atari ST emulator for the Amiga. Why? Seriously, what does the Atari ST have that the Amiga doesn't? As an academic exercise, I could see a reason for doing it. But there are really a lot more productive things you could be doing with either your Amiga or your Atari. -- Michael Portuesi * Information Technology Center * Carnegie Mellon University INTERNET: mp1u+@andrew.cmu.edu * BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ MAIL: Carnegie Mellon University, P.O. Box 259, Pittsburgh, PA 15213
kudla@pawl.rpi.edu (Robert J. Kudla) (05/08/89)
In article <0YN9Vay00VsfE5s3Mb@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: aman@xroads.UUCP (Chris Minshall) writes: > I am going to write an Atari ST emulator for the Amiga. Why? Purely one-upsmanship. The Atari-SuperToy people have been saying they're going to have an Amiga emulator Real Soon Now for the past few years; why not do them one better and actually do it? And to be honest, I'd like to be compatible with every computer with >2% of America's market share. I've got Amiga, my roomates have PC and Atari 8-Bit, one of these days I'll buy another 64 or 128, and I want a Macintoaster II, so why not a SuperToy? Ever seeking bigger and better toys.... -- Robert Jude Kudla <kudla@pawl.rpi.edu> <kudla@acm.rpi.edu> <fw3s@RPITSMTS> Pi-Rho America \\ /// "Shooting stars never stop, 2346 15th St. \\ /// even when they reach the top." Troy, NY 12180 /X\ \\\/// keywords: mike oldfield yes u2 r.e.m. new order (518)271-8624 // \\ \XX/ steely dan f.g.t.h. kate bush .....and even Rush
peter@sugar.hackercorp.com (Peter da Silva) (05/08/89)
In article <0YN9Vay00VsfE5s3Mb@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > aman@xroads.UUCP (Chris Minshall) writes: > > I am going to write an Atari ST emulator for the Amiga. > Why? Because it's possible, and the opposite excersise isn't? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
marks@mgse.UUCP (Mark Seiffert) (05/08/89)
In article <0YN9Vay00VsfE5s3Mb@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > aman@xroads.UUCP (Chris Minshall) writes: > > I am going to write an Atari ST emulator for the Amiga. > > Why? > > > Seriously, what does the Atari ST have that the Amiga doesn't? Bugs, tons of them, I saw a Atari magazine that noted doing some simple math in basic would result in several cherries. what ever i do on my ST will cause the system to crash, the Basic interpreter is really bad. After so long i just stopped using it, and put it back in the box. I have tree 8-bit Atari computers, And like a fool, i assumed since Atari's other computers were good the ST would be too. Anyone looking for an Atari 520ST with mono and color monitors and a external disk drive make an offer. I need some cash so i can get an Amiga.
wbralick@afit-ab.arpa (Will Bralick) (05/11/89)
In article <0YN9Vay00VsfE5s3Mb@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: )aman@xroads.UUCP (Chris Minshall) writes: )> I am going to write an Atari ST emulator for the Amiga. ) )Why? ) )Seriously, what does the Atari ST have that the Amiga doesn't? ChessBase (tm)!
rminnich@super.ORG (Ronald G Minnich) (05/16/89)
In article <KUDLA.89May7204259@pawl13.pawl.rpi.edu> kudla@pawl.rpi.edu (Robert J. Kudla) writes: >In article <0YN9Vay00VsfE5s3Mb@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > aman@xroads.UUCP (Chris Minshall) writes: > > I am going to write an Atari ST emulator for the Amiga. > Why? >Purely one-upsmanship. The Atari-SuperToy people have been saying Look, why not skip the one-upsmanship and do us suffering amiga hackers a giant favor: port the stdwin package to the amiga. Then i could write simple programs for my amiga that used windows and menus and all that good stuff and that in addition could be recompiled on my sun and use all the same menus and windows and such. Boy, that would be nice. I just don't have the spare cycles to write nice window/menu stuff that i know will run ONLY on my amiga; it just is not worth the effort. If i knew the program would run on the Sun too, well, that would be a whole new ball game ... And stdwin looks easy, but I have not yet had the time ... interested, anybody???? ron
chen@.ucalgary.ca (Lawrence Chen) (05/17/89)
In article <9195@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes: >Look, why not skip the one-upsmanship and do us suffering >amiga hackers a giant favor: port the stdwin package to the amiga. >Then i could write simple programs for my amiga that used >windows and menus and all that good stuff and that in addition >could be recompiled on my sun and use all the same menus and windows >and such. Boy, that would be nice. > That sounds very much like the Eplot library that we have here....The library is here on our Suns....and is available for the Amiga. Its so programs written on the Sun can also be used on the Amiga, of course we use our Amigas here as graphics terminals on the SUN [we use Eterm]. Eplot is also available on IBM's...and I believe there are versions for the Mac and the ST. I don't know about availability outside of the Electrical Engineering Department at the University of Calgary, but you could try contacting Dr. M. Smith. > I just don't have the spare cycles to write nice window/menu stuff >that i know will run ONLY on my amiga; it just is not worth the >effort. If i knew the program would run on the Sun too, well, that >would be a whole new ball game ... >And stdwin looks easy, but I have not yet had the time ... >interested, anybody???? > What is stdwin like? What are the specs on it...like how would it compare to Eplot. >ron LKC
deven@rpi.edu (Deven Corzine) (05/18/89)
In article <9195@super.ORG> rminnich@super.ORG (Ronald G Minnich) writes:
Look, why not skip the one-upsmanship and do us suffering
amiga hackers a giant favor: port the stdwin package to the amiga.
[...]
I've seen mention of this stdwin package a couple times on the net,
but not elsewhere. It takes quite a bit more information than that to
port it. How about emailing me specs or directions to find same?
interested, anybody????
interested, sure. no promises.
Deven
--
shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America
deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.thad@cup.portal.com (Thad P Floryan) (05/22/89)
Re: the questions about where to get the STDWIN software ...
I regularly uucp stuff from osu-cis, and found this in their listing of
available "goodstuff" (they also have all the GNU goodies and what appears
to be ALL of the Usenet archives).
If you need uucp info (e.g. an L.sys or Systems entry), lemme know; from the
header (below) it appears the material is also FTP'able from gatekeeper.dec.com.
Of "interest" is the fact the STDWIN interacts/interfaces/whatever with X11
and also exists on the Atari, IBM, and other systems (from the file names).
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
------------------------
Included listing follows:
STDWIN
------
Standard window interface for different systems.
Source is gatekeeper.dec.com:pub/stdwin/* as of 29 Jul.
Files are ~/stdwin/
ABOUT.Z 7,426
README.Z 1,395
alfa.tar.Z 28,322
any.tar.Z 91,791
atari.tar.Z 30,977
bed.tar.Z 13,970
doc.old.Z 20,648
dpv.tar.Z 29,598
mac.tar.Z 38,141
man.tar.Z 26,115
mg1.tar.Z 49,747
miniedit.tar.Z 21,561
msdos.tar.Z 18,110
qview.tar.Z 12,690
report.ms.Z 22,875
termcap.tar.Z 22,492
x11.tar.Z 50,268new@udel.EDU (Darren New) (05/23/89)
In article <18653@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
#>Re: the questions about where to get the STDWIN software ...
#>... from the
#>header (below) it appears the material is also FTP'able from gatekeeper.dec.com.
#>STDWIN
#>Standard window interface for different systems.
#>Source is gatekeeper.dec.com:pub/stdwin/* as of 29 Jul.
#>Files are ~/stdwin/
Not any more, they aren't. I've been unable to find them on any
FTP site that has come thru here since I asked. I don't think
we have UUCP access here, so setting that up to get STDWIN would be
a real headache. Maybe somebody could mail them or post them to
Bob Page. If somebody mails them to me, we have (at louie.udel.edu)
an anonymous FTP site and I would see that they wind up there.
This sounds like a great thing for someone to port. -- Darrenrminnich@super.ORG (Ronald G Minnich) (05/23/89)
In article <15986@louie.udel.EDU> new@udel.EDU (Darren New) writes: >a real headache. Maybe somebody could mail them or post them to >Bob Page. If somebody mails them to me, we have (at louie.udel.edu) >an anonymous FTP site and I would see that they wind up there. >This sounds like a great thing for someone to port. -- Darren Ok, Darren, here you go. In the public ftp site at louie.udel.edu there is now a directory called stdwin, and in that directory are the stdwin sources. The first one to get is alfa.tar, but get them all for your viewing pleasure. Make your own stdwin directory, put the tar files in there, and unpack them. My guess when i looked at it was that the mac source would be the easiest to port. You are allowed to disagree :-) Ah, the priveledges of remote grad-student-dome ! So, for all you would-be stdwin porters, that number again: louie.udel.edu 192.5.39.3 anon. ftp, cd pub/stdwin, mget * Have fun! ron P.S. make sure you have room ... -rw-r--r-- 1 rminnich 71680 Nov 17 1988 alfa.tar -rw-r--r-- 1 rminnich 245760 Nov 8 1988 any.tar -rw-r--r-- 1 rminnich 40960 Nov 17 1988 bed.tar -rw-r--r-- 1 rminnich 71680 Nov 17 1988 dpv.tar -rw-r--r-- 1 rminnich 92160 Nov 17 1988 mac.tar -rw-r--r-- 1 rminnich 61440 Nov 8 1988 man.tar -rw-r--r-- 1 rminnich 51200 Nov 17 1988 miniedit.tar -rw-r--r-- 1 rminnich 30720 Nov 17 1988 qview.tar -rw-r--r-- 1 rminnich 51200 Nov 17 1988 termcap.tar -rw-r--r-- 1 rminnich 122880 Nov 17 1988 x11.tar
thad@cup.portal.com (Thad P Floryan) (05/24/89)
Since there appears to be a lot of interest surrounding STDWIN, and since
no-one's posted any details as to the nature of STDWIN, I uucp'd the stuff
from osu-cis.
The directory listing and contents of the ABOUT and README files are at the
end of this posting.
The material appears interesting and the code is "clean"; enjoy!
If you wanna get the stuff from osu-cis (Ohio State University), following
is the {L.sys | Systems} entry and following that are the two uucp commands
to get you started.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
--------------------
The osu-cis extract from my /usr/lib/uucp file is (several lines are l-o-n-g):
# osu-cis GNU stuff, etc.
#
# Micom switch 2400 baud
#
osu-cis Any tty000 9600 16142923124 "" \r\c Name? osu-cis GO \d\r\d\r\d\r in:--in:--in: Uanon
#
# use either the above or the below; the above works on MY system, the below
# is what's posted by Bob Sutterfield and Karl Kleinpaste (of osu-cis)
#
#osu-cis Any tty000 9600 16142923124 "" \r\c Name? osu-cis nected \c GO \d\r\d\r\d\r in:--in:--in: Uanon
The "official" L.sys or Systems file entry is:
#
# Micom switch 2400 bps
#
osu-cis Any ACU 2400 1-614-292-3124 "" \r\c Name? osu-cis nected \c GO \d\r\d\r\d\r in:--in:--in: Uanon
#
# Micom switch 1200 bps
#
osu-cis Any ACU 1200 1-614-292-3112 "" \r\c Name? osu-cis nected \c GO \d\r\d\r\d\r in:--in:--in: Uanon
When you're ready, issue the following to get the indices:
uucp -m osu-cis!~/GNU.how-to-get ~/osu-cis/
uucp -m osu-cis!~/ls-lR.Z ~/osu-cis/
--------------------
And the files that automagically appeared on one of my systems are:
ksh 1/11132> ls -l /usr/spool/uucppublic/osu-cis/stdwin
total 959
-rw-rw-rw- 1 uucp users 7426 May 22 02:39 ABOUT.Z
-rw-rw-rw- 1 uucp users 1395 May 22 02:39 README.Z
-rw-rw-rw- 1 uucp users 28322 May 22 02:41 alfa.tar.Z
-rw-rw-rw- 1 uucp users 91791 May 22 02:48 any.tar.Z
-rw-rw-rw- 1 uucp users 30977 May 22 02:51 atari.tar.Z
-rw-rw-rw- 1 uucp users 13970 May 22 02:52 bed.tar.Z
-rw-rw-rw- 1 uucp users 20648 May 22 02:53 doc.old.Z
-rw-rw-rw- 1 uucp users 29598 May 22 02:56 dpv.tar.Z
-rw-rw-rw- 1 uucp users 38141 May 22 02:59 mac.tar.Z
-rw-rw-rw- 1 uucp users 26115 May 22 03:01 man.tar.Z
-rw-rw-rw- 1 uucp users 49747 May 22 03:05 mg1.tar.Z
-rw-rw-rw- 1 uucp users 21561 May 22 03:06 miniedit.tar.Z
-rw-rw-rw- 1 uucp users 18110 May 22 03:08 msdos.tar.Z
-rw-rw-rw- 1 uucp users 12690 May 22 03:09 qview.tar.Z
-rw-rw-rw- 1 uucp users 22875 May 22 03:11 report.ms.Z
-rw-rw-rw- 1 uucp users 22492 May 22 03:13 termcap.tar.Z
-rw-rw-rw- 1 uucp users 50268 May 22 03:17 x11.tar.Z
ksh 1/11132>
ksh 1/11132> zcat /usr/spool/uucppublic/osu-cis/stdwin/README.Z
[Last modified on Fri Jul 29 17:24:20 PDT 1988 by gvr]
This directory contains the STDWIN distribution.
The source to STDWIN is copyrighted 1988 by Stichting Mathematisch
Centrum, Amsterdam. STDWIN is available for noncommercial use only,
free of charge, and with no guarantees. It can be freely used and
distributed provided these restrictions are honoured.
The following files will eventually find their way to this directory:
README this file
ABOUT what is STDWIN and how do I get it
report.ms source to the CWI report (ditroff -ms)
doc.old some relevant (but unfortunately somewhat outdated)
programmer's documentation (plain ASCII text)
man.tar directory with some man pages (incomplete)
any.tar source directories shared by all versions
alfa.tar source directories shared by the Unix termcap and MS-DOS versions
termcap.tar source directories relevant to the Unix termcap version
msdos.tar source directories relevant to the MS-DOS version
x11.tar source directory relevant to the X11R2 version
mg1.tar source directory relevant to the Whitechapel MG-1 version (old!)
mac.tar source directory relevant to the Macintosh version
atari.tar source directory relevant to the Atart-ST version
dpv.tar source directory for the ditroff previewer application
qview.tar source directory for the line printer queue view application
bed.tar source directory for the bitmap editor application
miniedit.tar source directory for the mini editor application
To get a complete implementation for any one target system, retrieve
the any.tar and <system>.tar files and untar them in a freshly created
directory (this will create several subdirectories), e.g. with the
command:
tar xf any.tar
Then follow the steps of configuration and compilation mentioned in
the file README (found in any.tar). Some test programs are found
in the subdirectory test (also on any.tar).
Note that most long files will actually be found with a .Z
suffix, meaning they have been compressed with BSD's compress(1)
program. Use binary file transfer mode when fetching such files,
and use uncompress(1) to get the original file. You can combine this
with the tar step, e.g.:
uncompress any.tar.Z | tar xf -
If you have any problems or requests, please mail to gvr@src.dec.com.
ksh 1/11132>
ksh 1/11132>
ksh 1/11132> zcat /usr/spool/uucppublic/osu-cis/stdwin/ABOUT.Z
[Last modified on Sat Jul 30 18:04:08 PDT 1988 by gvr]
1. Target systems
STDWIN is aimed at C programs. It consists of a few header files (of
which only one is visible to the user) and a library. In most cases
some system-provided libraries must also be used in the linking phase.
Currently, full STDWIN is available for the following environments:
(Note that in all cases the code is in beta test state; there may be
bugs, functionality may change slightly in the future and new
functionality may be added, but the basic framework isn't going to
change much.)
* X version 11 release 2
* Apple Macintosh using either LightspeedC (2.15) or MPW C (2.02)
* Atari ST using Mark Williams C (2.1)
* Whitechapel MG-1 running an old version of 4.2 BSD
You may volunteer to create a version for your favourite system, or to
port it to your favourite C compiler for one of the mentioned micros.
A subset emulating most of STDWIN's functionality on an alphanumeric
display (this excludes line drawing but includes windows, menus, text
editing etc.) is available for:
* Any decent Unix that has termcap (tested with 4.{2,3} BSD)
* MS-DOS using the Microsoft C compiler (4.0)
2. Getting the full scoop
I have written a paper about STDWIN which has been published as a
CWI report (Guido van Rossum: STDWIN -- A Standard Window System
Interface. Centre for Mathematics and Computer Science, report
CS-R8817. Amsterdam, 1988). You might get a copy mailed to you by
politely asking our secretary, Marja Hegt <marja@cwi.nl>.
You can also get a source version for any or all of the above-mentioned
systems. This is essentially a directory dump of my working version,
until I have the time or get some help to prepare a real distribution.
It is available through anonymous ftp access to gatekeeper.dec.com,
whose IP address is [128.45.9.52]. The directory is pub/stdwin; get
the file README for further instructions. A version of the document
you're currently reading is in the file ABOUT.
Distribution outside the USA is solely by electronic mail. Be prepared
to receive up to half a megabyte (in 50K pieces, tarred/ compressed/
uuencoded/ split). If you're interested, write to:
gvr@src.dec.com
(after October 14, 1988, try once again guido@cwi.nl.)
3. Basic functionality
STDWIN allows multiple "full-function" windows, roughly in Macintosh
style (title bar, grow box, close box, scroll bars). The appearance of
windows is determined by the default of the underlying window manager,
and so are other limitations (e.g., overlapping, maximum size, etc.).
Windows are dynamically created and destroyed by the application, never
directly by the user or the window manager.
STDWIN uses a coordinate system derived from the display's coordinate
system: (0, 0) is top left, with X pointing right and Y pointing down
(these are actually called h and v). Pixel size is that of the display.
There are enquiry functions to ask for the display size in pixels and in
millimeters.
The application is responsible for redrawing the window contents when it
is exposed. This is done by associating a "draw procedure" with each
window, which knows how to draw the entire window's contents. It gets
passed a pointer to the window and the coordinates of the rectangle that
needs to be redrawn, so it can (although it needn't) restrict itself to
that area. STDWIN guarantees that a window's redraw procedure is only
called while the application is waiting for an input event (most
implementations simply turn exposure events into calls to the draw
procedure).
If the application wants to change part of the graphics it is
displaying, this is usually done in a two-phase process: first, STDWIN
is told that a particular area of the screen must be changed; later,
when the application starts waiting for input events again, the draw
procedure is called to update the indicated area (and any other area
that was exposed or damaged in some way).
The application defines the width and height of the area it wants to
draw; this needn't bear any relation to the window or screen size. This
area is called the "document" although you may also think of it as a
virtual window. The actual window generally displays a sub-area of the
document; the window's scroll bars indicate the position of the window
with respect to the document. The application always uses the
coordinates of its document; STDWIN performs the translation to window
or screen coordinates are required by the window manager, and ensures
clipping of all output to the window.
STDWIN is event-based. An application is expected to have a main loop
containing a "get event" call followed by a switch on the event type.
There is no event mask; an application can simply ignore events it isn't
interested in. The most important event types are:
ACTIVATE: A window becomes active (keyboard attached and/or topmost)
CHAR: ASCII character key pressed (except BS, TAB, CR)
COMMAND: special key or function (CLOSE, TAB, RETURN, BS, CANCEL,
arrow keys etc.)
MOUSE: MOUSE DOWN, MOUSE MOVE (only while down), MOUSE UP;
fields in the event record indicate the h, v position,
the number of the button, and the "click number" if the
event is potentially part of a multiple-click sequence
MENU: menu id and item number of a menu selection
SIZE: user has resized the window
TIMER: the window's timer went off; each window has one
programmable timer which can be set to go off at N/10
seconds in the future. When the timer goes off a TIMER
event is returned.
Currently, STDWIN draws text in a single font. The actual font used
depends on the underlying window manager (and can sometimes be
influenced by the application programmer and/or the end user in a
system-dependent manner). The font may be proportionally spaced, and
there are enquiry functions to find out the dimensions of characters and
strings.
There are functions to draw text and simple lines, rectangles and
circles, and ways to erase, shade or invert rectangular areas. There is
no way (yet) to do general bitblt operations, or to influence the pen
shape.
4. Higher level functionality
STDWIN provides a blinking vertical bar which can be used to indicate
the text insertion point, so the application needn't use TIMER events to
do the blinking.
STDWIN provides Macintosh-style menus. Each window has its own set of
menus, although by default all menus apply to all windows. A reasonably
number of menus per window is allowed, each with a reasonable number of
(textual) menu items. Menus can be changed dynamically. Items can be
enabled or disabled, and a 'tick mark' can be placed in front of an
item. Each menu item may have a shortcut character, which, when typed
in combination with some system-defined meta key (e.g., ALT or an ESC-
prefix) selects the menu item (if enabled). Menu selection is done
completely "underwater"; all the application notices are MENU events.
STDWIN has a few simple routines to display Mac-style "dialog boxes",
e.g., to show an error message, or to ask a yes/no question or to ask
for a string to be typed. There is also a predefined function to ask
for a file name, which may allow the user to browse the file system in
some implementations.
STDWIN comes with a package built on top of the basic functionality, to
edit arbitrary blocks of text (cf. Macintosh TEXTEDIT). In the future,
more packages will be provided, e.g., a package to provide a simple file
editor (available now!), a package to display a scrolling list of items,
a package to define a list of arbitrary labeled "buttons", and a package
to simplify the binding of menus to functions somewhat, and a VT100
emulator (available now!).
5. Function definitions
Here follows a slightly edited listing of the <stdwin.h> header file,
which more or less documents all available functions and data
structures. Note that the argument lists are given here as ANSI C
prototypes (untested).
#define bool int
void winit();
void wdone();
void wsetdefwinsize(int width, int height);
void wsetdefwinpos(int h, int v);
#define MENU struct menu
/* The contents of a text attributes struct are disclosed here because
the interface allows the programmer to declare objects of this type.
(I'm not so sure anymore that this is the right thing to do!) */
struct textattr {
short font;
unsigned char size;
unsigned char style;
};
#define TEXTATTR struct textattr
#ifndef WINDOW
struct window {
short tag;
};
#define WINDOW struct window
#endif
WINDOW *wopen(char *title, void drawproc();
void wclose(WINDOW *win);
#define wgettag(win) ((win)->tag)
#define wsettag(win, newtag) ((win)->tag= newtag)
void wsetactive(WINDOW *win);
WINDOW *wgetactive();
void wgetwinsize(WINDOW *win, int *width, int *height);
void wsetdocsize(WINDOW *win, int width, int height);
void wsettitle(WINDOW *win, char *title);
void wsetorigin(WINDOW *win, int h, int v);
void wshow(WINDOW *win, int left, int top, int right, int bottom);
void wchange(WINDOW *win, int left, int top, int right, int bottom);
void wscroll(WINDOW *win, int left, int top, int right, int bottom,
int dh, int dv);
void wfleep();
void wmessage(char *str);
void wperror(char *name);
bool waskstr(char *prompt, char *buf, int buflen);
int waskync(char *question, int dflt);
bool waskfile(char *prompt, char *buf, int buflen, bool new);
void wsetcaret(WINDOW *win, int h, int v);
void wnocaret(WINDOW *win);
void wsettimer(WINDOW *win, int deciseconds);
MENU *wmenucreate(int id, char *title);
void wmenudelete(MENU *mp);
int wmenuadditem(MENU *mp, char *text, char shortcut);
void wmenusetitem(MENU *mp, int i, char *text);
void wmenusetdeflocal(bool local);
void wmenuattach(WINDOW *win, MENU *mp);
void wmenudetach(WINDOW *win, MENU *mp);
/* EVENT STRUCT DEFINITION */
struct event {
int type;
WINDOW *window;
union {
/* case WE_CHAR: */
int character;
/* case WE_COMMAND: */
int command;
/* case WE_MENU: */
struct { int id; int item; } m;
/* case WE_DRAW: */
struct { int left, top, right, bottom; } area;
/* case WE_MOUSE_DOWN, WE_MOUSE_MOVE, WE_MOUSE_UP: */
struct {
int v;
int h;
int clicks;
int button;
int mask;
} where;
} u;
};
#define EVENT struct event
/* Event types */
#define WE_NULL 0 /* (Used internally) */
#define WE_ACTIVATE 1 /* Window became active */
#define WE_CHAR 2 /* Character typed at keyboard */
#define WE_COMMAND 3 /* Special command, function key etc. */
#define WE_MOUSE_DOWN 4 /* Mouse button pressed */
#define WE_MOUSE_MOVE 5 /* Mouse moved with button down */
#define WE_MOUSE_UP 6 /* Mouse button released */
#define WE_MENU 7 /* Menu item selected */
#define WE_SIZE 8 /* Window size changed */
#define WE_MOVE 9 /* (Reserved) */
#define WE_DRAW 10 /* Request to redraw part of window */
#define WE_TIMER 11 /* Window's timer went off */
#define WE_DEACTIVATE 12 /* Window became inactive */
/* Command codes for WE_COMMAND.
Special ways of entering these are usually available,
such as clicking icons, standard menu items or special keys.
Some ASCII keys are also passed back as commands since they
more often than not need special processing. */
#define WC_CLOSE 1 /* Should become a separate event! */
/* The following four are arrow keys */
#define WC_LEFT 2
#define WC_RIGHT 3
#define WC_UP 4
#define WC_DOWN 5
/* ASCII keys */
#define WC_CANCEL 6
#define WC_BACKSPACE 7
#define WC_TAB 8
#define WC_RETURN 9
void wgetevent(EVENT *ep);
void wungetevent(EVENT *ep);
void wupdate(WINDOW *win);
void wbegindrawing(WINDOW *win);
void wenddrawing(WINDOW *win);
void wflush();
void wdrawline(int h1, int v1, int h2, int v2);
void wxorline(int h1, int v1, int h2, int v2);
void wdrawcircle(int h, int v, int radius);
void wdrawelarc(int h, int v, int radh, int radv, int angle1, int angle2);
void wdrawbox(int left, int top, int right, int bottom);
void werase(int left, int top, int right, int bottom);
void wpaint(int left, int top, int right, int bottom);
void winvert(int left, int top, int right, int bottom);
void wshade(int left, int top, int right, int bottom, int percent);
int wdrawtext(int h, int v, char *str, int len);
int wdrawchar(int h, int v, char c);
int wlineheight();
int wtextwidth(char *str, int len);
int wcharwidth(char c);
int wtextbreak(char *str, int len, int width);
void wgettextattr(TEXTATTR *attr);
void wsettextattr(TEXTATTR *attr);
void wgetwintextattr(WINDOW *win, TEXTATTR *attr);
void wsetwintextattr(WINDOW *win, TEXTATTR *attr);
void wsetplain();
void wsethilite();
void wsetinverse();
void wsetitalic();
void wsetbold();
void wsetbolditalic();
void wsetunderline();
/* TEXTEDIT PACKAGE DEFINITIONS */
#define TEXTEDIT struct _textedit
TEXTEDIT *tealloc(WINDOW *win, int left, int top, int width);
TEXTEDIT *tecreate(WINDOW *win,
int left, int top, int right, int bottom);
void tefree(TEXTEDIT *tp);
void tedestroy(TEXTEDIT *tp);
void tedraw(TEXTEDIT *tp);
void tedrawnew(TEXTEDIT *tp, int left, int top, int right, int bottom);
void temove(TEXTEDIT *tp, int left, int top, int width);
void temovenew(TEXTEDIT *tp,
int left, int top, int right, int bottom);
void tesetfocus(TEXTEDIT *tp, int foc1, int foc2);
void tereplace(TEXTEDIT *tp, char *str);
void tesetbuf(TEXTEDIT *tp, char *buf, int buflen);
void tearrow(TEXTEDIT *tp, int code);
void tebackspace(TEXTEDIT *tp);
bool teclicknew(TEXTEDIT *tp, int h, int v, bool extend);
bool tedoubleclick(TEXTEDIT *tp, int h, int v);
bool teevent(TEXTEDIT *tp, EVENT *ep);
#define teclick(tp, h, v) teclicknew(tp, h, v, FALSE)
#define teclickextend(tp, h, v) teclicknew(tp, h, v, TRUE)
char *tegettext(TEXTEDIT *tp);
int tegetlen(TEXTEDIT *tp);
int tegetnlines(TEXTEDIT *tp);
int tegetfoc1(TEXTEDIT *tp);
int tegetfoc2(TEXTEDIT *tp);
int tegetleft(TEXTEDIT *tp);
int tegettop(TEXTEDIT *tp);
int tegetright(TEXTEDIT *tp);
int tegetbottom(TEXTEDIT *tp);
/* Text paragraph drawing functions: */
int wdrawpar(int h, int v, char *text, int width);
/* Returns new v coord. */
int wparheight(char *text, int width);
/* Returns height */
ksh 1/11132>