basilisk-devel

[B2-devel] Changes committed, please check out

[<gb...@di...>]

Hi,

As for real addressing mode, I stepped down so direct addressing is now
the default addressing mode. To enable real addressing, please use the
--enable-addressing=real configure option.

Real addressing doesn't work on Solaris ; anyway its manpage states that
using MAP_FIXED in mmap(2) implies undefined behavior for further
sbrk(), malloc() calls...

In rom_patches.cpp and rsrc_patches.cpp, I mainly made the following two
changes for real addressing

- changed type of ScratchMem area from uint32 to uint8 * and use
Host2MacAddr() to get the corresponding mac address. Since I don't have
an Amiga, please check if my changes in main_amiga.cpp and
native_cpu/cpu_emulation.h broke something.

- The code for moving the System Zone now patches ROM in order to
insert:
RAMBaseMac+0x2000 and RAMBaseMac+0x3800

instead of:
RAMBaseMac and RAMBaseMac + 0x1800

Thanks.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Fri, Sep 22, 2000 at 07:53:23PM +0200, Gwenole Beauchesne wrote:
> As for real addressing mode, I stepped down so direct addressing is now
> the default addressing mode. To enable real addressing, please use the
> --enable-addressing=real configure option.

Something is wrong. The (windowed) display looks very confused (see attached
screenshot) on my machine (Linux 2.2.16 on a PII with XFree86 4.0.1). This
is with both real and direct addressing. In banked mode, it works fine.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[<gb...@di...>]

Hi,

> Something is wrong. The (windowed) display looks very confused (see attached
> screenshot) on my machine (Linux 2.2.16 on a PII with XFree86 4.0.1). This
> is with both real and direct addressing. In banked mode, it works fine.

VOSF is disabled by default unless direct or real addressing mode is
enabled. Could you please rerun your test with --enable-addressing=banks
--enable-vosf ? I think you will get the same result, even in DGA mode.
If this was a bug with the direct or real memory access routines, MacOS
wouldn't boot I think.

Now that you still get strange screen updates, there are several
options:

- What is your screen resolution ? It seems that your page size is an
exact multiple of bytes_per_row. That's not a problem but this explains
why complete lines are missing or are not updated in time, instead of
several lines plus a portion of the last one from the set.

I will guess 640x480 in 8bpp mode according to the information I got
from the image. It's clear that 4096 is not an exact multiple of 640 and
I too use a 640x480 window and I tried every screen depth except 1 bpp
and 24 bpp.

- I probably miscalculated the offsets (video_x.cpp/VideoInitBuffer) in
the mainBuffer structure though I am pretty sure it is correct to take
VideoMonitor.bytes_per_row which turns out to be img->bytes_per_pixel
for a windowed display. 

- Which type of signal handler is used ? Extended signals (siginfo_t) or
the hack for Linux/i386 (sigcontext) ? I heard that some early versions
of Linux kernels with extended signals were boguous and didn't set up
si_addr correctly... Hmm, that's a too easy answer ;-)

If this is through the sigcontext hack... well, this is a hack and it
works for me because the kenel sources (2.2.5) tell me that the cr2
field contains the faultive address. (linux/arch/i386/mm/fault.c).

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Sun, Sep 24, 2000 at 06:59:22PM +0200, Gwenole Beauchesne wrote:
> Could you please rerun your test with --enable-addressing=banks
> --enable-vosf ?

This shows the same bug.

> - What is your screen resolution ?

640x480x16

> - Which type of signal handler is used ? Extended signals (siginfo_t) or
> the hack for Linux/i386 (sigcontext) ?

The hack.

> If this is through the sigcontext hack... well, this is a hack and it
> works for me because the kenel sources (2.2.5) tell me that the cr2
> field contains the faultive address. (linux/arch/i386/mm/fault.c).

This also seems to be the case in 2.2.16.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[<gb...@di...>]

Hi,

> Something is wrong. The (windowed) display looks very confused (see attached
> screenshot) on my machine (Linux 2.2.16 on a PII with XFree86 4.0.1). This
> is with both real and direct addressing. In banked mode, it works fine.

This could also simply be the fact that I mis-implemented the
incremental screen update method.

Here is a patch that disables it. Since I didn't put the correct
dependancies into the Makefile, you will have to touch video_x.cpp
first.

<--- begin patch --->
--- BasiliskII.orig/src/Unix/video_vosf.h       Sun Sep 24 19:08:26 2000
+++ BasiliskII/src/Unix/video_vosf.h    Sun Sep 24 19:08:33 2000
@@ -332,6 +332,18 @@
                const uint32 length = (page - first_page) <<
mainBuffer.pageBits;
                mprotect((caddr_t)(mainBuffer.memStart + offset),
length, PROT_READ);
                
