> Video address 0x50100700 -> 0xb80700.

This does look like an odd video address.  I'd be surprised if the video
RAM was really there.  I'll poke around the developer notes tonight and
see what I can glean from the whitespace between the lines...  ;-)  I've
been skimming those notes occasionally over the last few days, and they
are rather sparse in the first couple of chapters.

> 	Note that, as the machine starts executing the kernel image,
> 	there is a blast of noise from the Quadra's speaker.

Ugh.  That's not good--something is poking around in the sound chip?

> 	Bob suspected that the Video address 0x50100700 is bogus,
> 	and that a memory clash was over-writing the ROM vectors.

That's possible--if you're using the serial console, though, it
shouldn't even being writing into video RAM (unless something's
changed in that regard).

> 	Because this particular machine has VRAM which is shared between
> 	main monitor and video I/O systems (and possibly DSP), I am
> 	inclined to accept that some addresses could move around a lot.

Quite possible.

> ...the MCA maps the ROM code to the lower end of RAM address space, starting
> at address $0000 0000. When the main processor is reset, it sets the program
> counter to the 32-bit address found at $0000 0004, which transfers execution
> to the actual system software entry point in the space $4000 0000 to
> $4FFF FFFF. After this first access, ROM is no longer mapped to the bottom
> of RAM space

This is actually common to all macs that I've run across.  That and the
address for via1 seem to be about the only constants...  ;-)

> -------	Does anyone know what sort of MacOs code fragment I need to run
> 	to poke around at the Video base addresses?

I don't remember the call, but it might be nice to see what the physical
addresses for 0x50100000 - 0x50101000 (or so) are.

Can you try the ftp://ftp.macbsd.com/pub/outgoing/briggs/for.scampbel
kernel?  The SCSI, at least, has a chance of working for you...

> 	The Developer Notes for the LC575 are actually quite helpful.
> 	Video stuff:

Yeah.  They are!  Kudos to whoever at Apple was responsible for these
notes--they're a good _start_...  ;-)

> The PrimeTime IC combines functions performed by several ICs in previous
> Macintosh designs. The PrimeTime IC includes
> The PrimeTime IC provides the data bus features of the MC68030 that the
> MC68040 does not provide. Those features are byte steering, which allows
> 8-bit and 16-bit devices to be connected to a fixed byte lane, and dynamic
> bus sizing, which allows software to read and write longwords to 8-bit and
> 16-bit devices. Thos features allow the computer to work with existing I/O
> software designed for the MC68030.

This last bit is nifty.  I think that it can be exploited to ramp up
SCSI performance on the machines with PrimeTime (C/Q6X0/Q800 and
similar machines like the LC575, apparently).  Unfortunately, the
Q700/900/950 can't take advantage of this (but we might be able to
something with "A/UX interrupts"...).

> 	I ftp'd the files mklinux-1.0DR2.{linux.src,mklibs,osfmk,tools}.tgz
> 	in the hope that there would be some driver code for my machine.
> 		(I read somewhere that there was little difference
> 		 between the 660 and 6100, 840 and 8100 machines)

The DMA, at least, might be similar to the 840AV--I really don't know.
The Cuda driver will probably be helpful for getting support for more
devices into the ADBTEST kernels.  There may be a few other goodies in
there--sounds?  power control?).

-allen

-- 
              Allen Briggs - end killing - briggs@macbsd.com