A.D.A. Amiga Demoscene Archive

Anyone familiar with this phenomenon:

main:
checkmouse (and jump to exit if clicked)
dostuff
jump to main
rts

exit:
blabla
rts

what happens:
- run => dostuff is executed
- click mouse => back to asm (okido)
- run again => dostuff isn't executed: the click mouse button is true without clicking => directly back to asm

It is as if the click mouse button is still true after clicking it once. Tested on winuae + asm-one. The only solution to get the dostuff back, is to click the mouse once in asm-one, before executing again.

Can't recall ever having run into this problem. At first it looks like a bug in WinUAE, but I wasn't able to reproduce it myself. What does your code look like?

z5: i assume you probably didn't assemble the source again (and maybe used wickedos)?

it is possible that your first program run already set the exit condition to some memory location. then if you don't re-assemble the source this memory wouldn't be reset before you run the program for the second time and thus the program might directly jump to exit due to the intercepted exit condition from the first run.

btw: rts after a jump will never be executed. also i would personally check for exit condition after doing stuff, but that is only a matter of taste.

The problem is in communication between the Windows mouse driver and WinUAE, it doesn't have anything to do with Asm-One or your code. When you press the button, the driver sends a "button pressed" message to the window that currently has the mouse focus. When it's released (or the mouse pointer leaves the window area, etc.), a "button release" message is sent to the same window.

When WinUAE is active, the mouse focus is locked on the child window displaying the Amiga screen. Press the button and that window gets a "button pressed" message, which UAE then uses to update its emulated mouse button state. It all goes wrong when pressing the button causes WinUAE to switch resolution, as is the case in most demos and in your example above, because in doing so WinUAE destroys the child window that received the "button pressed" message and replaces it with another one. The driver won't send the "button released" message to this new window because it doesn't know that it's supposed to. The message is just lost.

So bottom line is, UAE is never told that you've released the button. A proper fix to WinUAE I guess would be pretty complicated, but you can always work around the problem like this:

begin:
- set demo resolution

main:
- jump to exit if LMB is pressed
- render infinite sinescrollers
- jump to main

exit:
- jump to exit if LMB is pressed <-- this delay is teh fix
- unset demo resolution
- rts

or the mouse pointer leaves the window area

This of course doesn't actually trigger a button-released message.

@doom: thanks a lot!

Can somebody give me the offset value for _LVOCacheClearU or point me to the place where i can find it?

seems it is -636(a6)

(via http://www.mways.co.uk/amiga/howtocode/text/genera lguidelines.php which contains a webified copy of the howtocode tutorials)

One more question: i'm trying to integrate kalms c2p into my startup routine. First, i try to load the c2p routine (c2p1x1_8_c5_030_2.s, why are there two versions by the way? one without and one with _2 at the end) and compile it. But asm-one gives me the following error:
Undefined symbol: beq .none (while .none is defined just before the rts at the end of the routine)

The second version is further optimized and faster, and it does assemble fine under Asm-One 1.48. I would guess that you accidentally removed the local scope period sign from one of the other labels in the code and made the .none symbol local to there and thus giving the error message.

Labels with a . in front are local and their symbol name can be reused under a different global label

;----------
global_label
move.w #1000-1, d0
.local
move.w d1, (a0)+
dbf d0, .local
bsr.s routine
rts

routine
move.w #1000-1, d0
.local
add.w d2, -(a0)
dbf d0, .local
rts
;----------

Removing the . from .label below will make it a global symbol and thus making the .exit local to there

;----------
global_label
cmp.w #50, d1
beq.s .exit
moveq #3, d1

.label

.exit
rts
;----------

@zeroblue: c2p1x1_8_c5_030_2.s doesn't compile "out of the box". Other c2p routines do (like _040). I have a feeling it has something to do with smcinit. Can you actually do c2p1x1_8_c5_030_smc1 equ *-2 within a routine? I compared to the same c2p routine included into the kirchoff demosystem (from dalton) and smc_init + all smc equ's were commented out.

The problem is with local/non-local labels.

Code looks like this:



For some assemblers, the 'equ1' symbol does not occupy the same namespace as regular labels. Then '.label2' is within scope from where the bra.w is located. It is visible from the location of 'label1'.

For assemblers where 'equ1' occupies the same namespace as labels, the label '.label2' will only be visible from the location of 'equ1'.

Solutions:

1) make 'equ1' a local symbol
2) make '.label2' a global symbol

