WinUAE 2.0.0 beta series

[Ian]

I know what Toni meant

I was in a rush had to sort some students out.

Let me elaborate:

The disc boots fine, I press fast forward to load Oscar, it loads for a few seconds then nothing. No audio, no title screen (or whatever you want to call the scrolling thing at the start) the CD indicator stays solid blue as if it's reading something but it never gets any further.

[Steve]

Originally Posted by Ian

The disc boots fine, I press fast forward to load Oscar, it loads for a few seconds then nothing. No audio, no title screen (or whatever you want to call the scrolling thing at the start) the CD indicator stays solid blue as if it's reading something but it never gets any further.

Ok I can confirm that the game intro doesn't boot correctly when using the cycle-exact option. After about 20 seconds of no disc activity and a black screen I suddenly get the music playing and still the black screen. You can't progress any further.

This game doesn't need cycle exact though so why would use it anyway?? It boots fine if this is turned off. I don't think this is really a major issue but Toni might think otherwise.

[Toni Wilen]

Originally Posted by Steve

Ok I can confirm that the game intro doesn't boot correctly when using the cycle-exact option. After about 20 seconds of no disc activity and a black screen I suddenly get the music playing and still the black screen. You can't progress any further.

This game doesn't need cycle exact though so why would use it anyway?? It boots fine if this is turned off. I don't think this is really a major issue but Toni might think otherwise.

