Random Amiga programming trivia

[Galahad/FLT]

Originally Posted by Ray Norrish

how about doing it in 1989 demo stylee?

moveq #5,d0
add d0,d0
lea 7timestable(pc),a0
move (a0,d0.w),d1

7timestable: dc.w 7,14,21,28,35,42,49

or my personal favourite

REPT 7
add d0,d1
ENDR

ahem.... moveq? more like move.l #5,d0 if its 1989 demo stylee!

[cdoty]

Originally Posted by t0ne

... or how about for 7 ?
move.l d0,d1
lsl.l #3,d1
sub.l d0,d1

Heh! I've never thought of the sub option.

[Asman]

Originally Posted by Toni Wilen

I was not upset, only annoyed

Answer:

CLR.L $DFF088 does following (on 68000):

1: READ $DFF088
2: READ $DFF08A
3: WRITE $DFF08A
4: WRITE $DFF088

-> COPJMP1 is last address triggered.

Hi,

I have question. How many cycles eat CLR.L $DFF088 on 68000 ? And the second one. How check that the answer is correct ?

Regards

[Photon]

Originally Posted by Toni Wilen

add.l d0,d0 is even faster, only 6 cycles

On the 68000, 8 cycles if operand is register direct or immediate, as in this case.

There's always a "break even" point between successive adds and rotate instructions. For longs, a rotate instruction should be used if the shift is greater than 1, I think.

