Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - devkitSMS - develop your homebrew in C

Reply to topic Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
devkitSMS - develop your homebrew in C
Post Posted: Tue Jan 20, 2015 1:28 pm
Last edited by sverx on Tue Dec 20, 2016 1:44 pm; edited 1 time in total
Well, I know it's a very presumptuous name... hopefully it'll mature enough to be worth of it one day...
https://github.com/sverx/devkitSMS
it also includes SMSlib, C library for the Master System.

The lib/devkit makes possible to abstract a bit from the underlying hardware, and you don't have to write your code to:
- set SMS initial status (interrupts/stack/mappers)
- activate Mode 4
- turn on/off video and vblank IRQ
- set color/load palettes
- load tiles/tilemaps
- query the joypad/pause button status
- use sprites

hopefully the readme is clear enough. Let me know if something isn't.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 530
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Tue Jan 20, 2015 9:50 pm
Very nice project!
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Wed Jan 21, 2015 8:31 am
I've been able to compile my first rom (only a background). it's very nice!

But, i'm having some problem with the bool type in SMSLib.h, although i'm using the C99 standard. Maybe is some kind of problem with the SDCC version..
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Jan 21, 2015 8:36 am
did you
#include <stdbool.h>
right?

I'm using SDCC 3.4.0, I never tested older versions. Very old versions probably don't really support bool type, as they wrote in the manual.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Wed Jan 21, 2015 8:38 am
-_-'

I think i need not to program late at night :-P

I'm sure that this is, i'll try later at home!
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 567
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Wed Jan 21, 2015 8:57 am
This is a great initiative, sverx! I'll look forward to be following your work on this devkit.

Personally I never really learned C. I did a lot of BASIC back then, and recently some assembler for the SMS. This library might be my way into C :)
  View user's profile Send private message Visit poster's website
  • Joined: 09 Jan 2012
  • Posts: 55
  • Location: Germany
Reply with quote
Post Posted: Wed Jan 21, 2015 9:13 am
This bool thing is also in 3.4 a problem.

Why is crt0 under gpl? That makes all programs free.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 530
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Wed Jan 21, 2015 9:45 am
dark wrote
This bool thing is also in 3.4 a problem.

Why is crt0 under gpl? That makes all programs free.

Well, you'd never become rich by writing SMS homebrew, anyway... ;)
  View user's profile Send private message Visit poster's website
  • Joined: 09 Jan 2012
  • Posts: 55
  • Location: Germany
Reply with quote
Post Posted: Wed Jan 21, 2015 9:53 am
Maybe i'm already rich ;)
I have no problem to open my source code. But when i post here a program i also have to publish the source. And story and concept of a game isn't a thing which i want to publish. I don't need a porn version from everything.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Jan 21, 2015 10:07 am
dark wrote
Why is crt0 under gpl? That makes all programs free.


Right, I forgot to mention to read the "special exception" present in crt0.s:
Quote
; As a special exception, if you link this library with other files,
; some of which are compiled with SDCC, to produce an executable,
; this library does not by itself cause the resulting executable to
; be covered by the GNU General Public License.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Jan 21, 2015 10:17 am
hang-on wrote
Personally I never really learned C.


It's just fun :)
  View user's profile Send private message Visit poster's website
  • Joined: 26 Jan 2014
  • Posts: 476
Reply with quote
Post Posted: Wed Jan 21, 2015 12:05 pm
dark wrote
Maybe i'm already rich ;)
I have no problem to open my source code. But when i post here a program i also have to publish the source. And story and concept of a game isn't a thing which i want to publish. I don't need a porn version from everything.


Too bad, Master System Porn is pretty cool.


Nice one sverx ;) Is that a similar devkit that the one Vingazole & Ichigo are working on?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Jan 21, 2015 12:22 pm
Revo wrote
Is that a similar devkit that the one Vingazole & Ichigo are working on?


Similar, yes. I mean I had the fortune (thank you guys!) to see their work in progress few days ago... but it's always been in my plans to use only SDCC, while they're mixing it with WLA-DX.
Of course I don't see anything wrong with that, it's just I'm taking a different approach.

