Peter Stewart wrote:
Hi,
Sorry for using up mail space, but here is the cocoa.m file.
enjoy,
peter.
Thanks amillion!
I will try it out tomorrow.
Hope I too can produce a Patch soon, so there is not to much
unneccessary work mergin bits'n'peaces :)
Mike
___
Hi,
Just added Mike's keyboard fixes, so I could run doom.
Built and installed doom, it runs pretty well. It actually runs better
than I expected, pretty cool.
Thanks for the .img.
peter.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://
Hi,
Sorry for using up mail space, but here is the cocoa.m file.
enjoy,
peter.
/*
* QEMU Cocoa display driver
*
* Copyright (c) 2005 Pierre d'Herbemont
*many code/inspiration from SDL 1.2 code (LGPL)
*
* Permission is hereby granted, free of charge, to any person
o
Hi,
Sorry, kind of new at this...
Here is the diff -u version of cocoa.m, I guess you got the
Makefile.target fix :-)
diff -u cocoa.m.orig cocoa.m > cocoa.m.diff
enjoy,
peter.
--- cocoa.m.origSat May 21 17:19:45 2005
+++ cocoa.m Mon May 23 19:24:00 2005
@@ -37,16 +37,23 @@
Could you use diff -u please? that surely could help.
Thanks,
Hetz
On 5/23/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote:
> Peter Stewart wrote:
>
> > Hi,
> >
> > It looks faster than the original, but I don't have a benchmark, is
> > there one?
> > I would really like a bootable image with Doo
Peter Stewart wrote:
Hi,
It looks faster than the original, but I don't have a benchmark, is
there one?
I would really like a bootable image with Doom 1 on it.
http://www.kberg.ch/cocoaqemu/files/freedosdoom.img.zip
have fun
Here is the diff for cocoa.m ( diff cocoa.m.orig cocoa.m ) (from
Hi,
It looks faster than the original, but I don't have a benchmark, is
there one?
I would really like a bootable image with Doom 1 on it.
I also added to Makefile.target, the "-framework OpenGL" bit.
ifdef CONFIG_COCOA
VL_OBJS+=cocoa.o
COCOA_LIBS=-F/System/Library/Frameworks -framework Coco
$B0lK|1_J,!*40A4L5NA$G;HMQ(BOK
$B"#:#$J$i4V$K9g$&(BW$B%A%c%s%9!*L5NA%]%$%s%H%"%C%W3Z$7$5(B100$BG\!*"#(B
$B"([EMAIL PROTECTED](B
$B0l0L!'5U1g!J(B189$BL>EPO?!K(B
$BFs0L!'1g8r!J(B429$BL>EPO?!K(B
$B;00L!'(BSM$B5U1g!J(B243$BL>EPO?!K(B
$B;M0L!'%;%U%l!J(B1038$BL>EPO?!K(B
$B8^
Am Samstag, 21. Mai 2005 18:14 schrieb Damien Mascord:
Hi!
I tried to start qemu in nongraphical mode. This results in the following
error message:
qemu: could not open monitor device 'stdio'
What kind of monitor device can I use with mingw?
regards,
Jörg
--
Hi! I'm a .signature virus! Co
On Sun, 2005-05-22 at 16:49 +0300, Tero Kaarlela wrote:
> J. Mayer wrote:
>
> >> 2. on debug 2. What is this unaffected IO port 838 it tries to read &
> >>write ?
> >>
> >>
> >
> >This port is not documented in the PREP specification. You should check
> >in the Linux kernel to see if this p
On Mon, 2005-05-23 at 10:31 +1000, Benjamin Herrenschmidt wrote:
> > console=ttyS0 console=tty0
> > Note that the Open-Firmware frame-buffer support is broken in many 2.6
> > kernels (I mean on real Macs)
>
> How so ?
Well, there have been many issues with frame-buffer in 2.6, not only on
Mac pl
On Mon, 2005-05-23 at 12:47 +0200, J. Mayer wrote:
> On Mon, 2005-05-23 at 10:31 +1000, Benjamin Herrenschmidt wrote:
> > > console=ttyS0 console=tty0
> > > Note that the Open-Firmware frame-buffer support is broken in many 2.6
> > > kernels (I mean on real Macs)
> >
> > How so ?
>
> Well, there
On Sun, 2005-05-22 at 22:07 +0300, Tero Kaarlela wrote:
> Hi,
>
> I just browsed CVS repository and found following from ppc_prep.c:
>
>
>
> /* Check LE mode */
> if (val & 0x02) {
> printf("Little Endian mode isn't supported (yet ?)\n");
> abort();
>
On Sun, 2005-05-22 at 16:49 +0300, Tero Kaarlela wrote:
> J. Mayer wrote:
>
> >> 2. on debug 2. What is this unaffected IO port 838 it tries to read &
> >>write ?
> >>
> >>
> >
> >This port is not documented in the PREP specification. You should check
> >in the Linux kernel to see if this p
> Le dimanche 22 mai 2005 à 01:26 +0200, Herbert Poetzl a écrit :
> > On Sat, May 21, 2005 at 07:32:11PM +0200, Jérôme Warnier wrote:
> > > I'm trying to build qEmu v0.7.0 on Debian Sarge on a Sparc64 machine,
> > > and it fails with strange errors.
> > > Does anybody here have any idea to help m
Peter Stewart wrote:
Hi Hetz,
I will do a comparison, and a diff, and add some more comments.
Great, I can't wait to merge and test it :)
I have a 800Mhz ibook 640M. When I ran Knoppix, and glxgears I got
7fps on OpenGL profiler and 5fps reported by glxgears. OpenGL profiler
reported tha
hello,
qemu has -loadvm and -snapshot but I don't like having to take care of
using the right vm dump with the snapshot, and having to think to
savevm to the right file when I commit the disk.
What do you think of snapshot/commit (or an additionnal equivalent
command) working with full state ?
_
Hi Hetz,
I will do a comparison, and a diff, and add some more comments.
I have a 800Mhz ibook 640M. When I ran Knoppix, and glxgears I got 7fps
on OpenGL profiler and 5fps reported by glxgears. OpenGL profiler
reported that a maximum of 5% of the time was being spent in OpenGL. On
average ab
Am Montag, 23. Mai 2005 08:55 schrieb Joerg Platte:
> OK, now I tried gcc-3.3. Qemu does not really crash any more, but the
> behaviour is still different compared to the precompiled version. My
This was a mistake. I did not change the path in my skript. Now my version and
the precompiled versio
Peter Stewart wrote:
Hello to all,
esp. Pierre d'Herbemont,
I have changed cocoa.m (0.7.0) to use openGL with very fast texturing.
I removed the use of QuickDraw. The DisplayState data is now DMA'd to
the graphics card instead of copied by the CPU. This uses apple's
texture range extensions
Am Samstag, 21. Mai 2005 18:14 schrieb Damien Mascord:
> You are probably using GCC 3.4 for mingw rather than GCC 3.3.
>
> Try the 3.3 toolset, and see how you fare :)
OK, now I tried gcc-3.3. Qemu does not really crash any more, but the
behaviour is still different compared to the precompiled v
21 matches
Mail list logo