updating ntr1 project page to include link to mages book

-Please take some time to read the "UNIX FOR THE BEGINNING MAGE" PDF that

-is available for download off the course homepage.

-On GITHUB, under the account your provided to the instructor, create a

-new **private** repository by the name of the current SEMESTER.

-current SEMESTER. For example, if the semester is `spring2026`, that

-would be an ideal name for your new repository.

-It is suggested you create subdirectories at the base level of this

-# CSCS2650 Computer Organization

-

-# PROJECT: btt0

-

-## OBJECTIVE

-

-Our explorations this semester will target the `Vircon32` fantasy

-console, an Open Source 32-bit emulator with development toolchain.

-

-The purpose of this project is to ensure everyone in the class gets the

-latest version of `Vircon32` built, installed, and running on their local

-development system.

-

-## REFERENCE

-

-Be sure to check out the [Vircon32 Assembly Reference](https://github.com/g7n-org/v32ref), especially its [Internet Resources](https://github.com/g7n-org/v32ref?tab=readme-ov-file#internet-resources) section to facilitate finding the needed `Vircon32` archives.

-

-## TASK

-

-Download the latest SOURCE CODE release of the `Vircon32`

-**ComputerSoftware** repository (latest version as of writing is

-**v25.10.29**). Either grab that (or any newer release), or clone the

-**ComputerSoftware.git** repository (which should be as new or newer than

-the latest release).

-

-NOTE: If you are running a release OLDER than **v25.10.29** you will want

-to update, as there were some important bugs resolved and updates with

-this release.

-

-Please do **NOT** place the `Vircon32` SOURCE CODE in any of existing

-repository (not your SEMESTER repo, not the class repo). Place it

-someplace entirely independent of version control.

-

-Reading the provided `README`, go through the build process (installing

-any needed supporting packages) to build `Vircon32` FROM SOURCE and then

-INSTALL it on your local system.

-

-Once you have a working, installed `Vircon32` (**DesktopEmulator** AND

-**DevTools**), grab the "Hello, World!" C example available on lab46 as a

-grabit, and test things out (build it, run the cartridge, verify it all

-works).

-

-Then, modify that "Hello, World!" C program in some meaningful way,

-verify it still builds, runs, and works as expected.

-

-You will be submitting that `C` SOURCE file, the supporting `XML` file,

-along with the built `v32` cartridge file.

-

-### SUBMISSION CRITERIA

-

-```

-52:btt0:final tally of results (52/52)

-*:btt0:grabit of project files before Sunday prior to due date [13/13]

-*:btt0:adequate modification of source code beyond default state [13/13]

-*:btt0:code compiles cleanly, cartridge builds with no errors [13/13]

-*:btt0:the C SOURCE, XML, and v32 cartridge files submitted [13/13]

-```

-

-Additionally:

- * Solutions not abiding by spirit of project will be subject to a 25% 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 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

-# CSCS2650 Computer Organization

-

-# PROJECT: DEBUG A PROGRAM (dap0)

-

-## OBJECTIVE

-

-Create a simple debugging output routine to help investigate issues in

-program logic.

-

-## TASK

-

-Implement a Vircon32 assembly subroutines that displays the 32-bit

-hexadecimal value of an indicated item to the display at a provided set

-of coordinates (supplied via the stack).

-

-Specifically, you want to call the subroutine **`_debug`**, and place it

-in a file called **`debug.s`** so that you can **`%include`** it as

-needed in your debugging efforts.

-

-It is written entirely in Vircon32 assembly language, using no

-compiler-generated routines from the Vircon32 API (no **print**, no

-**itoa**)- you want to create whatever supporting routines are needed.

-

-Pass 3 parameters via the stack:

-

- * value to display (first added)

- * X coordinate (second added)

- * Y coordinate (third added)

-

-Be sure to preserve all register and important system states (ie whatever

-was going on before the call to debug must be preserved: save and

-restore)

-

-Make use of the stack instructions **PUSH** and **POP**, although all

-stack access does not have to exclusively be via **PUSH** and **POP**.

-

-Utilize bitwise logic in the process to convert each nibble of data into

-the value/region you will display

-

-Try it out on some existing code, posting a screenshot (with context) to

-the class discord.

-

-Provide usage instructions (what needs to be added to existing code to

-use your debug subroutine)

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/comporg/dap0$ make submit

-```

-

-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:

-

-```

-182:dap0:final tally of results (182/182)

-*:dap0:submitted file called debug.s or debug.asm [13/13]

-*:dap0:subroutine is called _debug or __debug [13/13]

-*:dap0:code assembles with no warnings or errors [13/13]

-*:dap0:parameters obtained via the stack [26/26]

-*:dap0:register states preserved across call [13/13]

-*:dap0:debug subroutine uses the stack [26/26]

-*:dap0:process utilizes bitwise logic [26/26]

-*:dap0:screenshot of subroutine in action to discord [13/13]

-*:dap0:code contains usage instructions in comments [13/13]

-*:dap0:output contains display of contents at coordinates [13/13]

-*:dap0:functionality is correct and to specifications [13/13]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: DEBUG A PROGRAM (dap1)

-

-## OBJECTIVE

-

-Extend our debugging infrastructure with the creation of a

-**`_debugmemory`** subroutine.

-

-## TASK

-

-Implement a Vircon32 assembly subroutine that uses your dap0 **`_debug`**

-subroutine. Your task is to display a range of memory addresses, along

-with their hexadecimal contents.

-

-The starting and ending memory addresses are given as parameters via the

-stack.

-

-Specifically, you want to call the subroutine **`_debugmemory`**, and

-place it in your existing **debug.s** file so that both can be

-**%include**'ed as needed in debugging efforts.

-

-It will call **`_debug`** in the process of operation (let **`_debug`**

-handle the display of information)

-

-Of course: written entirely in Vircon32 assembly language, using no

-compiler-generated routines from the Vircon32 API (no **print**, no

-**itoa**, only the routines YOU write)

-

-You will pass 2 parameters via the stack:

-

- * starting address (first pushed)

- * ending address (second pushed)

-

-You want to make sure all register states preserved (ie whatever was

-going on before the call to debug must be preserved: save and restore)

-

-Make use of the stack instructions **PUSH** and **POP**, although all

-stack access does not have to exclusively be via **PUSH** and **POP**

-

-Try it out on some existing code, posting a screenshot (with context) to

-the class discord

-

-In your code (via comments), provide usage instructions (what needs to be

-added to existing code to use your debug subroutine)

-

-Modify **`_debug`** to "return" an updated X and Y coordinate (by

-updating the value stored in the stack), so that **_debugmemory** can

-**POP** and use it in its own processes.

-

-Make sure to display any leading zeros in your output.

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/comporg/dap1$ make submit

-```

-

-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:

-

-```

-234:dap1:final tally of results (234/234)

-*:dap1:submitted file called debug.s or debug.asm [13/13]

-*:dap1:subroutine is called _debugmemory or __debugmemory [13/13]

-*:dap1:code assembles with no warnings or errors [26/26]

-*:dap1:parameters obtained, modified in the stack [26/26]

-*:dap1:register states preserved across call [26/26]

-*:dap1:debugging subroutines use stack instructions [26/26]

-*:dap1:screenshot of subroutine in action to DISCORD [26/26]

-*:dap1:code contains usage instructions in comments [26/26]

-*:dap1:output contains display of addresses, contents [26/26]

-*:dap1:functionality is correct and to specifications [26/26]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: DEBUG A PROGRAM (dap2)

-

-## OBJECTIVE

-

-Extend our debugging infrastructure with the creation of a

-**`debugregs`** subroutine.

-

-## TASK

-

-Implement a Vircon32 assembly subroutine that uses your dap0 routine.

-subroutine. Your task is to display the set of CPU registers (R0-R13),

-along with their hexadecimal contents.

-

-No parameters need to be given to this debugging subroutine, since it

-will always be displaying this same range of registers.

-

-Specifically, be sure to:

-

-... call the subroutine **`debugregs`** or **`_debugregisters`**, and

-place it in your existing **debug.s** file so that both (and also

-**_debugmemory** from dap1) can be **%include**'ed as needed in debugging

-efforts.

-

-Make sure it that it calls and makes use of your original **_debug**

-in the process of operation (let **_debug** handle the display of

-information).

-

-That it is written entirely in Vircon32 assembly language, using no

-compiler-generated routines from the Vircon32 API (no **print**, no

-**itoa**)

-

-As stated above: no parameters need to be passed in to use this routine.

-

-Pertaining to the registers, make sure your routine preserves existing

-register states, so that whatever was going on before the call to debug

-is saved, so you can restore it upon completion).

