Maximum Velocity demo (vector part glitches)

[amilo3438]

Hi,

Running it on Quickstart A500 OCS (& also ECS Agnus) some ugly glitches in the vector part appears.

To check if the disk image is corrupted/dammaged it should be tested on a real A500 first, right !?
(but I cant do it ... in fact still didnt find a way how to do a transfer since my old desktop died, and on my laptop there is no a floppy drive)

Maximum Velocity by The Silents
http://pouet.net/prod.php?which=4036
http://bitworld.bitfellas.org/demo.php?id=8879
http://ada.untergrund.net/?p=demo&i=454


EDIT:
Found an link to a video ... it says that has been taken on a real "Amiga 500 rev 6A PAL ECS Agnus 1MB" ... and its running just fine (see on 2nd picture below).
[ Show youtube player ]

But is still unknown are the disk images from one of the above links also used to make the video ?!

p.s.
Also a link to WHDLoad patch with some infos: http://www.whdload.de/demos/TSL_MaximumVelocity.html

[amilo3438]

I am a little bit surprised/confused as topic is still without reply, as it is not an AGA 68020CE problem, it is (we care) OCS ECS A500 problem, right ?!

Must say that after completely voluntarily have been done testing over 150 so called "the best rated Amiga500 demos", so far didnt encounter/found a such big or a similar problem on any other demo that has been tested in last 2 weeks, so that I am a little bit surprised that is nobody interested into what can cause a such vector glitch on an, I dare to say almost already perfect A500 emulation engine ???

Is perhaps that the disk images are somehow corrupted ?! ... or the emulator is still not ready to run a such weird code as is this one ?!

So, can somebody make a test on a real A500 to clarify the problem, Thanks.

(as mentioned in the 1st post, I cant do that for now)


p.s.
I'm sorry if someone find his/herself offended by my way of writing, it really was not my intention, I'm sorry for that.
My intention was to help in the detection of possible errors if they would possibly existed and for the purpose to help improving this great piece of software a little bit more.
Also sorry for my bad English, still learning and trying to improve it.

[Toni Wilen]

I haven't examined it enough yet but it does appear to be emulation problem, most likely some uncommon CPU instruction is used that takes too long to execute.

[Toni Wilen]

Unfortunately "something" takes too long, probably same problem as Anarchy's Madness 2 credits screen has (4MAT 3d object top part is not filled)

This still needs less complex test cases.

[amilo3438]

I must be missed this one on Anarchy's Madness 2 somehow ... checking it now again see why ... to me it still looks barely noticeable in comparison to main topic problem.

Hope that both can be repaired ... of course, in a near future.

Thanks for reply.

[Toni Wilen]

Originally Posted by amilo3438

I must be missed this one on Anarchy's Madness 2 somehow ... checking it now again see why ... to me it still looks barely noticeable in comparison to main topic problem.

It is only few frames that have the corruption but it does not matter. Anything is possible depending on how the demo is coded. If CPU/blitter is "racing the beam" very closely (for example there is only 10 or so scanline difference), even 1 cycle difference in repeatedly used instruction can cause visible difference.

Possible results are: few scanlines of garbage, the rest of frame shows garbage, next frame is corrupt, everything looks fine.

Maximum Velocity polls INTREQ vblank bit, then updates COP1 address in current copper list. If it takes too long (blitter active, mod player CIA timer interrupt comes), copper reruns old copper list (it is double buffered, contains lots of blits) which means previous frame's vector line blits and fills are blitted twice.

[amilo3438]

Originally Posted by Toni Wilen

Maximum Velocity polls INTREQ vblank bit, then updates COP1 address in current copper list. If it takes too long (blitter active, mod player CIA timer interrupt comes), copper reruns old copper list (it is double buffered, contains lots of blits) which means previous frame's vector line blits and fills are blitted twice.

Does it mean it would be too difficult to fix current A500 CE to deal with such special/unusual code programming technique ?!

Originally Posted by Toni Wilen

Anything is possible depending on how the demo is coded.

Anyway, after testing of some 150 A500 demos, this one problem now presents only 0.667% of code that is still not possible to run correctly ... and that is a really big/great achievement, isnt it.

[amilo3438]

Hi Toni,

I have found a link to big A500/1200 demo collection project running by only one man...

http://www.arabuusimiehet.com/break/amiga/faq.php

---------------------------------------------------------------------------------------------------------------------------------------------------
In his faq he mentioned following (quote):

"Does release X work? How do I run on an Amiga or an emulator?

As stated before, everything has been hand verified to work, using the latest (often beta) version of WinUAE maintained by my good pal Toni. Yes, everything works in an emulator, but you need to remember how to properly configure your stuff. Just as you would have to do with your real Amiga setup.

The default configuration of all non-AGA items is a basic A500 with kickstart 1.3 and 1.0MB RAM. (0.5MB chip/slow). If an item requires something else to work, it is noted in the additional info -field. For AGA stuff I nowadays use a pretty maxed-out configuration with lots of RAM etc.

