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 - SMS devkit

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
SMS devkit
Post Posted: Fri Jun 20, 2014 12:01 pm
[Admin: split from Support to create a new SMS game!]

I don't want to derail this topic too much, but I feel I have to add that SMS development is lacking some sort of devkit, everyone has to develop almost everything from ground up. I personally find this interesting, but I'm sure most of people would not bother, and we hardly see more than a handful of projects a year.
I wrote PSGlib, and maybe someone else will use it in their homebrew, but I also think that maybe the community should write wrappers to make common tasks very easy (I think of loading assets in VRAM, managing sprites and background tilemap) so that even beginners could easily start nice little projects their own.
But maybe I'm dreaming thinking that what was available when I was writing homebrew on GBA/NDS would ever be available here too... let's see what that C compiler project brings...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8507
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jun 20, 2014 12:24 pm
Yes in theory - everybody would agree with the theory, but you can't force it to happen. What you can do is lead your own initiative, make something (e.g. PSGLib), share it and evangelize its adoption.

Sega 8-bit programming is lower level than GBA/NDS because of simplicity and also general akwardness and lack of CPU resources. It makes it harder to share bits of code because every game/engine needs something different. As one gets toward making a non-trivial scrolling game with collisions, characters, etc, your storage and code will be very custom and appropriate the game design. Also one need to understand more of the hardware to do something non-trivial (as which point the simplier helpers aka "loading assets to VRAM" are of less use).

But yes one could come up with "generic scrolling platforming engine" and that could be super useful and get adopted (it would be nice) and be a platform for people to hack more. Until then what we have are a lot of useful code and tools scattered around and one could argue we could organise ourselves better to share and promote them. I mean we had people here publish competent map editors, compression routines, etc.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8507
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jun 20, 2014 12:30 pm
Anyway the bottom line is: let's just all continue to make stuff. The situation has been vastly improving in the past few years, we got more library, more tools, more competent people, better debuggers, etc.

Quote
"I also think that maybe the community should write wrappers"

You are the community :)
But remember writing code is a half of the battle, having people use it and jam on it and make things on it is the harder half that's more often ignored.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Fri Jun 20, 2014 1:11 pm
Bock wrote
You are the community :)

I know, and I think I will share more stuff, for other to enjoy/use/improve :)
  View user's profile Send private message Visit poster's website
  • Joined: 08 Oct 2012
  • Posts: 108
  • Location: Colmar PA, United States
Reply with quote
Post Posted: Sat Jun 21, 2014 9:57 am
Even for the popular older systems (Nin***cough***do) sales of new games tend to be low. After talking to other developers at conventions and from my own personal experience, I found that homebrew games tend to sell between 50 to 200 copies. Companies, even small ones, that make games for older systems are really rare. Sadly, I'd say maybe half of the people who buy homebrew games don't even play them. Some just keep them on the shelf as a collector's item. Some even put the game up on e-bay days later to make money on the resale.

Size and popularity do not matter. But if you want to get more people interested in games for older systems, and you aren't a programmer, maybe you could organize a get-together or game-swap in your local area. Video game conventions seem to be pretty popular in the US. I'm not sure how they would work in other countries.
  View user's profile Send private message
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Sat Jun 21, 2014 2:37 pm
sverx wrote
I don't want to derail this topic too much, but I feel I have to add that SMS development is lacking some sort of devkit, everyone has to develop almost everything from ground up.

All my yes.
  View user's profile Send private message
  • Joined: 21 Aug 2012
  • Posts: 357
  • Location: Berlin, Germany
Reply with quote
Post Posted: Sun Jun 22, 2014 9:22 am
lol now this topic gets some posts, after I cancelled my little project xD
But at least, it was useful for one or two people.;)
  View user's profile Send private message Visit poster's website
  • Joined: 08 Oct 2012
  • Posts: 108
  • Location: Colmar PA, United States
Reply with quote
Post Posted: Sun Jun 22, 2014 10:41 am
homsar47 wrote
sverx wrote
I don't want to derail this topic too much, but I feel I have to add that SMS development is lacking some sort of devkit, everyone has to develop almost everything from ground up.

All my yes.


