Page 2 of 2

Posted: Fri Jul 16, 2004 4:18 am
by gavin53
Hi

Well have tried all your suggestions but feel the problem is the floppy or more the controller.
As it just refuses to boot from the disk.......
With the command lines etc in autoexec.bat file, the bootdisk firstly I gather would need to BOOT to A:\> prompt ??????? then proceed to auto flash the BIOS???????

I feel something is seriously screwed up and I hadn't flashed the BIOS to get it in this state so I gather a hardware problem has caused this or probably the M/B itself.... as I have replaced CPU, RAM Floppy and Floppy cables....... another thought is maybe the PSU????

Unfortunately i dont have a volt metre to carry out a test ...

I also noticed this unit has sometime in past had a new PSU fitted around 2003 printed on it also with Pentium 4 ATX 300

Anyway I may just purchase NEW BIOS already programmed and go from there.... may save a lot of headaches I guess .lol

Thanks so much for your help thus far.. very much appreciated

Gavin

Posted: Fri Jul 16, 2004 4:52 am
by Ritchie
I cannot remember for sure how I did this, but recently I did get the command prompt coming up on every floppy disk boot for a bootblock BIOS.

I would have to double check the disk I made, but I think I did this by copying COMMAND.COM to AWDFLASH.EXE.

I don't think the bootblock BIOS cares what program is running within AWDFLASH.EXE - It only wants a program called AWDFLASH.EXE or ""wants to be tricked by renaming another program to AWDFLASH.EXE!!!"" (or to put it seriously CAN be tricked by; not WANTS TO).

Posted: Fri Jul 16, 2004 3:33 pm
by gavin53
Hi

Have read richies post but somewhat confused ........

"I would have to double check the disk I made, but I think I did this by copying COMMAND.COM to AWDFLASH.EXE. " ?????????

Do I take it that say dragging command.com to the AWDFLASH.exe file ????


Gavin

Posted: Fri Jul 16, 2004 6:33 pm
by ruelnov
AFAIK, it's only AMI BIOS that searches for the flash utility in the floppy on BootBlock recovery.

I have also completely disassembled my BootBlock (Award BIOS) and Decompression Block, and there isn't any reference or instructions to search for the award flash utility in the floppy while trying to recover from BootBlock.

Rather, it's the boot strap loader that's being initiated after finding that the floppy drive is working, as well as the floppy controller which resides in the board.

Posted: Fri Jul 16, 2004 7:58 pm
by Rainbow
Older Award BootBlocks simply boot from the floppy. Newer ones are trying to execute awdflash.exe, which often fails and booting must be done using fake awdflash.exe (awdblock).

Posted: Sun Jul 18, 2004 10:50 am
by Ritchie
Sorry for the confusion.

I am trying to say that I cannot remember for sure how I created a bootblock bootdisk that allowed me to boot to a command prompt (every time).

However, if I do remember correctly, the way I did do this was to produce a copy of the COMMAND.COM file, and name the copy AWDFLASH.EXE.

However, this is only necessary if you want to boot to a command prompt every time you boot with bootblock BIOS. If you are not interested in that, and just want to produce an automated bootdisk that does the BIOS update all by itself, you can ignore this advise.

Posted: Sun Jul 18, 2004 2:18 pm
by KachiWachi
Sounds like it is time for a hot flash...

The boot/flash floppy diskette is good.
You tried it with an ISA controller card and new floppy drive.

Not much else you can try...

Posted: Sat Sep 04, 2004 1:46 pm
by dos-freak
Ritchie: Are you sure, that copying command.com to awdflash.exe worked?
As a .com file is a one-(64k)Segment (originally CPM-Style) program, which doesn't has its own data, code and stack segments like we know from the MZ-Format EXE-files, I don't think that the boot-block would like to execute it, as it expects MZ. I remembered trying that too (although I expected that it wouldn't work), when I had my Boot-Problem, and it just caused a hangup.

Posted: Sun Sep 05, 2004 5:34 am
by Ritchie
Well what my last post said was what I remembered trying.

Personally I don't have any problems with renaming or copying .COM files to .EXE files. The way I understand it a .COM file is limited to 64KB as you say, and for larger files a .EXE file is required. But from my experience a file can be .EXE whether it is under or over 64KB and it still works just as well, meaning that for under 64KB a programmer has an option of whether to produce a .COM or .EXE executable.

Posted: Sun Sep 05, 2004 11:50 am
by dos-freak
It's not that simple..
When you rename command.com to .exe, the file format still remains .com, meaning, that there is NO .exe Header in it.
Now if the bootblock expects a MZ - header, it searches for an EIP
in the .exe file in order to know to which location it has to jump to start executing the Executable.
Check here for details on the .exe header:
http://www.corion.net/cgi-bin/wiki.cgi/ ... t:MZ%20EXE

The .com file has no real header, it is just a binary file, which is loaded
into memory and is executed straight forward.
See here:
http://www.corion.net/cgi-bin/wiki.cgi/ ... Format:COM

When you code a .com Program, you can do the following, for example:

Code segment

assume cs:code ; We compile to .com, so only 1 code-segment available
Org 100h ; start of .com is located @ 100h in the segment

start:
Jmp opcodes ; Jump to EIP skipping data chunks (as we compile to .COM)

WELCOME db "Here is data, don't execute me!"

; Here we go ---------------[EIP]----------------------------
main proc
Opcodes:
Mov dx, offset WELCOME ; Say hello to user
Mov ah,09h
Int 21h
Mov ah,4ch ; byebye...
Int 21h
main endp

;;;;;;;;;;;;;;;;;;;;;


You might have noticed the instruction:

Jmp opcodes ; Jump to EIP skipping data chunks (as we compile to .COM)

It's the first instruction executed and it's straight on the beginning of your .com file. This means, it's just loadewd into mem and executed.
Whereas an .exe file is different. It has a Signature at the beginning (MZ) and so usually you can recognize it as .exe and let it search for the EIP (at 0014h).
BEcause the boot-block BIOS has to be very small and simple, it may not check for the file format, but just jump to the address it finds at the EIP-Location in the renamed .com File. Because the .com is no real .exe, there is code at this location, but no correct address and therefore, it jumps somewhere in the memory and this may just cause a hangup.

Maybe modern Bootblock-BIOS versions check for the header and are able to determine if it's a .com or a .exe and execute it the right way.
But as they expect the awdflash.exe, there would be no need to do a header-check and better save the space for it.

Additionally, command.com relies on MS-dos, as it may also use DOS-Functions (like the multiplexer Interrupt 21h), so it's part of MS-DOS but not DOS itself (which resides in msdos.sys and io.sys). command.com is just a commandline-interpreter (showing you that A:\> prompt and telling DOS to execute what you enter) and therefore also quite useless to start any DOS-programs.

Tell me, if I am wrong, but in my opinion, renaming just CAN'T work.

Posted: Fri Sep 10, 2004 8:14 pm
by ruelnov
I second the motion.

Posted: Sun Sep 12, 2004 1:34 pm
by Ritchie
I'm sure renaming the file is what I did, and from experience it has worked, at least for me, in practise, even if not in theory.

If I come across the floppy (disk) that I used to perform this flash procedure I will post details of it. Unfornately I cannot check it as I do not have a suitable machine to test it on - however next time I am in this situation I might see if I can test my disk and procedure and post results.

Anyway, if you figure you have nothing to lose, you could always try renaming yourself and see whether it works for you in practise as it did for me. If it does not, then that supports your theory - if it does, then that may be useful to you, and you can then revise your theory if you wish to match what occurs in practise.