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

I played a bit with CC65, which supports a subset of ANSI C89 (e.g. no floating point). The code it generates is quite different from what a competent 6502 assembly programmer would write. Having only one 8-bit accumulator, two 8-bit index registers and a 256 byte stack to work with makes 6502 a rather difficult target for a C compiler I guess. IMO C compilers for the 6502 are not very useful if you just want to reuse some C code not specifically written for this target. It might be somewhat useful if for some reason you have to use a 6502, have memory and performance to spare, don't feel like writing 6502 assembly code but are willing to write C code specifically for this target. I feel pretty much the same way about C compilers 8-bit AVR's, though for that target the GCC compiler can produce quite reasonable code if you keep the limitations of the 8-bit AVR in mind.

Reply to
Dombo
Loading thread data ...

Does the Motorola Exorciser not qualify ? ISTR it was built with 6800s.

Nick

--
"The Internet, a sort of ersatz counterfeit of real life" 
	-- Janet Street-Porter, BBC2, 19th March 1996
Reply to
Nick Leverton

I believe this was about a C compiler, I don't think there ever was one for MDOS and/or for MDOS09. Then there was the Exorset also, it ran a version of MDOS09 called XDOS. And there were numerous systems built to run MDOS and MDOS09, mine included - which mostly took some patches to the MDOS code and (at least for mine 2 machines) writing the firmware, the monitor at $f000-$fbff and the disk eprom at $e800-$efff.

The usable programming tools were called RASM (6800 relocatable assembler), RASM09 (same but for the 6809) and RLOAD (the linker for the above two).

The text editor took an Exorterm terminal, emulating that to a sufficient extent so the editor would run using the terminal board I had built was my first larger piece of code :-).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
dp

This particular kit has a CHIPOS interpreter in EPROM so it can be programmed that way.

In the 80s I managed to get it to receive (bit-banged) MIDI from a Yamaha DX7 by assembling in exactly the same way you describe!

Cheers, Chris.

Reply to
CTH

[snip]

I strongly suspected when I posted the original question that it'd be a long shot.

I appreciate your taking the time to look into it.

Cheers, Chris.

Reply to
CTH

Thanks John, I'll look into it.

Cheers, Chris.

Reply to
CTH

Thanks David, if all other avenues fail this might be a practical last resort.

Cheers, Chris

Reply to
CTH

Hi Walter. I did manage to turn up links that referenced the HP system you mention.

In reality, I suspected as much regarding your comments concerning availability of compilers in relation to the design-life of the 6800.

Thought it was worth a try...

Cheers, Chris.

Reply to
CTH

Hi Tim, I already have a couple of those ;-). They won't run in any cmd windows on modern Windows, but that's what DosBox is for (they're fine there).

It's a promising step that I can re-create the original 'Monitor' EPROM binary from a cleaned-up OCR of the printed asm listing in the scanned magazine article.

Cheers, Chris.

Reply to
CTH

Thanks Paul, I'll look into this!

Cheers, Chris.

Reply to
CTH

Elsewhere in this tangle of sub-threads, Walter Banks mentions that the

6811 is a superset of the 6800. So if you can find a new 6811 assembler you can just exercise a little bit of self-control, and use the 6800 part.
--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

The 6802 and 6808 (no onboard page0 memory not the later 6808 with a different ISA) were both 6800 compatible. The essential difference was it was much easier to interface to. Most of our 6800 projects were actually done with 6802's. The 6801 had some differences and both 6800 and 6801 were true subsets of the 6811.

If I were wanting to do a quick implementation of a C compiler for the 6800 I would probably start with a 6811 C compiler and strip out the code generation of the super set instructions or replace them with

6800 macros to emulate the additional instructions.
--
Walter Banks 
Byte Craft Limited
Reply to
Walter Banks

The Introl tool chain for the 68HC11 could generate 6800 code also.

Reply to
WangoTango

Uhm, yes but would still be somewhat painful - emulating a CPU on another one with fewer registers should be if not painful at least inefficient (one has to maintain the extra regs somewhere in system memory). My experience with emulation has been the other way, I did a source level emulation of the CPU32 on power (which is how my vpa started) and a binary emulation of the 6809 on power again; having the extra registers was a true blessing :-).

But then since you have done C for the *6805* I suppose a CPU being too small won't impress you much if at all :D.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
dp

Lets put it all in one place.

I agree with care the 6811 assembler could be used although there are some 6800 cross assemblers around..

The 6811 has a second index register (Y) , the 6811 could treat the A and B registers as a single 16Bit D register. The 6800 didn't have mul and divide instructions. The 6800 was missing most (maybe all) of the 16 bit compare instructions. The 6811 had several additional ways to use the index registers. Both the 6811 and 6800 instruction set documentation is online in multiple places including the original Motorola documentation.

I have just looked at both the 6800 and 6811 ISA documentation. Earlier I said I would start with a 6811 C compiler to create a 6800 compiler. This too would probably be quite difficult before it would reliably work.

w..

Reply to
Walter Banks

Thanks Tim, yes I saw that.

It's the 'self-control' part that might be a problem ;-)

Cheers, Chris.

Reply to
CTH

I was sure the 6800 had cpx # (remember the skip2 macro?... :-) ) but I was unsure about direct and extended addressing modes... Not remembering that felt too personal so I ran a try (using my dps emulated exorciser th9 emulation); they are there alright.

formatting link
.

IIRC cpx on the 6800 produced only the Z flag correctly though, so it was not a true 16 bit compare.

ROFL, can you believe we would be sitting discussing the 6800 after all these years :D . I seem to get some fun out of it, who would have thought. :D

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
dp

I'm amazed at the response too!

That's what I thought when I found my old kit, and started going through all the archived info ;-)

Cheers, Chris.

Reply to
CTH

Do I correctly understand that your 6800 box has 1k of rom and 2k of ram? It's not so easy to tell from the description. I guess that is comparable to some of today's 8-bitters that are routinely programmed in C. Even still it seems more in the retro spirit to program that machine directly in assembler, since it's so small.

Reply to
Paul Rubin

Yes, I am a big user of the "unofficial" port. There was a period when msp gcc was very much behind the state of the art - it was based on gcc

3.2.3 even though gcc was well into the 4.x line with a lot of new capabilities. We moved more to AVR chips at that time - the gcc support on the AVR's was not the only factor in that decision, of course. After the new gcc 4 support solidified (again, mainly thanks to Peter Bigot, but also due to many others over the years), I was happy again :-)

(I know that /you/ know the history here, and probably remember more details than I do, but others might be interested.)

That's my opinion too. I have worked a bit on a project using a 120 KB msp430, using CCS 3 (it was before gcc supported the larger memory spaces), and it was a complication I could happily live without.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.