Vorticon

It certainly was Looking forward to playing it as it looks really interesting!

Unless you are a collector, $40 seems way over the top as far as pricing is concerned.

This is really looking great You are are actually pulling this off!

Try building a two dimensional matrix with numeric values where you save your maze. You will no longer need those GCHARs. For me it gained a lot of speed, especially in TI Basic. Exactly my thoughts, although I don't have enough memory left for another matrix. What I will do is creatively reuse the matrix used to created the maze.

Yes, Dark Maze certainly comes to mind, although it's not quite the same take. Movement is slow because a lot of GCHAR checks are happening for both the player and the Minotaur, with updating the timer slowing things further. This is the first iteration though, and I have an idea or two that may speed up movement a little bit. I place the Minotaur randomly within 4 rows of the player's initial position to increase pressure, but maybe I'll play with different settings to decreased the difficulty level. Thanks for the feedback More to come.

This game looks much better on real hardware. The edges are softer and the colors warmer... Maybe I've been staring at an NTSC monitor for too long

OK, here's what I was able to come up in a short programming sprint. You are being punished by the Gods, and so you have been thrown in a maze armed only with a feeble torch that will light up your way for a short distance. Find your way out using the arrow keys, and while you are at it a fierce Minotaur is hunting you down. It can hear your footsteps and sometimes even pick up your scent. Your only clue is the beast's breathing which gets louder the closer it is to you. If it gets very close, you might be able to pick up a quick trace of it, maybe... Don't take too long finding the exit or you will die of exhaustion! The maze will be drawn at the beginning of the game, so try to memorize it before you are plunged in the dark. Dedalus.zip

Got it. Pretty cool though

The SZC example seems to be the easiest. Thanks! One question though: wouldn't ANDI R1,0 simply place >0000 in @ANDX2+2 and replace its content?

Hold on to your pants! Matt has yet another idea! Which reminds me I totally forgot to send you that drive enclosure... I'll see if I can send it out this week. Walid

Hi. What is the best way to emulate AND in assembly? The TI provides us with ANDI, but I need to AND 2 registers together. Why there is no built in AND function is a mystery to me...

Nice scrolling owen. And the graphics really look great! One suggestion: I think the scrolling should happen when the character is 2 or 3 characters from the edge rather than right at the edge so that one can see a little further ahead.

All right! I'll get cracking and should have a preliminary report by month's end

