Bochs x86 PC emulator

On Sat, Mar 02, 2002 at 03:26:40PM -0800, Stu Grossman wrote:
> I have a set of patches which allows the user to specify the device to use for
> emulating com1 (and possibly com2->4 later on).  You just add something like:
> 
> 	com1:	dev=/dev/ttyp6
> 
> to your .bochsrc file.
> 
> I also have some bug fixes for the serial code (SERIAL_ENABLE) that fixes a
> problem with the way select is being used.  Without this, output doesn't work
> (at least on Linux and FreeBSD).
> 
> So, 1) is anybody interested in the patches, and 2) where do I send them?
> 
> 			Thanks, Stu

We are always interested in patches, even more when they fix actual
problems/bugs we are experiencing.  You can send them directly on this
mailing list attached to your message if they aren't too big (below
20KB), otherwise you could send them directly to me or I guess Bryce and
we will make sure they are fowarded properly.

Thanks for this work!
-- 
EKS - Dave Poirier                               (instinc@...)
"may the hairs on his toes never fall out"           http://uuu.sf.net/
"The last good thing written in 'C' was Franz Schubert's 9th symphony."

On Sat, 2 Mar 2002, Stu Grossman wrote:

> I have a set of patches which allows the user to specify the device to use for
> emulating com1 (and possibly com2->4 later on).  You just add something like:
> 
> 	com1:	dev=/dev/ttyp6
> 
> to your .bochsrc file.
> 
> I also have some bug fixes for the serial code (SERIAL_ENABLE) that fixes a
> problem with the way select is being used.  Without this, output doesn't work
> (at least on Linux and FreeBSD).
> 
> So, 1) is anybody interested in the patches, and 2) where do I send them?

Cool!  I'm interested in the patches, and you can email them to me.
I take it you're using com port as a terminal.  Have you tried connecting
it to an actual modem on a raw serial port?

One minor point:

Since bochs isn't specific to any OS, I don't really like calling it com1,
since that name is so specific to DOS/Win.  Maybe serial0, serial1, etc.?  
The whole "floppya, diskc" thing has always seemed strange to me.  Or
maybe I'm just being picky.

Thanks,
Bryce

Bryce Denney writes:
 > On Sat, 2 Mar 2002, Stu Grossman wrote:
 > 
 > > I have a set of patches which allows the user to specify the device to use for
 > > emulating com1 (and possibly com2->4 later on).  You just add something like:
 > > 
 > > 	com1:	dev=/dev/ttyp6
 > > 
 > > to your .bochsrc file.
 > > 
 > > I also have some bug fixes for the serial code (SERIAL_ENABLE) that fixes a
 > > problem with the way select is being used.  Without this, output doesn't work
 > > (at least on Linux and FreeBSD).
 > > 
 > > So, 1) is anybody interested in the patches, and 2) where do I send them?
 > 
 > Cool!  I'm interested in the patches, and you can email them to me.

Coming up shortly.

 > I take it you're using com port as a terminal.  Have you tried connecting
 > it to an actual modem on a raw serial port?

I've not tried to make it work with a real (ie: physical) terminal.  The code
as such should work just fine on a hardwired line.  Making wiggle the modem
control lines would require a bunch of code to translate the 16554 register
settings into OS-specific stuff.  Not an inkling of that code exists at this
time.  (FYI, my primary interest is in debugging PC's which use the serial
ports as consoles (ie: servers, et. al.)).

 > One minor point:
 > 
 > Since bochs isn't specific to any OS, I don't really like calling it com1,
 > since that name is so specific to DOS/Win.  Maybe serial0, serial1, etc.?  
 > The whole "floppya, diskc" thing has always seemed strange to me.  Or
 > maybe I'm just being picky.

Agreed.  I also had some qualms about the name com1.  I decided to use that
anyway since a lot of hw doc, and many bios's refer to it by that name.  I'm
not married to the name though, so serial would be fine with me as well.

				Stu

