SMSPower Coding Competition 2016

[DarkKobold]

http://www.retrocollect.com/News/smspowers-2016-coding-competition-alex-kidd-in-miracle-world-2-a-more-master-system-games-out-now.html

There are some super impressive homebrews that come out for the SMS every year, thanks in part to this coding competition. Its curious to me as to why the SMS homebrew scene is so strong, while the TG16 homebrew scene is much smaller.

Perhaps the SMS scene has more euro folk? It just seems strange.

Maybe a yearly PCEFX coding competition could inspire more people to give it the ol' college try?

[Black Tiger]

The SMS was a hit on most parts of the world. Basically, anywhere that Nintendo didn't have an unfair/illegal monopoly. Plus Sega is much more popular than the NEC/Hudson/PCE brand.

I've also heard many people say that it's relatively easy to develop for and I regularly see new tools being posted in various forums.

It shouldn't be this way, but it is: you'd get much more interest from the gaming community in general if more people made
PCE tech demos that are ports of sections of popular games. An increase in popularity of PCE demos might lure new programmers to the system.

Even if you simply recreated the early stretch of SotN on PCE, people would freak out. Even though 16-bit games already do that kind of stuff and more.

[elmer]

There are some super impressive homebrews that come out for the SMS every year, thanks in part to this coding competition. Its curious to me as to why the SMS homebrew scene is so strong, while the TG16 homebrew scene is much smaller.

Perhaps the SMS scene has more euro folk? It just seems strange.

I guess it's because to some folks in some regions it gives them the same warm-and-fuzzy feelings that the NES gives US folks ... and in a package that is nicer to program.

The wonderful PCE really only got released in Japan, and in the US (where we know that few folks have the warm-and-fuzzies about it).

So there just seems to be a smaller pool of people that want to write stuff for it 30-years-later.

[DarkKobold]

I'm curious why the Z80 is easier to program for over the 6802 clones (NES/PCE). In my experience, HC6811 (Genesis) is by far the easiest to program for, if you are doing assembly level stuff. Extra registers just make life so much easier.

Thus far, all dev I've done has been in HuC, and its functional enough to do everything I need. Unfortunately, most HuC updates are happening behind the scenes, and most devs here talk shit on it. (Perhaps it is deserved, I'm not qualified to answer that.) Squirrel is great, mappy sucks ass, image2pce gets the job done.  I can't think of any other tools for PCE development. We'd benefit from a stronger, better advertised C compiler. That said, if it takes a smart coder to code a homebrew, it takes a genius coder to develop a compiler.

[Necromancer]

It'd be cool to see more people coding for it, but like elmer said, the Turbob didn't have that wide of an audience.  Making a game (even just a demo) is an awful lot of work, and I don't think many people want to tackle such a task unless they already like the system.

But maybe that's where a coding contest could entice a few new peeps; with the right prizes (cash, free hand jobs, etc.), perhaps we'd get a couple more guys/gals interested in the 'bob.  They'd have to be mighty talented and/or damn fast learners to surpass anything the established guys could submit, but there's no shame in that.  Ya gotta start somewhere.

[elmer]

I'm curious why the Z80 is easier to program for over the 6802 clones (NES/PCE). In my experience, HC6811 (Genesis) is by far the easiest to program for, if you are doing assembly level stuff. Extra registers just make life so much easier.

I think you mean ...

"I'm curious why the Z80 is easier to program for over the 6502 clones (NES/PCE). In my experience, HC68000 (Genesis) is by far the easiest to program for, if you are doing assembly level stuff. Extra registers just make life so much easier."

The 6502 has A, X and Y registers.

The Z80 has A,B,C,D,E,H,L ... and then you've got the 16-bit registers BC,DE,HL,IX,IY and the alternate registers BC',DE',HL'.

So you do have a lot more registers to play with, and you actually have 16-bit registers that you can use as pointers.

In fact (pro-tip) the fastest way to draw sprites on the old bitmapped home-computers was to use the Z80's stack-pointer as the destination pointer to the screen and just "push" the sprite data.

That's the Z80 equivalent of Bonknuts' favorite ST1/ST2 on the PC Engine.

Yes ... the 68000 has even more registers, and even nicer instructions, but the Z80 usually provides "enough".

Assembly language programmers on the 6502 can play all sorts of tricks with zero-page memory and self-modifying code ... but the Z80 is usually cleaner and easier to read (and write) IMHO.

 

Thus far, all dev I've done has been in HuC, and its functional enough to do everything I need. Unfortunately, most HuC updates are happening behind the scenes, and most devs here talk shit on it. ... We'd benefit from a stronger, better advertised C compiler. That said, if it takes a smart coder to code a homebrew, it takes a genius coder to develop a compiler.

The 6502 and the Z80 just don't do C well ... they weren't designed for high-level-language programming, and they're slow and crap at it when you force them, particularly for stack-based languages like C.

HuC and CC65 are about as good as you're going to get, and both have their limitations.

Of the two, I prefer CC65 because it is "standard" C, and so it's easier to grab other people's libraries. It's also nice and flexible.

There are alternative high-level languages that fit much better with the 6502, and you can read about some of them here ... http://www.dwheeler.com/6502/

[DarkKobold]

I think you mean ...

"I'm curious why the Z80 is easier to program for over the 6502 clones (NES/PCE). In my experience, HC68000 (Genesis) is by far the easiest to program for, if you are doing assembly level stuff. Extra registers just make life so much easier."

Doh! Boneheaded move there. I learned Assembly way back when on a 68HC11, which is why I always remember that one instead of the correct processor.

The 6502 and the Z80 just don't do C well ... they weren't designed for high-level-language programming, and they're slow and crap at it when you force them, particularly for stack-based languages like C.

HuC and CC65 are about as good as you're going to get, and both have their limitations.

There are still improvements that can be made, for example, the stuff Bonknuts talks about, with all array access using far pointers, and such.

Also, Rover is creating a version of HuC that allows you to know compiled function size, thus allowing you to optimize bank placements.

[nodtveidt]

Also, Rover is creating a version of HuC that allows you to know compiled function size, thus allowing you to optimize bank placements.

I actually did this quite some time ago... it's a modified version of pceas that does exactly what you mention. I first used it for the 2014 rebuild of Mysterious Song... so it's been around for awhile now. Of course, it's still based on the vanilla 3.21 Denki version, so it has none of Tom's pceas modifications.

[wilykat]

ugh I remember trying to code for 6502 variant, one for 2600.  It took me a few days of figuring ASM enough and the 2600's quirks enough to make a stable code, and a few more days to make it display something on screen.  Never got past that.  The code was something like 250 bytes total.  I probably would have had better result if I took up Batari (2600 BASIC compiler) as it was easier, I had BASIC experience since Commodore PET ruled the school (yes I am old!!), and many recent decent games were made with Batari.

In comparison, I could do 8k of C variant coding in a single hour and not much more time spent debugging it.