[CSDb] - User Forums - Event id #3157 : Unofficial Tiny SID Compo 2022

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Event id #3157 : Unofficial Tiny SID Compo 2022

2022-02-05 00:20

Karmic

Registered: Apr 2015
Posts: 66

Event id #3157 : Unofficial Tiny SID Compo 2022

Welcome to the Unofficial Tiny SID Compo 2022.

Rationale
Now, as you may be aware, recently in the scene there has been an uptick in people using so-called "tiny" SIDs, mostly thanks to Didi & Richard's series of Intro Creation Compos, where the intros are only allowed to use a certain block of RAM. The problem with this is that there is a severe lack of decent tiny SIDs out there- all it takes is a little bit of browsing through the comments of ICC2021 entries to see some discontentment over the same old GRG tunes being reused over and over again. Now unfortunately this compo comes a little too late to rectify that particular situation, but I believe that even outside of the ICC2021 context, coders will appreciate having a wider library of tiny SIDs to choose from for their killer RAM-eating effects.

This compo idea does have precedent- Stefano Tognon (Ice00) has previously hosted some Tiny SID Compos 15 or so years ago, which got a decent amount of entries. My rules are fairly different from his, though.

Rules
The goal of this compo is to produce a self-contained tune, where, with the exception of the zeropage and stack, the entire RAM area used by the tune is contained in one 512b/1kb/2kb (depending on the category) block.

The exact technical rules by which your tunes will be judged are as follows:
- All code, data, and non-zeropage variables that are required for your tune to play should fit in one continuous block of the size specified by the category. Your music code is not allowed to access any non-zeropage RAM outside of this range.
- Your music code should not rely on the initial state of any zeropage location.
- Stack area ($01xx) must only be accessed conventionally, as a stack. That is, only use JSR, RTS, PHA, PLA, PHP, and PLP. Most stack tricks hurt the self-contained-ness of your code.
- Your music code cannot access any I/O registers outside of $D400-$D41B.
- Your music code cannot access any of the ROMs (kernal, basic, chargen).
- Your music code cannot access $00-$01. A coder certainly won't like it if his SID interferes with the bank configuration.
- To give tunes some zeropage "breathing room", your music code cannot access $02-$07.
- Your music code cannot access $0200-$033B, $D000-$DFFF (the RAM under I/O), or $FFFA-$FFFF. Again, a coder won't like it if you mess with these.
- Your music code cannot change the I bit in the CPU status register. So, no SEI, no CLI, and any PLP should be accompanied by a corresponding PHP.
- If you find a use for the decimal mode, you must make sure you turn it off before your music code exits. You can safely assume decimal mode is off at the entry points of your music code.
- Your music routines should be accessible like a PSID file, with an init entry point that exits with an RTS, and a play entry point that executes once per frame, and exits with an RTS.

Be aware that none of the above rules apply to any code that presents your music. As per CSDb rules, you must provide an executable. A good way to think about it is: if we in HVSC had to rip your tune as a SID, which code and data would we have to include?

To make up for the extreme technical restrictions, I am giving you very little creative restrictions:
- Covers and tiny adaptations of other SID tunes ARE allowed.
- It IS allowed to use a player made by someone else, but your tune must be wholly new and not just a cheap edit of the original.
- One composer can enter a maximum of 2 tunes per category.
- Your tune must last for at least 10 seconds before it loops.
- Your tune's presentation must be fairly minimal. Some text, a logo, and an equalizer is okay, but you can't submit a whole demopart and call it a "music entry".

When adding your entries to CSDb, please use the "512b/1K/2K Game" compos. This looks odd but at the end of the day gives the best at-a-glance look at the categories.

The entry period lasts from right now until May 7th, 11:59 PM CSDb time (CET). Depending on the amount of entries, I will either use an external votesheet or you will vote right on CSDb. We'll see.

Tips
If you are a musician who is not a coder, you probably know someone who is and would be willing to help you. If you really don't, you can at least enter the 2k category with a tune in a slim player such as GoatTracker or NinjaTracker.

... 86 posts hidden. Click here to view all posts....

2022-02-21 15:51

Hein

Registered: Apr 2004
Posts: 933

All I can say is that I had fun coding my tiny music routine. The music I converted to the tiny format was an old piece anyway.

