Jump to content
IGNORED

M1 delay


ThomH

Recommended Posts

Looking at this schematic I see a 74LS74A which appears to be set up to trigger a cycle of WAIT upon every M1.

 

That's not too uncommon for Z80 machines because it extends the opcode fetch read from 2 cycles to 3, moving it into line with most other accesses. It's even offered as a sample external circuit in at least one of the Z80 data sheets.

 

Yet I've never heard about that in ColecoVision world. It would if I'm reading things correctly give operations the same cost as on the MSX. So e.g. NOP would take 5 cycles, not 4.

 

Since I trust my schematic reading maybe only 70%, having no formal grounding in electronics, can anybody confirm or deny that the ColecoVision inserts an extra cycle into every M1 machine cycle?

Link to comment
Share on other sites

Also, if you're taking a more serious look at the CV schematics, I'll shill for my own schematics, which I've also gone through the trouble of verifying. More consistent labeling, and all connections represented, and also a PCB diagram to help locate the components. Contains PDF and Kicad formats. Also shows schematic for the regular controller, Super Action Controller, and Roller Controller.

 

Comments welcome.

 

http://atariage.com/forums/topic/285656-new-colecovision-schematics/

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Yep, that wait cycle is there.

 

It also has a wait state when sending data to the sound chip.

 

 

Actually, belated follow-up on that: is the sound chip delay just a single cycle?

 

The data sheet mentions an "approximately" 32-cycle delay being signalled via the READY line, which goes straight to WAIT, starting from chip select going active. So shouldn't the Z80:

  • begin its output cycle;
  • trigger the SN's chip enable 1.5 cycles after that, when write goes low;
  • 1 cycle after that sample WAIT and spot that it needs to wait;
  • have to wait for "approximately" 32 - 1 = 30 cycles;
  • then do the last cycles and a half of its output cycle?

So that's 31 extra cycles?

 

That sounds like a huge amount, so I'm sure I'm getting something wrong here.

Link to comment
Share on other sites

Well, first of all, you are misunderstanding the order of events. The 1.5 cycle wait is only for memory reads during instruction fetch (M1 is for instruction fetch). Here's an outline:

 

  1. CPU executes I/O write instruction.
    1. Places address on address bus
    2. Places data on the data bus if this is a write. Otherwise prepares for data input.
    3. Sets RD and WR lines as necessary.
    4. Brings IORQ low. No device is expected to even be watching the bus until this signal arrives. This also implies that the address, data, and direction are already set on the bus.
  2. I/O decoder IC (U6) is activated by the IORQ line. This IC is a 3-bit decoder that activates one of the output lines when all 3 enables are as required (E1 and E2 low, E3 high). The line activated will be based on the address line bits A6:A5:WR. For the sound chip, O6 will be activated.
  3. O6 is connected to the sound chip's write enable and chip enable inputs.
  4. Sound chip pulls READY low while it's latching the data into the appropriate internal location, and brings READY high again when done.
  5. Since READY is connected to WAIT, however long this takes, the CPU will hold the current bus state.
  6. If this is a read, CPU samples the data bus.
  7. CPU releases IORQ, RD, WR, address, and data lines for next instruction.

 

Otherwise yes, a write to the sound chip is slllooooooowwwwww.... 32 cycles, or about 8.9us, or 1/7 of a video line, or about 4 shift instructions (well, not counting the time to load the instructions from memory). The only saving grace is that you don't need to send many bytes to it to play sounds in human perceptible time.

Edited by ChildOfCv
  • Like 1
Link to comment
Share on other sites

Well, first of all, you are misunderstanding the order of events. The 1.5 cycle wait is only for memory reads during instruction fetch (M1 is for instruction fetch).

 

Apologies, I'm unclear how to interpret this, so I'm going to ask a further follow-up. I'm looking at this timing diagram:

 

Z80%20I%3AO%20cycle.png

 

I count T1 high, T1 low and T2 high before WR and IORQ go low. So is that not 1.5 cycles before the SN can possibly receive chip enable? (rounded to half cycles, anyway)

 