Yesterday I did test with official previous beta using ce and it did work fine.. and everyone MUST use new cycle exact now (at least you must mention if you DON'T use it, as usual. Quickstart only anyway), thats the whole point of this beta series

Anyway, wait for next beta. too many changes happening too regularly now..

[Ian]

You are missing the point Steve.

Toni has done a lot of work on cycle exact mode so if something doesn't work it's going to improve the compatability.

It also doesn't use 100% CPU time, which means less fan noise.

Toni, if it still doesn't work for me I will do further testing in a few days with whatever beta we are at then.

[andreas]

Originally Posted by Ian

You are missing the point Steve.

Toni has done a lot of work on cycle exact mode so if something doesn't work it's going to improve the compatability.

I fully agree. A "hooray! it works when I turn off CE" will go against the ambitious thinking to gain quasi-perfect compatibility.
CE-mode should always be the reference mode for beta tests (this does NOT necessary apply to you gamers who maybe save some CPU load by turning this off!!)

[Toni Wilen]

Originally Posted by Steve

Another thing I noticed on the quickstart was that the compatibilty settings for my Sidewinder Plug & Play gamepad are set wrong and aren't like a real CD32 pad. The settings are set to this:

0 = Red, 1 = Blue, 2 = Yellow, 3 = Green, 4 = FFW, 5 = RWD

The correct setting should be this:

0 = Red, 1 = Blue, 2 = Green, 3 = Yellow, 4 = RWD, 5 = FFW

Not beta related but you are right

Just tried that version using the quickstart CD32 option. No difference. Did you get the palette change playing the CD32 version because its definitely not working here.

Yes, palette changed.

I've noticed the HOST settings remain as the previous custom settings if you load a quickstart setting. Is it supposed to do that?? I assume it does that by design. Had me puzzled for a while.

Quickstart sets hardware settings, settings that specify Amiga model, emulated hardware features etc.. Host setting is user configuration and it does not change emulation compatibility.

(took long enough to notice..)

I've just tested all the betas to see when the first occurence of slow-motion in Oscar CD32 occurs. It seems that Oscar is broken and doesn't get further than the intro sequence in betas 1 to 7. In beta 8 the game loads properly but then slowdown is evident in this beta.

Mystery solved: There are 2 Oscar & Diggers images.

Diggers & Oscar (1993)(Commodore)[!][compilation][AMIGA-CD 31, 54] (10 audio tracks)
Diggers & Oscar (1993)(Commodore)[!][compilation][AMIGA-CD-V2] (23 audio tracks)

EDIT2: "31, 54" No palette change. "V2" = Palette change.

"V2" works, "31, 54" freezes when loading.

EDIT: "31,54" has totally crappy code:

00131970 303c 0190 MOVE.W #$0190,D0
00131974 323c 07d0 MOVE.W #$07d0,D1
00131978 51c9 fffe DBF .W D1,#$fffe == $00131978
0013197C 51c8 fff6 DBF .W D0,#$fff6 == $00131974

CPU delay loop before taking over the system. If too early system takeover: CD driver data prefetches are still active, result is never-ending INT2 "interrupt storm". Game takes over INT2 but of course it does not know how to clear Akiko interrupts..

This probably worked previously when CD hardware emulation was too crappy and data prefetching never really worked without retries..

[andreas]

Excellent work Toni. Unless this works on the REAL CD32, the [!] in the TOSEC name should be revoked on the double with the [31,54] version!
I could throw up whenever I see these DBF loops

[Ian]

All the [!] means it two or more people have produced exactly the same image from original images. (In the CD dats anyway)

I doubt a dodgy image would cause bad code. It is likely that the image still works perfectly on a real CD32.

I guess it's something to do with daemon tools (and real CD drives) are way to quick for the crappy code to run properly.

[Steve]

Originally Posted by Toni Wilen

Mystery solved: There are 2 Oscar & Diggers images.

Diggers & Oscar (1993)(Commodore)[!][compilation][AMIGA-CD 31, 54] (10 audio tracks)
Diggers & Oscar (1993)(Commodore)[!][compilation][AMIGA-CD-V2] (23 audio tracks)

Thats great Toni!! You're the original Sherlock Holmes!

The Oscar CD I have has the code AMIGA-CD 54 and it seems to be almost a beta release before the fixed V2 version came out. I have just bought another copy off eBay for a couple of pounds and the seller tells me the code is AMIGA-CD-V2 22. Here is an image of another version maybe? AMIGA-CD-V2 31.

http://www.toseciso.org/scans/91_disc.jpg

Anyway well done. I look forward to testing the new V2 version when it arrives. Incidentally the graphics glitches I mentioned earlier are fixed when CE is used.

[Toni Wilen]

Originally Posted by andreas

Excellent work Toni. Unless this works on the REAL CD32, the [!] in the TOSEC name should be revoked on the double with the [31,54] version!
I could throw up whenever I see these DBF loops

Where did I say it does not work on real CD32? I only said it is stupid and uses CPU loops and if you have been reading this thread you would have noticed something about 68020 CE CPU timing..

[Steve]

Can you rename the 'Display Card' tab to something else please like 'Gfx Card' or 'RTG Card'. Having 2 Display tabs near each other is a bit confusing. lol.

[andreas]

Originally Posted by Toni Wilen

Where did I say it does not work on real CD32?

Sorry!
Well, frankly, I had just concluded it indirectly from facts. This...

If too early system takeover: CD driver data prefetches are still active, result is never-ending INT2 "interrupt storm". Game takes over INT2 but of course it does not know how to clear Akiko interrupts..

The part in boldface first sounded to me like "Game chokes" or "Game may choke or may not, depending on every single run" (or weather )
But at second read, it became clear. Sorry for the noise.

OK, back on topic:

As I take it, to support the [31,54] version, it will be required to modify WinUAE so that the situation of the system being taken over too early cannot occur. Correct now?

[Toni Wilen]

http://www.winuae.net/files/b/winuae_2000b13.zip

Beta 13:

- MMU emulation bug fix (was bug in Aranym's code, official fix now included), fixes MMULib crash
- other MMU emulation fixes
- Gayle IDE address mapping corrected, reserved Gayle expansion space not included anymore
- CD32/CDTV CD led flickers blue when there is CD activity, shows green when playing CD audio
- built-in hrtmon updated to 2.31
- 68020 cache freeze-bit emulation fixed
- CD32 pad default mapping green and yellow buttons switched
- MOVES fixed (this has always been wrong but nobody noticed because it is only used with MMU)
- bsdsocket: support MSG_WAITALL (previously recv() with MSG_WAITALL always returned -1)
- 68020+ bit field instruction update from Aranym (correct memory access size for MMU and CE020. BFCHG, BFSET ignored size)
- more regstruct (ccrflags) removal
- added U <logical address> debugger command, shows translated physical addresses (user+code,user+data,super+code,super+data. RW=readwrite, RO=readonly) or * if address is not mapped (accessing it would cause access violation)

[Steve]

Originally Posted by Toni Wilen

- CD32 pad default mapping green and yellow buttons switched

The RWD and FFW buttons are still the wrong way round.

[JohnF]

Just to confirm these also occur in beta 13.

Let me know if you want savestate(s) (the colour bars are ~10 minutes into the demo).

Originally Posted by JohnF

Same in Beta 12 2009.09.01.

Also noticed a minor audio glitch: when the 'revolution' sample is played (accompanied by the word on screen), the sample repeats.

[Kyon]

thread name will be bump to 2.0.0 beta series ?

[Toni Wilen]

Originally Posted by JohnF

Just to confirm these also occur in beta 13.

Let me know if you want savestate(s) (the colour bars are ~10 minutes into the demo).

I tested and couldn't hear or see anything wrong. (in either parts)
Run without statefiles again to confirm it.

[JohnF]

Originally Posted by Toni Wilen

I tested and couldn't hear or see anything wrong. (in either parts)
Run without statefiles again to confirm it.

No no, I wasn't using statefiles while testing (just offering if helpful).

I've just re-produced the missing colour bars twice in a row using b13 - see attached ddbad.png and associated log. It should look like ddgood.png

The sound glitch appears to be intermittent, grrr.

[Toni Wilen]

Originally Posted by JohnF

No no, I wasn't using statefiles while testing (just offering if helpful).

I've just re-produced the missing colour bars twice in a row using b13 - see attached ddbad.png and associated log. It should look like ddgood.png

The sound glitch appears to be intermittent, grrr.

Ok, attach the statefile, please. Sound could be related to cube issue..

[Kettenhund]

found a graphical glitch again. this time in the "State of the Art" Demo. It runs fine with cycle-exact on, but turned off it produces the following glitch.

in previous versions it looked fine even with cycle-exact off.

[JohnF]

Originally Posted by Toni Wilen

Ok, attach the statefile, please. Sound could be related to cube issue..

Two state files (just before, and during) zipped and attached.

The strange thing is, when I load the dd-before state (fresh start of winuae), the colour bars don't disappear.

To be clear, when the colour bars do disappear, they were present when the cube first appeared, then disappear as the cube grows.

[dlfrsilver]

Originally Posted by Kettenhund

found a graphical glitch again. this time in the "State of the Art" Demo. It runs fine with cycle-exact on, but turned off it produces the following glitch.

in previous versions it looked fine even with cycle-exact off.

Now cycle-exact is the rule.

[Toni Wilen]

Originally Posted by dlfrsilver

Now cycle-exact is the rule.

Not really. It is case-by-case and SOTA does not have anything tricky so it should still work

[Toni Wilen]

Originally Posted by JohnF

Two state files (just before, and during) zipped and attached.

The strange thing is, when I load the dd-before state (fresh start of winuae), the colour bars don't disappear.

To be clear, when the colour bars do disappear, they were present when the cube first appeared, then disappear as the cube grows.

Something is corrupting the copper list. Copper list is generated just before cube appears, it is corrupted in "during" statefile, "before" generates it correctly. I guess statefile needs to be created earlier, perhaps before the starfield even appears.

[JohnF]

Originally Posted by Toni Wilen

Something is corrupting the copper list. Copper list is generated just before cube appears, it is corrupted in "during" statefile, "before" generates it correctly. I guess statefile needs to be created earlier, perhaps before the starfield even appears.

New statefiles attached that both show the problem (also tested these on a separate/older XP SP3 machine, same result once I remembered to set Best Compatibility).

[Steve]

I recieved Oscar V2 in the post this morning. Its brand new as well which is pretty amazing. Not a scratch on it! Anyway just thought I'd let you know that this version works perfectly using the latest beta. Seems this V2 doesn't suffer from the same slow-motion effect in WinUAE, unlike the V1 which have. The palette change works correctly and CD music plays during the levels. Great stuff!

The only small problem I noticed was that the CD music started a tad early before you get to the level screen. Its only early by a couple of seconds or so and this probably occurs on a real CD32 anyway. It seems like a good stable beta at the moment!

[Toni Wilen]

Originally Posted by JohnF

New statefiles attached that both show the problem (also tested these on a separate/older XP SP3 machine, same result once I remembered to set Best Compatibility).

Unfortunately I can't find anything obvious, probably usual demo bug that only accidentally works. (yes, it did work on older versions but they had blitter timing bugs)

This won't be fixed. At least not until some other program is found the can be debugged more easily. (this isn't simple blitter directly corrupting some data)

Originally Posted by Steve

The only small problem I noticed was that the CD music started a tad early before you get to the level screen. Its only early by a couple of seconds or so and this probably occurs on a real CD32 anyway. It seems like a good stable beta at the moment!

It may be "bug", CD audio seek delays (CD32 CD seeks are really slow, can be more than 1 second..) and CD audio fades are not emulated.

[JohnF]

Originally Posted by Toni Wilen

Unfortunately I can't find anything obvious, probably usual demo bug that only accidentally works. (yes, it did work on older versions but they had blitter timing bugs)

This won't be fixed. At least not until some other program is found the can be debugged more easily. (this isn't simple blitter directly corrupting some data)