+#if 1
+               do_update_framebuffer(the_host_buffer + offset,
the_buffer + offset, length);
+               
+               const int y1 = mainBuffer.pageInfo[first_page].top;
+               const int y2 = mainBuffer.pageInfo[page - 1].bottom;
+               const int width = VideoMonitor.x;
+               const int height = y2 - y1 + 1;
+               if (have_shm)
+                       XShmPutImage(x_display, the_win, the_gc, img, 0,
y1, 0, y1, width, height, 0);
+               else
+                       XPutImage(x_display, the_win, the_gc, img, 0,
y1, 0, y1, width, height);
+#else
                // There is at least one line to update
                const int y1 = mainBuffer.pageInfo[first_page].top;
                const int y2 = mainBuffer.pageInfo[page - 1].bottom;
@@ -383,6 +395,7 @@
                        XShmPutImage(x_display, the_win, the_gc, img,
x1, y1, x1, y1, width, height, 0);
                else
                        XPutImage(x_display, the_win, the_gc, img, x1,
y1, x1, y1, width, height);
+#endif
        }
 }

<--- end patch -->

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Sun, Sep 24, 2000 at 07:21:43PM +0200, Gwenole Beauchesne wrote:
> Here is a patch that disables it.

This rather makes it worse (see attachment).

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[<gb...@di...>]

Hi,

> On Sun, Sep 24, 2000 at 07:21:43PM +0200, Gwenole Beauchesne wrote:
> > Here is a patch that disables it.
> 
> This rather makes it worse (see attachment).

Arrgl :-/

I now really suspect the problem to be the information contained in the
mainBuffer structure. Hadn't there at least one frame (the first one in
fact) that was fully and correctly drawed ?

Oh, I got an idea. Does the display uses or not X-Shm ? All my tests in
windowed mode were carried out with Shm. One difference I see between
the_buffer_copy from Shm mode or from no-Shm mode is that in one case
width is used to create an XImage, and in the other case, aligned_width
is used. Another difference is that the bitmap_pad in the latter case
(given to XCreateImage) is 32 whereas aligned_width is aligned on
16-byte boundaries (XShmCreateImage).

By the nature of the blit functions, it is important to have the same
line width between the "host" buffer, the one created by a call to
XShmCreateImage() or XCreateImage(), and the temporary frame buffers.
Actually, I think they are identical... at least in X-Shm mode.

I also see a potential bug, in init_window() and direct or real
addressing mode, VideoMonitor.mac_frame_base is initted to the_buffer.
In fact, the alignment of the_buffer on page boundary carried out in
VideoInit(), should be done when the_buffer is assigned to
VideoMonitor.mac_frame_base. I don't think this is the bug we are
currently facing to, however. Otherwise, mprotect() would gently have
segfaulted if the address wasn't aligned on page boundary.

Have you tried 8bpp DGA mode ? This is bound to work since this is the
only mode for a little endian system where VOSF is not involved. I would
be really surprised if it still draws weird things...

BTW, here is another patch against the sources you now have:
It updates the XImage buffer line per line. Please tell me it works now
;-)

<--- begin patch 2 --->
--- BasiliskII.orig/src/Unix/video_vosf.h       Mon Sep 25 02:03:46 2000
+++ BasiliskII/src/Unix/video_vosf.h    Mon Sep 25 02:12:02 2000
@@ -333,10 +333,16 @@
                mprotect((caddr_t)(mainBuffer.memStart + offset),
length, PROT_READ);
                
 #if 1
-               do_update_framebuffer(the_host_buffer + offset,
the_buffer + offset, length);
-               
                const int y1 = mainBuffer.pageInfo[first_page].top;
                const int y2 = mainBuffer.pageInfo[page - 1].bottom;
+               
+               for (int i = y1; i <= y2; i++) {
+                       do_update_framebuffer(
+                               the_host_buffer + i *
img->bytes_per_line,
+                               the_buffer + i *
VideoMonitor.bytes_per_row,
+                               VideoMonitor.bytes_per_row );
+               }
+               
                const int width = VideoMonitor.x;
                const int height = y2 - y1 + 1;
                if (have_shm)
<--- end patch 2 --->

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Mon, Sep 25, 2000 at 02:26:27AM +0200, Gwenole Beauchesne wrote:
> Hadn't there at least one frame (the first one in fact) that was fully and
> correctly drawed ?

The initial black screen? Yes, this is drawn correctly. :-)

> Oh, I got an idea. Does the display uses or not X-Shm ?

It uses Shm.

> Have you tried 8bpp DGA mode ?

This is the only mode that works. 16bpp and 8bpp/16bpp window modes all show
stripes, regardless of the display size. They sometimes also crash with a
"Segmentation fault at ..." message.

> BTW, here is another patch against the sources you now have:

This makes it revert to the former behaviour (i.e. before your first patch).

I've also tried it on a Debian 2.2 (PIII/500, Linux 2.2.17, XFree86 3.3.6)
system and there it works very nicely. I wonder whether XFree86 4.x might
be the culprit?

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Sat, Oct 07, 2000 at 04:16:47PM +0200, Christian Bauer wrote:
> The initial black screen? Yes, this is drawn correctly. :-)

Also, when the window gets an Expose event, one correct frame is drawn.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[<gb...@di...>]

Hi!

> This rather makes it worse (see attachment).

I committed a change involving a cleaning up of the Expose event
handling code. Maybe could have it corrupted the dirtyPages structure ?
Hmm, I don't think so but who knows...

-- 
Gwenolé Beauchesne