[uae] Re: Pointer trails

  • From: "Keith G. Robertson-Turner" <uae-freelists@xxxxxxxxxxxxxxxxxxxxxxx>
  • To: uae@xxxxxxxxxxxxx
  • Date: Tue, 09 Mar 2004 06:16:30 +0000

On Tue, 2004-03-09 at 04:27, Richard Drummond wrote:

> On Monday 08 March 2004 11:08 pm, you wrote:
> > Well I think I've just confirmed your theory.
> 
> Great stuff! I now know when it is caused . . . if not precisely why. ;-)
> 
> It is, as I suspected, caused when the JIT is enabled but direct memory is 
> not. I see from your config, etc. you are allocating 128MB of ZIII memory. 
> This causes NATMEM to fail, because glibc cannot allocate a shmem segment 
> that large (32MB is the max). Try running UAE with 32MB of ZIII memory to 
> confirm this, please.

Sorry to disappoint you Rich, but ... no joy at 32MB either.

However, I get an *all-new* type of GFX special-FX now ... the pointer
paints nice black lines. Check the uae area of my website for the new
screenshots I've just taken. Shot 2 is what I get after switching
screenmodes from 16bit to 8bit and back again. What you can't see from
the screenshots is that the 8bit screen looked fine (no corruption
anyway). Also the following output on the console:

Fastmem (32bit): mapped @$10000000: 32 MB Zorro III fast memory
   Card 2 (ZorroIII) done.
JIT: Reverting to "indirect" access, because canbang is zero! 

Apparently it can't bang, which is pretty much how I feel after a few
pints :)

> Thanks for all your hard work testing this . . . Sorry. I should have 
> realized 
> what was causing this sooner.

No probs, but I don't know about "hard work" though. My next project's
gonna be hard - re-writing Tripwire from scratch (dumping STLPort &
crypto++, building against standard glibc and openSSL/beecrypt, adding a
QT GUI, and modernising the core code to use proper c++ constructs and
namespaces). And the really good news is I'm probably going to be a team
of "1" doing this. Great! No I'm not kidding.

> I've been meaning to rewrite the direct memory stuff to use mmap() and 
> friends 
> rather than shmget() etc to overcome this limitation. First, though, I'll see 
> if I can sort out what's causing the P96 problem when NATMEM is diabled.

I keep saying this but, I'm just really impressed that it's come this
far so quickly (since you started the experimental version). Kinda
awesome really. So don't feel like I'm nagging or anything ;-)

Anyway, I've got a "real" A4000T next door, so WTF am I complaining
about :)

-- 
Regards,

K.


Other related posts: