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

Welcome to our latest new user maak ! (Registered 2024-04-18)

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.

2022-02-05 00:51

Burglar

Registered: Dec 2004
Posts: 1031

yay! an original compo :) looking forward to entries :)

2022-02-05 10:01

DeMOSic

Registered: Aug 2021
Posts: 126

Quote: 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.

Yay! A new TinySID compo! ill try to participate if i can

2022-02-05 11:59

Krill

Registered: Apr 2002
Posts: 2825

What's the rationale behind those very detailed technical restrictions? (I still haven't fully grasped the gist of them.)

Why isn't executable size (with or without load address/start stub) enough?

2022-02-05 12:07

Krill

Registered: Apr 2002
Posts: 2825

Ah, the idea seems to be maximum reuseability.
Including separate init and play calls.
With conventional usage patterns of zeropage/stack/code/data.
In tiny tunes. For very size-restricted productions.

I dunno. Seems a bit like a contradiction, with avoidable overhead pre-programmed.

But do go ahead. :)

2022-02-05 15:06

Jammer

Registered: Nov 2002
Posts: 1289

I understand that particular memory limits concern only driver+data, not whole thing with exec wrapper?

2022-02-05 15:13

chatGPZ

Registered: Dec 2001
Posts: 11100

Thats simply so ppl judge the music, not the fancy demo

2022-02-05 15:55

Karmic

Registered: Apr 2015
Posts: 66

Quoting Krill

Ah, the idea seems to be maximum reuseability.
Including separate init and play calls.
With conventional usage patterns of zeropage/stack/code/data.
In tiny tunes. For very size-restricted productions.

I dunno. Seems a bit like a contradiction, with avoidable overhead pre-programmed.

But do go ahead. :)

I suppose it does, after all, if I didn't restrict you in these ways you could certainly find ways to make the code smaller. But it does go against the mission of the compo, which is to give intro-coders a wider variety of easily usable small SIDs to choose from. Purely judging on executable size would certainly be valid for a "whole product" (like a demo), but this compo is not about producing "whole products". It's more like you're making an "ingredient" that a demo-chef can make part of his recipe, and for this to work, your ingredient must be able to coexist with other things in the same bowl.

I don't think most of the limits are hard, most of them aren't even really limits, it's just "regular" practice. Lots of PSIDs in HVSC follow these rules (aside from the size restriction) already. Unless you actively try to break them, you probably won't.

Quoting Jammer

I understand that particular memory limits concern only driver+data, not whole thing with exec wrapper?

Yeah. The guideline is, only anything that would have to be included in a SID file is counted.

2022-02-05 16:50

The Syndrom

Registered: Aug 2005
Posts: 56

I like the idea... challenge accepted..

2022-02-07 12:41

Frostbyte

Registered: Aug 2003
Posts: 165

Brilliant, thanks for organising this, and thanks for a reasonable entry period too. May even have time to do something for this, or at least attempt to. :)

I fully understand the strict rules, which enforce the "self-containment" and thus make the music actually useable in real life prods. Also I appreciate the "music, not a demo part" rule. :) Only a couple of things I'd want to nitpick about:

"- Your music code cannot access any I/O registers outside of $D400-$D41B."

This should probably be up to $D41C, which is the last SID register (voice 3 ADSR output)? Leaving it out prevents implementing some custom tricks (e.g. filter curves) based on it.

Also, everything from $D420 to $D7FF is just shadows of SID registers. Allowing usage of the shadow registers could possibly help shave off a few bytes from here and there, depending on the player implementation. This could be valuable especially for 512b entries. But just thinking aloud here, really.

And just to further clarify:
"- 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."

So in short, the tune can utilize the ZP from $08 to $FF in any way it sees fit (temp variables, player code, music data)?

2022-02-07 15:47

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Quote:

But it does go against the mission of the compo, which is to give intro-coders a wider variety of easily usable small SIDs to choose from.

I think this is a good priority! Easier usability is worth more than the few saved bytes possibly gained by weird trickery.

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

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

El Jefe/sidDivers
Guests online: 101

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)

Top onefile Demos

1 It's More Fun to Com..  (9.9)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Crackers

1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

Page generated in: 0.178 sec.