Why did Hitachi waste a perfect oppertunity?

[Multijointed Monster Maker]

Not releasing any information about the 6309's upgraded features, so that the computer market overlooked it as "outdated" or "low end" when it was neither of the two?

[JamesD]

Not releasing any information about the 6309's upgraded features, so that the computer market overlooked it as "outdated" or "low end" when it was neither of the two?

I'd guess they thought Motorola might yank their license to produce it.

[Multijointed Monster Maker]

Not releasing any information about the 6309's upgraded features, so that the computer market overlooked it as "outdated" or "low end" when it was neither of the two?

I'd guess they thought Motorola might yank their license to produce it.

 

I guess if I worked at Motorola and seeing Hitachi taking our own design and using it to dominate us, I would get pissed off and sue Hitachi.

 

If Hitachi did a big ad campaign bousting it's "32-bit capabilities" and "multiplication and division" and "higher MIPS than 68000" and upped the Mhz, that would be a big threat to Motorola's market share.

[carmel_andrews]

well I do remember seeing somewhere that Motorola and Hitachi fell out over one of the 68k family of processors(i think the spat was sorted out and both parties continued producing that particular 68xxx processor)

[Multijointed Monster Maker]

If there wasn't the issue with Motorola, how would you think the 6309 would be used? I think it would've been perfect for a 16-bit videogame system, or maybe even some 90's arcade games, although it would require a lot of bankswitching. But I still think it would fit the arcade business over a lot of other cpu choices, due to it's overall speed and ease to program.

[JamesD]

I think it would have made it's way into a lot of CoCo's a lot sooner, possibly some arcade machines but only as a cpu driving sound effects and such like the 6809 was being used for.

 

FWIW, Hitachi also had a 6303 which was faster than the 6803 but they released info on it. But then they only optimized instructions and added a handful of new instructions (that we know of) to it.

[Multijointed Monster Maker]

Am I the only one who actually find the 6309 to be more powerful than a 68000? Just compare the cycle counts between multiplication/division, and bit shifting instructions and you'll see what I mean.

[JamesD]

Am I the only one who actually find the 6309 to be more powerful than a 68000? Just compare the cycle counts between multiplication/division, and bit shifting instructions and you'll see what I mean.

Yeah, but what MHz was the 6309 available in? 4MHz max?

The 68000 was probably available in a 16MHz version by the time the 6309 was released. Plus the 68000 has more internal registers so it doesn't have to load/save as many times as the 6309 would.

[Multijointed Monster Maker]

I don't want to piss people off, but I always had a thing against the 68000 for many reasons.

 

1) It started all the "bits and Mhz mean everything" marketing crap.

2) In colleges, if you ever questioned the authority of the 68000 you were expelled and weren't qualified to get a job as a programmer.

3) Everybody thought your supposed to program everything else like a 68000. I can't count how many times I deassembled a Super Nintendo game and saw something like this, "lda $00, add $02, sta $00, lda $00, add $04, sta $00" or like, "lda #$80, sta $00, lda $02, add $00, sta $02, lda $04, add $00, sta $04"

4) Programmers started thinking that using 32-bit instructions for everything made them "epic" or "elite" programmers.

5) Once programmers ran into a system that doesn't use a 68000, they start throwing tantrums like little cry babies. **cough**SNES**cough**

6) People thought that it had some kind of "magic" or "feel" in arcade games, like "OMG! look at how hard Ryu punched Ken thanks to the 68000 running this machine!"

Edited March 4, 2010 by Multijointed Monster Maker

[Multijointed Monster Maker]

Sorry, computer caused me to double post.

Edited March 4, 2010 by Multijointed Monster Maker

[JamesD]

I don't want to piss people off, but I always had a thing against the 68000 for many reasons.

 

1) It started all the "bits and Mhz mean everything" marketing crap.

2) In colleges, if you ever questioned the authority of the 68000 you were expelled and weren't qualified to get a job as a programmer.

