68HC11F1 setup questions

[srb1954]

The original circuit used several 74xx gates to do partial decoding of the addresses. Trying to work out how to tweak the decoding to accommodate the the change from this bespoke MPU to the HC11 was complicated enough I thought about switching to a GAL, then I recalled working on some other boards in the past that used an EPROM for decoding.

I looked through my stash of EPROMs and it seems all of them are glacially slow at 200 or even 250nS. Rats.

Just use the programmable chip selects available from port G of the 68HC11F1. These require a little bit of startup code to set up the various registers controlling the chip selects but they are very versatile and allow clock stretching to cater for slow peripherals such as the 8279. Otherwise, clock stretching is not really feasible with the HC11 family and the only solution is to run the processor at a sufficiently slow speed to interface to the slowest peripheral chip thus causing a penalty to the overall system performance.

I noticed the timer section on the HC11, but am not sure of the feasibility of implementing it.

The 6840 is set up so Timer 1 is a programmable delay (1/16 second per count), Timer 2 generates a steady 2.439kHz signal (this is fed to the XIRQ line), and Timer 3 generates a switchable 12.5kHz signal (signal carrier).

The internal HC11 timer will handle these tasks but the operation of this timer is significantly differently and more flexible than the 6840 timer. The cost of this is that the HC11 timers require a bit of S/W to reset the timer after each output pulse if you are using them to generate a fixed output frequency. You need to study the user manual carefully to understand how the timing system operates.

Having interrupts at 2.439kHz is pretty fast for uPs of this vintage and will consume quite a bit of processor time in the interrupt handler. I would recommend increasing the main processor clock to 8MHz to ensure that sufficient processing power is available for the main application S/W. Operating at this higher speed will require faster external EPROMs and decoding logic. This will definitely rule out using an EPROM as a decoding chip.

Converting to a chip using internal program memory such as a 68HC711E9 avoids all the timing issues associated with external memory and can be run at full speed with no issues.

The 6821 has three lines under the interrupt routine's control (PA0-PA2), initialization signal (PA4 - output), contact closure checks (PB0-PB3), mode select (PB6), and keypress pending indication (PB7).

If some of these outputs are controlled in response to a timer interrupt their function might also be able to carried out by the timer subsystem in the HC11 reducing S/W overhead. Again, this requires thorough reading of the user manual to understand the capabilities of the timer system.

[metertech58761]

I'm beginning to wonder if I took on something well above my pay grade.

Just for laughs, here's the original circuits that I started with.

[DiTBho]

just checked, the uv eprom on the evb board is 70ns.

[newbrain]

The specific part for the 2732 is AM2732A-200 and the 2764 is MM27C64Q 200

Fine at 1 MHz, from a quick check of the timing diagram. Definitely not at 2 MHz.

I'll throw in a provocation: have you considered going on a completely different road?
How about using an AVR (a 328P might be enough!) or some other 5V (tolerant? STM32?) MCU?

The original FW must be rewritten in any case and:

• A modern MCU has much more power and flexible peripherals.
• No need to fuss with external memory
• Interface to specific peripherals (8279) can be bit banged through a GPIO port.
• Last, but not least, tools for a modern(ish) MPU are much more pleasant to use

That said, I also like tinker with vintage stuff...

[metertech58761]

I sure would like to 'port' the code to a newer platform, but there are parts that I can't quite get my mind around how to translate to C.

These parts involve 8-bit signed arithmetic, carry flag usage, and bit rolls.

[newbrain]

These parts involve 8-bit signed arithmetic, carry flag usage, and bit rolls.

So the original FW in assembly language is available - that's good.
I can understand that going the HW way with a largely similar MCU is appealing.
In any case, if you have only a few spots to clarify in ASM->C, eevblog denizens (me included, when possible) are usually more than willing to help - it's your choice.

[metertech58761]