2022-02-21 16:39

spider-j

Registered: Oct 2004
Posts: 444

@Conrad: what are you talking about? Since when is "It IS allowed to use a player made by someone else" a "real coder's competition"?!?

2022-02-21 16:39

Karmic

Registered: Apr 2015
Posts: 66

Quoting Conrad

I was going to stay quiet, but fuck it, I really don't care anymore...

Respect to Hermit for FlexSID and nothing personal against him... but after what Karmic has just said, it's practically rendered most of the rules in this compo worthless and it's ruined a real coder's competition. You (Karmic) may as well just remove the entire rule-list on the code limits now and make it a compo for musicians only. I don't know about other coders, but one feels he's wasted a valuable amount of hours/days for nothing.

EOD.

It was never a "real coder's competition". From the beginning I said entrants could use other people's players, and even recommended GT and NinjaTracker for desperate situations. This new tracker is IMO only a good thing, as I'm sure there are a lot of talented composers (e.g. Steel who posted in this thread before) who wanted to participate, couldn't, and now can. It might not seem like it, but aside from the size limits, the rules are not made to limit you, it's just the guidelines that all "reusable" play routines follow already.

Anyway, aside from that, I can only reiterate what Krill and Michal said. I believe that voters will take into account the effort spent on making a player, and when it comes to tiny stuff you always get the best results designing your player "around" the tune instead of using a generic player anyway. You are a good composer and coder so I hope you understand, and continue working on your entry.

2022-02-21 16:49

Krill

Registered: Apr 2002
Posts:

Real coders let the tune compose itself!

(Code a player for procedural/generative music and have a tune that's impossibly long and diversely structured for the size, or something.)

2022-02-21 16:57

Karmic

Registered: Apr 2015
Posts: 66

Quoting Krill

Real coders let the tune compose itself!

(Code a player for procedural/generative music and have a tune that's impossibly long and diversely structured for the size, or something.)

I'm actually hoping for at least one of these in the compo.

2022-02-21 18:23

Krill

Registered: Apr 2002
Posts:

IIrc, 2K ($0800 bytes) tunes have been around for a while, and can be made with regular editors quite easily.
Things like JCH's newplayer V19 have been around since the early 1990s or so. :)

(That said, 2K may be considered small, but not really "tiny". 1K isn't that tiny either.)

2022-02-22 13:18

Ninja

Registered: Jan 2002
Posts: 404

I have to agree with Krill. 1 or 2K are also not tiny in my book. 256 and 512 byte tunes were the real challenge back then. But yeah, it is Karmic's compo, if it wasn't for his initiative, we wouldn't have the discussion now.

And Conrad, if you finish your thing, I am sure it will kick major ass anyhow!

2022-02-22 14:35

deetsay

Registered: Aug 2005
Posts: 36

I made a lot of analysis of SID files some time last year, using a SID header reader that says how many pages the files are using (and which pages, to figure out the best place for a DJ-program to reside in). Only the load address and size of file is considered, of course, this doesn't say if the SID stays within its loading footprint. Luckily most do. The decade depends on the year being written in the first 4 characters of the COPYRIGHT-field (it is *almost* always there). 512b contains only the SIDs that are 257b-512b, 1k is only 513b-1k, etc.

There are *NOT* a lot of SIDs that fit inside a single page, and 2k isn't exactly mainstream either:

	80s	90s	00s	10s	20s
256b	25	3	3	6	1
512b	86	4	20	16	11
1k	227	13	36	42	18
2k	681	1106	483	626	178
4k	4549	17768	3748	3535	660

I don't remember which HVSC version was used specifically, don't remember if I had other limiting "search options" and didn't do any double-checking on these numbers, but I'm sure that the idea of scale expressed by the numbers is fairly reliable.

2022-02-22 14:43

Krill

Registered: Apr 2002
Posts:

Well that table clearly shows that anything below 1K is home of SID shortage, which this compo aims to address. :)

1K itself is debatable, 2K is plenty.

2022-02-22 15:24

deetsay

Registered: Aug 2005
Posts: 36

Maybe this is more interesting than just numbers. Should we expect to see World Records broken in this compo? Time to check what the rules say about BASIC... http://www.tero.fi/tinysids.txt