HTTP server for RHML

Im working on a separate branch that will allow you to host RHML pages on an ordinary web server.  This will be great for folks who dont mind hosting some RHML pages and already run a web server for their main site.  I have a few kinks to work out, but it will be ready soon.  On top of this, linking to other servers is inherently built in.  If all goes well, we will drop the nodejs server completely.

Stay tuned.

2400 baud for C64 client...more coming

Today I added the much requested 2400 baud mode for the 64. 

Also, Ive been working (not ready yet) on accessing rhml pages directly from an HTTP server.  The pros:

* Websites can host RHML pages right along side their normal HTML pages
* Less development work on our part.  No need to maintain server code

The cons:

* The HTTP header adds more data to transfer
* Im having trouble getting flow control working properly - the server just shoves the data right down the wire faster than the wifi modem can handle.
* Nodejs is lightweight (moreso than most web servers)

But, experimentation is worth it in this case.  While I love Nodejs, I'd like to see it go away.. I think.

What do you think?

Lots of updates!

The latest build of the codebase introduces some new things:

1) Variable width GEOS BSW font.  It just looks good.
2) Uppercase characters.  It just looks good...too.
3) *I command.   Allows you to save bitmaps to another file to be [I]ncluded in your page file.  Great for making pages consistent.  (You can use it for other things as well, but bitmaps are a great use)
4) Code refactoring (always), with a focus on doing things in a more object oriented manner.  This is a precursor to developing widget components.

Known issues:

*S (scaling) has been temporarily disabled.  This will return soon.  Basically all of the font rendering code was ripped out and replaced when we went to the variable width font.

The 64 version must be leaking memory somewhere because it gets to a point and then just stops or (worse) returns to BASIC.  This is top priority for a fix.

Variable width font

Im thinking of changing the browsers to use a variable width font instead of a mono sized one.  This would improve readability and rendering speed.  The idea is somewhat taken from GEOS fonts.  The idea would be:

128 64 32 16  8  4  2  1
        *  *  * 
     *        *
     *        *
        *  *  *
              *
              *
     *        *
        *  *

Notice that the entire 128 column, 4, 2, and 1 are empty.   Also note that row 5 could be a descender below the baseline.

Each character would still require 8 bytes for it's definition, but there would be two additional bytes to be used as a header bytes to determine width and Y offset (for descenders)

So in the case above, the header byte would be:

128 64 32 16  8  4  2  1
     *  *  *  *               = 72 / $48

This would tell the browser to only render bits 3-6 for this character.

The second header byte would be:

128 64 32 16  8  4  2  1
                 *     *      = 5 / $05

Which indicates that the offset for this character (from the y plot) is 5 bytes down.  This one is a bit wasteful, unless I can find something to do with the high nybble.  Maybe later on a style byte or something.

Its even possible, with height and width bytes, to use even more data for larger font sizes.  But I dont really want to go there just yet.  Will see in time.

RLE Compression

One thing I want to add to the server and client is a simple RLE compression to help in transmission speed. The idea is that the server will perform compression such as with bitmaps. So it will read the image data:

 *X,....XXXX...XXXXXX

 and then perform compression to send the following:

 *X,^4.^4X^3.^6X

 The client would reverse the process. This saves on transmission time without forcing the page to be compressed. I will try this first for images and see how it works, then maybe try for other elements as well. But images would provide the most benefit.

Update:  Newest build adds compression.  It doesnt work exactly like the above, but there was a simple code fragment available that did it readily.  Works pretty good.

RHML - A Retro Computing Web Protocol

Thanks for checking this project out.  RHML is a simple protocol being developed to provide a web-like experience for retro computing enthusiasts.  Note that this project does NOT require GEOS despite the recognizable interface.

Rationale:
------------------------------------------------------------------------------------

We retro computing folks have invested money in networking capabilities for our machines.  Mant retro machine platforms today have access to wifi modems now, along with network cards, etc.  Its been great seeing the revival of the good ol' BBS scene.

But it's time for more.

RHML is a very simple markup language to provide retro computers of all types to access a web-like system.  It is not possible for these older machines to handle all the complexities of modern web sites with javascript, css, etc.  But we need not stay in text-only mode forever.  The initial browser implementation was written with CC65 for the Commodore 128, so with minor changes, could be modified for other 8 bit systems as well.

UPDATE!:  A 64 build is now also available, currently for 1200 baud.

Non-Commodore Users:  I want to especially invite you to take a look at this protocol and consider getting involved.  This can only work well if we have participation across multiple platforms.  So your interest and involvement is definitely desired!

Implementation:
------------------------------------------------------------------------------------

RHML is a very simple protocol, using text codes to represent rending commands.  Here's a quick rundown:



Render Text to the page