I dumped the original EPROMs and used a program that converted the binary to assembly, and after reading through the code umpteen times, I was able to make reasonable guesses as to what a lot of it does.

Some sections, like where it converts between binary and BCD, I'm sure could be replaced with standardized code.

Okay. Gimme a bit to make sure the dump and my assembly cleanup are legible then I'll start a fresh thread.

[Benta]

Right.
Again, the main issue I have (HW-wise) is using NMI (6801 version) or XIRQ (68HC11 version) for timing. That's a total no-go and always has been. I don't know who designed this, but he/she would never get a job with me.
NMI or XIRQ are for catastrophic failures (eg, power fail). IRQ is for smooth, controlled execution.

[metertech58761]

I think the reason for using NMI in this case was so the receive / transmit code can run continuously in the background.

So if I stayed with the HC11, I would be better off swapping the connections for XIRQ and IRQ?

[DiTBho]

Unbelievable that Motorola didn't release cheap evaluation boards for K* and F*, but only for A* and E*

• EVB
• EVBU
• EVBU2

EVS and EVO were expensive, but with an hw debugger.

A "poor man" solution used with EVB for single stepping code debugging, useful for studying the HC11 instruction set and program operation, was connecting PA7 and /XIRQ together.

[newbrain]

A "poor man" solution used with EVB for single stepping code debugging, useful for studying the HC11 instruction set and program operation, was connecting PA7 and /XIRQ together.

Ah yes, same as it was done on the 6502 with Sync and NMI (through an inverter, possibly gated not to single step in the NMI routine itself).

[PCB.Wiz]

I sure would like to 'port' the code to a newer platform, but there are parts that I can't quite get my mind around how to translate to C.

These parts involve 8-bit signed arithmetic, carry flag usage, and bit rolls.

Did you look into  Tekmos parts  ? https://www.tekmos.com/products/microprocessors/68hc711-microcontrollers

If you have enough volume to port to a newer platform, usually you do not try to clone ASM lines to C lines.

I think you have functional ASM code that you can edit ?

If you have that,  you can move it to a more [library + asm] structure, while keeping functionality you need.
Then, those library calls can be simple C operators.

You then create a new version, with a focus on functional equivalent in C, rather than line by line equivalent.

If you have two working boards, this pathway is predictable.

I noticed the timer section on the HC11, but am not sure of the feasibility of implementing it.
The 6840 is set up so Timer 1 is a programmable delay (1/16 second per count), Timer 2 generates a steady 2.439kHz signal (this is fed to the XIRQ line), and Timer 3 generates a switchable 12.5kHz signal (signal carrier).
The 6821 has three lines under the interrupt routine's control (PA0-PA2), initialization signal (PA4 - output), contact closure checks (PB0-PB3), mode select (PB6), and keypress pending indication (PB7).

If you know what hardware timing you need, you can start a parallel development by doing that on a NEW MCU using C to init those new peripherals.

Is there anything here that really must be HC11 cycle-identical ?  (nothing above sounds cycle timing paranoid)

[newbrain]

DiTBho kindly asked me in PM how did I come to the conclusion that:

Fine at 1 MHz, from a quick check of the timing diagram. Definitely not at 2 MHz.

Hoping that the answer might be useful to someone else, I'll put it here, instead of a PM to them.

First, I got the timing diagram and values for the non multiplexed bus of the F1 from here, Appendix A (see Picture1 and 2 attachment).

Then I got the same for the EPROMS, see Picture 3 - this is for a 350 ns access time 2716, which is more conservative wrt the OP EPROM (300 ns).
Last I checked the 6840 timing, Picture 4.

Now I have everything I need.

We need to make timing requirements in Picture2 are fulfilled.

For reads from the FW EPROM to succeed, I look at the second falling edge of E and work backwards.

Setup time (17) is 30 ns at 2 MHz, let's be conservative and use 40 ns (as it seems to decrease when raising the frequency).
Hold time (18),  0 ns for all clock frequencies, let's go with that (i.e. no need to check it!)-

