1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

C cross-compiler for 6800 (yes, you read correctly)

Discussion in 'Embedded' started by CTH, Feb 10, 2014.

  1. CTH

    CTH Guest

    Hi All,

    Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...

    Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.

    I'm hoping for something that'll run under DosBox at least - although I'm guessing that the 6800 was already way obsolete but the time PC/MSDOS emerged.

    Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?

    CTH, Feb 10, 2014
    1. Advertisements

  2. CTH

    dp Guest

    The HC11 has more registers and opcodes, code for it won't run on
    the 6800. 6802 was 6800 compatible, I think 6801 also was but I am
    not sure, never used it. I never used the 02 either but did clone/extend
    a kit (D5) for the 6802 on a 6800.

    I am not sure there has ever been a C compiler for the 6800, I'd be
    surprised if there has been one really. Would have been quite useless
    for those tiny systems anyway.
    My programming started using pencil and paper to write the assembly
    code, then manually assemble it using the processor manual then enter it
    into my kit, debug and run :D . I think I can still read some 6800 object
    code :D :D .

    dp, Feb 10, 2014
    1. Advertisements

  3. ISTR there were minor differences between 6800/6802 and 6801/6803.
    It was easy enough to write code that would run on either but you
    had to watch out for the odd exceptions both ways. It was when
    you got up to the 6809 and its derivatives that 68xx compatibility
    completely went out of the window.

    Returning to the OP's issue I have hazy memories of coming across
    a Small-C derivative for the 6800. I probably have a copy of it
    around somewhere but it'll suffer from all the limitations Small-C
    always had - K&R syntax, no floating point, no structures, only
    single dimensional arrays. Dave Dunfield's Micro-C targeted many
    processors of that vintage too and ISTR the source is a free download
    now. I know it targeted the 6809, can't remember about plain 6800,
    but it was designed to be easy enough to write new back ends for
    and the manual actually described what was needed in some detail.
    That wasn't much more capable than Small-C but did at least support
    multi-dimensional arrays.

    I'll have a look around my hard drive and see if I can find anything.
    Andrew Smallshaw, Feb 10, 2014
  4. I think the old (commercial) IAR HC11 compiler had option flags to
    generate 6800 code (suppress the HC11 specific instructions).
    John Devereux, Feb 10, 2014
  5. CTH

    Tauno Voipio Guest

    You're probably out of luck.

    The 6800 (6801, 6802, 6803) is very tight on data handling
    paths: there are two 8-bit accumulators (A and B) which must
    be used for nearly all data moving. There are also two
    16-bit registers, X and SP, but due to their special uses,
    they are less usable. IMHO, compiling C for this architecture
    is at least challenging.

    The first 680x processor suited for running C is 6809. The
    68(HC)1x are its successors.
    Tauno Voipio, Feb 10, 2014
  6. CTH

    Tom Gardner Guest

    Not at all.

    The current atmega devices are equivalent to a 6800, except
    they have a /less/ pleasant architectures for C programs.
    Most people program them in C, using a cross compiler.

    But in the early 80s cross-compilers were a luxury: most
    people used *self-hosted* compilers.
    The major "challenge" I found was that, on a CP/M-Z80
    system with two floppies, there was barely enough space
    for the compiler's symbol table.
    Tom Gardner, Feb 10, 2014
  7. Op Mon, 10 Feb 2014 09:56:08 +0100 schreef Tauno Voipio
    How is this different from the challenges of modern(!) STM8 processors?
    Boudewijn Dijkstra, Feb 10, 2014
  8. CTH

    MK Guest

    If you don't mind paying for it:


    (No idea how good)

    I never programmed 6802 or 6809 in anything other than assembler but we
    did several 68HC11 projects in C.

    BTW the 'hc11 is not a derivative of the '09, the '09 had additional
    registers and lea (load effective address) instructions which never
    appeared elsewhere.

    Michael Kellett
    MK, Feb 10, 2014
  9. CTH

    David Brown Guest

    Bytecraft have compilers for 6805 and 6808, if that is any help (I am
    not familiar with the 6800, so I don't know the details). Bytecraft
    tools are not cheap, especially if this is just a hobby, but they do a
    great job at a very difficult task. And I'm sure that if you email
    Walter Banks at Bytecraft, he will give you helpful advice.
    David Brown, Feb 10, 2014
  10. CTH

    David Brown Guest

    The AVRs (including the Mega) are a world apart from these old 8-bit
    accumulator-based designs. While they have a few C-unfriendly issues
    (too few pointer registers, poor stack addressing modes), they are far
    easier for C. There is a reason why there are several good AVR C
    compilers available in a range of price categories.
    Nobody self-hosted on a 6800.
    David Brown, Feb 10, 2014
  11. Killer for me was the separate code/data memory address spaces. #pragma
    PROGMEM and so forth. Putting some constant structures in flash ended up
    infecting most of the program with weird typedefs and special versions
    of library functions everywhere.

    I think in principle the compilers could have made all of this
    invisible, but none of them did AFAIK.

    CM3 is so much nicer now for most things.
    John Devereux, Feb 10, 2014
  12. CTH

    Walter Banks Guest

    As far as I know the only commercial C compiler for the 6800
    was part of the HP development system no longer produced or
    supported. This did indeed translate C into code that would run
    on the 6800 and that is about all that could be said for it.

    The 6800 was phased out before the availability of basic
    compiler technology needed to produce an asm competitive
    compiler for 6800. The 6800 evolved into 6811 and 6805. The
    6805 is a 6800 with a single accumulator and different codings
    for the ISA.

    The 6805 was our first C compiler project. The code generated
    for the 6805 will not run on a 6800.


    Walter Banks
    Byte Craft Limited
    Walter Banks, Feb 10, 2014
  13. CTH

    David Brown Guest

    Yes, that's another serious C-unfriendly issue with the AVR - no doubts
    there. But it's still /much/ better for C work than the 6800 or similar
    architectures, which was my point here.
    You can't make the memory spaces invisible to the programmer without a
    lot of inefficiencies, as it requires fat pointers. Compiler
    optimisations can perhaps reduce the overhead a bit, but it would still
    be there. But if you are happy to pay the price of 24-bit pointers, gcc


    Imagecraft had a different idea (at least when I used their AVR
    compiler, which was a long time ago) - they made "const" mean "flash".
    That let you write most C code in a natural way, and const data got put
    in flash. But it meant that converting a non-const pointer to a const
    pointer would cause disaster, which was a bad idea.


    The msp430 is probably the smallest cpu the is /really/ C friendly.
    David Brown, Feb 10, 2014
  14. CTH

    dp Guest

    Hah! Not to some extent may be, but I won't agree with the "at all" :).
    I have only a vague idea of the register model of the atmega,
    -is it unable to add 8bits (not to speak of 16) to a 16-bit register?
    -is it unable to access data relative to its sp so one has to
    constantly do tsx/txs (6800 lingo) and be able to access things
    only at an 8 bit fixed, unsigned offset from X after that?

    It the answers to these are "yes" we are closer to your
    "not at all" but still a long way from it - namely,6800 systems
    regarded a 2K EPROM as a huge space for an embedded project.
    It will take 20k to fit the equivalent C code using a C compiler - if
    you are lucky and if the compilers have become better than
    I expect them to be.
    On the 6809 under MDOS09 there was a pascal compiler. I played
    with it for a few months - I was learning the trade then.
    Man it was moaning and puffing with the floppies clicking the
    head load/unload for half an hour for not that long pieces
    of code :D :D . Was pretty good though (integer only), my main
    gain was to understand the difference between high an low
    level programming. Had enough time to think about it while
    waiting for the compiler :D :D. Basically high level is
    a good thing if the underlying architecture/register model is
    dirty/inconvenient and hiding it makes the programmer more
    efficient. I am glad I had the stomach to stay with architectures
    I did not find ugly and inconvenient (like the hugely popular x86 was,
    nowadays ARM which is not as ugly, just limiting). Cost me a fortune from
    a consumer point of view but the feeling when you look 20+
    years back and like what you see to a point you still want
    to keep on building on it is good, I suppose it is irreplaceable.

    dp, Feb 10, 2014
  15. CTH

    dp Guest

    Yep, I was about to post something in that sense but turned out
    I am not the only one here who remembers that :).

    I grew up on 6809 assembly, RASM09 / RLOAD were used a lot :).
    In fact I can still run them on an emulated th9 machine in
    a dps window, haven't done so for ages though
    ( http://tgi-sci.com/misc/sc09em.gif ).
    Last year or so I undug my first ever CPU board (early 80-s,
    done as a hobby project), here are its remnants (was 100% populated
    back in the day): http://tgi-sci.com/misc/grany09.gif . Was running
    MDOS09, it was the one I used to play with the pascal compiler
    I mentioned elsewhere (along with other boards on that bus).

    dp, Feb 10, 2014
  16. CTH

    Rich Webb Guest

    Imagecraft now uses "__flash" to indicate that an object is in the
    AVR's program memory space, so the overloading of "const" (which was
    handy but had pitfalls, as you point out) is no longer supported.
    There are also additional library functions (e.g., char *cstrcat())
    where the constant object is in flash.
    Rich Webb, Feb 10, 2014
  17. Yes sorry, drifted off the point there. Actually would be fine for most
    deeply embedded programs, I ran into trouble when trying to do GUIs with
    big constant structures like fonts and menus.
    Those must have come after I abandoned AVR for new
    development. Inefficient as you say.
    I thought that was standard behaviour for embedded, e.g. I thought the
    gcc toolchains put constants into a read-only segment that the link
    script puts in flash.
    I admit I under-use "const".
    Yes never tried it but would look into it if needed something really
    small/low power. Everyone had nice things to say about it. I seem to
    recall it did not have a proper gcc port when I would have been in a
    position to use it last, so I went with ARM.

    John Devereux, Feb 10, 2014
  18. Or from the 6502 ? [which has several compilers].

    George Neuner, Feb 10, 2014
  19. CTH

    dp Guest

    Was any of these any useful? I seriously doubt this has been the case
    but I don't really know.

    dp, Feb 10, 2014
  20. CTH

    Tim Wescott Guest

    It may be more profitable to look for an assembler, particularly if you
    want to be _really_ nostalgic.
    Tim Wescott, Feb 10, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.