We need an iBrowse replacement for 68k!!!

[chris]

Processing the exec list header as a node is basically what I was trying to say and it's a common problem with exec lists. Do the list nodes have many data (non-link) pointers? If so, would it be easy to define data (like padding) and clear the memory below the List or MinList header structures? Then if the list header was used like a node for a pointer, it would usually generate a MuForce/Enforcer hit to address 0 which we should be able to catch.

OK, well I'm pretty sure Buzz's code is OK as it's in use elsewhere, but I've added some padding to the list structure in the function which usually allocates the memory for my lists, so if it is still reading the list header anywhere we'll see it.

The RA_HandleInput problem is tough because there is a lot of abstraction in this area. This is where it would be nice to have line debug and know the source lines. I can normally pretty well compare the C source to assembler but not here.

I added some more debugging to try and track this down, and it seems to be consistently crashing after RA_HandleInput now, so I'm thinking I've fixed this.  You'll see how the function is called on the debug now, which might help.

Could you have a look at the new build and see what you get?  Thanks for your help!

edit: fixed build as an earlier fix got reverted accidentally

[chris]

The last value which looked like a return value that I could find on the stack would return to ami_bitmap() in /amiga/plotters.c. The return would have been from graphics.library BltMaskBitMapRastPort() near the bottom and may indicate a problem with this function call but is not reliable. I would have to catch the process before this to be more certain but it's a possible lead.

Blimey you're good!

I'd managed to transpose the last two arguments of BltMaskBitMapRastPort (only the OS3 build uses it otherwise I'd have noticed sooner).  I've fixed it now and put a new build up.

[chris]

I don't know any way to redirect stderr with AmigaDOS though.

On OS4 it's *>SER:
I think that's new though.

Good. My Amiga was in a stable condition up to this problem. NetSurf seems to use a lot of chipmem though (1-1.5MB on my P96 RTG Amiga). I hope it doesn't need any more big chunks or there could be failures due to low mem conditions and fragmentation.

It uses an offscreen buffer for rendering, which defaults to the same size as the screen.
edit: it's flagged as BMF_DISPLAYABLE so will be using chip mem, however it doesn't get displayed itself, only blitted to a displayed bitmap, so I might be able to remove this flag? (edit2: I've removed it and it seems happy on the OS4 build)

You can reduce it with the following options in Choices:
redraw_tile_size_x:nnn
redraw_tile_size_y:nnn
(replacing nnn with your chosen size)

It might also be a good idea to use Simple Refresh windows, with:
window_simple_refresh:1

I'll take a look at the new executable. At some point we should break through the startup and have a running NetSurf.

Hopefully!  I actually got it running a minute ago long enough to get into the menu and call up the hotlist.  I'm still not getting any rendered output on screen which is a bit concerning.

[chris]

How does NetSurf render?

Does it only use Reaction for the gadgets outside the main window and just treat everything inside the main display area as a large bitmap?

Yes.

[chris]

Cool, we should be able to do a C2P straight to the main bitmap then for extra speed

If you mean rendering direct to the window, I've tried that and it gives all sorts of problems.  There's an option to enable it (I think.. or maybe I removed it again), but it's only there to aid debugging.

[chris]

Edit Final:

It looks like the freeze is from BltMaskBitMapRastPort() of gui_window_set_icon() from gui.c.

A0 = scrbm = 0x973a574
D0 = srcx = 0
D1 = srcy = 0
A1 = destrp = 0xa43b388
D2 = destX = 0x9e
D3 = destY = 0x14
D4 = sizeX = 0x10
D5 = sizeY = 0x10
D6 = minterm = 0xe0
A2 = bltmask = 0

It looks to me like the minterm and bltmask arguments are switched for BltMaskBitMapRastPort(). Is that what was fixed for the other BltMaskBitMapRastPort() in /amiga/plotters.c?

Yes, and I fixed it here too at the same time. http://git.netsurf-browser.org/netsurf.git/commit/?id=9ac9866521e48933389dcf05f1ec5523f36b3435

minterm is correct - 0xe0 looks about right (whatever "(ABC|ABNC|ANBC)" equates to)
I think the problem is that I've not accounted for bltmask being NULL.  I've fixed this now, and also in plotters.c.  New build up (this one appears to work without freezing up).

[chris]

Startup completes here with no freezes or hits and displays the startup page! Good job!

Wait... you're actually getting the NetSurf welcome page rendered on screen?  I mean this one?

There are many different paths or areas to debug now but you may need to fix some things up first? Let me know what path(s) should be debugged first.

I'm not getting anything rendered here and it crashes if I move the mouse.  Certainly the moving the mouse crash I'd like to fix, if it shows up for you?  Beyond that I can't really test it!  It won't run on my A1200 either - red screens at some point during startup.

[chris]

edit: looks like the webpages get plotted in four colors;)?? (at least when it comes to graphics, is there some planar code in the plotter?)

