[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-05-29 02:23

Karmic

Registered: Apr 2015
Posts: 66

Voting is now OVER, and the results are in. Out of 13 voters:

256b Category

1. Pocket Universe (8.83)
2. Rozzo (7.75)
3. Compromises (7.08)
4. HerMiniSID-252bytes (7.00)
5. Ambience (6.67)
6. Page Beep (6.50)
7. LFSR-SID (4.67)


512b Category

1. Lift Off (9.17)
2. Rain (8.58)
3. Immortality (8.33)
4. Dark castle (7.67)
5. Paralyzed Bits (7.64)
6. 512 Rap (7.23)
7. MajomTanc (6.83)
8. 1 Byte Under 512 (4.64)


1k Category

1. Selfies from the Ex (8.92)
2. Airport (8.62)
3. Immortality II (8.00)
4. Minisea (7.55)
5. 1kTestAcle (7.50)
6. Size Matters (7.33)
7. Barrel Cortex (6.83)
8. Congratulatheme (6.58)
9. Sweet Martha (6.50)
^. Mini Blues (6.50)


2k Category

1. Quite Close (8.42)
2. MSK Cover-XF End (8.25)
^. Gravity (8.25)
4. Young Poe (8.23)
5. Electric Zoo (7.50)
6. Sunday (7.42)
7. Robust Condor (6.50)

Thanks for participating! Again, I am very pleased at the amount of entries in this compo.

2022-05-29 14:23

ChristopherJam

Registered: Aug 2004
Posts: 1408

Yes, thanks everyone - some definite gems in here.

And Karmic, thank you so much for organising! Excellent ruleset, and prompted quite a flurry of entries.

Now to pick over a few of the smaller entries for code inspiration :)

2022-05-29 21:46

Jammer

Registered: Nov 2002
Posts: 1335

Applause for the worthy winners! <3
It was really a compo everyone needed after that long time. I hope next edition is going to launch sooner ;)

2022-05-30 09:26

deetsay

Registered: Aug 2005
Posts: 43

For next time, I hope for some clarification: Does the tune need to re-initialize *all* it's parameters to the same starting state in every init call? If yes, then that's understandable and fine. However, at least I am interested in revolving as many parameters as possible over time (add, roll, change opcodes). Changing all of these back to the starting state takes a lot of bytes, in a situation where every byte is critical (at least in 256b).

The thing is, there IS a workaround: Just copy everything to zeropage and work from there. That will eat up almost all of it, but for some reason that would be currently allowed. Going ZP with the self-modifying code should save about as much as the copying code takes. But I'm not sure that this is a great option for the rationale -- in a production, a coder might like to have a chunk of the zeropage for something more critical than the music.

And also for the purpose of small demoish productions, restarting the song in exactly the same way doesn't sound like a strictly necessary feature.

So I would propose a ruleset that goes something like:

- The song needs to initialize itself to a playable state in the init code and needs to initialize all data outside the loading footprint (same as now).

- On calling init AGAIN it still needs to initialize all data it uses outside its loading footprint so that it's playable, BUT it DOESN'T have to be exactly the same data as the first time.

- If the song takes that liberty and does not re-init itself completely each time, then the SID file needs to come with a different init code that always fixes everything to the starting state, to stay in line with the standard. This extra init-code is not counted against the size limit.

I know, it's too complicated and probably confusing. But that's what I'm proposing anyway!

2022-05-30 19:50

ChristopherJam

Registered: Aug 2004
Posts: 1408

I like where you’re going with that Deetsay. Personally I’d prefer that the version within the size limit not have to support a second call to init at all; as you said, it’s not something that most productions would require, and can definitely entail extra baggage.

Also agreed about how trashing all of zp is likely to be a conflict. Perhaps a future compo could limit that to 64 bytes? Or alternatively, the compo could just require the zp usage be documented with the entry, so voters can include lightness of zp impact in their scoring consideration?

Similar considerations apply to raster usage of course.

2022-05-30 20:07

iAN CooG

Registered: May 2002
Posts: 3186

The requirement of a proper init is due to a long history of old songs ripped while playing and natively lacking of a proper init, so they wouldn't restart
with all the voices inited properly, or not even from the first pattern and so on. Imagine being in the old days, when you didn't have the pre-inited
original binary, but wanted to use *THAT* tune, you would rip it from memory and most probably after it started playing.
Another problem of not initing correctly all the vars is due to memory fill patterns different on every C64 depending on the RAM chips mounted.
You (probably) have no idea how many sids got re-ripped in the previous years to fix such silly problems.
A proper init would guarantee the tune playing always the same no matter when it gets re-saved.

2022-05-30 20:30

ChristopherJam

Registered: Aug 2004
Posts: 1408

Ian: no one is proposing “no init.” We just want the possibility to make an entry where init is only guaranteed to work once, at least in the smaller variant of the release. Of course the compo could also require a .Sid where init works many times, but that would be allowed to exceed the size restriction for the category entered.

2022-05-30 20:36

Burglar

Registered: Dec 2004
Posts: 1085

I think Ian is mixing up "hvsc requirements" with "compo requirements", while I understand it from a hvsc perspective, it's not in the rules for this compo.

2022-05-30 21:47

iAN CooG

Registered: May 2002
Posts: 3186

> init is only guaranteed to work once

At this point if you only care about it working only once, just do like Dane does from some years, there is NO init at all, you need to have the preinited binary when you link the tune to your prod, that's it, and fuck everybody else, there's an idiot out there that patches a correct init when he rips the tunes for his collection in any case ;)

Burglar: I only wanted to tell an explanation why an init is a good thing. Adding it or not, it's just a matter or caring about who is going to use the tune apart the author himself, or not caring at all.

2022-05-31 18:02

Burglar

Registered: Dec 2004
Posts: 1085

Quoting iAN CooG

Burglar: I only wanted to tell an explanation why an init is a good thing. Adding it or not, it's just a matter or caring about who is going to use the tune apart the author himself, or not caring at all.

I agree, you are correct there, but in the scope of this thread/compo, every byte counts.

I would suggest modifying the rules a tiny bit for any future tinysid compos:
require a .sid including proper init (exactly as you specified), but the music code+data in the (also required) .prg will be used to count bytes for the size limit.
win-win? :)

edit: I forgot to add, what an awesome compo this was!
thanks for organizing and participating, many gems found :)

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

DJ Gruby/TRiAD
Guests online: 138

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Wonderland XIV  (9.6)
8 Comaland 100%  (9.6)
9 No Bounds  (9.6)
10 Christmas Megademo  (9.5)

Top onefile Demos

1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)

Top Groups

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

Top NTSC-Fixers

1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Page generated in: 0.046 sec.