lowlevel PCI-coding / Amithlon

[Ratte]

At the moment i am working on a open-pci 68k gfx driver.
Its still working in a "framebuffer"-mode as long as i am trying to support all kind of amiga-pci-systems.
openpci is great for this kind of drivers, but some very lowlevel operations during hw-init must be separated for different pci-systems.
So it seems to be impossible to read the pci-rom trough powerpci/openpci on Amithlon.
I have to code the bars directly like pci-specs describe it.

But here is the problem, it will work for ONE time, after a reset the system hangs if i try to read the pci-rom again.
This problem seems to be old ... amithlon-open:
http://tech.groups.yahoo.com/group/amithlon/message/13190

Is there an existing workaround or a bugfix?
Or some documented "softreset" code for pci-slots?

An other solution could be a resetproof resident-structure with a copy of the gfx-card.rom generated during the first amithlon-coldstart.
But I like to read the real rom before i start playing with resident-structures.

Thanx in advance.

[Photon]

I moved the thread to NextGen, hope you don't mind. Just to make sure: this is to enable the Linux 68k emulator to get access to any PCI slots in the PC?

[Ratte]

thanx 4 support
[ Show youtube player ]

[amigoun]

Amazing!

[fishyfish]

Damn, that's freaking awesome
Im still a big amithlon fan/user, so Im very interested in this.
Just curious though, and I dont want to be negative towards your work, but is there much likelyhood of those few functions (writepixelarray in particular is pretty important for me) that dont do as well as with powerfb being sped up still?
Also what cards are supported? Is it specifically the radeon9250?
Im currently using a core2duo machine for my amithlon box, so as is the case with most machines released in the last few years pci slots are limited. I have 3 and theyre all occupied (sound,nic, gfx(matrox g550 currently)).
Also does using an openpci driver remove the graphics ram limit that's normally there with amithlon?

Thanks again, and great work Im quite excited about this

[Ratte]

Originally Posted by fishyfish

Just curious though, and I dont want to be negative towards your work, but is there much likelyhood of those few functions (writepixelarray in particular is pretty important for me) that dont do as well as with powerfb being sped up still?
Also what cards are supported? Is it specifically the radeon9250?
Also does using an openpci driver remove the graphics ram limit that's normally there with amithlon?

A lot of functions are still software emulated.
Most of them are slower than powerfb, because powerfb is using x86 code for emulating and not 68k like i did.
Generally it is a framebuffer with "some" functions accelerated by hardware, some blitter and sprite functions.
Target is a full accelerated driver in the future.

RAM limit is gone, but due to a bug i have to limit the driver to 64mb, but the problem is no longer and 256mb videomem is no problem.

Currently supported are R200-RV280 chipsets.
Code is written to support a wide range from r100-r500 series in the future.
But I still have to transfer a lot of linux/bsd-code.

[amigoun]

Thanks for informing us about this great project and keep up the good work!

[XDelusion]

Very very cool, as another Amithlon fanatic, I'll be keeping a close eye on this!

[billt]

Back in the early days of the original ATI Radeon driver we had a similar/same problem. Joshua fixed it so I'm not sure exactly what he had to do, but he did find a way to tell the Radeon to allow ROM access. But I think that was Radeon specific, so we had to know that's what we were talking to and the right thing to do for this chip. Search your datasheets for your chips for what bit in what register to twiddle to open this up. I don't know if our solution survives reset or if it must be releated every possible boot. I won't have time for a few weeks, but will try to find a copy of sourcecode from back then and try to find this bit in there to report back.

[Ratte]

The reset-problem is no longer.
1. the driver is searching for a romfile on libs: picasso96/radeon.rom
if no file available
2. the driver is searching for a romtag with a romdump
if no romtag found
3. the driver is reading the rom

if it find a rom, it build a romtag (if not available)


btw.
[ Show youtube player ]
(on a4000 with latest opci-driver)

[kriz]

Very cooool !!!! Looking forward to this!!a

[Ratte]

preview available on request
ato.lha (zoned) + personal file (radeon.card) on request
supported systems:

- radeon 9200 & 9250 (& 8500 & 9100 untested) = Rx2xx chipsets

- mediator 4000 (at the moment no a1200)
- prometheus
- amithlon

- searching for grex users in germany-ostwestfalen !!!!

[johnim]

Hi Ratte nice project

will this be done for the 1200 mediator in time

cheers john

[wXR]

Wow Prometheus support! Nice job, Ratte, and thanks!

[Ratte]

Originally Posted by johnim

Hi Ratte nice project

will this be done for the 1200 mediator in time

cheers john

why not .. but first i like to fix the grex!
we are going two steps forward and one backward.

grex is a bit wirred .. rom-decoding and timings.

[wXR]

Ratte are you making source available for this?

[johnim]

Thanks for reply Ratte

keeping an eye on this

[Ratte]

Originally Posted by wXR

Ratte are you making source available for this?

No, but most parts are based on Linux & NetBSD code.

[XDelusion]

What ever became of this?

[Locutus]

Also, of its based on Linux code (i guess RadeonFB) doesnt that mean you are encumbered by GPL license and should release code to anyone who has the .card binary? ;-)