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

[Gibstov]

Introducing Neon. Neon is an application I thought of after getting started with FujiNet, and wishing that I could browse FujiNet on my Atari.
 
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).

 

Use the power of Antic to create pages that mix text and graphics.

 

GTIA modes can be used to add more colors or shades to your documents.

 

With user defined characters sets, add fonts and graphics to your document.

 

 

Hyperlink to other pages in a document, or link to another document.

 

 

Neon requires an Atari computer with at least 48K and requires a Joystick to navigate links.

 

Neon consists of two functions: Read - Read a compiled document. Make - Compile a document written in ADF.

 

In a case of show don't tell, please find the attached Demo.  There a multiple documents hyperlinked together for browsing.  Eating your own dog food or “dogfooding” is the practice using your own products or services, I have written the Neon/ADF documentation in ADF.

 

For this demo, after starting the program:

    1) At the Read/Make prompt: Choose R - Read
    2) At the filespec prompt> Press [RETURN] to load D:INDEX.DOC

 

Thanks, for any feedback.

 

Find the Demo below.

Neon.0.1.atr

 

Atari Document Format (ADF) commands. (Updated 7/10/2021)

 

Atari Document Format.txt

 

Source (ADF) for the DOC files in the Demo.

ADF Source Files.zip

 

Edited July 10, 2021 by Gibstov

[Gibstov]

Hello World Example in ADF.

 

Here is a quick example of Hello World written in ADF.

:head
:page
:text
Hello World

This will create the following page.

 

 

Add one more command FILL to fill out the rest of the screen.

 

:head
:page
:text
Hello World
:fill

 

We can easily change text modes.

:head
:page #mo 7
:text
HELLO world
:fill

 

And also easily change colors, etc.

:head
:page #mo 7 #c4 B4 #c5 36
:text
HELLO world
:fill

 

To compile these examples ensure that the file is saved in ATASCII format.

 

In Neon, choose M - Make.

 

Enter the source file> D:HELLO.ADF

Enter the destination file> D:HELLO.DOC

 

[TGB1718]

Interesting, but I think the individual commands need a bit more explanation on how to use them, maybe

the source for the .DOC files on the .atr would be helpful.

 

I created a couple of your examples above and compiled, they worked fine, although I'm using SDX and

used ED to create them while on drive DN:.

ran the program from D1: while staying on DN:, the read command would not work until I specified the drive DN:file.ext

 

Also a directory function would be useful

 

[Gibstov]

8 minutes ago, TGB1718 said:

Interesting, but I think the individual commands need a bit more explanation on how to use them, maybe

the source for the .DOC files on the .atr would be helpful.

 

I created a couple of your examples above and compiled, they worked fine, although I'm using SDX and

used ED to create them while on drive DN:.

ran the program from D1: while staying on DN:, the read command would not work until I specified the drive DN:file.ext

 

Also a directory function would be useful

 

Good point about the source for the .DOC files, I added them to the original post. Note the included .ADF files are in ATASCII.

[Clint Thompson]

That's pretty cool gave me a Halt and Catch fire feeling moment there.

[Gibstov]

Here is another example, creating two pages and linking them together.

 

;Linking two pages together

:head ;each page starts with :head

:page $na "Page1" ;you can give each page a name
:text #mo 7 #al 1 ;antic mode 7 center alignment
PAGE 1
:text ;switch back to default (antic 2)
This is an example page. 

We can enter in as many lines of text
as we want. We stay in text entry mode 
until we enter another command.

Click Next to go to page 2

:fill #mb D0 ;leave room for navigation
:text #mo 6  #al 2 ;switch to mode 6 right alignment
NEXT->
:link $li "Page2" ;$li is page name to link to

:page $na "Page2" ;this is our second page
:text #mo 7 #al 1 ;antic mode 7 center alignment
PAGE 2
:text
Lorem ipsum dolor sit amet, consectetur 
adipiscing elit. Ut vel scelerisque 
purus. 

Donec egestas, augue ac vestibulum 
lacinia, mauris lacus consequat enim, 
non auctor augue arcu quis tortor. 

Nunc sollicitudin, nulla eget rutrum 
consectetur, justo odio euismod turpis, 
et dignissim est erat in leo.

Click Previous to go to page 1

