Parallax Forums

Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)

Forum Quick Jump

848 posts in this thread.
Viewing Page :

[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/18/2009 7:52 PM (GMT -8)

Dr_A: Does the sun go down on ZiCog?
Don't forget I'm in Finland, the sun soon going to be pretty much down for 6 months:)

I have not posted the code yet, must clean up my files a bit.

As for terminals, I'm on Linux so no HyperTerminal/TeraTerm. The BST terminal window gives me a blank line, say between A> prompts, every time I hit return. In GtkTerm I can send $0D or $0A individually and then no blank lines.
So this is a terminal problem not a ZiCog proplem. I'll try minicom at some point.

Dr_A: "heater, can you pls bump the zicog thread - it has been lost in the mists of time..."
Check this out: Go to Google, enter "zicog", the ZiCog thread is the FIRST result returned!!!
We are THAT famous. Seems in the whole internet "zicog" only appears on 412 pages!

Re: My disk images: I'm using SIMH 8Mbyte HD disk images expanded to 32MB by placing each 128 byte sector into one 512byte SD block with each being padded by zeros. I actually create my 8 floppies and one HD as a single file that is written directly to the SD card (no FAT or partitions or such)

I can skip the floppies and just make the HD image if you are interested.

For me, the past is not over yet.

Cluso99
We live onboard

Date Joined Apr 2008
Total Posts : 2276

Posted 8/18/2009 8:48 PM (GMT -8)

Heater: re hard disk image - What files are on the hdisk? Can I just copy them from a floppy style drive? If so, I can use one of the blank copies and format, then pip to it. I posted a VB6 program here maybe a week or two ago that I use to make the disk files. They take 137 byte inputs though and create 128 bytes of the 512 byte sectors like you have in the end.

Nice re google

You have made history then

Links to other interesting threads:

Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade, SixBlade, website

Single Board Computer: 3 Propeller ICs and a TriBladeProp board (ZiCog Z80 Emulator)

Prop Tools under Development or Completed (Index)

Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)

Search the Propeller forums (uses advanced Google search)

My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/18/2009 9:18 PM (GMT -8)

For my hard disk I just used SIMH AltairZ80 to create a blank disk I: and then copied all the files from A: to I: just so as to have something on it. CP/M 2 is using 128 byte sectors for hard disks by default so I have a Python program that stretches the SIMH image file, 128 sector bytes every 512 byte SD block bytes in the output file.

Actually the Python program also stretches 8 floppy disk images, 137 sector bytes into 512 SD block bytes, and concatenates them and the hard disk image into a single output file.

That output file is then written to the SD card using the Linux dd command as raw blocks (no FAT or partitions).

The Python program, mk_zicog_image.py is included in the release of ZiCog that I have just now posted.

As for the Google results, it seems odd to me. "zicog" is such a short word, most 5 letter combinations turn up for something even if its just due to spelling mistakes. Before we turned up "zicog" only had 200 or so hits.

For me, the past is not over yet.

Cluso99
We live onboard

Date Joined Apr 2008
Total Posts : 2276

Posted 8/18/2009 9:40 PM (GMT -8)

Heater: Do you convert the 137 bytes down to 128 in your conversion? Are they checked anywhere in CPM? I have been filling them in just in case. If we can ditch the 137 and go to 128 it would make things simpler for all of us.

Your hard disk image will be the same as mine then, so I can just format and pip files to it

Links to other interesting threads:

Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade, SixBlade, website

Single Board Computer: 3 Propeller ICs and a TriBladeProp board (ZiCog Z80 Emulator)

Prop Tools under Development or Completed (Index)

Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)

Search the Propeller forums (uses advanced Google search)

My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/18/2009 9:54 PM (GMT -8)

No. I'm putting all 137 bytes of the floppy sector into 512 bytes of SD block with zero padding.
The spin floppy emulator just throws all those 137 bytes at the BIOS.

You have a good point if I understand correctly:

1) Make my floppy images as 128 bytes of "real" sector data per every 512 bytes of SD block.
2) Have the floppy emulation read those 128 bytes and add the pre and post junk bytes.
3) Pass the 137 bytes into the BIOS.

As you say we then have floppy disk images that can be used in DemoBoard or TriBlade.

Just in case of confusion, SIMH does NOT have any "junk" bytes in its hard disk sectors. Only the 128 real data bytes. Only floppies have the 137 bytes.

For me, the past is not over yet.

Cluso99
We live onboard

Date Joined Apr 2008
Total Posts : 2276

Posted 8/19/2009 2:23 PM (GMT -8)