Hello from Gregg C Levine normally with Jedi Knight Computers
I have. Once. I think I was trying to compile something that I ported
over from U*X land. It means there is a permissions, error, have Peter,
try to reinstall the whole blob. At least that is what I needed to do.
(Remember, I think it was a permissions error.)
-------------------
Gregg C Levine drwho8@...
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."=A0 Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: bochs-developers-admin@...
[mailto:bochs-developers-
> admin@...] On Behalf Of Bryce Denney
> Sent: Saturday, March 02, 2002 12:42 AM
> To: Bochs Developers
> Cc: Peter Tattam
> Subject: [Bochs-developers] Re: cygwin configure problem
>=20
> Has anyone seen this before when compiling in cygwin?  It looks like
the
> cygwin compiler is not installed right.  Or else some of those gcc
> arguments are incompatible with that compiler.
>=20
> Thanks,
> Bryce
>=20
>=20
> Peter Tattam wrote:
> > It barfs here.  Here's a transcript.
> >
> > $ sh .conf.win32-cygwin
> > loading cache ./config.cache
> > checking for gcc... gcc
> > checking whether the C compiler (gcc -mno-cygwin -DWIN32 -O6
> > -march=3Dpentium -mpentium) works... no
> > configure: error: installation or configuration problem: C compiler
> > cannot create executables.
>=20
>=20
>=20
> ---------- Forwarded message ----------
> Date: Sat, 2 Mar 2002 16:07:12 +1100 (EST)
> From: Peter Tattam <peter@...>
> To: Bryce Denney <bryce@...>
> Subject: Re: Bochs simulator - help wanted.
>=20
> On Fri, 1 Mar 2002, Bryce Denney wrote:
>=20
> > On Sat, 2 Mar 2002, Peter Tattam wrote:
> >
> > > On Fri, 1 Mar 2002, Bryce Denney wrote:
> > >
> > > > On Sat, 2 Mar 2002, Peter Tattam wrote:
> > > >
> > > > > is there vesa (VBE) emulator? It would be cool to have some
basic functions
> > > > > where you get a 256 or more colors & do 800x600 mode and
stuff.  I could
> give
> > > > > you a list of minimum emulation modes that would get something
working.
> It
> > > > > could be added to the VGA bios I guess.
> > > >
> > > > Peter,
> > > >
> > > > Please look at the recent mailing list archive.
> > > > http://bochs.sourceforge.net/mailinglists.html
> > > > http://marc.theaimsgroup.com/?l=3Dbochs-dev
> > > >
> > > > People have been talking about VBE in the last week, but I
haven't been
> > > > following the thread.  In fact I've had very little time for
Bochs work in
> > > > the last 3 months.  Fortunately, several other developers have
been
> > > > keeping the project alive and healthy.  You will probably get
more
> > > > informed answers if you send questions to the mailing list.  If
I know the
> > > > answer, I'll respond.
> > > >
> > > > I will take a look at the ENTER thing in the next few days.
> > >
> > > I have some compiler test programs which can verify if it's
working ok.
> > >
> > > I've downloaded cygwin & gcc, and the bochs source.  The configure
fails
> > > though.  Complains about gcc.
> >
>=20
>=20
> been following these instructions.
> >
> >
> > http://bochs.sourceforge.net/doc/docbook/alldocs.html
> > Click User Guide
> > Click Compiling on Win32 with Cygwin
> >
> > Cygwin is a free Unix-like environment for Windows written by Steve
> > Chamberlain and now maintained by RedHat, Inc. You can download it
from
> > http://www.cygwin.com. Because Cygwin supports the configure script and
uses GNU
> > gcc/g++, you can use the standard compile process. A few compiler
options
> > are needed, so it is best to use the configure shortcut script
called
> > .conf.win32-cygwin. Edit the shortcut script if you want to modify
the
> > configure options. Then, to compile in Cygwin, just type:
> >
> >   sh .conf.win32-cygwin
>=20
> It barfs here.  Here's a transcript.
>=20
> $ sh .conf.win32-cygwin
> loading cache ./config.cache
> checking for gcc... gcc
> checking whether the C compiler (gcc -mno-cygwin -DWIN32 -O6
-march=3Dpentium
> -mpentium) works... no
> configure: error: installation or configuration problem: C compiler
cannot create
> executables.
>=20
> >   make
> >
> > These options are known to work in cygwin, so they are enabled in
the
> > configure shortcut file:
> >
> >   --enable-cdrom
> >   --enable-sb16=3Dwin
> >
> >
> >
> > > I will check the source to see how you emulate the instruction and
> > > then compare with my experience.  Might save you a bit of time.
> > Yes that sounds good.
> >
> > -Bryce
> >
> >
>=20
> --
> Peter R. Tattam                            peter@...
> Managing Director,    Trumpet Software International Pty Ltd
> Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
>=20
>=20
> _______________________________________________
> bochs-developers mailing list
> bochs-developers@...
> https://lists.sourceforge.net/lists/listinfo/bochs-developers

