login
Search
Hello all, I'm trying to get a better picture of everything that's needed for a video card, so I can hopefully help out in the near future with well, something. I'm willing to document a whole lot of things (as soon as I understand it myself). Right now I convinced myself I 'get' how PCI works, but right after that I'm stuck. I'm hoping somebody can answer (some of) the following questions; a) How do plain VGA registers (lots of documentation talks about things like address 3B4h) get 'mapped' to the correct PCI device? Is address 3B4h in C/BE#'s 'I/O Space', 'Memory Space', or some added fields to the configuration space? b) If I plug in a PCI device which identifies with Base Class 03h, Sub Class 00h and Interface 00h, will the PCI BIOS and/or 'main' BIOS use this automagically or is some action from the PCI cards' point of view required? How tightly is this coupled with question a? Do I (the PCI card) need to request any mapping? c) What's all this talk about VGA BIOS? Where is it located (motherboard or PCI card) and if this contains code which is executed by any other BIOS calls and/or interrupts, what does it (as a bare minimum) need to support? d) All registers seem to be explained, but I can't figure out how you switch the graphics mode. Every document seems to say 'just switch to mode 3', but from a PCI card perspective, how is this done? Is this a specific register? VGA BIOS instruction? That were the more fundamental questions for now, I got a few 'less tricky' ones as well :) d) How is OGD1 doing this whole VGA BIOS thing, and why can't I find anything of it in the CVS? e) Is there a movie available of OGD1 working at OSCON? Really curious, that's all. :) Thanks! Mike www.wacco.mveas.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC ...
3B4h is in I/O space. And it's not in a BAR-mapped space. When our PCI controller sees that address (and we've enabled VGA), it decodes a limited range of "legacy" I/O space addresses. These are the only I/O space addresses we support. All others are memory space. Since these legacy addresses are not allocated to a particular device, there are certainly concerns in a PC system about more than one device attempting to accept them. I think the correct thing to do is have the first VGA device figure out that it was initialized first (there's a certain order in which a PC BIOS initializes devices, with the console gfx card being very early) and be the only one to enable the decode. (Enabling the decode would be device-dependent, I would I'm guessing you're referring to a VGA device (I don't have the class listing in front of me). Basically, when the BIOS starts up, it looks for one of these devices very early in the boot processes and sets it up. Then it does other initialization, followed by setup of other PCI For our purposes, "VGA BIOS" is a bit of x86 code that resides in our EPROM that sets up our card in VGA-compatible modes. There is a header with a certain format. Somehow, we hook into a table of far pointers (this is all done in real mode) so that certain x86 traps (interrupts) are directed to our code. (Look up int10.) We can then provide hooks for changing text/gfx modes, writing characters to the screen, etc. Note that many DOS programs completely bypass some of these system calls; for instance, when in an 80x25 text mode, software often just assumes a standard 2 byte per character arrangement and write to the display memory directly. That's one of the reasons we It hasn't been written yet. Our XP10 FPGA is hooked up to a SPI PROM, and we have all the logic in there to handle THAT part of it. So if someone were to write the VGA BIOS, we could put it in there, and then with all of the supporting logic ultimately in place, we can act as a No. ...
I don't know the exact details, but I'm fairly sure the system bios handles this. ie. it only initializes the VGA bios for one card. Other devices are just setup as regular PCI devices, and it's up to the OS to "boot" secondary VGA devices. Many BIOS have a setting that lets you choose whether to prefer AGP or PCI VGA cards. My guess is that there's a bit in the in the option ROM header that says "I'm a VGA card". Either that or it just goes off the PCI class. Paul _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yeah, those are the base class, subclass, and interface he was talking about. I think these numbers are readable from PCI config space. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The MB's BIOS initializes only one of the graphic cards. As far as I remember, the secondary card's boot message appeared only at the time when X was started in dualhead mode. Which one is being initialized at boot depends on bios settings, usually you have a choice to init PCIe or PCI card first. Result: we don't need to handle sharing of cards in any way. Reset = turn off everything and if the bios is run, then initialize the card. Question is how to detect which card's bios is being executed in case you have 2 cards on same bus :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
There may be some way for the VGA BIOS to detect (query from the system BIOS) which physical device it's being run from. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
So the X driver does everything through memory space, and only the VGA bit is optionally done through I/O? And that's currently not working yet? Aka; you don't see a boot message yet but you do see X booting after a while. Earlier talks were suggesting that VGA was working (you see the energy star logo and all that) so that's where my VGA BIOS That was VGA. :) From all this I understand that these legacy addresses are broadcasted to all cards on the PCI bus, or just automagically passed on to the initialised PCI VGA card. In any case, from a PCI card perspective I I've done some OS-related development so I'm familiar with interrupt tables. I'm just confused on the point of 'we hook into a table..', how is the BIOS giving us that option? Is there some magic boot sequence which enables us to get temporary control of the CPU? Does the BIOS asks for data from an address, which is then copied from the EPROM into main memory and finally executed (so we can register interrupts etc)? Also, how is the a000h memory range mapped to our device? In safe mode I assume we just have to use a driver which talks to the PCI bios somehow to do memory read/writes, which on the PCI card are So no boot screen until X starts, right? And does this mean that this rom is platform dependent? Mike www.wacco.mveas.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
We're some way off from having VGA working. Here are a few of the things that need to be finished to support it: - _Our_ PCI controller has never actually been tested in hardware. We've actually been using someone else's (with permission, of course). We need to test ours in hardware so that we can decode those I/O space accesses. - We need to finish the nanocontroller and integrate it. All addresses are broadcast to all devices. It is the device's responsibility to "claim" a particular transaction based on it Well, our decode of I/O space will be disabled by default, so in our VGA BIOS, we'll have to flip a bit (we'll probably put it in extended Nothing magic. The system BIOS probes each device's EPROM and looks for a particular header format. Part of that header is an x86 jump instruction. For a VGA console, the system BIOS jumps through that, and so our code executes. So, in our code, we're supposed to modify the interrupt table to point to some of our own code or something like that. We may also have to store the original vector so that we can forward requests we don't Yeah. PCI devices have a special BAR that points to the EPROM. The system BIOS will enable that and either shadow it in RAM or execute We decide how it gets mapped. I'm not sure exactly how to make just a If you're talking about like Windows "safe mode", basically, everything just thunks to real mode and uses int calls to the BIOS. Yes and no. PCI provides a way to chain multiple firmwares in ROM. One header points to the next header, etc. So we can include firmware for PC, SPARC, Alpha, HP, etc. The PC only maps 64k bytes, so we'd put the PC code first. Other platforms can map the whole thing, so we can stack them further down. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing ...
Why the nanocontroller exactly? Anything specific or just general 'ordering of things'? I'm guessing that's going to need some sort of Yeah ok, but we don't have to drive a specific pin low on a specific I found the appropriate second in the PCI Specification, I'll read up What exactly do you mean with BAR? Is that short for "Base Address Register" in the configuration space? If so, I get it (I think, the 'base' part is We're pretty much stuck to this location because as you said earlier (and I've done a few times myself) some applications write directly to that location. I meant more as in, for interrupts there's an interrupt table, is there a table for memory mappings as Sorry, I meant protected mode. And switching back to real mode is expensive, I really Again, I'll read up on it. Thanks again for the suggestion, everything is starting to make a whole lot more sense right now :) Mike www.wacco.mveas.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
One discussion was about managing DMA transactions (controlling the PCI master and also decoding command packets). Another discussion was about VGA. In either case, it might be more cost-effective to develop dedicated control logic. But given that both DMA and VGA won't be used at the same time, along with the advantages of having something more flexibly programmable, we decided to go ahead and develop a simple contoller to manage them. (For VGA, the controller's job is to emulate VGA by translating from text characters to pixels in the background, rather than putting the translation logic into the video Yes, Base Address Register. BTW, sometimes, we'll refer to the memory space itself (configured by the register) also as a "BAR." My wife, with her two graduate degrees, tells me that this is a form of Besides the config space of the device itself, there's probably some mapping hardware in the CPU or host chipset we can muck about with. We may want to make it configuration just how much of a aperture we'll decode. This way if, say, BAR1 can map 256 megabytes, but for the moment, we want 32K bytes, we can just change the BAR to point to A000 and also limit the decode to 32K. I feel like I'm missing something important here, though, because I know that when I did something like I think it might be, although I've noticed that there are chunks of code in certain VGA BIOSs that are 32-bit code. I don't know how it No problem. Excellent set of questions! -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I've glanced over the OGA1HQ implementation and found the discussion (including an odd assembler) from march/april, but I'll get into Metonywhat? :) I don't completely get it yet. The main BIOS will write 0xFFFFFFFF to it on boot, we set it to how much memory we want, and then the BIOS will set a particular address in it which is then where we're 'mapped'? That's how I understood section 6.2.5.1 of spec 2.2, which sounds like these registers have a dual purpose. Am I right? Also I noticed there are 20 of them, plus another one purely for the Expansion ROM. Makes more sense, I initially thought there was only As I understood it we (the PCI card) can't, the BIOS and/or system can. Although it's a bit unclear if this is tracked only in the BARs Done. I had to LOL when I saw that the 'magic header' is 0x55AA. How original! Anyway, I'm going to have a look at how much work it'll be to write this setup code for the PC platform. Hopefully next week I'll find some time to cook up assembly. It doesn't seem to hard now that the overall picture is getting clearer. Famous last words ;) Mike www.wacco.mveas.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yeah, sorta. The BARs don't allow all bits to get written. Let me give you an example. Let's say that the aperture is going to be 65536 bytes. (This is a demand made by the PCI target.) The BIOS will write 0xFFFFFFFF, but when it reads the register back, it'll get 0xFFFF0000 (the lowest 2 bits may not be zero). Based on that, the BIOS figures out that it needs a 64KiB area in address space. These memory spaces are always 2**N in size, and they also have to be placed on 2**N boundaries. The bits that read back 0 can never be anything else. The BIOS finds an aligned 64KiB area and writes the address of Not 20. I believe it's 5. Keep in mind that these are 32-bit numbers, but the addressing is byte-oriented. All cfg space registers If we make the BAR sizes configurable, then we can let them be remapped at whatever sizes dynamically. Basically, it's the target (device) that controls how much memory is Sweet. We have nearly enough of the VGA stuff in place that perhaps it should be the next major thing for us to do. This way, people can use unaccelerated OGD1 boards as VGA consoles. Then we can add a simple 2D blt engine, and then keep working our way up. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Might I ask how you found the PCI Specification? Surely, you did not pay $3000 to join the PCI-SIG? Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
There's a book you can get from Amazon that is basically a superset of the spec. http://www.amazon.com/PCI-System-Architecture-MindShare-Inc/dp/0201309742/ref=pd_bbs_s... -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Second? Did I really say that? I must've been asleep. Oh well. And I've got "The PC-hardware book" by Hans-Peter Messmer (translated to Dutch from German I believe) which explains a boatload of details. Really nice book. Mike www.wacco.mveas.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I was wondering about that, too. I assumed my English just wasn't up to Thanks for the tips, both of you! If have actually already ordered the book that Timothy linked to. Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The book arrived today, and I now understand a *lot* more about PCI than I did previously. Thanks again! This might not be the place for these things, but if you don't mind spending a little time on me, there's still something I don't quite understand in relation to VGA legacy address decoding. Namely, how does the system select which card is supposed to do legacy decode? Since it is usually selectable in the system BIOS UI which card should be initialized as _the_ VGA card in the presence of multiple VGA-compatible cards, there has to be some standardized way of enabling legacy decode on a card, right? I just can't find what that way is. My naive guess is that it might be that the system BIOS only calls the VGA BIOS code for the selected card, and it sets up legacy decode in a card-specific way, but I can just find no way to confirm that, and I've been googling for quite some time now. Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This is definitely the right place. We need VGA emulation. If there's a standard way to enable/disable VGA legacy decode, I don't know about it. I've seen cards with a physical jumper. But what I think is more common is that VGA is enabled in a device-specific way by the VGA BIOS code. The system BIOS finds the first VGA-capable card and runs its BIOS code, and that code will switch on the decode Possibly, but a lot of "standard" things are only standardized by the Time to disassemble someone's BIOS code and find out? :) Note that anyone who does that needs to be careful about how they contribute to developing a new BIOS, because we don't want to be accused of stealing code. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Bochs and qemu use an open source BIOS and vgabios implementation (the actually have two - one for a "real" cirrus card, and one for a fake emulated VGA device). I've never tried multiple heads inside qemu, so I can't guarantee it'll do the right thing there. It may be a helpful way of poking at a normal startup sequence though. Paul _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Just for the sake of trying, I attempted to extract the BIOS of one of I suspect that the `[disabled]' string is key to the failure, and with my new-found knowledge of PCI along with `lpsci -x', I can tell that the ROM decode is disabled, but then the question arrives how to tell the kernel how to enable it. I can't imagine that the kernel will enjoy me writing directly into the config space (although it is allowed through sysfs). I would have thought that the kernel would enable it for me if I tried to cat /sys/bus/pci/.../rom, but it didn't (instead cat got EINVAL from read()). I can't find any other reliable mechanism to enable the ROM. So, is it safe to just write the address mentioned in lspci into the config space or will my machine crash and die if I try? Has anyone tried? As an aside, isn't it weird that the kernel keeps the address allocated if the decode isn't enabled? If the address space is allocated, why *not* decode it? Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
'setpci' is a common linux tool that will do it. You need to set bit 0 of offset 30h in config space for that card. Then you can read from the memory location reported by lspci. You could also just read the shadowed version in the c000 segment. See: http://linuxbios.org/VGA_support It may not really be the kernel that did that, but probably the BIOS. The PC BIOS will enable that expansion ROM, shadow it, disable it, then execute it. Note that this is "allocated" out of PCI memory space, so it doesn't really help to reclaim it. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I see. So it is OK the alter the PCI config behind the kernel's back, in Since I have three cards in this machine, though, I don't think there is any way for me to know which one is shadowed there at the moment, right? Generally, I wonder how the X server manages this thing. If I'm not mistaken, some drivers routinely call into its card's VGA BIOS to do various things whose real interfaces are undocumented. But the VGA BIOS must reasonably expect to be able to access the card through the VGA registers, as it cannot know where the card's PCI resources have been mapped, right? Therefore, I guess that the X driver has to tell the card to start decoding VGA addresses before running the BIOS code and then tell it to stop again after the BIOS code returns (if it didn't tell it to stop, it would never work with several cards in a system). But when running more than one X server (I currently run three servers, one for each card), there has to be some mutual exclusion device to make sure that only one card decodes VGA addresses at a time. I think I will try and look through some X drivers for hints on how it is done. Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
As long as you don't change the address, it should be just fine. Check this out: http://en.wikipedia.org/wiki/VESA_BIOS In the card's firmware are protected mode routines that you can call to do things with the device. It can ask the system BIOS for the flat address of whatever BAR it needs to access in the device. Typically, then, it would not use legacy VGA registers but talk to the device through memory space. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Heh, now that you mention it, I even remember it from writing protected mode DOS games many years ago. :) However, that does not seem to be the entire story, because I'm currently browsing through the X driver for S3 cards, and it definitely uses the real VGA ports to do things with the card. It's guarded by some functions that seem to be controlling access to VGA hardware inside the X server, but it in turn uses some very indirect calls to do the actual work, and I have yet to find where they are initialized and defined. I also found this: <http://www.x.org/wiki/PciReworkProposal> Point 7 under "Required Functionality" covers the fact that the X server hackers want VGA ownership arbitration, so there clearly is a need to turn VGA legacy decode on and off. I'll continue my research. Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I see that Tom Sylla answered your main question. I probably shouldn't have suggested reverse engineering someone's BIOS. I don't know the laws about that, and information acquired this way must be handled very carefully. WE have to be especially careful, because the OGP could be damaged by even false legal claims of us stealing someone's intellectual property. In other words, lacking more knowledge, the OGP should avoid even many legal activities that someone might take issue with, erroneously or not. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I see. Then I will refrain from extracting my BIOS code, just to be sure not to cast any doubt over OGP. Fredrik Tolf _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That being said, if you have documentation on how the VGA BIOS should be arranged (tables and such), there's no harm in getting a look at a real one to make sure you have understood the standard. I would just avoid looking at any code specific to one of the major vendors. Perhaps you could get your hands on a card made by a company that is now defunct. I see no reason why you couldn't use this as a means to verify facts that are otherwise publically available. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
If you do that in Slovakia (central europe) then such an action is totally legal and it is one of the exceptions given by law - "reverse engineer someone's code to ensure compatibility". To follow that law, we could reverse engineer only a PC BIOS, or let the linux-bios people reverse engineer a VGA BIOS (the next paragraph in the law forbids RE for competitive purposes - e.g. OGP looking at NV vga bios, etc). Anyway, anybody asked linux-bios if they know the answer we're seeking? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Would it be legal for us to look at/use the Bochs BIOS(s)? Actually, taking a quick look at the BIOS source (under LGPL), they appear to handle the int 10h by simply handing it over to the VGA BIOS. There is a vgabios project which is the Bochs BIOS under LGPL. I haven't had time to more than glance through, but it looks as if it is pretty well documented and could easily serve as a reference. From their README: The source code is based on information taken from : - Kevin Lawton's vga card emulation for bochs/plex86 - Ralf Brown's interrupts list avalaible at http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html - Finn Thogersons' VGADOC4b available at http://home.worldonline.dk/ ~finth/ - Michael Abrash's Graphics Programming Black Book - Francois Gervais' book "programmation des cartes graphiques cga-ega- vga" edited by sybex - DOSEMU 1.0.1 source code for several tables values and formulas Finn Thogersons' looked interesting, so I downloaded it. There is a file called PCI.TXT that contains initialization instructions for PCI cards. Luckily, the license, while not LGPL or such, is basically "You can use it for whatever as long as you mention my name and VGADOC somewhere." Hope that helps! _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't see why not! The problem with looking at a _proprietary_ BIOS is not that we'd necessarily be doing anything illegal, but that they don't want us competing with them. They would not hesitate to CLAIM that we did something infringing or illegal if it suits their purposes. The Bochs people, on the other hand, are developing Free Software, encouraging others to share in their knowledge. They would not object to us learning from their work. They would also not object to us using their source code under their licensing terms. The only situation where we have to be careful HERE is this: Part of what Traversal was formed for is so that the OGP could commercially license its IP. But that means that Traversal has to hold the copyright (or have an unrestrained license). The OGP can use any libre stuff they want, but Traversal needs to be very careful about what we may relicense under other terms. It's just as bad for Traversal to infringe on a Free Software copyright as it would be for us to infringe on any other "intellectual property." -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Thu, 9 Aug 2007 21:40:41 +0200
The original way of doing things were, that the BIOS expected
to have executable code at certain memory locations. This got
later changed to some probing (IIRC some signature) at fixed
memory positions.
If you are old enough, you might remember that old ISA devices
hat lots of jumpers or dip switches to set on which memory addresses
the card should listen to.
I'm not sure whether the afore mentioned Ralf Browns Interrupt List
explains how this works. If not, you have to look it up in some
old PC books. The german "PC Intern" (by Michael Tischler)
used to do a good job in that. But i guess that any better
PC internal book from until mid 90s should do the job.
Attila Kinali
--
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Just barely, but yes, I remember them. Ah, when everything was so Ralfs' list afaik only tells you what interrupts do what, not how it internally 'really works'. I have some books here explaining those details. My problem is that once the BIOS jumps to the OS bootloader, the memory map has already been set up so I've never seen this being 'organised' somewhere. The OS can then add and/or remove interrupts, but I've never seen it happen that memory mappings are altered in some way (real mode, I don't mean moving around in the page tables of protected mode). I don't know how to 'set this up' when the ROM is executed on boot, on the 'computer side' of things (not on the PCI card self, we can do whatever we want there). Or maybe I'm overcomplicating things and there's no such thing as a table of mappings. Mike www.wacco.mveas.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
On Wed, 8 Aug 2007 23:12:27 +0200
I think you might still have problems understanding the
notion of memory space and i/o space and their relevance.
Best documentation of this i found so far was the docs on
the old Intel chips, 8086/8088 and 80186/188. Especialy the
Embedded processors 80C186EA/EB/EC (long time EOL, but the documentation
should be still online). Other than that, any decend x86
assembler book should cover this.
Also worth a look is Ralf Borwns interrupt list, which is
a classic among the unoffical docs on x86 based computers
from the time where DOS was all and everything. It has some
additional docs on where and how certain devices are accessed.
These days most of the original design goals of the x86
I/O system are not valid anymore, but their side effects
are still visible. That's why the PCI spec gets at times
a bit confusing on these things.
Attila Kinali
--
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)