Subject: Re: grf_cl.c tested on A2000+Spectrum1MB
To: Sascha Groening <groening@fmi.uni-passau.de>
From: Michael L. Hitch <osymh@gemini.oscs.montana.edu>
List: amiga-dev
Date: 02/05/1995 10:50:20
On Feb  5,  1:12pm, Sascha Groening wrote:
> btw. cp netbsd /dev/reload does not work for me...
> I just ge a black screen , or was it dark grey (?).
> I have to mount BFFS from AmigaDOS, copy the new kernel to AmigaDOS and
> boot with loadbsd -a -c 2000 netbsd 
> Anyone got the same problems ?

  If locore.s changes any, /dev/reload won't work (most of the time).  The
problem is that the kernel restart code relies on the old code (in the
running kernel) EXACTLY [mostly] matches the same code in the new kernel.
After the new kernel is copied to chip memory, the MMU is shut off, so
the CPU begins execution of the new code in chip memory at that point.

  I tried once to move the restart code to the beginning of locore.s, but
then the kernel wouldn't even boot.  I didn't pursue that problem, since
it's easy enough to just reboot to AmigaDOS and loadbsd the new kernel.

> Spectrum memory
> grf_cl: zap->size 2097152          <--- !!!! my Spectrum does not have 2MB

  Does this mean that the Spectrum configures 2MB of memory space, even
if it only has 1MB?  GVP strikes again!!

> grf3 at grfcl0: width 0 height 0 colors 0   <--- !?!
> ite at grf3 not configured                  <--- !?!

  Did you read the README?

> sounds quite good to me...
> but if I try to toggle, I just get a black screen.
> If I toggle twice I get the normal console back
> must be something like black on black.

  The README states that the Spectrum with 2MB is supported - it doesn't
say anything about support the 1MB board.

>                                 printf("Spectrum memory\n");
>                                 printf("grf_cl: zap->size %d\n", zap->size);
>                                 printf("grf_cl: zap->slot %d\n", zap->slot);
>                                 printf("grf_cl: zap->serno %d\n", zap->serno);
>                                 printf("grf_cl: zap->pa %x\n", zap->pa);
>                                 printf("grf_cl: mapped zap->pa %x\n", ztwomap(zap->pa));
>                                 printf("grf_cl: zap->va %x\n", zap->va);
>                                 printf("grf_cl: mapped zap->va %x\n", ztwomap(zap->va));
> 
>         /* Ezy, why do this here? is zap->size incorrect? Are there Spectrum
> with 1MB avail? ill */
> 
>         /* YES !!! Changed from 2MB -> 1MB        */
>         /* ... at least it works fine for me -SG- */

  Does the 1MB Spectrum start at the same location within the 2MB configured
area, or might it possibly start at the 2nd MB?

>                                 cl_fbsize = 1024*1024;
>         /* needs to be mapped to ztwo adress             */
>         /* dont know how to handle this with zthree -SG- */

  Zthreebus should have already mapped it - and the current kernel does
away with separate ztwo/zthree bus configuration and should handle the
mapping in a consistant manner.

>                                 zap->va = cl_fbaddr = ztwomap(zap->pa);

  Ztwomap() won't work - the 1.0 kernel only maps the Zorro II I/O address
space (the 64K segments from 0xe90000 through 0xef000000).  Take a look at
the Picasso handling in amiga_init.c and grf_cl.c.

>         /* was a break -SG- */
>                                 return(0);

  Uh - doesn't a return(0) indicate an error?  This routine looks like it
returns 1 if everything is OK.

>          ...................
> 
>   return(1);
    ^^^^^^^^^^
  I.e. right here/

> Markus:  I'm new to NetBSD so I don't know how to handle ztwomap and
> 			zthreemap properly and 1MB<->2MB properly , but I think some 
> 			#IFDEF SPECTRUM1MB
> 			would do fine
> 			If you've got something new, let me know...

 It would be much better to make the driver work with either 1M or 2M
dynamically.  If the 1MB board really indicates the memory space is 2M,
perhaps the driver will have to test the memory to see if all 2M is
present and adjust the size accordingly.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA