https://lolsnes.kuribo64.net The latest news on lolSnes devblog. https://lolsnes.kuribo64.net/?eid=6 Wed, 18 Dec 2013 16:07:04 +0000
I've been busy between real life and lolSnes, so uh, this site went a little neglected in the meantime. But now it's time to fix it.

The compatibility list is finally a thing. Later on there may be an automatic submission interface, but in the meantime, post your submissions in the lolSnes thread.

I'll also do the remaining page (Screenshots) soon.]]> e6 https://lolsnes.kuribo64.net/?eid=5 Thu, 17 Oct 2013 10:17:30 +0000
First of all, the SNemulDSP experiment is done. It turned out to be successful. I've been able to not only successfully integrate SNemulDS's DSP code, but also improve it a bit. Sound output is finally stable and at the right pitch, and I also added linear interpolation. It doesn't sound as good as the real thing, but it's pretty good already.

Sadly, this tends to come at the expense of performance. I'll probably make interpolation optional, and also give an option to lower the sampling frequency to 24KHz instead of 32KHz. I also don't believe the ARM7 will be able to handle any better interpolation without a dramatic performance hit.


On the graphics side, progress is being made too. More video modes are supported, among which, mode 7. HDMA is still not supported, though.

Mode 7 is implemented in such a way that it is possible to switch to/from it at any time with about no performance hit. This is particularly useful for games that use mode 7 combined with another mode, like SMW's boss rooms.

I've also been fixing bugs with the VRAM mapping handler, fixing several cases of missing or corrupt graphics. For example, Earthbound no longer has those weird stripes in its background, and Super Puyo Puyo now looks alright, or almost.


My next main targets before the 1.1 release will be to fix the issues that plague the ROM cache and make Super Metroid hang, and fix more important PPU bugs. Layer priority comes to mind. I need to redo it properly and get rid of that awful BG3 priority hack.]]> e5 https://lolsnes.kuribo64.net/?eid=4 Mon, 23 Sep 2013 22:24:47 +0000
To be performant enough, it'd have to be rewritten into ASM. So instead, I had another idea: trying to use SNemulDS's DSP code. It works, it doesn't suffer from performance issues (or not as much as my code), it supports more features than my code (namely ADSR), and I have good ideas on how to make it better.

I figured that since my C code will have to be trashed anyway, this may be a good idea. I'd normally write my own code, but sound programming is kinda annoying. Mainly because when the output sounds wrong, it's not always easy to find out what you're doing wrong.


I will be experimenting this idea in a separate branch named SnemulDSP. If it is successful, I'll merge it into the master branch.

There will be no Git builds for the SnemulDSP branch, sadly. The autobuild system only works with one branch.]]> e4 https://lolsnes.kuribo64.net/?eid=3 Sat, 07 Sep 2013 23:01:45 +0000
There's also a RSS feed for this, so you can be informed of new Git builds at any time.

Enjoy!]]> e3 https://lolsnes.kuribo64.net/?eid=2 Tue, 03 Sep 2013 01:14:30 +0000
Immediate results were that the game didn't even start. It got stuck while uploading data to the SPC700. The code it uses for that is the same that is used in SMW, and it works fine there, so the problem was likely not inside the routine.

I noticed that the routine was reading its data from uninitialized RAM. Since it was the same data over and over again, it'd keep transferring forever.

I then ran the game in NO$SNS, pointed the memory viewer to where the SPC700 data was, and searched for that data inside the ROM. The data appeared at address 07:FC00 (file offset 0x3FC00). I then added some logging of DMA transfers in lolSnes, and quickly found out what was wrong.

The game did a DMA transfer from 07:FC00 to port $2180. This port can be used for reading and writing to the WRAM, and is useful when transferring data from ROM to WRAM. It was not implemented in lolSnes. After implementing it, the game progressed further.


The Nintendo logo appeared, and then the menu. But, no sound. And trying to go anywhere would freeze the game. This looked like the SPC700 program was crashing. Some debugging revealed that it was calling a function, but the memory space where the function should have been, was empty.

This meant that not all the SPC700 data was being transferred. The size of the data chunk was 0x210F, but the DMA transfer that copied it to WRAM was only 1024 bytes long. Another similar DMA transfer was done to copy the rest of the data, but it was failing.

The address the second transfer copied from, happened to be above the first megabyte of ROM (the SMAS ROM is 2MB). Since lolSnes only caches the first megabyte of ROM into RAM, the DMA was reading from uncached ROM. Logging uncached ROM reads quickly revealed the issue: the file offset values used were wrong. This was a silly mistake in the code that reads the memory mapping table for DMA transfers (the code for regular memory accesses was unaffected).


Once this issue fixed, SMAS gets further. It gets sound, and goes ingame. For now though, you can't control Mario. This is probably due to SMAS using oldstyle joypad IO, which isn't supported in lolSnes.

There's also the graphics corruption almost everywhere. This is due to an unsupported video mode and should be fixed soon.


While I was at it, I came back to SMW, wanting to fix the bug that broke autoscroll in Donut Plains 2 and rendered the level unplayable. I first asked the SMWC community for some technical information about SMW's autoscroll mechanism, figuring it'd be easier to fix the bug if I roughly knew where to look.

I examined the code around the locations the SMWC guys pointed me to. A part of the code was doing a division, I figured that might be what's at fault. Quickly tried making the division result always be zero: the level just didn't scroll at all.

I then logged divisions. The one division that intervened in autoscrolling was always 256 / 7. This didn't look right. The autoscroll parameters aren't fixed. Some debugging in NO$SNS revealed that the 256 there was not right.

The value was being pulled from WRAM (at $0A) and then written to the dividend register. In lolSnes, the value in RAM was correct, but not the dividend value used in the division. The bug was quite stupid: the game was writing the 16bit dividend directly, and 16bit writes to that register were just not handled. After fixing this, the autoscroll worked flawlessly.


Most bugs there are silly mistakes, apparently. Oh well :P]]> e2 https://lolsnes.kuribo64.net/?eid=1 Fri, 23 Aug 2013 20:43:37 +0000
This site is still under construction, so several links are 404 for now. That won't last, though ;)


As for lolSnes, I just got a icon for it, courtesy of Flurry (from GBAtemp):


I'll add it to lolSnes. In the meantime, you'll notice that I made a 16x16 version of it for this site.]]> e1