Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Tobias V. Langhoff

206
Posts
12
Topics
92
Followers
158
Following
A member registered Dec 01, 2017 · View creator page →

Creator of

Recent community posts

I see, thanks. I find Playscii a little cumbersome to use with the pop-up char selector, but I guess that's one of its strengths as well!

It looks like the Extended tileset has a Rexpaint charmap, but the X3 tileset doesn't?

Perfect, found it! Thanks so much

Thanks a lot! I'm not entirely sure how I find those nodes in the UI yet, but I'm sure I'll locate it :)

Thanks for this, it's great! One question from a Blender noob: Is there a way to move/remove the reflection on the very left of the screen lens which looks like a window (?) or is that an actual part of the lens texture? Have to admit I find it a little distracting that it's always visible in the exact same spot on every image made with this :)

Looks fantastic!

One thing on my wish list is more paper distress options. Stuff like magazines and game manuals is rarely "crumbled up" completely, especially near the center of the page. Usually creases occur near the edges, when people leaf through them. Not sure how to choose how to spread it around, though. Stuff like dog ear marks would also be amazing.


While I'm dreaming I'd also love textures for the midfold:


You can still apply different palettes to different elements on the screen, even if each element only uses 1 bit per pixel. It just means that each palette can only have two colors.

As it says in the description, it's built with Multimedia Fusion 2.

Yeah I know, I've done a bit of work on it myself. It's not a decomp though, but a disassembly. The game was written in Game Boy assembly language, not C, so it can't be ported to other platforms, it has to be emulated. 

No, how would that even work?

(1 edit)

Hey! It seems that both the GB and GBC versions run fine on a regular GB (DMG), so I'm a little confused as to why there are two different versions? The GBC version and the GB version look identical to me when running on a GB.

However, the GB version doesn't seem to work on a GBC - after the initial fade, the screen remains black, so there seem to be some palette issues there. But, again, I'm not sure what the GB version is really for, since the GBC version runs on a GB.

(The reason I wanted to try the GB version on a GBC was to play around with different palettes, so that could be one reason for its existence!)

I still haven't made an XO-CHIP game, so I'm thinking of maybe doing that!

It really whips the octopus's ass

This is great! Now I can have an RPN calculator on my HP 48!

Great stuff! Really reminds me of the PICO-8 tracker.

(1 edit)

Wow. This is incredible. Imagine travelling back in time to the late 70s with this game on a tape, and showing it to the VIP community! I loved your writeup, amazing insights.

Of course, that'd be cool! https://itch.io/jam/octojam-8/rate/491494

Sorry, I have to report this submission, it breaks the jam rules by clearly not being an Octo game. It's too amazing!

Möbius Chip

I like demakes and adaptations, so that's what most of my (not very creative) ideas are so far. I hope to make an XO-CHIP game, which I haven't done so far.

This is great! And super hard!

It was completely unplayable for me with the default cursor speed, as it was impossible for me to move the cursor only one step at a time, but when I turned it down to 1 or 2 it worked great.

I wonder if it'd be possible to add mouse control, or if that'd make it too easy (navigating the cursor around with the keyboard does add its own challenge). But with mouse support and potentially a browser version for a lower barrier of entry, I think this could be a hit.

Any chance of getting a ROM download so I can play this on real hardware?

thank you!!

What build pipeline did you end up with? I also lost some work to the dreaded "loading..." message the other day (although I had backed it up manually in a gist a few days before, so it wasn't so bad). I'm mostly using VSCode, and the Octo extension seems outdated and non-functional.

I wrote an article on how to get CHIP-8 up and running on one of these beauts: https://tobiasvl.github.io/blog/chip-8-hp-48/

You are correct in that `i ` pointed to real memory locations, and that programs start at 0x200 because the CHIP-8 interpreter was using that RAM on the COSMAC VIP. However, on the VIP, the font characters weren't located in the interpreter, but in the VIP's own OS or monitor program (CHIP-8 simply reused the VIP's font). The original CHIP-8 specification didn't specify where the font was (or should be) located, so in a way it was "abstracted" away. The value of `i` after using the font opcode was, in a sense, undefined.

Modern interpreters do it differently. Somewhere along the line, people decided to put the font in the now unpopulated memory region that used to be occupied by the interpreter. After all, why not, if the spec doesn't say where it should be?

(2 edits)

Not quite; the screen memory was not located in the first 512 bytes. (Neither was the font, which was in the VIP OS.) That only contained the interpreter code itself, but no variables. On the COSMAC VIP, the 256 bytes of screen/frame buffer were located in the last 352 of the addressable memory, along with variables for the V and I "registers" and other data. This location changed depending on how much memory the VIP had, which is probably one reason it wasn't included in the spec.

There were in fact even some "hires" CHIP-8 interpreters for the COSMAC VIP, such as "CHIP-10". That was unproblematic, as long as the VIP had enough memory. Although, the way the "Pixie" video chip worked, the resolution was 64x128 instead of 128x64 (because each pixel was fewer scanlines tall).

(1 edit)

It simply wasn't part of the original interpreter spec.

Other implementations (including CHIP-48 and SCHIP) didn't put the screen memory (and other stuff) at the same locations. Any program that relies on the screen memory location would only work in that specific interpreter. (Some early CHIP-8 games for the VIP might rely on this.)

In fact, the location of the screen memory changed in the original COSMAC VIP interpreter based on how much memory the computer had, since the interpreter's variables (including the screen memory) was always lcoated at the end of the addressable memory space.

Octojam 7 community · Created a new topic HP 48

Got some hardware in the mail. Ready to play some Octojam submissions!

Looks great! Haven't heard about that game before, but it seems similar to Qix?

Very nice and simple! My best so far is 15. What Octo speed is it running at? It feels very hard to get lower than 15!

Well, there's nothing stopping you from putting code beyond the "regular" 4K of CHIP-8 memory, but XO-CHIP doesn't provide a way to jump or call code there. You can set the `i` index register to anywhere in the 64K memory space, however, so it's easy to use for graphics or audio.

Cool! Usually CHIP-8 games have the scope of a single micrograme, hehe. But it's definitely possible to cram a bunch of stuff into one game, especially if they don't need a lot of graphical assets. Even then, XO-CHIP gives you a lot of space for assets (just not code, easily at least).

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.

The jam has started! Has anyone started? Do you have any ideas?

I have a few ideas. This year my goal is to make on CHIP-8 game targeted at the COSMAC VIP, one SUPER-CHIP game targeted at the HP48 calculators, and one XO-CHIP game. I made two CHIP-8 games that ran on original COSMAC VIP hardware last year, and that was great fun. (I also like turn-based stuff and puzzle games anyway, which is well suited for that.)

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.

This sounds like a great feature!

Octojam 7 community · Created a new topic CHIP-8 keypad

I'm so stoked for Octojam, I put together a little keypad, inspired by the COSMAC VIP's keypad, to play this year's games with:

It's a BM-16A PCB and case, purchased from KPRepublic.  I had to solder in switches myself (I put in some Zealios Zilent switches I had lying around for a tactile feel). The keycaps are a DSA Mono-Color keyset for an ortholinear layout from Pimp My Keyboard (Signature Plastics); the DSA profile means the keycaps are all the same height, and the ortholinear set comes without sublegends on the numeric keys. 

I then programmed the keypad using the open source QMK firmware, and mapped the keys to the Octo layout (ie. 1234qwerasdfzxcv).

Time to play some CHIP-8 games!

Maybe pressing a key could swap between the standard and alternate palettes?