Forums

I couldn't find a copy of "Z80 Optimization for Dummies" at the local bookstores (they say it doesn't exist.. I think they're too lazy to order it.)

So I was wondering: When optimizing z80 code, should I be optimizing for t-states or cycles? Somewhere I remember reading that T-states were more critical.

I was also wondering how the various sms emulators manage their timing... do they count cycles, t-states, or just instructions (I remember at least some versions of MasterGear counting instructions).

And finally.. I haven't been able to find any sort of z80 optimization FAQ anywhere, popular though the z80 still is (in gameboys, ti calcs, etc.) But I have found a few things while writing that never-to-be-finished demo of mine... If there is no other faq maybe we (I) should start one.

[....]
Pardon my ignorance, but I don't even know what are T-States!
Isn't that another word for "cycles" ?

[....]

Quote

> I remember at least some versions of MasterGear counting instructions

That's definitively a bad idea if you want good/accurate emulation, but most (non tricky) softwares would works which such a simple counting scheme.

Quote

>If there is no other faq maybe we (I) should start one.

Documentating anything is a good idea.

Quote

> [....]
> Pardon my ignorance, but I don't even know what are T-States!
> Isn't that another word for "cycles" ?

The Z80 is weird. What it calls a T-state, we call a cycle. It then has "M-cycles", which tend to be composed of either 3 or 4 T-states.

A T-state is one pulse of the clock. An M-cycle tends to be how long it takes to read/write memory (it is possible to extend this with wait states).

Quote

> [....]
> > I remember at least some versions of MasterGear counting instructions

> That's definitively a bad idea if you want good/accurate emulation, but most (non tricky) softwares would works which such a simple counting scheme.

Why am I not suprised that Marat used instruction count timing at one point? :-)

Quote

> >If there is no other faq maybe we (I) should start one.

> Documentating anything is a good idea.

Optimizing Z80 code, or optimizing a Z80 emulator?

--Nyef

Quote

> > >If there is no other faq maybe we (I) should start one.
> > Documentating anything is a good idea.
> Optimizing Z80 code, or optimizing a Z80 emulator?

Optimizing Z80 code I guess. He mentionned a demo.

Quote

> > > >If there is no other faq maybe we (I) should start one.
> > > Documentating anything is a good idea.
> > Optimizing Z80 code, or optimizing a Z80 emulator?

> Optimizing Z80 code I guess. He mentionned a demo.

