I have been playing Pokemon Yellow on an Android GameBoy Color emulator lately. Thoughts about these apps and their model.

• First started with this one: "Gameboy Color A.D"
• Simple app. Easy to use.
• Free with ads in the home screen, not during play time. Ads not shown when in airplane mode.
• All features available in free mode.
• One of them (Fast Forward) wants you to watch a movie before activating it ⇒ skipped in airplane mode.
• Lacks a couple features (Link Mode) + crappy zoom quality (too blurry)
• Tried this alternative: "My Old Boy! Free (GBC)"
• Better quality game.
• Unfortunately many essential features are blocked by a "Only in paid version".
• Load: you can save but cannot reload!
• Link Remote: only in paid.
• ⇒ That was enough of a kill-it-and-uninstall. I think the pure block is not a good strategy as I could not even evaluate the feature. The ability to save without reload is a total non-sense and feels like a bad bait-and-switch.
• There are many many other Android apps for GBC emulation, most of them looking exactly like each other.
• ⇒ My feeling is there are 1 or 2 engines out there and everyone is just repackaging the same thing.
• There is one open source Android version: "Gameboid"
• It seems the original project was open-source and then the original app went paid/closed on Android.
• This uses an NDK z80/gbc emulator source + code around to handle inputs and display and stuff.
• Doesn't seem to support the Link Cable feature which I want.
• I could rebuild an app around this, but is it worth my time? Probably not.
• So for a second I thought about whether I could rewrite the NDK gbc emu in Java.
• ⇒ But surely someone has done it, hasn't it?
• What do I know about z80 assembly code & emulation? ⇒ Nothing.
• What do I know about GBC hardware emulation? ⇒ Nothing.
• ⇒ Again, worth my time trying? Not really.
• "JavaBoy" is one such emulator rewritten in Java.
• Tried it and it builds and run as a Java App in IJ with no problem.
• Source is clean and instructive.
• Most interesting there's a one-file z80 emulator right in there.
• The rest is handling peripherals and magic GBC-specific constants.
• Mentions passes some kind of emulation test + a list of games compatibles.
• ⇒ All this clearly shows I know little on the subject, nor do I really care.

So bottom line:

• Reading the JavaBoy source code, I did learn a couple interesting things on how ROMs & save files are handled (basically they are 8k or 32k memory chunks) and they all tend to load a blah.zip or blah.gb with a side blah.sav for the 32k chunk so that means pretty much all these emulators are cross-compatible if you give them the right files.

Went with the paid version of "My Old Boy!".

• It's disappointing that the Free version can't properly act as good test app.
• Just suck it up and use the 15-min window for trying it out.
• The Link Remote feature worked over wifi + over BT. It's a bit flaky (works fine initially when it goes bad.)
• The app is $4.

It's not worth my time rebuilding my own emu for that price yet I had a fun time looking at the emulator sources and their implementations.

State of Nova script :

• Lack of interest for spec 1 of the language
• Not convinced about antlr4
• Pro : not writing lexer myself. Simple to understand, as it just generates a lexer tree. No mixing ast instructions + code in grammar file. Visitor pattern easy to work with.
• Cons: doesn't do much. No automatic ast generation. Lots of boring template code to generate internal ast. Lack of non-free documentation.
• Results in unfinished project so didn't tackle the hard parts yet such as execution.
• Should I continue on something I won't use for the sake of it, or redesign directly for 'what I want' (and what) without knowing if I can really implement it?
• Logic dictates I finish v1 as a proof of concept but don't stop there.

Same issue again : too many projects going on.

• Work stuff. Main project going nowhere, maintenance takes most of the time. ==> Cut side things.
• Home focus should be NovaScript.
• Got a plan, should stick to it.
• Fixed Comics2, good.
• Learning Ember JS can wait.
• Using it for Comics3 is overkill yet a simple way to start. Can wait though.
• RPi + PiFace : stick to a quick test so that I can demo it. Come back to it later.
• Digispark : stick to the demo. Chances are he won't use it.

[...]

That little hardware hack should preempt NovaScript.

Learning JS stuff:

