The Open Computers JavaScript arch!

No longer are you tied to using a single language for your comps.  Dominate others with the Power of JAVASCRIPT!

Download / Source / Wiki / Emulator

Features:

• Program in JavaScript
• Default EEPROM.  Drop an init.js on a floppy and go.
• That's it!

ToDo:

• Still no memory or cpu management, so definently not server safe.
• Needs an OS.
• No built in code.  You'll need to program an eeprom yourself.  This is no longer the case.  New alpha will have an usable eeprom now.

Thistle is a 6502 based architecture for OpenComputers

• Fully persistable
• Supports up to 256MB of memory via memory mapping
• Built in VT100 like terminal and keyboard input
• Built in DMA Engine
• Built in EEPROM (soon to have built in assembler (and network booting hopefully))
• Component and Signal interface via TSF Serialization
• Supports booting programs off Managed Filesystems and Unmanaged drives
• API to allow others to create 6502 friendly mappings of components

Various documentation is available on the GitHub wiki

Downloads

Source: https://github.com/gamax92/Thistle

Releases: https://github.com/gamax92/Thistle/releases

(The 1.9.4 release will also work with 1.10.2)

https://github.com/EcmaXp/OpenPython

OpenPython makes micropython available on OpenComputers.

micropython is Python for embedded devices and is different from CPython.
Currently, micropython is partially compatible with Python version 3.4 as of October 2018.

Features include:
- Fully persistable.
- Runs in a sandboxed environment and does not require a separate native DLL.
- Supports virtual file system.
- It can call other components and supports Lua architecture's UserData.

Limitations include:
- The firmware is 256 KB and the memory limit has the same limit as the Lua architecture, but the stack is allocated in a separate memory.
- Most modules are difficult to use because the battery is partially included.
- The operating system is not yet fully implemented, so the Python interpreter now runs.
- Ctrl + C is not supported, so if you accidentally run infinite repeated code, the only way to stop it is to turn the computer off and then on.

To use the Python architecture, you need the following items:
- EEPROM (OpenPython): I'm sorry, but you have to bring items from the Creative tab.
- Floppy Disk (OpenPython OS): This item can be obtained by creating a floppy disk and Scrench, or you can check it on the Creative tab.
- OpenPython CPU: You can choose OpenPython architecture by holding Shift + Right Click on the Lua architecture CPU.

It is still unstable, but we plan to make further improvements in the future.

I need help from people who are familiar with OpenComputers and Python.

Thank you for playing.

Status:

- The CPU itself is mostly complete.

- It's sorely lacking in software, although Lua 5.3.2 runs (or at least used to).

- It's got an ELF bootloader EEPROM.

- I used to be able to boot Lua off a T1 (192KB) stick of RAM when run atop Mocha + libgreen, but I accidentally broke stuff so I still need to fix that.

- The component API currently sucks. Here's a proposal that should help make it suck less for some components.

OCMIPS source: https://github.com/iamgreaser/ocmips

If you want binaries, lurk on #oc and I spit them out from time to time, although this old one might work (link is for a 1.7.10 version; github should have 1.9 stuff).

For building a cross compiler, I use binutils + gcc + newlib.

Feed "--target=mipsel-none-elf" into the configure scripts.

When building gcc, use "make all-gcc" and "sudo make install-gcc" for the first stage, build newlib, and then continue with "make all" and "sudo make install".

"--enable-languages=c,c++" should work fine. Fortran support needs to be whacked with a hammer initially so you may want to skip that unless you really need it. Other langs not tested.

Latest screenshot:

Cache works!

Mod Edit:

Pinned

~ Liz

The Minecraft 1.7.10 version can be found here, and the (very dry) documentation for both the hardware and the BIOS is here. It should build for later Minecraft versions with only minor modifications; I built it for 1.7.10 because that's the version I use. (Source code is on GitHub.)

Please report bugs on the GitHub issue tracker, though don't be surprised if it takes me a while to respond there (GitHub notifications aren't working for me). Feel free to poke me on IRC; SolraBizna on irc.esper.net or irc.tejat.net.

Features

• Total control over memory usage 
• Fully persistable
• Technically supports almost 32MiB of main memory through the MMU*
• Non-maskable watchdog timer
• Interrupts occur on signal delivery, allowing interrupt-based signal handling
• Straightforward memory mapped interfaces for disk drives, redstone, and battery
• "Serial terminal" allows basic, simple screen-and-keyboard based UIs
• Support via UIF for all components accessible from Lua, including userdata support
• Standard BIOS
  • Very basic interactive debugger, can load S-records either pasted or manually entered
  • Bootloader can boot S-records and binary images from managed and unmanaged drives
  • Basic signal handling for keyboard input, including a blinking cursor
  • Can selectively turn on/off BIOS features from booted code
• User Mode (barely tested) allows memory protection, multitasking—even total virtualization with some work
• Sync safe (only with a deadline setting of 10ms or so)
• The CPU has around 512 bytes of built-in memory, allowing simple programs to run without any RAM modules

*If you dial up the memory amount high enough, you may get disconnection errors due to an oversight in OpenComputers' API. This will hopefully be fixed soon, whether through a workaround in OCMOS or a change to OpenComputers. Memory modules are, by default, smaller than those for Lua computers; in my own testing with two tier 3.5 memory modules (256KiB), I did not experience any disconnects. Meanwhile, since the 65C02 can do so much with very limited memory, you shouldn't experience any serious problems.

