the /dev/realmode intraface was not documented, but it is very simple.
/dev/realmodemem is just an image of the first megabyte of
physical memory that is addressable from 16 bit realmode.
plan9 reserves a 4k page at 0x9000 (defined as RMBUF) that can be
refered to in the bios call as data
On Mon, Mar 07, 2011 at 11:39:10AM +0100, cinap_len...@gmx.de wrote:
the /dev/realmode intraface was not documented, but it is very simple.
Thank you for explaining this.
/dev/realmodemem is just an image of the first megabyte of
physical memory that is addressable from 16 bit realmode.
On Mon, Mar 07, 2011 at 11:39:10AM +0100, cinap_len...@gmx.de wrote:
/dev/realmodemem is just an image of the first megabyte of
physical memory that is addressable from 16 bit realmode.
That being where the machine's BIOS resides, if memory serves.
Plus whatever can fit in there if one
in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h)
(in x86 machine byte order?) containing the register contents and the
interrupt number of the bios call you want to make.
yes. you should use libmach to do this dirty work.
- erik
On Mon, Mar 07, 2011 at 07:23:36AM -0500, erik quanstrom wrote:
in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h)
(in x86 machine byte order?) containing the register contents and the
interrupt number of the bios call you want to make.
yes. you should use libmach to
On Mon, Mar 7, 2011 at 7:23 AM, erik quanstrom quans...@quanstro.net wrote:
in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h)
(in x86 machine byte order?) containing the register contents and the
interrupt number of the bios call you want to make.
yes. you should use
On Mon, Mar 07, 2011 at 09:19:58AM -0500, Russ Cox wrote:
huh? what does libmach (which takes apart executables)
have to do with any of this?
Did I get the wrong impression when I perceived libmach, as released
with GoLang - cause that's where I looked - seemingly quite capable of
huh? what does libmach (which takes apart executables)
have to do with any of this?
Did I get the wrong impression when I perceived libmach, as released
with GoLang - cause that's where I looked - seemingly quite capable of
synthesising as well as analysing binary images?
i think you did.
With the latest realemu, graphics and rio are finally working in my
VMware Workstation 6.5.1 guest:
% aux/vga -m vesa -p
vesa flagUlinear|Hlinear
vesa sigVESA 2.0
vesa oemV M ware, Inc. VBE support 2.0 2.0
vesa vendor VMware, Inc
vesa product
Cinap suggested invoking realemu in a subshell so that the
process exits after aux/vga completes. The following is a patch
for the man page.
-sl
% diff -n -c /sys/man/8/realemu.orig /sys/man/8/realemu
/sys/man/8/realemu.orig:84,89 - /sys/man/8/realemu:84,102
the
.I srvname
argument then
applied, thank you. also fixed some bugs in code:
properly convert the register values from the 386 ureg.
read back #P/realmodemem on every access as some graphics cards
use the a segment as memory mapped i/o. (Matrox MILLENNIUM)
we dont use #v/vgabios anymore and rely on #P/realmodemem to
yes, this started as 8i from russ. it was renamed to realemu after i
made it into a fileserver providing /dev/realmode and
/dev/realmodemem. this way i dont have to reimplement aux/vga's vesa
code and it can be used as drop in replacement. (just start it before
running aux/vga)
mkfile is fixed
mkfile is fixed now. will install itself into /$objtype/bin/aux/realemu
and install realemu (8) manpage.
impovement on the manpage is welcome as my english is not so good :)
Again, I'm delaying testing because I need to install a different
video card in the available hardware, but I'm
for everyone running realemu, please try with the new version to
see if i broke something.
Why TARG=qi in the mkfile (I would have guessed 8i, but I could be
wrong)? and I think the error:
term% mk install
cp 8.out $BIN/qi
rc: null list in concatenation
mk: cp
for everyone running realemu, please try with the new version to
see if i broke something.
the changes include:
switch back to textmode works now, as we use #P/realmodemem to
wite back changes to physical memory in the range B-A.
with realemu and the patch (see below), i'm able to
completed realmode emulator that is to be used with aux/vga -m vesa ...
to enable the graphics card thru vesa bios in an attempt to make 8i
work (thanks russ ;-)).
tarball can be found in /n/sources/contrib/cinap_lenrek/realemu.tgz
needs the patch /n/sources/patch/vesa-softscreen-resize applied
On Tue Mar 1 19:23:42 EST 2011, cinap_len...@gmx.de wrote:
completed realmode emulator that is to be used with aux/vga -m vesa ...
to enable the graphics card thru vesa bios in an attempt to make 8i
work (thanks russ ;-)).
tarball can be found in /n/sources/contrib/cinap_lenrek/realemu.tgz
i'm sorry i've forgotten. what's the problem with unemulated vesa?
Going back and forth to 16 bits does not make thing faster exactly. It will be
even more fun in 64bits. 16-32-64...
G.
On Tue Mar 1 19:49:36 EST 2011, pau...@gmail.com wrote:
i'm sorry i've forgotten. what's the problem with unemulated vesa?
Going back and forth to 16 bits does not make thing faster exactly. It will be
even more fun in 64bits. 16-32-64...
is that an issue? the only time that vesa bios
the real realmode is shoot and pray. it might just crash the machine
or do wired things like reenable interrupts or even try to switch
itself to protected mode.
with realemu, you might get a messed up screen, but plan9 is still
running. in case the vesa bios did wired stuff that caused plan9 to
no, speed was never a concern for realemu.
--
cinap
---BeginMessage---
On Tue Mar 1 19:49:36 EST 2011, pau...@gmail.com wrote:
i'm sorry i've forgotten. what's the problem with unemulated vesa?
Going back and forth to 16 bits does not make thing faster exactly. It will be
even more fun
you can also use it as a reverse engineering tool for
writing graphics drivers :)
--
cinap
On Tue Mar 1 20:18:04 EST 2011, cinap_len...@gmx.de wrote:
you can also use it as a reverse engineering tool for
writing graphics drivers :)
that could be a very interesting applicaiton.
- erik
On Tue Mar 1 20:07:19 EST 2011, cinap_len...@gmx.de wrote:
the real realmode is shoot and pray. it might just crash the machine
or do wired things like reenable interrupts or even try to switch
itself to protected mode.
with realemu, you might get a messed up screen, but plan9 is still
yes, i had one that did this as its first thing then chained into some
other bios call.
i have to look... i might still have the trace log.
i do no attempt in detecting bad stuff. its perfectly valid to enable
interrupts in the emulator... there are no interrupts in the virtual
machine right
this is from Fish-'s NSC Geode GX2:
00 4f00 9000 fffa
c000 cszopdi 00a8 cd INT $6d
00 4f00 9000 fff4
c000 cszopdi 00e5 fb STI
01 4f00
On Tue Mar 1 20:36:48 EST 2011, cinap_len...@gmx.de wrote:
yes, i had one that did this as its first thing then chained into some
other bios call.
i have to look... i might still have the trace log.
i do no attempt in detecting bad stuff. its perfectly valid to enable
interrupts in the
On Tue Mar 1 20:44:40 EST 2011, cinap_len...@gmx.de wrote:
this is from Fish-'s NSC Geode GX2:
00 4f00 9000
fffa c000 cszopdi 00a8 cd INT $6d
00 4f00 9000
in coreboot we went with an emulator instead of dropping to 16-bit and
running the bios. We did run 16-bit code directory for a few years (I
wrote that bit), but it's just too dangerous to trust a vga bios. I
think if a BIOS has to support VGA bios with an emulator then an OS
should do the same.
Don't forget platforms != x86; an emulator would be needed on ARM (say) if a
PC-like graphics chip found its way over there. I believe X has had such a
beast (x86emu?) and used it heavily on PPCen.
-- vs
On Tue Mar 1 22:10:13 EST 2011, m...@acm.jhu.edu wrote:
Don't forget platforms != x86; an emulator would be needed on ARM (say) if a
PC-like graphics chip found its way over there. I believe X has had such a
beast (x86emu?) and used it heavily on PPCen.
the kw openrd in fact does have a
there would have to be some more stuff to add to get it working on
non pc hardware. like setting up the virtual interrupt vector table.
we currently just get a copy of the first megabyte of physical memory
thru '#v/vgabios' or '#P/realmodemem' wich contains the real ivt of
the host pc that was
32 matches
Mail list logo
