Notch's Specification for the In-Game DCPU-16 • Hacker News Board

Re: Notch's Specification for the In-Game DCPU-16

#31

Post by nknight » Wed, Apr 04, 2012, 1:31 PM UTC

akavel wrote: post #27

nknight wrote: post #9

Earlier quoted context omitted.

Although some of the implications require experience to understand, I'd say it already is in "relatively plain English", you simply haven't been exposed to the vocabulary and concepts necessary. Trying to explain in any detail would basically be reproducing Wikipedia, so here are some links: http://en.wikipedia.org/wiki/Program_counter http://en.wikipedia.org/wiki/Word_(computer_architecture) http://en.wikipedia.org/…

> a highly dynamic language is unlikely Lua, perhaps? There was an article how to reduce its binary size, for an older version of the language (Lua 4.0): http://www.lua.org/notes/ltn002.html With no reductions, and for x86 assembly, it started at ~64KB, so not very useful here; but after dropping standard libraries and parser , they got to ~24KB. Now however, some further questions arise I'm not sure about: - whether…

Lua is a good place to start! And the VM minus parser is useful, though it may make debugging harder. You simply write out the bytecode and upload that.

The VM is only part of the problem, though. I consider the bigger problem to be memory management. A garbage collected language operating reliably in 128KB? I'm deeply skeptical.

Re: Notch's Specification for the In-Game DCPU-16

#32

Post by ajuc » Wed, Apr 04, 2012, 1:33 PM UTC

TomFrost wrote: post #3

unwind wrote: post #2

Just waiting for the first post about programming this CPU to pop up on Stack Overflow ... :) It's quite an interesting architecture. From an initial perusal, I found these features note-worthy: * Explicit access to PC as a register, makes "computed goto" trivial and very natural. * Because of the above, there is no JMP instruction. * Treating operations on registers as "values" makes the instruction set very orthogo…

> * Word-addressed memory will make string processing interesting to implement. Maybe in space, everyone uses UTF-16. Everyone in Minecraft, too -- almost. The string encoding in Minecraft's protocol spec is UCS-2, just a sneeze away from UTF-16. It seems Notch has a soft-spot for large encodings. It makes sense from a calculation and lookup perspective, but I wonder if the increased bandwidth and storage of 16-bit b…

I think Java strings are UCS-2, so that explains why Minecraft uses this?

Re: Notch's Specification for the In-Game DCPU-16

#33

Post by rplacd » Wed, Apr 04, 2012, 1:36 PM UTC

Ready - steady - port tcc!

Re: Notch's Specification for the In-Game DCPU-16

#34

Post by sp332 » Wed, Apr 04, 2012, 1:37 PM UTC

unwind wrote: post #2

Just waiting for the first post about programming this CPU to pop up on Stack Overflow ... :) It's quite an interesting architecture. From an initial perusal, I found these features note-worthy: * Explicit access to PC as a register, makes "computed goto" trivial and very natural. * Because of the above, there is no JMP instruction. * Treating operations on registers as "values" makes the instruction set very orthogo…

> No I/O instructions means I/O must be memory-mapped, further reducing the space available for code.

In a tweet, notch said It's going to be dynamic later on, but right now [the keyboard is] a cyclic 16 letter buffer at 0x9000. 0=no char yet. Set to 0 after read. http://pastebin.com/raw.php?i=aJSkRMyC

Re: Notch's Specification for the In-Game DCPU-16

#35

Post by sp332 » Wed, Apr 04, 2012, 1:39 PM UTC

Here's some work (not mine) on a third-party implementation in Go :) https://github.com/kballard/dcpu.go/tree/master/dcpu

Re: Notch's Specification for the In-Game DCPU-16

#36

Post by dasmoth » Wed, Apr 04, 2012, 1:40 PM UTC

stusmith1977 wrote: post #17

unwind wrote: post #2

Just waiting for the first post about programming this CPU to pop up on Stack Overflow ... :) It's quite an interesting architecture. From an initial perusal, I found these features note-worthy: * Explicit access to PC as a register, makes "computed goto" trivial and very natural. * Because of the above, there is no JMP instruction. * Treating operations on registers as "values" makes the instruction set very orthogo…

> Explicit access to PC as a register, makes "computed goto" trivial and very natural. Am I right in thinking ARM uses this model? I haven't worked on them since ARM2, but I have a hazy recollection...

Yes it does.

(Thinks of a typical SWI handler...)

Re: Notch's Specification for the In-Game DCPU-16

#37

Post by nightpool » Wed, Apr 04, 2012, 1:42 PM UTC

DanBC wrote: post #30

This might be a stupid question but where does the output go? Is it just a memory location? And does that memory location map to a "ship function"? So, er, on a PC if I write data to address 0x378 it'll appear on LPT1. What's the equivalent on DCPU-16? If I write data to a certain address it'll appear on the missile bay ports? Or is there a level of abstraction?

I/O is still being developed: https://twitter.com/#!/notch/status/187454444571598848

Re: Notch's Specification for the In-Game DCPU-16

#38

Post by sp332 » Wed, Apr 04, 2012, 1:43 PM UTC

xer0x wrote: post #15

SideburnsOfDoom wrote: post #6

Context: For those who are puzzled (as I was) as to what this CPU is for , I found this: > Notch's next game, 0x10c, "will allow players to create their own spaceship in the far, far future of an alternate universe ... More exciting - especially for those versed in programming languages - is the ship's computer. It's a fully-functional 16-Bit CPU that controls the entire vessel..." http://www.dealspwn.com/notchs-spac…

Thanks for mentioning this. I was getting real confused about why someone would create a CPU/ASM for their game. Thought he'd then have to build the new game on top of that CPU and notch is crazy but that seemed a bit much..

It's not completely unheard of. State machines are pretty popular in FPS's, and the Infocom Z-machine code is still used (although upgraded quite a bit) for modern "interactive fiction"/text adventure games.

Re: Notch's Specification for the In-Game DCPU-16

#39

Post by rcamera » Wed, Apr 04, 2012, 1:43 PM UTC

For those interested, there is a C based implementation of Notch's DCPU-16 in github: https://github.com/swetland/dcpu16

I haven't tested it much, but it seems to work pretty well.

Re: Notch's Specification for the In-Game DCPU-16

#40

Post by a-priori » Wed, Apr 04, 2012, 1:45 PM UTC

DanBC wrote: post #30

This might be a stupid question but where does the output go? Is it just a memory location? And does that memory location map to a "ship function"? So, er, on a PC if I write data to address 0x378 it'll appear on LPT1. What's the equivalent on DCPU-16? If I write data to a certain address it'll appear on the missile bay ports? Or is there a level of abstraction?

If I had to guess, he's going to implement memory-mapped I/O. So, there's going to be another specification that lists various memory locations' functions. Reading from some will return information about the ship's systems; writing to other locations will control the ship.