PearPC Client OS as primary OS in a pc

[nurv]

Hi

I have a new name for the project. It seams that "PearPC Standalone" is not very creative... what about "Kilt". Why? Because is "Macintosh's skirt"!

akamai: the page is a great start.

Now let us check what is coming up:

First I think that we have to put the system work under linux. We compile a smal kernel, change /etc/rc.1 to load X on start and then load up pear pc with a nice of 20 and raw disk access. This will be my first atemp. After this and if i had demonstrated that the system had run more fast then i will pass to the next level.

I will build a new kernel (Yes its correct, new kernel). The objective is to develop a way to pearpc have prime access to devices and access to PCI bus directly in a way to have access to the grafics card, and sound card !

now its what is want you to do:

guru3: can you find me in what ways 32bits PowerPC PCI bus is diferent of IA-32 PCI bus. And try to get me any books about PPC assembly and
design

akamai: can you create a CVS tree in the site a post a html page?

thanks

[Guru3]

There seem to be nore clear cut documents that I can find on this, but I think I've found a few things that either have helpful diagrams or something... Probably not what you're looking for but best I could do so far...

(I do have a number of other projects that I am working on...)

http://www.cs.arizona.edu/computer.help ... ibus1.html
http://www.quicklogic.com/images/pc603_ap.pdf
http://www.quicklogic.com/images/V292PBC_DS.pdf
http://www.codepedia.com/1/PCI+BUS
http://developers.sun.com/solaris/devel ... -ultra.pdf
http://www.litz.com.tw/pdf/PLX/PCI%209656.pdf
http://www.erik.co.uk/ans/AIX_Binary_Compatability.html
http://www.macbsd.com/openmac/refs.html

[akamai]

I'm testing some raw-disk access stuffby linking machd.img to /dev/hda4 (that's the partition with OS X HFS on it), but I run into the problem of the filesize of 516096. Why can the fsize only be a multiple of 516096... shouldn't we be able to fix this?

[color=red:2839d83a1f]@nurv: Would you please be so kind and zip the whole document tree originating from / of your current linux distro (The one for Kilt). Be sure NOT to include OS X if you have it somewhere in the document tree. If you can create this, please email it to me as an attachment. I will post it on our project site. Regarding CVS, I will try to create an SF tomorrow.[/color:2839d83a1f]

[mmebane]

[quote="nurv":9b8e4a7cb2]
2 - The best think we could do is interlink PCI bus and MacOS. Why? because if we get the grafics board to process the grafics insted processor getting important resources and maybe you could play quake in macos, if you know what ia mean... But for now is important to have the system running so we use X org.
[/quote:9b8e4a7cb2]

I don't think this will work, since cards have to have different firmware for x86 and Mac. An OpenGL "bridge" might work. Basically, you write a special OpenGL driver for OS X, which sends the commands to PearPC, which sends them to the host OS.

[akamai]

Are you sure the GPU needs different firmware? Usually the GPU commands are the same...

[Lone_Wolf]

Hello, I just wanted to let yall know that if you get a beta going, id love to throw my name in the hat for testing it for yea! I know its probably far off, but just letting yea know.

[nurv]

No we at this point don't have any thing. Maybe in two weeks maybe less. depends of my luck

tomorow maybe i had something for you all...

[mmebane]

[quote="akamai":96af6915fd]
Are you sure the GPU needs different firmware? Usually the GPU commands are the same...
[/quote:96af6915fd]

The firmware has to be written in x86 or PPC machine language. Other than that, the cards can be exactly the same.

[mmebane]

Hmm, it might actually work, after all.

[url:ea20351e93]http://developer.apple.com/technotes/tn/tn1044.html[/url:ea20351e93]

[quote:ea20351e93]
No Support of Open Firmware

The first type of Open Firmware support is that of no support. This lack of support does not require an expansion ROM at all, although an expansion ROM with no FCode is also contained in this category. However, placing an expansion ROM on a device costs money, and it makes little sense to provide an empty ROM.
Problems With This Approach

There are problems that you should consider with this type of support: 1) not being plug-and-play, 2) having an ambiguous device driver name, 3) wasting memory space, since using base registers only allow memory sizes to be multiples of powers of two, and 4) not being able to define sub-apertures. Sub-apertures are defined using the Configuration Space base registers. A typical example is a display device with a frame buffer, video controller, and RAMDAC. By defining three base registers, one for each function on the device, families can write memory differently than they do registers. This is useful for caching.
No Plug-and-Play

Without an expansion ROM, the device won't be plug and play. Nor will it be available to the user until the file system is initialized because the driver container must be placed on a hard disk and loaded from there. Note that the driver container does not necessarily have to be place on a hard disk: it could, for example, be located on a network. However, the device and driver will be matched and loaded.
Ambiguous Device Driver Name

Another issue to consider is that a distinct device "name" property cannot be provided when there is no expansion ROM. This makes unique device/driver matching ambiguous. For example, two manufacturers may supply a similar driver for a particular device, or a chip vendor may rev a PCI interface chip used on your device. Open Firmware during its probing process first looks for a name property in the Expansion ROM. It then looks for the Subsystem ID and Subsystem Vendor ID. And finally, it will choose the Device ID and Vendor ID if the name property is not defined and the Subsystem ID and Subsystem Vendor ID are zero.

Runtime drivers may fall into the no-support category but boot drivers cannot exist without an expansion ROM and therefore do not belong in this category.

The no-support category is populated mostly by applications controlling a device via a private driver. The device is not available to other applications. Since the name may not be unique, the driver should provide additional software to make sure that the device it has been matched with by the operating system is indeed its device. This could be some sort of a signature diagnostic. For instance, all drivers have a validateHardware interface that is called by the family that instantiates the driver to validate that the match is correct and the device is functional.
[/quote:ea20351e93]

So it would work, you would just have to have special drivers for the card.

[nurv]

Hi there

After a litle rest i start the project. At this point, i could sucessfuly start PearPC no a slackware linux with only the required libs and X, with out raw access. the speed increase was very small, nearly 5% or 6%. The dock's animes are still a bit "max payned"...

There for i started building Kilt.

At this point the only thing that i could do was to appear

"Welcome to kilt" when the operating system started.

maybe at the end of august i could have something.