Minimig Discussion Forum

Discussing the Open Source FPGA Amiga Project
It is currently Sun Sep 24, 2017 3:12 am

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Copper issue
PostPosted: Thu Apr 10, 2014 8:18 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
During copper module tests I've found some unexpected behavior. I use following copper list:
Code:
COPPERL1:
        DC.W    $0F01,$8F00   ; Wait for VP=0xxx1111
        DC.W    INTREQ,$8010  ; Set the copper interrupt bit...

        DC.W    $00E3,$80FE   ; Wait for Horizontal $E2
                              ; This is so the line gets finished before
                              ; we check if we are there  (The wait above)

        DC.W    $7F01,$7F01   ; Skip if VP>=127
        DC.W    COPJMP1,$0    ; Force a jump to  COP1LC

COPPERL2:
        DC.W    $8F01,$8F00   ; Wait for VP=1xxx1111
        DC.W    INTREQ,$8010  ; Set the copper interrupt bit...

        DC.W    $80E3,$80FE   ; Wait for Horizontal $E2
                              ; This is so the line gets finished before
                              ; we check if we are there  (The wait above)

        DC.W    $FF01,$FE01   ; Skip if VP>=255
        DC.W    COPJMP2,$0    ; Force a jump to  COP2LC

        DC.W    $FFFF,$FFFE   ; End of Copper list

This copper list should trigger copper interrupt every 16 lines.
From my tests it looks like an interrupt will be requested only at the beginning of line 0x0F and line 0x80.

Does anyone can make test on a real hardware (amiga and minimig) and confirm correct/incorrect behavior?


Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Fri Apr 11, 2014 10:23 am 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
I will run a test on the original Hardware and the Minimig as soon s possible :)

_________________
_____________________________
JMP $00000BED ; will guru-meditation until next morning


Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Wed Apr 16, 2014 7:07 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
I'm expecting some problems w/ wait for a $E2 horizontal position. From a simulation it looks like Copper will not change a state from WAITSKIP2 to FETCH1 because when 'beam_match_wait' signal is active there is no enable signal for Copper FSM.

Can anyone write a simple test to check this? Copper list above shall trigger Copper interrupt every 16 vertical lines. Changing a COLOR00 register value in an interrupt shall 'produce' color gradient through a screen.

Thx,
madeho


Attachments:
E2_wait_issue.jpg
E2_wait_issue.jpg [ 154.9 KiB | Viewed 2394 times ]
Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Sat May 03, 2014 4:12 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
Finally, I have got time to made some tests. The result confirm issue w/ a copper FSM in case of wait/skip horizontal position E2. According to a HRM (COPROCESSOR HARDWARE/Advanced Topics/A Copper Loop Example chapter) copper interrupt should be generated on every 16th line.
To make a test simple I use only one copper list and update COLOR00 register value on every copper interrupt.
Code:
wait_for_copper_irq:
  move.w   INTREQR(A6),D0
  btst          #5,D0
  beq.w     test_copper_irq
  move.w   #$20, INTREQ(A6)
  move.w   #$f, d6
test_copper_irq:   
  btst        #4,D0
  beq.w     wait_for_copper_irq
  move.w   #$10, INTREQ(A6)
  lsl.w       #4, d6
  btst       #15,D6
  beq.w     no_restart
  move.w   #$f, d6
no_restart:
  move.w   d6,COLOR0(A6)
  jmp         wait_for_copper_irq

In case of wait for $E2 position there are only 2 changes of color on line 16 and 128. When copper list is modified to wait for $E0 there are 8 changes of color what is correct to expected result.
Attached are: bootrom source code, bootrom verilog file and 2 precompiled minimig cores w/ wait for E0 and E2 position


Attachments:
copper_issue.zip [197.85 KiB]
Downloaded 117 times
Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Sun May 04, 2014 10:29 am 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
I will have a look at the cores.
A direct compare to real Amiga hardware will be necessary, to be sure off :)

OT: What kind of compiler/tool did you use to get the Verilog boot-code?

_________________
_____________________________
JMP $00000BED ; will guru-meditation until next morning


Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Sun May 04, 2014 6:25 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
boing4000 wrote:
A direct compare to real Amiga hardware will be necessary

Sure, it has to be checked on a real Amiga, but I'm almost 100% sure that wait for $E0 and $E2 shall give the same result what is not true in case of minimig. The copper list from a first post is taken from Amiga HRM and I also read on AEB that someone use that copper list and it worked as it was intended.

