We've discussed using a wiki for various projects from time to time here, so I have taken the liberty of setting one up. It is at:

http://6502org.wikidot.com

(Hope you don't mind me calling it the 6502.org Wiki, Mike!) I've put up a few pages as a starting point. The wiki is set up so that anyone can view pages, but you must be a member of the wiki to make edits. The reason for this is NOT to prove that you're some sort of super duper 6502 expert, it's to prevent people from vandalizing or posting spam on the wiki. You can become a member by being invited by a wiki administrator, which at the moment is only one person, namely me. Here is how I propose we proceed.

There are two ways an invitation can be extended. If you already have a wikidot account (Wikidot accounts are free) an invitation can be extended that way. (Some wikidot wikis are set up so that anyone with a wikidot account can edit it. Our wiki imposes the additional requirement that you also be a member of our wiki.) The other way is to extend an invitation by e-mail.

It would probably be wise to have at least a few people with admin privileges so that if someone is out of town, or sick, or gets eaten by a lion, etc. and something comes up that requires admin privileges, then there will be someone else available. For the time being, inviting/approving new members would probably the most common task that requires admin privileges. Maybe something else will come up that requires admin privilege, I really don't know. We'll cross that bridge when we come to it.

Also, since I may get inundated with member requests, before extending invitations to everyone, it would probably make sense to start with just one person, then get that person set up first as member, then with admin privileges. In other words, a guinea pig. This will give me a chance to learn how to add members, before opening the floodgates.

As far as I am concerned, everyone from the forum is welcome to become a wiki member also. So, here is what to do to become a member. Send me PM via the forum. (I know some people e-mail addresses, but in the interests of consistency, send me PM instead.) If I don't recognize your username, I can easily and quickly look up your posts (even if there's only a couple of them) to make sure you're an actual 6502 enthusiast, and not someone who signed up for a forum account to just spam the forum. Since I will be reading each PM individually it doesn't have to be anything special. Here are a couple of examples.

Example #1:

Subject: wiki

Body:

my e-mail is lmao@notredamesseason.com
I wanna be an admin
I'll be the guinea pig


Example #2:

Subject: wiki

Body:

my wikidot username is johnsmith123


Then I will choose a guinea pig and reply ONLY to that person. Once the guinea pig is up and running, I'll get everyone else set up. Then I will post another message in this thread to let you all know that I have done that. THEN you can hassle me about why it isn't working. Hopefully, we'll all be up and running in a few days. Also, it makes sense that there not be a huge time difference or a language barrier to overcome between me and the guinea pig, since we may need to exchange e-mails to get any kinks worked out. I am in the Central Time Zone in the U.S.; anyone anywhere is welcome to volunteer to be the guinea pig though; I'll take what I can get! If you want to be the guinea pig, please let me know where you are if it's not in your profile, a nearby metro area or even just a state is fine.

Whew! Are we almost done? No. Let's continue.

