Solra Bizna

The "Enhanced" Apple IIe did. The others, as with earlier Apples, used a plain old NMOS 6502. The 65C02 is the CMOS version of the processor. It's largely compatible with the NMOS one, but has more instructions, fewer bugs, and draws less power at high clock speeds. Most of the undocumented instructions of the NMOS processor became documented no-ops, breaking the programs that relied on them. Apple BASIC should be compatible; someone should try to load it up... I forgot to mention in the OP that I specifically emulate the Western Design Center version of the chip, so it has the RMB*/SMB*/

Since I had to write a 65C02 emulator core for work anyway, and since there is still a distinct lack of finished "real CPU" architecture modules for OpenComputers, I just spent the last couple weekends making one. All features that have been tested work, though the testing has not been very thorough. 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.) Ple

I edited it to remove the 4-byte padding from the binary boot records. My reasoning is that, on IO port heavy 8-bit architectures (such as OCMOS), tracking the current position and skipping a specified number of bytes is clumsier than just reading until the NUL; whereas on alignment-sensitive architectures, it's not terribly difficult to do an unaligned read "by hand".

Cross-Architecture Booting Universal Interchange Format OpenComputers Ethernet (reserved by myself) OCranet family of protocols: OCR (OCranet Relay) OCranet family of protocols: NNR (Network-to-Network Routing) Global Empire Routing Technology ON2 - Simple L2 protocol for network stacks Allocated Network Card Port Numbers (reserved by MajGenRelativity) If you'd like to reserve an OETF document number, contact me, as I appear to have become the central authority for them. Here are the ways in which I can be contacted, in descending order of how quic

Sure does. Just two things to keep in mind: The CPU boots in big-endian mode, so you'll want to do SETEND LE as your first instruction. I'm not certain, but it might switch to big-endian mode on interrupts as well. (Not that it matters, since my interrupt code is just stubs...) boot0 will only load big-endian ELFs. It should be (relatively) simple to make a little endian version: do SETEND LE as the first instruction, manually byte swap the constants/shifts wherever boot0 uses a 32-bit integer comparison to test 4 bytes of memory, and remove the code that checks for the BE8 flag.

They should be atomic, because they do not contain other Values. (If I have understood the question correctly.)

THIS IS A DRAFT. It may change before becoming "official". Please feel free to suggest breaking changes. Abstract This document provides a binary interchange format, intended primarily to support generic component IO. Rationale OpenComputers' component bus is designed for high-level languages. It sends and receives groups of dynamically typed values. It is intended to be user-friendly and self-discoverable, and it has largely achieved this goal. However, with low-level architectures, there is no obvious, straightforward way to represent these values. This document aims to provid

I'm picking up this project again in earnest. I've determined that the main thing that's been gumming me up is trying to attack the software and hardware ends simultaneously and in an ad-hoc way. To that end, I'm going to focus down. I've edited the OP with my current todo list.

THIS IS A DRAFT. It may change before becoming "official". Please feel free to suggest breaking changes. Abstract This document provides guidelines for dealing with EEPROMs and locating architecture-specific boot code. Rationale OpenComputers supports a wide variety of architectures. Even more so than in the real world, OpenComputers architectures can differ dramatically from one another. Some architectures run programs in a particular high-level language directly, while others simulate real or fictitious low-level ISAs. Some architectures natively deal with data in 8-bit u

OC-ARM's timing simulation isn't very detailed. Every instruction and every memory access incurs a cycle cost with no simulation of contention or other wait states. As much as I enjoy optimizing around low-level details like bus timings, a less precise scheme like that is probably enough for OpenComputers purposes.

It's a pain, certainly. It doesn't require a general-purpose multiply, though. Multiplying by 10 just involves two two-bit shifts and two adds. Division is much harder on some architectures than others; using sector offsets makes things much easier on those architectures. Adding a division routine could easily make the bootloader no longer fit into ROM. (Correct me if I'm wrong, but I was under the impression that the sector-based read code takes a sector number, not a byte offset. Also, the sector size may change between different configurations or different devices, so it can't be ha

The lag (if you're talking about the latency between causing a signal and having the program "receive" it) is a side effect of the way OpenComputers syncs with Minecraft. The simulator is simulating it accurately(ish). Doing a tight loop to wait for a signal will reduce the lag in the simulator but will increase it in Minecraft. Getting GNU libc compiled for this target would probably not work at all, and then use too much memory if it did. The Lua source code theoretically shows the proper way to link with the compiled newlib, but I haven't released it yet (because it's still broken and I'

Active might be pushing it. Alive, maybe. It would not have been completely broken; the exceptions would, however, have prevented some important updating and left the simulator subtly broken. (Unless I don't know how Java's `finally` keyword works, which is entirely possible.)

After I added -addrinfocmd, I never tested without it. Apparently the simulator has never functioned without it. I've made a new release of the simulator, 0.0a3a, that no longer has this bug.

This post contains instructions on how to make a .elf, requiring boot0 to load it. The procedure for making a .rom instead is nearly identical, but unless you really want to be limited to 1000ish instructions, you should probably make a .elf instead.