Forums

Hi!
I'm a NDS/GBA homebrewer and I'm interested in exploring the GG :)
I've read some of the many interesting docs you provide on this website, but I failed in finding some information I need. So sorry for bothering you all with simple questions... in case just point me to the documents I should read, it would be much appreciated :)
The main questions are:
- is there some sort of devkit (for Windows if possible) I can download, maybe even including some simple examples to get started?
- is there any chance to code in some HLL or is it absolutely only ASM programming?
- how can I run homebrew on a *real* GG (I've got one home already)?
Thank you very much!

You can probably find a C compiler for the Z80 but it is highly advisable to go full assembly unless you want to make something simple. GBA and DS have nearly infinite power compared to GG and can suck up the overhead of a higher level language...

You need to buy a flashcart, such as the EverDrive GG.

You can take the SMS examples and adjust for GG; it's slightly less well-loved so the details might not be particularly obvious, but basically:
- the palette format is different
- there's a Start button and no Pause button
...and everything else is pretty much the same. (The Gear-to-Gear link is probably the biggest thing I ignored for that list.)

The z88dk is probably the best "HLL" (small-C is pretty low-level really) but I don't think it is very productive for meaningful games. More laid-back things like menus can get away with it - for example, the Everdrive UI is in C with core stuff in assember. I'd recommend going assembler all the way, though :)

Everdrive is your best bet for flashcarts at the moment. With the USB one there's the possibility to send files to it without ejecting the SD card, which can speed up debugging iterations if you like to do them on hardware; I like emulators and breakpoints...

Thanks both for your reply! Good to know there's a C compiler, it's a good way to start coding something easily... I never meant coding something very CPU intensive with it.

As for the EverDrive GG, it might not be the best choice for me... I read the UBS version requires the GameGear attached to it, but I can't easily bring it with me where the PC is. Unscrew the cart and remove the microSD card each time I want to update the contents doesn't seem a feasible idea either. Are there some other carts (or some EverDrive variant) that support an accessible SD/microSD slot? (most GBA/NDS carts are done this way and they're very handy...)

And finally... of course I need an emulator, most of time (I usually run tests on hardware only when everything works fine enough on the emulator). Suggestions? What's the best choice from a developer's perspective?

Thank you!

sverx wrote

of course I need an emulator, most of time (I usually run tests on hardware only when everything works fine enough on the emulator). Suggestions? What's the best choice from a developer's perspective?

meka is a great emulator with nice hacking/debugging features ;)

wow, looks like such a nice tool!
Thank you!

I think there are fewer people familiar with the C side of things. Note that on the Sega 8-bit consoles, most interesting stuff is port-mapped rather than memory-mapped, as you may be used to from NDS/GBA, I think that means you have to do some kind of out(byte) for every video memory write rather than just videomemory[offset] = value.

There's not really any alternative to the Everdrive; except for home-made things where you are pulling out an EPROM and putting it into a programmer, and I think that's not the direction you want to go. The idea is that you make a hole in the cart for removing the uSD, you don't seal it inside :) The USB mode on the Everdrive uses the host system's CPU, so you do need it there and turned on. Surely a Game Gear is reasonably portable?

Meka is generally the best for debugging, some like to try other emulators that better emulate timing edge cases but if you're careful not to write to video memory while the screen is on, you won't have much trouble.

Maxim wrote

Note that on the Sega 8-bit consoles, most interesting stuff is port-mapped rather than memory-mapped, as you may be used to from NDS/GBA, I think that means you have to do some kind of out(byte) for every video memory write rather than just videomemory[offset] = value.

Ok, I'm not such a newbie :) LOL :) [in fact the first asm sources I ever wrote were for the x86, where OUT and IN are very common opcodes for instance when programming the soundblaster or the EGA/VGA]
Thanks for the hint, anyway :)

BTW do you think cutting a hole in the EverDrive would be sufficient to easily pull the microSD? I wonder why they didn't make it so from the beginning...

