Top Gear 3000

[Nach]

I did a lot of debugging to see why is it screwing up.
I think the problem is somewhere in ZSNES' CPU core, since ZSNES is trying to access the DSP-4 when it shouldn't be. Or at least ZSNES is trying to access it at a time when Snes9x which I compared to doesn't.

[Dreamer_Nom]

(CVS files, not WIP 02-24-05)

dsp4emu.c

(uninitialised variable after label resume6)
- line 1178: bool8 draw;
- line 1232: draw = TRUE;

(I've never understood why the nybbles get flipped during emulation but not with the real binary data)
(Either way, will temporarily fix the AI issue)
- line 2241: uncomment line
- line 2242: comment out line


dsp4proc.asm

(add)
EXTSYM regaccessbankr16,regaccessbankr8
EXTSYM regaccessbankw16,regaccessbankw8

Code: Select all

NEWSYM DSP4Read8b
    test ecx,8000h
    jnz .dsp4area
    jmp regaccessbankr8
.dsp4area
(regular code)

(Repeat for DSP4Read16b, DSP4Write8b, DSP4Write16b)


As for the flicker, well... timing...? :/
It does run faster than the current snes9x one though.

Regardless, nice work Nach.

[Nach]

Thanks for the info, I thought I had to do something with the normal registry accesses, but I wasn't sure.

I also would not have noticed the problem with draw.

The two versions with Op 0A however, I've been playing with since I wasn't sure which had to be used.

As for speed, I bet I can get it even faster if I integrate DSP4GetByte/DSP4SetByte into the assembly better and clean up the DSP-4 core a bit.

For the flickering, odds are, I messed up something when porting it to C, as I have the same problem when I threw my C core into Snes9x. I'll have to look things over.

[Dreamer_Nom]

Thanks for the info, I thought I had to do something with the normal registry accesses, but I wasn't sure.

(quote) Looking at the crazy inputs to OP01 and putting an "int 3" on GetByte flushed out the WRAM read to the DSP-4.

I also would not have noticed the problem with draw.

(quote) When the sprites didn't show up in-race, I knew where to look fast. ;)

The two versions with Op 0A however, I've been playing with since I wasn't sure which had to be used.

(quote) The correct version is line 2242 but then the inputs appear to get nybble-flipped, from looking at normal logged inputs to OP0A.

As for speed, I bet I can get it even faster if I integrate DSP4GetByte/DSP4SetByte into the assembly better and clean up the DSP-4 core a bit.

(quote) Ooh. Nice. :) It can be ungodly slow sometimes, especially with 1P-split.

For the flickering, odds are, I messed up something when porting it to C, as I have the same problem when I threw my C core into Snes9x. I'll have to look things over.

(quote) Even the C++ code causes the same flicker with 9x. I remember once hearing (Overload?) that it was insane timing but my memory is foggy. It's supposed to render the track twice per frame and the WAI throws things off more. There's no chance I can fix anything that deep. I think Super Sleuth handles live data from the chip fine though. The forks in the road are really the ideal timing test cases.

[Nach]

Thanks for the info, I thought I had to do something with the normal registry accesses, but I wasn't sure.

(quote) Looking at the crazy inputs to OP01 and putting an "int 3" on GetByte flushed out the WRAM read to the DSP-4.

Well I realized it was doing something it wasn't with my debug core.

Code: Select all

ZSNES:
Multiplier: 4294966272; Multiplicand: 192
DSP4Set Address: 32768; Byte: 76
DSP4Set Address: 32769; Byte: 0
DSP4Get Address: 32768; Byte: 253
DSP4Get Address: 32769; Byte: 255
DSP4Get Address: 180; Byte: 128
DSP4Get Address: 181; Byte: 128
DSP4Get Address: 549; Byte: 128
DSP4Get Address: 550; Byte: 128
DSP4Get Address: 550; Byte: 128
DSP4Get Address: 551; Byte: 128
DSP4Set Address: 32768; Byte: 0
DSP4Set Address: 32769; Byte: 0
DSP4Set Address: 32768; Byte: 0
DSP4Set Address: 32769; Byte: 0
DSP4Set Address: 32768; Byte: 0
DSP4Set Address: 32769; Byte: 252
DSP4 Command: 0
Multiplier: 0; Multiplicand: 4294966272

Snes9x:
Multiplier: 4294966272; Multiplicand: 192
DSP4Set Address: 32768; Byte: 76
DSP4Set Address: 32769; Byte: 0
DSP4Get Address: 32768; Byte: 253
DSP4Get Address: 32769; Byte: 255
DSP4Set Address: 32768; Byte: 0
DSP4Set Address: 32769; Byte: 0
DSP4Set Address: 32768; Byte: 0
DSP4Set Address: 32769; Byte: 239
DSP4Set Address: 32768; Byte: 0
DSP4Set Address: 32769; Byte: 252
DSP4 Command: 0
Multiplier: 4294962944; Multiplicand: 4294966272

What I meant was I didn't know how to fix it. I looked at how the DSP-2 was tied in to write dsp4proc.asm. BTW is that test for 8000 correct?
Because there's this test too:

Code: Select all

if ((dsp4_address & 0xf000) == 0x6000 || (dsp4_address >= 0x8000 && dsp4_address < 0xc000))

