I'm pleased to say that out of my long list of broken games on
X86-64, Hans' ym2151.c fix seems to fix most of them. :-)
Excluding soldivid and gunbird2--which should also be fixed
now--the only ones left that segfaulted for me (from my small
collection) are:
bmaster
lethalth
psoldier
rtypeleo
sf
Lawrence Gold wrote :
> On Nov 2, 2004, at 1:32 AM, Matthias Saou wrote:
>
> > Seems like it now works with the default yuv mode, yeah! This is great
> > since forcing YV12 didn't allow me to apply any effects.
> >
> > Still a problem, though : When I press Ctrl+Pgdn, I get "Black
> > scanlines
On Nov 2, 2004, at 1:32 AM, Matthias Saou wrote:
Seems like it now works with the default yuv mode, yeah! This is great
since forcing YV12 didn't allow me to apply any effects.
Still a problem, though : When I press Ctrl+Pgdn, I get "Black
scanlines
2x2" fine, but when I do it a second time, it bo
Matthias Saou wrote:
Alastair M. Robinson wrote :
It seems that with x11-mode 1, when I force yuv to mode 2 (as I've
actually always been required to on this computer), it works great!!!
The thing is, games with artwork don't seem to require me to force yuv
to display properly.
It sounds as thoug
Hans de Goede wrote :
> > More on my x86_64 problem!
> >
> > It seems that with x11-mode 1, when I force yuv to mode 2 (as I've
> > actually always been required to on this computer), it works great!!!
> > The thing is, games with artwork don't seem to require me to force yuv
> > to display prope
Alastair M. Robinson wrote :
> > It seems that with x11-mode 1, when I force yuv to mode 2 (as I've
> > actually always been required to on this computer), it works great!!!
> > The thing is, games with artwork don't seem to require me to force yuv
> > to display properly.
>
> It sounds as though
Hi,
Matthias Saou wrote:
It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually
always been required to on this computer), it works great!!! The thing is,
games with artwork don't seem to require me to force yuv to display
properly.
It sounds as though your video driver might h
That way the divide operation will work, otherwise you will only be able
to divide by powers of 2, which is not what you want.
Yes sorry, I got the negative representations wrong ( damn head cold ).
However if you look at the output of:
#include
void main( void )
{
int i = 0x2;
int h = 0x80
Matthias Saou wrote:
Hi,
More on my x86_64 problem!
It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually
always been required to on this computer), it works great!!! The thing is,
games with artwork don't seem to require me to force yuv to display
properly.
If you need any mo
smf wrote:
But it is not -1. it is -0.0001
In 16:16 fixed point:
0.5 is represented by 0x8000;
1.0 is represented by 0x0001;
-1 is represented by 0x.
-1.5 is represented by 0x8000.
No no no, the part behind the point also is added to the negative of 2
to the power of 15, s
But it is not -1. it is -0.0001
In 16:16 fixed point:
0.5 is represented by 0x8000;
1.0 is represented by 0x0001;
-1 is represented by 0x.
-1.5 is represented by 0x8000.
This again highlights the issue:
#include
void main( void )
{
int i = 0x8000;
printf( "%d\n", i >> 1
smf wrote:
About the fixed point notation you've by orring it with 0x made
the value -1/65536 which divided by 1 (which 0x1 fixed point is)
is indeed 0.
I know, it was a contrived example to show you that the fixed point
number -1. could only be converted to -1 by shifting and not
About the fixed point notation you've by orring it with 0x made the
value -1/65536 which divided by 1 (which 0x1 fixed point is) is indeed
0.
I know, it was a contrived example to show you that the fixed point
number -1. could only be converted to -1 by shifting and not dividing.
Ph
smf wrote:
and it was not a fixed point number.
And It looks very much like a fixed point number to me... It's an
accumulator where you specify the number of point bits.
Could be anyways the shift was right I will fix this in CVS when I've
rebooted back into a real operating system.
Regards,
H
smf wrote:
Even on a signed fixedpoint number a shift would be wrong, and it was
not a fixed point number.
No the shift would be correct ( as long as your compile isn't broken ):
#include
void main( void )
{
int i = ( -1 << 16 ) | 0x;
printf( "%d\n", i >> 16 );
printf( "%d\n", i / 0x1 )
and it was not a fixed point number.
And It looks very much like a fixed point number to me... It's an
accumulator where you specify the number of point bits.
Phill
___
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.twisted.org.uk/mailman/listinfo/x
Even on a signed fixedpoint number a shift would be wrong, and it was not
a fixed point number.
No the shift would be correct ( as long as your compile isn't broken ):
#include
void main( void )
{
int i = ( -1 << 16 ) | 0x;
printf( "%d\n", i >> 16 );
printf( "%d\n", i / 0x1 );
}
The shift
smf wrote:
I've also found that they we're using right shift as a divide op on
signed numbers which won't work ofcourse.
Well it depends on what effect it was trying to achieve. You can't
blindly assume that a shift on a signed number is wrong. If the number
was a fixed point number and it was
I've also found that they we're using right shift as a divide op on
signed numbers which won't work ofcourse.
Well it depends on what effect it was trying to achieve. You can't blindly
assume that a shift on a signed number is wrong. If the number was a fixed
point number and it was converting to
F.J. McCloud wrote:
I had segfault problems with x11-mode 2 or 3 unless I specified
-yv12.
segfault problems are great, those produce a core and that I can debug
remotly :)
-x11-mode 1 seemed to work except it was an unscaled image in
the upper left corner of the screen, surrounded by junk pixel
F.J. McCloud wrote:
--- Paul Priest <[EMAIL PROTECTED]> wrote:
Other people have reported PsikyoSH crashing in the vidhrdw,
both Haze
and I looked and couldn't think of anything immediately
obvious.
- Paul
Yeah, soldivid crashes immediately in
psikyosh_drawbackground().
I just started looking at
Matthias Saou wrote:
Hi,
More on my x86_64 problem!
It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually
always been required to on this computer), it works great!!! The thing is,
games with artwork don't seem to require me to force yuv to display
properly.
If you need any m
Matthias Saou wrote:
I just tested, and things seem to have definitely improved! With x11-mode
1, games with artwork work great (tried pacman & mario), but the artwork
_must_ be enabled. Without, a similar problem than before happens : I get
the display inside the window "stretched" horizontally,
F.J. McCloud wrote:
--- Hans de Goede <[EMAIL PROTECTED]> wrote:
Could you take a look at that? I don't have a x86_64 machine.
I sent a reply to this email already.
http://www.mail-archive.com/xmame%40toybox.twisted.org.uk/msg07646.html
I had also experienced the stretching/vertical green lines i
F.J. McCloud wrote:
--- Hans de Goede <[EMAIL PROTECTED]> wrote:
I can reproduce this on my 32 bit system too,
investigating...
You were able to reproduce the segfault on 32-bit?
No, I was able to reproduce the triggering of the check for negative
indexes steve put in ym5121.c when debugging on
--- Hans de Goede <[EMAIL PROTECTED]> wrote:
> Could you take a look at that? I don't have a x86_64 machine.
I sent a reply to this email already.
http://www.mail-archive.com/xmame%40toybox.twisted.org.uk/msg07646.html
I had also experienced the stretching/vertical green lines in
the past on Xv
--- Paul Priest <[EMAIL PROTECTED]> wrote:
> Other people have reported PsikyoSH crashing in the vidhrdw,
> both Haze
> and I looked and couldn't think of anything immediately
> obvious.
> - Paul
Yeah, soldivid crashes immediately in
psikyosh_drawbackground().
I just started looking at it but
Hans de Goede wrote:
The real fix is that oper[].kc_i got initialised to 0 where as it should
have been initialised to 768 since that is the min value for kc_i.
I've also found that they we're using right shift as a divide op on
signed numbers which won't work ofcourse.
This is fixed in CVS now
F.J. McCloud wrote:
As a
sanity check, can someone else with X86-64 try the following
games and report their status on 32-bit and 64-bit for 10K
frames?
gunbird2
soldivid
Other people have reported PsikyoSH crashing in the vidhrdw, both Haze
and I looked and couldn't think of anything immediate
--- Hans de Goede <[EMAIL PROTECTED]> wrote:
> I can reproduce this on my 32 bit system too,
> investigating...
You were able to reproduce the segfault on 32-bit?
The strange thing is stunrun has never segfaulted for me on
32-bit. (Where "32-bit" means a multilib gcc activated by the
-m32 flag.)
Hi,
More on my x86_64 problem!
It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually
always been required to on this computer), it works great!!! The thing is,
games with artwork don't seem to require me to force yuv to display
properly.
If you need any more details, please
Hans de Goede wrote :
> p.s.
>
> A few days ago we also received this report:
>
> ---
> I've just recompiled a CVS snapshot on my x86_64 system, and am having
> problems with the x11/xv target.
[...]
> ---
That would be me :-)
> Could you take a look at that? I don't have a x86_64 machine. Mai
p.s.
A few days ago we also received this report:
---
I've just recompiled a CVS snapshot on my x86_64 system, and am having
problems with the x11/xv target. I've always had problems with it, and had
been using the OpenGL target instead, but as this build doesn't have the
OpenGL built in (my bad),
The real fix is that oper[].kc_i got initialised to 0 where as it should
have been initialised to 768 since that is the min value for kc_i.
I've also found that they we're using right shift as a divide op on
signed numbers which won't work ofcourse.
This is fixed in CVS now, Lawrence Please mer
F.J. McCloud wrote:
This is core MAME code but no one on mametesters is doing
64-bit work yet. I hope someone here can shed some light on
this first.
There are a number of games that work fine in 32-bit X86 xmame,
but crash on 64-bit amd64 xmame regardless of gcc version or
setting. This also has
Hmm, did some quick scanning, doesn't look 64 bit related to me.
Have you looked at the debug output when you compile it in 32 bit mode?
Regards,
Hans
F.J. McCloud wrote:
This is core MAME code but no one on mametesters is doing
64-bit work yet. I hope someone here can shed some light on
this firs
This is core MAME code but no one on mametesters is doing
64-bit work yet. I hope someone here can shed some light on
this first.
There are a number of games that work fine in 32-bit X86 xmame,
but crash on 64-bit amd64 xmame regardless of gcc version or
setting. This also has nothing to do with
37 matches
Mail list logo
