:::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: /S03::$d000:::::::::::::::::::S O F T W A R E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: : Innovation in the 90s : Revisiting The Super Hi-Res Interlace Flexible Line Interpretation Technique by Roland Toegel (Crossbow/Crest), Count Zero/TRC*SCS, and George Taylor (aa601@chebucto.ns.ca) Prelude from George Taylor, technical editor ----------------+--+--+--------------------- Once you have FLI, why not just overlay some sprites on it to make better graphics? A simple idea you may have thought of, but as you will see, implementing the concept was very difficult. There are two key concepts to making it work. The following article is a brilliant piece of work on the subject. It was presented in disC=overy (issue 2) and subsequently raised a great deal of discussion. There are some confusing concepts involved so I have added extra interpretation to the original text as as editorial notes, which I hope will help bridge the gap from foreign language translated text and difficult explanations. Prelude from Count Zero --------+--+--+-------- First seen earlier this year, the new SHIFLI video technique that is described in this article is -the- paramount example of programming brilliance. The inventor of the technique, Roland Toegel (Crossbow of Crest), was helpful in providing the original SHIFLI documentation, which I translated from German into the English text that follows for the exclusive use of the disC=overy journal. So without further ado, let us now learn from Mr. Toegel how to achieve the award winning : 'Super Hires InterLace Flexible Line Interpretation' Graphics mode ! Please note that the technique is described primarily for Commodore computers based on the European/Australian PAL TV standard. NTSC-based Commodore machines require an extra 2 cycles per line to be added to the raster routine. This may require the programmer to time out the routines by hand, but this should not be a major obstacle to overcome. Count Zero -- i. Foreword As the inventor of the SHI-FLI mode, I am pleased to have the services of Count Zero and the disC=overy journal for the dissemination of my technique into the English language. I must add that the text below does require the reader to be already familiar to a high degree with VIC-II programming on the C64. I would suggest books such as 'Mapping the 64' and the programming texts found at ftp.funet.fi/pub/cbm/documents, for a solid base of instruction. Also, some terms used in this document (e.g., mix-color) are meant to be uniquely descriptive and hence, will not be found in any 'standard' programming text. The terminology is a result of the strain that occurs when new methodology meets old semantics. However, the experienced programmer should find the words to be self-evident in the context which they are used. [Mix-color: a new color derived from the original 16 by the process of alternating normal colors at such a high rate of speed that they blend to the eye. Also know as flashcolors. -GT] -- 1. Introduction to Super Hires [Hires FLI: a graphics mode which uses rasters to enable the use of a separate color memory on each line, thus giving 2 colors chosen freely in each 8x1 hires pixel area. Interlace: alternating any two graphics modes to allow the use of mix colors. FLI without the 'hires' modifier usually means the use of the FLI technique with a multicolor mode as the basis. Super Hires FLI might be more aptly named as Sprite Hires FLI, but the super means that sprites are overlayed on top of another graphics mode. -GT] Super-Hires Interlace FLI : The absolute successor of the Super-Hires-Modes. Just like normal Super-Hires, the width is 96 Hires Pixels, which is equal to 12 Characters or 4 Sprites next to each other. For visual enjoyment this area is centered though using Char-Position 15 to 26 inclusive on the screen. The Y-Axis is 167 pixels high having nearly 21 Character lines or 8 Sprites and to have as much flexibility as possible on choosing colors or pixels, 2 layers of sprites in a row of 4 beside each other are used (8 sprites on the rasterline) over the bitmap graphics. Due to the fact that all 8 sprites are used for a 96 * 21 pixel-wide area, a small multiplexer is needed to repeat the 8 layered sprites for 8 times, at 21 pixel intervals as you go dowards on the screen, with each row using their own bitmaps. We thereby win 2 colors plus the 2 normal colors of the Hires-Bitmap Mode in an 8*8 pixel block. Please note that the 2 additional colors are the same throughout the whole picture. 2. Super Hires with FLI !?! FLI is, for most coders, still quite hard. Sprites over FLI, for most, quite impossible. Maybe one or two sprites, but 8 !?! next to each other and still FLI in each rasterline! Hard to believe, eh? First of all you need to know how to do FLI and what it does and also what effect sprites have on it. 2.1 Normal FLI On each eighth rasterline (the Badlines, the first rasterline of each charline) the VIC stops the processor for 40-43 cycles to read the new Characters and colors of the video and color-ram. This is the case when the bits 0-2 of the registers $D011 and $D012 are the same. Now if you change on each rasterline the bits 4-7 of $D018, which holds the length of the video-ram (handling the colors on bitmap graphics) and set the bits 0-2 of $D011 to get a badline on each rasterline, you will get new colors on each rasterline in the bitmap graphics. The only condition to be followed is that on each rasterline 23 cycles are used but for the *used cycles - 22* char of the textline the next 3 chars have the byte $FF (light grey) read from the video ram and the FLI effect starts after that (the FLI bug). In the multicolor mode, for the color-ram the next byte in the program after writing to $D011 is chosen as the color. As we are using the Hires Mode here, this is irrelevant. > NOTE: The last 3 sentences were pretty hard to translate and I advise you > to read other articles about FLI aswell, if you want to know more > about Multicolor FLI. (CZ) 2.2 Sprites over FLI So what does a sprite do over FLI? Pretty simple, as it just eats up some cycles. All 8 sprites use 19 cycles per rasterline, meaning in the case where we code our FLI routine without loops, we just need 2 x (LDA, STA) commands (for $D018 and $D011), using 12 cycles per rasterline. All together with the 8 used sprites that makes 31 cycles. Thus, the 'light grey' FLI-Bug occurs on char-positions 9,10 and 11 and from char 12+, the FLI effect comes up. This doesn't matter much to us, as the Super Hires Picture starts at Char-Pos 15. We therefore get 3 cycles per rasterline for other commands. [The explanation of when the FLI effect starts in 2.1 was unclear. Here we can understand that the effect starts 3 cycles after the write to $d011. The only catch is that this code is delayed by the extra DMA time used by the sprites. Thus the formula (12+19)-22=9 gives the start of the grey pattern, and 9+3=12 is the start of the FLI effect. The constant 22 comes from a measurement of when the CPU continues after DMA is released, relative to the position on the raster line. -GT] 3. Mulitplexing over FLI Now we have to increase the Y-Coordinates of the sprites by 21 pixels each 21 rasterlines and give them new patterns. As we use 8 different video-rams on FLI for the colors and the sprite-pointers are always at the end of the video-ram, we are supposed to write 8 * 8 values for the patterns plus 8 values for the Y-Coordinates, resulting in 72 different addresses. Thats far too much for a single rasterline and adding the FLI routine will bust the limits. Therefore we have to do a little trick. 3.1 Changing the sprite-pointers The trick is not to change anything at all! On the other hand we don't want the patterns to look the same everywhere. Luckily, the height of a sprite (21 pixels) is not capable of being divided by the height of a textline (8) and the smallest mutual multiple is 168 (meaning 21 * 8). As we are writing (due to the FLI) a new value to $D018 on each rasterline and we use 8 video rams, we can abuse this and have different sprite-pointers on every video-ram. The handling of where the graphics for the sprite-patterns are located becomes a little bit confusing, but it doesn't eat up any rastertime as we don't have to change the pointers. [Put another way, we take advantage of the fact that the video matrix location is changing every raster line (and therefore also the sprite pointers at the end of the video matrix), and slice up the sprites so that the bitmap definition is located in a different place in memory for each line of the sprite. This is very confusing, and the graphics are spread throughout memory in essentially random locations to make them fit around the other graphics areas. But at least it is possible to give every part of every sprite a separate bitmap without changing sprite pointers at all, and is the first key concept to making this technique work, and a brilliant invention by Mr. Togel. -GT] 3.1.1 Table to illustrate the sprite pattern-handling Spriteline Video-Ram Screenline (NOT equal to rasterline!) 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 9 1 9 10 2 10 11 3 11 12 4 12 13 5 13 14 6 14 15 7 15 16 8 16 17 1 17 18 2 18 19 3 19 20 4 20 21 5 21 -------------------------------- 1 6 22 2 7 23 3 8 24 4 1 25 . . . . . . . . . 20 1 41 21 2 42 -------------------------------- 1 3 43 2 4 44 3 5 45 . . . . . . . . . 3.1.2 Example Small example for Sprite 0 under the following conditions: Used 8 Video-Rams : $4000 - $5FFF content of the sprite-pointer: $43F8 80 00 00 00 00 00 00 00 $47F8 81 00 00 00 00 00 00 00 $4BF8 82 00 00 00 00 00 00 00 $4FF8 83 00 00 00 00 00 00 00 $53F8 84 00 00 00 00 00 00 00 $57F8 85 00 00 00 00 00 00 00 $5BF8 86 00 00 00 00 00 00 00 $5FF8 87 00 00 00 00 00 00 00 Thus the Sprite-Patterns are in memory from $6000-$61FF. Therefore the pattern-handling looks like this: Screenline Memorylocation 1 $6000-$6002 2 $6043-$6045 3 $6086-$6088 4 $60C9-$60CB 5 $610C-$610E 6 $614F-$6151 7 $6192-$6194 8 $61D5-$61D7 9 $6018-$601A 10 $605B-$605D 11 $609E-$60A0 12 $60E1-$60E3 13 $6124-$6126 14 $6167-$6169 15 $61AA-$61AC 16 $61ED-$61EF 17 $6030-$6032 18 $6073-$6075 19 $60B6-$60B8 20 $60F9-$60FB 21 $613C-$613E 22 $6180-$6182 23 $61C3-$61C5 . . . . . . 3.1.3 Remark to the display-routine of the editor As the changing of the video-ram on the editor-routine happens inside of the textscreen (but the spritepointers are read inside the sideborder), the change takes effect one rasterline later. [To state this again, the changes in the raster routine are made at a time when the sprite pointers have already been read by the VIC, therefore, even though the changes are made on the same raster line, they don't take effect until the next raster line. -GT] This means that whenever the colors for the bitmap of color ram 2 are read, the sprite pointers or video ram 1 are still active. This is the reason why the editor uses only 167 screenlines (instead of 168) and why the first textline of the first video-ram and the first rasterline of the bitmap stays empty. [I would consider this a minor bug which potentially could be fixed in a future version, by starting the raster routine one line earlier. -GT] 3.2 Changing the Sprite Y-Values As the changing of the sprite pointers more or less happens by itself, we just have to make sure the correct Y-Value comes into the game. These are still 8 values, but they don't have to be set in one rasterline and we got 21 rasterlines to set them. As we have just 3 cycles left on each rasterline on the FLI routine described and that wouldn't be enough for a simple LDA : STA, we have to change the FLI routine a little bit. 3.2.1 Load new sprite Y-Value As the height of all sprites is the same, we just have to do a single LDX #$VALUE. Therefore, 2 of the 3 free cycles are used and we cannot do anything else with the last free cycle. LDX #$VALUE LDA #$08 STA $D018 LDA #$38 STA $D011 3.2.2 Preload the Upcoming $D011 Value As a STA $SPRITE0Y needs 4 cycles, we cannot include it in the next rasterline, but we can already load the next $D011 value into the Y-Register. The free cycle stays unused. LDY #$3A LDA #$18 STA $D018 LDA #$39 STA $D011 3.2.3 Write new Sprite Y-Value As we already did the loading of the $D011 value for the next line, we now have 5 cycles left and therefore enough time for a STA $SPRITE0Y. STX $SPRITE0Y LDA #$28 STA $D018 STY $D011 Now plot 3.2.2 and 3.2.3 have to be repeated for the remaining 7 sprites with changed values for $D011 and $D018. So there is now 1 rasterline for loading the new sprite Y-value and 8 * 2 rasterlines to write the new sprite Y-Value. We now have 17 rasterlines and the 4 remaining ones just need an additional NOP so that all rasterlines use the same amount of cycles. [This tricky piece of raster code is the second brilliant concept to making the technique work. Note also that there will be some staggering in the timing of FLI effect, due to the unused cycles, but still within the parameters required. Also it seems that parts of the row of 4 sprites in 2 layers would gradually be moved downward after parts of them have already been drawn, therefore causing a repetition of graphics, except for the fact that the sprite pointers are different in the new position, and that the sprites are really sliced apart in lines, so it doesn't matter. I find this a very difficult concept. -GT] 3.2.4 Remark to the Display-routine of the editor For simplification of the routine, which generates the FLI routine, in the remaining 4 rasterlines an LDX #$VALUE was used instead of an NOP. 4. Memory-allocation Now video-rams, the bitmap, and the sprites have to be placed reasonably in a VIC-Bank. As the banks from $0000 - $3FFF and $8000 - $BFFF are useless for graphics due to the overlay of the Char-rom we choose the back from $4000 - $7FFF for now. 4.1 Video-rams The 8 video-rams need $2000 Bytes. They are located from $4000 - $5FFF. 4.2 Bitmap The bitmap needs $1F40 Bytes. It's located at $6000 - $7F3F. 4.3 Sprites As we need 2 sprites overlayed {two layers of 4 sprites next to each other} (four times next to each other and 8 times below each other), we need 2 * 4 * 8 sprites, meaning 64 overall. We need $1000 bytes for the sprites. We check what the video-rams and the bitmaps already allocate and recognize that only $7F40 - $7FFF, enough memory for 3 sprites, is left open. How do we rectify this situation? As the video-rams and the bitmap just need a small part for displaying the picture, the sprites can be put into the spare parts of the video-rams and the bitmap. They have to be masked by choosing the right color in the video- rams. A textline of a bitmap covers $140 bytes. Our Super Hires cutout just needs $60 bytes though and is centered. Thus the first and the last $70 bytes of a textline of the bitmap is free. As a sprite needs $40 bytes, we can put 2 sprites in each textline of the bitmap (one to the left and one to the right). Due to the height of the picture (21 textlines), this results in space for 42 sprites. From textline 22 on (in memory from $7A40) we can use the whole textline for sprites, resulting in 5 sprites per line. Continuing this until textline 24 inclusive, we have space for 15 additional sprites. So overall we already have 57 sprites and just 7 are missing now. These we could place in the remaining free area of the bitmap ($7E00-$7FFF), but that's not very efficient as we have some space left in the video-rams. The Textline of a video-ram contains $28 bytes. The Super Hires cutout just needs the middle $0C bytes. As the sprites we put to the left and to the right of the picture are supposed to be invisible, we need to set a background-color in the video-ram (in our case, the color light-grey $FF). So we don't have enough spare room for the sprites to the left and the right of the picture in the video-ram. If we finish the FLI Routine from textline 22 on and keep the video-ram on until the end of the screen (filling the this area ($4370-$43E8) with the backgroundcolor $FF to hide the sprites) we can use the remaining 7 video-rams from textline 22 (from $4770, $4B70, $4F70, $5370, $5770, $5B70, $5F70) for one sprite each. Now we have placed all 64 sprites and the allocation of the sprite pointers looks like this: $43F8 80 84 85 89 8A 8E 8F 93 $47F8 94 98 99 9D 9E A2 A3 A7 $4BF8 A8 AC AD B1 B2 B6 B7 BB $4FF8 BC C0 C1 C5 C6 CA CB CF $53F8 D0 D4 D5 D9 DA DE DF E3 $57F8 E4 E8 E9 EA EB EC ED EE $5BF8 EF F0 F1 F2 F3 F4 F5 F6 $5FF8 F7 1E 2E 3E 4E 5E 6E 7E The pointers from $80 to $E4 are the 2 sprites which are left and right next to the picture in the bitmap. The pointers from $E8 to $F7 are the sprites from textline 22 to 24 below the picture in the bitmap. The pointers from $1E to $7E are the sprites from textline 22 to 24 below the picture in the video-rams. 5. Interlace Until now we had the normal Super Hires FLI mode, supplying the basics for interlace. For the interlace mode we need 2 pictures of this kind switching, displayed 25 times per second (PAL). [30 times/sec in NTSC -GT] As such a picture fits into the VIC-Bank from $4000 - $7FFF and we have another VIC-Bank ($C000-$FFFF) with the same assumptions we can easily place the 2nd picture there. We had in the Super Hires FLI mode (on a 8 * 1 pixel-area) the choice between 4 colors (2 sprite-colors, being the same for the whole picture + 2 FLI colors). Now, in the interlace mode, we have the choice between 16 mix-colors, meaning the combined 4 colors from picture one and two. When using interlace, mix-colors are created except for the case when the same colors are used for both pictures on the same 8 * 1 pixel-area (Check the following example) : Pic2 -> Sprite1:$E [ Sprite2:$0 [ FLI1:$6 [ FLI2:$9 ---------------------------------------------------------------- Pic1 Sprite1:$1 [ $1E [ $10 [ $16 [ $19 [ Sprite2:$3 [ $3E [ $30 [ $36 [ $39 V FLI1 :$E [ $EE [ $E0 [ $E6 [ $E9 FLI2 :$6 [ $6E [ $60 [ $66 [ $69 This results in the following 16 mixcolors: 1. White-Lightblue 2. Cyan-Lightblue 3. Lightblue-Lightblue (pure Lightblue) 4. Blue-Lightblue 5. White-Black 6. Cyan-Black 7. Lightblue-Black 8. Blue-Black 9. White-Blue 10. Cyan-Blue 11. Lightblue-Blue 12. Blue-Blue (pure Blue) 13. White-Brown 14. Cyan-Brown 15. Lightblue-Brown 16. Blue-Brown When choosing the colors you should take care that the brightness-values of the 2 mix-colors are about the same and that they do not differ by more than 2 brightness steps, as things otherwise start to flicker too much. (e.g. Black-White flickers a lot). Here is a table with brightness-values from light to dark. (Colors on the same line have the same brightness) $1 : White $7, $D : Yellow, Lightgreen $3, $F : Cyan, Lightgrey $5, $A : Green, Lightred $C, $E : Grey, Lightblue $4, $8 : Lilac (Purple), Orange $2, $B : Red , Darkgrey $6, $9 : Blue, Brown $0 : Black [On very old 64's (64 cycle raster line NTSC VICs), there are only 5 luminance values in the 16 colors, making them less distinct. Yellow and cyan are the same brightness, then green, grey, and purple, then red and blue. White and black form the last 2 values of brightness. The pairing of colors above are included. -GT] 6. Additional Graphics (Not handled by the editor) We found out that on the left or right of the picture in the bitmap, $70 bytes was left for spritedata. We used just $40 bytes of that space, meaning we still have $30 bytes (6 Chars or 48 Pixels) left to both sides of the picture. 6.1 Left to the picture Our Super Hires Picture starts at position 15. The spare $30 bytes are from position 9 to 14. As we use 14 cycles in our FLI routine and the 8 sprites use 19 cycles per rasterline, the light-grey FLI Bug now uses the chars 11, 12, 14. Thus meaning we could use char 14 for Hires FLI. On chars 9 and 10 we could just use 2 different colors (respectively 4 mix-colors for interlace) on the height of 21 textlines in the bitmap, as the FLI effect starts from Char 14 and before that no new data (colors in this case) are read from the video-ram. The colors are in the first video-ram in memory from $4008+$4009 respectively $C008+$c009. [The shifli pic could probably be expanded by rearranging the raster code very carefully, and even areas outside the shifli effect could still use normal graphics modes, but I expect only a small improvement. -GT] 6.2 Right to the picture Our Super Hires Picture lasts until char-position 26. The spare $30 bytes in the bitmap are from position 27 - 32. Here we could use all 6 chars for Hires FLI (or Interlace Hires FLI). 7. Memory-allocation of a picture startable with RUN The included SHIFLI picture, once unpacked, can be easily modified for your own use, as follows : $0801-$080C Basic Startline $080D-$0860 Routine for copying the Graphic-data to the correct memory area $0861-$095B Routine which is setting the I/O registers and creates the display-routine (from $085F-$10FB) $095C-$475B Data of the 1. Picture (to be copied to $4000) $475C-$855B Data of the 2. Picture (to be copied to $C000) 8. Conclusion For questions or comments concerning this article : Roland Toegel is available at : toegelrd@trick.informatik.uni-stuttgart.de Count Zero/TRC*SCS is available at : count0@mail.netwave.de :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: /S04::$dd00:::::::::::::::::::S O F T W A R E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Defeating Digital Corrosion (aka "cracking") - a beginners guide to software archiving By Jan Lund Thomsen (aka QED/Triangle) Pontus Berg briefly touched the subject of tape cracking in his disC=overy 1 article (/S08: Software analysis and reconstructive therapy, a historical view on "cracking"). But then again, "great minds think alike". :) The purpose of this article is to provide a broader, more detailed view at the general components - as well as some insight on the way a cracker did his "thing" back in the old days. Although some degree of technical knowledge is required to make the most of this article the casual C64 enthusiast should also be able benefit from it. Disclaimer ---------- Despite the issues discussed in this article it is in no way written to encourage software piracy. You are not allowed to use the knowledge found here to make copies for other people. If you go ahead and do this despite what I have just said it is not my problem and I can't be held responsible in any way. [Ed. note : As always, disC=overy and the editors and staff of disC=overy can not be held responsible for the use or misuse of any information presented in this article.] Preface ------- In a world of digital corrosion the need to create backups is something most of us deal with sooner or later. You might never have had any problems yourself - but tapes or disks have been known to "go bad". And what if your tape deck suddenly blows up, rendering you unable to play your favourite games? Wouldn't it be nice to have a backup? Some people (myself included) prefer using the backup copy and storing the original in a safe place. Copies can be stored on floppy disks or hard drives for easier/faster loading. Creating an exact copy of a backup is not only very easy; it eliminates the risk of losing data due to corroded tapes. Yes, the techniques described here are exactly the same as software pirates have been using since the dawn of time; defeating a protection scheme in order to create something that can easily be backed up. This article is *not* about Software Piracy (and I will not answer any comments on that issue). I strongly believe that owners of original software have every right to create backups. During the course of this article I will be looking into the specifics of transferring original tape software to disk. I have several reasons for choosing the subject of tape rather than disk software: - I have far more tape originals than disk originals. (I.e. more research material.) - From a beginners point of view, Tape software is far easier to crack. - Disk originals are easier to reproduce, and therefore not as vulnerable to digital corrosion as tapes. Requirements ------------ Apart from a tape deck and one or more original tape programs it goes without saying that a good deal of 6510 Assembly skills are required to be able to be a successful cracker. A good cartridge is really a must as well. I prefer the Action Replay Mk V or the Expert V4.2 due to their awesome debugging features. Why don't I just use the backup option in my cartridge? ------------------------------------------------------- To be able to answer this question we need to go back in time and take a look at the C64 crackers of yesteryear. As different people all over the world were pirating software, cracking soon became a quest for quality rather than quantity. Of course some people cared less about quality and more about releasing a steady stream of software. A real cracker didn't care about speed. Any cracker could produce a working copy in a couple of hours - but the real cracker wasn't satisfied with just producing a "working copy". Why would anyone capable of doing a *great* crack settle for less? For some crackers "good" simply wasn't good enough. Bugs were fixed, cheat modes installed, and excess data was surgically removed to produce shorter, cleaner cracks. Real cracking is about technical achievement, pride, dignity, and a dedication to quality. Needless to say, no cracker worth his salt will want to freeze/backup anything. I, for one, have never used this feature of my Action Replay - not even for the purpose of producing copies for my eyes only. Although a backup created with the "backup" option of the Action Replay, Expert, or any other freezer cartridge might run just fine, it can *never* be as good as the result produced by a dedicated cracker who knows what he is doing. In short: *Anyone* can press a button. Getting started --------------- As this article is aimed at the beginner level we will only deal with "single-loaders" - i.e. programs loaded into memory in a single pass. Programs using additional I/O (highscore savers, intermission screens, levels, etc.) are known as "multi-loaders" and will be briefly mentioned in chapter 5: What's next? Cracking (let's not beat about the bush and call it something else just to be politically correct) a tape game boils down to the following four steps: 1) Transferring the loader to disk. 2) Analysing the loader. 3) Modifying the loader and pulling the files off tape. 4) Wrapping up. Chapter 1: Transferring the loader to disk (or "One small step...") -------------------------------------------------------------------- By definition, copy protection prevents the user from duplicating a piece of software. In the case of tape software programs are stored in a non-standard format, incorporating a fast loader of some sort. The "loader" - a short assembly program at the start of the tape contains the program code necessary to load the rest of the data. As the loader is stored in the standard tape format it is fitted with an autostart feature to prevent tampering. Therefore, the first step to transferring a tape original to a copyable form is to load the "Loader" program *without* starting it. Luckily Commodore themselves come to our rescue with the following ROM routines: Decimal Hex. Description ----------------------------------------------- #63278 $F72C Read program header off tape #62828 $F56C Read rest of program off tape By inserting a tape and issuing the 'SYS 63278' command the program header will be read into the tape buffer at $033C-03FC. The first bytes of a typical program header will look something like this: .:033C 03 A7 02 04 03 4C 4F 41 .....LOA .:0344 44 45 52 00 00 00 00 00 DER..... As you might have noticed, the filename is stored from $0341 onwards. However, the five bytes from $033C-0340 are of much more interest to us. The first byte describes the type of header: in this case "03" - a machine language program. The next four bytes contain the start and end address (Low/High byte) of the program. This header above denotes "LOADER", a machine language program loaded from $02A7-0304. As the $0300-0304 area contains a number of system vectors that can be modified to to point at the loader program and this explains the autostart. If we modify the start/end address before reading the rest of the program (using the routine at $F56C) the file will be relocated, thereby circumventing the autostart. I recommend adding #$10 to each of the high bytes (thus shifting the entire loader $1000 bytes upwards in memory) as this makes further studies a lot easier. The file in question would be relocated to $12A7-$1304. Having read the "loader" program to another memory location we are now able to save it to disk. But that's not all! Program code can also be stored in the tape buffer so be sure to examine the contents of $033C-03FC before moving on to step 2. If the buffer contains any other data than the five control bytes and the filename discussed earlier, save it to disk as well. Congratulations! You have now taken the first step... there's much more to come! Chapter 2: Analysing the loader. -------------------------------- Brace yourselves! This is the tough part. There are a *lot* of different protections out there. It would be rather impossible to discuss even a fraction of them here. Some tape protections are quite easy to crack once you've gotten past the initial autostart loader. Others might require you to decrypt data in one way or another. Some particular nasty systems even load a new copy of the loader on top of the old one to prevent tampering (the Firebird Gold loader being a good example of this). Cyberload, the mother of all tape protection schemes, not only uses this technique - it also features encryption as well as two different load systems. If you can force a Cyberloader to it's knees, you have every reason to be proud of yourself. It really goes without saying that a good deal of assembly language skills are required in order to understand what goes on. However, as long as you are able to grasp the overall function of the various parts of the program under scrutiny - you do not need to know every detail about the inner workings of it. Having said that it should be obvious that the odds increase the more you are able to understand. In other words: Practice! Practice! Practice! Consider the following example: l1 JSR $XXXX ; get byte from tape STA ($F9),Y ; store in memory INC $F9 ; increase pointers BNE l2 INC $FA l2 [...] ; check for end-of-file/last file/etc. BNE l1 SEI LDA #$35 STA $01 JMP $1000 ; start the program. XXXX [...] l3 LDA $DC0D AND #$10 BEQ l3 LDA $DD0D STX $DD07 LSR LSR LDA #$19 STA $DD0F [...] RTS The subroutine at XXXX seems to be doing something with certain I/O registers. Understanding exactly what goes on isn't all that important because by looking at the code following the JSR (at l1) we can clearly see that something is stored in memory after calling the routine - i.e. the routine at XXXX must be some kind of loader. As Sir Arthur Conan Doyle's famous detective would put it, "Elementary, my dear Watson." Sometimes you will have to overcome various obstacles to get to the heart of a loader. Some protections schemes rely on encryption, others on obfuscated coding. The creators of the most sophisticated protection schemes knew that understanding what goes on is the key issue regarding cracking, and went to great lengths to discourage the "professional" as well as the casual cracker. Chapter 3: Modifying the loader and pulling the files off tape. --------------------------------------------------------------- Now that you have penetrated the outer layers, you will want to pull the individual files off the tape and store them on disk. One approach would be to locate the piece of code that launches the main program and replace it with something that halts the computer using a infinite loop, allowing you to enter your cartridges in-built monitor, and save a memory dump to disk. In some cases it is advisable to halt the computer after each file has loaded and save the data to disk before carrying on to the next file. Whatever approach you choose the key issue is to halt the C64 and save the relevant data. If space permits, I prefer to insert the following piece of code: SEI LDA #$37 STA $01 l1 INC $D020 CLC BCC l1 If there is no room in loader for big modifications like the above make a note of the original code before modifying the loader. l1 CLC BCC l1 also works quite well, not to mention only taking up three bytes. However, this requires you not to enter the monitor until you are completely sure the program has entered the infinite loop. I have used this approach so much that I know the assembly opcodes ($18,$90,$FD) by heart, even though I haven't used them in years. Now that the C64 is halted and we are ready to save the data to disk we need to obtain the relevant addresses. I mean, why take up too much diskspace? :) Using the example from the previous chapter the data was stored at the memory location held in $F9/$FA . Thus, looking at the content of $F9/$FA will give us the end address of the file. For the start-address we can either make an educated guess using the 'M'emorydump or 'I'nterrogate to scroll backwards until we encounter something that does not look like it belongs to the file (after lots of practice real crackers can be quite good at this.) A more precise (not to mention subtle) approach is to patch the loader to store the content of the pointer elsewhere and modify the loader back to normal to prevent the start-address from being increased due to the pointer being increased. Chapter 4: Wrapping up. ----------------------- Having transfered the files to disk it is time to wrap everything up. This is by far the easiest step. Link the relevant files, then use a Char/RLE packing program (EBC, Link & Crunch, X-Terminator, etc.) followed by a "cruncher" program (DarkSqueezer, Byteboiler, Cruelcrunch, etc.) For shorter, cleaner cracks be sure to removing any excess data. Try having a look at the game code - be sure to examine any memory-ranges that are cleared by the startup code. Often quite a bit of data can be surgically removed without causing any damage to the "patient". Loading pictures are most often turned into stand-alone files. Just add a short piece of code to get the graphics on screen and pack everything. *Test* the finished product. In the old days a lot of bad quality could have been avoided if crackers had taken the time to make sure everything worked before releasing it onto the public. Again, this boils down to real cracking being more than just churning out a heap of "warez" every day. I suppose the modern day term is "quality assurance". :) Chapter 5: What's next? ----------------------- Practice -------- Just because you suddenly find yourself able to breach one protection scheme doesn't mean that you have suddenly become an expert cracker. Lots of practice and further studies are needed to become successful. If you have more than one original tape using the same copy protection, don't be afraid of experimenting. Maybe you'll want to try out some new approaches. A lot can be learned from writing a program to automatically transfer files saved by a specific system. Gradually progress to other systems. If a system seems impossible to breach, try sharpening your skills on easier systems and coming back to it later. As mentioned earlier, there are a *lot* of different loaders on the market. Although the schemes used vary from one program to another, chapters 2 and 3 should give you a rough idea about the basic idea and the steps needed to circumvent various systems. Multiloaders ------------ Multi-loaders (Programs using additional I/O such as intermission screens, levels, etc.) will require you to replace the original loader with a custom disk-loader. If you poke around the original loader you will most likely discover some sort of internal level-counter that can be used to refer to the name of the file you want to load next. Be sure to compress data files with a Levelpacker for a result consuming a lot less disk space. Levelpackers include a short loader/depacker program that will decompress the files on the fly. Disk originals -------------- Feeling confident about tape cracking? Why not move on to disks? Be prepared to encounter everything from minor obstacles to the meanest mothers in the business. Disk cracking is, as they say, "A whole different ballgame!" --- The author has been a C64 enthusiast for the past 11 years - and a general 8-bit addict for even longer. In his earlier years he was part of the European C64 cracking scene. He is an active participant both on the #c-64 IRC channel, and in the comp.emulators.cbm and comp.sys.cbm newsgroups. Recently he took his group "Triangle 3532" to the World Wide Web. When he isn't busy playing Lode Runner on his C64 he is available for questions and/or general comments at the following Internet address: kwed@pip.dknet.dk :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: /S05::$df00:::::::::::::::::::S O F T W A R E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: A possibility to be explored : Real Time Video with the Ram Expansion Unit by Nate Dannenberg (Natedac@dfw.net) A few weeks ago, there was a discussion on the comp.sys.cbm usenet newsgroup concerning the viability of using the Ram Expansion Unit as a medium for displaying real-time video animation on the C64 or C128. I thought about the possibility and came to a few conclusions. The following text is how I would undertake such a project. Along the way, I shall illustrate some previous "reu-animation" efforts and how the peculiar qualities of the REU allowed such efforts to be accomplished. -- While I've never actually done video, Commodore did it at least twice. On the 1750 and 1764 Test/Demo disks there is a "Pound" demo and a "Globe" demo. These two are full motion displays using your REU. The "Pound" demo is a 3-dimensional # sign transforming in and out, the "Globe" is a full rotating Earth/globe. The controlling program for these is written in BASIC, with a small ML program to decompress the graphic data that's stored on the disk, as it's loaded into the REU. The REU has a transfer rate of about 1,022,000 bytes per second. Since a single video frame is 1/60 of a second, that gives you 16,666 clock cycles per video frame (including video sync time). Chances are good you will probably want to only display about 15 frames a second, which is the MPC-1 specification for PC full motion video playing from a CD-ROM disc. With simple code, you can get about a 7.7Khz sample rate for the audio, by playing one sample byte every other raster line, and maintain a smooth 60 FPS video transfer rate, should you want to go this high. All you have to worry about is making sure you start an animation frame transfer at the top of the intended video refresh, raster line 0. You do this with a simple wait loop: loop BIT $D012 BMI loop As soon as bit 7 of $D012 goes low, the BMI will fail, signalling raster line 0 on a new frame. The VIC chip steals 43 cycles from the CPU (and any REU transfer in progress) on the first of every 8 raster lines. The line where this occurs now only has about 21 cycles free instead of the usual 64, this is called a "bad" line in demospeak. You want your audio routines to use the odd lines, to stay out of the way of the bad lines that occur every 8 lines. The video routines and any additional overhead can be used after the audio routine has done it's job on it's line. An algorithm like this might do the job: 0 bad line, start audio REU xfer from last video refresh (see below) 1 Play 1 sample of audio data and run animation copier routine 2 :::: 3 Play 1 sample and run animation copier 4 :::: 5 Play 1 sample and run animation copier 6 :::: 7 Play 1 sample, set REU to grab 2 more audio bytes 8 bad line, start the audio REU xfer (should take 8-10 cycles) 9 Play 1 sample and run animation copier 10 :::: 11 Play 1 sample and run animation copier 12 :::: 13 Play 1 sample and run animation copier 14 :::: 15 Play 1 sample, set REU to grab two more audio bytes 16 bad line, start the audio REU xfer (8-10 cycles) 17 Play 1 sample of audio data : You use a 2-byte transfer buffer for the digi audio data, to cut REU overhead to a minimum, and to maximize the usage of those bad lines. Remember that packed RAW data, as stored in a file, takes 1 byte for 2 samples. So we're really transferring 4 samples here.. Basically on every badline you simply tell the REU to start the 2 byte transfer that was set up on the previous line. In the case of line 0 of the very first frame when starting the code, simply set up everything needed, including the first 2 byte audio pointer, which will be used by the REU at the end of line 0 to copy those 2 bytes.. This only takes 6 cycles to activate, plus 2 cycles for the dma copy. You have 11 cycles left, which may or may not be useful. Just use four NOPs and a BIT, to waste this time out to the next line. Play 1 sample of audio data on every odd line, this takes only 6 cycles if the data from the REU was copied to Zero Page. You have the remainder of the this rasterline and all of the next to run your animation copier, a total of about 120 cycles. You should be able to squeeze in about 80 or so bytes into this space (80 bytes plus about 40 cycles of REU overhead is about 120 cycles). The REU can be programmed to remember where it left off after a transfer, making subsequent contiguous transfers painless. It takes about 40 cycles to set up and execute the first transfer (plus the actual copy time), and then only 6 cycles to repeat the transfer (plus transfer time of course), by using LDA #imm:STA $DF01 , where #imm is the value that tells the REU to start, I forget offhand, something like #$95 I think... This means that you might only be able to copy 80 or so bytes the first time after an audio data copy (the first line following a bad line), but you can transfer another 80-byte block just by using only 6 cycles to re-execute the copy. Use another 6 cycles to adjust the size of the transfer if you want more to be transferred this time, LDA #imm : STA $xfer_size_reg where #imm is your new size and xfer_size_reg is the REU register for the low byte of the transfer length.. In this way you use 12 cycles to start a new size of transfer, and are able to copy around 108 bytes, instead of just 80. On every raster line that'S just before a badline, you play the last sample in the buffer, and use the rest of the line to set up the REU to transfer another 2 bytes of audio data into your audio buffer. This should only take about 40 cycles or so, plus whatever time is needed to update your audio data pointers. To keep your timing easy, you should definitely keep this line down to less than 64 cycles. You can push it into the next (bad) line, but then you gotta make sure the REU has completed the 2 byte transfer before the VIC starts the line following the bad line, and you only have 21 cycles on that bad line in which to do it. Use as much raster time as you can for the REU copier code, since the audio code is so simple and requires comparatively little CPU time. The REU is predictable; you will always know precisely how many cycles a transfer will take. However, you may not always know how much time your own code will take, so you may need a simple wait loop like this at the ends of certain raster lines, to wait for the next raster line: LDA $D011 loop CMP $D011 BEQ loop This takes 11 cycles, plus 7 each time it loops. Needless to say, you need to know a little about synchronizing all of this to the video display and the raster lines. Location $D011 in the VIC is the low byte of the raster counter. Reading this register will tell you what raster line the VIC is on at any given moment. Remember that an NTSC TV has 525 lines, which consist of two 262 line fields, often called "even" and "odd" fields. In a TV displaying a normal broadcast signal, One set of fields is normally positioned half a raster line below the other, resulting in true 525 line interlaced display at a 30Hz refresh rate. The VIC chip gets around this by displaying the exact same data in both fields, and by placing both fields on the exact same position on screen, instead of moving one down half a line. The result is the "normal" 262 line screen with a 60Hz refresh rate. Synchronizing to a particular raster line is a simple matter of: LDA #your_raster_line loop CMP $D011 BNE loop This type of wait loop takes 9 cycles for the first run, plus 5 cycles each time it loops. When you start a new frame update/copy, you need to synchronize your routine to start on raster line 0. You can do this by watching the high bit of the raster counter: loop BIT $D012 BMI loop This only takes 5 cycles per loop. As soon as bit 7 of $D012 goes low (0), the BMI will fail, signalling that the VIC has started an even video field. This way you know you are at the start of the TV's video frame as well as the VIC's idea of a frame. I don7t knwo if this would really matter, however. :) Remember that line 0 is NOT a bad line, nor are any other lines outside the range 48 to 199, because there is no visible display here, only border. On these lines outside the visible display, you have 43 cycles more on every 8th line, which are normally the bad lines on the visible display. They are all a full 64 cycles long like any other non-bad line elsewhere on the display. Let's take a general routine that copies 80 bytes on every two raster lines (minus the bad line and the line before that), not using the REU's ability to remember where it left off. 80 bytes * 3 transfers per row is 240 bytes. 25 visible rows * 240 bytes yields exactly 6000 bytes. Well we still have those 56 rasters off screen. That'S about 7 rows tall, and we can use the same routine as we do for the on-screen rows (except we have no bad lines to deal with).. So 7 * 240 = 1680 bytes + 6000 from the on-screen rows = 7680 bytes. That'S not quiet fast enough to do 60 FPS, but you can certainly get 15 out of it. :) In fact that looks to be good enough for 50 FPS. Well we can improve this! Since the REU can remember where it left off, why not get it to transfer 80 bytes the first time on each row, and 108 bytes each of the next two times (as described way up there someplace)? Well, let's add it up... 80 + 108 + 108 = 296 bytes per row. 25 rows times 296 bytes yields 7400 bytes on the visible screen. We only need another 600 bytes to finish our 8000 byte bitmap... LeT's just use the next three rows and waste a few rasters.. 296 * 3 = 888, add the 7400 bytes we've done on the visible screen and we get 8288 bytes. Just slightly more than enough for the full screen. After all this we still have another 32 rasters left, on which the audio routine is still running (on every other line). That audio routine is probably only using maybe 1/20 of the total raster time. Even then we could still speed this up by using some of that leftover raster time, and with a little fiddling you can get 15Khz instead of 7.7Khz, but that'S kinda tricky and involves a lot more cycle counting. Now remember, all of this audio and video data takes a LOT of ram.... You can only get 8 animation frames into a 64K bank in the REU if you go with full-size 320x200 bitmaps. A 1750 REU only has 8 banks, that'S a total of 64 animation frames. At 15 FPS, that'S only about 4 seconds of video.. A 2MB REU on the other hand has 32 banks, which yields 256 frames. At 15 FPS, that'S only about 17 seconds of video. One way to increase the video time is to use custom characters to simulate an 80x100 bitmap using a text screen. This would still be monochrome and would be much lower resolution, but you would now have about 8 times longer video. That 2MB REU would now be able to handle about 140 seconds, or just over two minutes. The advantage of that method is you would only have to copy 1K of data instead of 8K, which could be done in about 5 rasterlines using the above copy-and-remember method. And then you still have your audio track with that.. a 7.7Khz sample uses 7700 bytes for 2 seconds (packed 4 bit data) of sound, so a 4 second long sample, will take just over 15K. A 17 second sample would take about 65K. And to match up that 140 seconds of video with 140 seconds of audio would take about 537K, or about 1/4 of the 2MB REU. Obviously you would have to find a break-even point here, where you have as much audio time as video time. From the looks of it, video takes about 4 times as much data as audio, when using 1K charctermapped frames, or about 32 times as much when using full 8K bitmaps. If you were playing the Audio data from the C64's memory, or if you had one ram device to hold audio data and one to hold video, then the overhead would be virtually nil. You could probably get away with a 44 KHz sample rate and 60 FPS video, depending on the code and the speed of the ram device(s) in question. Two REU's mapped at different addresses in memory should in theory be enough to do it. :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: /S06::$f00d:::::::::::::::::::S O F T W A R E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: A look into 'The Fridge' by Stephen L. Judd (sjudd@nwu.edu) [Ed. note : The following text is from The Fridge, an archive on the World Wide Web dedicated to the preservation of useful routines and algorithms. The Fridge (http://stratus.esam.nwu.edu/judd/fridge) is authored and maintained by our technical editor, Mr. Stephen L. Judd. All contributions to The Fridge should be sent to him at sjudd@nwu.edu] Sample descriptions ------------------- * ascii2bin.doc - A description of an ASCII to binary number converter. * ascii32.s - A routine to convert a 32 bit number to ASCII and print it to the screen. * rand1.s - A simple pseudo-random number generator from dim4. Not that great of a random sequence, but fine for simple sequences. * bitchin.doc - "A totally bitchin' circle algorithm" -- ascii2bin.doc The idea here is pretty simple. Numbers are read in left to right, and each time a number is read in, the total is multiplied by ten and the digit is added in: total=0 digit=0 :loop total= total*10 total= total + digit read digit (and convert from ASCII to integer) if not EOF then goto :loop There are two ways to multiply by ten. The first way is to use a general multiplication method. The second is to realize that 10 = 8+2, thus x*10 = x*8 + x*2 = x*2*(1+4), so with a few shifts, a temporary location, and an addition, multiplying by ten can be done very quickly. Example: read in the number 1653 total=0 digit=0 1st read: digit=1 total= total*10 => total=0 total= total+digit => total=1 2nd read: digit=6 total= total*10 => total=10 total= total+digit => total=16 3rd read: digit=5 total= total*10 => total=160 total= total+digit => total=165 4th read: digit=3 total= total*10 => total=1650 total= total+digit => total=1653 Voila! SLJ 10/96 -- ascii32.s *------------------------------- * * 32 bit -> ASCII conversion * * Take 2 -- Divide by 10 manually; remainder is coefficient * of successive powers of 10 * * Number to convert -> faq2..faq2+3 (lo..hi) * * SLJ 8/28/96 ORG $1300 FAQ2 EQU $6A TEMP EQU $FE CHROUT EQU $FFD2 LDA #$FF STA FAQ2 STA FAQ2+1 STA FAQ2+2 STA FAQ2+3 LDA #10 STA FAQ2+4 LDY #10 :LOOP STY TEMP JSR DIV32 LDY TEMP CLC ADC #48 STA $0400,Y ;Stick it on the screen DEY BNE :LOOP RTS * * Routine to divide a 32-bit number (in faq2..faq2+3) by * the 8-bit number in faq2+4. Result -> faq2..faq2+3, remainder * in A. Numbers all go lo..hi * DIV32 LDA #00 LDY #$20 :LOOP ASL FAQ2 ROL FAQ2+1 ROL FAQ2+2 ROL FAQ2+3 ROL CMP FAQ2+4 BCC :DIV2 SBC FAQ2+4 INC FAQ2 :DIV2 DEY BNE :LOOP RTS -- rand1.s *------------------------------- * * GETRAND * * Generate a somewhat random repeating sequence. I use * a typical linear congruential algorithm * I(n+1) = (I(n)*a + c) mod m * with m=65536, a=5, and c=13841 ($3611). c was chosen * to be a prime number near (1/2 - 1/6 sqrt(3))*m. * * Note that in general the higher bits are "more random" * than the lower bits, so for instance in this program * since only small integers (0..15, 0..39, etc.) are desired, * they should be taken from the high byte RANDOM+1, which * is returned in A. * GETRAND LDA RANDOM+1 STA TEMP1 LDA RANDOM ASL ROL TEMP1 ASL ROL TEMP1 * ASL * ROL TEMP1 * ASL * ROL TEMP1 CLC ADC RANDOM PHA LDA TEMP1 ADC RANDOM+1 STA RANDOM+1 PLA ADC #$11 STA RANDOM LDA RANDOM+1 ADC #$36 STA RANDOM+1 RTS -- bitchin.doc A totally bitchin' circle algorithm Last revised: 2/20/97 SLJ With a revision! The old algorithm ignored one small detail -- the plot8 8-fold plotter, which can be a real pain! One thing to do is to make the algorithm draw a quarter of a circle instead of an eighth, and the way to do that is to attempt to reverse the procedure that drew the first eighth of the circle. BLARG does exactly this; in the process, I also experimented with how the order of statements below makes a difference in the way the circles look. So the algorithm below is now the best version I know of, i.e. makes the most beautiful circles at all radii. This is the entire algorithm: Y = Radius X = 0 A = Radius/2 :loop Plot4(x,y) ;Could just use Plot8 X = X + 1 A = A - X if A<0 then A=A+Y : Y=Y-1 if X < Y then :loop ; Now more or less reverse the above to get the other eighth A = -R/2 - 1 :loop2 Plot4(x,y) A = A + Y Y = Y - 1 if A<0 then X=X+1:A=A-X if Y>=0 then :loop2 Neat! The other possibility is to use the first half of this algorithm with an 8-fold symmetric plot, and be sure to plot the last point X=Y. See C=Hacking Issue #9 for more details, but note that A=R/2 above, which will make the circle correct for small R (it just rounds numbers). -- These and other useful bits of information can be obtained through Mr. Judd's web page, - The Fridge -, at http://stratus.esam.nwu.edu/judd/fridge :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: /S07::0100h:::::::::::::::::::S O F T W A R E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: C-128 CP/M, trailblazer in a jungle of formats. By Mike Gordillo The microcomputer world was once awash in an estimated 100 different major operating systems with over 2000 proprietary disk format-types. The numbers are much less intimidating today, but with the resurgence of older systems amongst the public (IMHO), the need to extract information from an obscure disk format may become very real to the hobbyist. Your C-128 and its drive peripherals are extremely flexible when coupled to the right software. When running CP/M, your C-128 is at its best in its role as an inter-platform intermediary. This article will attempt to deliniate what your C-128, under CP/M, can do for you in this regard. -- The original C-128 CP/M BIOS directly supports six 5.25" CP/M MFM (Modified Frequency Modulation) and two 5.25" CBM GCR (Group Coded Recording) format-types. They are as follows: Epson QX10 (MFM) - CP/M Z80 DS/DD Epson Euro (MFM) - CP/M Z80 DS/DD IBM-86 (MFM) - CP/M 8086 DS/DD Kaypro II (MFM) - CP/M Z80 SS/DD Kaypro IV (MFM) - CP/M Z80 DS/DD Osborne (MFM) - CP/M Z80 SS/DD C-128 DS/DD (GCR) - The "Default" C-128 CP/M format-type. C-64 SS/DD (GCR) - C-64 CP/M (Z80 Cartridge) SS/DD Note: The 1581 is "officially" supported in the 28 MAY 87 version of C-128 CP/M 3.0+. The official 1581 format-type is MFM DS/DD. (SS = Single Sided, DS = Double Sided, DD = Double Density) MFM disks usually have the same number of sectors on each track while GCR disks have a variable number of sectors for different ranges of tracks. Commodore-DOS-style GCR is the "default" format-type for C-128 CP/M because this allows "Joe User" to easily boot up CP/M from a 1571 or even a 1541 (slow!) drive. (Fortunately, when Commodore finalized the 28 May 87 version of C-128 CP/M, they not only provided a format-type for use with the 1581 but added a FORMAT.COM that could create a 1581 3.5" C-128 CP/M bootable system disk.) What can you do with these format-types? Taking advantage of what CP/M provides is as simple as inserting a diskette. For example, let's say I have some files on my Kaypro which I need to use on C-128 CP/M. All I have to do is put the Kaypro disk in my trusty 1571 and voila, I can use it and the files within as I please with no hassles. This is no small point of trivia. The message here is that you can use data on these "alien" format-types as if the data were sitting on the "default" C-128 CP/M disk. What about copying them over to C-128 CP/M disks? No problem! The transfer process is as easy as using an off-the-shelf file copier because as far as CP/M is concerned, the "alien" and "default" (native) format-types are one in the same. This degree of transparency is due largely to the internal disk format table which exists within the computer's memory as part of the CP/M BIOS (Basic Input/Output System). This arrangement constitutes better support and flexibility over the rigid Commodore DOS system when it comes to juggling different format-types. What happens if I run across a format-type that is not directly supported by C-128 CP/M? Flexibility to the rescue! The "built-in" drive table is modifiable (both in memory or on the system disk). If you need to access other CP/M format-types, the solution may be as easy as installing the parameters that match the disks in question. A good example of a utility that does this is the UNIDRIVE utility by Frank Prindle. It reconfigures the drive table, allowing up to ten different 5.25 MFM format-types at any one time from an overall selection of twenty-four. Because of the drive table, UNIDRIVE is a simple elegant program that can make these changes without sacrificing any TPA (Transient Program Area) memory. The undisputed king of format "jugglers" and nowhere near as simple is the JUGGLER utility by Miklos Garamszeghy. This program can read and write and format over ONE HUNDRED THIRTY different format-types, mostly 5.25" MFM (with 1571) but also 3.5" MFM (with 1581) based disks. This includes the popular space extending, speedy alternative formats for C-128 CP/M, namely Maxi 1571/1581 and MG 1581. A demo version of the JUGGLER utility is publically available. It does not have as many features as the full version, you can only access twenty-two format-types and modifying the "built-in" drive table is out of the question. This would be inconvenient if the full version were hard to find as it once was. This has changed as its author as put up the full version of Juggler on the World Wide Web at http://www.herne.com/cpm.htm What about MSDOS MFM disks, can I use them as well? Yes you can! I know of at least three separate utilities that will allow communication between C-128 CP/M and MSDOS diskettes. First on the list is the RDMS 2.33 utility. This is an old program designed to read MSDOS diskettes, and that's all it does. It will read from MSDOS into CP/M but will not write back to MSDOS. Frank Prindle ported over this program (for the 1571 drive) and he would have probably added a "write MSDOS" option if someone else hadn't beaten him to the punchline. The TRANSFER 128 v1.2c utility (ported over by Gilly Cabral from David Koski's original TRANSFER util.) came soon after Prindle's rendition of RDMS 2.33. In fact, the routines used to communicate with the 1571 are based on Prindle's work. TRANSFER 128, however, goes way beyond RDMS 2.33. Not only does it read and write to MSDOS disks but it also provides a suprisingly high level of sophisticated access to the internal workings of MSDOS disks. For example, it can display the MSDOS FAT (File Allocation Table) and reconstruct it, if needed, using a backup FAT as a template. TRANSFER 128 supports single and double sided 5.25" format types with eight or nine sectors per track. It places no limits on the size of the data it can transfer. The only limitation is the free space left on the destination diskette. This is a huge advantage over the first "native" mode MSDOS to CBM DOS programs which use internal memory buffering. For many years, TRANSFER 128 was my only standby for large files. When better utilities came out for the "native" modes, I still found TRANSFER 128 to be my choice. Why? Because of the excellent Ram Expansion support under the CP/M BIOS. CP/M thinks the Ram Expansion Unit is truly a real drive. TRANSFER 128 (and other CP/M programs) does not have to worry about steering clear of "interface pages" and silly stuff like that when dealing with the additional Ram. Eventually, people wrote transfer utilities that did work with CBM RAMDOS, for example. Too late, my heart was set on TRANSFER 128. It's been a good companion and since it comes bundled with its Turbo Pascal source, I can always modify it in case of trouble. In fact, I had to do just that when I set up several BIOS/BDOS/CCP enhancements on my system. (But that's another story :))) The one tiny snag with TRANSFER 128, however, is that it will format the various MSDOS format-types perfectly as far as MSDOS itself is concerned, but "native" mode transfer programs do not recognize the disks which TRANSFER 128 has formatted. I am at a loss to explain this, so I won't ;), but its safe to say i'll give TRANSFER 128 the benefit of the doubt anytime! What about 3.5" MSDOS format-types using my 1581? Ah, yes, I've neglected to mention what may be the best "transfer" utility available for the C-128. It may be too sophisticated for young viewers so this section of this article will be rated PG-13 :). Well Well Well !??!? Don't keep us in suspense! Not to worry! The utility i'm harping about is called MSDOSEM (by Nichita Sandru). It doesn't just give you a temporary transfer "window of opportunity", it makes CP/M think of MSDOS disks as native CP/M disks and it provides (get this) *full* subdirectory support!!! This is similar to the transparent "juggling" of CP/M format-types, yes? Yes, except that CP/M disks carry the same directory structure no matter how their format-type is arranged. In order to support the MSDOS directory structure, MSDOSEM creates a separate buffer area for internal conversions between CP/M and MSDOS logical constructs. The actual physical nature of the MSDOS format-types, however, is handled (once again) with a modified CP/M drive table. MSDOSEM has no problem with 5.25" (1571) or 3.5" (1581) double density MSDOS format-types. Again, as described earlier in this article, transparency means that you can play with the "alien" disk as if it were a "default" one. Any copy utility you have sitting around can now access MSDOS diskettes with MSDOSEM as the go-between. This is the ultimate in MSDOS to C-128 transferring because you (essentially) do not have to transfer anything anymore! The "stuff" on your MSDOS disks is no longer anathema to CP/M, even though it may be to you :). What about support for regular Commodore DOS (GCR) disks? In reality, the original "default" C-128 CP/M format-type is as Commodore DOSian GCRish as anything Commodore has done for the "native" modes. I take advantage of this when backing up my CP/M disks, either with FastHack'em (or any GCR copier) in C-128 mode or IMAGE.COM under CP/M itself. These programs allow us to manipulate Commodore GCR on a gross level. For a more refined manipulation of files "stuck" in regular CBM GCR disks, I generally use the RDCBM 2.1 utility by Rob Tillotson and Turbo Penguin Software. This program can read files from 1541 or 1571 "native" Commodore GCR disks and spit them out as straight binaries (eg., no translation) or it can convert files from PETSCII to ASCII. Like RDMS 2.33, RDCBM 2.1 does not write back to the disks it so aptly read and it does not read anything on the 1581. These quirks are *highly irritating* considering its a pretty good program otherwise. Good enough to provide limited support for files under the GEOS file structure. Fortunately, I surmise that I have not run into a more recent version of RDCBM to evaluate. I say this because the source listing of this program contains "Hooks and Crannies" pointing to the author's efforts to implement a "write-back" option and 1581 support. You mean I cannot transfer material from my CP/M disks to my regular 15xx disks??? No I don't. There exist several "native" C-64 and C-128 utilities which will do this. The C-128 "native" mode version of the Big Blue Reader program has this ability. Utilities like Supersweep and Crosslink can also port your files to CBM DOS 15xx disks, albeit these two programs set limitations on the size of the files in question. That's nice, but i'm a C-128 CP/M'er through and through! Ok, you beat it out of me. There *is* a way to "save" files to a regular CBM DOS diskette from within C-128 CP/M. You first use the C128LOAD utility by David Bratton to load a file into Bank 1 of the CP/M memory map. Next, you hit CTRL-ENTER (on the numeric keypad, do not press RETURN) and this will put you in C-128 "native" mode. Finally, you use the built in C-128 ML monitor to save to disk the memory block (Bank 1) where the program was loaded. Please note the following example; A> C128LOAD DIEHARD.C64 Program loaded - from 2000 to 8192 <-- Last byte-address --When the A> prompt reappears, press the CONTROL and ENTER keys simultaneously. (The ENTER key is on the NUMERIC KEYPAD.) READY. MONITOR (activate the C-128 ML monitor & insert CBM DOS disk into drive 8) S "DIEHARD.C64",8,2000,8193 <-- Always add +1 to the last byte-address. ---- In effect, we have just moved the file DIEHARD.C64 from C-128 CP/M to a CBM DOS disk (remember to use the bank address of 1 when saving). While this method places an absolute restriction on the file size of what you can "save", it means that files can be "saved" to any drive supported by the C-128. It is possible to save only one file per iteration of this cycle. In order to save many files, you will have to reboot CP/M and go through these steps for each file involved. This is a roundabout way to "write-back" to CBM DOS and it certainly isn't as contained within CP/M as most of us would like. How do the exciting CMD FD-2000 and FD-4000 drives factor into all this? They are "covered" insofar the programs that support the 1581 also support them, namely the JUGGLER, MSDOSEM, and C128LOAD utilities, and also the 28 MAY 87 Version of CP/M 3.0+ on the C-128. The FD series drives do a pretty good job at emulating the 1581 and should present no problems under C-128 CP/M. The 1581 is limited to around 800 kilobytes and this may not be adequate for you. As far as accessing the high capacity disks within the scope of the FD-drives, the key issue is software (again). For example, there is nothing in terms of hardware that says we cannot use these drives to play with MSDOS 2.88 megabyte formats (ala FD-4000) or create 2.88+ megabyte CP/M formats of our own design. I do not know if FD-based software exists to allow this under C-128 CP/M. How do I use the strengths of some programs to get around the limitations of other programs? I take it you are asking this because of the software gap in linking CP/M to CBM DOS (at least from the CP/M side of the equation)? Well, we have a trump card in our sleeves in the form of the MSDOS format-types. These tend to be the lowest common denominator for information inter-change in the entire microcomputer world. For example, if the JUGGLER utility lacks the ability to communicate with a particular brand of CP/M format-type (a rare event indeed), chances are the system (with the funny format-type) has some means to get information from its disks onto MSDOS disks. Obviously, I can simply use the MSDOS format-types as a bridge "over troubled sectors" :) and not worry anymore. The same holds true for CP/M to CBM DOS. If it becomes too inconvenient to save with C128LOAD and the built in C-128 mode monitor, I simply pop up TRANSFER 128 or MSDOSEM and let them put things into MSDOS disks for later retrieval by CBM DOS-able "native" mode programs such as Big Blue Reader or Little Red Reader/Writer 128. Mind you, this has its own share of inconveniences, but it does present an attractive alternative to some people. What if I don't have a C-128 but I need to put files on a C-128 CP/M disk or some other type of CP/M disk? Hmmm...that's a tad outside the scope of this article but I can see a situation arising from this where a C-128 CP/M user might miss out on some software. If you have a machine that runs MSDOS, you can avoid that situation. There is a MSDOS to CP/M utility called 22DISK140 which supports 140 different CP/M MFM formats in its demo version and over 400 (!) in the full version. The key thing here is that it supports the Commodore 1581 CP/M MFM format. Any files you put in there are going to be useful to a C-128 CP/M user as long as he/she has a 1581 and the 28 MAY 87 Version of CP/M 3.0+ on the C-128 (or a suitable patch which supports the Commodore 1581 CP/M MFM format). You've shown me the software, but where do I get it? All the C-128 CP/M utilities I mentioned are available on Internet FTP sites such as ccnga.uwaterloo.ca in directory /pub/cbm/os/cpm. I have also seen some of them in the GEnie and Delphi information networks. The 22DISK140 utility is available on the Internet FTP site oak.oakland.edu in directory /pub/msdos/diskutil Final thoughts... Software Software Software... This article is by no means the final word on what you can or can't "port" out of C-128 CP/M. For example, Apple CP/M GCR disks are completely isolated from C-128 CP/M, 22DISK140 or anything out there besides an Apple drive! However, some clever magician among you may set to master the Apple GCR format using a Commodore GCR drive. If you do it, drop me a line, good CP/M software is usually a thing of beauty. As I hinted the last time we met, CP/M's strength lies in its software, (: and in its users does its software lie. :) ------- Mike Gordillo is an expert in CP/M and Z80 programming as well as a devout Commodore fanatic. He may be reached on the Internet as s0621126@dominic.barry.edu for general comments or questions. :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: \H01::::::::::::::::::::::::::H:A:R:D:W:A:R:E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: The X10 PowerHouse, What is it? by Dan Barber (xy3951@epix.net) Well to put simply, it is a system that allows you to control up to 256 lights and or appliances in your house automatically, or from a distance. The most basic part of the system is the modules. They are small boxes that plug into a plain 2 or 3 pin electrical outlet (depending on the module you have purchased) and the device you wish to control is plugged into the module. Then you can get numerous remote controls that send signals to a receiver that then sends the signals over your wiring to the individual modules, which then turn on, off, or dim (if you are using a lamp module). As I have said, you can get remote controls to control the appliances, but why not just control them with the normal switch and save yourself some money? Because a computer interface can also be purchased for the system, and this interface can be programmed with a Commodore 64/128! Or if you are one of the unfortunate that don't own a Commodore, then you can use a MS-DOS, Apple Macintosh, or Apple IIe/IIc. The CP290 Home Control Interface is 5 inches wide by 7 long, and 1 1/2 deep. The top face is covered by rocker keys which allow you to control 8 modules from one HOUSECODE which is adjustable. The modules have two dials on them, the first is the letters A-O. This is called the the HOUSECODE. The second dial on the modules is the number 1-15, this is the UNITCODE. So, your first module would probably be name d A1 and the second A2 and so on, for a total of 256 modules. The interface can handle control of all 256 modules but if you are using the Commodore 64/128, you can only program 95 using the included point-and -click GUI (Graphic User Interface) program. If you have more than 95 modules you will have to use the included BASIC extension program that is included on the disk. Then you can create your own simple program to control all of the modules if need be. But I can't personally imagine anyone using over 95 modules, unless you have a mansion. :) The program that sets up the interface is very simple to use. With the power off you connect the cable to the userport and the interface turn it on and load the program. You set the time and the HOUSECODE you want the rocker keys to respond to and then the screen shows the different rooms you can "install" modules in. There are 9 "virtual" rooms you can place and program modules, though it does not make any difference what room you have the module in as long as the dials on it are set properly. Programs for use with other computer systems have differences, some you type in the name of the room instead of using the "virtual" rooms. And some can control all 256 modules with the supplied software, where as other systems must write there own software if they need to control all 256 modules. Once you pick a room (by using the cursor keys or the joystick to move a pointer and clicking) you are presented with 11 "tabs" where you can "place" modules. When you select one you are presented with choices of icons (graphics) that look like appliances and lamps. When you chose one it is stored in the interface as well as the HOUSECODE and UNITCODE. Note, it does not make any difference what icon you select to go along with a module, it is just to remind you of what the device is. So you could have a toaster icon (graphic) actually controlling a coffee pot, the only thing that really matters is the dials on the modules and the interface codes are the same. Once you have the rooms set up with icons you like, you go to the operate mode. This is where you program the interface to come on or off at specific times of days. You can set it to go on NOW, which turns it on immediately. OFF immediately, ON TODAY, OFF TODAY, ON/OFF SPECIFIC DAYS, ON/OFF EVERYDAY. And this is the beauty of the system, you can have your house have a "lived-in" look even though it isn't. With SPECIFIC DAYS and EVERYDAY modes, you can set a security mode. This means that if you set something to come on at 5:00pm, it would come on between 5:00pm and 5:30pm. It just picks a random time and ON (or OFF) it goes. The interface is very versatile and you can enter numerous ON and OFF times, so for instance, if you have kids that forget to turn off the lights you can have them go off-only at designated times, the same goes for ON. Now this is why this system shines over others, when you aredone programming you unplug the interface from the computer! It does not tie the computer up. You only use the computer to program the interface. Afterwards it runs completely on its own. The interface will handle up to 128 timed events, which means if you were controlling a Christmas light setup, and you were changing the lights every minute (the closest span that you can program a timed event) you could have over 2 hours of automatic control. I should mention that it does not make any difference how many modules have been setup to go on or off for one particular time (up to 16 modules). It would still be considered one time event (ex. modules A1, A4, A7, and A15 programmed to go on at 70% brightness on Mondays, Wednesdays, and Fridays at 7:30 p.m. is just one event). Also, you can only set brightness for a lamp module with the interface hooked up to the computer to send the commands manually, or as a pre-programmed event. So, if you just hit one of the rocker keys or turn the lamp on, off, and back on (the module will sense this and turn on), the lamp will just come on full. AFTER PROGRAMMING IS COMPLETE And after you get the interface all programmed just the way you want it-the power fails and you loose your entire program. Well, if you have a 9 volt battery installed the program would have been safe. The battery can hold the memory of the interface for 10 hours (or so). And it is a good precaution, the only problem might be to forget it is in there and after a few years, the battery leaks. But that applies to any battery-powered device. There is also the option to save the entire contents of the interface to disk. This is available as a separate program on the disk, and it saves the interface data as a file to the disk. Three saves can be on the disk at one time, and if you need more just copy the disk, it is not protected. One of the greatest benefits of this feature is the ability to swap setups in and out so you can have one for different times of the year. For instance you could save your Christmas light setup to disk and next year get out the same setup and save yourself a lot of time in programming. If you have a elaborate house setup that takes 20 minutes or more to program. It is great to be able to load the settings back in a minute or so! Another good reason for having a backup is because the interface can "lock-up" and you must remove the battery and unplug it to reset it. This of course causes the program to be lost so having a backup is necessary in this case, otherwise you have to reprogram it. I have had it happen once, but I was moving the interface. I think that the battery lost contact momentarily while I was moving it to another room and caused a "lock-up" to occur. But I had just done a backup so nothing was lost. Power failures have different effects on the modules as well. The appliance module will stay in the same position (they have a latching mechanical relay type switches) as it was before the outage. Where as, the lamp modules will be off after a power failure (they have a triac for dimming), no matter what state the module was in before the failure. HARDWARE There are a lot of clones on the market, and they all appear to be compatible. X-10 was the first, but other places such as Radio Shack has both the interface, modules, and other addons for the system. But in the case of Radio Shack's interface, it is missing a very important feature (at least in my opinion): no manual rocker keys! Other than that, I don't know of any differences between the systems. ** Just as this issue of disC=overy was going to press, I found out that X-10 manufactures all the clones themselves! The differences are minor and limited to cosmetic changes as the example listed above. The equipment is long lasting (people have had the system in place for over 20 years). But of course if you have a lightning strike I would not expect them to survive, and don't try to put a surge suppressor on them either. Most filter the lines and will block any signals going out or coming in to the attached equipment. And a plug-in intercom system or baby monitor will interfere with the signals if they happen to be sent at the same time as the intercom is on. In short this system is MUCH easier than running cabling all over your house, and much cheaper. You can get the interface and 4 modules for around $100. And if you want to control a chandler or other such lighting fixture, just replace the switch with an X-10 controllable switch, and the same applies for outlets. And replacing them is very easy, and can be done in an afternoon (unless you are doing an entire mansion). Just make sure to turn off the power at the breaker!!!! Other addons for X-10 include entire alarm systems, motion sensing flood lights, emergency dialer (dial for assistance when you push the remote control), telephone responder (remote control your home while you are away), and many other interesting products. There have been some interesting uses I have heard of for the X-10 system. Like, magicians using it in there act, remote control lighting for underground cavetours, and lighting control for chicken farms to fool the chickens into laying more eggs. And many others, this proves that is no limit to what the system can do if you put your mind to it. TECHNICAL SEPCIFICATIONS The processor is in the interface is a 80C48. And I mentioned before a maximum of 256 modules with a maximum of 128 timed events. The transmissions are complex and are sent twice for verification and basically the signals involve short RF burst which represent digital information. The transmissions are synchronized to the zero crossing point of the AC power line. The goal is to transmit as close to zero crossing point as possible, but certainly within 200 microseconds of the crossing point. A Binary 1 is represented by a 1 millisecond burst of 120 kHz at the zero crossing point, and Binary 0 by the absence of 120 khz. And the instructions to the module is sent with those two signals (as is all computer information). The complete code transmission involves eleven cycles of the power line. The different cycles represent different commands to the module. Such as the first two cycles represent start, next four represent the House Code and the last five represent either a Number Code (1 thru 16) or a Function code (ON, OFF, etc). The programming manual is reproduced below with permission and for the edification of the reader. -- [Ed. Note : Portions of the technical information below require some basic understanding of signal theory and electronics.] INTRODUCTION Software is required to use your computer to program the X-10 Home control Interface. The interface is packaged with software and connecting cable for either IBM PC, Apple Macintosh, Apple IIe/IIc or Commodore 64/128. THAT'S ALL YOU NEED. A utility program of Basic statements is included with the Home Control Software for IBM, Apple IIe/IIc and Commodore Computers. These Utility programs let you write your own programs in Basic. For more advanced programming you may also need to refer to this programing guide. This programing Guide is for advanced programmers who wish to write their own software using Machine code and need information than is supplied in the owner's manual which comes with the X-10 Home Control Software. If you do NOT intend to write your own software, don't be intimidated by this programming guide- you don't need it. The Interface must be connected to your computer for programming but once programmed it can be disconnected and will continue to send commands to the X-10 Modules under time control. The Main functions of the Interface are summarized as follows. *Maintains a real time clock *Stores the timed events relating to control of lights and appliances in the home. *Stores the graphics data required by the computer to display the details of lamps and appliances installed into the house by the user. *Transmits X-10 Control Signals onto existing house wiring to control lights and appliances connected to the X-10 Modules. A 9volt Alkaline battery will provide approximately 100 hours back up for the Interface clock and stored data. When the Interface is running on battery power, the L.E.D. pulses approximately once every 5 seconds. Up to 128 timed events + 256 ICONS (Graphical pictures of lights and appliances) can be stored in the Interface. A timer event is any number of unit codes on the same Housecode programmed to go on or off at a particular time at a specified brightness level on any day or days of the week. (E.G. Modules A1, A4, A7 and A15 programmed to go on at 70% brightness on Mondays,Wednesdays and Fridays at 7:30 P.M. is just one event and 128 events can be stored.) The Interface has 8 rocker keys to give manual control of unit codes 1 thru 8 onthe Base Housecode. Base Housecode is set to "A" on power up but can be changed by the software. PROGRAMMING The Interface is programmed to recognize 8 different types of instruction for the computer and each instruction has an ID number between 0 and 7. Each instruction from the computer has a leading SYNC pattern of 16 x FF bytes. The ID number tells the Interface what type of data to expect and a check sum is maintained which is compared with the last byte of data in the instruction. If the check sums agree, the Interface will acknowledge back to the computer and obey the instruction. It is suggested that if no response to an instruction is received within 10 seconds, the computer should advise the user of potential problem with the connections to the Interface. (E. G. the program could display a message such as "Error check Interface connections. Press Enter to continue".) The Interface is programmed via the 5 pin DIN socket on the back of the Interface. The pin connections are shown below. Looking at Back of Interface 5 1 4 2 3 Pin Description 1 - 2 Receive (Input) 3 Ground 4 Transmit (Output) The input signals from the computer (receive data input) are connected between pins 3 and 2. The output signals to the computer (transmit data output) are connected between pins 3 and 4. A data cable is available for IBM, Macintosh, Apple IIe, and Commodore 64/128 and is included with the Interface and software for these computers. Voltage levels meet RS-232 specifications and the data format is RS-232 with the following characteristics. Baud rate: 600. Data bits: 8. Parity: None. Stop bits: 1. BYTE FORMAT Start Stop Bit D0 D1 D2 D3 D4 D5 D6 D7 Bit V+ --- --- --- --- ! 0 ! 1 ! 0 1 1 1 ! 0 ! 1 ! 0 ! 1 V- --- --- ----------- --- --- 1011 D D0 to D3 1010 5 D4 to D7 Dec = 93 Hex = 5D 0 = Mark 1 = Space A gap of 1 Millisecond should be left between each byte of data sent. A start bit signifies that a string of 8 data bits will follow. A start bit is always a SPACE bit, i.e. "0". A stop bit signifies that the data is finished and separates one byte from another. A stop bit is always a MARK bit, "1". DOWNLOAD BASE HOUSECODE When the Interface is first powered up, the Base Housecode is set to "A". To change this you must first send a leading SYNC pattern of 16 x FF bytes to the interface, followed by the identifier "0" for "download base Housecode" and then of data, the upper nibble of which contains the Housecode information. See below. BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 Sync, 16 X FF 17 0 0 0 0 0 0 0 0 ID 0, download Base Housecode 18 ---HOUSECODE------------- 0 0 0 0 See table 1. TABLE 1 House Byte 18 House Byte 18 House Byte 18 A 60 B E0 C 20 D A0 E 10 F 90 G 50 H D0 I 70 J F0 K 30 L B0 M 00 N 80 O 40 P C0 Base Housecode is used by the rocker keys on the Interface. Changing the Base Housecode will reset all timer events and graphics data stored in the Interface, therefore before downloading a new Base Housecode to the Interface, the program should warn the user of this. (E.G. the program could display "Warning changing Base Housecode will erase all program information. Continue with change yes/no".) After a successful download, the Interface will acknowledge by sending the "ACK" message to the computer. ACK MESSAGE Byte D7 D6 D5 D3 D2 D1 D0 1-6 1 1 1 1 1 1 1 FF X 6 7 0 0 0 0 0 0 S Status The STATUS bit is reset to "0" during power up of the Interface and is set to "1" by a download of data from the computer (any data with byte 17 equal to ID 0, 1, 2, or 3). The STATUS bit is used to warn the computer that the Interface has been powered down. E.G. a STATUS bit equal to "0" could tell the program to display a message such as "The Interface has been powered down and contains no data. Press Enter to continue". DIRECT COMMAND (instant ON or OFF) To turn something ON or OFF or adjust the brightness level of a light instantly,m it is first necessary to send a leading SYNC pattern of 16 x FF bytes of data to the interface. This is then followed by the identifier "1" for "direct command" and then 4 bytes of data followed by a check sum. The check sum is the sum of bytes 18 through 21. See below. BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 SYNC FF x 16. 17 0 0 0 0 0 0 0 0 ID1, Direct command. 18 LEVEL FUNCTION See notes 1 and 2. 19 HOUSECODE 0 0 0 0 See table 1. 20 9 10 11 12 13 14 15 16 Bit mapped unit codes. 21 1 2 3 4 5 6 7 8 X-10 Modules. 22 CHECK SUM Sum of bytes 18-21. NOTE 1 "LEVEL" is dimmer settings for lamps. This applies only to X-10 Lamp Modules and Wall Switch Modules. Level F Hex is full DIM and level 0 Hex if full BRIGHT. The lamps specified by bytes 20 and 21 will switch on, adjust to full brightness and then DIM to level specified by the upper nibble of byte 18. All codes between 0 Hex and F Hex are acceptable thus providing 16 discrete light levels. NOTE 2 D3 D2 D1 D0 Function Explanation 0 0 1 0 ON Modules with house codes as specified by upper nibble byte 19 and unit codes as specified by bytes 20 and 21 will turn on. 0 0 1 1 OFF As above, except turn OFF. 0 1 0 1 DIM Lamp Modules and Wall Switch Modules addressed as above will turn on, adjust to full intensity and then DIM to the level specified by upper nibble of byte 18. Appliance Modules do not respond to bright and dim codes. NOTE 3 If the check sum is accepted, the Interface will send the ACK response to the computer and will then transmit the X-10 codes onto the house wiring. When the power line transmission is complete the command is uploaded to the computer (see command upload). Also, if X-10 codes are transmitted by pressing the keys on the Interface, at the end of each transmission the codes are uploaded to the computer. This allows the computer to keep track of the ON/OFF status of the Modules while it is connected to the Interface. DIRECT COMMAND EXAMPLES Example 1: Turn ON modules A1 and A4 Bytes: 1-16 17 18 19 20 21 22 Data: FF 01 02 60 00 90 F2 Example 2: Turn OFF modules A1 and A4 Data FF 01 03 60 00 90 F3 Example 3: Turn on lamp module B9 and DIM to 50% Data FF 01 75 E0 80 00 D5 Example 4: Turn OFF all modules with housecode A Data FF 01 03 60 FF FF 61 COMMAND UPLOAD (Interface to Computer) This follows every transmission of X-10 onto the power line either from pressing the rocker keys, or from direct commands, or from timed events. This enables the computer to keep track of the ON/OFF status of lights and appliances. Byte D7 D6 D5 D4 D3 D2 D1 D0 1-6 1 1 1 1 1 1 1 1 FF X 6. 7 0 0 0 0 0 0 0 0 Status. 8 HOUSECODE FUNCTION See note 4 below. 9 9 10 11 12 13 14 15 16 Bit mapped unit codes of 10 1 2 3 4 5 6 7 8 X-10 Modules. 11 BASE HOUSECODE 0 0 0 0 Same as table 1. 12 CHECK SUM Sum of bytes 8-11. NOTE 4 -House code same as table 1. Function same as note 2, except that the code for DIM is UPLOADED to the computer as 0100 (4hex). SET CLOCK (Computer To Interface) To set the clock in the Interface it is first necessary to send a leading SYNC pattern of 16 X FF bytes of data. This is followed by the identifier "2" for set clock and then 3 bytes of data followed by a check sum. This check sum is the sum of bytes 18 thru 20. See below. Byte D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 SYNC 16 X FF. 17 0 0 0 0 0 0 1 0 ID2, set for clock. 18 0 0 MINUTES HEX 00 to 3B (0 TO 59). 19 0 0 0 HOURS HEX 00 to 17 (0 TO 23). 20 0 Sun Sat Fri Thu Wed Tue Mon Bit mapped Days. 21 CHECK SUM Sum of bytes 18 to 20. SET CLOCK EXAMPLES EXAMPLE 1 To set clock to 9:30 a.m. on Monday. BYTE 1-16 17 18 19 20 21 DATA FF 02 1E 09 01 28 EXAMPLE 2 To set clock to 7:45 p.m. on Friday. BYTE 1-16 17 18 19 20 21 DATA FF 02 2D 13 10 50 TIMER EVENT OR GRAPHICS DATA DOWNLOAD (Computer to Interface) To download either a timed event or graphics data you must frist send a leading sync pattern of 16 X FF bytes. The ID. (Byte 17) is 3 HEX for both timer events and graphics data but D2 in Byte 19 is a "0" for timer events and a "1" for graphics data. Timer events are stored in bytes 0 to 1023 of the 2k X 8 RAM in the interface. Only bytes 20 to 27 of the downloadable message are stored. Each event (group of 8 bytes) is assigned a Start Address in the RAM in the Interface. This Star Address is specified by A0-A4 in Byte 18 and A5-A6 in Byte 19. D0, D1, and D2 in byte 18 must ALWAYS be 0, so that the Start Addresses increase in multiples of 8 (0, 8, 16, .... 1016). The computer should keep track of the event Start Addresses and load new events into vacant address locations in RAM. Byte 20 designates the type of timer event as shown in table 4. Bytes 21 through 23 set the time and day of the event. Bytes 24 and 25 specify which Modules will be controlled and byte 26 specifies the Housecode of these Modules. Byte 27 specifies whether the Module(s) will turn ON, OFF, or DIM and to what brightness level. Byte 28 is the sum of bytes 20 to 27. TIMER EVENT DOWNLOAD BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 SYNC 16 X FF 17 0 0 0 0 0 0 1 1 ID3, event/graphics download. 18 A4 A3 A2 A1 A0 0 0 0 A0 to A6 binary coding of 19 x x x x x 0 A6 A5 event number. 20 0 0 0 0 MODE See table 4. 21 0 Sun Sat Fri Thu Wed Tue Mon Bit map of days. 22 0 0 HOUR HEX 00 to 17 (0 to 23). 23 0 0 0 MINUTE HEX 00 to 3B (0 to 59). 24 1 2 3 4 5 6 7 8 Bit map of unit codes. 25 9 10 11 12 13 14 15 16 Bit map of unit codes. 26 HOUSECODE 0 0 0 0 Same as table 1. 27 LEVEL FUNCTION Same as Notes 1 and 2. 28 CHECKSUM Sum of bytes 20 to 27. X=DON'T CARE TABLE 4 - TIMER MODE SELECTION BYTE 20 lower nibble D3 D2 D1 D0 MODE EXPLANATION 1 0 0 0 NORMAL Occurs on a weekly cycle at the same time each day, on day or days specified by byte 21 and at the time specified by bytes 22 and 23. The function and codes for event are specified by bytes 24 to 27. 1 0 0 1 SECURITY Same as NORMAL mode except that the event time will be different each day and will be within one hour after the time specified by byte 22. (varies in a pseudo random pattern). SECURITY is only available in EVERYDAY and SPECIFIC DAYS modes, see note 5. TABLE 4 - TIMER MODE SELECTION BYTE 20 lower nibble D3 D2 D1 D0 MODE DESCRIPTION 0 1 0 0 TODAY EVENT occurs only TODAY at the time specified by bytes 22 and 23. and will be cleared from memory at midnight TODAY. 0 0 1 0 TOMORROW EVENT occurs only TOMORROW at the time specified by bytes 22 and 23. and will be cleared from memory at midnight TOMORROW. 0 0 0 0 CLEAR Clears from memory, the event specified by the event number stored in bytes 18 and 19. NOTE 5 In addition to TODAY and TOMORROW, it is suggested that the program offer the user the choice of EVERYDAY and SPECIFIC DAYS. If EVERYDAY is chosen, byte 21 should be sent as 7F HEX (all days selected). If SPECIFIC DAYS is chosen, byte 21 should indicate which days were chosen. GRAPHICS DATA DOWNLOAD Graphics data is stored in bytes 1024 to 1535 of the 2K x 8 RAM in the interface. Only bytes 20 and 21 of the downloaded message are stored. Each pair of bytes is assigned a number between 0 and 511 as specified by A0 to A6 in byte 18 and A7 in byte 19. D0 in byte 18 is ALWAYS '0' so these address numbers increase in steps of 2 (for graphics type and X-10 code of 256 objects). Note also that byte 19 D1 is ALWAYS "0" and D2 is ALWAYS "1". The computer should keep track of the message numbers and load new messages into vacant address locations. The contents of bytes 20 and 21 depends on the graphics approach used by the programmer (see note 6), the interface merely stores this data and will upload it to the computer upon request (see graphics upload). Byte 22 is the sum of bytes 20 and 21. GRAPHICS DATA DOWNLOAD BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 Sync 16 X FF 17 0 0 0 0 0 0 1 1 ID3, event/graphics download. 18 A6 A5 A4 A3 A2 A1 A0 0 A0 to A7, binary number for 19 X X X X X 1 0 A7 graphics object- 256 objects. 20 GRAPHICS DATA User RAM to define type and 21 GRAPHICS DATA X-10 code of graphics object. 22 CHECK SUM Sum of bytes 20 and 21. X= DON'T CARE Note 6 A suggested allocation for byte 20 is shown below. BYTE 20 D7 D6 D5 D4 D3 D2 D1 D0 1=ON ICON TYPE 0=OFF FOR EXAMPLE ICON of a lamp shown in the ON state. 1 0 0 0 0 0 0 1 ICON of a T.V. shown in the ON state. 1 0 0 0 0 0 1 0 ICON of a coffee pot shown in the ON state. 1 0 0 0 0 0 1 1 ICON of a fan shown in the OFF state. 0 0 0 0 0 1 0 0 Byte 20 = 0 indicates a vacant ICON storage location. To clear an ICON from the Interface you need to send a graphics download with byte 20 = 0. Note, after doing this, you should also send a DOWNLOAD TIMER EVENT message with byte 20 = 0 (to clear any timed events for the removed ICON). A suggested allocation for byte 21 is shown below. BYTE 21 D7 D6 D5 D4 ! D3 D2 D1 D0 HOUSECODE OF ! UNIT CODE OF STORED ICON ! STORED ICON REQUEST CLOCK AND BASE HOUSECODE (Interface to Computer) To upload the time and Base Housecode from the Interface it is first necessary to send a leading SYNC pattern of 16 X FF bytes, followed by an ID4 for the request clock and Base Housecode. See below. BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 SYNC FF X 16 17 0 0 0 0 0 1 0 0 BASE Housecode. If the Interface receives the request correctly it will respond by uploading the clock and Base Housecode to the computer, as shown. If the request is not received correctly, no response is given. CLOCK AND BASE HOUSECODE UPLOAD Byte D7 D6 D5 D4 D3 D2 D1 D0 1-6 1 1 1 1 1 1 1 1 SYNC 6 X FF 7 0 0 0 0 0 0 0 S status bit. * 8 0 0 MINUTES HEX 00 to 3B (0 to 59) 9 0 0 0 HOURS HEX 00 to 17 (0 to 23). 10 0 Sun Sat Fri Thu Wed Tue Mon Bit mapped days. 11 BASE HOUSECODE 0 0 0 0 Same as table 1. 12 CHECK SUM Sum of bytes 8 to 11. * The STATUS bit is reset to "0" during power up of the Interface and is set to "1" by a DOWNLOAD of data from the computer (any data with byte 17 equal to ID 0 , 1, 2, or 3). The STATUS bit is used to warn the computer that the Interface has been powered down. E.G. a STATUS bit equal to "0" could tell the program to display a message such as "The Interface has been powered down and contains no data. Press Enter to continue". REQUEST TIMER EVENTS (Interface to Computer) To upload the timer events from the Interface it is first necessary to send a leading SYNC pattern of 16 X FF bytes, followed by an ID5, for request timer events. See below. BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 1 SYNC FF X 16 17 0 0 0 0 0 1 0 1 ID5, request timer events. The Interface will respond by uploading to the computer, all of the 128 events starting with number 1 as shown below. A vacant event is represented by a single FF byte, this shortens the time for the upload. The check sum does not include these FF bytes. TIMER EVENTS UPLOAD EXAMPLE WHERE ONLY FIRST TWO EVENTS ARE PROGRAMMED BYTE D7 D6 D5 D4 D3 D2 D1 D0 16 1 1 1 1 1 1 1 1 SYNC FF X 6. 7 0 0 0 0 0 0 0 0 Status. 8-15 EVENT NUMBER 1 AS DOWNLOADED, 8 BYTES. 24-149 1 1 1 1 1 1 1 1 FF X 126 to indicate 126 vacant event spaces. 150 CHECK SUM Sum of bytes 8 to 23 (FF bytes ignored). REQUEST GRAPHICS DATA (Interface to Computer) To upload graphics data from the Interface it is first necessary to send a leading SYNC pattern of 16 X FF bytes followed by and ID6, for request graphics data. See below. BYTE D7 D6 D5 D3 D2 D1 D0 1-16 1 1 1 1 1 1 1 SYNC FF X 16 17 0 0 0 0 1 1 0 ID6, request graphics data. The Interface will respond by uploading to the computer, all of the 256 ICONS starting with number 1, as shown on page 33. A vacant ICON space is represented by a single FF byte, this shortens the time for the upload. The check sum does not include these FF bytes. GRAPHICS DATA UPLOAD EXAMPLE WHERE ONLY 5 ICONS ARE PROGRAMMED BYTE D7 D6 D5 D4 D3 D2 D1 D0 1-6 1 1 1 1 1 1 1 1 SYNC FF X 6. 7 0 0 0 0 0 0 0 0 Status. 8-9 ICON NUMBER 1 2 bytes. 10-11 ICON NUMBER 2 2 bytes. 12-13 ICON NUMBER 3 2 bytes. 14-15 ICON NUMBER 4 2 bytes. 16-17 ICON NUMBER 5 2 bytes. 18-268 1 1 1 1 1 1 1 1 FF X 251 to indicate 251 vacant ICON spaces. 269 CHECK SUM Sum of bytes 8 to 17 (FF bytes ignored). DIAGNOSTIC The Interface has a self test diagnostic routine which is initiated by sending a leading SYNC pattern of 16 X FF bytes followed by a ID7. Upon receiving this instruction, the Interface will run a self check on it's own hardware and software (firmware). The output of the Interface (pins 3 and 4) will go low for 10 seconds as part of this test. If the check is o.k. the Interface will respond by sending the ACK with status "0". If a fault is diagnosed, the interface will Send ACK with status "1" or will not respond. BYTE D7 D6 D5 D4 D2 D1 D0 1-16 1 1 1 1 1 1 1 SYNC FF X 16 17 0 0 0 0 1 1 1 ID7, initiate self test. The above programming guide is included when you purchase the interface. I checked and it is freely distributable. And remember, if you don't want to control more than 95 modules, you don't need to create your own program (as stated previously. If you want to read further on the X-10 system, then go to there web page at http://www.x10.com. They have information on all the products they carry, as well as ones still in the works. Also on the web page is a FAQ (Frequently Asked Questions) file that has a wealth of information on the X-10 system and compatible products. Unfortunately, the interface is no longer sold packaged with the Commodore cable and software. So, you must purchase the interface packaged with some other software and call X-10 and order the Commodore connection package separately for $25. Of course you can create a cable and copy the software (it is also freely distributable) if you wanted to. To get the interface and any modules or compatible products, Home Controls has a great selection, and there catalogue is filled with home automation equipment. X-10's and Home Controls addresses and phone numbers are as follows: X-10 (USA) INC. 91 Ruckman Rd. Closter, NJ 07624 Phone: 201-784-9700 Home Controls INC. 7626 Miramar Road, Suite 3300 San Diego, CA 92126-4446 Phone: 800-266-8765 or 619-693-8887 :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: \H02::::::::::::::::::::::::::H:A:R:D:W:A:R:E::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: !......The Metal Shop......! // - The Metal Shop - // ^...!..The Metal Shop..!...^ Contributors : XmikeX (xmikex@eyrie.stanford.edu) Co-Sysop of DiamondBack BBS (305)258-5039 David Wood (jbevren@willowtree.com) Marc-Jano Knopp and Daniel Krug http://www.student.informatik.th-darmstadt.de/%7Emjk/c64.html Dear Metal Shop, I recently found a 16 KB Commodore expander for my trusty VIC-20. My glee turned to disgust after realizing that I needed the proper DIP scheme required to bank the memory into the VIC. I barely know the old '20, much less this expander. Please tell me this will be easy.... :) RE -- RE, You are in luck RE because as the Good Lord would have it, I have also run into a VIC-20 expander! Ok...I didn't just "run" into it... I actively sought one out to view the new Veni Vedi Vic (Vedi Veni Vic?) demo by Marko Makela (with umlauts over the a's). :) And oh Yes, this will be easy! Without much further ado, I decoded the DIP scheme for my 16 KB VIC-20 expansion cartridge, as follows : CBM VIC-1111 16 KiloByte RAM expansion cartridge with eight DIP scheme ---------------------------------------------------------------------- Expansion RAM bank 1 Expansion RAM bank 2 (8 KB) (8 KB) 8 KB Mapped to : 1 2 3 4 5 6 7 8 on off off off -> $A000-RAM/ROM4 <- on off off off off on off off -> $6000-RAM/ROM3 <- off on off off off off on off -> $4000-RAM/ROM2 <- off off on off off off off on -> $2000-RAM/ROM1 <- off off off on As is evident above, the DIP settings for each bank yield identical results so I suspect that the settings for the 8 KB CBM ram expander follow the same scheme. 8 KB chunks do keep things simple, and we can either give the VIC-20 just 8 KB of expansion memory at $2000, $4000, etc., or we can activate both banks and map them to these RAM/ROM expansion blocks within the VIC's memory map for 16 KB total. For example, whereas 8 KB ROM images are usually quite happy with 8 KB of memory at RAM/ROM4, most 16 KB rom images tend to require that RAM/ROM blocks 3 and 4 be active. We can accomplish this by mapping expansion bank 1 into $6000 and bank 2 into $a000 (or vice versa!). In this case, our DIP settings could be : 1 2 3 4 5 6 7 8 off on off off on off off off OR on off off off off on off off Please note that with the CBM 16k expander, we cannot map any of its memory to the 3 KB expansion area sitting at $0400-0fff (1024-4095). - XmikeX -- [Ed. Note : The following is a response to the 1541 <-> Apple disk ][ discussion that appeared in this column, issue 2. It has been reprinted in its entirety with permission from the author.] From : jbevren@willowtree.com Date : 19-JAN-1997 08:58:43.19 Subject : info on 1541/disk ][ transfers First: Thank you disC=overy magazine. I've read a few zines, and only yours and C= Hacking make the bet for me. Keep up the _good_ work! Dear Metal Shop, I was reading the article in the disC=overy magazine, issue two. In there was a section from a user who has an Apple ][ computer who wished to transfer files from the computer's disk drive to the Commodore 1541 (or was it vice-versa?). I am commenting on the hardware aspect of the disk ][ drives on the Apple computer. When I was in college, my 1541 failed completely due to lightning. The main board was fine, but the read/write head was blown "open" as I discovered in the school's electronics lab. Remembering my days on the ol' ][ in high school, I thought of hooking a disk ][ assembly to the 1541 board. I acquired a junk drive assembly from a friend, unhooked all the electronics, and re-wired the assembly to the 1541 drive's CPU board. Voila! The system ran fine, until I could come up with a low-density single-sided assembly from a PC to fit "inside" the 1541's case. It even ran fastloaders and GEOS. Point at hand? The disk ]['s mechanical assembly is functionally identical to the 1541's drive assembly. In fact, the Alps assembly was used in some Apple compatible drives (am I right?). Reading Apple disks on the 1541 will be one hell of a challenge, because of the drive's limited RAM. However, reading Commodore's GCR format should be fairly easy if you have a little advanced knowledge of the disk ][ interface. All you have to do is get a modified CBM DOS binary into the Apple ][, and have it read the Commodore disk. Not a trivial task mind you. When the DOS is in the Apple, the rest is easy. simply change the locations the program uses to read/write the disk, and you have it. Hope I was helpful! -David Wood ps: All the disk ][ is (with the interface included), is a 1541 with no brains. :) -- [Ed. Note : The text below to the end of the article is a sample of the C= hardware repair and enhancement projects put out by Marc-Jano Knopp & Daniel Krug on the WWW http://www.student.informatik.th-darmstadt.de/%7Emjk/c64.html Reprinted with permission.] SAFER SID! Project: Protection circuit for SID Target : C64 (all models) Time : 20 min Cost : ~1 US$ Use : Protect the SID from overvoltage. Cause The SID cannot stand more than 3Vss or 1Veff, respectively. Therefore, if you use the SID audio input, the input voltage should be limited. The circuit below limits the input signal to about 1.4Vss. This is done by two antiparallel silicon diodes which cut off the signal at +/- 0.7V. The resistor limits the current coming out of the audio source. Ingredients - 1 resistor 470 ohm - 2 diodes 1N4148 (or 1N914) Instructions 1. Build the following circuit: SID protection circuit ---------------------- (5) O---------o----------o-------XXXXX-----O Audio in | | | | __ +-----+ ----- / \ <-- to SID \ / / \ <-- -+----+----+- \ / / \ \__/ ----- +-----+ | | (2) O---------o----------o-----------------O GND XXXXX = resistor 470ohm diodes = 1N4148 or 1N914 2. ... and stuff it in a DIN plug for the AV jack. SPONTANEOUSLY RESETTING C-64? Symptom: C-64 resets at random. Target : C64 (all models) and VC20 Time : 10 min. Cost : <1 US$ Cause Voltage level floats near to forbidden zone (unstable voltage below ~4 volts). Fix Pull-up resistor between pin 3 (/RESET) and pin 2 (+5V) of user port. Value should be in the range of 4.7k to 10k, starting with 10k. Note C-64s which are used industrially, should be equipped with an additional 100nF capacitor connected between pin 3 (/RESET) and GND (pin 1), which provides excellent noise immunity. The same applies to users encountering reset problems due to a long reset switch cable. Ingredients - resistor of 10k (or less) Instructions 1. Open case, disconnect power plug! 2. Solder one end of resistor to pin 2 the other end to pin 3 of the user port connector. DO NOT solder the leads directly onto the contact area, instead try soldering them to the nearest visible bare point connected to the above pins. 3. Connect power plug and keep your C-64 running for several hours. See if it resets spontaneously as before; if not, close the case again. Possible failures - Resistor's value is too high, try 5.6k or 4.7k otherwise. 'FIX' RESTORE KEY! Project: Make RESTORE key behave like all the other keys Target : C64 (old) Time : 15 min. Cost : <1 US$ Use : Never hear the RESTORE key singing 'Killing me softly ...' again. Extract Replace 'NMI-capacitor' C38 by a 4.7nF one. Cause The value of the built in capacitor responsible for triggering the NMI via the timer 556 is too small in old C-64's (big PCB). On account of the pressure dependant resistance of the keys, pressing the RESTORE key just as softly as the other keys is not sufficient for producing a trigger signal at the timer's TRIG input. Therefore, we will replace it with a 4.7nF capacitor. The problem described above was fixed in the new (small) PCB's and in the SX-64. Ingredients - 1 capacitor 4.7nF Instructions 1. Open case, disconnect power plug! 2. Search for capacitor C38 (51pF) below the leftmost CIA. In most boards it is built into a resistor case with green base color! Its color code is: green-brown-black 3. Unsolder it and replace it with the 4.7nF one. 4. Connect power plug. 5. Switch your C-64 on. After the startup screen appeared press [STOP]-[RESTORE] just as softly as you would usually hit the other keys. Repeat that procedure a few times and if the RESTORE key seems to behave like the other keys, close the case again. Possible failures - Replaced the wrong capacitor. Often the capacitor is built into a resistor case. BLACK SCREEN Symptom: Screen remains black. Target : C-64 Possible sources of failure - Power supply's fuse is blown -> no power :) - continuous reset -> no startup - Fuse -> no 12V for VIC (old C-64) - Voltage regulator -> no 12V, no fun (old C-64) - CPU -> blocks phi2 or bus - VIC -> blocks bus - SID -> blocks bus - PLA -> well.... :) - 8701 -> no clock cycles Analysis - Power supply ok? If the power LED is not lit, check the power supply's fuse and replace it, if necessary. Next, measure the voltage directly on the power plug. If you cannot find 5VDC and 9VAC anywhere, kick the power supply and get a new one. If you have an old C-64, check its internal fuse now. Then check the 5V at the power jack (before the switch!) with the power supply plugged in and the C-64 switched on. It should be between 4.9 and 5.1V. If not, a defective IC might demand a current so high that the 5V level gets pulled below 4.8V. You should be able to locate the very IC by simply touching all the chips and checking for especially hot ones. Replace it. Next, measure the 5V supply voltage between pin 7 (GND) and pin 14 (Vcc) of a 74xx chip. If the 5V show to be ok, then continue with 'Voltage regulator ok?'. Otherwise, it is very likely that the cause for the low vol- tage level is - believe it or not, it DID happen to a lot of people - the power switch(!), so that it could be a good idea to either rock the switch several dozen times, open and clean it or to replace it completely. Reset line HIGH? Since it is possible that the black screen is caused by a con- tinuous reset, you should check the voltage between pin 1 (GND) and pin 3 (/RESET) of the user port. If it is below 1V, then check the reset switch, if you got one. Otherwise, check wether the output levels of the 7406 and 74LS14 (new board) match their input levels. Next, you should check the timer 556 (old board) when I managed to offer you a description for that chip :) Until then, simply replace it, it is not socketed, but cheap. If that does not help, some other chips load the reset line so that the level is below 2.4V which causes the CPU to reset. Try a pull-up resistor (4.7k) between pin 2 (+5V) and pin 3 (/RESET) of the user port. If that does not make the blank screen vanish, check for other defective chips (which probably become very hot, see later in this document). Voltage regulator ok? In case you have an old C-64, check the 12V voltage regulator VR1 (7812). At the output (right pin, 2) you should measure around 12V (11.8 to 12.3V). If not, measure the input voltage (left pin, 1), the voltmeter should show about 15 to 20V. If the latter is the case, replace the VR. If the input voltage is out of range, check the 9VAC on the power plug (with the C-64 still switched on). If they prove to be ok, then the two diodes before the voltage regulator could be damaged; replace them. If you cannot find the 9VAC, make sure you have checked for the C-64's internal fuse and otherwise get another power supply. CPU running? Try accessing the floppy drive by typing blindly (you do not need to close your eyes) LOAD"$",8 (assuming your device id is '8') If the floppy drive's motor starts spinning, you are lucky. The processor, the CIA's and the address manager seem to work. If the floppy does not react in any way, you probably have a serious problem and should continue reading... Other chips alive? Test VIC, SID, PLA and, where applicable, the clock circuit 8701 near the VIC (not in very old PCB revisions), whether they get extraordinaryly hot. If any of the chips gets hot, it is very likely that they are defective and, e.g. block the bus. These should be replaced. In C-64s with the new board, you will find a 64-pin multifunction chip, the MMU. If the other chips are ok, it is probably the MMU which is damaged. Alas, this MMU is prac- tically impossible to replace, there are neither suitable sockets nor spare chips. Of course, every chip connected to the bus in any way could be damaged and blocking the bus, therefore you should also check if the CIAs, the ROMs, the RAMs, the RIMs or the RUMs (oops) are getting extremly hot. Especially in the old C-64 board, the various 74xx/74LSxx might be responsible for the failure. If all else fails... ... you should consider the very low price of a used C-64 on the free market or, if you live in a strange country with prices over US$ 30 for a C-64 (including power supply), check for hair cracks and dry joints. :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: \L01:::::::::::::::::::::::::::::L:E:G:A:L:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: A R T I C L E S O F O P E R A T I O N Article 1 : Mission Statement Our intent is to present useful information in order to enhance and preserve the knowledge base of the Commodore 8-bit domain, including, but not limited to, the Commodore 64 and Commodore 128 home computers. To this end, we shall require that every article contain what in our discretion should be a viable Commodore 8-bit hardware and/or software point of relevance. Likewise, each issue should include material that can both potentially enlighten the most saavy of users as well as the layman. We intend to complement and assist all others engaged in similar endeavours. We believe it is of paramount concern to stave off entropy as long as possible. Article 2 : disC=overy Staff The current staff of disC=overy, the Journal of the Commodore Enthusiast, is as follows: Editor-in-Chief : Mike Gordillo (s0621126@dominic.barry.edu) Associate/Tech Editor : Steven Judd (sjudd@nwu.edu) Associate/Tech Editor : George Taylor (aa601@chebucto.ns.ca) Webmaster : Ernest Stokes (drray@eskimo.com) disC=overy, issue 3 logo by 'WaD' We invite any and all interested parties to join us as authors, panelists, and staff members. Article 3 : General Procedures - Submission Outline - a. Articles may range in size from 1 kilobyte and up. Approximately 15 kilobytes of text is the preferred length, including any software present. b. Sufficient technical content about Commodore 8-bit home computers, concerning software and/or hardware relevant to these systems, is a requirement. What constitutes a sufficient amount of 'technical content' is left to the discretion of the Editor-in-Chief and/or the review panel (see below). - Staff Priorities - The Editor-in-Chief shall supervise the organization of each issue in regards to grammatical and syntactical errors, flow of content, and overall layout of presentation. The Editor-in-Chief and Associate Editor shall form a review panel whose function it shall be to referee literary work which the Editor in-Chief has deemed to be of advanced technical merit. The Editor-in-Chief iand disC=overy, the Journal of the Commodore Enthusiast, shall retain copyright solely on the unique and particular presentation of its included body of literary work in its entirety. Authors shall retain all copyrights and responsibilities with regards to the content of their particular literary work. Authors shall be required to submit their works to the Editor-in-Chief approximately two weeks prior to publication. Article 4 : Peer Review To the best of our knowledge, disC=overy shall be the first Commodore 8-bit journal with a review panel dedicated to uphold the technical integrity and legitimacy of its content. The Editor-in-Chief and the Associate Editor shall be responsible for the formation of the panel. The appointed panelists shall have the option of anonymity if desired. The panel shall review works primarily for technical merit if the Editor-in-Chief and the Associate Editor deem it necessary. Authors may be asked to modify their works in accordance with the panel's recommendations. The Editor-in- Chief shall have final discretion regarding all such "refereed" articles. Article 5 : Distribution Although we welcome open distribution by non-commercial organizations, there are currently four "official" distribution channels available to interested parties. This journal may be obtained by directly mailing the Editor-in-Chief or via the World Wide Web at http://www.eskimo.com/~drray/discovery.html and at FTP site : ftp.eskimo.com - directory /u/t/tpinfo/C64/Magazines/discovery A "snail" mail disk copy of any issue of this journal may also be obtained from Arkanix Labs at the following physical address : disC=overy, c/o Jon Mines Arkanix Labs 17730 15th Ave NE Suite #229 Shoreline, WA 98155 This source should follow the distribution guidelines as listed in Article 6 below. However, specific questions concerning billing, etc., should be directed at them. Several versions of this journal may be available for your convenience, please check with the aforementioned sources. Article 6 : Disclaimers The Editor-in-Chief and disC=overy, the Journal of the Commodore Enthusiast, retain all copyrights regarding the presentation of its articles. Authors retain all copyrights on their specific articles in and of themselves, regarding the full legal responsibility concerning the originality of their works and its contents. The Editor-in-Chief and disC=overy, the Journal of the Commodore Enthusiast, grants the reader an exclusive license to redistribute each issue in its entirety without modification or omission under the following additional stipulations: - If distribution involves physical media and is part of a commercial, not-for-profit, or PD distribution, the maximum allowable monetary charge shall not exceed $4 1996 United States Dollars per issue unless more than one issue is distributed on a single media item (i.e., two or more issues on one disk), in which case maximum allowable charge shall not exceed $4 1996 United States Dollars per media item. All dollar values given assume shipping costs are -included- as part of the maximum allowable charge. - If distribution involves non-physical media and is part of a commercial, not-for-profit, or PD distribution, the maximum allowable charge shall be limited to the actual cost of the distribution, whether said cost be in the form of telephony or other electronic means. - Software included within articles (as text) may be subject to separate distribution requirements as binary executables. Please check directly with authors regarding distribution of software in binary form. - disC=overy should be distributed on per-issue basis, and any potential subscription arrangements are strictly between distributor and reader. We do not guarantee subscriptions nor do we take responsibility for distribution outside of the disC=overy home page on the World Wide Web (http://www.eskimo.com/~drray/discovery.html) It is understood that distribution denotes acceptance of the terms listed and that under no condition shall any particular party claim copyright or public domain status to disC=overy, the Journal of the Commodore Enthusiast, in its entirety. The Editor-in-Chief and disC=overy, the Journal of the Commodore Enthusiast, reserve the right to modify any and all portions of the Preamble and the Articles of Operation. :::::::::::d:i:s:C=:o:v:e:r:y:::::::::::::::::i:s:s:u:e::3:::::::::::::::::::: \END:::::::::::::::::::::::::::March 26, 1997::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::