Jump to content
IGNORED

Dreams & Wants of 2021


Omega-TI

Recommended Posts

Some wishlist stuff:

- Compact, legacy-compatible RS-232 which can used in tandem with SAMS/TIPI. 

- Exciting updates/refinements to Realms of Antiquity pending release.  And a nice final manual.  There's a lot to cover.

- Modern demonstration and/or refinement of Barry Boone's MBX subroutines.  Exploration of MBX voice synth.

- Heck, why not a TIPI-based MUD?  Or just more exploration of Internet multiplayer, in the age of TIPI.

 

 

  • Like 3
Link to comment
Share on other sites



Some wishlist stuff:
- Compact, legacy-compatible RS-232 which can used in tandem with SAMS/TIPI. 
Heck, why not a TIPI-based MUD?  Or just more exploration of Internet multiplayer, in the age of TIPI.
 
 


1 you could hook up a RS232 adapter to the pi and make the python changes to make that work with the ti

2 basically there's no way to have a multi-user dungeon which is what mud stands for running on a TI itself. There's a possibility of making a single user dungeon game that is accessible over the internet however that's not quite as fun.. You can play the muds now with your ti with the telnet app. I have three or four on thekeep.net help yourself

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

3 hours ago, pixelpedant said:

Some wishlist stuff:

- Compact, legacy-compatible RS-232 which can used in tandem with SAMS/TIPI. 

- Exciting updates/refinements to Realms of Antiquity pending release.  And a nice final manual.  There's a lot to cover.

- Modern demonstration and/or refinement of Barry Boone's MBX subroutines.  Exploration of MBX voice synth.

- Heck, why not a TIPI-based MUD?  Or just more exploration of Internet multiplayer, in the age of TIPI.

 

 

You'll have RoA before 2021. :)

  • Like 4
Link to comment
Share on other sites

re mud

 

It seems pretty straight forward how to do this; 

 

Since the TI's network stack works through the TIPI anyway, have the TIPI function as either "MUD server" or "MUD Client", where in client mode, it caches resources and dungeon state data even when the TI is not actually requesting it.  The TI then interacts over the very low latency connection with the Pi, via the TIPI exclusively, and is the interface used to actually play the MUD.

 

The hierarchy would then look like this:

 

 

TIPI hosting MUD server
|                          |

---Internet            --Connected TI 99/4A running MUD Dungeon Master program

         |

         --TIPI Running MUD Client

         |                |

         |                  --Connected TI 99/4A running MUD interface program

         |

         --TIPI Running MUD Client

         |                |

         |                  --Connected TI 99/4A running MUD interface program

         |

         --TIPI Running MUD Client

                          |

                            --Connected TI 99/4A running MUD interface program

         

 

(for however many users in the MUD you have)

 

 

The Dungeon Master program would tell the running MUD server what the dungeon looks like, where to put monster spawn points, where puzzle elements are.. etc..  It's the toolbox for crafting and maintaining the dungeon. The server program running on the PI connected to the TIPI, can leverage the vastly increased amounts of RAM, local storage, and networking functions to actually handle multiple users.

 

The client program for the PI, connects to the server over the internet, then caches the dungeon state. It relays user actions from the connected MUD interface program to the server, which then relays it to other connected clients for caching.  This allows for things like graphics data to be downloaded only a single time, and be stored inside the PI's storage, as well as reducing traffic down to just the bare minimum needed to keep the dungeon stateful.

 

