Jump to content
IGNORED

Space Harrier XE


Recommended Posts

In my opinion a great advantage of the VBXE is the possibility to use the high quality RGB-output. You don´t have to use the improved graphic abilities, maybe there´ll be not much software for it, but you can benefit of the better screen anyway.

 

Sleeπ

 

Which graphics mode in stock Atari benefits from RGB? Perhaps, artifacting is gone in 384*240 (assuming RGB monitor can handle the overscan).

Link to comment
Share on other sites

Indeed, all standard Atari graphics modes have ultra sharp RGB video output with the VBXE. For me it was one of the main reasons to buy a VBXE. The additional graphics features are a bonus.

 

Because the picture is so sharp, graphics 8 artifacting is indeed gone. A game like Amaurote that has moire patterns with the regular video output (PAL), now has pure black white pixels. For some this might be a disadvantage, but in that case you can still use the regular output. My XE is connected with both RGB and Chroma/Luma to a Commodore 1084 monitor and with one press of a button I can switch between both inputs.

 

One additional benefit is if you have one of those 800XEs with a faulty GTIA chip. The VBXE output displays the GTIA modes correctly because it bypasses the bugged GTIA chip.

 

Robert

Link to comment
Share on other sites

All of them.

You have to see it to believe it.

 

Forget any "Super Video" mods, VBXE makes any existing signal look stoneaged.

 

Given most monitors are at least color clock resolution, I would have to see it to believe it. And unless it works with those Commodore type dual composite/rgb type monitors, you would need to carry an extra monitor as well.

 

And about artifacting, most software using 320+ resolution assumes it exists, so it's not that useful to not have it.

Link to comment
Share on other sites

Ha ha!

yeah, you'd need the cable too. And the blank carts are about $20 a pop (Atarimax.com) Good of Sal to offer a cart up. I might have another cart knocking about somewhere too, which could save you on shipping (although you'd miss out on the fancy lablel!)

 

 

Shipping for something this simple should be about $10-$15 US dollars at the most.

Link to comment
Share on other sites

1084 isn't colour-clock resolution, it's well over double. It displays Amiga and VBXE resolutions just fine.

 

I'd hardly say "most 320x" software wants/assumes artifacting. In fact, with PAL systems, artifacting is mostly undesirable because it looks crap.

Link to comment
Share on other sites

When I'm done with Space Harrier (soon!)

:D Now that's great news.

 

Sheddy, will the NTSC version be identical to the PAL one? NTSC Ataris produce screen with slightly different colours and different pixel aspect ratio. Knowing that your game is an excersise in perfectionism ;), I'm curious whether you take the above issue into account.

 

Given most monitors are at least color clock resolution, I would have to see it to believe it.

With RGB signal the whole concept of colour clocks becomes irrelevant. The signal is sent from the source straight to the screen without any modulation or YUV encoding.

 

And about artifacting, most software using 320+ resolution assumes it exists, so it's not that useful to not have it.

True for US software, but for Europeans it won't be that much of an issue, since they don't see artifacting normally anyway.

Link to comment
Share on other sites

Sheddy, will the NTSC version be identical to the PAL one? NTSC Ataris produce screen with slightly different colours and different pixel aspect ratio. Knowing that your game is an excersise in perfectionism ;), I'm curious whether you take the above issue into account.

Not quite that much perfectionism ;) I am looking at defining different colour palette for NTSC though, although it might look strange on some of the Emus that don't have a NTSC palette

Link to comment
Share on other sites

1084 isn't colour-clock resolution, it's well over double. It displays Amiga and VBXE resolutions just fine.

 

I'd hardly say "most 320x" software wants/assumes artifacting. In fact, with PAL systems, artifacting is mostly undesirable because it looks crap.

 

That's why it looks like crap because the software assumes artifacting and it doesn't occur (for the most part) on PAL. Also, when you adjust the 1084 monitors hsize/vsize, you are rescaling the image to another grid that most likely doesn't correspond to the exact number of RGBs on the physical screen so there's some distortion being added there even with RGB mode. Only LCDs with exact mapping of pixel coming in to pixel going out can you obtain a perfect image.

Link to comment
Share on other sites

