Jump to content
IGNORED

TransKey-II in development


mytek

Recommended Posts

No, I have no clue as to where this should be - should be SOMEWHERE.

 

If I were looking for the TK-II, I would start on AtariAge, but I don't think there is a place for this kind of thing, here.

 

Too bad. It would be very cool to have all the hacks and enhancements - with schematics, code, and instructions, all in one place - just for the 8-bits.

 

DropBox?

 

Bob

Link to comment
Share on other sites

No, I have no clue as to where this should be - should be SOMEWHERE.

 

If I were looking for the TK-II, I would start on AtariAge, but I don't think there is a place for this kind of thing, here.

 

Too bad. It would be very cool to have all the hacks and enhancements - with schematics, code, and instructions, all in one place - just for the 8-bits.

 

DropBox?

 

Bob

 

I don't think the free version of DropBox allows for easy sharing of an entire directory, while still having a Read-Only status. I could be wrong about this (it wouldn't be the first time), but if I couldn't control who can modify and/or delete stuff, then this would be a no go.

 

Perhaps someone else reading these posts can chime in on where a good place to store the entire TK-II project for public consumption would be (and I'm not just talking about the PCB files, but the whole project, docs, images, and all). Bumzyman's suggestion of OSH Park for the PCB files is great, and most likely I will do that, but it would also be nice to have a central repository for everything as well.

 

-Michael

Link to comment
Share on other sites

 

I don't think the free version of DropBox allows for easy sharing of an entire directory, while still having a Read-Only status. I could be wrong about this (it wouldn't be the first time), but if I couldn't control who can modify and/or delete stuff, then this would be a no go.

 