Okay Toni, thanks for looking.

[Toni Wilen]

Originally Posted by JohnF

Okay Toni, thanks for looking.

It is guaranteed there are demos with other issues that will help fixing this, only problem is lack of time

[Toni Wilen]

http://www.winuae.net/files/b/winuae_2000b14.zip

Beta 14:

- added very basic MMU statefile support
- and more MMU compatibility updates (LINK, RTD, CMPM)
- FTRAPcc fix from Aranym (I guess nobody uses this instruction..)
- MMU access error instruction restart update, Linux really works now but is quite useless because there is no hardware cdrom or network emulation..
- CD32 pad default mapping RWD and FFW swapped
- non-CE mode blitter timing fix (blitter timing got better few betas ago but it was less compatible because cpu is not slowed down..)
- bsdsocket MSG_WAITALL really works now
- added "value must change" debugger memwatch mode (C)
- another reading write-only (or more like "read-only") register update, reading 0xDFF000 always returns whatever was left on chip bus. Only on OCS chipset and only 0xDFF000 (BLTDDAT) does this. Correct fix for Codetrash. This demo has really "fun" bug, it does cmp.b #$30,$dff000;bne.s loop (should be $dff006) and this comparison only succceeds because of 0xDFF000 special case AND because module player is running and there is at least one audio sample with value of $30! (unbelievable, isn't it?)

