My only experiences with Amithlon are on native hardware. My current Amithlon box is a core2duo@3.86ghz+1gig ram, so I know it will work on multi core cpus at least. Oviously only one core is in use, but depending on the cpu the one active core could inherit all available l2/l3 caches, which is something at least :)

Each to thier own and whatnot, but unless there's drivers available for emulated hardware (and the emulated hardware accurate enough for the drivers of said hardware to work well(Ive had probs with gfx drivers in particular with things like dosboxand bochs running Windows)) then Im not sure I see an advantage in amithlon vs. some form of UAE. The overheads in a VM (even using VT or equivalent), plus the overheads using vesa adds make it a cumbersome option(correct me if Im wrong please someone, but does this hurt DMA? Ive used amithlon on many systems over the years and the few times I had to fall back to vesa it always seemed to hurt performance beyond just gfx).

I say this as a big fan and longtime user of amithlon (and current user), so its not just me suggesting my preference.

All comes down to what you want to do I guess, despite the potentially more cumbersome nature of using amithlon in a VM vs UAE they are somewhat different in the way the work under the hood. All of which Im sure you know, but maybe you could rethink your approach if the current one isnt working?


edit: sorry, I missed the note about uae in your 1st post :)

Last edited by fishy_fis on 25-Aug-2011 at 04:56 PM.

@Belxjander

Quote:

so I don't know why everyone else has any kind of memory limitation issue

The problem is that one of the first things the Amithlon kernel does is to reprogram all the PCI devices, shifting them downwards in the address space by 2GB[1]. Depending on the motherboard, BIOS, and installed components, *some* address space in the 1-2GB range will be taken up; It might be right at 1GB, or it might only start at 1.5GB, or 1.2, or anywhere else. And while PCI mappings tend to actually have priority over RAM on the physical, hardware side, *linux* gets unhappy when some area it considers to be RAM suddenly fails to return the values written to it....

So yes, give the kernel parameter a shot. May be worth it :)


[1]: That's because they are usually in the 3GB-4GB range. Amithlon's memory handling is very Amiga-like, in that the MMU is essentially transparent, and thus physical and logical addresses are identical. But because Amithlon *is* running as an x86 linux task, and x86 linux reserves the top GB of address space for the kernel, it is not possible to map PCI devices in the 3-4GB range with a 1:1 mapping. But I could manage to make the 1-2GB range available, so shifting the PCI devices there solves the problem.

Last edited by umisef on 26-Aug-2011 at 03:29 AM.