Read on Twitter
#octojam 7 is happening. About a month ago I had no idea what #chip8 was. @samccone pulled me in, and I’m enchanted 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread">
#chip8 is an interpreted language/VM from the mid-70s. But unlike any “interpreted” languages I knew, it’s just a VM with its own simple machine language. There are hardware implementations for the virtual machine. It has 16 registers, 35 opcodes, and ~4k of memory.
#chip8 worked with a 64x32 display, which is ridiculously “small” or at least rough. It’s only twice the size of original Macintosh icons in 1984, or not much bigger than your mouse pointer on a modern high-density screen. https://en.wikipedia.org/wiki/CHIP-8 ">https://en.wikipedia.org/wiki/CHIP...
But another fun thing about #chip8 is that it’s been ported to just about everything. Including the web. And even better than that, Octo is a neat high-level assembly language + editor + VM + toolkit for working with #chip8. https://github.com/JohnEarnest/Octo">https://github.com/JohnEarne...
While Octo gives some fantastic conveniences unavailable to hackers in the 70s and 80s, you still have to think within the restrictions of the screen, memory, speed, and instruction set.
October hasn’t been an easy month. And there’s only a week left. But I’m still going to try and get something in for #octojam. I’ll start by recapping some things I explored in late September:
The sample programs in Octo are really cool and worth poking around. My first example started from the default program, simplifies the movement logic and adds a walk cycle.
Here’s the full commented source, which assembles down to 172 bytes (!!!) of chip8. (Link to downloadable source TBD)
Roughly, what’s going on is that when the D key is pressed during a loop, the “dostep” procedure runs. The X-position, px, is incremented every time. And the ”i“ register is also incremented, looping from (0-7) ⨉ 15
There’s a fair bit that can be optimized here, but that’s a whole other issue. A lot of magic happens with those “sprite” instructions at the beginning and end of dostep…
sprite px py 15
draws a sprite (think image) 15 pixels tall (by 8 wide, always) at position px, py. The image is whatever the “i” register is pointing to. Our loop startsIi at :person, advances by 15 every loop until it would run off the end, then starts again at :person
draws a sprite (think image) 15 pixels tall (by 8 wide, always) at position px, py. The image is whatever the “i” register is pointing to. Our loop startsIi at :person, advances by 15 every loop until it would run off the end, then starts again at :person
The sprite instruction, backed by the chip8 DXYN opcode, will always XOR the contents of the sprite with what’s on the screen. Meaning an “on” pixel (picture element) in the data will turn on a dark pixel on the screen, or turn off a pixel that’s already lit.
Which is why in :dostep we first draw the sprite before we touch px or i. The idea is that if you re-draw the same thing twice, you will erase it. So first we erase the person, then move them (px), change their pose (i) and draw them.
But where does the image of a walking person come from? What kind of magic is that? Let’s zoom in on the first 15 values listed at :person to get a better look…
^ That’s the first pose of the walking person. It’s not very glamorous. And it’s not a good standing pose for a figure. But I like to think I did an OK job with the animation overall. So let’s drill into how that bag of numbers and letters turns into this image.
If you’re unfamiliar with hexadecimal, https://samsaccone.com/posts/demystifing-the-hex.html">https://samsaccone.com/posts/dem... is a friendly introduction.
A nice characteristic of hex is each digit represents 4 bits. So 0x18 is 8 bits, but we can think of the first and last four bits independently. If we map each bit in these numbers to a pixel (as the sprite instruction does) we can start seeing some structure.
That first row, 0x18, can also be interpreted in binary as 0b0001 1000. That image could be written out in binary instead of hex like this, and you may be able to see the underlying image somewhat. But working in binary directly can be pretty cumbersome…
… especially when Octo has a convenient sprite editor built in.
To be continued… ?
My next experiment was a simulation of a curving road.
It has two parameters: angle and curvature.
The road is drawn one row at a time, and basic calculus on the left edge of the road makes a curve. There’s slope, which is how much to shift the next row. And there’s curvature is how much to change the slope after that.
The road is drawn one row at a time, and basic calculus on the left edge of the road makes a curve. There’s slope, which is how much to shift the next row. And there’s curvature is how much to change the slope after that.
But there’s some curvatures it achieves that are more subtle than what you can get with an integer slope and an integer curve. And chip8 doesn’t have floating point numbers. The solution is fixed point arithmetic with a power of 2 scaling factor. https://en.wikipedia.org/wiki/Fixed-point_arithmetic">https://en.wikipedia.org/wiki/Fixe...
Most computers can bitshifts easily. Bit shifting is moving each of the bits in a number over some amount, e.g.
0b1110 >> 1 = 0b0111
And just like that, you’ve divided by two in one easy instructionhttps://abs.twimg.com/emoji/v2/... draggable="false" alt="😄" title="Lächelndes Gesicht mit geöffnetem Mund und lächelnden Augen" aria-label="Emoji: Lächelndes Gesicht mit geöffnetem Mund und lächelnden Augen">
14 >> 1 = 7
With << and >> dividing and multiplying by a power of 2 is easy.
0b1110 >> 1 = 0b0111
And just like that, you’ve divided by two in one easy instruction
14 >> 1 = 7
With << and >> dividing and multiplying by a power of 2 is easy.
Which is great because chip8 doesn’t have division or multiplication instructions. (On other computers I’ve worked with, it’s also useful because shifting is much faster than multiplying and dividing)
With the curving road, I just use it for division. But other fun tricks are possible, and I explored them a bit too…
For example you can keep some extra bits when doing calculations, and shift it out when doing the drawing. This means the road is calculated for a higher resolution screen, then the extra detail is thrown away, leading to smoother looking curves.
Source here, and the results are 839 byes.
https://fabiancanas.com/chip8/simple-road-curve-fcanas.gif">https://fabiancanas.com/chip8/sim...
https://fabiancanas.com/chip8/simple-road-curve-fcanas.gif">https://fabiancanas.com/chip8/sim...
