Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  1. Bump. Any ideas? come on I know you have them.
  2. OS X for SSE (qemu)

    PS: OMG I just spent forever trying to go through QEMU's source and it is a HUGE mess. What kind of project doesn't document its operation? Nevermind. I'm going to skip the kqemu part for now and focus on making slax leaner or replacing it all together.
  3. OS X for SSE (qemu)

    Sorry I got tied up with work today so I didn't get far on the qemu iso image I'm going to look at your slax image real soon but my experience with those images have been they have a lot of bloat for running a specific application need. In other words they try to do everything in as little amount of space as possible when what we need is to do just 1 thing in a little amount of space and do it well.
  4. OS X for SSE (qemu)

    I would load it via the initrd process. That is easy because I have already done all this before minus the QEMU part for some embedded devices I have worked on in the past. I can even refold the initrd into the kernel and thus it be 1 file but that might be overkill. PS I belive we can overide SSE2 instructions in KQEMU, I'm looking into it right now since KQEMU recently became open sourced.
  5. OS X for SSE (qemu)

    No I have not, I must have missed it. Can you point me to it? I'm going to try to look for it by myself but if you can save me the time that would be great. If you were refferring to these instructions I have something better that won't take me too long to do. From Drag's post: 1. Download SLAX Kill Bill Edition from : http://www.slax.org/download.php 2. Burn ISO to cd using burning software such as "Nero" or "Disk utility" 3. Boot SSE computer using the SLAX CD. 4. At boot screen enter "slax copy2ram" or "slax toram" AND "flux" (for fluxbox desktop) 5. This will take several minutes. 6. After it has copied to RAM and has loaded the GUI, open up an xterm window. 7. Make sure you have a harddrive you can wipe in your pc. 8. You need to format that harddrive as ext2, so if you are ready to wipe it use the command - "mke2fs /dev/sda" 9. Input "Y" and press enter. 10. Then in xterm use these commands : "mkdir /mnt/harddrive" AND "mount -t ext2 /dev/sda /mnt/harddrive" 11. After it has finished creating the partition, connect to a pc on the network via Konqueror (you can open it from the flux menu) e.g (\\computername\). 12. Copy your tiger-x86-flat.img to /mnt/harddrive from konqueror. (open 2 windows) 13. Once that has finished, it will probably take 15 minutes or longer, go to your xterm window and use "qemu -hda /mnt/harddrive/tiger-x86-flat.img -m 480 -no-kqemu -boot c" and use "platform=X86PC "Graphics Mode"="800x600x16" -v" as usual. 14. Help me get this working with an accelerator. ---End here--- What I was planning on was a 2.6.18 kernel booting, going into busybox's init process where hwdetect was ran and the appropriate modules were loaded, then a quick check for the proper video driver 1 of 3 choices: 1. Nvidia with HW OpenGL 2. ATI with HW OpenGL 3. VESA with SW OpenGL (Mesa) load the kqemu module set /dev/kqemu to 0777 launch X then directly into QEMU fullscreen and if its an nvidia or ati video card you should have some level of acceleration as qemu will use kqemu and opengl via sdl. What do you think.
  6. OS X for SSE (qemu)

    I simply don't have the time to hack the XNU kernel otherwise I would. That being said I would enjoy the benefits of having the qemu route for my own personal fun.
  7. OS X for SSE (qemu)

    Putting SSE2 emulation into the XNU kernel I believe is going to be hard if you are using QEMU as the source. The reason is: 1. The QEMU source is a bit hard to follow, sorry to the author but I looked at it more then once and have gotten lost in it. 2. The QEMU emulation is going to be geared towards the QEMU CPU Emulator and not to the XNU kernel's APIs. That being said if anyone is going to do this then I recommend: 1. Get the source for the current SSE3 emulation 2. Use the Intel Ref Docs and do a clean room implimentation of the SSE2 instruction set 3. .... 4. Profit! LOL But seriously I will take a crack at the qemu thin linux distro method sometime tomorrow, I can use one of my smaller custom linux distros as a starting point. The only question I have is that if anyone has a qemu image of osx86 running in it so I don't have to recreate one. All my macs are real macs and I would love to have this CD available to me to use on x86 hardware. The one HUGE advantage to using a virtualization layer is that it doesn't matter what video card, what sound card or what network card you have they will all show up as the same brand, model and version to the mac osx.
  8. Cocoa Tutorial

    For various reasons I have to ask the next question how can you make a cocoa application WITHOUT the interface builder? That is sort of cheating since you need to include the nib in some form. I want to know how to make a real window and widgets using ObjC or C without using a GUI to construct it. Any advice?
  9. Commercially I am working on an OSX Terminal Server just like the Windows Terminal Services but allows multiple users to have different desktops hosted on the 1 mac server. This is cool because the clients could be dumb terminals or even windows clients, (mac clients are also supported). Open Source wise I am thinking about working on a method introduced by the guys at this thread: http://forum.insanelymac.com/index.php?showtopic=38763 And if they don't want to do that then to make a bootable dvd that boots a very small linux kernel then a qemu system to boot osx86 in it. Like a LiveDVD but where the hardware is abstracted from the OS while not sacrificing more then 10% of the speed if it were to run natively. This would make it very portable and able to run on platforms that would others be unable to run osx86.
  10. OS X for SSE (qemu)

    Ok, I guess I need to step in now, just kidding. I know most of you have probably done a lot of homework but a few things: 1. Straight QEMU PPC emulation doesn't run OSX PPC. 2. Straight QEMU x86 emulation is slightly faster then BOCHS (which is by far a better x86 emulator) 3. Straight QEMU x86 running OSX x86 vs PearPC running OSX PPC will probably lose to the PearPC since emulating a G3 (PPC's target platform though some G4 is implimented) is a lot easier then emulating the x86 extremely bad evolution 4. QVM86 is buggy and is not maintained anymore. KQEMU is mostly closed source and has many licensing issues. 5. Using a hypervisor method is out of the question since that requires VTX or AMDV which are both way past SSE in the evolutionary chain Ok that said. If you are going to use QEMU with KQEMU which is way faster the PearPC then are you going to use the SDL interface or a X widget interface? If you are going to use X then is 3d acceleration an issue? If not then kdrive anyone? If SDL vesafb anyone? Boot process once kernel loads should be 5-10 seconds depending on the IDE bus scan of the platform's IDE driver. The funny thing is that all drivers should be made as modules and then wrapped into a cpiogz file that is then embedded into the kernel so that the entire boot process is 1 file. The init process could be busybox.... actually it should be busybox with a few shell scripts. Autodetection could be done by knoppix hwdetect tool which is gpled and already ported over to so many version of linux. I don't see why this couldn't be done under 20-30mb of ram and storage, bearing that the whole OS is in ram. You could even shave off 10MB if you dropped GLIBC in favor of uclibc. So where do you guys want me to post the rough draft of the howto? BTW we need to answer a few questions 1st since I don't want to write a howto that takes many if directions like if you want uclibc do this, if you want to use X over SDL do this, etc. Also what about wifi nics? A few things to ponder. Also will the project leads PM so I can clearify that I'm not making an ASS out of myself by doing something you guys don't want or aren't looking for.
  11. So I read this link http://www.osnews.com/story.php?news_id=10366 but I'm failing to adapted it to the x86 version of OSX. What my problem is that I know a group of APIs that I will probably want to interface with but those APIs are not documented. So I was looking at 1 of 2 solutions. 1 decompile, disassemble, and/or disect the libraries in question or 2 do the same to a group of applications that use those APIs. What would you guys suggest? Any advice?