z80 opcode documentation.

thegamefreak0134 · Post by **thegamefreak0134** » Fri 20 Oct, 2006 4:47 pm

I am writing a GB emulator. Since the GB and GBC both use a variant of the z80 processor, I've been using a lot of different things. I'm bascally going to code every single instruction into the thing before I try to write a display routine and run anything. As I was going down the list however, I found quite a few (mainly the CB prefixed instructions) that I could not figure out the useage for. There was also a lot of missing info on flags. The docs I have mention which flags are affected, but usually fail to specify how. And yes, I realize that the GB only has 4 flags, whereas a typical z80 processor should have 8, but we won't go there.

Can someone provide me with some much more complete documentation on the z80 instruction set? I have lots of info on how the GB itself actually displays the screen based on the registers and such, but I can't seem to get the emulation of the core down at all. Perhaps the writers of VTI and PTI could help me out? Once I have the processor running, the rest should be relatively simple.

-gamefreak

Post by **benryves** » Fri 20 Oct, 2006 4:57 pm

As far as I'm aware, the "Sharp80" is not entirely compatible and uses some different opcodes to the regular Z80. Bearing that in mind, I have lots of nice tables for the Z80 from this site.

Also, take a look at the SMS Power! Z80 section - they have the original user manual up for download.

leofox · Post by **leofox** » Fri 20 Oct, 2006 5:33 pm

As far as i know, the GB processor is more like the 8080 than the z80. For example, instructions take 4,8,12 T states to compute, for the z80 it's 4,7,10.

CoBB · Post by **CoBB** » Fri 20 Oct, 2006 5:50 pm

I wrote up a reference at WikiTI, but it’s really just a reference. All the flags, including all the ‘undocumented’ behaviour is covered, but I have no idea how much of that can be applied to this variant.

thegamefreak0134 · Post by **thegamefreak0134** » Mon 23 Oct, 2006 3:42 pm

Wow. The references y'all gave are a lot to swim through, but it's usefull. Thanks! I've finally started to work on the finer details of the "core" if you will, and it will take a few weeks but it should work out alright.

I do have one question though. On some of the documentation there are jp and call commands that have a "$+2" following them, and have no bytes listed in the opcode as arguments. This basically means to relative jump to the one byte address following the opcode and to directly jump to the two byte address (depending on the command of course) yes?

Also, two questions concerning 16-bit numbers. In what order are 16-bit numbers stored on the stack, and in what order will they appear in memory? I want to say they get "pushed" high, then low, but get "written" low then high, but I'm not quite sure. Confirmation on this?

-gamefreak

King Harold · Post by **King Harold** » Mon 23 Oct, 2006 3:56 pm

Sean McLaughlin wrote: SP is decremented and regMSB is stored into the memory location pointed to by SP. SP is decremented again and regLSB is stored into the memory location pointed to by SP.

Which means that in memory, the LSB comes before the MSB, and that was to be expected really.

CoBB · Post by **CoBB** » Mon 23 Oct, 2006 4:30 pm

thegamefreak0134 wrote:Also, two questions concerning 16-bit numbers. In what order are 16-bit numbers stored on the stack, and in what order will they appear in memory? I want to say they get "pushed" high, then low, but get "written" low then high, but I'm not quite sure. Confirmation on this?

The Z80 is little-endian, which means that all instructions involving 16-bit memory operations (ld, push, pop, call, ret, rst) treat the numbers as ‘LSB first’.

Post by **benryves** » Mon 23 Oct, 2006 4:38 pm

The Z80 Family CPU User Manual file should be of interest. It describes things fairly thoroughly.

thegamefreak0134 · Post by **thegamefreak0134** » Tue 24 Oct, 2006 8:04 pm

Ahh... that would certainly explain why the second instruction in the header has the bytes stored as 5010h byt the instruction gets translated jp 150h. It's all so clear now. Thanks!

necro · Post by **necro** » Tue 24 Oct, 2006 9:36 pm

?.? holy $%!7...it makes so little sense...

Saibot84 · Post by **Saibot84** » Thu 26 Oct, 2006 4:14 pm

actually, it makes perfect sense to anyone working in z80 asm

King Harold · Post by **King Harold** » Thu 26 Oct, 2006 4:22 pm

Wait.. shouldn't it be $1050?

Saibot84 · Post by **Saibot84** » Thu 26 Oct, 2006 4:24 pm

he probably missed typing the 0 after the 1 in 1050

Post by **benryves** » Thu 26 Oct, 2006 4:32 pm

Makes little sense to me. 150h would be stored as {50h, 01h} - not {50h, 10h} (so {C3h, 50h, 01h} for jp 150h).

DigiTan · Post by **DigiTan** » Fri 27 Oct, 2006 4:57 am

You mean there are sickos out there who store the little end of their bytes first?!!? Prepare the invasion immidiately!

The $0150 thing is an honest typo. Will be interesting seeing how well the calc can be emulated.