This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
blog:pushbx:2022:1107_ldos_boot_loader_review [2022-11-07 21:38:03 +0100 Nov Mon] ecm created |
blog:pushbx:2022:1107_ldos_boot_loader_review [2022-11-13 15:21:17 +0100 Nov Sun] (current) ecm [read_sector hardening, optimisations] code format register names |
||
---|---|---|---|
Line 38: | Line 38: | ||
===== read_sector hardening, optimisations ===== | ===== read_sector hardening, optimisations ===== | ||
- | In any case, today I noticed that the ever-crucial read_sector function of ldosboot and also lDebug could be optimised a bit. The savings were 3 bytes in the FAT12 and FAT16 and FAT32 loaders and 5 bytes in the initial loader. What actually made me stumble on this was a vaguely recalled comment that there are ROM-BIOS implementations of the LBA extensions that require es to be set to the buffer segment, even though for the extensions the buffer address is supposed to be passed in the disk access packet. | + | In any case, today I noticed that the ever-crucial read_sector function of ldosboot and also lDebug could be optimised a bit. The savings were 3 bytes in the FAT12 and FAT16 and FAT32 loaders and 5 bytes in the initial loader. What actually made me stumble on this was a vaguely recalled comment that there are ROM-BIOS implementations of the LBA extensions that require |
- | Cue my surprise at finding that setting es unconditionally, | + | Cue my surprise at finding that setting |
During adaptation of this patch to the initial loader and the test status writer kernel we had to carefully consider the different paths. In addition to the plain LBA read and CHS read, both of them also have a " | During adaptation of this patch to the initial loader and the test status writer kernel we had to carefully consider the different paths. In addition to the plain LBA read and CHS read, both of them also have a " | ||
Line 49: | Line 49: | ||
==== The lDebug bug ==== | ==== The lDebug bug ==== | ||
- | During testing lDDebug within qemu, tracing the sectorseg read/write LBA/CHS cases, it happened to be the case that sectorseg reading loaded a random value into cx to copy the data from the sector segment to the target. The desired value would have been 200h, or 512. This happened because lDebug' | + | During testing lDDebug within qemu, tracing the sectorseg read/write LBA/CHS cases, it happened to be the case that sectorseg reading loaded a random value into '' |