What is important for SDK

#Sumary Yifan Lu is making a SDK for PS Vita. To get a hint to make it better, I’ll point out important things for SDK.

SDK should have the following feature:

They allows to make a SDK which can be used for any purpose anytime.

#Introduction Today, PS Vita and 3DS homebrew scene is on active development. To make the scenes better, I’ll consider what is important for SDK referring the following SDKs.

[Yifan Lu Calling all coders: We need you to help create an open Vita SDK!](http://yifan.lu/2015/05/23/calling-all-coders-we-need-you-to-help-create-an-open-vita-sdk/)

I’ll consider why PSPSDK is so great.

#PSPSDK PSPSDK has some features which allows coder to write a program easily. Some of them come from API of PSP implemented by SCE. Actually, SDK on proprietary software is bound to API. So the quality of SDK does not correspond developers’ skills. However, PSPSDK has unique features.

This part refers to a sample in PSPSDK:

/*
 * PSP Software Development Kit - http://www.pspdev.org
 * -----------------------------------------------------------------------
 * Licensed under the BSD license, see LICENSE in PSPSDK root for details.
 *
 * main.c - Basic PRX template
 *
 * Copyright (c) 2005 Marcus R. Brown <mrbrown@ocgnet.org>
 * Copyright (c) 2005 James Forshaw <tyranid@gmail.com>
 * Copyright (c) 2005 John Kelley <ps2dev@kelley.ca>
 *
 * $Id: main.c 1888 2006-05-01 08:47:04Z tyranid $
 * $HeadURL$
 */
#include <pspkernel.h>
#include <stdio.h>

/* Define the module info section */
PSP_MODULE_INFO("template", 0, 1, 1);

/* Define the main thread's attribute value (optional) */
PSP_MAIN_THREAD_ATTR(THREAD_ATTR_USER | THREAD_ATTR_VFPU);

int main(int argc, char *argv[])
{
	printf("Hello World\n");

	return 0;
}

TARGET = template
OBJS = main.o

BUILD_PRX=1

INCDIR = 
CFLAGS = -O2 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)

LIBDIR =
LDFLAGS =

PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak

##POSIX As you can see, it has a compatibility with POSIX. PSPSDK offers several libc with API of PSP. Thanks to API of PSP which is similar to POSIX, those libraries can offer most standard functions. It allows to port softwares easily. As a instance, Snes9x with many POSIX functions has been ported easily.

##Compact Code Its overhead code is only 4 lines (PSP_MODULE_INFO and PSP_MAIN_THREAD_ATTR) That’s amazing. It means that a software without hardware dependencies can be ported just by adding 4 lines.

##Makefile PSPSDK offers several files which enable to write Makefile easily. At a glance, they may be useful to write Makefile. Actually, those features are used by many applications. However, some of them can cause a comatibility problem. I’ll show some of them.

###psp-config PSPSDK has their unique applications written in C language. psp-config is one of them. But the dominant usage is setting of PSPSDK variable. The application reduces portability only for that.

###build.mak build.mak seems useful because it allows to build executable file (EBOOT.PBP or prx) only by defining objects and TARGET. But build.mak restricts developers and causes compatibility issues.

As you can see, the Makefile doesn’t specify targets (not TARGET). It means the Makefile can’t offer several targets. Some applications like HBL which specifies several targets can’t use build.mak.

Its compatibility issues can be shown by the large memory support and PrxEncryptor support. Some developers has modified to support them and lost their build.mak compatibility.

The solution of the issues is easy: remove the target definitions. But it will lose its usability. Something like build.mak should not be used.

##Conclution of This Part The best PSPSDK’s advantage is this: the usability. Even you don’t have any knowledge of PSP, you can write code. But even a great things has its disadvantages. It should be more compact to improve the portability and compatibility

#devkitARM devkitARM is great in the point that it can be used for many devices. The feature keeps older devices up-to-date. For example, you can use LTO (Link Time Optimization) function which is introduced by 4.6 and still high development. However, devkitARM is not more successful than PSPSDK, as I wrote. I’ll point out the issues.

##Share of libc It disables to implement device-dependencies. The problem is clear. You can’t use functions like fopen.

##Complex Let’s see the list of repositories… devkitPro (GitHub)

Too complex. Even if you have knowledges of GBA, you can’t use the knowledges. Neither contents have consistency.

The libraries include unnecessary parts and it makes itself too complex and produce overheads. For example, let’s see decompress.c in libnds.

/*---------------------------------------------------------------------------------

Copyright (C) 2005
Jason Rogers (dovoto)

This software is provided 'as-is', without any express or implied
warranty.  In no event will the authors be held liable for any
damages arising from the use of this software.

Permission is granted to anyone to use this software for any
purpose, including commercial applications, and to alter it and
redistribute it freely, subject to the following restrictions:

1.	The origin of this software must not be misrepresented; you
must not claim that you wrote the original software. If you use
this software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.

2.	Altered source versions must be plainly marked as such, and
must not be misrepresented as being the original software.

3.	This notice may not be removed or altered from any source
distribution.


---------------------------------------------------------------------------------*/

#include <nds/arm9/decompress.h>
#include <nds/bios.h>
#include <nds/arm9/sassert.h>

int getHeader(uint8 *source, uint16 *dest, uint32 arg) {
	return *(uint32*)source;
}

uint8 readByte(uint8 *source) {
	return *source;
}

TDecompressionStream decomStream = {
	getHeader,
	0,
	readByte
};

void decompress(const void* data, void* dst, DecompressType type)
{
	switch(type)
	{
		case LZ77Vram:
			swiDecompressLZSSVram((void*)data, (void*)dst, 0, &decomStream);
			break;
		case LZ77:
			swiDecompressLZSSWram((void*)data, (void*)dst);
			break;
		case HUFF:
			swiDecompressHuffman((void*)data, (void*)dst, 0, &decomStream);
			break;
		case RLE:
			swiDecompressRLEWram((void*)data, (void*)dst);
			break;
		case RLEVram:
			swiDecompressRLEVram((void*)data, (void*)dst, 0, &decomStream);
			break;
		default:
			break;
	}
}

void decompressStream(const void* data, void* dst, DecompressType type, getByteCallback readCB, getHeaderCallback getHeaderCB)
{
#ifdef ARM9
	sassert(type != LZ77 && type != RLE, "LZ77 and RLE do not support streaming, use Vram versions");
#endif


	TDecompressionStream decompresStream =
	{
		getHeaderCB,
		0,
		readCB
	};

	switch(type)
	{
		case LZ77Vram:
			swiDecompressLZSSVram((void*)data, (void*)dst, 0, &decompresStream);
			break;
		case HUFF:
			swiDecompressHuffman((void*)data, (void*)dst, 0, &decompresStream);
			break;
		case RLEVram:
			swiDecompressRLEVram((void*)data, (void*)dst, 0, &decompresStream);
			break;
		default:
			break;
	}
}

It doesn’t seem necessary. It’s more easier to call SWI directly. libnds has many similar functions.

##Conclusion of This Part It’s clear that the complexity and lacks of compatibility make it difficult to use them. However, many people use it because it support many devices.

#Conclution of this article Those examples show what is important for SDK. To make a SDK, it is necessary to be aware of them because anybody can make mistakes and they will be left as they are.

[top]