Just a quick update: a basic 2D driver is available now. The license appears to be very liberal (i.e., no GPL). This could well be used as a basis for an Amiga driver.
BTW, what extactly is git? It looks like yet another CVS/subversion like tool.
IMHO a VESA gfx driver doesn't make sense, we need a new, faster gfx system using hardware 3D, not something which is much slower than the supported gfx cards. A VESA driver can be used for booting a system which doesn't have a driver for the currently installed gfx card yet to install the new gfx card driver, but not for normal usage.
I wouldn't mind having some generic VESA mode driver. Why? I've got a particular Radeon card who's chip IDs are not yet in the graphics driver ID list, so the system does not know to load the Radeon driver for it. It thinks there is no graphics card present. How do I add my card's IDs to the list? I could swap graphics cards around. I could have previously set up envoy or samba. There may eb a coupel other ways I haven't thought of. But with none of these already in place, it's an inconvenience. If I find my particular Radeon card somehow does not work withthe current driver, I could use it in VESA mode until we get things working with it properly without constantly swapping cards back and forth. If it fails the test then just reboot with VESA, make some edits, recompile and try again without the power cycle and board swaps. may not sound like much, but saving that small inconvenience would be beneficial to motivation. Sure, it'd be a lot of work to make a VESA driver, but I think it would be useful to have available if some issues could be solved.
You get into the question of how does the computer know what card is a graphics card or not to try the VESA diver with. If it's not already in the graphics card IDs list, do you ned to add your new card, and how? Or will there be some new field setting in uboot, and some list of PCI IDs you can get from uboot to know what the IDs of your new card are without booting Linux or something? You don't want the computer trying to run VESA driver on a sound card or SATA card etc but how will it know which is the graphics card? Wil it end up having the same problem with an unlisted gaphics card as I have with my particular Radeon card, and thus not really solve anything?
We do have the x86 emulation in uboot that runs graphics BIOS. But it lacks some instructions, as can be sen if you try and boot with an AllInWonder 8500-DV card, which fails due to non-implemented instruction error in said emulation. Is there enough there to run BIOS subroutines? I don' t know. Is it available to OS4 using this emulation? I don't know that too, but I am under the impression that anything uboot goes away when OS4 begins, and not much is handed off during the transition.
billt wrote: Sure, it'd be a lot of work to make a VESA driver, but I think it would be useful to have available if some issues could be solved.
I recall looking into this way-back-when, and discussing the possibility with the other OS4 developers. I think the issues with VBE (VESA BIOS Extensions) was that:
1. It's x86 calls in the video BIOS (and we had issues even reading the Radeon BIOS inside OS4 until one of the last few releases of the Radeon driver where I found a work around for that specific to the Radeon) 2. The x86 emulator is only available in UBoot (currently) 3. The x86 emulator is only enough to get the video BIOS executed (as you've pointed out below) 4. VBE uses interrupt vectors which is a whole other ball of problems in a partially emulated x86 environment that the current x86 emulator doesn't contemplate (AFAIK) 5. It'd be terribly slow (though if it's just for fallback/failsafe usage it'd still be useful) 6. It's a /huge/ amount of work 7. I'm sure there's more I'm not remembering
Quote:
You get into the question of how does the computer know what card is a graphics card or not to try the VESA diver with. If it's not already in the graphics card IDs list, do you ned to add your new card, and how? Or will there be some new field setting in uboot, and some list of PCI IDs you can get from uboot to know what the IDs of your new card are without booting Linux or something? You don't want the computer trying to run VESA driver on a sound card or SATA card etc but how will it know which is the graphics card? Wil it end up having the same problem with an unlisted graphics card as I have with my particular Radeon card, and thus not really solve anything?
The PCI header has a device "class" with it. That's how on a PC when the BIOS lists the devices it can say "Multimedia device" or "Network controller" without understanding individual PCI IDs. Specific to this discussion, there is a "display controller" class (0x03?).
The thought at the time was that PCIGraphics.card would go hunting for any PCI IDs it supported and, if found, fire up the first one (which is what it does today). If it traversed its entire list of PCI IDs, it would then query PCI (expansion.library) for the first "display controller" class PCI device and attempt to fire up the VESA.chip driver on it. For the reasons above this became impossible/impractical.
Quote:
We do have the x86 emulation in uboot that runs graphics BIOS. But it lacks some instructions, as can be sen if you try and boot with an AllInWonder 8500-DV card, which fails due to non-implemented instruction error in said emulation. Is there enough there to run BIOS subroutines?
No, not AFAIK.
Quote:
Is it available to OS4 using this emulation? I don't know that too, but I am under the impression that anything uboot goes away when OS4 begins, and not much is handed off during the transition.
Exactly, the UBoot environment and code is toast once the OS takes over.
There may be /some/ way to get it all to work. But writing hardware drivers in itself (as you know Bill :> ) is no picnic. Add to it the complexity of getting x86 interrupt vectors in a BIOS to execute in a non-x86 system, and you're in for one hellish experience.
Here's another question toward a VESA generic driver. Is there a standard definition of VESA graphics registers, refresh rates, PLL settings, etc? Previous graphics like VGA and SVGA I think were completely standard everywhere, or at least to a large extent. If there is some absolute standard for all VESA registers, their offsets, sizes, field definitions, etc. then even without an x86 emulation it could be possible to write a driver to that standard register set instead of using x86 stuff, much like the current driver talks directly to Radeon specific registers or Voodoo driver talks directly to Voodoo specific registers. Yes, a great deal of work and all. Who's interested in researching this and has time to do so? I suppose a new thread should be made to further the VESA driver concept if it gets anywhere. If there is a standard register set it's the same kind of work as making or porting the Radeon open-source driver, but probably less as there's probably not much acceleration for lines, rectangles etc. to do as there is in chip-specific drivers.
billt wrote: Here's another question toward a VESA generic driver. Is there a standard definition of VESA graphics registers, refresh rates, PLL settings, etc? Previous graphics like VGA and SVGA I think were completely standard everywhere, or at least to a large extent. If there is some absolute standard for all VESA registers, their offsets, sizes, field definitions, etc. then even without an x86 emulation it could be possible to write a driver to that standard register set instead of using x86 stuff, much like the current driver talks directly to Radeon specific registers or Voodoo driver talks directly to Voodoo specific registers.
VBE uses x86 functions (called via interrupt vectors) to set everything up. There are no "registers" per se, the BIOS exports functions to do specific things like setup the DAC or change the pixel clock. This actually makes sense as having the limitation of specific registers at specific locations with specific values (as the VGA standard does) locks you into a fixed set of functionality. For example, cards can define whatever modes they want with VBE (function 00h returns a list of modes, and you can use function 01h to get details about the modes), in VGA you're stuck with the /very/ few modes & timings VGA defines.
So you really need the x86 functionality to use VBE. You might be able to do a VGA driver with just register writes, but you'd be stuck within the limits of VGA (640x480 in 16 colors IIRC), which is hardly worth it (I don't think the OS4 installer will display on anything less than 800x600?).
Quote:
If there is a standard register set it's the same kind of work as making or porting the Radeon open-source driver, but probably less as there's probably not much acceleration for lines, rectangles etc. to do as there is in chip-specific drivers.
There is an extension to VBE called VBE/Accelerator Functions (VBE/AF). I'm not sure how well supported it is in video cards, but it's supposed to have support for some of that stuff like hardware cursors, hardware blits, drawing functions, etc...
If I had more time I'd look into it further (if only to verify it's impossible :> ), but given there's still things in the native Radeon driver that need attention and I haven't managed to get to those, I can't see me getting to this anytime soon. If some adventurous sole out there wants to give it a shot, please do, I'd provide all the info I could. It would of course require a very experienced developer, because honestly, drivers and CPU emulation aren't for the newb or moderate level. The first step (if I were doing this) would be to get the x86 emulator into some OS4 library or other resource that would allow it to be used within the OS (perhaps by passing a function some environment info and a pointer to the x86 code to execute?)... That way it could be used for other things as well later, if needed, not just a VBE driver.
billt wrote: Here's another question toward a VESA generic driver. Is there a standard definition of VESA graphics registers, refresh rates, PLL settings, etc?
No, you have to call BIOS functions to get anything with VESA.
Quote:
Previous graphics like VGA and SVGA I think were completely standard everywhere, or at least to a large extent.
AFAIK only VGA, SVGA and higher modes weren't any more.
Quote:
If there is some absolute standard for all VESA registers, their offsets, sizes, field definitions, etc. then even without an x86 emulation it could be possible to write a driver to that standard register set instead of using x86 stuff, much like the current driver talks directly to Radeon specific registers or Voodoo driver talks directly to Voodoo specific registers. Yes, a great deal of work and all.
A generic VGA, i.e. max. 640x480 4 bit planar, driver would have been possible that way, but since IIRC support for planar modes was removed in the AmigaOS4 version of Picasso96 that wont work either ... (but it could be that the planar modes were only removed from all drivers and not from Picasso96 itself).
There's a difference between the PC BIOS, and VGA BIOS. The PC BIOS shouldn't be required for a VESA driver as it's the VGA BIOS (on the graphics card itself), that contains all the routines.
A generic VGA, i.e. max. 640x480 4 bit planar, driver would have been possible that way, but since IIRC support for planar modes was removed in the AmigaOS4 version of Picasso96 that wont work either ... (but it could be that the planar modes were only removed from all drivers and not from Picasso96 itself).
Planar modes weren't removed in P96-OS4, we just opted not to implement them in the OS4 Radeon driver as their usefulness seemed rather limited today.
Oh well for VESA then. It does make mroe sense to define the software API than the register set, but a standard register set would have been more convenient for this sortof OT discussion.
I hope to get my AmigaOne booting again soon, then I can work on finding time to do something toward Radeon again.
They were removed, check the release notes of rtg.library version 41.4272. For example my Merlin supports planar modes but on AmigaO4 they are not available anymore.
But I expect the standard entry point is the PC BIOS, because that where PCI card is registered after scanning the PCI bus for vendor id?s and product id?s, the video cards IO ports and memory maps are located some where else (but only the PC bios knows where that is if I?m right.)
To understand how Interrupt 0x10 work, you need to know sub interrupt vector routine found in the interrupt vector table works.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
But I expect the standard entry point is the PC BIOS, because that where PCI card is registered after scanning the PCI bus for vendor id?s and product id?s, the video cards IO ports and memory maps are located some where else (but only the PC bios knows where that is if I?m right.)
I'm certainly not an expert in this area, but I'd expect that all that a driver would need is the PCI card's base address. PC BIOS calls aren't available once an OS starts either, the OS basically extracts the hardware info it needs, loads the necessary driver, and then stops using BIOS calls. The VESA standard should specify how to find the VGA bios; that's all you really need.
They were removed, check the release notes of rtg.library version 41.4272. For example my Merlin supports planar modes but on AmigaO4 they are not available anymore.
Hmm, interesting, must have been done after we opted not to implement planar modes in the Radeon driver...
LiveForIt wrote: But I expect the standard entry point is the PC BIOS, because that where PCI card is registered after scanning the PCI bus for vendor id?s and product id?s, the video cards IO ports and memory maps are located some where else (but only the PC bios knows where that is if I?m right.)
No, that's not correct. The PCI subsystem and the PCI devices themselves know where the apertures of the PCI devices are mapped. The PC BIOS doesn't maintain control of anything once the OS starts (remember, the BIOS is responsible for getting the system up to a point where it can load an OS, and then go away, that's really it). Of course, many mainboards have other things in the BIOS ROM like IDE controller or video card ROM images -- but technically that's not part of the BIOS, that the PCI boot ROM for these devices integrated into the same physical ROM IC.
(how many posts can I make in a row in the same thread? :> ) @Hans Quote:
I'm certainly not an expert in this area, but I'd expect that all that a driver would need is the PCI card's base address. PC BIOS calls aren't available once an OS starts either, the OS basically extracts the hardware info it needs, loads the necessary driver, and then stops using BIOS calls. The VESA standard should specify how to find the VGA bios; that's all you really need.
You'd need the PCI card's /ROM base address/ (PCI devices have several apertures with different base addresses). There is some trickery to reading a PCI ROM from the OS as it's not really mapped, so you have to swap it into an address space that's already allocated /and/ is big enough (the video card's framebuffer area is great for this). And you're right, once you do that (which we already do in the Radeon driver), it's just a matter of locating the VBE section(s) in the ROM and working with them, you really shouldn't need a PC BIOS in addition to the video ROM.
Will any of the R5xx/R6xx cards on AGP 8x work, or are we stuck with PCI?
Would you be interested in any donations of similar cards to round out your R5xx/R6xx collection? I'm thinking RV516-based X1550 and/or RV610-based XT2400 PRO if we are limited to PCI.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
