Planning Tutorials

I’ve been trying to come up with a content management system for a while now. And I think I finally have something that might actually work. With content management i’ve always wanted something that’s simple where I can declare a few a few categories and then post a series of articles in a specific sequence. WordPress is good for stream-of-consciousness, but it’s kind of plugin hell to try and force a rigid layout.

Anyways, so content management seems to work. A few glaring omissions are a 404 not found page, mobile layout and client based navigation. And while it’s tempted to get into some of the bells and whistles right away, it’s a lot more important to focus on the content. So in terms of content, we need to start with the first EGL tutorial.

So in the first tutorial for the forward, we need to cover what the tutorial covers, which is going from drawing a simple triangle, and moving our way up to rendering a simple model in OpenGL. For the environment that we want to do this is, we need to cover the expected set up, which is programming for the Raspberry Pi 3b with a display hat. And to do this we need another computer to act as the ssh-client and the first computer to act as the ssh host.

To summarize the forward should layout the environment and conditions needed to use to program for the tutorial. And then we need to cover what the tutorial is for, and what the final output should be. So we should create drawings for all for the environment that needs to be used.

From there the easiest way to get started for the tutorials themselves is to provide a framework, list the title, and provide an image for each step, and fill in a gitlab link where the tutorial code can be viewed by the person taking the tutorial. From there we should probably try and provide a summary of what will be covered in the tutorial, what parts of the tutorial are challenging and try to come up with aspects that we should either attempt to cover or not. And then we can highlights parts of the code that we want to cover, and think about if or how we want to illustrate each point.

More Paperwork

Paperwork sucks. Have to renew my daughter’s visa. So I guess I should go over the list of documents that I need.

1. Application for extension:
2. 外国人登録証 (コピー)
3. パスポート(コピー)
4. 健康保険被保険者証(コピー)
5. 住民票
6. 市県民税所得課税証明書
7. 納税証明書
8. 在職証明書
9. 給与所得の源泉徴収表

Seems easy enough, I guess I’ll get to it and start to build a folder for the documents. I also might as well go to the store and start making copies for stuff.

X220 + X240 vs e495

I’m not sure if I’m trying to talk myself into or talk myself out of this stupid idea. Right now I have two computers, an Asus UX305 and a HP Chromebook 13 G1. The Asus UX305 has been my main driver for the last several years. Over all it’s a pretty good computer, 13.3″ full hd with a fanless processor 4GB of RAM, and a 128GB SSD. Has a decent battery life and a nice keyboard layout. My ideal daily driver would be 14″ 1440p, 8GB RAM, 256GB SDD, and USB-C charging. Right now the Thinkpad Carbon X1 series seems to be ideal replacement, but those computers are stupidly expensive.

The HP Chromebook 13 G1 is a computer that I bought as a replacement. It has a 13.3″ 4k screen, fanless, usb-c charging, and 32GB of onboard storage. My thinking was that I could get around the short comings of the hardware, but after trying, there are too many flaws. The main flaw is track pad. It’s tiny and over all pretty terrible. It doesn’t feel anywhere as fluid as the Asus track pad. The keyboard doesn’t stack up, and while the keys have a decent click, the Chromebook keyboard leaves out a lot of common keys like delete, page up, page down, home and end, which I use a lot. The computer will always force suspend mode when closed, there isn’t a driver for the onboard audio, and 32GB of onboard storage fill up stupidly fast.

So I figured I’d go back to the drawing board. Effectively I want two computers. One computer would basically be a windows computer. I don’t use Windows every often, but there are a few occasions when it comes in handy. Specifically Daemon tools and really information from disks is a life saver. And I don’t like running Wine on Linux. If I need to do anything on Windows I prefer to have a network drive where I can drag and drop files to have something done on Windows and then copy back to Linux directly.

So my thinking was to have an X220 computer and an X240 computer. The X220 would be a simple Windows computer to run stuff on occasionally and the X240 would my main driver with Debian Gnome. Either that or get a e495 and use that as my main driver and convert my current Asus into a windows computer. Though my issue is that the e495 seems pretty expensive for a minor upgrade. It has 8GB of memory, 256GB of SDD, and USB-c for charging. But basically without the 1440p screen it seems like an expensive mid-step for a year or two before I replace it again.

