Cybearg Posted August 25, 2014 Share Posted August 25, 2014 Overlaying MOBs to add additional colour Clever use of the Color Stack and "reversed video" to extend the palette Of course, you can always do "multiplexing," but it is not very effective on the Intellivision, and therefore not very common. I don't know what those things mean. Could you please explain? Also, can one change the foreground/background color of cards on a per-card basis, or does setting it for one card affect all until changed? Quote Link to comment Share on other sites More sharing options...
catsfolly Posted August 25, 2014 Share Posted August 25, 2014 (edited) I don't know what those things mean. Could you please explain? Also, can one change the foreground/background color of cards on a per-card basis, or does setting it for one card affect all until changed? Sprites are called "Motion Objects" on the Intellivision. This is sometimes shortened to "mobs". Each Sprite has one color. To make a multicolored character (like "Carol" or "Sydney Hunter"), you can put several sprites on top of each other, with each sprite providing one color. Since there are only 8 sprites total, using 2 or more sprites for one character reduces the total number of sprites available for bad guys, shots, explosions or whatever... "Multiplexing" means alternating a sprite quickly between two or more positions to create the illusion or two or more independent sprites. The most imfamous example of this is probably Atari 2600 Pacman, which used one sprite for all 4 ghosts, with lots of flickering. On the other hand, Intellivision Space Patrol used multiplexing for some of the enemy sprites, and it was pretty much unnoticeable. For a good explanation of the Intellivision video modes, check out the STIC wiki: http://wiki.intellivision.us/index.php?title=STIC Catsfolly Edited August 25, 2014 by catsfolly 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 25, 2014 Share Posted August 25, 2014 Thanks for the information! That explains it well. I'll reiterate the one question that wasn't answered: Also, can one change the foreground/background color of cards on a per-card basis, or does setting it for one card affect all until changed? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 25, 2014 Author Share Posted August 25, 2014 Thanks for the information! That explains it well. I'll reiterate the one question that wasn't answered: You can change the foreground/background per each card. In the Color Stack mode is the only one were the background color is choosed from an actual pointer to a 4 spaces table (4 from 16 colors) and setting one bit (bit 13) in a card changes the background color to next one cycling from the 4. And this background color keeps until setting again the bit 13. Hehehe you didn't read the STIC Wiki 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 26, 2014 Share Posted August 26, 2014 (edited) Hehehe you didn't read the STIC Wiki Finally read it! Initially, I thought I would be going with Mode 0 (Color Stack), but Mode 1 (BG/FG) is looking more and more appealing, now. I foresee fiddling with those color bits will be a real pain in the butt unless I make some kind of subroutine to convert/set those bits for me. Or is that handled by the BASIC? Edited August 26, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 26, 2014 Author Share Posted August 26, 2014 Finally read it! Initially, I thought I would be going with Mode 0 (Color Stack), but Mode 1 (BG/FG) is looking more and more appealing, now. I foresee fiddling with those color bits will be a real pain in the butt unless I make some kind of subroutine to convert/set those bits for me. Or is that handled by the BASIC? IntyBASIC doesn't handle the color bits, it writes the word directly into screen memory $0200-$02EF using PRINT AT. Mostly you don't need to fiddle so much because probably you'll use fixed colors and probably IntyColor to precalculate graphic screens. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted August 26, 2014 Share Posted August 26, 2014 Finally read it! Initially, I thought I would be going with Mode 0 (Color Stack), but Mode 1 (BG/FG) is looking more and more appealing, now. I foresee fiddling with those color bits will be a real pain in the butt unless I make some kind of subroutine to convert/set those bits for me. Or is that handled by the BASIC? I find the Color Stack superior for my own work. I much rather have the increased custom tile space than more colours, if only because more colours can be achieved with clever tricks. The Christmas Carol title screen was drawn in Color Stack mode, and nobody can accuse it of lacking colour <-- click to enlarge Let me see if I can explain some of the tricks used, to which I alluded before. That scene employed the following colour definition: COLOR_STK: C_GRN, C_WHT, C_CYN, C_RED FG_COLOR_0: X_CYN FG_COLOR_1: X_GRN FG_COLOR_2: X_WHT FG_COLOR_3: X_RED FG_COLOR_4: X_DGR FG_COLOR_5: X_ORG FG_COLOR_6: X_YEL FG_COLOR_7: X_BLU FG_COLOR_8: X_LBL FG_COLOR_9: X_PNK FG_COLOR_A: X_YGR The rest uses foreground colours. Notice that the colour transitions mostly follow the stack order, from green to white, to cyan, to red. I say mostly because, as you can see, cyan is not really well represented. So, how do you get from green to white, to green again? This is where clever use of the stack comes into play. My solution to skip stack colours was to advance the colour stack and use only foreground colours. Take a look at the first row: ; 00 01 02 03 04 ; 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 :COL=4,0 :COL=4,0 :COL=2,0 :COL=4,0 :COL=4,1 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=1,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=2,1 :COL=2,1 ; 00 ......#. ........ .......x ######## ###..... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ######## ######## ; The "O" in "Carol" needs to be overlayed ......#. ........ ..##.... ...##### #....... .#####.. ##...#.. ######.. .####... .#####.. ######## .#...#.. ..###... .#####.. ........ .#####.. ..###... ######.. ######## ..###### ; with a MOB. This saves us one GRAM card. ......## ........ .####... .......# #....... ##....#. ##....#. ##....#. ..##.... ##...... ...##... ###.###. .#...#.. ##...... ........ ##....#. .#...#.. ##....#. ######## ..###### ; ......## ........ ..##.... .......# ##...... ##...... ##....#. ##....#. ..##.... .#####.. ...##... #######. ##...##. .#####.. ........ ##...... ##...##. ##....#. ######## ..###### ; The serifs will be overlayed with MOBs also. ......## ........ ........ ........ ###..... ##...... ##...##. ##...#.. ..##.... ......#. ...##... ##.#.##. ##...##. ......#. ........ ##...... ##...##. ##...#.. ######## ..###### .....### ........ ........ ........ #######. ##....#. #######. #####... ..##.... #....##. ...##... ##.#.##. #######. #....##. ........ ##....#. #######. #####... ######## ..####.# .....### #....... ........ ........ ######## #######. ##...##. ##..##.. ..##.... #######. ...##... ##...##. ##...##. #######. ........ #######. ##...##. ##..##.. ######## .......# .....### #....... ........ .......# ######## .#####.. ##...##. ##...##. .####... .#####.. ...##... ##...##. ##...##. .#####.. ........ .#####.. ##...##. ##...##. ######## #.....## The stack starts as green, drawing the background of the Christmas tree. It increases the stack pointer on the 5th column (as attested by second argument in my colour definitions: :COL=4,1). That coincides with the white field, which uses the second colour in the stack, and the letters are painted using a red foreground colour (:COL=3,0 means FG=FG_COLOR_3 (Red), INCREMENT=No). As you can see, the stack is incremented twice on the last two cards (:COL=2,1), conveniently cycling back to the first colour, green, just in time to draw the Christmas tree on the first column of the next row. The first increment (for the letter "O") puts it on cyan, which is not used (the card is a solid block painted with FG white). The next increment puts it on red, which is then used to draw the letter "L" in "reverse video." That is, the red BG colour is used for the FG letter, and the white FG colour is used for the tile's BG. However, that left a hole on the next to last column, where the last "O" would be. (Remember that I skipped the cyan BG colour, and I can't remove cyan from the stack, for I will need it much later.) As the comments in the drawing above note, a MOB is overlaid to fill in. Similar techniques are used for the following rows, all skipping one or two stack entries whenever possible. For instance, by the 4th row, this trick has caught up with me, and I land on the first column with a stack on the third colour, cyan. No worries, just do the same as before: paint it solid with FG colour green. (This re-uses the "solid block" card, which happens to be conveniently in GROM, and saves us GRAM space!) Ta-da! -dZ. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 26, 2014 Share Posted August 26, 2014 First off, thanks tons for your awesome, detailed post! Unfortunately, I'm gonna have to load off my questions... I find the Color Stack superior for my own work. I much rather have the increased custom tile space than more colours, if only because more colours can be achieved with clever tricks.Increased custom tile space? I thought that FG/BG mode only made you lose the non-alphanumeric pre-built ROM cards? Aren't there only 64 custom RAM cards for both Color Stack AND FG/BG? Also, you're clearly using more than 4 color, there. I count at least 9. What gives? The Christmas Carol title screen was drawn in Color Stack mode, and nobody can accuse it of lacking colour title_screen.png <-- click to enlarge Very cool! It looks very complicated for tiles, but I guess it's just very clever tiling, huh? Let me see if I can explain some of the tricks used, to which I alluded before. That scene employed the following colour definition: COLOR_STK: C_GRN, C_WHT, C_CYN, C_RED FG_COLOR_0: X_CYN FG_COLOR_1: X_GRN FG_COLOR_2: X_WHT FG_COLOR_3: X_RED FG_COLOR_4: X_DGR FG_COLOR_5: X_ORG FG_COLOR_6: X_YEL FG_COLOR_7: X_BLU FG_COLOR_8: X_LBL FG_COLOR_9: X_PNK FG_COLOR_A: X_YGR The rest uses foreground colours. Notice that the colour transitions mostly follow the stack order, from green to white, to cyan, to red. I say mostly because, as you can see, cyan is not really well represented. I think I follow... The image happens to have mostly green, then white, then cyan, then red, although that's only the case in this very specific scenario. I guess it takes a lot of careful, clever design to make your scene follow these patterns while still looking dynamic and good. So, how do you get from green to white, to green again?From the tree to the green text, you mean? This is where clever use of the stack comes into play. My solution to skip stack colours was to advance the colour stack and use only foreground colours. Take a look at the first row: ; 00 01 02 03 04 ; 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 :COL=4,0 :COL=4,0 :COL=2,0 :COL=4,0 :COL=4,1 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=1,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=2,1 :COL=2,1 ; 00 ......#. ........ .......x ######## ###..... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ######## ######## ; The "O" in "Carol" needs to be overlayed ......#. ........ ..##.... ...##### #....... .#####.. ##...#.. ######.. .####... .#####.. ######## .#...#.. ..###... .#####.. ........ .#####.. ..###... ######.. ######## ..###### ; with a MOB. This saves us one GRAM card. ......## ........ .####... .......# #....... ##....#. ##....#. ##....#. ..##.... ##...... ...##... ###.###. .#...#.. ##...... ........ ##....#. .#...#.. ##....#. ######## ..###### ; ......## ........ ..##.... .......# ##...... ##...... ##....#. ##....#. ..##.... .#####.. ...##... #######. ##...##. .#####.. ........ ##...... ##...##. ##....#. ######## ..###### ; The serifs will be overlayed with MOBs also. ......## ........ ........ ........ ###..... ##...... ##...##. ##...#.. ..##.... ......#. ...##... ##.#.##. ##...##. ......#. ........ ##...... ##...##. ##...#.. ######## ..###### .....### ........ ........ ........ #######. ##....#. #######. #####... ..##.... #....##. ...##... ##.#.##. #######. #....##. ........ ##....#. #######. #####... ######## ..####.# .....### #....... ........ ........ ######## #######. ##...##. ##..##.. ..##.... #######. ...##... ##...##. ##...##. #######. ........ #######. ##...##. ##..##.. ######## .......# .....### #....... ........ .......# ######## .#####.. ##...##. ##...##. .####... .#####.. ...##... ##...##. ##...##. .#####.. ........ .#####.. ##...##. ##...##. ######## #.....##The stack starts as green, drawing the background of the Christmas tree. It increases the stack pointer on the 5th column (as attested by second argument in my colour definitions: :COL=4,1). That coincides with the white field, which uses the second colour in the stack, and the letters are painted using a red foreground colour (:COL=3,0 means FG=FG_COLOR_3 (Red), INCREMENT=No). Ok, I think that makes sense. But what about all those tiny, multicolored details where there are balls and lights in close proximity on the tree? Also, are you able to use all foreground colors, or are you limited to only certain ones? As you can see, the stack is incremented twice on the last two cards (:COL=2,1), conveniently cycling back to the first colour, green, just in time to draw the Christmas tree on the first column of the next row. The first increment (for the letter "O") puts it on cyan, which is not used (the card is a solid block painted with FG white). The next increment puts it on red, which is then used to draw the letter "L" in "reverse video." That is, the red BG colour is used for the FG letter, and the white FG colour is used for the tile's BG. However, that left a hole on the next to last column, where the last "O" would be. (Remember that I skipped the cyan BG colour, and I can't remove cyan from the stack, for I will need it much later.) As the comments in the drawing above note, a MOB is overlaid to fill in. Really clever! Does this technique often work, or was it just by fortune that it happened to suit this particular case? But, if it's possible to skip more than 1 place in a stack, why didn't you do so for the O? And why does the stack cycle instead of popping, as I would have expected? Similar techniques are used for the following rows, all skipping one or two stack entries whenever possible. For instance, by the 4th row, this trick has caught up with me, and I land on the first column with a stack on the third colour, cyan. No worries, just do the same as before: paint it solid with FG colour green. (This re-uses the "solid block" card, which happens to be conveniently in GROM, and saves us GRAM space!)Again, really clever, but why didn't you just increment to the point in the stack that you needed? Was the compromise purely to save the GRAM space without having to load in another card? Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted August 26, 2014 Share Posted August 26, 2014 First off, thanks tons for your awesome, detailed post! Unfortunately, I'm gonna have to load off my questions... No worries, it was my pleasure. Increased custom tile space? I thought that FG/BG mode only made you lose the non-alphanumeric pre-built ROM cards? Aren't there only 64 custom RAM cards for both Color Stack AND FG/BG? I'm sorry for not being clear. You are right that the FG/BG mode restricts the number of pre-built GROM cards, specifically excluding the graphical/geometric ones. Since I try to use GROM cards as much as possible, not having them available increase the need to use custom GRAM cards for standard shapes such as lines and blocks. This by extension reduces the amount of detail I can include in the scene. I think about it like this, in FG/BG mode, I have ASCII characters in ROM and 64 custom cards; while in Color Stack mode, I have all that plus 128 built-in graphical characters. Also, you're clearly using more than 4 color, there. I count at least 9. What gives? There's the four in the stack: COLOR_STK: C_GRN, C_WHT, C_CYN, C_RED And then there's the 11 FG colours I used: FG_COLOR_0: X_CYN FG_COLOR_1: X_GRN FG_COLOR_2: X_WHT FG_COLOR_3: X_RED FG_COLOR_4: X_DGR FG_COLOR_5: X_ORG FG_COLOR_6: X_YEL FG_COLOR_7: X_BLU FG_COLOR_8: X_LBL FG_COLOR_9: X_PNK FG_COLOR_A: X_YGR The snippet of a row I posted is the actual source drawing I used. I made a script that parses such a file and generates the background data automatically. It includes the colour definitions above so that I can just reference something like "COL:4,0" on each card which means "Use fourth FG colour in the definition (i.e., X_DGR or Dark Green), and do not advance the Color Stack." The rest is just a technical trick: Remember, a blank card with a WHITE background looks exactly the same as a solid block painted in WHITE over a CYAN background. The WHITE pixels obscure the background so you can't see it. Very cool! It looks very complicated for tiles, but I guess it's just very clever tiling, huh? Yes. The way I work through it is that I draw the scene how I want it, break it into tiles, and then try to figure out what I need to do to make it work. Sometimes a particular piece of detail is not possible, so then you trim it. I also sometimes find that the scene takes more than 64 cards, so I figure out how to change pixels here and there to re-use one card in place of two similar ones--or use a GROM card instead. I think I follow... The image happens to have mostly green, then white, then cyan, then red, although that's only the case in this very specific scenario. I guess it takes a lot of careful, clever design to make your scene follow these patterns while still looking dynamic and good. Yes, like I said above, it starts with the artwork. If you think in tiles, your scene will look like a bunch of tiles. Try to have a nice piece of artwork first and then figure out how it needs to be scaled down or modified to make it work, rather than the other way around. Tiling is one step in the process, and not the first one. It takes some work, but the results are spectacular. Take a look at any of nonner64's artwork for GroovyBee's games. So, how do you get from green to white, to green again? From the tree to the green text, you mean? I meant that in the first few rows, the background can be described like this: Green for the tree with colourful baubles sprinkled on it White field for red letters However, the Color Stack has been defined as green, white, cyan, red; while the background looks like its alternating over green then white, then green and white again, seemingly skipping over the last two colours. Ok, I think that makes sense. But what about all those tiny, multicolored details where there are balls and lights in close proximity on the tree? Also, are you able to use all foreground colors, or are you limited to only certain ones? Color Stack mode allows you to use all 16 colours to define the stack and for the foreground colour of GRAM cards. However, for GROM cards, you can only use the first 8 colours in the palette. The multicoloured details are made by painting circles with a foreground colour, like yellow, white, or purple. When you see two balls with different colours right next to each other, that's because they are in different cards, with different foreground colours. The card boundary may be right where the balls converge. Trick! Really clever! Does this technique often work, or was it just by fortune that it happened to suit this particular case? But, if it's possible to skip more than 1 place in a stack, why didn't you do so for the O? And why does the stack cycle instead of popping, as I would have expected? These techniques can be applied to any Color Stack scene. I used them in this particular case because they suit me best, but generally they offer a means to manipulate the stack in a way that you do not have to explicitly use the background colours in order every single time. Why didn't I use it for the "O"? I would have had to draw the "O" in "reverse video" like the "L," and thus consume another GRAM card. However (and this is the clever bit), since the regular "O" was already added to GRAM for other words in the title (e.g., "Ghost" and Of"), I figured I can save one GRAM card by using that same card in a MOB! In its place, the background card for that slot uses the "solid block," which comes from GROM. Trick! And finally, even though it's called a "stack," it actually works as a circular array. That is, every time you advance the stack pointer (i.e., by setting bit 13 on the BACKTAB record), it will point to the next colour. When you advance the stack from the last colour, it will cycle back to the first one. Again, really clever, but why didn't you just increment to the point in the stack that you needed? Was the compromise purely to save the GRAM space without having to load in another card? That's precisely the reason. By the way, it is not just to save GRAM space for the sake of conservation; it's to make GRAM available for other cards that provide greater detail in other areas. Because I saved one or two cards this way, I could use them to overlay the squiggly tails on the bottom of the "R"s and the "T" in "Presents" (called "serifs"), or to give more organic detail to the ribbons. It's a trade off. In closing, let me say that, although this sounds like a lot of work and complex techniques, in practice they are actually rather straightforward. You should make your drawing with as much flair as you want, break it into tiles, and then figure out what you need to do to make it work and fit within the constraints of the platform. These techniques are just more tools in your kit to get you there. My whole point in this discussion is that Color Stack can be very versatile (as I'm sure FG/BG can be as well); all you need is some sharp tools and a bag of tricks. -dZ. Quote Link to comment Share on other sites More sharing options...
drfloyd Posted January 27, 2015 Share Posted January 27, 2015 Hello, Is there a manual/guide/wiki for all the instructions of INTY Basic ? Quote Link to comment Share on other sites More sharing options...
catsfolly Posted January 27, 2015 Share Posted January 27, 2015 Hello, Is there a manual/guide/wiki for all the instructions of INTY Basic ? When you download the latest version, it includes a manual.txt file that explains the commands. Quote Link to comment Share on other sites More sharing options...
ravenxau Posted July 12, 2015 Share Posted July 12, 2015 I just tried to complie an included example with intybasic and get the following error: system cannot execute specified program I'm running Windows Xp SP3 are there any necessary .dll files or anything else that I may be missing? Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted July 12, 2015 Share Posted July 12, 2015 I just tried to complie an included example with intybasic and get the following error: system cannot execute specified program I'm running Windows Xp SP3 are there any necessary .dll files or anything else that I may be missing? Do you have an emulator installed? IntyBASIC only compiles into Assembly Language, then you need to assemble with an assembler. And finally, you need to run with an emulator. We are working on a new version of IntyBASIC that will address many of these issues by providing a set of tools to handle it all for you. Expect it out in a few days. -dZ. Quote Link to comment Share on other sites More sharing options...
ravenxau Posted July 12, 2015 Share Posted July 12, 2015 Do you have an emulator installed? IntyBASIC only compiles into Assembly Language, then you need to assemble with an assembler. And finally, you need to run with an emulator. We are working on a new version of IntyBASIC that will address many of these issues by providing a set of tools to handle it all for you. Expect it out in a few days. -dZ. I have used assemblers befor - Intybasic crashed without even producing an output .asm file hopefully the new tools will sove my problem - look forward to trying them thanx for the help. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted July 12, 2015 Share Posted July 12, 2015 I have used assemblers befor - Intybasic crashed without even producing an output .asm file hopefully the new tools will sove my problem - look forward to trying them thanx for the help. Which version of IntyBASIC are you using? Is it the latest? Could you post a sample of the code that causes it to crash? -dZ. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted July 12, 2015 Share Posted July 12, 2015 I have used assemblers befor - Intybasic crashed without even producing an output .asm file hopefully the new tools will sove my problem - look forward to trying them Can you give more information about what you were doing? e.g. command line, what version of IntyBASIC etc. Screen shots might help as well. Quote Link to comment Share on other sites More sharing options...
freewheel Posted July 13, 2015 Share Posted July 13, 2015 *deep breath* I doubt this is an emulator/assembler/command line/version issue. It's pretty clearly a Windows execution issue (and a somewhat well known Windows error message). https://www.google.ca/?q=system+cannot+execute+specified+program As far as I know, there are no unusual DLL dependencies or anything like that - it should run out of the box on any Windows system. This smells like a security/permissions issue with downloaded files. If it IS a DLL issue, you've done something strange to your Windows install because many people use IntyBASIC on XP without problems. Quote Link to comment Share on other sites More sharing options...
ravenxau Posted July 14, 2015 Share Posted July 14, 2015 (edited) ahhh..... that would be it, I'm actually using MicroXP (a cut down version of XP) - I did try a few different versions of IntyBasic (Command line) and the source code was just one of the included examples in the zip file. Micro XP must have something removed that IntyBasic needs... might sound odd, but is there any chance of a DOS version (just for assembling and linking) that would work under DosBox? Edited July 14, 2015 by ravenxau Quote Link to comment Share on other sites More sharing options...
+nanochess Posted July 14, 2015 Author Share Posted July 14, 2015 ahhh..... that would be it, I'm actually using MicroXP (a cut down version of XP) - I did try a few different versions of IntyBasic (Command line) and the source code was just one of the included examples in the zip file. Micro XP must have something removed that IntyBasic needs... might sound odd, but is there any chance of a DOS version (just for assembling and linking) that would work under DosBox? I see. Probably you're missing the Visual C++ 2008 runtime package (included with XP service pack 2 or 3) http://www.microsoft.com/es-mx/download/details.aspx?id=29 Quote Link to comment Share on other sites More sharing options...
ravenxau Posted July 14, 2015 Share Posted July 14, 2015 I see. Probably you're missing the Visual C++ 2008 runtime package (included with XP service pack 2 or 3) http://www.microsoft.com/es-mx/download/details.aspx?id=29 You were correct - installing the Visual C++ 2008 runtime package has solved the problem. Many thanks for you astute analysis and help. Now to start writing some code and games!!!! 5 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.