what is the best way to understand an amiga patent?

[Rock'n Roll]

Patent Number: 5,103,499 - BEAM SYNCHRONIZED COPROCESSOR

1. we need the patent
The PDF-File can you find here:
https://www.freepatentsonline.com/5103499.html
https://patents.google.com/patent/US.../en?oq=5103499

2. bring the text from the PDF to a txt-File
http://structurise.com/screenshot-ocr/ to convert from pdf to txt
or copy the text from the site (txt-file is attached)

3. now print a pdf-file
4. read the document and mark the passages
- green - no questions
- (yellow - I believe, I have no questions)
- red - don't understand - big questions
also possible - make comments in your pdf-file

5. now, try to understand this with other docs

in my case I found following sentence:
Unlike the display window registers, which have a one pixel
resolution (low resolution mode), the data fetch regis-
ters have only a 4 pixel resolution because only five bits
are used in either register to specify the beginning and
ending position for the data fetch.

only horizontal position
$81 - DIWSTRT = 129 (one pixel resolution) Bit7-Bit0 = H7-H0
$38 - DDFSTRT = 56*2=112 Bit7-Bit0 = H8,H7,H6,H5,H4,H3, x, x
($38=%0011.1000) 0, 0, 1, 1, 1, 0, 0, 0

it's the same like SPRCTRL H8-H1 is two pixel resolution
$40 - Sprite = 64*2=128 (Sprite - without H0 in SPRxPOS)
or VHPOSR Bit7-Bit0 = H8-H1 (2-pixel resolution)

HRM: It is recommended that data-fetch start values be restricted
to a programming resolution of 16 pixels (8 clocks in low-resolution
mode, 4 clocks in high-resolution mode).

ok:
129-112=17pixel (is 8.5 clock cycles before) 1 clock cycle = 2 Pixel

--------------------------------------------------------------
from ross I know
CPU cycles are doubled in respect to internal/custom chips BUS cycles.
1 CCK = 1 chip cycle = 3546895Hz on PAL (281.94ns).
Of course CPU clock on PAL 68k A500 is 7093790Hz (double this for PAL 020 A1200).

Mainboard main crystal clock is 28375160Hz (chip clock*8); from this all the
others are derived (comprised the submultiple 90/180/270° different phase one).
With this clock you can display the 35ns super-hires pixels on ECS/AGA.
--------------------------------------------------------------

an other open question would be:
"Therefore, by allocating every other memory cycle to the 68000 processor,
the processor 402 can run at full speed because it appears to the processor that it
has memory access all of the time."

[Rock'n Roll]

The microprocessor 402 uses only the even numbered memory access cycles.

http://eab.abime.net/showthread.php?t=72575
(says: 4: "CPU only uses even-numbered memory access cycles" is wrong.)

I want examine this with the WinUAE Debugger.
Is there a tool what can visible the CPU memory access?
Can the DMA-Debugger show memory access from the CPU?

start:
	move.w #$4000,$dff09a	; Interrupts disable
waitmouse:  
	btst	#6,$bfe001		; left mousebutton?
	bne.s	Waitmouse	
WaitWblank:
	CMP.b	#200,$dff006	; vhposr - wait line
	bne.s	WaitWblank

	lea	Table,a0			; 12 cycles
	movem.l	(a0)+,d3-d7/a3-a6	; 84(21/0)
	movem.l	(a0)+,d3-d7/a3-a6
	movem.l	(a0)+,d3-d7/a3-a6
	movem.l	(a0)+,d3-d7/a3-a6
	movem.l	(a0)+,d3-d7/a3-a6
	movem.l	(a0)+,d3-d7/a3-a6	

	btst	#2,$dff016		; right mousebutton?
	bne.s	WaitWblank		 
	
	move.w #$C000,$dff09a	; Interrupts enable
	rts

Table:
	blk.w 1200,$FFFF		
	end

>t
Cycles: 42 Chip, 84 CPU. (V=200 H=66 -> V=200 H=108)
  D0 00000000   D1 00000000   D2 00000000   D3 FFFFFFFF
  D4 FFFFFFFF   D5 FFFFFFFF   D6 FFFFFFFF   D7 FFFFFFFF
  A0 00029D3E   A1 00000000   A2 00000000   A3 FFFFFFFF
  A4 FFFFFFFF   A5 FFFFFFFF   A6 FFFFFFFF   A7 00C60DB0
USP  00C60DB0 ISP  00C61DB0
T=00 S=0 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0 STP=0
Prefetch 4cd8 (MVMEL) 78f8 (MOVE) Chip latch 00000000
00029CCE 4cd8 78f8                MOVEM.L (A0)+,D3-D7/A3-A6
Next PC: 00029cd2
>v 200  66
Line: C8 200 HPOS 42  66:
 [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]  [48  72]  [49  73]
           BPL0 110            BPL1 112            BPL0 110            BPL1 112
               6638                0000                6666                0000
           0001C8BA            000218BC            0001C8BC            000218BE
 C43A9C00  C43A9E00  C43AA000  C43AA200  C43AA400  C43AA600  C43AA800  C43AAA00

[a/b]

I'd go with negative logic: if custom hardware (disk/audio/sprites are the obvious choice) is using X, then the cpu is using !X.

[Rotareneg]

Originally Posted by Rock'n Roll

The microprocessor 402 uses only the even numbered memory access cycles.

http://eab.abime.net/showthread.php?t=72575
(says: 4: "CPU only uses even-numbered memory access cycles" is wrong.)

I want examine this with the WinUAE Debugger.
Is there a tool what can visible the CPU memory access?
Can the DMA-Debugger show memory access from the CPU?

The visual DMA debugger will show CPU accesses to chip ram : http://eab.abime.net/showpost.php?p=...7&postcount=67

The "only even numbered cycles" part is incorrect, the CPU will use even or odd memory cycles just fine.

[Rock'n Roll]

In my case there is no CPU code or data shown like in your screenshots.
What is wrong? How is the procedure to get them? I only make >v -4 (activate dma debugger - different sizes)
I know I can activate, deactivate the channels with the vm command.

>vm 2 0 ; activate or deactivate the cpu channel

That works for all dma channels but nothing is changing for cpu.

The next is:
I want also see the cpu memory access in the empty fields same like for the dma channels.
Is it possible?

>v 200 10
Line: C8 200 HPOS 0A  10:
 [0A  10]  [0B  11]  [0C  12]  [0D  13]  [0E  14]  [0F  15]  [10  16]  [11  17]
                               AUD  0AA                                AUD  0CA
                                   0000                                    D8F7
                               00014DCE                                00005E0E

I found the solution: cycle-exact full has to be activated !!! It works!!!

[Rock'n Roll]

Ok, now I can see the cpu use the even cycles.

Line: C8 200 HPOS 10  16:
 [10  16]  [11  17]  [12  18]  [13  19]  [14  20]  [15  21]  [16  22]  [17  23]
   CPU-RW              CPU-RW              CPU-RW              CPU-RW
     4CD8                FFFF                FFFF                FFFF
 00029CB2            00029CDA            00029CDC            00029CDE
 8DA1E000  8DA1E200  8DA1E400  8DA1E600  8DA1E800  8DA1EA00  8DA1EC00  8DA1EE00

When does the cpu also use the odd cycles?
In which cases? A short piece of code what can demonstrate that would be good.

[Rock'n Roll]

Maybe it was a stupid question from me, because in line 0 I can see memory access on
odd cycles very fast. But I have also disabled disk-dma (7, 9, 11) and audio-dma (13, 15, 17, 19) here.

move.w #%1000001110000000,$dff096

>v 0
Line: 00   0 HPOS 00   0:
 [00   0]  [01   1]  [02   2]  [03   3]  [04   4]  [05   5]  [06   6]  [07   7]
 COP  1FE  RFS1 1FE  COP  08C  RFS2 1FE  COP  180  RFS3 1FE  COP  08C    CPU-RW
     0000      FFFF  s   0180  s   FFFF  s   005A  s   FFFF  s   00E2      41F9
 00023898            00000420            00000422            00000424  0002B7B4
 AB310C00  AB310E00  AB311000  AB311200  AB311400  AB311600  AB311800  AB311A00

 [08   8]  [09   9]  [0A  10]  [0B  11]  [0C  12]  [0D  13]  [0E  14]  [0F  15]
 COP  0E2            COP  08C    CPU-RW  COP  120    CPU-RW  COP  08C    CPU-RW
     0000                0120      0C39      0000      00C8      0122      00DF
 00000426            00000428  0002B7AA  0000042A  0002B7AC  0000042C  0002B7AE
 AB311C00  AB311E00  AB312000  AB312200  AB312400  AB312600  AB312800  AB312A00

then with enabled dma-channels
move.w #%1000001111111111,$dff096
Why is 7, 9, 11 disk-dma not an empty field now?
For audio-dma 13, 15 it would be ok.

>v 0
Line: 00   0 HPOS 00   0:
 [00   0]  [01   1]  [02   2]  [03   3]  [04   4]  [05   5]  [06   6]  [07   7]
 COP  1FE  RFS1 1FE  COP  08C  RFS2 1FE  COP  180  RFS3 1FE  COP  08C    CPU-RW
     0000      FFFF  s   0180  s   FFFF  s   005A  s   FFFF  s   00E2      F006
 00023898            00000420            00000422            00000424  0002B7D4
 DBCBD200  DBCBD400  DBCBD600  DBCBD800  DBCBDA00  DBCBDC00  DBCBDE00  DBCBE000

 [08   8]  [09   9]  [0A  10]  [0B  11]  [0C  12]  [0D  13]  [0E  14]  [0F  15]
 COP  0E2    CPU-RW  COP  08C    CPU-RB  COP  120  AUD0 0AA  COP  08C  AUD1 0BA
     0000      66F6      0120      0000      0000      0000      0122      0000
 00000426  0002B7D6  00000428  00DFF006  0000042A  0001057C  0000042C  0001057C
 DBCBE200  DBCBE400  DBCBE600  DBCBE800  DBCBEA00  DBCBEC00  DBCBEE00  DBCBF000

[Toni Wilen]

Originally Posted by Rock'n Roll

Maybe it was a stupid question from me, because in line 0 I can see memory access on
odd cycles very fast. But I have also disabled disk-dma (7, 9, 11) and audio-dma (13, 15, 17, 19) here.

Because most 68000 instructions don't have idle cycles (=only memory cycles back to back, cycle length is divisible by 4), refresh cycles basically "forces" CPU to only use even cycles.

Shift instructions are easy test case, each shift by one takes 2 CPU cycles (=1 DMA cycle).

then with enabled dma-channels
move.w #%1000001111111111,$dff096
Why is 7, 9, 11 disk-dma not an empty field now?
For audio-dma 13, 15 it would be ok.

Cycle allocation is dynamic, cycle is reserved for DMA only if DMA transfer is required. No cycles are wasted.