@imagodespira

Nice!! Looking forward to buying and trying in a couple of weeks when I have some spare time again.

@Georg/@kas1e

Yup, that is also my take away from doing DMA in the USB drivers.
You must align your DMA buffers to MMU cache line size. If input buffers are not aligned you need to bounce-buffer it (at least partially).

And also, yes, do not access memory setup for DMA. It *will* get you into trouble. Setting up for DMA flushes/invalidates CPU caches, and if you access the memory afterwards from the CPU you undo that preparation, leading to the DMA either using values you didn't expect (the values you expect are in the CPU cache still), or read back data you didn't expect (you're reading data from the CPU cache, not what DMA placed into the memory).

@328gts
Impressive - well done!

@Tuvok
Are you referring to being dumped in an AmigaDOS shell?
If you're using a KVM switch it may be the KVM switch reporting false initial state of mouse buttons. That may lead AmigaOS to think you're holding down mouse buttons to either enter Early Startup or "Boot Without Startup-Sequence". I have that on my ATEN KVM sometimes.
The bootmouse driver has a bios environment variable, "use_mouse_btn_check" you can set to "0" or "no" to disable initial reading of mouse buttons to avoid this specific problem.

@afxgroup
Btw. regarding "the Sirion stack's tendency to report the same physical device multiple times at different USB addresses" you mention: Please tell me more.
I've never myself experienced anything like this, but if there's some underlying bug there which needs to be fixed in Sirion I'm all ears :)

@afxgroup
Nice!

@328gts

This is on my Sam460ex.
The X5000 is mainly used for USB testing and things requiring Warp3D Nova.

@328gts

81324 for now. Not a top scoring, but joining in the fun none the less :)
This game is really addictive

@328gts
This X5000 (and SAM460ex) user is spending his remaining spare time doign softare development (and sneak peeking at the players, wondering when he will get his act together and join in the gaming again

@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.