What if there was a fantasy console in a fantasy console? That's a question that I never got. Instead, I was curious to see if I could come up with a way to get some form of programming on Pico-8.
Well, here you go. The language resembles CPU instructions. The fantasy console allows up to 256 instructions in ROM and has 256 byte RAM which can be viewed at runtime.
The console itself comes with a 16x16 1-bit display and 6 buttons. All IO can be directly accessed and manipulated through RAM. For convenience, it's marked with green (display) and yellow (input) in the editor.
Also, I came up with this idea due to the Ludum Dare theme "The more you have, the worse it is". I actually did it during Ludum Dare and finished it in time. I guess it's an unofficial Ludum Dare entry :-)
Navigating the editor can be done using the D-pad (arrow keys). Most interactions are done using X.
The available interactions can be seen at the bottom of the editor.
For the sake of space I decided to use binary to display numbers. This might require a bit of getting used to but most values can be found in decimal at the bottom of the screen when interacting with a number.
Pressing X on an empty line will display all the available instructions.
After choosing one the editor might prompt for additional parameters.
Parameters always come with a value represented as an 8-bit number.
A prompt will appear to set the value of the parameter.
To remove a line of code hold the O button and press X.
To move a line of code hold the O button and move it up or down using the D-pad.
Once you're ready to try out your program navigate to the console in the bottom right using the D-pad.
The play button will start to blink. Pressing X will now start the program.
The play button will start blinking again once the program reaches the end.
To terminate the program (for example to get out of an infinite loop) press X and O at the same time.
Saving the program can be done by pressing left twice when in the rom section.
Please note that there's a limit to the size of the program which is smaller then 256 instructions. each instructions takes between 3 and 5 byte to save and a maximum of 256 bytes are saved.
Set (address value)
Sets value at address to value.
Add (address, value)
Adds value to the value at address.
Subtracts value to the value at address.
Jump (rom address)
Jumps the program count to rom address.
Jump if zero (rom address, value)
Jumps the program count to rom address if value equals zero.
Jump if not zero (rom address, value)
Jumps the program count to rom address if value equals zero (higher than zero).
Or (ram address, value)
Bitwise or value to the value at address.
And (ram address, value)
Bitwise and value to the value at address.
Not (ram address, value)
Bitwise not for value and stores value at address.
Bit shift left (ram address, value)
Shift bits to left at address value times.
Bit shift right (ram address, value)
Shift bits to right at address value times.
Call (rom address)
Jumps the program count to rom address and adds the current rom address to the program stack.
Jumps the program count the the last rom address that was added to the program stack.
Well, I hope that you folks can have a bit of fun with it. Let me know if you were patient enough to make anything!
Also, feel free to make suggestions. There's plenty of space left for more instructions if needed.
Now to create a fantasy console within your fantasy console within a fantasy console.
It will have one instruction, MADD, and the output will be a single 7-segment LED digit.
The, uh, games won't be much fun. Snake will end quite quickly.
Or, I could play Opus Magnum for eight hours straight.
@moechofe The screen is mapped from 0 to 31 (bx00011111) and each bit represents a pixel on the screen. Starting at the top left going from left to right all the way to the bottom.
The input is located at 32 (bx00100000). The first bit (right most) is d-pad left, the second bit is d-pad right and so on (The order is the same as Pico-8). The last two bits are not used.
The rest of the memory is all yours. The call stack is stored in a separate "memory bank" and not accessible.
I've just added some bitwise operations which are pretty much a necessity to be able to do anything. In a bit, I'll add bit shifting as well.
Currently in the process of trying to create a set pixel function and seeing what I need on the way. I would like to have a pixel walking around on the screen as the default program.
Micro-8 now comes with a default program.
The default program allows you to plot a line using the d-pad.
Line 2 to 13 can be used as a function to draw a pixel on the screen. The function takes a single parameter by setting the value at ram address 240. This value is the position the pixel will be drawn at.
I've also fixed several errors and added bit shifting. There was also a bug in the display which has now been resolved.
Thanks for this great game.
I will use it more frequently in the future to get closer to assembler.
My question is how high the fantasy CPU is clocked to find out how to implement a delay function to create animations.
I wonder why so few people are interested in your program
My only beef is that it's all on one screen. I'd rather have 3 swappable screens each with more clarity than all of it onscreen at once.
Also I should say I've been meaning to do something similar to this for a while now, who knows if i'll get around to it though.
It's nice you actually made it a bit more user friendly!
On my case I should had done a hex editor, output screen and that's it! ... then force the developer to assemble opcodes with a pen and paper like the very old times of computers and punch cards!
But of course all of that shouldn't be fun at all to write programs ;)
I'll recommend to get some inspiration from Chip-8 and actually have a blitter instruction, that will lift a huge weight from developer's shoulders and seriously speed things up, the very limited user program won't be busy writing graphics, the system will!
A XOR blitter alone will be fine but if SET/CLEAR are included then will be much better! Additionally it can have a fixed ROM GFX with some generic graphics (like Famicom BASIC) that the user could blit without wasting precious ROM space.
Lastly, 256 bytes of RAM is fine but 256 bytes of ROM is very small... specially when each instruction is sooo loooong... while this limitation is mainly due to the savegame space the instructions set could seriously be improved! Take a few notes from how old 8-bits CPUs like the 6502 work.
Also agreed with Davbo, it should be called "femto", "atto" or "zepto" ;)
Oh ... this really is a technical cart. Question. Is there a way to make a bouncing ball like in Atari 2600 BASIC ?
Remember it only has room for 64-commands, (64-bytes if you will) so your program may be more advanced than this.
Log in to post a comment