Jump to content
IGNORED

More "TI-99/4A Computers TI-99/4A Development"...ish channals/forums/treads...


oddemann

Recommended Posts

I see that many talk about programming and it looks like it is mostly a thing people do alone and questions related to a specific lango is spread all over. What about making a new "TI-99/4A Computers TI-99/4A Development" forum where it is narrowed down to one specific thing.

"TI-99/4A - Programming in Basic!"
"TI-99/4A - Programming in Extended Basic!"        (I would love this one and to keep learning about Ex. B.)

.and

.so

.on

What about making a dedicated forum tread for Programming in...
- TI Basic!
- TI Ex Basic!
- Logo!
- Fortran
- Pascal
- Assembler
- GPL? or something
- RXB!
- And other programming langos!

Why... To collect specific stuff for Basic (and other programming langoes) in one place with separation of different things within Basic. It would be a "living book" about new ways of programming and where new ideas could be talked about. Like a tread about RND and best ways to use it. And how to practically put it in a program. Also people could ask about a specific subject and then it will be searchable within the "under forum". Then there is a specific place for Basic where everything is ONLY about Basic. And so for every other langos anyone wants to put out there.

Even if Basic gets it's own tread, it is hard to find something within x pages of stuff about Basic. Maybe you have to look at 20 pages and countless posts to find stuff about "put in that ever your looking for!". It gets old fast!

Then in the Basic tread there will be a tread about...
- How to use Data to save space. (thinking about how pixelpedant way to saved space, in his last game - Great idea. And with its own tread this could maybe be expanded upon.)
- How to make the optimal joystick routine.
- Optimal way of "painting" the screen, save time and space.
- Tricks and tips!

Also I think it would make it easier to start to learn an new programming lango! At least one could ask question within that specific lango. Also the masters of a topic would know how to push forward development of langos/games/programs. (from questions)

Over time the separate treads would be a "How to" for all beginners. Like a "playing around" and start testing one and one of the topics. You will educate yourself within your chosen programming lango. Also stuff could be formatted so that more programmers can learn and start to make programmes for the TI. There is one tread about optical illusion, with its own tread in its own lango this could maybe make it easier for people to test, try and make there own stuff to inspire others again. (easier to find to in a learning setting)

I asked a question about making an animation of a running man (a long time ago, I learned so much from that question)... That tread is WAY down in "TI-99/4A Computers" or "TI-99/4A Computers TI-99/4A Development". I wish it was easy to get back to and then maybe use it or just play around with it. But as it is now... hard to find stuff. What was the name of that tread? And then there was this other tread about a trick in Ex. Basic... Don't remember the name or anything else... With one place for Basic, Ex Basic and others. It would be easier to find stuff and it is ONLY about one subject that is fragmented into all related things.

Now - "TI-99/4A Computers" or "TI-99/4A Computers TI-99/4A Development" contains all and everything!

I think that sorting things in this way it would be easier to help people and grow there potential to make programs. Or at least make it easier to find something your looking for.

This is what I think... what do you think?

Edited by oddemann
Not done...
  • Like 2
Link to comment
Share on other sites

I have seen other forums try this, and IMO it does not help, and I actually miss things I would have otherwise read.  The 99/4A community here does not have enough people doing things in all those areas to justify separate subforums, again IMO.

 

Also, having the subforums would not help with the biggest problem of any forum, which is collecting and distilling the relevant information from various discussions into usable information.  The current solutions for gathering usable information in one place are a Wiki or a book.

 

However, a Wiki suffers if people do not put forth the effort to contribute distilled and accurate information, and a book is generally a large effort of one or two people (usually).

 

In a hobbyist community, without any financial benefit or reward, people tend to prefer to spend their limited time messing with things they find interesting, rather than collecting, organizing, or writing documentation for the benefit of others.  Everyone wants the information resource, but few are willing to give up the time and effort to make it happen.

  • Like 5
Link to comment
Share on other sites

