Forums

I take back every bad thing I ever said about anyone not wanting to write their own CPU core. Wanna know why? BECAUSE IT'S TEDIOUS AS HELL!!! I figured since my company left from spring break and I only had yesterday and today full of freetime that I would "try out" this CPU emulation stuff but damn does it drain the life out of you! You have to sit down and do instruction after instruction after instruction. I figured I'd try the 6502 since it's so simple, and it is a pretty simple and straight-forward chip to emulate but damn it takes a lot to emulate! In total I've spent 4 and 1/2 hours programming and studying and so far I've come up with 187 instruction macros, and 10 supported instructions. I need to finish the other 40 or 50 macros and then add support for the rest of the instructions from the macros. But damn, if the 6502 takes this much time, My GOD, I can't imagine the Z80 (with it's 600 or so instructions) or the 68000!!

Chris :o|

Quote

> I take back every bad thing I ever said about anyone not wanting to write their own CPU core. Wanna know why? BECAUSE IT'S TEDIOUS AS HELL!!! I figured since my company left from spring break and I only had yesterday and today full of freetime that I would "try out" this CPU emulation stuff but damn does it drain the life out of you! You have to sit down and do instruction after instruction after instruction. I figured I'd try the 6502 since it's so simple, and it is a pretty simple and straight-forward chip to emulate but damn it takes a lot to emulate! In total I've spent 4 and 1/2 hours programming and studying and so far I've come up with 187 instruction macros, and 10 supported instructions. I need to finish the other 40 or 50 macros and then add support for the rest of the instructions from the macros. But damn, if the 6502 takes this much time, My GOD, I can't imagine the Z80 (with it's 600 or so instructions) or the 68000!!

Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me,

I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end.

It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually.

I am already playing with an r3000 disassembler, and am considering starting an SH-2 core.

And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40".

Quote

> Chris :o|

--Nyef

Quote

> > I take back every bad thing I ever said about anyone not wanting to write their own CPU core. Wanna know why? BECAUSE IT'S TEDIOUS AS HELL!!! I figured since my company left from spring break and I only had yesterday and today full of freetime that I would "try out" this CPU emulation stuff but damn does it drain the life out of you! You have to sit down and do instruction after instruction after instruction. I figured I'd try the 6502 since it's so simple, and it is a pretty simple and straight-forward chip to emulate but damn it takes a lot to emulate! In total I've spent 4 and 1/2 hours programming and studying and so far I've come up with 187 instruction macros, and 10 supported instructions. I need to finish the other 40 or 50 macros and then add support for the rest of the instructions from the macros. But damn, if the 6502 takes this much time, My GOD, I can't imagine the Z80 (with it's 600 or so instructions) or the 68000!!

> Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me,

> I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end.

> It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually.

> I am already playing with an r3000 disassembler, and am considering starting an SH-2 core.

> And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40".

> > Chris :o|

> --Nyef

The problem with the SH CPUs is that they are 68000 CPUs on steroids.

From the SH-1 Product Brief: "32-bit internal data paths / 16-bit external data paths" Just like the 68000. "16-bit fixed instruction set" Just like the 68000.

The SH-2 at least has 32-bit external data paths, but that makes it a 68020 or a 68030, I'm not sure which.

The addressing modes available are almost as bad. And I haven't figured out if the pipeline stuff is important to emulate or not.

In short, I'd rather tackle a MIPS chip with their fucked up cache semantics, screwed up control registers, and 32-bit instruction encoding from hell than deal with the SH-2. And I will do neither of them without my full toolkit (code generators, test frameworks, etc.).

But first, I'd like to see Phantasy Star II running in DarcNES. And perhaps Sonic CD and Lunar (Hrm... Looks like my Ambition and my Ego are making a run for it, I hope they don't get beaten too badly). ^_^

--Nyef

Quote

> But first, I'd like to see Phantasy Star II running in DarcNES. And perhaps Sonic CD and Lunar

Now that would be great ^_^

Quote

> Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me,

Ouch! That must have sucked! I tried doing that and I guess that's why I bombed with my very first Z80 Core. This is actually my 2nd time doing a core and things are running much more smoothly. I also have lots of good documents this time around(ones that even tell you every possible instruction available). With these docs it takes the venture time away (having to figure out what instructions do what and what their machine equivalents are) and gives me more time to conentrate and code. But shit, last night, even with all this stuff right be for my eyes, it was my eyes and my brain that gave out at about 3:00 last night (3:00AM). I finished the 148 machine/instruction macros. Now I need to emulate all 148 of them and test them on some 6502 data.

Quote

> I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end.

Same thing with me. Except my un-ending project is the Z80.

Quote

> It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually.

Does the 6280 work similar to the 6502? All this time I was thinking that the 6280 was some custom (built from scratch) chip that was designed by NEC or something.

Quote

> I am already playing with an r3000 disassembler, and am considering starting an SH-2 core.

My dream would be to create my own 68000 core, Z80 core, and SH2 core so that way I can run the 32X games. I don't see why my 366Mhz computer can run those games.

Quote

> And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40".

You're right. 128 to be exact. I was so tired last night that I was seeing things. Having to write lines and lines of




....


#define SBC_IdX	0xE1


#define CPX_ZP		0xE4


#define SBC_ZP		0xE5


#define INC_ZP		0xE6


#define INX			0xE8


#define SBC_Im		0xE9


#define NOP			0xEA


#define CPX_Ab		0xEC


#define SBC_Ab		0xED


#define INC_Ab		0xEE


#define BEQ			0xF0


#define SBC_Id_Y	0xF1


#define SBC_ZP_X	0xF5


#define INC_ZP_X	0xF6


...

can really affect you.

Chris :o)

The only Sega console I haven't used yet is the Sega CD and the only game I've ever played was Sonic CD, and even that was the PC port, not the genuine one on the Sega CD. What makes the Sega CD so good? Is it like some mega attachment like the 32X? Does it have a big boost in RAM or an extra processor? Oh, and would it be possible to convert a Sega CD game into a solid .BIN or .SCD file or something? Or would the games wind up being 100-600MB anyway? There's lots of games out there that I've never even heard of. I keep hearing good things about some game galled Lunar and stuff. I'd like to try it someday.

Chris :o)

