Sega Genesis Dev Kit (SGDK)

[Stef]

Can there be ASM stuff in your lib ?

Yeah, i plan to add some later, but only for critical part.
I want to use C when ASM isn't necessary

Anyway you can freely mix your ASM code with the lib.
Just do a 'main' function in ASM then you call C functions as you want.
You just have to repect the C calling convention :
Pushing arguments on the stack
Remove them on the caller side.

[TmEE co.(TM)]

I haven't messed with C (so I didn't understand that 'Main' function) and don't plan to until I finish 12th grade and go to IT college. In my mind ASM is way simpler that other languages (IF the CPU is like 68K).

[Stef]

The main function is just a "main" label for you.
The reason : the sega.s file ends by a "jmp main"

[TmEE co.(TM)]

No I see

[Stef]

New version of the mini devkit available

Some news features and fixes as usual. Most important features added :
- controller change state event system.
- z80 basic sample player driver included.
- z80 2 samples player driver included.

The archive contains 2 examples which demonstrate use of controller event stuff and Z80 drivers

* The basic sample z80 player with variable playback rate need unsigned 8 bits sample.
* Driver which can play 2 samples at same time need signed 8 bits sample at a fixed ~14Khz rate (i can't do better for now :-/). I'm not checking for overflow during the mix (for speed reason) so if you play 2 high volume samples at same time, you can overflow and destroy output sound. Hopefully this happen quite rarely and you can definitly avoid it just by lowerering volume level of yours samples.

Genesis Mini DevKit v0.3
Genesis Particules with 2 wav channels playback (sources & bin)

[MG]

Yop all !

Well, ok for now, i had understood how the screen is made (map plane) and how the sprites are made too (well, not very simple).
I'm using your dev'kit version 0.3 and i had found some mistakes in file vdp_spr.c. (euh, i suppose)
The mistake is on the variable unsigned 16 bits spriteMaxInde and the test in the subroutine VDP_updateSprites().

---- en français :
Dans VDP_SPR.C tu définis
"static u16 spriteMaxIndex;"
mais le pb c'est que par la suite, dans la routine VDP_updateSprites() tu fais un test pour savoir si au moins un élément existe par :
"if (spriteMaxIndex == 0) return;"
Sauf que s'il n'y a qu'un seul sprite dans la liste et bien du coup, il ne s'affiche pas.
Perso j'ai passé la variable en "s16" et comme on travaille sur des éléments de 0 à xxx, le test s'effectue sur -1 pour sortir de la routine.

Sinon j'en suis encore à lié avec le link des sprites de 4 (width) x 5 (height) et je galère pas mal...
Définition de un sprite de 4x4 puis un sprite linké de 4x1 mais bon, c'est pas ça :/

[Fonzie]

Sinon j'en suis encore à lié avec le link des sprites de 4 (width) x 5 (height) et je galère pas mal...
Définition de un sprite de 4x4 puis un sprite linké de 4x1 mais bon, c'est pas ça :/

EDIT : Ho, you want to make bigger sprites than the hardware could do
Yeah, its the trick, just put two sprites in the list ... with a shift of Y by 32pixels and a shift of 16tiles for the second one.
What is wrong with that?

----------------

I think you misunderstood a slight thing about linking...
Link is the way the sprites are linked toguether... the classic link value are (i start from first sprite on the list):
1
2
3
...
80
0 <Last sprite (sprite number 80) links to the first one (apparently, some early md models may hang if the sprite list do not loop).


The link value is byte form and since you cannot write bytes to VRAM, it is associated with sprite size to make a word.
0xSSLL (size, link)

Size are

0

0
1

0
1
2

0
1
2
3

04
1
2
3

04
15
2
3

....

There are also Y,X,Pattern values and the final data for one sprite is :

0xYYYY 0xSSLL 0xPPPP 0xXXXX

0xPPPP is same data construction as plane A & B cells
PriorityPalPalFlipFlipPatPatPatPatPatPatPatPatPatPatPat

You should learn to deal directly with the VDP and VRAM... Once its learned, it is the fastest way, using a function to set a sprite is totaly waste of cpu time

[MG]

Yeap, you've right !
Now i know... arf...

Now, i'm trying to scroll the A plane... éhéh, i'm at the beginning

[Stef]

Yop all !

Well, ok for now, i had understood how the screen is made (map plane) and how the sprites are made too (well, not very simple).
I'm using your dev'kit version 0.3 and i had found some mistakes in file vdp_spr.c. (euh, i suppose)
The mistake is on the variable unsigned 16 bits spriteMaxInde and the test in the subroutine VDP_updateSprites().

---- en français :
Dans VDP_SPR.C tu définis
"static u16 spriteMaxIndex;"
mais le pb c'est que par la suite, dans la routine VDP_updateSprites() tu fais un test pour savoir si au moins un élément existe par :
"if (spriteMaxIndex == 0) return;"
Sauf que s'il n'y a qu'un seul sprite dans la liste et bien du coup, il ne s'affiche pas.
Perso j'ai passé la variable en "s16" et comme on travaille sur des éléments de 0 à xxx, le test s'effectue sur -1 pour sortir de la routine.

Hi !

Thanks for your report, you're right there is *severals* bugs in the code sorry. Actually i wrote it but never tested
I just fixed them (available on the next release) =)

