A.D.A. Amiga Demoscene Archive

Alright, cool. Stick with the v1.29 then! It is certainly "good enough" to code demos with it. I used it all the time and so did many others.

And I wouldn't worry too much about newer ASM-One versions. There is probably no advantage as the progress between version was always very little. Sometimes they even made negative progress. I remember that parts of Mnemonics had to be assembled with v1.25 because later versions didn't correctly assemble Fastjacks sources (which used bfins or sth.)!

oh, and as written in wos-infos.txt:
- you can now set the ISREADY flag, assemble and write the effect to disk.

- you can also run the packwos script on that file so compress the executeable if you want to (it's not required)
- then use that (packed or unpacked) effect in the linktest source

- do some fading, add some music and you have your first intro!

in the meantime, i've got my own fading routine in place, but i have quite a few questions.

I used the example above (SETMODE, DISPLAY2) then i add my fade routine in the checkexit loop. My fade routine consists of a 256 color loop.

It seems that i have to use SETCOLS each time to see pallette changes on screen. Is that correct?

doloop
do fade
SETCOLS
go to doloop

Also, the whole issue of timing pops up again. My fade routine loops 256 times. When is this loop executed and how fast? And how can i be sure that the loop is finished when the Amiga starts putting the picture on screen? Am i correct in saying that my main loop is started 25 times/second (using DISPLAY2) and starts at the vertical blank interrupt?

Also, my fade routine was too fast if i added / substracted 1 each loop. How do you guys put speed into a fade? I have put a timer into my fade routine so my fade routine is only executed when my counter is at his ending position.

Is there a macro to check if the left mouse button is pushed?

And what is the story about the whole double/triple buffering issue?

It seems that i have to use SETCOLS each time to see pallette changes on screen. Is that correct?
That is correct. The SETCOLS macro converts your colour-table into copper format and writes it to the current copper list. This has of course to be redone for each colour change.

When is this loop executed and how fast?
This loop is the MAIN program. It does not get executed by some other routine. It is this main loop that calls other subroutines (e.g. SETCOLS, DISPLAY2, yourCool3DEffect).
I am not sure if I understand your "how fast" question but I guess you mean this in regard to the frame-rate. In that case the answer would be: the main routine is running at different speeds on different processors. You wouldn't want to time depending on the processor speed. That's why there are the DISPLAY1 and DISPLAY2 macros. The work as fast as possible up to a certain frame speed. DISPLAY1 is for 1 frame routines (50 fps) and DISPLAY2 for 2 frame routines (25 fps). You have to know that 320x200 256 colour c2p (+ an effect) can not run at 50 fps so you should always pick DISPLAY2 for this mode. DISPLAY1 only makes sense for 320x100 and 160x100 (256 cols,). HAM8 needs 2 frames again.

And how can i be sure that the loop is finished when the Amiga starts putting the picture on screen?
There won't be any picture changes until you reached the DISPLAY2 call. And this only happens if your loop is finished.

Also, my fade routine...
If you only want to fade in/out from black, you could just use the SETCOLS macro. It comes with a brightness parameter which gives nice results, even when you want to make a fast fade.

Is there a macro to check if the left mouse button is pushed?
CHECKEXIT should be used for that. It also senses the <ESC> key and its behaviour can be controlled by setting the NOESC, NOLMB and NORMB flags.

And what is the story about the whole double/triple buffering issue?
Double Buffering is needed to make a computer animation smooth. I suspect you know this otherwise read about it. It is an essential concept! It is basically about only showing the results of a drawing operation and not the drawing operation itself (you might know single buffered picture viewers where you can see how the picture is drawn, which sucks).
A tripple buffered screen just needs a third buffer to make the final picture. In the case of WickedOS this is because for 68020/68030 based Amigas it is faster to do the c2p with the help of the Blitter. In the first pass the buffer gets converted (a bit) and copied to the chip mem. Then in the second pass the Blitter converts that intermediate buffer into the final picture for the next frame. At the same time your effect will already be filling a new buffer. I know it might sound complicated

Still a few questions (hopefully not many anymore :)):
my question about a macro for checking left mousebutton wasn't clear. What i want to do is have a main loop with all my "tests" after each other, but you only go from one effect to the other if the mouse is pressed. I tried with CHECKEXIT like this:

loop1
checkexit
beq loop1

loop2
checkexit
beq loop2

exitwos

But that doesn't work. The second loop isn't executed and it quits (because checkexit is still "true").

The second question i have. I'm trying to get my brain in "chunky" mode but stumbled across the following problem. If i convert a 16-color picture to chunky format, i get 1 byte per pixel (which is standard for chunky mode to make things easier). However, my converted 16 color pallette (converted as 8-bit in piccon) only gives a 16 color pallette.

Now if i do SETMODE,#pic,#pal, my picture is assuming 256 colors but i'm pointing at a 16 color pallette. Should i, by standard, always work with 256 color pictures?

