Non-cycle exact mode in 2.5.1

[Photon]

I installed WinUAE cleanly again on my PC to have something to test converted samples on quickly and transfer to (Amiga-formatted) CF.

1) If I use Fastest possible+cycle exact chipset off, Protracker 3.15 can't set loopvalue at the correct time, with any vblank, cia, or soft interrupt setting. So the interrupts are executed too fast or out of order. CIA interruptcounters probably already run at normal speed even if cycle exact is off? But the interrupt code seems to be executed at the wrong time despite this.

2) Non cycle exact also causes problems with system-friendly keyboard routines, Amiga-M f.ex. is repeated erratically, or Esc key in Asm-One 1.20. (Sometimes once, twice or 3 times with just a short press.)

Actually 2) seems to work if I go Cycle Exact for CPU and chipset, and then uncheck for both again It didn't fix 1), though.

Also, sometimes it's black window for 20 seconds before booting, if my CF card is in the reader. (not related to above)

Config attached. Bootlog is from normal CF boot, normal 3 seconds black window.

[Toni Wilen]

I use asmone very regularly without cycle-exact and never had any screen switching or keyboard problems.

You sure you don't have some weird system helper utilities running?

EDIT: also can't say anything without winuaelog.txt.

EDIT2: your config has cycle exact enabled? Also never use it with 68030+ unless you really know what it means.

[Photon]

OK, sounds promising And Fastest possible CPU+68060?

I'm using the same startup-sequence as for my real A1200-060, if that's what you mean. I shut down Autohotkey and Sound Volume Hotkeys (Windows), and got the Esc-repeat bug again now. Happens in Asm-One 1.02+ also. I've of course also used the same programs before in WinUAE and didn't get this problem. I noticed when I was cleaning up a source that I typed commands into the source and instructions on the command line I will set keyrepeat in Windows to slowest and see if that helps. (Edit: nope.)

I've used PT 3.15 before in WinUAE too of course. The only difference from before for both programs is that I don't run cycle-exact, which I did before.

The 'theory' about interrupts is probably wrong, though. So it's just two things that happen when you uncheck cycle exact. I think it's just for the CPU non cycle exact.

20 second wait before leaving blackscreen happened again now. Could it be looking at all external harddrives and waiting for spinup? Edit: happened again a bit later when CF was no longer in the reader. So unrelated to the CF.

Edit: booted with no startup-sequence now and ran Asmone from CLI. Same bug.
Edit: will give you winuaelog.txt.

[Photon]

Originally Posted by Toni Wilen

I use asmone very regularly without cycle-exact and never had any screen switching or keyboard problems.

You sure you don't have some weird system helper utilities running?

EDIT: also can't say anything without winuaelog.txt.

EDIT2: your config has cycle exact enabled? Also never use it with 68030+ unless you really know what it means.

Weird. Here is the config. Can't find winuaelog.txt under G:\WinuAE or under docs and settings.

[TCD]

Have you ticked this box:



? (sorry... couldn't resist )

[Toni Wilen]

And also test with normal 68020 configuration first. (and test latest beta too)

[Photon]

Originally Posted by TheCyberDruid

Have you ticked this box:



? (sorry... couldn't resist )

I have now. (Didn't it use to create that log file by default before?)

Also attached a winuaebootlog.txt (run after cycle exact unchecked), if you didn't have that Toni.

[Photon]

Originally Posted by Toni Wilen

And also test with normal 68020 configuration first. (and test latest beta too)

Sure, 68020 without cycle exact?

Nothing special to consider, just unzip the beta over 2.5.1?

Edit: Results 2.5.1, 68020:
Keyboard bug: even in 68020 normal mode, and also with Fastest Possible/chipset nonexact.

Protracker setloop: bugs if Fastest Possible is on, otherwise not. (Just as with 68060.)

Edit: Results beta:
(to be tested)

[TCD]

Originally Posted by Photon

(Didn't it use to create that log file by default before?)

It has been a Misc option for quite a while now

[Toni Wilen]

Just unpack the exe, nothing else needed.

But you should first minimize unknown variables, remove all unneeded harddrives etc. winuaelog.txt shows nothing interesting (except huge number of harddrives)

winuaelog.txt has never been created by default because it can slow down emulation.

[Photon]

Same behavior in beta 7, see logs.

Edit:
Regarding the Protracker bug, it bugs with 68020 cycle exact and no startup-sequence - with CIA timing and softint on. With CIA timing and softint off, it works with cycle exact off and normal 68020. If I drag the slider to 500% or turn on fastest possible, it bugs again. Smells like 'too fast for CPU wait loop', except it works on real fast Amigas.

[Toni Wilen]

Originally Posted by Photon

Regarding the Protracker bug, it bugs with 68020 cycle exact and no startup-sequence - with CIA timing and softint on. With CIA timing and softint off, it works with cycle exact off and normal 68020. If I drag the slider to 500% or turn on fastest possible, it bugs again. Smells like 'too fast for CPU wait loop', except it works on real fast Amigas.

Note that 68020+ CPU automatically (if not CE) will enable audio hacks that prevent buggy CPU timed DMA waits to not cause lost notes.

Attach bootable test disk image or zip archive (contains everything needed + short instructions. Make sure problem can be heard in max 30s or I lose interest and quite the emulator )

[Photon]

Ah. Didn't know this. An option to hack or not to hack maybe fixes the ones that do it correctly? Or something. My crystal ball (I have one too) says playroutine waits for rasterchange a few times if softint is off, and there's no DMAwait value so there's no DBF d0-loop.

Anyway here is a little zip file

[Photon]

It's not related to 68020, 68000 in non cycle exact + fastest possible also causes the Protracker sound bug. Just made a standard A600 3.1 8MB normal fastmem config, same phenomenon.