When we'll see elinks for MSX?

Pagina 6/7
1 | 2 | 3 | 4 | 5 | | 7

Van Eugeny_Brychkov

Paragon (1118)

afbeelding van Eugeny_Brychkov

21-11-2018, 11:31

I did not pay atteniton to this thread for a while, and now I see I have to contribute.

I had several urges to start designing web browser, in screen 8 or screen 5 modes. These urges were stopped even before they started for the following reasons:

  1. GR8NET does already have very simple browser, which you can invoke using _NETBROWSE. It supports several tags, and targeted to show directory list provided by the Apache (either regular or fancy). I designed it for people to browse ROM directories on the internet and SD-cards, however I believe it can be used to browse very simple web pages without any dynamic content;
  2. To make something usable machine will require a lot of RAM: load HTML, load pics, render text into graphics (as on-the-fly rendering will not be possible for performance reasons as it will be simply unusable). I think 32MB RAM space would be considerable, but the only device I know having it at once is GR8BUS master board which has never got to the production;
  3. It will require a lot - a LOT of work, and I believe porting as is will be even more work than designing from the scratch (having MSX specs in mind) and reusing only some portions of code (e.g. JPG/GIF rendering, color conversion, etc);
  4. As mentioned here - HTTPS/TLS. There were questions and requests about GR8NET supporting these protocols, I personally is willing to implement them (partially within FPGA so performance will not be a bottleneck), but I need tech information what is required to support them. None so far approached me telling what computing power is required, and also for discussion how firmware/software architecture would look like.

At this time I am not convinced that the effort is worth the degree the final product will be used. I may extend/enhance current _NETBROWSE to specific sane degree, but requirements must be discussed, defined, and fixed to do it properly.

The focus team will be needed for the project, it will take ages for one person to do all required things. Members will have to be available, reliable and responsible. And of course - knowledgeable and experienced.

Another thing being discussed here is other device performing rendering, converting to some format (simplest - SC5 image for direct display on MSX) with some indication of clickable area. That would be the simplest thing to start with - in terms of protocol, applications at both sides. However there're possible hassles - e.g. form filling, and in general feedback from actions performed on MSX machine. Then another issue - browser will rely on some external device, which may be subject to bugs and unavailability.

Lots of words are written in this thread so far, I think we must start acting in some direction. Fudebrowser? No idea what is it, but if it is doable let's try it.

Van karloch

Prophet (2068)

afbeelding van karloch

21-11-2018, 13:18

FudeBrowZer was the graphical web browser for UZIX. It featured a really nice web browsing experience at somewhat acceptable speed in SCREEN 2 (due to the FlyBrowser protocol in which is based). It uses a Intel x86 hosted proxy server called WILD (WWW Intelligent Lowsizer Daemon), that degraded the webpage to something that was possible for the MSX to manage.

Long ago I used to play with this browser and even hosted a publicly accessible WILD server. I still have some screenshots:

Anyway, I agree with the discussion so far: doing a text based web browser like Lynx or eLinks is almost the same as a graphical one, if you plan to render the HTML and CSS correctly even in text mode.

Quote:

As mentioned here - HTTPS/TLS. There were questions and requests about GR8NET supporting these protocols, I personally is willing to implement them (partially within FPGA so performance will not be a bottleneck), but I need tech information what is required to support them. None so far approached me telling what computing power is required, and also for discussion how firmware/software architecture would look like.

Yay! That would be awesome. Sometimes we can't just download a file with HGET.COM or GR8NET basic program because the web is HTTPS, that is more and more common today. TLS proxy solutions are a pain for HTTP due to the certificate trust.

IIRC, GR8NET FPGA is an Altera Cyclone III right? That is the very same FPGA used by the Apollo Team in their next generation m68k CPU. I own that core on my Amiga and the speed is somewhat double of the 68060 at 50 MHz and mostly the same as a mid-range Pentium. In other words: it should be powerful enough to handle TLS. However, I guess that depends on the space available on the FPGA and the logic implementation; unless already done, I know this is quite hard. Also, my Amiga with Apollo Core handles SSH and TLS nicely due to the implementation of a fast m68k CPU, it's not using dedicated TLS encryption/decryption logic in the FPGA.

Van Grauw

Ascended (8704)

afbeelding van Grauw

21-11-2018, 13:42

Eugeny_Brychkov wrote:

To make something usable machine will require a lot of RAM: load HTML, load pics, render text into graphics (as on-the-fly rendering will not be possible for performance reasons as it will be simply unusable). I think 32MB RAM space would be considerable

