ggorts wrote:

I think dosbox isn't the best way to test it. 🙁 Perhaps I'll switch to dosbox-x and put it to the test.

Your code only seems to be setting the screen but not doign anything else unless i copied it wrong (I'm trying to condense it into separate functions so SWimp_endframe isn't a mess anymore)

I also just pushed now code that divides the banked and planar into two separate functions, youll have to if 1 them to play around. This will make it easier if you figure it out and send me a diff

Also you can use -vgaonly to make sure you're not accidentally using a VESA mode. That will only add 320x200 , 320x240 (if you if 1 the add planar function) and the banked SVGA modes.

One thing I noticed is that screen_width is not being used at all, just being set.

I think the outportb commands are ok, but the Q1 code will be unique resource for the drawing code.

what i'm saying is i think you only need to do the vregsetc and you can remove the changing to byte mode etc in drawbanked, and you only need taht select function.

The code is locking up at the dosmemput, so you're probably writing to something improperly. If you comment that line out you can invisibly type sw_mode 0 and get back to 320x200

I agree. I was just updating and missed your previous message. I also tried Basic code which had a good implementation.

Edit: I see your commits now, thanks!

One of the Quake 1 functions for planar mode is: VGA_UpdatePlanarScreen, in d_copy.s file. The function has a comment:

1// copies 16 rows per plane at a pop; idea is that 16*512 = 8k, and since
2// no Mode X mode is wider than 360, all the data should fit in the cache for
3// the passes for the next 3 planes

It seems the easiest way to hook their "library" somehow, especially since it's in assembly.
Edit: here appears the other part:

1	if (pcurrentmode->planar)
2	{
3		for (plane=0 ; plane<4 ; plane++)
4		{
5		// select the correct plane for reading and writing
6			outportb (SC_INDEX, MAP_MASK);
7			outportb (SC_DATA, 1 << plane);
8			outportb (GC_INDEX, READ_MAP);
9			outportb (GC_DATA, plane);
10
11			for (i=0 ; i<(height << repshift) ; i += reps)
12			{
13				for (k=0 ; k<reps ; k++)
14				{
15					for (j=0 ; j<(width >> 2) ; j++)
16					{
17						backingbuf[(i + k) * 24 + (j << 2) + plane] =
18								lvid->direct[(y + i + k) * VGA_rowbytes +
19								(x >> 2) + j];
20						lvid->direct[(y + i + k) * VGA_rowbytes + (x>>2) + j] =
21								pbitmap[(i >> repshift) * 24 +
22								(j << 2) + plane];
23					}
24				}
25			}
26		}
27	}

Which contrasts with non-planar mode:

1		for (i=0 ; i<(height << repshift) ; i += reps)
2		{
3			for (j=0 ; j<reps ; j++)
4			{
5				memcpy (&backingbuf[(i + j) * 24],
6						lvid->direct + x + ((y << repshift) + i + j) *
7						 VGA_rowbytes,
8						width);
9				memcpy (lvid->direct + x + ((y << repshift) + i + j) *
10						 VGA_rowbytes,
11						&pbitmap[(i >> repshift) * width],
12						width);
13			}
14		}

I wonder if the planes were previously enabled:

1	// enable all planes for writing
2		outportb (SC_INDEX, MAP_MASK);
3		outportb (SC_DATA, 0x0F);

And this shows the way the buffer is filling I think:

1	VGA_planar = pcurrentmode->planar;
2	if (VGA_planar)
3		VGA_rowbytes = lvid->rowbytes / 4;
4	else
5		VGA_rowbytes = lvid->rowbytes;

Right, I've seen all this stuff (I may have missed the enabling planes write though, good catch). The biggest problem is I don't really understand all of it. I've never really done any sort of direct low level programming before and DOS VGA program is more or less a dead art now.

lvid->direct I assume is the actual vid.buffer. There is a separate branch where I tried to implement all this code over and ran into issues. Honestly, I'm just concerned about getting 320x240 in. The other weirdo modes like 320x256 (who uses that?!) can all get lost.

Is the 320x240 lfb mode supported by the older systems which could potentially run q2dos? If not, then I'm hoping that there is source code available with a better example of mode-x. Perhaps the demos. If the examples are not good, and the libraries are not useful, then the mathematics of the planar mode seems like a last resort. I mainly pasted the snippets above for future reference, they may be the one of the few working examples that are applicable.

I'm trying to avoid libraries entirely here. It's a matter of me not understanding and nobody here can hold my hand through it.

I have planar output some garbage now instead of just crashing.

Perhaps all the magic bits are lined up in the right order. :)

Google opened a gate with mention of demos: http://www.oldskool.org/demos/pc/modex.faq.

It's drawing a very small portion and is overlapping. So it's kind of close but the math is wrong and I don't understand it.

Anyways, its pushed if you want to play with it

Thanks, I'm looking forward to looking over the code!

Edit: attached an example from a demo, I think. The code looks actually interpretable.

The problem i have with all this stuff is that its drawing it pixel by pixel.

It loaded in dosbox-x better than vanilla dosbox. I'll try to compare it to other examples, hopefully ones that don't demonstrate writing by pixel.

Edit: using the VideoRegisterSet function was a good idea.

Edit: http://fly.srk.fer.hr/GDM/articles/vgamodex/vgamx1.html

I guess the math is all that's left, but this is insightful (320x200 example):

1 To implement paging we simply divide up our video memory into four sections, each 200 lines high and set the start address to the top of each page. For example, page 0 would have a start address of 0000h, page 1 would start at line 200 and would have a start address of 3E80h or 16000 (80 bytes per line * 200 lines) The next two pages would have starting addresses of 7D00h (32000) and BB80h (48000) respectively.
2
3Note that we only tell the VGA controller where the offset is in video memory, not the whole address. The VGA graphics screen still begins at segment A000h, however we are telling it to change where it starts reading in video data for display purposes. In our paging example above, our page 0 data is located at the absolute address of A000h:0000h, page 1 at A000h:03E80h, etc.

I pushed something with using id's code but it's all slanted. getting close i suppose.

Impressive! I'm still trying to imagine how it works. I'll take a look asap.

Should be simple to bypass, but I have this (I think it's byte versus char type):

1dos/vid_dos.h:22:14: error: redefinition of typedef 'pixel_t'
2dos/../ref_soft/r_local.h:76:23: note: previous declaration of 'pixel_t' was here

no it's defined twice, you can remove the pixel_t definition in vid_dos.h that was my mistake

It's very good progress. I can see almost an image, especially the console. The screen dimension is correct and there is the full screen, it's just the drawing routine that needs adjustment. The register bits must be all correct, too.

That was brilliant in adapting the q1 routine. I didn't think to swap out the buffer names.

Edit: the screen_offset is the only factor left?

I got it! With abrashes code!