Monitor for iSBC 8024

Please see embedded remarks below. Dick ----- Original Message ----- From: ajp166 &lt;ajp166(a)bellatlantic.netTo: &lt;classiccmp(a)classiccmp.orgSent: Sunday, October 29, 2000 11:54 AM Subject: Re: Monitor for iSBC 8024 It's the term "mailer" that confused me. compiler, have 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