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

151–160 of 177 posts

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

#151

Post by mightywok »

tptacek wrote: post #138
swang wrote: post #115

Earlier quoted context omitted.

Learning about assembly/to-the-metal coding is probably not the best way to learn programming. "OP? LOAD? REGISTER? PC LOAD LETTER? What's a word? There's only 8 registers? Does that mean I can only save 8 things? What do you mean I have to push things into a stack?" This is why most people advocate learning python or ruby. You don't have to deal with the underlying manipulation of the computer until you've decided y…

Knuth would disagree with you. And PC LOAD LETTER?

I love me some Donald Knuth references

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

#152

Post by jlawer »

stephengillie wrote: post #96
jerf wrote: post #62

Earlier quoted context omitted.

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

Exactly. Remember the 64kb video demos from 2004? http://www.theproduct.de/

Problem was most of the demos used many many megs of ram as they procedurally generated objects and stored them in memory. The 64k demos were disk size.

Assuming memory mapping is used for displays the (128k of ram (64k of words)) is also needed to hold your display buffer. Assuming a mere 320 x 200 x 8 screen will use 1/2 of your entire virtual memory space. Look for demos of what people do on C64 demos for a better idea. Yes you can run a UNIX, yes you can talk TCP... but its going to chew up a lot of the capacity for that infrastructure. I expect very light weight protocols, TCP/IP is likely too heavy weight.

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

#153

Post by ricardobeat »

tlrobinson wrote: post #148
Zaak wrote: post #121

Earlier quoted context omitted.

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.

Not to mention a MMU. Of course that didn't stop someone from implementing an ARM emulator on an AVR and running Linux on it... http://hackaday.com/2012/03/28/building-the-worst-linux-pc-e...

The project website: http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%...

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

#154

Post by Zaak »

tlrobinson wrote: post #148
Zaak wrote: post #121

Earlier quoted context omitted.

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.

Not to mention a MMU. Of course that didn't stop someone from implementing an ARM emulator on an AVR and running Linux on it... http://hackaday.com/2012/03/28/building-the-worst-linux-pc-e...

Actually, uClinux doesn't require an MMU, and it's been merged into the main line of kernel development.

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

#155

Post by javert »

jiggy2011 wrote: post #130
javert wrote: post #107

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. 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 inter…

Wow, now that is a very cool idea! I'm really looking forward to the game.

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

#156

Post by ericbb »

swang wrote: post #115
dlikhten wrote: post #108

Earlier quoted context omitted.

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?

Learning about assembly/to-the-metal coding is probably not the best way to learn programming. "OP? LOAD? REGISTER? PC LOAD LETTER? What's a word? There's only 8 registers? Does that mean I can only save 8 things? What do you mean I have to push things into a stack?" This is why most people advocate learning python or ruby. You don't have to deal with the underlying manipulation of the computer until you've decided y…

I don't know about "most people" but I think a machine like this DCPU-16 is better than learning Python or Ruby. Those languages are huge and full of complexity. With a 16-bit machine with a tiny instruction set, the student actually has a chance of getting the feeling, 'I know everything there is to know about this system'. And that connects to a piece of wisdom I love from Design Principles Behind Smalltalk: "If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual".

And there's a certain concreteness to such a machine. The mental model has no vagueness at all. You could imagine building a physical copy of it and playing the role of CPU--adding small numbers, moving data between registers and memory, etc. I've played with this idea myself before of using an invented 16-bit machine as a teaching device.

Maybe it's just a case of personal differences, but as a starting programmer, I would have been extremely excited about a simple programmable thing that I can fully understand and use to do things within a game world. Python is cool too but it's overwhelming. There are learn-Python books that are thicker than most of my university textbooks.

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

#157

Post by ericbb »

wglb wrote: post #145
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 :) ?

I would be astonished if there wasn't soon a FORTH running on it. And something like http://code.google.com/p/femtolisp/ might not be totally out of the question. But who can say. The second Fortran compiler I used ran on an IBM 1800 (equivalent to the IBM 1130, but for process control) had something like 29 phases, and ran on a machine with a total of 4k 16-bit words.

Pico Lisp might be a good starting point. Its interpreter for x86-64 machines is written using a simplified custom assembler and already uses a reduced number of registers.

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

#158

Post by ealloc »

asdfaoeu wrote: post #141
ealloc wrote: post #60

Earlier quoted context omitted.

By going UTF-16, he would make the game much more accessible to those not using a latin alphabet. If I was designing the game, I would favor internationalization vs space efficiency in the virtual computer. That way russian kids would get to have fun learning to write silly programs too.

UTF-8 still has all the characters UTF-16 does it just uses more bytes to encode them. UTF-8 makes more sense if most of your characters can be represented in 8 bits.

you can encode all characters in the basic multilingual plane with a single utf-16 code unit, while in utf-8 BMP characters have variable lengths from 1 to 3 bytes.

If Notch only allows BMP characters and uses utf-16, internationalized string maniulation is very easy, as easy as ASCII for kids to mess with.

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

#159

Post by ericbb »

RodgerTheGreat wrote: post #100
tvorryn wrote: post #66

Earlier quoted context omitted.

That's my plan actually. It should be a lot easier to get going than C or an LLVM backend as others are suggesting.

Same here. The main design decision is how to represent the secondary stack. I was thinking we could reserve a pair of registers to keep the parameter stack pointer and return stack pointer, and swap them out with SP as needed. 1 2 + >r becomes something like SET PUSH, 0x1 SET PUSH, 0x2 SET A, POP ADD A, POP SET X, SP // back up data stack pointer SET SP, Y // switch to return stack SET PUSH, A Thoughts?

My first try would probably be to use SP for one stack and some other fixed register for the other stack. Also, traditional Forth interpreters don't use code like you showed. I think the main benefit of using Forth (unless you just happen to love RPN) is the compactness of the interpreted code. If you're not going to use an interpreter, then I'm not sure if Forth is really a win.

Edit: Just to clarify about the interpreter point, I'd expect something like "1 2 + >r" to be represented at run time as four words in memory and there'd be an interpreter, written in machine code, reading code word sequences and jumping to small bits of machine code to either do a built-in function or push the call stack.

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

#160

Post by mrtron »

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…

Unix permissions would be a simple layer to add on top. Create a user/group/root structure for read/write/execute (execute?).

A road location would be rwxr--r-- while a road texture could be rwxrwxrwx.

Your player's character look could be rwxr--rwx.

A signpost coudl be rwxrwxr--.

Post reply on HN