Then it's another low/high to the first sampling of WAIT, then however long the SN is still holding that for, with that total delay rounded up to a whole number of Z80 clocks because that's how often the Z80 seems to sample, then another low/high/low to complete the machine cycle.

 

 

Here's an outline:

  1. CPU executes I/O write instruction.
    1. Places address on address bus
    2. Places data on the data bus if this is a write. Otherwise prepares for data input.
    3. Sets RD and WR lines as necessary.
    4. Brings IORQ low. No device is expected to even be watching the bus until this signal arrives. This also implies that the address, data, and direction are already set on the bus.
  2. I/O decoder IC (U6) is activated by the IORQ line. This IC is a 3-bit decoder that activates one of the output lines when all 3 enables are as required (E1 and E2 low, E3 high). The line activated will be based on the address line bits A6:A5:WR. For the sound chip, O6 will be activated.
  3. O6 is connected to the sound chip's write enable and chip enable inputs.
  4. Sound chip pulls READY low while it's latching the data into the appropriate internal location, and brings READY high again when done.
  5. Since READY is connected to WAIT, however long this takes, the CPU will hold the current bus state.
  6. If this is a read, CPU samples the data bus.
  7. CPU releases IORQ, RD, WR, address, and data lines for next instruction.

Otherwise yes, a write to the sound chip is slllooooooowwwwww.... 32 cycles, or about 8.9us, or 1/7 of a video line, or about 4 shift instructions (well, not counting the time to load the instructions from memory). The only saving grace is that you don't need to send many bytes to it to play sounds in human perceptible time.

 

... I think that last part clears it up for me regardless. It really is 32 cycles, in terms of the same clock as the Z80, between chip enable and the WAIT(/READY) line deactivating.

 

I had failed to observe that the same behaviour would happen on an input, but I guess since there's no reason to perform an input that maps to the SN, I hadn't really thought about it. Yes, that sounds like a good excuse.

Link to comment
Share on other sites

 

I count T1 high, T1 low and T2 high before WR and IORQ go low. So is that not 1.5 cycles before the SN can possibly receive chip enable? (rounded to half cycles, anyway)

 

Then it's another low/high to the first sampling of WAIT, then however long the SN is still holding that for, with that total delay rounded up to a whole number of Z80 clocks because that's how often the Z80 seems to sample, then another low/high/low to complete the machine cycle.

 

Oh, I see. I thought you were still talking about the external wait state generator. I hadn't even looked that closely at the z80 I/O timing diagram. But the data sheet has a nice summary:

 

 

Figure 7 illustrates an I/O read or I/O write operation. During I/O operations a single wait state is automatically inserted. The reason is that during I/O operations, the time from when the IORQ signal goes active until the CPU must sample the WAIT line is very short. Without this extra state, sufficient time does not exist for an I/O port to decode its address and activate the WAIT line if a wait is required. Also, without this wait state, it is difficult to design MOS I/O devices that can operate at full CPU speed. During this wait state time, the WAIT request signal is sampled.

 

During a read I/O operation, the RD line is used to enable the addressed port onto the data bus just as in the case of a memory read. For I/O write operations, the WR line is used as a clock to the I/O port.

 

 

 

 

This seems to imply that the I/O device's wait time can overlap the internal wait state some. So that does mean that the total wait state time is going to be either 32 or 33 cycles for the sound chip, depending in how quickly the logic on the way can react.

 

As for input, well the sound chip doesn't support input, and the CV doesn't offer a way to try either :)

 

Oh, and AA pointed out your other thread about the sound chip from May of last year. I guess we've already cleared this up, but the AN chip has a divide by 8 counter before it reaches the 4-cycle internal clock, so yeah, 32 cycles of 3.58MHz clock to load data.

Link to comment
Share on other sites

Great, thanks for your reply! My previous thread, apart from reaching the wrong conclusion, gained no traction whatsoever so the unprompted mention of a sound chip wait period here was too much to pass up.

 

