hwimpact.html
25 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
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="ProgId" content="Word.Document">
<meta name="Generator" content="Microsoft Word 9">
<meta name="Originator" content="Microsoft Word 9">
<link rel="File-List" href="./hwimpact_files/filelist.xml">
<title>BB HW Change impact</title>
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Author>jprincen</o:Author>
<o:LastAuthor>jprincen</o:LastAuthor>
<o:Revision>6</o:Revision>
<o:TotalTime>208</o:TotalTime>
<o:Created>2002-05-06T16:34:00Z</o:Created>
<o:LastSaved>2002-05-08T01:37:00Z</o:LastSaved>
<o:Pages>2</o:Pages>
<o:Words>1089</o:Words>
<o:Characters>6212</o:Characters>
<o:Company>RouteFree</o:Company>
<o:Lines>51</o:Lines>
<o:Paragraphs>12</o:Paragraphs>
<o:CharactersWithSpaces>7628</o:CharactersWithSpaces>
<o:Version>9.3821</o:Version>
</o:DocumentProperties>
</xml><![endif]-->
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
h1
{mso-style-next:Normal;
margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:1;
font-size:16.0pt;
font-family:Arial;
mso-font-kerning:16.0pt;
font-weight:bold;}
h2
{mso-style-next:Normal;
margin:0in;
margin-bottom:.0001pt;
text-align:center;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:2;
font-size:24.0pt;
mso-bidi-font-size:12.0pt;
font-family:"Times New Roman";
font-weight:bold;}
h3
{mso-style-next:Normal;
margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
mso-pagination:widow-orphan;
page-break-after:avoid;
mso-outline-level:3;
font-size:13.0pt;
font-family:Arial;
font-weight:bold;}
p
{margin-right:0in;
mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;
margin-left:0in;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:53091577;
mso-list-type:hybrid;
mso-list-template-ids:-2126447018 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l1
{mso-list-id:82919173;
mso-list-type:hybrid;
mso-list-template-ids:-718117768 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l2
{mso-list-id:165436510;
mso-list-type:hybrid;
mso-list-template-ids:-1311228882 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l3
{mso-list-id:422650892;
mso-list-type:hybrid;
mso-list-template-ids:419468964 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l3:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l4
{mso-list-id:1003630957;
mso-list-type:hybrid;
mso-list-template-ids:-944750416 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l4:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l5
{mso-list-id:1363242439;
mso-list-type:hybrid;
mso-list-template-ids:-1975880208 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l6
{mso-list-id:1497182114;
mso-list-type:hybrid;
mso-list-template-ids:720262462 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l6:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l7
{mso-list-id:1591691564;
mso-list-type:hybrid;
mso-list-template-ids:-526234310 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l7:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l8
{mso-list-id:1671519886;
mso-list-type:hybrid;
mso-list-template-ids:2103457038 -1243170796 1455750678 412756100 -1736138448 1213623060 1866640010 -57233198 224812354 300832018;}
@list l9
{mso-list-id:1987664543;
mso-list-type:hybrid;
mso-list-template-ids:-1935267480 143178172 319178122 1071008004 -1390096302 1526908006 358495008 -1288265754 -1492377242 -763599922;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1"/>
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" style="">
<div class="Section1">
<h2 style="text-align: justify;"><span style="">Hardware changes effecting
legacy software <o:p></o:p></span></h2>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">This document identifies hardware changes that will impact
the n64 development kit software, and the n64 game code. We will make the
appropriate changes to the n64 development kit code for migration to a BB
dev kit. However, game code will likely need to be updated to compensate for
HW changes in the list below as well (i.e., simply rebuilding the n64 game
code against a BB dev kit will probably not be sufficient). In each case
below the impact of the change: whether it is DevKit, or application is identified.</p>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<h3>PIF security functions</h3>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">The PIF is removed completely from the BB system design.
The security functions that it provided are handled by other parts of the
system.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No PIF security code.</b> Applications can
communicate directly with the PIF for security operations. Since the PIF does
not exist these functions are unimplemented. We will need to go through game
code and remove all these accesses.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
2.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>Boot:</b> the boot code was in the PIF. Our
boot model is similar. We will provide an alternative packaging mechanism
for game images that matches our boot model. We don’t expect any issues.</p>
<p class="MsoNormal">For item 1 we need to understand from Nintendo what
application code was introduced in games for security functions to gauge
how much effort would be involved in removing it. Our current understanding
is that very few games use this security mechanism.</p>
<h3>PIF Controller Functions </h3>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">The controller related functions provided through the
PIF are emulated in hardware to provide an equivalent mechanism.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>Controllers. </b>For controller access we
are implementing a backward compatible solution that will implement controller
query, controller read, and controller reset. All other controller commands
will be unimplemented (See SI specification). We should remove any other functions
from the dev kit.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
2.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No Controller Pak media:</b> games used this
to store persistent state in SRAM. There is a controller pak file system API
(pfs module) in the n64 dev kit, so for games that used this API our BB implementation
can emulate the behavior using some other storage area. Depending on performance
requirements it may be possible to use Flash directly. Alternatively it may
be possible to use the on-chip SRAM to store the data, then write to application
flash as the game shuts down. The difficulty here is when the transfer from
SRAM to flash would be triggered, since it is possible that the user would
just switch the system off without exiting the game.</p>
<p class="MsoNormal" style="">For 2 we need to understand the way games use
SRAM. It is likely that, given the performance limitations of the serial interface,
we can write directly to Flash.</p>
<h3>PIF Pre-NMI/NMI</h3>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">In the N64 the reset button was connected to PIF and
generated an NMI followed by a cold reset after 0.5 sec. This gave games
time to stop audio and graphics for a clean shutdown. </p>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No PIF NMI/Reset:</b> In BB we are providing
a direct input from the Reset button to the BB chip. The BB will send an INT2
to the embedded MIPS CPU and after 0.5 sec generate a soft reset. The OS
exception handling code will be changed to provide the OS_ EVENT_PRENMI event
based on the new hardware behavior.</p>
<h3>Cartridge ROM, EEPROM and SRAM </h3>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">The BB system uses Flash instead of a ROM cartridge and
does not support devices for saving state that existed in some cartridges.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>Flash access time (i/o and DMA):</b> Flash
has 25 uSec hit for switching blocks (a block is 512 bytes), then 70nSec per
byte. ROM speed was 200nSec per 2 byte word, no hit for random access (double
check with Frank). Our assumption is most time critical code does DMA transfers
which are relatively long (>= 1024 Kbytes), so our performance is around
7 Mbytes/sec peak for this case. For long transfers the asymptotic transfer
rate peak is 14 Mbytes/sec. We assume this is sufficient. </p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
2.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No ROM contiguous addresses:</b> we will emulate
this, but since nand-flash will have bad blocks, the application loading must
program new hardware registers to make the flash address space of a game
appear contiguous. The current plan is to make bad blocks completely transparent
to the software. However, depending on detailed evaluation of flash characteristics,
it is possible we may need to change DMA code to provide some software support
for mapping out bad blocks. This could potentially affect every existing
ROM to RAM DMA in the code. This would involve a change to the PI DMA library
in the dev kit.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
3.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No EEPROM in game cartridge:</b> games used
this to store persistent state. There is an EEPROM i/o API in the n64 dev
kit, so for games that used this API our BB implementation can emulate the
behavior. It is noteworthy that the EEPROM on the cartridge was visible to
the n64 game as a "fifth" controller. So, the eeprom API has some controller
dependence. </p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
4.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No SRAM in game cartridge:</b> games used
this to store persistent state. There was no API for this, since the SRAM
was available directly through the AD16 bus, so this case would need to be
considered on a game-by-game basis by altering the game-code itself. We would
prefer to replace these with writes to Flash. Performance could be an issue,
if games do a lot of read/write to SRAM during game execution.</p>
<h3>MIPS CPU Change</h3>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">The available MIPS cores have slightly different cache
design than the R4300. </p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>Data cache line size:</b> the line size is
likely to grow from 16 to 32 bytes. Alignment of all dma buffers (i/o APIs
provided in dev kit) and RCP buffers (handed off to SP in task list) will
need to be changed to the new line size. Also, to facilitate the use of overlays
the Nintendo dev kit <i>makerom</i> utility will automatically generate symbols
to use as arguments to the functions osInvaliICache/DCache. We will provide
a tool similar to <i>makerom</i>, to generate final images. Any "auto" layout
performed by this tool must take into account the new data cache line size.
</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
2.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>Cache mapping and overall size:</b> cache
mapping will change from direct to 2 (or 4) way set associative. This will
mean the Cache Invalidate and writeback code has to change. This could also
produce the effect of having multiple in-cache mappings of a given physical
address if the Game Developers use the TLB and the kseg0 address space to
access the same piece of physical memory. This is a corner case and unlikely
to cause problems.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
3.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>TLB number of entries will change:</b> so
long as the new number is greater this should not affect games directly unless
they program the TLB without using the dev kit functions. However, the DevKit
functions such as osUnmapTLBALL may require minor change.</p>
<h3>AD16 BUS</h3>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">The AD16 bus does not exist.</p>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>No AD16 bus:</b> We don’t provide any registers
associated with AD16 bus control (eg to set up different speeds). </p>
<h3>DRAM Change to DDR</h3>
<p class="MsoNormal" style="margin-left: 0.75in; text-indent: -0.25in;"><!--[if !supportLists]-->
1.<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">
      </span><!--[endif]--><b>SDRAM vs RDRAM timing issues:</b> Currently
our hardware design will provide a lower latency memory access, along with
better throughput (since it hides page crossings). Should not be any issues.</p>
<h2 style="text-align: justify;">Software Porting Issues</h2>
<p class="MsoNormal"><!--[if !supportEmptyParas]--> <!--[endif]--><o:p></o:p></p>
<p class="MsoNormal">In addition to the above hardware related issues, there
are several software only issues that effect how easy it will be to port a
game to the BB system.</p>
<ol start="1" type="1">
<li class="MsoNormal" style=""><b>New Library version:</b> the game
was linked originally vs some version of a DevKit. Although we have the
latest DevKit and will make porting changes, this DevKit may not be
completely backward compatible with the DevKit used for a particular
game. We need to understand in more detail the DevKit history and the code
used for particular games. </li>
<li class="MsoNormal" style=""><b>New library sizes:</b> the new
DevKit will likely have libraries of different size those the game originally
linked with. This will probably require changes to the spec file for
makerom (or .lk file for SN) to be changed to allow for new placements.
</li>
<li class="MsoNormal" style=""><b>Font sizes may grow:</b> the Chinese
font bitmaps may be larger than the Kanji ones currently in place. This
may alter the assumed memory map for a given game (depending on where
font storage actually was located). Also, since we do not have more memory
than N64 we need to be careful of increasing memory footprint.</li>
</ol>
<br>
<h2 style="text-align: justify;">Changes To libultra</h2>
<p class="MsoNormal" style=""><!--[if !supportEmptyParas]--> <!--[endif]--><br>
<b>Power off interrupt</b><br>
Add a default handler to detect power off.  This will be in place of the
pre-nmi handler.   This handler is effectively the same as the pre-nmi handler
and simply turns off graphics and audio just as the original pre-nmi handler
did.<br>
<br>
</p>
<p class="MsoNormal" style=""><b>Controller Pak State Support</b><br>
We will emulate one 32KB controller pak using flash memory.  Content metadata
will include information about whether the game can use the controller pak.
 The contents in flash will be moved into bb chip internal SRAM before the
start of the game and the controller pak library will operate on the SRAM
image.  This involves changes to the osPfs routines.  When power is turned
off, the game state is saved back to flash by the browser application.  We
still need to decide what to do to support the equivalent of controller pak
removal and insertion.<br>
<br>
</p>
<p class="MsoNormal" style=""><b><o:p></o:p>EEPROM State Support</b><br>
We will emulate a 256B or 2KB EEPROM using flash memory.  Content metadata
will indicate whether the game supports EEPROM and if so, the contents will
be transfered to internal SRAM before the game starts,  The eeprom library
routines are changed to operate on the eeprom image in SRAM.  This involves
changes to the osEeprom routines.  If we are supporting both controller pak
and EEPROM simulatenously, then EEPROM state will be cached in DRAM rather
than SRAM and the controller pak state will use SRAM.  The browser must be
capable of locating the state.</p>
<p class="MsoNormal" style=""><br>
<b>SRAM State Support</b><br>
We will emulate 32KB SRAM using flash memory for persistent storage.  Content
metadata will indicate whether the game supports SRAM and if so, the contents
will be transferred to internal SRAM before the game starts.  There is no
SRAM libultra routines per se, so games will require specific changes on a
game by game basis.<br>
</p>
<p class="MsoNormal" style=""><br>
<b>Flash State Support</b><br>
We will emulate up to 256KB of cartridge flash memory using the bb player
flash.  Content metadata will indicate whether the game supports flash memory
and the flash routines will be enabled as appropriate.  We libultra flash
library will be modified to write to the bbplayer flash directly.  This involves
changes to the osFlash routines.<br>
</p>
<p class="MsoNormal" style=""><br>
<b>GBPak  and Voice Recognition Support</b><br>
The GB Pak and Voice Recognition System are not supported.  The <tt>osGbpak</tt>
and <tt>osVoice</tt> routines are disabled.<br>
</p>
<p class="MsoNormal" style=""><br>
<b>Controller Support</b></p>
<p class="MsoNormal" style="">Changes to the controller routines to use the
more restricted set of commands and avoid referring to the PIF RAM space.
 This involves small changes to the osCont routine to change the Reset sequence.<br>
<br>
</p>
<p class="MsoNormal" style=""><b>Rumble Pak Support</b><br>
The rumble pak is manipulated through the <tt>osMotorInit,</tt> and <tt>
osMotorAccess</tt> functions.  These functions are replaced with versions
supporting the modified SI support.  The motor functions use a controller
pak (pfs) structure as a handle, so for compatibility this needs to be maintained.<br>
<br>
</p>
<p class="MsoNormal" style=""><b>Initialization Changes</b><br>
The game launcher must fill in the various pieces of information formally
supplied by the PIF boot process <tt>(osTvType,</tt> <tt>osRomType,</tt>
<tt>osResetType,</tt> <tt>osCicId,</tt> <tt>osVersion,</tt> <tt>osRomBase,</tt>
<tt>osMemSize</tt>).<br>
<br>
</p>
<p class="MsoNormal" style=""><b>Video Changes</b><br>
Changes to support the bcp internal encoder (if any).  Changes to the video
format tables to match any clock changes.<br>
<br>
</p>
<p class="MsoNormal" style=""><b>CPU Clock</b><br>
The macros <tt>OS_CYCLES_TO_{USEC,NSEC}</tt> and <tt>OS_{USEC,NSEC}_TO_CYCLES</tt>
are normally used to convert between timer ticks and time.  Rather than
change these, the timer routines will be modified to operate in normalized
timer ticks at 46.875MHz (62.5MHz*1.5/2).  This means that these timer routines
must know the CPU clock frequency from the board strappings to perform the
correct conversion.  The timer routines are <tt>osGetTime,</tt> <tt>osSetTime,</tt>
and <tt>osGetCount.</tt><br>
</p>
<p class="MsoNormal" style=""><b><br>
Issues:</b><br>
</p>
<ul>
<li>Exact changes to controller code.</li>
<li>What to do if more than 1 state mechanism is supported by game (e.g.,
Controller Pak + EEPROM).<br>
</li>
</ul>
</div>
</body>
</html>