Login

Forum Help Post Your Message ="hidden" name="cat" value="Programming"> Username: (Login) Topic: Message:   Previous Messages Posted By Lavina on 2005-06-20 03:24:26  Re: Upcoming Demo cummon guys, I think everybody should time his/her part and forget SPACE at last. Posted By bubis on 2005-06-17 08:36:02  Re: Upcoming Demo My two parts are 95% ready. Just waiting for music from a c64 musician and than I build them togethert. Ahh, there will be no loading between them. Posted By nukem on 2005-05-27 20:38:10  Re: Upcoming Demo +++ HOT NEWZ +++ Yeah! I finished my part just in this minute!! Hard work, 'coz there were many bugs and raster-errors. It isn't still perfect, but ya can look it! So, I'll send this crazy part to DCD. CUL8ER! Posted By Luca on 2005-05-27 16:55:34  Re: Upcoming Demo LOL, with forgotten password! Good job, Marcus, you're the 4th part that DCD will get! Posted By nukem on 2005-05-27 16:23:34  Re: Upcoming Demo yo, my (recycled) part is 98% ready. sum bugs that i don't find. maybe release this or nexxt night! Posted By Luca on 2005-05-26 07:49:04  Re: Upcoming Demo Ok, my part is in too. Posted By Luca on 2005-05-25 12:09:28  Re: Upcoming Demo Oh, well... Csio, if you have another personal precise deadline date, seems to be good... E.g., after my part is ready (today/tomorrow!), I have to compose some jingles for the IRQ loader, and push it into $e000 space. So, time will pass, but the best is keep the date of 31may!! Posted By Csio on 2005-05-25 11:57:52  Re: Upcoming Demo yes-yes, Luca! CSABO RULEZ!!!! DCS=dcd in hexadecimal Krona=chronos in hexa and so on...... my part is very poor in this time........but i hope the date 'may 31' will moving to june 12........ see you xxxx Posted By Degauss on 2005-05-24 20:33:11  Re: Upcoming Demo Mine is nearly finished aswell... Posted By Luca on 2005-05-24 14:57:30  Re: Upcoming Demo About me, I'm still composing my nostalgic tune, gimme a couple of days yet... Posted By Ati on 2005-05-24 13:40:12  Re: Upcoming Demo Nu, my part is ready! Posted By Luca on 2005-05-23 19:30:44  Re: Upcoming Demo Mmmmh, most of all, I don't see any DCS here Hey are you joking me? Posted By Csabo on 2005-05-23 17:36:14  Re: Upcoming Demo You mean you DON'T know DCS? He's a friend of Lákó, Króna, Ngga and of course Töpsöh. Get with the program! Posted By Luca on 2005-05-23 14:45:05  Re: Upcoming Demo Csio, who the hell is DCS? My part uses the spacebar to go on, and if you need compress/decompress memory for your effect, I don't see difficulties in using a cruncher. From the other side, if you simply had coded several parts matrioska-crunched, well, let load them separately! Personally, I don't see problems in use $FF81 kernel call.. DCD, wadda you say about? Posted By Csio on 2005-05-23 12:34:22  Re: Upcoming Demo OKAY DCS! we had it.... But what's with the BIT$ff19? and can we use the illegal codes? and what is the design? 1.get space to ready next dimension 2.timer countdown will kicks watcher's asseseseseseses 3. print rnd (x) and what about the crunching if i need decrunch while my part is running, but the memory is weak.....can i use any compressor? and can we use the jsr$ff81 when our part beginning? we are waiting your answear...... Posted By Luca on 2005-05-23 10:15:56  Re: Upcoming Demo Aha! I did them all, I did them all! Posted By DCD on 2005-05-23 09:39:58  Re: Upcoming Demo a new rule (recomendation): please, set up all used ted registers in your part, dont assume they have the default values. for example, its not sure that $ff14 will have the value of $08, when your part gets called thanx Posted By Csabo on 2005-05-18 21:35:37  Re: Upcoming Demo I had to reduce the number of your exclamation points... I hope you don't mind, the core of your message is still the same. Posted By Luca on 2005-05-18 18:36:36  Re: Upcoming Demo Hey, don't waste time killing the forum's page, but COOODE! Posted By Csio on 2005-05-18 17:00:05  Re: Upcoming Demo ahhh, what a llama question: Have you got anybody...... sorry, my mind is smashing .... Posted By Csio on 2005-05-18 16:58:09  Re: Upcoming Demo Have you got anybody a 'free-timer-switcher', cause i need it.......very-very much The may in my company is very dangerous ::: a lotlotlot-work So and here coming the june,........ah,my god I MUST CODE! DON'T SLEEP! CODE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! and i am angry cos no time to .......CODE!!!!! Posted By Luca on 2005-05-12 10:22:43  Re: Upcoming Demo Hahahaha, lol! I killed my synapsis in order to have a nested IRQs running part, and now... Posted By DCD on 2005-05-12 09:48:27  Re: Upcoming Demo it'll be an old fashioned press-space demo, therefore: - no global music, everyone should use his own music. - you should not code in nested irqs (no loading during parts, there will be a separate loader part) - you can use the memory from $10 to $dfff - jmp to $fcfd when your part ends happy coding! Posted By Degauss on 2005-05-12 09:09:31  Re: Upcoming Demo Erm, sorry, I meant: How much RAM should be preserved for the *next Part* (not the IRQ-Loader) Posted By Degauss on 2005-05-12 08:51:39  Re: Upcoming Demo Ok, seems that i can make it until 31.05. So: I'm in! I can get along with putting everything in nested IRQ's but I still have some questions concerning the Framework/IRQ-Loader: - Will this be a PART - SPACE - PART - SPACE - Demo or is it supposed to be more like a Trackmo? If it's ought to be Trackmo-like: Will there be a "global" Music? If yes: JSR $1003 or where to? - Is there any suggestion about how much RAM and CPU-Time should be reserved for the IRQ-Loader? E.g. 16KB, half a screen every 2nd frame? (Sorry, no experience with that...) Posted By Luca on 2005-05-10 19:40:10  Re: Upcoming Demo Ah, I'd forgotten, Murphy and ATI (la creme de la creme!), how it had to be possible? CSIO, and you? Posted By Luca on 2005-05-10 11:49:40  Re: Upcoming Demo I'd like to suggest that, if your available coding time is too short, you could present one of your just known fx in a brand new fashion. Better older than missing. At the moment, me, DCD and bubis are the most sure participants. About me, I only have to compose the dedicated music (today I'd to code the fadeout, but I was lazy and the sun outside was inviting; I'd only written some quick code during lunch, and, dunno why, the global stuff works well...). A list of "dunno, probably, I'll try" will follow, with different probability percentage: Dr.Death/TEK,TBH/TDC and others that probably don't wanna be named. Probably, we need to scream toward the "Tokai zone" of the +4 (TLT, Skoro, maybe Sensor), because we're not sure they know about the demo. 31 May is THE date at the moment. Posted By Degauss on 2005-05-10 03:06:41  Re: Upcoming Demo Ok. I'll see if i can put something together until 31st. Thank you Posted By bubis on 2005-05-10 02:40:20  Re: Upcoming Demo No, it is not fixed as I know but there is no guarantee that u can take part if u send your part after may. So u better take it seriously. Posted By Degauss on 2005-05-10 00:49:48  Re: Upcoming Demo Erm, eh. I'd probably like to take part, but i don't know if i got enough time to do so. Is 31.05.2005 a fixed date? Posted By Csabo on 2005-05-09 16:20:27  Re: Upcoming Demo Maybe the question should be: has anyone contacted them? My guess is that Skoro and the TLT team don't have internet connection at home, so they may not know about it. Posted By Luca on 2005-05-09 12:34:21  Re: Upcoming Demo Who contacted Skoro and the TLT in order to have a part? Posted By Luca on 2005-04-28 09:08:11  Re: Upcoming Demo Nested IRQs? I'd written the EOR instruction yesterday for the very first time, while you were talking of nested IRQs! Posted By DCD on 2005-04-28 03:29:02  Re: Upcoming Demo ok, i knew i should have answered earlyer to bubis's post however it's possible to code a demo, which loads next parts during the actual effect (using nested irqs), it's very difficult to do it in a cooperation demo, where several coders make his own part separeted from each other. let's take an example: coderA contributes with partA, coderB with partB. partA uses memory up to $d000 (loader from $e000!), only $d000-$dfff is free to load. i should force coderB, to make partB be able to compress down to $1000, so partA could load partB while running. mission impossible. i think irqloading during the effect is a nice idea for a oneman show, but not the way a cooperation demo sould work. btw, if you plan more than 1 part, you may use nested irqs Posted By Luca on 2005-04-27 13:32:15  Re: Upcoming Demo Oops! OMG, I'd thought, that way isn't a full IRQ running code! In facts, if I try to avoid the endless loop (JMP itself), the whole stuff runs at a crazy interrupt timing I guess I did something very stupid then... Posted By Csabo on 2005-04-27 13:16:28  Re: Upcoming Demo If your demo/whatever runs completely from IRQ, all you have to do at the end of your initialization routine is to do a CLI (to let them run) and JMP * (endless loop). Posted By Luca on 2005-04-27 13:07:00  Re: Upcoming Demo I played a bit in the direction of running a program via IRQ only: some settings at the beginning that pass to IRQ all the job. It means that all the code runs at IRQ timing, after the initial code, and this initial code must start the IRQ waterfall. In order to do it, the setup code must finish with a RTI, or a BRK, or a nested JSR, and playing with stack and counter in order to make it works. I tried lotta choices, but no one, had worked. Hence: which's the secret within? Posted By Luca on 2005-04-23 14:54:54  Re: Upcoming Demo ...and I still have problems in music play...maybe I had to handle $FF09 when calling the IRQ without using an irq (simply JSR$1003 and SIDcard shifting). Posted By Luca on 2005-04-23 14:08:16  Re: Upcoming Demo "LOD is back!" source seems to be quite difficult to be read by me, I tried but I'm not skilled enough. Today, I played managing a moving rasterbar, and I had my difficulties, though I got the $FF1E checking stuff. Finally, I was half happy and half discouraged, cause the timing facts. In "Lameness" I used a raster editor in order to draw the bars, but I would do them by myself, in order to learn. Things I caught: there should be a rastertable, containing $FF1E screen level and most of all, times that the bar is drawn in that $FF1E height (that's like a "waiting bar"). If you have more than one bar, once both had been drawn, the very last is the frontward one. The bar moves, but I have to change the $FF0B for it, and the bar's thickness changes during its move ($FF0A missing bit facts?). Often, there are some glitches (do I need some NOPs?). Bah, it continues to be a big mistery for me, so mani issues... Posted By Csabo on 2005-04-23 10:49:44  Re: Upcoming Demo Yes, if you want to have a main program running beside your IRQ, you have to save any registers you use. (If you only use A and X for example, it's enough to save those.) Also, you don't have to use the stack, it's very common to save the registers to a 16 bit address (lame) or a zeropage address (best for speed). If you don't have a main program, you don't have to worry about any of this though. Remember, the source for LOD is Back is also released to the public, it has tons of effects and tricks, all fairly well commented. Posted By Luca on 2005-04-22 19:12:18  Re: Upcoming Demo Ah I understand... Csabo, I watched the sample2.asm file you released with Plus4 IDE, and I was surprised by the AXy storing at the beginning of interrupt routine: I hadn't do it! I guessed that AXY registers were automatically stored in the stack when ai IRQ happens! Posted By Csabo on 2005-04-21 16:52:02  Re: Upcoming Demo It's pretty simple. Let's say the letter "A" is made up of characters 1,2,3,4. Then letter "B" is made up of 5,2,6,7. (See, they share one character... But O and U for example could share the bottom two etc.) You would simply store this as a "table", just some bytes after another. table DB 1,2,3,4 DB 5,2,6,7 When you want to print a 2x2 char on the screen, let's say the character is in "A": ASL A ASL A ; multiply by four for the lookup TAX LDA table,x STA (screenpos) LDA table+1,x STA (screenpos+1) LDA table+2,x STA (screenpos+40) LDA table+3,x STA (screenpos+41) Something along those lines. Posted By Luca on 2005-04-21 12:22:29  Re: Upcoming Demo Which shape a lookup table has? I imagine a series of cmp/bne instruction: load the next char to be printed, then a gigantic LM list distribute the correct chars (that's the way that LNeditor used to). Posted By Csabo on 2005-04-21 12:01:29  Re: Upcoming Demo It's definitely easier to code a 2x2 scroll that uses the restriction you've mentioned (basically you output the original char + OR $40 + OR $80 + OR $C0), but you don't have to. You could use a character look-up table. In LOD is back, the hidden part has a 2x2 font. It's not scrolling, but it's an example for lookups. (The reason of doing it that way of course was memory limitation.) If you use the 5x8 char editor, you can edit lots of sizes, AND it will make an actual scroll routine for you! All you have to do is use that code and call it. Posted By Luca on 2005-04-21 11:05:47  Re: Upcoming Demo Well, bubis, I tried the asl$ff09 lda#$xx sta$ff0b in the Lonenews Editor intro for the very first time, following some talking sessions I had with DCD. The results had been mmmm....bah, average: the stuff runs, but I'd tried to better animate all the stuff via irq, and *dunno why!*it hadn't worked. Hence, I decided to stop the experiment at that reached level. We'll see, but watching the facts from my personal point, this is, as it is, a big quality jump for a llamah like I am. I never tried to code a scrolling text. Well, I tried years ago, but probably the timings are wrong, cause all my attempts had shown occasional "jelly" moments during the scrolling. Probably, I must NOP that code manually (a series of NOPs instead than a NOPloop), and that would mean this is the very last thing to set, after alll the other stuff run. I also think that, e.g., a 2x2 chars scrolltext needs a fully correspondant ASCII charset (where "a" stays for upper side of "a" and "a"+#$40 for lower side of a, etcetera), using a smart ORA#$40 for the lower line. Because of this, I also suspect that 2x2 charsets are done as follows: #$01----> XX <----#$81 #$41----> XX <----#$C1 Auff, whu I got so much lameness over my shoulders!? Service Communication! Service Communication! Service Communication! O Mister X that asked me for a logo: the job is done, I could send it via email but I prefer to give you the stuff personally. So, plz, contact me via ICQ, for examle! You'll like it! Posted By bubis on 2005-04-21 08:00:05  Re: Upcoming Demo Yes Luca, I think u got the point. The main idea is that if the program (demo part) execution is in the irq then the "main" program can load form the disk with a proper loader (so called irq loader). That's all. But it is not necessary to separate every task into separate irq routines. U can do the sid playback and the effect in one irq for example. And an other nice trick is nested irq-s: when u call a CLI in an irq routine allowing other irqs happen to manadge smaller tasks (like raster effects or a scroller), but I dont want to overload your brain... Posted By Luca on 2005-04-21 06:33:50  Re: Upcoming Demo *effect ... irq scrolltext lda #$80 sta $ff0b ... *scrolltext ... irq music lda #$90 sta $ff0b ... [CPU is free until $ff0b is #$e0] *music ... irq effect lda #$e0 sta $ff0b .. Posted By Luca on 2005-04-21 06:30:22  Re: Upcoming Demo Bah, the 3rd point sounds confusing for a lamer like me Probably, it means that all the subroutines call each other with IRQ assignment+a flag placed on $ff0b: it means I had to divide the screentime in order to run music routine for a timeslice (let put, e.g., #$20), another timeslice, e.g. ,for a scrolltext (dunno how much), the rest for an effect (dunno how much). It would show as follows: *effect *scrolltext *music ... ... ... irq scrolltext irq music [CPU is free irq effect lda #$80 lda #$90 until $ff0b is lda #$e0 sta $ff0b sta $ff0b #$e0] sta $ff0b ... ... ... Am I right, in a general view? I guess I can't code the classic Terrorists'demo, with music and scroll, but I would. One idea is to code a lame stupid stuff, showing the logos drawn during 1hour logodraw compo at 4ever03... Posted By bubis on 2005-04-21 02:51:44  Re: Upcoming Demo 3+) Ahh, and leave the CPU alone for a while. Posted By bubis on 2005-04-20 11:05:31  Re: Upcoming Demo Some more important/usefull infos: 1) DCD takes care of the compression, give them your part uncompressed. 2) When the part ends, jump to $fcfd. 3) Try to organize all the executed code into irq routines if u dont use all of the available memory. This makes possible to load form the drive during your part. 4) DCD's ICQ uin for consultation: 79402253 5) I can help as well if not too busy (icq:24418272; skype:andras.dotsch) bubis Posted By Luca on 2005-04-18 09:34:15  Re: Upcoming Demo Personally, I'm ready: all the ppl can ask me about original music and graphics for their parts. I'm just drawing a logo for...eheh. Posted By Csabo on 2005-04-18 09:10:42  Upcoming Demo As the readers of the Hungarian forums already know, DCD is organizing a new demo project. This was supposed to be released for the 20th bday of the Plus/4, but it's going to be a bit late... It would be something like the Cracker's Demo series. Anyone who feels like is invited to contribute with a demopart. The details so far: - Confirmed participants: bubis, Murphy, Ati, Csio & DCD. - Tentative deadline: 2005.05.31. - Technical restrictions: don't use memory above $E000 (reserved for loader, etc). You can contact DCD or use this thread to ask questions. Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon