search for: int_13h

Hi, i am looking now at the code which i assume loads the rest of isolinux.bin. The entry point for program execution from the MBR is obviously at http://git.zytor.com/syslinux/syslinux.git/tree/core/isolinux.asm#n186 (Do i get it right that this is the Intel syntax ? (Gronfff)) If POP yields the victim of the most recent not yet popped PUSH, then this does not look correctly coordinated

...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 understand on David's BIOS after andw $1,%cx /* Bit 0 = fixed disk subset */ jz 1f jz jumps because CX is 0. This gets pushed to the stack. (So the code around the int 13 assumes that either int 13 fails and returns CX == 0, or the reply is good enough to...

Sounds like we should change the "and cx" mask to 5 so that if either EHDD support or LBA is announced by the bios, the correct EHDD path will be taken. Phil P. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com Changing the world through technical innovation

...gt; > > * DX > > > * I die now. i wrote: > > 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...

...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,%cx /* Bit 0 = fixed disk subset */ > jz 1f > > jz jumps because CX is 0. This gets pushed to the stack. > (So the code around the int 13 assumes that either int 13 fails and returns &...

...quot; before the "nop"s gets removed then the second one after the "nop"s needs to be removed, too. One could hardcode the block address of "isolinux.bin" (8444 decimal) and inspect or print the bytes read from there via BIOS INT 13H (see https://en.wikipedia.org/wiki/INT_13H). Next one would try on Linux to find the block iaddress which yields that content. Further one could try to find out whether "we have EBIOS" with LBA addressing or "CBIOS" with Cylinder/Head/Sector addressing. If CBIOS, INT 13 with AH 6 is used for reading, else AH 42. If C/H/...

...17 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,%cx /* Bit 0 = fixed disk subset */ >> jz 1f >> >> jz jumps because CX is 0. This gets pushed to the stack. >> (So the code around the int 13 assumes that eith...

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

On 03/18/2017 01:18 AM, Ady Ady via Syslinux wrote: > Some of the things you should / could (re)test / (re)try: > > _ Verify the md5sum of the ISO image. SHA256 verified for downloaded image and for contents of USB flash drive (see below). > _ Is this particular USB device _still_ capable of booting newer > computers? Yes. > What happens if you would try _again_ to boot a

...op"s gets removed then the > second one after the "nop"s needs to be removed, too. > > One could hardcode the block address of "isolinux.bin" (8444 decimal) > and inspect or print the bytes read from there via BIOS INT 13H > (see https://en.wikipedia.org/wiki/INT_13H). > Next one would try on Linux to find the block iaddress which yields that > content. > > Further one could try to find out whether "we have EBIOS" with LBA > addressing or "CBIOS" with Cylinder/Head/Sector addressing. > If CBIOS, INT 13 with AH 6 is used for...