My latest MSX game: Westen House

ah, yeah, if you do not have an IDE (Netbeans, Eclipse, IntelliJ, etc.) it's a bit of a pain. With an IDE it's super easy. I just open Netbeans, new project, add that "java/src" folder as the source folder, and then just "right click on Main.java -> Run" If you just want to do it manually, without an IDE, the common way is to use "ant" (the equivalent of "make" in the C/C++ world).

In any case, I just tried to do this myself (cloned the github into an empty folder and run ./build). I think I see your problem. I did not include the "zx0" binary in the github project (as that is an OS-dependent binary). The "zx0" binary should be placed in the "java" folder, you can get the sources from this github repo to compile it: https://github.com/einar-saukas/ZX0

Once I put that zx0 file there, a working .rom was generated. So, it seems the files in GitHub are fine. But I might have to add a comment about zx0 :)

Yes, Zx0 exe is mentioned in the readme and was placed in de jave dir like mentioned, rom generation was not a problem, but the rom did not work and is different with the working rom that was shipped with the source zip so thats why i did post the question if anyone did compile the source supplied on github.
Did already search and found a few java IDE so thnx for the tip, going to try Netbeans IDE this evening.

On a recent project I used lz4 (hc) because compressors are easily available on all systems and in programming language packages (e.g. Node.js has several), and the decompressor was also easy to write. Worked in one go, surprisingly.

Later I checked out some other compressors to see if I could save more space, based on them scoring higher in some compression size charts, amongst others zx0, pletter and lzsa2. But to my surprise on my particular data set (music and graphics data) the results were not as good as I was led to believe from those charts. They did better in some files worse in others, and overall most of the compressors I tried actually got a lower compression rate in total, or in one case only marginally better, just a few tens of bytes rather than the 25% difference I was expecting.

All this while more niche compressors like zx0 definitely have downsides, such as lack of availability in standard packages, lack of prebuilt binaries for certain OS-es, lack of documentation, much slower compression, and also the OWCC compiler dependency for zx0 is unusual and an additional obstacle to include it in a build process, not a big fan.

The lesson for me is, don’t take those charts as gospel, and lz4 is not necessarily compressing as badly as they make it seem. Test on your specific data of course, but really, to me they all seemed to get roughly similar results so choice of compression won’t matter that much in the grand scheme of things and you should also take into account other factors.

@Grauw: With LZ4 you mean this one: https://github.com/lz4/lz4 ?

LZ4 HC is activated by specifying option --best right?

I tried compressing some files (code, music, graphics) with LZ4 but the compressed files were all about 30% bigger than the results I got with ZX0. Of course the compression ratio can vary between tools depending on what kind of files you try to compress, but it's a bit strange you didn't observe such big differences.

LZ4 does compress fast though, that's nice. ZX0 is very slow (even when specifying option -q).

I don't think that OWCC is a dependency; it compiled fine for me with GHC (though I didn't actually compress anything with it). CC=owcc just happens to be what they defined in the Makefile.

But as far as which one to use, I'd say just have your build system try different builds with all of them and pick the best. :-)