I think the point is being missed here: what Rybags is saying (and I'm sure he'll correct me if I'm wrong) is that in all but the handful of instances where software (usually a game) was designed to take advantage of artifacting, it looks awful and is completely undesirable. I'd say "most" hi-res (320x) software looks a damned sight better without artifacting, which is at best an inexact process which doesn't even work consistently across the board.

 

I'd strongly advise anyone who hasn't seen VBXE on a good quality LCD or 1084S montor to take a look at it. To me, it's like having a veil of electromagnetic crap and noise lifted from the screen, revealing the true picture beneath. My original reason for buying VBXE was its RGB display. That's not to say you can't get similar results with s-video if you're prepared to mod the guts out of your Atari and happen upon the one in a hundred LCD panels which handle the picture just right.

 

A 1-1 pixel mapped display (obtainable if such things as roughly 332x240 or 664x480 LCD panels existed to cater precisely for the border areas) would not necessarily constitute a perfect display for the Atari. Some level of pixel interpolation is acceptable, and even desirable for a picture not to look too cartoonish. It has a similar effect to ClearType on the PC. The simple inescapable fact of the matter is that you will not get a better picture from the Atari than from VBXE. And to want that, in this day and age, is not sacrilegeous.

 

The question of whether games and applications should be modified to take advantage of the new hardware capabilities is another matter, but I for one have gradually warmed to the fact that my Atari now has a hardware 80 column text mode. That's not to say I didn't do a lot of soul searching in the early days of the VBXE project. The ideal scenario is that a game or application should check for VBXE and take advantage of it if it detects the hardware.

Edited by flashjazzcat
Link to comment
Share on other sites

Well, same is true for PAL. Some PAL games have problems on NTSC. And those using NTSC artifacting have problems in appearance on PAL systems. I don't see much improvement for 160 wide modes on Atari whether I use Svideo or composite so RGB shouldn't help much. Even RF output looks great to me.

Link to comment
Share on other sites

Sheddy, will the NTSC version be identical to the PAL one? NTSC Ataris produce screen with slightly different colours and different pixel aspect ratio. Knowing that your game is an excersise in perfectionism ;), I'm curious whether you take the above issue into account.

Not quite that much perfectionism ;) I am looking at defining different colour palette for NTSC though, although it might look strange on some of the Emus that don't have a NTSC palette

Users who care that much, probably all have already configured their emulators with custom palettes ;) Atari800 from version 2.1.0 supports separate PAL and NTSC palettes; moreso colour accuracy has improved since the last release. So things are definitely getting better. Maybe other emulators will follow.

 

Nice to know that you have such an eye for detail. I'm keeping my fingers crossed for you to finish the game.

 

 

1084 isn't colour-clock resolution, it's well over double. It displays Amiga and VBXE resolutions just fine.

Shouldn't surprise anyone since the monitor handles Amiga's 640*512 interlaced without problems. With ~13" vievable area and dot pitch of 0.42mm, the screen's grid has resolution of about 640*480.

 

I'd hardly say "most 320x" software wants/assumes artifacting.

Who's gonna be the first person to count number of hi-res programs from the US vs. hi-res programs from Europe? :)

 

That's why it looks like crap because the software assumes artifacting and it doesn't occur (for the most part) on PAL.

Even with PAL software which obviously doesn't need artifacting, the amount of artifacts that occur on PAL makes the graphics smeared and ugly.

 

Also, when you adjust the 1084 monitors hsize/vsize, you are rescaling the image to another grid that most likely doesn't correspond to the exact number of RGBs on the physical screen so there's some distortion being added there even with RGB mode. Only LCDs with exact mapping of pixel coming in to pixel going out can you obtain a perfect image.

That distortion isn't really noticeable on CRT screens. With LCD, each subpixel is treated as a whole - the whole area of a subpixel has the same brightness. With CRT, due to its analogue nature, each dot in the grid can be lit partially - you can have a half of the dot fully lit and the other half unlit. This allows the display to still look great despite not being 100% adjusted to the dot grid.

 

