Re: Atari MiNT Port
by Bernd Roesch
Hello
On 31.05.10, you wrote:
>
> Well, I didn't even noticed mad colors. a.) Maybe thats because I'm color
> blind b.) Maybe that's because of the screenshot program. c.) Maybe it's
> really mad. :)
>
the colors on your GUI are wrong.more you can see when you go online and show a page.
coldfire is big endian same as 68k, and nsfb work only little endian with offical source.even with
native GUI you need pixel convert routines for Big endian
you can use the amiga nsfb code attached.it should bring you correct colors when this statement is
true.
#if __BYTE_ORDER == __BIG_ENDIAN
there is also a Bug fixed i report some time ago in the 16bit plotter file
fgcol must be 32 bit var.
the attached files work on Amiga 68k CPU for 16 bit and 32 bit screen.but you should use
SDL_HWSURFACE
static bool
glyph8(nsfb_t *nsfb,
nsfb_bbox_t *loc,
const uint8_t *pixel,
int pitch,
nsfb_colour_t c)
{
uint16_t *pvideo;
nsfb_colour_t abpixel; /* alphablended pixel */
int xloop, yloop;
int xoff, yoff; /* x and y offset into image */
int x = loc->x0;
int y = loc->y0;
int width = loc->x1 - loc->x0;
int height = loc->y1 - loc->y0;
- uint16_t fgcol;
+ uint32_t fgcol;
>> As for text not appearing, have you tried it with both the internal text
>> and freetype text? It's a build option.
>
> I did not inspected these options, I will have a look.
internal Fonts do not work on amiga 68k, only freetype with antialiasing work.
there seem a problem in static bool
glyph1(nsfb_t *nsfb,
older netsurf work, but newer not.maybe its a endian issue when it work on your Linux build and
internal fonts
maybe you can confirm this
>
> Thanks for your informations,
>
> greets,
> Ole
Regards
13 years
Re: Atari MiNT Port
by Michael Drake
In article
<b632a496bbb2b84ba53bc7729d06ce19-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUBFBDBTXF5bVkYJX11oAFFRMl5dRkABX15QRV4=-webmailer2@s,
Ole Loots <ole(a)monochrom.net> wrote:
> This is how it looks after running nsfb:
> http://freeshell.de/~monokrom/tmp/netsurf_black.png
The mad colours is probably a mismatch in the red/green/blue/alpha
component order that nsfb expects and what is actually used. Or some
endian issue.
As for the black screen, it looks like NetSurf's not being told where to
look for its resources (such as the default CSS file). Run NetSurf with
-v and post the log here.
As for text not appearing, have you tried it with both the internal text
and freetype text? It's a build option.
Best regards,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
13 years
Atari MiNT Port
by Ole Loots
Hello everybody,
I'm new to this list. I'm trying to do some porting of Netsurf for newer
Atari Machines (Coldfire based).
Currently I'm doing an SDL-Framebuffer PoC port that compiles/ runs with
aranym ( Atari Virtual Machine ).
I have passed all libnsfb make test cases. The graphics show up.
I'm not that familiar with the hardware and I'm not familiar with SDL.
This is how it looks after running nsfb:
http://freeshell.de/~monokrom/tmp/netsurf_black.png
I did not try to debug/investigate why it only shows a black screen.
I hade the same result with x86-Linux X11-Framebuffer Port .
I have seen several postings about the same symptom. So maybe this is an
known Problem, and people can point me into the right direction.
Not just for solving the black screen problem, but about porting in general.
I'm targeting an native port of netsurf, but I would like to have an
working SDL-framebuffer port as "reference", before getting into native
GUI development.
Other problems when running the program:
- Input doesn't show up in the URL textfield. But events (I used the -v
option) show up when pressing keys.
- If I hit enter in the URL textfield, nothing seems to happen ( throbber
is not animated ) - I don't have the Virtual Machine connected to any
networks. But I thought, maybe it shows up Text in the Status bar or
something like that!? ( probably there are problems with font rendering?
...)
- it often happens that the mouse cursor is not visible when moving the
cursor out of the browser window.
I'm willing to investigate these issues. But I thought I'll post this,
maybe you are interested and maybe someone is out there knowing about
these problems ( maybe the Amiga port people :) ).
Kind regards,
Ole
13 years
NetSurf on ARMv7 platforms
by John-Mark Bell
Afternoon,
So, NetSurf runs mostly ok on ARMv7 platforms with their backwards
incompatible unaligned LDR behaviour turned on. Tinct, however, appears
to perform some LDRs from unaligned addresses, resulting in crashes.
Here's a backtrace:
> Fatal signal received: Segmentation fault
>
> Stack backtrace:
>
> Running thread 0x59e53c
> ( 5a7ee0) pc: 462860 lr: 74f4c sp: 5a7ee4 __write_backtrace()
> ( 5a7f10) pc: 74d64 lr: 463298 sp: 5a7f14 ^ro_gui_signal()
> ( 5a7f38) pc: 463288 lr: 462f58 sp: 5a7f3c __unixlib_exec_sig()
> ( 5a7fa0) pc: 462a18 lr: 463870 sp: 5a7fa4 __unixlib_raise_signal()
> ( 5a7fb0) pc: 463774 lr: 5a6c48 sp: 5a6c04 __h_cback()
>
> Register dump at 005a7fb4:
>
> a1: 12f a2: 2d a3: 1f4 a4: 0
> v1: 0 v2: 0 v3: 202513b4 v4: 1
> v5: 3d5 v6: 0 sl: 41b78d39 fp: 67197124
> ip: 20248394 sp: 5a6c04 lr: 5a6c48 pc: 2024609c
> cpsr: 80000113
>
> 20246088 : .p.â : e21a7003 : ANDS R7,R10,#3
> 2024608c : .... : 0a000008 : BEQ &202460B4
> 20246090 : .àgâ : e267e003 : RSB R14,R7,#3
> 20246094 : ..^á : e15e0000 : CMP R14,R0
> 20246098 : .à Á : c1a0e000 : MOVGT R14,R0
> 2024609c : .??å : e59a9000 : LDR R9,[R10,#0]
> 202460a0 : ..@Ð : d040000e : SUBLE R0,R0,R14
> 202460a4 : ..?Ò : d2800003 : ADDLE R0,R0,#3
> 202460a8 : ..?À : c0800007 : ADDGT R0,R0,R7
>
> Invalid pc address bebeec
For reference, Tinct is loaded at 202416B4.
J.
13 years
wy the framebuffer x frontend use not xlib ?
by Bernd Roesch
Hi,
See here in wikipedia
http://en.wikipedia.org/wiki/Xlib
I see most programs/GUI Systems use this xlib when they want use X.
here is a small example that use this lib
amiga os 68k also have a xlib that wrap to native windows.maybe this solution is better as SDL.
int main(void) {
Display *d;
Window w;
XEvent e;
char *msg = "Hello, World!";
int s;
/* open connection with the server */
d = XOpenDisplay(NULL);
if (d == NULL) {
fprintf(stderr, "Cannot open display\n");
exit(1);
}
s = DefaultScreen(d);
/* create window */
w = XCreateSimpleWindow(d, RootWindow(d, s), 10, 10, 200, 200, 1,
BlackPixel(d, s), WhitePixel(d, s));
/* select kind of events we are interested in */
XSelectInput(d, w, ExposureMask | KeyPressMask);
/* map (show) the window */
XMapWindow(d, w);
/* event loop */
while (1) {
XNextEvent(d, &e);
/* draw or redraw the window */
if (e.type == Expose) {
XFillRectangle(d, w, DefaultGC(d, s), 20, 20, 10, 10);
XDrawString(d, w, DefaultGC(d, s), 50, 50, msg, strlen(msg));
}
/* exit on key press */
if (e.type == KeyPress)
break;
}
/* close connection to server */
XCloseDisplay(d);
return 0;
}
Bye
13 years
Fwd: wy the framebuffer x frontend use not xlib ?
by Dee Sharpe
Demetrious Sharpe
Sent from my iPhone
Begin forwarded message:
> From: Rob Kendrick <rjek(a)netsurf-browser.org>
> Date: May 7, 2010 9:54:11 AM CDT
> To: Dee Sharpe <demetrioussharpe(a)netscape.net>
> Subject: Re: wy the framebuffer x frontend use not xlib ?
>
> On Fri, 7 May 2010 09:50:40 -0500
> Dee Sharpe <demetrioussharpe(a)netscape.net> wrote:
>
>> I don't even have a port up & running & I understand that basic
>> concept. The sdl port it solely a debugging tool. If you want a
>> backend, port a native one.
>>
>> Demetrious Sharpe
>>
>> Sent from my iPhone
>
> Did you mean to tell your iPhone to send this to the mailing list? :)
>
> B.
13 years
Trunk behaviour and the road to 2.6
by Daniel Silverstone
Hi,
We rushed *hard* to get 2.5 out, and unfortunately it wasn't all we'd hoped it
would be. As such we're calling a moratorium on committing feature changes to
trunk so that we can *all* concentrate on bug-fixes.
This means that all the frontend enhancement development, the core-treeview
branch, etc, should all be backburnered so that we can fix bugs in the core,
and any frontend bugs which mean that 2.5 is damaged-goods.
Everyone should be capable of helping in this process.
We need to find memory leaks, track down allocation issues, find sites which
trigger these things reliably, along with any crashers anyone can find.
Basically stress-test the browser and then find ways to easily reproduce issues
so that we can track them down and fix them.
So, to reiterate, only bug-fixes on trunk for now please. Someone needs to
remove the PDF export bit of the RISC OS menu (or fix PDF export, but I think
that's too much for this phase to be honest).
Feature development can continue on branches if you truly feel you cannot
contribute to the bug-fix effort.
We will release 2.6 when we feel it won't be another disappointment; and at
that point, trunk will be reopened to development.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
13 years, 1 month