Version History

0.5.2

• Architecture now has NoMemoryRequirements annotation, allowing you to build microcontrollers, drones, and robots without memory modules if all you need is the stack and zero page.
• WAI no longer spins pointlessly, and now reduces host CPU usage when called.
• Now, by default, if runThreaded runs for longer than one second without meeting the cycle budget, it will give up on doing so and briefly sleep. This prevents degenerate MMU slowdowns from ruining a world or server.

0.5.1

• Works on the server now. (The LAST change I made before releasing 0.5 broke this.)
• biosOptional option means you get the Standard BIOS even if no EEPROM is installed. This is slightly cheaty, but since there's not a crafting recipe for the Standard BIOS yet...

0.5.0

• Initial release

My idea was to make an emulator that completely follows the spec, including all or most of the devices. This would mean that existing software would work perfectly.

Development is slow as my motivation disappears and returns very briefly. One of my problems is that I can never keep working on one project for long, my interest change sporadically. But I have mostly finished the CPU itself, I haven't tested all the instructions so it's not bugfree. Currently I am working on the devices, specifically the lem1802 (the screen) and the keyboard. The screen works but currently I can't change the colour pallette or change the font(which I don't think will be possible in oc currently). The keyboard is alot more buggy, keys are sometimes doublepressed, not pressed at all, and sometimes just completely break the buffer.

It's not on github atm but if people are interested in the code I'll post the source.

I'm not working on it anymore, and that's not going to change. It's open source, so feel free to fork it and finish what I started. (Start by making things OETF #1 and #2 compliant.)

Current "stable" alpha release is 0.0a3 and can be downloaded at GitHub. If you're on a UNIX-like (Mac or Linux), you can use occross to build cross compilation tools for this architecture. Some useful programs and a build system that can be used to make more of them are also on GitHub. Lua boots, OpenOS runs, and it can mostly install to a hard disk. The whole thing is an exercise in patience; Lua does not run fast on a 500KHz machine, even at one instruction per clock. (Later, if JIT is added, one should be able to up the default speed to the order of several MHz without excessive Minecraft load.)

Missing features, in roughly the order they'd need to be added: Completed test suite, interrupts and exceptions, virtual memory.

--[==[actual program data goes in here]==]error"This EEPROM is not compatible with Lua computers"

I think we need a more general strategy for architecture-specific ROMs. One way to handle this would be to add a "na" (short for Need Architecture) function to machine.lua, and have non-Lua architecture EEPROMs take the exact form (with no extra spaces):

--[==[actual program data goes in here]==]na"Architecture Name"

The na function could be as simple as:

function na(arch)
  error("This EEPROM requires a CPU running the "..arch.." architecture.")
end

Other architectures would then parse the exact structure above, and check that the "Architecture Name" exactly matches their architecture. If it doesn't, they could crash with an error message equivalent to the above. If it does, they map the EEPROM, skipping as many bytes as are in the initial --[==[ block.

The "Architecture Name" would have to be standardized, to prevent problems. For instance, mine would likely be "OC-ARM", while the other ARM architecture might be "OpenArms".

I'd be happy to write this up as an OETF document, but first I'd like to hear how other architecture devs have handled this problem, and get feedback on this idea in general.

static const uint8_t e_ident_match[16+8] = 
	"\x7F" "ELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00"
	"\x02\x00"
	"\x08\x00" // Change this to match your architecture
	"\x01\x00\x00\x00";

struct ElfHeader
{
	uint8_t e_ident[16];
	uint16_t e_type, e_machine;
	uint32_t e_version;
	uint32_t e_entry, e_phoff, e_shoff, e_flags;
	uint16_t e_ehsize;
	uint16_t e_phentsize, e_phnum;
	uint16_t e_shentsize, e_shnum;
	uint16_t e_shstrndx;
};

struct ProgHeader
{
	uint32_t p_type;
	uint32_t p_offset;
	uint32_t p_vaddr;
	uint32_t p_paddr;
	uint32_t p_filesz;
	uint32_t p_memsz;
	uint32_t p_flags;
	uint32_t p_align;
};

#define PT_LOAD 0x00000001

For e_ident_match you'll want to change it to match the first 24 bytes of the ELF you're trying to load, assuming you compiled it correctly.

Here's how I build mocha (note the text-segment bit - this is where your ELF will be loaded):

mipsel-none-elf-gcc -nostdlib -fno-builtin-headers -fno-builtin -Os -G0 -msoft-float -Wl,-Ttext-segment=0xA0005000 -o init.elf ${CSRCS} -lc -lgcc && \
cp init.elf "${OUTDIR}/" && \
mipsel-none-elf-strip "${OUTDIR}/init.elf" && \
mipsel-none-elf-objdump -p init.elf && \
ls -l init.elf "${OUTDIR}/init.elf" && \
true

The general loading process goes like this:

1. Load the header. (Verify the things you want in there.)

2. Use e_phoff to find the program header list, and e_phnum to find out how many program headers there are in the list.

3. Seek to e_phoff, and read e_phnum program header entries.

4. For every program header with a p_type of 1 (PT_LOAD), allocate + zerofill p_memsz bytes at p_vaddr, and if p_filesz is nonzero, read p_filesz bytes from p_offset in the file into p_vaddr in memory.

5. Jump to e_entry... That is:

((void (*)(void))(ehdr.e_entry))();

Actually building the bootloader typically involves writing a GNU linker script and is outside of the scope of this document.