tty vs. console

[Whatever5k]

Can s.b. please explain me the difference between a tty driver and a console driver - I think they stand in relation, but in how far? What's the job of tty and what's the job of the console driver?
Currently, I'm planning to implement virtual terminals (switched by Fx keys), so what do I need to implement? And do I have to use the hardware (I've seen this in Minix and TheMoebius) - why cannot I just use software?

[Pype.Clicker]

of course, you're not forced to use VGA hardware to implement virtual consoles ... it's just more convenient and efficient

[Whatever5k]

Alright, so how do I use the VGA hardware - any reference?

[Tim]

Here's my TTY switching code.

Code: Select all

void tty::updateCursor()
{
    uint16_t addr;
    
    if ((unsigned) (this - consoles) == cur_console)
    {
        addr = (uint16_t) (addr_t) (buf_top - (uint16_t*) PHYSICAL(0xb8000)) 
            + y * width + x;
        out(_crtc_base_adr + VGA_CRTC_INDEX, 14);
        out(_crtc_base_adr + VGA_CRTC_DATA, addr >> 8);
        out(_crtc_base_adr + VGA_CRTC_INDEX, 15);
        out(_crtc_base_adr + VGA_CRTC_DATA, addr);
    }
}

void tty::switchTo()
{
    uint16_t addr;
    addr = (uint16_t) (addr_t) (buf_top - (uint16_t*) PHYSICAL(0xb8000));
    
    out(_crtc_base_adr + VGA_CRTC_INDEX, 12);
    out(_crtc_base_adr + VGA_CRTC_DATA, addr >> 8);
    out(_crtc_base_adr + VGA_CRTC_INDEX, 13);
    out(_crtc_base_adr + VGA_CRTC_DATA, addr);
    cur_console = this - consoles;

    updateCursor();
}

Each TTY is a C++ object which has a buf_top pointer member variable, which points to the address of that TTY in video memory.

You have 65536 / (width * height * 2) colour TTYs available, where width and height are the numbers of columns and rows in the TTY (e.g. 80 and 25). The first one starts at B8000, the second at B8000 + width * height * 2, the third at B8000 + width * height * 2 * 2, etc.

[Whatever5k]

Alright, and I cannot go farther than 0x10000, right?
By the way, do you presume that the video card can handle wrap around? That means you don't support older cards, right?

[Tim]

Alright, and I cannot go farther than 0x10000, right?

You can't go further than C0000. BTW, the addresses should have been B0000 onwards in my last post.

By the way, do you presume that the video card can handle wrap around? That means you don't support older cards, right?

Right. Actually, I don't support this method much anyway, since the console is handled by a user-mode program. Minix is probably a better source for this than my code.

[RicoSanchez]

But what actually is the difference between a tty driver and a console driver? isn't a tty a console?

[Whatever5k]

You can't go further than C0000.

Oups, yes of course...

[Tim]

But what actually is the difference between a tty driver and a console driver? isn't a tty a console?

I use the terms interchangably.

[Whatever5k]

Tim, do you use software scrolling? If yes, is there a way to use hardware scrolling *and* having multiple virtual consoles?
And is it really true that you can have 16 virtual consoles - I thought 8 is the maximum...

PS: any way how I can detect if I have a colour or a monochrome card? df's code seems a bit dirty

[Tim]

Tim, do you use software scrolling?

Yes.

If yes, is there a way to use hardware scrolling *and* having multiple virtual consoles?

Yes, you could have hardware scrolling if you want fewer hardware consoles.
[qupte]And is it really true that you can have 16 virtual consoles - I thought 8 is the maximum...

16 consoles, at 80x25, will fit inside the range B0000-C0000.

PS: any way how I can detect if I have a colour or a monochrome card? df's code seems a bit dirty

It looks OK to me. Why bother detecting the type of card if the BIOS has already detected it?

[Whatever5k]

Alright, one more question: I saw many systems buffer their output (minix does so) - so a call to out_char() won't write anything to video memory, but store the character in a ramqueue - only a flush() will write them to video memory...
Is this a good idea?

[Pype.Clicker]

i think it depends on what you wish to do. For sure, it is wise not to have a system call (or even a function call) for every character you display. So if the application provides characters one byte at a time, it might be nice to buffer them and wait either for a flush or for a full buffer to display them at once.

Now, buffering also means you can't rely on the output for debugging (because some exception might make you loose the buffer content. So if you have "print('stuff done')" in your code, you can only tell stuff has been done if you see the message, but in the absence of message, you cannot conclude stuff hasn't been done -- see what i mean ?)

So most system that provides buffering of the output will have IOCTL commands to turn buffering off if needed...

[_mark]

Just for the sake of clariity...

TTY origiinates from the old printers called TeleType Terminals. They were basically just a printer with a keyboard attached. Later on terminals such as the VT100 became common, and functioned much like the printers. They allowed for teletype output from the computer and provided a keyboard for input. The big difference was there was no paper needed.

Dos and Windows have never really needed the concept of a TTY. Since they cannot run headless (without a VGA display of somesort). Unix can still run on a computers without keyboards and displays, thus they retain the concept of a tty.

So a tty is really an input output stream to some device. The device itself handles both input and output. This differs from what we know as a console which is strickly output. The input is handled by another device (the keyboard and mouse).

_mark

[Tim]

Since they cannot run headless (without a VGA display of somesort).

Headless Windows servers are common. You can do virtually all administration over the network. Terminal Services is also being used more and more, which is roughly equivalent to using X over the network.