Couple of bugs found

[mark_k]

Hi,

I think I've discovered a couple of bugs in WinUAE (tested with 1.5.1). Can anyone confirm?

Emulation-related bugs first:

• Delicate Sounds by Razor 1911 (ftp://ftp.amigascne.org/pub/amiga/Gr...icateSound.dms):
  At the menu press F3 to select greetings, then F10. The text at the bottom of the screen is corrupted (but the reflection below it appears okay). That happens with cycle-exact timing, regardless of the emulated chipset (OCS, ECS Agnus, full ECS). No corruption on my ECS 1.3 A2000.
  
  
• PMC Mega Demo by Pure Metal Coders (ftp://ftp.amigascne.org/pub/amiga/Gr...C-Megademo.DMS):
  Boot and when the text about function keys appears press F7. Wait for the demo to load and decrunch, then press the LMB when prompted. There are problems with the upper part of the display, probably related to non-interlace to interlace mode switching. If you Alt-Tab out of then back to WinUAE the display corrects itself. (Notice also how the scrolling text at the bottom is almost unreadable due to the interlaced display. WinUAE's lack of an "interlaced scanlines" line mode which would make that readable is a bug in itself IMHO... )

Some other bugs/issues:

• If WinUAE is started with the "Don't show taskbar button" box checked, and the user unchecks that option and minimises WinUAE, there is still no taskbar button.
  
  
• When not showing a taskbar button, under Windows Vista, if the main window is minimised, it becomes a small title bar near the bottom left of the screen, just above the taskbar. If the user double-clicks the system tray icon to open the WinUAE settings window, then clicks Cancel, the mouse pointer is trapped in a small region of the screen below the minimised main window. If it has not been moved the pointer is trapped at the left side of the taskbar. If the minimised main window title bar has been moved up, the pointer is trapped in a small rectangle below it.
  
  
• There are two problems with the floppy drive sound feature. Enable floppy drive sounds. Start emulation, boot a floppy disk and when the drive motor sound is playing, press F12. Change to CD32 in the Quickstart page. Notice that there are no emulated floppy drives now. Click Reset. The drive motor sound plays continuously. The second issue occurs if you start WinUAE, make sure floppy drive sounds are disabled, then boot a floppy disk. While it is loading press F12, enable floppy drive sounds and click OK. There is no drive motor sound, only the head movement sound. A good disk to demonstrate this is ftp://ftp.amigascne.org/pub/amiga/Gr...GameSound1.DMS. The drive motor stays on when the bouncing disk hand appears, so press F12 then.
  
  Related to that, it would be good if there were an option to only play the head stepping sound, not the drive motor. Hearing the heads step can be helpful - you know when a program is loading - but many games and demos leave the drive motor on all the time.
  
  [Is there a problem with running SANITY-BestGameSound1.DMS? It wouldn't load fully on my ECS A2000, but the background behind the song list flickers, regardless of the chipset used in WinUAE. Is there any real Amiga that it displays correctly on?]

[Toni Wilen]

After 1.5.2 or later.

[mark_k]

Here are a few more issues...

The Digital Force demos Ode To Ramon and Ode To Ramon II both have scrolling text at the bottom of the screen which is corrupted, as if the bitplane modulos are wrong. Happens with cycle-exact OCS/ECS Agnus/full ECS emulation. http://ftp.amigascne.org/pub/amiga/G...OdeToRamon.DMS http://ftp.amigascne.org/pub/amiga/G...eToRamonII.dms http://ftp.amigascne.org/pub/amiga/G...deToRamon2.DMS
(The last two DMS files are different sizes; I haven't investigated what difference if any there is between them. Update: DF_OdeToRamon2.DMS is bad; tracks from offset $D1000 in the disk image all contain "DMS!!ERR" repeated. So use OdeToRamonII.dms instead.)


With no filter, start emulation, running something that has movement over most of the screen. Then enable "Correct aspect ratio" in the Display settings. The extra scanlines which are added to the Amiga display contain whatever happened to be there before, and do not update. (Presumably the extra lines should be the same as the scanline above, or a mix of the colours of the scanlines above and below.) This is pretty visually unattractive since those lines contain the same "trash" even after resetting or loading another program. If the Direct3D filter was enabled, and the user disables it, checks the Correct aspect ratio box, then continues emulation, the extra scanlines may be black.


When a sound is playing, if you click the tick icon at the top left of the window to bring up the window menu, the emulation pauses but the currently-playing sound loops over and over.


The A3000 Quickstart setting has two floppy drives. A3000s were (as far as I know) normally sold with one drive.


Not sure if this one qualifies as a bug; maybe it's desired behaviour? When the WinUAE emulation is running but the window is not active, I don't think it should receive input (mouse movement) when the pointer moves across it. Example scenario: user has WinUAE playing some music while working in other applications. Moving mouse from one window to another affects the emulated Amiga if the mouse passes over the WinUAE window. I think the emulation should only receive input when the user clicks inside the window (or Alt-Tabs to WinUAE).


One more for you... Start WinUAE. Select A1200 in the Quickstart page. (This might require you have an A1200 Kickstart 3.1 ROM image.) Start the emulation. After a second or two press F12. Change the settings like this: CPU 68000, match A500 speed, cycle exact, OCS/ECS Agnus/full ECS chipset, chipset extra A500, ROM Kickstart 1.2, RAM 512K chip. Click Reset. Get a yellow screen, flashing power LED and reboot infinite loop. That persists even if you press F12 and click Restart.

Or similarly, start WinUAE, select A1200 Quickstart. Start emulation. Press F12, select A500 Quickstart with 1.2 ROM, 512K chip RAM only. Click Reset. Get black screen (emulation seems to be running though).

[Toni Wilen]

Slow answers, one by one..

Originally Posted by mark_k

Then enable "Correct aspect ratio"

I'd prefer removing "Correct aspect" completely. Filters can do it already (may need some extra settings)

Would also simplify display code.

[Toni Wilen]

Originally Posted by mark_k

When a sound is playing, if you click the tick icon at the top left of the window to bring up the window menu, the emulation pauses but the currently-playing sound loops over and over.

AFAIK it is not possible to know when sysmenu is exited. I don't know when to stop or restart the sound.. (and DSound keeps looping if no new sample data sent and I am not going to add stupid thread that only watches for sound loops and stops it )

[andreas]

Originally Posted by Toni Wilen

I'd prefer removing "Correct aspect" completely.

Yes, PLEASE!
Never liked this option, because you can set something sane and then violently force WinUAE into a "correct" aspect (which will then somewhat undo your 'sane' settings)

[Toni Wilen]

Originally Posted by mark_k

The Digital Force demos Ode To Ramon

This is interesting! First, this is OCS-only. Same garbage on real ECS Agnus A500.

But this isn't your standard "lets use OCS-undefined DDFSTRT/STOP low bits" like Eliminator or Double Dragon.

This is something much more interesting, need to switch OCS Agnus to my "logic analyzer" A500..

Copper list is very simple (BPLCON1 writes are only for "ripple" effect, they don't have anything to do with this OCS-only effect)

My guess is that DDFSTRT=0x10 is the difference, it seems OCS allows earlier than 0x18 DMA start but it also makes bitplane hardware to miss next line's start. (scan-line effect)

"Unfortunately" both 0x10 and 0x14 DDFSTRT works in WinUAE so I can't know what real OCS limits are without LA tests.

Copperlist:

 000377e2: 0100 0000            ; BPLCON0 := 0x0000
 000377e6: ffdf fffe            ; Wait for vpos >= 0xff and hpos >= 0xde.
                                ; VP ff, VE 7f; HP de, HE fe; BFD 1
 000377ea: 0092 0010            ; DDFSTRT := 0x0010
 000377ee: 0094 00d0            ; DDFSTOP := 0x00d0
 000377f2: 008e b161            ; DIWSTRT := 0xb161
 000377f6: 0090 32d1            ; DIWSTOP := 0x32d1
 000377fa: 00e0 0003            ; BPL1PTH := 0x0003
 000377fe: 00e2 9ffb            ; BPL1PTL := 0x9ffb
 00037802: 0182 0000            ; COLOR01 := 0x0000
 00037806: 0180 0000            ; COLOR00 := 0x0000
 0003780a: 0001 fffe            ; Wait for  hpos >= 0x00.
                                ; VP 00, VE 7f; HP 00, HE fe; BFD 1
 0003780e: 0100 1000            ; BPLCON0 := 0x1000
 00037812: 0201 fffe            ; Wait for vpos >= 0x02 and hpos >= 0x00.
                                ; VP 02, VE 7f; HP 00, HE fe; BFD 1
 00037816: 0182 0000            ; COLOR01 := 0x0000
 0003781a: 0102 0001            ; BPLCON1 := 0x0001
 0003781e: 0401 fffe            ; Wait for vpos >= 0x04 and hpos >= 0x00.
                                ; VP 04, VE 7f; HP 00, HE fe; BFD 1
 00037822: 0182 040a            ; COLOR01 := 0x040a
 00037826: 0102 0001            ; BPLCON1 := 0x0001
 0003782a: 0601 fffe            ; Wait for vpos >= 0x06 and hpos >= 0x00.
                                ; VP 06, VE 7f; HP 00, HE fe; BFD 1
 0003782e: 0182 040a            ; COLOR01 := 0x040a
 00037832: 0102 0001            ; BPLCON1 := 0x0001
 00037836: 0801 fffe            ; Wait for vpos >= 0x08 and hpos >= 0x00.
                                ; VP 08, VE 7f; HP 00, HE fe; BFD 1
....

Screenshot clearly shows scanline-effect but there is nothing in copperlist that can do it. (WinUAE hacked with 0x10/0x14 DDFSTRT does not show scanline-effect either and text has 1/2 height)

ADDED:

My theory (which includes infamous "mysterious 4 cycle" delay as seen in copper thread): Because OCS has already known feature, disabling and re-enabling bitplane dma during scanline disables it completely until next time. (ECS can restart)

OCS DDFSTRT < 0x14 -> "mysterious 4 cycle" runs but because DMA is still inhibited until 0x18, DMA stops (4 cycle "gap"). No restart anymore until next line but because "mysterious cycles" have already run, next horizontal line is shown normally. And so on.

This would explain scanline-effect.

Following tests needed: (unfortunately my AR3 is damaged, going to do tests after Agnus transplant is done)
- DDFSTRT set to 0x14 should allow normal display but scanline-effect should disappear.
- DDFSTRT set to 0x10 or smaller should show normal display including scanline-effect. Even DDFSTRT set to zero.

Tested with Action Replay 1.. (what a pain..)

- DDFSTRT 0x14 = still works normally, scanline-effect works
- DDFSTRT >=0x18 = wrong modulo, no scanline effect
- DDFSTRT <8 = more graphics errors

So.. OCS DDFSTRT=0x18 "hard limit" seems to be broken. You can have earlier DDFSTRT but if DDFSTRT<0x18, every other line gets skipped. (missing/skipping bitplane start?)

[mark_k]

Interesting.

So for the scanline effect, how does it work? Suppose you have a source image 100 lines tall. Would the output with this effect be 200 lines, with a blank line in between each source line. Or, would the output be 100 lines, with a blank line in place of source lines 2, 4, 6, ...

(In other words, are the bitplane pointers updated on the blank lines or not?)

[Toni Wilen]

Originally Posted by mark_k

Interesting.

So for the scanline effect, how does it work? Suppose you have a source image 100 lines tall. Would the output with this effect be 200 lines, with a blank line in between each source line. Or, would the output be 100 lines, with a blank line in place of source lines 2, 4, 6, ...

(In other words, are the bitplane pointers updated on the blank lines or not?)

Bitplane pointers are not updated, like bitplane dma was disabled or number of bitplanes set to zero.

[mark_k]

Hi,

Here are another couple of bugs...

Run the "Blit" demo on Fred Fish disk 276. That uses a low-res interlaced screen, with a copperlist which makes the lower right corner high-res. When the mouse pointer is moved over the high-res area, it becomes half normal width, i.e. its pixels are high-res instead of low-res! If the pointer is only partly in the high-res area, part of it appears low-res and the other part high-res.

There appears to be a bug with the Direct3D filter when scanline transparency >0. With the default WinUAE display size, the transparency effect is not applied to the rightmost 16 pixels.

[Toni Wilen]

Originally Posted by mark_k

Hi,

Here are another couple of bugs...

Run the "Blit" demo on Fred Fish disk 276. That uses a low-res interlaced screen, with a copperlist which makes the lower right corner high-res. When the mouse pointer is moved over the high-res area, it becomes half normal width, i.e. its pixels are high-res instead of low-res! If the pointer is only partly in the high-res area, part of it appears low-res and the other part high-res.

Bug and not so bug. Horizontally mixed lores and hires is not yet supported (remember Disposable Hero title screen..)

But that was nice, there are now 2 known programs that does it

[Toni Wilen]

Originally Posted by Toni Wilen

This is interesting! First, this is OCS-only. Same garbage on real ECS Agnus A500.

Seems to work correctly if DDFSTRT=HPOS and HPOS=0x18 are considered separate steps when deciding DDF started state.

HPOS==0: clear DDF state. (this is also OCS-only, ECS does not clear it if previous line never reached DDFSTOP)
HPOS==0x18: change DDF state variable ("started") Probably at 0x14 because two simultaneous checks and state changes is most likely not possible. (and here is our infamous 4 cycle difference again..)
HPOS==DDFSTRT: change DDF state again ("active") but only if it was in "started" state previously.

-> properly working "scanline" effect if DDFSTRT < 0x18.

I still think this was meant to prevent 0 <= DDFSTRT < 0x18 but it was incorrectly implemented (and was fixed in ECS)

[andreas]

Sorry for interrupting, Toni, but the visible horizontal tear in some letters (e. g. in the 'W', recheck attached screenshot above) does not have anything to do with the issues described here I guess?

Looks like screenshot was done using windowed mode, where vsync has no effect.

[Toni Wilen]

Originally Posted by andreas

Sorry for interrupting, Toni, but the visible horizontal tear in some letters (e. g. in the 'W', recheck attached screenshot above) does not have anything to do with the issues described here I guess?

Looks like screenshot was done using windowed mode, where vsync has no effect.

That is not a screenshot...

Attached is a real screenshot

[andreas]

LOL. I'm convinced