Table of Contents

Corning Community College

CSCS2650 Computer Organization

Testing and Investigating Computing (ticX)

Objective

To immerse yourself in relevant and important aspects the nature of the CPU, utilizing it to implement experiments and other activities, and getting to play with all of it under the guise of a simple system.

Task

Each week, throughout the semester, the aim will be to focus on various activities related to implementing some functionality pertinent to this class (to be implemented and run in the TIC80 simulator):

The overall aim is to enable you to challenge yourself, explore areas and concepts you are not familiar with, and grow as a programmer and problem solver. I don't want to see you just doing things the way you are familiar with (simply because you've always done them that way).

The outline of semester progress:

week project chapter points per item (PTS) TOTAL
2 tic2 snake demo in TIC80 1 13
3 tic3 create a pong game 2 26
4 tic4 extend to breakout game 2 26
5 tic5 palette and persistence 3 39
6 tic6 full palette setting 3 39
7 tic7 time-enhanced colors 4 52
8 tic8 choice: TIC80 game or NES game 4 52
9 tic9 continuation of choice 5 65
10 ticA continuation of choice 5 65
11 ticB continuation of choice 6 78
12 ticC completed game 6 78

topic: palette and persistence

Through playing with memory via the peek and poke functions and referencing the TIC-80 memory map, we can effect run-time and automatic changes to facilities in TIC-80 without needing to manual set something in the development environment.

Two items of focus here:

I want you to make a color setting program in TIC80, one that lets the user set the color of one palette color (you can pick which one, aside from #0, that you'd like to target).

On the TIC80 screen should be the following information:

Controls:

On program startup: read the red/green/blue values from persistent memory (the very first time, it'll probably be 0, 0, 0), but this will allow you to “resume” where you previously were.

topic: full palette

A similar program to the first time around, but this time you will present the user with full control of the entire palette (all 16 colors). Individual R/G/B component settings, individual palette colors. Save/load to persistent memory.

Also, I'd like further sophistication to definitely be present, not just some rudimentary up/down to select component, left/right to adjust -/+ by some value.

Implement red, green, blue mouse sliders (some line that you can click and drag, or click on some point: and the point on the line represents the 0-255 value). Sort of like how you'd find in some graphics program.

Exposure to mouse stuff is important to know, so yeah: there we go.

topic: timing the palette to get more colors

The nature of TIC80 in mimicking classic hardware designs is that of a fixed, and often reduced, color palette. 16 colors definitely fits the bill.

But, similarly, there were opportunities on old machines, just as there are with TIC80, to take advantage of the ability of knowing where we are in the drawing process, to strategically set the palette, allowing for 16 distinct colors… on a given line or lines. So, 16 unique colors on any given line, but line-to-line, those 16 colors do NOT have to be the SAME 16 colors.

This allows for 16 colors x 136 lines = 2176 total colors displayable on the TIC-80 screen.

We don't need to go THAT far (not to 2176), but I would like you to write a TIC80 program that displays in any given frame, at least 48 colors, in some manner conducive to enhancing the user-experience (ie the additional colors make it better than if there were only 16).

Maybe a mock-up of a game: score and level data banner at the top in one color scheme, main game view in the middle, and player stats banner on the bottom. Each slice adhering to a different color palette.

Or enhance your breakout game to have many many more brick colors…

Might be worth checking: https://github.com/nesbox/TIC-80/wiki/palette

And, it should be beyond obvious: don't just lift tutorial code you find and pass it off in its entirely (with author comments stripped) as your own. You can refer to examples, but I want the final program you submit to be an effort all your own.

topic: a bigger TIC-80 game experience

We have spent some time exploring the basics of memory access, peripheral control, and resource manipulation across various aspects of TIC-80. We now move into a larger phase where you bring it all together in some larger, original creation.

You are to implement over the next span of weeks, a more sophisticated game of sufficient detail and utilization of TIC-80 resources that is commensurate with the timeframe involved and experiences gained.

There will be 5 checkpoints that you will submit prototype/draft versions of your game (each week):

Aspects that need to be present in your finished product:

The game can be based on an existing one (a tetris clone, a doom implementation, etc.) but the code should be your own, and it should be sufficiently involved for a multiple week effort.

It should go without saying: the code you write should be your own. Don't copy anything.

It should also go without saying: you are to be submitting code. In earlier weeks it doesn't necessarily have to be complete or even functional, but you are communicating your progress through submitted code and any commentary you provide.

topic: switching this up and coding in assembly on the NES/6502

For those that want to dive a little deeper into the inner-workings of how a computer works, you can elect to diverge from the TIC80 path for this next set of projects, and instead learn and implement a simple game in 6502 assembly for the NES.

The game can be something like breakout, asteroids, dig dug, etc. or some original idea, but does not have to be as expansive as the multi-week TIC80 game effort.

NOTE: the game cannot be pong, hopefully for obvious reasons.

To start, check out the Nerdy Nights tutorials:

Do note: the aim here is to learn 6502 ASSEMBLY LANGUAGE for the NES, creating ROMs to run in an NES emulator.

There will be 5 checkpoints along the way where you will submit a snapshot of what is being explored/worked on. Note that unlike the big TIC80 effort, each weekly snapshot does not have to pertain to the final game being pursued; the early weeks could be prototype code/explorations, but variations if using whatever runnable content exists in a tutorial (ie don't just submit a ROM of something all the code has been given for).

It should go without saying: the code you write should be your own. Don't copy anything.

It should also go without saying: you are to be submitting code. In earlier weeks it doesn't necessarily have to be complete or even functional, but you are communicating your progress through submitted code and any commentary you provide.

Submission

TOTAL:ticX:final tally of results (TOTAL/TOTAL)
*:ticX:assimilate indicated and related content [PTS/PTS]
*:ticX:asked, responded, worked through any questions [PTS/PTS]
*:ticX:reveal of interesting insight, knowledge gained [PTS/PTS]
*:ticX:discussion regarding content, related resources [PTS/PTS]
*:ticX:experimentation, playing, reporting insights gained [PTS/PTS]
*:ticX:state what your code is going to do [PTS/PTS]
*:ticX:implementation of example or your own variant [PTS/PTS]
*:ticX:contribute content to class notes page [PTS/PTS]
*:ticX:no warnings, compiler notes for code [PTS/PTS]
*:ticX:no syntax errors in code [PTS/PTS]
*:ticX:no logical errors in code [PTS/PTS]
*:ticX:no runtime errors for code [PTS/PTS]
*:ticX:submitted code aligns with intent, author statement [PTS/PTS]

Additionally: