EASy68K  
It is currently Thu Aug 24, 2017 8:29 am

All times are UTC




Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject:
PostPosted: Sun Nov 04, 2012 7:54 pm 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
My thoughts on the topic of peripheral blend...

So far, in discussion have been three peripheral devices, namely:

68901 = one UART, 8 GPIO with vectored INT capability, 4x 8-bit timers
68230 = two 8-bit bidirectional ports (w/handshaking), 1x 24-bit timer
68681 = two UART, 8-bit output port, 6-bit input port, 1x 16-bit timer

Both the 68901 and the 68230 are obsolete and not so easy to obtain. The 68681 is still available (e.g. Digikey) and reasonably priced.

For a MINIMUM system, I think it makes the most sense for the BIOS to assume a 68681 DUART because that device is still available (e.g. Digikey). The 68681 has a built-in timer which is free for use if the xtal-derived baud rates are OK (to me they are).

If a MINIMUM system needs parallel I/O beyond that available on the 68681, I propose the 8255. Sure, it's clunky, but it's very available and nearly everyone is familiar with it. So, I'm ambivalent - the MINIMUM can include an 8255 or not. I'll assume "include" unless someone vehemently objects.

I will personally want to add a 68901, which plays nicely with others in that it does not assume that it is the only vectored int source. Therefore, the 68681 must be the highest priority on the vector chain, followed by my 68901. I'm OK with that. I will probably end up not using the UART on the 68901. I think I'm OK with that, also.

Back to memory map a bit - I'd like to have fixed addresses for the 68681 and 8255, as well as addresses for 68901 and 68230 in the event that someone opts to include either or both of those devices. I'm happy to put all of these somewhere in the uppermost 32K.

As far as contacting me, I can be reached using gmail and my username there is the same as I use in this forum.

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 05, 2012 12:33 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
I think it makes the most sense for the BIOS to assume a 68681 DUART

Not forgetting to map it to even bytes only so that MOVEP can be used.

Ok, forget the 68230 for the minimum requirement.

Quote:
I propose the 8255.

Aaaaagh!

Quote:
and nearly everyone is familiar with it.

Which is why I dislike it so. Want to change a port's direction to output? Ok, but all the output bits will be set to 1 at the same time.

How about the W65C22 or even the Z80 PIO instead?

Then again if this system is going to be EASy68K compatible most of the I/O will be pretty much custom.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 05, 2012 1:38 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
lee wrote:
Quote:
I think it makes the most sense for the BIOS to assume a 68681 DUART

Not forgetting to map it to even bytes only so that MOVEP can be used.

Yep. That's pretty much a given, but thanks for stating it 'for the record', Lee. All the I/O should be on even byte boundaries.

Quote:
Quote:
I propose the 8255.

Aaaaagh!

Trust me...I didn't like writing those words much more than you liked reading them, I'll bet! Leave it to Intel to make a completely ghastly PIO chip. Which is why I really liked your suggestion of the 65C22. Brilliant.

Quote:
Then again if this system is going to be EASy68K compatible most of the I/O will be pretty much custom.


You seem to have come to exactly the same conclusion that I did, Lee, when I questioned even having parallel I/O . In the end, I think it's a good idea. I'm happy to break the cycle of 8255 agony in favor of a 65C22. :lol:

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 05, 2012 2:57 pm 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
My energy regarding the addressing mode for peripheral I/O is from experience on my prototype PCB. I didn't initially have I/O mapped to use Absolute Word addressing, and I noticed the inefficiency. For example, someone earlier mentioned the ability to get to higher baudrates on the 68901. My experience is that you really have to work to make any use of baudrates above 9600 because the processor can't keep up (regardless if I used the UART interrupt-driven or polled, I ended up inserting delays on the PC end, or using flow control, to give the 68000 time to process data received over the UART). On EASy68K everything is blazingly fast, but with real hardware every bus cycle you can save is a help!

Regarding GPIO, there's always CPLDs. The GPIO can be designed using a CPLD in a sane manner, and most any CPLD could keep pace with the CPU bus without wait states or synchronizing to the E signal. We could keep in the "spirit" of the thing by modeling the register map after one of the mentioned chips, or off of the GPIO in one of the Freescale ColdFire chips.

I'll look at the 65C22 as well. I think I may have programmed a 6522 once on an old AIM65 my dad gave me when his work was throwing them out, but it's been years.

Keep up the discussion!


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 06, 2012 3:24 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
My experience is that you really have to work to make any use of baudrates above 9600 because the processor can't keep up

