head	1.3;
access;
symbols;
locks
	yap:1.3; strict;
comment	@# @;


1.3
date	97.12.05.20.13.14;	author yap;	state Exp;
branches;
next	1.2;

1.2
date	97.12.04.16.21.47;	author yap;	state Exp;
branches;
next	1.1;

1.1
date	97.11.20.16.41.37;	author yap;	state Exp;
branches;
next	;


desc
@@


1.3
log
@*** empty log message ***
@
text
@<html>
<title>
PROJECT PAGE: V22.0201, Machine Organization I, Yap
</title>
<body bgcolor="EEEEEE">

<h4><font color=AA0000> <center>
<a name=top>
V22.0201.002, Machine Organization I, Yap
</a><br>
Fall 1997
</center></font> </h4>

<img src="http://cs.nyu.edu/~yap/gifs/lines/rainbowline.gif">

<h4><font color=AA00AA> <center>
FINAL PROJECT HOMEPAGE
</center></font> </h4>

This page collects useful information for
doing your final project.  Please look here for
information that I will add, from time to time.

<h3><font color=AA00AA>
CONTENTS
</font> </h3>
<ol>
<li> <a href=#info>Project Information</a>
<li> <a href=#prop>Proposal Tips</a>
<li> <a href=#proplist>Your PROPOSALS</a>
<li> <a href=#reuse>Programs You Can Use</a>
<li> <a href=#tips>Technical Notes and Tips</a>
<li> <a href=#desiderata>Considerations in Project Design</a>
<li> <a href=#faqs>F.A.Q.s</a>
<li> <a href=#bot>Bottom of Page</a>
</ol>

<p>
<hr>
<h3><font color=AA00AA>
<a name=info>
PROJECT INFORMATION
</a>
</font> </h3>
<ul>
        <li>
        <a href=../hw/proj.htm>Project Description</a>: this is
        due Wed Dec 10 (last class).
        <li> Proposal is due Mon Nov 24 (instead of Nov 19).
                Proposal is worth 20 points.
        <li> Here are the <a href=../hw/teams.htm>Project Teams</a>.
                You cannot do hw4 or final project if your name
                is not in this list!
        <li> Here are some <a href=../hw/games/>GAMES</a>
		from the past that you
                can use (either for examples or as basis
                for your own project)
</ul> 

<p>
<hr>
<h3><font color=AA00AA>
<a name=prop>
PROPOSAL TIPS
</a>
</font> </h3>
There are things that I like to see in your game proposals:
<pre>
 	(1) some element of timing
	(2) some animation and graphics
	(3) interesting or innovative twists
</pre>
Does not mean every proposal has to have
all (or even any) of these elements.  But
if these are missing, I think you better
introduce some other nice features that I
consider adequate substitute.  Note that even
with graphics or animation, you may be able
to use text modes rather than the graphics modes.
<p>
When you write your proposal, try to mention
whether you will use any of the following features,
and expand on them if necessary:
<pre>
	(a) random number generator
	(b) use of timer
	(c) setting up of new interrupts
	(d) use of mouse
	(e) video modes: graphics or text mode?
	(f) use of animation
</pre>
E.g. The usual game of pong has (1) and (2), but
is boring from the viewpoint of (3) -- there are
plenty of such games available (for instance, there
is one in the book).  
<p>
E.g. The Extreme Volleyball game by students in
my previous class is really a simple variation of the
pong game, but they gave it a nice twist.
<p>
E.g. Don't propose to do tic-tac-toe, in the standard
version of this!  No timing, no animation, no novelty.
But if you want to do a 3D version of this, I would be 
more receptive.  
<p>
E.g. Tetris has (1) and (2) but do not propose to
do the standard game (it is easy to copy the
code for this game from the internet).  
But I can think of lots of
variations of tetris that you can do.  One might
be to add "obstacle" squares such that a piece can get
stuck if lands on the obstacles.  Another would be
to change the shape of the region in which you play
the game (e.g., the bottom edge need not be flat).



<p>
<hr>
<h3><font color=AA00AA>
<a name=proplist>
YOUR PROPOSALS
</a>
</font> </h3>
Here is the (working) <a href=../hw/prop.htm>list of proposals</a>.
If your proposal is not here, contact me at once!