Ignore that 128 number. The number is 148 like the top.

Chris :o)

Quote

> The only Sega console I haven't used yet is the Sega CD and the only game I've ever played was Sonic CD, and even that was the PC port, not the genuine one on the Sega CD. What makes the Sega CD so good? Is it like some mega attachment like the 32X? Does it have a big boost in RAM or an extra processor? Oh, and would it be possible to convert a Sega CD game into a solid .BIN or .SCD file or something? Or would the games wind up being 100-600MB anyway? There's lots of games out there that I've never even heard of. I keep hearing good things about some game galled Lunar and stuff. I'd like to try it someday.

The big thing about the SegaCD (aside from the CD drive) was the 12 MHz 68000 processor (even more speed than the Genesis CPU). It also had SRAM, and some hardware scaling/rotating support (which, by all reports, was slower than using the CPU to do it).

And most SegaCD games used CD audio, and were megabytes in size, so converting them to carts is not exactly feasable.

Quote

> Chris :o)

--Nyef

Quote

> > Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me,

> Ouch! That must have sucked! I tried doing that and I guess that's why I bombed with my very first Z80 Core. This is actually my 2nd time doing a core and things are running much more smoothly. I also have lots of good documents this time around(ones that even tell you every possible instruction available). With these docs it takes the venture time away (having to figure out what instructions do what and what their machine equivalents are) and gives me more time to conentrate and code. But shit, last night, even with all this stuff right be for my eyes, it was my eyes and my brain that gave out at about 3:00 last night (3:00AM). I finished the 148 machine/instruction macros. Now I need to emulate all 148 of them and test them on some 6502 data.

Oh, not at all. I started testing the core before I wrote it (well, I put the main loop and the unimplemented code handler in first), that way I know I got most of the instructions right. The only catch when writing a a core generator is that you can have up to three macro processors in the mix (as opposed to an ASM core, which is limeted to two). And when my brain last fried, I went to bed. The following morning I cleared up the problem that was frying my brain in about a minute.

Quote

> > I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end.

> Same thing with me. Except my un-ending project is the Z80.