Perhaps someone else reading these posts can chime in on where a good place to store the entire TK-II project for public consumption would be (and I'm not just talking about the PCB files, but the whole project, docs, images, and all). Bumzyman's suggestion of OSH Park for the PCB files is great, and most likely I will do that, but it would also be nice to have a central repository for everything as well.

 

-Michael

 

Github?

Link to comment
Share on other sites

Well I've been working on the mouse code (keyboard side is completed and working good), and it has been interesting to say the least. I'm trying to do it through polling, instead of the streaming method. Reason being, is that there is no certain way to know where you are in a given byte packet when letting the mouse stream the data. So if you get out of sync, it would not be pretty. Polling is cool, since I decide when and if I want a data packet, and nothing can get out of whack. Of course streaming is probably better for high resolution, but for what I am doing this is not at all required, in fact a low resolution is preferred.

 

Now for the interesting part. It is very strange to use a mouse that essentially works on a 960 character grid, which compared to the usual situation, is an extremely low amount of dots. So to go diagonally across the screen requires a series of up-right, down-left, (you get the idea) arrow key presses to emulate. So it looks a bit funny when watching the cursor traverse the screen. Good news is that thus far the diagonal runs are very fast, much faster than vertical or horizontal movement. This is due to the nature of POKEY's debounce routine, which when dealing with like characters, it needs to see a bit of a pause between them to really acknowledge them as separate key presses. However if sending two entirely different characters, no pause is required.

 

So although I do have a mouse pushing the cursor around the screen, it still needs a lot more work to get it to what I think would be acceptable behaviour. Also I need to integrate it with the keyboard side of things to make sure there will be no conflicts, and also implement a way to detect the absence of either device (mouse or keyboard), so that it'll work fine on a solo basis.

 

-Michael

Edited by mytekcontrols
  • Like 1
Link to comment
Share on other sites

Yay!!!

 

So, send a 'dummy' character between like characters?

 

How will the buttons be handled? Can they just send an unused key and let the OS figure it out?

 

Bob

 

Hi Bob,

 

I did go from using delay to sending a dummy character between "like" key presses, and this did speed things up a bit faster than the normal key repeat, but curiously still not as fast as the diagonal movement, which really seems odd to me considering that both situations are now in essence sending two keys. But at any rate it does seem usable. Now I just need to figure out why the mouse seems to have fallen asleep, because when I first move it slowly, nothing happens. And it kinda needs me to give it a kick by initially moving fast and then I can slow down when the cursor actually begins to move (once it's moving, it responds fine to slow movement). This is also very odd, because when not moving the mouse, nothing should be interfering or stealing cycles from mouse polling. I'll figure it out for sure, and it'll be one of those aha moments when I do.

 

Mouse Buttons: Left will send the RETURN key, which seems like the logical and most useful thing to do since you'll likely use the mouse to move to a particular item, and then pressing the left button (RETURN) will execute that item. The right button will send an unused (but mapped) key that yes the OS or program can detect and use for whatever it wants. This is the same as I have done for the LWIN, RWIN, and MENU keys on the keyboard. And the middle button, will probably just send a CONTROL variant of the right button code (since I have run out of unused keys on the matrix).

 

Scroll Wheel: This will simple be translated into UP-ARROW and DOWN-ARROW movement.

 

-Michael

Edited by mytekcontrols
  • Like 1
Link to comment
Share on other sites

 

I did go from using delay to sending a dummy character between "like" key presses, and this did speed things up a bit faster than the normal key repeat, but curiously still not as fast as the diagonal movement, which really seems odd to me considering that both situations are now in essence sending two keys.

 

I think I know why the diagonal still appears to be faster. It's double the movement for one thing, whereas using the dummy key in the vertical or horizontal direction is only one move since the dummy key adds nothing.

 

Also when I was observing the diagonal movement, something didn't look right about the angle of travel. The angle started becoming steeper, because the effective vertical vs horizontal resolution is not the same. And even making two moves horizontal and one move vertical doesn't quite address this, and just creates the opposite problem of the angle getting shallow (see image below of two moves horizontal and one move vertical).

 

Diagonal%20Move1.png

 

So it looks like I need a formula to compensate for this effect. Which brings me to my worse subject, Math. So could some math whiz out there make a suggestion, as in a formula to correct this problem? Obviously it doesn't need to be perfect, since you will tend to correct for this on your own as you move the mouse. But it would be nice to adjust for this somehow. Of course here is the tricky part; the formula will need to adjust for when you stop and start movement in a diagonal direction, essentially resetting for more horizontal movement initially, and then increasing the vertical as you go.

 

-Michael

Link to comment
Share on other sites

 

I think I know why the diagonal still appears to be faster. It's double the movement for one thing, whereas using the dummy key in the vertical or horizontal direction is only one move since the dummy key adds nothing.

 

Also when I was observing the diagonal movement, something didn't look right about the angle of travel. The angle started becoming steeper, because the effective vertical vs horizontal resolution is not the same. And even making two moves horizontal and one move vertical doesn't quite address this, and just creates the opposite problem of the angle getting shallow (see image below of two moves horizontal and one move vertical).

 

Diagonal%20Move1.png

 

So it looks like I need a formula to compensate for this effect. Which brings me to my worse subject, Math. So could some math whiz out there make a suggestion, as in a formula to correct this problem? Obviously it doesn't need to be perfect, since you will tend to correct for this on your own as you move the mouse. But it would be nice to adjust for this somehow. Of course here is the tricky part; the formula will need to adjust for when you stop and start movement in a diagonal direction, essentially resetting for more horizontal movement initially, and then increasing the vertical as you go.

 

-Michael

Here's some math, you're off by about 4 vertical, for 40 horizontal. 10% error. For something that you will have visual feedback for, this is not a big problem I would think. Just leave it. I refer you to the acronym, KISS. Keep It Simple, Stupid. :)

Link to comment
Share on other sites

How much input do you get from the mouse? On a granular level, you will always (almost always) move in a diagonal direction, even if it is just a couple of steps from being on the X or Y axis. It is very difficult to move exactly on axis, right?

 

You have a counter that tells you where you are in each 'cell', underflow moves you either DOWN or LEFT and overflow moves you UP or RIGHT? Then reset the counter to the middle of the cell.

 

I would think that the visual feedback you get from the cursor movement will correct for any skew in the X/Y coordinates.

 

The two most useful applications for the mouse (for me, anyway) are editing, where you are taking advantage of the live screen data, and menu navigation, where you 'hit' a series of drop-downs. In either case, the cursor movement needs to be somewhat accurate, but not perfect.

 

Bob

  • Like 1
Link to comment
Share on other sites

Here's some math, you're off by about 4 vertical, for 40 horizontal. 10% error. For something that you will have visual feedback for, this is not a big problem I would think. Just leave it. I refer you to the acronym, KISS. Keep It Simple, Stupid. :)

 

