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). lain:

 

[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

 

[bcrew1375]

You think NES is harder than PSX? 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 .

 

[refraction]

You think NES is harder than PSX? 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 .

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

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.