Problematic Demos.

[ross]

Originally Posted by amilo3438

Does it work every time on the real machine or does it sometimes also cause problems?

For example, with the pack disk "BigMarcPack38.adf / F4" (In the Zone as TSB-LethalC.zip) it works in Denise emu after hard reset but not in the WinUAE!? (I wonder why)

Check the Zone.

You will find two versions, both with forced initialization.
In one case with a 'decent' value (probably not the one the programmer wanted, but that doesn't matter), the other with a problematic value.

Both should behave the same way in all situations, emulated or not.

[amilo3438]

I don't know, I don't care if a program is broken or not, but how it behaves in real conditions! (ie on a real machine)

There are two ways to make programs work: or set the emulator to run programs or set programs to run on the emulator! (which is the correct way?)

[ross]

Originally Posted by amilo3438

I don't know, I don't care if a program is broken or not, but how it behaves in real conditions! (ie on a real machine)

There are two ways to make programs work: or set the emulator to run programs or set programs to run on the emulator! (which is the correct way?)

In this case you must care if the program is broken because the glitches depend on the conditions in which it runs (down to initial CPU registers conditions!)
When I debugged last night I realized that the demo worked quite differently depending on the environment in which it started, until I found the very stupid setting of TB CRA and TAHI.

That's why I made you two new versions of the executable: I didn't change anything in the demo code, but only in the initial setting of the offending register, which is now constant
(the registers at code startup may not be identical even with identical physical configurations).

This allows you to understand if it is an emulation problem or not.
Now IT SHOULD work the same everywhere.

Please check it.

[amilo3438]

I already checked:
TSB-LethalC_sane ... works
TSB-LethalC_broken ... not working

on both emus, winuae and denise! (so valid for emu conditions)

But the original also works on a real machine! (still an emu problem to me)

Edit: Which would mean that the starting conditions in the emulator do not correspond to those in the real machine! (as I understand it)

(Except: "BigMarcPack38.adf F4: TSB / LethalC " works in Denise emu after hard reset but not in the WinUAE!?)

[ross]

Originally Posted by amilo3438

I already checked:
TSB-LethalC_sane ... works
TSB-LethalC_broken ... not working

on both emus, winuae and denise! (so valid for emu conditions)

But the original also works on a real machine! (still an emu problem to me)

No, my executables are to be tested on the real machine, not the broken original

In the real machine the conditions are simply created for that register to have a 'sensible' value, but is only by chance!
Even if you're using the same hardware setup it takes just a trifle to 'randomize' registers on program startup.

That's why only the defined ones (D0/A0) should be used, the others have 'undefined' values (if you exclude those from the BCPL framework, but that have nothing to do now)

If you still don't trust me, I can make another version that returns the value of D6 on exit, so you can see that it is the reason for all the mess and the emulation has nothing to do with it

[amilo3438]

Originally Posted by ross

That's why only the defined ones (D0/A0) should be used, the others have 'undefined' values (if you exclude those from the BCPL framework, but that have nothing to do now

So it could solve the emulator problem if the emulator uses "defined values" already at start or after a hard reset!? (or it is random in the emulator as well)

Edit: But the question of whether the problem ever occurs on the real machine (with the original demo) has still not been answered? (or confirmed with testing)

[ross]

Originally Posted by amilo3438

So it could solve the emulator problem if the emulator uses "defined values" already at start or after a hard reset!? (or it is random in the emulator as well)

Edit: But the question of whether the problem ever occurs on the real machine (with the original demo) has still not been answered?

It is not only a matter of 'values' but also of 'times' and 'previous order' of execution: in a multitasking environment like Amiga anything can happen before starting a program that changes the contents of the registers, even an allocation at a different moment is enough.
Moreover now WinUAE (rightly so) uses a random seed on startup which changes, like in real machines, some conditions.

However this is the offending code, look at how many reasons it is wrong..

			lea.l $00bfd000,a0
			move.b #$7f,(a0,$0d00) == $00bfdd00
			move.b d6,(a0,$0e00) == $00bfde00
			move.b #$ef,(a0,$0400) == $00bfd400
			move.b d6,(a0,$0500) == $00bfd500
			move.b #$81,(a0,$0d00) == $00bfdd00

D6 in never set at start.

Multiple reasons why it (do not) works by chance

[amilo3438]

I give up, it is beyond my ability to understand! (or I'm too stupid to process this or too stubborn)

[ross]

Originally Posted by amilo3438

I give up, it is beyond my ability to understand! (or I'm too stupid to process this or too stubborn)

There is a remote possibility that random writing to TB CRA activates an unknown mode of the CIA which allows it to work 'differently' (no, I do not believe it ).
Even if it seems impossible to me since there are high enough values of TAHI such that during the VBI a forced request to restart the timer before the underflow is always satisfied (so no CIA IRQ trigger and therefore audio DMA is not activated and notes are skipped).

In any case I ran out of ways to explain it to you, but sure my fault, don't worry

[rutra80]

I'm far from understanding too, but I understand the point of amilo that if the demo always works on certain real system, it should always work on the same emulated system (even if the demo is broken). If it does not, emulation is not accurate.

[Toni Wilen]

Problem with these kind of bugs where demo uses unitialized variables is that there is no true correct or false values. Value for example might come from uninitialized memory or from pack menu and so on. Even when booting exe directly, layout of the virtual ADF can affect it or floppy speed (WinUAE for example always uses turbo floppy when loading exes turned to ADFs)

Only correct test is to use existing ADF (for example some menu pack) or create your own ADF and use it. EDIT: and still floppy mechanical differences can affect it.

[amilo3438]

Originally Posted by Toni Wilen

Only correct test is to use existing ADF (for example some menu pack) or create your own ADF and use it. EDIT: and still floppy mechanical differences can affect it.

I made some more detail test from other pack disk too about the music problem on denise emu! https://eab.abime.net/showpost.php?p...2&postcount=91

[amilo3438]

And the same test as above in winuae:

Lethal (Demo) by The Special Brothers http://janeway.exotica.org.uk/release.php?id=1070
tested on latest beta 7z (13.07.2023.):

--------------------------------------------------------------------------------------------------------------
WinUAE configuration:			KS 1.3 ECS 512+512		 KS 1.3 ECS 512
				  	(after hard reset)		(after hard reset)
--------------------------------------------------------------------------------------------------------------
From creaated adf:
------------------
TSB-LethalC.adf				-				- (it returns to CLI)
					+ (if started from CLI)
--------------------------------------------------------------------------------------------------------------
From pack disks:
----------------
Angels-CompactDisk05.adf		-				+
Awesome-CriminallyInsane09.adf		-				+
BigMarcPack38.adf			- (work in denise emu!)		- (it returns to CLI)
BJ-DemoLibDisk046.adf			+				-
LSD-AddictionPack050.adf		+				- (Guru Meditation)
PowerXtreme-DemosPack4.adf		+				-
Rebels-DizzyDream07.adf			+				+
SCOOPEX-RangerPack136.adf		+				+
Treacl-DreamPack3.adf			+				+ (weird 1st sounds)
TRSI-TuffStuff15.adf			+				+
TSB-InternPack36.adf			-				+
TSB-Luxpack03.adf			-		  		- (it stops, but denise emu has problem here)
UFO-DemoPack.adf			- (work in denise emu!)		+
--------------------------------------------------------------------------------------------------------------

+ = work
- = not work

Almost same as denise emu except two pack disks in the KS 1.3 ECS 512+512 configuration that not work in winuae!

EDIT: I wonder if these few that work in KS 1.3 ECS 512 and not in KS 1.3 ECS 512+512 config are working on the real machine in KS 1.3 ECS 512+512!? (and one that does not work in any configuration)

[Zarnal]

@amilo3438

Good morning,

I didn't quite understand the problem. Without checking on hard beforehand, we cannot know the "good" behavior (even random).

Some of the menus of the packs can leave "traces" after a reboot (or even a first launch) which can alter the operation.

Is it concretely that there have been repeated tests on real hardware (Agnus ECS 512+512) for your tests on the compilations?

I will look with the executable alone on Adf. And I will have it checked on hard (if possible) under the same conditions.

[Toni Wilen]

Turtle Party Intro (Intro) by Image ... http://janeway.exotica.org.uk/release.php?id=846

Originally Posted by Toni Wilen

But there is also a difference: glitch graphics also "wraps" around to left border of display on real HW. Need to debug more..

Fixed. (as in corruption if ECS is now correct)

[rutra80]

Is Syntro-n (Crack Intro) by Capsule properly rendered on WinUAE? From what I understand it should interlace middle part of the screen, but on WinUAE emulating A500 whole screen is interlaced, and on emulating A1200 only middle is laced but lacks resolution. Is it consistent with real hardware?
http://janeway.exotica.org.uk/release.php?id=105524

[ross]

Originally Posted by rutra80

From what I understand it should interlace middle part of the screen

There is no "interlace middle part of the screen".
The field either it is interlaced or progressive (the choice of short or long frame display is made at the beginning of the vertical blank).
You can simply choose whether to 'duplicate' the lines displayed, a bit like dragging two wb screens with the two resolutions mixed.

, but on WinUAE emulating A500 whole screen is interlaced,

And it is correct.

and on emulating A1200 only middle is laced but lacks resolution.

I don't know if I understood this sentence correctly.
However, I don't see any differences in WinUAE between A500 and A1200 emulation.

Are we using different versions?
Or I don't understand what difference I should see

[rutra80]

My A1200 config seems somehow corrupted because in the demo it adds scanlines even though they are off everywhere (on AmigaDOS screen there are no scanlines)... Doesn't happen on Quickstart. Newest official 5.0.0
Sorry for confusion.

[ross]

I was exploring the possibility that there was a 'field dominance' issue (and this would imply a bad initial setup code).
And when trying various starts I got random crashes of the intro with the A500 configuration.

So for sure there's some little problem.. if it were in the setup it would explain the possible noticed (I haven't seen it though, but from what you've described it could be that) inverted fields and it can be corrected.
Do you happen to start the intro from a wb in interlaced mode?

I'll look at it better tomorrow

[rutra80]

No I start it via mounting the archive as floppy. I might record video of how it is - are you interested in A500, A1200 issue, or both?