VGA Text Mode 132x60

paul · Post by **paul** » Sat Aug 04, 2007 1:23 pm

In my little OS I'm using code derived from this to set a vga text mode greater than 80x25 from protected mode. It's working great, but I'd like to get into 132x60 mode if possible, and unfortunately the original code only contains the register values for up to 90x60.

So, my question is: does anyone know what the registers should be set to in order to get into 132x60 text mode?

jnc100 · Post by **jnc100** » Sat Aug 04, 2007 4:09 pm

AFAIK its a vesa mode, number 0x10c, therefore the implementation need not be standardised and you should just rely on int 10h. Guess you could drop back to real mode to make the switch, or use a v8086 task or ask grub to do it for you.

Regards,
John.

Combuster · Post by **Combuster** » Sun Aug 12, 2007 2:18 am

132 characters equals 1188 or 1056 pixels in the width. That is way beyond the 'sane' limit of VGA's - if you try it the resulting refresh rate will be around the 20hz. I have yet to find a CRT that supports that. The limit for the VGA is around 100x75 characters, using 8x8 cells, which equals a 45hz 800x600 resolution. The refresh rate is already good for getting headaches, but if you want a very-high-resolution text mode using a plain VGA, this is about the best you can get.

if you do want to get 132x60 mode, jnc is right and you should try using VESA, or even card-specific drivers.

inflater · Post by **inflater** » Sun Aug 12, 2007 3:32 am

Never seen 132x60 mode. It must be a pain in the ... ehm you know where, with 20Hz refresh rate. It's bad for your eyes. Even 80x50 is totally stretched up (I use 80x25 normally...)
I can send you hardware switching to 80x25, 80x43 (like on EGA card) or 80x50 mode, but... 132x60?

Is there any screenshot with today's CRT monitor running text mode 132x60 with some, preferably DOS application?

Regards
inflater

paul · Post by **paul** » Sun Aug 12, 2007 5:57 am

Well, I know linux can handle up to 132x60, and I'd like to get into that mode even if just for testing in bochs & qemu, because I find 80x25 is not enough space to display detailed debug information, and the 90x60 mode I'm using now looks stretched horizontally.

My eventual plan is to get into a graphical mode but for now I'm not ready for that, and I need as much display space I can get even if it doesn't work/isn't practical on most read hardware.

Combuster · Post by **Combuster** » Sun Aug 12, 2007 6:51 am

if you want to cheat on bochs crappy VGA implementation, you can just load the horizontal total and display end registers with really high values to get the space you want.

setting
0x3d4/0x00 -> 0xFF
0x3d4/0x01 -> 0xFF
0x3d4/0x13 -> 0x80
should theoretically trick bochs into displaying 256(!) characters horizontally. I haven't tested it, and i can not guarantee it works. It will however desync all self-respecting monitors so I urge you not to try it on real hardware.

hope that helps

urxae · Post by **urxae** » Sun Aug 12, 2007 3:39 pm

paul wrote:[snip] and I'd like to get into that mode even if just for testing in bochs & qemu, because I find 80x25 is not enough space to display detailed debug information, [snip]

You could also consider sending debugging output to one of the serial ports (possibly in addition to sending it to the screen). The code to do so is very simple, can be found in the linked wiki article.
You can then configure bochs & qemu to redirect com1 output to a file (or terminal, if you're running a Unix-variant). I like to send it to the emulator's stdout and run the emulator from a max-width terminal window.
For qemu, add "-serial file:com1.log" or "-serial: stdio" to the command line (the latter only works on Unix according to the man page).
For bochs, put "com1: enabled=1, mode=file, dev=com1.log" or "com1: enabled=1, mode=file, dev=/proc/self/fd/1" in your config file. The latter will again only work on Unix (at least AFAIK Windows doesn't expose a file name for stdout, and the bochs manual doesn't give a way to send serial port output to stdout so directly).

Unfortunately, for a test on real hardware you'll need a null modem and another computer to get at the serial port output. You may want to conditionally compile the serial port output and remove it if you don't have those available, since at least one computer I have here gets very slow when writing to an unconnected serial port... (can't try writing to a connected one since I don't have a null modem)

paul · Post by **paul** » Sun Aug 12, 2007 4:16 pm

urxae wrote:You could also consider sending debugging output to one of the serial ports (possibly in addition to sending it to the screen).

Thanks for that, the serial port should be extremely useful, I hadn't though of using it before, but having a full output of debug info would be much better than outputting to the screen where it eventually scrolls away. I'm gonna need to rework some code now so I can have multiple 'consoles' for screen & serial, and maybe have a debug flag that grub can pass to enable the serial one.

Kevin McGuire · Post by **Kevin McGuire** » Sun Aug 12, 2007 7:53 pm

#define PPORT 0x378
outb(BYTE, PORT);
outb(0x0c, PORT + 0x2);
outb(0x0d, PORT + 0x2);

BOCHS will print from the parallel port to file very easily, but QEMU is a little trickier. QEMU will allow you to specify the parallel port with the command line option -parallel, but it requires it to be a character device. You can redirect it to stdout using -parallel /dev/stdout however I have noticed the my terminal will stop echoing typed characters and ignore control characters once you do this. This problem could be just confined to my setup and not others so it might be worth a try.

If you could find a way, which I am sure exists, to send parallel data to a regular file using QEMU then of course using the parallel port is a definitive option I think.

<urxae suggestion>
I have never tried -parallel file:<file>. That might be the solution for QEMU.
</urxae>