On Mar 13,  2:32pm, "Eduardo E. Horvath  eeh@btr.com" wrote:
> Chris, have you made any changes to the source that are incompatible with 
> ld.old when you switched to the new ld?

  I don't think that would be the problem - I'm still using the old ld.

> > 	This was just the approach I was intending to take over the
> > next few days.  Would it be possible to clean up your debugging code
> > and get it committed to the tree?  Debugging is really painful before
> > printf is available, and it would be nice to have some color changes
> > to see how far booting is progressing.
> 
> I just sprinkled the code with:
> 
> *((short*)0xdff180) = 0x0f00;

  There's already a little routine called ROLLCOLOR that will set the
color for you, and delay a while.  I fixed it to work correctly when
I was trying to get the 68040 MMU initialized.

> After a very close examination of the source and assembly output, the 
> only conclusion I can come to is that the page table size is insanely 
> huge, and the loop starts scribbling into the custom chips and IO area of 
> memory.  Since most of my devices start going crazy, this obviously seems 
> to be happenning, but I can't see why.

  You could put a test in after pagetable_size is computed and check it for
a reasonable amount.  If it's too large (or negative), set the screen color
and hang in a loop.

> This whole thing is really a big mystery to me.

  To me too!

Michael

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

------------------------------------------------------------------------------