Directions

Make sure you have Minecraft 1.7.10 and OpenComputers 1.5+ installed and working. This version only targets Minecraft 1.7.10 as that is the version I use.

Copy OpenComputers-ARM-MC1.7.10-0.0a1.jar into your .minecraft/mods/1.7.10 folder.

In a Minecraft world, preferably in Creative, set up a computer. This computer will be used to burn EEPROMs and/or write floppies.

Somehow, get tetris.rom onto that computer. For those who cannot do this easily, I have provided the files on my website, and you can put them on the OpenComputers computer by installing an Internet card and doing:

wget http://wotan.tejat.net/mcjarm/0.0a1/tetris.rom

(The same command works for boot0.rom and test.elf if you change the filename.)

Insert a blank EEPROM into the EEPROM slot of the computer and do:

flash tetris.rom

Follow the prompts, and when it finishes, remove the now-burned EEPROM from the computer. Put a new CPU (any tier) in your inventory, and shift-rightclick with it until it says its architecture is "ARM". Put this CPU, the burned EEPROM, and any tier graphics card into a new computer with any tier screen (and keyboard) attached. If you're wondering why I didn't instruct you to place RAM in the computer... that's because RAM is actually not required for this ROM!

When you press the power button, if everything is working, you will see the game draw itself (slowly) on your screen. Now, you can enjoy the laggy, slightly unresponsive experience of 10KHz Tetris! (If the pieces do not fall, turn doDaylightCycle back on.)

You may also try running test.elf with the dead simple bootloader. (It requires that the allowSerialDebugCP option in OpenComputers-ARM.cfg is enabled. Oh, and unlike tetris.rom, it does require RAM.) Copy test.elf to /boot/arm.elf on a floppy or hard disk, burn boot0.elf to an EEPROM, insert them both into a computer and start it up. CPU speed, memory map, and connected components will be outputted to your Minecraft log.

About Tetris

Like many ARM SOCs, this CPU has a built-in SRAM. It shadows the EEPROM's nonvolatile storage. With default settings, this nonvolatile storage (and therefore the SRAM) is 256 bytes in size. tetris.rom uses this for all its rewritable storage needs. In fact, it only uses 150 or so bytes of it!

This SRAM (and the EEPROM) effectively run at 10KHz, so the CPU isn't able to run any faster than that when operating this way; this is why tetris.rom is so laggy. If you want to experience a more responsive Tetris, change romLatency in OpenComputers-ARM.cfg to <1 1 1> instead of <2 10 50>; this will allow the ROM (and SRAM) to operate at the same speed as the CPU.

Custom Programs

Custom programs and ROMs are possible. Unfortunately, there isn't any documentation yet. The source archive contains the source code for the three files (tetris.rom, boot0.rom, and test.elf) mentioned here, and also the source code for the incomplete boot1.rom (which is too large to fit in 4096 bytes without Thumb).

The following limitations are still in effect:

• There is still no virtual memory or memory protection.
• Many, many instructions and control registers aren't implemented. Executing an unimplemented instruction will terminate your ROM's execution.
• Some Feature Registers are implemented, but they represent the final state of the emulator, not the current level of completion.
• Still no floating point!
• Still no persistence!

Here's what is implemented:

• All core registers, including mode-specific ones
• Almost every form of word/halfword/byte load/store
• Almost every form of multiple-word load/store, including push/pop
• Many forms of branch
• Every(?) basic ALU operation (addition, subtraction, etc.)
• Coprocessor instructions
  • CP3 provides most Minecraft-specific functions available to Lua computers (but support for userdata isn't there yet)
  • CP7 provides extremely basic character output (see test.c for usage) and on-demand CPU state dumps (CDP p7, 0, cr0, cr0, cr0, #0), but only if allowSerialDebugCP is enabled in the config
• Conditional execution
• MSR CPSR_*, #x instruction (but still not other forms of MSR/MRS)
• SMMUL, SMMULR, MLA instructions
• A few other instructions, seemingly at random
• All hardware exceptions are "implemented", in that the appropriate exception vector is called and the appropriate mode set, etc. However, they do not set the exception information registers (which do not yet exist). The exception handler is essentially blind.

Important information:

• RAM is mapped starting at 0x00000000.
• ROM is mapped at 0xC0000000, and wraps around at the nearest power of two that contains the ROM data. (For standard 4096-byte ROMs, you can pretend it is just mapped at 0xFFFF0000.)
• SRAM is mapped at 0x80000000. At power-on, it contains the values in the EEPROM's nonvolatile storage.
• The most common instructions are implemented, but many are not. Execution of an unimplemented instruction will shut down the computer and give a hopefully-informative error message. (It does NOT raise an ARM exception!)
• Try enabling allowROMDevArchitecture in the configuration file. This provides an alternative architecture (named JARM (ROMDev)) which throws an error when an exception occurs instead of processing it through the emulated ARM system. It provides a complete dump of the CPU's state in the moment the exception occurs. Check the log.