Neon (Demo) - Hypertext (ADF) Browser for Atari

[massiverobot]

Neon was talked about in Episode 87 of Antic the Atari Podcast:

 

https://ataripodcast.libsyn.com/antic-episode-87-good-news-bad-news

 

 

[Gibstov]

18 hours ago, massiverobot said:

Neon was talked about in Episode 87 of Antic the Atari Podcast:

 

https://ataripodcast.libsyn.com/antic-episode-87-good-news-bad-news

 

 

Awesome....I will have to check it out

[cobracon]

Is there currently any pages online that are working? Haven't been able to find any. I really think a web page creation program would make this take off.

[Gibstov]

On 11/26/2022 at 8:57 PM, cobracon said:

Is there currently any pages online that are working? Haven't been able to find any. I really think a web page creation program would make this take off.

Have you tried any of these...sorry I couldn't confirm whether they are working at this time:

 

N:HTTP://fujinet.diller.org/neon/s1/index.doc

N:HTTPS://fujinet.pl/index.ahd

N:HTTP://www.retrokorner/pl/index.ahd

 

 

[patjomki]

None of them work

 

First and second one: Error07

 

Last one loads and loads and loads but nothing happens.

 

Edit: Last one works when I change the URL to:

 

N:http://retrokorner.pl/INDEX.AHD

Edited August 3, 2023 by patjomki

[Gibstov]

21 hours ago, patjomki said:

None of them work

 

First and second one: Error07

 

Last one loads and loads and loads but nothing happens.

 

Edit: Last one works when I change the URL to:

 

N:http://retrokorner.pl/INDEX.AHD

I tried most of those links and they appear to be deprecated and don't work anymore.

 

I was able to get the URL you listed to work.

[patjomki]

3 hours ago, Gibstov said:

I tried most of those links and they appear to be deprecated and don't work anymore.

 

I was able to get the URL you listed to work.

 

So the idea of having lots of ahd files online is dead?

[tschak909]

10 minutes ago, patjomki said:

 

So the idea of having lots of ahd files online is dead?

You weren't part of the early days of the web, were you?

I was.

It was really hit or miss, and took a considerable effort to build something that lasted, and we still constantly lose endpoints.

 

This was an experiment to see what was possible to create a system-specific web like infrastructure. It is now dormant, because more work is needed.

 

That's okay, we'll keep trying things, and some things will stick, you will benefit.

 

-Thom

[patjomki]

Keep my fingers crossed that there will be more and more programs for FujiNet.

 

It wasn't my intention to sound negative. It is just because few years ago I bought my FujiNet 1.5 but to to severe lack of time I could only just start to play with FujiNet.

 

As I also own an AVG cart that makes some funcionality of FujiNet obsolete I am now looking for networking apps to have a reason to use my FujiNet.

 

Highscore gaming is such a nice feature and the wether app (way faster to start than a modern device), too. So I hoped that neon would also be a reason to use FujiNet more often . Well, guess we have to wait.

 

An e-mail program, something like C6Maps (on C64) or a web browser would be cool but I know that the no. of atari developers is very limited so patience will help as well. 🙂

[_The Doctor__]

NEON UI would be sweet, being able to use your Atari to configure everything that the webUI does would be a natural for FujiNet.

[mozzwald]

2 hours ago, _The Doctor__ said:

NEON UI would be sweet, being able to use your Atari to configure everything that the webUI does would be a natural for FujiNet.

Until someone ports the compiler to run on fujinet, I don't think this will work. Fujinet has no way to produce the neon/adf files

[_The Doctor__]

It's just data, with fujinet serving a page, it only needs minimal interaction just like html

not much different than running a BBS and serving pages in ascii atascii ansi vt52. It doesn't care what it's serving. and it minimally binds the key to functions. Mark up languages take it a bit further but it's all the same principle for forms check boxes etc. that was the whole point for browsers and mark up languages .... hyper text mark up language. NEON is simpler than that monster. In any event it would be perfect way to showcase both the FujiNet and NEON. It certainly would make for the device being more widely used with a TNFS and NEON server sitting at each persons location as well as being able to fully handle all configurations from the Atari itself. Might be some cool neon pages to visit by extension once people see it in practical use setting up their FujiNets completely from their Atari's Locally and Remotely for that matter.

Edited August 5, 2023 by _The Doctor__

[mozzwald]

1 hour ago, _The Doctor__ said:

It's just data, with fujinet serving a page, it only needs minimal interaction just like html

not much different than running a BBS and serving pages in ascii atascii ansi vt52. It doesn't care what it's serving. and it minimally binds the key to functions. Mark up languages take it a bit further but it's all the same principle for forms check boxes etc. that was the whole point for browsers and mark up languages .... hyper text mark up language. NEON is simpler than that monster. In any event it would be perfect way to showcase both the FujiNet and NEON. It certainly would make for the device being more widely used with a TNFS and NEON server sitting at each persons location as well as being able to fully handle all configurations from the Atari itself. Might be some cool neon pages to visit by extension once people see it in practical use setting up their FujiNets completely from their Atari's Locally and Remotely for that matter.

The NEON markup is compiled into a binary format for the Atari before viewing. The NEON reader isn't parsing the markup on the fly. This would need to be done by fujinet on the fly, hence the need for a compiler that runs on fujinet. Currently, fujinet could only serve up static pages that do not change.

[_The Doctor__]

