• Please review our updated Terms and Rules here

Programming old mc6800/6802/6808 mpu's

O

old8bit

New Member
Joined
Jul 4, 2012
Messages
7
Hi all:

I'm into pinball machines and have the dream of generating custom code for an old 1980's era pinball machine.
The particular machine uses an old Motorola 6802 processor. So here's the question... do I have to write in assembly or are there higher level language options? I've found C compilers for the 68hc11, 6801, 6805 and 6809 but nothing for a mc6800/6802/6802. I'm not surprised as the 6800/6802/6808 processors are much older but I'm hoping someone knows of something... Perhaps written by a hobbyist.

The other option is to find a newer cpu with a same or similar pinout but so far no dice on that either... any ideas?

Thanks!
Tim
 
If I read the Wikipedia article on the Motorola 6800 correctly the 6802 and 6801 share the same CPU. You might check the 6502 out as I believe it was intended to be pin-compatible with the 6800.
 
sprite9 said:
If I read the Wikipedia article on the Motorola 6800 correctly the 6802 and 6801 share the same CPU. You might check the 6502 out as I believe it was intended to be pin-compatible with the 6800.
Click to expand...

No--it's the 6501 that was more-or-less pin compatible with the 6800. The 6502 has a very different pinout, in response to a lawsuit filed by Motorola.

To the OP: I assume that you mean "cross-compiler". Some of the old toolsets ran on 6800 FLEX, which is not something I've ever seen on a pinball machine.

As to C for 6800-base machines, there were several vendors, Wintek, Introl, TSC all had C compilers. Avocet is still in business and still offers a C cross-compiler
 
Thanks for the replies... yes, I do mean cross-compiler... although I'm open to acquiring old hardware as well if that gets the job done.
I've checked a number of the C compilers and most do not directly support 6800/6808/6802. The closest I can find is support for 68HC11 which has a very similar but expanded opcode set. I assume the C cross-compiler might use some of the opcodes not supported by the 6800 and, therefore, this is close but no cigar.
It's tempting to try to find a MOS6501 and then use a 6502 compiler since the 6501 is pin compatible with the 6800 and the 6502 is software compatible with the 6501... but I probably wouldn't be able to find a 6501. : )
 
How much ROM space do you have in the pinball machine? Compiled C can be rather bulky, in particular on 68xx and 65xx systems that have very little or no natural stack, so the compiler has to create its own heap. The topic was discussed on the Tandy MC-10 mailing list last week. That is a 6803 machine, and I think that CPU has quite a bit in common with the 6800, 6801 and 6802.

If you want to get an idea about C compiler effiency, you can download the free cc65 compiler and e.g. the VICE emulator suite (or an Atari 800 emulator if you're rather into Atari than Commodore). Even if you're not a C64 fan, you can try to use that platform just to get a feeling how efficient code is produced.

Also, how much variation can you get in a pinball machine? Scoring certainly, perhaps counters for number of times you need to hit certain items but can you change the rules of the game completely while maintaining the same playfield? Besides, you would probably need a fair bit of documentation or at least disassembling the original ROMs to get anything meaningful out of your own code, no matter if it is handwritten assembly code or a compiled language. Actually, you might find the compiler touching memory addresses not meant to be touched (e.g. low RAM for system variables) and that would cause you more trouble than you gain.

I suppose you might be able to replace the original CPU with a daughterboard equipped with a different CPU, onboard RAM and perhaps secondary storage medium but that would be a rather big task. Again, that amount of work would only be useful if you can produce astonishing results with the pinball machine in the end.
 
Yes... this is probably more work than it is worth. I do have a very good understanding of the hardware so writing code should't be a problem... but it looks like I would have to do it in assembly. I have seen a mention of a few things that might work but, like you said, how custom could I really make it?
Thanks,
Tim
 
Don't forget the good old art of hacking existing ROMs! Many people on various platforms have created more or less personalized versions of existing games by binary hacking and patching the original ROM set. If you just want to change scoring, that probably would be trivial. Depending on ROM space, you might find room for patching in own routines although I doubt the manufacturers would've left a lot of unused space in a period when ROM was relatively expensive.
 
I guess I'm just surprised that there doesn't appear to be any way to prog the 6800 except in assembly. How did williams pinball crank out soo many games writing in assembly!? I guess it's possible though ... At least it wasn't punch cards ; )
 
Didn't I point you to a couple of C compilers?

Most programming was likely done in assembly, which wasn't at all unusual. We did everything in assembly back then--and don't count punched cards out completely for the earliest stuff. I certainly used them for early 8080 stuff, compiling on a mainframe. Intel had PL/M fairly early, but it was hideously inefficient at a time when memory was expensive. There were early BASICs, but they were mostly interpreted and slow.

My first exposure to C was around 1979, when I encountered Unix.
 
Hi Chuck... Yes, I looked at those compilers but from what I can tell none of them can handle the 6800. I emailed one of the companies that is still around and they don't think the 6800 was a good candidate due to its register design. I don't really understand the reasoning but I am greatful that they even put thought into the idea. I have found reference to a pascal compiler for the 6800 but cannot find a copy. It was put out by HP for their HP-UX systems circa 1981. Maybe the manufacturers used this ... Dunno. Wish I could find a copy to confirm that it could be used with the 6800. Thanks for your help.
 
