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 enthus...

Saturday, July 7, 2018

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



12 comments:

  1. With say the example demo page, how much time is spent connecting and how much time is spent downloading the data?

    ReplyDelete
    Replies
    1. Its pretty quick. But obviously can only be as quick as if you were reading the same amount of text from a telnet BBS. The rendering is quite fast compared to standard IO. As Patrik says below, maybe Ill work out a youtube video.

      Delete
  2. I was interested to know the connect time as I understand that is why it is not supported to link to other servers?

    IMHO it would not matter if it is slow to redirect to another server, as long as it is possible - links are important.

    ReplyDelete
    Replies
    1. Yes, linking to other servers is definitely something I will be adding once the main things are worked out and it's stable. And, Ill need some other servers to link to :) Feel free to post your own server address if you want to run one!

      Delete
  3. This could be a good idea to implement a browser in SymbOS for MSX

    ReplyDelete
  4. Awesome! I have some questions, though :)
    How to deal with text only screens, like TRS-80 and ZX-81?
    And how about having links on the text itself (not only on buttons?)

    ReplyDelete
    Replies
    1. Not yet sure how to handle the TRS and ZX. Will have to study up on them a bit if they dont have bitmap modes.

      And yes, Ive thought about proper "links" instead of / including buttons, which would save some screen real estate. Great idea, and one which will probably be implemented imminently.

      Delete
  5. Great fun this.

    I've set up a server at 5.1.88.175:6464.

    The way the text renders is charming.
    I tried running it at 2Mh,3mh,4mh with my turbo chameleon and while it works intitally, it eventually crashes. I suppose thats to be expected.

    Thanks for all your work with this, I look forward to future developments.

    ReplyDelete
  6. Hi

    I'm no JS guru, but I think this is wrong ?

    // ignore modem commands
    if(inqueue.substring(0,2)=='+++') {
    inqueue = "";
    return;
    }

    if you count 2 chars from index 0 it would be '++' ?

    Apologies if I'm mistaken.

    ReplyDelete
  7. thank you For Sharing a Nice Information But You Face Any Technical Issues In google chrome browser So Contact us We Fix It.
    google chrome technical support

    ReplyDelete