Vorticon
-
Content Count
4,687 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Vorticon
-
-
This is really looking great
You are are actually pulling this off! -
... 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. ...
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.
-
A lot in common with, was it Dark Maze !?
Very nice implementation. Fine graphics. Good effects. Lovely maze drawing. Slow or very slow player movement. Areas you have visited become dark again. I quickly became frustrated. Concentrated more on moving than exploring. Second through fifth play had the Minotaur very close and I was killed almost instantly. Appears to be too many dead ends. Sixth play went better, but only had one way to go (no turn points/intersections before getting killed). Seventh play. Was in a dead end, moved 4 squares and was killed.
Put it on CPU Overdrive. Better movement - which is nice. Same gameplay. Killed almost instantly. Ninth play. Hey, I died of exhaustion. Couldn't remember the maze or anything, but apparently chose the wrong way - opposite way out ? - well, I guess the minotaur can be set anywhere to begin with ?
Nice one. Good work.
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. -
Awesome! Gotta play with this.
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.
-
The "immediate" value is part of the instruction in memory. The >0000 is just a place holder since the assembler needs a value. The opcode is 2-bytes in memory, and the CPU will look at the two byte immediately following the opcode for the immediate value, which we replace at runtime prior to the CPU fetching the immediate value. Note that if the code is in ROM you cannot do this. Also, this kind of self modifying code is illegal on modern processors with run levels, or with processors that read ahead and precache instructions. However, we can do it on our 9900 and that is part of what makes coding on older computers fun.
Got it. Pretty cool though
-
SOC is a logical OR operation. It can take any source and destination types (register, indirect, symbolic, indexed). Why they didn't call it "OR" is beyond anyone.
The SZC does: DST = DST AND (!SRC)
So, if you do a 1's complement (invert) the source register first, SZC will do your AND operation:
LI R1,>FF00 LI R2,>2020 INV R1 R1 = NOT R1 SZC R1,R2 R2 = R2 AND (NOT R1)If you need the original source then you will have to do another INV R1 after the instruction.
The last option would be to overwrite the immediate of the ANDI instruction, or use the X instruction (probably the safest):
DEF MAIN MYWS EQU >8300 * In the data section ... ANDX ANDI R1,0 ANDOP EQU ANDX+2 * Memory address of the ANDX immediate value . . . MAIN LIMI 0 LWPI MYWS LI R1,>FF00 LI R2,>2020 MOV R2,@ANDOP X @ANDX * Or, the direct modification LI R1,>FF00 LI R2,>2020 MOV R2,@ANDX2+2 ANDX2 ANDI R1,0The nice thing about the SOC and SZC methods is that they have byte versions, SOCB and SZCB, and can take all 4 memory access types for both the src and dst. For AND you just have to do and INV on the source, and again afterwords if you care about the original src value.
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?
-
Oooh, that just gave me an idea!
Pretty cool.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.
-
I can do FreeBSD/Linux side server programming in C or PHP. I even have a well connected machine to host a server if we get that far.
All right! I'll get cracking and should have a preliminary report by month's end
-
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
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?
-
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
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?
-
Parallel ports are not designed to be connected together. That's why network cards were invented.
Trying to work out the electrical details would be difficult, and in the end a one-off custom circuit. Parallel cables are also very limited in length.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!!
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
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
-
Parallel ports are not designed to be connected together. That's why network cards were invented.
Trying to work out the electrical details would be difficult, and in the end a one-off custom circuit. Parallel cables are also very limited in length.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.IMO it would be better to use the serial port, and just use a serial to USB adapter, since USB *is* designed to have multiple devices plugged in to the same bus. Or, even better, use the serial port and a serial to Ethernet device, then you can use a TCP/IP network and a FreeBSD/Linux/Unix/MAC/Windows machine as the server (or even another 99/4A, or no "server" at all.) The serial to Ethernet adapters were expensive, but I think they are coming down in price.
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
-
I'm still curious as to how, physically, you plan to connect the machines? Parallel ports are also point to point. Do you have a link to such a parallel port "hub"?
Matthew
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?
-
Walid, that would be amazing! What do you think of the prospects of a multi-player roguelike on a setup like that? Imagine being able to explore a dungeon and then battle the guy sitting across from you in real time, on a 99/4A!
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've been wanting to do a "network" lib for the 99/4A for a while, but until we get some sort of network stack and hardware, it did not seem practical. The problem with serial ports is that they are point to point. How will you have more than two computer connected? I suppose you could require each machine to have two serial ports, and every machine receives and passes on the data in a loop - kind of like token ring. Otherwise you need a "server" machine with lots of serial ports that all the other machines connect to.
Matthew
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.
-
You know what I really liked from last year, Vorticon, was that presentation you did on the card reader! That was great. I would love to see a little project made out of that, something to sell on the CHC store or something!
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
-
I'm going to begin the recovery process of these HCM tapes this week.... OLD CS1, save to CF7, repeat, repeat, repeat repeat.....
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.
-
Maze Man is proving to be quite a nicely designed game--- I have no idea who wrote it or when.... But the mystery is kind of cool.
Maybe we should re-make this in our own image.
I'm going to post it with the next update of the gameshelf. Too bad there is no author known... Thanks for saving it from oblivion! Who knows? The author may stumble across it someday and step up. It has already happened many times since the gameshelf site was launched.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Maze Man
in TI-99/4A Development
Posted
Unless you are a collector, $40 seems way over the top as far as pricing is concerned.