Problematic Demos.

[amilo3438]

Originally Posted by Toni Wilen

Usual bad copper wait. There are hundreds of those.

So, this (Tales Of A Dream by Dreamdealers) and similar (Megademo by Freedom Force & NorthStar Megademo3) can be treated as inside of a demo programming problem and not an Amiga emu problem, right?

[Toni Wilen]

Originally Posted by amilo3438

So, this (Tales Of A Dream by Dreamdealers) and similar (Megademo by Freedom Force & NorthStar Megademo3) can be treated as inside of a demo programming problem and not an Amiga emu problem, right?

Yes. Garbage in far left or right border is usually normal. It has to be visible in emulation because there are some programs that use max overscan and have actual real graphics there.

[amilo3438]

Pax Americana by Complex -> http://janeway.exotica.org.uk/release.php?id=19676

QS A500 OCS/ECS (see pic.1)(see pic.3)
QS A1200 AGA (see pic.2)

Does it happen also on a real A500? (didnt find anywhere mentioned that is AGA only)


EDIT: It doesnt happens if CE(Cycle-exact) = OFF!

EDIT2: Also it doesnt happens if CE(Cycle-exact) = ON and CPU Freq. = 4x, 8x ... (It happens only when CPU Freq. = 1x, 2x ... but it behaving differently.)

EDIT3: It doesnt happens if CE(Cycle-exact) = ON and CPU Freq. = Custom 7.093790 !!! (see pic.4)

EDIT4: Very interesting situation! -> Setting according to pic.3 glitches as shown on pic.1 but according to pic.4 runs fine as shown on pic.2 ?! Why?

[amilo3438]

Today have just finished with verifying whole 16 pages (16 x 25 = 400) of pouet Amiga OCS/ECS demos sorted/filtered according to thumbs-up ... see on link.

Also, I am not interested anymore to continue with verifying further pages as most of those other demos looks to be boring and not such demanding for an WinUAE emu testing as previous.

Hope that those already verified should cover enough demo coding tricks, if not all possible, so that there is then no need to continue with further testings.
But if there anyone who would want to continue, just go ahead!

p.s. Now only waiting for next official (fixed) version of WinUAE to come out. Hope it will happen before .

EDIT:
Reminder on comments and current status -> http://eab.abime.net/911206-post57.html

[amilo3438]

Originally Posted by Toni Wilen

Silly scroller finally fixed.

This was really difficult to debug because it was not actual chipset emulation bug but internal emulation bug (internal buffer was not always cleared correctly, this is another speed optimization, only clear just enough, never too much) when resolution or number of bitplanes change mid-scanline. For some reason this didn't trigger with Disposable Hero or others that really abuse BPLCON0 mid-scanline.

This is one of those demos that have (most likely accidental) BPLCON0 write mid-scanline. I am quite sure coder was confused, he probably thought it was some HRM or chipset bug, then he decided to adjust bitplane pointers and/or DDFSTOP/STRT until display was fixed.

Just for info...
Have just tested it on a newer WinUAE b7(19.09.2013.) and found that there are still some blinking line appears (see pic.) on same place where before the white line was. Note: Its impossible to see it on a picture as not the whole line is blinking, only partially!


The main question is that now noticed the "Phenomena" logo it looks to be somehow shifted ... (forgot on this before) ...
Does this also happening on a real Amiga ?!

EDIT: Blinking line appears seams to be fixed in WinUAE b8 (21.09.2013.)!

[Toni Wilen]

Originally Posted by amilo3438

Pax Americana by Complex -> http://janeway.exotica.org.uk/release.php?id=19676

QS A500 OCS/ECS (see pic.1)
QS A1200 AGA (see pic.2)

Does it happen also on a real A500? (didnt find anywhere mentioned that is AGA only)

It (accidentally as usual) writes to blitter registers while blitter is active. Results can be quite mysterious (blitter can stop, it can suddenly do something impossible and more..), practically impossible to fix without having blitter's original logic diagrams/schematics.

[amilo3438]

Originally Posted by Toni Wilen

It (accidentally as usual) writes to blitter registers while blitter is active. Results can be quite mysterious (blitter can stop, it can suddenly do something impossible and more..), practically impossible to fix without having blitter's original logic diagrams/schematics.

Its interesting that it doesnt happens on an AGA blitter ?! (Well, on an QS A1200 configuration.)

[Toni Wilen]

Originally Posted by amilo3438

Its interesting that it doesnt happens on an AGA blitter ?! (Well, on an QS A1200 configuration.)

It is not interesting. Blitter is exactly same, CPU speed can be very different.

[amilo3438]

Originally Posted by Toni Wilen

...practically impossible to fix without having blitter's original logic diagrams/schematics.

Hope you probably know for below, on 1st link it looks to be only basic block diagram, still could maybe happen you find something you missed on 2nd:

Blitter Block Diagram picture

Schematics

EDIT: Ok, just found that already exist an opened topic about -> Modifying blitter registers while it's running

[amilo3438]

The end by trilobit

Reminder about this one, still missing a comment?! (Probably has not been explained well there. It doesnt work on OCS as need ECS Agnus 1mb chip ram.)

Tested on beta 7 A500 ECS Agnus 1mb chip (see on pic. 2).

EDIT: It looks to working fine in WinUAE2.6.1 (last official) version! (see on pic.3)

EDIT2: It seems to be broken starting from beta 4 version!

[amilo3438]

Unreleased demo by Flash Production & Anarchy & Quartex

Does it happens on a real A500?!


EDIT:
p.s. Dont forget to check also EDIT3 from http://eab.abime.net/911918-post81.html !!!

[Toni Wilen]

Originally Posted by amilo3438