No, nothing planar at all, it uses some graphics.library basic drawing tools to contruct the pages, and cheats a bit with datatypes.library to dither the graphics down for the screen.  Maybe that's the problem?  What sort of screenmode are you running in?  Can you try an 8-bit screen?

edit: Also I remember that I disabled the tiled bitmap renderer, which might account for amiga.org looking a bit dodgy (beyond the lack of colours thing).

edit2: so, even with debug off the interaction like following links is still pretty slow here.

Unfortunately I can't enable GCC optimisations due to the tag-trashing problem.  However I know there's some sub-optimal code there - such as using datatypes to scale and dither bitmaps, and outline fonts on OS3 are really slow so I could try a quick'n'dirty bitmap font renderer.  You'd lose support of characters outside ISO-8859-1 but the speed up should be significant.

[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?

[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.

[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?

[chris]

I'm hoping it works for both. I tried 8 bit at one point and I believe wawa has been using 8 bit some also. You could dl it and tell us how well it works on AGA.

It should work on AGA.  It doesn't require P96 although it will try to open P96 library and continue if it fails.  Actually the OS3 build doesn't use P96 at all at the moment.  I'll try enabling it once I have the 8-bit bitmaps displaying properly.

I don't see many RTG specific functions. Look at /amiga/rtg.c in the NetSurf sources. It uses P96 only if P96Base != NULL. This may work with AGA right now or I'm guessing it wouldn't take much to get it working. We will see what Chris says though.

Yeah, I moved all the P96 code to that file to contain it, as OS4.1FE apparently shouldn't need it, so it's there to make it easy for me to get rid of.  I do extensively use the ARGB colour setter of OS4 though.  Not sure what to do with that, I might have to do pen allocation even on truecolour screens on OS3.

and link with -noixemul if possible?

It doesn't use ixemul, so you don't need that option.  I'm using clib2.

I've just uploaded a new build.  It may just freeze as I've temporarily removed the tab bar in case the corruption there was causing your earlier problems.  I've also had another go at fixing the bitmaps, although I'm not holding out much hope.

I can see a potential problem where I'm remapping to the screen, and then blitting to an 8-bit bitmap before it ends up on the screen.  Specifying direct_render:1 might help point to whether that is the problem or not, although using an 8-bit screen should have worked if it was, so... *shrug*

[chris]

I think it's better to still specify it, doesn't hurt.

Actually it does because I tried it out of curiousity when I was having serious compilation problems initially.  It makes gcc link with libnix, which isn't on here either

[chris]

Yea. Maybe NovaCoder will start playing with the sources .

I hope so, doing remote fixes like this isn't really very efficient.

The gfx are a little different with the new build:

new http://www.heywheel.com/matthey/Amiga/NetSurf_grab3.png
old http://www.heywheel.com/matthey/Amiga/NetSurf_grab2.png

"A little different" as in "non-existent"?

Clearly that didn't work! I've partially reverted it and uploaded, this time built with -m68020 and -fomit-frame-pointer

Any change in graphics or speed?

[chris]

The fonts have a grey halo

That's normal for direct_render.  It's the main reason I say it's for debugging only.

Edit: Oh yea. New build is better at rendering. Without direct_render:1 it looks like this:

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

Much better and I think I know why old pages are showing through, will fix later.

I didn't notice much of a difference in speed. Maybe GCC is stuck in slow mode without -O2. I would have expected the executable size to drop a lot more than that too. Did all the source get recompiled for the 68020?

Yes, although most of the executable is static libraries.  I'll see if I can get -m68020 added for the NetSurf libraries.

@wawrzon

I know exactly what a.org is supposed to look like in NetSurf