Sega Master System

[albertwesker]

i don't know of any other good forums for general emu development, so i wanted to start a thread on SMS emu dev here. ^_^

anyway, here's an excellent resource for sega master system documentation: http://www.smspower.org/dev/docs/

if anyone has had a go at this system, post your experience here! i'd be glad to hear about it. also, please post any tech documents you know of that you don't see listed in that link! :happy:

maybe a mod can sticky this thread as well?

[blueshogun96]

i don't know of any other good forums for general emu development, so i wanted to start a thread on SMS emu dev here. ^_^

anyway, here's an excellent resource for sega master system documentation: http://www.smspower.org/dev/docs/

if anyone has had a go at this system, post your experience here! i'd be glad to hear about it. also, please post any tech documents you know of that you don't see listed in that link! :happy:

That's cool. I never even thought of even touching sega master system. I'll give it a look, and maybe you'll get some good responses.


maybe a mod can sticky this thread as well?
dunno, a thread has a better chance of being a stiky depending on the interest of the members (as well as mods/admins) in emulation of this console. I tried to get an interest in atari 2600 going, but no luck here. Oh well, at least I found the documentation I was looking for ( even though a google search took F-O-R-E-V-E-R). :plain:

[ShizZy]

If it becomes a useful resource I'm sure it'll be stickied in time. I never though of doing a SMS emu, maybe when I finish my other ones first.

[aprentice]

If it becomes a useful resource I'm sure it'll be stickied in time. I never though of doing a SMS emu, maybe when I finish my other ones first.

I've "looked" into it, as in i've emulated the complete memory system including paging, and used the z80 from my gameboy emu, spent a total of 2 days on it but then put it on freeze because I just didn't have the time and still don't really, the sms doesn't look that bad, but thats not code for its easy, its definately easier than the nes :P

[bcrew1375]

You think NES is harder than PSX? :P I'm thinking one of the best parts about the PSX is that there's no extra hardware to emulate. You don't need to find documentation on all kinds of different mappers :P.

[refraction]

You think NES is harder than PSX? :P I'm thinking one of the best parts about the PSX is that there's no extra hardware to emulate. You don't need to find documentation on all kinds of different mappers :P.


well having seen people work on PSX and worked on PS2 emulation myself, i can tell you now, PSX is a shit load harder than NES ;p

[blueshogun96]

well having seen people work on PSX and worked on PS2 emulation myself, i can tell you now, PSX is a shit load harder than NES ;p
Yeah, emulation of a 6507 vs a MIPS in difficulty? No brainer.

[albertwesker]

ok, so a slight delay and now i'm beginning. i've been pouring over the docs the past few days and one thing in particular is bothering me. maybe some of you with z80 exp can shed some light on this. here are two exerpts from the zilog z80 user manual:

"There are also two sets of accumulator and flag registers and six special-purpose registers."

"The CPU includes two independent 8-bit accumulators and associated 8-
bit flag registers. The accumulator holds the results of 8-bit arithmetic or
logical operations while the FLAG register indicates specific conditions
for 8-bit or 1 16-bit operations, such as indicating whether or not the
result of an operation is equal to zero. The programmer selects the
accumulator and flag pair with a single exchange instruction so that it is
possible to work with either pair."

i understand what the accumulator and flags are for but what i'm having trouble understanding is why there is a 'pair' of them and when to use one or the other. anyone care to expound on these two details?

[TJA]

It is quite simple actually all the z80 registers can be accessed as a pair making a 16-bit register or as an 8-bit single registers, for example the accumulator register is register A, this register is paired with the flag register F making the register AF, you can use unsigned char (e.g. unsigned char reg_A ) to emulate a single register and int for a pair ( e.g. int reg_AF ) but if you do it this way make sure the values in the paired and single register are the same after each cpu execution for example the first 8-bit of the reg_AF>>8 should be equal to the 8-bit value in reg_A, as for the flag register reg_F I found for simplicity sake to just use four integer values e.g. int carry_flag, int zero_flag etc to hold its values rather than having to deal with accessing individual bits of reg_F, it just makes your code easier to follow i think.

