@rjd324
I'm using a fine mix of bundled cables and off-the-shelf USB and DVI cables without problem.

Only known issue for me is that the initial mouse button state some times reports buttons pressed. So sometimes my Amigas will boot into the Early Startup instead of to Workbench.
This can be remedied, though, by setting a UBoot variables for the AmigaOS bootmouse driver to ignore initial mouse button state. The only side effect of this is that you then have to move the mouse while pressing both mouse buttons if you really need to enter the Early Startup at some time.

Yeah, Merry Christmas, all!
Hope you'll have a good one!

@broadblues
Thanks! And a merry Christmas to you, and you all, too.
It's always a joy to see your Christmas greeting card unfold on screen!

@yogi32
Good to hear it was actually a 3rd party driver issue - and one which was quickly solvable.
Hadn't thought of a 3rd party driver to be part of that mix.

Regards,
Thomas

@Tuvok
I don't have an X1000 myself, only MicroA1, SAM460 and X5020, so can't comment on how CFE uses USB keyboards. Does it stall forever in CFE? What if you switch the KVM away from the Amiga and back? Or presses keys on the keyboard?

I've never upgraded the firmware of my CS1784A, so I guess mine is still running some ancient version :)

@nbache
I always uses the keyboard shortcut for switching the KVM, but that probably requires you to use the keyboard USB port for it to work.

Regards,
Thomas

@rjd324
I use an ATEN CS1784A, but I chose that primarily to get the video switching with DVI-I support so it could switch both scan-doubled classics, CyberVision64 output and NG Amigas

@tao
That would be from Trevor's presentation at Amiga40.

@daveyw
For the test of it, could you try removing the bootkeyboard.usbfd from a new test section in kicklayout and boot with that?
Note you won't have keyboard support before the OS fully boots with that kicklayout, at which time the HID driver picks up your keyboard. I imagine the problem is between bootkeyboard.usbfd driver and your USB keyboard, and this will (to some extend) test that by disabling the driver.

@AmigaSociety

Without knowing for sure it could look like some file did not get updated, or was corrupted, from the crash during install.

It seems your boot breaks when the 2nd-level bootloader is trying to enter the "Kickstart ROM" it has read in from disk. So it must be related to the modules in the kickstart folder on the boot partition, or the KickLayout file contained within.

Do you have another Amiga to attach the harddrive to? Then you could perhaps cross-reference the Kickstart folder contents with that from the Update3 archive (and also the X5000-specific drawer within it) and copy over anything missing.
And maybe update the Kicklayout file to ensure your RadeonRX.chip (i believe it is called) driver also in it at the same time.

But I believe you'll need another working AmigaOS which can access your HD to do it (or perhaps the MorphOS you still have booting - never tried it).

And, when you got it working, an idea would be to make a safety AmigaOS4 boot partition for fallback in cases like this :)

I hope you'll have a swift recovery from the problem!

Hi rheesthefox

I believe the latest public bootmouse driver has problems with high DPI mice, giving the behavior you describe with X/Y.

The booting into shell may be due to your KVM reporting bogus mouse button state. How does it work if you attach the mouse directly to the Amiga? Also, if attached to the KVM, does the boot work correctly if you're moving the mouse while booting?

What version are you using of
- bootmouse.usbfd
- bootkeyboard.usbfd
- hid.usbfd

Hi Josef

No need to do new logs for now. And good to hear you don't have flaky USB ports - they're a nuisance to have ;)

Can you send me a PM with your email address? I'd like to send you something for testing, if you're up for it. Your problem may correlate with some fixes I have queued up.

Hi Josef

Just to pick up on your logs.
Am I right in my interpreting your USB topology, where the Keyrah attaches, like this:

Rear USB
+ Port 1: Hub 1
..+ Port 1: MidiMate device
..+ Port 3: Hub 2
....+ Port 1: (in the failure log this holds the Keyrah)
....+ Port 2: Optical mouse
....+ Port 3: (in the success and detach-and-attach logs this holds the Keyrah)

And am I also right in interpreting from the logs that you're not really detaching/attaching the Keyrah but actually "Hub 2"?
Just trying to understand the scenario.

Also, from the "detach and attach" it looks like the Keyrah actually attaches correctly. But I can't see from the log that any drivers were launched on it. Could that align with what you experience?

My initial though is that Hub 2 port 1 may be faulty - but the I have not enough data to back that up. Is it consistent that it will fail in port 1 and work in port 3?
Just trying to rule out causes to simplify what I have to evaluate :)

Hi Flynn

