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 .

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.)!

Attached Thumbnails

Last edited by amilo3438; 21 September 2013 at 14:31.
Reason: Small corrections.

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.

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.)

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.

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?

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

Plasma part bugs are also exact same.

Quote:

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.

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):