OSDev.org

Posted: **Sat Jan 28, 2017 12:03 pm**

Hi, I wanted to move the text mode cursor, and I noticed that the wiki page on the subject says the following:

Also note that the base port (here assumed to be 0x3D4) should be read from the BIOS data area.

Interestingly enough, the wiki page on the BIOS data area says this:

The BDA is only partially standardized, and almost all the values stored there are completely obsolete and uninteresting. The following is a partial list. See the External Links references below for more detail.

Every single "tutorial" I've found that moves the text mode cursor assumes the base port to be 0x3D4. There must be a good reason for that.
If I can find this information using the multiboot info struct, that would be very reassuring, but I'm having some trouble verifying if I've actually obtained the multiboot info struct.

Am I going about this the right way, or should I just assume that 0x3D4 is the magical "base port" like everyone else seems to be doing?

Here's my boot.s which is the bare bones tutorial boot.s but with one extra line added push %ebx:

Code: Select all

# Declare constants for the multiboot header.
.set ALIGN,    1<<0             # align loaded modules on page boundaries
.set MEMINFO,  1<<1             # provide memory map
.set FLAGS,    ALIGN | MEMINFO  # this is the Multiboot 'flag' field
.set MAGIC,    0x1BADB002       # 'magic number' lets bootloader find the header
.set CHECKSUM, -(MAGIC + FLAGS) # checksum of above, to prove we are multiboot

# Declare a multiboot header
.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM

# establish a stack
.section .bss
.align 16
stack_bottom:
.skip 16384 # 16 KiB
stack_top:

# the entry point
.section .text
.global _start
.type _start, @function
_start:

	# point the stack pointer to the top of the stack
	mov $stack_top, %esp

	# maybe one day I'll load a GDT here

	# I suppose the multiboot info is here
	push %ebx

	# call kernel_main to begin the kernel stuff
	call kernel_main

	# halt, jump, loop, poop
	cli
1:	hlt
	jmp 1b

.size _start, . - _start

so my kernel_main looks like this:

Code: Select all

void kernel_main(multiboot_info_t* mbt) {
	
	terminal_init();
	/* access multiboot info */
}

Posted: **Sat Jan 28, 2017 12:48 pm**

peachsmith wrote:Every single "tutorial" I've found that moves the text mode cursor assumes the base port to be 0x3D4. There must be a good reason for that.

The vast majority of the time, when your code is loaded, the base port will be 0x3D4. It's actually pretty difficult to accidentally stumble across situations where it isn't; hardly anyone wants to do anything that would coincidentally change it, and hardware that doesn't default to 0x3D4 is extremely rare and mostly very old. (And if you're worried about such old hardware, you also need to consider that the video card might not be VGA.)

peachsmith wrote:Am I going about this the right way, or should I just assume that 0x3D4 is the magical "base port" like everyone else seems to be doing?

You can ask the hardware directly. There are some pretty thorough VGA resources out there, so it shouldn't take too long to figure it out.

Posted: **Sat Jan 28, 2017 1:53 pm**

Hi,

peachsmith wrote:Hi, I wanted to move the text mode cursor, and I noticed that the wiki page on the subject says the following:
Also note that the base port (here assumed to be 0x3D4) should be read from the BIOS data area.
Interestingly enough, the wiki page on the BIOS data area says this:
The BDA is only partially standardized, and almost all the values stored there are completely obsolete and uninteresting. The following is a partial list. See the External Links references below for more detail.
Every single "tutorial" I've found that moves the text mode cursor assumes the base port to be 0x3D4. There must be a good reason for that.

IBM's VGA cards (which were never intended to be a standard) were released in 1987. Three years later (1990) IBM release its successor (XGA); but they were a little late to make VGA cards obsolete. What happened is that "clone manufacturers" made VGA cards obsolete before IBM could by releasing various SVGA cards.

However, while VGA cards themselves were obsolete over 25 years ago, the "clone manufacturers" kept VGA compatibility for SVGA's registers (in order to cash in on the very short-lived success of IBM's VGA card). This VGA compatibility grew into a de-facto standard; and by the late 1990s was still adding pointless bloat nobody really used (because everyone was using VBE and high-resolution video modes by then).

For better or worse, retarded obsolete trash never dies easily. The "legacy VGA compatibility" became entrenched; and the SVGA manufacturers continued providing it even after switching to PCI (and the potential of having more than one video card, which requires breaking VGA compatibility, became a reality). Instead, the shear idiocy spread into special "legacy VGA hackery" built into PCI bridges and PCI host controller, all to prop up obsolete junk in one and only one video card (of the potentially many video cards that might be installed).

While all this was happening; ASCII (which was poor even for "US English" before you even start to consider internationalisation) got expanded in multiple directions (code pages) into a horrific nightmare of confusion and breakage; and Unicode rose out of the resulting cesspool. By the end of the 1990s, ASCII was obsolete, making the already obsolete "text mode" doubly obsolete.

In addition, due to BIOS sucking badly for many reasons (most of which related to excessive compatibility with antiquated turds) UEFI was introduced (originally on Itanium, but making its way to 80x86 about 15 years ago).

UEFI is like a "cleansing glacier" pushing the rotting remains of deceased ancient technology out of the way, so that we can achieve something that would've been "modern" at the beginning of this century. However (sadly), like a glacier, this is a very slow process - despite the fact that every OS that matters had adopted UEFI over a decade ago; most (but not all) current computers still provide "legacy BIOS" (complete with all the festering puss that nobody sane has actually wanted for 20 years now).

The base port 0x3D4 is part of that "obsoleted in multiple ways many decades ago legacy VGA compatibility".

However that's not quite the end of the parade of deprecated garbage (before ancient history there was "pre-history"). VGA itself was a "slightly compatible" successor to EGA; and EGA was a "slightly compatible" successor to both CGA and MDA. MDA (from 1981) used a different base IO port.

Essentially; you "need" to get the base IO port from the BIOS Data Area to maintain compatibility with hardware that was released over 35 years ago.

peachsmith wrote:If I can find this information using the multiboot info struct, that would be very reassuring, but I'm having some trouble verifying if I've actually obtained the multiboot info struct.

You won't find the information in the multi-boot info struct (GRUB/multiboot is only 20 years old, which is new enough not to have a reason to care much about VGA).

peachsmith wrote:Am I going about this the right way, or should I just assume that 0x3D4 is the magical "base port" like everyone else seems to be doing?

In my opinion; the right way (for current computers) is to get the boot loader (GRUB in your case) to set a high resolution graphics mode for you.

Cheers,

Brendan

Posted: **Sat Jan 28, 2017 9:27 pm**

Thanks!
By the way:

Brendan wrote:UEFI is like a "cleansing glacier" pushing the rotting remains of deceased ancient technology out of the way

That was a beautiful sentence.

OSDev.org

[SOLVED] How do I get the base I/O port for text mode cursor

[SOLVED] How do I get the base I/O port for text mode cursor

Re: How do I get the base I/O port for text mode cursor

Re: How do I get the base I/O port for text mode cursor

Re: How do I get the base I/O port for text mode cursor