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.
OpenComputers-ARM-MC1.7.10-0.0a1.jar into your
In a Minecraft world, preferably in Creative, set up a computer. This computer will be used to burn EEPROMs and/or write floppies.
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:
(The same command works for
test.elf if you change the filename.)
Insert a blank EEPROM into the EEPROM slot of the computer and do:
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
/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.
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
<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 and ROMs are possible. Unfortunately, there isn't any documentation yet. The source archive contains the source code for the three files (
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:
Here's what is implemented:
test.cfor usage) and on-demand CPU state dumps (
CDP p7, 0, cr0, cr0, cr0, #0), but only if
allowSerialDebugCPis enabled in the config
MSR CPSR_*, #xinstruction (but still not other forms of
allowROMDevArchitecturein 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.