The MUD interface program would interact with the client, requesting graphics data, requesting local dungeon data (as can fit in the TI's memory), and provides the UI interface for the player to interact with the dungeon. Since the connection is over the "localhost" connection with the connected TIPI, the latency of talking to the client should be minimal.

 

 

This would allow the client to do all the real heavy lifting and let the TI's basically just be interface portals.

 

 

It should be possible to get the PI to execute a program, upon being called by the TI to do so, by leveraging the embedded telnet. (It should even be possible to get the TI to instruct the PI to grab the needed ARM executable from a known webhost using wget, and everything, and do so transparently to the user. They just "start the game", and the "Game" starts the client, and then connects with a running server.)

 

 

Link to comment
Share on other sites

36 minutes ago, wierd_w said:

re mud

 

It seems pretty straight forward how to do this; 

 

Since the TI's network stack works through the TIPI anyway, have the TIPI function as either "MUD server" or "MUD Client", where in client mode, it caches resources and dungeon state data even when the TI is not actually requesting it.  The TI then interacts over the very low latency connection with the Pi, via the TIPI exclusively, and is the interface used to actually play the MUD.

 

The hierarchy would then look like this:

 

 

TIPI hosting MUD server
|                          |

---Internet            --Connected TI 99/4A running MUD Dungeon Master program

         |

         --TIPI Running MUD Client

         |                |

         |                  --Connected TI 99/4A running MUD interface program

         |

         --TIPI Running MUD Client

         |                |

         |                  --Connected TI 99/4A running MUD interface program

         |

         --TIPI Running MUD Client

                          |

                            --Connected TI 99/4A running MUD interface program

         

 

(for however many users in the MUD you have)

 

 

The Dungeon Master program would tell the running MUD server what the dungeon looks like, where to put monster spawn points, where puzzle elements are.. etc..  It's the toolbox for crafting and maintaining the dungeon. The server program running on the PI connected to the TIPI, can leverage the vastly increased amounts of RAM, local storage, and networking functions to actually handle multiple users.

 

The client program for the PI, connects to the server over the internet, then caches the dungeon state. It relays user actions from the connected MUD interface program to the server, which then relays it to other connected clients for caching.  This allows for things like graphics data to be downloaded only a single time, and be stored inside the PI's storage, as well as reducing traffic down to just the bare minimum needed to keep the dungeon stateful.

 

The MUD interface program would interact with the client, requesting graphics data, requesting local dungeon data (as can fit in the TI's memory), and provides the UI interface for the player to interact with the dungeon. Since the connection is over the "localhost" connection with the connected TIPI, the latency of talking to the client should be minimal.

 

 

This would allow the client to do all the real heavy lifting and let the TI's basically just be interface portals.

 

 

It should be possible to get the PI to execute a program, upon being called by the TI to do so, by leveraging the embedded telnet. (It should even be possible to get the TI to instruct the PI to grab the needed ARM executable from a known webhost using wget, and everything, and do so transparently to the user. They just "start the game", and the "Game" starts the client, and then connects with a running server.)

 

 

TIPI is a serial interface with a DSR. Nothing runs on TIPI but the device DSR.

 

So basically by your description above the mud runs on the PI as a linux application and the TI acts as another client aka "dungeon master"..  so you'd have to develop an entire linux application to do that, plus add on to the interface for the TIPI to allow for comms, or just use tcp for comms I suppose..   

 

You can run a mud on your pi right now, apt-get install and then just telnet to it :) 

 

 

Link to comment
Share on other sites

24 minutes ago, wierd_w said:

For something that might be doable natively though--

 

 

Networked "The Omega Virus", (shameless copy of the Milt&Bradley board game), with 4 players and TI speech.

 

The amount of data needed to be synced would be low, and the board game itself was pretty simple in its graphical elements.

I like the name... ?

2133293568_Virus.thumb.PNG.f0bd2457ee3364a58517b3ff9e4f3655.PNG

 

Link to comment
Share on other sites

One of my long terms wants has a high probability of never happening because it would REQUIRE an F18A, a SAMS card, and probably a fair portion of space on a FinalGROM too for a decent port.  All of which translates into a butt-load of coding on someone's part for only a portion of the TI-Community.  What is it?  A slightly scaled down version of the original SimCity. 

 

Screen.thumb.png.a8cff42c1c15b0eb6bd79191822f5d68.png

 

 

  • Like 3
Link to comment
Share on other sites

It’s an interesting challenge to think about even a 2 line BBS running natively. It would involve polling two serial ports, or even four, constantly, to Asynchronously buffer input or push output. 

I have some experience here...

 

Instead of a branching structure of one-user command prompt loops, with just a few interrupting sysop keys..

 

There would be a round-robin state check and for each user a queue of tasks like fetching a file record or sending a string or checking response. 


I remember the Compuserve Muds from the 80s.  

maybe the Pi could run a straightforward TCP server and assign session numbers to each “caller”. A back and forth protocol over Tipi would comprise packets with a session identifier and data string.
 

I just read how Tymnet bundled chars for many users together in a packet, which was fascinating, but not needed in a short link. 

 

I don’t need another rabbit hole though. My yard is full of them. 

  • Like 2
Link to comment
Share on other sites

It’s an interesting challenge to think about even a 2 line BBS running natively. It would involve polling two serial ports, or even four, constantly, to Asynchronously buffer input or push output. 

I have some experience here...
 
Instead of a branching structure of one-user command prompt loops, with just a few interrupting sysop keys..
 
There would be a round-robin state check and for each user a queue of tasks like fetching a file record or sending a string or checking response. 

I remember the Compuserve Muds from the 80s.  

maybe the Pi could run a straightforward TCP server and assign session numbers to each “caller”. A back and forth protocol over Tipi would comprise packets with a session identifier and data string.
 
I just read how Tymnet bundled chars for many users together in a packet, which was fascinating, but not needed in a short link. 

 
I don’t need another rabbit hole though. My yard is full of them. 
It's the memory requirements in the ti I worry about. I guess if we used SAMS and probably a supercart we might pull off 2 users

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

1 hour ago, arcadeshopper said:

It's the memory requirements in the ti I worry about. I guess if we used SAMS and probably a supercart we might pull off 2 users

Sent from my LM-V600 using Tapatalk
 

I'm thinking about what it would take. I'm not sure the extra user pushes the memory too much higher. My abandoned code for "Hobbit", the TI-Net BBS rewrite in all assembly. It had the data structures for the user and the message board they were reading. I crammed a lot into 128 byte records. I only had the utility routines to measure footprint by; those were between 8-16K. 

 

I'm also mindful that, in another abandoned CRPG, I crammed all the monster and item data for a map location into 64 bytes, by encoding it sort of like MIDI, sort of like LISP.  I did that because a 16x16 map sector could be compressed into 192 bytes with 64 left over for data (:. The 6-bit map codes stood for 32 "fixed" tileset and 32 that varied by what part of the world it was in.

 

Each "thing" took from 1-16 bytes, where 16 bytes might be a treasure chest with 3 used items and a trap and an orc that got in there somehow. Bytes in the range 80-FF signified new items, monsters, attributes. Unrolled items don't need any further bytes. After rolling attributes, those insert bytes in 00-7f. So a new orc might be A0 xx. It's followed by 7 bits of location. If you fight it, it rolls for hit dice (80) and records its hit pts in attribute 81, so it becomes A0 xx 81 hp or 4 bytes.  If it steals your ferret, that goes in its inventory (F0 starts a container, F8 marks its end). Then it has 8 bytes maybe. If it spawns with or picks up a magic sword, that might add a lot of bytes. Same if you cast a spell of slowness or haste on it... At save time, that gets prioritized and squished down, possibly destroying a magic item. A get() routine retrieves either the customized attribute or a default.

 

Anyhow, I would do that and there would be a lot of small cache records moving around. My brain is targeting 32K.

 

Still, for a server, requiring some SAMS is not unreasonable. The client could probably be a more basic system. 32K for sure since it's a serial connection.

Link to comment
Share on other sites

A new version of the TIPI/32k that also supports some of the other RAM expansions.   Use some of the PI’s io pins to be able to turn features on/off when you “CALL TIPI”.  So if a program won’t run from expansion RAM, you could easily shut it off.  Maybe even by having a config file in the same directory that would set up RAM expansion, drives, etc.

Link to comment
Share on other sites

On 10/13/2020 at 1:46 PM, FarmerPotato said:

I'm thinking about what it would take. I'm not sure the extra user pushes the memory too much higher. My abandoned code for "Hobbit", the TI-Net BBS rewrite in all assembly. It had the data structures for the user and the message board they were reading. I crammed a lot into 128 byte records. I only had the utility routines to measure footprint by; those were between 8-16K. 

 

I'm also mindful that, in another abandoned CRPG, I crammed all the monster and item data for a map location into 64 bytes, by encoding it sort of like MIDI, sort of like LISP.  I did that because a 16x16 map sector could be compressed into 192 bytes with 64 left over for data (:. The 6-bit map codes stood for 32 "fixed" tileset and 32 that varied by what part of the world it was in.

 

Each "thing" took from 1-16 bytes, where 16 bytes might be a treasure chest with 3 used items and a trap and an orc that got in there somehow. Bytes in the range 80-FF signified new items, monsters, attributes. Unrolled items don't need any further bytes. After rolling attributes, those insert bytes in 00-7f. So a new orc might be A0 xx. It's followed by 7 bits of location. If you fight it, it rolls for hit dice (80) and records its hit pts in attribute 81, so it becomes A0 xx 81 hp or 4 bytes.  If it steals your ferret, that goes in its inventory (F0 starts a container, F8 marks its end). Then it has 8 bytes maybe. If it spawns with or picks up a magic sword, that might add a lot of bytes. Same if you cast a spell of slowness or haste on it... At save time, that gets prioritized and squished down, possibly destroying a magic item. A get() routine retrieves either the customized attribute or a default.

 

Anyhow, I would do that and there would be a lot of small cache records moving around. My brain is targeting 32K.

 

Still, for a server, requiring some SAMS is not unreasonable. The client could probably be a more basic system. 32K for sure since it's a serial connection.

I don't know why a MUD hosted on a 4A with a TIPI attached for storage and network access couldn't be a thing.  The TIPI server socket support is designed to allow multiple incoming connections on the same listening port.  Setup some limits like 8 users... 8 connection slots... process active connections and then if you have open slots see if there is a new connection waiting for service, stuff it in the chain, and process the existing connections again. Make a fat-client for the 4A, and you can establish a protocol that is light weight for exchanging commands and state changes. You can also spill to file storage if you don't need things active outside cells that users are actually in...    Using models like FarmerPotato describes, you could easily describe a room and it's inventory and connectivity in a single file record. etc, etc, etc... 32k starts to seem like a ton of RAM space. 

Link to comment
Share on other sites

The issue I see is the "Being available" to service an incoming packet event.  The TI is already living behind a wall of waitstates. Throw into that it having to do actual work behind memory that is hobbled, and then having to do strange things with the data bus and a signal line to access the CRU interface...  and then try to throw in "fast network response" on top of it.

 

The more users you have, throwing data into the hosting TI, the worse it will be. 

 

That's why I suggested moving the server portion into the PI itself, and just using the TI as the presentation interface.  It gets pre-processed data streams that way, and does not have to have multi-user contention issues.

 

 

Link to comment
Share on other sites

6 hours ago, wierd_w said:

The issue I see is the "Being available" to service an incoming packet event.  The TI is already living behind a wall of waitstates. Throw into that it having to do actual work behind memory that is hobbled, and then having to do strange things with the data bus and a signal line to access the CRU interface...  and then try to throw in "fast network response" on top of it.

 

The more users you have, throwing data into the hosting TI, the worse it will be. 

 

That's why I suggested moving the server portion into the PI itself, and just using the TI as the presentation interface.  It gets pre-processed data streams that way, and does not have to have multi-user contention issues.

 

 

You might as well as put the server in Amazon web services then... 

 

You forget we are talking about a MUD, not an fully graphical MMO. all this need for speed doesn't exist... Just limit the user base to how many it can handle in 1 second per turn. Realtime games are just turn based games with a really short turn timeout. Hell most users would be fine with 3 seconds per turn. 

 

Using TIPI, and TCP server sockets, the 4A won't lose data. The 4A doesn't have to be available, the incoming data queues in the TCP stack.

  • Like 3
Link to comment
Share on other sites

On 10/13/2020 at 9:22 PM, Omega-TI said:

One of my long terms wants has a high probability of never happening because it would REQUIRE an F18A, a SAMS card, and probably a fair portion of space on a FinalGROM too for a decent port.

The reason it will never happen is not the hardware requirements but because it would take thousands of hours to develop. 

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...