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

Corning Community College

CSCS2650 Computer Organization

PROJECT: Debug And Polish (DAP0)

OBJECTIVE

As we have been implementing our pong game, issues crop up and we find ourselves in need of debugging.

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:

  • 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
  • written entirely in Vircon32 assembly language, using no compiler-generated routines from the Vircon32 API (no print, no itoa)
  • 3 parameters via the stack:
    • value to display (first added)
    • X coordinate (second added)
    • Y coordinate (third added)
  • all register and important system 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.
  • 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)

EDIT

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

DAPX

stack operations

PUSH
POP
referencing relative to SP/BP

Preserving our Registers

For our debug to work with any given code we need to preserve everything that we may be using; part of this is to save the contents of our registers.

To do this we can set up a local stack to save the contents of our register while we use them with the instructions:

PUSH BP
MOV  BP, SP

Once we set up a local stack, we can push all of our registers onto this new stack, while still having access to the previous stack with some manipulations.

Once you have done everything you need to, you need to restore your registers and stack.
For the registers, simply pop them off the stack in reverse order, i.e if you pushed 0-13, you will pop 13-0. The stack can be just as simple as that, or more difficult depending on your approach. The simpler approach is to do the reverse of creating a local stack, that is:

MOV  SP, BP
POP  BP

Preserving our Textures

Along with preserving your register you need to preserve your texture and region, this should be done after preserving at least one of your registers, as we need to use a register to get the data to preserve.
Once we have preserved our registers, simply use the 'IN' instruction to get information from the GPU port like this:

IN   R0, GPU_SelectedTexture
PUSH R0
IN   R0, GPU_SelectedRegion
PUSH R0

And just like our registers, we need to pop them in reverse order to restore them when we're done:

POP  R0
OUT  GPU_SelectedRegion, R0
POP  R0
OUT  GPU_SelectedTexture, R0

bitwise operations

OR
AND

The AND op code will do an and comparison of two values

mov  R0,  0x00F00000
mov  R1,  0x12689649
and  R0,  R1

This code will leave us with 0x00600000 because every other value was put into and with a zero.

NOT
NAND
NOR
XOR
XNOR
SHIFT
Shift Left

A shift left can be done with the op code SHL

mov  R0,  0x00F00000
mov  R1,  4
shl  R0,  R1

This code will give R0 the value 0x0F000000 because the original value was left-shifted by 4 bits.

Shift Right

There isn't an op code provided by Vircon32 for right shifts, so we must shift left by a negative value.

mov  R0,  0x00F00000
mov  R1,  -4
shl  R0,  R1

This code will give R0 the value 0x000F0000 because we shifted the original value to the left by -4 bits.

pseudocode

debug
SET DATA
SET X
SET Y
SET POSITION TO LEFTMOST NIBBLE
UNTIL WE HAVE DISPLAYED ALL NIBBLES:
    OBTAIN NIBBLE AT POSITION
	SHOULD NIBBLE BE GREATER THAN OR EQUAL TO TEN:
	    ADD SEVEN TO ITS VALUE
	ADD FORTY EIGHT TO ITS VALUE
	DISPLAY NIBBLE AT X, Y
	INCREMENT X ACCORDINGLY
	ADJUST POSITION TO NEXT NIBBLE TO THE RIGHT
REPEAT

In your code you will want to put

%include "debug.s"

at the very end of your code. THIS IS VERY IMPORTANT. If you include debug.s at the top of your code, the hexadecimal values may print but the remainder of the program in which you called __debug may not function as expected.

debug function

Formatting

Beyond getting your values to be displayed you also need to include “0x” to signify that the number you are displaying in hexadecimal. It is important to know that the 0 and x have a number assigned to them in ASCII code which are as follows:

ASCII code for 0 --> decimal 48, hexadecimal 0x30
ASCII code for x --> 120
ASCII code for [ --> 91
ASCII code for ] --> 93
ASCII code for : --> 58

Knowing this, we can now select where we want to display these values by simply calling the following:

    mov R0, 48 ; ASCII code for 0 is moved into RO
    out  GPU_SelectedRegion, R0 ; Selecting region
    out  GPU_DrawingPointX, R2  ; Providing X axis location
    out  GPU_DrawingPointY, R3  ; Providing Y axis location
    out  GPU_Command, GPUCommand_DrawRegion ; Displaying
    iadd R2, 9 ; Spacing logic

Getting your value

Masking

We need to get a nibble on it's own, to do this we can use a bit mask

A mask only allows certain bit positions to be either 1 or 0, and forces everything else to be 0

This is done with the and operator

In order to get the most significant nibble we would want a mask of 0xF0000000 (0b11110000000000000000000000000000)

mov   R1,   0xF0000000  ; Creating the mask
and   R1,   R0          ; R0 is the original value

To get the second most significant nibble, instead of creating a new mask by hand, we can shift the old mask over by a nibble ever time we loop

We should have a register keep track of our loop count

mov   R2,   R3          ; R3 is the loop count
imul  R2,   -4          ; Left shift bits per nibble

mov   R1,   0xF0000000  ; Creating the mask
shl   R1,   R2
   
and   R1,   R0          ; R0 is the original value
Shifting
To ASCII

debugmemory function

Displaying

Because we already have the debug function, we can use that to display all of the hex values needed

The format is identical for every address, and goes as the following: [address]:value

We can print the brackets and colon manually and leave the address and values to the debug function

mov   R3,         91          ;ASCII code for '['
out   GPUREGION,  R3
mov   R3,         0           ;Xpos
out   XDRAWINGP,  R5
out   GPUCOMMAND, DRAWREGION  ;Draw

Repeat this for ']' and ':' changing the Xpos and accounting for the address width

Utilize the debug function to print the address and value as shown in the following

push  R2                      ;R2 is the current address
mov   R3,         10          ;Xpos
push  R3
push  R4                      ;Ypos
call  _debug

mov   R3,         [R2]        ;Get the value
push  R3
mov   R3,         130         ;Xpos
push  R3
push  R4                      ;Ypos
call  _debug

All of this code should be run for every address, stepping from the start value to the end value

We will need to setup a loop with an exit condition

pseudocode
MOVE THE STARTING ADDRESS INTO A DEDICATED REGISTER (current address)
UNTIL WE HAVE PASSED THE FINAL ADDRESS:
   TEST IF THE CURRENT ADDRESS IS GREATER THAN THE FINAL ADDRESS
      SHOULD IT BE GREATER SKIP TO AFTER THIS LOOP
   DISPLAY THE ADDRESS AND VALUE
   INCREMENT THE YPOS
   INCREMENT THE ADDRESS
REPEAT

debugregister function

dapX imagery

dap0

dap1

dap1

dap2

Debug Registers

Printing out R:
Printing registers
Debugging our debugregs Subroutine
Calling debugregs
 

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:

156:dap0:final tally of results (156/156)
*: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 [13/13]
*:dap0:register states preserved across call [26/26]
*:dap0:debug subroutine uses stack instructions [13/13]
*:dap0:process utilizes bitwise logic [13/13]
*: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]

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/dap0.txt · Last modified: 2025/03/01 22:29 by 127.0.0.1