A couple MC6809 questions

[metertech58761]

When I began working on a project (currently on indefinite hold) to duplicate a piece of test equipment, one of the first things I needed to do was to find a substitute for the unobtainium industrial MC6801 variant at the core of this piece of equipment.

I had considered the MC6809, but the literature for that MPU left me with the impression that I would have to rewrite the 6801 assembly code to run on the MC6809, which is what eventually led me to attempt to design based on the HC11 MPU instead since it uses the exact same instruction set.

I recently came across another bit of data that suggests that 6801 code WILL run as-is on the MC6809, I just need to tell the MPU where in memory the range to be accessed via direct mode (zero page) is.

So which is right? Mainly asking out of curiosity at this point (since 6809s appear to be slightly easier to get than HC11s these days).

On the off chance I would attempt to redo my attempt at redesign using a MC6809 / MC68A09 / MC68B09, how would one use an external clock with this? The original industrial 6801 variant MPU was run from the same 1MHz oscillator used by the rest of the system.

The HC11 requires a clock running at 4x system frequency (which means a 4MHz oscillator), and the 1MHz signal to the rest of the system is fed from the E pin on the HC11.

It looks like the MC6809 has the same divide by 4 clock requirement? Or, is it possible to set it up to run directly from the main 1MHz clock?

[brucehoult]

I recently came across another bit of data that suggests that 6801 code WILL run as-is on the MC6809, I just need to tell the MPU where in memory the range to be accessed via direct mode (zero page) is.

So which is right? Mainly asking out of curiosity at this point (since 6809s appear to be slightly easier to get than HC11s these days).

I just started to have a look at opcode tables for 6801 and 6809. Yes, a lot is the same.

But the very first 6800/6801 instruction, ABA A+B -> A opcode 1B is an unused opcode on 6809.

If you write ABA in 6809 assembly language then the assembler outputs:

Code: [Select]

PSHS B
ADDA ,S+

So 6809 is assembly language compatible with 6800/6801 but not binary compatible.

Other instructions that are simulated in a similar way on 6809:

6800: CBA CLC CLI CLV DES DEX INS INX SBA SEC SEI SEV TAB TAP TBA TPA TSX TXS WAI

6801: LSRD PSHX PULX LDAD STAD

[srb1954]

When I began working on a project (currently on indefinite hold) to duplicate a piece of test equipment, one of the first things I needed to do was to find a substitute for the unobtainium industrial MC6801 variant at the core of this piece of equipment.

Have you considered the 6803? This is the same as a 6801 but without the internal ROM. Since the 6803 is a standard part it should be more readily available on the market. The 6801, having an internal mask programmed ROM, would only be made to custom order and would not generally find its way onto the open market. I believe Hitachi also did a CMOS version of the 6803, the 63C03.

I had considered the MC6809, but the literature for that MPU left me with the impression that I would have to rewrite the 6801 assembly code to run on the MC6809, which is what eventually led me to attempt to design based on the HC11 MPU instead since it uses the exact same instruction set.

I recently came across another bit of data that suggests that 6801 code WILL run as-is on the MC6809, I just need to tell the MPU where in memory the range to be accessed via direct mode (zero page) is.

So which is right? Mainly asking out of curiosity at this point (since 6809s appear to be slightly easier to get than HC11s these days).

The 6809 is nearly source code compatible with the 6801 but is not binary code compatible so you couldn't just copy an EPROM and expect it to run on the 6809. To run the 6801 program on a 6809 you would have to reassemble the assembly language source code into a new 6809 binary. The 6809 assembler automatically converts some of the special function op-codes from the 6801 into the more generalised functions available on the 6809 architecture.

You don't have to worry about setting the zero page location as, by default on power on, the 6809 uses the same zero page as the 6801/3.

