#78 132column support


Can/Does Dosbox support 132columns ?
When I tried usual dos mode command (mode con: cols=132) get "Illegal Command: mode."


  • Peter Veenstra
    Peter Veenstra

    DOSBox supports 132 columns without problems.

    However dosbox doesn't come with mode.com
    so you have to get one from a dos instalation.

    (for example IDA can run without problems in 132 columns mode)

  • kalpha


    "without problems" for some but not me.

    I don't know how IDA achieves it,
    but I am trying to code for it using an assembly call h10 which works under dosemu (tho I then have an issue with font size) when I try the same call in dosbox it is still 80char wide, text still appears but everything after character 80 on line 1 is forever in wrong place.

    also I tried to "take" mode from some dos installations the MS ones complain about incorrect version, the freedos one (which works in dosemu) still only gives 80char in DosBox.

  • Peter Veenstra
    Peter Veenstra

    for the CVS:
    "default/svga_s3" supports mode 0x54 and 0x55
    "svga_et3000/svga_et4000" supports mode 0x18,0x19,0x1a and 0x22,0x23,0x24
    " svga_paradise" supports 0x54,0x55,0x56,0x57

    I think that 0.72 supports 0x54 and 0x55 (IDA uses one of those)

    Could attach a code sample that reproduces the problem ?

    (small com file ?)

  • kalpha

    0x54 in DOSBox gives 132x43 (in Dosemu it gives 132x30)
    looks like 0x00 to 0x13 are "standard" cga/ega/mcga/vga modes
    above 0x50 and below 0x100 are referred to as video card makers "BIOS" modes and I suspect there may be some differences. you mentioned s3, et4000 and paradise. it appears dosemu uses Trident 8900 as a reference.
    Which maybe accounts for differences with 0x54
    0x100 and above appear to be referred to as "VESA" modes, in dosemu they have one table vgaemu_modelist.h and cross reference the "BIOS" and the "VESA" modes
    {0x53, 0x109, TEXT, TEXT, 4, 1056, 350, 132, 25, 8, 14},
    {0x54, -1, TEXT, TEXT, 4, 1056, 480, 132, 30, 8, 16},
    {0x55, 0x10a, TEXT, TEXT, 4, 1056, 473, 132, 43, 8, 11},
    {0x56, 0x10c, TEXT, TEXT, 4, 1056, 480, 132, 60, 8, 8},
    on the face of it the 0x54 entry is saying there is no VESA equivalent.
    The VESA equivalents appear correct from what I can find, but the "BIOS" modes are probably video card maker specific and unfortunately differ from S3 etc. I came across comments suggesting that various Video Card makers dropped certain modes because of space constraints on the old video card bios.

    It would be nice to see the VESA modes supported in DOSBox as it would mean I could create code that works in DOSBox or Dosemu regardless of video card being emulated ?

    Having got 132 column support in DOSBox I have same prob as with Dosemu, the width of the box is wider than my laptop 1024 pixel screen. Is there anyway to make the font and hence box narrower ? Is that worh a seperate feature request thread ?

    I'll see if I can knock up usable code sample, but code wise I invoke the mode change in PB3.5 using an inline assembler call as below
    reg 1, &h4f02
    reg 2, &h54
    call interrupt (&h10)

    to write to screen I'm using a routine from I think a PB sample called QPRINT which I hacked for 132 column support.
    I'll try to tidy it all up and attach later.

  • Peter Veenstra
    Peter Veenstra

    for dosbox you can find our vesa modi:

    I see currently no reason to change our 0x54 to 132x30.
    It are after all custom modes anyway. You should actually list all vesa modes and select the one you want.
    Not want that dosbox and dosemu have the same ones. (we emulate a different chip then dosemu)

    I could add a 132x30 mode to DOSBox. but would have to see if the s3 supported that one.

    When emulating a tseng the modes 0x1a and 0x22 might be interesting (132/28)

    I will search some documentation on which 0x54 is more common.

    You don't need to request for downscaling the graphics. I see no reason to have it in dosbox. (which targets primary gamers, who want as big graphics as possible.)

  • kalpha

    wasn't asking for a change to 0x54 (as DOSBox) seems correct to VESA ( I do not want 30 lines)
    But was suggesting support for VESA modes 0x10a, 0x10b, 0x10c would be useful.
    (they are the ones I am interested in, i.e. 132 cols and min of 43 lines, tho 50 or 60 would be useful)
    From a code calling point of view If you support all VESA modes then what chip you are emulate is irrelevant.
    But obviously there may be issues if you are tied to emulating s3 and there is a reason why that chip can not handle these modes (that also affects emulation) i.e. some issues around hardware restrictions may not apply in software emulation.

    Just because of your opinion and DOSBox primarily/originally aimed at gamers, is there any other reason not to expand it's use (if it doesn't affect the gamers) ?

  • Peter Veenstra
    Peter Veenstra

    try output=overlay
    and a window/full resolution.
    That might scale it down, but I don't know for sure I as I never tried it.

    features not for games: Makes DOSBox bigger, more bloated and the code needs to be maintained.

  • kalpha

    haven't had much chance to test, but initial attempts with output= and resolutions= do not seem to make any noticeable difference for me. But maybe I did something wrong. The startup box always seemed to be about same size no matter what resolution (for full or window) I tried and ditto for the changing of screen mode ?

    just as a test I duplicated the line for 0x54 in int10_modes.cpp with an entry for 0x10A this added 64bytes of bloat but appears to have had my desired affect of allowing my code to call 0x10A whether it is dosemu or dosbox. But I have not had time to check what the other values on the line represent and what the true VESA 0x10A should have if different to 0x54 details.