Aany client could be identified by its IP address. However, that does not work very well when multiple people are behind a single NATd router. Thus, it would probably be good to just have a new client make an initial "I need and ID" request to the server. The server passes back a new unique ID that it uses to identify the client from that point forward. Then, all requests after that from the client need to include that ID. As for what gets sent to / from the client and server, that is totally up in the air. Your initial data protocol that you were thinking of for the parallel port would work. In the game loop, all clients send their *desired* location information. Once the server receives this information from all clients, it sends back *real* location information to all the clients. This is not totally how online games work, but it is close, and this way everyone would stay in sync. But, a single client with high latency would cause everyone to suffer. So, each client could just send its desired location, then immediately receive real location that is as up to date as possible. The desired vs. real location has to do with the server actually playing the game itself. When a client says "I'm at location x,y", the server sees if that location is valid before saying "ok" and sending your location to the other clients. This helps prevent cheating or illegal moves, but it also means the clients don't have to do location validity checking for all the other players in the game. The server is keeping track of where everyone is, bullets flying, who is shooting who, who is blowing up, where the monsters are, etc. You will see this kind of thing in a modern MMORPG or FPS that is played online. You will be running, then all of a sudden you will be *back* a few steps. That's because you were running forward and your local client was rendering you running in the map, as well as sending your updated location information to the server. You local client always assumes its information is being received by the server. At some point there was probably some lag, and when it caught up the server said "no no no, *this* is where you really are", and your client updated your location based on what the server said. Thus you see a "jump" and all of a sudden you are back where you were 10 seconds ago. It can all get very complicated no matter what physical network is used. For our retro systems, we want to keep the load on the machines as low as possible, so having a real server is probably a good idea (meaning don't use a retro computer for a server.) We also probably don't care as much about people modifying the code or network data to try and cheat (but we should always keep it in mind.) Maybe we can come up with a universal kind of game engine that does not restrict the kind of game being played, ie. you could use it to write just about any kind of game. Lots to think about I guess. It *can* be simple, relatively speaking, since adding coordination and synchronization between even two computers adds a certain amount of complexity. Matthew That's what I'm afraid of... I don't think we can realistically have a TI server do location checks and the like because it will slow things down quite a bit as it is doing work for 3 other consoles. I would prefer to have each individual console do its own checking locally in order to minimize the lag. What I'm going to do is code the protocol for a PIO network and test it out with just 2 consoles and see what issues come up for simplicity's sake. That way I can at least demonstrate a proof of concept. I'll add a third console if everything works out and go from there. If I hit major issues, then we'll look at the serial to ethernet option and I will definitely need your help here with the coding on the server side, likely a linux box. I have a PEB based system and another with a CF7, so I should be set. Does anyone here know if the CF7 parallel port is set up like the TI?

Aany client could be identified by its IP address. However, that does not work very well when multiple people are behind a single NATd router. Thus, it would probably be good to just have a new client make an initial "I need and ID" request to the server. The server passes back a new unique ID that it uses to identify the client from that point forward. Then, all requests after that from the client need to include that ID. As for what gets sent to / from the client and server, that is totally up in the air. Your initial data protocol that you were thinking of for the parallel port would work. In the game loop, all clients send their *desired* location information. Once the server receives this information from all clients, it sends back *real* location information to all the clients. This is not totally how online games work, but it is close, and this way everyone would stay in sync. But, a single client with high latency would cause everyone to suffer. So, each client could just send its desired location, then immediately receive real location that is as up to date as possible. The desired vs. real location has to do with the server actually playing the game itself. When a client says "I'm at location x,y", the server sees if that location is valid before saying "ok" and sending your location to the other clients. This helps prevent cheating or illegal moves, but it also means the clients don't have to do location validity checking for all the other players in the game. The server is keeping track of where everyone is, bullets flying, who is shooting who, who is blowing up, where the monsters are, etc. You will see this kind of thing in a modern MMORPG or FPS that is played online. You will be running, then all of a sudden you will be *back* a few steps. That's because you were running forward and your local client was rendering you running in the map, as well as sending your updated location information to the server. You local client always assumes its information is being received by the server. At some point there was probably some lag, and when it caught up the server said "no no no, *this* is where you really are", and your client updated your location based on what the server said. Thus you see a "jump" and all of a sudden you are back where you were 10 seconds ago. It can all get very complicated no matter what physical network is used. For our retro systems, we want to keep the load on the machines as low as possible, so having a real server is probably a good idea (meaning don't use a retro computer for a server.) We also probably don't care as much about people modifying the code or network data to try and cheat (but we should always keep it in mind.) Maybe we can come up with a universal kind of game engine that does not restrict the kind of game being played, ie. you could use it to write just about any kind of game. Lots to think about I guess. It *can* be simple, relatively speaking, since adding coordination and synchronization between even two computers adds a certain amount of complexity. Matthew That's what I'm afraid of... I don't think we can realistically have a TI server do location checks and the like because it will slow things down quite a bit as it is doing work for 3 other consoles. I would prefer to have each individual console do its own checking locally in order to minimize the lag. What I'm going to do is code the protocol for a PIO network and test it out with just 2 consoles and see what issues come up for simplicity's sake. That way I can at least demonstrate a proof of concept. I'll add a third console if everything works out and go from there. If I hit major issues, then we'll look at the serial to ethernet option and I will definitely need your help here with the coding on the server side, likely a linux box. I have a PEB based system and another with a CF7, so I should be set. Does anyone here know if the CF7 parallel port is set up like the TI?

All true, however it is possible to work out. I'm not too worried about about generalization of the design because I frankly don't see a lot of people throwing a "LAN" party at someone's house too often with TI's You under estimate me! I would have a mandatory TI LAN party with some local friends. LAN ToD!! You could use a TI as the "server". The serial to [uSB / Ethernet] works just like the serial port on the 99/4A side of things. Also, I'd be willing to kick in some Unix based server assistance if you wanted. Heck, with a serial to Ethernet adapter, the games could be Internet based! Matthew That would be a hoot! As for the serial to Ethernet aspect, I guess I need to understand better how that would work from a connectivity standpoint. How would the TI server process all the information being sent to it from the slave consoles? How would it know which one is talking to it and how would it selectively talk back? I wouldn't mind any assistance you can provide here at all

All true, however it is possible to work out. I'm not too worried about about generalization of the design because I frankly don't see a lot of people throwing a "LAN" party at someone's house too often with TI's The project will really be a one off demonstration for the Faire which we could reuse subsequently at later Faires with different games. Besides, it should simple enough to replicate if needs be. That's probably a great way to go but will likely require some pretty technical programming on modern machines which I am not up to. I think I have a hard enough time understanding the ins and outs of the PIO port as it is

Ahhh... Good question. The answer is no. However, what I envision is connecting the PIO ports of the slave consoles in parallel, with the terminus being the server PIO port. That terminal port is the "bus" which is read by all the other ports. So, we can have all the slave consoles continuously monitor the bus for a "data available" signal which could be signaled though the HANDSHAKE lines. Once the signal is received, all the consoles read the data on the bus, which will initially have the ID of a specific console. From there on, only the console with the matching ID will respond, while the others will sit idle. The selected console will acknowledge the server again via the HANDSHAKE lines, which will place the server in "listen" mode and start receiving the data from the console. We will likely need to also use the SPARE lines to corrall each data frame being sent and define a communication protocol. The process will repeat for each slave console. At the end, the server will send again a "data avaialble" signal to all with a special ID code which will allow all the consoles to read the bus at the same time, and update the game. The issue here is whether there will be interference between the different PIO ports, and this will need experimentation. From an electronic standpoint, what kind of issues are you anticipating?

Once the network "protocols" have been established and tested, then it should not be too hard to create any game that takes advantage of this. It certainly does open a bunch of very interesting possibilities

I'm actually thinking of using the PIO (i.e. parallel) port, not the serial port (much faster). All the ports will be connected to a central hub akin to a common bus. Preliminary protocol: 1- Each machine is assigned an ID code 2- One machine will be the "server" 3- The server will query each connected machine in turn for current status. While all the consoles will receive the query, only the console with the matching ID will respond. 4- Once the server has collected all the updates from each machine, it will add its own update, and then send a general game update to all the consoles at once. We could use a special ID code to indicate this. 5- Go back to 3 Easier said than done of course, but I think it's feasible.

I'm not sure I want to revisit the card reader project. That was a lot of fun to develop but it has only academic value, a hack basically. On the other hand, I am considering a real-time multiplayer game demo using several TI's connected via their PIO ports. I'm thinking initially of something relatively simple to code like a Tron Lighcycle contest with 4 players, each one on a separate console. We could easily set this up using CF7's instead of bulky PEB's. That would be kind of fun, and we could even have a mini-championship during the Faire I just have to be careful not to steal too much time away from finishing Ultimate Planet!

Beautiful demo Adam. Quick question: Are you storing the scrollable map entirely in memory or do you load it on the fly in sections from disk?

I will be there barring an unforeseen event, and should have the Ultimate Planet wargame completed by then. I have also just started exploring the possibility of hooking up a CC40 to the TI's PIO port and using the latter as a mass storage device, but it is still way too early for me to tell whether this will come to fruition or not. I will likely attend both the social gathering at the Legion and then join up with the rest of the hackers at the hotel. It's good to have some balance guys

Please post these games! There may be hidden treasures in there

There is already a BASIC/XB converter out there I believe programmed by a German TIer. As a matter of fact I found it on a CD distributed by Berry Harmsen a couple of years ago. What it does is take a plain text file and convert it into a program. I will play with it tonight and see if it still requires line numbers or not. It looks like you are going beyond a straight converter though with some potentially nice enhancements, and I'm looking forward to the final product.