> > Perhaps not _that_ minimal, since the Eclipse needs a proper MMU setup
> > to work (well, at least if you want to access the frame buffer directly).
> >
> So there's no way to access it without using the MMU? Not even with only 4Mb
> ST-RAM?
You can of course do the same job by hand that the MMU code normally does
for you. Just about the only thing you can't do easily that way is fast
direct accesses to the frame buffer. It's 'just' a matter of modifying an
Eclipse configuration register whenever you need access to another 'bank'.
I've not looked at the X mach64 driver, but the only good reasons for direct
frame buffer accesses are usually blits from the screen and possibly 'random'
writes of some kind (such as circle drawing). fVDI worked quite well for
most things even before the PCIBIOS was finished (without ever reading from
the screen except in pixel by pixel mode).
I don't know enough about the Eclipse hardware to say for sure if it would
be possible to make one large bank available at another physical address.
I don't think so, though.
> Btw. I noticed that you've released a special version of the TK-driver for
Yes. The main difference is support for external bus error handlers that
can modify the memory map, but to make that work well with all programs
we've also made a new vector table and changed the vector base register.
(IIRC, I did something with the VDI patch and/or NVDI recognition too.)
> this, have you tested this with memory-protection under MiNT?
I have actually never run with memory protection under MiNT since I got
my AB040, but I'll give it a try. The recent kernels are supposed to
handle that, right?
--
Chalmers University | Why are these | e-mail: rand_at_cd.chalmers.se
of Technology | .signatures | johan_at_rand.thn.htu.se
| so hard to do | WWW/ftp: rand.thn.htu.se
Gothenburg, Sweden | well? | (MGIFv5, QLem, BAD MOOD)
Received on ti. aug. 03 1999 - 20:20:04 CEST