So I guess it depends most strongly on what you think the SN76489 data sheet is trying to communicate with an "approximately" 32-cycle wait — e.g. is it a fixed period independent of the clock rendered into cycles on the assumption of a 4Mhz clock? — but if it were exactly 32 then I'd expect an output cycle to be extended by an additional 31 cycles both naively, given the single cycle of wait that's built in, and by thinking about when WAIT would first be sampled high if the 32 count kicked in exactly on the downward transition of T2.

 

So the whole machine cycle would be 35 cycles.

 

On the separate issue of the M1, yeah, I understand that to be a single cycle delay during the M1 machine cycle. So it's then the same length as every other memory access cycle. So it's five cycles for a plain NOP, as refresh isn't affected, and the differences to more complicated instructions depend on whether they signal M1 during opcode fetch. Speaking extemporaneously only, I think that some of the more compound forms, like the (ix+d)/(iy+d)s, don't actually signal M1 for everything they fetch from the PC — if memory serves then the opcodes after the offset are issued as ordinary read cycles. Or maybe I'm thinking of the offsets. Either way, I'm pretty confident I have it implemented properly in my little simulator.

Link to comment
Share on other sites

On the separate issue of the M1, yeah, I understand that to be a single cycle delay during the M1 machine cycle. So it's then the same length as every other memory access cycle. So it's five cycles for a plain NOP, as refresh isn't affected, and the differences to more complicated instructions depend on whether they signal M1 during opcode fetch. Speaking extemporaneously only, I think that some of the more compound forms, like the (ix+d)/(iy+d)s, don't actually signal M1 for everything they fetch from the PC — if memory serves then the opcodes after the offset are issued as ordinary read cycles. Or maybe I'm thinking of the offsets. Either way, I'm pretty confident I have it implemented properly in my little simulator.

I can't say authoritatively if that is true, but instinctively I would expect it to issue M1 for every byte of instruction. From a "delay" perspective, this is the only way that slow memory such as M27C64-4 chips can keep up. Also, if you were attempting to use M1 to enforce a Harvard architecture, you'd be SOL unless it fires on every byte of instruction fetch.

Link to comment
Share on other sites

It's a little reading between the lines, and not exactly how I stated it above, but my expectation in that area comes from the Z80 manual, specifically the Z80 instruction breakdown by machine cycle that begins on page 85 where e.g. the machine cycle breakdown for ALU A, (IX+d) is described as (page 88):

 

OCF(4), OCF(4), OD(3), IO(5), MR(3)

 

Which, to save you the effort of looking up the key, means:

 

opcode fetch (4 cycles), opcode fetch (4 cycles), operand data read (3 cycles), internal operation (5 cycles), memory read (3 cycles)

 

The whole instruction is of course two opcodes plus the offset that forms the '+d', but the time that it takes to read the offset is 3 cycles rather than 4. So immediately you know that there's no refresh cycle in there, and a relatively safe assumption is that it's just a normal read cycle. That's even though the '+d' comes from the program counter like a real opcode.

 

There's certainly no three-cycle pattern documented that signals M1, and M1 is documented as occurring only during "the op code fetch cycle of an instruction execution". That's elsewhere in the manual, alas, but I think it's likely that it means "opcode fetch" in the same sense as does the timing diagram — i.e. not to include operand data reads.

 

Admittedly that doesn't amount to establishing the absence of an M1 beyond reasonable doubt, but I'd argue it's beyond balance of probability. Sadly I'm not aware of anybody that has ever just connected up an oscilloscope and produced hard evidence either way.

 

EDIT: though, actually, further weak evidence on that particular type of instruction being weird is that, if memory serves, immediate operand instructions like LD (IX+2), 32 put the immediate operand before the offset, which means it's the only instruction where the immediate operand isn't the final thing. Or maybe it's just me that often trips up on that.

Edited by ThomH
Link to comment
Share on other sites

Well, the z180 manual states it explicitly (for the z180), but that does support your beliefs.

 

Operand and Data Read/Write Timing. The instruction
operand and data read/write timing differs from op-code
fetch timing in two ways. First, the M1 output is held inac-
tive. Second, the read cycle timing is relaxed by one-half
clock cycle since data is latched at the falling edge of T 3 .

 

Still, from the timing standpoint especially, I shake my head at this.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...