Jump to content

What's the state of play with serial port support?


BruceMcF
 Share

Recommended Posts

NMI is reserved for PS/2. Technically you could snag it. Basically there are 2 6522s. The first one handles the PS/2 ports, joysticks, and the IEC bus. This VIA has its IRQ wired to NMI because we found that PS/2 was not working on all keyboards due to timing issues largely caused by IRQ handling delays. By moving it to NMI that eliminated audio, video, and other events from the IRQ and allows the KERNAL to assume that the only NMI events are keyboard or mouse related. If you enable a TIMER in VIA 1 it could be used as a watchdog. You’d just have to hook into the NMI loop.

Are you guys opposed to an SPI UART?


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

9 minutes ago, Lorin Millsap said:

NMI is reserved for PS/2. Technically you could snag it. Basically there are 2 6522s. The first one handles the PS/2 ports, joysticks, and the IEC bus. This VIA has its IRQ wired to NMI because we found that PS/2 was not working on all keyboards due to timing issues largely caused by IRQ handling delays. By moving it to NMI that eliminated audio, video, and other events from the IRQ and allows the KERNAL to assume that the only NMI events are keyboard or mouse related. If you enable a TIMER in VIA 1 it could be used as a watchdog. You’d just have to hook into the NMI loop.

Are you guys opposed to an SPI UART?


Sent from my iPhone using Tapatalk

Now you don't tell me that if you move the mouse while loading a file breaks the IEC bus (as this is big-banged and allergic to NMI)?

I'm not opposed to SPI, or SPI UART, in fact I think an SPI interface with potentially multiple devices on it is a nice thing - given that SPI is not bit-banged but using a real shift register. I've done USB-over-SPI on the Commodore PET userport using the VIA shift register, and can use a USB mouse on the PET just fine. But it required a) VIA shift out via SR, and b) a 74 series TTL serial-to-parallel shift register to shift in the data at the same time as SPI does. And it VIA can only handle SPI mode 3 "out of the box". See my solution here: http://www.6502.org/users/andre/csa/spi/index.html

Edit: the userport USB is here: http://www.6502.org/users/andre/cbmhw/cbmusb/index.html

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

In fact _my_ dream computer nowadays would just have a number of SPI-based module ports, and no parallel bus connector anymore. You could plug in SPI modules for serial, USB, memory, Ethernet, whatever you dream of.

And btw run your main computer on any fast speed as you like, as there is no external bus to take care of.

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

  • Super Administrators
3 hours ago, Andre said:

Absolutely agree. A couple of cycles is ok, but if it gets more, the driver should back up and e.g. enable interrupt, if only to be able to break out of the wait loop and not maybe hang indefinitely. (does X16 have an NMI key?).

 

My experience has been that with a single tasking system and a decent buffer, polling the serial port uses fewer cycles and is more reliable than interrupt driven I/O. And it's certainly less code. But I don't see the harm in designing the implementation so that it can be polled or interrupt driven...

What I don't want to see is an interrupt-only system, since I want to retain the simplest possible I/O API for programmers - especially when using BASIC (as Commodore BASIC has no ON COM keyword.)

Since this actually has some peoples' interest, I'll work up a Google Doc for this, including the suggestions people have made.

I think we have the beginning of a workable specification; once I'm done moving, next month, I can grab a WDC prototype board and we can test this on a real VIA and an Arduino. 

https://docs.google.com/document/d/1HwHCv2txDu91l3uozRH8hwBrq6Fw06lmrQl3kidKQ1c

 

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

  • Super Administrators
On 7/17/2020 at 4:02 AM, BruceMcF said:

The latter is what an EPP interface would rely on ... as far as I can tell, CA1 set to 0 and CA2 set to 001 so both are independent negative edge detects would be fine for an EPP protocol ... especially since what connects to EPP are typically ISA bus speed devices, so being unable to keep up with the CX16 would rarely be a problem.

