Hello again ...

Scott, Re:

> Before I get into this, I spent an hour or two over the last day and a
> half looking at this code and searching for clues in the relevant Apple
> documentation.  The Classic II devnote lists (probably incorrectly!) that
> the 32-bit address of the frame buffer is at 0x9f9a80.  I seem to recall
> that this was a typo, and that 0xfee09a80 is in fact correct.

Hmmm ...  but I thought the video gets mapped onto the 0xfee09a80 address 
to mimic a NuBus address sequence.  But here's another oddity.  If I 
change the 0xfee09a80 to 0x9f9a80 in machdep.c, pmap_bootstrap still 
tells me (just before it dies):

Video Address 0xfee09a80 -> 0xbf9a80

as the actual video address comes from videoaddr (which is grabbed from 
the booter).  When I  set videoaddr to 0x9f9a80 explicitly, but that just 
hanged completely!  (I'd hoped that the problem was something like a map 
0x9f9a80 -> 0xfee09a80 must be preserved when the map 0xfee09a80 -> 
0xbf9a80 was created, but obviously not.)  OK OK so I don't really 
understand any of this, but at least I'm trying :-(


Re:

>> I then replaced the line in machdep.c that prints out the "no internal 
>> video" with one to output the mac68k_vidlen variable.  But when I 
>> recompiled, I get:
>> 
>> On-board video at addr 0xfee09a80 (phys 0xfee09a80), len 0x5580
>> 
>> This wasn't the line I expected and comes from earlier in the machdep.c 
>> code.  Very strange - why does adding a printf line lower in the routine 
>> force if to output this line (something that it should have anyway as the 
>> Classic II should have the mac68k_vidlen variable set).
>
> This is strange!  I expect the `On-board video...' line on the Classic II.
> Changing the code further down shouldn't matter at all.  However, it'd be
> helpful to know which compilers are being used, here.  There are clearly
> egcs codegen bugs, so the stock (gcc-2.7.2.2) compiler should be used.

This is out of the box 1.3.2 for everything - compiler, source, the lot.

>On your system, since it's in the intvid_info[] array, check_video
>should never be in the code path.

Indeed.  I was trying to merge the 1.2 nased IntVidTest0.4 code with the 
1.3.2 code to get a Classic II to work.  My reading of the IntVidTest 
code is that it:

1.) stops get_pte being called for some PowerBook machines.  This didn't 
apply for the Cassic II, though.

2.) Stopped the NuBus aress space being searched.  But this code is in 
the 1.3.2 code except for the call to check_video.  I put it in in an act 
of desparation (and because it's obviously in the C2 1.3.2 kernel I'm 
currently using, judging by the output).

So now I think the 1.3.2 kernel should work on a Classic II, but doesn't!

Yours,

Andrew



* ---------------------------------------------------------------------- *
Running NetBSD version 1.3.2 on a Classic II
See http://www.foakes.demon.co.uk/NetBSD.html for details