OSDev.org

I'm not currently writing any drivers in 64-bit long mode, so I'm going to use the BIOS as a driver, but I'm experiencing a triple glitch and return address error when returning 16-bit real mode from 64-bit long mode

Code I referencedviewtopic.php?f=1&t=23125


》I am from China and use translators to communicate

ccya wrote:I'm going to use the BIOS as a driver

This does not work with UEFI.

ccya wrote:I'm experiencing a triple glitch and return address error when returning 16-bit real mode from 64-bit long mode

Where? Which exception? Are you using a virtual machine?

refer to the ReactOS code to solve this problem，return to real mode from long mode
https://github.com/reactos/reactos/blob ... 64/entry.S

Returning to real mode is not the problem. The problem is that there might be no real mode BIOS that you can use.

唯一需要回到bios操作的东西可能是vesa，这个在v8086模式下完全可以进行

Google Translated to (please verify):
The only thing that might require returning to the BIOS is VESA, which can be handled entirely within V8086 mode.

"Might be"? Either the system was booted using BIOS, meaning there is a BIOS, or it wasn't, in which case there isn't. There is no guessing involved.

“Might be” expresses a possibility, not a guess.

I solved this problem a long time ago, but I still want to mention one thing: If I boot from UEFI, I will call UEFI directly — there is fundamentally no need for any return at all. If I boot from BIOS, I must return to real mode before I can call BIOS. There is no optionality here whatsoever.

你要是int 0x13 extension或者0xe820那没话说，其他情况纯属自讨苦吃

Google Translated to (please verify):
If you're using INT 0x13 extensions or INT 0x15 E820, then fair enough; otherwise, you're just asking for trouble.

(BenLunt EDIT: This is and always has been and English-speaking forum. May I ask that you translate to English before posting. Please and thank you.)

wishedtobe wrote: ↑Fri Jul 31, 2026 9:43 pm 你要是int 0x13 extension或者0xe820那没话说，其他情况纯属自讨苦吃
(If you're using INT 0x13 extensions or INT 0x15 E820, then fair enough; otherwise, you're just asking for trouble.)

还有int 10用于更改屏幕分辨率，和int 15用于接收USB键盘输入，这些都是很有用的

Google Translated to (please verify):
There are also `int 10` for changing the screen resolution and `int 15` for receiving USB keyboard input; both are very useful.

ccya wrote: ↑Thu Aug 13, 2026 8:59 pm 还有int 10用于更改屏幕分辨率，和int 15用于接收USB键盘输入，这些都是很有用的

Google Translated to (please verify):
... `int 15` for receiving USB keyboard input; both are very useful.

Please expand on this a little. If your USB controller/System Management is using Legacy support, standard keyboard input can be done with 16h as usual, just as if the keyboard controller had submitted the key stroke instead of the USB. The BIOS/firmware receives an interrupt, and its handler doesn't know the difference.

Please expand on the 'int 15' a little by posting what service, indicated in AH, is used.

(Slightly off topic, but I do remember that Chinese versions of some firmware did have additional services. But I could be remembering wrong.)

Thank you,
Ben
- https://www.fysnet.net/osdesign_book_series.htm

This is actually proprietary code I discovered using a debugger. It's likely the XHCI driver used internally by the BIOS, but I've long since abandoned these things. I've stopped developing my project because I've encountered more difficult problems.