:fill #mb D0 ;leave room for navigation
:text #mo 6 ;switch to mode 6 
<-PREVIOUS
:link $li "Page1" ;Link to page 1

 

To compile these examples ensure that the file is saved in ATASCII format.

 

In Neon, choose M - Make.

 

Enter the source file> D:PAGES.ADF

Enter the destination file> D:PAGES.DOC

Edited July 3, 2021 by Gibstov
Fixed typo

[ivop]

Why do you sometimes use $bla and sometime #bla?

 

:page $na "Page1"

 

vs

 

:text #mo 7

 

Why not #na "Page1"? (I assume na means name. Why not use the full words?)

[Gibstov]

14 minutes ago, ivop said:

Why do you sometimes use $bla and sometime #bla?

 

:page $na "Page1"

 

vs

 

:text #mo 7

 

Why not #na "Page1"? (I assume na means name. Why not use the full words?)

The first character of an attribute denotes its type: #-byte, %-word,$-string.

The attributes are 2 characters because of memory constraints.

[dely]

Awesome!

[Gibstov]

Here is an example of how to have multiple hyperlinks per line, and how to use the #ML and #MR attributes to control what part of the line gets highlighted for each link.*(Bottom of "Page2")

 

;Multiple Links on a Line

:head ;each page starts with :head

:page $na "Page1" ;you can give each page a name
:text #mo 7 #al 1 ;antic mode 7 center alignment
PAGE 1
:text ;switch back to default (antic 2)
This is an example page. 

We can enter in as many lines of text
as we want. We stay in text entry mode 
until we enter another command.

Click Next to go to page 2

:fill #mb D0 ;leave room for navigation
:text #mo 6  #al 2 ;switch to mode 6 right alignment
NEXT->
:link $li "Page2" ;$li is page name to link to

:page $na "Page2" ;this is our new second page
:text #mo 7 #al 1 ;antic mode 7 center alignment
PAGE 2
:text 

This is our new second page.

We can use byte to insert graphics

:byte #mo 8 #al 1 ;bitmap mode Antic Mode 8 center align
A5 A5 A5 FF 55 AA 55 FF
A5 A5 A5 FF 55 AA 55 FF
A5 A5 A5 FF 55 AA 55 FF
:text ;switch back into text mode

Use Joystick to choose previous or next

:fill #mb D0 ;leave room for navigation
:text #mo 6 ;switch to mode 6 
<-PREVIOUS    NEXT->
:link $li "Page1" #ML 0 #MR 9 ;use #ml,#mr to control inverse
:link $li "Page3" #ML E #MR 13 ;use #ml,#mr to control inverse  

:page $na "Page3" ;this is our third page
:text #mo 7 #al 1 ;antic mode 7 center alignment
PAGE 3
:text
Lorem ipsum dolor sit amet, consectetur 
adipiscing elit. Ut vel scelerisque 
purus. 

Donec egestas, augue ac vestibulum 
lacinia, mauris lacus consequat enim, 
non auctor augue arcu quis tortor. 

Nunc sollicitudin, nulla eget rutrum 
consectetur, justo odio euismod turpis, 
et dignissim est erat in leo.

Click Previous to go to page 2

:fill #mb D0 ;leave room for navigation
:text #mo 6 ;switch to mode 6 
<-PREVIOUS
:link $li "Page2" ;Link to page 2

 

To compile these examples ensure that the file is saved in ATASCII format.

 

In Neon, choose M - Make.

 

Enter the source file> D:LINKS.ADF

Enter the destination file> ?LINKS.DOC

[Gibstov]

Here is an example of using :DATA to create an image once, and then using :VIEW to display that image multiple times in different Antic Modes.

 

;Define an image once with DATA and the use VIEW to display it many times