-

-Display registers R0-R7 in the left column, starting at or near the top

-left of the screen, with R8-R13 in the right column, separated by an

-appropriate distance.

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/comporg/dap1$ make submit

-```

-

-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:

-

-```

-286:dap2:final tally of results (286/286)

-*:dap2:submitted file called debug.s or debug.asm [26/26]

-*:dap2:subroutine is called _debugregs or __debugregisters [26/26]

-*:dap2:code assembles with no warnings or errors [26/26]

-*:dap2:register states preserved across call [26/26]

-*:dap2:calls upon original _debug to do data output [26/26]

-*:dap2:output contains display of registers, contents [52/52]

-*:dap2:screenshot of subroutine in action to DISCORD [26/26]

-*:dap2:code contains usage instructions in comments [26/26]

-*:dap2:output contains display of addresses, contents [26/26]

-*:dap2:functionality is correct and to specifications [26/26]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: GAME SNAPSHOT (gamE)

-

-## OBJECTIVE

-

-Snapshot of progress on the EoCE game

-

-## TASK

-

-As per the EoCE, we are implementing a game in Vircon32 assembly

-language; while the game is not expected to be done by this point, active

-participation in its development is to be underway.

-

-Commits and contributions will be looked at to make sure everyone is

-pulling their own weight.

