Drunken Coders

Breaking new ground in console homebrew development

Hello!

After a few years, at last I continue with this emulator. :P I’ve been coding for a few weeks and at last I have a release.

The main change is that it now uses SDL2 for the GUI, not WinAPI. It can compile under Windows or Linux with the included Code::Blocks project file (I want to add a Makefile later). You can check the source code here:

 

https://github.com/AntonioND/giibiiadvance

 

Some screen captures:

 

giibiiadvance020giibiiadvance020_2

(more…)

Posted by AntonioND

In responce to the call for extra credit in the Space Invaders test compo Mtheall has implemented the space ship generator code on an HTML 5 canvas. Now you have no excuses!

Untitled

http://mtheall.com/~mtheall/spaceship.html

Posted by dovoto

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

Rotate a bitmap 
---------------------------------------------------------------------------------*/
#include 

#include "drunkenlogo.h"

//---------------------------------------------------------------------------------
int main(void) {
//---------------------------------------------------------------------------------
	
	videoSetMode(MODE_5_2D);
	vramSetBankA(VRAM_A_MAIN_BG);

	int bg = bgInit(3, BgType_Bmp16, BgSize_B16_256x256, 0,0);
	dmaCopy(drunkenlogoBitmap, bgGetGfxPtr(bg), drunkenlogoBitmapLen); 

	bgSetCenter(bg, SCREEN_WIDTH/2, SCREEN_HEIGHT/2);
	bgScroll(bg, SCREEN_WIDTH/2, SCREEN_HEIGHT/2);

	while(1) 
	{
		swiWaitForVBlank();

		bgRotate(bg, 10);

		bgUpdate();
	}

}

Remember to call bgUpdate() once per frame when using rotations and scaling. You can set a specific angle with bgSetRotate().

Posted by dovoto

Probably the most challenging aspect of this is setting up your background memory so your maps and your graphics dont overlap between the keyboard and the console. I used mtheall’s slick vram tool to figure it out:

http://mtheall.com/vram.html#T0=3&NT0=128&MB0=2&TB0=0&S0=0&T1=4&NT1=864&MB1=3&TB1=1&S1=2

Posted by dovoto
Posted by dovoto

Another test of the compo engine to see if it is ready to handle the load necessary for a smooth winter coding compo.

Your goal is to create the worlds greatest Space Invaders clone for the Nintendo DS. There is no requirement for this to run on hardware (I am too lazy to test outside of the emulator anyway) nor are there any other rules really. Compos will be judged against arbitrary standards to be announced soon ish.

You have one week!

Space Invaders!

To get you started, here are some spaceship graphics I stole from http://web.archive.org/web/20080228054410/http://www.davebollinger.com/works/pixelspaceships/ (bonus points to anyone who can get the space ship generator on that site working as an html5 canvas) Mtheall has done it! http://mtheall.com/~mtheall/spaceship.html

pixelspaceships_wp_color_1600x1200

Posted by dovoto

Here is a very simple example on how to take an image stored as a .png file (or any of the supported file formats supported by grit) and put it on the screen. The first thing we need is a target image. For that let’s chose our standard Drunkencoder logo:

drunkenlogo

I cant tell you exactly how this was made but I am fairly certain there was some sort of paint program involved. Anyway, notice it is 256×256 png file which matches one of the allowed background sizes for the DS (this isn’t necessary it just makes the copy to video memory trivial and this demo is…well…trivial).

Next we need to convert our image into something the DS can understand and there are a few ways to make that happen. We could write it to an SD card file system or use the special file system supported by Nintendo DS roms called nitroFS and then try to parse the data as we load it. Or we could do it the easy way and run it through grit which is included with libnds and devkitPro.

To do this is very easy. Simply create a folder called “gfx” or “data” in your project directory and drop the png file into it. Next create a text file with a name that matches your image file but with an extension of .grit.

This file is how we tell grit what to do with our image….in this case we want it to create a binary array of pixel data we can just copy into video memory. Its pretty simple and we only need three options. First is -gT! this tells grit to ignore any transparency data in the image file and set all the pixels to visible (if you don’t use this there is a good change your image won’t render correctly or you will have to set the alpha bits of each pixel manually as you load them into video memory, using the alpha channel of an image is very useful but for now its likely just to confuse things so lets turn it off).

Then we do -gB16 and -gb which tells grit to produce 16 bit pixel bitmap data and to write that out as a straight binary file. There are a LOT of options for grit and we will explore many of them in these FAQs but your best bet is the grit readme or website to really get a feel for how it all works.

Your grit file should look something like the following:

# disable alpha and set opaque bit for all pixels
-gT!

# 16 bit bitmap
-gB16
-gb

