Nes emulator written in go
github.com
github.com
I don't know if it's a statement about fogleman or Go, but it seems so much more clean than other emulators I've looked at.
It was written by pcwalton, one of the main driving forces behind Rust. (Unfortunately, it hasn't been updated for a couple months, so it won't build with latest rust).
In the case of Sprocketnes, one of its goals is to serve as a demonstration of Rust's ability to run entirely without a runtime (see the long-outdated quote in the readme: "The Rust garbage collector is not used in this project"... we really need to get this updated for 1.0).
Possibly the most telling sentence I have ever read about Rust. I am (well more honestly, was) excited by the language but until there is some sort of stability guarantee, it is a fun toy, a distraction.
The Rust community appears desperate to have continuous improvement at the core language level, and despite some hand-waving, it feels like they simply won't be pinned down. I will watch it with interested post the May 15th 1.0 deadline -- but since they shipped entirely new Path and IO in Feb -- added new language constructs and removed others (Alpha2)... I am worried...
> The Rust community appears desperate to have continuous improvement at the core language level, and despite some hand-waving, it feels like they simply won't be pinned down.
What is the impending 1.0 release if not that? We've been very clear all along that 1.0 means language stability. I see no "hand-waving".
> I will watch it with interested post the May 15th 1.0 deadline -- but since they shipped entirely new Path and IO in Feb -- added new language constructs and removed others (Alpha2)... I am worried...
Why would you be worried that we're following precisely the schedule that we said we would?
> What is the impending 1.0 release if not that? We've been very clear all along that 1.0 means language stability. I see no "hand-waving".
I guess I don't consider "stability" and "backwards compatibility" the same thing -- in the "stability as a deliverable" post, it was specifically referenced that rust will "continue to evolve at a rapid pace and even accelerate!" (quoted from memory, sure it is somewhat off).
I think a constantly growing language (no longer changing cause old code has to work, but growing... which seems worse) and the fact that libraries will opt into new features and bundle use of those features with bug fixes will mean that the entire userbase is on a 6 week upgrade cycle -- 8 or 9 upgrades a year. I consider that a mistake. Furthermore, I consider the idea that the channels will not fracture the community to be very naive. I expect a lot of libraries will just live on unstable and tell users to "come with them".
> Why would you be worried that we're following precisely the schedule that we said we would?
You are correct and that was unfair. I can't fault the team for doing what they said -- even if to an outsider it seems like an insanely late time to be doing these types of refactoring.
> no longer changing cause old code has to work, but
> growing... which seems worse
> the entire userbase is on a 6 week upgrade cycle -- 8 or
> 9 upgrades a year.
> I consider the idea that the channels will not fracture
> the community to be very naive.
Rust 1.0 does not mean "the language is done and perfect". It means "we know you're tired of breaking changes, so we've set aside all these enhancements that we were planning on adding so that we can achieve stability sooner, with the expectation of landing those features backward-compatibly at some later date." Rust could easily spend years and years and years in an unstable state, seeking perfection, and there are some in the community who still wish that were the plan. But as someone who's been using Rust since 2011, I'm in agreement with the core team: stability now, evolution over time.
In no world does "we expect that pace of change to accelerate" mean "we expect subtle refinement of the language". Refinement or polishing generally isn't something that "accelerates change".
You can't have a perfect language. Ever. But if you want people to use the damn thing to build actual software, you have to stabilize eventually. C/C++ aren't perfect either - even the most hard-core C++ fan will admit to that - but they get shit done.
Go gets shit done. Sometimes in an ugly way. Rust could get things done in a beautiful way, if they just....stabilized it. Just stop changing it.
> Rust could get things done in a beautiful way, if they
> just....stabilized it.
Or your favorite library author just likes nightlies, which effectively forces you to run nightlies to keep up with bug fixes if he isn't maintaining a separate branch (and who has time for that noise).
> "Stable" but adding new features every 6 weeks... which
> will get used by library authors... which will put all
> users on a 6 week upgrade cycle
> Or your favorite library author just likes nightlies,
> which effectively forces you to run nightlies
That's true, but it ignores the way modern software unfortunately works. Programmers are lazy, and maintaining multiple development branches takes work, so they will try not to do that if they can get away with it. How many bug fixes will get backported to Rust 1.0.x, or to the 1.0-supporting version of that library? Probably not very many. Most developers will just bump the major version every 6 weeks, because that's easier than worrying about stability.
> I think that isn't so much attitude as experience
> some of the policies will be (broad adoption) language
> suicide
<a href="/errors" target="errors">"errors"</a>It's a bit 'exotic' but there are some interesting NES games which only exists on the disk system, like '3d hot rally' (super mario racing game), 'doki doki panic' (the game from which super mario 2 was remade), here's a list of all the disk games: http://en.wikipedia.org/wiki/List_of_Family_Computer_Disk_Sy...
I wouldn't mind if I have to learn from zero (OS, hardware, etc). I think I might have found a side project that I can be passionate about!
UPDATE: Thanks for the replies. I'm having hard time to follow those links since I don't even know where to start. Is there another tutorial that can explain the fundamental of "emulator" first before the NES part kicks in?
PS: I'm planning to use Java for this side-project.
The overall logic is very simple (read a program into ram, read an opcode from the starting location, do whatever that opcode is supposed to do, go to the next opcode... rinse and repeat) and you can find tons of tutorial online (I liked this one: http://www.multigesture.net/articles/how-to-write-an-emulato...)
It should set your mind on the fact that writing a simple emulator is just doing a fetch/decode/execute (https://en.wikipedia.org/wiki/Instruction_cycle) on some code.
For the documentation, I've found that EmuTalk (www.emutalk.net/forums/30-Emulator-Programming) has tons of interesting links.
> PS: I'm planning to use Java for this side-project.
Emulators typically use repetitive code, less than int-sized math, 2d arrays and pointer manipulation. Java is not good at dealing with any of those, so you might want to find a more fun language. Then again, one thing at a time.
Right now I'm just trying to figure out the basic fundamental concept of "emulation" (what is it, what does it take, how can I write a simple one :)).
Chip-8 has 30-something instructions and is relatively simple to implement, and test driving it is pretty easy too. I thought it was a really wonderful first emulation exercise.
Is a fantastic resource. They are helpful and have lots of docs.
>PS: I'm planning to use Java for this side-project.
One place to start might be to try and write an emulator for the DCPU-16. It's a simple made-up computer that Notch (creator of Minecraft) designed for the game 0x10c.
Although the game was never finished, many people wrote emulators based on the DCPU's specifications[1]; search Github for "DCPU Java" to see several examples in that language.
[1] https://raw.githubusercontent.com/gatesphere/demi-16/master/...
Also, the only emulator for anything written in Io, as far as I know :p
Not that it was good, mind you. But I do highly recommend DCPU-16 as an emulation launching point. It's a really easy to understand system :)
He presents the code in the style of a tool assisted run, typing it in in high speed. I never saw templates used like that to create the unrolled CPU dispatcher
A comment elsewhere in the thread mentions Sprocketnes, written in Rust, which takes a different tack here: it uses a hygienic macro to implement opcode dispatching, which allows the giant block of dispatching logic to be reused for both the emulator and the disassembler: https://github.com/pcwalton/sprocketnes/blob/master/cpu.rs#L...
for those that don't know, the title screen, above the checkerboard, has a very thick black line. compare to a proper NES (or Nestopia) to see.
Because doing ${things that exists} in ${current trendy programming language} is somehow gauged as a Good Thing™ in your portfolio by the startup mindset.
Because posting this Good Thing™ on Hacker News is basically the SF startup scene's own LinkedIn equivalent.
Because other people who has bee doing this Good Thing™ want their own Good Things™ to be validated as well, so they continue this tradition.