So effectively for my uses, the X240 with a 1080p fills the same roll as the e495 for a fraction of the price. Originally I was thinking an X220 and an X240, but I’m actually tempted to go for 2x X240’s to have one with Windows 10 and the other with Debian/Gnome. That means that I can effectively have the same power connector and have one that uses windows and one that uses Linux and share the same hardware experience between them.

Youtube Cover Bands

This is not something that would normally go on this blog, but I wanted to try and make a list of Youtube bands

Against the Current –
Beast in Black –
Cristina Grimmie –
Jonathan Young –
Caleb Hyles –
The Midnight –

Load Save State issue

OK so. After trying to set the memory I ran into several problems. At 1st I thought it was because I tried to change too many things to fast. And then after walking back several changes The reason seemed to be because Save States were not loading at all. The main reason I can think of for this is because the version I ForkedHad an issue with it.

I think there are several ways to do with This. One would be to look for a different version to fork. And another will be the right tools for looking at save states directly. As far as looking at save States directly I mean is you is looking into the Decompression. No in general would make more sense to use a version that actually works. So I think I’m going to look into the apt-get version and find out where that repository is.


After a few tests I found that trying to move around the order so that the system memory comes at the start of the save state has the side effect that save states don’t seem to be listed when loading. So there could be some check that happens ahead of time to throw these away. Not sure if I want to track down this process or not.

And then I also find that the 10th save state tends to be pretty annoying. The 10th state seems to a backup state that is automatically created when the emulation had stopped to be able to restore the state again. So I might try and check the last three characters of the save state, and if it’s ‘010’, then skip and don’t write a state.

Pcsx-Reloaded Memory Debug Edition

I’ve finally had a tiny bit of time to put into looking into PSX graphics again. And I think it would be a good idea to fork pcsx-r to try and re-write the save state writing and save state loading to make it easier to debug system memory. The cloned version is over at

The code responsible for reading and writing states is libpcsxcore/misc.c.

