fix initializtion (pr#1853) from Ignatios Souvatzis

This commit is contained in:
chopps 1995-12-27 07:21:07 +00:00
parent dafae56a80
commit 05ab6375cc
1 changed files with 46 additions and 8 deletions

View File

@ -1,4 +1,4 @@
/* $NetBSD: grf_ul.c,v 1.8 1995/11/30 00:57:01 jtc Exp $ */
/* $NetBSD: grf_ul.c,v 1.9 1995/12/27 07:21:07 chopps Exp $ */
#define UL_DEBUG
/*
@ -273,10 +273,7 @@ ul_load_code(gp)
/* font info was uploaded in ite_ul.c(ite_ulinit). */
/* unflush cache, unhalt cpu -> nmi starts to run */
ba->ctrl &= ~(HLT|CF);
#if 0
#if 1
/* XXX load image palette with some initial values, slightly hacky */
ba->hstadrh = 0xfe80;
@ -293,17 +290,50 @@ ul_load_code(gp)
/*
* XXX load shadow overlay palette with what the TMS code will load
* into the real one some time after the TMS code is started above.
* This is a rude hack.
* into the real one some time after the TMS code is started below.
* This might be considered a rude hack.
*/
bcopy(ul_ovl_palette, gup->gus_ovcmap, 3*4);
/*
* Unflush cache, unhalt cpu -> nmi starts to run. This MUST NOT BE
* DONE before the image color map initialization above, to guarantee
* the index register in the bt478 is not used by more than one CPU
* at once.
*
* XXX For the same reason, we'll have to rething ul_putcmap(). For
* details, look at comment there.
*/
ba->ctrl &= ~(HLT|CF);
#else
/* XXX This version will work for the overlay, if our queue codes
/*
* XXX I wonder why this partially ever worked.
*
* This can't possibly work this way, as we are copyin()ing data in
* ul_putcmap.
*
* I guess this partially worked because SFC happened to point to
* to supervisor data space on 68030 machines coming from the old
* boot loader.
*
* While this looks more correct than the hack in the other part of the
* loop, we would have to do our own version of the loop through
* colormap entries, set up command buffer, and call gsp_write(), or
* factor out some code.
*/
/*
* XXX This version will work for the overlay, if our queue codes
* initial conditions are set at load time (not start time).
* It further assumes that ul_putcmap only uses the
* GRFIMDEV/GRFOVDEV bits of the dev parameter.
*/
/* unflush cache, unhalt cpu first -> nmi starts to run */
ba->ctrl &= ~(HLT|CF);
gcm.index = 0;
gcm.count = 16;
gcm.red = ul_std_palette + 0;
@ -810,6 +840,14 @@ ul_putcmap (gp, cmap, dev)
/* then write from there to the hardware */
ba = (struct gspregs *)gp->g_regkva;
/*
* XXX This is a bad thing to do.
* We should always use the gsp call, or have a means to arbitrate
* the usage of the BT478 index register. Else there might be a
* race condition (when writing both colormaps at nearly the same
* time), where one CPU changes the index register when the other
* one has not finished using it.
*/
if (mxidx > 4) {
/* image color map: we can write, with a hack, directly */
ba->ctrl = LBL;