I find that bmp2tile, meka (awesome for debug) and the wla-z80 assembler are plenty to make games. That's your devkit right there. Well, if you don't mind writing games in Z80 assembler. :)

I prefer writing in assembly language to C or any higher level language. C just doesn't always do what I expect it to do. But, I'm probably just weird.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Sun Jun 22, 2014 2:16 pm
There could be some more helpful tools but they would soon become restrictive. A generalised metatile scrolling engine might be nice, but hard to genericise. Maybe some libraries for maths, collision detection, and a sprite engine that could do flickering and screen entry for any size sprite. All of these may end up being specific to a particular way of doing things and hard to mix in to other code, though.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 760
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Jun 22, 2014 10:08 pm
One possibility would be to do something like Batari Basic does, that is, to have multiple 'kernels' with different sets of advantages and limitations, and let the programmer choose which one best fits the desired game style.

Another option would be to do something similar to Jonathan Cauldwell's
Arcade Game Designer, Platform Game Designer and S.E.U.D., that is, to make a simple-to-use, single-purpose tool designed to do a single type of game. Even with the limitations, there's still a lot that can be done with just that.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Mon Jun 23, 2014 6:28 am
Certainly, a <genre> construction kit type generator would work well, but that's not very common on even the most popular platforms...
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 331
Reply with quote
Post Posted: Mon Jun 23, 2014 6:55 am
Somewhat related.

I have been working on a side project. It is many things, one of which I have labeled assembly++.

It has similarities WLA DX macros except the idea is to have portable libraries and code snippets.

I hacked a primitive prototype of the idea using a java library called casper. It allows you to insert javascript statements in to text. We can pass it values to which can be inserted and or operated on. All basic programming structures supported (for, if / else, while, etc).

This is an example from caspers website.

Hello <% if(name =="vivek" ) { %> handsome <% } else { %> beautiful  <% } %> ${name}


output: Hello handsome vivek

I originally came up with the idea to consolidate component management code in to single statements. For example with the VDP i could write...

.initialisevdp lines = "240", vInterupts = true


It has kind of grown way beyond that though. It is a very powerful tool allowing us to write logic independent of data specifics (what data, where is it, how big is it, etc). The user gives the specifics and away we go.

A++ can appear in your code in two different ways.

- An a++ command can appear multiple times in code. The processed code is injected each time (may be different from instance to instance depending on user variables).

- An a++ command could refer to something more complex like a decompression algorithm. You only want this to exist once in your code. You would wrap the algorithm behind a section and when you need to use it call the section.

The value of a++ is linked to your programming methodology. It works with mine well, for others it will be more trouble than its worth or they will have their own solution.

I originally built it in to a crude assembler i wrote. I am looking to shift it in to a self contained module so that compilation would be something like [code] > [a++ injection] > [compiler] > [rom].

Curious to see peoples thoughts. Not sure the solution is as solid as it could be.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Mon Jun 23, 2014 9:04 am
dragonfeet wrote
I find that bmp2tile, meka (awesome for debug) and the wla-z80 assembler are plenty to make games. That's your devkit right there.


You're right, I've not been precise enough. I really meant that a collection of basic "functions" would be very handy for beginners. From that point on, everyone can evolve its own specific work, if needed.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 760
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Jun 23, 2014 9:48 pm
sverx wrote

You're right, I've not been precise enough. I really meant that a collection of basic "functions" would be very handy for beginners. From that point on, everyone can evolve its own specific work, if needed.


Well, most code you'd need is already out there, on this sites' development and homebrew sections, though it's spread over multiple examples and sources. In order to make it less difficult for beginners, I guess it would simply(?) be a matter of copy-pasting all the useful parts together into a library, cleaning up and documenting everything, and maybe creating some simple tutorial, plus a few example games.

Maybe it could become even easier for beginners if everything was made accessible trough a higher level language, like C, for example; if the toolset could become as streamlined as GBDK or SGDK, then so much better. My old z88dk adaptation was easy to use, but didn't quite reach the level of those two.

I believe making something comparable to GBDK would be a more realistic goal.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Mon Jun 23, 2014 11:10 pm
sverx wrote
dragonfeet wrote
I find that bmp2tile, meka (awesome for debug) and the wla-z80 assembler are plenty to make games. That's your devkit right there.


