Native 68k Netsurf

[utri007]

I would contribute also, could somebody who has a more experience to start it? It would also need lots of advertising.

Working web browser would be essential, I really don't understand why people are not more interested about this. They rather arguing and whining pointless things and spread their positive attitude all over them. <- sarcasm

[NovaCoder]

I would contribute also, could somebody who has a more experience to start it? It would also need lots of advertising.

Working web browser would be essential, I really don't understand why people are not more interested about this. They rather arguing and whining pointless things and spread their positive attitude all over them. <- sarcasm

Does the 68k port use the SDL and therefore need an RTG....is that about right?   If so it might be possible to remove the SDL requirement and code an AGA chunky mode instead.

[wawrzon]

or you could code your c2p routines directly into bernds sdl library, in order to have a potential possibilty to run all sdl apps on planard screens. this will probably cost just too much performance for most games. is though a much desired feature ive observed. also i have suggested that before.

[NovaCoder]

or you could code your c2p routines directly into bernds sdl library, in order to have a potential possibilty to run all sdl apps on planard screens. this will probably cost just too much performance for most games. is though a much desired feature ive observed. also i have suggested that before.

No sorry, I would never try and compile the SDL source code.   I'm currently using the 68k SDL library for audio and multi-threading (timer) and using native C2P AGA for graphics.   With a NetSurf port I'd probably just the SDL requirement (if possible).

[wawrzon]

i dont understand very well, but whats more complicated in inserting c2p routines into existing sdl static library project than into a netsurf project? both sources will be most likely made available on demand if you volunteer to contribute. but improving sdl would be a more universal gain as it is used by many more applications except netsurf itself.

edit: just to be clear: sdl 68k refuses to work on planar screens for now. when such a screen was detected say by bestmodeid the gfx output could be redirected to your native c2p routine. i don think that it is complicated. bernd woulld sure help with some guidance, since he knows the source. what do you think?

[utri007]

Problem is that SDL is quite useless with real amigas. Even with 8bit modes availlable, it would be useless for real amiga users and pointeless because UEA users doens't need 8bit modes

[wawrzon]

that depends, ive released some stuff that works acceptably on real hardware to aminet, but with c2p overhead it will sure get slower yet.

[eb15]

Last time I looked for AWeb sources, the published server link I found was no longer available...  If there is open source to any of the old Amiga web browswers besides AMosaic, which I already have through AROS, I would be interesting in playing with it under the AROS build system to see if I can get it to build and run under AROS.  That should help prep for working on lighter NetSurf and/or OWB ports (without MUI or SDL dependencies).

[chris]

Are any of the existing amiga based ports (mos/os4) using mui/reaction and other "native" code paths, or are they relying on SDL backend for most everything?

The OS4 one uses Reaction (things will need tweaking for OS3.9, but largely it should work unaltered)
The old MOS version uses MUI.  Note that the interface to NetSurf's frontends has changed significantly, so this frontend will not work "out of the box" with the latest core.

Does the 68k port use the SDL and therefore need an RTG....is that about right?   If so it might be possible to remove the SDL requirement and code an AGA chunky mode instead.

No, don't do that.  The framebuffer frontend (which is what the existing 68k port is) is not really suitable and should not be hacked around for this purpose.  The NetSurf core devs don't like it either.  Create a proper OS3/68k frontend.

@all
The only code you need to touch to modify my OS4 frontend is in the "amiga" directory.

Anything relating to graphics output is in the file "plotters.c".  Currently it uses a mix of graphics.library, (optionally Cairo) and Picasso96 calls.  The graphics.library part sets colours using new OS4 32-bit calls - that will need modifying to use FindColor() - or ObtainBestPen() if you can figure out a way of keeping track of which pens can be unlocked.

I've recently added back in direct to screen rendering, it's buggy atm but should work better for 8-bit modes.

A lot of functions could be stubbed out with #ifdef __amigaos4__ to get it compiled, and then gradually fix functions as they are needed.  There is a heck of a lot of code which is extra UI stuff which won't really matter for an initial porting effort.

I will help!  Ask me questions and I will answer them!

[wawrzon]

just checking, here is a lot of stuff in amiga dir, would have to read into that again, no ifdefs anywhere else?
also i think it would be better to modify p96 to cgx calls for overall 68k compatibility, otherwise half of the systems remain unsupported.

[utri007]

