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

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

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

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

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.

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

Thanks John, I'll look into it.

Cheers, Chris.

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

Cheers, Chris

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.

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.

Thanks Paul, I'll look into this!

Cheers, Chris.

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 
http://www.wescottdesign.com

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

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

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

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

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

Thanks Tim, yes I saw that.

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

Cheers, Chris.

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.

.

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

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

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.

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.

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.