Cheers, TJA.

As for when a pair or single is used that just depends on the instruction you are emulating.

[ShizZy]

Yes, like TJA said, the reason for the individual registers and pairs is just for simplicity with the instructions. If you wanted, you could just use 16bit pairs, then mask out just the 8bit parts when they are refferenced, or vice versa, but that could get sloppy. And rather than making sure they are all the same after each instruction, just set them up as a union structure.

[albertwesker]

thanks for the good explanations!
but that leads me to another question.

i think i've decided to just have all the registers seperate as unsigned chars and deal with them that way, but in the case of an instruction like INC BC how would that be addressed?

since the z80 is little endian, how would i handle this? would i increment B or C or the combined value of the pair?

for example if B=0xFF and C=0xFF then what would the outcome of that instruction be? and do i need to be concerned with handeling carries here?



/* INC ss */
(B << 8 | C)+=1; //or
(C << 8 | B)+=1; //or
...
etc.


i'm probably overcomplicating this...

[Cyberman]

Well I recomend doing this instead
UINT16 Temp = (B << 8) | C;
Temp++;
B = Temp >> 8;
C = Temp & 0xFF;
this rids you of overflow detection in C
You should do under/overflow detection in Temp though so perhaps it should be a UINT32. So Temp++ and it overflows 1 bit will be 65536 or 0x10000 All you need to do is see if it's > than 65536 and set the appropriate flags.

Cyb

[ShizZy]

Cyb's way is better, but:

if(C==0xff)
{B+=1}
C+=1;

will work. OR you could save yourself a lot of agony and just do:

union REGISTERS
{
struct{unsigned short AF,BC,DE,HL,SP,PC;};
struct{unsigned char F,A,C,B,E,D,L,H,SPlo,SPhi,PClo,PChi;};
} reg;

Then just do reg.BC+=1; ;) If you don't know what a union does, basically it allows you to redefine the same memory with different variable names/data types.


Edit:

so perhaps it should be a UINT32.
Bad idea. Overflow protection isn't really an issue, you'd just end up over cluttering all your code. It's better just to handle data as the actual system would.

[TJA]

I never thought of using a union maybe I will change my code to use one, as I have manually checked almost every opcode and although I have fixed a couple of bugs my phoenix emu still has the same errors, maybe if i change to using a union i might fix something i missed in my awakward register code. Anyways I'm going to do this then move on to gameboy emulation as I only did my phoenix emulator as a learning project ( displaying graphics).

Cheers, TJA.

EDIT: Think I could have found something, I implemented these the same.
Can someone tell me the difference between the instructions:

RLCA and RLA???

EDIT2: implemented union and cleaned up cpu code which fixed some graphics errors in phoenix, but emulation still coming to halt/logo issues.
Also now I can chose between compiling a z80 or gameboy cpu.

[ShizZy]

RLCA - rotates A left one bit, placing bit 7 at bit 0 as well as in the Carry flag.
RLA - rotates A left one bit, placing bit 7 into the Carry flag and the contents of the Carry flag into bit 0 of A.

The difference is that RLCA places bit7 of register A into bit0 of register A, and RLA places the contents of the Carry Flag into bit0 of register A. (If that makes sense).

In RLA make sure that you don't set bit7 to the carry flag first, and then put that into bit0 of A, because then you'd just be putting bit7 into bit0.

Edit: Do you have any phoenix docs? Just for the hell of it I'd adapt my gameboy cpu.

[albertwesker]

ShizZie, that's a great idea with the unions. i never thought of using them.
and by the way, the op i mentioned before (INC ss) doesn't even take carries into consideration according to the docs, but its 8-bit equivelent (INC r) does... well, half carries anyway... so i was worried for nothing :P

anyway, thanks for everyones input! this is starting off to be a fun project!

[TJA]

