Zilog z80 replacement on a MSX computer

It will run at the speed of the slowest component, which won't be your new 20MHz Z80.

NT

In addition, you would have to check the maximum allowed rise and fall times for the fast Z80 inputs. In the old system, these might be too slow.

Also check the rise and fall times for the fast Z80 outputs, these got to be much shorter, in order to theoretically be able to operate at 20 MHz. This can cause all kinds of signal reflections, which can mess up things.

So if the original 2.5 MHz Z80 worked well on a Veroboard computer, but using a 20 MHz Z80 running at the original 2.5 MHz might not work properly, due to the sharper edges and reflections.

Besides the technical issues already mentioned by others (just replacing the chip will not make it faster) you should know that in those days the computers of the same class (e.g. MSX) were all the same speed, so programmers often designed their software with this speed in mind.

When making the system 10 times as fast, you would get timing problems like games that run 10 times faster and become unplayable.

It was some years later that, in the "PC compatible" class of computers, the issue first arised because faster computers became available that were binary compatible with older ones and thus could run the same software. For some time, speed switching ("Turbo button") was implemented to allow the user to slowdown the computer when required to run software that was unusable at the higher speed.

After all the programmers adapted to the new environment and learned to use timers instead of software loops to control execution speed, the speed switches were no longer provided.

Your MSX will still run at 2.5MHz...It's controlled by the crystal frequency.

--
This email has been checked for viruses by Avast antivirus software. 
https://www.avast.com/antivirus

Some of us assumed the OP would be trying other crystal frequencies, but who knows, perhaps not.

NT

Does the CPU have TTL Voltage levels? Also, this here kinda suggests that the bus s async, or at least can work with different CPUCLOCKs So, I'd say it might work, but you'll have to find a schematic for the bus system to definitely figure that out.

I assume we are talking about a garden variety Z80 here. What they mean by "asynchronous" timing is that the clock is not required to use the bus. The address is set up and the control lines are asserted which give the timing. I recall the Z80, like the 8080, uses separate Read and Write strobes (low true) while the other school of thought was to use a single line to indicate read/write as uses on the 6800 and similar processors.

The timing of these strobes are set by the clock. The only way to extend them is to assert the wait signal until the memory or I/O device is ready. The CPU then adds clock cycles until the wait signal is deasserted. So to use a 10x clock with this new CPU a wait state generator would need to be added (or modified) to slow the CPU to match the memories.

Of course the other alternative would be to swap out memory to ones that will run at the faster rate. This is entirely possible, but they will definitely not be pin compatible and in fact, you will have a hard time finding any that run at 5 volts (a bit of a problem) and they will be

*much* larger than the address space of the Z80 (not really a problem). But then you are still left with the I/O which the CPU will need to be slowed down for.

--

Rick C

You still don't really have the right group. Try comp.arch.embedded Oh, here, I'll cross post for you.

--

Rick C

Although I have never even looked inside an MSX, I would be surprised if that worked.

There's a good chance the crystal oscillator is used to generate other clocks in the design, such as timers or serial I/O. If you simply change the clock, they would all be off.

The C64 uses the CPU oscillator to generate the correct frequency for the TV image generator. As a result, the PAL and NTSC versions have slightly different CPU clock speeds.

--
RoRo

That's misleading. The bus is, of course synchronous (as the processor itself is a synchronous machine -- even the Burroughs was!)

But, unlike its ~contemporary, the M6800, the length of a bus cycle can be negotiated by the peripheral.

The Z80 has several different types of bus cycles:

- (general/data) memory read/write

- opcode fetch (nominally one -- but sometimes *two* -- per instruction)

- I/O read/write (the Z80 has a 64Kx8 I/O space that is separate from the "memory" address space -- though most folks are under the misconception that it is just 256x8 :< )

- interrupt acknowledge (allows an interrupt vector to be "fetched" from a peripheral)

[There are also some special bus transactions that don't really qualify as special cycles; e.g., Z80-family peripherals snoop the bus to detect when the RETI -- return from interrupt -- opcode is fetched so they can manage their internal interrupt "daisy-chain" logic]

These cycles are typically 3 clocks in duration (though fetches require

4 clocks and are often exploited to "hide" DRAM refresh -- without having to stall the bus, otherwise). A "/WAIT" signal is sampled during the bus cycle and, if asserted, the cycle is extended for another clock cycle.

As such, bus cycles are always an integral number of clock cycles.

Contrast this with something like the M68000 (68K) that requires an "acknowledgement" (DTACK) from memory to end the bus cycle.

I.e., a 68000 system that doesn't "handle" each bus access by generating a DTACK will stall at the first unhandled address. By comparison, a 6800 or Z80 system will gladly march through memory that doesn't exist.

[A sure-fire way to determine catastrophic bus failure on the 8085 -- a close predecessor to the Z80 -- was to note that it was HALTed at address 0x0076 (77?). As the data bus was multiplexed onto the least significant 8 bits of the address bus, a fetch of address 0x0076 would typically "see" 0x76 floating on the data bus pins as vestigial charge from when it was driven as an address. The HALT instruction has an opcode of 0x76!]

You MIGHT be able to salvage the PCB *foils* by upgrading all of the related components. But, otherwise, you're just putting an overspec'ed component in an underutilized design.