@(#)top: ######## ################## ###### ###### ##### ##### #### #### ## ##### #### #### #### #### #### ##### ##### ## ## #### ## ## ## ### ## #### ## ## ## ##### ######## ## ## ## ##### ## ## ## ## ## ##### ## ## ######## ## ## ## ### ## ## #### ## ## ##### #### #### #### #### ##### #### #### #### #### #### ###### ##### ## ###### ###### Issue #13 ################## Version 1.0 ######## July 1996 ------------------------------------------------------------------------- @(#)contents: Table of Contents Features 6. OS/A65: A Multitasking Operating System by Andre Fachat (Reference: os) Just when you thought it was safe to run a single program on your Commodore 64, Andre ups the ante and details a framework that allows you to coax your machine to do multiple things at once. If one app was trouble enough, try taming two or more at a time! 8. Using UQWK with QWKRR128 by Gaelyne Moranec (Reference: uqwk) After years of using QWKRR128 to read BBS email and FIDO echoes, you want to access the Internet as well. Does that mean you'll have to shelve QWKRR128? No way! Gaelyne details how to use a UNIX program called UQWK to package up USENET newsgroups and Internet electronic mail for offline perusal by QWKR128. 10. Brad Templeton: The Programmer's Friend - An Interview by Jim Lawless (Reference: pal) Templeton, the originator of the PAL assembler and a driving force in programmer aids in the late 70's and early 80's, reflects on those early years, where programmer tools were pretty spartan. Travel in time with Brad to an era where IBM specialized in mainframes, and proprietary schemes were commonplace. 12. Hacking Graphics by Stephen Judd (Reference: demo) We've talked about 2D graphics, and we've talked about 3D graphics. So now it's time to talk about 4D graphics. This article will explain how to do just that, and includes source and binaries for dim4, an entry in the recent 4k demo contest held by Driven magazine. 13. Exploiting the 65C816S CPU by Jim Brain (Reference: cpu) So, the eagerly anticipated accelerator from CMD is becoming available. Sure it's fast, and it'll boost speeds in existing applications. However, you know users won't be content for long. Learn how to take advantage of the extra addressing modes and wider CPU registers when you flip the '816 into Native mode. In addition, Jim will detail the preliminary set of "magic" memory locations in the CMD SuperCPU. 14. Using HTML on the Commodore, Part 1 by Jim Brain (Reference: html) Your IBM friends are drooling over the World Wide Web and its markup language: HyperText Markup Language (HTML). Are you worried your CBM machine might not be able to handle HTML? Worry no more. Jim will teach you the HTML language and how it can be used on the Commodore system. In part 1, Jim details the language and its elements and lays the ground work for a Commodore HTML parsing engine. Columns 4. Hi Tech Trickery by Alan Jones (Reference: trick) Here's the proof you need to kill off the persistent myth that 8-bitters can't cut the mustard in complex computations. Alan lays some groundwork and details a few tricks in stretching those 8-bits to the limit and beyond. 15. Hacking Graphics by Todd Elliott (Reference: gfx) So you have created the world's nastiest dungeon engine for your torture chamber of a game. Don't forget the presentation. Todd shows how to create a 3-dimensional scene that will bring your dungeon to life. This will give your unsuspecting victim the most realistic gameplay possible. Departments 1. The (cough, cough) Hacking Editor (Reference: editor) 2. Input/Output (Reference: io) 3. Newsfront (Reference: news) 5. Hacking the Mags (Reference: mags) 7. UseNuggets (Reference: usenet) 9. FIDO's Nuggets (Reference: fido) 11. Hack Surfing (Reference: surf) 16. Commodore Trivia (Reference: trivia) 17. ? DS, DS$: rem The Error Channel (Reference: error) 18. The Next Hack (Reference: next) 19. Hacking the Code (Reference: code) ------------------------------------------------------------------------- @(#)legal: Commodore Hacking Legal Notice Commodore and the respective Commodore product names are trademarks or registered trademarks of ESCOM GmbH. Commodore Hacking is in no way affiliated with ESCOM GmbH, owners of said trademarks. Commodore Hacking is published 4 times yearly by: Brain Innovations Inc. 10710 Bruhn Avenue Bennington, NE 68007 The magazine is published on on-line networks free of charge, and a nominal fee is charged for alternate mediums of transmission. Permission is granted to re-distribute this "net-magazine" or "e-zine" in its entirety for non-profit use. A charge of no more than US$5.00 may be charged by redistribution parties to cover printed duplication and no more than US$10.00 for other types of duplication to cover duplication and media costs for this publication. If this publications is included in a for-profit compilation, this publication must be alternately available separately or as part of a non-profit compilation. This publication, in regards to its specific ordering and compilations of various elements, is copyright (c) 1995-96 by Brain Innovations, Incorporated, unless otherwise noted. Each work in this publication retains any and all copyrights pertaining to the individual work's contents. For redistribution rights to individual works, please contact the author of said work or Brain Innovations, Inc. Brain Innovations, Inc. assumes no responsibility for errors or omissions in editorial, article, or program listing content. ------------------------------------------------------------------------- @(#)info: Commodore Hacking Information Commodore Hacking is published via the Internet 4 times yearly, and is presented in both ISO-8859-1 and HTML versions. This and previous issues can be found at the Commodore Hacking Home Page (http://www.msen.com/~brain/chacking/), as well as via FTP (ftp://ccnga.uwaterloo.ca/pub/cbm/hacking.mag/) In addition, the Commodore Hacking mail server can be used to retrieve each issue. To request a copy of an issue, please send the following electronic mail message: To: brain@mail.msen.com Subject: MAILSERV Body of Message: help catalog send c=hacking13.txt quit To retrieve a PKZIP 1.01 archive of the individual articles in Commodore Hacking, request the file c=hacking13.zip To subscribe to the Commodore Hacking and receive new issues as they are published, add the following command to you MAILSERV message prior to the quit command: subscribe c=hacking Firstname Lastname msglen (msglen is largest size of email message in line you can receive. Each line is roughly 50 characters, so 600 lines is about 30000 bytes. When in doubt, choose 600) example: subscribe c=hacking Jim Brain 600 Although no fee is charged for this magazine, donations are gladly accepted from corporate and individual concerns. All moneys will be used to defray any administrative costs, subscribe to publications for review, and compensate the individual authors contributing to this issue. New: As part of a magazine promotion, Commodore Hacking Issue #12 was professionally laid out on printed format. These printed copies are for sale for US$6.00. Price includes shipping within the US. Any persons wishing to author articles for inclusion in Commodore Hacking are encouraged to view the submission guidelines on the WWW (http://www.msen.com/~brain/pub/c-hacking-submit.txt) or via the MAILSERV server (send c-hacking-submit.txt). ========================================================================= @(#)rch: Reading C=Hacking Starting with Issue 11 of Commodore Hacking, the new QuickFind indexing system is utilized to aid readers of the text version in navigating the magazine. At the top of each article or other important place in the magazine, a word prefixed with a special string is present. (See the title of this article for an example. Throughout the magazine, if an article is mentioned, it will be followed by a reference string. For example, if we mentioned this article, we would add (Reference: rch) after the name. By using your favorite editor's search function and searching for the string after the word "Reference:", prefixed by the magic prefix string, will move you directly to the article of choice. To merely skip to the next article in the magazine, search only for the magic prefix string. Some handy indexing strings possibly not referenced anywhere are: top top of issue bottom bottom of issue contents table of contents legal legal notice For those with access to a UNIX system, the command "what" can be run on the issue, which will result in all the article titles being printed. A slightly different magic prefix string "@(A)" is used to delimit sub-topics or main heading in articles. The text after the magic string differs depending on article content. For the Input/Output column (Reference: io), the text after the magic prefix will either be "c" for comment, or "r" for response. In features and columns, a number after the prefix indicates the ordinal of that heading or sub-topic in the article. If a specific sub-topic is referenced elsewhere in the article, a sub-topic reference will be indicated. A reference to "@(A)r" would be written as "(SubRef: r)". As time goes on, the role of this indexing system will be expanded and changed to ease navigation of the text version, but minimize the clutter added by these extra items. ========================================================================= @(#)editor: The Hacking Editor by Jim Brain (j.brain@ieee.org) I recently had to choose between my interest in Commodore computers and something else. To many, the choice was clear. Many assured me that hobbies were important, but they simply had to take a back seat when other pressing issues came up. I'll admit that the decision was hard to make. I find that strange, do you? I mean, seriously, it's just an outdated, underpowered, orphaned, incompatible, proprietary, obsolete, 8-bit computer system. Why would I even consider that important? If you can explain that to me, then you are a true Commodore enthusiast as well. We are all bound together by the immense "pull" of these systems. We don't just "own" them, we treat them like part of the family. We buy toys for them, we help them grow, we accept their limitations, we spend hours with them, and we know everything about them. Although we might have younger and faster family members, we cherish our Commodore. No person or thing could convince us to trade in our familiar family member for a newer, shinier model. As I think of it this way, it seems a bit scary, doesn't it. Not to leave you in suspense, the "something else" I alluded to above was a new employment opportunity and the subsequent relocation of myself and my family. Even as strong as my feelings are for my beloved machine, I decided that my family came first. Hobbies, no matter how important, are not quite as important. I announced my decision to others who have similar "family members" in their homes, and I pulled the plug on my hobby. Now, I don't consider myself that important in the scheme of things, but I did underestimate the consequences of my decision. As friends and I tallied up what resources would be unavailable as I left, the amount grew sizable. Luckily, just as with all situations, friends stepped forward to help and keep information from becoming unavailable. Others simply provided moral support and all offered the precious gift of patience while I turned to matters at hand. I consider myself lucky that so many offered so much to make the situation more tolerable. For reasons unknown to me, it bothered me greatly that deadlines would be missed, pieces of information would go unpublished, important updates would not be updated, and information seekers would find nothing but unanswered questions. Although I knew better, I felt I had deserted the people who depended on me. It's amazing how wrapped up in this I have become. As you may have guessed, one of the most disturbing resources that was left unfinished was this issue of Commodore Hacking. Although originally scheduled for publication in mid-June, I regretfully shelved it and spent what little time that remained in preparing for a move. Luckily, the move is over, and you now hold the newest issue of this publication. With this newest issue comes some notes. My wife, Julie, has graciously agreed to offer her services as assistant editor. This will free some of my time to write articles and concentrate on technical article editing. In our quest to find capable writers to author the columns found in each issue, Geoffrey Welsh is now writing "FIDO's Nuggets". We encourage others to help out in this way. Finally, due to the delay in publishing this issue and the length of some submissions, this issue is far larger than our maximum desired size. We apologize for those who will find the excessive size a problem, but the timeliness of the articles and the sheer volume of current events information prevented reduction in size. We will return to a more manageable size by next issue. As well, we created a professionally laid out and printed version of Commodore Hacking Issue #12. If you would like one of these copies, please see "Commodore Hacking Information" (Reference: info) for more information. Enjoy YOUR magazine, Jim Brain (j.brain@ieee.org) editor ========================================================================= @(#)io: Input/Output Obviously, Commodore Hacking depends on the comments and article submissions from the Commodore community to flourish. Everyone sees the articles, but let's not forget those comments. They are very helpful, and every attempt is made to address concerns in them. Address any comments, concerns, or suggestions to: Commodore Hacking 10710 Bruhn Avenue Bennington, NE 68007 j.brain@ieee.org (Internet) @(A)c: So, You Think You're Fast Enough, Eh? From: Ralph Mason Dear C=Hacking, Keep up the good work with C=Hacking. I was just reading your article about the Super CPU and thought I would add my 2p worth. You noted that the SuperCPU appeared to be 21.79 times faster but attributed this to the VIC chip stealing cycles. I think this is only part of the story (the smaller part). I think the most cycles are likely to be lost or gained due to the jiffy interrupt routine. The standard 64 executed this routine 660 times and scanned the keyboard etc. during it's count from 1 to 10000. The SuperCPU only executed this code 31 times. Far more of its cycle was spent actually doing work. I think if you could turn off these interrupts you would find that the SuperCPU is actually running short of the 20 times faster than it appears to be showing. It's almost stooping to silly IBM style Norton SI numbers or other useless benchmarks. These will never show the true story. From what I've read, I'd guess (user's will see) a real world speed enhancement running real application of around 400%, more or less depending on the app. Cheers, -Ralph Mason @(A)r: Jim Brain replies, Ralph, after reading your explanation, I think you are correct in stating that the bulk of the time saved on a 20 MHz unit is indeed due to the fewer interrupts it must service in a given time frame. However, since we can rarely turn off the 60 cycle interrupt, the effective speed is what people will notice. Also, while I think you are correct on this discussion waxing philosophic, I believe most users should see more than 400% increase in applications. Of course, YMMV (Your Mileage May Vary). @(A)c: A Round of Ice Water for the Editors From: drankin@crashb.megalith.miami.fl.us (Dave Rankin) Thank you for all your efforts and putting out this Mag. I and many others do enjoy seeing all this activity for the 8 bit Commodore. Dave @(A)r: Thanks for the letter. We always enjoy knowing that the hours we spend producing this magazine are appreciated by those in the community that read it. @(A)c: There's Nothing Like the Real Thing, Baby(tm) From: cjbr@gonix.gonix.com (Jim Lawless) Dear C=Hacking, Just wanted to express my enthusiasm for your electronic publication and hope to make regular contributions in the coming months. I was a C64 hacker from '84 until about '87 when I progressed throughout the Amiga and into the PeeCee world. I found out about the C64 emulators for MS-DOS/Windows...etc. and downloaded one this morning. It was a great feeling seeing the '64 startup screen again! My wife expressed some curiosity seeing a pile of old Transactor magazines next to the recliner today. I told her how excited I was about the emulator. This evening, she returned from a church auction with a C128, a 1541, a 1650 modem, a westridge mode, and a bundle of software all for $30.00. I guess it's time to get back to my roots and have some fun! Jim Lawless, cjbr@gonix.com @(A)r: We appreciate the thanks. In addition, we always encourage Commodore enthusiasts to submit articles to the magazine. However, we are most grateful that you have come home again. While emulators have their downside, we have noticed that many who download one end up buying a real machine and rediscover the simple elegance of the Commodore computer. We applaud you for your choice. @(A)c: Copy Rights! From: EricJ1@aol.com I'll make this short and sweet. But, I have to tell you, I love C= Hacking. I'd like to post this as a public bulletin on my BBS if it is not a problem. Thanks Eric @(A)r: We encourage redistribution of Commodore Hacking for non-profit means. Simply read the guidelines in the issue's legal statement (Reference: legal). As long as the conditions in that guide are met, we would love to see C=H spread throughout the Commodore community. ========================================================================= @(#)news: Newsfront @(A): ACE Release #15 ACE-15 Programmer's Reference Guide For those of you who have taken advantage of the Advanced Computing Environment (ACE) operating system written by Craig Bruce, Craig has published the programmer's reference guide for Release #15 of this popular application environment. It is available in the following locations: ftp://www.csbruce.com/pub/cbm/c128/os/ace/ace16-prg.txt http://www.csbruce.com/~csbruce/ace/ If you haven't used ACE before, you should give it a try. @(A): Unscientific Study Proves Commodore Computers are Preferred! It seems that as homely as some may think the Commodore computers are, children warm up to them very quickly. In fact, the machines are chosen over more expensive machines, as the following stories attest: James Grubic (grubic@avicom.net) wrote: One of the teachers in the school I'm based in actually enjoys using the older computer systems like the Apple IIe, and her students are truly excited about using them. The other day, I gave them a 64c to use, and they were blown away! If you could just see it...a whole gang of youngsters gathered around the C64, waiting for their turn at Jupiter lander...almost brought tears to my eyes. Needless to say, I'll be arranging for them to get another one. And Bob Masse followed up with: I am not surprised. My little nine year old nephew has a brand new pentium beast with all the goodies, and he is scared to be in his room alone with it when it is on! On the other hand when He comes over to his Uncle Bob's house he has a tantrum to use this old Commodore. Bob kh6zv9@pe.net So, once again, bigger is not always better! @(A): Assembly '96 Is Coming! Have you ever been to a "demo party"? Well, if not, you are missing one of the staples of the Commodore scene since the beginning of the reign of the Commodore computer. Assembly is one such party held in Helsinki, Finland. In case you aren't aware, demo parties are where demo programmers, computer graphics artists, and computer music artists gather to compete for prizes. Assembly '96 holds parallel competitions for PC, Amiga, and C64 computer systems. Assembly '96 is to be held August 16 to 18 in the Helsinki Fair Center, Rautatielaisenkatu 3, Finland. Tickets are available for US$50.00. If you are in the vicinity, you should stop by and peruse the 1996 Commodore 64 entries. If, however, you would like to compete in the Commodore 64 class, please read the rules and information packet at: http://stekt.oulu.fi/~mysti/the_sharks/ Prizes of cash are to be awarded to 1st, 2nd, and 3rd place winners in the demo, graphics, and music categories. For more information, you can contact the organizers via the following ways: Voice: ASSEMBLY Org. +358-0-777 3741 WWW: http://www.assembly.org/assembly96 E-mail: assembly@assembly.org IRC: #asm96 Normal mail: ASSEMBLY '96 Lakkisepantie 13 00620 Helsinki FINLAND @(A): Where in the world is Novaterm 9.6 (NovaRom)? Late last year, Nick Rossi informed the Commodore community that he was developing a new version of his popular 64 terminal emulation software, Novaterm 9.6. However, Nick stated that 9.6 would be marketed as a commercial product, not as a shareware offering as in previous versions. Well, as with all announcements, speculation as to what the new version would include filled up the communication channels for quite a while. Then, in early 1996, the news that Novaterm 9.6 was to be marketed on CARTRIDGE surfaced. Nick cited concerns over piracy and ease of use in deciding to try the cartridge route. Users who asked were told that Novaterm (NovaRom by some accounts) would ONLY be offered as a cartridge. Performance Peripherals Inc. (PPI) was chosen to manufacture and market the new version. Tentative offering included the basic cartridge and an option that included PPI's CommPort Swiftlink-compatible cartridge and a PPI 3 slot cartridge expansion unit. Since creating a cartridge requires a higher level of code robustness, delays in the introduction generated reports that Nick was having trouble getting the code to a ROMable state. Other reports mentioned that PPI status as a part time endeavor was the reason for the delays. Whatever the reason, the following announcement was made by Nick Rossi concerning Novaterm 9.6 on July 5, 1996. Contrary to earlier reports, the software will be available on disk format only and will be initially be marketed directly through Nick Rossi: NOVATERM 9.6 ------------ Bring the telecommunications revolution to your Commodore 64. After many delays and headaches, I'm excited to finally announce the release of Novaterm 9.6! Novaterm 9.6 is available ON DISK, in either 1541 or 1581 format. It comes with a 90-page user's manual. The price for the disk and manual is US$29.95. ORDERING INFORMATION Send check or money order for US$29.95 to: Nick Rossi 10002 Aurora Ave. N. #3353 Seattle, WA 98133 U.S.A. INTERNET CONTACTS Check out the Novaterm 9.6 web site for more information: http://www.eskimo.com/~voyager/novaterm.html My e-mail address is voyager@eskimo.com. NOVATERM 9.6 FEATURES Novaterm 9.6 supports the following new features: * Zmodem upload, download, auto-download, and crash recovery. Also supports streaming mode with the buffer. * Ymodem-g and Xmodem-1k-g streaming protocols with the buffer. * Use any RAM expansion device as the buffer: REU, BBGRam, GEORam, RAMLink or RAMDrive partition, C128 VDC memory. * "Buffer recovery" feature retains contents of the buffer between Novaterm sessions as long as the memory device does not lose power or get overwritten. * Text editor can read and write files directly from the buffer. * Supports the SwiftLink, CommPort, HART cartridge, and Daniel Dallmann's 9600 bps user port enhancement (see http://rpool1.rus.uni-stuttgart.de/~etk10217/proj.html). * Supports the C128's fast-mode 80-column screen in terminal mode (25, 28, 43, and 50 line modes available). * C64 80-column emulation features "scroll-ahead" for better scrolling performance. Optionally supports a fast scroll if you have an REU. * Built-in ASCII translation and UUencode/decode options * Built-in 80-column file viewer * Reads real-time clock devices (BBRTC, CMD drives) for terminal mode clock display * Single-menu loading of terminal emulations (finally!) * A step-by-step user-friendly configuration utility Novaterm 9.6 still supports the basic feature set: * Terminal emulations: ANSI graphics, VT100/102, VT52, Standard, and Commodore graphics in 40 or 80 column mode * Protocols: Zmodem, Ymodem batch, Ymodem-g, Xmodem-1k, Xmodem-1k-g, Xmodem-CRC, WXmodem, Kermit, Punter, Multi-Punter * Hardware flow control for high-speed modems * Script language for automatic operation * Multiple 19-entry phone books * 16 user-definable macro keys * Miniature BBS module / answering service * Text editor utility with integrated script compiler * ASCII table editor and Font editor utility I could keep going, but you get the idea! Novaterm 9.6 supports all of the standard features from previous versions, but its capabilities have been greatly expanded. Thanks for all the support and suggestions -- the new version finally made it! @(A): BBS Magazine dead, Long Live Some Trees Gaelyne Moranec, writer of articles for magazines such as Commodore Hacking (Reference: uqwk), Commodore World, and BBS Magazine, reports that BBS Magazine is no longer. Cited as a magazine for BBS operators and users, the magazine contained a monthly series by Moranec on Commodore BBS users and systems. Being one of the few magazines not Commodore specific to cover Commodore content, its demise is sad indeed. Evidently, the magazine continued on for one issue as _BBS.NET_ but has not been published since. Some of the writers for BBS will be given space in a new magazine to take the place of BBS, but the focus will be on sysops and sysadmins. Gaelyne hopes the new magazine will allow her to continue to write, but she is somewhat doubtful of the prospect. @(A): Hide the Wolf PC: Little Red Reader-128 2.5 released! Craig Bruce has released version 2.5 of Little Red Reader-128, the popular freeware utility that allows Commodore 128 owners with 1571, 1581, or CMD FD drives to read IBM PC disks. Features available in the new release include: * miscellaneous bug fixes * date support for reading and writing files * counts of bytes of files in a directory * remove Commodore files The program is available from the following locations: ftp://ftp.csbruce.com/pub/cbm/c128/utilities/lrr26.uua (uuencoded archive) lrr26.doc (documentation) lrr26.asm (assembly source) http://www.pobox.com/~csbruce/commodore/lrr/ @(A): Basement Boys Software Demise The geoClub UK newsletter reports that Commodore software developer and distributor Basement Boys Software has ceased operation. Fortunately, Basement Boys Software completed all paid orders and settled all reported business before closing its doors. While we regret the closing due to "lack of support", we are impressed with the ethical methods of doing so. @(A): LOADSTAR LETTER Going Subscription As reported in "Hacking the Mags" (Reference: mags), LOADSTAR LETTER will become a subscription based publication. The LETTER, currently bundled with issues of LOADSTAR and LOADSTAR 128, contained 8 pages of additional content not found in either LOADSTAR or LOADSTAR 128. J and F Publishing, which publishes the LOADSTAR line of software and magazines, cites increasing costs and the need for more editorship support in deciding to change the magazine's status from free to subscription. The LETTER will be bundled with the disk magazines until Issue #37. A one year subscription can be purchased for US$12.00 from: LOADSTAR Letter P.O. Box 30008 Shreveport LA 71130 Starting with Issue #37, Jeff Jones will join with Scott Eggleston and others to turn the LL into a more hard hitting magazine with fewer ads. The new magazine will continue to run articles by Jim Brain, Gaelyne Moranec, and Jeff Jones, among others. J and F is trying to break 1000 subscribers in order to keep the subscription rate for future subscribers at US$12.00. @(A): The Commodore Cruiser Is on the InfoHighway John Brown, of Parsec, Inc., has announced the arrival of the Commodore Cruiser, a subscription based Commodore support BBS system. Accessible via direct phone lines and the Internet, The system is Internet accessible via a telnet to jbee.com. John is offering a free account to each Commodore User Group that requests one. For users, subscription includes full Internet access, as well as Commodore specific areas and file transfer areas. For more information, contact Parsec at: JBEE Parsec, Inc. PO Box 111 Salem, MA 01970-0111 USA @(A): Commodore and Amiga Technology Sold (Again!) By InfoWorld Staff Posted at 3:45 p.m., PT, April 11 Financially troubled German PC retailer Escom AG said Thursday that it will sell its Amiga Technologies GmbH subsidiary to Visual Information Services Corp. (VIScorp) of Chicago in a $40 million transaction. SEscom acquired the Commodore and Amiga computer technology, patents, Sintellectual properties, and brand names in April 1995 for $10 million Sat a bankruptcy auction for Commodore International, which filed for Sliquidation in 1994. Escom earlier this year itself reported losses of S$85 million for 1995, prompting founder Manfred Schmitt to resign last Smonth. Selling Amiga will allow Escom to better concentrate on its core Sbusiness of PC retailing, Escom said in a statement. VIScorp, which Smakes set-top boxes, will acquire the Amiga and Commodore technology and Sintellectual property, but not the Commodore brand names, Escom said. VIScorp is online at: http://www.vistv.com @(A): DisC=over a New Commodore Specific Technical Magazine As reviewed in "Hacking the Mags" (Reference: mags), there is a new Commodore publication available. Citing itself as the "The Journal for Commodore Enthusiasts", DisC=overy contains technical content analogous to that found in the defunct Transactor magazine and Commodore Hacking. Available only in text format, the magazine is available at: http://www.eskimo.com/~drray/discovery.html Alternately, the magazine can be requested via email from: s021126@dominic.barry.edu @(A): CMD SuperCPU unveiled Initial reports of the CMD SuperCPU are overwhelmingly positive. In fact, it is reported that one European publication would not believe a commissioned review of a beta unit and requested a first hand look at one before they would print the review. Suffice it to say they were impressed as well. For a report that Guenther Bauer wrote on the new accelerator, check out his review at: ftp://ftp.giga.or.at/pub/c64/Super64CPU_test.txt One of the units traveled to Michigan where Maurice Randall (developer of GeoFAX and owner of Click here Software) debuted it in the US to the Lansing Area Commodore Club. Tim Lewis, LACC President, reported to USENET after the debut: "I am one of the few lucky people who have seen for myself what the new Super64 CPU can do. It is nothing short of INCREDIBLE!!! For all of you serious GEOS users, I can honestly say this: GET IT! It is money that will not be thrown away! The processing speed is amazing. If you use the Super64 CPU with a REU, I will guarantee you that you cannot go wrong! You have to see it to believe it! Club members that saw Maurice Randall demo this could not believe their Seyes! I was watching this go thru a directory of files, and it just Sflew! Folks, you have to see this to believe it! My hats off to CMD, they have really outdone themselves! All I can say is: (sic)COGRATULATIONS!!!" For more information on CMD or the SuperCPU, contact CMD or visit their WWW Site: Creative Micro Designs, Inc. P.O. Box 646 E. Longmeadow, MA 01028 (413) 525-0023 http://ww.the-spa.com/cmd/ @(A): Commodore Hacking Contributes to Computer-Mediated Communication Magazine Following a call for articles in alt.zines on hurdles faced by electronic magazines, Jim Brain contributed an article on the challenges faced by Commodore Hacking. Brain, editor of Commodore hacking, cited the challenges of providing a text version of the magazine for Commodore owners, while attempting to draw out of the closet Commodore enthusiasts online with a hypertext version of the publication. The full text of the published article is available at: http://www.december.com/cmc/mag/1996/may/brain.html @(A): "Zelch" Down for the Count In C=Hacking #12, we noted that Bo Zimmerman had connected his Commodore 128 to the Internet, albeit through a Linux system. Well, as all good things must end, Bo has taken down the BBS system due to hardware overheating problems. However, Bo hopes to provide documentation on how the system was set up so that others can configure similar systems. @(A): The "Official" DesTerm WWW Site In March, Matt Desmond, creator of the popular 128 terminal emulation program DesTerm, announced that he is now online at: http://www.ionline.net/~mdesmond It contains information about Matt, but is more importantly the gateway to the "Official DesTerm Page." The site contains information about the new 3.0 version of DesTerm that Matt is developing. @(A): Compuserve INformation Service = Compuserve Internet On May 21, Compuserve (CIS) announced it would phase out its proprietary software and services in favor of providing service using Internet standards. The company hopes to re-launch itself as an Internet provider by year's end. The new service will be accessible through a standard World Wide Web browser. It is unclear how this change will affect Commodore users who rely on Compuserve's "shell" access for Internet and Compuserve specific access. @(A): Creative Micro Designs, Inc. New Sponsor of Genie CBM RTC Creative Micro Designs, Inc., has taken over as the sponsor of the Commodore RTC area on Genie. The Commodore RTC remains one of the few well utilized places to stay current on Commodore events and find Commodore information. CMD cited an interest in providing quality information for Commodore enthusiasts as a driving reason behind the decision to sponsor the Genie forum. @(A): Hail the New Prez Meeting 64/128 Users Through the Mail, a non-profit organization designed to allow Commodore users to unite and gather information about their machines via mail, has announced a change in presidency: The new president is Tom Adams, and the new address for club correspondence is as follows: Meeting 64/128 Users Through the Mail c/o Tom Adams, President tom.adams@neteast.com 4427 39th St. Brentwood, MD 20722-1022 If you are interested in membership, please contact Tom. The club is especially useful for those who live in areas with no Commodore support. @(A): Commodore VIC-20 Newsletter Address Change For those interested in the Commodore VIC-20, a very useful but under utilized computer, Jeffrey Daniels publishes a newsletter for the machine. The publication address has changed to: Vic Newsletter Jeff's Ink Press & Deli P.O. Box 477493 Chicago, IL 60647 USA Jeffrey Daniels, editor U17632@UICVM.CC.UIC.EDU A copy can be obtained by writing the above address. @(A): ESCOM Does a CBM! (Well, Not Really) Financial Time/Edupage: July 4, 1996 "Escom, the German company that is one of Europe's largest PC retailers, is seeking protection from its creditors (similar to Chapter 11 protection in the U.S.), following significant trading losses, and losses caused by a stock write-down. Aggressive expansion into new markets such as the U.K. had caused storage and supply problems." Since ESCOM had recently sold the rights to the Commodore and Amiga lines to VISCorp, the filing will have little affect on Commodore 8-bit owners. Also, CMD reports that this action is part of a massive reorganization effort by ESCOM intended to solidify its PC manufacturing operation. CMD notes that, unlike CBM, ESCOM is NOT liquidating, but merely employing a common US business tactic of filing to shield themselves from creditors while reorganinzing the business. ========================================================================= @(#)trick: HEAVY MATH - Part 0: History, Arithmetic, and Simple Algorithms by Alan Jones (alan.jones@qcs.org) Someone on comp.sys.cbm asked if the C64 could do HEAVY MATH, meaning solve computationally intensive numerical problems. The answer is of course, YES! This is the first of a series of articles on numerical computing for the C64/128. @(A): Introduction The C64 is not the best computer for numerical work. However, it does quite well within its limitations of speed and memory. It is fine for most homework and hobby related problems, but not for big industrial problems. It does not bother me at all to let it crunch numbers while I watch a movie or sleep. Those old commercials about sending your children to college with a C64 were a joke. Still, it can save you a long walk to the campus on a miserable night. And you can always use it as a terminal to check jobs running on the mainframe. The C64 is also a good computer for developing numerical algorithms and programs. You can try new ideas and write programs at your leisure at home with a C64. When developed to your satisfaction, algorithms and programs can be "ported" to bigger and faster computers to solve larger problems. The C64 has many programming languages available, although many are not well suited for numerical development work. On larger computers Fortran and C are popular for numerical work. On a C64, Power C might be a good choice for some users. I use COMAL 2.0. I also have COMAL programs that can help convert source codes from BASIC to COMAL, and COMAL to Fortran. Our C64 with its 6502 (6510) and 64K of RAM is a very simple machine. It is so simple that many contemporary numerical programs are far from ideal on a C64. So I will start with a bit of numerical computing history. Early computers and the numerical algorithms that they used are often closer to ideal for the C64 than contemporary PCs. Researching old numerical algorithms can be useful for the C64; e.g. Quartersolve in C-Hacking #10. Of course new algorithms are useful also and sometimes you might want to combine ideas from both sides of the spectrum. @(A): History In the beginning... were fingers. Seriously, "computer" was a human job description. These days, human computers are just an oddity seen on TV talk shows. The invention of logarithms was a big boon, and log tables and slide rules were just the start of computational aids. Eventually, mechanical adding machines were developed for high precision, error free (but slow) numerical work. One can still find large desk top Friden and Monroe mechanical adding machines. Numerical work was still a slow tedious process. More computing tools were developed. The Differential Analyzer was a mechanical computer that could solve IVPs (Initial Value Problems, integrating differential equations). There were also some early analog electronic computing aids. The first electronic analog computer was actually developed after electronic digital computers. (One could argue that many WW II autopilots and automatic control circuits were electronic analog computers.) The first digital electronic computers were the ABC, ENIAC, EDVAC, and UNIBLAB. (UNIBLAB is just for the Jetson's fans. ;) ) John Vincent Atanasoff invented the first digital electronic computer at Iowa State University. (So if someone answers the phone and says, "He's on the John. Can he call you back later?" It might not be mean what you first think.) Clifford Berry, was a grad student and chief technician, hence the Atanasoff-Berry Computer, or ABC. The Atanasoff story is fascinating. See: The First Electronic Computer: The Atanasoff Story, Alice R. and Arthur W. Burks, The University of Michigan Press, 1988. Atanasoff wanted to be able to solve large sets of linear equations. Even with large mechanical adding machines, solving a 10 by 10 problem was about the largest size that would be attempted. Schemes to connect several mechanical adding machines were not feasible, and analog devices were not precise enough. He was working at a small university and the small grants available to him were a serious constraint. He developed the ABC over a couple years for less than $7,000. The ENIAC would later cost about $500,000! Atanasoff invented a way to use electronic vacuum tubes as high speed digital switching devices. He then invented a serial arithmetic logic unit, ALU. Vacuum tubes were still too expensive so he used cheap capacitors for memory. He invented additional circuitry to refresh the capacitors, i.e. dynamic RAM. He designed a parallel computing machine that could add (and subtract, shift, NOR,...) 30 50-bit binary numbers using 30 modular ALU units. This allowed it to solve up to 29 linear equations with one right hand side vector. The design could easily be scaled up in size and precision. It used scratch paper for I/O and temporary memory. (Created in man's image?) The card punch/reader was the limiting factor. Mechanical punches, like (then) new accounting machines might use, were too slow. An electronic spark punch was developed. A dielectric material (paper) was placed between electrodes. A high electrical voltage would carbonize a dot in the material and actually burn a small pin hole. A smaller voltage would later test for the mark. This was actually Berry's project. It had decimal to binary and binary to decimal conversion for initial and final I/O, as well as other nice touches. Atanasoff also developed a variation of Gaussian elimination for solving the linear systems of equations with the ABC. The ABC, like our 6502, has no multiply instruction. The ABC had capacitor memory to hold two rows of equations. Multiplication was done with shifts and adds, but whole rows were computed in parallel. Fixed point binary arithmetic with truncation (no rounding) was used. However, it provided 50 binary bits of precision which was more than the adding machines provided. It used no division. The result would be printed (punched) out in decimal as two integers that would be divided on a mechanical desk calculator for each variable. His numerical algorithm may be useful for our 6502, although I'm sticking with the slower floating point arithmetic. It was not a general purpose "stored program" computer, but it could have been adapted to solve a variety of problems. The ABC was completed and operational in April or May of 1942 except for one problem: The card punch reading was not reliable. The problem may have been the dielectric material or choice of paper. A 5 by 5 problem could be reliably solved, but not the larger problems that it was designed for. The problem could have been fixed. However, Atanasoff and Berry were called to other WW II related work and not allowed to perfect the ABC. The ABC was stored and later dismantled. Ironically, the war that built the ENIAC killed the ABC. Of course many of John Atanasoff's original inventions were later used in the ENIAC and EDVAC computers. The ABC was built into a desk sized wheeled cart and could be transported to a researcher's "home." It cost less than $7000, but additional units would have been cheaper. The ABC was akin to our favorite low cost home computer. By contrast, the second computer, ENIAC, cost a fortune, required a team of technicians to operate, and filled a large room. The ENIAC led to monolithic computing centers. It would be decades before the computer returned to the home. I'll skip the better known history lessons: transistor > microprocessor > electronic hand calculators > home computers > C64 >... And of course the electronic computer caused an explosion in the development of mathematics and numerical algorithms. @(A): Arithmetic Arithmetic is the basic building block of numerical algorithms. There are many types of numerical variables and arithmetics. Binary arithmetic is the most efficient for intensive numerical work. Decimal arithmetic is best for simple math where conversion to and from binary would just slow down entering and outputting numbers. Floating point arithmetic is easy to use because it is self scaling and covers a large dynamic range, but it tends to be slow. Fixed point, e.g. integer, arithmetic is fast but not as easy to use. Interval arithmetic involves computing not just a rounded result but an upper and lower bound on the result to cover the interval of the arguments and the accuracy of the computation. PGP encryption uses a high precision modular arithmetic. Complex, quaternian, and vector arithmetic can also be used. The C64 built in BASIC provides 5 byte floating point variables and arithmetic and 2 byte integer variables. I think integer arithmetic is done by converting to floating point. Most of the programming languages for the C64 use the same numerical variable types and even the same arithmetic code. Even in assembly language we often call the same floating point arithmetic routines. The +, -, *, and / arithmetic operations on the C64 have no bugs. However, they appear to be coded for minimum code size rather than minimum execution time. Every type of computer arithmetic can be built up from the 6502 instruction set. Some arithmetics can be coded for specific applications such as Polygonamy in C-Hacking #12. My interest is in using the floating point routines with numerical algorithms and writing programs. Of course even floating point arithmetic routines are built up from smaller arithmetic blocks. The key building block is the multiplication of two positive 8 bit values into a 16 bit result. Our 6502 has no such instruction. The 6502 CPU was designed to be a low cost 8 bit CPU. It is fairly cheap to interface to and will quickly access cheap "slow" memory. It is also very quick and responsive to interrupts. It can perform 8 bit binary and BCD addition with carry. The Z80 CPU was designed to be the ultimate 8 bit CPU. It has several 8 bit internal registers which can be used in 16 bit pairs. It has a full instruction set that includes some nibble oriented instructions and a 16 bit add. On average a 1 Mhz 6502 is about as effective as a 2 Mhz Z80, and Z80s are generally available in faster speeds. The C128 has a Z80 CPU that could be used for numerical work, but it was poorly integrated into the C128 and offers us no advantage over the 6502 (other than executing CP/M and other Z80 code). Neither CPU has a multiply instruction. The fastest way to multiply with a Z80 is with the simple binary shift and add method. However, this is not true with the 6502! The fastest way to do math on a 6502 is by using table look ups. This opens the door for creative programming solutions. Tables can use up a lot of memory, especially for a function of two or more arguments. An 8 bit multiply table could eat up 128K of memory. A 4 bit, or nybble, multiply table would only need 256 bytes, but this would involve so much additional work to realize the 8 bit multiply that it is hardly worthwhile. The C64/128 multiplies with the slow binary shift and add method. However, it is not so slow that we can use disk or REU memory to speed up such a simple function (a large bank switched ROM would be much faster). The table look up method can be readily used when multiplying by a constant, such as when calculating CRCs. Now consider the algebraic identity, a*b = ((a + b)/2)_2 - ((a - b)/2)_2. With some more work we can do the multiplication using a table of squares of only about 512 bytes! (a + b) could overflow to nine bits, but we will immediately shift right one bit (the division by 2) so this is no problem. However, if (a + b) is odd the least significant bit is lost. This is easy to test for by doing a Roll Right instead of a shift and testing the carry bit. One way to compensate is to decrement a by 1 (a <> 0), multiply as above and add b, a*b = (a-1)*b + b. The decrement is free, but we pay for the extra add. Using 256K of external memory you could do a 16 bit multiply this way. For an example of the shift and add type multiply and divide see, "High- Speed Integer Multiplies and Divides", Donald A. Branson, The Transactor, Vol. 8 , No. 1, July 1987, pp. 42-43, 45. Note also that although a*b = b*a, the ordering of the arguments can effect the multiplication speed depending on the bit patterns. Perhaps a year ago there was a discussion running in comp.sys.cbm on ML routines to do fast multiplication. There was no clear best solution. Performance often depended on where the arguments a and b were and where the product was to be stored. This also affects how well these building blocks can be used to perform multi byte arithmetic. Division is a more difficult problem. It can be done by shifting and subtracting, table look up, and algorithms based on computing the inverse. Consider: a/b = exp(log(a) - log(b)). With tables of the logarithm and exponential functions (and you might want to use base 2) we can do division with three table look ups and one subtraction. The log and exp functions will have to be tabulated to a greater precision than the arguments and result, or it will only produce an approximation. In most cases we will still have to calculate the remainder using multiplication and subtraction. Of course with log and exp tabulated we can calculate fast approximations to many other functions, including multiplication. Stephen Judd used multiplication based on a table of squares and division based on a table of log and exp in Polygonamy in C-hacking #12. He reported that his 9 bit/8 bit divide takes 52 cycles "best case." However, where numerical algorithms are concerned, only worst case and average case performance are important. Double precision, and multiple precision arithmetic routines should be coded efficiently in assembly language using the fast building blocks suggested above. However double precision FP variables and arithmetic can be built using pairs of ordinary FP variables and arithmetic. This will be slow but it can be effective when used sparingly such as when testing single precision algorithms or using iterative improvement techniques. See, "Double Precision Math", Alan Jones, Comal Today, Issue 20, Feb. 1988, pp. 18-20, and Comal Today, Issue 22, May 1988, pp. 58-61. @(A): Numerical Algorithms An algorithm is a procedure or set of instructions for computing something. I am mainly concerned with HEAVY MATH algorithms, but here I will present only feather weight numerical algorithms. Consider the trivial algorithm, repeat x := (x + 1/x)/2 until converged This is a stable quadratically convergent algorithm. For any initial x <> 0 it will converge to sign(x), i.e. +1 or -1. Pick a number, say 1.5 and take a few iterations. Note how fast it converges to 1.0. The error or distance from 1 keeps getting squared down toward zero. The number of correct digits in each iteration doubles. This is the quadratic convergence. Pick another number such as 10_20 and try again. At each iteration the error is cut in half. We take giant strides but convergence is still painfully slow. This is a linear convergence rate. This is a typical Newton's method algorithm. Near the solution, inside the region of quadratic convergence, convergence is very fast. Outside the region convergence is much slower. On more complex problems convergence may fail altogether or converge to an undesired point. In general an algorithm will converge to a "limit point" and if the algorithm is numerically stable, the limit point will be very close to the exact solution intended. Although it looks like this algorithm could run forever like an infinite series, in finite precision arithmetic it always converges in a finite number of iterations, even from the bad starting points. This algorithm is not so trivial when applied to a square matrix (with no eigenvalues on the imaginary axis). It will compute the matrix sign function which can be used to compute the stable invariant subspace, which can be used to solve the algebraic matrix Ricatti equation, which can solve two point boundary value problems, and be used to solve linear optimal control problems. Not to mention other pseudo random buzz mumble... @(A): Inverse and Division The inverse x = 1/b can be iteratively computed from x := x*(2 - b*x). This is best used as a floating point, or multiple byte algorithm. This is a quadratically convergent algorithm. This means that each iteration should double the number of correct bits in x. You could use an 8 bit multiply and converge to an 8 bit solution from an initial guess. A better use would be to compute a 32 bit result (our floating point mantissa). We might start with an 8 bit estimate from x := exp(-log(b)) using look up tables, take an iteration using 16 bit multiplication (or 16 by 8) to get a 16 bit estimate, and take another iteration using 32 bit multiplication to get the final 32 bit result. Division can then be accomplished as a/b := a*(1/b). Of course this is only useful if you have fast multiplication. @(A): Square Roots BASIC 2.0 calculates square roots from x = exp(0.5*log(a)). This is slow since BASIC calculates the log and exp functions, and inaccurate as well. If you have these functions tabulated you might want to use them for an initial estimate of x. If you have a table of squares, the inverse function of the square root, you could use a search routine on the table. Square roots can be calculated iteratively from the Newton's method algorithm, x := (x + a/x)/2 One can also compute x = 1/SQR(a) using x := x*(3-a*x*x)/2 avoiding the division. E. J. Schmahl published ML code for computing the square root in "Faster Square Root For The Commodore 64" in The Transactor, Vol. 8, No. 1, July 1987, pp. 34-35. This used a 16 byte look up table to start, followed by Newton's method. He called the ROM FP routines to do the calculations, but variable precision arithmetic could also be used as suggested for the inverse algorithm. Another interesting algorithm for the INTEGER square root was recently published by Peter Heinrich, "Fast Integer Square Root", Dr. Dobb's Journal, #246, April 1996. This is a fast algorithm that uses no multiplication or division. It is not known yet if this is a good algorithm for the 6502. @(A): Algebraic Geometric Mean The AG Mean is our first real numerical algorithm, the others above are our arithmetic building blocks. Repeat a(i+1) := (a(i) + b(i))/2 b(i+1) := SQR(a(i)*b(i)) until converged For 0 < a(0) <= 1 and 0 < b(0) <= 1 the sequences converge quadratically to their common limit point, the AG mean of a(0), b(0). Note that we need to use full precision from the start and an accurate square root routine. The BASIC 2.0 SQR routine is not accurate enough. This can be used to compute the complete elliptic integral of the first kind, K(k). With a(0) = 0 ,and b(0) = SQR(1-k_2), K(k) = PI/(2*a(n)). The AG Mean can also be used for some other computations @(A): A Caution Many mathematical equations can be found in math books and similar sources. However, these are often in a form for ease of typesetting and further algebraic manipulation. They should not generally be coded as written. For example, the well known quadratic equation is the best way to compute the roots of a second order polynomial equation. However, there is a particular way to code it to avoid overflow, underflow, and loss of precision. There are also analytical expressions for the roots of third and fourth order polynomial equations. However, roots of third and higher order polynomials are best solved for using general root finding techniques. @(A): Conclusion This article is long on discussion and short on usable code. Although it suggests faster ways of performing arithmetic on a C64, the built in FP +, -, *, and / routines are reliable and can used for serious computations. If I continue this series, I would want each article to present source code for solving a numerically intensive problem. In Part 1, I present an introduction to Linear Programming. Hopefully other topics will be suggested by readers, and possibly articles will even be written by other users. Of course I could also write articles on numerical methods, or turn this into a simple question and answer column. I suspect many readers have already written many HEAVY MATH C64/128 programs but have not shared them with the Commodore user community yet. ========================================================================= @(#)mags: Hacking the Mags Not everything good and/or technical comes from Commodore Hacking, which is as it should be. (We still think we have the most, though...) Thus, let's spotlight some good and/or technical reading from the other Commodore publications. If you know of a magazine that you would like to see summarized here, let C=Hacking know about it. These summaries are only limited by Commodore Hacking's inability to purchase subscriptions to all the Commodore publications available. We are very grateful to those publications that send complimentary copies of their publications for review. @(A): Commodore Gazette This new introduction is published by Commodore Gazette Publications, and is NOT related to COMPUTE's Gazette, in case you are wondering. In Volume 1, Number 7, editor Christopher Ryan mentions the above fact, as it seems some upset COMPUTE'S Gazette subscribers were calling him. In this issue, you will find some detailed instructions on installing CMD's JiffyDOS, as well as how to turn your 64 computer into a 128 (I should mention this was the April issue). Kenneth Barsky provides some handy tips for BASIC programmers, including one involving the append mode of CBM disk drives. Overall, the fare is a bit light, but is pleasing. @(A): Commodore World (http://www.the-spa.com/cmd/cwhome.html) In the continuing saga of the funky graphics, Jenifer Esile, who made a good share of them, has resigned from editorship of Commodore World. We hope it isn't something we said :-). Anyway, CW has hired a new assistant editor, and two new issues have rolled off the press. Doug Cotton, the editor of CW, mentioned that Issue 13 was a nightmare. I guess even CMD falls prey to the superstitious number. No matter. For those wanting to learn more about the World Wide Web and HTML, Katherine Nelson presents an article on how to use this presentation markup language to develop exciting WWW sites. A glimpse of the Commodore LCD computer is given, and Doug Cotton presents his RUN64 loader, also presented in the last issue of C=H. For those who are anticipating the new release of Novaterm, Gaelyne Moranec interviews Nick Rossi, the author of Novaterm. Issue 14 follows up on the HTML tutorial by Katherine Nelson. Since Commodore software is developed on many computer platforms, Doug Cotton presents an article on transferring files between dissimilar computer systems. In the reference department, clip out the User Group list compiled in this issue. Obviously, you don't need it, but it's something to send the clueless person who calls asking for help. Jim Butterfield shows how to get some input into your ML programs, and Maurice Randall delved into the VLIR file format used in GEOS. @(A): DisC=overy (http://www.eskimo.com/~drray/discovery.html) Subtitled "The Journal of the Commodore Enthusiast," this recent publication introduction debuted online on May 17. Available in electronic format, like C=H, this is a magazine Commodore Hacking readers won't want to miss. Issue #1 includes articles by Stephen Judd on VDC timing, by Nate Dannenburg on constructing an 8-bit analog to digital board, and by Mike Gordillo on upgrading the 16kB 128 VDC to 64kB. Other articles include a discussion on George Taylor's new Tri-FLI technique, an overview of CP/M, and a look at ModPlay 128. Commented source is included for many of the articles, and the technical details are not spared. The layout is similar to early issues of Commodore Hacking, but more attention is paid to consistency throughout the issue. In addition to the issue itself, there is a WWW Site devoted to the magazine: (http://www.eskimo.com/~drray/discovery.html). Still uncertain here at Hacking Headquarters is the publication cycle for this new arrival, but we hope it finds an eager audience. The editors are certain that there is room in the Commodore publication arena for DisC=overy and more magazines like it. @(A): Driven (http://soho.ios.com/~coolhnd/) Issue #13 contains a good review of the 1541-DOS package from Bonestripper. For those who don't know, 1541-DOS allows your 1541 to read and write a disk format that can be read on IBM 5.25" floppies. Iceball presents a reality-check for the demo scene, while Tao discusses some ideas to help developers write graphics-format independent code. Even if you don't develop graphics code, you should read this article and heed its warnings. Failing to test NTSC code on PAL machines or vice versa can impact the usefulness of your application. A little extra effort in development can pay off in the end. Finally, Tron presents some more information on Internet Relay Chat (IRC), including how to use its features. Eclipsing the last issue, Drive #14 offers a wealth of information. Nate Dannenburg presents information on ModPlayer 128, while Guenther Bauer reviews the new CMD 20 MHz SuperCPU accelerator. Nate describes some of the theory behind creating digital music and how it can be done using a Commodore 64. Lastly, Issue #14 presents a transcript of the Genie roundtable discussion on the 64 and its place on the Internet. @(A): LOADSTAR (http://www.loadstar.com) Issue 142 brings us Fender's proposal for dealing with the glut of good software languishing in the closets of those who have forgotten it sits there. Adam Vardy presents a screen saver appropriately described as "a screen saver for a computer that doesn't need one." Of special mention on this issue is Terry Flynn's SYSARCH, a handy 14 screen reference guide containing PRG info at the touch of a key or two. For those who have flipped through the 64 PRG enough to wear out the binder, this might provide some relief. In Issue 143, Jeff Jones presents the nuts and bolts behind LOADSTAR's text packing routines, while CodeQuest '95 silver medal winner Paul Clark offers a handy LIST wedge that allows forward and backward BASIC listing scrolls. Paul's wedge even allows searching. That's a neat twist for you BASIC programers. For those who don't regularly use GEOS but are given graphics in GEOPaint format, Saimak Ansari provides a utility that will allow you to view and print them without GEOS. By far the most technical of the 3 reviewed, issue 144 contains a number of helpful utilities. One, called Menu Toolbox II, allows the programmer to create useful and functional user interfaces with a minimum of effort. Jeff Jones, the author, has rolled an extensive list of user interface controls into this package. Additionally, Ken Robinson presents some bug fixes and enhancements to Jeff Jones' Static Array System, a package that allows programmers to treat RAM like a relative file. @(A): LOADSTAR 128 (http://www.loadstar.com) For all the Dave's Term folks, Issue 31 presents the 5th and final installment of the 128 terminal program. Bob Markland presents his RANDOM 2-254 program that one can use to create random numbers. In addition, Bob presents RLE 128, a utility to Run Length Encode (RLE) fines to make them smaller. RLE packing is especially useful for text screens and other files with repeating symbols. Fender Tucker notes in the introduction that many new 128 titles are arriving for publication, and he mentions that Mr. Markland will be taking charge of more aspects of this publication. We hope he enjoys it. @(A): LOADSTAR LETTER (http://www.loadstar.com) We have decided to break LL out from the LOADSTAR reviews because J and F Publishing has recently decided to make LL a separate product. The details are in LL Issue #34. The publication will continue to be free of charge until #37. In LL #32, LOADSTAR introduces two more editions in its "Compleat" line. The Compleat Crossword offers what the name inplies, while The Compleat Jon presents 11 previously published Jon Mattson games in one compilation. Jeff details a particlularly nasty bug that he worked around in The Compleat Crossword. He invites savvy folks to figure out the problem. In the reference department, most will want to archive Jeff Jones' Introduction to Machine Language. Oh sure, it won't teach YOU anything new, but the tables are sure nice to have if, perchance, a friend ever forgets the addressing modes for some opcode. Lastly, Jim Brain presents part 5 of the Internet series. LL #33 showed up with a revamped look. The publication now has a professional front splash graphic, and the style has evolved. We are impressed with the new look. Of notable mention is the preliminary information on the CMD SuperCPU and its compatibility. A discussion of BASIC compiler pitfalls and problems follows. Every programer should read and re-read the article on how to write applications that work on machines with "old" ROMs. The problems are so simple, but neglicting them ruins a perfectly fine app on an old 64. If you haven't figured out how to access RAM under ROM and I/O at $D000, there's some functions in the issue to do that as well. In LL #34, we learn the new email address for LOADSTAR email: jeff@loadstar.com. The issue also mentions LOADSTAR's WWW address: http://www.loadstar.com and notes that it will be the "coolest C64 site on earth." Well, we'll see about that, but credit is due for the attempt. In this issue, LOADSTAR notes the impending change of LL from free to subscription based, and some more information on the SuperCPU is related. For those in the demo scene, you'll be pleased to know that Driven will now be distributed on the 3.5" version of LOADSTAR. Gaelyne Moranec and her WWW site is spotlighted, but the most newsworthy information in this issue is the mention that Byte magazine recently recognized the 6502, the SID, and the Agnes/Denise/Paula chips as some of the 20 most influential ICs in the computer industry. Although LL will appeal to the beginner to intermediate Commodore user with current events information, we are pleased to see numerous code fragments and technical discussions interspersed with the lighter fare. For $12.00 a year, don't pass it over without a look. @(A): The Underground Commodore Hacking would like to thank the anonymous Underground reader who donated a subscription so that we can review this magazine for our readers. We appreciate the donation. With our first issue, Scott Eggleston has changed the format of the publication a bit. Citing problems with reproduction of the smaller format and printing woes, The Underground gains a whole new larger format look with Issue 13. For those developers considering a CMD hard drive purchase, Disk Estel reviews an HD-40. Two Internet related articles surface in this issue, as Mark Murphy explains some of the technology of the Internet, while Disk Trissel details the File Transfer Protocol (FTP). A full complement of columns and departments accompany each issue as well. The Underground covers beginner to intermediate material and uses GEOS to publish each issue. Digitized photos make frequent appearances, and the content is top-notch. Other magazines not covered in this rundown include: * _64'er_ * _Atta Bitar_ (_8 bitter_) + _Bonkers_ + _Coder's World_ + _COIN!_ o _Commodore 64/128 Power User Newsletter (CPU) o _COMMODORE CEE_ * _Commodore Network_ * _Commodore Zone_ * _Gatekeeper_ o _Vision_ Notes on Legend: * = We have never received an issue of this publication. o = We have not received a new issue of this publication to review. + = We will begin reviewing this magazine in the next issue. In addition, others exist that C=Hacking is simply not aware of. As soon as we can snag a copy of any of these, or get the foreign language ones in English :-), we will give you the scoop on them. ============================================================================ @(#)os: OS/A65 - a Multitasking/Multithreading Operating System for 6502 Computers by Andre Fachat (a.fachat@physik.tu-chemnitz.de) http://www.tu-chemnitz.de/~fachat @(A): Introduction In 1989, I first thought about building a self-designed computer. I already had some experience with 6502 based computers. A friend of mine and I had been trying to build a telephone line switch computer based on the 6502. Although the project never succeeded (well, to a certain extent it worked, but then we always got new ideas...), the project gave me an idea of what an OS should be capable of. With my homebrew computer, I not only wanted to implement one of those 'simple' OSes as in the C64 or other 6502 based computer, but I also wanted to go a step further and do a real multitasking, microkernel design OS. This constrained the hardware design to allow memory mapping of key memory locations, including the 6502 zero-page and stack. @(A): What Should a Real OS Do? A real operating system has four major parts that handle the input/output, filesystems, memory management and process handling. At the very least, a "real" OS includes some form of multitasking :-) Process management forms one block of an OS. A multitasking operating system requires more administration than a single-tasking OS. A process, or task, can be seen as a set of allocated resources. These resources include memory pages, swap pages, open files, and even the CPU, if the task is active. The CPU is the processing element that executes the given program using the allocated resources. Therefore, the CPU state has to be saved if a task is interrupted. This allows undisturbed continuation after the interruption is handled. For each task, the allocated resources have to be registered and freed. As the CPU can be allocated to only a single task at a given time, it must be shared among all the active processes. So, in order to create the illusion of executing multiple processes at the same time (pseudo-parallelism), the CPU has to be assigned to one task after another, at a speed that achieves this illusion. If the assignments happen too slow, the illusion is lost, but if the speed is too fast, the CPU spends all of its time administering the tasks and not enough time executing the tasks. The same concepts hold true for multiprocessor computers, except that such a machine can achieve parallel operation on as many tasks as there are CPUs in the system. A scheduler interrupts the CPU after a certain time to allow the CPU to be assigned to another task. If the scheduler interrupts the task itself to schedule a new task, the system is called preemptive. If the task has to give the CPU back to the system, it is called cooperative multitasking, like in MS Windows (tm). of the two, preemptive is preferred, as cooperative multitasking fails when a single process forgets or is unable to relinquish control of the CPU. If such a scenario occurs, the computer is "blocked". As the second part, I/O provides a uniform interface to all peripherals, including character devices (serial lines, parallel printers), or block devices (disk drives). These services are normally provided by device drivers, which, in some operating systems, are even loadable. One problem is the communication between device interrupt routines and the rest of the system. Andrew Tanenbaum, in _Operating Systems, Design and Implementation_, says that, "Interrupts are an unpleasant fact of life. They should be hidden away, deep in the bowels of the system, so that as little of the system as possible knows about them." Nevertheless, interrupts are necessary to handle time critical operations, like providing new data to serial lines. Provisions must be taken to avoid data corruption by an interrupt routine and a program (or the kernel) using the same memory locations at the same time. So, even if you don't like interrupts, you have to use them. As the third part, the filesystem provides user-level abstraction of I/O. Files store information of any kind. It is the most visible part of the OS. The naming conventions make a big part of the OS view for the normal user. (Remember the 8+3 character filename length restriction in MS-DOS filesystems?) The filesystem itself provides a standard interface to the user, although the underlying structure (i.e. how files are stored) may differ on different devices. In UNIX operating systems, even devices can be used as files and are represented by special entries in the directory structure (on the newest version of Linux (pre2.0.) even files can be used as filesystem (that hold files that can be used as filesystem (that hold files.. Ooops ;-))). I will not go further into this issue, but how a filesystem is organized can sometimes become a religious war among their respective followers. Since a filesystem keeps all internal structures to itself, it is possible to mount differently structured filesystems in one system. As the final part, memory management keeps track of which parts of the memory are in use and which are not. Memory can be allocated when needed and is freed for other uses when no longer needed. Modern systems use the concept of virtual memory. Virtual memory specifies a system that uses a translation table between the CPU and the real memory locations. When the CPU tries to access a certain memory address, the address given in the opcode does not reflect the real address used to access the memory chips. Instead, the translation table is used to look up the real memory address from the `virtual' address given in the opcode. So, if there is no appropriately sized contiguous memory block available in real memory, such a block can be built using smaller chunks by setting up the translation table for the task. The lookup is done by the memory management unit (MMU). Software called a memory mapper is used to load and change the table. It loads the table with the values set up for each task. So the same opcode address in two different tasks accesses very different memory locations in the RAM. More sophisticated memory managers even do swapping. The memory manager allows a task to allocate more memory than actually available. If a memory location that is not available is accessed, the CPU is trapped (the ability to do this cleanly was one of the (IMHO very few) additions from the Motorola 68000 to the 68010 CPU). The memory manager then saves (swaps out) another memory page to disk and uses the now free memory. The CPU can then continue. If a swapped out memory address is accessed, the CPU is halted again and the page is swapped in again - swapping out another page if necessary. Clearly this slows the whole thing down, but then virtual addresses are a very nice feature. You can hide the pages used by other tasks or map the same memory to several tasks, making it shared memory. These inclusion of these features implies that all resources can be assigned equally to each task. As there are problems with this in the 6502 (think of the stack), another concept should at least be mentioned. The IBM `Virtual Machine' (VM/*) series of operating systems emulates the entire computer's hardware resources for a single task (i.e. a task doesn't talk to the system via system calls, but by writing data into some I/O registers). These register accesses are trapped and appropriate action is taken. This means that the task can behave as if it owns the entire machine. This also means it must load its own OS to handle disk and other I/O (the second part of the "VM/*" naming scheme). The Commodore PET and its successors, the VIC, C64 and 128, already contain some functionality of a "real" OS. On these machines, a single interface allows uniform file access across different devices (tape, disk, console). All of them are accessed via the standard OPEN / CKOUT / CHKIN / CLOSE system calls. However, I/O comprises only one part of an OS, as defined above. The Commodore 8 bit computers are single CPU, singletasking systems (for exceptions see below). Therefore, no process management is necessary. In addition, there is no memory management. All memory is assigned to the single running process. (Although sometimes the need for multiple $cXXX pages seems pressing.) The filesystem, an important part of an OS, is put into the floppy drive on Commodore 8-bit computers and is accessed via standard I/O over the IEEE bus. One interesting exception is the old (IEEE488) Commodore disk drives. These drives have not one but two processors: one 6502 and a 6504 that run in parallel and share some memory. The 6504 is used as a floppy drive controller that handles the low level disk I/O. The 6502 gets the commands from the bus and processes the `filesystem' task. By writing low level commands to certain memory locations, it sends commands to the floppy drive controller (the 6504) that in turn reads and writes the disk blocks. If you look at the 1541, for example, you can see that this concept still holds true. However, in the 1541, the interrupt routine takes the role of the drive controller. Ironically, this reduction in CPUs was done to save 1541. In its effort to cut costs, Commodore forced the single CPU of the 1541 to multitask, creating a bare operating system to support drive operation. @(A): Modern Kernel Design Early operating systems started with a monolithic approach. i.e. all the system functions were provided with one big binary. Modern UNIX systems- even Linux, which is not derived from the original UNIX source- use this concept. A modern kernel instead has a microkernel design. A microkernel only provides the means of communication between different processes, not doing much itself. Some implementations even have the scheduler (!) or memory manager (!) running as a separate task. The kernel calls these processes to find out about free memory pages and which task to start next. This reduces the size of the kernel and allows greater flexibility. On the downside, the microkernel designs forces more messages to be transferred, slowing down operation somewhat. One `famous' microkernel implementation is the current Mach microkernel. This kernel, and its derivatives, has been ported to many platforms. The PowerPC Platform OS/2 is based on a mach derived microkernel, as well as Linux for PowerPC Macintosh (mklinux). But, these are relatively simple ports of already existing operating systems. These mach `single servers' don't allow alternate OS system to run alongside or instead of themselves. On the other hand, the GNU Hurd operating system exploits the mach design to allow any server to be replaced by another. @(A): The OS/A65 Operating System Now let's get from the theory to practice... @(A): The Kernel Implementation When it comes to hardware design, the 6502 has a big advantage: It is a very simple CPU. With only a few support ICs, it is possible to build a fully functional computer (neglecting video and sound capabilities). On the other hand, the simplicity of the CPU has drawbacks. The 6502 has only three multi-purpose registers, and all are 8 bits. As such, none can hold a complete 16 bit 6502 memory location. Even the stack pointer is 8 bits, restricting the stack to the 256 bytes from $0100 to $01ff. The stack size and the absolute addresses are a severe limitation if you intend to develop a multitasking OS on this machine. Because I was developing a new system, I could do anything I wanted to get around this problem. I solved the stack problem by using an MMU, a Memory Management Unit. (Although the used chip, the 74ls610 is stated to be a `Memory Mapper' for paged memory mapping, I call it a `Memory Management Unit'...). The upper 4 address bits are used to select one of 16 8-bit registers. (The 74ls610 has 12-bit registers, but only 8 bits are used, for obvious reasons.) The output of the registers were then used as the upper 8 address bits, extending the total accessible memory to 1 MByte. The CPU could switch each 4 kByte page to any of the 256 pages available by changing the register values in the MMU. Oops - just introduced virtual addresses to the 6502 ;-) For each task, new memory is allocated and saved in the task's page table. When a task is activated, the MMU registers are loaded with these values, giving each task its own memory environment. In the described OS, the memory `manager' is part of the kernel, although a quite independent part. The virtual addresses in the opcodes are translated to the real addresses through the contents of the MMU registers. The tasks are handled by the environment routines. These routines set up the environment tables used by the scheduler. The (round robin) scheduler performs the task switching and decides which task to run next. Preemptive multitasking is achieved by using the interrupt to switch between different tasks. The most important routines are the two kernel entry and exit routines. These sub-routines have to switch the pages and the stack pointer as well as preserve all other register values. The tasks providing filesystem services register with the filesystem manager. They are then assigned drive numbers. Although UNIX filesystems are virtual, where a user can reconfigure the system at any time, developing such a system for the 6502 would overly complicate matters. Different filesystems can then be used at the same time with different drive numbers. The drive numbers are translated by the filesystem manager when passing the message through to the filesystem task. Currently `fsiec' for IEEE488 (parallel IEC-bus) interfaced CBM disk drives, `fsibm' (for PC style disks) and `fsdev' for using devices as files are provided. The interface to the hardware is provided by the devices. Devices are simply stripped off tasks and are called as subroutines only. A device- filesystem (`fsdev') task translates filesystem requests to the device interface, so that any device can be used like a file. The general structure can be seen in Fig.1. ---------- --------- --------- ------ ------- | fsdev | | fsiec | | fsibm | | sh | | mon | tasks... ---------- --------- --------- ------ ------- ---------------------------- -------------- ----- ---------- -------- | | | | fsm | | | | | | | | | env | -------------- | | | | | | | | ------------------ | | stream | | mem | | | | | | | | | -------------------------------------- | | | | | devices | | | | | ------------------------------------------------- ---------- -------- --------- ------- ----------- ---------- | video | | par | | spooler | | serial | devices... --------- ------- ----------- ---------- Fig.1: General OS structure. The devices and tasks make up the features of the system, while the kernel provides communications. (fsm = filesystem manager, env = environment handling, task switcher) In addition to executing code within the task, tasks also need to execute to communicate with other tasks or components of the OS. To communicate between tasks, a send/receive interface is provided. Using a rendezvous technique (the sender blocks till the message can directly be copied to the receiver and vice versa) the mechanism is kept simple, as no buffering is involved. Semaphores can be used for synchronization between different tasks. Data streams are used to pass data between tasks, and even between tasks and devices. Each task has a standard input, output, and error streams opened upon creation, analogous to the stream in UNIX systems. The shell can even redirect or pipe the output. @(A): Program examples The shell is a good example to show some of the capabilities of the system. As already mentioned, each task has three specially assigned streams. Filesystem tasks don't use them (and have them set to an ignored stream), but shells normally get started with these streams connected to a terminal device or a serial line device. The streams are normally opened by the task that `forks' the new task. On boot, the ROM contains some hints about which device number to open for a program. When a new task is started with a shell command, the shell has to open the devices. Normally the standard input and output streams used by the shell itself are registered for the new task. However, if given on the command line, other files can be opened and the streams for these files used as stdio streams. When a file has to be opened, an OPEN message is sent to the filesystem manager. This part of the kernel translates the drive number and forwards the message to the filesystem task. The filesystem then tries to open the file and sends a reply message. The originating task provides a stream number with its first message. If the filesystem task succeeds in opening the file, it uses the provided stream to read or write the data to. If the file ends, the writing task closes the stream, which is recognized by the other end when there's nothing more to read. This works for read only and write only opens, but not for read/write opens. @(A): Problems Bootstrapping was the first major problem. How do you start a new computer and debug its OS if don't have an OS on the computer? From earlier systems I already had a small monitor program - directly burned into an EPROM - able to load binaries through a serial line. Getting the MMU (74ls610) was the second problem, because it was on the CoCom list, and it was not allowed to export to eastern countries. (Although I don't live in an eastern country, this posed some difficulties...) After defining the necessary interfaces between kernel and tasks and kernel and devices, the design was quite straightforward, actually. One problem was the small number of registers in the 6502. For some of the kernel routines, as well as for the send/receive interface it was necessary to define a special buffer. This buffer is at an absolute address at $02XX, which is the same for each task. For systems with an MMU, this is not a problem after all. But it showed out to be a significant problem when porting the OS to systems without MMU, like the C64 (see below). @(A): Operation without an MMU After the system worked well with an MMU, I decided to build a stripped down version for systems without an MMU to better fit some `embedded applications' I had in mind. The system without an MMU is much more a multithreading than a multitasking system. Threads, as opposed to tasks, share the same memory, thus being able to change variables and data of other threads. But, on the other hand, two identical programs cannot run at the same time as with an MMU, unless they know they will together ahead of time. The problem lies within the limited stack size of the 6502. Without an MMU, it is not possible to remap memory pages, especially the page with the stack in it. So the stack is divided into several parts, limiting the stack size of each thread, of course. Another problem is global, absolute addresses - like the send/receive buffer for example. As it would be too much of a rewrite and memory wastage to give each thread its own buffer, the send/receive buffer is now protected by a semaphore. A sempahore is a construct that allows exactly one thread to be in a certain routine or manipulate the protected data at a time. Semaphores originate from the railways, where it is important not to have two trains on the same rail, running in opposite directions... @(A): Port to the C64 In addition to lacking an MMU, the Commodore 64 posed other porting problems. Only small changes had to be made to the kernel. The C64 kernel required an interrupt source for task switching. The video device had to be changed to support the C64 keyboard map and video interface. The hardware cursor used in my homebrew computer was replaced by a software cursor. The IEEE488 filesystem was first ported to the IEEE488 interface for the C64 and then to the C64 serial port. When stress testing the system I realized that I still hadn't ported the STDIO library - a few low level subroutines that make life easier. The library was mapped to most tasks and was called from the task environment, not from inside the kernel. Unfortunately, it used global variables - which broke the library when running on a multithreaded system without an MMU. Therefore, some routines have been changed, while others can only be protected by a semaphore. @(A): Port to the C128? Well, the C128 has more memory and even the capability of remapping the stack and zero page to other locations. In a simple expansion of the C64 version, this could be a way to raise the limited stack size to the full possible 256 bytes. Then, other ideas come to mind. The original memory management is made for a system with MMU and is quite useless without an MMU. What is missing is a call to get a contiguous memory block of more than a memory page in size. Then such a large block could be allocated for a new task to load the binary. The binary itself must then be relocated to fit the new address range. Unfortunately, plans to extend the system calls or add relocation capabilities do not exist at this time. @(A): Conclusion The OS/A65 operating system provides multitasking and multithreading capabilities with a modern kernel design for a 6502 CPU. The OS can be used from embedded applications to desktop systems. A shell provides modern I/O redirection and piping capabilities. Filesystems for Commodore disk drives and PC-style floppies are available. For me, it was a real adventure to design a completely new computer and operating system the way I wanted them designed. I also learned a lot about operating system design - maybe you have learned a bit as well. If you are interested in it, more information is available at: http://www.tu-chemnitz.de/~fachat. ========================================================================= @(#)usenet: UseNuggets COMP.SYS.CBM: The breeding ground of programmers and users alike. Let's see what topics are showing up this month: @(A): Let's Poll Together Throughout the past few months, Paul Allen Panks has been conducting a poll on Commodore Business Machines' greatest success stories and most momentous flops. Although some biased opinions exist, many have agreed that the C64 was a success, while the 264 series (Plus/4 and C16) was a flop. After that, however, and few agree. @(A): Ymodem vs. FX, Round -1 The many people who use Craig Bruce's ACE environment know that he recently added support for a special transfer protocol, FX. Proprietary in nature, FX supports very large buffer sizes and can achieve throughput of 200% or more over standard protocols like Ymodem or Xmodem. The downside of FX is the necessity of compiling an FX "server" on a UNIX host in order to utilize the protocol. While not newsworthy in itself, a discussion about which standard protocols are fastest kicked up some dust. Many were inquiring about DesTerm support for Zmodem, causing Ismael Cordeiro to note that the DesTerm protocol implementors chose to optimize existing protocols rather than introduce new ones. A lively debate started, as Craig Bruce noted that even the fastest implementations of Ymodem were no match for FX. Ismael countered by calling the comparison unfair. Ismael noted the drawbacks of FX being proprietary and not available for all Commodore users. Also, Ismael explained the reasons for FX's increase in throughput over standard protocols. Packet size was a large factor, as FX uses a much larger buffer size. However, FX suffers when retransmissions are necessary, since the time between handshakes (which occur between packets) is much longer. When using a comparable packet size, FX and Ymodem are competitive. @(A): Operating System Support In last issue's USENuggets, we discussed the conversations stemming from the proliferation of operating system ideas on comp.sys.cbm. (C=H#12, Reference: usenet) We noted that many expressed a need for programmers to support the ACE computing environment, written by Craig Bruce. Upon noticing this, Craig responded: "I, of course, support the idea of other people building more applications for the ACE environment. I also support the idea of using ACE applications with other operating systems. ACE was built on the idea of providing a well-defined Application-Program Interface (API), and any alternative OS that can emulate the ACE interface (using a "middle-ware" layer of software) can run all of the existing ACE applications. Thus, a new operating system can have a base of (a few) high-quality programs available instantly (high-enough quality that even _I_ use them). Admittedly, I have to update the documentation on the ACE API, since it changed in Release #15, but the basic functionality will always be the same. In addition, I also support the idea of other people using ACE code inside of their own operating systems. Why re-invent the wheel? Especially useful may be the dynamic-memory stuff and some device drivers. ACE is Public Domain software, so you can do with it whatever you please." @(A): The "More Power" Swiftlink (An Update) As well, Craig followed up to our story last issue on the "hacked" Swiftlink that could do 115,200 bps. (C=H #12, Reference: usenet) Craig noted that ACE #15 supports the modified Swiftlink and that the code in ACE handles the new speeds "flawlessly". @(A): And Speaking of Operating Systems... Since the last issue of Commodore Hacking, at least two more operating systems have been announced. One, OS/A65, is detailed in this issue of Commodore Hacking (Reference: os). Another, called COMMIX 2, will encompass an object oriented operating system. The system is comprised of multiple sub parts, including: Networked X Input/Output (nXIO), the communications sub system COMMIX Object Format (CXOF), an object and code description format nXIOtee, the object oriented programming language. For more information on this networked OS design, check out its WWW site at: http://www.cynapses.com/ry/cx2/cx2home.html ========================================================================= @(#)uqwk: Using UQWK with QWKRR128 by Gaelyne R. Moranec (gaelyne@cris.com) @(A): Introduction One of my first priorities when joining an Internet service was to find a way to utilize the QWKRR128 offline mail and news reader to read Internet email and USENET newsgroups. Like all QWK offline readers, QWKRR128 is commonly used with Bulletin Board Systems (BBS). A user dials into a BBS, selects which groups and what email to download. The BBS program then gathers and compresses the user's requested messages into a file called a QWK packet. The user downloads the resulting packet, and then runs QWKR128 or some other QWK reader on the packet. Thus, users can read email and news offline and reduce connect time. Replies are also handled in much the same way, allowing the user to read and reply to messages without tying up the phone. What happens when we replace the BBS with the Internet? Well, for a while, making the switch meant shelving QWK offline readers. However, as with all problems that occur on the Internet, this deficiency was soon remedied by Steve Belzack, who wrote the Unix QWK system, called UQWK. It allows Internet users to package up Internet email and USENET newsgroups into QWK packets for use with QWK readers like QWKR128. Like its BBS counterpart, UQWK also handles reply packets from the QWK reader. @(A): Finding UQWK You can find out if your system already has UQWK by typing any of the following - if one command doesn't work try the next one. where uqwk whereis uqwk which uqwk find uqwk If your system has UQWK installed, DON'T run the program until after you've read the manual for it. UQWK requires command line switches to work and defaults to emptying your mail box, which isn't nice. To read the manual, type: man uqwk It's a good idea to create a text file in your home directory with the manual so you can download, print, and review it offline. The command to do this is: man uqwk >> uqwk.manual Then, to read it you type: more uqwk.manual To download it with Ymodem, the command is: sb uqwk.manual If your system doesn't already have UQWK available, you may be able to get the file and compile it for your personal use. Because there are so many versions of Unix to deal with, I cannot help you with compiling it for use on your system. If in doubt, give the file to your system administrator and ask him or her to install it. The FTP site is: gte.com Directory: /pub/uqwk/uqwk1.8.tar.Z Be sure to get both UQWK and the README file. The text file will tell you step by step how to set it up on your account. @(A): Using UQWK I use two Unix script files when I use UQWK, named "getmail.script" and "sendmail.script". I keep these text files in my home directory. I had to change the permissions on them so Unix would see them as "executable" files. The command for this is: chmod +x filename or chmod 700 filename You will need to make changes in the files so that they represent the BBSID used on your system. For instance, CRISINET is the BBSID on my system and is used in the examples below. When you use the getmail.script the first time, just use an arbitrary name for the name of the .qwk packet, but change your script after you know the correct BBSID to use. Be sure to use proper upper or lower case *exactly* as it appears in your control.dat file for any references to your .REP and .msg files. This may not always work, however, as it depends on your terminal program. Some CBM term programs will maintain the same casing as is used by PETSCII, while others will convert them to ASCII. If yours changes the filename, be sure to change the appropriate lines in your script files so UQWK and other utilities can find it. @(A): Scripts To Get You Started # ---------------- # getmail.script # rm crisinet.qwk uqwk +r +m +n +e arc a crisinet.qwk *.dat *.ndx sb crisinet.qwk rm messages.dat *.ndx # ---------------- Notes: rm crisinet.qwk - This removes any previously created .qwk packet. it is in lower case, as since we name this file ourselves, there's no need to make it uppercase. uqwk +r +m +n +e - The command to tell UQWK what you want it to do. +r keeps UQWK from deleting your Email and marking your newsgroup messages as read. +m process Email. +n process newsgroups +e tells it to create a control.dat file listing ONLY those subscribed newsgroups. * Also you can use -m or -n so UQWK won't process * mail or newsgroups. UQWK defaults to doing * Email, but not newsgroups. (+m and -not) * The +e switch is a must for QWKRR users, as * this list gets loaded into memory and reduces * the amount available for reading messages. arc a crisinet.qwk *.dat *.ndx - This creates an ARC archive of the files UQWK has created. QWKRR users don't need to include the *.ndx files, but it's included here for those who use other offline mail readers. ... Heathens! :-) As mentioned previously, although the BBSID is "CRISINET", since we are creating the archived file, we can leave it in lower case for our own convenience. sb crisinet.qwk - This begins a Ymodem download of your QWK packet. You have to start the transfer with your terminal program manually. rm messages.dat *.ndx - This removes the messages.dat and *.ndx files from your directory. If you have sensitive Email you don't wish others to view, this prevents anyone from reading it. # ---------------- # sendmail.script # rb unzip CRISINET.rep uqwk -m -n -Rcrisinet.msg rm CRISINET.rep # ---------------- Notes: rb - This begins a Ymodem upload so you can upload your Reply packet. You have to start the upload with your term program manually. unzip CRISINET.rep - If you've ipped your reply packet, this is the command to unzip it. When QWKRR creates the file, it honours the case of the BBSID, so the filename is in upper case. uqwk -m -n -Rcrisinet.msg - This is UQWK command to process a reply packet. The -m and -m switches tell it NOT to process your Email or newsgroups into a new batch of mail to download. This file (crisinet.msg) is within the "REP" packet. It is lower case. rm CRISINET.rep - This deletes the .rep file from your directory. UQWK automatically deletes the *.msg file. You can also create these scripts with your term program. Either way works. When you review the UQWK manual, you'll see the commands and should be able to follow the script file and make adjustments to suit your needs. You can have UQWK create QWK packets for Email, newsgroups, or both. Also, you can have one script file that sends your replies then creates the next batch of QWK mail for you. @(A): Safeguarding Your Email On one system I use UQWK with, I can back up my Email file, something I recommend especially when you first start using the program. To back up my mail file, I copy the mail spool file to a local temp directory. The actual path string for this varies depending on the type of Unix system you are using. For me, this works: cp /var/mail/username ~/temp/filename On another system, I can't make a backup of my Email file, as the system doesn't allow users to move or copy mail files. However, I can use a command for UQWK that tells it not to erase my mail or newsgroup articles. If you use the read-mode only command, you have to delete Email manually, and mark newsgroup articles as read. NOTE WELL: ---------- UQWK uses your .newsrc file to find what groups you are subscribed to. ALWAYS upload and process your current Replies before subscribing or unsubscribing to newsgroups, or else you will have your replies going to the wrong newsgroups. @(A): The Files UQWK Creates UQWK only creates the base QWK mail files, which are "control.dat", "messages.dat" and files that end with "*.ndx" (*.ndx files are not needed for use with QWKRR). If you want to you can archive the files QWKRR needs, or you can download the *.dat files uncompressed. The getmail script file covers creating the arc file and beginning a Ymodem download. I compress my mail using arc, as I have a program that will automatically dissolve my QWK mail and start QWKRR. The program is called QPE, and can be found in the archive NZP12817.SFX. If you arc your mail packet, you will need an ML program found in the archive CSX01.SDA. I could use Zip, but my ISP's Zip program creates only PKZip 2.04g files, and Commodore users don't yet have a program that will unzip these. @(A): Replying To Email By default, QWKRR doesn't display any data after an "@" symbol in the headers. To be able to see the complete Email addresses (a must for Internet use), first load but don't run QWKRR. Type: poke 49169,255 Then save the program using a different name (such as qwkrrinet), just in case you've made an error when entering the values. @(A): Long Email Addresses If the Email address of the recipient doesn't fit in the "To:" field, you must use other addressing methods. Erase the name in QWKRR's header and substitute the person's first and last names, or any two words with a space between them. Do NOT have a "." or "@" here if the full Email address is too long to fit in the field. If you do, UQWK assumes it's a valid Email address. The reason you want two words instead of one is so the program doesn't assume you're sending local mail on your ISP. On the first line of the message, type: To: user.name@anywhere.com Begin your message on the following line. Hint: Type "To: " on the first line. Quote enough of the message so the Email address is on the screen, and then move the address so it is in place after the "To: ". There is a space between the colon and the Email address. @(A): Sending Newsgroup Articles The only thing different from Email you'll need to do is make sure that your articles have the word "all" or "ALL" in QWKRR's "To:" field. Messages from almost any QWK offline mail reader do not conform to Internet standards for newsgroup articles, as QWK was originally designed for Fidonet only. You can still post articles with these programs using the above method of placing "all" in the "To:" field. For those who want their articles to conform to the Internet specs, you can have UQWK look to the body of your message for the header information by using the +X switch. This will let threaded newsreaders properly add the article into an existing thread. This is only for those who are well experienced with RFC-1036, the "Standard for Interchange of USENET Messages" and RFC-822, the standard for Internet Text Messages. These documents can be found on the web at: http://www.internic.net/rfc. In the future, I'll be adding information to QWKRR's web site on how to create articles that do conform to this standard. QWKRR has a known bug when it comes to quoting lines that are over 255 characters long. This bug often appears when replying to newsgroup articles, as the "Path:" line often exceeds this. The next version of QWKRR will not have this problem. To reply to a newsgroup article that has a long pathline, export the article as a temporary text file, then import it into the message. eport is a function only available to registered QWKRR users. @(A): A known UQWK Quirk for QWKRR users When importing text that has a "message" header on it (i.e., all the To, From, Subject etc.), UQWK makes the assumption that a new message has started. To avoid having your message split at this stage, indent the To/From info in the imported text about 4 columns. @(A): Sending Your Replies Most Unix systems can unzip reply packets that have been Zipped by QWKRR. It can also handle files that are ARC'ed if you use the QPA program. UQWK doesn't require this. All UQWK knows about is the *.msg file within the .REP file. It is possible to choose ink within QWKRR and upload the resulting *.msg file, BUT if you do this, you may have problems with Xmodem padding (also Ymodem) added to the end of the file by your term program. This extra padding will cause you to receive an Email bounce as UQWK tries to interpret the padding as a message. It's easier to ip the replies then let your script file unzip them. @(A): UQWK and Signatures When posting articles to newsgroups, UQWK will append your .signature, but if it doesn't like the length of your signature, it will not post the article. (I don't know the length it will accept). You may want to change the filename from .signature to .sig and use a QWKRR macro for your signature instead. (Be sure to change your settings for other programs like Pine so it will look for a file called .sig, though). @(A): UQWK and Newsgroup Subjects There is a UQWK version that doesn't accept newsgroup articles created with QWKRR and complains that the subject line is incomplete or incorrect. So far the only cure I've found is to use an older version of UQWK that my system has online. UQWK version 1.8 does not have this problem, and after checking FTP sites, it appears my current ISP is using a customized version. If I find others have similar problems and find a cure, I'll post info regarding it on QWKRR's WWW site. http://www.msen.com/~brain/guest/Gaelyne_Moranec/qtoc.html @(A): Conclusion While reading BBS news and email offline is a blessing, it is almost a necessity on the Internet, where the level of email and news can be overwhelming to the online reader. UQWK and QWKR128 make a powerful combinations that help you manage your time effectively yet still enjoy the pleasures of keeping current on all the Internet has to offer. ============================================================================ @(#)fido: FIDO's Nuggets by Geoff Sullivan (geoff.sullivan@tbbs.bcs.org) The CBM GEOS, CBM, and CBM-128 FIDONet echoes are places where Commodore users unite. Let's see what they discussed over the past few months: @(A): GEOCable and Printers GeoCable was a product originally marketed by Berkely Softworks to eliminate the need for a serial interface for non-Commodore printers in the Geos environment. It also speeds data transfer from computer to printer. Well, some users decided to test this speed increase and found that what was accepted before may not be true in all cases. Many scientific, and not so scientific, test results showed that the speed of printing may have more to do with the type of data being printed and the buffer size of the printer, than with the actual method used to get the data to the printer. Lately more programs outside the Geos operating system are sporting printer drivers that support the GeoCable. As Phil Heberer aptly puts it: "Most of us GEOS users know the obvious benefit of using a geocable when printing from GEOS, but I'm also happy to see many programmers adding gc support to their programs. I can now use my geocable with nearly ALL of my favorite CBM programs that I currently use besides GEOS (i.e. Superscript/Superbase, TWS128, FGM, BROWSER and ACE15) If Maurice Randall gets 'The Wave' finished for GEOS, it will round out my applications quite nicely!" Many users are building their own cables as well. Some users are discussing the need for drivers that will work with the Hewlett-Packard PCL language that is becoming more prevalent now that Commodore users are fooling around with ink-jet and laser printers. @(A): DESTERM Matt Desmond has recently posted a message on FIDONet confirming his work on a version 3.0 of Desterm. He has also stated again that it will have hardware flow control and enhanced REU support. It will NOT support any transfer protocol beginning with the letter Z. @(A): EZ Loader v3.2 Released David Schmoll announced the release of an upgraded version of his EZ Loader program for the 64 or 128. It is designed to help you access your most used programs on any disk or fixed drive through a single menu. Although most useful for CMD drive owners, it can be used with any Commodore drive. It has too many slick features to be mentioned here but certain ones are disabled on the downloadable version. They can be activated by registering the program. It is available via FTP from ccnga.uwaterloo.ca in /pub/cbm/util128/ and possibly on local BBS's by now. @(A): Alternate Character Set Access One user was toying with the idea of storing multiple character sets in the VDC 64K memory of his C128 and swapping between them by simply changing the register address. His aim is to perfect this for display applications for various programs such as character set editors. Rod Gasson suggested an alternate scheme would be to swap the entire stored character set from the VDC ram into the default page at $2000. He says that the VDC's block move is very quick and it allows mixing of characters from more than one set. @(A): Internet Some folks have reported problems downloading binary files via Lynx or FTP through UNIX servers with their Commodores. Ismael Cordeiro had some suggestions for these MIME type problems. For those with shell access on a UNIX system he suggested using FTP with a customized MIME type file: "...create a text file named '.mime.types' in your home directory with one line: application/octet-stream sfx sda arc prg cvt lnx If you don't have shell access and Lynx is the user interface...the only thing to do is ask the system administrator to include the above line in the system's mime.type file." @(A): Miscellaneous Among the miscellaneous topics being discussed on FIDONet is the use of a C64/128 for ham radio communications. This is a rather popular use for the 64. The program being discussed is Digicom. Many newcomers are still asking questions of the "old timers" concerning Desterm setup with high speed modems, REU expansion, and off-line mail reading and replying. For a "dead" machine, it is surprising to see how many are being dragged out of closets, dusted off, and booted up! So, that's a glimpse into the world of FIDO, the wonder dog of networks, for this time. Here, boy.... ========================================================================= @(#)pal: Brad Templeton: The Programmer's Friend by Jim Lawless (cjbr@gonix.gonix.com) The following text is an interview held via e-mail with former C64 software author Brad Templeton. Mr. Templeton is the author of the PAL assembler and the Power productivity tool. Mr. Templeton is the founder and current CEO of ClariNet, a networked newspaper with over a million subscribers. Please refer to the references at the end of this text for Internet resources detailing his accomplishments. Q: Were PAL, Power, and C Power fruits of your imagination, or were you contracted by Pro-line to write them? A: C Power was a C compiler written by Brian Hilchie, nothing to do with me. But POWER and PAL (Can't recall which I did first, probably PAL, but POWER was the one sold first.) were done on my own. Professional Software licensed Power for the Pet and Pro-Line licensed it and Pal for the C-64. Actually, I think I wrote a quick cross assembler in B (the predecessor language to C) to run on the mainframe at my university first, and wrote the early version of PAL in that. Then of course moved it to the Pet so that PAL could assemble itself -- always the big moment in any language development. My memory is getting dim, I might have started from an Apple based assembler. I know I wrote a cross assembling, one-pass version of Pal, with macros for Unix a few years later but just used it to develop stuff for the C64. (Most people are startled to learn that C compilers, even the very first one, are usually written in C, and so on. You bootstrap by writing a very simple one using an existing tool, then get it going and then enhance it.) Q: PAL was/is one of the most widely used assemblers for the C64 (and I assume the PET). Had you written any assemblers before PAL, or did you just happen to create a darn good product "coming out of the starting gate"? A: No, I hadn't written any assemblers other than the cross assembler. Before that however, I had developed Time Trek, a game for the Pet, Checker King (a game) for the Atari 800, Apple ][ and Pet and the Atari 800 graphics for Microchess. Q: In the days of PAL and Power, were you actually making a living writing software for CBM machines or was it sort of a part-time excursion? A: Well, I was a student at the time. But after graduating, it was enough of a living to be able to work on other projects, and eventually get the contract to develop my next product, Alice Pascal, in 84. Q: What were some of the biggest problems marketing your CBM software? (Was piracy an issue?) A: Piracy was somewhat of an issue. The big mistake with Power was doing demos at some pet user groups before I was ready to sell it. Bill Seiler of Commodore saw a demo I did at the silicon valley PUG, and added some of the best features to Basic-AID, which Commodore gave out for free. Power was better than Basic AID but a good free competitor didn't help. It was still a hobbyist market, not nearly as big as the computer industry grew to be. Q: When and why did you finally abandon development efforts geared toward the C64? A: The machines faded away and the IBM based machines clearly took the lead for more serious applications. If you wanted to do things that took more than a few kilobytes, or work in C, the C64 wasn't really an alternative. I did some games for the C64 but never went anywhere with them. Q: With C64's showing up at garage sales and emulators available on a wide variety of machines, a renewed interest in that little machine is experiencing a rebirth. Do you have anything you'd like to say to a new generation of C64 hackers out there? A: On one hand I am shocked, since vastly more powerful computers are of course available very cheap, garage sales or otherwise. However, there was a certain excitement to a small computer that one person could fully understand and work with like the Pet or C-64. If you view the computer as a hobby or a toy, it doesn't have to be the most advanced thing, what matters is that you have fun with it. I certainly wouldn't advocate Windows programming to the ordinary start-up hobbyist but such people can have fun on a C64. For more information on Mr. Templeton's current endeavors, the following WWW documents may be of interest to you: An Interview with Brad Templeton URL: http://info.acm.org/crossroads/xrds2-3/templeton.html Brad Templeton's Homepage URL: http://www.clari.net/brad/ ========================================================================= @(#)surf: Hack Surfing For those who can access that great expanse of area called the World Wide Web, here are some new places to visit that are of interest to the Commodore community. In early 1994, when the US Commodore WWW Site started, the number of sites online that catered to Commodore numbered in the 10's. Now, the number is in the 100's. What a change. If you know of a site that is not listed here, please feel free to send it to the magazine. The following links have been gleaned from those recently changed or added to the US Commodore WWW Links Site (http://www.msen.com/~brain/cbmlinks/). To encourage these sites to strive to continually enhance their creations, and because we like to gripe :-), we'll point out improvements that could be made at each site. @(A): Companies o The Official DesTerm 128 Page URL: http://www.ionline.net/~mdesmond/desterm.html Here is where you will find the latest scoop on the popular terminal emulation program for the 128, as well as information on the newest release, Desterm 128 3.0. As well, you can download Desterm 2.00. C=Hacking gripe: There isn't much information on the 3.0 version. o Keyboard Studio URL: http://www.cu-online.com/~gwilson/ Gordon Wilson's company motto is: "Large enough to get it done; small enough to care." That sits well with us. This small site announces Mr. Wilson's Commodore repair facility to the world. It offers basic information about the type of repairs possible and what other services are offered. C=H gripe: We wish there was more detailed information on repair services, like pricing information. o Novaterm 9.6 URL: http://www.eskimo.com/~voyager/novaterm.html For a guy who just released a new version of his popular C64 terminal emulation program, Nick Rossi has managed to put some effort into this site. The site is flashy, but can be viewed with text browsers as well. The information here includes a rundown on Novaterm 9.6 features, details on who helped write it and how to purchase it, and links to obtain the 9.5 release. Of special mention is the fully indexed HTML online documentation. C=H gripe: For those who want to order with a credit card, the site refers to a list of authorized Commodore dealers that we couldn't find. o Omni 128 BBS Software Home Page URL: http://www.nwlink.com/~bbell19/omni128.html At this site, Brian Bell presents an overview of his Bulletin Board System Software and updates on releases. Additionally, information on capabilities like "Echo Net" are present. C=H gripe: We couldn't find out how to purchase the software or how much it costs. @(A): Publications o DisC=overy Home Page URL: http://www.eskimo.com/~drray/discovery.html We'll save a review of the magazine for "Hacking the Mags" (Reference: mags), but the publication does tout its own WWW site. It's pretty bare at present, but it does have links to both a text and also a compressed version of the Premiere Issue. C=H gripe: We didn't expect much here, but we do hope the publication offers an index or list of articles here at some point. o 64'er Online URL: http://www.magnamedia.de/64er/ This site presents information about the German Commodore publication. The layout is nicely done. The July issue is currently featured, with information on the contents and an index of articles. Alas, the site is for German readers only, but we expected no more. For those who can read German, ordering information and pointers to other products are available. C=H gripe: The site leans a bit heavily on graphics, making it slow to load. o Commodore Online Information Network (COIN!) URL: http://people.delphi.com/cynrcr/ccs.html This site offers information on the COIN! disk magazine. Information on the magazine is presented, and links to the 2 most recent issues are provided for your downloading pleasure. A small description is given detailing the contents of older issues as well. C=H gripe: White text on a black background takes a bit of time to get used to. However, text mode users won't notice :-) @(A): Demo Groups o Millenium Home Page URL: http://marie.az.com/~waveform/millenium.html This site shows off screen shots of the demo groups' creations. The site is nicely done, with many screen shots and nice graphics. C=H gripe: How do we download the demos? o Demo/Revenge Distribution Site URL: http://hack.lakeheadu.ca/~revenge/index.html Demo groups tend to provide the splashiest sites, and this one is no exception. The graphics are nicely done, but the content is available to all text-mode browsers as well. Links to demos are provided, as are links to other sites of interest. C=H gripe: With limited time to download, could we get a small description of each demo to help us pick? @(A): Reference Works o The C64 Games WWW Home Page URL: http://www.student.nada.kth.se/~d93-alo/c64/ Screen shots are provided for a couple of C64 games, and clicking on the names reveals detailed information on the games and its gameplay. Music from many C64 games is present, as are tips and hints for playing some vintage Commodore games. C=H gripe: The name of the site is a bit misleading, since the list of games isn't that extensive. o Poldi's Projects - LUnix URL: http://rpool1.rus.uni-stuttgart.de/~etk10217/proj.html UNIX on a 64. Don't even think that it cannot be done. Daniel Dallmann has already proved it CAN. This site details the entire project to execute a multitasking OS on a 64 from kernel to device driver. In addition, some of Daniel's other projects are detailed at this site. Daniel has developed a fast soft-80 screen driver for the C64, and the code with detailed information is available here. Schematics, code, comments, and an overview for Daniel's 9600 bps serial routines are available here. These routines have also been incorporated into Noavterm 9.6. Finally, Daniel has developed a basic implementation of the Serial Line Internet Protocol (SLIP) for the 64. Code and information are linked off the site. Many of the projects include screen shots and schematics. C=H gripe: A high level overview of some of the projects would help first time surfers. o OS/A65 Computer and Operating System URL: http://www.tu-chemnitz.de/~fachat/csa/ Andre Fachat's work on a multi-tasking OS and a home built 6502 based computer system are outlined at this site. The software is detailed in Andre's article elsewhere in this issue (Reference: os), as well as on the site. The full text is presented on the site, with an indexed overview. C=H gripe: We couldn't find a link to the bare 64 binaries. o Technical SID documentation URL: http://stud1.tuwien.ac.at/~e9426444/sidtech.html For the SID-savvy of the bunch, this site offers a technical discussion of the 6581 SID IC and descriptions of the various waveforms with mathematical treatment. C=H gripe: The presentation is pretty basic. o Commodore Product Source List Issue #5, On-line Edition URL: http://www.televar.com/~rjlong/ Roger Long has placed his Commodore products SourceList Online. The online version, which is updated more frequently than the printed version, contains a wealth of information on where to find hardware, software, and supplies for the Commodore computer. C=H gripe: An alphabetical index would be nice. o Carrier Detect URL: http://www.swt.edu/~ez13942/bbs/cbmbbss.htm For all the BBS sysops or ex-BBS sysops, this page will certainly bring back memories. A History of BBS in the 1980's is given, followed by an extensive review of various