The Everdrive is just the PCB; you mount it in a donor cart case or buy it with one for a little more money. The SD card is positioned such that it's right next to the surface of the cart, so with a little effort you can cut a hole in the plastic and make the SD card accessible. It does look like you can also enclose it, unlike on the SMS version.

Here's a video showing an example:

For MEKA you want to make sure you are using a build from the 0.8x branch, it has a lot more new debugging tools:
http://www.smspower.org/forums/viewtopic.php?p=75717#75717

Let us know how to experiments are going!

An Everdrive is a nice piece of HW to test full compatibility (and it is just cool play your own projects on the real thing). But my experience is that I do 95% testing on emulator and the other 5% I test on real HW to be sure there are no VRAM update errors (writing too fast).

Meka is a great emulator for debugging and features and bugs are quickly added/fixed (kudos for that!).

Some years ago I started Z80 coding using Hi-tech C but after some time I just switched to ASM as it make things much easier (Coding games with a mapper just gave too much problems).

The hardware and VDP documents from Charles on this site are two documents I use for reference (http://www.smspower.org/Development/Documents).

Thank you all for your advices. Indeed it seems possible to cut away a part of the cart case and make the microSD accessible, as seen in the posted video. Of course this will come only when I'll have something worth testing on a real hardware, and it's not going to happen tomorrow.

About the C or ASM thing... I have to think a bit more about that. I don't want to skip the chance to try coding in C, even if I know I'll also have to write many parts in ASM. But also building ASM functions and call them from C looks like an intriguing idea ;)

Hello again :)
I have pretty much read all the fundamental docs, so I have now some questions on how to start experimenting myself. I see that there isn't a 'ready to use' devkit, so which tools do I need to start coding/compile my stuff? And where I can find some simple sources to use for testing the development cycle? Please point me to some existing documents if there are some I couldn't find... thanks!

edit: beside that, I've read the YM2413 docs and it's almost everything clear to me (because I have read details about the AdLib years ago...) but it says this 'low cost model' has fixed predefined values for 'instruments' 1 to 15. Is there any chance to read these predefined values somewhere and/or have a wave sample of a note played using those? (and should I open a new topic for each question/argument? ;) )

(2nd edit - I should have googled before... actually there are samples here...)

Hi sverx !

I think reading Maxim's How to Program will answer to your first question : http://www.smspower.org/maxim/ (if you aim at programming in ASM) ;)

I'm aiming to learn as much as possible, and I'll probably start with plain ASM since it's what everyone uses, and eventually later I'll explore also the other ways. BTW that link is great and will be of good help, so thanks! :)

Ok, now that I read and understood that I was wondering if there are some common (maybe community built?) defines and/or helper functions that can be used?
Or does everyone make its own from scratch?

The latter, mostly. There's no great consensus on naming conventions or the use of assembler macros (or even which assembler to use) which makes it hard to mix and match things. If you have strong opinions, make your own, else build on something already existing from open source homebrew. There's a limited number of things worth defining, for example (ports, mapper addresses, bitmasks for buttons), and your utility functions may well differ from project to project anyway (e.g. which registers are convenient to use for arguments may vary). Other things (e.g. decompressors) are perhaps a bit more slot-in.

