Up/Down/Left/Right - move North/South/West/East
Z - Interact (Use / Pick up)
X - Use Item
As part of the coming of age ceremony of your village, you are tasked with defeating the vile dragon atop the mountains north of town.
Your quest may be more complex than most as you were born blind, deaf, without the sense of touch, and without the ability to feel pain.
However, don't let that dissuade you! Where your senses fail you, perhaps your sense will prevail!
And so - your quest begins!
I didn't know about that notation for setting the 0th element of an array, thanks for that insight.
No idea about the rest though - is this, combined with your other cart, some sort of 'hack this cart' metagame?
I'm intrigued if so, but also far too lazy to think too hard about it right now.
Some neat ideas in here! Going just from code review:
It's a tiny CPU with 23 operations, instructions and data in a self-modifiable addressable memory region, an accumulator (a), a flag (b), an instruction pointer (p), and a stack pointer (s). The data region holds bytes, with little-endian encoding of 16-bit values. The registers are 16 bits wide. The stack is technically stored in the data region but at negative addresses. (Improperly handled it code corrupt the program. :) ) Operations are encoded in the data region as 0-22 x 2 + 0 or 1, where the lowest bit is an addressing mode (0: immediate, 1: dereference).
This cart does not have access to the Pico-8 addressable memory region (no peek or poke), nor does it invoke graphics or sound primitives. This leaves this cart blank and silent. It can read input of at least one form, possibly more depending on how the stat instruction is invoked.
The most significant feature is its ability to load() other carts from the BBS by cart number. The load operator is t. You call it with a data address in a. The address points to two 255-terminated strings using a 17-element character set. The first string is the filename, or more likely a BBS cart number ("#123"). The second string is the load "param" accessible in the cart being loaded with stat(6). This implies that this machine navigates between multiple carts, possibly each with their own ability to load other carts and pass data between them. While this cart can't display anything or make noise, any of the others could.
[Update: removed erroneous paragraph about the cart not working on the BBS]
Haven't tried it yet though. More fun to stare at it first. :)
... Unfortunately the uploaded .p8.png of the cart is broken! The BBS displays the code region just fine, but when I load it into Pico-8 proper I only get the first dozen or so chars in the code region. It works if I copy-paste the code from the BBS into a cart.
Now that I'm actually trying it, this looks like a silent dark maze, and the load() is probably just the reward screen. It stays a black box until solved. This is, of course, implied directly by the story in the description. :)
[Update: removed paragraph about load() not working on the BBS]
It's seems like I'm not supposed to solve this just by pressing buttons and I actually need to disassemble the data region. That'd be fun but not right now. :)
Cool! I guess that makes some sense. I just assumed that all "disk" access was disabled in the web player.
Note that when I say the "cart" is broken on the BBS, I mean there's something wrong with the .p8.png download if I click "Cart". The result I get is missing nearly all of the code. If the cart is working in the BBS web player, I can't tell because I haven't solved it yet.
P.S. I woke up this morning to the realization that flip() is necessary to get btn() results to change, and to slow down the cart. I wondered about it before considering there's no graphics to display.
Poked at this some more.
There's definitely a death condition that manifests as an infinite loop and no further interaction at address 1939. To make this remotely playable I added a visual death indicator, a pause, and an automatic reboot (run()) when p==1939. Death happens at some map locations, and always happens after 43 moves even if you walk back and forth between two safe spots or just hit x 43 times.
Assuming that's intentional and not a bug, it looks like you have 42 moves before the dragon torches you. The path to the north (toward the dragon) is treacherous and probably needs to be mapped through trial and error. From the start I can walk 42 paces west, east, or south before dying.
Thinking that I might try to disassemble the program as part of the solution, I added range checking in case it tries to modify itself via memory write or stack corruption. I haven't found any stack corruption yet but it's definitely writing to the pre-initialized memory region for some stuff, and writing above it for others. For example, it appears to write to address 621 while I arrive on certain tiles, so maybe those tiles have items or interactables. I may try capturing and visualizing all memory writes.
I also added a memory display for addresses above 5900. 5908 is the move counter. 5906 and 5907 are used to store and debounce the btn() calls in the input loop. Plenty to play with here.
I barely started disassembly but I have the cart itself printing instructions it executes. I mute the output between 1726 < p < 1787, which is the input loop, so it only prints responses to button presses. So far I don't see any real-time state changes within the input loop, but don't hold me to that. (There may be other input loops in here!)
Anyway, I assume this is how this game is meant to be played. I don't see any other way to play it. Fun for nerds. :)
[Please log in to post a comment]