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
index | next in thread | previous in thread | raw e-mail
> > > 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 Pialkinhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609201110.PAA19509>