atcfwchg... & more

[SV]

I would like to run this utility on my development machine... but all docs
and threads Ive seen indicate I have to do all my CF priming on the target
device. Why is it impossible(?) to run the utility on my SanDisk CF 256MB,
as well as fdisk, format, and bootprep.. on my dev machine and not on the
target, if all I'm doing is modifying the CF disk format and boot sector
information? Why do atcfwchg and fdisk need to be on the target device to
work properly?
Thanks
SV

 

[KM]

SV,

Nothing impossible and not much prevents you from running the tools on your dev machine.
However, consider these:
- bootprep has to be run from DOS. The same seems to apply to atcfwchg (I don't know exactly but as far as I heard).
- working from DOS, on your dev machine you have to get BIOS support for CF card (either IDE to CF adapter or some else way)
- better for your dev machine to have the same BIOS support as on the target (otherwise may or may not appear some issues on the
target)

Btw, why do you need to do the CF priming on your dev machine? Why not on target? Not much effort it will take if you do that on
target - you will likely have to do through the preparation only once.

 

[SV]

Painful explanation. Someone went on vacation and I don't have all the
equipment I need is the short answer... I'm getting ready to make another
trip to the store. The only thing I do have is this CF, which the target
BIOS sees on Secondary IDE, Master. I wonder if I could set up the CF like a
boot floppy and run the atcfwchg on itself...
I've actually already tried to run the utility from the command shell on my
laptop, with the CF plugged into a PCMCIA slot. But it's not really
secondary drive so its not working with /s. I don't see how it could work.
Tried to just boot laptop to boot floppy but the PCMCIA slot is still not
secondary. I suppose thats obvious but I'm not hardware savvy. You probably
couldn't boot to the PCMCIA slot any more than you could the PS/2 port, huh?
I think you answered my questions, though: BIOS support, and the CF/IDE
adapter on dev machine. I do remember reading about some of those issues
that could come up. Thanks so much.

SV,

Nothing impossible and not much prevents you from running the tools on your dev machine.
However, consider these:
- bootprep has to be run from DOS. The same seems to apply to atcfwchg

(I don't know exactly but as far as I heard).

- working from DOS, on your dev machine you have to get BIOS support

for CF card (either IDE to CF adapter or some else way)

- better for your dev machine to have the same BIOS support as on the

target (otherwise may or may not appear some issues on the

target)

Btw, why do you need to do the CF priming on your dev machine? Why not on

target? Not much effort it will take if you do that on

 

[KM]

SV,

Take a look at the links and maybe will you catch some help from CF-->IDE adapters:
http://www.pi-si.com/eDapter.html
http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm

(don't think you can use it with your laptop, though)

 

[Slobodan Brcin \(eMVP\)]

Hi SV,

Why do atcfwchg and fdisk need to be on the target device to work

properly?

Because MS - MBR loader will work with L-CHS values only instead of LBA
values.
Also FAT BPB fields like SecPerTrack and NumHeads must reflect target device
BIOS L-CHS values.

NTFS does not have this limitation since it ignores fields SecPerTrack and
NumHeads and instead it uses LBA values.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[SV]

So, the MBR's fixed disk drive assignment is written on the CF in L-CHS
addressing form... which is specific to the actual device and... should
agree with the BIOS's understanding of where everything is (is in the same
terms, L-CHS)? But if I could format this CF in NTFS (which it seems I
can't, at least not through MS's Windows GUI), then the BIOS has
understanding of LBA values also... That is, BIOS (at least "Enhanced"
version?) uses both L-CHS and LBA addresses....
And the MBR loader on NTFS formatted media uses LBA values...

I guess I'm just clarifying my understanding, but I can definitely work with
the info you've provided. Thank you SO MUCH. You guys are so great.

 

[SV]

I don't have a way that I can see of making my current CF slot on my target
board Primary. BIOS has it assigned as Secondary and other IDE slot/port as
Primary (for HDD). This thing looks as if I could plug it in to Primary
slot. Which would be really helpful.

Thank YOU a BAZILLION. I've learned so much in past couple days....

Shawna

 

[Slobodan Brcin \(eMVP\)]

....

And the MBR loader on NTFS formatted media uses LBA values...

Not exactly.

MBR is file system independent it is first sector on CF. It uses L-CHS
values only.
BPB is located in first sector of each partition, and it is used by loader
located on FAT.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

Slobodan,

NTFS does not have this limitation since it ignores fields SecPerTrack and
NumHeads and instead it uses LBA values.

Are you sure about this?
From what I've seen, the NTFS boot sector (first 512 bytes, not IPL) does test for LBA mode (INT 13, AH=41h) and uses it if
supported. If not supported, it reads first 16 sectors of the NTFS partition in CHS mode. BPB, of course, used too. And
"SecPerTrack" BPB field is used in CHS mode which are useless in LBA mode.

Konstantin

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

Are you sure about this?
From what I've seen, the NTFS boot sector (first 512 bytes, not IPL) does

test for LBA mode (INT 13, AH=41h) and uses it if

supported. If not supported, it reads first 16 sectors of the NTFS

partition in CHS mode. BPB, of course, used too. And

"SecPerTrack" BPB field is used in CHS mode which are useless in LBA mode.

You are probably right about that, but I haven't noticed this because my
boards use LBA mode. But FAT boot sector certainly needs CHS. NTFS in all my
cases worked.

OTOH I never wanted to disassemble NTFS Boot sector since it is documented
and for these BPB values it says "Not used or checked by NTFS".
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us
/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkd_t
ro_ilxl.asp

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

Hi Slobodan,

OTOH I never wanted to disassemble NTFS Boot sector since it is documented
and for these BPB values it says "Not used or checked by NTFS".
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us
/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkd_t
ro_ilxl.asp

Thanks for the link. I saved it in my favorites

Actually NTFS boot sector is too popular area to disassemble it now. It has been disassembled millions times, I think.
Here is a good link you can take a look at: http://bootmaster.filerecovery.biz/appnote3.html
If you look at the asm code there, you will see the CHS section and LBA test code.

Konstantin

 

[Slobodan Brcin \(eMVP\)]

Hello Konstantin,

Thanks for this link I read though code and it certainly confirms your
claim. Although MS doc then is incorrect. Nevertheless I always set these
values (better safe than sorry logic) since MS say that they ignore them, I
thought that I should set them instead of letting them undefined.

Regards,
Slobodan

PS:
This again confirms that we should not blindedly follow MS doc

Hi Slobodan,


Thanks for the link. I saved it in my favorites

Actually NTFS boot sector is too popular area to disassemble it now. It

has been disassembled millions times, I think.