Sine scroller

[Toni Wilen]

Startup code (+interrupt handling) is something that was last used in 1986 or 87 Extremely bad way to do it..

Also, copjmp1 is word sized register, now it really triggers copjmp2..

[pmc]

Originally Posted by AGN

I don't like You.

I'll live... No seriously, apologies for those things you asked me to correct creeping back into the source - they came back in cos I went back to an earlier version at some stage and then added things back in. I've corrected those things again now in the final version that's in the zone...

Originally Posted by AGN

Race condition. Your code is not able to update copper list before its execution.

I added in your extra line to the copper list and that fixed the glitch. Thanks AGN. As you can tell from my code and the questions I've asked and how I've been getting stuck I'm just a beginner and nowhere near your league. Can you explain to me exactly what a race condition is and how the extra copper list line you gave me fixes it? I'd be really grateful.

Originally Posted by Toni Wilen

Startup code (+interrupt handling) is something that was last used in 1986 or 87 Extremely bad way to do it..

Well, I was trying to do a proper, authentic old skool routine!! I'm not surprised my code is, from an expert like yourself's perspective, really bad. But I'm learning, and I'll keep trying to get better...

[AGN]

Originally Posted by pmc

I added in your extra line to the copper list and that fixed the glitch. Thanks AGN. Can you explain to me exactly what a race condition is and how the extra copper list line you gave me fixes it? I'd be really grateful.

I'm busy ATM so no explanation in this odd language. Here is pic for you:

At NOW it's too late to update already executed copperlist entries.

Originally Posted by pmc

As you can tell from my code and the questions I've asked and how I've been getting stuck I'm just a beginner and nowhere near your league.

And You are wrong, especially about 'league'.

Originally Posted by Toni Wilen

Startup code (+interrupt handling) is something that was last used in 1986 or 87 Extremely bad way to do it..

Not to mention that shitty code makes winuae better.
Is there any good doc which explains "what" to do and more important "why"?
How to code answers about "what" part.

[AGN]

Originally Posted by pmc

Can you explain to me exactly what a race condition is and how the extra copper list line you gave me fixes it?

http://en.wikipedia.org/wiki/Race_condition
http://eab.abime.net/showthread.php?t=21866

[pmc]

Thanks for taking the time to give me a more detailed explanation AGN.

All your help has been appreciated - that's why, in the new source, you too now get a mention in the scrolltext!

I'll check out the How To Code tutorial on startup code and perhaps implement this into my sinescroll routine and the routines I do in the future.

[korruptor]

pmc: cheers for running it. I've not actually tested it on an A500, just E-UAE pretending to be a 1200. I'll double buffer it when I get a chance and do some more thorough tests. Thanks

[pmc]

@korruptor - no worries man, anytime. Can you post the WinUAE settings you used for your testing? I ran the standard A1200 config that comes with UAE and assembled your source under that. When I ran it though, the screen looked corrupted - like what you'd see with wrongly set modulos.

Fear of having problems getting my metal banging, full of bad practices and non-OS friendly code to work on an AGA chipset is one of the reasons I have my WinUAE set for A500+. At least the hardware reference manual covers the ECS chipset.

