Table of Contents

Corning Community College

CSCS2650 Computer Organization

PROJECT: Move The Block (MTB1)

OBJECTIVE

Here, we take our working C version from MTB0, and from scratch, by hand, write an assembly-equivalent version.

EDIT

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

MTB1

Only task headings have been provided. You are not expected to know how to do the task given by just that description (although in some cases it can be adequately figured out). Instead, if no further information is yet present, ASK FOR DETAILS on the discord, then contribute that clarity here.

If something is present but needs polish: spruce it up.

If something is present but is incorrect: please fix it.

This is intended to be an informative, useful document that all can benefit from.

Those with prior experience, please be mindful not to gobble up all the low-hanging fruit from the newcomers.

Design your sprites / custom texture

Specifying Texture in XML
Selecting Texture

Just like in C, selecting a texture is simple

In C to select a texture we can use:

select_texture( int texture_id );

In Assembly the process is similar, as the command is simply:

out GPU_SelectedTexture texture_id

Where texture_id is either the immediate value of the texture id, or a register containing the texture id
NOTE: To select any BIOS texture, such as the built in font, you need to use the texture id -1

Defining Region

Defining a region is where assembly becomes much less simple, as in C one can use a variety of built in functions that handle everything, whereas in assembly we have to send the GPU every value ourselves

This looks like:

out GPU_SelectedRegion #
out GPU_RegionMinX #
out GPU_RegionMinY #
out GPU_RegionMaxX #
out GPU_RegionMaxY #
out GPU_RegionHotspotX #
out GPU_RegionHotspotY #

Once again with # corresponding to an immediate value or register containing the values we want to input

Selecting Region

Selecting texture is where the Assembly code once again directly mirrors the C code, as the instruction to select a region is simply:

out GPU_SelectedRegion region_id

NOTE: if you are trying to print text, the region_id for each character is the ASCII value associated with it.
For example, to print the character '0' to the screen you need to use region_id 0x30 or 4810

Check for keypresses

Selecting joystick

Selecting a joystick is very similar to the C process and only takes one command. In C, we use:

select_gamepad( gamepadID );

Where gamepadID is the value of the gamepad you wish to select.

In assembly we use:

out INP_SelectedGamepad, gamepadID

Where again, gamepadID is the gamepad we wish the use.

Reading joystick value

Reading the joystick values is also similar to the C version, the C version is the following:

variableName = gamepad_left();

Where variableName is a integer variable

In assembly we use registers instead of variables to store the returned value

in R0, INP_GamepadLeft

Reading the other directions can be done by using up/down/right instead of left

translating read joystick value into X and Y

The value returned by the gamepad is the number of frames it has been in that state

This value can be converted into a boolean with ige:

ige R0, 0

Where R0 is a joystick direction value

After you have the boolean version, you can either use a conditional jump to a label that does whatever you want when a certain direction is pressed, or directly add/subtract the value to the x/y position

jt R0 _label

or

iadd R1, R0

Where R1 is a x/y position

Playfield bounds checking

Vircon32 screen resolution
How to check if our sprite has reached a bound

Checking the bounds of the screen can be done using greater than/less than instructions

Remember that instructions overwrite the register

mov R0, R1
ilt R0, YMIN
jt  R0, _upper_bound

and

mov R0, R1
igt R0, YMAX
jt  R0, _lower_bound

Where R1 is a the y position and YMIN/YMAX are the min and max bounds

How to limit our sprite from leaving the playfield
How to cause our sprite to wrap-around on the playfield
 

SUBMISSION

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

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:

104:mtb1:final tally of results (104/104)
*:mtb1:submitted handwritten assembly [13/13]
*:mtb1:submitted Vircon32 cartridge [13/13]
*:mtb1:submitted XML and build script [13/13]
*:mtb1:displays unique block that moves based on direction [13/13]
*:mtb1:clear and consistent labels [13/13]
*:mtb1:cartridge is NOT added to repository [13/13]
*:mtb1:an attempt at bounds check and block adjustment [13/13]
*:mtb1:committed project related changes to semester repo [13/13]

Pertaining to the collaborative authoring of project documentation

Additionally