We need an iBrowse replacement for 68k!!!

[matthey]

Yes

It's still freezing for me so unless I haven't removed the On/OffMenu properly (I've #defined them out of existance) then there's something new to find.

O.k. I have something else I need to work on so I probably won't be able to test until tomorrow. Did you place a new build at the same location as the others?

[matthey]

I've fixed all the font code so it should now be reading fonts and printing to the window exactly the same as on OS4 (ie. full UTF-8 support).  You'll probably find you need to set some different fonts in the Choices file, as the defaults are set to fonts which come with OS4, so something like this should work on a basic OS3 install: (they must be outline fonts)

Code: [Select]

font_sans:CGTriumvirate
font_serif:CGTimes
font_mono:LetterGothic
font_cursive:CGTimes
font_fantasy:CGTimes
Choices is usually PROGDIR:Users/default/Choices (the "default" may differ if you have the USER env-var set).  You may need to create it.

I tried this font config in Choices and the bullet.library crashed fairly early.

Code: [Select]

Exception !!   00000003     TCB: 08AF5338     CTX: 081C0380     SSP: 082816DC
USP : 0911BED0 SR: 0004  (U0)(-)(-)  TCB: 08AF5338
Data: 097AD9E8 00000000 0000000B 00000400 00000100 022B7B1D 022B0D13 00000000
Addr: 0911BEE8 0911BF08 097AC870 08AF5338 097AD9E8 0911BF68 ABADF00D 082816DC
Stck: 0000000B 00000400 08B4F53C 0911BF68 097ADDEC 097D200A 0911BF08 00000000
Stck: 08B58390 080189F4 09005FDE 0000000B 0911BF08 097AD9E8 80000001 00550055
Stck: 80000008 000B0000 8000000E 00000000 8000000F 00000000 8000000A 00000000
----> 097D184E - "LIBS:bullet.library"  Hunk 0000 Offset 0000593E
----> 08B4F53C - "netsurf"  Hunk 0000 Offset FFFFFFFC
----> 097D200A - "LIBS:bullet.library"  Hunk 0000 Offset 000060FA
----> 08B58390 - "netsurf"  Hunk 0000 Offset 00008E50
----> 09005FDE - "netsurf"  Hunk 0000 Offset 004B6A9E
097d180e :  001c 6718                  ori.b #$18,(a4)+
097d1812 :  72ff                       moveq.l #-$1,d1
097d1814 :  b2ac 0020                  cmp.l $20(a4),d1
097d1818 :  6710                       beq.s $97d182a
097d181a :  4a6c 0024                  tst.w $24(a4)
097d181e :  670a                       beq.s $97d182a
097d1820 :  48c0                       ext.l d0
097d1822 :  0c80 0000 ffff             cmpi.l #$ffff,d0
097d1828 :  6604                       bne.s $97d182e
097d182a :  7006                       moveq.l #$6,d0
097d182c :  6058                       bra.s $97d1886
097d182e :  7e01                       moveq.l #$1,d7
097d1830 :  6014                       bra.s $97d1846
097d1832 :  202d 0004                  move.l $4(a5),d0
097d1836 :  7e01                       moveq.l #$1,d7
097d1838 :  3940 0050                  move.w d0,$50(a4)
097d183c :  6008                       bra.s $97d1846
097d183e :  7001                       moveq.l #$1,d0
097d1840 :  6044                       bra.s $97d1886
097d1842 :  7002                       moveq.l #$2,d0
097d1844 :  6040                       bra.s $97d1886
097d1846 :  41ef 0018                  lea.l $18(a7),a0
097d184a :  2c6c 1100                  movea.l $1100(a4),a6
097d184e : *4eae ffd0                  jsr -$30(a6)
097d1852 :  2a40                       movea.l d0,a5
097d1854 :  4a80                       tst.l d0
097d1856 :  6600 fc68                  bne $97d14c0
097d185a :  4a07                       tst.b d7
097d185c :  6726                       beq.s $97d1884
097d185e :  4a2c 0015                  tst.b $15(a4)
097d1862 :  6704                       beq.s $97d1868
097d1864 :  7009                       moveq.l #$9,d0
097d1866 :  601e                       bra.s $97d1886
097d1868 :  4a2c 0016                  tst.b $16(a4)
097d186c :  6704                       beq.s $97d1872
097d186e :  700a                       moveq.l #$a,d0
097d1870 :  6014                       bra.s $97d1886
097d1872 :  486c 0018                  pea.l $18(a4)
097d1876 :  6100 af3e                  bsr $97cc7b6
097d187a :  584f                       addq.w #$4,a7
097d187c :  4a40                       tst.w d0
097d187e :  6704                       beq.s $97d1884
097d1880 :  7003                       moveq.l #$3,d0
097d1882 :  0c40 7000                  cmpi.w #$7000,d0
097d1886 :  4cdf 608c                  movem.l (a7)+,d2-d3/d7/a5-a6
097d188a :  4e75                       rts
097d188c :  9efc 000c                  suba.w #$c,a7
Name: "Shell Process"  CLI: "netsurf"

I didn't try to bebug this further as I was able to get further without Choices. I can take a look if you want though.

I've just updated it again.  This time the menus should work (so OnMenu/OffMenu is back in place) and I've enabled the auto on/off scrollbars.  It doesn't appear to be freezing any more, but it crashes far too much for me to tell whether it works!

Somehow, though, I managed to click on a link to NetSurf's homepage, so I'm pretty sure the display of webpages isn't working.

I have the debugger stopped on the first hit while I post from AWeb on the same Amiga. Images in AWeb will load but are immediate flushed despite plenty of memory (edit: my 2MB of gfx mem is <512k with P96 RTG which explains the flushing and slowness) on  and the system is slower than it should be so there must already be some kind of problem. It seems stable enough though.

The last NetSurf debug output:

Code: [Select]

(12.866687) amiga/gui.c ami_openscreen 725: Screen signal 22
(14.550011) amiga/font.c ami_font_open 381: Font cache miss: DejaVu Sans
(14.583344) amiga/os3support.c OpenOutlineFont 64: Unable to open FONTS:DejaVu Sans.otag
(14.600012) amiga/font.c ami_font_open 388: Requested font not found: DejaVu Sans
(14.633347) amiga/misc.c ami_misc_req 54: Unable to open
DejaVu Sans
(14.833350) amiga/gui.c gui_window_create 3713: Creating window object
(15.333339) amiga/gui.c gui_window_create 3978: Opening window
(15.450009) amiga/gui.c gui_window_create 3982: Window opened, adding border gadgets
(15.500009) desktop/browser.c browser_window_navigate 1895: bw 0x9660ba0, url about:welcome
(15.533344) desktop/browser.c browser_window_navigate 1994: Loading 'about:welcome'
(15.566682) amiga/gui.c ami_gui_splash_close 5254: Closing splash window

The MuForce hit:

Code: [Select]

LONG READ from FBFBFC03                        PC: 08C8352A
USP : 09240108 SR: 0010  (U0)(-)(-)  TCB: 08B40040
Data: 00000004 00000003 09281228 00000400 00000100 022FA539 022C9399 08C73284
----> 08C73284 - "NetSurf"  Hunk 0000 Offset FFFFFFFC
Addr: FBFBFBFB 08B40040 0912DE2C 08B40040 00000000 092401B0 08021A14 08280620
Stck: 00570001 0924018E 09281228 00000400 0912DE2C 08021A14 00030000 08B49A3A
Stck: 00000028 45BE29A9 00000118 00000400 00000100 022FA539 022C9399 08C73284
Stck: 00000001 08C3A9F8 0912DE2C 08B40040 00000000 09240178 08CA17E0 08020000
----> 08C8352A - "NetSurf"  Hunk 0000 Offset 000102A2
----> 0912DE2C - "NetSurf"  Hunk 0000 Offset 004BABA4
----> 08B49A3A - "C/MuGuardianAngel"  Hunk 0000 Offset 00002162
----> 08C73284 - "NetSurf"  Hunk 0000 Offset FFFFFFFC
----> 0912DE2C - "NetSurf"  Hunk 0000 Offset 004BABA4
----> 08CA17E0 - "NetSurf"  Hunk 0000 Offset 0002E558
08c834ea :  181c                       move.b (a4)+,d4
08c834ec :  206d ffd6                  movea.l -$2a(a5),a0
08c834f0 :  7004                       moveq.l #$4,d0
08c834f2 :  b0a8 000e                  cmp.l $e(a0),d0
08c834f6 :  6622                       bne.s $8c8351a
08c834f8 :  2f2d ffce                  move.l -$32(a5),-(a7)
08c834fc :  4eb9 08c9 8996             jsr $8c98996
08c83502 :  588f                       addq.l #$4,a7
08c83504 :  4a40                       tst.w d0
08c83506 :  6708                       beq.s $8c83510
08c83508 :  6100 24c4                  bsr $8c859ce
08c8350c :  6000 1808                  bra $8c84d16
08c83510 :  2b6d ffd2 ffd6             move.l -$2e(a5),-$2a(a5)
08c83516 :  6000 17ee                  bra $8c84d06
08c8351a :  41ed ffde                  lea.l -$22(a5),a0
08c8351e :  2f08                       move.l a0,-(a7)
08c83520 :  2f3c 0057 0001             move.l #$570001,-(a7)
08c83526 :  206d ffce                  movea.l -$32(a5),a0
08c8352a : *2f28 0008                  move.l $8(a0),-(a7)
08c8352e :  4eb9 0912 50d0             jsr $91250d0   ; <- this is DoMethod()
08c83534 :  4fef 000c                  lea.l $c(a7),a7
08c83538 :  2b40 fffc                  move.l d0,-$4(a5)
08c8353c :  4aad fffc                  tst.l -$4(a5)
08c83540 :  6700 17c4                  beq $8c84d06
08c83544 :  222d fffc                  move.l -$4(a5),d1
08c83548 :  0281 ffff 0000             andi.l #-$10000,d1
08c8354e :  2b41 ff70                  move.l d1,-$90(a5)
08c83552 :  0cad 0004 0000 ff70        cmpi.l #$40000,-$90(a5)
08c8355a :  6700 16e2                  beq $8c84c3e
08c8355e :  0cad 0004 0000 ff70        cmpi.l #$40000,-$90(a5)
08c83566 :  6236                       bhi.s $8c8359e
08c83568 :  0cad 0002 0000 ff70        cmpi.l #$20000,-$90(a5)
Name: "Shell Process"  CLI: "NetSurf"  Hunk 0000 Offset 000102A2

I don't see many symbols beside the call to DoMethod() so the function doing the DoMethod() call is probably a "static" function. The problem is a bad pointer argument being passed to DoMethod(). The base pointer above is A0=FBFBFBFB and on my current run is A0=A7A7A7A7. This is probably an unitialized pointer from MuGuardianAngel munging of memory. I may know after I step a bit but I'll post this in case it crashes.

Edit: I believe this hit is from ami_handle_msg() in /amiga/gui.c. I can see calls to ami_401login_event() and ami_try_quit() probably before the DoMethod() call and a call to ami_gui_get_space_box() right after. What is generating the call to DoMethod() I can't tell from the source. DoMethod() is a GCC or NetSurf function with what looks like 3 stack based arguments and *not* an AmigaOS library call.

Edit2: I believe the next 2 hits from this same build come from ami_mime_entry_locate in /amiga/filetype.c. This would be a bit after the GetHead(ami_mime_list). There is another unitialized pointer in a list or structure.

[matthey]

DoMethod is an amiga.lib function.  I think what you're referring to must be the RA_HandleInput() call (which is a macro - and actually calls DoMethod) around here in the source (there's a ami_gui_trap_mouse before the ami_gui_get_space_box though, unless you're only seeing functions that are being called).

The DoMethod() that I describe is called with a BSR and *not* JSR (xxx,A6) so it is *not* an AmigaOS call with a library base in A6. The DoMethod() function calls some AmigaOS functions though. There is a good chance the code that gives the DoMethod() is from RA_HandleInput() and may be from amiga.lib. It looked too big to me to be a stub.

I've just twigged what the cause of that is.  I'll put a fixed version up later.

The freeze was from a bullet.library SetInfoA() call if you want verification .

[matthey]

Should you check that list->lh_Head isn't null also ?

It should not be necessary unless checking for a corrupt or unitialized list (an empty list with no nodes is o.k). An AmigaOS list is initialized by setting the lh_Head field to the address of lh_Tail. Adding or removing nodes should never make this field NULL. An empty list (initialized List header but no nodes) will have the list lh_Head field set to the address of lh_Tail (list->lh_Head = &list.lh_Tail). The list header acts like a node when transversing the list in either direction.

Edit: The info above is good but the other I had was wrong. The list or list header (List structure) is not the same as the list Head (List->lh_Head->Node) which confused me. Chris's GetHead() still looks correct which extracts the Head node from a List header after checking that the pointer to the list is not NULL and that the list is not empty. The list is empty if (NULL == list->lh_Head->ln_Succ) or (list->lh_TailPred == (struct Node *)list). There is a macro called IsListEmpty() in exec/lists.h which uses the latter way to check for an empty list and could give something like the following if used.

Code: [Select]

struct Node *GetHead(struct List *list)
{
struct Node *res = NULL;

if ((list != NULL) && !IsListEmpty(list))
           res = list->lh_Head;
return res;
}

It's more readable to me and should generate a little more optimal code than what Chris is using.

[matthey]

Code: [Select]

if (node->ln_Succ->ln_Succ == NULL) return NULL;

This is interesting, and appears to have solved my problem.

Perhaps the code above will not get the last node in a list? I suspect that some of the list handling code doesn't handle exec empty lists correctly (an empty exec list looks like there is one more node in it when it is empty but it is actually pointing back to the list header) or tries to process the last link in the list (either direction) which is the list header (valid data nodes have non-NULL successor and predecessor pointers).

[matthey]

I think it stops the list header being used as a node, whereas without it the list header ends up being parsed and we get problems.

All my lists are checked with Is(Min)ListEmpty before proceeding even to the GetHead.

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.

I'm still getting the crash around RA_HandleInput.  Curiously it sometimes gets past that and tells me a WMHI_ACTIVE message (262144 - which I think is WMHI_ACTIVE anyway) is received.  WMHI_ACTIVE doesn't do much at all.

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.

[matthey]

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

I'm working with the NetSurf executable which is now 5920060 bytes. A "Scanning fonts..." requestor now opens and it gets almost 60% of the way through the top guage and barely started on the bottom guage as it scans my large collection of fonts before I get an address error exception from the bullet.library. The return value on the stack from an RTS (Return from Subroutine) is 0xffffffff (-1 signed) and the PC must maintain even alignement thus the address error. The last debug output is:

Code: [Select]

amiga/font_scan.c ami_font_scan_fonts 293: Found 0 new glyphs (total = 474)
amiga/font_scan.c ami_font_scan_fonts 290: Scanning NewBrunswick_BoldItalic
amiga/os3support.c OpenOutlineFont 105: Using font engine bullet
amiga/font_scan.c ami_font_scan_fonts 293: Found 0 new glyphs (total = 474)
amiga/font_scan.c ami_font_scan_fonts 290: Scanning NewBrunswick_Italic
amiga/os3support.c OpenOutlineFont 105: Using font engine bullet

It's strange that bullet.library didn't crash with the NewBrunswick_BoldItalic font before this. Maybe this font is from Wordworth?

Edit: I tried the NewBrunswick_Italic font in WordWorth to make sure it wasn't corrupt and it worked fine. I then retried NetSurf and didn't have any problems in the font scanning this time.

I am past the screen and window open and I believe farther than ever. The PC seems to have gotten lost and points to 0xc0. The last debug output is:

Code: [Select]

(274.300005) image/png.c info_callback 182: size 17 * 17, rowbytes 68
(274.333339) content/content.c content_convert 281: content file:///Big/NetSurf/Resources/Icons/search.png (0x96fe2e0)
(274.383341) image/image_cache.c image_cache_add 480: centry 0x96fe738, content 0x96fe2e0, bitmap 0x96d9cf4
(274.516676) content/content.c content__init 80: url file:///Big/NetSurf/Resources/en/welcome.html,faf -> 0x96feb48
(274.599994) render/html_css.c html_css_new_stylesheets 548: 2 fetches active
(274.633327) render/html_css.c html_css_new_stylesheets 575: 3 fetches active
(274.666659) content/content.c content_add_user 599: content file:///Big/NetSurf/Resources/en/welcome.html,faf (0x96feb48), user 0x8eedece 0x9731c78
(275.116690) content/content.c content_convert 281: content file:///Big/NetSurf/Resources/en/welcome.html,faf (0x96feb48)
(275.183337) render/html.c html_convert 1026: quirks set to 0
(275.200004) render/html.c html_convert 1030: 2 fetches active
(275.233343) render/html_css.c html_stylesheet_from_domnode 199: 3 fetches active
(275.266673) render/html_css.c html_css_process_modified_style 276: Updating sheet 0x000000 with 0x99a2020
(275.350010) content/content.c content__init 80: url x-ns-css:0 -> 0x99a4238
(275.433342) content/content.c content_add_user 599: content x-ns-css:0 (0x99a4238), user 0x8eedece 0x99a2020
(275.583324) content/content.c content_convert 281: content x-ns-css:0 (0x99a4238)
(275.616661) render/html_css.c html_convert_css_callback 105: done stylesheet slot 4 'x-ns-css:0'
(275.666659) render/html_css.c html_convert_css_callback 107: 2 fetches active
(275.766667) content/content.c content__init 80: url file:///Big/NetSurf/Resources/default.css -> 0x99caf30
(275.816664) content/content.c content_add_user 599: content file:///Big/NetSurf/Resources/default.css (0x99caf30), user 0x8eedece 0x9720600
(275.899998) content/content.c content_convert 281: content file:///Big/NetSurf/Resources/default.css (0x99caf30)
(275.966665) render/html_css.c html_convert_css_callback 113: stylesheet resource:user.css failed: UnacceptableType
(276.016666) render/html_css.c html_convert_css_callback 117: 1 fetches active
(276.133335) content/content.c content__init 80: url file:///Big/NetSurf/Resources/nsdefault.css -> 0x99c7ec8
(276.183337) content/content.c content_add_user 599: content file:///Big/NetSurf/Resources/nsdefault.css (0x99c7ec8), user 0x8eedece 0x99db9e8
(276.483342) content/content.c content_convert 281: content file:///Big/NetSurf/Resources/nsdefault.css (0x99c7ec8)
(276.533347) render/html_css.c html_convert_css_callback 105: done stylesheet slot 0 'file:///Big/NetSurf/Resources/default.css'
(276.583325) render/html_css.c html_convert_css_callback 107: 0 fetches active
(276.616659) render/html.c html_begin_conversion 1083: Completing parse
(276.649993) render/html.c html_finish_conversion 574: DOM to box (0x96feb48)
(276.783331) render/html_object.c html_fetch_object 713: 1 fetches active
(276.833332) content/content.c content__init 80: url file:///Big/NetSurf/Resources/netsurf.png -> 0xa3a6050
(276.883331) content/content.c content_add_user 599: content file:///Big/NetSurf/Resources/netsurf.png (0xa3a6050), user 0x8eedece 0x97232b0
(277.000003) content/content.c content_convert 281: content file:///Big/NetSurf/Resources/netsurf.png (0xa3a6050)
(277.050000) image/image_cache.c image_cache_add 480: centry 0xa3a64a8, content 0xa3a6050, bitmap 0x000000
(277.266673) content/content.c content__init 80: url file:///Big/NetSurf/Resources/netsurf.png -> 0xa3c8b20
(277.316673) content/content.c content_add_user 599: content file:///Big/NetSurf/Resources/netsurf.png (0xa3c8b20), user 0x8eedece 0x9aefe10
(277.416676) content/content.c content_convert 281: content file:///Big/NetSurf/Resources/netsurf.png (0xa3c8b20)
(277.466675) image/image_cache.c image_cache_add 480: centry 0xa3c9070, content 0xa3c8b20, bitmap 0x000000
(277.516677) render/html_object.c html_object_callback 161: 0 fetches active
(277.583324) render/html.c html_box_convert_done 86: Done XML to box (0x96feb48)
(277.616658) content/content.c content__reformat 360: 0x96feb48 file:///Big/NetSurf/Resources/en/welcome.html,faf
(277.983335) content/content.c content_open 742: content 0x96feb48 file:///Big/NetSurf/Resources/en/welcome.html,faf
(278.033334) content/content.c content_open 742: content 0xa3c8b20 file:///Big/NetSurf/Resources/netsurf.png
(278.100003) desktop/browser_history.c browser_window_history_add 513: Creating thumbnail for file:///Big/NetSurf/Resources/en/welcome.html,faf

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.

[matthey]

here it opens window as well, i give it plenty of stack to be sure, but is there a way to redirect the netsurf debug to serial?

I expect the error output from NetSurf -v is going to stderr instead of stdout as I tried to redirect it and it didn't work. If stdout was used it would be possible to use:

Code: [Select]

>NetSurf -v >SER:

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

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.

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. I'll take a look at the new executable. At some point we should break through the startup and have a running NetSurf.

Edit: I get further now but to another freeze:

Code: [Select]

amiga/font.c ami_font_open 381: Font cache miss: CSCourierOblique
amiga/os3support.c OpenOutlineFont 105 Using font engind bullet
amiga/font.c ami_font_open 396: Bold font defined for CSCourierOblique is CSCourierBoldOblique
amiga/font.c ami_font_open 404: Warning: No designed italic font defined for CSCourierOblique
amiga/font.c ami_font_open 410: Warning: No designed bold-italic font defined for CSCourierOblique
desktop/browser.c browser_window_update_favicon 1141fetching general favicon from 'resource:favicon.ico'
./content/fs_backing_store.c set_store_entry 719: url:http://www.google.com/favicon.ico
./content/fs_backing_store.c store_open 828: opening PROGDIR:Users/userCache/d/M/I/2/MI2VURB
./content/fs_backing_store.c store 1304: Writing 5430 bytes from 0x9787998
./content/fs_backing_store.c set_store_entry 719: url:http://www.google.com/favicon.ico
./content/fs_backing_store.c store_open 828: opening PROGDIR:Users/userCache/m/M/I/2/MI2VURB
./content/fs_backing_store.c store 1304: Writing 433 bytes from 0xa5150b8
./content/fs_backing_store.c get_store_entry 660: url:http://www,google.com/favicon.ico
./content//fs_backing_store.c entry_release_alloc 1324: freeing 0xa5150b8
content/llcache.c llcache_persist 2494: Overran timestlot
content/content.c content__init 80: url file:///Big/NetSurf/Resources/favicon.png (0xa4ecab0), user 0x8fb927a 0xa4fc720
image/png.c info_callback 182: size 17* 17, rowbytes 68
content/content.c content_convert 281: content file:///Big/NetSurf/Resources/favicon.png (0xa4ecab0)
image/image_cache.c image_cache_add 480: centry 0xa4ec5f0, content 0xa4ecab0, bitmap 0x97c9bec

And follows is the NULL pointer hit in P96 Voodoo.card which maybe is bitmap and/or gfx related?

Code: [Select]

LONG READ from 00000000                        PC: 08851D8C
USP : 097269C8 SR: 8004  (U0)(-)(-)  TCB: 0952E6C8
Data: 03000000 FFFFFFFE 00100000 0000000F 00000000 00000010 000000E0 00000009
Addr: 00000000 60100000 09726A84 09726AAC 0884BE74 09726A94 08851C18 08280BD8
Stck: 00000010 00000010 000000FF 08013BB4 0883672A 00000010 00000010 68168410
Stck: 0000009E 00000014 00000010 00000010 000000E0 000002FF 00000000 09A27608
Stck: 0A3E6A30 0A3E6648 08013BB4 08851C18 00000011 00000000 FFFFFFFF 3FFF097A
----> 08851D8C - "LIBS:picasso96/Voodoo.card"  Hunk 0000 Offset 00002ABC
----> 0883672A - "LIBS:picasso96/rtg.library"  Hunk 0004 Offset 0000A0BA
----> 08851C18 - "LIBS:picasso96/Voodoo.card"  Hunk 0000 Offset 00002948
08851d4c :  e548                       lsl.w #$2,d0
08851d4e :  322a 0004                  move.w $4(a2),d1
08851d52 :  9240                       sub.w d0,d1
08851d54 :  5342                       subq.w #$1,d2
08851d56 :  2052                       movea.l (a2),a0
08851d58 :  203c 0300 00cc             move.l #$30000cc,d0
08851d5e :  082a 0001 0007             btst #$1,$7(a2)
08851d64 :  6704                       beq.s $8851d6a
08851d66 :  103c 0055                  move.b #$55,d0
08851d6a :  082a 0000 0007             btst #$0,$7(a2)
08851d70 :  6604                       bne.s $8851d76
08851d72 :  0040 0100                  ori.w #$100,d0
08851d76 :  2340 0070                  move.l d0,$70(a1)
08851d7a :  082a 0002 0007             btst #$2,$7(a2)
08851d80 :  663e                       bne.s $8851dc0
08851d82 :  7800                       moveq.l #$0,d4
08851d84 :  182a 0006                  move.b $6(a2),d4
08851d88 :  6616                       bne.s $8851da0
08851d8a :  3002                       move.w d2,d0
08851d8c : *2358 0080                  move.l (a0)+,$80(a1)
08851d90 :  51c8 fffa                  dbra d0,$8851d8c
08851d94 :  d0c1                       adda.w d1,a0
08851d96 :  51cb fff2                  dbra d3,$8851d8a
08851d9a :  4cdf 041c                  movem.l (a7)+,d2-d4/a2
08851d9e :  4e75                       rts
08851da0 :  2f05                       move.l d5,-(a7)
08851da2 :  3002                       move.w d2,d0
08851da4 :  e9d0 5900                  bfextu (a0){d4:$0},d5 ;extended opcode
08851da8 :  2345 0080                  move.l d5,$80(a1)
08851dac :  5888                       addq.l #$4,a0
08851dae :  51c8 fff4                  dbra d0,$8851da4
08851db2 :  d0c1                       adda.w d1,a0
08851db4 :  51cb ffec                  dbra d3,$8851da2
08851db8 :  2a1f                       move.l (a7)+,d5
08851dba :  4cdf 041c                  movem.l (a7)+,d2-d4/a2
08851dbe :  4e75                       rts
08851dc0 :  2f05                       move.l d5,-(a7)
08851dc2 :  7800                       moveq.l #$0,d4
08851dc4 :  182a 0006                  move.b $6(a2),d4
08851dc8 :  661c                       bne.s $8851de6
08851dca :  3002                       move.w d2,d0
Name: "netsurf"  CLI: "netsurf"

image_cache_add() OK
content_set_ready() OK
content_set_done() Freeze!!!

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?

[matthey]

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)

