Talk:Contended I/O: Difference between revisions

From Sinclair Wiki
Jump to navigation Jump to search
m (Sign reply)
m (Add signature (please use ~~~~ for signatures!))
Line 1: Line 1:
IMHO the "... the ULA '''halts''' the processor" is not the best phrase, because there is a HALT instruction in Z80 assembly, which really '''halt''' the CPU and the processor is '''halted''' while an interrupt arrived. Hmm... o.k. not exactly, because Z80 do NOPs to refresh memory.
IMHO the "... the ULA '''halts''' the processor" is not the best phrase, because there is a HALT instruction in Z80 assembly, which really '''halt''' the CPU and the processor is '''halted''' while an interrupt arrived. Hmm... o.k. not exactly, because Z80 do NOPs to refresh memory.


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> [[User:Szaszg|Szaszg]] ([[User talk:Szaszg|talk]])


: 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)
: 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)

Revision as of 00:27, 3 June 2015

IMHO the "... the ULA halts the processor" is not the best phrase, because there is a HALT instruction in Z80 assembly, which really halt the CPU and the processor is halted while an interrupt arrived. Hmm... o.k. not exactly, because Z80 do NOPs to refresh memory.

This situation the ULA really stops CPU clock signal. 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... Szaszg (talk)

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 WAIT (note: I'm using {{overline|WAIT}} for 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. Zub (talk) 00:25, 3 June 2015 (UTC)