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.

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.

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

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.

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 [ 93.85 KiB | Viewed 2646 times ]

Another open question for me is how Copper shal behave in a following case:1) OCS selected, CDANG = 0, Copper write to 0x0602) w/ a settings above it is illegal address for write and it stops3) before frame end CPU set CDANG bit, now address 0x060 is inside of a range allowed to writeWhat 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. Unfortunately I don't have real Amiga HW to make tests on it

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.

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

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

Who is online

Users browsing this forum: No registered users and 1 guest

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