-

-Having some sort of viewable / playable thing wouldn't hurt (although

-that depends on overall development progress).

-

-## SUBMIT

-

-While no format submission is necessary, be sure that your repository

-activity is such that it can be clearly discerned that you are active and

-documenting of your contributions and progress.

-

-## RUBRIC

-

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

-

-```

-312:gamE:final tally of results (312/312)

-*:gamE:multiple commits pertaining to the game in class repo [156/156]

-*:gamE:contributions documented commit messages [156/156]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: MOVE A BLOCK (mab0)

-

-## OBJECTIVE

-

-This week we turn our attention to starting to write (from scratch) code

-in Vircon32 assembly language.

-

-We will start with the most basic of ingredients: render a block on the

-screen, and allow it to move via the gamepad.

-

-## GRABIT

-

-There is a GRABIT available, containing some skeleton code, an XML file,

-and a Makefile, that will facilitate building the cartridge.

-

-## TASK

-

-Implemented from scratch, in assembly:

-

- * select the loaded texture

- * select 4 objects (regions) to display

- * display the object on the screen, allowing for its control via the gamepads

- * each gamepad direction should display a different object

- * implement bounds checks on the screen edges, preventing the object from moving off the screen (or performing a wraparound, as desired)

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/DESIG/mab0$ make submit

-```

-

-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:

-

