Forums

To any Z80 experts out there:

Does any one know how the IN reg, (C) instruction affects the Auxilliary Carry (sometimes referred to as Half-Carry) flag?

I have consulted both Marat's Z80 emulator source, Massage 6.1's source, and two independent Z80 documents regarding this instruction. There is very little consensus among them. Most of these documents state that the flag is modified. However, since no arithmetic operation is performed it is unclear to me how the modification could be meaningful. Perhaps the flag should be left untouched, or maybe SET or RESET?

Also, Zoop, would you be willing to inform me what Z80 emulator you used in Meka? I'd like to check how it's IN reg, (C) instruction affects the flag.

Any help is appreciated. Thank you.

Eric Quinn

Here's Meka...

Marat's Z80 CPU Core <--Saves time, typing, and agrivation
Allegro's Graphics Functions <--Saves time, typing, and studing VGA graphics
SEAL's Sound Functions <--Saves, time, typing, and stuying sound cards
Some Japanese dudes kick ass YM2143 Core <--I guess he figured, "Ahh what the hell, let's use this
too".
All compiled with DJGPP I bet.

So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code.
That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing
the VDP and Sound interpretation codes. This is how 90% of the emulators out there are written.
MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know
what they all have in common...

THEY ALL RUN SLOW ON MY P133!!!

Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would
I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines
for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's
the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody
will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're
only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG.
Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in
mind before and during the time you're writing your emulator.

Meka still kicks ass though, Zoop.

