Undocumented Amiga hardware stuff - Page 8

Photon · 25 June 2013, 19:54

It's all about sharing and width of buses. That's still no guarantee against delays. Delays can simplify designs.

Toni Wilen · 23 July 2013, 11:46

CIA TICK input pin (TOD increases when it goes from low to high) seems to have some kind of built-in debounce circuit.

I set ALARM interrupt and used logic analyzer to check when INT line goes active. There was always 14-16 E-clock cycle delay between TICK going high and INT line going active.

Even "simple" CIA chips can have secrets.

hooverphonique · 23 July 2013, 13:26

Quote:

Originally Posted by xArtx

Everyone knows about the Pause control (physical pin) on the 68000 right?
Have you emulated that Toni??

I don't know that it could be if the Amiga doesn't connect to it.

I'm not sure what the last line of your post means, but asserting the pause signal on an A500 works a treat..

Leffmann · 08 October 2013, 17:21

It seems that register FMODE can only be written using the Copper. Whenever I try setting 64-bit bitplane fetch mode with the CPU, it has no effect. It only works when I write FMODE from the Copper program. WinUAE doesn't emulate this correctly, either.

Is this the case for any other hardware registers?

StingRay · 08 October 2013, 18:25

Did you try writing to FMODE every frame? Not sure about 64-bit fetch mode but FMODE can be set using the CPU as I've used that quite often to fix old demos which would have modulo bugs otherwise.

Toni Wilen · 08 October 2013, 18:55

I can't duplicate this. CPU writes seem to work just fine. (You sure previous copper list isn't still active and reseting your changes?)

Leffmann · 09 October 2013, 16:30

Ok so this was obviously not some weird behavior of the hardware. It didn't make sense to me either.

I'm using various macros to arrange the data inside sections, and there was an error in one of them causing the data to align wrongly. Every time I would insert that one instruction in the Copper program, bitplane data got moved down in memory without aligning correctly.

It seems FS-UAE and WinUAE don't emulate the side-effects of 32-bit and 64-bit fetch modes correctly, so the error only appeared when I ran the code on my real A1200, making it seem like a real hardware issue. Very confusing.

Photon · 09 October 2013, 20:07

Yes, in my current prod I just write FMODE before the first copper is started and that works fine. I haven't really experimented with a copper spammed full of alternating fetch modes, presumably green vomit will emanate from the DF0 slot like in The Exorcist...

Toni Wilen · 11 October 2013, 11:19

Quote:

Originally Posted by Leffmann

It seems FS-UAE and WinUAE don't emulate the side-effects of 32-bit and 64-bit fetch modes correctly, so the error only appeared when I ran the code on my real A1200, making it seem like a real hardware issue. Very confusing.

It does not because it is not as simple as clearing some low order bits (I did some tests years ago, sometimes you get quite weird side-effects) and so far no known program requires it.

Galahad/FLT · 11 October 2013, 18:49

Quote:

Originally Posted by StingRay

Did you try writing to FMODE every frame? Not sure about 64-bit fetch mode but FMODE can be set using the CPU as I've used that quite often to fix old demos which would have modulo bugs otherwise.

This. Never had an issue when I've had to fix something using using the CPU, never had to modify a copper list to get it to work.

Mrs Beanbag · 17 October 2013, 20:49

There is a very strange effect I have noticed before but I have no idea how to reproduce it.

