We need an iBrowse replacement for 68k!!!

[chris]

The 68k code is really aweful, even for optimizations being turned off. [...] There is a *lot* of room for optimization improvement.

If somebody can supply the relevant patches to get a working gcc4.5.4 or newer and prove it doesn't optimise taglists away, maybe we can resolve that?

[wawrzon]

@matthey
i can navigate through pretty well under uae. can you catch some screenshot and post it? uae is still an emulator not always able to catch all quirks real hardware may have. perhaps we should coordinate the emulated system with your real one. i assume 060,128mb, i have 256 set, but netsurf doesnt need unnaturally much memory. i cant emulate mediator/voodoo though, but i could try to set up a p4 again. when back in studio ill test on my 060/mediator/voodoo machine as well.

tried to compare speed with an alternative aros68k/owb setup on similar hardware settings. speed seems about comparable, admitted owb spits also a lot debug and it doesnt render aorg well, even if most others are alright.

[wawrzon]

@chris

Can you try an 8-bit screen?

the result on an 8bit screen is visually the same.

what concerns gcc perhaps best to ask people on eab, i doubt there is anyone here experienced in this field. alternatively, would that be possible to borrow aros compilers for the time being? these are patched versions of 4.6.4 and 4.8.2 afair, with outlook at 5.x.x. they should produce 68k elf code that can be converted to hunk. though they are not exactly efficient now due to some register macros as it appears. ideally could we get netsurf compiling with vbcc?

[matthey]

@matthey
i can navigate through pretty well under uae. can you catch some screenshot and post it? uae is still an emulator not always able to catch all quirks real hardware may have. perhaps we should coordinate the emulated system with your real one. i assume 060,128mb, i have 256 set, but netsurf doesnt need unnaturally much memory. i cant emulate mediator/voodoo though, but i could try to set up a p4 again. when back in studio ill test on my 060/mediator/voodoo machine as well.

Here is my welcome window screen grab.

http://www.heywheel.com/matthey/Amiga/NetSurf_grab.png

Edit: Amiga.org is working for me now

http://www.heywheel.com/matthey/Amiga/NetSurf_grab2.png

NetSurf is using 800x600x32 BGRA (little endian) here.

tried to compare speed with an alternative aros68k/owb setup on similar hardware settings. speed seems about comparable, admitted owb spits also a lot debug and it doesnt render aorg well, even if most others are alright.

I haven't made it far enough to say anything about the speed. I now have a lot more free chip mem which should provide a speedup by not using .

Edit: Now that amiga.org is working, I can see that it is quite slow. It is multitasking friendly though.

[wawrzon]

@matt:
but it doesnt look much worse. dont think its endian. you sure gave it stack? downloaded the last version form chris' link? it doesnt seem to eat up chip anymore.

[chris]

@matt:
but it doesnt look much worse. dont think its endian.

I have a suspicion that it is related to ARGB vs RGBA.  I've uploaded a version with a potential fix.  If that doesn't work there's something else I can try.

It might be useful if this build doesn't help, to set the option: (maybe with the current build too)
mask_alpha:0
That should show more obviously if it's anything to do with byte ordering.

[chris]

Here is my welcome window screen grab.

http://www.heywheel.com/matthey/Amiga/NetSurf_grab.png

Edit: Amiga.org is working for me now

http://www.heywheel.com/matthey/Amiga/NetSurf_grab2.png

NetSurf is using 800x600x32 BGRA (little endian) here.

Interesting spacing with that font.
There's something wrong with the clicktab gadget, the text in it is corrupted.  Can't see any obvious reason why - if you open more tabs (RAmiga-N) does it sort itself out?
The status bar has ended up above the top window border.  I'll need a bit of time to get that working as intended.
Also the window doesn't appear to have cleared itself before rendering the new page.

Edit: Now that amiga.org is working, I can see that it is quite slow. It is multitasking friendly though.

Let's get the bitmaps showing up properly first (see my post above), then I'll have a go at speeding it up.

[itix]

@chris

the result on an 8bit screen is visually the same.

what concerns gcc perhaps best to ask people on eab, i doubt there is anyone here experienced in this field. alternatively, would that be possible to borrow aros compilers for the time being? these are patched versions of 4.6.4 and 4.8.2 afair, with outlook at 5.x.x. they should produce 68k elf code that can be converted to hunk. though they are not exactly efficient now due to some register macros as it appears. ideally could we get netsurf compiling with vbcc?

To me it sounds like GCC is optimizing code by putting varargs to registers. Solution could be using __VA_ARGS__ style macros in tag calls but you need to craft some inline asm there.

[matthey]

Interesting spacing with that font.