Well, my real unending project is DarcNES. The 68000 is merely the longest-running broken module (except maybe the PC-Engine emulation, I'll have to check that).

Quote

> > It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually.

> Does the 6280 work similar to the 6502? All this time I was thinking that the 6280 was some custom (built from scratch) chip that was designed by NEC or something.

It's a 65c02 with some of the bit manipulation instructions twisted, block movement instructions, an integrated MMU, and a few other new instructions. It was designed by Hudson Soft (hence HuC6280).

Quote

> > I am already playing with an r3000 disassembler, and am considering starting an SH-2 core.

> My dream would be to create my own 68000 core, Z80 core, and SH2 core so that way I can run the 32X games. I don't see why my 366Mhz computer can run those games.

Just you wait. I have the 32X-CD version of Night Trap around somewhere. I expect that it will hammer my Celeron 333A into submission. A Z80, two 68000s, two SH-2s, three video systems, three audio systems, and streaming video. Now that's a lot of emulating.

Quote

> > And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40".

> You're right. 128 to be exact. I was so tired last night that I was seeing things. Having to write lines and lines of
> > .... > #define SBC_IdX 0xE1 > #define CPX_ZP 0xE4 > #define SBC_ZP 0xE5 > #define INC_ZP 0xE6 > #define INX 0xE8 > #define SBC_Im 0xE9 > #define NOP 0xEA > #define CPX_Ab 0xEC > #define SBC_Ab 0xED > #define INC_Ab 0xEE > #define BEQ 0xF0 > #define SBC_Id_Y 0xF1 > #define SBC_ZP_X 0xF5 > #define INC_ZP_X 0xF6 > ... >

> can really affect you.

You, sir, are nuts. First of all, you use an enum for that (see Marat's Z80 core). Second, you don't do that in the first place. Most of that falls out if you use a jump table.

You need macros for flag setting, memory access, addressing modes, and most of the instruction types, but you don't use macros that are used in exactly one instruction (unless you need the same operation 8 times in one instruction, like TMA on the 6280).

You then write a small (3-5) line function to actually do the job.



void cpu6502_op_LDA_imm(struct cpu6502_context *context)


{


	Get_Immediate();


	Do_LDA();


}

If you are writing an ASM core, you also want a macro to do the whole next instruction thing (cycle counters, and either returning to a central dispatch routine or dispatching the next instruction directly).

Quote

> Chris :o)

--Nyef

Quote

> > The only Sega console I haven't used yet is the Sega CD and the only game I've ever played was Sonic CD, and even that was the PC port, not the genuine one on the Sega CD. What makes the Sega CD so good? Is it like some mega attachment like the 32X? Does it have a big boost in RAM or an extra processor? Oh, and would it be possible to convert a Sega CD game into a solid .BIN or .SCD file or something? Or would the games wind up being 100-600MB anyway? There's lots of games out there that I've never even heard of. I keep hearing good things about some game galled Lunar and stuff. I'd like to try it someday.

> The big thing about the SegaCD (aside from the CD drive) was the 12 MHz 68000 processor (even more speed than the Genesis CPU). It also had SRAM, and some hardware scaling/rotating support (which, by all reports, was slower than using the CPU to do it).

it was my understanding that the scaling and rotation was the job of the second (12mhz) 68000, which ran in tandem with the original 68000.

eh?

Quote

> it was my understanding that the scaling and rotation was the job of the second (12mhz) 68000, which ran in tandem with the original 68000.

No, apparently there's an ASIC that can do it. But as I said, using the CPU is apparently faster.

--Nyef

Quote

> You, sir, are nuts. First of all, you use an enum for that (see Marat's Z80 core). Second, you don't do that in the first place. Most of that falls out if you use a jump table.
> You need macros for flag setting, memory access, addressing modes, and most of the instruction types, but you don't use macros that are used in exactly one instruction (unless you need the same operation 8 times in one instruction, like TMA on the 6280).

I don't really understand why what I'm doing is crazy. First, the 148 macros that I created are going to be used in a case like this...




switch(memory[PC])


{


case LDA_Ab: A = Absolute(memory[&PC]); break;


case TXA: A = X; break;


case LDA_IdX: A = PreIndexIndirect(memory);

That's example code. I'll handle the details like Carry, Overflow, and cycles in my real code. Almost any method that you use will result into a ton of code anyway. There's no way around that, at least one that I know of. I've already made the PreIndex, PostIndex, Absolute stuff into assembly functions to give it some speed(C/Asm). And I'm already too deep into my way of doing it to turn back and re-code something new. I'm still willing to learn though.

Quote
> You then write a small (3-5) line function to actually do the job.

>
> void cpu6502_op_LDA_imm(struct cpu6502_context *context)


> {


> 	Get_Immediate();


> 	Do_LDA();


> }


> 

Ah. Function calls. I don't want to have 148 functions and they work exactly like the way I was doing, but slowdown the emulation. I've heard and seen too many examples where functions slow down high-priority programs. Even if it takes more code, I try not to use them.

Quote

> If you are writing an ASM core, you also want a macro to do the whole next instruction thing (cycle counters, and either returning to a central dispatch routine or dispatching the next instruction directly).

Chris :o)

I'm not really using a Jump Table. I'm using the macros instead of flipping back and fourth through my book everytime I want to find the hex value of an instruction. I devised a system so that way I could use english statements instead of hex stuff.

I think everything I'm doing will lay out fine. I'm making a hell of a lot more progress than I did the last time. I tested Castlevania III to try out the 6502 core and it worked so far! The first instruction was BRK, the second was LDA Absolute! Then I tried it on Tetris and it said, BRK, then LDX Immediate, then STX Absolute, next was CMP Zero Page, it was sweet! Everytime I see stuff like that it makes me proud and want to work harder.

Chris :o)

Quote

> The problem with the SH CPUs is that they are 68000 CPUs on steroids.

> From the SH-1 Product Brief: "32-bit internal data paths / 16-bit external data paths" Just like the 68000. "16-bit fixed instruction set" Just like the 68000.

> The SH-2 at least has 32-bit external data paths, but that makes it a 68020 or a 68030, I'm not sure which.

> The addressing modes available are almost as bad. And I haven't figured out if the pipeline stuff is important to emulate or not.

> In short, I'd rather tackle a MIPS chip with their fucked up cache semantics, screwed up control registers, and 32-bit instruction encoding from hell than deal with the SH-2. And I will do neither of them without my full toolkit (code generators, test frameworks, etc.).

> But first, I'd like to see Phantasy Star II running in DarcNES. And perhaps Sonic CD and Lunar (Hrm... Looks like my Ambition and my Ego are making a run for it, I hope they don't get beaten too badly). ^_^

