I don't think 12 bits parallel rom/ram exists irl, so you'll just have to use 8bits instead.

No, it doesn't exist yet, but why not try something new? I wanted to make it as narrow as possible to use only one memory cell for every single command.

If you plan making a bigger cpu, maybe use 16 bits. Or a different amount of 8 bit blocks depending on the instruction, but that will make it a bit more complicated.

That sounds cool, I might pariticipate.
Am I allowed to use techniques (e. g. a tilemapper or a savegame organizing routine) not related to any special game I developed before the start of the contest?

Instead of using a second program, you could store the maps in different appvars you can archive and unarchive in axe.
To create those appvars, it might be helpful to make a map editor.

Twice (or as often you use it). To prevent that, you can do
"text"->str1
...
text(0,0,str1)
...
text(0,6,str1)


Two things:

Firstly, I won't be able to continue any of my project for two weeks, 'cause I'm going to the USA tomorrow (school exchange, yeah!).

Secondly, I finally got my super fast (due to 8 bit assembler LUT function and coordinate transformation algorithms) flat tilemapper for any size of map ready:

 
(again, better grey on calc)

The program lets you enter the size of the tilemap (only square maps, but other arbitary formats aren't any harder to implement), then it generates some random grey/white tiles and displays it on the screen. You can scroll around with the arrow keys.

Wow, those are cool mappers. I think I will make it more like a flat terrain with 3D ish objects, so I do not really need to take care about the layers.
Maybe I will do the scrolling with the screen-shifting operations and only draw the tiles shifted in.

The middle one is sped up, right? I don't think TI-basic with xLib runs that fast on a 83+/84+.

now can you implement bigger cube? if you do? maybe someone can make FFT...

You can implement whatever you want. That's the strength of this method.
The problem is that you need twice as much data for an isometric tilemapper than for a normal (viewn from above, 3-level grey) tilemapper, even though the size of the tiles is the same. The cuby needs atm 48 bytes of data. If you made a flat isometric tilemapper, each (8x8) tile would need 32 bytes of data. You can imagine that an 8x8x8 pixel rough terrain tile or a character would need then 64 bytes.

I'm now gonna try to make a flat tilemapper.

Here's the download:

Keys:

Horizontal cursor movement: vertical cursor movement: Add block: Remove block: Clear all: Calculate random terrain (in progress):   Exit without deleting:

Keypad 7|8|4|5 (just like the directions in the space) + (deeper) - (higher) 2nd (Hold and move for staight lines) ALPHA DEL MATH CLEAR

Because of the lag if there are many blocks, you sometimes need to hold a key instead of just a short click.

The model is saved to the first 64 bytes of L1, so it stays if you leave.
The Axe app and other programs use this space, so you can get some interesting shapes (e.g. if you compile).