Reset delay on Motorola 6809, so that TTL logic around it becomes stable - Page 1
Forum section: electronics / general

author: MadTux
author_rank: Frequent Contributor
timestamp: November 20, 2020, 12:44:00 pm
content: Got a broken Deckel Dialog4 NPP90 card for repairs.Since I don't have programmer for ancient TMS2564s on there and the sockets on the board became brittle junk over time, I decided to swap ancient 4x TMS2564 EPROMs for a 27C512, so that I can confirm EPROM content and upgrade software.Should have been simple, right? Grab A13-A15 adress lines from 74LS138 demultiplexer and wire them to 27C512.And rewire /CS and /OE lines.But board refused to work afterwards. So grabbed my nice 16500C and started probing. Couldn't find the fault, that thing was driving me crazy. Should have been so simple. Values at reset vector FFFE/FFFF are FF/25, which is likely correct. After some more time, I found that the 74LS04 inverter that inverts 6809 R/W line for 27C512 /CS line doesn't work right at the time the 6809 is resetting. Works fine only like 100ms later. So data bus has corrupted data and 6809 goes to 0x0000 nirvana as it gets 0x0000 as reset vector.Question, how do I delay 6809 reset like a 500ms or so, until all the TTL logic has stable voltages???

author: MadTux
author_rank: Frequent Contributor
timestamp: November 20, 2020, 01:17:02 pm
content: Just had another look at the 6809 datasheet, there should be some kind of reset circuitry at reset pin.Will trace that out, since Deckel supplied schematic is unreadable garbage and try, if I can change like some resistor/capacitor at RC circuit/schmitt trigger thing or something.

author: srb1954
author_rank: Super Contributor
timestamp: November 20, 2020, 09:12:33 pm
content: Quote from: MadTux on November 20, 2020, 12:44:00 pmIn a normal logic design there shouldn't be any need to have long delay for the TTL logic to stabilise as this is usually negligible compared to the time for the processor to stabilise. Normally the reset delay is determined by allowing 10-20ms for the supply rails to stabilise and another 100ms or so for the uP clock oscillator to start up and stabilise. For the 6809 the clock signal must be running before the reset is released.Things to look for are the main power supply having a very slow rise time or non-monotonic rise on the power supply rail. A very slow rise time on the power supply rails can result in some parts of the circuit coming out of reset while other parts are still held in the reset state. This is usually prevented by having a uP supervisor or voltage detector on the reset circuit that doesn't release the reset until the supply reaches 4.5V or thereabouts. I don't see a uP supervisor on this PCB so it may just have a RC delay reset circuit, which wouldn't be effective with slow rising power supplies.68xx family devices are also sensitive to glitches on the reset line on start-up otherwise they can lock-up and get stuck in an endless loop. They need a clean monotonic reset signal to ensure reliable start-up. Again a uP supervisor chip is the best solution to provide a clean reset signal.

author: srb1954
author_rank: Super Contributor
timestamp: November 21, 2020, 10:24:04 am
content: Quote from: MadTux on November 20, 2020, 12:44:00 pmIt is not recommended to use the inverted R/W line for the 27C512 /CS as it creates the potential for bus conflicts between the EPROM and other devices on the next bus cycle.The normal configuration for a 6809 system is to use the inverted R/W line as the EPROM /OE line. The EPROM /CS should then be derived from the decoded address gated with the the E clock high state to ensure that the EPROM is immediately disabled at the end of the bus cycle when the E clock goes low.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: November 22, 2020, 10:24:18 pm
content: Quote from: MadTux on November 20, 2020, 12:44:00 pmThat does not make sense: 74LS04 logic should be stable in nano seconds from power up.Delay effects of 100ms region on any LOGIC parts, would be very rare indeed, even as a fault, but if itreallydoes take 100ms to become stable, replace the part.Are the power supplies clean ? On older boards it may be more likely aging caps give power problems.

author: ale500
author_rank: Frequent Contributor
timestamp: November 26, 2020, 10:59:43 am
content: You know, it could also be that the EPROM you are using (100 ns) is a bit too fast when disabled at the time ~CE, ~OE get negated not guarantying the hold time.

