[Notch], the guy behind Minecraft, is currently working on a new game called 0x10c. This game includes an in-game 16-bit computer called the DCPU that hearkens back to the 1980s microcomputers with really weird hardware architecture. [Benedek] thought it would be a great idea to turn his ThinkPad into a DCPU, so he wrote a bootable x86 emulator for the DCPU that is fully compliant with the current DCPU spec.
This bootable DCPU emulator comes from the fruitful workshop of [Benedek], the brains behind drawing fractals on the DCPU, emulating bit-flipping radiation, and even putting the Portal end credits inside [notch]’s 0x10c computer.
[Benedek] wrote this new in x86 assembly, allowing it to be booted without an OS from a USB flash drive on any old laptop. This allows for direct hardware communication for everything implemented for the DCPU so far.
If you’d like to run your bare-metal DCPU, [Benedek] made all the files avaiable. Since the entire emulator is only 1800 lines of x86 assembly, it’s possible to load this off a floppy disk; an ancient tech we’ll be seeing in [notch]’s new game.
Oh. One more thing. When we were introduced to 0x10c, we said we’ll be holding a contest for the best hardware implementation of the DCPU. We’re still waiting on some of the hardware specs to be released (hard drives and the MIDI-based serial interface), so we’ll probably be holding that when there is a playable alpha release. [Benedek]’s bootable emulator is a great start, though.
I had the idea for a game with a programmable VM a couple years back, but I lacked the wherewithal (both in terms of skillset and drive) to actually do anything with it. It’s such a cool idea and I’m really glad someone is finally making it happen. I just wish it had been me, so that maybe I wouldn’t be writing VB for a living. :V
The way I’d originally conceived of it there’d be a deliberately included exploit in the VM that’d let you escape the VM and get into the scripting engine that runs the game, letting you write in-game apps that explode enemies’ heads. I’d call it Technomancy.
“so he wrote a bootable x86 emulator for the DCPU”
(…)
“This bootable DCPU emulator ”
(…)
“Since the entire emulator is only 1800 lines of x86 assembly”
I needed to read the entire thing just to know WTF the article author was talking about. From the first phrase it seemed that x86 was being emulated from DCPU.
What I want to see is a game like the KErbal Space Program and this combined.
Let me design a rocket AND write the software to control it’s mission.
Soon :-)
here is a teaser
Wonder when it will be ported to to the Raspberry…
I have been thinking of doing that, but I’ll first have to buy one, learn ARM assembly and rewrite the whole thing from scratch basically, because it’s a different architecture and you can’t re-use assembly code that way :)
Plus you won’t have BIOS interrupts, making it a much bigger and much more painful task.
Or you could just write it in c. Really the CPU does not look that hard.
It uses 16bit unsigned words. which will map to a an unsigned 16 bit int with no problem. As will all the registers and you have 16 opcodes. So you just use a switch statement for that.
What makes this hack somewhat cool is that it is in assembly. You could write that CPU in Python, Perl, C, heck even Fortran with very little effort.
The data sheets for the SD card controller, USB interface and GPU on the Raspberry Pi weren’t publicly available last time I checked so that might be tricky.
@lwatcdr: Also the fact that it’s running natively with no OS. Don’t underestimate that work that takes on x86. Since all this runs in real mode, everything has to fit in under 1MB of memory. Moving to C still wouldn’t get him anything here– he’d either have to still use BIOS interrupts via inline assembly or write at the very least a simple VGA driver. Either way, it would still be very x86 specific.
@Brian true I missed the bootable. You could still write it in C. It would be tiny and would have no problem running in under one MB in real mode.
I have not dug into the source code but I wonder how he handles IO. The DCPU has no IO instructions and no interrupts that I saw to emulate bios calls. So did he map the IO into the memory space? maybe an OS where you load a register and make a jump to an address? Like I said I have not read the source and the video well is a video. I watched it for a bit but i would rather read.
Still would be easy to write the CPU in C to run as as task on a pi. Booting it would be IMHO way more trouble than it is worth.
Now on an AVR would be a good choice.
@lwatcdr: I’ll give you something to read :)
Writing this in assembly was one of the goals/challenges I set for myself when I started, with one reason being that I had never yet made a bootable program utilizing C :)
The I/O works exactly as specified by the DCPU-16 spec, so for example, you can tell the monitor which memory range to use as a screen, and you can set up the keyboard to send DCPU-interrupts on events, or query it directly. The DCPU has no idea that it’s surrounded by a BIOS, PC hardware, PC interrupts and whatnot.
The drawing of the screen takes place regularly at fixed frequency: Every time this happens the program goes through the memory the screen is mapped to and writes it to the VGA screen memory, just as it should appear according to the spec (considering the font and the color palette, too; and don’t forget that we’re in VGA text mode!).
PC keyboard events are caught as interrupts by the emulator program, processed (the scan-codes are turned into ASCII with some DCPU-specific codes) and put into a small keyboard buffer for the DCPU to read. Optionally, a DCPU interrupt can be triggered or put into a queue, just as the spec requires.
Indeed, there are easier ways to write it, especially using an OS, but I already did that (I wrote an emulator using SDL in C++). And you might be right, there might be better ways to write a bootable emulator, but I haven’t seen any other one yet and quite honestly, I’m happy with how this turned out.
Did I see MIDI serial interfaces? That’s awesome. I’m so hooking up a piano to one.
so how exactly does one “install” the software you’d enevitably have made from one’s emulator “into” the game’s computer???
i find this problem funny and might involve a kinect and H.U.D. glasses? as well as the game being able to read your physcal F.D.D. ???
so when you insert the floppy in real life the game “sees” this via kinect and tells the game to move the picture of the disk along with your movements. and then when inserted inside of DCPU computer (98% disk surface hidden inside drive) that the disk inserted sensor should now detect a disk???
just one question though:
would WE be “inside” the virtual reality…
or would the virtual reality be “outside” and around us?
confusing
what about using virtual-VirtualReality glasses to see “outside” the game into the real world. all the while the HUD onto the real world could be programmed using the DCPU.
few! that was a confusing little one wasnt it? hahaha
Unbelievable what people can do… The game isn’t even released and there is more content that ever to discover. Well done community !