> --Nyef

Hmmm.... if you're writing a SH1/SH2 eumlator, maybe you'd be able to have the first emu to support Virtua Racing ^_^

~unfnknblvbl

Quote

> Ah. Function calls. I don't want to have 148 functions and they work exactly like the way I was doing, but slowdown the emulation. I've heard and seen too many examples where functions slow down high-priority programs. Even if it takes more code, I try not to use them.

This is a perfect example on where you should use the 'inline' keyword :) this would not cause it to run slower actually since all of the code would be inline. it would in effect end up being the same outpt of code most likely from what your macros are doing but it looks cleaner to do it with lots of little functions. Also, you can make your macros look like functions as well, which would also clean things up a little bit.

ATani

Quote

> > Ah. Function calls. I don't want to have 148 functions and they work exactly like the way I was doing, but slowdown the emulation. I've heard and seen too many examples where functions slow down high-priority programs. Even if it takes more code, I try not to use them.

> This is a perfect example on where you should use the 'inline' keyword :) this would not cause it to run slower actually since all of the code would be inline. it would in effect end up being the same outpt of code most likely from what your macros are doing but it looks cleaner to do it with lots of little functions. Also, you can make your macros look like functions as well, which would also clean things up a little bit.

No it isn't. The best case for your switch statement is a jump table anyway (the most time-efficient encoding for this problem), and when the compiler generates a jump table from a case statement it puts a bounds check on it (slow). Using a switch statement and inline functions gains you nothing.