See my reply on ZiCog thread. But quickly
1 Yes
2 Yes but pre & post not required to be set
3 Pass 128 bytes into BIOS buffer +3

Then the only difference will be you are using 1 file the same as all my files (disks) concatenated and you don't use FAT16.

Links to other interesting threads:

Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade, SixBlade, website

Single Board Computer: 3 Propeller ICs and a TriBladeProp board (ZiCog Z80 Emulator)

Prop Tools under Development or Completed (Index)

Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)

Search the Propeller forums (uses advanced Google search)

My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/19/2009 3:41 PM (GMT -8)

Yep: sounds OK.

For me, the past is not over yet.

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/22/2009 1:51 PM (GMT -8)

Problem with unstable CP/M using 4 hard drives on TriBlade (and SIMH) resolved:

Peter Schorn has put me right regarding setting up 4 hard drives. Turns out that when one set nhdsks to 4 in CFGCCP.LIB the resulting CBIOSX is too big to fit into the memory space assigned to it in the rest of the system generation process. To accommodate the bigger BIOS one has to also set bioslen to 1000H in CFGCCP.LIB and change the line "SAVE 44 CPMBOOT.COM" to "SAVE 47 CPMBOOT.COM". Then do the syscpm2.

Had we been paying attention we would have noticed the warning message about this during the syscpm2 run.

Those two drives are costing us 768 bytes of RAM !!

For those in a hurry attached is a SIMH format disk built for 4 hard drives.

For me, the past is not over yet.

File Attachment :
cpm2_4hd.dsk 1.06Mb (application/octet-stream)

This file has been downloaded 21 time(s).

Dr_Acula
Registered Member

Date Joined Dec 2008
Total Posts : 606

Posted 8/24/2009 2:00 AM (GMT -8)

I've been doing some experiments trying to get it to boot from a hard drive. Was heater working on this too?

Anyway, zicog currently appears to copy DRIVE_1M.DSK into ram. This binary file looks pretty straightforward as it starts with
C3 00 F2 00 00 C3 06 E4 00 00 00 00 00 00 00 00

I know it is a bit sad being able to read machine code from hex, but that is a jmp to F200 which makes sense. So, load in an image of 64k of ram, then start executing at the first byte.

So I tried recompiling on the altair simh. This appears to work and drive A is cpm2.dsk. But looking at the binary of the disk, the first line is
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5

So, I'm not sure how the data is stored on the system tracks. Or even where the system tracks are.

The last line of the SYSCPM2.SUB batch file is
; write boot file to reserved tracks, must be last command
BOOTGEN CPMBOOT.COM A:

This writes a file to the system tracks. I managed to find the source for this program on the app.dsk

It is written in a language called SPL (simple programming language). This is a bit like C. To my eyes, and in a somewhat circular sort of way, it also looks awfully like Spin.

Anyway, this code contains a tantalising clue as to how the system tracks work

The sectors of a track are read in the following order:
first odd sectors, then even sectors in ascending order
1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,
2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
T0[S9 - S32], T1, T2, T3, T4, T5[S1 - S24]
28 + 32+ 32+ 32+ 32+ 28 = 184 sectors = 23552 byte (5C00)
loads sectors to 0 .. 5bff and jumps to 0 when done

But I can't quite decode how it works. At the very least, it does not seem to be a 1:1 copy of the memory.

Has zicog got to the stage of booting from a floppy image where the floppy image boot tracks have been modified with BOOTGEN?

And, can I ask who created the DRIVE__1M.DSK?

Floppy and hard drives ?? have the same boot track geometry. (Though hard drives maybe have more space). Would booting off DRIVE__A.DSK, or indeed, DRIVE__I.DSK involve decoding the system track geometry in Spin.

Any help or advice would be appreciated. Or maybe this has already been cracked?

Working through this document at the moment simh.trailing-edge.com/pdf/altairz80_doc.pdf

... found a C3 00 F2 up at 680H. Not sure what it is doing there.

... found info in the simh documentation about the boot rom on page 8 of the above pdf.

Post Edited (Dr_Acula) : 8/24/2009 10:12:44 AM GMT

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/24/2009 3:51 AM (GMT -8)

Hi Dr_A,

Yes I have been looking at booting from hard drive. Turns out to be very easy.
Yes we have been booting from CP/M laid down by BOOTGEN for a long time.

Here is an experiment you can do on SIMH to convince yourself of how booting from HD works.

1) Fire up SIMH into CP/M 2. Be sure you have "attach hdsk0 i.dsk" in your cpm2 command file first.

2) Rebuild CP/M 2 with "do syscpm2", be sure you first have at least 1 HD configured in CFGCCP.LIB
This step ensures you have HD enabled and produces a CPMBOOT.COM file.