3) Everybody thought your supposed to program everything else like a 68000. I can't count how many times I deassembled a Super Nintendo game and saw something like this, "lda $00, add $02, sta $00, lda $00, add $04, sta $00" or like, "lda #$80, sta $00, lda $02, add $00, sta $02, lda $04, add $00, sta $04"

4) Programmers started thinking that using 32-bit instructions for everything made them "epic" or "elite" programmers.

5) Once programmers ran into a system that doesn't use a 68000, they start throwing tantrums like little cry babies. **cough**SNES**cough**

6) People thought that it had some kind of "magic" or "feel" in arcade games, like "OMG! look at how hard Ryu punched Ken thanks to the 68000 running this machine!"

That sounds more like you have a personal vendetta against the 68000 rather than facts.

 

For what it's worth... I've never seen a 68K program that looks anything like that SNES code you give as an example.

One of the benefits of the 68K *which I already mentioned* was that you didn't need to constantly save load/save register contents. I've even seen a simple crappy 68K compiler generate better code than that.

[Multijointed Monster Maker]

It looks like programmers got so used to having 16 registers on the 68000 to work with, that once they were hired to work on the Super Nintendo's 65816 with only one register to do math with, they literally used it's direct page memory as if they were 68000 registers, with all kinds of unnecessary loading and storing.

 

At least the 6309 register set wasn't nearly as bad as the 65816's.

[JamesD]

It looks like programmers got so used to having 16 registers on the 68000 to work with, that once they were hired to work on the Super Nintendo's 65816 with only one register to do math with, they literally used it's direct page memory as if they were 68000 registers, with all kinds of unnecessary loading and storing.

You sure that wasn't just the output from a poor C compiler? That's really ugly.

 

At least the 6309 register set wasn't nearly as bad as the 65816's.

The register set of the 65816 is almost a clone of the 6809... but the devil is in the details as they say.

It's not the registers so much as how they can be used that is the problem.

The 6809/6309 have 8 and 16 bit oriented instructions where the 65816 has 8 and 16 bit modes for registers.

You can alternate between 8 and 16 bit instructions from one to the next on the 09 but not on the 816.

And B isn't quite as useful on the 816 due two a few less instructions to manipulate it.

 

One problem I have with the 6309 is register order. I spent some time working on a 6809/6803 code generator for a C compiler. With A and B requiring less cycles than the two new 6309 accumulators (E & F) it makes sense to use A & B most with a C compiler. But since the new registers form the least significant 16 bits, it makes conversion from 8 or 16 bit numbers slower than they needed to be. If the 6309 were little endian... it would work great, but the 09 is big endian.

That would only happen when you typecast something between 8 or 16 bits and 32 bits, but it's uglier than it needed to be. I doubt the engineers were thinking of how a compiler works when they added the new registers. It's probably a moot point anyway if you start allocating registers since any of them could get typecast to a different size. But if I were to implement a 6309 today I'd change that.

[Multijointed Monster Maker]

I can imagine the connected-register archetecture to allow some very clever tricks. Such as using D as a sprite's y-coordinate, and W as the sprite's y-coordinate, and manipulating both x and y coordinates at the same time by using Q, or individually with D and W.

[JamesD]

I can imagine the connected-register archetecture to allow some very clever tricks. Such as using D as a sprite's y-coordinate, and W as the sprite's y-coordinate, and manipulating both x and y coordinates at the same time by using Q, or individually with D and W.

Well, on the 6803 and 6809 I've used D to load separate variables into A & B at the same time.

I've also used D to write to two hardware registers with one instruction.

A little creativity with variable placement can save a few clock cycles just by doing that.

 

I really haven't done much with 6309 specific code so I can't be sure, but many 6309 opcodes are two bytes rather than one so they might not offer as much of a speed boost as you think.

It's the same reason you use X and the user stack pointer before Y whenever possible. Y requires two byte opcodes.