Whether CA1 should trigger an IRQ or not depends on whether you want an interrupt driven routine or want to poll.

However, as the User Port is most recently specified, would require a little rewiring of the standard block header to parallel port connector so that /Reset is on a spare GPIO. WIth a jumper setting, the same cable could be used for a standard parallel port and for an EPP.

A custom parallel port protocol could indeed be faster by relying on the hardware handshake to allow you to read or write a packet with very little delay.
 

So I'm rethinking the pins to take your suggestions into account. The problem is that I don't know if there's a way to directly read CA1/CA2. Can I read those pins with a PEEK? Otherwise, I need a separate ACK line, since ACK is currently tied to CA1, which is also the interrupt pin. (And I don't want the board triggering an interrupt when I do a read cycle.)
 

Link to comment
Share on other sites

6 hours ago, TomXP411 said:

The problem is that I don't know if there's a way to directly read CA1/CA2. Can I read those pins with a PEEK? Otherwise, I need a separate ACK line, since ACK is currently tied to CA1, which is also the interrupt pin. (And I don't want the board triggering an interrupt when I do a read cycle.)

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

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

10 hours ago, Andre said:

Absolutely agree. A couple of cycles is ok, but if it gets more, the driver should back up and e.g. enable interrupt, if only to be able to break out of the wait loop and not maybe hang indefinitely. (does X16 have an NMI key?).

The EPP is not a timing sensitive handshake, so it would be safe to have IRQ enabled, as long as all of the IRQ users respect the state of the handshake. In a fully IRQ driven I/O system, you can add that to your watchdog timer tasks.

In single tasking, if the busy loop is branch OUT on success, decrement X and branch back on nonzero, you can set a timeout and return with read/write failed.

Link to comment
Share on other sites

10 hours ago, Lorin Millsap said:

Are you guys opposed to an SPI UART?

If it's that SPI UART that is available in the +5v through pin package, I'm all in favor, whether it is because there is ONE free pin on Vera to enable a second SPI select (though in that case, it wouldn't be USING the +5v / through pin version, but I'd still want to be using that one, due to the expansion slot possibilities for re-using the same driver code) ...

... or because something is done to provide an SPI bus on the motherboard ... in the second case, bringing out SCLK, MOSI and MISO through block jumpers on the User Port would make the CX16 User Port a distinct step up from the C64 User Port.

But I've already made it clear the throughput available on a SPI UART is fine by me, I guess the question is directed to everybody else.

Edited by BruceMcF
Link to comment
Share on other sites

16 hours ago, BruceMcF said:

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

Just a simple addition:

(5) the IFR with the interrupt flags - and thus edge detection - can be read even when the interrupts themselves are disabled. CPU interrupts are only enabled if the IFR register bit _AND_ the corresponding IER (interrupt enable register) are set. Pls. have a look at the VIA datasheet for more details.

Link to comment
Share on other sites

14 hours ago, BruceMcF said:

If it's that SPI UART that is available in the +5v through pin package, I'm all in favor, whether it is because there is ONE free pin on Vera to enable a second SPI select (though in that case, it wouldn't be USING the +5v / through pin version, but I'd still want to be using that one, due to the expansion slot possibilities for re-using the same driver code) ...

... or because something is done to provide an SPI bus on the motherboard ... in the second case, bringing out SCLK, MOSI and MISO through block jumpers on the User Port would make the CX16 User Port a distinct step up from the C64 User Port.

But I've already made it clear the throughput available on a SPI UART is fine by me, I guess the question is directed to everybody else.

What about SSOP? It's not through-hole but better to solder than TQFP. E.g. this one https://datasheets.maximintegrated.com/en/ds/MAX3107.pdf (Note: haven't used it myself, just quickly googled it)

Or this one seems to be available in 14 pin DIP: https://docs.rs-online.com/ec74/0900766b80811942.pdf

  • Like 1
Link to comment
Share on other sites

  • Super Administrators
18 hours ago, BruceMcF said:

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

 