:head ;each document starts with :head
:data #id a1 ;#ID is used to create a databank
FF FF FF FF FF 00 FF FF FF FF FF 00 00 00 00 00 00 00 00 00 
FF FF FF FF FF 00 FF FF FF FF FF 00 00 00 00 00 00 00 00 00 
FF FF FF FF 00 55 00 FF FF FF FF FF 00 55 55 55 55 55 00 FF 
FF FF FF FF 00 55 00 FF FF FF FF FF 00 55 55 55 55 55 00 FF 
FF FF FF FF 00 55 00 FF FF FF FF FF 00 55 55 55 55 55 00 FF
FF FF FF FF 00 55 00 FF FF FF FF FF 00 55 55 55 55 55 00 FF
FF FF FF 00 55 55 55 00 FF FF FF FF FF 00 55 55 55 00 FF FF
FF FF FF 00 55 55 55 00 FF FF FF FF FF 00 55 55 55 00 FF FF
FF FF FF 00 55 55 55 00 FF FF FF FF FF 00 55 55 55 00 FF FF
FF FF FF 00 55 55 55 00 FF FF FF FF FF 00 55 55 55 00 FF FF
FF FF 00 55 55 55 55 55 00 FF FF FF FF FF 00 55 00 FF FF FF
FF FF 00 55 55 55 55 55 00 FF FF FF FF FF 00 55 00 FF FF FF
FF FF 00 55 55 55 55 55 00 FF FF FF FF FF 00 55 00 FF FF FF
FF FF 00 55 55 55 55 55 00 FF FF FF FF FF 00 55 00 FF FF FF
FF 00 00 00 00 00 00 00 00 00 FF FF FF FF FF 00 FF FF FF FF
FF 00 00 00 00 00 00 00 00 00 FF FF FF FF FF 00 FF FF FF FF

:page 
:text
After creating a databank, use :VIEW
to create an LMS to display anywhere
in the document.

Mode D

:view #id a1 #mo d #ln 8 ;#id of the databank, Antic Mode d, #ln 8 lines

:text

Mode E

:view #id a1 #mo e #ln 8 ;#id of the databank, Antic Mode e, #ln 8 lines

:text

Use %sz to display images in modes
with different lengths

Mode A

:view #id a1 #mo a #ln 8 %sz 28 ;#id of the databank, Antic Mode e, #ln 8 lines, %sz size 28

;%sz in the example is 0x28 (40) because the original image's length is 0x28 (40)
;Mode A length is only 0x14 (20)

:fill

Edited July 4, 2021 by Gibstov

[Gibstov]

Here is an example of how to create and call DLIs with CODE and CALL.

The first DLI changes playfield 2 color, the second DLI changes playfield 2 color and flips the characters upside down.

 

;Here is an example of using :CODE to create a DLI
;And using :CALL to call the DLI

:head
:code #id c1 #ws 1 #c6 d4 ;each DLI has an #ID,sync changes to beginning of line #ws, set color 6 to d4
:code #id c2 #ws 1 #c6 44 #cm 4 ;#ID,sync, set color 6 to 44, set char mode to 4

:page
:text
Here is our default color
:fill #mb 58 ;add blank lines until line 0x58
:call #id c1 ;call first DLI (c1), changing color
:text
Here is our new color
:fill #mb 98 ;add blank lines 
:call #id c2 ;call second DLI (c2), changing color & flipping characters
:text 
A third color and flipped characters
:fill

 

 

Edited July 4, 2021 by Gibstov
typo

[Heaven/TQA]

that's nice nerd stuff

 

[TGB1718]

On 7/3/2021 at 7:13 PM, Gibstov said:

The attributes are 2 characters because of memory constraints.

That's a big shame, looks like fun to play with, but having to refer to the Format Document all the

time is a bit of a pain. (would also make it more readable).

 

Is it not possible to "tokenise" the names for the compiler to use. ?

[Gibstov]

2 hours ago, TGB1718 said:

That's a big shame, looks like fun to play with, but having to refer to the Format Document all the

time is a bit of a pain. (would also make it more readable).

 

Is it not possible to "tokenise" the names for the compiler to use. ?

I will try to update the documentation this weekend.  I noticed some typos in it, which is never good in programming documentation.  I will also try to expand it.  I covered a lot of topics in the actual ADF Atari Documents on the disk, but need to provide them on the PC, so you don't have to read it in an emulator.

[Gibstov]

A note on memory management.

 

On the Atari, there are a few pitfalls regarding crossing certain memory boundaries. Also char sets and Player Missile graphics must be aligned on 1KB memory boundaries (2KB boundary for single line PM Graphics).

 

Crossing a 4KB memory boundary.

 

On the Atari, if screen memory crosses a 4KB boundary, it will cause the output to become corrupted.  In Neon, if you are using either the :TEXT  or the :BYTE command, you don't need to worry about this.  The compiler will automatically take care of crossing any 4KB boundary.

 