You're right, I've not been precise enough. I really meant that a collection of basic "functions" would be very handy for beginners. From that point on, everyone can evolve its own specific work, if needed.

What might be helpful is a few organized examples to cover the basics. Y'know, sound, sprites, VDP, basic code snippets (obviously and most importantly :P,) all of that. The homebrew section has plenty of code, but most of it seems to be scrambled and hard to make your way through to find anything useful.
  View user's profile Send private message
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Mon Jun 23, 2014 11:14 pm
haroldoop wrote
sverx wrote

You're right, I've not been precise enough. I really meant that a collection of basic "functions" would be very handy for beginners. From that point on, everyone can evolve its own specific work, if needed.


Well, most code you'd need is already out there, on this sites' development and homebrew sections, though it's spread over multiple examples and sources. In order to make it less difficult for beginners, I guess it would simply(?) be a matter of copy-pasting all the useful parts together into a library, cleaning up and documenting everything, and maybe creating some simple tutorial, plus a few example games.

Maybe it could become even easier for beginners if everything was made accessible trough a higher level language, like C, for example; if the toolset could become as streamlined as GBDK or SGDK, then so much better. My old z88dk adaptation was easy to use, but didn't quite reach the level of those two.

I believe making something comparable to GBDK would be a more realistic goal.

This might be somewhat random, but what's the fun in using C for such old game systems? Yes, C may be easier, but clearly ASM has more resources for Sega consoles in specific. That, and few actually use C right now on this forum. (I may be wrong, not sure).
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 760
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Jun 23, 2014 11:51 pm
homsar47 wrote

This might be somewhat random, but what's the fun in using C for such old game systems? Yes, C may be easier, but clearly ASM has more resources for Sega consoles in specific. That, and few actually use C right now on this forum. (I may be wrong, not sure).


That's mostly a question of individual preference; even by using C, one would still have to creatively work around the system's constraints; it would all boil down to what kinds of challenge one prefers to tackle.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Tue Jun 24, 2014 7:29 am
There's a code snippets section in the development section here, which anyone can add to. While it might be nice to produce a big include file with useful functions in it, ready to be discarded if not used (note: there's no standard way to do that, so we stick a bit more on WLA DX), I see two main problems:

- Which registers should I use? Do I make overloads of (for example) SetVRAMAddress for passing the address in hl, de, bc, (hl), ...
- It hides the implementation details from people, making it harder to go beyond the first stage
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 715
Reply with quote
Post Posted: Tue Jun 24, 2014 4:33 pm
Maxim wrote
- Which registers should I use? Do I make overloads of (for example) SetVRAMAddress for passing the address in hl, de, bc, (hl), ...
- It hides the implementation details from people, making it harder to go beyond the first stage

I can agree on your second point, but I don't think the first one is really a problem. If someone isn't able to adapt example code to his program's needs, he won't get anywhere far with his project anyway.

I do think that the code snippets section, nice as it is, could use a little more content. It would be nice to have some standard solutions to standard problems handy. As a total beginner when it comes to assembly language myself, I often feel like I have to reinvent the wheel when tackling even the most trivial of problems.

This forum has some great resources for developers, but some of the best stuff is hidden in forum threads whose titles aren't always the most descriptive.

Your tutorial is a very good starting point for someone who wants to develop for the SMS, but it can be hard to go on from there. Actually, it was Jonathan Cauldwell's tutorial "How to write Spectrum games" that proved to be most helpful next step for me. If you ignore the Spectrum-specific stuff, it gives a very good insight into Z80 assembly and touches on a lot of points interesting to the budding developer, namely collision detection, score handling, enemy ai, etc.

