Forums

buffalo in chip

Started by sergioheta April 5, 2005

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 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?

thanks in advanced

Sergio


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


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 ---------------------------------



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!



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!





>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 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.



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!


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!