OSDev.org

I want to emulate mode 512x480 256-color mode.

I need it for programs like NO$GMB.

What would be the VGA register values and maybe a VESA mode number?

VBE mode numbers are hardware-dependent. While the obsolete 1.0 version of the VBE specification did have some "standard" mode numbers, 512x480x8bpp was not one of them. If, for some reason, you're using ancient DOS software that doesn't have a built-in way to list and select modes, I'm certain that there are existing utilities able to list the modes supported by your hardware with their respective mode numbers.

512x480x8pp is also not achievable on standard IBM VGA hardware as there is no clock chip that can generate the required frequencies and therefore any register settings will also be hardware-specific.

Not sure what this question has to do with OS development, but anyway...

i never see a vesa resolution like this one

but if I needed this resolution, I would lazily use a resolution of 640 * 480 but not write anything on a 64 pixel strip each side, and I would dilate the image of my screen

But then, what resolution does NO$GMB 2.5 for DOS use?

Is it VESA or plain VGA?

Is it 640x480 or 512x480?

It has at least 256 colors.

If it's a resolution achievable by the VGA but not standard, it would be very important to get the VGA registers somehow.

i think the 640*480*8 is a vesa mode because we can access more of 256kb w vesa and this mode need 300Kb

im not sure but the max in 8bit in vga is 640*400.

only a specialist of vga can tell you if you can or not change setting of vga card to obtain 512*480 mode but i'm not

i just can tell you the vesa in linear mode can acces all the video memory without any memory bank swapping, you just have to select the good video mode in real mode before use protected mode

Unless it's targeting SVGA, it doesn't have more than 256 colors. How certain are you on the 512 width? There were a lot of column doubled and line doubled possibilities. For GameBoy/Super Game Boy support, 16 colors would be enough, though it would need more for GBC.

512x480x8bpp would fit in the 256k VGA memory. If your card has a full VBE, you could query it to see if they gave it a mode number or not.

At the time, everything supported the usual VGA register interface, and nonstandard modes came down to fiddling with the CRT controller settings and hoping your monitor liked the result. These would be the variety of modelines for custom X11 resolutions and refresh rates. http://www.osdever.net/FreeVGA/vga/vga.htm would serve as a decent starting place for those bits. Finding a copy of Michael Abrash's Black Book would provide plenty more gory details.

If it did hit a 512x480 mode, it would not be a nice linear framebuffer, but would be the chunky/planar Mode X style setup -- 4 64KB planes visible at A000:0000, with the particular one read/written selected via some register bits (and thus needing a couple of OUTBs to change it), with 8 bit pixels, and the pixels interleaved horizontally across the scanline. Byte 0, plane 0 at the upper left corner of the buffer, byte 0, plane 1 to the right of it, and so on, until byte 1, plane 0 as the 5th pixel, and so on.

These days that interface will get emulated by DOSBox. I'm not sure how much of the raw register interface tends to be supported by hardware these days, as opposed to just exposing the old BIOS interface.

You can set up the VGA Hardware registers to do 512-pixel wide, but only in 4-bit modes. Since a VGA's memory clock is not fast enough, it will always double pixels horizontally for 8-bit modes (i.e. 320x240x8 is actually 640x480 on the wire). You won't find this mode in VESA either, leaving device-specific methods as the only option. And of course there has to be the mandatory warning with these shenanigans that some very crappy monitors do not at all like this resolution and might choose to depart for the green fields forever. The 512x480x4 mode is an exercise for you, detailed info is on the wiki.

tl;dr: If you need those minimums, just use a 640x480 VESA mode and ignore the pixels on the left/right side.

You can get 800x600x4@migraineHz out of a VGA, but the hard limit is that 1024 pixels wide (needed for the 512 wide in 8-bit colours) needs that one extra bit in the register size that the VGA doesn't have.

Yes; due to that pixel-doubling and the 256KB memory limitation the highest 256-colour mode that's achievable on standard VGA is 360x480, which is 720x480 "on the wire". This should be "safe" for any VGA monitor/card (but don't quote me on that), since it's the just the 720x400 resolution used for 80-column text mode with the 640x480 vertical timings.

Hi,
Probably 640x480x256 VESA, but that's just a guess.

Because it's a DOS program, that's actually quite easy.