I feel, purely for me personally, that using an emulated A1200 with an AGA chipset for my coding leaves me more on my own due to (from what I've seen / can tell) the lack of detailed docs on the hardware.

The other reason is that the only real working Amiga I still own is an A500+...

[AGN]

Considering that

        addq.l  #3,a3                   ;this is the offset added. Change this value to 2, 3, 5 or 6 for different sine bounces.

You need better termination

@@ -612,7 +612,7 @@
        dc.b    180,180,180,180,180,179,178,178,177,176,175,174,173,172,170,169
        dc.b    167,166,164,162,161,159,157,155,153,151,148,146,144,142,139,137
        dc.b    135,132,130,127,125,123
-       dc.b    255
+       dc.b    255,255,255,255,255,255,255,255,255,255,255     ; lame :(

 ** Data **

[pmc]

You know AGN, I like your posts. They're concise and they make me think. I shall return, and this time with sine code that doesn't need lame termination...

[Big-Byte]

Great thread!! Ive uploaded a bunch of Amiga adf's of old source code I and my mates wrote over 20 years ago now! into the zone for you to look at. Theres some sine scrollers in there among other things.

Hope you find them useful.

[pmc]

Originally Posted by Big-Byte

Great thread!!

Thanks Big-Byte, you're a gent.

Originally Posted by Big-Byte

I've uploaded a bunch of Amiga adf's of old source code I and my mates wrote over 20 years ago now! into the zone for you to look at.

And thanks for these too! I'll check them out... Judging from Toni's post earlier about my coding practices being from 20 years ago they should be right up my alley!

[Toni Wilen]

About startup-code:

If you are going to take over the system, take over it completely, disable unused interrupts, don't call any KS's interrupt routines (you don't want to confuse the system or user too much by allowing system's inputhandler or disk checks to work etc.., they also waste precious raster time)

LoadView(NULL);WaitTOF();WaitTOF() is also good idea (before taking over copper), or things can get very "interesting" if previous display mode was not standard OCS/ECS-mode.. (and LoadView(previously stored gfxbase->actiview) when restoring)

Check also VBR (if CPU >=68010)

Wait for blitter before entering your code. Previous blit started by OS may still be active!

btw, this has nothing to do with emulation compatibility, this only causes unnecessary "bug" reports because this kind of startup-code is unreliable, even on an A500 and really unreliable on expanded Amigas.

[pmc]

Thanks for all your advice Toni. I'll try to get my head round all the things you're saying about best practice startup code and try to include them in my source.

Originally Posted by Toni Wilen

Also, copjmp1 is word sized register, now it really triggers copjmp2..

By the way, you'll be pleased to know my latest version (not yet posted to the zone) writes copjmp1 with a move.w instead of a move.l!

[korruptor]

pmc:

From memory, my settings are (E-UAE):
Rom: 310
Ram: 2mb Chip, 8 fast, 32 rtg
CPU: 68020/68881 Direct JIT
Chipset: AGA / PAL Collision Full, Intel TSC, No immediate blitters

Everything else is default, I think.

I can PM you the file if you want?

[pmc]

@korruptor - I played around with the settings as per what you remembered and got your routine working better than I ever have before - thanks for that. Why not send me the settings via PM though so what you see is definitely what I see?

It's almost there! From what I saw your routine might be suffering from the same 'race condition' that mine was - there's a diagonal graphic glitch in the top right hand corner of your scrolltext - check AGN's explanations earlier in the thread.

Oh, and I still had the problem with the routine restoring back to the OS after lmb. Those are minor things though in my opinion - the main core of what the code is trying to do works. Knowing the struggle I took to get that far I say you've done really well.

A couple of small amendments now and it'll be perfect, keep up the good work...

[pmc]

Originally Posted by AGN

Considering that

Code:

addq.l #3,a3 ;this is the offset added. Change this value to 2, 3, 5 or 6 for different sine bounces.

You need better termination
Code:

@@ -612,7 +612,7 @@ dc.b 180,180,180,180,180,179,178,178,177,176,175,174,173,172,170,169 dc.b 167,166,164,162,161,159,157,155,153,151,148,146,144,142,139,137 dc.b 135,132,130,127,125,123- dc.b 255+ dc.b 255,255,255,255,255,255,255,255,255,255,255 ; lame ** Data **

@AGN - I've been pondering over the above for a couple of days and have decided that I disagree that the termination is invalid.

From what I've seen / tried, the only way to make the scrolltext 'wave' is to add an offset value to the sin table pointer each iteration of the interrupt. Most routines I've looked at take this approach.

In my sin table there are 150 values. That means that adding a value of 3 each iteration will always mean the 'end of sin' marker gets hit - 150 is exactly divisible by 3. I could also add 2, 5 or 6 as 150 is exactly divisible by these values too. Granted, if I add a sin value so that my sin table contains 151 values and still use 3 as an offset, then everything goes wrong. As it stands though, by my reckoning, the termination is adequate.

If I'm missing something, can you explain further - it'll help me understand using sin tables better...

[korruptor]

Originally Posted by pmc

@korruptor - I played around with the settings as per what you remembered and got your routine working better than I ever have before - thanks for that. Why not send me the settings via PM though so what you see is definitely what I see?

It's almost there! From what I saw your routine might be suffering from the same 'race condition' that mine was - there's a diagonal graphic glitch in the top right hand corner of your scrolltext - check AGN's explanations earlier in the thread.

Oh, and I still had the problem with the routine restoring back to the OS after lmb. Those are minor things though in my opinion - the main core of what the code is trying to do works. Knowing the struggle I took to get that far I say you've done really well.

A couple of small amendments now and it'll be perfect, keep up the good work...

Thanks for the kind words

There's actually a lot of stuff to fix in that code, as numerous problems were identified in my interference circle routine that I've nearly fixed. All of which probably apply to that code as well. I think I'll re-write it and double buffer everything. Hopefully I'll get some time soon to have a go...

[pmc]

@korruptor - got the PM with your UAE settings, thanks. If you're going to have a go with double buffering then you could do a lot worse than use the routine from this code:

http://www.flashtro.com/page.php?id=607&a=dl

it's a nice and neat way to do it...

[AGN]

Originally Posted by pmc

@AGN - I've been pondering over the above for a couple of days and have decided that I disagree that the termination is invalid.

This is not about invalid termination.

Originally Posted by pmc

In my sin table there are 150 values. That means that adding a value of 3 each iteration will always mean the 'end of sin' marker gets hit - 150 is exactly divisible by 3. I could also add 2, 5 or 6 as 150 is exactly divisible by these values too. Granted, if I add a sin value so that my sin table contains 151 values and still use 3 as an offset, then everything goes wrong. As it stands though, by my reckoning, the termination is adequate.

This is about freedom. You can make sine_table any size and add any numer - code will handle it.

@@ -417,13 +417,12 @@

 get_mstr_sin_val:
        move.l  mstr_sin_ptr,a3                 ;move the mem position of the current sin value into a3.
-       cmp.b   #255,(a3)                       ;have we reached the end of the sin table?
-       bne.s   not_end_of_sin                  ;nope, read in the next sin value
-       move.l  #sin_table,mstr_sin_ptr         ;yep, rest the mstr sin pointer back to the start of the table
-       move.l  mstr_sin_ptr,a3                 ;and put the first sin value back in a3
+       addq.l  #3,a3                           ;this is the offset added. Change this value to 2, 3, 5 or 6 for different sine bounces.
+       cmp.l   #sin_table_end,a3               ;have we reached the end of the sin table?
+       blt.s   not_end_of_sin                  ;nope, read in the next sin value
+       sub.l   #sin_table_size,a3                      ;yep, rest the mstr sin pointer back to the start of the table

 not_end_of_sin:
-       addq.l  #3,a3                   ;this is the offset added. Change this value to 2, 3, 5 or 6 for different sine bounces.
        move.l  a3,mstr_sin_ptr                 ;update the mstr sin pointer with this value

 * We need to load in pointers to the first word of the scrollplane and the displayed screen, this is where the blits will start from
@@ -544,8 +543,8 @@
 * The offset needs to use a temporary sine pointer (a4 register is used for this) to write the rest of the screen words using sequential sin table values

 get_offset:
-       cmp.b   #255,(a3)                       ;have we reached the end of the sin table? we have to check this in the temporary pointer too so that we can reload back to the start of the table if needed
-       bne.s   not_end_temp_sin                        ;nope, read in the next temp sin value
+       cmp.l   #sin_table_end,a3                       ;have we reached the end of the sin table? we have to check this in the temporary pointer too so that we can reload back to the start of the table if needed
+       blt.s   not_end_temp_sin                        ;nope, read in the next temp sin value
        move.l  #sin_table,a3                   ;yep, reset the temp sin pointer back to the start of the table

 not_end_temp_sin:
@@ -612,7 +611,9 @@
        dc.b    180,180,180,180,180,179,178,178,177,176,175,174,173,172,170,169
        dc.b    167,166,164,162,161,159,157,155,153,151,148,146,144,142,139,137
        dc.b    135,132,130,127,125,123
-       dc.b    255
+sin_table_end:
+
+sin_table_size equ     sin_table_end-sin_table

 ** Data **

[pmc]

@AGN - Ahhhh, I see where you were heading now... That makes a lot more sense and is a much more flexible approach. Much neater than my 'locked in' solution. Thanks again - I've learned another lesson.

I've edited the code to have local labels and also my routine is running OK as a 1 pixel sin now. I want to edit the clunky linear code and make the sin_blits part of the code with a loop instead. Will post the next version to the zone when that's done...