A.D.A. Amiga Demoscene Archive

        Welcome guest!

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / Fixing Redux for 060

 

Author Message
Paradroid
Member
#1 - Posted: 7 Apr 2013 15:15 - Edited
Reply Quote
So I've spent the occasional hour or two since Revision working on some fixes for Redux for when it's run on faster Amigas. All has gone well and I've only had to do a single none trivial recode of an effect (the plasmas near the start), but I've just told winuae to pretend the hardware has an 060 in it and the cache detection that I do in the bootblock is failing.

I have no doubt whatsoever I'm about to be told off for doing it this way, but here is how I'm detecting the presence of a cpu cache...

	moveq	#1,d0
.cached st.b bCpuCacheDetected-Copperlist(a0)
move.w #$4228,.cached-Copperlist(a0) ; replace the above "st.b x(a0)" with "clr.b x(a0)"
dbf d0,.cached


...which is working fine until it's run with an 060. Does the 060 start with its caches disabled? Does its caches only work for certain RAM? I'm quite clueless when it comes to these details! ?_?

Telling me off is fine as long as it's followed up with useful advice :)
Toffeeman
Member
#2 - Posted: 7 Apr 2013 15:55
Reply Quote
Hi Paradroid sorry a bit off topic here. I loved the demo and I'm really pleased to see a OCS demo get so much attention :0)

In the opening zoom I read you used the 102 zoomer. Did you generate the pre-scaled images during the loading ? I guess the A500 isn't fast enough todo this in realtime whilst the incremental zooms are displayed.

Which zoom technique did you use for the credits part ?

Do you think you will do another OCS demo for next years Revision ?
Angry Retired Bastard
Member
#3 - Posted: 7 Apr 2013 16:08 - Edited
Reply Quote
Paradroid: Not really an answer to why your current test doesn't work but: As long as you still have a valid execbase why not just check the AttnFlags to see what CPU class you're on rather than explicitly checking for the cache?
In Vold I simply checked the lib version and did a jump to _LVOCacheControl(a6) to disable all caches if the machine was running V37 or higher.
Of course, that will fail for kick 1.2 / 1.3 machines with caches so it might need a fallback solution for those quite rare cases...

Edit: and just because examples are better than my sometimes shoddy terminology: by Attnflags I meant the word at execbase+296, and libversion (kick rev) execbase+20
Paradroid
Member
#4 - Posted: 7 Apr 2013 16:16
Reply Quote
Toffeeman:
Hi Paradroid sorry a bit off topic here. I loved the demo and I'm really pleased to see a OCS demo get so much attention :0)

Glad you liked it. And no worries for going off topic, I'm happy to answer any questions about it... well, as long as I get this cache nightmare fixed soon, aargh!!!

(the demo runs fine on 060 if I force my cache flag, so I can probably just test what the exec.cachecontrol is returning, but I'd still like feedback)

Toffeeman:
In the opening zoom I read you used the 102 zoomer. Did you generate the pre-scaled images during the loading ? I guess the A500 isn't fast enough todo this in realtime whilst the incremental zooms are displayed.

Yep, they're generated just before the demo starts. If the zoom animation is flat and not too rapid you don't actually need to generate a new image each frame, so the amiga would be plenty fast enough even with a logo of that size. I was just lazy/short of time, so only optimised or did stuff like that when absolutely necessary ;-)

Toffeeman:
Which zoom technique did you use for the credits part ?

For the horizontal I'm using the blitter to draw vertical strips that are then flood filled (the image requires some pre-processing so the fill will work). For the vertical portion I just stretch the image using the copper.

Toffeeman:
Do you think you will do another OCS demo for next years Revision ?

I will be doing another demo, but not so sure about Revision. I don't want to commit to a date as I've got a very busy year ahead of me. I may do some smaller releases before then.
Paradroid
Member
#5 - Posted: 7 Apr 2013 16:25
Reply Quote
Angry Retired Bastard:
Paradroid: Not really an answer to why your current test doesn't work but: As long as you still have a valid execbase why not just check the AttnFlags to see what CPU class you're on rather than explicitly checking for the cache?
In Vold I simply checked the lib version and did a jump to _LVOCacheControl(a6) to disable all caches if the machine was running V37 or higher.
Of course, that will fail for kick 1.2 / 1.3 machines with caches so it might need a fallback solution for those quite rare cases...

Yeah, i was already using that func to disable the caches (or I should have been, I might have accidentally released with it commented out, oops) but I need them on for the fixed AGA release as the plasmas weren't fast enough on a stock A1200 once I inserted the required blitwait. I now run a pure CPU version for the faster CPUs, but the A1200/A4000 still require the cache activated as the data is still setup for 68000+blitter, so not well suited to proper 020~060 optimisation (something I really can't be fussed to change).

As mentioned in my previous post, the demo runs fine when I force the detection, so I'll look at those AttnFlags and I might be okay. thanks for the tip :-)
Paradroid
Member
#6 - Posted: 7 Apr 2013 22:23
Reply Quote
Solved the detection problem, now to deal with flushing the cache after loading code from disk... <whisper> and during effects that use SMC </whisper>

