8bitfiles.net/archives

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

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

Wrap

Text File | 1990-02-12 | 37.4 KB | 863 lines

************ Topic 7 Sun May 22, 1994 B.GANN1 (Forwarded) Sub: staying motivated How to stay motivated to finish a program 7 message(s) total. ************ ------------ Category 5, Topic 7 Message 1 Sun May 22, 1994 B.GANN1 (Forwarded) Motivation... How do you programmers out there keep yourself motivated to finish a program? I find myself working hard on a program. Then I shelve it to work on something else. I never seem to finish and polish anything up. Anybody got any tips to overcome this? Brenda ------------ Category 5, Topic 7 Message 2 Sun May 22, 1994 B.MASSE [BIG BOB] (Forwarded) Category 5, Topic 28 Brenda said to all.... Motivation... How do you programmers out there keep yourself motivated to finish a program? I find myself working hard on a program. Then I shelve it to work on something else. I never seem to finish and polish anything up. Bob says, I certainly am not a REAL creative programmer, but I have done quite a few simple programs to use in my business. My experience over the last 10 years is that a program is NEVER finished. There always seems to be little things to add or improve on, or just plain change around. On the other hand, I have a hard time allowing a program that I am currently creating or improving get hung-up with some BUG that makes it an un-working program. Then I will get obsessed until I have either fixed it or trashed it all together.... must be the VIRGO in me. Bob ------------ Category 5, Topic 7 Message 3 Sun May 22, 1994 CBM-ED [e.g.bell] (Forwarded) Brenda: BG> How do you programmers out there keep yourself motivated to BG> finish a program? Personally, when I'm writing a program, it is usually because I need it. When I stop working on it to work on something else, it is because something else I need more came up, or someone has found a glitch in something else. I have also done contracting work and I think I can understand what you are saying in those terms. It is most fun when he big dramatic parts of the building are going up. For instance, raising the walls, hanging drywall, etc. It gets tedious when you start doing the million little things that need done to finish the project. That is when I was usually chomping at the bit to move on. Of course, I get that way after I've spent a long time on a project too. When all is said and done, I don't want to be known for one program or one genre of program... I like to move around like a dog... little spot on every pole. :) BM> a program is NEVER finished. There always seems to be little BM> things to add or improve on, or just plain change around I've found that to be true, but also a demon I've learned to live with. If I ever want to move on, I have to say it is enough. I'll go back and fix something that turns up wrong, but at a certain point, I consider things done as far as I'm concerned. Magic 128 is a good example for me. There may be things I'd like, but it does do everything I've ever needed from it. Again, I just don't want to be known for one program or type of program. BM> hard time allowing a program that I am currently creating or BM> improving get hung-up with some BUG that makes it an BM> un-working program. Then I will get obsessed until I have BM> either fixed it or trashed it all together I can also identify with that. There have been many programs where I just cut my losses and rewrote the program or the troublesome routine. Frequently, it ended up better this way than my original intent. Some programs got put away and never finished because of this. And I eat, sleep, and go to the bathroom listings and debugging... I hand code on paper, flow chart, and desk check even more than I work at the keyboard. Like Bob said, though, it is probably obsession that keeps me at something until I consider it finished. And then there is Mark Dulski, who makes SURE I never stop working on my stuff until it is 'finished'. hehehehe ------------ Category 5, Topic 7 Message 4 Mon May 23, 1994 CBM-MARK (Forwarded) LOL! Ed ;D ------------ Category 5, Topic 7 Message 5 Thu May 26, 1994 S.EYRSE [steve] (Forwarded) Myself it is the drive from Gig Harbor to Seattle. As this takes a hour to hour and a half. I have a lot of time to THINK about the program I'm working on (if any) *l del 5 ------------ Category 5, Topic 7 Message 6 Fri May 27, 1994 CBM-ED [e.g.bell] (Forwarded) I agree with that too Steve... I usually walk twice a day for about 45 minutes each, and that accounts for a LOT of my programming time too tho no code is getting written. ------------ Category 5, Topic 7 Message 7 Wed Sep 21, 1994 A.PLATT3 [Arthur] at 00:17 EDT Myself, I just set apart vertain times in a day to do the programming... or whenever I feel like I want to, or have the time. It's almost like homework (I know, you thought you were going t get out of it after school was out, but then again...) I always set apart a certain time to do it. It almost sounds like I don't like to program, but I do. I like to be formal, on time...once I've achieved that feel, I'llwork on anything.. but just as soon as my alarm clock doesn't go off, it takes me awhile to get back in the habit. But, this way, it keeeps my programming skills improving, although I may not even be programming anything at all, anyway. Too, I do a lot of my staging out and graphics, and overall memory locations, organization, and other things away from the keyboard. I seem to program MUCH faster that way. I get it on paper and the programming just comes. But, I guess, the main point of this WHOLE response is, for me, if I keep myself on a not-too-strict, but partially strict schedule, I've got it made. ------------ 5 ? ************ Topic 9 Mon Jun 06, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Sub: Speeds avove 1200 baud... How do I get the C64 to handle modem speeds greater than 1200 Bps? 19 message(s) total. ************ ------------ Category 5, Topic 9 Message 1 Mon Jun 06, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Hi! I'm trying to write a terminal program, and I am having a problem figuring out how to get the c64 to receive data from the modem at speeds above 1200 bps. My test terminal is sending commands to the modem, apparently at 2400, but all I get when the modem responds is garbage. Any help will be appreciated. ------------ Category 5, Topic 9 Message 2 Mon Jun 06, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Oh, I forgot to mention that I am writing this term in ml. I suspect I may have to write a new NMI handler. ------------ Category 5, Topic 9 Message 3 Tue Jun 07, 1994 CBM-ED [e.g.bell] (Forwarded) Fred: FS> am having a problem figuring out how to get the c64 to receive FS> data from the modem at speeds above 1200 bps. My test terminal FS> is sending commands to the modem, apparently at 2400, but all FS> I get when the modem responds is garbage There have been 2 ways I have seen it done. One was to copy some of the ROM routines into RAM and adjust the timer latch values. This is how Steve Punter got his to work at 1200, and some people were able to tweak the same handler to do 2400. I never could get it to work reliably. Another, and better, way, would be to get a copy of George Hug's 2400 wedge which was just over 1 page of memory and does the job. Most 64 terminal programs at one time or presently used this to handle 2400 reliably. The down side, if you consider the following down sides, was that George's code disregards things like parity, and I believe handshake and some other things that a terminal could not do much with anyway. I don't believe his code handles 7 bit either, and there is only one stop bet setting available *if* I remember correctly. The up side is that as I said, many programmers have made good use of his code to achieve this 2400 feat with ease and reliability. There was an author (CCGMS) who was the first to do this with the 64 and without George's code. I'm not sure how he did it. I never looked that close at his code, but I hve at George's and have used it for years. If you decide to go it on your own, you are going to have to do something to tweak the timers used to accumulate the incoming bits. It is going to really be the receive that causes the most problem, I am sure you wwill find out. ------------ Category 5, Topic 9 Message 4 Tue Jun 07, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Yes, I have discovered that it's the receive that causes the problem. I have looked at some code, and it appears the chkin routine was altered, although I'm not sure why... unfortunately, my copy of mapping the c64 was taken out of state by a friend, and he lives there now... so I am programming with nothing more than the Programmer's Reference Guide... with is about as useful as boobs on a bull. Which timers control the incoming bits? I was experimenting with $0299 and $029a, and timers a and b of cia #2... and I did get some usable output, but garbage as well. ------------ Category 5, Topic 9 Message 5 Wed Jun 08, 1994 CBM-ED [e.g.bell] (Forwarded) FS> it appears the chkin routine was altered, although I'm not sure FS> why I can't remember what George's code does. I am pretty sure it modifies that vector though. I don't even use chkin for my modem stuff. I just go directly to a routine to read from the input buffer. It saves that much more time... and in the C64 time is precious. $0299 and $029a are the timers for sending a bit. Addresses at $0295/6 are for non-standard baud rate bit timers. According to the mapping book, the value here should equal the system clock frequency divided by 2 minus 100, stored in low-byte/hi-byte order". The system clock frequency for NTSC is 1.02273MHz. As I recall, this pair of values would be part of the rs232 open statement in the last 2 positions of the 'filename'. I don't know how you would go about tweaking the start-bit detection time in the ROM code if you can at all. All of this is why you would be much better getting hold of George's code. It works. BTW, timers a and b of cia #2 are correct for this. Have you considered disassembling the ROM NMI routines? Might give you some clues as to where to start. ------------ Category 5, Topic 9 Message 6 Wed Jun 08, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Yes, I have considered dissasbling the rom nmi routines... problem is I'm not good at figuring out what other people have done... but perhaps it would be worth printing out the rom routines... maybe if it was on paper I could follow it better. I like your idea of reading right from the modem buffers... it does seem like it would be faster, and not that difficult to keep the pointers inline. I'll have to try that. Finally, where can I get 2400 wedge? I didn't see it in the library. Also, thanx for taking the time to try and help. :). ------------ Category 5, Topic 9 Message 7 Thu Jun 09, 1994 CBM-ED [e.gbell] (Forwarded) FS> I'm not good at figuring out what other people have done... but FS> perhaps it would be worth printing out the rom routines... FS> maybe if it was on paper I could follow it better You would be surprised how much easier it is to figure things out when you have them on paper in front of you. I bought my first printer before I bought a disk drive for this very reason. And to tell the truth, you don't need to understand it all.... all you really need are to see where the timers are loaded from and what would be needed in RAM. You *could* download one of the Punter protocol source files from our libraries. They have the source code for Punter's kludge included, which is how Steve P. tweaked 1200 out of the 64, and some have gone to 2400. As for George Hug's wedge, I think someone could make arrangements to get you a copy of that code. I have it somewhere unmodified. I contacted Transactor years ago when it first came out and got permission to use it. Their condition at the time for me or anyone was that the author be credited (George Hug) along with the volume and issue of the magazine in which it appeared, which was Volume 9 Issue 3, April 1989. I'll drop it in your mailbox within the next few days. Just gotta find the time and the file. :) FW> I like your idea of reading right from the modem buffers... it FW> does seem like it would be faster, and not that difficult to FW> keep the pointers inline Well, consider than in the 64, there are 4 pointers dedicated to these buffers in zero page. The system doesn't mess with them... you just have to set them in the right order of your vars, etc. if you plan on relocating the rs232 buffers. Long time since I've worked with all that. George's code may obviate the need for all that. FW> thanx for taking the time to try and help That's one of the ways we earn our keep. :) ------------ Category 5, Topic 9 Message 8 Thu Jun 09, 1994 S.FREDERICK [Fred Stein] (Forwarded) Thanx... I hope that your disks are better organized than mine... since I got the 486 I really haven't taken the time to put my commie disks in order. ------------ Category 5, Topic 9 Message 9 Sat Jun 11, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Ed -> I received the file this morning... thanks. I'll let you know how I make out. -Fred ------------ Category 5, Topic 9 Message 10 Sun Jun 12, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Ed -> Thanx for the Hug's Wedge... problem is, it doesn't seem to be working very well. I assembled and ran it, and now when I send a character to the modem, the send light comes on and remains lit. It does exit the nmi routine, however... I stopped my terminal and looked at the 9e00, and my modem command was there... but the modem did not respond... there was nothing at $9f00. Any suggestions? I've tried using someone else's code, which was almost identical to Hug's Wedge, and the modem did the same thing. I suspect that something in the nmi handler routine is causing this, but I'm not sure what it is. -Fred ------------ Category 5, Topic 9 Message 11 Mon Jun 13, 1994 CBM-ED [e.g.bell] (Forwarded) What assembler do you use? If I were you, I would dump a listing to printer, since it is only a memory page or so, and carefully check to make sure what you got is what you wanted. I know Merlin, for example, needs to be explicitly told that a binary parameter is immediate or it assumes it to be an absolute operation. This can cause major problems with the code. I know this from experience when I helped another guy who used Merlin. This is just one suggestion. I assume you are using buffers at $9e/$9f from your message. Guess those *are* the defalut c64 rs232 buffers tho. ;) Did you open the channel to the modem correctly BEFORE you installed the wedge? The wedge uses the settings made by that operation to install its own timer values. Check all this and see if any of it makes a difference. ------------ Category 5, Topic 9 Message 12 Mon Jun 13, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Did I open the channel correctly BEFORE I installed the wedge? Errr... no. Let me hop off here and try that... I installed the wedge first. :D. ------------ Category 5, Topic 9 Message 13 Tue Jun 14, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Welp, itthe modem light stopped staying on after I opened it when I was supposed to. I do have one question: at which times am I supposed to call the routines inable and disable, and am I supposed to use rsget and rsout for modem i/o? I really wish I had the Transactor article to refer to. ------------ Category 5, Topic 9 Message 14 Wed Jun 15, 1994 CBM-ED [e.g.bell] (Forwarded) Fred: FS> question: at which times am I supposed to call the routines FS> inable and disable These routines shut down the NMI during DOS activity. Therefore, call 'disable' prior to any DOS activity, including REU and especially RamLink. When this activity is complete, call 'inable' to restore the NMI handling. FS> am I supposed to use rsget and rsout for modem i/o Yes. That is exactly right. As I recall from the original wedge, the chkin and chkout routines are routed through new vectors that handle the inable/disable for you... I don't remember that for sure and calling them more than once won't hurt anything. I changed the code somewhat as far as what happens when, etc. because certain things were done more often than needed IMO... like the baud rate setting, among other things. I also skip the chkin/chkout routine calls altogether and just call disable/enable when needed. This frees me to just call the rsget/rsout routines instead of using the kernal entry points. The reason you had to open the modem channel before installing the wedge is because the open sets up a couple memory addresses, one of which is used to generate the pointer into the baud rate tables in the wedge. Not opening this, you were using the incorrect pointer. ------------ Category 5, Topic 9 Message 15 Wed Jun 15, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Ok... thanks for the info. I'll see what I can do with it. ------------ Category 5, Topic 9 Message 16 Sun Jul 03, 1994 S.FREDERICKM [Fred Stein] (Forwarded) Ed... You asked me why I did the chkin/getin thing right after the call to open... from what I could gather from the prg reference manual, that call was necessary to initialize the rs-232 channel. Maybe I was misled by what I read. When I attempted to open the channel at 300 baud, I assumed the kernal rom routines would set up $299/$29a for 300 baud operation... likewise the 1200 baud, which I know to be incorrect. But the system should have run fine at 300 baud, and it didn't. Although I'd like for the program to default to 2400, it's not a necessity. The code has been modified about seventy times trying different things. As far as the baud routine in hugs wedge, I also do not like the and #06 thing... I don't see why I couldn't just ldy with 0, 1 or 2 to set the baud rate. I'll try your suggestions, and I'll set the baud rate to 1200 in the open command, if that's what the wedge is expecting. About the dec thing: I realise now that you are correct. Wouldn't the following also work: dec $0299 bpl label1 ;test negative flag dec $029a label1 rts Saving 3 bytes? -Fred ------------ Category 5, Topic 9 Message 17 Sun Jul 03, 1994 CBM-ED [e.g.bell] (Forwarded) Fred: FS> As far as the baud routine in hugs wedge, I also do not like FS> the and #06 thing... I don't see why I couldn't just ldy with FS> 0, 1 or 2 to set the baud rate. I'll try your suggestions, and FS> I'll set the baud rate to 1200 in the open command I think if you are going to do it that way you may have to load .y with 0, 2, or 4 if I remember correctly Fred. I always thought that was an odd way to do it, but since the kernal does put the correct values (as far as what the wedge needs) into baudof and baudof+1 when you open the rs232 channel for a specific baud (300 1200 or 2400 only) that is all you need to do. As I said later, given that you were poking a 1 into baudof+1.... I don't know. I should have done the open and checked from BASIC to see what the value in baudof was. Your code may not be a problem, but I believe you may have run into problems at any other baud doing things like that because of the BAUD routine. 2400 may be the *one* you could get away with it with since it was the first set of values in the table, if you see what I mean. FS> from what I could gather from the prg reference manual, that FS> call was necessary to initialize the rs-232 channel. Maybe I FS> was misled by what I read. When I attempted to open the FS> channel at 300 baud, I assumed the kernal rom routines would FS> set up $299/$29a for 300 baud operation I don't think that is correct for a couple of reasons. First, you are not going to be using the ROM routines at all once you call SETUP and have Hug's wedge in place. Thus no need to 'initialize' that. I believe the OPEN takes care of $0299 and $029a automatically for you... depending on the last 2 values in the OPEN statement to the rs232 channel. You opened the channel then manually poked the values from Hug's timers into BAUDOF/BAUDOF+1. You now have 2400 values in the timers and are trying to read data from the modem with a routine (ROM) that won't handle that. I believe, no matter where the problem is finally found, you don't need to connect or read the channel to the modem before calling SETUP. Matter of fact, you can do things calling RSGET and RSOUT directly, never referring to that channel again IF you make sure to handle DISABLE and ENABLE correctly. As far as I've ever been able to tell, the only thing that OPEN is really needed for is to set those values in BAUDOF/BAUDOF+1. I could be wrong about that, but I do know I don't use CHKIN or CHKOUT at all in my 128 code. It just adds time to the handler, not to mention CLRCHN. I just make direct calls to RSGET and RSOUT, and DISABLE/ENABLE prior to any DOS or REU activity. Wouldn't the following also work: dec $0299 bpl label1 ;test negative flag dec $029a label1 rts Saving 3 bytes? No, this won't work either, and this is a trap I still get caught in frequently when I am not paying attention. Here is why. The bit you are testing, but 7, is going to be set as long as the value in $0299 is greater than 128. that the high byte is going to be cycling 1/2 the time. I can't tell you how many times I have done this in my programs and took days finding out why later routines would not work. (I would be using the test in an init routine.) Ex: init.code lda #0:ldy #160 !01 sta registers,y dey bpl !01 rts The code would only init the first time thru the look, at registers+160. .y would be decremented once, but since it was then 159, and bit 7 thus set, it would be satisfied and leave. Looking at the routine, everything looks great TO ME, but the computer doesn't like it and never protests. :) BTW, I am wondering just what your code is doing. From later examination of the Term mode, I am guessing that perhaps a character is being sent constantly to the modem. Is that correct? O, and finally, during testing I would recommend you remove any cartridges (exc. SwiftLink, when you start working with that) to make sure your results are not skewed by something outside the 'control' conditions. I've gotten beaten by that ttoo... my code was working but my Mach128 cartridge was making it seem that it was not, etc. After you try some of this stuff, and post back, let us know exactly what is or is not happening. O, and you don't have to lower the baud rate of your test code to 1200. Just make sure that the values in Hug's timers are at 2400 after you set them there in your code, if you know what I mean. Dump your assy. to printer so you can brk out and check them to make sure. ------------ Category 5, Topic 9 Message 18 Sat Jul 09, 1994 S.FREDERICKM [Fred Stein] (Forwarded) I Found It! I think the problem boiled down to the differences in the assemblers we use. In the hug source that I got from you, stt24 and full24 were defined at the top, then were put into the code after the nop. The labels should have been beneath the nop, in the format: strt24 .wor $01cb strt12 .wor $0442 etc. As it was written, my assembler placed the value $01cb in the baud subroutine... e.g. lda strt24,y ;lda $c [ $01cb,y which should have read: lda $ce13,y I really must apologise. The reason I didn't find it was because I did not follow your instructions. You suggested printing out the assembly... today I finally did that, and voila! Bug found! I suppose it was out of laziness... I don't keep my printer plugged into the 64 due to space constraints. I really apreciate you're taking the time to help me out... I couldn't find anyone local who knew how to do 2400 baud. I also made all the other changes you suggested. When I'm done writing yetanothercommieterm, I'll be sure and send you a copy. -Fred ------------ Category 5, Topic 9 Message 19 Sat Jul 09, 1994 CBM-ED [e.g.bell] (Forwarded) Fred: FS> The reason I didn't find it was because I did not follow your FS> instructions. You suggested printing out the assembly I kind of suspected this would turn out to be the problem because I've had it happen to me before with another person. Glad you got it working tho, which is the most important part! ------------ 5 ? ************ Topic 12 Sun Jan 29, 1995 T.FARRELL5 [12Paws] (Forwarded) Sub: Can't format these disks! 4 message(s) total. ************ ------------ Category 5, Topic 12 Message 1 Sun Jan 29, 1995 T.FARRELL5 [12Paws] (Forwarded) I got a bunch of used disks from a guy at work. These were used commercially in the auto business. I do not know what type of computer they were used on. I tried to format them with Super Snapshot v4-no good. I get a read error Then I tried my 128D w/ jiffydos-same thing. I loaded up a c-64 utility (omega-q) and tried, but I got a write protect on error (no write protect is no [D [Don). I trien to format them with my warpspeed cart.-no good again! I tried a c-64 pgm called diskmaster-again write protect on error. How do I format these disks? ------------ Category 5, Topic 12 Message 2 Sun Jan 29, 1995 C128.JBEE (Forwarded) If the disks are high density (without hubs) or quad density (with hubs) you can not format them properly. Some older high density disks came with hubs, though you can usually format the disk. You just encounter read/write errors the more you use the disk and eventually lose the directory too. Some early DEC systems (RX series of drives?) came with the disks hard formatted and are unusable on any system. ------------ Category 5, Topic 12 Message 3 Tue Jan 31, 1995 T.FARRELL5 [12Paws] (Forwarded) Thanks, JBEE! I looked closely at the disks and there are no hubs. Guess I just got given a bunch of disk sleeves. Evev the 64 the fellow gave me comes up with "out of memory error in 0". Thanks again for the answer to my problem. ------------ Category 5, Topic 12 Message 4 Wed Feb 01, 1995 C128.JBEE (Forwarded) You're welcome :) ------------ ************ Topic 13 Wed Feb 01, 1995 D.TUOMI [Doctor] (Forwarded) Sub: BASIC I'm having a bit of a problem with a BASIC extension and would like some advise. 12 message(s) total. ************ ------------ Category 5, Topic 13 Message 1 Wed Feb 01, 1995 D.TUOMI [Doctor] (Forwarded) I have a rather nifty little subroutine that I discovered in a book. The routine extends basic with a new command: INPUT* lfn,len,var This command enables you to have an open channel on the disk drive and (lfn=logical file number) and specify the length of the string of data you with to input (len), and put into into a variable (var). Nice thing is that this routine will allow everything to come into the variable. I've actually written a file copier with just this single command extension! Only one problem with it. I have no idea how to shut it off. I need to be able to disable the command extension and return BASIC to normal. I'd like some advise on how to do this. From my reading of the M/L routine the initialization of this extension is this: 033C LDA #$47 033E LDY #$03 0340 STA $0308 0343 STY $0309 0346 RTS Looking at my handy Mapping the 64 I discover that locations $0308 and $0309 (dec 776-777) is the vector to the routine that executes the next BASIC token. This makes no sense to me at all. Why is this necessary. How is this routine managing to wedge itself into BASIC. And most importatnly, how do I get rid of it when I'm done?! As to the actual mechanics of the routine, when I got into it it basically checks the tokens for the INPUT command and the * (multiply) command. If the incoming token is by itself it jumps to the appropriate routine, but if they're together then the new routine is executed. Well, not being particularly experience in BASIC extensions, and not really ever seeing anything quite like this. I'd certainly appreciate any advise that anyone might be able to give. Doc. ------------ Category 5, Topic 13 Message 2 Wed Feb 01, 1995 C128.JBEE (Forwarded) This is going to be an interesting answer :) ------------ Category 5, Topic 13 Message 3 Wed Feb 01, 1995 E.GBELL [e.g.bell] (Forwarded) Doc: DT> I have no idea how to shut it off You have the idea... you just stopped short of getting it. You looked at the vector to see what it did. You should have looked at the default address of this vector, normally pointing to $a7e4. To turn the wedge off, just put that address back into addresses 776 and 777, in low byte/ high byte format. In other words, poke 776,228:poke 777,167. This will disable the wedge by taking it out of the execution loop of BASIC. DT> vector to the routine that executes the next BASIC token. DT> This makes no sense to me at all. Why is this necessary. DT> How is this routine managing to wedge itself into BASIC BASIC tokenizes its keywords into one byte each, which must then be evaluated. Your extension is checking for the INPUT token as you figured, and I guess the asterisk, to determine that it is the extended command. If it is not, your extension jumps to the normal $a7e4 address. If it is the new command, your extension does its stuff, exiting back at a normal re-entry place, which I don't know right at the moment. Put it like this. Your son drives the car every night to wherever he goes. You get an idea for a REALLY neat extension to his routine, whereby he sstops for gas when the GAS-FLAG=E. Since he does not have this programmed into his routine presently, he never stops for gas. However, wedge the routine in, and when GAS-FLAG=E, he stops for gas. If it does not see that flag, he never stops, even though the routine is active now. Is that a good example? There are a number of ways people have added routines to bASIC. That is just one of them. Some people wedge into the error vector, parsing commands that are syntactically incorrect, like DEEK, for example, and if the syntax error matches a new command list, the appropriate command is executed. bottom line is, the wedges are designed to recognize something unique about a line of bASIc code, and if found, execute the new command. If not found, they go on their merry way thru the normal routine, even as you found. I'm not too high on BASIC extensions for program mode because people who run your programs must have the extension installed, but did any of this explain what is going on and how to undo it? ------------ Category 5, Topic 13 Message 4 Wed Feb 01, 1995 M.RANDALL2 [Maurice] (Forwarded) Ed Bell, Correct me if I'm wrong Ed, because I've never messed with wedging a routine into the vector at $308,$309. But it would seem that if this vector is changed from within BASIC, that you would most likely crash before the second byte of the vector is altered. The first poke would be successful, but when BASIC attempts to evaluate the next token which would be the second poke, the address in the vector would be way off since the second poke has not yet occured. Am I right on this? If so, then the only way to change this vector would be through machine language, just like it is done within the routine that Doc is using, he just needs a similar routine for putting the vector back. There is also a routine built into the BASIC rom that will restore all of the BASIC vectors. SYS 58451 will do the job. You know something? Jumping straight into the operating system like this is considered to be a no-no. That is why we have kernal jump tables so that future upgrades to the operating system will be compatible with existing software. Do you suppose that SYS 58451 will not work when Commodore upgrades the operating system in the 64? Just wondering... (and being stupid) ------------ Category 5, Topic 13 Message 5 Thu Feb 02, 1995 D.TUOMI [Doctor] (Forwarded) I did try to change the vector back to the original value. It, as Maurice stated crashed out the computer. The funny thing is that when I wrote the routine into M/L, it had no effect. True, I could put the default numbers back in there, but it didn't disable anything. The routine continued working whether the vector was changed or not. This is the part that is so mysterious to me, because I can't figure out HOW it still works. I must be doing something wrong. Doc. ------------ Category 5, Topic 13 Message 6 Thu Feb 02, 1995 E.GBELL [e.g.bell] (Forwarded) Maurice: MR> would seem that if this vector is changed from within BASIC, MR> that you would most likely crash before the second byte of the MR> vector is altered duhhhhhhhhh! Yes, of course you are right Maurice. It would have to be done from ML. MR> also a routine built into the BASIC rom that will restore all MR> of the BASIC vectors. SYS 58451 will do the job. He might not want to use that Maurice, since that would disable anything else that might have been changed. It might even affect JiffyDos, tho I can't say that for 100% certain. as far as jumping straight into system addresses, wonder what Fred Bowen would say about that, particularly in the light of Ramdos. :) DT> put the default numbers back in there, but it didn't disable DT> anything. The routine continued working whether the vector DT> was changed or not I'm inclined to say this is impossible unless there is something else that routine does that you did not see. Check the error vector at 768/769 too. Matter of fact, make sure all of the BASIC vectors are pointing where they did before you installed the wedge. If this is the only one you are using, try Maurice's SYS to reinstall them, or if you are fussy, write a routine to do it yourself. One way would be to store them all when you first run your program and recover them from there, which would make it easy to undo any future additions. If the vectors are at their original points, the routine cannot work. It will never get called... matter of fact, you should get syntax errors, which is why I said to check the error vector. Things may be getting trapped there too. ------------ Category 5, Topic 13 Message 7 Fri Feb 03, 1995 D.TUOMI [Doctor] (Forwarded) It indeed looked impossible, till I tried something. I disabled my RAMLink and tried my routine again. It worked like a charm. With the RAMLink out of the system the vectors could be changed and the I could disable the extension. I don't know why the RAMLink is interferring, but its the only logical explanation since my rotine does work correctly with it out of the loop. I did find that Maurice's SYS call worked with either the RAMLink in or out. Its probably what I'll use, as it seems to work correctly, and it doesn't disable JiffyDOS. Doc. ------------ Category 5, Topic 13 Message 8 Mon Mar 13, 1995 C128-QT.PIE at 17:59 EST I have an idea for a prg I've been wanting to create for some time. Since it will be my first REAL program, I'd like to stick to BASIC. Is there a routine available that will let me easily grab a KOALA pic and display it within my program? My program will be a shell program that I can use to create a sora demo which will contain a Koala and various text files. But, I'd like to be able to easily change the files displayed by this program. Does anyone understand anything I just said? <g> Any tips or pointers will be greatly appreciated ;) ------------ Category 5, Topic 13 Message 9 Tue Mar 14, 1995 D.BELTER at 04:04 EST Yep, I think so. What you want is to display a Koala pic from Basic, right? If I remember correctly all you have to do is lower basic top of memory and do a series of pokes. Blast, I can't seem to find the disk that the info is on. Someone should be able to tell easily. I know it was easy since I used to do in a couple of programs. ------------ Category 5, Topic 13 Message 10 Tue Mar 14, 1995 CBM-MARK at 19:21 EST Sherry, don't know if this will be of any help but file #9541 MULTICLR-2- KOALA is a basic program that saves a multicolor image on your C128 to a koala file on disk. I don't remember how well commented the program is but you might be able to 'reverse engineer' off of it to write a basic program that will read a koala file from disk and display it. ~~Mark~~ ------------ Category 5, Topic 13 Message 11 Tue Mar 14, 1995 C128-QT.PIE at 21:50 EST Thanks for the info, Mark ;) ------------ Category 5, Topic 13 Message 12 Thu Mar 16, 1995 CBM-MARK at 20:27 EST Don't know if that file will be much help but, you're welcome Sherry ;) ------------ 5 ?