boing4000 wrote:
OT: What kind of compiler/tool did you use to get the Verilog boot-code?


I use an Easy68k assembler to build a s19 file. To make an "internals" of boot rom I use s2vrlg converter, you can find it below.


Attachments:
bootrom.zip [56.95 KiB]
Downloaded 115 times
Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Thu May 08, 2014 1:16 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
I'm still evaluating current Copper implementation. I think that I've found next issue related to illegal address write by MOVE instruction
On a new frame Copper restart code execution from COP1LC stored address (blue marker). It moves $0 to COLOR00 register and start MOVE instruction w/ destination set to $3E (OCS mode selected, CDANG = 0). Copper FSM stops in a FETCH2 state. (yellow marker)
Attachment:
move_3e_stopt.jpg
move_3e_stopt.jpg [ 171.33 KiB | Viewed 2310 times ]

Up to now behavior seems to be correct. Some "?" appears when I force Copper to restart by write to a COPJMP1 register (yellow marker on a screenshot below). According to Amiga HRM each write to a copper jump register shall restart Copper code execution from an address pointed by COP1LC register. In current implementation Copper is not restarted.
Attachment:
move_3e_restart.jpg
move_3e_restart.jpg [ 93.85 KiB | Viewed 2310 times ]

Another open question for me is how Copper shal behave in a following case:
1) OCS selected, CDANG = 0, Copper write to 0x060
2) w/ a settings above it is illegal address for write and it stops
3) before frame end CPU set CDANG bit, now address 0x060 is inside of a range allowed to write
What shall happen now ..... Copper shall be stopped until SOF/COPJMP1 write or shall continoue code execution from a place it stopped?

I hope that someone will be able to answer on my questions. :D Unfortunately I don't have real Amiga HW to make tests on it

Thx,
madeho


Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Thu May 08, 2014 1:50 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Hi madeho,

I wouldn't blindly trust the simulation results, unless you thoroughly checked the code also. The minimig source isn't really simulation -clean code, because of misuse of blocking / non-blocking assignment operators, and no delays added to flip-flop assignments, which could easily confuse a proper Verilog simulator. The RTL source could of course be cleaned up, but it's quite some work.

Can't you try your copperlists on WinUAE, or other UAE variant?

_________________
** my minimig builds: http://somuch.guru/ **


Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Thu May 08, 2014 2:54 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
Hi chaos,
chaos wrote:
Can't you try your copperlists on WinUAE, or other UAE variant?

Which issue are you a talking about ....
There are 2 or even 3 different.
1) Issue w/ WAIT instruction for horizontal position $E2.
It is confirmed on a minimig HW. If you wait for horizontal position $E2 Copper will not 'cautch' beam match for it. When WAIT position is changed to $E0 it behaves correctly

2) Restart Copper by COPJMP write if it is stopped by illegal address.
Copper list from point 1 uses MOVE instruction to restart copper. In a simulation (hpos wait set to $E0) waveforms is correct and behavior is the same as on a real minimig. It means that simulation of MOVE $0080, $0000 it is correct.
When you look at a simulation result, when copper is stopped, write to COPJMP register seems to be discarded. Simulation of my copper code gives the same results as simulation of original verilig code. I have even use it to build a bin file. Dexion "Megademo" works great w/ it. I've started "F..ing copper" part at the same time on winUAE and minimig and there was no differences in behavior and timing.
The only simulation difference (between minimig and my design) is that in my code Copper is restarted (from a stop state) when COPJMP write is issued by CPU. Minimig seems to stay in that state until SOF apprears.

3) Behavior of Copper in case of CDANG set when it was stopped by write to restricted range (for detailed description see post above).
I couldn't find any information how it shall behave. That way it is mentioned as a possible issue


Top
 Profile  
 
 Post subject: Re: Copper issue
PostPosted: Thu May 08, 2014 5:20 pm 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
In any case please only compare to native real Amiga chipset.
I also made many bad error reports due to using any replica (Jakub may remember this ;)).
Because real Chipset still act "right in any case" even if this is a true Chipset bug.

_________________
_____________________________
JMP $00000BED ; will guru-meditation until next morning


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Translated by Xaphos © 2007, 2008, 2009 phpBB.fr