We need an iBrowse replacement for 68k!!!

[NovaCoder]

(Not picking on you, Yasu)

I understand that not everyone has a big system, but come on, this is why we can't have nice things.

The "it's gotta work on an A500" mentality didn't help us in the 90's and it's not helping now.

At some point, you need to get some upgrades if you want to run software that wasn't made in the 90's, for 80's systems.

It's a good question.

You can't expect a Classic to offer Chrome levels of speed, that's crazy.

I think with an 060 and RTG you should be able to create a 'usable' browser experience, AGA wouldn't be as usable of course but should still be better than using IBrowse.

Usable doesn't mean fast or fully featured, just that most sites would work and be rendered before you get bored.

Anything less than an 060 (or FAST FPGA!) would be better off sticking to AWeb or I browse.

[chris]

Will Netsurf work on a plain A1200 with 4 MB fast RAM?

I doubt it; the executable alone is ~5.5MB.

I'd suggest you'd need at least 8MB to start it, and probably 16MB to actually view any pages.  But I don't know for sure until I get it running, and I don't have a clue what the speed would be like on a 14MHz '020/AGA.

[Yasu]

So, Netsurf on faster machins and an open sourced Ibrowse for slower ones?

[utri007]

So, Netsurf on faster machins and an open sourced Ibrowse for slower ones?

There woun't be open source iBrowse I'm a afraid.

But any way, I do not understand what you would possible do with 4mb ram Amiga on internet?

FTP would be more suitable for that kind of machine.

[Thorham]

The best way is to write an optimized html+css engine and use optimized codecs for images. Rendering can be done in HAM6/HAM8 at good quality (and is similar in speed to error diffusion). Meynaf from EAB has nice and fast codecs in his image viewer, but fast html+css still has to be done from scratch.

[Heiroglyph]

If nothing else, this browser builds FAST.

I haven't tried cross compiling yet, just made sure that I could build and run the Linux version.

Hopefully I'll get the Amiga build working tonight and I'll test in UAE until my hardware comes in.

I've got to get a source level debugger set up somehow though. Working on something as big as a browser with only assembly debugging and printf's is like building a ship in a bottle when you just want a ship.

[matthey]

I've got to get a source level debugger set up somehow though. Working on something as big as a browser with only assembly debugging and printf's is like building a ship in a bottle when you just want a ship.

BDebug is not a true source level debugger but it can display the current source line as you step through the 68k assembler executable. You do have to get to the main() function before it will work and it does have to be able to find your source code. BDebug is in the Barfly package.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

The docs say that it supports STABS as well as the SAS/C (SAS D1) debug info. GCC can output STABS with a switch which Chris has selected in the makefile of the NetSurf /amiga directory. Vbcc with a 68k target outputs SAS/C debug by default (with -g in vbcc 0.9d).

[Heiroglyph]

BDebug is not a true source level debugger but it can display the current source line as you step through the 68k assembler executable. You do have to get to the main() function before it will work and it does have to be able to find your source code. BDebug is in the Barfly package.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

The docs say that it supports STABS as well as the SAS/C (SAS D1) debug info. GCC can output STABS with a switch which Chris has selected in the makefile of the NetSurf /amiga directory. Vbcc with a 68k target outputs SAS/C debug by default (with -g in vbcc 0.9d).

Thanks, I'll have to check that out as an option.

I'm spoiled to the Visual Studio and even the SAS/C debuggers. Normally I'd use vbcc and the SAS/C debugger.

I sure wish this would build with vbcc. At some point I'm going to see how gcc specific this codebase is.

[wawrzon]

please share the debugging methods as i have now to get at it myself. winuae has a built in debugger that can be accessed via shift+f12 or something like that. also i came over this:http://eab.abime.net/showthread.php?t=60759
still i didnt come to how to idenfify offending source line as yet.

[Yasu]

There woun't be open source iBrowse I'm a afraid.

But any way, I do not understand what you would possible do with 4mb ram Amiga on internet?

FTP would be more suitable for that kind of machine.