I just do a search on a topic and try my best that I used the right term and get a hit and then start reading from the top. Of course it's going to take time, but this way I can find most stuff. 

I'll email Lee, Brian or someone that can deal with me if I'm really lost.

 

I have an Auto service (car) database that I wrote because I wanted to put the service manual in it and look things up and it's really nice to use. But again, it's because theres a search routine, like here.

 

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

Good thread topics and tags help immensely.  Topics like "What I discovered today..." on a thread with a breakdown of some assembly tricks are unhelpful.  Also, avoiding thread derailing and hijacking helps, and no one should be insulted when a thread owner tells people to move their tangential discussion to another thread, nor should they be complete pricks and thumb their nose at the request (you know who you are.)  To that end, I have the ability to move posts between threads, into new threads, and move threads between subforums as needed or requested.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

16 hours ago, matthew180 said:

I have seen other forums try this, and IMO it does not help, and I actually miss things I would have otherwise read.  The 99/4A community here does not have enough people doing things in all those areas to justify separate subforums, again IMO.

I can see that point, but... we have split this forum into 3 at this point. And it works! Sometimes I do not go to "Development", I just stay at the first level. So it works. BUT, I also see that I might miss stuff if I do NOT go to "Development". But I like that split, as I know where to ask and find stuff. With that split I know that if I ask in one place I might get answer from just the right person.

14 hours ago, GDMike said:

I just do a search on a topic and try my best that I used the right term and get a hit and then start reading from the top. Of course it's going to take time, but this way I can find most stuff.

I have tried that and at times is is mostly a miss, I get hits, but they are fare from what I want. BUT If I know what to specificity look for, it is easier. But... usually I am looking for something I know exist, BUT I do not know the "name" of it. And most of the time then, searching is a miss. I then end up asking or making my own tread about stuff. And then I run the risk of getting... "You need to read TI-99/4A FAQ" and sometimes that works. And sometimes I just give up. as the FAQ gives me an overview. But luckily, often someone takes the time to give me info, that I can use and understand. But I am making more treads and more stuff to search, for the next guy. And IF I made a good title on my tread, it might be of help.

13 hours ago, OLD CS1 said:

Good thread topics and tags help immensely.  Topics like "What I discovered today..." on a thread with a breakdown of some assembly tricks are unhelpful.  Also, avoiding thread derailing and hijacking helps, and no one should be insulted when a thread owner tells people to move their tangential discussion to another thread, nor should they be complete pricks and thumb their nose at the request (you know who you are.)  To that end, I have the ability to move posts between threads, into new threads, and move threads between subforums as needed or requested.

And at this point I am bad, i am NOT good at making a good tread title, do not think about using tags or in other way make it smart for the future. Is there a "This is what you need to think about in a title, topic and tag with!"? At this point in time I am adding to the chaos 😛

I see your points, but still IMO, I think that Ex Basic should get its own tread as it can be compiled and made into something usable on the TI. And that there are many that still use Ex Basic. Example... I was playing around with "
Nerm of Bemer" the version I was looking at, did not have joystick support. Then in a tread about Ex Basic I could search for "how to joystick" and do the replacement my self as learning. On the other hand I did search then for "Nerm of Bemer" and found it had been compiled and with joystick setup. Also I think that some of the old games can be "modernized" and made better if one know what and where to fix stuff. And I think a separate forum about Ex Basic, would over time help me get better with Ex Basic. I can see that I have improved, since I found my own tread about "Nerm of Bemer" and program listings. I could debug them fast and I see that I understand much more now, then back in 2019. So... I can learn this way too.

BUT... seeing the skill of some of the people here, I know I would benefit from a forum about ONLY Ex Basic. Over time I would learn more and also the next guy will also benefit from it, I think.

  • Like 1
Link to comment
Share on other sites

1 hour ago, oddemann said:

Is there a "This is what you need to think about in a title, topic and tag with!"? At this point in time I am adding to the chaos 😛

