That's a great question!

The Chip8 virtual machine runs at an arbitrary speed. On the original COSMAC VIP, different instructions took a different amount of time to execute, and execution was generally quite slow. On modern interpreters, including Octo, this is generally abstracted to simply executing some number of instructions per frame. Octo allows you to adjust this speed by using the "Speed" top menu. (30 or less could be considered loosely "realistic" if you want your program to run acceptably on an HP-48 calculator, and the VIP is a little closer to 15.)

While we don't know how fast instructions will execute, we do have one precise timing reference: the "delay" register. If nonzero, the delay register counts down 60 times a second. Thus, if we use delay as a reference, we can make a fast-running interpreter burn off excess time, and allow our games to run at the same apparent speed. There's an example of this delay loop in the Chip8 programming techniques guide, as well as in many examples.

Like the delay register, the Chip8 display is updated 60 times a second- no matter where the program is in execution, or how much progress it has made in updating the display for the main loop. If objects are drawn in time on some frames and too late on other frames, they flicker.

So what do we do about it? Here are a few approaches:

1. Increase emulation speed. Faster updates will often outright hide flicker. Some example programs suggest an appropriate speed to be run at; if the interpreter is too slow for a program, games will get sluggish and flicker more.
2. Use a delay loop in combination with more speed.
3. Minimize how much of the display you're redrawing on each frame. Using "clear" and redrawing everything each time is usually not a good approach for an action game. Use the xor-drawing feature of sprites to erase just the parts of the display you want to change before redrawing them.
4. Minimize how long objects are erased for before being redrawn. The longer the gap between erasing and redrawing a sprite, the larger the chance it will look flickery. With specially-prepared sprites, it may be possible to "xor" the next frame of animation on top of the old one without erasing, giving buttery-smooth animation on even slow interpreters.

Yep. If your interpreter is fast enough, and your rendering will never exceed the available time, doing what you describe will work. You could also initialize the delay timer before starting a render, so you're timing render+update and then burning off any excess in the sync loop.

How much speed a game requires is mostly up to the developer. Some very interesting ideas are possible with brute force. Games that have more modest requirements will be playable on a wider range of devices. Working within the performance envelope of old hardware can be a fun creative constraint, but you're welcome to ignore it if it isn't for you.

I was just drawing a distiction between

loop
    # render
    vf := 1
    delay := vf
    # update
    loop
        vf := delay
        if vf != 0 then
    again
again

and

loop
    vf := 1
    delay := vf
    # render
    # update
    loop
        vf := delay
        if vf != 0 then
    again
again

Thanks for the tip, I'm considering targeting HP48. Quick question: Are the scrolling instructions heavy? How costly are they really? I have no idea how they work behind the scenes.

It's important to note that Octo, while allowing us to ignore some things, does also serve as a very good platform for developing games that would run on real hardware (from the eras where such hardware existed). Even though written today, this jam does typically receives a few submissions that have been created with this intent - running at realistic speeds and with the appropriate interpreter quirks. A good number of people are fairly passionate about retro computing and enjoy this aspect in particular - myself included. Sometimes the jam has been able to have the games demonstrated on the appropriate hardware, but, emulators for the specific platforms do also exist, which allow us to verify this to some degree.

To answer your question about the HP48 display - it's a little complicated? The HP48 display is updated from a buffer in the calculator's memory, but, it is on a line by line basis & spread out evenly across the entire 'frame' time - there's eg no flip() that updates the entire display all at once. The update rate for the whole display is effectively 64Hz, however the 'next' line is drawn at a rate of 4096Hz by the CPU, interrupting away from eg the interpreter as it goes, but allowing our code to run in between. This allows us to eg turn off a sprite halfway through it being drawn.

This is not quite the same as writing directly to the screen, but it shares some of the issues. The point where the line-by-line update coincides with when you 'delay' may also strobe across the display, as we have little to anchor it in place. If you might only have a sprite drawn into the buffer for eg 10% of that 64Hz tick, that may be the cause of the issues observed.

