A.D.A. Amiga Demoscene Archive

A question about wos aimed at noname: i'm using two planar bitplanes in a 320*200*256 chunky screen by overwriting the bitplane pointers in vbi, as described in the chunky to planar thread:

move.l #planes,d0
move.l #320*200/8,d1
lea $dff000,a6
move.l d0,bplpt+$18(a6)
add.l d1,d0
move.l d0,bplpt+$1c(a6)

bss_c
planes ds.b 200*40*2

Now in my code, i do this:
lea planes,a0
move.l #$ffffffff,(a0)

I had expected that this short line would appear in the top left corner, left edge. However, it is on the first line, but not at the left edge.

This seems to put it at the left edge:
lea planes-1,a0
move.l #$ffffffff,(a0)

so in the first case, it actually is plotted at left edge + 1 byte.

Could there be any reason for that or something i'm doing wrong?

Can't see anything obviously wrong. I would expect your line to appear top-left as well.

problem solved

Is it possible that the symbol "planes" is located at an odd address?

The display DMA fetches data in 2-, 4- or 8-byte chunks depending on the setting in the FMODE ($dff1fc) register. Bitplane pointers are required to be 2/4/8-byte aligned in accordance with the FMODE setting.

What this means is:
If FMODE=3 then display hardware fetches 8 bytes at once, and the lowest 3 bits of the bitplane pointers will be *ignored*. So if you have written $12345 to BPL0PT, the display hardware will begin fetching from address $12340 (which is what you get if you ignore the lowest 3 bits in the previous address).

What you want to do is:
Ensure that the bitplane-pointer you use is 2/4/8-byte aligned.

The AmigaOS executable loader guarantees that all sections will be 4-byte aligned. Therefore, a simple CNOP 0,4 on the line before the "planes" symbol will ensure that "planes" is 4-byte aligned.

If you need 8-byte alignment, you need to do the alignment at runtime though. (i.e. your program needs to adjust to whether the entire bss_c segment got loaded to an address that is evenly divisible by 8.)
One way of doing that is:

move.l #planes+7,d0
and.b #$f8,d0
move.l d0,planeptr

This will take an address that is 7 bytes into the "planes" buffer, round it downward to the first address that is evenly divisible by 8, and then store it in a pointer.

Do the rounding once (at startup), and subsequently use the "planeptr" pointer instead of the "planes" label everywhere in the rest of the program.

Oh, and make sure that the 'planes' buffer has room for 7 extra bytes, too.

Just found the reason (before reading kalms post):
there was another "ds.b" definition right before my "planes ds.b" and no "even" in between, so yes, i presume that planes was located at an odd address (the one before that was a ds.l).

@z5: Could you please change the URLs to the release package in my previous posts to http://www.dig-id.de/amiga/Wos_v1.01.lha. I want to shut down the other domain at some point.

Thanks!

@noname: found and changed two links. I don't think there are more.

(wos specific question)

Maybe a daft question but imagine the following: i've got a brush that i want to move from outside screen left -> screen -> outside screen right.

The easiest way, it seems, would be to reserve an area of space outisde my visible screen (left and right side), put the brush there and move it every time + deleting where it was.

I seem to remember that i was possible to define areas larger than the visible screen with the modulo.

How do i set this up in the wos system. I have a 320*200 screen defined and i use SETMODE + DISPLAY. Let's say that i want 8 bytes extra at both sides.

I doesn't work like that with WickedOS (which gives you a chunky framebuffer). What you probably want to do is to add clipping to your brush routine.

I doesn't work like that with WickedOS (which gives you a chunky framebuffer)

In that case, i thought i could reduce the "copy size" proportionally with the distance from the border. Is that what clipping is about?

That's right, yes. Your case is really simple, so just take a piece of paper and work it out.

Btw., you could have investigated about the meaning of "clipping" for yourself by using the mighty Google or Wikipedia ;)

Clipping is simple but still a pain to code. So word of advice, make a brush/bob plotting routine you can reuse easily. It was only this year I finally got around to doing that myself. And now I hate myself for not doing it sooner.

Another Wos related questions aimed at noname:
i've got this scene running with various stuff happening. Sometimes, i just change colors (color cycle for example) so i only use the SETCOLS macro, without the two DISPLAY2's.

In the same scene, sometimes i do change the screen (for example deleting a couple of pixels) + i keep doing the colorcycling so i use SETCOLS, then DISPLAY2 (twice). However, my color cycling isn't as fast in this case, due to the DISPLAY2 macro.

In short, only using SETCOLS is faster than using SETCOLS + DISPLAY2. In this case, what should be the same color cycling speed in the whole scene, becomes different in both cases.

What can i do to solve this problem?

Doesn't sound very WOS specific. The DISPLAY2 macro no doubt does buffering, including C2P, which makes the overall loop slower, which affects the speed of the palette effect. You can do one of two things:

