- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
-
Content Count
90 -
Joined
-
Last visited
-
Days Won
8
Solra Bizna last won the day on May 16 2016
Solra Bizna had the most liked content!
About Solra Bizna
-
Rank
Junior Member
- Birthday 04/28/1989
Contact Methods
-
AIM
solrabizna
-
Jabber
sbizna@tejat.net
-
Skype
solrabizna
-
Minecraft
SolraBizna
-
GitHub
SolraBizna
Profile Information
-
Gender
Male
Recent Profile Visitors
2222 profile views
-
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
-
draft OETF #1: Cross-Architecture Booting (draft)
Solra Bizna replied to Solra Bizna's topic in OpenEngineering Task Force
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.
-
draft OETF #2: Universal Interchange Format
Solra Bizna replied to Solra Bizna's topic in OpenEngineering Task Force
They should be atomic, because they do not contain other Values. (If I have understood the question correctly.) -
draft OETF #2: Universal Interchange Format
Solra Bizna posted a topic in OpenEngineering Task Force
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 -
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
-
How do we clock a contended bus controller? [OC2]
Solra Bizna replied to GreaseMonkey's topic in OpenEngineering Task Force
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. -
Standardized booting of nonstandard architectures
Solra Bizna replied to Solra Bizna's topic in OpenEngineering Task Force
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'