What you will have to worry about is whether the 6801 uses any of its internal peripherals such as the RAM, timer and I/O ports. None of these exist on the 6809 and will have to be implemented in external H/W. Also the 6801/3 has several operating modes ranging from single chip mode where the address and data buses are not externally accessible through to the expanded multiplexed mode where the full 64K of the address space is externally accessible. Only the expanded multiplexed mode is compatible with the 6809 although even that may not function correctly with external peripheral chips that connect using the multiplexed address bus; the 6809 has a non-multiplexed address bus.

On the off chance I would attempt to redo my attempt at redesign using a MC6809 / MC68A09 / MC68B09, how would one use an external clock with this? The original industrial 6801 variant MPU was run from the same 1MHz oscillator used by the rest of the system.

The HC11 requires a clock running at 4x system frequency (which means a 4MHz oscillator), and the 1MHz signal to the rest of the system is fed from the E pin on the HC11.

It looks like the MC6809 has the same divide by 4 clock requirement? Or, is it possible to set it up to run directly from the main 1MHz clock?

There is another variant of the 6809, the 6809E, that runs off an external 1MHz E clock but this also requires a external Q clock as well, which is most easily generated by dividing down from a 4MHz clock source. The 6809E variant is usually only used where two or more processors, or other type of bus master, need to be synchronised on a bus and requires additional external support circuitry. If you don't absolutely need to run the processor off an external 1MHz clock it is far easier to use the 6809 version and use its 1MHz E clock output to drive the rest of the circuitry, though suitable buffers if necessary.

I would persevere with looking for a 68HC11 as it will be far easier to port the application onto this processor family rather than the 6809. Remember, there are many different 68HC11 variants with different memory sizes etc so if you widen your search parameters you might find a suitable chip. Failing that you might want to look at the MC9S12 family which is the next generation upgrade from the 68HC11 family.   

[metertech58761]

Thank you - I couldn't recall what it was that I'd have to be cautious of in assembling for the 6809.

Of the above list of opcodes handled differently on the 6809, these make an appearance in the source:

ABA, CBA, CLC, CLI, DEX, INX, INS, SBA, SEI, TAB, TBA, LSRD, LDD, STD