Someone remind me to keep the system alive the next time I make a demo, lol
Angry Retired Bastard
Member
#7 - Posted: 8 Apr 2013 09:15
Reply Quote
Excellent, what was the problem with the actual detection?
As for the SMC... I find that it helps keep retrocoding interesting! ;)
Paradroid
Member
#8 - Posted: 8 Apr 2013 09:49 - Edited
Reply Quote
My detection code was fine on real hardware, it was just in winuae (I suspect a config error of my own) that it was failing. I got around it by using exec.cachecontrol to force the instruction cache on, then read it back to see if it worked and set my own flag accordingly.

That got the job done, but now I've got this issue after loading code. I've stepped into the kickstart function for flushing the cache to see what it's doing for the various CPUs, but I don't think it's such a good idea for me to emulate that as I'm bound to miss something for configurations I've not even considered. I also looked at disabling the cache once the plasmas are complete, but again, no idea if it's safe to rely on tinkering with the CACR for all 020+ CPUs.

Hmmm, I'll have another bash at recoding the plasmas so they don't need the cache...

Angry Retired Bastard:
As for the SMC... I find that it helps keep retrocoding interesting! ;)

yeah, but I get the odd feeling of both Yeaaah!! and Nooooo!! when I using it, knowing that the above problems are just around the corner, hehe
Paradroid
Member
#9 - Posted: 8 Apr 2013 16:01
Reply Quote
Paradroid:
I'll have another bash at recoding the plasmas so they don't need the cache...

I had productive lunch hour and have just got word back that it's now running properly on real 060 hardware :)

My house is a kid free zone tomorrow, so I'll leave it until then to make the final build... I'll finally be able to start thinking about what comes next without distractions, at least until someone points out it doesn't work on their setup :P
Toffeeman
Member
#10 - Posted: 11 Apr 2013 23:06
Reply Quote
How many pixels does the initial image zoom by ? You need an image for every 16 pixels of horizontal zoom right ?

I love what you did with the Blitter filling on the credits zoomer! You extended my original zoom routine that I wrote back in the 90s. I was using the blitter to copy vertical lines as well but I was doing it for every row. To keep it at 50hz I needed a low colour depth and shortish source bitmap image. I thought yours looked faster!

Totally understand about committing to dates but it is really good to hear you are planning more Amiga stuff :0)

Does the mosiac at the start also use Blitter filling ?
Paradroid
Member
#11 - Posted: 13 Apr 2013 15:21
Reply Quote
Toffeeman:
How many pixels does the initial image zoom by ?

I can't remember how much the Lemon logo zooms, but you're right about needing to have an image for every 16 pixels of zoom (with the steps in between handled by changing the smooth scroll amount across the screen). I think I just used however many I could fit in 64Kb (or maybe 64kb per bitplane).

Toffeeman:
I thought yours looked faster!

The amiga isn't even trying in the credits zoomer, it's just a clear + 97 xor blits that are the height of the logo*planes + a fill, must be at least half a frame remaining. I imagine it would be a lot faster to use the cpu to render the equivalent of those 97 blits. I'll have to give that a try :-)

Toffeeman:
Does the mosiac at the start also use Blitter filling ?

The mosaic part doesn't use blitter filling, in fact it's just a super lazy row or column copy that's done at the start to make a little anim that I then use the copper to stretch out (i.e. test code didn't need optimising, so it stayed in the demo). The mosaic in the original RAD (and the game Dragonstone, which used the same effect) was very much realtime and quite fast, although it was just based around some hand crafted copy+shift blits IIRC. Hmmm, I've just had an idea how to improve on that... .. .
Blueberry
Member
#12 - Posted: 16 Apr 2013 19:18
Reply Quote
One trick I sometimes use for A500 code to make it run on faster machines regardless of caches is to put the code in chip memory. It will be the same speed as fake-fast on A500 anyway, and it will not be cached since chip memory is marked as uncacheable.

There might be cases where it will run slower on faster machines than on A500 this way, but I have not encountered any so far.
Paradroid
Member
#13 - Posted: 16 Apr 2013 22:49
Reply Quote
the code I was having problems with was already in chip ram and running slow on the faster machines ;-) All sorted now, after several rewrites of the plasmas i ended up with just a small tweak to the original code with the caches off. final available at pouet.
Alexco
Member
#14 - Posted: 9 Jun 2013 22:57
Reply Quote
Hi Paradroid,

I tested the final version from Pouet but on my A600 with 68030, Indivision ECS and 2 MB Chip I can see some glitches:
- the presents scroller at the beginning slows down in the middle
- the glenz vectors show some filling issues
- the bitmap rotozoomer shows white pixel garbage and the music slows down

Anyone here with a full ECS setup who can test that? It may also be that the Indivsion ECS is the problem, since it re-implements the ECS logic in FPGA.
Paradroid
Member
#15 - Posted: 24 Jun 2013 18:20
Reply Quote
err, missed this post until now. I've had a few reports of glitches on machines with an indivision installed, so I'm hoping it's that. I can't say I've encountered or heard of those specific bugs before though.

 

  Please log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0