Now, since I had suggested to qualify the /OE signal with E & R/W, i.e. use the already available RD and as this was a quick check I'll ignore the handful of ns of an HC gate), /OE will become valid (low) when E rises (R/W from the MCU is stable long before).

I look in Picture3 to t_GLQV, time from /OE low to data out: 120 ns: with 500 ns half cycle, we have a margin of:
500 - 120 - 40 = 340 ns, no issue here.

Then I checked the time it takes the 2764 to provide a stable output,  t_ELQV: 350 ns.

The time needed for the 2732 to give a valid /CS to the 2764, is of course the same.

Going backwards from the E falling edge, we need to sum:
 40 ns setup time
350 ns 2764 access time from /OE
350 ns 2732 access time (since its /OE and /CS are always active, I use  t_AVQV in Picture3
165 ns Address Delay Time (11 in Picture 1 and 2), 1/8 cycle time + 40 ns
-------
905 ns

As this is less than our 1000 ns cycle time (and we have about 100 ns margin to add, as I used 350 ns instead of 300), I foresee no issue.

The same exercise, mutatis mutandis, can be applied to the 6840 - similar results.

So OK for 1 MHz E clock.

Not so much for a 2 MHz one, the first check will still be OK, but the second one gives:
 30 ns setup time at 2 MHz
300 ns 2764 access time from /OE
300 ns 2732 access time (since its /OE and /CS are always active, I use  t_AVQV in Picture3
103 ns Address Delay Time (11 in Picture 1 and 2), 1/8 cycle time + 40 ns
-------
733 ns

50% greater than our cycle time, so no go.

 

[metertech58761]

I'll check out the HC711 MPUs and see which version etc. to go with - thanks for the link. (edit: that vendor has a 100-piece MOQ)

I also posted the section of code I'd tried converting; see if I had been on on the right track.

[metertech58761]

QUESTION:

In post 26, there are a set of buffers in between the logic and interface boards (74LS241, 74LS244,74LS245).

What is the determining factor whether or not to have such buffers on inter-board connections?

In the original unit, the two boards are connected via two 18-conductor ribbon cables.

Do I assume correctly if the boards were adjacent to each other (i.e., connected by a header instead of ribbon cable), such buffers would not be necessary?

What impact do these buffers have in the overall timing scheme?

[metertech58761]

Let me just push the crickets and tumbleweeds aside for a few minutes.

Supposing I was to swap the EPROM with a GAL - would this be the correct way to hook it up?

Also, if I used a TLC7705 instead of the DS1233+ (because it has active-high AND active-low reset outputs), would I be able to use both outputs at the same time or is it better to stick with a single-output device and generate one output with an inverter?

[metertech58761]

Anyone out there?

So I went back and made some corrections to the design:

Added terminating resistors to all unused ports on the 'HC11
Moved the receive clock connection from XIRQ to IRQ
Changed master oscillator to 4MHz and tied it to EXTAL on the 'HC11
Moved the master clock (E) source to pin 4 on the 'HC11
Replaced the 2732 EPROM with a 16V8 GAL
Replaced the DS1233 with a TL7705A (as it has both active-high and active-low reset)

How's that?

[srb1954]

Anyone out there?

So I went back and made some corrections to the design:

Added terminating resistors to all unused ports on the 'HC11
Moved the receive clock connection from XIRQ to IRQ
Changed master oscillator to 4MHz and tied it to EXTAL on the 'HC11
Moved the master clock (E) source to pin 4 on the 'HC11
Replaced the 2732 EPROM with a 16V8 GAL
Replaced the DS1233 with a TL7705A (as it has both active-high and active-low reset)

How's that?

You also need to:

• Strap the 6840 C1, C2, C3 inputs to ground or supply or via a pull-up resistor.
• Strap the 6821 CA1, CA2 inputs to ground or supply or via a pull-up resistor.
• Strap the 16V8 CLK, OE inputs low and all other unused IO lines to ground or supply or via a pull-up resistor if not programmed as outputs.

You don't really need the pull-up resistors on the address bus nor on ports PA, PD or PG if the pins on these ports are programmed as outputs. The unused bi-directional ports and control pins (CB1, CB2) on the 6821 also need to be programmed as outputs to prevent static charge build-up on floating inputs.

There is a potential issue with obtaining valid logic levels on the processor data bus as you are using a mixture of CMOS and HMOS chips. The 68HC11F1 is a CMOS device and requires a input logic high of minimum 3.5V when reading from peripherals on the data bus. However, the 2764 EPROM, 6840 timer, 6821 PIC and the 8279 KDB interface are all HMOS devices and only guarantee a logic high level of 2.4V when driving the data bus, not sufficient to guarantee the 68HC11F1 to see a valid logic high level. It would be best if you could use all CMOS devices but I am not sure if all the peripheral chips were ever available in CMOS.

The pull-up resistors on the data bus help pull the logic high levels up to the 3.5V level but, because of bus capacitance, the rise time from 2.4V to 3.5V can be too slow for the processor to read a valid logic level at the end of a bus cycle. Reducing the pull-resistors can help improve the rise time; I generally would use 3K3 as this corresponds to the maximum rated current, typically 1.6mA, that the peripheral chips can sink when driving the bus. The whole area of the bus logic levels and timing needs careful examination when you build a prototype.

All the issues of speed, logic levels, timing etc could be avoided if you were to collapse the whole design onto the 68HC11F1 operating in single chip mode. But this would be at the expense of having to rewrite some of the S/W.

[metertech58761]

With so many ill-fitting moving parts in this, it's no wonder that my attempt to copy the original is so fragile design-wise.

On the original, the 6840 had those three pins floating, as well as on another board in a similar application. I'll check the configuration code and then look at adding a pull-up for those.

Also, as far as the 6821, CA1 was left floating, CA2 went to what appears to be a watchdog section (but nothing in the firmware handles the watchdog), CB1 had a pull-up but also went to a non-populated connector, and CB2 went to a non-populated section of the board.

As for pull-ups, the address bus only had them on A0-A7.

Your comment explains why the original used 3.3K pull-ups, and i'll see about making the suggested changes. Thanks!

[metertech58761]

Going through the post from @srb1954

Done:
6840 C1, C2, C3 pins: Tied together to a single pull-up
6821 CA1, CA2, CB1, CB2 pins: each pin tied off to a pull-up
All 10K pull-ups on the HC11 have been changed to 4.7K
6821 setup code: DDR values were corrected to set all unused PAx / PBx pins to output mode (as was in original unit)
Figured out how to configure and use the chip selects on Port G, permitting elimination of the GAL.

To do:

Verify whether I should go ahead and remove the pull-ups from A0-A15 (the original had them on A0-A7 only).

Review HC11 documentation to try and understand how the timer pins on Port A work in hopes of eliminating the 6840.

Determine whether I need to use the HC11's on-board EEPROM as a bootstrap to initialize the internal registers first


Wish list:

If anyone is familiar with the HC11 timer, here is how the 6840 is set up:

Timer 1: Fully internal; used only to provide a programmable delay (looks like 1/16 second per count - can provide assembly code)
Timer 2: Output is 'always on' and is routed to the IRQ pin to provide interrupt signal (sampling timer)
Timer 3: Output is switched on/off as needed to provide the output carrier frequency (modulated with 6821 PA1 line via XOR gate)

[metertech58761]

Current version - eliminated the 6821 in favor of using ports A / G on the HC11.

If I understand right, there shouldn't be any problems using PG0-PG3 (am using the chip selects on PG4-PG7 - which should allow me to remove the GAL).

As for using Port A, as long as I don't touch any of the timer registers, only Port A data / DDR registers, I should be able to use it for I/O, correct?