Yes after thinking about this overnight, I would have to agree with your KISS acronym. Thanks Joey.

 

How much input do you get from the mouse? On a granular level, you will always (almost always) move in a diagonal direction, even if it is just a couple of steps from being on the X or Y axis. It is very difficult to move exactly on axis, right?

 

You have a counter that tells you where you are in each 'cell', underflow moves you either DOWN or LEFT and overflow moves you UP or RIGHT? Then reset the counter to the middle of the cell.

 

I would think that the visual feedback you get from the cursor movement will correct for any skew in the X/Y coordinates.

 

The two most useful applications for the mouse (for me, anyway) are editing, where you are taking advantage of the live screen data, and menu navigation, where you 'hit' a series of drop-downs. In either case, the cursor movement needs to be somewhat accurate, but not perfect.

 

Bob

 

Lots of good questions. Basically I've come to the conclusion to do anything but single steps, as in character positions with the cursor for most of the normal mouse movement creates a problem of accurately getting to where you actually wish to be. However this is not to say that with a fast movement, that some acceleration can be achieved and be desirable by double stepping. But ultimately its got to revert back to single steps, otherwise you'll miss your target. So if I start seeing a large difference in newX and/or newY readings vs oldX and/or oldY, then I can add in an extra step, since these are essentially more like acceleration registers when handled this way.

 

"How much input do you get from the mouse?"

 

As by how much input, I'm assuming you are referring to how big a number is sent vs distance traveled. If I were streaming the mouse, some of this could be adjusted by a couple of registers it has for scaling and sample rate. When polling (as I am doing), then there is a resolution register that has 4 possible settings: 1 count/mm, 2 count/mm, 4 count/mm, 8 count/mm. Of course my polling isn't perfect, and is kind of dependent on what else is asking for attention in the main program loop. But with that said, even the 8 count/mm tends to work ok, since it would take a bit over an inch of travel to cause the 8-bit axis counters to overflow. So long as I can service the mouse before it travels an inch, the X &Y data stays intact. Of course if I were to sample that slow, it would be a pretty horrible mouse implementation. (Note: each time I request a data packet from the mouse, the axis counters get reset automatically)

 

"It is very difficult to move exactly on axis, right?"

 

If you keep to single steps, it is fairly easy to maintain a path up or down the Y axis, or left or right on the X axis. Diagonal is a bit less accurate, but not overly so. So in other words imagine that you are traveling horizontally with the mouse, then think of the height of a character on screen as being a window of multiple pixel resolution, so long as you are staying within that window while moving across the screen no up or down change in the cursor position will occur. This is the advantage to a low resolution. If you were to do the same on your Mac, Windows, or Linux machine, you would find it extremely difficult to maintain a single horizontal line of travel due to the higher resolution available (the window is essentially a pixel or two in size, with far more pixels than the Atari screen, hence much smaller as well).

 

"I would think that the visual feedback you get from the cursor movement will correct for any skew in the X/Y coordinates."

 

Yes I agree.

 