I am going to sound like a jerk, but basic common sense and writing skills would be useful.  Now, being a jerk is out of the way, really, just distill your post to the simple ideas.  You put together a pretty comprehensive and granular list of topic types, so those will make good tags.  The title is a short, one-sentence summary of the problem, question, or helpful tidbit.  What is it you cannot do?  What is it that you ultimate did?  What is it you want to ask or tell someone?  Easy peasy.

  • Like 2
Link to comment
Share on other sites

Personally, I feel like subdivision of forums is only desirable to the extent that it separates out discussion among different audiences holding different interests. 

 

And TI BASIC (for example) is of at least some interest to essentially all TI-99 development enthusiasts.  Since it's pretty much the main function of the operating system of the TI-99.  So it wouldn't make much sense to separate out TI BASIC discussion into its own development forum, to me.  TI BASIC enthusiasts and TI Extended BASIC enthusiasts and GPL/Forth/Pascal/Logo/Assembly enthusiasts are not really different audiences, at least at this point. 

  • Like 1
Link to comment
Share on other sites

Yes i'm aware i often forget to use tags in my topics, i am guilty of that. But i do try to put as much thought into my content as my aging ADHD compromised brain will allow.

I find the current layout just fine.

General issues and topics in the main forum, and a dedicated sub to ask about and discuss development topics.

Its kind of nice that Tutor et al has a sub too, but i never minded seeing those topics creeping into the main TI forum.

I think if we sub-divided the issues / topics here any further, it would be rather counter productive.

Edited by jrhodes
  • Like 5
Link to comment
Share on other sites

  • 3 months later...

I like development as a single category.

Here is why.  I would have Never gone out of my way to see anything related to RXB or Forth etc.  As I use XB and Compiled XB 99.9% of the time.

 

However, "unrelated" to a language are techniques.  That is, no matter what you use to create it, it is the method or tricks used to achieve the outcome.

 

I have been here a LONG time.  I have gotten a TON of help and support here.

 

I will ask general questions when it is called for or targeted questions when needed.  That is, a GEM or XB256 question will include at senior falcon, where if you want to know how to find what character is at row 7 column 3, it is a general question.

With that Question, you will get a Forth answer, an XB answer an RXB answer and maybe a GEM answer as well.  Unless you add...  In RXB or using Forth etc.

 

I will read the answers to these as I may want to do this some other way than I do it now.

CALL GCHAR is painfully slow...  Can we do a VREAD?  I don't know, but this general question will most likely suggest a few ways to do it and maybe even timed analysis on different methods.

 

I am a huge fan of video demos also.  If I can see it, I can remember it.

  • Like 1
Link to comment
Share on other sites

2 hours ago, 1980gamer said:

I like development as a single category.

Here is why.  I would have Never gone out of my way to see anything related to RXB or Forth etc.  As I use XB and Compiled XB 99.9% of the time.

 

However, "unrelated" to a language are techniques.  That is, no matter what you use to create it, it is the method or tricks used to achieve the outcome.

 

I have been here a LONG time.  I have gotten a TON of help and support here.

 

I will ask general questions when it is called for or targeted questions when needed.  That is, a GEM or XB256 question will include at senior falcon, where if you want to know how to find what character is at row 7 column 3, it is a general question.

With that Question, you will get a Forth answer, an XB answer an RXB answer and maybe a GEM answer as well.  Unless you add...  In RXB or using Forth etc.

 

I will read the answers to these as I may want to do this some other way than I do it now.

CALL GCHAR is painfully slow...  Can we do a VREAD?  I don't know, but this general question will most likely suggest a few ways to do it and maybe even timed analysis on different methods.

 

I am a huge fan of video demos also.  If I can see it, I can remember it.

LOL well I have been trying to speed up CALL GCHAR for over 2 months now.

Yesterday I finally got it faster by 3 seconds but sad news that was a test in a 10,000 loop test between XB 1.10 and RXB 2023.

