[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Proposed modification to k_init.c (XaAES)



Hi,

The video-initialisation code for the Falcon has a "feature" which is kind of annoying if you implement a new graphics card.

Please have a look at the following code:

				/* Ronald Andersson:
				 * This should be the method for falcon!
				 */
				nvmode = vcheckmode(cfg.videomode);
				if ((nvmode & (1 << 4)) &&	/* VGA_FALCON */
				    (nvmode & 7) == 4)		/* is 16bit */
				{
					nvmode &= ~(1 << 3);		/* Set 320 pixels */
				}

				work_out[45] = nvmode;
				mode = 5;

In short, it forces a 40 column mode in 16bpp colour depth when using VGA monitors.

1. Why should XaAES make assumptions about this stuff? I guess it is to prevent the user from making mistakes, but if you put a screen enhancer (centscreen, blowup etc) into the equation,
the user is still perfectly capable of making similar mistakes anyway.

2. Why does it only prevent 80 column hicolor modes, and not 40 column monochrome modes (which are also illegal)?


On the SuperVidel, we're using bit 14 to indicate extended resolutions, and bits 9-13 to specify a "base resolution". The "standard" modecode bits are then used to modify this resolution (double line, double pixels) and to specify colour depth. Unfortunately, since we've aimed to re-use existing bits instead of re-inventing the wheel again, the code above interferes with this approach, forcing horizontally double-sized pixels in all hicolor modes.

As a temporary solution, I can use a workaround and filter the VGA-bit in my VcheckMode()-implementation if I find an XaAES-cookie. This is not pretty, however.

So what to do? I see a couple of options:

1. Remove the following code:

				if ((nvmode & (1 << 4)) &&	/* VGA_FALCON */
				    (nvmode & 7) == 4)		/* is 16bit */
				{
					nvmode &= ~(1 << 3);		/* Set 320 pixels */
				}

- this allows users to set an illegal resolution on VGA, but they are perfectly capable of doing so even with the presence of that code.
- removal of this code seems like the neatest solution for our purpose, since that means we don't need special treatment for our stuff.

2. Add checks for CTPCI & SuperVidel-cookies and implement dedicated code for them.
- honestly I don't like this approach at all, but that's how it's done on the Milan & Nova

3. Force monkey-style workarounds in my code
- honestly I like this even less, naturally :-D


Comments? Or can I make a patch for this and live happily forever after?

best regards

-- PeP