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.

I'm not sure I understand the question.

It currently requires command line arguments. At the minimum, an argument pointing to the EEPROM image to use. Arguments I used when testing Tetris: -rom /home/sbizna/jarmrom/bin/tetris.rom -screen 2Arguments I used when testing the Lua interpreter: -rom /home/sbizna/jarmrom/bin/boot0.rom -screen 2 -memory 1024 -fsro /home/sbizna/nobackup/openos_floppy/ -fsrw /home/sbizna/nobackup/lua_test_disk/ -addrinfocmd "arm-none-eabi-addr2line -spfe /home/sbizna/luajarm/bin/lua52.elf.unstripped"If you run it without any arguments, it'll print a usage string giving the meanings of all the argument

You're not missing anything. I went to all the trouble to build the jar, then forgot to upload it. D'oh! Fixed now...

Fixed the link, thanks for letting me know. As for Eclipse... I feel you there. The sad thing is that as far as IDEs go it's the middle of the pack. There are many far worse IDEs...

I build the simulator using Eclipse, but the project is not included. (I am not at all comfortable with blindly committing the huge array of cache files and metadata files and such that come with an Eclipse project. I can't prove to my satisfaction that I wouldn't be inadvertantly commititng something covered by an NDA.) It should be pretty easy to set up an Eclipse project to build it. Exclude the ocarm folder (right click it and "close", or something) and set the launch class to name.bizna.ocarmsim.OCARMSim. Edit: You'll also need to add the OpenComputers API to the build path in order f

The Lua architectures boot a built-in "machine.lua", which boots "/init.lua". OC-ARM's (non-built-in) boot0 used to boot "/boot/arm.elf", but this was changed to "/OC-ARM" for three reasons: Compatible with OpenOS (which would try, and fail, to run "/boot/arm.elf" as Lua code on startup) No conflict with OpenArms (or other ARM architectures) Similar to standard practice for OS kernels (/mach_kernel, /vmlinuz, /kernel...) Naturally, more advanced bootloaders will include ways of specifying alternate boot targets, but it makes sense to have a standard process for determining the default on a gi

The only downside of that is that the "flash" utility would have to prompt for that information (user error party!), or it would have to be stored in the ROM file some other way. I'm open to it, though. Perhaps something like my original proposal as the storage format, and the "flash" utility can recognize that, strip it, and tag the EEPROM? ROM images that aren't tagged would default to "Lua 5.2;Lua 5.3" for obvious reasons. Maybe something like: arch=Lua 5.2;Lua 5.3 Blah blah blahand after "flash" is done with it, the EEPROM only contains "Blah blah blah" and has its architecture tag

My time is getting crowded again, and this project is suffering as a result. Nevertheless, 0.0a3 is out now, including source code. The first post has been edited with details.

That can only work when there's an OS to handle the software interrupt. There isn't an OS for OC-ARM yet. You have to find a GPU, find a screen, bind the GPU to the screen, and then make drawing calls. I strongly recommend looking at tetris.s for this.

The way I learned isn't really applicable anymore, but Learn C The Hard Way looks good.