All attempts to make it assembly getting a single character off screen never was faster or even as fast as the original XB 1.10 version.

So the result is only slightly faster by moving some of the GPL commands around, Assembly just could not speed it up.

I should mention GPL commands are just so efficient it would be hard to make them any better or faster.

I got a speed increase in CALL GCHAR by moving the save and restore values before and after the CALL GCHAR main loop.

1 ! XB TEST
100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL GCHAR(24,7,X)
141 CALL GCHAR(24,8,Y)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

! RXB TEST
100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL GCHAR(24,7,X,24,8,Y)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

So the above for XB took 7 minutes 13 seconds and RXB 2023 took 6 minutes 20 seconds.

Not much of an improvement but finally a improvement.

  • Like 2
Link to comment
Share on other sites

Just now, RXB said:

LOL well I have been trying to speed up CALL GCHAR for over 2 months now.

Yesterday I finally got it faster by 3 seconds but sad news that was a test in a 10,000 loop test between XB 1.10 and RXB 2023.

All attempts to make it assembly getting a single character off screen never was faster or even as fast as the original XB 1.10 version.

So the result is only slightly faster by moving some of the GPL commands around, Assembly just could not speed it up.

I should mention GPL commands are just so efficient it would be hard to make them any better or faster.

I got a speed increase in CALL GCHAR by moving the save and restore values before and after the CALL GCHAR main loop.

1 ! XB TEST
100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL GCHAR(24,7,X)
141 CALL GCHAR(24,8,Y)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

! RXB TEST
100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL GCHAR(24,7,X,24,8,Y)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

So the above for XB took 7 minutes 13 seconds and RXB 2023 took 6 minutes 20 seconds.

Not much of an improvement but finally a improvement.

I found the same thing when I was testing compiled XB performance for my game project. GCHAR calls just killed it, and the XB256 equiv. did little to speed it up.

  • Like 2
Link to comment
Share on other sites

3 minutes ago, retrodroid said:

I found the same thing when I was testing compiled XB performance for my game project. GCHAR calls just killed it, and the XB256 equiv. did little to speed it up.

