User Tools

Site Tools


haas:spring2024:comporg:projects:cta0

Corning Community College

CSCS2650 Computer Organization

PROJECT: C(onvert) To Assembly (CTA0)

OBJECTIVE

With a snake game bootstrapped in C, commence an implementation in Vircon32 assembly.

NOTE

Please update your Vircon32 DevTools to at least version v24.02.04

Vircon32 Assembly Reference

Instead of relying on unoptimized compiler output to swipe internal Vircon32 symbol names, please make use of this reference instead:

EDIT

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

CTA0

To update your vircon DevTools to v24.2.4, go to this link

https://github.com/vircon32/ComputerSoftware/releases/tag/devtools-v24.2.4

Then, depending on the system you use for class, follow the appropriate steps on the github page to install. There is even a section labeled “How to Install.

With the new version of dev-tools, you can use %define to clean up your code, making it more readable and easier to detect errors. (example of this is in the 06b_hello_define directory within the public directory.

The examples we went over in class can be found in the public class directory under “examples.” To get to the public class directory cd into /var/public/spring2024/comporg/examples.

  • cd /var/public/spring2024/comporg/examples

Assembly

Random Spawn

To have your snake food spawn randomly, we will use the built-in random function that is offered by Vircon32. In C, it is extremely simple to implement. You would simply do the following:

#include "misc.h"
#include "time.h"
 
// Seeding srand
srand(get_time());
 
// Getting random X and Y cords for apple
int xApple = rand() % (screen_width);
int yApple = rand() % (screen_height);

So we simply just include the .h file that holds the function, seed srand and then use rand() and specify the range. But in asm we dont need to include any files.

Seeding srand in asm:

in R0, TIM_CurrentTime
out RNG_CurrentValue, R0

So this first spot is the equivalent of seeding srand with get_time. We are getting the time and storing it in R0 and then feeding it into RND_CurrentValue.

; X value
in R0, RNG_CurrentValue
imod R0, 620
mov R14, R0
 
; Y value
in R0, RNG_CurrentValue
imod R0, 320
mov R15, R0

Looking at the above, we are getting a random value between 0 and 620 and storing that in R0. we then feed that into R14. This is our X value for the food. We then repeat the same steps for the y value for the food.

Make sure your object moves at a predictable speed (example: 1 pixel at a time), for if you don't. Then you run the risk of the objects not touching again, as the random value will have a random number assigned to it. Imagine your speed is 5 pixels, then your object will only be able to land on the food in the 2/10 chance it lands in a position ending in 0 or 5.

Remember to add one to the result if your region bounds happen to be at 0, as although unlikely, the fruit can still spawn at 0,0 causing an unfortunate game over. You can add to the random number with iadd R0, 1. This snippet of code will add one to R0.

Collision With Food

Collision is extremely simple in Vircon assembly and can be done in just 20-ish lines. To start, we need to store our X and Y values of our snake head into temp registers so they do not get destroyed. We will first start with finding the position difference between the snake head and food (for me, an apple). Here is what that looks like:

    ; Collision Detection
    mov R10, R2 ; Snake head X
    isub R10, R14 ; Subtract apple X
    iabs R10 ; Absolute value of X difference
 
    mov R11, R3 ; Snake head Y
    isub R11, R15 ; Subtract apple Y
    iabs R11 ; Absolute value of Y difference

From the code snip above, we first store our X and Y values in temp registers that will get destroyed later on. Then we calculated the difference. It does not matter if the result is negative or positive because we take the abs value. We take the absolute value because the difference in position is a difference. It's hard to explain but it just needs to be the abs value (Someone please step in and make this clearer. I cannot figure out how to say it).

Next, we want to check if the snake head comes in contact with the food. Here is what that looks like:

    ; Check if within 30 pixels
    ile R10, 30
    jf R10, _no_collision ; If false then go to _no_collision
 
    ; Check if within 48 pixels
    ile R11, 48
    jf R11, _no_collision ; If false then go to _no_collision

Here, we are simply just checking the difference we got for the X and Y values and then either jumping out of this check because they are not in contact or falling through to what will happen if we are in contact with the food.

Text Area
Data
Registers

Vircon has 16 registers (0-15) with 14 and 15 being reserved for stack purposes.

  • Registers are used to store values/data in.
  • For example in R0 we are storing a value of 1.
  mov R0, 1
  • We can also modify the values in R0.
  iadd R0, 1
  • This will make R0 = 2.

A register will also store a “yes” or “no” value from certain operation like IGE, which is “Integer Greater Than or Equal To”.

  ige R0, 1
  • This checks if R0 is greater than or equal to 1. If so it returns a 1 for true which will then be stored in R0 and the 2 will be lost forever.
  • But if you wanted to save the 2 in R0, before the “ige” you could copy R0 into another register:
  mov R1, R0
  • This will copy the 2 in R0 to R1.
  • ILE is similar but checks if R0 is less than or equal to 1.
  ile R0, 1
Instructions

Instructions are things that can be done to effect registers, memory addresses, and where you are in your code. There are many different types of instruction sets, for example:

  • The previously demonstrated “iadd” is part of the “int arithmetic” instruction set.
  • The also previously mentioned “ige” is part the “compare” instruction set.
  • The instruction “jt” which is part of the “branch” instruction set goes hand and hand with any “compare” instruction and that when properly used will change where the program will go next.
  • Most importantly there are the “control” instructions “hlt” and “wait” that will effect what the program is doing at that current instant by either stopping the program or pausing it.
 

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:cta0:final tally of results (130/130)
*:cta0:implementation by hand in Vircon32 assembly [91/91]
*:cta0:clarifying comments throughout [13/13]
*:cta0:assembles cleanly with no warnings or errors [13/13]
*:cta0:source and project resources tracked in 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
haas/spring2024/comporg/projects/cta0.txt · Last modified: 2024/02/17 08:55 by 127.0.0.1