An alternative approach to FujiNet (that maybe FujiNet can already do?)

[voidstar]

 

So a little patience, I'd like to tell a background story first...

 

A few years ago, we started a kind of Christmas holiday break "tradition" of playing the 1987/1988 IBM PC version of Wheel of Fortune (WoF).  As many know, it's sometimes a challenge to get non-vintage-computer persons to engage on these old systems.   But there is something "charming" about this particular old version of WoF - it's a casual pace replica of the game with some cute CGA, with up to three players ("live" or AI).  It started off as just my excuse to fire up the old IBM PC 5150, but as family visited during holidays, I found the game to be just engaging enough that both young and old folks can understand and enjoy it.  So a variety of folks would huddle around the vintage computer - and if folks got interrupted (phone call, check on the cooking, go pick up missing supplies, etc.), other folks could take their spot.  An example of what Thomas has said "being useful" for these old systems.

 

But eventually it occurred to me: the game-state itself is fairly simple.  So, it's similar to the modern web: the content (game-state data) can be independent to the presentation (how-you-show that game-state).   That is, why couldn't an Apple (40x24), Commodore PET (40x25), TRS-80 (64x16) also "link up" and join in on the game?  Or, why couldn't there be a lobby of waiting WoF sessions - and I use my "vintage system of the day" to join in? (i.e. the modern game-lobby concept).   How the game is presented is different to each of us, but the overall game-state is consistent (whose turn it is, total points, what letters have been guessed already, etc.).   [ taken to the extreme, imagine a hypothetical system with a 20x4 LCD as its screen - there eventually would be "minimum hardware requirements" for certain applications, plus WoF has things like a limited amount of time between turns ]

 

Doing this would require all new software for those vintage systems (to know how to use a serial interface to cross-connect to a TCP/IP port, gather game state info, and present it accordingly to the systems local capability).  So, another idea came to me: what about a kind of "kaleidoscope" application?  These vintage machines connect to a server, announce their local capability, and the server just starts to "push" content that renders stuff appropriately to that vintage system?  I viewed this as just a specialized version of a BBS (I use to run one years ago).  This would be great to just have setup as a kind of dynamic "screen saver" or a passive "screen crawl" to present on these systems.

 

So as a proof of concept, I built something like this last year (borrowing an old multi-client network test tool that I had also built years ago).  My PET and CoCo3 have legacy terminal software that understand VT52 and ANSI.  So, I'd use the WiModem on those systems to connect to my server (a kind of typical telnet thing).  Then using regular terminal software, the connected client types a simple command, such as:

"*B,W32,H16,ANSI,E*"  

This simple command tells the server the local clients width and height (32x16 is old CoCo1/2 default), terminal protocol, and B|E just mark the beginning/end of the command.  Just given that context, the server then "randomly generates" content (in ANSI, but keeping the cursor within the height/width constraint). If VT52 was specified, the server omitted color commands.  

 

Then I wrote a script utility, where you could specify animations that got exported to both VT52 and ANSI formats.  The script interpreted a mini-language I used to "programmatically define" a kind of animated picture, including instrumenting wait-states (for example, to "wait half a second" varies if the person is connected at 300baud vs 19200- so the server has to know how to interpret these wait/pause commands depending on the capability of the connected client).

 

The next step would be to add smarts to auto-scale a given animation into smaller and larger resolutions.  But basically this is abstracted to the concept of having a server stream out animated ANSI content - hence the "vintage kaleidoscope" name.

 

The concept worked, but I never polished it off for production.  Extending the concept further, the server would "model" the screen state of each connected client - it would know what the connected client "should" look like (assuming it has received and parsed all the terminal commands correctly, or that they had sent a correct configuration command at the beginning -- this is similar to why classic BBS's ask to press ESC during connection, as a way to auto-detect your terminal capability; but a more modern approach is to just have a standard "identity command", except that all the legacy BBS software couldn't be updated to such a standard).

 

From there, it could be interactive, and do round-robin "turns" to each connected client.  The advantage here is that existing terminal software could be used, but the "hard work" is moved all to the server (of coordinating the state of each client, and dealing with things like sudden disconnects of participants - like power failures for instance; the server could also proxy in AI players during a dropout like that).   

 

NOTE: In the TV series Halt and Catch Fire, they depict a startup company implementing this idea of multi-play games across a modem.  It depicts a tank game, and there is a scene with frustration in accurately/fairly trying to determine "who fired first."  There is no real solution to this, when you have some clients at 300baud and other clients at 57600.  Modern MMOs still have this problem - not so much due to baud rates (lag has some impact, sure).  But also just the variety of hardware (some people at 10fps versus 60+ fps).  Anyway, I think turn based card or strategy games can work here - but interactive real-time games might struggle (like racing games).

No single system probably has enough of a following to sustain an active lobby on its own.  But collectively there are many vintage computer enthusiasts - we might not power up the same systems every day, but being able to casually interact with a heterogenous set of other systems (via a coordinated lobby) would be interesting, and keep the systems "useful" (as Thomas mentioned in his recent VCF talk).

 

 