The document can be dowloaded here, at the bottom of the page:
http://www.spanglefish.com/egghead/index.asp?pageid=397755
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Tue Jun 24, 2014 6:11 pm
Feel free to add code snippets, and everyone else should feel free to edit them. Within reason, you can copy/paste bits from other sites (e.g. http://map.grauw.nl/articles/mult_div_shifts.php ) if there is no obvious rule against it and you link back nicely. Making things WLA DX compatible where appropriate is nice too.

If you find a topic whose title could be made a lot more relevant, PM me or Bock. We can edit it.

My tutorials stop where they do for a few reasons:
1. Life
2. I haven't done everything

For the higher-level stuff like collision detection and AI, I can't say I've ever really implemented much of them (my ono game had nice collision detection using Pythagoras, but that only applies to circular sprites so isn't very useful).

Still, in the middle there's a lot of reinventing the wheel and it would be nice to work on some of that. Maybe next time you come across an example, you can start a forum topic on it and if it's nice and small, people may weigh in on the optimisation/critiquing/etc, much like the many sverx threads we had around the start of the year.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 715
Reply with quote
Post Posted: Tue Jun 24, 2014 8:28 pm
I wasn't aware that anyone had the rights to edit the wiki pages. I don't really know if my coding skills are up to scratch to contribute anything meaningful, though.

However, taking your cue, I just put up my first page there. I wrote a screen fading routine today, which I assume might be interesting for others. It works quite beautifully for me, although I'm sure it can be done more efficiently.

Here it is, feel free to shred it to bits:
http://www.smspower.org/Development/ScreenFading
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Tue Jun 24, 2014 8:30 pm
Maxim wrote
[...] much like the many sverx threads we had around the start of the year.


As a total SMS/Z80 asm beginner I really had to bother you all with lots of questions. That's why I felt that something was missing.
From zero to 'one' there's Maxim's tutorial, very nice starting point.
From 'one' on, I had to figure everything myself, with lots of help from this community, of course.
Anyway I guess we could start making some collection of macros. I defined many in my code, again using lots of your suggestions... for instance code to do
add hl,a
or
shl a,#n

and such.
Will post them soon, with some explaining comment. Please everybody feel free to add/update/improve/enhance/comment :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Tue Jun 24, 2014 9:04 pm
I meant your threads were a good thing, too many people go through the same stages privately (one to one help or even just on their own), when doing it in public gets you better responses from more people and a resource for others to use later.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Wed Jun 25, 2014 11:35 am
OK, here are the macro I'm using (well, those who might actually be of some use to others...)
I know it's not much, but... hey, it's free ;)

.macro ASLA args shift
  ; this is ARITHMETIC SHIFT LEFT A by 'shift' bits using ADD A,A since it's more efficient than SLA A
  ; cycles taken = 4*shift
  ; affects A, Flags
  .rept shift
    add a,a
  .endr
.endm

.macro LSRA args shift
  ; this is LOGICAL SHIFT RIGHT A by 'shift' bits using RRCA, more efficient than using SRA for shift>1
  ; cycles taken = 4*(shift+1)
  ; affects A, Flags trashed
  .rept shift
    rrca
  .endr
  and $FF>>shift
.endm

.macro ASLHL args shift
  ; this is ARITHMETIC SHIFT LEFT HL by 'shift' bits using ADD HL,HL
  ; cycles taken = 11*shift
  ; affects HL, Flags unaffected
  .rept shift
    add hl,hl
  .endr
.endm

.macro RRA args shift
  ; this is ROTATE RIGHT A by 'shift' bits
  ; cycles taken = 4*shift
  ; affects A, Flags
  .rept shift
    rrca
  .endr
.endm

.macro ADDHLA
  ; this is HL=HL+A, since ADD HL,A doesn't exist...
  ; cycles taken = 20
  ; affects HL and A, Flags trashed
  add a,l
  ld l,a
  adc a,h
  sub l
  ld h,a
.endm


I hope the comments are clear and correct. Again, feel free to add (or fix) everything that might be useful.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8507
  • Location: Paris, France
Reply with quote
Post Posted: Wed Jun 25, 2014 12:23 pm
Putting code on the Wiki can be intimidating because code is something that evolve and can be discussed and can be improved and can be fixed, and the wiki may carry this feel of "this is accurate data".

Some routines may be generic and "confident" enough to land on a wiki (like the screen fade) but perhaps we could take an habit of sharing code on the forum under a common label, e.g. topic "Shared Code: my arithmetic macros" ? then it is less scary and more open-ended, and maybe the thread can lead to a wiiki page which would like back to the thread for further discussion.

Article like the "ScreenFading" page should be dated and signed preferably? To provide with a context. Although I think we want to discouarge people from messaging the author directly, and encourage public discussion instead. At any rate they should be treated as community 'articles / proposal' rather than 'facts' - I think it would lead users to more constructive reactions.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Wed Jun 25, 2014 12:50 pm
How about a GitHub repository?
We could start simply collecting code snippets, then we might eventually evolve it into a full programming library, time given...
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 715
Reply with quote
Post Posted: Wed Jun 25, 2014 4:46 pm
Bock wrote
Some routines may be generic and "confident" enough to land on a wiki (like the screen fade) but perhaps we could take an habit of sharing code on the forum under a common label, e.g. topic "Shared Code: my arithmetic macros" ?

That is an excellent idea. Next time I think I have something worth sharing I'll do just that.

Bock wrote
Article like the "ScreenFading" page should be dated and signed preferably? To provide with a context.

You can always click on the "History" button to see the edits and who put the page up originally. That's not terribly obvious, though, so adding a line at the end of an article that states the author and the latest edit seems like a good idea, and readers can easily see that the article is a personal contribution of a community member.

sverx wrote
How about a GitHub repository?
We could start simply collecting code snippets, then we might eventually evolve it into a full programming library, time given...

I like this idea. How do you want to handle the documentation, though? Even simple bits of code sometimes need rather extensive instructions on their function and how to use them properly, not all of which can be done with inline comments easily.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Thu Jun 26, 2014 7:40 am
Kagesan wrote
How do you want to handle the documentation, though?


I have no idea! Suggestions?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Thu Jun 26, 2014 9:43 am
Block comments? URLs of wiki pages in comments?

I don't think github is ideal for this kind of project, it would require too much active maintenance of the "primary" fork. We need to optimise for few people occasionally diving in to contribute, we are not dealing with the Linux kernel here.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Thu Jun 26, 2014 11:01 am
So which platform would be suitable? I mean, I believe we need something that has sort of the Git features and also enables the occasional contributor to take part...
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2013
  • Posts: 353
  • Location: Osaka
Reply with quote
Post Posted: Thu Jun 26, 2014 11:20 am
maybe the simplest solution is just a new forum section,
where each thread is about a single topic.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Thu Jun 26, 2014 12:31 pm
But I guess those who wants to start programming needs some sources (a zip file?) to download and put it with its code...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Thu Jun 26, 2014 1:32 pm
I suggest using the wiki here for collaboration - I can make a separate section for it if wanted. This is resilient to people disappearing, as it's in "common ownership", as opposed to something on GitHub where in the same situation you would need to find the active fork.

Given a little time, I could cobble together a bit of PHP to turn the whole lot into a single downloadable file, with sections, contributor names and URLs back to the originating pages. Or you guys can come up with something if you want to dabble in PmWiki, it's quite friendly.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Thu Jun 26, 2014 9:15 pm
To get back to the palette fade above...

I find for a game of any complexity, I end up having the palette (and sprite table) in RAM, and copy them to the VDP on every VBlank. This means that I can do palette fades by operating on the palette copy at an appropriate interval (60fps is too fast), so usually change my VBlank function pointer to one devoted to fading, to invoke the change.

It's best to make the fade include as many steps as possible to make it look smoother. Phantasy Star does this by fading the red channel first (3 steps), then green, then blue. You get weird colour casts but the smoothness seems worth it to me. (Obviously, the Game Gear does much better in this respect.)

Another idea is to fade the background and tiles separately, or to fade to white, or to a greyscale palette on the way. These can be nice for special effects, and can be achieved by changing the fade function to use two palettes, the current and target palettes, and have it calculate the intermediate steps by whatever algorithm you like.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 200
Reply with quote
Post Posted: Fri Jun 27, 2014 10:43 am
Yes, we need better tools. I think they're coming. Lots of people are working on lots of different things. It will all eventually come together.

I am doing my part by writing a better assembler: OZ80MANDIAS

Making code more portable and re-usable is its purpose. It has features no other assembler has, all designed around making SMS programming easier.


  • A means to define memory use by name, with auto-incrementing of the address. A library function can just provide the names of the RAM variables / structures it needs and the assembler will assign the addresses for you, e.g.

    RAM {
        .FLOORLAYOUT AS BYTE x 4KB
        .CURRENTLEVEL as BYTE
        .FRAMECOUNT AS WORD
        `etc...
    }

    These are accessed through special variables, like so: `ld hl, ($.FRAMECOUNT)`

  • Documented procedures allow any user of your code to get at-a-glance information on how to use your procedures

    PROC :myProcedure
        PARAMS hl `address to data
        RETURN a `result of calculation
        CLOBBERS de
    {
        `...
    }


  • BMP2Tile like functionality, able to 'include' a BMP file which will get automatically converted into SMS format, with optional compression scheme. (the syntax for this is undecided yet)

    BINARY TILESET "tileset.bmp" COMPRESS PSG

    This could, for example, be expanded in the future to include music to be played by PSGLib

  • Better bank management, as current assemblers require you to place bank information close to the data required. This is not good for portability and worse for managing a large code base. With OZ80, bank management is much simpler!

    A section map can be defined at the start of your code which assigns different sections to different banks (or leaves it up the assembler)

    SECTION ::interrupts    BANK 0 SLOT 0
    SECTION ::main          BANK 0 SLOT 0
    SECTION ::objects       BANK 1, 2 SLOT 1, 2
    SECTION ::sound         BANK 3, SLOT 2

    Within your code, you just mark each block with the section it belongs to:

    PROC :myProcedure SECTION ::main { ... }

    The assembler will find the right place for it to go in the ROM. What's more you now have a single heads-up ROM map that lets you rearrange banks and slots without trawling the whole codebase! This allows 3rd-party library code to be moved around without having to modify the code itself (as long as it's correctly labelled internally)


