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.

@tekmage

A class 0x00/0x00 device has its class type specified at an Interface level. So you should probably also include the Interfaces listed under the device in the output where you took the device information from.

@BSzili

What if you allocate a page sized (or is that cache line sized?) block in front and after the memory region (and alligned to its natural boundary) when you allocate it, and then use IMMU->SetMemoryAttrs() to make them MEMATTRF_READ_ONLY?

Haven't tried myself, though.

@AmigaSociety
The requirement for use in the Early Startup is that the keyboard in question supports the boot keyboard protocol. Maybe some gamer keyboards do not support that? But I don't know, just taking a wild guess.

At any rate this is too early in the boot sequence for usbctrl to have any say in it.

-- double post --

@mbrantley
Good to hear you got it solved.

Getting a bit technical here, the reason you keyboard (and mouse) started acting up is that usbctrl is required to tell the USB stack that the OS is booted far enough for file system access, UI etc. to be available.
So when usbctrl does not run the USB stack stays "pre-booted" and only uses drivers already in memory as kickstart modules, and it won't read any environment variables holding configurations - only what may be set in UBoot variables.

@mbrantley

Yes, it's the version of usbsys.device reflecting the USB stack version, as Niels mentions. The usbctrl version must match this -
at least in earlier versions of the command.

Give me a PM if you fail to find the right version. I have many older versions still in storage :)

@328gts
I'm playing this on my trusty SAM460ex with 2GB ram and, if I remember correctly, a Radeon HD6450.

3380 points for my first entry - wuhu!

For me the most used programs boils down to this (leaving out all the underlying OS components :):

Workbench
AmiDock
Shell
CodeBench
gcc
DirOpus 5
AmiPDF
AutoDockViewer

So currently mostly development use.
...with the odd gaming session now and again where Mace Tower Defense makes continuous comebacks and where Gorky 17 and Tower57 are on my to-pickup again list :)

Always a joy to read your roundups - thanks!

@sailor
I don't they are free of license-lock - it's just that the rights for these reimplementations are now with AmigaKit.
So same-same from an outsider perspective, except for the version numbering mixups and name clashes :)

@broadblues
Thanks for the X-mas card!
Merry X-mas to you and all the rest in here

@m3x

The TFPT firmware downgrade worked a charm with serial cable from PC as stdin and stdout in UBoot.
Thanks for the tip!

And with the older firmware back in my SAM460ex my USB keyboards are working again in UBoot .
So it seems I have to stay on the old firmware for now. But good thing is I didn't really need it. I mostly wanted to keep up-to-date and support the maintenance work.
So next update, perhaps

At any rate, thanks for keeping the ball rolling!

@m3x
Awesome, thanks!
I'll try this out as soon as I have some spare hours for setting it up!

@NinjaCyborg
Are you on one of the newer "grey background" versions?
I came from one of the old "black background" versions which worked fine for me.