-```

-78:mab0:final tally of results (78/78)

-*:mab0:code written from scratch in Vircon32 assembly [13/13]

-*:mab0:code assembles cleanly, with no warnings [13/13]

-*:mab0:submit code, XML file, and v32 cartridge [13/13]

-*:mab0:program displays one of four regions based on direction [13/13]

-*:mab0:program reads the gamepad to adjust position of region [13/13]

-*:mab0:region when encountering screen edge will stop or wrap [13/13]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: MOVE A BLOCK (mab1)

-

-## OBJECTIVE

-

-This week we extend upon our simple block movement program, turning it

-into a fully functional one-player `PONG` game, hand-written in Vircon32

-Assembly Language.

-

-## GRABIT

-

-There is a GRABIT available, containing some skeleton code, an XML file,

-and a Makefile, that will facilitate building the cartridge.

-

-## TASK

-

-Implemented from scratch, in assembly:

-

- * have texture(s), regions for a paddle and a ball

- * have the ball rebound, continuing in one direction until it hits a bound

- * bounds can be the top, bottom, or side of the screen (which it will reflect off of)

- * bounds can also be the paddle (which it will also reflect off of)

- * paddle bounds are the edges of the screen (prevent it from getting lost off the screen)

- * if the paddle fails to deflect the ball and the ball moves beyond the screen, reset the ball and start again

- * display the paddle and ball on the screen, allowing paddle control via the gamepad

- * two gamepad directions will be necessary for moving the paddle

- * implement a simple scoring system and display

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/DESIG/mab1$ make submit

-```

-

-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:

-

-```

-104:mab1:final tally of results (104/104)

-*:mab1:code assembles cleanly, with no warnings [13/13]

-*:mab1:submit code, XML file, and v32 cartridge [13/13]

-*:mab1:paddle displays, position adjusted by gamepad [13/13]

-*:mab1:paddle is bounded by screen edges [13/13]

-*:mab1:paddle can deflect ball [13/13]

-*:mab1:ball moves automatically, resets if it goes off screen [13/13]

-*:mab1:ball deflects off screen edges [13/13]

-*:mab1:game keeps and displays score [13/13]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: MAKE A BREAKOUT (mab2)

-

-## OBJECTIVE

-

-Now, take your `PONG` game, and transition it into a `BREAKOUT` game,

-where in addition to the paddle and ball, there are bricks present on the

-screen (either in rows or some pattern). The ball when colliding with a

-brick will rebound off of it (just as if it were a wall or paddle), but

-cause the brick to disappear.

-

-## GRABIT

-

-There is a GRABIT available, containing some skeleton code, an XML file,

-and a Makefile, that will facilitate building the cartridge.

-

-## TASK

-

-Implemented from scratch, in assembly:

-

- * use more than just the BIOS texture for graphics

- * have texture(s), regions for a paddle, brick(s), and a ball

- * have the ball rebound, continuing in one direction until it hits a bound

- * bounds can be the top, bottom, or side of the screen (which it will reflect off of)

- * bounds can also be the paddle (which it will also reflect off of)

- * bounds can be any of the bricks (which it will reflect off it, causing the brick to disappear)

- * paddle bounds are the edges of the screen (prevent it from getting lost off the screen)

- * if the paddle fails to deflect the ball and the ball moves beyond the screen, reset the ball and start again

- * display the paddle and ball on the screen, allowing paddle control via the gamepad

- * two gamepad directions will be necessary for moving the paddle

- * display the bricks on the screen, allowing for collision with the ball (if present/visible)

- * implement a simple scoring system and display (hitting and destroying a brick)

-

-Feel free to add some frills:

-

- * power-ups

- * different brick colors

- * sound effects (ball hitting paddle/bricks)

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/DESIG/mab2$ make submit

-```

-

-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:mab2:final tally of results (130/130)

-*:mab2:post screenshot or short video of game in class channel [13/13]

-*:mab2:code assembles cleanly, with no warnings [13/13]

-*:mab2:submit code, XML file, and v32 cartridge [13/13]

-*:mab2:paddle displays, position adjusted by gamepad [13/13]

-*:mab2:paddle is bounded by screen edges [13/13]

-*:mab2:paddle can deflect ball [13/13]

-*:mab2:ball moves automatically, resets if it goes off screen [13/13]

-*:mab2:ball deflects off screen edges, paddle, or bricks [13/13]