We should discuss how we want to handle new members in the future. Just on general principles, I'm opposed to having to sign up for A to get access to B, where in this case, A is the forum and B is the wiki. In practice, this probably won't be an issue, since who going to want to be a member of the wiki, but not the forum? However, one alternative is that it's possible to set up a page on the wiki where someone can fill out form to apply to be a member. They'd be instructed to submit some sort of technical content (e.g. changes or additions they'd make). Maybe something along the lines of "here's an addressing decoding article" or "you can optimized the code on page such-and-such by doing this". Anyway, we don't have to make a decision now, but it's food for thought.

Since we already have an established community here, we can probably just play it by ear, for the most part. There are only a few rules that come to mind.

1. Like 6502.org and its forum, the content should be targeted towards general 6502

2. There are no limits are the number of pages, but the total amount of space for file attachments (like pictures) is 100 MB. So please don't upload .pdfs (e.g. datasheets, scanned manuals, etc.) or .zip files since we'll run out attachment space quickly. Notice how I did it on the 65816 datasheet errata page; I didn't upload the datasheet onto the wiki, the datasheet is stored at WDC's website and I just linked to it. Likewise for the FIG-Forth errata page; in that case, the zip file is store here at 6502.org and the wiki page simply has a link to it. It is okay to upload a diagram or a schematic (e.g. a .png or .svg file) when it's relevant to the wiki article. For example, if you write an article about address decoding using only an 'HC00, an accompanying (black and white) schematic (e.g. a .png file) is clearly relevant to the article and should only be a few dozen kilobytes or so.

3. Since we already have a forum, to me it would make sense for the wiki to be article-oriented (like Wikipedia or the Sports Argument Wiki) rather than lots of discussion amidst the article itself (like WikiWikiWeb). When discussion is needed, a new thread can be started here in the forum and then linked to from the wiki.

What else...there's a page at wikidot describing the wiki syntax. Plus there's a how-to guide. It seems pretty easy to use. It's similar to the quote/code/bold tags here in the forum. A couple of things I've encountered so far.

1. The code block tags don't indent the first line of source code. Notice that the first line of code on the FIG-Forth errata page starts with a semicolon. If the line with the semicolon is removed, then the new first line won't be indented. I should probably submit some sort of bug report or a change request about this, but the semicolon work-around is what I came up with and it's easy to do.

2. There are no concept of directories at wikidot (there's categories which isn't quite the same thing). In the pages I've put up so far,I've adopted the naming convention:

directory-subdirectory-subsubdirectory-article

as a way of faking subdirectories. So errata is the errata page errata-software is the software errata page, and errata-software-figforth is the FIG-Forth errata page. And so on.

Anyway, it would probably be good to keep a copy of anything you add to the wiki in case something goes wrong, or at least until we all get a better idea of how it should be organized.

Finally, one other thing we should probably discuss at some point is the license for the wiki content. Right now its a Creative Commons license (the default license), but we can use whatever license we want, there's even an "other" option where you can write your own license.

If you have questions or comments, fire away. I'll answer what I can. I'm learning too.

Well, I wasn't sure how many people would want to sign up for the wiki immediately. ONE whole person! (Really!) That's fine, though. My intention is for this to be a long term project, so it can build slowly. If anyone has anything they want to add or otherwise contribute to the wiki, just PM me whenever you're ready and I'll get you set up. The nice thing about a wiki is that it can be updated incrementally, so even small changes/additions and experimentation is fine.

Again, if there are questions or issues anyone wishes to discuss, please feel free to reply in this thread.

Well, that is positively the single most user-hostile wiki syntax I've ever seen in my life. Even Media Wiki is easier to use than that.



Is there any reason why you chose this wiki provider instead of one based on MediaWiki?

SUBJECTIVE KNEE-JERK REACTION ALERT: Wiki is, to me, supposed to be as easy as it is supposed to be fast. That means that I should be AbleToCreateNewPagesEffortlessly, without having to [[[constantly wrap]]] everything into [[[Triple Brackets]]]. But, then again, I grew up on C2's wiki formatting.

Maybe I can offer some content in the form of my Forth compiler research efforts. This past thanksgiving, I have completed several proof-of-concepts which produce pretty stellar code, for relatively few lines of code (about 250 lines, for almost optimal representation of DUP @ 255 AND ROT -256 AND XOR SWAP !). It is still not as simple as it could be, though, and am thinking of writing a third proof of concept to explore my ideas further.

However, program flow is giving me issues, and I'm currently meditating on how best to implement that.

The idea may still be pretty foreign to our members here (including me); but they will probably start seeing the value when they see some good stuff going up. I would like to add a lot of material but it will be awhile before I'm back in a work mode that is conducive to that.

I looked at a number of different wiki farms with several criteria in mind. There wasn't one that stood out as being 100% perfect. Some of the criteria I considered were:

1. There should be no limit to the size of a page, no limit to the number of pages, no limit to the number of pictures (schematics) that can be attached, no requirements on how often the pages must be updated. I couldn't find one that met all of these, so something had to give. I chose the attachment limit; Wikidot claims they would like to increase the total space available for attachments, so that was what gave.

2. In an effort to keep the site low maintenance with regards to spam/graffiti, there should be a way to restrict who can edit pages.

3. Given that the subject is the 6502, source code and schematics are likely to be common; while it may not be necessary to specifically support them, it shouldn't be too ugly.

There are other things as well, e.g. a real directory/hierarchical structure (rather than just a naming convention) would have been nice, but to me, #1 and #2 are the biggies. I didn't really give much thought to wiki syntax. (I'm someone who willingly edits HTML, SVG, XML, etc. files with primitive text editors like Notepad, so virtually anything will be less verbose than that. In other words, I am perhaps not the best person to judge who has the best wiki syntax. )

That's the long way of saying I took a guess.



Yeah, single brackets for internal/new pages and triple brackets for external links rather than the other way would have made more sense to me, since the former is likely to be used more often. I'll admit I did look for syntax that DOESN'T MakePagesLikeThis specifically because ThisIsCompletelyUnFrigginReadableIMO. (There's a lot of interesting stuff at the C2 wiki, though.)

My position is that if a page has truly useful content, then it is going to read far more often than it is created/updated, so when it comes to a choice between the reader's convenience (legibility) and the writer's convenience (wiki syntax), side with the reader. On the other hand, we don't want to discourage writers from contributing.

It also crossed my mind that this may be less of an issue once we get used to the syntax. However, in most cases the bulk of the text is not wiki syntax, so whether it's really easy and fast or somewhat inconvenient is really dealing with exception and not the rule.

This brings me to one the main reasons I set this up: to try it out. Let's get the likes and dislikes out on the table, and let's separate the actual dislikes from the anticipated dislikes. I believe we'll get a much better idea of what we want in a 6502 wiki by trying one out than from speculation. The 6502 SBC For Beginners/Everybody Topic has come up numerous times, and it's resulted in more long (but amicable) threads than SBCs that get built. So for the wiki, I just made a decision and took the initiative. If it turns out that there's a better provider then so be it. As tedious as it may be to switch to a different provider, it will still be less painful if that conclusion is reached sooner rather than later. What I've set up is only a starting point.



No one should feel obligated to contribute content. There's been several topics that would seem to be better candidates for a topic-oriented wiki than a chronologically-oriented forum (especially since threads don't get bumped much here), most notably, Garth's scaled-integer math material. A few others that come to mind are errata, the stuff from the tip-of-the-day thread, address decoding using a quad 2-input NAND gate, collections of code like the recent bit counting thread, and proposals for things like a bus or a file format (rather than start from the first post, add this feature, subtract that feature ... what are open issues again?).

Those are things that have already been written. If something new comes up that seems suitable for a wiki, there's now a wiki available to experiment with whenever people are ready. It just seemed like now was a good a time as any to start a wiki.