Posted By
TLC
on 2007-02-08
15:53:58
|  Re: Plus/4 Expansion port...
Yep... that's true, if it relies upon IRQs, or DMAs.
Still, I think, it's possible to do without either. Single write cycles are predictably followed by an opcode fetch. These single write cycles _can_ be catched IMHO... it would need some clever knowledge of the bus signals and probably three flip-flops.
What we need?
Activate something on a _read_ cycle, which is preceded by a write cycle, which is preceded by a read cycle.
Let's use three flip-flops (or a shift register with three bits, whose first bit can be loaded without an implied shift at the same time, but let's just stay with flip-flops for the sake of simplicity). Let these be A, B, and C. B is loaded into C and A into B at the end of every CPU cycles (ie. it's shifted on all CPU cycles, and it's done at a time when it won't disturb our circles).
Find or create a signal that goes active in all CPU cycles at about the time or slightly later when r/w' drops on write cycles. Upon the active edge of this signal, store the state of r/w' into A. Also, at this very minute, (C & !B & A) (or for the sake of speed, C & !B & r/w' itself) will tell us if it's "our time" (e.g. D0-D7 can safely be pulled low).
"A" might be unneccessary, if r/w' is still active at the time the "shifting" signal goes active (ie. r/w' could be stored to B directly, after B had been shifted to C). Maybe, it's just the way to go, as we also need to know the "end" of "our time" (e.g. when D0-D7 must be released) so we need a signal like that anyway.
This would get active sooner or later, unless the program executed no write opcodes (pretty unlikely  ) or it executed rmw opcodes or JSRs or BRKs only...  .
|
