| [Files] New Amithlon 1.29 update available | ANN.lu |
| Posted on 11-Mar-2004 20:42 GMT by top (Edited on 2004-03-12 18:05:13 GMT by Christophe Decanini) | 73 comments
View flat
View list |
the New update for Amithlon to run AmigaOS3.9 under PC hardware via Linux Drivers :
° Amithlon Kernel compatible Linux PCI drivers : PC network chipsets, PC sound chipsets
° Added new version of the XCat Utility (Thanks to Bernd Meyer)
° FIX: Somehow the name of the installed amithlon1_com.device was wrong!
Available for download in Aminet
link file:
Amithlon 1.29 update
Author: geit@gmx.de (Guido Mersmann)
Author: amithlon@amithlon.net (Bernd Meyer)
and
Author: support@vmc.de (Harald Frank, VMC)
Author: bvernoux@wanadoo.fr (Benjamin Vernoux, Titan)
|
|
| List of all comments to this article |
| New Amithlon 1.29 update available : Comment 67 of 73 | ANN.lu |
| Posted by Crumb // AAT on 15-Mar-2004 08:54 GMT | In reply to Comment 52 (Bernie Meyer):
"On the Amiga, anyone and everyone hits all sorts of hardware directly. In particular, screen data gets written by applications directly into gfx card memory. Which means that simply using memory in reverse order would result in the display being turned 180 degrees...."
Thank you for your explanation, is really interesting. I don't know if you have read my comment in Amiga.org (I can't access Amiga.org now, it's explained more or less in detail in the AROS forum) about using memory in reverse order, I was refering to split the memory in two parts, one part would be for 68k programs (with reverse memory) and the other for x86. The screen would be created in the x86 area, so we shouldn't have the display rotated :-)
This is more or less the method I thought for AROS:
We split memory in two parts, we detect if a program wants to access the memory part of the 68k or the x86 side using the MMU. The 68k memory chunks will have reversed their addresses.
"Also, while doing so avoids the need for byte swaps, it makes it necessary to do some maths on the addresses before using them --- which was faster on a 386 (no bswap instruction), but actually takes more time on modern processors.
To avoid that, you'd have to use inverted logic all the way through, which is just too twisted to seriously consider..."
Well, using the MMU and the method I have described you may have a little-endian OS and you wouldn't need to do byte swaps with native programs. The emulated ones may run more or less fast than byte swapping, but you wouldn't have to change much the design of AROS, the native programs would continue running and it would be a portable approach (AROS PPC would know also use two memory parts, one for 68k and the other for the ppc but it wouldn't need to reverse the addresses) |
|
| List of all comments to this article (continued) |
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|