At that point in the game, I had almost no understanding of the source code, so I had been slightly concerned about how much would need to change for compatibility
(not as concerned now, since I have attained a marginally better understanding of the code's functionality). Some, like the last three, would be almost trivial for me to adjust in the source before dropping it into a 6809 compiler.

As for on-chip features, this MPU variant had no built-in peripherals or RAM, and used the same package as the 6800 (the pinout is ALMOST the same - only pins 3, 38, and 39 differ).


Actually, given the above, it would probably be better to say the original MPU is a 6803 with pinout similar to the 6800, and is configured to always run in expanded mode.


So, yes, the HC11 remains the better choice - it was the -F1 variant I had tried to use (either I did not load the setup registers correctly or I missed something in my design).

But now that I have a sufficient understanding of the code, I believe it should be possible to recreate it in C++ so a modern programmable controller similar to the Arduino could be used.

Before I do that, I want to get an understanding of (and try to optimize the code for) the other piece of equipment used in this system so the messaging protocol can be better understood.

I did look around for the MCS9S12, but I get the sense that it has gone out of production as well.

[rhodges]

I have some 6803 from surplus boards you can have. Let me know if you want some.

[Benta]

If your old circuit is running code from internal (mask) ROM, options could be MC68701 or HD63701 EPROM versions. Very likely also unobtaineum, but being standard products you might get lucky.
I wouldn't consider the 68HC11, too mant CPU differences. MC6809 I can't say.

[brucehoult]

Thank you - I couldn't recall what it was that I'd have to be cautious of in assembling for the 6809.

Of the above list of opcodes handled differently on the 6809, these make an appearance in the source:

ABA, CBA, CLC, CLI, DEX, INX, INS, SBA, SEI, TAB, TBA, LSRD, LDD, STD

At that point in the game, I had almost no understanding of the source code, so I had been slightly concerned about how much would need to change for compatibility
(not as concerned now, since I have attained a marginally better understanding of the code's functionality). Some, like the last three, would be almost trivial for me to adjust in the source before dropping it into a 6809 compiler.

If you have the source code and will be re-assembling it then YOU DON'T HAVE TO WORRY. The 6809 assembler implements all the above instructions -- just with bigger and slower code than the 6800.

[srb1954]

Thank you - I couldn't recall what it was that I'd have to be cautious of in assembling for the 6809.

Of the above list of opcodes handled differently on the 6809, these make an appearance in the source:

ABA, CBA, CLC, CLI, DEX, INX, INS, SBA, SEI, TAB, TBA, LSRD, LDD, STD

At that point in the game, I had almost no understanding of the source code, so I had been slightly concerned about how much would need to change for compatibility
(not as concerned now, since I have attained a marginally better understanding of the code's functionality). Some, like the last three, would be almost trivial for me to adjust in the source before dropping it into a 6809 compiler.

As for on-chip features, this MPU variant had no built-in peripherals or RAM, and used the same package as the 6800 (the pinout is ALMOST the same - only pins 3, 38, and 39 differ).


Actually, given the above, it would probably be better to say the original MPU is a 6803 with pinout similar to the 6800, and is configured to always run in expanded mode.


So, yes, the HC11 remains the better choice - it was the -F1 variant I had tried to use (either I did not load the setup registers correctly or I missed something in my design).

But now that I have a sufficient understanding of the code, I believe it should be possible to recreate it in C++ so a modern programmable controller similar to the Arduino could be used.

Before I do that, I want to get an understanding of (and try to optimize the code for) the other piece of equipment used in this system so the messaging protocol can be better understood.

I did look around for the MCS9S12, but I get the sense that it has gone out of production as well.

The 68HC11F1 variant would be harder to source these days as it was the least used of the 68HC11 variants. The -A8, -E9 and -E20 variants were the more commonly used variants.

All the 68HC11 variants are listed as end-of-life on the NXP web site but there still seem to be plenty of MC9S12 options that are listed as active on the NXP site. However, having something being listed as being in active production is not the same as getting your hands on one. Practically every microcomputer chip seems to be unobtanium these days.

[Benta]

The 68HC11F1 variant would be harder to source these days as it was the least used of the 68HC11 variants. The -A8, -E9 and -E20 variants were the more commonly used variants.

I hope you mean A0, A1, E0 and E1.
A8, E9 and E20 were mask ROM versions.

[metertech58761]

rhodges: Hmm. I'll keep that in the back of my mind.

Benta: Thankfully, the code resides on a 2764 (which I've long since dumped and converted back into source for analysis).

srb1954: I chose the -F1 as it was used on another of the boards used in this system later. However, as long as it has on-board RAM and enough I/O pins I'm willing to consider other HC11 variants.

[james_s]

The 6803 and 6801 rings a bell, I think there are some early solid state pinball sound boards that used the 6801, and some have made adapters to use a 6803 with an external ROM. Pretty sure I recreated one of them on an FPGA a few years ago.

[brucehoult]

rhodges: Hmm. I'll keep that in the back of my mind.

Benta: Thankfully, the code resides on a 2764 (which I've long since dumped and converted back into source for analysis).

srb1954: I chose the -F1 as it was used on another of the boards used in this system later. However, as long as it has on-board RAM and enough I/O pins I'm willing to consider other HC11 variants.

2764? 8 KB? How much RAM do you have? How much IO?

[metertech58761]

RAM: 256 bytes (including stack space) is plenty.

Yes, the firmware fits neatly onto one 2764 - actual code length is more like 5.5K

I/O: Three chip selects, 7 inputs, and three outputs.

[brucehoult]

RAM: 256 bytes (including stack space) is plenty.

Yes, the firmware fits neatly onto one 2764 - actual code length is more like 5.5K

I/O: Three chip selects, 7 inputs, and three outputs.

Hmm. So how would you feel about replacing that with a $0.12 48 MHz RISC-V chip with 2 KB RAM, 16 KB flash, with maybe 4 KB of the flash (maximum) containing a cycle-accurate 6801 emulator?

[srb1954]

The 68HC11F1 variant would be harder to source these days as it was the least used of the 68HC11 variants. The -A8, -E9 and -E20 variants were the more commonly used variants.

I hope you mean A0, A1, E0 and E1.
A8, E9 and E20 were mask ROM versions.

No mistake. The -E9 and -E20 versions were definitely available in OTP EPROM variants. Not so sure about the -A8 having an EPROM variant but I think is had an EEPROM variant.

[metertech58761]

brucehoult: Yeah? Definitely piqued my curiosity...

It would also be nice to replace the ancient 8279 keyboard / display driver. 4x4 matrix and I had thoughts of wanting to replace the 16-character display (ten 7-segment, six LED) with a 4x20 LCD.

[Kleinstein]

brucehoult: Yeah? Definitely piqued my curiosity...

It would also be nice to replace the ancient 8279 keyboard / display driver. 4x4 matrix and I had thoughts of wanting to replace the 16-character display (ten 7-segment, six LED) with a 4x20 LCD.

That would than be a full replacement with new software and one could use a modern µC of what ever flavor one prefers.

[metertech58761]

Kleinstein: I have been considering doing just that anyway, now that I have a general understanding of what each module in the code does.

Right now, though, I'm trying to analyze the other piece of code I have at hand - while the code spoken of earlier was merely badly written, this other code I'm trying to pick apart is a big plate of spaghetti (they used a snot-ton of BRA / JMP and abused the [censored] out of the indexed mode to squeeze 5K of code into 4K).

When I'm ready to move forward, I'll begin a new thread as I want to pick a hardware platform, start with the GUI code (display and keyboard), and then move on to the individual test steps.

[Benta]

Right now, though, I'm trying to analyze the other piece of code I have at hand - while the code spoken of earlier was merely badly written, this other code I'm trying to pick apart is a big plate of spaghetti (they used a snot-ton of BRA / JMP and abused the [censored] out of the indexed mode to squeeze 5K of code into 4K).

Heheheh... memory was expensive back them, all tricks were OK. I remember the times.

[brucehoult]

brucehoult: Yeah? Definitely piqued my curiosity...

It certainly seems doable. Or with a Cortex-M0. But the RISC-V CH32V003 seems to be the the price leader in 32 bit flash-based MCUs.

The biggest issue would be that (like any modern microcontoller) the address and data buses are purely internal to the chip, so if your 6801 has external busses (using a 2764 ROM means it must have) AND you have things other than RAM and ROM hanging off that bus then those things need to be emulated too and brought out to GPIO pins. If it's just a 6820 then that's easy enough.

It would also be nice to replace the ancient 8279 keyboard / display driver. 4x4 matrix and I had thoughts of wanting to replace the 16-character display (ten 7-segment, six LED) with a 4x20 LCD.

If you're doing all that then that's a code rewrite and, yeah, translating it to C and compiling it for whatever modern CPU you want would be the better idea.

I see there is a commercial tool, Relogix, for converting assembly language to C. They seem to think they have good products for IBM 360, 68k, x86, 8051, PIC, and 6502. They also mention Z80, AVR and 68xx as being possible, perhaps as a service not as a product you can buy and use youself.

Sadly, their pricing page doesn't actually give any prices.

[Kleinstein]

A point with a really moder µC can the the voltage, as the 32 bit ones are usually 3.3 V with only 5 V tolerant in parts, but not giving 5 V out. Some 8 bits types (8051, AVR, PIC) are still 5 V.

With different (e.g. µC internal) periphery the SW would need a rewrite anyway. So more than just a simple translate from ASM to C.

[brucehoult]

A point with a really moder µC can the the voltage, as the 32 bit ones are usually 3.3 V with only 5 V tolerant in parts, but not giving 5 V out. Some 8 bits types (8051, AVR, PIC) are still 5 V.

The WCH ones I mentioned (specifically the 10c-12c CH32V003) operates at either 3.3 or 5 V and the GPIO operates at the supply voltage:

https://www.eevblog.com/forum/projects/improved-performance-5v-arduino-nanomega-compatible/25/

With different (e.g. µC internal) periphery the SW would need a rewrite anyway. So more than just a simple translate from ASM to C.

Yes. That's where an actual emulator that also emulates old peripherals e.g. Moto PIA / MOS VIA / Zilog PIO would be good. Or even just a library.

[rhodges]

The biggest issue would be that (like any modern microcontoller) the address and data buses are purely internal to the chip, so if your 6801 has external busses (using a 2764 ROM means it must have) AND you have things other than RAM and ROM hanging off that bus then those things need to be emulated too and brought out to GPIO pins.

A couple decades ago, I faced a quantity of "large" and cheap 215 LCD modules that could replace our expensive 213 displays. But, the 213 had a decent controller and the 215 did not, just row or column drivers. So I went on a project to create a controller for those boards. I ended up with a Z80 that "executed" the rather worthless register to register instructions that occupied one fourth of the total instruction set. So a display refresh would be a call to a long list of these "useless" instructions that exterior logic would clock into the LCD.

Yes, this was really mangled. But at the time, it was the cheapest way to feed an LCD without a controller.

[brucehoult]

I ended up with a Z80 that "executed" the rather worthless register to register instructions that occupied one fourth of the total instruction set.

That might well have been more opcode space than they really warranted, but at least they were somewhat useful.

Maybe ld to and from A could have been in the main opcode page, and the full orthogonal set in a secondary page. But that would be if the Z80 was designed from scratch. The 8080 didn't have secondary opcode pages. If designed from scratch, I'd also put 16 bit moves between {BC,DE,HL, and M/(HL)} in the main page.

If you want to see a complete waste, SPARC uses 25% of the opcode space -- all instructions with 01 in the MSBs -- as CALL which, with instructions 4-byte aligned -- means the 30 bit address allows calling a function anywhere in the 32 bit address space with a single instruction.  Modern RISC ISAs more sensibly allow a single-instruction CALL to functions within ±1 MB or 4 MB or 16 MB of the current PC, and the rarer calls to something further away require multiple instructions -- generally two instructions for something within ±2 GB, or loading a 64 bit address from a constant pool into a register and then an indirect jump via the register for arbitrary calls.

[metertech58761]

I'm getting ahead of myself, but the I/O lines break down so:

Four are for sensing a relay closure (I would probably want to move those behind a set of optos). Two drive relays (one is more a 'dry' closure to put the unit under test in test mode while the other switches the analog board between transmit / receive). One is the output data stream, so if I use a 3.3V CPU, I'd need to level-shift to 5V, and I'd need to level-shift in the other direction for the input data stream. Two existing I/O lines would be eliminated  - one changing to a software flag (select one-way or two-way unit tests), and the other would be eliminated by hardware change (a flag line from the 8279 to indicate a key has been pressed).

The devices currently hanging off the external address / data bus are the 8279 (keyboard / LED displays), MC6821 PIA, external RAM (two physically separate ranges thanks to partial decoding), ROM, and the MC6840 PTM (all 3 channels used - programmable delay, receive clock, and transmit clock). The 8279 I would replace with a matrix keyboard tied directly to the PLD and an I2C LCD, the PIA would be replaced by direct I/O to the PLD, RAM and ROM would move to internal space on the PLD, and that would just leave the PTM as one of the remaining riddles to solve.

But as I said, I'm not ready to get back into that part of the project yet.