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

121–130 of 177 posts

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

#121

Post by Zaak »

dlikhten wrote: post #108
exch wrote: post #23

Earlier quoted context omitted.

Nice. With a bit of fiddling one could perhaps invert an enemy's shield polarity. That always seems to work miracles in any sci-fi show.

This opens a whole stream of electronic warfare, however, the problem is that this will be writing programs that have no real-world usage. Except... These programs will be a great way to introduce both kids and adults to programming as learning it will give an edge to people. Question: Will we need to program an OS? And does it run Linux?

I expect that there will be some kind of default OS released with the game, and that many alternatives will pop up very quickly.

It will not run Linux, because Linux requires a 32-bit CPU with megabytes of RAM. Someone might write a Linux-like system for it though.

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

#122

Post by Zaak »

jiggy2011 wrote: post #49
phoboslab wrote: post #13

Now here's an interesting bit: "Question: can we trade the programs we create? How will you stop malicious viruses etc?" "yes. And I won't stop viruses, the players will have to do that themselves." ~ https://twitter.com/#!/notch/status/187474819980328962

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…

I expect that inter-computer communication will be more like it was in the 80s, with swapping floppies and dial-up BBSs being the norm. It's still possible to get viruses that way, but there won't be worms spreading autonomously through the entire system.

I can imagine how an economy of reputation could arise where some people are trusted to distribute malware-free code.

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

#123

Post by Zaak »

cpeterso wrote: post #89
TomFrost wrote: post #3

Earlier quoted context omitted.

> * 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…

If the DCPU has only 64KB of RAM, encoding strings using UCS-2 or UTF-16 seems rather wasteful.

You're free to choose or write software for it that encodes three 5-bit characters in a 16-bit byte if you like.

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

#124

Post by chrismsnz »

phreeza wrote: post #12
wagabond wrote: post #7

Earlier quoted context omitted.

I'm a self-taught programmer, and don't know much about CPUs. Would someone mind putting this into relatively plain english, I'm quite curious to know the practical implications of this. Can we expect to see Python running on it in the near future for example :) ?

"real" python seems unlikely, given that the standard executable is well over 64KB in size. A variant like cython that compiles to this assembly? maybe...

RPython, perhaps?

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

#126

Post by Tichy »

clavalle wrote: post #105
rg0ne wrote: post #94

That compulses me to take Compiler class next semester, and write a C compiler for this precious fictional CPU. And what about creating this cpu?

Already done in a few languages: http://www.reddit.com/r/dcpu_16_programming/

I think so far there are only assemblers, not C compilers (or any high level languages)?

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

#127

Post by clavalle »

Tichy wrote: post #126
clavalle wrote: post #105

Earlier quoted context omitted.

Already done in a few languages: http://www.reddit.com/r/dcpu_16_programming/

I think so far there are only assemblers, not C compilers (or any high level languages)?

Ahh, I was only answering the last question.

Now that we have some emulators, people are working on compilers.

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

#128

Post by viraptor »

JEBailey wrote: post #65

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?

a and b are just decoded value bits. That means they can be either one of those things. 0x00-0x07: registers themselves, 0x08-0x0f: addressing via register, etc.

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

#129

Post by Benjo »

redthrowaway wrote: post #109
overshard wrote: post #69

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…

When you sell it, however, you'll be selling the source. No pre-compiled binaries, here. Might be a bit difficult to charge for something people can trade for free.

No, the binaries may be easier to disassemble, but it's still machine code. I don't have to include the assembly source if I don't want to.

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

#130

Post by jiggy2011 »

javert wrote: post #107
jiggy2011 wrote: post #102

Earlier quoted context omitted.

You would have to abstract the CPU in some way and then write the permissions management in software as part of the interpreter. Bear in mind that this is already only a 16bit CPU with a restricted address space.

You would have to abstract the CPU in some way and then write the permissions management in software as part of the interpreter. Yes, that's what I said. :) Bear in mind that this is already only a 16bit CPU with a restricted address space. I suspect the interpreter could be made to fit, with limited space left for the untrusted (to-be-interpreted) code. As has been pointed out elsewhere, though, if there is a backin…

True, but your CPU is limited too so having to lex & parse sourcefiles and walk syntax trees to run programs could be a bottleneck there, if you remember old computers there was a significant performance gap between native and interpreted code.

In practice that might not matter for many applications if they do not have to use intensive algorithms etc.

I would still imagine that compilers would be used more than interpreters though which would mean that some security would need to be present at the "hardware" or "firmware" level.

Another interesting thing to think about regards backing stores:

I assume that the programs will be able to take input from the world around them, i.e other ships , objects in space etc.

So what's to stop you from using (perhaps) a tractor beam to re-organise the position of asteroids in space and then "read" that data back using ship instrumentation?

Potentially the entire universe becomes one big DB!

Post reply on HN