Thanks shizzie I fixed those instructions but still have the same problems, oh well. I've started on my gameboy emu just setting up basic structure, memory routines, etc.
And yeah I have some info on phoenix its from the old arcade emulation how to document.
Also I have a doc with the differences between the gameboy cpu, and z80 ( which I already posted in a thread a while back so you might already have it )

TJA.

There is also some info on sound in the aeht doc but I'm not to sure about sound emulation I think its DOS Specific stuff I can remember.

[ShizZy]

Thanks for the docs. The phoenix.txt is a little vague. I hope it's everything I need to adapt my z80 emulator. Is there anything else you used?

Btw keep us updated on your Gameboy progress, nice to see other emulators moving foreward. Havn't had much time to work on mine latelly, dev slowed down a lot it's mostly just tweaking and hardcore bug fixing.

[TJA]

Well I based most of my graphics information on the jabawape 0.8 source available from http://caesar.logiqx.com/php/emulator.php?id=jabawape I wasn't really sure about pallet information so I just used the source from that emulator from the pallet.h and removed >>2 not sure what it did, I think something with allegro. As for my gameboy emulator progress, I have been trying to build a GUI for my phoenix emulator so that I can build a debugger and trace down the bug in my cpu core before I move onto the gameboy emu.

I have question though. I was building the emulator with portability in mind at first I thought about using GTK+ for the GUI but have found difficulty finding examples of it working with SDL especially on win32, so then I looked at wxWidgets but also wasn't sure about how well it worked with SDL too. Anyway I have moved on to create a Tcl/Tk based debugger for my emu which is fine for the moment, but I would like to latter add a GUI to my gameboy emu does anyone have any advice on building a GUI, with one of these toolkits, shizzie I see your gameboy emu uses SDL and has a GUI, I'm guessing you used Visual C++ as it seem to integrate well, not sure if you didn't use Visual studio though I would be keen to know how you did it. Anyway as for your next project I suggest the Sega Master System this is why I chose the gameboy ( so I could re-use the z80 core ) plus your emulating two systems at once the sega master system and the sega game gear. I don't know though its up too you, personally I have a soft spot for sega systems the first console I ever played was my uncles sega master system, I owned a game gear, my brother had a mega drive (genesis) and I later had a Saturn.

Cheers, TJA.

[ShizZy]

Thanks for the tips on system choice. Actually, the public build of my emulator uses directx for graphics, and sdl for sound. In my latest private build, I instead use 100% sdl for everything. Why? Because I like it better, and it's more portable. For a GUI, I use something like the BGP emulator. Basically, it's an SDL window with titlebar and a logo, and when you right click the titlebar a popup menu comes up with all the options - ie you can open the debugger/gfx settings/etc. I really like it, and it uses minimal win32 making it very portable. Download BGP if you haven't already and see if you like it.

[albertwesker]

things are moving along, but i was wondering if someone could explain how to determine if the half-carry flag is to be set or cleared. the P/V flag is a little confusing too, but i haven't come accross an opcode where that flag is affected yet.

i've read that most emulation problems with the z80 occur because of incorrect flag register implementation... :plain:

[ShizZy]

A carry occurs if the value of a bit carries over to the next bit to the left after an operation occurs. So say if it says to set Flag H if there is a carry from bit3, you check if bit4 (the next bit) is set after the operation. Simple as if(answer&0x10). A half carry is the same as a carry, except that it only occurs in the lower nibble of the byte.

Just so you know the H and N flags are BCD flags, and thus only used by the DAA function for scores and what not. So H/N flag errors for the most part won't cause a game to break. You should be more concerned about the Carry and Zero flags, which are used for jumps and things.

[blueshogun96]

Glad to see that this thread is thiving :)

[albertwesker]

A carry occurs if the value of a bit carries over to the next bit to the left after an operation occurs. So say if it says to set Flag H if there is a carry from bit3, you check if bit4 (the next bit) is set after the operation. Simple as if(answer&0x10). A half carry is the same as a carry, except that it only occurs in the lower nibble of the byte.

