PMC Mesmerized Demo - Fails before triangle/pyramid seq.

[Yulquen74]

Whatever I do, I am unable to view the triangle/pyramid sequence of this demo.

It fails with an exception access fault, Byte read from ....

This happens on real A1200 with Blizzard 1260, but also WinUAE.

I have tried a lot of stuff in WinUAE 4 (WB3.1) without getting closer:

- changing CPU to 020 or 030, still fails
- removing commodities and patches
- running demo with early startup after setpatch with wbrun
- tried various tooltypes (nocache, novbrmove, nommu...)
With 030 and nommu, it does not crash, but the triangle/pyramid sequence
is not shown, only a black screen and the red stripes are visible while music is still playing. when the sequence is "done", it starts showing the other sequences over.
- tried both new (V18) and old version (V16) of WHDLoad
- downloaded original demo and slave, and installed it over again. new install behaved the same, and produced the same files as existing one
- both downloaded and read my original kick 1.2/1.3 roms - both was the same as I already have in devs/kickstarts
- booting from a setup floppy I have instead of hard disk (with setpatch and 060 libs) and running the demo from there

according to information in older threads the demo is supposed to work, just not for me atm.

can anyone please confirm it is fully working on real amiga, preferably with 060, or WHDLoad (any cpu)?

[StingRay]

It's a slave problem, it needs to be updated.

[ross]

I've only launched the exe (not have checked the slave) but it does not seem to have big problems.
Maybe the slave do not patch the wrong DIW values?

[StingRay]

There are invalid copperlist entries and other problems which haven't been fixed.

[ross]