<p>
<hr>
<h3><font color=AA00AA>
<a name=reuse>
ROUTINES YOU CAN USE
</a>
</font> </h3>
<ol>
<li>
<b>Random number generator.</b>
In many games, you want to generate random numbers.
We will provide you with such a program to use, if
you need one.
<li>
<b>Counting clock ticks.</b>
Another critical element in many games is the ability
to keep time.  The text book (ch.15) has a timer program that
is set up as an interrupt.  Use this if you need a timer.
<li>
<b>Sound.</b>
We plan to give a lecture on sound.  But even without
going into fancy sound (with music, etc), you can
use beeps and other simple sounds to improve the
quality of your game.  We suggest you consider this.
<li>
<b>Mouse.</b>
If you want to define and change the mouse cursor, please look
in our notes on mouse (INT 33h, function 9).
<li>
<b>Animation.</b>
We will give a lecture on this.
Or, look at the sample games.
<li>
<b>Collection of VGA graphics routines.</b>
	A collection of such routines in assembly
language and in C language is available in subdirectories "asm" and
"c" in the progs directory.  The file egalib.asm in vga-asm includes
all the other programs. So you could assemble it to test all the
routines.  However, you need to write your own main program!
<p>
	P.S. I found that using "CONST" as name of a segment
	is illegal in TASM, so you can replace it by "_CONST".
	There are 3 places where you need to do this.
<p>
There is a line drawing routine (prog086.asm)
and a routine to draw a solid box (prog085.asm).
I have written some main programs to call these routines
(e.g., vgaline.asm uses the routine in prog086.asm).
<p>
One of the most useful programs here is "Bit Block Transfer",
<b>_BitBlt</b> in prog087.asm.  It
copies a block of pixels from a source block to a destination block. 
Unfortunately, I believe this works only on page 0
of your graphics mode.
Look at my files vgablt*.asm to exercise _BltBlt in various modes.
<p>Also, if the source and destination
blocks overlap, there may be some undesirable effects in _BitBlt.
My solution is to write another program, called
<b>_BitBltX</b> which also does block transfer
but calls _BitBlt several times,
each time making sure that there is no overlap,
</ol>

<p>
<hr>
<h3><font color=AA00AA>
<a name=tips>
TECHNICAL NOTES TIPS
</a>
</font> </h3>
Here is a list of <a href=index.html>general notes</a>
on various aspects of assembly language programming
(video, mouse, etc).
Below, we mention additional information
specific to your final project. 
<ol>
<li>
<b>CHOOSING VIDEO MODES.</b>
See <a href=video.htm>Video Info</a> for general
details about video programming.
<br>
One of the first decisions you need to make is whether
to use a text mode or a graphics mode.  Although
the choices may at first appear confusing, remember
that most of you really only need to learn
how to use ONE of these modes.  In choosing modes,
remember that there are
simple text capabilities even in graphics mode.
Likewise, there are
some primitive graphics ability even in text mode.
For instance, in text mode
using the IBM extended character set,
you can draw rectangular boxes (or, mazes)
in single or double lines!  (INT 10h, function 9 will
work for extended character sets)
Moreover, the mouse capability (INT 33h)
works in text as well as graphics mode.
<li>
<b>USEFUL VIDEO MODES.</b>
Normally, your MS-DOS Prompt begins in mode 3 (cga text mode).
For instance, the pong game in the text is written in this mode.
Also, when you exit from your games, you should always
reset your screen back to this mode.
<p>
Generally, most games can use more colors
in which case I recommend modes 12h or 13h,
which are vga graphics modes.  These modes have only
one video buffer page.
<p>
If you need more than one page,
consider using (vga graphics) mode 10h which has two pages.
Mode 10h has screen size 640x350, and has 16 colors
provided your video buffer is at least 128K.
See Helppc for more details.
These days, most machines have 256K video buffer,
so this is not a problem.  To find out what your computer has,
use INT 10h, fcn=12h.
<p>
Note that when you switch modes or pages,
normal the display is cleared.
To prevent this, make sure that bit 7 of AL is
set before you call INT 10h. 
	<pre>
	mov ah,0	; set mode
	mov al,10h	; choose mode 10h
	or al,80h	; set bit 7 of AL
	int 10h
	</pre>
<li>
<b>USING THE MOUSE in Win95 or WinNT.</b>
See <a href=mouse.htm>Mouse Info</a> for general
details about mouse programming.
<br>
If you use mouse inputs, it may not work properly
if your program is a window in Win95 or WinNT.
The best solution is to take
over the whole screen for your program.  You can
do this by typing ALT-ENTER to toggle between
taking over the screen and going back into Win95.
<br>
NOTE: In Win95, you can also choose the ``properties'' menu
of the MSDOS Prompt Window, and under the ``misc'' tab,
choose to make the mouse exclusive.
In WinNT, one can also get to the ``properties|misc'' tab,
but it does not seem to work.
<li>KEEPING ABSOLUTE TIME.<br>
	In graphics animation, you often need to delay
	the display.  One way is to use a do-nothing loop.
	But this approach does not keep absolute time -- the
	time depends on the speed of your CPU.  (Another problem
	is that this ties up your CPU doing nothing).
	To avoid this problem, you need to make use
	of the timer chip in your PC.  Chapter 16 of your
	text book gives a simple solution.  Essentially, it
	writes a timer interrupt procedure called TIMER_TICK
	(page 344) to be called automatically 18.2 times per
	second (equivalently, every 55 ms).  This procedure
	simply sets a global variable TIMER_FLAG to 1.
