SMAS progress | lolSnes devblog


175965 views	lolSnes \| Compatibility \| Screenshots \| Download \| Github \| Forums \| RSS feed	04/19/2024 12:04:37
	Guest: ~~Register~~ \| Log in

Main » SMAS progress » Comments

SMAS progress Posted on 09/03/2013 01:14:30 by StapleButter
I figured that I should get lolSnes to run something else than SMW. Super Mario All-Stars seemed a good candidate to test. 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

SMAS progress
Posted on 09/03/2013 01:14:30 by StapleButter

I figured that I should get lolSnes to run something else than SMW. Super Mario All-Stars seemed a good candidate to test.

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

1 comment has been posted.

HolyRomanEmperor says: Posted on 09/05/2013 20:18:09
It's nice to hear that the autoscrollig was fixed in Super Mario World. I am looking foward to hearing more on Super Mario All-Stars and any fixed issues. But at least two games total are now being tested on lolSnes.

Main » SMAS progress » Comments

Page rendered in 0.005 seconds.
MySQL: 12 queries, 10/10 rows. Powered by Kuriblog v1.1
copyright 2010-2024 StapleButter