3) Format your I drive with "xformat i" (optional)

4) Copy all your useful CP/M commands from A: to I: with "PIP I:=A:*.*"

5) Put CP/M system on the boot tracks of drive I with "BOOTGEN CPMBOOT.COM I:"
Actually the I: disk supplied with SIMH already is bootable but this is how to make it so.

6) Exit SIMH and edit your cpm2 command file such that the last line reads "boot hdsk0" instead of "boot dsk" or whatever.

7) Restart your SIMH and BINGO you are booted up from and logged into the I. drive.

Now how do we do this on the TriBlade ?

1) On SIMH assemble the HD boot loader HDSKBOOT.MAC to get HDSKBOOT.COM

2) Like DSKBOOT.COM this needs to be loaded into RAM prior to starting the emulation, we need both DSKBOOT and HDSKBOOT. It should be loaded at 5C00, if I remember correctly. So this HDSKBOOT.COM will need to be inserted into the RAM image file DRIVE_1M.RAM for TriBlade.

3) There is a byte in the DSKBOOT that determines the drive to boot from, I forget its offset now look in DSKBOOT.MAC.
This byte will need setting to 8, I believe, to select the I: disk.

4) The I: disk will need to have been BOOTGENed as above.

How does it work?

On start up the Z80 runs through RAM which is full of NOPs (zeros) until it hits the HDSKBOOT code at 5C00.
HDSKBOOT runs and finds out the desired boot device from the magic byte within DSKBOOT, which is at FF00.
HDSKBOOT then loads CP/M from that hard drive.

There is one catch: The HDSKBOOT as supplied uses some SIMH feature we don't have on TriBlade.
Just now i can't remeber what that was. Something to do with it asking the emulation, via the SIMHPORT, if banked memory is enabled. I think ...

For me, the past is not over yet.

Dr_Acula
Registered Member

Date Joined Dec 2008
Total Posts : 606

Posted 8/24/2009 4:24 AM (GMT -8)

Thanks heater.

I managed to work out booting from hard disks on the simh yesterday.

But booting on the zicog is eluding me. Working through your instructions now. Looks a little complex - maybe we need to automate this somehow? I'll see how it goes...

Hmm - are we rewriting the file syscpm2.sub?

Maybe go back a step - has anyone managed to boot from a floppy disk image?

Post Edited (Dr_Acula) : 8/24/2009 12:35:31 PM GMT

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/24/2009 4:26 AM (GMT -8)

I would try it myself, but booting from HD requires 24K RAM, no room on the DemoBoard.

For me, the past is not over yet.

Dr_Acula
Registered Member

Date Joined Dec 2008
Total Posts : 606

Posted 8/24/2009 5:13 AM (GMT -8)

Yikes, this is turning very complicated. First of all, booting to disk I on the SIMH seems to have a few bugs - using R and W hangs the simulation. So I've gone back to booting from A.

hdskboot.mac doesn't TYPE properly nor view in notepad, but you can view it by selecting all the text in notepad and then paste that into Word.

There is this little bit of code which does suggest it is not loading from sector 0:

firstSector equ 8 ; first sector to load
firstTrack equ 0 ; from this track

I had this idea that one could drop in a simh disk image with the system tracks already loaded and there would be enough information to boot from that. I guess we are looking for a boot eprom, and I think such a thing exists in the simh but I can't find its description. The altair simh c source is many files to search through.

Rebuilding the N8VEM is complicated too, especially when every part is packed together so when you add a few bytes to one bit of code it overwrites another bit. I ended up automating the whole process with the program below - which behind the scenes has pages of vb.net code. It even shells out to the simh via telnet at one stage. It does come down to a few clicks on boxes to make a new image and that is simple - just as running DO SYSCPM2 is a simple one step command on the simh.

I was trying to aim for simplicity by creating a 'boot rom' in Spin to read off the first few sectors and act on them. But even that could be complex as there will be different settings for hard and floppy disks.

So.... maybe go back to the system as it is. Boots by reading in an exact copy of the 64k of memory off a simple binary file DRIVE__1M.DSK

The only thing I have tweaked in Spin for that is to only read in 8 blocks instead of 128. Speeds up cold boots. And if I want to fill the ram disk, there are other ways to do that. Though I think there is a trend towards using the ram for banking anyway.

I'm leaning towards heater's philosophy on this - keep the simh as it is, 8 floppy drives, 2 hard drives. And boot from whatever is in DRIVE__1M (kudos to the author of that!).

Image Attachment :

Image2.jpg 134KB (image/jpeg)