>
>
>>>>>is there vesa (VBE) emulator? It would be cool to have some basic functions
>>>>>where you get a 256 or more colors & do 800x600 mode and stuff.  I could give
>>>>>you a list of minimum emulation modes that would get something working.  It
>>>>>could be added to the VGA bios I guess.
>>>>>
Basicly the bochs VBE 'emulator' consists out of 2 components:

* the Vesa Bios Extension (this is implement in the vgabios found in the 
CVS repository at http://savannah.gnu.org/projects/vgabios/)
* the bochs (host) side display code (this is NOT implemented yet, but 
should allow for higher resolutions & more colors)

Yesterday, I added the standard vgamode 13h (320x200x8) to the list of 
VBE supported modi. Since this mode is already supported by both bochs & 
the normal vgabios, we can 'trick' programs to actually display gfx 
output (using the VBE) until the bochs host side display code gets 
written. I have put a binary of this vbe bios at 
http://japj.org/projects/bochs_plex86/vbebios/

If you have a program/os/whatetever that:
1) can run in bochs
2) can display something in a 320x200x8 VBE mode
then you could try running it with the vbebios binary and see what it 
does (and please tell me too!)

Now, if I understand correctly then Petros/bochs 'fails' nr 1) at this 
moment. As long as it cannot run within bochs you won't be able to test 2)

If Petros *does* run in bochs and it supports 320x200x8 then I'm very 
interested in wether it can use the current VBE bios (since this will 
really put it to the 'test').

Hope that this is enough information for the moment?

Best regards,

Jeroen Janssen

On Sat, 2 Mar 2002, Jeroen Janssen wrote:

> >
> >
> >>>>>is there vesa (VBE) emulator? It would be cool to have some basic functions
> >>>>>where you get a 256 or more colors & do 800x600 mode and stuff.  I could give
> >>>>>you a list of minimum emulation modes that would get something working.  It
> >>>>>could be added to the VGA bios I guess.
> >>>>>
> Basicly the bochs VBE 'emulator' consists out of 2 components:
> 
> * the Vesa Bios Extension (this is implement in the vgabios found in the 
> CVS repository at http://savannah.gnu.org/projects/vgabios/)
> * the bochs (host) side display code (this is NOT implemented yet, but 
> should allow for higher resolutions & more colors)
> 
> Yesterday, I added the standard vgamode 13h (320x200x8) to the list of 
> VBE supported modi. Since this mode is already supported by both bochs & 
> the normal vgabios, we can 'trick' programs to actually display gfx 
> output (using the VBE) until the bochs host side display code gets 
> written. I have put a binary of this vbe bios at 
> http://japj.org/projects/bochs_plex86/vbebios/

I think this is the one I tried.

VBEBIOS  BIN        25,460  03-02-02  6:10p vbebios.bin


> 
> If you have a program/os/whatetever that:
> 1) can run in bochs
> 2) can display something in a 320x200x8 VBE mode
> then you could try running it with the vbebios binary and see what it 
> does (and please tell me too!)

