8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / PROGRAMMING.SFX / 00programming next >

Wrap

Text File | 1990-02-12 | 35.8 KB | 878 lines

rea 2 nor rea 4-5 nor ************ Topic 2 Wed Apr 20, 1994 CBM-PRESS [Butterfield] (Forwarded) Sub: 128 Bank Switching Details on how a programmer can make good use of the 128's memory bank switching capabilities. 9 message(s) total. ************ ------------ Category 5, Topic 2 Message 1 Wed Apr 20, 1994 CBM-PRESS [Butterfield] (Forwarded) The Basic BANK command is deceptive. On standard 128s, only FOUR bank numbers are of any value: BANK 15 (default), Bank 14 (for looking at the character gen ROM at $D000), Bank 1 and Bank 0. Note that the Basic command BANK does NOT set the bank; it just logs the number given and invokes a bank switch when a PEEK, POKE, or SYS is used. Also: a "bank" isn't exactly that; it's usually a mixture of RAM, ROM, and I/O. The average M/L programmer, writing code into RAM bank 0, might think that BANK 0:SYS ... would be all he/she needed. WRONG. Because BANK 0 makes the ROM disappear totally; all you have is RAM at all addresses. (The interrupts, by the way, take care of themselves pretty well). If the M/L program is sited below $4000, it would be much better to use BANK 15:SYS ..., since this give you a mixture of: RAM0 at $0000-$3FFF, ROM at $4000-$BFFF and (sorry, that's ROM at $4000-CFFF and at $E000-$FFFF, and the I/O chips at $D000-$DFFF. Great, but you can't usually site a program of any size below $4000, especially since Basic normally starts at $1C00 and may start much higher if the 128 is in graphics. So .. instead of relying on the four BANK values, you can make up new memory mixes by storing a selected value to address $FF00. The usual procedure is to command BANK 0:SYS ... and when your program starts running, thump a new value into $FF00 to get the Kernal ROM (and maybe I/O) back in. For Bank 0 ROM, the best value to use is $4E, which .. no, the best value is $0E, which configures you to: RAM0 at $0000 to $BFFF; ROM at $C000 to $CFFF and $E000 to $FFFF, and the I/O chips at $D000 to $DFFF. With the $0E value, your program can use 48K of RAM and still have the Kernal and I/O chips available. If the M/L program returns to Basic, be sure to restore the configuration to Bank0 before returning. Do this by putting $3F into $FF00. Next message deals with Bank 1. ------------ Category 5, Topic 2 Message 2 Wed Apr 20, 1994 CBM-PRESS [Butterfield] (Forwarded) Wanna put your program into bank 1, where there's less collision with Basic stuff? No problem. As usual, you will command BANK 1: SYS ... and then you have to get the ROM and I/O chips back into your configuration. This time, it's REALLY value $4E that goes into address $FF00. Gives you RAM1 from $0000 to $BFFF; the rest is as previously described. When you're done, go back to "bank 1" configuration by storing $7F into $FF00. Need to look at the character generation ROM for some reason? Just add 1 to the values given earlier. Thus, $0E becomes $0F and $4E becomes $4F. And don't forget to put things back as they were. I hope this gives further insight into the question we discussed in the conference area recently. --Jim Butterfield ------------ Category 5, Topic 2 Message 3 Wed Apr 20, 1994 GEOS-TIM (Forwarded) BTW It was a great conference. The transcripts will be uploaded in a couple days. Thanks again Jim. For those folks that didn'T know, Jim Butterfield will be on GEnie through this week. If you'd like to ask a question, do so on this message thread. :) -Tim ------------ Category 5, Topic 2 Message 4 Thu Apr 21, 1994 S.EYRSE [steve] (Forwarded) Jim: Thanks for starting this thread. The question I have is when the 125 is Bank switched is the area for code renumbered. By that I mean if I switch from bank 15 to bank 0 am I still working in a $0000 to $FFFF limit computer? Also if I did a program that started out in the normal bank 15 mode with the start at say $4200 and inside switched to Bank 0 to store material could it then start at the same $4200. But then there would need to be a chunk of code in Bank 0 that would switch it back to 15. So is Bank switching like having a internal REU ? Which would make it much faster as switching to a bank and having a "NEW" program or part should be very fast. My interest in this in a general way is that some have asked me to recode a 64 GEos program I did to work with the 128 and it would really helpto have some idea how the machine works. I have a 64. If the HEX numbers all stay the same that would explain how BSW could make 128 Geos work much faster and have things like printer drivers just standing by. The "internal" REU concept. They had VLIR with overlays down that next step would have been a snap, If that is the way the 128 works. Thanks: Steve. ------------ Category 5, Topic 2 Message 5 Fri Apr 22, 1994 CBM-ED [e.g.bell] (Forwarded) Steve: SE> when the 125 is Bank switched is the area for code renumbered No. SE> Also if I did a program that started out in the normal bank 15 SE> mode with the start at say $4200 and inside switched to Bank 0 SE> to store material could it then start at the same $4200 At a lower address what you are suggesting would work... lower than $4000. Higher than that is BASIC ROM in Bank 15, so when you called your code at that address you would actually hit something in ROM. If you started your code at $3f00 and switched to Bank 0 there, any address would be available to you in bank 0 (ram-0), but you would lose basic, the kernal, etc. The numbers (addresses) all stay the same when you switch configurations though. The only thing that changes is what the 128 can 'see' at those addresses. Try this from BASIC.... bank 15:print peek(16384) and then bank 0 :print peek(16384) As Jim already said, it is much handier to stash #$0e into the MMU, which gives you ram -0 up to $BFFF, and the screen editor stuff i/o block, and kernal above that. Unless you need BASIC routines in your code, it is an excellent configuration. I'm not really a chip person, but it helped to visualize things having worked on the 64 under BASIC... that was pretty much the same thing as in the 128 as far as what is happening, at least that is how I see it. Do you have a copy of Mapping the 128 by Otis Cowper. THAT is the book to get! ------------ Category 5, Topic 2 Message 6 Fri Apr 22, 1994 C128.JBEE (Forwarded) $FE is another good one for bank 1. ------------ Category 5, Topic 2 Message 7 Sat Apr 23, 1994 CBM-PRESS [Butterfield] (Forwarded) `$FE for bank 1? I must comment on this one. Bit 7 of the MMU is not active in the 128. Thus, storing $FE into $FF00 is the same as storing $7E. Now, what this gives you is: RAM1 throughout, except for D000-DFFF, which will have the I/O chips. No good for calling the Kernal, since there's no ROM there, but if you need to hit I/O directly, you could do that. The official "BANK 1" is $7F into $FF00; that gives you RAM1 everywhere, including $D000 to $DFFF. handier if your job is handling data. And, as I mentioned earlier, $4E will give you RAM1 from $0000 to $BFFF, ROM from $C000 to $FFFF exception for the I/O chips at $D000 etc. I should maybe note that with ALL confiruations, addresses $0002-$03FF are always RAM0. ------------ Category 5, Topic 2 Message 8 Sat Apr 23, 1994 CBM-PRESS [Butterfield] (Forwarded) In reply to a question: at any instand, the 128 can reach only 64K of memory. In M/L terms, this is addresses 0000 to FFFF. So you get to various "bits" of memory by calling up the bank configuration that you want. Now, when you go INTO a bank with SYS, to run a machine language program there, Basic logs its old bank configuration; that way, when your program says goodbye with RTS, Basic will have its ROM back in place and can continue going. So you have to think of Basic as a separate game from the M/L program, which acquires its bank status the instant it starts running. (If the Basic command BANK 0 *really* did the bank switch right then, Basic would crash, since the ROM which makes it run would have vanished!) "Bank 15" specifies RAM0 at all addresses below $4000, so if you could site your M/L program entirely below that address, you could leap into the code without worrying too much about the architecture: Kernal ROM would still be in place. But once your code if forced above $3FFF, Basic's only option is "Bank 0" .. and that starts up the M/L program with no ROM or I/O chips in place. That's why you have to fool around with the contents of $FF00. This is my last day on Genie. Good to see you all, and hope this stream helps a bit in the Banking Business. --Jim ------------ Category 5, Topic 2 Message 9 Sat Apr 23, 1994 C128.JBEE (Forwarded) What $FE is good for is BLOADing graphics into Bank 1 and then putting them onto the VDC screen real fast :) ------------ 5 | ************ Topic 4 Sun May 01, 1994 A.PLATT3 (Forwarded) Sub: Raster Register--HUH?? How do you use the raster? 3 message(s) total. ************ ------------ Category 5, Topic 4 Message 1 Sun May 01, 1994 A.PLATT3 (Forwarded) I'm getting into heavy game programming for the 64 and getting nowhere with the raster register. When I try to ise it, the computer resets, and eventually locks up. I manually reset the computer, and it works fine for awhile, then locks up again. I thought someone might help me with this description, so DOD DERNET, HELP ME! ------------ Category 5, Topic 4 Message 2 Wed May 04, 1994 CBM-ED [e.g.bell] (Forwarded) AP: AP> I'm getting into heavy game programming for the 64 and getting AP> nowhere with the raster register I know you probably think I forgot you, but I didn't... just up to my ears in other stuff. I dug up an old raster routine I used in the past. I don't remember all the whys of it cuz I haven't used it in over 5 years but I think you should be able to figure it out.... 105 ;-----<flip the raster code on> 110 ; 115 wedgeon sei 120 lda #<raster:sta $0314 125 lda #>raster:sta $0315 130 cli 135 lda #27:sta $d011 140 lda #1:sta $d01a:sta 56334 145 rts 150 ; 155 ;-----<interrupt> 160 ;-----<status line - screen top> 165 ; 170 raster lda $d012:cmp #58:bcc !01 175 ldx #1:stx $d019 180 dex:stx $d012:jsr $ffea:jmp $ea7b 185 ; 210 !01 ldx $d6:cpx #1:bcs !03; is cursor on line 1 or more 215 ldx #1:stx $d6:jsr $e56e; no - line 0 - set to line 1 220 ; 225 !03 ldy #39 230 !04 lda rasterline,y:sta 1024,y 235 lda rastercolr,y:sta 55296,y:dey:bpl !04 240 jmp $ea81 245 ; 250 ;-----<poke data> 255 ; 260 rasterline .byte "Your Data Here - Anything - 40 chars max" 265 rastercolr .byte 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 265 : .byte 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 270 ; Line 170 checks to see if the raster beam in on the correct line and line 175 unlatches the interrupt (if I remember this stuff correctly). Line 180 sets up for the next interrupt at the top of the screen, updates the system clock and handles the keyboard polling by calling the routine at the end of the IRQ.. (Yes, I know it is an undocumented entry... I was looking for the maximum speed possible in this routine and willing to shave EVERY clock cycle possible) Line 210 checks the current cursor row. If 0, it sets to line 1. If 1 or greater it skips that part. LInes 225-240 poke the status line data into the top screen line RAM. There are 2 separate 'exits' for a raster code since you are exiting it twice at different points. You don't want to perform all of the irq functions at every interrupt... just the last one on the screen. Remember code you want displayed on the screen must be screen code, no petscii or it won't display correctly. The exit in line 240 just exits the irq by cleaning the stack... no polling of the keyboard or clock updates take place at that point. O, and the $e56e in line 215 is more cursor positioning stuff. Let me know if you can make sense of this. I think it is pretty straightforward. There is no code included to turn off the wedge, but I think you can probably handle that, right? :) ------------ Category 5, Topic 4 Message 3 Sun May 29, 1994 A.PLATT3 [Chance] (Forwarded) Hey, thanks! I haven't taken this source and really broken it down, but I should be able to learn how to use the raster from your example. Thanks!!! And for those who are interested in gaming, any suggestions, including type of game, names, characters, or any game info. will be greatly considered! Mostly important to me, though, is the story line. Any story line that can incorporated sequels will be considered the most. Thank you! (Post under this response for suggestions!!) ------------ ************ Topic 5 Tue May 17, 1994 D.BOBER [RENTaLASER] (Forwarded) Sub: BASIC 64 Need help with this compiler... 20 message(s) total. ************ ------------ Category 5, Topic 5 Message 1 Tue May 17, 1994 D.BOBER [RENTaLASER] (Forwarded) I'm trying to compile a program with BASIC 64. My program occupies aprox. 102 Blocks. There is a 9 block font located at 51200 and a ML Routine loacated at 828. Now, I included the directive REM@ S=1024 to keep variable out of the cassette buffer. But for some reason the compiled program trashes the ML Routine. Everything located between 828-1024 is wiped out. As for the font, I'm not sure because the program crashes. But I used the "Advanced Development Features" and set the top of memory at 51100. The program uses a lot of DIM Arrays, but nothing too large because it all works with out a problem in BASIC. Any help would be appreciated, this is my first attempt at compiling a program, heck, it's my first useful program. Thanks, Douglas ------------ Category 5, Topic 5 Message 2 Wed May 18, 1994 CBM-ED [e.g.bell] (Forwarded) DB> 9 block font located at 51200 and a ML Routine loacated at 828. DB> Now, I included the directive REM@ S=1024 to keep variable out DB> of the cassette buffer. But for some reason the compiled DB> program trashes the ML Routine Why don't you try moving your ML routine to the top of memory, above the font. A 9 block font is only going to be about 2048 bytes. O, just checked... it won't fit there, but put it below the font/screen then, but still in page $c0. In other words, put the ML routine at 49152. Here is one thing you may need to consider though. I have never used BASIC 64, but I have used BASIC 128 pretty often, and it puts the compiled code high in memory. The limits you are setting may be keeping the program from getting enough memory. Remember also that there is a run-time package added to compiled BASIC programs that might increase the size of the final file. BASIC 128 offers the option of turning off the math processor or something like that. Does the 64 version? Anyway, try the shift of the ML. There is 1948 bytes left below 51100, and I know the cassette buffer is only like 192 bytes, so there is definitely room if that is the problem. And one last thing... BASIC 128 has a menu for the advanced development features. I use that in my progs for different memory specs rather than the inline directives. I don't know if it matters, I just prefer it. I then save them into an 'e' file that I load to configure things the same every time for that compile. Just a thought. :) ------------ Category 5, Topic 5 Message 3 Thu May 19, 1994 D.BOBER [RENTaLASER] (Forwarded) Well I changed the load address of the ML Routine to 49152 and tested the routine (I did not compile it) and the routine does not work there. I found this routine in a library book some time ago. Basically what it does is copy the screen into memory with SYS858. Then SYS828 recalls the screen. I use this for a simple "Window" routine. Trouble is, when I relocate it, it doesn't work. BASIC 64 does not give you the option of turning off the math processor. It does however have a menu for the advanced development features... A. Speedcode or Machine Language option B. Input a Symbol table C. Save Symbol table D. Generates an address list E. Change the end-of-memory address of compiled program F. Raise or lower the start address of compiled program G. Controls connection of the run time module H. BASIC extensions I. Imput no. of bytes per extended BASIC command J. Locates the ELSE command K. Turn off runtime error handling L. Suppress the overlay feature M. Send DOS commands to disk N. Directory I just don't understand why BASIC 64 is clearing my routine from the cassette buffer. If I load the routine in direct mode and PRINT PEEK(828) I get somthing like 152. (That is not the actual number, I'm just using it as an example) After loading and running the compiled program. It crashes then I enter PRINT PEEK(828) again and the result is 0. In fact all the address' from 828 to 1024 are reset to 0. :( ------------ Category 5, Topic 5 Message 4 Fri May 20, 1994 C128.JBEE (Forwarded) From the Basic 64 manual on page 20: "The compiler normally places all variables in the cassette buffer for easy access. You can use this range for your own purposes by supplying an address where you feel the buffer should end. For example: rem@ s=1024 " The compiler probably zeros out the cassette buffer before storing variables there. ------------ Category 5, Topic 5 Message 5 Fri May 20, 1994 CBM-ED [e.g.bell] (Forwarded) You observation leads me to ask a question. After you used the compiler directive to protect the cassette buffer, did you LOAD the ML routine from disk to use it? This may be a question that this thread already answers, of course. Also, you didn't say in your post whether this did the trick. Send me a copy of your ML routine and I'll fix it if I can to work at the higher address. It can only be 192 bytes or less, right? It has to be very small if it was written to work in the cassette buffer. It is probably using the cassette buffer for its variables, ad all it has to have done is to reassemble it for the higher address. Upload it to me. In the meantime, why not try this... I assume you changed the SYS calls to address 828 to point to 49152, right? Now, put a POKE 49152,96 at the start of your code, then compile again to see if it crashes. If not, this may really be all that is required. ------------ Category 5, Topic 5 Message 6 Fri May 20, 1994 CBM-ED [e.g.bell] (Forwarded) DB: A. Speedcode or Machine Language option Which are you using here. I would recommend the Speedcode because of the size of the program you are starting with. E. Change the end-of-memory address of compiled program F. Raise or lower the start address of compiled program What are these 2 for? I would take a look at the settings here also. Particularly 'F'. This is where I'd adjust my program parameters, from this menu, tho that is a personal preference. There is a lot to recommend the way you are doing things too, particularly not having to remember the settings for compiles later. K. Turn off runtime error handling Do you need this? You might try turning it off unless you need it. Just to try to cut down the size of the finished program. None of this is really meant to address the problem you are having. I can understand why what you tried does not work. You can't just change the load address of an ML program and have it work. That needs tweaked. I'm just curious here about the features available in BASIC 64. ------------ Category 5, Topic 5 Message 7 Fri May 20, 1994 D.BOBER [RENTaLASER] (Forwarded) The routine is binary code, not basic data statements. Can I upload it via E- Mail or do I have to upload it to the Libs? ------------ Category 5, Topic 5 Message 8 Fri May 20, 1994 D.BOBER [RENTaLASER] (Forwarded) EB> After you used the compiler directive to protect the cassette buffer, did you LOAD the ML routine... Yes, 20 if a=0 then a=1:load"bank ml",8,1:rem load window routine EB> I assume you changed the SYS calls to address 828 to point to 49152, right? I just changed all the SYS828 to SYS49152 and SYS858 to SYS49182, is that what you mean? SYS828 copies the screen. SYS858 recalls the screen. EB> Which are you using here. I would recommend the Speedcode because of the size of the program you are startig with. Yes, I'm using the speedcode option. I also used option 'E' Change the end-of- memory address of compiled program. This sets the end-of-memory for the compiled program. This will save space for routines, fonts, ect. I didn't raise or lower the start address of compiled program option 'F'. Option 'K' is OFF by default. I changed the ML Routine start address to 49152 and included the POKE 49152,96 in the beginning of the program. The compiled program crashed and the BASIC version crashes also. It looks like the SYS49152 causes the crash in BASIC, the screen resets to start-up blue and the loaded font resets to upper- case, graphics. Grumble, grumble... :/ ------------ Category 5, Topic 5 Message 9 Sat May 21, 1994 CBM-ED [e.g.bell] (Forwarded) DB: You can upload that file however you like. However, remember that uploading it to my mailbox will cost you, whereas uploading it to the library will not. Seems like an easy choice if I had to make it! :) If it is only a couple hundred bytes, which I assume because you have it in the cassette buffer, it won't take any time at all to disassemble and reassemble in a new address. ------------ Category 5, Topic 5 Message 10 Sat May 21, 1994 CBM-ED [e.g.bell] (Forwarded) DB: DB> changed all the SYS828 to SYS49152 and SYS858 to SYS49182, is DB> that what you mean Yes, that is what I meant. DB> option 'E' Change the end-of- memory address of compiled DB> program. This sets the end-of-memory for the compiled DB> program. This will save space for routines, fonts, ect. DB> I didn't raise or lower the start address of compiled program DB> option 'F' Did you lower the end-of-memory address from 51100 where you had it to 49151? As for raising the start-address, if the @1024 thing does that I guess it is probably not needed from the menu. DB> included the POKE 49152,96 in the beginning of the program. DB> The compiled program crashed and the BASIC version crashes DB> also. It looks like the SYS49152 causes the crash in BASIC This kind of suggests that it is really not the routine that is causing the problem because the 96 you poked into memory is just an RTS intruction, like a RETURN at the end of a BASIC subroutine. If you didn't already, set the top of program pointer to 49151 and try this experiment again. I know it is a PITA, but that is the kind of stuff you have to go through to get this stuff working. (When I say try it again, I'm talking about the POKE 49152,96) You might also try this. Try compiling a little BASIC program that pokes 49152 with 96, does the screen moves, etc. and that is all. Compile it and see if it works. Perhaps you are trying to do something that simply isn't going to work the way you want to do it. If you eliminate everything else but this code, it can give you some very helpful clues. ------------ Category 5, Topic 5 Message 11 Sat May 21, 1994 D.BOBER [RENTaLASER] (Forwarded) Ok, I compiled this little program... 5 rem compile test 6 poke49152,96 10 ifa=0thena=1:load"bank ml",8,1:REM ml routine at 828 20 ifb=0thenb=1:load"bank.font",8,1:REM font at 51200 30 poke56578,peek(56578)or3 40 poke56576,(peek(56576)and252) 50 poke53272,(peek(53272)and15) 60 poke648,192 70 poke53272,(peek53272)and240)or2 80 end Now, after loading and running it, the screens switch and my font is now active. But when I enter sys49152, the screen resets back and the font is no longer active. Also the cursor disappears. But the computer isn't really locked up, because if I hit F1 the ACTIVITY/ACCESS leds on the RamLink light up, denoting that the directory is being read, just can't list it on the screen. This occures to the BASIC and COMPILED version... When compiling, I set the end-of-memory address to 49151 and this time I omitted the REM@ S=1024 directive since I don't need the cassette buffer. Seems like all my trouble is around that ML Routine, perhaps it's time to make a big change to my program... Douglas ------------ Category 5, Topic 5 Message 12 Sat May 21, 1994 CBM-ED [e.g.bell] (Forwarded) DB: I cleaned up your message. When you post stuff like that ALWAYS use *sn to send it. not *s. That way it won't be reformatted. Here it is: 5 rem compile test 6 poke49152,96 10 ifa=0thena=1:load"bank ml",8,1:REM ml routine at 828 20 ifb=0thenb=1:load"bank.font",8,1:REM font at 51200 30 poke56578,peek(56578)or3 40 poke56576,(peek(56576)and252) 50 poke53272,(peek(53272)and15) 60 poke648,192 70 poke53272,(peek53272)and240) or 2 80 end DB> after loading and running it, the screens switch and my font is DB> now active. But when I enter sys49152, the screen resets back DB> and the font is no longer active Here is what you have learned from this. The ML routine works at 828 as it should. I gather this from the above... and assume that the switches are called with the routine in the cassette buffer, right. Now here is something else to try with what you have right now. The way you have the program set up, it just ENDs, meaning nothing should have changed from the way you had it while running. Do a PEEK at address 49152 after the thing stops to see what value is in there. See if it is still 96. Incidentally, I just noticed something that may be causing all of this as well... and this one is kind of my fault, tho with an explanation. Notice that you poked 648 with the value 192. Well, that is probably how I originally told you to do it. This actually explains everything. I was thinking that way because the problem with the cassette buffer had not cropped up at that time. This poke tells the screen editor that the screen is at 49152. In other words, anything PRINTed is POKEd to the 1024 byte block starting at 49152. Here is what is probably happening, in light of this. The first character at this address is a space, probably, which is the machine language instruction to JSR, similar to a GOSUB in BASIC. The next 2 bytes tell the computer where in memory this routine is. Since this is random, the address is going to be who knows where, which is why you are getting such odd, and inconsistent, results. Do this. Instead of using address 49152, try address 50176, which is after screen memory and before the font, meaning unused. Poke the 96 there, compile, then try the switches (in the cassette buffer.... leave the ML there). The reason you are probably getting the disappearing cursor, etc. is because of all the bank and pointer changes being done. DB> I set the end-of-memory address to 49151 and this time I DB> omitted the REM@ S=1024 directive since I don't need the DB> cassette buffer. There is something you must keep in mind when shifting ML code around in memory. SOMETIMES it will work, and this may be one of those cases. However, it is also possible that the code needs variables that are absolute... in other words, they are in the same block of memory as the program itself. When you move the code, it *may* work if it doesn't have to JMP or JSR to any internal addresses.... in other words, any routines of its own. However, if it uses internal variables, these references won't change. What this means is that the routine may work wherever it is loaded, but it will play havoc with any important data other routines/programs have in that area. Solution *if* this is what is happening, is to 1] leave the routine where it is and protect it with compiler directives, or 2] move the routine, but still protect the original block of memory, namely, in this case, the cassette buffer, or 3] re-do the routine to assemble at a new address. Try the change to 50176 instead of 49152. I think you are going to see some further changes. I really think you are getting some valuable information/clues as to what is going on from this little program. Try the address change and get back w/your results from that. You may have to make some changes to your program... maybe not. You're getting closer to the solution all the time though! :) ------------ Category 5, Topic 5 Message 13 Tue May 24, 1994 D.BOBER [RENTaLASER] (Forwarded) Oh, I forgot to mention soemthing. When I first started eveloping this program, SYS828 would copy the screen into memory and SYS858 would recall the screen. But when I started using my font, SYS885 would copy the screen and SYS828 recalls the screen. I don't know why, but it works. Now, I changed the POKE 49152,96 to POKE 50176,96 and changed the load address of the ml routine, and it worked only after removing the POKE 50176,96 It worked in BASIC and Compiled. But when I made the needed changes to my program and tried it. When my program calls SYS50206 to copy the screen to memory, it does. But when it calls SYS50176 to recall the screen, it breaks. Entering CONT continues the program, it also recalls the screen. But the compiled version doesn't work at all. It crashes like before. I used the REM@ s=1024 to keep the cassette buffer open. We're gettin closer, Just don't know what to do. ------------ Category 5, Topic 5 Message 14 Tue May 24, 1994 CBM-ED [e.g.bell] (Forwarded) DB: DB> program, SYS828 would copy the screen into memory and SYS858 DB> would recall the screen. But when I started using my font, DB> SYS885 would copy the screen and SYS828 recalls the screen. I DB> don't know why, but it works I can't explain that either. :( DB> It worked in BASIC and Compiled. But when I made the needed DB> changes to my program and tried it. When my program calls DB> SYS50206 to copy the screen to memory, it does. But when it DB> calls SYS50176 to recall the screen, it breaks That is not all tha surprising. It is more surprising that it works either time, actually. Like I told you before, what is probably needed is for that screen save routine to be rewritten to work in page $C0-$CF. It may also be that the save routine is saving data into this block of memory, meaning that it is overwriting the ML which could cause what you describe. The screen data takes 1024 bytes. The color, depending on how it is done, may take as little as 512 bytes... but this had to come from somewhere, and it may well be from this very bock of memory. This might complicate things too... finding enough memory to save the screen in. The 1K can come from the normal screen area, which your routine would not be doing, and 512 other bytes would have to be found somewhere... but I think the problem sounds for all intents and purposes to be solved. The routine must be reassembled to work... and I have to suspect from your description that it is overwriting itself... Upload it. :) ------------ Category 5, Topic 5 Message 15 Wed May 25, 1994 D.BOBER [RENTaLASER] (Forwarded) Ok, I'll upload it tonight. ------------ Category 5, Topic 5 Message 16 Thu May 26, 1994 CBM-ED [e.g.bell] (Forwarded) DB: I have good news for you, and some explanation as well. First, the reason the save/restore works in reverse when you have that hack I gave you installed is this. As I surmised, the routine you are using to save the screen data is indeed saving it to $c000. This is almost too perfect to ask for, because it takes data from the screen area at $0400 and saves it in $C0 block, and vice versa to restore it. Since my code puts the screen at $c0 block, the same code will work, but in reverse. In other words, you are taking from $C000 and putting to $0400 to save and vice versa to restore. This was a stroke of coincidence/luck. Second, the routine is only saving the text portion of the screen, not the color data, meaning that we don't need any more than just the normal screen area... not the extra 512-1024 bytes for color storage/recovery. Third, I think all you will have to do to get this routine to work is to make it load at 50176. Then sys 50176 should recall the screen and sys 50206 should save it. This takes all of the ML and font, etc. out of the live area for BASIC 64 and it shouldn't trip over itself. Of course, is this what you have already said does not work? Hmmmmm! I can't recall. But here is what the routine you sent me looks like disassembled: restore ldy #0 !01 lda $0400,y sta $c000,y lda $0500,y sta $c100,y lda $0600,y sta $c200,y lda $06e8,y sta $c2e8,y iny bne !01 rts ; save ldy #0 !01 lda $c000,y sta $0400,y lda $c100,y sta $0500,y lda $c200,y sta $0600,y lda $c2e8,y sta $06e8,y iny bne !01 rts ------------ Category 5, Topic 5 Message 17 Thu May 26, 1994 D.BOBER [RENTaLASER] (Forwarded) UPDATE! UPDATE! OK, I double checked my code, removed the REM@ S=1025 directive, and also removed the lines that loads the FONT and ML. (I made a BASIC loader for those.) Then compiled the program... It started to work! The first SYS50206 (save screen) worked but the SYS50176 (recall) caused a crash. (Blue screen, no cursor.) This also happens with the BASIC version, only somewhat slower. That makes sense, the speedcode would be faster! I stated earlyer that in BASIC, I could enter CONT to continue the program, that's not right, I can't. Something else I noticed when it crashes back to the blue screen, there is some text on the blue screen. However, they are in Upper-case/Graphics. Example, the top of the screen looks something like this... Account Options --------------------------------------------------------------------- But after the crash "Account" and "Options" are in uppercase/graphics. Seems like it jumped to the original screen (default). I think we're getting closer yet.... :) ------------ Category 5, Topic 5 Message 18 Thu May 26, 1994 D.BOBER [RENTaLASER] (Forwarded) Uh-oh! Ignore my last post! I'm Embarassed! I was pouring over my program this evening and I found it... ...It was there...A lonely little SYS828 right in the place that caused the crash I posted in my last post. I then Re-Compiled it and it now works flawlessly! Although, When the screen is copied into memory (SYS50206) about 6-8 characters appear at the lower- middle of the screen. EXAMPLE: k<k<rp<= Have no idea why, or what it is. SYS50176 removes it. Must be caused by the compiler. I'll experiment with it. Thanks alot for all you're help! I really appreciate it!!! I have a few other things I want to add and change. After testing this program I will upload it to GEnie. Should be about two weeks. Again, THANK YOU!! :) Douglas Bober ------------ Category 5, Topic 5 Message 19 Fri May 27, 1994 CBM-ED [e.g.bell] (Forwarded) Just give me an honorable mention in your acknowledgements. hehehe The spurious characters appear when you *save* the screen? It sounds like something spurious is getting into your $C000-$c7ff screen area. I'm glad you found the final problem though. This last thing you found is typical of the kinds of things programmers run into. :) ------------ Category 5, Topic 5 Message 20 Fri May 27, 1994 D.BOBER [RENTaLASER] (Forwarded) Thank you... I will definitly mention you in my acknowledgements! ------------ 5 |