AthenaEnv gives PlayStation 2 homebrew a JavaScript runtime with VU1 acceleration

A JavaScript runtime where the hardware is the API

AthenaEnv is a complete JavaScript Runtime Environment for the PlayStation 2, and the README puts it more strongly than that. It is an enhanced JavaScript environment for PlayStation 2, and the description calls it a complete JavaScript environment for creating homebrew applications and games on PlayStation 2.

What makes it different from a plain QuickJS port is the module list. There are dozens of built-in exclusive libraries made for the project, such as an MMI instruction accelerated 2D renderer, an asynchronous texture manager system, an advanced 3D renderer powered by VU1 and VU0, and a custom build HTTP/S client. The promise is that you can almost instantly write modern code on PS2, powered by performant libraries and a fine-tuned interpreter for it.

The modules cover the whole console. System handles file operations, folder operations, mass device control, machine info such as CPU, GPU, memory and temperature, native function control to call C functions, and loading native dynamic libraries. Archive is a simple compressed file extractor with ZIP, GZ and TAR support. IOP is the I/O driver and module manager, with module registration, I/O memory tracking, reverse init and end callbacks and a smart reset routine.

Then Image, Draw, Render, Screen, TileMap, Font, Pads, Sound, Video, Shadows, Network, Socket, Timer, Keyboard and Mouse. That is the entire PS2 feature set, and each is a JavaScript module rather than a C header.

It is built on ps2dev and QuickJS, and the project is MIT licensed. The last push was on 2026-10-19, and the only release tag is latest, described as a development build, dated 2026-08-01.

The render module is the part that is genuinely unusual

The Render module is a high performance 3D renderer, and its feature list reads like a mini engine, which is what it is.

The hardware is used directly. There is a VU1 vertex transformer and a VU0 matrix processor, which is the PS2's vector unit pair used in the conventional way, the VU1 for geometry and the VU0 for matrix maths, and here they are exposed as named facilities rather than as hand-written assembly.

The lighting and shading model is complete for the era. There is a LookAt camera system, ambient lighting, diffuse lighting, specular lighting, polygon clipping, front and back face culling, per-vertex colors, emboss bump mapping, skinning with node transforming, environment and reflection maps, and multiple material processing.

Then three details that reveal the project is used by people who need to hit frame rate. A frame stats API giving draw calls and triangles, described as being for live tuning. Optional zero-copy vertex buffers through `Render.vertexList(..., { shareBuffers: true })`, which avoids a copy of the vertex data on the way to the VU. And a set of high-level helpers, batching with `Batch`, a scene graph with `SceneNode`, and cooperative streaming with `AsyncLoader`.

Those helpers are the interesting bit, because they change the shape of the JavaScript you write. The export model note says AthenaEnv exports constructors on globalThis via ath_env, with no imports from C modules, and the example is:

const batch = new Batch({ autoSort: true });
const root = new SceneNode();
const loader = new AsyncLoader({ jobsPerStep: 2 });

So you construct these directly rather than importing them, and a batch with autoSort means the renderer sorts for you, and a loader with two jobs per step means it does a bounded amount of work per frame instead of blocking on a load.

TileMap is the one module built around a specific renderer

TileMap is described as a high-throughput 2D tilemap renderer built on QuickJS plus VU1, and it is the module with the most implementation detail in the documentation.

It uses a descriptor and instance model for reusing textures and materials, and the sprite buffers are exposed as `ArrayBuffer`, which the documentation says you mutate via DataView or TypedArray. That is a deliberate choice. If the buffer is a plain JavaScript array you copy it into the ArrayBuffer; if it is the ArrayBuffer itself you write into it with a view and nothing is copied, and the whole point of the VU1 pipeline is that the data goes to the vector unit without a detour through a JavaScript heap copy.

The rest follows from the same concern. There is material-aware batching and automatic texture uploads.

The documentation points to docs/TILEMAP.md and to the Functions, classes and consts section for the API and usage, which tells you the tilemap is the module with the most surface area to learn.

The other modules are more conventional. Image gives renderable surfaces in PNG, BMP and JPEG with nearest and bilinear filters, off-screen rendering surfaces, a surface cache system with locks, and asynchronous image list loading. Draw is the shape drawing layer, MMI accelerated, covering points, lines, rectangles, circles, triangles in flat and gouraud shading, and quads in flat and gouraud. Font is text rendering with MMI acceleration, a render-time resizer, FreeType and Image fonts, outline and drop shadow support and alignment support.

So the design pattern across the whole library is the same: the PS2 has specialised units for 2D and 3D, and the modules wrap them rather than asking you to program them directly.

The build switches are how you fit a homebrew into a scene

The Makefile is where the project makes a decision that is worth understanding before you build anything, because it determines what is compiled into the environment at all.

There are named flags for the features, and they default to a sensible split. Graphics, ODE physics collision and audio are all on by default. So are the static keyboard, static mouse and static network, while the dynamic variants of all three are off, and the static camera is off while the dynamic camera is also off.

