CSC258H5: RISC-V assembly
Introduction
In the first four labs, you wrote small pieces of RISC-V assembly code to implement conditionals (if- statements), loops, functions, and arrays. In the project, we're asking you to use those skills together to build a game based on Sokoban (https://en.wikipedia.org/wiki/Sokoban) .
To complete the project, you will need to implement:
- The base requirements, which allow you to play the game.
- Two enhancements. You may use the ones we suggest or suggest your own.
- User documentation that describes how to run and play the game.
Your project is due Friday, November 10 @ 5:00 p.m. Submit both your .s (assembly program) (https://q.utoronto.ca/courses/321378/assignments/1110271) and .pdf (user documentation) (https://q.utoronto.ca/courses/321378/assignments/1110272) to their respective assignments on Quercus.
Background
Sokoban (https://en.wikipedia.org/wiki/Sokoban) is a puzzle game. The original version is played
on a grid representing a warehouse, where every square is a floor or wall. The character occupies a
floor space, and boxes are scattered across the grid, also on the floor space. Targets (also called
storage locations) are scattered on the floor. Neither the character nor the boxes can enter a wall,
and the character can push one box at a time. The goal is to push all of the boxes onto the targets.
We will mimic the core game-play. You will use a grid of LEDs to represent the board. The character, boxes, walls, and targets will each be represented by specific colors of LED (that you may choose). We will use a D-pad to control the movement of the player, and we will take a reset input on the console. Messages, such as congratulations sent on success, will also be sent to the player via the console.
Starter Code
We are providing starter code (https://q.utoronto.ca/courses/321378/files/27780714?wrap=1)
(https://q.utoronto.ca/courses/321378/files/27780714/download?download_frd=1) that provides
examples of how to generate random numbers and how to handle I/O. Your first task is to read this
code to see what facilities it provides:
- main is not implemented. It contains a sequence of TODO instructions that will guide you through
the base functionality.
- Above main, there are several memory locations reserved to store the location of the player, box,
and target location. You may wish to update these declarations later, but you should be efficient about
your use of memory. Use bytes, for example, instead of words unless you need the additional range
provided by words.
- The rand function provides a (not really) random number that you can use to set initial locations for
the player, box, and target.
- The setLED and pollDpad functions handle memory-mapped IO
(https://github.com/mortbopet/Ripes/wiki/Memory-mapped-IO) . They will allow you to turn the LEDs on
and off and to receive input from the user via the d-pad.
The last two functions are particularly interesting, and I encourage you to look at them to see how they work. We'll discuss ways to handle communication later in this course, and mapping devices into memory is a common technique. In short, input from the device is written into a specific location in memory, where your processor can request it using the normal memory interface, instead of needing to deal with the device directly. Similarly, output to the device is written to a specific location in memory, and the device will check that location to accept and process your output (its input).
Running the Starter Code
Before you run your code, you will need to configure the I/O devices. Open Ripes and select the I/O tab.
Double-click on the "LED Matrix" device to get an LED matrix if there is not already one. To the right, you should see a panel "LED Matrix 0" with parameters "Height", "Width", and "Size". Set the height and width to 8 and 8. Set the size to a value that makes it easy for you to distinguish the LEDs.
Next, double-click on the "D-Pad" device to get a d-pad if there is not already one. To the right, you should see a panel "D-Pad 0". Select it and read the instructions. No values need to be set here; they should be okay as-is.
Finally, to make sure the program runs quickly enough, use the single-cycle processor and use fast execution (the ">>" symbol). That's how we'll mark, and you should configure your processor this way as you develop the code.
Base Requirements
Successfully implementing the base requirements will give you a score of 6 / 10. The base requirements are intended to allow someone to play the game. Your program must:
- Generate a random location for the character, 1 box, and 1 target.
- Light up the correct elements of an 8x8 LED grid to represent the character, boxes, and targets. The
perimeter of the grid should be colored to represent walls.
- Read input from the d-pad and react to each of the 4 directions of the d-pad being pressed by moving the "character" and any "box" in front of them corresponding to the direction selected.
- The LED grid should update to match the corresponding state.
- Movement should be blocked by walls following the normal sokoban rules.
- Restart (by either providing a new randomly generated grid or resetting to the original) if the user
requests it. You may choose -- and should document -- how the user signals that they want a restart.
- Inform the user on the console when the box has successfully been placed on the target.
- The game should be solvable. (Updated: Sep 26)
Your program must be written in assembly and will be submitted to Quercus as a .s file. It should not be written in C and compiled to assembly.
Enhancements
To obtain full marks on the project, you must implement two enhancements -- one from each category below. Each successfully implemented enhancement will add up to 2 points to your score, to a maximum of 10 / 10. You may receive less than the full 2 points for a partially completed enhancement.
Important: At the top of your sourcecode file, add a comment (a) stating precisely which enhancements you are implementing, (b) where we can find them (line number or label name), and (c) how they are implemented. This will help the TAs find your enhancements and to gauge whether they are well designed. If they are unable to find your enhancement, it'll be marked as not being present.
The ideas below are our suggestions. If you'd like to implement a different enhancement, please post your suggested enhancement to this thread on piazza (https://piazza.com/class/llwlf8q2sw4c5/post/99) . Do so at least one week prior to the deadline. We'll respond with "Yes, it fits into category [A/B]" or "No, sorry." If a feature has been approved, you may use it, whether or not you are the one who proposed it.
Category A: Memory enhancements
Option 1: Increase difficulty by increasing the number of boxes and targets.
- This requires a change to how the boxes and targets are stored.
- The number of boxes and targets should be (theoretically) unbounded. That is: you may not assume there is a maximum of, say, 64.
Option 2: Provide a multi-player (competitive) mode.
- For full credit, the program should prompt for the number of players prior to starting the game.
- Each player should be given a chance to play the same puzzle each round.
- The program should track how many moves each player needs to solve the puzzle and should display cumulative standings (number of moves required) after the round.
Category B: Code enhancements
Option 1: Improve the random number generator by implementing (and citing in a comment) a formal
pseudo-random generation function.
Option 2: Increase difficulty by adding a time limit on the game. Display this countdown in the console
or via an LED interface.
Option 3: Generate internal walls in addition to the character, box, and target. To get full credit for this enhancement, multiple walls must be randomly generated but there must always be a path from the box to the target.
- If you are very ambitious, also generate additional boxes and targets. The puzzle should still be solvable!
- Note: This enhancement is far more challenging than the other two suggestions!
咨询 Alpha 小助手，获取更多课业帮助