When running hardware-hitting asm code from within AMOS (which I often used for testing things) on a few occasions in the past when there has been some bug in it, something very odd has happened and I ended up with two mouse pointers, as if a sprite had been duplicated across the screen. Both moved together, but some horizontal distance apart (don't remember exactly how far apart but at least 64px). One had the odd-numbered lines, the other had the even lines, as if the DMA were fetching the sprite data twice in one line.

Toni Wilen · 17 October 2013, 20:59

Quote:

Originally Posted by Mrs Beanbag

There is a very strange effect I have noticed before but I have no idea how to reproduce it.

When running hardware-hitting asm code from within AMOS (which I often used for testing things) on a few occasions in the past when there has been some bug in it, something very odd has happened and I ended up with two mouse pointers, as if a sprite had been duplicated across the screen. Both moved together, but some horizontal distance apart (don't remember exactly how far apart but at least 64px). One had the odd-numbered lines, the other had the even lines, as if the DMA were fetching the sprite data twice in one line.

Post #15 in this thread?

Mrs Beanbag · 17 October 2013, 22:52

Ah! Thanks for that, I missed it. Neat trick. I'll have to try it on purpose now!

btw one thing I'm missing from the scant AGA documentation I've got, when you want to do hardware scrolling you set DDFSTART 16 pixels further left than usual. If you use 32 bit fetch mode do you have to set it 32 pixels further left? And then lose another sprite?

Leffmann · 19 October 2013, 15:52

Yep, and I think you're going to lose 3 sprites actually, unless you want to narrow the screen width, and if you want to use 64-bit fetch mode and still have the 320 wide lowres screen then you have to move DDFSTRT all the way back to $18 and lose 7 sprites, unfortunately.

Mrs Beanbag · 19 October 2013, 17:59

oh well, maybe if I used some Fmode tricks I could get away with using 2 fewer sprites. Which would also free up some palette entries.

Toni Wilen · 24 December 2013, 11:25

Quote:

Originally Posted by Toni Wilen

COPJMP1 or COPJMP2 writes have one strange cycle.

Write to COPJMP:
Next copper cycle fetches next instruction word normally (just like another MOVE)
Second copper cycle is the strange one.
- if cycle is free, it gets allocated for copper (CPU or Blitter can't anymore use it) and it fetches following word and writes it to 0x1FE. It looks like normal copper MOVE to 0x1FE in logic analyzer.
- if cycle is not free (was used by BPL DMA for example), it still is usable by copper.

Strange second cycle got even stranger. If second cycle would be located exactly after first refresh slot, it will disappear and it will get replaced with normal copper fetch from new pointer.

In other words COPJMP sequence is 2 color clocks faster in this situation.

Lekman · 12 January 2014, 19:49

Funny to read this thread, i discovered the copper skip bug in 1995, and here is another bug i discovered in 1997 when writing a blitterscreen c2p. My final version is with blitter interrupt and that works fine. Here's what I wrote in 1997 and the source code for the basic C2P routine without Blitter interrupt:

Quote:

*****************************************************************************
** Just the basic C2B convert...
*****************************************************************************
** When using 8 Bitplanes, a large copper list and eight 64*256 sprites
** it seems like the Amiga doesn't know when to set the "BBUSY" flag.
** It works with "Blitter Nasty", but that probably won't work for
** Amigas with Fast-RAM...
**
** ---- Some hours later ----
**
** It's the sprites that cause the problem, use 2,4 or 6 Bpls instead and
** use one Bitplane for Masking.
**
** I have used 30 fucking hours to find the fault just to find out that it
** wasn't anything wrong with my code, just bugging HARDWARE...
**
** Normally we use Blitter Interrupts, and
** that works fine, also with sprites ;-(..fucking hardware fucking bug..)-;
**
** ---- One day later ----
**
** With my LameAsHell Macro it works fine also without blitter nasty =8)
**
** ---- Some hours later ---
**
** My LameAsHell Macro doesn't work without "Blitter Nasty" anymore???
**
** ---- Some more hours later ---
**
** With my new LameAsHell Macro it works fine also without blitter nasty =8)
**
** What is this shit =8(
*****************************************************************************

Code:

LameAsHell	MACRO
		tst.b	$dff002
.WaitBlit\@	tst.b	$bfe001
		tst.b	$bfe001
		btst.b	#6,$dff002
		bne.s	.WaitBlit\@
		tst.b	$dff002
		ENDM

BS_SC2P:	lea	CUSTOM,a6
		move.w	#$8400,DMACON(a6)	; Enable "Blitter Nasty"

		lea	BS_ScrSwap,a3
.WaitScrChange	tst.l	(a3)			; This will probably
		bmi.s	.WaitScrChange		; never happen

		move.l	BS_Scr1_P,a3
;-------------------------------- PASS 1 -------------------------------

		lea	(a0),a2
		lea	BS_ConvertBuff,a1	; Convert buffer
		LameAsHell

		IFNE	SpeedTest_FLAG
		move.w	#$00ff,COLOR01(a6)
		ENDC

		move.w	#$4000,BLTCON1(a6) ; A+BC, >>4
		move.l	a2,BLTAPTH(a6)
		addq.w	#2,a2
		move.l	a2,BLTBPTH(a6)
		move.l	a1,BLTDPTH(a6)
		move.w	#$f0f0,BLTCDAT(a6)	  ; MASK (%1111000011110000)
		move.l	#128*40<<16+1,BLTSIZV(a6) ; 128*40 words (Plane 7654)

;-------------------------------- PASS 2 -------------------------------

		lea	BS_ConvertBuff,a1	; Convert buffer
		lea	40*128*3(a3),a2		; Plane 4 (767676....)
		LameAsHell

		IFNE	SpeedTest_FLAG
		move.w	#$0ff0,COLOR01(a6)
		ENDC

		move.w	#$2000,BLTCON1(a6) ; >>2
		move.l	a1,BLTAPTH(a6)
		addq.w	#2,a1
		move.l	a1,BLTBPTH(a6)
		move.l	a2,BLTDPTH(a6)
		move.w	#$cccc,BLTCDAT(a6)	; MASK (%1100110011001100)
		move.l	#128*20<<16+1,BLTSIZV(a6) ; 128*20 words (Plane 76)

;-------------------------------- PASS 3 -------------------------------

		lea	BS_ConvertBuff+40*128*2-2,a1	; Convert buffer
		lea	40*128*3-2(a3),a2		; Plane 3 (545454....)
		LameAsHell

		IFNE	SpeedTest_FLAG
		move.w	#$00ff,COLOR01(a6)
		ENDC

		move.w	#$2002,BLTCON1(a6) ; <<2, Descending
		move.l	a1,BLTAPTH(a6)
		subq.w	#2,a1
		move.l	a1,BLTBPTH(a6)
		move.l	a2,BLTDPTH(a6)
		move.w	#$3333,BLTCDAT(a6)	; MASK (%0011001100110011)
		move.l	#128*20<<16+1,BLTSIZV(a6) ; 128*20 words (Plane 54)

;-------------------------------- PASS 4 -------------------------------

		lea	160*128-2(a0),a2
		lea	BS_ConvertBuff+40*128*2-2,a1 	; Convert buffer
		LameAsHell

		IFNE	SpeedTest_FLAG
		move.w	#$0ff0,COLOR01(a6)
		ENDC

		move.w	#$4002,BLTCON1(a6) ; <<4
		move.l	a2,BLTAPTH(a6)
		subq.w	#2,a2
		move.l	a2,BLTBPTH(a6)
		move.l	a1,BLTDPTH(a6)
		move.w	#$0f0f,BLTCDAT(a6)	; MASK (%0000111100001111)
		move.l	#128*40<<16+1,BLTSIZV(a6) ; 128*40 words (Plane 3210)

;-------------------------------- PASS 5 -------------------------------

		lea	BS_ConvertBuff,a1	; Convert buffer
		lea	40*128(a3),a2		; Plane 2 (323232....)
		LameAsHell

		IFNE	SpeedTest_FLAG
		move.w	#$00ff,COLOR01(a6)
		ENDC

		move.w	#$2000,BLTCON1(a6) ; >>2
		move.l	a1,BLTAPTH(a6)
		addq.w	#2,a1
		move.l	a1,BLTBPTH(a6)
		move.l	a2,BLTDPTH(a6)
		move.w	#$cccc,BLTCDAT(a6)	; MASK (%1100110011001100)
		move.l	#128*20<<16+1,BLTSIZV(a6) ; 128*20 words (Plane 32)

;-------------------------------- PASS 6 -------------------------------

		lea	BS_ConvertBuff+40*128*2-2,a1	; Convert buffer
		lea	40*128-2(a3),a2			; Plane 1 (101010....)
		LameAsHell

		IFNE	SpeedTest_FLAG
		move.w	#$0ff0,COLOR01(a6)
		ENDC

		move.w	#$2002,BLTCON1(a6) ; >>2, Descending
		move.l	a1,BLTAPTH(a6)
		subq.w	#2,a1
		move.l	a1,BLTBPTH(a6)
		move.l	a2,BLTDPTH(a6)
		move.w	#$3333,BLTCDAT(a6)	; MASK (%0011001100110011)
		move.l	#128*20<<16+1,BLTSIZV(a6) ; 128*20 words (Plane 10)

		LameAsHell

		not.l	BS_ScrSwap		; Ready to swap screen

		IFNE	SpeedTest_FLAG
		move.w	#$0000,COLOR01(a6)
		ENDC

		rts

The Copper are buggy when using much DMA, I had to add COPNOP between two wait instructions here:

Code:

.ScrollLoop	move.l	d0,(a0)+		; WaitLine
		move.l	d1,(a0)+		; Scroll
		eor.b	#$31,d1			; $10,$21,$10...
		move.l	d0,(a3)+
		move.l	d1,(a3)+
		add.l	#$01000000,d0		; Next line
		bcc.s	.NoPALHack
		move.l	#$ffdffffe,(a0)+	; \ PAL HACK
		move.l	#COPNOP<<16,(a0)+	; /
		move.l	#$ffdffffe,(a3)+
		move.l	#COPNOP<<16,(a3)+
.NoPALHack	dbf	d2,.ScrollLoop

TheDarkCoder · 13 January 2014, 22:25

Quote:

Originally Posted by Lekman

Funny to read this thread, i discovered the copper skip bug in 1995, and here is another bug i discovered in 1997 when writing a blitterscreen c2p. My final version is with blitter interrupt and that works fine. Here's what I wrote in 1997 and the source code for the basic C2P routine without Blitter interrupt:

Code:

LameAsHell	MACRO
		tst.b	$dff002
.WaitBlit\@	tst.b	$bfe001
		tst.b	$bfe001
		btst.b	#6,$dff002
		bne.s	.WaitBlit\@
		tst.b	$dff002
		ENDM

You mean that also in AGA a plain
.WaitBlit\@
btst.b #6,$dff002
bne.s .WaitBlit\@
does not work?
Under which condition?

Quote:

The Copper are buggy when using much DMA, I had to add COPNOP between two wait instructions here:

Code:

.ScrollLoop	move.l	d0,(a0)+		; WaitLine
		move.l	d1,(a0)+		; Scroll
		eor.b	#$31,d1			; $10,$21,$10...
		move.l	d0,(a3)+
		move.l	d1,(a3)+
		add.l	#$01000000,d0		; Next line
		bcc.s	.NoPALHack
		move.l	#$ffdffffe,(a0)+	; \ PAL HACK
		move.l	#COPNOP<<16,(a0)+	; /
		move.l	#$ffdffffe,(a3)+
		move.l	#COPNOP<<16,(a3)+
.NoPALHack	dbf	d2,.ScrollLoop

could you pleas explain in further detail? A0 and A3 write two similar copper list? and what's in the copper list after the COPNOP?

Lekman · 13 January 2014, 23:18

Quote:

Originally Posted by TheDarkCoder

You mean that also in AGA a plain
.WaitBlit\@
btst.b #6,$dff002
bne.s .WaitBlit\@
does not work?
Under which condition?

Well, as explained

: (Yes, in AGA)

*****************************************************************************
** Just the basic C2B convert...
*****************************************************************************
** When using 8 Bitplanes, a large copper list and eight 64*256 sprites
** it seems like the Amiga doesn't know when to set the "BBUSY" flag.
** It works with "Blitter Nasty", but that probably won't work for
** Amigas with Fast-RAM...
**

I was probably very desperate, so macro could probably look like this:

Code:

                    tst.b $ dff002
                    tst.b $ bfe001
                    tst.b $ bfe001
. WaitBlit \ @      btst.b # 6, $ dff002
                    bne.s. WaitBlit \ @

Quote:

Originally Posted by TheDarkCoder

could you pleas explain in further detail? A0 and A3 write two similar copper list? and what's in the copper list after the COPNOP?

I had 2 copperlists because of a fake laced mode, it looked good on an original Amiga monitor (not in WinAUE on a new monitor).

After the COPNOP there is a wait instruction and a scroll instruction.

Toni Wilen · 14 January 2014, 08:09

Sorry but there is not enough information. Obviously it is some corner case where nearly every DMA slot is in use but it is impossible to find the exact condition (which is the point of this thread, to document these features/bugs) without full code. You also mention sprites in comment but there is nothing in the code, also FMODE and BLTCON0 contents are missing.

I don't assume anything, full "buggy" code (binary is best, source isn't that good because different assembler may optimize it differently..) or nothing

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
who can provide hardware to create ADFs of some old rare stuff like Nautilus...?	Bernd	support.Other	3	19 August 2011 23:41
Stuff for sale amiga a1200 plus more retro stuff	blast	MarketPlace	23	22 June 2010 19:05
Action Replay Undocumented Features	deicidal	support.Hardware	0	01 March 2010 17:15
I've got some Amiga stuff...I want your SNES stuff!	Fingerlickin_B	MarketPlace	14	20 February 2009 01:33
Amiga stuff for trade for Atari Stuff	8bitguy1	MarketPlace	0	12 February 2009 05:36

25 June 2013, 19:54	#141
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,658	It's all about sharing and width of buses. That's still no guarantee against delays. Delays can simplify designs.

23 July 2013, 11:46	#142
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,573	CIA TICK input pin (TOD increases when it goes from low to high) seems to have some kind of built-in debounce circuit. I set ALARM interrupt and used logic analyzer to check when INT line goes active. There was always 14-16 E-clock cycle delay between TICK going high and INT line going active. Even "simple" CIA chips can have secrets.

08 October 2013, 17:21	#144
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	It seems that register FMODE can only be written using the Copper. Whenever I try setting 64-bit bitplane fetch mode with the CPU, it has no effect. It only works when I write FMODE from the Copper program. WinUAE doesn't emulate this correctly, either. Is this the case for any other hardware registers?

08 October 2013, 18:25	#145
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Did you try writing to FMODE every frame? Not sure about 64-bit fetch mode but FMODE can be set using the CPU as I've used that quite often to fix old demos which would have modulo bugs otherwise.

08 October 2013, 18:55	#146
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,573	I can't duplicate this. CPU writes seem to work just fine. (You sure previous copper list isn't still active and reseting your changes?)