However, if you are using the :DATA command to create images, you will need to make sure that the :DATA doesn't cross a 4KB boundary, and if it does, you will need to split the data into two separate commands.  

 

Aligning data

 

As mentioned above, char sets and PM Graphics need to aligned on 1KB boundary.  In Neon, the document data starts at $4000, so it is already aligned on a 1KB/4KB boundary.  So if you define char sets and PM Graphics first, they will be aligned on a 1KB boundary.  However, this isn't always possible, so you can use the %OF attribute of the :DATA (or :LOAD) command to align your data on a 1KB boundary.

 

Here is a short example of using %OF to align on a 1KB boundary

 

; Example of using %of to align data on 1KB boundary

:head
:data #id d1 ;small image
FF AA 55 00 FF AA 55 00
:data #id c1 $fs "H1:MLPfont.fnt" %sz 400 %of 3F8 ;align char set on 1KB boundary
:page #ch c1 ;set CHBASE to databank c1
:text
EXAMPLE OF ALIGNING ON 1KB BOUNDARY
:fill

 

Note in this example we needed an offset on 3FB (1016) to align the data statement on a 1KB boundary.

 

 

Edited July 9, 2021 by Gibstov

[Gibstov]

I updated the ADF Command List document to be more comprehensive.  You can find it here, or in the original post.

 

Atari Document Format.txt

Edited July 10, 2021 by Gibstov

[Gibstov]

As noted in an earlier post, if you need need to display an image over 4KB, it must be split into two.  The magic number to split the file at, assuming you are going to display it a mode such E, is FF0 (4080).  This is the last full 40 byte line before 1000 (4096).

 

This example shows how to display an image over 4KB.  I found the source for the image here: http://gury.atari8.info/detail.php?id=14559&src=8

 

; Example of displaying an image greater than 4KB by splitting it into two :DATA statement

:head
:data #id a1 $fs "H1:clown1.pic" %sz ff0 ;Split the file at FF0(4080), last full line before 1000(4096)
:data #id a2 $fs "H1:clown2.pic" %sz e14 %of 10 ;we need to offset by 10(16) to start at 4KB
:page #c4 94 #c5 38 #c6 0F
;We need two view statements to view the full picture
:view #id a1 #mo e #ln 66 ;66(102) lines because 4080/40
:view #id a2 #mo e #ln 5A ;5A(90) lines = 3604/40
:fill

 

 

 

Edited July 11, 2021 by Gibstov
Fixed typo

[ClausB]

On 7/3/2021 at 9:46 AM, Gibstov said:

Use the power of Antic to create pages that mix text and graphics.

Cool!

 

I did something similar in 1982 but without the hypertext. My employer set up Ataris in hotels and piped them into their cable TV systems for use as an information channel. We programmed custom info screens and ads in BASIC, which was labor intensive. So I wrote a WYSIWYG editor to build displays like yours without custom programming. Then I left that company and lost track of them.

[+x=usr(1536)]

Following with great interest - there're a couple of applications I have in mind for this.

[Gibstov]

6 hours ago, x=usr(1536) said:

Following with great interest - there're a couple of applications I have in mind for this.

Awesome.  I really want to start testing on FujiNet, the original inspiration for this application.

[Gibstov]

Relative vs absolute file specifications.

 

Absolute filespec: D:example1.doc  or  D1:example1.doc

Relative filespec: example1.doc

 

All ADF commands use the absolute filespec except the :LINK command*.  The :LINK command can use either the full absolute file spec or can use the relative filespec. 

 

This makes development easier.  You can develop on a PC using Altirra with its built in virtual hard drive feature using the H: device.  Then you can easily copy the DOC files over to a floppy disk and all the links will work without having to manually change H: to D:,  and recompiling.

 

; Absolute Links

:head
:page
:text
Example 1
:link $fs "D:Example1.doc"
:text
Example 2
:link $fs "D:Example2.doc"
:text
Example 3
:link $fs "D:Example3.Doc" $li "About" ;link to a page in Example 3
:fill

Same document using relative links instead of absolute links.

 

; Relative Links

:head
:page
:text
Example 1
:link $fs "Example1.doc"
:text
Example 2
:link $fs "Example2.doc"
:text
Example 3
:link $fs "Example3.doc" $li "About" ;link to a page in Example 3
:fill

 