Unreleased demo by Flash Production & Anarchy & Quartex

Does it happens on a real A500?!

Yes. It is 100% correct.

The end by trilobit

No fixes yet.

[amilo3438]

Spectre party demo by Phenomena

QS A500 OCS (pic.1) ECS (pic.2) ... Does it happens on a real A500?!


EDIT: It looks OCS runs fine here too ... glitches on pic.1 probably appeared during 1st testing by accident.

[Toni Wilen]

Originally Posted by amilo3438

Spectre party demo by Phenomena

QS A500 OCS (pic.1) ECS (pic.2) ... Does it happens on a real A500?!

ECS causes blue bars (which is correct). OCS works fine here.

[amilo3438]

LTP4 MEGADEMO by x-metal force crew

On 3rd demo called "beirosinus" some glitches appears!

[amilo3438]

Originally Posted by Toni Wilen

It is not interesting. Blitter is exactly same, CPU speed can be very different.

This should be then interesting -> Cycle-exact = ON , Blitter is exactly same , CPU speed is exactly same -> and 2 different cases!

For more detail see EDIT4 on http://eab.abime.net/911918-post81.html !!!

[Toni Wilen]

Originally Posted by amilo3438

This should be then interesting -> Cycle-exact = ON , Blitter is exactly same , CPU speed is exactly same -> and 2 different cases!

For more detail see EDIT4 on http://eab.abime.net/911918-post81.html !!!

No, there is still nothing interesting, sorry

CPU speed did change. Multiplier = CPU clock rate is syncronized to chipset clock (sync clock). Value = manual value, async clock. Difference is not as small as you think it is. Even single cycle change can make huge difference during blitter accesses.

[amilo3438]

Originally Posted by Toni Wilen

No, there is still nothing interesting, sorry

CPU speed did change. Multiplier = CPU clock rate is syncronized to chipset clock (sync clock). Value = manual value, async clock. Difference is not as small as you think it is. Even single cycle change can make huge difference during blitter accesses.

Mentioned this as found both to be under same "Cycle-exact CPU Emulation Speed" option ... very confusing ?!

I always thought that cycle-exact = sync clock to chipset.


EDIT:Would it mean that cycle-exact isnt same as cycle-accurate then?!

According to this in WinUAE there are then 4 possible modes regarding A500 CPU Emulation Speed, right?

1) Cycle-exact sync clock (CE=ON, Multiplier CPU clock) = best compatibility mode!

2) Cycle-exact async clock (CE=ON, Custom CPU clock)

3) Approximate A500/1200 (CE=OFF)

4) Fastest possible (CE=OFF) = lowest compatibility mode!


EDIT2: Does cycle-exact should mean to synchronize processor between opcodes and cycle-accurate between cycles ?!

EDIT3: When comparing config. files of "CE=ON, Multiplier CPU clock" and "CE=ON, Custom CPU clock" found only one option different, else is same:

cpu_speed=real
cpu_throttle=0.0
cpu_type=68000
cpu_model=68000
cpu_compatible=true
cpu_24bit_addressing=true
cpu_multiplier=2
cpu_cycle_exact=true
blitter_cycle_exact=true
cycle_exact=true

cpu_speed=real
cpu_throttle=0.0
cpu_type=68000
cpu_model=68000
cpu_compatible=true
cpu_24bit_addressing=true
cpu_frequency=7093790
cpu_cycle_exact=true
blitter_cycle_exact=true
cycle_exact=true

So, CPU and blitter is cycle-exact on both ... but 1st mode work in sync and 2nd mode work in async between CPU and blitter, right ?

[Toni Wilen]

Originally Posted by amilo3438

LTP4 MEGADEMO by x-metal force crew

On 3rd demo called "beirosinus" some glitches appears!

Exact same on A500. Probably needs some specific config to not have glitches.

Plasma part bugs are also exact same.

Originally Posted by amilo3438

Mentioned this as found both to be under same "Cycle-exact CPU Emulation Speed" option ... very confusing ?!

I always thought that cycle-exact = sync clock to chipset.

Amigas can have sync or async CPU clock. A500 (and other 68000 based) and A1200 are sync. CPU clock = chipset master crystal (28.xMHz), usually divided by some power of 2 integer value. 7.xMHz, 14.xMHz, 28.xMHz are the usual values.

Async = CPU has separate clock crystal, for example any 25MHz or 33MHz (or more.). Only when CPU needs to access chipset addresses, CPU syncs with chipset clock (= CPU waits, sometimes it can be quite long wait), does the access and then continues normally.

[amilo3438]

Originally Posted by Toni Wilen

Amigas can have sync or async CPU clock. A500 (and other 68000 based) and A1200 are sync. CPU clock = chipset master crystal (28.xMHz), usually divided by some power of 2 integer value. 7.xMHz, 14.xMHz, 28.xMHz are the usual values.

Async = CPU has separate clock crystal, for example any 25MHz or 33MHz (or more.). Only when CPU needs to access chipset addresses, CPU syncs with chipset clock (= CPU waits, sometimes it can be quite long wait), does the access and then continues normally.

Thanks for clarifying this with very detail explanation.


EDIT: Last question ... If chipset master crystal=28.375160 why we have then in freq. option multipliers instead of dividers ?!

For example now we have choices with multipliers (instead of dividers):

1x 3.549865 (= master clock / 8)
2x 7.093790 (= master clock / 4)
4x 14.187580 (= master clock / 2)
8x 28.375160 (= master clock / 1)

Does 3.549865 freq. meaning something important?

As is a little confusing. Never understood why is this freq. chosen to be 1x instead of 7.093790 , as there is no Amiga exist that runs in freq. lower than this one.