This is a space for members of the Computer Organization class to create a source of information reflective and assisting to the course.
Aside from assignments that may have you specifically perform operations here, you should contribute when you encounter any of the following:
In order to change part of persistent memory, the process begins as normal for any other piece of memory - `poke(addr, data, size)`. However, making persistent changes to the cart is a special case - since the cart is loaded into RAM (virtually and in reality) when it is run, changes made to its memory will only apply as long as it is being run, meaning something else needs to happen in order to, say, make a visual change to the editor. After making a change to the cart, the `sync()` function must be called, specifically `sync(0, 0, true)`, which breaks down into: sync(sector bitmask, bank, tocart) - in our case, sync all (0) sectors to bank zero (0), and apply the changes to the cart (true).
In addition, one can utilize the pmem() function to retrieve or save values to persistent memory without needing the pro version of TIC-80. This is how you use it: pmem(address (0-255), 32-bit value), where the value can be omitted if one only wants to read from the address. This will save value(s) across sessions on that cart, and can be used for high scores, palettes, etc. You may want to have a “reset” function for this if you plan on adjusting and saving the palette, just in case things go sideways and you want to start over.
For specific, upper-level questions (such as how to use peek() and/or poke()), it can be hard to find online resources. However, the “Code examples and snippets” section of the TIC-80 wiki has many examples that can be studied for a greater understanding of the subject matter.
It is currently understood that there is 1 kilobyte of persistent memory stored at offset 0x14004 (remember '0x' means it is hexadecimal) in memory. This persistent memory can be manipulated to one's liking as described above, and any usage of `poke()` here will have that data remain in the game cart.
TIC-80 renders the pixels on its screen using scanlines. The concept is straightforward, from the top of the screen to the bottom a scanline is rendered per each row of pixels (up to the Y position maximum).
Using the 'SCN()' function, one can manipulate the memory in TIC-80 between each scanline render as such:
function SCN(scanline) -- insert code here to manipulate pallete or other things end
One simply has to put this function somewhere in their script, it is similar to the main function 'TIC()' so it requires no additional setup. If one is familiar with modifying the palette, they can modify the palette between scanline rendering allowing for more than 16 colors (maximum colors in a palette) to render at a time.
If you choose to go the TIC-80 route from week 8 onwards, you may find it beneficial to play with the map. mset(), mget(), and map() are important tools for such an endeavor. You can use combinations of these functions to, for example, manage player collisions with environment(s). You can also use map() in addition to SCN() to display a colorful, fulfilling background without the need to manually display a bunch of sprites.
The sfx() function within TIC-80 can be used to play audio from the SFX Editor. It can adjust the note, duration, volume, etc.
mouse() returns, among others, 3 important things: the x-coordinate of the pointer, the y-coordinate of the pointer, and whether or not the mouse is being clicked. Thus,
x,y,z = mouse()
will allow you to check where you are currently clicking. This allows for the implementation of buttons for the player.
By using peek/poke, it is actually possible to make rather large global changes to both your program itself and the way it is run. Below are some examples.
0x3FF9: DrawX 0 point. By adjusting the data stored here, it is possible to change TIC80's understanding of “0” on the x axis as it draws to the screen. This means that if you set this to 120, for example, your program's visual elements would be shifted 120 pixels to the right on every frame.
0x3FFA: DrawY 0 point. By adjusting the data stored here, it is possible to change TIC80's understanding of “0” on the y axis, similar to the DrawX 0 point. Setting this to 60, for example, would shift every frame down 60 pixels.
If you're working with JS, remember that when you go to grab a constant from a library (say, pi from Math), if you forget to capitalize `Math.PI` and instead write `Math.pi` or `Math.Pi`, it will read the non-existent field without any runtime error, and instead treat it as 0. This can produce some frustratingly low-flying bugs, especially when working with games that have vector physics.