8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / 00CAT5MSGS.SFX / 01cat5msgs < prev

Wrap

Text File | 1990-02-12 | 43.6 KB | 1,045 lines

************ Topic 3 Mon Oct 21, 1991 H.HERMAN1 (Forwarded) Sub: miscellany... I couldn't think of any other place where I could put this. 82 message(s) total. ************ ------------ Category 5, Topic 3 Message 41 Wed Aug 25, 1993 T.RUTTER2 [Troy Rutter] at 22:37 EDT Ed: Sounds great, except for one small detail. When Kermit made his source code available for SIDpic, he left the following in the file description: "This code requires the use of Craug Chamberlain Sidplayer M/L (version one) that was especially modified to work with my player. If you want to work on this and add more to my player, I cannot help you beyond providing this code abd pointing you to the M/L attached to SIDPIC V3.5 - I cannot distribute Craig's M/L as it might offend him. If you want it though, you CAN figure out from my Source Code where his M/L loads into, and take it out of SIDPIC V3.5." So, the actual ML that PLAYS the music is still in executable form only. I would still appreciate it, however, if you took a look at the source code. Especially routines such as: frommem convert and etc. PS.. the SIDfest is not until 1994. -Troy ------------ Category 5, Topic 3 Message 42 Wed Aug 25, 1993 C128.JBEE at 22:48 EDT Since I have the exclusive rights to the book, I do not mind the passing of the code back and forth if it means getting something accomplished that will increase the sales of the book. ------------ Category 5, Topic 3 Message 43 Thu Aug 26, 1993 CBM-ED [e.g.bell] at 10:00 EDT Does that mean, John, that you do have the source code for the SID player? ;) Troy: I looked at the source code you sent me today, and I can honestly say I can't understand why Kermit made such an extensive use of the .bas pseudo-op in PAL! It is confusing reading, but I did find something you should find interesting. The routines you want to convert and print the word strings seem to me to already exist in the code. The pertinent routine is FROMMEM in line 352. It first calls the routine called ROUTINE, which moves the variable pointers for I presume A1$ into the variables at $8c-$8e. These are used as pointers and general information into the string. Note the definition of A1$ in line 11. This seems to me to be defining the string in memory for use by the FROMMEM routine. It receives the string data when you call FROMMEM from the BASIC routine. Note particularly lines 161-175 (esp. lines 166-175). If you study this routine, you should be able to either use it or see how it is used. It seems to me to do exactly what you want done tho, and in ml to boot. The routine CONVERT at line 410 in your source file is a conversion routine. I did not study it closely, but based on what you say, I assume it converts A1$ data to the proper format. It makes this change to the string directly. Without running this, the code seems to me to: set the word address in lne 168, poking the low and high bytes into 113 and 114 ($71/$72 used in FROMMEM) I'm not sure what line 166 is doing, but I bet it is turning something off, probably an interrupt (I just checked... that is exactly what it is doing. See line 833) 167 is also assigning LA the value held in .x(low) and .y(high). Line 169 calls FROMMEM, which loads the next string into A1$, and then puts the length of that string into A. Line 170 puts the string into t$, necessary since you NEVER want to mess with A1$ or you would goof it up as far as length!!!! It assigns it the value of left$(a1$,a) which pares it down to its actual length. Line 171 apparently sets up the pointer for the next string an also stores that in WA. Line 172 sets up the FROMMEM routine again, and line 173 calls it, doing as described above. Line 174 converts a1$ for printing and stores it into w2$ and updates the address pointer. At this point, I don't know what the difference is between t$ and w$, but you could find that out by doing run-time displays (after reassembling the program with the appropriate instructions) to see what is in them with each iteration of the routine. Bottom line is that the routines you need are already written and available for your use. Give them a try and see if I'm not right. Now, do you have access to Kermit Woodall? I contacted him YEARS ago about using Wxmodem in BellTerm,tho I never did. I don't have his address even if I did have a presence of mind with him. Based on what John said about the book rights, it seems you have a basis for asking for Craig's player source code if you are willing and have that kind of access to him, and I would consider it a personal favor if you did! egb ------------ Category 5, Topic 3 Message 44 Sat Aug 28, 1993 T.RUTTER2 [Troy Rutter] at 13:46 EDT Ed, all, unfortunately, I have tried to use those subroutines in my programs and it locks up... i think it is bad memory management... here is what I have: Main basic program: 7169-10026 ML (frommem,routine,convert) 12288-12378 SID files load in at 15000 sid routine: 49152-53152 And it locks up after i use modlink to put them all in one file. Im wondering if modlink iteself uses some of that memory in there. Also, i wonder why the basic program loads at 7169... isnt it sposed to load at 2048 or something? BTW.. modlink = Modlink by Robert Stoerelle (MALAKAI) Any idears? ------------ Category 5, Topic 3 Message 45 Sat Aug 28, 1993 C.DRUTIS [Monsoon] at 23:15 EDT Greetings. This seems as good a place to ask as any... Could someone tell me if it's possible to run an ML subroutine within Bank 1? I want to put a text editor within Bank 1, but no matter what I do with the MMU register or the PCR's, the program refuses to work properly (or at all) within Bank 1. It works fine when I load it in Bank 0, though. For Bank 1, I begin with the following code: LDA #$4E ; corresponds to %01001110 which SHOULD be : Bank 1 RAM STA $D500 ; Kernal and IO . . . STA $FF00 Of course when I use it in Bank 0 I use LDA #$0E. Any help would be apprecitated. [Apptest 0000321.A] ------------ Category 5, Topic 3 Message 47 Sun Aug 29, 1993 C128.JBEE at 00:43 EDT It sounds like a Basic 7.0 shell (C-128) using the original SID ML (C-64). ------------ Category 5, Topic 3 Message 48 Sun Aug 29, 1993 R.KNOP1 [Rob Knop] at 00:43 EDT Troy- I don't think you want to link these various sections into one file. It looks like there are gaps between where the various sectios want to go. I don't know how this linker works, but if it just links the files together into one program, the resulting program will load sequentially in memory starting at the load address, not putting the various parts where they ought to go. If modlinker takes care of this, somebody please correct me.... Re: the starting address, the usual start for BASIC programs is indeed 2049. It sounds like the code was moved up for a relocated start-of-BASIC (e.g. to make room below the start of BASIC for a custom character set, a trick I used to use way back when). How do you want this program to function after it has been linked? -Rob ------------ Category 5, Topic 3 Message 49 Sun Aug 29, 1993 R.KNOP1 [Rob Knop] at 00:44 EDT Monsoon- I assume that you are issuing a "BANK 1" command before loading the ML program and SYS'ing to the address? If not, then there's the simple answer :D What are you calling in the way of BASIC and KERNAL subroutines? I am not sure, but I believe it possible that some of the Kernal subroutines may only return to bank 15, or at any rate a configuration with RAM 0 rather than RAM 1 visible. Hopefully, and probably, this is not the case, and the Kernal routines are friendly, but it is possible. It is more likely with some of the BASIC routines. It's been years since I've directlly called any BASIC or KERNAL routines from RAM 1, and the only reason I did that was because I was doing it from within GEOS, and in GEOS it is usually not necessary to directly call BASIC or the Kernal. Any idea just where the code is dying? What is the manner in which it dies? Ideally, ML things should work in RAM 1 just as they do in RAM 0. Curious, why are you locating the program in RAM 1 as opposed to RAM 0? -Rob ------------ Category 5, Topic 3 Message 50 Sun Aug 29, 1993 R.KNOP1 [Rob Knop] at 00:45 EDT Aha! JBEE posted that even as I was composing my reply, but yes, that load address is the standard start of BASIC for the 128, so it may be the BASIC program was intended to run on the 128. -Rob ------------ Category 5, Topic 3 Message 51 Sun Aug 29, 1993 C.DRUTIS [Monsoon] at 04:09 EDT Rob, Yes, I've issued a BANK1 command when I've tried to start if from Basic. I've also issued a G10400 (it resides at $400 in Bank 1) from the monitor. It doesn't crash... it simply stalls. In other words nothing happens. The computer doesn't lock up because it responds to a RS/Restore. This is why I'm puzzled. If it couldn't reach the kernal from Bank 1, it would (or should) break and drop to the monitor. I'm beginning to suspect that the kernal and the 128's editor wasn't designed to interact with Bank 1. I was kinda hoping someone had successfully written a program that uses them from Bank 1. Thanks anyway. :) Oh... I want to put it in Bank 1 because of memory constraints in Bank 0. I also don't want to rewrite the entire thing using INDFET and INDSTA and the like. Call it laziness. <g> [Apptest 00324.A] ------------ Category 5, Topic 3 Message 52 Mon Aug 30, 1993 R.KNOP1 [Rob Knop] at 01:08 EDT Monsoon- re: putting code in Bank 1 because of memory constraints, actually, this is a reasonable thing to do. Speed constraints would be another good reason; if you are writing (say) a text editor that keeps its text in BANK 1, it might be advantageous to write short "memory moving" routines in bank 1, which would save several cycles for each lda and sta as compared to INDSTA and INDFET. One other little obvious thing to check: how have you set the MMU register for common memory? If you haven't messed with it, $400 should be fine. Also, are you using this program at all with BASIC? If so, have you moved up the pointers for the bottom of variable memory? Re: 128's OS interacting with Bank 1, in my experience the monitor works beautifully with Bank 1, no problem there. Again, I am not sure about the Kernal. One thing that might be worth trying: setting break points. You can do this manually, by replacing instructions with BRK instructions. Put these varying distances into your code, and if, when you execute the code, the program breaks out to the monitor from one of these, you know that the code is at least getting that far. Another option would be to check out HEXPERT, which is a simple ML debugger that lets you set breakpoints and step through code. I am not sure that Hexpert will work with code in Bank 1, since (again) I haven't tried it, but it's probably worth looking at. -Rob ------------ Category 5, Topic 3 Message 53 Mon Aug 30, 1993 C.DRUTIS [Monsoon] at 04:09 EDT Rob, Yes, yes, no, yes. :) Did that. The monitor resides in RAM-0. I've used Hexpert. I've also set break points. The program actually WORKS in bank 1, but it doesn't seem to interact with some of the Kernal routines (GETIN and BSOUT for ex.). Yet, I HAVE found a kludgy work-around. What I did was move the program down to $1000 in Bank 1 (or, as you say, RAM-1 ), I then shifted Common Ram to 4k. I found a few spare bytes in that 4k and put in three subroutines that did the actual JSRs to the Kernal routines. Then I JSR to those routines from the program in place of the original Kernal calls. Seems to work. BTW, after much searching, I did find a couple of references to RAM 1 not working with the Kernal. On page 414 of the 128-PRG it says that you must be in RAM-0 (with I/O and high ROM). And on page 403 it states that you should invoke configurations 12, 13, 14 or 15; all of which use RAM-0. Thanks for your help. :) [Apptest 00334.A] ------------ Category 5, Topic 3 Message 54 Tue Aug 31, 1993 R.KNOP1 [Rob Knop] at 01:34 EDT One thing you can do is use JSRFAR (or eqivalent) to call the Kernal routines- all it takes is changing one byte in the RAM routine to return to another configuration other than bank 15. Myself, I don't really like JSRFAR (too much of a pain to use), so I brewed up something else that I call "JSROB" which is very much like what you describe doing with your "switchboard" routines in the 4K of common RAM- the main difference being that I put JSROB in zero page (obviously, this won't work if you want to use BASIC with the program). This requires less setup than JSRFAR, saves and restores the registers itself, and returns to the bank from whence it was called. IMHO such an entity is a better and safer way to call Kernal routines from Bank 1 than changing the return configuration of JSRFAR. If anybody is interested I could post the routine here (it's short). Re: terminology, I use RAM-0 and RAM-1 to refer to the RAM blocks in the 128, and Bank n to refer to the 128 standard memory configuration number n. Although bank 0 and bank 1 are (roughly) the same is RAM-0 and RAM-1, this way I avoid confusing myself when I start talking about bank 0 RAM being visible in bank 15 and such things. -Rob ------------ Category 5, Topic 3 Message 55 Thu Sep 02, 1993 T.RUTTER2 [Troy Rutter] at 21:18 EDT Indeed, Modlink thorws the files where they are supposed to be when it runs. As for moving basic up... I do use that trick... but later in the program. What it does is this: The main program loads, BLAMMO! Throws the SID ML at $c000, ML routines wherever they may go (since they aren't added yet) Then it moves basic up to 15000 so i dont have to mess with loading the SIDs in at different addresses using the sys commands all the time... really kinda handy. I chose 15000 for no particular reason. Scott Resh told me to place it at 16 something... but I like 15. :D Im verrrrry hesitant to post exactly what my program is doing... for 2 reasons: 1) My code is very messy. ;D 2) Somebody may see how simple(?!) my routine is and beat me to the punch) But if somebody would help me out getting the words display, they would be included in the program... but I have to know who it is... and then give me time to clean up my code, add comments, etc. (BTW.. id really appreciate this... Scott gives me hints but will not collaborate or help, he makes HIS run right but wont tell me how it works!) Actually, Scott is a lot of help, and I thank him every time I get for making me figure things out. But this needs to get done and I am nowhere nearer to figuring words out than i was 2 years ago. -Troy ------------ Category 5, Topic 3 Message 56 Sun Sep 05, 1993 CBM-ED [e.g.bell] at 01:26 EDT Troy: There seem to be answers to 2 questions being posted as tho they were just one... I have some observations on what has been said so far based n a very quick glance at what has already been said.... TR> Main basic program: 7169-10026 TR> ML (frommem,routine,convert) 12288-12378 TR> SID files load in at 15000 TR> sid routine: 49152-53152 Rob correctly fingered your problem here. Note the SID routine loads in C block... this is where the 64 version of the program loads. Remember the SID code is interrupt driven, and this will not correctly transport to the 128 for this reason. This code is under ROM, and that ROM must be present during interrupts... or more correctly, that RAM will be switched out of context immediately upon the start of the interrupt each time. BTW, whoever id'd the start address of BASIC 7.0 was correct, and at the same time identified the problem with what you are trying to do. wrt what Jeff said about Modlinker... JJ> Your program MUST have been saved from where it runs, not only JJ> for proper LOAD address, but for line links. Correct wrt load address, but unless this involves some requirement of the linker, BASIC programs are relinked every time they are loaded so the line links are irrelevant as long as they are within the correct range in terms of bytes. And this is petty anyway, because it doesn't take one thing away from the answer... except that it seems to be geared for 64 mode programs, which doesn't seem to be the case here. And I bet the C block SID address is why. ------------ Category 5, Topic 3 Message 57 Sun Sep 05, 1993 CBM-ED [e.g.bell] at 01:40 EDT Monsoon: Steve Punter published the technique he used in Word Writer in a Transactor from many years ago that requires about 20 bytes in common memory and about 30 or 40 in the $FF block of memory... it is some fancy footwork allowing kernal routines to be called from any bank and return to the caller bank... and he also published a cute little code to allow routines to be called from any bank in any bank and the return to the proper bank. His program did what you seem to want to do. The code is neat, and the memory used is negligible because it is, in high memory, in a normally unused section of code, and in common memory, very small. He had the same objections you do. ------------ Category 5, Topic 3 Message 58 Sun Sep 05, 1993 CBM-ED [e.g.bell] at 01:56 EDT Troy: I did say that I believe your problem is trying to run 64 mode ML on a 128, under ROM, and irq code at that, but I did want to say one other thing that would help if you can convince someone to share their source code for the SID player. TR> Then it moves basic up to 15000 so i dont have to mess with TR> loading the SIDs in at different addresses using the sys TR> commands all the time... really kinda handy. I chose 15000 TR> for no particular reason. Scott Resh told me to place it at TR> 16 something... but I like 15. :D Scott Resh is correct, you should use 16384, but for your convenience, not anything mystical. If you use the GRAPHIC commands, I believe GRAPHIC 1:GRAPHIC 5, your BASIC code will be moved to 16384 automatically with no pokes from you, and you will then have the 9k from 7169-16383 in which to put your irq code IFF you can get someone to assemble it to 1] work there, and 2] read the SID song data wherever it ends up. I still stand by my original answer wrt the routines I told you about. They will work, and probably work on the 128 (tho not with the GRAPHIC thing I just mentioned) unchanged if assembled and BLOADED. The reason they won't work as they are is due to the relocating being done. Remember, you are assembling them at the end, and connected to, the BASIC portion of the program. As I mentioned earlier, the line links won't be changed because the linker, tho it will relink the program, will stop at the 3 zeroes at the end of your code, but all JSR's and JMP's and references to internal routines will be hopelessly confused when you install the program at a different address, and in this case, you would have to check to see where PAL puts the start of code in a BASIC type pseudo-op assembly. Does it assume 2049 or do you explicitly put it somewhere. If you can do that, assemble it at 16384 and your battle is 1/2 fought, albeit the easy half. When you put it at 15000, you are making your job unnecessarily hard. ------------ Category 5, Topic 3 Message 59 Sun Sep 05, 1993 C.DRUTIS [Monsoon] at 10:07 EDT e.g.bell, I wish I had the Transactor you mentioned a week ago -- t'would have saved me a great deal of time. As it is, the technique of putting the kernal calls in common RAM works for the most part. I only used three kernal routines in the program, BSOUT, GETIN, and PLOT. BSOUT and GETIN worked fine this way, but PLOT would bomb-out every time. My guess is that some Kernal routines flip to RAM-0 (or mess with the MMU in some way) as a matter of course. Luckily, writing a cur sor-positioning routine to replace PLOT was pretty easy. [Apptest 0412] ------------ Category 5, Topic 3 Message 60 Sun Sep 05, 1993 CBM-ED [e.g.bell] (Forwarded) Monsoon: I was on vacation since August 27... hehe. I really see no reason for what you are experiencing though with 1 possible exception. How are you handling interrupts? You know that when an interrupt hits bank 15 must be in context, right? There is an exceptionally neat little routine you can use to make sure all goes well for you when programming in other banks so that the interrupts occur properly... and this could very well have been your problem all along, you know... the technique involves the BRK interrupt, and looks like this: sei lda 788; first point brk vector sta 790; at irq service code lda 789 sta 791 lda #<irqsrv; then point irq vector sta 788 lda #>irqsrv; at your switch sta 789 cli rts irqsrv = * lda #0 sta $ff00; set bank 15 configuration brk; and service irq thru brk nop pla; restore old configuration sta $ff00 pla; and .a, .x, and .y also tay pla tax pla rti irqsrv MUST be in common ram and this should take care of interrupt processing for you wherever your code is. This code was contributed to Transactor, Volume 8, Issue 3, by Chris Miller, author of Buddy and a bunch of other stuff, and he ascribes it to Brial Hilce, author of Pro-Line's Cocompiler. Now, why should you go to the trouble of using this now... considering that you are working in bank 1, interrupts may prove to be a problem down the road even if they were not the current problem, and this little trick is almost too neat not to use... Anyway, may future sailing be smooth! ------------ Category 5, Topic 3 Message 62 Mon Sep 06, 1993 CBM-ED [e.g.bell] at 05:53 EDT Jeff: JJ> If the programmer does what I suggest, the program WON'T be JJ> linked when LOADED. Only the first BASIC program will be JJ> linked. The BASIC routine will come to the first 000 and JJ> think it's at the end of the program when there's a sea of JJ> binary data and a whole program in higher memory. If that JJ> program isn't linked properly, all lockup could break loose. This is what I said would happen... the BASIC code would be relinked, and that unless you were speaking of something peculiar to modlinker.... why would binary data have to be relinked? I have been under the impression that modlinker linked multiple ml modules to a BASIC program. (I know that even a BASIC program is binary data at the very lowest level, btw ;) I have never used modlinker.... are you saying that it allows you to, for example, link a basic program to a block of sprite data to a block of ml code to another block of BASIC program (which would have to be relinked) or that the sprite data and ML code would have to be relinked. If the former, that makes for some interesting questions I would have regarding modlinker. Actually, what you suggested I don't think would have worked for him. He said his code loaded at 7169, which is not $1800, but $1c01, the start address for 128 mode BASIC 7.0 files, which Rob or JBEE noted. I got the impression you were answering based on a 64 mode program that twiddled the start-of-basic pointers. If modlinker shuffles all the various program parts into place after a load, I would think it would handle the relinking also (via a call to that routine, tho I don't know if it is as accessible in the 64 mode as in 128 mode). Does Modlinker require a BLOAD? (or load ,8,1). If so, even the first program would not be linked. This is kind of interesting... especially what kind of linking the sea of binary data and the program in higher memory need. ------------ Category 5, Topic 3 Message 63 Mon Sep 06, 1993 C.DRUTIS [Monsoon] at 08:14 EDT Nice code, e.g., thanks. I'll try it out the next time I update the program. [Apptest 0451] ------------ Category 5, Topic 3 Message 64 Mon Sep 06, 1993 T.RUTTER2 [Troy Rutter] at 10:57 EDT Whoa! Time Out! My SID player is on a 64... where did the 128 come into play? I remember the sid code Ed wanted was for the 128, but my SID player is for the 64. I dont think the graphic commands will work in basic 2. <g> BTW ed... im still trying to get a hold of some people... a couple more people to try for what you need. Keep your fingers crossed. -Troy ------------ Category 5, Topic 3 Message 65 Mon Sep 06, 1993 CBM-ED [e.g.bell] at 13:40 EDT Troy: The reason we were considering the 128 BASIC was the load address you gave of 7169. That is where the 128 mode BASIC programs normally load. However, if you d what you are saying you are doing, your problem is very apparent. Kermit assembled the code we have been talking about using the .bas pseudo-op, and it automatically adds the ML to the end of the BASIC code. I thought I had already pointed out that when you relocate the BASIC code anywhere, even 1 byte higher or lower in memory, you screw up all of the absolute references in the ML code. If you want to move the start of BASIC up, you must assemble your code (using PAL or Buddy, whichever it is you were using) to that address and assemble it there. This will assure that the routines I mention will work correctly. Otherwise they are going to work like fish out of water. Give this a try and see how you make out. ------------ Category 5, Topic 3 Message 67 Mon Sep 06, 1993 CBM-ED [e.g.bell] at 23:02 EDT Jeff: JJ> I wrote the book on linking. Every issue of LOADSTAR only has JJ> 2300 blocks of space available. In my five years at LOADSTAR, JJ> I have had to link and pack SCORES of programs. I asked you specifically if the linking you were talking about had something to do with the linker program. What I said has to do specifically with program links, and I said, as you did, that only the first BASIC program loaded would be linked. I also asked you if your linker linked BASIC to ML to BINARY to BASIC, for example, so that I could understand why ** BASIC ** would have to link binary data etc. I said, and am correct (as you also said) that it would not. So far, in the particulars, we seem to agree, right? JJ> I've developed a foolproof method of getting these things JJ> linked, packed and on the issue with utilities designed for JJ> programs that load at $801 I'm sure you have. I have no reason to question that. After all, you wrote the book, right. However, the original questioner stated in his post that his program did not load at $0801, and he uploaded source code to me that you did not have access to for your answer. That does not mean that what you suggest would not work. I was answering based on information I had, his post (which, as others also noted, indicated a start at 7169 and not $0801/2049). Based on what I saw of his start of program at 7169, I made a natural assumption that this was a 128 mode BASIC program, which you did not, right or wrong. But given a BASIC program that starts at 7169, do you agree that address 43 and 44 will have no effect on the start of BASIC in 128 mode? That such pokes will not work? As it is, the program is in 64 mode, but I was paying attention to what Troy was asking me, not some utility of my own that I thought would solve his problem. None of this is solving Troy's problem tho (and I only mentioned the incorrect hex thing because, again, it seemed to more than me that we were dealing with a BASIC 7.0 program rather than a relocated BASIC 2.0 program) and for Troy, I stand by my answer, especially if it is in 64 mode. Assembling the code, including the BASIC portion of it, at 2049 (or 7169) and loading it at 15000, when it has attached ML, will simply not work, and I doubt if StarLinker or ModLinker, or any other program, could make it work, and I know you will agree with that too. (the source code is in PAL format or Buddy, whichever has the .bas pseudo-op, and has a big BASIC section at the start, followed by an attached ML section which is auomatically assembled and saved as one file, so we are on the same page) Just to synch what we are talking about, when I talk about linking, I am talking about the linking that is done to a BASIC program after it is loaded with a ',8', which, as we both have said, will only go to the terminating 3 zeroes at the end of the file, regardless of how much is in the file. I don't know how your linker works, tho I did ask. You can check my post to see that that is what I had said. ------------ Category 5, Topic 3 Message 68 Tue Sep 07, 1993 T.RUTTER2 [Troy Rutter] at 14:59 EDT Ed, all: I figured out one minor problem... the reason my basic file was loading aty 7169 or something like that was because I renumbered the program and saved it in 128 mode, so the file pointer kept the 128 basic address. :) ------------ Category 5, Topic 3 Message 69 Tue Sep 07, 1993 CBM-ED [e.g.bell] at 1748 EDT Troy: 2 things came to me today that will cause a problem with doing the things the way you are doing them. First, when using the Kermit code you sent me with the ML attached to the BASIC.... did you make ANY changes at all to the BASIC. If so, there is one major problem. In programs constructed like that, you cannot make any edits to the BASIC code at all using the BASIC editor. Any changes must be made to the ML source code, which includes the BASIC portion, and all must be reassembled or the ML will be totally trashed. Second, I now understand what you are doing wrt the start-of-basic pointer, moving it so you can just LOAD the SID data and it goes to address 15000. There are 2 major problems with this. First, the way BASIC programs operate require the start-of-basic pointer to be pointing at the true start of BASIC code. This is necessary so all of the GOSUBs will work, among other things. For forward branches/jumps, the BASIC interpreter starts at the current address and searches forward to the end of the BASIC program for the desired address. However, for backward GOSUBs, the search starts at the start of BASIC, which I am sure is derived from those pointers. You have tricked it into looking in the wrong place for its search if I understand things correctly. In addition, and semi-related to what Jeff and I were saying, if you locate the start of basic pointers to point to 15000 so that you can just 'LOAD "DATA",8' for example, when this data is loaded, the computer will attempt to link the data as though it was a BASIC program file, which at best will trash your SID data, and at worst, cause the lockups you describe. Thanks for filling us in on that 7169 address. It was tainting many of the answers I was giving. To deal with the first problem I mentioned above, you are going to either have to get PAL and do your edits with the BASIC and ML and then assemble it, or you will have to separate the ML and BASIC and make your edits like that. The second problem you will have to use the pokes/sys's suggested if the files are not set to load at 15000. As for the lockups, either could cause them. ------------ Category 5, Topic 3 Message 70 Sat Sep 11, 1993 CBM-ED [e.g.bell] at 09:54 EDT Troy: I wrote a little code last night at work that you can use to display your word files. I need to verify a couple things before posting it though. Do the word files end with 0's and does each line end with a carriage return. I can make the code relocatable, but that is a bit more work than I want to do, but it is very very short and I believe you will be able to work with it. I'll post it as soon as you give me the answer to those 2 questions. Also tell me where you would like the code to execute. It is less than 256 bytes so any even page would be fine. I wanted to fit it into the cassette buffer, but it was not to be because of the lookup-table. How about, say, $CF00? ------------ Category 5, Topic 3 Message 71 Mon Sep 13, 1993 T.RUTTER2 [Troy Rutter] at 19:08 EDT Ed, sounds great! There is a carraige return at the end of every line, and also a 00 at the end of the words file. The SID player ML is located from $c000-Cfff The basic program is at 2049 with the SID archives being loaded at 15000. So locating the subroutine at $3000 (12288) should be safe as long as my program doesnt get too big. On a linear note: Image my surprise when I found the following in Jim Butterfield's book... "If the Commodore character is below $3f, it may be transmitted directly to the ASCII facility "If the COmmodore character is between $40 and $5f, it should be logically ORed with $20 before transmission "If the Commodore character is between $c0 and $df, it should be logically ANDed with $7f before transmission." Sheesh, maybe I should have looked at this before I started... ::sigh:: ------------ Category 5, Topic 3 Message 72 Mon Sep 13, 1993 CBM-ED [e.g.bell] at 21:08 EDT Troy: Then my code is correct. I'll post the source here tomorrow when I have more time for the routine, and I'll assemble a copy at 12288 and drop it in your mail box along with the routine addresses you will need. There will be 2, one to set it all up and one to call for each line of words. BTW, I'll pot the source in this topic... tomorrow. As for Butterfield's code, yes, it is just that simple to translate PETSCII to TRUE Ascii. Many don't choose that algorithm because it is slower than a lookup table, and in telecom, a very frequent user of that kind of code, speed is kind of important. However, in your code it is not that critical. Maybe I'll try to make the code relocatable tonight at work. The lookup table is one of the bigger obstacles to making the routine relocatable, and, as a matter of fact, where it can be put. Remove that and it will fit in the cassette buffer and you won't have to worry at all about BASIC. BTW, the code you quoted from Butterfield is going in the opposite direction, so to speak. You need code to translate from True ASCII to PETSCII, tho it is not all that difficult a task. I'm sure I have the code to do it somewhere around, but it will take less time to rewrite than to find. ------------ Category 5, Topic 3 Message 73 Tue Sep 14, 1993 CBM-ED [e.g.bell] at 10:00 EDT Troy: Here it is.. it was somewhat longer than I originally anticipated. The code is only like 70 bytes or so, but I am posting an assembly dump, including instructions for using it and DATA statments for poking it in from your BASIC. Test it cuz I can't. If we need to adjust it we'll do that... here goes: 30 last edited 09/14/93 by e.g.bell - source code in egads format 35 40 -----<this code is relocatable> 45 -----<program variables - rs232 zp variables> 50 55 low = $f7 60 high = $f8 65 h.low = $f9 70 h.high = $fa 75 80 -----<kernal calls> 85 90 chrout = $ffd2 95 plot = $fff0 100 105 -----<entry for text display 110 115 3000 18 routine clc 3001 90 09 bcc show 120 125 -----<initialize word address pointers> 130 135 3003 setup = * 140 3003 85 f7 sta low 3005 85 f9 sta h.low 145 3007 86 f8 stx high 3009 85 fa sta h.high 150 300b 60 rts 155 160 -----<show a line of text in row .x> 165 170 300c a0 00 show ldy #0 300e 18 clc 300f 20 f0 ff jsr plot 175 180 3012 a0 00 ldy #0 185 3014 b1 f7 !01 lda (low)y 3016 d0 09 bne !02 190 195 -----<handle end of words by resetting pointers> 200 205 3018 a6 f9 ldx h.low 301a 86 f7 stx low 210 301c a6 fa ldx h.high 301e 86 f8 stx high 215 3020 60 rts 220 225 -----<update words pointer> 230 235 3021 e6 f7 !02 inc low 3023 d0 02 bne !21 240 3025 e6 f8 inc high 245 250 -----<is this the end of the current line> 255 260 3027 c9 0d !21 cmp #13 3029 f0 18 beq !03 265 270 -----<translate from true ascii> 275 280 302b c9 41 cmp #65 302d 90 0e bcc !24 < "a" 285 302f c9 5b cmp #91 3031 90 08 bcc !22 <="z" 290 3033 c9 61 cmp #97 3035 90 06 bcc !24 some punctuation chars 295 300 -----<print and loop for next character> 305 310 3037 e9 20 sbc #32 3039 b0 02 bcs !24 'upper' to lower case 315 320 303b 69 80 !22 adc #128 'lower' to upper case 325 330 303d 20 d2 ff !24 jsr chrout 335 3040 18 clc 3041 90 d1 bcc !01 for relocatable 340 345 -----<return to caller - line has been printed and pointers are> 350 -----<pointing at next string> 355 360 3043 60 !03 rts 365 370 -----<to use this code> 375 380 setting up 385 1] poke 780,word-address-low 390 2] poke 781,word-address-high 395 3] sys routine+3 400 405 showing a line of words 410 1] poke 781,row-to-display-text-on 415 2] sys routine 420 425 when the routine returns 430 - if peek(780)=0 then end-of-words-data 435 - if peek(780)>0 then end-of-line 440 This is the data you would poke into memory to install the above routine. 12288 data 024,144,009,133,247,133,249,134 12296 data 248,133,250,096,160,000,024,032 12304 data 240,255,160,000,177,247,208,009 12312 data 166,249,134,247,166,250,134,248 12320 data 096,230,247,208,002,230,248,201 12328 data 013,240,024,201,065,144,014,201 12336 data 091,144,008,201,097,144,006,233 12344 data 032,176,002,105,128,032,210,255 12352 data 024,144,209,096,-1 122 does not use the zp pointers I used. That would cause a definite problem. Let me know how this works for you. ------------ Category 5, Topic 3 Message 74 Tue Sep 14, 1993 T.RUTTER2 [Troy Rutter] at 15:33 EDT Ed, I changed one thing in your code... on line 3037 I changed subtracting 32 to subtracting 128. The words file dont include any characters between 97 and 122. All alphabetic chars are either between 65 and 90 or 193-218. It works great in my tests so far. :) also, as I said in Email, I think the SID program uses 780,782 as well as 250. Could be some problems... ill check and see. Thanks... looking better! ------------ Category 5, Topic 3 Message 75 Tue Sep 14, 1993 CBM-ED [e.g.bell] at 23:24 EDT Troy: TR> on line 3037 I changed subtracting 32 to subtracting 128. The TR> words file dont include any characters between 97 and 122. TR> All alphabetic chars are either between 65 and 90 or 193-218. If all alphabetic characters are in the range you say, this is not a true ascii file, and it sounds to me like there should be no translation needed at all. That is even further suggested by your question about the color codes. TR> I think the SID program uses 780,782 as well as 250. Registers 780-782 are the .a, .x, .y, and .sp registers respectively, used by virtually all ML programs in the 64 mode. If SID uses 250, that would be a problem, but if it is working as well as you say, I don't think it is. You'll have to keep an eye on that. You may have to do some thinking about other registers than what I used, and how I did it. As for the changes you made, I really need to see a copy of the data file you are using. You have made me rethink the whole translation required. I had been under the impression this was in true ascii format because of what you had said earlier. But that would not be consistent with using color sequences or the range you mention above. It sounds more now like none is needed. Could you ul a file, or direct me to the number of one in our libs that I can download and check out myself. Does the program that combines the components into the SAL or whatever they are called do any kind of compression or anything on the files? ------------ Category 5, Topic 3 Message 76 Thu Nov 10, 1994 J.SZCZAP (Forwarded) I have no idea if this is the right place to ask this,but... I have a C-64 and was wondering about computer languages... I've noticed that TONS of people make programs and demos on the C-64, in machine lnguage... Is there anywhere that I can find out how to program in mchine language??? I really would like to find out... Thanks... Justin... ------------ Category 5, Topic 3 Message 77 Sat Nov 12, 1994 GEOS-TIM at 01:30 EST Justin, >>Is there anywhere that I can find out how to program in Machine >>language??? In our libraries, right here in the Commodore area there are many files on ML programming. You can get a large list, by Setting your library to #61 (all libraries) and using the search of "ML". Several examples I got were: file # 2910 ML Column.ARC, file # 15892 Tutor.ARC a basic and ML tutor prgs., file # 14896 ML Tutor.SDA, file # 12199 MLearn-JBEE.txt, and also three files that were from a Programming course in our RT...file numbers 14555,14556, and 14438. There were also files with memory maps, ML monitors, etc. Happy programming.......Programming keeps the platform alive. :) :) -Tim ------------ Category 5, Topic 3 Message 78 Sun Nov 13, 1994 CBM-MARK at 00:42 EST Thanks for replying to Justin, Tim! Sheesh, *I* forgot all about those ML tudor files in he Libs :/ ~~Mark~~ ------------ Category 5, Topic 3 Message 79 Sun Nov 13, 1994 J.SZCZAP at 18:23 EST This is Justin... Thanksa lot for your help!!! ------------ Category 5, Topic 3 Message 80 Tue Nov 15, 1994 J.FOWLER [Lone Wolf] at 19:38 EST Hi! I have PowerC 128 and 64, I was wondering if the some of the files intthe libs that are suppossedly fix's to bugs in the C compiler. one I have disolved in to a file that ends with .a and when i veiwed it it had a C function header, however all the code was in assembly. do I need to compile the code on Power Assembler? Also their was a peek poke fix that is in the same format. Do I really need this fix or is it just some minor bug. Also I noticed that the linker does not like using 2 drives is there some thing I need to do to get it to work better. Also using the CED syntax checker editor gives my errors on global variables at times, when i use them inside other functions! Is there a better syntax checker than having to discover error at compile time! ------------ Category 5, Topic 3 Message 81 Wed Nov 16, 1994 PIXELS [Lee Sr.] at 20:40 EST Lone Wolf, See ya in Cat 5, Topic 10; "Programming in C". ------------ 5 ?