-*:mab2:brick disappears upon collision with ball [13/13]

-*:mab2:game keeps and displays score [13/13]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: PRIME NUMBER COMPUTATIONS (pnc0)

-

-## OBJECTIVE

-

-Start exploring algorithm/implementation comparison and optimization with

-respect to various approaches of computing prime numbers.

-

-## GRABIT

-

-There is a GRABIT available, containing some skeleton code, an XML file,

-and a Makefile, that will facilitate building the cartridge.

-

-## TASK

-

-Implement two separate, independent programs, one in Vircon32 C, and

-other in Vircon32 assembly, that:

-

- * performs a brute force/"trial-by-division" process on a range of values, 2-N

- * the values for N are some sufficient quantity still small enough to fit within an integer

- * the values for N will have some relationship (powers of 2, powers of 10/magnitudes) that ideally can be computed via some loop/equation (ie 1024, 2048, 4098, 8192, 16384, etc.)

- * the values for N have some sufficient quantity large enough where its upper set values will take some amount of time to compute (fast enough to have some relatable value, not to exceed 16 seconds)

- * for each value of N:

- * display that N/upper bound

- * tally: display the number of primes identified (2-N)

- * display the amount of time taken to do the total computation for that value of N, out to 3 decimal places

- * display each N value and result in an arrangement on the screen that can be clearly identified and read by the viewer

- * timing should go out, as reasonable, to a few decimal places, and should be consistent across all attempts.

- * timing is on the computational process only, not the display of results.

- * create a graph (using some external tool) that plots the performance of the C and assembly implementations working on identical workloads of this brute force algorithm according to the various N's and the time it took. Share your graph of your results on the class discord and on the project documentation page.

- * a line graph is the suggested best candidate

- * the assembly version is to be done entirely by hand, and make zero use of C API functions. Just the usual in/out stuff we've been doing.

- * this will not be an interactive program: it starts up, does its thing, outputs it results, then halts.

- * this brute force implementation is meant as our baseline. As such, it should not contain any optimizations or attempted improvements. As we progress through `pnc1` and `pnc2`, this base implementation should be the least efficient. This is important, to allow us to realize the impact of various improvements we will be making in those upcoming projects.

-

-## REFERENCE

-

-The following are reference screenshots of what your implementations

-should approximate:

-

-### PNC0 C IMPLEMENTATION

-

-

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/DESIG/pnc0$ make submit

-```

-

-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:

-

-```

-156:pnc0:final tally of results (156/156)

-*:pnc0:submitted working C and assembly implementations [26/26]

-*:pnc0:post screenshots to class DISCORD channel [26/26]

-*:pnc0:processing is correct, and to specifications [26/26]

-*:pnc0:no optimizations or improvements on the process [26/26]

-*:pnc0:graph produced from timing data produced [26/26]

-*:pnc0:timing data is taken out to at least 3 decimal places [26/26]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: PRIME NUMBER COMPUTATIONS (pnc1)

-

-## OBJECTIVE

-

-Continue exploring algorithm/implementation comparison and optimization

-with respect to various approaches of computing prime numbers.

-

-## GRABIT

-

-There is a GRABIT available, containing some skeleton code, an XML file,

-and a Makefile, that will facilitate building the cartridge.

-

-## TASK

-

-Add to your two separate, independent programs, one in Vircon32 C, and

-other in Vircon32 assembly, functionality that:

-

- * implements functionality for the following optimizations (both in C and assembly):

- * break: breaks from trial division/brute force when a viable factor is found (break on composite)

- * odds: assuming 2 is prime, does odds-only processing (both number and factor check)

- * sqrt: only processes up through the square root point of the number being evaluated

- * implementation here include the following:

- * break

- * odds

- * sqrt

- * break+odds

- * odds+sqrt

- * break+sqrt

- * break+odds+sqrt

- * collects the same timing data with common workloads to the brute force/naive variants from pnc0

- * new variants added to the runtime graph you made in pnc0, adjusting and re-running pnc0 variants to allow for a consistent presentation of information