If it reported a valid VBE mode in the list it would work.  However, my initial
test of the emulator showed that the list wasn't terminated correctly with a
0xFFFF (or it wasn't structured right - not really sure yet).

> 
> Now, if I understand correctly then Petros/bochs 'fails' nr 1) at this 
> moment. As long as it cannot run within bochs you won't be able to test 2)
> 
> If Petros *does* run in bochs and it supports 320x200x8 then I'm very 
> interested in wether it can use the current VBE bios (since this will 
> really put it to the 'test').

I only support 3 vga modes (640x200x4, 640x350x4, 640x480x4), not the 320x200x8
mode because I program the CRTC/VGA registers directly for these modes - the
code was done before I had the ability to call the bios from the kernel. 

I've got the kernel to run in bochs.  Ignoring the enter() traps and going via
floppy only. I have a kernel build that doesn't use a dword IDE controller (you
can ignore it, but the emulated controller doesn't work in 32 bit mode).  I
also had to redirect the log file to nul as it grew to 20 megs in < 1 minute on
my brand new P3 933Mhz test machine  :)

I have a test program which will cycle through all the reported VBE modes and
run a graphics test (fillrects of various sizes).  I can supply a boot floppy
image of this if you wish.  Also, I will see if I can implement the 320x200x8
video mode, even if it's just thunking to the bios to do it. The vga modes work
under bochs, but only with the regular vga bios - go figure.

> 
> Hope that this is enough information for the moment?

I think so.  Where are you up to in your emulation of the various VBE calls?  I
need the following.

AX = 0x4F00	- get vesa controller info.

	has to set the mode list mainly, also I check for VBE2 as per spec.
VBE2 is preferred as you can guarantee the list is in the same buffer that was
passed.

AX = 0x4F01	- get vesa mode info.

	needs to fill out a fair bit.
	if you can, return a flat mode, then there is no virtual frame buffer
	needed.  if the frame buffer is < 64K it will be mapped as a flat fram
	anyway.  We can test paged mode a little later.  I think 16 bit v86 
	emu apps will need it.

AX = 0x4F02	- set vesa mode

	all you need to do is set gfx mode with the frame buffer at the address
	reported by 0x4F01.


the following are optional - I can work around them.

AX = 0x4F03	- get vesa mode (I think this is called by my debugger)


AX = 0x4F05	- vesa window function (probably not used any more)

AX = 0x4F09	- get/set palette (bl = 0,1) (i think used to grab the mode).

> 
> Best regards,
> 
> Jeroen Janssen
> 
> 
> 

--
Peter R. Tattam                            peter@...
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

>
>
>I think this is the one I tried.
>
>VBEBIOS  BIN        25,460  03-02-02  6:10p vbebios.bin
>
Ok, if you try the vbebios.debug.bin you will get additional output from 
the vbe bios part in the bochsout.txt

>If it reported a valid VBE mode in the list it would work.  However, my initial
>test of the emulator showed that the list wasn't terminated correctly with a
>0xFFFF (or it wasn't structured right - not really sure yet).
>
Ok, the video_mode_list pointer should point to 0xc0604a (debug) or 
0xc05d86. Can you check if this is the case for you?
(or if possible, can you print out the modi in the list you are seeing?)

I previously had some problems with a test program that tried to read 
the list with a signed short (16bit) and after I changed it to use 
unsigned shorts it worked ok.

Better yet, is the source to your vesa code available so I can see what 
might be happening?

>>Now, if I understand correctly then Petros/bochs 'fails' nr 1) at this 
>>moment. As long as it cannot run within bochs you won't be able to test 2)
>>
>>If Petros *does* run in bochs and it supports 320x200x8 then I'm very 
>>interested in wether it can use the current VBE bios (since this will 
>>really put it to the 'test').
>>
>
>I only support 3 vga modes (640x200x4, 640x350x4, 640x480x4), not the 320x200x8
>mode because I program the CRTC/VGA registers directly for these modes - the
>code was done before I had the ability to call the bios from the kernel. 
>
what I meant to ask : does Petros support a VBE mode 320x200x8? (if it's 
available), if not what VBE modi does it 'need'/support?