I'm aiming to solve the whole "code is hard to reuse" problem and create the new standard assembler for SMS. Any feedback would be appreciated.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 715
Reply with quote
Post Posted: Fri Jun 27, 2014 1:06 pm
Maxim wrote
To get back to the palette fade above...

I find for a game of any complexity, I end up having the palette (and sprite table) in RAM, and copy them to the VDP on every VBlank. This means that I can do palette fades by operating on the palette copy at an appropriate interval (60fps is too fast), so usually change my VBlank function pointer to one devoted to fading, to invoke the change.

It's best to make the fade include as many steps as possible to make it look smoother. Phantasy Star does this by fading the red channel first (3 steps), then green, then blue. You get weird colour casts but the smoothness seems worth it to me. (Obviously, the Game Gear does much better in this respect.)

Another idea is to fade the background and tiles separately, or to fade to white, or to a greyscale palette on the way. These can be nice for special effects, and can be achieved by changing the fade function to use two palettes, the current and target palettes, and have it calculate the intermediate steps by whatever algorithm you like.

That's why I called it a 'Quick fade' in the block comments. I'm well aware of the limits that particular piece of code has, but I wasn't actually aiming for a full-on cinematic effect, just for something simple to take the edge off the transition from one (static) screen to the next.

That there are ways to make it prettier/smoother goes without question.

