On Wed, 26 Aug 1998, Andrew Foakes wrote many things, some of which are
quoted here.

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.

> 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.

> Should I read any significance that the len variable is differenct from 
> the 0x8000 above?

Nope.  It's not a full (Mac OS) 32K page, as the check_video() code used
to imply.  The new code is much more careful about getting the offset and
length of the framebuffer correct.

> By the way, the reason it is 0x8000 and not 0x5580 is that mac68k_vidlen 
> is set to 21888 (512x342 bits in bytes) using the definitions earlier in 
> the file but check_video then changes this to 32768.

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

--scott

-> Get your official NetBSD-1.3.2 CDROM set today! http://www.netbsd.com/ <-