On 12/15/07, Stephen Pollei <[EMAIL PROTECTED]> wrote: > I think just going with nasm is the right answer even if it used order > that some don't like. It's 6 of one; half a dozen of another. Not > really worth futzing over.
I think I used nasm because it took the intel syntax (as opposed to AT&T, right?) that I already had source for. It was also good for disassembly. I wrote this browser tool that would take any block of binary data and let you mark which bytes are 8-bit numbers, 16-bit, 32-bit, 16-bit asm code, or 32-bit asm code. Then it would show it inline, and you could scroll up and down, set bookmarks, jump around, etc. For the machine code, it would pass the blocks through nasm to disassemble and then display that inline too. Then when you were on some kind of branch instruction, you could tell it to go there, and it would store where you were on a stack so you could hit a key and return. It was all done with curses. One of the things I disassembled with it was an x86 VGA BIOS (a proprietary one, but the vendor told us we could do it, because we had a contract with them). Which of these assemblers is most common? If the only difference is some directives, then I suggest flipping a coin or doing an informal vote. I know that people get attached to their tools, but changing assemblers isn't the most disruptive thing, especially if you can just grab it with apt-get. I cast my vote for nasm, because it's the one I have installed, and I don't have gas. > The real different between nasm and gas would be the directives. Also > I think gas might be geared pretty heavy for being 32/64bit flat and > outputing elf or other object files and not raw binaries. nasm might > be a bit more flexible for what we'd need to do. We need to output raw binary code with no extra junk so that we can just burn it to the PROM. > > I think you misspelled BSD, OS-X and Plan-9. Pesky typos. > Sure, solaris, (free|net|open)bsd, os x aka darwin aka YAbsd, linux, > windows (xp|vista), hurd, qnx, plan-9, reactos. > Frankly if you just test for windows and linux you already did more > than some hardware vendors. so fedora, ubuntu, netbsd, solaris, > darwin, windows xp, windows vista, centos, suse should cover it well > enough. I think that they shouldn't be all that radically different > anyway. There's always a chance that we have some bug that makes it break for one. Fortunately, both the BIOS and the VGA emulation are all "software," so we can just fix it easily. Of course, fixing the FPGA code isn't so bad either. Someone needs to scrounge up a copy of DOS. That'll be the first thing to try. Then try a recent Linux "text console only." Then try Windows, then each of the others as it is convenient. > Also probably needs to be tested on more than one bios -- Award, > American Megatrends (AMI) and Phoenix etc etc. They all would call > both the setup code and the int 0x10 interface. For example someone > mentioned that a bios generated logo was done by changing the fonts, > so that needs to work. Most DOS software seems to just write directly to the display memory. They don't bother with int10. And of course, protected mode stuff can't call int10. The text mode breaks the 32K area into 4K slices. I think there's like 7 screens and the 8th slice contains the font. I don't recall for sure. It will be the job of the microcode in HQ to read the font and use it to render characters correctly. We'll make it not cache anything; if you change the font, it'll change all the characters on the display immediately. The commercial entities that want to license our VGA core don't want to work with open code, so all the stuff you do needs to be original work so that we can relicense it. Since you guys are doing the BIOS, which I'm very happy about, it should probably also be you guys who do the code for HQ as well. Petter already developed an assembler for it, and it's in SVN. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
