Re: mint & matgraph 1208

[hohmuth@inf.tu-dresden.de (Michael Hohmuth)]

Juergen Rose wrote:

> Neither in MiNT 1.12h2- nor in MiNT 1.12h3-Version a patch was considered,
> which is essential, if graphic cards are used. At least it es necessary, if you
> use the MatGraph TC1208-card. Without this patch the most of the alphanumeric
> output will not redirected by REDIRECT.PRG of NVDI to the graphic card. This
> concerns also the Login-Prompt of MiNTOS.
> So you need this patch necessary if you want to work with MiNTOS.
> To be exactly, without the patch the output of c_conws() goes beside of
> existence of REDIRECT.PRG in the AUTO-folder to the VGA-interface. On the other
> hand the output of Cconws() e.g. "MiNT is Now TOS..." goes to the monitor at
> the graphic card.
> 
> I got a mail from Helmut Hahne @ MS with a patch by Juergen Orschiedt @ KA2.
> I try to translate this mail:
> .......
> I have also the Matrix card (TC1208) and of cause NVDI. The problem mentioned
> by you is not a problem of the graphic card or the driver, but a problem of
> MiNT. There is a missing test, whether there is a grafic card.
> 
> Here is the patch:
> -----------cut here----------
> scrnplace = (long)Physbase();
> #if 1
> /*
> *   Juergen Orschiedt @ KA2
> *   For graphic cards
> *   include in mem.c, line 272
> */
> #define v_bas_ad    (*(ulong*)0x44eL)   /* Added: jo */
>     if ((long) v_bas_ad > scrnplace)    /* Added: jo */
>         scrnplace = (long) v_bas_ad;    /* Added: jo */
> #endif
> 
> [...]

I can't quite imagine how this patch can fix the problem.  Obviously,
Physbase() returns the base address of the ST screen (why?) while
*(ulong*)0x44eL contains the base address of the graphics card screen.
REDIRECT.PRG failing to redirect BIOS output to the graphics card must
be an unfortunate effect of the various Setscreen()s happening if
Physbase() points to ST memory.  Now tell me whether MiNT or NVDI or
REDIRECT.PRG is at fault.  :-)

I don't know what the best way to fix this is.  Perhaps the calls to
Physbase() should generally be replaced by derefences of 0x44eL?

Michael
-- 
Email: hohmuth@inf.tu-dresden.de
WWW:   http://www.inf.tu-dresden.de/~mh1/