- Put the palette effect in the VBI handler. That way it gets run 50 times per second regardless of what else is going on. (Only put code in the VBI if you're sure it finishes in less than 1/50 s, or shit happens. Colour cycling is fine though.)

- Update a counter in the VBI. Then every frame, read it and reset it, so that you know how many vertical blankings (1/50ths of secondsethsth) have passed since you last looped. Then you just adjust the palette effect accordingly.

Second approach will give you a less smooth palette effect, but more control, so it gets easier to sort out flickering bugs etc. I'll let noname explain how to do one or both with WOS. :*)

Since I don't feel too much like explaining at the moment I just want to say that Dooms proposals are correct, but that I would generally prefer to do stuff in the VBI if I wouldn't even have a third possibility that I think is the best: music-pattern based triggering, a.k.a. Effecttracker.

At the end of the day a demo gets synced to the music. Effecttracker takes the inverse approach of the other two mentioned possibilites. Rather than trying to work everything out in the mainloop, you have events getting triggered at defined positions in the music-module. The result: exact timing to the beat and the option to quickly change the timing or update the effects that are being triggered!

So have a look at the /docs folder and read about it. I only had this system at hands for the Back2TheRoots demo and Yes! intro. Haven't used it in the intro as much as I would have liked due to a surprisingly early deadline, but it really helped me doing the flashes and jumps in the rubber-vector part towards the end of the BTTR demo.

The music can be used to trigger effects at the right time, but it doesn't help with the speed of each effect, e.g. how many seconds it takes for the palette to fade to black. You need interrupts for that, one way or another. Luckily it's easy:

Find the level 3 interrupt handler somewhere. It gets called exactly 50 times per second, out of context. Put this in:

current_lvl3_handler dc.l 0
.
.
movem.l d0-a6,-(a7)
move.l current_lvl3_handler(pc),a0
tst.l a0
beq.b .skip
jsr (a0)
.skip
movem.l (a7)+,d0-a6

Then split every effect into two processes, and put the pointer to one of them in current_lvl3_handler, e.g.:

my_effect_begin:
<some init code>
move.l #colourcycler,current_lvl3_handler
mainloop:
<effects working on chunky buffer> ; these can run at any framerate
<C2P and buffer switch>
<check mousebutton>
bne mainloop
clr.l current_lvl3_handler
rts

colourcycler: ; called 50 times per second
<your palette effect> ; must finish in < 1/50 s
rts

Eventually you'll want to time the chunky effects as well. If you do, say, a rotozoomer, you'd put the code that moves the camera (some sinetable lookups or something) into the VBI handler, and in the main loop you'd read off the position of the camera as often as you redraw the screen.

Maybe I got carried away while answering - interrupts are of course needed to complete the triggered fades, etc.. And because interrupts are needed in every proper effect, they are also easy to setup in WOS.


- where xyz is the label of the routine that you want to be called in every vertical blank interrupt
- saving the registers has already been done prior to calling xyz, so you wouldn't have to do it again in this case


- where oneoffroutine is something that you want to be called in the next vertical blank interrupt (similar to dooms proposal in the post above)

Here is a minimum interrupt skeleton:

Thanks for the great help. I'll try to get this up and running + use the effecttracker to start my routines.

In the meantime, it works. I've got constant palette cycling and fading (not so important here) while doing other stuff on screen. I use the SETCOLS macro here (which puts 256 colors into a color copper list, i assume). However, when i'm changing only a few colors (like in this case), would it be better to write them directly to the color registers or isn't that possible? And how will i know that my vbi routine takes longer than 1/50s?

(ps. hopefully yhe amount of questions will reduce soon :))

And still one question regarding wos (yes, i searched and read the docs first this time). I'm trying to include a P61 mod (the standard ones work, for example MUSIC=1) but it doesn't seem to work.

The doc mentions P61MOD Macro incbin mymod endm but where am i supposed to put this. does my mod need to be in fastmem or chipmem. And do i still have to use the MUSIC=1 (1=p61) at the beginning for non-included mods. Using MUSIC=1 and putting the P61MOD macro in, gives me a grey screen and i have to reset.

Not sure how WOS handles the palette, ie. directly to colour regs or via copper lists, but either way you waste a little time by updating more colours than necessary of course. Not much though, so you should probably focus on other stuff first.

1/50 s is a long time, so updating the palette is safe. You can safely play music (mods) from the VBI as well. A good way to test the time your VBI code takes to execute is this:

move.w #$0f08,$dff180
.
.
<your code>
.
.
move.w #0,$dff180

This'll set the background col (and border col, if border blanking is disabled) to a hideous pink while <your code> is running. It gets set at the beginning of vertical blanking, so you can measure how far along the screen the raster gets, indicating how long <your code> takes to execute. The entire screen (including max overscan) represents 1/50s. With just some palette changing, the pink probably won't even reach into the visible part of the screen.

