Sega Genesis Dev Kit (SGDK)

[Chilly Willy]

Unless you're using the light gun support in the controller code, then you need to use level 1, not level 3.

Not a big deal... you'll know if you're using a light gun as you need to look if they're available and then set the controller support to turn on the gun(s).

External is not level 2 ? but as we don't need it we usually set mask interrupt to 3 (so horizontal interrupt are not masked)

External IS level 2, but remember that the mask is a MASK. Just as you use level 3 to ALLOW level 4 and higher, you use level 1 to allow level 2 and higher. That simplified the interrupt hardware in the chip... when a level X int is asserted, just copy that level into the mask and you're safe! No need to make an adder circuit to put X+1 into the mask.

[Stef]

External IS level 2, but remember that the mask is a MASK. Just as you use level 3 to ALLOW level 4 and higher, you use level 1 to allow level 2 and higher. That simplified the interrupt hardware in the chip... when a level X int is asserted, just copy that level into the mask and you're safe! No need to make an adder circuit to put X+1 into the mask.

Yeah it's what i meant, i just misunderstood your previous post :p
We set mask to level 3 to allow H-Int (4) and V-Int (6).
If we need Ext-Int (2) then we need to set mask to level 1

[Chilly Willy]

External IS level 2, but remember that the mask is a MASK. Just as you use level 3 to ALLOW level 4 and higher, you use level 1 to allow level 2 and higher. That simplified the interrupt hardware in the chip... when a level X int is asserted, just copy that level into the mask and you're safe! No need to make an adder circuit to put X+1 into the mask.

Yeah it's what i meant, i just misunderstood your previous post :p
We set mask to level 3 to allow H-Int (4) and V-Int (6).
If we need Ext-Int (2) then we need to set mask to level 1

Yeah, I realize the post was confusing as I left off a word... MASK level versus INT level. Had I said set the MASK level to 1 for external ints, it probably wouldn't have been as confusing.

[lingh]

How should look like bmp file, to use it for font.
Char height, weight, space between char and their order.

[Stef]

How should look like bmp file, to use it for font.
Char height, weight, space between char and their order.

Char should be 8x8 pixels (tile), unfortunately the VDP_loadFont(..) is not really designed it to load that from a single BMP file.
Looks at the font_base.c file and you will see how font is stored.

If you want to load font front a bitmap, use this method instead :

Code: Select all

void VDP_loadBMPTileData(const u32 *data, u16 index, u16 w, u16 h, u16 bmp_w);

Use TILE_FONTINDEX for the index, also the size in tiles (w * h) should be equal to FONT_LEN (96), for instance you can use a 16 * 6 tiles bitmap

[lingh]

Joypad example doesnt work for me.
It's detects correct only 3 and 6 button controllers.

Mouse, Menacer and Justifier - unknown.
JOY_getPortType doesn't help either. Is this works only on real hardware, no luck with emulators?
--
Yep, just check out original compiled rom. Mouse support work, but when i compiled code myself - it doesnt. Some change in constants?
--
All works normal on 2 port. On 1 port you still cant detect mouse, menacer, justifier.

Code: Select all

	s16 stringSize = 10;
	char myString [10];
	
	u8 port1Type = 0;	
	port1Type = JOY_getPortType (PORT_1);	
	intToStr (port1Type, myString, stringSize);
	VDP_drawText(myString, 2, 4);
	switch (port1Type)
	{
		case PORT_TYPE_PAD:
			VDP_drawText("Pad", 2, 2);
			break;
		case PORT_TYPE_MOUSE:
			VDP_drawText("Mouse", 2, 2);
			break;
		case PORT_TYPE_MENACER:
			VDP_drawText("Menacer", 2, 2);
			break;
		case PORT_TYPE_JUSTIFIER:
			VDP_drawText("Justifier", 2, 2);
			break;
		default:
			VDP_drawText("Unknown", 2, 2);
			break;
	}
	
	u8 port2Type = 0;
	port2Type = JOY_getPortType (PORT_2);	
	intToStr (port2Type, myString, stringSize);
	VDP_drawText(myString, 2, 8);
	switch (port2Type)
	{
		case PORT_TYPE_PAD:
			VDP_drawText("Pad", 2, 6);
			break;
		case PORT_TYPE_MOUSE:
			VDP_drawText("Mouse", 2, 6);
			break;
		case PORT_TYPE_MENACER:
			VDP_drawText("Menacer", 2, 6);
			break;
		case PORT_TYPE_JUSTIFIER:
			VDP_drawText("Justifier", 2, 6);
			break;
		default:
			VDP_drawText("Unknown", 2, 6);
			break;
	}

[bioloid]

Ok, going to make another demo using the SGDK, but this time with hardware usage. Since it'll mix planes/sprites & bitmap mode, is there some things to be aware of when switching modes ? (shutdown the screen, PCM music troubles, etc...). Here is a sample to show the incorrect load behavior when sending tiles.[/url]

[Stef]

Ok, going to make another demo using the SGDK, but this time with hardware usage. Since it'll mix planes/sprites & bitmap mode, is there some things to be aware of when switching modes ? (shutdown the screen, PCM music troubles, etc...). Here is a sample to show the incorrect load behavior when sending tiles.[/url]