* All commands with the exception of :LOAD, load files at compile time and the data becomes part of the document, so relative links are not as important.

Edited July 11, 2021 by Gibstov

[+x=usr(1536)]

6 hours ago, Gibstov said:

Awesome.  I really want to start testing on FujiNet, the original inspiration for this application.

Funnily enough, that was exactly where I was thinking that this could come in handy.

 

My thoughts are this: FujiNet has an approach to network connectivity that is not totally dissimilar to FTP.  What I mean by this is that it's mainly concerned with the transfer of executable objects (including media images in this context), which it moves from place to place but does not act upon them as a rendering agent in the sense of a browser.

 

Building on that, it would be useful to see an extension to TNFS that allowed for both its current functionality as well as client-side presentation of documents.  HTTP is way too heavy for this, but something with functionality midway between HTTP and Gopher would probably work.  It looks as though there's potential for this to happen with ADF.

 

Since ADF is a specification as well as software, there's excellent potential for it to run on non-A8 platforms.  This opens the door to things like an ADF daemon handling page compilation on a *nix box acting as the server, much as tnfsd runs on remote non-Atari hosts.

 

Apologies for the stream-of-consciousness; if any of the above doesn't make sense it's because it's a mostly-unfiltered brain dump ?

 

BTW: any plans for implementing something analogous to the HTTP PUT and GET methods?  With those, the possibilities of building things like a BBS or platform-specific forum would be very close.

[Gibstov]

19 hours ago, x=usr(1536) said:

Funnily enough, that was exactly where I was thinking that this could come in handy.

 

My thoughts are this: FujiNet has an approach to network connectivity that is not totally dissimilar to FTP.  What I mean by this is that it's mainly concerned with the transfer of executable objects (including media images in this context), which it moves from place to place but does not act upon them as a rendering agent in the sense of a browser.

 

Building on that, it would be useful to see an extension to TNFS that allowed for both its current functionality as well as client-side presentation of documents.  HTTP is way too heavy for this, but something with functionality midway between HTTP and Gopher would probably work.  It looks as though there's potential for this to happen with ADF.

 

Since ADF is a specification as well as software, there's excellent potential for it to run on non-A8 platforms.  This opens the door to things like an ADF daemon handling page compilation on a *nix box acting as the server, much as tnfsd runs on remote non-Atari hosts.

 

Apologies for the stream-of-consciousness; if any of the above doesn't make sense it's because it's a mostly-unfiltered brain dump ?

 

BTW: any plans for implementing something analogous to the HTTP PUT and GET methods?  With those, the possibilities of building things like a BBS or platform-specific forum would be very close.

 

Can I ask you some question about FujiNet, I have been working off of assumptions when developing this, but may have some misunderstanding on how it works.

 

So please indulge me with this theoretical scenario.

 

Suppose you were to set up a tnfs server say: tnfs://my-test-server/

 

And then create a folder called NeonTest.  Suppose the example above, under "relative links", was saved as a file called Index.DOC.  And then there were 3 other files, Example1.DOC, Example2.DOC, and Example3.DOC also in that folder.

 

Also, let's assume we have booted an Atari, and loaded the N: device driver/device handler, and have Neon loaded.

 

First question:

 

In theory we should be able to load up the Index.DOC in Neon, by choosing R to read, and then entering in:

>N:tnfs://my-test-server/NeonTest/Index.DOC

to pull the file down over the FujiNet.  Is this accurate or will this not work.

 

Second question:

 

If the above works, then theoretically the relative links should work.  When you click on example one, it would resolve to

N:tnfs://my-test-server/NeonTest/Example1.DOC

and example two would be

N:tnfs://my-test-server/NeonTest/Example2.DOC

 

In theory this should work right, I am pretty sure the relative stuff works, but more importantly, it should be able to pull each document down, if it has the full address?

 

"Since ADF is a specification as well as software, there's excellent potential for it to run on non-A8 platforms.  This opens the door to things like an ADF daemon handling page compilation on a *nix box acting as the server, much as tnfsd runs on remote non-Atari hosts."

 

It should be fairly straight forward to port the Neon Compiler (Make) to other platforms (famous last words), because the program is written in C.

 

"BTW: any plans for implementing something analogous to the HTTP PUT and GET methods?  With those, the possibilities of building things like a BBS or platform-specific forum would be very close."

 

