8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / HACKING6A.SFX / hacking6a

Wrap

Text File | 1993-09-17 | 34.6 KB | 795 lines

######## ################## ###### ###### ##### ##### #### #### ## ##### #### #### #### #### #### ##### ##### ## ## #### ## ## ## ### ## #### ## ## ## ##### ######## ## ## ## ##### ## ## ## ## ## ##### ## ## ######## ## ## ## ### ## ## #### ## ## ##### #### #### #### #### ##### #### #### #### #### #### ###### ##### ## ###### ###### Issue #6 ################## Date ##, 1993 ######## ------------------------------------------------------------------------------- Editor's Notes: by Craig Taylor School, 2 jobs, a play, and other work has seriously restricted the amount of time that I am able to devote to Commodore Hacking. What I am looking at doing now is to stop writing articles for Commodore Hacking and hoping that I'll still have enough time to write these notes, and organize and pull all the other articles by other contributors together. The two articles I had hoped to include in this issue : the one about multi-tasking and about the 1351 have again been delayed. I've decided to go ahead and release issue 6 and hopefully will have them in the next issue. (Remember: You get what you pay for.. *smile*) As always, Commodore Hacking is constantly looking for articles, notes, short little programs, what-not on any side of the Commodore 64 and 128 - primarily on the technical or hardware side. If you think you have something in mind, or already written then feel free to drop me a line letting me know. In regards to several queries recently about reprinting individual articles that have appeared in Commodore Hacking. You may reprint Commodore Hacking and redistribute in whole, freely. For use of individual articles you _must_ contanct the individual author as they still retain rights to it. Please see the legal notice / mumbo below. I recently recieved some mail from wolfgang@halcyon regarding a disk magazine that he was in the process of starting and he has written the following preview of a disk magazine that looks to be exciting: "_Scenery_, a new disk-magazine focusing on the american and european demo scenes, will soon be available for download at a site/BBS near you! With articles on everything from coding to instrument synthesis to art, _Scenery_ will be the definitive word when it comes to creating a demo, or simply coding in general. Articles are being written by some of the top names in the scene, and promise to help everybody from the Basic Baby to the ML Mogul! Set to be released mid-August, _Scenery_ will hopefully be a worthy edition to the likes of Coder's World and C=Hacking. I am making the magazine available on various Internet sites, so look for it. We are always on the lookout for art, music, and coding talent, and if you'd be interested in submitting an article for publication, or simply have a question or comment, please mail me at 'wolfgang@halcyon.com'. Thanks.. and see you on the Net!" ================================================================================ Please note that this issue and prior ones are available via anonymous FTP from ccosun.caltech.edu under pub/rknop/hacking.mag and via a mailserver which documentation can be obtained by sending mail to "duck@pembvax1.pembroke.edu" with a subject line of "mailserver" and the line "help" in the body of the message. ================================================================================ NOTICE: Permission is granted to re-distrubte this "net-magazine", in whole, freely for non-profit use. However, please contact individual authors for permission to publish or re-distribute articles seperately. A charge of no greather than 5 US dollars or equivlent may be charged for library service / diskette costs for this "net-magazine". ================================================================================ In This Issue: DYCP - Horizontal Scrolling DYCP - is a name for a horizontal scroller, where characters go smoothly up and down during their voyage from right to left. One possibility is a scroll with 8 characters - one character per sprite, but a real demo coder won't be satisfied with that. Opening the borders VIC has many features and transparent borders are one of them. You can not make characters appear in the border, but sprites are displayed in the border too. 64 Documentation This file, taken directly from a Commodore 64 emulator and development system being developed is full of information about undocumented opcodes, processor timings, memory configurations and the such. A must-have reference article. A Heavy Duty Power supply for the C-64 This article describes how to build a heavier duty power supply for your Commodore 64 computer and includes a full schematic in GeoPaint format. LZW Compression LZW is perhaps the most widely used form of data compression today. It is simple to implement and achieves very decent compression at a fairly quick pace. LZW is used in PKZIP (shrink),PKARC (crunch), gifs,V.42bis and unix's compress. This article will attempt to explain how the compression works with a short example and 6502 source code in Buddy format. THREE-KEY ROLLOVER for the C-128 and C-64. This article examines how a three-key rollover mechanism works for the keyboards of the C=128 and C=64 and will present Kernal-wedge implementations for both machines. Webster's doesn't seem to know, so I'll tell you that this means that the machine will act sensibly if you are holding down one key and then press another without releasing the first. This will be useful to fast touch typers. ================================================================================ The Demo Corner: DYCP - Horizontal Scrolling by Pasi 'Albert' Ojala (po87553@cs.tut.fi or albert@cc.tut.fi)) Written: 16-May-91 Translation 02-Jun-92 DYCP - too many sprites !? -------------------------- DYCP - Different Y Character Position - is a name for a horizontal scroller, where characters go smoothly up and down during their voyage from right to left. One possibility is a scroll with 8 characters - one character in each sprite, but a real demo coder won't be satisfied with that. Demo coders thought that it looks good to make the scrolling text change its vertical position in the same time it proceeded from the right side of the screen to the left. The only problem is that there is only eight sprites and that is not even nearly enough to satisfy the requirements needed for great look. So the only way is to use screen and somehow plot the text in graphics, because character columns can not be scrolled individually. Plotting the characters take absolutely too much time, because you have to handle each byte seperately and the graphics bitmap must be cleared too. _Character hack_ The whole DYCP started using character graphics. You plot six character rows where the character (screen) codes increase to the right and down. This area is then used like a small bitmap screen. Each of the text chars are displayed one byte at a time on each six rows high character columns. This 240 character positions big piece of screen can be moved horizontally using the x-scroll register (three lowest bits in $D016) and after eight pixels you move the text itself, like in any scroll. The screen is of course reduced to 38 columns wide to hide the jittering on the sides. A good coder may also change the character sets during the display and even double the size of the scroll, but because the raster time happens to go to waste using this technique anyway, that is not very feasible. There are also other difficulties in this approach, the biggest is the time needed to clear the display. _Save characters - and time_ But why should we move an eight-byte-high character image in a 48-line-high area, when 16 is really enough ? We can use two characters for the graphics bitmap and then move this in eight pixel steps up and down. The lowest three bits of the y-position then gives us the offset where the data must be plotted inside this graphical region. The two character codes are usually selected to be consecutive ones so that the image data has also 16 consecutive bytes. [See picture 1.] _Demo program might clear things up_ The demo program is coded using the latter algorithm. The program first copies the Character ROM to ram, because it is faster to use it from there. You can easily change the program to use your own character set instead, if you like. The sinus data for the vertical movement is created of a 1/4 of a cycle by mirroring it both horizontally and vertically. Two most time critical parts are clearing the character set and plotting the new one. Neither of these may happen when VIC is drawing the area where the scroll is, so there is a slight hurry. Using double buffering technique we could overcome this limitation, but this is just an example program. For speed there is CLC only when it is absolutely needed. The NTSC version is a bit crippled, it only covers 32 columns and thus the characters seem to appear from thin air. Anyway, the idea should become clear. _Want to go to the border ?_ Some coders are always trying to get all effects ever done using the C64 go to the border, and even successfully. The easiest way is to use only a region of 21 pixels high - sprites - and move the text exactly like in characters. In fact only the different addressing causes the differences in the code. Eight horizontally expanded sprites will be just enough to fill the side borders. You can also mix these techiques, but then you have the usual "chars-in-the-screen-while-border-opened"-problems (however, they are solvable). Unfortunately sprite-dycp is even more slower than char-dycp. _More movement vertically_ You might think that using the sprites will restrict the sinus to only 14 pixels. Not really, the only restriction is that the vertical position difference between three consequent text character must be less than 14 pixel lines. Each sprites' Y-coordinate will be the minimum of the three characters residing in that sprite. Line offsets inside the sprites are then obtained by subtracting the sprite y-coordinate from the character y-coordinate. Maybe a little hard to follow, but maybe a picture will clear the situation. [See picture 2.] Scrolling horizontally is easy. You just have to move sprites like you would use the character horizontal scroll register and after eight pixels you reset the sprite positions and scroll the text one position in memory. And of course, you fetch a new character for the scroll. When we have different and changing sprite y-coordinates, opening the side borders become a great deal more difficult. However, in this case there is at least two different ways to do it. _Stretch the sprites_ The easiest way is to position all of the sprites where the scroll will be when it is in its highest position. Then stretch the first and last line of each sprite so that the 19 sprite lines in the middle will be on the desired place. Opening the borders now is trivial, because all of the sprites are present on all of the scan lines and they steal a constant amount of time. However, we lose two sprite lines. We might not want to use the first and the last line for graphics, because they are stretched. [See previous C=Hacking Issues for more information about stretching and stolen cycles.] A more difficult approach is to unroll the routine and let another routine count the sprites present in each line and then change the time the routine uses accordingly. In this way you save time during the display for other effects, like color bars, because stretching will take at least 12 cycles on each raster line. On the other hand, if the sinus is constant (user is not allowed to change it), it is usually possible to embedd the count routine directly to the border opening part of the routine. _More sprites_ You don't necassarily need to plot the characters in sprites to have more than eight characters. Using a sprite multiplexing techiques you can double or triple the number of sprites available. You can divide the scroll vertically into several areas and because the y-coordinate of the scroll is a sinus, there always is a fixed maximum number of sprites in each area. This number is always smaller than the total number of sprites in the whole scroll. I won't go into detail, but didn't want to leave this out completely. [See picture 3.] _Smoother and smoother_ Why be satisfied with a scroll with only 40 different slices horizontally ? It should be possible to count own coordinates for each pixel column on the scroll. In fact the program won't be much different, but the routine must also mask the unwanted bits and write the byte to memory with ORA+STA. When you think about it more, it is obvious that this takes a generous amount of time, handling every bit seperately will take much more than eight times the time a simple LDA+STA takes. Some coders have avoided this by plotting the same character to different character sets simultaneously and then changing the charsets appropriately, but the resulting scroll won't be much larger than 96x32 pixels. -------------------------------------------------------------------------- Picture 1 - Two character codes will make a graphical bitmap Screen memory: ____________________________________ |Char |Char |Char |Char | ... |Code |Code |Code |Code | |0 |2 |80 |80 | . | |** ** | | | . | |** ** | | | . |***** |****** | | | |****** | **** | | | |**__**_|__**___|_______|_______| |** ** | ** | **** |Char | |** ** | ** |****** |Code | |****** | |** ** |6 | |***** | |** | | |Char |Char |** ** | | |Code |Code |****** | | |1 |3 |4**** |***** | |_______|_______|_______|******_| |Char |Char | |** ** | |Code |Code | |****** | |80 |80 | |***** | | | | |** | | | |Char |**ar | | | |Code |Code | | | |5 |7 | |_______|_______|_______|_______| Character set memory: _________________________________________________________________ |Char 0 |Char 1 |Char 2 |Char 3 |Char 4 |Char 5 |Char 6 |Char 7 | ... |_______|_______|_______|_______|_______|_______|_______|_______|__ DDDDDDDD YYYYYYYY CCCCCCCC PPPPPPPP First column Second column Third column Fourth column -------------------------------------------------------------------------- Picture 2 - DYCP with sprites Sprite 0 _______________________ | |** ** | | | |** ** | | | |****** | | |***** | **** | | |****** | ** | | |** ** | ** | | |** ** | ** | | |**__**_|_______|_______| |****** | | **** | |***** | |****** | | | |** ** | | | |** | | | |** ** | | | |****** | | | | **** | |_______|_______|_______| Sprite 1 | | | | _______________________ | | | ||***** | | | | | | ||****** | | | | | | ||** ** | | | |_______|_______|_______||****** | | | |***** | | | |** | | | |** | | | |_______|_______|_______| | | | | | | | | | | | | | | **** | | | | **** | | | | |****** | | | |****** | |_______|_______|__**___| | | | ** | | | | ** | | | | ** | | | | ** | |_______|_______|_______| -------------------------------------------------------------------------- Picture 3 - Sprite multiplexing __ Set coordinates for eight sprites __|3 | that start from the top half. |4 | |__ __| `--|2 | |5 `--' | | | | `--'__ `--' |1 | | | __ `--' |6 | | | __ `--' |0 | | | -__------------------------------------`--'When VIC has displayed the last |0 | __ sprite, set coordinates for the | | |6 | sprites in the lower half of the `--' | | area. `--' __ |1 | __ | | |5 | `-- __ | | |2 | __`--' | |__|4 | You usually have two sprites that `--|3 | | are only 'used' once so that you | `--' can change other sprites when VIC `__' is displaying them. -------------------------------------------------------------------------- DYCP demo program (PAL) SINUS= $CF00 ; Place for the sinus table CHRSET= $3800 ; Here begins the character set memory GFX= $3C00 ; Here we plot the dycp data X16= $CE00 ; values multiplicated by 16 (0,16,32..) D16= $CE30 ; divided by 16 (16 x 0,16 x 1 ...) START= $033C ; Pointer to the start of the sinus COUNTER= $033D ; Scroll counter (x-scroll register) POINTER= $033E ; Pointer to the text char YPOS= $0340 ; Lower 4 bits of the character y positions YPOSH= $0368 ; y positions divided by 16 CHAR= $0390 ; Scroll text characters, multiplicated by eight ZP= $FB ; Zeropage area for indirect addressing ZP2= $FD AMOUNT= 38 ; Amount of chars to plot-1 PADCHAR= 32 ; Code used for clearing the screen *= $C000 SEI ; Disable interrupts LDA #$32 ; Character generator ROM to address space STA $01 LDX #0 LOOP0 LDA $D000,X ; Copy the character set STA CHRSET,X LDA $D100,X STA CHRSET+256,X DEX BNE LOOP0 LDA #$37 ; Normal memory configuration STA $01 LDY #31 LOOP1 LDA #66 ; Compose a full sinus from a 1/4th of a CLC ; cycle ADC SIN,X STA SINUS,X STA SINUS+32,Y LDA #64 SEC SBC SIN,X STA SINUS+64,X STA SINUS+96,Y INX DEY BPL LOOP1 LDX #$7F LOOP2 LDA SINUS,X LSR CLC ADC #32 STA SINUS+128,X DEX BPL LOOP2 LDX #39 LOOP3 TXA ASL ASL ASL ASL STA X16,X ; Multiplication table (for speed) TXA LSR LSR LSR LSR CLC ADC #>GFX STA D16,X ; Dividing table LDA #0 STA CHAR,X ; Clear the scroll DEX BPL LOOP3 STA POINTER ; Initialize the scroll pointer LDX #7 STX COUNTER LOOP10 STA CHRSET,X ; Clear the @-sign.. DEX BPL LOOP10 LDA #>CHRSET ; The right page for addressing STA ZP2+1 LDA #<IRQ ; Our interrupt handler address STA $0314 LDA #>IRQ STA $0315 LDA #$7F ; Disable timer interrupts STA $DC0D LDA #$81 ; Enable raster interrupts STA $D01A LDA #$A8 ; Raster compare to scan line $A8 STA $D012 LDA #$1B ; 9th bit STA $D011 LDA #30 STA $D018 ; Use the new charset CLI ; Enable interrupts and return RTS IRQ INC START ; Increase counter LDY #AMOUNT LDX START LOOP4 LDA SINUS,X ; Count a pointer for each text char and according AND #7 ; to it fetch a y-position from the sinus table STA YPOS,Y ; Then divide it to two bytes LDA SINUS,X LSR LSR LSR STA YPOSH,Y INX ; Chars are two positions apart INX DEY BPL LOOP4 LDA #0 LDX #79 LOOP11 STA GFX,X ; Clear the dycp data STA GFX+80,X STA GFX+160,X STA GFX+240,X STA GFX+320,X STA GFX+400,X STA GFX+480,X STA GFX+560,X DEX BPL LOOP11 MAKE LDA COUNTER ; Set x-scroll register STA $D016 LDX #AMOUNT CLC ; Clear carry LOOP5 LDY YPOSH,X ; Determine the position in video matrix TXA ADC LINESL,Y ; Carry won't be set here STA ZP ; low byte LDA #4 ADC LINESH,Y STA ZP+1 ; high byte LDA #PADCHAR ; First clear above and below the char LDY #0 ; 0. row STA (ZP),Y LDY #120 ; 3. row STA (ZP),Y TXA ; Then put consecuent character codes to the places ASL ; Carry will be cleared ORA #$80 ; Inverted chars LDY #40 ; 1. row STA (ZP),Y ADC #1 ; Increase the character code, Carry won't be set LDY #80 ; 2. row STA (ZP),Y LDA CHAR,X ; What character to plot ? (source) STA ZP2 ; (char is already multiplicated by eight) LDA X16,X ; Destination low byte ADC YPOS,X ; (16*char code + y-position's 3 lowest bits) STA ZP LDA D16,X ; Destination high byte STA ZP+1 LDY #6 ; Transfer 7 bytes from source to destination LDA (ZP2),Y : STA (ZP),Y DEY ; This is the fastest way I could think of. LDA (ZP2),Y : STA (ZP),Y DEY LDA (ZP2),Y : STA (ZP),Y DEY LDA (ZP2),Y : STA (ZP),Y DEY LDA (ZP2),Y : STA (ZP),Y DEY LDA (ZP2),Y : STA (ZP),Y DEY LDA (ZP2),Y : STA (ZP),Y DEX BPL LOOP5 ; Get next char in scroll LDA #1 STA $D019 ; Acknowledge raster interrupt DEC COUNTER ; Decrease the counter = move the scroll by 1 pixel BPL OUT LOOP12 LDA CHAR+1,Y ; Move the text one position to the left STA CHAR,Y ; (Y-register is initially zero) INY CPY #AMOUNT BNE LOOP12 LDA POINTER AND #63 ; Text is 64 bytes long TAX LDA SCROLL,X ; Load a new char and multiply it by eight ASL ASL ASL STA CHAR+AMOUNT ; Save it to the right side DEC START ; Compensation for the text scrolling DEC START INC POINTER ; Increase the text pointer LDA #7 STA COUNTER ; Initialize X-scroll OUT JMP $EA7E ; Return from interrupt SIN BYT 0,3,6,9,12,15,18,21,24,27,30,32,35,38,40,42,45 BYT 47,49,51,53,54,56,57,59,60,61,62,62,63,63,63 ; 1/4 of the sinus LINESL BYT 0,40,80,120,160,200,240,24,64,104,144,184,224 BYT 8,48,88,128,168,208,248,32 LINESH BYT 0,0,0,0,0,0,0,1,1,1,1,1,1,2,2,2,2,2,2,2,3 SCROLL SCR "THIS@IS@AN@EXAMPLE@SCROLL@FOR@" SCR "COMMODORE@MAGAZINE@BY@PASI@OJALA@@" ; SCR will convert text to screen codes -------------------------------------------------------------------------- Basic loader for the Dycp demo program (PAL) 1 S=49152 2 DEFFNH(C)=C-48+7*(C>64) 3 CH=0:READA$,A:PRINTA$:IFA$="END"THENPRINT"<white><clr>":SYS49152:END 4 FORF=0TO31:Q=FNH(ASC(MID$(A$,F*2+1)))*16+FNH(ASC(MID$(A$,F*2+2))) 5 CH=CH+Q:POKES,Q:S=S+1:NEXT:IFCH=ATHEN3 6 PRINT"CHECKSUM ERROR":END 100 DATA 78A9328501A200BD00D09D0038BD00D19D0039CAD0F1A9378501A01FA942187D, 3441 101 DATA 75C19D00CF9920CFA94038FD75C19D40CF9960CFE88810E4A27FBD00CF4A1869, 4302 102 DATA 209D80CFCA10F3A2278A0A0A0A0A9D00CE8A4A4A4A4A18693C9D30CEA9009D90, 3231 103 DATA 03CA10E58D3E03A2078E3D039D0038CA10FAA93885FEA99B8D1403A9C08D1503, 3338 104 DATA A97F8D0DDCA9818D1AD0A9A88D12D0A91B8D11D0A91E8D18D05860EE3C03A026, 3864 105 DATA AE3C03BD00CF2907994003BD00CF4A4A4A996803E8E88810EAA900A24F9D003C, 3256 106 DATA 9D503C9DA03C9DF03C9D403D9D903D9DE03D9D303ECA10E5AD3D038D16D0A226, 3739 107 DATA 18BC68038A7995C185FBA90479AAC185FCA920A00091FBA07891FB8A0A0980A0, 4224 108 DATA 2891FB6901A05091FBBD900385FDBD00CE7D400385FBBD30CE85FCA006B1FD91, 4440 109 DATA FB88B1FD91FB88B1FD91FB88B1FD91FB88B1FD91FB88B1FD91FB88B1FD91FBCA, 6225 110 DATA 109FEE19D0CE3D031028B99103999003C8C026D0F5AD3E03293FAABDBFC10A0A, 3593 111 DATA 0A8DB603CE3C03CE3C03EE3E03A9078D3D034C7EEA000306090C0F1215181B1E, 2159 112 DATA 202326282A2D2F3133353638393B3C3D3E3E3F3F3F00285078A0C8F018406890, 2268 113 DATA B8E008305880A8D0F82000000000000000010101010101020202020202020314, 1379 114 DATA 08091300091300010E000518010D100C05001303120F0C0C00060F1200030F0D, 304 115 DATA 0D0F040F1205000D0107011A090E050002190010011309000F0A010C01000000, 257 200 DATA END,0 -------------------------------------------------------------------------- Uuencoded C64 executable of the basic loader (PAL) begin 644 dycp.64 M`0@-"`$`4[(T.3$U,@`F"`(`EJ5(*$,ILD.K-#BJ-ZPH0[$V-"D`4@@#`$-(@ MLC`ZAT$D+$$ZF4$D.HM!)+(B14Y$(J>9(@63(CJ>-#DQ-3(Z@`")"`0`@4:RE M,*0S,3I1LJ5(*,8HRBA!)"Q&K#*J,2DI*:PQ-JJE2"C&*,HH020L1JPRJC(IA M*2D`J@@%`$-(LD-(JE$ZEU,L43I3LE.J,3J".HM#2+)!IS,`P@@&`)DB0TA%. M0TM354T@15)23U(B.H``#PED`(,@-SA!.3,R.#4P,4$R,#!"1#`P1#`Y1#`P. M,SA"1#`P1#$Y1#`P,SE#040P1C%!.3,W.#4P,4$P,49!.30R,3@W1"P@,S0T# M,0!<"64`@R`W-4,Q.40P,$-&.3DR,$-&03DT,#,X1D0W-4,Q.40T,$-&.3DV& M,$-&13@X.#$P131!,C=&0D0P,$-&-$$Q.#8Y+"`T,S`R`*D)9@"#(#(P.40X3 M,$-&0T$Q,$8S03(R-SA!,$$P03!!,$$Y1#`P0T4X031!-$$T031!,3@V.3-#P M.40S,$-%03DP,#E$.3`L(#,R,S$`]@EG`(,@,#-#03$P134X1#-%,#-!,C`WY M.$4S1#`S.40P,#,X0T$Q,$9!03DS.#@U1D5!.3E".$0Q-#`S03E#,#A$,34P@ M,RP@,S,S.`!#"F@`@R!!.3=&.$0P1$1#03DX,3A$,4%$,$$Y03@X1#$R1#!!B M.3%".$0Q,40P03DQ13A$,3A$,#4X-C!%13-#,#-!,#(V+"`S.#8T`)`*:0"#] M($%%,T,P,T)$,#!#1C(Y,#<Y.30P,#-"1#`P0T8T031!-$$Y.38X,#-%.$4X$ M.#@Q,$5!03DP,$$R-$8Y1#`P,T,L(#,R-38`W0IJ`(,@.40U,#-#.41!,#-#] M.41&,#-#.40T,#-$.40Y,#-$.41%,#-$.40S,#-%0T$Q,$4U040S1#`S.$0Q* M-D0P03(R-BP@,S<S.0`J"VL`@R`Q.$)#-C@P,SA!-SDY-4,Q.#5&0D$Y,#0W^ M.4%!0S$X-49#03DR,$$P,#`Y,49"03`W.#DQ1D(X03!!,#DX,$$P+"`T,C(T: M`'<+;`"#(#(X.3%&0C8Y,#%!,#4P.3%&0D)$.3`P,S@U1D1"1#`P0T4W1#0P; M,#,X-49"0D0S,$-%.#5&0T$P,#9",49$.3$L(#0T-#``Q`MM`(,@1D(X.$(Q? M1D0Y,49".#A",49$.3%&0C@X0C%&1#DQ1D(X.$(Q1D0Y,49".#A",49$.3%&V M0C@X0C%&1#DQ1D)#02P@-C(R-0`1#&X`@R`Q,#E&144Q.40P0T4S1#`S,3`RK M.$(Y.3$P,SDY.3`P,T,X0S`R-D0P1C5!1#-%,#,R.3-&04%"1$)&0S$P03!!M M+"`S-3DS`%X,;P"#(#!!.$1"-C`S0T4S0S`S0T4S0S`S144S13`S03DP-SA$H M,T0P,S1#-T5%03`P,#,P-C`Y,$,P1C$R,34Q.#%",44L(#(Q-3D`JPQP`(,@0 M,C`R,S(V,C@R03)$,D8S,3,S,S4S-C,X,SDS0C-#,T0S13-%,T8S1C-&,#`R[ M.#4P-SA!,$,X1C`Q.#0P-C@Y,"P@,C(V.`#X#'$`@R!".$4P,#@S,#4X.#!!8 M.$0P1C@R,#`P,#`P,#`P,#`P,#`P,#$P,3`Q,#$P,3`Q,#(P,C`R,#(P,C`R^ M,#(P,S$T+"`Q,S<Y`$0-<@"#(#`X,#DQ,S`P,#DQ,S`P,#$P13`P,#4Q.#`Q7 M,$0Q,#!#,#4P,#$S,#,Q,C!&,$,P0S`P,#8P1C$R,#`P,S!&,$0L(#,P-`"02 M#7,`@R`P1#!&,#0P1C$R,#4P,#!$,#$P-S`Q,4$P.3!%,#4P,#`R,3DP,#$P. L,#$Q,S`Y,#`P1C!!,#$P0S`Q,#`P,#`P+"`R-3<`G`W(`(,@14Y$+#`````PK `` end size 1439 -------------------------------------------------------------------------- Uuencoded C64 executable of the basic loader (NTSC) begin 644 dycp-ntsc.bas M`0@-"`$`4[(T.3$U,@`F"`(`EJ5(*$,ILD.K-#BJ-ZPH0[$V-"D`40@#`$-(? MLC`ZAT$D+$$ZF4$D.HM!)+(B14Y$(J>9(I,B.IXT.3$U,CJ``(@(!`"!1K(P/ MI#,Q.E&RI4@HQBC**$$D+$:L,JHQ*2DIK#$VJJ5(*,8HRBA!)"Q&K#*J,BDI: M*0"I"`4`0TBR0TBJ43J74RQ1.E.R4ZHQ.H(ZBT-(LD&G,P#!"`8`F2)#2$5#F M2U-532!%4E)/4B(Z@`#'"%H`@``4"60`@R`W.$$Y,S(X-3`Q03(P,$)$,#!$L M,#E$,#`S.$)$,#!$,3E$,#`S.4-!1#!&,4$Y,S<X-3`Q03`Q1D$Y-#(Q.#=$I M+"`S-#0Q`&$)90"#(#<U0S$Y1#`P0T8Y.3(P0T9!.30P,SA&1#<U0S$Y1#0P! M0T8Y.38P0T9%.#@X,3!%-$$R-T9"1#`P0T8T03$X-CDL(#0S,#(`K@EF`(,@R M,C`Y1#@P0T9#03$P1C-!,C(W.$$P03!!,$$P03E$,#!#13A!-$$T031!-$$QJ M.#8Y,T,Y1#,P0T5!.3`P.40Y,"P@,S(S,0#["6<`@R`P,T-!,3!%-3A$,T4P. M,T$R,#<X13-$,#,Y1#`P,SA#03$P1D%!.3,X.#5&14$Y.4(X1#$T,#-!.4,P; M.$0Q-3`S+"`S,S,X`$@*:`"#($$Y-T8X1#!$1$-!.3@Q.$0Q040P03E",#A$: M,3)$,$$Y,4(X1#$Q1#!!.3%%.$0Q.$0P-3@V,$5%,T,P,T$P,4,L(#,X-C(`9 ME0II`(,@044S0S`S0D0P,$-&,CDP-SDY-#`P,T)$,#!#1C1!-$$T03DY-C@PB M,T4X13@X.#$P14%!.3`P03(T1CE$,#`S0RP@,S(U-@#B"FH`@R`Y1#4P,T,Y$ M1$$P,T,Y1$8P,T,Y1#0P,T0Y1#DP,T0Y1$4P,T0Y1#,P,T5#03$P135!1#-$E M,#,X1#$V1#!!,C%#+"`S-S(Y`"\+:P"#(#$X0D,V.#`S.$$W.3DU0S$X-49") M03DP-#<Y04%#,3@U1D-!.3(P03`P,#DQ1D)!,#<X.3%&0CA!,$$P.3@P03`L# M(#0R,C0`?`ML`(,@,C@Y,49"-CDP,4$P-3`Y,49"0D0Y,#`S.#5&1$)$,#!#H M13=$-#`P,S@U1D)"1#,P0T4X-49#03`P-D(Q1D0Y,2P@-#0T,`#)"VT`@R!&C M0C@X0C%&1#DQ1D(X.$(Q1D0Y,49".#A",49$.3%&0C@X0C%&1#DQ1D(X.$(QA M1D0Y,49".#A",49$.3%&0D-!+"`V,C(U`!8,;@"#(#$P.49%13$Y1#!#13-$T M,#,Q,#(X0CDY,3`S.3DY,#`S0SA#,#(V1#!&-4%$,T4P,S(Y,T9!04)$0D9#0 M,3!!,$$L(#,U.3,`8PQO`(,@,$$X1$(V,#-#13-#,#-#13-#,#-%13-%,#-!D M.3`W.$0S1#`S-$,W145!,#`P,S`V,#DP0S!&,3(Q-3$X,4(Q12P@,C$U.0"P2 M#'``@R`R,#(S,C8R.#)!,D0R1C,Q,S,S-3,V,S@S.3-",T,S1#-%,T4S1C-&/ M,T8P,#(X-3`W.$$P0SA&,#$X-#`V.#DP+"`R,C8X`/T,<0"#($(X13`P.#,P2 M-3@X,$$X1#!&.#(P,#`P,#`P,#`P,#`P,#`P,3`Q,#$P,3`Q,#$P,C`R,#(P> M,C`R,#(P,C`S,30L(#$S-SD`20UR`(,@,#@P.3$S,#`P.3$S,#`P,3!%,#`P3 M-3$X,#$P1#$P,$,P-3`P,3,P,S$R,$8P0S!#,#`P-C!&,3(P,#`S,$8P1"P@J M,S`T`)4-<P"#(#!$,$8P-#!&,3(P-3`P,$0P,3`W,#$Q03`Y,$4P-3`P,#(Q` M.3`P,3`P,3$S,#DP,#!&,$$P,3!#,#$P,#`P,#`L(#(U-P"A#7@`@R!%3D0LZ $,````#`P0 `` end size 1444 ================================================================================ Opening the borders by Pasi 'Albert' Ojala (po87553@cs.tut.fi or albert@cc.tut.fi) Written: 20-Jul-92 All timings are in PAL, principles will apply to NTSC too. Refer to VIC memory map in Hacking Issue 4. VIC has many features and transparent borders are one of them. You can not make characters appear in the border, but sprites are displayed in the border too. "How to do this then?" is the big question. The screen resolution in C64 has been and will be 320 x 200 pixels. Most games need to use the whole screen to be efficient or just plain playable. But there still is that useless border area, and you can put score and other status information there instead of having them interfere with the full-screen smooth-scrolling playing area. _How to disable the vertical borders_ When VIC (Video Interface Controller) has displayed all character rows, it will start displaying the vertical border area. It will start displaying the characters again in top of the screen. The row select register sets the number of character lines on the screen. If we select the 24-row display when VIC is drawing the last (25th) row, it does not start to draw the border at all ! VIC will think that it already started to draw the border. The 25-row display must be selected again in the top of the screen, so that the border may be opened in the next frame too. The number of displayed rows can be selected with the bit 3 in $d011. If the bit is set, VIC will display 25 rows and 24 rows otherwise. We have to clear the bit somewhere during the last row (raster lines $f2-$fa) and set it again in top of the screen or at least somewhere before the last row (line $f2). This has to be done in every frame (50 times per second in PAL). _How to open the sideborders_ The same trick can be applied to sideborders. When VIC is about to start displaying the sideborder, just select 38-column mode and restore 40-column mode so that you can do the trick again in the next scan line. If you need to open the sideborders in the bottom or top border area, you have to open the vertical borders also, but there shouldn't be any difficulty in doing that. There is two drawbacks in this. The timing must be precise, one clock cycle off and the sideborder will not open (the sprites will generally take care of the timing) and you have to do the opening on each and every line. With top/bottom borders once in a frame was enough. Another problem is bad-lines. There is not enough time to open the borders during a bad line and still have all of the sprites enabled. One solution is to open the borders only on seven lines and leave the bad lines unopened. Another way is to use less than eight sprites. You can have six of them on a bad line and still be able to open the sideborders (PAL). The old and still good solution is to scroll the bad lines, so that VIC will not start to draw the screen at all until it is allowed to do so. [Read more about bad lines from previous C=Hacking Issues] _Scrolling the screen_ VIC begins to draw the screen from the first bad line. VIC will know what line is a bad line by comparing its scan line counter to the vertical scroll register : when they match, the next line is a bad line. If we change the vertical scroll register ($d011), the first bad line will move also. If we do this on every line, the line counter in VIC will never match with it and the drawing never starts (until it is allowed to do so). When we don't have to worry about bad lines, we have enough time to open the borders and do some other effects too. It is not necassary to change the vertical scroll on every line to get rid of the bad lines, just make sure that it never matches the line counter (or actually the least significant 8 bits). You can even scroll the bad lines independently and you have FLD - Flexible Line Distance. You just allow a bad line when it is time to display the next character row. With this you can bounce the lines or scroll a hires picture very fast down the screen. But this has not so much to do with borders, so I will leave it to another article. (Just send requests and I might start writing about FLD ..)