8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CHACKING11A.ARC / ISSUE11-A

Wrap

Text File | 2019-04-13 | 71.6 KB | 1,803 lines

######## ################## ###### ###### ##### ##### #### #### ## ##### #### #### #### #### #### ##### ##### ## ## #### ## ## ## ### ## #### ## ## ## ##### ######## ## ## ## ##### ## ## ## ## ## ##### ## ## ######## ## ## ## ### ## ## #### ## ## ##### #### #### #### #### ##### #### #### #### #### #### ###### ##### ## ###### ###### Issue #11 ################## Version 1.0 ######## December 1995 ------------------------------------------------------------------------------- #(@)contents: Table of Contents Features 6. Speed up RAMLink transfers with the Double-DMA Technique (Reference: dbldma) by Doug Cotton and Mark Fellows RAMLink Designer Mark Fellows and Technical Editor Doug Cotton of CMD describe a way of using a Commodore REU to increase transfer rates of the CMD RAMLink to one-half the speed of the REU transfer rate. 8. The Graphics Toolbox by Stephen Judd (Reference: toolbox) To add another tool to our toolbox, Stephen details a new algorithm for drawing ellipses. Some improvements to the circle routine in a previous column that will enable it to draw perfect circles of any radius is discussed, as well as details on using logarithms to perform division. 10. Design and Implementation of an Advanced Text Editor by Craig Bruce (Reference: zedace) Peer into the internal organization and implementation of an advanced text editor/word processor for the ACE environment. Relevant data structure, global variables, display maintenance, text "sloshing", and algorithms for many editing commands are detailed. Columns 4. Hi Tech Trickery by George Taylor (Reference: trick) Don't let anyone ever tell you the SID chip is only capable of 4 bit sample playback. George Taylor explains using the digi dithering technique to increase the SID's resolution. 12. Hacking Graphics by Rick Mosdell (Reference: gfx) Dig into this overview on how to set up the VIC-II to display Doodle and KOALA format pictures. The two formats are detailed, and similar formats are referenced. Departments 1. The (cough,cough) Hacking Editor (Reference: editor) 2. Input/Output (Reference: io) 3. Newsfront (Reference: news) 5. Hacking the Mags (Reference: mags) 7. UseNuggets (Reference: usenet) 9. Hack Surfing (Reference: surf) 11. Commodore Trivia (Reference: trivia) 13. ? DS, DS$: rem The Error Channel (Reference: error) 14. The Next Hack (Reference: next) ------------------------------------------------------------------------------- #(@)legal: Commodore Hacking Legal Notice Commodore and the respective Commodore product names are trademarks or registered trademarks of ESCOM GmbH. Commodore hacking is in no way affiliated with ESCOM GmbH, owners of said trademarks. Commodore Hacking is published 4 times yearly by: Brain Innovations Inc. 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 "net-magazine" or "e-zine" in its entirety for non-profit use. A charge of no more than US$5.00 may be charged by redistribution parties to cover printed duplication and no more than US$10.00 for other types of duplication to cover duplication and media costs for this publication. If this publication is included in a for-profit compilation, this publication must be alternately available separately or as part of a non-profit compilation. This publication, in regards to its specific ordering and compilations of various elements, is copyright(c) 1995 by Brain Innovations, Incorporated, unless otherwise noted. Each work in this publication retains any and all copyrights pertaining to the individual work's contents. For redistribution rights to individual works, please contact the author of said work or Brain Innovations, Inc. Brain Innovations, Inc. assumes no responsibility for errors or omissions in editorial, article, or program listing content. ------------------------------------------------------------------------------- #(@)info: Commodore Hacking Information Commodore Hacking is published via the Internet 4 times yearly, and is presented in both ISO-8859-1 and HTML versions. This and previous issues can be found at the Commodore Hacking Home Page (http://www.msen.com/~brain/chacking/), as well as via FTP (ftp://ccnga.uwaterloo.ca/pub/cbm/hacking.mag/) In addition, the Commodore Hacking mail server can be used to retrieve each issue. To request a copy of an issue, please send the following electronic mail message: To: brain@mail.msen.com Subject: MAILSERV Body of Message: help catalog send c=hacking11.txt quit 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 file in kilobytes you can receive in an email message. When in doubt, choose 64) example: subscribe c=hacking Jim Brain 100 Although no fee is charged for this magazine, donations are gladly accepted from corporate and individual concerns. All monies will be used to defray 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://www.msen.com/~brain/pub/c-hacking-submit.txt) or via the MAILSERV server (send c-hacking-submit.txt). ============================================================================ #(@)rch: Reading C=Hacking Starting with Issue 11 of Commodore Hacking, the new QuickFind indexing system is utilized to aid readers of the text version in navigating the magazine. At the top of each article or other important place in the magazine, a word prefixed with a special string is present. (See the title of this article for an example. Throughout the magazine, if an article is mentioned, it will be followed by a reference string. For example, if we mentioned this article, we would add (Reference: rch) after the name. By using your favorite editor's search function and searching for the string after the word "Reference:", prefixed by the magic prefix string, will move you directly to the article of choice. To merely skip to the next article in the magazine, search only for the magic prefix string. Some handy indexing strings possibly not referenced anywhere are: top top of issue bottom bottom of issue contents table of contents legal legal notice For those with access to a UNIX system, the command "what" can be run on the issue, which will result in all the article titles being printed. A slightly different magic prefix string "#(A)" is used to delimit sub-topics or main heading in articles. The text after the magic string differs depending on article content. For the Input/Output column (Reference: io), the text after the magic prefix will either be "c" for comment, or "r" for response. In features and columns, a number after the prefix indicates the ordinal of that heading or sub-topic in the article. If a specific sub-topic is referenced elsewhere in the article, a sub-topic reference will be indicated. A reference to "#(A)r" would be written as "(SubRef: r)". As time goes on, the role of this indexing system will be expanded and changed to ease navigation of the text version, but minimize the clutter added by these extra items. ============================================================================ #(@)editor: The Hacking Editor by Jim Brain (brain@mail.msen.com) Two new faces appear in this month's Commodore Hacking. One is its new editor, while the other is its new look. I hope neither causes anyone to worry about the content of the magazine. It's all still here. C=Hacking will continue to provide leading edge technical information about the Commodore computers we all know and love. The magazine will continue to cater to the Commodore computer programmer, whether it be in the areas of sound, graphics, algorithms, disk media access, or communications. However, the role of the magazine continues to expand. It has been shown that many people other than CBM programmers read the magazine, and programmers have requested other information besides technical content be included in the magazine. To this end, Issue 11 contains many new features, including: o "Hacking the Mags" (Reference: mags), which will summarize the other Commodore magazines in the market place. Not everyone can read or subscribe to all the quality CBM publications out there, so this column will alert readers to specific issues that may be of interest. o "Newsfront" (Reference: news), which will bring the Commodore programmer and user up to date on developments in the Commodore community. The Commodore world doesn't stand still, and every programmer should be aware of the newest technologies affecting the CBM line. o "The Error Channel" (Reference: error), which will formalize the process of fixing errors in earlier issues. Hopefully, this will be unnecessary in most issues, but it will be here just in case. o "Input/Output" (Reference: io), which will allow C=Hacking readers space for comments and concerns. Many readers have sent me suggestions and comments, some C=Hacking can implement, and some C=Hacking cannot. This spot will detail which is which and why. o Article separators. As you can see above, each article or column in the magazine is delimited by the special key, followed by a short name of the article. See "Reading C=Hacking" (Reference: rch) in this issue. o Smaller size. The last issue was over 400kB in size, which generated many complaints. There is no need to create such a long issue, when more issues can be published. This issue should comfortably fit on two sides of a 1541 disk, a 1571 disk, or a 1581 disk. o Stable publication dates. Circumstances (college, job hunt), made it hard for the previous editor to maintain a schedule, so no blame is laid, but the magazine does need some stability. Although possibly unrealistic, I am striving to publish C=Hacking quarterly, with the following schedule: Publication Date Submission Deadline March, 1996 February 10, 1996 June, 1996 May 10, 1996 September, 1996 Auguest 10, 1996 December 1996 November 10, 1996 If article submissions keep up, a switch to bi-monthly publication might be warranted, but I won't get too far ahead. o Fully HTML-ized version of the magazine. Issue 11 contains many improvements designed to make the publication of an World Wide Web readable version of the magazine easier. Look for the HTML version of this and older issues at URL: http://www.msen.com/~brain/chacking/. Many people have compared Commodore Hacking to the defunct _Transactor_ magazine, which is encouraging. The new format will hopefully add to the appeal of Commodore Hacking. Although many of you know me or of me through previous Commodore work, this is my first editorship, so please comment on the changes I have made and what your opinions on each are. As the magazine is for you, the reader, it is always important to keep the reader happy. Sadly, some things, like the WWW browser for C=Hacking, did not get done, but there is always next time. Enjoy YOUR magazine, Jim Brain (brain@mail.msen.com) editor ============================================================================ #(@)io: Input/Ouput Obviously, Commodore Hacking depends on the comments and article submissions from the Commodore community to flourish. Everyone sees the articles, but let's not forget those comments. They are very helpful, and every attempt is made to address concerns in them. Address any comments, concerns, or suggestions to: Commodore Hacking 602 N. Lemen Fenton, MI 48430 brain@mail.msen.com (Internet) #(A)c: Need Samples of Samples From: "Clifford \"Paska\" Anderson" <andersoc@saturn.uaamath.alaska.edu> Dear C=Hacking, Hey. Just writing to mention something I'd like to see in C=Hacking, if you can find someone to write about it. I am interested in knowing more about how samples work on the 64, how to play, etc. ----- _ _ _ Si vales, valeo #(A)r: Your wish is granted. Check out this issue's Hi Tech Trickery (Reference: trick) by George Taylor for some insight into playing samples. #(A)c: You Index, I Index, We all Index From: coyote@wakko.gil.net Dear C=Hacking, I would like to offer an idea for the Chacking mag. Every now and then I'll come across a reference to an article in this or that Chacking Issue. I run Zed and load that issue in (Thanks Mr Bruce) and start hunting for the start of the article. This process would be made a lot easier if Chacking used a method of indexing I have seen used in several publications. It involves the search function of most text editors. A 2/3/4 ? letter code (with a delimiter char to prevent unintentional matches) that the reader uses to find the beginning of the article. (Outline of suggestion deleted) I would like to add a personal thanks for all your efforts on behalf of the C= community. Al Anger 13841 SW 139 Ct. Miami Fl. 33186 (305) 233-4689 #(A)r: Fire up that search function in your favorite editor. Issue 11 now contains the QuickFind indexing system that should fit your needs. See "Reading C=Hacking" (Reference: rch) for information on how to utilize the indexing system. We would like to add that C=Hacking appreciates your personal thanks. #(A)c: Are We Talking the Same Language? From: Jack Vander White <ceejack@crl.com> Dear C=Hacking, Noticed something that may be a potential problem and thought I would let you know. Way back when hacking mag started I didn't have Internet access. the first couple of issues were sent to me by fellows who had downloaded them and in downloading had set their terms to translate them to PETSCII. This of course changed the coding in the uuencoding parts of the magazine and made them decode improperly. Since then I have my own access and have re-downloaded them and posted them on my BBS in the original straight ASCII so that those who download them can uudecode the relevant parts and then translate the text for reading. Since different Terminal Programs are using different Translation tables I can see all kinds of problems in this for the average user. Any comment???? Jack VW #(A)r: The HTML version of Commodore Hacking utilizes the ISO-8859-1 text encoding standard, while the text version utilizes its 7-bit subset, commonly called ASCII. Normally, the encoding standard poses little problem, as text uses but a nominal set of characters which can be translated between PETSCII and ASCII. However, as you point out, the uucode format uses more characters, which may or may not be translated correctly. To circumvent this problem, which only occurs in the text version, the files embedded in a Commodore Hacking issue should be uudecoded prior to converting the file to anoy alternate format. ============================================================================ #(@)news: Newsfront * Although not new news, Some still may not know that Creative Micro Designs, Inc., is currently designing the Super64CPU accelerator. This external 3" tall by 6" wide by 2" deep cartridge will allow Commodore computers to execute programs at either 10MHz or 20MHz (actually, 9 and 18 MHz, realistically). The unit uses the Western Design Center's 65C816S CPU, which is object code compatible with the 6502/6510/8502. The CPU, used in the Super Nintendo Entertainment System as well as other products, can be switched between 6502 emulation mode and "native" mode, which allows the following: o access to 16 MB of RAM without bank switching. o 64kB stack. o 64kB zero page (now called "direct access"). o 16 bit registers. o Support for virtual memory systems. The unit is scheduled for production in February, 1996, and will cost ~US$149.00 for the 10MHz unit and US$199.00 for the 20MHz unit. * The following information was relayed to the USENET newsgroup comp.sys.cbm by Jack Vanderhite, editor and publisher of COMMODORE CEE disk magazine: Rather than reply to all the messages asking about DIEHARD I will tell all what has been happening over the last few days. Brian Crosthwaite, Publisher of Diehard, contacted CMD, Loadstar, and Commodore CEE this week with the following form letter faxed to each of us: ----------- Diehard, the Flyer for commodore 8bitters is planning to cease publication and we are looking to transfer our subscription fulfillment. Our number of outstanding subscribers is approximately 8,400 and I would be willing to throw in the balance of the list, totaling approximately 12,000. Please call me at (xxx)xxx-xxxx if you are interested in acquiring these readers and names. Sincerely, Brian L. Crosthwaite Publisher ---------- Each of us did contact Brian for further details. They are bleak. The total number of paper issues due to subscribers is approximately 64,000. This does not count the approximately 1,200 spinner subscribers which would make approximately 10,000 disks due. The cost of publishing alone would amount to approximately $100,000 for printing, layout, disks, ,mail cost, etc. Not taking into account the cost of articles, etc. when asked about money Brian's only comment was "There is none. It's gone." a further complication is that Tom Netsel told me last week that General Media says that Brian has assumed the obligation to deliver the balance of the Gazette subscriptions. I questioned Brian about this. Brian says that general media faxed him the terms of transference of the obligation and that he faxed back an acceptance of the terms. While I have not seen the actual faxes involved it does sound like offer and acceptance of a binding contract from here. Obviously, all of us have rejected this offer. I have been told that there is an issue of Diehard at the printers, probably printed. However, the printing bill alone is over $8,000 plus the cost of mailing. Since there is no money it sits there. If anyone were willing to assume the total obligations they would have to assume a liability of well over $100,000 over the next year before any returns from renewals would even make a dent in this huge obligation. Please Note: I am putting this out as a public message. This is ALL I know. Please do not come back at me asking questions. I have nothing more I can add to this. Jack VW So, if you have outstanding issues of dieHard due you, as the editor does, the fears have been confirmed. However, for those who purchased the dieHard "Spinner" disk, read on for the encouraging news. * The LOADSTAR disk magazine has been recently purchased from Softdisk Publishing by LOADSTAR principles Fender Tucker and Julie Mangham. Now owned by J and F Publishing, a corporation founded by Mr. Tucker and Mrs. Mangham, provide the magazine with even more flexibility Tucker states that now LOADSTAR is "more solvent then ever before". Existing subscribers will see no difference with this change, as Softdisk and LOADSTAR will continue to maintain a close relationship, with Softdisk continuing to handle subscriptions, in addition to other tasks. In related news, J and F Publishing has agreed to fulfill the remainder of the outstading dieHard "Spinner" subscriptions. Although unfortunate that dieHard left its subscribers out in the cold, it is commendable that these subscriptions will be fulfilled with LOADSTAR issues. The agreement will provide one issue of LOADSTAR for every two issues of the Spinner, as the Spinner was a single disk, whereas LOADSTAR is double that. No word has been heard yet on the fate of dieHard paper subscriptions. All 1200 Spinner subscribers should be receiving information about the subscription fulfillment soon. * For those people wishing to use the Internet with their Commodore 64, only to find out that the local Internet Service Provider (ISP) only provides Serial Line Internet Protocol (SLIP) service with no shell account service, help is coming. A prototype Transmissions Control Protocol/Internet Protocol (TCP/IP) protocol stack with SLIP support has been developed by Daniel Dallmann (Daniel.Dallmann@studbox.rus.uni-stuttgart.de) of Germany. Available now via the Internet (ftp://131.188.190.131:/pub/c64), the package is by no means complete, but does include the basic TCP/IP stack, the SLIP driver, and a rudimentary Telnet application. * Another Commodore hardware/software supplier has announced its online presence: Performance Peripherals Incorporated. Maker of the RAMDrive and BB units (BBGRAM, BBRTC, and BBGRam), PPI published an online catalog that users can retrieve via the C=Hacking WWW Site (http://www.msen.com/~brain/pub/PPI_catalog.11.95.txt) and the C=Hacking MAILSERV server. (send PPI_catalog.11.95.txt). In addition to importing FLASH8 (the 8MHz accelerator cartridge from Germany), PPI manufactures CommPort, which is a 6551 UART cartridge (ala Swiftlink) which has the basic 6551 functionality with the addition of switch selectable NMI or IRQ interrupt triggering and switch-selectable $de00/$df00 addressing. * PPI has one more trick up its sleeve. PPI will be carrying Novaterm 9.6, the newest version of Nick Rossi's oft-used terminal program for the C64. The blurb follows: Novaterm 9.6 is a complete terminal emulation program on cartridge for the C64. Novaterm has several features such as 80 column ANSI on a stock C64, and compatibility with CommPort, RAMDrive, BBGRam, and many other hardware devices. Just connect a BBGRam, and Novaterm can use it as a "buffer" for storing text or as a "virtual disk" for quickly and easily downloading files. Definately the perfect setup for Internet usage. And since Novaterm is in cartridge form, the program loads in seconds, not minutes. Novaterm 9.6 is the latest version programmed by NICK ROSSI. Includes autoboot switch. ============================================================================ #(@)trick: Hi Tech Trickery: Sample Dither by George Taylor (yurik@io.org) #(A): Introduction You may know of dithering in graphics. It is when a limited number of colors are used to simulate more. This is done by randomly arranging the pixels so they blend at a distance, creating an average of the shades. Here, screen space is being averaged, and more shades are being produced. In playing samples, time is being averaged, and more bits are being produced. #(A): Dithering Sound Let's say we do the following: lda #8 sta $d418 This code toggles the low bit of the output. lda #9 sta $d418 Over an average of time, this is the same as: lda #8.5 But we can't really do this. sta $d418 This idea can be used to easily do 5 bit sound. Basically, we take a 5 bit sample, shift right, then add 0. If bit 0 was high, it will increment the 4 bit number. Then as this adding takes place, toggling bit 0, it will average out to give half a bit. #(A): Is There a Catch? There is one drawback though. This toggling can be heard as the high frequency square wave it resembles. You must use a high enough sample rate so this can't be heard. Also it takes two bit toggles to create the 5th bit, so you must double the sample rate. In order to play 8.5, for example, you must play 8 and then 9, so the 8 and 9 must take half the normal time, or your sample will play too slow. One other problem is that there is the possibility of overflow. In this case you can use hard clipping on the signal. In other words, the 5 bit sample 31 will be played at 16, so instead play 15. This is actually called pulse width modulation. It is a good example for illustrating sample dithering. For example, you can play TRUE 16 bit sound, even with one bit. To do this, take the 16 bit sample, add a 12 bit random number, then play the high 4 bits of this result. Also remember the clipping problem as mentioned above. @(A): How Is This Like Pulse Width Modulation? The random number range is proportional to the 16 bit sample. If the 16 bit number is high, then it is very likely the 0 bit (toggle bit) is high. It is the random number which allows the toggle bit to change. So now we have 16 bit sound with 16db signal to noise ratio. There are some more advanced technical issues to this. The kind of random number you choose affects the results. You need a triangle density function for perfect linearity (ie., for no distortion). This is the relationship of random numbers in the sequence, and does not affect the probability distribution, which should be equal. The choice of density function is a tradeoff between added noise and linearity. I used pulse density function in my demo, which is non-filtered random numbers, and it's ok but I can still hear some noise pumping. #(A): Conclusion Enjoy the ditherdigi! #(A)5bit: Listing One: 5 bit play routine Memory map: 3: start page of sample 4: end page of sample 5: sample period (remmber to play twice normal speed) fb,fc: pointer to sample start lda 3 sta $fc lda #0 sta $fb ; initialize sample pointer lda #$b sta $d011 ; blank screen for better timing sei ; disable interrupts for better timing play lda ($fb),y lsr sta $d418 ; push sample ldx 5 d dex bne d pha nop adc #0 cmp #$10 beq s1 sta $d418 bpl s s1 nop nop nop s pla ldx 5 d1 dex bne d1 iny bne play inc fc lda fc cmp 4 bne play lda #$1b sta $d011 cli end rts #(A): References Consult the proceedings of the ACM for further info on digi dithering. ============================================================================ #(@)mags: 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...) Thus, let's spotlight some good and/or technical reading from the other Commodore publications. If you know of a magazine that you would like to see summarized here, let C=Hacking know about it. These summaries are only limited by Commodore Hacking's inability to purchase subscriptions to all the Commodore publications available. We are very grateful to those publications that send complimentary copies of their publications for review. #(A): COMMODORE CEE Volume 1, Issues 1 and 2 came all packaged as one "mega-issue". This particular double issue should be renamed the memory map issue, with I/O and/or memory maps for the VIC, 64, 128, and PET computers. Information on 6522 bugs and on the 6526 CIA chips that was cut from the final compilation of the Commodore 64 Prorammer's Reference Guide is of interest to Commodore Haking readers. Some of the information is culled from the Internet: the 64 memory maps, the info on the 6522, and a list of all the CSG produced IC numbers with descriptions. Of course, these files are also available on the Internet, if you have access. Howver, for those who don't know where to look or for those without access, the information is welcome. Issue 3 has a PCX to GEOPaint converter, much like _LOADSTAR_, and Issue 4 will begin a column on PAL to NTSC program conversions. One thing we'd like to see at Commodore Hacking is a better menu program, as the current one is somewhat hard to navigate. #(A): Commodore World Issue 10 just arrived at the computer room, with a snazzy front cover. Slick paper aside, the picture of Al Anger's Tower 128 was a masterpiece. Editor Doug Cotton spews about the hype of Windows 95, and the first ads for the Super 64 CPU accelerator are present. If you're into hardware mods, you can't miss page 4, which shows some other Al Anger hacked Commodore creations. Jim Butterfield's 4 page 65XX ML reference is useful for the newer programmers, and Doug Cotton's Assembly Line topic of serial routines will help those disk I/O challenged in the crowd. This issue details the high level routines, while #11 will tackle the low level disk I/O. Maurice Randall goes over event handling in GEOS, while Al Anger details how to disable the internal 1571D in the C128D. Gaelyne Moranec touches on the Internet nitty-gritty of learning UNIX commands and includes a table of UNIX-like commands found in ACE and LUnix. At the end, though, C=Hacking's burning question is: What hangup does Doug have with those abstract graphics sprinkled throughout the mag? There's nothing wrong with them, but some look like those psycho-analyst inkblot test cards. #(A): Driven Driven 9 contains a rundown on USENET (written by Jim Brain), which will help those Internet "newbies". For those doing cross development, the review of the PC<->C64/C128 networking system called 64NET by Paul Gardner- Stephen might help some get object code from the PC to the 64/128. Eddie Bourdon has some info on GEnie, including what Commodore support is available. Driven 10 presents some useful WWW addresses, while XMikeX and Pegasus tackle the issues of apathy and pessimism in the Commodore community. Both make for good reading, but the best (in our opinion) was the pessimism piece. How many times have YOU been laughed out of CompUSA for mentioning that modem or SCSI drive was for a Commodore? #(A): LOADSTAR Issue 138 just finished loading on the 1581 disk drive, and the disk is packed with information. Fender Tucker goes into much detail on the recent changes at LOADSTAR and its new Publishing company, J and F Publishing. Of interest to programmers is the PCX to GEOPaint converter program, written by Fender Tucker and Doreen Horne. Some details on Al Angers machines that are shown in Commodore World are related. Jeff Jones presents a simple program pause routine, which fiddles with the NMI interrupt, and gives out source code as well. The Internet 101 series takes a month off from the LOADSTAR letter in #28, but is expected back next month. Lastly, Dave Moorman presents his fractal generator called FRACTAL MOUNTAINS. C=Hacking couldn't get it to work, but we think it's user error. #(A): LOADSTAR 128 In Issue 29, Fender apologizes for not paying enough attention to the 800 LOADSTAR 128 subscribers. Of interest to programmers is the program listing pause program on the issue, but the rest is pretty light stuff, not to knock LOADSTAR. Different audiences need different material. #(A): Vision In Issue 7, Rick Mosdell has an article on graphics formats, updated and reproduced in this issue (Reference: gfx). There is some information from USENET reproduced, and a list of FTP sites as posted to USENET is also presented. Not much technical content in here, but C=Hacking was impressed with the graphics, music, and stories in the mag. Besides, everyone needs some time to enjoy the machine. Other magazines not covered in this rundown include _The Underground_, _Gatekeeper_, _Commodore Network_, _64'er_, _Atta Bitar_ (_8 bitter_), as well as those 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. ============================================================================ #(@)dbldma: Speed up RAMLink transfers with the Double-DMA Technique by Doug Cotton (cmd-doug@genie.com) and Mark Fellows #(A): Introduction When CMD designed the RAMLink, we tried to make the system as fast as possible, but costs and complexity prohibited us from duplicating the operation of the DMA operation found in the Commodore RAM Expansion Unit (REU), The 8726 DMA controller found in the REU is a very complex item that allows the REU to transfer one byte per 1 MHz CPU clock cycle (1 microsecond). On the other hand, the RAMLink uses the 6510/8502 CPU load and store operations to transfer memory from the RAMLink memory to main memory. For the user who uses RL-DOS and RAMDOS, the difference is not noticeable, because although the RAMLink transfer is slower, RAMDOS continually pages its code in and out of main memory, effectively slowing its effective transfer speed down significantly. But, what if the programmer isn't using RAMDOS? Then, the speed of the RAMLink becomes an issue. The RAMLink takes about 8 cycles to perform a transfer of a byte, while the REU does it in 1. This is significant. However, if a user owns both a RAMLink and an REU, there is a way to boost the transfer rate of the RAMLink via software. The method is called Double-DMA. #(A): Double-DMA Description Basically, the process is quite simple. Since the REU has the ability to transfe memory at 1 byte/microsecond, you can use the REU DMA to transfer memory from the RAMLink to main memory. To understand how we can do this, remember that the normal RL-DOS transfer routines use the CPU to perform the memory transfer. Well, to do that, at least some of the RAMLink RAM must be mapped into main memory. To be exact, 256 bytes is mapped in. So, to utilize the Double-DMA technique, the programmer simply makes the appropriate 256 bytes of RAMLink memory to be transferred visible in the main memory map, uses the REU to transfer that 256 bytes to the REU, and then uses the REU to transfer the 256 bytes in the REU to its destination in the main memory map. Thus, the Double-DMA technique will allow the RAMLink to transfer data at rouyghly 1/2 the speed of the REU, or 3-4 times faster than using the CPU to perform transfers. #(A): The RAMLink memory map To achieve this transfer speed gain, the programmer must forego RL-DOS usage and write specialized transfer routines. To do that, we need to discuss how the RAMLink maps itself into main memory and detail the various RAMLink registers needed to make this feat possible: Address Description ------- ----------- $de00 256 bytes of data (See $dfc0-$dfc3 for more information) $df7e write to this location to activate the RAMLink hardware $df7f write to this location to deactivate the RAMLink hardware. $dfa0 lo byte of requested RAMCard memory page $dfa1 hi byte of requested RAMCard memory page $dfc0 write to this location to show RL variable RAM at $de00 (default) $dfc1 write to this location to show RAMCard memory at $de00 $dfc2 write to this location to show the RAM Port device $de00 page at $de00 $dfc0 write to this location to show Pass-Thru Port dev. $de00 page at $de00 For all locations that have the description "write to this address...", the program can safely write any byte to those locations, as the RAMLink hardware simply waits for an access, not any particular byte to be written. #(A): Order of Operations Although the Double-DMA technique relies on use of the REU, it is beyond the scope of this article to detail how to access the REU RAM under programmatic control. For more information on transferring data from the Commodore 128/64 and the 17XX REU, refer to the back of a REU owner's manual. The following steps will realize the Double-DMA method: Notes: P = PAGE in RAMCard RAM to be transferred to/from A = PAGE of RAM in main memory to be transferred to/from X = single page of memory in REU used as temp RAM 1) if computer = 128, set up correct RAM bank 2) make I/O visible in main memory 3) sei 4) sta $df7e - activate RAMLink 5) lda #<P 6) sta $dfa0 7) lda #>P 8) sta $dfa1 9) sta $dfc1 - make $de00 show PAGE of RAM on RAMCard Now, with the RAMLink hardware enabled in this way, the REU registers are also visible, so one can do a double DMA transfer at this point. There are two choices: Transfer A->P: 10) set up REU for A->X transfer 11) initiate REU DMA transfer 12) set up REU for X->$de00 transfer 13) initiate REU DMA transfer Transfer P->A 10) set up REU for X->$de00 transfer 11) initiate REU DMA transfer 12) set up REU for A->X transfer 13) initiate REU DMA transfer Now, to go on: 14) If more byte need transferrring, A=A+1, P=P+1, goto 5 15) sta $dfc1 - restore contents of $de00 15) sta $df7f - deactivate RAMLink hardware 16) if computer = 128, restore bank 17) restore I/O visibility if needed 18) cli #(A): Address Translation To effectively use the Double-DMA technique, a programmer will want to set up a DACC partition in the RAMLink for use as external RAM. The programmer will need to determine the start address of the partition with the RL-DOS G-P command (or its sister command, G-[shift]P) This command will return the address of the DACC partition, or will it? The answer is: Maybe. If a user has inserted an REU into the RAMLink RAM port and has the Normal/Direct swittch set to Normal, RL-DOS uses REU memory as the lowest RAM in the RAMLink memory map. However, when directly accessing the RAMLink and bypassing RL-DOS, the REU is not mapped into the RAMLink memory map. So, for such a condition, the code that determines the start of the DACC partition must SUBTRACT the size of the REU from the address returned by the G-P command. It's non-utopian, but the program need only do this once. However, for such an REU configuration, one must take care to ensure that at least 256 bytes of REU RAM is available and not already in use before utilizing the Double-DMA technique. #(A): Performance Craig Bruce, who has implemented this technique in his ACE operating system, provides the following performance figures for different access techniques: Type Bandwidth Latency Notes (bytes/sec) (~usec) ------------- --------- ------- ----- REU 1,007,641 65.8 REU in Direct mode REU thru RL 1,007,641 77.8 REU in RAM Port in Normal mode RAMLink 105,792 199.2 Regular RAMLink access RL with REU 372,827 319.8 Double-DMA Internal RAM0 120,181 44.2 Zero-page Internal RAM1 80,283 56.3 All main memory except zero-page So, using this technique in ACE results in a 3.7x increase in transfer speed. For some applications, that is well worth the trouble. #(A): Conclusion Obviously, CMD recommends that the RL-DOS be used for most operations, but we realize that some programmers simply need faster transfer rates. The Double-DMA technique should provide the speed needed from the RAMLink. Obviously, since this technique bypasses RL-DOS, code using it can potentially corrupt RAMLink memory if errors occur or if the technique is improperly used. When using the technique, we recommend extensive testing using various DACC partitions and different REU configurations to ensure proper operation. #(A)ddcode: Double-DMA Code Following is a set of functions that will perform transfers using Double-DMA. They are copied from the routines used in Craig Bruce's ACE operating system, Release 14, which incorporates the Double-DMA method. We thank Craig for the code below: ; Name: Double-DMA memory transfer ; Author: Craig Bruce ; Date: 1995-12-4 ; Description: The following routines use the Double-DMA technique to transfer ; memory to/from main RAM and the RAMLink. If no RL is present, ; normal CPU transfer methods are utilized. ; ; Variables: [mp] holds the address of RAMCard memory to transfer ; ramlinkNearPtr hold the address of main memory to transfer ; ramlinkLength is length of data to transfer ; ramlinkOpcode = $90: main memory -> RL ; = $91: RL -> main memory reu = $df00 rlActivate = $df7e rlDeactivate = $df7f rlSram = $dfc0 rlPageSelect = $dfa0 rlPageActivate = $dfc1 rlPageData = $de00 ramlinkOpcode .buf 1 ramlinkLength .buf 2 ramlinkNearPtr .buf 2 ramlinkMpSave .buf 3 ramlinkZpSave .buf 2 ramlinkOp = * ;( [mp]=farPtr, ramlinkNearPtr, ramlinkLength, ramlinkOpcode ) lda mp+0 ldy mp+1 ldx mp+2 sta ramlinkMpSave+0 sty ramlinkMpSave+1 stx ramlinkMpSave+2 lda zp+0 ldy zp+1 sta ramlinkZpSave+0 sty ramlinkZpSave+1 lda ramlinkNearPtr+0 ldy ramlinkNearPtr+1 sta zp+0 sty zp+1 clc lda mp+1 adc aceRamlinkStart+0 sta mp+1 lda mp+2 adc aceRamlinkStart+1 sta mp+2 - lda ramlinkLength+0 ora ramlinkLength+1 beq + jsr rlTransferChunk jmp - + lda ramlinkMpSave+0 ldy ramlinkMpSave+1 ldx ramlinkMpSave+2 sta mp+0 sty mp+1 stx mp+2 lda ramlinkZpSave+0 ldy ramlinkZpSave+1 sta zp+0 sty zp+1 clc rts rlTrSize .buf 1 rlTransferChunk = * ;( [mp]=rlmem, (zp)=nearmem, rlLength, rlOpcode ) ;** figure maximum page operation lda ramlinkLength+1 beq + lda #0 ldx mp+0 beq rlTrDo sec sbc mp+0 jmp rlTrDo + lda mp+0 beq + lda #0 sec sbc mp+0 cmp ramlinkLength+0 bcc rlTrDo + lda ramlinkLength+0 ;** do the transfer rlTrDo = * tay sty rlTrSize jsr rlPageOp ;** update the pointers and remaining length clc lda rlTrSize bne + inc mp+1 inc zp+1 dec ramlinkLength+1 rts + adc mp+0 sta mp+0 bcc + inc mp+1 + clc lda zp+0 adc rlTrSize sta zp+0 bcc + inc zp+1 + sec lda ramlinkLength+0 sbc rlTrSize sta ramlinkLength+0 bcs + dec ramlinkLength+1 + rts rlPageOp = * ;( [mp]=rlmem, (zp)=nearmem, .Y=bytes, ramlinkOpcode ) php sei sta rlActivate lda mp+1 sta rlPageSelect+0 lda mp+2 sta rlPageSelect+1 sta rlPageActivate lda aceReuRlSpeedPage+3 bne rlPageOpReu ;xxx dependency on aceMemNull==0 rlPageOpNonReu = * tya clc adc mp+0 tax lda ramlinkOpcode cmp #$91 bne rlPageOpWrite dex dey beq + - lda rlPageData,x sta (zp),y dex dey bne - + lda rlPageData,x sta (zp),y jmp rlPageOpContinue rlPageOpWrite = * dex dey beq + - lda (zp),y sta rlPageData,x dex dey bne - + lda (zp),y sta rlPageData,x rlPageOpContinue = * sta rlSram sta rlDeactivate plp rts rlPageOpReu = * ;( [mp]=rlmem, (zp)=nearmem, .Y=bytes, ramlinkOpcode ) ;** ramlink hardware already switched in ldx #1 tya beq + ldx #0 cmp #0 ;xx cut-off value bcc rlPageOpNonReu + ldy ramlinkOpcode cpy #$90 beq + ldy #$90 ;rl->reu->intern jsr rlPageOpReuRl ldy #$91 jsr rlPageOpReuIntern jmp ++ + ldy #$90 ;intern->reu->rl jsr rlPageOpReuIntern ldy #$91 jsr rlPageOpReuRl + sta rlSram sta rlDeactivate plp rts rlPageOpReuIntern = * ;( .AX=bytes, .Y=op ) sta reu+7 ;len stx reu+8 sty temp1 pha lda zp+0 ldy zp+1 sta reu+2 sty reu+3 lda aceReuRlSpeedPage+0 ldy aceReuRlSpeedPage+1 sta reu+4 sty reu+5 lda aceReuRlSpeedPage+2 sta reu+6 .if computer-64 ldy vic+$30 lda #0 sta vic+$30 .ife lda temp1 sta reu+1 .if computer-64 sty vic+$30 .ife pla rts rlPageOpReuRl = * ;( .AX=bytes, .Y=op ) sta reu+7 ;len stx reu+8 sty temp1 pha lda mp+0 ldy #>rlPageData sta reu+2 sty reu+3 lda aceReuRlSpeedPage+0 ldy aceReuRlSpeedPage+1 sta reu+4 sty reu+5 lda aceReuRlSpeedPage+2 sta reu+6 .if computer-64 ldy vic+$30 lda #0 sta vic+$30 .ife lda temp1 sta reu+1 .if computer-64 sty vic+$30 .ife pla rts ============================================================================ #(@)usenet: UseNuggets COMP.SYS.CBM: The breeding ground of programmers and users alike. Let's see what topics are showing up this month: #(A): We Want More Power! CMD's announcement of the Super64 CPU accelerator got things stirred up in the newsgroup. When it was announced that the initial product would run on a C64 or on a C128 in 64 mode only, some angry C128 128 mode users vented all over the place. Everything from people wondering aloud what extra work the 128 version would require to threats of non-purchase of the unit ensued. Then, just as the first wave of fighting subsided, the next wave started, programmers worried about RAM transfer speed bottlenecks questioned CMD's decision not to include a DMA device on the unit to speed data transfers. CMD's response: From: Doug Cotton <cmd-doug@genie.geis.com> Newsgroups: comp.sys.cbm Subject: Re: Power Users! Date: 28 Nov 1995 00:59:26 GMT Organization: Creative Micro Designs, Inc. There were some earlier questions about how fast memory transfers could be accomplished with the accelerator, and at least one individual emailed me over the lack of a DMA controller. I obtained some figures from Mark concerning this. Presently, the DMA transfers using an REU transfers a byte in 1 microsecond. The accelerator can achieve this same speed when transferring data from either on-board static RAM, or from expansion memory (slower DRAM) to the host computer RAM. Transfers internally (from static RAM to static RAM) will take .35 microseconds per byte (350 nanoseconds). Transfers from RAMLink RAMCard RAM (direct style) to the host computer RAM will take about 2 microseconds per byte. The only figures I don't have yet are for transfers between on-board static RAM and expansion DRAM, but this will be governed by the speed of the DRAM itself, and the number of wait-states required. It definately will be faster than 1 byte per microsecond though. So the only thing slower than a current DMA operation is transferring to and from RAMLink RAMCard memory, which is still pretty impressive at half the speed of present DMA transfers. Given these speeds, the cost of high-speed DMA controllers ($$$$), and a real lack of anywhere to put one on the main board, I think going without a DMA controller is reasonable. If you really want one, though, there's always the high-speed expansion port, and a do-it-yourself project. Doug Cotton Notice the tiny "high speed expansion port" mention at the end. Reports indicate that such a port or ports will definitely appear on the unit, but it is still undetermined whether a single connector or a small expansion bus will be utilized. Commodore Hacking recommends the latter, as more options for hardware mods are available. #(A): Let's all design the Commodore 64 Laptop! Yes, the dreamers are at it once again. Starting in late October, the net was abuzz with thoughts on what should be included on a Commodore Laptop. The designs were flying fast and furious, with many different features discussed. It was agreed that the laptop would need to be a power sipper and have an LCD screen and a keyboard. However, that was where agreement ended. Some of following items were bantered about: CPU: o "really fast" 6510 o 65C816S Disk: o FLASH RAM cards. o built in hard drive o low power 1581 or CMD FD2000/4000 RAM o definitely more than 64kB, but disagreement as to how much more. Video o VIC-II compatibility with more modes. o VIC-III as found in Commodore 65 Sound o Built in stereo SIDs o Quad SIDs So, on and on it went. Some got down to the nitty gritty of planning designs for chips. Some wanted to put the SIDs into one chip, while others wanted a SID/VIC/CPU single chip solution. It's December, and the thread is still going strong, but a few great things have surfaced, which is why you can't just discount this type of dreaming: o Someone posted the procedure for modifying the C64 to run on battery power. o A few people started looking into how much money such designing would require. o Most people who thought disk media should be included agreed that the CMD FD drive could/should be used. o Everyone woke up and noticed that the NMOS CPU process used for the fabbibng of the CBM chips was power hungry and ill-suited to battery operation. C=Hacking encourages users to answer the quetion: My dream Commodore laptop computer would include.... Send you entries to Commodore Hacking (brain@mail.msen.com) with the subject "LAPTOP". We'll print the best entries next issue. Everyone seems to think that CMD is going to have one in development before long. Dunno. Commodore Hacking has heard rumors of what is going on at CMD, but we haven't heard about the laptop project. Of course, we're not SPECIAL or anything.... :-) #(A): The Tower of Power It seems Al Anger's (coyote@gil.net) Tower 128 picture on Commodore World's Issue 10 cover got everyone excited. A couple of people were sending Al email about it, Commodore Hacking asked some questions, and some USENETters were deciding how to do it themselves. Al states that $2000 would just about cover it, which turned a few enquiring minds away, we're sure. Still, the reasons given for wanting a tower were solid. Commodore users are getting tired of all the clutter and mess cables, power cords, expansion extenders, Swiftlink cartridges, etc. make in the computer room. C=Hacking notes that at least one manufacturer produces tower 64 systems, but the cost is evidently more than what most folks are willing to fork over (~US$300 - US$550). So, everyone is waiting for the cost to come down.... #(A): Dave Letterman, Eat Your Heart Out! The latest thread is the top ten list of games. Everyone is submitting their 10 most favorite games for the CBM machines. (Is anyone compiling these?) Anyway, it turns out this thread has a nice side effect. People are reminiscing about the old games, and the Commodore users are noting that the new games "just aren't as good". Here, here! So, that wraps up the USENET this time. We try to keep an eye out for stuff of interest, but drop us a line if you think we might miss an IMPORTANT topic... ============================================================================ #(@)toolbox: The Graphics Toolbox: Ellipses by Stephen L. Judd (sjudd@nwu.edu) #(A): Introduction After a much needed break from Commodore 64 programming, I thought it would be nice to construct another algorithm for the 2D graphics toolbox. Since we did circles last time, a natural successor would be an algorithm to draw eclipses. We will first review the circle algorithm, and then build upon it to draw eclipses. You may recall that the algorithm had problems with small-radius circles. There is a very easy way to fix this, so we will cover that issue as well. #(A): Circles Recall that the equation for a circle is x^2 + y^2 = r^2 After taking differentials of both sides, we find that dy = -x/y dx That is, if we take a step of size dx in the x-direction, we in principle want to take a step of size dy in the y-direction. Next we start at the top of the circle, so that y=r and x=0. We start increasing x in step sizes of one. We only care about step sizes of one, since our basic unit is now a pixel. The y-coordinate is going to start piling up these dy's, and at some point the integer part of y will increase, and we get a new y-coordinate for the pixel. The idea, then, is to keep adding the dy's together, and once their sum is greater than one, we decrease y (remember that y starts at the top of the circle). The sneaky way to do this is to treat y as an integer "constant". Then it is very easy to add the dy's together, since they have a common denominator equal to y. So really all we need to do is start adding x-coordinates together, and once their sum is larger than y, we decrease y and hang on to the remaining fractional part of dy. The algorithm then looks like: y=r x=0 a=r loop: x=x+1 a=a-r if a<=0 then a=a+y:y=y-1 plot (x,y) if x<y then loop: Now, Chris McBride pointed something out to me. As you may recall, the algorithm breaks down for small r. Chris said that if a is initially set to r/2 instead of r, the algorithm works perfectly. Why is that? Recall that we add dy to itself until it is greater than one. Wouldn't it make more sense to add dy to itself until it is greater than 0.5? That would have the effect of rounding things up. Thus, starting at r/2 is like adding 0.5 to the fractional part of y -- it is the difference between INT(y) and INT(y+0.5). Thus, the above line a=r should be changed to a=r/2 for a perfect circle every time. Thus, this corresponds to adding an LSR to the machine code. Incidentally, this fix appeared in an earlier C=Hacking, but it was placed in such a crazy place that you probably never saw it. #(A): Ellipses, HO! Now we can move on to eclipses. Since ellipses are simply a squashed circle, it seems reasonable that we could modify the above circle algorithm. So, let's get to it! Everyone knows the equation of an eclipse: x^2/a^2 + y^2/b^2 = 1 Upon taking differentials of both sides we have, 2*x*dx/a^2 + 2*y*dy/b^2 = 0 or, equivalently, dy = -b^2/a^2 * x/y * dx As you can see, life becomes suddenly becomes more complicated by a factor of b^2/a^2. Furthermore, with an eclipse we only have reflection symmetries through the x- and y-axis. In the circle algorithm we could get away with just drawing an eighth of the circle, but now we have to draw a full quarter of the eclipse. We will start drawing the eclipse at x=0, y=b, so that initially x will increase by one at each step, and y will wait a few steps to increase. At some point, though, we will want y to increase by one at each step, and x to wait a few steps before increasing; in the circle algorithm we just quit once we reached this point, but now we are going to need an equation for dx: dx = -a^2/b^2 * y/x * dy In the circle algorithm, we used a single variable to count up and tell us when it was time to increase y. Perhaps your intuition suggests that we can do an eclipse with _two_ variables; mine said the same thing, so that is exactly what we will do. First, let us assume we have a way of calculating b^2/a^2: E = b^2/a^2 I will suggest a way to perform this calculation later. Let's write out the first few terms in the dy summation, starting at x=0, y=b: dy1 + dy2 + ... = -E * (x0 + x1 + x2 + x3 + ...)/y = -E * (0 + 1 + 2 + 3 + ...)/b = - (0 + E + 2E + 3E + ...)/b So, the basic structure of the algorithm is: add up 0, E, 2E, etc. until the sum is larger than y. At that point, reset the counter, keeping the remainder, and decrease y. This is where the two variables come in: X=X+1 T2=T2+E T1=T1+T2 IF T1>=Y THEN T1=T1-Y:Y=Y-1 Do you see how it works? T2 simply takes on the values 0, E, 2E, 3E, etc., and T1 is the counter. Furthermore, you can see that once T2 is larger than Y, dy will be larger than one at each step. We need a new algorithm to continue the calculation, and it turns out to be quite simple. Look at the expression for dx above. We could calculate a^2/b^2, but somehow that goes against the spirit of the calculation so far. Let's instead rewrite dx slightly: dx = - y/(E*x) * dy Here we have simply written a^2/b^2 as 1/(b^2/a^2) = 1/E. But E*x is exactly the variable T2 above, so we can continue the calcuation without even stopping for breath: Y=Y-1 T1=T1+Y IF T1>=T2 THEN T1=T1-T2:X=X+1:T2=T2+E (remember that T1 keeps track of the fractional part of y). So, we now have a complete algorithm for drawing an eclipse: 0 REM ELLIPSE ATTEMPT #N SLJ 11/3/95 10 A=150:B=16:E=B*B/(A*A) 20 X=0:Y=B:T1=0:T2=0.5 30 GRAPHIC1,1:SLOW:X0=160:Y0=100:DRAW1,X0+A,Y0:DRAW1,X0,Y0-B 40 X=X+1:T2=T2+E 50 T1=T1+T2 60 IF T1>=Y THEN T1=T1-Y:Y=Y-1 70 DRAW1,X0+X,Y0-Y 80 IF T2<Y THEN 40 90 Y=Y-1 100 T1=T1+Y 110 IF T1>=T2 THEN T1=T1-T2:X=X+1:T2=T2+E 120 DRAW1,X0+X,Y0-Y 130 IF Y>0 THEN 90 Lines 40-80 are the top part of the eclipse, and lines 90-130 handle the bottom part. Note that T2 starts at 0.5, to round off the calculation in the same spirit as we did in the circle algorithm. Naturally, this algorithm has a few limitations. In line 30 the start and end points are plotted, so you can see how close the algorithm really is. In my experiments it occasionally missed the endpoint by a pixel or two. As usual, I was a little too lazy to investigate possible ways to get around this. If you require a perfect eclipse, you need to start the calculation at x=0, y=b and run it forwards (e.g. lines 40-80 above), and then do another, similar calcuation, starting at x=a, y=0, and running backwards. That is, for the second calculation, calculate E2=a^2/b^2, and then run the algorithm just like lines 40-80, interchanging X and Y. Now we need to translate this algorithm into assembly. I am going to make a few assumptions: first, that everything fits in a byte. In particular, I require that b^2/a < 256. This insures that b^2/a^2 < 256, and also insures that T2 will not overflow (note that when x=a, T2=E*a, e.g. T2=b^2/a). What this means is that eclipses can't be too squashed. Next, we need to deal with the fraction E=b^2/a^2. Any number like this consists of two parts, an integer part plus a fractional part (e.g. a number and a decimal). So, let's split E into two parts, EL and EH, where EL represents the decimal part and EH the integer. Now our addition consists of adding together the fractional parts, and if there is an overflow, increasing the integer part. For example, if E=1.62, then EH=1 and EL=0.62. We add EL to our number, and if it is greater than one, we carry the one to when we add EH to our number. The best thing to do is to represent EL as a fractional part of 256. That is, our EL above should really be 0.62*256. This way, carries and overflows will be handled automatically (this will become clear in a moment). Let me give some pseudo-assembly code and we'll push off the explanation until later: 35 GOTO 200 190 REM *********************** 200 XM=0:YM=B:X=128:Y=0:EH%=INT(E):EL%=INT((E-EH%)*256+0.5) 210 XM=XM+1 220 C=0:A=X:A=A+EL%:IF A>255 THEN A=A-256:C=1 230 X=A:A=Y:A=A+EH%+C:Y=A 235 A=A+T1 240 IF A>=YM THEN A=A-YM:YM=YM-1 250 T1=A:DRAW1, X0+XM, Y0-YM 260 IF Y<=YM THEN 210 265 T2=Y:A=T1 270 YM=YM-1 280 A=A+YM:IF A<T2 THEN 300 290 A=A-T2:T1=A:XM=XM+1:A=X:C=0:A=A+EL%:IF A>255 THEN A=A-256:C=1 295 X=A:A=T2:A=A+EH%+C:T2=A:A=T1 300 DRAW1, X0+XM, Y0-YM 310 YM=YM-1:IF YM>=0 THEN 280 XM and YM are the x and y coordinates of the point to be plotted. Note that in line 200 X starts at 128, and this again is to round up all our calculations; compare to line 20, where we started T2 at 0.5. In the above code I store T2 in the X and Y registers for the first part of the code. Note that in lines 220 and 290 there is some extraneous code to simulate things that in assembly are taken care of by the 6502. Note also that the comparison in line 260 has been changed from < to <=. This makes the branch easier, and I'm not sure how it affects the calculation (I didn't notice any difference in the few runs I tried it on). Moving through the code, we increase x, and then add the decimal part of E to the counter. Then we add the integer part of E to the counter, along with any carries. If the integer part of the counter is greater than y, it is time to decrease y and reset the counter. Moving to the second part of the code, we do a little rearranging in line 265. Really a better thing to do would be to let A=T1-T2, so that the compare in line 280 becomes simpler. Anyways, note that the Y register becomes freed up at this point. From here on, it is pretty much the same thing as before. The full assembly code is then: ;Ellipse SLJ 11/3/95 Assumptions: ;0->XM B->YM, x- and y-coordinates ;0->T1 ;EL and EH contain remainder and integer parts of E, resp. LDX #128 LDY #00 CLC L1 INC XM TXA ADC EL TAX TYA ADC EH TAY ADC T1 CMP YM BCC :CONT1 SBC YM DEC YM :CONT1 STA T1 JSR PLOT CPY YM BCC L1 STY T2 LDA T1 SBC T2 DEC YM L2 ADC YM BCC :CONT2 SBC T2 STA T1 INC XM TXA ADC EL TAX LDA T2 ADC EH STA T2 LDA T1 :CONT2 JSR PLOT DEC YM BPL L2 ;Assuming y<128 #(A): Logarithms Finally, we need a way of calculating b^2/a^2. I suggest using logarithms for this. I do believe I discussed this concept in an earlier issue of C=Hacking. Nevertheless, the idea is that if x = b^2/a^2 then log(x) = 2*log(b) - 2*log(a) so that x = exp(2*(log(b) - log(a)) Thus, three tables need to be created: one for log(x), and one each for the integer and remainder parts of e^(2*x). Now, to improve accuracy, the first table might be a table of f(x)=222/log(128) * log(x/2). This constant is chosen so that f(255) is roughly 255. 222 was chosen because the inversion (i.e. the e^x part) works best at that value. This pretty much assumes that x is not zero or one, either. You can of course use more tables for somewhat better accuracy. One really nice thing about this is that you don't have to worry about squaring things, since that part can be taken care of automatically in logarithm space. On the downside, we are restricted even further by the types of numbers we can divide (e.g. log(a)-log(b) can't be larger than 127 or so). Division then consists of a table lookup, subtraction of another table lookup, and two more table lookups. Here is a short program to demonstrate the use of logs in this sort of division, and a very rough feel for the type of accuracy to expect -- note that it doesn't compare decimal parts, or convert the decimal parts into fractions of 256, etc.: 1 FAST:PRINT"[CLR]" 10 DIM L(256),EI(256),ER(256):FC=222/LOG(128) 20 FOR I=1 TO 256 25 PRINT "[HOME]"I 30 L(I)= INT(FC*LOG(I/2)+0.5):IF I=1 THEN L(I)=0 40 S=I:IF I>127 THEN S=I-256 50 EX=EXP(2*S/FC):IF EX>256 THEN PRINT"WHOOPS! EX="EX"I="I 60 EI(I)=INT(EX+0.5) 70 ER(I)=EX-EI(I) 80 NEXT I 90 EI(0)=1:ER(0)=0 100 FOR A=2 TO 250 110 FOR B=2 TO 250 120 X=L(B)-L(A) 123 IF X>127 THEN PRINT"OOPS:A="A"B="B"X="X 126 IF X<0 THEN X=X+256 130 A1=EI(X)+ER(X):A2=B*B/(A*A):IF A2>255 THEN B=600 135 BL=INT(A2+0.5)-INT(A1+0.5) 140 PRINT A;B,A1;A2,"ERR="INT(A2+0.5)-INT(A1+0.5) 150 NEXT:NEXT #(A): Conclusion Sorry, no 3D graphics this time around. Watch for a full-screen, hires bitmapped solid 3D virtual world sometime in the not too distant future. Otherwise, may your ellipses never be square :). ============================================================================ #(@)surf: 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. In early 1994, when the US Commodore WWW Site started, the number of sites online that catered to Commodore numbered in the 10's. Now, the number is in the 100's. What a change. If you know of a site that is not listed here, please feel free to send it to the magazine. The following links have been gleaned from those recently changed or added to the US Commodore WWW Site Links page (http://www.msen.com/~brain/cbmlinks.html). 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://www.escom.nl ESCOM Interactive, Inc. The new home of Commodore has links to many of its offices and some general information. The pages are still under construction, but you should probably save this address. C=Hacking gripe: No Commodore 8-bit inforation yet. o http://www.msen.com/~brain/guest/cmd/ Creative Micro Designs. Stay tuned to this site for information on the accelerator, and keep up to date on the latests prices on CMD peripherals and software. C=Hacking gripe: For a comapny wanting having just announced the Super64CPU, no mention of it is to found anywhere on the WWW site. Bummer. #(A): Publications o http://www.softdisk.com/about/c64.html LOADSTAR and LOADSTAR 128. If you are interested in LOADSTAR, check 'em out here. Some Commodore links are included, and the and a few magazine teasers are present. In addition, details on how to ordr LOADSTAR or any of its related software titles is provided. C=Hacking gripe: the background color. Yellow is hard on our eyes... Oh well. o http://www.mds.mdh.se/~dat95pkn/8bitar/ Atta Bitar (8 Bitter) magazine. Full indexes for the past 3 years, as well as information on how to subscribe. We'd tell you more, but none of us read German (At least we THINK it's German), and the English transmation page isn't done yet. Anyway, if you would like to subscribe or need to search the index of the magazine, here's the place to go. C=H gripe: Yes, we know this is English-centric, but we just wish we could actually read all the great info on this site. #(A): User's Groups o http://www.cucug.org/ Champaign-Urbana Commodore User's Group. Home of the Universtity of Illinois (the editor's alma mater!) Meeting dates and time, along with newsletters and a user group listing are presented. C=H gripe: No mention of what local CBM 8-bit users are doing. This site recently changed addresses, so change all your links... o http://www.psc.edu/~eberger/pcg/ Pittsburgh Commodore Group. Local news, meeting dates and time, and some newsletters are present. This site has also recently relocated to this new address. C=H gripe: Same as for CUCUG. We want to know what the CBM 8-bitters are doing in Pittsburgh. o http://www.slonet.org/~rtrissel/ The Central Coast Commodore User's Group. Those in the Santa Maria CA area will be glad to know that CCCUG is there for them. Past newsletter are available, and some links to other information of interest is present. C=H gripe: Meeting dates and times need to be present in some easy place. C=H plug: It sounds like this club might need a little help, as it is down on members. If you are in the Santa Maria area, consider joining... #(A): Miscellaneous o http://www.byte.com/art/9408/sec14/art1.htm Byte Magazine's Commodore obituary, by Tom Halfhill. Tom spells out many of the things that Commodore DID do right in its lifetime, and reflects on the blunders CBM made. The article makes for very good reading, but will depress some. C=H gripe: The pictures in the real article aren't reproduced in the WWW page. o http://stud1.tuwien.ac.at/~e9426444/geoswarp/index.html GEOS Warp 1.0. For the Mac user who needs or wants to run GEOS, this program, run on a Macintosh, will allow GEOS programs to operate on the Mac. The system looks very impressive, to the point of us not asking, Why? C=H gripe: Not really with the page, but the writer laments that progress is slow owing to no agreement with GEOWorks. Such things may doom the project to failure. o http://vanbc.wimsey.com/~danf/cbm/ Dan Fandrich's WWW Site. For those who develop on alternate platforms or use multiple programming languages with the C64/128, bookmark this page. Very current info, and lots of it is presented. Some defunct Commodore mags are indexed, and pointers are provided to many of the current crop of magazines, including this one. C=H gripe: the page needs a little bit more organization to make it easier to get at juicy info. o http://www.aloha.net/~scatt/commodore.htm Scatt's WWW Site. For those just moving into assembly language programming from BASIC or something else, this page has a beginner's tutorial you might find useful. C=H gripe: A little low on content, but we are glad what there is is available. o http://www.cs.wm.edu/~pbgonz/progc64.html Pete Gonzalez's WWW Site. Small page, but worth viewing. Pete shows some screen shots of a new game he is developing, and offers copies of his in progress cross assembler for the PC. C=H gripe: When's the game coming out again? :-) o http://www.ts.umu.se/~yak/cccc/ The Commodore Computer Cult Corner. Some people play games, and then some people PLAY games. Jonas Hulten has pictures of his game design, implementation, and programming heoes. You can read about each one, and even light a "candle" for them. This site has a CBM links page, which anyone can add their link to automatically. C=H gripe: We can add our home page automatically, but not our hero. o http://www.slonet.org/~jwilbur/ John Wilbur's WWW Site. Basically, just a links page right now, but we'll check back. C=H gripe: We'd like to see a little more about John as it relates to Commodore. o http://www.student.informatik.th-darmstadt.de/~supermjk/ Marc-Jano Knopp's WWW Site. Mainly a large links page for Commodore information, this site does give a glimpse of the never produced Commodore LCD laptop computer. C=H gripe: As above, we love to see a little more about Marc-Jano as it relates to Commodore.