Programming old mc6800/6802/6808 mpu's

[Hugh]

Fortran is still going reasonably strong. However it wouldn't make it to my list of languages for programming video games in.

Right.

The implicit stack of C is a problem for the 6800 that Fortran doesn't have, but it has a lot of other problems. For example, Fortran native data-types are not natural for the 6800. You want most values to be one byte long in the 6800 -- that doesn't work in Fortran or C (I think that BDS C does work, but it isn't C). BOth languages tend to have large runtime systems that are inappropriate for this task (but there is a concept of embedded C; it has less runtime).

Really, for this application, assembly language is appropriate.

Besides, you are likely to have to fit in with reverse-engineered 6800 machine language.

If you don't understand 6800 assembler well enough to do the project it is unlikely that you could succeed anyway.

 

[patscc]

You can certainly use 1-byte types in C. The problem are the ANSI promotion rules, which you can either try to cast around, or use a compiler that lets you turn them off.
You can work around the stack issue by not using recursion, for example.
I'm not saying you should write a game in C, just pointing out that there's lots of stuff you can do if you want to use C.
patscc

 

[Chuck(G)]

Large runtime for FORTRAN, like C, is dependent upon what you use. Don't forget that you could compile and run FORTRAN on a 4K PDP/8 or even a 4K S/360 model 20, not to mention a 1620, 1401 or 709.

But yes, FORTRAN is generally implemented with a 16-bit integer type. In that sense, it's no different from C, BASIC or any other language. The old USA BASIC FORTRAN had very few statement types and was quite useful.

Although many early games were implemented using it (remember Chess 3.0 or Adventure?), the 6800 is a very underpowered chip even for its day.

 

[g4ugm]

I wonder what makes you say it was underpowered? It was released at almost the same time as the 8080 and I don't believe that it has any less power than the 8080. I found that it was easier to program as whilst it has fewer registers it does have an indexed address mode which only appeard on the z80.

I have also written X.25 communications software in Fortran 77. Horrible but doable witrh some assembler support routines.

Lastl;y don't over estimate the size of the "C" run time routines. If you don't support floating point then you can get them down very small...

 

[gcoville]

Another option to consider is a good macro assembler. I've used an assembler called "asl" for both some 6800 and 6502 noodling recently.
http://john.ccac.rwth-aachen.de:8000/as/

Be sure to get the latest "beta", as that's where all the recent fixes are. I did have some trouble with macros in the last "released" version 1.41r8

Gilbert

 

[Chuck(G)]

I wonder what makes you say it was underpowered? It was released at almost the same time as the 8080 and I don't believe that it has any less power than the 8080. I found that it was easier to program as whilst it has fewer registers it does have an indexed address mode which only appeard on the z80.

Shrug. Small register set most of all. memory-mapped I/O, strange peripheral protocol... Just look at all of the software that was written for the 6800--WordStar, Multiplan, COBOL, FORTRAN, PL/I... Oh wait, that was the 8080... :wink:

Don't get me wrong--I think the 5800 family makes a good microcontroller--but there was a reason that the world followed Intel and MOS Technology for personal computers and not Motorola's 6800. The 68K was a very different matter, however.

 

[carlsson]

I don't see much use running WordStar on a pinball game anyway. :lol:

Apart from which programming languages and development tools are available, I must reiterate that the user interface on a pinball game only will give room for so much variation and different games. Even though the original poster had a good understanding of memory maps, I think a hacked ROM or newly compiled code can only change the scoring, the order of hitting certain ramps and bumpers, how much bonus you get when you drop the ball and so on.

 

[g4ugm]

Shrug. Small register set most of all. memory-mapped I/O, strange peripheral protocol... Just look at all of the software that was written for the 6800--WordStar, Multiplan, COBOL, FORTRAN, PL/I... Oh wait, that was the 8080... :wink:

Don't get me wrong--I think the 5800 family makes a good microcontroller--but there was a reason that the world followed Intel and MOS Technology for personal computers and not Motorola's 6800. The 68K was a very different matter, however.

I think the 8080 the things that made the 8080 was S/100 bus and CP/M. These were much better than Flex and SS-50 bus. However SWTPC and TSC did well enough out of 6800 based systems and according to

http://en.wikipedia.org/wiki/FLEX_(operating_system)

That "C" Fortran, Basic and Pascal were all available, but I only ever had Basic and Assembler.

What is a pity is that I can't find any benchmarks to see how the machines compared. I only ever really used 6809 and Z80 based systems which isn't what we are comparing. I don't remeber much difference between these later two systems...

 

[Chuck(G)]

I viewed the Z80 as what the 8080 should have been, and the 6809 as what the 6800 should have been. But a few years back then, thanks to Moore's Law makes a ton of difference. Had Motorola come out with the 6809 earlier, they would probably have made a big splash. The 8085 in particular, was notable for what it wasn't--even to the extent of Intel not documenting really useful added instructions, making it even less attractive. Regardless, it still found its way into a bunch of equipment.

One of the big weaknesses that I found when looking at the 6800 instruction set was the lack of orthogonality in the register set. In particular, the X register seemed to be added as an afterthought. How do you get A or B into X or vice-versa without having to store either in memory and then load it into the other? That makes the indexed addressing feature a less flexible than one would otherwise have originally thought.

 

[patscc]

I had to think about this a bit, but I'd say it fits in with the gradual push towards a more RISC-like philosophy, starting with the MC68k family.
If this was indeed the hintergedanke, then the 6800's chief failing would be it was just too slow.
It would be interesting to see the first few paper designs of the MC6800
patscc

 

[JamesD]

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.

The 6802 is a 6800 with a different hardware interface (clock & power) that is easier to design for and results in cheaper designs. It is 100% compatible with 6800 software.

The 6800 does not support stack based languages like C well.
There was a Flex small C compiler, but I think it generated bytecodes that ran on an interpreter.
It's still pretty fast but I'm not sure it's fast enough for your application without at least some assembly code to support it.

The 6801/6803/68701 are all microcontrollers with the same CPU core plus some built in hardware. They run 6800 code but have built in hardware addressed in the first 16 bytes of the memory map.
The 6801 has built in ROM companies could order preprogrammed with their software.
The 6803 either has no ROM or had it disabled.
They all have some built in memory, but I think the 68701 had more than the other two.

There are several different DIP packages for these chips but none are not pin compatible with the 6800 or 6802. If the buss/clock interface is similar, then they could be adapted to replace the 6802, but I don't know off the top of my head.
The instruction set has been enhanced over the 6800 with a multiply, Add B to X, A&B registers can be combined to form a 16 bit D register, and many opcodes require fewer clock cycles.
Hitachi offers even faster/lower power versions of these chips (HD6303). Many opcodes execute in fewer clock cycles. All single byte opcodes that operate on a single register require 1 clock cycle. The multiply is 3 clock cycles faster than the 6801. It adds an eXchanGe D & X instruction and some bit test instructions.

The 6803 is easier to program than the 6800 and most code is smaller.

There have been commercial C compilers that supposedly support these CPU's, but I've never gotten ahold of any of them.

 

[JamesD]

...
The 6800 does not support stack based languages like C well.
There was a Flex small C compiler, but I think it generated bytecodes that ran on an interpreter.
It's still pretty fast but I'm not sure it's fast enough for your application without at least some assembly code to support it.
...

Fast compared to a typical BASIC interpreter. And I'd think a lot of assembly would be required.

 

[grantb5]

The closest I ever came was the Imagecraft C compiler for the 68HC11. Depending on generic the code generator is, it might work for 68xx, but not sure. Byte Craft might also have or had something. My experience with 8031 C compilers was very positive. They really have been tweaked to the nth degree and can compete with assembler very, very well. I'm working with a 6303 right now and would kill for an emulator or ICE for that.