中国DOS联盟

You said how to carry out experiments with debug!

Using the first one, that is, cat --hex (fd0)2878+1 will crash!

Neiljoy, why not update the BIOS first? ASUS series seem to all support online updates

I learned from the ASUS website that this is the final BIOS version.

Then give you another task to find the boundary between freezing and not freezing:

cat --hex (fd0)xxxxxx+1

It is known that when xxxxxx=0, it doesn't freeze, and when xxxxxx=2878, it freezes. Find the largest value of xxxxxx such that the cat command doesn't freeze.

Just like the test you just did, if it can't even read the sectors within 1.44M, I estimate it's hopeless, and we might ultimately be unable to do anything.

However, you still do the following test under DOS, trying every possible way:

Type debug to enter the debug command line. Then type the following commands:

a ;This a is the assembly command
mov AH,8
mov DL,0 ;DL,0 means (fd0), if the USB flash drive is (fd1), then here should be mov DL,1
int 13
int 3
;Press one more Enter here to end the assembly command
g ;This g is to run

Okay, now paste the output result of the screen here.

Finally, use the q command to exit debug and return to DOS:

q

Last edited by 不点 on 2006-7-24 at 16:24 ]

I'm conducting an experiment and just saw your content upstairs. First, I'll talk about my own experiment situation, and then I'll do the experiment upstairs.
1. I separately made img images containing grub.exe, menu.lst, and diskgen.img files with capacities of 1.44M and 2.88M respectively;
2. Tested in a virtual machine, ran a batch script. The 1.44M one can start diskgen.img with GRUB, but the 2.88M one can't, but it doesn't crash;
3. In the case of 1.44M, whether there is or not map (fd0) (fd1); map --floppies=2 can both start diskgen.img;
4. Found a problem. Whether using the latest version or version 0.4.1, even if grub.exe and menu.lst are both in the root directory of the floppy disk, running grub.exe has no menu displayed (the same in the virtual machine and the real floppy disk), and it prompts error 17, file not found.

Conclusion: 1. When the USB flash drive is in FD or ZIP mode, it's impossible to start the image files of 1.44M and above in the USB flash drive with grub.exe on the USB flash drive.
2. The problem of GRUB crashing when running on the USB flash drive is related to the data structure of the USB_ZIP disk (referring to having MBR, DBR).

Therefore, pictures cannot be posted here. My pictures have been sent to Wuyou Forum, please refer to:
http://bbs.wuyou.com/viewthread.php?tid=80080&extra=page%3D1

Please check it as soon as possible, maybe it will be deleted by the moderator.

－－4. Found a problem. Whether using the latest version or version 0.4.1,
－－Even if grub.exe and menu.lst are both in the root directory of the floppy disk,
－－Running grub.exe does not display the menu (this is the case in both the virtual machine and the real floppy disk),
－－Error 17 is prompted, file not found.

This is not a problem. grub.exe is not like GRLDR, which can determine the partition number of the disk it is on. Therefore, grub.exe does not know that you are running grub.exe from the root directory of the floppy disk. To run grub.exe, you must have --config-file=(fd0)/menu.lst. Otherwise, the default (hd0,0)/menu.lst should be used

Now provide the test results in the virtual machine
Test objects: 1.44M and 2.88M images, equivalent to two floppy drives with capacities of 1.44M (referred to as A) and 2.88M (B)
Test process:
1. Run grub.exe --config-file=(fd0)/menu.lst, A can display the menu; B cannot display, entering the GRUB command line.
2. Store the files in B in order into an empty img: first is io.sys, then menu.lst, diskgen.img (720K), grub.exe in sequence, and other files can be put in out of order.
3. Re-execute grub.exe --config-file=(fd0)/menu.lst, B still has no menu display.
4. Execute cat --hex (fd0)2879+1 to display all "F6", indicating that this sector has no file (and the previous few sectors are also empty), but at 2880+1 it displays:
Error 26:Attempt to access block outside partition