It is possible to look at other DOS mouse source (http://cutemouse.sourceforge.net/) for insight, or to see how it done?

 

Thanks for the link Fuji, I'll check it out :)

 

Here's a quote from another source talking about the idea of scaling the mouse movement...

 

http://wiki.osdev.org/Mouse_Input

When a user is trying to point at something on a screen, they will quickly move the mouse in the general direction of the target, and then slow down to accurately point at it. The deltaX/Y values from the mouse packets can be used directly, but doing that will force the user to move the mouse very far to get the cursor from one area of the screen to another.

A better answer may be to scale the mouse movement by additional multiples, based on how fast the mouse is moving. If the mouse is moving slowly, the scale factor can be 1 -- to allow the highest possible sensitivity. When the mouse is (or has been) moving fast, the scale factor could be 5 or 10, to allow the cursor to move across large distances on the screen quickly.

There are many ways to do such scaling, obviously. If you are coding the driver in assembler, one suggestion might be to use the BSR command to generate an approximate log base2 of deltaX plus deltaY, and use that as your scaling factor.

 

 

-Michael

Link to comment
Share on other sites

Houston we have Mouse lift off!

 

https://youtu.be/mUi1Vr1_Q1g

 

I got this mouse thing working pretty good. Ended up doing mouse acceleration utilizing a combination of the stock Control-Arrow keys (normal speed) and the XL/XE F1-F4 cursor movement keys for fast mode. Using a two key send with entirely different key codes really makes the cursor zip around the screen when you move the mouse faster. Of course this means that a non-XL/XE computer will not have this variable acceleration feature, unless it is running a modified OS. But at least the mouse will still work.

 

When you watch the video you'll see that I drop a couple of characters onscreen utilizing the mouse buttons (got all 3 buttons working), and I also implemented the scroll wheel to do single Up-Arrow and Down-Arrow key sends to POKEY when the scroll wheel is moved up or down.

 

BTW; I had to turn off the normal key click sound, it was driving me crazy :mad:

 

-Michael

Edited by mytekcontrols
  • Like 3
Link to comment
Share on other sites

Looks fantastic!

 

What else needs to be done? Is it ready to make boards?

 

Bob

 

After I tweak a few things with the mouse code, it needs to be integrated with the keyboard routines. If this goes well, then I'll have some boards made. My original concern was by only having keyboard interrupt capability, would the polled mouse routines work smoothly, and will there be any conflicts between the two. Keep in mind that only the low level keyboard stuff is handled by the interrupt routine,and I still have a lot of processing of keys in the main line code. So far it's looking good, and it'll be even better when I do the mouse tweaks I have in mind, which will allow a more flow thru aspect, thereby promoting a more shared experience between the two aspects and help eliminate any bottlenecks.

 

If I had to, I do have a few other interrupt resources on the PIC chip, but they all involve timers or counters, and are not as straight forward to use as the clock level one I am presently implementing for the keyboard.

 

As for boards, I already have the layout done and waiting to be made :sleep:

 

TransKey-II%20PCB.png

 

I decided to panelize it, so for every board made, you get two standard boards and one XEGS version. Although I was thinking that the XEGS version might also double as a solder-in version for the standard machines where there is limited room due to numerous other add-ins. Just be a matter of using a D-SUB 15 ribbon cabled connector, and soldering the wires at the opposite end to all the required signal connections on the Atari.

 

XEGS (or solder-in) Version: J1 and J2 = PS/2 mouse and keyboard connectors, with J3 being the XEGS's keyboard connector.

 

Standard Piggy-Back Version: J1 = mouse/keyboard header, J2 = console key header, and U2 is the POKEY piggy-back socket.

 

BTW Bob, having problems initializing the Microsoft roller ball mice you gave me. Tried 3 other mice including a USB one with an adapter, and they all work as they should. But something fishy about the Microsoft ones. They do work but certain aspects are either missing (middle mouse button), or the sampling/resolution is stuck with the wrong setup which causes some movement issues. I'll keep doing some research on this, and see if there is something different that needs to be done in the set-up, which the other mice apparently don't need. Ran into similar problems with the keyboard set-up routines as well, until I found some obscure reference that shed light on what was happening. At any rate, this wont delay the project, since other mice are working well, and I'll test with a few more after I make a trip over to the computer recycling place here in town.

 

-Michael

 

 

Edit: That right angle PCB D-SUB 15 connector needs to be modified, as in shave off the sides before use. Unfortunately the way the XEGS is made with the recessed keyboard port, means that a standard connector will not fit. Since shaving off the sides means no solder-in mounting tabs are left, I figure a drop or two of JB-Weld epoxy might be in order to secure the connector to the PCB (don't want to rely solely on the solder pins to do that).

Edited by mytekcontrols
  • Like 2
Link to comment
Share on other sites

Hi Bob,

 

Yep the schematics are still current. However if there were to be any changes, those links would automatically give you the latest update, since they derive from my public folder on DropBox.

 

Yeah that's right, the 1200XL was done the same as the XEGS, with the MUX chips integrated with the keyboard. Hmmm... makes me wonder if there is someway to make a piggy-back 1200XL keyboard adapter with a ribbon header on it? That way you could just make up a D-SUB 15 to DIL ribbon header connection cable, and utilize the TransKey-II-XEGS version with minimal soldering (still need to break out the console key connections separately, but that could also happen on the piggy-back board).

 

-Michael

 

 

Edit: Forgot to answer your question about finding PS/2 connectors. Yes I found some very nice PCB ones even sporting the proper colors (purple for keyboard, green for the mouse). Pretty cheap too, straight from China, but they appear to be good quality. As for the Standard Transkey-II, I also found a cheap source for these (see below) that I combine into a single DIL connector (same one it comes with). And for those guys that like to PC case their Atari, it already comes with a full-height bracket.

 

PLATE6F.Main.jpg

Edited by mytekcontrols
Link to comment
Share on other sites

I was thinking like this on the 1200XL. The original k/b cable plugs into the right-angle connector (not all the pins are there, yes) and the flat cable goes to the TRANSKEY- II.

 

Bob

 

 

attachicon.gifDSC01490.JPG

 

 

 

Yep that could be made to work, and just base it on the XEGS version. But I also read your email and responded, that I think I will simply mirror the POKEY piggy-back version top to bottom, which will then allow it to work just fine with your XL14, and be better for the stereo board as well. After your email, I really started scrutinizing motherboard pictures, including one with a stereo board installed, and said "what the heck was I thinking?". Sometimes my brain gets things reversed for no particular reason. Anyway no problem in making the change at this point, and better to do it now then after I have some boards made. And that is also the point of posting stuff here as I go, so that problems can get addressed early on.

 

Of course with all the multitude of add-in boards and all the different motherboard designs, there will not be one size that fits all. Funny thing about this is that of all the 8-bit computers that were popular in the day, only Atari managed to create in essence 8 different layouts for essentially the same computer. Who does that?

 

Stayed tuned for new version PCB to appear in the next couple of days.

 

-Michael

  • Like 2
Link to comment
Share on other sites

 

Mike I am glad to see you building things for the Atari 8-bit. You already know I have 3 of your Transkeys since 1990's and have enjoyed them for years. I started Building the KRH & KRH-II because There were no Transkeys that could be purchased any where. Just so you know I have the KRH-II Finished and PC Boards in hand and will be selling them in the next 30 to 45 days as soon as I am finished testing them. The KRH-II is designed to work with the Stereo Pokey Lotharek sells as well as the Candle -o- Sin Atari 8-bit upgrade. But Mike please reserve 3 of your new transkey-ii so I can add them to my collection.

 

Does your new Transkey-II include USB Keyboard Support. I ask this because I would very much like to use wireless keyboards with my Atari. Also is your new transkey-ii going to work with all the new hardware upgrades that have been designed since 2000?

Here is a snap shot of our new KRH-II PCB.

post-9681-0-30580000-1438312151_thumb.jpg

 

 

Take care and looking forward to the transkey-ii when it is ready.

 

Take Care!

Stephen J. Carden

http://www.realdos.net

 

 

 

 

Edited by Stephen J. Carden
  • Like 2
Link to comment
Share on other sites

 

 

Mike I am glad to see you building things for the Atari 8-bit. You already know I have 3 of your Transkeys since 1990's and have enjoyed them for years. I started Building the KRH & KRH-II because There were no Transkeys that could be purchased any where. Just so you know I have the KRH-II Finished and PC Boards in hand and will be selling them in the next 30 to 45 days as soon as I am finished testing them. The KRH-II is designed to work with the Stereo Pokey Lotharek sells as well as the Candle -o- Sin Atari 8-bit upgrade. But Mike please reserve 3 of your new transkey-ii so I can add them to my collection.

 

Does your new Transkey-II include USB Keyboard Support. I ask this because I would very much like to use wireless keyboards with my Atari. Also is your new transkey-ii going to work with all the new hardware upgrades that have been designed since 2000?

 

Take care and looking forward to the transkey-ii when it is ready.

 

Take Care!

Stephen J. Carden

http://www.realdos.net

 

 

 

 

Hi Steven good to hear from you :)

 

No on the USB support. That'll have to wait for some future revision, if there ever will be one. I thought I could do it with some of the USB variants of the PIC chips I have worked with, but discovered they are only good as Slaves and not suitable as a Host, which is what is needed. Then when I started looking into what it would take to set-up a Host, it quickly gave me a major headache :o

 

"Also is your new transkey-ii going to work with all the new hardware upgrades that have been designed since 2000?"

 

Well here's what I did concerning that. After talking with Mr. Woolley, and looking through images of various motherboards with and without upgrades, I made a revision on my PCB layout (see Post 40). I can't say that it'll work with everything right out of the box, but at least I did try to make it more workable with some of the obvious upgrades that are in the vicinity of POKEY. And if the piggy-back version just wont work, then there is always the solder-in approach which I figure that the XEGS version of TransKey-II might be suitable for (you could place this anywhere, even outside of the computer by simply installing a D-SUB 15 keyboard connector like on an XEGS.

 

The cool thing was when I re-worked the PCB layout today, I was able to make the piggy-back version even smaller on the 2nd go around.

 

"Mike please reserve 3 of your new transkey-ii so I can add them to my collection."

 

Well I don't intend to produce these myself, other then a prototype run. Bob and I were chatting about the possibility of an established manufacturer/vender producing and selling these. Keep in mind that the whole project will go open source upon completion of the R&D, so in reality anyone could do this, since the firmware and PCB files will be made available as part of the project release (although the design and prototype board run is being done through ExpressPCB, I will also include gerbers along with the express files as part of the release). And last but not least, it is highly probable that the gerber files will be uploaded to OSH Park as well (still looking into this).

 

-Michael

Link to comment
Share on other sites

I finished the tweaks on the PCB's, and bit the bullet and placed a prototype order for 4 of them today at the tune of $180 (since they are panelized, that equals 12 individual boards when separated at $15 each). This will be enough for my uses and several to Bob for helping me get this project going, and I'll hang on to a couple for any seriously interested parties that are contemplating a production run and wish to play around with it first.

 

This is the first time I've tried panelizing something through ExpressPCB, so I have my fingers crossed that all will go well. The vertical board to the left is the TransKey-II-XEGS, which will also double as the solder-in model, utilizing a D-SUB 15 connector best installed into the case, for external plug-in connection similar to what is done on the XEGS computer. The two other boards to the right are the standard POKEY Piggy-Back version (TransKey-II).

 

PCB with Ground Plane ON

TransKey-II%20PCB.png

 

PCB with Ground Plane OFF

TransKey-II%20PCB%20(GndPlane%20OFF).png

 

-Michael

Link to comment
Share on other sites

 

Just so you know I have the KRH-II Finished and PC Boards in hand and will be selling them in the next 30 to 45 days as soon as I am finished testing them. The KRH-II is designed to work with the Stereo Pokey Lotharek sells as well as the Candle -o- Sin Atari 8-bit upgrade.

 

 

Hi Stephen, I was checking this out, and it appears to be extremely compact which I guess was the goal on this newest version. A very nicely layed out little board :thumbsup:

 

However just curious about one thing. Are my eyes playing tricks on me, or did the holes for the PS/2 connector mounting tabs not get drilled? If so, curious as to why.

 

Looking good!

 

-Michael

Edited by mytekcontrols
Link to comment
Share on other sites

 

Hi Stephen, I was checking this out, and it appears to be extremely compact which I guess was the goal on this newest version. A very nicely layed out little board :thumbsup:

 

However just curious about one thing. Are my eyes playing tricks on me, or did the holes for the PS/2 connector mounting tabs not get drilled? If so, curious as to why.

 

Looking good!

 

-Michael

Hi Mike!

Because we are going to offer more than one way to install the KRH-II we opted to drill the PS2 Mounts our self. If we had those holes drilled I would be locked into one way and only one way to install.

I am glad you like our little PCB. Now I have a ton of surface parts to hand solder. Yes I hand solder Surface Mount parts. Down side to me soldering the surface mount parts is I can only build 5 or 6 KRH-II in a day.

 

Stephen J. Carden

Link to comment
Share on other sites

Hi Mike!

Because we are going to offer more than one way to install the KRH-II we opted to drill the PS2 Mounts our self. If we had those holes drilled I would be locked into one way and only one way to install.

I am glad you like our little PCB. Now I have a ton of surface parts to hand solder. Yes I hand solder Surface Mount parts. Down side to me soldering the surface mount parts is I can only build 5 or 6 KRH-II in a day.

 

Stephen J. Carden

 

Hi Stephen,

 

Thanks for taking the time to explain this. Check your email when you get the chance, I left you a couple of replies.

 

-Michael

 

Edit: Sometimes my email gets stuck in someone's junk mail, so look for mytekcontrols -at- gmail.com (replace -at- with "@").

Edited by mytekcontrols
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...