> Sorry to reply yet again, but I found this: > > <http://community.the-underdogs.org/pub/tools/slowdown/tppatch.zip> > > which *claims* to patch Turbo Pascal (maybe not Borland?) and remove "Runtime error 200". On the contrary Mike, your help is greatly appreciated :) At least, someone is helping :) Thanks a lot :) > Another approach ... is to write or find your own loader. > It's not hard. I know I have seen a little S19 loader which fits into the EEPROM at $B600. It's also not difficult to send the standard "talker" and communicate with that. I won't mind, in fact, I wish I can have small directions about the steps on what to do... Actually, I'm not interested in debugging, I only erase and reprogram chips. And sometimes check the contents of EEPROM... Regards, Roger Tannous. > > Mike > > -- > p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} > I speak only for myself, and I am unanimous in that!

micro controller wrote: >>You might check Karl Lundt's home page for more information >> >> ><http://www.seanet.com/~karllunt/>. > >Karl's Program doesn't work on my PC, it generates the following >error: > >Runtime error 200 at 20FF:0091. > >I don't know why is that error generated !! I just copied >pcbug11a.exe to my pcbug11 folder, and issued the following command: > >pcbug11a -a port=1 > >Do you have any information why is that error generated ? > I downloaded tppatch.zip and tried it on my Linux box, running DOSEMU. First, I got an old copy of PCBUG342.EXE I had lying around, and put it on my Linux machine. I ran DOSEMU and ran PCBUG342.EXE, so I have a guaranteed original copy of PCBUG11, latest release. I then ran it, and got Runtime error 200. Good so far. I then pkunzipped tppatch.zip, and ran it. It supposedly does some checks, and it pronounced that it had properly patched the executable. I then ran it, and I got the so-familiar question "Is the talker installed on your board? (Y/N)" with no Runtime error 200. I pressed <ESC> and it exited just as I hoped. I have no idea whether it will actually work. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I speak only for myself, and I am unanimous in that!

micro controller wrote: >>You might check Karl Lundt's home page for more information >> >> ><http://www.seanet.com/~karllunt/>. > >Karl's Program doesn't work on my PC, it generates the following >error: > >Runtime error 200 at 20FF:0091. > >I don't know why is that error generated !! I just copied >pcbug11a.exe to my pcbug11 folder, and issued the following command: > >pcbug11a -a port=1 > >Do you have any information why is that error generated ? > Sorry to reply yet again, but I found this: <http://community.the-underdogs.org/pub/tools/slowdown/tppatch.zip> which *claims* to patch Turbo Pascal (maybe not Borland?) and remove "Runtime error 200". Anyway, I suggest you check out that site, as some of the stuff there claims to work well under Windows (which I presume you are using). Another approach (if all you want is to load your program, and not to use the debugging features of PCBUG11) is to write or find your own loader. It's not hard. I know I have seen a little S19 loader which fits into the EEPROM at $B600. It's also not difficult to send the standard "talker" and communicate with that. Then a very simple command-line parser would give you a debugger. That could be written in a day or so. (the parser, I mean) Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I speak only for myself, and I am unanimous in that!

micro controller wrote: >>You might check Karl Lundt's home page for more information >> >> ><http://www.seanet.com/~karllunt/>. > >Karl's Program doesn't work on my PC, it generates the following >error: > >Runtime error 200 at 20FF:0091. > >I don't know why is that error generated !! I just copied >pcbug11a.exe to my pcbug11 folder, and issued the following command: > >pcbug11a -a port=1 > >Do you have any information why is that error generated ? > Yes. The link library used by the old compiler that program was compiled with has a delay(millisecs) procedure in it. This is a subroutine intended to eat time with a loop. During startup, the library code first does some timing to calibrate delay() for the processor speed. If the processor is very fast, then the code divides by zero. Division by zero is "Runtime error 200". You might get some benefit from one or more of the programs at <http://community.the-underdogs.org/pub/tools/slowdown/> I used to use ATSLOW many years ago. I personally have not used anything downloaded from that site, so I don't know about possible virus infections and so on. You might need to load multiple copies into memory within your DOS box under Windows. I suggest you download one or more of the programs, scan for viruses/trojans, read the documentation, and select one of them to load. Start an MSDOS window, and follow the directions. The way these programs typically work (the way ATSLOW works, e.g.) is to hook into the timing interrupt chain (if I recall correctly, INT 8 is the hardware interrupt, which chains to a software interrupt 1C, and the software interrupt is what gets hooked). > > >>(2) the author refuses to rebuild using a later version of the >>compiler, and >>(3) the author refuses to release the source so someone else can >>work on it. >> >> > >Could this be because they want to push us using the currently >produced chips ? A-series chips are no longer produced... > Who is "they"? The author, as I understand it, was an independent contractor. PCBUG11 works fine with the later chips. It just won't run on a fast PC. >I considered using an HC08 family chip, but no HC908 chip I have >contains 3 input capture pins. >The only left chips are two HC912B32 which I didn't use and didn't >get familiar with yet. > >Regards, >Roger Tannous. > I find that BUFFALO satisfies my needs so far. I have had some problems with breakpoints and BUFFALO, so I don't use them. But otherwise, it does what I want. Have you considered getting a software simulator and using that? It might work for debug. I hear that Wookie is pretty good. I've never used it. Of course, you'll eventually need to program a chip :) Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I speak only for myself, and I am unanimous in that!

