Trouble with int 13h

[onlyonemac]

Hi!

I'm just starting out and have switched to protected mode. Now I'm trying a temporary switch back to real mode in order to read the disk. The problem is that as soon as I call int 13h, the system hangs (I've tried it in Bochs and Qemu and it works in both; it crashes on real hardware).

I've tried int 10h for text output and that works fine, so I'm definitely entering real mode correctly. This issue is specific to using int 13h. Any ideas?

Thanks

[Bender]

Do you restore the IRQs and restore the hardware configuration?
Both int 0x13 and int 0x16 will fail in that case IIRC.
Believe me switching to real mode for Disk Access is a really bad idea,
BIOS Drivers are something no to trust outside boot sectors (of course for video modes it's okay, though doing it in V86 mode is better).
If you're planning to use the BIOS I would recommend Unreal Mode instead of protected mode. (This is my opinion, I am not aware of what the OP wants)

[onlyonemac]

I haven't reconfigured any hardware at this point and I've checked with Bochs that I'm reloading the IDTR correctly for the real-mode IVT. I haven't touched the IVT at all, and as I said, other software interrupts are working fine.

@Bender: My OS is my OS and I'm making the design descisions.

[h0bby1]

do you set up the stack back correctly after going back to real mode ?

[onlyonemac]

As I have said above, other interrupts work, so presumably my stack is fine. I have also checked the stack by pushing and popping some values under Bochs.

This issue is clearly specific to int 13, so it's not going to be stacks/IDTs etc. All I can think of is that either the timer interrupt (I think it's int 0x08) or int 0x06 is not executing (as that would explain why it works under Bochs - floppy emulation doesn't rely on the timer), but I can't see why that would be the problem becuase I haven't disabled the timer or remapped the PIC. Should I confirm that the timer interrupt is working, and if so how?

[Combuster]

As I have said above, other interrupts work, so presumably my stack is fine. I have also checked the stack by pushing and popping some values under Bochs.

Mind you, "It happened to work" is not a proof in the least. Your stack configuration might still be broken. I'd also check that you didn't write into the BDA or EBDA anytime.


Also, most importantly, you can easily debug this yourself by removing all code that's not responsible for mode switches.

[h0bby1]

i mentioned the stack because int13 is most likely to use some of it, as it can used the stack to create tables to store command for the controller, and it need some amount of it, probably more than other interrupts, but it might be something else as well, but just check the stack is at least few kilo, otherwise in the classics, make sure your 32 bits registers are well cleared, or that you clear them with the 32 bit prefix when you go back to real mode, in 13h can be picky about data alignment as well, so it can potentially be a source of bug if you send unaligned pointer to it on some bios, and make sure all address you send are with the 16 bit seg/ofset real mode format

if you want to check the timer irq, if you are in text mode you can just output a counter directly on the screen from the interrupt handler, and sometime bios can potentially use some memory a bit anywhere to store some informations, normally you can get a memory map with another interrupt (16h i think ?), so it can be worthy to check if you don't write memory in an "non available" memory area

[onlyonemac]

Well I've checked the timer interrupt and it's working fine. Any more ideas?

@h0bby1: I'm afraid almost none of your suggestions are specific to real hardware (remember I said it works fine under both Bochs and Qemu).

[thepowersgang]

Actually, his suggestions are VERY applicable to real hardware.
Bochs and qemu use quite simple BIOS code (due to the well defined hardware), while a real BIOS tends to have very complex BIOS code (which will use extended registers, and probably use far more stack).

Make sure you leave your system in a state that the BIOS expects before calling BIOS interrupts. Emulators might let you off easy, but there will be at least one real system that will do something funky.

[onlyonemac]

@thepowersgang: Yes, that's what I mean. h0bby1's suggestions may be APPLICABLE to real hardware, but not SPECIFIC to real hardware. Exactly what I'm getting at is that yes, real BIOSes are more complex than Bochs, so are more likely to fail if something's not right. Now the question is, what's likely to cause a real BIOS to fails which does NOT cause emulators to fail (i.e. which is SPECIFIC to real hardware)?

[Combuster]

Your whole way of posting says you're too lazy to do the necessary grunt work.

OSDev isn't about guesswork, so I'm not even going to give you guesses.

[onlyonemac]

I tried clearing the extended registers - coincidently I had actually left something in the upper part of the ebx register. Nevertheless, this didn't help.

@Combuster: This is not guesswork. It's a case of that I've tried everything I can to fix the problem but it didn't work. Not knowing what to do next, I have turned to the forums to ask those who know more about this issue and what could be causing it. I don't know what your problem is.

[Combuster]

I guess your problem is that you haven't learned to debug, so I just have to force that.

[iansjack]

@thepowersgang: Yes, that's what I mean. h0bby1's suggestions may be APPLICABLE to real hardware, but not SPECIFIC to real hardware. Exactly what I'm getting at is that yes, real BIOSes are more complex than Bochs, so are more likely to fail if something's not right. Now the question is, what's likely to cause a real BIOS to fails which does NOT cause emulators to fail (i.e. which is SPECIFIC to real hardware)?

I think you really mean "(i.e. which is SPECIFIC to my real hardware)". As fate would have it, I don't have access to your real hardware, so can't help with that. But you are in luck as there is one - and just one - person on these forums who does have access to that hardware. Your problem now is to convince that person that they need to do a little debugging for you.

[JAAman]

@thepowersgang: Yes, that's what I mean. h0bby1's suggestions may be APPLICABLE to real hardware, but not SPECIFIC to real hardware. Exactly what I'm getting at is that yes, real BIOSes are more complex than Bochs, so are more likely to fail if something's not right. Now the question is, what's likely to cause a real BIOS to fails which does NOT cause emulators to fail (i.e. which is SPECIFIC to real hardware)?

your just plain old wrong here...

your problem is NOT something that is specific to real-hardware, it is something that is specific to your real hardware

no 2 computers in the entire world work exactly the same way -- your problem is not emulator-vs-real-hardware, it is one-system-vs-another-system

h0bby1 was exactly right -- and almost certainly mentioned what your problem is -- all these things he mentioned are things that can easily go wrong on some systems but work fine on other systems -- in fact, they can sometimes work and sometimes fail even on the same system!