Re: Building a 6502 peripheral - timing

Den Thu, 15 Mar 2018 18:33:50 +0100 skrev Gerrit Heitsch
<gerrit@laosinh.s.bawue.de>:
> On 03/15/2018 05:52 PM, Mia Magnusson wrote:
> > Den Thu, 15 Mar 2018 09:49:43 +0100 skrev Gerrit Heitsch
> > <gerrit@laosinh.s.bawue.de>:
> >> On 03/15/2018 09:21 AM, Baltissen, GJPAA (Ruud) wrote:
> >>> Hallo Patryk,
> >>>
> >>>
> >>>> No, it can't. PHI2 is nowhere to connect to there so it has to be
> >>>> taken care of externally.
> >>>
> >>> I meant: the moment you disable CS, the state of WE doesn't matter
> >>> anymore. In my designs I always make sure that PHI2 is part of CS
> >>> selection circuit. Using R/W could be dangerous: what if WE
> >>> becomes (H) before CS? In that case a bus clash can occur, even
> >>> it is just a very short time.
> >>
> >> In most systems you have bus clashes, but yes, short ones. Someone
> >> said that this is the reason why a 7501 uses less power than a 8501
> >> (20mA less from, what I measured). The 8501 is faster, so it gets
> >> its lines active before the other side becomes inactive.
> > 
> > The most important thing here is to study the data sheets /
> > specifications for the involved ICs to make sure that there is no
> > harm when a short bush clash occurs.
> 
> With NMOS-drivers on both sides there can be no harm, that comes from 
> the way NMOS and HMOS works.

Yeah, but it's not really nice.

One thing that IMHO is bad practice although really common is to not
decode R/_W for ROMs.

Each time software writes to ROM in a VIC 20 there is a bus clash all
the way during that cycle. For KERNAL and BASIC it's a NMOS-NMOS clash
(assuming Commodore made their ROMs as NMOS at that time), while for
CHAR ROM it's a TTL-NMOS clash as the clash occurs between the CPU and
the '245 data bus buffers that divide the "CPU only" bus from the "CPU
mixed with VIC" bus.

Too bad that those chips are a bit rare/expensive nowdays. Back in the
90's when 8-bit stuff were almost for free it would had been
interesting to leave a VIC-20 on running a short loop that just writes
to two different ROM locations, with the values written and values in
rom selected so all data bus lines clashes in both way for a cycle of
two writes. Probably nothing would had happened but maybe something
finally would give up?

What other reasons are there for ROMs to tend to go bad more often than
for example CPUs?

(I haven't replaced any bad ROMs myself, and I think I've never read of
anyone replacing a bad ROM actually examining in what way the ROM is
broken. Random bit rot or stuff related to the adress bus might just be
that they are old. But if some bit is stuck at either 0 or 1, or maybe
even works but with too low bus drive capability, it might stem from
bus clashes. Although that doesn't explain bad ROMs in a C64 as the PLA
makes sure there are no bus clashes when writing to ROM addresses as
writes end up in RAM instead).

-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.