29 Oct
2000
29 Oct
'00
4:54 a.m.
From: Richard Erlacher <richard(a)idcomm.com>
Unless your system is severely crippled your Email has an
editor that will allow your to strip the excess non relevent text.
Try it, make it easier to read on the other end.
What I
said (I thought) was that I don't want to fiddle with small-C to the
From: Richard
Erlacher <richard(a)idcomm.com>
Use the editor that comes with the mailer, please.
What??? > I havent a clue why you said that at all since the
origin of the
smallc-c
> compiler is 8080? I still have the original DDJ
articles with
sources.
extent of writing a new code generator for the
'HC11, 'HC05's,
805x-series,
PIC, etc, since Hi-Tech already has a code generator
for their compiler
for
No problem with that. But I thought the initial problem was testing a
bunch
of ISBC8020s? Where did all the other excess about other cpus come
into that?
each of those. It would be a BIG job to do that for
the Hendrix
compiler,
reduced though it is, since what's needed is a
general enough compiler
that
once I write a debug monitor based on some existing
model I already have
and
I wouldn't know, I did did the later version for Z80 with TDL opcodes.
know. It's not enough that the 8080 and Z80 are
already supported,
since
Also 8088 and maybe later.
I'll only need to use the 8080, which, BTW,
it's not obvious that the
Hi-Tech 'C' supports. As I said, if I'm going to wander into the
quagmire,
I avoid the quagmire and use asm.
the near future. I'm quite sure nobody is going to
hire me to generate
code
for the Z80 or 8080. I've been known to write code
in assembler as
well,
but haven't done anything for hire in about 10
years that has required
Z80
or 8080 coding.
While I understand the desire it's all outside the scope of the original
problem to test and apparently use a bunch of 8085 multibus cards.
Oh, z80 is still out there as Z180, Z380 and Rabbit for embedded
apps and CPU library cores in gate arrays.
Allison
30 Oct
30 Oct
1:31 p.m.
Please see embedded remarks below.
Dick
----- Original Message -----
From: ajp166 <ajp166(a)bellatlantic.net
To: <classiccmp(a)classiccmp.org
Sent: Sunday, October 29, 2000 11:54 AM
Subject: Re: Monitor for iSBC 8024
what this refers to is the fact that I've
used neither small-C or the
Hi-Tech compiler, and before I wade into yet another quagmire, for this
specific job, unless it leads me into a new tool that I can use later. Back
when these older tools were developed, there was no standard for 'C' and the
K&R "proposal" was seldom adhered to enough to allow one to rely on it.
What interests me about the HI-Tech compiler is that the thing supports the
'HC11, HC05, PIC, and TMS320 family. That's sufficient capability to
warrant the effort of learning it. The small-C would take a lot of work,
particularly since it's not written in a dialect of 'C' that is familiar to
me. I do, by the way, have the Mix-C compiler and its CP/M based
antecedent. I just realize, unlike lots of other, for some of whom it's
perhaps not yet the case, that I'm getting close to full capacity,
memory-wise, and I really don't want to learn yet another odd-ball compiler.
I'd rather do the job in assembler <sigh>.
The Hi-tech compiler, if the documentation is to be believed, doesn't have a
code generator for the 8080 and 8085, BTW. It's a pretty decent
possibility, however, "less-than-perfect" this compiler may be, if it were
to be fit to generate a "solution" to my problem, I'd use it. It's on
the
list, but I'm not ready to wander into the quagmire without an account to
which to bill the time, (yet). It's not that I need to have someone pay for
me to learn what I don't know, but I do need a motivation to start, and a
deadline makes the job get done. I haven't used one of these
8020-descendants for several years, but a debug monitor written in a dialect
that supports everything that I might soon use would serve as a motivator.
> I wouldn't know, I did did the later
version for Z80 with TDL opcodes.
I have a bunch of TDL stuff, but have never used
it myself.
> >know. It's not enough that the
8080 and Z80 are already supported,
> since
what for? There are native tools that are
completely useable.
> Also 8088 and maybe later.
> >I'll only need to use the 8080,
which, BTW, it's not obvious that the
> >Hi-Tech 'C' supports. As I said, if I'm going to wander into the
> quagmire,
> I avoid the quagmire and use asm.
> >the near future. I'm quite sure
nobody is going to hire me to generate
> code
> >for the Z80 or 8080. I've been known to write code in assembler as
> well,
> >but haven't done anything for hire in about 10 years that has required
> Z80
> >or 8080 coding.
> While I understand the desire it's all outside the scope of the original
> problem to test and apparently use a bunch of 8085 multibus cards.
> Oh, Z80 is still out there as Z180, Z380
and Rabbit for embedded
> apps and CPU library cores in gate arrays.
I don't see that as a justification for
paying attention to them. The 650x
core is out there too, only at 5-10 MIPS in a core and at about half that
pin-compatible version. The core is significantly smaller than the Z80
equivalent, though it's because it has fewer resources. Performance,
however, is considerably better. That might depend on how it's to be used,
however. The Rabbit is promising, but it's sole-sourced.
> Allison
From: Richard Erlacher <richard(a)idcomm.com
It's the term "mailer" that confused me.
From: Richard Erlacher <richard(a)idcomm.com
Use the editor that comes with the mailer, please.
What???
Unless your system is severely crippled your Email has an
editor that will allow your to strip the excess non relevent text.
Try it, make it easier to read on the other end.
What I said (I thought) was that I don't want to fiddle with small-C to
the
compiler,
> I havent a clue why you said that at all
since the origin of the
smallc-c
> compiler is 8080? I still have the original
DDJ articles with
sources.
extent of writing a new code generator for the
'HC11, 'HC05's,
805x-series,
PIC, etc, since Hi-Tech already has a code
generator for their compiler
for
No problem with that. But I thought the initial problem was testing a
bunch
of ISBC8020s? Where did all the other excess about other cpus come
into that?
>each of those. It would be a BIG job to do that for the Hendrix >reduced though it is, since what's needed is a
general enough compiler
>that once I write a debug monitor based on some existing model I already
have
2 Nov
2 Nov
8:59 a.m.
I think I can find an eprom or eprom image for a Monitor that works on the
SBC 8024A... Unfortunatly I don't have source.
It is for something called 'supermonitor'. Would this be helpful?
George Rachor
=========================================================
George L. Rachor Jr. george(a)racsys.rt.rain.com
Hillsboro, Oregon http://racsys.rt.rain.com
United States of America Amateur Radio : KD7DCX
On Mon, 30 Oct 2000, Richard Erlacher wrote:
Please see embedded remarks below.
Dick
----- Original Message -----
From: ajp166 <ajp166(a)bellatlantic.net>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, October 29, 2000 11:54 AM
Subject: Re: Monitor for iSBC 8024
what this refers to is the fact that
I've used neither small-C or the
Hi-Tech compiler, and before I wade into yet another quagmire, for this
specific job, unless it leads me into a new tool that I can use later. Back
when these older tools were developed, there was no standard for 'C' and the
K&R "proposal" was seldom adhered to enough to allow one to rely on it.
What interests me about the HI-Tech compiler is that the thing supports the
'HC11, HC05, PIC, and TMS320 family. That's sufficient capability to
warrant the effort of learning it. The small-C would take a lot of work,
particularly since it's not written in a dialect of 'C' that is familiar to
me. I do, by the way, have the Mix-C compiler and its CP/M based
antecedent. I just realize, unlike lots of other, for some of whom it's
perhaps not yet the case, that I'm getting close to full capacity,
memory-wise, and I really don't want to learn yet another odd-ball compiler.
I'd rather do the job in assembler <sigh>.
The Hi-tech compiler, if the documentation is to be believed, doesn't have a
code generator for the 8080 and 8085, BTW. It's a pretty decent
possibility, however, "less-than-perfect" this compiler may be, if it were
to be fit to generate a "solution" to my problem, I'd use it. It's on
the
list, but I'm not ready to wander into the quagmire without an account to
which to bill the time, (yet). It's not that I need to have someone pay for
me to learn what I don't know, but I do need a motivation to start, and a
deadline makes the job get done. I haven't used one of these
8020-descendants for several years, but a debug monitor written in a dialect
that supports everything that I might soon use would serve as a motivator.
> I wouldn't know, I did did the
later version for Z80 with TDL opcodes.
I have a bunch of TDL stuff, but have
never used it myself.
> >know. It's not enough that
the 8080 and Z80 are already supported,
> since
what for? There are native tools that are
completely useable.
> Also 8088 and maybe later.
> >I'll only need to use the
8080, which, BTW, it's not obvious that the
> >Hi-Tech 'C' supports. As I said, if I'm going to wander into the
> quagmire,
> I avoid the quagmire and use asm.
> >the near future. I'm quite
sure nobody is going to hire me to generate
> code
> >for the Z80 or 8080. I've been known to write code in assembler as
> well,
> >but haven't done anything for hire in about 10 years that has required
> Z80
> >or 8080 coding.
> While I understand the desire it's all outside the scope of the original
> problem to test and apparently use a bunch of 8085 multibus cards.
> Oh, Z80 is still out there as Z180,
Z380 and Rabbit for embedded
> apps and CPU library cores in gate arrays.
I don't see that as a justification
for paying attention to them. The 650x
core is out there too, only at 5-10 MIPS in a core and at about half that
pin-compatible version. The core is significantly smaller than the Z80
equivalent, though it's because it has fewer resources. Performance,
however, is considerably better. That might depend on how it's to be used,
however. The Rabbit is promising, but it's sole-sourced.
> Allison
From: Richard Erlacher
<richard(a)idcomm.com>
It's the term "mailer" that confused me.
From:
Richard Erlacher <richard(a)idcomm.com>
Use the editor that comes with the mailer, please.
What???
Unless your system is severely crippled your Email has an
editor that will allow your to strip the excess non relevent text.
Try it, make it easier to read on the other end.
What I said (I thought) was that I don't want to fiddle with small-C to
the
compiler,
> I havent a clue why you said that at all
since the origin of the
smallc-c
> compiler is 8080? I still have the original
DDJ articles with
sources.
extent of writing a new code generator for the
'HC11, 'HC05's,
805x-series,
PIC, etc, since Hi-Tech already has a code
generator for their compiler
for
No problem with that. But I thought the initial problem was testing a
bunch
of ISBC8020s? Where did all the other excess about other cpus come
into that?
>each of those. It would be a BIG job to do that for the Hendrix >reduced though it is, since what's needed
is a general enough compiler
>that once I write a debug monitor based on some existing model I already
have
8584
days inactive
8588
days old
2 comments
3 participants
participants (3)
-
ajp166＠bellatlantic.net -
george＠racsys.rt.rain.com -
richard＠idcomm.com