Chris :o(

Quote

> Here's Meka...

> Marat's Z80 CPU Core <--Saves time, typing, and agrivation
> Allegro's Graphics Functions <--Saves time, typing, and studing VGA graphics
> SEAL's Sound Functions <--Saves, time, typing, and stuying sound cards
> Some Japanese dudes kick ass YM2143 Core <--I guess he figured, "Ahh what the hell, let's use this
> too".
> All compiled with DJGPP I bet.

> So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code.
> That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing
> the VDP and Sound interpretation codes. This is how 90% of the emulators out there are written.
> MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know
> what they all have in common...

> THEY ALL RUN SLOW ON MY P133!!!

> Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would
> I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines
> for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's
> the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody
> will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're
> only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG.
> Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in
> mind before and during the time you're writing your emulator.

> Meka still kicks ass though, Zoop.

> Chris :o(

>

Quote

> That's why he could spend so much time writing a kick ass GUI.

too similar to allegro's bog standard gui to be a co-incidence too, it shows how something ugly can look good with some tweaking

Quote

>He spent mabye a month writing
> the VDP and Sound interpretation codes. This is how 90% of the emulators out there are written.
> MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know
> what they all have in common...

> THEY ALL RUN SLOW ON MY P133!!!

> Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would
> I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines
> for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's
> the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody
> will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're
> only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG.
> Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in
> mind before and during the time you're writing your emulator.

so then, explain to the clueless authors some detailed routines to do things faster, eg wave synthesis, prevention of redundant overdrawing and the like.

Quote

> Meka still kicks ass though, Zoop.

even though its sounds like you are saying the opposite.. hmm i dunno. but anyways, how many of the mentioned emu's claimed that speed was their strong point?

Quote

> Chris :o(

you seem to be out of character (or at least the type of character you have showen us in the past).. sure youre not an imposter?

Quote

>

Quote

> This is how 90% of the emulators out there are written.
> MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know
> what they all have in common...

> THEY ALL RUN SLOW ON MY P133!!!

You may have a point. Looking at the larger issue, does it make sense that 8-bit consoles should require so much computing power to emulate? I'm not convinced they should, either.

HOWEVER, (that's a big "however") code optimization is not easy. It truly takes years to master, and during that time compilers, assemblers, and microprocessors will change, making anything the programmer knows about optimization all but obsolete. Additionally, there's the fact that not many programmers are willing to rip apart code they just got working in order to optimize it. Now, you may say, "just make sure it's optimized from the start." Well, that's easier said than done, as I'm sure you'll discover during the process of writing your emulator. Sometimes you just want to get the darn thing working.

Quote

> Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would
> I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines
> for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's
> the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody
> will admit that their emulator was poorly written.

I'm not sure everyone who writes an emulator has high-performance in mind. Additionally, it's difficult to write an emulator on a PII-300 that performs well on a Pentium-133. A program always performs best on machines it was written/debugged on. Many of these authors may simply have fast computers, and their emulator runs fine on them.

If you truly feel this state of affairs unacceptable, then I encourage you to write a high-performance emulator. Everyone will benefit. (Also, remember that the longer it takes you to write it, by tweaking it here and there, the faster computers will be by the time you're finished...)

Good luck.

Now, does anyone know about how the flags are affected by the IN reg, (C) instruction?

Eric

Listen When I say poorly written I mean coding like this:

Calling Function Emuate...
OP Code found, calling function OPcode...
special OP code found, calling header file functions...
Oh, header function found graphics statement, calling graphics functions...done, I think
calling sprite functions...
leaving sprite functions...
leaving graphics functions...
returning from header functions...
returning from Emulate function...

All of this jumping back and fourth to other functions during an emulator loop. This waste
so much time it's not even funny. I think it's absoulely rediculous. I'm not saying to not use
functions at all, that's fucking phycotic. But be reasonible with the calls. Here's a good way...

Calling function emulate...
found opcode, performing instructions...done.
found graphics code, calling graphics functions...
in graphics, performing graphics...done.
leaving graphics...
leaving emulate...

Now the above still wasn't the fastest, but that could drastically improve CPU emulation from 10 to
30% or more. Same thing goes for all graphics and sound capabilites for your emulator. You
could be using Kgen's or Genecyst's 68k core. If your emulator calls hundreds of sound functions
then your entire emulator will be affected.

Now there's some things that you simply cannot help. Like a multiply or divide instruction. You
have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use
bit shifts when ever you can. For example, if you're going to multiply something times 2, don't
just write this:

a * 2

That's just pure carelessness. Write this

a << 2;

Now, was that all that bad? You just saved your PC another 50 cycles or so.

I'm not some emulator expert, by no means. But these are just common programming principles
that are required for Game Programming and emulator programming is a form of
game programming. It's a high priority, realtime program that should be optomized here and there.
Sure, technology is changing everyday, even as I type this message but come on, don't be so
lazy and careless.

Better yet, look at this analogy...

A couple of people got together and wrote Mame. It's slow, but it's acceptable because it has
lots of hardware support, right?

Now, if those same people got together and wrote a Basic interpreter, called MameBasic,
could you imagine how slow it would be? The way they write their programs are written, it would
probably take 2 seconds or more to do a loop from 1 to 100!! But you know what they would say,
"Oh well, it's acceptable because MameBasic can run on all OS."

Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads,
"optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator
programmers. But nobody cares to even take a glance at it. I'm guess I'm the only one that reads and
looks at his updates. I got the perfect word...Careless Coders. People who are desperate to get
their emulator to run some games at all cost.

It's okay though. I'm just going to keep studying my Assembler, C, and emulator programming
tutorials and mabye someday I'll get to prove my point.

Chris :o|

Quote

> Also, Zoop, would you be willing to inform me what Z80 emulator you used in Meka? I'd like to check how it's IN reg, (C) instruction affects the flag.

I'm using Marat core, as mentionned in the documentation

Quote

> Marat's Z80 CPU Core <--Saves time, typing, and agrivation

And frustration. Writing a CPU core is pretty easy but really boring and frustrating.
And none of my core was in a state to be used for the emulator yet.

Quote

> Allegro's Graphics Functions <--Saves time, typing, and studing VGA graphics

Doing VGA graphic manually is basically three instructions to initialize the video mode and the video memory is very easy to deal with as it is an array.
Allegro is primarly used for compatibility, as it has been tested with a lot of hardware kind. And without Allegro I woudn't be able to include any joystick support for the simple reason I do not have a joystick myself (well, I recieved one since).

Quote

> SEAL's Sound Functions <--Saves, time, typing, and stuying sound cards

That's because DOS sucks. With any good operating system (Windows and Linux on PC) you don't have to deal with this kind of thing anymore, which is absolutly crap and useless to study.
Also, SEAL provide a compatibility with various kind of soundcard no single programmer would be able to provide (I could have done SB, and maybe GUS but I never tried to program my GUS before).

Quote

> Some Japanese dudes kick ass YM2143 Core <--I guess he figured, "Ahh what the hell, let's use this
> too".

He made it for Meka.

Quote

> All compiled with DJGPP I bet.

And what does it mean ?
You thought someone was typing instructions directly in hex into a binary file ? Hahaha.

Quote

> So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code.

10000 lines of code is nothing.

Quote

> That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing
> the VDP and Sound interpretation codes.

Sure, and that's all to emulate ?
Finish your SG-1000 emulator you started ten years ago first.

Quote

> This is how 90% of the emulators out there are written.
> MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know
> what they all have in common...
> THEY ALL RUN SLOW ON MY P133!!!

Magic Engine is 99% Assembly and is simply one of the fastest emulator around.

Quote

> Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would
> I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines

That's because FX3 doesn't know how to code, and his emulator is heavily based on xNES which
a friend made and was the worst piece of code ever made.

Quote

> for Windows, I repeat, Windows,

What's the problem with Windows ? It is not slow.

Quote

> can run the same Mario Bros. game at fullspeed. See, that's
> the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody
> will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're
> only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG.
> Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in
> mind before and during the time you're writing your emulator.

What's the problem if someone want to release an emulator ?
You are not forced to use anything.

Nesticle CPU core is based on another one, by the way.

Quote

> > That's why he could spend so much time writing a kick ass GUI.
> too similar to allegro's bog standard gui to be a co-incidence too, it shows how something ugly can look good with some tweaking

The GUI was wrote absolutly from stratch, expect from the putpixel and line routines (very hard to write, man!).

[...]

Quote

> Now there's some things that you simply cannot help. Like a multiply or divide instruction. You
> have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use
> bit shifts when ever you can. For example, if you're going to multiply something times 2, don't
> just write this:
> a * 2
> That's just pure carelessness. Write this
> a << 2;
> Now, was that all that bad? You just saved your PC another 50 cycles or so.

Euh, most compilers (djgpp included), replace automaticaly a * 2 by either a +a or a << 2. So for
now a * 2 is better, because it's less cryptic. It's among the easiest optimization a compiler can make.
Even a student project mini-compiler can easily implement that sort of optimization.

[...]

Quote

> Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads,
> "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator
> programmers. But nobody cares to even take a glance at it. I'm guess I'm the only one that reads and
> looks at his updates. I got the perfect word...Careless Coders. People who are desperate to get
> their emulator to run some games at all cost.

Okay, I guess Mame is written in C because it's for porting purpose, and probably because it runs just
great enough on their PII computers. Well mame runs pretty well on my PII, though. I understand how you
feel about that the emulators are not fast enough, one year ago I still had my good old 486, and the only
emulator I was able to run around was massage. Most emulators are freeware, and authors cannot work
on them like if they were game to be sold... Maybe you should not ask too much.

Quote

> Calling Function Emuate...
> OP Code found, calling function OPcode...
> special OP code found, calling header file functions...
> Oh, header function found graphics statement, calling graphics functions...done, I think
> calling sprite functions...
> leaving sprite functions...
> leaving graphics functions...
> returning from header functions...
> returning from Emulate function...

Wow, you really know a lot about emulation!
(it's pure bullshit, btw)

Quote

> All of this jumping back and fourth to other functions during an emulator loop. This waste
> so much time it's not even funny. I think it's absoulely rediculous. I'm not saying to not use
> functions at all, that's fucking phycotic. But be reasonible with the calls. Here's a good way...

And do think it's leaving a function ten times a second that make an emulator slow ?

Quote

> Calling function emulate...
> found opcode, performing instructions...done.
> found graphics code, calling graphics functions...
> in graphics, performing graphics...done.
> leaving graphics...
> leaving emulate...
> Now the above still wasn't the fastest, but that could drastically improve CPU emulation from 10 to

It's exactly the same thing.

Quote

> 30% or more. Same thing goes for all graphics and sound capabilites for your emulator. You
> could be using Kgen's or Genecyst's 68k core.

They were not released.

Quote

> Now there's some things that you simply cannot help. Like a multiply or divide instruction. You
> have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use
> bit shifts when ever you can. For example, if you're going to multiply something times 2, don't
> just write this:
> a * 2
> That's just pure carelessness. Write this
> a << 2;

Man, you are really a good programmer. This is the most simplest optimisation you can do, and
just about all C compiler do it for yourself when you multiply/divise by a power of two.

Btw, the right thing to do was "a << 1" and not "a << 2". Considering the fact you also posted some
questions about how to "handle bits in a byte" a few days ago, that make me think you do not even
know what you are talking about.

Quote

> Now, was that all that bad? You just saved your PC another 50 cycles or so.

I would say 15 cycle, if not less.

[..]

Quote

> Now, if those same people got together and wrote a Basic interpreter, called MameBasic,
> could you imagine how slow it would be? The way they write their programs are written, it would
> probably take 2 seconds or more to do a loop from 1 to 100!!

HAHAHAHAHAHA! Even the CPU in my watch would do better.

Quote

> But you know what they would say, "Oh well, it's acceptable because MameBasic can run on all OS."

Because it is C and because of the way it was originally wrote.
Most of the programmers in MAME team are really good.

Quote

> Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads,
> "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator
> programmers. But nobody cares to even take a glance at it.

How do you know that ?
Larry is mainly emulating very simplest game systems, and his optimisations do not apply to most
systems. I even doubt he did emulate a system with hardware scrolling or more than one layer !

Quote

> I'm guess I'm the only one that reads and looks at his updates.

And you do even understand them ? (I'm serious)

Quote

> It's okay though. I'm just going to keep studying my Assembler, C, and emulator programming
> tutorials and mabye someday I'll get to prove my point.

Then you are not on the right tracks, because good programmers do not have to read tutorials.

Quote

> > Calling Function Emuate...
> > OP Code found, calling function OPcode...
> > special OP code found, calling header file functions...
> > Oh, header function found graphics statement, calling graphics functions...done, I think
> > calling sprite functions...
> > leaving sprite functions...
> > leaving graphics functions...
> > returning from header functions...
> > returning from Emulate function...

> Wow, you really know a lot about emulation!
> (it's pure bullshit, btw)

No, I don't know a lot but I know that's how a lot of emulators are written.

Quote

> > All of this jumping back and fourth to other functions during an emulator loop. This waste
> > so much time it's not even funny. I think it's absoulely rediculous. I'm not saying to not use
> > functions at all, that's fucking phycotic. But be reasonible with the calls. Here's a good way...

> And do think it's leaving a function ten times a second that make an emulator slow ?

I can slow it down a little. Now, when you're looping that little becomes a lot and slows things
down. Am I right or wrong?

Quote

> > Calling function emulate...
> > found opcode, performing instructions...done.
> > found graphics code, calling graphics functions...
> > in graphics, performing graphics...done.
> > leaving graphics...
> > leaving emulate...
> > Now the above still wasn't the fastest, but that could drastically improve CPU emulation from 10 to

> It's exactly the same thing.

No, it's not exactly the same thing. There's a little difference because that's using less functions.

Quote

> > 30% or more. Same thing goes for all graphics and sound capabilites for your emulator. You
> > could be using Kgen's or Genecyst's 68k core.

> They were not released.

huh?

Quote

> > Now there's some things that you simply cannot help. Like a multiply or divide instruction. You
> > have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use
> > bit shifts when ever you can. For example, if you're going to multiply something times 2, don't
> > just write this:
> > a * 2
> > That's just pure carelessness. Write this
> > a << 2;

> Man, you are really a good programmer. This is the most simplest optimisation you can do, and
> just about all C compiler do it for yourself when you multiply/divise by a power of two.

Oh yeah, << 1. Forgot that fast. Thanks :o)

Quote

> Btw, the right thing to do was "a << 1" and not "a << 2". Considering the fact you also posted some
> questions about how to "handle bits in a byte" a few days ago, that make me think you do not even
> know what you are talking about.

I know what I'm talking about. Just a typeo, sort of.

Quote

> > Now, was that all that bad? You just saved your PC another 50 cycles or so.

> I would say 15 cycle, if not less.

Okay, but it does save some CPU time. Right, or wrong?

Quote

> [..]
> > Now, if those same people got together and wrote a Basic interpreter, called MameBasic,
> > could you imagine how slow it would be? The way they write their programs are written, it would
> > probably take 2 seconds or more to do a loop from 1 to 100!!

> HAHAHAHAHAHA! Even the CPU in my watch would do better.

> > But you know what they would say, "Oh well, it's acceptable because MameBasic can run on all OS."

> Because it is C and because of the way it was originally wrote.
> Most of the programmers in MAME team are really good.

I didn't say they weren't. I'm just saying under MAME Galaga can barely run at 5 frameskip on my
P133 :o)

Quote

> > Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads,
> > "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator
> > programmers. But nobody cares to even take a glance at it.

> How do you know that ?
> Larry is mainly emulating very simplest game systems, and his optimisations do not apply to most
> systems. I even doubt he did emulate a system with hardware scrolling or more than one layer !

You do have a point because Hive dosen't emulate anything after 1985, except for Galaga 88 and
that uses ancient hardware.

Quote

> > I'm guess I'm the only one that reads and looks at his updates.

> And you do even understand them ? (I'm serious)

Yes, I do understand sections here and there. I just wish I could express what I want to be done
in C. My syntax is wrong but my ideas are correct.

Quote

> > It's okay though. I'm just going to keep studying my Assembler, C, and emulator programming
> > tutorials and mabye someday I'll get to prove my point.

> Then you are not on the right tracks, because good programmers do not have to read tutorials.

So you mean to tell me you wrote Meka entirely by yourself without any help from anyone? Sorry
Zoop, I don't believe you on that one. I couldn't write my SG1K without your doc.

If I made you angry I'm sorry. I'm just pissed because I can't run anything over 16 bits on my
PC. I guess I'll just stop bitching and upgrade my PC.

"Can't we all just get along?" -Rodney King

Chris :o)

I'll stop bitching about it. I guess I'll get a job, save up money, and either buy a new PC
or a little laptop for college.

Chris :o)

Wah! I can't take it anymore! You win! You all win! Zoop I am absolutely sorry for ever saying
anything bad about your expertise on emu programming. I'm sick of arguing. Let's get back
to asking questions about carry flags and pointers.

Chris :o)

Quote

> I'll stop bitching about it. I guess I'll get a job, save up money, and either buy a new PC
> or a little laptop for college.

You are somewhat right about doing some optimizations, for instance Mame's Narc is pure C and it
features a 48MHz TMS34010 chip, it truely needs to be rewritten in asm, but well don't blame the
authors, it's already an incredible work to have a working Narc, even slow.

PS: I've done a mistake, a * 2 is in fact a << 1 and not a << 2 (a << 2 is a * 4), I am sorry.

Quote

> > Marat's Z80 CPU Core <--Saves time, typing, and agrivation

> And frustration. Writing a CPU core is pretty easy but really boring and frustrating.
> And none of my core was in a state to be used for the emulator yet.

This is almost always the case (as an aside, makez80 is apparently 4 or more times faster than Marat's core).

Quote

> > All compiled with DJGPP I bet.

> And what does it mean ?

Aside from long compile times, that is (the _real_ reason to use ASM isn't for runtime speed).

Quote

> You thought someone was typing instructions directly in hex into a binary file ? Hahaha.

Been there, done that (it worked, too). :-)

Quote

> > So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code.

> 10000 lines of code is nothing.

And all of the "objectionably-oriented" programmers have been screaming "code reuse" at us for so long that many emu authors figure "what the heck, lets try it". :-)

Quote

> > That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing
> > the VDP and Sound interpretation codes.

> Sure, and that's all to emulate ?
> Finish your SG-1000 emulator you started ten years ago first.

At least the VDP and sound code is more interesting than a z80 core or some vga drivers.

Quote

> Magic Engine is 99% Assembly and is simply one of the fastest emulator around.

Ah. I had been wondering.

Quote

> > Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would
> > I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines

> That's because FX3 doesn't know how to code, and his emulator is heavily based on xNES which
> a friend made and was the worst piece of code ever made.

RockNES is based on both xNES and DarcNES. In the case of video, the DarcNES control code and the xNES blitter (if you can call that a blitter).

Didn't the xNES code get folded into the MESS project?

I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games.

Quote

> > for Windows, I repeat, Windows,

> What's the problem with Windows ? It is not slow.

It's also full of fun ways to obtain ABSOLUTE POWER. :-)

Quote

> > can run the same Mario Bros. game at fullspeed. See, that's
> > the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody
> > will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're
> > only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG.

"Eww, you're only using a P133? Finally, someone with a computer as slow as mine. :-P"

Quote

> > Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in
> > mind before and during the time you're writing your emulator.

I'm not a speed freak, I just want to be able to play at full speed on my Linux box with no frameskip. :-)

--Nyef

Young Christopher ;) here has a point.
I am of the belief that most Emulator Programmers are in high-paying jobs and can afford to go out and buy the latest PIII 550 with 1GB SDRAM or whatever the fuck the latest computer is at the moment.
Quite a lot of us emulator users (that I know of) are just students who are on Austudy (student welfare(?)) and cannot afford to go out and buy said system whenever they want.
Why should we need a state-of-the-art computer to emulate a console that was state-of-the-art *10* years ago!?

Quote

> Didn't the xNES code get folded into the MESS project?

It was heavily rewritten.

Quote

> I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games.

I must admit I didn't try DarcNES since a while. I'll compare with the DOS port soon.
With VESA 2 enabled, Meka run Psycho Fox title screen at 80 fps on my machine, and most games vary between 40 and 60 fps.

Quote

> Young Christopher ;) here has a point.

And not one to be dismissed out of hand, either.

Quote

> I am of the belief that most Emulator Programmers are in high-paying jobs and can afford to go out and buy the latest PIII 550 with 1GB SDRAM or whatever the fuck the latest computer is at the moment.

I am not of that belief. I starting programming emulators at school on a p133 and almost no income. It was at least 8 months after I got a real job before I got a better machine (mainly used for playing mp3s, I still use the p133 for development).

Quote

> Quite a lot of us emulator users (that I know of) are just students who are on Austudy (student welfare(?)) and cannot afford to go out and buy said system whenever they want.

Neither can I. I am not likely to upgrage for quite a while (and then I'll probably go for an OpenBSD box with large hard drives to act as a reliable fileserver rather than a high-end game machine).

Don't argue about the OS choice listed, it is just an example.

Quote

> Why should we need a state-of-the-art computer to emulate a console that was state-of-the-art *10* years ago!?

Because most programmers rely on Moore's law. Also because the console has dedicated hardware that has to be emulated in software. It doesn't help that a number of authors are really bad at coding (no, I won't be naming names).

Feel free to write your own emulator to see how hard it is (I lost track of the number of times I rewrote the rendering engines in DarcNES).

--Nyef

Quote

> > Didn't the xNES code get folded into the MESS project?

> It was heavily rewritten.

> > I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games.

> I must admit I didn't try DarcNES since a while. I'll compare with the DOS port soon.
> With VESA 2 enabled, Meka run Psycho Fox title screen at 80 fps on my machine, and most games vary between 40 and 60 fps.

I was actually thinking of a more scientific test, since DarcNES DOS has a speed lock that prevents it from going faster than 60fps. Plus there is no fps counter.

Most games that I have tested (phantasy star, california games, zillion) run at about 60 fps (sometimes a little slower) on my development machine (a p133 Linux box) when compiled as SVGALib.

--Nyef

Quote

> > Quite a lot of us emulator users (that I know of) are just students who are on Austudy (student welfare(?)) and cannot afford to go out and buy said system whenever they want.

> Neither can I. I am not likely to upgrage for quite a while (and then I'll probably go for an OpenBSD box with large hard drives to act as a reliable fileserver rather than a high-end game machine).

> Don't argue about the OS choice listed, it is just an example.

What the frig is OpenBSD? Why should I argue? I use a dual boot Win95/Red Hat 5.2 (on a 1.5GB HDD, it's kinda cramped...)

Quote

> Feel free to write your own emulator to see how hard it is (I lost track of the number of times I rewrote the rendering engines in DarcNES).

I would if I could afford a decent programming utility or could scam Visual C++ 6 off my friend (is that good enough?) and a few beginning tutorial books on programming.
I have VB5 professional (I can't figure it out) but I really don't think that it is a terribly good choice for programming an emulator. I'd program a front-end for BRSMS or Massage (Meka doesn't need one) if I could figure out how to output data into a .ini file or even how to get the data fron all the sliders, etc, into a command to call the selected program. See? I'm a gamer, not a programmer.

Quote

> --Nyef

--unfnknblvbl

P.S. I'd use the P133 for playing MP3s amd the other for development.

Quote

> I was actually thinking of a more scientific test, since DarcNES DOS has a speed lock that prevents it from going faster than 60fps. Plus there is no fps counter.
> Most games that I have tested (phantasy star, california games, zillion) run at about 60 fps (sometimes a little slower) on my development machine (a p133 Linux box) when compiled as SVGALib.

Then we got approximately the same speed, maybe Meka is slighty slower.

Quote

> > Neither can I. I am not likely to upgrage for quite a while (and then I'll probably go for an OpenBSD box with large hard drives to act as a reliable fileserver rather than a high-end game machine).

> > Don't argue about the OS choice listed, it is just an example.

> What the frig is OpenBSD? Why should I argue? I use a dual boot Win95/Red Hat 5.2 (on a 1.5GB HDD, it's kinda cramped...)

The "Don't agrue" bit is because backing a non-Linux OS is a good way of starting a flame war. :-)

Quote

> > Feel free to write your own emulator to see how hard it is (I lost track of the number of times I rewrote the rendering engines in DarcNES).

> I would if I could afford a decent programming utility or could scam Visual C++ 6 off my friend (is that good enough?) and a few beginning tutorial books on programming.

gcc under RedHat is a decent programming utility (if you can stand using RedHat, that is). VC++6 would probably suffice for Win32 programming (I wouldn't know, I do all my Win32 programming in ASM).

There should be some programming tutorials available online somehwere (The art of ASM is a good example), but I don't know where to find them.

Quote

> I have VB5 professional (I can't figure it out) but I really don't think that it is a terribly good choice for programming an emulator. I'd program a front-end for BRSMS or Massage (Meka doesn't need one) if I could figure out how to output data into a .ini file or even how to get the data fron all the sliders, etc, into a command to call the selected program. See? I'm a gamer, not a programmer.

By this I assume that you don't actually have the manuals for VB5? (doesn't it come with online help?)

Quote

> > --Nyef

> --unfnknblvbl

> P.S. I'd use the P133 for playing MP3s amd the other for development.

I'm sure you would. The problem with that is that most of my stuff is on the p133 and I _don't_ like opening it to get the hard drives out (and copying that much stuff over 10Base-T would be silly). Plus some people like having emulators that work on slower systems, and the only way to do that properly is to develop on one. :-)

I'll probably switch after I get that fileserver mentioned earlier. Simply because I'd want all my data in a safe (SCSI RAID is safe, right?) place.

--Nyef

I repeat: "What the frig is OpenBSD?" is it any good?

Quote

> gcc under RedHat is a decent programming utility (if you can stand using RedHat, that is). VC++6 would probably suffice for Win32 programming (I wouldn't know, I do all my Win32 programming in ASM).

> There should be some programming tutorials available online somehwere (The art of ASM is a good example), but I don't know where to find them.

> > I have VB5 professional (I can't figure it out) but I really don't think that it is a terribly good choice for programming an emulator. I'd program a front-end for BRSMS or Massage (Meka doesn't need one) if I could figure out how to output data into a .ini file or even how to get the data fron all the sliders, etc, into a command to call the selected program. See? I'm a gamer, not a programmer.

> By this I assume that you don't actually have the manuals for VB5? (doesn't it come with online help?)

*coughp*
*coughi*
*coughr*
*cougha*
*cought*
*coughe*
Figure it out... why should I pay ~$800AUD for any software?
Books online sucks, anyway. Too complicated to get any useful information out of.

Quote

> I'll probably switch after I get that fileserver mentioned earlier. Simply because I'd want all my data in a safe (SCSI RAID is safe, right?) place.

Hmm... I saw a kernel module for Linux that adds support for some sort of filesystem that not only encrypts *all* of the data on the HDD, but hides it in such a way as to appear that the data was never there. Interesting...

-unfnknblvbl
P.S. What's wrong with Red Hat? Besides, Windoze is just fine for all of my needs except for graphics. All hail The GIMP!!!
(unless you know of any MIDI authoring software for Linux?..)

Quote

> > Didn't the xNES code get folded into the MESS project?

> It was heavily rewritten.

> > I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games.

> I must admit I didn't try DarcNES since a while. I'll compare with the DOS port soon.
> With VESA 2 enabled, Meka run Psycho Fox title screen at 80 fps on my machine, and most games vary between 40 and 60 fps.

Actually I am a firm believer in reinventing the wheel but the major reason behind that
is i feel coders should understand what they are doing alot of them dont but in my personal
experience meka runs rather well on my p100 is it full speed im not really sure probally not
but its not unbarably slow its more then playable

Author	Message
Eric Guest	Z80 Flags Posted: Mon Jul 12, 1999 2:58 am
Eric Guest	To any Z80 experts out there: Does any one know how the IN reg, (C) instruction affects the Auxilliary Carry (sometimes referred to as Half-Carry) flag? I have consulted both Marat's Z80 emulator source, Massage 6.1's source, and two independent Z80 documents regarding this instruction. There is very little consensus among them. Most of these documents state that the flag is modified. However, since no arithmetic operation is performed it is unclear to me how the modification could be meaningful. Perhaps the flag should be left untouched, or maybe SET or RESET? Also, Zoop, would you be willing to inform me what Z80 emulator you used in Meka? I'd like to check how it's IN reg, (C) instruction affects the flag. Any help is appreciated. Thank you. Eric Quinn

Chris Guest	I'm pissed Posted: Mon Jul 12, 1999 8:16 am
Chris Guest	Here's Meka... Marat's Z80 CPU Core <--Saves time, typing, and agrivation Allegro's Graphics Functions <--Saves time, typing, and studing VGA graphics SEAL's Sound Functions <--Saves, time, typing, and stuying sound cards Some Japanese dudes kick ass YM2143 Core <--I guess he figured, "Ahh what the hell, let's use this too". All compiled with DJGPP I bet. So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code. That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing the VDP and Sound interpretation codes. This is how 90% of the emulators out there are written. MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know what they all have in common... THEY ALL RUN SLOW ON MY P133!!! Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG. Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in mind before and during the time you're writing your emulator. Meka still kicks ass though, Zoop. Chris :o(

Chris Guest	Excuse my language nt Posted: Mon Jul 12, 1999 8:19 am
Chris Guest	Quote > Here's Meka... > Marat's Z80 CPU Core <--Saves time, typing, and agrivation > Allegro's Graphics Functions <--Saves time, typing, and studing VGA graphics > SEAL's Sound Functions <--Saves, time, typing, and stuying sound cards > Some Japanese dudes kick ass YM2143 Core <--I guess he figured, "Ahh what the hell, let's use this > too". > All compiled with DJGPP I bet. > So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code. > That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing > the VDP and Sound interpretation codes. This is how 90% of the emulators out there are written. > MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know > what they all have in common... > THEY ALL RUN SLOW ON MY P133!!! > Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would > I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines > for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's > the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody > will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're > only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG. > Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in > mind before and during the time you're writing your emulator. > Meka still kicks ass though, Zoop. > Chris :o( >

Limbs a Flyin' Guest	Re: I'm pissed Posted: Mon Jul 12, 1999 1:12 pm
Limbs a Flyin' Guest	Quote > That's why he could spend so much time writing a kick ass GUI. too similar to allegro's bog standard gui to be a co-incidence too, it shows how something ugly can look good with some tweaking Quote >He spent mabye a month writing > the VDP and Sound interpretation codes. This is how 90% of the emulators out there are written. > MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know > what they all have in common... > THEY ALL RUN SLOW ON MY P133!!! > Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would > I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines > for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's > the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody > will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're > only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG. > Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in > mind before and during the time you're writing your emulator. so then, explain to the clueless authors some detailed routines to do things faster, eg wave synthesis, prevention of redundant overdrawing and the like. Quote > Meka still kicks ass though, Zoop. even though its sounds like you are saying the opposite.. hmm i dunno. but anyways, how many of the mentioned emu's claimed that speed was their strong point? Quote > Chris :o( you seem to be out of character (or at least the type of character you have showen us in the past).. sure youre not an imposter? Quote >

Eric Guest	Re: I'm pissed Posted: Mon Jul 12, 1999 4:25 pm
Eric Guest	Quote > This is how 90% of the emulators out there are written. > MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know > what they all have in common... > THEY ALL RUN SLOW ON MY P133!!! You may have a point. Looking at the larger issue, does it make sense that 8-bit consoles should require so much computing power to emulate? I'm not convinced they should, either. HOWEVER, (that's a big "however") code optimization is not easy. It truly takes years to master, and during that time compilers, assemblers, and microprocessors will change, making anything the programmer knows about optimization all but obsolete. Additionally, there's the fact that not many programmers are willing to rip apart code they just got working in order to optimize it. Now, you may say, "just make sure it's optimized from the start." Well, that's easier said than done, as I'm sure you'll discover during the process of writing your emulator. Sometimes you just want to get the darn thing working. Quote > Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would > I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines > for Windows, I repeat, Windows, can run the same Mario Bros. game at fullspeed. See, that's > the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody > will admit that their emulator was poorly written. I'm not sure everyone who writes an emulator has high-performance in mind. Additionally, it's difficult to write an emulator on a PII-300 that performs well on a Pentium-133. A program always performs best on machines it was written/debugged on. Many of these authors may simply have fast computers, and their emulator runs fine on them. If you truly feel this state of affairs unacceptable, then I encourage you to write a high-performance emulator. Everyone will benefit. (Also, remember that the longer it takes you to write it, by tweaking it here and there, the faster computers will be by the time you're finished...) Good luck. Now, does anyone know about how the flags are affected by the IN reg, (C) instruction? Eric

Chris Guest	The Real Thing Posted: Mon Jul 12, 1999 8:06 pm
Chris Guest	Listen When I say poorly written I mean coding like this: Calling Function Emuate... OP Code found, calling function OPcode... special OP code found, calling header file functions... Oh, header function found graphics statement, calling graphics functions...done, I think calling sprite functions... leaving sprite functions... leaving graphics functions... returning from header functions... returning from Emulate function... All of this jumping back and fourth to other functions during an emulator loop. This waste so much time it's not even funny. I think it's absoulely rediculous. I'm not saying to not use functions at all, that's fucking phycotic. But be reasonible with the calls. Here's a good way... Calling function emulate... found opcode, performing instructions...done. found graphics code, calling graphics functions... in graphics, performing graphics...done. leaving graphics... leaving emulate... Now the above still wasn't the fastest, but that could drastically improve CPU emulation from 10 to 30% or more. Same thing goes for all graphics and sound capabilites for your emulator. You could be using Kgen's or Genecyst's 68k core. If your emulator calls hundreds of sound functions then your entire emulator will be affected. Now there's some things that you simply cannot help. Like a multiply or divide instruction. You have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use bit shifts when ever you can. For example, if you're going to multiply something times 2, don't just write this: a * 2 That's just pure carelessness. Write this a << 2; Now, was that all that bad? You just saved your PC another 50 cycles or so. I'm not some emulator expert, by no means. But these are just common programming principles that are required for Game Programming and emulator programming is a form of game programming. It's a high priority, realtime program that should be optomized here and there. Sure, technology is changing everyday, even as I type this message but come on, don't be so lazy and careless. Better yet, look at this analogy... A couple of people got together and wrote Mame. It's slow, but it's acceptable because it has lots of hardware support, right? Now, if those same people got together and wrote a Basic interpreter, called MameBasic, could you imagine how slow it would be? The way they write their programs are written, it would probably take 2 seconds or more to do a loop from 1 to 100!! But you know what they would say, "Oh well, it's acceptable because MameBasic can run on all OS." Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads, "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator programmers. But nobody cares to even take a glance at it. I'm guess I'm the only one that reads and looks at his updates. I got the perfect word...Careless Coders. People who are desperate to get their emulator to run some games at all cost. It's okay though. I'm just going to keep studying my Assembler, C, and emulator programming tutorials and mabye someday I'll get to prove my point. Chris :o\|

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Mon Jul 12, 1999 8:50 pm
	Quote > Also, Zoop, would you be willing to inform me what Z80 emulator you used in Meka? I'd like to check how it's IN reg, (C) instruction affects the flag. I'm using Marat core, as mentionned in the documentation

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: He's pissed Posted: Mon Jul 12, 1999 9:00 pm
	Quote > Marat's Z80 CPU Core <--Saves time, typing, and agrivation And frustration. Writing a CPU core is pretty easy but really boring and frustrating. And none of my core was in a state to be used for the emulator yet. Quote > Allegro's Graphics Functions <--Saves time, typing, and studing VGA graphics Doing VGA graphic manually is basically three instructions to initialize the video mode and the video memory is very easy to deal with as it is an array. Allegro is primarly used for compatibility, as it has been tested with a lot of hardware kind. And without Allegro I woudn't be able to include any joystick support for the simple reason I do not have a joystick myself (well, I recieved one since). Quote > SEAL's Sound Functions <--Saves, time, typing, and stuying sound cards That's because DOS sucks. With any good operating system (Windows and Linux on PC) you don't have to deal with this kind of thing anymore, which is absolutly crap and useless to study. Also, SEAL provide a compatibility with various kind of soundcard no single programmer would be able to provide (I could have done SB, and maybe GUS but I never tried to program my GUS before). Quote > Some Japanese dudes kick ass YM2143 Core <--I guess he figured, "Ahh what the hell, let's use this > too". He made it for Meka. Quote > All compiled with DJGPP I bet. And what does it mean ? You thought someone was typing instructions directly in hex into a binary file ? Hahaha. Quote > So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code. 10000 lines of code is nothing. Quote > That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing > the VDP and Sound interpretation codes. Sure, and that's all to emulate ? Finish your SG-1000 emulator you started ten years ago first. Quote > This is how 90% of the emulators out there are written. > MAME, DGen, DTMNT, Magic Engine, HU6280, RockNes, and yes, Meka. Now, you want to know > what they all have in common... > THEY ALL RUN SLOW ON MY P133!!! Magic Engine is 99% Assembly and is simply one of the fastest emulator around. Quote > Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would > I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines That's because FX3 doesn't know how to code, and his emulator is heavily based on xNES which a friend made and was the worst piece of code ever made. Quote > for Windows, I repeat, Windows, What's the problem with Windows ? It is not slow. Quote > can run the same Mario Bros. game at fullspeed. See, that's > the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody > will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're > only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG. > Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in > mind before and during the time you're writing your emulator. What's the problem if someone want to release an emulator ? You are not forced to use anything. Nesticle CPU core is based on another one, by the way.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Meka GUI Posted: Mon Jul 12, 1999 9:01 pm
	Quote > > That's why he could spend so much time writing a kick ass GUI. > too similar to allegro's bog standard gui to be a co-incidence too, it shows how something ugly can look good with some tweaking The GUI was wrote absolutly from stratch, expect from the putpixel and line routines (very hard to write, man!).

Lin Ke-Fong Guest	Re: The Real Thing Posted: Mon Jul 12, 1999 9:02 pm
Lin Ke-Fong Guest	[...] Quote > Now there's some things that you simply cannot help. Like a multiply or divide instruction. You > have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use > bit shifts when ever you can. For example, if you're going to multiply something times 2, don't > just write this: > a * 2 > That's just pure carelessness. Write this > a << 2; > Now, was that all that bad? You just saved your PC another 50 cycles or so. Euh, most compilers (djgpp included), replace automaticaly a * 2 by either a +a or a << 2. So for now a * 2 is better, because it's less cryptic. It's among the easiest optimization a compiler can make. Even a student project mini-compiler can easily implement that sort of optimization. [...] Quote > Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads, > "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator > programmers. But nobody cares to even take a glance at it. I'm guess I'm the only one that reads and > looks at his updates. I got the perfect word...Careless Coders. People who are desperate to get > their emulator to run some games at all cost. Okay, I guess Mame is written in C because it's for porting purpose, and probably because it runs just great enough on their PII computers. Well mame runs pretty well on my PII, though. I understand how you feel about that the emulators are not fast enough, one year ago I still had my good old 486, and the only emulator I was able to run around was massage. Most emulators are freeware, and authors cannot work on them like if they were game to be sold... Maybe you should not ask too much.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Alright. Please answer to everything. Posted: Mon Jul 12, 1999 9:11 pm
	Quote > Calling Function Emuate... > OP Code found, calling function OPcode... > special OP code found, calling header file functions... > Oh, header function found graphics statement, calling graphics functions...done, I think > calling sprite functions... > leaving sprite functions... > leaving graphics functions... > returning from header functions... > returning from Emulate function... Wow, you really know a lot about emulation! (it's pure bullshit, btw) Quote > All of this jumping back and fourth to other functions during an emulator loop. This waste > so much time it's not even funny. I think it's absoulely rediculous. I'm not saying to not use > functions at all, that's fucking phycotic. But be reasonible with the calls. Here's a good way... And do think it's leaving a function ten times a second that make an emulator slow ? Quote > Calling function emulate... > found opcode, performing instructions...done. > found graphics code, calling graphics functions... > in graphics, performing graphics...done. > leaving graphics... > leaving emulate... > Now the above still wasn't the fastest, but that could drastically improve CPU emulation from 10 to It's exactly the same thing. Quote > 30% or more. Same thing goes for all graphics and sound capabilites for your emulator. You > could be using Kgen's or Genecyst's 68k core. They were not released. Quote > Now there's some things that you simply cannot help. Like a multiply or divide instruction. You > have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use > bit shifts when ever you can. For example, if you're going to multiply something times 2, don't > just write this: > a * 2 > That's just pure carelessness. Write this > a << 2; Man, you are really a good programmer. This is the most simplest optimisation you can do, and just about all C compiler do it for yourself when you multiply/divise by a power of two. Btw, the right thing to do was "a << 1" and not "a << 2". Considering the fact you also posted some questions about how to "handle bits in a byte" a few days ago, that make me think you do not even know what you are talking about. Quote > Now, was that all that bad? You just saved your PC another 50 cycles or so. I would say 15 cycle, if not less. [..] Quote > Now, if those same people got together and wrote a Basic interpreter, called MameBasic, > could you imagine how slow it would be? The way they write their programs are written, it would > probably take 2 seconds or more to do a loop from 1 to 100!! HAHAHAHAHAHA! Even the CPU in my watch would do better. Quote > But you know what they would say, "Oh well, it's acceptable because MameBasic can run on all OS." Because it is C and because of the way it was originally wrote. Most of the programmers in MAME team are really good. Quote > Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads, > "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator > programmers. But nobody cares to even take a glance at it. How do you know that ? Larry is mainly emulating very simplest game systems, and his optimisations do not apply to most systems. I even doubt he did emulate a system with hardware scrolling or more than one layer ! Quote > I'm guess I'm the only one that reads and looks at his updates. And you do even understand them ? (I'm serious) Quote > It's okay though. I'm just going to keep studying my Assembler, C, and emulator programming > tutorials and mabye someday I'll get to prove my point. Then you are not on the right tracks, because good programmers do not have to read tutorials.

Chris Guest	Re: Alright. Please answer to everything. Posted: Mon Jul 12, 1999 11:36 pm
Chris Guest	Quote > > Calling Function Emuate... > > OP Code found, calling function OPcode... > > special OP code found, calling header file functions... > > Oh, header function found graphics statement, calling graphics functions...done, I think > > calling sprite functions... > > leaving sprite functions... > > leaving graphics functions... > > returning from header functions... > > returning from Emulate function... > Wow, you really know a lot about emulation! > (it's pure bullshit, btw) No, I don't know a lot but I know that's how a lot of emulators are written. Quote > > All of this jumping back and fourth to other functions during an emulator loop. This waste > > so much time it's not even funny. I think it's absoulely rediculous. I'm not saying to not use > > functions at all, that's fucking phycotic. But be reasonible with the calls. Here's a good way... > And do think it's leaving a function ten times a second that make an emulator slow ? I can slow it down a little. Now, when you're looping that little becomes a lot and slows things down. Am I right or wrong? Quote > > Calling function emulate... > > found opcode, performing instructions...done. > > found graphics code, calling graphics functions... > > in graphics, performing graphics...done. > > leaving graphics... > > leaving emulate... > > Now the above still wasn't the fastest, but that could drastically improve CPU emulation from 10 to > It's exactly the same thing. No, it's not exactly the same thing. There's a little difference because that's using less functions. Quote > > 30% or more. Same thing goes for all graphics and sound capabilites for your emulator. You > > could be using Kgen's or Genecyst's 68k core. > They were not released. huh? Quote > > Now there's some things that you simply cannot help. Like a multiply or divide instruction. You > > have no choice but to do a * or a /. Same thing in assembler, MUL and DIV. But try to use > > bit shifts when ever you can. For example, if you're going to multiply something times 2, don't > > just write this: > > a * 2 > > That's just pure carelessness. Write this > > a << 2; > Man, you are really a good programmer. This is the most simplest optimisation you can do, and > just about all C compiler do it for yourself when you multiply/divise by a power of two. Oh yeah, << 1. Forgot that fast. Thanks :o) Quote > Btw, the right thing to do was "a << 1" and not "a << 2". Considering the fact you also posted some > questions about how to "handle bits in a byte" a few days ago, that make me think you do not even > know what you are talking about. I know what I'm talking about. Just a typeo, sort of. Quote > > Now, was that all that bad? You just saved your PC another 50 cycles or so. > I would say 15 cycle, if not less. Okay, but it does save some CPU time. Right, or wrong? Quote > [..] > > Now, if those same people got together and wrote a Basic interpreter, called MameBasic, > > could you imagine how slow it would be? The way they write their programs are written, it would > > probably take 2 seconds or more to do a loop from 1 to 100!! > HAHAHAHAHAHA! Even the CPU in my watch would do better. > > But you know what they would say, "Oh well, it's acceptable because MameBasic can run on all OS." > Because it is C and because of the way it was originally wrote. > Most of the programmers in MAME team are really good. I didn't say they weren't. I'm just saying under MAME Galaga can barely run at 5 frameskip on my P133 :o) Quote > > Why do you think people like Larry Banks and Neil Bradley are preaching this stuff into our heads, > > "optomization, optomization". Larry even put up a huge Code Corner, aimed directly to emulator > > programmers. But nobody cares to even take a glance at it. > How do you know that ? > Larry is mainly emulating very simplest game systems, and his optimisations do not apply to most > systems. I even doubt he did emulate a system with hardware scrolling or more than one layer ! You do have a point because Hive dosen't emulate anything after 1985, except for Galaga 88 and that uses ancient hardware. Quote > > I'm guess I'm the only one that reads and looks at his updates. > And you do even understand them ? (I'm serious) Yes, I do understand sections here and there. I just wish I could express what I want to be done in C. My syntax is wrong but my ideas are correct. Quote > > It's okay though. I'm just going to keep studying my Assembler, C, and emulator programming > > tutorials and mabye someday I'll get to prove my point. > Then you are not on the right tracks, because good programmers do not have to read tutorials. So you mean to tell me you wrote Meka entirely by yourself without any help from anyone? Sorry Zoop, I don't believe you on that one. I couldn't write my SG1K without your doc. If I made you angry I'm sorry. I'm just pissed because I can't run anything over 16 bits on my PC. I guess I'll just stop bitching and upgrade my PC. "Can't we all just get along?" -Rodney King Chris :o)

Chris Guest	Yeah Posted: Mon Jul 12, 1999 11:38 pm
Chris Guest	I'll stop bitching about it. I guess I'll get a job, save up money, and either buy a new PC or a little laptop for college. Chris :o)

Chris Guest	I give up Posted: Tue Jul 13, 1999 12:02 am
Chris Guest	Wah! I can't take it anymore! You win! You all win! Zoop I am absolutely sorry for ever saying anything bad about your expertise on emu programming. I'm sick of arguing. Let's get back to asking questions about carry flags and pointers. Chris :o)

Lin Ke-Fong Guest	Re: Yeah Posted: Tue Jul 13, 1999 4:15 am
Lin Ke-Fong Guest	Quote > I'll stop bitching about it. I guess I'll get a job, save up money, and either buy a new PC > or a little laptop for college. You are somewhat right about doing some optimizations, for instance Mame's Narc is pure C and it features a 48MHz TMS34010 chip, it truely needs to be rewritten in asm, but well don't blame the authors, it's already an incredible work to have a working Narc, even slow. PS: I've done a mistake, a * 2 is in fact a << 1 and not a << 2 (a << 2 is a * 4), I am sorry.

Nyef Guest	Re: He's pissed Posted: Tue Jul 13, 1999 4:41 pm
Nyef Guest	Quote > > Marat's Z80 CPU Core <--Saves time, typing, and agrivation > And frustration. Writing a CPU core is pretty easy but really boring and frustrating. > And none of my core was in a state to be used for the emulator yet. This is almost always the case (as an aside, makez80 is apparently 4 or more times faster than Marat's core). Quote > > All compiled with DJGPP I bet. > And what does it mean ? Aside from long compile times, that is (the _real_ reason to use ASM isn't for runtime speed). Quote > You thought someone was typing instructions directly in hex into a binary file ? Hahaha. Been there, done that (it worked, too). :-) Quote > > So basically, using everyone else's stuff, that just saved him well over 10,000 lines of code. > 10000 lines of code is nothing. And all of the "objectionably-oriented" programmers have been screaming "code reuse" at us for so long that many emu authors figure "what the heck, lets try it". :-) Quote > > That's why he could spend so much time writing a kick ass GUI. He spent mabye a month writing > > the VDP and Sound interpretation codes. > Sure, and that's all to emulate ? > Finish your SG-1000 emulator you started ten years ago first. At least the VDP and sound code is more interesting than a z80 core or some vga drivers. Quote > Magic Engine is 99% Assembly and is simply one of the fastest emulator around. Ah. I had been wondering. Quote > > Their all poorly written for emulation!!! A very good example is RockNes!!! Why the fuck would > > I need 6 frameskip to run Super Mario Bros!!?? Meanwhile a simple, old ass emulator like Ines > That's because FX3 doesn't know how to code, and his emulator is heavily based on xNES which > a friend made and was the worst piece of code ever made. RockNES is based on both xNES and DarcNES. In the case of video, the DarcNES control code and the xNES blitter (if you can call that a blitter). Didn't the xNES code get folded into the MESS project? I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games. Quote > > for Windows, I repeat, Windows, > What's the problem with Windows ? It is not slow. It's also full of fun ways to obtain ABSOLUTE POWER. :-) Quote > > can run the same Mario Bros. game at fullspeed. See, that's > > the problem with emulation. Everybody and their uncle wants to write an emulator, but nobody > > will admit that their emulator was poorly written. So, they blame the hardware. "Eww, you're > > only using a P133? You'll need a Pentium III 500 and 64MB RAM" just to run fucking PONG. "Eww, you're only using a P133? Finally, someone with a computer as slow as mine. :-P" Quote > > Bullshit!!! You don't have to be a speed freak like Sardu or Larry Banks, but keep them in > > mind before and during the time you're writing your emulator. I'm not a speed freak, I just want to be able to play at full speed on my Linux box with no frameskip. :-) --Nyef

unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Re: Alright. Please answer to everything. Posted: Tue Jul 13, 1999 6:20 pm
unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Young Christopher ;) here has a point. I am of the belief that most Emulator Programmers are in high-paying jobs and can afford to go out and buy the latest PIII 550 with 1GB SDRAM or whatever the fuck the latest computer is at the moment. Quite a lot of us emulator users (that I know of) are just students who are on Austudy (student welfare(?)) and cannot afford to go out and buy said system whenever they want. Why should we need a state-of-the-art computer to emulate a console that was state-of-the-art 10 years ago!?

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Comparing speed Posted: Tue Jul 13, 1999 7:07 pm
	Quote > Didn't the xNES code get folded into the MESS project? It was heavily rewritten. Quote > I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games. I must admit I didn't try DarcNES since a while. I'll compare with the DOS port soon. With VESA 2 enabled, Meka run Psycho Fox title screen at 80 fps on my machine, and most games vary between 40 and 60 fps.

Nyef Guest	Re: Alright. Please answer to everything. Posted: Tue Jul 13, 1999 8:17 pm
Nyef Guest	Quote > Young Christopher ;) here has a point. And not one to be dismissed out of hand, either. Quote > I am of the belief that most Emulator Programmers are in high-paying jobs and can afford to go out and buy the latest PIII 550 with 1GB SDRAM or whatever the fuck the latest computer is at the moment. I am not of that belief. I starting programming emulators at school on a p133 and almost no income. It was at least 8 months after I got a real job before I got a better machine (mainly used for playing mp3s, I still use the p133 for development). Quote > Quite a lot of us emulator users (that I know of) are just students who are on Austudy (student welfare(?)) and cannot afford to go out and buy said system whenever they want. Neither can I. I am not likely to upgrage for quite a while (and then I'll probably go for an OpenBSD box with large hard drives to act as a reliable fileserver rather than a high-end game machine). Don't argue about the OS choice listed, it is just an example. Quote > Why should we need a state-of-the-art computer to emulate a console that was state-of-the-art 10 years ago!? Because most programmers rely on Moore's law. Also because the console has dedicated hardware that has to be emulated in software. It doesn't help that a number of authors are really bad at coding (no, I won't be naming names). Feel free to write your own emulator to see how hard it is (I lost track of the number of times I rewrote the rendering engines in DarcNES). --Nyef

Nyef Guest	Re: Comparing speed Posted: Tue Jul 13, 1999 8:23 pm
Nyef Guest	Quote > > Didn't the xNES code get folded into the MESS project? > It was heavily rewritten. > > I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games. > I must admit I didn't try DarcNES since a while. I'll compare with the DOS port soon. > With VESA 2 enabled, Meka run Psycho Fox title screen at 80 fps on my machine, and most games vary between 40 and 60 fps. I was actually thinking of a more scientific test, since DarcNES DOS has a speed lock that prevents it from going faster than 60fps. Plus there is no fps counter. Most games that I have tested (phantasy star, california games, zillion) run at about 60 fps (sometimes a little slower) on my development machine (a p133 Linux box) when compiled as SVGALib. --Nyef

unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Yeah, well... Posted: Wed Jul 14, 1999 9:11 am
unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Quote > > Quite a lot of us emulator users (that I know of) are just students who are on Austudy (student welfare(?)) and cannot afford to go out and buy said system whenever they want. > Neither can I. I am not likely to upgrage for quite a while (and then I'll probably go for an OpenBSD box with large hard drives to act as a reliable fileserver rather than a high-end game machine). > Don't argue about the OS choice listed, it is just an example. What the frig is OpenBSD? Why should I argue? I use a dual boot Win95/Red Hat 5.2 (on a 1.5GB HDD, it's kinda cramped...) Quote > Feel free to write your own emulator to see how hard it is (I lost track of the number of times I rewrote the rendering engines in DarcNES). I would if I could afford a decent programming utility or could scam Visual C++ 6 off my friend (is that good enough?) and a few beginning tutorial books on programming. I have VB5 professional (I can't figure it out) but I really don't think that it is a terribly good choice for programming an emulator. I'd program a front-end for BRSMS or Massage (Meka doesn't need one) if I could figure out how to output data into a .ini file or even how to get the data fron all the sliders, etc, into a command to call the selected program. See? I'm a gamer, not a programmer. Quote > --Nyef --unfnknblvbl P.S. I'd use the P133 for playing MP3s amd the other for development.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: Comparing speed Posted: Wed Jul 14, 1999 9:49 am
	Quote > I was actually thinking of a more scientific test, since DarcNES DOS has a speed lock that prevents it from going faster than 60fps. Plus there is no fps counter. > Most games that I have tested (phantasy star, california games, zillion) run at about 60 fps (sometimes a little slower) on my development machine (a p133 Linux box) when compiled as SVGALib. Then we got approximately the same speed, maybe Meka is slighty slower.

Nyef Guest	Re: Yeah, well... Posted: Wed Jul 14, 1999 2:50 pm
Nyef Guest	Quote > > Neither can I. I am not likely to upgrage for quite a while (and then I'll probably go for an OpenBSD box with large hard drives to act as a reliable fileserver rather than a high-end game machine). > > Don't argue about the OS choice listed, it is just an example. > What the frig is OpenBSD? Why should I argue? I use a dual boot Win95/Red Hat 5.2 (on a 1.5GB HDD, it's kinda cramped...) The "Don't agrue" bit is because backing a non-Linux OS is a good way of starting a flame war. :-) Quote > > Feel free to write your own emulator to see how hard it is (I lost track of the number of times I rewrote the rendering engines in DarcNES). > I would if I could afford a decent programming utility or could scam Visual C++ 6 off my friend (is that good enough?) and a few beginning tutorial books on programming. gcc under RedHat is a decent programming utility (if you can stand using RedHat, that is). VC++6 would probably suffice for Win32 programming (I wouldn't know, I do all my Win32 programming in ASM). There should be some programming tutorials available online somehwere (The art of ASM is a good example), but I don't know where to find them. Quote > I have VB5 professional (I can't figure it out) but I really don't think that it is a terribly good choice for programming an emulator. I'd program a front-end for BRSMS or Massage (Meka doesn't need one) if I could figure out how to output data into a .ini file or even how to get the data fron all the sliders, etc, into a command to call the selected program. See? I'm a gamer, not a programmer. By this I assume that you don't actually have the manuals for VB5? (doesn't it come with online help?) Quote > > --Nyef > --unfnknblvbl > P.S. I'd use the P133 for playing MP3s amd the other for development. I'm sure you would. The problem with that is that most of my stuff is on the p133 and I _don't_ like opening it to get the hard drives out (and copying that much stuff over 10Base-T would be silly). Plus some people like having emulators that work on slower systems, and the only way to do that properly is to develop on one. :-) I'll probably switch after I get that fileserver mentioned earlier. Simply because I'd want all my data in a safe (SCSI RAID is safe, right?) place. --Nyef

unfnknblvbl Joined: 12 Jul 1999 Posts: 891	Re: Yeah, well... Posted: Wed Jul 14, 1999 5:31 pm
unfnknblvbl Joined: 12 Jul 1999 Posts: 891	I repeat: "What the frig is OpenBSD?" is it any good? Quote > gcc under RedHat is a decent programming utility (if you can stand using RedHat, that is). VC++6 would probably suffice for Win32 programming (I wouldn't know, I do all my Win32 programming in ASM). > There should be some programming tutorials available online somehwere (The art of ASM is a good example), but I don't know where to find them. > > I have VB5 professional (I can't figure it out) but I really don't think that it is a terribly good choice for programming an emulator. I'd program a front-end for BRSMS or Massage (Meka doesn't need one) if I could figure out how to output data into a .ini file or even how to get the data fron all the sliders, etc, into a command to call the selected program. See? I'm a gamer, not a programmer. > By this I assume that you don't actually have the manuals for VB5? (doesn't it come with online help?) coughp coughi coughr cougha cought coughe Figure it out... why should I pay ~$800AUD for any software? Books online sucks, anyway. Too complicated to get any useful information out of. Quote > I'll probably switch after I get that fileserver mentioned earlier. Simply because I'd want all my data in a safe (SCSI RAID is safe, right?) place. Hmm... I saw a kernel module for Linux that adds support for some sort of filesystem that not only encrypts all of the data on the HDD, but hides it in such a way as to appear that the data was never there. Interesting... -unfnknblvbl P.S. What's wrong with Red Hat? Besides, Windoze is just fine for all of my needs except for graphics. All hail The GIMP!!! (unless you know of any MIDI authoring software for Linux?..)

ziggy880 Guest	Re: Comparing speed Posted: Thu Jul 15, 1999 6:37 am
ziggy880 Guest	Quote > > Didn't the xNES code get folded into the MESS project? > It was heavily rewritten. > > I would actually be interested to see how DarcNES and Meka compare speedwise for SMS games. > I must admit I didn't try DarcNES since a while. I'll compare with the DOS port soon. > With VESA 2 enabled, Meka run Psycho Fox title screen at 80 fps on my machine, and most games vary between 40 and 60 fps. Actually I am a firm believer in reinventing the wheel but the major reason behind that is i feel coders should understand what they are doing alot of them dont but in my personal experience meka runs rather well on my p100 is it full speed im not really sure probally not but its not unbarably slow its more then playable

Forums

View topic - Z80 Flags