ix / lazyboy

An EDSL implemented in Haskell for programming the Nintendo Game Boy.

An embedded domain-specific language + compiler written in Haskell for producing code to run on the Nintendo Game Boy.

Also features a library for manipulating constructs such as memory and graphics.

Currently, RGBASM is the only output target, but in the future native machine code generation is planned.

Syntax example (will be updated as more complex constructs are added):

main :: IO ()
main = rom >>= T.putStrLn
    where rom = compileROM $ do
            byte A 0xDE
            byte B 0xDE
            if' ((A == (0xDE :: Word8)) && (A == B)) $ do
                write (Address wram0) 0xDE
            freeze

See app/Main.hs for a full usage example.

Build a ROM (output will be named main.gb):

stack run > examples/main.asm
cd examples && make NAME=main

About issues

I mostly use the issue tracker on here as a place to write about planned features and compiler development, don't take the count as an indicator of active bugs, and be sure to filter to show only issues that are bugs if you are curious on the state of the project.

Contributing

Please see the Contributing page on the Wiki.

Additional information about the project can also be found on the Wiki.

Special thanks

Thanks to Francesco149 and Bonzi for kindly devoting their time and knowledge to the project. The graphics functionality in particular would not be where it is without their assistance.

lazyboy's Issues

Improve the build process

Right now the user has to run a Makefile to generate a ROM.

This isn't ideal, and we'd also like to customize some of the metadata contained inside the output ROM, such as the name of the game.

We also would like to provide a browser-based live programming environment, where code can be entered, built and the results be run automatically next to the code window. The user would also have the option of saving the built ROM. As a stretch, having debugging and introspection features would be nice too.

Better testing through CPU emulation

In the testing, it'd be nice if we threw generated code into an emulator and at least made assertions about the final state of the system.

Quirks, requirements, things to be conscious of

• VBlank/safe VRAM access (seems to be fine provided VBlank is waited on, yet to determine whether there's a limit to how much can be done in one interval).
• INC xx and DEC xx with BC, DE or HL can corrupt the sprite memory. We should probably emit a warning about this.

Mutation and the need for a register allocator

A problem - it is theoretically possible with Lazyboy at present to mutate the value of a register as it is being used in something, such as a loop.

I'm writing this on a whim and not testing it, so it could have mistakes, but the general idea is the same.

.a_loop
  ;; some code that modifies A
  sub 1 ;; A--
  jr nz, .a_loop 

To prevent this we could track which registers are in use in a scope and prohibit mutable access to them. Alternatively, we could silently allow them to be mutated, but move the value they have into a free register or create a map-like structure. After the inner code is executed, we can then move the value back into them before it's needed again.

Better error messages.

At present, error messages only provide the cause of the error, as opposed to where it occurred.

Compound conditionals, more looping options, syntax sugar

Conditionals

Right now conditional execution is achieved through the cond function, which has the type signature cond :: Condition -> Lazyboy () -> Lazyboy ().

This is OK for use with primitive conditions (which are defined to be the Z/NZ/C/NC flags), but we need compound conditionals. I'm not sure yet what the type of these will be exactly, but what I have in mind for syntax is as follows.

-- A and B are registers
cond (A == B) $ do
  write 0xC0DE 0xD00D 0xF

This will undoubtedly involve implementing a function (==) (and hiding the implementation in Prelude), which in this case takes two registers (but we could also make a typeclass to permit support for immediate values too). Assembly wise, this is implemented fairly typically through use of the SUB instruction and jumping conditionally based on the Z flag.

It'd also be really nice to see if we can override the behavior of if ... then but I don't think this is possible and the syntax we have at present is relatively satisfying anyway.

Loops

Right now loops can be achieved by jumping back to a label that an action receives from withLabel or withLocalLabel - it'd be nice to have some more imperative constructs for looping, or to find some other way of expressing loops. Also in Main.hs there's an implementation of repeatOp just kind of sitting there as a potential way of implementing loop unrolling.