int SaveState(const char *file) {
    gzFile f;
    long size;

    f = gzopen(file, "wb9"); // Best ratio but slow
    if (f == NULL) return -1;
    return SaveStateGz(f, &size);

int LoadState(const char *file) {
    gzFile f;

    f = gzopen(file, "rb");
    if (f == NULL) return -1;
    return LoadStateGz(f);

We have two functions SaveState and LoadState. And they both use a gxFile object type to create a compressed snapshot of memory to save as a state. We really don’t need this to be compressed. An easy change would probably be to change the compression from a 9 to a 0 for no compression. But I’m also tempted to change the order the file is written to make editing and reading easier.

nt SaveStateGz(gzFile f, long* gzsize) {
	int Size;
	unsigned char pMemGpuPic[SZ_GPUPIC];

	//if (f == NULL) return -1;

	gzwrite(f, (void *)PcsxrHeader, sizeof(PcsxrHeader));
	gzwrite(f, (void *)&SaveVersion, sizeof(u32));
	gzwrite(f, (void *)&Config.HLE, sizeof(boolean));

	if (gzsize)GPU_getScreenPic(pMemGpuPic); // Not necessary with ephemeral saves
	gzwrite(f, pMemGpuPic, SZ_GPUPIC);

	if (Config.HLE)

	gzwrite(f, psxM, 0x00200000);
	gzwrite(f, psxR, 0x00080000);
	gzwrite(f, psxH, 0x00010000);
	gzwrite(f, (void *)&psxRegs, sizeof(psxRegs));

	// gpu
	if (!gpufP)gpufP = (GPUFreeze_t *)malloc(sizeof(GPUFreeze_t));
	gpufP->ulFreezeVersion = 1;
	GPU_freeze(1, gpufP);
	gzwrite(f, gpufP, sizeof(GPUFreeze_t));

	// SPU Plugin cannot change during run, so we query size info just once per session
	if (!spufP) {
		spufP = (SPUFreeze_t *)malloc(offsetof(SPUFreeze_t, SPUPorts)); // only first 3 elements (up to Size)        
		SPU_freeze(2, spufP);
		Size = spufP->Size;
		SysPrintf("SPUFreezeSize %i/(%i)\n", Size, offsetof(SPUFreeze_t, SPUPorts));
		spufP = (SPUFreeze_t *) malloc(Size);
		spufP->Size = Size;

		if (spufP->Size <= 0) {
			spufP = NULL;
			return 1; // error
	// spu
	gzwrite(f, &(spufP->Size), 4);
	SPU_freeze(1, spufP);
	gzwrite(f, spufP, spufP->Size);

	sioFreeze(f, 1);
	cdrFreeze(f, 1);
	psxHwFreeze(f, 1);
	psxRcntFreeze(f, 1);
	mdecFreeze(f, 1);

	if(gzsize)*gzsize = gztell(f);

	return 0;

Here is the save state. And I think we’re interested in system memory and the framebuffer specifically. So we we’re interested in:

gzwrite(f, psxM, 0x00200000); 
// gpu
if (!gpufP)gpufP = (GPUFreeze_t *)malloc(sizeof(GPUFreeze_t));
gpufP->ulFreezeVersion = 1;
GPU_freeze(1, gpufP);
gzwrite(f, gpufP, sizeof(GPUFreeze_t));

And I think if we turn off compression and move these to the start of the function, we should get an uncompressed save state with memory for the first 2MB, followed by vram for the next 1MB, and then everything else thrown in after that. But then we need to make sure the Load state function also matches.

int LoadStateGz(gzFile f) {
	SPUFreeze_t *_spufP;
	int Size;
	char header[sizeof(PcsxrHeader)];
	u32 version;
	boolean hle;

	if (f == NULL) return -1;

	gzread(f, header, sizeof(header));
	gzread(f, &version, sizeof(u32));
	gzread(f, &hle, sizeof(boolean));

	// Compare header only "STv4 PCSXR" part no version
	if (strncmp(PcsxrHeader, header, PCSXR_HEADER_SZ) != 0 || version != SaveVersion || hle != Config.HLE) {
		return -1;

	gzseek(f, SZ_GPUPIC, SEEK_CUR);

	gzread(f, psxM, 0x00200000);
	gzread(f, psxR, 0x00080000);
	gzread(f, psxH, 0x00010000);
	gzread(f, (void *)&psxRegs, sizeof(psxRegs));

	if (Config.HLE)

	// gpu
	if (!gpufP)gpufP = (GPUFreeze_t *)malloc(sizeof(GPUFreeze_t));
	gzread(f, gpufP, sizeof(GPUFreeze_t));
	GPU_freeze(0, gpufP);

	// spu
	gzread(f, &Size, 4);
	_spufP = (SPUFreeze_t *)malloc(Size);
	gzread(f, _spufP, Size);
	SPU_freeze(0, _spufP);

	sioFreeze(f, 0);
	cdrFreeze(f, 0);
	psxHwFreeze(f, 0);
	psxRcntFreeze(f, 0);
	mdecFreeze(f, 0);


	return 0;

In which case we also need to move the read system ram and vram to the start of the function.

gzread(f, psxM, 0x00200000);
// gpu
if (!gpufP)gpufP = (GPUFreeze_t *)malloc(sizeof(GPUFreeze_t));
gzread(f, gpufP, sizeof(GPUFreeze_t));
GPU_freeze(0, gpufP);

That means the version checks for the state state version will come after, but I think that should be okay. So we might as well give this a shot and see if it works.

Open Source Pi Handheld

Something my brain won’t stop thinking about is an open source handheld based on the Raspberry Pi. I know in general there are a lot of DIY handheld cases for the Raspberry Pi, but I can’t say that I’m a big fan of the designs, which generally tend to be the original Gameboy with four face buttons.

For the most part I really want a Gameboy Advance clone to program for more than anything. Gameboy advance or potentially PSP. If there was a kit that replicated one of these two options that would make me super happy. I think when it comes down to it, that’s really want I want, either a Gameboy advance or PSP clone with XP-input controls and a full size SD card for fan games.

Because I’m a stupid idiot, and I keep thinking about hardware I’ll go ahead and make a quick list of the Raspberry Pi clones I would love to see (or make if I had any talent).

1. Piboy Pocket – Clone of the Gameboy Pocket with a black and white (e-ink would be amazing if the refresh rate wasn’t terrible) screen at 640 x 480 . With D-pad, A, B, Select, Start.

2. Piboy Color – Clone of the Gameboy Color with an IPS display at 640 x 480 . With D-pad, A, B, Select, Start.

3. Piboy Advance – Clone of the Gameboy Advance with an IPS display at 800 x 480 . With D-pad, A, B, X, Y, R, L Select, Start.

4. Piboy Portable – Clone of the Sony PSP with an IPS display at 800 x 480 . With D-pad, A, B, X, Y, R, L Select, Start, Left Analog.

5. Piboy Portable2 – Clone of the Sony PS-Vita with a touch-screen IPS display at 800 x 480 . With D-pad, A, B, X, Y, R, L, R2, L2, Select, Start, Left Analog, Right Analog

6. PiBoy Switch – Clone of the Nintendo Switch Lite with a touch-screen IPS display at 1280 x 720. With D-pad, A, B, X, Y, R, L, R2, L2, Select, Start, Left Analog, Right Analog, Right Analog Click, Left Analog Click.

If I could choose only one from this list, I think it would probably be the Piboy Portable. I think that would generally be a good starting point of having four face buttons, two trigger buttons, the main input being a directional pad, with the option of using the analog for more control. I wonder if there is a happy medium between the PSP and PS-Vita that could be targeted. But in general, I would really like to see a well designed kit for a Gameboy Advance or PSP that is it’s own kit that you can put together and not have to mod the original console.

Though if that’s what I’m looking for, then it might be a good idea to buy a pre-made version of the Gameboy Advance Pi mod.

Links Awakening DX

Next post, we come to the game that doesn’t need any introduction. Links Awakening DX is a god tier game on the Gameboy Color. What started off as a side project by Kazuaki Morita ended up being probably the best game on the system. As for the game, there’s a lot going for it. It’s a great top down adventure RPG, with a simple but comelling story, eight freaking dungeons that gives the game a decent run time, and a lot of areas to explore across a huge map.

Overall the only disappointing aspect of Links Awakening was that as I far as I know there weren’t that many clones made of the game. An action RGB seems like one of the best effective uses of the Gameboy’s capabilities, and it seems like Links Awakening is one of the few games to be able to take advantage of the Gameboy’s hardware and present a game with a huge scope.

Rom Hacks

If you want to experience the original game and get an improved experience, the best Rom Hack for Links Awakening DX is probably Link’s Awakening Redux. Which is actually four different hacks rolled into one. It removes some of the censorship, makes the text look a lot better, translates the photos and removes a lot of text.

For Rom Hacks that change how the game is played it looks like there’s New Awakening and Hard Awakening.


Wario Land 2 & 3

I can’t say that I’m too familiar with Wario Land 2 and Wario Land 3 other than that they are really well animated games and have good reviews and great sprites.


There’s not too much in terms of rom hacks. It looks like there is a Master quest romhack for Wario Land 3 that rearranges all of the areas to provide a new experience. Persoanlly thinking abotu Wario Land 2 and Wario Land 3 makes me wonder about the different versions of Gameboy cartridges. There are the grey, black and clear cartridges. And I’m kind of wondering what the difference is.

Specifically I know the gray cartridges are for the original gameboy. So the only graphics are the ones included are shades of grey/green. The gameboy color attempted to automatically create palettes for these games. Then the are the black cartridges which work both on the Gameboy and the Gameboy color. I suppose that these are games built to the specs of the gameboy, but also have color data defined. And then the clear color cartridges are likely games that are built specifically for the Gameboy color, which means they probably use more RAM and VRAM.

In general I wonder if there is any difference between black and clear cartridges. Specifically it looks like a colored ROM hack would basically be a black cartridge and a ROM hack that added more sprites and took advantage of the extra RAM would probably effectively be a complete gameboy color port.