Open ATI Specifications For R100-200

[stan]

Power management and TV-out

I didn't think so but will add it to the list of things to check after we get 6xx 3d going.

Great, thanks a lot! I got my info from Wikipedia :-)

The derivative Mobility Radeon 9000 ... had advanced power-saving technologies incorporated.

Also, the TV-out functionality, having been partially reverse engineered by the GATOS team, is not very reliable probably due to some incorrect guesses on their part when it comes to registers. It would be great to have TV-out fully documented as well, which would instantly make Radeons of all generations the top pick for MythTV/LinuxMCE/ELISA/Freevo home theater builders. Specifically, being stuck at a low resolution of 800x600 is a bummer and is really noticeable on medium-sized to large TVs.

[bridgman]

>>Specifically, being stuck at a low resolution of 800x600 is a bummer and is really noticeable on medium-sized to large TVs.

I see this topic (desire for higher resolution on tv-out) come up from time to time and I still don't fully understand it. The TV standards are either 525 line or 625 line with a very low colour subcarrier frequency (3.58-ish MHz, or ~200 cycles per active scanline), so the composite video standard (NTSC or PAL, don't think we do SECAM) is going to block any attempt to get a high resolution image out to the TV.

S-video splits the subcarrier out so you can have higher resolution in the luminance (which helps with monochrome text I guess) but that's about as far as it goes AFAIK... or are you talking about component video and HD timings ?

[agd5f]

The signal sent to the TV is fixed based on standard (PAL, NTSC, etc.), however the input image can be down-scaled to the resolution of the tv signal by the tv encoder on older radeons and the scaler on avivo chips. Teh TV always gets a standard NTSC or PAL signal. The problem isn't so much the register documentation (most if not all is available in the register headers in the radeon driver), but the proper algorithm for calculating the pixel and tv plls and the frame timings. It wouldn't be too hard to create a hardcoded table of values, but no one has take the initiative to do so.

[stan]

TV-out

Bridgman, agd5f: thanks a lot for the explanation. I was indeed referring to S-Video TV-out, but I wasn't aware that NTSC and PAL aren't capable of displaying resolutions higher than 800x600.

The problem isn't so much the register documentation (most if not all is available in the register headers in the radeon driver), but the proper algorithm for calculating the pixel and tv plls and the frame timings. It wouldn't be too hard to create a hardcoded table of values, but no one has take the initiative to do so.

Perhaps it would be possible to lift the table (filter_table[] ?) from i830_tv.c in the xf86-video-intel driver. I notice they support input resolutions up to 1920x1080:

input_res_table[] = 
{
        {"640x480", 640, 480},
        {"800x600", 800, 600},
        {"1024x768", 1024, 768},
        {"1280x1024", 1280, 1024},
        {"848x480", 848, 480},
        {"1280x720", 1280, 720},
        {"1920x1080", 1920, 1080},
}

[bridgman]

Part of what makes the whole TV world hard to understand is that there is no fixed H resolution, just a fixed V resolution and some bandwidth and rate-of-colour-change H limits which *practically* limit you to 640x480 or 800x600.

You can display at an insanely high resolution as long as you scale down to -- you guessed it -- something like 640x480 or 800x600 before feeding into the NTSC/PAL encoder. Displaying at a higher resolution is sorta useful because you have more freedom in *where* you place the information on the screen, but you still can't display any more information than you could at the lower resolution.

Back in the days when TV was a common output for PCs there were people spending their lives working on clever ways to pack a bit more text information into a standard TV signal, typically with a combination of anti-aliasing and clever colour choices, but these days I think all those people have 1080P HDMI displays and are just sitting back and wallowing in the resolution

[b15hop]

R100 cards must be rare these days?

[Arch4Ever]

What lacks here is not specifications but people to work on that code. I am pretty sure we already know most of the things even for hyper-z on r100/r200.

That being the case... Is there anyone willing to work on this for money? I know quite a few people who would donate more than you would think to be able to play Urban Terror on a ~1GHz laptop.

[trev_vb]

R100 cards must be rare these days?

Rare? That's true, to a point...
However, there are SOME of us who are forced by circumstances beyond our control to cast our minds back to such prehistoric times (and MORE).

