
SCRIPT-8: An 8 Bit Fantasy Computer Programmed with Javascript - nsfmc
https://script-8.github.io/
======
gabrielflorit
Hello everybody, author here. I hope you enjoy my tiny project.

Regarding language, I chose Javascript for three reasons:

\- the (ab)use of `eval` lets you do all sorts of sorcery, like instant
evaluation

\- the JS Redux library makes it easy to work with state, and I couldn't have
implemented SCRIPT-8's time-traveling debugger without it

\- I dream in Javascript

I love Lua's small footprint, and very early on I considered writing SCRIPT-8
in MoonScript, which compiles to Lua and has gorgeous syntax. Maybe some day.

And yes, my fantasy computer is definitely not the only open source project,
there's several out there, and probably all of them are more stable than mine.
Go check them out.

~~~
vanderZwan
> very early on I considered writing SCRIPT-8 in MoonScript, which compiles to
> Lua and has gorgeous syntax. Maybe some day.

I know it's no longer considered hip these days, but why not support
CoffeeScript?

It's easy to compile to JS on the client-side, so support should be much
simpler than Lua or MoonScript. You could steal the trick TIC-80 uses to
support MoonScript and say that starting a cassette with the string _" use
CoffeeScript"_ marks it as a CS file. Then it's "just" a matter of an
_if(String.startsWith( "use CoffeeScript\n"))_-check followed by an
intermediate string-to-string compilation step, right?