Now if anyone knows if there's already a program that can turn a group of binary files (tiles, tilemaps, PSGs, sound effects...) into a single C file (with its own .h file too) containing arrays, that would be handy for including resources easily. If such a program still doesn't exists, I will write it myself. (my plans are to generate the bank#.c and bank#.h file 'automatically' from the contents of a folder, so that moving contents around ROM would just require a cut-and-paste of the corresponding binary file...)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Wed Jan 21, 2015 12:58 pm
sverx, we are using our own software to generate .h files for our Megadrive developments.

It's not public because it's still buggy as hell, but i may improve it with master system capabilities
811131615_148781.jpg (48.98 KB)
811131615_148781.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Jan 21, 2015 1:14 pm
that's nice indeed, but I need a tool to handle files generated by BMP2Tile (as compressed tiles, compressed tilemaps, palettes... etc) as well as other files as PSG, PSGc, other 'generic' binary data.

I first thought about writing some plugins for BMP2Tile to generate C files but that would require a bigger effort and solve only a part of my problems.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Thu Jan 22, 2015 10:57 am
Last edited by sverx on Fri Jan 23, 2015 12:33 pm; edited 2 times in total
Here's a little demo (with sources) of devkitSMS / SMSlib.
I took a dithered and 448-tiles reduced image from haroldoop's RgbQuant-SMS (great work man! :D ) and I created tileset/tilemap/palette with BMP2Tile, all 3 files are in uncompressed binary format.
Then, using folder2c, which is now part of devkitSMS, I turned the 3 binary file into a single C file, along with its header file which I included in my main program.
The program loads the data into VRAM and then generates a b/w version of the palette. It then sets a line interrupt handler to switch the palette from color to b/w midframe. Using up/down you can move the line on which the line interrupt happens. Pressing pause 'resets' it to line 90.
Full source included. I hope you enjoy! :)

(attachment removed)
line_irq_test-01.png (21.52 KB)
screenshot
line_irq_test-01.png

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12790
  • Location: London
Reply with quote
Post Posted: Thu Jan 22, 2015 3:02 pm
I guess you are not handling the complexity of line interrupt repeats? Does the line interrupt palette write go slowly enough to work on real hardware? If the framework could let you specify the lines you want interrupts on, and the callback for each line, that would be awesome but I guess the overhead would be quite high.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Thu Jan 22, 2015 3:58 pm
I still didn't run any test on hardware, everything it's such at a 'draft' level...
About having a list of lines on which you want line interrupt triggered... well, there's surely a lot of overhead. But you might achieve a simpler version of this by changing the callback function and setting next line interrupt line in the callback function itself. That might work :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Thu Jan 22, 2015 8:24 pm
Amazingly, works on hardware too (Master Everdrive on my SMS II), but the curious pattern made by the snow effect made me realize I didn't understand correctly how line interrupt works.
In short: if you set the line counter (VDP register $A) to some value, say 5, the IRQ will get fired at line 5 and then again after 5 lines and so on...
Which also means that my example needs a fix.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12790
  • Location: London
Reply with quote
Post Posted: Thu Jan 22, 2015 8:47 pm
Plus, the line counter is reloaded before your interrupt is called. It's really tricky to get line interrupts on a given line without burning too much CPU, more so if you want more than one. Maybe you can disable line interrupts at the start of your line interrupt - hopefully before the next one is triggered for n=1 - and enable them in the VBlank? The snow is hard to avoid, and I think you can even fail to update all the colours if you write too fast.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 530
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Thu Jan 22, 2015 10:15 pm
It looks pretty nice. Keep up the good work! ;)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Thu Jan 22, 2015 10:24 pm
All the pipeline is quite nice now :-)
1985Alternativo.zip (2.56 KB)

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Thu Jan 22, 2015 10:39 pm
@Maxim: I think another possible workaround is to update the counter value and change the function that will gets called when the (old) counter will underflow again. And I believe it's impossible to avoid the snow, but if you know how, let me know :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12790
  • Location: London
Reply with quote
Post Posted: Thu Jan 22, 2015 11:09 pm
We had a load of discussion a while back, basically you can't update 16 colours on one scanline at all and if you carefully made all the palette writes offscreen, it would take six scanlines to do them all. Raster palette FX means either only a few colours, or you need to mask the snow somehow.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Fri Jan 23, 2015 8:41 am
Yes, I remember that discussion, but we never discussed on how to make sure the CRAM update would happen horizontally off-screen.

