Guru Mediation Error

[spectre1989]

Hi all,

I really didn't intend on asking my next dumb question so soon, but I've hit the next wall in my nds programming, a "Guru Mediation Error".

My program worked on nocash (which I know doesn't mean it will work on hardware) so what kind of things could cause an issue on hardware that doesn't occur on an emulator?

I'm using an EZ Flash V. My program uses libfilesystem, and after I removed the default exception handler code, the mediation error no longer occurred but nitrofs is failing to initialise. Other things of note, the program is linked with the dswifi lib but doesn't actually actively use it yet. I've also tried applying the EZ Flash V dldi patch to the rom (not sure if that would make a difference, still very new to all this) which didnt fix the problem.

Not really sure where to start here, any advice from the pros?

Cheers!
Spec

[melw]

You should definitely keep the defaultExceptionHandler() for helping find the problems in your code. This enables the exception screen that shows the register values and current addresses where things went wrong. You can then trace back these addresses on your development computer with following command:

Code: Select all

addr2line -e <nds_name>.elf <address>

Valid address range starts at 0x02000000, if addr2line doesn't give any any reasonable results then you've done something wrong already earlier in the code (say, hit a stack overflow or reading/writing in invalid memory areas).

[spectre1989]

Ah ha, can't believe I could be so stupid. Basically after I output the text saying "nitrofs failed to initialise" I then didn't halt the program, so without the default exception handler the program output the text and then crashed. I've now changed it and I no longer get the mediation error, so I'm pretty certain all that happened was I was trying to use nitrofs when it hadnt actually initialised.

So what I need to work out now is why nitrofs won't initialise.. Again I'm on an EZ Flash V if that has any significance. Does anyone know if making a rom like this run will require certain patches and such like?

[StevenH]

How are you launching your nds file that uses libfilesystem/nitrofs?

If you are using Moonshell then you will always fail to init the filesystem as it does not support the missing information that is needed to run nds files that use nitrofs. You will need to use the homebrew menu that is in the SVN for devkitPro (Not sure if WinterMute will be releasing an nds version of this in a future dkP or not) as that application supports the new libfilesystem and nitroFS boot order.

Basically what's missing is the argv[0] / file location that is normally passed to an application from the OS, this is what the homebrew menu application provides to the newly launched nds file.

[spectre1989]

How are you launching your nds file that uses libfilesystem/nitrofs?

If you are using Moonshell then you will always fail to init the filesystem as it does not support the missing information that is needed to run nds files that use nitrofs. You will need to use the homebrew menu that is in the SVN for devkitPro (Not sure if WinterMute will be releasing an nds version of this in a future dkP or not) as that application supports the new libfilesystem and nitroFS boot order.

Basically what's missing is the argv[0] / file location that is normally passed to an application from the OS, this is what the homebrew menu application provides to the newly launched nds file.

You, good sir, are my new god! I also found http://blea.ch/wiki/index.php/Talk:Nitr ... ary_so_far which has a block of code for finding the .ds filename, I loaded up the example rom which uses it and it worked, however I'm not sure how to incorporate it into libfilesystem without playing with the source...

[WinterMute]

You, good sir, are my new god! I also found http://blea.ch/wiki/index.php/Talk:Nitr ... ary_so_far which has a block of code for finding the .ds filename, I loaded up the example rom which uses it and it worked, however I'm not sure how to incorporate it into libfilesystem without playing with the source...

You don't.

As Steven said, you use the homebrew menu from SVN, patched with a DLDI for your card. Searching for the filename is a seriously bad idea, both in terms of the time required to do it and the fact that there's zero guarantee it will find the right file.

[spectre1989]

You don't.

As Steven said, you use the homebrew menu from SVN, patched with a DLDI for your card. Searching for the filename is a seriously bad idea, both in terms of the time required to do it and the fact that there's zero guarantee it will find the right file.

Well I grabbed the homebrew menu off of SVN, and well, I'm just a little ticked off that the official EZ Flash people can't write a loader that properly sets up argv, but I guess it's more aimed at pirates than developers.

Anywho, I'm having some issues (again) and my app seems to resemble the matrix or something lol. I'm trying to set up a console of sorts (I know I could use the one in libnds, but I'm just doing it as an exercise), it works in emulators fine but on hardware it looks all messed up:

Code: Select all

//main.cpp
#include <nds.h>
#include <fat.h>
#include <filesystem.h>
#include <stdio.h>

#include "Text.h"

void init(void)
{
	defaultExceptionHandler();
	irqInit();
	irqEnable(IRQ_VBLANK);

	fatInitDefault();
	if(!nitroFSInit())
	{
                consoleDemoInit();
		printf("Failed to init NitroFS\n");
		while(1){swiWaitForVBlank();}
	}
	Text::init();
}

int main(void) {
	
	// Initialise
	init();

	Text::cprintf("Hello world! %d\nSecond line...", 42);
	while(1){swiWaitForVBlank();}

	return 0;
}

// Text.h
#ifndef _TEXT_H_
#define _TEXT_H_

#include <nds.h>
#include <stdio.h>
#include <stdarg.h>

#include "ContentLoader.h"

class Text
{
private:
	static u16* m_map;
	static int m_hbg;
	static int m_cx;
	static int m_cy;
public:
	static void init()
	{
		// Set up top screen to display some text
		videoSetMode( MODE_0_2D );
		vramSetBankA( VRAM_A_MAIN_BG );
		m_hbg = bgInit( 0, BgType_Text4bpp, BgSize_T_256x256, 0,3);
		
		// Find the file
		FILE* fontFile = fopen("nitro:/fonts/font.bmp","rb");
		if(!fontFile)
		{
			consoleDemoInit();
			printf("Couldn't find the file");while(1){swiWaitForVBlank();}
			return;
		}

		// Load the bitmap
		BmpFile* bmp = ContentLoader::loadBitmap(fontFile);

		// Close file
		fclose(fontFile);

		//copy the palette
		for(unsigned int i = 0; i < bmp->info.numColors; i++)
		{
			BG_PALETTE[i] = RGB15(bmp->colors[i].red >> 3, bmp->colors[i].green >> 3, bmp->colors[i].blue >> 3);
		}

		// copy image into tile memory
		dmaCopy(bmp->image, bgGetGfxPtr(m_hbg), 96*32); // This happens to be a vertical strip of 96 8x8 4bpp characters

		// clear the memory
		delete[] bmp->colors;
		delete[] bmp->image;
		delete bmp;

		// Initialise map
		m_map = new u16[32*32];
		for(int i = 0; i < 32*32; ++i) m_map[i] = 0;
		
		dmaCopy(m_map, (u16*)bgGetMapPtr(m_hbg), 32*32*2);
	
		// Init cursor
		m_cx = 0;
		m_cy = 0;
	}

	static void cprintf(const char* format, ...)
	{
		// Get string
		char b[256];
		va_list args;
		va_start(args, format);
		vsnprintf(b, 256, format, args);
		va_end(args);

		// Check for empty string
		if(b[0]=='\0') return;

		// Print string
		int mapIndex;
		int c = 0;
		do
		{
			mapIndex = m_cy*32 + m_cx;

			if(b[c] == '\n')
			{
				++m_cy;
				m_cx = 0;
			}
			else
			{
				if(m_cx > 31)
				{
					m_cx = 0;
					++m_cy;
				}
				m_map[mapIndex] = b[c]-32;
				++m_cx;
			}

			++c;
		}while(b[c] != '\0');

		dmaCopy(m_map, (u16*)bgGetMapPtr(m_hbg), 32*32*2);
	}

	static void clear()
	{
		for(int i = 0; i < 32*32; ++i) m_map[i] = 0;
		
		dmaCopy(m_map, (u16*)bgGetMapPtr(m_hbg), 32*32*2);
		m_cx = 0;
		m_cy = 0;
	}

	static void setChar(u8 x, u8 y, u8 c)
	{
		m_map[y*32+x] = c-32;
		
		dmaCopy(m_map, (u16*)bgGetMapPtr(m_hbg), 32*32*2);
	}
};

u16* Text::m_map;
int Text::m_hbg;
int Text::m_cx;
int Text::m_cy;

#endif

// ContentLoader.h
#ifndef _CONTENTLOADER_H_
#define _CONTENTLOADER_H_

#define PACKED_STRUCT __attribute__ ((packed))
#define LONIBBLE(x) x & 0xf
#define HINIBBLE(x) x >> 4

#include <nds.h>
#include <stdio.h>

typedef struct
{
	u8 red;
	u8 green;
	u8 blue;
	u8 reserved;
}PACKED_STRUCT RGB;

typedef struct
{
	char signature[2];
	unsigned int fileSize;
	unsigned int reserved;
	unsigned int offset;
}PACKED_STRUCT BmpHeader;

typedef struct
{
	unsigned int headerSize;
	unsigned int width;
	unsigned int height;
	unsigned short planeCount;
	unsigned short bitDepth;
	unsigned int compression;
	unsigned int compressedImageSize;
	unsigned int horizontalResolution;
	unsigned int verticalResolution;
	unsigned int numColors;
	unsigned int importantColors;
	
}PACKED_STRUCT BmpImageInfo;

typedef struct
{
	BmpHeader header;
	BmpImageInfo info;
	RGB *colors;
	u8 *image;
}PACKED_STRUCT BmpFile;

class ContentLoader
{
public:
	static BmpFile* loadBitmap(FILE* file)
	{
		BmpFile* bmp = new BmpFile;

		// Read header and info
		fread(&bmp->header, sizeof(BmpHeader), 1, file);
		fread(&bmp->info, sizeof(BmpImageInfo), 1, file);

		// Allocate and read colour palette
		bmp->colors = new RGB[bmp->info.numColors];
		fread(bmp->colors, sizeof(RGB), bmp->info.numColors, file);
		bmp->image = new u8[bmp->info.width*bmp->info.height];

		// Read image into a buffer
		unsigned int bytes = bmp->info.width*bmp->info.height;
		if(bmp->info.bitDepth == 4) bytes/=2;
		
		u8* buff = new u8[bytes];
		fread(buff, sizeof(u8), bytes, file);
		
		// Rearrange buffer into image
		for(unsigned int i = 0; i < bytes; ++i)
		{
			bmp->image[i] = buff[bytes-i-1];
		}

		// delete buffer
		delete[] buff;

		// Flip horizontally
		if(bmp->info.bitDepth == 4)
		{
			u8 *hline = new u8[bmp->info.width/2];

			for(unsigned int y = 0; y < bmp->info.height; ++y)
			{
				unsigned int x;
				for(x = 0; x < bmp->info.width/2; ++x)
				{
					hline[bmp->info.width-(x*2)-1] = LONIBBLE(bmp->image[y*(bmp->info.width/2)+x]);
					hline[bmp->info.width-(x*2)-2] = HINIBBLE(bmp->image[y*(bmp->info.width/2)+x]);
				}
				for(x = 0; x < bmp->info.width/2; ++x)
				{
					bmp->image[y*(bmp->info.width/2)+x] = hline[x*2] | hline[x*2+1] << 4;
				}
			}

			delete[] hline;
		}
		
		// Return hopefully the proper data
		return bmp;
	}
};

#endif

Again, sorry for any forehead slappingly stupid mistakes...

[StevenH]

OK, I've just had a quick scan over your code and a couple of things pop into my "DANGER WILL ROBINSONE, DANGER!" tray XD

1) Your attempting to use packed structs on the DS - Unfortunatly this is not possible as if you do a make clean then a make you will see a few warnings about __attribute__ ((packed)) being ignored as not supported on this archutecture.
2) Why are you reading a BMP file? why not just use grit to convert the BMP font data into a DS memory block and copy directly into the tile positions?
3) Are you sure that the BMP file is saved in that format? what about compression? A bitmap file has many save modes, and you are making an assumption about the layout of the file.
4) You do know that a BMP file is stored bottom first right?
5) Your cprintf() code moves the currect X and Y positions but does not update the mapindex before updating your internal map
6) Why us an internal map? just interface with the tile map of the screen directly?
7) If you want to use an internal map the lines that read for(int i = 0; i < 32*32; ++i) m_map = 0; can be changed easily to memset( m_map, 0, 32*32); as IIRC it's faster and easier to maintain.
WARNING TOO MANY PROBLEMS - ABORTING LISTING REPLY HERE.

