A new BIOS for the i440fx

[fysnet]

Hi guys,

Partly because the current BIOS is buggy, but mostly I wanted to see if I could do it, I have created a new BIOS.
It is based on a lot of the existing BIOS, but with many fixes and enhancements, namely it will now boot from a USB device.
I have the 128k image at: https://www.fysnet.net/temp/i440fx.zip
Use the standard romimage declaration: romimage: file=$BXSHARE/bios/i440fx.bin

If you apply PR #209, you can simply add the following line in your bochsrc.txt file.:
boot: usb

It will try to boot the first USB disk it finds. Without that PR, you can simply press F12 when prompted, and choose one of the devices.

No other modifications are needed.

UHCI, OHCI, EHCI, and xHCI is supported.

There are a few things I still need to do. It will boot a floppy and hard drive image, but not a CDROM since it can be emulated as a floppy, HD, or no emulation at all. The code is there, due to that fact that I emulate El Torito with standard CD-ROM images, I just need to modify it to use the USB CDROM image as well. So currently, booting a USB CD-ROM is not fully supported.

It is completely writing in x86 assembly. Yep, you read that right, assembly. I have written it in assembly, assembled with my own assembler (https://www.fysnet.net/newbasic.htm). It assembles using only the assembler, no external utilities are needed. i.e.: no preparser, sed, biossums, or anything. Simply give a couple command line parameters to the assembler, and the whole thing is built with one utility.

However, I have not included source at the moment. It needs a lot more testing first. I am including the binary here asking that, if you so desire, please try it.

I have tested with most Windows versions up to WinXP, and I haven't found any errors yet, but that doesn't mean there aren't any.
I have tried booting Win98 as a USB thumb drive and it stops with a 'protection error'. However, occasionally Win98 gives this error booting from an actual disk image, so I think my code just triggers the error.

I have booted DOS based images, HD and Floppy, as USB drives and they seem to work as expected.

One of the enhancements you might find quite quickly is that it boots into a graphic mode displaying an icon as it boots. Another is PnP support, as well as a limited Boot Specification interface support.

Anyway, I am simply asking tests be done, and let me know what you find. I tested with everything I got, but that isn't anywhere enough of a test. If you so desire, please test and let me know what you find.

If you can include a link to the booted image you tried, that will be very helpful.

Thanks,
Ben

P.S. If you run it while in the x86 debugger, it will break on xchg cx,cx in many places. This is simply to let me know where it got and if it actually does break on one of those, it didn't make it to where I thought it should. If you can't include a test image, please at least give me the linear break address it stopped on. i.e.: 0x000E1234. Try continuing on all stops, but as soon as it noticeably faults, please note the break address.

P.P.S. As many of you know and/or can imagine, writing such a beast in assembly can be and was a challenge, but an enjoyable challenge. Being it is my own assembler, that made a huge advantage. For example, let me include a few lines of code:

           mov  es:[esi+xHCI_EVENT_RING->address],eax
           mov  es:[esi+xHCI_EVENT_RING->table_size],dl
           mov  es:[esi+xHCI_EVENT_RING->first_trb],edi
           mov  es:[esi+xHCI_EVENT_RING->cur_trb],edi
           mov  byte es:[esi+xHCI_EVENT_RING->cycle_bit],TRB_CYCLE_ON
           mov  byte es:[esi+xHCI_EVENT_RING->cur_index],0

This is from the xHCI code. Notice that there are a lot of 'helpers'. For example, the C style pointers in the lines shown. As long as I know, in this case, esi points to the start of the associated event ring, using xHCI_EVENT_RING-> will calculate the address for me given a simple struct declaration before hand.

xHCI_EVENT_RING struct
  address    dword    ; address of segment table
  first_trb  dword    ; address of first trb in segment
  cur_trb    dword    ; next free trb
  cycle_bit  byte     ;
  table_size byte     ; size of table
  cur_index  byte     ; current index
  resv       dup  5
xHCI_EVENT_RING ends

In this case,
mov es:[esi+xHCI_EVENT_RING->table_size],dl
simply translates, or assembles to:
mov es:[esi+13],dl

This way, I can add, remove, rearrange, or modify members as I see fit with little to no other modification other than the struct itself. It makes it a lot easier as well as a great side-effect, it self documents...

Anyway, enough bragging, or maybe no so much bragging, but it was an enjoyable challenge. I know most of us here can relate to that.

Thanks again, and I would appreciate any testing results you wish to share.
Ben

[Vort]

Here is test image: DOSSmall.zip.
There are two tests for it:

1. Try to format b:.
2. Try to press Ctrl+Alt+Del (with user shortcut for example).

[vruppert]

It looks promising and I hope it will replace the existing BIOS some day. Since I'm at the moment the only developer of the LGPL'd VGABIOS, I'm interested in new tools to build the VGABIOS. Over the years I have rewritten parts of the code from C to assembler. The Banshee and Cirrus extensions are asm code (except debug messages) and the rewrite of the Bochs VBE stuff is nearly complete. Only the VGA core stuff still has a lot of C code. With the planned Bochs release 2.8 I intend to release VGABIOS version 0.9 and I hope that release 1.0 will be completely asm code and build with the same tools you use.

[vruppert]

You are right. The LGPL license doesn't exclude commercial use. Since the rewrite of VGABIOS in assembler is not yet complete, switching to a modern assembler is not important yet. At the moment we have to find out whether or not the new BIOS can be included in the Bochs tree. In the Bochs bios directory you can still find the Elpin VGABIOS which is a leftover from the early days of Bochs. It has been licensed for the use with Bochs (no other limitation I think). Can we include the USB boot option in Bochs without providing a BIOS for it?

[Vort]

Can we include the USB boot option in Bochs without providing a BIOS for it?

There are 3 things which I think are important here:

1. Level of integration of boot option with BIOS code. From looking at Allow the boot usb option #209, I make conclusion that integration level is low, so it is should be possible to use any other BIOS if needed (and if it will be available).
2. It should be properly explained to user that USB boot requires separate BIOS ROM file.
3. There should be decision at which level Bochs should promote this new BIOS, considering "pertaining to this code" phrase.

Overall, I think merging of #209 won't hurt, but some additional steps will be needed.

[fysnet]

@vruppert, are you sure that LGPL license of VGABIOS is compatible with these lines from nbasm.doc?

There is no fee for any executable file produced with this package as long as this executable file is for non-commercial use. If you use this package for commercial use, please contact me for special terms and conditions.

I wrote that many many years ago, probably more than 20 years ago. It really doesn't pertain to this, so for clarity sake, I will remove it from the documentation.

[fysnet]

Can we include the USB boot option in Bochs without providing a BIOS for it?

There are 3 things which I think are important here:

1. Level of integration of boot option with BIOS code. From looking at [Allow the boot usb option #209](https://github.com/bochs-emu/Bochs/pull/209), I make conclusion that integration level is low, so it is should be possible to use any other BIOS if needed (and if it will be available).

2. It should be properly explained to user that USB boot requires separate BIOS ROM file.

3. There should be decision at which level Bochs should promote this new BIOS, considering [_"pertaining to this code"_](https://github.com/fysnet/i440fx/blob/a18a6e0291fc02ddb3ef3e2406fb9c0e8097d399/boot.asm#L12-L14) phrase.

Overall, I think merging of #209 won't hurt, but some additional steps will be needed.

The header on each .asm file pertains to it currently, as it is my code. However, if and when we/you decide to integrate it into the Bochs tree, another license can easily be applied. My intent is for all to use it as they wish, when (and if) it is part of the Bochs package.

[Vort]

... another license can easily be applied ...

I think this list gives good idea about what licenses may be compatible with Bochs:
The Open Source Definition – Open Source Initiative

@vruppert should know better however.

[fysnet]

Thanks guys for your feedback.

Having custom assembler means one additional dependency to support.

I don't disagree, however, the way I see it, being it currently takes gcc, bcc (and a specific version at that), sed, as86, and biossums to build the current BIOS, that is moving from five dependencies to one. A win in my book. Also, some of those expect a 32-bit DPMI environment. My assembler works in a 64-bit environment.

...and build with the same tools you use.

I am more than happy to have a look to see if I can port your code to my assembler. I tried to make it very close to MASM 5.1, so it may be a small task to do so. I am also going to see if I can get a *nix image with a *nix version of gcc and build my assembler with it, so that *nix environments can build my BIOS as well.

1. Try to `format b:`.

Two missing cs: overrides and that is fixed. Thanks.

2. Try to press Ctrl+Alt+Del (with user shortcut for example).

I have the following in my bochsrc.txt:
keyboard: user_shortcut=ctrl-alt-del
I then click on the user ribbon button which brings up ctrl-alt-del and then I click on OK and it reboots as expected.
What happens in your environment? Can you give a bit more detail?

Thanks again,
Ben

[Vort]

that is moving from five dependencies to one

Do you think other assemblers can't perform the same task as your assembler can?
Without BIOS sources, however, it is not possible to compare abilities of other assemblers for building it.

What happens in your environment?

Various hangs.
For example, with this message:
PANIC: file: :\bochs\bochs\bios\i440fx\keyboard.asm -- line: 248

[fysnet]

that is moving from five dependencies to one

Do you think other assemblers can't perform the same task as your assembler can?

Yes. For example, I can place the following line in the source file...
.checksum 0x21 0x08 ; do a byte checksum of the last 0x21 bytes, placing the result at offset 8
...and the assembler will do a zero-sum checksum of the last 0x21 bytes and place the result at offset 0x08 from that position.
i.e.: No need for biossums anymore. This is an advantage of owning the assembler. :-)

Without BIOS sources, however, it is not possible to compare abilities of other assemblers for building it.

Agreed. All in good time.

What happens in your environment?

Various hangs. For example, with this message: PANIC: file: :\bochs\bochs\bios\i440fx\keyboard.asm -- line: 248

That line means the self test did not return 0x55.

I used the same declaration lines you have:

keyboard: type=mf, serial_delay=150, paste_delay=100000, user_shortcut=ctrl-alt-del
mouse: type=ps2, enabled=false, toggle=ctrl+mbutton

and still have it work as expected. The emulation reboots as expected both with and without x86 debug support compiled in.

However, I decided to use your bochsrc.bxrc file as is, and I got the same results as you stated. I went back to my bochsrc.txt file and after doing random resets, after the 4th or 5th reset, it started acting up. I will have a look.

Thanks again. Your feedback is appreciated.
Ben

[fysnet]

Various hangs. For example, with this message: PANIC: file: :\bochs\bochs\bios\i440fx\keyboard.asm -- line: 248

Yep, a jmp to the wrong place. Please try now. (https://www.fysnet.net/temp/i440fx.zip)

Much appreciation.

[Vort]

With new version both format and reboot work correctly.

[fysnet]

Just a follow-up. Work on this BIOS is progressing. (new file at https://www.fysnet.net/temp/i440fx.zip, dated 25 Feb 2024)
There are still some issues, namely preserving the FS selector during a BIOS call. I am working on this.
As long as the Guest doesn't use HIMEM or other memory managers like this (while in real mode), it will boot a USB image with all four controllers supported in Bochs and QEMU.
I have included a notes.txt file that I have started making notes about what it can and can't do as well as how to use it.
Thanks,
Ben

[fysnet]

...namely preserving the FS selector during a BIOS call. I am working on this. As long as the Guest doesn't use HIMEM or other memory managers like this (while in real mode), it will boot a USB image with all four controllers supported in Bochs and QEMU.

I think I have fixed this issue. Now works with HIMEM, etc. If you have a chance to test it, please do. (same URL, new file)

Thanks,
Ben

[fysnet]

As an update, I think I have fixed all known issues and added all items that need to be added (except for a couple more) and have tested as much as I can.

The link for this BIOS is still at https://www.fysnet.net/temp/i440fx.zip and still only includes the binary(s), for now.
I need to add a few small things and finish the CD-ROM boot stuff and then I think it is ready for source code release.

It includes two image files, one for Bochs and one for QEMU. Except for a few (known) items, it should boot QEMU just like it boots Bochs.

I have added a minimal GUI style setup app invoked by pressing F10 at the same place you would press F12. It needs some work, but the basic core is there so it should be easy to add other things now.

Anyway, just an update, and a thanks for the tests,
Ben