magazines:chacking12
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | magazines:chacking12 [2015-04-17 04:34] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | < | ||
+ | | ||
+ | ######## | ||
+ | ################## | ||
+ | ###### | ||
+ | ##### | ||
+ | ##### #### #### ## ##### | ||
+ | ##### ## ## #### ## | ||
+ | ##### | ||
+ | ##### ## ## ######## | ||
+ | ##### #### #### #### #### ##### | ||
+ | ##### ## | ||
+ | ###### | ||
+ | ################## | ||
+ | ######## | ||
+ | | ||
+ | ------------------------------------------------------------------------- | ||
+ | </ | ||
+ | ====== Table of Contents ====== | ||
+ | < | ||
+ | Features | ||
+ | 6. " | ||
+ | (Reference: polygon) | ||
+ | Did you ever feel real time 3 Dimensional graphics was just asking | ||
+ | too much from a Commodore 64? Well, ask no more, as Stephen shows | ||
+ | us just hoiw it can be done. The 64 steps up to the challenge of | ||
+ | displaying correctly rendered shaded 3D polygons right before your | ||
+ | very eyes. | ||
+ | 9. Underneath the Hood of the SuperCPU by Jim Brain | ||
+ | (Reference: cmdcpu) | ||
+ | Delve into the technical details of this new accelerator | ||
+ | under development by CMD. Jim will explain its advantages | ||
+ | over existing offering, epxlain the features it provides, and | ||
+ | dispel some myths about the unit. | ||
+ | |||
+ | Columns | ||
+ | 4. Hi Tech Trickery by Doug Cotton | ||
+ | (Reference: trick) | ||
+ | Trying to switch from 128 mode to 64 mode on a C128 without | ||
+ | human intervwention is triccky. | ||
+ | is doubly so. Doug details a routine that will work regardless of | ||
+ | the ROM in use. | ||
+ | 12. Hacking Graphics by Levente Harsfalvi | ||
+ | (Reference: gfx) | ||
+ | All you Commodore Plus/4 lovers, listen up. Levente delves into | ||
+ | the Commodore Plus/4 TED chip, explains its many functions and | ||
+ | details its various registers. | ||
+ | chip does in addition to handle video. | ||
+ | |||
+ | Departments | ||
+ | 1. The (cough, | ||
+ | (Reference: editor) | ||
+ | 2. Input/ | ||
+ | (Reference: io) | ||
+ | 3. Newsfront | ||
+ | (Reference: news) | ||
+ | 5. Hacking the Mags | ||
+ | (Reference: mags) | ||
+ | 7. UseNuggets | ||
+ | (Reference: usenet) | ||
+ | 8. FIDO's Nuggets | ||
+ | (Reference: fido) | ||
+ | 10. Hack Surfing | ||
+ | (Reference: surf) | ||
+ | 11. Commodore Trivia | ||
+ | (Reference: trivia) | ||
+ | 13. ? DS, DS$: rem The Error Channel | ||
+ | (Reference: error) | ||
+ | 14. The Next Hack | ||
+ | (Reference: next) | ||
+ | 15. Hacking the Code | ||
+ | (Reference: code) | ||
+ | |||
+ | ------------------------------------------------------------------------- | ||
+ | </ | ||
+ | ====== 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. | ||
+ | published 4 times yearly by: | ||
+ | |||
+ | Brain Innovations Inc. | ||
+ | 602 N. Lemen | ||
+ | Fenton MI 48430 | ||
+ | |||
+ | 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 " | ||
+ | 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. | ||
+ | compilation, | ||
+ | part of a non-profit compilation. | ||
+ | |||
+ | This publication, | ||
+ | various elements, is copyright(c) 1995 by Brain Innovations, | ||
+ | unless otherwise noted. | ||
+ | copyrights pertaining to the individual work's contents. | ||
+ | redistribution rights to individual works, please contact the author of said | ||
+ | work or Brain Innovations, | ||
+ | |||
+ | Brain Innovations, | ||
+ | editorial, article, or program listing content. | ||
+ | |||
+ | ------------------------------------------------------------------------- | ||
+ | </ | ||
+ | ====== Commodore Hacking Information ====== | ||
+ | < | ||
+ | | ||
+ | Commodore Hacking is published via the Internet 4 times yearly, and is | ||
+ | presented in both ISO-8859-1 and HTML versions. | ||
+ | be found at the Commodore Hacking Home Page | ||
+ | (http:// | ||
+ | (ftp:// | ||
+ | |||
+ | In addition, the Commodore Hacking mail server can be used to retrieve each | ||
+ | issue. | ||
+ | mail message: | ||
+ | |||
+ | To: brain@mail.msen.com | ||
+ | Subject: MAILSERV | ||
+ | Body of Message: | ||
+ | |||
+ | help | ||
+ | catalog | ||
+ | send c=hacking12.txt | ||
+ | quit | ||
+ | |||
+ | To retrieve a PKZIP 1.01 archive of the individual articles in Commodore | ||
+ | Hacking, request the file c=hacking12.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. | ||
+ | line is roughly 50 characters, so 600 lines is about 30000 bytes. | ||
+ | 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. | ||
+ | any administrative costs, subscribe to publications for review, and | ||
+ | compensate the individual authors contributing to this issue. | ||
+ | |||
+ | Any persons wishing to author articles for inclusion in Commodore Hacking are | ||
+ | encouraged to view the submission guidelines on the WWW | ||
+ | (http:// | ||
+ | server (send c-hacking-submit.txt). | ||
+ | |||
+ | ========================================================================= | ||
+ | |||
+ | </ | ||
+ | ====== 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. | ||
+ | magazine, a word prefixed with a special string is present. | ||
+ | title of this article for an example. | ||
+ | article is mentioned, it will be followed by a reference string. | ||
+ | example, if we mentioned this article, we would add (Reference: rch) after | ||
+ | the name. By using your favorite editor' | ||
+ | for the string after the word " | ||
+ | string, will move you directly to the article of choice. | ||
+ | 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 | ||
+ | contents table of contents | ||
+ | legal legal notice | ||
+ | |||
+ | For those with access to a UNIX system, the command " | ||
+ | run on the issue, which will result in all the article titles being | ||
+ | printed. | ||
+ | |||
+ | A slightly different magic prefix string " | ||
+ | sub-topics or main heading in articles. | ||
+ | differs depending on article content. | ||
+ | (Reference: io), the text after the magic prefix will either be " | ||
+ | comment, or " | ||
+ | the prefix indicates the ordinal of that heading or sub-topic in the | ||
+ | article. | ||
+ | a sub-topic reference will be indicated. | ||
+ | be written as " | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== The Hacking Editor ====== | ||
+ | < | ||
+ | by Jim Brain (brain@mail.msen.com) | ||
+ | |||
+ | Speed and the Web. The owners are asking about it. The developers are | ||
+ | looking into it. The market is readying itself for it. No, not the PC | ||
+ | market, I'm referring to the Commodore 8-bit market. | ||
+ | usually referred to as " | ||
+ | a condescending tone. Well, mature we might be, but isn't that considered | ||
+ | a good thing? People are supposed to mature as they grow older. | ||
+ | they are revered and looked up to. What parallels can we draw here? | ||
+ | |||
+ | If you haven' | ||
+ | 20 MHz accelerator cartridges for the C64 and C128, shame on you! You | ||
+ | need to stay in touch more. For those who have, let's not overdo the | ||
+ | hype. CMD isn't the first to produce such a cartridge, but they will be | ||
+ | the first to introduce 20 MHz as a speed option. | ||
+ | as the first 128 mode accelerator ships from CMD. When this happens, | ||
+ | performance approaching that of the venerable Intel 80386 will be as | ||
+ | close as the on/off switch. | ||
+ | |||
+ | The explosion of interest in the Internet and the World Wide Web is | ||
+ | changing the way people view computers. | ||
+ | people thought only computer systems including a 32 or 64 bit CPU, | ||
+ | multiple megabytes of RAM, gigabyte hard drives, infinite resolution | ||
+ | monitors and million bit sound cards were worth owning. | ||
+ | owners have felt the sting of ridicule as they continually take blow | ||
+ | after blow for remaining loyal to a machine with much to offer. | ||
+ | be patient, because 1996 might be the year of the " | ||
+ | smaller comuter system that trades all the fancy features of bloated PCs | ||
+ | for a smaller size, cost, and a connection to the Internet. | ||
+ | like IBM, Oracle and Apple are pushing this idea, which would bring to | ||
+ | market systems with modest RAM, small drives, television displays, and | ||
+ | small operating systems. | ||
+ | it describes many features of Commodore 8-bit systems. | ||
+ | 8-bit still lacks a few items present in the IBM/ | ||
+ | but the bulk of features are already available on your so called | ||
+ | " | ||
+ | if your friends tout the benefits of such a machine, gently remind them | ||
+ | that you own of of the first and best, a Commodore 8-bit. | ||
+ | |||
+ | Enjoy YOUR magazine, | ||
+ | |||
+ | Jim Brain (brain@mail.msen.com) | ||
+ | editor | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== Input/Ouput ====== | ||
+ | < | ||
+ | |||
+ | Obviously, Commodore Hacking depends on the comments and article submissions | ||
+ | from the Commodore community to flourish. | ||
+ | let's not forget those comments. | ||
+ | is made to address concerns in them. Address any comments, concerns, or | ||
+ | suggestions to: | ||
+ | |||
+ | Commodore Hacking | ||
+ | 602 N. Lemen | ||
+ | Fenton, MI 48430 | ||
+ | brain@mail.msen.com (Internet) | ||
+ | |||
+ | @(A)c: Time Travellin' | ||
+ | |||
+ | From: Robin Harbron < | ||
+ | |||
+ | Dear C=Hacking, | ||
+ | I was looking at the Commodore Hacking page (fantastic magazine) and | ||
+ | noticed that the " | ||
+ | dates, while I assume that the last 4,5,or 6 probably should be 1996. | ||
+ | Thanks for everything! | ||
+ | |||
+ | Robin | ||
+ | |||
+ | @(A)r: | ||
+ | Yep, we must have just returned from our time travel experiments when we | ||
+ | wrote that in the WWW pages. | ||
+ | home was in error. | ||
+ | | ||
+ | @(A)c: Run (Down) the Software | ||
+ | |||
+ | From: sis319@educ.di.unito.it | ||
+ | |||
+ | Dear C=Hacking, | ||
+ | I really appreciate the work you are doing with the Commodore Hacking | ||
+ | on-line magazine. I like the new look and the new features you added, such | ||
+ | as newsfront and hacking the mags. | ||
+ | |||
+ | I would like to see on the magazine some reviews about the latest and more | ||
+ | interesting PD and Shareware software (with a list of FTP sites where these | ||
+ | are available) and hardware products. | ||
+ | |||
+ | Please note that Commodore Hacking is the only Commodore magazine I can | ||
+ | easily find here in Italy, because all the Italian magazine there were are | ||
+ | dead and all the foreign magazines that were distributed, | ||
+ | " | ||
+ | |||
+ | @(A)r: | ||
+ | We appreciate your comments about the new look of C=Hacking. | ||
+ | inclusion of reviews, we're looking into it. it's not that we don't want | ||
+ | to do it, just that we need to schedule the reviews (Commodore Hacking | ||
+ | shouldn' | ||
+ | software is worthy of review. | ||
+ | |||
+ | @(A)c: Separate But Equal | ||
+ | |||
+ | From: alan.jones@qcs.org (Alan Jones) | ||
+ | |||
+ | Dear C=Hacking, | ||
+ | I like your new version of C=Hacking. | ||
+ | relevant news and summaries of other magazines and disks. | ||
+ | be a constraint, although you should publish early when it exceeds some | ||
+ | critical size. Don't scrimp on source code listings and uuencoded files! | ||
+ | There is no other publication for this sort of bulky technical stuff. | ||
+ | It would also be wonderfull if we could get an apropriate means for | ||
+ | including diagrams or pictures, viewable by C64/128 users. | ||
+ | like to have the C64/128 html viewer/ | ||
+ | not know it but we came very close to having Al Angers Tower article | ||
+ | submitted to C=Hacking in place of _Commodore World_, but C=Hacking could | ||
+ | not really handle drawings and photos. | ||
+ | |||
+ | I have been separating C=Hacking into separate articles and files, archiving | ||
+ | them and placing the archive(s) on a local BBS. This compacts the length | ||
+ | and makes it easier to read and use. I try to make C=Hacking easy to | ||
+ | download and use locally, but I still want to keep it as whole and original | ||
+ | as possible. | ||
+ | |||
+ | @(A)r: | ||
+ | Alan, we're glad you approve of the new format. | ||
+ | the size so that it will always fit onto 2 1541 disk sides. | ||
+ | is still working on the HTML viewer, but it's taking a back seat to other | ||
+ | more pressing issues. | ||
+ | distributing the magazine that way as well. As for your separation, we | ||
+ | appreciate the work you've done to make C=Hacking easier to distribute. | ||
+ | With issue #12, we are offering an archive of all the article in separate | ||
+ | files. | ||
+ | C=Hacking MAILSERV server for the file. | ||
+ | |||
+ | Late news: check Commodore Hacking Information (Reference: info) for | ||
+ | more information of retrieving an archive of the individual articles. | ||
+ | |||
+ | @(A)c: Enquiring Minds Wanna Know! | ||
+ | |||
+ | From: Peter Hofman < | ||
+ | |||
+ | Dear C=Hacking | ||
+ | I would like to make a suggestion for your " | ||
+ | Maybe you could add a link to a page with some info about the next issue of | ||
+ | Commodore Hacking, so people know what will be in the next issue. The reason | ||
+ | why I make this suggestion is that I read the other issues, and I am very | ||
+ | curious, what will be published. | ||
+ | |||
+ | @(A)r: | ||
+ | Good suggestion. | ||
+ | can't completely predict the future, so the information in the link may | ||
+ | not exactly reflect the contents of the issue when it is published, but | ||
+ | we'll try to keep the two in sync. | ||
+ | |||
+ | @(A)c: Pulling It Out of the Closet | ||
+ | |||
+ | From: bloodbane@rlion.com (Jeffrey S Cotterman) | ||
+ | |||
+ | Dear C=Hacking, | ||
+ | Well, I was just writing to say I think you did a great job on C= | ||
+ | Hacking... I am throughly amazed by the support and the interest in | ||
+ | the Commodores. | ||
+ | I have not used any of them in a long time, I have two Beamers that I | ||
+ | use more. However seeing all this stuff makes me want to turn them back | ||
+ | on. (Actually I use the 64 quite a bit for playing games, plus the | ||
+ | 1702 monitor works great with a Super Nintendo!) | ||
+ | proficient at the 64, but it is slipping. | ||
+ | back in gear so maybe I can post an article or two.... Geesh, and just | ||
+ | last year I got rid of all my Run and Compute' | ||
+ | Oh well I will look through the cobwebs and see what I can come up | ||
+ | with. | ||
+ | |||
+ | @(Ar: | ||
+ | We appreciate the thanks. | ||
+ | or other CBM machines out of the closet and turn it back on through what we | ||
+ | do, it is worth it. | ||
+ | |||
+ | @(A)c: C=Hacking Flunked Geography | ||
+ | |||
+ | From: Peter Karlsson < | ||
+ | |||
+ | Dear C=Hacking, | ||
+ | I saw your mention of Atta Bitar in Commodore Hacking. | ||
+ | |||
+ | German? Heheheh... :-) | ||
+ | |||
+ | Anyway, the English information page is available now, but not much will=20 | ||
+ | be in English (sorry). It is a Swedish paper :) | ||
+ | |||
+ | From: Erik Paulsson < | ||
+ | |||
+ | Dear C=Hacking, | ||
+ | I'm the editor of the Swedish mag Atta Bitar (8 bitter), so I thought I | ||
+ | should drop you a line. | ||
+ | |||
+ | I really like the " | ||
+ | |||
+ | One small comment regarding Atta Bitar, it's not in German, it's in swedish. | ||
+ | I just thought you should know... | ||
+ | |||
+ | @(A)r: | ||
+ | Picky, picky, picky. | ||
+ | Commodore Hacking came from CANADA. | ||
+ | Correction made. Thanks for the update, and if we ever learn Swedish, we'll | ||
+ | try to read it again. | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== Newsfront ====== | ||
+ | < | ||
+ | |||
+ | * Matthew Desmond, the author of Desterm, has recently resurfaced and | ||
+ | | ||
+ | | ||
+ | | ||
+ | who wish to register Desterm or express their support. | ||
+ | |||
+ | * Speaking of email addresses, LOADSTAR will be changing theirs. | ||
+ | the online service GEnie has recently been purchased and new fares | ||
+ | have been put in place, LOADSTAR finds its monthly bill rising too | ||
+ | high for pleasure. | ||
+ | | ||
+ | |||
+ | * While we're on the subject of email addresses, CMD has expanded their | ||
+ | set of Internet email address contacts in order to better support its | ||
+ | | ||
+ | |||
+ | Email Address | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | World magazine. | ||
+ | |||
+ | | ||
+ | | ||
+ | be used items not applicable to the above | ||
+ | | ||
+ | |||
+ | | ||
+ | Sales and Marketing. | ||
+ | items not applicable to above email addresses. | ||
+ | |||
+ | * We're not done yet, as COMMODORE CEE has recently moved its office and | ||
+ | is now at: | ||
+ | |||
+ | |||
+ | COMMODORE CEE | ||
+ | 5443 College Oak Drive #26 | ||
+ | Sacramento, CA 95841 | ||
+ | Jack Vanderwhite@cee-64.wmeonlin.sacbbx.com (Contact) | ||
+ | ceejack@crl.com (Contact) | ||
+ | Jack Vanderwhite, | ||
+ | Fidonet: 1:203/999 | ||
+ | (916) 339-3403 (Bulletin Board System) | ||
+ | |||
+ | * The Commodore Zone. No, it's not an alternate universe, but a magazine | ||
+ | for the Commodore gamer and/or demo fan. Each issue' | ||
+ | of reviews, interviews with top programmers, | ||
+ | strip done by Alf Yngve. | ||
+ | tape containing game demos, demos, and full games. | ||
+ | often included. | ||
+ | |||
+ | More information can be obtained through: | ||
+ | |||
+ | Commodore Zone | ||
+ | 34 Portland Road | ||
+ | Droitwich | ||
+ | Worcestershire | ||
+ | WR9 7QW | ||
+ | England | ||
+ | |||
+ | | ||
+ | Zone PD. | ||
+ | | ||
+ | * Also in the magazine front, Computer Workshops, Inc. is planning a | ||
+ | World Wide Web magazine to feature gaming. | ||
+ | |||
+ | CWI is working on a new Web magazine to feature the newest and | ||
+ | hottest in c64/128 Gaming. But, before we can do that, we need | ||
+ | your help. Send us what you're working on, or, if you're a | ||
+ | programmer with something for review, send us that too! Also, | ||
+ | if you've got a product you'd like to advertise, we'd like to | ||
+ | hear that too (a la Yahoo). | ||
+ | |||
+ | Send it to either, or both: | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | ATTN: Commodore Gamer | ||
+ | 3612 Birdie Drive | ||
+ | La Mesa, CA 91941-8044 | ||
+ | |||
+ | (Please don't send binaries to the spectre@ address.) | ||
+ | | ||
+ | Thanks for your support, and barring any unforseen difficulties, | ||
+ | Commodore Gamer should be ready to premiere in about two months. | ||
+ | |||
+ | Cameron Kaiser | ||
+ | |||
+ | * The December 10, 1995 edition of the Waco Tribune Herald put one of our | ||
+ | own in the spotlight. | ||
+ | fans here, elsewhere." | ||
+ | | ||
+ | was Karen Allison, known on the FIDO network. | ||
+ | with Karen was Brad Jackson, of Commodore Country, who said that | ||
+ | a C64 was raced against an Intel 386 using identical programs, and | ||
+ | the 64 won. Allison claims in the article that "the challenge is finding | ||
+ | | ||
+ | | ||
+ | cost Tax program she uses to pay the IRS every year. Allison, a diehard | ||
+ | " | ||
+ | think my Commodore can't do much and is just a toy. But for a toy, | ||
+ | this computer does pretty good." | ||
+ | |||
+ | * For those good with an assembler and the VIC/SID registers, Driven | ||
+ | | ||
+ | 1st 1996. Although the program must run on an NTSC 64, PAL programmers | ||
+ | are encouraged to enter. | ||
+ | close of the contest, and entrants can re-use their entries. | ||
+ | | ||
+ | |||
+ | 4k Demo Contest Rules | ||
+ | |||
+ | - 1 file only (no secondary loading) | ||
+ | - max file size is $1000 bytes | ||
+ | - must be started with BASIC ' | ||
+ | - 1 demo per coder; multiple entries per group are allowed. | ||
+ | | ||
+ | as there remains only 1 demo per coder. | ||
+ | - credits for all parts of an entry must be given at time of entry; | ||
+ | if a particular credit is unknown, mark it as " | ||
+ | - demos will be evaluated on NTSC c64. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | coolhand@kaiwan.com | ||
+ | |||
+ | or postal mail to: | ||
+ | |||
+ | Bill Lueck | ||
+ | 17411 Mayor Lane | ||
+ | Huntington Beach, California, 92647 | ||
+ | USA | ||
+ | |||
+ | | ||
+ | other non-demomaking NTSC demo enthusiasts. | ||
+ | |||
+ | There will be categories for evaluation, but there will not be separate | ||
+ | | ||
+ | | ||
+ | but they will include design, originality, | ||
+ | | ||
+ | | ||
+ | |||
+ | * Bo Zimmerman has put his Commodore 128 on the net. No, he didn't | ||
+ | log into some Internet service from his 128, he actually PUT it on | ||
+ | the ' | ||
+ | | ||
+ | | ||
+ | bps, so don't hog the system, OK. | ||
+ | |||
+ | For the technical types, the 128 is connected to the serial port | ||
+ | of a Linux PC hooked up the Internet. | ||
+ | | ||
+ | |||
+ | * In the March 1996 issue of _Next Generation_ magazine, on pages 31 | ||
+ | and 32, NG published a very unflattering definition of the Commodore | ||
+ | 64 as part of their: "The Next Generation 1996 Lexicon A to Z: | ||
+ | A definitive guide to gaming terminology" | ||
+ | | ||
+ | | ||
+ | on early Apples. | ||
+ | but evidently had never used a C64 or never owned an early Apple II. | ||
+ | In either case, the fervor caused by the definition sparked an outrage | ||
+ | in the USENET newsgroup comp.sys.cbm. | ||
+ | for the scoop. | ||
+ | |||
+ | If you would like to write to _Next Generation_, | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | Email: | ||
+ | Fax: (415) 696-1678 | ||
+ | Phone: | ||
+ | | ||
+ | | ||
+ | |||
+ | Email: | ||
+ | Phone: | ||
+ | |||
+ | Post Office Mail: | ||
+ | |||
+ | Next Generation | ||
+ | Imagine Publishing, Inc. | ||
+ | 1350 Old Bayshore Highway, Suite 210 | ||
+ | Burlingame, CA 94010 | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== trick: RUN64: Moving to 64 Mode ====== | ||
+ | < | ||
+ | by Doug Cotton (doug.cotton@the-spa.com) | ||
+ | |||
+ | Reprinted with permission. Copyright (c) 1996 Creative Micro Designs, Inc. | ||
+ | |||
+ | Various routines have been used over the years to allow programs to move | ||
+ | from 128 mode to 64 mode without user intervention. With the advent of | ||
+ | modified Kernal ROMs (JiffyDOS, RAMLink, and others) many of the methods | ||
+ | that work on stock machines have either failed to do the job completely, | ||
+ | and in some cases fail all together. | ||
+ | |||
+ | RUN64 is the answer to those users looking to worm their way into | ||
+ | 64 mode without having to be concerned with the different Kernal ROMs. The | ||
+ | program is presented here in two ways: as a BASIC program that will move to | ||
+ | 64 mode and load the program you request, and as assembly language source | ||
+ | for ML programmers. | ||
+ | |||
+ | BASIC Notes: The BASIC version uses the ML code produced by the | ||
+ | assembly language source. This is found in the data statements beginning at | ||
+ | line 660. When you run it, the program will ask for the file name, device | ||
+ | number, and file load type (BASIC or ML). The first two parameters should | ||
+ | be self-explanatory, | ||
+ | loading is itself a small loader (1, 2 or 3 blocks) then it will almost | ||
+ | always be an ML program. Likewise, if you usually load the file with a | ||
+ | ", | ||
+ | larger file, or a file that you normally load with just a ", | ||
+ | the BASIC option. | ||
+ | |||
+ | Also, if you remove the REM instructions from lines 150 through 180 | ||
+ | the program becomes a dedicated loader. Just specify the file name and | ||
+ | other options within those lines. | ||
+ | |||
+ | @(A): How The Routine Works | ||
+ | |||
+ | RUN64 performs its trick by masquerading as a cartridge. | ||
+ | the code copies the payload routines into $8000, with the special header | ||
+ | that signifies a cartridge is present. | ||
+ | system initializes and checks for a cartridge. | ||
+ | routines, it executes them just like it would any cartridge. | ||
+ | pseudo-cartridge routines then switch out BASIC, call the remainder of | ||
+ | the KERNAL init routines, switch BASIC in, call some BASIC init routines, | ||
+ | set the " | ||
+ | keyboard buffer, and finally jump into the BASIC interpreter. | ||
+ | |||
+ | @(A): Assembly Language Notes: | ||
+ | |||
+ | The source code is pretty well documented, and ML programmers should have | ||
+ | little trouble figuring out what everything does. Take note of the Buddy | ||
+ | Assembler .off pseudo-op used a few lines below the code label. This | ||
+ | adjusts all fixed references within the code that follows it to execute | ||
+ | properly at $8000. | ||
+ | |||
+ | The code uses some indirect vectors (ibv, ibr and ibm) to overcome not | ||
+ | having an indirect jsr opcode, and switches out BASIC ROM temporarily since | ||
+ | the KERNAL finishes intializing by indirectly jumping through the address | ||
+ | at $a000. | ||
+ | must put its own address at $a000 to regain control. | ||
+ | |||
+ | To use the routine, just set up a file name at filename, put a | ||
+ | device number in $ba, set the load type in sa1flag, then execute the | ||
+ | routine. | ||
+ | |||
+ | |||
+ | 100 rem run64.bas (c) 1996 creative micro designs, inc. | ||
+ | 110 : | ||
+ | 120 print " | ||
+ | 130 print | ||
+ | 140 : | ||
+ | 150 rem f$=" | ||
+ | 160 rem dv=peek(186) | ||
+ | 170 rem l$=" | ||
+ | 180 rem goto 310 | ||
+ | 190 : | ||
+ | 200 input " | ||
+ | 210 input "{2 SPACES}device"; | ||
+ | 220 poke 186, | ||
+ | 230 dv = peek(186) | ||
+ | 240 print | ||
+ | 250 print " | ||
+ | 260 print "{2 SPACES}a. | ||
+ | | ||
+ | 270 print "{2 SPACES}b. | ||
+ | | ||
+ | 280 get l$ : if l$<>" | ||
+ | 290 print | ||
+ | 300 print l$;" selected" | ||
+ | 310 print | ||
+ | 320 print "going to 64 mode!" | ||
+ | 330 : | ||
+ | 340 : rem poke in main ml | ||
+ | 350 : | ||
+ | 360 i = 6144 | ||
+ | 370 read d | ||
+ | 380 if d = -1 then 450 | ||
+ | 390 poke i,d | ||
+ | 400 i = i + 1 | ||
+ | 410 goto 370 | ||
+ | 420 : | ||
+ | 430 : rem poke in filename | ||
+ | 440 : | ||
+ | 450 for i = 0 to len(f$)-1 | ||
+ | 460 : poke 6356+i, asc(mid$(f$, | ||
+ | 470 next i | ||
+ | 480 poke 6356+i,0 | ||
+ | 490 : | ||
+ | 500 : rem poke in device number | ||
+ | 510 : | ||
+ | 520 if dv$="" | ||
+ | 530 poke 186, | ||
+ | 540 : | ||
+ | 550 : rem check load type | ||
+ | 560 : | ||
+ | 570 poke 6324,0 | ||
+ | 580 if l$=" | ||
+ | 590 : | ||
+ | 600 : rem sys to ml | ||
+ | 610 : | ||
+ | 620 sys6144 | ||
+ | 630 : | ||
+ | 640 : rem ml data | ||
+ | 650 : | ||
+ | 660 data 32, | ||
+ | 670 data 153, | ||
+ | 680 data 141, | ||
+ | 690 data 9, | ||
+ | 700 data 0, | ||
+ | 710 data 22, | ||
+ | 720 data 169, | ||
+ | 730 data 160, | ||
+ | 740 data 252, | ||
+ | 750 data 32, | ||
+ | 760 data 189, | ||
+ | 770 data 232, | ||
+ | 780 data 240, | ||
+ | 790 data 162, | ||
+ | 800 data 210, | ||
+ | 810 data 240, | ||
+ | 820 data 49, | ||
+ | 830 data 255, | ||
+ | 840 data 186, | ||
+ | 850 data 157, | ||
+ | 860 data 128, | ||
+ | 870 data 157, | ||
+ | 880 data 108, | ||
+ | 890 data 86, | ||
+ | 900 data 56, | ||
+ | 910 data 34, | ||
+ | 920 data 82, | ||
+ | 930 data 78, | ||
+ | |||
+ | |||
+ | |||
+ | ; RUN64.SRC | ||
+ | ; Doug Cotton & Mark Fellows | ||
+ | ; (c) 1996 Creative Micro Designs, Inc. | ||
+ | ; | ||
+ | .org $1800 | ||
+ | .obj run64.obj | ||
+ | |||
+ | run64 | ||
+ | ; | ||
+ | ldy # | ||
+ | - | ||
+ | sta | ||
+ | iny | ||
+ | bne - | ||
+ | ; | ||
+ | lda | ||
+ | sta | ||
+ | ; | ||
+ | jmp | ||
+ | ; | ||
+ | code .byt $09,$80 ; cold start | ||
+ | .byt $09,$80 ; warm start | ||
+ | .byt $c3, | ||
+ | ; | ||
+ | .off $8009 ; offset code | ||
+ | ; | ||
+ | lda # | ||
+ | sta | ||
+ | sei ; disable interrupts | ||
+ | ; | ||
+ | lda # | ||
+ | sta | ||
+ | ; | ||
+ | jsr | ||
+ | jsr | ||
+ | lda # | ||
+ | sta | ||
+ | lda #< | ||
+ | sta | ||
+ | lda #> | ||
+ | sta | ||
+ | ; | ||
+ | jmp | ||
+ | ; | ||
+ | reenter lda # | ||
+ | sta | ||
+ | ; | ||
+ | jsr | ||
+ | jsr | ||
+ | jsr | ||
+ | ; | ||
+ | ldx # | ||
+ | - | ||
+ | beq + | ||
+ | jsr $ffd2 | ||
+ | inx | ||
+ | bne - | ||
+ | ; | ||
+ | + | ||
+ | - | ||
+ | beq | ||
+ | jsr $ffd2 | ||
+ | inx | ||
+ | bne - | ||
+ | |||
+ | ; | ||
+ | + | ||
+ | - | ||
+ | beq | ||
+ | jsr $ffd2 | ||
+ | inx | ||
+ | bne - | ||
+ | ; | ||
+ | + | ||
+ | beq | ||
+ | lda #',' | ||
+ | jsr | ||
+ | lda #' | ||
+ | jsr | ||
+ | ; | ||
+ | + | ||
+ | jsr $ffd2 | ||
+ | jsr $ffd2 | ||
+ | ; | ||
+ | lda | ||
+ | sta | ||
+ | ; | ||
+ | + | ||
+ | - | ||
+ | beq + | ||
+ | sta | ||
+ | inx | ||
+ | bne - | ||
+ | ; | ||
+ | + | ||
+ | bne | ||
+ | lda # | ||
+ | + | ||
+ | ; | ||
+ | jmp | ||
+ | ; | ||
+ | ibv | ||
+ | ibr | ||
+ | ibm | ||
+ | ; | ||
+ | dvtemp | ||
+ | sa1flag .byt $00 ; load type (1=ML, | ||
+ | ; 0=BASIC) | ||
+ | ; | ||
+ | part1 | ||
+ | .byt ' | ||
+ | .byt $22 ; quote | ||
+ | .byt $00 | ||
+ | ; | ||
+ | part2 | ||
+ | .byt ', | ||
+ | .byt $00 | ||
+ | ; | ||
+ | keydata .byt $0d ; [RETURN] | ||
+ | .byt ' | ||
+ | .byt $0d ; [RETURN] | ||
+ | .byt $00 | ||
+ | ; | ||
+ | filename | ||
+ | .byt $00 ; 00 byte must follow filename! | ||
+ | ; | ||
+ | .end | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== Hacking the Mags ====== | ||
+ | < | ||
+ | |||
+ | Not everything good and/or technical comes from Commodore Hacking, which | ||
+ | is as it should be. (I still think we have the most, though...) | ||
+ | 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' | ||
+ | publications available. | ||
+ | send complimentary copies of their publications for review. | ||
+ | | ||
+ | @(A): COMMODORE CEE | ||
+ | At press time, Issue #5 was in the works, so we'll detail the contents | ||
+ | next time. However, see Newsfront (Reference: news) for address changes | ||
+ | for COMMODORE CEE. | ||
+ | |||
+ | @(A): Commodore 128/64 Power User Newsletter (CPU) | ||
+ | A while back, Gosser Games, Ltd., Inc. sent us a sample issue of this | ||
+ | | ||
+ | | ||
+ | the BBS arena, the " | ||
+ | | ||
+ | | ||
+ | of GeoFAX and "Radio Controlled Flight Simulator" | ||
+ | | ||
+ | is small but full of potential. | ||
+ | |||
+ | @(A): Commodore World | ||
+ | If you remember last time we spoke of Commodore World, we asked the | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | at Hacking Headquarters. (just joshing, we can be so mean sometimes). | ||
+ | | ||
+ | | ||
+ | | ||
+ | Kudos to CMD for that effect. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | for reference. CMD also takes time to note that the SuperCPU cartridge | ||
+ | will contain a 65C816 8/16 bit CPU, not the earlier mentioned 65C02 | ||
+ | 8-bit CPU. | ||
+ | |||
+ | Issue 12 should be subtitled the " | ||
+ | | ||
+ | | ||
+ | ntes that the 10 MHz version has been scrapped, but the 128 version | ||
+ | has been added, dealying introduction until April for the 64 version. | ||
+ | C=H was hoping to review a prototype unit this issue, but we'll do it | ||
+ | next time. Jason Compton and Katherine Nelson describe HTML, the | ||
+ | | ||
+ | using KERNAL devices 0 (keyboard) and 3 (screen). | ||
+ | to run a Bulletin Board System, Max Cottrell describes how to ensure | ||
+ | | ||
+ | | ||
+ | funky graphics.... | ||
+ | |||
+ | @(A): Driven | ||
+ | | ||
+ | tone expresses a tinge of disappoinment with the hope that 1996 will | ||
+ | be a better year for demos. | ||
+ | crack at covering the PAL scene. | ||
+ | a complete list of releases is given. | ||
+ | | ||
+ | of Triad discusses the origins of the demo scene in " | ||
+ | |||
+ | If you've ever wondered what goes on inside the mind of a demo " | ||
+ | | ||
+ | the group FOE and Zyron of F4CG are included, both telling it as it is. | ||
+ | For those wanting to set up or design a BBS system Mitron takes a look | ||
+ | at CNET DS2 and details some general guidelines on how the networking | ||
+ | code works. | ||
+ | | ||
+ | |||
+ | @(A): LOADSTAR | ||
+ | Issue 139 starts off with the announcement that LOADSTAR is taking over | ||
+ | the dieHard Spinner disk subscriptions, | ||
+ | Base 64 from John Serafino will be useful for anyone organizing their | ||
+ | disk collection. | ||
+ | | ||
+ | | ||
+ | Jeff delivers. | ||
+ | | ||
+ | |||
+ | As we started Issue 140, we noticed something was different. | ||
+ | | ||
+ | | ||
+ | can be changed and saved. | ||
+ | mark up text using highlights, bold, and underline on printers that | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | as Issue 11 is reprinted in the 3.5" version. | ||
+ | | ||
+ | in detail the CIA TOD clocks and their bugs, err " | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | Right before we went to press, issue 141 showed up in the mailbox. | ||
+ | | ||
+ | was taken over by J & F Publishing. | ||
+ | |||
+ | | ||
+ | 606 Common Street | ||
+ | | ||
+ | |||
+ | Also, they say checks should now be made out to LOADSTAR, not Softdisk. | ||
+ | |||
+ | For all you TUI (Text User Interface) folks, Jeff Jones goes over how | ||
+ | to create " | ||
+ | is provided as well, which is rare for LOADSTAR. | ||
+ | to us was Terry Flynn' | ||
+ | it displays impossible constructions and 3D illusions. | ||
+ | some space, as issues 3 and 4 are available on the 3.5" disk version. | ||
+ | Jim Brain supplies article 4 in the Internet series on LOADSTAR LETTER | ||
+ | #31, included with the issue. | ||
+ | | ||
+ | | ||
+ | |||
+ | @(A): LOADSTAR 128 | ||
+ | We loaded up LS128 #30 for a look-see. | ||
+ | | ||
+ | one focus of this issue. | ||
+ | | ||
+ | | ||
+ | Craig Bruce. | ||
+ | |||
+ | @(A): Vision | ||
+ | At press time, Issue #8 was in the works, so we'll detail the contents | ||
+ | next time. | ||
+ | |||
+ | Other magazines not covered in this rundown include: | ||
+ | |||
+ | * _The Underground_ | ||
+ | * _Gatekeeper_ | ||
+ | * _Commodore Network_ | ||
+ | * _64' | ||
+ | * _Atta Bitar_ (_8 bitter_) | ||
+ | * _Commodore Zone_ | ||
+ | * _Commodore Gazette_ | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== Polygonamy: A Study in 3 Dimensions ====== | ||
+ | < | ||
+ | by Stephen L. Judd (sjudd@nwu.edu) | ||
+ | |||
+ | We've been making some pretty small potatoes for a while now, so | ||
+ | the time has come for a little more ambition and challenge. | ||
+ | think up a real challenge, containing problems that I had no idea how to | ||
+ | solve, and see what I could come up with. | ||
+ | |||
+ | I set out to create a 3D virtual world for the C64, e.g. a space | ||
+ | populated with various three-dimensional objects, which I could wander around | ||
+ | in. I wanted it to be full-screen 320x200 hires bitmapped. | ||
+ | wanted the objects to be solid, and since there are only two colors I | ||
+ | wanted to be able to put patterns on the faces. | ||
+ | translate nicely to the 128's VDC chip, in 2MHz mode. Finally, naturally, I | ||
+ | wanted the program to be fast. This was the framework in which I placed | ||
+ | myself, and a few other ideas presented themselves along the way. The | ||
+ | outcome of all of this is Polygonamy. | ||
+ | |||
+ | Just a brief history of this project: I have wanted to do a 3D | ||
+ | world for a very long time, and have been thinking about it for some | ||
+ | time in the back of my head; my imagination was probably first fired | ||
+ | the first time I played Elite. | ||
+ | afternoon last summer, for a high school student I was teaching, and | ||
+ | the equations are very simple. | ||
+ | measureable value accomplished, | ||
+ | algorithm. | ||
+ | finally began to code the graphics. | ||
+ | Adding the rest took a few weekends more. I have about 128 pages of notes, | ||
+ | analytical calculations, | ||
+ | is, I think, a nice number of pages to have :). My original plans were | ||
+ | to place five objects in the world, but time and memory constraints whittled | ||
+ | that down to three. | ||
+ | ready to finish, so I had to reconstruct a bunch of tables, but other than | ||
+ | that I finally managed to finish it up, albeit with a few rough edges ;). | ||
+ | |||
+ | Although the concepts from previous articles are used as a solid | ||
+ | foundation, the code is almost 100% from scratch -- I only borrowed a | ||
+ | tiny piece of code from an earlier program, and even that I modified | ||
+ | somewhat. | ||
+ | |||
+ | One caveat before we begin: I am primarily interested in the | ||
+ | challenge of designing the algorithms, which means I like to come up | ||
+ | with my own solutions. | ||
+ | in a graphics book or perhaps in someone else's code; I have examined | ||
+ | neither, so I have no idea what the relative merit of my algorithms | ||
+ | may be. These are simply my solutions to challenges placed before me. | ||
+ | And if you know of a better way to do things, please feel free to email | ||
+ | me! | ||
+ | |||
+ | Furthermore, | ||
+ | assumptions work and some do not, and these will be considered at the end | ||
+ | of this article. | ||
+ | |||
+ | Finally, I am not including the source code. For one thing, it is big. | ||
+ | Like, _HUGE_, man. I had to split it up when I ran out of editor memory | ||
+ | on my 128 (which, incidentally, | ||
+ | cool and very powerful linker feature). | ||
+ | fragments in assembly and BASIC which demonstrate all the important | ||
+ | concepts. | ||
+ | |||
+ | By the way, if you are interested in measuring frame rates, you can | ||
+ | use the first object. | ||
+ | So time how long it takes to complete a full rev (or maybe several), and | ||
+ | divide that number into 128, to get an idea of frames per second. | ||
+ | For a rundown of frame rates for stock and SuperCPU operation, see | ||
+ | " | ||
+ | elsewhere in thi issue. | ||
+ | |||
+ | Some brief acknowledgements: | ||
+ | the extremely powerful macro and linking capabilities of the Merlin 128 | ||
+ | assembler, by Glen Bredon. | ||
+ | JiffyDOS and my FD-2000, from CMD. I used my Action Replay extensively | ||
+ | for debugging, and without the excellent documentation for the 64, such as | ||
+ | the PRG and Mapping the 64, this would have been a nightmare. | ||
+ | must acknowledge my friend George Taylor; a few days before I was all | ||
+ | finished I explained some routines to him, and he made a great suggestion | ||
+ | which made my fast fill routine blaze. | ||
+ | |||
+ | Okay, WAY too much talk. There are a ton of issues involved with this | ||
+ | project so let's just wade in hip-deep and deal with them as they come. | ||
+ | |||
+ | @(A): The Equations | ||
+ | ------------- | ||
+ | |||
+ | First some relaxing abstraction. | ||
+ | how to project an object in three dimensions through the origin into a | ||
+ | plane. | ||
+ | principle, then, we have all the mathematics we need to do a 3D world. | ||
+ | |||
+ | But we should be thoughtful. | ||
+ | turn to the right; we can either rotate ourselves, and change the | ||
+ | direction we are looking, or we can rotate the world around us, so that | ||
+ | we are always looking ' | ||
+ | but the two are mathematically equivalent. | ||
+ | our projection routines, it should be clear that we want to rotate the | ||
+ | objects in the world around us. | ||
+ | |||
+ | (Or, to put it another way, we are at the center of the world, and the | ||
+ | world revolves around us.) | ||
+ | |||
+ | We have another issue: how do we know when an object is visible or not? | ||
+ | How do we know when we've bumped into an object (or blown it out of the | ||
+ | sky :)? Moreover, if we have ten objects, and each object has six points, | ||
+ | it would be a real drag to have to rotate all sixty points, especially | ||
+ | if none of the objects were even visible. | ||
+ | |||
+ | It should be clear that we really want to define every object relative | ||
+ | to some center of the object. | ||
+ | object, and rotate and translate the centers, and only calculate the | ||
+ | full object if it is visible. | ||
+ | relative to this center. | ||
+ | |||
+ | What happens to this center when we translate or rotate the world? | ||
+ | |||
+ | Let's simplify our model a little bit and only deal with rotations about | ||
+ | one axis, e.g. we are driving a tank and can move forwards and backwards, | ||
+ | and turn left or right. | ||
+ | straightforward, | ||
+ | of three. | ||
+ | |||
+ | First we need to agree on a coordinate system. | ||
+ | x-axis go _up_ a page of paper, the y-axis comes up out of the page, and | ||
+ | the z-axis goes from left to right. | ||
+ | the x-z plane, at the origin, with the y-axis extending upwards from me. | ||
+ | If you still don't understand my orientation, | ||
+ | |||
+ | I am going to choose my orientation so that I am always looking straight | ||
+ | down the x-axis, e.g. in the direction that x is increasing. | ||
+ | walk forwards or backwards, this corresponds to decreasing or increasing | ||
+ | the x-component of the center coordinate: | ||
+ | |||
+ | let C=(cx, | ||
+ | move forwards => cx=cx-1 | ||
+ | move backwards=> | ||
+ | |||
+ | So far so good. As always, draw a picture if you can't visualize it. | ||
+ | That takes care of translations, | ||
+ | |||
+ | We certainly know how to rotate points about the origin. | ||
+ | if we have a point with coordinates (x1,z1) and rotate it clockwise by | ||
+ | an angle s, we get the new point as follows: | ||
+ | |||
+ | | ||
+ | |||
+ | So that's easy enough. | ||
+ | sitting around this point, and need to figure out what to do with it! | ||
+ | |||
+ | Consider the following: let's say we have a line out some distance from | ||
+ | the origin, | ||
+ | |||
+ | X | ||
+ | X | ||
+ | | X | ||
+ | | ||
+ | | X | ||
+ | | X | ||
+ | Origin | ||
+ | |||
+ | and we rotate it by some amount theta about the origin: | ||
+ | |||
+ | X | ||
+ | XX | ||
+ | | ||
+ | | | ||
+ | | ||
+ | | X | ||
+ | XX | ||
+ | |||
+ | You can see (from my incredible ASCII artwork) that the line is now at an | ||
+ | angle with respect to the origin. | ||
+ | |||
+ | Imagine that we draw a line from the origin to the center of the point, | ||
+ | in the first picture (or get a pencil and paper and actually do it), so | ||
+ | that we have the letter " | ||
+ | by some angle theta, so that the top of the " | ||
+ | been rotated. | ||
+ | |||
+ | The stem of the " | ||
+ | a line from the rotated center straight down to the z-axis, and call this | ||
+ | line l2. Since the T is at a right angle, and we have rotated it by an | ||
+ | angle theta, the angle between our line and the z-axis is 90-theta. | ||
+ | this means that the angle between our line (the top of the " | ||
+ | line l2 is just theta. | ||
+ | |||
+ | Thus, if we rotate the center by an amount theta, all we have to do | ||
+ | is rotate the object by an amount theta *about the center*, and our | ||
+ | perspectives will all be correct. | ||
+ | be clear now that this works no matter where the " | ||
+ | is chosen. | ||
+ | but rather the center of rotation of the object. | ||
+ | |||
+ | Since this is true of rotations about any axis, we now know how to | ||
+ | generalize to higher dimensions. | ||
+ | |||
+ | Note further that we can now implement local rotations -- that is, let' | ||
+ | say the object is a tank, and this tank turns independently of whether | ||
+ | or not we turn. Piece of cake. | ||
+ | |||
+ | You can also see that the rotations are cumulative. | ||
+ | left, and then turn left again, we can simply apply two rotations to the | ||
+ | points of the object. | ||
+ | move left again, we still apply just two rotations to the points of the | ||
+ | object; the center, however, has moved. | ||
+ | |||
+ | This is quite important, as it allows us to measure an object' | ||
+ | rotation to us, whether or not it is visible. | ||
+ | want to rotate the points that define an object when the object is | ||
+ | visible. | ||
+ | Instead, we track how much the object needs to rotate, and rotate the | ||
+ | original points by that amount. | ||
+ | |||
+ | The center of the object will change with each rotation and translation. | ||
+ | We never change how we define an object about this center, though. | ||
+ | simply apply a rotation to the original points when appropriate. | ||
+ | object centers must be kept track of because they can undergo translation | ||
+ | as well as rotation. | ||
+ | |||
+ | To summarize then: we define each object relative to a center of | ||
+ | rotation. | ||
+ | world, and allows us to operate on centers when we need to rotate or | ||
+ | translate the world. | ||
+ | object, so that we could, for instance, have a spinning cube located | ||
+ | inside our world. | ||
+ | the object to be visible, and plot it. | ||
+ | |||
+ | Whoops -- what does it mean to be ' | ||
+ | You can see things when they are in front of you. Or, to be more | ||
+ | precise, you have a field of vision. | ||
+ | would be a cone. I think a better model, certainly one which is | ||
+ | easier to deal with computationally, | ||
+ | a pyramid. | ||
+ | and anything which lies outside we consider not visible. | ||
+ | |||
+ | Two-dimensionally, | ||
+ | Anything within the wedge we count as visible, and anything outside | ||
+ | of it we count as not visible. | ||
+ | with equal but opposite slope (i.e. slope=+/ | ||
+ | | ||
+ | \ Visible / | ||
+ | \ View / Outside of visual area | ||
+ | \Area / | ||
+ | \ / | ||
+ | \ / | ||
+ | * <--- Me | ||
+ | |||
+ | Probably lines at some angle are more reasonable than others. | ||
+ | simple guy, and the two simplest lines I can draw are at 45 degree angles | ||
+ | from the axis, so their slope is +/-1. Thus, any points which lie | ||
+ | between the lines x+z=0 and x-z=0 are visible. | ||
+ | object is within this area, we will consider the object visible. | ||
+ | is, if cx+cz>0 and cx-cz>0 the object is visible. | ||
+ | |||
+ | One last thing: if we are too close to the object, we either want to | ||
+ | bump into it (i.e. not move) or else not display it. So we also need to | ||
+ | check if cx<x0 for some x0. | ||
+ | |||
+ | We are now in a position to write some simple code. I wrote the | ||
+ | following in evil Microsoft QBasic, but BASIC7.0 on the 128 would work | ||
+ | just as well, although you need to change the variables (I didn't have my | ||
+ | 128 handy, otherwise I would have written this on the 128): | ||
+ | |||
+ | @(A): Polygon Prototype Code | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | rad= 3.1415926/ | ||
+ | cdel= COS(rad*delta) | ||
+ | sdel= SIN(rad*delta) | ||
+ | | ||
+ | | ||
+ | x0= 60 ' | ||
+ | REM z0 y0 would be 160,100 to place the object in the center | ||
+ | REM of the screen | ||
+ | y0= 170 'I want the bottom of screen to be ground | ||
+ | z0= 160 | ||
+ | |||
+ | REM Set up the object | ||
+ | REM Tetrahedron: | ||
+ | DIM obx(4), oby(4), obz(4) | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | cx= 100 | ||
+ | cy= -10 | ||
+ | cz= 0 | ||
+ | |||
+ | REM Get input | ||
+ | main: | ||
+ | |||
+ | DO | ||
+ | | ||
+ | LOOP UNTIL a$<>"" | ||
+ | |||
+ | IF a$=" | ||
+ | IF a$="/" | ||
+ | IF a$=";" | ||
+ | IF a$="'" | ||
+ | |||
+ | IF cx<x0 THEN CLS: GOTO main: | ||
+ | IF cx<cz OR cx+cz<0 THEN CLS: GOTO main: | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | p1x= cx + ctheta*obx(1) + stheta*obz(1) | ||
+ | p1y= cy + oby(1) | ||
+ | p1z= cz + ctheta*obz(1) - stheta*obx(1) | ||
+ | p1y= y0 + d*p1y/ | ||
+ | p1z= z0 + d*p1z/p1x | ||
+ | [... similar for p2x, | ||
+ | |||
+ | CLS | ||
+ | LINE (p1z, p1y)-(p2z, p2y) | ||
+ | [... lines between p2-p3, p3-p1, p1-p4, p4-p2, p4-p3] | ||
+ | |||
+ | GOTO main: 'Main loop | ||
+ | |||
+ | REM rotate left | ||
+ | rotl: | ||
+ | | ||
+ | blah= cdel*cx + sdel*cz | ||
+ | cz= -sdel*cx + cdel*cz | ||
+ | cx= blah | ||
+ | | ||
+ | |||
+ | rotr: | ||
+ | | ||
+ | blah= cdel*cx - sdel*cz | ||
+ | cz= sdel*cx + cdel*cz | ||
+ | cx= blah | ||
+ | | ||
+ | |||
+ | (You may note that cx=cx+20 is used for a translation, | ||
+ | This will be detailed later). | ||
+ | |||
+ | So much for the easy part. | ||
+ | |||
+ | @(A): Filling | ||
+ | ------- | ||
+ | |||
+ | If there is one thing that the previous programs have taught us, it is | ||
+ | that graphics are slow. At least, they are far and above the major thing | ||
+ | slowing down the program, and deserve the most attention and thought for | ||
+ | improvement. | ||
+ | elimination of just a few instructions can translate to thousands of | ||
+ | cycles saved. | ||
+ | | ||
+ | We have examined several fill routines up to now, but neither of them is | ||
+ | up to the task of Polygonamy. | ||
+ | allow multiple objects, and certainly doesn' | ||
+ | an EOR-buffer is just plain slow and inefficient and a big drag. So it's | ||
+ | time to rethink this problem. | ||
+ | | ||
+ | Recall that on the 64 the bitmap screen is divided into 8x8 cells, which | ||
+ | are arranged horizontally in rows. It's a pretty kooky way of doing | ||
+ | things, but we shall overcome. | ||
+ | |||
+ | First of all it should be clear that we want to fill from left to right | ||
+ | (as opposed from top to bottom). | ||
+ | instead of dinking in little pixels at a time. | ||
+ | |||
+ | Previously we used a custom character set to plot into. One of the major | ||
+ | reasons for doing so was to use Y as the Y-coordinate, | ||
+ | particular point was as simple as STA COLUMN, | ||
+ | idea, but only within each row. That is, if we let Y=0..7, we can address | ||
+ | each individual pixel-row within each 8x8 block row with an STA ADDRESS,Y. | ||
+ | |||
+ | For real speed, we are going to want an unrolled fill routine. | ||
+ | we don't want to mess around with loop counters and updating pointers and | ||
+ | such. Since there are 25 rows on the screen (25 times 8 = 200 pixels | ||
+ | high) we are probably going to need 25 separate fill routines. | ||
+ | |||
+ | I constructed my fill routine as follows: | ||
+ | |||
+ | STA COL1,Y | ||
+ | DEX | ||
+ | BEQ :DONE | ||
+ | STA COL2,Y | ||
+ | DEX | ||
+ | BEQ :DONE | ||
+ | STA COL3,Y | ||
+ | ... etc. | ||
+ | : | ||
+ | |||
+ | Thus X would be my counter into the number of columns to fill, A can | ||
+ | contain our pattern to fill with, and Y can range from 0..7 to index the | ||
+ | individual rows within the block. | ||
+ | STA/DEX/BEQ code chunk is six bytes. | ||
+ | which row to start filling at, multiply by six, and add that number to | ||
+ | the start of the fill routine. | ||
+ | place in the fill, and let it fill the right number of columns, stored in | ||
+ | X. | ||
+ | |||
+ | There is a little problem though -- what we're talking about doing is an | ||
+ | indirect JSR, and there is no such thing. | ||
+ | because we can use an indirect JMP. So a call to the fill routine would | ||
+ | look like the following: | ||
+ | |||
+ | ... | ||
+ | JSR FILL | ||
+ | ... | ||
+ | FILL JMP (ADDRESS) | ||
+ | |||
+ | where ADDRESS simply points to the correct entry point in the fill routine. | ||
+ | |||
+ | Moreover, you may also note that 40 columns times 6 bytes/ | ||
+ | bytes, so that each little fill routine handily fits in a page. Thus, | ||
+ | moving between rows in the bitmap corresponds to a simple decrement or | ||
+ | increment of the high byte of the ADDRESS pointer. | ||
+ | |||
+ | This was the state of things when, days before I was to be all done with | ||
+ | Polygonamy, I mentioned it to my friend George Taylor, who suggested the | ||
+ | following modification: | ||
+ | fill, just make the fill routine: | ||
+ | |||
+ | STA COL1,Y | ||
+ | STA COL2,Y | ||
+ | STA COL3,Y | ||
+ | ... | ||
+ | |||
+ | Then, insert an RTS into the right place in the routine. | ||
+ | calculate which column to stop filling at, multiply by three, and stick | ||
+ | an RTS in the fill routine at that point. | ||
+ | STA ..,Y back on top of the RTS. | ||
+ | | ||
+ | I don't think you're going to make a fill routine faster than that :). | ||
+ | |||
+ | Moreover, note that each fill routine takes up just 120 bytes, so we can | ||
+ | now fit two fill routines in each page. I did not do this, but it is | ||
+ | easy to do, and instantly frees up 25 pages. | ||
+ | |||
+ | @(A): Filled Polygons | ||
+ | --------------- | ||
+ | | ||
+ | I mean, hey, this _is_ " | ||
+ | them. | ||
+ | |||
+ | Clearly all that is needed to draw an object are the left and right | ||
+ | endpoints of the object, since everything in-between will be filled. | ||
+ | |||
+ | An observation to make is that if you take a slice out of a convex | ||
+ | polygon, the slice will intersect the polygon at exactly two points. | ||
+ | Another, more important, observation is to note that the highest and | ||
+ | lowest point of a polygon will always be at a vertex. | ||
+ | important to note that any vertex of a polygon has exactly two lines | ||
+ | extending out of it, one to the left, and one to the right. | ||
+ | |||
+ | Consider a piece of a polygon: | ||
+ | |||
+ | \ / | ||
+ | | ||
+ | \ / | ||
+ | | ||
+ | \ / | ||
+ | | ||
+ | |||
+ | where the vertex v0 is the lowest point of the polygon. | ||
+ | to be done is to move upwards (DEY), compute the left and right points | ||
+ | of the polygon at that point, and then fill between the two (JSR FILL). | ||
+ | | ||
+ | The idea then is to start at the bottom (or the top) and to steadily move | ||
+ | upwards while _simultaneously_ calculating the endpoints of the left and | ||
+ | right lines, and filling in-between. | ||
+ | left and right lines to do this. | ||
+ | | ||
+ | Now it's time for another observation. | ||
+ | n vertices v1, v2, ..., vn, and furthermore that as we move between these | ||
+ | points we move around the polygon counter-clockwise. | ||
+ | right of v2, v1 is to the left of v2, v4 is to the right of v3, etc. | ||
+ | For example: | ||
+ | |||
+ | v1____v3 | ||
+ | \ / | ||
+ | \/ | ||
+ | v2 | ||
+ | |||
+ | What happens if we rotate this polygon? | ||
+ | |||
+ | v2____v1 | ||
+ | \ / | ||
+ | \/ | ||
+ | v3 | ||
+ | |||
+ | The vertices have changed position, but *their order has not*. v3 is | ||
+ | still to the right of v2, and v1 is still to the left. | ||
+ | |||
+ | Now we have a real plan. We simply define the polygon as a list of | ||
+ | points v1 v2 v3 ... vn. We then figure out which one is lowest, i.e. has | ||
+ | the smallest (or greatest) y-coordinate, | ||
+ | endpoints of the left and right lines are vm-1,vm and vm, | ||
+ | along those lines until the next vertex is reached. | ||
+ | recompute the appropriate line, and keep moving upwards until the top of | ||
+ | the polygon is reached. | ||
+ | |||
+ | Perhaps an example would be helpful: | ||
+ | |||
+ | v1 | ||
+ | |\ | ||
+ | | \ v3 | ||
+ | | / | ||
+ | |/ | ||
+ | v2 | ||
+ | |||
+ | v2 is the minimum. | ||
+ | line has endpoints (v2, | ||
+ | lines as we creep upwards. | ||
+ | we compute a new equation for the right line, this time with endpoints | ||
+ | (v3, | ||
+ | right lines, until we hit v1, at which point we are finished. | ||
+ | |||
+ | It is important to keep in mind that the order of the points never | ||
+ | changes. | ||
+ | points; we only need to find the lowest point, and branch left and right | ||
+ | from there, keeping in mind that the points are cyclic (i.e. v1 is to the | ||
+ | right of vn). | ||
+ | |||
+ | It is now time to start thinking about code. One aspect of the fill | ||
+ | routine we haven' | ||
+ | buffer was cleared and then the new stuff was drawn into it. But this | ||
+ | seems like a bit of a waste; it seems wasteful to clear a bunch of memory | ||
+ | that is just going to be overwritten again. | ||
+ | efficiently, | ||
+ | |||
+ | Here is how Polygonamy does it: If a line needs to be cleared, then it | ||
+ | is cleared up to the edges of the object, but the part that is going to | ||
+ | be filled is ignored. | ||
+ | efficiency gains, though). | ||
+ | |||
+ | To see the status of a particular line, a table is used, containing a | ||
+ | value for each Y-coordinate. | ||
+ | if it's 0 then the line has old junk in it, and if it's 1 then the line | ||
+ | has new junk in it. Thus we only clear the line if its entry in the fill | ||
+ | table is a zero. | ||
+ | |||
+ | So a fill routine might flow like the following: | ||
+ | |||
+ | let Y count from 7..0 | ||
+ | |||
+ | If we are at the left endpoint then recalculate the left line. | ||
+ | If we are at the right endpoint the recalculate the right line. | ||
+ | | ||
+ | If line needs to be cleared then clear line. | ||
+ | If the starting fill column is different than the previous fill | ||
+ | | ||
+ | Plot the left and right endpoints (since the fill routine only plots | ||
+ | eight bits at a time) | ||
+ | Fill the in-between parts | ||
+ | | ||
+ | If Y passes through zero then update fill entry point, set Y=7 etc. | ||
+ | Keep going until we reach the top | ||
+ | |||
+ | The next thing to figure out is how to calculate the left and right | ||
+ | lines. | ||
+ | to the left and right endpoints, but clearly this isn't too efficient. | ||
+ | |||
+ | The question is: if the y-coordinate increases by one, then how much does | ||
+ | the x-coordinate increase by? The equation of a line is: | ||
+ | |||
+ | | ||
+ | |||
+ | or | ||
+ | |||
+ | | ||
+ | |||
+ | So, if the change in y is 1, then then the change in x is 1/m. All we | ||
+ | need to do then is calculate the inverse-slope=dx/ | ||
+ | dy=y2-y1, and add this to the x-coordinate with each step in y. | ||
+ | |||
+ | Isn't this a fraction? | ||
+ | as dx/dy = N + Rem/dy, where N is an integer, and Rem is the remainder, | ||
+ | which is always less than dy. So to calculate x=x+dx/dy: | ||
+ | |||
+ | x= x+N | ||
+ | xrem= xrem+Rem | ||
+ | If xrem>=dy then x=x+1: | ||
+ | |||
+ | As usual, we want to start xrem at dy/2, which has the effect of rounding | ||
+ | numbers up. | ||
+ | |||
+ | 10 REM LINE ROUTINE TAKE TWO SLJ 11/24/95 | ||
+ | 12 REM ACTUALLY IT'S A FILL RTY NOW | ||
+ | 15 GRAPHIC 1,1 | ||
+ | 20 X0=160: | ||
+ | 30 X1=5: | ||
+ | 35 X3=50: | ||
+ | 40 D1=Y2-Y1+1: | ||
+ | 45 TL=INT(D1/ | ||
+ | 46 D2=Y4-Y3+1: | ||
+ | 48 TR=INT(D2/ | ||
+ | 50 DRAW1, X0+X1,Y0-Y1 TO X0+X2, | ||
+ | 60 REM MAIN LOOP | ||
+ | 70 XR=XR+RI: | ||
+ | 75 DRAW1, X0+XL,Y0-Y TO X0+XR,Y0-Y | ||
+ | 80 XL=XL+LI: | ||
+ | 90 REM DRAW1, X0+XL,Y0-Y TO X0+XR,T0-T | ||
+ | 100 Y=Y+1:IF Y<=Y2 THEN 60 | ||
+ | |||
+ | In this program (x1, | ||
+ | the right line. The first thing to note is that in lines 40 and 46, | ||
+ | Y=y2-y1+1. | ||
+ | 3D-graphics article. | ||
+ | anatomically correct with DY=y2-y1, it will look silly. | ||
+ | to see this is to consider y2-y1=1, e.g. say we draw a line between | ||
+ | (0,10) to (50, | ||
+ | one from (0,10) to (25,10) and the other from (26,11) to (50, | ||
+ | we use DY=1 we will have one line segment from (0,10) to (50,10), and a | ||
+ | single point at (50,11). | ||
+ | |||
+ | Adding one to DY is just a simple cheat. | ||
+ | look just fine, but lines which have a slope near one will come out a bit | ||
+ | wrong. | ||
+ | article, is more complicated to implement in this routine. | ||
+ | DY will also have a useful benefit which we shall shortly see. | ||
+ | |||
+ | In line 50 above the boundaries of our object are drawn in, to check the | ||
+ | accuracy of the algorithm. | ||
+ | |||
+ | In lines 70-80 the right point is updated, then the thing is filled, then | ||
+ | the left point is updated. | ||
+ | right, e.g. they both have positive slope. | ||
+ | segments will be drawn; in general, we want to draw from the left end of | ||
+ | the left line segment to the right end of the right line segment. | ||
+ | (Sometimes this will look a little off where the two lines meet). | ||
+ | |||
+ | Since the left and right lines can each have either positive or negative | ||
+ | slopes, there are four possibilities: | ||
+ | and Minus-Plus. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | If this is still confusing, try out the above program with various left | ||
+ | and right line segments, and these things will jump right out. | ||
+ | |||
+ | Now we need to think about implementing this in assembly. | ||
+ | being done in hires 320x200, the x-coordinate requires two bytes, and the | ||
+ | y-coordinate requires one. We also need another byte to store the | ||
+ | remainder portion of the x-coordinate. | ||
+ | |||
+ | The most glaring question is the calculation of dx/dy: somehow we need a | ||
+ | fast way of exactly dividing an eight bit number dy into a nine bit | ||
+ | number dx. Recall that we always add one to dy, so that dy actually | ||
+ | ranges from 2 to 200. Since the maximum value of dx is 320 or so, the | ||
+ | largest value of dx/dy that we can have is 320/2 = 160. In other words, | ||
+ | both the integer and remainder part of dx/dy will fit in a byte. Simply | ||
+ | adding one to dy makes life pretty easy at this end. | ||
+ | |||
+ | One very fast method of doing division is of course by using logarithms. | ||
+ | But they have a problem with accuracy. | ||
+ | know how to do very quickly is multiplication. | ||
+ | |||
+ | This then is the plan: use logarithmic division to get an estimate for N, | ||
+ | the integer part. Then calculate N*dy, compare with dx, and adjust the | ||
+ | integer part accordingly. | ||
+ | |||
+ | A quick reminder of how logarithms can be used for division: | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | thus | ||
+ | |||
+ | a/b = exp(log(a)-log(b)). | ||
+ | |||
+ | How do we take the log of a 9-bit number? | ||
+ | construct a table of f(x)=log(2*x), | ||
+ | parameter. | ||
+ | integer part. | ||
+ | |||
+ | Moreover, if the tables are constructed carefully we can insure that the | ||
+ | estimate for N is either exact or too small. | ||
+ | for undershoots, | ||
+ | particular, the tables were constructed as follows: | ||
+ | |||
+ | 10 DIM L1%(160), L2%(200), EX%(255): C=255/ | ||
+ | 20 FOR I=1 TO 160 | ||
+ | 30 L1%(I)=INT(C*LOG(I)) | ||
+ | 40 NEXT | ||
+ | 50 FOR I=2 TO 200 | ||
+ | 60 L2%(I)=INT(C*LOG(I/ | ||
+ | 70 NEXT | ||
+ | 80 FOR I=0 TO 255 | ||
+ | 90 EX%(I)=INT(EXP(I/ | ||
+ | 95 IF(I=129)OR(I=148)OR(I=153)OR(I=81)OR(I=98)THEN EX%(I)= EX%(I)-1 | ||
+ | 100 NEXT | ||
+ | 110 L2%(3)=L2%(3)+1 | ||
+ | |||
+ | The constant C is needed obviously to improve accuracy (log(160) simply | ||
+ | isn't a very large number). | ||
+ | logarithms in half; instead of calculating 2*dx/dy I calculate dx/(dy/2), | ||
+ | which is of course the same thing. | ||
+ | By ' | ||
+ | undershoot, which works out to about 6% of all possible calculations we | ||
+ | may perform. | ||
+ | |||
+ | The actual division routine works out pretty slick in assembly: | ||
+ | |||
+ | | ||
+ | LDA LOG1, | ||
+ | SEC | ||
+ | SBC LOG2,Y | ||
+ | BCS CONT | ||
+ | LDX #00 ; | ||
+ | LDA ]1 ;LDA dx, since dx is exactly the remainder | ||
+ | BCC L2 | ||
+ | CONT | ||
+ | TAX | ||
+ | LDA EXP,X | ||
+ | TAX ;X is now integer estimate | ||
+ | STA MULT1 | ||
+ | EOR #$FF | ||
+ | ADC #00 ; | ||
+ | STA MULT2 | ||
+ | LDA ]1 ;ldxlo or rdxlo (i.e. low byte of dx) | ||
+ | ADC (MULT2),Y | ||
+ | SEC | ||
+ | SBC (MULT1), | ||
+ | | ||
+ | BCC DONE | ||
+ | | ||
+ | SBC ]2 ;and subtract dy | ||
+ | CMP ]2 ;Repeat until remainder< | ||
+ | BCS L1 | ||
+ | | ||
+ | |||
+ | Do you see how it works? | ||
+ | log(x) - log(y/2) is negative then dx/dy is less that one, so the | ||
+ | remainder is simply dx and the integer part is zero. Otherwise, | ||
+ | R= dx - N*dy is calculated. | ||
+ | always be positive, so the high byte of dx isn't needed. | ||
+ | R is the remainder, so if it is larger than dy simply increase the | ||
+ | integer estimate and subtract dy from R, and repeat if necessary. | ||
+ | |||
+ | The end result then is a 9-bit/8-bit divide which takes 52 cycles | ||
+ | in the best case. Pretty neat, huh? And quite adequate for our | ||
+ | purposes. | ||
+ | |||
+ | Wait just a minute there, bub... what about when dy=0? Consider what | ||
+ | dy=0 means: it means that two vertices lie along the same line. That in | ||
+ | turn means that the next vertex can be immediately skipped to. That is, | ||
+ | simply move on to the next point in the list, be it to the right or to | ||
+ | the left, if dy=0. | ||
+ | |||
+ | Well, ah reckon that that just about completes the polygon fill routine. | ||
+ | To summarize: start at the bottom (top, whatever) of the polygon. | ||
+ | Calculate the " | ||
+ | Update the coordinates, | ||
+ | end-sections. | ||
+ | then recalculate the corresponding line. | ||
+ | |||
+ | Alert people may have noticed that this algorithm translates very nicely | ||
+ | to the 128's VDC chip. | ||
+ | |||
+ | I should probably briefly mention the pattern fills. | ||
+ | to a pattern table, so it was very natural to use 8x8 character patterns. | ||
+ | With different indexing of course more complicated patterns can be used. | ||
+ | Moreover, it dawned on me that animated patterns were just as easy as | ||
+ | normal ones, so I tried to think up a few interesting animated patterns | ||
+ | (there are two in Polygonamy, each pattern is eight frames). | ||
+ | |||
+ | So that's the graphics part, more or less. | ||
+ | |||
+ | We ain't even CLOSE to being done yet. | ||
+ | |||
+ | @(A): 3D Code | ||
+ | ------- | ||
+ | | ||
+ | Now it's FINALLY time to start writing the master program to control the | ||
+ | 3D world. | ||
+ | work from. | ||
+ | |||
+ | First is to decide how angles will be measured. | ||
+ | to let the angle variable vary between 0..127 or 0..255; that is, to | ||
+ | measure angles in units of 2*pi/128 (or 2*pi/ | ||
+ | smart is because the angle is now periodic, wrapping around 256. Angles | ||
+ | can be added together without checking for overflow, etc. (257=1, 258=2, | ||
+ | 259=3, etc.). | ||
+ | and let the angle variable vary from 0..119, so angles were measured in | ||
+ | three degree increments, and I had to place all sorts of checks into the | ||
+ | code. Polygonamy uses angle increments of delta=2*pi/ | ||
+ | |||
+ | Next there is the issue of cx=cx+20 instead of cx=cx+1. | ||
+ | that if cx=cx+1 is used it takes forever to move around in the world. | ||
+ | Moreover, the objects get really small at around cx=5000. | ||
+ | means is that in the assembly version we can use a single byte for cx, | ||
+ | and just treat each unit of cx as 20 "real world" units. | ||
+ | the assembly program, we will keep track of cx/20 instead of cx. | ||
+ | |||
+ | Sort-of. | ||
+ | |||
+ | Consider the rotation which takes place when we turn left or right: the | ||
+ | world is rotated through an angle delta=2*pi/ | ||
+ | |||
+ | blah= cdel*cx + sdel*cz. | ||
+ | cz= -sdel*cx + cdel*cz | ||
+ | |||
+ | The problem is that sin(2*pi/ | ||
+ | means that, in practice, cdel*cx=cx. | ||
+ | small when cz starts to get small (e.g. 10*sdel = 0.49). | ||
+ | this is that objects close to the origin (e.g. us) will not be rotated at | ||
+ | all! | ||
+ | |||
+ | Thus the centers need to be calculated more accurately. | ||
+ | second byte is needed to store the ' | ||
+ | precise, this second byte will contain the decimal part of the center | ||
+ | times 256. This way we can add and subtract remainders and any over- or | ||
+ | underflows will then affect the integer parts cx,cy,cz. | ||
+ | |||
+ | Very quickly we should decide how to represent remainders of negative | ||
+ | numbers. | ||
+ | just as well be represented as -2.0 + 0.5. By using the second method | ||
+ | remainders are always positive, and that's the smart way to do things (if | ||
+ | nothing else it lets the remainder be a fraction of 256, instead of a | ||
+ | fraction of 128). It's also the way any computer will round: type | ||
+ | INT(-1.5) and see what happens. | ||
+ | |||
+ | further question arises about how to represent the centers, specifically, | ||
+ | how do we represent an object which is behind us, e.g. has a negative | ||
+ | value for cx. The normal way to represent negative numbers is of course | ||
+ | to use 2's complement notation, but this has some disadvantages. | ||
+ | them is multiplication: | ||
+ | footwork needed to be done just to be able to multiply numbers between | ||
+ | -64..64, and we certainly want the centers to range over more numbers | ||
+ | than that. This gets worse if we decide to use more bits to represent | ||
+ | the centers, as we must do if a larger world is constructed. | ||
+ | |||
+ | Moreover, Polygonamy is an excuse for testing new and different ideas and | ||
+ | investigating their strengths and limitations, | ||
+ | different. | ||
+ | this choice, but how about the following: let's add 128 to all of our | ||
+ | numbers.(I think this is called excess-128 notation). | ||
+ | represented as 126, -1 will be represented as 127, six will be | ||
+ | represented as 134, etc. | ||
+ | |||
+ | Shifting between the excess numbers and ' | ||
+ | EOR #128. Recall that to multiply two numbers, let f(x)=x^2/4, so that | ||
+ | a*b = f(a+b) - f(a-b). | ||
+ | |||
+ | xo = 128+x | ||
+ | yo = 128+y | ||
+ | |||
+ | which means: | ||
+ | |||
+ | xo+yo = 256 + (x+y) | ||
+ | | ||
+ | |||
+ | The 256 added above can be thought of as the carry bit. What this means | ||
+ | is that all that is needed is to construct a single function, | ||
+ | | ||
+ | f(x) = (x-256)^2 | ||
+ | |||
+ | where x=-255..255. | ||
+ | the range -128..128, and with just a single (albeit 512 byte) table, | ||
+ | using essentially the same multiplication procedure as before. | ||
+ | |||
+ | Now the downside of this method: adding and subtracting excess-128 | ||
+ | numbers, and in particular checking for overflow. | ||
+ | |||
+ | xo+yo = 256 + (x+y) | ||
+ | if x+y >= 128 then we have overflow | ||
+ | if x+y < -128 then we have underflow | ||
+ | |||
+ | which implies: | ||
+ | |||
+ | xo+yo >= 256+128 | ||
+ | xo+yo < 128 | ||
+ | |||
+ | with similar results for subtraction. | ||
+ | addition or subtraction 128 needs to be either added or subtracted from | ||
+ | the result, which either way corresponds to an EOR #$80. So it's a | ||
+ | little more work to add numbers in this system. | ||
+ | normal numbers to excess-128 numbers is no problem, so INC and DEC work | ||
+ | fine). | ||
+ | |||
+ | Back to rotations. | ||
+ | |||
+ | f(x) = (x-128)*cos(delta) + 128 | ||
+ | g(x) = (x-128)*sin(delta) + 128 | ||
+ | |||
+ | but remember that the remainders are also needed: | ||
+ | |||
+ | fr(x) = 256*(remainder((x-128)*cos(delta))) | ||
+ | gr(x) = 256*(remainder((x-128)*sin(delta))) | ||
+ | |||
+ | Since remainders are always positive none of this excess-128 junk is | ||
+ | needed. | ||
+ | tables, then convert from two' | ||
+ | performing additions etc. The conversion is, what do you know, EOR #$80. | ||
+ | This is the smarter thing to do, and an even smarter thing to do is to | ||
+ | let the cosine table (f(x) above) to be in excess-128 format, and the | ||
+ | sine table g(x) in 2's complement. | ||
+ | as normal, and no conversion need take place: | ||
+ | |||
+ | * Compare to BaSiC subroutine rotl: above | ||
+ | |||
+ | ROTL | ||
+ | INC THETA | ||
+ | LDY # | ||
+ | DEY | ||
+ | |||
+ | : | ||
+ | LDA CDEL, | ||
+ | LDX CZ,Y | ||
+ | CLC | ||
+ | ADC SDEL,X | ||
+ | STA TEMP ;t1 = ci+si | ||
+ | LDA CXREM,Y | ||
+ | CLC | ||
+ | ADC SDELREM, | ||
+ | BCC :CONT1 | ||
+ | INC TEMP | ||
+ | CLC | ||
+ | : | ||
+ | ADC CDELREM,X | ||
+ | BCC :CONT2 | ||
+ | INC TEMP | ||
+ | : | ||
+ | |||
+ | LDX CZ,Y | ||
+ | LDA CDEL,X | ||
+ | LDX CX,Y | ||
+ | SEC | ||
+ | SBC SDEL,X | ||
+ | STA TEMP2 ; | ||
+ | LDA CZREM,Y | ||
+ | SEC | ||
+ | SBC SDELREM,X | ||
+ | BCS :CONT3 | ||
+ | DEC TEMP2 | ||
+ | : | ||
+ | CLC | ||
+ | ADC CDELREM,X | ||
+ | BCC :CONT4 | ||
+ | INC TEMP2 | ||
+ | : | ||
+ | LDA TEMP2 | ||
+ | STA CZ,Y | ||
+ | LDA TEMP | ||
+ | STA CX,Y | ||
+ | DEY | ||
+ | BPL :LOOP | ||
+ | |||
+ | Well, that takes care of two lines of BASIC code :). As it turns out, | ||
+ | using a single byte for the remainder does a pretty good job of holding | ||
+ | the number. | ||
+ | produces a center which is within a few decimal places of the starting | ||
+ | value. | ||
+ | |||
+ | Next up: projections. | ||
+ | |||
+ | | ||
+ | |||
+ | where P=(px, | ||
+ | want to calculate: | ||
+ | |||
+ | | ||
+ | |||
+ | where s=20, to translate C into the 'real world' | ||
+ | consider the following function: | ||
+ | |||
+ | g(x) = r*d / (s*((px-128)/ | ||
+ | |||
+ | where r is some scaling factor. | ||
+ | |||
+ | 1/r*( (g-128)*(P-128) + s*(g-128)*(C-128) ) | ||
+ | |||
+ | Thus we need some more tables, one of 1/(4r) * (256-x)^2, the other of | ||
+ | s/(4r) * (256-x)^2, to do the multiplication. | ||
+ | (x-128)/s would be pretty handy, and finally we need a table of | ||
+ | g(x) = r*d/ | ||
+ | |||
+ | The general outline of a program would be: | ||
+ | |||
+ | Get keypress | ||
+ | 1- If translate, then update all cx's (just some INCs and DECs) | ||
+ | 2- If rotate left or right, then rotate world | ||
+ | 3- Update angles for global & local rotation matrix (e.g. theta) | ||
+ | 4- Figure out which objects to display/ | ||
+ | 5- Call each object in turn | ||
+ | 6- Update bitmap: clear out remaining garbage and swap bitmaps | ||
+ | |||
+ | Numbers 1 and 2 are done. In number three, by global matrix I mean the | ||
+ | object rotation that results from us turning left or right. | ||
+ | rotation I mean rotations independent of whether or not we turn. The | ||
+ | local rotation allows e.g. the octahedron to spin around in Polygonamy. | ||
+ | |||
+ | Figuring out which objects to display is easy: just check to make sure it | ||
+ | lies within the viewing cone/ | ||
+ | an object is to be displayed, it needs to be placed in a list. I | ||
+ | constructed the list to make sure that objects which are farther away are | ||
+ | drawn first; that way objects can overlap one another correctly. | ||
+ | was done via a simple insertion sort -- i.e. bump up objects in the list | ||
+ | until the right spot is reached to insert the object. | ||
+ | |||
+ | We have most of the tools to deal with #5. Handling an object consists | ||
+ | of rotating and projecting it, then displaying it. Rotation is the same | ||
+ | as it has always been, albeit now involving sixteen bits, and projection | ||
+ | is described above. | ||
+ | points of the polygon into the polygon list, setting up the fill pattern | ||
+ | and the pointer to the minimum Y-value, and calling the polygon fill | ||
+ | routine. | ||
+ | to plot it. | ||
+ | |||
+ | The minimum y-value can be found very easily while inserting the points | ||
+ | into the point list -- just keep track of ymax and compare to each point | ||
+ | as it is inserted. | ||
+ | |||
+ | We have discussed several methods of calculating hidden faces -- | ||
+ | cross-product, | ||
+ | looking at a vector normal to the face, and either projecting it or | ||
+ | taking the dot product with a vector going to the origin. | ||
+ | pain in the butt, especially since values can be sixteen-bits, | ||
+ | |||
+ | Did you ever stop to wonder about what happens to all the previous | ||
+ | polygon-fill calculations if the point-list is entered in reverse order? | ||
+ | Quite simply, left -> right and right -> left. And what happens when a | ||
+ | face is invisible? | ||
+ | in the polygon, which go counter-clockwise around the polygon, will go | ||
+ | clockwise when the polygon is turned around. | ||
+ | least in my code the points on the polygon are actually done in | ||
+ | clockwise-order, | ||
+ | |||
+ | So, we have hidden-faces already built-in to the polygon plot routine! | ||
+ | In essence, we simply don't plot any polygon which the routine will freak | ||
+ | out on. We can of course be systematic about this; within the plot | ||
+ | routine: | ||
+ | |||
+ | - Calculate the left and right lines. | ||
+ | - Take a trial step along the left and right lines | ||
+ | - If xleft < xright then we are OK, otherwise punt. | ||
+ | |||
+ | In principle we only need to do this on the first calculation, | ||
+ | some properties of the lines to make things easier (for instance, if the | ||
+ | left line is moving left and the right line is moving right, and they | ||
+ | emanate from the same point, we know the polygon is visible). | ||
+ | Unfortunately, | ||
+ | right slopes have the same integer parts. | ||
+ | within the fill code to make sure the left point doesn' | ||
+ | right point. | ||
+ | code, but luckily there is (was) a natural place to put in a quick check. | ||
+ | |||
+ | All that is left then is #6: run through the fill table, and clear any | ||
+ | lines that still have old junk in them. Since I used two bitmaps as a | ||
+ | double-buffer, | ||
+ | again. | ||
+ | |||
+ | Et voila. | ||
+ | |||
+ | @(A): Analysis and Conclusions | ||
+ | ------------------------ | ||
+ | |||
+ | As you can see, the program is not without its flaws. | ||
+ | I think, deals with the projection. | ||
+ | s=20, and add it to cx. My feeling was that px was going to be very | ||
+ | small compared with cx, and so not modify the projection by much. But | ||
+ | either this is a bad assumption, or the rotations are all screwed up, | ||
+ | because certain rotations look a bit goofy. | ||
+ | up close to the octahedron it starts to get jumpy, or wobbly. | ||
+ | further that when you are far away from an object it looks much better, | ||
+ | so that might be a way to fudge around the problem (e.g. make the value | ||
+ | of d in the projection much larger). | ||
+ | |||
+ | Speaking of rotations, the 'funky shake' which used to plague the old | ||
+ | programs has now been fixed. | ||
+ | would work well but at some point it would appear to start rotating | ||
+ | backwards, then start going the right way again. | ||
+ | an overflow in the calculation of the rotation matrix, in a term that | ||
+ | looked like(sin(t1) + sin(t2) - sin(t3) - sin(t4))/4, and the solution is | ||
+ | to split such terms into two, e.g. (sin(t1)+sin(t2))/ | ||
+ | (sin(t3)+sin(t4))/ | ||
+ | |||
+ | Speaking further of rotations, I find the current system of rotation and | ||
+ | projection unsatisfying, | ||
+ | program slows down when all three objects are visible; some 40 points | ||
+ | are being rotated, both locally and globally, at this point. | ||
+ | possible to reduce the number of matrix multiplications from 9 to 8 (and | ||
+ | even lower, with lots of extra overhead), but I find this unsatisfying. | ||
+ | A better method is needed... | ||
+ | |||
+ | There is another bug somewhere in the global rotations which sometimes | ||
+ | causes the objects to wander around -- occasionally I can get the ship or | ||
+ | the octahedron to move close to the pyramid. | ||
+ | close to an object and turn, you might notice the curious effect of the | ||
+ | object rotating by small amounts, and then jumping position by a large | ||
+ | amount. | ||
+ | the remainder part of (cx,cy,cz) needs to be used here, and then the | ||
+ | display will be smooth as well. | ||
+ | |||
+ | Of course, if multicolor mode was used many of the calculations would be | ||
+ | much simpler, since the screen x-coordinate would only require one byte | ||
+ | instead of two. | ||
+ | |||
+ | The program should be made more efficient memory-wise of course. | ||
+ | the fill routines for each buffer together would help out, and a system | ||
+ | for rotating points out of a list, similar to that used in the last 3D | ||
+ | program, would greatly streamline things (although it would be a tad | ||
+ | slower). | ||
+ | |||
+ | There is still a minor bug or two in the fill routine, which causes | ||
+ | little blue chunks to be taken off the ends of some polygons, but I | ||
+ | didn't feel like tracking it down. | ||
+ | |||
+ | Note that although Polygonamy only lets you run around in a plane, | ||
+ | running around in a full three dimensions is quite simple to add. And, | ||
+ | although there are only three objects in the world, it is all set up to | ||
+ | deal with a lot more. In summary, I see no major problems standing | ||
+ | in the way of doing reasonably fast 3D graphics on the 64. | ||
+ | |||
+ | The object file for this article is available in " | ||
+ | (Reference: code, SubRef: polycode) found elsewhere in this issue. | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== UseNuggets ====== | ||
+ | < | ||
+ | | ||
+ | COMP.SYS.CBM: | ||
+ | see what topics are showing up this month: | ||
+ | |||
+ | @(A): What is the HECK is BCD? | ||
+ | As most ML programmers know, the 65XX CPU line has a arithmetic mode | ||
+ | | ||
+ | | ||
+ | | ||
+ | group what earthly use BCD has on the 65XX CPU. Well, among other things, | ||
+ | | ||
+ | |||
+ | I recall someone asking what the use of BCD (Binary Coded | ||
+ | Decimal) was. I have here a 99-byte program that uses it to | ||
+ | print out a number stored in the memory in decimal, with a | ||
+ | maximum of more than 10^500 digits, Within 5 seconds ; | ||
+ | What's the use ?? Well, you can impress your friends by | ||
+ | calculating the answer to the chessboard-problem ( 2^64 | ||
+ | - 1 or 0xFFFFFFFFFFFFFFFF ) within 0.06 of a second. | ||
+ | and the maximum is pretty easy to overcome, with a slight | ||
+ | code change, if anyone needs numbers greater than, oh, | ||
+ | 509 digits.. ;) | ||
+ | |||
+ | * = $1000 | ||
+ | | ||
+ | SNUM = $1100 | ||
+ | BUFF = $1200 | ||
+ | | ||
+ | PRINT = $FFD2 | ||
+ | | ||
+ | SNUMPTR | ||
+ | SNUMBF | ||
+ | BUFFEND | ||
+ | | ||
+ | LDA #0 | ||
+ | TAX | ||
+ | CLRBUFF | ||
+ | INX | ||
+ | BNE CLRBUFF | ||
+ | SED | ||
+ | STA BUFFPTR | ||
+ | LDY #210 | ||
+ | STY SNUMPTR | ||
+ | BYTELOOP | ||
+ | STA SNUMBF | ||
+ | LDY #8 | ||
+ | BITLOOP | ||
+ | LDX #0 | ||
+ | ADDLOOP | ||
+ | ADC BUFF,X | ||
+ | STA BUFF,X | ||
+ | INX | ||
+ | BCS ADDLOOP | ||
+ | CPX BUFFEND | ||
+ | BCC ADDLOOP | ||
+ | STX BUFFEND | ||
+ | DEY | ||
+ | BNE BITLOOP | ||
+ | DEC SNUMPTR | ||
+ | LDY SNUMPTR | ||
+ | CPY #$FF | ||
+ | BNE BYTELOOP | ||
+ | CLD | ||
+ | LDA #13 | ||
+ | JSR PRINT | ||
+ | DEX | ||
+ | LDA BUFF,X | ||
+ | AND #$F0 | ||
+ | BEQ LOWNYB | ||
+ | PRINTLOOP | ||
+ | LSR | ||
+ | LSR | ||
+ | LSR | ||
+ | LSR | ||
+ | CLC | ||
+ | ADC #48 | ||
+ | JSR PRINT | ||
+ | LOWNYB | ||
+ | AND #$0F | ||
+ | CLC | ||
+ | ADC #48 | ||
+ | JSR PRINT | ||
+ | DEX | ||
+ | CPX #$FF | ||
+ | BNE PRINTLOOP | ||
+ | |||
+ | @(A): Commodore' | ||
+ | OK, try the following on your beloved 128: | ||
+ | |||
+ | print 23.13 - 22.87 hit RETURN | ||
+ | | ||
+ | Do you get .260000005? | ||
+ | | ||
+ | The resuling thread after this question was posed started to lean in the | ||
+ | | ||
+ | 8-bit machines. | ||
+ | | ||
+ | | ||
+ | |||
+ | Recently, the C64/128 floating point arithmetic has been maligned | ||
+ | here. The C64/128 has good floating point math. It uses 5 byte reals | ||
+ | with a 4 byte (32 bit) mantissa. | ||
+ | arithmetic. | ||
+ | more useful than compters using 32 bit reals, but not up to IEEE | ||
+ | standard arithmetic. | ||
+ | precision...) would be much slower than our existing FP routines. | ||
+ | course it might be possible to interface a hardware FPU to the new | ||
+ | Super64/ | ||
+ | | ||
+ | The other C64/128 FP routines, such as SIN, EXP, and functions that use | ||
+ | them are not accurate to full 32 bit FP precision. | ||
+ | care, they are often accurate enough for engineering work. | ||
+ | | ||
+ | The most annoying inaccuracy may be the conversion between binary FP | ||
+ | and decimal for I/O. BASIC only prints 9 decimal digits of a FP | ||
+ | number, but our binary FP number has about 9.6 decimal digits of | ||
+ | precision. | ||
+ | some simple tricks that you can use to print the FP number with more | ||
+ | decimal precision, and you could do I/O using HEX notation. | ||
+ | save intermediate results for later use, make sure you write the FP | ||
+ | values as binary rather than ASCII (converted to decimal). | ||
+ | | ||
+ | If you do accounting type stuff with dollars and cents, using binary FP | ||
+ | with its limited precision and rounding can be anoying. | ||
+ | results are off one penny, all of your work will be suspect. | ||
+ | family of CPUs also has decimal arithmetic. | ||
+ | arithmetic exactly, although you may have to program it yourself. | ||
+ | think the Paperclip word Processor will do simple calculations with up | ||
+ | to 40 decimal digits of precision. | ||
+ | | ||
+ | If you are using 64+ bit FP you can compute some things in a fast and | ||
+ | sloppy manner. | ||
+ | need more careful attention when coded for a C64/128. | ||
+ | | ||
+ | Some numbers can not be represented exactly in binary FP formats of any | ||
+ | precision. | ||
+ | | ||
+ | a: | ||
+ | | ||
+ | You should code it as: | ||
+ | |||
+ | a: | ||
+ | | ||
+ | Aside from being faster, it is more accurate. | ||
+ | |||
+ | There are many tips for preserving numerical accuracy in computations. | ||
+ | There are often interesting tradoffs between computation speed, memory | ||
+ | usage, and accuracy and stability. | ||
+ | specific tips. (e.g. we usually store a real value in 5 bytes of | ||
+ | memory but push it onto a stack as 6 bytes when we want to use it.) | ||
+ | | ||
+ | This is not intended to be a Commodore FP tutorial. | ||
+ | that the C64/128 can be used for "heavy math", and there are no bugs | ||
+ | in the Commodore +, -, *, /, Floating Point arithmetic routines. | ||
+ | uses 32 binary bit mantisa FP reals with proper rounding. | ||
+ | Simple examples can always be contrived to demonstrate a perceived FP | ||
+ | bug by computer illiterates(? | ||
+ | | ||
+ | Alan got his dig in at the end there. | ||
+ | | ||
+ | case, we all learned a neat trick along the way. Peter Karlsson shared | ||
+ | his easy way of determining whether his programs are running on a C64 or | ||
+ | C128 by issueing the following statement: | ||
+ | |||
+ | C=64+64*INT(.1+.9) | ||
+ | |||
+ | Since the 64 and 128 differ ever so slightly in their arithmetic | ||
+ | | ||
+ | |||
+ | @(A): We need another OS! | ||
+ | It all started when Benjamin Moos posted a message in the newsgroup | ||
+ | | ||
+ | and wondered whether anyone would want him to finish work on a C++ based | ||
+ | | ||
+ | but Moos continued on, asking if there was any interest in an alternate | ||
+ | OS for the 64 or 128. Moos mentioned that he had been also working on | ||
+ | | ||
+ | | ||
+ | based graphic windowing system that would allow all 64 programs to run | ||
+ | in the 128 80 column screen in 40 column windows. | ||
+ | |||
+ | Well, that brought out some friendly debate, to state the obvious. Part | ||
+ | of the group posted words of encouragement, | ||
+ | | ||
+ | the camp echoed the words of Patrick Leung, who expressed concern that | ||
+ | there are many programmers in the arena that are doing the same thing | ||
+ | | ||
+ | bases to arrive at robust full-featured programs instead of fragile bare- | ||
+ | bones applications that single programmers can't support. ACE, Craig | ||
+ | | ||
+ | up by some, who asked that programmers heed Leung' | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | ideas to the table and have them rapidly incorported into the design. | ||
+ | | ||
+ | |||
+ | Going full circle, Benjamin Moos reponded to some of the posts, saying | ||
+ | that the OS work was going to be placed on the shelf for now, as many | ||
+ | had expressed interest in the C++ like compiler. | ||
+ | that work would begin again at a later date, but no decision was made | ||
+ | as to how he will proceed. | ||
+ | |||
+ | @(A): The "More Power" Swiftlink | ||
+ | Ever striving to squeeze the most performance out of his C128 system, | ||
+ | Craig Bruce modified his Swiftlink and lived to tell about it in the | ||
+ | | ||
+ | ACIA IC used in the SL, Craig noted that Dr. Evil Labs (the original | ||
+ | | ||
+ | bps maximum in the ACIA to 38,400 bps. The IC claims that any baud | ||
+ | rate up to 125,000bps can be achieved with the IC, given the correct | ||
+ | | ||
+ | | ||
+ | stock crystal. | ||
+ | | ||
+ | | ||
+ | top frequency for IBM UARTs and is supported by most newer modems. | ||
+ | Craig verified that his 2MHz 128 can keep up with the extra data | ||
+ | that his modofoed SL allows him to receive, but not always. | ||
+ | | ||
+ | | ||
+ | very tight terminal program code to keep up with this speed, but it | ||
+ | will fit nicely with the SuperCPU. | ||
+ | |||
+ | As with all things, there is a downside in that 19,200 becomes the | ||
+ | next lower bps rate. 38,400 is gone forever. | ||
+ | | ||
+ | |||
+ | @(A): The Eternal Problem | ||
+ | | ||
+ | can relate. How many have ever went into the local CompUSA of local | ||
+ | | ||
+ | only to hear the dreaded laugh and chide that you should "buy a REAL | ||
+ | | ||
+ | " | ||
+ | | ||
+ | |||
+ | When someone keeps an old car around, babies it, works on it, | ||
+ | adds to it, drives it around in style, no one says "Look at | ||
+ | this dummy driving an out-dated gas guzzler that can't even do | ||
+ | 80, and gets atrocious gas mileage. | ||
+ | The windows aren't electric. Why doesn' | ||
+ | they are ' | ||
+ | |||
+ | Well, ... we are " | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== FIDO's Nuggets ====== | ||
+ | < | ||
+ | |||
+ | The CBM and CBM-128 FIDONet echoes. | ||
+ | unite. | ||
+ | |||
+ | @(A): UNZIP 2 or not UNZIP 2? | ||
+ | For a while now, Commodore users have been able to uncompress | ||
+ | | ||
+ | by PKWare or one of its clones. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | 4.3 on the 128. The programs work by retrieving a COMPRESSED | ||
+ | | ||
+ | | ||
+ | | ||
+ | for retrieval packets. | ||
+ | | ||
+ | to bring PKZIP 2 functionality to the 64. Some thought it was a | ||
+ | done deal when a FIDNetter contacted Info-Zip, the authors of a | ||
+ | free clone of PKZIP 2 by the same name. They were told the source | ||
+ | code was available. | ||
+ | no compilation on the 64 or 128 has been successful. | ||
+ | |||
+ | @(A): QWKIE v3.1 FREE! | ||
+ | Many C64 users have delighted over the use of QWKIE v3.1 to read | ||
+ | | ||
+ | the product. | ||
+ | | ||
+ | | ||
+ | | ||
+ | QWKIE FREE, a patched version of the program that is marked as | ||
+ | | ||
+ | | ||
+ | |||
+ | @(A): That Darn Internet! | ||
+ | As of late, many FIDONet regulars have been diappointed in the | ||
+ | | ||
+ | | ||
+ | has dwindled. | ||
+ | | ||
+ | | ||
+ | that both resources are needed. | ||
+ | | ||
+ | to cast a vote here, we do hope that interest in the echoes stays | ||
+ | high, as some only have access to FIDONet, and Commodore support | ||
+ | | ||
+ | |||
+ | @(A): Let's Randomize | ||
+ | Some soul on the echo was looking for a way to generate a random | ||
+ | | ||
+ | came to the rescue, with varying degrees of complexity. | ||
+ | |||
+ | The first post, by Ken Waugh, included the text from one of | ||
+ | Rick Kepharts WWW Site pages that explained, in two BASIC lines or | ||
+ | less, how to create a set of 255 nonrepeating random numbers. | ||
+ | |||
+ | Then, ever the guru, George Hug, of 2400 bps on a 64 fame, described | ||
+ | a method to find random numbers based on " | ||
+ | shift registers", | ||
+ | | ||
+ | than what the original author was looking for. Nonetheless, | ||
+ | | ||
+ | |||
+ | @(A): Catch the Wave! | ||
+ | By now, most know that Maurice Randall, the author of GeoFAX, has been | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | be incoporated and under test. Mr. Randall was hoping to add such | ||
+ | | ||
+ | | ||
+ | |||
+ | @(A): Who's First? | ||
+ | Rod Gasson posed an interesting question on FIDONet a while back. He | ||
+ | asked which CPU was in control of the 128 when it is first powere up. | ||
+ | The abvious answer of "the 8502" was given many times over, but Rod | ||
+ | | ||
+ | | ||
+ | from the C128 Programmer' | ||
+ | | ||
+ | |||
+ | @(A): Desterm Confusion | ||
+ | Many in the 128 arena use a telecommunications program called Desterm, | ||
+ | by Matt Desmond. | ||
+ | | ||
+ | 2.01 that works with RAMLink, but has bugs not present in 2.00. So, | ||
+ | which to use? That questions gets asked in verious forms in the echoes | ||
+ | | ||
+ | a while, the supposed hand-over of the code to Steve Cuthbert, and the | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | rumor that Matt will add Z-modem capabilities keeps pooping up, but | ||
+ | Matt has denied any such work. He merely doesn;t see a need, since | ||
+ | add in modules can be created to do this. | ||
+ | |||
+ | So, that gives you a glimpse into the world of FIDO, the wonder dog of | ||
+ | networks. | ||
+ | experiencing problems as of late, so we too may have missed some juicy | ||
+ | tidbits. | ||
+ | |||
+ | Here, boy.... | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== Underneath the Hood of the SuperCPU ====== | ||
+ | < | ||
+ | by Jim Brain | ||
+ | |||
+ | Does your mind go blank when you hear about the SuperCPU? | ||
+ | mention of it in magazines and newsletters, | ||
+ | much of the discussion is hype and how much is true? Are you worried | ||
+ | that this latest attempt is just another design destined for failure | ||
+ | like the others before it? Well, if so, then you're not alone. | ||
+ | the reputation accelerator cartridges and their manufacturers have | ||
+ | acquired over the years, you are wise to be concerned. | ||
+ | yourself, as we peer under the hood of the Creative Micro Designs | ||
+ | SuperCPU accelerator cartridges. | ||
+ | |||
+ | Note: The information contained in this article has been gleaned from | ||
+ | talks with CMD, Mr. Charlie Christianson' | ||
+ | responses to USENET posts by Mr. Doug Cotton, and information from Commodore | ||
+ | World Issue #12. While general information is not likely to change, | ||
+ | some details discussed in this article may differ slightly from those | ||
+ | incorporated in the final product. | ||
+ | |||
+ | @(A): What's An Accelerator? | ||
+ | |||
+ | Did you know a Commodore 64 CPU executes things at 1 MHz? A tiny clock | ||
+ | inside the 64 ticks off 1 million " | ||
+ | the CPU to move forward one cycle at a time. The CPU, in turn, | ||
+ | either executes an internal operation, reads from memory, or writes | ||
+ | to memory during that cycle. | ||
+ | form funtions, which is the smallest piece of work a programmer can | ||
+ | ask the CPU to perform. | ||
+ | take an average of 3 cycles each to perform. | ||
+ | CPU does 333,333 things a second. | ||
+ | can run twice as fast when in " | ||
+ | an upper bound on the amount of useful work each CPU can do in a | ||
+ | amount of time. | ||
+ | |||
+ | An accelerator increases that amount of work done by substituting a | ||
+ | faster CPU and clock speed for the 1 MHz 64 CPU. The ratio of | ||
+ | increase should be as easy to determine as dividing the new clock | ||
+ | frequency by 1 MHz for a 64. If this were true, an accelerator that | ||
+ | runs at 4 Mhz would execute things at 4 times the speed of a stock 64. | ||
+ | Sadly, this is not true, since not all parts of the system can be sped | ||
+ | up to the higher frequency. | ||
+ | it utilizes ICs designed for the faster clock speed, and slows down when | ||
+ | it must " | ||
+ | at the slow 1 MHz clock speed. | ||
+ | |||
+ | Most accelerators are produced as large cartridges that plug into the | ||
+ | expansion port of the computer system. | ||
+ | attached to internal components, while others do not. | ||
+ | |||
+ | @(A) The New Kid on the Block | ||
+ | |||
+ | In mid 1995, Creative Micro Designs, after having evaluated the FLASH 8 | ||
+ | accelerator from Europe with only mild success, noted that there might | ||
+ | possibly be a market for a speedy accelerator that would run GEOS and | ||
+ | other useful applications in the USA. After surveying the readership | ||
+ | of Commodore World, the Internet, and FIDONet, CMD decided that interest | ||
+ | in such a unit was forthcoming. | ||
+ | announcement was made. | ||
+ | |||
+ | As development work ensued, progress reports and preliminary information | ||
+ | about the product surfaced from CMD. The first items involved the processor | ||
+ | choice, which was originally the 65C02S but is now its bigger brother, the | ||
+ | 16 bit 65C816S. | ||
+ | an enclosure 6" wide by 2" deep by 3" wide. This enclosire contains | ||
+ | a circuit board protruding from the front of the unit that will plug into | ||
+ | the Commodore 64 or 128 expansion port. In back, a complementary card | ||
+ | edge connector is provided to pass signals through the cartridge. | ||
+ | will allow users to attach other expansion port cartidges to the | ||
+ | system. | ||
+ | |||
+ | The first switch enables or disables the SuperCPU unit. The second switch | ||
+ | enables or disables JiffyDOS, which is built into the unit. The third | ||
+ | switch determines the speed of the unit. This third switch has three | ||
+ | positions. | ||
+ | MHz speed (the same speed as the stock C64). The second position allows | ||
+ | the programmer to change the speed via a register in the SuperCPU memory | ||
+ | map. The third position locks the SuperCPU into 20 MHz mode, regardless | ||
+ | of register settings. | ||
+ | |||
+ | The use of the CMD SuperCPU will be straightforward. | ||
+ | unit into the expansion port, set the appropriate switches on the top of | ||
+ | the unit, and powering on the unit. | ||
+ | |||
+ | @(A) Technical Details | ||
+ | |||
+ | The basic system utilizes a WDC W65C816S 16 bit microprocessor running at | ||
+ | 20 MHz. This CPU can not only fully emulate a CMOS 6502, it can be | ||
+ | switched into " | ||
+ | 16 megabytes of RAM without bank switching, DMA, or paging. | ||
+ | |||
+ | Attached to the CPU is a bank of 64 kilobytes of Read Only Memory (ROM) | ||
+ | and 128 bilobytes of high speed static RAM (SRAM). | ||
+ | 64 kB is used to " | ||
+ | details. | ||
+ | |||
+ | A number of features designed to maximize the performance of the | ||
+ | SuperCPU are being developed into the unit. Since the late 1980' | ||
+ | ROM speeds have not been able to keep pace with CPU clock frequencies. | ||
+ | With the CMD accelerator moving into the frequency range of newer | ||
+ | PC systems, this becomes a problem for the SuperCPU as well. The | ||
+ | Commodore typically stores its KERNAL and BASIC code in ROMS, and the | ||
+ | SuperCPU will need to read that code. The easiest solution is to read | ||
+ | the stock ROMs in the computer, but those ICs can only be accessed | ||
+ | at 1 MHz (they are part of that set of older ICs that cannot be utilized | ||
+ | at 20 MHz). So, the next option is to copy that code into faster ROMs | ||
+ | and instal those ROMs int the cartridge. | ||
+ | ROMs of sufficient speed are very expensive and not widely available. | ||
+ | So, the third option, which is the one CMD will use, is to copy the | ||
+ | KERNAL and BASIC at startup to RAM and write protect the RAM area, making | ||
+ | it look like ROM. Fast static RAM (SRAM) is available to meet the | ||
+ | 20 MHz clock requirements, | ||
+ | PC systems use the same memory for similar uses. This technique is | ||
+ | called ROM shadowing and has been utilized for a few years in the IBM | ||
+ | PC community. | ||
+ | |||
+ | The heart of the unit is the Altera Complex Programmable Logic Device | ||
+ | (CPLD). | ||
+ | ten or hundreds of discrete ICs in circuits. | ||
+ | for decoding the complex series of signals presented in the expansion | ||
+ | port, handling DMA requests to an REU unit, emulating the specialize | ||
+ | I/O port found at locations $00 and $01 on the 6510 CPU, and handling | ||
+ | the synchronization of the SuperCPU memory and C64 memory. | ||
+ | |||
+ | One item that has plagued accelerator designers for years and minimized | ||
+ | the widespread acceptance of accelerators invoves this RAM sync operation | ||
+ | the Altera CPLD handles. | ||
+ | only RAM is present, like $0002 - $40959, the synchronization of | ||
+ | memory can be handled very easily. | ||
+ | like $d000, where RAM AND IO can be present, the situation becomes more | ||
+ | complex. | ||
+ | since many video applications use the RAM under IO at $d000 for graphics | ||
+ | or text. | ||
+ | |||
+ | As the VIC-II IC in the C64 and C128 requires that screen information be | ||
+ | present in on-board memory, memory " | ||
+ | CMD has introduced two new technologies, | ||
+ | CacheWrite(tm) to reduce the slowdown associated with mirroring the | ||
+ | SuperCPU SRAM and the slower on-board DRAM. According to documentation, | ||
+ | WriteSmart allows the programmer to decide which portions of memory need | ||
+ | mirroring. | ||
+ | color memory are mirrored, " | ||
+ | memory are mirrored, " | ||
+ | " | ||
+ | between the two RAM areas. | ||
+ | |||
+ | The other technology, called CacheWrite(tm), | ||
+ | this mirroring. | ||
+ | RAM that requires mirroring, the value is stored not only in SuperCPU | ||
+ | RAM, but also into a special cache memory location. | ||
+ | allowed to continue processing, while the system waits for the on board | ||
+ | DRAM to acknowledge readiness to store a value. | ||
+ | to mirror ranges are done, the system must slow down, but can still | ||
+ | operate at about 4 MHz. This speed is achieved because the SuperCPU need | ||
+ | not wait for the value to be successfully stored before it attempts to | ||
+ | fetch the next opcode and operand. | ||
+ | memory avarage 4 cycles to complete, the SuperCPU can effectively do 4 | ||
+ | cycles worth of processing in 1 period of the 1 MHz clock. | ||
+ | this slowdown does not occur if the cache is not full when a store | ||
+ | instruction is executed. | ||
+ | |||
+ | @(A) Features | ||
+ | |||
+ | Being a CMD product, the CMD SuperCPU comes with JiffyDOS, CMD's | ||
+ | flagship speed enhancement routines, installed. | ||
+ | can be switched out for those applications that fail to run with this | ||
+ | serial bus enhancement functionality. | ||
+ | |||
+ | The unit also features compatibility with RAMLink, CMD's RAM drive unit. | ||
+ | As the RAMLink fucntions by sharing the CPU with the computer system and | ||
+ | runs a special set of instructions called RL-DOS, the SuperCPU contains its | ||
+ | own version of RL-DOS optimized to take advantage of the speed and extra | ||
+ | features available in the 65C816S. | ||
+ | RAMLink data retrieval, typicially much slower the REU data retrieval, | ||
+ | will now operate at speeds approaching that of the REU. In addition, the | ||
+ | on-baord RL-DOS will handle usage of the special parallel CMD HD drive | ||
+ | cable available with the RAMLink. | ||
+ | |||
+ | For those with expansion in mind, CMD has incorporated a special | ||
+ | expansion port internal to the unit. The port, called the " | ||
+ | Socket", | ||
+ | CPU and possibly other support ICs. This will allow developers to | ||
+ | produce peripheral cards for the unit containing hardware that will run | ||
+ | at 20 MHz (The cartridge port will still be limited to slow speed). | ||
+ | |||
+ | @(A): Myths About the Unit | ||
+ | |||
+ | In the early phases of development, | ||
+ | installed in the unit could be used as a fast RAM disk, a la RAMLink. | ||
+ | However, the inability to battery back up that RAM area, coupled with the | ||
+ | small increase in speed gained form doing so and the lengthy development | ||
+ | time needed to realize this feature, has prompted CMD to abandon this | ||
+ | idea for the time being. | ||
+ | might resurface, but the feature is most likely never to be implemented. | ||
+ | |||
+ | Also, early information about the units noted that two speed options would | ||
+ | be available, but low support for the slower 10 MHz model prompted CMD to | ||
+ | discontinue development on that version. | ||
+ | speed option available: 20 MHz. | ||
+ | |||
+ | When CMD first announced the unit to the public, it was to include the | ||
+ | Western Design Center W65C02S microprocessor. | ||
+ | 1996, CMD opted to switch from that CPU to its bigger brother, the W65C816 | ||
+ | 16 bit CPU, owing to small increase in per item cost, more flexibility, | ||
+ | more expansion options. | ||
+ | |||
+ | Although the speed of the CPU in the SuperCPU unit is running at 20 MHz, | ||
+ | that does not imply all operations will occur twenty times faster. | ||
+ | operations, like reads from I/O ICs, derial bus operation, and mirroring | ||
+ | of video memory, require the CPU to slow down temporarily. | ||
+ | reduce the effective speed to about 17-18 MHz. | ||
+ | |||
+ | @(A): Compatibility Issues | ||
+ | |||
+ | All legal 6502/ | ||
+ | Undocumented or " | ||
+ | |||
+ | Although not a compatibility issue, some applications that rely on the | ||
+ | CPU running at a certain speed to correctly time events will most likely | ||
+ | fail or operate too quickly to be useful. | ||
+ | code should operate correctly. | ||
+ | |||
+ | The SuperCPU 64 model will operate correctly with any C64 or C64C model | ||
+ | of computer system, as well as with any C128 or C128D in 64 mode. However, | ||
+ | CMD has recently announced a 128 native version of the cartridge. | ||
+ | |||
+ | @(A): Super128CPU | ||
+ | |||
+ | In early 1996, CMD announced that interest was compelling and that would | ||
+ | begin development on a 128 version of the SuperCPU. | ||
+ | announcement, | ||
+ | validated the SuperCPU design so that it could be used to manufacture | ||
+ | both the SuperCPU 64 and SuperCPU 128. Both units will operate at a | ||
+ | maximum of 20 MHz, and will most likely be packaged in the same enclosure. | ||
+ | The SuperCPU 128 will operate in both 64 mode and native 128 mode. It | ||
+ | will not enhance CP/M mode on the C128. CMD announced that the | ||
+ | availability of this unit would be Auguest or September ot 1996. As far | ||
+ | as cost is concerned, a current estimate falls at $300.00, and advance | ||
+ | orders are being taken with a security deposit of US$50.00 needed to | ||
+ | place an advance order. | ||
+ | |||
+ | As this announcement was made, some confusion has resulted in the naming | ||
+ | scheme. | ||
+ | 20 MHz), the new models are referred to as alternately: | ||
+ | |||
+ | 128 model 64 model | ||
+ | |||
+ | Super128CPU | ||
+ | SuperCPU 128/ | ||
+ | |||
+ | @(A) Prototype Testing and Benchmarks | ||
+ | |||
+ | As no developer unit have shipped as of this date, CMD has the sole unit | ||
+ | availabel for be testing and benchmarks. | ||
+ | of a handwired unit on perfboard. | ||
+ | prototype would actually run at 20 MHz, since such designs are not | ||
+ | " | ||
+ | crosstalk, which inhibits operation at higher frequencies. | ||
+ | that in mind, early tests were done at 4 MHz. CMD reported in late | ||
+ | Fenbruary 1996 that the prototype had been ramped up to 20 MHz and was | ||
+ | operating correctly. | ||
+ | can, illustrated by the following example: | ||
+ | |||
+ | CMD tested the following program at 1 MHz on a Commodore 64 | ||
+ | |||
+ | 10 TI$=" | ||
+ | 20 FORI=1TO10000: | ||
+ | 30 PRINTTI | ||
+ | |||
+ | The result from this test was 660. After enabling the unit, the test was | ||
+ | rerun and the result printed out again: 31. | ||
+ | |||
+ | Quick calculations by the CMD personnel verified that the unit was | ||
+ | executing this program 21.29 times the normal speed. | ||
+ | is impossible, as the CPU is only clocked 20 times the nortmal speed. | ||
+ | |||
+ | The supposed impossibility is explained if you delve deeper into the | ||
+ | timing of the 64. As many know, the VIC-II " | ||
+ | in order to refresh the VIC-II video screen. | ||
+ | for sprites. | ||
+ | minus the amount of time the VIC-II " | ||
+ | SuperCPU enabled, the VIC-II does not " | ||
+ | the accelerator uses it own private memory area for operation. | ||
+ | meanwhile, uses the on-board C64 memory. | ||
+ | |||
+ | CMD notes that games that use timers or are event driven function | ||
+ | correctly, but hotse that count processor cycles or utilize spin-wait | ||
+ | loops run so quickly as to be virtually unusable. | ||
+ | |||
+ | Of partiular note to Commodore Hacking readers is the test done with the | ||
+ | object code for the Polygonamy (Reference: polygon) article elsewhere in | ||
+ | this issue. | ||
+ | frames per second. | ||
+ | fps. CMD notes that further gains might be realized if the code was | ||
+ | modified to cooperate more fully with the CupserCPU memory scheme. | ||
+ | |||
+ | As for Ram Expansion Unit compatibility, | ||
+ | have been tackled and that DMA operation is available on the SuperCPU | ||
+ | unit. In adiition, CMD notes that the CPU need not be running at 1 MHz | ||
+ | to initiate a DMA transfer. | ||
+ | |||
+ | As stated from the beginning, the 64 model of the SuperCPU accelerator | ||
+ | wil work on the Commodore 128 in 64 mode, and test have confirmed that | ||
+ | the prototype 64 model does indeed frunction correctly any the C128 and | ||
+ | C128D. | ||
+ | |||
+ | @(A): Conclusion | ||
+ | |||
+ | While it is too early to determine the success of the CMD SuperCPU | ||
+ | product, the company has a reputation for delivering stable products | ||
+ | packed with features. | ||
+ | compatibility with all Commodore software, the CMD offering should provide | ||
+ | the best compatibility options thus far, due to its solutions to | ||
+ | RAM synchronization problems that have plagued accelerator designers for | ||
+ | years. | ||
+ | family of software products and manufacturers a wide variety of | ||
+ | successful mass media storage devices bodes well for compatibility with | ||
+ | those applications and peripherals. | ||
+ | |||
+ | @(A): For More Information | ||
+ | |||
+ | TO find out more about the CMD SuperCPU family of accelerators, | ||
+ | CMD at the following address of via email: | ||
+ | |||
+ | Creative Micro Designs, Inc. | ||
+ | P.O. Box 646 | ||
+ | East Longmeadow, | ||
+ | (413) 525-0023 | ||
+ | (800) 638-3263 | ||
+ | cmd.sales@the-spa.com | ||
+ | |||
+ | Advance orders are being taken for all units, and the cost to place an | ||
+ | advance order is $50.00. | ||
+ | |||
+ | For programmers, | ||
+ | which will help those wanting to exploit the potential of the new unit to | ||
+ | achieve success. | ||
+ | addressing modes will be provided, as will documentation pertaining to the | ||
+ | unit, the CPU, and its capabilities. | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== Hack Surfing ====== | ||
+ | < | ||
+ | | ||
+ | For those who can access that great expanse of area called the World Wide | ||
+ | Web, here is some new places to visit that are of interest to the Commodore | ||
+ | community. | ||
+ | of sites online that catered to Commodore numbered in the 10' | ||
+ | number is in the 100' | ||
+ | |||
+ | If you know of a site that is not listed here, please feel free to send it | ||
+ | to the magazine. | ||
+ | changed or added to the US Commodore WWW Site Links page | ||
+ | (http:// | ||
+ | |||
+ | To encourage these sites to strive to continually enhance their creations, | ||
+ | and because we like to gripe :-), we'll point out an improvements that | ||
+ | could be made at each site. | ||
+ | |||
+ | @(A): Companies | ||
+ | |||
+ | o http:// | ||
+ | | ||
+ | | ||
+ | for visual effects, and the content is good as well. At the time we " | ||
+ | the page, CWI was working on a new game called Nether for the 64/ | ||
+ | From the information, | ||
+ | both CBM and MS-DOS titles. | ||
+ | | ||
+ | the diehard CBM user should be able to skip it. As of now, it's all on | ||
+ | the same page. | ||
+ | |||
+ | o http:// | ||
+ | | ||
+ | this site for new and advanced users. | ||
+ | | ||
+ | | ||
+ | is clean and simple, with no fancy graphics, but lots of meaty information. | ||
+ | Links include the QWKRR128 user's manual, the actual product' | ||
+ | and helper applications needed to use QWKRR128. | ||
+ | tell what all I need to read Internet email via QWKRR128. | ||
+ | |||
+ | o http:// | ||
+ | RMS Computer Systems. | ||
+ | | ||
+ | | ||
+ | and clean, using either Microsoft Explorer or Netscape Navigator | ||
+ | | ||
+ | the C-Net BBS software for sale and present information on the 64 and | ||
+ | 128 versions of the program. | ||
+ | of using Netscape of Microsoft Explorer. | ||
+ | | ||
+ | |||
+ | @(A): Publications | ||
+ | |||
+ | o http:// | ||
+ | | ||
+ | | ||
+ | is detailed. | ||
+ | Of course, we're not sure it does justice to the magazine, but that' | ||
+ | true of LOADSTAR' | ||
+ | as the change dates are 9-95. When they do update it, we hope they' | ||
+ | | ||
+ | |||
+ | @(A): User's Groups | ||
+ | |||
+ | o http:// | ||
+ | Cnada Commodore Users Group of Nova Scotia. | ||
+ | color and grpahics to provide links to a number of Commodore content | ||
+ | sites on the Internet. | ||
+ | and provides a public download area for software retrieval. C=H gripe: | ||
+ | We still think this is a user's group, but no meetings, minutes, | ||
+ | | ||
+ | |||
+ | o http:// | ||
+ | Metro C-64/128 User's Group. | ||
+ | | ||
+ | this groups parent organization, | ||
+ | C=H gripe: some newsletters from past meetings and a bit more about the | ||
+ | group would be nice. | ||
+ | |||
+ | o http:// | ||
+ | The Middle Peninsula Computer Users Group. | ||
+ | WHY the groups is named this way. Meeting times, dates, places, past | ||
+ | | ||
+ | has a sprinkle of color and graphcis to break up the text. C=H gripe: | ||
+ | It looks like the group is multi-platform, | ||
+ | what Commodore 8-bit owners will find at meetings. | ||
+ | |||
+ | @(A): Demo Groups | ||
+ | |||
+ | o http:// | ||
+ | The EQUINOXE WWW Site. This demo group puts on a good show, with | ||
+ | | ||
+ | the announcement on the upcoming Shout! #2 magazine release. | ||
+ | of links is implressive as well. C=H gripe: | ||
+ | fonts sizes is a bit overdone. | ||
+ | |||
+ | o http:// | ||
+ | The OMNI/ | ||
+ | site as well. A bit of history about Revenge is given, links to the | ||
+ | demos to download is present, and information about upcoming releases | ||
+ | is detailed. | ||
+ | the well-done page. | ||
+ | |||
+ | @(A): Miscellaneous | ||
+ | |||
+ | o http:// | ||
+ | Dan Fandrich' | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | C=H gripe: | ||
+ | | ||
+ | |||
+ | o http:// | ||
+ | The Commodore VIC-20 Cartridge List. Cartridges from many different | ||
+ | | ||
+ | As with the Programming Language Page, this list is extensive. | ||
+ | in the opening credits the trasnsitions the list has made to arrive at | ||
+ | this current form. C=H gripe: same as for the langauge list. This thing | ||
+ | is LARGE, and might benefit from a more heirachial listing treatment. | ||
+ | |||
+ | o http:// | ||
+ | John Elliot' | ||
+ | and other " | ||
+ | | ||
+ | as it shows practical uses to dispel the myth that 8-bits are truly | ||
+ | | ||
+ | of these reall world examples. | ||
+ | |||
+ | o http:// | ||
+ | The Alternate Reality WWW Site. For those wanting to relive the best of | ||
+ | this game for the 64, visit this site. Everything from tips to tricks, | ||
+ | | ||
+ | | ||
+ | does look neat. | ||
+ | |||
+ | o http:// | ||
+ | | ||
+ | | ||
+ | | ||
+ | any, and describes the game itself. | ||
+ | | ||
+ | | ||
+ | |||
+ | o http:// | ||
+ | Todd Elliott' | ||
+ | and links to hardware hacks and ML tips. Of particular interst is his | ||
+ | | ||
+ | some of the history behind the machines. | ||
+ | page details his experisnces with Radio Shack.... C=H gripe: | ||
+ | to know how Todd Elliott fits into the Commodore 8-bit arena. | ||
+ | |||
+ | @(A): Change of Address | ||
+ | |||
+ | o CMD recently moved to http:// | ||
+ | CMD heard our issue #11 gripe, as the home page now has links directly | ||
+ | to the SuperCPU information. | ||
+ | |||
+ | o LOADSTAR has moved to http:// | ||
+ | |||
+ | o Marc-Jano Knopp' | ||
+ | | ||
+ | |||
+ | o The US Commodore WWW Links Site has moved to: | ||
+ | | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== Commodore Trivia ====== | ||
+ | < | ||
+ | by Jim Brain (brain@mail.msen.com) | ||
+ | | ||
+ | @(A): Introduction | ||
+ | |||
+ | I had the good fortune of receiving some fine back issue of magazine and | ||
+ | old books from a friend in Michigan (thanks Gaelyne), so I got busy reading | ||
+ | and gleaning. | ||
+ | rack your brain and have you reachin' | ||
+ | publications. | ||
+ | |||
+ | As some may know, these questions are part of a contest held each month on | ||
+ | the Internet, in which the winner receives a donated prize. | ||
+ | those who can received the newest editions of trivia to enter the contest. | ||
+ | |||
+ | This article contains the questions and answers for trivia editions #23-26, | ||
+ | with questions for the current contest, #27. | ||
+ | |||
+ | If you wish, you can subscribe to the trivia mailing list and receive the | ||
+ | newest editions of the trivia via Internet email. | ||
+ | list, please mail a message: | ||
+ | |||
+ | To: brain@mail.msen.com | ||
+ | Subject: MAILSERV | ||
+ | Body: | ||
+ | subscribe trivia Firstname Lastname | ||
+ | help | ||
+ | quit | ||
+ | |||
+ | @(#): Trivia Questions | ||
+ | |||
+ | A publication describing BASIC on the Commodore makes the claim that | ||
+ | BASIC variables are limited to 5 characters, with the first two being | ||
+ | significant. | ||
+ | |||
+ | ABCDE=5 | ||
+ | ABCDEF=6 | ||
+ | |||
+ | The following questions refer to this claim: | ||
+ | |||
+ | Q $160) What is wrong with the above statement? | ||
+ | |||
+ | A $160) Variables can indeed be longer than 5 characters. | ||
+ | |||
+ | Q $161) What causes the variable ABCDEF to fail? | ||
+ | |||
+ | A $161) The variable name fails becase the BASIC keyword " | ||
+ | |||
+ | Q $162) How long can variable names really be? | ||
+ | |||
+ | Extra Credit: | ||
+ | |||
+ | A $162) As long as the maximum command line length. | ||
+ | automated code generation, you can get a variable name that is | ||
+ | just shy of 255 characters in length. | ||
+ | | ||
+ | Oh, and Abacus wrote the offending book. | ||
+ | |||
+ | The Commodore LCD Computer system, much like the Commodore 65, | ||
+ | was a product that never reached the market. | ||
+ | pint-size CBM machine? | ||
+ | |||
+ | Q $163) How many keys were on the CLCD keyboard? | ||
+ | |||
+ | A $163) 72 keys, including 8 function keys and 4 separate cursor keys. | ||
+ | |||
+ | Q $164) What does LCD in the Commodore LCD stand for? | ||
+ | |||
+ | A $164) Liquid Crystal Display. | ||
+ | |||
+ | Q $165) Was an internal modem to be includes? | ||
+ | |||
+ | A $165) Yep, A 300 bps auto dial/auto answer modem. | ||
+ | |||
+ | Q $166) Like the Plus/4 the CLCD unit had integrated software. | ||
+ | were included? | ||
+ | |||
+ | A $166) As referenced in $158, there are 8 integrated programs: | ||
+ | |||
+ | Word Processor | ||
+ | File Manager | ||
+ | Spreadsheet | ||
+ | Address Book | ||
+ | Scheduler | ||
+ | Calculator | ||
+ | Memo Pad | ||
+ | Telecommunications Package | ||
+ | |||
+ | Q $167) How many batteries of what type did the CLCD use for power? | ||
+ | |||
+ | A $167) 4 AA alkaline batteries. | ||
+ | |||
+ | Q $168) Approximately how much did the CLCD unit weigh? | ||
+ | |||
+ | A $168) 5 pounds. | ||
+ | |||
+ | Q $169) What version of BASIC was to be included with the CLCD computer? | ||
+ | |||
+ | A $169) 3.6. It contained all of Basic 3.5 plus a few extras. | ||
+ | |||
+ | Q $16A) The CLCD unit contained a port that could be used with a | ||
+ | Hewlett-Packard device. | ||
+ | |||
+ | A $16A) An HP bar code reader. | ||
+ | |||
+ | Q $16B) What microprocessor did the CLCD unit utilize? | ||
+ | |||
+ | A $16B) The 65C102 CPU. This CPU was built using the 65C02 core from | ||
+ | Western Design Center, who licenses the popular 65C816S CPU | ||
+ | as well. CBM licensed this chip at little or no cost as a result | ||
+ | of a lawsuit settlement between WDC and CBM over 6502 architecture | ||
+ | patent infringements. | ||
+ | |||
+ | Q $16C) In addition to the usual inclusion of standard Commodore ports, | ||
+ | what two industry standard ports were included on the CLCD? | ||
+ | |||
+ | A $16C) Centronics Parallel (printer) port, and an EIA-232 (RS-232C) port. | ||
+ | |||
+ | Q $16D) How much RAM did the CLCD computer include? | ||
+ | |||
+ | A $16D) 32kB of battery backed RAM. | ||
+ | |||
+ | Q $16E) How many pixels are on the LCD screen on the CLCD machine? | ||
+ | |||
+ | A $16E) 480 x 128 or 61440 pixels | ||
+ | |||
+ | Q $16F) How much ROM did the CLCD computer contain? | ||
+ | |||
+ | A $16F) 96kB of ROM, which held the OS and the integrated programs. | ||
+ | |||
+ | Q $170) What text is displayed on the screen of a Commodore 128 upon | ||
+ | bootup? | ||
+ | |||
+ | A $170) The following text is centered on either the 40 or 80 column | ||
+ | screen: | ||
+ | |||
+ | COMMODORE BASIC V7.0 122365 BYTES FREE | ||
+ | (C)1985 COMMODORE ELECTRONICS, | ||
+ | (C)1977 MICROSOFT CORP. | ||
+ | ALL RIGHTS RESERVED | ||
+ | |||
+ | Q $171) How many bytes free does a Commodore 128 have on powerup? | ||
+ | |||
+ | A $171) As shown above in Q $170, 122365 bytes. | ||
+ | |||
+ | Q $172) On the Commodore B-128 series, the bell beeps at the right margin. | ||
+ | What column is the default right margin on the B-128? | ||
+ | |||
+ | A $172) Column 70. | ||
+ | |||
+ | Q $173) When a Commodore C64 is hooked up to a 1541 and an MPS 801 | ||
+ | printer, everything is powered up and connected correctly, and | ||
+ | the floppy won't load. What is wrong? | ||
+ | |||
+ | A $173) The printer is offline. | ||
+ | will operate correctly. | ||
+ | |||
+ | Q $174) How do you access the " | ||
+ | |||
+ | A $174) One brute force way: | ||
+ | |||
+ | While in the machine language monitor, type: | ||
+ | |||
+ | m f63f5 f640b | ||
+ | |||
+ | Q $175) Some of you may remember the Commodore Magic Voice cartridge. | ||
+ | If so, how many words was in the base unit's vocabulary? | ||
+ | |||
+ | A $175) 235 | ||
+ | |||
+ | Q $176) Who write the 3+1 software bundled with the Commodore | ||
+ | Plus/4 in ROM. | ||
+ | | ||
+ | A $176) Tri Micro wrote the code, and created a version for the C64. | ||
+ | It turns out that the 3+1 software included with the Commodore | ||
+ | Plus/4 was originally designed to be but one of the many choices | ||
+ | for bundled software with the 264. When the focus changed, 3+1 | ||
+ | became the only software bundled, and some assumed Commodore | ||
+ | had written it. (Ref. RUN April 1985:43) | ||
+ | |||
+ | Q $177) The BASIC extension " | ||
+ | |||
+ | A $177) David Simons (Ref: Commodore Power/Play April/May 1985:56-7) | ||
+ | |||
+ | Q $178) Simons' | ||
+ | manufacturer' | ||
+ | |||
+ | A $178) Hewlett Packard. | ||
+ | |||
+ | Q $179) How many commands does Simons' | ||
+ | |||
+ | A $179) 114. (P/P Apr/May 1985:57) | ||
+ | |||
+ | Q $17A) In the United Kingdom, there was an extension to Simons' | ||
+ | developed by David. | ||
+ | about the original BASIC extension does it address? | ||
+ | |||
+ | A $17A) Renumbering GOTOs and GOSUBs when renumbering a program. | ||
+ | |||
+ | Q $17B) In the Commodore Plus/4 File Manager, there exists two bugs, | ||
+ | which show up if you have over a certain number of records. | ||
+ | is this magic number? | ||
+ | |||
+ | A $17B) When merging over 255 records in the Word Processor, a printout might | ||
+ | stop early int the file and continually reprint a single record, or | ||
+ | entering one record might trash another record. (RUN April 1985:43) | ||
+ | |||
+ | Q $17C) Commodore Semiconductor Group (CSG) manufactured an 8500 IC. | ||
+ | What common IC number is this IC functionally equivalent to? | ||
+ | |||
+ | A $17C) The 6502. The change in number owes more to a change in | ||
+ | manufacturing process than anything else. | ||
+ | |||
+ | Q $17D) How many BASIC commands were included in BASIC 3.5, not | ||
+ | including the monitor commands? | ||
+ | |||
+ | A $17D) 80. (RUN November 1984:37) | ||
+ | |||
+ | Q $17E) On the Commodore VIC-20, 64, and C16 keyboards, what row and | ||
+ | column pins on the keyboard connector does the letter D | ||
+ | correspond to? | ||
+ | |||
+ | A $17E) Row 2 Column 2. (RUN July 1984:109) | ||
+ | |||
+ | Q $17F) What is special about the keys in Row 4 of the hardware keyboard | ||
+ | matrix? | ||
+ | |||
+ | A $17F) Column 2-4 spell out CBM. (RUN July 84:109) | ||
+ | |||
+ | Q $180) Most people know what CPU is in a Commodore disk drive, but what | ||
+ | CPU powers the venerable CBM 1525 printer? | ||
+ | |||
+ | A $180) You had better sit down.... The 1525 is powered by an Intel 8039 | ||
+ | 8-bit microcontroller. | ||
+ | since Commodore didn't actually develop the printer, but used a | ||
+ | Seikosha GP-100 printer mechanism for the unit, and most likely | ||
+ | contracted Seikosha to develop the firmware. | ||
+ | |||
+ | Q $181) What is the maximum number of characters per line on a CBM 1520? | ||
+ | |||
+ | A $181) 80. 22 columns per inch times 3.63... inches of usable paper width. | ||
+ | |||
+ | Q $182) Commodore rarely manufactured its own printer mechanisms. | ||
+ | mechanism did Commodore use in the DPS 1101? | ||
+ | |||
+ | A $182) The Juki 6100 printer mechanism. | ||
+ | |||
+ | Q $183) What is unique about the DPS 1101 printer? | ||
+ | |||
+ | A $183) It is daisy-wheel, | ||
+ | makes it unique is that it is the only such serial daisy-wheel made | ||
+ | for the Commodore line. | ||
+ | |||
+ | Q $184) Which was the first Commodore modem with DTMF dialling capabilities? | ||
+ | |||
+ | A $184) The first to offer some kind of DTMF support was the Commodore 1660 | ||
+ | modem. | ||
+ | a cable to allow the SID to output to the phone line. Thus, with the | ||
+ | SID's ability to reproduce DTMF tones, the modem could tone dial. | ||
+ | Note that this was only possible on the C64, which has a SID. The | ||
+ | first mode to INCORPORATE DTMF into the modem itself was the 1670. | ||
+ | |||
+ | Q $185) Which was the last Commodore 8-bit peripheral drive developed? | ||
+ | |||
+ | A $185) By develop, we are referring to actually produced models. | ||
+ | definition, the 1581 holds this title. | ||
+ | produced, The prototype 1590-D-1 3.5" 1.44 MB model owned by Jack | ||
+ | Vander White probably was the last under development. | ||
+ | |||
+ | Q $186) What is the maximum size of RAM available for use for program | ||
+ | storage on an expanded VIC-20 | ||
+ | |||
+ | A $186) If you discount the screen area (512 bytes) and Color RAM (512 bytes), | ||
+ | up to 28159 bytes can used for BASIC programs and variables (original | ||
+ | 3583 bytes and 3 banks of 8192 bytes each), and up to 40448 bytes can | ||
+ | be used for ML programs. | ||
+ | 40960-49151). | ||
+ | |||
+ | Q $187) One of the most poular magazines for computers in the 1980's was | ||
+ | COMPUTE! | ||
+ | |||
+ | A $187) COMPUTE!' | ||
+ | |||
+ | Q $188) In a strange twist of irony, COMPUTE! was itself descended from a | ||
+ | Commodore content magazine. | ||
+ | |||
+ | A $188) The PET Gazette. | ||
+ | Lindsey. | ||
+ | at times 4000 people. | ||
+ | headed by Robert Lock, purchased the magazine from Len and changed | ||
+ | the name to COMPUTE. | ||
+ | systems at that time. The first issue of COMPUTE. appeared in the | ||
+ | Fall of 1979. It seems the relationship between Len Lindsay and | ||
+ | Robert Lock was less than ideal, but I refer readers to INFO #15, | ||
+ | page 8 for the scoop. | ||
+ | |||
+ | Q $189) COMPUTE! underwent a name change very shortly after introduction. | ||
+ | What subtle change was made to the name? | ||
+ | |||
+ | A $189) COMPUTE. changed to COMPUTE! | ||
+ | |||
+ | Q $18A) How were LOADSTAR and Commodore Microcomputing-Power/ | ||
+ | connected? | ||
+ | |||
+ | A $18A) In the mid 1980' | ||
+ | both magazines in the disk magazine. | ||
+ | |||
+ | Q $18B) What is the fastest Commodore ever clocked a 6502 or derivative | ||
+ | CPU in a machine? | ||
+ | |||
+ | A $18B) The CSG65CE02 CPU, clocked at up to 3.54 MHz in the Commodore 65 | ||
+ | (64DX) prototype. | ||
+ | |||
+ | Q $18C) Name one byte that yields the same character when printed and poked | ||
+ | to a Commodore screen. | ||
+ | |||
+ | A $18C) Any byte between 32 and 63 will produce identical results. | ||
+ | |||
+ | Q $18D) Quick, which chr$ value flips to uppercase/ | ||
+ | |||
+ | A $18D) chr$(14) | ||
+ | |||
+ | Q $18E) Quicker, which chr$ value flips it back to uppercase/ | ||
+ | |||
+ | A $18E) chr$(142) | ||
+ | |||
+ | Q $18F) How do you get INPUT to not display a question mark? | ||
+ | |||
+ | A $18F) open 1, | ||
+ | |||
+ | Q $190) In reference to Commodore, what does TOI stand for? | ||
+ | |||
+ | A $190) The Other Intellect. | ||
+ | engineers were working on before the VIC-20 project. | ||
+ | sounds like it was dreamed up after the fact. In either case, this | ||
+ | machine might have been the "Color PET" mention in _The Home | ||
+ | Computer Wars_ that Chuck Peddle was designing before company | ||
+ | shifted to the VIC architecture. | ||
+ | |||
+ | Q $191) Name two values that, when poked to the screen, will yield the | ||
+ | identical character appearance. | ||
+ | |||
+ | A $191) 32 and 96 or 160 and 224. Space and reverse space. | ||
+ | 103 and 106 or 101 and 116. Left and right lines. | ||
+ | |||
+ | Q $192) What chr$ codes lock out and re enable the shift/ | ||
+ | flip from uppercase to lowercase on the VIC-20? | ||
+ | |||
+ | A $192) chr$(8) and chr$(9), respectively. | ||
+ | |||
+ | Q $193) What chr$ codes lock out and re enable the shift/ | ||
+ | flip from uppercase to lowercase on the C64? | ||
+ | |||
+ | A $193) chr$(8) and chr$(9), respectively. | ||
+ | |||
+ | Q $194) What chr$ codes lock out and re enable the shift/ | ||
+ | flip from uppercase to lowercase on the C128? | ||
+ | |||
+ | A $194) chr$(11) and chr$(12), respectively, | ||
+ | |||
+ | Q $195) On CBM machines prior to the VIC-20, what chr$ code outputs the | ||
+ | same character as chr$(44), the comma. | ||
+ | |||
+ | A $195) 108. | ||
+ | |||
+ | Q $196) Is the character described in $195 of any use? | ||
+ | |||
+ | A $196) To put commas in strings read via INPUT. | ||
+ | a comma (chr$(44)) as a delimiter between input fields, but chr$(108) | ||
+ | does not produce the same effect, so you could replace 44 with 108 in | ||
+ | data written to disk, and read it in with INPUT. | ||
+ | |||
+ | Q $197) The speed of Commmodore BASIC increased dramatically after the first | ||
+ | OS upgrade in 1979. Why? | ||
+ | |||
+ | A $197) Jim Butterfield supplies us the answer: | ||
+ | |||
+ | " | ||
+ | | ||
+ | the original code would write to screen memory only during | ||
+ | the " | ||
+ | | ||
+ | out, the screen sparkle was solved, and characters were | ||
+ | | ||
+ | | ||
+ | and used zero page very heavily, to the dismay of home | ||
+ | | ||
+ | | ||
+ | the screen reorganization that caused 95% of the | ||
+ | | ||
+ | --Jim | ||
+ | | ||
+ | Related to this question is $00C, which implies that the | ||
+ | " | ||
+ | increased the performance of the original PET by setting the RETRACE | ||
+ | line mentioned above to an output, which fooled the system into | ||
+ | thinking the video was ALWAYS in RETRACE mode. | ||
+ | |||
+ | Q $198) COMAL, a programming language available for Commodore computers, was | ||
+ | created by whom? | ||
+ | |||
+ | A $198) Borge Christensen and Benedict Lofstedt, although Borge is given | ||
+ | the most credit. | ||
+ | |||
+ | Q $199) At the 1980 COMDEX, Commodore PETs proved instrumental during a | ||
+ | crisis. | ||
+ | |||
+ | A $199) The following is excerpted from _The Whole PET Catalog_, page 21: | ||
+ | |||
+ | " | ||
+ | | ||
+ | to help track rooms, guests, etc. According to _InfoWorld_, | ||
+ | 7 PETs with OZZ data-bases (predecessor to SILICON OFFICE) | ||
+ | were used for two straight days. Local police agreed they | ||
+ | could not have kept of the guests as well as the PETs did. | ||
+ | Also, untrained operators quickly learned the system. | ||
+ | | ||
+ | |||
+ | Q $19A) Who designed the PET/CBM 8032 computer? | ||
+ | |||
+ | A $19A) Bill Seiler, the able assistant to Chuck Peddle, designed the unit. | ||
+ | |||
+ | Q $19B) What was the " | ||
+ | |||
+ | A $19B) No answer available yet (I can't find my notes!) | ||
+ | |||
+ | Q $19C) On a PET/CBM (early models), what will "POKE 14,1" do? | ||
+ | |||
+ | A $19C) If done immediately prior to an INPUT, the poke will suppress the | ||
+ | question mark prompt. | ||
+ | |||
+ | Q $19D) What version of BASIC would not utilize disk drives? | ||
+ | | ||
+ | A $19D) BASIC 1.0 | ||
+ | |||
+ | Q $19E) Who is Lyman Duggan and why is he important? | ||
+ | |||
+ | A $19E) He is one of the founding fathers of the Toronto PET User's Group | ||
+ | (TPUG), along with Jim Butterfield. | ||
+ | |||
+ | Q $19F) Jim Butterfield notes to me that he received plenty of help in | ||
+ | creating the first PET memory map (Q $0D8) from the Sphinx group, | ||
+ | who published critical information in their early newsletters. | ||
+ | did Commodore influence the name of the group? | ||
+ | |||
+ | A $19F) The name " | ||
+ | the Great Sphinx, the Lion with the head of a pharoah. | ||
+ | |||
+ | Q $1A0) Commodore produced an assembler for the 128 called HCD65. | ||
+ | does HCD stand for? | ||
+ | |||
+ | Q $1A1) Who wrote most of RAM DOS? | ||
+ | |||
+ | Q $1A2) What is the name of the first C64 disk copy program? | ||
+ | sported a "gas gauge" | ||
+ | |||
+ | Q $1A3) What was the case color of the original Commodore 64s? | ||
+ | |||
+ | Q $1A4) There are at least two ways to enter 64 mode from 128 mode on a C128: | ||
+ | go 64 and sys 65357. | ||
+ | they differ in at least one noticable way. How? | ||
+ | |||
+ | Q $1A5) What CPU powers the B-128 computer system? | ||
+ | |||
+ | Q $1A6) What type of drive mechanisms are in the D series hard drives from | ||
+ | Commodore? | ||
+ | |||
+ | Q $1A7) Commodore produced a 16kB RAM expander for the Commodore VIC-20. | ||
+ | What is its model number? | ||
+ | |||
+ | Q $1A8) Commodore produced at least one disk drive with an optical track | ||
+ | one sensor. | ||
+ | |||
+ | Q $1A9) The Commodore PET series used the IEEE bus to communicate with | ||
+ | peripherals. | ||
+ | are supported by the PET? | ||
+ | |||
+ | Q $1AA) Many people have developed Commodore software with the PAL assembler. | ||
+ | What does PAL stand for? | ||
+ | |||
+ | Q $1AB) Many people remember Compute' | ||
+ | for the word processor program it shared with thousands of | ||
+ | subscribers. | ||
+ | |||
+ | Q $1AC) In some 6502 assemblers, the opcode " | ||
+ | for " | ||
+ | is this opcode referring to? | ||
+ | |||
+ | Q $1AD) If I wanted to do a " | ||
+ | opcode would i use? | ||
+ | |||
+ | Q $1AE) Each Commodore peripheral has a device number, which is associated | ||
+ | with a type of device. | ||
+ | printer. | ||
+ | However, one peripheral in the PET was phased out and its device | ||
+ | number was reused. | ||
+ | |||
+ | Q $1AF) What is the maximum amount of general purpose RAM can one utilize | ||
+ | in a stock C64? (I need an exact number here) | ||
+ | |||
+ | ========================================================================= | ||
+ | </ | ||
+ | ====== Talking to TED: The MOS 7360/8360 Text Display ICs ====== | ||
+ | < | ||
+ | by Levente Harsfalvi (TLC@MSZI.PMMF.HU) | ||
+ | |||
+ | @(A): Introduction | ||
+ | |||
+ | This information file is based on my old books, descriptions, | ||
+ | my experiences while I was coding. | ||
+ | was not very famous in the world, but they were very poular in mideast | ||
+ | Europe. | ||
+ | some of this information while writing demos for the machine in demo groups, | ||
+ | while other things were gleaned from personal work on the machine. | ||
+ | computers did indeed play an important part in Commodore computer history. | ||
+ | |||
+ | I started my first code development on a Plus/4 in late 1986. After I saw a | ||
+ | HomeLab 3 (made in Hungary, U880 - GDR made Z80 compatible proc, B/W, 16K), | ||
+ | I started writing demos and other software for the Plus/4 machine I owned. | ||
+ | It actually wasn't that strange to see demo groups sprout up for all | ||
+ | kinds of machines, including the Plus/ | ||
+ | and individuals, | ||
+ | each machine. | ||
+ | for the Plus/4 in Hungary, Germany, and as far away as Alaska. | ||
+ | |||
+ | @(A): Overview | ||
+ | |||
+ | Let's discuss the TExt Editor (TED) IC and its environment. This DIL-48 IC | ||
+ | was designed specifically for the 264 series of machines, which initially | ||
+ | included the CV364 and the 264, evolving into the Plus/4, C16, and C116 | ||
+ | machines. | ||
+ | suited to any other system. | ||
+ | | ||
+ | The TED contains all functions done by several chips in former Commodore | ||
+ | computers. The TED is a complete video-interface and composite video | ||
+ | signal generator, sound generator, keyboard input latch, timer, | ||
+ | clock generator, memory manager and DRAM refresher in a single IC. It can | ||
+ | address the full memory map of the 264 series machines, and it generates | ||
+ | the RAS', CAS', and MUX signals for the DRAM memory used in that series. | ||
+ | For ROM, it generates the chip select (CS) lines, depending on the state | ||
+ | of the internal registers. | ||
+ | TED IC is a simplistic MMU as well. | ||
+ | |||
+ | @(A): Video Information | ||
+ | |||
+ | We see the TED chip shine as it does its primary job, displaying graphics. | ||
+ | Its abilities mostly parallel those of the uniquitous VIC-II video IC in the | ||
+ | C64. It has the following modes: | ||
+ | |||
+ | * 40x25 screen (characters) | ||
+ | * enhanced color mode | ||
+ | * multicolor mode | ||
+ | * 320x200 Hi-Res Graphics | ||
+ | * 160x200 Multicolor Graphics | ||
+ | |||
+ | Of course, there are differences. | ||
+ | |||
+ | To offset this omission, the TED chip can select 8 intensities for each of | ||
+ | the 16 supported colors, giving 121 colors (the 8 shades of black are all | ||
+ | black). | ||
+ | and hardware inverse character support. | ||
+ | memory, and graphics bitplanes can be addressed directly, without additional | ||
+ | logic as found on the C64. In fact, even RAM/ROM selection requires change | ||
+ | of a single bit. | ||
+ | |||
+ | Character modes need $800 bytes of RAM for screen and color memory. The | ||
+ | first $400 bytes act as color memory (the memory permanently located at | ||
+ | $d800 on the C64), with the lower 4 bits containing color codes, exactly | ||
+ | as found on the 64. Bits 4-6 denote the intensity level of the color, while | ||
+ | the high bit select flashing/ | ||
+ | contain the screen codes for the displayed characters. | ||
+ | character inversion is selected, the lower 7 bits hold the screen code and | ||
+ | the high bit selects inversion for the character. | ||
+ | is not selected, all 8 bits denote the screen code. Extended Color Mode (ECM) | ||
+ | and Multi Color Mode (MCM) modes work exactly as described on the 64. While | ||
+ | these two modes are in effect, inversion and blinking are disabled. | ||
+ | |||
+ | Things get a bit more complex in graphics mode (pun unintentional). | ||
+ | graphcis mode, the bitplane occupies $2000 bytes and is handled just like a | ||
+ | VIC-II biplane. | ||
+ | for color memory, which is laid out in $400 bytes of intensity memory | ||
+ | and $400 bytes of color memory. | ||
+ | lowest nybble of the appropriate color memory location as the color and | ||
+ | retreieves the intensity from bits 4-6 of the appropriate intensity memory | ||
+ | location. | ||
+ | appropriate color memory location, while the intensity is taken from bits | ||
+ | 0-2 of the intensity memory location. | ||
+ | unused. | ||
+ | |||
+ | In multicolor mode, differences abound. | ||
+ | utilize 3 different colors in each 8x8 cell and a single background. | ||
+ | TED simply cannot accomplish this due to the lack of adequate color memory. | ||
+ | So, TED allows only 2 varying colors per 8x8 cell. Those colors are chosen | ||
+ | from the palette of 121. The remaining 2 colors are chosen for the | ||
+ | entire screen, again from the 121 color palette. | ||
+ | follows: | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The TED IC is able to generate both PAL and NTSC compatible signals from | ||
+ | a single IC. Only the crystal need be changed to go from one standard to | ||
+ | the other. | ||
+ | lines of display. | ||
+ | NTSC mode. It's always 57 clock cycles per rasterline. | ||
+ | the supplied crystal frequency by 20 for PAL display and by 16 for NTSC. | ||
+ | |||
+ | For the serious video programmer, raster interrupts are implemented as on the | ||
+ | VIC-II. | ||
+ | of the character screen area, not the top of the border. | ||
+ | current raster line can be read from TED registers. | ||
+ | counter as well. Doing so will most likely affect the screen display. | ||
+ | a bonus, the horizontal location of the raster can be read and modified in | ||
+ | the same way. Unfortunately, | ||
+ | effects, as the TED can't handle sprites. | ||
+ | |||
+ | @(A): Running The Show | ||
+ | |||
+ | As earlier mentioned, the TED IC does more than produce graphics. | ||
+ | its tasks involves generating the clock signal for the 7501/ | ||
+ | microprocessor. | ||
+ | 885 kHz and twice that speed, 1.773 Mhz. The speed depends on TED's current | ||
+ | task. It generates the slower clock signal when refreshing DRAM or fetching | ||
+ | data for the video screen. | ||
+ | The user can disable fast clock generation via a register. | ||
+ | is a machine that operates at approximately 1 MHz, as the CPU runs in slow | ||
+ | mode while the screen is displayed, and operates in fast mode when the | ||
+ | TED starts drawing the top and bottom borders. | ||
+ | |||
+ | @(A): Sound Advice | ||
+ | |||
+ | As far as a sound device is concerned, the TED doesn' | ||
+ | SID in the 64. Just 2 squarewave generators, of which the second can be | ||
+ | switched to generate white-noise, | ||
+ | Volume control is available in 8 levels. | ||
+ | |||
+ | To play samples, the TED can switch the sound generators to constant level | ||
+ | outputs. | ||
+ | generator can generate frequencies from 100Hz to 23kHz. | ||
+ | |||
+ | @(A): Other features | ||
+ | |||
+ | The timers available in the TED appear to be nothing more than 16 | ||
+ | bit decrementing timers. | ||
+ | The first timer reloads its starting value when it reaches 0, the other 2 | ||
+ | are free-running. | ||
+ | |||
+ | Since it already does almost everything else, it's not unusual to notice | ||
+ | the TED handles the keyboard matrix. | ||
+ | keyboard interfacing. | ||
+ | |||
+ | As noted above, a single bit in the register space will page ROM or | ||
+ | RAM into the upper 32kB of the address map. Since the TED knows what is | ||
+ | paged in at all times, it knows what to output to access the memory | ||
+ | locations in this area. | ||
+ | |||
+ | @(A): Conclusion | ||
+ | |||
+ | Well, that about wraps up the TED IC. All that is left is a map of the | ||
+ | registers. | ||
+ | If you have questions, I cna be reached at the Internet address listed above | ||
+ | or at: | ||
+ | |||
+ | Levente Harsfalvi | ||
+ | 7200 Dombovar | ||
+ | Gorkij 33. | ||
+ | Hungary | ||
+ | |||
+ | By the way, catch FLI ED. V1.0; Its info file may contain some more about | ||
+ | TED's screen-handling. It may be retrieved as | ||
+ | ftp:// | ||
+ | |||
+ | @(A): Register Map | ||
+ | |||
+ | Register | ||
+ | -------- | ||
+ | $ff00- $ff01: Counter #01. It always starts to decrement from the last | ||
+ | written value into it. | ||
+ | $ff02- $ff03: Counter #02. It runs freely from $ffff. | ||
+ | $ff04- $ff05: Counter #03. Same as above. | ||
+ | $ff06 : Mostly the same as VIC's $d011. | ||
+ | Bit 0,1,2 : Vertical smooth-scrolling | ||
+ | Bit 3 : 24/25 rows screen | ||
+ | Bit 4 : Blank screen | ||
+ | Bit 5 : Bitplane mode | ||
+ | Bit 6 : Enhanced color mode | ||
+ | Bit 7 : TED's internal test, it should be 0. | ||
+ | $ff07 : Most similar VIC-reg is $d016. | ||
+ | Bit 0,1,2 : Horizontal smooth-scrolling | ||
+ | Bit 3 : 40/38 columns screen | ||
+ | Bit 4 : Multicolor mode | ||
+ | Bit 5 : TED stop. If set, the TED stops it's counters and | ||
+ | screen-generating, | ||
+ | cycles remain. | ||
+ | Bit 6 : PAL/NTSC. 0:PAL, 1:NTSC | ||
+ | Bit 7 : Disable reverse mode. If 0, we got 128 characters | ||
+ | and higmost bit tells if the character should | ||
+ | appear in inverse. If set, no inverse mode but | ||
+ | 256 characters. | ||
+ | $ff08 : Keyboard input latch. Giving a strobe - writing to the register, | ||
+ | the latch stores the values of the input-lines. Then, we | ||
+ | can read them from this register. | ||
+ | $ff09 : Interrupt request register. When a counter sends want to send | ||
+ | an IRQ, it's bit will appear as a 0; then, if the IRQ was | ||
+ | caused then highmost bit is set. | ||
+ | Bit 0 : Unused | ||
+ | Bit 1 : Raster-counter | ||
+ | Bit 2 : Lightpen. Not implemented. | ||
+ | Bit 3 : Counter #1 | ||
+ | Bit 4 : Counter #2 | ||
+ | Bit 5 : Unused | ||
+ | Bit 6 : Counter #3 | ||
+ | Bit 7 : Interrupt occured. This bit is set when an IRQ | ||
+ | was enabled and therefore, the IRQ was sent to the | ||
+ | processor. Physically, this is the negated level of | ||
+ | the TED's IRQ output. The IRQ should be deleted | ||
+ | with writing the register-value back after | ||
+ | accepting an interrupt. | ||
+ | $ff0a : Interrupt mask register. These bits could be used to disable and | ||
+ | enable interrupt-sources. When a place is set to 1, that will | ||
+ | be able to cause an interrupt to the processor. If not, the sign | ||
+ | of the interrupt request will only be appear in the above | ||
+ | register. | ||
+ | Bit 0 : 9th bit of $ff0b (see there) | ||
+ | Bit 1 : Raster-counter | ||
+ | Bit 2 : Lightpen. Not implemented. | ||
+ | Bit 3 : Counter #1 | ||
+ | Bit 4 : Counter #2 | ||
+ | Bit 5 : Unused | ||
+ | Bit 6 : Counter #3 | ||
+ | Bit 7 : Unused | ||
+ | $ff0b : Raster interrupt register. Same as $d012 when writing; it stores | ||
+ | the position of occuring raster interrupt. Higmost bit is in | ||
+ | $ff0a' | ||
+ | $ff0c,$ff0d : Hardware-cursor position (10 bits). Lower bits: $ff0d, higher | ||
+ | 2 bits in $ff0c' | ||
+ | not seeable. | ||
+ | $ff0e : This reg is the first sound-source' | ||
+ | More 2 bits are in $ff10' | ||
+ | $ff0f : 2nd. source, lowmost 8 bits. More 2 bits in $ff12, 0. and 1. | ||
+ | places. | ||
+ | The soundregister-value can be calculated as | ||
+ | reg=1024-(111860.781/ | ||
+ | reg=1024-(111840.45 /frq[Hz]) (PAL) | ||
+ | $ff10 : 1st. sound-source, | ||
+ | $ff11 : Sound control register. | ||
+ | Bit 0-3 : Volume. Maximum value is 8. | ||
+ | Bit 4 : Sound #1 on/off. | ||
+ | Bit 5 : Sound #2 squarewave on/off. | ||
+ | Bit 6 : Sound #2 noise on/off. If You set both, the square | ||
+ | will sound. | ||
+ | Bit 7 : D/A mode. See above for more. | ||
+ | $ff12 : Bit 0,1 : 2nd sound-source, | ||
+ | Bit 2 : Character generator in ROM or RAM. When set, TED | ||
+ | will enable ROM when trying to get data from the | ||
+ | charactergenerator to build screen. Else, it will | ||
+ | give out control-signals to the DRAM' | ||
+ | Bit 3,4,5 : These bits tell, where to find bitplane in the | ||
+ | memory when using bitplane-mode. TED assumes them | ||
+ | as A15,A14 and A13 bits. So, the bitplanes can be | ||
+ | switched as 8K pages, anywhere in the 64K. | ||
+ | Bit 6-7 : Unused. | ||
+ | $ff13 Bit 0 : A sign to having control about memory paging. This | ||
+ | bit always sets to 1 when ROM is active over $8000. | ||
+ | Else, it will be 0. READ ONLY. | ||
+ | Bit 1 : Force single clock mode. Then, TED will disable to | ||
+ | generate twiee clock. | ||
+ | Bit 2-7 : Charactergenerator. Bit 7 corresponds to A15, 6 to | ||
+ | A14 and so on. This value shows and sets the start | ||
+ | of the charactergenerator. It can be paged as $400 | ||
+ | bytes. Use with addition of $ff12-2.bit. | ||
+ | $ff14 Bit 0-2 : Unused | ||
+ | Bit 3-7 : Start of the video-ram. Bit 7 also corresponds to | ||
+ | the A15 line as above. So, video-ram is mappable | ||
+ | as $800 bytes - 2K. The above $ff12-2.bit doesn' | ||
+ | affect this, but the actual RAM/ROM mapping (see at | ||
+ | $ff3e/$ff3f and $ff13/0) does. | ||
+ | $ff15 : Background. Lower bits contain color-code, higher 3 luminance | ||
+ | and higmost is ignored. | ||
+ | $ff16 : Color-reg 1 | ||
+ | $ff17 : Color-reg 2 | ||
+ | $ff18 : Color reg 3. This and the above are used in ECM and MCM modes. | ||
+ | $ff19 : Border. All color registers use codes as described in $ff15. | ||
+ | $ff1a : Bit 0-1 : Higmost bits of the next $ff1b | ||
+ | Bit 2-7 : Unused | ||
+ | $ff1b : Actual character-position. Higmost bits in the above register. | ||
+ | TED counts the characters that it had fetched and put out to | ||
+ | the screen. The number is increasing by 40 after every | ||
+ | characterline (8 rasterline). | ||
+ | $ff1c : Bit 0 : Higmost bit of $ff1d | ||
+ | Bit 1-7 : Unused | ||
+ | $ff1d : Actual position of vertical scanning. Higmost | ||
+ | bit is in $ff1c. Read/ | ||
+ | $ff1e : Actual position of horizontal scanning. R/W!. Lowmost bit is | ||
+ | unused. It contains the TED's internal counter' | ||
+ | bits. So, it increases 4 with every character. When writing, | ||
+ | it seems to put the value to a functionally different register | ||
+ | (writing back a reading value in right time affects the screen). | ||
+ | $ff1f : Bit 0,1,2 : Actual vertical scanning-line in a character-row. | ||
+ | R/W!. | ||
+ | Bit 3-6 : Flashing counter. It's value increases with every | ||
+ | frame, and TED fits it's flashing feature to this | ||
+ | register' | ||
+ | Bit 7 : Unused | ||
+ | $ff3e : Switching to ROM. A writing statement to this address will | ||
+ | cause to turn on the ROM between $8000-$ffff. It's an other | ||
+ | matter, which one; this time, only sure thing that it'll give | ||
+ | CS signals instead of RAS', CAS' and MUX. | ||
+ | See $ff13/0 and $ff14 | ||
+ | $ff3f : Switching to RAM. The opposite of the above. | ||
+ | |||
+ | ============================================================================ | ||
+ | |||
+ | @(#)error: ? DS, DS$: rem The Error Channel | ||
+ | |||
+ | We are not aware of any errors with issue 11, save the changes to some WWW | ||
+ | addresses as noted in Hack Surfing (Reference: surf). | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== The Next Hack ====== | ||
+ | < | ||
+ | | ||
+ | "... and that's not all you get." | ||
+ | what Commodore Hacking is cooking in its TV informercial cookware for | ||
+ | issue #13: | ||
+ | |||
+ | o CMD has announced that SuperCPU development units should be made | ||
+ | | ||
+ | | ||
+ | |||
+ | o Exploiting the 65C816S. | ||
+ | to allow testing of the examples with the CMD SuperCPU. | ||
+ | will detail the new opcodes available to programmers, | ||
+ | | ||
+ | | ||
+ | |||
+ | o Let's get HTMLized! | ||
+ | do HTML. There' | ||
+ | | ||
+ | CBM system, so C=Hacking begins a 4 part series on the language and | ||
+ | how to render HTML pages on a Commodore machine. | ||
+ | |||
+ | o And, of course, C=Hacking' | ||
+ | |||
+ | So, go ahead, buy that box of disks, and label one now for Commodore | ||
+ | Hacking Issue #13. | ||
+ | |||
+ | ============================================================================ | ||
+ | </ | ||
+ | ====== Hacking the Code ====== | ||
+ | < | ||
+ | |||
+ | For articles in Commodore Hacking that include binary files as part | ||
+ | of their article, these binaries files are made available in this section | ||
+ | as encoded text files. | ||
+ | which is a standard widely used on the Internet to transmit binary files | ||
+ | using only printable ASCII characters. | ||
+ | must be decoded with a suitable decoding program before they can executed. | ||
+ | Typical examples inlucde UUXFER for the 64, uudecode on the ACE OS for the | ||
+ | 64 and 128, and uudecode on most UNIX OS machines. | ||
+ | multiple files, while others will require the user to manually split this | ||
+ | section into individual pieces prior to decoding. | ||
+ | |||
+ | WARNING: | ||
+ | PETSCII. | ||
+ | section to a PETSCII mode computer system, or download this section without | ||
+ | translation to PETSCII. | ||
+ | UUCode files, but the practice is not recommended because conversion is | ||
+ | typically done in a telecommunications program and cannot be guaranteed to | ||
+ | be accurate. | ||
+ | |||
+ | @(A)polycode: | ||
+ | |||
+ | begin 600 polygonamy | ||
+ | M`0@0", | ||
+ | M+80NA: | ||
+ | M!I`2*0& | ||
+ | M\`3& | ||
+ | MF@%E_H6, | ||
+ | MI/ | ||
+ | MUJDWA0' | ||
+ | MS+& | ||
+ | M*=@8@$I*4MK(T.KN/ | ||
+ | MU*F`G0; | ||
+ | MU*`" | ||
+ | M> | ||
+ | M)(" | ||
+ | M3`X"? | ||
+ | M%*J`F!# | ||
+ | M^.; | ||
+ | M$=# | ||
+ | MQ@8`+P, | ||
+ | M`(!& | ||
+ | MO1!, | ||
+ | M`" | ||
+ | M*P=L/ | ||
+ | M, | ||
+ | M, | ||
+ | MT-# | ||
+ | M; | ||
+ | M-87@& | ||
+ | M3F/ | ||
+ | M9OZE].WUR2# | ||
+ | MIG+V/ | ||
+ | MA@(& | ||
+ | M%00$`04TG3(8(# | ||
+ | M!@< | ||
+ | MA8JP(U^)C@0L9I2H4!" | ||
+ | MCY" | ||
+ | MO+V^O\# | ||
+ | MZ> | ||
+ | M!P7((B`>' | ||
+ | MQ</ | ||
+ | M=G1S< | ||
+ | M(2!H, | ||
+ | M`T" | ||
+ | M%]XC3$U.2X]; | ||
+ | MQT> | ||
+ | M\_7W^? | ||
+ | M[NSJZ>? | ||
+ | MGYZ< | ||
+ | M8%]> | ||
+ | M, | ||
+ | M%A6$(*`G)FH))< | ||
+ | MH)R"; | ||
+ | M(" | ||
+ | M2$E*2TU.3U!14E-45E=865I; | ||
+ | M@8.$AH> | ||
+ | MR< | ||
+ | M[L2:< | ||
+ | M*`; | ||
+ | MR: | ||
+ | MT; | ||
+ | M2C\T*B`6# | ||
+ | M%Q01# | ||
+ | M14I055M@9FUS> | ||
+ | MV.7R``T; | ||
+ | MT>; | ||
+ | M, | ||
+ | M^!U": | ||
+ | M)E.`GWZB!!; | ||
+ | M`S5$%S8`%Q8!%Q(" | ||
+ | M# | ||
+ | M`@D# | ||
+ | M=' | ||
+ | MB!```01P`D``_Q@\\" | ||
+ | M' | ||
+ | M# | ||
+ | M_V" | ||
+ | M\._O[^[N[F> | ||
+ | MX># | ||
+ | ML\`=# | ||
+ | MZ? | ||
+ | M' | ||
+ | M4V!L> | ||
+ | MB)6BKKO' | ||
+ | MOLK7X_# | ||
+ | MQ# | ||
+ | M$2`P`2$3(C`!(Q, | ||
+ | M$S8P`3< | ||
+ | MHC4^V4< | ||
+ | M" | ||
+ | M"; | ||
+ | M*$)(P`103%C`!& | ||
+ | MT$S8P`3@3.C`!/ | ||
+ | M8$QHP`1P#' | ||
+ | M)O!@`O@B2BP""" | ||
+ | M)H!@`H@FD& | ||
+ | M"# | ||
+ | MF# | ||
+ | MF(`H" | ||
+ | MF(" | ||
+ | MCR($2$Q0P`183&# | ||
+ | MT, | ||
+ | M8, | ||
+ | M8`+P)O@GH, | ||
+ | M8`*`)HA@`I`FF& | ||
+ | M`0@3$# | ||
+ | M`9@3H# | ||
+ | M(`DHF(`P" | ||
+ | ML`FXF(# | ||
+ | M]2A" | ||
+ | M!-!, | ||
+ | M!& | ||
+ | MZ"; | ||
+ | M>": | ||
+ | M$0@P`1`3&# | ||
+ | M$Y@P`: | ||
+ | M()B`*`DPF(`X" | ||
+ | ML)B`N`G`F(# | ||
+ | M4H\B!$A, | ||
+ | M3-# | ||
+ | M3&# | ||
+ | MZ& | ||
+ | M>& | ||
+ | M%@$($Q`P`1@3(# | ||
+ | M, | ||
+ | M@" | ||
+ | M@+`)N)B`P`G(F(# | ||
+ | M*/ | ||
+ | MP`303-C`!.!, | ||
+ | MP`1@3& | ||
+ | M`N@F\& | ||
+ | M`G@F@& | ||
+ | M8A$(, | ||
+ | MD!.8, | ||
+ | M" | ||
+ | M";" | ||
+ | M.KH30$I(P`103%C`!& | ||
+ | MR, | ||
+ | M6, | ||
+ | MX"; | ||
+ | M<" | ||
+ | M/ | ||
+ | M, | ||
+ | MF(`8" | ||
+ | MF(" | ||
+ | M,# | ||
+ | M)F=@`F@F: | ||
+ | M)GY@`G\F@& | ||
+ | M(=# | ||
+ | M-" | ||
+ | M5U4N1415SR.0`08@< | ||
+ | M!R!UFAD).I%`$1& | ||
+ | MD%@H3P$%14< | ||
+ | M& | ||
+ | M!4]W%4$@4T5# | ||
+ | MJ0AT$T< | ||
+ | M05DP4*D$A? | ||
+ | M6*(*AFBB# | ||
+ | MR$R-`L`-@XTAW(*-(L`-1(U!W+R-0A9`=HT@%HTERP5G\3DV1' | ||
+ | M\" | ||
+ | M..8YI3H$%P.%.J6QK`+)P#" | ||
+ | MO!0$A3PI" | ||
+ | M// | ||
+ | M%.!`Y@< | ||
+ | M/ | ||
+ | M`, | ||
+ | M%T3RI/ | ||
+ | MIJW*$-REO]`_-/ | ||
+ | M6/ | ||
+ | MA; | ||
+ | M& | ||
+ | M6=+L2$4@5T%94R!/ | ||
+ | M4C`4PA< | ||
+ | M./ | ||
+ | M!`]0S/ | ||
+ | MT3CE0C6W" | ||
+ | MI# | ||
+ | MO0`5JJ0> | ||
+ | MJ& | ||
+ | M`44IL6](L6VD_SCQ; | ||
+ | M/ | ||
+ | M> | ||
+ | MQ(RA=HY@$T-XE1'# | ||
+ | MKB"" | ||
+ | MW78$T`K" | ||
+ | MK$)3BV`!8OB7)H@@J& | ||
+ | M$$$H$8@FH!19C$$T: | ||
+ | MI? | ||
+ | M@++& | ||
+ | MF@I02N; | ||
+ | MD!-2Q-R6`!(4)%.6$U3D!%4!ISL$R3RIC# | ||
+ | M`@4E%" | ||
+ | M0# | ||
+ | M52@" | ||
+ | M(44' | ||
+ | MJ-@!HF(' | ||
+ | M`T3%# | ||
+ | M'" | ||
+ | MRG($!`4YC@2E5(TE.E6-17`/ | ||
+ | MC`: | ||
+ | M)<? | ||
+ | MD7, | ||
+ | MAI" | ||
+ | M*H(R4A5# | ||
+ | MHXLCY00D.25!2H19DN-B)CDG04XHD" | ||
+ | M!" | ||
+ | M,: | ||
+ | M*HV$A: | ||
+ | M+(T" | ||
+ | M& | ||
+ | M0& | ||
+ | MF.D`D/ | ||
+ | M`< | ||
+ | M65*J" | ||
+ | MHI+*: | ||
+ | M, | ||
+ | M.H8`%MF0`QCFJ)$^QXP!/ | ||
+ | MI83\_? | ||
+ | MJ<: | ||
+ | MAK`# | ||
+ | M_VD`A5FEM' | ||
+ | M6JNEI^6IA:< | ||
+ | M3[)?, | ||
+ | M(%6FIJ< | ||
+ | MY;> | ||
+ | MPA.I`: | ||
+ | M7: | ||
+ | M; | ||
+ | M># | ||
+ | M" | ||
+ | M" | ||
+ | M" | ||
+ | ML$RXP`3`3, | ||
+ | M0$Q(P`103%C`!& | ||
+ | M)M!@`M@FX& | ||
+ | M)F!@`F@F<& | ||
+ | M)O!DH, | ||
+ | M># | ||
+ | M"# | ||
+ | MF(" | ||
+ | MF(`H" | ||
+ | ML, | ||
+ | M0, | ||
+ | M8`+0)MA@`N`FZ& | ||
+ | M8`)@)FA@`G`F>& | ||
+ | M8`+P: | ||
+ | M`7@3@# | ||
+ | M`0@3$# | ||
+ | MD`F8F(" | ||
+ | M(`DHF(`P" | ||
+ | M!+!, | ||
+ | M!$!, | ||
+ | MR"; | ||
+ | M6" | ||
+ | MZ"; | ||
+ | M$W@P`8`3B# | ||
+ | M$0@P`1`3&# | ||
+ | MD)B`F`F@F(" | ||
+ | M()B`*`DPF(`X" | ||
+ | M3+# | ||
+ | M3$# | ||
+ | MR& | ||
+ | M6& | ||
+ | MZ& | ||
+ | M, | ||
+ | M%@$($Q`P`1@3(# | ||
+ | M@)`)F)B`H`FHF(" | ||
+ | M@" | ||
+ | MP`2P3+C`!, | ||
+ | MP`1`3$C`!%!, | ||
+ | M`L@FT& | ||
+ | M`E@F8& | ||
+ | M`N@F\' | ||
+ | M< | ||
+ | M8A$(, | ||
+ | MF(" | ||
+ | MF(`@" | ||
+ | M!*A, | ||
+ | M!# | ||
+ | MP%`" | ||
+ | M4& | ||
+ | MX& | ||
+ | M@& | ||
+ | M@/ | ||
+ | M4=ID[GD$D!RI-L12X7``D"& | ||
+ | M8`" | ||
+ | M9!K1B$# | ||
+ | M7" | ||
+ | M22P0]-F^I(IQ6$`H$? | ||
+ | M*B0>& | ||
+ | M$" | ||
+ | M\1A`: | ||
+ | MQ@1" | ||
+ | MD.0YCN0ZD> | ||
+ | M3KDDD/ | ||
+ | M`1/ | ||
+ | MOK_`0HW$Q<;' | ||
+ | MIN; | ||
+ | MV]O; | ||
+ | M(``080`(" | ||
+ | MY@LZ!0P-# | ||
+ | M5" | ||
+ | M45)45EA96UU? | ||
+ | M# | ||
+ | M0A-%, | ||
+ | M=' | ||
+ | M0D4(/ | ||
+ | M3I$G8605(S$V.), | ||
+ | M<' | ||
+ | M`+N[QP!`4%6[@0" | ||
+ | M? | ||
+ | M!O]^`0EKH@0$0``P]^OW[]? | ||
+ | M^_\!I' | ||
+ | M@X!]> | ||
+ | M34]14U576EQ? | ||
+ | M? | ||
+ | M2H@!0" | ||
+ | M[NWLZ^GHY^; | ||
+ | M_? | ||
+ | MV# | ||
+ | M_MC%1; | ||
+ | M3%%66EYB96AL; | ||
+ | MIJ> | ||
+ | MQ, | ||
+ | MU]? | ||
+ | M_J7T[? | ||
+ | ,& | ||
+ | ` | ||
+ | end | ||
+ | |||
+ | ========================================================================= | ||
+ | </ |
magazines/chacking12.txt · Last modified: 2015-04-17 04:34 by 127.0.0.1