Well, C is a lousy fit for most early microcontrollers. It can be done, but the code usually looks terrible. Here are some things to consider:

1. C uses as its basic computational unit, a 16-bit int. On systems where the 8-bit byte is the fundamental unit, that's an issue.
2. C pretty much requires the ability to maintain a stack for function-local data. Look, for example, at the 8080 CPU. It has a stack, but very few ways to manipulate it. If you want to do one of the simplest things, such as incrementing a local int, or in other words, the statement "i++;", you get code like this:
Code: 
	LXI	H,var_I		; get location within stack
	DAD	SP		; get absolute address
	MOV	E,M		; first byte
	INX	H		; bump address
	MOV	D,M		; next byte
	INX	D		; increment byte
	MOV	M,D		; store high order
	DCX	H		; back to low order
	MOV	M,E		; store low-order
The Z80 with its expanded instructions and IX/IY-relative addressing is quite a bit better, but still is no great shucks.

The lack of stack facilities was not considered to be all that unusual back then. A lot of big iron didn't have the facility, unless one could be synthesized. After all, how much code is actually recursive?

Recall, also, that in 1975, C was not that well known outside of the DEC community. So you found lots of BASICs (almost all were either directly interpreted from tokenized source or compiled P-code), the occasional FORTRAN, Pascal (mostly due to the hot trend of "structured programming", although to a lot of people that meant code without GOTO statements). There were pockets of FORTH (really, pretty logical as it doesn't require much to implement it) and around 1979 or so, DRI started its ISV program for developers based on, of all things, PL/I.

But assembly was the rule for low-level code that had to be fast.
 
Fascinating! I love hearing the history. Sometimes I wish I was born 20 years earlier....
 
I looked into writing C for my various 8085 projects. The BDS C compiler, which will make 8080 object code and runs under CP/M, was released into the public domain, so I played with that a little. I found that, for embedded projects, it was really quite a bit more efficient just to write in 8085 ASM. The 6800/6802 is somewhere on my "list of CPUs to build SBCs around" as well.
 
As long as you have a decent full text editor and cross assembler so you don't have to tap in hexadecimal codes one by one, programming in machine code isn't that cumbersome. Also, I'd expect Williams created a library of routines that could be reused and included into every new machine, as long as the hardware sensors, outputs etc were similar.

I looked up some typical amounts of ROM in those pinball machines. Hot Tip (Nov 1977) belongs to Williams System 3 and has 8K ROM and an empty slot! Jungle Lord (Feb 1981) is a System 7 with 10K code + 2K sound effects + 12K speech ROM. Laser Cue (Feb 1984) also is System 7 but without speech so 10K code + 2K sound ROM. Sorcerer (Mar 1985) is a System 9 with 6808 (optional 6802) and has 12K ROM code + 16K ROM sound effects + 16K ROM speech.

From my experiments with the cc65 compiler, which indeed is freeware and might not be the most efficient 6502 compiler that ever has existed, 8K is about the minimum executable size for any non-trivial program. Of course you wouldn't need to include any stdio printf and similar stuff so you might be able to trim down the compiler overhead. In the latter machines, you could probably cut down on the sound effects (assuming the CPU has access to those ROMs at all) and get some 20K space for own code.
 
Hi, i programmed for the MC6800 and for MC68HC11 on college a few years ago, for the MC6800, the tool used was an copy of the Heathkit ET3400, there's an windows simulator, named 6800 trainer that emulates the hardware and it's good to exercise some codes and to discover the instructions.

Unfortunately it's a very tedious task to program and reprogram EPROM or FLASH memories in order to debug your code, if you really want to do this, you will need an EPROM emulator hardware to do things faster.

In your place, i would prefer to do another PCB, and to use an modern microcontroller with ISP, so you don't have to take off the IC's in order to program, on an 8 bit AVR microcontroller with 16kB of FLASH, like ATMEGA16, it will take less than 20 seconds to reprogram your code, and, it have the GCC compiler, a very good compiler that i use on my projects.

C isn't a very good idea for the MC6800, the best is to do the programming by assembly, this CPU only have two accumulators, the code generated by compilers for CPU's like this are very large and slow, compared with the code done by hand using opcodes or assembly.

To do it on MC6800, the first thing you will have to do is to do the mapping of the peripheral addresses, looking at the schematic diagram of your PCB.

http://www.vintage-computer.com/heathkit3400.shtml

If you need some advice please contact me!
 
I think I might have a "Small-C" compiler about somehere that targets 6800 but its probably not much use as the generated code is huge. I think if you want compiled code it might be worth looking at Forth. A quick google throws up one or two links so I think you might find something.

Actually 6800 assembler is quite good to write once you have the hang of it. The fact is that the instruction set is pretty orthogonal, which means once you know a few instructions things kind of pop out quickly.
 
Dare I say it? FORTRAN is usually a good match for some of these old CPUs as it doesn't require a stack. The problem is finding a compiler...
 
You must log in or register to reply here.
Back
Top