It is my understanding that the Z80 micro-architecture is very simple (by today's standards): it's not even pipelined. Consequently, Z80 optimization should mostly consist of cycle-count minimization. There's no need to worry about register interlocks, or caching, or branch prediction, or any of the issues plagueing modern assembly programmers. If any one has any high-performance Z80 (general-purpose) routines please let me know, and I'll post them in the Source Code area.

Eric Quinn

Quote

> > > > >If there is no other faq maybe we (I) should start one.
> > > > Documentating anything is a good idea.
> > > Optimizing Z80 code, or optimizing a Z80 emulator?

> > Optimizing Z80 code I guess. He mentionned a demo.

Yeah, z80 code. If an emulator is too slow, I just run it on a faster computer.

Quote

> It is my understanding that the Z80 micro-architecture is very simple (by today's standards): it's not even pipelined. Consequently, Z80 optimization should mostly consist of cycle-count minimization. There's no need to worry about register interlocks, or caching, or branch prediction, or any of the issues plagueing modern assembly programmers. If any one has any high-performance Z80 (general-purpose) routines please let me know, and I'll post them in the Source Code area.

I also assume there is no memory refresh to worry about (the sms does use static ram, right?) but there'd be nothing to do about it anyway.

I'm glad to hear that people who refer to cycles on a z80 also mean t-states. I'd be using the two interchangably for a long time, and I see that's not a bad thing.

Quote

> I also assume there is no memory refresh to worry about (the sms does use static ram, right?) but there'd be nothing to do about it anyway.

The reason you don't have to worry about the memory refresh is because you CAN'T TURN IT OFF. Kudos to the people at Zilog for making such an obnoxious design decision.

Quote

> I'm glad to hear that people who refer to cycles on a z80 also mean t-states. I'd be using the two interchangably for a long time, and I see that's not a bad thing.

It's not nessecarily a bad thing, just remember the difference between a "cycle" (or T-state) and an "M1 cycle" (which is the opcode fetch, at 4 T-states (thank you again, Zilog for integrated DRAM refresh)).

--Nyef

Author	Message
Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	SMS/Emulator Timing, z80 optimization. Posted: Sun Nov 14, 1999 6:52 pm
	I couldn't find a copy of "Z80 Optimization for Dummies" at the local bookstores (they say it doesn't exist.. I think they're too lazy to order it.) So I was wondering: When optimizing z80 code, should I be optimizing for t-states or cycles? Somewhere I remember reading that T-states were more critical. I was also wondering how the various sms emulators manage their timing... do they count cycles, t-states, or just instructions (I remember at least some versions of MasterGear counting instructions). And finally.. I haven't been able to find any sort of z80 optimization FAQ anywhere, popular though the z80 still is (in gameboys, ti calcs, etc.) But I have found a few things while writing that never-to-be-finished demo of mine... If there is no other faq maybe we (I) should start one.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Sun Nov 14, 1999 7:38 pm
	[....] Pardon my ignorance, but I don't even know what are T-States! Isn't that another word for "cycles" ? [....] Quote > I remember at least some versions of MasterGear counting instructions That's definitively a bad idea if you want good/accurate emulation, but most (non tricky) softwares would works which such a simple counting scheme. Quote >If there is no other faq maybe we (I) should start one. Documentating anything is a good idea.

Nyef Guest	Posted: Sun Nov 14, 1999 9:05 pm
Nyef Guest	Quote > [....] > Pardon my ignorance, but I don't even know what are T-States! > Isn't that another word for "cycles" ? The Z80 is weird. What it calls a T-state, we call a cycle. It then has "M-cycles", which tend to be composed of either 3 or 4 T-states. A T-state is one pulse of the clock. An M-cycle tends to be how long it takes to read/write memory (it is possible to extend this with wait states). Quote > [....] > > I remember at least some versions of MasterGear counting instructions > That's definitively a bad idea if you want good/accurate emulation, but most (non tricky) softwares would works which such a simple counting scheme. Why am I not suprised that Marat used instruction count timing at one point? :-) Quote > >If there is no other faq maybe we (I) should start one. > Documentating anything is a good idea. Optimizing Z80 code, or optimizing a Z80 emulator? --Nyef

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Sun Nov 14, 1999 10:55 pm
	Quote > > >If there is no other faq maybe we (I) should start one. > > Documentating anything is a good idea. > Optimizing Z80 code, or optimizing a Z80 emulator? Optimizing Z80 code I guess. He mentionned a demo.

Eric Guest	Posted: Mon Nov 15, 1999 4:15 pm
Eric Guest	Quote > > > >If there is no other faq maybe we (I) should start one. > > > Documentating anything is a good idea. > > Optimizing Z80 code, or optimizing a Z80 emulator? > Optimizing Z80 code I guess. He mentionned a demo. It is my understanding that the Z80 micro-architecture is very simple (by today's standards): it's not even pipelined. Consequently, Z80 optimization should mostly consist of cycle-count minimization. There's no need to worry about register interlocks, or caching, or branch prediction, or any of the issues plagueing modern assembly programmers. If any one has any high-performance Z80 (general-purpose) routines please let me know, and I'll post them in the Source Code area. Eric Quinn

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Mon Nov 15, 1999 5:01 pm
	Quote > > > > >If there is no other faq maybe we (I) should start one. > > > > Documentating anything is a good idea. > > > Optimizing Z80 code, or optimizing a Z80 emulator? > > Optimizing Z80 code I guess. He mentionned a demo. Yeah, z80 code. If an emulator is too slow, I just run it on a faster computer. Quote > It is my understanding that the Z80 micro-architecture is very simple (by today's standards): it's not even pipelined. Consequently, Z80 optimization should mostly consist of cycle-count minimization. There's no need to worry about register interlocks, or caching, or branch prediction, or any of the issues plagueing modern assembly programmers. If any one has any high-performance Z80 (general-purpose) routines please let me know, and I'll post them in the Source Code area. I also assume there is no memory refresh to worry about (the sms does use static ram, right?) but there'd be nothing to do about it anyway. I'm glad to hear that people who refer to cycles on a z80 also mean t-states. I'd be using the two interchangably for a long time, and I see that's not a bad thing.

Nyef Guest	Posted: Mon Nov 15, 1999 5:19 pm
Nyef Guest	Quote > I also assume there is no memory refresh to worry about (the sms does use static ram, right?) but there'd be nothing to do about it anyway. The reason you don't have to worry about the memory refresh is because you CAN'T TURN IT OFF. Kudos to the people at Zilog for making such an obnoxious design decision. Quote > I'm glad to hear that people who refer to cycles on a z80 also mean t-states. I'd be using the two interchangably for a long time, and I see that's not a bad thing. It's not nessecarily a bad thing, just remember the difference between a "cycle" (or T-state) and an "M1 cycle" (which is the opcode fetch, at 4 T-states (thank you again, Zilog for integrated DRAM refresh)). --Nyef

Forums

View topic - SMS/Emulator Timing, z80 optimization.