re detected
by which, are installed anyway. This is of course not clean, but worked
for the time.
--
Joachim Henke
http://base91.sourceforge.net/j-o/
Im sorry, but I just found that a checking should be done in a more
proper way. Please additionally apply the attached patch after my
3DNow! patch.
Sorry again,
Jo.
On 29 Apr 2007, at 21:32, Joachim Henke wrote:
The attached patch adds the 3DNow! and extented 3DNow! instruction
sets to
test this with an old computer game,
etc...
I would appreciate any hints or suggestions.
Regards,
Jo.
--
Joachim Henke
http://base91.sourceforge.net/j-o/
3dnow.diff.gz
Description: GNU Zip compressed data
t the attached patch.
Thanks,
Jo.
--
Joachim Henke
http://base91.sourceforge.net/j-o/
gccconf.diff
Description: Binary data
/../../../libmx.dylib(single
module) definition of _lrintl$LDBL128
The attached patch works for me.
Kind regards,
Jo
--
Joachim Henke
http://base91.sourceforge.net/j-o/
softfloat.diff
Description: Binary data
idle.
Please use the updated patch below.
Sorry,
Jo.
Joachim Henke wrote:
Could you please check, if the attached patch works for you? A
quick test showed that Linux boots fine with the MONITOR flag set now.
This patch adds 'monitor' and 'mwait' as nops, as suggested
any kernel modules;
some being closed source. And if an mwait lurks somewhere in your
kernel, you might get a really obscure breakage that will be a pain
to debug...
--
Joachim Henke
http://he-jo.net/
___
Qemu-devel mailing list
Qemu-devel@
hen using kernel-
kqemu _and_ having the MONITOR flag set in the host cpuid. So I'm
sure, Fabrice would be able to do the trick - maybe by using the
hosts monitor/mwait instructions.
--
Joachim Henke
http://he-jo.net/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
lation in user space. Probably
someone else will come up with a better solution. Anyway, your last
suggestion looks good.
--
Joachim Henke
http://he-jo.net/
mwait_hlt.diff
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
: Attempted to kill init!
--
Joachim Henke
http://he-jo.net/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Try
zcat mwait.diff.gz | patch -p0
in the source directory.
Am 07.07.2006 um 14:57 schrieb maestro:
btw: when i patch < mwait.diff in the qemu-src directory patch cannot
find the files to patch and asks me for their location - did i do
anything wrong?
--
Joachim Henke
http://he-jo.
idle.
Please use the updated patch attached below.
Sorry,
Jo.
Joachim Henke wrote:
Could you please check, if the attached patch works for you? A
quick test showed that Linux boots fine with the MONITOR flag set now.
This patch adds 'monitor' and 'mwait' as nops, as su
...]
<0>Kernel panic - not syncing: Attempted to kill the id
--
Joachim Henke
http://he-jo.net/
mwait.diff.gz
Description: GNU Zip compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
d (right?). (At least the patch in the end
of that thread seems to already be included in the sources?)
So, my hypothesis is that there is some other feature that appears
in my host CPUID, which the booting linux image tries to make use
of, but which qemu does not emulate.
--
Joach
The attached patch
- fixes a wrong entry in the keycode translation map (0x9c = 156, not 152)
- adds some entries to support more keys on Apple USB keyboards
- changes keymap[] to be an array of bytes (saves some space)
- fixes a typo in a warning message
Kind regards,
Jo.
--
Joachim Henke
of
bounds
[event characters] returns an empty string for dead keys; so calling
[[event characters] characterAtIndex:0] will raise an
NSRangeException that crashes qemu. The attached patch fixes this
bug, and it also adds support for the keys Home, End, and Delete in
the monitor.
--
Joachim
lobally
available in 'gArgc' and 'gArgv' anyway.
Regards,
Jo.
--
Joachim Henke
http://he-jo.net/
cocoa-fix-1.diff
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
truction,
and also the MON CPUID flag must be added.
Fabrice Bellard wrote:
The problem is that it is not possible to trap on the CPUID
instruction :-( So the only possible patch is to support PNI in
QEMU. For monitor/mwait for example, doing nops should suffice...
Fabrice.
--
Joachim
tions (it detects them at least). So I would really appreciate
it, if someone could test this patch and/or give me links to programs
(Linux/Win98) that use SSE3 instructions (and preferably also prove
the results).
Thanks
Jo.
--
Joachim Henke
http://he-jo.net/qemu/
sse3-2006-02-18.dif
x27;s CVS. So try it, while it's
hot (c: Run QEMU with '-soundhw pcspk' and
Have fun!
Jo.
--
Joachim Henke
http://he-jo.net/qemu/
pc-speaker.diff.gz
Description: GNU Zip compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.
hose can't be reproducted --
instead significant distortion will be generated (google for
Nyquist frequency).
--
Joachim Henke
http://he-jo.net/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
programs, provided QEMU implements a precise cycle
counter (it will come someday !).
--
Joachim Henke
http://he-jo.net/
pcspk.diff.gz
Description: GNU Zip compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
ulate things as close to
reality as feasible. Why do more work & intentionally break the
close emulation, while it's even easier to acheive?
Many PC games used low frequencies to emit varius buzzes and stuff
(like engine noise). With sine wave those will be completely broken.
--
Jo
realistic. Then fixed
point calculation (16 bit integer part and 16 bit fractional) is
easy without all those sin calculation.
--
Joachim Henke
http://he-jo.net/
pc_speaker.diff.gz
Description: GNU Zip compressed data
___
Qemu-devel mailing l
malc wrote:
> I'd like to not one thing, namely, you are using FPU to generate the
> samples. This is something Fabrice expressed dissatisfaction with. In
> the case of speaker it might be feasible to switch to fixed-point
> calculation.
--
Joachim Henke
http://he-jo.net/
Lust
gs: you try to write N bytes, AUD_write
returns zero, yet you are tring again immediately - ad nauseam. We
have only one thread - hence audio can not push the data out of
internal buffers into the host, and what you get is an infinite loop.
--
Joachim Henke
http://he-jo.net/
pcspeaker.diff.gz
I forgot to mention, that you must call QEMU with the switch '-
soundhw pcspk' to enable PC speaker emulation.
Sorry
Jo.
Joachim Henke wrote:
Ok, here is it - my first attempt for emulating the PC speaker
using the audio API. This needs some testing, tough it seems to
work well
ll, if speaker is switched on */
+if (spk_off & speaker_data_on)
+ puts("*beep*\a");
}
--
Joachim Henke
http://he-jo.net/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Hi Paul,
I already reported this on 2006-01-02 (see http://lists.gnu.org/
archive/html/qemu-devel/2006-01/msg00015.html), but since there was
no response and it's still broken in your repository, I assume that
your spam filter dropped my e-mail. Your hand-written code generator
fails to co
Hi Paul,
I just had a short look at your hand written code generator
(https://nowt.dyndns.org/cgi-bin/svn-qop-diff) and did some quick tests
with the i386-softmmu target on my iMac G5 (Mac OS 10.4.3). Before I could
successfully compile the code, I needed to apply a small fix:
--- host-ppc/qop-co
In the meanwhile I did some more fixes and improvements over the patch I
posted on December 27th. Here is the complete ChangeLog:
- fix a crash that occurs when pressing a dead key in the monitor
(I already reported this on December 8th, please drop that old patch)
- keymap corrections
- make ct
- don't pass undefined keycodes to the guest OS during KeyDown and KeyUp
events (as it is already done for modifier key events)
- fix a crash that occurs when pressing a dead key in the monitor
(I already reported this on December 8th, please drop that old patch)
- make HOME, END, and DELETE ke
The separate keymaps are only used when QEMU is built with the SDL
frontend. So we can avoid bloated installations of non-SDL (e.g. Cocoa)
builds with this simple patch:
Index: Makefile
===
RCS file: /sources/qemu/qemu/Makefile,v
ret
Please note that '-fno-tree-ch' is passed to GCC4 only for compiling
op.c, so that 'dyngen' doesn't fail, when it is working on op.o
afterwards! All other source files are still compiled without this flag.
On x86 GCC4 fails during compilation of op.c anyway. But '-fno-tree-
ch' could also he
I know that you have already discussed this on the list, and that you don't
want to actively support GCC 4. But (at least on Mac OS X) only a fix in
the build configuration is necessary to do the magic: op.c must be compiled
with -fno-tree-ch (as already mentioned on this mailing list).
GCC 4.0 is
...just to end this thread (c:
The problem is fixed in todays CVS. Compling QEMU with GCC 3.3 on Mac
OS X now works again: Running FreeDOS and Doom timedemo don't crash
anymore.
http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00206.html
Many thanks to Fabrice!
___
Thanks for your hint!
Again I modified several suspicious parts of the code, but I haven't
had any success. Today I installed GCC 3.4.5 from sources. The qemu
binary compiled with this version does _not_ crash. Now I'm beginning
to believe that the whole trouble is really a bug in Apple's o
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0010
0x00062f98 in tb_phys_invalidate (tb=0x8cad00,
page_addr=4294967295) at /Volumes/Data/build/qemu/exec-all.h:249
249 {
This is the path to the crash (each function calling
Thanks for the patch! I already browsed through the CVS history on
savannah, but it's a bit tricky because some code parts moved between
files when SMP support was added. Could you please provide a complete
diff to the last fully working CVS snapshot? According to your patch,
it dates back
gcc4 and -fno-tree-ch did the trick for me, too.
-fno-tree-ch was mentioned earlyer on this list, to compile with
gcc4 on OS X. But since gcc4 is still not in the default toolchain,
I did not even try :(.
Seams that we have a problem with gcc3.3 and not gcc4 for once :)
The error behavement
I just did some tests on the freedos image from your web-site and my first
impression is that these crashes are something compiler related. When I
build qemu with
./configure --prefix=/usr/local --cc=gcc-3.3 --target-list=i386-softmmu
--enable-cocoa
and start your image with
qemu -hda harddisk_
Ok, thanks for your reply.
I'm currently building qemu from CVS code several times a week, but I
never had DOS related problems. The guest OS is Win98 SE and I use
the DOS command prompt quite often. What are you doing, when it
crashes qemu? Does this occur randomly or when running special
This concerns the current cocoa version in cvs: When typing into the
monitor and accidentally pressing a dead key, qemu quits immediately and
all unsafed data in the guest os is lost:
2005-12-04 15:15:00.833 qemu[193] Exception raised during posting of
notification. Ignored. exception: *** -[N
With current CVS, when running Linux as guest OS, the kernel log is
flooded with messages like
atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
atkbd.c: Use 'setkeycodes 00 ' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x0 on isa0060/serio0)
Hi,
the current Cocoa frontend in CVS releases the mouse grab every time
when Shift, Alt, Ctrl, etc. is pressed. It's a simple fix. The patch
below adds the missing braces.
Sincerely,
Jo.
--- qemu-cvs/cocoa.m
+++ qemu-jh/cocoa.m
@@ -399,8 +399,10 @@
/* release Mou
Hi, I tried the current Qemu CVS sources on my iMac G5 (Mac OS X
10.4.3) and was really happy about the cocoa improvements. Thank you
for this great work! But while doing some x86 emulation (running
Linux and Win98 as guests) I encountered a small error: On my German
Apple keyboard the [^]
46 matches
Mail list logo
