Date: Fri, 20 Sep 1996 15:10:43 +0400 (MSD) From: Alexey Pialkin <pialkin@abel.pdmi.ras.ru> To: sos@freebsd.org Cc: msmith@atrad.adelaide.edu.au, j_mini@efn.org, emulation@freebsd.org Subject: Re: New doscmd available for testing/munching Message-ID: <199609201110.PAA19509@abel.pdmi.ras.ru> In-Reply-To: <199609201045.MAA03725@ra.dkuug.dk> from "sos@freebsd.org" at Sep 20, 96 12:45:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > My 'conceptual model' for this went something like : > > > > > > - allocate 128K in the emulation process for screen memory. > > > - when vt is activated, copy the area that falls under the physical screen > > > memory to a temporary store. > > > - mmap the screen memory onto your emulation's buffer. > > > - copy your temporary store back. > > > - when vt is deactivated, reverse the process. > > > > Great.. The most funny thing that i am trying to do the same thing :( And no > > result.. BTW problem is with mmap the screen memory onto emulation buffer .. > > Somthing wrong there .. But what ? > > What I meant was that I don't think that we can do a mmap onto memory > thats is mapped directly to HW adressees, ask Dyson about this, he > will know how to if at all possible. There is nothing syscons has > to do with this, its strictly a vm problem... Sorry me - but what do you mean by directly HW access ? In all cases before using the direct access to 0xA0000-0xC0000 i must mmap() some part of /dev/mem for that.... > > > ... but I really don't know what happens when you mmap() screen memory > > > onto a section of your process' space that is already mapped. Or would > > > > As I said ask Dyson, I'n not sure this works at all in the curretn VM system... Thanx, for nice advise..... Letter is written. Alexey Pialkin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609201110.PAA19509>