Or rather lack of spacing.

There's something wrong with the clicktab gadget, the text in it is corrupted.  Can't see any obvious reason why - if you open more tabs (RAmiga-N) does it sort itself out?

I can't tell any difference besides being taken back to the welcome page.

Let's get the bitmaps showing up properly first (see my post above), then I'll have a go at speeding it up.

Maybe Arti could help. His and Novacoder's SDL 68k build of NetSurf is reasonable speed for the 68k. He is using GCC 4.5.4 on Linux:

http://eab.abime.net/showthread.php?p=1000964#post1000964

GCC installs are no fun to mess with I know. I just fixed my GCC 3.4.0 version on my Amiga after several years of it not being installed properly but still compiling some programs. Maybe it's worth while because the early versions of GCC 4 had problems but the newest versions seem to be getting better again.

[matthey]

I closed a window which generated a MuForce hit. It looks like it's from gui_window_destroy() in /amiga/gui.c. I believe it is the Remove() toward the bottom of gui_window_destroy(). Perhaps that exec list problem is not completely gone?

Code: [Select]


LONG WRITE to  09B070F2        data=09B070F6   PC: 00F81A2A
USP : 097F8D40 SR: 8010  (U0)(-)(-)  TCB: 09600778
Data: ABADF00D ABADF00D 0985DCF8 00000400 00000100 025796ED 0240870F 09040D1C
----> 09040D1C - "netsurf"  Hunk 0000 Offset FFFFFFFC
Addr: 09B070F6 09B070F2 094FD588 09600778 00000000 097F8D80 080008D4 0828077C
Stck: 09058128 094FD588 09600778 089F1348 094FD588 09600001 09B1559C 097F8D78
Stck: 09070F1C 089F1348 098BE03C 00000000 00000024 098BE03C 0000002B 00000000
Stck: 097F8D90 090A3118 09B01B1C 0985DCF8 097F8D9C 090A336A 09AF74F0 097F8DD4
----> 00F81A2A - "ROM - exec 45.20 (6.1.2002)"  Hunk 0000 Offset 0000197C
----> 09058128 - "netsurf"  Hunk 0000 Offset 00017408
----> 094FD588 - "netsurf"  Hunk 0000 Offset 004BC868
----> 094FD588 - "netsurf"  Hunk 0000 Offset 004BC868
----> 09600001 - "LIBS:datatypes/picture.datatype"  Hunk 0003 Offset 00000121
----> 09070F1C - "netsurf"  Hunk 0000 Offset 000301FC
----> 090A3118 - "netsurf"  Hunk 0000 Offset 000623F8
----> 090A336A - "netsurf"  Hunk 0000 Offset 0006264A
00f81a26 :  2059                       movea.l (a1)+,a0
00f81a28 :  2251                       movea.l (a1),a1
00f81a2a : *2288                       move.l a0,(a1)
00f81a2c :  2149 0004                  move.l a1,$4(a0)
00f81a30 :  4e75                       rts
Name: "netsurf"  CLI: "netsurf"


It seems to be the Node->ln_Pred that is invalid.

[chris]

I closed a window which generated a MuForce hit. It looks like it's from gui_window_destroy() in /amiga/gui.c. I believe it is the Remove() toward the bottom of gui_window_destroy(). Perhaps that exec list problem is not completely gone?

It seems to be the Node->ln_Pred that is invalid.

That'll be because I never fixed GetPred same as GetSucc.

Are the colours better now?

[matthey]

Are the colours better now?

There is no difference that I can tell with your new build. I'll try some different Choices settings and see what happens.

It might be useful if this build doesn't help, to set the option: (maybe with the current build too)
mask_alpha:0
That should show more obviously if it's anything to do with byte ordering.

mask_alpha:0 in Choices also didn't seem to make much difference.

[wawrzon]

Are the colours better now?

no. i tried ARGB and RGBA..

[NovaCoder]

no. i tried ARGB and RGBA..

Arti had some trouble with the bye ordering of colors for the SDL port, not sure what he did to fix it though.

Are you guys targeting native chipset 8 bit displays or RTG?

Also, what compiler options are you using?   We might be able to improve speed by using the right performance options (after it's running properly and it's stable of course!)

[wawrzon]

btw, netsurf depends on picasso96api.library, which will be only available on p96 systems. would probably be better to make it compatible with cgx3 as p96 and everything else is compatible to this quasi standard.

[NovaCoder]

btw, netsurf depends on picasso96api.library, which will be only available on p96 systems. would probably be better to make it compatible with cgx3 as p96 and everything else is compatible to this quasi standard.

So it will only run on RTG systems?  

No AGA support