Using global variables or the "fastcall" convention (globals are out if you want your core to be re-entrant), and no frame pointers (GCC's -fomit-frame-pointer option), means that your functions will be faster than a switch before cache effects are taken into effect. Even with cache effects, an explicit jump table and procedures should be a win (measure it, though. always measure it).

And then look at where the bottlenecks really are. Opcode fetching, and memory access in general.

And this is just the CPU core. In my experience, the CPU core has rarely been a performance issue. It is possible to write an SMS emulator with Marat's Z80 core that runs at full speed on a p133 with sound.

There are also a few things to keep in mind. The saying "Premature optimization is the root of all evil", and the two rules of optimization, "Rule one: Don't do it. Rule two (for experts only): Don't do it yet." are two to start with.

Quote

> ATani

--Nyef

Author	Message
Consolemu Guest	I didn't realize... Posted: Mon Apr 24, 2000 6:56 am
Consolemu Guest	I take back every bad thing I ever said about anyone not wanting to write their own CPU core. Wanna know why? BECAUSE IT'S TEDIOUS AS HELL!!! I figured since my company left from spring break and I only had yesterday and today full of freetime that I would "try out" this CPU emulation stuff but damn does it drain the life out of you! You have to sit down and do instruction after instruction after instruction. I figured I'd try the 6502 since it's so simple, and it is a pretty simple and straight-forward chip to emulate but damn it takes a lot to emulate! In total I've spent 4 and 1/2 hours programming and studying and so far I've come up with 187 instruction macros, and 10 supported instructions. I need to finish the other 40 or 50 macros and then add support for the rest of the instructions from the macros. But damn, if the 6502 takes this much time, My GOD, I can't imagine the Z80 (with it's 600 or so instructions) or the 68000!! Chris :o\|

Nyef Guest	Posted: Mon Apr 24, 2000 12:56 pm
Nyef Guest	Quote > I take back every bad thing I ever said about anyone not wanting to write their own CPU core. Wanna know why? BECAUSE IT'S TEDIOUS AS HELL!!! I figured since my company left from spring break and I only had yesterday and today full of freetime that I would "try out" this CPU emulation stuff but damn does it drain the life out of you! You have to sit down and do instruction after instruction after instruction. I figured I'd try the 6502 since it's so simple, and it is a pretty simple and straight-forward chip to emulate but damn it takes a lot to emulate! In total I've spent 4 and 1/2 hours programming and studying and so far I've come up with 187 instruction macros, and 10 supported instructions. I need to finish the other 40 or 50 macros and then add support for the rest of the instructions from the macros. But damn, if the 6502 takes this much time, My GOD, I can't imagine the Z80 (with it's 600 or so instructions) or the 68000!! Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me, I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end. It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually. I am already playing with an r3000 disassembler, and am considering starting an SH-2 core. And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40". Quote > Chris :o\| --Nyef

unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Woohoo! SH2! Good Luck! nt Posted: Mon Apr 24, 2000 1:03 pm
unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Quote > > I take back every bad thing I ever said about anyone not wanting to write their own CPU core. Wanna know why? BECAUSE IT'S TEDIOUS AS HELL!!! I figured since my company left from spring break and I only had yesterday and today full of freetime that I would "try out" this CPU emulation stuff but damn does it drain the life out of you! You have to sit down and do instruction after instruction after instruction. I figured I'd try the 6502 since it's so simple, and it is a pretty simple and straight-forward chip to emulate but damn it takes a lot to emulate! In total I've spent 4 and 1/2 hours programming and studying and so far I've come up with 187 instruction macros, and 10 supported instructions. I need to finish the other 40 or 50 macros and then add support for the rest of the instructions from the macros. But damn, if the 6502 takes this much time, My GOD, I can't imagine the Z80 (with it's 600 or so instructions) or the 68000!! > Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me, > I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end. > It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually. > I am already playing with an r3000 disassembler, and am considering starting an SH-2 core. > And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40". > > Chris :o\| > --Nyef

Nyef Guest	The problem with the SH-1 and SH-2 Posted: Mon Apr 24, 2000 2:17 pm
Nyef Guest	The problem with the SH CPUs is that they are 68000 CPUs on steroids. From the SH-1 Product Brief: "32-bit internal data paths / 16-bit external data paths" Just like the 68000. "16-bit fixed instruction set" Just like the 68000. The SH-2 at least has 32-bit external data paths, but that makes it a 68020 or a 68030, I'm not sure which. The addressing modes available are almost as bad. And I haven't figured out if the pipeline stuff is important to emulate or not. In short, I'd rather tackle a MIPS chip with their fucked up cache semantics, screwed up control registers, and 32-bit instruction encoding from hell than deal with the SH-2. And I will do neither of them without my full toolkit (code generators, test frameworks, etc.). But first, I'd like to see Phantasy Star II running in DarcNES. And perhaps Sonic CD and Lunar (Hrm... Looks like my Ambition and my Ego are making a run for it, I hope they don't get beaten too badly). ^_^ --Nyef

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: The problem with the SH-1 and SH-2 Posted: Mon Apr 24, 2000 2:32 pm
	Quote > But first, I'd like to see Phantasy Star II running in DarcNES. And perhaps Sonic CD and Lunar Now that would be great ^_^

Consolemu Guest	Minor Correction Posted: Mon Apr 24, 2000 2:45 pm
Consolemu Guest	Quote > Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me, Ouch! That must have sucked! I tried doing that and I guess that's why I bombed with my very first Z80 Core. This is actually my 2nd time doing a core and things are running much more smoothly. I also have lots of good documents this time around(ones that even tell you every possible instruction available). With these docs it takes the venture time away (having to figure out what instructions do what and what their machine equivalents are) and gives me more time to conentrate and code. But shit, last night, even with all this stuff right be for my eyes, it was my eyes and my brain that gave out at about 3:00 last night (3:00AM). I finished the 148 machine/instruction macros. Now I need to emulate all 148 of them and test them on some 6502 data. Quote > I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end. Same thing with me. Except my un-ending project is the Z80. Quote > It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually. Does the 6280 work similar to the 6502? All this time I was thinking that the 6280 was some custom (built from scratch) chip that was designed by NEC or something. Quote > I am already playing with an r3000 disassembler, and am considering starting an SH-2 core. My dream would be to create my own 68000 core, Z80 core, and SH2 core so that way I can run the 32X games. I don't see why my 366Mhz computer can run those games. Quote > And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40". You're right. 128 to be exact. I was so tired last night that I was seeing things. Having to write lines and lines of `.... #define SBC_IdX 0xE1 #define CPX_ZP 0xE4 #define SBC_ZP 0xE5 #define INC_ZP 0xE6 #define INX 0xE8 #define SBC_Im 0xE9 #define NOP 0xEA #define CPX_Ab 0xEC #define SBC_Ab 0xED #define INC_Ab 0xEE #define BEQ 0xF0 #define SBC_Id_Y 0xF1 #define SBC_ZP_X 0xF5 #define INC_ZP_X 0xF6 ...` can really affect you. Chris :o)

Consolemu Guest	Sega CD Stuff Posted: Mon Apr 24, 2000 2:50 pm
Consolemu Guest	The only Sega console I haven't used yet is the Sega CD and the only game I've ever played was Sonic CD, and even that was the PC port, not the genuine one on the Sega CD. What makes the Sega CD so good? Is it like some mega attachment like the 32X? Does it have a big boost in RAM or an extra processor? Oh, and would it be possible to convert a Sega CD game into a solid .BIN or .SCD file or something? Or would the games wind up being 100-600MB anyway? There's lots of games out there that I've never even heard of. I keep hearing good things about some game galled Lunar and stuff. I'd like to try it someday. Chris :o)

Consolemu Guest	Re: Minor Correction Posted: Mon Apr 24, 2000 2:53 pm
Consolemu Guest	Ignore that 128 number. The number is 148 like the top. Chris :o)

Nyef Guest	Re: Sega CD Stuff Posted: Mon Apr 24, 2000 3:06 pm
Nyef Guest	Quote > The only Sega console I haven't used yet is the Sega CD and the only game I've ever played was Sonic CD, and even that was the PC port, not the genuine one on the Sega CD. What makes the Sega CD so good? Is it like some mega attachment like the 32X? Does it have a big boost in RAM or an extra processor? Oh, and would it be possible to convert a Sega CD game into a solid .BIN or .SCD file or something? Or would the games wind up being 100-600MB anyway? There's lots of games out there that I've never even heard of. I keep hearing good things about some game galled Lunar and stuff. I'd like to try it someday. The big thing about the SegaCD (aside from the CD drive) was the 12 MHz 68000 processor (even more speed than the Genesis CPU). It also had SRAM, and some hardware scaling/rotating support (which, by all reports, was slower than using the CPU to do it). And most SegaCD games used CD audio, and were megabytes in size, so converting them to carts is not exactly feasable. Quote > Chris :o) --Nyef

Nyef Guest	Re: Minor Correction Posted: Mon Apr 24, 2000 3:28 pm
Nyef Guest	Quote > > Ah, realization cometh. Yes, it can be tedious. On the other hand, it takes less effort every time. It took me weeks to write my first 6502 core (actually a 65816 core), and I never finished it. It took me months to write my next 6502 core, and that was made by asking "what instruction do I need next to run this ROM?". It took me days to write my third 6502 core (actually a 6280 core), and for that I wrote a program to write it for me, > Ouch! That must have sucked! I tried doing that and I guess that's why I bombed with my very first Z80 Core. This is actually my 2nd time doing a core and things are running much more smoothly. I also have lots of good documents this time around(ones that even tell you every possible instruction available). With these docs it takes the venture time away (having to figure out what instructions do what and what their machine equivalents are) and gives me more time to conentrate and code. But shit, last night, even with all this stuff right be for my eyes, it was my eyes and my brain that gave out at about 3:00 last night (3:00AM). I finished the 148 machine/instruction macros. Now I need to emulate all 148 of them and test them on some 6502 data. Oh, not at all. I started testing the core before I wrote it (well, I put the main loop and the unimplemented code handler in first), that way I know I got most of the instructions right. The only catch when writing a a core generator is that you can have up to three macro processors in the mix (as opposed to an ASM core, which is limeted to two). And when my brain last fried, I went to bed. The following morning I cleared up the problem that was frying my brain in about a minute. Quote > > I am still working on my first 68000 core after more than a year. Every now and then I do some work on it, and then I ignore it for weeks on end. > Same thing with me. Except my un-ending project is the Z80. Well, my real unending project is DarcNES. The 68000 is merely the longest-running broken module (except maybe the PC-Engine emulation, I'll have to check that). Quote > > It will probably take me about a day to do my next 6502 core, but that's because I'm planning on hacking up my 6280 core to make it. I do not wish to have to write my own Z80 core, but I will eventually. > Does the 6280 work similar to the 6502? All this time I was thinking that the 6280 was some custom (built from scratch) chip that was designed by NEC or something. It's a 65c02 with some of the bit manipulation instructions twisted, block movement instructions, an integrated MMU, and a few other new instructions. It was designed by Hudson Soft (hence HuC6280). Quote > > I am already playing with an r3000 disassembler, and am considering starting an SH-2 core. > My dream would be to create my own 68000 core, Z80 core, and SH2 core so that way I can run the 32X games. I don't see why my 366Mhz computer can run those games. Just you wait. I have the 32X-CD version of Night Trap around somewhere. I expect that it will hammer my Celeron 333A into submission. A Z80, two 68000s, two SH-2s, three video systems, three audio systems, and streaming video. Now that's a lot of emulating. Quote > > And 187 macros sounds like a lot for 10 instructions, My last ASM 6502 core only needed 100 macros total, and that includes things like "#define flag_Z $0x40". > You're right. 128 to be exact. I was so tired last night that I was seeing things. Having to write lines and lines of > `> .... > #define SBC_IdX 0xE1 > #define CPX_ZP 0xE4 > #define SBC_ZP 0xE5 > #define INC_ZP 0xE6 > #define INX 0xE8 > #define SBC_Im 0xE9 > #define NOP 0xEA > #define CPX_Ab 0xEC > #define SBC_Ab 0xED > #define INC_Ab 0xEE > #define BEQ 0xF0 > #define SBC_Id_Y 0xF1 > #define SBC_ZP_X 0xF5 > #define INC_ZP_X 0xF6 > ... >` > can really affect you. You, sir, are nuts. First of all, you use an enum for that (see Marat's Z80 core). Second, you don't do that in the first place. Most of that falls out if you use a jump table. You need macros for flag setting, memory access, addressing modes, and most of the instruction types, but you don't use macros that are used in exactly one instruction (unless you need the same operation 8 times in one instruction, like TMA on the 6280). You then write a small (3-5) line function to actually do the job. void cpu6502_op_LDA_imm(struct cpu6502_context *context) { Get_Immediate(); Do_LDA(); } If you are writing an ASM core, you also want a macro to do the whole next instruction thing (cycle counters, and either returning to a central dispatch routine or dispatching the next instruction directly). Quote > Chris :o) --Nyef

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Sega CD Stuff Posted: Mon Apr 24, 2000 4:25 pm
	Quote > > The only Sega console I haven't used yet is the Sega CD and the only game I've ever played was Sonic CD, and even that was the PC port, not the genuine one on the Sega CD. What makes the Sega CD so good? Is it like some mega attachment like the 32X? Does it have a big boost in RAM or an extra processor? Oh, and would it be possible to convert a Sega CD game into a solid .BIN or .SCD file or something? Or would the games wind up being 100-600MB anyway? There's lots of games out there that I've never even heard of. I keep hearing good things about some game galled Lunar and stuff. I'd like to try it someday. > The big thing about the SegaCD (aside from the CD drive) was the 12 MHz 68000 processor (even more speed than the Genesis CPU). It also had SRAM, and some hardware scaling/rotating support (which, by all reports, was slower than using the CPU to do it). it was my understanding that the scaling and rotation was the job of the second (12mhz) 68000, which ran in tandem with the original 68000. eh?

Nyef Guest	Re: Sega CD Stuff Posted: Mon Apr 24, 2000 5:02 pm
Nyef Guest	Quote > it was my understanding that the scaling and rotation was the job of the second (12mhz) 68000, which ran in tandem with the original 68000. No, apparently there's an ASIC that can do it. But as I said, using the CPU is apparently faster. --Nyef

Consolemu Guest	Why am I nuts? Posted: Mon Apr 24, 2000 10:08 pm
Consolemu Guest	Quote > You, sir, are nuts. First of all, you use an enum for that (see Marat's Z80 core). Second, you don't do that in the first place. Most of that falls out if you use a jump table. > You need macros for flag setting, memory access, addressing modes, and most of the instruction types, but you don't use macros that are used in exactly one instruction (unless you need the same operation 8 times in one instruction, like TMA on the 6280). I don't really understand why what I'm doing is crazy. First, the 148 macros that I created are going to be used in a case like this... `switch(memory[PC]) { case LDA_Ab: A = Absolute(memory[&PC]); break; case TXA: A = X; break; case LDA_IdX: A = PreIndexIndirect(memory);` That's example code. I'll handle the details like Carry, Overflow, and cycles in my real code. Almost any method that you use will result into a ton of code anyway. There's no way around that, at least one that I know of. I've already made the PreIndex, PostIndex, Absolute stuff into assembly functions to give it some speed(C/Asm). And I'm already too deep into my way of doing it to turn back and re-code something new. I'm still willing to learn though. Quote > You then write a small (3-5) line function to actually do the job. > > void cpu6502_op_LDA_imm(struct cpu6502_context *context) > { > Get_Immediate(); > Do_LDA(); > } > Ah. Function calls. I don't want to have 148 functions and they work exactly like the way I was doing, but slowdown the emulation. I've heard and seen too many examples where functions slow down high-priority programs. Even if it takes more code, I try not to use them. Quote > If you are writing an ASM core, you also want a macro to do the whole next instruction thing (cycle counters, and either returning to a central dispatch routine or dispatching the next instruction directly). Chris :o)

Consolemu Guest	Oh yeah, Jump Table stuff Posted: Mon Apr 24, 2000 10:39 pm
Consolemu Guest	I'm not really using a Jump Table. I'm using the macros instead of flipping back and fourth through my book everytime I want to find the hex value of an instruction. I devised a system so that way I could use english statements instead of hex stuff. I think everything I'm doing will lay out fine. I'm making a hell of a lot more progress than I did the last time. I tested Castlevania III to try out the 6502 core and it worked so far! The first instruction was BRK, the second was LDA Absolute! Then I tried it on Tetris and it said, BRK, then LDX Immediate, then STX Absolute, next was CMP Zero Page, it was sweet! Everytime I see stuff like that it makes me proud and want to work harder. Chris :o)

unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Re: The problem with the SH-1 and SH-2 Posted: Tue Apr 25, 2000 7:38 am
unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Quote > The problem with the SH CPUs is that they are 68000 CPUs on steroids. > From the SH-1 Product Brief: "32-bit internal data paths / 16-bit external data paths" Just like the 68000. "16-bit fixed instruction set" Just like the 68000. > The SH-2 at least has 32-bit external data paths, but that makes it a 68020 or a 68030, I'm not sure which. > The addressing modes available are almost as bad. And I haven't figured out if the pipeline stuff is important to emulate or not. > In short, I'd rather tackle a MIPS chip with their fucked up cache semantics, screwed up control registers, and 32-bit instruction encoding from hell than deal with the SH-2. And I will do neither of them without my full toolkit (code generators, test frameworks, etc.). > But first, I'd like to see Phantasy Star II running in DarcNES. And perhaps Sonic CD and Lunar (Hrm... Looks like my Ambition and my Ego are making a run for it, I hope they don't get beaten too badly). ^_^ > --Nyef Hmmm.... if you're writing a SH1/SH2 eumlator, maybe you'd be able to have the first emu to support Virtua Racing ^_^ ~unfnknblvbl

ATani Guest	Re: Why am I nuts? Posted: Tue Apr 25, 2000 2:41 pm
ATani Guest	Quote > Ah. Function calls. I don't want to have 148 functions and they work exactly like the way I was doing, but slowdown the emulation. I've heard and seen too many examples where functions slow down high-priority programs. Even if it takes more code, I try not to use them. This is a perfect example on where you should use the 'inline' keyword :) this would not cause it to run slower actually since all of the code would be inline. it would in effect end up being the same outpt of code most likely from what your macros are doing but it looks cleaner to do it with lots of little functions. Also, you can make your macros look like functions as well, which would also clean things up a little bit. ATani

Nyef Guest	Re: Why am I nuts? Posted: Tue Apr 25, 2000 3:02 pm
Nyef Guest	Quote > > Ah. Function calls. I don't want to have 148 functions and they work exactly like the way I was doing, but slowdown the emulation. I've heard and seen too many examples where functions slow down high-priority programs. Even if it takes more code, I try not to use them. > This is a perfect example on where you should use the 'inline' keyword :) this would not cause it to run slower actually since all of the code would be inline. it would in effect end up being the same outpt of code most likely from what your macros are doing but it looks cleaner to do it with lots of little functions. Also, you can make your macros look like functions as well, which would also clean things up a little bit. No it isn't. The best case for your switch statement is a jump table anyway (the most time-efficient encoding for this problem), and when the compiler generates a jump table from a case statement it puts a bounds check on it (slow). Using a switch statement and inline functions gains you nothing. Using global variables or the "fastcall" convention (globals are out if you want your core to be re-entrant), and no frame pointers (GCC's -fomit-frame-pointer option), means that your functions will be faster than a switch before cache effects are taken into effect. Even with cache effects, an explicit jump table and procedures should be a win (measure it, though. always measure it). And then look at where the bottlenecks really are. Opcode fetching, and memory access in general. And this is just the CPU core. In my experience, the CPU core has rarely been a performance issue. It is possible to write an SMS emulator with Marat's Z80 core that runs at full speed on a p133 with sound. There are also a few things to keep in mind. The saying "Premature optimization is the root of all evil", and the two rules of optimization, "Rule one: Don't do it. Rule two (for experts only): Don't do it yet." are two to start with. Quote > ATani --Nyef

Forums

View topic - I didn't realize...