707
edits
(Reply) |
m (Sign reply) |
||
Line 3: | Line 3: | ||
This situation the ULA really stops CPU clock signal. <del>pulls the "/WAIT" pin of CPU, and Z80 adds "empty" clock cycles while /WAIT is low. BTW: while Z80 waits, does not refresh the memory, so a long wait cycle can "erase" the DRAM...</del> | This situation the ULA really stops CPU clock signal. <del>pulls the "/WAIT" pin of CPU, and Z80 adds "empty" clock cycles while /WAIT is low. BTW: while Z80 waits, does not refresh the memory, so a long wait cycle can "erase" the DRAM...</del> | ||
: Thanks, Gergely! I've had a go at this. Unfortunately, I'm working from memory here. My recollection is that ULA I/O access is delayed using {{overline|WAIT}} (note: I'm using <nowiki>{{overline|WAIT}}</nowiki> for {{overline|WAIT}} in this Wiki, not /WAIT, !WAIT, ~WAIT or ¬WAIT :-)) but that the spurious I/O contention stops the clock. Please correct me if I'm mistaken. I don't quite get why access to ULA ports between 0x4000 and 0x7fff results in less contention than non-ULA access within that some range. We could do with adding a reference to Chris Smith's book here, although I don't currently have it. | : Thanks, Gergely! I've had a go at this. Unfortunately, I'm working from memory here. My recollection is that ULA I/O access is delayed using {{overline|WAIT}} (note: I'm using <nowiki>{{overline|WAIT}}</nowiki> for {{overline|WAIT}} in this Wiki, not /WAIT, !WAIT, ~WAIT or ¬WAIT :-)) but that the spurious I/O contention stops the clock. Please correct me if I'm mistaken. I don't quite get why access to ULA ports between 0x4000 and 0x7fff results in less contention than non-ULA access within that some range. We could do with adding a reference to Chris Smith's book here, although I don't currently have it. [[User:Zub|Zub]] ([[User talk:Zub|talk]]) 00:25, 3 June 2015 (UTC) |