8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / HACK2.1-4.SFX / hack.1

Wrap

Text File | 1990-02-12 | 47.0 KB | 1,001 lines

├├├├├├ ╚╚ ╚╚ ┴┴┴┴ ├├├├├ ╦╦ ╦╦ ╔╔╔╔╔╔ ╬╬ ╬╬ ╟╟╟╟ ├├ ==== ╚╚ ╚╚ ┴┴ ┴┴ ├├ ╦╦ ╦╦ ╔╔ ╬╬╬ ╬╬ ╟╟ ├├ ==== ╚╚ ╚╚ ┴┴ ┴┴ ├├ ╦╦╦╦ ╔╔ ╬╬ ╬╬╬╬ ╟╟ ├├ ╚╚╚╚╚╚╚╚ ┴┴ ┴┴ ├├ ╦╦╦╦ ╔╔ ╬╬ ╬╬╬╬ ╟╟ ╟╟╟ ├├ ==== ╚╚ ╚╚ ┴┴┴┴┴┴┴┴ ├├ ╦╦ ╦╦ ╔╔ ╬╬ ╬╬╬ ╟╟ ╟╟ ├├ ==== ╚╚ ╚╚ ┴┴ ┴┴ ├├ ╦╦ ╦╦ ╔╔ ╬╬ ╬╬ ╟╟ ╟╟ ├├├├├├ ╚╚ ╚╚ ┴┴ ┴┴ ├├├├├ ╦╦ ╦╦ ╔╔╔╔╔╔ ╬╬ ╬╬ ╟╟╟╟╟ ╓OLUME 1 - ╔SSUE 2 - ┴PRIL 22, 1992 ============================================================================== ┼DITOR'S ╬OTES: BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU) ┼EEGH! - ╫HEN ╔ FIRST STARTED THIS ╔ NEVER REALIZED HOW MUCH WORK IT'D BE. ╔'M GLAD OF THE RECEPTION IT'S GOTTEN FROM THE ├OMMODORE COMMUNITY AT LARGE. ╔'D LIKE TO THANK EACH OF THE AUTHOR'S IN THIS ISSUE AND LAST FOR THEIR WORK THEY'VE PUT INTO IT AS WELL AS THEIR TIME. ╨LEASE NOTE THAT ALL FILES, DOCUMENTATION ETCETERA ASSOCIATED WITH ├= ╚ACKING AND WHATNOT CONTAINED WITHIN ARE ALSO NOW AVAILABLE AT TYBALT.CALTECH.EDU VIA ANONYMOUS FTP UNDER THE DIRECTORY /PUB/RKNOP/HACKING.MAG. ┴NY UPDATES TO FILES CONTAINED WITHIN OR CORRECTIONS WILL BE POSTED THERE AS WELL AS MENTIONED HERE. ├URRENTLY IT HAS THE CORRECT 1ST ISSUE AND (SOON TO BE) 2ND ISSUE. ┴LSO ╥OBERT ╦NOP'S FILE BMOVER.SFX IS THERE FOR THE ┬ANKING ╟EOS ARTICLE IN THIS ISSUE. ╔T SEEMS AS IF WE'RE AVERAGING ABOUT 2 MONTHS FOR EACH ISSUE AND HOPEFULLY WE'LL KEEP THAT RATE DURING THE SUMMER BUT DUE TO AN INTERNSHIP (╔'LL HOPEFULLY GET) ╔ MAY NOT HAVE NET ACCESS DURING THE SUMMER. ╔N THAT CASE IT'LL BE DELAYED UNTIL AFTER ╔ GET BACK TO SCHOOL IN THE FALL. ┴LSO, IF YOU'VE GOT ANY IDEAS FOR ARTICLES OR HAVE WRITTEN A PROGRAM THAT IS UNIQUE THAT YOU'D BE INTERESTED IN DOCUMENTING AND P'HAPS LETTING OTHER PEOPLE SEE SOME OF THE TRICKS OF THE TRADE THEN PLEASE SEND ANY QUERIES TO DUCK@PEMBVAX1.PEMBROKE.EDU. ****************** ╫┴╥╬╔╬╟╙, ╒╨─┴╘┼╙, ┬╒╟ ╥┼╨╧╥╘╙, ┼╘├... ********************* ╨LEASE NOTE THAT IN THE LAST ISSUE WHEN THE UNDOCUMENTED OPCODES WERE DISCUSSED THAT THEY ARE _╓┼╥┘ ╬╧╬-╙╘┴╬─┴╥─_. ┴ND ANY FUTURE ACCELERATOR BOARDS FOR THE ├=128 OR ├=64, IN ALL LIKELEHOOD, _WILL NOT WORK_. ┌IP'S BOARD [WHEN ARE THEY EVER GONNA FINISH IT?] FOR THE ├=128 WILL BE BASED ON A SIMILAIR PROCESSOR TO THE 8502 AND IS PRACTICALLY GUARENTEED NOT TO WORK WITH THE UNDOCUMENTED OP-CODES. ╔F YOU PLAN TO RELEASE ANY ═╠ PROGRAMS FOR GENERAL USE ╨╠┼┴╙┼ BE AWARE THAT THEY MAY BE IN-COMPATIBLE WITH FUTURE SYSTEMS. ============================================================================ ╬OTE: ╨ERMISSION IS GRANTED TO RE-DISTRIBUTE THIS "NET-MAGAZINE", IN WHOLE, FREELY FOR NON-PROFIT USE. ╚OWEVER, PLEASE CONTACT INDIVIDUAL AUTHORS FOR PERMISSION TO PUBLISH OR RE-DISTRIBUTE ARTICLES SEPERATELY. *** ┴╒╘╚╧╥╙ ╠╔╙╘┼─ ┬┼╠╧╫ ╥┼╘┴╔╬ ┴╠╠ ╥╔╟╚╘╙ ╘╧ ╘╚┼╔╥ ┴╥╘╔├╠┼╙ *** ============================================================================ ╔N THIS EDITION WE'VE GOT THE FOLLOWING ARTICLES: ╠EARNING ═╠ - ╨ART 2 ┘ES, THE INFAMOUS LEARNING MACHINE LANGAUGE TUTORS BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU). ╔N THIS SESSION WE EXAMINE INDEXED ADDRESSING AND IT'S USEFULLNESS IN PRINTING STRINGS OF CHARACTERS. 8563 : ┴N ╔N-─EPTH ╠OOK ╘HIS ARTICLE DOCUMENTS AND DETAILS THE 8563 IN-DEPTH. ╔T COVERS ALL AVAILABLE REGISTERS, DOCUMENTS THEIR FUNCTIONS AND SUGGESTED METHODS OF GETTING CERTAIN EFFECTS. ┴LSO COVERS HOW TO READ AND WRITE TO 8563 REGISTERS AS WELL AS READ THE 16K OR 64K OF MEMORY THAT CONTAINS THE ╓─├ CHAR-SET, SCREEN MEMORY ETC. ╫RITTEN BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU). ╘HE ╨OOR ═AN'S ╫AY TO ╟ETTING ╞ILES FROM ═╙-─OS ─ISKETTES ╬OW THERE'S A WAY TO TRANSFER FILES OF ANY LENGTH FROM ═╙-─OS DISKETTES USING A PUBLIC DOMAIN PROGRAM THAT WILL ONLY READ FILES OF 43K OR LESS AND A ╔┬═ PROGRAM TO SPLIT THE FILES UP. ╘HERE ARE BETTER WAYS, BUT IF YOU DON'T WANT TO PAY FOR ┬IG-┬LUE ╥EADER THIS IS ONE METHOD TO GO. ╫RITTEN BY ═ARK ╠AWRENCE (9152427─@╠EVELS.╒NI╙A.┼DU.┴U). ┬ANKING ON ╟EOS ╟┼╧╙ 128, BEING AN EXTENDED AND EXPANDED VERSION OF ╟┼╧╙ 64, PROVIDES A CONTIGUOUS BLOCK OF APPLICATION SPACE IN A SINGLE ╥┴═ BANK. ╘HE "STANDARD" PROGRAMMING DOCUMENTATION MAKES FEW REFERENCES TO THE USE OF OTHER BANKS IN ╟┼╧╙. ╘HIS ARTICLE DESCRIBES ACCESSING OTHER ╥┴═ BANKS (INCLUDING ╥┴═ BANKS 2 AND 3 FOR 256╦ EXPANDED 128'S) UNDER ╟┼╧╙128, USING BOTH THE ╟┼╧╙ ╦ERNAL ROUTINES AND MORE DIRECT METHODS. ┬Y ╥OBERT ╦NOP (RKNOP@TYBALT.CALTECH.EDU). ─YNAMIC ═EMORY ┴LLOCATION ╫RITTEN BY ├RAIG ┬RUCE (F2RX@JUPITER.SUN.CSD.UNB.CA) THIS ARTICLE EXAMINES HOW TO IMPLEMENT AND USE DYNAMICALLY ALLOCATED MEMORY THAT WILL ALLOW YOUR PROGRAMS TO BETTER UTILIZE ALL OF THE AVAILABLE MEMORY ON YOUR ├=128, INCLUDING EXPANSION MEMORY. ╘HESE ROUTINES ARE EXTRACTED FROM THE ┌ED-128 PROGRAM WHICH IS A TEXT EDITOR THAT CAN EDIT 600╦┬YTE FILES ON A 512╦ EXPANDED 128. ============================================================================= ┬EGINNING ═╠ #2 BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU) ╠AST TIME WE INTRODUCED THE DEFINITION OF WHAT EXACTLY ═ACHINE ╠ANGUAGE / ┴SSEMBLY ╠ANGUAGE IS ALONG WITH AN EXAMPLE OF CLEARING THE SCREEN IN ═ACHINE ╠ANGUAGE. ╬OW, IN THIS ISSUE LET'S PRINT MY NAME (AND LATER YOUR NAME). ╠OOKING AT THE CODE FROM LAST TIME THE FOLLOWING ASSEMBLY SOURCE JUMPS TO MIND: ------------ PRINT_1.ASM: LDA #147 ; CLR/SCREEN CODE JSR $FFD2 ; PRINT LDA #'├' ; CODE FOR ASCII "├" JSR $FFD2 ; PRINT LDA #'R' JSR $FFD2 LDA #'A' JSR $FFD2 LDA #'I' JSR $FFD2 LDA #'G' JSR $FFD2 LDA #32 ; CODE FOR SPACE JSR $FFD2 LDA #'╘' ; PRINT MY LAST NAME.... JSR $FFD2 . . (AD NASEUM...) . RTS ---------- ╬OW, FOR SHORT STRINGS LIKE "╚╔!" THAT MIGHT BE FINE BUT IF YOUR NAME IS SOMETHING LIKE "╙EYMOUR ╩OHNSON THE THIRD" IT CAN GET A LITTLE BIT RIDICULOUS IN TERMS OF THE AMOUNT OF MEMORY AND THE AMOUNT OF TYPING (EEGH! - TYPING!) INVOLVED. ╘HERE'S AN EASIER WAY. ╔T'S CALLED INDEXED ADDRESSING. ╫HAT IS THIS YOU SAY? ╠ET'S FIRST TAKE A LOOK AT THE ABOVE PROGRAM USING INDEXED ADDRESSING AND THEN EXPLAIN IT. ------------ PRINT_2.ASM LDY #$00 LOOP LDA STRING,Y JSR $FFD2 INY CPY #NUMCHARS BNE LOOP RTS STRING .BYTE 147 .ASCII "├RAIG ╘AYLOR" NUMCHARS = *-STRING ------------ ╚MM, LOOKS A LITTLE BIT CONFUSING 'EH? ╫HAT WE'RE DOING IS USING THE REGISTER Y TO ACT AS A POINTER TO GRAB THE Y'TH CHARACTER IN WHAT IS AT MEMORY LOCATION ╙╘╥╔╬╟. ╔F Y IS 0 THEN WE'LL GET STRING+0 WHICH HAPPENS TO BE A 147. ╘HE .BYTE AND .ASCII DIRECTIVES ARE NOT REAL INSTRUCTIONS THE COMPUTER UNDERSTANDS. ╫HAT HAPPENS IS THAT YOUR ASSEMBLER SEES THAT YOU WANT DATA PUT AT THOSE LOCATIONS SO IT CONVERT 147 AND "├RAIG ╘AYLOR" TO NUMBERS AND PUTS THEM AT THE PROPER LOCATIONS, RELIEVING YOU THE BURDEN OF DOING IT. ╘HE NUMCHARS = *-STRING LOOKS CONFUSING AT FIRST... OBVIOUSLY, NUMCHARS STANDS FOR THE NUMBER OF CHARACTERS WE NEED TO PRINT OUT BUT HOW IS IT BEING FIGURED? ═OST ASSEMBLERS KEEP THE CURRENT LOCATION IN MEMORY IT'S ASSEMBLING TO IN SOMETHING CALLED A PROGRAM COUNTER OF ╨├. ═OST ASSEMBLERS ALSO WILL LET YOU HAVE THE VALUE AT ASSEMBLY TIME BY REFERENCING IT USING THE "*" SYMBOL. "STRING" IS ALREADY A SYMBOL THAT HAS BEEN SET AN ADDRESS IN MEMORY AND AFTER ASSEMBLING THE .BYTE AND .ASCII INSTRUCTION "*" WILL BE EQUAL TO THE NEXT ADDRESS THAT THE ASSEMBLER WOULD PUT ANY INSTRUCTIONS AT, HAD WE HAD ANY. ╬OW, *-STRING BASICALLY IS SAYING TO THE COMPILER, LOOK, TAKE THE CURRENT PROGRAM COUNTER (WHERE IT'S ASSEMBLING TO) AND SUBTRACT IT FROM WHERE THE SYMBOL STRING STARTS AT (WHICH IT JUST ASSEMBLED A WHILE BACK). ╘HIS SHOULD BE THEN, OUR NUMBER OF CHARACTERS WE HAVE. ╫┴╠╦-╘╚╥╧╒╟╚: ╥EGISTER ┘ IS INITIALLY SET TO ZERO IN THE FIRST INSTRUCTION, AS WE WANT TO BEGIN WITH THE FIRST CHARACTER. ╘HE FIRST CHARACTER IS AT STRING+0, NOT STRING+1. ╘HIS MAY SEEM A LITTLE BIT ODD AT FIRST, BUT TRY THINKING OF IT THIS WAY: ╘AKE, FOR EXAMPLE, 3 DISKETTES. ╨UT THEM IN A ROW AND CALL THE ONE ON THE LEFT "STRING" (OR SOME OTHER NAME). ╘HEN POINT AT "STRING+1", "STRING+2".. ╬OTICE THERE'S NO "STRING+3" EVEN THO' THERE'S 3 DISKETTES? ╘HIS MAY SEEM A LITTLE BIT STRANGE AT FIRST, BUT AFTER THINKING ABOUT IT A WHILE YOU'LL BEGIN TO UNDERSTAND. ╔N MACHINE / ASSEMBLY LANGUAGE, YOU TYPICALLY COUNT STARTING FROM ZERO, IN THE REAL WORLD, TYPICALLY FROM ONE. ╘HE LDA STRING,Y INSTRUCTION IS TELLING THE COMPUTER TO REFERENCE STRING AS IF IT WAS AN ARRAY, GET THE BYTE AT LOCATION STRING + Y, OR FOR YOU BASIC PROGRAMMERS THINKING OF STRING AS AN ARRAY OF BYTES (WITH NO BOUNDS CHECKING) STRING[Y]. ╘HUS, THE ACCUMULATOR IS EQUAL TO THE YTH BYTE STARTING FROM THE LOCATION STRING IS DEFINED TO BE. ╫E THEN CALL THE ROUTINE ├OMMODORE SO GRACIOUSLY PROVIDED FOR US THAT PRINTS OUT THE CONTENTS OF THE ACCUMULATOR. ╬OW, SOME ROUTINES, AS WE'LL SEE IN OTHER EDITIONS, ARE NOT SO NICE AND MAY CHANGE THE VALUE OF THE ACCUMULATOR, THE X AND Y REGISTERS. ╚OWEVER, ├OMMODORE WAS EXTRA NICE AND THE ROUTINE AT $FFD2 IS GUARANTEED NOT TO CHANGE ANY OF THE REGISTERS. ╘HE ROUTINE THEN "INY". ╫HAT IS THIS? ╔T "╔╬CREMENTS THE ┘ REGISTER". ╔╬╪ WILL "╔╬CREMENT THE ╪ REGISTER". ╘HE ╪ AND ┘ REGISTER CAN NOT HAVE ANY MATH PERFORMED ON THEM OTHER THAN INCREMENT AND DECREMENT OPERATIONS (IE: ADDING ONE AND SUBTRACTING ONE). ╘HE ONLY REGISTER THAT ALLOWS ADDITION OR SUBTRACTION IS THE ACCUMULATOR. ╚OWEVER, IN THIS CASE WE JUST WANT Y TO POINT TO THE NEXT CHARACTER, THE NEXT BYTE SO "╔╬┘" SERVES US FINE. ╫E THEN "├OM╨ARE ┘" REGISTER TO THE NUMBER OF CHARACTERS IN THE STRING. ╬OTICE THE # SIGN. ╔F WE HADN'T HAVE HAD THAT THERE, IT WOULD'VE TRIED TO LOOK AT WHATEVER MEMORY LOCATION NUMCHARS WAS DEFINED FOR. ╬UMCHARS WAS SET UP TO HOLD THE NUMBER OF CHARACTERS IN THE STRING, NOT BE A POINTER FOR A MEMORY LOCATION. ╬OW THAT WE'VE COMPARED IT, WE "┬RANCH IF THE LAST COMPARISON WAS ╬OT ┼QUAL" BACK TO WHERE LOOP IS AT (IN THIS CASE, WHERE WE LOAD A WITH CHARACTER AGAIN). ╔F IT WAS EQUAL WE FALL THROUGH TO THE ╥╘╙ WHERE WE RETURN FROM OUR LITTLE PROGRAM. ┬ASICALLY, WE'VE GOT SOMETHING LIKE THE FOLLOWING FLOWCHART: _______ / ╙╘┴╥╘ \ \_______/ ▄ \▄/ +-----------------+ ▄ ╙ET ╔NDEX (┘) ▄ ▄ FIRST CHARACTER ▄ +-----------------+ ▄ \▄/ +-------------------+ ▄ ╟ET THE CHARACTER ▄ / ▄ POINTED TO BY ▄<------------------+ ▄ THE INDEX(┘) ▄ \ ▄ +-------------------+ ▄ ▄ ▄ \▄/ ▄ +-------------+ ▄ ▄ ╨RINT IT ▄ ▄ +-------------+ ▄ ▄ ▄ \▄/ ▄ +------------------------+ ▄ ▄ ╔NCREMENT THE ╔NDEX(┘) ▄ ▄ +------------------------+ ▄ ▄ ▄ \▄/ ▄ /\ ▄ /= \ ▄ /# OF\ ▄ /CHARS?\ ▄ /TO PRINT\___NO,NOT =_____------------->+ \??? / \ / \ / \ / \/ ▄ \▄/ _____ / ┼╬─ \ \_____/ ╔NDEXED ADDRESSING IS USED *VERY* OFTEN IN ASSEMBLY LANGUAGE. ╘RY PLAYING WITH THE SECOND PROGRAM AND EXPERIMENT WITH IT UNTIL YOU UNDERSTAND FULLY WHAT IS GOING ON. ╬EXT TIME WE'LL LOOK AT HOW TO ACCESS SOME OF THE DISKETTE ROUTINES AND TO DISPLAY A FILE ON DISK. =============================================================================== ┴N ╔N-─EPTH ╠OOK AT THE 8563 ╓IDEO ├HIP ON THE ├= 128 ----------------------------------------------------- BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU) ─UE TO THE ARTICLE IN THE LAST ISSUE BY ├RAIG ┬RUCE (F2RX@JUPITER.SUN.CSD.UNB. CA) AND SOME LETTERS FROM PEOPLE ASKING ABOUT HOW THE 8563 ╓IDEO ├HIP WORKS AND MORE TECHNICAL INFORMATION THIS ARTICLE WILL ATTEMPT TO PRESENT AS MUCH DETAIL AS POSSIBLE ON THE 8563 CHIP & IT'S VARIOUS CAPIBILITIES. --------------------- ! ╚ARDWARE ┴SPECTS: ! --------------------- ╘HE FOLLOWING IS A PHYSICAL LAYOUT OF THE 8563 AND THE AVAILABLE PIN OUTS: +------------------+ 42 O_▄──7 ╓── ├╙ ─┴7▄_O 33 ─┴0-─┴7 - ┴DDRESS ┬US FOR ╥AM 41 O_▄──6 ─┴6▄_O 32 ──0-──7 - ─ATA ┬US FOR ╥AM 40 O_▄──5 ─┴5▄_O 31 ─0 - ─7 - ─ATA ┬US 8563 / ├PU 39 O_▄──4 ─┴4▄_O 30 ├╙ /├╙ - ├HIP ╙ELECTION ╨IN 38 O_▄──3 ─┴3▄_O 29 /╥╙ - ╥EGISTER ╙ELECT 36 O_▄──2 ─┴2▄_O 28 ╥/╫ - ─ATA ─IRECTION FOR ─ATA ┬US 35 O_▄──1 ─┴1▄_O 27 ╔╬╔╘ - ╔NITIALIZE INTERNAL LATCHES 34 O_▄──0 ─┴0▄_O 26 ─╔╙╨┼╬ - (╒NUSED) ─ISPLAY ┼NABLE ▄ ▄ ╥┼╙ - (╒NUSED) ╥ESET ALL SCAN CNTS ▄ ▄ ╘╙╘ - (╒NUSED) ╘EST PURPOSES ONLY 10 O_▄─7 /├┴╙▄_O 48 ─╥/╫ - ╠OCAL ─RAM ╥EAD/╫RITE 11 O_▄─6 /╥┴╙▄_O 47 /╥┴╙ - ╥OW ┴DDRESS ╙TROBE 13 O_▄─5 ─╥/╫▄_O 21 /├┴╙ - ├OLUMN ┴DDRESS ╙TROBE 14 O_▄─4 ▄ ─├╠╦ - ╓IDEO ─OT ├LOCK 15 O_▄─3 ╥▄_O 46 ├├╠╦ - (╒NUSED) ├HARACTER ├LOCK 16 O_▄─2 ╟▄_O 45 ╠╨2 - ╔NPUT FOR ╠IGHT ╨EN 17 O_▄─1 ┬▄_O 44 ╚╙┘╬├ - ╚ORIZONTAL ╙YNC 18 O_▄─0 ╔▄_O 43 ╥,╟,┬,╔ - ╨IXEL ─ATA ╧UTPUTS ▄ ▄ ▄ ▄ 8 O_▄/╥╙ ▄ 7 O_▄/├╙ ▄ 9 O_▄╥/╫ ╓╙┘╬▄_O 20 23 O_▄/╥┼╙ ╚╙┘╬▄_O 3 ▄ ▄ ▄ ├├╠╦▄_O 1 25 O_▄/╠╨2 ─╔╙╨┼╬▄_O 19 ▄ ▄ ▄ ╘╙╘▄_O 24 2 O_▄/─├╠╦ ╓╙5 ╔╬╔╘▄_O 22 +------------------+ !12 O ╘AKEN FROM ╨G. 596-8 ├=128 ╨ROGRAMMER'S ╥EFERENCE ═ANUAL ╨UBL. ╞EB 1986 ┬ANTEM ┬OOKS +-----------------------------+ ▄ ╚OW ├OMMODORE ╚OOKED ╔T ╒P! ▄ +-----------------------------+ ╬OW, THE 8563 IS HOOKED UP TO THE COMPUTER VIA THE FOLLOWING METHOD: +---------------------+ ▄ ▄ +--------+ +-------+ ▄├OMPUTER ═EMORY ▄ ▄ 8563 ▄ ▄16K OR ▄ ▄ (╥┴═) ▄ ▄ ▄ % ▄ 64K ▄ ▄ ▄___$D600_____▄DA0-7 ▄ % ▄╓─├ ╥┴═▄ ▄ ▄ ▄ ▄ % ▄ ▄ ▄ ▄___$D601_____▄DR0-7 ▄ % ▄(╙CREEN▄ ▄ ▄ ( /RS) ▄ D0-7▄___▄ ═EM) ▄ +---------------------+ +--------+ +-------+ ├ONFUSING 'EH? (╘HE %'S REPRESENT CONTROL SIGNALS THAT ALSO ARE USED).. ╫HAT BASICALLY HAPPENS IS THAT EVERY TIME THE COMPUTER WANTS TO ACCESS THE 8563 TO PROGRAM OR CHANGE ONE OF IT'S NUMEROUS REGISTERS IT HAS TO STORE THE REGISTER NUMBER TO $D600, THEN LOOP UNTIL THE 7TH BIT OF $D600 CHANGES TO A 1. ╧NCE THIS IS DONE, YOU CAN THEN READ OR WRITE A VALUE TO/FROM $D601. ├OMMODORE ALSO EMPLOYED THE ══╒ (═EMORY ═ANAGEMENT ╒NIT) TO MANIPULATE PAGES OF MEMORY AND THUS, THE 8563 ONLY SHOWS UP IN THE ╔/╧ PAGE (USUALLY REFERENCED AS ┬ANK 15 OR A VALUE OF $00 IN THE ══╒ ╥EGISTER AT $FF00) OR IN PAGES THAT THE ╔/╧ SECTION OF MEMORY IS ENABLED. ╘HE REGISTER AT $D600 IN THE ╔/╧ SPACE OF THE ├=128 IS LAID OUT AS FOLLOWS: ┬IT ╨OSITION: 7 6 5 4 3 2 1 0 ╙TATUS ╠IGHT╨EN ╓┬LANK -----╒NUSED---- ------╓ERSION #-------- ╫HEN A VALUE IS PLACED IN $D600 INSTEAD OF PUTTING THE VALUE IN ╙TATUS, ╠IGHT╨EN BITS ETC, THE VALUE REFLECTS WHICH REGISTER # IS REQUESTED. ┬IT 7 OF THIS REGISTER (╙TATUS) WILL THEN RETURN A BINARY 1 WHEN $D601 REFLECTS THE ACTUAL VALUE OF THE REGISTER JUST POKED TO $D600. (╙EE THE ═╠ ROUTINES FOR STORING AND READING VALUES TO/FROM REGISTERS AT THE END OF THIS ARTICLE). ╫HEN A VALUE IS FIRST PLACE IN THIS REGISTER, $D600 BIT 7 IS EQUAL TO A ZERO. ┬IT 6, IS USED TO INDICATE WHEN NEW VALUES HAVE BEEN LATCHED INTO THE LIGHTPEN REGISTERS (16-17). ┬IT 5, ╓┬LANK REFERS TO WHEN THE 8563 IS IN THE PERIOD KNOWN AS "╓ERTICAL ┬LANKING ╨ERIOD". ╒SUALLY, HOWEVER THIS BIT IS SELDOM REFERRED TO AS UPDATING THE 8563 IS USALLY TOO SLOW TO MAKE USE OF THIS FOR ANY SPECIAL EFFECTS. ┬ITS 0-2 RETURN A VERSION # OF WHICH %000 AND %001 ARE THE KNOWN VERSIONS OUT. ┼ARLY 128'S WILL CONTAIN THE VALUE OF $0 WHILE LATER 128'S WILL CONTAIN THE VALUE OF $1. ╬OTE THAT THERE ARE SLIGHT DIFFERENCES BETWEEN THE 8563'S, IN THAT REGISTER 25 (HORIZONTAL SMOOTH SCOLL REGISTER) REQUIRES DIFFERENT SETTINGS. ╘HE REGISTER AT $D601 RETURNS THE VALUE OF REGISTER # THAT HAS BEEN WRITTEN INTO $D601 (WHEN BIT 7 OF $D600 = %1). ╬OTE THAT STORING A VALUE HERE WILL ALSO DO A WRITE INTO THE REGISTER # SELECTED. (╥EFER TO THE ═╠ ROUTINES FOR STORING AND READING VALUES TO/FROM REGISTERS AT THE END OF THIS ARTICLE FOR AN EXAMPLE). ------------------------ ▄ ╥EGISTER ─EFINITIONS ▄ ------------------------ ╥EG# 7 6 5 4 3 2 1 0 ─ESCRIPTION ╬OTES ------- ---- ---- ---- ---- ---- ---- ---- ---- ------------------------ ----- 0 ╚Z╘7 ╚Z╘6 ╚Z╘5 ╚Z╘4 ╚Z╘3 ╚Z╘2 ╚Z╘1 ╚Z╘0 ╚ORIZONTAL ╘OTAL ^1 1 ╚Z─7 ╚Z─6 ╚Z─5 ╚Z─4 ╚Z─3 ╚Z─2 ╚Z─1 ╚Z─0 ╚ORIZONTAL ─ISPLAYED ^1 2 ╚Z╙7 ╚Z╙6 ╚Z╙5 ╚Z╙4 ╚Z╙3 ╚Z╙2 ╚Z╙2 ╚Z╙0 ╚ORIZONTAL ╙YNC ╨OSITION ^1 3 ╓╙╫3 ╓╙╫2 ╓╙╫1 ╓╙╫0 ╚╙╫3 ╚╙╫2 ╚╙╫1 ╚╙╫0 ╓ERT/╚ORIZ. ╙YNC ╫IDTH ^2 4 ╓E╘7 ╓E╘6 ╓E╘5 ╓E╘4 ╓E╘3 ╓E╘2 ╓E╘1 ╓E╘0 ╓ERTICAL ╘OTAL ^3 5 .... .... .... ╓E┴4 ╓E┴3 ╓E┴2 ╓E┴1 ╓E┴0 ╓ERTICAL ╘OTAL ╞INE ┴DJU ^3 6 ╓E─7 ╓E─6 ╓E─5 ╓E─4 ╓E─3 ╓E─2 ╓E─1 ╓E─0 ╓ERTICAL ─ISPLAYED ^3 7 ╓E╙7 ╓E╙6 ╓E╙5 ╓E╙4 ╓E╙3 ╓E╙2 ╓E╙1 ╓E╙0 ╓ERTICAL ╙YNC ╨OSITION ^2 8 .... .... .... .... .... .... ╔LC1 ╔LC0 ╔NTERLACE ═ODE ^4 9 .... .... .... ├╘╓4 ├╘╓3 ├╘╓2 ├╘╓1 ├╘╓0 ├HARACTER ╘OTAL ╓ERTICAL ^5 10 .... ├R═1 ├R═0 ├SS4 ├SS3 ├SS2 ├SS1 ├SS0 ├URSOR ═ODE/ ╙TART ╙CAN ^6 11 .... .... .... ├ES4 ├ES3 ├ES2 ├ES1 ├ES0 ├URSOR ┼ND ╙CAN ^6 12 ─S15 ─S14 ─S13 ─S12 ─S11 ─S10 ─S09 ─S08 ─ISPLAY ╙TART ┴DRS (╚I) ^7 13 ─S07 ─S06 ─S05 ─S04 ─S03 ─S02 ─S01 ─S00 ─ISPLAY ╙TART ┴DRS (╠O) ^7 14 ├P15 ├P14 ├P13 ├P12 ├P11 ├P10 ├P09 ├P08 ├URSOR ╨OSITION (╚I) ^7 15 ├P07 ├P06 ├P05 ├P04 ├P03 ├P02 ├P01 ├P00 ├URSOR ╨OSITION (╠O) ^7 16 ╠P╓7 ╠P╓6 ╠P╓5 ╠P╓4 ╠P╓3 ╠P╓2 ╠P╓1 ╠P╓0 ╠IGHT ╨EN ╓ERITCAL ^8 17 ╠P╚7 ╠P╚6 ╠P╚5 ╠P╚4 ╠P╚3 ╠P╚2 ╠P╚1 ╠P╚0 ╠IGHT ╨EN ╚ORIZONTAL ^8 18 ╒A15 ╒A14 ╒A13 ╒A12 ╒A11 ╒A10 ╒A09 ╒A08 ╒PDATE ┴DDRESS (╚I) ^9 19 ╒A07 ╒A06 ╒A05 ╒A04 ╒A03 ╒A02 ╒A01 ╒A00 ╒PDATE ┴DDRESS (╠O) ^9 20 ┴T15 ┴T14 ┴T13 ┴T12 ┴T11 ┴T10 ┴T09 ┴T08 ┴TTRIBUTE ╙TART ┴DRS (╚I) ^7 21 ┴T07 ┴T06 ┴T05 ┴T04 ┴T03 ┴T02 ┴T01 ┴T00 ┴TTRIBUTE ╙TART ┴DRS (╠O) ^7 22 ╚C╨3 ╚C╨2 ╚C╨1 ╚C╨0 ╔C╙3 ╔C╙2 ╔C╙1 ╔C╙0 ╚Z ├HR ╨XL ╘TL/╔├HAR ╙PC ^┴ 23 .... .... .... ╓C╨4 ╓C╨3 ╓C╨2 ╓C╨1 ╓C╨0 ╓ERT. ├HARACTER ╨XL ╙PC ^5 24 ┬LK═ ╥VS╙ ╓SS5 ╓SS4 ╓SS3 ╓SS2 ╓SS1 ╓SS0 ┬LOCK/╥VS ╙CR/╓. ╙CROLL ^9^┬^├ 25 ╘EXT ┴TRI ╙EMI ─BLE ╚SS3 ╚SS2 ╚SS1 ╚SS0 ─IFF. ═ODE ╙W/╚. ╙CROLL ^─,^┼ 26 ╞GD3 ╞GD2 ╞GD1 ╞GD0 ┬GD3 ┬GD2 ┬GD1 ┬GD0 ╞ORE╟ROUND/┬ACK╟ROUND ├OL ^╞ 27 ╥IN7 ╥IN6 ╥IN5 ╥IN4 ╥IN3 ╥IN2 ╥IN1 ╥IN0 ╥OW/┴DRS. ╔NCREMENT ^╟ 28 ├╙A2 ├╙A1 ├╙A0 ╥AM╘ .... .... .... .... ├HARACTER ╙ET ┴DDRS/╥AM ^╚,^╔ 29 .... .... .... ╒D╠4 ╒D╠3 ╒D╠2 ╒D╠1 ╒D╠0 ╒NDERLINE ╙CAN ╠INE ^6 30 ╫D├7 ╫D├6 ╫D├5 ╫D├4 ╫D├3 ╫D├2 ╫D├1 ╫D├0 ╫ORD ├OUNT (-1) ^9 31 ─TA7 ─TA6 ─TA5 ─TA4 ─TA3 ─TA2 ─TA1 ─TA0 ─ATA ^9 32 ┬LK╞ ┬LK┼ ┬LK─ ┬LK├ ┬LK┬ ┬LK┴ ┬LK9 ┬LK8 ┬LOCK ├OPY ╙OURCE (HI) ^9 33 ┬LK7 ┬LK6 ┬LK5 ┬LK4 ┬LK3 ┬LK2 ┬LK1 ┬LK0 ┬LOCK ├OPY ╙OURCE (LO) ^9 34 ─E┬7 ─E┬6 ─E┬5 ─E┬4 ─E┬3 ─E┬2 ─E┬1 ─E┬0 ─ISPLAY ┼NABLE ┬EGIN ^╩ 35 ─E┼7 ─E┼6 ─E┼5 ─E┼4 ─E┼3 ─E┼2 ─E┼1 ─E┼0 ─ISPLAY ┼NABLE ┼ND ^╩ 36 .... .... .... .... ─RM3 ─RM2 ─RM1 ─RM0 ─╥┴═ ╥EFRESH ╥ATE ^╦ +-----------------+ ▄ ╥EGISTER ╒SAGE: ▄ +-----------------+ ^1 : ╥EGISTER #0: ╚ORIZONTAL ╘OTAL --- ╥EGISTER #1: ╚ORIZONTAL ─ISPLAYED ╥EGISTER #2: ╚ORIZONTAL ╙YNC ╨ULSE ╘HESE TWO REGISTER FUNCTION TO DEFINE THE DISPLAY WIDTH OF THE SCREEN. ╥EGISTER 0 WILL CONTAIN THE NUMBER OF CHARACTERS MINUS 1 BETWEEN SUCESSIVE HORIZONTAL SYNC PULSES, THE HORIZONTAL BORDER AND THE INTERVAL BETWEEN HORIZONTAL SYNC PULSES. ╘HE NORMAL VALUE FOR THIS IS USUALLY SET TO 126. ╥EGISTER 1 SPECIFIES HOW MANY OF THE POSITIONS AS SPECIFIED IN REGISTER 0 CAN ACTUALLY BE USED TO DISPLAY CHARACTERS. ╘HE DEFAULT VALUE FOR THIS IS 80. ╘HE ╓─├ CAN TAKE VALUES LESS THAN 80 AND THUS, WILL ONLY DISPLAY THAT MANY CHARACTERS. ┴ USEFUL EFFECT CAN BE A SWEEP FROM THE RIGHT BY INCREMENTING THE VALUE HERE FROM 1 TO 80. ╥EGISTER #2 SPECIFIES THE STARTING CHARACTER POSITION AT WHICH THE VERTICAL SYNC PULSE BEGINS. ╘HUS, IT ALSO DETERMINES WHERE ON THE ACTIVE SCREEN CHARACTERS APPEAR. ┴ DEFAULT VALUE OF 102, INCREASING THE VALUE MOVES THE SCREEN TO THE LEFT, DECREASING IT MOVES IT TO THE RIGHT. ^2 : ╥EGISTER #3: ╓ERTICAL / ╚ORIZONTAL ╙YNC ╨OSITION. ---- ╥EGISTER #7: ╓ERTICAL ╙YNC ╨OSITION ╔N ╥EGISTER 3, ┬ITS 0-3 OF THIS REGISTER SPECIFIES THE HORIZONTAL SYNC WIDTH AND SHOULD BE EQUAL TO 1 + THE NUMBER OF PIXELS PER CHARACTER. ╘HUS, THE VALUE HERE IS NORMALLY 1+8 OR 9. ┬ITS 4-7 OF REGISTER 3 SPECIFY THE VERTICAL SYNC WIDTH AND NORMALLY CONTAINS A VALUE OF 4. ╞OR INTERLACE SYNC AND VIDEO MODE, USE A VALUE THAT IS TWICE THE NUMBER OF SCAN LINES DESIRED. ╥EGISTER #7 ALLOWS FOR ADJUSTMENT OF WHERE THE VERTICAL SYNC WILL BE GENERATED ALLOWING SHIFTING OF THE ACTUAL DISPLAY UP AND DOWN. ╬ORMALLY, A VALUE OF 4, DECREASING THE VALUE WILL MOVE THE SCREEN DOWN, INCREASING IT WILL APPEAR TO MOVE IT UPWARDS. ^3 : ╥EGISTER #4: ╓ERTICAL ╘OTAL ---- ╥EGISTER #5: ╓ERTICAL ╘OTAL ╞INE ┴DJUST ╥EGISTER #6: ╓ERTICAL ─ISPLAYED ╥EGISTER #4 OF THIS REGISTER DETERMINES THE TOTAL NUMBER OF SCREEN ROWS, INCLUDING THE ROWS FOR THE ACTIVE DISPLAY, AND THE TOP AND BOTTOM BORDERS IN ADDITION TO THAT OF THE VERTICAL SYNC WIDTH. ╘HE VALUE HELD HERE IS NORMALLY A VALUE OF 32 FOR ╬╘╙├ SYSTEMS (╒╙ ╙TANDARD) OR 39 FOR ╨┴╠(┼UROPEAN) SYSTEMS. ╥EGISTER #5 HOLDS IN BITS 0-4 A "FINE-ADJUST" WHERE ANY EXTRA SCAN LINES THAT ARE NECESSARY TO MAKE UP THE DISPLAY CAN BE SPECIFIED HERE. ╘HE VALUE HERE IS NORMALLY A 0 IN BOTH THE ╬╘╙├ AND ╨┴╠ INITIALIZATIONS BY THE KERNAL AND BITS 5-7 ARE UNUSED, ALWAYS RETURNING A BINARY 1111. ╥EGISTER #6 SPECIFIES THE TOTAL NUMBER OF THE VERTICAL CHARACTER POSITIONS (AS SET IN ╥EGISTER 4) THAT CAN BE USED FOR ACTUAL DISPLAY OF CHARACTERS. ╘HUS, THIS REGISTER USUALLY HOLDS A VALUE OF 25 FOR A STANDARD 25-ROW DISPLAY. ^4 : ╥EGISTER #8: ╔NTERLACE ═ODE ├ONTROL ---- ╥EGISTER 8 ALLOWS CONTROL OF VARIOUS DISPLAY MODES THE 8563 CAN GENERATE. ┬ITS 0 AND 1 ARE THE ONLY BITS USED IN THIS REGISTER, THE REST ALWAYS READING A BINARY 1. ┬ITS 0 AND 1 ARE CONFIGURED AS FOLLOWS: ┬INARY %00, %10 - ╬ON╔NTERLACED ═ODE %01 - ╔NTERLACED ╙YNC %11 - ╔NTERLACED ╙YNC AND ╓IDEO ╬OTE THAT THE DEFAULT VALUE IS $00 WHICH IS STANDARD, NON-INTERLACED. ╔NTERLACED SYNC DRAWS EACH HORIZONTAL SCAN LINE TWICE BUT APPEARS TO SUFFER FROM AN ANNOYING JITTER DUE TO HOW IT IS DRAWN. ╔NTERLACED ╙YNC AND ╓IDEO DRAWS TWICE AS MANY LINES, THUS DOUBLING THE RESOLUTION. ╚OWEVER, IT ALSO SUFFERS FROM JITTER AND THAT IS WHY MOST MONITORS SUFFER HORRIBLY WHEN USING PROGRAMS THAT SUPPORT 30 COLUMNS OR GREATER. ╬OTE THAT FOR INTERLACED SYNC AND VIDEO, THE FOLLOWING REGISTERS WILL NEED TO BE CHANGED: #'S: 0,4,6,7,8. ^5 : ╥EGISTER #9: ╘OTAL ╙CAN ╠INES ╨ER ├HARACTER ---- ┬ITS 0-4 OF THIS REGISTER ARE THE ONLY RELEVANT ONES, THE REST RETURNING A BINARY 1. ┬ITS 0-4 DETERMINE THE CHARACTER HEIGHT IN SCAN-LINES OF DISPLAYED CHARACTERS AND ALLOW UP TO SCAN-LINE HEIGHTS OF 32 SCAN LINES. ╘HE ╓─├ NORMALLY SETS ASIDE 16 BYTES FOR EACH CHARACTER (NORMALLY, EACH BYTE IS EQUIVLENT TO 1 SCAN LINE) SO THE VALUE HERE COULD BE INCREASED TO 16-1 AND A DOUBLE-HEIGHT CHARACTER SET COULD BE LOADED IN. ╬OTE, HOWEVER THAT VALUES LESS THAN 16 WILL TELL THE ╓─├ TO USE A 8,192 BYTE CHARACTER SET (NORMAL) WHILE SPECIFYING VALUES GREATER THAN 16 WILL MAKE IT USE 32 BYTES PER CHARACTER EVEN IF SOME OF THE BYTES ARE NOT USED. ^6 : ╥EGISTER #10: ├URSOR ═ODE / ╙TART ╙CAN ╠INE ---- ╥EGISTER #11: ├URSOR ┼ND ╙CAN ╠INE. ╥EGISTER #29: ╒NDER╠INE ╙CAN ╠INE ├ONTROL. ╘HESE REGISTERS ALLOW THE USER TO SPECIFY THE CURSOR BLINK MODE, AS WELL AS THE STARTING AND ENDING SCAN LINES FOR THE CURSOR (ALLOWING A FULL SOLID, AN UNDERLINE, ┬ITS 0-4 OF REGISETER #10 DETERMINES THE SCAN LINE WITHIN EACH POSITION FOR THE TOP OF THE CURSOR. ╬ORMALLY, THIS VALUE HOLDS A VALUE OF 0 FOR THE BLOCK CURSOR, OR A VALUE OF 7 FOR THE UNDERLINE CURSOR. ┬ITS 5-6 OF ╥EGISTER 10 SPECIFY THE BLINK RATE FOR THE CURSOR. ┴ VALUE OF %00 SPECIFIES NO BLINK, IE: A SOLID CURSOR. ┴ VALUE OF %01 SPECIFIES NO CURSOR, A VALUE OF %10 SPECIFIES A FLASH RATE OF 1/16 THE SCREEN REFRESH RATE, WHILE A VALUE OF %11 SPECIFIES A FLASH RATE OF 1/32 THE SCREEN REFRESH RATE. ╬OTE THAT BIT 7 OF ╥EGISTER 10 IS UNUSED AND NORMALLY RETURNS A BINARY 1. ╥EGISTER 11 SPECIFIES THE BOTTOM SCAN LINES IN BITS 0-4, THE OTHER UNUSED BITS RETURNING A BINARY 1. ╘HE VALUE HELD IN THESE BITS USUALLY IS 7 FOR THE BLOCK AND UNDERLINE CURSOR MODES IN THE NORMAL 128 EDITOR. ╥EGISTER #29 IS USED TO INDICATE WHERE THE SCAN LINE IS "SET" IN THE CHARACTER. ╘HE "UNDERLINE" IS ONLY 1 PIXEL TALL AND THUS, THIS LOCATION JUST INDICATES THE START AND END LOCATION IN PIXELS, SIMILAIR TO REGISTERS #10 AND #11 BEING THE SAME VALUE. ╬OTE THAT BITS 5-7 OF THIS REGISTER IS UNUSED AND NORMALLY RETURN A BINARY 1. ^7 : ╥EGISTER #12: ─ISPLAY ╙TART ┴DDRESS (╚I) ---- ╥EGISTER #13: ─ISPLAY ╙TART ┴DDRESS (╠O) ╥EGISTER #14: ├URSOR ╨OSITION (╚I) ╥EGISTER #15: ├URSOR ╨OSITION (╠O) ╥EGISTER #20: ┴TTRIBUTE ╙TART ┴DDRS (╚I) ╥EGISTER #21: ┴TTRIBUTE ╙TART ┴DDRS (╠O) ╬OTE FIRST, THAT ALL OF THESE REGISTERS ARE GROUPED IN ╚I BYTE, ╠O BYTE ORDER WHICH IS USUALLY DIFFERENT FROM THE 6502 CONVENTION OF LOW BYTE, HI BYTE (IE: IN NORMAL 6502 ML, $C000 IS STORED AS $00 $C0, HOWEVER IN THE 8563 IT WOULD BE STORED AS $C0 $00). ╥EGISTERS 12 AND 13 DETERMINE, WHERE IN ╓─├ MEMORY THE 8563 IS THE START OF THE SCREEN. ╔NCREMENTING THIS VALUE BY 80 (THE NUMBER OF CHARACTERS PER LINE) AND WITH A LITTLE ADDITIONAL WORK CAN PROVIDE A VERY EFFECIENT WAY OF HAVING A SCREEN THAT "SEEMS" TO BE LARGER THAN JUST 80X25. ╘HE CURSOR POSITION IN REGISTERS 14 AND 15 REFLECT THE ACTUAL CHARACTER IN MEMORY THAT THE CURSOR CURRENTLY LIES OVER. ╔F IT'S NOT ON THE DISPLAY SCREEN, THEN IT IS NOT DISPLAYED. ╥EGISTERS 20 AND 21 REFLECT WHERE IN THE 8563 MEMORY ATTRIBUTE MEMORY IS HELD. ┴TTRIBUTE MEMORY REFERS TO THE CHARACTER ATTRIBUTES SUCH AS FLASH, INVERSE VIDEO, COLOR ETC THAT CAN BE SET FOR EACH CHARACTER. ^8 : ╥EGISTER #16: ╠IGHT ╨EN ╓ERTICAL ---- ╥EGISTER #17: ╠IGHT ╨EN ╚ORIZONTAL ╘HESE REGISTERS RETURN THE LIGHT PEN POSITION AND REFER TO THE ACTUAL CHARACTER POSITIONS ON SCREEN (IE: VALUES RANGING FROM 1..25 FOR VERTICAL). ╘HE HORIZONTAL READING WILL NOT CORROSPOND EXACTLY TO CHARACTER POSITIONS, BUT WILL RANGE FROM VALUES OF 27-29 TO 120 DEPENDING ON THE EDGE OF THE SCREEN. ╔T'S RECOMMENDED THAT THE HORIZONTAL CHARACTER POSITION IS GIVEN MORE TOLERANCE THAN THE VERTICAL LIGHT PEN POSITION FOR THIS REASON. ^9 : ╥EGISTER #18: ╒PDATE ┴DDRESS (╚I) ---- ╥EGISTER #19: ╒PDATE ┴DDRESS (╠O) ╥EGISTER #24:7 ├OPY / ╞ILL ┬IT ╥EGISTER #30: ╫ORD ├OUNT(-1) ╥EGISTER #31: ─ATA ╥EGISTER #32: ┬LOCK ├OPY ╙RC (╚I) ╥EGISTER #33: ┬LOCK ├OPY ╙RC (╠O) ╘HESE REGISTERS ALLOW CONTROL AND MANIPULATION OF THE 16K OR 64K BLOCK WITHIN THE 8563 MEMORY. ╥EGISTERS 18 AND 19 POINT TO WHERE IN ╓─├ MEMORY THE NEXT READ OR WRITE WILL TAKE PLACE FROM. ╥EGISTER 30 SPECIFIES THE NUMBER OF BYTES - 1 TO COPY OR FILL DEPENDING ON BIT # 7 OF REGISTER #24. ╬ORMALLY, THE 8563 WILL AUTOMATICALLY PERFORM THE DESIGNATED OPERATION (OF WHAT BIT 7 OF REGISTER #24 SAYS) WHEN REGISTER #31 (THE DATA BYTE) IS WRITTEN TO. ╥EGISTERS 18 AND 19 AUTOMATICALLY UPDATE UPON READ OR WRITE, SO THAT IS WHY REGISTER #30 SPECIFIES A VALUE 1 LESS THAN WHAT IS ACTUALLY NEEDED. ╥EGISTER #31, AS ALREADY MENTIONED IS THE BYTE TO WRITE FOR REGISTER #30 TIMES (OR COPY FROM ╥EGISTER#32 / #33). ╔F REGISTER #24, BIT 7 IS SPECIFIED AS A BINARY 1 THEN THE MEMORY IS COPIED FROM THE ADDRESS IN ╓─├ MEMORY POINTED TO BY REGISTERS #32 AND #33. ^┴ : ╥EGISTER #22: ├HARACTER ╚ORIZONTAL ╙IZE ├ONTROL ---- ┬ITS 0-3 OF THIS REGISTER DETERMINES HOW MANY HORIZONTAL PIXELS ARE USED FOR EACH DISPLAYED CHARACTER. ╓ALUES GREATER THAN 8 HERE RESULT IN APPARENT GAPS IN THE DISPLAY. ╔NTER-CHARACTER SPACING CAN BE ACHIEVED BY SETTING THIS VALUE GREATER THAN THAT OF BITS 4-7. ┬ITS 4-7 DETERMINE THE WIDTH OF EACH CHARACTER POSITION IN PIXELS. ╘HUS, WHILE BITS 0-3 ALLOCATE N-PIXELS, BITS 4-7 SPECIFY HOW MANY OF THOSE PIXELS ARE USED FOR CHARACTER DISPLAY. ^┬ : ╥EGISTER #24:5 ╥EVERSE ╙CREEN ┬IT ---- ╥EGISTER #24:6 ┬LINK ╥ATE FOR ├HARACTERS. ┬IT #6 SPECIFIES FOR THE ╓─├ FOR ALL PIXELS NORMALLY UNSET ON THE ╓─├ SCREEN TO BE SET, AND ALL SET PIXELS TO BE UNSET. ┬IT #5 SPECIFIES THE BLINK RATE FOR ALL CHARACTERS WITH THE BLINK ATTRIBUTE. ╙ETTING THIS TO A BINARY 1 SPECIFIES A BLINK RATE OF 1/32 THE REFRESH RATE, WHILE A BINARY 0 IS EQUIVLANT TO A BLINK RATE 1/16TH OF THE REFRESH RATE. ^├ : ╥EGISTER #24:0-4 ╓ERTICAL ╙MOOTH ╙CROLL ---- ╘HE 8563 PROVIDES FOR A SMOOTH SCROLL, ALLOWING BITS 0-4 TO FUNCTION AS AN INDICATOR OF THE NUMBER OF BITS TO SCROLL THE SCREEN VERTICALLY UPWARD. ^─ : ╥EGISTER #25:7 ╘EXT OR ╟RAPHICS ═ODE ╔NDICATOR ┬IT ---- ╥EGISTER #25:6 ═ONOCHROME ═ODE ┬IT ╥EGISTER #25:5 ╙EMI-╟RAPHICS ═ODE ╥EGISTER #25:4 ─OUBLE-╨IXEL ═ODE ╘HE 8563 ALLOWS THE IMPLEMENTATION OF A GRAPHICS MODE, IN WHERE ALL OF THE 16K OF THE SCREEN MAY BE BIT-MAPPED SEQUENTIALLY RESULTING IN A RESOLUTION OF 640X200 (SEE ├RAIG ┬RUCE'S 8563 ╠INE-╨LOTTING ROUTINE IN THE FIRST ISSUE FOR A MORE DETAILED EXPLANATION OF THIS FEATURE). ╙ETTING THIS BIT TO 1 SPECIFIES GRAPHICS MODE, BINARY 0 INDICATES TEXT MODE. ┬IT 6 INDICATES TO THE 8563 WHERE TO OBTAIN ITS COLOR INFORMATION ETC, ABOUT THE CHARACTERS. ┬IT 6 WHEN IT IS A BINARY 0 RESULTS IN THE 8563 TAKING IT'S COLOR INFORMATION FROM BITS 4-7 OF REGISTER 26. ╫HEN THIS BIT IS A BINARY 1, THE ATTRIBUTE MEMORY IS USED TO OBTAIN COLOR, FLASH, REVERSE INFORMATION. ┴LSO NOTE THAN WHEN THIS BIT IS A BINARY 1 THAT ONLY THE FIRST OF THE TWO CHARACTER SETS IS AVAILABLE. ┬IT #5 INDICATES A SEMI-GRAPHICS MODE THAT ALLOWS THE RIGHTMOST PIXEL OF ANY CHARACTERS TO BE REPEATED THROUGH-OUT THE INTERCHARACTER SPACING GAP. ┴CTIVATING IT ON THE NORMAL DISPLAY WILL RESULT IN WHAT APPEARS TO BE A "DIGITAL" CHARACTER FONT. ╘HE 8563 WITH BIT #4 ALLOWS A PIXEL-DOUBLE FEATURE WHICH RESULTS IN ALL DISPLAYED HORIZONTAL PIXELS HAVING TWICE THEIR USUAL SIZE. ╘HUS, A 40 COLUMN SCREEN IS EASILY OBTAINABLE ALTHOUGH THE VALUES IN REGISTERS #00-#02 MUST BE HALVED. ^┼ : ╥EGISTER #25: ╚ORIZONTAL ╙MOOTH ├ONTROL ---- ╘HIS REGISTER IS ANALOGOUS TO REGISTER #24 ╓ERTICAL ╙MOOTH ├ONTROL AND FUNCTIONS SIMILAIRLY. ╔NCREASING THIS BITS MOVES THE SCREEN ONE PIXEL TO THE RIGHT, WHILE DECREASING THEM MOVES THE SCREEN ONE PIXEL TO THE LEFT. ^╞ : ╥EGISTER #26: ╞ORE╟ROUND / ┬ACK╟ROUND ├OLOR ╥EGISTER ---- ╘HIS REGISTER, IN BITS 0-3 SPECIFIES THE BACKGROUND COLOR OF THE DISPLAY WHILE BITS 4-7 SPECIFY THE FOREGROUND CHARACTER COLORS WHEN ATTRIBUTES ARE DISABLED (VIA BIT 6 OF REGISTER #25). ╬OTE, THESE ARE NOT THE USUAL ├= COLORS BUT ARE INSTEAD ORGANIZED AS FOLLOWS: ┬IT ╓ALUE ─ECIMAL ╓ALUE ├OLOR ---------------------------------- +-----------------------------+ %0000 0 / $00 ┬LACK ▄ ╬OTE: ┬IT 0 = ╔NTENSITY ▄ %0001 1 / $01 ─ARK ╟RAY ▄ ┬IT 1 = ┬LUE ▄ %0010 2 / $02 ─ARK ┬LUE ▄ ╥╟┬╔ ┬IT 2 = ╟REEN ▄ %0011 3 / $03 ╠IGHT ┬LUE ▄ ┬IT 3 = ╥ED ▄ %0100 4 / $04 ─ARK ╟REEN ▄ ▄ %0101 5 / $05 ╠IGHT ╟REEN +-----------------------------+ %0110 6 / $06 ─ARK ├YAN %0111 7 / $07 ╠IGHT ├YAN %1000 8 / $08 ─ARK ╥ED %1001 9 / $09 ╠IGHT ╥ED %1010 10 / $0┴ ─ARK ╨URPLE %1011 11 / $0┬ ╠IGHT ╨URPLE %1100 12 / $0├ ─ARK ┘ELLO %1101 13 / $0─ ╠IGHT ┘ELLOW %1110 14 / $0┼ ╠IGHT ╟RAY (─ARK ╫HITE) %1111 15 / $0╞ ╫HITE ^╟ : ╥EGISTER #27: ╥OW ┴DDRESS ─ISPLAY ╔NCREMENT ---- ╘HIS REGISTER SPECIFIES THE NUMBER OF BYTES TO SKIP, WHEN DISPLAYING CHARACTERS ON THE 8563 SCREEN. ╬ORMALLY, THIS BYTE HOLDS A VALUE OF $00 INDICATING NO BYTES TO SKIP; HOWEVER TYPICALLY PROGRAMS THAT "SCROLL" THE SCREEN DO SO BY SETTING THIS TO 80 OR 160 ALLOWING THE PROGRAM TO THEN ALTER THE ╙CREEN ╙TART (╥EGISTERS #12 AND #13) AND APPEAR TO "SCROLL". ╬OTE THE NORMAL ├= 128 ╦ERNAL ╙CREEN ┼DITOR DOES NOT SUPPORT THIS FUNCTION. ^╚ : ╥EGISTER #28:7-5 ├HARACTER ╙ET ┴DDRESS ---- ╘HESE BITS INDICATE THE ADDRESS OF SCREEN MEMORY * 8K. ╘HUS THE VALUES IN THESE BITS MAY BE MULTIPLIED BY 8192 TO OBTAIN THE STARTING CHARACTER SET POSITION (NORMALL THESE BITS HOLD A VALUE OF $01 INDICATING THE CHARACTER SET BEGINS AT 8192). ╬OTE THAT THE CHARACTER SET IS NOT IN ╥╧═, BUT IS USUALLY COPIED TO 8192 WHEN THE COMPUTER IS FIRST TURNED ON AND THE 8563 IS INITIALIZED. (┼XAMINE THE ╔╬╔╘80 ROUTINE AT $├┼0├ IN BANK 15). ^╔ : ╥EGISTER #28:4 ╥AM ├HIP ╘YPE ---- ╘HIS BIT SPECIFIES WHETHER 16K OR 64K OF ╥┴═ HAS BEEN INSTALLED. ╬OTE, HOWEVER THAT THIS VALUE MAY NOT REFLECT FUTURE UPGRADES FROM 16K TO 64K. ╔T IS BEST, IF A PROGRAM IS DEPENDANT ON 64K TO WRITE TO AN ADDRESS > 16K AND SEE IF IT IS MIRRORED AT ANY OTHER LOCATION IN ANOTHER SECTION OF MEMORY. ╘HIS BIT HAS A BINARY VALUE OF 0 IF 16K OR 1 IF 64K ╥┴═. ^╩ : ╥EGISTER #34: ─ISPLAY ┼NABLE ┬EGIN ---- ╥EGISTER #35: ─ISPLAY ┼NABLE ┼ND ╘HE 8563 CAN EXTEND IT'S HORIZONTAL BLANKING INTERVAL TO BLANK A PORTION OF THE DISPLAYED SCREEN. ╘HE VALUE IN REGISTER #34 DETERMINES THE RIGHTMOST BLANKED COLUMN, AND REGISTER #35 DETERMINES THE LEFTMOST BLANKED COLUMN. ╬OTE THAT A VALUE OF 6 USUALLY CORRESPONDS TO THE LEFTMOST COLUMN OF THE SCREEN, WHILE A VALUE OF 85 CORRESPONDS TO THE RIGHTMOST COLUMN. ╘HIS FEATURE IS USEFUL FOR "INSIDE-OUT" WRAPS IN WHICH BOTH THE RIGHT AND LEFT MARGIN CAN CLOSE-IN ON TEXT, THE TEXT CAN BE CLEARED, THESE VALUES RESET ETC... ^╦ : ╥EGISTER #36: ╥EFRESH ├YCLES PER ╙CAN ╠INE ---- ╘HIS REGISTER IN BITS 0-3 ALLOWS THE USER (IF HE HAD ANY REASON) TO SPECIFY THE NUMBER OF REFRESH CYCLES FOR MEMORY FOR THE RAM. ╙ETTING THIS VALUE TOO LOW MAY CAUSE THE ╥┴═ TO NOT REMEMBER ALL THE INFORMATION. ├HANGING THIS VALUE GIVES SOME ADVANTAGE, IN TERMS OF DISPLAY SPEED INCREASES BUT IS NOT ADVISED. ╘HE VALUE NORMALLY HELD HERE IS $05, FOR FIVE REFRESH CYCLES PER SCAN LINE. +--------------------------+ ▄ 8563 ═EMORY ╧RGANIZATION ▄ +--------------------------+ ╬ORMALLY, THE EXTRA MEMORY OF THE ├=128'S EQUIPPED WITH 64K GOES UNUSED (48K WORTH) UNLESS PROGRAMS LIKE ┬ASIC-8 ETC, TAKE ADVANTAGE OF IT. ╘HERE ARE VARIOUS MOD FILES DESCRIBING THE UPGRADE FROM 16K TO 64K AND IT IS _STRONGLY_ ADVISED (ALTHOUGH THE AUTHOR HAS NOT YET DONE SO) AND BE AWARE THAT ***╧╨┼╬╔╬╟ ┘╧╒╥ ├╧═╨╒╘┼╥ ╩╒╙╘ ╘╧ ╠╧╧╦, ┘╧╒ ═┴┘ ═┼╙╙ ╔╘ ╒╨*** AND IT IS _STRONGLY_ ADVISED THAT YOU CONTACT A PERSON EXPERIENCED WITH ELECTRONICS TO PERFORM THE UPGRADE FOR YOU. ╬OTE ALSO THAT SOME MAIL ORDER COMPANIES ARE OFFERING AN "UP-GRADE BOARD" WHICH PLUGS INTO THE 8563 SLOT AND DOES NOT INVOLVE DISAUDERING THE ╥┴═ CHIPS. ╬OW, THE 8563 USES THE 16K OF MEMORY (IT IGNORES THE EXTRA 48K OF MEMORY WHEN IT'S GOT 64K, THUS THE FOLLOWING APPLIES ALSO TO THE 8563'S EQUIPPED WITH 64K OF MEMORY) AND NORMALLY, HAS THE FOLLOWING MEMORY MAP: $0000 - $07FF - ╙CREEN ═EMORY $0800 - $0FFF - ┴TTRIBUTE ═EMORY $1000 - $1FFF - ╒NUSED $2000 - $2FFF - ╒PPER├ASE / ╟RAPHIC ├HARACTER ╙ET (├HAR ╙ET #1) $3000 - $3FFF - ╠OWER├ASE / ╒PPER├ASE ├HARACTER ╙ET (├HAR ╙ET #2) +---------------------------+ ▄ ╫RITING TO 8563 ╥EGISTERS ▄ +---------------------------+ ╬OW HOW DO WE WRITE TO THESE REGISTERS WE'VE LEARNED SO MUCH ABOUT? ╘HERE'S SEVERAL WAYS DEPENDING ON HOW LAZY YOU ARE. ╘HE PURE-ML VERSION: ╫╥╔╘╔╬╟ ╘╧ ┴ ╥┼╟╔╙╘┼╥: WRITEREG = * ; THIS ROUTINE WRITES .A TO REGISTER # .X, ┴SSSUMES ╔/╧ BLOCK IN STX $D600 - LDX $D600 BPL - STA $D601 RTS ALSO, IN BANK 15 THERE IS A SIMILAIR ROUTINE AT $CDCC. ├ALLING IT AT $CDCA LOADS .X WITH A VALUE OF 31 INDICATING THE DATA REGISTER WHICH IS OFTEN USEFUL. ╞ROM BASIC, JUST USE A ╙┘╙ 52684, VALUE, REGISTER# ╥┼┴─╔╬╟ ╞╥╧═ ┴ ╥┼╟╔╙╘┼╥: READREG = * ; THIS ROUTINE RETURNS THE CONTENTS OF REGISTER # .X IN .A ; ┴SSUMES ╔/╧ BLOCK SWITCHED IN STX $D600 - LDX $D600 BPL - LDA $D601 OR USE THE ROUTINE IN BANK 15 AT $CDDA. ╞ROM BASIC, A ╙┘╙ 52698,,REGISTER# AND THEN A ╥╥┼╟ ┴ RETURNS THE VALUE IN VARIABLE ┴. +--------------------+ ▄ ╞URTHER 8563 ╬OTES ▄ +--------------------+ ═ANY ├=128 OWNERS ARE STILL USING THEIR MONITORS THEY HAD WHEN THEY HAD THEIR ├=64'S AND ARE ABLE TO USE THE 80 COLUMN SCREEN THROUGH A "CONVERTER-CABLE" (BASICALLY TAKING PIN 7 OF THE ╥╟┬╔ PORT AND FEEDING IT AS RAW VIDEO). ╘HERE IS ALSO A TEXT FILE OUT EXPLAINING HOW TO TAKE THE ╥,╟,┬,╔ PINS ON THAT PORT TO DISPLAY SHADES OF GRAY ON A MONOCHROME MONITOR (BASICALLY TYING RESISTORS WITH DIODES ACROSS EACH COLOR PIN AND THEN JOINING THEM). ╘HERE IS RELIEF!! :-) ╘HE 8563 IS A CHIP FULL OF CABIBILITIES WAITING TO BE FOUND AND DEVELOPED. ╔'D BE INTERESTED IN SEEING ANY CODE / TECHNIQUES THAT READERS OF THIS NET-MAG HAVE FOUND. ╟IVEN THAT ENOUGH ARE SUBMITTED, A POSSIBLE LISTING OF SOME OF THE BETTER TRICKS AND TECHNIQUES MIGHT BE POSSIBLE IN THE FUTURE. =========================================================================== ╞╔╠┼ ╙╨╠╔╘╘┼╥ - ═ARK ╠AWRENCE 9152427D@LEVELS.UNISA.EDU.AU ============= ╘HIS PROGRAM STEMMED FROM THE INABILITY OF ╪╠╔╬╦ TO TRANSFER ├╙-─╧╙ FROM MY PC TO MY 128. ╪╠╔╬╦ TRANSFERS ABOUT 43╦ (╔ THINK), WHEREAS ├╙-─╧╙ WAS ABOUT 48╦. ╥ATHER THAN DO THE WHOLE THING AT ONCE, WHY NOT CUT THE JOB UP INTO MORE SIZEABLE PIECES, TRANSFER THE PROGRAM PIECE BY PIECE, AND THEN REASSEMBLE THE PIECES AT THE OTHER END? ┴ND SO EVENTUATED THE BIRTH OF ╙╨╠╔╘ :-) ╙╨╠╔╘, WRITTEN ENTIRELY IN ╘URBO ╨ASCAL, ALLOWS YOU TO SPLIT ─╧╙ FILES INTO SMALLER PIECES - YOU CAN EITHER TELL IT A SIZE TO SPLIT THE FILES INTO, OR TELL IT A NUMBER OF FILES TO CREATE. ┘OU THEN GIVE ╙╨╠╔╘ THE BASE FILENAME FOR THE NEW FILES ╫╔╘╚ ╬╧ ┼╪╘┼╬╙╔╧╬ - ╙╨╠╔╘ WILL GIVE THE NEW FILES THEIR OWN EXTENSIONS, AND ╙╨╠╔╘ WILL THEN CREATE THESE FILES TO YOUR LIKING. ╩UST TRANSFER THE FOLLOWING PROGRAM TO ╘URBO, COMPILE IT, AND AWAY YOU GO!!! ╚OPEFULLY, THE PROGRAM IS COMMENTED ENOUGH TO GIVE YOU A FAIR IDEA OF WHAT'S GOING ON - ALTHOUGH IT ISN'T AT ALL COMPLICATED TO UNDERSTAND. ┴T SOME POINTS ╔ HAVE COMMENTS THAT SEEM THE LEAST IMPORTANT - ┼╬─ █ ├┴╙┼ ▌ - THEY ARE TO HELP ME WHEN ╔ PROGRAM... ╔ FIND IT EASY TO LOSE TRACK OF WHICH ┼╬─ IS FOR WHAT, STUFF UP MY INDENTATION, LOST BITS AND PIECES, DELETE THE WRONG PARTS, ETC, ETC. ╔ FOUND IT HELPED ME, SO IT MAY HELP OTHERS. ╔F YOU NEED ANY FURTHER EXPLANATION, JUST LET ME KNOW :-) ┴NOTHER INTERESTING THING ╔ DISCOVERED ABOUT ╪╠╔╬╦. ╔T DOESN'T TRANSFER THE FILES TO THE CORRECT SIZE. ╔ THINK (HAVEN'T HAD TIME TO SIT DOWN AND CHECK IT OUT YET) IT TRANSFERS TO THE NEAREST 256, 512 OR 1024 BYTE BOUNDARY. ╔F YOUR FILE DOESN'T REACH THE BOUNDARY, IT WILL PAD THE REST OUT WITH ZEROES ╔ THINK. ╙O, WHEN YOU GO TO REASSEMBLE THE FILE, IT'S GOT ALL THIS GARBAGE IN PLACES WHERE IT SHOULDN'T BE, AND THE THING WON'T WORK. ╙O, WHEN ╙╨╠╔╘TING A FILE, SPECIFY THE SIZE TO A MULTIPLE OF ONE OF THESE BOUNDARIES. ╘HEN, USING A M/C MONITOR, LOAD ALL THE PARTS IN TOGETHER. ╔'LL TRY TO SET ASIDE A LITTLE TIME IN THE NOT TOO DISTANT FUTURE TO WRITE A M/C PROGRAM TO JOIN THE PARTS FOR YOU, SINCE IT CAN GET CONFUSING REASSEMBLING THE PARTS BY HAND, AND THE BUILT IN DOS COPY THAT COMMODORE SO KINDLY GRACED US WITH IS SO DARNED FAST <COUGH> <COUGH> :-) [┼D. ╬OTE: ╫HILE THE DOS COPY COMMAND IS SLOW.... FOR THOSE OF YOU WHO ARE IMPATIENT TRY USING SOMETHINE LIKE THE FOLLOWING TO JOIN FILES TOGATHER MAKING SURE THAT THERE'S ENOUGH SPACE ON THE DISK: OPEN15,8,15,"C0:NAME=NAME1,NAME2...": CLOSE15] ╙O, GOOD LUCK AND ENJOY! --------------------------------------------------------------------------- ╨ROGRAM ╙PLIT (INPUT,OUTPUT); ╒SES ─OS; █ USES SPECIFIC FILE HANDLING ROUTINES ▌ ╓AR ╔N╞ILE,╧UTFILE : ╞ILE OF ┬YTE; ├OUNT,╬UMBER,╙IZE,╬EW╙IZE, ╠AST,├OUNTER : ╠ONGINT; ╔N╞ILE╬AME,╬EWFILE,╧UT╞ILE╬AME: ╙TRING; ╙,╨ : ╨ATH╙TR; ─ : ─IR╙TR; ╬ : ╬AME╙TR; ┼ : ┼XT╙TR; ╙PLIT╘YPE,├HECK : ├HAR; ─ATA : ┬YTE; ┼XTENSION : ╙TRING[3]; ┬EGIN ╞OR COUNT := 1 TO 25 DO ╫RITELN; █ ─UMB WAY TO CLEAR THE SCREEN :-) ▌ ╫RITELN ('*********************************************************'); ╫RITELN ('* ╞╔╠┼ ╙╨╠╔╘╘╔╬╟ ╒╘╔╠╔╘┘ ╓0.01 (├) 1992 ═┴╥╦ ╠┴╫╥┼╬├┼ *'); ╫RITELN ('* (-: ═┴─┼ ╔╬ ┴╒╙╘╥┴╠╔┴ :-) *'); ╫RITELN ('*********************************************************'); ╫RITELN; ╫RITE ('┼NTER ╞ILENAME (INCLUDING DRIVE AND PATH) '); ╥EAD╠N (╔N╞ILE╬AME); ╫RITELN; ╞OR COUNT := 1 TO LENGTH (╔N╞ILE╬AME) DO ╔N╞ILE╬AME[COUNT] := ╒P├ASE ( ╔N╞ILE╬AME[COUNT] ); █ CHANGE FILENAME TO ALL UPPERCASE CHARACTERS ▌ ╞╙PLIT(╔N╞ILE╬AME,D,N,E); █ SPLIT FILENAME INTO IT'S RESPECTIVE PARTS: D - ─IRECTORY N - ╬AME E - ┼XTENSION ▌ ╙ := ╞╙EARCH(╔N╞ILE╬AME,╟ET┼NV(─)); █ SEARCH FOR FILE ╞╔╠┼╬┴═┼ IN DIRECTORY ─ ▌ IF ╙ = '' THEN WRITELN ('*┼╥╥╧╥* ╞ILE "',╔N╞ILE╬AME,'" NOT FOUND.') █ ╙ EQUALS '' (NOTHING) IF ╞╔╠┼╬┴═┼ DOESN'T EXIST ▌ ┼LSE ┬EGIN ┴SSIGN (╔NFILE,╔N╞ILE╬AME); ╥ESET (╔NFILE); █ ╧PEN THE ╔NPUT ╞ILE ▌ ╙IZE := ╞ILE╙IZE (╔N╞ILE); █ ╟ET FILE SIZE ▌ ╫RITELN ('╞ILE╬AME: ',╔N╞ILE╬AME); ╫RITELN ('╞ILE╙IZE: ',╙IZE,' ┬YTES.'); ╫RITELN; █ ╙HOW FILE INFO ▌ ╫RITELN ('╔N WHICH WAY WOULD YOU LIKE THE FILE SPLIT?'); ╫RITELN (' (A) ╬UMBER OF ┬YTES.'); ╫RITELN (' (B) ╬UMBER OF ╞ILES.'); ╥EPEAT ╫RITE ('┼NTER YOUR SELECTION '); ╥EADLN (╙PLIT╘YPE); ╙PLIT╘YPE := ╒P├ASE(╙PLIT╘YPE); ╒NTIL (╙PLIT╘YPE >= '┴') AND (╙PLIT╘YPE <= '┬'); █ LET USER CHOOSE WHICH WAY TO SPLIT FILE ▌ ╫RITELN; ├ASE ╙PLIT╘YPE OF '┴': ┬EGIN █ SPLIT BY NUMBER OF BYTES ▌ ╫RITE ('┼NTER BYTE SIZE OF NEW FILES '); ╥EADLN (╬EW╙IZE); ╫RITELN; ╔F (╬EW╙IZE > ╙IZE) THEN ╫RITELN ('╚EY - ┼VEN ╔ CAN''T DO THAT!!!') ┼LSE BEGIN ╬UMBER := ╙IZE DIV ╬EW╙IZE; ╠AST := ╙IZE - ╬UMBER * ╬EW╙IZE; ╬UMBER := ╬UMBER + 1; ╫RITE ('┼NTER ┬ASE ╞ILENAME (INCLUDING DRIVE AND PATH) '); ╥EADLN (╬EW╞ILE); ╫RITELN; ╫RITELN ('├REATING ',╬UMBER,' NEW FILES...'); ┼ND; ┼ND; █ ┴ ▌ '┬': ┬EGIN █ ╙PLIT BY FILE SIZE ▌ ╫RITE ('┼NTER NUMBER OF NEW FILES: '); ╥EADLN(╬UMBER); ╫RITELN; ╬EW╙IZE := ╙IZE DIV ╬UMBER + 1; ╠AST := ╙IZE - (╬UMBER - 1) * ╬EWSIZE; ╬UMBER := ╬UMBER; ╫RITE ('┼NTER ┬ASE ╞ILENAME (INCLUDING DRIVE AND PATH) '); ╥EADLN (╬EW╞ILE); ╫RITELN; ╫RITELN ('├REATING ',╬UMBER,' NEW FILES...'); ┼ND; █ ┬ ▌ ┼ND; █ ├ASE ▌ ╫RITELN; ╞OR ├OUNT := 1 TO ╬UMBER DO █ ╬╒═┬┼╥ NEW FILES WILL BE CREATED ▌ ┬EGIN ╔F ├OUNT = ╬UMBER THEN ╬EW╙IZE := ╠AST; █ ═ORE OFTEN THAN NOT, THE FILES WON'T DIVIDE EVENLY FROM THE ORIGINAL. ╙O, THE LAST FILE WILL BE SMALLER THAN THE REST. ┬ECAUSE OF THIS, ╔ PREVIOUSLY CALCULATED THE SIZE OF THE FINAL FILE, AND HERE CHECK IF WE'RE UP TO THE LAST PART YET - AND IF WE ARE, ╔ SET THE SIZE OF THE LAST FILE ACCORDINGLY ▌ ╙TR(├OUNT,┼XTENSION); █ ═AKE ┼╪╘┼╬╙╔╧╬ A STRING REPRESENTATION OF ├╧╒╬╘, TO BE ADDED TO THE ╧UT╞ILE╬AME TO MAKE THINGS A TAD EASIER ▌ ╧UT╞ILE╬AME := ├ONCAT(╬EW╞ILE,'.',├OPY('00',1,3-╠ENGTH(┼XTENSION)),┼ █ ├REATE FILENAME BASED ON WHICH PART WE'RE UP TO ▌ ┴SSIGN (╧UT╞ILE,╧UT╞ILE╬AME); ╥EWRITE (╧UTFILE); █ ╧PEN EACH ╧UTPUT ╞ILE ▌ ╫RITE ('├REATING ',╧UT╞ILE╬AME,'... '); ╞OR ├OUNTER := 1 TO ╬EW╙IZE DO █ ╫RITE TO EACH ╧UTPUT ╞ILE ▌ ┬EGIN ╥EAD (╔NFILE,─ATA); ╫RITE (╧UT╞ILE,─ATA); █ ╘RANSFER DATA FROM INPUT FILE TO OUTPUT FILE ▌ ┼ND; ├LOSE (╧UTFILE); █ ├LOSE EACH ╧UTPUT ╞ILE ▌ ╫RITELN ('─ONE!');