Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

0x10c.com

Post reply on HN
Print view View original

61–70 of 177 posts

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

#61

Post by coderdude »

nknight wrote: post #57
coderdude wrote: post #52

Earlier quoted context omitted.

I was thinking they could treat software and components like we do when granting third-parties permission to access our Twitter/Facebook accounts: Plasma Shield Generator requests the following permissions: * Read/write to the ship's log * Draw power from the core * Use the red alert system Plasma Shield Generator will not: * Access communication protocols

It's 128KB of RAM, that's the same as the original Macintosh in 1984. I would be surprised if it ran at more than about 10MHz. And nevermind the constrained resources for implementing any of this hypothetical infrastructure, unless Notch adds an MMU, you can't enforce permissions You can't think about this in modern terms. It's not a modern computer. It's a 1980s computer, and it's supposed to run a spaceship. Think…

Couldn't the permission system exist outside of the constraints of the in-game computer (as just some game mechanism)? If each of the ship's discrete components were accessible at some address, couldn't the game enforce the permissions at a level above the simulated CPU?

A rough static analysis of the code might reveal where those components are accessed, and as long as you enforce permissions while the software runs then you should be able to catch anything that tries to slip past.

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

#62

Post by jerf »

nknight wrote: post #51
jiggy2011 wrote: post #49

Earlier quoted context omitted.

I worry about the griefing potential here. I can imagine nothing pissing off a noob more than getting a virus within 10 minutes of play and having no idea how to stop his ship from self destructing. Perhaps this will need some sort of firewall system built in where ships cannot communicate unless ports have been explicitly opened. Perhaps some sort of communications proxy that can serve for safe communications. It co…

Firewall? Ports? Communication proxy? It has 64K 16-bit words. What exactly are you expecting the default software to do that opens it up to viruses?

Do not underestimate those old computers. When you remove audio, visual, and textual data from your programs, remove all the code for handling those and slinging them about and processing them, when you remove the textual file formats and replace them with hand-optimized binary, when you give up on any form of structured modern programming and just hand-compile custom assembler, when your opcodes aren't 64-bits wide, and so on and so on, you can get a lot done in 128KB of code.

Obligatory (but illustrative of my point): http://www.pbm.com/~lindahl/mel.html

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

#63

Post by abrahamsen »

enygmata wrote: post #44
hythloday wrote: post #20

Earlier quoted context omitted.

You don't need the full python repl/compiler/interpreter/libraries, you "just" need the python virtual machine. Once there's a C compiler for the platform that should be relatively straightforward, because I sincerely doubt that takes all 128KiB.

I wonder how hard would it be to get a working DCPU-16 backend for GCC or Clang.

GCC already has 4 other 16-bit backends (e.g. pdp11), so it should be achievable.

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

#64

Post by dspillett »

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…

The thing that looked odd to me was:

>* IFE, IFN, IFG, IFB take 2 cycles, plus the cost of a and b, plus 1 if the test fails*

It is a long time since I worked in assembly, but I don't remember comparison functions having different timings depending on results when I were a lad.

(FYI, most of the assembler I played with was for 6502s (in the old beebs) with a little for the Z80 family and early x86)

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

#65

Post by JEBailey »

I follow most of what's occurring within this document, but there's a bit that's throwing me and I hope someone can shed some light. When you're processing the step

SET A,B

Does A have to represent a register, or is it a memory location or is it both and the registry is just a location in ram?

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

#67

Post by mdwrigh2 »

lt wrote: post #19
stephengillie wrote: post #11

Earlier quoted context omitted.

It's good to see Notch working on the Little Coder problem, even if that's not his direct intention. :)

Ugh. Googling Little Coder problem matches "small code problems" and "little codec problems" before something remotely related to what I wanted. There's a single relevant result in the first page. The verbatim search returns a very good match in #1 and about 80% of the results seem appropriate. It seems the recent synonyms fixes are not nearly enough. And, for the interested: http://blog.steveklabnik.com/posts/2009-1…

Well, you actually wanted a synonym (Little Coder's Predicament not problem), just not the ones they appear to give.

For what its worth, _why's article is the third result for me, and a couple other articles on it are in the top 10.

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

#68

Post by Zaak »

SideburnsOfDoom wrote: post #42
stephengillie wrote: post #11

Earlier quoted context omitted.

It's good to see Notch working on the Little Coder problem, even if that's not his direct intention. :)

Little Coder problem = how to get people interested in coding by writing little programs. Hard to do on consoles and iPhones. I started thinking that if I was going to get people interested in coding, I'd start with something more approachable - maybe something like a subset of Python, Java, Ruby or even JavaScript (it's where so many people write little programs anyway now). I heard Lua mentioned as a good scripting…

It is possible that someone will implement versions of those languages, but this CPU is so memory and speed constrained that you'd be hard pressed to get much useful done. And if the speed of your programs executing turns out to be relevant to success in the game, then people using an interpreted language will be at a possibly decisive disadvantage.

That said, I can see a nice friendly language becoming popular for non-time-critical tasks where ease of experimentation is most important. I just hope it's not BASIC. :)

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

#69

Post by overshard »

I wonder if it's just me but this game has me more excited about programming in ASM than I ever have, ever...

Also in this game I feel like I'll be playing the reverse role I play in real life. IRL I generally always advocate using things like Python and open sourcing everything. In this game I'm definitely going to pull a Steve Jobs, hire out a few friends of mine to program my ASM apps and sell them in some kind of Market for insanely marked up prices telling people that my Orange(TM) software is so much better than Macrosofts(TM)! (And it will be!)

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

#70

Post by nknight »

coderdude wrote: post #61
nknight wrote: post #57

Earlier quoted context omitted.

It's 128KB of RAM, that's the same as the original Macintosh in 1984. I would be surprised if it ran at more than about 10MHz. And nevermind the constrained resources for implementing any of this hypothetical infrastructure, unless Notch adds an MMU, you can't enforce permissions You can't think about this in modern terms. It's not a modern computer. It's a 1980s computer, and it's supposed to run a spaceship. Think…

Couldn't the permission system exist outside of the constraints of the in-game computer (as just some game mechanism)? If each of the ship's discrete components were accessible at some address, couldn't the game enforce the permissions at a level above the simulated CPU? A rough static analysis of the code might reveal where those components are accessed, and as long as you enforce permissions while the software runs…

Go back and look at the first post in this very thread. Notch explicitly intends nothing of the kind, and I certainly can't see why it would be done -- it runs counter to the vision thus far articulated.
Post reply on HN