• Next FCUG meeting - Sunday, July 21

    From rbernardo@iglou.com@3:770/3 to All on Tue Jul 16 19:06:39 2019
    Happy Ice Cream Day (Sunday), C= and Ami aficionados!

    The Fresno Commodore User Group has its next meeting from 11 a.m. to 2:00+ p.m., Sunday, July 21, at

    Panera Bread Restaurant
    3590 W Shaw Ave. (corner of W. Shaw Ave. and Marty Ave.)
    Fresno, CA 93711
    (559) 271-0104
    http://www.dickestel.com/meet_loc.htm

    It's only a few weeks before the August 10-11 Commodore Vegas Expo v15 (CommVEx), and we'll be talking about the latest happenings with that show. Also the Classic Los Angeles Computers! exhibit has just been approved for the Dec. 7 Downtown Los Angeles
    Maker Faire, and we'll talk about that, too.

    Speaking of CommVEx, if you haven't seen it yet, we'll look at the CommVEx 2019 commercial which shows some of the Commodore/Amiga personalities that have graced the show since 2005. Also for those who cannot make it to the show, we'll look at the video
    presentation of Roger Van Pelt demonstrating Giga-CAD+ with the SuperCPU.

    In hardware/software, the Ultimate 64 will have the new 2019 games -- Crystal Caverns, Death Weapon, Run Demon Run, Super Goatron, Stercore XD, Super Galax-I-Birds, and the silly Royal Hunt. We ran out of time at the last meeting for Robots Rumble on the
    VIC-20/Plus4, and we'll get to it this time. Also there is the new SD2IEC-Ready Games Collection (1986 onwards) for the VIC-20. The Amiga 1200 returns, and we'll look at some of the software loaded up on its hard drive.

    Truly,
    Robert Bernardo
    Fresno Commodore User Group - http://www.dickestel.com/fcug.htm

    P.S. Though our venue doesn't sell ice cream, you can still celebrate Ice Cream Day at the Sonic Drive-In down the street.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Rbernardo@iglou.Com@1:153/135 to All on Tue Jul 16 19:06:00 2019
    ilar fashion, which is also beyond the
    | scope of this FAQ. See your mail program's documentation.

    1.3 What we don't post

    We do not post:

    * non-binary items. Spam is deleted. Discussion is deleted. People writing us about why no one discusses anything in this group get deleted.
    Et cetera.
    The exceptions are the FAQ, naturally, and moderator announcements.
    So where should you post if you want to talk about Commodore 8-bits?
    A good question. Refer to:

    comp.emulators.cbm
    comp.sys.cbm
    alt.c64

    All of these, in particular the first two, have active discussion.
    Talk on them. We'd love to hear from another 8-bit fanatic.

    * binary items not relevant to the 64. UUencoded JPEGs of your pet wonderdog Snotbrain whizzing on Mrs. Eagleson's petunias get deleted. And so on.

    * 'warez'. Cracks, hacks, etc. are NOT allowed. The old argument
    that 'it's 10 years ago, the copyright doesn't matter' is hogwash. Someone still has the copyright, even if they're not enforcing it, and we don't want
    to be on their lawyer's target list if they decide to enforce it suddenly. (Want an example? Okay. Three words: Activision fifteen pack. Case closed.) Freeware and shareware versions of products are exempt because they are explicitly freely distributable, in contrast to ...

    * restricted distribution products. This is a fancy way of referring
    to 'stuff that shouldn't be publicly distributed', and includes things such
    as registered versions of shareware or beta tests that are not intended for
    the public. Moreover, if there's a restriction on the software's distribution, it's probably heavily copyright-protected too ... see 'warez'.

    * programs not intended for all audiences. For example, posting a
    nudie slide show for the 64 here would not be appropriate, and it would
    never be approved, even if it *were* in the public domain and freely distributable. This is not comp.binaries.erotica.cbm. You may think this is
    a silly thing to say, but there are some of these demos around.

    * things that don't work. Garbled submissions don't work. Make sure your uuencoded file didn't get truncated. Make sure your mailer didn't eat characters or add new ones, because on our end it looks like hell. IF YOU MUST MAIL US YOUR POST, PLEASE see the section on 'How to post by mail' to get around this problem.
    Most importantly, however, if it don't work, it don't post. If we
    can't get it to run, odds are most people who read this group won't either.

    * anything we decide not to post, at our discretion. Some people have claimed we're ignoring their posts because we don't like them. Tough orange peels.

    1.4 What happens if you post something we don't post

    Nothing.

    Yes, nothing. You will get no response from us, ever.

    In the past, the response was to notify you that we did not accept your post, and to send you some appropriate reason why. In this day and age of rampant spammage and people who blindly post insulting things instead of reading FAQs, that is an insurmountable task. Therefore, if you do not get a response to your
    post WITHIN A SUFFICIENT INTERVAL and/or your post never appears on the group, we did not approve it.

    If you have trouble with your newsreader, and want to know if your post
    came through, please state you want confirmation in the message body. We will confirm only in cases where we have a serious posting. If you post 'why aren't my messages posting somebody please respond' you will get a resounding fat
    load of nothing returned to you. However, if there's a possible submission attached to your polite and understanding request, we would be happy to tell you that it got there in one piece. Do not, though, assume that a lack of response indicates bad connection and therefore multiple reposting, because this will not endear yourself to the moderators and collect you many four- letter words. Ask first before you send that 2.5MB file again.

    If you do get a message back from us, we probably just need a small extra
    thing from you, like a description. Please read the note and comply; upon
    your doing so, you will be the proud parent of a new post.

    The phrase 'WITHIN A SUFFICIENT INTERVAL' has been cap'ed for a reason. It takes time to check through a submission, first to receive it, then to test
    it and then for the final post (if any) to percolate through the fibrous
    wire mishmash of Usenet. Please respect the fact it may take as long as a week to finish this process -- we have lives of our own, and we do this out of
    our free time. Therefore, not seeing your post immediately does in no way
    imply open and extremely prejudical rejection.

    1.5 What happens if you post something we post

    We post it.

    If appropriate, we will notify you (usually 'thanks!'), but in most cases
    you will know your post has been approved when you see it in the group. It is
    | good form to make sure your newsreader does in fact see this group. You
    | might also subscribe to the mailing list echo.

    If you want confirmation, say so. See above for conditions on that. Remember that sending confirmation messages is not guaranteed.

    1.6 c.b.c courtesy

    | Good things to do that make things easy for the moderators (and also, I
    | hasten to add, make things easier on the viewing audience):

    * Use .sda or .sfx, or any other self-dearcing format. It's easy
    for us because we don't have to crank up the dearcer. Lynx is especially bad
    on this point, since there's so many versions, a lesson I have learned the
    hard way with many people asking me why Ultimate Lynx doesn't understand
    CWI's Lynx archives. (Answer: We use Lynx IV, and they're mutually incompatible.) Failing that:

    * Use a standard emulator disk or tape image (compressed would be
    nice -- .zip okay, .gz even better!). With modern code, even zipped and
    GZipped .d64s can be handled directly on a C64, and for those mods that
    do quick testing on an emulator, we can drop the image right in. .d64 is
    now so ubiquitous that it has supplanted most .arc and .lnx formats as the preferred method of archiving floppies and files, despite its disadvantages.
    Failing that:

    * Use a standardized arc format. I like .lnx best, but can tolerate .arc. I find .lzh slightly exotic and .rar even more opaque. If you post using Fritz Fluegelwagen's RLE-LZW-Huffman-Lynx encoder, something three people on the planet use, the chances of my hitting delete in the mailreader increase exponentially.
    The one standard arc format you should avoid, if at all possible, is ZipCode (the 1! .. 2! .. files.) These cause some irritation on my part, mostly
    because I have to deal with four files instead of one. There are some circumstances where ZipCode is needed, but most of them involve copy- protection, which you find on (surprise!) copyrighted warez. See above.
    If these are PC binaries, please please PLEASE use .zip. I HATE
    unarj with a passion, and I don't like DOS tar or gunzip. I suspect the other moderators have similar preferences.
    But best of all:

    * Don't arc. If you can avoid it, don't! That's best of all. Then
    we can just run the stinking thing.

    For clarity, preferred formats, from most preferred down, for Commodore:

    .prg/.bin, .sfx/.sda/.spy/.sdl, .d64/.t64/.p00, .lnx, .arc/.lzh, .rar/.lbr

    For PC/Mac/UNIX:

    .zip/.infozip/.gz/.tgz, .Z, .sit, .arj, .rar/.lzh

    These are my preferences only and should not be construed as support for
    any format or having any rational basis in fact. :-)

    * UUencode. Don't Base64. This means refrain from using attachments. Most Unix newsreaders don't understand MIME, and most of us use a Unix newsreader. If you don't, please be kind to the large majority that do.
    The only exception to this is if you use a MIME-enabled mailer, and in that case you should read the section on 'How to post' BEFORE YOU POST!!!

    * No yEnc, please. There is no native C64 yEnc decoder, and we'd
    prefer they can access all postings even if you think the target shouldn't
    be a real machine. Furthermore, the autobots that handle automatic posting
    and processing all expect documents to be in uucode.

    * Document! You don't need to tell us how to turn the computer on,
    but please do tell us what we're looking at, and what we can expect when
    we run it. We can probably guess the rest. Accuracy helps. :-)

    A NOTE ON DOCUMENTATION: Some people believe that documentation consists of a single sentence saying 'this is a program for the (64|128|+4)'. We can see that already. Documentation is telling us what the program is supposed to do and what it needs to run, and this information is vital!
    Steve Judd writes particularly nice documentation. Look for some of this previous posts, if your news spool goes back that far (!).
    If you are sending an archive of programs, like a freeware
    archive, please describe each program individually and completely as if
    you had posted each one separately. A nice paragraph about the archive
    itself will probably not suffice. :-)

    * Post your post instead of mailing to us. The reason is not that
    we care how the post arrives, but that most modern mailers fiddle around with files and add metacharacters and 8-bit encoding and the like. Most news programs don't. Therefore, a post arrives more cleanly in general than does
    the mail.
    IF YOU MUST MAIL, PLEASE see the section on 'How to post by Mail'.

    * Above all, remember that your post must be readable by the lowest common denominator. Usually, that's us.

    1.7 Things you should *never* do

    * Crosspost. Never ever crosspost. Announcements about your web site, whether or not it will resurrect the 64 to millions of waiting fans
    worldwide and usher in a new computing paradigm renaissance, are not binary
    and therefore not germaine. Announcements about service offerings you may
    be providing, or the software opus you're writing, are not binary and
    therefore not germaine. (But if you have a demo, why not post that?)
    Why am I picking on announcements? Announcements are, bar none, the single
    most crossposted crud I can think of. STOP IT.
    Moreover, it s a waste of time for you, because if I don't approve
    the post, or any of the other moderators, it won't appear in any of the other groups you've crossposted to either. And we're not going to strip the c.b.c group and and repost it for you. It's not our job.
    The problem is now of such an extent that c.b.c no longer accepts crossposts, even if they *are* on-topic. Sorry. See section 2.1.1.

    * Mass post or autopost. In the past six months or so I have had two incidences of nearly several hundred megabytes of warez end up in my mailbox with more on the way, to the point where I had to complain to the offender's ISP to get them to stop before my server's mail spool got overrun.
    Not only is this unspeakably rude and impossible to process in a
    timely fashion, but it also can cause denial of service problems for moderators' ISPs and systems. Do NOT load your programs into an autoposter
    and let your program blast us on autopilot. Do NOT pack everything into a gigantic archive and bolus us at 5 gigs a post. If we can't contact you to
    turn it off, we *will* make sure you're disconnected one way or another.
    Please don't forget there's a human being looking at every post you send,
    and that not everyone's hard disk is as big as yours.

    * Use a hopelessly munged address. We're a fairly astute bunch of
    guys, and most mail munges are creative enough to be bot-foolers but still humanly decipherable, and we have no problem with munging per se. (Heck, I
    used to regularly munge mine.) However, we have received submissions from "G@RT" (actual from address) that we needed more information on. Guess what, bucko? Into the bit bucket. If we can't contact you about your post, we will reject it.

    * Bite your nails. Don't do it, it's a nasty habit and you look funny gnawing on them like that.

    2. Talking to c.b.c

    2.1 How to post

    2.1.1 The anti-spam bot

    In days gone by, the c.b.c moderator job had become increasingly difficult because of large amounts of spam to both the group and to the submission addresses, as well as large and frequently lengthy and repeated crossposts
    to groups where things should not be crossposted. This has meant many mod mailbox overflows and many ruined keyboards bouncing on whatever delete
    key is defined.

    Seriously, it really has been a problem, and only because of the magnitude
    have more drastic options been applied.

    On August 1, 2005, this policy went into effect (which is also given in the mini-FAQ). To successfully submit a formal submission or a question through
    the request address, your post or E-mail:

    - MUST HAVE: either the words 'commodore' or 'comp.binaries.cbm',
    spelled correctly, in upper/lower case, in either your MESSAGE BODY,
    MESSAGE SUBJECT, or both. No other headers will qualify. Odds are
    your message contains these key terms already! If it doesn't, it
    will be silently DELETED.

    ** Simply having comp.binaries.cbm in the Newsgroups: header is not enough! **

    - MUST -NOT- HAVE: newsgroups *other* than comp.binaries.cbm in the
    Newsgroups: header, if one exists. If you crosspost, it will be
    silently DELETED. (If you do not have a Newsgroups: header, then
    the first rule applies.)

    I'm sorry about the onerousness of the requirements, but they are a needed measure to keep c.b.c running smoothly, and most legitimate submissions
    should not be affected by this policy. Please note that messages that are trapped by the anti-spam filter do not reach the moderator, so we will not
    see them if your post fails any of these conditions.

    2.1.2 How to post by newsreader (MOST preferred)

    Simply point your newsreader to comp.binaries.cbm and post your document.
    You should refer to your newsreader for the appropriate documentation. Make sure it is uuencoded -- raw binaries never make it, and yEnc or MIME may be eaten by our pre-processing bots.

    What will happen is that your post will be sent by UUnet to the moderators,
    who will then review it. This method is most preferred because mailreaders screw around with mail they send, particularly MIME-enabled mailers. Most newsreaders don't. See above for the rest of the process.

    Please remember that your posts are pre-filtered! Read section 2.1.1.

    2.1.3 How to post by mail

    While we don't really encourage this, people do have trouble posting through Usenet, especially if your only access is through Google Groups or the like.
    If you really can't post by news, send your document to:

    comp-binaries-cbm(at)floodgap.com

    which is a mail alias maintained by Cameron Kaiser. If you use a
    MIME-enabled mailer, DO NOT UUENCODE IT BECAUSE THE MAILER EATS IT! In this case, and this case only, SEND IT AS AN ATTACHMENT. If the mailer is not MIME-enabled, like mailx or many Elm versions, send uuencoded files as
    usual.

    | Even if you subscribe to Spiro's mailing list (1.1.4), you can't submit
    | through it as posts do not enter the c.b.c moderation stream (and the
    | list is configured to block posts except from administrators anyway). Use
    | the submission address above instead.

    As a point of clarity, if you intend to send your program as an attachment,
    do NOT uuencode the program and send the *uucode* as the attachment. SEND
    THE BINARY ITSELF! Also, try to give the attachment a semi-descriptive name.
    We often strip out attachments in one big bunch, and a whole lot of similar looking files makes it tough to match files with posts.

    CompuServe seems to be problematic with uuencoded attachments. If you can
    use 'NewMail', please do so. If you can't, please alert the moderators in
    the message body that you're using CompuServe OldMail and we will try to
    rescue the post. (Thanks to John Iannetta.)

    Please remember that your posts are pre-filtered! Read section 2.1.1.

    2.2 Contacts

    As mentioned, it is better to mail the moderators collectively. Posting
    will have the same effect as mailing, but it's better to mail because we
    can differentiate between the two.

    The alias

    cbc-request+at+floodgap.com

    will send to all members of the moderation team, including me.

    If you wish to contact me personally regarding the FAQ or the large check you'll send me or the attractive, unmarried sister you have, send mail to

    ckaiser{at}floodgap.com

    and I promise to ignore it for as long as I can, unless I really like your sister or the check is good.

    John Iannetta has promised me an attractive sister, but I think someone at
    | Federal Express routed the crate to the Sultan of Brunei. Spiro Trikaliotis
    | has not sent me one yet.

    2.3 Troubleshooting

    2.3.1 'My post was approved, but it hasn't appeared yet'

    If you know that we approved your post, there are several reasons why it
    hasn't appeared yet. The only reason under our control is that we simply haven't injected it into the Usenet stream yet.

    Normally, we post things as soon as we approve them, just to get them out of our hair, so most of the time these reasons below apply. In such cases,
    there's no one you can blame, unless you have contacts at WorldCom. Usenet
    is a very haphazard mish


    --- PCBoard (R) v15.3/M 100
    * Origin: Danger Bay BBS * Vancouver, Canada (1:153/135)
  • From Charles Stephenson@1:226/16 to rbernardo@iglou.com on Wed Jul 17 21:21:53 2019
    On Jul 17th 1:29 am rbernardo@iglou.com said...
    Happy Ice Cream Day (Sunday), C= and Ami aficionados!

    The Fresno Commodore User Group has its next meeting from 11 a.m. to 2:00+ p.m., Sunday, July 21, at

    Panera Bread Restaurant 3590 W Shaw Ave. (corner of W. Shaw Ave. and Marty Ave.) Fresno, CA 93711 (559) 271-0104


    *SIGH*.. wish I lived in Fresno just so I could go! (and... for the ice cream!)



    --- ENiGMA 1/2 v0.0.10-alpha (linux; x64; 10.15.2)
    * Origin: The Amiga Frontier BBS *frontierbbs.net:8888* OH (1:226/16)