uhOpenGame.3p
5.22 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
.TH uhOpenGame 3P local "Silicon Graphics, Inc."
.SH NAME
.upperok
uhOpenGame, uhCloseGame, uhReadGame, uhWriteGame, uhReadRamrom, uhWriteRamrom \- data transfer facilities from/to host and game
.SH SYNOPSIS
.nf
\f3
.Op c
#include <ultrahost.h>
.sp .8v
int uhOpenGame(const char *device);
.sp .8v
int uhReadGame(int fd, void *addr, int nbytes);
.sp .8v
int uhWriteGame(int fd, void *addr, int nbytes);
.sp .8v
int uhReadRamrom(int fd, void *ramrom_addr, void *data, int nbytes);
.sp .8v
int uhWriteRamrom(int fd, void *ramrom_addr, void *data, int nbytes);
.sp .8v
int uhCloseGame(int fd);
.Op
\f1
.fi
.SH DESCRIPTION
These routines allow a host application to set up a communications channel
for the transfer of raw data between the host and the game.
They work in concert with the routines described in
.IR osReadHost (3P)
on the game side.
.PP
The
.I uhOpenGame
routine opens the given
.I device
special file and configures it to listen for game I/O events.
Which device should be opened is dependent on which read and write
calls will be needed. For
.I uhReadGame
and
.I uhWriteGame, uhOpenGame
should open the device
.I /dev/u64_data.
For
.I uhReadRamrom
and
.I uhWriteRamrom, uhOpenGame
should open
.I /dev/u64.
Note that this is a change from previous releases that specified
.I /dev/u64
for all calls.
The file descriptor returned by
.I uhOpenGame
is passed to
.IR uhReadGame ,
.IR uhWriteGame ,
.IR uhReadRamrom ,
.IR uhWriteRamrom ,
and
.IR uhCloseGame ,
presuming the open succeeds.
.PP
The
.I uhReadGame
routine will attempt to read
.I nbytes
of data from the game and copy it to the memory region beginning at
.IR addr .
For correct operation, it should be paired from the game side with a
.I osWriteHost
with
.I exactly
the same number of bytes.
If the read is attempted from the host side before the game has executed
the write, the host process will block. Conversely, if the write is
attempted from the game side before the host has executed a read, the
game thread will block. When both sides have correctly made the
corresponding procedure call, the transfer will take place and the
blocking side will proceed.
.PP
The
.I uhWriteGame
routine will attempt to copy
.I nbytes
of data from the host beginning at
.I addr
to the game.
In this case,
the operation should be paired on the game side with a
.I osReadHost
procedure with the same byte count.
As above,
either the host or game will block until the rendezvous is complete.
.PP
The
.I uhReadRamrom
routine will attempt to copy
.I nbytes
of data from the ramrom memory, begining at
.I ramrom_addr.
The calling program must supply a buffer,
.I data
big enough to hold the requested nbytes.
In previous releases, calls to
.I uhReadRamrom
needed to be paired from the game side with a
.I osAckRamromRead. This is no longer neccessary.
.PP
The
.I uhWriteRamrom
routine will attempt to write
.I nbytes
from
.I data
to the ramrom memory, begining at
.I ramrom_addr.
In previous releases, calls to
.I uhWriteRamrom
needed to be paired from the game side with a
.I osAckRamromWrite. This is no longer neccessary.
.PP
The
.I uhCloseGame
procedure can be used if desired to close the given file descriptor.
.PP
These routines are part of the Ultra 64 host side library
.IR libultrahost.a ,
and thus are available to the application by adding
.I -lultrahost
on the link line.
.SH EXAMPLE
The example on the following page shows how a host application can
initiate the same and establish a connection to transfer data.
This particular sequence will guarantee that no handshaking events will
be lost.
By the time the game sends its first packet of data,
the host device driver is ready to acknowledge it.
Furthermore, the host side application does not attempt to send
data to the game before it has booted.
.bp
.ta 5
.Ex
main(int argc, char **argv) /* Host side code */
{
pid_t pid;
int fd, status;
if ((fd = uhOpenGame("/dev/u64_data")) == -1) {
perror("uhOpenGame");
return(-1);
}
if ((pid = fork()) == -1) {
perror("fork);
return(-1);
} else if (pid == 0) {
(void)execl("/usr/sbin/gload", "/usr/sbin/gload", 0);
fprintf(stderr, "host: execl(\"gload\") failed\n");
return(-1);
}
if (uhReadGame(fd, hostBuffer, 4) == -1) {
fprintf(stderr, "uhReadGame %s\n", sys_errlist[errno]);
return(1);
}
if (uhCloseGame(fd) != 0) {
perror("uhCloseGame");
return(-1);
}
if (waitpid(pid, &status, WUNTRACED) == -1) {
perror("waitpid");
return(-1);
}
}
...
mainproc(void *arg) /* Game side code */
{
osWriteHost(gameBuffer, 4);
osExit();
}
.Ee
.SH DIAGNOSTICS
.PP
.I uhOpenGame
On success, a valid file descriptor is returned.
Otherwise, a -1 is returned and errno is set to indicate the error.
.PP
.I uhReadGame
The number of bytes successfully read is returned.
.PP
.I uhWriteGame
On success, uhWriteGame returns the number of bytes actually written.
Otherwise, it returns -1 and sets errno to identify the error.
.PP
.I uhReadRamrom
On success, a value of 0 is returned.
Otherwise, a -1 is returned and errno is set to indicate the error.
.PP
.I uhWriteRamrom
On success, a value of 0 is returned.
Otherwise, a -1 is returned and errno is set to indicate the error.
.PP
.I uhCloseGame
On success, a value of 0 is returned.
Otherwise, a -1 is returned and errno is set to indicate the error.