• Bootstrap for UI/widget/look.
• Embed JS for "application" framework (what does it bring? How's that MVC and testing really useful?)
• Kinetic for HTML5 canvas.

Ideas:

• Block editor. Saves locally on server.
• Dashboard showing server data / state. Think piscine enregistreur.
• [...]

Speaking of piscine enregistreur, I don't think I can support velleman's USB stuff on an RPi (never got motivated to find how to deal with the driver), so look into other venues to have voltage measurement.

Web ide idea: not a full project per se, just a server side hack.

Did some work on the Music App this week-end: I kind of like and hate the little script language implementation. It would be interesting to formalize its implementation into a design doc and write a standalone library for it, working on separating "core" language from app-specific extensions.

[update 2014-03-09, here it is: NovaScript [idea]]

Follow up to the last note about the hint documents. Generally speaking I should clearly organize documents using a category system. The 'ideas' folder is such an attempt, but maybe some large categories in the title would help:

• Brainstorming or Idea or Concept: live log about a concept or idea, unstructured.
• Research: structured with version, or unstructured with live log. Explores one singular topic. Similar to brainstorming but more focused on a single topic.
• The separation between research and brainstorming is fuzzy. Brainstorming kind of implies the document is unfocused and quite exploratory. Research kind of implies I already know more or less what I want to talk about.
• I don't like the word "Brainstorming." In fact I don't like any of these qualifiers here.
• Design doc: structured, not a live log. Use versions to capture evolution. Describes one specific project, in a singular version. Discussions go in another document (concept one).
• Implementation: companion details about a single design doc version. Unstructured, live log. If one topic gets too large, extract it into a research document.
• Platform or Overview: large description about a given system that might encompass several projects. Structured, with versions. Ongoing discussions go into a live research or brainstorming document, the overview document captures the summary of a potential state.

Applying this to the hint thing:

• "Platform hint" becomes Brainstorming on the ikaria platform.
• Overview: Ikaria v1
• Overview: Hint language v1. --> design doc v1.
• Research: feedback on clojure.
• Research: immutable data types for closures.
• Idea: Cloud Bus --> Design doc v1
• Brainstorming: Robot game. --> Design doc v1 --> various design doc links to subprojects.

Also go back to older documents and rename them as clearly obsolete.

[...]

I think I'll settle for [Idea] and [Research] for now.

Part of the goal is to have a more systematic approach. Most of my documents are merely exploring an idea for an app or a library and are often expressed as a list of "specifications" that combine both desired features and potential implementations. One goal would be to have a more structured and formal approach where there's first a discussion document that explores possible variations and then settle down on one particular set of features & implementation.

Phase 1: A project description starts with an [Idea] document.

• Often I just stop there or have various iterations on the idea. That can go into the same document.
• If at some point I decide I'm taking a radically new direction, I should make a new version (so Project Foo v1 [Idea] ⇒ Project Foo v2 [Idea].) Make sure to link to the previous one for reference.
• Many times a document would describe an idea along with a potential "specification" overview. The pattern would be to add "Spec" to the doc title, but it's not a category by itself, it's still an idea unless it's formally rewritten as a design doc. That's because such documents are generally live documents where the proposed spec is part of the exploration, and not necessarily final.

Phase 2: If the project starts to get serious enough, try to stabilize one version of it.

• This becomes an [Overview] document or a [Design Doc] document.
• These documents should describe the project fixed at a particular implementation. If it turns out to not be satisfactory, amend the [Idea] document with an on-going discussion and continue stabilizing the idea.
• Only a minority on medium-to-long term "serious" projects would get that treatment.

Git?

We have git at home.

Looking at the various Hint documents, it's a bit of a mess: As explained in the [Hint Platform] document, the various Hint docs are mixed because some define what I want to do "with Hint" rather than "for Hint".

Namely [Hint Platform] describes how the discussion should be split into different projects:

• Hint documents should be purely about the language and the VM itself.
• Ikaria should be the umbrella platform, the shell that _uses_ Hint.
• Cloud Bus is a separate project.

One cleanup operation is to take the old [Hint Platform] and pretty much rename/move it into an "Ikaria Platform" document. Then the Hint doc folder should only have Hint material focusing on the language, its syntax, and implementation.

Given that, the goals are not quite changed:

• Target apps are still Black Editor, Nerdkill/Asqare on top of Hint.
• Apps are networked using experimental versions of Cloud Bus.

Last week, experimented with Robolectric.