If you get a flashing pink border, your code takes too long to finish (which causes VBIs to get skipped) and if you fill the screen half way, it means the VBI code is eating up half your CPU time (which also isn't always good). Try to keep it below 10 or so rasterlines.

Note that if col 0 is updated by the copper this won't work.

About the music, Idunno either. But mods go in chipmem as a rule.

when i'm changing only a few colors (like in this case), would it be better to write them directly to the color registers or isn't that possible?
You are doing assembly with full source. As a rule of thumb everything is possible. But i wouldn't care about this, yet. Don't optimize prematurely!

how will i know that my vbi routine takes longer than 1/50s?
Dooms advice with $dff180 is spot on. I might add that you could introduce a housekeeping variable that indicates whether you are currently already performing a vbi routine. So in case your routine is taking too long and the interrupt gets triggered again 20ms later, you would just read that variable and skip your routine in this vbi!

MUSIC=1
MUSIC tells the system which replay routine to include. If you want just P61, you just set it to whatever value P61 was (can't remember, probably 1). If you want to have all replay routines in your server, set all flags (15).

P61MOD
If you want other tunes than the default ones (I bet you want), you just set this macro. Sounds have to go to Chipmem of course. That is why P61MOD ensures exactly that. Have a look at line 3729 of wos_v1.0.s:


So in your case you need to set MUSIC and P61MOD accordingly. I don't know why you get crashes. Maybe your module is not in the right format. Try loading one of the supplied p61 mods using the P61MOD macro! If that works, try to find out why it doesn't work with the other module. A hex-monitor like FileX will be handy for this.

Keep going, you are getting closer!

Does your mod maybe use packed samples? In that case you have to use P61BUFFERSIZE.

from wos_infos.txt:

If you get a flashing pink border, your code takes too long to finish (which causes VBIs to get skipped) and if you fill the screen half way, it means the VBI code is eating up half your CPU time (which also isn't always good). Try to keep it below 10 or so rasterlines.

Hm... i've got a completely pink screen which flashes :( The more i put into my vbi, the more it flashes.

Apparently, after stripping down the code, it appears that SETCOLS is already enough for a pink screen. I tried the font example aswell, just put the two color writes in the vbi and i see purple aswell.

I can use the testmods with the macro so that part is ok. Must be a thing in the conversion of the mod, i think?

For the music, i use the converter supplied with the player 6.1A, version 610.4. The only preferences i've got checkmarked are "Tempo".

Ah. Ok I think I get it. One of the BPLCON registers sets the current colour bank (there are 8, to allow access to the whole palette via the 32 colour registers). I guess SETCOLS writes directly to the registers then, and switches through to bank 7 in the process. You want to reset to bank 0. I don't have any docs here, but my gut says you want to look at BPLCON3.

Regarding the music, IIRC the "tempo" feature (effects F20..FFF, right?) requires CIA timing to work. It might be that the replayer doesn't include the relevant code and then just crashes if it runs into a tempo effect (those players are never any kind of robust). In that case you have to set some constant somewhere to enable it. Also, for CIA timing to work, level.. 6? (I'm old): interrupts must be enabled etc., but I think TP6 takes care of that.

I am pretty sure the replayer is ok and guess it got something to do with the module you try to play. It it most probably a missing P61 signature (once introduced to hide the music in memory) or a missing packed sample buffer (as mentioned in a previous post). I also assume that the module is not crunched when you try to play it!

Come on, give it a go and try to find out why it isn't working. If all else fails you can send me the mod and I can convert it over here and tell you how to do it. But first I would like you to find out and learn for yourself.

z5: Just checked it on my Amiga and you also have to set the "P61A" sign in the preferences.
Out of curiosity: did you get the grey-screen on an emulator or a real Amiga? Because on my Amiga WickedOS pops out with an error message reading "Couldn't play module"

z5: Just checked it on my Amiga and you also have to set the "P61A" sign in the preferences.
Out of curiosity: did you get the grey-screen on an emulator or a real Amiga? Because on my Amiga WickedOS pops out with an error message reading "Couldn't play module"

I know. I checked the testmod with filex (great program btw) and i saw the P61A sign at the beginning. I then checkmarked it in the p61 converter prefs. So now i don't have the grey screen anymore (indeed, it's in Winuae) but i get noise instead of a proper mod. I assume i don't have packed samples as i haven't checkmarked this option in the P61 converter. So i'm not there yet but i'll keep searching.

On another note, when i exit my "demo", the music tends to lag (repeating a couple of times) when wos is doing en exit (again, this is winuae related).

@noname: off-topic: seeing as you still have a working Amiga and still seem interested in the Amiga and coding, did you never think about doing a comeback or is this a closed chapter? (sorry if i have asked this before)

on-topic question for noname: i'm close to figuring out the effecttracker, but i wonder about one thing: why can't there be any DISPLAY2 macro inside an effect called by the effecttracker? Even in the effecttracker example, when i put a DISPLAY2 macro in any of the four routines, winuae puts garbage on screen and hangs.

Another question: dc.l normal,0 in the effecttracker example: what happens at the second position (the 0)? Is the normal routine called again or is no routine called at that position of the pattern? And how do i maintain a loop then? I suppose it is in the normal routine itself that the loop should be?