What?! You have a whole millisecond between characters at 9600 baud, that is almost forever as far as even an 8MHz 68008 is concerned.

I have the 68681 on my 68008 Dart Board set to 57600 as the default speed because my old, single core laptop has trouble keeping up beyond that.

Quote:
but with real hardware every bus cycle you can save is a help!

Even the Motorola MC68000 educational computer, probably the slowest 68000 system ever made - 4MHz clock and two wait cycles per memory access, ran its serial ports at 9600 baud.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 06, 2012 9:53 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
maalper wrote:
Regarding GPIO, there's always CPLDs. The GPIO can be designed using a CPLD in a sane manner, and most any CPLD could keep pace with the CPU bus without wait states or synchronizing to the E signal. We could keep in the "spirit" of the thing by modeling the register map after one of the mentioned chips, or off of the GPIO in one of the Freescale ColdFire chips.


I agree that with programmable logic, a better and faster peripheral can be concocted. I think, however, that this is a pretty expensive way to get GPIO. A CPLD is very appropriate, for example, for some special I/O need - but in my opinion is not something that should be required for a "minimum system".

An 8255 or 6522 or 6821 or Z80 PIO (etc.) suits the purpose just fine, and any of these can be used without using the synchronous bus - it's simply a matter of DTACK generation.

I'm particularly fond of Lee's WDC 65C22 suggestion because that chip supports up to 14 MHz operation. That's faster than any 68008/000/010/020 can cycle even with DTACK grounded. The 65C22 will be waiting on the CPU! :o

Mark's point about the synchronous bus does bring one thing to my mind re: the 65C22. The 65C22 has timers, and those really want to count PHI2 pulses (T1 only counts PHI2 pulses, T2 can count PHI2 or PB6 pulses). If the 65C22 is connected asynchronously (cycle terminated by DTACK, PHI2 generated only during 65C22 access cycles) the timers become nearly worthless. Connecting the 65C22 synchronously (using the "6800 peripheral bus" and E clock) would remedy this - but that's not a solution for my 68EC020 and Lee's 68030 (those CPU's have no synch bus support)

Another, perhaps easier, possibility - use the WDC 65C21 instead of the 65C22. The 65C21 is a 6821 replacement; a PIO chip without timers. No timers = no problem with them not keeping time :wink:

Even if we opt for the 65C21/6821, our system will have the timer internal to the 68681 DUART, which we've already assumed as "standard equipment".

I'd like to hear the opinion of others re: 65C22/6522 vs. 65C21/6821 for the SBC assumption. (I'm leaning towards the 65C21/6821 approach).

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 06, 2012 4:48 pm 
Offline

Joined: Mon Jul 26, 2010 11:43 pm
Posts: 198
Location: Aurora, IL
maalper wrote:
Since the 68000 exception vectors *have* to be at $0000 I like to take advantage of the 68000 "feature" that it treats word-sized address operands as signed numbers and put I/O in the range of $FFFF8000 - $FFFFFFFF (decimal -1 to -32768). You probably already know, but putting I/O there makes accessing peripheral registers more efficient, and 32 K of I/O space seems like plenty to me.

In case someone reading this thread doesn't know about it (I sure thought it was a neat trick the first time I saw it) the assembler will generate an Absolute address operand in the above address range as a 16-bit number instead of a 32-bit number. When decoding the instruction the CPU reads the address as a 16-bit number and sign extends it to 32-bits.

On our MC68EC020FG boards we parked the RAM so it spanned zero. So taking the high order address bit out of the CPU (A23), and connecting it to the high order on the RAM.

For 64KB you had $000000..$007FFF, and $FF8000..$FFFFFF

Which works well with the sign extending hack, and the fact the assembler and compiler choose the most efficient opcode encoding that exploit that.

Where we had FLASH at $000000 and soldered to the board, we used some logic to map that too $800000 and access a ROM on a daughter programmer card that mapped to $000000 when installed, to permit in-circuit programming and recovery.

Other boards I've use have a ROM/FLASH boot at $000000, where writes are mapped to RAM, and the reset code copies in a minimal vector set before jumping to a mirrored/shadowed ROM location, and enabling RAM read/write at $000000.

The old MC68307 chips had 8-bit ROM and remapping functions built in, although availability at this point is probably pretty bleak.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 06, 2012 11:14 pm 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
Quote:
What?! You have a whole millisecond between characters at 9600 baud, that is almost forever as far as even an 8MHz 68008 is concerned.


