Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

SuperFrog Glitch On V4

Manfred Bergmann

Posts 226
27 Sep 2020 17:05


Hi.

I'm not sure if this is known or not.
But I see an issue in SuperFrog with WHDLoad.
Some part of the lower screen is copied but doesn't really fit to the rest of the screen.
See here:
EXTERNAL LINK 

Manfred


James Husted
(Needs Verification)
Posts 81/ 3
27 Sep 2020 17:48


Hi there, yes this is a known issue - something hacky with how superfrog works I believe.


Saladriel Amrael

Posts 166
29 Sep 2020 08:39


Is it just me or it seems the game is rendering the screen displaying correctlty the first  320x200 pixels and filling the missing 56 bottom lines with the upper 56?
Could this have something to do with a misrecognition/misconfiguration of PAL/NTSC settings of the chipset?




Gunnar von Boehn
(Apollo Team Member)
Posts 6197
29 Sep 2020 08:52


Super Frog always had a Copper list including "useless/bad copper instructions" at the end.
When fully executed the original Super Frog Copperlist will make the lower part look strange.

In the A500 this list was not 100% executed as the Amiga misses one DMA slot and was not able to reach this part of the game list.

The V4 Copper is today 1 DMA slot faster and because of this reaches this "hidden" part. We will make the V4 Copper match the A500 and then this will "hide" again.
 


Saladriel Amrael

Posts 166
29 Sep 2020 09:28


If it's like this wouldn't be a better solution to patch the game code through WHDLOAD and keep V4 Copper wider DMA slots range?

(Just asking...)


Ozzy Boshi

Posts 31
29 Sep 2020 16:24


Probably the copperlist at some point resets the bitplanes pointers and this instructions are never executed in regular/old amigas because usually the speed of the copper is fixed and when the beam reaches the end the copperlist is reexecuted from scratch.
It 's only my assumption, and it is probably wrong.

If Gunnar changes this behaviour (increasing the copper speed) I fear a lot of legacy code would break, for example copperchunky usually relies on the fact that the copper takes the equivalent of some pixels to perform a move, if the v4 is faster that could lead to some incorrect behaviours and old copperchunky routines cant work as expected.

As Gunnar stated in our meeting, Amiga is a quite complicated system and my opinion is that sometimes making all the coprocessors work correctly in sync with the cpu is hard.

To complicate even more things, old programmers used tricks and banged the hardware so hard that compatibility can be an issue even between old commodore Amigas.

posts 6