Thanks. That ties in with what I've been thinking... let's discuss this in more detail on the new thread. (I think you'll find I've anticipated this answer and have added interrupt handling to the spec.)

 

  • Like 1
Link to comment
Share on other sites

10 hours ago, Andre said:

What about SSOP? It's not through-hole but better to solder than TQFP. E.g. this one https://datasheets.maximintegrated.com/en/ds/MAX3107.pdf (Note: haven't used it myself, just quickly googled it)

Or this one seems to be available in 14 pin DIP: https://docs.rs-online.com/ec74/0900766b80811942.pdf

Yes, the MAX3100, that's the one that is still available in through hole packaging and 5v power. AFAICT, all of the later ones in the series are only 3.3v, surface mount. Mouser carries that one ... Digikey doesn't carry it ... they have 95 of the $7 (Q1) in stock, and list a six week factory lead time for larger orders.

Link to comment
Share on other sites

  • 5 months later...
On 7/6/2020 at 4:21 PM, Lorin Millsap said:

Since ROMs can’t be easily put in the expansion bus there are several methods for handling the driver.

[...]

Method 3 which adds complexity to the card, is that a microcontroller on the card could do a DMA operation and inject code into system memory. During this operation the CPU is inhibited while the microcontroller accesses system memory. While this may sound like an appealing plug and play option it has drawbacks. Firstly making sure it’s code injection plays nice with other hardware and that it doesn’t use memory reserved for other purposes. Also if something does go wrong it’s possible for the card to lock up the system. In reality this method would likely be a real-time compiler so that the generated code could be relocated. It can be made to work, it’s just in my opinion more complex and more likely to cause issues versus loading the driver from the SD card. If it becomes corrupted it would be harder to fix.

 

Since I don't have access to any development information right now - is that already "set in stone" that expansion cards are not able to provide their own ROM "on the card"? Is method 3 the only work-around that does not involve adding drivers manually to the kernal or kernal infrastructure? I also haven't looked into that design either - is there public information on that available? Could it be sent to me? I sign NDAs too, if needed... 😉

Link to comment
Share on other sites

22 hours ago, TheUnknownDad said:

Since I don't have access to any development information right now - is that already "set in stone" that expansion cards are not able to provide their own ROM "on the card"? Is method 3 the only work-around that does not involve adding drivers manually to the kernal or kernal infrastructure? I also haven't looked into that design either - is there public information on that available? Could it be sent to me? I sign NDAs too, if needed... 😉

Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.

There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

Link to comment
Share on other sites

23 minutes ago, BruceMcF said:

Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.

There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

