| |
Didi
Registered: Nov 2011
Posts: 487 |
Event id #2889 : Intro Creation Competition 2019
Preface: Please use this thread for questions, discussion and everything else concerning this competition.
Many people were asking about the competition being held this year. It turned out to be a good place to have it after the big X party each second year. But why not give it a try in between?
This time I decided to add a second category to the well known rules: 4kB intro! It is different to the 4kB intro category you know from demo parties. There the executable file has the limit of 4096 bytes and may allocate as much as you like during runtime. Rules here only allow to use 4kB overall for a different challenge. Please check the rules for more details. Result will show if that was a good idea.
Here you go...
Competition runs from November 4th, 2019, until January 5th, 2020. So you have a full 2 months to deliver your creations. This should be enough for an intro.
RULES for both categories:
Your intro entry...
- has to work on a plain stock C64 (PAL standard) without any extensions.
- has to be a one-part intro. Short fade-ins and fade-outs are OK.
- has to contain at least one Logo at whatever size you like.
- has to contain a changing or moving text message (e.g. scrolling text, different lines fading in & out, etc.)
- has to be interruptable any time by pressing SPACE-key (exception are short fade-in and fade-out).
- does not need to have exclusive graphics, charsets or music. But the code should be exclusive, so reuse of existing code with just exchanged graphics and music is not allowed.
- has not been publicly used before entering the competition.
- has to be handed in as executable format startable with RUN (.prg or embedded in .t64 or .d64).
Your 16kB intro...
- has a maximum RAM footprint of $4000 bytes at one block, at whatever location you like. Screen RAM counts as used memory. Exclusions are system addresses like VIC (inkl. Color RAM), SID, CIA, Stack, Zero-page, IRQ vectors. This means RAM besides chosen $4000 bytes area and exceptions has to be the same before and after running the intro. What happens during runtime is up to you.
- has to contain music (not just a humming sound, please).
- is linked to this competition as "C64 Demo" entry (sorry, no other fitting entry exists).
Your 4kB intro...
- has a maximum RAM footprint of $1000 bytes at one block, at whatever location you like. Screen RAM counts as used memory. Exclusions are system addresses like VIC (inkl. Color RAM), SID, CIA, Stack, Zero-page, IRQ vectors. This means RAM besides chosen $1000 bytes area and exceptions has to be the same before and after running the intro. What happens during runtime is up to you.
- does not have to contain any sound, but feel free to add some.
- is linked to this competition as "C64 4k Intro" entry.
You are allowed to enter maximum 3 entries per participant and category, so you are can enter 6 entries at best. Entries might be taken back from the compo until deadline. That means if you want to remove one of your works from the compo to make space for another entry from you, this can be done until deadline.
Deadline for entry submission is Sunday January 5th, 2020 at 23:59:59 (11:59:59 pm) CET.
Voting closes at Sunday January 12th, 2020 at 23:59:59 (11:59:59 pm) CET.
Voting platform is CSDb (with all disadvantages it may have), therefore entries have to be posted here.
Entries will be ranked by weighted average of CSDb votes. Entries with the same weighted average are ranked by their percentages of 10s, 9s, etc.
No prices to win, just the fame. May the best creation win! |
|
... 173 posts hidden. Click here to view all posts....
|
| |
Didi
Registered: Nov 2011
Posts: 487 |
Color RAM does not need to be restored.
Stack may be garbled as well, same goes for zeropage.
$00 and $00 should be in a valid state on exit.
Would be nice if the JMP on exit would be changeable later on which might pbe a problem if it is in crunched part. ;) |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
My intro is going to use $3000-$3fff, but exomized file is, naturally, placed after right $0800. Does it violate the rules? ;) |
| |
Didi
Registered: Nov 2011
Posts: 487 |
Of cource not. But you should not rely on blanked screen or colors set by the decruncher. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Didiyou should not rely on blanked screen or colors set by the decruncher.
Sure, but can we decrunch directly to color ram if the decruncher supports multiple destination segments? |
| |
Didi
Registered: Nov 2011
Posts: 487 |
You can decrunch to color RAM if you like, if the decruncher is part of your custom area. If you use another area e.g. $1000-$2000 and your intro relies on colors set by a decruncher which is used to make it run-excecutable, it might look strange because the decruncher will not be present anymore in a later collection. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ah, that makes sense, thank you.
Ok, I'll just have 0801-1800 for my custom area I think, should avoid any confusion. |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
Tillax Intro
Count me in ;) |
| |
TheRyk
Registered: Mar 2009
Posts: 2241 |
Quote: Quoting TheRyk only problem is there are just few useful routines in ROMs and the most useful (KERNAL CLRSCR) fills ColRAM differently on older ROM revs.
As Zyron pointed out a while back, you can safely use
lda #col
sta $d021
jsr $e536 on both old and new ROMs
Does NOT seem to work on the kernal rev (probably 1 or 2) that WinVICE uses per default when you set "C64 model" to "OLD NTSC". you can use my the compo version of Madmen + Machines to check. ColorRAM is not initialised with accu but totally garbled. will of course be fixed when it's first used for a crack. |
| |
Didi
Registered: Nov 2011
Posts: 487 |
LDA #color
STA $0286
JSR $E536 |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
old discussion on the same problem: $e544 ?
Disasming the various kernal roms it's clear what they did wrong.
rev 1 ALWAYS fills $d800 with 1 (white)
EA07 A9 20 LDA #$20
EA09 91 D1 STA ($D1),Y
EA0B A9 01 LDA #$01 <-
EA0D 91 F3 STA ($F3),Y
EA0F 88 DEY
EA10 10 F5 BPL $EA07
EA12 60 RTS
rev 2 uses $d021 color
EA07 A9 20 LDA #$20
EA09 91 D1 STA ($D1),Y
EA0B 20 DA E4 JSR $E4DA <- patch
EA0E EA NOP
EA0F 88 DEY
EA10 10 F5 BPL $EA07
EA12 60 RTS
E4DA AD 21 D0 LDA $D021 <- doh! wrong value
E4DD 91 F3 STA ($F3),Y
E4DF 60 RTS
rev 3 finally gets it done correctly
EA07 20 DA E4 JSR $E4DA <- patch first
EA0A A9 20 LDA #$20
EA0C 91 D1 STA ($D1),Y
EA0E 88 DEY
EA0F 10 F6 BPL $EA07
EA11 60 RTS
E4DA AD 86 02 LDA $0286 <- at last
E4DD 91 F3 STA ($F3),Y
E4DF 60 RTS
CCS 2.x was known to provide a weird rev.2 kernal but with the LDA $D021 patched with the correct LDA $0286, instead of providing the rev.3 kernal directly. |
| Previous - 1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | ... | 19 - Next |