author: srb1954
author_rank: Super Contributor
timestamp: November 26, 2020, 09:20:27 pm
content: Quote from: ale500 on November 26, 2020, 10:59:43 amHold time is unlikely to be the cause of the problem in this case as it seems more likely that there is a bus contention problem through the address decoding being mucked up by the modifications to the original design.The original design appears to use six 8k EPROMs for a total of 48K with address decoding and chip selects provided via a 74LS138 decoder. A further 74LS138 decoder appears to be used for providing chip select signals for the RAM and peripheral chips. This would utilise the remaining 16K of the 6809 address space not used by the 6 EPROMS so there is no possibility of a bus contention problem.It is hard to tell from the photos how the address decoding for the modified EPROM is set up but it looks as though it might be permanently enabled for the whole of the 64K address space. I don't see any connection to the outputs of either 74LS138 decoder to disable the 64K EPROM for the part of the address space occupied by the RAM and other peripherals.In a normal design hold time is not likely to be an issue even for very fast EPROMS. With conventional 6809 address decoding practice the time delay through the decoding logic will provide sufficient additional delay to the EPROM /CE to ensure that there is more than adequate hold time for the 6809, which only requires 10ns data hold time. However, even if the EPROM output were to be tri-stated immediately after the end of the cycle, the bus capacitance would easily hold the data long enough to satisfy the hold time requirement, provided there are no bus contention problems caused by other devices driving the bus when the EPROM is enabled .

author: MadTux
author_rank: Frequent Contributor
timestamp: December 01, 2020, 02:11:42 pm
content: Mystery solved, that R/W line had nothing to do with it, MC6828 was trolling me hard.And many thanks for helping me!It's a kinda weird design with weird address map:0x0000-0x3FFF RAM/other IO stuff?0x4000-0xDFFF ROM0xE000-0xFFFF ROM, but with address lines A1-A5 modified by MC6828 interrupt controller chip, adress bus goes to ROM#1-5, as everyone would expect, but then goes to MC6828 A1-4+some logic on A5, and comes out of MC6828 Z1-4 lines which goes to ROM#6 A1-4 lines+A5 from 74 logic across the board.That MC6828 was trolling me the whole time, finally found out what was wrong, when I disassembled the binaries and the code at 0xFF25 made absolutely no sense. Then probed all adress lines for continuity and found it, lol.Board works fine with ROM#6 installed and /OE disabled on 27C512 for adress range 0xE000-0xFFFF.Next step is grab A1-A5 from A1-A5 adress bus and A1-A5 from ROM#6, feed both to 2x 74LS157 multiplexer, which selects adress bus depending on ROM#6 /OE line, so that 27C512 gets normal adress bus from 0x4000-0xDFFF and modified one from 0xE000-0xFFFF.

author: srb1954
author_rank: Super Contributor
timestamp: December 02, 2020, 04:04:45 am
content: Quote from: MadTux on December 01, 2020, 02:11:42 pmThis address map is perfectly normal for a 6809 system, which fetches its restart and interrupt vectors from the top of the address space so the EPROM is installed from the top of the address space downwards. This is contrary to Intel 8-bit processors which fetch vectors from the bottom of the address space. RAM and I/O devices are typically allocated at the lowest addresses as there is a speed and code size advantage for accessing devices in the bottom 256 bytes of the address space in a 6809 systemThere shouldn't be any need to add any extra 74LS157 multiplexers on the address lines A1-A5 as this multiplexing function is already built into the 6828. Just be sure to take these addresses lines downstream from the 6828 i.e. from the 0XE000-0xFFFF ROM socket, rather than directly off the processor address bus.In normal operation the 6828 passes the address through from the processor unmodified but fiddles with the address lines A1-A5 when the processor is fetching an interrupt vector from EPROM. This effectively creates another interrupt vector table in EPROM and gives the system an additional 7 individually vectored interrupts so the S/W doesn't have to waste time polling peripheral devices to find the source of an interrupt. This is all fully explained in the 6828 data sheet.It still sounds as though you need to look more closely at the /CE and /OE logic when installing the 27C512 EPROM. To avoid contention with the RAM and I/O devices you need to be sure that the EPROM is disabled for the lower address range 0x0000-0x3FFF. I wouldn't expect that suitable logic signals are available from the ROM#6 socket signals as there is no need for that functionality with the smaller EPROMs. You need to derive a new EPROM /CE from the address decoder logic such that when the RAM or I/O devices are selected the EPROM is disabled. This can probably be easily done by taking the active low enable input for the 74LS138 RAM and I/O address decoder, inverting that signal and feeding it to the 27C512 /CE input. You need to review the whole address decoding circuit to verify this.

author: MadTux
author_rank: Frequent Contributor
timestamp: December 02, 2020, 11:23:05 pm
content: Thanks!Address lines straight from 6828/ROM#6 makes it a lot simpler, will try that./OE signals should work out fine, I took the 6 /OE signals for TMS2564 from 74LS138 demultiplexer and ANDed them together with 74LS11, so if a /OE line goes low, 74LS11 goes low, all /OE high, 74LS11 => high./CE is straight from TMS2564, all connected together, shouldn't make a difference for 27C512.

author: MadTux
author_rank: Frequent Contributor
timestamp: December 05, 2020, 08:50:20 pm
content: Works the way described above, thanks everyone!!!!