CBM Funet Archive

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

/ CBM Funet Archive / cbm-funet-archive-2003.iso / cbm / geos / programming / documents / geoProgrammer.txt < prev next >

Wrap

Text File | 1998-01-11 | 115.4 KB | 3,102 lines

hITCHhIKER'S gUIDE tO gEOpROGRAMMER v2.0 ---------------------------------------- tHIS DOCUMENT CONTAINS A COLLECTION OF WORKING DOCUMENTS CONCERNING GEOpROGRAMMER v2.0. aS THERE IS NO USER'S MANUAL, THESE FILES WILL HAVE TO SUFFICE FOR NEW USERS. eRIC e. dEL sESTO, dECEMBER 1990. gENERAL: FEATURESv2 round1 versions verstats upgrade_to_v2 todo gEOaSSEMBLER: GEOaSSEMtodo gEOlINKER: GEOlINKtodo gEOdEBUGGER: GEOdEBUGtodo GEOdEBUGsPECSreadme iNITfORiobUG reunOTES reuBUGS APPtYPES MEMpROTECT CBMaPPS HIDEmODE INTERRUPTS NMI RBOOTwARN VIEWcOMMAND ENVIRONMENT WISHlIST NEW: GEOaSSEMBLER, GEOlINKER, AND GEOdEBUGGER TAKE FULL ADVANTAGE OF EXTRA MEMORY AND 2 mhz PROCESSOR SPEED OF cOMMODORE 128 AND 128d COMPUTERS. nOW: FASTER AND MORE MEMORY-EFFICIENT! gEOpROGRAMMER iMPROVEMENTS iN vERSION 2.0 gEOaSSEMBLER: ONE PROGRAM RUNS UNDER geos 64 and geos 128 (80 COLUMN ONLY ON 128) FILE SELECTION db SCROLLS FASTER AND HOLDS 40 FILENAMES SYMBOL TABLE SIZE:c64 MODEc128 MODE 3210 MACRO TABLE SIZE:c64 MODEc128 MODE XXX NAMES, XXX CHARS389 NAMES, 8000 CHARS OBJECT CODE SIZE LIMIT:c64 MODEc128 MODE XXX BYTES7999 BYTES NEW ERROR MESSAGES: "TOO MANY LOCAL LABEL REFERENCES" "PHASE ERROR IN VALUE" "PHASE ERROR IN FLAG" "SYNTAX ERROR" ("TOO MANY LOCAL LABELS" CHANGED TO "TOO MANY LOCAL LABEL DEFINITIONS") HAS .TEXT DIRECTIVE TO ASSEMBLE ASCII INTO cbm TEXT CODES. ENDING db HAS ICON TO RUN THE LINKER gEOlINKER: ONE PROGRAM RUNS UNDER geos 64 and geos 128 (80 COLUMN ONLY ON 128) FILE SELECTION db SCROLLS FASTER AND HOLDS 40 FILENAMES vlir LINKS: UP TO 21 MODULES (RESIDENT + 20 OVERLAY) ALLOWS UP TO 20 .REL FILES PER MODULE (OR TOTAL IN seq LINK) SYMBOLS:c64 MODEc128 MODE seq / cbm APPLICATIONS:XX vlir APPLICATIONS:XX RESIDENT MODULE:X3185 SWAP MODULE:X1375 OBJECT CODE SIZE LIMIT:c64 MODEc128 MODE XXX BYTES7999 BYTES NEW ERROR MESSAGES: "TOO MANY ERRORS" "ILLEGAL FILE NAME" "TOO MANY FILES IN A MODULE" ENDING db HAS ICON TO RUN THE DEBUGGER gEOdEBUGGER: ONE PROGRAM RUNS UNDER geos 64 and geos 128 SEE SUB-AREAS BELOW FOR NOTED DIFFERENCES BETWEEN MACHINES SYMBOLS:c64 MODEc128 MODE seq / cbm APPLICATIONS: vlir APPLICATIONS: RESIDENT MODULE: SWAP MODULE: sUPERdEBUGGER (IN reu) NOW OFFERS 800 SYMBOLS AND 1k OF MACRO DEFINITIONS. 128 MODE HAS NEW "bACKrAM sUPERdEBUGGER", WHICH HIDES IN bACKrAM. uSER CAN WRITE FULL-SIZED APPLICATIONS IN fRONTrAM. cAN HANDLE 1000 SYMBOLS AND 1k OF MACRO DEFINITIONS. **tHIS NEW 20k DEBUGGER DOES NOW INCREASE SIZE OF gEOdEBUGGER: THERE IS A DIFFERENTIAL LOADER SCHEME WHICH LOADS IN THE SUPER DEBUGGER AND THEN RELOCATES THE CODE FOR EITHER THE reu OR bACKrAM. NO geos SCREEN ASSUMPTIONS: DISPLAYS DEBUG INFORMATION ON 40-COLUMN SCREEN, AND RETURNS TO WHATEVER SCREEN (AND SCREEN MODE) WAS IN USE WHEN RUNNING USER CODE, OR WHEN f7 IS PRESSED SEE BELOW ABOUT DEBUGGER'S SHADOW VARS FOR vic PARAMETERS NEW AND IMPROVED MEMORY READ/WRITE ROUTINE: iNTERCEPTS (AND REDIRECTS TO DEBUGGER SHADOW VARIABLES) READS AND WRITES TO: $0000 AND $0001 (REGISTERS WHICH CONTROL MEMORY MAP) AREA OF ZERO PAGE WHICH IS USED BY DEBUGGER MEMORY AREAS USED BY reu sUPERdEBUGGER (REDIRECTS TO USER MEMORY SWAP AREA IN BANK #0 OF reu) SEVERAL vic CHIP REGISTERS, INCLUDING $dd00 (CIA2bASE), WHICH CONTROLS vic MEMORY MAP ON 128: $d500-$d50a (MEMORY MANAGMENT UNIT) $ff00-$ff04 (MORE MMU REGISTERS) $d030 (1mhz/2mhz SWITCH) dISALLOWS READS AND WRITES TO: ALL rom AREAS (SO NO BLEED THROUGH TO ram OCCURS) ANY AREA WHERE DEBUGGER CODE OR SYMBOLS ARE STORED (5 DIFFERENT CASES HERE, DUE TO 3 DEBUGGER TYPES ON 2 MACHINES.) STACK AREA BELOW CURRENT sp (DEBUGGER IS USING) PAGE 3 irq/brk/nmi VECTORS USED BY romS $fff9 AREA irq/brk/nmi VECTORS RAM EXPANSION UNIT'S dma CONTROLLER, IF USING reu sUPERdEBUGGER "CTAB" - EXTERNAL 1kX4 ram USED BY vic CHIP IN TEXT MODE. oN 128, THERE ARE TWO OF THESE. dEBUGGER USES CTAB #1, AND PREVENTS r/w TO IT. uSER IS FREE TO USE CTAB #0. wHEN ACCESSING ram IN 128 MODE, CALCULATES EFFECTIVE ADDRESS, TAKING BANK NUMBER AND BANK SHARING STATUS INTO ACCOUNT. nEW AND IMPROVED CONTEXT SWITCH (SECTION OF CODE WHICH BRIDGES GAP BETWEEN DEBUGGER AND USER CODE): TRAPS INTERRUPTS WHICH OCCUR WHEN USER'S APPLICATION SWAPS rom IN WITHOUT DISABLING INTERRUPTS; WARNS USER THROUGH DEBUGGER MESSAGE. ON 128 SYSTEM: HANDLES BANK-TO-BANK SWITCHING REQUIRED TO GET FROM EITHER BANK TO ONE OF 3 DEBUGGERS. SAVES AND RESTORES PROCESSOR CLOCK SPEED 1mhz / 2mhz *iMPROVED gETb / pUTb COMMAND: WORKS WITH 1571 AND 1581 DRIVES. *dISASSEMBLES AND TOP-STEPS THROUGH IN-LINE CALLS TO geos CORRECTLY. uSER CAN DISABLE THIS OPTION. *DISPLAYS cpu_data ($0001) OR cONFIG ($ff00) AS PRIMARY MEMORY MAP REGISTER IN 64 AND 128 MODES RESPECTIVELY. tHIS AFFECTS THE "r" REGISTER DISPLAY COMMAND AND THE "reg" REGISTER DISPLAY/MODIFY COMMAND. mORE ERROR CHECKING DURING FILE LOADS, WITH INFORMATIVE DIALOG BOXES: EXTENSIVE ERROR CHECKS AND GOOD ERROR DIALOG BOXES FOR: DEBUGGER MODULE SWAPS USER APPLICATION LOADS MACRO FILE LOADS SYMBOL FILE LOADS DISPLAYS INFORMATIVE ERROR DIALOG BOX FOR FORMAT ERRORS IN GEOwRITE MACRO DEFINITION FILES. dISPLAYS FILENAME, ERROR MESSAGE, PAGE AND LINE NUMBER. CAN DEBUG APPLICATIONS WHICH TRASH geos APPLICATION MUST HANDLE LOADING ITS OWN CODE IN OVER geos AREAS APPLICATION MUST DISABLE INTERRUPTS OR SET UP ITS OWN INTERRUPT SERVICE ROUTINE. wILL HAVE TO BE CLEVER TO PLACE HIS INTERRUPT VECTOR IN $334 AREA WHEN HIS APPLICATION IS RUNNING UNDER THE DEBUGGER. (i WILL SUPPLY THIS CODE IN THE NEW SAMPLE APP.) uNSEEN COMPLICATIONS WHICH ARE HANDLED: BANK SWITCH CONCERNS DURING: CONTEXT SWITCH jsr COMMAND gETb / pUTb COMMANDS RBOOT MAINTAINING SOFTWARE BREAKPOINTS SINGLE STEP BREAKPOINT aND ALL BUGS HAVE BEEN FIXED! sAMPLE fILES: geoprogrammer v2.0 beta test round #1 jULY 29, 1988 *** please read this before you install the disk *** cONGRATULATIONS ON BEING SELECTED AS A TESTER FOR GEOpROGRAMMER v2.0 ! bECAUSE GEOpROGRAMMER IS SUCH A COMPLEX PRODUCT, AND BECAUSE WE WANT TO MAKE SURE IT IS 100% BUG-FREE WHEN WE START SHIPPING IT, WE HAVE DECIDED TO PUT GEOpROGRAMMER v2.0 THROUGH TWO ROUNDS OF bETA tESTING. tHIS IS ROUND ONE. iN THIS PACKAGE YOU WILL FIND YOUR GEOpROGRAMMER v2.0 DISK, AND SOME QUICK NOTES ABOUT DIFFERENCES FROM VERSIONS v1.0 AND v1.1. uNFORTUNATELY, WE HAVE NOT HAD THE TIME TO FULLY TEST GEOlINKER, AND WE HAVE NOT YET COMPLETED UPGRADING THE COLLECTION OF SAMPLE FILES TO geos v2.0 LEVEL. tHEREFORE, DO NOT BE CONCERNED IF YOU ENCOUNTER SEVERAL BUGS IN GEOlINKER. jUST LET ME KNOW BY FILLING OUT ONE OF THE ENCLOSED bUG rEPORT FORMS, AND SENDING THE FORM BACK (ALONG WITH SOURCE FILES IF REQUIRED) TO bERKELEY sOFTWORKS AS SOON AS POSSIBLE. oVER THE NEXT THREE TO FOUR WEEKS WE WILL PUT THE FINISHING TOUCHES ON THE PRODUCT, WILL FIX ANY BUGS THAT YOU FIND, AND WILL DO MORE IN-HOUSE TESTING. wE WILL THEN SEND YOU A GEOpROGRAMMER v2.0 beta 2 DISK, AND ROUND TWO WILL HAVE BEGUN. wE EXPECT THE ENTIRE bETA tEST PERIOD (ROUNDS ONE AND TWO) TO LAST FIVE TO SIX WEEKS. wE DO NOT YET HAVE A DRAFT OF THE GEOpROGRAMMER v2.0 uSER'S mANUAL aDDENDUM TO SEND YOU, SO THE INFORMATION ON THE FOLLOWING PAGES WILL HAVE TO SUFFICE FOR THE NEXT FEW WEEKS. fROM A USER-INTERFACE STANDPOINT, THERE ARE FEW DIFFERENCES BETWEEN VERSIONS 1.0 AND 2.0, SO IF YOU HAVE NEVER USED THE PRODUCT BEFORE, YOU CAN FOLLOW THE INSTRUCTIONS IN THAT TEXT. iF YOU HAVE BEEN USING GEOpROGRAMMER v1.0 OR v1.1 FOR SOME TIME, PLEASE BE SURE TO TRY ASSEMBLING AND LINKING AND SOURCE FILES YOU'VE ALREADY WRITTEN. important: YOU WILL NOT BE ABLE TO INSTALL GEOdEBUGGER ON A 1571 DRIVE WHICH IS CONFIGURED AS A 1571. yOU MUST RE-CONFIGURE THE DRIVE AS A 1541, AND RE-OPEN THE GEOpROGRAMMER v2.0 DISK, BEFORE YOU CAN INSTALL GEOdEBUGGER. tHIS BUG WILL BE CORRECTED IN THE SOFTWARE YOU RECEIVE IN ROUND TWO. iF YOU HAVE ANY QUESTIONS REGARDING OUR bETA tEST PROGRAM OR THE GEOpROGRAMMER PRODUCT, PLEASE CONTACT kEVIN bOLAND, AND HE WILL CONNECT YOU TO ME OR ONE OF THE OTHER TEAM MEMBERS. wELCOME TO THE TEAM, AND THANKS FOR YOUR HELP! eRIC e. dEL sESTO gEOpROGRAMMER pROJECT lEADER state of geoprogrammer v2.0 beta test round 1 GEOaSSEMBLER: sHOULD BE FAIRLY SOLID. bE TOUGH ON IT. GEOlINKER: hAS SOME KNOWN BUGS, BUT SHOULD BE ABLE TO CORRECTLY LINK seq, cbm, AND vlir APPLICATIONS. GEOdEBUGGER: sHOULD BE ROCK SOLID. tORTURE IT. mAKE IT DIE. sAMPLE geos fILES: aRE ON THE DISK, AND HAVE BEEN UPGRADED TO INCLUDE geos 128 AND geos 64 v2.0 DEFINITIONS. nOT THAT BEFORE YOU INCLUDE THESE FILES, YOU MUST SET THE CONSTANTS c64 AND c128 TO true ($ff) OR false ($00). sAMPLEsEQ: nOT INCLUDED ON bETA rOUND 1 DISK. sAMPLEvLIR: aLL THE REQUIRED FILES ARE ON THE bETA rOUND 1 DISK. nOTE THAT THE sAMvLIReQUATES FILE SETS THE c64 AND c128 CONSTANTS. tHESE ARE PRESENTLY SET SO THAT THE APPLICATION WILL ONLY RUN UNDER c64 geos. iF YOU ARE TESTING ON A c128, BE SURE TO CHANGE THESE CONSTANT DEFINITIONS BEFORE YOU BEGIN. aLSO- THERE ARE SEVERAL NEW ADDITIONS TO THE sAMPLEvLIR FILES, SUCH AS SUPPORT FOR KEYBOARD SHORTCUTS IN THE MENUS. yOU CAN EXPECT TO FIND SOME PRETTY OBVIOUS BUGS IN SOME OF THESE NEW FEATURES. sAMPLEda: nOT INCLUDED ON bETA rOUND 1 DISK. sAMPLEcbm: tHIS IS A NEW SAMPLE FILE, TO DEMONSTRATE THE NON-geos CAPABILITY OF GEOdEBUGGER v2.0. nOT INCLUDED ON bETA rOUND 1 DISK. geoprogrammer improvements iN vERSION 2.0 GEOaSSEMBLER: ONE PROGRAM RUNS UNDER geos 64 and geos 128 (80 COLUMN ONLY ON 128) FILE SELECTION db SCROLLS FASTER AND HOLDS 239 FILENAMES IMPROVED OUTPUT FILE CREATION: FASTER ASSEMBLIES, DELETES PARTIAL FILES AFTER DISK ERRORS HAS .TEXT DIRECTIVE TO ASSEMBLE ASCII INTO cbm TEXT CODES. EXAMPLE:.TEXT"tHIS IS TEXT FOR THE cbm TEXT SCREEN" c64 MODE ONLY: WILL GENERATE UP TO 3584 CODE BYTES MAX NUMBER OF MACRO DEFINITIONS: 100 SIZE OF MACRO STORAGE BUFFER: 3560 SYMBOL TABLE HOLDS 1151 SYMBOLS c128 MODE ONLY: WILL GENERATE UP TO 7670 CODE BYTES MAX NUMBER OF MACRO DEFINITIONS: 389 SIZE OF MACRO STORAGE BUFFER: 12520 SYMBOL TABLE HOLDS 3208 SYMBOLS GEOlINKER: ONE PROGRAM RUNS UNDER geos 64 and geos 128 (80 COLUMN ONLY ON 128) FILE SELECTION db SCROLLS FASTER AND HOLDS 210 FILENAMES IMPROVED OUTPUT FILE CREATION: FASTER LINKS, DELETES PARTIAL FILES AFTER DISK ERRORS IMPROVED .LNK FILE PARSING: ALLOWS MULTIPLE PAGE .LNK FILES, GIVES MORE INFORMATIVE ERROR MESSAGES .sym FILE CAN HAVE 60 LINES/PAGE vlir LINKS: UP TO 21 MODULES (RESIDENT + 20 OVERLAY) ALLOWS UP TO 20 .REL FILES PER MODULE (OR TOTAL IN seq LINK) c64 MODE ONLY: BUFFER FOR COMPACTED .lnk FILE HAS 3840 BYTES CODE BUFFER IS 3584 BYTES RESIDENT SYMBOL TABLE HOLDS 1274 SYMBOLS SWAP MODULE SYMBOL TABLE HOLDS 850 SYMBOLS DURING seq AND cbm APPLICATION LINKS, COMBINES SYMBOL TABLES TO ALLOW A TOTAL OF 2124 SYMBOLS c128 MODE ONLY: BUFFER FOR COMPACTED .lnk FILE HAS 3840 BYTES CODE BUFFER IS 7670 BYTES RESIDENT SYMBOL TABLE HOLDS 3217 SYMBOLS SWAP MODULE SYMBOL TABLE HOLDS 1740 SYMBOLS (STATE OF THE PRODUCT, CONTINUED...) GEOdEBUGGER: IMPROVED ERROR DETECTION WHEN PARSING .dbm FILES, PRINTS PAGE AND LINE NUMBER WITH ERROR MESSAGE CAN TOP-STEP OVER IN-LINE CALLS TO geos ROUTINES SUCH AS I_rECTANGLE mINI dEBUGGER (c64/c128) OCCUPIES $3500-$5fff, PLUS $334-$3FF IN BANK 1 (HOLD run/stop KEY DOWN WHILE RUNNING GEOdEBUGGER TO INVOKE THE MINI-DEBUGGER.) sUPER dEBUGGER (c64/c128 WITH reu) MACRO BUFFER IS 1024 BYTES SYMBOL TABLE HOLDS 731 SYMBOLS OCCUPIES SPACE IN reu BANK 0, PLUS $334-$3FF IN BANK 1 (iF YOU HAVE A ram expansion unit ON YOUR SYSTEM, THIS DEBUGGER WILL AUTOMATICALLY LOAD WHEN YOU RUN GEOdEBUGGER. bY HOLDING run/stop OR space DOWN, YOU CAN OVERRIDE THIS TO RUN THE mINI-dEBUGGER OR bACKrAM sUPER-dEBUGGER.) bACKrAM sUPER dEBUGGER (c128 ONLY) (128 MODE HAS NEW "bACKrAM sUPERdEBUGGER", WHICH HIDES IN bACKrAM. uSER CAN WRITE FULL-SIZED APPLICATIONS IN fRONTrAM.) cAN HANDLE 1000 SYMBOLS AND 1k OF MACRO DEFINITIONS. MACRO BUFFER IS 1024 BYTES SYMBOL TABLE HOLDS 910 SYMBOLS OCCUPIES $2000-$9fff IN c128 BANK 0, PLUS $334-$3FF IN BANK 1 (iF YOU HAVE AN reu ON YOUR c128 SYSTEM, YOU MUST HOLD THE space KEY DOWN WHILE RUNNING GEOdEBUGGER TO INVOKE THE bACKrAM sUPER-dEBUGGER.) aDDITIONAL TECHNICAL INFORMATION ON GEOdEBUGGER v2.0 (yOU MIGHT FIND THIS INFORMATION INTERESTING.) NO geos SCREEN ASSUMPTIONS: DISPLAYS DEBUG INFORMATION ON 40-COLUMN SCREEN, AND RETURNS TO WHATEVER SCREEN (AND SCREEN MODE) WAS IN USE WHEN RUNNING USER CODE, OR WHEN f7 IS PRESSED SEE BELOW ABOUT DEBUGGER'S SHADOW VARS FOR vic PARAMETERS NEW AND IMPROVED MEMORY READ/WRITE ROUTINE: iNTERCEPTS (AND REDIRECTS TO DEBUGGER SHADOW VARIABLES) READS AND WRITES TO: $0000 AND $0001 (REGISTERS WHICH CONTROL MEMORY MAP) AREA OF ZERO PAGE WHICH IS USED BY DEBUGGER MEMORY AREAS USED BY reu sUPERdEBUGGER (REDIRECTS TO USER MEMORY SWAP AREA IN BANK #0 OF reu) SEVERAL vic CHIP REGISTERS, INCLUDING $dd00 (CIA2bASE), WHICH CONTROLS vic MEMORY MAP ON 128: $d500-$d50a (MEMORY MANAGMENT UNIT) $ff00-$ff04 (MORE MMU REGISTERS) $d030 (1mhz/2mhz SWITCH) dISALLOWS READS AND WRITES TO: ALL rom AREAS (SO NO BLEED THROUGH TO ram OCCURS) ANY AREA WHERE DEBUGGER CODE OR SYMBOLS ARE STORED (5 DIFFERENT CASES HERE, DUE TO 3 DEBUGGER TYPES ON 2 MACHINES.) STACK AREA BELOW CURRENT sp (DEBUGGER IS USING) PAGE 3 irq/brk/nmi VECTORS USED BY romS $fff9 AREA irq/brk/nmi VECTORS RAM EXPANSION UNIT'S dma CONTROLLER, IF USING reu sUPERdEBUGGER "CTAB" - EXTERNAL 1kX4 ram USED BY vic CHIP IN TEXT MODE. oN 128, THERE ARE TWO OF THESE. dEBUGGER USES CTAB #1, AND PREVENTS r/w TO IT. uSER IS FREE TO USE CTAB #0. wHEN ACCESSING ram IN 128 MODE, CALCULATES EFFECTIVE ADDRESS, TAKING BANK NUMBER AND BANK SHARING STATUS INTO ACCOUNT. nEW AND IMPROVED CONTEXT SWITCH (SECTION OF CODE WHICH BRIDGES GAP BETWEEN DEBUGGER AND USER CODE): TRAPS INTERRUPTS WHICH OCCUR WHEN USER'S APPLICATION SWAPS rom IN WITHOUT DISABLING INTERRUPTS; WARNS USER THROUGH DEBUGGER MESSAGE. ON 128 SYSTEM: HANDLES BANK-TO-BANK SWITCHING REQUIRED TO GET FROM EITHER BANK TO ONE OF 3 DEBUGGERS. SAVES AND RESTORES PROCESSOR CLOCK SPEED 1mhz / 2mhz *iMPROVED gETb / pUTb COMMAND: WORKS WITH 1571 AND 1581 DRIVES. *dISASSEMBLES AND TOP-STEPS THROUGH IN-LINE CALLS TO geos CORRECTLY. uSER CAN DISABLE THIS OPTION. *DISPLAYS cpu_data ($0001) OR cONFIG ($ff00) AS PRIMARY MEMORY MAP REGISTER IN 64 AND 128 MODES RESPECTIVELY. tHIS AFFECTS THE "r" REGISTER DISPLAY COMMAND AND THE "reg" REGISTER DISPLAY/MODIFY COMMAND. aDDITIONAL TECHNICAL INFORMATION ON GEOdEBUGGER v2.0 (CONTINUED) mORE ERROR CHECKING DURING FILE LOADS, WITH INFORMATIVE DIALOG BOXES: EXTENSIVE ERROR CHECKS AND GOOD ERROR DIALOG BOXES FOR: DEBUGGER MODULE SWAPS USER APPLICATION LOADS MACRO FILE LOADS SYMBOL FILE LOADS DISPLAYS INFORMATIVE ERROR DIALOG BOX FOR FORMAT ERRORS IN GEOwRITE MACRO DEFINITION FILES. dISPLAYS FILENAME, ERROR MESSAGE, PAGE AND LINE NUMBER. CAN DEBUG APPLICATIONS WHICH TRASH geos APPLICATION MUST HANDLE LOADING ITS OWN CODE IN OVER geos AREAS APPLICATION MUST DISABLE INTERRUPTS OR SET UP ITS OWN INTERRUPT SERVICE ROUTINE. wILL HAVE TO BE CLEVER TO PLACE HIS INTERRUPT VECTOR IN $334 AREA WHEN HIS APPLICATION IS RUNNING UNDER THE DEBUGGER. (i WILL SUPPLY THIS CODE IN THE NEW SAMPLE APP.) uNSEEN COMPLICATIONS WHICH ARE HANDLED: BANK SWITCH CONCERNS DURING: CONTEXT SWITCH jsr COMMAND gETb / pUTb COMMANDS RBOOT MAINTAINING SOFTWARE BREAKPOINTS SINGLE STEP BREAKPOINT aND ALL BUGS HAVE BEEN FIXED! aDDITIONAL TECHNICAL INFORMATION ON GEOdEBUGGER v2.0 (CONTINUED) hOW gEOdEBUGGER MANAGES MACHINE-DEPENDENT MEMORY-MAP ENVIRONMENT INFORMATION tHE DEBUGGER CARRIES MEMORY-MAP ENVIRONMENT INFORMATION, WHICH IS MACHINE- DEPENDENT, AROUND IN GENERIC VARIABLES SUCH AS APPbANKiNFO1 AND APPbANKiNFO2. tHIS WAY, THE ROUTINES WHICH JUST MOVE THIS INFORMATION AROUND (BUT DON'T DIRECTLY USE IT) ARE MACHINE-INDEPENDENT. eXECUTION eNVIRONMENT: wHEN THE DEBUGGER STOPS EXECUTION OF AN APPLICATION (restore PRESSED OR sbp HIT), THE USER'S "EXECUTION ENVIRONMENT" IS SAVED. tHIS INCLUDES: PROCESSOR REGISTER AND FLAG VALUES pc ADDRESS CURRENT BANK INFORMATION ZERO PAGE VARIABLES STACK INFORMATION wE CALL THE pc ADDRESS AND ITS MEMORY-MAP INFORMATION THE "eXECUTION eNVIRONMENT" OR MORE SIMPLY, THE "pc POINTER". vIEWING eNVIRONMENT: oNCE THE DEBUGGER HAS STOPPED AN APPLICATION, THE "VIEWING ENVIRONMENT" IS THE SAME AS THE "EXECUTION ENVIRONMENT". tHIS MEANS THAT ALL OF THE MEMORY EXAMINATION AND MODIFICATION COMMANDS USE THE SAME MEMORY-MAP INFORMATION AS THE eXECUTION eNVIRONMENT. tHROUGH USE OF THE setview COMMAND, THE VIEWING ENVIRONMENT CAN BE CHANGED. yOU CAN SET UP A NEW MEMORY-MAP CONFIGURATION, AND THEN USE THE MEMORY EXAMINATION AND MODIFICATION COMMANDS TO READ/WRITE MEMORY IN THIS NEW CONFIGURATION. wHEN YOU GIVE THE go COMMAND TO RESUME EXECUTION, THE DEBUGGER RESTORES THE EXECUTION ENVIROMENT, AND YOUR PROGRAM CONTINUES EXECUTION. wE CALL THE VIEWING ADDRESS AND ITS ENVIRONMENT THE "lc POINTER". ------------------------------------------------------------------------------- aSPECTS OF gEOdEBUGGER WHICH MUST CHANGE ACCORDING TO MACHINE-DEPENDENCIES IN v2.0, TO REMAIN COMPATIBLE WITH v1.0. (kILL THESE IN v3.0.) rEGISTER COMMAND: DISPLAYS pc ADDRESS, HIGHLIGHTS ADDRESS IF EFFECTIVE ADDRESS OF pc (CONSIDERING pc BANK INFO) IS BANK 0. DISPLAYS cpu_data VALUE (iT REALLY SHOULD NOT DO THIS ANYMORE, BUT i AM TRYING TO MAINTAIN COMPATABILITY WITH v1. 64:READ DIRECTLY FROM APPbANKiNFO1 128:[7-3,0]: DIRECT READ FROM MEMORY [21]: SHADOW WITH APPcpu_b21 aDDITIONAL TECHNICAL INFORMATION ON GEOdEBUGGER v2.0 (CONTINUED) rEGISTER oPEN cOMMAND: ..INCLUDES mm REGISTER: IS cpu_data. (tO BE COMPATIBLE WITH v1) 64:DIRECTLY READ/WRITE TO APPbANKiNFO1 128:[7-3,0]: DIRECTLY r/w TO MEMORY [21]: SHADOW WITH APPcpu_b21 ------------------------------------------------------------------------------- aSPECTS OF gEOdEBUGGER WHICH ARE MACHINE-INDEPENDENT. mEMORY EXAMINATION AND MODIFICATION: BANK COMMAND:AFFECTS lc'S BANK INFO: CURbANKiNFO1 AND CURbANKiNFO2 OPEN MODES:USES lc'S BANK INFO HIGHLIGHTS ADDRESS IF IS IN PHYSICAL BANK 0 DUMP COMMAND:USES lc'S BANK INFO HIGHLIGHTS ADDRESS IF IS IN PHYSICAL BANK 0 MOVE/FILL/DIFF/FIND:USES lc'S BANK INFO HIGHLIGHTS ADDRESS IF IS IN PHYSICAL BANK 0 @ AND @@ OPERATORS:USES lc'S BANK INFO sINGLE AND tOP-STEP BREAKPOINTS: MAINTAIN THEIR OWN BANK INFORMATION (COPIED FROM pc BANK INFO BEFORE EXECUTION BEGUN) sOFTWARE bREAKPOINTS: MAINTAIN THEIR OWN BANK INFORMATION (COPIED FROM pc BANK INFO BEFORE EXECUTION BEGUN) pc COMMAND: WITHOUT ARGUMENT:COPY pc ADDRESS AND BANK INFO TO lc (RESTORES EXECUTION ENVIRONMENT) WITH ARGUMENT: (SAME AS SETTING pc IN OPEN MODE) SET pc ADDRESS = ARGUMENT SET pc BANK INFO = lc BANK INFO aDDITIONAL TECHNICAL INFORMATION ON GEOdEBUGGER v2.0 (CONTINUED) (this portion of the geodebugger test list is supplied to give you an idea of how the memory-environment management commands work.) 4.10 mEMORY-mAP eNVIRONMENT mANAGEMENT 4.10.1 initview COMMAND: COPIES THE MEMORY-MAP ENVIRONMENT INFO FROM THE EXECUTION VARIABLES (pc) TO THE DISPLAY/MODIFY VARIABLES (lc). uSED WHEN USER HAS BEEN VIEWING DIFFERENT BANKS, AND NOW WANTS TO EXAMINE THE MEMORY MAP AS IT WAS WHEN WE STOPPED EXECUTION. 64 128 128 reu reu back ___ ___ ___INITVIEWNO ARGUMENTS. dISPLAYS pc LINE AND ENVIRONMENT INFO. ___ ___ ___NOTE THAT pc COMMAND HAS SAME EFFECT OF COPYING ENVIRONMENT INFORMATION, BUT DOES NOT DISPLAY MEMORY-MAP INFO WHEN DONE. ___ ___ ___VERIFY THAT "iv" COMMAND ALIAS WORKS 4.10.2 setview COMMAND: SETS THE MEMORY-MAP ENVIRONMENT FOR THE DISPLAY/MODIFY COMMANDS. dISPLAYS NEW ENVIRONMENT INFO IF NO ERROR. FORMAT:SETVIEW <mEMmAP1> [, <mEMmAP2> ] ___ ___ ___SETVIEW <mEMmAP1>SETS APPmEMmAP1. ___ ___c128: SHOULD NOT AFFECT APPmEMmAP2 SETVIEW <mEMmAP1>,<mEMmAP2> ___ ___c128: SETS APPmEMmAP1 AND APPmEMmAP2. ___ ___c128: VERIFY THAT b7 AND b6 ARE CLEARED IN APPmEMmAP2 (THIS VARIABLE MUST HAVE 0'S IN THOSE POSITIONS) ___ ___ ___DISPLAYS NEW ENVIRONMENT INFO CORRECTLY ___ ___ ___ERROR IF NO ARGUMENTS GIVEN ___ ___ ___ERROR IF EITHER VALUE GREATER THAN 255. ___ ___ ___VERIFY THAT "sv" COMMAND ALIAS WORKS 4.10.3 view COMMAND: DISPLAYS CURRENT MEMORY-MAP ENVIRONMENT INFO. ___ ___ ___VIEWNO ARGUMENTS REQUIRED ___c64: ONLY DISPLAYS 1ST OF 2 VALUES ON EACH LINE ___ ___c128: DISPLAYS BOTH VALUES ON EACH LINE ___ ___ ___VERIFY THAT "vw" COMMAND ALIAS WORKS 4.10.4 useview COMMAND: FORCES THE DISPLAY/MODIFY ENVIRONMENT UPON THE EXECUTION ENVIRONMENT. dISPLAYS NEW INFO WHEN FINISHED. ___ ___ ___USEVIEWNO ARGUMENTS REQUIRED ___ ___ ___VERIFY THAT "uv" COMMAND ALIAS WORKS 4.10.5 b0 COMMAND: SET DISPLAY/MODIFY ENVIRONMENT VARIABLE SO THAT ALL OF BANK 0 IS VISIBLE. dISPLAYS NEW INFO WHEN FINISHED. ___ ___ ___B0NO ARGUMENTS REQUIRED 4.10.6 b1 COMMAND: SET DISPLAY/MODIFY ENVIRONMENT VARIABLE SO THAT ALL OF BANK 1 IS VISIBLE. dISPLAYS NEW INFO WHEN FINISHED. ___ ___ ___B1NO ARGUMENTS REQUIRED 4.10.7 mEMORY-mAP eNVIRONMENT mANAGEMENT... test: VIEW ENVIRONMENT SAME AS EXECUTION ENVIRONMENT WHEN SOFTWARE BREAKPOINT IS HIT OR restore IS PRESSED. ___ ___ ___USE VIEW COMMAND, VALUES ON TWO LINES SHOULD BE EQUAL. aDDITIONAL TECHNICAL INFORMATION ON GEOdEBUGGER v2.0 (CONTINUED) test: THE FOLLOWING COMMANDS, MAKING SURE THAT THEY USE THE VIEW ENVIRONMENT MEMORY-MAP INFORMATION WHEN ACCESSING MEMORY. ___ ___ ___"a" OPEN MODE ___ ___ ___"m" OPEN MODE ___ ___ ___DEPOSITING VALUES WHEN IN AN OPEN-MODE ___ ___ ___@ AND @@ OPERATORS IN EXPRESSIONS ___ ___ ___dump ___ ___ ___dis ___ ___ ___n ___ ___ ___w ___ ___ ___print ___ ___ ___fill / copy / diff / find test: THAT EXECUTION ENVIRONMENT IS USED WHEN EXECUTION IS RE-STARTED. ___ ___ ___NEED TEST CODE FOR THIS... test: (c128 ONLY) IN THE FOLLOWING COMMANDS, AN ADDRESS SHOWS UP HIGHLIGHTED IF THE EFFECTIVE ADDRESS (CONSIDERING ram SHARING) IS IN BANK 0. hINT: TO SET lc TO BANK 0, USE b0 COMMAND. tO SET pc TO BANK 0, USE b0 FOLLOWED BY useview COMMAND. ___ ___"r" ___ ___"a" OPEN MODE ___ ___"m" OPEN MODE ___ ___dis, w, n, ETC. ___ ___dump ___ ___diff ___ ___find ___ ___history ------------------------------------------------------------------------------ v1.00011/2/87sENT TO hls, BUT NEVER MASTERED DUE TO 128 CRASHES. complete master release tape made 11/11/87. tHIS version 1.0 (11/2/87) RELEASE WAS SENT TO hls, BUT WAS NEVER MASTERED BECAUSE bRIAN HAD ME CHANGE THE 128 ENABLE BIT IN EACH APPLICATION'S HEADER BLOCK. sEE v1.010 FOR LIST OF KNOWN BUGS. ------------------------------------------------------------------------------ v1.01011/18/87sENT TO zmag. dUPLICATED AS gEOpROGRAMMER v1.0. 4000 SHIPPED WITHOUT ERRATA SHEET. eRRATA ITEMS POSTED TO qlink 1/25/88 oNLY DIFFERENCE FROM v1.000: BITS SET IN HEADERS SO DOES NOT CRASH geos 128. (iTEMS MARKED patch WERE CORRECTED WITH pATCH2.88 PROGRAM TO CREATE v1.1. iTEMS MARKED later WERE NOT FIXED UNTIL v2.0.) kNOWN BUGS IN 11.18 RELEASE, WHICH WERE CORRECTED WITH pATCH2.88 PROGRAM. lINKER HAS TROUBLE CREATING vlir FILES. bUG: VARIABLE CALLED FILEwRITTEN NOT SET TO true, SO bam IS RE-READ FROM DISK INSTEAD OF USING MORE RECENT bam WHICH IS IN MEMORY. aSSEMBLER HAS TROUBLE WITH LOCAL LABELS AFTER PARSING A BITMAP OR ROUTINE LONGER THAN 254 BYTES. bUG: TWO BRANCHES SKIP TOO FAR AND MISS CODE WHICH RESETS A VARIABLE. aSSEMBLER HAS TROUBLE WITH BITMAPS. bUG: UNCOMPACTING WRONG. lINKER HAS TROUBLE WITH .RAMSECTS IN rESIDENT AND sWAP MODULES. kNOWN BUGS IN 11.18 RELEASE, NOT CORRECTED UNTIL v2.0: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - aSSEMBLER (THINGS TO MENTION IN ERRATA LIST): iN ASSEMBLER, IF ENCOUNTER DISK ERROR, SHOULD ATTEMPT TO CLOSE ANY OPENED FILES SO DISK IS NOT INCONSISTENT. errata: WARN THEM, TELL THEM TO DELETE FILES AND VALIDATE DISK. aSSEMBLER HAS TROUBLE UNCOMPACTING BITMAPS OF LESS THAN 18 PIXELS HEIGHT errata: DON'T DO IT iF A ROUTINE IS LARGE ENOUGH TO COME CLOSE TO THE END OF CODEbUFFER, IT COULD OVERFLOW INTO THE eXTERNAL rEFERENCE bUFFER. errata: KEEP ROUTINES SMALLER THAN APPROX 250 BYTES (ASK TED) aSSEMBLER: DOES NOT PRINT CORRECT PAGE NUMBER IN ERROR MESSAGES REFERRING TO BRANCH INSTRUCTIONS. aLSO COUNTS MACRO EXPANSION LINES, SO MOST ERROR MESSAGES ARE OFF. errata: IF YOU GET A LOCAL LABEL ERROR, CONSIDER THAT IT MIGHT BE ON THE PREVIOUS PAGE (OR PAGE BEFORE THAT). oTHER ERRORS: CONSIDER MACRO EXPANSIONS WHEN COUNTING LINE NUMS. wHEN ASSEMBLING lda zp,y (WHICH DOES NOT EXIST), ASSEMBLER SHOULD SUBSTITUTE lda abs,y. errata: WARN AND TELL THEM HOW TO GET AROUND IT. LDA #rELOCvALUE OR .BYTE rELOCvALUE PASSES RELOCATION POINTER TO LINKER WHICH TRASHES WORD IN CODE. aSSEMBLER SHOULD GENERATE ERROR MESSAGE. errata: USE LOW BYTE OPERATOR: "[" BEFORE ANY SUCH REFERENCES. "*" OPERATOR ALWAYS GETS PSECT VALUE, SO DOES NOT WORK IN RAMSECT OR ZSECT AREAS. errata: WARN THEM iN ASSEMBLER, SCREEN COLORS NOT SET CORRECTLY, SO CAN SEE iNSORT WORKING BY CHANGING YOUR SCREEN COLORS. errata: TELL THEM TO CLOSE THEIR EYES DURING ASSEMBLIES. dOES NOT LOOK FOR gEOwRITE CORRECTLY WHEN OPENING ERROR FILE: SHOULD LOOK FOR PERMANENT NAME STRING. errata: DO NOT RENAME YOUR GEOwRITE. aSSEMBLER: (THINGS i WAS TOLD ABOUT TOO LATE TO MENTION THEM IN THE ERRATA LIST) "+" OPERATOR DOES NOT WORK IN UNARY CASE pHASE eRROR: JSR $0045 DOES NOT ASSEMBLE CORRECTLY. wHEN AN UNRESOLVED SYMBOL IS USED AS THE SECOND OPERAND IN AN EXPRESSION THAT INVOLVES A DIVISION OR A MODULUS, THE EXPRESSION WILL NOT BE PASSED TO THE LINKER. iNSTEAD, IT WILL GENERATE AN ERROR IN THE ASSEMBLER. aSSEMBLER: (THINGS NOT TO MENTION IN ERRATA LIST) aSSEMBLER'S BITMAP DECOMPACTION CODE DOES NOT HANDLE bIGcOUNT VALUES CORRECTLY. nOT A BIG PROBLEM: PHOTO SCRAPS UP TO geos v1.3 WORK OK. iF THERE IS ANY TEXT AFTER A .ENDM, PRODUCES "hIDDEN eRROR". fILE SELECTION db BUG: COULD RUN PROGRAM WITHOUT CHOOSING A FILE. aSSEMBLER SHOULD NOT PASS pASS1, pICw, AND pICh SYMBOLS TO LINKER. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - lINKER: (THINGS TO MENTION IN ERRATA LIST) iN LINKER, IF ENCOUNTER DISK ERROR, SHOULD ATTEMPT TO CLOSE ANY OPENED FILES SO DISK IS NOT INCONSISTENT. errata: WARN THEM, TELL THEM TO DELETE FILES AND VALIDATE DISK. lINKER: WHEN USING fREEbLOCK TO DELETE HEADER BLOCKS FROM cbm FILES, DOES NOT REALIZE THAT 1.2 KERNAL DOES NOT HAVE CODE FOR 'fREEbLOCK'. errata: WARN THEM, SUGGEST THEY UPGRADE TO geos 1.3. lINKER: DOES NOT CORRECT FOR ILLEGAL .REL FILENAMES. dOES NOT GIVE CORRECT ERROR FOR .REL FILE NOT FOUND. dOES NOT STOP AFTER FIRST 10 .REL FILES IN A MODULE, PRODUCING A BUG. errata: WARN THEM NOT TO HAVE MORE THAN 10 .REL FILES PER MODULE. oN ONE-DRIVE SYSTEM, LINKER DOES NOT DISPLAY "SYM FILE" DIALOG BOX. errata: TELL THEM TO BUY A SECOND DRIVE. iN LINKER, SCREEN COLORS NOT SET CORRECTLY, SO CAN SEE iNSORT WORKING BY CHANGING YOUR SCREEN COLORS. errata: TELL THEM TO CLOSE THEIR EYES DURING ASSEMBLIES. dOES NOT LOOK FOR gEOwRITE CORRECTLY WHEN OPENING ERROR FILE: SHOULD LOOK FOR PERMANENT NAME STRING. errata: DO NOT RENAME YOUR GEOwRITE. lINKER: (THINGS i WAS TOLD ABOUT TOO LATE TO MENTION THEM IN THE ERRATA LIST) "+" OPERATOR DOES NOT WORK IN UNARY CASE, AND "//" OPERATOR DOES NOT WORK. errata: i DIDN'T HEAR ABOUT THIS UNTIL IT WAS TOO LATE. lINKER: (THINGS NOT TO MENTION IN ERRATA LIST) lINKER IS NOT CLEARING zp FLAG BIT, SO IN DEBUGGER SOME SYMBOLS HAVE A GRAPHICS CHARACTER IN POSITION 3. lINKER DOES NOT STOP AT 99 ERRORS. fILE SELECTION db BUG: COULD RUN PROGRAM WITHOUT CHOOSING A FILE. wHEN .LNK FILE IS WRITE-PROTECTED, LINKER DISPLAYS db. cLICK ON IGNORE TO CONTINUE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - dEBUGGER: (MENTION IN ERRATA LIST:) SOME SYMBOLS SHOW UP WITH GRAPHICS CHAR IN POSITION 3. iS REALLY A LINKER BUG. errata: WARN THEM, SUGGEST THEY USE * WILDCARD DURING SEARCHES. dEBUGGER: (DO NOT MENTION IN ERRATA LIST:) DEBUGGER FILE-SELECT db DOES NOT DISPLAY WRITE-PROTECTED FILES DEBUGGER DOES NOT LOAD prg FILES WHICH ARE WRITE-PROTECTED CORRECTLY DEBUGGER IS NOT SAVING OR RESTORE DESKtOP'S rom VECTORS ($314-$318) CORRECTLY. iS NOT PREVENTING WRITES TO $314-$315. nOT A BIG PROBLEM: MY VECTORS AT $314 AND $316 ARE THE SAME ANYWAY. fIXED 2/1/88 BY CORRECTING BASbrkvEC AND BASirqvEC IN CONSTANTS FILE. nEW CODE INSTALLED IN mAY TO HANDLE THIS DIFFERENTLY. reu sUPERdEBUGGER ONLY ALLOWS 768 SYMBOLS, WHERE IT COULD HAVE 870. reu sUPERdEBUGGER DOES NOT GETB/PUTB FROM 1571 DRIVE CORRECTLY. IF YOU HOLD stop KEY DOWN WHEN DEBUGGER TURNS ON TEXT SCREEN DURING INITIAL BOOT SEQUENCE, IT ABORTS ITS INIT CYCLE, AND LEAVES YOU AT THE COMMAND PROMPT WITH THINGS SCREWY. nOTE:bOTH MONITORS IN gEOdEBUGGER HAVE AN UNUSED ROUTINE WHICH TAKES 18 BYTES. good location for patch subroutines! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sAMPLE fILES: (MENTION IN ERRATA LIST) iN sAMvLIR.LNK, SHOULD HAVE $3000 INSTEAD OF $5000 FOR VARIABLE AREA. (CAUSES MINI-DEBUGGER TO CRASH) iN sAMsEQ.LNK, SHOULD HAVE $3000 INSTEAD OF $5000 FOR VARIABLE AREA. (dOES NOT CAUSE MINI-DEBUGGER TO CRASH BECAUSE NO VARS ARE USED.) iN sAMsEQ AND sAMvLIRrES, "vertical" UNDER mENUtABLE SHOULD BE "sub_menu". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mANUAL: (MENTION IN ERRATA) .HEADER STRUCTURES ARE CHECKED FOR 12 STATEMENTS, NOT 11. dEBUGGER IS NOT AS ISOLATED AS WE MAKE IT SOUND: STILL USES geos RAM EXPANSION ROUTINES. dEBUGGER USES $340-$3FF, NOT $350-$3FF. app_ram == $400 HAS BEEN CHANGED TO app_ram = $400. rUNTO (RT) COMMAND WILL ONLY DISPLAY geos SCREEN IF OPTION 5 IS ENABLED (G1 COMMAND). tHE SAMPLE APPLICATION CANNOT BE RE-RUN WITH GO $400. pAGE 7-11 INCORRECT IN STATING THAT RUNTO WILL SHOW SCREEN. pAGE 8-1 THE bRITISH POUND CHARACTER IS A SINGLE KEY (NO NEED TO PRESS c= KEY). sAMPLEvLIR DOES NOT DO ANY ERROR CHECKING WHEN TRYING TO FIND "sAMPLEvLIR" ON DISK. iF THEY ARE NOT CAREFUL WHEN CHANGING APPLICATION'S NAME, WILL NOT LOAD CORRECTLY. wARN PEOPLE THAT USE OF pASS1 IS DANGEROUS; tELL THEM TO MAKE SURE THEY HAVE A .PSECT AFTER INCL. ZP VARS FILE. mANUAL: (DO NOT MENTION) mAY WANT TO EXPLAIN A LITTLE BIT ABOUT INTERRUPT TIMING, OR "WHY MOUSEdATA CHANGES". ------------------------------------------------------------------------------ v1.1002/88tHIS VERSION IS ACTUALLY v1.010 AFTER THE pATCH2.88 PROGRAM HAS MODIFIED THE aSSEMBLER AND lINKER. pATCH2.88 DISTRIBUTED THROUGH qUANTUMlINK, AND v1.100 mASTER DISK CREATED BY RUNNING pATCH2.88 ON v1.010 mASTER DISK. tHIS v1.100 mASTER DISK DUPLICATED BY zmAG, COPIES SENT FREE OF CHARGE TO REGISTERED OWNERS WHO REQUESTED IT. ------------------------------------------------------------------------------ v2.000aPRIL 1988c64/c128 VERSION, WITH MANY IMPROVEMENTS AND BUG FIXES. this is a quick list; SEE "VERSIONv2" FILE FOR A SUMMARY. aSSEMBLER iMPROVEMENTS: RUNS UNDER geos 64 AND geos 128 (IN 80 COLUMN MODE) ENDING db HAS ICON TO RUN LINKER HAS .TEXT DIRECTIVE TO ASSEMBLE ASCII INTO cbm TEXT CODES. lINKER iMPROVEMENTS: RUNS UNDER geos 64 AND geos 128 (IN 80 COLUMN MODE) ALLOWS UP TO 20 .REL FILES PER MODULE ENDING db HAS ICON TO RUN DEBUGGER dEBUGGER iMPROVEMENTS: sAMPLEfILES iMPROVEMENTS: nEW WARNINGS FOR MANUAL: aSSEMBLING FILES UNDER c128 AND LINKING THEM UNDER c64-- DOES lINKER CHECK FOR TABLES WHICH ARE TOO LARGE? ------------------------------------------------------------------------------ tECHNICAL oVERVIEW OF iMPORTANT dIFFERENCES bETWEEN gEOpROGRAMMER vERSIONS aSSEMBLER: sINCE CODE RECORD, XREF RECORD, RELOC RECORD, AND ERROR FILE PAGES ARE WRITTEN OUT BLOCK BY BLOCK, WE ARE NOT CONCERNED WITH BUFFER SIZES. mACRO TEXT STORAGE SIZE: v1.02k v2.0 (64 MODE)3560 v2.0 (128 MODE)12520 sYMBOL TABLE SIZE: v1.03017+7670 = 10687 (1068 SYMBOLS) v2.0 (64 MODE)11510 (1151 SYMBOLS) v2.0 (128 MODE)32080 (3208 SYMBOLS) dOES NOT RUN IN 128 40-COLUMN MODE BECAUSE ALL dma WORK IN BACKRAM CAUSES 40-COLUMN SCREEN TO FLICKER BADLY. lINKER: xREF AND rELOC POINTERS ARE READ BLOCK-BY-BLOCK FROM RECORDS, SO WE ARE NOT CONCERNED ABOUT BUFFER SIZES. cODE BUFFER SIZE (FOR ONE .REL'S CODE RECORD) v1.06608 v2.0 (64 MODE)3584 v2.0 (128 MODE)7670 rESIDENT MODULE SYMBOL TABLE SIZE: v1.010k= 10240 (1024 SYMBOLS) v2.0 (64 MODE)12740(1274 SYMBOLS) v2.0 (128 MODE)32170(3217 SYMBOLS) sWAP MODULE SYMBOL TABLE SIZE: v1.08k= 8192 (819 SYMBOLS) v2.0 (64 MODE)8500 (850 SYMBOLS) v2.0 (128 MODE)17400 (1740 SYMBOLS) sEQUENTIAL aPPS: v1.010k(YOU MIGHT THINK IS 10k + 8k, BUT THERE IS A BUG: IS ONLY 10k) v2.0 (64 MODE)21240 v2.0 (128 MODE)32170 (BACKRAM ONLY. mATTsORT TO USE BOTH BANKS (GIVING 48k) WOULD BE A MESS.) nUMBER OF .REL FILES PER MODULE: v1.010 v2.0 (64/128)20 cREATING gEOwRITE SYM FILES: FOR EACH .DBG RECORD: READ BLOCK BY BLOCK INTO FRONTRAM AND MOVE TO BACK SORT ENTIRE IN BACK FOR EACH SYM IN BACK COPY SYM TO FRONT WRITE TO 5k PAGE BUFFER (fg SCREEN AREA?) WRITE OUT 5k BUFFER AS PAGE dOES NOT RUN IN 128 40-COLUMN MODE BECAUSE ALL dma WORK IN BACKRAM CAUSES 40-COLUMN SCREEN TO FLICKER BADLY. gEOdEBUGGER: GEOpROGRAMMER v2.0 FOR c64 AND c128 uPGRADE oFFER sEPTEMBER, 1988 dEAR GEOpROGRAMMER USER: oUR LATEST RELEASE OF THE GEOpROGRAMMER PACKAGE, GEOpROGRAMMER v2.0, WILL SOON BE AVAILABLE. wE CAN OFFER YOU, AS A REGISTERED GEOpROGRAMMER OWNER, THIS NEW PRODUCT FOR THE LOW PRICE OF $xx.xx. wE HAVE REWRITTEN MUCH OF THE ORIGINAL SOFTWARE, TAKING YOUR SUGGESTIONS INTO ACCOUNT, AND ADDING SOME NEW FEATURES. oVERALL pRODUCT iMPROVEMENTS: - GEOpROGRAMMER v2.0 SUPPORTS THE cOMMODORE 128 AND 128d COMPUTERS. GEOaSSEMBLER, GEOlINKER, AND GEOdEBUGGER NOW RUN UNDER geos 128 AT THE FASTER 2mhz CLOCK RATE, USING THE 80-COLUMN SCREEN AND ADDITIONAL MEMORY. - GEOpROGRAMMER v2.0 IS FULLY COMPATIBLE WITH ALL VERSIONS OF geos: v1.2, v1.3, AND v2.0, AND WITH THE NEW 1581 DISK DRIVE. - IN BOTH c64 AND c128 MODES, GEOpROGRAMMER v2.0 RUNS FASTER AND MORE EFFICIENTLY. eRROR DETECTION HAS BEEN IMPROVED, AND MORE INFORMATIVE ERROR MESSAGES ARE PROVIDED. fILE SELECTION HAS BEEN STREAMLINED. - THE THREE SAMPLE APPLICATIONS HAVE BEEN UPGRADED TO SUPPORT THE c128, AND TO ILLUSTRATE MORE geos PROGRAMMING CONCEPTS SUCH AS KEYBOARD SHORTCUTS. - THE geos "INCLUDE" FILES HAVE BEEN UPDATED TO REFLECT geos v2.0 INFORMATION. - GEOpROGRAMMER v2.0 INCLUDES AN ADDITIONAL SAMPLE APPLICATION, WHICH DEMONSTRATES HOW YOU CAN DEVELOP "cbm" APPLICATIONS WHICH DO NOT REQUIRE geos TO RUN. iMPROVEMENTS IN GEOaSSEMBLER v2.0: - GEOaSSEMBLER v2.0 WILL READ GEOwRITE SOURCE FILES FROM ALL VERSIONS OF GEOwRITE, UP TO v2.1. - NEW .TEXT DIRECTIVE CONVERTS ASCII TEXT STRINGS DIRECTLY INTO cOMMODORE SCREEN CODES. mAXIMUMmAXIMUM aSPECT OF GEOaSSEMBLER v2.0IN c64 mODEIN c128 mODE ------------------------------------------------------------------ SYMBOL DEFINITIONS:1151 SYMBOLS3208 SYMBOLS MACRO DEFINITIONS:100 MACROS389 MACROS OR 3560 BYTESOR 12520 BYTES CODE BYTES GENERATED PER .REL FILE:3584 BYTES7670 BYTES ------------------------------------------------------------------ iMPROVEMENTS IN GEOlINKER v2.0: - GEOlINKER v2.0 WILL ACCEPT MULTIPLE-PAGE ".LNK" COMMAND FILES, GENERATED WITH ANY VERSION OF GEOwRITE. - WILL LINK UP TO 20 .REL FILES INTO A seq OR cbm APPLICATION, AND UP TO 20 .REL FILES PER MODULE IN A vlir APPLICATION. mAXIMUMmAXIMUM sYMBOL DEFINITIONS IN GEOlINKER v2.0IN c64 mODEIN c128 mODE ------------------------------------------------------------------ WHEN LINKING seq AND cbm APPLICATIONS:2124 SYMBOLS3217 SYMBOLS WHEN LINKING vlir APPLICATIONS: RESIDENT MODULE:1274 SYMBOLS3217 SYMBOLS FOR EACH OVERLAY MODULE:850 SYMBOLS1740 SYMBOLS ------------------------------------------------------------------ iMPROVEMENTS IN GEOdEBUGGER v2.0: - NEW "HIDDEN MODE": NOW YOU CAN VIEW YOUR APPLICATION'S SCREEN WHILE GIVING COMMANDS TO GEOdEBUGGER. - GEOdEBUGGER v2.0 WILL RECOGNIZE CALLS TO INLINE geos ROUTINES SUCH AS I_rECTANGLE, ALLOWING YOU TO SAFELY TOP-STEP OVER AND DISASSEMBLE THESE CALLS. - NEW bACKrAM sUPER dEBUGGER ALLOWS c128 OWNERS WITHOUT A RAM EXPANSION UNIT TO TAKE ADVANTAGE OF THE sUPER dEBUGGER'S FEATURES. - IMPROVED "CONTEXT SWITCH" IN c128 MODE, ALLOWING SINGLE-STEP THROUGH CODE WHICH INVOLVES BANK SWITCHING; ALLOWS EXECUTION AT EITHER 1 mhz OR 2 mhz CLOCK RATE. - FULL SUPPORT FOR NON-geos APPLICATIONS, INCLUDING TECHNICAL NOTES ON HOW TO WRITE AND INSTALL YOUR OWN INTERRUPT SERVICE ROUTINES. - STRAY INTERRUPT TRAPPING FACILITY, TO AID IN ISOLATING RARE CRASH CONDITIONS IN c64 AND c128 APPLICATIONS. staci- EXPLAIN HOW THEY GO ABOUT ORDERING THE UPGRADE: - PRICE - WHERE TO SEND CHECK / MONEY ORDER / CREDIT CARD # / ETC - WHETHER OR NOT THEY CAN CALL THEIR ORDER IN - IF THEY MUST SEND THEIR ORIGINAL DISK, OR IF A RECEIPT WILL SUFFICE. (DO NOT ASK THEM TO TEAR THE COVER OFF THEIR MANUAL- THEY WILL STILL NEED THE OLD MANUAL!) - WHO THEY SHOULD CALL WITH QUESTIONS, OR WHERE TO WRITE FOR INFO ON THE UPGRADE OFFER (NOT ME!) c128 MODE HAS REAL TROUBLE WITH BITMAPS. sEE FILE14&15... ------------------------------------------------------------------------------- kNOWN (AND ALLOWABLE) DIFFERENCES BETWEEN GEOaSSEMBLER (tED'S) AND GEOaSSEMBLER (MINE) OUTPUT FILES. ted:eric: ---------------------------------------------- .rel FILE: cODE RECORD ILLEGAL BRANCH:GETS GARBAGE OFFSETOFFSET = $20 eXrEF RECORD: LESSi GENERATE MORE eXrEFS rELOC rECORD: sym RECORD: +3: rELOC BIT:SET FOR zp LABELSALWAYS 0 +4: "==" BITSET FOR "=" EQUATESSET FOR "==" EQUATES .err FILE: MARGINS IN RULER:OFFSET=+7: =$28=$30 ------------------------------------------------------------------------------- bugs: done: - FIXED LINK ICON - CLEANED UP SOME 40/80 COLUMN PROBLEMS IN iNIT MODULE - MADE WRITEbamtOdISK A BYTE VARIABLE - ADDED pANICwRITEnEWbamtOdISK TO ROUTINES WHICH DELETE CHAINS - CLEANED UP 40/80 COLUMN MODE SWITCHING SOME MORE - FIXED LOTS OF MISCELLANEOUS THINGS IN MACRO EXPANSION... - REWROTE HOW MACRO PARAMETERS ARE PARSED FROM DEFINITION LINE, SO THAT CAN DETECT ALL ERROR CASES - REWROTE HOW MACRO ARGUMENTS ARE PARSED FROM INVOCATION LINE, HOW THEY ARE STORED AND SEARCHED. SHOULD HANDLE NULL ARGS, TOO MANY ARGS - FIXED HANDLING OF GLOBAL LABELS WITHIN MACROS- NOW SUBSTITUTES CORRECTLY, HANDLES 8 CHAR SYMBOLS - FIXED BUG IN NESTED MACROS WHICH HAVE GLOBAL LABELS (+1 ERROR) - FIXED HOW sEARCHtABLE DETERMINES LENGTHS OF THINGS IT CAN SEARCH FOR - RE-WROTE TEST FILE #19 (TESTS MACRO DEF AND EXP ERRORS), ADDED A SERIES OF ADDITIONAL TESTS, VERIFIED ALL OUTPUT, PLACED ON TEST DISK a. - CREATED TEST FILE #75 (TESTS ALL POSSIBLE NON-FATAL ERROR MESSAGES) iNCLUDES MOST SCENARIOS WHICH COULD GENERATE THESE ERRORS. VERIFIED ALL OUTPUT, PLACED ON TEST DISK b. - FIXED "RELOC" FLAG BUG: NOW SETS RELOCATION BITS IN LABELS CORRECTLY - REWROTE HOW LOCAL LABELS AND REFERENCES TO THEM ARE PLACED IN TABLES (CORRECTED BUG WHICH CLEANED UP AFTER jmp 10$ INCORRECTLY) - REWROTE HOW INFORMATION IS COLLECTED ABOUT AN OPERAND WHILE IT IS BEING EVALUATED, AND HOW THIS INFORMATION AFFECTS THE POSSIBLE ADDRESSING MODES. cORRECTED SEVERAL BUGS HAVING TO DO WITH EXPRESSIONS WHICH CONSIST OF SEVERAL DIFFERENT TYPES OF ARGUMENTS. - EXPRESSION WAS JUDGED AS RELOCATABLE EVEN AFTER MATH - BIT FOR EQUATE WAS SET BY NOGLBL/NOEQIN STATUS - "*" OPERAND DIDN'T SET RIGHT BIT FOR PSECT/RAMSECT - WAS SETTING STATUS:b3 FOR "uNARYtOGETHER" CASES- WHY? - IMPROPER HANDLING OF lda # AND .byte OPERANDS - NOT GENERATING RELOC POINTERS AND EXREFS IN ALL CASES - NOT CATCHING ALL POSSIBLE BRANCH ERRORS (BAD LOCAL LABEL USAGE) - MADE 2 CENTRAL ROUTINES FOR GRABBING ARGS FOR .if ETC, .block, .psect ETC, ETC. - CHANGED THE WAY gETeXPRESSION LOOKS AT "MUSTeVAL" - REMOVED THE "COMPLEXeXP" FLAG - REWROTE ERROR DETECTION IN LOCAL LABEL REFERENCES AND DEFINITIONS - NOW CAN FORGET MOST RECENT LOCAL LABEL REFERENCE, FOR CASES WHERE LINE IS BAD (DOES NOT STAMP CODE WHICH IS NOT ASSEMBLED) - CREATED TESTFILE: FILE76_1 TO TEST ALL EXPRESSION PARSING AND ERROR DETECTION; ALSO INCLUDES SOME BRANCHING TESTS - FIXED A LOT OF BUGS RELATED TO USING "*" IN EXPRESSIONS cORRECTED EXPRESSION EVALUATOR'S TYPE-CHECKING IN GENERAL CREATED NEW TEST FILE (FILE7) TO TEST THIS - oPENsOURCEfILE IN fILE/FILErOUTINES NO LONGER DOES A fINDfILE BEFORE oPENrECORDfILE. sPEED ASSEMBLY A BIT. - SPENT A DAY CHASING FILE14 BUG IN 128 MODE. nO LUCK. keep an eye out for: tHERE MIGHT BE A BUG WITH FILE62 (TOO MANY BACKRAM SYMBOLS) TRY ON STAND-ALONE, SEE IF boldface CHARACTERS GET TRASHED iF SO, DISABLE dma mOVEdATA, SEE IF IT STILL HAPPENS ------------------------------------------------------------------------------- wARN IN MANUAL: iT MAY BE POSSIBLE FOR ASSEMBLER TO HAVE TOO MANY SYMBOLS THAN THE LINKER COULD READ IN FROM ONE .rel FILE. bUT IF SOME OF THESE ARE .NOEQIN OR .NOGLBL'ED OUT, WE ARE OK. wARN IN MANUAL THAT bne sTART+sTART WILL NOT ASSEMBLE CORRECTLY, BECAUSE i ASSUME IS SOMETHING OF THE FORM: bne sTART+2, WHICH IS LEGAL. fILE SELECT db WILL DISPLAY ANY APPLICATION DATA FILE WHICH DOES NOT END IN ".REL", ".DBG", ".SYM", ".ERR", ".LNK": THUS IS FASTER THAN BEFORE. pROBLEM: WILL DISPLAY GEOfILE AND GEOpAINT ETC. DOCUMENTS. ------------------------------------------------------------------------------- future: aDD TO TEST LIST PAGE TOO BIG (4096) ECHO TOO MANY PAGES TOO MANY ERROR PAGES MINOR BUGS FOUND IN FILE75: nOT RECOGNIZING "LINE TOO LONG" CORRECTLY cOULD NOT GET IT TO PRINT "EXPRESSION TOO COMPLEX" DOES NOT DETECT .RAMSECT AND .INCLUDE IN MACRO DEFINITION SEE ERROR #61- i DID NOT FORCE IT CORRECTLY SEE FILE3: ASSEMBLER IS NOT FLAGGING ERROR FOR ".WORD "ERIC" " c128 MODE: INTERMITTENT BUG WHEN TRYING TO ASSEMBLE FILE14 (BIG BITMAP) OFF OF DRIVE a, ONTO ram disk. sOMETIMES GET "DISK NAME MISMATCH" ERROR. c128:WHY DID 3208 NOT OVERFLOW SYMBOL TABLE? TABLE HOLDS 3208- i SENT 3208 PLUS 3 ALREADY THERE! cREATE A FILE78 WHICH IS A COPY OF FILE75, BUT WHICH TESTS .IF pASS1 STUFF. i DID THIS ON 10/1/88, AND HIT A WEIRD PHASE ERROR AT gLOBALlABEL:. i DON'T THINK THIS IS A BIG PROBLEM. sLIGHT PROBLEM IN EXPRESSION EVALUATION: PARSES JMP (LABEL) AS RELOCATABLE WITH MATH, SINCE IT HITS THE ENDING PARANTHESES. nEED TO EDUCATE GETeXPRESSION A LITTLE MORE SO THIS DOES NOT HAPPEN. tHIS IS NOT A PROBLEM WITH THE (,X) AND (),Y ADDRESSING MODES, BECAUSE THEY MUST HAVE RESOLVABLE zp EXPRESSIONS, AND SO THEY NEVER GENERATE EXTERNAL REFERENCES. ------------------------------------------------------------------------------- distant future mOVE LOCAL LABEL PARSING OUT OF EXPRESSION EVALUATOR: RIGHT NOW THE ERROR DETECTION IS VERY CONFUSED BY CASES SUCH AS LDA10$+4 LDA4+10$+6666666666666 LDA10$+20$+30$;THREE REFERENCES ADDED TO LIST, ;ONLY LAST ONE DELETED... mINOR PROBLEM: a LINE SUCH AS .BYTE1,CRAP,2 WILL STILL GENERATE 3 BYTES OF CODE: WOULD BE NICE TO COMPLETELY REVERSE THE EFFECTS (CODE, lc INCS, EXREFS AND RELOCS GENERATED, ETC) OF A CODE LINE WHEN AN ERROR IS DETECTED. oTHERWISE THERE IS NO EASY WAY TO HANDLE THIS CASE. rELATED PROBLEM: IN CASES WHERE AN ERROR IS DETECTED IN PASS 2 AND not PASS 1, WE HAVE TO MAKE SURE THE SAME AMOUNT OF CODE IS GENERATED IN BOTH PASSES, SO THAT NO PHASE ERRORS SHOW UP. "tOO MANY LOCAL LABEL REFERENCES" IS A GOOD EXAMPLE OF THIS. sEE BEGINNING OF pARSEiNST FOR HOW i HANDLED THIS. c128 MODE HAS REAL TROUBLE WITH BITMAPS. sEE FILE14&15... ------------------------------------------------------------------------------- kNOWN (AND ALLOWABLE) DIFFERENCES BETWEEN GEOaSSEMBLER (tED'S) AND GEOaSSEMBLER (MINE) OUTPUT FILES. ted:eric: ---------------------------------------------- .rel FILE: cODE RECORD ILLEGAL BRANCH:GETS GARBAGE OFFSETOFFSET = $20 eXrEF RECORD: LESSi GENERATE MORE eXrEFS rELOC rECORD: sym RECORD: +3: rELOC BIT:SET FOR zp LABELSALWAYS 0 +4: "==" BITSET FOR "=" EQUATESSET FOR "==" EQUATES .err FILE: MARGINS IN RULER:OFFSET=+7: =$28=$30 ------------------------------------------------------------------------------- bugs: done: - FIXED LINK ICON - CLEANED UP SOME 40/80 COLUMN PROBLEMS IN iNIT MODULE - MADE WRITEbamtOdISK A BYTE VARIABLE - ADDED pANICwRITEnEWbamtOdISK TO ROUTINES WHICH DELETE CHAINS - CLEANED UP 40/80 COLUMN MODE SWITCHING SOME MORE - FIXED LOTS OF MISCELLANEOUS THINGS IN MACRO EXPANSION... - REWROTE HOW MACRO PARAMETERS ARE PARSED FROM DEFINITION LINE, SO THAT CAN DETECT ALL ERROR CASES - REWROTE HOW MACRO ARGUMENTS ARE PARSED FROM INVOCATION LINE, HOW THEY ARE STORED AND SEARCHED. SHOULD HANDLE NULL ARGS, TOO MANY ARGS - FIXED HANDLING OF GLOBAL LABELS WITHIN MACROS- NOW SUBSTITUTES CORRECTLY, HANDLES 8 CHAR SYMBOLS - FIXED BUG IN NESTED MACROS WHICH HAVE GLOBAL LABELS (+1 ERROR) - FIXED HOW sEARCHtABLE DETERMINES LENGTHS OF THINGS IT CAN SEARCH FOR - RE-WROTE TEST FILE #19 (TESTS MACRO DEF AND EXP ERRORS), ADDED A SERIES OF ADDITIONAL TESTS, VERIFIED ALL OUTPUT, PLACED ON TEST DISK a. - CREATED TEST FILE #75 (TESTS ALL POSSIBLE NON-FATAL ERROR MESSAGES) iNCLUDES MOST SCENARIOS WHICH COULD GENERATE THESE ERRORS. VERIFIED ALL OUTPUT, PLACED ON TEST DISK b. - FIXED "RELOC" FLAG BUG: NOW SETS RELOCATION BITS IN LABELS CORRECTLY - REWROTE HOW LOCAL LABELS AND REFERENCES TO THEM ARE PLACED IN TABLES (CORRECTED BUG WHICH CLEANED UP AFTER jmp 10$ INCORRECTLY) - REWROTE HOW INFORMATION IS COLLECTED ABOUT AN OPERAND WHILE IT IS BEING EVALUATED, AND HOW THIS INFORMATION AFFECTS THE POSSIBLE ADDRESSING MODES. cORRECTED SEVERAL BUGS HAVING TO DO WITH EXPRESSIONS WHICH CONSIST OF SEVERAL DIFFERENT TYPES OF ARGUMENTS. - EXPRESSION WAS JUDGED AS RELOCATABLE EVEN AFTER MATH - BIT FOR EQUATE WAS SET BY NOGLBL/NOEQIN STATUS - "*" OPERAND DIDN'T SET RIGHT BIT FOR PSECT/RAMSECT - WAS SETTING STATUS:b3 FOR "uNARYtOGETHER" CASES- WHY? - IMPROPER HANDLING OF lda # AND .byte OPERANDS - NOT GENERATING RELOC POINTERS AND EXREFS IN ALL CASES - NOT CATCHING ALL POSSIBLE BRANCH ERRORS (BAD LOCAL LABEL USAGE) - MADE 2 CENTRAL ROUTINES FOR GRABBING ARGS FOR .if ETC, .block, .psect ETC, ETC. - CHANGED THE WAY gETeXPRESSION LOOKS AT "MUSTeVAL" - REMOVED THE "COMPLEXeXP" FLAG - REWROTE ERROR DETECTION IN LOCAL LABEL REFERENCES AND DEFINITIONS - NOW CAN FORGET MOST RECENT LOCAL LABEL REFERENCE, FOR CASES WHERE LINE IS BAD (DOES NOT STAMP CODE WHICH IS NOT ASSEMBLED) - CREATED TESTFILE: FILE76_1 TO TEST ALL EXPRESSION PARSING AND ERROR DETECTION; ALSO INCLUDES SOME BRANCHING TESTS - FIXED A LOT OF BUGS RELATED TO USING "*" IN EXPRESSIONS cORRECTED EXPRESSION EVALUATOR'S TYPE-CHECKING IN GENERAL CREATED NEW TEST FILE (FILE7) TO TEST THIS - oPENsOURCEfILE IN fILE/FILErOUTINES NO LONGER DOES A fINDfILE BEFORE oPENrECORDfILE. sPEED ASSEMBLY A BIT. - SPENT A DAY CHASING FILE14 BUG IN 128 MODE. nO LUCK. keep an eye out for: tHERE MIGHT BE A BUG WITH FILE62 (TOO MANY BACKRAM SYMBOLS) TRY ON STAND-ALONE, SEE IF boldface CHARACTERS GET TRASHED iF SO, DISABLE dma mOVEdATA, SEE IF IT STILL HAPPENS ------------------------------------------------------------------------------- wARN IN MANUAL: iT MAY BE POSSIBLE FOR ASSEMBLER TO HAVE TOO MANY SYMBOLS THAN THE LINKER COULD READ IN FROM ONE .rel FILE. bUT IF SOME OF THESE ARE .NOEQIN OR .NOGLBL'ED OUT, WE ARE OK. wARN IN MANUAL THAT bne sTART+sTART WILL NOT ASSEMBLE CORRECTLY, BECAUSE i ASSUME IS SOMETHING OF THE FORM: bne sTART+2, WHICH IS LEGAL. fILE SELECT db WILL DISPLAY ANY APPLICATION DATA FILE WHICH DOES NOT END IN ".REL", ".DBG", ".SYM", ".ERR", ".LNK": THUS IS FASTER THAN BEFORE. pROBLEM: WILL DISPLAY GEOfILE AND GEOpAINT ETC. DOCUMENTS. ------------------------------------------------------------------------------- future: aDD TO TEST LIST PAGE TOO BIG (4096) ECHO TOO MANY PAGES TOO MANY ERROR PAGES MINOR BUGS FOUND IN FILE75: nOT RECOGNIZING "LINE TOO LONG" CORRECTLY cOULD NOT GET IT TO PRINT "EXPRESSION TOO COMPLEX" DOES NOT DETECT .RAMSECT AND .INCLUDE IN MACRO DEFINITION SEE ERROR #61- i DID NOT FORCE IT CORRECTLY SEE FILE3: ASSEMBLER IS NOT FLAGGING ERROR FOR ".WORD "ERIC" " c128 MODE: INTERMITTENT BUG WHEN TRYING TO ASSEMBLE FILE14 (BIG BITMAP) OFF OF DRIVE a, ONTO ram disk. sOMETIMES GET "DISK NAME MISMATCH" ERROR. c128:WHY DID 3208 NOT OVERFLOW SYMBOL TABLE? TABLE HOLDS 3208- i SENT 3208 PLUS 3 ALREADY THERE! cREATE A FILE78 WHICH IS A COPY OF FILE75, BUT WHICH TESTS .IF pASS1 STUFF. i DID THIS ON 10/1/88, AND HIT A WEIRD PHASE ERROR AT gLOBALlABEL:. i DON'T THINK THIS IS A BIG PROBLEM. sLIGHT PROBLEM IN EXPRESSION EVALUATION: PARSES JMP (LABEL) AS RELOCATABLE WITH MATH, SINCE IT HITS THE ENDING PARANTHESES. nEED TO EDUCATE GETeXPRESSION A LITTLE MORE SO THIS DOES NOT HAPPEN. tHIS IS NOT A PROBLEM WITH THE (,X) AND (),Y ADDRESSING MODES, BECAUSE THEY MUST HAVE RESOLVABLE zp EXPRESSIONS, AND SO THEY NEVER GENERATE EXTERNAL REFERENCES. ------------------------------------------------------------------------------- distant future mOVE LOCAL LABEL PARSING OUT OF EXPRESSION EVALUATOR: RIGHT NOW THE ERROR DETECTION IS VERY CONFUSED BY CASES SUCH AS LDA10$+4 LDA4+10$+6666666666666 LDA10$+20$+30$;THREE REFERENCES ADDED TO LIST, ;ONLY LAST ONE DELETED... mINOR PROBLEM: a LINE SUCH AS .BYTE1,CRAP,2 WILL STILL GENERATE 3 BYTES OF CODE: WOULD BE NICE TO COMPLETELY REVERSE THE EFFECTS (CODE, lc INCS, EXREFS AND RELOCS GENERATED, ETC) OF A CODE LINE WHEN AN ERROR IS DETECTED. oTHERWISE THERE IS NO EASY WAY TO HANDLE THIS CASE. rELATED PROBLEM: IN CASES WHERE AN ERROR IS DETECTED IN PASS 2 AND not PASS 1, WE HAVE TO MAKE SURE THE SAME AMOUNT OF CODE IS GENERATED IN BOTH PASSES, SO THAT NO PHASE ERRORS SHOW UP. "tOO MANY LOCAL LABEL REFERENCES" IS A GOOD EXAMPLE OF THIS. sEE BEGINNING OF pARSEiNST FOR HOW i HANDLED THIS. LINKER DOES NOT WARN ABOUT WORD STAMPED INTO BYTE LOCATION: .BYTE eXTERN LDA #eXTERN;SEE FILE7 gEOlINKER things to do: - CORRECTED BAD mOVEdATA IN lINKhEADER WHICH WAS TRASHING SYMBOL TABLE, CAUSING BAD .sym FILE TO BE CREATED (TO AVOID, DO NOT CREATE CUSTOMIZED HEADER BLOCK) - CORRECTED BUG IN MODULE SWAPPING, WHICH CAUSED PROBLEMS WHEN WRITING .sym FILE TO OTHER DISK (TO AVOID, SET OUTPUT DRIVE = APPLICATION DRIVE) - NOW RUNS GEOdEBUGGER PROPERLY (HAD BAD PERM NAME) - TESTED .CBM LINK WITH MULTIPLE .REL FILES: WORKS OK - REMOVED WARNINGS ABOUT mOVEbdATA OVERLAPPING SYMBOL TABLE - FIXED: "SYMBOL DEFINED MORE THAN ONCE"- IS PRINTING FILENAME INSTEAD OF SYM - FIXED: IF SYM ERROR IN HEADER FILE, ERROR MESSAGE FUNNY - FIXED: IF SYM TABLE EMPTY, SEARCHES ALL OF MEMORY FOR SYMBOL - FIXED: PRINTS CORRECT ERROR WHEN HEADER BLOCK WRONG SIZE - FIXED: DOES NOT DELETE OLD FILES WHEN OUTPUT DRIVE NOT INPUT DRIVE - FIXED: SEQ, CBM, AND VLIR .obj FILES SHOULD NOW HAVE CORRECT SIZE. - RE-INSTALLED RESIDENT CODE MUNGING - CLEANED UP SOME 40/80 COLUMN PROBLEMS IN iNIT MODULE after beta 1: ADD FILES TO TEST LIST fUTURE: i AM NOT SO SURE THE hEX/DECIMAL/OCTAL ETC PARSERS WORK. SAME PROBLEMS IN ASSEMBLER? i MAY HAVE SCREWED UP HOW IT EVALUATES EXPRESSIONS IN .mod STATEMENTS sEE rESIDENT/GETlINE, AND A VARIABLE "OPERAND" WHICH DETERMINES WHERE A WORD BOUNDARY IS. done: - REORDERED MODULES - MADE SURE THAT PROGRAM HAS A TOP-LEVEL IN RESIDENT, AND THAT EVERYTHING IS A CALL FROM IT - UPDATED HOW SWAP AND DRIVE ROUTINES WORK - COMBINED fILE, dRIVE, AND cOMPACT MODULES - UPDATED gETfILENAME, WITH CHANGES WE MADE TO GEOaSSEMBLER - COPIED NEW tOtEXT AND tObITMAP ROUTINES OVER FROM ASSEMBLER - MOVED SOME INIT CODE TO fILE MODULE - MOVED ERROR FILE CREATION TO fILE MODULE - REMOVED ALOT OF UNUSED CODE IN EXPRESSION EVALUATOR, REMOVED BUGS - CREATED gETlINEaNDwORD - oPENaNOTHERfILE -> oPENrELfILE - REWROTE HOW lnk FILE IS PARSED MOVED MOST OF IT TO fILE REWROTE MID-LEVEL AND TOP-LEVEL PARSING ROUTINES DELETED SOME ERROR MESSAGES, ADDED SOME - UPDATED SCREEN HANDLING - REWROTE HOW SYMBOLS ARE RELOCATED - REWROTE HOW RELOC POINTERS ARE READ IN AND USED - REWROTE HOW EXPRESSIONS ARE READ IN AND USED - REWROTE ROUTINE TO SEARCH SYMBOL TABLES- REMOVED LOT OF EXCESS CODE, POSSIBLY SOME BUGS. SEARCHES 2-3 TIMES FASTER NOW. - SIMPLIFIED HOW SYMBOLS ARE COMPACTED, FIXED, SORTED, AND WRITTEN OUT TO DISK - PLACED rES AND sWAP TABLES NEXT TO EACH OTHER, COMMENTED OUT ALL BIGsEQ CODE - rewrote HOW .obj FILE IS CREATED AND WRITTEN TO, INCLUDING CUSTOM HEADER BLOCK / cbm FILE CONSIDERATIONS - REWROTE HOW HEADER BLOCK .rel FILE IS LINKED TO REST OF APPLICATION- HEADER .rel FILE CAN NOW HAVE ITS OWN SYMBOL DEFS, WHICH GO TO SWAP TABLE. - rewrote HOW LINKER OPENS GEOwRITE OR GEOdEBUGGER (CODE FROM ASSEM) - BROUGHT NEW tOtEXT AND tObITMAP CODE OVER FROM GEOaSSEM - REWROTE ERROR PRINTING ROUTINES - reduced total size of app from 24k TO 20k - reduced size of resident by 2589 bytes! - DID COMPLETE WALK-THROUGH OF NEW CODE, MAKING SURE THAT DISK AND USER ERRORS CAUSED THE RIGHT THING TO HAPPEN - FINAL WORK ON FILE CREATION/DELETION STUFF - RE-INSTALLED stop KEY CHECKS - ADDED cHECKdISKeRROR CALLS THROUGHOUT PROGRAM - ADDED CODE TO SET FILENAME POINTER IN CASE ERROR OCCURS - ADDED NEW ERROR DIALOG BOX: PRINTS FILENAME, ERROR, ALLOWS cancel - ADDED CODE TO DELETE OUTPUT FILES CORRECTLY ON ERROR, DISPLAY SECOND db IF SECOND DISK ERROR - NUKED ERROR MESSAGE POINTER TABLE TO SAVE BYTES IN RESIDENT - rewrote HOW WE CREATE THE .err FILE MADE SURE RULER AND VERSION # ARE ok - rewrote HOW WE CREATE THE .dbg FILE - MODIFIED HOW WE CREATE THE .sym FILE- DOES THIS NEED ANY WORK? DON'T FORGET TO TEST INSTALLATION WITH 1571 DRIVE! tHINK ABOUT 2 DIFFERENT PHYSICAL DRIVES ON NON-reu SYSTEM: WILL geos TELL ME THAT DRIVER DOES NOT EXIST, OR WILL i CRASH? bUG: 1571 AS a, 1581 AS b, RUN DEBUGGER ON b, TRY TO SELECT DRIVE a, AND SINCE THERE IS NO reu, geos sETdEVICE DOES NOT WORK. dOES IT RETURN ERROR CONDITION TO DEBUGGER? OR JUST CRASH... bUGS IN tUESDAY (6/21) 12pm VERSION: STOP COMMAND IN HIDDEN MODE DOES NOT DO THE RIGHT THING! CHANGE NOTES IN GET INFO BOX bUGS IN THU (6/16) 4pm VERSION: FIXED: setu U.E2 COMMAND DOES NOT CLEAR HIGH BITS! FIXED: sym R0l FINDS R0 ALSO! FIXED: GETN COMMAND IS READING DISK INFO FROM BANK 0! FIXED: IN RBOOT, QUIT, AND EXIT COMMANDS, PRESSING f8 SCREWS UP LINE FIXED: STOP COMMAND DOES NOT CANCEL HIDDEN MODE ANYMORE FORGET: @# OPERATOR DOES NOT TAKE IN-LINES INTO ACCOUNT INVESTIGATED: WE CANNOT PROTECT ALL OF i/o SPACE WARN IN MANUAL: IN bACKrAMsUPER (AND HAVE reu), SHOW geos SCREEN WHEN TOP-STEPPING THROUGH mOVEdATA, BECAUSE IT USES dma TO MOVE SMALL THINGS. (tHEY COULD DISABLE mOVEdATA IN CONFIGURE TO BE SURE. aLSO WARN THAT AN rboot BRINGS BACK OLD mOVEdATA/rboot FLAG VALUES.) bUGS IN EARLIER VERSIONS: FIXED: SETU SS,0 PLACES CURSOR WRONG FIXED: PRINT @ SIGN WHERE pc SHOULD GO FIXED: NOT DELETING sbp'S CORRECTLY FIXED: TRASHES x (AND OPEN MODES) WHEN SETTING sbpS TO ram FIXED: DOES NOT LOAD cbmS WITH HEADER CORRECTLY FIXED: $03fc-$03ff STILL TREATED DIFFERENTLY FIXED: IN 64 MODE, IS NOT TRACKING BANK INFO WITH sbpS CORRECTLY FINISH NOW WORKS WITHIN INLINE CALL CLEANED UP fETCHiNST USAGE N COMMAND WILL NOW SET FINAL lc CORRECTLY IF LAST LINE IS INLINE jsr FIXED fINDnEXT: m MODE SHOULD NOW IGNORE INLINE STUFF CHECK UP AND DOWN IN BOTH MODES, CHECK REG, FLAG, OPT, ETC CORRECTED "w": NOW USES fINDnEXT, SO SHOULD WORK. FIXED jsr COMMAND TEST: BOOT APP AND TRY jsr $400: SHOULD COME BACK TO US BEFORE GOING OFF TO geos MAINLOOP FIXED SKIP COMMAND: TAKES BANK INTO ACCOUNT FIXED DIFF AND COPY COMMANDS FIXED f8 IN MINI DEBUGGER RIGHT-SIDE PROMPT BUG FIXED LOAD cbm APP WITH HEADER BUG FIXED $3fc-$3ff BUG FIXED BANK INFO COMPARISONS ADDED i AND r PRINTING TO OPEN COMMAND PRINTS ERROR IF TRY TO SET bp IN rom OR io FIXED io AREA DECODE BUG ($d022) CLEANED UP INIT CODE: ZEROED ALL VARS AT START, SAVED LOTS OF BYTES FIXED sTUFFbrkaTlsa BUG WHICH i CREATED YESTERDAY! ------------------------------------------------------------------------------ mAJOR CODE SECTIONS: ------------------------------------------------------------------------------ fOR tEST lIST: GOOD TEST FOR c64 VERSION: CHECK TO SEE IF $ff00 AND $d506 ARE CHANGING SPECIAL ASSIGNMENTS FOR bETA tESTERS? SINGLE STEPPING THROUGH DIFFERENT BANKS MEMORY ACCESS TESTS SYMBOL TABLE USE MACRO DEFINITION USE ------------------------------------------------------------------------------ nEW cONCERNS: WHAT IF IN 64 MODE THEY SWAP rom IN AND USE DEBUGGER gETbLOCK? ------------------------------------------------------------------------------ tHINGS tO rESEARCH: reset EXECUTES roms, BUT DO THEY CHECK ram? bANK 0 pAGE 3 ISSUES: i FILL FIRST WITH $00 AND THEN WITH $ED, AND DESKtOP AND ICON EDITOR HAD NO PROBLEMS RUNNING. CANNOT LOAD OTHER DESK ACCESSORIES? EASY WAY TO LOAD DRIVERS? ???CONVERT TABS FOUND IN MACRO DEFS ???dir SAVE pc? iNITfORio TRASHES $314 AREA VECTORS- yes: $314 AND $318 (irq AND nmi) ------------------------------------------------------------------------------ nOT CONCERNED WITH: DEBUGGER ASSUMES ALL GEOwRITE VERSIONS ABOVE 1.1 ARE THE SAME. 64 MODE ON c128: CAN SET FOR 2mhz? restore KEY BOUNCES! gENERATES TWO nmi SIGNALS, SPACED ABOUT 200 USEC APART ------------------------------------------------------------------------------ lOW pRIORITY: uSER COMPLAINT: HIS PROGRAM RAN UNDER dgb, CRASHED UNDER geos. hE HAD FORGOTTEN TO PUT A DUMMY ICON UP. pOSSIBLY RELATED TO DEBUGGER CLEARING MEMORY. sHOULD NOT ALLOW USER TO LOAD APPLICATION WHICH TRASHES mINIdEBUGGER IN MEMORY OR WHICH WOULD TRASH geos ADD OPTION TO DISABLE geos dISK USAGE? (SO THEY WON'T DO THE WRONG THING WHEN DEBUGGING GAMES) ADD DETECTION FOR TRASHED geos? (WOULD FORCE RBOOT ON EXIT) READ OPTION PRESETS FROM VALUE OF options CONSTANT IN SYMBOL TABLE AFTER USER HAS TRASHED MEMORY, SHOULD BOOT geos FROM DISK... OPTION TO ALLOW THEM TO USE brk AS AN INSTRUCTION (GET TO THEIR VECTOR) ------------------------------------------------------------------------------ fOR mANUAL: MINOR: HOLDING MOUSE BUTTON LOOKS LIKE RUN/STOP DURING BOOT THEIR irq SERVICE ROUTINE MUST FINISH WITH AN rti BECAUSE OF THE WAY THINGS ARE PUSHED... dEBUGGER WILL NOT LOAD THEIR gAME OVER geos: gAME MUST CALL geos ROUTINES TO GET THE REST OF IT IN (THIS IS WHAT DESKtOP WOULD REQUIRE ANYWAY.) PLACES brk AT rSTRaPPL IF IS RUNNING DESK ACCESSORY MENTION "pRESS restore SHARPLY" IN MANUAL $d506 AND $ff00 SHADOWED R.MM NUKED COMPLETELY. r COMMAND NO LONGER SHOWS mEMmAP SCREEN FLICKER DURING STEP IS DUE TO POOR geos 128 INTERRUPT CODE HOLDING KEY DOWN WHEN DEBUGGER STARTS WILL FORCE ERROR ON FIRST LINE USER MAY WANT TO CHANGE R COMMAND: CREAT MACRO WHICH DOES r AND bank. USER CAN CHANGE pc MEM MAP DIRECTLY BY ACCESSING FF00 AND D506 IF USER'S CODE UPDATES SCREEN REGISTERS, BUT DEBUGGER SCREEN IS VISIBLE, THEN WHEN DEBUGGER KICKS IN IT WILL ASSERT ITS VALUES, LOSING THE USER'S NEW VALUES. wARN THEM TO ENABLE TARGET SCREEN BEFORE EXECUTING SUCH CODE. SEE sPECS/USERnOTES FOR MORE... ------------------------------------------------------------------------------ aSSUMPTIONS: geos 128 HAS SAME $FFFA VECTORS IN b1 AND b0. i ASSUME THIS TO BE TRUE FOR ALL FUTURE VERSIONS. ------------------------------------------------------------------------------ sAVE bYTES: MINI DEBUGGER DOES NOT HAVE TO BE AS CAREFUL ABOUT SCREEN STUFF IN RESIDENT: COMPACT THAT DAM dRIVE ICON! ------------------------------------------------------------------------------ fUTURE: DO NOT EXECUTE ILLEGAL INSTRUCTIONS COULD CUSTOMIZE DEBUGGER ACCORDING TO 64/128 MODE reu AS TRACE BUFFER? DON'T ALLOW TWO MACROS OF SAME NAME IN MACRO FILE WRITE OUT MACRO FILE ADD MODULES TO DEBUGGER FOR MORE FEATURES SENSE USER'S MODULE SWAP AND CORRECT sbpS? COULD SAVE b1/b0 INFO IN SYMBOL TABLE TO FURTHER REDUCE CONFLICTS MEMORY RANGE COMMANDS COULD EASILY MOVE DATA FROM BANK TO BANK COMMANDS LIKE w WILL NOT WORK IF PRINTING IS OFF, BECAUSE dISPLAYlOCATION IS NEVER CALLED, BYTES NEVER READ, POINTERS NEVER MOVED. tHIS COULD BE CLEANED UP. CLRB IS NOW CRIPPLED BECAUSE IT RELIGIOUSLY CHECKS FOR EXACT BANK INFO WHEN SEARCHING THE sbp LIST. cOULD REMOVE THIS RESTRICTION TO MAKE THE CLRB COMMAND EASIER, BUT THEN TRYING TO REMOVE A DOUBLE-sbp (BANK1 AND 0, SAME ADDR) USING AN OPEN MODE WOULD BE IMPOSSIBLE. aCTUALLY, THERE IS A DEEPER PROBLEM WITH THE WAY WE STORE BANK INFO WITH sbpS IN THEIR TABLE: WE SHOULD JUST STORE THE EFFECTIVE BANK DIFFERENCE, NOT THE 16 BITS OF INFO. iF THE SETB COMMAND IS CHECKING FOR EXACT MATCHES WHEN IT INSERTS A NEW sbp, THEN YOU COULD HAVE SEVERAL "EQUAL" sbpS IN THE SAME TABLE. ------------------------------------------------------------------------------ fINISHED: 40/80 COLUMN TEXT BITS AND CENTERING STUFF, MOVED TO ONE FILE, STANDARDIZED db TEXT POSITIONS (WILL HELP APPLE PORT) MACRO LOAD BUGS, EXTENSIVE ERROR CHECKING, PAGE/LINE # BUGS SYMBOL LOAD BUG INFO BOX CODE: DISPLAYS STATUS MESSAGES AS FILES LOAD stop KEY BUG BUGS IN LOADsAVEbYTE ERROR CHECKING DURING SYMBOL TABLE LOADS LOADS DEFAULT.DBM EVEN IF NO FILENAME GIVEN NEED rESpREPfORqUIT EXTENSIVE ERROR CHECKING DURING MODULE SWAPS, DEBUGGER LOADS, AND FILENAME SELECTION (INCLUDING PRINTING CURRENT FILENAME DURING ERROR) ADDED MEMORY r/w CHECKS FOR $ff01-$ff04 PAGE # IN MACRO FILE LOADS FIXED 80 COLUMN SCROLL BUG rESpREPfORqUIT RESTORES USER'S SCREEN, NOT BE SAME AS geos SCREEN CLEAR PENDING INTERRUPT BEFORE STEPPING TEST NEW lcra-lcrd STUFF INVERTS ADDRESSES IF DISPLAYING BANK #0 ADDRESS gETbLOCK, pUTbLOCK: CALL BANK 1 ROUTINE, DISPLAY BANK 1 DATA jsr DOES WORK IN EITHER BANK (BECAUSE IS LIKE A TOP-STEP) reu CHECK UNDER geos v1.2 TEST RBOOT IN ALL 5 CONFIGS c64 MODE! BANKiNFO1/2 VARIABLE: CARRIES INFO IN 64 AND 128 MODES CALL gET1STdIReNTRY, USE R5, CALL GETnXTdIReNTRY - NEED TWO NEW PRIMITIVES - CHANGE DIR MACRO TRACKED DOWN SCREEN FLICKER BUG (IS geos 128 INTERRUPT CODE!) - IMPLEMENTED NEW 3-LEVEL nmi ENABLE/DISABLE CODE - FOUND BUG IN 128 geos iNITfORio - ADDED cia2 nmi HANDLING - WROTE DOCUMENTATION ON STRAY INTERRUPT TRAPPING - WROTE ROUTINES SO USER'S APPLICATIONS CAN SET INTERRUPT SERVICE ROUTINE VECTORS CORRECTLY WHEN RUNNING UNDER gEOdEBUGGER - DOCUMENTED VECTORS IN gEOdEBUGGER WEDGE CODE WHICH ARE USEFUL - FIXED "LDA a000" PARSE BUG - FIXED SYM SEARCH BUG - FIXED BUG IN STOPMAIN - FIXED DISASSEMBLY BUG: NOW DISPLAYS CODE WHEN CANNOT FIND LABEL MACRO ERROR BUG STOP KEY BUG CIA1 DDR ASSERTION RTI BUG CENTERING lDfILE USAGE BUG FILE INIT ADDRESS BUG EXIT AFTER DISK ERROR CORRECTED SELECT FILE db ICONS, SCROLLING BUG FILE db SELECTION AREA SETU / PR U.E1 BUG DIR / GETBLOCK FROM ram disk BUG FLAGS ON BOOT BUG rboot MORE INTELLIGENT IGNORES stop KEY IN LEFT-SIDE MODE REWROTE SOME PRINTING ROUTINES ADDED NEW hide FEATURE CORRECTED 128 MODE KEYBOARD SCAN PROBLEM ADDED KERNAL CHECKING TO gET1STdIReNTRY/gETnXTdIReNTRY AND MADE SOME CORRECTIONS DISPLAY COPYRIGHT MESSAGES DISPLAY DISK NAME WHEN SELECTING FILE TOP-STEP THROUGH INLINE CALLS DISASM UP AND DOWN THROUGH INLINE CALLS PAGE 3 CODE ASSERTS VALUE OF $0000 TO $2f DUMPD COMMAND SETS lc TO b1$8100 CORRECTED gETbLOCK/pUTbLOCK CORRECTED DISK AND DRIVEA/B COMMANDS CORRECTED pRINTdISKnAME COMMAND REWROTE WAY THAT THE 3 MONITORS READ/WRITE/SWAP MISC. geos VECTORS AND VARIABLES JUST FIXED 64 MODE BUG, MADE TABLE SHORTER USING {SHIFT--} OPERATOR BACKRAM SUPER SHOULD DISABLE da LOADS ------------------------------------------------------------------------------ files in this directory /STAFF/JIM/GEOS/products/GEOpROG/GEOdEBUG/sPECS uSEFUL: iNITfORiobUG:DETAILED INFO ON c128 iNITfORio BUG reunOTES:FULL DOC ON geos reu USAGE AND HOW WE USE IT reuBUGS:HOW TO WARN USER THAT dma USES vic BANK INFO APPtYPES:INFO ON HOW DESKtOP AND DEBUGGER LOAD APPLICATIONS MEMpROTECT:DETAILED SPEC OF HOW DEBUGGER'S LOADsAVEbYTE ROUTINE WORKS CBMaPPS:INFO ON HOW TO USE PRODUCT TO DEVELOP cbm APPLICATIONS HIDEmODE:ALL ABOUT THE NEW HIDE DEBUGGER SCREEN FEATURE INTERRUPTS:NOTES TO USER ABOUT INTERRUPTS NMI:NOTES ON nmi INTERRUPTS, restore BOUNCE, ETC RBOOTwARN:WARNING ABOUT RBOOT COMMAND, KNOWN PROBLEMS VIEWcOMMAND:HOW NEW VIEW COMMANDS WORK ENVIRONMENT:VIEW COMMANDS- DECISIONS MADE WISHlIST:IDEAS... nOT USEFUL: 128IDEAS:GENERAL IDEAS ON INSTALLING USER'S isr TRAPPING STRAY INTERRUPTS 40/80 COLUMN SCREEN USAGE ON 128 MEMORY MAP REGISTERS, CLOCK SPEED, KEYBOARD iNITiNTsVC2.OLD: OLD isr INSTALL INFO mini:THINGS NUKED IN mini DEBUGGER TO SAVE SPACE specs:OUTLINE FOR PRODUCT SPECIFICATION ASSEMiNbASIC:HOW TO USE GEOlINKER TO CREATE basic APPS BOOT:OLD OUTLINE OF DEBUGGER BOOT SEQUENCE DESIGNdECISIONS: DECISIONS MADE ALONG THE WAY PROBLEMS:UNRESOLVED PROBLEMS IN THE DESIGN CONTEXTsWITCH:INFO ON HOW c64 / c128 INTERRUPTS WORK, AND HOW DEBUGGER'S CONTEXT SWITCH WORKS WITH THEM WARNINGS:PROBLEMS IN THE DESIGN FOR WHICH NO SOLUTION EXISTS SCREENdECISIONS: DECISIONS MADE IN DESIGN OF v2 SCREEN ROUTINES c128 iNITfORio BUG? oN BOTH THE 64 AND 128, THE cia2 CHIP HAS THE CAPABILITY OF GENERATING AN nmi SIGNAL. tO PREVENT THIS FROM OCCURING DURING DISK-ACCESS ROUTINES, THE geos iNITfORio ROUTINE FORCES THE cia2 TO GENERATE ONE INTERRUPT BY SETTING THE cia TIMER VALUE TO A LOW NUMBER LIKE 1. iNITfORio KNOWS THAT IT WILL GET CONTROL WHEN THIS FORCED-nmi OCCURS BECAUSE IT SWAPS THE KERNAL rom INTO THE HIGH-MEMORY AREA AND SETS THE KERNAL'S PAGE 3 nmi VECTOR (NMIVEC, $0318) TO POINT TO A DUMMY nmi ROUTINE. - ON THE c64, THIS WORKS FINE, EXCEPT FOR THE FACT THAT iNITfORio IS TRASHING ANY nmi VECTOR THAT THE APPLICATION WRITES TO $0318. - ON THE c128, iNITfORio DOES NOT SWAP rom IN CORRECTLY (IT IS CHANGING LOCATION $0001). sO WHEN IT FORCES THIS nmi TO OCCUR, THE 6510 USES THE VECTOR AT b1$fffa OR b0$fffa, WHICH NORMALLY POINT TO THE geos nmi HANDLER ROUTINE, WHICH SIMPLY DOES AN rti. iF AN APPLICATION CHANGES THE geos nmi VECTORS AT b0$fffa AND b1$fffa, THEN THE USER'S HANDLER ROUTINE WILL GET CALLED EVERY TIME iNITfORio IS CALLED. tHE USER'S HANDLER ROUTINE SHOULD POLL THE cia CHIP AND RETURN IMMEDIATELY IF THE nmi WAS GENERATED BY THE cia. iF THE USER IS EXPECTING nmiS FROM THE cia CHIP, THEN THIS "POLLING" PROCESS MUST ALSO INCLUDE AN EXAMINATION OF THE STACK TO SEE IF iNITfORio IS IN PROGRESS... cONCLUSION: dUE TO THE FACT THAT iNITfORio MAKES SOME ASSUMPTIONS ON THE c128, USERS WHO WRITE THEIR OWN nmi HANDLER ROUTINE WILL HAVE TROUBLE. pOSSIBLE FIXES: c64 AND c128 iNITfORio SHOULD BOTH BRING rom IN, AND SHOULD BOTH SAVE THE nmi VECTOR AT $0318 (BANK 0 ON THE 128), AND RESTORE IT LATER. tHIS WOULD MAKE iNITfORio WORK ALL THE TIME (REGARDLESS OF WHAT THE USER HAS DONE TO THE VECTORS) AND IT WOULD NOT AFFECT THE APPLICATION'S VECTORS. 1764/1700/1750 rAM eXPANSION uNITS ---------------------------------- 1764:128k2 64k BANKS, INTENDED FOR c64 CAN BE EXPANDED TO 512k 1ST 64k BANK: geos SYSTEM STUFF. 2ND BANK UNUSED. 1700:256k4 64k BANKS, INTENDED FOR c128 CAN BE EXPANDED TO 512k 1ST 64k BANK: geos SYSTEM STUFF. 2ND - 4TH BANKS: 1541 ram disk OR 1541 DISK SHADOW. 1750:512k8 64k BANKS, INTENDED FOR c128 CAN BE MADE TO WORK ON c64 1ST 64k BANK: geos SYSTEM STUFF. 2ND BANK UNUSED. 2ND - 8TH BANKS: 1541/1571 ram disk OR 1541/1571 DISK SHADOW. reu bANK #0: (1ST BANK) bANK #0 IS RESERVED FOR geos KERNAL USE. geos WILL, HOWEVER, HONOR SOME ENABLE BITS IN SYSramfLG AND ITS' SHADOW VARIABLE SYSfLGcOPY. bY CLEARING SOME OF THESE BITS, YOU CAN PREVENT geos FROM USING CERTAIN AREAS, AND THEN YOUR APPLICATION CAN USE sTASHram, fETCHram, ETC TO STUFF DATA UP THERE. c128 64 geos128 geoscONTROL BIT ----------------------------------------------------------- $0000 - $38ffmOVEdATA SWAP AREAmOVEdATA SWAP AREA1xxxxxxx $3900 - $78ffmOVEdATA SWAP AREAgeos KERNAL FOR rbOOTNOTE 1 $7900 - $7dfftObASIC CODEtObASIC CODExx1xxxxx $7e00 - $82ffgeos KERNAL FOR rbOOTgeos KERNAL FOR rbOOTxx1xxxxx $8300 - $b8ffdEVICE DRIVERS a, b, cdEVICE DRIVERS a,b,cx1xxxxxx $b900 - $fc3fgeos KERNAL FOR rbOOTgeos KERNAL FOR rbOOTxx1xxxxx $fc40 - $ffff????????? nOTE 1: DIFFERENT FOR 64/128. reu bANKS 1 THROUGH 7: uSED BY DEVICE DRIVERS FOR ram disk AND SHADOWING. iT IS A REAL BAD IDEA TO TOUCH THESE BANKS. ------------------------ reu dma notes: DISABLE SHARING WHEN USING reu dma RELOCATION HIGH BYTE: ONLY b0 R/W CAPABLE, MUST WRITE TO LOW BYTE BEFORE CAN READ INFO BACK FROM HIGH BYTE (INDICATING RELOCATION IS ACTIVE) mIGHT BE ABLE TO USE THIS TO DECIDE WHETHER OR NOT nmi OCCURRED WHILE SOMEONE WAS STUFFING VALUES IN THESE REGISTERS. ------------------------ mATT: i GUESS IT IS REALLY ONLY 1 BUG, AND IT IS NOT A BUG IF THE USER IS USING THE STANDARD geos SCREEN FOR DISPLAY, AND IS NOT TRYING TO dma DATA TO BACKRAM (BANK 0). tHERE ARE A NUMBER OF CONCERNS WHEN USING THE reu'S dma CHIP ON A c128: 1) THE CLOCK MUST BE SLOW (1mhz, NOT 2mhz) 128 geos HANDLES THIS CORRECTLY. 2) THE io SPACE MUST BE IN, SO YOU CAN ACCESS THE dma CHIP (BIT 0 OF $FF00 "CONFIG" MUST BE A 0) UNDER 128 geos, THE io SPACE IS ALWAYS IN. 3) WHEN THE dma CHIP FORMS AN ADDRESS FOR WHERE IN THE c128'S 128k TO READ AND WRITE, IT IGNORES THE STANDARD BANK 0 / BANK 1 SELECTION CONTROLS AND THE "BANK SHARING" CONTROLS. tHESE CONTROLS i AM TALKING ABOUT ARE BITS 7 AND 6 OF $ff00 (CONFIG) AND BITS 5 THROUGH 0 OF $d506 (rcr) IN THE io SPACE. tHE dma CHIP KNOWS WHICH OF THE TWO 64k BANKS TO USE BECAUSE IT USES THE SAME BANK 0 / BANK 1 CONTROL LINE THAT THE vic CHIP USES. tHIS CAN BE USEFUL: NO MATTER WHAT BANK SETUP YOU HAVE FOR THE 8510 PROCESSOR CHIP, YOU CAN HAVE THE dma CHIP READ/WRITE TO ANYWHERE IN EITHER BANK. nOW DEPENDING ON WHICH BANK THE vic CHIP IS LOOKING AT AND WHICH BANK YOU WANT TO r/w TO, YOU MAY HAVE TO CHANGE THE vic CHIP BANK # SETTING TEMPORARILY (WILL CAUSE SCREEN TO FLASH). cODE TO DO THIS: (ASSUMES R0-R3l HAVE ALREADY BEEN SET UP FOR sTASHram) ;FIRST, i ASSUME io SPACE IS IN, BECAUSE UNDER ;128 geos, $ff00 = $7e, MEANING io IS IN. LDAMMU+6;GET "rAMcONTROLrEGISTER" PHA;SAVE CURRENT BANK SHARING ;STATUS AND vic BANK # INFO ;ON STACK AND#%00111111;KEEP b5-b0 INTACT ORA#bank << 6;SET bIT 6 ACCORDING TO BANK WE ;WANT vic AND dma CHIPS TO SEE STAMMU+6;SAVE NEW vic BANK # INFO JSRsTASHram/fETCHram ETC... ;CALL geos TO TURN ON dma CHIP PLA;RESTORE vic BANK # STAMMU+6 cOMMODORE 64/128 geos fILE TYPES, AND IF THE DESKtOP AND/OR GEOdEBUGGER CAN LOAD THEM. cbmgeosoPEN FROM TYPEFILE TYPEDESKtOP dESCRIPTION ----------------------------------------------------------------- delANYTHINGNOdELETED FILE seqnot_geosNOcOMMODORE SEQUENTIAL DATAFILE, PROBABLY GENERATED BY basic PROGRAM. seqdataNOsAME AS ABOVE, WITH HEADER ADDED BY iCON eDITOR. -------------------------------------------------------------------------- prgnot_geosYES *1cOMMODORE basic OR ASSEMBLY PROGRAM. iF THE FILE IS A basic PROGRAM, THEN IT WAS PROBABLY CREATED USING c64 OR c128 basic'S "save" COMMAND. tHE DESKtOP CAN ALWAYS LOAD SUCH A PROGRAM, AND IN SOME CASES CAN tURBO-LOAD IT. iF THE FILE IS AN ASSEMBLY-LANGUAGE PROGRAM, THEN IT WAS PROBABLY CREATED USING AN ASSEMBLER UTILITY, OR USING c128 basic'S "bsave" COMMAND. prgbasicYES *2cOMMODORE basic PROGRAM, WITH HEADER BLOCK ATTACHED BY iCON eDITOR. iF PROGRAM IS LESS THAN 31k IN SIZE, THE DESKtOP WILL HAVE geos tURBO-LOAD IT. prgassemblyYES *3cOMMODORE ASSEMBLY PROGRAM, WITH HEADER BLOCK ATTACHED BY iCON eDITOR. iF PROGRAM LOADS TO APPLICATION SPACE ($400-$7fff), THEN THE DESKtOP WILL HAVE geos tURBO-LOAD IT. -------------------------------------------------------------------------- usrnot_geosNOoLD cOMMODORE "USER" FILE. usrbasicNOillegal combination usrassemblyNOillegal combination usrdataNOillegal combination usrsystemNOgeos SYSTEM FILE (seq OR vlir STRUCTURE) usrdesk_accYESgeos DESK ACCESSORY (seq STRUCTURE) usrapplicationYESgeos APPLICATION FILE (seq OR vlir) usrappl_dataYESDATA FILE FOR A geos APP. (seq OR vlir) usrfontNOgeos FONT FILE (vlir) usrprinterNOgeos PRINTER DRIVER (seq) usrinput_deviceNOgeos INPUT DEVICE (MOUSE, KOALA, ETC. seq) usrdisk_deviceNOgeos DISK DEVICE DRIVER usrsystem_bootNOgeos SYSTEM BOOT FILE (FOR geos, geos boot, geos kernal) usrtemporaryNOtEMPORARY FILE TYPE, FOR SWAP FILES. usrauto_execYESaPP (seq OR vlir) WHICH LOADS AND RUNS UPON BOOT usrinput_128NOgeos 128 iNPUT DRIVER -------------------------------------------------------------------------- relnot_geosNOcOMMODORE RANDOM-ACCESS DATAFILE, AS IF GENERATED BY basic PROGRAM. cANNOT BY GIVEN AN ICON BY iCON eDITOR BECAUSE WOULD DESTORY EXISTING POINTER TO DATA CHAIN. -------------------------------------------------------------------------- nOTES: *1: (prg, not_geos) wHEN YOU TRY TO OPEN THIS TYPE OF PROGRAM FROM THE DESKtOP, THE DESKtOP'S "dObASIClOAD" ROUTINE WILL LOAD THE PROGRAM'S FIRST DATA BLOCK, TO CHECK ITS LOAD ADDRESS. ADDR < $0400 iS A "STACK-GRABBING" ASSEMBLY LANGUAGE PROGRAM. geos CANNOT tURBO-LOAD THIS, SO WE FORCE basic TO EXECUTE: load "NAME",8,1. ADDR = $0801($1c01 ON 128) iS A basic PROGRAM. tHE DESKtOP WILL CHECK THE FILE SIZE INFORMATION IN THE DIRECTORY ENTRY TO SEE IF THE PROGRAM CAN BE tURBO-LOADED. iF THE basic PROGRAM IS <= 30480 BYTES, THE DESKtOP WILL HAVE geos tURBO-LOAD IT, AND THEN FORCE basic TO EXECUTE THE run COMMAND. iF THE basic PROGRAM IS LARGER THAN THIS, THE DESKtOP WILL NOT LOAD IT. ADDR = OTHER tHE c64 DESKtOP WILL NOT ALLOW YOU TO LOAD THIS APPLICATION. tHIS IS SO THE DESKtOP WILL NOT ATTEMPT TO RUN A c128 basic PROGRAM UNDER c64 basic. tHE c128 DESKtOP WILL USE THE basic "boot" COMMAND TO LOAD THIS FILE. iF YOU ATTEMPT TO OPEN SUCH A PROGRAM FROM gEOdEBUGGER, IT MUST HAVE A LOAD ADDRESS OF $0400 OR HIGHER. gEOdEBUGGER WILL NOT CHECK THE LOAD ADDRESS TO SEE IF THE PROGRAM IS basic CODE, SO YOU CAN USE GEOdEBUGGER TO EXAMINE THE INTERNAL STRUCTURE OF c64 AND c128 basic PROGRAMS. *2: (prg, basic) tHE DESKtOP WILL ATTEMPT TO LOAD SUCH A FILE IN THE SAME MANNER AS THE "ADDR = $0801" CASE ABOVE. aS NOTED ABOVE, THE DEBUGGER CAN ALSO LOAD SUCH A PROGRAM FILE. *3: (prg, assembly) wHEN YOU TRY TO OPEN THIS TYPE OF FILE FROM THE DESKtOP, THE DESKtOP'S "dOaSSEMBLYlOAD" ROUTINE WILL LOAD THE FILE'S FIRST DATA BLOCK, TO CHECK ITS LOAD ADDRESS. ADDR < $0400 iS A "STACK-GRABBING" ASSEMBLY LANGUAGE PROGRAM. geos CANNOT tURBO-LOAD THIS, SO THE DESKtOP FORCES basic TO EXECUTE: load "NAME",8,1. $0400 <= ADDR < $0800 tHE c64 DESKtOP WILL NOT ALLOW YOU TO LOAD THIS PROGRAM, BUT THE c128 DESKtOP WILL. ADDR >= $0800 tHE DESKtOP WILL LOAD THE PROGRAM'S HEADER BLOCK, TO CHECK ITS ENDING ADDRESS. iF THE PROGRAM ENDS BELOW $8000, THE DESKtOP WILL HAVE geos tURBO-LOAD THE PROGRAM. basic WILL THEN EXECUTE A sys TO THE PROGRAM'S INIT ADDRESS FROM THE HEADER BLOCK. iF THE PROGRAM ENDS AT OR ABOVE $8000, THE DESKtOP WILL FORCE basic TO EXECUTE: load "NAME",8,1:sys (INIT ADDRESS) iF YOU ATTEMPT TO OPEN SUCH A PROGRAM FROM gEOdEBUGGER, IT MUST HAVE A LOAD ADDRESS OF $0400 OR HIGHER. gEOdEBUGGER WILL SET THE pc TO THE VALUE OF THE INIT ADDRESS WHICH IS STORED IN THE HEADER BLOCK. gEOdEBUGGER WILL NOT CHECK THE ENDING ADDRESS OF THE PROGRAM. gEOdEBUGGER mEMORY rEAD/wRITE rOUTINE ------------------------------------- wHENEVER THE DEBUGGER IS ASKED TO READ OR WRITE A BYTE TO MEMORY, IT WORKS THROUGH THE lOADbYTE/sAVEbYTE ROUTINE IN mONITOR/C64IO. eXAMPLES INCLUDE: - EXAMINING AND MODIFYING MEMORY USING "a" OR "m" OPEN COMMANDS - SETTING AND CLEARING INSTRUCTION BREAKPOINTS - MEMORY RANGE COMMANDS: MOVE, FILL, DIFF, FIND tHESE TWO ROUTINES ARE BOTH VERY SHORT: THEY SIMPLY SET A FLAG INDICATING WHETHER WE ARE READING OR WRITING, AND THEN CALL lOADsAVEbYTE. lOADsAVEbYTE GOES THROUGH A FOUR STEP PROCESS TO DETERMINE WHAT TO DO WITH THE MEMORY ACCESS REQUEST. tHIS IS A COMPLICATED PROCESS BECAUSE THERE ARE MANY CASES WHERE A DIRECT LOAD/SAVE IS OUT OF THE QUESTION: - THE USER IS TRYING TO MODIFY A BYTE IN ZERO PAGE, BUT THE MONITOR KEEPS THE USER'S ZERO PAGE IN THE MONITOR VARIABLE SPACE - THE USER IS TRYING TO MODIFY A BYTE IN THE APPLICATION SPACE, BUT IT HAS BEEN SWAPPED OUT TO THE reu - THE USER IS TRYING TO WRITE OVER MONITOR CODE - THE USER IS TRYING TO READ/WRITE TO THE OTHER BANK THAN IS CURRENTLY IN DURING MONITOR EXECUTION. - THE USER IS TRYING TO MODIFY cpu_data OR CONFIG, WHICH WOULD IMMEDIATELY CHANGE THE MEMORY MAP AND PROBABLY CRASH THE DEBUGGER. lOADsAVEbYTE'S FOUR STEP PROCESS CAN BE BROKEN DOWN AS: 1) hANDLE MEMORY MAP CONTROLS AT $0000, $0001, AND $ff00 (128) AS A SPECIAL CASE. 2) iF THIS ACCESS IS IN THE io SPACE, AND io IS ENABLED, USE THE io address table TO DECIDE WHICH io LOCATIONS HE CAN MODIFY DIRECTLY AND WHICH ONES WE KEEP SHADOWS FOR IN THE MONITOR VARIABLE AREA. 3) iF THIS ACCESS IS IN A SPACE WHERE rom IS CURRENTLY IN, THEN ONLY ALLOW READ OPERATIONS. tHE DEBUGGER DOES NOT ALLOW "BLEED THROUGH" WRITES TO RAM UNDERNEATH ROM. 4) iF NONE OF THE ABOVE CASES HOLD, THEN THE ACCESS MUST BE TO RAM. cALCULATE THE EFFECTIVE BANK NUMBER (128 ONLY), AND USE THE ram address table TO DECIDE WHICH LOCATIONS NEED RE-DIRECTION OR ARE ILLEGAL. hERE IS THE KEY USED IN THE LOOKUP TABLES ON THE FOLLOWING PAGES: MINI / SUPER / BACK SUPER m = MINI DEBUGGER CODE AREA (ILLEGAL TO READ/WRITE) s = SUPER DEBUGGER CODE AREA (MUST READ/WRITE TO reu SPACE) b = BACKRAM SUPER DEBUGGER CODE AREA (ILLEGAL TO READ/WRITE) x = USED BY ALL THREE MONITORS, NO COPY SAVED (ILLEGAL TO READ/WRITE) t = SUPER DEBUGGER TEXT SCREEN AREA (color_matrix: R/W TO reu SPACE) r = READ ONLY d = READ/WRITE DIRECTLY z = ZERO PAGE RAM WHICH MONITOR USES (MUST READ/WRITE TO SAVED COPY OF AREA) NA = NOT APPLICABLE (FOR EXAMPLE, io CANNOT SHOW UP AT $0400) sTEP 1: CHECK FOR OVERRIDING io LOCATIONS ----------------------------------------- pSEUDO-CODE: c64mODE: $0000DIRECT, READ ONLY $0001<--> APPmEMmAP(MEMORY MAP INFO) c128: $0000DIRECT, READ ONLY $0001<- b2 AND b1 -> APPcpu_b21(VIDEO CONTROL INFO) <- OTHER BITS -> APPmEMmAP(NON ESSENTIAL INFO) $ff00<--> APPcONFIG(MEMORY MAP INFO) $ff01-$ff04SPECIAL CASE: IS READING pcra-pcrd OR IS SENDING ONE OF THOSE FOUR TO cONFIG sTEP 2: CHECK FOR io SPACE ACCESSES ----------------------------------- io address table c64 mODE.......c128 mODE.............. mEMORY RANGEUSAGE / geos EQUATEioio ----------------------------------------------------------------------- $0000 - $d010RAM / IO: vic REGSd/dd/d/d $d011 *IO: vic GRCTRL1APPvic1APPvic1 $d012 - $d014IO: vic REGSd/dd/d/d $d015 *IO: vic MOBENBLEAPPvic2APPvic2 $d016 *IO: vic GRCTRL2APPvic3APPvic3 $d017IO: vic REGd/dd/d/d $d018 *IO: vic GRMEMPTRAPPvic4APPvic4 $d019 - $d020IO: vic REGSd/dd/d/d $d021 *IO: vic BAKCLR0APPvic5APPvic5 $d022 - $d02fIO: vic REGSd/dd/d/d $d030 *IO: c128 2mhz CTRLd/dAPPcLK $d031 - $d4ffRAM / IO / ROMd/dd/d/d $d500 *IO: c128 mmu CONTROLd/dAPPcONFG $d501 - $d504IO: c128 mmu REGSd/dd/d/d $d505 *IO: c128 mmu mcrd/dr/r/r $d506 *IO: c128 mmu "rcr"d/dAPPrcr*1 $d507 - $d50a *IO: c128 mmu zp RELOCd/dr/r/r $d50b - $d7ffRAM / IO / ROMd/dd/d/d $d800 - $dbff *IO: TEXT COLORS "CTAB"r/r*2* $dc00 - $dcffRAM / IO / ROMd/dd/d/d $dd00 *IO: CIA2BASE (vic MMAP) APPcia2_b10 *3* APPcia2_b10 $dd01 - $deffRAM / IO / ROMd/dd/d/d $df00 - $df09 *IO: reu dma CONTROLr/rr/r/r $df0a - $efffRAM / IO / ROMd/dd/d/d $f001 - $ffffRAM / ROMd/dd/d/d ----------------------------------------------------------------------- cONCLUSIONS: nO DIFFERENCES BETWEEN THREE DEBUGGERS- JUST BETWEEN TWO MACHINES. oNLY THREE POSSIBLITIES: DIRECT, READ-ONLY, OR ONE OF SEVERAL SPECIAL CASE ROUTINES. fOR EACH AREA, NEED BYTE IN TABLE WHICH CONTAINS TWO THREE-BIT CODES, DENOTING WHAT TO DO ON THAT MACHINE. tABLE SIZE: 25 LINES * (1 WORD + 1 BYTE) = 75 BYTES pLUS vic HANDLER ROUTINE (USES ADDRESS TO SEE WHICH vic REGISTERS WE WANT, AND THEN READS/WRITES TO MONITOR SHADOW FOR THAT REGISTER. pLUS HANDLER ROUTINES FOR APPcLK, APPcONFIG, APPrcr, AND APPcia2_b10. note 1: IN 128 MODE, $d506 IS SPLIT UP BETWEEN APPrcr_b76 (vic BANK INFO) AND APPrcr_b50 (MEMORY MAP INFO). note 2: THE TEXT SCREEN COLOR TABLE IS LOCATED AT $d800-$dbff. iN c64 MODE, WE ONLY ALLOW READS FROM THIS AREA, SO THE USER WON'T SCREW UP THE MONITOR'S TEXT COLORS. iN c128 MODE, THERE ARE ACTUALLY TWO COLOR TABLES AT THIS LOCATION. bIT 1 OF $0001 DETERMINES WHICH IS VISIBLE TO THE 6510. iF THIS BIT IS CLEAR, WE ALLOW DIRECT READ/WRITES. iF THIS BIT IS SET, WE ONLY ALLOW READS. note 3: BITS 1-0 OF LOCATION $dd00 CONTROL WHICH 16k MEMORY BANK THE vic CHIP USES, AND SO ARE SAVED IN APPcia_b10. tHE OTHER BITS (7-2) ARE WRITTEN TO/ READ FROM MEMORY. cAUTION ERIC: IN c64 MODE, MAKE SURE io IS IN WHEN DOING THIS. pSEUDO-cODE: IF THE ADDRESS IS BETWEEN $d000 AND $dfff: c64:CHECK LOCATION $0001. iF (b1=1 OR b0=1), THEN i/o SPACE IN. iF b2=0, THEN 4k char rom IS VISIBLE: ONLY ALLOW READS. iF b2=1, THEN 4k OF i/o DEVICES ARE VISIBLE: CALL TABLE LOOKUP ROUTINE, USING io address table. USE b5-b3 OF RETURN BYTE TO DECIDE WHAT TO DO. ELSE CAN READ/WRITE DIRECTLY c128:CHECK LOCATION $ff00: iF (b0=0), THEN i/o SPACE IS IN. CALL TABLE LOOKUP ROUTINE, USING io address table. USE b2-b0 OF RETURN BYTE TO DECIDE WHAT TO DO. ELSE CAN READ/WRITE DIRECTLY ELSE (ADDRESS IS NOT IN io RANGE) GO TO STEP 3 sTEP 3: CHECK FOR rom ACCESS ---------------------------- c64 mODE rOM tRUTH tABLE LOCATION $0001 mEMORY RANGEwHAT mIGHT bE tHERE76543210nOTES --------------------------------------------------------------------------- $0000 - $9fffRAM-------- $a000 - $bfffRAM / bASIC ROM-------1b0=1 $c000 - $dfffRAM*1*-------- $e000 - $ffffRAM / kERNAL ROM------1-b1=1 nOTE THAT THERE ARE CASES WHERE CARTRIDGES PLUGGED INTO THE c64 CAN OVERRIDE THESE AREAS. tHE c64 pROG. rEF. gUIDE IS NOT VERY CLEAR ON THIS, SO i WILL NOT BE CONCERNED ABOUT CARTRIDGES FOR NOW. eds 2/8/88. nOTE 1: THE CASE WHERE char rom IS MAPPED IN FROM $d000 TO $dfff HAS ALREADY BEEN HANDLED BY io TABLE. c128 mODE rOM tRUTH tABLE LOCATION $ff00 mEMORY RANGEwHAT mIGHT bE tHERE76543210nOTES --------------------------------------------------------------------------- $0000 - $3fffRAM-------- $4000 - $7fffRAM / bASIC ROM LOW------0-b1=0 $8000 - $bfffRAM / bASIC ROM HIGH----AB--b3=0 OR b2=0 $c000 - $ffffRAM / kERNAL ROM--AB----b5=0 OR b4=0 i DON'T COMPLETELY UNDERSTAND c128 EXTERNAL ROMS YET. i AM GOING TO ASSUME THAT b5-b1 IN $ff00 DETERMINE IF THERE IS ANY rom IN. i DON'T CARE IF IS kERNAL, EXTERNAL, INTERNAL, OR CARTRIDGE ROM. i JUST WON'T WRITE TO THOSE RANGES IF THE BITS ARE CLEAR. pSEUDO-CODE: aS IT TURNS OUT, THE FASTEST AND TIGHTEST CODE TO HANDLE THIS SIMPLY CHECKS ADDRESS RANGES AND BITS DIRECTLY. sEE THE CODE. sTEP 4: ram ACCESS ------------------ c64 mODEc128 mODE...... mEMORY RANGEUSAGE / geos EQUATEramram b1ram b0 --------------------------------------------------------- $0000 - $0001aLREADY HANDLED BY STEP 1. $0002 - $00dd *ZERO PAGE (MON SWAPS)z/zNAz/z/z $00de - $00ffZERO PAGEd/dNAd/d/d $0100 - sp *STACK (MONITOR USES)x/xNAx/x/x sp+1 - $01ffSTACK (USER'S DATA)d/dNAd/d/d *1* $0200 - $0313RAM d/dd/d/dd/d/d $0314 - $0319 *BASirqvEC, brk, nmir/rd/d/dr/r/r $031a - $0333RAMd/dd/d/dd/d/d $0334 - $03fb *MONITOR CODEx/xx/x/xx/x/x $03fc - $03ffMONITOR jsr AREAd/dd/d/dd/d/d $0400 - $1fff *RAMd/sd/s/dd/d/d $2000 - $3bff *RAM d/sd/s/dd/d/b $3c00 - $5fff *RAM m/sm/s/dd/d/b $6000 - $78ff *RAMd/sd/s/dd/d/b $7900 - $8bff *RAMd/dd/d/dd/d/b $8c00 - $8fe7 *RAM (MONITOR TEXT SCR)r/tr/t/dd/d/b $8fe8 - $9fff *RAMd/dd/d/dd/d/b $a000 - $fff9RAM / ROM IF >$d000d/dd/d/dd/d/d $fffa - $ffff *nmi_vector, reset, irqr/rr/r/rr/r/r ----------------------------------------------------------------------- cONCLUSIONS: mINI DEBUGGER AND sUPER DEBUGGERS ARE COMPLETELY DIFFERENT CASES. uSE CONDITIONAL ASSEMBLY TO DECIDE WHICH TABLE TO USE. mINI DEBUGGER HAS FOUR POSSIBILITIES: DIRECT, READ-ONLY, ILLEGAL, AND ZERO PAGE. fOR EACH AREA, NEED BYTE IN TABLE WHICH CONTAINS TWO THREE-BIT CODES, DENOTING WHAT TO DO ON THAT MACHINE. tABLE SIZE: 15 LINES * (1 WORD + 1 BYTE) = 45 BYTES aLL TABLE VALUES ARE STANDARD CASES. tHE SUPER DEBUGGER'S TABLE IS SIMILAR: FOR EACH AREA, THERE ARE SIX POSSIBILITIES, ALL STANDARD. tHE TABLE NEEDS TO GIVE US A WORD VALUE WHICH CONTAINS FIVE THREE-BIT CODES: MACHINEMONITORACCESS TYPEBITS IN WORD --------------------------------------------------------- 128 MODEBACKRAM SUPERBANK 0 ACCESSb14-b12 128 MODEBACKRAM SUPERBANK 1 ACCESSb11-b9 128 MODEreu SUPERBANK 0 ACCESSb8-b6 128 MODEreu SUPERBANK 0 ACCESSb2-b0 64 MODEreu SUPERb5-b3 --------------------------------------------------------- tABLE SIZE: 18 LINES * (1 WORD + 2 BYTES) = 76 BYTES aLL TABLE VALUES ARE STANDARD CASES. note 1: THE REGION sp+1 TO $313 CAN BE COMBINED, BECAUSE THE EFFECTIVE BANK CALCULATION WILL NOT GIVE AN ADDRESS <$200 IN BANK 1. pSEUDO-CODE: FIRST CALCULATE EFFECTIVE BANK (ONLY NECESSARY ON c-128) IF ADDRESS IS LESS THAN $200, IS bANK 0. IF APPcONFIG b6 = 1 THEN(note: IGNORE b7) (BANK 1 IS ENABLED, BUT WE MUST CHECK RAM SHARING) IF ADDRESS HIGH BYTE >= $80 IF APPrcr b3 = 1 USE LOOKUP TABLE FOR APPrcr b1-b0: 00$fc 01$f0 10$e0 11$c0 IF ADDRESS HIGH BYTE < THIS VALUE, IS BANK 1 ELSE IS BANK 0 ELSE IS BANK 1 ELSE (ADDRESS HIGH BYTE < $80) IF APPrcr b2 = 1 USE LOOKUP TABLE FOR APPrcr b1-b0: 00$04 01$10 10$20 11$40 IF ADDRESS HIGH BYTE >= THIS VALUE, IS BANK 1 ELSE IS BANK 0 ELSE IS BANK 1 ELSE IS BANK 0 these bit numbers have changed tHEN USE TABLE TO DETERMINE WHAT TO DO WITH THAT ADDRESS, CONSIDERING THE MACHINE, MONITOR TYPE, AND BANK DESIRED. IF USING MINI DEBUGGER CALL TABLE LOOKUP ROUTINE, USING mini ram address table IF IN c64 MODE: USE b5-b3 OF RETURN BYTE TO DECIDE WHAT TO DO. ELSE (c128 MODE): USE b2-b0 OF RETURN BYTE TO DECIDE WHAT TO DO. IF USING SUPER DEBUGGER: CALL TABLE LOOKUP ROUTINE, USING mini ram address table IF IN c64 MODE: USE b5-b3 OF RETURN BYTE TO DECIDE WHAT TO DO. ELSE (c128 MODE): IF SUPER DEBUGGER IF ACCESSING BANK 1 USE b2-b0 OF RETURN WORD IF ACCESSING BANK 0 USE b8-b6 OF RETURN WORD IF BACKRAM SUPER DEBUGGER IF ACCESSING BANK 1 USE b11-b9 OF RETURN WORD IF ACCESSING BANK 0 USE b14-b12 OF RETURN WORD tHIS DECISION TREE SEEMS FAIRLY COMPLICATED, BUT IT BREAKS DOWN PRETTY WELL IN THE CODE. gENERAL mEMORY pROTECT mAP -------------------------- c64 mODE.......c128 mODE.............. mEMORY RANGEUSAGE / geos EQUATEramioram b1ram b0io ----------------------------------------------------------------------- $0000 *cpu_ddr 6510 ddrALL CASES: r/rALL CASES: r/r $0001 *cpu_data 6510 DATA PORT<-> APPmEMmAP<-> APPcpu_b21+APPmEMmAP $0002 - $00dd *ZERO PAGE (MON SWAPS)z/zNANAz/z/zNA $00de - $00ffZERO PAGEd/dNANAd/d/dNA $0100 - sp *STACK (MONITOR USES)x/xNANAx/x/xNA sp+1 - $01ffSTACK (USER'S DATA)d/dNANAd/d/dNA $0200 - $0313RAMd/dNAd/d/dd/d/dNA $0314 - $0319 *BASirqvEC, brk, nmir/rNAd/d/dr/r/rNA $031a - $0333RAMd/dNAd/d/dd/d/dNA $0334 - $03fb *MONITOR CODEx/xNAx/x/xx/x/xNA $03fc - $03ffMONITOR jsr AREAd/dNAd/d/dd/d/dNA $0400 - $1fff *RAMd/sNAd/s/dd/d/dNA $2000 - $3bff *RAM d/sNAd/s/dd/d/bNA $3c00 - $3fff *RAM m/sNAm/s/dd/d/bNA $4000 - $5fff *RAM (bg SCREEN)m/sNAm/s/dd/d/bNA $6000 - $78ff *RAMd/sNAd/s/dd/d/bNA $7900 - $8bff *RAMd/dNAd/d/dd/d/bNA $8c00 - $8fe7 *color_matrix / RAMd/dNAd/d/dd/d/bNA $8fe8 - $8fff *RAMd/dNAd/d/dd/d/bNA $9000 - $9fff *RAMd/dNAd/d/dd/d/bNA $a000 - $bfffRAM (fg SCREEN)d/dNAd/d/dd/d/dNA $c000 - $cfffRAMd/dNAd/d/dd/d/dNA $d000 - $d010IO: vic REGSd/dd/dd/d/dd/d/dd/d/d $d011 *IO: vic GRCTRL1d/dAPPvic1d/d/dd/d/dAPPvic1 $d012 - $d014IO: vic REGSd/dd/dd/d/dd/d/dd/d/d $d015 *IO: vic MOBENBLEd/dAPPvic2d/d/dd/d/dAPPvic2 $d016 *IO: vic GRCTRL2d/dAPPvic3d/d/dd/d/dAPPvic3 $d017IO: vic REGd/dd/dd/d/dd/d/dd/d/d $d018 *IO: vic GRMEMPTRd/dAPPvic4d/d/dd/d/dAPPvic4 $d019 - $d020IO: vic REGSd/dd/dd/d/dd/d/dd/d/d $d021 *IO: vic BAKCLR0d/dAPPvic5d/d/dd/d/dAPPvic5 $d022 - $d02fIO: vic REGSd/dd/dd/d/dd/d/dd/d/d $d030 *IO: c128 2mhz CTRLd/dd/dd/d/dd/d/dAPPcLK $d031 - $d4ffRAM / IO / ROMd/dd/dd/d/dd/d/dd/d/d $d500 *IO: c128 mmu CONTROLd/dd/dd/d/dd/d/dAPPcONFG $d501 - $d504IO: c128 mmu REGSd/dd/dd/d/dd/d/dd/d/d $d505 *IO: c128 mmu mcrd/dd/dd/d/dd/d/dr/r/r $d506 *IO: c128 mmu "rcr"d/dd/dd/d/dd/d/dAPPrcr*1 $d507 - $d50a *IO: c128 mmu zp RELOCd/dd/dd/d/dd/d/dr/r/r $d50b - $d7ffRAM / IO / ROMd/dd/dd/d/dd/d/dd/d/d $d800 - $dbff *IO: TEXT COLORS "CTAB"d/dr/rd/d/dd/d/d*2* $dc00 - $dcffRAM / IO / ROMd/dd/dd/d/dd/d/dd/d/d $dd00 *IO: CIA2BASE (vic MMAP)d/d APPcia2_b10d/d/dd/d/d*3* $dd01 - $deffRAM / IO / ROMd/dd/dd/d/dd/d/dd/d/d $df00 - $df09 *IO: reu dma CONTROLd/dr/rd/d/dd/d/dr/r/r $df0a - $dfffRAM / IO / ROMd/dd/dd/d/dd/d/dd/d/d $e000 - $efffRAM / ROMd/dNAd/d/dd/d/dNA $f000 *c128: CONFIG REGISTERd/dNAALL CASES: <-> APPcONFIG $f001 - $fff9RAM / ROMd/dNAd/d/dd/d/dNA $fffa - $ffff *nmi_vector, reset, irqr/rNAr/r/rr/r/rNA ----------------------------------------------------------------------- aSSUMPTIONS: rom DECODED SEPARATELY ADDRESS DECODE FOR RAM BANK SHARING ALREADY WORKED OUT CAN SIMPLIFY TABLE A BIT WITH .IF mini note 1: IN 128 MODE, $d506 IS SPLIT UP BETWEEN APPrcr_b76 (vic BANK INFO) AND APPrcr_b50 (MEMORY MAP INFO). note 2: THE TEXT SCREEN COLOR TABLE IS LOCATED AT $d800-$dbff. iN c64 MODE, WE ONLY ALLOW READS FROM THIS AREA, SO THE USER WON'T SCREW UP THE MONITOR'S TEXT COLORS. iN c128 MODE, THERE ARE ACTUALLY TWO COLOR TABLES AT THIS LOCATION. bIT 1 OF $0001 DETERMINES WHICH IS VISIBLE TO THE 6510. iF THIS BIT IS CLEAR, WE ALLOW DIRECT READ/WRITES. iF THIS BIT IS SET, WE ONLY ALLOW READS. note 3: BITS 1-0 OF LOCATION $dd00 CONTROL WHICH 16k MEMORY BANK THE vic CHIP USES, AND SO ARE SAVED IN APPcia_b10. tHE OTHER BITS (7-2) ARE WRITTEN TO/ READ FROM MEMORY. cAUTION ERIC: IN c64 MODE, MAKE SURE io IS IN WHEN DOING THIS. wARN IN MANUAL THAT WE DO NOT ALLOW BLEED-THROUGH. tHEY WILL HAVE TO SWAP RAM IN MANUALLY TO CHANGE IT. tHIS MEANS WE CAN'T USE A SINGLE move COMMAND TO COPY ROM TO RAM... gEOdEBUGGER HAS LIMITED SUPPORT FOR THE CREATION AND DEBUGGING OF cbm APPLICATIONS. tHE c128 DESKtOP HAS SOME BUGS RELATED TO LOADING cbm APPLICATIONS. gEOpROGRAMMER CURRENTLY SUPPORTS THE ASSEMBLY AND LINK OF: geos APPLICATIONS(seq OR vlir, WITH HEADER) geos DESK ACCESSORIES(seq BY DEFINITION, WITH HEADER) cbm APPLICATIONSSTANDARD cOMMODORE prg FILE (geos FILE TYPE = not_geos, DOES NOT HAVE A HEADER BLOCK). dESKtOP HAS RESTRICTIONS ON WHICH LOAD ADDRESSES IT CAN HANDLE. cOMMODORE basic'S load AND boot COMMANDS CAN LOAD MOST ADDRESSES OK. gEOdEBUGGER CAN LOAD MOST ADDRESSES OK. tHERE IS SOME AMOUNT OF SUPPORT IN THE DEBUGGER FOR LOADING AND DEBUGGING cbm APPLICATIONS. - CAN TOGGLE BETWEEN ANY KIND OF SCREEN THE vic AND vdc CHIPS SUPPORT - APP CAN TRASH ALL OF geos ADDRESS SPACE pROBLEMS: - ON c128, DEBUGGER CAN ONLY LOAD A cbm APP TO BANK 1, WHEREAS basic EXPECTS SUCH AN APPLICATION TO RUN IN BANK 0. eITHER WRITE YOUR APPLICATION TO RUN IN EITHER BANK (SEE sAMPLEcbm), OR USE A CONSTANT SO YOU CAN ASSEMBLE IT TO RUN IN EITHER BANK. - tHE DEBUGGER DOES NOT DO ANY ERROR CHECKING ON THE LOAD ADDRESS OF A cbm APPLICATION. iT WILL CRASH IF YOU TRY TO LOAD AN APP BELOW $400. aPPLICATION CANNOT LOAD ABOVE THE $8000 AREA. - gEOdEBUGGER FILLS THE TEXT COLOR TABLE ONCE. iF THE cbm APPLICATION FILLS THE TEXT COLOR TABLE (TABLE #1 ON THE 128), THE DEBUGGER'S CHARACTERS WILL BE COLORED. iF THE cbm APP FILLS WITH $0b, THE DEBUGGER CHARACTERS WILL BE INVISIBLE, SINCE THE DEBUGGER SETS THE BACKGROUND TO $0b. - IF THE cbm APP PUTS UP A SCREEN WHICH RESIDES IN THE $0400-$7fff AREA, THEN YOU WILL NOT BE ABLE TO VIEW IT FROM THE SUPER DEBUGGER USING f7 OR f8. tHIS IS BECAUSE THESE COMMANDS DO NOT SWAP THE DEBUGGER CODE OUT OF THIS AREA: THE vic CHIP WILL BE GIVEN THE CORRECT PARAMETERS, BUT IT WILL BE DISPLAYING DEBUGGER CODE INSTEAD OF THE APPLICATION'S SCREEN DATA. wITH A LITTLE BIT OF WORK, YOU CAN GET GEOaSSEMBLER AND GEOlINKER TO GENERATE: aSSEMBLY-iN-bASIC PROGRAM a (prg-not_geos) APPLICATION WHICH LOOKS LIKE A basic PROGRAM, BUT REALLY ONLY HAS SEVERAL LINES OF basic. rEMAINDER IS ASSEMBLY CODE. seq DATAFILE: AS IF WAS CREATED BY basic. cREATE A geos seq FILE, THEN CHANGE THE cOMMODORE AND geos FILE TYPE BYTES. geos APPLICATION DATAFILE: AS IF WAS CREATED BY A geos APPLICATION. cREATE A geos seq FILE, THEN CHANGE THE geos FILE TYPE BYTE. iN A SIMILAR MANNER, YOU CAN USE gEOdEBUGGER TO EXAMINE A WIDE VARIETY OF DIFFERENT FILE TYPES. bUT FIRST, YOU MUST CHANGE THE cOMMODORE AND/OR geos FILE TYPE BYTE, AND THE LOAD ADDRESS IN THE HEADER BLOCK. fUTURE gEOpROGRAMMER IDEAS: gENERATE cbm aPPLICATION WITH HEADER: eSSENTIALLY A cbm ASSEMBLY-LANGUAGE PROGRAM, BUT WITH A geos HEADER. wOULD SAVE THE iCON eDITOR STEP CURRENTLY REQUIRED. sPECIFICATION OF "HIDE DEBUG SCREEN MODE" f7 IS PRESSED: toggle screen: SHOW user SCREEN WAIT FOR PRESS SHOW debug SCREEN IF mini: PLACE CURSOR ON LEFT PRINT PROMPT PRINT INPUT LINE AS IT WAS LOOP FOR NEXT CHARACTER f8 IS PRESSED: IF HIDDEN = false enable show mode: CALL tOGGLEsCREEN TO SWITCH USER PARAMETERS TO HARDWARE SET HIDEdEBUGsCREEN = true LOOP FOR NEXT CHARACTER IF HIDDEN = true disable show mode: SET HIDEdEBUGsCREEN = false CALL tOGGLEsCREEN TO SWITCH USER PARAMETERS TO SHADOWS, AND DISPLAY DEBUGGER SCREEN IF IN LEFT-SIDE COMMAND MODE (MUST REPRINT LINE BECAUSE NOTHING HAS BEEN PRINTED) PLACE CURSOR ON LEFT PRINT PROMPT PRINT INPUT LINE AS IT WAS IF NOT IN LEFT-SIDE COMMAND MODE CANCEL OPEN MODE / DEPOSIT MODE PRINT PROMPT LOOP FOR NEXT CHARACTER hOW gEOdEBUGGER hANDLES irq iNTERRUPTS -------------------------------------- iF YOU ARE WRITING A NORMAL geos APPLICATION, THEN YOU DO NOT HAVE TO READ THE FOLLOWING INFORMATION. yOU CAN SKIP AHEAD TO THE SECTION TITLED "sTRAY iNTERRUPT "trap" fACILITY". iF YOU ARE WRITING A NON-geos APPLICATION WHICH SETS UP ITS OWN INTERRUPT SERVICE ROUTINE, THIS INFORMATION IS VITAL; YOUR PROGRAM WILL NOT RUN CORRECTLY UNDER gEOdEBUGGER UNLESS YOU FOLLOW THESE INSTRUCTIONS. nOTE: isr STANDS FOR iNTERRUPT sERVICE rOUTINE. wHEN gEOdEBUGGER IS RUNNING A USER APPLICATION, IT INSERTS A SMALL WEDGE ROUTINE IN PLACE OF THE NORMAL isr (WHICH IN MOST CASES WILL BE THE geos isr). tHIS WEDGE FIRST CHECKS IF THE irq INTERRUPT WAS GENERATED BY THE irq LINE OR A brk INSTRUCTION. iF IT WAS A brk INSTRUCTION, THE WEDGE EXECUTES THE APPROPRIATE MONITOR. iF THE INTERRUPT WAS AN irq, THE WEDGE CALLS THE EXISTING isr. tHUS: THE DEBUGGER IS ABLE TO MONITOR THE irq/brk EVENTS, WITHOUT INTERFERING WITH REGULAR INTERRUPT SERVICING THAT IS VITAL TO MOST APPLICATIONS. tO INSERT THIS WEDGE ROUTINE INTO THE INTERRUPT SEQUENCE, gEOdEBUGGER MUST FIRST EXAMINE THE irq VECTOR AT LOCATION $fffe, TO SEE WHERE THE CURRENT isr IS LOCATED. iT THEN MUST MODIFY THIS VECTOR SO IT WILL POINT TO THE gEOdEBUGGER WEDGE ROUTINE WHICH IS LOCATED IN THE $0334 AREA. iF YOU ARE WRITING A NON-geos APPLICATION WHICH SETS UP ITS OWN isr, THEN YOU WILL PROBABLY WE SETTING THE irq VECTOR AT SOME POINT DURING YOUR INITIALIZATION CODE. iN ORDER FOR YOUR APPLICATION TO RUN UNDER gEOdEBUGGER, YOU MUST SET THIS VECTOR CAREFULLY; BECAUSE IF YOUR APPLICATION IS RUNNING UNDER gEOdEBUGGER, YOU NEED TO STORE THE ADDRESS OF YOUR isr TO A VECTOR IN THE gEOdEBUGGER WEDGE CODE, not TO THE irq VECTOR. bELOW IS A ROUTINE WHICH YOU CAN INSERT INTO YOUR PROGRAM TO SET UP THE APPROPRIATE VECTOR TO YOUR isr. nOTE THAT THIS ROUTINE ASSUMES THAT YOUR APPLICATION WILL ONLY ALLOW INTERRUPTS WHEN THE MEMORY MAP IS CONFIGURED AS A STANDARD geos MEMORY MAP. oN THE c64, THIS MEANS ALL ram, AND ON THE c128, THIS MEANS ALL BANK 1 ram, NO rom. iF YOUR APPLICATION IS GOING TO ALLOW INTERRUPTS IN OTHER MEMORY MAP CONFIGURATIONS, USE THE "iNTERRUPT hANDLING rEFERENCE nOTES" SECTION OF THIS DOCUMENT TO CUSTOMIZE THIS INSTALLATION ROUTINE. iNSERT THE FOLLOWING CONSTANTS AND SUBROUTINE INTO THE INITIALIZATION PHASE OF YOUR APPLICATION, FOR IT TO RUN PROPERLY UNDER gEOdEBUGGER. iN THE CONSTANT DEFINITION PORTION OF YOUR PROGRAM: development= true;sET TO true IF YOU SOMETIMES RUN THIS ;APPLICATION UNDER gEOdEBUGGER v2.0, ;AND RUN IT UNDER THE DESKtOP OTHER TIMES. ;sET TO false IF YOU WILL NEVER RUN THIS ;APPLICATION UNDER gEOdEBUGGER v2.0. tOiNTsVC= $0367;aDDRESS OF gEOdEBUGGER VECTOR WE MODIFY iN THE INITIALIZATION PORTION OF YOUR PROGRAM: ;************************************************************************* ;iNITiNTsVC ; ;tHIS ROUTINE MODIFIES THE irq VECTOR, SO THAT THE USER'S INTERRUPT ;SERVICE ROUTINE IS CALLED INSTEAD OF THE geos INTERRUPT SERVICE ROUTINE. ;tHIS ROUTINE CAN ASSEMBLE ONE OF TWO WAYS, DEPENDING UPON THE ;VALUE OF THE CONSTANT CALLED "development". ; ;aSSUMPTIONS: ;1) tHAT THE STANDARD geos MEMORY MAP IS PRESENT WHEN THIS ROUTINE RUNS. ;2) tHAT YOUR APPLICATION DOES NOT DO ANYTHING WEIRD SUCH AS ALLOWING ;INTERRUPTS WHEN HIGH-MEMORY rom OR ram BANK 0 (ON THE c128) IS ;SWAPPED IN. ; ;sIDE-EFFECTS: ;1) iF THE FOLLOWING SCENARIO APPLIES: ;- YOU ARE WRITING A NON-geos APPLICATION FOR THE c64 ;- WHICH TRIES TO DISABLE INTERRUPTS WHEN rom IS IN ;- YOU RUN IT UNDER gEOdEBUGGER ;- YOUR PROGRAM SWAPS kERNAL rom IN, WITHOUT PROPERLY ;DISABLING INTERRUPTS ;- AN INTERRUPT OCCURS ;...THEN gEOdEBUGGER will PROPERLY RUN YOUR isr, WITHOUT GIVING ;YOU ANY WARNING THAT THERE IS A BUG IN YOUR PROGRAM, AND THAT IT ;WOULD HAVE CRASHED IF IT WAS NOT RUN UNDER gEOdEBUGGER. ; ;aUTHOR:eRIC e. dEL sESTOaPRIL 1988 ;cALLED BY:INITIALIZATION CODE ;pASS:NOTHING ;rETURNS:NOTHING ;aLTERS:ACCUMULATOR AND FLAGS ; ;************************************************************************ iNITiNTsVC: SEI;DISABLE INTERRUPTS .IFdevelopment;------------------------------------------------ ;aSSEMBLE THE FOLLOWING CODE WHEN YOU WANT YOUR APPLICATION TO RUN CORRECTLY ;UNDER gEOdEBUGGER v2.0. LDAirq_vector+1;CHECK HIGH BYTE OF EXISTING irq VECTOR ;TO SEE IF WE ARE RUNNING UNDER DEBUG. BMI50$;SKIP IF NOT... ;WE ARE RUNNING UNDER gEOdEBUGGER: MUST STORE OUR irq VECTOR TO ;THE gEOdEBUGGER CODE IN THE $0334 AREA. iF RUNNING IN c128 MODE, ;THIS ONLY MODIFIES THE WEDGE CODE IN BANK 1, WHICH IS SUFFICIENT. lOADwtOiNTsVC,#mYiNTsVC CLI;ENABLE INTERRUPTS RTS;ALL DONE 50$:;WE ARE NOT RUNNING UNDER gEOdEBUGGER: SET UP NEW irq VECTOR ;IN NORMAL FASHION. .ENDIF;(development)--------------------------------------------------- ;aT THIS POINT, WE KNOW THAT EITHER THE APPLICATION IS NOT RUNNING UNDER ;gEOdEBUGGER, OR THAT WE DON'T EXPECT IT TO RUN UNDER gEOdEBUGGER (THE CASE ;WHERE development = false). iNTERRUPTS HAVE ALREADY BEEN DISABLED ABOVE. ;sET UP THE irq VECTOR AT $fffe TO POINT TO NEW SERVICE ROUTINE. nOTE THAT ;IN c128 MODE, THIS ONLY AFFECTS THE irq VECTOR IN BANK 1 ram. lOADwirq_vector,#mYiNTsVC CLI;ENABLE INTERRUPTS RTS;ALL DONE sTRAY iNTERRUPT "trap" fACILITY ------------------------------- yOU WOULD EXPECT THAT AN APPLICATION WHICH OFTEN HAS TO SWAP IN THE kERNAL rom WOULD BE CAREFUL TO DISABLE INTERRUPTS DURING THESE OPERATIONS. tHIS IS TO PREVENT THE CASE WHERE AN irq OCCURS AND geos INTERRUPT CODE HAS BEEN SWAPPED OUT OF THE MEMORY MAP. oFTEN, IT IS EASY FOR SUCH A PROVISION TO BE LEFT OUT IN THE INITIAL IMPLEMENTATION OF A PROGRAM. tO CATCH THESE HARD-TO-FIND BUGS, gEOdEBUGGER HAS A "STRAY irq TRAP" FACILITY. tHIS FACILITY SERVES TO WARN YOU WHEN AN INTERRUPT HAPPENS AND THE MEMORY MAP IS CONFIGURED IN A MANNER YOU DID NOT EXPECT. iF YOU ARE RUNNING A geos APPLICATION (WITH NORMAL geos INTERRUPTS), THEN THIS FACILITY WILL STOP PROGRAM EXECUTION AND DISPLAY THE "*** eXECUTION STOPPED ***" MESSAGE WHEN AN irq OCCURS AND THE kERNAL rom IS SWAPPED IN. yOU CAN EXAMINE THE pc REGISTER TO SEE WHICH OF YOUR ROUTINES WAS EXECUTING WHEN THE irq OCCURRED, AND CAN ADD INTERRUPT-DISABLING CODE WHERE NECESSARY. iF YOU ARE WRITING A NON-geos APPLICATION WHICH RUNS ON THE c128, AND SETS UP ITS OWN INTERRUPT SERVICE ROUTINE, YOU WILL PROBABLY DESIGN IT SO INTERRUPTS ARE ENABLED ONLY WHEN THE MEMORY IF CONFIGURED IN A SPECIFIC WAY. hERE ARE SEVERAL EXAMPLES OF ASSERTIONS YOU MIGHT FIND IN SUCH AN APPLICATION: - "i WILL ONLY ALLOW INTERRUPTS WHEN BANK 1 ram IS MAPPED IN." - "i WILL ONLY ALLOW INTERRUPTS WHEN BANK 0 ram OR rom IS MAPPED IN." bY REFERING TO THE "iNTERRUPT hANDLING rEFERENCE nOTES" SECTION OF THIS DOCUMENT, AND ADDING SOME CODE TO THE INITIALIZATION PORTION OF YOUR PROGRAM, YOU CAN ALTER THE WEDGE CODE SO THAT A trap IS PRODUCED IF AN INTERRUPT OCCURS WHEN THE MEMORY MAP IS IN AN UNEXPECTED CONFIGURATION. (iS IT POSSIBLE TO CONTINUE PROGRAM EXECUTION AT THIS POINT???) iNTERRUPT hANDLING rEFERENCE nOTES iF YOU ARE WRITING A NON-geos APPLICATION, THE FOLLOWING TABLES PROVIDE USEFUL REFERENCE INFORMATION ABOUT THE VECTORS IN gEOdEBUGGER'S WEDGE CODE. bY ADDING CODE TO YOUR APPLICATION WHICH CHANGES THESE VECTORS, YOU CAN GET YOUR INTERRUPT SERVICE ROUTINE TO WORK WHEN YOUR APPLICATION IS RUNNING UNDER gEOdEBUGGER. yOU CAN ALSO SET THESE VECTORS SO THAT A trap OCCURS IF AN INTERRUPT HAPPENS WHEN THE MEMORY MAP IS SUCH THAT YOUR APPLICATION WOULD CRASH. c64 mODE -------- lABELaDDRnORMAL cONTENTSmODIFIED cONTENTS ----------------------------------------------------------------------------- rOMirq_vEC:$0338JMP tRAProm4c 45 03JMP hANDLEirq4c 5e 03 - AS IT STANDS, THIS LOCATION WILL CAUSE A trap WHENEVER AN irq HAPPENS AND THE kERNAL rom IS MAPPED INTO HIGH MEMORY. mODIFY THIS LOCATION IF YOU WANT EXECUTION TO CONTINUE TO THE tOiNTsVC VECTOR WHEN rom IS MAPPED INTO HIGH MEMORY. tHE tOiNTsVC VECTOR CAN THEN DIRECT EXECUTION TO YOUR isr. tOiNTsVC:$xxxxJMP gEOSisr4c XX XXJMP yOUR_isr4c ll hh -OR- JMP tRAPirq4c xx xx - AS IT STANDS, THIS LOCATION DIRECTS EXECUTION TO THE geos isr WHEN AN INTERRUPT OCCURS. yOU CAN MODIFY THIS VECTOR TO POINT TO YOUR OWN isr, OR FORCE A trap WHEN AN irq OCCURS. nOTE THAT IF rOMirq_vEC POINTS TO hANDLEirq, THEN THE tOiNTsVC VECTOR HANDLES ALL irq INTERRUPTS, REGARDLESS OF WHETHER ram OR rom IS IN. c128 mODE --------- lABELaDDRnORMAL cONTENTSmODIFIED cONTENTS ----------------------------------------------------------------------------- (IN BANK 0) rOMirq_vEC:b0$xxxxJMP tRAProm4c xx xxJMP hANDLEirq4c xx xx - AS IT STANDS, THIS LOCATION WILL CAUSE A trap WHENEVER AN irq HAPPENS AND THE kERNAL rom IS MAPPED INTO HIGH MEMORY. mODIFY THIS LOCATION IN BANK 0 ram IF YOU WANT EXECUTION TO CONTINUE TO THE tOiNTsVC VECTOR WHEN rom IS MAPPED INTO HIGH MEMORY. tHE tOiNTsVC VECTOR CAN THEN DIRECT EXECUTION TO YOUR isr. (IN BANK 0) tOiNTsVC:b0$xxxxJMP gEOSisr4c XX XXJMP yOUR_isr4c ll hh -OR- JMP tRAPirq4c xx xx - AS IT STANDS, THIS LOCATION DIRECTS EXECUTION TO THE geos isr WHEN AN INTERRUPT OCCURS and BANK 0 IS VISIBLE IN THE $0300 AREA. yOU CAN MODIFY THIS VECTOR TO POINT TO YOUR OWN isr, OR FORCE A trap WHEN SUCH AN irq OCCURS. nOTE THAT IF rOMirq_vEC POINTS TO hANDLEirq, THEN THIS BANK 0 tOiNTsVC VECTOR WILL ADDITIONALLY HANDLE irq INTERRUPTS WHICH OCCUR WHEN rom IS MAPPED INTO HIGH MEMORY. (IN BANK 1) tOiNTsVC:b1$xxxxJMP gEOSisr4c XX XXJMP yOUR_isr4c ll hh -OR- JMP tRAPirq4c xx xx - AS IT STANDS, THIS LOCATION DIRECTS EXECUTION TO THE geos isr WHEN AN INTERRUPT OCCURS and BANK 1 IS VISIBLE IN THE $0300 AREA. yOU CAN MODIFY THIS VECTOR TO POINT TO YOUR OWN isr, OR FORCE A trap WHEN SUCH AN irq OCCURS. nmi (rESTORE KEY) iNTERRUPTS wHEN gEOdEBUGGER IS EXECUTING USER CODE, WE SET UP THE nmi VECTORS SO THAT THE restore KEY CAN STOP EXECUTION AT ANY POINT AND BRING US INTO THE MONITOR. nOTE THAT THIS INVOLVES THREE nmi VECTORS: b1$fffa, b0$fffa, AND b0$318 FOR nmiS WHICH OCCUR WHEN rom IS MAPPED INTO THE $FFFA AREA. wHEN THE MONITOR IS RUNNING, WE SET UP THE CURRENT BANK'S $fffa nmi VECTOR SO THAT THE USER CAN HIT THE restore KEY TO QUIT ANY OPERATION. tHIS IS IMPLEMENTED AS "SET-FLAG AND POLL-FLAG-AND-STOP WHEN YOU CAN" SO THAT CRUCIAL OPERATIONS (SUCH AS INSERTING A SYMBOL) ARE NOT INTERRUPTED. tO SIMPLIFY MATTERS, WE DISABLE nmi INTERRUPTS DURING CONTEXT SWITCHING (STARTING OR STOPPING AN APPLICATION). tHIS IS ACCOMPLISHED BY MODIFYING THE WEDGE CODE SLIGHTLY SO THAT IF AN nmi OCCURS WHEN WE DON'T WANT IT TO, THE WEDGE CODE IMMEDIATELY RETURNS. iN BOTH c64 AND c128 MODES, THERE IS ONLY ONE LOCATION IN THE WEDGE CODE WHICH MUST BE MODIFIED. (tHIS IS TRUE ON THE 128 BECAUSE NO MATTER WHICH ENTRY POINT IS USED TO GET INTO THE WEDGE CODE: rAMnmi_b0, rAMnmi_b1, OR rOMnmi_b0, EXECUTION ENDS UP AT THE POINT LABELED sKIPtOrETURN IN THE WEDGE CODE IN BANK 1. tHEREFORE WE ONLY NEED TO ALTER THE WEDGE CODE AT THAT POINT, AND NOT IN BOTH BANKS.) nOTES: 1) v1.0 gEOdEBUGGER USED TO DISABLE nmi INTERRUPTS DURING CALLS TO geos INTERRUPT CODE. tHE MOTIVATION FOR THIS IS THE IDEA THAT WHEN THE USER HITS THE restore KEY, HE DOES NOT WANT TO STOP EXECUTION IN THE MIDDLE OF geos INTERRUPT CODE. v2.0 gEOdEBUGGER DOES NOT DO THIS ANYMORE BECAUSE WE DO NOT WANT TO LOCK-OUT THE restore KEY WHILE THE USER'S INTERRUPT SERVICE ROUTINE IS RUNNING. aND BESIDES, WHAT IS THE STOPMAIN COMMAND FOR ANYWAY? 2) CONCERNING nmi BOUNCE: - WHEN THE restore KEY IS PRESSED, TWO nmi SIGNALS AREA GENERATED, ABOUT 150USEC APART. 3) cONCERNING PREVENTING nmiS WHICH IMMEDIATELY FOLLOW A brk INSTRUCTION: - WE HANDLE THIS CORRECTLY 4) oN BOTH THE 64 AND 128, THE cia2 CHIP HAS THE CAPABILITY OF GENERATING AN nmi SIGNAL. tO PREVENT THIS FROM OCCURING DURING DISK-ACCESS ROUTINES, THE geos iNITfORio ROUTINE FORCES THE cia2 TO GENERATE ONE INTERRUPT BY SETTING THE TIMER VALUE TO A LOW NUMBER LIKE 1. iNITfORio KNOWS THAT IT WILL GET CONTROL WHEN THIS FORCED-nmi OCCURS BECAUSE IT SWAPS THE KERNAL rom INTO THE HIGH- MEMORY AREA AND SETS THE KERNAL'S PAGE 3 nmi VECTOR (NMIVEC, $0318) TO POINT TO A DUMMY nmi ROUTINE. - ON THE c64, THIS WORKS FINE, EXCEPT FOR THE FACT THAT gEOdEBUGGER'S VECTOR AT $0318 GETS TRASHED BY iNITfORio. - ON THE c128, iNITfORio DOES NOT SWAP rom IN CORRECTLY (IT IS CHANGING LOCATION $0001). sO WHEN IT FORCES THIS nmi TO OCCUR, THE 6510 USES THE VECTOR AT b1$fffa OR b0$fffa, AND WE END UP IN THE DEBUGGER. tO SOLVE THIS PARTICULAR PROBLEM, i HAVE ADDED CODE TO v2.0 TO POLL THE cia2 CHIP AFTER AN nmi OCCURS TO SEE IF IT WAS THE restore KEY OR THE cia2 CHIP. iF IT WAS THE cia2 CHIP, gEOdEBUGGER QUICKLY RETURNS TO THE APPLICATION. hANDLING nmiS FROM THE cia CHIP IN THIS MANNER IS A GOOD IDEA IN GENERAL, ON BOTH THE c64 AND THE c128. iT ALLOWS THE USER TO WRITE PROGRAMS WHICH USE THE cia2'S nmi CAPABILITY WITHOUT WORRYING ABOUT THE DEBUGGER GETTING CONFUSED. bUT NOTE THAT THE USER'S APPLICATION WILL NOT RUN AS EXPECTED: ANYTIME THE cia2 GENERATES AN nmi, THE DEBUGGER WILL GET CONTROL, POLL THE cia2 TO SEE THAT IT IS RESPONSIBLE, AND WILL RETURN TO THE APPLICATION. tHE APPLICATION WILL HAVE NO WAY OF KNOWING THAT AN nmi OCCURRED, SINCE NOT ONLY DID WE STEAL THE nmi INTERRUPT, WE ALSO CLEARED THE cia2 INTERRUPT STATUS REGISTER JUST BY POLLING IT. tHAT'S LIFE IN THE BIG CITY! ;************************************************************************* ;dOrBOOT ; ;tHIS COMMAND DOES WHAT THE "rboot" ICE MACRO DOES: IT PULLS THE ENTIRE ;geos KERNAL IN FROM reu BANK #0. ; ;tALKED TO dOUG 6/6/88: ;iF THE CURRENT DRIVE IS A ram disk WHEN THIS COMMAND IS INVOKED, ;THE DESKtOP WILL COME UP OK. tHE DRIVE WHICH IS SELECTED WILL DEPEND ;UPON A COPY OF CURdRIVE WHICH IS STORED IN THE reu. (yOU CAN CHANGE ;THIS COPY USING sELECTpRINTER FROM THE DESKtOP.) ; ;iF THE CURRENT DRIVE IS NOT A ram disk WHEN THIS COMMAND IS INVOKED, ;THEN THE DESKtOP WILL NOT COME BACK UNTIL THE PHYSICAL DRIVE IS ;TURNED OFF AND BACK ON AGAIN. ; ;tHE ONLY WAY TO IMPROVE THIS WOULD BE FOR THE DEBUGGER TO CALL ;eXITtURBO TO LET GO OF THE PHYSICAL DRIVE. bUT SINCE WE ARE NOT ;SURE THE eXITtURBO CODE IS STILL IN MEMORY, THAT IS A BAD IDEA. ;wE CAN'T CLOSE THE eXITtURBO CODE, BECAUSE IT IS DIFFERENT FOR ;EVERY DIFFERENT DISK TYPE. ; wE MAINTAIN TWO SEPARATE MEMORY POINTERS: pc (ACTUAL PROGRAM COUNTER), AND lc (ADDRESS FOR OPEN COMMANDS). eACH POINTER INCLUDES ADDRESS AND MEMORY ENVIRONMENT INFORMATION. nEW COMMANDS: superminiUSAGE ----------------------------------------------------------------------------- INITVIEW--COPY pc ADDR AND BANK INFO TO lc SETVIEWSVSET lc'S BANK INFO VIEWVWDISPLAY CURRENT pc AND lc ADDRESS AND BANK INFO USEVIEWUVCHANGE pc'S BANK INFO TO WHAT IS IN lc B1B1SAME AS VIEW ($7e,$00) B0B0SAME AS VIEW ($3e,$00) ----------------------------------------------------------------------------- SETVIEW, VIEW, AND USEVIEW ARE PRIMITIVES POSSIBLE USAGES: VIEWING OTHER BANKS AND PROCEEDING FROM OLD pc AND BANK: ADDRESSBANK INFO --------------- ------------------- A ADDRESSlc = ADDRESS SETVIEW XX,XXlcB = NEW BANK INFO A ADDRESS, ETC...lc = ANYTHINGlcB = ANYTHING GOUSES pc ADDRESS AND BANK INFO SETTING A NEW pc AND BANK: ADDRESSBANK INFO --------------- ------------------- VIEW XX,XXlcB = NEW BANK INFO PC ADDRESSpc = NEW ADDRpcB = lcB - OR - PC ADDRESSpc = NEW ADDR VIEW XX,XXlcB = NEW BANK INFO USEVIEWpcB = lcB CHANGING pc'S BANK INFO WITHOUT CHANGING pc ADDRESS ADDRESSBANK INFO --------------- ------------------- VIEW XX,XXlcB = NEW BANK INFO USEVIEWpcB = lcB CHANGING pc ADDRESS WITHOUT CHANGING BANK INFO: ADDRESSBANK INFO --------------- ------------------- PClc = pclcB = pc (ONLY REQUIRED IF HAVE CHANGED lc SINCE restore KEY) PC NEW ADDRESSpc = NEWpcB = lc pOSSIBILITY FOR FUTURE view COMMAND: WHEN INVOKED WITHOUT ARGUMENTS, DIPLAYS: - split into pc and lc columns - aDDRESS rANGE rAM bANK vISIBLE oVERRIDE ------------- ---------------- -------- $fc00 - $ffff1rom $f800 - $fbff1rom $f000 - $f7ff1rom $e000 - $efff1rom $d000 - $dfff1i/o $c000 - $cfff1 $b000 - $bfff1 $a000 - $afff1 $9000 - $9fff1 $8000 - $8fff1 $7000 - $7fff1 $6000 - $6fff1 $5000 - $5fff1 $4000 - $4fff1 $3000 - $3fff1 $2000 - $2fff1 $1000 - $1fff1 $0800 - $0fff1 $0400 - $07ff0 $0000 - $03ff0 USE PRINT HEX WORD ROUTINE, ADDING $0FFF TO GET RIGHT SIDE START INCREMENT AT $0400, OFFSET AT $03ff ONCE GET TO $1000, INC = $1000, OFFSET = $0fff hOW gEOdEBUGGER MANAGES MACHINE-DEPENDENT MEMORY-MAP ENVIRONMENT INFORMATION tHE DEBUGGER CARRIES MEMORY-MAP ENVIRONMENT INFORMATION, WHICH IS MACHINE- DEPENDENT, AROUND IN GENERIC VARIABLES SUCH AS APPbANKiNFO1 AND APPbANKiNFO2. tHIS WAY, THE ROUTINES WHICH JUST MOVE THIS INFORMATION AROUND (BUT DON'T DIRECTLY USE IT) ARE MACHINE-INDEPENDENT. eXECUTION eNVIRONMENT: wHEN THE DEBUGGER STOPS EXECUTION OF AN APPLICATION (restore PRESSED OR sbp HIT), THE USER'S "EXECUTION ENVIRONMENT" IS SAVED. tHIS INCLUDES: PROCESSOR REGISTER AND FLAG VALUES pc ADDRESS CURRENT BANK INFORMATION ZERO PAGE VARIABLES STACK INFORMATION wE CALL THE pc ADDRESS AND ITS MEMORY-MAP INFORMATION THE "eXECUTION eNVIRONMENT" OR MORE SIMPLY, THE "pc POINTER". vIEWING eNVIRONMENT: oNCE THE DEBUGGER HAS STOPPED AN APPLICATION, THE "VIEWING ENVIRONMENT" IS THE SAME AS THE "EXECUTION ENVIRONMENT". tHIS MEANS THAT ALL OF THE MEMORY EXAMINATION AND MODIFICATION COMMANDS USE THE SAME MEMORY-MAP INFORMATION AS THE eXECUTION eNVIRONMENT. tHROUGH USE OF THE setview COMMAND, THE VIEWING ENVIRONMENT CAN BE CHANGED. yOU CAN SET UP A NEW MEMORY-MAP CONFIGURATION, AND THEN USE THE MEMORY EXAMINATION AND MODIFICATION COMMANDS TO READ/WRITE MEMORY IN THIS NEW CONFIGURATION. wHEN YOU GIVE THE go COMMAND TO RESUME EXECUTION, THE DEBUGGER RESTORES THE EXECUTION ENVIROMENT, AND YOUR PROGRAM CONTINUES EXECUTION. wE CALL THE VIEWING ADDRESS AND ITS ENVIRONMENT THE "lc POINTER". ------------------------------------------------------------------------------- aSPECTS OF gEOdEBUGGER WHICH MUST CHANGE ACCORDING TO MACHINE-DEPENDENCIES IN v2.0, TO REMAIN COMPATIBLE WITH v1.0. (kILL THESE IN v3.0.) rEGISTER COMMAND: DISPLAYS pc ADDRESS, HIGHLIGHTS ADDRESS IF EFFECTIVE ADDRESS OF pc (CONSIDERING pc BANK INFO) IS BANK 0. DISPLAYS cpu_data VALUE (iT REALLY SHOULD NOT DO THIS ANYMORE, BUT i AM TRYING TO MAINTAIN COMPATABILITY WITH v1. 64:READ DIRECTLY FROM APPbANKiNFO1 128:[7-3,0]: DIRECT READ FROM MEMORY [21]: SHADOW WITH APPcpu_b21 rEGISTER oPEN cOMMAND: ..INCLUDES mm REGISTER: IS cpu_data. (tO BE COMPATIBLE WITH v1) 64:DIRECTLY READ/WRITE TO APPbANKiNFO1 128:[7-3,0]: DIRECTLY r/w TO MEMORY [21]: SHADOW WITH APPcpu_b21 ------------------------------------------------------------------------------- aSPECTS OF gEOdEBUGGER WHICH ARE MACHINE-INDEPENDENT. mEMORY EXAMINATION AND MODIFICATION: BANK COMMAND:AFFECTS lc'S BANK INFO: CURbANKiNFO1 AND CURbANKiNFO2 OPEN MODES:USES lc'S BANK INFO HIGHLIGHTS ADDRESS IF IS IN PHYSICAL BANK 0 DUMP COMMAND:USES lc'S BANK INFO HIGHLIGHTS ADDRESS IF IS IN PHYSICAL BANK 0 MOVE/FILL/DIFF/FIND:USES lc'S BANK INFO HIGHLIGHTS ADDRESS IF IS IN PHYSICAL BANK 0 @ AND @@ OPERATORS:USES lc'S BANK INFO sINGLE AND tOP-STEP BREAKPOINTS: MAINTAIN THEIR OWN BANK INFORMATION (COPIED FROM pc BANK INFO BEFORE EXECUTION BEGUN) sOFTWARE bREAKPOINTS: MAINTAIN THEIR OWN BANK INFORMATION (COPIED FROM pc BANK INFO BEFORE EXECUTION BEGUN) pc COMMAND: WITHOUT ARGUMENT:COPY pc ADDRESS AND BANK INFO TO lc (RESTORES EXECUTION ENVIRONMENT) WITH ARGUMENT: (SAME AS SETTING pc IN OPEN MODE) SET pc ADDRESS = ARGUMENT SET pc BANK INFO = lc BANK INFO wOULD BE NICE: v3.0: MAKE reu SUPER MONITOR HAVE OPTION TO USE 32k BACKRAM FOR SYMBOL TABLE... wOULD BE COOL IF DEBUGGER COULD CHECKSUM RAM EXPANSION TO SEE IF IS ALREADY UP THERE (SO COULD ASSEM, LINK, DEBUG, ASSEM, LINK, DEBUG REALLY QUICKLY WHEN GEOdEBUG IS ON DISK, AND NOT ON RAMDISK). wHY NOT WAIT TILL JUST AFTER INTERRUPT CODE RUNS TO DISABLE INTERRUPTS BEFORE GOING TO USER'S CODE? wOULD FLICKER A BIT LESS. wARN USER IF WHEN WE BREAK HIS sp IS SO LOW THAT MONITOR CODE WILL WRAP IT AROUND... iF nmi COULD REALIZE WHAT IT INTERRUPTED AND COULD MAKE REPAIRS SO A go WOULD NOT CRASH US. iF THE TOP-STEP COMMAND COULD RECOGNIZE CALLS TO MOST OF THE geos INLINE ROUTINES AND STOP AND WARN THE USER WHAT IS ABOUT TO HAPPEN. bEGIN AND eND STRUCTURES IN MACROS. iF AND FOR MACROS COULD SKIP TO NEXT "END". mIGHT EVEN ADD COUNTER SO COULD BE SEVERAL LEVELS DEEP. cLEAN UP ENTIRE S/T/P/GO CONDITIONED/LEAP-FROGGED STRUCTURE cLEAN UP ENTIRE OPEN MODE THING cLEAN UP MOVE/DIFF/FILL/FIND aDD INTELLIGENCE TO PARSE MACRO SO THAT IF ARGS ARE THERE BUT NOT EXPECTED, GENERATES ERROR. ALLOW MACRO DEFS WHICH ARE BIGGER THAN SIZE OF INPUT BUFFER? (ESPECIALLY WHEN LOADING FROM FILE.)