in the following piece of code:
/* Allocate method table for this interface */
ifb->MethodTable = (struct IFMethod *)AllocVec(mtab_size, MEMF_ANY);
/* Get correct ID for the interface
(string ID => interface ID mapping) */
if (init_mi_methodbase(interface_id, &(ifb->InterfaceID), OOPBase))
Found it? No? Too bad, you loose. Remember my words: “ULONG is BAD, IPTR is GOOD“. The init_mi_methodbase expects as a second argument a pointer to an ULONG and the ifb->InterfaceID was declared as an ULONG some days ago. It was supposed to work properly, since the ID is not a pointer in any form. Fine. The issue is, the struct IFMethod which did contained the InterfaceID ULONG field “inherits” from the Bucket used in hahstables of the oop.library. The Bucket structure expets this ID field to be an IPTR….
What a mess!
The 32-bit ULONG variable of struct IFBucket was initialized properly but the Bucket structure expected to find there a 64-bit IPTR one. Until now it was just reading some random values, name them trash. On some machines one had there zeroes instead of random values. That was the case on my machine, on qemu and on vmware. I have not seen this bug Now I have modified memory alloc functions, so that they fill allocated region with some trash, unless the MEMF_CLEAR flag was set. Thanks to this small change I was able to see what many of you saw upon trying my last aros64 iso. After some fight with oop.library (adding debug points here and there) I have solved the issue.
You may download the new AROS64 iso from here. The md5 sum of the file is: 4852e85ab83f949e9ffe0019ea039e59.
I hope you will be able to boot into Wanderer now. And remember, AROS64 in VESA mode looks simply better
EDIT: I have uploaded newer iso. Here, the kernel limits address space to the 4GB. As soon as proper MMU handling is done, I will remove this limit.