A.D.A. Amiga Demoscene Archive

Hi folks,

we're in the process of crawling toward a final release for our Revision Demo.
Managed to shift enough data around to fit the A500 + 512 Fake Fast requirements.
Doc.K is allocating some chip mem for his 3D object which threw me off the tracks when
granting Novel another 30k for the tune - silly me.
But in this allocation there probably lies another quirk. The party version has a curious memory bug
when it's changing scenes from the hexagon-floor to the 3D object. So much so that it either completely
bugs off the Blitter and is just showing trash or it distorts the tune or the P61 replayer routine.

I've got an uncrunched executable that should run on an A500 + 512 that you can download for testing and/or debugging. I'd be glad for any hint advise to tackle this bugger

remember: THIS IS NOT A FINAL ... and no official release
quintessence_a500

Any help will be highly appreciated ( ... and credited)

Bump... Anyone helping out yet? :)

Love to see a final version!

It doesn`t help but I lauched it on A1200 040 and it runs fine as far as I can say.

Thanks blakkhar but I need test/debugs on an A500 + 512 environment.

Hey Dodge, if you are really still looking for A500 + 512 test data, I will get my machine off the attic and test it for you this week. Should I do that?

Got word and an svn diff from doc.K . He restructured routine calls inside the scene in question.
I'll merge and test that first and report back.

Doc.K evidently fixed the Blitter-Bug by re-arranging the setup calls for the scene in question (setplanes, bpl-clear, copperlist etc. ... I messed up the calling order at some point).
Nevertheless, the damn sample distortion still remains :( ... just one sample in the tune but it's the clave which is one of the most prominent ones, darn !

And you've verified that the player plays the song correctly without that effect?
In that case it's probably about time to fire up the UAE debugger and set some memory write watchpoints (either on that one specific sample, or on all the datastructures).

I wanted to test the whole demo with effect routine calls commented in the "platonic solids scene" first to maybe identify the area where the corruption might come from. But ATM I'm at work, so perhaps this evening I'll give an update and post a new executable.

Are you sure it's not the wav->iff conversion issue? All samples in Protracker mod have to be in proper IFF format, but I guess you and Novel are perfectly aware of it.

Can't be because the sample plays just fine until the scene with the platonic solids starts. It happens on the fly during or after the setup of the scene or due to some actions in one of the effect routines.
On top of that, it might just only happen on an A500 with 512k chip + 512k public mem. On 1mb + machines the bug might not even manifest.
My guess is that the sample data at this position (i.e. the clave sample) gets corrupted by some memory write action during that particular effect scene. That's what I'll test now ... work is done, svn commit done ... weekend o/ ... bugtracking (._.)

Just as an out of the box thought: could it be interrupt related? Do you handle them for yourself? Do you save all registers for each interrupt-call?

Done a lot of testing. Got rid of the sample corruption (probably).
But we're back to the Blitter-trash :/
It's somewhere in the routine calls for the 3D object (drawing, filling, moving)

Uploaded some test images to test on either UAE or the real McCoy.

NOTE: for testing purposes only, NOT A FINAL, just test versions of the party version on the A500

platonics scene w/o drawing the dodecahedron (but with 3d init code executed): mds-qnt_no3d.adf

with 3D draw switched on: mds-qnt_3d.adf

You said that changing the order of things during setup, setting Copper pointers among other things, fixed the Blitter-trashing. Are you updating the Copper pointers while the Blitter is running perhaps?

There's a nasty bug in the hardware that can trash the Blitter D pointer in the middle of blitting: if you touch the COPJMP registers to latch the Copper pointer while the Blitter is running, then the D pointer may get overwritten.

Just pausing the Blitter temporarily by disabling Blitter DMA won't help, you have to make sure the Blitter has finished completely before touching COPJMP.

quick update

We isolated the problem to conflicting orders of routine calls.
It runs a bit more reliable now but still screws up when re-run from CLI after exiting on the 500.
Doc.K said he suspects a problem in his gl3d blitter code and is looking into it.
I think we can provide the A500 disk image for the party version by the end of May.

Now I can finally focus on polishing a final.