Even if that assessment is incorrect on a technical level, the strategy proposed prior has been shown to make games significantly more playable on the HP48, besides which it's generally good advice that helps keep flickering to a minimum. If any given sprite is flickering in some way, it will significantly impact its vibrancy on screen on the HP48, as the pixels aren't super quick to respond in either direction. On the plus side, it also means doing pixel queries to the display are relatively hidden.

Well, I hope that was interesting! The jam certainly attracts all sorts so, feel free to focus on the aspects that are most appealing to you!

Octo programs are assembled in one long linear pass. There are a few minor exceptions to this, like forward-referenced labels, but the conceptual model is not recursive or scoped. It works very much like a Forth.

A program is a sequence of tokens. Each statement, like "sprite" or "i := NNN", consumes some number of tokens from that sequence. The name of a previously-declared macro is a statement, (an invocation) which consumes zero or more tokens (as arguments), and then dumps a list of tokens (the macro body) into the program's token sequence, substituting arguments as it goes.  Another way to think about it is that macro invocations are always the head of a statement.

Constant expressions (inside { }) are their own separate domain from normal assembly, and macros usually only interact with them while substituting arguments as part of their expansion process. It's also worth noting that bindings created by ":calc" are global (much like aliases), and can be redefined as many times as needed over the course of assembly; they are not evaluated specially in relation to macro bodies or constrained to the scope of a macro where they appear.

Does that all make sense? Could you provide more context for what you're trying to accomplish?

Cool! I made two games last year that targeted the original COSMAC VIP CHIP-8 implementation, and I'm working on another now. Historical accuracy is definitely one of the things I enjoy most in Octojam.

"Sprite drawing trigger vblank" means that when Octo encounters a  `sprite` instruction, it will then halt and wait for the next frame is drawn before continuing execution, so drawing sprites will be a bottleneck for speed.

I think 7 or 15 cycles per frame is reasonable. It's all an approximation, of course, since in Octo all instructions take one "cycle" (AFAIK) while it varies between instructions on COSMAC VIP. Here's a table of real-world timing for each instruction.

The best approach is probably to test your game in the Emma02 emulator, which emulates the COSMAC VIP faithfully. As far as I remember it's a little hard to understand how to use it though.

It's true that self-modifying code is necessary if you want to load an arbitrary 12-bit address in one cycle. Depending on the specific circumstances, there may be simpler alternatives:

• just use `i:=NNN` to set a base address and then add an offset with `i += vx`. This is sufficient for many kinds of array indexing.
• If your array is no more than 256b and elements are wider than 1 byte, you might be able to use pre-multiplied offsets.
• If you need an array that is larger than 256b and elements are wider than 1 byte, use `i:=NNN` to set a base address and then add your offset several times: twice for 2-byte-wide elements, 4 times for 4-byte-wide elements, etc.
• If you only need to choose between a handful of 12-bit addresses, you could use conditionals or a jump table dispatched via `jump0`.

I have some examples and more discussion in the Chip8 programming techniques guide

Treat i more like a pointer. You can advance it to get to another memory location. https://johnearnest.github.io/Octo/docs/Manual.html#statements

It’s easy enough to load it (using self modifying code)… but you can’t ever retrieve it’s value (that’s hidden inside the emulator)… so if you need that type of indirection then you manually need to use your OWN external pointer and track it’s value, loading it into i when necessary… which of course is slower.

The Octo Repository has a few examples of different approaches to simple data structures and algorithms, and the FAQ has some simple examples of working with memory.

So long as the number of elements fit in a v-register, indexing into an "array" requires setting "i" to the base of the array, adding your offset, and then using load/save. A stack (FILO) requires persistent storage of the index of the top of the stack, perhaps in a reserved v-register. A queue (FIFO) is most easily implemented as a circular buffer, and requires two indices, for a "head" and "tail".