If you feel that the example is too specific in its use and not generic enough to remain in the code snippets section, feel free to remove it.
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8507
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jun 27, 2014 1:20 pm
Last edited by Bock on Fri Jun 27, 2014 4:53 pm; edited 1 time in total
Kagesan wrote
If you feel that the example is too specific in its use and not generic enough to remain in the code snippets section, feel free to remove it.

This is the essence of the discussion we are having IMHO. No code will be generic enough ever. We have to embrace that and just post stuff because no code will be perfect but all code can be useful. This is also why I think a flexible medium is preferable to allow iterations and discussions. Also why I suggested putting names and date along with code to put an emphasis on "this is something someone did, it may be useful to copy or learn from" rather "this is the definitive way to do xx".

Aka it would be totally fine and healthy if we had 3 different screen fading code on that page.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Fri Jun 27, 2014 3:43 pm
Yes, I don't mean to say your method is bad at all, just that there are lots of alternatives worth bearing in mind, even for something apparently so simple. The preamble does a good job of explaining the scenario where your code is running.

One idea I had was to specify a "baseline" program with things like pointer-based VBlank and HBlank handlers, a pause handler just setting a flag, and some RAM buffers for the palette, sprite table and VDP registers, and functions to emit them during the VBlank. In other words, a better "Hello world". This could then be a baseline for extra functionality on the top. The problem is, this thing doesn't exist right now and while it's a pretty good foundation, it's still not generic enough, there are scenarios where it'd not work. Also, your existing code would have to be modified to work with it.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 715
Reply with quote
Post Posted: Fri Jun 27, 2014 4:59 pm
Bock wrote
This is the essence of the discussion we are having IMHO. No code will be generic enough ever. We have to embrace that and just post stuff because no code will be perfect but all code can be useful. This is also why I think a flexible medium is preferable to allow iterations and discussions. Also why I suggested putting names and date along with code to put an emphasis on "this is something someone did, it may be useful to copy or learn from" rather "this is the definitive way to do xx".

