cvs 2007-01-03 works
cvs 2007-01-23 works
cvs 2007-01-25 has the error!

2007-01-24 17:29 harekiet

* include/render.h, include/vga.h, src/gui/render.cpp,
src/gui/render_loops.h, src/gui/render_scalers.cpp,
src/gui/render_simple.h, src/gui/render_templates.h,
src/gui/sdlmain.cpp, src/hardware/vga.cpp,
src/hardware/vga_crtc.cpp, src/hardware/vga_draw.cpp,
src/hardware/vga_memory.cpp, src/hardware/vga_misc.cpp,
src/hardware/vga_other.cpp, src/ints/int10.cpp,
src/ints/int10_modes.cpp: Fixes to hercules emulation, better
detection and bank switching Fixes to tandy emulation, 640x200x16
mode and different sizes bank. EGA/VGA memory changes detection
for faster rendering added Renderer does initial pass to check for
needing to lock buffer

That was really complex change touching quite a few aspects of video memory emulation. The issue looks like endianness bug in which case it should affect other large-endian CPUs. Did anyone see this bug on non-Intel Macs?

Afaik it's the unchained ega only, not that much was changed for those,
but i fail to see why it looks that funny (endianness might be the cause
due to the (Bit32u*) forced casting).

Either in vga_memory or in vga_draw, there are a few places where pointers are casted to Bit32u*. In addition to endianness, there is another possibility: some ARM CPUs have very peculiar way of dealing with unaligned accesses -- those get quietly aligned to proper boundary. If that is the case some other ports should crash on those spots badly.

On a tip from Harekiet i tried reversing byte order here - didn't fix...

1class VGA_ChainedEGA_Handler : public PageHandler {
2
3...
4                colors0_3 = 
5                        //ARNIM Harekiet
6                        Expand16Table[3][temp.b[3]] |
7                        Expand16Table[2][temp.b[2]] | 
8                        Expand16Table[1][temp.b[1]] |
9                        Expand16Table[0][temp.b[0]];
10                *(Bit32u *)write_pixels=colors0_3;
11                temp.d=pixels.d & 0x0f0f0f0f;
12                colors4_7 = 
13                        Expand16Table[3][temp.b[3]] | 
14                        Expand16Table[2][temp.b[2]] |
15                        Expand16Table[1][temp.b[1]] |
16                        Expand16Table[0][temp.b[0]];
17                *(Bit32u *)(write_pixels+4)=colors4_7;

First check that you're at the unchained handlers, or change both to be sure.
Then you didn't change the code, just re-arranged it. The first line should
read something like

1Expand16Table[0][temp.b[3]]

so you actually change the ordering, the other ones respectively.

we are actually making progress
the bugs are caused by unalligned memory acces.
forcing the cpu to workaround those makes it work. However that is not a workable solution. We are trying to find a workaround.

(it is caused by the the vga.mem.leanar[start] which is casted to 32u (and friends))

Well adding a host_writed then, uses fast direct access on regular architectures,
and splits stuff up elsewhere.

Thanks to Serge for pointing-out this trick:

"If you set 'echo 3 > /proc/cpu/alignment' and it 'fixes' the problem, alignment issues are really involved. You can also check 'dmesg' output after running dosbox and it will show addresses of instructions causing problems. Setting 'echo 4 > /proc/cpu/alignment' will generate signal and terminate program on improper alignment, it is useful if you can run it in gdb or want to get a coredump."

Here is an example of a warning generated:

[96001.396148] Alignment trap: dosbox (1363) PC=0x000962d0 Instr=0xe5802004 Addres s=0x014ab5eb FSR 0x813

Here is the backgrace of the first hangup:

http://pastebin.ca/725398

Removing these casts allowed chained mode to run.

diff src/hardware/vga_memory.cpp src/hardware/vga_memory.cpp~
234c234
< pixels.d=(vga.mem.linear)[start];
---
> pixels.d=((Bit32u*)vga.mem.linear)[start];
237c237
< (vga.mem.linear)[start]=pixels.d;
---
> ((Bit32u*)vga.mem.linear)[start]=pixels.d;
247c247
< *write_pixels=colors0_3;
---
> *(Bit32u *)write_pixels=colors0_3;
254c254
< *(write_pixels+4)=colors4_7;
---
> *(Bit32u *)(write_pixels+4)=colors4_7;
256,257c256,257
< *(write_pixels+512*1024)=colors0_3;
< *(write_pixels+512*1024+4)=colors4_7;
---
> *(Bit32u *)(write_pixels+512*1024)=colors0_3;
> *(Bit32u *)(write_pixels+512*1024+4)=colors4_7;

c2woody suggested changes which yield proper visual results in vgatest.

(AWESOME)

From the Jan.25 cvs

1diff vga_memory.cpp vga_memory.cpp.orig
2117,118c117
3<               //vga.latch.d=((Bit32u*)vga.mem.linear)[start];
4< vga.latch.d=host_readd((HostPt)(&((Bit32u*)vga.mem.linear)[start]));
5---
6>               vga.latch.d=((Bit32u*)vga.mem.linear)[start];
7161,162c160
8<               //pixels.d=((Bit32u*)vga.mem.linear)[start];
9<               pixels.d=host_readd((HostPt)(&((Bit32u*)vga.mem.linear)[start]));
10---
11>               pixels.d=((Bit32u*)vga.mem.linear)[start];
12232,233c230
13< //            pixels.d=((Bit32u*)vga.mem.linear)[start];
14< pixels.d=host_readd((HostPt)(&((Bit32u*)vga.mem.linear)[start]));
15---
16>               pixels.d=((Bit32u*)vga.mem.linear)[start];
17236,237c233
18< //            ((Bit32u*)vga.mem.linear)[start]=pixels.d;
19< host_writed((HostPt)(&((Bit32u*)vga.mem.linear)[start]),pixels.d);
20---
21>               ((Bit32u*)vga.mem.linear)[start]=pixels.d;
22247,248c243
23< //            *(Bit32u *)write_pixels=colors0_3;
24< host_writed((HostPt)write_pixels,colors0_3);
25---
26>               *(Bit32u *)write_pixels=colors0_3;
27255,256c250
28< //            *(Bit32u *)(write_pixels+4)=colors4_7;
29< host_writed((HostPt)(write_pixels+4),colors4_7);
30---
31>               *(Bit32u *)(write_pixels+4)=colors4_7;
32258,261c252,253
33< //                    *(Bit32u *)(write_pixels+512*1024)=colors0_3;
34< //                    *(Bit32u *)(write_pixels+512*1024+4)=colors4_7;
35< host_writed((HostPt)(write_pixels+512*1024),colors0_3);
36< host_writed((HostPt)(write_pixels+512*1024+4),colors4_7);
37---
38>                       *(Bit32u *)(write_pixels+512*1024)=colors0_3;
39>                       *(Bit32u *)(write_pixels+512*1024+4)=colors4_7;

Running with the kernel unaligned memory trap still throws an exception later on at line 426:

1writeHandler(addr+0,(Bit8u)(val >> 0));  // triggers unaligned trap - PUPNIK

I will try to get the video capture going to provide better feedback. There are still some odd errors drawing in some modes.

Cheers 😀

All alignment problems fixed! thanks to c2woody. Changes in cvs.

Congrats on fixing the bug! 😁

pupnik wrote:

Dosbox 0.72 // Nokia 770 arm926ej-s screenshots

This is very cool. The Nokia 770 got a 252 MHz ARM CPU, no? I'm curious, though, how well does DOSBox run on such machine?

It runs overall at PC-XT speed - 4.77-8mhz with a fairly high frameskip (2-4).