Ok. It works. Thanks!

situation start:
- startup/shutdown code + P61 replayer
- assemble => black screen + 1 pixel + music => ok

situation 1:
when i include the c2p source, after including all the rest, before starting my own startup code:
- assemble => ok, no errors
- execute => no black screen, asm-one immediately shows the content of my registers (D0,...), no error though => what's going on?

situation 2:
when i include the c2p source + call the c2p init routine (before my startup-code):
- "relative mode error" on the bsr c2pinit => what's going on? (google doesn't know relative mode error)

relative mode error: Some instruction is trying to make a relative reference to a symbol in a different section.

Example 1:


Here, the bra.w will try to record the location of 'sym', relative to the current PC.

Example 2:



Here, the first dc.l statement tries to record the difference between the two symbols.

The reason why the above constructs won't work is that the AmigaOS hunk loader can load sections independently of each other, and thus the relative positioning of different sections is not known at the time of assembling.

To work around this, you use absolute references (jsr instead of bsr, for instance).

In your example (situation 2), the c2p code resides in a section different from the section your init-code resides in.


As for situation 1, recall that when AmigaOS is loading+launching a program, it will normally start execution at the first instruction in the code section. Does your main program look like this?



In that case your program will begin executing at the first instruction inside of c2p.s which happens to be the c2pinit function. This function only does a few lines of computations and then returns. The RTS there will terminate the program.

So you need to make sure that the first instruction in your program really is part of its bootstrap sequence. (Preferably by re-ordering INCLUDE statements, or by moving the INCLUDEs for subroutines (such as c2p) down to the bottom of your main source.)

Alternatively you could also put a "jmp mystartuplabel" before the include lines to jump over them. in that case you migth want to define a new code section just before "mystartuplabel:" to make sure it gets what it needs and doesn't accidently end up in whatever section has been created by one of the included sources.

Having all the includes together above any self-written source-code would be the neatest solution. Can you actually do this without jumping over the includes and without actually changing the includes themselves? Kalms hints at "re-ordering" but i can't see how this can be done.

Is there any website/info that deals with sections, alignment and stuff like that?

Btw. my c2p now works. There's something trashing my 8th bitplane though (the c2p conversion has nothing to do with it). I vaguely remember having the same problem a long time ago but i'll try to find the cause myself first :o)

z5: no.

You currently have something like this which is quite fragile:



I normally use this, which is C-inspired:



but the following would be equally flexible:

Interesting! Two questions though: can you have more sections with the same name? What is actually the importance of section names anyway? And assuming that i use the last way, how do i deal with the fact that the includes can have sections aswell (for example the c2p has two sections)?

Yes. Sections with identical names get merged.

So, structure each .s file such that all instructions & all data written inside of that .s file end up in the correct section(s), regardless of what might be hidden inside of some INCLUDEd file. Basic idea: After you have INCLUDEd another .s file, you need a new SECTION directive.

Everything seems to be working. I've got 610.4, c2p, pal (my palette routines), startup (startup+shutdown) included at the beginning, using the jump method. I also have a copperlist included near the end (in data chip mem).

I had a relative mode error when using start, presumably because "start" is also used as a parameter within the P61 replayer (the pattern where you want your module to start, so it seems) so i used begin for my code.

The code is already much better organised than before.

One last question about sections. Is there any point at all in creating sections with different names, if the type (code, data_c,...) is the same? For example, i now have a section copper,data_c and music,data_c. Does that have any actual advantage/use/...?

If your question is if it's better to split the data into separate sections then the answer is yes. Let's say you have a very large module f.e, you'd put that in one section and for pictures and other stuff you could use another section. Advantage here is that your demo doesn't need one very big chunk of chipmem and thus it will work even if memory is fragmented.

if your question was about the actual section names, then the answer is no, there's no real need to use different names, you can perfectly have

SECTION BLA,CODE

...

rts
SECTION BLA,CODE
...
rts

and it will work/assemble without problems. :)

With Devpac, a "SECTION a,code" will automatically get merged with another "SECTION a,code" but not with a "SECTION b,code".