Just so you know the H and N flags are BCD flags, and thus only used by the DAA function for scores and what not. So H/N flag errors for the most part won't cause a game to break. You should be more concerned about the Carry and Zero flags, which are used for jumps and things.

shizzie, wouldn't it be (answer&0x8) to check the fourth bit? and also, in a carry operation in binary arithmetic, if the fourth bit was already a 1, then a carry from the addition of the third bits would cause the fourth bit to be 0 and cause it to carry to the fifth bit, etc.

here is an example of this scenario:

in this case the fourth bit for each operand was already 0, so the carry to the fourth bit made the fourth bit 1 for a binary result of 1000 or 0x8.

0000 0100
0000 0100
----------
0000 1000

here, the fourth bit is already set in one of the operands (in this case, the first), so a carry from the addition of the third bit causes another carry in the addition of the fourth over in to the fifth, resulting in the binary value 10000 or 0x10.

0000 1100
0000 0100
----------
0001 0000

taking this into consideration, i think to figure out if a half carry occurs at the third bit during and INC r instruction, where the register is simply incremented by '1', i would simply do this:

//run this before the increment operation
if(reg.B&0x7){
// then the result is a carry
}

in other words if
reg.B = 0111
and 0111 + 0001 = 1000 then
we have a half-carry situation and need to set the appropriate flag.

perhaps i'm missing something? :plain:

[ShizZy]

Yeah... it isn't the 4th bit, it's bit 4. There's bits 0-7, so actually it'd be the 5th bit - 0x10. And by bit three they mean the 4th bit. That's how the docs refer to them ;)

[blueshogun96]

Ok, I have officially started my SMS emulator a few days ago. Right now, I'm just trying to get my z80 core out of the way. Heh, the jump from the 1802 to the z80 is a bit more difficult than I anticipated, lol.

I have a quick question about the z80 state flags. This is how I calculate my flags so far.

// Bit 3 of status thingy
#define RegX(p) ( ( p >> 3 ) & 0x1 )

Is there a better way of calculating flags? I'm getting lost quite easily here on the z80 emulation part. My strengths ly in the GPU not CPU :\

[ShizZy]

You're trying to see if there's a carry from bit 3, right?
This would be better:

#define RegX(p) (p&0x10)

Check bit 4 to see if it'd be carried into the bit 3. Easy as that.

[blueshogun96]

Sorry, it took me so long to reply, thanks for the info :) Been tied up with other stuff >_>

[albertwesker]

here's an update of where i am. the cpu core is complete and the vdp is nearing completion. rom paging is next, then sound. so far this is easier than i had anticipated. thanks to finally sitting down and pouring through some documentation, things starting coming together. here's an early screenshot of Hang On on the Mega Master System:

http://www.infourmation.com/images/mega.jpg

and obviously, there's still quite a bit of work left.

[ShizZy]

Looking good, keep it up!

[blueshogun96]

Exellent, you are doing well. Keep up the good work sir.

[albertwesker]

another update. vdp nearly finished, with tile flipping and bg priority left. sound next.

http://www.infourmation.com/images/mega1.jpg http://www.infourmation.com/images/mega2.jpg http://www.infourmation.com/images/mega3.jpg
http://www.infourmation.com/images/mega4.jpg http://www.infourmation.com/images/mega5.jpg http://www.infourmation.com/images/mega6.jpg
http://www.infourmation.com/images/mega7.jpg http://www.infourmation.com/images/mega8.jpg http://www.infourmation.com/images/mega9.jpg
http://www.infourmation.com/images/mega10.jpg http://www.infourmation.com/images/mega11.jpg http://www.infourmation.com/images/mega12.jpg

[smcd]

Nice :)

[hap]

I see you implemented tile flipping (updated screenshots :P )

Anyway, looking good.
How about an alpha/beta for us to try out ?

[albertwesker]

thanks hap!

i've got a few issues i need to fix in the cpu core and the mem mapper and then it will be ready for an alpha release.

[ShizZy]