I don’t understand this. On-the-fly rendering is mandatory to make it perform and usable and work within a reasonable amount of RAM. Loading and preloading and prerendering up front will take ages before you even see anything. And up to 32 MB no less you say! That’s a dazzling amount of memory and just not a realistic amount of RAM for a Z80 to be processing in a timely fashion.

Also this thread is about elinks, a text-mode browser, which greatly simplifies the problem by eliminating image rendering from the equation. Just stream load files over HTTP, parse some markup, show some text, follow links to other files. I don’t see where the big performance or memory cost of that would be.

Eugeny_Brychkov wrote:

It will require a lot - a LOT of work, and I believe porting as is will be even more work than designing from the scratch (having MSX specs in mind) and reusing only some portions of code (e.g. JPG/GIF rendering, color conversion, etc);

It is definitely quite some work, but in one evening I was able to have rudimentary parsing and some very basic formatting for the msx.org frontpage. Since I just wanted to make a little proof of concept I’ve not implemented a full HTML5 parser (which is by the way very nicely and clearly documented) and focused on doing things quick rather than neatly. But if problems are tackled one at a time, I think it is quite manageable. I will finalise the proof of concept and make a video once I have some time for it later this week.

Also doing it on the MSX has its charm for me. If a PC is involved, then why not just browse the internet on the PC, it defeats the purpose IMO. You’d effectively be making a remote desktop client, the graphical equivalent of telnetting to a PC with elinks installed on it.

Eugeny_Brychkov wrote:

At this time I am not convinced that the effort is worth the degree the final product will be used.

That is for sure a worthy consideration. Yet it’s difficult to judge up front. Considering my two biggest projects from recent years, Synthesix and VGMPlay, the former got relatively little interest, whereas the latter has gotten a lot (which keeps me motivated to work on it). The only way to know is to try, and to start small so that you can get feedback early and if there is very little you can let the project go while still leaving something functional to the world.

Van Eugeny_Brychkov

Paragon (1118)

afbeelding van Eugeny_Brychkov

21-11-2018, 13:43

Grauw wrote:

a text-mode browser, which greatly simplifies the problem by eliminating image rendering from the equation. Just stream load files over HTTP, parse some markup, show some text, follow links to other files.

What's wrong with _NETBROWSE then? It does what is requested. Not for all pages I guess, but it can be expanded.

Van Grauw

Ascended (8704)

afbeelding van Grauw

21-11-2018, 13:49

Maybe _NETBROWSE is exactly what this thread is asking for? Smile

@AxelStone @Wolverine_nl?

Van geijoenr

Expert (96)

afbeelding van geijoenr

21-11-2018, 14:59

similar approach in C64

HyperLink

Van Wolverine_nl

Paragon (1060)

afbeelding van Wolverine_nl

21-11-2018, 15:31

I will try to load a page using _netbrowse this evening. Wink

Van skumlerud

Resident (46)

afbeelding van skumlerud

21-11-2018, 15:48

Eugeny_Brychkov wrote:

Then another issue - browser will rely on some external device, which may be subject to bugs and unavailability.

Such a device would most likely be a normal PC, or a Raspberry Pi or equivalent. I don't think availability will be a problem, atleast not for people stu... ehh... *dedicated* enough to get online with a 35 year old computer.

A "gateway" service for retro computers should not only cover the web, but also messaging protocols, mail, file sharing (Dropbox!) and transfering etc., and this is something most (all?) retro platforms would benefit from.

Van Grauw

Ascended (8704)

afbeelding van Grauw

24-02-2020, 21:38

HTML viewer for MSX proof of concept

Parsing and showing the frontpage of msx.org on MSX.

The HTML is processed and displayed on the fly with some primitive formatting. Being a proof of concept I only implemented basic parsing.

The display speed is mostly limited by the slow character display in MSX-DOS, doing an interslot call for every character printed. Due to this it’s comparable in speed to the TYPE command. I’ll add text routines which directly communicate with the VDP next which should speed things up greatly. Nevertheless it already scrolls faster than you can read, so that’ll just mean it’ll pass by in the blink of an eye.

Note this is running on a turboR. Also note I do not plan to actually pick this up as a full project ;).

Source code: https://hg.sr.ht/~grauw/htmlview

Van fr3nd

Expert (92)

afbeelding van fr3nd

21-11-2018, 20:00

Very nice proof of concept! I'll try to understand the code, but asm is way too difficult for me yet..

I believe the browser should not require any external proxy and with basic html parsing (no images, etc) should be more than enough. I haven't tried _NETBROWSE so I don't know how it works, but it looks good.

I'll keep trying to implement something as a proof of concept too. No promises though Smile

Pagina 6/7
1 | 2 | 3 | 4 | 5 | | 7