[Steve]

When I start emulation using any of my configs the first thing to pop up is the WinUAE debug window.

[Toni Wilen]

Originally Posted by Steve

When I start emulation using any of my configs the first thing to pop up is the WinUAE debug window.

Redownload. I forgot some debugging code..

[Mclane]

Same here, if you load up as an A500 you can't even get rid of the debug window, I had to shut the task down. I deleted the stored registry setting and it's the same.

Rescanned the roms, the same..

A1200 mode sends it straight to the debug window, A1000 mode does not even boot

[Mclane]

oops...ignore last

EDIT:

Redownloaded 3 times and same thing still...I'll try a shut down and a clear cache incase it's that..


EDIT 2: Fine now, must have been the cache being saved..

[JohnF]

Originally Posted by Toni Wilen

It is guaranteed there are demos with other issues that will help fixing this, only problem is lack of time

Here's another:

Day of Reckoning/Digital (DDC0E168): In the credits/end part, a black horizontal line appears towards the bottom of the screen (first visible when spaceship comes on screen) in b10 through b13. No black line in b9 and earlier (tested back to b2).

I can't tell what happens in b14 as the demo Gurus after the 'firework with a trail' - log attached.

[JohnF]

Another example of a horizontal black line can be seen in Speedball 2 (IPF 180 - C9BF9330), on the intro screens, in b4 through b14. The line starts twitching when 'LOADING GAME'. No black line in b2 and b3.

[DamienD]

Originally Posted by JohnF

Another example of a horizontal black line can be seen in Speedball 2 (IPF 180 - C9BF9330), on the intro screens, in b4 through b14. The line starts twitching when 'LOADING GAME'. No black line in b2 and b3.

Is this the same thing that we discussed in an old thread JohnF?

... Picture bobbing 1 rasterline up and down

If not then please ignore my comment.

[JohnF]

Originally Posted by DamienD

Is this the same thing that we discussed in an old thread JohnF?

... Picture bobbing 1 rasterline up and down

If not then please ignore my comment.

The video looks very similar, except in my case the line is visible more of the time than not.

[Deleauvive]

Could anybody try, in WinUAE beta
Lancelot and/or Gnome Ranger WHDload slaves with cycle exact enabled, plz ?


I am currently suspecting a possible bug with cycle exact enabled, but I can't really say which side it is : WHDload or WinUAE.

Left of the cursor, you may notice some letters getting truncated.
It doesn't happen with Cycle Exact unticked
AND
it doesn't happen when simply loading the ADF of that game from the WB.

If you need me to post about this
in prb games or in another section, just let me know.


This not aimed at distracting the cycle exact supporters
to use this setting extensively,
as it may not induce any noticeable errors for other types of games.

[Deleauvive]

Since I have my CD32 config. ready to roll, I thought I could fire Oscar v2 ISO (also holds Diggers) for a few seconds, and apparently, it's working fine. Seems the Amiga game developers never got tired of coding colorful jump'n'runs !

@Steve
I guess it's my turn to send you a CD32 config if you still have issues with it