search for: isohdpfd

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

...With that jc changed to jnc you will invert the result of the EBIOS test and my qemu always has EBIOS. Download the resulting isohdpfx here: <http://www.ludd.ltu.se/~ams/tmp/isohdpfx.force_cbios.bin> Back to Thomas' debug prints. You can download my logger version of isohdpfx called isohdpfd here: <http://www.ludd.ltu.se/~ams/tmp/isohdpfd.bin> <http://www.ludd.ltu.se/~ams/tmp/isohdpfd.S> In the EBIOS case it will print: E<LBA0>/<LBA1>/<LBA2>/<LBA3>/ <Big dump of first loaded sector> Key? and wait for a key press. In the CBIOS case it will p...

...e effective read operation seems to use H/C = 32 , S/H = 63. The correct LBA would be addressed by H/C = 63 , S/H = 32. -------------------------------------------------------------------------- Reasoning: I have transplanted the "Force CBIOS" change from isohdpfx.force_cbios.bin to isohdpfd.bin. The Intel manual tells me that JNC is 0x73 (= 's') and JC is 0x72 ('r'). Looking for the instruction operand 0xaa55 in isohdpfd.bin leads me to the value 0x72 at byte position 56. So i patched isohdpfd.bin to let it force CBIOS by cp isohdpfd.bin isohdpfd.force_cbios.bin...

CC:ing syslinux. Thanks for testing David. On Thu, Mar 23, 2017 at 05:23:51PM -0700, David Christensen wrote: > Trying isohdpfd.bin: ... > Boot it in D865GBFLK Pentium 4 3.4E GHz -- I see a screenful of information, > 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...

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 performe...

Thomas Schmitt wrote: > My main point of interest is which block is really loaded as first one > of isolinux.bin. [Program snipped.] > (It could be shorter if i did not insist in big endian words.) Why insisting? Anyway appended is a dumper version. I could put up a binery version if needed. Let me know if so. -- MartinS /*

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/wi...

CC:ing syslinux David Christensen reports that my latest isohdpfd.bin reported C, thus it failed early (carry set) in finding an EBIOS. My interpretation is that it must corrupt CX so isolinux is fooled into trying EBIOS first. So, again David, can you please try this one: <http://www.ludd.ltu.se/~ams/tmp/isodavid.tgz> To keep your (our?) spirits up I...

...anced 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 read in "CHDD" mode by C/H/S and thus ran into the stack sequence bug. Martin: > > > http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 David: > the following f...

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