This image has been viewed 25 time(s).

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/24/2009 6:51 AM (GMT -8)

HDSKBOOT.MAC has funny line endings, I view it in wordpad or kate on Linux.

SIMH dose have a boot ROM. It loads the DSKBOOT.COM into FF00 prior to starting. The code for DSKBOOT.COM is actually held in the C source of the floppy disk emulation as a bunch of data definition bytes. I forget the name of the disk driver emulation source.

Likewise the HDSKBOOT code is held in the hard disk driver emulation module.

I would recommend NOT creating a "boot rom" in Spin. Could be done but one has to read the sectors in a strange order and then doit differently for floppy or hard disks. We already have a floppy boot ROM working. It's DSKBOOT.COM and it is in that DRIVE__1M.DSK. Soon we will be able to put HDSKBOOT.COM into that file as well.

By the way DRIVE_1M.DSK is not any kind of disk image CP/M or otherwise. It is an image of the 64K RAM to set up prior to starting the emulation. With the DSKBOOT.COM sitting at FF00 and a few jumps setup at 0000 up.

For me, the past is not over yet.

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/24/2009 3:01 PM (GMT -8)

Just managed to get reading and writing of packed Altair floppies working in ZiCog, 4 sectors per SD block.

Results:
Reads seem to go at about the same speed. No measurements just how it feels.
Writes are noticeably slower.
Disks are one quarter the size, duh.

Whats wrong?
Despite all my previous hand waving arguments about consecutive reads/writes benefiting from only having to read/write one SD block for every 4 sectors we have forgotten that CP/M, at least the BIOS, actively works against us.

CP/M has allocation blocks on disk. That is it works with files in chunks of sectors, say 1024 bytes worth, which would be great for ensuring a lot of sequential reads/writes.

BUT in an attempt to optimize the performance of real floppy drives it implements sector skewing. That is when accessing "logical" sectors 0, 1, 2, 3, 4... the BIOS goes to "physical" sectors on disk 01, 18, 03, 20.... or some other scheme. This is an attempt too allow the disk to spin around so that the next logical sector is under the head while the last sector is being processed.

This effort by the BIOS to ensure speedy sequential accesses of course is exactly the opposite of what we need and almost guarantees we never see sequential access to sectors within our SD card blocks.

Damn.

I will now get on with the packed hard disks. Luckily HDs don't use skewing and have large allocation blocks so sequential sector access should be the norm.

For me, the past is not over yet.

Yoda
Registered Member

Date Joined Mar 2009
Total Posts : 61

Posted 8/24/2009 3:38 PM (GMT -8)

Heater:

You can change the skew pretty easily in the CBIOSX. It is discussed in Johnson-Laird. I was thinking we would run into this - you got there before I could tell you.

Dave

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/24/2009 10:30 PM (GMT -8)

That skew thing has been in the back of my mind in the past, trouble is the back of my mind seems to have a hole in it.

Yes we can easily get rid of the skew. But then we hit that SIMH incompatibility problem again.

For me, the past is not over yet.

Cluso99
We live onboard

Date Joined Apr 2008
Total Posts : 2276

Posted 8/25/2009 2:22 AM (GMT -8)

WOW - I did the skew thing in 1975 on the mini's I worked on

Could read every 2nd physical sector, but only write every 4th physical. Never thought it would be in CPM.

Heater, give the packed sectors a miss for now. We can always do it in V2.0. It is not a show stopper and for now it is fast enough. We have far better things to improve on than this.

Later, it will be easy enough to determine whether the drive is packed or not.

Links to other interesting threads:

Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade, SixBlade, website

Single Board Computer: 3 Propeller ICs and a TriBladeProp board (ZiCog Z80 Emulator)

Prop Tools under Development or Completed (Index)

Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)

Search the Propeller forums (uses advanced Google search)

My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/25/2009 5:41 AM (GMT -8)

Clusso. I'm on a roll here, can't stop.
Thing is there is no skew problem with the hard disks plus hard disks have large allocation blocks, I forget how big just now.
Allocation blocks are consecutive sectors used as the minimum chunk size of a file and so should give rise to predominantly sequential access of sectors.
So again I'm curious to see if there is any performance boost from packed hard disk images disk images.

The way I see it, given that we have 4 large hard drives, and that floppies are always full, one would be working mostly in the hard disks. Maybe only using floppy images to import stuff from SIMH say.

So if floppy read speed is about the same who cares if we drop a bit of floppy write speed?

It's not much effort to do this, lets see how it goes, if it is a real dog we can drop it for now.

Are you up to giving the packed hard disks a test when I'm done, still need to take time out to build TriBlade.