So, the above approach is basically treating all the vintage systems as "dumb terminals" -- and was leaning more towards "ASCII text" type games (recall the IBM PC Scott Miller Kroz games).  Although the IBM PC WoF used CGA graphics, the game state could be depicted without that.   I think FujiNet works a bit differently, with a larger expectation of the application work running on the vintage system itself?   Regardless, aside from the technical aspects - I think both ideas have the same goal: shared interactive experience across a variety of vintage systems.     So with that, I'll strive to learn more about FujiNet, and will be interested to see if we could get that goal of Wheel of Fortune as one of its applications (in some mock up samples, I realize it doesn't have to be a wheel - on the PET I was just going to depict a vertical version of the board; note the standard version of that game uses "24 wedge" pieces, conveniently enough to fit on the screen of many vintage systems).   Or just the "show me a kaleidoscope" screen saver would be nice too [ i.e. "just make my vintage system draw some stuff."   but have change throughout seasons/year -- the ISS Tracker is a neat application, kudos on that ].

 

 

[voidstar]

Here is a "concept" diagram I had awhile back.   

 

I've seen IRC-like chat channels ( bbs.alsgeeklab.com:2323 has one, intra-connected with a few BBS's ), which has a very clever usage of ANSI to coordinate screen updates.  Requires no new software on the vintage system (just an existing terminal program).  But they are generally "locked" to typical 40-col or 80-col systems -- the experience doesn't work when connecting with a 32-col CoCo.  A "new kind of BBS" could ask a new connected client just a few questions: screen dimension, what character set they support (CP-437), and can they support some cursor-movement protocol (VT52/100/ANSI, or just a "line printer").  A "standard command" could be defined to specify all this.

Again, it's just treating the vintage systems as "dumb terminals" connected to a specialized web server (one that "down scales" to the declared limits of the client).     

 

 

One of the last BBS host software I ran in mid-1990s did have graphical support.  But I can't remember its name or protocol - the only client terminal I saw was on the IBM PC.  As a SysOp, we had to draw a page using a graphical editor provided with the BBS (not ASCII Art, TheDraw type stuff - but actual graphics), and designate mouse click points.  It would save the graphic in a compressed format (more like commands of: "draw box here" and "draw line here of this color"), and exchange that with clients (if they designated that they were running a terminal that support this protocol).  So "graphical BBSing" was a thing, but quickly overran by HTML+Netscape, etc.

 

[tschak909]

2 hours ago, voidstar said:

Here is a "concept" diagram I had awhile back.   

 

I've seen IRC-like chat channels ( bbs.alsgeeklab.com:2323 has one, intra-connected with a few BBS's ), which has a very clever usage of ANSI to coordinate screen updates.  Requires no new software on the vintage system (just an existing terminal program).  But they are generally "locked" to typical 40-col or 80-col systems -- the experience doesn't work when connecting with a 32-col CoCo.  A "new kind of BBS" could ask a new connected client just a few questions: screen dimension, what character set they support (CP-437), and can they support some cursor-movement protocol (VT52/100/ANSI, or just a "line printer").  A "standard command" could be defined to specify all this.

Again, it's just treating the vintage systems as "dumb terminals" connected to a specialized web server (one that "down scales" to the declared limits of the client).     

 

 

One of the last BBS host software I ran in mid-1990s did have graphical support.  But I can't remember its name or protocol - the only client terminal I saw was on the IBM PC.  As a SysOp, we had to draw a page using a graphical editor provided with the BBS (not ASCII Art, TheDraw type stuff - but actual graphics), and designate mouse click points.  It would save the graphic in a compressed format (more like commands of: "draw box here" and "draw line here of this color"), and exchange that with clients (if they designated that they were running a terminal that support this protocol).  So "graphical BBSing" was a thing, but quickly overran by HTML+Netscape, etc.

 

We've already gone way past that.

 

e.g. the FujiNet can parse XML and JSON data on the device, sending back relevant data to the computer via query.

This has been used to implement a whole bunch of apps, including a 5 card stud poker game, with lobby, using standard protocols, that any of the target FujiNet systems can implement fully featured clients for.

 

-Thom

 

Edited July 2, 2023 by tschak909

[tschak909]

Come to the discord: https://discord.gg/7MfFTvD and pitch in! 

 

-Thom

 

[voidstar]

I've too many other projects at the moment, mostly I just wanted to express some ideas of how this could be used and see if I was in the ballpark of understanding how it works.  I may not have the proportion of how much local ROM software is used, versus just server pushed display updates, quite right.   And I was thinking in terms of a single central server, but seems for now the idea is a server per app?  Eitherway, the goal is interconnected "low bandwidth" systems, and I think FujiNet can get us there.

 

After July hopefully I can get more hands-on here - specifically, to try to be an advocate in the CoCo community.    (longer term, seeing some pre-1977 equipment involved would be neat, like the IBM 5100 or even a PDP-8 - but seems a modern Arduino with a 40x4 LCD could also be adapted as a platform).

 

One comment though:  The word Fuji always just makes me think of FujiFilm.  So early on it got in my head that this project was related to photography    I guess it could be - one app could be the streaming of a webcam video into low fidelity ASCII art?

 

Edited July 2, 2023 by voidstar