Yes, checked the slave and the DIWs in copper list are not patched.
But there is a strangeness..
Yulquen74 specified that with WinUAE during the triangle sequence only a black screen and the red stripes are visible:
this is probably due to the illegal DIWSTRT=xx00 that on ECS/AGA doesn't open the display window.
But on copper list there is also DIWSTOP=xxff and on the latest WinUAE version (i've tried 4.0+) this open the video and the demo works.

So what is the exact behavior of these illegal DIW setup?

Logically patch is simple, both value need to be corrected and some other little detail in copper list also, but the 'emulation' question remain.

Yulquen74, what version of WinUAE do you use?

[Galahad/FLT]

Galahad checks Mantis.... Zero reports.

Galahad opts to check crystal ball....... not getting anything from that either.

Galahad checks random thread on EAB...... oh, thats how we get bug reports on 16 year old WHDLoad slaves now.

[Galahad/FLT]

Originally Posted by ross

I've only launched the exe (not have checked the slave) but it does not seem to have big problems.
Maybe the slave do not patch the wrong DIW values?

I wrote the install on an A1200 with 060 card and 16 years later, there are issues with someones A1200 with an 060 card.

[ross]

Originally Posted by Galahad/FLT

I wrote the install on an A1200 with 060 card and 16 years later, there are issues with someones A1200 with an 060 card.

This is the Amigaaa Powaaa!


(checked on Ama*on, there are some really cheap crystal balls )

[Toni Wilen]

Originally Posted by ross

this is probably due to the illegal DIWSTRT=xx00 that on ECS/AGA doesn't open the display window.

Yes (it is not that simple in reality) but it can be timing sensitive, for example if display window is already open when demo switches to this copper list, window stays open, even if new DIWSTRT/STOP combination would not open it.

[ross]

Originally Posted by Toni Wilen

Yes (it is not that simple in reality) but it can be timing sensitive, for example if display window is already open when demo switches to this copper list, window stays open, even if new DIWSTRT/STOP combination would not open it.

Very clear, thanks. This explains the divergent operations in the various cases
(between similar versions of real hardware and also for the different configurations of WinUAE).

This is due to the bad habits of the metal's bashers to strobe COPJMP.
That I will never understand why it is used and that generates the most various problems.
Of course, it can serve, but only in special and rare cases.

[Yulquen74]

Ross: I'm using WinUAE 4.0.0

Galahad: I see your point, and I appreciate that you took the time to read and reply to the thread, but please know that it was not meant as a formal bug report, if so I would have used your bugtracker. Since other users had gotten it working, I assumed that it was just a bit troublesome to get working on.

Update: My assumption yesterday was that I would always get it working somehow in WinUAE, so I did the bulk of the trial and error there, using the CF card from my A1200.
That assumtion was wrong, as I got it somehow working on my real A1200 today:

If I enable the NOMMU tooltype and start the demo, I first get a requester saying something like "The option NoMMU has been activated but ... the installed prog will prob not work, try a different 040/060 library".I click ignore, the demo starts, and all sequences are shown without crash, including the triangle and pyramids. But the side-effect of this tooltype set is no exit, and the converging circles effect does not display correctly (layers are like pulled apart, see picture, also happens in WinUAE with NOMMU) .

I pulled the CF card and used in WinUAE again to see if something had changed, but there was still no action during triangle/pyramid sequences.

[StingRay]

But the side-effect of this tooltype set is no exit, and the converging circles effect does not display correctly (layers are like pulled apart, see picture, also happens in WinUAE with NOMMU) .

There are several bugs in the demo (it for example accesses memory outside the 512K chip area; this causes the "byte read from $xxxx" error message), using NOMMU will only prevent WHDLoad from catching these problems but the bugs are of course not fixed. So don't expect miracles when using NOMMU.

[Galahad/FLT]

Originally Posted by StingRay

There are several bugs in the demo (it for example accesses memory outside the 512K chip area; this causes the "byte read from $xxxx" error message), using NOMMU will only prevent WHDLoad from catching these problems but the bugs are of course not fixed. So don't expect miracles when using NOMMU.

What is your Amiga specs so I can set Winuae to the same to capture them, this is the first time i've had any mention of bugs in 16 years

[Galahad/FLT]

Originally Posted by Yulquen74

Ross: I'm using WinUAE 4.0.0

Galahad: I see your point, and I appreciate that you took the time to read and reply to the thread, but please know that it was not meant as a formal bug report, if so I would have used your bugtracker. Since other users had gotten it working, I assumed that it was just a bit troublesome to get working on.

Update: My assumption yesterday was that I would always get it working somehow in WinUAE, so I did the bulk of the trial and error there, using the CF card from my A1200.
That assumtion was wrong, as I got it somehow working on my real A1200 today:

If I enable the NOMMU tooltype and start the demo, I first get a requester saying something like "The option NoMMU has been activated but ... the installed prog will prob not work, try a different 040/060 library".I click ignore, the demo starts, and all sequences are shown without crash, including the triangle and pyramids. But the side-effect of this tooltype set is no exit, and the converging circles effect does not display correctly (layers are like pulled apart, see picture, also happens in WinUAE with NOMMU) .

I pulled the CF card and used in WinUAE again to see if something had changed, but there was still no action during triangle/pyramid sequences.

Attachment 58998

Dont stress dude, its just that if I didnt happen upon this thread by accident, I wouldnt have known it had bugs still, and that after all is what we are all trying to fix.

I've fixed all the DIW bugs in the copperlist, now I just to wait on Stingray for the access fault reports and we can get it 100% on your machine, just weird that it was done on my old A1200 tower with 060 card, and these bugs didnt manifest themselves at the time, especially as the bits that dont work on your machine I had to check as the demo uses Kickstart for the very things that don't work on your machine.

[sneeker]

Just tried this, A1200, Apollo 1240, whdload 18.3, ClassicWb 3.9.

I get Exception "Access Fault"($7008)
PC = $63E82
Byte Read frp, $2EF1764

Educated guess its at the same point as Yulquen as Ive never watched the demo before.

[Photon]

Originally Posted by Galahad/FLT

Galahad checks Mantis.... Zero reports.

Galahad opts to check crystal ball....... not getting anything from that either.

Galahad checks random thread on EAB...... oh, thats how we get bug reports on 16 year old WHDLoad slaves now.

Hehe. I think I'm guilty of posting in this forum about slave errors too T'is true I do not play as much WHDLoad as a few years ago. What, pray, is this Mantis of which you speak?

[StingRay]

Originally Posted by Galahad/FLT

now I just to wait on Stingray for the access fault reports and we can get it 100% on your machine

The reason for the "out of bounds" memory access is at offset $2fe8e in the binary (absolute location is $34000+$2fe8e=$63e8e) and should be easy to fix as just the cmp.l #$fffdff,a1 instruction needs to be corrected.



Also look out for missing BPLCON0 color bits in the copperlists, there are a few.

Originally Posted by sneeker

Just tried this, A1200, Apollo 1240, whdload 18.3, ClassicWb 3.9.

I get Exception "Access Fault"($7008)
PC = $63E82
Byte Read frp, $2EF1764

Educated guess its at the same point as Yulquen as Ive never watched the demo before.

It's the "demo accesses memory outside the 512k" problem I've mentioned above.

[Retroplay]

Originally Posted by Photon

What, pray, is this Mantis of which you speak?

When you use the bug report form on the install page for the demo, it sooner or later ends up on the Mantis Bug Tracker.
You can also make a bug report directly on the Bug Tracker.

[ross]

Originally Posted by StingRay

The reason for the "out of bounds" memory access is at offset $2fe8e in the binary (absolute location is $34000+$2fe8e=$63e8e) and should be easy to fix as just the cmp.l #$fffdff,a1 instruction needs to be corrected.

I'm for a rewrite for the "random generator" through ROM patterns.
Two bird with a stone: no more ROM required by the slave and no more dumb absolute address check (so no more Access Fault error).

Also look out for missing BPLCON0 color bits in the copperlists, there are a few.

The little details I was mentioning

[StingRay]

Originally Posted by ross

I'm for a rewrite for the "random generator" through ROM patterns.
Two bird with a stone: no more ROM required by the slave and no more dumb absolute address check (so no more Access Fault error).

That's Galahad's decision. I would do it your way as well.

The little details I was mentioning

I mentioned them in post #4 too, just a bit more subtle.