One of these nice solutions is the fastest. If there is a tie, the one with the fewest instructions will cause less competition with DMA, if the code is in chipmem (ie. works on unexpanded A500). I haven't calculated, but I suspect t0ne's will be the one. Might even be faster than the table one (don't have my timing sheet here but ... 14+4 for the table, 4+14+8... so could break even if the extra longword memory access would have to wait for two blitter cycles...)

But in this case, a table would be crap. Because in order to do it correctly, it would have to be 64K longs = 256K!

[meynaf]

For those who like weird things : what happens when opcode $FF10 is executed by a 68020 or 68030 (EC or not) in user mode ?

[StingRay]

Should simply trigger a line-f exception.

[frank_b]

Originally Posted by ant512

I don't think you could do this in C, AMOS or Blitz, because you rely on the behaviour of a specific asm instruction and a specific memory address. You can access the memory address using C, but you can't guarantee that the compiler will choose that specific instruction. As has already been mentioned, there's at least one other way to achieve what the CLR command is intended to (use MOVE to put 0 into the memory address).

In C it'd look like this:

long *p;
p = 0xDFF088;
*p = 0;

Think that's right, haven't done any C in ages (and don't really know asm yet either!). It just sets the long value at memory address 0xDFF088 to 0.

Have I got this right?

I'd add volatile to it if you're banging the hardware.

[meynaf]

Originally Posted by StingRay

Should simply trigger a line-f exception.

But will not. Instead you'll get a privilege violation exception (try it if you don't believe me).

A note about poking to DFF088 : there's no reason to do that anyway, apart if you want your freshly initialized copperlist to start right in the middle of actual screen and make you see garbage during one frame

[Toni Wilen]

Originally Posted by meynaf

For those who like weird things : what happens when opcode $FF10 is executed by a 68020 or 68030 (EC or not) in user mode ?

0xFF10 is FPU instruction (FSAVE) which is privileged instruction. CPU will decode them even if FPU is not installed.

Originally Posted by meynaf

A note about poking to DFF088 : there's no reason to do that anyway, apart if you want your freshly initialized copperlist to start right in the middle of actual screen and make you see garbage during one frame

There is if you want to have 100% robust code. Previous copper list may poke some registers which you may not want to happen

[meynaf]

Originally Posted by Toni Wilen

0xFF10 is FPU instruction (FSAVE) which is privileged instruction. CPU will decode them even if FPU is not installed.

No my friend it's not FPU instruction. ALL fpu opcodes are in the range F200-F3FF. FSAVE is F310, not FF10.

Originally Posted by Toni Wilen

There is if you want to have 100% robust code. Previous copper list may poke some registers which you may not want to happen

Like what ? If you initialize everything you have nothing to fear about previous coplist.

And if you want 100% robust code then it's better to waitvbl() after setting up your coplist.

[Toni Wilen]

Originally Posted by meynaf

No my friend it's not FPU instruction. ALL fpu opcodes are in the range F200-F3FF. FSAVE is F310, not FF10.

It is. Check your CPU manual again

Bits 9-11 is FPU ID number = ignored when decoding the instruction type. (EDIT: not 12-10. Never used in Amiga but there it is in official Motorola manuals)

Like what ? If you initialize everything you have nothing to fear about previous coplist.

And if you want 100% robust code then it's better to waitvbl() after setting up your coplist.

Yeah but if you let the old copper list run while initializing custom registers = you can get quite random results..

[meynaf]

Originally Posted by Toni Wilen

It is. Check your CPU manual again

Bits 9-11 is FPU ID number = ignored when decoding the instruction type. (EDIT: not 12-10. Never used in Amiga but there it is in official Motorola manuals)

It's certainly not. Bits 11,10,9 are COPROCESSOR id, not FPU id. See the difference ?

COPROCESSOR ID=1 -> FPU. Perhaps YOU need to look in your CPU manual again

0 is MMU (which means F800 isn't MMU even in weird EC030, but I already told this to you someday), 2 is 040 cache control (cinvl, cinvp, cpusha, etc.), 3 is move16 block (040), 4 is power control (lpstop, 060), 5 is debug block ( wddata, wdebug), 6 and 7 are unused.

Originally Posted by Toni Wilen

Yeah but if you let the old copper list run while initializing custom registers = you can get quite random results..

If you initialize custom registers by hand, just turn the copper dma off.

[Toni Wilen]

Originally Posted by meynaf

It's certainly not. Bits 11,10,9 are COPROCESSOR id, not FPU id. See the difference ?

COPROCESSOR ID=1 -> FPU. Perhaps YOU need to look in your CPU manual again

0 is MMU (which means F800 isn't MMU even in weird EC030, but I already told this to you someday), 2 is 040 cache control (cinvl, cinvp, cpusha, etc.), 3 is move16 block (040), 4 is power control (lpstop, 060), 5 is debug block ( wddata, wdebug), 6 and 7 are unused.

Oops, it is coprocessor

You are partially right but 020 and 030 still considers bits 9-11 as "no care" when decoding, afaik it is meant for other external support chips just like 68851 MMU or 68881 FPU. CPU don't know (or care) if they exist or not

(btw, there is no 030 MMU emulation so it isn't something important)

If you initialize custom registers by hand, just turn the copper dma off.

Thats one way to do it properly but there has been few games that fail if run at wrong time or previous (system) copperlist does something "unexpected" due to crappy setup routine.

Just complaining because this isn't rare error at all, just check recent post in this forum

[Toni Wilen]

Originally Posted by Asman

Hi,

I have question. How many cycles eat CLR.L $DFF088 on 68000 ? And the second one. How check that the answer is correct ?

I'll check this when I bother with boring logic analyzer stuff again.

Originally Posted by Photon

On the 68000, 8 cycles if operand is register direct or immediate, as in this case.

Same here

[Photon]

clr.l $dff088 takes 32 cycles according to my docs. The fastest way to accomplish the exact same thing is a move.l Dn,(An) (12 cycles), or to make it a part of a movem.l, in which case it takes 8 cycles+one or two for the shared start of the movem, depending on how many registers share the movem startup cycles.

[meynaf]

Originally Posted by Toni Wilen

Oops, it is coprocessor

You are partially right but 020 and 030 still considers bits 9-11 as "no care" when decoding, afaik it is meant for other external support chips just like 68851 MMU or 68881 FPU. CPU don't know (or care) if they exist or not

The 030 seems to care about those bits, because MMU opcodes are really with ID=0 (I checked all opcodes on my 030 so I know about this).
For me they decode the cpsave before they check about the coprocessor being present or not. 68000 and 040/060 don't do this and we'll get line-F as expected.
This could be another way to detect emulators

Originally Posted by Toni Wilen

(btw, there is no 030 MMU emulation so it isn't something important)

I know, but you can't fool a program which uses that. Perhaps one day we'll see a demo checking it and refusing to run on emulators...

Originally Posted by Toni Wilen

Thats one way to do it properly but there has been few games that fail if run at wrong time or previous (system) copperlist does something "unexpected" due to crappy setup routine.

Just complaining because this isn't rare error at all, just check recent post in this forum

I complained probably because I've seen just too many games having graphical glitches at startup, and writing to DFF088 is a nice way of making them

[Toni Wilen]

Originally Posted by meynaf

The 030 seems to care about those bits, because MMU opcodes are really with ID=0 (I checked all opcodes on my 030 so I know about this).
For me they decode the cpsave before they check about the coprocessor being present or not. 68000 and 040/060 don't do this and we'll get line-F as expected.
This could be another way to detect emulators

I know, but you can't fool a program which uses that. Perhaps one day we'll see a demo checking it and refusing to run on emulators...

There are many MUCH easier ways to do that (that are much harder to "fix")

I still won't care

I complained probably because I've seen just too many games having graphical glitches at startup, and writing to DFF088 is a nice way of making them

Ok, we agree. Lets say it this way: you can write dff088 if you know what are you doing

[meynaf]

Originally Posted by Toni Wilen

There are many MUCH easier ways to do that (that are much harder to "fix")

I still won't care

If you don't care... no problem here

Originally Posted by Toni Wilen

Ok, we agree. Lets say it this way: you can write dff088 if you know what are you doing

Just like any other hardware address

[gimbal]

Man, threads like this really make me wish I was born 5-10 years sooner

[alexh]

There is still a strong homebrew scene today on consoles and phones if you wanted to "prove" yourself.

[TheDarkCoder]

I have a question about proper copperlist startup. If one:
1) stops copper dma
2) init hardware registers
3) change COP1LC to its own copperlist but do not poke $dff088
4) starts copper dma

what happens whrn copper dma restarts? Isn't it possible that the old copperlist is executed because COP1LC is copied in the hidden copper instruction pointer only at the next VBLANK ?

[Photon]

IIRC I had a startup code like that way back. Ie. stop all dma, init stuff, set new copperptr, start dma. When DMA is started it will start fetching copper instruction as usual, and the address counter will be reset next Vsync or next time copjmp is poked.

[pmc]

@ Photon - you do remember correctly. Just tested as follows:

Turned off DMA.
Waited for vblank.
Pointer to my copperlist --> cop1lch.
Turned on DMA again.

My copperlist executed normally with no move to copjmp1

[Photon]

Well, waiting for vsync kinda spoils it tho But just make a loop in your favorite NonSystemStartup.S and set the normal copper as usual at vblank, then change the frame loop to wait (with cpu) for scanline $50 or so, and switch copper off, set copper address to a second copperlist which changes bg-color to neon pink, and copper dma on again.

If you see pink starting on rasterline $50, "dma-on" triggers copper start without copjmp, mid-frame.

If not, turning copper dma off mid-frame kills the copper until copjmp trigger or autotrigger(=vblank) OR continues reading instructions on dma-on from the normal copper (test by having a bgcolor-change on rasterline $60 or so in the normal cop)

Poking copjmp mid-frame should probably give the famous "force vblank hiccup" on CRTs.

[pmc]

OK, I setup two identical copperlists and did this:

 
.wait_line: move.l vposr(a6),d0
               and.l #$1ff00,d0
               cmp.l #$5000,d0
               bne.s .wait_line
               move.w #%0111111111111111,dmacon(a6)
               move.l #my_cop_listtwo,cop1lch(a6)
               move.w #%1000011111000000,dmacon(a6)
               bsr .wait_vbl
               move.w #%0111111111111111,dmacon(a6)
               move.l #my_cop_listone,cop1lch(a6)
               move.w #%1000011111000000,dmacon(a6)
               btst #6,$bfe001
               beq.s .exit
               bra.s .wait_line

With a red colour change in my_cop_listtwo and a blue color change in my_cop_listone. With the above loop executing I get a blue colour change on screen ie. I see the colour change from listone that's getting triggered to be read at vblank and not the colour change from listtwo that's getting triggered not at vblank.

If I insert a move to copjmp1 after moving listtwo to cop1lch I see a red colour change on screen again indicating that a move to copjmp1 is needed to force the copper instructions to be read from the new list.

So, *if* I understood your explanation right, and *if* I coded something that tests it right (big ifs, after all it's me we're talking about ) then dma on by itself doesn't trigger copper start - a move to copjmp or a vblank is needed for that.

If I'm being a complete denzil with my 'testing' then tell me so and also please tell my why I'm being so stupid - my ego can take it and it'll help me learn!

[Photon]

Yeah, it's not triggered by just writing a value, like the sound registers. It's quite logical, or there wouldn't be a separate trigger register, really

What I was curious for was if it would continue reading words from the original copper, even though the address had changed. It should, and it did.

Also, copper is auto-triggered each vblank without any write to copjmp. No surprise there, it wouldn't work otherwise. But would a write while copper dma was off be recognized? I tested, and yes. Again, no surprise, no reason why it should not, but it's tested.

Also, by adding a copjmp trigger mid-frame, it switches to cop2 as expected, WITHOUT any display hiccup. Wonder where those hiccups came from, maybe you need to trigger them at a certain scanline and copper must contain a wait that causes it to miss, ie. copper waits across vblanks somehow and no vsync comes to the CRT. Dunno.

I used the same colors as you, with a wait for scanline $60+green to test if it continued reading on after dmaon.

See attached source, I only added a few lines in loop: and inter:

[pmc]

Cool. More things learned. Cheers Photon.

[TheDarkCoder]

Hi, if I have understood it right, your test do confirm that to have a correct statup either you poke copjmp1 or you sync the dma copper restart to the vblank.
The display hiccup are probably generated when copperlists do change display windows settings

[hooverphonique]

that sounds strange.. i'm sure I never waited for vbl or poked any trigger register in my startup code, and I never saw display corruption (when there weren't any other bugs that could cause corruption, of course ;-)

[TheDarkCoder]

Originally Posted by hooverphonique

that sounds strange.. i'm sure I never waited for vbl or poked any trigger register in my startup code, and I never saw display corruption (when there weren't any other bugs that could cause corruption, of course ;-)

of course it's not automatic, it depends on what your code does. If, for instance, all bitplaes and sprite register are set by the copper list, you have no problem. Only be aware that the copperlist will start at next blank.

Problems occur if you need the copperlist to start executing immediatley after the end of the startup code. If you need such a behavior, then either trig COPJMP1 or wait for blank before leaving the startup code