I did say baudrates above 9600. I agree I can do practically anything I want at 9600. But at the risk of coming across as defensive, I'll give you an example of what I mean. Let's pretend I'm going to put a hypothetical UART on our hypothetical 68008 SBC and run it with a baudrate of 19200--about 520 microseconds in between characters. I want to use a buffered, interrupt-driven scheme to drive the UART so that data processing can happen while the UART is busy. Assume our hypothetical UART is mapped so that Absolute addressing has to be done using 32-bit addresses (since that was one of my earlier points). Finally, let's assume the 68008 is running at 8 MHz so we have a concrete definition of "forever."

Here's some code I threw together today mimicking the transmitter half of a buffered UART implementation I've successfully used on various microcontrollers over the past several years. The UART has a Control/Configuration Register (UART_CR), a Status Register (UART_SR) and a Transmittier/Receiver Data Register (UART_D). The UART buffer is a 64-byte buffer, and it is indexed with a head index and a tail index. Assume an insert function exists that puts bytes into the buffer and increments the head index, rolling the head index back to 0 when it reaches 64, and enables the UART Transmit Data Register Empty interrupt. This interrupt handler The execution cycles (according to EASy68K) for each instruction is given in brackets in the comment at the end of each line, and the total for each execution path is at the top of the routine.

Code:
********************************************************************************
* ISR to handle (hypothetical) UART Transmit Data Register Empty
*
* Execution Time:
* transmit buffer empty           - 142 cycles
* transmit buffer not empty, index not rolled   - 194 cycles
* transmit buffer not empty, index rolled   - 200 cycles
********************************************************************************
uart_xmit_empty_isr:
   movem.l   d0/a0,-(sp)      ;[24] save registers
   lea      uartBuffer,a0      ;[12] address of UART buffer
   tst.w      length(a0)         ;[12] any more bytes to xmit?
   bne.b   xmit_char          ;[10] yes: do the next character
                     ;     no: disable interrupt
   bclr      #CR_TDRE,UART_CR   ;[24] Disable Transmit Data Reg. Empty interrupt
   bra.b      uart_xmit_empty_exit   ;[10] exit isr...
xmit_char:
   move.w   tailIdx(a0),d0      ;[12] get index to tail of buffer
   move.b   buffer(a0,d0.w),UART_D   ;[26] transmit next char from the buffer
   subq.w   #1,length(a0)      ;[16] decrement the buffer length
   addq.w   #1,d0         ;[4] increment tail index
   cmpi.w   #UART_BUFF_SIZE,d0   ;[8] check for roll-over
   bmi.b   save_tail_index      ;[10] no roll-over, so we're finished
   clr.w      d0            ;[4] roll-over, so set index to the beginning
save_tail_index:
   move.w   d0,tailIdx(a0)      ;[12] save the index
uart_xmit_empty_exit:   
   movem.l   (sp)+,d0/a0      ;[28] restore registers
   rte                  ;[20] exit interrupt handler

(and now I find out just how ugly the code renders in this forum software...)

The 68008 has an 8-bit data bus, so our execution cycle counts roughly double. The M68000 User Manual lists the Exception Processing Execution Time of an interrupt as 72 cycles with an 8-bit bus (Table 7-15, p. 7-11 [p. 116 on my PDF version]). So on average that's roughly 72 + 194 * 2 = 460 cycles, and worst case 72 + 200 * 2 = 472 cycles. At 8 MHz that's an average of 57.5 uS, worst case 59 uS, around 11% of the processor time you have in between characters.

Now let's postulate a realistic application of the code to a BIOS firmware. Assume there's a very similar ISR for receiving characters from the UART and stuffing them into another buffer, which takes about as long to execute. And let's have our BIOS firmware echoing received characters by placing them into the transmit buffer--both ISRs would execute after each character, so that's 115 uS average, 118 uS worst case, or 22% of our time between characters.

Now throw in the execution time for that non-ISR code in our BIOS necessary for handling the buffered UART--such as pulling received characters out of the receiver buffer, implementing the "echo" by copying received characters into the transmit buffer, and stuffing received characters into a line buffer until the CR character (ASCII $D) is received (the CR will signal the BIOS to interpret the data inside the line buffer as a monitor command and process it). we're easily talking between 35% and 50% of the minimum CPU time between received UART characters just taken up in handling the buffers.

In the "real world" where I ran into problems was my BIOS routine for downloading S-records to my prototype SBC. At faster baudrates short files worked just fine, but once the terminal program started dumping the entire contents of a decent-sized S-Record file over the serial port with no delays and flow control, my BIOS code couldn't always keep pace. Inserting delays between each line made it work, of course, but also resulted in S-record downloads being just as slow as they were at 9600 baud!