Neon is an application designed for viewing hypertext documents on the Atari 8-bit computers.  However, the hypertext documents are not HTML documents but in a hypertext language designed especially for the Atari call Atari Document Format (ADF).

 

so you are telling me this is not the case but rather it's just a compiled binary you run each time like a separate exe file for everything?

 

That does not add up, an ADF is loaded and processed by the NEON applications last I knew. It's confusing to be told otherwise. But if that is the case. It's a very convincing fake. Am I fooled?

 

Now if the argument is that NEON compiles the ADF on reception for the Atari to view, I'd call that a client. I'd call whatever was sending the ADF the server.

Edited August 6, 2023 by _The Doctor__

[Gibstov]

13 minutes ago, _The Doctor__ said:

Neon is an application designed for viewing hypertext documents on the Atari 8-bit computers.  However, the hypertext documents are not HTML documents but in a hypertext language designed especially for the Atari call Atari Document Format (ADF).

 

so you are telling me this is not the case but rather it's just a compiled binary you run each time like a separate exe file for everything?

 

That does not add up, an ADF is loaded and processed by the NEON applications last I knew. It's confusing to be told otherwise. But if that is the case. It's a very convincing fake. Am I fooled?

 

Now if the argument is that NEON compiles the ADF on reception for the Atari to view, I'd call that a client. I'd call whatever was sending the ADF the server.

Actually you are partially correct.  Originally the NEON application read the ADF markup language and created the output in real time, like a web browser.  However I never released this version, because it was pretty slow.

 

The way the released NEON application works is that compiles the markup language to a binary format. (Not like an executable....think of it more as all the data and display list/DLI are all in a chunk of memory...And then as you navigate the pages, it jumps from one Display List pointer, to another).

 

I haven't worked on NEON for a while...I did convert the NEON Make (compiler) part to run in C# so it could be run from a webserver and generate the documents dynamically.  Then I started to try and convert from the Atari CC65 application to a modern C application...but then it ran into a bunch of issues and kind of burned myself out.

 

I am thinking about taking another shot at it, if people are interested.

[_The Doctor__]

The interest is there, it would make some of these devices much better for our Ataris, I was hoping to use it as a an extension of BBS's as well, along the lines of CGS but better. It wasn't all that slow compared to other proof of concept ideas that have floated about over time, I felt you were a bit hard on yourself.

Edited August 6, 2023 by _The Doctor__

[massiverobot]

I am always interested. I never got the dynamic server generation part to work, and static ADF docs are only so interesting.

 

I know that people in PL got the dynamic part working I saw screens that were dynamically generated and it was very cool.

 

Given the renewed burst of networked gaming (FujiNet Game System) going on - there are many people building little servers and services for FN enabled devices to better utilize the network- so now may be a good time if you are able to take a nother look at this unique and fascinating system.

[mozzwald]

I found this app that claims to convert C# code to C++ and I ran the Neon compiler source code through it. I'm sure it won't compile as is, but here it is if someone wants to take a stab at making it work. C++ would be drop in for Fujinet

 

NEON-CPP.zip

[TGB1718]

The code looks really weird, I don't think C++ will like all the angled brackets i.e. <>

 

std::shared_ptr<ADF::Compiler> C = std::make_shared<ADF::Compiler>();

 

also the capital letter "L" before all strings. 

 

std::wstring Source = L"";

std::wcout << L"Destination file:";

[danwinslow]

The angle brackets mark templating, where a declaration takes a typename as an argument. The L marker on a literal means that it is a 'wide ascii' literal (2 bytes per char).

The code is probably fine for most c++ compilers but will never probably not ever compile on anything that has a target of the Atari.

Edited August 7, 2023 by danwinslow

[mozzwald]

2 hours ago, danwinslow said:

The code is probably fine for most c++ compilers but will never probably not ever compile on anything that has a target of the Atari.

There is already a compiler for the Atari in a separate repo. The idea here is to get something that runs on the Fujinet (esp32) and/or a server somewhere that compiles the markdown on the fly so the Atari doesn't have to.

[danwinslow]

Ah gotcha. Might work then.

[Gibstov]

OK...I've updated NEON to support dynamic ADF files. It will all be handled from the NEON program on the Atari without needing a separate compiler on the webserver.  Basically the way it works now, if you choose "R" to READ, and the file extension end with .ADF it will compile the file on the fly and display it, if the file extension is .DOC (or anything else) it assume it is a precompiled file and load it that way (as it did before).

 

I don't have webserver, if anyone here has a webserver and would like to help test it out, that would be great.  Please share the URL in this thread.

 

Here is some sample ADF code to get you started: (I guess the only caveat for the file is it will have to be Atari formatted: specifically replace CRLF with the Atari CR (ATASCII 155) if that make sense).

 

:head
:page
:text
Server time is now 00:00:00
:fill

 

I am attaching the the XEX file with new version of NEON....and also ATR file that has NEON and the N-Device so ready to run out the box on your Fuji enabled Atari.

 

 

neon-ndevice.atr neon.xex

Edited August 11, 2023 by Gibstov

[_The Doctor__]

Nice solution. I like this thinking.

[atarixle]

In Windows, compiled hypertext documents have the extension chm.

I wish the same for the Atari, AHT (and also please PHP) for uncompiled sources, which easily can be produced by PHP scripts; and let's say CHT for compiled pages, because DOC is for formatted text and others are for other file formats.