I think the point is being missed here: what Rybags is saying (and I'm sure he'll correct me if I'm wrong) is that in all but the handful of instances where software (usually a game) was designed to take advantage of artifacting, it looks awful and is completely undesirable.

I sense a logical contradiction here - if a software was designed to use artifacting, it by definition looks desirable - I mean, as desired by the author.

 

I'd say "most" hi-res (320x) software looks a damned sight better without artifacting, which is at best an inexact process which doesn't even work consistently across the board.

U.S. hi-res software definitely looks better with artifacting even if it's inconsistent colour-wise. (I know they're emulated screens, but they're fairly accurate).

Edited by Kr0tki
Link to comment
Share on other sites

 

I think the point is being missed here: what Rybags is saying (and I'm sure he'll correct me if I'm wrong) is that in all but the handful of instances where software (usually a game) was designed to take advantage of artifacting, it looks awful and is completely undesirable.

I sense a logical contradiction here - if a software was designed to use artifacting, it by definition looks desirable - I mean, as desired by the author.

 

 

That's exactly what FJ is saying in that sentence ;)

 

 

Pete

Link to comment
Share on other sites

Off-topic alert: Would it actually be possible to have a cheap version of VBXE without all the fancy features BUT the RGB output?

I know Candle's pooh-poohed this idea in the past, but to be honest, for purists with shallow pockets, it would be a desirable upgrade.

Link to comment
Share on other sites

I think the point is being missed here: what Rybags is saying (and I'm sure he'll correct me if I'm wrong) is that in all but the handful of instances where software (usually a game) was designed to take advantage of artifacting, it looks awful and is completely undesirable. I'd say "most" hi-res (320x) software looks a damned sight better without artifacting, which is at best an inexact process which doesn't even work consistently across the board.

...

It's only two types of artifacting for NTSC A8 machines so I would say it's pretty exact. It's good to know you can put some colors up in high resolution even if they are different on XL/XE vs. 400/800. I'm sure that can be taken into account. I haven't seen what it looks like on PAL, but that could be a third option.

 

I'd strongly advise anyone who hasn't seen VBXE on a good quality LCD or 1084S montor to take a look at it. To me, it's like having a veil of electromagnetic crap and noise lifted from the screen, revealing the true picture beneath. My original reason for buying VBXE was its RGB display. That's not to say you can't get similar results with s-video if you're prepared to mod the guts out of your Atari and happen upon the one in a hundred LCD panels which handle the picture just right.

...

I wasn't speaking against VBXE but about standard A8 modes using RGB. You don't gain much with a RGB output vs. standard RF/Svideo/Composite A8 signals. Perhaps, if you want to simulate an 80-column display (which Atari wasn't meant for), yeah artifacting would stink things up. The standard 40-column text mode on A8 was set up with the colors to minimize artifacting (since there it was undesirable) whereas in other scenarious it was desirable.

 

A 1-1 pixel mapped display (obtainable if such things as roughly 332x240 or 664x480 LCD panels existed to cater precisely for the border areas) would not necessarily constitute a perfect display for the Atari. Some level of pixel interpolation is acceptable, and even desirable for a picture not to look too cartoonish. It has a similar effect to ClearType on the PC. The simple inescapable fact of the matter is that you will not get a better picture from the Atari than from VBXE. And to want that, in this day and age, is not sacrilegeous.

...

Again back to the point-- it's not necessary nor that helpful to have RGB output for standard A8 modes.

 

The question of whether games and applications should be modified to take advantage of the new hardware capabilities is another matter, but I for one have gradually warmed to the fact that my Atari now has a hardware 80 column text mode. That's not to say I didn't do a lot of soul searching in the early days of the VBXE project. The ideal scenario is that a game or application should check for VBXE and take advantage of it if it detects the hardware.

 

Well, I don't see how we draw a generic conclusion about A8 video based on requirement by some applications of an 80 column mode which standard A8 doesn't support.

Link to comment
Share on other sites

Given most monitors are at least color clock resolution, I would have to see it to believe it.

With RGB signal the whole concept of colour clocks becomes irrelevant. The signal is sent from the source straight to the screen without any modulation or YUV encoding.

 

 

What I was referring to here the minimum resolution that TVs/monitors can handle-- based on the color clock (3.57Mhz). They can definitely deal with 160*240 without screwing things up that you need an RGB monitor. I need some proof to say this is not so. Perhaps, a snapshot of 160*200 images with composite/svideo and RGB output.

Link to comment
Share on other sites

Off-topic alert: Would it actually be possible to have a cheap version of VBXE without all the fancy features BUT the RGB output?

 

I tried to build a simple device for NTSC Atari's that would determine the phase of the color clock on each 160-width cycle so it could look up RGB values in a ROM. The idea was to bypass the normal NTSC decoding and generate a perfectly crisp RGB picture. It never worked very well, but it still might be possible with a slightly different approach.

 

For NTSC, the color output is simply the 3.58MHz clock delayed by a certain number of ns. The idea I had was to determine how many ns after the start of the cycle the signal transitioned (low-hi or hi-low) and then determine what color GTIA is trying to produce. With accurate enough circuitry, I think it could still work.

Link to comment
Share on other sites

I reckon that'd be a good idea... probably need to run on a 28 MHz clock or something though wouldn't it?

 

In conjunction with a feed from luma you could just have a palette similar to the way VBXE operates. Maybe have some option for saturation control too.

Link to comment
Share on other sites

I reckon that'd be a good idea... probably need to run on a 28 MHz clock or something though wouldn't it?

 

In conjunction with a feed from luma you could just have a palette similar to the way VBXE operates. Maybe have some option for saturation control too.

 

Sure you could use any RGB palette you wanted. Here's some more details of how I'd do it:

 

The transitions near the color clock boundaries are pretty messy. Since there are two transitions per cycle, it would be best to look for a transition that happens in the middle portion of the color clock cycle.

 

You'd have to tune the GTIA color delay to match the reference timing.

Link to comment
Share on other sites

You don't gain much with a RGB output vs. standard RF/Svideo/Composite A8 signals.

Erm... OK.

 

Perhaps, if you want to simulate an 80-column display (which Atari wasn't meant for), yeah artifacting would stink things up. The standard 40-column text mode on A8 was set up with the colors to minimize artifacting (since there it was undesirable) whereas in other scenarious it was desirable.

True, the standard 40 column font was set-up to counteract artifacting, but where is it written that artifacting was designed into the machine in the first place? It's surely a by-product of Atari's crappy colour circuits, coupled with the absolute inability of the most prevalent display device of the time (the large dot-pitch TV set via RF or CV) to adequately display a half colour clock pixel properly. The fact that games designers came along and capitalized on the effect doesn't mean that it was designed into the specs of the machine as a "feature"? The fact the Atari doesn't have a hardware 80 column text mode surely doesn't obviate the possibility or desirability of being able to depict a half colour clock line in the correct hue.

 

Again back to the point-- it's not necessary nor that helpful to have RGB output for standard A8 modes.

Not "necessary", no, but very helpful depending on your combination of display device. S-video is being gradually phased out on TV sets in Europe, and legacy CRT and even LCD monitors will not last forever. SCART remains popular in Europe, but the fact that American sets don't have it probably makes VBXE far less versatile over there. But returning to that point: I was simply responding to your assertion that a 1-1 pixel mapped display is the only way to obtain a "perfect" picture.

 

...I don't see how we draw a generic conclusion about A8 video based on requirement by some applications of an 80 column mode which standard A8 doesn't support.

The fact that some applications avail themselves of an 80 column mode - either via software or hardware - wasn't cited as a generic conclusion about A8 video. I was responding to concerns of purists who assert that a VBXE equipped Atari 8-bit might as well be a PC or Commodore Amiga. The fact is that you can buy a VBXE and enjoy a nice display and not worry about the blitter and extra colours.

Edited by flashjazzcat
Link to comment
Share on other sites

You don't gain much with a RGB output vs. standard RF/Svideo/Composite A8 signals.

Erm... OK.

...

You misunderstood (or misquoted). I am speaking in context of standard A8 modes. You don't gain much with a RGB output vs. a standard RF/Svideo/Composite A8 output.

 

Perhaps, if you want to simulate an 80-column display (which Atari wasn't meant for), yeah artifacting would stink things up. The standard 40-column text mode on A8 was set up with the colors to minimize artifacting (since there it was undesirable) whereas in other scenarious it was desirable.

True, the standard 40 column font was set-up to counteract artifacting, but where is it written that artifacting was designed into the machine in the first place? It's surely a by-product of Atari's crappy colour circuits, coupled with the absolute inability of the most prevalent display device of the time (the large dot-pitch TV set via RF or CV) to adequately display a half colour clock pixel properly. The fact that games designers came along and capitalized on the effect doesn't mean that it was designed into the specs of the machine as a "feature"? The fact the Atari doesn't have a hardware 80 column text mode surely doesn't obviate the possibility or desirability of being able to depict a half colour clock line in the correct hue.

...

That's your speculation that it's crappy color circuits. I think it's doing exactly what it was meant to do. It wasn't written that you can replicate (re-use) colors horizontally either, but its consistent and it works (and for a lot of other things as well). Same thing with artifacting-- it's consistent amongst 400/800 and XL/XE series and because of that it has been written in many places including Atari magazines. Showing an exact hue in half a color clock was a later thing and that is subject to more inexactness then artifacting. So your assertion:

 

"I'd say "most" hi-res (320x) software looks a damned sight better without artifacting, which is at best an inexact process which doesn't even work consistently across the board."

 

is unfounded. I guess I don't have PAL software so most is also correct for me that most software in 320+ mode will look worse without artifacting.

 

Again back to the point-- it's not necessary nor that helpful to have RGB output for standard A8 modes.

Not "necessary", no, but very helpful depending on your combination of display device. S-video is being gradually phased out on TV sets in Europe, and legacy CRT and even LCD monitors will not last forever. SCART remains popular in Europe, but the fact that American sets don't have it probably makes VBXE far less versatile over there. But returning to that point: I was simply responding to your assertion that a 1-1 pixel mapped display is the only way to obtain a "perfect" picture.

...

It's not helpful at all as far as I'm concerned since I don't see the difference in 160 and lower resolutions and for 320 mode, it's more subjective. I prefer having artifacting for my work. As far as 1-1 display occurs, yep only LCDs do that-- I have a thinkpad with 1024*768 display and it maps 1-1 with the video card otherwise it crops it and still does a 1-1. The RGB and SVideo/Composite/RF all affect the signal in someway to prevent a 1-1. I wasn't claiming one should get an LCD for Atari though-- it's prefectly fine to use the stock video outputs. Thus, I don't buy your assertion which is just speculation (or misunderstanding):

 

"Some level of pixel interpolation is acceptable, and even desirable for a picture not to look too cartoonish. It has a similar effect to ClearType on the PC. The simple inescapable fact of the matter is that you will not get a better picture from the Atari than from VBXE. And to want that, in this day and age, is not sacrilegeous."

 

You will get a fine picture without any RGB output for standard A8 modes.

 

...I don't see how we draw a generic conclusion about A8 video based on requirement by some applications of an 80 column mode which standard A8 doesn't support.

The fact that some applications avail themselves of an 80 column mode - either via software or hardware - wasn't cited as a generic conclusion about A8 video. I was responding to concerns of purists who assert that a VBXE equipped Atari 8-bit might as well be a PC or Commodore Amiga. The fact is that you can buy a VBXE and enjoy a nice display and not worry about the blitter and extra colours.

 

Well, you wrote:

 

"I'd strongly advise anyone who hasn't seen VBXE on a good quality LCD or 1084S montor to take a look at it. To me, it's like having a veil of electromagnetic crap and noise lifted from the screen, revealing the true picture beneath. My original reason for buying VBXE was its RGB display. That's not to say you can't get similar results with s-video if you're prepared to mod the guts out of your Atari and happen upon the one in a hundred LCD panels which handle the picture just right."

 

That's total rubbish. For stock A8 modes, there's no crap to be lifted nor any modifications to Atari hardware necessary to get perfectly good video output. I have never modified any of my machines except those that don't have A/V output (600XL/A400). Atari is perfectly fine for what it was meant for. The fact that you can't get a good 80-column display or avoid artifacting for YOUR particular case does NOT allow you claim Atari video circuit is crappy or needs heavy modifications. It works fine for what it's meant for and beyond that as well for many hacks.

Link to comment
Share on other sites

Off-topic alert: Would it actually be possible to have a cheap version of VBXE without all the fancy features BUT the RGB output?

 

I am the opposite-- I think it's better to have a VBXE that works with the SVideo and composite and doesn't require soldering nor RGB output. Otherwise, it's just for hardware hackers-- nothing that can hope to become a standard for the majority. In fact I use my Amiga with composite monitors although on that machine it does make a BIG difference if you use RGB output or composite.

Link to comment
Share on other sites

Given most monitors are at least color clock resolution, I would have to see it to believe it. And unless it works with those Commodore type dual composite/rgb type monitors, you would need to carry an extra monitor as well.

 

And about artifacting, most software using 320+ resolution assumes it exists, so it's not that useful to not have it.

 

Does using only palette entries from the grayscale (8 CTIA grayscales, 16 GTIA) section of the palette avoid artifacts? Obviously if you have the Y/C outputs, you could simply use only luma -including plugging luma into a composite monitor, but I was wondering more about the standard composite video/RF out. (I know some other machines had modes disabling the color carrier for higher resolution grayscale/monochrome still using a standard definition 15.7 kHz vsync video signal -like CGA)

 

The CTIA/GTIA palette is YUV based, isn't it? (so, technically speaking, Y'PbPr output might make more sense, though transcoding to RGB isn't much different other than the fact that newer SDTVs in the US support Y'PbPr but not RGB -the TMS9928 outputs natively in Y'PbPr iirc)

 

However, by that logic, grayscale images using a dedicated luma line should look no better in RGB (or Y'PbPr) than the native Y/C output, assuming the same monitor is used.

 

 

1084 isn't colour-clock resolution, it's well over double. It displays Amiga and VBXE resolutions just fine.

It's just a SDTV monitor (standard ~15 kHz Vsync), being analog there's no hard limit on horizontal resolution, color is limited by the carrier signal, but the only thing limiting horizontal resolution for luma is beam precision and phosphor dot pitch, which should indeed be far higher than 160 dots across. (even old TVs should have over 400 across, newer ones tend to be closer to 600-800 I believe, -obviosuly HDTVs and VGA/SVGA monitors are far higher; perhaps some really small/cheap old sets have lower, but I doubt even close to 160, probably few lower than 300)

 

Of course, the color signal resolution (for NTSC especially) has always been much lower than the actual broadcast picture, pure B/W broadcasts didn't have to deal with that, and still color broadcasts just have lower color resolution than the actual picture (and some artifacting/degridation from the combined chroma/luma signal) That's also why many lower budget films/TV shows done in tape (composite video signal) can look a good bit sharper/more detailed in B/W than color. (particularly noticeable in a series that started in B/W and transitioned to color -and especially visible on modern DVD releases using the original master tapes -or similar laserdisc or SVHS copies previously, even VHS should be somewhat noticeable -and additionally due to color degridation/artifacting in the VHS format itsself)

And MPEG type video encoding tends to have chroma at 1/2 the luma resolution anyway. (though that generally far exceeds the NTSC or even PAL color limits, for DVD at least, for 320x240 VCD, chroma resolution would correspond quite well to NTSC)

 

That's why it looks like crap because the software assumes artifacting and it doesn't occur (for the most part) on PAL. Also, when you adjust the 1084 monitors hsize/vsize, you are rescaling the image to another grid that most likely doesn't correspond to the exact number of RGBs on the physical screen so there's some distortion being added there even with RGB mode. Only LCDs with exact mapping of pixel coming in to pixel going out can you obtain a perfect image.

I disagree: with high precision beam and very fine dot pitch, the picture can indeed be sharper (or near the same) as a native resolution display on LCD/Plasma/OLED digital displays, as is the case with good VGA/SVGA monitors. (any physical advantage in pixel sharpness is tempered by the higher contrast and black level a CRT is capable of -less so for Plasma, but that's not really an issue int he context of computer monitors, and plasma has other disadvantages -namely pixel size, cost, and power consumption)

 

Of course, you can still display higher resolution than the native dot pitch and not require precise alignment, but the coarser the dot pitch the more difficult it is to display really sharp graphics. (there's also other factors, like dot pattern: ie square grid, staggered square dots, or a delta pattern -fine pitch delta pattern possibly being the best, though the difference is really minimal)

 

 

With RGB signal the whole concept of colour clocks becomes irrelevant. The signal is sent from the source straight to the screen without any modulation or YUV encoding.

Doesn't CTIA/GTIA use a native YUV derived palette (or digital representative thereof, or the similar, but distinct YCbCr)? The CRT monitors themselves use RGB natively for the display, but that's another issue. (and transcoding YUV/Y'PbPr/RGB really doesn't introduce perceptible loss)

Edited by kool kitty89
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...