>I have a test program which will cycle through all the reported VBE modes and
>run a graphics test (fillrects of various sizes).  I can supply a boot floppy
>image of this if you wish. 
>
Yes, I would very much appreciate that. Can you put it somewhere to 
download? (or if it's not too big, zip it and email it too me)

>> Also, I will see if I can implement the 320x200x8
>video mode, even if it's just thunking to the bios to do it. The vga modes work
>under bochs, but only with the regular vga bios - go figure.
>
Well, currently 320x200x8 VBE mode is 'setup' with the normal vga bios, 
the VBE bios should provide enough information for programs to 'think' 
there is a 320x200x8 VBE mode available with a LFB at 0xa0000.

>I think so.  Where are you up to in your emulation of the various VBE calls?  I
>need the following.
>
>AX = 0x4F00	- get vesa controller info.
>
present & should be working ok.

>AX = 0x4F01	- get vesa mode info.
>
>	needs to fill out a fair bit.
>
present, but I'm not sure if all fields are correctly filled in at this 
moment.
Currently it returns that there is only a LFB available - no banked mode 
(and in the case of 320x200x8, that is a LFB at 0xa0000)

>AX = 0x4F02	- set vesa mode
>
>	all you need to do is set gfx mode with the frame buffer at the address
>	reported by 0x4F01.
>
present & working (for 320x200x8 it actually should display on screen, 
all other modi are 'faking' that they succeeded)

>
>the following are optional - I can work around them.
>
those are not present yet

>AX = 0x4F03	- get vesa mode (I think this is called by my debugger)
>AX = 0x4F05	- vesa window function (probably not used any more)
>AX = 0x4F09	- get/set palette (bl = 0,1) (i think used to grab the mode).
>
---
Jeroen Janssen

I'll make a couple of petros images to demonstrate the enter() > 0
problem and the dword access to 0x1a0 problem (32 bit disk access).

Peter

--
Peter R. Tattam                            peter@...
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

On Sat, 2 Mar 2002, Peter Tattam wrote:

> I'll make a couple of petros images to demonstrate the enter() > 0
> problem and the dword access to 0x1a0 problem (32 bit disk access).

sorry, that should be 0x1f0.

> 
> Peter
> 
> --
> Peter R. Tattam                            peter@...
> Managing Director,    Trumpet Software International Pty Ltd
> Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
> 
> 

--
Peter R. Tattam                            peter@...
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

Hello from Gregg C Levine
Could someone enlighten me, as to what this "petros" thing is? I would,
of course, like to be included in this examination as to the behavior of
that Intel instruction. I have an idea as to what it does, something to
do with the NDP functions, but I am probably wrong.
-------------------
Gregg C Levine hansolofalcon@...
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."=A0 Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: bochs-developers-admin@...
[mailto:bochs-developers-
> admin@...] On Behalf Of Peter Tattam
> Sent: Friday, March 01, 2002 8:48 PM
> To: Bryce Denney
> Cc: Peter Tattam; Bochs Developers
> Subject: [Bochs-developers] Re: Bochs simulator - help wanted.
>=20
> On Sat, 2 Mar 2002, Peter Tattam wrote:
>=20
> > I'll make a couple of petros images to demonstrate the enter() > 0
> > problem and the dword access to 0x1a0 problem (32 bit disk access).
>=20
> sorry, that should be 0x1f0.
>=20
> >
> > Peter
> >
> > --
> > Peter R. Tattam                            peter@...
> > Managing Director,    Trumpet Software International Pty Ltd
> > Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
> >
> >
>=20
> --
> Peter R. Tattam                            peter@...
> Managing Director,    Trumpet Software International Pty Ltd
> Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
>=20
>=20
> _______________________________________________
> bochs-developers mailing list
> bochs-developers@...
> https://lists.sourceforge.net/lists/listinfo/bochs-developers
>=20

On Fri, Mar 01, 2002 at 08:53:24PM -0500, Gregg C Levine wrote:
> Hello from Gregg C Levine
> Could someone enlighten me, as to what this "petros" thing is? I would,
> of course, like to be included in this examination as to the behavior of
> that Intel instruction. I have an idea as to what it does, something to
> do with the NDP functions, but I am probably wrong.
> -------------------
> Gregg C Levine hansolofalcon@...
> ------------------------------------------------------------
> "The Force will be with you...Always." Obi-Wan Kenobi
> "Use the Force, Luke."? Obi-Wan Kenobi
> (This company dedicates this E-Mail to General Obi-Wan Kenobi )
> (This company dedicates this E-Mail to Master Yoda )

http://petros.trumpet.com.au/

PETROS is a new 32-bit operating system for the PC platform released by
Trumpet Software International Pty Ltd., based in Hobart, Tasmania.

PETROS has been created from first principles, allowing it to focus on
a small size and a modular approach. It is not intended to just create
yet another desktop environment, but rather one of the underlying design
concepts has been to create a system that would load faster and allow
better performance without the overheads of resource hungry facilities
or excessive feature creep. 

PETROS is an operating system that gives back to the user a greater
measure of control and influence over the processing that occurs whilst
they work. It is not a system that will bind the user of a desktop or
network to any particular architecture or application suite. It does not
require the user to learn another instruction set above what they are
already likely to be familiar with. 

(PETROS is a registered trademark of its respective owner, due to the
nature of text messages the registered trademark sign couldn't be
included).
-- 
EKS - Dave Poirier                               (instinc@...)
"may the hairs on his toes never fall out"           http://uuu.sf.net/
"The last good thing written in 'C' was Franz Schubert's 9th symphony."

On Sat, 2 Mar 2002, Peter Tattam wrote:

> One other thing.
> 
> Is there any kind of feature that allows one to access existing drives as
> read-only drives.  Or is there a utility that allows for easy copying of files
> to & from a FAT disk image?  (Guess I could write one, but if it's been done,
> why bother).   Win32 or DOS please.

Accessing existing drives...

Bochs can read real floppies and cdroms, but I think you're talking about
hard disks.  Somebody wrote a patch for win32 to access the physical harddisk
(http://sourceforge.net/tracker/index.php?func=detail&aid=451743&group_id=12580&atid=312580)
but we've been a little afraid to let Bochs touch the real hard disk
because of the risk of screwing it up.  I know, you said read only.  
Still, there hasn't been much activity in that direction.

The usual way of transferring files is what you mentioned second, which is
some program running on the physical machine (not inside bochs) that can
read and write the bochs disk image.  Mtools is usually what comes to
mind.  See http://bochs.sourceforge.net/links.html for links to mtools.

In the unix world, you can pretend the disk image is a raw disk and mount
it as a filesystem.  I haven't seen this kind of utility for Windows,
though it probably exists somewhere.

-Bryce


> 
> Peter
> --
> Peter R. Tattam                            peter@...
> Managing Director,    Trumpet Software International Pty Ltd
> Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
>

On Fri, 1 Mar 2002, Bryce Denney wrote:
> Basically, the message was intended to help us find test cases.  And to
> annoy us until we fix the problem.

I made it so that this warning will no longer fill up your hard disk.
This is only a temporary solution of course.
-Bryce

----------------------------
revision 1.9
date: 2002/03/01 17:27:25;  author: bdenney;  state: Exp;  lines: +8 -2
- the stack_return_from_v86 error is sometimes printed millions of times
  and produces a gigantic log file.  Now, after 100 times, it will no
  longer print any more of this particular error.
----------------------------