Clear page	*C,
Render Text. The *T command will respect margins (*M) and goto (*G)	*T,THIS IS SOME TEXT TO DISPLAY
Move (Goto) X,Y position on page for text and graphics.	*G,100,20
Scale text and bitmap graphics. Values can be 1 (very small) and up. 2 is most readable on 640x200	*S,2
Set a (M)argin of X pixels for text and graphics.	*M,10
Draw a line	*L,100,50,200,70
Draw a circle (X,Y,R)	*O,100,50,20
Render a bitmap. Bitmaps are simply ascii art available on the web. Any non-space character is rendered as a pixel.	*X,### ### ##
Render a hyperlink button at x,y	*B,20,40,somepage.rhml,CLICK ME
Include another file (useful for common gfx elements)	*I,somepage.rhml
End of page. this is important. See below for details.**	*E,

** Note that because wifi modems are intended to duplicate the functionality of the older dial up modems, a persistent connection is needed to the server. The initial server is running under nodejs. This is why the *E command is required. Otherwise, the modem would have to ATDT<ip address> each and every time, load a page, then disconnect. The upside is that the modem need not do this. The downside is that you can not link to other servers, only pages on the same server. I may experiment with this to see if its a nuisance, or if its viable. Remember, this is still in an early and changing state. 

Update: 7/11/18 - The server now sends *E on its own, so you dont need to add this to your pages.

The *X command seems very wasteful.  In fact, it is, from a data transmission perspective.  However, the reasoning behind this format is:

• The images are easily hand-crafted and human readable
• Images can be created readily using common ASCII art
• Transmission speed has become less of a factor as modems obtain better speeds
• This format is similar to an older PBM format
• In relation, I would consider html itself to be very wasteful
• Update:  I added RLE compression to the data, so images should transfer a little quicker

Why not WBMP?
The problem here is that unlike a modern browser, we can only make a single request at a time.  We *could* use WBMP images, but the result is that when a page references an external WBMP file, it must cache the name and continue rendering the page, then go back and load the images.  As opposed to having complete embedded control within the page as to what image to display and when.  I believe the perceived slowness of this process would be too annoying for users, and isnt worth the effort.

Requirements:
------------------------------------------------------------------------------------
Client:
* The first client browser is has been written with CC65, targetting the Commodore 128.  You can download the files here.  A 1351 mouse in port 1 is required.   The browser renders to the 80 column VDC screen.
* NEW:  A C64 port is also available.  Again, a 1351 mouse is currently required.  I will add joystick and keyboard support in time.

Server
* If you would like to run a server, you will need to install nodejs.  Then run the rhtml-server.js script.  It will listen for connections on port 23.  Open your firewall and do proper port forwarding if you would like external access to the server.  Connections coming to your server will first transmit an rhml file called "index.rhml".  See the included files for examples.

Getting Started:
------------------------------------------------------------------------------------

On the 128, switch to 80 column mode and run the program called "browser". The files "c128-1351.mou" and "c128-vdc.tgi" are required to be in the same directory as well.  After loading, it will initialize the screen and will be expecting a 1200 baud connection.  (This may change as I work on adding 2400 or faster support).  So be sure your wifi modem is first set to 1200. 2400 baud (as of 7/9/2018!)

You will see a simple browser interface.  When you type, you are typing to the modem.  So at this point, you can type AT commands.  In this way, the browser acts as a terminal program.  If typing AT (RETURN) displays OK, then you are all set.  If not, try hitting RETURN a few times as some wifi modems first must connect to your wireless router.

Next, try hitting my demo site at ATDT206.251.214.103:6400

If all goes well, you should see the welcome page.  Congratulations!  You're surfing the kinda-web with your 8 bit computer!

Here you can click any buttons such as the SEE DEMO button to be taken to the next page.  Pages can have multiple buttons, as the demo will show.

At any time, you can disconnect from the server, by issuing the old AT +++ command and then ATH0.  Again, we may rethink and make all this automatic in time depending on feedback.

You can also type GET <pagename.rhml> if you know the name of the page you want.  Currently resource urls arent supported  (ie resourcex/resourcey/page.rhml).  Maybe in the future.

The reload button does exactly what you'd expect.  The previous and next buttons, at the time of this writing, do not work just yet.  Same with the exit button at the top right.  Just haven't implemented the code yet.

Disclaimer:
------------------------------------------------------------------------------------

The protocol and client are in early stages, so expect bugs, buffer overruns, and all kinds of silly problems.  But the code is open source and I hope others will help submit pull requests to make it better.  As well, ports to other platforms too.  Its time we have a web for us.

Hope you find this project interesting and thanks for looking!

VICE users:  yes, you can.  Before starting the browser, set your RS232 ip address the test address above, and the userport to 1200 baud.  2400 baud. No need for AT commands as you will automatically connect.  Enable mouse support with ALT-Q.  (For 3.x versions, go into Control Port Settings, and make port 1 have a 1351 attached)

Also, a quick shout out to my friends at Commodore4Ever who distributes these wifi modems.  You can check his ebay page out here.


Github repo: https://github.com/xlar54/rhml