SquirrelJME is an idea and execution that extends from previous ideas and projects. The base idea extends from my desire to write an operating system to run on systems, since such things have fascinated me.

Old Projects (2011/01/15 - 2016/02/25)

These are old defunct projects which I have previously worked on.

I will say that it can take years before you can find a project you enjoy working on and one that inspires you. Keep searching. Just be careful where you step and do not take in more than you can handle.

HandOS (2011/01/15 - 2011/01/22)

This was an attempt at creating an open source implementation of Palm OS. Palm OS was not actively used much often and additionally existing emulators for Palm OS are sub-par in that they were either old or were horribly out of date. The goal of the project was to run m68k and ARM Palm OS applications on the host system.

The project was fully structured and had all the default applications in place as placeholders for when they were ready.

However, the project could not actually be compiled, it was mostly pretty much just placeholders, some reference documentation, and notes. It did include some tests which showed that threading was indeed possible on Palm OS like modern systems.

MPA Orange-Sapphire (2011/12/12 - 2011/12/13)

This was a very short project which never really took off. It was intended to be an operating system written in a BASIC-like language. Obviously BASIC is rather horrible compared to the languages of today.

MPAYAOS (2012/02/20 - 2012/02/29)

Standing for Yet Another Operating System.

This was a short attempt at another operating system, it never really got past the bootloader stage. It was written in C.

HandNIX (2012/05/28 - 2012/05/29)

Standing for Hand UNIX Environment.

This was an attempt to make a UNIX-like environment for Palm OS so that I could do development for my projects on Palm OS. It existed as a single C source code file.

Only a few things were implemented. The major thing which was implemented was a basic cooperative tasked system which was based on Palm OS's versions of setjmp and longjmp. There also was a basic terminal emulator which did not support any escape sequences.

