Building the BIOS

[fysnet]

I am having issues trying to build the BIOS files.
I am using a WinXP machine.

MAKE = GNU Make 4.3 (DJGPP port (r1))
BCC = Dev86dos: v0.16.2

BCC doesn't like filenames longer than the DOS 8.3, so after making a few modifications, I got it to build the legacy bios. However, even though it is 65,536 bytes in size, it is nowhere near the same as the BIOS-bochs-legacy file.

BCC = version v0.16.10a freezes on the build. It is invoked, but never finishes. Never returns to DOS for the next command.

My thoughts are that I haven't given any parameters to:

CXXFLAGS=
CPPFLAGS=
LDFLAGS=

etc., due to that fact that I need to run some kind of script to configure the @CDFLAGS@ etc. portion.
However, I don't see any script or other documentation stating what these should be.

Whoever has the ability to build the BIOS files, will you please explain the process? The platform you are using? etc.

Maybe even just share the makefile that is the result of running said script.

Anyway, if anyone has more information on building the BIOS files, any help would be grateful.

Thank you,
Ben

P.S. My reason: I am tracking down a bug that I think might be in the BIOS, so I need to modify the BIOS to help find this error.

[Vort]

My thoughts are that I haven't given any parameters to:

Bochs should be configured in the same way as for building bochs.exe.
Then bochs\bios\Makefile will be created.

Whoever has the ability to build the BIOS files, will you please explain the process? The platform you are using?

I used my main PC with Windows 7.
Option 1 is to use https://web.archive.org/web/20160317164928if_/https://monarc.googlecode.com/files/dev86-0.16.17.rar .
Since it is hard for some reason for people to understand how dynamic linking works, in addition x86 cygwin1.dll should be found somewhere. This allows to use version 0.16.17.
Option 2 is to build dev86 from sources: https://github.com/lkundrak/dev86 . This produces version 0.16.21.
If you encounter CPP-FATAL error: Cannot open output file error, it means that tmp directory should be created somewhere. dev86 do not like Windows platforms for some reason.

Another problem is that rombios32 build fails for me. But these errors can be avoided by using make BIOS-bochs-legacy instead of just make.

it is nowhere near the same as the BIOS-bochs-legacy file.

This is how compilers works.
Unless you use exactly the same build environment (CPU, OS, compiler), results will differ.
Having perfect match usually means developers intentionally made reproducible builds possible.
But usually developers don't worry about it.

I am tracking down a bug that I think might be in the BIOS, so I need to modify the BIOS to help find this error.

It should be possible without perfect binary match.
If not, please let me know why.

[stlintel]

Wow!
Can you upload the

MAKE = GNU Make 4.3 (DJGPP port (r1))
BCC = Dev86dos: v0.16.2

somewhere ?

I was seeking for a way to build Bochs BIOS outside Linux for very long time.
Will be happy to have the tools and instructions, if you can share !

[fysnet]

I used my main PC with Windows 7.