Maybe in the future, I was thinking that Form elements could be added.  Kind of using the same frame work, maybe moving the joystick will move the focus to the various controls.  Click the button on the control to change its value.  Though I imagine the way this would work is it would save the Form values as a file. 

 

 

[+x=usr(1536)]

2 hours ago, Gibstov said:

Suppose you were to set up a tnfs server say: tnfs://my-test-server/

 

And then create a folder called NeonTest.  Suppose the example above, under "relative links", was saved as a file called Index.DOC.  And then there were 3 other files, Example1.DOC, Example2.DOC, and Example3.DOC also in that folder.

 

Also, let's assume we have booted an Atari, and loaded the N: device driver/device handler, and have Neon loaded.

Understood so far.

2 hours ago, Gibstov said:

First question:

 

In theory we should be able to load up the Index.DOC in Neon, by choosing R to read, and then entering in:

>N:tnfs://my-test-server/NeonTest/Index.DOC

to pull the file down over the FujiNet.  Is this accurate or will this not work.

The short answer is, "it should work".  I'll come back to this after the next question, since parts of the answer tie into that question as well.

2 hours ago, Gibstov said:

 

Second question:

 

If the above works, then theoretically the relative links should work.  When you click on example one, it would resolve to

N:tnfs://my-test-server/NeonTest/Example1.DOC

and example two would be

N:tnfs://my-test-server/NeonTest/Example2.DOC

 

In theory this should work right, I am pretty sure the relative stuff works, but more importantly, it should be able to pull each document down, if it has the full address?

I think I see what you're getting at here.  In this particular case, I'm leaning towards absolute TNFS URIs being necessary.  Here's why:

 

Consider for a moment how a browser determines whether a link is relative or absolute: it retrieves a remote HTML file, examines it for rendering, and notes the absolute location of that specific file on the remote server.  When a link in that file is followed, it is compared with the file's absolute location and a determination is made as to whether or not the link is absolute or relative.

 

TNFS operates differently in that it has no knowledge of the file's contents - it just reads or writes it as appropriate without parsing its contents.  As such, all TNFS URIs can be considered absolute because there's no good way to determine a path relative to the file's location from the contents of file itself by the TNFS client.  This is where I earlier alluded to TNFS being more like FTP than HTTP: even though both FTP and HTTP perform file transfers from a remote host to a local client, FTP doesn't examine and/or act upon the file's contents - much like TNFS.

 

As this relates to Neon: because Neon would be running on top of TNFS (i.e., just using TNFS to transport files to or from the Neon client), Neon would have the same addressing limitations as TNFS would.  Thus, no relative links in Neon.

 

One thing I will add is that TNFS respects URIs with absolute paths that traverse directories - so URIs containing the '..' shorthand to change up a level will be processed correctly.  Symlinks also seem to be handled correctly, but that's more a filesystem-level concern.  Either way, neither one really gets you where you want to be; just decided to mention them for completeness.

 

FWIW, TNFSD is pretty lightweight, by which I mean that simplicity seems to be favoured over features.  Not a huge deal, but it does mean that in order to do things like have a welcome message on the root of the TNFS server, you have to create a zero-length file where the filename is the (very brief) message you want to display when someone accesses that directory.  There's no concept of an index.html or similar.

2 hours ago, Gibstov said:

"Since ADF is a specification as well as software, there's excellent potential for it to run on non-A8 platforms.  This opens the door to things like an ADF daemon handling page compilation on a *nix box acting as the server, much as tnfsd runs on remote non-Atari hosts."

 

It should be fairly straight forward to port the Neon Compiler (Make) to other platforms (famous last words), because the program is written in C.

Nifty, and good to hear.

2 hours ago, Gibstov said:

"BTW: any plans for implementing something analogous to the HTTP PUT and GET methods?  With those, the possibilities of building things like a BBS or platform-specific forum would be very close."

 

Maybe in the future, I was thinking that Form elements could be added.  Kind of using the same frame work, maybe moving the joystick will move the focus to the various controls.  Click the button on the control to change its value.  Though I imagine the way this would work is it would save the Form values as a file.

It occurred to me after I wrote that that TNFS does have its own analogy to the PUT method via the copy feature.  But for something like a form, you'd have to edit it on the client, recompile, then upload rather than just sending the data back for processing.  Not ideal.