@kusfo: verticall scroll wraps at 224 (when in 192 lines mode) so you should account for that :)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Fri Jan 23, 2015 8:54 am
Yeah, i notice but it was only a quick and dirty test :-P

But it's very nice to using BMP2tile+folder2c in a really easy way
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12790
  • Location: London
Reply with quote
Post Posted: Fri Jan 23, 2015 9:18 am
To get palette changes off screen, you need to only change three and burn CPU just the to right amount to time it. Games using palette line effects (Space Harrier for example) do this.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Fri Jan 23, 2015 9:36 am
Does that 3 colors change happen during left off-screen (I mean right when line irq handler start) or during right offscreen (after the whole line has passed)?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Fri Jan 23, 2015 9:38 am
kusfo wrote
Yeah, i notice but it was only a quick and dirty test :-P


:)

as for folder2c, I think I already have something to fix. For instance I think it's stupid to allocate two bytes in ROM for the lenght of the data when I could just use a #define, which will also perform better when using it in an immediate operation such as my_data_bin_len/32 for instance.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Fri Jan 23, 2015 12:35 pm
new version, better line irq handling and b/w conversion.
line_irq_test.zip (287.01 KB)
ROM and source code

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Fri Jan 23, 2015 8:42 pm
I realized it's unoptimal to have LoadTiles and LoadTilemap 'len' parameter count tiles and tilemap entries, so I'll soon change that to 'size' to indicate that you'll have to specify how many bytes you're going to load, instead of tiles (bytes/32) or tilemap entries (bytes/2).
Thus also the #defines which are into folder2c created .h files will be called <data_array_name>_size instead of _len.
Hopefully nobody has already written hundreds of lines of code :)

edit: I forgot to mention that I'll probably add more features to the library based on your requests so if you already feel the need to ask for some specific function/feature let me know.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Sun Jan 25, 2015 10:38 am
I was wondering if you're planing to include PSGlib in the devkit. It'll be extremely useful! :-D
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Sun Jan 25, 2015 1:43 pm
I'm still undecided about writing a wrapper around current (asm) PSGlib or to create a new PSGlib in C, eventually giving it more features. One way or another, there will be PSG support of course.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Dec 2013
  • Posts: 334
  • Location: Canada
Reply with quote
Post Posted: Sun Jan 25, 2015 7:15 pm
sverx wrote
I'm still undecided about writing a wrapper around current (asm) PSGlib or to create a new PSGlib in C, eventually giving it more features. One way or another, there will be PSG support of course.


Some love for the YM2413 as well?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Mon Jan 26, 2015 9:40 am
db-electronics wrote
Some love for the YM2413 as well?

I didn't plan that :|
But everybody can contribute, of course! :)

I fixed that len/size thing. Now each time a 'size' parameter is required, you should specify the size in bytes, not in elements (tiles/tilemap entry/etc). folder2c also now creates #defines <data_array_name>_size instead of <data_array_name>_len (and also prints how many bytes are in total defined by the generated .c file. Useful for checking that total size is correct and eventually <=16KB)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Tue Jan 27, 2015 9:23 am
SEGA and SDSC ROM headers are now supported too :) (checksum will be calculated and fixed automatically by the ihx2sms utility)

Anyway I was wondering if that 'product code' and 'version' (revision) included in the SEGA ROM are really somewhat important...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12790
  • Location: London
Reply with quote
Post Posted: Tue Jan 27, 2015 10:04 am
They're not important at all, I never set them.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Tue Jan 27, 2015 12:29 pm
I see. Well, I won't remove that now ;)
Let's set homebrew to product 9999 :D
SMS_EMBED_SEGA_ROM_HEADER(9999,0);
/*
SMS_EMBED_SEGA_ROM_HEADER(productCode,revision);
productCode = 0 to 9999
revision = 0 to 15
*/
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 12790
  • Location: London
Reply with quote
Post Posted: Tue Jan 27, 2015 10:11 pm
Product can go up to 159999... You should make a parameterless overload which sets them to zero.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Tue Jan 27, 2015 10:23 pm
Maxim wrote
Product can go up to 159999

I know, but SDCC seems it still doesn't like long constants.

