Sega Genesis Dev Kit (SGDK)

[Stef]

YM2612_Init() isn't anymore called in this version as far i remember

Arf... hum... it's in an older file :/

Hehe no problems as you saw, many minors fixes and changes

[Fonzie]

There is ! by the way, how you figured this code ? where did you got the documentations ? In gens, my only way to implement multipad support was reverse engineering from 4-players game...

Héhé, its a long story

I had a .txt documentation, so i coded a SegaMultitap code (which wasn't working exept in some rare cases, as usual LOL).
Then MaskOfDestiny fully coded a SegaMultitap with the help of the segasaturn manual & reverse engenering of the hardware.
It was ultraslow because it was using the "periferial-per-periferial-directory-mode" of the sega multitap.
Then Steve Snake (he knows everything, you don't remember?) helped me a lot to do the EA4Wayplay code.
The segamultitap model2 (with two wires) is also compatible.
This mode is very fast to use, very easy to understand (it use one wire to select the joypad, and the other wire to read it, as usual ^^)...


I'm gonna email you the files soon.

[Stef]

There is ! by the way, how you figured this code ? where did you got the documentations ? In gens, my only way to implement multipad support was reverse engineering from 4-players game...

Héhé, its a long story

I had a .txt documentation, so i coded a SegaMultitap code (which wasn't working exept in some rare cases, as usual LOL).
Then MaskOfDestiny fully coded a SegaMultitap with the help of the segasaturn manual & reverse engenering of the hardware.
It was ultraslow because it was using the "periferial-per-periferial-directory-mode" of the sega multitap.
Then Steve Snake (he knows everything, you don't remember?) helped me a lot to do the EA4Wayplay code.
The segamultitap model2 (with two wires) is also compatible.
This mode is very fast to use, very easy to understand (it use one wire to select the joypad, and the other wire to read it, as usual ^^)...


I'm gonna email you the files soon.

Glad to hear you have an efficient code for that Thanks for sharing it !
Steve Snake maybe got some "authentics" documents about how use these multipad (NBAJam ?).
On my side, i fixed the timer bug as expected it was due to this insane VCounter rollback at end of frame...

[Mask of Destiny]

There is ! by the way, how you figured this code ? where did you got the documentations ? In gens, my only way to implement multipad support was reverse engineering from 4-players game...

Héhé, its a long story

I had a .txt documentation, so i coded a SegaMultitap code (which wasn't working exept in some rare cases, as usual LOL).
Then MaskOfDestiny fully coded a SegaMultitap with the help of the segasaturn manual & reverse engenering of the hardware.
It was ultraslow because it was using the "periferial-per-periferial-directory-mode" of the sega multitap.
Then Steve Snake (he knows everything, you don't remember?) helped me a lot to do the EA4Wayplay code.
The segamultitap model2 (with two wires) is also compatible.
This mode is very fast to use, very easy to understand (it use one wire to select the joypad, and the other wire to read it, as usual ^^)...


I'm gonna email you the files soon.

Glad to hear you have an efficient code for that Thanks for sharing it !

I think the code I wrote for the Sega protocol (which is compatible with both versions of the Sega multi-tap, but not the EA one) could be made reasonably fast. Part of the problem with the code I wrote is that I ran into a bug in the build of GCC I was using. I ended up sticking in a lot of debugging code and extra nops trying to figure out why my code was broken only to find the compiler was broken. I never cleaned out the extra nops and didn't have time to optimize the code. Given enough time I'm sure I could get it running reasonably, but at the time I was having trouble making time for Sega coding and Fonzie was understandably eager to get MMM finished (I had already delayed things quite a bit by taking an incredibly long time to fix some bugs in my CD library).

I was surprised at the amount of info on the Genesis peripherals in the official Saturn docs. It has info on everything from the standard 3-button to the Mega Mouse and Sega multi-tap. Makes you wonder if Sega was planning an adatper to let you use Genesis peripherals on the Saturn at one point. The only reason I resorted to reverse engineering is that the documentation wasn't entirely clear in a couple of places.

[Stef]

Héhé, its a long story

I had a .txt documentation, so i coded a SegaMultitap code (which wasn't working exept in some rare cases, as usual LOL).
Then MaskOfDestiny fully coded a SegaMultitap with the help of the segasaturn manual & reverse engenering of the hardware.
It was ultraslow because it was using the "periferial-per-periferial-directory-mode" of the sega multitap.
Then Steve Snake (he knows everything, you don't remember?) helped me a lot to do the EA4Wayplay code.
The segamultitap model2 (with two wires) is also compatible.
This mode is very fast to use, very easy to understand (it use one wire to select the joypad, and the other wire to read it, as usual ^^)...


I'm gonna email you the files soon.

Glad to hear you have an efficient code for that Thanks for sharing it !

I think the code I wrote for the Sega protocol (which is compatible with both versions of the Sega multi-tap, but not the EA one) could be made reasonably fast. Part of the problem with the code I wrote is that I ran into a bug in the build of GCC I was using. I ended up sticking in a lot of debugging code and extra nops trying to figure out why my code was broken only to find the compiler was broken. I never cleaned out the extra nops and didn't have time to optimize the code. Given enough time I'm sure I could get it running reasonably, but at the time I was having trouble making time for Sega coding and Fonzie was understandably eager to get MMM finished (I had already delayed things quite a bit by taking an incredibly long time to fix some bugs in my CD library).

I was surprised at the amount of info on the Genesis peripherals in the official Saturn docs. It has info on everything from the standard 3-button to the Mega Mouse and Sega multi-tap. Makes you wonder if Sega was planning an adatper to let you use Genesis peripherals on the Saturn at one point. The only reason I resorted to reverse engineering is that the documentation wasn't entirely clear in a couple of places.

Well, it's a shame, i searched for age these documents and they were available for saturn devers

[MG]

Yop !

Kaneda had made a very good work on FM/PSG/DAC player (3 in one, éh éh )
I want to submit my contribution to the convertion of this work into the "GenDevKit"...

Here are the libraries :
http://blatter.perso.cegetel.net/mdprog/lib_include.zip
An example (with sources/ressources included and an adaptation of Kaneda script for Mappy to respect the syntax with the compiler...
Always war between ";" and "*" from comment in assembler files) :
http://blatter.perso.cegetel.net/mdprog/zic.zip

A+

[KanedaFr]

so, as we said in MVSTracker post, your PSG comment is wrong because of me....sorry

and for "war" between ";", "*" and "|"...it's why I use maccerX *
I added GCC support when I switched from SGCC to XGCC...I didn't want to rewrite all my asm files!
I so keep my asm file with the comment format I want but compile to any compiler !
you really should try it and/or include it in your compiling process like I do.
I never got feedback on Maccer so if there is something wrong with it, contact me

[MG]

At the beginning i'll try to use maccer without success...
but at the beginning, there are lot of things to learn...
in future, i'll try again.

[KanedaFr]

I first used it for binary include then I was happy to convert my old asm files!

[MG]

Yes, a good tool too.
Easy for use and translation seems good, well another tool to have !

tcks again

[MG]

Yop !

Little bug in "PSG.C" :

Example :

Code: Select all

void PSG_init()
{
    volatile u8 *pb;
    u16 i;
    pb = (u8*) PSG_PORT;
    for (i = 0; i < 4; i++)
    {
        // set tone to 0
        *pb = 0x80 | (i << 6) | 0x00;
        *pb = 0x00;
        // set envelope to silent
        *pb = 0x90 | (i << 6) | 0x0F;
    }
}

good is :

Code: Select all

void PSG_init()
{
    volatile u8 *pb;
    u16 i;
    pb = (u8*) PSG_PORT;
    for (i = 0; i < 4; i++)
    {
        // set tone to 0

        *pb = 0x80 | (i << 5) | 0x00;

        *pb = 0x00;
        // set envelope to silent

        *pb = 0x90 | (i << 5) | 0x0F;
    }
}

All the lines with "(i << 6)" must be replaced by "(i << 5)".

Edit :
Another thing, to code volume :
(in PSG_setEnvelope(u8 channel, u8 value))
You have :

Code: Select all

*pb = 0x90 | ((channel & 3) << 5) | (value & 0xF);

But in fact, may be that is better for comprehensive code :

Code: Select all

*pb = 0x90 | ((channel & 3) << 5) | ((0xf-value) & 0xF);

because max volume = 0x0 and min volume = 0xf.

Have fun !
Explanation of the PSG here :
http://www.smspower.org/dev/docs/sound/ ... 030421.txt
(Bah, you have already, i suppose).

A+

[Stef]

Yop !

Little bug in "PSG.C" :

...

Have fun !
Explanation of the PSG here :
http://www.smspower.org/dev/docs/sound/ ... 030421.txt
(Bah, you have already, i suppose).

A+

As asual, thanks for your bug report ! A stupid bug afaik :p
By the way, for the envelop function, i assume it's normal to set it in this way, we often see that on sound chip (0 = max volume) and i guess sound programmer are aware of that typo

[MG]

I follow the movement, it's ok for me

[Stef]

Code::Blocks IDE integration moved to the first page

[ElBarto]

Sweet.
I've started a template for visual studio 2005, will post it when it's finish.