You'll have to write a small TSR that sits on the video and keyboard interrupts. Whenever a video interrupt is called, you log the registers into a file. For the keyboard interrupt, you look for a specific key (let' say PrScr), and when it pressed, then you read and log the VGA registers.

You install this TSR before you start NO$GMB. Then when you see it's using that resolution, you press PrScr, and violá, you'll have in the log file everything you need. If it's a VESA mode, then you'll see it's mode number (could be card specific). If it's a VGA mode, then you'll see what resolution was originally used, and in the register dump you'll see what clock values were used (those are probably just garbage for VESA modes, only valid if a VGA mode was set with the video int).

See https://files.osdev.org/mirrors/geezer/osd/graphics/modes.c, it lists VGA register dumps for a few modes. Combining different vsync and hsync values may result in non-standard, but working resolutions (or blowing up your CRTC monitor ). For example 320x240 is achieved by using half the clock values of 640x480.

Also http://www.rohitab.com/discuss/topic/42383-entering-mode-q-by-tweaking-vga-mode-13h/

This might be useful too

I've never heard of a mode 512 wide, however it's half of 1024, so I assume 512x384 wouldn't be impossible (in theory at least). With 256 colors, it could fit into the VGA RAM, but would need 3 banks (mode-x uses only 2).

Cheers,
bzt

The file zuliagmb.png shows a strange 16-color resolution when I run ZULIA.COM for intercepting INT 10H.

Only in the menu screen (nozuliagmb0.png) the resolution seems to be a VESA one like 640x480x256. Bochs doesn't report dimension change than when it is in plain VGA 640x480x16 under Windows 98.

But the resolution of the main one seems to be less than 640x480 (nozuliagmb1.png).

This is what Bochs reports:


This is the minimum DOSBox configuration that works, it suggests that it is a plain VGA-only mode (and vgaonly is a tiny bit less bright than the default svga_s3):

Top one would be pixel and line-doubled 256x240 at 8bpp. Bochs/dosbox emulation would stretch that up to a 512x480 window to best match the expected behavior. Most likely set up by either setting to mode 13h and tweaking the registers, or just hammering the vga regs directly for the mode.

Second one looks like it set things up for 320x200x8bpp mode 13h, with a particularly hideous color selection.

It seems so.

The 512x480 mode is like MODEQ from ZSNES (256x240 at 8bpp).

But I still don't know why I can't set the mode with my INT 10H patch (that's where it looks like 16-color mode), there has to be some sort of bug that doesn't properly call the original INT 10H or preserve return registers:
http://forum.osdev.org/viewtopic.php?t=35245

As mentioned, they may not be calling int 10h at all for some of that, and just be setting registers directly. The BIOS in the BOCHS or DOSBox might be expecting some extra state to stay valid, that gets trampled by your explicit register set.

For the raw Win7 space, I would expect things to only work right on 32 bit windows. The BIOS code will likely all be 16 bit code, that won't even run from long mode, and V86 mode went away. I'm not sure DOSBox really gives you a test environment that would transfer to a Win7 console program.

The late era VESA/VBE modes tended to need an external driver install, like SciTech's UniVBE or display doctor.

Looking at the code from the other thread: (ignore dumb questions, my old dos-fu is rusty)

How do you know 7FFF:0000 is available and not going to be trashed?
The code appears to be making some big assumptions about the value of DS on entry to your int10h

The code was totally outdated and with bad bugs.
This is the latest:
download/file.php?id=4265

The code is really reserved at current CS:_int10 offset (only the function offset is static, CS can always change).

And didn't return the result value in AX.

Now it works better than previous versions for standard VGA (I still need to add support for VESA under Windows 7, but I need to understand how DOS ZSNES manages to activate it as this is the program to understand this trick).

You can help by inspecting the code and describing in code how to call VESA services so they become enabled in Windows 7.

The logical way to do that is:
- Set mode 13,
- Do your mode-x stuff to get 240 vertical
- Update horizontal display end to 512 (this makes the right side of the screen blank on CRTs)
- Update horizontal raytrace start and end, make it start and end 64 pixels earlier (this shifts the screen to the right so that its centered again)
- Hope this doesn't confuse the hell out of LCD panels.

I believe Tweak has settings for 256x256x8 that you can source.