<p>
	This TIMER_TICK program is used in pgm16_2 (page 346).
	It is used to for generating a fixed frequency
	tone for the sound card (page 347).
	I have written a sample program (found in the file
	timeout.asm) to illustrate how you can keep time using
	the timer_tick interrupt routine.  (Look under ``samples''
	in class page.)
<p>
	NOTE: Another method to keep absolute time is to
	directly read the clock tick at address 0000:046C
	and 0000:046E (this is a 32 bit value that is updated
	by the clock every 55 ms).  See the file egalib.asm
	in the vga-asm directory.
<li>KEYBOARD BUFFER EMPTY?<br>
	It is often useful to know if the keyboard buffer is empty
	or not.  You cannot use INT 21h, function 1 for this
	(why not?).
	This requires INT 16h, function 1.
	On return from this interrupt, the
	zero flag (ZF) is set if keyboard is empty.
	The program timeout.asm (mentioned above)
	uses this interrupt function.
	Actually, DOS also provides a similar interrupt function:
	INT 21h, function 11h is called the "input status interrupt".
	<pre>
		INPUT:  ah=11h
		OUTPUT: al=0 if buffer is empty
			al=0FFh if buffer is not empty
	</pre>
	Related to this interrupt is the ability to flush the buffer,
	and execute an input command at the same time.
	<pre>
	INT 21h, function 0Ch:
		INPUT:  ah=0Ch
			al=1,6,7,8 or OAh
	</pre>
	The output depends on which of the subfunctions (1,6,7,8,0Ah)
	is used.  Other inputs are also necessary,
	depending on the subfunction.
	For instance, al=0Ah refers to reading a string.  In this
	case, ds:dx must be setup to contain the address of the
	memory buffer for storing the string input.  (This was
	the subject of HW3.)
<li>USING STANDARD MEMORY MODELS.<br>
	Usually, we use the "small" model
	and this should be sufficient for many of your
	projects as well.  But suppose you need other
	models.  First, let us note that the small model
	assumes that there are separate segments for
	each of the following:
	<pre>
		code, stack, data.
	</pre>
	Suppose your program does not fit the small model.
	You can of course, go to full blown definitions
	of your own segments (using the "SEGMENT" directive).
	But a more convenient way is to use other
	``standard memory models''.
	We now explained three of the most common ones.
	In other models, we allow code and data to be put into
	more than one segment.  Moreover, we distinguish several
	kinds of data segments.
	<pre>
		data:	has (possibly) initialized data
		data?:	has only un-initialized data
		const:	has constant data
		fardata: has (possibly) initialized data
		fardata?: has only un-initialized data
	</pre>	
	<b>MEDIUM MODEL</b>: data here can be put in one segment but code
	needs to be put into several segments.  
	To use this model, you use the following directive:
	<pre>
		.MODEL MEDIUM &gt;csn&lt;
	</pre>
	where &gt;csn&lt; refers to "code segment name".  If you have
	several assembly modules, each with a different &gt;csn&lt;,
	you can generate several code segments this way.
	But, in fact, you can also generate more than one code
	segment within the same assembly module, by using the
	directive
	<pre>
		.CODE &gt;csn&lt;
	</pre>
	This directive begins a new code segment with name
	&gt;csn&lt;_text, or continues a previously started code
	segment with that name.
	<p>
	<b>COMPACT MODEL</b>: code here can be put into one segment
	but data needs to be put into several segments.
	The usual .DATA directive generates one data segment which
	is the "near data segment".  You can generate other data 
	segments by using the directive
	<pre>
		.FARDATA &gt;name&lt;
	</pre>
	This begins or continues (possibly) initialized data
	segment with name &gt;name&lt;.  For instance, suppose if you have
	the statements
	<pre>
		.FARDATA data1
		Var1 db ?
		...
	</pre>
	To you can access Var1, you need to first get its
	segment number into ds.  For instance, to set Var1 to 
	the constant 1, you can do
	<pre>
		mov dx, SEG Var1	; alternatively, use
					; 	mov dx,data1
		mov ds, ax		; this sets up ds
		mov di, OFFSET Var1	; alternatively, use
					;	lea di,Var1
		mov [di], BYTE PTR 1
	</pre>	
	<b>LARGE MODEL</b>: this is just the combination of the medium
	and the compact models.
	<br>
	<b>NOTE</b>: the "assume" statement is useful in these models.