Question: According to reason, several key files are all in the front sectors. From the cat command, they are also within the GRUB reading range, but still cannot display the menu and cannot boot diskgen.img. I don't know the reason?

Last edited by neiljoy on 2006-7-24 at 21:58 ]

It's very simple. The BIOS of the virtual machine doesn't support floppy disks larger than 1.44M.

The other test I mentioned earlier is also needed, which is to find the largest xxxxxxx such that cat --hex (fd0)xxxxxxx+1 doesn't crash.

I estimate there is still hope for a solution. You need to continue to cooperate with the test.

Test under DOS with debug:
a ;This a is an assembly command
mov AX,201
mov BX,200
mov CX,4F12
mov DX,100
int 13
int 3
;Press one more Enter here to end the assembly command
g ;This g means to run
q ;Return to DOS

Report whether there is a crash. If there is no crash, report whether the lower right corner shows NC or CY?

1. What do you mean by saying that the BIOS of the virtual machine doesn't support floppy disks larger than 1.44M? In fact, the VM I use can also start the 2.88M image normally. How can it start if it doesn't support it? How can my test be carried out?

2. Looking for the maximum XXXXX that doesn't crash. I have provided the test result of 2.88M (floppy disk) on floor 39. As for the USB flash drive, if it crashes, I have to press the reset button to restart, which is time-consuming and troublesome. It depends. If it crashes more than twice, I don't want to test it.

I will try debug later. Last time it didn't crash, otherwise I couldn't capture the screenshot!

Last edited by neiljoy on 2006-7-24 at 22:53 ]

1. Can boot, but that doesn't mean it supports 2.88M. It's very likely that all your files are within 1.44M.

2. Don't need the floppy disk test result. Need the USB flash drive one (didn't you want to solve the problem of being unable to access the USB flash drive?). To test the USB flash drive, there must be a system crash, but if you design it well, you can find the largest xxxxx just with several tests. This is not troublesome. Of course, maybe you find it troublesome, then forget it, and continue testing debug.

UM has been used frequently recently. Using it to boot and run 2.88M image files is common, and they all run normally. It can be affirmed that most of the image files I use have a size close to 2.88M. Today is just an exception.

Through experiments with 2.88M in a virtual machine, I am not very optimistic about the USB flash drive anymore.

Now submit the test report of the USB flash drive: three freezes.
The first time, using 2875+1;
The second time, using 2850+1;
The third time, strictly following your debug program, it freezes when executing -g, and then the screen naturally has no display, and there is no need to capture screenshots.

You should use a small value for testing, only then is there hope of not crashing.

But your test is very important. The crash during debugging indicates that accessing the USB flash drive according to the 80/2/18 specifications under DOS is also not possible. This is very useful. If this test sequence can be completed, I think the problem of accessing the USB flash drive should be solved, it will definitely work. However, it's time to rest now, come back tomorrow.

It is estimated that the maximum value of C can only be 7 and 8. So, it should be safe to use C=7, H=2, S=18.

7 * 2 * 18 = 252
8 * 2 * 18 = 288

So, I estimate that using a value within 252 will not cause a system crash. The maximum value should be between 252 and 288.

cat --hex (fd0)252+1
cat --hex (fd0)288+1

------------------------------------------

Test in DOS using debug:
a ; This a is an assembly command
mov AX,4100
mov BX,55AA
mov DX,0
int 13
int 3
; Press an extra Enter here to end the assembly command
g ; This g means to run
q ; Return to DOS

Report whether there is a system crash. If there is no crash, report whether NC or CY is displayed in the lower right corner. Also report the values of the four registers AX, BX, CX, DX.


No matter whether there is a system crash or not, after the above test is completed, the following test will be carried out, and then all tests will be completed.


Test in DOS using debug:
a ; This a is an assembly command
mov AX,4800
mov SI,180
mov DX,0
int 13
int 3
; Press an extra Enter here to end the assembly command
g ; This g means to run
d 180 ; Display data at 180
q ; Return to DOS

If there is no system crash, please upload the screen capture.