🚀 go-pugleaf

To: coco@pucc.princeton.edu
Reply-To: knudsen@ihades.att.com


>        I was going to be doing work w/ hundreds of tiny modules that
>would be linking and unlinking on the fly, so even when all was in memory,
>the 070 would be page faulting continuously.  The 340 is fast enough to

Is this page faulting for real?  I guess it is, if all those
modules each have their own process space.  But I thought the 070
just ran a full flat-out address space and didn't bother with all
that L2 mapping stuff.

>fix them.  All of my direct screen write code still works!

Yep.  Kev P and I were relieved this Spring to see that UME had no
problems.

>        The new ROMS try to boot from my HD before it is ready (Maxtor
>128meg), a slight delay would help :).  Break is also broken!  Any

I remember Kev P had to increase the delay in the MM/1 boot ROMs
too.  And I think he changed Break's effects too.  He's probably
reading this List and will get onto a fix.

>        Gcc really zips along!  Now if only the l68 defs libraries weren't
>brain damaged, it would be as fast as our Sun!  Fix the linker, add
>hardware scrolling, and this thing would really blaze!

What's the problem with the libs and linker?  I know the linker
has a neat hack for dealing with "far" data and subroutine  references,
to overcome the 070's lack of 32-bit relative addressing.
I'd expect the 68020 version of L68 to not bother with this,
since the compiled code can handle far addresses directly.
Is your problem that GCC and its linker can handle it, but L68
code modules are all set up for 68000?

I'd be much more interested in the 340 upgrade if I could compile
the improved 020-style C code.