Honestly i never tried to mix bitmap and planes at same time but it should work as soon you are aware of bitmap limitation mode (one plan is fixed for the bitmap mode). When you done with bitmap mode you have to call BMP_end() to release memory used with bitmap buffers. Also you can use VDP_init() right after so you are sure everything has been reseted correctly.
PCM is annoyed by any DMA transfers so try to keep them low or that will affect the PCM playback quality.
About your tiles loading problem, what method do you use to do the loading ?

[bioloid]

Wow, awesome. thanks! I was sure to read somewhere bitmap mode was using 2 planes, but it was APLANE scrolling maybe, this open doors.
About the DMA hitting PCM, I had read it in another thread, thats why I've doubt about the whole things, I'll go to the low access road as you say. Will need some test (if it creates only noise it may be acceptable).
I'm using VDP_loadBMPTileData & VDP_fillTileMapRectInc just before a "while() VDP_waitDMACompletion();" loop, maybe thing to do is call those once in first loop, or maybe there is some "screen barriers" which may be preferred.

edit: note that I use VDP_load/fill before the

Code: Select all

    SYS_setVIntCallback(vblank);
    SYS_setHIntCallback(hblank);
    VDP_setHIntCounter(1);
    VDP_setHInterrupt(1); 

will need further testing I guess.

[lingh]

Where Genny store constant data i use, for example - describe tile positions in background, in the ram?

Code: Select all

	const u8 zone [11][16] = {
		{86, 86, 86, 86, 86, 86, 86, 4, 4, 86, 86, 86, 86, 86, 86, 86},
		{86, 86, 86, 86, 36, 86, 88, 4, 4, 86, 86, 86, 86, 86, 86, 86},
		{86, 86, 86, 88, 4, 4, 4, 4, 4, 86, 86, 86, 86, 86, 86, 86},
		{86, 86, 88, 4, 4, 4, 4, 4, 4, 86, 86, 86, 86, 86, 86, 86},
		{86, 88, 4, 4, 4, 4, 4, 4, 4, 84, 86, 86, 86, 86, 86, 86},
		{4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4},
		{58, 60, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 58, 58},
		{86, 86, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 86, 86},
		{86, 86, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 86, 86},
		{86, 86, 58, 58, 58, 58, 58, 58, 58, 58, 58, 58, 58, 58, 86, 86},
		{86, 86, 86, 86, 86, 86, 86, 86, 86, 86, 86, 86, 86, 86, 86, 86}
	};

Can you store this data in the rom and read it from it?
Do you need create asm file like this?

Code: Select all

	.align 2
	.globl testData
testData:
	dc.l testData_map
	dc.w 1
	dc.l 2
	
testData_map:
	dc.w 3
	dc.w 4
	dc.w 5

[Stef]

Wow, awesome. thanks! I was sure to read somewhere bitmap mode was using 2 planes, but it was APLANE scrolling maybe, this open doors.

Indeed it uses plan A, in the bmp_cmn.h file you have the following declaration :

Code: Select all

/**
 *      \def BMP_PLAN
 *          Plan used to draw bitmap (plan A).
 */
#define BMP_PLAN                    APLAN

About the DMA hitting PCM, I had read it in another thread, thats why I've doubt about the whole things, I'll go to the low access road as you say. Will need some test (if it creates only noise it may be acceptable).

Yep, you can test it to see how much it impact but as all PCM drivers in SGDK are cycle based timing i guess the impact is quickly visible...

I'm using VDP_loadBMPTileData & VDP_fillTileMapRectInc just before a "while() VDP_waitDMACompletion();" loop, maybe thing to do is call those once in first loop, or maybe there is some "screen barriers" which may be preferred.

Are you loading your tiles severals time to VRAM ??
Also why are you manually waiting for DMA completion ? something you have to know is that any write to VRAM (and so tiles loading operation) are a lot faster when you are in Blank area so if you need to do some VRAM upload at each frame you have to take care of that.
Also bitmap mode is already heavily using the blank area to transfer bitmap buffer to VRAM so you won't have much time left for your own tiles upload.
Bitmap mode is intended to be used this way :
- prepare bitmap buffer during active period
- blit bitmap buffer during blank period

This can be done transparently for you depending the bitmap flags you are using, in this case you only have to prepare buffer and call BMP_flip() when it's done.

edit: note that I use VDP_load/fill before the

Code: Select all

    SYS_setVIntCallback(vblank);
    SYS_setHIntCallback(hblank);
    VDP_setHIntCounter(1);
    VDP_setHInterrupt(1); 

will need further testing I guess.

Again there are some restrictions with bitmap mode, the H interrupt cannot be used anymore as bitmap engine use it to upload tile to VRAM (i do need to use H Interrupt as bitmap mode can extends the blank area).
If you redefine the Hint counter value, bitmap mode won't work anymore :-/

[Stef]

Where Genny store constant data i use, for example - describe tile positions in background, in the ram?

Code: Select all

	const u8 zone [11][16] = {
...	};

By default const data are stored in rom.

[Chilly Willy]

Where Genny store constant data i use, for example - describe tile positions in background, in the ram?

Code: Select all

	const u8 zone [11][16] = {
...	};

By default const data are stored in rom.

And when using assembly files, use

Code: Select all

    .text
/* all data from here goes in rom */

    .data
/* all data from here goes in ram */

[KanedaFr]

little bug on the joy support :
readJoypad return joy state and type
unfortunatly type is also used when it calls joyEventCB
so change is not 0 when released but type << 12 ...
I would prefer to keep the initial mode : 0 for release, button for press

[KanedaFr]

By default const data are stored in rom.

I really need to write somewhere when to use const, static and volatile...
I always forget