edit: Ooops, no, I was wrong. It was me doing stupid things. Now values up to 159999 are accepted :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Feb 18, 2015 9:50 am
I hope some of you is already enjoying this :)
I just wanted you to know to avoid using SDCC --fomit-frame-pointer switch when compiling since it's still not 100% working. It gave me a bad half-an-hour headache and I want you to avoid that.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Wed Feb 18, 2015 9:52 am
Already doing something with devkit....

Are you already working in sprite positioning? maybe i can contribute...
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Feb 18, 2015 10:28 am
kusfo wrote
Are you already working in sprite positioning?


Not yet, apart from the basic -still mostly untested- functions:
void SMS_initSprites (void);     /* we're going to start declaring sprites, in front-to-back order */
bool SMS_addSprite (unsigned char x, int y, unsigned char tile); /* declare a sprite - returns false if no more sprites are available */
void SMS_finalizeSprites (void);      /* we're done declaring sprites */
void SMS_copySpritestoSAT (void);     /* copy sprites to Sprites Attribute Table (do that during vBlank) */


I had plans to support sprite windowing (define a window on screen and do not draw any sprite which falls [partially?/completely?] outside of it) but I still didn't work on that. Instead, I'll soon -hopefully- work on sprite 'freezing', which will be useful for the (secret) project I'm working on since few days... :D
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Fri Feb 20, 2015 2:50 pm
I promised this quite a long ago... PSGlib is available now also as part of devkitSMS. It's a part wrapper and a part a small rewrite, works the same way the original version.
Attached there's a quick demo-test, using the very same assets of the original demo. Source included.
PSGlib_test.zip (130.51 KB)
devkitSMS/PSGlib demo with sources

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Mon Feb 23, 2015 9:49 am
MD pad supported, now :)

Additional keys are read using separate functions:
#ifdef MD_PAD_SUPPORT
/* functions to read additional MD buttons */
unsigned int SMS_getMDKeysStatus (void);
unsigned int SMS_getMDKeysPressed (void);
unsigned int SMS_getMDKeysHeld (void);
unsigned int SMS_getMDKeysReleased (void);

/* handy defines for additional MD joypad(s) handling */
#define PORT_A_MD_KEY_Z         0x0001
#define PORT_A_MD_KEY_Y         0x0002
#define PORT_A_MD_KEY_X         0x0004
#define PORT_A_MD_KEY_MODE      0x0008
#define PORT_A_MD_KEY_A         0x0010
#define PORT_A_MD_KEY_START     0x0020
/* port B still missing */
#endif


if you don't plan to use these additional features, recompile the library commenting/removing the
#define MD_PAD_SUPPORT

line on top of SMSlib.h

attached there's a small demo, with sources.
On my PAL SMS II everything works correctly, hopefully it'll work on any other hardware configuration too. If you happen to test the demo, please let me know.
controllers-emulicious.png (6.64 KB)
Emulicious screenshot of the demo
controllers-emulicious.png
controllers.zip (111.1 KB)
Demo w/ sources

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Thu Feb 26, 2015 2:55 pm
devkitSMS/PSGlib updated : PSGInit() removed, as it became useless

@kusfo: already using this too? :)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Thu Feb 26, 2015 3:15 pm
i have to try PSG yet, but i've a psg song ready for the test :-D
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Wed Mar 04, 2015 7:01 pm
kusfo wrote
Are you already working in sprite positioning?


Function to place a sprite only if it's not completely out of a user defined clipping window added to devkitSMS/SMSlib. It's currently supporting 8x8 sprites only.
To make the function clip even those sprites that would be just partially out of the defined window just define a smaller window ;)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 479
  • Location: Spain
Reply with quote
Post Posted: Sun Mar 15, 2015 11:42 pm
is it possible that now is compulsory to define a clipping window for sprites? Since updating the library, now no sprite is shown in my little demo....
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2425
Reply with quote
Post Posted: Mon Mar 16, 2015 8:55 am
There's no clipping performed if you use
SMS_addSprite (unsigned char x, unsigned char y, unsigned char tile)

just note that I changed it to accept unsigned char parameters.
(also, if you set some sprite at Y=0xD1, you'll actually stop displaying next sprites... this is something I still have to somehow address)
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next



Back to the top of this page

Back to SMS Power!