- * be sure to use distinctive colors/patterns to distinguish items on the graph (again, line graph is a recommended choice)

-

-## REFERENCE

-

-The following are reference screenshots of what your implementations

-should approximate:

-

-### PNC1 C IMPLEMENTATION

-

-

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/DESIG/pnc1$ make submit

-```

-

-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:

-

-```

-208:pnc1:final tally of results (208/208)

-*:pnc1:submitted working C and assembly implementations [13/13]

-*:pnc1:graph produced from timing data produced [26/26]

-*:pnc1:post screenshots to class DISCORD channel [26/26]

-*:pnc1:processing is correct, and to specifications [26/26]

-*:pnc1:working break on composite optimization [26/26]

-*:pnc1:working odds only processing optimization [26/26]

-*:pnc1:working sqrt factor cap optimization [26/26]

-*:pnc1:all variants and combinations thereof operational [26/26]

-*:pnc1:timing data is taken out to at least 4 decimal places [13/13]

-```

-

-### 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

-# CSCS2650 Computer Organization

-

-# PROJECT: PRIME NUMBER COMPUTATIONS (pnc2)

-

-## OBJECTIVE

-

-Continue exploring algorithm/implementation, this time exploring a new

-algorithm: the sieve of eratosthenes and selected optimization.

-

-## GRABIT

-

-There is a GRABIT available, containing some skeleton code, an XML file,

-and a Makefile, that will facilitate building the cartridge.

-

-## TASK

-

-Add to your two separate, independent programs, one in Vircon32 C, and

-other in Vircon32 assembly, functionality that implements the following:

-

- * sieve of eratosthenes (soe)

- * sieve of eratosthenes with sqrt optimization (soe +s)

-

-Collect the timing data and add them onto your graphs. NOTE that you may

-have to adjust your bounds, and if needed, drop the naive brute

-implementation from consideration due to the extreme gap in performance.

-

-## PROGRAM

-

-Your next program, and first sieve, will be the Sieve of Eratosthenes.

-Perhaps among the best and likely longest-known sieves, its origins date

-from antiquity.

-

-This sieve, instead of calculating to determine the eligibility of a

-prime, works in a manner of marking off patterns of values that cannot be

-prime (so, it is composite-focused in approach vs. prime-focused).

-

-In order for it to work, we must store all the values we're processing so

-we can obtain what is left when done– what remains are the prime

-values.

-

-Some refined considerations:

-

- * include memory management related to the sieve in your timing

- * take measurements out to FIVE (5) decimal places

- * consider doing a bar graph instead of line graph

-

-Please check out the [wikipedia page for the Sieve of Eratosthenes](https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes)

-

-Here is an animated image of this sieve in action (from wikipedia):

-

-

-

-## REFERENCE

-

-The following are reference screenshots of what your implementations

-should approximate:

-

-### PNC2 C IMPLEMENTATION

-

-

-

-## 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.

- * 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 and aligned

- * Code must be consistently written, to strive for readability from having a consistent style throughout

- * Code must be commented

- * Sufficient comments explaining the point of provided logic **MUST** be present

- * Track/version the source code in your private 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 (once on LAB46, with all your data

-present):

-

-```

-lab46:~/src/SEMESTER/DESIG/pnc2$ make submit

-```

-

-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:

-

-```

-260:pnc2:final tally of results (260/260)

-*:pnc2:submitted working C and assembly implementations [26/26]

-*:pnc2:graph produced from timing data produced [26/26]

-*:pnc2:post screenshots to class DISCORD channel [26/26]

-*:pnc2:processing is correct, and to specifications [26/26]

-*:pnc2:working sieve of eratosthenes implementation [52/52]

-*:pnc2:working soe with sqrt implementation [52/52]

-*:pnc2:all variants and combinations thereof operational [26/26]

-*:pnc2:timing data is taken out to at least 5 decimal places [26/26]

-```

-

-### 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