

GoSpeccy: A concurrent ZX Spectrum Emulator Written in Go - remogatto
https://github.com/remogatto/gospeccy

======
thristian
Every month or so, somebody drops by the bsnes[3] forums asking why bsnes pegs
one CPU core and leaves the others idle, instead of using each core equally.
The answer, of course, is that a SNES has a number of different processing
units all running at different speeds, and it's much more efficient to design
the emulation core with coöperative multi-tasking[4] than with OS threads.
Since bsnes is implemented in C++, I've wondered whether a language more
focussed on concurrency could make a multi-threaded emulator possible, but it
looks like GoSpeccy isn't a particularly useful example of it.

From the "Architecture" page[5]: _In consequence, the whole emulation core is
basically just one goroutine_

[3]: <http://byuu.org/bsnes/>

[4]: Like, ridiculously more efficient, making it possible to sync millions of
times per second. The system bsnes uses is called "libco", and although it
doesn't have its own web-site, you can browse the code here:
<http://gitorious.org/bsnes/bsnes/blobs/master/bsnes/libco/>

[5]: <https://github.com/remogatto/gospeccy/wiki/Architecture>

~~~
scott_s
One OS thread per task is not the only way to parallelize a program. If you
have a runtime system that allows the creation of light-weight tasks that can
be executed by pre-existing OS threads, you can exploit very fine grain task
parallelism. See The Implementation of the Cilk-5 Multithreaded Language:
<http://supertech.csail.mit.edu/papers/cilk5.pdf>

~~~
remogatto
That's right. In Go such light-weight tasks are called goroutines.

Quoting from Effective Go[1]:

A goroutine has a simple model: it is a function executing in parallel with
other goroutines in the same address space. It is lightweight, costing little
more than the allocation of stack space. And the stacks start small, so they
are cheap, and grow by allocating (and freeing) heap storage as required.

Goroutines are multiplexed onto multiple OS threads so if one should block,
such as while waiting for I/O, others continue to run. Their design hides many
of the complexities of thread creation and management.

[1] - <http://golang.org/doc/effective_go.html#goroutines>

------
beagle3
In the real speccy, you could double the horizontal resolution from 192 lines
to 384 lines, and also get different colors for each 8x1 (or 8x0.5 if
extending to 384) by changing the screen bitmap while the scanline is being
generated.

Pixel timing accurate emulators exist -- in fact, C64 games written after
~1990 are useless without it.

~~~
0xe2-0x9a-0x9b
The "8x1 mode" and border effects do work in GoSpeccy. You can try the
Overscan demo (<http://www.worldofspectrum.org/infoseekid.cgi?id=0007636>).

GoSpeccy does not support any 384 line mode. As far as I know, the
_horizontal_ resolution is 256 pixels, so doubling that would yield 512
horizontal pixels.

------
pmarin
Can you explain were the concurrency is used?

~~~
indy
Here's a link to the GoSpeccy architecture:
<https://github.com/remogatto/gospeccy/wiki/Architecture> each of the modules
communicate via Go channels

