We need an iBrowse replacement for 68k!!!

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

[matthey]

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

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.

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

The Amiga makefile used to specify:

CFLAGS += -O2 -gstabs

but Chris probably changed to -O0 or -O1 because of a GCC compiler error with tag lists on the 68k. The code looks like it is compiled for the 68000 currently also. Good starting options would normally be something like:

CFLAGS += -O2 -m68020-060 -fomit-frame-pointer -gstabs

and link with -noixemul if possible? What do you think?

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.

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.

[matthey]

Yes I'd change it to -m68030 or even -m68040 (68000 is a bad target!).

A -m68020-60 or -m68060 target should get instruction scheduling (instruction scheduling can make a huge difference on a superscalar CPU like the 68060) and won't use trapped 64 bit integer instructions which is much better for the 68060. The 68060 instruction scheduling doesn't hurt any other 68k processor (only disadvantage is slower compiling). Losing the 64 bit integer instructions does slow the 68020-68040 dependent on the code. The best would probably be to have a -m68030 compile for 68020-68040 and -m68060 compile for the 68060. For testing purposes, anything but a 68000 compile should give a nice speedup. The 68000 does fine for executables <64kB but NetSurf is a tad bigger.

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.

Yea. Maybe NovaCoder will start playing with the sources .

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*

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

[matthey]

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?

The direct_render:1 in Choices made a difference:

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

The fonts have a grey halo and the amiga.org pic doesn't even try to display but it is actually more usable if less readable. This is with the old build. I'll try the 68020 build now.

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

And with direct_render:1 it looks like this:

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

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?

[matthey]

New build up.  This should fix the problem with the previous page appearing behind the current one. (edit: although it might blotch it out in the wrong colour depending on when you downloaded!)

No improvement in the visuals. It still looks like this:

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

It seems a little bit faster but nowhere close to Arti's NetSurf SDL builds yet.

[matthey]

Disappointing.  I've done the P96 updates anyway, so try the one I've just uploaded and see how that works.

I'll have a think about why the page isn't clearing.

Something is messed up with the P96 visuals:

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

I've also had another go on my A1200 and managed to get the main window up.  I think it wasn't working before due to lack of memory, so I might invest in a 32MB SIMM to make it easier for me to test.

I thought NetSurf was pretty good on memory. I expect it should be usable with 32MB. Maybe you were out of chip mem before. Almost all 2MB of my chip mem is free because I was using RTG. If you were using AGA in a descent resolution and depth with a picture backdrop then you probably ran out of chip memory. You solved the chip mem problem though. NetSurf should easily run on any Amiga with 1 MB of chip mem .

[matthey]

Hmm, that can only be to do with how I'm allocating the off screen bitmap, as everything else is the same (except the bitmap code, which is clearly working).

Does the log show your screen as 32 or 24 bit? (depth= somewhere near the top)

What log? The -v stderror? I have selected 800x600x32 BGRA (little endian) every time it has asked. I tried mask_alpha:0 in Choices with the lastest build but it didn't help. NetSurf does create a new user in Users with my name rather than "user" now.

Chip RAM seems fine - 1.8MB free at the point it crashes (I reduced it to a 4 colour hires screen . Only 90K of fast mem though! It plummets from 6 to 1 MB just before the window opens, so unless there's a bug causing it to soak up memory I don't think I can gain enough to make it get any further. That's with simple refresh windows and a small tile size. (edit: hold on, shouldn't it be using chip ram when fast runs out?)

Yes, chip mem should be used when fast memory runs out. It might keep you going but there is a big hit in speed when using chip mem instead of fast mem. What TCP/IP stack are you using? The selection of stack can make a significant difference in memory usage. If NetSurf would work without a stack online, you could load html from your hard drive for testing saving a significant amout of memory.

I think the outline fonts are eating a fair bit (as well as being slow), looking at that code it's going to be easier to conditionally compile either for outline or bitmap fonts, rather than trying to support both. I might be able to make it a runtime option. I'll have a play with that when I have more time.

I don't know that the outline fonts are working. My font Choices that you had me configure ended up being changed to:

Code: [Select]


font_cursive:CGTimes


The new user in Users doesn't even have this.

[matthey]

Yes, the -v log.  I added something to report the screen depth.  I know you're on 32-bit, but I'd like to know if that knows as it could be causing the off-screen bitmap to be set up wrong.

I've put a new build up anyway which might fix it, but if it doesn't I'll need to know what the screen depth is being reported as.

edit: I've just added the bitmap tiler as well, which might solve some other graphical glitches or (more likely) create some new ones.

Using the old build I get "amiga/plotters.c ami_init_layers 102: Screen depth = 24"

Edit: The new version is no better than the version before it.

Somewhere along the line you've set or changed the USER env-var.

It was probably as part of one of my scripts I use before programming, So NetSurf is multi-user on the Amiga .

MiamiDx, which is probably not the best at memory conservation, given it uses MUI.