I don't think it is necessary to specify BMF_DISPLAYABLE for a bitmap that is never displayed on screen (a double buffering buffer would need it though). I believe you should use the displayed Window->RPort->Bitmap or Screen-RastPort->BitMap as the friend_bitmap for best performance (and no chip mem used with RTG) when allocating with AllocBitMap().

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

Nice to know, I could have always lowered the resolution but I only selected 800x600x32 and some browsers today may have issues at 640x480. The simple_refresh option may end up being faster on a gfx board. I'd rather not go crazy with options until we get the basic NetSurf working.

Be sure to see my Final Edit from my last post to hopefully fix the last freeze.

There is a requestor which pops up asking for PROGDIR right around the time the screen opens. It doesn't seem to stop NetSurf or affect anything whether I choose a gadget or ignore it. Do you get the requestor? Any idea what is causing it?

[matthey]

With Os 3.9 and the shell from Os 3.9, it is "star less than greater than". Thus, "program "star less than greater than"foo" redirects the standard error to a file (or a device). Actually, it's in the manual. I wonder why so many people don't find the time to browse it for such questions.

I picked up and read my AmigaOS 3,1 manual that was sitting beside me. I don't know if wawa was using AROS (based on 3.1), UAE (probably with 68k AROS Vision knowing wawa) or AmigaOS 3.9. I only assumed the lowest modern (in Amiga terms) Amiga base. In a perfect Amiga world, all 68k users with a 68020+ would be using AmigaOS 3.9 and it would still be developed. Of course if AmigaOS 3.9 was still developed then the AmigaOS and Reaction APIs would be more similar to AmigaOS 4 and Chris wouldn't have wasted so much time adding AmigaOS 3 compatible code and I wouldn't have wasted so much time debugging it. It doesn't do any good to complain about it as that is not productive. Instead you see us doing it. Thanks for helping to provide the debugging tools to do it. I also understand that you are trying to be helpful and realize the importance of what we are trying to do here .

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

Startup completes here with no freezes or hits and displays the startup page! Good job! 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.

[matthey]

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

Yes! This is the page I see although with a few more glitches. There were no more hits up to that point for me.

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.

No problems here until I try to interact with something. It seems to be stable sitting there. I'll try again to see if it intermittently works.

[matthey]

links and filling the forms works, though the browser isnt exactly responsive on uae, so it might make impression as it locks up on real hardware.i will mute the debug now and see how that works.

edit: looks like the webpages get plotted in four colors;)??

I was able to get through startup to the welcome page again (this time with no -v). Typing in amiga.org for the URL works but hitting return crashes for me with no guru or recorded hits. I have more gfx gliches than you wawa. It's possible that the slower speed on the real hardware is a problem but I wouldn't think so. The 68k code is really aweful, even for optimizations being turned off.

Code: [Select]

  move.l (a0),(a1)
   addq.l #4,a0
   addq.l #4,a1

instead of:

Code: [Select]

  move.l (a0)+,(a1)+

doesn't make debugging easier. There is a *lot* of room for optimization improvement.

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

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

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