1. Use proper identification to what chips use what.
2. Apply some mode switch fixes to the ATI 8514/A Ultra and make 1024x768 87Hz interlaced the default mode if htotal is 0 and on ati8514_init.
3. Add the undocumented ports to the ATI 8514/A Ultra add-on as well.
SVGA related:
If CRTC1/HDISP is odd (if bit 0 is set), then make it even accordingly, else leave it as is. Should fix some display skews.
S3 related:
Remove old code references (can still be accessed through history if one needs it).
8514/A compatible related:
Proper use of the htotal and hdisp timings.
1. Implemented the FIFO test data to pass some tests of the Mach8 POST ROM and tests (not complete yet).
2. Overhauled the mode switches again, but this time with way less hacks and more on manual instructions.
3. Use a function pointer to determine if the Mach8 type used is a VGA combo or add-on.
4. Mach32 mode tests are no longer incorrectly green (was caused by improper pixtrans parts).
5. Implemented overscan color to the Mach32 as well as the CRT offset.
6. And fixed a PCI LFB GPF issue with the Mach32 2.3 drivers on Win3.1x.
7. Implemented memory boundary for both the Mach32 SVGA and its accelerator.
8. Added undocumented ports used by the FIFO (such as ports 0x8AEE and 0xEAEE).
9. Plus resetting the device right a la s3.
10. Temporarily switched the bus type of the Mach8 to 8-bit in both MCA and ISA variants.
1. Avoid audio stops when they don't need to be.
2. And improved the MMIO-based NCR 53c400 timings to be similar to the port I/O-based one (T130B).
3. Minor timing fixes to the T128/PAS as well (especially for the hdd, when entering Windows 1.x using a SCSI HDD).
For whatever fucking reason, glibc's functions dealing with decimal numbers apparently can only accept either commas or dots in strings, but not both. Meanwhile, both Windows and macOS have no apparent issues accepting both.
I will never understand why they decided to even consider such behaviour acceptable, especially since those ARE used for parsing decimal numbers in many programs, but I guess it's their own version of Not Invented Here syndrome that they (or anyone else) can't be bothered to deal with. This is not how good C standard libraries are written, at all.