[https://coffeescript.org/](https://coffeescript.org/)

~~~
gchamonlive
Coffee Script is hell.

Apart from [https://github.com/usefulthink/coffeescript-from-
hell/blob/m...](https://github.com/usefulthink/coffeescript-from-
hell/blob/master/README.md), it takes the worst approach to spaces as syntax,
because it doesn't enforce consistency, so with many devs you can end up with
a file with two, four spaces, tabs all compiling but easily breaking. It has
features their own syntax checker recommend not using, like defining objects
without curly braces (which I think shouldn't even be a feature, but it was
once so backwards compatibility)

Coffee Script tries to be beautiful without straying too far from Javascript
and it ends up being an easily broken mess. I would then recommend either
typescript or purescript.

~~~
vanderZwan
Honest question: pointing out programming design warts that allow for WAT-
level code[0] is perfectly valid, and I obviously prefer elegantly designed
languages. Having said that, how realistic are the odds of being bitten by
these issues when using CoffeeScript?

Also, if our point of comparison is Lua and MoonScript, how do those compare?

EDIT: regarding TypeScript and PureScript, can those be compiled in the
browser? By which I mean, I'm sure they can _technically_ but do not-too-heavy
implementations of such exist?

[0]
[https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

~~~
gchamonlive
> how realistic are the odds of being bitten by these issues when using
> CoffeeScript?

In my experience, minimal if you know the language well and can work around
its quirks. Having said that, I prefer working with a language that doesn't
require much time to tame and let me do concrete work, at the same time
holding my hand when necessary (because of time schedule and pressure and so
on). This is less of an issue with private projects, but still there are no
downsides in learning a tool that is great for both lone and team work, so
there is no real benefit in using coffeescript when there are much more solid
languages that compiles to Javascript out there. Hell even heard you can
change Glasgow backend compiler to make haskell output Javascript haha

I can't answer about lua and moonscript, I'm completely unfamiliar with them.

About typescript and purescript being compiled in browser, I have never even
looked into such approach, they feel unrealistic, because from the top of my
head it would require a compilation tool written in JS, which is not
particularly efficient for this kind of task that benefits from
parallelization, specially if you are not doing deep checks, just translating
code. Then there is the matter of what to do with the resulting code. Can we
dump it into a file and load it programatticaly? I would be surprised if we
could. Eval() the output? Not without some serious security checks that would
further compromise performance.

So I believe there is no motivation in not pre-compiling and distributing the
result dist code

~~~
vanderZwan
> _About typescript and purescript being compiled in browser, I have never
> even looked into such approach, they feel unrealistic, because from the top
> of my head it would require a compilation tool written in JS_

Eh, not really: you could write the compiler _in any language that compiles to
JS_ , then use the compiled output as your compiler. In the case of TypeScript
or PureScript you could basically write a self-hosting compiler this way.

Walt is a compiles-to-WASM language that has partialy done so[0]. Its compiler
written in JavaScript, and the generated compiler is also JavaScript. While
not self-hosting, the guy developing it has rewritten _parts_ of it in WASM to
figure out what the best language design for strings and related JavaScript
interop would be.

> _which is not particularly efficient for this kind of task that benefits
> from parallelization_

First of all, isn't WebPack written in JavaScript? Seems to do just fine.

Also, if we are talking about a somewhat modern browser that supports Web
Workers parallelization is perfectly viable, no? Add Web Assembly and
TextEncoder/TextDecoder in the mix and things could get even faster[1][2][3].

(The main performance issue I see is that due to SharedArrayBuffers being
disabled (for now), each worker would need its own Uint8Array copy of the
source input[4])

> _Can we dump it into a file and load it programatticaly? I would be
> surprised if we could._

Saving a file is easy these days, just use a Blob[5].

> _Eval() the output? Not without some serious security checks that would
> further compromise performance._

Creating Function object works. It just requires a string as input. I also
don't see why this would be more insecure than compiling the same source
string ahead of time - you end up running the same code. This isn't the
typical user-context in which eval is dangerous.

> _So I believe there is no motivation in not pre-compiling and distributing
> the result dist code._

You are arguing this from a _technical_ point of view, which misses the entire
point. Namely, that client-side compilation allows for browser-based apps,
demos, and sharing. It greatly lowers the threshold to trying things out.

You may dislike CoffeeScript, but being able to try it out in the browser is
quite a good sales pitch[6].

For a more ambitious example: Observable is a notebook environment similar to
IPython, but for JavaScript, and with one of IPython's biggest quirks removed:
cells track dependencies on other cells and re-evaluate as necessary[7]. The
server is there for cloud storage and remote collaboration, allowing you to
instantly share the notebook. However, I think it does most, if not all of its
compilation client-side, since it still works when you are temporarily off-
line (also, Jeremy Ashkenas is part of the developer team).

The aforementioned compiler for Walt can easily run in the browser, so last
year I tried combining the two. It took me only a couple of hours to get it
working[8].

Of course, you lose the benefit of a developer environment _made_ for the
language (but IIRC supporting compiles-to-JS languages is on the long-term
Observable roadmap), but still: being able to quickly try out some simple WASM
code without needing anything except a modern browser is quite powerful.

[0] [https://github.com/ballercat/walt](https://github.com/ballercat/walt)

[1] [https://dzone.com/articles/webassembly-web-
workers](https://dzone.com/articles/webassembly-web-workers)

[2] [https://developer.mozilla.org/en-
US/docs/Web/API/TextEncoder](https://developer.mozilla.org/en-
US/docs/Web/API/TextEncoder)

[3] [https://developer.mozilla.org/en-
US/docs/Web/API/TextDecoder](https://developer.mozilla.org/en-
US/docs/Web/API/TextDecoder)

[4] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer)

[5] [https://developer.mozilla.org/en-
US/docs/Web/API/Blob/Blob](https://developer.mozilla.org/en-
US/docs/Web/API/Blob/Blob)

[6] [https://coffeescript.org/#overview](https://coffeescript.org/#overview)

[7] [https://beta.observablehq.com/](https://beta.observablehq.com/)

[8] [https://beta.observablehq.com/@jobleonard/compiling-walt-
in-...](https://beta.observablehq.com/@jobleonard/compiling-walt-in-the-
observable-experiment)

------
akx
I find kind of disingenuous that the page does not mention PICO-8 at all,
which is the obvious inspiration for this project, starting from the name.
Many people who are in the scene, as it were, do know PICO-8 and know to draw
the parallels, but it'd still be nice to link back to
[https://www.lexaloffle.com/pico-8.php](https://www.lexaloffle.com/pico-8.php)
somewhere...

~~~
gabrielflorit
That's a fair point. SCRIPT-8 is inspired by many projects, and PICO-8 is
definitely one of them. I'll make sure to add a note.

------
aquova
I'm an avid Pico-8/fantasy computer fan, and this is a really nice project.
There have been quite a number of fantasy consoles coming out within the past
few years, so it's nice to see one that offers features that the others don't,
rather than simply "Pico-8, but with a twist". The live coding window and
sliders in particular are simple things that increase QoL.

Others have noted that the use of JS is somewhat of a turn off, but even as a
big Lua fan myself, it doesn't really bother me, I already have one (probably
more than one) Lua fantasy console that covers my wishes. However, the
author's comment here did mention adding MoonScript support, which would be
something I would be very interested in.

------
ddrdrck_
This looks incredible ! Real time editing, time travel ... and integrated
sprite, map, and music editors are a real plus. Only thing is the default
color palette that is great but I wonder if we can change it ?

For people complaining about JS vs Lua : go have a look at Amulet. This is not
a fantasy console but also has an online editor and is perfectly suited for
retro games. Just have a look at "Defender of the Weeping Quasar" in the
example section :
[http://www.amulet.xyz/editor.html](http://www.amulet.xyz/editor.html)

~~~
gabrielflorit
Thank you for the kind words. I have no immediate plans for changing the
palette, but you should open an issue here
[https://github.com/script-8/script-8.github.io](https://github.com/script-8/script-8.github.io).

------
magoghm
Interesting how different people arrive at similar ideas. Many years ago I
created a retro-like "virtual computer" in Java, called simpleJ, to let
teenagers learn how to program by creating simple arcade games. It also had an
IDE like environment, with a step by step debugger that could draw a diagram
of run time data-structures (arrays, linked lists, trees, etc.), a tile
editor, a sprite editor, and a even a book teaching you how to program a video
game. You can take a look at it at [http://simplej.com/](http://simplej.com/)
(in Spanish).

------
strainer
This is exceptional - an online IDE with tutorials, sprite and tune editor,
interesting code examples and little games to hack on, even an upload to share
feature.

It only looks a bit ~dusty due to the sepia pallet, should be good to have
other choices like a neon hue, and even free custom selection. But hats off
here, this is a great resource !

------
edmundhuber
For those wondering, the biggest differentiator of this from PICO-8 is that
this is open-source and PICO-8 is not.

~~~
Impossible
No it's not. TIC-80 is open source and there are other open source fantasy
consoles. The killer feature here is the Bret Victor inspired live coding
support.

------
jungler
My main minus to this is not that it's JS(I'm building a JS fantasy computer
too) but that it's a node/react piece, which inspires zero confidence that it
will have anything resembling foundational stability in the future.

------
triptych
I'm super jazzed about this. Wonder if there's anything gained by compiling to
web assembly? Thanks for making this.

~~~
pokstad
I’m sorry, did you say _jazzed_?

~~~
recursive
You can just go reread it. There's no need to apologize.

~~~
pokstad
It’s a LEGO Batman quote.

------
Midnightas
Unlike most, I don't see a problem with it being Lua or JavaScript. I'm just
curious why people pick such high-level languages in the first place. I'm
planning to make a fantasy computer myself (basing it off the z80), and would
never think to make it scriptable in something other than machine code.

~~~
pjmlp
Because we had BASIC on 8 bit home micros and those languages are the natural
successors.

~~~
ken
But BASIC on those computers was interpreted, and thus far too slow. Even the
C compilers weren't that great. Every real game, AFAIK, was written in 6502
assembly.

~~~
pjmlp
True, yet it made lots of kids happy to try out programming their own games
and now they work across the industry, including myself.

Not everything is about the ultimate performance.

~~~
Midnightas
The point is that it's not "javascript interpreted in machine code", which in
my opinion would make these computers far more fun, otherwise they're just
fancy game frameworks.

------
krapp
It's nice but why does it seem to have lower resolution and fewer colors than
actual 8 bit computers?

------
threatofrain
Is there a sample game to view?

~~~
gabrielflorit
There are game-like demos:

\-
[https://script-8.github.io/?id=07b50badd10dc9be002ecb9f9031f...](https://script-8.github.io/?id=07b50badd10dc9be002ecb9f9031f3f0)

\-
[https://script-8.github.io/?id=cd8d6811adb3afb472aaf7505729c...](https://script-8.github.io/?id=cd8d6811adb3afb472aaf7505729cf01)

\-
[https://script-8.github.io/?id=7f370bc716aff805f593a3f800087...](https://script-8.github.io/?id=7f370bc716aff805f593a3f80008711f)

------
n1vz3r
Nice project! It would be great to have on-screen gamepad on mobile!

~~~
gabrielflorit
There's an issue for this:
[https://github.com/script-8/script-8.github.io/issues/41](https://github.com/script-8/script-8.github.io/issues/41)

------
lucio
Congrats, excellent work, I'll be exploring...

------
azhenley
The time-traveling and live editing features make this incredible.

When I get the time I’d love to replicate this in Go (since I’m trying to
learn Go at the moment). Nice work!

------
nategri
I love absolutely everything about this except the language choice.

~~~
Waterluvian
What's an alternative that doesn't make massive sacrifices to the feature set?

~~~
sloum
I think Lua is a wodnerful langauge, highly embedable, great feature
set/style, quite fast, really lightweight. Pico-8 had it right in everything
but the license.

------
dmitrygr
"8-bit"

You keep using that word. I do not think it means what you think it means.

Javascript has no 8-bit types, nor does it have memory limits that 8-bit
machines had. Pixelated graphics are cool and all, but it does not place you
in the same league with people who made games fit in 128 bytes of ram and 2K
of ROM, sorry!

~~~
kittiepryde
Other than the phrase 8-bit fantasy, I couldn't find the phrase 8-bit anywhere
on the linked page.

~~~
dmitrygr
title of submission is " SCRIPT-8: An 8 Bit Fantasy Computer"

~~~
popnroll
There is a big difference between a 8 bit computer and a 8 bit FANTASY
computer. But you don't get it, sorry!

