View Full Version : input automatically swapped to Catweasel
Marcuz
02 June 2009, 20:48
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 (http://eab.abime.net/showpost.php?p=523898&postcount=288) 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
02 June 2009, 21:00
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
02 June 2009, 21:10
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
02 June 2009, 21:20
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
02 June 2009, 21:48
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
03 June 2009, 08:02
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
03 June 2009, 10:59
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. :confused
Toni Wilen
03 June 2009, 11:08
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. :confused
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
03 June 2009, 11:38
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
03 June 2009, 13:33
Ah, ok.. Perhaps there is still some problem with aspi? (your config file had aspi enabled)
Marcuz
03 June 2009, 13:49
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
03 June 2009, 23:58
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
04 June 2009, 10:48
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
04 June 2009, 15:48
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
04 June 2009, 16:27
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
04 June 2009, 16:37
"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
04 June 2009, 16:39
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
04 June 2009, 16:43
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
04 June 2009, 17:03
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
04 June 2009, 17:18
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
Toni Wilen
04 June 2009, 17:19
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:
But log is now totally different. You also said it crashes/quits. It does not quit in this situation, just goes back to GUI.
So what is it? When troubleshooting, always be very specific. "not working" -type responses only annoy and confuse everyone.
I expect basic troubleshooting steps from users, I am not going to spoon-feed anyone :)
(I hope you really have quickstart enabled, configuration won't change automatically if "start in quickstart mode"-checkbox is not checked. and it isn't checked in attached registry screenshot..)
Marcuz
04 June 2009, 17:32
i'm sorry if i was not clear Toni, but i stated in that post that the logs, and the ini were different in the (in "every" should be correct) first run of winuae AFTER the emptying of the ini file!
so: you told me to deleting the ini yesterday, which i have. when putting an empty ini today, the roms were scanned for and if you clicked run, after selecting a quickstart mode without shutting down, then winuae acted like it was using a rom replacement.
but if you shut it down and restart it, then starting a quickstart mode OR any other saved configuration simply quitted winuae, without opening the emulation window at all.
the workaround i have explained in my previous post: it is NOT the normal winuae behaviour, even if "start in quickstart mode" was not selected.
AND "start in quckstart mode" WAS and IS switched on at all times in all my previous tests, at least in the GUI, i haven't looked what's typed in the ini or logs about that, but the button is and has always been ticked on.
:)
Toni Wilen
04 June 2009, 21:23
Arghh.
1) rom scanning works just fine. (it simply can't stop working suddenly)
2) still no info except "not working". (could you even check if correct rom/path is shown in rom panel? It can't be that difficult)
3) this thread has at least 3 different problems mixed together. This is getting too confusing.
-> ignored until someone cleans up this mess and explains what exactly is going on.. (I have absolutely no idea)
Marcuz
04 June 2009, 22:58
sorry, but what kind of info would your require more?
1) yeah rom scanning works fine but it appears that the something about the code that tells winuae what rom to use may be broken, since it disregards it. possibly it is about the "start in quickstart mode". there's plenty of info above to check.
2) "not working" what can i say more than: "winuae quits when clicking the "start" button" about the rom selecting problem? there's no dump, of course, as it simply quits, and the logs and ini i have produced above.
also: since i've taken hours to test this winuae (many hours, taking in account the older beta releases) i think i can at least check basic things as paths, and yes i have in this case.
3) yes, that's true. but they have started all together since i have put the 1.6.1 in the folder, and they affect also the previous release. may that be that there is something to see in the way winuae reads/writes settings different from one version to one other, that causes all the above problems?
i'm not the only one to have the quit problem, for instance:
http://eab.abime.net/showpost.php?p=555760&postcount=25
i'm not bugging you to use a wizard rack and solve problems, i'm just telling you to read what i write, which may not be perfectly expressed in english, but it's hardly casual.
and as i said many times, if you need more info, please point me what to test.
prowler
04 June 2009, 23:04
i'm not the only one to have the quit problem, for instance:
http://eab.abime.net/showpost.php?p=555760&postcount=25
Hi Marco,
Have you tried the latest fix in the next post?
http://eab.abime.net/showpost.php?p=555896&postcount=26
Marcuz
04 June 2009, 23:11
heilà prowler,
yeah i tested it, but it was aimed at a different problem, and in fact it does not solve the ones above
prowler
04 June 2009, 23:19
heilà prowler,
yeah i tested it, but it was aimed at a different problem, and in fact it does not solve the ones above
I'm sorry to hear that, mate. You sure have some tough problems to solve here. ;)
Marcuz
02 October 2009, 17:22
hello... is there some news on the input problem?
to resume, both with the amiga joysticks plugged and unplugged, the input gets reverted to them. costantly :/
vBulletin® v3.7.0, Copyright ©2000-2013, Jelsoft Enterprises Ltd.