Miami has a Reaction GUI option (I don't recall MiamDx getting one) which would share many of the Reaction GUI resources such as libraries, gadgets and images saving memory. I use the AmigaOS 3.9 version of Genesis which also uses Reaction. Roadshow may use the least amount of memory having no GUI.

Unfortunately it won't as bsdsocket is loaded by clib2, and there's not much I can do to stop it (and I'm not sure if it would work without it anyway, given there is sockets-related code in the main loop)

Bummer. Being able to work offline is a nice feature,

[matthey]

OK, try the new build and see if that fixes the colour issues on P96.  If it doesn't I'll go back to Plan A.

Nope. I can't see any difference from the last build.

[matthey]

I've just put a new build up (hopefully this one will work with p96 modes).

Still no help. It looks the same.

I'm going to be out of town for a few days. NetSurf seems to be working good enough for other beta testers now. I'll be able to help with debugging more when I get back. Good luck.

[matthey]

I'm back. I tried the newest archive and it has problems. The welcome page no longer loads nor does any other page. I can't quit either. I get this MuForce hit:

Code: [Select]

LONG WRITE to  ABADF00D        data=090D7B6C   PC: 00F81A10
USP : 090D7B68 SR: 0000  (U0)(F)(-)  TCB: 090C8758
Data: 097E69E8 00000034 00000318 0000024B 00000318 0000024B 00000034 00000008
Addr: ABADF00D 090D7B6C 09086FBC 090C8758 097E698C 097E698C 080008D4 0828056C
Stck: 00F82D50 097E69E8 ABADF00D 090C8758 097E698C 00000034 097E69D4 09086FBC
Stck: 0882AF88 090D7BFE 0883486E 09086FBC 00000318 0000024B 00000000 00000000
Stck: 00000000 00000000 09086FBC 090C8758 00000000 090D868C 08013BB4 00000400
----> 00F81A10 - "ROM - exec 45.20 (6.1.2002)"  Hunk 0000 Offset 00001962
----> 00F82D50 - "ROM - exec 45.20 (6.1.2002)"  Hunk 0000 Offset 00002CA2
----> 09086FBC - "NetSurf"  Hunk 0002 Offset 0003B604
----> 0882AF88 - "LIBS:picasso96/rtg.library"  Hunk 0002 Offset 000165B0
----> 0883486E - "LIBS:picasso96/rtg.library"  Hunk 0004 Offset 00007EB6
----> 09086FBC - "NetSurf"  Hunk 0002 Offset 0003B604
----> 09086FBC - "NetSurf"  Hunk 0002 Offset 0003B604
00f81a00 :  5888                       addq.l #$4,a0
00f81a02 :  2028 0004                  move.l $4(a0),d0
00f81a06 :  2149 0004                  move.l a1,$4(a0)
00f81a0a :  c188                       exg.l d0,a0
00f81a0c :  48d1 0101                  movem.l d0/a0,(a1)
00f81a10 : *2089                       move.l a1,(a0)
00f81a12 :  4e75                       rts
Name: "NetSurf"

I believe ABADF00D is a pointer from unitialized memory. This may be exec list related. Do I need to debug this?

[matthey]

i didnt test quitting till lately, so i cant say it was possible previously, still it definitely didnt worked with the last one. matt, have you test it, since it may been the case all along and not being a new bug?

I went back to the last version I was using before I left and it works fine including displaying pages and quitting from the menu,

@Chris
The MuForce hit occurs inside exec.library AddTail(). The list *lh_Tail (offset 4) is where ABADF00D comes from so the list is unitialized or corrupt. I'll see if I can figure out where in NetSurf the call comes from.

Edit: I believe the hit comes from a graphics.library RectFill() call in ami_plot_clear_bbox(). RectFill() in the graphics.library calls a function in the P96 rtg.library which calls an ObtainSemaphore() in exec.library which calls AddTail() where the hit happens and then it calls Wait() where it waits for a very long time.

[matthey]

OK, that should be fixed in the new build I've just put up.

Same result here also, It still has the hit in AddTail() from RectFill() and then NetSurf is unresponsive.

[matthey]

strangely under uae muforce doesnt detect any hits (mmu on, jit disabled). probably proves again that testing on real hw is more reliable. must check with my a4k again.

MuGuardianAngel is munging memory and setting up memory allocation detection walls here resulting in ABADF00D. I may even have increased the defaults.

Here is the script I have been using:

Code: [Select]


Run >NIL: <NIL: C/MuForce AREGCHECK DREGCHECK STACKCHECK STACKLINES=3 DISPC DISRANGE=64 FILE=VMEM:MuHits.txt BUFFERSIZE=100000
Wait 3
Run >NIL: <NIL: C/MuGuardianAngel TOMUFORCE SHOWHUNK NAMETAG DISPC DISRANGE=128 STACKCHECK SHOWSTACK STACKLINES=3 AREGCHECK DREGCHECK PRESIZE=64 POSTSIZE=64 DUMPWALL CONSISTENCY
endcli >NIL:


[matthey]

Detecting hits with Enforcer, MuForce, GuardianAngel and any similar tool is matter of good luck. MuForce only detects illegal memory accesses to unused address space. GuardianAngel detects illegal memory accesses to unused memory but if your memory is heavily used by other applications it detects nothing.

So less is more, more or less? The most common hits are to the zero page which are not luck. A hit from using munged memory is also not luck if the munging number is chosen carefully like 0xABADF00D (the most significant bit is 1). This address is >2GB (or negative if using a two's complement signed number) which is highly unusual to be in use as regular memory on an Amiga anyway. Sure, there is some luck to picking up a random hit due to lack of memory protection but I believe this is a small minority of hits. The ABADF00D hit in NetSurf was detected 4 out of 4 times I tried to catch it by the way.

[matthey]

Hmm, try now.

It still has the hit in the same location and then becomes unresponsive.