Being able to see a homepage correctly would be enough. And use Paypal, Amazon and other SSL related stuff. I don't demand that you can do everything, just that homepages doesn't look like crap.

[utri007]

Being able to see a homepage correctly would be enough. And use Paypal, Amazon and other SSL related stuff. I don't demand that you can do everything, just that homepages doesn't look like crap.

I'm afraid that there woun't be web browser wich will do that with 4mb ram, it just a impossible.

[chris]

First, make sure you are using the 3.9 NDK as Novacoder suggests. Next, you might try these fixed NDK 3.9 includes:

http://www.heywheel.com/matthey/Amiga/fixed-includes-ndk39.lha

They are from the dead AWeb web site. AWeb uses ClassACT/Reaction also and these were probably fixed by Andy Broad (broadblues).

Unfortunately they appear to be no better than the ones I was using

[kolla]

The most feasable way to bring a modern browsing experience to classic Amiga, would be a with a dedicated proxy server that renders and optimize web pages for a dedicated browser on the Amiga. Something akin to what Opera does with Opera Coast and Opera Mobile, and I believe Google does too with Chrome on mobile. SSL complicates things though

[matthey]

I'm spoiled to the Visual Studio and even the SAS/C debuggers. Normally I'd use vbcc and the SAS/C debugger.

SAS/C's debugger CPR is another good GUI debugger and better than BDebug in some ways. I think BDebug is better overall though. Either will work with SAS/C debug info giving the choice of 2 powerful tools.

I sure wish this would build with vbcc. At some point I'm going to see how gcc specific this codebase is.

From my quick view, most of the code does not use GCCisms (there was an ASM define which I did not track down where it was used though). The build system does uses GCC specific switches. Some lib dependencies may be a problem also. It would take some work to compile with vbcc because it's enough different but then that difference or lack of some bug in GCC or its setup could allow the current problem to be avoided. Compiling with more than one compiler helps to find some problems.

please share the debugging methods as i have now to get at it myself. winuae has a built in debugger that can be accessed via shift+f12 or something like that. also i came over this:http://eab.abime.net/showthread.php?t=60759
still i didnt come to how to idenfify offending source line as yet.

Remote debugging is usually only necessary for low level debugging, driver debugging and debugging while booting where the system is in a delicate state or execution can't be stopped. I believe SAS/C's CPR also has a remote debugging feature and is friendlier than GCC's debugger for the monitoring computer.

Both BDebug and CPR can stop within a few instructions of an Enforcer/MuForce hit and can display the source line with SAS/C debug info. It's very helpful to know a little 68k assembler at this point but the values in variables and symbols can be observed. Sometimes the system will crash or freeze after a hit. In that case, use the hit hunk offset with GCCFindHit or FindHunkOffset with vbcc.

http://sun.hasenbraten.de/~frank/projects/download/FindHunkOffset.lha

Without a hit, debugging is trickier and there are several methods of dealing with it.

Unfortunately they appear to be no better than the ones I was using

Bummer. I looked at the reaction includes for vbcc to see if there are any fixes but there are none. If there is a problem with the includes then it doesn't seem to be well known.

I'm out of ideas for now.

[NovaCoder]

Unfortunately they appear to be no better than the ones I was using

Maybe it's just an OS 3.x bug that's been fixed for OS 4.

Either that or you are meant to use those OS functions differently for OS 3.x

Debugging GCC 68k code can be painful, I always use old-school log messages (very tedious!)

[chris]

Maybe it's just an OS 3.x bug that's been fixed for OS 4.

Either that or you are meant to use those OS functions differently for OS 3.x

I don't think so - I've used ReAction on OS3 before and it's no different.  This is the first time I've tried from GCC though, however it only seems to be certain things not working.

Debugging GCC 68k code can be painful, I always use old-school log messages (very tedious!)

Me too.  This bit isn't crashing though, it's just displaying a tiny empty window, so it's either the NewObject call erroring or LAYOUT_AddImage not adding the object.  I suspect the former but need some more logging to be sure - and a window created entirely out of macros is always a pain as it is technically all on one line.