- Why did you put NO message at all in the boot sector, not even a single letter in case of error? And why use Q / W to move the cursor instead of more intuitive arrow keys?

I wanted to do all the real mode, BIOS-related work in the 512 byte boot sector, so that I can enter protected mode right after executing it and forget about BIOS (except for its protected mode interfaces and some optional, rare call in virtual 8086 mode). To reach this goal I squeezed the code needed to: get information from BIOS, get VESA modes, let the user select one, read the rest from disk and enter protected mode enabling A20 line. Don't expect informational/error messages or user friendly features in the bootsector code: every choice, like using Q / W keys, aims at reducing code size.

- I tried to read boot sector code but it is very cryptic: what the hell of a coding style is this?

See above question: I'm just sparing space. Sometimes the source is hard to read, even though widely commented, because of some "dirty" tricks to reduce the size (one was taken from VIC 20 world!). To understand BIOS calls you surely need Ralph Brown's Interrupt List; by the way, note that in the 1589h call info, BL and BH (IRQ vectors) are erroneously swapped.

- I get a headache even with main program messages: no explanation, a lot of acronyms, strange numbers ... Which is the reason here?

I chose to always keep the MCGA mode option, in case of problems with VESA: this limits the space for printing information data, because I have a 320 x 200 bitmap and I can't choose a font too small which couldn't be read in high resolution modes. So here too you won't find detailed and clear, complete messages.
I'm not sure I will keep MCGA because some cards don't support it, moreover I see that VESA always works.
Numbers are all hexadecimal (also the RAM size in MB, for example) because I wanted to reduce non-hardware code like print formatting (see ReadMe.txt).

- Why did you compress all the data in the upper left corner of the screen while leaving a lot of space unused? I must use a magnifier to read it! 

The data shown on the screen is formatted to fit an MCGA (320 x 200) area, so in other modes you will see the printing on your screen's upper-left corner. It overwrites the picture, when present, which is always in the upper-left corner too, even when there is room in the bottom right.
In high resolutions you get very small charachters and a lot of wasted space: it was simpler to code one resolution only and I reduced non-hardware code. Remember that this software is not meant to be useful, easy to use or nice-looking when running.

- While running the program, it's not clear to me its flow and how to test specific features. Did you really need to make it so uncomfortable?

In general, user friendly features require adding code and complexity which do not help learning hardware control: you end up with tons of pages full of code you're not interested in and you have to search for the lines that really control the machine. In fact, the only (extensively used) user-friendly feature which makes sense in a software like this, is comments on the source code. My code is not optimized neither for size, nor for speed: most of the times I choose to minimize the source, and I use general optimization tricks like xor eax, eax instead of mov eax, 0.
You'd better run this program with the README.TXT file in front of you, which should guide you.

- Can I run this software on a PC emulator like QEMU or Bochs?

I gave a quick try on Bochs 2.4.1 for Windows, setting only disks parameters. The only problem I saw was APM shutdown not working. When using a floppy image I had to take those generated by makecd.bat since they must be the correct length (of course I had to tell Bochs they were 1.2 MB images). When using hard disk image, I had to set Sectors per track and Heads to 1, and Cylinders to the number of 512 blocks the image was made of.
Actually I don't see the point of running a useless, demo-only software like this inside an emulator, unless you want to debug it: you may stumble on an emulator bug or unimplemented feature and search for something wrong in HwTest - that's why I didn't care for APM not working -. For example, with this version of Bochs I saw that microcode MSR are not implemented (not a problem at all), and INT 15/89 call was added only recently (its lack is a big problem with HwTest).

- Can the software use bank switching graphic modes?

Yes. When probing VESA modes, I ask for Linear Frame Buffer (LFB); if not available, I enable paging on the processor to emulate it, in a way similar to LFBEMU by A. Frounze. Even though video cards without LFB are long gone, someone may find interesting the way it is done, especially the calls to the bank switching function: you can try emulation even when you have LFB available (delete "or bh, 0xC0" in BootVesa.inc).

- Initial stages - especially the bootloader - store system data in a way not clear to me. How can I understand how to use such data?

Info.asm in general contains some examples of reading the data gathered by previous stages (in particular the bootloader).

- What is PS/2 emulation?

It is an OHCI feature which creates virtual PS/2 ports (60h / 64h) in machines without PS/2, when it finds an USB mouse/keyboard attached at boot. This is accomplished by using an SMM driver, which can interfere with USB test, so I created a switch to decide whether to keep this emulation or not.
I chose to set PS2_EMULATION switch to 0 (= try to get rid of emulation) by default since it seems that some BIOS SMM drivers manage other devices besides mouse: I found a machine where a printer enabled SMM driver, thus making USB test fail. If you don't have a PS/2 mouse but just an USB one, you might want to switch PS2_EMULATION to 1, so my program will be able to use it. It doesn't affect EHCI because EHCI can't handle mice/keyboards which are low speed devices (the only ones to keep a BIOS driver for). As to UHCI, it has no standard mechanism to get controller ownership, so I simply disable all SMI, but maybe this brute-force method could cause problems.

- ReadMe.txt says I can ping the machine running HwTest. Is it always available?

Ping is enabled after your network card is recognized and initialized. It works even when the processor enters an infinite loop (I saw the case of a page fault/instruction restart loop). Ping generally works if you correctly set up MAC and IP addresses.

- Why does HwTest supports so few network/audio cards?

Because it doesn't make sense to write a driver for every card in a useless program. This is just an example so that YOU write your drivers for you system, I only demonstrate for the most common and wide-spread hardware.

- Can I change graphics for screen, mouse and font, and the sound?

Yes, put your own files in Data directory. Sound is an 8 bit / 11025 Hz mono PCM file; graphics are upside-down .BMP images with no compression. More precisely:
- screen (Screen.bmp): 8 bits per pixel
- mouse (Mouse.bmp, only for Trident cards): 8 bits per pixel; size of 64 x 64 ; colors = those with index 0, 1, 3, 8 in the palette
- font (Xterm.bmp): 1 bit per pixel; width <= 24