What i want to do is have a main loop with all my "tests" after each other, but you only go from one effect to the other if the mouse is pressed. I tried with CHECKEXIT like this:
Alright, in that case you would want to do it differently because the CHECKEXIT signal will stay true after the mouse or ESC have been pressed. Let's assume you know how to check for the mouse for yourself (look into the source) you can then modify the CHECKEXIT behaviour to make it not react on mouse buttons. You do this by setting the NOLMB and NORMB flags.

That said, you should consider using INCEFX, DEFEFX and CALLEFX macros before you start gathering huge numbers of different effects in one source code. I am not saying you should do it right at this point, but bear in mind.

but i'm pointing at a 16 color pallette. Should i, by standard, always work with 256 color pictures?
I would say yes. It doesn't really matter if you saved your pic in 256 cols since it just used 16 anyway. The only difference would be that the palette would have been of the correct size. Right now it would work even with that 16 colour palette but the colour converter would read beyond the end of the palette and this is generally dirty. So just save your chunky pics in 256 cols and you are fine. Also there is no speed gain if you use 16 colour pics on a 256 colour chunky to planar (c2p) routine.

Apart from the 256 colour c2p modes there is also a 64 colour c2p mode and a truecolour HAM8 c2p mode. Have a look at them at a later stage.

z5: About your problem with asm-one and crashes when trying to start your effect with j, did you try to increase stacksize? I had the same problem with very large sources once and I just increased the stack and everything worked like a charm then.

Thanks for the help, noname! That should get me going for a while. Surely i will use CALLEFX later on, but i don't have anything yet :) (unless you consider a whipe an effect). So it's just for a bit of testing.

I must say: the system of bitplanes was far more logical in some cases so i'm still thinking about chunky. My first "project" would be: fade in a picture, overlay a brush on it, fade out the brush and then the picture. Seeing that i can give a color offset for my fading routine and did set up halfbrite pallette last year, that should give some interesting opportunities. Still have to figure out a way to impose one graphic over the other, which was extremely easy in bitplane mode. But i'll search myself before asking.

In any case, WickedOS is a great system for newbies. Within minutes, you can assemble an example and actually see results on screen. Which is great. Cool stuff.

Though assembly language and democoding still seems "plunging into the very deep and dark" for me. It's incredible and completely mad that such fantastic demos can come from it :)

I tried increasing the stack but it didn't work. Can anybody actually test if you can execute wos examples from within Asm-one v1.48?

Actually, asm-one v1.29 doesn't really like my system.
It crashes:
- when i touch the numpad
- when i do a search
- when i try to debug a wos example (crashed on the include wos.i, address not found),
- ...

so i lost quite a few bits of code due to that. Accidentally, i read somewhere that v1.29 doesn't like a 68060 :(

Little question: how does the CLEARPLANES macro work? It doesn't take any variables so how can we say where the screen buffer is located?

asm-one v1.29 on 060:
i used asm-one on an 060 but switched over to asm-pro because it was able to use my graphics card for a higher resolution in the editor. i have seen asm-one crash sometimes, mostly while scrolling page-wise with shift-cursor. but this didn't happen on a regular basis. i never used the debugger on wickedos (afterall it kills the system) and wouldn't expect it to work great. actually, being able to use the debugger would have been the only reason for me to implement system-friendly screenmodes. but i still liked the workflow with asm-one/-pro good enough to not change anything.
the solution for you might be to try another assembler that works for you. devpac, oma and phxass are all really good. since they are all commandline driven (with some additional editor/debugger on top) you can also use any other editor that suits you. many people liked cygnus ed which is a professional text editor that doesn't crash. you can even use emacs, if you wish. i think i saw loaderror using phxass on some mekka party. maybe it's worth asking him for his setup.

clearplanes macro:
you have the full sourcecode and could have looked for that by searching a bit for yourself (obviously with another text-editor ;)
but afterall, CLEARPLANES is nothing important. it just cleares the bitplanes in chip-memory where your chunky buffer gets converted into. the bitplanes are allocated and managed by the system so the macro doesn't need to know any parameters. you don't need to call this unless you find some glitches on your own multi-effect demos!

z5: I just tried to execute a WOS example from within asm-one v1.48 and I didn't have any problems doing it. So I guess you might have some patches running that confuse asm1. Also, do you start asm1 from the icon or do you start it from a shell? I need to start all versions of asm1/pro from a shell since otherwise a lot of weird bugs occur. You might try that as well, maybe it solves your problems.

i'm starting asm-one from icon. I will try to do so from shell. Honestly, i don't have a lot of patches running. I do have oxypatcher but that is the only one i can think off. Thanks for trying!

i would have assumed as well that you started asm-one from shell!
there is a batch in wickedos archive at s/asmone that you could modify to your needs. it starts asm-one with a given amount of memory, sets a working directory and opens the file requester for loading.

maybe it's worth mentioning that i can wholeheartedly recommend having the kingcon shell replacement. kingcon (kcon) gives you filename completion (or requesters if multiple names match) and a scrollable buffer.

in combination with MultiCX and MUI_MCX_Prefs it is really easy to define a CLI pop-key (that is: you press a button and get a new (kingcon) shell). this is probably the feature that i like best about my amiga and about the first key combination that i press after boot.

