And you can't use uboot to initialize the card or use the uboot x86 emulator from os4? What would be the easiest way to solve this problem without just looking for pitfalls?
@Rogue
If you're reading this, what's your take on it? Could the x86 emulator that 'you' wrote for uboot be reused from within os4 somehow if it's not possible to do via uboot once os4 is up and running?
Perhaps a VESA or gfxcard BIOS api wrapper can be made that can be called from OS4 applications/drivers so that applications don't have to deal with interpreting/emulating x86 code.
Edited by orgin on 2007/9/15 16:23:49 Edited by orgin on 2007/9/15 16:24:34 Edited by orgin on 2007/9/15 16:33:23 Edited by orgin on 2007/9/15 16:44:00
I know that it needs an x86 emulator. Who wrote the emulator that UBoot uses? Depending on the license, perhaps that one could be used.
The other issue is the number of poor VESA implementations around. Rogue encountered a huge variation on Radeon cards when having a quick look at using VESA modes for a graphic logo on startup (like the SAM board has). It would have to be tested on a wide range of graphics cards.
The advantage would be that we'd at least get a display on all graphics cards.
I thought so but couldn't confirm it. If they wrote it, they should be allowed to release it under a dual license (i.e., a GPL version for UBoot and proprietary version for the driver).
Actually, I'd prefer it if they concentrated on a new graphics API/driver system that will rid us of the limitations of the current one that are ruining 3D performance. As I said earlier, a Radeon x1### PCI card could be used to develop the new system on the same machine that's using the old system for the AGP card. That way you'd still have a working display on the machine while developing and testing the new system. If you're really stretched for cash, you could use a KVM (for it's monitor switching only) so that you don't need two monitors.
And you can't use uboot to initialize the card or use the uboot x86 emulator from os4?
U-Boot could set up a VESA gfx mode, but all you'd have is a single frame buffer in a fixed mode, you couldn't switch to different modes in OS4, and using more than one screen wouldn't be possible without ugly hacks like the HAM emulation of OS4 either. To be able to use more than one screen, all in the same, fixed resolution set up by U-Boot of course, for example all screen and other bitmaps would have to created in mainboard RAM and the contents of the current screen would have to be copied for example 50 times per second to the frame buffer, a dumb frame buffer for a single screen would be very slow already, but something like that would be completely unusable. When AmigaOS4 is started U-Boot is gone, it initializes the system and passes some arguments to AmigaOS4, but it doesn't survive.
Quote:
What would be the easiest way to solve this problem without just looking for pitfalls?
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.
Probably because it's wrong The BIOS and x86 emulator in U-Boot is from SciTech (they used it for SNAP), Hyperion licensed it and IIRC ported it to U-Boot as well, but they didn't write it.
* x86 BIOS emulator capable of initialising and using nearly all PCI and AGP graphic cards based on the chipsets of ATI, nVidia, 3DFX, S3, 3Dlabs (Permedia), Trident etc.
But anyway, that's too bad then. Probably not so easy to reuse it from within os4 then.
I disagree, I think that OS4 could use a VESA driver. As I said, it's not for performance, it's for at least getting a display out of any card you might find out there. Specific drivers isn't growing like weed in mums garden and old cards are going to get harder to find.
If my gfx card broke down I would have to special order a new one from something like ebay or over priced from some amiga outlet. I'd rather be able to at least get it going again using a cheap card from a local dealer than waiting for the postal service to stumble over itself.
* x86 BIOS emulator capable of initialising and using nearly all PCI and AGP graphic cards based on the chipsets of ATI, nVidia, 3DFX, S3, 3Dlabs (Permedia), Trident etc.
Whats wrong with that? U-Boot can use (nearly) any gfx board AFAIK, it is e.g. able to create DVI output on a Radeon and I remember that somebody did send me a gfx board where OS4 had no driver, U-Boot could happily use it and OS4 was even clever enough to display the "No P96 driver for this board" message on the gfx board (in text mode as initialized by U-Boot) before giving up.
joerg wrote: (SNAP) Maybe it had a generic VESA framebuffer driver as well, but the main point of SNAP was that it has accelerated drivers for lots of gfx cards.
It says that it was implemented by Hyperion, which to at least me means that they wrote the code. But supposedly they didn't so I guess the text needs to be interpretated some other way.
* x86 BIOS emulator capable of initialising and using nearly all PCI and AGP graphic cards based on the chipsets of ATI, nVidia, 3DFX, S3, 3Dlabs (Permedia), Trident etc.
What's wrong there? Hyperion did implement it in U-Boot/PPCBoot, using the SciTech emulator. Without it there would be nothing on the gfx card in U-Boot and you'd have to use a serial terminal for changing U-Boot settings or to select a boot configuration in the SLB.
Anyway to get back to the other off topic discussion, to get VESA going we'd need an x86 emulator or at least a step by step interpreter but can't use the code for the UBOOT one since that was (probably) not part of the license that Hyperion got. If I remember correctly the gfx card BIOS uses 8086 instruction set or is it using a more modern instruction set like 80386?
I wonder if the emulation would have to be able to handle interrupts. Or if it would be enough to just interpret the x86 instructions one by one, keeping track of cpu flags and registers, move data to from memory, handle jumps to other sections and such.
I'm not that much into what the BSD license allows, but I assume that it in contrast to GPL allows you to include it in commercial software such as OS4?
Probably. I have no knowledge of writing device drivers not least P96 drivers, and only looked at the code briefly so don't really feel qualified enough to comment. There are four directories within the source code dir though - one was for the bios emulator, and I forget the other three. Somebody who knows how to write P96 drivers might be able to knock something up.
"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg
Probably. I have no knowledge of writing device drivers not least P96 drivers, and only looked at the code briefly so don't really feel qualified enough to comment. There are four directories within the source code dir though - one was for the bios emulator, and I forget the other three. Somebody who knows how to write P96 drivers might be able to knock something up.
You'd only require the x86emu part of it for a graphics driver. I have no idea how long writing a driver would take.
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
The 