The naming is the key. A static input device is one that is always present, and a dynamic one is one that can be connected and disconnected at runtime. So a build with static keyboard has a keyboard in the machine permanently, and a build with dynamic keyboard supports plugging one in later, at the cost of the code and the memory to poll for it. If you are building a demo that never uses a controller, the dynamic variants are pure overhead.

Other flags control the shape of the artefact. The binary prefix is athena by default, and the package directory is derived from it. There are also flags for UDPBD, for ILINK, for MX4SIO, for debug builds and for the emulator, with PADEMU defaulting to on, which suggests the emulator support is considered part of the normal build rather than an extra.

The output is an.elf, and the libraries it links against are the ps2dev ports for the pad library, the multitap library, the memory card library, the patches library, zlib, lzma, zip, the file IO library, the elf loader, erl and debug. The header graphic in the Makefile is an ASCII rendering of the AthenaEnv logo, which is the sort of thing that tells you the project is run by someone who cares about presentation as well as function.

Testing on PC is the workflow, and HostFS is the requirement

The coding section is written around the practical problem of developing for a console you may not have open all the time, and the answer is PCSX2 with HostFS.

The prerequisites are given for two platforms. On PC you need Visual Studio Code with the JavaScript extension, and either PCSX2 at 1.7.0 or above with HostFS enabled, or PS2Client for testing. On Android you need QuickEdit and a PS2 with wLE for testing.

The README then notes that you can even create your code on PS2 itself, which is the sort of remark that tells you how capable the runtime is. The environment is a complete JavaScript implementation, so a full editor and toolchain on the console is plausible.

HostFS is the important term, and the documentation goes into how to enable it in PCSX2 1.7.0, with separate instructions for the older WxWidgets interface and the newer Qt one. The Qt version has a further recommendation, to enable console output, which is how you see the JavaScript console output from the game you are running in the emulator.

The visual studio code recommendation and the PCSX2 recommendation sit together because the edit-run loop is the point. You edit JavaScript in an editor on your PC, and the files are visible to the running program through HostFS, so you reload and see the change. That is what makes iterating on a homebrew game tolerable, and it explains why the project describes itself as a complete environment rather than a set of libraries.

The building instructions live in a separate document, docs/BUILDING_ATHENA.md, and the repository carries the machinery for it, with a Makefile.const holding the shared constants, a Makefile.dl for the download rules, a Makefile.embed for the embedded assets, a build-exports.sh script, the src/ directory with the C sources, the ee_modules/ and iop_modules/ directories for the environment and IOP modules, and a native_module_template/ for people writing their own native module.

What the project is asking of you as a contributor

The README is arranged for contributors as much as for users, and the structure of the tree tells you where the work goes.

The src/ directory holds the C sources for the environment itself, the interpreter integration and the module implementations. The ee_modules/ directory is where the JavaScript-facing modules live, and iop_modules/ is the equivalent for the IOP side, which is a separate processor with its own memory and its own module loading model. The native_module_template/ directory is there so that writing a new native module is a matter of filling in a template rather than working out the build wiring.

The tools/ directory holds the supporting scripts, and the build-exports.sh script at the root is the export step for the finished environment. The examples/ directory has one example listed, ode_ray_example.js, which is a fair sample of what a homebrew using this environment looks like, since the Shadows module integrates ODE ray casting and the example demonstrates it.

The assets/ directory holds the embedded resources, which connects to the Makefile.embed file, and the bin/ directory is where the built binaries land. The docs/ directory holds the documentation sources including the tilemap reference and the building guide.

The project also carries the usual governance files. There is a Makefile.const, a .github/ directory, a LICENSE and the table of contents in the README is a hand-maintained details block with a link to the About, Coding, Module system, Contributing, License and Contact sections.

The module system has its own section in the table of contents, separate from the module list, and that is the part that is about how third parties extend the environment rather than consume it. Combined with the native_module_template directory and the fact that the repository maintains separate module trees for the two processors, the picture is of a project built to be extended by people writing homebrew for a two-decade-old console.

Editorial conclusion

Adopt AthenaEnv if you are writing PlayStation 2 homebrew and want to work in JavaScript with the IOP, the VU units, the audio and the network exposed as modules, since writing that in C with ps2dev is a much larger job. Skip it if you need a supported commercial environment, since this is an unfunded homebrew project shipping a development build tag, and if you are on a platform other than PS2, because the modules are hardware-specific. Verify first that you have a PS2 toolchain and ps2dev set up, that your host can run PCSX2 with HostFS enabled or a PS2 with wLE for testing, and which of the build-time feature flags you need, since the Makefile compiles the keyboard, mouse, network and camera support in or out.

Frequently asked questions

Official sources

1. DanielSant0s/AthenaEnv on GitHub
2. Issues
3. License: MIT
4. README
5. Releases