my PopCLI settings
hotkey: lamiga esc
command: NewShell window=KCON:20/118/580/300/Popup/CLOSE
stack: 4096

hope this helps.

KCON is indeed pretty cool. I also have my "open shell" hotkey but I am using MCP for that since it is so much better than Multi-CX, even though the Multi-CX coder loved to say the opposite in his MCX doc. :)

Well, starting asm-one from the shell did the trick...

noname, are you still around?

Does anyone know what "No Operand Space allowed" means in Asm-One?

I think you should remove spaces after commas, like in

move.l (a0,d0.l), d0

where you can't have space after a0...

I actually tried to compile the font example supplied with wos using Winuae and Asm-One 1.48 (at one point last year, it compiled with Asm-One 1.48 on my real Amiga) and i got this "No Operand Space allowed" error. I really don't know where to start searching for a solution.

Has anyone ever managed to compile the wos examples on Winuae?

ps. I use Winuae because my real Amiga has a non-working disk-drive, a non-working right mouse button, a dodgy harddrive, a worn-out monitor and it's stored in a cold place.

ps. Me trying to compile this has no meaning. I suck at coding so i won't try again but i would like this thing working anyway :)

Have you tried using the supplied assembler and settings from the ENV folder in TOSYS? I vaguely remember that I put the settings in there for compatibility reasons. Might be worth a try.

And yes, definitely had it working in WinUAE!

Have you tried using the supplied assembler and settings from the ENV folder in TOSYS? I vaguely remember that I put the settings in there for compatibility reasons. Might be worth a try.


I did try that first. Asm-one 1.29 with the supplied prefs. But asm-one was acting strange on winuae: i could not see any text on screen, no matter what screen resolution i used. So i had to take 1.48 instead (worked with wos on my real Amiga).

What i did was fairly straightforward. Started from a clean out of the box Amiga Forever workbench 3.1. Followed all the instructions and made the necessary assigns. That's it. But then i got this error code.

Last thing to try: look at my prefs file on my Amiga (as my disk drive is broken, i can't copy it).

To be a bit more precise, i get the following error code when trying to compile the font.s file in examples:

(after a bunch of includes):

"In file WOS:WOS_v1.0.s (line: 389) >> dc.l 0 : sprlist (dummy)
16 include wos.i"

I no longer know the ASM-One interface and error messages by heart, but I am quite sure that your problem has got something to do with the settings of the assembler. Try different combinations of the settings to the right in the "Assembler Settings" (or similar) window. Look for the "comments with ;" option as well.

Basically you have to try to replicate the settings that I used as shipped with the release.

I configured the prefs exactly like on my amiga and it works :)

However, when i compile the font example or my own "show picture" example as explained earlier on in this thread, all i get is a black screen.

On a sepearate note, is it possible to run asm-one in a window on workbench. My pc is switching screens and resolutions like mad.

One step closer: the font example works :o)

and so does my picture.

I get the "no operand space allowed" when i checkmark ; as comment in the assembler preferences.

I have one last question though, aimed at noname. I have typed the exact same code (to display a picture) as found in this forum (see start of thread) to display a picture.

When i assemble and run a first time, all is well. From then on, when i assemble and run, i'm greeted with a grey screen, which stays until i press the mouse button. Only then, the picture is shown as normal. A second mousebutton press returns me to asm-one.

Is there anything you could think of, within wos, which explains that behaviour. I actually see the grey screen when running the font example aswell, but only very briefly and then it starts to fade from black, showing the font text as normal.

edit: after some more testing, it doesn't actually happen all the time but sometimes.

Sounds strange and could have something to do with WinUAE. Try tweaking your settings. If all else fails, you could post a screengrab showing how you produce that behaviour.

Hardware screens are tricky, especially in UAE and especially with copperlists. My advice, which is hardly relevant since you're using someone elses demosystem :), is: If your copperlist doesn't do anything besides setting the display window etc., don't use a copperlist. There's just no point complicating that with unnecessary race conditions, so just do it all with the CPU during the VBI.

I can have a look at WOS when I get home tonight. It sounds like it doesn't properly suspend the OS.

I have the impression that whenever i run something, wos always shows a grey screen initially (even in the font example). However, sometimes it goes away immediately (meaning i just see a very quick flash or nothing at all), sometimes it doesn't go away and i just see a completely grey screen. In that case, i just have to press the mousebutton once and then the "demo" starts.

It's not a major issue. It just means that i sometimes have to press the mousebutton once to see the effect running. I'll try to experiment a bit more to see what's happening.

Actually it's probably a UAE problem after all. I see this a lot - UAE doesn't receive the "mouse button release" event if it arrives during resolution switching (window closes/opens), which for demos tends to happen right about when you're releasing the mouse button. So the button "sticks" and must be pressed once before another release message can be received.

My guess is that WOS delays starting the demo until LMB is not pressed (so it won't exit at once if it's started by a mouse click somewhere). If that's the case (and I'm fairly sure it is), the solution is to not restore the OS screen until LMB is released.