Hello, so I decided to follow brokenthorn's tutorials a while ago, and now am on the part where I read from the floppy. The only problem is, when I try to read from it, it doesn't output any text. I have a file (TEST.TXT) stored on the floppy image. I have debuged the whole track of functions to read from the floppy but they all work fine. Any help would be great!!
And personally I think this is a perfictaly legitimate question, and I have done a lot of searching
Brokenthorn's tutorial
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Brokenthorn's tutorial
You too, young padawan, must learn not to lie to yourself.I have debuged the whole track of functions to read from the floppy but they all work fine.
Re: Brokenthorn's tutorial
What do you mean? Do you know whats wrong?
PS: I commented all the wait_interrupt() functions so it will continue since I'm running from qemu.
PS: I commented all the wait_interrupt() functions so it will continue since I'm running from qemu.
Re: Brokenthorn's tutorial
Hello,
What is your build environment and tool chain? The series targeted a specific version of VC and may not work on other versions due to the assumptions made in some of the older code (although can be made to work with little modification.) More specifically, we suspect the error might be with the ISR which should have been written in assembly language not C for portability. It might also be helpful to provide your current code - unless of course it is the same code as provided in the series.
I think what Combuster was referring to was with the use of a proper debugger you can isolate the problem code fairly easily. Never assume code works - know it. Unfortunate the only debugger available is Bochs unless you write or port a source level debugger compatible with VC. If interested, we are in the process of making one however it will still be a few months. If you are using GCC, GD is a powerful source level debugger that integrates very nicely.
If you are using GCC however it would be helpful to provide relevant code sections. Since you mentioned wait_interrupt we need to first verify proper configuration and initialization of the FDC and DMAC since that routine has nothing to do with the file system driver.
What is your build environment and tool chain? The series targeted a specific version of VC and may not work on other versions due to the assumptions made in some of the older code (although can be made to work with little modification.) More specifically, we suspect the error might be with the ISR which should have been written in assembly language not C for portability. It might also be helpful to provide your current code - unless of course it is the same code as provided in the series.
I think what Combuster was referring to was with the use of a proper debugger you can isolate the problem code fairly easily. Never assume code works - know it. Unfortunate the only debugger available is Bochs unless you write or port a source level debugger compatible with VC. If interested, we are in the process of making one however it will still be a few months. If you are using GCC, GD is a powerful source level debugger that integrates very nicely.
If you are using GCC however it would be helpful to provide relevant code sections. Since you mentioned wait_interrupt we need to first verify proper configuration and initialization of the FDC and DMAC since that routine has nothing to do with the file system driver.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: Brokenthorn's tutorial
Thanks for the reply, I am actually not using VC. So I have written the files, edited them etc. to fit without using VC.
By debuging what I meant was that for each function call and return througout the whole proccess I had it print usefull information to the screen. Such as: the function name, sector, return value, boolean value, etc.. My only problem (that I have discovered) is when I try to read a file, it doesnt print anything to the screen. Thanks!!
By debuging what I meant was that for each function call and return througout the whole proccess I had it print usefull information to the screen. Such as: the function name, sector, return value, boolean value, etc.. My only problem (that I have discovered) is when I try to read a file, it doesnt print anything to the screen. Thanks!!
Re: Brokenthorn's tutorial
Hello,
Have you used the debugger to actually verify the file gets loaded into memory at the expected location and the contents of it is correct? (Do not try to display it, verify it using the debuggers xp command and compare with the use of a hex editor.) If it is valid then you can be sure the file system code is not at fault (note however it does not mean its error free.)
Not necessarily. If you never receive the interrupt signal after sending the read request (this is what wait_interrupt waits for) then you have a lower level problem. The file system code should not at all be dependent on wait_interrupt - they operate on different abstraction layers. wait_interrupt is the FDC only and should always work and has nothing to do with the file system code.My only problem (that I have discovered) is when I try to read a file, it doesnt print anything to the screen. Thanks!!
Have you used the debugger to actually verify the file gets loaded into memory at the expected location and the contents of it is correct? (Do not try to display it, verify it using the debuggers xp command and compare with the use of a hex editor.) If it is valid then you can be sure the file system code is not at fault (note however it does not mean its error free.)
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: Brokenthorn's tutorial
I apologise for the ambiguous reply, what I meant was that I had commented (and thus disabled the wait_interrupt() function call) the wait_interrupts call due to my knowledge that we my doesn't issue those interrupts. So in the flpy_read_sector(args...) it no longer waits for the floppy interrupt. But after this, it
Spotted out a blank line instead of "Hello from test.txt".
Thanks for the help guys
!!
Spotted out a blank line instead of "Hello from test.txt".
Thanks for the help guys
!!Re: Brokenthorn's tutorial
Hello,
You have not provided the requested information and have not provided nearly enough detail about your source and environment to even begin providing assistance. You seem to be under the assumption that the file system code is fine however we must confirm it with an actual debugger and back track if it is not to find the source.
Regarding wait_interrupt, it is tricky to get this one right. You must wait for an interrupt request but need to be careful of it being triggered prior to this call. This loop should wait for an interrupt but break after a timeout has occurred to avoid infinity loop.
You have not provided the requested information and have not provided nearly enough detail about your source and environment to even begin providing assistance. You seem to be under the assumption that the file system code is fine however we must confirm it with an actual debugger and back track if it is not to find the source.
Regarding wait_interrupt, it is tricky to get this one right. You must wait for an interrupt request but need to be careful of it being triggered prior to this call. This loop should wait for an interrupt but break after a timeout has occurred to avoid infinity loop.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: Brokenthorn's tutorial
Hello, here is a little more information about my situation:
Cross-Compiler:
i686-pc-elf
Linker:
i686-pc-elf-ld
I think the file system is stable. But I think that qemu might just not like the floppy image I am using...
Cross-Compiler:
i686-pc-elf
Linker:
i686-pc-elf-ld
I think the file system is stable. But I think that qemu might just not like the floppy image I am using...
Re: Brokenthorn's tutorial
Hello,
This is my third and final request. Please verify that the file actually gets loaded using a debugger. I can provide instructions if needed. Never assume - know. Use Bochs for the debugging process (it is recommended to test using multiple emulators and virtual machines for compatibility.)
Sorry but you have not provided anything at all relevant to the problem in question which is why we are not getting anywhere. Since you are under the assumption that the file system code is correct, we need to check that assumption first and then backtrack (I am sure it is not but we need to verify.)
Since you have modified the software and environment we can not make any assumptions about your code and what it looks like. Note that we are not mind readers; please provide as much detail as possible in future posts.
If you provide the floppy disk image we can perform the tests here however you really need to be able to use the debugger yourself as well. Please feel free to provide the disk image here but do try the debugger first.
This is my third and final request. Please verify that the file actually gets loaded using a debugger. I can provide instructions if needed. Never assume - know. Use Bochs for the debugging process (it is recommended to test using multiple emulators and virtual machines for compatibility.)
Sorry but you have not provided anything at all relevant to the problem in question which is why we are not getting anywhere. Since you are under the assumption that the file system code is correct, we need to check that assumption first and then backtrack (I am sure it is not but we need to verify.)
Since you have modified the software and environment we can not make any assumptions about your code and what it looks like. Note that we are not mind readers; please provide as much detail as possible in future posts.
If you provide the floppy disk image we can perform the tests here however you really need to be able to use the debugger yourself as well. Please feel free to provide the disk image here but do try the debugger first.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: Brokenthorn's tutorial
Ok, I think I need your offer of instructions to check if the file is loaded. I have attached the floppy image.
The only part of the code I changed was the part where the floppy driver waited for an interrupt, and the part where it capitalized the inputed name (using toupper()).
Please let me know if you need anything else, just let me know
The only part of the code I changed was the part where the floppy driver waited for an interrupt, and the part where it capitalized the inputed name (using toupper()).
Please let me know if you need anything else, just let me know
- Attachments
-
- floppy.img.zip
- The floppy image.
- (3.37 KiB) Downloaded 89 times
Re: Brokenthorn's tutorial
The Bochs debugger is ideal for this situation (and conversely, the problem is likely to be very hard to solve without a debugger). It has an amazing graphical debugger, as well as one that works from the command line.
First, single step until you find the interrupt that is responsible for the loading of the floppy into RAM. Verify the values in the registers against those used in the tutorial and/or those in Ralph Browns interrupt list. Now check the memory where the floppy image should be loaded to. Then step over the call (not into it), and re-check the memory in Bochs (you might have to refresh the view to see if it has changed), and compare with the memory in the floppy sector that should be loaded.
When you've done this, you might have a better clue what's going wrong. It is not feasible to say what's wrong based on what you have told us so far. The probability that anyone will take the time to spit through your bootloader is very low: it's your code, it will take other people a lot of time to read and understand all of it (especially if you just post the binaries).
First, single step until you find the interrupt that is responsible for the loading of the floppy into RAM. Verify the values in the registers against those used in the tutorial and/or those in Ralph Browns interrupt list. Now check the memory where the floppy image should be loaded to. Then step over the call (not into it), and re-check the memory in Bochs (you might have to refresh the view to see if it has changed), and compare with the memory in the floppy sector that should be loaded.
When you've done this, you might have a better clue what's going wrong. It is not feasible to say what's wrong based on what you have told us so far. The probability that anyone will take the time to spit through your bootloader is very low: it's your code, it will take other people a lot of time to read and understand all of it (especially if you just post the binaries).
Re: Brokenthorn's tutorial
The image I posted was the disk image I am using as a floppy disk. Here is some of the edited code I did (the files are attached).
- Attachments
-
- Source.zip
- (10.55 KiB) Downloaded 70 times
Re: Brokenthorn's tutorial
Hello,
The provided boot image does not include a valid boot record and also appears to not contain the boot loader executable and thus will not be possible to test with. You can use DD to create an image but still need to copy of the boot record which should be done in a way to avoid overwriting the Bios Parameter Block. Something like this,After which copy over any other file needed (such as your boot loader and test document.)
Note: It is a good idea to write a small utility to install the boot record and merges it with the existing file system tables (this is what the last two commands do.) The utility can be smart enough to detect the file system, if any, and install the correct boot record automatically.
If you are using or prefer another method to create the image please post it here so that it can be corrected.
It will also be helpful to provide a copy of your current source code. Upload it to a source repository if not already done so (We use BitBucket) and link to it. As noted above many people probably will not want to take the time to look through all of it. I can look through it a little depending on its readability and design but will not be able to test it here due to differences in build environments.
Edit: We will take a look at the source but still recommend a source repository for the long run as the project continues to grow. We also need a valid disk image.
The provided boot image does not include a valid boot record and also appears to not contain the boot loader executable and thus will not be possible to test with. You can use DD to create an image but still need to copy of the boot record which should be done in a way to avoid overwriting the Bios Parameter Block. Something like this,
Code: Select all
dd if=/dev/zero of=floppy.img bs=512 count=2880
mkfs.msdos floppy.img
dd if=bootsect.bin of=floppy.img bs=1 count=3
dd if=bootsect.bin of=floppy.img bs=1 skip=62 seek=62 count=450Note: It is a good idea to write a small utility to install the boot record and merges it with the existing file system tables (this is what the last two commands do.) The utility can be smart enough to detect the file system, if any, and install the correct boot record automatically.
If you are using or prefer another method to create the image please post it here so that it can be corrected.
It will also be helpful to provide a copy of your current source code. Upload it to a source repository if not already done so (We use BitBucket) and link to it. As noted above many people probably will not want to take the time to look through all of it. I can look through it a little depending on its readability and design but will not be able to test it here due to differences in build environments.
Edit: We will take a look at the source but still recommend a source repository for the long run as the project continues to grow. We also need a valid disk image.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}