That sounds interesting. Will there be a kernel function to step through the expansion slots I/O memory areas and check whether there is a card and let that initialize itself (with maybe even copying a ROM into RAM, patching BASIC vector, stuff like that? That would make expansion slot extensions a lot more flexible and would not bother users to manipulate SD card content. It could even be that there is an address to be jumped at per JSR and that byte holds RTS but could actually contain a small boot code?

We could check whether 32 bytes can make nice init function for expansion cards...

Kernel could check if there is a magic number in I/O space and then hand over execution of code. It should be possible to deactive this expansion card initialization either via keypresses on reset or via menu/system config. Manual starting of this should also be possible then.

Edited by TheUnknownDad
Link to comment
Share on other sites

I keep editing that post, so here a new post with a new idea:

To make this also a tinker's dream, let me build an expansion card with some SPI interfaces, some I2C, even I2S, some simple shift registers and even direct I/O.

You would want to have a nice interface for that, right? Be it some BASIC expansion that abstracts most of the protocol things away. Cool enough? But - why bother the user to install anything besides that card? Things get complex by themselves, so why not keep some things simple?

Obviously this is a more user convinience driven point of view. But I hope this computer is having its share, it should be overly complex to use - in my opinion. I couldn't really get an answer on what the design philosophy is regarding ease of use/user convenience. Most decisions seem to have a more technical reason so far... 

Edited by TheUnknownDad
Link to comment
Share on other sites

Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.

 

There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

Yup that is definitely finalized. Wanna load software/drivers? Put them on the SD card. As Adrian shared, the SD load routines are extremely fast. Why bother with ROM when your storage medium is not really going to keep you waiting.

 

The only ROM method available via the expansion slots is DMA. However there really isn’t DMA arbitration so good luck with that. Yeah it will work but it’s way more complicated for minimal benefit.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

13 minutes ago, Lorin Millsap said:

Yup that is definitely finalized. Wanna load software/drivers? Put them on the SD card. As Adrian shared, the SD load routines are extremely fast. Why bother with ROM when your storage medium is not really going to keep you waiting.

 

The only ROM method available via the expansion slots is DMA. However there really isn’t DMA arbitration so good luck with that. Yeah it will work but it’s way more complicated for minimal benefit.

Thanks Lorin, but isn't installing drivers something we love to not have needed "back then"? As I stated, this approach is very technical and maybe inconvenient for users, even though (or maybe bacause) they are retro enthusiasts. Does the design team have a target user group characterized? Could I find this (or a discussion on that) somewhere? I could learn more about the the product philosophy.

I imagine this computer should somehow revive that old feeling of "turn it on and let the fun begin". Here is an expansion card - it "just works"(TM). One part of the old fun was. that it was all selfcontained. No need to tamper around with another system to get up and running.

I am not asking for a design change here - I was asking for the intended use of the system. If that old way of getting things to work would still work, that would be nice and retro too.

I can skip DMA stuff, if there is a way to get my loader being called at the 32 Byte I/O window and that loader copies all needed code into RAM via the CPU. But that would actually require some kernel function to support this while booting. Just like the old cartridges.

Link to comment
Share on other sites

Well the way it works will probably be simple. You install your card, and that card will immediately be able to be used for software that supports it. If you want seamless KERNAL integration, well handling IO is the KERNALs job so extending its functionality through the SD which can be configured to load on powerup will be pretty seamless. You may have to run an installer the first time. Plug and play was not a design goal.

From my standpoint if the primary storage method was slow and clunky carts and IO mapped ROM makes sense. But when your SD card is about as fast as the CPU can handle it doesn’t make sense to do anything.

And what happens if you put two cards with a ROM? How would it know which one takes priority? How would it know where to put it in memory without conflicting? On systems like the C64 you had one expansion slot, so you really didn’t have to worry about conflicts caused by two expansion carts. On our design you’ve got 4 physical slots and 5 IO slots they can be mapped to. It does not differentiate which physical slot you put a card into.

Putting ROM on the expansion brings in all the difficulties of first generation ISA and the endless hardware conflicts that entailed. And the benefits of putting a ROM on the card does not offset the problems it creates when you have a more elegant and flexible solution known as put the driver on the SD card.


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

19 minutes ago, Lorin Millsap said:

Well the way it works will probably be simple. You install your card, and that card will immediately be able to be used for software that supports it. If you want seamless KERNAL integration, well handling IO is the KERNALs job so extending its functionality through the SD which can be configured to load on powerup will be pretty seamless. You may have to run an installer the first time. Plug and play was not a design goal.


From my standpoint if the primary storage method was slow and clunky carts and IO mapped ROM makes sense. But when your SD card is about as fast as the CPU can handle it doesn’t make sense to do anything.

And what happens if you put two cards with a ROM? How would it know which one takes priority? How would it know where to put it in memory without conflicting? On systems like the C64 you had one expansion slot, so you really didn’t have to worry about conflicts caused by two expansion carts. On our design you’ve got 4 physical slots and 5 IO slots they can be mapped to. It does not differentiate which physical slot you put a card into.

Putting ROM on the expansion brings in all the difficulties of first generation ISA and the endless hardware conflicts that entailed. And the benefits of putting a ROM on the card does not offset the problems it creates when you have a more elegant and flexible solution known as put the driver on the SD card.
 

Ok, many points here, let me get into this.

First of all: Plug and play was or is not a design goal? 

I understand your point regarding SD speed, I am still looking for that PnP usabililty.

From what I have heard and understood so far: physically, the system is extendable, but the way extensions are handled in a software way is not yet looked at?

Regarding hardware conflicts: I don't see the point. It is up to good design, to tell expansions apart. Am I right, that each expansion slot has its dedicated 32 byte I/O area? Or are they simply shared among all cards and you are "not to listen" to other devices I/O by magically selecting a free I/O memory area? So, if there is a way for the card to identify which I/O slot it is in, and there is a clear association, why is there hardware conflicting? We are still in the spec setting phase - so implementation can be regulated. Do it this way and things work out fine. There should also be a way to safely identify all connected expansion cards and the memory slot they are using. Is that already though of and part of the kernel?

What is the main planned usage of these expansions? Is it to take over the whole system or add special funcionality that ought to be used by either ASM or better even BASIC? If the later, how is the supposed way to add new commands in a compatible way? (so that more then one card can add BASIC commands!)

Don't get me wrong - this is no blaming or bashing. I just want to point into a certain direction of thinking about the system. I am eager to help if this direction has not yet been thought of. I believe that once the X16 is out, to have a working eco system, these expansion questions should be worked out already. Giving people a ready built example will help to implement new stuff and drive the eco system. It also sets standards to usage.

If I am all wrong and that expansion system is already all laid out well on hardware and software side (architecture), could you please be so kind to point me to the documentation? That would help me understanding a lot. Thanks.

Link to comment
Share on other sites

2 hours ago, TheUnknownDad said:

That sounds interesting. Will there be a kernel function to step through the expansion slots I/O memory areas and check whether there is a card and let that initialize itself (with maybe even copying a ROM into RAM, patching BASIC vector, stuff like that? That would make expansion slot extensions a lot more flexible and would not bother users to manipulate SD card content. It could even be that there is an address to be jumped at per JSR and that byte holds RTS but could actually contain a small boot code?

We could check whether 32 bytes can make nice init function for expansion cards...

Kernel could check if there is a magic number in I/O space and then hand over execution of code. It should be possible to deactive this expansion card initialization either via keypresses on reset or via menu/system config. Manual starting of this should also be possible then.

I don't follow "would not bother users to manipulate SD card content." It seems a lot simpler to just have a basic program load things up that you want loaded and set it to be the power up autoload program. This all seems like trying to solve problems the hard way because of some desire to not solve them the easy way.

Link to comment
Share on other sites

1 minute ago, BruceMcF said:

I don't follow "would not bother users to manipulate SD card content." It seems a lot simpler to just have a basic program load things up that you want loaded and set it to be the power up autoload program. This all seems like trying to solve problems the hard way because of some desire to not solve them the easy way.

I would try to splitt that apart into two aspects: Installing and using.

I want to make sure that everyone can do both. Many of my questions above in the discussion with Lorin are pointing to the "install" part. I am a strong believer in ease of use. I don't doubt, that getting an autoload program from SD is technically the best solution (as long as it then manages things like installing BASIC extensions & stuff like that).

How will the "setup" programm  get on the SD card? What does the user need to decide and what does he need to know to use the expansion card? My way of looking at things is to hide all technical aspects but not to make them unavailable. Meet people at their specific level and give them the opportunity to evolve further by digging deeper - but only if they want to.

Think of "Simon's Basic". As an example, it makes graphics easily accessable - you don't need to know how C64 managed graphical memory. It was "just there". You could also expand things yourself and tamper around with it. But to use it initially, you're not expected to copy anything anywhere, reply to configuration questions, edit config files, change disks, etc.

Why not make it as easiest as possible to start with? This is what my philosophy is so far.

If there are other technical ways of achieving the same - be my guest.  I just wanted to understand how to realize it with the possible X16 architecture so I can implement it in a way that could be used as a tutorial/example.

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.

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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use