Previous Thread
Next Thread
Print Thread
Page 55 of 120 1 2 53 54 55 56 57 119 120
Joined: Mar 2001
Posts: 16,960
Likes: 76
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,960
Likes: 76
Haze: the timing in MAME used to be unstable when everything was float-based. The all-integer system used now is very solid in my (admittedly limited) testing.

As far as the Megadrive, your best bet is probably to work with the Spritesmind guys. If you can cook up some test programs I'm sure they'd be willing to run them on hardware.

Joined: May 2009
Posts: 2,092
Likes: 126
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,092
Likes: 126
Originally Posted By R. Belmont
3) Fix remaining rendering issues (offset-per-tile, range over, tile over, mosaic). Maybe we do just use the bsnes code - there's a fairly compelling story there, but are we willing to completely trash what we have?


It's Kale's and Fabio's code, not mine, but I would just like to offer my two cents: Having an emotional attachment to code in MAME or MESS is dangerous. Comparing MAME's code 10 years ago to MAME's code today, the drivers have almost nothing in common, and I don't dare imagine how much things will evolve in the coming 10 years. Speaking for the code that I've written, I welcome anyone to come in and rewrite it. smile

Joined: Jun 2008
Posts: 205
B
Senior Member
Offline
Senior Member
B
Joined: Jun 2008
Posts: 205
Quote:
and I thought I'd dealt with things which were fussy over timing ...


I don't even think it was intentional. In Mortal Kombat II's case, it was setting the HIRQ counter for something like dot # 64, and the code it executed after that took just under the needed amount.

I'm sure the devs weren't even bothering to count cycles. They probably tried a few numbers, saw that 64 worked okay and went with it. So when I was off by one cycle, it was just missing the IRQ, stopping it from setting up all future IRQs for the frame, completely destroying things.

It's funny, too. ZSNES tends to run about 40% faster than the real hardware, so it finished with plenty of time to share before the IRQ event. You can get much better compatibility by running things way too fast than running them just a little too slow. These bugs don't even show up until you really start to hammer down all the hardware delays (DRAM refresh, penalty cycles, memory access speeds), and it makes your emulator appear to be the less accurate one when the bugs show up.

Quote:
I think we should take it eventually.


Ah, that's good. I can see myself being active for another 5-10 years or so, but I certainly don't have the longevity of something like MAME.