Author	Message
sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	a newbie interested in programming on the GameGear Posted: Thu Sep 05, 2013 9:27 am
	Hi! I'm a NDS/GBA homebrewer and I'm interested in exploring the GG :) I've read some of the many interesting docs you provide on this website, but I failed in finding some information I need. So sorry for bothering you all with simple questions... in case just point me to the documents I should read, it would be much appreciated :) The main questions are: - is there some sort of devkit (for Windows if possible) I can download, maybe even including some simple examples to get started? - is there any chance to code in some HLL or is it absolutely only ASM programming? - how can I run homebrew on a real GG (I've got one home already)? Thank you very much!

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Thu Sep 05, 2013 10:25 am
	You can probably find a C compiler for the Z80 but it is highly advisable to go full assembly unless you want to make something simple. GBA and DS have nearly infinite power compared to GG and can suck up the overhead of a higher level language... You need to buy a flashcart, such as the EverDrive GG.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Thu Sep 05, 2013 11:29 am
	You can take the SMS examples and adjust for GG; it's slightly less well-loved so the details might not be particularly obvious, but basically: - the palette format is different - there's a Start button and no Pause button ...and everything else is pretty much the same. (The Gear-to-Gear link is probably the biggest thing I ignored for that list.) The z88dk is probably the best "HLL" (small-C is pretty low-level really) but I don't think it is very productive for meaningful games. More laid-back things like menus can get away with it - for example, the Everdrive UI is in C with core stuff in assember. I'd recommend going assembler all the way, though :) Everdrive is your best bet for flashcarts at the moment. With the USB one there's the possibility to send files to it without ejecting the SD card, which can speed up debugging iterations if you like to do them on hardware; I like emulators and breakpoints...

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Thu Sep 05, 2013 12:50 pm
	Thanks both for your reply! Good to know there's a C compiler, it's a good way to start coding something easily... I never meant coding something very CPU intensive with it. As for the EverDrive GG, it might not be the best choice for me... I read the UBS version requires the GameGear attached to it, but I can't easily bring it with me where the PC is. Unscrew the cart and remove the microSD card each time I want to update the contents doesn't seem a feasible idea either. Are there some other carts (or some EverDrive variant) that support an accessible SD/microSD slot? (most GBA/NDS carts are done this way and they're very handy...) And finally... of course I need an emulator, most of time (I usually run tests on hardware only when everything works fine enough on the emulator). Suggestions? What's the best choice from a developer's perspective? Thank you!

vingazole Joined: 20 Feb 2008 Posts: 118 Location: Saintes, France	Posted: Thu Sep 05, 2013 1:28 pm
	sverx wrote of course I need an emulator, most of time (I usually run tests on hardware only when everything works fine enough on the emulator). Suggestions? What's the best choice from a developer's perspective? meka is a great emulator with nice hacking/debugging features ;)

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Thu Sep 05, 2013 3:57 pm
	wow, looks like such a nice tool! Thank you!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Thu Sep 05, 2013 3:59 pm
	I think there are fewer people familiar with the C side of things. Note that on the Sega 8-bit consoles, most interesting stuff is port-mapped rather than memory-mapped, as you may be used to from NDS/GBA, I think that means you have to do some kind of out(byte) for every video memory write rather than just videomemory[offset] = value. There's not really any alternative to the Everdrive; except for home-made things where you are pulling out an EPROM and putting it into a programmer, and I think that's not the direction you want to go. The idea is that you make a hole in the cart for removing the uSD, you don't seal it inside :) The USB mode on the Everdrive uses the host system's CPU, so you do need it there and turned on. Surely a Game Gear is reasonably portable? Meka is generally the best for debugging, some like to try other emulators that better emulate timing edge cases but if you're careful not to write to video memory while the screen is on, you won't have much trouble.

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Thu Sep 05, 2013 4:10 pm
	Maxim wrote Note that on the Sega 8-bit consoles, most interesting stuff is port-mapped rather than memory-mapped, as you may be used to from NDS/GBA, I think that means you have to do some kind of out(byte) for every video memory write rather than just videomemory[offset] = value. Ok, I'm not such a newbie :) LOL :) [in fact the first asm sources I ever wrote were for the x86, where OUT and IN are very common opcodes for instance when programming the soundblaster or the EGA/VGA] Thanks for the hint, anyway :) BTW do you think cutting a hole in the EverDrive would be sufficient to easily pull the microSD? I wonder why they didn't make it so from the beginning...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Thu Sep 05, 2013 5:24 pm
	The Everdrive is just the PCB; you mount it in a donor cart case or buy it with one for a little more money. The SD card is positioned such that it's right next to the surface of the cart, so with a little effort you can cut a hole in the plastic and make the SD card accessible. It does look like you can also enclose it, unlike on the SMS version. Here's a video showing an example:

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Thu Sep 05, 2013 5:53 pm
	For MEKA you want to make sure you are using a build from the 0.8x branch, it has a lot more new debugging tools: http://www.smspower.org/forums/viewtopic.php?p=75717#75717 Let us know how to experiments are going!

