Using the TIC-80 fantasy console simulator on your pi, implement a program that visually displays a range of values (lower and upper bounds adjustable by the user) that colorfully displays whether each value is a prime or composite value.

The algorithms you are to implement are during program runtime can select include the following trial-by-division-based approaches:

• none; aka brute force (naive: NO optimizations; this is what you should have accomplished in pnf0)
• break on composite (mostly brute force, but you can stop checking a number once you determine a number isn't prime, versus still having to go all the way)
• odds-only processing (with the exception of 2, all primes are odd numbers)
• square root trick (only need to check factors ⇐ the square root of the number)

Time how long it takes to execute (displaying elapsed time for the run at its conclusion; this is useful for comparisons), and display this result, especially in relation to the work load and algorithm used.

Note that the “break on composite”, “odds-only”, and “square-root” optimizations can be selectively combined for a program runtime.

That means, your program needs to support running the following modes (selectable by the user at program start):

• brute (-)
• break (b)
• odds (o)
• sqrt (s)
• break+odds (bo)
• break+sqrt (bs)
• odds+sqrt (os)
• break+odds+sqrt (bos)

But, you will want to arrange your logic so you aren't supporting eight distinct operating modes, containing mostly redundant code. Instead: ONE routine for prime processing, bringing various optimizations online or not, depending on initial selection.

Additionally, the entire class will be participating in documenting and filling out this project page. It is the responsibility of EACH class member to:

• ask copious, clarifying questions (so you can better add content)
• craft a coherent and organized document, with information located under pertinent headings
• explain the fundamentals of the process, conceptual background, algorithmic approach, and you can even suggest particulars related to TIC-80 (certain functions that might prove useful- individual, unrelated snippets to do things like capturing time, or displaying text, etc.)
• to get full credit, each individual that submits must perform no fewer than 4 changes to this document (as viewable from the wiki revision system). Failure to do so will result in documentation penalties being applied.

TIC80 works on a system of carts. The carts present on a system can be listed via a familiar call to `ls`, or, at a more involved level, the system folder which TIC80 uses to store its data can be accessed via the `folder` command in the TIC80 terminal. A new cart can be made with the `new` command, and the loaded cart can be saved via the `save` command. The code content of these cards after `load`ing them can be accessed by pressing [ESC] from the terminal, opening the included basic IDE equipped with a code, sprite, map, sfx, and music editor.

The code editor is relatively simple: 64KB are allotted for a script written in any of: Lua, JavaScript, Moonscript, Wren, Fennel, and Squirrel. External packages may also be used to allow for the usage of more languages. The first step in writing a basic program in TIC80 is to supply a series of comments (formatted in the choice language) which allow TIC80 to ascertain four pieces of metadata, as in:

-- title: PrintThing(TM)
-- author: Wedgie
-- desc: Print.. something.
-- script: lua

for Lua, or:

// title: PrintThing(TM)
..
// script: js

for JavaScript, and so on.

Once a language is selected, a developer will need to include a `TIC()` function. This is essentially the “main” function as many other programs would have, and is called automatically once the `run` command is issued on the cart 60 times per second. This can be relied on to provide synchronous 60fps display and physics or other necessary mechanics. Additionally, the `spr()`, `print()`, and `cls()` functions will prove essential. The `spr()` (Sprite) function is used to call upon sprites designed in the sprite editor and place them at some location on-screen. `print()` (Print) is more clear: this will print text directly to screen in the default font. It should be noted that the print function can also accept additional arguments for text position, size, and color. `cls` (Clear Screen) simply clears the screen of all pixel data and resets to blank.

An effective way of going about this project is to allow the prime detection algorithm to “step” once every frame. That is, by allowing the TIC() function to call the calculation of the number currently being assessed, greater functionality is easier to implement. For example, animations can be played simultaneously as the calculation occurs since the entire TIC() function is able to run without needing to wait for some checkPrime() or similar process to finish. Additionally, the various optimizations can be more consistently implemented from a user perspective since they will not affect the framerate nearly as drastically as if the entire algorithm was called during a single frame.

This can be relatively simply and familiarly implemented (at a high level) in the way that the chmod accepts permission codes. By assigning each optional optimization to a number (in binary terms, starting with 1, 2, 4, 8, 16, …) and passing the set of selected optimizations as the sum of those selected numbers, the algorithm can handle, in a way of limited individual variables, optional functions. At runtime, these can be checked from greatest to least: if the options argument is a number greater than the number corresponding to the biggest number, perform that operation, and subtract that value from the argument, then move on to the next-biggest, and so on, until the final option.
In the case of Break, Odds, and Square Root methodology, break can be 1, odds can be 2, and sqrt can be 4. If the input is then sqrt and odds, for example, and argument input would be 6. If nothing is selected, argument input would be 0, causing the brute force method.