If you really have trouble getting something you've downloaded from me to run, let me know and we'll sort it out. Just don't go around yelling "emulators suck" when they infact don't "
---------------------------------------------------------------------------------------------------------------------------------------------------

I also found "Silents, The - Maximum Velocity" in his collection but as .adf file ... according to above it could be working ?!
http://www.arabuusimiehet.com/break/...ils.php?id=398

It would be really a shame to not have some statistic about on what WinUAE last version some demo has been tested/approved to work too ...
have you ever been contacted by him regarding of any demo running problem on WinUAE ?!

[Toni Wilen]

Originally Posted by amilo3438

I have found a link to big A500/1200 demo collection project running by only one man...

Yes, I know

It only means this demo worked accidentally previously. It only looked correct because other parts of emulation had even worse timing that canceled the problem.

Not the first time this has happened.

[amilo3438]

Originally Posted by Toni Wilen

It only means this demo worked accidentally previously. It only looked correct because other parts of emulation had even worse timing that canceled the problem.

Not the first time this has happened.

Hope that some of other 150 already tested A500 demos will not stop working in distant future because it had working yesterday by accidentally.

[Toni Wilen]

Originally Posted by amilo3438

Hope that some other of already tested A500 demos will not stop working in distant future because it was working yesterday by accidentally.

Hopefully they do break because the more broken programs, the easier it becomes to fix them.

[amilo3438]

Originally Posted by Toni Wilen

Hopefully they do break because the more broken programs, the easier it becomes to fix them.

Ok, thanks for clarifying ... then I look to preserve this existing version just in case for future.

EDIT: Looking how today younger generations are not very interested into Amiga emulation (like my cousin), and are more occupied with their modern gadgets, can not exactly agree that it will be easier to fix possible problems in distant future.

[amilo3438]

Originally Posted by Toni Wilen

Unfortunately "something" takes too long, probably same problem as Anarchy's Madness 2 credits screen has (4MAT 3d object top part is not filled)

This still needs less complex test cases.

Hope this could be of help to better localize the problem...

testing the older WinUAE versions with .adf image found the following:

the last version when it was running good was WinUAE1330

on later version WinUAE1340 the problem starts to appear.

See on pictures attached below:

[Toni Wilen]

You missed the point. Something got improved in that version that "broke" it = it means there is still something _else_ that is (and has been for ages) incorrect.

Very very common when working with emulators. Pre-2.0 cycle-exact mode was very inaccurate.

[amilo3438]

Originally Posted by Toni Wilen

You missed the point. Something got improved in that version that "broke" it = it means there is still something _else_ that is (and has been for ages) incorrect.

The point is ... isnt time than to try to fix that "something" ...

I see no need for hurry, there is no deadlines.
Now when the problem is known, time is to see whats wrong, right ?!
Or is there a good reason to postpone the problem for some more, dont know.

But dont want to believe that there is no interest to solving it at all.

EDIT: Otherwise, what's the point reporting problems ?!

[mc6809e]

Originally Posted by amilo3438

The point is ... isnt time than to try to fix that "something" ...

I see no need for hurry, there is no deadlines.
Now when the problem is known, time is to see whats wrong, right ?!
Or is there a good reason to postpone the problem for some more, dont know.

But dont want to believe that there is no interest to solving it at all.

EDIT: Otherwise, what's the point reporting problems ?!

Well this is all a volunteer effort.

Be thankful there are people willing to do the work that you cannot.

[prowler]

Originally Posted by amilo3438

EDIT: Otherwise, what's the point reporting problems ?!

Don't lose heart. The more problems are reported. the more likely it is that this bug will be fixed.

Actually, Toni has already answered your question above.

Originally Posted by Toni Wilen

Hopefully they do break because the more broken programs, the easier it becomes to fix them.

[amilo3438]

I was afraid that will happen, so I want to clarify that here for good.

I really do respect work and effort of any engaged into the project,
and I didnt want to hurt anyone's feelings ... I am really sorry if that happen.

I just hoped that we all have the same goal, to help Toni to improve the emulator even a little bit more. And that was my intention, nothing more.

And thats why I have been also volunteer, also spending my free time, and I am not sorry for that.

I want all the best to the project in the future.

Cheers

[TCD]

Maybe a tad more patience is all you need amilo3438 Don't expect right away answers or reactions and just wait a bit longer until you question if anything will be done (that's how I read your post too). It's good to report problems, but it's not helping to push them too hard.

[amilo3438]

Originally Posted by TCD

It's good to report problems, but it's not helping to push them too hard.

Well, I must admit, I wasnt quite happy with the given answer at first ...
I would be much happier if the answer was something like "thank you for reporting the problem, we will look at it when will find a time" ...
because I have got after given answer a feeling as I shouldnt report it at all, as I did something wrong ... I dont know, but as it looks now maybe I did make mistake.

EDIT: I think I learned my lesson ... sometimes less really means more.