Take Over The Galaxy with GitHub (DCPU16 support)
github.com
github.com
Thanks, github. You made my day.
I've been thinking of how hard would it be to take two 32k SRAMs and an AVR and do some fancy bank switching to handle it. I know I could probably manage it by using the onchip support directly but then I'd end up with some memory inaccessible from addressing holes.
It seems like it should be possible to do, and then it would be easy to allow real IO and everything later when that's standardized.
https://github.com/krasin/llvm-dcpu16/
C compiler support for dcpu16!
In a way this almost saddens me as by the time the game comes out it looks like the community will have javascript ported to the CPU and no one will actually have to program in assembler as per the original idea... ;)
If the current level of interest persists, by the time the game launches, I imagine that the vast majority of people will be downloading and running programs written by others. These will have been pored over and optimized to an extent that most of us would be unable to achieve by ourselves, and it will not pay to roll your own trivial implementation. I'd be curious to see what Notch can do to still encourage people to learn how the CPU works themselves. If the environment and game dynamics are rich enough, perhaps this will not really be a problem?
Have some ship customisation stuff tied to assembly programming. People love changing the colour of carpets or wearing hats or collecting and displaying fossils.
Then allow the community to create simple how to guides - "This program will do $THIS_THING; here's how it works; now try to change it to do something slightly different."
I guess Codecademy should have a DCPU section too.
Agreed that higher-level langs would be helpful for "newbies". I wonder if this was at all inspire by Schemaerse (google it, but TL;DR it's a space game written mostly with Postgres triggers where /you build the game client/ in whatever you want to use to interface with the pgsql :)
The Haskell embedding is very likely to head in that direction.
(See e.g. in this style : http://www.fftw.org/faq/section4.html#whyfast or this style : http://www.cse.unsw.edu.au/~chak/papers/polymer.pdf -- code generation + DSL + constraint solver for instruction level timings).
At least, that's what I'd do.
[0] http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
The task builder.
TKB allowed (much) larger applications to run in the address space of a 16-bit DEC PDP-11, using what were called overlays, and overlay trees.
With overlays, the application call tree within an application was analyzed and implemented to allow various sections of code within a tree of subroutine calls to be paged out to backing storage.
If the underlying "processor" is fast enough and if you have enough swap space available, then you can stuff a whole lot of code into a 16-bit address space. Just not all loaded in physical memory at once.
And debugging it... Shudder...
It was more similar to vi + integrated compiler as an IDE.
I love the game idea, and think Notch is a great game designer+developer, and sincerely hope that it will be what we think it will be. But at the same time, I'm not as optimistic as others might be.
We keep abstracting, but we can gain so much by going back to the hardware. Also, exploiting in general is fascinating to me, and I hope this pushes it more mainstream.
I think it is great for teaching kids to program as well, or be excited about it. Notch is going to do what thousands of teachers can't do because he is using the power of gameplay to drive it.
So for example, you'd have the difference between a single-celled organism (standalone ship) versus a multi-celled organism (a fleet), with a fleet of ships delegating work to specific ships. So 10 ships run the "scout" programming in a perimeter, 5 act as resource gatherers, and a few others as transports within the protected space. Perhaps some act as brain cells which tell ships when to change roles.
All of this is happening even when no members of the fleet are actually playing.
This just boggles the mind with possibilities and I can't wait to start playing this game.
Furthermore, you have people trying to break into space protected by fleets by attacking networking protocols--in a game!
Viable?
There's a market for minecraft servers, so anything's possible.
Your second question is a reservation that I have as well. We have already witnessed a huge influx of people coding up DCPU-16 software for free, but such programs are only related to the software engineering side of the spec rather than the actual gameplay. Obviously we know less about the latter since few details have been released, but in the competitive game I imagine it could be different. For example, to build a really awesome weapons system and then share it with other people seems a bit counter-intuitive. So there may be room yet for a business built on custom, clandestine code for a player's ship.
Gamers are already a demographic with money to spend. This could be seen as a worthwhile investment to some. If you are interested, email me and we can talk there.
I doubt the returns reach the proportions necessary to support a startup, especially with the low barriers for entry, competition from free alternatives, and piracy. Maybe it could support a single developer, though; more of a "lifestyle business."
btw, awesome work w/ mappum on the js emulator stuff. you guys update w/ impressive speed.
Also, thanks!
Let's not get too excited here. Name one thing that can be done in days that used to take decades.
"When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to `what follows B?'). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder."
-- Dennis Ritchie, who wrote the first C compiler. http://plan9.bell-labs.com/who/dmr/chist.html
The discussion is about how much effort it is for people to implement things, not computers to run them.
But even those that are doing it for fun -- you might be underestimating the amount of nerd rage that people are capable of when stuff they don't want to have happen happens. Just sayin'.
https://github.com/ReturnInfinity/BareMetal-OS/blob/master/o...
The 64-bit register names are still not handled correctly. It does properly color the 8, 16, and 32-bit register names.
[1]: https://github.com/sybreon/dcpu16 [2]: https://github.com/filepang/dcpu16-verilog
The [next word + register] instruction is also a bit annoying to deal with in the given time tables and a simple register file design, though I haven't thought about the design of that too much.