Nicelly done :)

[GbaGuy]

edited: I found what I needed at links provided earlier in the thread. I failed horribly at GB emus. I can write a chip8 emulator as fast as it takes to type it out. I can write a NES emu to the point of having most of the common mapper games playable (no sound). Let's watch me fail at SMS...

[albertwesker]

edited: I found what I needed at links provided earlier in the thread. I failed horribly at GB emus. I can write a chip8 emulator as fast as it takes to type it out. I can write a NES emu to the point of having most of the common mapper games playable (no sound). Let's watch me fail at SMS...

in case you didn't know, the gameboy's z80 has only a subset of the opcodes that the master system's z80 has.

[GbaGuy]

Yeah, I realized that rather quickly. I started working on GB emu once more, this time in Java (for the hell of it). I don't think CPU emulation is my problem. I just never seem to get the graphics and interrupts working right. Perhaps this time I'll post in the GameBoy thread for help once I get everything implemented and see what I can get to work and what doesn't, etc.

[aprentice]

i tried a sms emu a year or two ago, i only got complete memory emulation with banking etc done then i just got bored and stopped working on it, maybe i will continue it in the future when im done with my current projects, it didnt look too difficult

[hap]

Emulating a Z80 sucks, it's just too.. bloated.

Why I'm really replying, good Z80 documentation:
- the official one, find it on the smspower link albertwesker posted
- "The Undocumented Z80 Documented", the one on smspower is outdated, get it from http://www.myquest.nl/z80undocumented/
- ZEXALL is a very good Z80 emulation test, it's included with YAZE: http://www.mathematik.uni-ulm.de/users/ag/yaze-ag/

[krypt100]

some progress on my sms emulator which I started 2 weeks ago, most of the time was spent on the Z80 (still buggy and incomplete), as of now it's still far away from completion, interrupt handling is broken, scrolling is not implemented, sprite layer is missing, and the bg tiles are flipped.

screen shots from the nametable area of the VRAM

[hap]

nice results pretty quickly :)

[-indecisive-]

Looks great. When I'm not hammered from school I'll give this a try for sure.

[JKKDARK]

some progress on my sms emulator which I started 2 weeks ago, most of the time was spent on the Z80 (still buggy and incomplete), as of now it's still far away from completion, interrupt handling is broken, scrolling is not implemented, sprite layer is missing, and the bg tiles are flipped.

screen shots from the nametable area of the VRAM

Did you do some progress since August? :)

[CodeSlinger]

Im having a look at starting a sega master system emulator now I've finished my gamboy emulator. I've had a quick look through the documentation and it looks easier than the gameboy which I didnt think would be the case. The only issue im having so far is I havent found anything related to the reset state of the SMS, like what do the registers get set to on startup and what is the stack pointer initialized to along with the program counter?

Anyone know of any documentation which explains this?

I cant see this project taking that long, maybe two months including sound emulation.

Thanks

Edit:

Im guessing that as I cannot find any documentation on this, perhaps the system sets the registers etc to a known state itself on powerup, so I dont need to set them the game will automatically do it... just a thought.

[nameuser]

CodeSlinger - you can always get a BIOS, emulate it correctly, and check the system state after the BIOS turns itself off. As for running the BIOS - you just need to set PC to 0, I believe.

EDIT : also, interrupts are disabled before running the BIOS, of course. Also, both SP and AF are apparently 0xffff before running the BIOS (other registers are undefined) but I dunno if there are any BIOSes that make use of that - there are only a few, after all. (this is from the "undocumented Z80 documented" document and, again, applies to the machine's state before the BIOS, not before the games)

[CodeSlinger]

Thats a good idea actually, thanks!

So far I've programmed about 50% of the Z80 cpu so hopefully by the weekend I can start getting some results.

[AamirM]

Hi,

@ CodeSlinger:
If your still wondering why Shadow Dancer doesn't run on your SMS emu, SP should be 0xDFF0 ;) (disasm the bios).

stay safe,

AamirM

[CodeSlinger]

Thanks mate :)