For me, the past is not over yet.

Dr_Acula
Registered Member

Date Joined Dec 2008
Total Posts : 606

Posted 8/25/2009 5:57 AM (GMT -8)

Just for a lark I thought I would fire up MPM on the simh. 4 simultaneous users and banked memory.

Steps to do this:
Get MPM from http://www.schorn.ch/cpm/intro.php (about 1/4 of the way down) and put it in a directory
Copy the program ALTAIRZ80.COM into that directory (is on other packages but not in this one)
Create a little file (with notepad) called MPM.BAT and add this line :
altairz80 mpm

Run hyperterminal with a new session 'connect using TCP/IP' Leave the host address blank and use port 23
Type MPM<Ret> and it should scroll up some text.

Open hyperterminal again so both are running and do the same thing.
One will be user
0A>
and the other
1A>

Why bother?

Well, if we can drop in disk images for CP/M2, then we ought to be able to drop in other disk images. This is the simh compatability that heater talks about. Leave the disk images as they are and if you want something different (eg emulate a few ports from the N8VEM), add a few lines of spin code.

I have a reason for wanting this. I would like to be able to be running CP/M (or MP/M) on one board, and to be able to browse another board via wireless. Like Windows can. With a multi user system, one serial port could be the real port running whatever user programs one is running, and another serial port could be connected to a wireless transceiver (like we already have with xmodem) and in that user area one could have a simple program that autoboots and serves up files. A wireless file repository. I think that would be a really cool use for the zicog, with its huge file capacity and all.

But I'm a bit confused about something. I have books for MPM but non CPM3. MPM has banked memory, presumably for multi users. Is CP/M3 multi user? Is the banked memory in CP/M3 used for the same thing?

But a sanity check first - is this all crazy talk?

Addit: I've started documenting my wireless CP/M project here www.smarthome.viviti.com/build

Post Edited (Dr_Acula) : 8/25/2009 2:04:04 PM GMT

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/25/2009 6:10 AM (GMT -8)

I'd love to see MP/M on a TriBlade. Are we going to need interrupts to make that work ?

CP/M 3 is not multi user but it can use banked memory. Basically it moves a load of its BIOS, BDOS, CCP stuff into one bank making room for a lot bigger TPA in another bank. I believe it is possible to shrink the "resident" part of CP/M down to a couple of K, just enough for the applications to make calls into then it bank switches to get the work done. So the TPA can be over 60K. Use of any other banks seems to be down to the applications to do as they will.

On SIMH and ZiCog we are using 48K banks and 16K resident area at the top of memory. It's fast and convenient that way.

CP/M 3 did not have time to catch on before it was run over by DOS/MicroSoft/IBM. So I guess books on it are thin on the ground.

MP/M extends this idea by having many banks and a TPA per user.

For me, the past is not over yet.

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/25/2009 6:24 AM (GMT -8)

Oh I forgot: "But a sanity check first - is this all crazy talk?"

No it is not crazy talk. Cluso has had CP/M 3 running on TriBlade. we should be able to get the bank switching sorted for CP/M 3 with banks.

So MP/M is very close.

Second thoughts, it's 2009 and we are putting CP/M on a micro-controller, we are all crazy !

For me, the past is not over yet.

hinv
Registered Member

Date Joined Jan 2007
Total Posts : 487

Posted 8/25/2009 6:47 AM (GMT -8)

Hi Heater,

Since you can emulate a CP/M machine with your ZiCog, How about emulating a TimexSinclair TS1000?

Doug

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/25/2009 7:40 AM (GMT -8)

TimexSinclair TS1000 - Is that like a ZX80, ZX81 or Sinclair Spectrum ?

At least one person here started down the road of a ZX80/81 using ZiCog as the CPU.
The Speccy might have to much Tricky hardware to deal with but on TriBlade board who knows what's possible.
Personally I have no desire to go down that road but I'd love to someone do it.

For me, the past is not over yet.

heater
Registered Member

Date Joined Feb 2008
Total Posts : 1832

Posted 8/26/2009 5:46 AM (GMT -8)

Just got ZiCog reading and writing for packed hard disks. Speed seems quite fine.

I would post the code but I left the version with packed floppies on a USB stick back at my office. So tomorrow.

For me, the past is not over yet.

[ << Previous Thread | Next Thread >> ]

848 posts in this thread.
Viewing Page :

Forum Information

Currently it is Friday, November 20, 2009 10:16 PM (GMT -8)
There are a total of 393,733 posts in 55,521 threads.
In the last 3 days there were 83 new threads and 703 reply posts. View Active Threads