On 13 Nov, Stefan Reinauer wrote:
Dear OpenBIOS readers,
I had the time to have a closer look at Daniel Engstroems code now and I think we should use this as a code base for further developments. (Daniel, I hope, you allow this :>)
Ok. :)
About the name, when I thought of the name I very delibraty(sp?) avoided the use of the word 'BIOS', since we're actually not trying to clone the BIOS, but doing something rather generic. Not that this is important or anything...
We only have support for 3 chipsets right now.
2, the Ali 1510 support does not work yet...
which is definitely not enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets, as I have an old HX board at home. If anyone is capable of doing this (it's not really hard, as you just need the datasheets for your chipset and a board containing the chipset itself to test)
I must admit that having the data sheets helps, but the only chipset I have found data sheets for is the ACC1287. Having a working bios image on disk is what really helps, ndissasm is your friend. Hint: the bios enters at 0xffff0 (eg. 'ndissasm -e 0xfff0 -o 0xffff0 rom.bin > bin.txt' for a 64k bios)
I thought about building something like an eprom simulator which can be plugged into the bios socket of a board and to the parallel port of another computer which just holds a file with the bios image. This would make defelopment and testing *quite* faster. Has anyone experiences with this or does anyone know whether there are ready, cheap solutions for this?
I know they exist. A one Mbit version costs about $500 here. They can be bough from DanBit http://www.danbit.dk (Danish languge pages only) A friend of mine is thinking of designing one for other reasons, he can be found at http://www2.e.kth.se/~e92_jre/ .
A port 0x80 decoder is very useful...
Now, at the moment, we don't have hardware drivers for any bootdevices. Should we go the way linux goes and write our own drivers or should we try to use other bioses (i.e. scsi bios on host adapter) for that?
I think we need to do at least floppy and IDE ourself. That will keep us busy for a while... I still haven't given up on the idea of being 100% OpenFrimware compatible at some point in the future.
Well.. I wrote this just to start discussion again :-)
Some notes on the current code:
The chipset drives are not finished. I am planning of having a 2nd stage C part of them that runs shortly after the console is initialized, it would probe and test the memory above 1MB. (The 16 bit asm version should enable memory below 1MB with a safe timing.) The last part, also in C should set the memory timings to a value specified by the user (saved in the NVRAM, obiusly)
the boot/init32 directory should be moved to the top level firmware dir.
Only MDA displays are working, the EGA/VGA stuff is some bone headed attempt to get those working without using their BIOSes, it might work for some cards some day, the other plan is to steal some 386-emulator to parse the video BIOS with, like the ppc/alpha people do (calling the video BIOS directly would just postpone the problem 'til we port this to a non-386 compatible processor, besides the BIOS is 16bit anyway).
Console in is not done yet. I can read the keyboard, but I don't keep track of the shift-state, etc. Serial console in is not done yet. (What terminal emulation should we use? Some very basic I think.) Serial console is fixed to com1,9600,8n1
Oh, and the board I have been using are Ampro CM2/3SXi, CM2/4DXi, LB3/P5i. I also have an old ASUS 486 board with a SIS chipset, that I plan on doing (I have the chipset manual, but the board have an Eprom istead of a flash, and I have no 28pin flashes around)
/Daniel
--