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.


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!


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.

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

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


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


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

    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.

  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.

    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!

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

  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?)

    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.

  5. Great fun this.

    I've set up a server at

    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.

  6. Hi

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

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

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

    Apologies if I'm mistaken.

  7. Is this still being developed?

    1. yes, but slowly. ive got a lot of other projects happening. ill return to it, but suggestions and even pull requests are always welcome

  8. I'm just getting back into the community, but this looks like something I'd like to implement and contribute to, once I'm on my feet, so to speak. I've got several things that I'd want to finish first.

    I'm building a web server to put online. It isn't so much that I have a lot to offer but more that I want my own server to hack on and learn. I do plan on having a simple web site, a simple blog, and a simple BBS, among other projects. I'd be interested in running a RHML server as well.

    As far as other platforms, there are some projects that I'd want to tackle:
    - An open source server that isn't written in JavaScript. This is for my own benefit, but it would be open in case others wanted to use it. It would be a standalone server, as opposed to something that requires a separate web server.
    - An open source cross-platform client.

    Something else that I think would be cool would be a JavaScript client that could be loaded in a standard web browser, so RHML pages could be accessed from any modern web browser. However, this likely would not be a project that I'd take on. I've never written a line of JavaScript and web development isn't my thing.

    I'll touch base once I'm to a point that I can get started, which would be to start a RHML server using your current server code.