input automatically swapped to Catweasel

[Marcuz]

i've tryed the last beta today; what follows it's a pointer to a problem that is NOT beta related, but it's related to - i suppose - the way each successive beta and main release handles .ini and configs.

as the title says, the input i select in winuae game ports panel gets automatically swapped after few instants to a catweasel joystick/port.

i reported this already during 1.5.4/1.6.0 betas and it was not solved if not deleting all configurations and write new ones from scratch. (catweasel is updated to the last drivers, no button on joystick is stuck; the catweasel resources are correctly related. also all was working fine in the 1.6.0 release; it both happen with "catweasel=1" and "catweasel=0". most important, between my last report of that problem and now Windows and catweasel have been reinstalled, and this setup is pretty much a vanilla one.)

also, when the mouse thing happen, concurrently other configurations that worked in the previous release (in this case it is the 1.6, but in the case of my previous report, it happened between 2 different betas) stop to work at all, crashing winuae without dump created.

this mean i guess that

when you execute a new winuae.exe in its directory, either some setting not in the configuration you load gets saved (in the ini or in the registry) that is not compatible with an older ini

or

that if you load a configuration file from a previous version of winuae and save it without modification with a newer one, it actually HAS some setting changed that makes it uncompatible with an older Winuae.

or still that catweasel screws with winuae in ways i can't fathom, but this one it's a a bit far fetched.

anyway, here the logs of the one configuration that changes the inputs and the one that crashes.

the "inputdevice change" calls in the logs are my manual switching back to mouse, that winuae had switched to catweasel joystick port 2 i think.

in the crash logs, using an identical configuration that worked with 1.6.0 before 1.6.1 was used, you can see that a minidump is created only with 1.6.0


can you shed some light please? i wouldn't mind do new configurations files each time i use a new version of Winuae, but i would like to see fixed the input problem once for all

[Toni Wilen]

Do not use fullscreen. It can prevent creation of crash dumps. (practically NEVER use fullscreen when testing/debugging if it is not fullscreen related)

Also disable winuae.ini first. (unsupported stuff enabled = not supported at all unless it is 100% proven it is really ini related problem)

[Toni Wilen]

Originally Posted by marco pedrana

the "inputdevice change" calls in the logs are my manual switching back to mouse, that winuae had switched to catweasel joystick port 2 i think.

I am not so sure about that.. (to confirm use -log parameter)

Message means catweasel joystick was moved from port 1 to port 0 because second button was pressed (GUID matches with the CW device in bootlog)

I'd say this is CW (driver) bug causing ghost joystick second button presses. Or perhaps SID issue (If I remember correctly, 2nd and 3rd button are read via SID if SID is installed) Try without SIDs

[Marcuz]

tested again, after having deleted the winuae.ini file;

at the first starting (i've started the 1.6.0 version first), the kickstart path was missing so i relinked it; the same happened at the first start of winuae 1.6.1 some hours ago, with the winuae.ini present. i don't know if it's relevant, anyway;

- tested the crashing configuration again, windowed (it was already that before) only difference being the lack of winuae.ini;
Winuae crashes again, still NOT producing the dump in the case of version 1.6.1*.

- tested the input problem again: in windowed mode the mouse works again, it's not clear if the pointer movement is fluid, i believe it is constantly remapped to the mouse, but anyway it works.

if you then switch to fullscreen, the input gets switched back to catweasel and if then you get back to windowed mode without to change the mapping, at the first click of the mouse button, the pointer gets correctly switched back to its input.

the logs are attached.

[edit]sorry, just now seen your last post, now i'll go check that too

[edit 2] corrected: * it's winuae 1.6.1 that doesn't produce a dump when crashing.

[Marcuz]

Originally Posted by Toni Wilen

I am not so sure about that.. (to confirm use -log parameter)

Message means catweasel joystick was moved from port 1 to port 0 because second button was pressed (GUID matches with the CW device in bootlog)

I'd say this is CW (driver) bug causing ghost joystick second button presses. Or perhaps SID issue (If I remember correctly, 2nd and 3rd button are read via SID if SID is installed) Try without SIDs

tested with the -log parameter;

with it, the input problem is solved in both fullscreen and windowed modes, the pointer movement is fluid in windowed too.
without it, the problem appears again.

this time i have not changed the input settings in the gui when mouse was not responding, i've simply quit: in the logs, the line "inputdevice change" doesn't appear.

also, the SID is not installed, as far as i know: there's no track of that driver in Windows device manager panel.

as much as i agree that catweasel is a scary hardware, when it comes to its drivers, what puzzles me is that winuae handles a configuration until a new version is used, at which point something changes.

i attach the logs of the -log parameter enabled and disabled again; the other config. keeps crashing anyway.

[Toni Wilen]

Originally Posted by marco pedrana

as much as i agree that catweasel is a scary hardware, when it comes to its drivers, what puzzles me is that winuae handles a configuration until a new version is used, at which point something changes.

I already replied in some older thread: Since 2.5 or so CW drivers have its own input driver. WinUAE does not directly poke the device anymore because it would cause even more conflicts.

[Marcuz]

i know that, i did not meant that the problem it is in winuae handling input, but in something that different releases of winuae change in some setting, maybe overwriting with a default instruction, one that i have unknownly changed and that regards input? or catweasel itself? or something else entierely?

otherwhise, how do you explain an unchanged (looking at the datestamp) configuration stopping to work suddenly, in any winuae release once you use a newer winuae? not working even in releases that used to work flawlessly before, in regard both input and crash i've just report here.

[Toni Wilen]

Originally Posted by marco pedrana

i know that, i did not meant that the problem it is in winuae handling input, but in something that different releases of winuae change in some setting, maybe overwriting with a default instruction, one that i have unknownly changed and that regards input? or catweasel itself? or something else entierely?

I don't know but because I can't test it myself (no 64-bit drivers) = I won't debug this unless there is some very obvious bug. (but I don't go looking for that). Sorry.