Now before anyone points out I could simply not echo the received UART characters (I wasn't echoing in my aforementioned S-Record upload routine, by the way!), or points out inefficiencies or design flaws with my (slapped together example) ISR code, my point is simply that now you're starting to optimize. At 9600 baud and below the SBC just worked with the stupid-simple-obvious UART driver I wrote. Above 9600 I had to start making decisions affecting my implementation (optimize the ISRs, etc.). Solving these problems is part of the fun (for me, anyway) of system design in general, and using the older hardware in particular, but it's also behind my energy to design things as efficiently as possible on the front end.

Regarding the cost of CPLDs vs. the other GPIO options we've mentioned, Mouser shows the W65C21S6TPLG-14 at $5.95 for one, or $4.95 a piece for 10-99. The W65C22S6TPG-14 is $6.95 for one, or $5.95 a piece from 10-99. I see CPLDs with 32 to 64 macrocells in PLCC and TQFP packages (easy to solder) for anywhere from just under $1.50 to $9.00 unit cost. For a simple GPIO implementation mimicking, say, a 6821, isn't 32-64 macrocells likely to be enough? I'm hardly an expert on CPLDs, though, so I don't know which would be the best option. I've only used the Lattice ispMACH 4000V series, which is a 3.3V part (not cool for the GPIO of a 68K SBC, I think).

I'm perfectly happy to use 65C22 or 65C21, but I wanted to ask the question.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 07, 2012 3:01 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
or points out inefficiencies or design flaws with my (slapped together example) ISR code

I'm sorry but I can't resist. You made a classic error of implementing a buffer with an increasing index. If you implement the buffer with a decreasing index you get the bounds check for free when you decrement the index. This saves two word reads.

Quote:
with no delays and flow control,

Oh, I think I've found your main problem. 8^)=

Quote:
I've only used the Lattice ispMACH 4000V series, which is a 3.3V part (not cool for the GPIO of a 68K SBC, I think).

Actually it's not that bad. 3.3V CMOS parts can drive LS TTL logic inputs directly and you can usually get away with driving 3.3V parts directly with LS TTL outputs because the output high drive capability falls off very rapidly above 3.4V.

I'd like to see the EASy68K hardware implemented, could one of those ispMACH 4000V series devices do it?

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 07, 2012 3:14 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
maalper wrote:
I see CPLDs with 32 to 64 macrocells in PLCC and TQFP packages (easy to solder) for anywhere from just under $1.50 to $9.00 unit cost. For a simple GPIO implementation mimicking, say, a 6821, isn't 32-64 macrocells likely to be enough?


Hi Mark,

I'm pretty well versed with the Altera MAX7000 CPLD family, and I'd say 64 macrocells would allow for a rudimentary 16 bits of GPIO. At least 32 macrocells are required for the data and direction registers alone - each macrocell contains a single FF. For the two control registers, that's 16 more macrocells...so, yep, a 64 macrocell part could probably mimic a 6821 - perhaps even make it better in terms of bus interface, etc.

An EPM7064S could probably fit - and those are $7 new at digikey. So, you're right - it's about a wash in terms of cost compared to a new WDC65C21. The CPLD also requires some "infrastructure" to make it work (e.g. a JTAG programmer is required for Altera MAX7000 family).

In my opinion, it's a bit much to ask that the GPIO on a minimum system requires someone to buy and program a CPLD. FWIW, 1 MHz 6821 DIP pulls are available from Jameco for $4 each.

That being said, I am *certainly* going to use a CPLD on my implementation of the 68008 SBC for glue logic, DTACK generation, I/O decoding, maybe a SPI master if I can squeeze that in. I've got many 128-macrocell EPM7128S devices on hand. Once you've designed with a CPLD, you'll never want to go back to "hard logic" again!

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 07, 2012 6:19 am 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
Quote:
I'm sorry but I can't resist. You made a classic error of implementing a buffer with an increasing index.


@lee, you just proved my point...You're (compulsively? :-) ) optimizing my code. Good for you! I'm just wanting to optimize the hardware design, because I like doing that, too, and because if saving some cycles is worth a backwards buffer I would argue it is also worth getting the hardware optimal.

By the way, you'd lose one of the reads you gain using a decreasing index by having to set the index back to UART_BUFF_SIZE-1 when it rolls over instead of clearing it...unless of course you set the index using MOVEQ instead of MOVE immediate, in which case you couldn't use the other optimization I thought of and replace the MOVEM.L instructions pushing and popping registers with a pair of MOVE.W to save and restore D0 and a pair of MOVE.L to save and restore A0, which saves two bus cycles, I think...

Moving on, yes, these CPLDs would certainly be capable of implementing the EASy68K hardware, save of course for the graphics. In duplicating the Sim68K I/O window, the LEDs and switches would be a cinch, but the row of 7-segment displays would take a bit of horsepower, since I think you'd want to store the segment states as memory inside the CPLD for them to work like EASy68K. The segment memory alone would eat up 64 macrocells, assuming the decimal point segment is included.

@tom, even if the GPIO doesn't require a CPLD, the address decoding almost certainly will, for all the reasons you stated. Since many CPLDs use JTAG there are fairly inexpensive, if somewhat obscure, options out there. Once there's one CPLD on the design, I don't think it's really any worse having a second one.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 07, 2012 6:19 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
In duplicating the Sim68K I/O window, the LEDs and switches would be a cinch, but the row of 7-segment displays would take a bit of horsepower

Then there's also the auto interrupts which is not quite as hard as it first looks as the granularity seems to be 10ms, even though you can set it in increments of 1ms.

And yes, I do have a program that makes use of this feature, a morse code trainer that seems to work. After a lot of testing of the code I was out one day and heard someone's phone do the morse thing when they got a text and, quite to my surprise, my brain heard S M S. Must finish it sometime.

It's beginning to look like a small MCU of some kind may be needed to handle generating auto interrupts, selecting the timing and scanning the seven segment LEDs. The addresses of all the ports can be fixed as these can be read with task 32 but there's also the problem of controlling the hardware via task 32 by the 68K.

So with an MCU doing all the heavy lifting the hardware CPLD would be reduced to address decoding a port and some signal bits. As long as the MCU can respond before a bus error is generated, if ever, it would appear transparent to the 68K programmer.

I really want to build this.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 08, 2012 4:44 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
maalper wrote:
@tom, even if the GPIO doesn't require a CPLD, the address decoding almost certainly will, for all the reasons you stated.


Yep, I thought I was pretty clear on that. As I wrote in my last post, I will definitely use a CPLD for the "glue" - address decoding, DTACK/BERR generation, RESET/HALT generation, etc.

Quote:
Since many CPLDs use JTAG there are fairly inexpensive, if somewhat obscure, options out there. Once there's one CPLD on the design, I don't think it's really any worse having a second one.


I see your point, but I guess we differ here. I would not go to the bother to make a 6821 work-alike - I value my "spare time" too much to put the required effort (design, debug, document) into making a copy of a chip I can just buy for $6 (or less). But, hey, we all have our own views - if you want to make a 6821 work-alike from a CPLD, by all means, do so. It won't have any impact at all on the "standard" 68K family SBC we're going for here.

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 08, 2012 4:56 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
lee wrote:
It's beginning to look like a small MCU of some kind may be needed to handle generating auto interrupts, selecting the timing and scanning the seven segment LEDs. The addresses of all the ports can be fixed as these can be read with task 32 but there's also the problem of controlling the hardware via task 32 by the 68K.


Consider the higher pincount (40+) PIC16 and PIC18 variants that have the "Parallel Slave Port" peripheral. Might be an easy way to interface a "smart" I/O controller to the 68K. I've used the PSP with a homebrew 80186 system eons ago with great results.

In fact, I'm considering some sort of PIC to provide analog input, SPI mastering, and PS/2 keyboard input. The last two, in particular, are tasks that I hate to tie up the 68K with: reading a bunch of stupid keyboard pulses, or bit-banging a SPI bus.

Quote:
So with an MCU doing all the heavy lifting the hardware CPLD would be reduced to address decoding a port and some signal bits. As long as the MCU can respond before a bus error is generated, if ever, it would appear transparent to the 68K programmer.


Here's where the PIC with PSP really shines. If you're not familiar with the PSP peripheral, give it a look - I think you'll find it will do just what you're after.

Quote:
I really want to build this.


Me too!

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 09, 2012 2:38 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
In fact, I'm considering some sort of PIC to provide analog input, SPI mastering, and PS/2 keyboard input.

Perhaps you could add an SD card slot for transfering software from a PC host and an LCD port to complement the PS/2 keyboard. That would give you a device with at least text I/O without requiring it be tethered to a host.

I already have a lot of the 68K side software done in a BIOS that supports just about all the text I/O calls and has trace capabilities with disassembly and register display or modification. Not exactly like running code in SIM68K but pretty close I think.

You also get S record and flash ROM support as well as EhBASIC built in.

Lee.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group