Would be very cool to write something in machine code in Amos to set the interlace screen properly with the graphics.library if that is indeed the issue. Have no idea how to do that though hahaha.
I'm going out on a limb, but you might not even need to to write a machine code routine or follow Mike's suggestion (but that might help a lot if a newer graphics library or the older one works).
The part that is broken is the software in Kickstart 3.1 that opens a graphics library. If you do that and then "hit the hardware" with a POKE, DOKE or maybe LOKE, hopefully the screen data your game produces is interpreted right and you are sorted.
If Amos let's you do such things, then that would get the code going to real Amigas, should be OK on the emulator. Without writing external code. I suspect Amos might not permit that, as it's the sort of "kiddy wheel feature" which stops rummaging under the bonnet. I don't know either way.
IIRC, the reason you can't do a copper list to write every single hardware registers is that the early hardware registers are protected from being written by a copper list. So an out of control copper has some kind of limit on it anyway. Again, IIRC, frames are displayed alternately, so you need to change the pointers to the data every screen update to do interlace on native Amiga chipsets.
The tough part is you learning how to setup Amiga screens by using hardware registers. Opening a library correctly and using that is the preferred, most compatible method. Further details on both methods in Hardware reference manual and rom kernal manuals.
It's nice to have different options by learning more, and it sucks that Amos just doesn't work in this respect. Amos Pro was released before 3.1 so I don't think it was tested with that.