Hi all, Yes, this is a very common problem for programs written in Borland Pascal when running on fast (500 MHz and up) pentiums. Tnere is a routine that attempts to measure the CPU's speed, which ends up performing a divide by zero (runtime error 200) if the CPU is too fast. I believe the error can be corrected if you have source code, but otherwise there isn't any good solution. Good luck, Scott micro controller <microcontroller2002@micr...> wrote: >You might check Karl Lundt's home page for more information <http://www.seanet.com/~karllunt/>. Karl's Program doesn't work on my PC, it generates the following error: Runtime error 200 at 20FF:0091. I don't know why is that error generated !! I just copied pcbug11a.exe to my pcbug11 folder, and issued the following command: pcbug11a -a port=1 Do you have any information why is that error generated ? > (2) the author refuses to rebuild using a later version of the > compiler, and >(3) the author refuses to release the source so someone else can > work on it. Could this be because they want to push us using the currently produced chips ? A-series chips are no longer produced... I considered using an HC08 family chip, but no HC908 chip I have contains 3 input capture pins. The only left chips are two HC912B32 which I didn't use and didn't get familiar with yet. Regards, Roger Tannous. --------------------------------- Yahoo! Groups Links To --------------------------------- Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.

>You might check Karl Lundt's home page for more information <http://www.seanet.com/~karllunt/>. Karl's Program doesn't work on my PC, it generates the following error: Runtime error 200 at 20FF:0091. I don't know why is that error generated !! I just copied pcbug11a.exe to my pcbug11 folder, and issued the following command: pcbug11a -a port=1 Do you have any information why is that error generated ? > (2) the author refuses to rebuild using a later version of the > compiler, and >(3) the author refuses to release the source so someone else can > work on it. Could this be because they want to push us using the currently produced chips ? A-series chips are no longer produced... I considered using an HC08 family chip, but no HC908 chip I have contains 3 input capture pins. The only left chips are two HC912B32 which I didn't use and didn't get familiar with yet. Regards, Roger Tannous.

Hi Mike > I use the A-series parts with only 256 bytes of RAM. Which A-series part do you use nowadays ? and which tool do you use to program them ?:) I'm facing difficulties in programming an HC11A1 chip with PCBug11 on a windows XP machine :S Thanks in advance, Roger Tannous. --- In m68HC11@m68H..., Mike McCarty <Mike.McCarty@s...> wrote: > Herrera Sergio wrote: > > >Thanks a lot Mike, the information you gave me is just what i needed > > > > > You're very welcome. I saw that really, I couldn't answer your > questions, so I > tried to give you the information necessary for you to anwer them for > yourself. > > If you don't mind telling, what is your project, and what were your > decisions? > > I often find that for a small project the EEPROM at $B600, even > only being 512 bytes, is enough code space. I use the A-series parts > with only 256 bytes of RAM. By the way, you can use some of the timer > locations as extra RAM in single-chip mode. Let me see, it's the output > compare registers which can be used as additional RAM. That's 10 additional > bytes of RAM. I once wrote a single-chip program which filled RAM with > all $00, then > computed e = 2.718281828459045... to 190 bytes (the rest of the 256 > being used for > stack and copied code), then copied the result to the second half of the > EEPROM at $B700, then refilled RAM with $FF and redid the computation > and compared the results. If they matched, then success was declared. > The program > fit in the first 256 bytes of the EEPROM at $B600. I then wrote a second > program which > converted the stored results from binary to decimal. That is 457 decimal > digits. > > So a lot can go into 1/2K of code and 1/4K of RAM. In fact, I only used > 1/4K of code for each program. This was a project just to see what I could > accomplish with single-chip mode. The code was completely stand- alone, it > used no calls into BUFFALO. > > So a great deal can be done in 512 bytes of code and 256 bytes of RAM. > With an E-series > part, of course, you get even more RAM. The F-series gives you 1K of > RAM, which really > is quite a bit. > > Mike > -- > > p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} > I speak only for myself, and I am unanimous in that!

micro controller wrote: >Hi Mike > >>I use the A-series parts with only 256 bytes of RAM. >> > >Which A-series part do you use nowadays ? and which tool do you use >to program them ?:) > MC68HC11A1FN I picked up a bunch being thrown out one day, and have over 100 of them, many with BUFFALO. I generally use BUFFALO to program them. >I'm facing difficulties in programming an HC11A1 chip with PCBug11 >on a windows XP machine :S > Yes, you will. When I use PCBUG11, I use an old '486 machine with DOS 6.0 on it. Using a faster machine causes problems. You might check Karl Lundt's home page for more information <http://www.seanet.com/~karllunt/>. The problems are (as I understand it) three fold: (1) PCBUG11 is written in an old version of Turbo PASCAL and has code in it which is processor speed dependent in the library, (2) the author refuses to rebuild using a later version of the compiler, and (3) the author refuses to release the source so someone else can work on it. Anyway, the problem is with PCBUG11, not the chip. I have written my own programs to talk to them for other uses. For example, I am running a program on that PC I mentioned above which talks to a floating point package I wrote for the MC68HC11. It's doing pretty rigorous tests of the package, which includes a more than complete elementary transcendental functions package. By "more than complete", I mean that I used Cody & Waite for most of the functions, but added asinh() and acosh() to the package, using routines I designed myself. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I speak only for myself, and I am unanimous in that!

