search for: isohdpfc

...One may guess that i will propose to patch the ISO at byte 8444*512+70, if i get a "yes" on this question.) --------------------------------------------------------------------- If this is indeed the wrong sequence in isolinux.bin then the riddle arises why the second try of David with isohdpfc.bin succeeded. And why do our virtual BIOSes work ? Don't they get the fake EBIOS flag ? Can it be that isolinux.bin unconditionally first tries "getlinsec_ebios" before it defaults to "getlinsec_cbios" which is a consumer of "bsSecPerTrack" and "bsHeads&quot...

Hi, Geert Stappers wrote: > Contact David off-list, he did unsubscribe. Can you tell when he unsubscribed (i.e. which of the messages he got as last one) ? > Martin posted elsewhere in this thread "Thomas, you found the bug" > and provided a patch. Open question is whether the fix helps with David's BIOS. The newest answer from Martin indicates that a failure to read

Hi, i now believe to see a difference between isohdpfd.S and isohdpfc.S which explains why isohdpfc.bin works with isolinux.bin on our virtual BIOSes: isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41. Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk Drive" could be set. https://en.wikipedia.org/wiki/INT_13H I u...

On Fri, Mar 24, 2017 at 05:38:31PM +0100, Thomas Schmitt via Syslinux wrote: > isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41. > Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk Drive" > could be set. > https://en.wikipedia.org/wiki/INT_13H > > I understand on David's BIOS after > > andw $1,...

...rmation, > with "Key?" at the bottom (see attached picture IMG_1578-r.JPG). > > > When I press a key, I see the following message at the bottom and the > computer stops: > > ISOLINUX 6.03 20150819 CHDDisolinux: Image checksum error, sorry... > > > Trying isohdpfc.bin: ... > Boot it in D865GBFLK Pentium 4 3.4E GHz -- I see a screenful of information, > with "Key?" at the bottom. Is it exactly the same numbers as in the picture you attached for the isohdpfd.bin boot? > When I press a key, the following message flashes by at the bottom: &g...

Hi, C/H/S addressing and reading of first block seems to be ok in isohdpfd.bin. The main suspect for the failure of the attempt with isohdpfd.bin is the number or content of the blocks read after the first one. But i have no clue why isohdpfc.bin should do better than isohdpfd.bin. They differ just by one instruction (JC = 0x72 versus JMP = 0xEB) which both are performed before the reading and should actually be equivalent on David's BIOS. MartinS wrote: > Looking at the code I see there might be a difference in CX _if_ the &gt...

On Fri, Mar 24, 2017 at 2:55 PM, Martin Str|mberg via Syslinux <syslinux at zytor.com> wrote: > On Fri, Mar 24, 2017 at 05:38:31PM +0100, Thomas Schmitt via Syslinux wrote: >> isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41. >> Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk Drive" >> could be set. >> https://en.wikipedia.org/wiki/INT_13H >> >> I understand on David's BIOS after >> &g...

...%cx, %cx /* Clear EBIOS flag. */ which Martin mentioned as "can be ignored" in the the text which i quoted before my statement. Additionally to the wrong stack sequence, which prevented booting on David's BIOS, we stumbled over the problem that the experimental MBR "isohdpfc" wrongly told isolinux.bin to use LBA addressing, although the MBR code had decided to use C/H/S addressing for itself. This misunderstanding could happen in real operation if the BIOS returns an unexpected signature in its reply to INT 13 AH 41 together with non-zero content in the CX registe...

...: > > I place my bet on CX value 4. :)) David Christensen wrote: > No carry. > 3000 > AA55 > 0004 > 0080 > I die now Hah ! CX announces no LBA addressing but Enhanced Disk Drive Support. https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present So isohdpfc pushed CX = 4 onto the stack, because it skipped andw 1,%xc So isolinux.bin read in "EHDD" mode by LBA and succeeded although it did not announce this capability. isohdpfd reached the "andw" instruction. So CX was set to (1 & 4) = 0 before it got pushed. So isolinux.bin...

Thomas wrote: > I think it still has good reason to exist. Would you please clarify what do you mean with "it"? What exactly should exist? By "it", do you mean the original code, or the patch? Do you mean that the original code (in this section of the file) should remain as it was/is, without applying the relevant part of Martin's patch? Or instead, do you mean

...fx.S?id=2f92affcce5ffef4da90fe44bcac5a4db45df25f > Finding a system that > doesn't seem to properly support LBA/EBIOS reads is increasingly > difficult due to age. It is now easier to force C/H/S for both MBR and isolinux.bin because of the "Clear EBIOS flag" code piece. A isohdpfc with "jmp" instead of "jc" after INT 13 AH 41, derived from the new code would instruct isolinux.bin to use C/H/S addressing, too. I just tested this replacement by locating the "jc" instruction by its neighbor "cmpw $0xaa55, %bx" at byte 88 and changing it...