Jump to content

blex0r

Members
  • Content count

    49
  • Joined

  • Last visited

About blex0r

  • Rank
    InsanelyMac Protégé

Profile Information

  • Location
    Candy Cane Mountain
  1. You don't need SSE3 anymore for getting some visual stuff to run (currently the same stuff that runs with SSE3 CPUs). Follow this link http://osx86.classicbeta.com/forum/viewtopic.php?t=100 for further information. Regards, blex0r
  2. Post edited due to implied violation of the DMCA. Posting that in anyway implies a violation of the DCMA will not be permitted in this forum. See Forum Rules for more information.
  3. Thread edited due to implied violation of the DMCA. Posting that in anyway implies a violation of the DCMA will not be permitted in this forum. See Forum Rules for more information. Hi, I'm running WindowServer, WaitingForLoginWindow and so on with my non-sse3 Northwood CPU under VMware. Here is a screenshot: <Image Unavaliable> I have patched CoreGraphics so it's using FISTP (SSE2) instead of FISTTP (SSE3). Those instructions are not actually equivalent but it seems to be working. I think this can help people with non SSE3 enabled CPUs to work on the stuff. Regards, blex0r
  4. All of the OS X era.
  5. Rosetta Kernel uses TCPA

    It doesn't. And about universal binaries, they're nothing but archives containing two or more versions of a binary for various architectures. You can even extract those binaries from the universal one (see man ditto). That can be useful for disassembling those binaries with tools that don't support universal binaries but are able to disassemble Mach-O files for both ppc and x86 like IDA. Regards, blex0r
  6. Rosetta Kernel uses TCPA

    ATSServer is a lightweight part of the OS X GUI and although it's run emulated I don't think it to be compromising the performance at all. Remember that it has been reported that some programs like Firefox run faster emulated on the Developer Kits than native on a Powermac G5 (I'm talking about the ppc version of Firefox, not about the universal binary that came out later). It should not have any impact in the development as applications are not aware of ATSServer being run emulated or native. We're not talking about the entire GUI but the Type Server. WindowServer is native, Quartz is native, key GUI apps like loginwindow or the Finder are native. ATSServer is the only component of the GUI that we have found being not native. They aren't likely to need nothing more than clicking a checkbox in Xcode to generate an ATSServer universal binary. They're talking about much larger and complicated apps being ported to x86 by changing no more than 20 or 30 lines of code. I don't think porting ATSServer to be a problem at all. ATSServer is not a library but a daemon. Processes communicate with it via IPC mechanisms. Rosetta emulated processes shouldn't have problems to communicate with native ones at all. It is not. There's an open source project called SoftPear that aims to create a ppc to x86 recompiler and a compatibility layer between OS X/ppc and Linux, FreeBSD and Darwin x86, in a similar way to wine's. However it's still in its very early stages of development and it can't run many more ppc executables than gzip, ls... I don't think it to be capable of running ATSServer and doing it well enough. I couldn't even compile it in Darwin/x86. Regards, blex0r
  7. Rosetta Kernel uses TCPA

    The mach kernel in the Developer Kits automatically launches Rosetta when trying to run PPC-only binaries instead of showing that "Can't execute binary file" error message. The latest open source versions of Darwin (8.1, 8.2) don't have such a functionality, it seems like you can still launch Rosetta manually (./oah750 binaryfile) but we can't be sure about that as Rosetta isn't currently running because of the TPM issue. Yes, it is. An essential service for running the GUI like ATSServer is not ported to the x86 architecture, so it runs emulated by Rosetta in the Developer Kits. No Rosetta, no text rendering, no GUI. At the moment, it is. Perhaps Apple will port ATSServer in the future, but we can't currently run the GUI without Rosetta. I don't know, i haven't found more binaries asking for the TPM, only oah750d, but maybe there are or there will be more ones. Another thing that seems related to the TPM chip is that a lot of binaries are signed in some way probably during the installation procedure as they don't match the checksums in the bom files and they're different between kits. And the different bytes between two copies of the same signed binary from different kits are the same in each case for every signed file, so if the signature corresponding to a devkit is 0xAABBCC, it will be the same for every signed file in that devkit. We're trying to identify a pattern in the signature's location as it is not at the same offset in every files. It seems to be found in the LINKEDIT section (only Mach-O executables and libraries are signed). Regards, blex0r
  8. That pointer-without-bg situation is the best we can get without a SSE3-enabled cpu. There's no way to bypass it apart from emulating SSE3 at kernel level or recompiling those binaries whose source code we don't have. We could patch that particular line but there are going to be a lot of SSE3 instructions all across the code as OS X86 has been compiled with the SSE3 flag enabled. And about your quote, perhaps in the final version of OS X for Intel processors SSE3 won't be mandatory, but the only Intel Mac currently available supports SSE3 and it's a beta version so they don't actually need to support non-SSE3 cpus as they don't have any. When they will do, the only thing they need to do is recompiling with the SSE3 flag turned off. Regards, blex0r
  9. This could be a good approach: Just in case you're thinking on upgrading your machine
  10. The good news is that it seems like a VESA compliant graphics card should be enough for running the GUI, although i don't know how fast could it be.
  11. You can guess it by issuing sysctl hw.optional.sse3 at Darwin's command line. You can also use cpu-z on Windows or just cat /proc/cpuinfo in Linux. However, I'm pretty sure your CPU doesn't support SSE3 at all as only Prescott and above do. That includes Prescott P4s, Pentium D, Celeron D. Venice Athlon64's also support SSE3 although they lack HyperThreading, but that doesn't seem to matter. Regards, blex0r
  12. ---Edit NO LONGER TRUE SSE2 CAN BOOT GUI ------sportman Bad news for most of us: we'll need a SSE3 powered CPU to start the GUI. I arrived at this conclusion after disassembling the code being executed when I get those Illegal instruction messages when trying to run graphical stuff like WindowServer -daemon, open and so on. The instruction being executed when the exception happens is fisttpll, a PNI (Prescott New Instructions) one. Then, no blue background for us at the moment. Latest versions of Bochs emulate SSE3 but it's just too slow and regardless it doesn't even boot the Darwin CD, so it can't help us at this point. We could take code from it to emulate SSE3 in some way at kernel level, but that could take weeks... or months. By the way, having a DVD image wouldn't change anything, so probably you don't actually need it nor the missing files at the moment if you don't have a SSE3 CPU. Regards, blex0r PS: If you're getting the blue bg with a non-sse3 computer please tell us. Try running WindowServer -debug.
  13. Supported Virtual Machine

    The bad thing is that you can't just unplug a PCI device from the host and plug it to the VM as you can do with USB devices, so you still can't make networking work under VMware, the pcnet is the only network card you can show to guest systems.
  14. errors!

    Have you restored the original Darwin extensions after overwritting them with the ones from the mactelbase ?
  15. Supported Virtual Machine

    VMware is supposed to be a lot faster than PearPC.
×