P96 and CGX shouldn't matter, as there are cgx emu buildin in P96?

[chris]

just checking, here is a lot of stuff in amiga dir, would have to read into that again, no ifdefs anywhere else?

You can disable features in makefile.config.  There are a couple of "#ifdef nsamiga" elsewhere but you don't need to worry about those.

also i think it would be better to modify p96 to cgx calls for overall 68k compatibility, otherwise half of the systems remain unsupported.

Actually it would be better to ditch them entirely, I only use four functions - p96AllocBitMap, p96FreeBitMap, p96EncodeColor and p96WritePixelArray.  They can be replaced, you don't want to be using p96 or cgx calls on OS3 as there's no guarantee it's available and you need to support AGA.  I'm only using them anyway for pixel format reasons (NetSurf uses RGBA/ABGR, internal OS4 functions prefer ARGB), write a pixel format conversion function and they then aren't needed.

[Khephren]

The OS4 one uses Reaction (things will need tweaking for OS3.9, but largely it should work unaltered)

No, don't do that.  The framebuffer frontend (which is what the existing 68k port is) is not really suitable and should not be hacked around for this purpose.  The NetSurf core devs don't like it either.  Create a proper OS3/68k frontend.

@

If we stick with reaction, that'll make it 3.9 only won't it? Would be a start though.

If he does not hack around, will we still be able to have a chunky graphics display?  it'll probably need one on AGA.

[NovaCoder]

The OS4 one uses Reaction (things will need tweaking for OS3.9, but largely it should work unaltered)
The old MOS version uses MUI.  Note that the interface to NetSurf's frontends has changed significantly, so this frontend will not work "out of the box" with the latest core.



No, don't do that.  The framebuffer frontend (which is what the existing 68k port is) is not really suitable and should not be hacked around for this purpose.  The NetSurf core devs don't like it either.  Create a proper OS3/68k frontend.

@all
The only code you need to touch to modify my OS4 frontend is in the "amiga" directory.

Anything relating to graphics output is in the file "plotters.c".  Currently it uses a mix of graphics.library, (optionally Cairo) and Picasso96 calls.  The graphics.library part sets colours using new OS4 32-bit calls - that will need modifying to use FindColor() - or ObtainBestPen() if you can figure out a way of keeping track of which pens can be unlocked.

I've recently added back in direct to screen rendering, it's buggy atm but should work better for 8-bit modes.

A lot of functions could be stubbed out with #ifdef __amigaos4__ to get it compiled, and then gradually fix functions as they are needed.  There is a heck of a lot of code which is extra UI stuff which won't really matter for an initial porting effort.

I will help!  Ask me questions and I will answer them!

Hiya,

I assume you use GCC to compile this for OS4?

Direct screen rendering sounds interesting, not sure how that fits in though.

Ok so is it using Reaction to render the entire web-page?   I think that would be very slow under AGA, the only way to make a reasonable fast browser for AGA is to to native hardware 'direct screen rendering' and bypass the OS's API functions....that way it could be done using either C2P or even better the new chunky mode from the Indivision Mrk2. This kind of approach could only work if the underlying browser engine output the complete webpages to a chunky buffer ready for displaying to the user (including its own take on dialog boxes etc).

[chris]

If we stick with reaction, that'll make it 3.9 only won't it? Would be a start though.

There's not much to the GUI, a few buttons, a string gadget, a couple of scrollers and a big expanse of empty space.  You should be able to downgrade it to work on ClassAct, there's nothing complicated there.

If he does not hack around, will we still be able to have a chunky graphics display?  it'll probably need one on AGA.

All the rendering code is in the frontend, which gets commands and colours or an RGBA bitmap.  You can do whatever you like with them.

Hiya,

I assume you use GCC to compile this for OS4?

Yes.

Ok so is it using Reaction to render the entire web-page?

No, just a blank area created by space.gadget, which gets filled in by the above-mentioned plotters.

the only way to make a reasonable fast browser for AGA is to to native hardware 'direct screen rendering' and bypass the OS's API functions....

Draw direct to the window via the window's RastPort (this is what my direct rendering does).  I wouldn't recommend hitting the hardware directly, you're probably not gaining much speed at the expense of extra complexity and hardware compatibility.

[chris]

I've dug out my old "what needs doing for OS3" and posted it on the NetSurf wiki:
http://wiki.netsurf-browser.org/Todo/AmigaOS_frontend#OS3_Support