09 October 2013, 16:30	#147
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Ok so this was obviously not some weird behavior of the hardware. It didn't make sense to me either. I'm using various macros to arrange the data inside sections, and there was an error in one of them causing the data to align wrongly. Every time I would insert that one instruction in the Copper program, bitplane data got moved down in memory without aligning correctly. It seems FS-UAE and WinUAE don't emulate the side-effects of 32-bit and 64-bit fetch modes correctly, so the error only appeared when I ran the code on my real A1200, making it seem like a real hardware issue. Very confusing.

09 October 2013, 20:07	#148
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,658	Yes, in my current prod I just write FMODE before the first copper is started and that works fine. I haven't really experimented with a copper spammed full of alternating fetch modes, presumably green vomit will emanate from the DF0 slot like in The Exorcist...

17 October 2013, 20:49	#151
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	There is a very strange effect I have noticed before but I have no idea how to reproduce it. When running hardware-hitting asm code from within AMOS (which I often used for testing things) on a few occasions in the past when there has been some bug in it, something very odd has happened and I ended up with two mouse pointers, as if a sprite had been duplicated across the screen. Both moved together, but some horizontal distance apart (don't remember exactly how far apart but at least 64px). One had the odd-numbered lines, the other had the even lines, as if the DMA were fetching the sprite data twice in one line.

17 October 2013, 22:52	#153
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	Ah! Thanks for that, I missed it. Neat trick. I'll have to try it on purpose now! btw one thing I'm missing from the scant AGA documentation I've got, when you want to do hardware scrolling you set DDFSTART 16 pixels further left than usual. If you use 32 bit fetch mode do you have to set it 32 pixels further left? And then lose another sprite?

19 October 2013, 15:52	#154
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Yep, and I think you're going to lose 3 sprites actually, unless you want to narrow the screen width, and if you want to use 64-bit fetch mode and still have the 320 wide lowres screen then you have to move DDFSTRT all the way back to $18 and lose 7 sprites, unfortunately.

19 October 2013, 17:59	#155
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	oh well, maybe if I used some Fmode tricks I could get away with using 2 fewer sprites. Which would also free up some palette entries.

14 January 2014, 08:09	#160
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,573	Sorry but there is not enough information. Obviously it is some corner case where nearly every DMA slot is in use but it is impossible to find the exact condition (which is the point of this thread, to document these features/bugs) without full code. You also mention sprites in comment but there is nothing in the code, also FMODE and BLTCON0 contents are missing. I don't assume anything, full "buggy" code (binary is best, source isn't that good because different assembler may optimize it differently..) or nothing

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)