[Stef]

Again a new version of the mini devkit
A lot of bugfixes this time. Thanks to MG, Edge and all others who reported bugs. Also i renamed some functions and filenames (sorry, you'll have to do modifications in your project based on older lib version).

This new version also bring :
- MVS Tracker Z80 driver (thanks MG)
- palette fading functions.
- don't need anymore to initialise the library (the lib is initialised first then your program execute).
- a cool intro logo you can disable in the makefile.gen (need library recompilation) :p

By the way the sonic part of the logo isn't from me, if the author recognize it and don't want to see it here, just contact me

The archive contains 1 sample for a quick overview about how use the lib.

Genesis Mini DevKit v0.4

Bug report are welcome, have fun

[Edge-`]

Sugoi! Thanks Stef, I'll try this out tomorrow.

I encourage anyone else, experienced or not to give the devkit a chance, find bugs, send stef your useful functions / ideas, etc. He is excellent about listening, fixing things, implementing new ideas, and great about communicating. I've really enjoyed it so far, especially some of the control functions. It's nice to have things so organized.

It takes a bit to get use moving from your own libs (in the XGCC and SGCC days it seems everyone wrote their own utility libs ), but once you do it makes it so much easier and clean. After porting to the devkit, you can enjoy updates to the new kit with minimal changes to your code.

[MG]

Yeap, i'm a fan too

Tcks for this update.
------------------------------
Just a little bug report :
in genbase.c, function Gen_init(), a call is made to "YM2612_init();", must be replaced by "YM2612_reset();"

Another thing :
can we modified "sega.s" with all the features explained in another topic in this forum ?
here : http://www.spritesmind.net/_GenDev/foru ... .php?t=122
like all the actions made by the Z80 at the boot.
To have a code more clean an more readable in your future official GenDevKit
In my "sega.s" file, i tried to make the startup code more readable and more flexible with one line for each interrupt.
you can see here : http://blatter.perso.cegetel.net/mdprog/sega.zip

edit: take care :
To have a jump to the initialisation subroutine, you must have "jmp start" at the end of the code and not "jmp main".

nice logo since initialisation


A+

[Fonzie]

Hi,

I personnaly never use any lib (exept for joypad, waitsync...)... From an experience I had with kaneda, jumping to functions (with parametters) really kill the 68K power :/ So i dropped the dev of my FVRlib (heavily copied from kaneda's lib ^^)

I will *donate* the multitap/4wayplay code I have if there is any interest, to support the project (which is great btw)

[Stef]

Sugoi! Thanks Stef, I'll try this out tomorrow.

I encourage anyone else, experienced or not to give the devkit a chance, find bugs, send stef your useful functions / ideas, etc. He is excellent about listening, fixing things, implementing new ideas, and great about communicating. I've really enjoyed it so far, especially some of the control functions. It's nice to have things so organized.

It takes a bit to get use moving from your own libs (in the XGCC and SGCC days it seems everyone wrote their own utility libs ), but once you do it makes it so much easier and clean. After porting to the devkit, you can enjoy updates to the new kit with minimal changes to your code.

Thanks for the very nice comment about the mini dev kit and me
It's a pleasure for me to do it and specially with guys like you
Maybe the mini dev kit will become a real complete sega genesis devkit in sometime.

Yeap, i'm a fan too

Tcks for this update.
------------------------------
Just a little bug report :
in genbase.c, function Gen_init(), a call is made to "YM2612_init();", must be replaced by "YM2612_reset();"

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

Another thing :
can we modified "sega.s" with all the features explained in another topic in this forum ?
here : http://www.spritesmind.net/_GenDev/foru ... .php?t=122
like all the actions made by the Z80 at the boot.
To have a code more clean an more readable in your future official GenDevKit
In my "sega.s" file, i tried to make the startup code more readable and more flexible with one line for each interrupt.
you can see here : http://blatter.perso.cegetel.net/mdprog/sega.zip

In fact i want to minimize as much as possible the "sega.s" task to move them in the C library part. As you probably noticed i already removed the default Z80 driver loading part. Having a more commented, more readable version is interesting tough, i was searching that since sometime now, good to see your

nice logo since initialisation

Thanks i do like a lot the sonic picture
For some reason my timer function (which should display the logo for 3 seconds) doesn't work sometime... i need to test that on real hardware.
Fusion seems to be more sensentive than Gens on that point.

Hi,

I personnaly never use any lib (exept for joypad, waitsync...)... From an experience I had with kaneda, jumping to functions (with parametters) really kill the 68K power :/ So i dropped the dev of my FVRlib (heavily copied from kaneda's lib ^^)

I do agree, i'm very unhappy about how GCC performs the function call stuff, there is no way to optimise them with registers. I recompiled severals version of GCC with the hope of getting something better but no way ! it always pass all parameters from the stack whatever you do... inlining functions also doesn't work and optimisation level > 1 gives generally worst results than O1 :-/
O1 is "correct" but still far from the best we can get with a very good asm code...

Anyway while the speed isn't a problem, the C library is more friendly for genesis deving and already offer some nice possiblities (as my basic 3D rendering )

I will *donate* the multitap/4wayplay code I have if there is any interest, to support the project (which is great btw)

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...

[MG]

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

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