otherwhise, how do you explain an unchanged (looking at the datestamp) configuration stopping to work suddenly, in any winuae release once you use a newer winuae? not working even in releases that used to work flawlessly before, in regard both input and crash i've just report here.

Attach working and non-working (after it has been "modified") configuration. (perhaps you already did it but at least it wasn't very clearly marked..)

[Marcuz]

Originally Posted by Toni Wilen

Attach working and non-working (after it has been "modified") configuration. (perhaps you already did it but at least it wasn't very clearly marked..)

the configuration is not changed at all (the datestamp of the file says last modification is january) only the winuae.ini and, when the ini is not present, the registry.

possibly the not crashing version does work because was resaved with the new version?

what i can do is to try to have a working config. in 1.6.0, save it and copy it somewhere; load it in 1.6.1, see if it don't work and if it doesn't, save it and post both to comparison. if it is useful i will do it as soon as i can (tomorrow)

[Toni Wilen]

Ah, ok.. Perhaps there is still some problem with aspi? (your config file had aspi enabled)

[Marcuz]

Originally Posted by Toni Wilen

Ah, ok.. Perhaps there is still some problem with aspi? (your config file had aspi enabled)

mmm i hadn't thought to check that in the older configs, after the 1.6.1 was out; i will do it along with the other test tomorrow, i'm sorry not to be able to look before, i'm buried in work today

[Marcuz]

i got me the time to test it more, but the problem gets more complicated

a bit of clearify:

1) the configuration that i have tested, the same as before, as i said it crashed winuae 1.6.0 and 1.6.1, but only since i have put winuae 1.6.1 in the directory: it worked before with 1.6.0 flawleslly (inputs too)

the difference between the crashes (please note that while they happen in all screen modes, i'm now referring to windowed modes for accuracy of the test) is that 1.6.0 produces a minidump, 1.6.1, it does not.

(for the above, check the post n.4 of this thread).

2) as per your suggestion i check a different setting for aspi:

- 1.6.0, with SPTI usually loads to the WB; the input problem is there.

i said usually: it looks completely random, using the same exact sequence:
> start winuae
> load the configuration
> change the aspi setting to SPTI, don't save
> hit the run button
-----> WB may or may not load completely: usually 1 on 4 tests end up with a cli window.


nero and frog still crash;
both uaescsi.device switched off and uaescsi.device switched on with "SPTI+scsi scan" selected do not crash winuae but it halts the loading of the WB at some point of the startup sequence (i guess that so far, all of that is expected, right?)


- 1.6.1 crashes still in all the different uaescsi.device different settings; even disabling the uaescsi.device there's no difference. NO dump created still.

----------------------------------------------------------------------------------


since it gets too complicate for me too to follow, i post here the configuration i've tested: one is the original one (pre 1.6.0); the other two are the same configuration saved by the 1.6.0 and by the 1.6.1: in both cases i've loaded a different copy of the original one and saved it with the version of winuae i was testing, so there aren't owerwrites between the 2 versions.

in the 2 new configuration files, only the aspi setting was changed, but the 2 configuration files are much different.

i've noticed that a configuration file .backup is created only by the 1.6.1 version. anyway...

this last part is prolly not relevant, but i will attach these configs for completition, attached in the file "configuration saves.rar".

-----------------------------------------------------------------------------------


lastly, i attach the logs of 1.6.0 loading the same config (aspi set to SPTI) in one of the tests that had the loading of the WB halted and the stopped at a CLI.

-----------------------------------------------------------------------------------


now i'm very confused and i truly am sorry if this explication is complicated to follow; i wait for pointers to what try next, because to continue in this very post would become to messy.

[Marcuz]

i've thought to add the logs of the 1.6.1 version crashing (quitting by itself with no dump) when running the same config. as above with the parameters -log and -logflush

[Toni Wilen]

Originally Posted by marco pedrana

i've thought to add the logs of the 1.6.1 version crashing (quitting by itself with no dump) when running the same config. as above with the parameters -log and -logflush

Can you narrow down the configuration that causes the crash? (Load your crashing configuration, starts disabling options until it stops crashing, like starting with JIT and Z3 fast)

[Marcuz]

i must be stupid not to have tryed a quickstart configuration before.
well, Winuae 1.6.1 stopped working at all, with every configuration, even a bare quickstart one.

then i created an empty winuae.ini file (i had deleted it as you said before)

started winuae again, it said the kickstart were not present; i linked again the directory containing them, and winuae scanned for them finding them.

after that i started a quickstart a500 mode, the window opened but it did not got to the boot, returning automatically to the gui.

after that, if i close winuae and restart it again, even the same quickstart quits winuae again, without any window opened.

therefore there must be something strange that get saved in winuae ini or registry upon closing winuae.

i attach the two ini, just created: one before and the other after closing winuae, with no other configuration savings (except in the .cache, i guess).

i attach also the logs of the first run with an empty ini, the one that gets to a window but not to the boot.

-------------------------------------------------------------------------------------

that said, i cannot narrow down the other crashing in 1.6.1 because at this point any difference in settings between a bare quickstart config and that custom one is unrelevant

-----------------------------------------------------------------------------------

summing it up for the sake of readability:

1.6.0 crashes are fixed using SPTI but not always that gets workbench fully loaded.

1.6.1 crashes always: could it be that the registry and all configuration must be flushed in order for it to work? (i would test that only if specifically needed, i'd prefer not to)

all versions, currently, possibly because of something tied to the same problem above, have the input bug, that you can't debug per se.

-----------------------------------------------------------------------------------

[Toni Wilen]

"You need to have a floppy disk (image file) in DF0: to use the system ROM replacement." = kickstart not found.

This is totally unrelated to your original problem.

[Marcuz]

but the kickstart are found, i have just scanned them and the requester said they were available! then i selected an A500 quickstart mode!

[Toni Wilen]

Originally Posted by marco pedrana

but the kickstart are found, i have just scanned them and the requester said they were available! then i selected an A500 quickstart mode!

So? Did you shutdown winuae first or just reported instantly, try to do some testing first before jumping to conlusions (note that you used ini-mode too which means something..)

I thought this was about some crashing problem..

[Marcuz]

it still is. sorry, i didn't meant to sound upstarted, i'm puzzled sincerely though
i'm not jumping at conclusions: i have tested the above many times, and attached the ini just to report that there was a difference between trying to run winuae before and after shutting it down when the kickstart roms were scanned and founded.

still Winuae quits without dump when you run even a quickstart mode with the correct rom found and even re-checked in the rom panel, and a disk inserted in df0:

it quits like reported by mcDuck in the beta thread. Simply i didn't knew before that this was a beta problem (it may still be something that regards the way winuae store the various settings, but i don't know how to help you more about that: i've even tryed disabled aspi, faster rtg etc, but a more basic config than this don't exist.

[edit] attached the registry settings

[Marcuz]

i managed to make it run at last.

the last beta requires that you manually choose the kickstart NOT by the drop down menu, but from the requester opened by the little icon next to it, in the ROM panel.

after that, the configuration works, but it needs to be saved or the next time it will not work again. this is the same with the quickstart modes too: they work only if you select the corresponding kicstart manually after choosing the quickstart mode.

moreover the aspi problem, the random not loading of the Workbench, is still there, like in 1.6.0