<li> HELPPC<br>
	This is an online system that allows you to
	get all kinds of technical information for pc programming.
	Please go to the link called "helppc" to get these files and
	installation information.
</ol>
 
<p>
<hr>
<h3><font color=AA00AA>
<a name=desiderata>
CONSIDERATIONS IN PROJECT DESIGN
</a>
</font> </h3>
<ol>
<li>
Please restore the video mode after the end of your game!
I do not want to restart my machine after testing each
of your games!
<li>
It is often good to ask the user if they want to
replay the game, instead of simply quitting.
<li>
It is a good idea to allow the user to set certain
parameters for the game (level of play, etc).  Do this
interactively.
<li>
ABSOLUTELY ESSENTIAL: give ONLINE instructions.
The simplest is to provide
one screen of information at the start of the game,
containing the following information:
	<ul>
	<li> The name of your game
	<li> Credits (your names and other acknowledgements)
	<li> Game objectives
	<li> How to play the game (what keyboard buttons to push!)
	<li> How to QUIT!
	</ul>
<li>
Remember that the amount of time delay is critical for
many games -- if it is too fast, it is impossible to play
and if it is too slow, it is boring.  But it is often difficult
to ensure that the time delay that you have measured perfectly for
your machine will be perfect for another machine.  E.g., the
game may be right for your 386 machine at home, but impossible
for my 300 MHz Pentium II machine.  Therefore, try to
set these time delays as parameters, say, via an EQU statement:
	<pre>
	TIMEDELAY  EQU 30
	</pre>
Better still, allow the user to select the time delay at the
start of the game.
</ol>

<p>
<hr>
<h3><font color=AA00AA>
<a name=faqs>
F.A.Q.s
</a>
</font> </h3>
<dl>
<dt>
<b>1. How do we divide the work among the team members?
</b>
<dd>
I suggest you get together and try to hammer out as
much details as possible (short of actually writing the code,
but figuring out what functions you need to write,
which interrupt numbers, graphics details, etc).
Then you should have no trouble figuring out
_some_ plan for partitioning the work.
Here is one breakdown for a 3-person team:
	<pre>
	1) Main routine and overall logic of the game
	2) Graphics
	3) Input/Output, interface issues, help routines.
	</pre>
But it really depends on your game.

</ol>

<p>
<hr>
<h3><font color=AA00AA>
<a name=bot>
BOTTOM OF PAGE.
</a>
</font> </h3>
Click <a href=#name>HERE</a> to go to the top of page.

</body>
</html>
@


1.2
log
@*** empty log message ***
@
text
@d221 2
a222 1
in single or double lines!
d304 1
a304 1
	This requires INT 16h, function 1 (not found in text).
d310 1
a310 1
	INT 21h, function 11 is called the "input status interrupt".
d312 1
a312 1
		INPUT:  ah=11
@


1.1
log
@Initial revision
@
text
@d3 1
a3 1
V22.0201, Machine Organization I, Yap: Information for Final Project
d8 3
a10 1
V22.0201.002, Machine Organization I <br>
d16 1
a16 1
<h3><font color=AA00AA> <center>
d18 1
a18 1
</center></font> </h3>
d21 2
a22 1
doing your final project.
d28 1
d30 1
d32 1
a32 1
<li> <a href=#tips>Technical Tips</a>
d34 2
d38 2
d41 22
d118 2
d121 10
d132 1
a132 1
REUSABLE PROGRAMS FOR PROJECT
d161 4
a164 4
<b>VGA graphics.</b>
	A collection of graphics routines in assembly
language and in C language is available in subdirectories "vga-asm" and
"vga-c" in the progs directory.  The file egalib.asm in vga-asm includes
d172 17
a188 3
Perhaps the most useful single program here is in prog087.asm
which copies one block of pixels from a source to a distination. 
There is also a line drawing program (prog086.asm).
d191 2
d195 1
a195 1
TECHNICAL TIPS
d198 5
d205 18
a222 6
<b>VIDEO MODES.</b>
This is one of the first decisions you need to make:
text mode or graphics mode.  Remember that there are
some primitive graphics ability even in text mode,
and there are also simple text capabilities even in
graphics mode.   Moreover, the mouse capability
d225 31
d257 3
d413 2
d459 38
@