Will you please upload somewhere your BCC build so that I (and Stanislav) can simply download the already built binaries?
This would help a lot. Will this build run on WinXP or is it Win7 or later only?
Will you please upload your makefile so that I can see what it consist of.
Please?
(Stanislav, the make file is from the DJGPP package at https://www.delorie.com/djgpp/zip-picker.html. I use that package for the gcc as well.)

it is nowhere near the same as the BIOS-bochs-legacy file.

This is how compilers works...It should be possible without perfect binary match.

Of course. When I say it nowhere near matches, i mean it didn't work. The resulting binary doesn't boot at all.
I can see if it was somewhat different, but it is so different that it didn't create a valid binary.
This is why I am asking for your makefile and the BCC binaries. I believe I don't have a valid build setup.

Thanks,
Ben

[Vort]

1. I use clang for compilation. The same version as I'm using for bochs.exe build. Do not know if it is important.
2. I just put dev86 binaries next to bios and add them to PATH: export PATH=$PATH:/e/_Projects/_Test/Bochs/bochs/bios/dev86_0.16.17_x86.
3. I replaced "$Revision$ $Date$" with "$Revision: 14314 $ $Date: 2021-07-14 18:10:19 +0200 (Wed, 14 Jul 2021) $" in rombios.c. Do not know if it is important.
4. I'm attaching bios_tools.zip. Not sure if it will be enough.

[Vort]

Will this build run on WinXP or is it Win7 or later only?

dev86_0.16.21_x64 most likely will not. I can try making WinXP compatible build, but first of all I need to understand why it is needed - do you use WinXP as your main operating system?
dev86_0.16.17_x86 - may work, but I did not tested.

i mean it didn't work

I did not tested produced files before.
But luckily they are fine.

[fysnet]

(Sorry for the delay. Over here in the States, we had a major holiday, and I was away from my desk)

Vort, I use WinXP to (try to) build the BIOS, because DJGPP is 32-bit only, requiring a DPMI. It does not run on 64-bit machines.
(If you didn't know, DJGPP is the DOS (Windows) port of the GNU GCC compiler.)
My main machine is a 64-bit Win10 machine, and does not run DJGPP.

Okay, so here is what I have found out so far.

When using the MAKE from DJGPP, it does not display the errors that as86 produces. As far as the display is concerned, it passed all checks. However, if you run each line separately, you will find that as86 does indeed return a few errors on the _rombiosl_.s file. Therefore, any commands after (-perl..., mv tmp.bin..., ./biossums..., etc.), though get executed, don't produce a valid rombios file.

The problem is that the write_dword() function, along with a few others, use a parameter named data.

When BCC creates the assembly file from:

void _write_dword(data, offset, seg)
  Bit32u data;
  Bit16u offset;
  Bit16u seg;
{

it creates the following lines:

export __write_dword
__write_dword:
__write_dword.seg set 8
__write_dword.data set 2
__write_dword.offset set 6

However, the next command in makefile is the sed line which is used to remove all .data and .text declarations. It just so happens, that it removes the .data part of the __write_dword declaration above, now producing:

export __write_dword
__write_dword:
__write_dword.seg set 8
__write_dword set 2        ! <------ this line is now in error
__write_dword.offset set 6

I am guessing that this problem is inherent to all platforms, not just Windows/DOS.
(The functions that are plagued with this error are: _write_byte, _write_word, _write_dword, _write_byte_SS, and _write_word_SS)

By changing the parameter name from data to _data, this fixed the error(s) and as86 runs with no more errors.

With this fix, I can now produce a valid BIOS-bochs-legacy bios file which seems to work just fine.

Stanislav, for your information, I used the following batch file on Windows XP, MAKE and DJGPP from the link I provided before, BCC version 0.16.10a, I don't remember where I got sed, and perl is Strawberry Perl:

gcc -m32 -march=i386 -fno-stack-protector -DLEGACY -E -P rombios.c > _rombl_.c
bcc -o rombiosl.s -C-c -D__i86__ -0 -S _rombl_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s > _rombl_.s
as86 _rombl_.s -b legacy.bin -u- -w- -g -0 -j -O -l rombiosl.txt
perl makesym.perl < rombiosl.txt > rombiosl.sym
biossums legacy.bin
del _rombl_.s

Notice that I had to rename some of the files to use valid 8.3 file names so that BCC would recognize them. This is BCC version 0.16.10a.

Also note that if I run this version of BCC via the MAKE file, it freezes, never ending the compilation. If I run it via this batch file, it works as expected.

It also does not update the bios version using the BUILDDATE macro. Something I will add (wasn't important at the time). Also, see the note that Vort made about manually updating the date.

I can create the legacy bios just fine using a WindowsXP machine, the MAKE and GCC from DJGPP. However, DJGPP does not produce elf files, which the BIOS-bochs-latest requires. So, I cannot use WindowsXP and DJGPP to produce the latest BIOS.

Vort, for your information, your BCC files you linked to do not run on WinXP, however, the x64 versions do run on Win10 just fine.
The problem is, I don't have a version of GCC that runs on my Win10 machine.

I believe if I wanted to take the time, I could get cl from VS2019 to be used instead of GCC. cl successfully created the processed file for the legacy bios[1]. I might be able to get it to create the latest bios.

One other thing I have noticed, when the Legacy BIOS is used (not just the one I can now produce, but the BIOS-Bochs-Legacy found on the github), if I use the cirrus vga bios, Bochs exits shortly after boot with a:

07910169898p[UNMAP ] >>PANIC<< Shutdown port: shutdown requested

This happens in FreeDOS and Windows 98, and possibly others. I have not tried...Yep, others as well.

Hope this helps.
Ben

[1] Added footnote: (30 Nov 2023)
cl successfully parsed the rombios.c file, as far as the C standard is concerned. However, it creates a few differences that bcc does not handle correctly. Furthermore, as86 flat out denies assembling because of this. One example is:
In rombios.c:

; b0: 1=Dual bus (MicroChannel + ISA)
db (0 << 7) | \
   (1 << 6) | \
   (1 << 5) | \
   (BX_CALL_INT15_4F << 4) | \
   (0 << 3) | \
   (BX_USE_EBDA << 2) | \
   (0 << 1) | \
   (0 << 0)

cl produces: _rombiosl_.c

; b0: 1=Dual bus (MicroChannel + ISA)
db (0 << 7) | \
   (1 << 6) | \
   (1 << 5) | \
   (1 << 4) | \
   (0 << 3) | \
   (1 << 2) | \
   (0 << 1) | \
   (0 << 0)

Which is valid C source (in the sense of this example). However, bcc produces the same output, and then as86 expects it to be:

; b0: 1=Dual bus (MicroChannel + ISA)
db (0 << 7)  | (1 << 6) | (1 << 5) | (1 << 4) | (0 << 3) | (1 << 2) | (0 << 1) | (0 << 0)

when it is not. It is actually:

; b0: 1=Dual bus (MicroChannel + ISA)
db (0 << 7) | 
   (1 << 6) |
   (1 << 5) |
   (1 << 4) |
   (0 << 3) |
   (1 << 2) |
   (0 << 1) |
   (0 << 0)

Which as86 does not assemble.

gcc produces the following line:

; b0: 1=Dual bus (MicroChannel + ISA)
db (0 << 7)  | (1 << 6) | (1 << 5) | (1 << 4) | (0 << 3) | (1 << 2) | (0 << 1) | (0 << 0)

where cl does not, but bcc and more importantly as86 needs it to be.

Therefore, cl cannot be used (without modifying rombios.c to cater to cl). Darn. I was hoping.

[Vort]

However, the next command in makefile is the sed line which is used to remove all .data and .text declarations. It just so happens, that it removes the .data part of the __write_dword declaration above, now producing:

Sed line looks like this:
sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s > _rombiosl_.s
^ there means that only .text and .data located at the start of the line should match.

The problem is, I don't have a version of GCC that runs on my Win10 machine.

Installing GCC with the help of MSYS2 should be easy enough.

However, DJGPP does not produce elf files, which the BIOS-bochs-latest requires.

I don't know how exactly your problem looks like, but I see this, may be related:

ld -o rombios32.out -T ./rombios32.ld rombios32start.o rombios32.o
D:\msys64\mingw32\bin\ld.exe: cannot perform PE operations on non PE output file 'rombios32.out'
make: *** [Makefile:100: rombios32.out] Error 1

[fysnet]

Sed line looks like this: sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s > _rombiosl_.s ^ there means that only .text and .data located at the start of the line should match.

Unfortunately, the version I have (GNU sed version 3.02.80) does not follow that assumption. If this is the case, looks like I need to find a newer version.

[Vort]

Problem is with shell, not with sed.
If I launch sed from cmd.exe, then the same thing as for you happens for me.
^ is escape character in cmd.exe.
You can use ^^ instead and sed will work fine.
But it is better just to use proper shell, like bash from MSYS2 (c:\msys64\mingw32.exe).

[fysnet]

^ is escape character in cmd.exe. You can use ^^ instead and sed will work fine.

ya, duh! Why didn't I remember that. My mind isn't what it use to be.

I think I have found the bug I was looking for, I just now need to figure out how to fix it. Thanks for your help.

[fysnet]

After a bit of investigation, I found that it was not a bug in the BIOS, but an error with the previous floppy disk emulation. Now that the new floppy disk emulation is working, the bug is gone. I found this out by unintentionally modifying the BIOS to trick Win98 into re-detecting the FDC controller, and it then worked as expected.

In a previous discussion Volker stated that in Win98, the second floppy drive did not have the B: declaration. I even confirmed this at the time.

After a little investigation, Win98 still thought the FDC driver (the Floppy Controller driver, not the Disk Driver) was the old controller. If you remove the FDC driver using the 'Device Manager', and then restart the emulation allowing Win98 to detect the new FDC controller, the second floppy disk is now assigned the b: declaration.

Volker, start up your Win98 emulation, then via the 'Device Manage', remove the FDC controller entry. This will remove the FDD entries as well. Then restart Win98. The floppy drives now should be a: and b: respectively. Can you confirm this? Here is a screen shot of mine.

[fysnet]

As a follow-up, Vort mentioned in the other discussion that installing Win98 on a clean hard drive still has the b: drive as e: (or d: in that case). After some investigation, I mentioned that I believe that it is a combination of an error in the BIOS and the way Win98 SETUP detects the floppy drive.

I was going to be done with it, but just couldn't put it down :-) I grabbed SEABIOS and using it, installed Win98 on a clean hard drive. Win98 successfully placed the b: drive as b:.

Unfortunately, this just confirms that there is an error in the current Bochs BIOS. Maybe if I get a chance, I will have a look.

[Vort]

However, DJGPP does not produce elf files, which the BIOS-bochs-latest requires

I was seeking for a way to build Bochs BIOS outside Linux for very long time.
Will be happy to have the tools and instructions, if you can share !

@fysnet, @stlintel: I suggest you to try https://github.com/lordmilko/i686-elf-tools
I tested i686-elf-tools-windows.zip from https://github.com/lordmilko/i686-elf-tools/releases (GCC 13.2.0) in conjunction with MSYS2 and dev86 binaries I shared earlier.
Results are promising: BIOS-bochs-latest was created without problems.
I do not know how to properly test BIOS binary, but looks like it is fine.

To use i686-elf-tools, I unpacked them into d:\i686-elf-tools directory and modified bochs\bios\Makefile like this:

GCC32 = /d/i686-elf-tools/bin/i686-elf-gcc.exe -m32 -march=i386 -fno-stack-protector
LD32 = /d/i686-elf-tools/bin/i686-elf-ld.exe
OBJCOPY32 = /d/i686-elf-tools/bin/i686-elf-objcopy.exe