Zipper Joined: 06 Apr 2011 Posts: 250 Location: Netherlands	Posted: Fri Sep 06, 2013 8:27 am
	An Everdrive is a nice piece of HW to test full compatibility (and it is just cool play your own projects on the real thing). But my experience is that I do 95% testing on emulator and the other 5% I test on real HW to be sure there are no VRAM update errors (writing too fast). Meka is a great emulator for debugging and features and bugs are quickly added/fixed (kudos for that!). Some years ago I started Z80 coding using Hi-tech C but after some time I just switched to ASM as it make things much easier (Coding games with a mapper just gave too much problems). The hardware and VDP documents from Charles on this site are two documents I use for reference (http://www.smspower.org/Development/Documents).

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Fri Sep 06, 2013 12:23 pm
	Thank you all for your advices. Indeed it seems possible to cut away a part of the cart case and make the microSD accessible, as seen in the posted video. Of course this will come only when I'll have something worth testing on a real hardware, and it's not going to happen tomorrow. About the C or ASM thing... I have to think a bit more about that. I don't want to skip the chance to try coding in C, even if I know I'll also have to write many parts in ASM. But also building ASM functions and call them from C looks like an intriguing idea ;)

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Tue Oct 01, 2013 2:12 pm
	Hello again :) I have pretty much read all the fundamental docs, so I have now some questions on how to start experimenting myself. I see that there isn't a 'ready to use' devkit, so which tools do I need to start coding/compile my stuff? And where I can find some simple sources to use for testing the development cycle? Please point me to some existing documents if there are some I couldn't find... thanks! edit: beside that, I've read the YM2413 docs and it's almost everything clear to me (because I have read details about the AdLib years ago...) but it says this 'low cost model' has fixed predefined values for 'instruments' 1 to 15. Is there any chance to read these predefined values somewhere and/or have a wave sample of a note played using those? (and should I open a new topic for each question/argument? ;) ) (2nd edit - I should have googled before... actually there are samples here...)

vingazole Joined: 20 Feb 2008 Posts: 118 Location: Saintes, France	Posted: Tue Oct 01, 2013 4:05 pm
	Hi sverx ! I think reading Maxim's How to Program will answer to your first question : http://www.smspower.org/maxim/ (if you aim at programming in ASM) ;)

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Thu Oct 03, 2013 6:46 am
	I'm aiming to learn as much as possible, and I'll probably start with plain ASM since it's what everyone uses, and eventually later I'll explore also the other ways. BTW that link is great and will be of good help, so thanks! :)

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Fri Oct 04, 2013 12:01 pm
	Ok, now that I read and understood that I was wondering if there are some common (maybe community built?) defines and/or helper functions that can be used? Or does everyone make its own from scratch?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Fri Oct 04, 2013 12:43 pm
	The latter, mostly. There's no great consensus on naming conventions or the use of assembler macros (or even which assembler to use) which makes it hard to mix and match things. If you have strong opinions, make your own, else build on something already existing from open source homebrew. There's a limited number of things worth defining, for example (ports, mapper addresses, bitmasks for buttons), and your utility functions may well differ from project to project anyway (e.g. which registers are convenient to use for arguments may vary). Other things (e.g. decompressors) are perhaps a bit more slot-in.

Forums

View topic - a newbie interested in programming on the GameGear