Here's a specific example of a (self imposed) sideline project of mine.
The systems in question are some of the earliest ever PCs that had a PCI slot (although the currently installed 'custom' cards are all ISA there's two available PCI slots!)
They are running a modified version of Concurrent DOS and the application in question is a PURE textual application (NO graphics involved at all!).
The _normal_ setup of these systems has two attached monitors - One being a hercules type MDA and the other being a VGA. (I repeat that BOTH of them are in 'text' mode).
The VGA is an IGD on the motherboard and the MDA is a separate ISA card.
The problem I have is that functional Hercules MDA monitors have become harder to find here than the Higgs Boson at LHC / CERN!!!
(And I am getting rather tired of replacing LOPTs on them!)
You can't _easily_ hook up a current LCD monitor to an MDA card (18kHz VSYNC is nowhere NEAR fast enough on most current LCDs although I guess it COULD be possible to 'butcher' an LCD TV as the sync frequencies are ALMOST in the ballpark)

After some serious 'head scratching', I remembered that VGA cards could run in 'monochrome emulation mode'.
The problem though is that co-existence of effectively TWO VGA cards, one running in MDA-text mode (BIOS mode 0x07) and the other running in VGA-text mode (BIOS mode 0x03) doesn't work right either!
The PCI setup in the system BIOS tends to only allow ONE of the two PCI cards to initialise and 'claim' the necessary video RAM (A000:0000 thru BFFF:FFFF), VGA BIOS (C000:0000 thru C000:FFFF) and the corresponding pertinent I/O space.
Interestingly enough, I can make it work perfectly using an ISA VGA card (with the BIOS ROM removed so that the system BIOS would not 'see' it was there), but I think I found the LAST ISA VGA card in existence!!!

Soooo, I am still kind of stuck for all the other machines of this group.
I then remembered the good old Radeon 7000 series. Some of them came out with TWO VGA outputs (others had a DVI + VGA + Composite).
I already know that the R100 includes TWO CRTCs along with two of most everything else...
What I am wondering is whether it will be feasible to drive BOTH monitors from a single (dual head) card.
The 'primary' head would be running in MDA emulation (BIOS mode 0x07 - Video RAM at B000:0000) and would have the control of the BIOS Data segment at 0040:0000
The 'secondary' head would be running as VGA (BIOS mode 0x03 - Video RAM at B800:0000).
The application suite performs direct writes to the VGA mode video RAM @ B800:0000 and it uses NO cursor, NO scrolling... (In the process, it violates almost every possible 'standard'... LOL)

If I had a nice clear manual on the R100 specifics (including ALL registers at the bit level), I could confirm or deny if the concept will work with a fairly good level of confidence.
Trying to 'guess' based upon the R100 register list in the sources is far less certain.
I've grabbed some new/old-stock R100 based dual head cards (just a few to start with) and I'm going to 'play' for a while.
Luckily, it's just a 'fun project' for me. I hope to learn a bit (a lot?) from it (along with refreshing my few remaining aging braincells with some OLD tech hardware).

Wish me luck!

[oliver]

Not wanting to go Too offtopic, but might it not be more then justified to rewrite this application so that at the very least it coul drun in maybe dos-box under linux if anything? If there is no support or anything for this application, I hate to say this, but you'll get screwed over in the long run anyway. Costs of finding such old and exclusive hardware will keep going up and finding it will be even harder.

As for r100-r200 based hardware, I have an old IBM x226 series server that has an onboard 7000 based radeon. Having the r100 supported wouldn't be interesting in terms of 3D games or even 3D desktop, it could be interesting for media boxes I guess but maybe somewhat more for opencl. You could offload, once supported, raid calculations, ssl calculations etc to the otherwise unused GPU.

Having said that, I'm in the process of migrating the old x226 out to be replaced by an HP microserver (n36l). Not because it's faster, the dual CPU 3.0ghz xeon is quite a bit faster, but because it's much quieter and uses a LOT less electricity. The idea still stands however, it uses an M880G (radeon hd 4200) which woul dbe very interesting to use to offload certain stuff too. Once software (and driver) support is in place

[trev_vb]

Not wanting to go Too offtopic, but might it not be more then justified to rewrite this application so that at the very least it coul drun in maybe dos-box under linux if anything? If there is no support or anything for this application, I hate to say this, but you'll get screwed over in the long run anyway. Costs of finding such old and exclusive hardware will keep going up and finding it will be even harder.

As for r100-r200 based hardware, I have an old IBM x226 series server that has an onboard 7000 based radeon. Having the r100 supported wouldn't be interesting in terms of 3D games or even 3D desktop, it could be interesting for media boxes I guess but maybe somewhat more for opencl. You could offload, once supported, raid calculations, ssl calculations etc to the otherwise unused GPU.

Having said that, I'm in the process of migrating the old x226 out to be replaced by an HP microserver (n36l). Not because it's faster, the dual CPU 3.0ghz xeon is quite a bit faster, but because it's much quieter and uses a LOT less electricity. The idea still stands however, it uses an M880G (radeon hd 4200) which woul dbe very interesting to use to offload certain stuff too. Once software (and driver) support is in place

Firstly... I just re-read my post and MAN do I waffle on a lot <Grins>
As for 'rewriting' the application, I would dearly LOVE to, but it's not MINE to rewrite! I'm just the fool who has literally volunteered to keep those old girls running!
FYI, I have already written a comparable application that performs all the same functions in a COMPLETELY different manner (and in doing so, I designed and built completely different hardware that I consider more 'appropriate to the current millenium').

My big 'motivation' for doing this 'the hard way' is that I hope to gain a LOT of knowledge in the process about basic some of the basics re GPU handling. (Something which I recall Bridgman alludes to earlier in this thread)
It's quite plausible that I might find out it's impossible to achieve my desired end goal and I'd be perfectly happy with that (providing I'd learned a lot in the process).
And lastly, if I was tackling this from a truly 'commercial' perspective, all that 'old iron' would have been thrown into the dustbin as step 1!
(I am fairly confident the PSU in some of my 'old iron' is '80-plus'... Namely, the tired old FAN in the PSU sucks 80+ Watts of power!!!)