Aka it would be totally fine and healthy if we had 3 different screen fading code on that page.

I agree completely.
  View user's profile Send private message
  • Joined: 09 Apr 2013
  • Posts: 106
  • Location: Sydney Australia
Reply with quote
Filter homebrew game search by games with source code
Post Posted: Fri Jun 27, 2014 10:14 pm
Hi Guys,

I found it really helpful to look at other sms homebrew games with source code when I was coding my minesweeper 2014 comp entry but it's a little hard to find which ones come with source code when browsing the homebrew section.

Would it be possible to add a browse by games with source code filter to the home brew search?
  View user's profile Send private message
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Fri Jun 27, 2014 10:46 pm
efry wrote
Hi Guys,

I found it really helpful to look at other sms homebrew games with source code when I was coding my minesweeper 2014 comp entry but it's a little hard to find which ones come with source code when browsing the homebrew section.

Would it be possible to add a browse by games with source code filter to the home brew search?

^^^^^^^^
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Sat Jun 28, 2014 5:47 am
http://www.smspower.org/Homebrew/Index?action=search&q=%24%3ASource%3Dsepara...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8507
  • Location: Paris, France
Reply with quote
Post Posted: Sat Jun 28, 2014 2:49 pm
This search query include KunKun & KunKun 2 which is on a separate repository
http://www.smspower.org/Homebrew/Index?action=search&q=%24%3ASource%3Dsepara...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Mon Jun 30, 2014 3:30 pm
Kroc wrote
I am doing my part by writing a better assembler: OZ80MANDIAS


Please, please... make function-style defines possible. Such as
.define SOMETHING(somevar)   ((somevar>>1)|0x0F)

for instance...
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 200
Reply with quote
Post Posted: Mon Jun 30, 2014 4:55 pm
sverx wrote
Please, please... make function-style defines possible.


There are functions (essentially macros that return a value so that they can be used inline as a value)

FUNCTION ?something ARGS #somevar {
        RETURN (#somevar >> 1) | $0F
}

DATA 1, 2, 3, {?something 4}, 5


Though I'm not decided fully on the return syntax yet (whether to use a statement, or a variable).

Since I'm disassembling the whole of Sonic 1, I've got a large, complex codebase to work as a testbed for what's necessary in the syntax. (Individual bit management, RAM management, Functions)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3259
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Tue Jul 01, 2014 7:52 am
Kroc wrote
There are functions (essentially macros that return a value so that they can be used inline as a value)


I guess it will work, as long as pure functions calls with constants arguments will be turned into a constant value (and not with some code and a call to it) :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8507
  • Location: Paris, France
Reply with quote
Post Posted: Sat Jul 05, 2014 3:12 pm
I added a "GETTING STARTED" page prominently linked from the Development section. It is empty at the moment but we could add links to tutorials, useful wiki pages/forums posts and some emulators.
http://www.smspower.org/Development/Index
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Sat Jul 05, 2014 7:41 pm
I'd like to have this page be made by people who are/have recently got started themselves, rather than by an ancient SMS developer like me. I may deal with wiki formatting and egregious errors, though.

If anyone wants to write a tutorial, we can put that on here too.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Dec 2013
  • Posts: 69
Reply with quote
Post Posted: Mon Jul 14, 2014 11:01 pm
Are there any libraries out there for displaying to the screen? I'm trying to gather a few useful things, and so far have found aPlib and PSGlib.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14225
  • Location: London
Reply with quote
Post Posted: Tue Jul 15, 2014 7:03 am
BMP2Tile comes with libraries and a demo for pushing compressed images to the screen. That is only good for static background images, for a real game you will want something more custom.
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!