User Tools

Site Tools


Sidebar

projects

wcp1 (due 20250129)
abc0 (due 20250205)
btt0 (due 20250205)
pct0 (bonus; due 20250205)
pct1 (bonus; due 20250205)
pct2 (due 20250205)
wcp2 (due 20250205)
mtb0 (due 20250212)
pct3 (bonus; due 20250212)
wcp3 (due 20250212)
mtb1 (due 20250219)
pct4 (due 20250219)
wcp4 (due 20250219)
pct5 (bonus; due 20250226)
wcp5 (due 20250226)
mtb2 (due 20250227)
dap0 (due 20250305)
gfo0 (due 20250305)
pct6 (due 20250305)
wcp6 (due 20250305)
dap1 (due 20250312)
pct7 (bonus; due 20250312)
wcp7 (due 20250312)
bwp1 (bonus; due 20250326)
dap2 (due 20250326)
pct8 (due 20250326)
wcp8 (due 20250326)
mtb3 (due 20250402)
pct9 (bonus; due 20250402)
wcp9 (due 20250402)
haas:spring2025:comporg:projects:mtb2

Corning Community College

CSCS2650 Computer Organization

PROJECT: Move The Block (MTB2)

OBJECTIVE

Restructure your MTB1 (or recreate from the ground up) to create an assembly-based pong game, with all supporting resources.

EDIT

You will want to go here to edit and fill in the various sections of the document:

Pong

scoring

Scoring in pong is as simple as checking if the ball has left the screen; if it crosses the left side the right player gets a point, and vice versa.

For our purposes, we can check if the ball's x position has exceeded 640 or subceeded 0

score storage

You can store the score and other variables you may use such as x and y positions to locations in memory by defining it, for example:

%define LScore    0x00000000

You can then load each score into a register before use so you can use the same score tracking function for both the right and left players scores by loading different scores before calling the function.

score display

Displaying the player's scores is where things start to get more complex, as we no longer have built in 'itoa' or 'print' functions, so we will have to build them manually.

First off, and debatably more complex portion, is creating an itoa function
To do this we can break down what we need to get printable characters from any arbitrary number
That process requires getting each digit from our number, ie to print 104, we need to have print a 1, a 0, and a 4, as they are all separate regions is the BIOS texture
One possible way of doing this is to use math to pick apart a number from right to left, converting each digit to its ASCII value, and store them, in a process that may look like:

   MOV  R0,   104
   MOV  R1,    R0   ; Store a copy of the original into R1
_itoa:
   MOV  R2,    R1   ; Store a copy of the number into R2
   IMOD R2,    10   ; Retrieve the last digit from the copy
   IADD R2,  0x30   ; Convert the number to its ASCII value
   PUSH R2          ; Store the digit onto the stack
   IDIV R1,    10   ; Remove the last digit from the original
   MOV  R3,    R1   ;                   ;
   IEQ  R3,     0   ; Repeat until zero ;
   JF   R3, _itoa   ;                   ;

Once we have each character we want to print, printing them is a simple matter
The process may look like:

   %define SELREG  GPU_SelectedRegion
   %define SELTEX  GPU_SelectedTexture
   %define DRAWX   GPU_DrawingPointX
   %define DRAWY   GPU_DrawingPointY
   %define GPUCOM  GPU_Command
   %define DRAWREG GPUCommand_DrawRegion
   
   ...
   
   OUT  SELTEX,        -1    ; Select the BIOS texture
   MOV  R0,             0    ; Place a dummy value onto the stack ;
   PUSH R0                   ;                                    ;
   CALL _itoa                ; (assuming itoa has a RET instruction)
_innerloop:
   POP  R0                   ; Retrieve the first character
   MOV  R1,            R0
   IEQ  R1,             0
   JF   R1,       _return
   OUT  SELREG,        R0    ; Set the region
   OUT  DRAWX,         RX    ; Set the x position (whatever register contains the xpos)
   OUT  DRAWY,          #    ; Set the y position
   OUT  GPUCOM,   DRAWREG    ; Draw the character
   IADD RX,            10    ; Move xpos to next open space
   JMP  _innerloop
_return:
   RET

computer operated player

determining computer paddle movement

The simplest version of a computer operated player has the bot moving the paddle to the same vertical position as the ball.

First we need to get the difference in position between the paddle and the ball.

*NOTE* we want the center of the paddle to hit the center of the ball, so we must make sure to compensate for the distance between the hotpots and centers of the paddle

This will tell us the direction and magnitude the paddle should move, but we will want to cap the movement speed of the paddle so the bot isn't too good.

We can also add a small multiplier to further limit the movement of the bot.

_npcMovement:
   ;RY is the register containing the ball's y pos
   ;RP is the register containing the paddles y pos
   ;RT is a temporary register
   
   mov   RT,   RY    ;Store a copy of the ball's ypos
   isub  RT,   RP    ;Get the difference in position
   iadd  RT,   20    ;Compensate for any differences in sizes
   
   imul  RT,    2    ;Optional slow down on bot movement
   idiv  RT,    3    ;This will make the bot 2/3 the responsive
   
   imax  RT,  -10    ;Limit the speed to -5 pixels and 5 pixels
   imin  RT,   10
   
   iadd  RP,   RT    ;Move the bot's paddle acordingly
   
   RET

difficulty of computer player

The difficulty of the computer can be tuned by changing the max speed and responsiveness during their movement step

Another way to increase difficulty is to have the ball move faster or have a smaller paddle. You could also give the computer player a larger paddle.

 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
  • Executed programs must display in a manner similar to provided output
    • output formatted, where applicable, must match that of project requirements
  • Processing must be correct based on input given and output requested
  • Output, if applicable, must be correct based on values input
  • Code must be nicely and consistently indented
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • Code must be commented
    • Any “to be implemented” comments MUST be removed
      • these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
      • Sufficient comments explaining the point of provided logic MUST be present
  • No global variables (without instructor approval), no goto statements, no calling of main()!
  • Track/version the source code in your lab46 semester repository
  • Submit a copy of your source code to me using the submit tool by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

RUBRIC

I'll be evaluating the project based on the following criteria:

130:mtb2:final tally of results (130/130)
*:mtb2:submitted handwritten assembly [13/13]
*:mtb2:submitted Vircon32 cartridge [13/13]
*:mtb2:submitted XML and build script [13/13]
*:mtb2:paddles can be controlled and have bounds detection [13/13]
*:mtb2:paddle and ball collisions work [39/39]
*:mtb2:ball moves on its own, rebounds off bounds [13/13]
*:mtb2:cartridge is NOT added to repository [13/13]
*:mtb2:committed project related changes to semester repo [13/13]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • near the class average edits (a value of at least four productive edits)
      • near the average class content change average (a value of at least 1024 bytes (absolute value of data content change))
      • no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements)
    • adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    • content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      • no contributions, co-efficient is 0.50
      • less than minimum contributions is 0.75
      • met minimum contribution threshold is 1.00

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
  • Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
  • Individuals who have not participated at least 50% will be subject to a 50% overall deduction.
haas/spring2025/comporg/projects/mtb2.txt · Last modified: 2025/02/12 11:30 by 127.0.0.1