To try and figure out what goes wrong (I don't have a Keyrah in any version myself) I have a coupe of questions/requests for you:

1) What are the version numbers of your USB modules (version full <modulename>)?
- usbsys.device
- usbresource.library
- ehci.usbhcd
- ohci.usbhcd
- hub.usbfd
- bootmouse.usbfd
- bootkeyboard.usbfd
- hid.usbfd
- usbhidgate.library

2) Please enable all USB logging on your system for testing:
setenv usb/system/LOGINFO 1
setenv usb/system/LOGWARNINGS 1
setenv usb/system/LOGERRORS 1
setenv usb/system/LOG_ATTACHMENT 1
setenv usb/system/LOG_HCDCALLS 1
Then open USB prefs and press the "Use" button. That will get the USB stack to reload its settings from ENV:

3) With logging enabled as mentioned in point 2, please record the following for a successful attachment of the Keyrah:
- T:usb.log
- output of command "usbinfo tree" (if you have it - your USB stack may be of a release which has it in the SDK and not the user install)

4) Record info as in pont 3, only for the case of a failing attachment of the Keyrah

----

If possible, please reset the OS before each test to get a clean state to test from.

So, collect this info
- USB module versions
- T:usb.log (and perhaps usbinfo) for successful attach
- T:usb.log (and perhaps usbinfo) for failed attach
in an archive and pass it on to me.

This will give me a good bunch of information to try and wrap my head around what might be going wrong.
I'm not sure if this is the right place for such large text content, so perhaps PM me a download link via wetransfer.com or similar, or ask here and I can give you my email address in PM.

Yes, happy birthday to the Amiga!
Many a good time has been had - wishing for many a good time ahead.

May she live long and prosper

@SteffJay
On that HDD you boot from with the weird mouse behavior, do you have
- "USBCtrl START" in your S:startup-sequence
- A hid.usbfd file in DEVS:usb/fd
- A hid.fdclass file in DEVS:USB/fdclasses

Otherwise you're running with a simplistic USB mouse driver using what is known as the boot-protocol (a simplistic data interface) for communicating with the USB mouse.
The HID driver (which is disk-based and triggered when the USB stack gets fully booted with "USBCtrl START" if it is available on disk) is much more sophisticated.

If your mouse does not play nice with the boot-protocol and the HID driver is not running you might see something like what you have with mouse not operating as expected.

Just a thought - might not be the culprit at all, though :)

Thanks for another roundup! I always look forward to your recap of the month

@TheMagicSN

Thanks, I'll give it a shot.
I'm kind of out of spare time for the next month, so I probably won't get to it for some time. I'd hoped I could get Warcraft2 up and running as a last thing before maxing out, but now I can look forward to it for when things get back to normal :)

With regards to *nix handling of '.' I don't believe I've setup anything myself, but I do have the AmigaOS4 SDK installed. Don't know if that has something tweaked to make build tools work.

@TheMagicSN

Ah, yeah, then it makes sense with the CD content path requester. I just don't have a CD with the Batlle.NET-client-installed version.

Anywho ... nope, I only got to that point with the error prompt when I used the path of the installed content copied over in the CD path requester.

Unfortunately I don't have any old DOS version CD. I might be able to dig out an old MacOS version CD if I dig long enough in my storage room, but I guess that won't cut it either. I played it a bit back in the day via ShapeShifter :)

Are the files from the install processed in any way, or would a directory/file layout list allow me to manually copy files where they should go, and then ignore the installer altogether?

@TheMagicSN

Just bought both your Amiga version and the Battle.NET Edition of WarcraftII and tried to do the install. But, alas, I can't seem to get it to work.
The installer simply bombs out with the message:

Quote:

"Programs:Games/Warcraft2" is my chosen install location. And if I check there is a "wc2.data" drawer in there.

It also spooks me a bit that the installer asks for the path of the CD before telling me to first do all the MpqMaster magic in Windows and then select where I've copied the extracted output.
There is not CD content since the Battle.NET version is an online installer run by the Battle.NET client on Windows.
My workaround has been to copy the entire Windows installed-game folder over and use that as CD content, although it seems a bit much to have basically copied the game over twice as both MPQ content and installed content.

Any good advice on how to continue?
It is, btw. on an X5000/20.

@MigthyMax
Yup, that I am.

Yeah, its a use case I've not had in mind with the fdclass files, so there's no such feature currently.
I definitely should add that as an alternative to the VENDOR and PRODUCT properties so a list of vendor/product pairs can be specified. I am, however, currently out of spare time until end of June, so unfortunately I can't jump in with a quick fix right now.