Herrera Sergio wrote: >Thanks a lot Mike, the information you gave me is just what i needed You're very welcome. I saw that really, I couldn't answer your questions, so I tried to give you the information necessary for you to anwer them for yourself. If you don't mind telling, what is your project, and what were your decisions? I often find that for a small project the EEPROM at $B600, even only being 512 bytes, is enough code space. I use the A-series parts with only 256 bytes of RAM. By the way, you can use some of the timer locations as extra RAM in single-chip mode. Let me see, it's the output compare registers which can be used as additional RAM. That's 10 additional bytes of RAM. I once wrote a single-chip program which filled RAM with all $00, then computed e = 2.718281828459045... to 190 bytes (the rest of the 256 being used for stack and copied code), then copied the result to the second half of the EEPROM at $B700, then refilled RAM with $FF and redid the computation and compared the results. If they matched, then success was declared. The program fit in the first 256 bytes of the EEPROM at $B600. I then wrote a second program which converted the stored results from binary to decimal. That is 457 decimal digits. So a lot can go into 1/2K of code and 1/4K of RAM. In fact, I only used 1/4K of code for each program. This was a project just to see what I could accomplish with single-chip mode. The code was completely stand-alone, it used no calls into BUFFALO. So a great deal can be done in 512 bytes of code and 256 bytes of RAM. With an E-series part, of course, you get even more RAM. The F-series gives you 1K of RAM, which really is quite a bit. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I speak only for myself, and I am unanimous in that!

Thanks a lot Mike, the information you gave me is just what i needed Mike McCarty <Mike.McCarty@Mike...> wrote:sergioheta wrote: >Hello >I have a school project and i have a doubt, hope someone could help >me >with this: > >wich hc11's have buffalo included in the micro, I recently bought a >mc68hc11e1cp2, i'm going to use the hc11 in expanded mode, so, should >I >include an extra eprom in the memory map with buffalo in it? > I'm not sure whether you are asking which versions of the 68HC11 have BUFFALO on chip. Anyway, it depends on what you want. It can be done either way. I have found that the on-chip version of BUFFALO is often 3.2, while I prefer to use 3.4 which has some nice features missing from 3.2. So even if I have BUFFALO on chip, I may use an external ROM. This can be controlled by using the ROMON bit in CONFIG at address $103F. In single-chip mode, ROMON is ignored, and the on-chip ROM appears in the memory map (in your case containing BUFFALO). In expanded modes, if ROMON is 1, then the on-chip ROM appears in the memory map and any external memory at those addresses is ignored, so you'd get the internal BUFFALO in your map. If ROMON is 0, then the internal ROM is not in the memory map in expanded modes, and you may use any external memory you like, including a later version of BUFFALO. That is what I do. I leave ROMON set to 0, and use internal BUFFALO 3.2 when I boot in single-chip mode, and use an external BUFFALO 3.4 when I boot in expanded mode. I leave the BUFFALO 3.4 external ROM in the circuit all the time. If you are satisfied with the version of BUFFALO you have on-chip, then by all means turn on ROMON and just run with that. In that way, you won't need an external ROM with BUFFALO in it. Another reason to use an external BUFFALO is that BUFFALO frequently overwrites location $4000. If you have RAM you are using there, then it will be clobbered. So I run with a patched 3.4 version of BUFFALO which leaves $4000 alone. The reason BUFFALO clobbers $4000 is that there was special hardware on the Motorola single-chip emulator boards which allowed one to use PORTD as one would on a single-chip product, but would switch PORTD to be used by the SCI when doing a download from the terminal. This special hardware was located at $4000. >I'm reading some manuals and i found out that if i use PE0 to control >buffalo, if i choose not to enter buffalo once it gets to adress >$B600 >i have to put a jump to an adress designated by me with possibly >another eprom with my program code, is this correct? Depends on what you want to do. BUFFALO checks PE0 and jumps to $B600. After that, you are on your own as to what you do. If your code is at $B600, then just run from there. If your code is somewhere else, then by all means jump to it. One thing to bear in mind... When you use PE0 jumpered to force BUFFALO to jump to your code, you have an essentially unitialized state. You have no stack set up, for example. So you can't make subroutine calls until you set your stack. The ADC is turned off. The SCI is disabled. Starting your code this way is significantly different from using the CALL command of BUFFALO. >thanks in advanced > You are very welcome. Mike --------------------------------- Yahoo! Groups Links To ---------------------------------