Congrats on getting the 660AV working!  It's always exciting to see
progress being made.

> I did encounter some strangeness similar to the "if (danprint)"
> section in macrom.c's mrg_aline_super... I haven't really looked into
> it much, but I think setup_egret might have the same problem. If I put
> a printf that does something useful (like print the value of
> mrg_InitEgret) right after the "if (0 != mrg_InitEgret)" line,
> setup_egret will always succeed (well, it worked all of the
> approximately 15 times I tried it). If I put a printf("") there
> instead, it works most of the time, but it'll hang sometimes (7
> sucesses, 3 hangs, I think). If I completely remove the printf, it
> hangs all the time (only tried it that way twice though). If I turn on
> tracing, it looks like it's hanging right after the jbsr @a1; it never
> starts executing InitEgret. Any ideas on what's causing this? I
> haven't tried using a delay instead of a printf... maybe it's a weird
> timing thing.

It sounds like a cache flushing problem to me:  if you've updated the
trap vectors or constructed some glue code on the fly (please excuse
the vagueness and my general ignorance -- I haven't actually looked at
the MRG code) and then try to jump to it without flushing the caches,
it seems to me that you might end up executing old data.  Printf()
with a non-trivial format string calls a pile of subroutines to do the
formatting, which could cause enough cache activity that the updates
actually make it to RAM.

						Brian Johnson