The magic makefile included in the libnds example templates will automatically call grit on all the image files in your gfx directory using the options supplied in the grit file. This will produce a binary file and a header file for easy inclusion in your project.

Here is what the actual code for the demo looks like:

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

Render a 16 bit per pixel bitmap to the screen

---------------------------------------------------------------------------------*/
#include 
#include 

int main(void) {



	videoSetMode(MODE_5_2D);
	vramSetBankA(VRAM_A_MAIN_BG);

	int bg = bgInit(3, BgType_Bmp16, BgSize_B16_256x256, 0,0);
	dmaCopy(drunkenlogoBitmap, bgGetGfxPtr(bg), drunkenlogoBitmapLen); 

	while(1) 
	{
		swiWaitForVBlank();
	}

	return 0;
}

That “drunkenlogo.h” is the header file auto generated by grit. You can find it in your “build” directory after you call make. If you were to open it up you would see something like the following:

//{{BLOCK(drunkenlogo)

//======================================================================
//
//	drunkenlogo, 256x256@16, 
//	Alphabit on.
//	+ bitmap not compressed
//	Total size: 131072 = 131072
//
//	Time-stamp: 2013-08-24, 17:01:25
//	Exported by Cearn's GBA Image Transmogrifier, v0.8.10
//	( http://www.coranac.com/projects/#grit )
//
//======================================================================

#ifndef GRIT_DRUNKENLOGO_H
#define GRIT_DRUNKENLOGO_H

#define drunkenlogoBitmapLen 131072
extern const unsigned int drunkenlogoBitmap[32768];

#endif // GRIT_DRUNKENLOGO_H

//}}BLOCK(drunkenlogo)
Posted by dovoto

Let’s just modify the libnds 16-bit bitmap demo included in libnds examples to allow text on the same screen. All we really need to do is set up the console for the main display using background layer 0 and move our bitmap graphics to make room for it by adjusting its map base offset (an offset of 1 moves the memory 16KB further into memory which is plenty of room for a font and a map layer for text).

#include 
#include 

int main(void) {
	

	
	videoSetMode(MODE_5_2D);
	vramSetBankA(VRAM_A_MAIN_BG);
	
        int bg = bgInit(3, BgType_Bmp16, BgSize_B16_256x256, 1,0);
	decompress(drunkenlogoBitmap, bgGetGfxPtr(bg), LZ77Vram); //Displays/decompresses top image

	consoleInit(0,0, BgType_Text4bpp, BgSize_T_256x256, 4,0, true, true);
	iprintf("Hello there !");
	
       while(1) {
		swiWaitForVBlank();
	}
	return 0;
}

And we get:
16bitwithtext

Posted by dovoto
/*---------------------------------------------------------------------------------

	Basic template code for starting a DS app

---------------------------------------------------------------------------------*/
#include <nds.h>

//---------------------------------------------------------------------------------
int main(void) {
//---------------------------------------------------------------------------------
	int x, y;

	//set the mode to allow for an extended rotation background
	videoSetMode(MODE_5_2D);
	videoSetModeSub(MODE_5_2D);

	//allocate a vram bank for each display
	vramSetBankA(VRAM_A_MAIN_BG);
	vramSetBankC(VRAM_C_SUB_BG);

	//create a background on each display
	int bgMain = bgInit(3, BgType_Bmp16, BgSize_B16_256x256, 0,0);
	int bgSub = bgInitSub(3, BgType_Bmp16, BgSize_B16_256x256, 0,0);

	u16* videoMemoryMain = bgGetGfxPtr(bgMain);
	u16* videoMemorySub = bgGetGfxPtr(bgSub);


	//initialize it with a color
	for(x = 0; x < 256; x++)
		for(y = 0; y < 256; y++)
		{
			videoMemoryMain[x + y * 256] = ARGB16(1, 31, 0, 0);
			videoMemorySub[x + y * 256] = ARGB16(1, 0, 0, 31);
		}

	while(1) 
	{
		swiWaitForVBlank();
	}

}

The only thing of note in the above that may not be clear from the code and cross referencing the libnds documentation is the macro ARGB16(). This takes an alpha value (1 for visible, 0 for transparent) and 5 bits of red green and blue to form the 16 bit color.

Posted by dovoto

Background control is provided via an API or Direct register access. Usually these methods can be mixed. However, scrolling, scaling, and rotation will have unexpected results if API and Direct Register access is mixed. Effort is being directed at ensuring the API can access all hardware features without limitation.

The DS contains two separate hardware 2D cores responsible for rendering 2D backgrounds. The definitions below outline the libnds api for utilizing these backgrounds.
The background engine provides basic initialization and management of the 8 2D backgrounds available on the DS. Other than initialization and hardware limitations background control is identical on both main and sub screens.

The following modes of operation are allowed:

Main 2D engine
______________________________
|Mode | BG0 | BG1 | BG2 |BG3 | T = Text
| 0 | T | T | T | T | R = Rotation
| 1 | T | T | T | R | E = Extended Rotation
| 2 | T | T | R | R | L = Large Bitmap background
| 3 | T | T | T | E |
| 4 | T | T | R | E |
| 5 | T | T | E | E |
| 6 | | L | | |
—————————–
Sub 2D engine
______________________________
|Mode | BG0 | BG1 | BG2 |BG3 |
| 0 | T | T | T | T |
| 1 | T | T | T | R |
| 2 | T | T | R | R |
| 3 | T | T | T | E |
| 4 | T | T | R | E |
| 5 | T | T | E | E |
—————————–
On the main engine BG0 can be used as a 3D rendering surface.

Posted by dovoto

Smealum has finally released his work in progress. A very functional, playable, and editable Portal clone. Watch the video and try out the rom!

scr1

Posted by dovoto

Here is a neat little project (with schematics and source code) to interface a GBA to a pic microcontroller and use it for a data acquisition system. GBA_meter

Its pretty cool and uses the Multiboot protocol so you can probably build the whole thing for a couple of dollars.

A link to the project!

Posted by dovoto

After a very long pause Martin has released an update to his powerful emulator NO$GBA. For a long time we wondered if he was subject to some foulplay but it turns out he is still alive and kicking. The paypal links seem to be working for the $15 homebrew debug version which, in the past, has been money very well spent.

In its day, NO$ was easily the most accurate DS emulator out there and I would say still gives the others a tight run for their money….not to mention its coded in that OCD fashion we all love allowing it to zip along on even modest hardware.

Here is a long list of changes: Changes

And a link to the homebrew debugger page: http://nocash.emubase.de/gba-dev.htm

Posted by dovoto

Been working on a back end to host coding competitions and could use some help testing it out. Come check out our first compo:

Pong

Current Entries

Posted by dovoto

Hello!

I’ve been messing around with electronics lately (after all, that’s what I’m studying :P), and this is the result! A 32×8 LED Matrix controlled by a PIC18F2550. You can click in the pictures for full size! At the end of the post there is a video of the screen running.

Everything together

(more…)

Posted by AntonioND

This wont help but if you find it fun to watch then you are probably on the right website!

Posted by dovoto

Finally, a bitcoin mining with a purpose!

Although a touch convoluted by using a Raspberry Pi to fetch bits of work and a webcam to read the result from the NES in the form of a screen color change its still pretty slick.

RetroMiner

Posted by dovoto

This may be one of the more ridiculous things I have ever seen…an 8 bit serial computer built ENTIRELY of NAND gates and wire routing…

Crazy attention to detail. If you don’t follow kevtris you should.

What is a NAND computer? Well a quick refresher on digital logic:

There are a few fundamental building blocks to constructing a digital circuit. These are gates, which perform the basic boolean logic operations (OR, AND, NOR, NAND, XOR, NOT) and latches/flipflops which preserve the value of a bit. It turns out that you can build any gate from a NAND gate and so can build flip flops and latches from NAND gates as well. (for more info see: http://en.wikipedia.org/wiki/NAND_logic )

The picture you see below is a whole bunch of NAND gates in discreet logic chips which are wired together to form an entire CPU. The better you understand it the more you will realize how ridiculous it is that someone thought to do it and furthermore how crazy they must have been to actually finish it.

http://blog.kevtris.org/

Posted by dovoto

Now this is just pretty slick. It seems these guys decap and photo old chips, then trace them out using some custom tools and convert the images to netlists for use in a javascript simulator. The result? A gate level simulation of the entire NES PPU you can interact with on a web page (at about 2Hz mind you) including the ability to trace signals and nodes. Its pretty crazy and worth checking out.

http://www.qmtpro.com/~nes/chipimages/visual2c02/

http://www.visual6502.org/faq.html

Posted by dovoto

sverx has posted some memory benchmarks in an attempt to answer that ever annoying question of which memory copy method is fastest on the DS.

Some of the more interesting results:

  • copying using DMA is both the slowest option (when copying to main RAM) and the fastest one (when copying to video RAM)
  • memcpy() gets overtaken by almost every other method, so I guess one should use it only when prototyping or when performance is not an issue
  • reading from an uncached address seems to give some % of boost when using ldmia/stmia; it just makes things worse when using memcpy()
  • Loop unrolling doesn’t give any advantage when copying to main RAM; on the contrary, it effectively speeds up a bit when copying to video RAM
  • reading from a cache unaligned source address can slow down things a bit, especially when reading from a cached address
  • using a DTCM temporary copy doesn’t help

Read the full post here: A DS Homebrewer’s Diary

Posted by dovoto
Featured Video