This is something we may have to live with :( 

  • Like 2
Link to comment
Share on other sites

1 hour ago, RXB said:

LOL well I have been trying to speed up CALL GCHAR for over 2 months now.

Yesterday I finally got it faster by 3 seconds but sad news that was a test in a 10,000 loop test between XB 1.10 and RXB 2023.

All attempts to make it assembly getting a single character off screen never was faster or even as fast as the original XB 1.10 version.

So the result is only slightly faster by moving some of the GPL commands around, Assembly just could not speed it up.

I should mention GPL commands are just so efficient it would be hard to make them any better or faster.

I got a speed increase in CALL GCHAR by moving the save and restore values before and after the CALL GCHAR main loop.

1 ! XB TEST
100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL GCHAR(24,7,X)
141 CALL GCHAR(24,8,Y)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

! RXB TEST
100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL GCHAR(24,7,X,24,8,Y)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

So the above for XB took 7 minutes 13 seconds and RXB 2023 took 6 minutes 20 seconds.

Not much of an improvement but finally a improvement.

What is sucking up the time on this one Rich?

 

Link to comment
Share on other sites

1 hour ago, TheBF said:

What is sucking up the time on this one Rich?

 

Tons different approaches to fetch one character off screen and send it back to XB.

See in a nut shell the problem is VDP entirely in XB.

 

Your XB program lines are in VDP using the Crunch Buffer for each program line as it executes.

Your XB variables are in VDP using the Crunch Buffer for each variable.

Your XB character on screen to fetch by CALL GCHAR is in VDP.

Lastly even though Numeric Variables are in RAM at upper 24K before they are put there, they are processed in VDP RAM!

 

Honestly the problem is XB and TI Basic are designed to be VDP based and that is the problem.

 

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

See in a nut shell the problem is VDP entirely in XB.

Your XB program lines are in VDP using the Crunch Buffer for each program line as it executes. Nope. You can look at the crunch buffer at v0820 and the program lines are not read to there when a program runs.

Your XB variables are in VDP using the Crunch Buffer for each variable. Nope. Variables do not go to the crunch buffer when a program runs.  Don't take my word for this; check it with a debugger.

Your XB character on screen to fetch by CALL GCHAR is in VDP. Finally a correct statement.

Lastly even though Numeric Variables are in RAM at upper 24K before they are put there, they are processed in VDP RAM! I see no evidence of this when running a test program.

Honestly the problem is XB and TI Basic are designed to be VDP based and that is the problem.

 

Here are two test programs:

10 FOR ROW=1 TO 24::FOR COL=1 TO 32::CALL GCHAR(ROW,COL,CH)::PRINT CH;::NEXT COL::NEXT ROW

10 X=RND*123456789::PRINT X::GOTO 10  Look at the crunch buffer at v0820 and you will see no activity. If you look in ram at >FF00, you will see 7-8 bytes constantly being updated at >FFC3.

 

VDP is not a performance enhancer, but the main reason why no significant (if any) speedup is possible is because GPL XB routines are used to retrieve the row and the column and the address of the variable. Once those are found then retrieving the value from VDP is trivial and takes almost no time, whether in GPL or assembly. I found this when developing the assembly versions of HCHAR and VCHAR for XB 2.9 G.E.M. and later Rich found the same when developing those for RXB. Once the row, column, character and # repeats are known, then assembly can take over and put the characters very quickly on the screen, but for one character there is virtually no difference, and of course, GCHAR only retrieves 1 character at a time.

 

GPL uses a lot of instructions to do what it does. For example:

DST @>836E,>06F8        takes 30 assembly instructions

DST @>8324,>@>836E  takes 48 assembly instructions

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, retrodroid said:

I found the same thing when I was testing compiled XB performance for my game project. GCHAR calls just killed it, and the XB256 equiv. did little to speed it up.

I just tested this program in XB and compiled:
5 INPUT L
10 FOR N=1 TO L :: CALL GCHAR(1,1,G):: NEXT N

To loop 1000 times in XB took 23 seconds. To loop 30000 times compiled took 15 seconds. That works out to 46x faster.

 

 

Link to comment
Share on other sites

40 minutes ago, senior_falcon said:

I just tested this program in XB and compiled:
5 INPUT L
10 FOR N=1 TO L :: CALL GCHAR(1,1,G):: NEXT N

To loop 1000 times in XB took 23 seconds. To loop 30000 times compiled took 15 seconds. That works out to 46x faster.

 

 

I meant compiled XB CALL GCHAR vs compiled XB256 CALL LINK() were basically the same, timing wise.

Compiled is faster than interpreted, of course.

  • Like 1
Link to comment
Share on other sites

13 hours ago, 1980gamer said:

That is, a GEM or XB256 question will include at senior falcon, where if you want to know how to find what character is at row 7 column 3, it is a general question.

With that Question, you will get a Forth answer, an XB answer an RXB answer and maybe a GEM answer as well.  Unless you add...  In RXB or using Forth etc.

It's a bit of an unwritten rule in this forum that if you ask anything about any specific language, you should expect some answers for that language PLUS at least one answer referring to RXB and/or GPL ;).

  • Like 4
Link to comment
Share on other sites

4 hours ago, senior_falcon said:

See in a nut shell the problem is VDP entirely in XB.

Your XB program lines are in VDP using the Crunch Buffer for each program line as it executes. Nope. You can look at the crunch buffer at v0820 and the program lines are not read to there when a program runs.

Your XB variables are in VDP using the Crunch Buffer for each variable. Nope. Variables do not go to the crunch buffer when a program runs.  Don't take my word for this; check it with a debugger.

Your XB character on screen to fetch by CALL GCHAR is in VDP. Finally a correct statement.

Lastly even though Numeric Variables are in RAM at upper 24K before they are put there, they are processed in VDP RAM! I see no evidence of this when running a test program.

Honestly the problem is XB and TI Basic are designed to be VDP based and that is the problem.

 

Here are two test programs:

10 FOR ROW=1 TO 24::FOR COL=1 TO 32::CALL GCHAR(ROW,COL,CH)::PRINT CH;::NEXT COL::NEXT ROW

10 X=RND*123456789::PRINT X::GOTO 10  Look at the crunch buffer at v0820 and you will see no activity. If you look in ram at >FF00, you will see 7-8 bytes constantly being updated at >FFC3.

 

VDP is not a performance enhancer, but the main reason why no significant (if any) speedup is possible is because GPL XB routines are used to retrieve the row and the column and the address of the variable. Once those are found then retrieving the value from VDP is trivial and takes almost no time, whether in GPL or assembly. I found this when developing the assembly versions of HCHAR and VCHAR for XB 2.9 G.E.M. and later Rich found the same when developing those for RXB. Once the row, column, character and # repeats are known, then assembly can take over and put the characters very quickly on the screen, but for one character there is virtually no difference, and of course, GCHAR only retrieves 1 character at a time.

 

GPL uses a lot of instructions to do what it does. For example:

DST @>836E,>06F8        takes 30 assembly instructions

DST @>8324,>@>836E  takes 48 assembly instructions

 

LOL could you run your test with no 32K?

(see you seem to fixate on 32K being there and XB never assumes it is there, it is OPTIONAL! I assume no 32K)

See XB detects the 32K and if there moves your programs to upper 24K

So if you remove the 32K and run from only VDP like Console try your test again please.

Do not take my word for it just try it without a 32K please.

Link to comment
Share on other sites

1 hour ago, TheMole said:

It's a bit of an unwritten rule in this forum that if you ask anything about any specific language, you should expect some answers for that language PLUS at least one answer referring to RXB and/or GPL ;).

Yea but like the above post sometimes everyone missed all the factors involved and fixate on own solutions.

I have to remain backwards compatible with Console only, but like XB  I can work with the 32K or SAMS or other devices.

The main thing just my Cart alone can do much with no other added devices.

Doing assembly speeds from Console only is my main goal.

  • Like 1
Link to comment
Share on other sites

6 hours ago, RXB said:

LOL could you run your test with no 32K?

(see you seem to fixate on 32K being there and XB never assumes it is there, it is OPTIONAL! I assume no 32K)

See XB detects the 32K and if there moves your programs to upper 24K

So if you remove the 32K and run from only VDP like Console try your test again please.

Do not take my word for it just try it without a 32K please.

Crunch buffer not used when running without expansion.

The bottom line is this:

1 - If VDP is the main reason XB is slow, with GPL only playing a minor role, then it will be virtually impossible to see any significant speed increase on an unexpanded system, and you are wasting your time trying to achieve that.

2 - If GPL is the main reason XB is slow, with VDP only playing a minor role, then less GPL means a faster XB, and of course, the ultimate would be XB written totally in assembly.

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, senior_falcon said:

Crunch buffer not used when running without expansion.

The bottom line is this:

1 - If VDP is the main reason XB is slow, with GPL only playing a minor role, then it will be virtually impossible to see any significant speed increase on an unexpanded system, and you are wasting your time trying to achieve that.

2 - If GPL is the main reason XB is slow, with VDP only playing a minor role, then less GPL means a faster XB, and of course, the ultimate would be XB written totally in assembly.

 

1. LOL so you think the XB ROMs provide no speed increase, despite everyone knows XB is faster as it has 12K more ROM?

2. Oh so you are going to make more Assembly for XB without 32K?

    I thought that is what I was doing by adding more ROMs and running as much out of Scratch Pad as possible.

 

Can you explain why this assembly runs at same speed on a Console with no 32K or with 32K?

Many of these are Assembly in ROM 3 so they work with console only or with 32K.

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...