Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About nnobody

  • Rank
    InsanelyMac Protégé

Profile Information

  • Gender
  • Location
  1. migle: Anyway thanks for your work, now I can boot Windows from GPT drive without USB flash drive.
  2. 1. I found what is wrong with Gpt - it saves dl to 7C00:01B6 after relocation to 0600:0000 occurs and later loads bootsector to 7C00:0000, and not even try to pass dl to bootsector. If I save dl to 0600:01B6 and restore it before jump to bootsector code all works without hardcoded bDrive. 2. I can't produce working gpt.com with gcc(compiles without erros, but binary totaly corrupted), only ntddk(with ml/link16) build works, so I can only make patch for .asm and share binary. BTW, I've checked Mbr code and algorithm there is the same, can't figure why it works from stock gpt.zip
  3. setup.1 is in #if !defined(DEBUG) - #endif clause, so DEBUG version of BootDuet don't jmp to Efildr Just recompiled BootDuet without -DDEBUG and it works great now (with hardcoded drive number) Also works with VMware SCSI and VirtualBox AHCI hard drives
  4. I think I can solve missing EFILDR by myself, just stuck on int13, but it's behind now. I'll report back later seems that problem in LFN or something like that I use diskpart from WinPE3.0 for partitioning and formatting
  5. 1. I can't find calculation of root directory sector, but at 0x2800 is directory entry, first 32 byte is LFN entry and after it 32 byte FAT entry of EFILDR20 (the only file on filesystem, there is no dirs except of root) 2. Does BootDuet read first FAT sector? It seems that first sector read by MBR record that places it to 0x7c00, from this addres BootDuet gets FAT parametrs, isn't it? 3. answers for inteligent questions: a. According to _ttp://www.delorie.com/djgpp/doc/rbinter/id/14/7.html, 0x01 in AH means invalid function or its parameters b. Yes, it's SCSI hard drive (tried to change type to IDE with no luck). In VirtualBox(on windows host) it's all the same, no matter of controller type c,d. I tried to movb bDrive,%al and call printn, just before int13, output is 0. movb %dl,%al in main, after movb %dl,main_bDrive(%bp), output is 0. seems Gpt.com do not not pass disk index, as it done by Mbr.com I hardcoded $0x80(passed by Mbr.com on same machine) in main instead of %dl and int13 work ok, but I get Missing EFILDR20. I need further investigation...
  6. migle: I installed BootDuet/bd32.bin in EFI partition's FAT32 bootsector, in MBR - Gpt.com from Tianocore/Duet. Gpt executes BootDuet, but BootDuet halts after int13 in first call of read function (called from fread, which is called from readroot). Return code from int13 is 0x01 (in AH). Arguments to read function - ecx: 0x02, eax: 0x2800 (points to LFN entry of Efildr20), edi: 0x8000. On MBR partitioned drive with Mbr.com from Duet and FAT32 primary partition BootDuet starts efildr20 as expected. i.e. the same behaviour as bs32.bin from Duet (which prints BError! on GPT drive and halts). I tried all of it on WMware virtual machine. May be the problem with Gpt.com, and not with bootsector code? I can produce more specific debug output if needed.