Quote:
Once cothreads are added to the MAME core (Aaron is interested, but I don't know what all would be involved)


Wow, is he really going to add that? I was under the impression the save state issue was a deal breaker.

Please see if he's interested in libco. Runs just about everywhere (even on SPARC, MIPS and PPC), and the x86-32/x86-64 ones are insanely optimized (~10 opcodes, in large part thanks to Aaron himself and Shay Green.) Any new platform modules could flow back to me which would be incredibly helpful.

I really feel they're a huge benefit to writing sane, easy-to-read code. I was disappointed that they never caught on with anyone.

Entire API, stable for 3 years now:
Code:
cothread_t co_active();
cothread_t co_create(unsigned int, void (*)(void));
void co_delete(cothread_t);
void co_switch(cothread_t);


Simple enough for a goldfish to figure out.

Quote:
Haze: the timing in MAME used to be unstable when everything was float-based. The all-integer system used now is very solid in my (admittedly limited) testing.


Whew. I was about to cry, thinking MAME was still FP-based.

Are they see-saw counters, or are they all grouped?

See-saw: one signed counter represents a link between two components. When A moves, increment counter, when B moves, decrement it. When A does something that B can see, make sure counter < 0, when B does something A can see, make sure counter >= 0, else sync up the other chip.

Grouped: one unsigned counter per component, all counters get normalized periodically (subtract lowest counter from all of them) to prevent overflow. When A does something B can see, ensure Acounter >= Bcounter, and vice versa.

I like the former model a lot better myself, much easier and faster. But every emu source I've seen uses the latter.

Quote:
Having an emotional attachment to code in MAME or MESS is dangerous


I would say that's the case for any project, but especially for MAME / MESS smile

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
erm... dunno Kale's feelings but I don't really care about current code. I guess most of it still dates back to Anthony Kruize or to the first Arbee's rewrite, but I tried to make the video code as similar as possible at byuu's source at concept stage.

the final rendering is still done quite differently but if you compare most of the drawing routines, you can easily see the parallelism

that said, if anyone feels the need of a rewrite, be my guest. I had attempted already once to rip the pixel output stage and replace it with a (hopefully more accurate) different implementation, but I failed. I have no time to retry the whole thing at the moment, so feel free to take over the task

Joined: Mar 2001
Posts: 16,960
Likes: 76
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,960
Likes: 76
byuu: libco is definitely a large part of the interest, since it takes care of the actual task switching quite nicely.

ETA: (err, edited to add, not etabeta) also, I wasn't speaking of an emotional attachment, more of a utilitarian "did we just waste everyone's time" kind of thing. That said, it looks like there are few objections. JD can probably do the port himself if he wants to.

Last edited by R. Belmont; 09/23/09 09:35 PM.
byuu #54312 09/23/09 09:37 PM
Joined: Feb 2008
Posts: 107
D
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
Originally Posted By byuu
These bugs don't even show up until you really start to hammer down all the hardware delays (DRAM refresh, penalty cycles, memory access speeds), and it makes your emulator appear to be the less accurate one when the bugs show up.


Oh yeah. You'd think Dreamcast, with all it's power, is exempt from timing issues such as these. Nope. No such luck. It's only a few "problematic" titles though.

Joined: May 2009
Posts: 2,092
Likes: 126
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,092
Likes: 126
Originally Posted By R. Belmont
JD can probably do the port himself if he wants to.


I probably could if I wanted to. Right now I'm tied up with CD-i, though. smile

Joined: Mar 2001
Posts: 16,960
Likes: 76
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,960
Likes: 76
Xbox 1 is the timing hater's dream console. MS used reject-bin RAM for the first year or two of production to save costs and the BIOS did a fairly elaborate set of tests each power-on to figure out what clock it was stable at. This meant that each console ran the RAM at a different clock, which sometimes resulted in visible framerate differences between two systems.

Joined: Jun 2008
Posts: 205
B
Senior Member
Offline
Senior Member
B
Joined: Jun 2008
Posts: 205
Quote:
byuu: libco is definitely a large part of the interest, since it takes care of the actual task switching quite nicely.


Awesome! Oh, it's also thread-safe (each thread can have its own cothreads running), and the main core of MAME / MESS need not even know about it.

If you guys get serious about it, please let me know. I'll explain how to get around the save state issue, how to pass arguments to newly created cothreads, and how to vastly speed things up by running out-of-order and only syncing on reads from chips that aren't yet caught up.

I literally run the S-CPU and S-SMP several thousand opcodes out of sync with each other =)

Quote:
Oh yeah. You'd think Dreamcast, with all it's power, is exempt from timing issues such as these. Nope. No such luck.


Are you serious? That completely ruins my theory that the faster a system gets, the less accuracy you need to emulate it frown

Quote:
MS used reject-bin RAM for the first year or two of production to save costs and the BIOS did a fairly elaborate set of tests each power-on to figure out what clock it was stable at.


Thanks. As if I needed more reasons to never buy an MS-produced gaming console smile

byuu #54316 09/23/09 10:46 PM
Joined: Mar 2001
Posts: 16,960
Likes: 76
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,960
Likes: 76
You need less accuracy in general (it's hard to count cycles when caches are involved), but certain operations (usually audio/video streaming) end up relying pretty tightly on timings even when the programmer didn't actually intend it. And that's one case where being way too fast does hurt smile

Page 55 of 120 1 2 53 54 55 56 57 119 120

Link Copied to Clipboard
Who's Online Now
2 members (Kale, eberhab), 35 guests, and 4 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,158
Posts119,916
Members5,034
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com