I now have one game showing the first screen which isnt bad considering ive only been working on it this weekend.

One question I do have though is the vcounter on the VDP has 192 active scanlines (default) and a total of 261 scanlines (default). When it goes over 261 it wraps back to 0. This means that an 8 bit variable cannot hold the full vcounter range because it can only hold a range of 0-255 and I need to store a range of 0-261. Now it seems quite obvious to me that I shouldnt be using an 8 bit variable to store vcounter and should be using a 16 bit which means I easily have enough room to store the vcounter range. All this seems fine to me.

However when the ROM reads from port $7F (mirrored in $7E) it stores the value of the vcounter in one of the 8 bit registers. So how can an 8 bit register store the correct value of vcounter because the vcounter cannot always be represented in an 8 bit number? The opcode responsible for retrieving the vcounter is "IN A, (n)" which doesnt set any flags otherwise I thought thats how it could do it.

Thanks for any help

[AamirM]

Hi,

VCounter is always between 0-255. It jumps (comes back) between different screen areas. For example, on line 259 (on 192 active lines display) vcounter value would be 253. So everything can come in 8-bits ;) .

stay safe,

AamirM

[CodeSlinger]

Thanks for the info! Sounds a bit hacky to me lol. Oh well simple enough to implement.

I havent been able to work on to emu for a few days now. I have two games showing their first screens. I dont think it will be that long until I change something and most games start showing something.

[AamirM]

Hi,

Its not hacky :) . Its simply how the real thing works. Here is what a real Master system would return for each line (all creadits to Charles MacDonald, he probed these):


uint8 vc_ntsc_192[] =
{
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F,
0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F,
0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F,
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F,
0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A, 0x7B, 0x7C, 0x7D, 0x7E, 0x7F,
0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E, 0x8F,
0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9A, 0x9B, 0x9C, 0x9D, 0x9E, 0x9F,
0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7, 0xA8, 0xA9, 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF,
0xB0, 0xB1, 0xB2, 0xB3, 0xB4, 0xB5, 0xB6, 0xB7, 0xB8, 0xB9, 0xBA, 0xBB, 0xBC, 0xBD, 0xBE, 0xBF,
0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF,
0xD0, 0xD1, 0xD2, 0xD3, 0xD4, 0xD5, 0xD6, 0xD7, 0xD8, 0xD9, 0xDA,
0xD5, 0xD6, 0xD7, 0xD8, 0xD9, 0xDA, 0xDB, 0xDC, 0xDD, 0xDE, 0xDF,
0xE0, 0xE1, 0xE2, 0xE3, 0xE4, 0xE5, 0xE6, 0xE7, 0xE8, 0xE9, 0xEA, 0xEB, 0xEC, 0xED, 0xEE, 0xEF,
0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, 0xFF,
};

stay safe,

AamirM

[CodeSlinger]

Thanks for the info you've been a great help!

CS

[CodeSlinger]

Hi Guys,

It has taken me longer than I'd of liked to make progress with my emulator, mainly because I just havent had the time to work on it that I hoped for.

Anyway here are some screenies:


The alex kidd image is slightly out of date as I now have transparency working on sprites.

Sonic is completable which is great but some games dont even make it to the first screen. This is what I'm going to look into next.

I've ran zexall through my emulator and I pass all tests apart from the following:

aluop a, <ixh,ixl,iyh,iyl>
aluop a,<b,c,d,e,h,l,(hl),a>

aluop are the 8 bit add,adc,sub,sbc,and,or,xor,compare instructions. Interestingly enough the following instructions pass zexall

aluop a, nn
aluop a, <<ix,iy>+1>

All the opcode emulation functions I use for aluop are the same for both the aluop tests that work and for the ones that dont. So I dont understand why they work in some tests and not others.

Hopefully I'll have these fixed soon and then can work on debugging the games that arent working. Then it'll be sound emulation time. Fun fun fun


Edit:

Removed images, no longer have working server.