So having the same name -> slightly smaller executable size (about 50 bytes per eliminated SECTION), allows relative references between pieces of code within the same section, but AmigaOS needs fewer+larger blocks of available memory in your system (like Stingray described).

Does AsmOne/AsmPro work the same way?

Yep, Asm1/Pro merge the Sections with the same name too, just tested it. :)

Assume someone wants to do a small intro/dentro with simple code but with c2p. What is the lowest hardware spec and what framerates can one expect with c2p and double buffering on an 68030. Is that a possible lowest target spec in this case?

The second question ties in with the first. A 320x200 screen, is that a 320*200 chunky buffer c2p'd into an 320*256 screen or into a 300*200 screen (i assume 320*200 is possible to setup with the bitplane registers?) Meaning, can i let the c2p do the work on handling different screen sizes. And coupled with my first question, what screen resolution should be adequate for 68030 + c2p + double buffering.

I hope these questions actually make sense :o)

Assuming someone wants to release their first production at Breakpoint and they want to go for anything lower than 060 with a c2p based 1x1 demo, they should target for the golden age 030@50 Mhz Amiga config of year 1997 demos.

That would allow for a target framerate of 25 fps in 320x200 in 256 colours. Please note that for the 030 it should still be faster to include c3b1 (meaning 3 pass cpu, one pass blitter) c2p which would call for triple buffering. People may correct me if I'm wrong here.

Your second question can be answered with: both, since everything is possible, depending on what you want to do and how you set it up;)
But seriously, go for 320x200. Btw. you already got the source for a possible copperlist in that resolution in the WickedOS source. Use the source, z5!

@noname: now is perhaps the time to determine if the reason i only got 198 lines visible in wickedos is caused by the setup in the copperlist. I assume that NOMODE1 corresponds to mode 1 (320*200,256cols)?

the copperlist looks like this:
diwstrt,$4671
diwstop,$0cd1
ddfstrt,$38
ddfstop,$a0

This results in:
HSTART = $71
HSTOP = $d1 + $100 (256) = $1d1
=> resulting in 352 pixels?

VSTART = $46
VSTOP = $0c (extra msb = complement of msb) => $10c
=> resulting in 198 pixels?

Some questions:
- can somebody explain in plain english what the datafetch registers do and how to calculate them. I read about it in a manual but i don't understand
- 352*198 for a 320*200: what am i missing here?

DDFSTRT/DDFSTOP control when the bitplane DMA starts and when it stops fetching bitplane data. Bitplane DMA fetches don't occur all the time; they occur at intervals specified in the hardware logic. DDFSTRT/DDFSTOP is used to *disable* bitplane DMA when it is not supposed to be running.

Also, DIWSTRT/DIWSTOP specify during which scanlines bitplane DMA should be enabled.

Bitplane DMA plus the horizontal scroll setting in BPLCON registers determine what pixel-data will be available where on-screen. In addition to this, DIWSTRT/DIWSTOP describe which region on-screen should have "border" color and which region should show actual bitplane DMA contents.

So there is a complex relationship. Don't worry about DDFSTRT/DDFSTOP unless you are planning to change the horizontal size/position of the display window.


VSTART/VSTOP settings: feature/bug in the original copperlist. Expand it by 2 pixels to get a full 200 scanlines high image. Other settings in WickedOS might assume 198 pixels high display window, too.

HSTART/HSTOP settings: the display window as being presented there is indeed set to 352 pixels horizontally, but the bitplane DMA is probably not fetching enough data for the window.

the settings I would use for a 320x200 screen are:
DIWSTRT $4881
DIWSTOP $10c1
DDFSTRT $38
DDFSTOP $d0
BPL1MOD -$8
BPL2MOD -$8
FMODE $f (or $3 if I don't care about the fetchmode setting for sprites)

The reason why BPL1MOD and BPL2MOD need to be set to -8 is because bitplane DMA is unnecessarily doing an extra fetch per line. With better configured values for DDFSTRT/DDFSTOP that can be avoided.

Setting up display windows/playfields/bitplanes/modulos isn't as straightforward as it first seems. If somebody ever feels liking writing a turorial/article here, i think that would be most interesting.

Oi, seems like WickedOS would benefit from a little update. Somehow not even the artist recognized the view was always 2 lines too narrow, so everything was perfectly fine :)

For my benefit, is there any speed gain for the DMA if I resize the window from 352 pixels to 320?