As for your comment about the Ez Flash crew not writing propper homebrew launchers correctly, they did not write the launcher that you use on the Ez Flash V / Vi (Small assumption here that the V is using the same Moonshell bastardisation version that the Vi uses) as it was originally wrote before the libfilesystem was out, hell I think the version of moonshell that is used as the launcher is about 3 years old since the latest version (Moonshell 2) is still in a prolonged beta period. Back then the libfilesystem did not really need a homebrew launcher, and as you say there's been a lot of work put into the pirate side (hell just a quick look on the EzFlash forums can atest to that).

If you want to develop your own console code you may want to look at the console.c file that is in the SVN for devkitPro or you can download an alternative console from here which is a graphical console that uses a 16 bit bitmap mode, there's even a utf8 aware font support getting added to the next release and I'm working on adding support for using sprites as an output for the iprintf code.

When you say it works on emulators - which emulators are you using? as the utf8 code I had originally worked flawlessly on an emulator (no$) but crashed and burned on actuall harware (EzFlash Vi + DSi) until I re-checked a couple of lines and spotted a slight mistake in an array access.

[spectre1989]

Yup I'm aware of the way bitmaps are stored, hence why I read it in backwards and then flip the horizontal lines. As for the file being in the right format, yeah I'm pretty positive given how it works perfectly in emulators (tested on no$ and dualis). Also not getting any warnings about __attribute__ ((packed)), I only heard of it through the tutorials on dev-scene, but I'll take your word for it and strip that stuff out.

Also the reason I'm using an internal map is I thought that I could only write to the tile map using dmacopy?

[StevenH]

Yup I'm aware of the way bitmaps are stored, hence why I read it in backwards and then flip the horizontal lines. As for the file being in the right format, yeah I'm pretty positive given how it works perfectly in emulators (tested on no$ and dualis). Also not getting any warnings about __attribute__ ((packed)), I only heard of it through the tutorials on dev-scene, but I'll take your word for it and strip that stuff out.

Also the reason I'm using an internal map is I thought that I could only write to the tile map using dmacopy?

Strange how your not getting any wornings, as I was always getting them...

No just look at the console.c code in the SVN as I used that as the basis of my graphics console, hell even my voxel test and fli player accesses the memory directly instead of via a buffer...