Don't write to ROM

[Paganini]

@floobydust, if I'm understanding you right, this problem only happens if an EEPROM is set up to be programmed in circuit, correct? If WE\ is tied high there might be bus contention if the ROM is selected during a write cycled, but the ROM won't see it as a write and freak out?

[Proxy]

Paganini wrote:

@floobydust, if I'm understanding you right, this problem only happens if an EEPROM is set up to be programmed in circuit, correct? If WE\ is tied high there might be bus contention if the ROM is selected during a write cycled, but the ROM won't see it as a write and freak out?

why would there be bus contention? if the CS line is pulled low but OE remains high (which is the case when you write to a ROM with no WE line, or where the WE line is permanently pulled high), then it should stay off the bus entirely with no contention

[floobydust]

Paganini wrote:

@floobydust, if I'm understanding you right, this problem only happens if an EEPROM is set up to be programmed in circuit, correct? If WE\ is tied high there might be bus contention if the ROM is selected during a write cycled, but the ROM won't see it as a write and freak out?

In addition to what Proxy posted...

Just realize that the AT28C256 has the same pinout as a typical 32KB SRAM. The chip select line (CS) must be active for any data to be transferred. The OE is basically a read line and WR is a write line. Using the AT28C256 (and any SRAM), you should use some logic to generate separate Read and Write lines from the CPU CLK and R/W lines. I've included a jumper on my boards so I can prevent accidental write to the EEPROM or, with the jumper set to connect the WR line, so I can update it insitu.

Also, I always use complete address decoding on my systems, so there's never any chance to have phantom addresses that attempt to access other devices. I've attached the basic C02 Pocket SBC schematic. Note that I use a single glue logic (ATF22V10) for address decode, I/O selects and CLK2 qualified Read and Write signals, which are used for SRAM, EEPROM and the UART.

Hope this helps.

[Paganini]

Proxy wrote:

Paganini wrote:

@floobydust, if I'm understanding you right, this problem only happens if an EEPROM is set up to be programmed in circuit, correct? If WE\ is tied high there might be bus contention if the ROM is selected during a write cycled, but the ROM won't see it as a write and freak out?

why would there be bus contention? if the CS line is pulled low but OE remains high (which is the case when you write to a ROM with no WE line, or where the WE line is permanently pulled high), then it should stay off the bus entirely with no contention

It's a good question. I don't know!

But consider this circuit that was discussed briefly in an old thread:

download/file.php?id=3507&mode=view

It seems to be contemplating a regular EPROM like a 27c64, and not one of the devices that floobydust mentioned that have only one activation signal. I don't know what to make of it. Should I just chalk it up to design error and move on?

It turns out that this thread is where Garth's comment (that I was earlier searching the Primer for) is located:

GARTHWILSON wrote:

Avoiding bus contention if you were to accidentally write to an EPROM address, with a minimum of parts, seems to be the main focus on this one. I would say however that such writes are not really a concern. The program-bug conditions that would make them happen will be rare and probably be encountered only during program development and then fixed, and be at too low of a duty cycle to cause any hardware damage, and the bug would would probably make your program crash anyway even with the hardware protection against writing to EPROM.

I'll see if I can refine the question a little, since after reading the replies so far I'm beginning to see my confusion more clearly:

In reading old forum threads and old literature, I've seen three different viewpoints:

1. You should make sure that ROM CS\ is qualified by RD\ so that you can't cause bus contention if you accidentally write to an address in ROM.
2. Accidentally writing to a ROM address is a rare bug and probably won't hurt anything, so don't worry about it.
3. It's impossible to cause bus contention by accidentally writing to ROM. Why are we talking about this?

I'm having trouble reconciling these 3 viewpoints, hence, this topic.

[BigEd]

I think 3 is only true if the glue logic arranges it to be true.

I think 1 and 2 are compatible, in the sense that 2 is pragmatic and 1 is pedantic. Different people will take one or other position, not based on difference of opinion about reality, but because of different personal preferences.

[hoglet]

BigEd wrote:

I think 3 is only true if the glue logic arranges it to be true.

FYI, I recently discovered that writing to the ROMs on the BBC Micro model B does indeed cause bus contention, because RnW is not included in the glue logic that drives nCS or nOE.

This caused my 6502 Decoder to flag errors during these write cycles, as the value observed on the data bus did not match the value it was expecting the 6502 to be outputting.

This can't really be good for the health of the 6502, and I wonder if a malicous program might eventually cause the data bus drivers in the 6502 to fail.

Dave

[BigEd]

Interesting! I'd forgotten...

(I suspect we'd be looking at a heating effect. For the most part, heat accelerates an ageing process, although not linearly. So one might look at what the temperature rise would be, at the drivers, in an average case or a worst case. The 6502 won't be writing for a great proportion of clock cycles, in any case. But some sacrificial testing would be needed to quantify this. My guess is, with the computer at normal room temperature and running some fairly aggressive contending writes, the temperature rise won't be so high that it's much worse than continuous operation at industrial high temperatures. It's only a guess!)

[plasmo]

Intermittent contention of digital logic is generally not harmful. Some active logic probe does it intentional by injecting signal into working system (overpowering existing output) and monitoring its effect. The immediate problem of contention is supply voltage spikes created by excessive current which can cause ground bounces. Persistent contention can create damaging localized heating. I suppose electro-migration damage is also possible even with the large feature size of retro devices.
Bill

[BigEd]

Yes, we should certainly think about what the power rail and ground are doing during contention.

And anyone building for battery powered operation would probably want to be careful.

And of course some chips have quite high drives, so that will make the effects greater.