Every POSIX command that existed on the system was referenced via a function pointer and the intention was to have virtual files (via #!) which would execute those internal commands when requested. The environment would have started on the shell (sh) which would then be available to execute other programs.

HandOS 6.3 (2012/05/31 - 2012/08/17)

HandOS is a clone of Palm OS, however the main purpose of this project was to implement the only released in a simulated environment: Palm OS Cobalt.

It was written in C and it required the Palm OS SDK for compilation.

I did not have headers for Palm OS 6, so I was writing the headers from scratch.

MPAPCOS (2012/09/30 - 2013/01/16)

Standing for Posix Compatible Operating System.

This was an attempt to write an operating system which was compatible with POSIX:2008 and could run such programs. A C preprocessor was written and some basic utilities were supported, but generally that was as far as it got.

HandOS 5.6 (2013/01/23 - 2013/02/05)

This was another attempt at writing a Palm OS clone, it did not get very far. There was basic project structure but not much else.

MPAMSEK (2013/03/31 - 2013/04/14)

Standing for Multi-System Emulation Kernel.

This project was I believe to write an operating system which could run many other operating systems in a very bare bones emulated environment to run as if it were on native hardware. Basically, you would boot into a system and instead of running an OS with an emulator running on it, the emulator would be directly running on the hardware.

I only really got a basic system launch on PowerPC's Open Firmware. I was able to print to the system's framebuffer console but not much else.

MPAOSKP (2013/04/14 - 2013/05/15)

This project is based off MPAMSEK.

I am not too sure what the acronym stood for, very likely it stood for Operating System Kernel Project.

I wrote a memory allocator but it never really got past the boot loader and early kernel initialization stages.

PowerPC and x86 worked on Open Firmware.

I failed to get SPARC working, I could just not get the bootloader to run properly and it usually ended up just crashing or not working at all. It may have been related to register windows.

I thought about writing a C compiler but I gave up quickly and abandoned that idea because that would be too much work with too little of a benefit.

POSIX Environment for Palm OS (2013/07/25 - 2013/07/27)

This project was essentially similar to an earlier but was a POSIX environment for Palm OS. By reverse engineering bits of Palm OS previously I determined that some things were very possible. For Palm OS 5 I had pretty much a concept background threading and server system. Basically a daemon would be launched in the background which would keep the environment running. There would be a connection made to the daemon with locks and semaphores. There would then be a terminal interface which would show what was being output to the console.

There would be threads in the background running tasks. However to access the server process a pointer would have to be remembered. This is where the feature manager was used to keep a persistent handle in memory so the daemon could be connected to. I determined that it was very important to be able to switch programs outside of the environment.

For SquirrelJME on Palm OS, I have an idea to do something very similar so that it runs in the background while other applications may be used.

POSIX Environment for Palm OS (2014/10/12 - 2014/10/12)

This project never went past a few files and headers. The purpose of this project was the same as the previous.

k5 (2013/12/25 - 2014/04/25)

This project had 503 commits.

This is basically the start of my delving into Java virtual machines. It was written in Java and was pretty bloated when it came to the compiler, using very abstract concepts for compilation. It was to target Java SE but I am not too sure which version it was for. Very likely it was Java 7 as Java 8 was released shortly before this project ended.

I never really got past the JIT stage in the project. It was also quite massive of a project.

Anything that was made for the documentation was written in LaTeX, which is far less friendly compared to Markdown.

k8/Squirrnix (2014/04/26 - 2016/02/25)

This is the direct predecessor to SquirrelJME. Utilities and classes in SquirrelJME have been derived from this project. Generally if I find a class which is missing in SquirrelJME I check this project and copy all the code from there since the bulk of it is just placeholder.

This project had a massive number of commits: 9041.

It intended to implement the entirety of Java SE 8 with all of its profiles. This was for the most part a very unrealistic goal. As with k5, it never really got past the JIT stage. The massive requirements in place were unrealistic. This project was doomed for failure even when it began but I was a bit foolish to take up this task.

SquirrelJME

Starting Background

SquirrelJME stems from the following ideas:

I had a growing fascination with J2ME. I had an old cell phone which could run J2ME applications. I would make a few concept projects but they did not last long because programming for J2ME is quite horrible as it is very lacking when it comes to Java. I did have the idea of writing a virtual machine that could run J2ME applications so that I could use some again.

Another thing is that the write once and run anywhere aspect of Java pretty much fascinated me also. The idea of writing a program once and having it work pretty much everywhere was indeed interesting. I wanted to do this with k8 but it was not really a feasible thing to do because it was so gigantic.

However, there was much frustration with my then current project k8. It was gigantic and the number of classes to implement was essentially an impossible mountain to cross. There was a growing sense of doubt that the project would never get anywhere because it had unrealistic goals that would be impossible for a single woman to obtain all by herself. I calculated that it could take perhaps up to a decade to implement the core classes of Java SE 8. By a decade's time, Java SE 8 would be obsolete and nobody would be using it anyway. So this compounded a wasted effort. Additionally, being a third-party VM, there would quite literally be very little interest in it, so it could not be for fame. Basically it was too much and too ambitious of a project and sadly it took two years to realize that.

Near the end of the project's life span I was a very depressed person, I felt like the project was a complete waste of time and that life was rather meaningless. I felt trapped working on the project with no escape. My life was melting away into nothingness and worthlessness. I did not want to admit that the project was a failure and would be going nowhere, I was naive.

In February of 2016 I watched Hack Summit 2016, it was pretty much the first online conference which I have visited. It was really exciting. It did move me a bit. However, I think the one talk which really moved me was the one by Sarah Allen (you can see her on YouTube here: https://www.youtube.com/watch?v=S1iYeThQO-g). It really resonated with me. It has really given me the light shining through my own fog to realize that my own project was ruining my life. After that I decided that my own project was not something I really wanted to do, that my ambitious goals were not even caring for myself. I decided that I should care more about myself and that I had to cut my project loose.

When that happened, I was still so very much interested in Java and having write once and run anywhere, portability and virtual machines. I found Java to be very awesome. I knew that k8 would never fit on the systems I would have liked to target. I got the motivation to push Java as small as it can go. I knew the gigantic size of k8 was too much, so I decided to switch to the small scale. I remember my fascination with J2ME, I wanted to clone that environment because I found it interesting. Java was seen as this gigantic bloated monster that ate so much CPU and so much memory. But working with the JVM so much made me realize how wrong it was. Java was in fact very small and very light. J2ME was very light and very simplistic.

The first thing to do is determine has J2ME been updated ever? To my surprise it actually was updated for Java 8. So this was quite something. Although it was not really a microscopic Java 8 VM it was Java 7, which was good enough. It added extra classes and was in general quite cool. JSR360, which is the specification for Java ME 8 was proposed on October 2, 2012. The final release was made on April 30, 2014. Java SE 8 being released on March 18, 2014. So Java ME 8 came out very shortly after Java SE 8. However, with Android and iOS being everywhere it never really stood a chance and Java ME 8 never really got the chance to actually be anything.

I decided to study Java ME 8, to see if it was indeed viable. I took a quick glance at it and then deeper dives into it. Java ME 8 imported quite a number of things from Java SE 7. It basically was bringing it up to date with the modern Java language rather than languishing in the past. It did remove some things but, in the essence of compatibility those could still be brought in. These removed things were stuff such as LCDUI, which were pretty much nowhere. It took a bit to verify compatibility but the changes made do not have an impact on backwards compatibility. As such this was a bonus.

One added bonus that I liked is that Java ME was so small compared to Java SE. It is very tiny and extremely compact. Basically what is in the language is the bare minimum sane choice. I will say that there are some errors and perhaps some omissions but in general it has been rather good. The thought of Java SE being implemented and the gigantic task I knew was impossible and the small size of Java ME is actually is within reach. The small number of classes, up around 512 classes for the standard makes it very reasonable. This estimated 512 classes is about half the size of Java SE 8's compact1 and does not include things such as SQL. I really liked the fact that it gave you the minimum set of classes and you could just bring your own classes in if you care about it. Personally, I do not really care for SQL and stuff like CORBA because I do not often use them at all.

Naming and Mascot

The name SquirrelJME comes from the fact that I personally find squirrels to be very interesting and curious animals, not to mention that they are cute. Where I used to live I would see squirrels all the time so they were quite common, although where I live currently as of this writing I do not often see squirrels.

Originally my plan for a mascot at least for k5 or k8 would be to have a pink bunny rabbit in reference to The Legend of Zelda: A Link To The Past. In this game there is a region that you can enter called the Dark World where every human who enters is transformed into an animal that reflects their inner self. I then switched my idea to having the mascot be albino because these animals are a bit more rare (since they are more easily predated in nature because their bright white fur stands out). Then when SquirrelJME has come around I decided to keep the same mascot but make him a squirrel instead. So the green tunic that Link wears is a reference to the Zelda series.

It was difficult finding a name for him, as such I initially decided on just placeholder name for awhile. I thought about Lexer but that was quite long and slightly complicated, so I shorted it to Lex. It was nice and for the most part the name stuck since I was happy with it. Therefor it was never changed.

He was uploaded on 2016/05/07 to the repository.

He has subsequently been redrawn on 2018/10/19 by Kat Adam-MacEwen, where he ended up very handsome. She is quite a wonderful artist.

The C based virtual machine RatufaCoat was named by meepingsnesroms of the Mu project. Ratufa being the sub-species of squirrels in southeast Asia.

Gaining a Sister Project

On 2018/11/03 the developer of Mu, meepingsnesroms, wanted to become a sister project of SquirrelJME, so this was very exciting! The link to her repository is in the readme! We will be cooperating mostly by word of mouth by linking to each other's projects to hopefully gain interest in both of our projects.

The First Release

The first version of SquirrelJME was released along with Mu on December 25, 2018. The repository had 10,571 commits. This version spent two years in development.

This release was mostly just a demo to show that SquirrelJME exists and that it is being worked on. It is very primitive and not much can be done with it. From the release though there has been slowly increasing interest in the project since there are not many emulators that support J2ME that exist and are actively worked on.

The Second Release

This is the currently being developed release. In 2019 without knowing the calamity of the year 2020, I put down here:

It is expected to be at most in development for two years and six months in development.

Naturally, as of this writing I am now at the two years and six months mark. Having lost probably a year of productivity during 2020, this will definitely mean this release gets pushed back.

• There is this article here you may read!

2019

The history from January to June was taken from a note, although it was never completed.

January

This is the month that was right after 0.2.0 was released. I started the initial work on SummerCoat which has taken pretty much the entire year and more to develop, it is a really complex system and it really shows. From this run I had the initial SCRF compiler which would eventually be thrown out and which would result in the current compiler that I wrote. I even had a base project setup for RatufaCoat at the middle of January. I also performed some refactoring of the compiler stuff as well making it cleaner because it did get a bit messy. I did get method processing put in but that was later split apart because wow it was complex. Also added a bunch of new tests and implemented parts of the class library since they were needed for the VM to function. I figured at this time that I should write a compiler which is not all that optimized to keep it simpler, although today I do have basic optimization in place. For CircleCI I put in JUnit reporting for the tests that ran which has been around for awhile now. Also, for the tests that run within the VM, the profiler snapshots are stored as well so that way I can determine how fast stuff has been running accordingly. I defined an API level for 0.4.0 but eventually later in the year I determined that the API stuff is too complex, so I opted for the much simpler system call stuff. I added system properties support for SpringCoat since I needed to enable or disable debugging.

February

More work was done with SCRF. Added the ability to launch tasks with system properties and such. SummerCoat VM went through a slight refactor as well. Some of the stuff that I worked on this month have somewhat survived to the end of the year such as the stack map stuff which worked well. I mostly just implemented a ton of methods. Not much here this month.

March

This month was very rough for me because I had gotten laid off at the start of the month and it was devastating to me. I pretty much still worked on this project because it helped me get through the rough times and it also acted as a resume for me as well. I was in and out of depression so I did not exactly work on this every single day as I was job hunting as well.

One big thing I did was remove tool-scrf and put it in tool-classfile and built it up from that. I know in 2020 I will be pretty much splitting that back out and writing a far more streamlined compiler which hopefully is faster and more efficient as well. This is where the MinimizedClassFile started from so it has quite been around. It is still around and it has always been improving from this point. SummerCoat had this class library kind of thing that basically cached single classes and such I believe in memory. I know with the compiler refactoring I brought stuff back in from SCRF since it still worked just fine. For the class file stuff I implemented more things that were missing such as the exception handler. I had all of the narrow and long stuff which was a bit confusing, I know later this eventually was removed because it was just impossible to handle while keeping things simpler. I know today that everything is 32-bit for the most part. I also worked on the graphics stuff too, which is interesting. This was even the advanced graphics stuff. This graphics stuff needs to be refactored but that will get done eventually. I also worked on Squirrel Quarrel when it was a Starcraft clone still, but now today it is more of its own original game that I have planned. You could kind of play it and command units I think and such. For graphics I added a serializer so that it could be done by the host VM, being faster. I may do that again for SummerCoat although it would be a bit more difficult. This was also when I was more going twords https://squirreljme.cc/ instead of my standard domain that I use. I also am actually glad the complex type handling was removed from SummerCoat. Even reference queues and such were their own instructions, but now that is different.

April

At the start of this month I did some fixing of the class parser. I did lots more compiler work. More library methods were implemented.

I renamed my Twitter and used my MultiPhasicApps handle for SquirrelJME stuff, which actually helped me much.

I worked on the graphics stuff. Implemented some base record store stuff which was nice. Refactored XPM and PNG image loading. Added a Null Audio system.

Lots of more compiler work.

Later in the month I completely refactored SummerCoat, it pretty much should be the same as it is today just more worked on.

Also corrected testing stuff.

At the end of the month I put a bunch of work into the fonts too, I did so much with them! I actually still need to finish the symbol fonts a bunch too.

Also kinda glad I do not have class IDs and such today as well.

May

More font stuff, yay!

This month I added the concept of BootRAM and this has actually simplified things making things easier to load and such.

Added some more implementations to methods as well and HTTP support!

Also big refactor of the testing framework, which ended up going rather nicely. I also added my first sorting algorithm which was ShellSort. However, I guess now there is just block sort which does nothing? Oh wait no there is ShellSort.

June

The notes stopped before June, so this and anything following was written much later on at the end of 2020.

This month there was much work done on RatufaCoat and SummerCoat since they are shared. The compiler has seen a number of changes as well. There was much going back and forth, fixing things, and debugging things. A compiler and virtual machine combination is very complex. Additionally, at the end of the month SummerCoat got profiling output.

July

This was the month when I was hired for my second programming job, as such from work there has been a great reduction in available time to work on SquirrelJME. However money is important, I was a single month away before I would have ran out which would not have been good.

At the start of the month I worked on Squirrel Quarrel a bit, I am assuming at this point I was to make it a turn based strategy although it may have been a real time strategy.

I did port RatufaCoat partially to Palm OS however it was not really functional and there were a number of limitations. Other than that, there was more minor work on SummerCoat/RatufaCoat. I decided it would be best to split the constant pool into a static pool with a run-time pool, that is still here to this day, however it is something that has simplified and reduced the need to load everything at once.

However due to my new job, the month mostly just had progressed at the start.

August

Due to my job, there was little progress this month. I worked a bit on the compiler, refactoring it and otherwise.

September

This month more work was done on the compiler, mostly with fixing bugs, making it better, and other such things. I did do much more than what I did the previous month however.

Unrelated to other things, I did put in support for a demo that requires a proprietary JVM to run a game.

October

Worked more on SummerCoat and attempting to get it booting up and otherwise. This would prove to be very difficult for me to do.

Otherwise, not much was done this month.

November

More work on SummerCoat and such, there were optimizations and fixes.

Most of this was done during the holidays where there were few days off.

December

Very much this was more work on SummerCoat. It was much work and I was getting more and more burnt out from working on this.

2020

Virtually everyone who has spent some time in 2020 will know how rough the year has been, there were no exceptions for myself.

January

I worked a bit more on SummerCoat but slowed down greatly, I decided to implement some other classes and such.

February

This was a difficult month... my close friend Emily passed away at the start of the month. I was devastated and was broken from it, I remember being at work and hearing the news and I sunk in my chair. I remember going outside and sitting on the small bench employees went to for their break. I broke down and cried. I remember calling my fiance and asking her to pick me up early from work. I knew she could tell that something was very wrong. I stuttered to tell her. My fiance comforted me so much. I still think of Emily often and I feel an emptiness inside of me when I do so. Typing this is difficult, but... I will remember her always. She was a close friend to me and we would talk so often. I do know that she was very thankful to have me as a friend. I hope that she is resting in peace.

Being devastated, I did my best to distract myself.

I remember just sitting down and was thinking how many months have gone by working on SummerCoat and such, being in an endless loop. I decided to change how I was doing SquirrelJME to use more modern development tools. I had always previously wrote it using a basic terminal and a basic text editor. I decided to make the switch to IntelliJ, which I can definitely say made development much easier. The first most important thing to do was to setup the Gradle build system, which I was doing. I never went with Gradle in 2016 because it was too limited, however in 2020 it has gone far enough in development to where it could work well with SquirrelJME. I did major cleaning up and otherwise. Organizing things and setting up testing like I had before. I setup a basic JNI wrapper for native calls since I need to do SquirrelJME things in Java SE to run them properly. I worked a bunch on the dependency system and otherwise, building a SquirrelJME plugin that could do everything I needed. I additionally started development in branches so I could do multiple things back and forth, this would help at times with ADHD.

March

SquirrelJME for the time was keeping me distracted much, my fiance was there for me as well. At the start of this month I married her, so from now on she is my wife. I know she has helped me get through this year so many times and I love her very much. We married the day before lockdown, we were very lucky.

For SquirrelJME, I continued on the Gradle work. By the second I had already merged in all of Gradle changes. It did feel good the direction this was going and it was the start of taking a new path. I know there were many thoughts to when I started SquirrelJME, how it was basically started from the realization that I was going nowhere with my SummerCoat work. So that was shelved for awhile.

I started work on bringing up SpringCoat. This would involve a large number of refactors and otherwise, to improve the old virtual machine I was intending to originally remove. I decided it would be best to keep SpringCoat because it is an additional vector into making sure things are operating. At least with the optimizations I have done it much quicker. I effectively continued it throughout the month. I made much progress. By the end of the month much was done but there was still a way to go.

April

This month started with continuing the refactoring and upbringing of SpringCoat. For the most part it was continuing but at a slower pace.

May

For the most part, I continued work on bringing up SpringCoat. However after about two months of working on it I realized that I was falling into the same pit as before with SummerCoat. So I decided to backpedal and start a new branch which was effectively cherry picking what I did. This was the second half of the month.

I had previously rewritten TAC, which that was cherry picked. I picked up some other things, but I suppose a bunch of it was dropped. This is okay though. This cherry picking was merged into trunk.

I additionally at the end of the month did a bunch of syntax and miscellaneous cleanup, this was a nice way to organize.

At the very end of the month, I decided that I needed to do this another way. So SpringCoat was very high-level and SummerCoat was very low-level, but it was difficult to bridge these together. So I decided on an idea of having a Mid-Level Emulation (MLE) which would bridge the gap. This is still around to the time of writing, so it has definitely been a good decision.

June

The first half of the month, little progress was made as I was mostly thinking about the best way to do things. It was thinking from nothing again, but I eventually figured it out. I did so some refactorings and such naturally.

However the second half of the month, I did much more work. I improved testing. I wrote new APIs for SpringCoat and put these on the emulation layer. I decided that it would be best if SpringCoat not do any Assembly stuff since that was complicated and I did not want to handle that for now. I did end up doing much work on SpringCoat as well. The speed increased more and it was much better.

At the very end of the month, I worked on utilities to replace the old shell scripts so that I could develop purely on Windows rather than a Linux VM.

I continued to do much more work on Mid-Level SpringCoat and eventually merged everything in accordingly! It was a very nice feeling.

July

This month was my birthday month but also I started work on Mid-Level LCDUI Refactoring and work on access control. Also the ability to launch tasks was added as well in the access control branch. Otherwise the Mid-Level LCDUI work is basically a complete refactoring of the LCDUI code. Before I had something that was too high and native while another that just used the framebuffer. So I decided to take a path that would allow both. For now it is based on Swing but it is very possible for it to be backed on a Framebuffer. Naturally for what is running on RetroArch will be using the framebuffer along with any system that lacks native widgets. However, for the systems that support it, it will effectively reduce the work that is needed to be done to make everything consistent to make it feel like it would be for that operating system.

The access control stuff carried on a bit and I decided I could really use what I wrote via the tasks, so I forked off that branch and merged that into trunk. I then merged trunk into the other branch. So this way whatever work I done could be used. Since access control is not too important. But otherwise, I made improvements there.

Near the end of the month I started on a slight refactor to RatufaCoat and switching it to CMake. Using CLion which is a very nice IDE, it should make it easier to work on it. It took about two days to do all of this so it was a really short-lived branch. But other than that, it did pave the way for refactoring of RatufaCoat. Regardless though I took a short break on the LCDUI stuff since I have been working on it for awhile.

On the 28th, I spent a day working on a user guide and a FAQ to answer some questions. This gets synced to GitHub accordingly. Something I feel is important since people tend to ask a bunch of questions about this.

August

This month I continued work on the LCDUI refactoring. I also started a new branch for refactoring the handling of the many virtual machines and the means for testing it. This work has been very helpful as I still use it and it is helping me progress and making sure everything is tested.

I also additionally started work on refactoring RatufaCoat which is ongoing but that is expected as I wanted to start some of it through interest despite SummerCoat itself not being ready. Of course once SummerCoat is ready I will likely work on this.

But majorly the month was spent on the build refactoring.

September

This continues the build refactoring and by the second week of the month I merged it in. It has been very beneficial. But from doing this and taking a break from the LCDUI work, I continued work on that. Pretty much the entire rest of the month was working on this.

October

This month continued the LCDUI work. At the start of the month I removed a bunch of the old code as it was no longer needed. Other than the LCDUI work I did some additional changes to the CI/CD pipelines. Progress on the LCDUI was scattered though and was generally slow to progress.

November

This month at the start was more of the same, working on the LCDUI. However after about half the month the branch was merged in. It was not 100% however it was at a level I was good with and I did not want to drag it on for more. So I took what I had and merged it in.

By the end of the month I started work on building the SummerCoat ROM, this was a combined image file and otherwise that would be needed by SummerCoat. This was mostly just to get the tasks running but not a ROM that could actually be ran. However I did merge this in.

After that, at the very end of the month I started working on Mid-Level SummerCoat. Like MLE SpringCoat, this was a refactor and simplification of SummerCoat, so I could get things running again.

December

This month I continued work on Mid-Level SummerCoat, although work has been scattered. I have been making very good progress on this however, since whatever progress I make is good.

Other than that, at the end of the month I started work on doing the completion counts which would be used to determine how far I am with standard API implementations and otherwise.

Near the very end of the month, publishing was added to Maven Local, BinTray, and OSS SonaType. This would allow documentation to potentially be downloaded or browser, but will mean that SquirrelJME can be consumed by others. There were additional fixes to task launching.

2021

This was written up until August 3 years ago, as it is now 2024, however I am completing it now. A few years to catch up but they were quite some years.

January

I finished up the end of the year fixes on launching on the first day of the month.

I essentially spent this month working on mostly SummerCoat, would say good progress was made on this.

There were minor fixes to the RetroArch build.

I planted roots for better graphics handling that would allow for more accuracy and acceleration.

February

I started the month working on SummerCoat, but also decided I wanted to work on RatufaCoat as well. So half of the month was dedicated to each. Before this point, the RatufaCoat work was based on trunk but I then switched it to be based on the SummerCoat WIP since there would be no other way to reliably work on it. I also did major CMake work on this branch, since it is a very nice build system.

March

I continued work on the RatufaCoat branch, making good progress and cleaning up accordingly.

I discovered that there is an issue in SummerCoat, but it was disparaging to find and fix. There was not much motivation to do so. I needed a debugger first and foremost.

I started work on shiny new JDWP support, which would help with finding issues and otherwise.

I did attempt to cherry-pick the improved LCDUI event handling but that failed, however that eventually got brough in by a future cherry-picking in July.

April

This was a big month for the JDWP support, I finished the debugging support for SpringCoat which allowed me to find potential issues and otherwise. Being able to debug in IntelliJ was very useful as well, although it is not the only supported debugger (Eclipse and JDB are supported).

Otherwise I worked on support for software float.

May

Base64 had some fixes and improvements, along with the addition of encoding to Base64.

A class dumper was added so that I could debug the SummerCoat compilation issues that existed. There were bug fixes centered around this. From this a discovery was made that SummerCoat's handling of stack exchanges was incorrect. However, there was not much motivation to fix this, it just made a bad feeling in me.

I made a WIP branch for an SDK, which will be a modern way to develop for SquirrelJME and J2ME.

June

Not much was done this month other than the detection of i-Mode titles in the launcher. Previously I planned to have a separate launcher that did this but I decided against that since it would be better if it were all included at once. This should make it easier to use this software. It does though require the two files that are needed. In light of needing these additional support files, I improved support for non-JARs in the library pickups.

Other than this, there was minor work and optimizations on SummerCoat.

Fixes were made to LCDUI and the floating-point functions were corrected.

At the very end of the month, one of my closest friends Near passed away. I will miss you lots, you helped me immensely, you will be missed always. It was an honor to be your friend.

July

I decided this month to celebrate my birthday for the first time in a very long time, since it has never really been a day I wanted to celebrate ever. I had a wonderful birthday with my wife, who makes me very happy. I decided to add an extra candle for both Emily and Near, since they never really were able to celebrate their own birthdays. I wanted to do this if at least in spirit.

Additionally, at work I was placed on an important project, which at times I would be working overtime. So I am doing my best to maintain a work/life balance.

By the end of the month I very heavily realized how long the SummerCoat branch has been going on for, since November 2020. I could not find the heart or feeling to work on anything in SquirrelJME because this branch was just too big, I made unrelated changes in it that were very important. Probably one of the biggest things I have done this month is cherry-picked into trunk from this branch.

These cherry pickings include:

• All the various Gradle changes and fixes.
• Base64 fixes.
• Fixed event handling for LCDUI.
• LCDUI form related functions.
• MLE changes that I want to keep but both affect SpringCoat and SummerCoat.
• Fixes to SpringCoat.
• Optimized and corrected sorting algorithms (ShellSort).
• Software math support for float and long.
• Additional tests which caused compilation issues within SummerCoat.
• Task improvements.

Additionally, the WIP branches for BuildVM and RatufaCoat had an improvement for the automated tests. The list of lists are now dynamically generated rather than having to copy them into two separate locations, this will make it easier to use and otherwise.

The long-standing SummerCoat issue was fixed and corrected this month with an unoptimized, but working, solution.

August

There was not much done this month, I mostly just continued work on the RatufaCoat refactor.

September

Apart from RatufaCoat work, I did update the branding for this month, updating and simplifying the copyrights and making sure all the logos or otherwise have been placed in the repository.

October

More RatufaCoat work, this was starting to drag on.

November

More RatufaCoat work still, definitely continuing to drag on. I started some work on UI reworks, however I would stop and pick this up a bit later.

December

Not much done other than RatufaCoat work.

2022

This year was more or less much the same. Looking back at it from 2024 in this retrospective, even though I did not have much free time to actually work on things, there were a few good things in here. Unfortunately, I did not have the time to really sit down and think what I wanted RatufaCoat and otherwise to become.

January

More RatufaCoat work.

At the end of the month I did some Gradle refactors in trunk to make testing better and easier, along with debugging.

Additionally, at the end of the month I finished the work in the UI branch and merged that in. It was mostly just minor improvements and DoJa support.

February

I performed some cleaning up of the modules to get them more organized and neat. I did open up the GIF support branch, although did not work on it much. Most other cleanups I did were UI related. There were also various other fixes and adjustments to the UI. I definitely had a thought on making new UI code, however that would be quite a thing to figure out first.

Shift-JIS support was added for decoding Japanese text such as those in DoJa titles.

Some minor work into running a few DoJa titles.

March

Adding support for handling KJX files, which are just JADs prefixed to a JAR. Additionally, to support this, raw Jar access was added in so that libraries could be read directly.

More RatufaCoat work.

April

I took a break from RatufaCoat this month to work on MIDI support, I spent the month working on this mostly.

May

Continued MIDI work.

A cherry-picked a bunch of nice changes I had in the RatufaCoat refactor branch such as the ability to perform full complete tests.

Other than these, I continued work on RatufaCoat.

June

More work on RatufaCoat, I did some more cherry-picking surrounding various fixes I have done since it was a long-running huge branch at this point.

I did fix PNGs being corrupted, however.

TODOs and Debugging notes were completely refactored, which ended up being a very good thing to do for consistency purposes.

I also worked on more GIF reading support.

July

Minor work was put into GIF reading.

Made fixes for M1 macOS systems since those were not working too well.

There were some additional methods in Collections implemented.

I also started an experiment on a framebuffer based UI interface, however that did not go anywhere.

August

I started work on SummerCoat AOT code generation.

Also worked on JavaDoc writing to markdown, partially.

September

There was a bunch of SummerCoat AOT work, but like RatufaCoat it started to feel like a bad idea.

On the otherwise, there was a positive which was a complete rewrite of the testing framework to take advantage of Gradle's testing features. This would allow me to see test results in IntelliJ which was pretty important as the number of tests have been growing constantly. I still use this to this day, and it was well worth it.

I additionally made some debugger improvements.

October

More SummerCoat and RatufaCoat work, reluctantly.

I added some more support for DoJa titles.

November

I took a break this month.

December

I continued work on SummerCoat and RatufaCoat. Making lots of new code.

2023

This was quite a year, most of it I feel was wasted, but it started to turn around in July.

January

More RatufaCoat and SummerCoat.

I started work on some ideas I had surrounding the UI, but ultimately that would not really lead anywhere.

One of the bigger and more important things was tagging all the methods, classes, interfaces, and packages with the new @Api annotation.

At the start of the month I started to work on utilizing ProGuard to make SquirrelJME ROMs a bit smaller by obfuscating them, mostly using it as just compression of sorts.

February

The work with ProGuard continued, this was merged in after about a month of work and has been going very well so far. I made a very extensible system and the ability to add some extra options for use when building libraries that get obfuscated. Additionally, there is @SquirrelJMEVendorApi which was very important. ProGuard I would learn would delete lots of code and otherwise, which SquirrelJME being a library for the most part was very problematic. Luckily it was worked around. This work was merged into trunk!

I did more cleanups and any vendor specific APIs I prefixed with vendor-api in the modules, this kept everything nice and organized and easy to find. Very helpful in the long run.

March

More RatufaCoat work!

April

I added support for JVLite2 binary ADFs which were the raw storage types used for some DoJa phones.

More RatufaCoat work, however at this point I was completely drained from working on it.

May

For most of the month, I took a break from things.

However, despite the break at the end of the month I would do something pivotal to the project, and that is abandon RatufaCoat and SummerCoat. I created the new NanoCoat which I intended to be much smaller and otherwise. It would be simpler, be a basic interpreter, and otherwise be much cleaner. Seeing as I am writing this August 2024, I will say that NanoCoat has been progressing very well. I will say also that some projects are not meant to be.

June

I was pretty much excited with NanoCoat, so I worked on it much, building it up and otherwise. I was being more thoughtful and careful this time around.

July

I continued work on the foundations of NanoCoat.

I added a number of tests for Java byte code instructions and otherwise to test out in SpringCoat and ultimately eventually NanoCoat. These were very helpful in figuring out some weird quirks of the JVM.

I also started using the JetBrains annotations for code inspections, which to this day have been rather helpful. Those are more for reference and so that the code inspecting and otherwise would have an easier time of things.

There was an old DoJa branch which was sitting around as well, I merged that in since it was pretty stale.

August

More work on NanoCoat.

For IntelliJ, I added file scope colors and otherwise, which helps at a glance see which class I am looking at. Java standard APIs are purple for the most part. Out of tree stuff is a different set of colors.

I also fixed a SpringCoat issue that I would say is called: invokespecial super.__packagePrivateMethod(). Which is a very one off edge case which one would likely not hit.

I also started an experimental branch for JFR, however that has not been worked on since. That was mostly just an idea of getting profiling working in IntelliJ, but VisualVM works fine for now.

September

Mostly just minor NanoCoat housekeeping.

October

Most of these days I was not working on the project, if I did for the few days I just made some NanoCoat changes.

I also got laid off from my job at Philips, so after the shock of that I would definitely have more time than I thought I would have to think.

November

I continued work on NanoCoat.

December

This month I merged in NanoCoat, it cannot run anything yet however I did not want it to drag on like RatufaCoat and NanoCoat. I felt that it was fine enough to merge in, which ended up being a very good decision to make.

I mostly worked in trunk this month, making a bunch of fixes and refactorings to the standalone environment.

There were also some more core NanoCoat code along with their tests as well, such as memory management. I did so much foundational work in NanoCoat for stuff that is still around to this day. I was invigorated and energized from this.

2024

Much was done this year making many improvements in many places.

January

I did much to improve and refactor the JDWP support in SpringCoat, along with building my own debugger interface. This was a very nice month for debugging.

February

I started work on a Calendar implementation to run one of the MMBN games which for some reason used that class, not sure why.

I also additionally worked on descriptor and name parsing in NanoCoat which has gone very well.

I finally got back around to MIDI support and merged that in. With the help of my musically inclined wife, she was able to help me figure out MIDI timings and otherwise. So very much thanks to her!

At the end of the month, I had a new idea for the UI: ScritchUI.

March

I started work on ScritchUI, basically to replace the old UIForm interface which was a giant mess and difficult to work with. This would be very pivotal work in terms of UI support.

I added building of FlatPak containers as well, so you could run standalone as a Flatpak.

At the end of the month, I closed all the branches for RatufaCoat, SummerCoat, and even an extended version of SpringCoat. I was feeling very good about NanoCoat and ScritchUI, like a breakthrough very good feeling.

April

I did mostly cleanups and work on ScritchUI.

May

More of the same, ScritchUI work and otherwise. ScritchUI has been really shaping up very well. It was clean, efficient, and easy to implement for. It also fixed some glaring issues with some software.

June

ScritchUI had a bunch of nice changes that were not entirely related to it, so I cherry-picked those into trunk. This helped reduce the scope of the branch and made the nice features of it mainline. It was at this point that I decided it would be best to finish off what I had, get Windows support in and worry about macOS later.

July

I continued the ScritchUI finalization and Windows support and spent most of the month doing final cleanups, specifically around images and buffer support, such as drawing and otherwise. I made ScritchUI serialized and single threaded, where it would force everything to happen in the UI thread. This was very important for all the different UI frameworks and how broken they are generally. Also as well, how broken applications are in a modern multithreaded multi-CPU world.

August

I finalized ScritchUI and got it merged into trunk. I was very happy about this. ScritchUI took about five months to develop from scratch, but it turned out very nice.

I did start a branch for Cocoa support in ScritchUI, but that is a side project for now.

Otherwise, I started work on Zip support along with many helper utilizes and weak references in NanoCoat.

I do start a new job back at Philips at the start of next month, so we shall see how that goes.

September

This month I finished up the work I was doing for NanoCoat around class parsing and got that merged in.

October

I started work on code execution and everything that it depends upon in NanoCoat. I continued work on the macOS Cocoa user interface. There were also miscellaneous changes as well. One big thing was the addition of the RSS feed, which would be very helpful.

November

I continued working on code execution and various other miscellaneous changes.

December

I really needed a break from NanoCoat, so I decided to take on. I worked a bunch on the macOS Cocoa interface along with many minor miscellaneous changes in trunk.

2025

This was written October 2026, thus very late and almost two years later.

January

The branch wip-nanocoatexec was continued on, although this branch did not focus on all code execution aspects as intended it did put in much of the groundwork that is still in NanoCoat as of today (October 2026). There were some byte code implemented such as ldc, however much of that was limited as previously stated. This is also where StringShelf started existing which completely redid how strings are handled in SquirrelJME. This effectively just made strings just better. Naturally this was cherry-picked into trunk.

Unrelated, wip-calendar got some merges from trunk to keep the branch alive although nothing else.

Regarding trunk, it received a minor ServiceLoader improvement around caching along with a limiter on System.gc() as some titles love to call that method.

I also posted about SpringCoat.

February

I did find out that DataInputStream.readUTF() was completely broken after reading single byte characters across read() barriers. Such barrier is hit when two characters are attempted to be read for a multibyte character, however there is no character yet available in the input stream. This is a fix to old code from 2018.

ScritchUI got some buffer overflow fixes, which is always good. There also were improvements cherry-picked from wip-cocoa, which as of today (October 2026) is still around in a branch. Graphics can also be closed.

A very important thing however is wip-serialpen which is exactly what it says on the tin. It serialized ScritchPencil, effectively meaning that it is now part of the ScritchUI event loop and drawing is inlined and correct for the most part. It is effectively how OpenGL and such operate, so whenever that happens it will be ready for it.

There was also module cleanup and refactoring, I started prefixing modules so that SquirrelJME specific libraries that are not SquirrelJME Runtime specific, but can be used by anyone, are prefixed by vendor-api-squirreljme-.

Then wip-nanocoatexec continued along. More instructions were implemented such as invoking methods and loading variables. Command line parsing started to get implemented. Much of the basis for the stack was implemented as well. Of course later on, how stacks work would be redone. The very basis for MLE calls also started being a thing as well.

The JSON library, from before SquirrelJME even existed (!) from 2014, got more methods implemented along with a refactor to support base Java ME so it could be used internally.

There were additionally a number of compiler specific checks and fixes for all the various environment configurations. Along with the very primitive basis for CMake patching.

March

Some related test fixes and organization, mostly brought about by SpringCoat.

More work on wip-nanocoatexec. The foundation of what became character sequences and strings was started here, after a large refactor. This was because character sequences were just a huge mess. It is now subtype based and is able to be expanded further for new formats and otherwise. Although, as of today (October 2026) that is not so likely.

Surprisingly, Cocoa got a minor amount of work and fixes. I do really need to get more work on that in and do get that done and merged for macOS support.

Whatever I had in wip-calendar got merged into trunk, I deemed it good enough.

This is also around the time where ProGuard was giving me issues, which is not something I would solve until much, much, later.

For CI/CD builds, I made a Universal Standalone Jar.

Also said this.

April

Naturally, wip-nanocoatexec. I added GDB renderers. Ironically, I just recently (October 2026) reworked these for LLDB and need to go back to get them working again for GDB. Otherwise, NanoCoat got some more instructions implemented such as array and stack operations. Later on, object allocation appeared. Due to the divergence of this branch, there was a major cherry-picking into trunk.

Locks and atomics all became aligned.

DoJa obtained a new compatibility checker since there have been breaking changes between the various DoJa versions, especially with transparency and how events are handled. This is also used to make older DoJa titles just run better overall. MIDP also got this treatment as well, as it handles background transparency slightly differently between versions.

CircleCI was also starting to annoy me here as well as they slowly started their dive into AI.

Then suddenly, MEEP RMS 2.0 for SquirrelJME which effectively overhauled how records worked along with BucketShelf being added for arbitrary data bits and otherwise. This format would eventually also be later adopted by FreeJ2ME-Plus. Otherwise, this was a much better and nicer way of storing records and was very reliable. It also helped that the JSON library was improved previously. This also facilitated fixes for DoJa scratchpads by allowing broken titles to do broken things to them, such as reading out of bounds.

Randomly, an AntiMicroX configuration appeared at the request of someone.

ScritchUI got some improvements. It can clip now, along with Windows not having the hourglass cursor everywhere.

The launcher got a single menu option to open the library directory as there was a complaint that finding the directory was difficult.

May

This is when the Keitai Wiki Music implementation was donated to SquirrelJME. A very huge thank you to Guy Perfect, who worked on this with my input on getting this working well. Once ready, this got merged into SquirrelJME. This was followed by a cleanup and a refactor as I said I would do as such. It was not a full cleanup/refactor, but it was quite a bump from the initial code.

ScritchAudio and much of its supporting code was implemented as well.

Native math acceleration in MathAccelShelf was added to facilitate the newly donated library.

Canvas now understands the number pad keys. There also is an option for having a calculator layout, or not, so that it can be mapped to a dial pad which uses an upside-down layout.

I did add some Install4J installers for Standalone, mostly for convenience. Once NanoCoat is done I will need to determine if these can be recycled or not, I do hope they can.

The following quote has also happened:

This format would eventually also be later adopted by FreeJ2ME-Plus.

June

AI contributions in SquirrelJME were officially banned this month, joy!

Importing of the donated Keitai Wiki Music library along with ScritchAudio continues. WinMM support was added, along with OSS. This did actually get merged in though after the first week of the month! Naturally, a bug in SpringCoat was found where dcmpg was popping floats instead of doubles, this was fixed.

Randomly as well, Eclipse Adoptium removed response file support. So a check actually had to be added in to see if the JVM supports them. I am assuming this was done for security reasons.

I added Visual C++ 8 support, for no reason. This also means the addition of the sjme_sm() macro, although this is needed for C89 anyway.

For wip-nanocoatexec, I did more cherry-picking and much more of it as well. Bytecodes got a gigantic LUT for execution for both slow and fast bytecodes. Fast bytecodes are anything that could be optimized.

DoJa saw some minor improvements such as single pixel drawing and more edge cases of deliberate scratchpad overflows. There were however major improvements to AudioPresenter and related classes as those are very version specific and they work in an extremely specific way.

As a note I am rather sleepy looking at 2025/06/15, I will return to this at a later date. Hopefully tomorrow.

And I return, not sleepy but tired.

Continuing, NanoCoat received much more work. Virtually all of it was foundational for it. Monitor entering and exiting, static field initialization, reference queues, MLE improvements, instance field access, temporary character sequences, invalid bytecode checking, more MLE implementations, lookupswitch, tableswitch, value conversion bytecodes, identity hashcode, math functions, virtual method re-lookup to invoke the correct method, basis for JVM and JNI compatibility layers, stack bytecodes, POSIX signal catchers when debugging, trace points, stack dumps, thread scheduling, exception handling, float and double comparison, multianewarray, and atomic improvements.

On the otherwise, WeakReference was refactored to be simpler and to remove an issue that has been around for a very long time where it would just get stuck in a loop checking itself. Also, ObjectShelf.arrayClone() was added which effectively makes array cloning faster. RMS was additionally 100% implemented, making it the first to reach such.

July

This is where I decided that wip-nanocoatexec was good enough with its large set of changes and base implementation that I wanted to get it merged in so it did not become this gigantic branch. I also wanted to work on other branches without them having to wait, in essence I was being driven sane. Thus, the merging to trunk happened.

There were a number of general optimizations, build fixes, and refactors.

Dependabot was officially nuked, it was annoying and rather useless for SquirrelJME anyway.

The type system was unified, thus removing TypeBracket and only having Class. The appropriate ObjectShelf methods were used in places where manual array operations were being performed. Terminal pipes received a number of corrections.

Standalone and NanoCoat ROMs have been semi-unified. NanoCoat can use any Standalone ROM that includes SpringCoat and such.

In NanoCoat, string comparison stopped checking a string against itself along with the wrong length being returned for non-intern strings. A simpler abort handler was added, garbage collection improvements, the basis for walking and core dumps. The walking code effectively is serialization of SquirrelJME's state, although it does need a major refactor as of today (October 2026). More option parsing was implemented.

In SpringCoat, TerminalShelf.available() was implemented, which is very nice to have.

TypeShelf.inJar() was added to locate which specific Jar a Class resides in. This is mostly just used for determining if a given class is a SquirrelJME provided classes or not, also if it is in cldc-compact.

A branch wip-stackcache was made for stack caching, however that would later be abandoned.

August

Virtually and almost nothing happened this month.

The wip-stackcache branch was abandoned.

I made the wip-concourse branch which was my idea into switching CI/CD systems from CircleCI as it was getting more and more broken due to it embracing AI. Nothing was done in this branch.

At the very end of the month, Cocoa got a merge in from trunk so that it would be updated. There were some fixes to menu bars, as there is the primary main menu bar at the top of the screen and application specific menu bars.

September

Cocoa saw some additional fixes in its branch, but I only had worked on it for a few days at the start of the month.

I created the wip-running branch (As a note in October 2026, I just actually went "Oh..." as I realized this branch has been alive for an entire year... Well then. I should actually finish what I am working on and splice at this point, just merging things in).

NanoCoat received more bytecode implementations, constructor initialization, more GC fixes, basis for JDWP entry points, debug messages, NanoTests and their templates, and finally verbosity macros.

October

NanoCoat received allocation pool fixes and optimizations, improved atomic operations, thread refactors, closeables, more walking implementation, GC fixes because of walking, phantom atomics because of walking, attempts at Doxygen, JNI header selection, super class counting, allocation pool dumping, code walking, fixes for main argument counting, non-cyclic atomics because of walking, logical error fixes, and more GC fixes.

Otherwise, Ratchet and Clank 2 was fixed and there was a Nokia display size fix with scaling. The ability to get String characters with the new system was implemented as well.

November

FlatPak support was dropped, because their build system setup to make the actual FlatPaks is very horrible.

NanoCoat received class loader GC fixes, a major string pool refactor which fixed many issues, isClasses refactors, freeing static field storage, refactors to NAL, and more GC fixes.

In the second half of the month:

At this time, the CI/CD pipelines on CircleCI were completely falling apart and there was not much I could do to fix them. My goal with this was to have an independent build system that could build the entirety of SquirrelJME and run on any system or setup. Rather than duplicating the rules to every build system, I just have an outer build system which is called by a pipeline. This is so I can have whatever setup I want. There were also a bunch of compilation fixes as now everything was being built. I wrote a system and compiler identification system, which works well to this day (October 2026). Additionally, ProGuard loves memory, so it can retry again if it runs out. The build pipeline is also able to call Fossil and upload/download as needed for any natives. It can also generate source archives. Also, CMake's FindJNI can be very broken so that got a check to make sure it was not. The installers received the ability to be built if Install4J was installed. There were also some random MIDP 2/3 fixes as well in this branch, along with ProxyGraphics for wrapping another graphics context.

Then all of this was merged in on the 26th!

C23 enum packing stopped being used.

A large cherry-pick from wip-running, using the description would probably be best here:

Cherry pick the non-NanoCoat related changes from wip-running: Doxygen generation; check for sys/socket.h; short forms for sjme_list and sjme_atomic; NT define mix around; Phantom atomic type; Split off of atomic implementations; An emit to console that does not go away in release mode; Refactoring of NAL functions in a more vendor/platform-split way, and also allow for more easier fallback in the event of not-implemented; Correct VERSION macros; Correct Doxygen tag usage; Base for blank TCP/UDP stream; Allocation system is more atomic, along with an edge of memory fix where it would give a block past valid memory; Improved weak reference handling, performing more validity checks and tends to work better; Makes closeables not refCounting enabled, they are always ref counted via weak; Deletion of character sequences; Correct reference counting in some base classes (due to GC correctness work); Add sjme_thread_wake(), which might not always work; Various seekable fixes around cleanup; Use instrinsic for popcount, if available; Correct counting in ZIPs (from GC correctness work).

Differences between DoJa and MIDP were documented.

Display scaling had additional fallbacks added. Fonts could get their character width determined.

A short-lived branch called wip-pfscan was made to generally pixel formats and scans. This was mostly so AShiningRay could work on some graphics related code, of which I did not want everything done only in RGBA. The PF system allows any pixel format to be used in an agnostic way. It was done in a day. GTK2's colors also were fixed once the correct color mechanisms were put in place. (As of October 2026, I am very happy with the PF scan system).

NanoCoat additionally received more fixes, and a large number of tests totalling 359 for every bytecode and their variant, and a threading refactor.

Install4J got SquirrelJME's icons.

AShiningRay contributed an implementation of ScritchPencil copyArea().

December

NanoCoat received a TCP/UDP reorganization.

AShiningRay contributed transformation fixes, also had this to say:

Previously those were broken due to certain transforms not being processed at all, or under the assumption they'd reach the same result as another (was seemingly the case for ROT_180 and TRANS_MIRROR_ROT180). Furthermore, after those transforms were processed, even if the matrix transforms themselves were correct, the end result would still be incorrect on screen due to the source/destination positions and sizes not being updated to reflect the transformed data. This commit fixes that, all transforms seem to be done properly now, in all cases known, passing the internal image tests as well as games such as CastleVania: Dawn of Sorrow (K800i version) and Sonic 2 Crash (also for K800i), both of which, together, use all the available transforms with a myriad of clipping and image width/heights. Do note that Sonic 2 Crash will not yet boot at the current tree state due to SquirrelJME missing Nokia DirectGraphics' implementations as well as fillArc and fillRoundRect, those will be coming soon.

The contributing guide was updated.

I started the base for the wip-tk branch, although I probably should finish the Cocoa branch first.

I had an idea for an RSS triggered pipeline build, but that would involve more work and a simple cron job would do for now. So I decided against that.

AShiningRay contributed graphics primitives and had this to say:

This commit implements the following methods in Software: - drawArc - drawRoundRect - fillArc - fillRoundRect - fillTriangle - fillPolygon (will be used by DirectGraphics and DoJa) - drawTriangle - drawPolyline Thus making SquirrelJME's graphics subsystem a lot more robust and removing many cases where it would previously fail with a TODO call. Fixes games such as Sonic 2 (won't boot without the staged DirectGraphics work), Landers, Bounce Tales (also needs DirectGraphics), among others. Furthermore, new corePrim_ methods were added for those, and fill/drawRect as well, in order to facilitate Hardware implementations for them when the time comes.

Palette transformation is now always performed for indexed colors, this is because if two paletted images use a different palette they would draw or reference the incorrect color.

meep-cellular saw stubs being added.

A bunch of native POSIX fixes happened, such as support for TCP/UDP address family fallback (AI_PASSIVE/AI_ALL), network polling is also now possible due to FIONREAD assuming it is available to begin with.

Modules and applications were renamed to fit the new, and more organized, naming scheme.

I did start a blank base for a ScritchUI Demo in NanoCoat, still unfinished as of October 2026.

Path handling in SquirrelJME was completely refactored and made completely system independent. The end result is that any path can be used on any system which is very flexible. This is something I am very happy with as of today. This was merged later in the same month.

AShiningRay implemented random Nokia APIs for odd color formats with some polygon fixes. Not much was said other than the obvious.

Official OSS headers were included from BSD, if the system does not have them. This was mostly due to AShiningRay not having the proper OSS headers from Arch. This fixed things, somewhat.

DoJa and Star applications starting working properly with certain properties as they actually got them from the appropriate location.

AShiningRay added support for Nokia DirectGraphics and had this to say:

Implement Nokia's DirectGraphics and add methods to read from screen SquirrelJME now supports Nokia DirectGraphics and screen reading! DirectGraphics wasn't implemented yet, and is used by quite a few J2ME applications, even those not actually meant to run on Nokia devices, like some Sony Ericsson ones. This commit solves that and also adds some new methods for reading and drawing to the screen from any supported pixel format: - drawRegion() - getRegion() Both of which are now available to the Java side. Also, it is now possible to access the native pixel format of the pencil from Java, as it is required by DirectGraphics. Some reworks were done to SquirrelJME's base Graphics stack as well, such as the addition of an 'ExtraGraphics' interface, to be extended with more vendor-specific operations in the future.

Despite the comment, due to how SquirrelJME is designed as a whole there have been no vendor-specific operations added to ExtraGraphics. They have never been needed.

Since polygons were now supported, I updated DoJa to draw said polygons along with some general graphics refactors.

A branch fun-lexinspace was started, this is a demo game that I have an idea of making. A kind of cross between No Man's Sky, Starbound, and Terraria.

All the blending modes were implemented along with means to add more, despite nothing actually needing them in any way.

Proper HiDPI and scaling support was added to SquirrelJME, although a chunk of this code was from the Cocoa branch which requires it.

At the very end of the month I started a refactor of MIDI playback with the help of my wonderful wife who I love very much.

But before the year was over on the final hour of the final day of the year, AShiningRay sent a patch to implement the Nokia Sound API and a bunch of playback surrounding it. He had this to say:

media-api: Improvements to deallocate and close methods. Close must be a no-op if the player in question is already closed, and deallocate() should throw an IllegalStateException if the player is closed, while resolving to a no-op if it's either REALIZED or UNREALIZED... and it also shouldn't be setting the player to the CLOSED state like it was doing before, instead, it must go into either REALIZED or UNREALIZED. Rather than copying all these checks into all players extending AbstractPlayer, deallocate() is now implemented in AbstractPlayer itself, while extending players must override a new becomingDeallocated method to manage internal deallocations. ... Implement Nokia Sound API. This commit implements Nokia Sound with OTA Ringtone decoder! The player was built so as to reuse as many bits of MIDP as possible, since Nokia Sound will also make use of the future WAV Player that is part of the standard set of MIDP Media Players. ... media-api: Bring in WAV support! A vast chunk of J2ME applications use WAV for all sorts of effects, so this commit implements not only base PCM WAV, but also brings decoders for IMA ADPCM and G.711 (u-Law and A-Law). GSM 06.10 (Full Rate), GSM 06.60 (Enhanced Full Rate) as well as the AMR (Adaptive Multi-Rate) family of codecs should also be supported down the line, since they are also used by applications, AMR being especially common on Nokia apps... however, decoding them is far more complex and taxing on the device as well, making their implementations better suited to reside in native code. As such, those are left for a later date.

Happy just before the New Year!

2026

Happy New Year!

January

I added a route and completion tracker to show progress within the repository in more meaningful terms.

ScritchUI received transferRegion() to replace copyArea(). Luckily this is PF agnostic, which means it can translate between formats.

The sound and MIDI refactor was finished early and I had this to say:

Merge in sound refactoring, yay! This adds a media player, which will be very helpful! There is the ability to play media files, including files in DoJa scratchpads via a linear scan method to find any MLDs which happen to exist (not perfect but good enough); With the help of my wonderful wife, MIDI is no longer broken and timings are now accurate, along with almost all MIDIs being able to play now unlike before; URIs have been added and connections use the new URI framework to be more conforming and standard, DoJa Scratchpads can now come in different formats because URIs are now smarter than before; Additionally, there have been pseudo-file: URI implementations to access the libraries that SquirrelJME knows about so you can play media from any library; ScritchAudio has been refactored greatly, the loop handling is reversed so that polled audio is called directly instead of going through the software mixer loop handler; Software mixing will only perform mixing when the audio format is different and/or there are more than one attached renderers; AbstractPlayer has an additional becomingPrimed() and becomingSolvent() so that any audio streams can be created and kept around longer rather than constantly creating and disconnecting streams, which should reduce sound card popping; ObjectShelf.arrayCopy() for SpringCoat now emits MLECallError correctly; Audio streams now expose a default rate and longer are implicitly created on initialization; Add EnumerationToIterator for the reverse operation, needed for FileConnection; Refactor MIME type detection and add more types; General Connection refactoring; Differentiate fast forward and set time, for tracker based formats; AbstractPlayer can now handle starting from the time of last playback and time adjustments while stopped/prefetched; Refactor state checks in AbstractPlayer; MIDI playback no longer produces garbage notes when stopping; IMelodyPlayer properly returns unknown time when the time is actually unknown; Correct some various annotations; Implement missing ExtendedDataInputStream methods.

And when I say my wife helped me, I really mean it:

Wife is solving all my MIDI problems; Squelch play during fast-forward should NOT reset all controls.

There also is a shiny new Media Player which allows you to play any media type that SquirrelJME supports, from any media source SquirrelJME supports. This even supports DoJa ScratchPads via scanning!

With the new AbstractPlayer, the other players including the pretty new Nokia and WAV players were ported over to the new system.

I changed how ResourceConnection for DoJa works for Hosted so that LoN/PoN can actually run in it. Mutable and immutable images were fixed as well.

Time on Windows also progresses and is no longer forever stuck on the same instant in the past. This was mostly to get audio working as there also were a number of ScritchAudio refactors. There were also more additional attempts to get ScritchAudio working in general.

NanoCoat saw test simplifications, static call fixes, a few tests passing, questioning of my insanity, instance AND static field cleanup, a value get/set refactor in the form of cisGetS()/cisSetS() (there will later be a transGet and transSet for far more complicated value access, but this will mostly be for JDWP and quirky libjvm/JNI stuff. Also, trans rights!).

I started work on the Many Fonts branch to clean up font handling, I mostly started writing the Barcode Bitmap Font Scaling Algorithm that I thought of on my own.

Extra data buckets were added, if you remember the RMS refactor.

The new pipeline build system saw some improvements regarding natives, to bundle and package them together better.

AI still banned from the repository.

February

Pipeline build system improvement and refactors continued.

I closed a bunch of dead branches and added a bunch of date tags in the appropriate places.

I did attempt merging Thread and VMThread into one, but that failed. I did cherry-pick the stuff I liked though, which was very minor and stubs for a unified command program called ABCD.

March

NanoCoat received CMake fixes, cancelling out define contradictions, fixes for Windows due to implibs, MSVC fixes.

Many Fonts received a flat mapping.

April

More work on Many Fonts, added the basis for font derivation, improved how scaling works, and fonts are placed in the Jar differently now.

AShiningRay contributed more audio format support, he had this to say, Note the error note I put in:

WavPlayer: Major reworks to both player and decoders. Following Nokia OTA, WavPlayer now conforms to the newer Abstract Player layout as well. But beyond that, quite a few improvements were made like separating all PCM decoders into their separate package so that other container formats can use them, improvements to wav header parsing and duration/time calculations, as well as IMA ADPCM decoding.

runtime.media: Bring the now-separated PCM decoders. My previous patch seemed to not have been fully applied, and the entire pcm subfolder was missing. That's good in a way, since it better separates the wavPlayer reworks from these decoders. (Stephanie: This was an error on my part, forgot to add the newly patched files! I did bring in this new description however.)

DoJa saw some minor fixes around palette updates, AShiningRay also noticed that clipRect() was not implemented for DoJa while I was working on the palette fixes.

I added stubs for the cellular network API.

I made a WebRing button.

AI still banned from the repository.

May

AShiningRay at the start of the month contributed some Samsung APIs, he had this to say:

modules: Implement important bits of Samsung API 1.0 This commit brings in all of the classes defined by the Samsung API 1.0 spec: AudioClip, LCDLight, SM, SMS and Vibration. SM and SMS are complete TODOs at the moment since SMS capability is likely not going to be a concern anytime soon, whereas AudioClip, LightLCD and Vibration are already setup to use SquirrelJME's available structures, including a few new ones.

Many Fonts received glyph fallback support.

I refactored key code translation to be much simpler and able to support multiple different vendors, although this would later be refactored again. A generic QWERTY dial-pad layout was added as well.

AShiningRay also fixed some MLD issues, he had this to say:

DoJa/MLD: Multiple improvements to MLD management and playback A few more MLD commands are now supported and ADPCM chunks finally get properly parsed (the player is not set to play them yet, quite a bit of rework is needed and this commit would get too big). MLDPlayer events such as EVENT_LOOP and EVENT_END are also handled and emitted in a more proper way with this commit, solving many cases where MLDs were always looping indefinitely. DoJa also got some improvements in how it handles said events, and some cleanups and renames were done to bring it up to par with the other players that were recently refactored. We must also keep a local copy of the data received by AbstractMediaResource, as otherwise SquirrelJME would throw NPEs whenever the player for that resource was deallocated/unrealized, then realized and prefetched again.

Supply chain documentation was added, so that in this AI hellscape it is known what SquirrelJME's dependencies are. Luckily there are very few.

June

The basis for a JNI/SquirrelJME was added, this is so that the reverse can happen where someone else's JNI is on SquirrelJME. Mostly started this so that emulator-base which is a horrible mess gets less and less specific code as that can be reused elsewhere.

I made the pipeline build nicer by being a bit more verbose about what is and what is not available.

ProGuard has become the bane of my existence.

There were general player fixes, mostly around timing.

NanoCoat saw more argument parsing, along with an initial blank base for MEEP SWM in native code which is needed for -jar, library loading, suite loading, manifest parsing, narrow and wide string comparisons, more debugging, blanks for libjvm, and GC correctness.

AShiningRay contributed a generic key mapper along with Nokia OTA Decoding, he had this to say:

Player + NokiaOTADecoder: Minor improvements to playback. NokiaOTADecoder got some clarity improvements and dropped its usage of floats on almost all scenarios. Now it only uses floats if the received audio format is FLOAT_F32. .. it also allows AUTOMATIC channel amounts. Furthermore, AbstractPlayer's setMediaTime(int) now allows its argument to be negative (it sets media time to 0 in these cases), and for media whose duration cannot be ascertained, it simply sets the media time to 0 no matter the time argument as opposed to doing nothing and just returning getMediaTime(). It makes more sense this way, as AbstractPlayer should pass that work onto the underlying Player implementation, and that one, in turn, may throw MediaException if it does not support setting media time. Support screen and keycode System/Environment properties for tasks Also, bring in other vendors' keycodes such as Motorola, LG, Siemens, etc. while also reworking how those are processed in order to properly apply vendor keycodes over Canvas ones when needed. The previous system of having a translator for each vendor in its own module subdirectory was dropped in favor of a generic translator which handles all known MIDP2 vendors currently, since they follow the same concepts. Other, more specialized translators can still be created later if needed. A few more keys were added to GenericDefaultKeys in order to better accommodate for all vendor keys that deviate from MIDP.

Support for ancient CMake 3.1 was added, this was mostly for older systems and the very out of date libretro build systems. There was much writing of backport handlers and shims for stuff that was added later, although it could be handled entirely by macros and/or functions. Neat.

AShiningRay also contributed eMelody and iMelody support, he had this to say:

media-api: Implement support for Ericsson's eMelody and iMelody These are plain text formats, not too difficult to introduce support for. However, some files found online do seem to go off-spec a bit (like adding volume information on the tempo section of the header or looping blocks without clearly separating them with parentheses), so their decoders cannot fully adhere to the official spec due to that. Also, Backlight, Vibration and LED control are wired to device controls, but those are not implemented yet, so those commands are effectively ignored for the time being. As a small extra, some of the code on this decoder was ported to Nokia's OTA, fixing a few issues and improving readability.

Selecting a different ScritchUI library is possible now, before it was fixed for a specific system.

AI still banned from the repository.

July

CMake was properly fully ported to version 3.1, there were some additional supporting scripts which were missed along with the pipeline build not being yet ported.

NanoCoat received the ability to default launch, and stack allocation.

The RMS save format was updated to encode forward slashes.

Enum was granted unlimited access to all classes, very powerful indeed.

August

The pipeline was adjusted to add a --probe argument so I could see if the actual executables that were compiled by the build system actually ran on the host system. If they did not, it would try more compilers. There were also other CMake fixes as well. Mostly for libretro and RetroArch, but mostly for RetroArch as it continues to degrade further and the pipelines break more and more (AI).

Mu's repository URL was updated and is now under SquirrelJME's organization.

I found out that GNU Make is broken when it comes to the jobserver and nested processes, fun.

A major cherry-pick from wip-running!

NanoCoat received the initial start of a rework of the stack variable storage system as it was very horrible, and a stack overflow detection off-by-one fix.

AShiningRay finished most of GameCanvas, he had this to say:

lcdui.game: Implement most of MIDP2 lcdui.game This commit implements Sprite, Layer, TiledLayer and LayerManager. Almost everything is here aside from Sprite's per-pixel collision, note that GameCanvas needs its getKeyStates() function implemented later as well, it's commonly used by apps that use lcdui.game.

Then out of nowhere, AShiningRay also moved the Keitai Wiki Music implementation very much in line with SquirrelJME's code style, he had this to say:

modules: keitaiwiki-music: Follow the project's code style. This commit overhauls the entire package, aiming at bringing it up to par with the rest of SquirrelJME's code style. Lots of additional documentation was added as well. Renaming the fields and package-private classes was left for later, if needed, as otherwise the surface area for mistakes would be way too big.

From that, I did make the rename refactors to finish the cleanup work he did, since I do have IntelliJ 2025.

Cocoa saw a merge from trunk, I said "it has been awhile" and it has been awhile indeed.

There were fixes to Windows and BSD pipeline builds.

On the final day, the backup Tor mirror was revived.

AI still banned from the repository.

September

A document detailing the technical debt in SquirrelJME that has been around for years was added, so I could think about it for later.

NanoCoat received the refactored stack storage code which is much nicer, threads were then switched to this new and better system, more MLE functions were implemented, package private was fixed, a recycling fix (I never made a note of when recycling was added, but effectively this is a check that if a class has been loaded the instruction re-runs), loading of the ScritchUI library, blank bases for loading single suites, an implementation of proxy interfaces which is needed for ScritchInterface to work, being allowed to use multi-arch libraries even on Windows, checking the current desktop manager to see which ScritchUI interface to prefer along with a default order, a separate runtime library path, an embedded VFAT style which is effectively a POSIX path style VFAT, libretro NAL refactoring, MLE refactoring, and design documents.

More fixes for CMake. The pipeline build shell scripts were made and setup instructions for launchd were added because copy and pasting from one system to another is painful when you have to set up four different macOS systems.

More fixes for the libretro/RetroArch pipelines, mostly around 3DS.

AShiningRay had contributed a small MIDI fix:

MIDI: MTrkTracker: Handle running status bytes. Previously there was no such handling, and tracks that send multiple events without repeated status values made track parsing desync completely.

Apparently, Font.charsWidth() was never implemented, so I implemented that.

This also extended to Short.parseShort(), so I implemented that.

AShiningRay also contributed a small DoJa fix:

DoJa: Bring PhoneSystem up to par with DoJa 5.1. Many device features from newer DoJa were missing, and the same was true for the more recent class methods. Additionally, optional phone system attribute IDs (range 128-255) are now considered and separated into their own class, like it is done for vendor-specific attributes.

ProGuard continues to be the thorn.

API violations in MIDP and DoJa were removed by adding a separate class which could be used to grab needed sharable global state, similar to how Player controls work.

Debug renderers for some classes when used with JDWP, mostly for IntelliJ.

AI still banned from the repository, despite a drop in reading comprehension. I specifically quoted "Do It Right The First Time, Patience First".

I also had to say:

Unfortunately, these documentation additions are for the GenAI and LLMs users that must rely on an agent to understand a project's contribution guidelines and are unable to reason the guidelines themselves.

October

NanoCoat received an option to change how the 0th argument is handled, proper static method access, ScritchUI loop runnables running, SDCC fixes, thread unification at least for NanoCoat only, Thread subclass handling which is done via a flag, and LLDB pretty printers (GDB to come next).

AShiningRay started this month off with two graphics related patches, one for converting floating point arc/circle drawing to use SquirrelJME's fixed point library, and another to implement and refactor some bits of DoJa's graphics. He had this to say:

ScritchPencilRasterShapes: Move arc drawing code to fixed-point. The hardware float guards were removed entirely from there as all architectures can use these now. drawArc got some optimizations bundled in by the means of DDA usage so that sin/cos is no longer calculated for each step, and fillArc, which was the biggest bottleneck previously, got swapped to a scanline algorithm that runs orders of magnitude faster while also dropping the need for that temporary "alpha buffer". As a bonus, some extra FP functions were also implemented. Not all of them are needed for arc drawing, but it's good to have them there for whenever something actually does.

DoJa: Update Graphics, Image, and Sprite classes. ImageMap and Sprites were initially introduced as optional packages in DoJa, but as of DoJa 3.5, they were made part of the core specification, going from 'opt.ui' to 'ui'. This commit implements them as their newer versions. What this means is that opt.ui.Graphics2 should now link its SpriteSet and ImageMap drawing methods to ui.Graphics, and the older opt.ui versions of SpriteSet and ImageMap should be redirected to their ui equivalents now. A few methods in Graphics2, Graphics and Image were also implemented based on their specifications, with notes being kept on sections where the specification is not clear about what happens when OOB access is attempted.

Modules that did not belong in modules were moved to tools or emulators, which makes everything smaller because nothing in the runtime will ever use them.

The beast named ProGuard has been defeated. I hope. I ripped all the settings to shreds and started from virtually nothing, although everything I had in place which wrapped and called ProGuard was untouched. I effectively just disabled shrinking, and made it so anything public is never obfuscated. Any that is not public can be shrunk and obfuscated. Optimization generally always happens. This means that @SquirrelJMEVendorApi and @KeepWhenCompacting are now gone! There is @KeepAbsolutelyEverything which keeps everything as-is and does not optimize, but this is mostly for entry points and very important things.

Java 24 killed SecurityManager so I did as well, except I will be keeping it around just for legacy compatibility. It only worked for well behaving applications regardless.

A note from before for later: pivot wip-running to just run the hello demo program and just output the text that exists, since it has been worked on for an entire year... it really needs to be merged. I dislike branches being out for this long.

... HALF DONE AS OF OCTOBER 2026, on the 13th ...

AI still banned from the repository, despite a drop in reading comprehension. Yes, this keeps coming up.

Reflecting back on what I wrote back in 2018:

This release was mostly just a demo to show that SquirrelJME exists and that it is being worked on. It is very primitive and not much can be done with it. From the release though there has been slowly increasing interest in the project since there are not many emulators that support J2ME that exist and are actively worked on.

With AI this has changed, there are now 30-40 dead emulators (and counting) and SquirrelJME is the sole active emulator which does not accept any AI contributions. There are even less active projects now if you do not consider the ones that die in a few weeks. It is ironic that a decade later the situation has not changed much at all, except for the ever-growing pile of lit corpses strewn about haphazardly in multiple dumpster fires. Java ME truly is niche, and nobody gets famous or rich in emulator development, nor should it be expected.

Working on getting wip-running merged in now! Yay!

November

... IN THE FUTURE AS OF OCTOBER 2026 ...

December

... IN THE FUTURE AS OF OCTOBER 2026 ...