For the flickering, odds are, I messed up something when porting it to C, as I have the same problem when I threw my C core into Snes9x. I'll have to look things over.

(quote) Even the C++ code causes the same flicker with 9x. I remember once hearing (Overload?) that it was insane timing but my memory is foggy. It's supposed to render the track twice per frame and the WAI throws things off more. There's no chance I can fix anything that deep. I think Super Sleuth handles live data from the chip fine though. The forks in the road are really the ideal timing test cases.

Maybe it's just my imagination, but the C++ code has less flickering.
Perhaps if we put some pauses into the core somewhere it won't flicker so much?

Current progress:

[snkcube]

That is some great progress. Fantastic job.

[Dreamer_Nom]

BTW is that test for 8000 correct?
Because there's this test too:

Code: Select all

if ((dsp4_address & 0xf000) == 0x6000 || (dsp4_address >= 0x8000 && dsp4_address < 0xc000))

(quote) Ahm.. Let me think. If we don't do the "test ecx,$8000", then DSP4Read16b will call DSP4GetByte. DSP4GetByte would return the SR = 0x80 instead of WRAM. I could easily be wrong though as I'm not technically inclined.

Maybe it's just my imagination, but the C++ code has less flickering.
Perhaps if we put some pauses into the core somewhere it won't flicker so much?

(quote) You could easily be right. I played around with it but no dice.

[Nach]

BTW is that test for 8000 correct?
Because there's this test too:

Code: Select all

if ((dsp4_address & 0xf000) == 0x6000 || (dsp4_address >= 0x8000 && dsp4_address < 0xc000))

(quote) Ahm.. Let me think. If we don't do the "test ecx,$8000", then DSP4Read16b will call DSP4GetByte. DSP4GetByte would return the SR = 0x80 instead of WRAM. I could easily be wrong though as I'm not technically inclined.

I mean should this test be done instead of the test for 8000 in DSP4Read16b and DSP4Write16b, and then remove the test from DSP4Get/SetByte?

[Nach]

And about this test:

Code: Select all

if ((dsp4_address & 0xf000) == 0x6000 || (dsp4_address >= 0x8000 && dsp4_address < 0xc000))

Where did this come from?

I'm thinking more along the lines of:

Code: Select all

if (((dsp4_address & 0xf000) == 0x6000) || ((dsp4_address & 0xc000) == 0x8000))

[Nach]

Okay current code in CVS has a few more FPS eeked out of it.

I've also just had an idea to use setjmp()/longjmp() instead of this dsp4_logic goto stuff, although I'm not sure if that would work...

[Nach]

I found a bug not occuring in race, I would like some info on it, ZST:
http://nsrt.edgeemu.com/tg3ksave.zip

[pagefault]

I found a bug not occuring in race, I would like some info on it, ZST:
http://nsrt.edgeemu.com/tg3ksave.zip

Looks like a offset mode change bug, try turning off offset mode to see if that fixes the bug.

[Nach]

Yeah it does
BTW, we have a similar bug in DKC3.

[pagefault]

Yeah it does
BTW, we have a similar bug in DKC3.

Ok I will fix that, but at least the flickering is gone now, the game is ready to be played.

[Nach]

Yep it's official. ZSNES currently is the best emulator for Top Gear 3000.

Even anomie's major rewrite of Snes9x which fixes tons of bugs doesn't play Top Gear 3000 as well as ZSNES does right now. But that will probably change as anomie irons out his new code.

Anyways, screenshots:

[Nach]

pagefault even fixed split screen mode:




Oh and I forgot to mention I'm getting full speed as long as I don't use HQ filtering

[crocomire]

FANTASTIC WORK!!!
It's an old dream play Top.Gear 3000 in ZSNES!
Thanks ZSNES Team!

[Joe Camacho]

FANTASTIC WORK!!!
It's an old dream play asparagus which sucks because it lacks a pavement on the jet engine (read docs please) in ZSNES!
Thanks ZSNES Team!

Oh, how would I miss this... So long word filter "Top Gear 3000" ...
/jk

Great work guys!

[Nach]

Nah, we'll leave in the filter in some form or another.

As taken from IRC:

<pagefault> ok code is backported
<pagefault> and I am no longer hitting trees
<pagefault> so as you can see my CPU core needs more work
<pagefault> this game sucks though Nach
<pagefault> it needs a gun on the hood
<Nach> yeah
<Nach> maybe we should steal some code from UOSNES to add a gun on the hood

[Agozer]

Hahahah... Yes, it really needs a gun on the hood.

[kieran_]

It looks like those Chase HQ games.

[adventure_of_link]

EDIT: Bah, forget this... I wasn't using the latest WIP -_-...

[FitzRoy]

Nah, we'll leave in the filter in some form or another.

As taken from IRC:

<pagefault> ok code is backported
<pagefault> and I am no longer hitting trees
<pagefault> so as you can see my CPU core needs more work
<pagefault> this game sucks though Nach
<pagefault> it needs a gun on the hood
<Nach> yeah
<Nach> maybe we should steal some code from UOSNES to add a gun on the hood

Ahahahhahaha

[snkcube]

Nice work devs.

[Noxious Ninja]

Great!

Thanks to Nach, pf, Dreamor_Nom, and whoever donated the code.