Home Page
Posted By: Kale The SNES WIP topic - 08/06/09 11:53 PM
Starting to think that maybe it's better to cover the SNES improvements here instead of my blog for better documentation if nobody mind, also it makes my life easier if I should find something or if somebody finds a bug that I might overlook...

Let's start with...

r5366 /src/mame/video/snes.c: SNES: Improved mode 5/6 gfxs when tile size = 16x16.

Desert Fighter & Bishoujo Janshi Suchiipai sets this, still many video bugs in both...

before:


after:

Posted By: Heretical_One Re: The SNES WIP topic - 08/07/09 06:20 AM
Actraiser: execution ratio between the 65816 and SPC700 favors the 65816 too much. Locks up. Note that the game is playable at 102% SPC700 speed (but still lacks sound).

There's a number of issues MESS currently has that contribute to this (system always runs at 6 master clocks/cycle, DRAM refresh period is likely not emulated, etc), and I am only posting this "so there is a record of it".

Edit 1: Full Throttle Racing doesn't start (which prevents me from seeing whether it's as messed up as it was in mainstream SNES emulators)

Edit 2: Strike Gunner (U). The sides scroll in MESS. They shouldn't (bsnes/snes9x show correct behavior in this case)

Edit 3: Umihara Kawase (j): Obvious. As I recall, the game does something demented with IRQs.

4: Final Fantasy: Mystic Quest has two obvious errors. FIrst, Player damage should descend in front of the player, not behind (the text is sprite-based). Second, when dialogue is shown, there is a line where the background is visible through the box. Shouldn't be there).

(In case you're wondering, I've got a list of games that have caused emulators of yore some headaches and I'm testing those)

5: Daffy Duck: The Marvin Missions will induce seizures by having one (Some kind of IRQ register functionality issue, supposedly). Note that Seiken Densetsu 3 is picky about IRQ operation as well, and should be regression tested when Daffy is fixed.

6: Last one for tonight, Moryo Senki Madara 2 has gaps in the middle of the text. All of the pixels are there, but there is a blank line or two in the middle of ALL of the text. Also, combat is seriously weird looking (probably some sort of hi-res thing?)
Posted By: Kale Re: The SNES WIP topic - 08/07/09 10:14 AM
The line in Umiwara Kawase is a common bug, almost certainly a rowscroll bug caused by the weird 225 vertical behaviour. Other games that I've seen that in places:
* Bishoujo Janshi SuchiiePai (title screen)
* Dead Dance / Tuff E Nuff (options screen, gameplay on the round bar)
* Return of Double Dragon / Super Double Dragon (level 1 elevator)
* Super Castlevania IV (just before the level 1 castle door)

Full Throttle instead is another game with fussy hirq timings anyway...
Posted By: Heretical_One Re: The SNES WIP topic - 08/07/09 10:28 AM
Can't say for sure one way or another without a detailed check, but the game is notorious for the IRQ being set strangely, and it makes the water display funny. While I always saw it as taking up most of the screen visually, and flickering on and off, I can't say that MESS might not display it as a single line. And that's what has me rather unsure here: the scanline is very obviously the top of the water.

As far as the 224/225 thing goes, I'm pretty sure it works like this (but it's been ages since I looked at anything SNES):
0 - sprites are processed for line 1, nothing is drawn, but this is still the origin of the tilemap.
1 - BG drawn, sprites drawn. (note that BGs are now on the second line of the tilemap, so a y-scroll of -1 is allegedly common)
224/240 - last rendered line, 240 is sometimes shorter than other scanlines.

(but that's also pre-bsnes info, so YMMV smile )
Posted By: etabeta78 Re: The SNES WIP topic - 08/07/09 10:47 AM
just to add a couple of other known problems:

* Go Go Ackman 2 gets stuck at title screen
* Super Mario All Starts has weird scrolling glitches (not only on the top line)

since I still cannot follow 100% the way MESS emulates SNES, in the weekend I was planning to move a few more bits into the snes_ppu struct (reducing direct accesses of video/snes.c routines to snes_ram)

it should not affect speed and I could spot more easily if any register is still doing something different compared to what Anomie's docs & Byuu's source document as correct
Posted By: Kale Re: The SNES WIP topic - 08/07/09 12:55 PM
Changing the refresh scanline with a +1...

VIDEO_UPDATE( snes )
{
int y;

for (y = cliprect->min_y; y <= cliprect->max_y; y++)
snes_refresh_scanline(screen->machine, bitmap, y+1);
return 0;
}


...fixes all the line bugs except for one in Umiwara Kawa Se, but I guess that's another issue...what do you think? Hackish maybe?

Originally Posted By etabeta78

it should not affect speed *cut*


Guess that you don't know that your changes have hitted a noticeable speed drop, no? (try Dead Dance on plain 0.133 and now and let me know...)
Posted By: etabeta78 Re: The SNES WIP topic - 08/07/09 01:07 PM
two remarks on the "speed drop":

1. I was referring to future changes, which should not affect current speed
2. I still get ~380-450% speed unthrottled in Dead Dance... is it that bad? moreover, I can see no difference with svn 5355 :-P
Posted By: Kale Re: The SNES WIP topic - 08/07/09 01:18 PM
I mean in gameplay, unless it's a bug of my compile enviroment it was 280% and now it's 220%...
Posted By: etabeta78 Re: The SNES WIP topic - 08/07/09 01:43 PM
Here it seems really as fast as 0.130 (I don't have 0.133 handy)

However, I found out that Nintendo logo in DKC only get screwed if you fast forward. Otherwise it is ok...

Tonight I might try to implement offset per tile... it is well explained in Anomie's doc and it seems I only need to understand exactly at which step of MESS (x,y) calculation I have to add the h/v offsets wink
Posted By: R. Belmont Re: The SNES WIP topic - 08/07/09 01:46 PM
Cool.

BTW, one minor thing I know we do wrong - Anomie and byuu determined the actual bit-accurate-to-the-hardware Mode 7 math about 2 years ago and bsnes uses it now but we're still using an older approximation. It's only really noticable in some demo that uses mode 7 + extreme mosaic or something, but it's nice to know we're perfect smile
Posted By: etabeta78 Re: The SNES WIP topic - 08/07/09 02:01 PM
could you name exactly the demo(s) you refer to? having test cases saves a lot of time wink
Posted By: Heretical_One Re: The SNES WIP topic - 08/07/09 02:08 PM
Super Chase HQ indicates we're allowing too many bits of precision somewhere in the Mode 7 code.

MESS SVN is about 15% faster than bsnes for me.

the +1 is only hackish in that a proper fix is probably to special case line 0 to update the y value and "process sprites".

Got my money for the next 2 weeks. Now I need my sleep smile
Posted By: Kale Re: The SNES WIP topic - 08/07/09 02:46 PM
r5370 /src/mame/video/snes.c: SNES: Fixed rowscroll line bug in many games

before (Dead Dance (J)):




after:






Oh, the PAL SNES doesn't catch that it must run at 240 vertical resolution...

Quote:

the +1 is only hackish in that a proper fix is probably to special case line 0 to update the y value and "process sprites".


Ah, ok, so it's not THAT hackish then, just inaccurate smile
Posted By: Kale Re: The SNES WIP topic - 08/07/09 03:15 PM
Ah, as a chain reaction the above bug have fixed another weird bug with color windows, examples:

Before:




After:




I love when this happens wink
Posted By: etabeta78 Re: The SNES WIP topic - 08/07/09 06:09 PM
I have a suspect about the mode 7 bits... thanks for the test case.

after dinner, if I don't fall asleep (I just traveled by car for around 3 hrs with around 30°C temperature and no air cooling frown ), I should be able to code a bit and test if I'm correct

stay tuned
Posted By: R. Belmont Re: The SNES WIP topic - 08/07/09 06:45 PM
Nice, and good luck eta smile
Posted By: Kale Re: The SNES WIP topic - 08/07/09 07:32 PM
Dokyusei 2 does a weird thing: during gameplay it swaps between bg modes 1 and 5, presumably for doubling the resolution of the background until a certain line...That explain why it writes both normal and wide sprites versions at the same time too.
Posted By: Just Desserts Re: The SNES WIP topic - 08/07/09 07:40 PM
Kale, can you investigate the problem that MESS has with Puzzle Bobble / Bust-A-Move, where every other time the bubbles are pushed downward, the sprite positions become desynced from the background layers? I recall that either SNES9x or ZSNES had the same issue until only the past 5-6 years or so.
Posted By: R. Belmont Re: The SNES WIP topic - 08/07/09 07:42 PM
Mode 1/7 splits are fairly common, especially in sports games. Never heard of a 1/5 before smile
Posted By: RColtrane Re: The SNES WIP topic - 08/07/09 08:04 PM
Super Kick Boxing (J) has severe background graphic glitches, but it's fully playable. Any clues on how to fix that??

I would post some pics here, but I can't find a good free webhosting that allow brazilian IP's... frown

Keep with the amazing work! smile
Posted By: etabeta78 Re: The SNES WIP topic - 08/07/09 08:10 PM
it's probably the same problem as Super Ghouls and Ghost


EDIT: my first guess about Mode 7 was wrong. however, I'll see tomorrow if I can update MESS to use newer findings by Anomie. Good night.
Posted By: Kale Re: The SNES WIP topic - 08/07/09 11:38 PM
It is the same problem of Super Ghouls 'n Ghosts, a.k.a. wrong HIRQ timing that doesn't enable the HDMA in time.
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 06:36 AM
Umihara: fixed.

Mystic Quest: lines fixed. Text still wrong (in battle, damage to player is incorrect)

Madara 2: the break in the text isn't gone, just "so low it shows up much less"

Strike Gunner: additional bug when the first boss flies past you. The shadow looks "just plain awful", and it definitely shouldn't.

The Flintstones - Treasure of the Sierra Madrock shows a sprite glitch in the attract sequence. (also demonstrates two other MESS issues: it doesn't start identically in fast forward mode, and if it locks up because of fast forward, a reset will not fix it!)

Super Bases Loaded 2 does not start (226 partial updates??)

Ys 3 also suffers from Mode 7 having too many bits of precision in the formula.

Super Robot Wars EX locks up in combat. Snes9x had this issue and it amounts to "improper TIMEUP emulation"

Top Gear 2 cannot get in game, which makes me depressed. (However, the music works!)

EDIT: ok, I can't follow the draw code at all, but is Mode 4 even using offset-per-tile? If you use the standard variation used by 2 and 6, it won't work (can only scroll in one direction per tile in Mode 4), but that would "definitely" break Puzzle Bobble.
Posted By: etabeta78 Re: The SNES WIP topic - 08/08/09 06:51 AM
you asked for it, you got it: Mode 7 correct math implemented




more comparison shots here: http://mamedev.emulab.it/etabeta/?p=102

I'd like to review a bit more the whole mode 7 routines, and then I'll commit the fix wink


EDIT: there is no offset-per-tile implementation so far... I'm looking into it, but it could take some time.
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 07:00 AM
Then Puzzle Bobble is screwed for cause.
Let me see if my screen-at-a-time renderer has an exact implementation.

The one quirk I can point out for sure is that it's not instantaneous, so the first opt offsets apply to the SECOND tile of the line. The reason is that the tilemap fetches are understood to occur consecutively during caching, allowing too little time for the offsets to be applied.

anyway, Mode 4 is a single 16-bit value. $8000 is the H/V flag (believe set is V). (aside from Mode 7, all PPU accesses are 16-bit, if that helps).

And sweet work to Kale and etabeta78. You guys are making a couple hours spent reviewing old emulator change logs looking for familiar bugs a very worthwhile undertaking!
Posted By: etabeta78 Re: The SNES WIP topic - 08/08/09 07:14 AM
thanks for info. they coincide with both anomie's docs and byuu's code.

the main problem is to exactly understand exactly how offsets are used to determine tiles in MESS (last night I was not able to get the logic behind them, but I was really tired... I hope I overlooked something obvious)
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 07:23 AM
It alters where you fetch the (BG1?) tilemap data from. Essentially, it's added like a scroll value, iirc.

Unfortunately, my sources aren't complete enough to just glance at and tell exactly what I expect (and it has seriously shoddy interrupt logic because I can't find byuu's definitive interrupt specifications)
Posted By: Kale Re: The SNES WIP topic - 08/08/09 01:28 PM
F1 Roc 2 - Race of Champions doesn't allow the player to write to the nvram (?)
F1 Grand Prix Part 3 has heavy video artifacts on the course presentation screens, it is bugged on zsnes and snes9x too, my guess is that it does a pretty fancy thing with color window effects and the h/v beam positions.
(Gameplay is broken too, but I guess that etabeta fixes will fix that?)
Posted By: etabeta78 Re: The SNES WIP topic - 08/08/09 04:24 PM
how annoying is mode 7 precision... we gained the road on the title screen of SCHQ and we lost the red car in the "game start" screen...

I'm trying to find which exact bit caused the regression. if I cannot find it soon, I will commit the changes as they are and we will investigate the disappeared car later frown

EDIT: added changes to svn. next thing I'll try: MOSAIC (at least for Mode 7 wink )

EDIT2: it seems that I actually screwed out Super Chase HQ (ingame road is broken). later tonight I'll go back to fix it. sorry for the inconvenience....
Posted By: Kale Re: The SNES WIP topic - 08/08/09 05:59 PM
Road gfxs are also still broken in F-1 Grand Prix Part 3...

Anyway...

r5374 /src/mame/machine/snes.c: SNES: Make the unsupported reads on i/o open bus, fixes (at least) a layer enable in Super Kick Boxing







Technical explaination: uses mode 2, one layer and sprites only and it reads from the TM (bg enable) register. Since it's actually an open bus register that isn't very good for business.
Posted By: R. Belmont Re: The SNES WIP topic - 08/08/09 06:05 PM
Nice work! I never would have guessed open bus from the previous scrambly screenshots of that game.
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 07:09 PM
Open Bus is omnipresent in the SNES. As I recall, anomie killed a huge number of game-specific hacks after adding it to snes9x.

I'll give Kale and eta some time to pummel the driver before I go bug hunting again (unless I attack from the source side)
Posted By: Kale Re: The SNES WIP topic - 08/08/09 07:21 PM
You can do bug hunting at any time, more things are broken more willingness I have for fixing them. wink
Posted By: Justin Re: The SNES WIP topic - 08/08/09 07:47 PM
This demo starts off cool, but then dies horribly.
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 07:56 PM
In that case...

Super Battleship has "serious" gfx issues. (Playable, though).
Aside from bsnes, not much DOESN'T have issues.

Super Bomberman - Panic Bomber W doesn't boot. I suspect I can offer a fix in a while (because I think I know exactly what's causing it)
Posted By: R. Belmont Re: The SNES WIP topic - 08/08/09 07:59 PM
Mortal Kombat 2 also has SPC/65816 timing issues, incidentally. 1 and 3 are fine oddly smile
Posted By: Kale Re: The SNES WIP topic - 08/08/09 08:09 PM
Originally Posted By Heretical_One

Super Bomberman - Panic Bomber W doesn't boot. I suspect I can offer a fix in a while (because I think I know exactly what's causing it)


Boots in my SVN wink Likely that was an open bus issue too...

Posted By: Just Desserts Re: The SNES WIP topic - 08/08/09 08:14 PM
How about the audio in the Clay Fighter intro? wink
Posted By: R. Belmont Re: The SNES WIP topic - 08/08/09 08:17 PM
Since Justin showed that demo, I checked the game it goes with (Madden '96) and there's two issues: one of the words in the EA Sports splash is gibberish and the yellow highlight on some of the menus is off by 1 pixel. (Both are fine on bsnes, of course).
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 08:22 PM
still doesn't boot here, and I just updated my dev tree. Either we're looking at different games, or different code smile

I really should stop playing here and start trying to figure out how I'm going to handle my own MESS-related projects. wink
Posted By: ht1848 Re: The SNES WIP topic - 08/08/09 08:22 PM
Here is the previously submitted bugs for SNES... Bugzilla SNES

Based on this thread there are clearly more and I don't see the most important bug ever (super mario kart!!! wink )

thanks to everyone who is looking at SNES
Posted By: etabeta78 Re: The SNES WIP topic - 08/08/09 08:26 PM
btw, mode 7 should be back to correct working state now.

I should better check which test changes are in the patch and which are not, before the commit... wink
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 08:26 PM
Clay Fighter requires "really freaking good" timing. As a single project, not something managable. As a long-term goal, broken down into a lot of small steps... MESS would benefit quite a bit from the on-going work before there's an ounce of improvement in Clay Fighters.
Posted By: ht1848 Re: The SNES WIP topic - 08/08/09 08:28 PM
Bug #1638 seems fixed as of svn 5734. I'll mark it fixed.

Thanks Kale.
Posted By: R. Belmont Re: The SNES WIP topic - 08/08/09 08:29 PM
H_O: He knows, he's being funny.
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 08:30 PM
The one time I don't automatically assume he's being sarcastic...
Posted By: R. Belmont Re: The SNES WIP topic - 08/08/09 08:32 PM
He and I both know the guy who programmed that audio driver. The author considers it an ongoing source of lulz that even bsnes sometimes glitches that audio but it's always perfect on real h/w.
Posted By: etabeta78 Re: The SNES WIP topic - 08/08/09 08:35 PM
just for the record, I confirm that Panic Bomber W is not working in current svn... it sits at a black screen at start
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 08:44 PM
Oh, that's one seriously SICK sound driver. Simple HDMA spooling is enough to give most emulators problems, and it doesn't even stop there smile

I'm not sure whether it's more impressive than Star Ocean's virtual sound channels, but it is decidedly more reliable smile
Posted By: R. Belmont Re: The SNES WIP topic - 08/08/09 08:47 PM
The same programmer came up with running code out of the DMA registers so you could decompress at 3.58 MHz on a slower ROM cart, which gave earlier emulators serious fits smile
Posted By: Heretical_One Re: The SNES WIP topic - 08/08/09 08:53 PM
have to be fairly small code, and there's a few oddities about... xxxB and xxxF addresses, I recall...

but horribly abusive of the RAM-like nature of that region. I like it.

Now if only you knew who designed the Capcom copy protection on Megaman X, because he's my personal hero. smile
Posted By: Stiletto Re: The SNES WIP topic - 08/08/09 11:44 PM
Originally Posted By R. Belmont
He and I both know the guy who programmed that audio driver. The author considers it an ongoing source of lulz that even bsnes sometimes glitches that audio but it's always perfect on real h/w.


You clowns are killing me over here... laugh
Posted By: Kale Re: The SNES WIP topic - 08/09/09 12:14 AM
Originally Posted By etabeta78
just for the record, I confirm that Panic Bomber W is not working in current svn... it sits at a black screen at start


Ah, the exact title is "Super Bomberman Panic Bomber World" then, not Super Bomberman only...it hangs because the audio cpu fails (i.e. doesn't load a proper program for the sound cpu), a fairly common bug actually...
Posted By: Heretical_One Re: The SNES WIP topic - 08/09/09 01:27 AM
Depending on how it fails, some games seem to want the SPC700's RAM to be initialized on power-up.

While a couple variations have been observed, they all do essentially the same thing: alternating blocks of 0/FF.

The games seem to keep going until they hit the other block.

Common SNES emulator practice is to flood-fill RAM with bit 5 of the address (but this doesn't fix Panic Bomber World. Already tried it). I believe Overload (of DSP-* fame) discovered that pattern.
Posted By: RColtrane Re: The SNES WIP topic - 08/09/09 02:53 AM
With the latest SVN build from Bobz (up to 5371), Rushing Beat(J) shows only a black screen. Maybe it's something related to that sound issue mentioned here before.
Posted By: R. Belmont Re: The SNES WIP topic - 08/09/09 02:54 AM
RC: did it work before? Please specify if reported bugs are regressions or new smile
Posted By: etabeta78 Re: The SNES WIP topic - 08/09/09 05:36 AM
for the record, no it has never worked (or at least, it was already broken around 0.133)
Posted By: Anna Wu Re: The SNES WIP topic - 08/09/09 07:48 AM
SVN r5380+
SNES
The start intro in ActRaiser seems to be ok, now.
Posted By: Kale Re: The SNES WIP topic - 08/09/09 11:15 AM
F-1 Grand Prix Part 3 mode 7 effect are still way off (rotation seems to work inverted)
Posted By: etabeta78 Re: The SNES WIP topic - 08/09/09 11:41 AM
I know, but we are using the correct math (for what I can see)

I'm going to investigate the related registers, next. we're definitely doing something wrong, but I don't know where (yet)
Posted By: Tafoid Re: The SNES WIP topic - 08/09/09 12:54 PM
Originally Posted By Anna Wu
SVN r5380+
SNES
The start intro in ActRaiser seems to be ok, now.


Which region?

The Japanese rom will get you music and a title screen and even allow you to start and play.
The US version shows the title fine, but no music. Then, when you press start, you get a black screen.
Posted By: Anna Wu Re: The SNES WIP topic - 08/09/09 01:11 PM
Originally Posted By Tafoid
Originally Posted By Anna Wu
SVN r5380+
SNES
The start intro in ActRaiser seems to be ok, now.


Which region?

The Japanese rom will get you music and a title screen and even allow you to start and play.
The US version shows the title fine, but no music. Then, when you press start, you get a black screen.


Sorry, for the missing details.
I was talking about graphics in start intro only, tested on (J) version. Because before it was looking funny.
And yes, for (U) and (E) versions, the music is missing.
Posted By: etabeta78 Re: The SNES WIP topic - 08/09/09 01:42 PM
Found a bug in the Mode 7 registers. Later, I'll test if fixing this bug allows for improvements in F-1 GP 3 and in Super Chase HQ start screen...
Posted By: RColtrane Re: The SNES WIP topic - 08/09/09 03:10 PM
Originally Posted By R. Belmont
RC: did it work before? Please specify if reported bugs are regressions or new smile


Sorry about the lack of information. With version 0.128, Rushing Beat shows the Jaleco intro screen and after that if goes to the black screen and nothing else happens. With the current SVN version, it doesn't even show the Jaleco title screen.
Posted By: etabeta78 Re: The SNES WIP topic - 08/09/09 03:37 PM
while neither Super Chase H.Q. nor the circuit preview in F-1 GP 3 do benefit from my change, it is nice to see that sharing registers as per Anomie's research fixes the in-game graphics in F-1 GP 3. the game is now playable!


(notice I reached the end of the first lap, something not possible in current svn)


As a drawback, few glitches has appeared in Super Chase H.Q. in-game road, but for sure emulation is more accurate now than it was.

Now I'm cleaning up a bit the code and then I commit the fix. I also noticed that STA77/STAT78 support seems incomplete and I will investigate it afterwards
Posted By: etabeta78 Re: The SNES WIP topic - 08/09/09 05:01 PM
Mode 7 improvements are in svn.

@Kale: your open bus work has broken both Super Double Dragon and SNES Test Program (they both woks if I return 0xff for unsupported reads)... could you take a look?
Posted By: Kale Re: The SNES WIP topic - 08/09/09 06:20 PM
It reads from 0x2555/0x2556, that aren't actually known registers (???).
What's supposed to do if it reads from invalid stuff?
Posted By: RColtrane Re: The SNES WIP topic - 08/09/09 06:27 PM
Hey RB, I think you can scratch out some items from your Wiki list:

•Add Nintendo varient that runs in terms of SNES master cycles for better accuracy
•Rewrite SNES renderer from scratch for better accuracy, including modern discoveries

smile
Posted By: R. Belmont Re: The SNES WIP topic - 08/09/09 07:15 PM
The first one's still very necessary. The second, less so now.
Posted By: Kale Re: The SNES WIP topic - 08/09/09 07:48 PM
028FC6: AD 55 25 LDA $2555
028FC9: CD 56 25 CMP $2556
028FCC: D0 F8 BNE 028fc6 (-$8)
028FCE: CA DEX
028FCF: 10 F5 BPL 028fc6 (-$b)


Fixed the open bus behaviour, but I wonder about the morality of reading undefined/invalid registers for (supposedly) delaying the program flow execution...
Posted By: R. Belmont Re: The SNES WIP topic - 08/09/09 08:41 PM
Probably a typo in the source. MAME's debugger is many times more powerful than what was available to actual developers at that time.
Posted By: etabeta78 Re: The SNES WIP topic - 08/09/09 09:14 PM
wow! now also the stars pattern in SNES Test Cart looks ok! great work Kale!
Posted By: Kale Re: The SNES WIP topic - 08/09/09 09:22 PM
r5388 /src/mame/video/snes.c: [SNES]: Fixed vram size when in hires mode

Desert Fighter


r5389 /src/mame/machine/snes.c: [SNES]: hooked up interlace mode



Syvalion


Bishoujo Janshi SuchiePai



(I know, sprites should be doubled in y-axis when in interlace mode...)

EDIT: and be careful about Syvalion sound, doesn't work and gives a (rather annoying) whistle...
Posted By: Heretical_One Re: The SNES WIP topic - 08/09/09 11:26 PM
Bug: Super Chase HQ menu. Background is all red, should be blue.

Mega Man X, with its fiendish copy protection? works! (at least the 1.0 version)

RPM Racing: Interplay logo is wrong.

Tokimeki Memorial: menus are bad screwed. (missing text)

Energy Breaker: world map is missing entirely.

Madara 2: menu is actually functional, but horribly misaligned (cursor/text it represents). Most likely a remaining hires sprite issue, because the cursor is confines to the left side of the screen.

Edit: just updated to 5390, and Madara 2 freaked out. Clean build fixes it. I suggest SVN users clean build before reporting bugs.
Posted By: Kale Re: The SNES WIP topic - 08/10/09 12:05 AM
Originally Posted By Heretical_One

RPM Racing: Interplay logo is wrong.


Another doubled y-axis issue due of interlace mode (check the system info, if it says 4** as vertical resolution then it's into that mode).

Posted By: Heretical_One Re: The SNES WIP topic - 08/10/09 12:19 AM
Well, you guys are kicking butt here, so I had to mention it. I don't expect it to be a valid bug for long, with the way you and etabeta78 are ripping through some of the fundamentals of rendering and register accesses.

I'm having no luck on my NES projects, so I'll see if I can't find any obvious ways to help out here smile

Edit 1: Probably the single biggest "quick fix" for timing being very off is that DMA takes 0 cycles. while the proper figure is (length+1) for the transfer itself, there is some overhead (I can't find byuu's *DMA data any better than I can keep up with his IRQ timing data to give exact figures)
Posted By: R. Belmont Re: The SNES WIP topic - 08/10/09 12:44 AM
Charles MacDonald's interlace demo from bug 786 works now too except for the (non) doubled sprites.

1843 and 1847 are likely both offset-per-tile mode even if I'm not clear wtf a "DYCP scroller" is smile
Posted By: Justin Re: The SNES WIP topic - 08/10/09 05:10 AM
I thought you were the demoscene fanboy smile
Posted By: R. Belmont Re: The SNES WIP topic - 08/10/09 05:19 AM
Hey, I almost remember the purported storyline of Second Reality someone made up on USENET 15 years ago, but I've never heard that term smile
Posted By: etabeta78 Re: The SNES WIP topic - 08/10/09 09:58 AM
Originally Posted By Kale
Originally Posted By etabeta78

it should not affect speed *cut*


Guess that you don't know that your changes have hitted a noticeable speed drop, no? (try Dead Dance on plain 0.133 and now and let me know...)


most regs have been added to PPU struct now. Dead Dance has lost <2% compared to rev.5355 (but I admit that I still haven't compared to 0.133)

my next task is to understand why window masking uses opposite values for color (it should not)...
Posted By: R. Belmont Re: The SNES WIP topic - 08/10/09 10:23 AM
Given the improvements in both correctness and the readability of the code (having everything in the PPU struct helps a lot here) I'm not too concerned about performance.
Posted By: Heretical_One Re: The SNES WIP topic - 08/10/09 10:24 AM
"different Y Character position", according to Wikipedia smile

Translation? Arbee nails it. OPT modes smile
Posted By: Kale Re: The SNES WIP topic - 08/10/09 11:09 AM

r5395 /src/mame/ (machine/snes.c video/snes.c includes/snes.h): [SNES]: Fixed doubled y-axis sprites when in interlace mode






Another interlace bug is with Syvalion vertical scrolling masks when it shows the level intro text, it's like halved at 256 instead of 512...
Posted By: Heretical_One Re: The SNES WIP topic - 08/10/09 01:07 PM
Good work, Kale!

Looks like the main issue with hi-res remaining is some half-width outputs. I'm guessing this is when the screen is partially 512 and partially 256.
Posted By: Kale Re: The SNES WIP topic - 08/10/09 03:18 PM

r5398 /src/mame/video/snes.c: [SNES]: Improved window effects when in H-512 mode.


Super Moero Pro Yakyu


Doukyusei 2


(there was a vertical stripe of corruption in the middle and windows were cutted in half before)
Dunno about that remaining corruption tile in Super Moero Pro Yakyu, I bet 15 bucks that's another window bug...
Posted By: etabeta78 Re: The SNES WIP topic - 08/10/09 03:33 PM
very good improvement! I'm temporarily taking a break from color math because is quite hard to follow on docs and I'm a bit busy with Real Life business
Posted By: R. Belmont Re: The SNES WIP topic - 08/10/09 03:38 PM
Very nice. I'm glad to see all these improvements smile
Posted By: Kale Re: The SNES WIP topic - 08/10/09 03:50 PM
About the Act Raiser (u) / Go Go Ackman 2 / Ring ni Kakero / Secret of Mana / Syvalion (and still counting) sound bug...
Setting the main cpu clock at 80% (and the sound cpu at 160%) fixes both the hangs and the missing sounds...
Maybe I should start to consider the usage of cpu_eat_cycles when a ROM is read?

(forgot to say: Super Castlevania IV level 2 scrolling quirk and Lethal Weapon color bug are also caused by CPU timing stuff)
Posted By: R. Belmont Re: The SNES WIP topic - 08/10/09 03:56 PM
The correct fix is to have a separate S-CPU core that's clocked at SNES master (21.whatever) and have everything take the right amount of cycles from there. Anything else will just cause trouble later.
Posted By: AWJ Re: The SNES WIP topic - 08/10/09 04:42 PM
Seiken Densetsu 3 is the poster child for partially-512, partially-256 screens. It's not immediately obvious in the English translated version because of the font used, but any region of the screen that has text on it is in hires, while the rest of the screen is, obviously, Mode 1.

I think Tokimeki Memorial might mix hires and "normal" resolution on the same screen too.
Posted By: Heretical_One Re: The SNES WIP topic - 08/10/09 10:52 PM
Tokimeki: it does just that.

timing: while emulating everything at the 6 master cycle level is definitely causing problems, you do also need to consider that DMA and HDMA are "free" in MESS (and 8 master cycles on hardware, plus somne overhead), and that we don't emulate DRAM refresh at all. (Don't ask me for an exact cycle count there. it's "40" master cycles, but is that decimal or hex? I forget!).

Adding any of that to the emulation would slow down the main CPU significantly. (DMA is a minimum 4% in most games as it rewrites the palette and OAM. More if it updates the tilemap or tile data!)

I'll be back in a while with an update on what I've found to be fixed.

Edit: early bug retesting:

Tokimeki - still broke as sin, and the performance indicates we're doing something terribly wrong somewhere. I'll try a release build later, just in case.

Madara 2 - menus are fixed. Text break-up is not. combat is still only half-screen. Definitely closing in on "pretty much perfect" hi-res smile

"new" bug report: Bishoujo Wrestler Retsuden has a background gradient that should take up the full screen. MESS currently has it half-screen. It's probably an old bug, but I hadn't tested this particular case until now.

Edit 3: ok, now Chase HQ's menu screen is GREEN??
Posted By: AWJ Re: The SNES WIP topic - 08/11/09 04:47 AM
I just remembered that Tokimeki Memorial is a 32Mbit LOROM, quite an unusual configuration. Are you mapping it correctly?
Posted By: Heretical_One Re: The SNES WIP topic - 08/11/09 06:08 AM
LoROM is a mess of conflicting boards. It's not even standardized enough to migrate a game from one board to another reliably.

For an "incorrect" Tokimeki mapping, find any of the many ZSNES versions that screw up in very funny ways when the code jumps into what is mapped as sram.
Posted By: etabeta78 Re: The SNES WIP topic - 08/11/09 06:13 AM
check error.log message and you'll see how is it recognized (I don't have a copy of the image right now to verify)

about Super Chase HQ: here the color of the start screen goes randomly from black to pink to green depending on the run

about Seiken Densetsu: I have tried it yesterday and it seemed working (with only dialogue windows of the wrong size). now, in-game, it shows a black screen only. but it could be another of these random behaviors, because I cannot find an older svn revision which works, atm

very weird behaviors wink

EDIT: ok. found an image. I'm quite sure we are mapping it correctly (code based on BSNES, if you check messnew.txt). I had thought that "broken as sin" would have meant something like Test Drive 2, but here Tokimeki Memorial shows most of the graphics and only menu entries are really broken... could the game make use of the still-MIA OPT feature?
Posted By: AWJ Re: The SNES WIP topic - 08/11/09 06:49 AM
IIRC, the main ingame screen in Tokimeki Memorial has the top and bottom parts of the screen in hires, with standard res sandwiched in between--not sure what actual modes are used. I doubt that it uses offset-per-tile, though.
Posted By: etabeta78 Re: The SNES WIP topic - 08/11/09 07:15 AM
ok. then it could be something else, hires related maybe. however, we currently display most of the graphics but the menus: of course, lack of menu means that even simply starting a game is a hard task frown

sooner or later we'll get it
Posted By: Heretical_One Re: The SNES WIP topic - 08/11/09 10:30 AM
Starting a game is easy. smile

Start. Start. Start. repeat until you pretty clearly aren't at a menu. Guess where either the top or bottom in-game choice is. If you happen to hit the one that say "give me the backstory, you'll see lots of pictures of high school freshman girls looking somewhat sad. If you don't, you go to a broken screen smile

Just... not as bad as ZSNES smile
Posted By: Kale Re: The SNES WIP topic - 08/11/09 12:00 PM
Tokimeki Memorial is just like Doukyusei 2 (even the same type of game, aka dating sims)...it swaps between mode 1 and 5, mode 1 gfxs gets doubled in x-axis if you swap into mode 5 (and I presume it's like this for available ROM space / performance purposes).
I don't know yet the real reason about the missing text in TM, the only sure thing is that is in "regular" mode 5 and it's theoretically drawn with bg2 / the 2bpp layer.
Posted By: RColtrane Re: The SNES WIP topic - 08/11/09 01:42 PM
Rushing Beat is still in the darkness frown
Posted By: etabeta78 Re: The SNES WIP topic - 08/11/09 02:06 PM
you already reported it. wait until it is announced as fixed. it's not as easy as snap your fingers wink
Posted By: Kale Re: The SNES WIP topic - 08/11/09 02:56 PM
Rushing Beat goes in the growing list of games that require a better master cycle emulation of the main/sound cpus, if you want to run it on MESS right now pause the emu just after the disclaimer, change the clocks to maincpu = 80% and soundcpu = 160% and unpause the emu...
Posted By: Shideravan Re: The SNES WIP topic - 08/11/09 04:08 PM
Waw!
The progress are being very fast!
Thank you guys!
Posted By: RColtrane Re: The SNES WIP topic - 08/11/09 04:35 PM
Originally Posted By Kale
Rushing Beat goes in the growing list of games that require a better master cycle emulation of the main/sound cpus, if you want to run it on MESS right now pause the emu just after the disclaimer, change the clocks to maincpu = 80% and soundcpu = 160% and unpause the emu...


It looks like black magic, but it WORKS!!! crazy

Thanks a lot Kale!

P.S. - sorry about the double post
Posted By: Kale Re: The SNES WIP topic - 08/11/09 05:18 PM

r5404 /src/mame/video/snes.c: [SNES]: Fixed the x scrolling wrap around bug when hscroll == 0


Symbolic snapshot (before it was corrupted on the right edge of the screen by just doing a couple of steps forward):


Actually anything that scrolls in horizontal benefits from this one, I've honestly got an headache from this one (tried to fix it since day one).
Posted By: etabeta78 Re: The SNES WIP topic - 08/11/09 05:22 PM
@Kale: when you added interlace mode, svn 5389, you broke the SNES Test Cart (check end of Mode 0 demo, at the beginning: the stars should become smaller, while now it is the rest of the screen to be squeezed)

could you take a look? I don't know if interlace should only affect hires modes or all Modes 0 -> 7 but this way it is broken...

tia
Posted By: Kale Re: The SNES WIP topic - 08/11/09 05:30 PM
It's a new bug, not that's broken, need to understand the interlace mode better (maybe non-hires + interlace == halved y axis?)...
Posted By: etabeta78 Re: The SNES WIP topic - 08/11/09 05:36 PM
Anomie says

Quote:
Screen interlace. When set in BG mode 5 (and probably 6), the
effective screen height will be 448 (or 478) pixles, rather than
224 (or 239). When set in any other mode, the screen will just get
a bit jumpy. However, toggling the tilemap each field would
simulate the increased screen height (much like pseudo-hires
simulares hires).


I read that as: in mode != 5, 6 we should not double the y coordinates.

otoh, the problem of the non-squeezing stars is probably due to missing object interlace (SETINI & 0x02) emulation. hence, no breakage on that side.

EDIT: maybe snes_dynamic_res_change shall be moved to the rendering step rather than called as soon as the bit is set...
Posted By: Kale Re: The SNES WIP topic - 08/11/09 05:55 PM
Anything but the VIDEO_UPDATE, please.
The best idea is to call a timer at hpos & vpos = 0,0 if the resolution changes, just like the MAME st-v driver currently does.

Meanwhile...any idea about why a bunch of japanese games (for example Captain Commando (J)) doesn't set the correct cart mode?
The USA version of CC is correctly setted as HiROM and code wise is very similar to CC Japan that for whatever reason is setted as LoROM...unsurprisingly bsnes crashes too with CC Japan...
Posted By: R. Belmont Re: The SNES WIP topic - 08/11/09 06:30 PM
The layer enables or something seem to be glitchy on stage 2 of Super Castlevania 4 - levels 1 and 3 are fine.

As far as false LoROMs the parameters in the header are never actually used by real hardware so they were sometimes deliberately set wrong to try and annoy copiers and stuff.
Posted By: Shideravan Re: The SNES WIP topic - 08/11/09 07:36 PM
Top Gear 2 don't runs anymore?
Posted By: Kale Re: The SNES WIP topic - 08/11/09 07:40 PM
Originally Posted By R. Belmont
The layer enables or something seem to be glitchy on stage 2 of Super Castlevania 4 - levels 1 and 3 are fine.


It's again the master clock timings (happens in Lethal Weapon and J.League Excite Stage '94 too), downclocking the maincpu fixes it...I do wonder if level 4 gfxs are fine actually...

Top Gear 2 has regressed somehow, appears to be the same issue as Shaq Fu (i.e. NOT the clock timings)
Posted By: Kale Re: The SNES WIP topic - 08/11/09 10:35 PM
Dunno what fixed this...



Posted By: etabeta78 Re: The SNES WIP topic - 08/11/09 10:54 PM
something between svn 5380 (broken) and 5388 (fixed)... my bet is between 5387 and 5388...

but the important thing is that it finally works smile

some glitches are still present in-game, I think (too tired to compare with BSNES wink )
Posted By: Kale Re: The SNES WIP topic - 08/11/09 11:04 PM
They are mixed mode 1/7 screens, so you fixed those. smile
Posted By: Kale Re: The SNES WIP topic - 08/12/09 01:02 AM
Ok, at this point let's do a recap:

*Bishoujo Janshi SuchiePai: Girls presentation made with mode 5 + interlace have still a graphic artifact. Then there's a blending bug with the VCR screen and the "dice sprite screen" just after the girl presentation has garbage on bg1, ALL the other emus have issues with this specific game, why?
*Bishoujo Wrestler Retsuden[/]: Halved back screen on the character selection screen, interlace issue;
*[i]Clay Fighter
: sound part is bugged;
*Daffy Duck: The Marvin Missions: scroll flicker that isn't caused by timings, heretical_one says hirq?
*Doukyusei 2 / Tokimeki Memorial / Donkey Kong Country: swaps between mode 1 and 5 during gameplay / Nintendo logo, needs doubled x-size pixels
*Energy Breaker: heavy broken blending effects, also world map is entirely missing (untested);
*F-1 Grand Prix Part 3 / Desert Fighter (J): heavy flicker during (ironically) the briefing for both games, probably abuses the gfx mode changes and the window / blending capabilities (at least mode 7 + something else)
*F1 Roc 2 - Race of Champions / Hayazashi Nidan: Morita Shougi: missing MCU emulation, the racing game uses a Seta ST-010, the shogi one ST-018 chip, according to dox pinout is V810/V850 compatible, needs to be bought and decapped.
*Final Fantasy - Mystic Quest: priority bug when the player is damaged;
*Moryo Senki Madara 2: gap in the text? vshift bug maybe?
*Puzzle Bobble / Bust-A-Move: Sprites goes offset after some time in challenge mode.
*Seiken Densetsu 3: Text boxes needs to be halved, switches between gfx modes 5/1, also there are corrupted gfxs on the text boxes
*Super Battleship: horizontal stripes all over the screen, vshift issue maybe?
*Super Chase HQ: Menu background is all red, should be blue (fixed?).
*Super Ghouls and Ghosts: Erratic HDMA enable / disable causes heavy gfx corruption, PLUS status bar got deleted if the HDMA is enabled thru kludges, likely to be a renderer bug. Also level 2 has submerged sprites for whatever reason -> http://mamedev.emulab.it/kale/fast/files/0095_1356982083.png
Super Moero Pro Yakyu: a bug with windows causes corrupted tiles during gameplay.
*Strike Gunner / Power Athlete (J): missing mode 2 offset-per-tile
*Strike Gunner there's a "bug when the first boss flies past you" (untested)
*Super Mario All-Stars: (fixed with latest svn commit r5405)
*Super Kick Boxing (J): (fixed)
*The Flintstones - The Treasure of Sierra Madrock (U): Sprite priority bug during attract mode? (Can't reproduce the fast forward bug...)
*Tokimeki Memorial: Missing text during gameplay?
*Umihara Kawase: cutted "hi" word tile, it was ok before without the y+1 fix;

Last but not least, the following games hangs or have issues here and there due of the clock timing issues:
Act Raiser (U)
Go Go Ackman 2
J-League Excite Stage '94
Lethal Weapon (colors during gameplay)
Mortal Kombat II
Power Athlete (J) (offset-per-tile PLUS scrolling flicker)
Rushing Beat (J)
Ring ni Kakero
Secret of Mana
Syvalion
Super Castlevania IV (level 2)
Super Valis IV


These instead doesn't start/locks up and apparently NOT related to the clock timing issues:

Captain Commando (J) (wrong cart mode selected)
Full Throttle Racing (POST)
Live-A-Live (wrong cart mode selected)
Shaq Fu (character screen)
Super Bases Loaded 2 (POST)
Super Bomberman Panic Bomber World (POST, doesn't load a proper sound cpu program)
Super Robot Taisen EX (combat screens, TIMEUP reg issue?)
Top Gear 2 (after choosing to start a new play)
Posted By: ht1848 Re: The SNES WIP topic - 08/12/09 01:09 AM
Excellent fixes...very exciting...

Super Mario Kart improved (yipee!!) not sure which fix did it, but the ground is now visible in game but has 2 behaviors that are not right...

4 pics

1. Driving works but there is some weird "walls" in the levels, even the computer controlled players bunch up. See picture.

2. If you quite while in game play and start again, the intro screen is shifted by a full screen to the left. If you exit any other (like while in select) time the intro is fine. see lower right screen shot, you can just see the edge of the background on left. something is bad from session to session.

Also since I was taking some snapshot I threw in there Super Offroad - The Baja. The gameplay roadway flashes, but the interesting bug is the panel flashes back and forth from being 1/4 screen off horizontally. took a screen shot of it in both positions, live it looks much crazier.
Posted By: Kale Re: The SNES WIP topic - 08/12/09 01:38 AM
DSP is more or less broken (more than less actually), Pilotwings for example is completely unplayable right now. frown
Super Offroad Baja instead switches between gfx modes 1 and 7.
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 01:49 AM
Gaah, DSP hookup used to be perfect back before the graphics worked smile
Posted By: ht1848 Re: The SNES WIP topic - 08/12/09 04:46 AM
Originally Posted By R. Belmont
Gaah, DSP hookup used to be perfect back before the graphics worked smile

yeah I see that now. I went back a few versions...and between release versions 122 and 123 something broke with the driving gameplay (DSP?). Something between Dec 30, '07 and Feb 9, '08.

.122 and before has fine gameplay but bad graphics..It is quite entertaining to use the rear view mirror (which has always shown the ground graphics) to get around the track.

There was what appears a significant re-write in SVN1479 but I didn't get a chance tonight to go figure out if it was that specific change (MAME122u3 I think) that caused the break. I didn't see anything else significant in the mess tree. I can do that tomorrow night if someone doesn't figure it out or speak up. Cheers!
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 04:48 AM
Wow, I thought it was correct more recently than that. LMK if it is 1479 that did it.
Posted By: etabeta78 Re: The SNES WIP topic - 08/12/09 06:06 AM
additional issues (just to keep record):

* Super Soccer has a black screen when you have to select a team (but you can see somehow through the black the flags)

* any game using special chips (but DSP1-DSP2-OBC1) does not work [1]

[1] I had a partial DSP3/DSP4 implementation but: 1. I need permission from Nach to use ZSNES code (I'm already in contact with him, and he's basically ok... we just need to sort out details), 2. I haven't pushed too much for the permission because DSP3 is still buggy & Top Gear 3000 (DSP4) suffers of the same bug of Top Gear 2... However, both chips will come at a point...
Posted By: Anna Wu Re: The SNES WIP topic - 08/12/09 07:15 AM
Quote:
* any game using special chips (but DSP1-DSP2-OBC1) does not work [1]


Also for Super-FX/FX2, right ?
Posted By: etabeta78 Re: The SNES WIP topic - 08/12/09 07:42 AM
of course. they are special chips and they are not DSP1-DSP2-OBC1 (which are the only 3 supported)
Posted By: Kale Re: The SNES WIP topic - 08/12/09 09:06 AM
Originally Posted By etabeta78

* Super Soccer has a black screen when you have to select a team (but you can see somehow through the black the flags)


Really no idea about it (open bus?) but that screen is actually completely black since that the fade register is 0 (and we currently use a +1 hack).
Posted By: Kale Re: The SNES WIP topic - 08/12/09 09:17 AM

r5406 /src/mame/machine/snes.c: [SNES]: fixed irq ack and fixed TIMEUP register open bus behaviour.


...means that Super Robot Taisen EX doesn't hang anymore.




r5407 /src/mame/machine/snes.c: [SNES]: Even more aggressive open bus fixes.








"Outstanding!" (cit.)

(also Full Throttle Racing shows the CyberSoft logo but hangs after it)
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 01:15 PM
Outstanding indeed smile
Posted By: Kale Re: The SNES WIP topic - 08/12/09 04:52 PM
Energy Breaker blending bug is caused by a missing HDMA. Game doesn't even attempt to enable the H-blank IRQ, and yes, the cause is pretty much a perversion smirk

MESS vs. Snes9x




And speaking about perversions...

r5409 /src/mame/machine/snes.c: [SNES]: Fixed a partial update bug when the screen is in interlace mode






(now I wonder about why the girls are decentered,ideas?)
Posted By: Shideravan Re: The SNES WIP topic - 08/12/09 08:55 PM
Great!

Well, the lasts svn has some weird graphics regressions:

Donkey Kong country 3 (u)-After you found Krematoa, water becames weird


Animaniacs (u) - Title screen corrupted


Donkey Kong country (u) - nintendo logo display unaccurate


Toy story (u) - Background issue at first level


And, thanks Kale, for the quick fixes!
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 09:00 PM
Kale: they're centered in bsnes? Because in actual photography you're supposed to put the subject off center like that, not that pre-PS2 programmers tended to know that smile
Posted By: etabeta78 Re: The SNES WIP topic - 08/12/09 09:06 PM
@Shideravan: are those really regressions? and when they were working correctly?

Nintendo logo in DKC has been like that since many days...
Posted By: Kale Re: The SNES WIP topic - 08/12/09 09:21 PM
Originally Posted By R. Belmont
Kale: they're centered in bsnes? Because in actual photography you're supposed to put the subject off center like that, not that pre-PS2 programmers tended to know that smile


Yes, centered. Dunno if I should trust the other emus about it...
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 10:40 PM
Well, in general if bsnes does something it's probably right smile
Posted By: Kale Re: The SNES WIP topic - 08/12/09 10:48 PM
bsnes has heavy sprite flickering bugs in random places, it's probably one of the few games that it's better (!) in our MESS driver.
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 10:56 PM
Actually the real SNES has heavy sprite flicker in a lot of games (Gradius III was worst, but nowhere near the only one). AFAIK his sprite flicker is correct. (Sega got this right: the lowest-priority sprite drops out first on the Genesis. On the SNES the highest-priority drops first so it's more likely to look really bad).
Posted By: Kale Re: The SNES WIP topic - 08/12/09 11:08 PM
Oh well, we need a mess vs. bsnes snap comparison before continuing talking all the day about it ;P





(imho it could flicker, but not that much)

MESS has another bug...during bonus games (after that you win a match), you cannot see the sprite that controls the selections that you do, yay...
Posted By: R. Belmont Re: The SNES WIP topic - 08/12/09 11:16 PM
Ok, yeah, that's a bug smile
Posted By: Kale Re: The SNES WIP topic - 08/12/09 11:39 PM

r5416 /src/mame/ (machine/snes.c video/snes.c): [SNES]: Fixed 8bpp layer colors.






(Unrelated note: Always wondered if the latter says "Chief!" on the title screen or what... ^^U)
Posted By: ht1848 Re: The SNES WIP topic - 08/13/09 02:26 AM
Originally Posted By R. Belmont
Wow, I thought it was correct more recently than that. LMK if it is 1479 that did it.


Yep confirmed. super mario kart gameplay broke in 1479. 1478 is fine (except graphics of course, which are now fixed in current svn).

should I file a bug since this was a regression and not related to the current snes party going on now?
Posted By: R. Belmont Re: The SNES WIP topic - 08/13/09 02:28 AM
No, it's part of the party now.
Posted By: Heretical_One Re: The SNES WIP topic - 08/13/09 02:43 AM
Super Chase HQ: background color appears fixed now.

Bishoujo Wrester Retsuden is fixed.

Strike Gunner: I can confirm. The shadow of the first boss comes out as a series of corrupted forest tiles, rather than a shadow. Possibly OPT?

Top Gear 2: New bug - bridges are solid yellow, should be yellow and black. Snes9x had the reverse problem (any line that had black in it was all black). Possibly same cause? (H-IRQ)

Posted By: etabeta78 Re: The SNES WIP topic - 08/13/09 06:05 AM
I would have bet there is need of a shift in 8bpp palette, but since this fixes more than the opposite I had probably made something wrong...
Posted By: Heretical_One Re: The SNES WIP topic - 08/13/09 06:33 AM
I wouldn't think so. palette RAM is 512 bytes, at 15 bits per entry.

As far as stuff broken on 8bpp, though, the palette bits in the tilemap do have a use. you can turn the palette selection and palette-ized color into a direct color mode. If I knew what was broken, I could cross-reference with some of my "known places that use this feature" lists and see. (Actraiser II for Direct Color)
Posted By: Kale Re: The SNES WIP topic - 08/13/09 09:02 AM
Originally Posted By Heretical_One
I wouldn't think so. palette RAM is 512 bytes, at 15 bits per entry.


512/2=256...8 bpp = 256 colors per entry

I need something that uses direct color without mode 7 anyway...
Posted By: Heretical_One Re: The SNES WIP topic - 08/13/09 10:12 AM
According to Overload (author of Super Sleuth):

Quote:

From my lists these games uses Direct Color Mode

ActRaiser 2, Romance of the 3 Kingdoms 2, Aerobiz, Aerobiz SuperSonic, Secret of Mana


I know Secret of Mana is a world map (and you'll spend longer getting to that point than you will on the bug itself!)


According to my notes (which may not reflect newer findings):
the palette entry itself (0-255) takes the form bbgggrrr and the tilemap palette selection becomes bgr. The palette index supplies the top bits, palette select the next bit, and the rest are 0. (That is, blue = iit00, green/red are iiit0, where t is the palette selection in the tilemap, and the other is the palette index taken from the tile)

Does that match your documents?
Posted By: Kale Re: The SNES WIP topic - 08/13/09 10:28 AM
Originally Posted By Heretical_One

Does that match your documents?


Yes, matches, also there's a bug on color calcs even in mode 7 that I need to fix.

EDIT: calcs were right but applied on the wrong layer. And I've lost hopes to find something that uses mode 3/4 + direct colors --"







Posted By: Heretical_One Re: The SNES WIP topic - 08/13/09 11:24 AM
Supposedly, Secret of Mana uses direct color + mode 3 for one of the world maps. that's a good 20+ hours of gameplay to reach, though.

It should work the same as mode 7, except that mode 7 doesn't have 3 palette bits in the tilemap.

What modes are those last two shots actually in? The first one is obviously Mode 7. The second very well could be (possible logo tricks like Actraiser pulls). The third would be... strange. That looks like a classic place to use Mode 3.
Posted By: Kale Re: The SNES WIP topic - 08/13/09 12:10 PM
It's mode 7 for all of three snaps, first two are Aerobiz, the third is Romance of the Three Kingdoms 2 (it uses zooming effects etc.). And, guess that I need to play Secret of Mana and at least I have an original SNES USA cart, I just need to check if I still have a valid save...
Posted By: Kale Re: The SNES WIP topic - 08/13/09 06:38 PM

r5426 /src/mame/video/snes.c: [SNES]: Fixed direct color gfxs in mode 3/4, also fixed color data shifting in both modes.


Many thanks to Lord Nightmare for the save file. smile



Color shifting is the first thing that MESS does what other snes emus don't afaik. Ideally if you should do a color conversion to a framebuffer and you can't completely fill that framebuffer, you should fill the remaining data with the most significant bytes of the color offsets.
Comparison:

before:


after:
Posted By: Deunan Knute Re: The SNES WIP topic - 08/13/09 07:06 PM
Is this "color shifting" the same as RGB channel depth promotion doing texture lookups?
Example: if the render target is 888 and the texture is 565 RGB format then the hardware will promote the bits like this:

destination R [7:0] <- source (R4, R3, R2, R1, R0, R4, R3, R2)

Posted By: Kale Re: The SNES WIP topic - 08/13/09 07:12 PM
Yes, exactly like that smile
Posted By: R. Belmont Re: The SNES WIP topic - 08/13/09 07:18 PM
Huh. On my laptop I couldn't see a difference between the "before" and "after" Aerobiz pictures above, but it's very obvious on my desktop (which admittedly has a much higher quality LCD panel). I guess those pictures are useful as a sort of color gamut quick check smile
Posted By: Deunan Knute Re: The SNES WIP topic - 08/13/09 07:18 PM
Well that's one more reason to try hardware rasterization :P
Posted By: byuu Re: The SNES WIP topic - 08/13/09 08:18 PM
Looks like you're making exciting progress, congratulations!
Please don't hesitate to ask if you have any questions.

Quote:
Oh well, we need a mess vs. bsnes snap comparison before continuing talking all the day about it ;P


Yes, discussed on my forum. Minor regression caused while moving some things for save state support:
src/ppu/ppu-inline.hpp:77:
status.hcounter = 0;
//was status.hcounter = 186;
//which was mis-aligning OAM address reset and such

http://img13.imageshack.us/img13/2981/71901316.png

In the middle of adding a GUI-based debugger, so no new build just yet.

Quote:
Color shifting is the first thing that MESS does what other snes emus don't afaik. Ideally if you should do a color conversion to a framebuffer and you can't completely fill that framebuffer, you should fill the remaining data with the most significant bytes of the color offsets.


If you're meaning SNES RGB555->RGB888 bit-extending (10111->10111101 instead of 10111000), I already do that. If you're meaning direct-color mode RGB443->RGB555, then you are incorrect. The low bits are always zero on the real thing.

//palette data = 00000bgr
//tilemap data = BBGGGRRR
//result = 0BBb00GGGg0RRRr0

Verify yourself by placing an all-white sprite on top of the BG layer.

If your goal is to make the output prettier than the real thing, it's a good strategy. I'd also recommend rasterizing mode 7 at 512x448 in that case wink

Now then, if you really want to be the first to do something ... $2100 INIDISP controls the screen brightness. But it is not a linear drop as you go down. In fact, with a brightness of zero the screen is still visible. Max out your TV brightness control and you will see it. The effect can't be simulated in RGB555 colorspace. The actual color adjust occurs on the luma channel upon TV output in YUV format. The exact algorithm is unknown, as it's very hard to measure.
Posted By: Shideravan Re: The SNES WIP topic - 08/13/09 08:18 PM
Good!
The Super Mario Kart are now showing the screen!
But i have a problem to report: the other racers are being attracted by mine...
and i can't go forward after this...
Posted By: Deunan Knute Re: The SNES WIP topic - 08/13/09 08:48 PM
Yup, color depth extension can be tricky - usually due to hardware limitations. On PowerVR twiddled textures will reuse high-order bits but non-twiddled (for example RT stride-type texture) will be zero-padded. Except one-bit channels, those are always properly extended (this only applies to alpha in 1555 mode anyway).
Posted By: Kale Re: The SNES WIP topic - 08/13/09 08:57 PM
Originally Posted By byuu
If your goal is to make the output prettier than the real thing, it's a good strategy. I'd also recommend rasterizing mode 7 at 512x448 in that case wink


The goal wasn't to do the output prettier, but to do things in line with all the other Arcade/Console HWs that does things like that (yes, it's a guess). If you've done tests on the real HW that says otherwise, then I'll go reverting it. smile
Posted By: byuu Re: The SNES WIP topic - 08/13/09 09:59 PM
Well, I always recommend everyone test on real hardware themselves. The truth is, I've tested thousands upon thousands of things, but I don't always keep documentation for each and every last thing.

I'm quite sure I've tested this, and it's the reason I always use my own custom palettes in mode 3 rather than direct color for my fan translation splash screens. Well, that plus only being able to control the low bit per 8x8 tile makes it extremely useless ...

But without a documented test ROM to prove it, I don't want to tell you with 100% certainty that I am correct here.

The best advice I can give you though, is that 99% of the time, the way you *think* something should logically work, is not the way the SNES actually works :P
Posted By: Tafoid Re: The SNES WIP topic - 08/13/09 10:12 PM
SVN r5427

Wordtris does not start (no input allowed]



You get to this screen and you should be able to options with the joypad/arrows or hit START to continue. Neither works and it sits there for a long while before restarting the Title Screen again.
Posted By: Heretical_One Re: The SNES WIP topic - 08/13/09 10:24 PM
byuu, how much of a testing battery for things like interrupts and DMA do you still have? I know you've done extensive work on these areas, but it's rather difficult to sort out the "right behavior" from forum posts (and code is notorious for subtle bugs that break things, so an actual test is always better than a source compare)
Posted By: byuu Re: The SNES WIP topic - 08/13/09 10:57 PM
Quote:
He and I both know the guy who programmed that audio driver. The author considers it an ongoing source of lulz that even bsnes sometimes glitches that audio but it's always perfect on real h/w.


I certainly wouldn't be proud of writing such flaky software, but to each their own wink

People tend to think that if something works on one real SNES, that it will work on every real SNES. Not true, those crystal clocks tend to vary per unit, if ever so slightly. I can almost guarantee you that even if it's only on 0.1% of SNES units, that some have problems with these types of games.

Anyway, I'm not aware of any audio glitches in this game. But I do know that we desperately need someone to clock the S-CPU crystal with an oscilloscope. We know that the S-SMP is rated at 24,576,000hz, but really runs at around 24,606,720hz. The S-CPU is rated at 21,477,272hz, but if it actually is off by such a large amount as well, it could very well be the cause of issues in Clayfighters.

If someone can reproduce Clayfighters sound issues, they can try modifying cpu.ntscClockRate in bsnes.cfg. I'm almost certain they could get sound perfected if they find the right value.

Quote:
Depending on how it fails, some games seem to want the SPC700's RAM to be initialized on power-up.
Common SNES emulator practice is to flood-fill RAM with bit 5 of the address (but this doesn't fix Panic Bomber World. Already tried it). I believe Overload (of DSP-* fame) discovered that pattern.


I've heard this a lot, and since bsnes started, I've always filled APURAM with 0x00 on power-on. Never had any problems, not even with Bomberman games.

The only game I know that has issues with APURAM initialization is SD Gundam G-NEXT, an SA-1 game. It has some sort of issue if you don't clear certain parts of it on reset. I haven't looked into it much.

Quote:
(something about Captain Commando (J) crashing in bsnes)


I can't reproduce that, it runs fine here. Any more details?

Quote:
byuu, how much of a testing battery for things like interrupts and DMA do you still have?


I have a few test ROMs that combine a few dozen tests each.

But seriously, you don't want them right now. You will need extremely precise timing for them to work. They will fail if you're off by even a single master clock cycle.

You'll need bus-level (not cycle-level) accuracy, DRAM refresh, (H)DMA/CPU sync, the differences between CPU revisions 1 and 2, every opcode tested to ensure the cycle timing and ordering are correct, full MDR support, etc etc etc perfected before you try them.

At this time, no other emulator can even pass my seek_frame function, which when called, returns with the PPU counters at *exactly* V=0,HC=0 (H=HC/4, by the way. $213c reports the current *dot*, but there are four cycles per dot.)

You guys really need to drop the current CPU approach and go full-on at 21MHz. Be prepared that proper DMA sync timing requires executing the next cycle of the current position, which can be in the middle of two opcodes, and you need to be able to sync up all other processors while a DMA that can be up to ten frames long runs.

I never managed to pull that off flawlessly with state machines, so hopefully you guys are more skilled with those than I am.

I would love it if you guys could catch up, and especially if you guys could start performing your own hardware tests. I desperately need someone else who's really interested in SNES emulation to help motivate-and-work-with me, so we can start making real progress once again laugh

Things have stalled badly since anomie left ...
Posted By: Kale Re: The SNES WIP topic - 08/13/09 11:13 PM
Originally Posted By byuu

Quote:
(something about Captain Commando (J) crashing in bsnes)


I can't reproduce that, it runs fine here. Any more details?


Maybe you already fixed it...anyway:

00F915: CLC
00F916: XCE
00F917: SEP #$30
00F919: JMP $c00000
C00000: SBC $ffffff,X
C00004: SBC $ffffff,X
(and so on and on and on)


This is what it does in MESS and presumably in bsnes v0.048 too since that the snescart code is ported from there. It does that in "Live-A-Live (J)" and "3x3 Eyes - Jyuma Houkan (J)" too, pratically decodes the cart as LoROM but it's actually an HiROM...

EDIT: r5429 /src/mame/machine/snes.c: [SNES]: Fixed a vram out of bounds bug

Posted By: byuu Re: The SNES WIP topic - 08/13/09 11:36 PM
Code:
00f914 sei         A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nv1BdIzc V:  0 H: 186
00f915 clc         A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nv1BdIzc V:  0 H: 200
00f916 xce         A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nv1BdIzc V:  0 H: 214
00f917 sep #$30    A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nvMXdIzC V:  0 H: 228
00f919 jml $c00000 A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nvMXdIzC V:  0 H: 250
c00000 sei         A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nvMXdIzC V:  0 H: 282
c00001 cld         A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nvMXdIzC V:  0 H: 296
c00002 lda #$8f    A:0000 X:0000 Y:0000 S:01ff D:0000 DB:00 nvMXdIzC V:  0 H: 310
c00004 sta $2100   A:008f X:0000 Y:0000 S:01ff D:0000 DB:00 NvMXdIzC V:  0 H: 326


Not from here it isn't ... that's from v048 official. Maybe an issue with the porting of my detection code?
Posted By: Kale Re: The SNES WIP topic - 08/14/09 12:02 AM
Maybe, I'll check it out tomorrow...
Posted By: Heretical_One Re: The SNES WIP topic - 08/14/09 12:02 AM
byuu, I don't even work on the SNES driver here smile

Just assume I have "outside interests" that could benefit, but aren't necessarily MAME-architecture compatible. (I doubt it will pass just yet, but I'd assume the tests would have an explanation of expectations that would)

I guess I'm just looking to address the large hole in the SNES testing battery.

At the highest level, you have an SPC700 test ROM from Overload.
In the middle, the SNES test cart.

There's not much else. Nothing to test the 5A22 (where I'm sure I have a bug somewhere). Nothing to test DMA register behavior short of games. Nothing to test IRQ/NMI at a tighter tolerance than the electronics test (which is not terribly precise). Nothing to check for the DRAM refresh. Obviously, your tests come at the extremely fine end of the scale, but they still would serve a purpose in circulation: that of offering a highly precise set of "last tests" for shaking down an emulator.
Posted By: Kale Re: The SNES WIP topic - 08/14/09 12:06 AM
Ah, before I forgot...
What exactly tests the SNES Test Program under "Eletronics Test"?
Posted By: Heretical_One Re: The SNES WIP topic - 08/14/09 12:35 AM
Off-hand?

range-time over flag.
interlace odd/even flag (always active)
RAM
interrupts (VERY coarse)

byuu might have ?anomie's? commented disassembly of it. I think that got left behind on my PC upgrade. It's not terribly useful anyway. You have to pass most of them just to get decent game compatibility, and the interlace flag is literally "opposite of whatever it was before" to pass. Not sure we know the initial state of the flag, though.

RTO is the big one, and anomie's documents ought to cover it all.
Posted By: R. Belmont Re: The SNES WIP topic - 08/14/09 12:37 AM
I had a partially commented disassembly that anomie made - I'll see if I can dig it up. First it tests things like VRAM and OAM uploads and downloads, then it tries to verify basic raster operations (VIRQ and HIRQ vs. latched counter values vs. the vblank and hblank status flags) and then it tests things like sprite time over/line over.
Posted By: Lord Nightmare Re: The SNES WIP topic - 08/14/09 01:34 AM
byuu: have frequency counter, will travel. which pin of which chip do you need measured?

EDIT: electronics test stuff? TRAC sent me a bunch, lemme see if i can find it...


LN
Posted By: byuu Re: The SNES WIP topic - 08/14/09 05:29 AM
http://i570.photobucket.com/albums/ss144/whickercuppajo3/5A22pinout.png

Pin 72 looks to be our target. Should be ~21,477,272hz. The more precision you can get, the better!

Thank you very much in advance, this will be extremely helpful!
Posted By: Deunan Knute Re: The SNES WIP topic - 08/14/09 09:09 AM
Is such accuracy even needed? Off the shelf crystal resonator will have about 50ppm initial skew. Even assuming constant ambient temperature (which it is not, worse even there are thermcal cycles when the device is turned on and then off) there will be about 10ppm shift every ten years. It's faster when the part is new and tends to slow down and stabilize as it gets older.
The frequency can be somewhat changed (and hence corrected) with a small variable capacitor but I really doubt getting it within 10ppm or so tolerance was a part of manufacturing process...

Sure, most of the PCBs produced are very similar to each other but every now and then there is a black sheep and it's crystal is way more off compared to the rest. That would mean the game requiring very precise timing would not work on that particular piece of hardware... In that case you can claim to emulate said kind of unit and explain it not working is normal behaviour smile
Posted By: byuu Re: The SNES WIP topic - 08/14/09 03:27 PM
Quote:
Is such accuracy even needed?


That seems to be the case. A few games will break using stock (official spec) speeds:
- American Tail: Fievel Goes West
- Breath of Fire 2: German vocal intro
- Clayfighters supposedly has sound skip issues
- Earthworm Jim 2: European sound effects

Running the S-SMP at 32040*768hz instead of 32000*768hz fixes everything, except R. Belmont is saying there's still some slight issues with Clayfighters.

The first two break if you change CPU<>SMP skew by 768hz more than what I use now.

Quote:
Off the shelf crystal resonator will have about 50ppm initial skew.


S-SMP stock is 24576000hz. Clocked at 24606720hz. That's a skew of 30720hz. Which is closer to 1,000ppm skew. In fact, almost all SNES units we've clocked have ended up right around the latter. It seems more like the spec was wrong than all the crystals.

Quote:
That would mean the game requiring very precise timing would not work on that particular piece of hardware... In that case you can claim to emulate said kind of unit and explain it not working is normal behaviour


I try and explain this, but people assume that because it worked on at least one SNES, that emulators are flawed if they don't also run it.

There are really flat out *broken* commercial games out there. Death Brade/Blade and this European racer won't work unless you initialize WRAM to non-0x00s. It checks a certain byte without initializing it, and if it's zero, the game doesn't work. Given the variable nature of DRAM on power-on, there's probably a 1:256 chance that will be the case on the real thing.

So, if we know console X can run these titles, and we match its oscillators, then we can rule out clock issues if the games still break in emulation.
Posted By: Lord Nightmare Re: The SNES WIP topic - 08/14/09 05:15 PM
Originally Posted By byuu
http://i570.photobucket.com/albums/ss144/whickercuppajo3/5A22pinout.png

Pin 72 looks to be our target. Should be ~21,477,272hz. The more precision you can get, the better!

Thank you very much in advance, this will be extremely helpful!


Signal is noisy as hell on both pins 72 and 71; freq meter says 2842.888 khz, I think this 4/3 of the actual clock due to some weird harmoinics (clock xtal says D214J1), that would put the clock at 21.32166Mhz which seems awfully low...
Maybe I need to run it through a bandpass or something...

EDIT: with the more low-tech non 10:1 probe i get a much cleaner signal, but its still showing as 2842.888khz for clock. now that i can see the waveform i see why its getting confused, there are two places where the slope is appropriate for triggering the edge sensor...

LN
Posted By: Kale Re: The SNES WIP topic - 08/14/09 05:31 PM
r5432 /src/mame/video/snes.c: [SNES]: Fixed a blending bug involving main/sub color maths



Posted By: etabeta78 Re: The SNES WIP topic - 08/14/09 05:40 PM
brilliant!!!!

I hope to be able to fix my hardware problems (my macbook died at last), and to come back to give my small contributions... but you're doing a much better work! (see my silly mode 7 direct color mistake wink )
Posted By: Kale Re: The SNES WIP topic - 08/14/09 06:17 PM
It's not about mistakes calculations, it's just to go forward. And I've did a mistake with direct color calcs too (see r5431).

Anyway...new OPT cases (both gfx mode 2):

Dead Dance, Rolf stage (6):

(rocket actually moves with the sprite)

Super Double Dragon, later in the stage 1:

(there's actually another elevator on the right, people enters from the glass "hole")

Still don't have a plan for OPT frown
Posted By: Deunan Knute Re: The SNES WIP topic - 08/14/09 06:42 PM
Originally Posted By Lord Nightmare
now that i can see the waveform i see why its getting confused, there are two places where the slope is appropriate for triggering the edge sensor...


Try different GND point - I'd go with pin #79 and then try something closer to the oscillator circuit if it's not clean enough. If that is still too noisy you can try bleeding the signal to ground a bit (with 100-1k pulldown resistor), this will lower the amplitude of course but it tends to eat up any parasite signals faster than the main one so it might just work.
Posted By: byuu Re: The SNES WIP topic - 08/14/09 08:12 PM
Quote:
that would put the clock at 21.32166Mhz which seems awfully low...


Well, keep in mind the PAL CPU supposedly runs at 21281370hz. Another thing we need tested. But yeah, 21321660hz breaks Earthworm Jim 2 (U)'s sound effects, so that's probably not right.
Posted By: R. Belmont Re: The SNES WIP topic - 08/14/09 08:16 PM
What are the relevant crystals/CMOS oscillators actually rated at? (On a real board, not in theory smile
Posted By: Kale Re: The SNES WIP topic - 08/14/09 08:45 PM
r5434 /src/mame/video/snes.c: [SNES]: Fixed interlace mode gfxs when not in gfx modes 5/6

Found that Ranma Nibunnoichi - Chonai Gekitou Hen / Street Combat uses interlace without hires, aspect ratio on screenshots is shitty as the rest of the game...



(Now the SNES Test program stars sprites are identical when switches from non interlace to interlace, dunno at the current time how they squeeze in half like bsnes does)
Posted By: etabeta78 Re: The SNES WIP topic - 08/14/09 09:09 PM
what about the black square moving in front of the stars?
Posted By: Kale Re: The SNES WIP topic - 08/14/09 09:17 PM
Where?
Posted By: R. Belmont Re: The SNES WIP topic - 08/14/09 10:58 PM
Here's one for ya - the main menu of Rock n' Roll Racing (US) is just a purple screen. The developer logos prior to it are fine - it looks like a palette DMA got missed or something.
Posted By: Kale Re: The SNES WIP topic - 08/14/09 11:12 PM
Shaq Fu is hanging for some reason, but I guess it's related to the sprite OAM stuff...when the game starts to do a DMA to the OAM port the game'll hang for some reason. Indeed a debug trick (by trigger random values to "zero-page" address $84 when it hangs during attract mode) shows the following screen...



...attempting to write more causes graphics artifacts with the (incidentally) sprites...ideas?

As for Rock N' Roll Racing, it's definitely un-initialized palette RAM, if you wait an attract cycle it puts the following:



EDIT:
It does this:
GDMA-Ch 3: len: 10000, abus: 7E2200, bbus: 2122, incr: 1, dir: CPU->PPU, type: 0

For non-experts: BBUS 0x2122 is the cgram port, cgram size is 0x200 and 0x7e2200 is null data. Pratically these are the DMA params modified by a previous DMA, if I remove the hook-up colors are right (i.e. if I keep the params to be abus = 0x7e2000 and length = 0x200). Still searching for a explaination (timings or a DMA quirk?)
Posted By: Heretical_One Re: The SNES WIP topic - 08/14/09 11:50 PM
Best way to watch for OAM is *usually* to watch for 544 byte DMA transfers (destination $04, but the 544 has always jummped out at me faster)

I'm thinking it's still going to wind up being a timing issue for Shaq Fu.

Possible lead on the other one (investigating now).

Apparently, Rock n Roll Racing expects DMA to stay in-bank. (Bank wrapping is not at all uncommon on the 65816, see MVN/MVP and several other modes where the top 8 bits of an address are fixed). My best reading of BSNES indicates likewise (the A-bus address only increments a 16-bit address and appends 8 bits for bank). MESS, otoh, uses a 24-bit DMA address.

edit because Kale added stuff: If DMA isn't reset after a DMA, that's what I would expect them to be. Short of DMA from a fixed source. Except for the length. That should be 0 after a transfer.

Edit (I'm stupid): oh. 0x10000 that's probably solved by adding the bank wrap. because the last 0x200 bytes that DMA would write? the palette!
Posted By: Kale Re: The SNES WIP topic - 08/15/09 12:07 AM
Ok, considering that the "param update" is...

snes_ram[SNES_DMA_BASE + dma + 2] = abus & 0xff;
snes_ram[SNES_DMA_BASE + dma + 3] = (abus >> 8) & 0xff;

(i.e. not +4 update)
..indicates that you're right, thanks smile

Posted By: etabeta78 Re: The SNES WIP topic - 08/15/09 09:04 AM
Originally Posted By Kale
Where?


end of Mode 0 demo. if you look at BSNES, there is a black square passing in front of the strip of stars which is missing in MESS wink
Posted By: Tafoid Re: The SNES WIP topic - 08/15/09 05:38 PM
r5439 - Tiny Toon Adventures - Buster Busts Loose (U)

At the end of the first level, you get a chance to play a mini-game selectable from a spinning wheel. This wheel still show correctly at times, but not all the time. I notice if I fast forward - it seems to show correctly all the time.







Here is an .INP to get you there and through it.
SNES .INP for Tiny Tune Adventures - Buster Busts Loose (U)
Posted By: Kale Re: The SNES WIP topic - 08/15/09 05:48 PM

r5440 /src/mame/machine/snes.c: [SNES]: Fixed HDMA mid-frame inits.


According to Anomie:

Originally Posted By "Anomie"

Note that enabling a channel mid-frame will begin HDMA at the next HDMA
point. However, the HDMA register initialization only occurs before the
HDMA point on scanline 0, so those registers will have to be
initialized by hand before enabling HDMA.


This was completely missing from the current emu, hooking it up means the following nice stuff to happen:

Energy Breaker (J)








Super Ghouls 'n Ghosts / Choh Makai Mura






Posted By: R. Belmont Re: The SNES WIP topic - 08/15/09 07:23 PM
Nice!
Posted By: byuu Re: The SNES WIP topic - 08/15/09 07:39 PM
Quote:
(Now the SNES Test program stars sprites are identical when switches from non interlace to interlace, dunno at the current time how they squeeze in half like bsnes does)


If I'm not mistaken, the half-compression is due to enabling OAM interlace.

Quote:
what about the black square moving in front of the stars?


It isn't a black square, it's range-tile over. There are too many sprites on the scanline to show all at once, so one ends up not getting rendered. They change the OAM base address to determine which is the FirstSprite, allowing them to cycle through all of them.

Support for this goes hand-in-hand with the RTO test in the electronics test, so you can kill two birds with one stone.
Posted By: Kale Re: The SNES WIP topic - 08/15/09 07:46 PM
Thanks for the info wink

On an unrelated note: Do you know the exact reason about why Puzzle Bobble / Bust-A-Move sprites gets gradually offsetted in vertical?
Posted By: byuu Re: The SNES WIP topic - 08/16/09 12:55 AM
No, I'll guess that it's related to offset-per-tile mode. Seems silly to use it in puzzle games, but I know there's a version of Tetris that does just that.
Posted By: R. Belmont Re: The SNES WIP topic - 08/16/09 01:47 AM
Super Tetris 3 I believe - I fixed a lot of problems that prevented it from starting when I last did major work on the driver, but I wanted no part of offset-per-tile smile
Posted By: Heretical_One Re: The SNES WIP topic - 08/16/09 06:35 AM
compared to Mode 5/6, offset per tile is rather straight forward, IMO.
Posted By: Kale Re: The SNES WIP topic - 08/16/09 08:30 AM
It's confirmed, Puzzle Bobble uses MIXED gfx modes 1/4, Lines 33-166 is gfx mode 4, gfx mode 1 otherwise. Needless to say, the mode 4 is used on the playfield...
I wonder how to handle all of this mode mixing...post processing with a VIDEO_EOF?
Posted By: Heretical_One Re: The SNES WIP topic - 08/16/09 08:50 AM
I'm confused.

Aside from Mode 5/6, where does mode-mixing matter?
Nothing else changes the resolution. The output's all 256 pixels wide for 0-4 and 7, and it's all 15-bit BGR color. How does the mode mixing require a post-process (again, aside from using 5 or 6)?

Now, if it's "when mode 5 is mixed in, we have issues", I can understand that. But Mode 1 and 4 seems like the standard scanline updates should handle this well enough? (ie, as well as you'll get without a dot-based PPU)
Posted By: Kale Re: The SNES WIP topic - 08/16/09 09:01 AM
I was talking in general, obviously modes 1/4 doesn't need post processing ;P
Posted By: Heretical_One Re: The SNES WIP topic - 08/16/09 09:12 AM
Ok. So it's the standard "uh-oh, h resolution doubled" issue every SNES emulator has to deal with.

Most wind up doubling everything up to that point, and from then on as well. No idea what byuu does, so he might have a better way than what the old emulators did.
Posted By: Kale Re: The SNES WIP topic - 08/16/09 09:39 AM
Don't know what byuu does, but generally resolution changes are processed at the start of a v-blank, so if we delay the snes_htmult variable to be changed only on these occasions then...

EDIT: still doesn't work, needs post-processing with VIDEO_EOF...

EDIT again: actually my first thought was right but forgot to do a video modification, will finish it soonish...
Posted By: Kale Re: The SNES WIP topic - 08/16/09 01:53 PM

r5445 /src/mame/video/snes.c: [SNES]: Made dynamic H resolutions to be called only at vblank start and and fixed gfx mode switching 1/5 and 5/1


Tokimeki Memorial


Seiken Densetsu 3


Donkey Kong Country


Doukyusei 2



The Firemen


New bug: Tokimeki Memorial hangs when you do a choice, maybe it senses that a DMA goes wrong? EDIT: it seems another timing bug...
Posted By: byuu Re: The SNES WIP topic - 08/16/09 05:31 PM
Quote:
Most wind up doubling everything up to that point, and from then on as well. No idea what byuu does, so he might have a better way than what the old emulators did.


What I do is render each line at whatever the current resolution is, and store its width into a buffer: unsigned lineWidth[480];
I also keep a flag: bool frameHasHires |= (thisLineWidth == 512);

In that way, my filters have the choice of either up-sampling each 256-width line to 512-width, or rendering each different section of the screen in different blocks.

The main problem is handling software filters like HQ2x. If you up-sample a 256-width screen to 512-width, you won't be able to properly HQ2x filter the screen. Games like Secret of Mana 2 will act screwy when your filtering drops every time a text box appears. The lineWidth buffer will allow you to work around that, but will require heroic efforts in writing said filters. For bsnes, only the NTSC filter supports it fully.

Quote:
(ie, as well as you'll get without a dot-based PPU)


If you're really ready to cry, I suspect that it's possible to change between lores and hires in the middle of a scanline. So any width between 256 and 512 should be theoretically possible.

I plan to forcefully always render at 512-width for my dot-based PPU. Indeed, the two modes are very similar on the SNES. It just changes how the main and sub screens blend together.
Posted By: AWJ Re: The SNES WIP topic - 08/16/09 05:47 PM
Wouldn't it be simpler just to render 512 horizontal pixels all the time? It's not like MESS cares about supporting kiddie filters. How big a speed penalty for non-hires games would this entail?
Posted By: R. Belmont Re: The SNES WIP topic - 08/16/09 05:49 PM
That's pretty much what MESS already does for a lot of systems. On the Apple IIgs I always render 640+border and pixel-double 320 mode, for instance, and it's fine.
Posted By: byuu Re: The SNES WIP topic - 08/16/09 05:52 PM
The speed penalty depends upon how fast MESS already is, or will be. For bsnes, it wouldn't even be noticeable because everything else is so slow already :P

It's just that SNES users are quite picky about having their NTSC or HQ2x filters. It's easy to say you don't care, but you can't very well test every last game ever made yourself. You'll need to get some hardcore fans to help you with that.
Posted By: Just Desserts Re: The SNES WIP topic - 08/16/09 06:57 PM
Originally Posted By byuu
It's just that SNES users are quite picky about having their NTSC or HQ2x filters. It's easy to say you don't care, but you can't very well test every last game ever made yourself. You'll need to get some hardcore fans to help you with that.


I guess it sucks to be us, then. smile

MESS and MAME ostensibly use an "If you build it, they will come" mentality - once a driver is considered relatively complete, eventually someone will wander by and try his or her favorite obscure game. And since that person will be trying MAME or MESS, that person is typically smart enough to track down the right forums and report the bug. It's slower, and more appealing to the lazy.
Posted By: AWJ Re: The SNES WIP topic - 08/16/09 06:59 PM
The NTSC filter would apply just fine to a doubled 512-wide image, wouldn't it? It'd just be (considerably) slower.
Posted By: etabeta78 Re: The SNES WIP topic - 08/16/09 07:25 PM
filters (except Blargg's NTSC one) suck because they make the result different from what I was able to see on the real thing.

if I want super-smooth edges and blurs, I'd play a PC first person shooter, not an old SNES game with any HQnx filter wink

that said, it would be great to try to create a generic NTSC filter which could be overlayed to MESS systems supposed to be connected to a TV
Posted By: Kale Re: The SNES WIP topic - 08/16/09 08:41 PM
I don't like the "double everything to 512" approach...unless proven otherwise, in the end Seiken Densetsu 3 is running with HRES=256 and the other test cases runs at HRES=512, so the CRTC is presumably doing some post-processing with the internal framebuffer and trigger the internal 256/512 switch caused by modes 5/6 at vblank time. It works for now for either MESS and for BSNES, but imho it's definitely something that requires tests on real HW if possible (for example by quickly switching between mode 1/5 on a single screen and see if there's or not a noticeable flicker on the resulting screen).
Posted By: R. Belmont Re: The SNES WIP topic - 08/16/09 08:53 PM
Also there's a difference between having users help test and deciding to become a slower version of zsnes. You can have users without letting them dictate your design. (I'm still somewhat horrified that bsnes has add-on chips now given how much byuu used to argue against them).
Posted By: byuu Re: The SNES WIP topic - 08/16/09 08:55 PM
Not sure what you mean. Hires can definitely be toggled mid-frame with no flickering. It just varies how long each color is fed to the display.

Same for pseudo-hires. It's quite possible to use two BG layers in mode 0 to make a 512x480 screen =)

Interlace on the other hand, while it can be toggled at any time and takes immediate effect on PPU addressing, obviously cannot take effect immediately on the TV. It caches the interlace setting somewhere and will apply it consistently to the entire screen. Not sure if it does it every single frame or every other frame, though. Too hard to tell.
Posted By: Kale Re: The SNES WIP topic - 08/16/09 09:06 PM
I mean the fact that afaik the screen is drawn correctly without any artifact on a real screen if you toggle gfx modes 1/5 or 5/1, something that's imho impossible to not be noted if the resolution is changed during the frame (otherwise games like Seiken Densetsu 3 weren't programmed like that if it was suicide for the eyes).
Posted By: AWJ Re: The SNES WIP topic - 08/16/09 09:57 PM
Originally Posted By Kale
I don't like the "double everything to 512" approach...unless proven otherwise, in the end Seiken Densetsu 3 is running with HRES=256 and the other test cases runs at HRES=512, so the CRTC is presumably doing some post-processing with the internal framebuffer and trigger the internal 256/512 switch caused by modes 5/6 at vblank time. It works for now for either MESS and for BSNES, but imho it's definitely something that requires tests on real HW if possible (for example by quickly switching between mode 1/5 on a single screen and see if there's or not a noticeable flicker on the resulting screen).


Buh? The SNES doesn't have an "internal framebuffer". I don't know if it even has a linebuffer (byuu?). AFAIK each scanline is rendered directly to the video outputs in real time. Don't confuse multi-thousand-dollar arcade PCBs that could afford to throw on hundreds of kilobytes of RAM with consoles that had to retail for $200.

That Seiken Densetsu 3 screenshot is definitely not what the game looks like on real hardware--the Japanese text is too blocky and almost unreadable.
Posted By: Kale Re: The SNES WIP topic - 08/16/09 10:07 PM
Every CRTC/video chip has an "internal framebuffer(s)", the sprites / tilemaps / blitters / polygons stuff is just a layer that is then always converted internally by the video HW. It's only a recent "invention" that you can control/write this framebuffer directly, but it was still there from the dawn of times...

About Seiken Densetsu 3, there's certainly a bug regarding that garbage at the top of the talk bar, surely there's a couple of bug in the current mode 5/6 implementation (see also the vertical stripes in that Tokimeki Memorial screen).
Posted By: byuu Re: The SNES WIP topic - 08/16/09 10:13 PM
Quote:
Buh? The SNES doesn't have an "internal framebuffer". I don't know if it even has a linebuffer (byuu?).


I sincerely doubt it. The closest they have is a sort of pre-fetch line for OAM, to handle all the RTO stuff and sorting. That's why scanline 0 is black, OAM is preparing. And yes, modifying certain registers mid-frame will thusly throw off OAM rendering really bad.

Outside of that, yes. It almost certainly outputs one pixel at a time and moves on.
Posted By: Heretical_One Re: The SNES WIP topic - 08/16/09 10:55 PM
SNES definitely draws on-the-fly. If it has any sort of *buffer, byuu's right: it's for sprites only.

Reasoning? Why would Nintendo add a framebuffer to the SNES, when the NES didn't have one? The hardware *is* directly related. Also, thwe SUperscope is a heavy argument against a framebuffer.

It's been calculated which way sprites are handled, and the basic answer is "there's no way to tell". The data necessary to hold the tiles and x position info are roughly equal to the demands of plotting the sprites out as tiles are fetched, and only handling priority and palette lookup during rendering to screen.

anomie's research always said that p-hi-res was simply double-pumping the DAC, and there was no reason to think modes 5 and 6 were different.
Posted By: AWJ Re: The SNES WIP topic - 08/16/09 11:20 PM
Originally Posted By byuu
I sincerely doubt it. The closest they have is a sort of pre-fetch line for OAM, to handle all the RTO stuff and sorting. That's why scanline 0 is black, OAM is preparing. And yes, modifying certain registers mid-frame will thusly throw off OAM rendering really bad.


Yeah, that's exactly what I meant by a "linebuffer". I meant a double-buffered setup for sprites--there's no reason to double buffer the BG layers!

When 2D arcade hardware is described as line buffered (e.g. Sega System 16A/B) or frame buffered (e.g. Sega X-Board) it refers to how the sprite generator works--BG layers are practically always rendered directly to the mixer. On a frame buffered system the fact that sprites, but not the BG, are double-buffered is what causes "sprite lag", where the sprites appear a frame or two out of sync with the BG if an emulator (or the original game code!) doesn't take the double buffering into account.

Originally Posted By Kale
About Seiken Densetsu 3, there's certainly a bug regarding that garbage at the top of the talk bar, surely there's a couple of bug in the current mode 5/6 implementation


I wasn't just talking about the garbage. Any time there's even a single visible scanline of hires anywhere on the screen you need to render the entire frame at 512 resolution, otherwise you're throwing ("half-")pixels away.
Posted By: Heretical_One Re: The SNES WIP topic - 08/16/09 11:41 PM
well, the SNES backgrounds are double-buffered as well, sort of.

The system doesn't have enough bandwidth to render the worst case scenario unless 2 complete sets of BG tiles are loaded at the start of rendering. It also explains why the left tile in Mode 2/4 is not offset smile
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 12:48 AM
Originally Posted By Heretical_One
The system doesn't have enough bandwidth to render the worst case scenario unless 2 complete sets of BG tiles are loaded at the start of rendering. It also explains why the left tile in Mode 2/4 is not offset smile


I'm having a hard time wrapping my brain around what you mean by that. What exactly is "double buffered"--the tile pattern data? And how does that help with bandwidth? What is the "worst case scenario", and what happens if it occurs on more than one scanline, or even on every scanline?
Posted By: Heretical_One Re: The SNES WIP topic - 08/17/09 01:34 AM
You have to load the second tile of the line before rendering starts. That means tilemap and tile data for up to 4 BGs must be present for 2 complete tiles before you start.

you can load 2 bytes per dot, and you render one pixel or 2 half-pixels in high res in that time.

worst case, you have to reload everything after 1 pixel. The SNES can't do that, but 8 pixels is just enough to do that, necessitating caching a second tile. (1 dot = 1 16-bit read, so 1 tilemap or 1 2bpp chunk of 8 pixels). This is why every time you raise the bit depth, the layers drop: to shift bandwidth to accomodate more planes being fetched.

Work it out, you NEED 2 tiles to draw at all with 7 pixels of the first tile scrolled off the left edge of the screen. Can't work any other way (although the order BGs are fetched in isn't assured, and it's unknown how tiles and tilemaps are interleaved)

This only affects a given line. The whole proces restarts on the next line.
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 02:59 AM
Oh, you meant double buffered in terms of tiles. I was thinking scanlines, since we were previously talking about line buffering sprite generators. Your explanation makes perfect sense (whereas buffering a scanline ahead makes no sense at all)

I figured that the reason the SNES PPU has the modes it does is because of memory bandwidth as soon as I noticed that the total number of 2-bit planes (doubled in the hires modes) plus the number of layers (counting the OPT table as a layer) always adds up to no more than 8:

Mode 0: 4 layers + 4 planes (1 + 1 + 1 + 1) = 8
Mode 1: 3 layers + 5 planes (2 + 2 + 1) = 8
Mode 2: 3 layers + 4 planes (2 + 2) = 7
Mode 3: 2 layers + 6 planes (4 + 2) = 8
Mode 4: 3 layers + 5 planes (4 + 1) = 8
Mode 5: 2 layers + 6 planes (2*2 + 1*2) = 8
Mode 6: 2 layers + 4 planes (2*2) = 6

ETA: I just noticed that this also explains the limitations of Mode 4 compared to the other OPT modes (i.e. each tile can only have a horizontal or vertical offset applied, not both)
Posted By: Kale Re: The SNES WIP topic - 08/17/09 10:21 AM
Originally Posted By AWJ

Originally Posted By Kale
About Seiken Densetsu 3, there's certainly a bug regarding that garbage at the top of the talk bar, surely there's a couple of bug in the current mode 5/6 implementation


I wasn't just talking about the garbage. Any time there's even a single visible scanline of hires anywhere on the screen you need to render the entire frame at 512 resolution, otherwise you're throwing ("half-")pixels away.


Then again...there's a bug in the mode 5/6 implementation that makes some pixels to be "thrown away"... check the charset 6 on snap 1 and charset 3 on snap 2.





Could also be that calling a single line of mode 5 makes the entire screen to be 512x224, but again we are into the same theory league as who shot JFK...

And in the end...I'm referring as "internal framebuffer" the thing that converts the digital format to something usable by an analog device like a TV, the DAC in short.
Posted By: Just Desserts Re: The SNES WIP topic - 08/17/09 12:02 PM
Originally Posted By Kale
And in the end...I'm referring as "internal framebuffer" the thing that converts the digital format to something usable by an analog device like a TV, the DAC in short.


But that's not the way a RAMDAC works.
Posted By: Kale Re: The SNES WIP topic - 08/17/09 12:19 PM
Go Go Ackman 2 hangs are caused by main<->sound cpu comms rather than timing, setting the interleave to perfect fixes the hangs on it.
Posted By: R. Belmont Re: The SNES WIP topic - 08/17/09 02:03 PM
Yeah, I just fixed kinstb in MAME by doing that (not that you can tell because the list is still broken). And perfect interleave makes Actraiser fart several times before it hangs ;-)
Posted By: Kale Re: The SNES WIP topic - 08/17/09 04:24 PM
Originally Posted By R. Belmont
The correct fix is to have a separate S-CPU core that's clocked at SNES master (21.whatever) and have everything take the right amount of cycles from there. Anything else will just cause trouble later.


Ok, I'm going to see this one, the plan is:
* Add a new CPU core, 5A22, that is a clone of G65816 with just a different CPU_EXECUTE (that contains a cycles*6 instead of cycles in this function)
* Modify SNES and friends driver to have this new core with clock = master clock instead of clock / 6
* Start to hook up all the cpu eat cycles where needed...

Is it a good plan? shocked

EDIT: part one of the plan doesn't already work as expected... frown
Posted By: R. Belmont Re: The SNES WIP topic - 08/17/09 04:40 PM
The plan I was going for was to clock it at 21.whatever and have each cycle of each instruction eat the appropriate number of master clocks depending on the speed switch, fast/slow ROM, etc. That way you don't need eat_cycles instructions all over the place.
Posted By: Kale Re: The SNES WIP topic - 08/17/09 04:49 PM
You mean doing all of this inside the cpu core and having extra internal states like the slow/fast ROM, right?
Posted By: R. Belmont Re: The SNES WIP topic - 08/17/09 04:54 PM
Right. The H8 core does something similar-ish where there's an internal function that given an address computes the number of clocks needed to access it and all the opcodes are built on that.

Technically all the 4xxx registers should be internal to the core also but I could see that causing trouble for HDMA etc.
Posted By: byuu Re: The SNES WIP topic - 08/17/09 04:59 PM
Feel free to use this as PD. Many people have tried to improve it (with lookup tables, ternary, only one return point, etc), but none have succeeded wink

Code:
unsigned sCPU::speed(unsigned addr) const {
  if(addr & 0x408000) {
    if(addr & 0x800000) return fastROM;
    return 8;
  }
  if((addr + 0x6000) & 0x4000) return 8;
  if((addr - 0x4000) & 0x7e00) return 6;
  return 12;
}


Set (unsigned)fastROM to 8 on reset, and on $420d.d0 writes, set to (d0 ? 6 : 8);

If you stick this function inside the bus_read() and bus_write() functions, the core of your CPU won't ever need to manually specify eat_cycles() calls.
Posted By: R. Belmont Re: The SNES WIP topic - 08/17/09 05:11 PM
Nice smile Thanks byuu!
Posted By: judge Re: The SNES WIP topic - 08/17/09 06:42 PM
This would be so much nicer with waitstate support in the core ...
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 07:20 PM
Originally Posted By Kale
Could also be that calling a single line of mode 5 makes the entire screen to be 512x224, but again we are into the same theory league as who shot JFK...


I'm sorry, but this talk about the resolution of "the entire screen" shows that you don't seem to grok how a CRTC or for that matter a raster display works. A CRT only has a discrete "resolution" in the Y axis--the number of visible scanlines. The X "resolution" is merely a question of how rapidly the analog signal feeding the CRT changes, and there's absolutely no reason that frequency has to be the same on each scanline. You could theoretically make a CRTC that produced a 320-pixel horizontal resolution in the top half of the display, a 256-pixel horizontal resolution on odd-numbered scanlines in the bottom half, and an 800-pixel horizontal resolution on even-numbered scanlines in the bottom half. Of course this hypothetical CRTC would have no practical use whatsoever, but it would work perfectly fine with any standard unmodified CRT.

Of course, an emulator has to ultimately produce a rectangular image with a discrete resolution in both axes. When the emulated CRTC output has different resolutions on different scanlines, the only way you can do this while preserving all the horizontal detail is by upscaling every scanline to the highest horizontal resolution that's present in the frame. The only other possibility is to downscale the higher-resolution scanlines to the lower resolution. That's what your SD3 screenshot is doing, and it's not correct emulation--it's throwing away image detail that would be visible on real hardware.

Someone (Arbee? Aaron?) help me out here, I'm not sure if I'm getting through...
Posted By: R. Belmont Re: The SNES WIP topic - 08/17/09 08:12 PM
byuu mentioned that 512 mode double-pumps the DAC - I assume that means the pixel clock goes faster for those lines so you have twice as many pixels per master cycle.

ETA: Alternatively the pixel clock is always fast enough for 512 but they normally feed each pixel twice. Either way we know it doesn't impact the actual H or Vsync timing or else the screen wouldn't sync when you did a split like that.
Posted By: byuu Re: The SNES WIP topic - 08/17/09 09:08 PM
I always like to show this picture to emu devs:
http://img35.imageshack.us/img35/3281/hires.png

That's Jurassic Park, it uses pseudo-hires. On the left is what the image looks like on a TV. On the right is an emulator that doesn't support pseudo-hires. The bottom image shows how pseudo-hires works. You'll notice even columns are one background layer, and odd columns are another.

The important thing to take away is that the pixels at 512-width aren't as sharp as pixels at 256-width: they tend to blur with their neighbors. It's because the TV has less time to display them, and CRT fuzziness, and bla bla bla.

Note that even with the blending, you will still need to render the output at 512-width. Merging even and odd pixels at 50% will lose too much detail.

Also note, something no other emulator does for some reason, but I hope you guys will: hires and pseudo-hires, though they grab pixels differently, output exactly the same. Thusly, you should perform the same blurring when you render true hires screens like in Secret of Mana 2. Yes, it will make text slightly harder to read. But there's nothing stopping a real system from using pseudo-hires to display text, or real hires to blend two screens ala Jurassic Park. A real SNES won't magically output clearer pixels in true hires mode.

This is how I output 512-width lines and blend them to create the top-left image. It averages the next pixel to output with the previous pixel, then saves the true current pixel for the next loop iteration. Feel free to use something similar, or not.

Code:
      for(unsigned x = 0, prev = 0; x < 256; x++) {
        curr = get_pixel_swap(x);
        *ptr++ = (prev + curr - ((prev ^ curr) & 0x0421)) >> 1;
        prev = curr;

        curr = get_pixel_normal(x);
        *ptr++ = (prev + curr - ((prev ^ curr) & 0x0421)) >> 1;
        prev = curr;
      }


Credit to blargg for the idea.
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 09:26 PM
Originally Posted By byuu
This is how I output 512-width lines and blend them to create the top-left image. It averages the next pixel to output with the previous pixel, then saves the true current pixel for the next loop iteration. Feel free to use something similar, or not.


A side effect of applying a lowpass filter to the entire screen (which is what you're doing) is that the parts of the screen that are fake-blended using pseudo-hires appear sharper than the unblended parts. Look at the fence posts near the left and right edges--the part of the post that's "behind" the text window has pixel-sharp edges, while the part that isn't is blurred.

ETA: the difference between the flames in the blended and non-blended parts of the upper left screenshot is even more obvious.

Also, it would be nice if you posted a screenshot of SD3 under your renderer for comparison.
Posted By: Kale Re: The SNES WIP topic - 08/17/09 09:45 PM
r5455 /src/mame/machine/snes.c: [SNES]: Made the gfx mode switches more accurate.


I was right on one thing: we definitely have a bug with gfx mode 5/6 (see the vertical stripes). So I declare it a draw! laugh

Posted By: byuu Re: The SNES WIP topic - 08/17/09 09:47 PM
Yeah, because it's aliasing with the popup window. Perhaps there's a better algorithm for the blending than what I used. The entire screen is actually rendered at 512-width, that's not a 50/50 split like the textboxes in Secret of Mana 2. It's just that most of the pixels outside of that window are the same on even and odd columns.

The same aliasing may occur on a TV, I'd have to look and see.

EDIT: AWJ, here's Secret of Mana 2. Note the flowers at the bottom. http://img11.imageshack.us/img11/374/sd3e.png
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 10:13 PM
Originally Posted By byuu
Yeah, because it's aliasing with the popup window. Perhaps there's a better algorithm for the blending than what I used. The entire screen is actually rendered at 512-width, that's not a 50/50 split like the textboxes in Secret of Mana 2. It's just that most of the pixels outside of that window are the same on even and odd columns.

The same aliasing may occur on a TV, I'd have to look and see.

EDIT: AWJ, here's Secret of Mana 2. Note the flowers at the bottom. http://img11.imageshack.us/img11/374/sd3e.png


Wow, the lowpass filter makes SD3's background look much nicer! Especially the grass. The font is also a lot less blurry than I expected.

I don't think it's possible to fix the aliasing (as you call it) in JP without making all the games that use hires "normally" look worse. JP is pretty much the only game that abuses hires for faux-alpha-blending (rather than to get more detail for fonts, etc.), isn't it? I wonder why they didn't just use color math...
Posted By: Kale Re: The SNES WIP topic - 08/17/09 10:23 PM
Something started to work with the latest change...









...I wonder if anything broke actually...
Posted By: Justin Re: The SNES WIP topic - 08/17/09 10:34 PM
Note that the MESS video code for SNES is shared with MAME for NSS so we can't go adding TV-specific blending effects willy-nilly without also handling the arcade monitor case.
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 10:39 PM
Originally Posted By Justin
Note that the MESS video code for SNES is shared with MAME for NSS so we can't go adding TV-specific blending effects willy-nilly without also handling the arcade monitor case.


Yeah, in the context of MAME/MESS filters like byuu's really don't belong in the driver layer.
Posted By: R. Belmont Re: The SNES WIP topic - 08/17/09 11:34 PM
Sure, but since none of the (dumped) NSS games use 512 mode does it matter? smile
Posted By: AWJ Re: The SNES WIP topic - 08/17/09 11:49 PM
Originally Posted By R. Belmont
Sure, but since none of the (dumped) NSS games use 512 mode does it matter? smile


It does matter if you decide to render at 512 width all the time (and, hence, apply the filter all the time)

And the idea of applying a lossy filter to the video at the driver level (which is what gets output to screenshots) should give Aaron fits.
Posted By: byuu Re: The SNES WIP topic - 08/17/09 11:52 PM
Well, you'll need to think of something, unless you want Jurassic Park to look like that bottom picture smirk

Also, I believe Kirby's Dreamland 3 also uses it for a water effect. You'll probably want to worry about the SA-1 more before that, though.
Posted By: Lord Nightmare Re: The SNES WIP topic - 08/18/09 01:12 AM
jp looking like the bottom picture then being squashed to 256x244 using bilinear filtering should look surprisingly like the actual screen i think.
It would look even better if nintendo had made the screen output alternate field1/field 2 by line, so it would be each layer displayed in a checkerboard.

LN
Posted By: Heretical_One Re: The SNES WIP topic - 08/18/09 06:44 AM
Great work with Full Throttle Racing, Kale!

Of course, I only found out if it booted because I was trying to check on HDMA bugs anomie solved in SNES9X. MESS exhibits the same bug (it screws up the colors), and something or other is also glitching the mode 7 area (again, it looks like old Snes9x versions (up through the early 1.4x series), except worse because it looks half-height). These bugs occur in jetski races.

Not exactly sure what changed (not that knowing helps, but it was fixed in 1.40), but it's definitely listed as HDMA.
Posted By: Kale Re: The SNES WIP topic - 08/18/09 11:24 AM
Cacoma Knight started to work too...



Now I'm really wondering: are we running with the correct pixel clock now or two faults DO make one reason? shocked
Posted By: Kale Re: The SNES WIP topic - 08/18/09 03:11 PM

r5458 /src/mame/machine/snes.c: [SNES]: improved joypad read/write handling and fixed a serial port quirk.


Fixed various input bugs to make at least version 1.0 of Bishoujo Janshi Suchie Pai to work. iirc there should be a bunch of games that was reporting wrong continous pressure before (Super Tetris 2 & Bombliss comes to mind)
I've also noticed that Libble Rabble, The Skins Game and the aforementioned Super Tetris 2 & Bombliss inputs are buggy (aren't consistant), originally I've thought that was the same bug but in reality they suffer of (guess what) maincpu timing issue...
Posted By: R. Belmont Re: The SNES WIP topic - 08/18/09 03:33 PM
Super Street Fighter 2 is a good input test - previously in MESS (and in older zsnes/snes9x) it wouldn't recognize any buttons once it reached the title screen.
Posted By: Kale Re: The SNES WIP topic - 08/18/09 03:52 PM
They works, but they were working on MESS 0.132 too...something of note is that tilemap scrollings (including "floor effects") were broken before and now are fixed, and the Ryu intro uses OPT effects (I presume for the lightning bolts)
Posted By: Kale Re: The SNES WIP topic - 08/19/09 12:20 PM
In the end I've enabled the perfect interleaving...

Go Go Ackman 2



Batman Forever



The cutted "Hold On" msg is caused by bad maincpu timings...I don't know why the window effects doesn't work at all though...

In the other news...Tafoid made a regression test, now we know almost every game that doesn't currently boot. I'll try to see the reason of each then post the results. smile
Posted By: R. Belmont Re: The SNES WIP topic - 08/19/09 01:53 PM
Perfect interleave also makes Actraiser fart instead of just hanging smile
Posted By: etabeta78 Re: The SNES WIP topic - 08/19/09 03:08 PM
Originally Posted By R. Belmont
Super Street Fighter 2 is a good input test - previously in MESS (and in older zsnes/snes9x) it wouldn't recognize any buttons once it reached the title screen.


Originally Posted By Kale
They works, but they were working on MESS 0.132 too...


they got fixed around 0.126 (when I fixed RAM/ROM/SRAM banking) and never had a problem since then
Posted By: Kale Re: The SNES WIP topic - 08/19/09 04:12 PM
r5466 /src/mame/machine/snes.c: [SNES]: Improved cart mode 20 reserved access behaviour

I don't know how it truly works (Anomie docs doesn't say anything about it), but several games reads from the low bank of 0xc***** area. Applying a guessed mirror fixes many (but not all) broken cases. Random screenshots:











The guessed mirror is:
value = snes_ram[0x200000 + ((offset & ~0x8000) | 0x8000)];
Now the question is: how it truly works? Shoudn't be in cart mode 20 at all? But these games doesn't seem suited to work with HiROM loading instead of LoROM...
Posted By: R. Belmont Re: The SNES WIP topic - 08/19/09 04:54 PM
Interesting. I assume byuu will tell us how that actually works smile
Posted By: Kale Re: The SNES WIP topic - 08/19/09 05:13 PM
And here's the compatibility list with my notes...

http://mamedev.emulab.it/kale/fast/files/548_not_working.zip

I wonder why Tales of Phantasia sound doesn't work at all even with the timing trick...sound (DSP) bug?
Posted By: R. Belmont Re: The SNES WIP topic - 08/19/09 05:22 PM
Hmm. NHL '96 (and probably the others in that series) is a regression, it works in 0.133.

ETA: the BS games of course all need special mapping and I think some add-on hardware.
Posted By: Kale Re: The SNES WIP topic - 08/19/09 05:26 PM
For the NHL games, is the same issue as Clay Fighter, aka caused by the Rock 'n Roll Racing GDMA boundary fix... --"

EDIT: actually no, it's not caused by that, and I quite don't have an idea about what broke it...
Posted By: R. Belmont Re: The SNES WIP topic - 08/19/09 05:46 PM
AFAIK NHL and ClayFighter both do the "execute an MVN out of the DMA registers" hackery, so be careful about open bus on those.
Posted By: Anna Wu Re: The SNES WIP topic - 08/19/09 06:11 PM
The sound for Actraiser (U/E) is not fixed yet, right ?
Posted By: R. Belmont Re: The SNES WIP topic - 08/19/09 06:19 PM
Right.
Posted By: Anna Wu Re: The SNES WIP topic - 08/19/09 06:21 PM
Originally Posted By R. Belmont
Right.


Oki smile
Posted By: Shideravan Re: The SNES WIP topic - 08/19/09 09:37 PM
Wow!
Alladin has the backgrounds fixed now!
Thank you guys!
Posted By: byuu Re: The SNES WIP topic - 08/19/09 11:56 PM
Quote:
several games reads from the low bank of 0xc***** area


Quote:
Interesting. I assume byuu will tell us how that actually works


src/memory/smemory/generic.cpp has your answers. You should just copy that part. There's some trickery involving SRAM sizes that will cause you trouble saving in Ys 3 if you try and do it yourselves.

There are about four dozen PCBs, and each one maps different data to different areas, and many have large open bus regions. Download Super Sleuth and look at pcbs.pdf for examples. Since the PCB ID isn't dumped with games, and the ZSNES team isn't interested in them, we get LoROM and HiROM, and have to make every game work. It's also the same reason we're stuck with copier headers and 20+ SNES ROM extensions in 2009.

Nach did an outstanding job and created generic layouts that work for all known games. Not the solution I'd personally want (I want the PCB IDs (or an exact list of mapping info for said PCB), as well as ROM, save RAM and RTC data all stored in the same file), but it works.

Anyway, I never map to $[c0-ef]:[0000-7fff] in LoROM games. That region falls through to open bus. If games are being fixed by that, you have other problems I'm afraid.
Posted By: Shideravan Re: The SNES WIP topic - 08/20/09 12:51 AM
In the first boss of Toy story, after you beat it, the stars that fall from enemy don't are showed...
Posted By: judge Re: The SNES WIP topic - 08/20/09 05:51 AM
For the time being the PCB information could be added to the hashfiles. Cowering usually creates those hashfiles whenever he releases a new goodsnes so he should be made aware of those changes too.
Posted By: byuu Re: The SNES WIP topic - 08/20/09 07:06 AM
What PCBs do you think he'll use for all the fan translations he refuses to remove from his sets?
Posted By: Heretical_One Re: The SNES WIP topic - 08/20/09 07:20 AM
for the most part translations would either use the parent board, or the next larger board in series. You've seen Overload's PCB documentation. You know quite well that most boards are simply part of a series that handle progressively larger ROM and SRAM smile

(For real fun, try Front Mission's fan translation. That makes assumptions that wouldn't work on a cheap PCB)*

* The 32 Mbit patch wouldn't need special mapping hardware, only the original patch would.
Posted By: JonasP Re: The SNES WIP topic - 08/20/09 12:10 PM
Couldn't find this reported here or in bugzilla:

Super Mario World: BG and platform graphics are corrupted during the first boss fight. This happens with latest SVN, r5467.
Posted By: R. Belmont Re: The SNES WIP topic - 08/20/09 02:51 PM
Jonas: what version?
Posted By: JonasP Re: The SNES WIP topic - 08/20/09 03:24 PM
Super Mario World (USA) in NoIntro
CRC32: b19ed489
Posted By: Kale Re: The SNES WIP topic - 08/20/09 03:25 PM
Yes, regression...that thing uses mode 7...
Posted By: R. Belmont Re: The SNES WIP topic - 08/20/09 03:29 PM
I meant "of MESS", but if Kale says it's a regression it's a regression smile
Posted By: Kale Re: The SNES WIP topic - 08/20/09 03:39 PM
http://mamedev.emulab.it/kale/fast/files/smw_wannabeaspeedrunner.zip

An INP of mine up to that point, delete NVRAM...
Posted By: guigongas Re: The SNES WIP topic - 08/20/09 03:44 PM
Dragon Ball Z - Super Saiya Densetsu has a bug in the beginning of the game. The character suddenly becomes green for a second.
Posted By: ht1848 Re: The SNES WIP topic - 08/20/09 03:46 PM
Originally Posted By byuu
Since the PCB ID isn't dumped with games, and the ZSNES team isn't interested in them, we get LoROM and HiROM, and have to make every game work. It's also the same reason we're stuck with copier headers and 20+ SNES ROM extensions in 2009.

Nach did an outstanding job and created generic layouts that work for all known games. Not the solution I'd personally want (I want the PCB IDs (or an exact list of mapping info for said PCB), as well as ROM, save RAM and RTC data all stored in the same file), but it works.

Originally Posted By Judge
For the time being the PCB information could be added to the hashfiles.

Someday I sure would like MESS to get to a "supported software" list like MAME. There just seems to be so many things it could solve. This is a whole nother thread worth of discussion so I don't want to derail the awesome SNES progress here.

PS...someone give byuu svn access. byuu - It is just like helping your neighbor work on his busted hotrod instead of your own.

Posted By: Kale Re: The SNES WIP topic - 08/20/09 03:53 PM
Originally Posted By guigongas
Dragon Ball Z - Super Saiya Densetsu has a bug in the beginning of the game. The character suddenly becomes green for a second.


This is a new bug instead...
Posted By: guigongas Re: The SNES WIP topic - 08/20/09 04:02 PM
I think it's similar to the bug in the intro of rock 'n' roll racing that you've already solved before. Something wrong in the pallete.
Posted By: Kale Re: The SNES WIP topic - 08/20/09 05:08 PM
It's more similar to the Bishoujo Janshi Suchie Pai "4 VHSes" bug actually, color offset bug?
Posted By: guigongas Re: The SNES WIP topic - 08/20/09 05:43 PM
Sorry, but i honestly don't have a clue.
Posted By: guigongas Re: The SNES WIP topic - 08/20/09 06:11 PM
Here's a screenshot of the bug.



I hope this helps.
Posted By: Kale Re: The SNES WIP topic - 08/20/09 06:20 PM
I'm still able to press start in a videogame, thanks anyway :P
Posted By: R. Belmont Re: The SNES WIP topic - 08/20/09 06:31 PM
You don't understand - Lizard Scrotum K fanboys are the worst in all of geekery and you will now be hounded for defiling their game ;-)
Posted By: byuu Re: The SNES WIP topic - 08/20/09 08:24 PM
Quote:
Someday I sure would like MESS to get to a "supported software" list like MAME.


Honestly not a good idea. You'd need at least 4,000+ entries, and then you can't run any hacks / fan translation stuff. I know some MAME people would like this; but whatever, most wouldn't. It also requires that giant database to be distributed with each and every emulator.

Nah, store the exact mapping info along with the game, and now you can custom-map and run anything. Makes the emulator more powerful and flexible.

Quote:
You don't understand - Lizard Scrotum K fanboys are the worst in all of geekery and you will now be hounded for defiling their game ;-)


dont u talk bad abt vegeta his power lvl is over 9000 hes even stronger then freezer as super sayajin 5 gojita n ur just jelus cuz pokemans iznt kool nemore lol
Posted By: judge Re: The SNES WIP topic - 08/20/09 09:14 PM
Originally Posted By byuu
Quote:
Someday I sure would like MESS to get to a "supported software" list like MAME.


Honestly not a good idea. You'd need at least 4,000+ entries, and then you can't run any hacks / fan translation stuff. I know some MAME people would like this; but whatever, most wouldn't. It also requires that giant database to be distributed with each and every emulator.

Nah, store the exact mapping info along with the game, and now you can custom-map and run anything. Makes the emulator more powerful and flexible.


Having a "supported software" list does not mean not being able to run hack/fan/fun stuff. The supported software list would be more documentation of what was actually released for the system. Anyway, that's a whole different discussion wink
Posted By: Just Desserts Re: The SNES WIP topic - 08/20/09 10:23 PM
Originally Posted By byuu
dont u talk bad abt vegeta his power lvl is over 9000 hes even stronger then freezer as super sayajin 5 gojita n ur just jelus cuz pokemans iznt kool nemore lol


You just went up like 10 points on my Awesome-O-Meter, and you were already pretty high up there. Well done.
Posted By: Kale Re: The SNES WIP topic - 08/20/09 11:41 PM
r5474 /src/mame/video/snes.c: [SNES]: Fixed a bug with color window maths

Batman Forever


Guess that there's a bunch of games that benefits of this fix...
Posted By: Shideravan Re: The SNES WIP topic - 08/20/09 11:46 PM
The progress in the driver is AMAZING!
Well, i bug that's affect MESS and MAME:


Should have to be a walking Mario on the place that i marked :p

Posted By: Kale Re: The SNES WIP topic - 08/20/09 11:57 PM
Another new issue (high priority bit maybe?)

Anyway...I think that the Super Famicom Box should be moved on the MAME side since it's a coin based for hotels, or not?
Posted By: R. Belmont Re: The SNES WIP topic - 08/20/09 11:58 PM
That's fuzzy - it's coin but not arcade.
Posted By: byuu Re: The SNES WIP topic - 08/21/09 12:00 AM
Originally Posted By Kale
Another new issue (high priority bit maybe?)


No, add range-tile over and Mario should show up.
Posted By: Kale Re: The SNES WIP topic - 08/21/09 10:52 PM
Fixed a blending bug caused by imperfect half colour behaviour in Soul Blazer. The half math now shouldn't take the back colour into account:





@Arbee: there's already a system like that in MAME, it's the Neo-Geo -bios 9 (aka the "Custom Japanese Hotel"). In my humble opinion that's eligible like the Playchoice-10 or the MegaTech.
Posted By: byuu Re: The SNES WIP topic - 08/22/09 12:29 AM
About the half-color bit. I forget whether it does the divide by two before or after adding the colors, but I did test that on hardware and verified that whatever I'm doing now is correct.
Posted By: Shideravan Re: The SNES WIP topic - 08/22/09 01:55 AM
Games tested in 5492:

Toy story: Regression. The title screen is showed as a blank screen

Super Mario Kart: Black Title screen:


The attract persist:


Megaman X3: Ratter to begin the game, that shows this screen:



Posted By: Just Desserts Re: The SNES WIP topic - 08/22/09 05:32 AM
Originally Posted By Shideravan
Games tested in 5492:
Megaman X3: Ratter to begin the game, that shows this screen:



Mega Man X2 and X3 use the CX4 coprocessor. Support will probably not be added for the forseeable future (though, looking at bsnes's source, I see no reason why it couldn't be).
Posted By: Just Desserts Re: The SNES WIP topic - 08/22/09 10:57 AM
I poked a MAMEdev (who wishes to remain anonymous) on IRC before I went to bed last night, and this morning I woke up to see basic CX4 support checked into the MAME source tree. After rolling it into MESS, both Mega Man X2 and Mega Man X3 boot right up and are almost fully playable. The only issue I've seen is that in scenes that should have wireframe graphics provided by the CX4, the OAM data that gets displayed is just garbage:









Posted By: Kale Re: The SNES WIP topic - 08/22/09 11:33 AM
Originally Posted By Shideravan
Games tested in 5492:
Toy story: Regression. The title screen is showed as a blank screen


Can't reproduce, I see the correct title screen here...
Posted By: Shideravan Re: The SNES WIP topic - 08/22/09 02:42 PM
Wow! Thanks!
Originally Posted By Just Desserts
[...]though, looking at bsnes's source, I see no reason why it couldn't be).


This could mean that the SuperFX can be supported soon?
Posted By: Kale Re: The SNES WIP topic - 08/22/09 07:04 PM
New bug related to Super Drift Out:



Translated in words: the game doesn't init the battery backed ram, meaning that the records can't be beated...maybe it wants a fill $ff?
Posted By: Shideravan Re: The SNES WIP topic - 08/22/09 08:26 PM
In 5493:

We can see problems in most of the games that use the DSP-1:

Armored trooper votons: some graphics problems...
Bike Daisuki! - Rider's Spirits: the try to enter in the game causes a reset...
Final Stretch: Weird graphics...
Michael Andretti's Indy Car Challenge: strange "pitch" in the road...
Pilotwings: "gravity" problems...
Suzuka 8 Hours: Only begin to show graphics in the game. Pre screens (such title) only shows blank
Super 3D Baseball: don't initiate the game here...
Super F1 Circus Gaiden: flag is wrong
Super MArio KArt: the problem was related before...
Posted By: ranger_lennier Re: The SNES WIP topic - 08/22/09 08:33 PM
Originally Posted By Kale

@Arbee: there's already a system like that in MAME, it's the Neo-Geo -bios 9 (aka the "Custom Japanese Hotel"). In my humble opinion that's eligible like the Playchoice-10 or the MegaTech.


FWIW, that's what I was thinking. Is the Super Famicom Box doing anything yet?

@Kale: Guru dumped a Waialae No Kiseki (Waialae Golf) & Super Mahjong 2 (PSS-62) cart for the Super Famicom Box, which I don't think is in the driver yet. If you don't have it, send me a message.
Posted By: guigongas Re: The SNES WIP topic - 08/23/09 05:23 PM
Could you improve the sound during battles in Chrono Trigger?
In the rest of the game the sound is nice, however in battles it keeps "freezing" all the time.

Thanks in advance!
Posted By: Lord Nightmare Re: The SNES WIP topic - 08/23/09 11:03 PM
does the chrono trigger sounds issue happen during the intro as well?

LN
Posted By: guigongas Re: The SNES WIP topic - 08/24/09 12:57 AM
Originally Posted By Lord Nightmare
does the chrono trigger sounds issue happen during the intro as well?

LN

No. Only during battles.

Edit - To make it clear: Is the BGM that keeps stopping and then restarting (sorry i can't find better words to describe it). smile
Posted By: Shideravan Re: The SNES WIP topic - 08/24/09 04:12 AM
Using 5496:
In Timon and pumba's jungle games.
In the minigame "Burper", the background is wrong.
Other problem is if you use a burp (which one) you will bugs the burp display, then you dont will be allowed to do a burp anymore...
Posted By: Just Desserts Re: The SNES WIP topic - 09/01/09 07:45 PM
byuu, can you think of anything off the top of your head that would allow SuperFX 1 games to boot and work well (Stunt Race FX, Starfox, and Vortex in particular), but completely fail to display any polygons? It's not even trying to draw them.
Posted By: byuu Re: The SNES WIP topic - 09/01/09 10:22 PM
Yes, I ran into the same bug. Thank _Demo_ for the solution.

<__Demo__> it turns out the superfx was accessing data in lower part of banks
<__Demo__> so it needs to simply contain the same data as the upper part from the superfx side

In case it's not clear, he's saying $00-3f:0000-7fff should be identical to $00-3f:8000-ffff. A15 is ignored.

Though there are some slight differences between each PCB revision, this memory map will work for all SuperFX games.

Code:
sfxbus.map(MapLinear, 0x00, 0x3f, 0x0000, 0x7fff, memory::gsurom);
sfxbus.map(MapLinear, 0x00, 0x3f, 0x8000, 0xffff, memory::gsurom);
sfxbus.map(MapLinear, 0x40, 0x5f, 0x0000, 0xffff, memory::gsurom);
sfxbus.map(MapLinear, 0x60, 0x7f, 0x0000, 0xffff, memory::gsuram);

cpubus.map(MapLinear, 0x00, 0x3f, 0x6000, 0x7fff, memory::gsuram, 0x0000, 0x2000);
cpubus.map(MapLinear, 0x00, 0x3f, 0x8000, 0xffff, memory::gsurom);
cpubus.map(MapLinear, 0x40, 0x5f, 0x0000, 0xffff, memory::gsurom);
cpubus.map(MapLinear, 0x60, 0x7d, 0x0000, 0xffff, memory::gsuram);
cpubus.map(MapLinear, 0x80, 0xbf, 0x6000, 0x7fff, memory::gsuram, 0x0000, 0x2000);
cpubus.map(MapLinear, 0x80, 0xbf, 0x8000, 0xffff, memory::gsurom);
cpubus.map(MapLinear, 0xc0, 0xdf, 0x0000, 0xffff, memory::gsurom);
cpubus.map(MapLinear, 0xe0, 0xff, 0x0000, 0xffff, memory::gsuram);


The RAM ones with "0x0000, 0x2000" at the end are simply saying "keep mirroring the first 8k", the same way SNES WRAM does to $00-3f|80-bf:0000-1fff.

By the way, how are you emulating these chips so fast? Are you reusing eg Snes9x's core, or is someone extremely talented working on it? smile
Posted By: Anna Wu Re: The SNES WIP topic - 09/01/09 11:06 PM
Originally Posted By Just Desserts
byuu, can you think of anything off the top of your head that would allow SuperFX 1 games to boot and work well (Stunt Race FX, Starfox, and Vortex in particular), but completely fail to display any polygons? It's not even trying to draw them.


SuperFX 1 support will be great. smile
Posted By: Heretical_One Re: The SNES WIP topic - 09/01/09 11:13 PM
IIRC, the SuperFX core comes from MAME somehow?
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 12:08 AM
Originally Posted By byuu
By the way, how are you emulating these chips so fast? Are you reusing eg Snes9x's core, or is someone extremely talented working on it? smile


A little of column A - bsnes, by the way - and a little of column B. smile

Currently, all of the RAM and ROM buffering / timing is disabled because it was more important (IMHO) to just get things booting to start with.

I have your S-DD1 and S-RTC implementations ported over, but neither of them currently work, and I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip? I'd be surprised if the cart didn't just use a stock RTC from some third-party manufacturer, for which datasheets exist.
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 01:40 AM
Star Fox:






Stunt Race FX:




Vortex:






byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?
Posted By: Stiletto Re: The SNES WIP topic - 09/02/09 02:52 AM
Originally Posted By Just Desserts
I have your S-DD1 and S-RTC implementations ported over, but neither of them currently work, and I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip? I'd be surprised if the cart didn't just use a stock RTC from some third-party manufacturer, for which datasheets exist.


I'd be willing to look, if I can get a decent PCB scan for SHVC-AE6J-JPN.

- Stiletto
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 05:26 AM
Originally Posted By Just Desserts

byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?


Incidentally, do you think those issues could be caused by mirroring where no mirroring is present, or having no mirroring where mirroring is present?

Basically, what I want to know is: if the SuperFX reads from a SuperFX memory address of 0x712345, does it actually read from index 0x2345 in the FX RAM buffer? If the S-CPU reads from 0x356789, is this the same as a read from 0x306789, which itself is a read from index 0x789 in the FX RAM buffer (due to mirroring)?

Thanks in advance.
Posted By: etabeta78 Re: The SNES WIP topic - 09/02/09 06:30 AM
while at it, byuu, can you confirm the statement you gave at bsnes 0.047 release

Quote:
SuperFX support was the work of many people. [snip] (for reference, the implementation in bsnes is my own design)


?

we included the SFX core (uniquely based on your implementation) on the assumption it was original design and, hence, PD as most of bsnes

finally, is Nach missing in action? I tried to contact him with no luck about some code of his...
Posted By: netol Re: The SNES WIP topic - 09/02/09 10:12 AM
Just a question,
did you read http://byuu.org/bsnes/license/ ?
I don't understand English perfectly but reading this I think that bsnes is not Public Domain, not exactly... wink
Posted By: etabeta78 Re: The SNES WIP topic - 09/02/09 10:24 AM
ok, I've definitely chosen the wrong wording and it's not public domain (even if, since he started working on his emu, byuu himself defined Public Domain bsnes source for quite some time wink )

however, as byuu has stated many times, bsnes can be used freely as a base for implementation in other emu (and he already kindly donated to MESS part of the cart recognition code) and this kind of free reference implementation is what we need for MESS in this particular case wink
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 01:18 PM
Grah. I'm trying to do a side-by-side execution comparison between bsnes and MESS, so as to track down the remaining issues, but for the life of me I can't compile bsnes. Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it. When I get home from work I'll see if I can find out exactly where.
Posted By: byuu Re: The SNES WIP topic - 09/02/09 05:25 PM
Quote:
I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip?


Yes. The registers just return the current time. Don't give it localtime() info, or the "round clock to the nearest minute" feature of games won't work, and the time setting screens will be pointless. Plus it'll break in 2014, as you can't set the clock higher than that in FEoEZ.

All the extra code in bsnes is to let you specify whatever time you want, and update it as real system time passes. Plus it has to work around libc localtime()/mktime() issues with dates outside the system epochs (the S-RTC chips have no such limitation.) And lastly, I store a 4-byte timestamp no matter what (so the same .rtc state file works on 32-bit and 64-bit systems), and use some trickiness to work even beyond Y2K38. Fun stuff.

If you could, please keep compatibility with my .rtc file format. SNESGT uses the same. Snes9X stupidly appends it to the end of .srm files (causing all other emulators to erase it), and ZSNES just uses the current system time.

Quote:
byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?


Not at all, sorry. For me, horrible crashing was usually due to opcode bugs, and I haven't had any of the other issues.

Are you handling IRQ communications between chips properly? Eg the GSU STOP command and such.

Quote:
Basically, what I want to know is: if the SuperFX reads from a SuperFX memory address of 0x712345, does it actually read from index 0x2345 in the FX RAM buffer? If the S-CPU reads from 0x356789, is this the same as a read from 0x306789, which itself is a read from index 0x789 in the FX RAM buffer (due to mirroring)?


I would strongly advise you to handle the mirroring properly (per my map on the previous page.) But I couldn't say for sure, mirroring was one of the first things I did.

Quote:
while at it, byuu, can you confirm the statement you gave at bsnes 0.047 release


Yes, that is correct. I looked at the Snes9X and SNESGT implementations, but wrote it all myself. And had a dozen bug fixes provided by Jonas Quinn. As you no doubt know, integrating someone else's CPU core is very tough, as they tend to hook all kinds of external stuff: IRQ triggers, a custom memory mapping system, etc.

Quote:
finally, is Nach missing in action? I tried to contact him with no luck about some code of his...


I haven't heard from him either. Both Nach and pagefault tend to disappear for months on end sometimes, though. Hard to say if anything is wrong or not. I certainly hope not.

Quote:
ok, I've definitely chosen the wrong wording and it's not public domain (even if, since he started working on his emu, byuu himself defined Public Domain bsnes source for quite some time wink )


It's kind of complicated. I defined all the special chip stuff as PD (except the modules I didn't write myself), but that was prior to SFX/SA1 support.

I don't mind if MAME or MESS use those cores, at any rate. In fact, I encourage it. If you guys use it, and then spot a bug, please let me know and we both end up benefiting. No need to reinvent the wheel, we aren't competing after all.

Quote:
Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it.


Ironically, the Windows port is the worst version of Qt. The OS X version is pre-compiled, and the Linux version is even easier: a single apt-get command.

Quote:
I'm trying to do a side-by-side execution comparison between bsnes and MESS


The timing differences will make it very hard to compare line-by-line, but be aware of the disasm modules for all of my cores. You will have to hook calls to it yourself in the ::enter() routines, and put the data in files yourself. v048 may be better, it had part of a tracing interface. I'm in the process of redoing that for a debugger as of v049+, so it will be harder to work with there.
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 06:14 PM
Originally Posted By byuu
Not at all, sorry. For me, horrible crashing was usually due to opcode bugs, and I haven't had any of the other issues.

Are you handling IRQ communications between chips properly? Eg the GSU STOP command and such.


I think so:

Code:
  775              case 0x00: // STOP
  776                  if(!(cpustate->cfgr & SUPERFX_CFGR_IRQ))
  777                  {
  778                      cpustate->sfr |= SUPERFX_SFR_IRQ;
  779                      cpustate->irq = 1;
  780                  }
  781                  cpustate->sfr &= ~SUPERFX_SFR_G;
  782                  cpustate->pipeline = 0x01;
  783                  superfx_regs_reset(cpustate);
  784                  break;


It makes perfect sense for the IRQ flag to be set in SFR, but I wasn't able to track down where exactly the "irq" class member variable is used. It doesn't appear to have a purpose inside your Super FX core, and I didn't find anything referring to it in the rest of the emulator. Is this true?

Originally Posted By byuu
Quote:
Basically, what I want to know is: if the SuperFX reads from a SuperFX memory address of 0x712345, does it actually read from index 0x2345 in the FX RAM buffer? If the S-CPU reads from 0x356789, is this the same as a read from 0x306789, which itself is a read from index 0x789 in the FX RAM buffer (due to mirroring)?


I would strongly advise you to handle the mirroring properly (per my map on the previous page.) But I couldn't say for sure, mirroring was one of the first things I did.


No offense intended, but that was the entire reason why I asked those two questions. smile

I'm still having some trouble wrapping my head around where, exactly, a given byte write to a given address by the S-CPU goes in relation to what the SuperFX chip then gets back. Those two questions were carefully designed such that, when answered correctly, will give me most of the info I need to do that.

I'd hazard a guess that I probably have the mirroring correct now, though, or there would be far worse problems, since SRFX and Vortex are at least drawing most of their triangles, and SF is now drawing line "primitives" (but not triangles).

Originally Posted By byuu
Quote:
Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it.


Ironically, the Windows port is the worst version of Qt. The OS X version is pre-compiled, and the Linux version is even easier: a single apt-get command.


Are there no pre-compiled binaries of Qt 4.5.2 anywhere? frown

Originally Posted By byuu
Quote:
I'm trying to do a side-by-side execution comparison between bsnes and MESS


The timing differences will make it very hard to compare line-by-line, but be aware of the disasm modules for all of my cores. You will have to hook calls to it yourself in the ::enter() routines, and put the data in files yourself. v048 may be better, it had part of a tracing interface. I'm in the process of redoing that for a debugger as of v049+, so it will be harder to work with there.


The timing differences are immaterial, as I would only be logging the opcodes executed by the Super FX chip. Also, I'm not interested in a diassembly, I'm interested in actually printf-ing the full register state after every single opcode, using some format like:

Code:
 R0=0000  R1=1111  R2=2222  R3=333
 R4=4444  R5=5555  R6=6666  R7=7777
 R8=8888  R9=9999 R10=aaaa R11=bbbb
R12=cccc R13=dddd R14=eeee R15=ffff
 DR=0     SR=0    SFR=0000


...and then make MESS output exactly the same thing. It'll produce a gigantic log file, probably a number of gigs in size, but that's not an intractible problem, I'd just use a binary diff program rather than visually diffing.

Trust me, this is how we tend to do things with MAME and MESS. smile
Posted By: Stiletto Re: The SNES WIP topic - 09/02/09 06:27 PM
Originally Posted By Just Desserts
Are there no pre-compiled binaries of Qt 4.5.2 anywhere? frown


Eh? http://qt.nokia.com/downloads

Is byuu modifying Qt or something? I'm not familiar with his makefile...
Posted By: R. Belmont Re: The SNES WIP topic - 09/02/09 06:30 PM
Yeah, the libs come in the download for Windows, I'm not sure what the issue is smile
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 06:51 PM
To be fair, you guys'd get pretty pissed if users just started downloading random crap off the Internet and then complaining about how they can't compile MESS, when there are guides around that supposedly tell you exactly how to compile it. In this case, http://board.byuu.org/viewtopic.php?f=3&t=74

ETA: For what it's worth, "configure" does seem to be working, it's just taking a long time to configure everything. I think it took about 10 minutes to get through network.pro, and that's on a 1.86GHz Core 2 Duo. frown
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 09:23 PM
Aha. Since LDW/LDB/STW/STB were changed to shunt around memory buffering for testing purposes, they weren't setting cpustate->ramaddr. SBK relies on cpustate->ramaddr. Now that they set ramaddr properly, there's a slightly larger amount of happiness:

The firework particles at the beginning of Vortex now show up properly:



Also, Stunt Race FX is considerably improved, including the tires now rotating the right direction on the car-select screen, and actually being able to get in-game and play. There are still some issues, though: The cars keep "popping" upward in the car-select screen, and bits of the scene geometry keep dropping out.









Posted By: byuu Re: The SNES WIP topic - 09/02/09 11:01 PM
Quote:
I wasn't able to track down where exactly the "irq" class member variable is used


regs.sfr.irq is used by the SuperFX MMIO registers at $30xx. cpu.regs.irq is checked by the S-CPU core (in timing.cpp IIRC) to trigger an external IRQ event.

Quote:
No offense intended, but that was the entire reason why I asked those two questions.


I can't answer your question in that case frown
I'd rather not break the mirroring in my own emulator to see what happens, heheh. Anyway, sounds like you got most of it figured out now, hoorah!

Quote:
Are there no pre-compiled binaries of Qt 4.5.2 anywhere?


You'll need them to be for GCC 4.x as well. For whatever reason, last I checked Qt was only officially supporting 3.x. But it still builds fine with 4.x anyway.

Quote:
The timing differences are immaterial, as I would only be logging the opcodes executed by the Super FX chip. Also, I'm not interested in a diassembly, I'm interested in actually printf-ing the full register state after every single opcode, using some format like:


You never know, if it loops polling a value from the CPU to be set, the logs won't line up.

Then again, I was using FuSoYa's closed-source Snes9X SFX tracer (don't want anyone stealing those fprintf statements I guess) and generating ~40MB worth of logs to compare to. A warning if you do, there's a bug somewhere in his tracer, I think it was involving ROMB. If you run DOOM with the tracer on, all the graphics get corrupted.

And my disasm thing spits out the register values as well. But you may as well dump them in binary format or whatever.

Well, whatever works for you. Just mentioning it.

Quote:
ETA: For what it's worth, "configure" does seem to be working, it's just taking a long time to configure everything.


Yeah, it's a huge library. Very slow to build. The tutorial thing on my page lets you turn a lot of stuff off, I can usually configure and build in about ~15 minutes with it.

Quote:
Aha. Since LDW/LDB/STW/STB were changed to shunt around memory buffering for testing purposes, they weren't setting cpustate->ramaddr. SBK relies on cpustate->ramaddr.


Ah, I remember that. Took quite a while to figure it out.

Looks like progress is coming along great. Let me know when SMW2 is working good. I'd like you to test something.

---

Anyway, sign up at my forum and post your user name here. I'll give you access to the dev forum. You can do searches for SuperFX and find some common bugs + fixes from me and Jonas Quinn.
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 11:39 PM
Originally Posted By byuu
Quote:
I wasn't able to track down where exactly the "irq" class member variable is used


regs.sfr.irq is used by the SuperFX MMIO registers at $30xx. cpu.regs.irq is checked by the S-CPU core (in timing.cpp IIRC) to trigger an external IRQ event.

Quote:
No offense intended, but that was the entire reason why I asked those two questions.


I can't answer your question in that case frown
I'd rather not break the mirroring in my own emulator to see what happens, heheh. Anyway, sounds like you got most of it figured out now, hoorah!

Quote:
Are there no pre-compiled binaries of Qt 4.5.2 anywhere?


You'll need them to be for GCC 4.x as well. For whatever reason, last I checked Qt was only officially supporting 3.x. But it still builds fine with 4.x anyway.

Quote:
The timing differences are immaterial, as I would only be logging the opcodes executed by the Super FX chip. Also, I'm not interested in a diassembly, I'm interested in actually printf-ing the full register state after every single opcode, using some format like:


You never know, if it loops polling a value from the CPU to be set, the logs won't line up.

Then again, I was using FuSoYa's closed-source Snes9X SFX tracer (don't want anyone stealing those fprintf statements I guess) and generating ~40MB worth of logs to compare to. A warning if you do, there's a bug somewhere in his tracer, I think it was involving ROMB. If you run DOOM with the tracer on, all the graphics get corrupted.

And my disasm thing spits out the register values as well. But you may as well dump them in binary format or whatever.

Well, whatever works for you. Just mentioning it.

Quote:
ETA: For what it's worth, "configure" does seem to be working, it's just taking a long time to configure everything.


Yeah, it's a huge library. Very slow to build. The tutorial thing on my page lets you turn a lot of stuff off, I can usually configure and build in about ~15 minutes with it.

Quote:
Aha. Since LDW/LDB/STW/STB were changed to shunt around memory buffering for testing purposes, they weren't setting cpustate->ramaddr. SBK relies on cpustate->ramaddr.


Ah, I remember that. Took quite a while to figure it out.

Looks like progress is coming along great. Let me know when SMW2 is working good. I'd like you to test something.

---

Anyway, sign up at my forum and post your user name here. I'll give you access to the dev forum. You can do searches for SuperFX and find some common bugs + fixes from me and Jonas Quinn.


Registered, as my typical MG handle.

I've been doing some investigation of the polygon drop-out in Vortex, it seems like the color that it's getting via either GETC or COLOR is messed up. frown
Posted By: Just Desserts Re: The SNES WIP topic - 09/02/09 11:55 PM
Argh, I'm a dumbass. It just now clicked that "regs" contains the SuperFX registers, but "cpu.regs" corresponds to the S-CPU registers. Grah.

ETA: Hmm, no. No, hooking up the S-CPU IRQ didn't seem to actually affect anything.

ETA2: Dammit, I reimplemented RAM and ROM buffering based on bsnes's spec, and it also isn't affecting anything. At least we're narrowing things down here.

ETA3: byuu, do you have a copy of this? bsnes_v046_wip13.tar.bz2
Posted By: Just Desserts Re: The SNES WIP topic - 09/03/09 05:06 AM
As it turns out, HIB checks against 0x80 for the sign bit and not 0x8000. Oops.

There are clearly still some problems lurking, as all games suffer from random culling and Z-buffering issues, but now Star Fox is ostensibly playable, and Vortex is not far behind once I hook up some mirrors:





















More pics, not inlined because UBB is lame:

http://moogle-tech.com/mess/superfx/9-3-2009/sf10.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf11.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf12.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf13.png
http://moogle-tech.com/mess/superfx/9-3-2009/sf14.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex6.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex7.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex8.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex9.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex10.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex11.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex12.png
http://moogle-tech.com/mess/superfx/9-3-2009/vortex13.png
Posted By: etabeta78 Re: The SNES WIP topic - 09/03/09 06:09 AM
cool!
Posted By: byuu Re: The SNES WIP topic - 09/03/09 07:25 AM
Quote:
ETA: Hmm, no. No, hooking up the S-CPU IRQ didn't seem to actually affect anything.


Argh, thought it was more important. It has to be used *somewhere* ... hmm. I know the SA-1 games use almost every last feature (except timer IRQs). Some features are used by only one game.

The SA-1 is better for adding little by little. Just cloning the S-CPU core is enough to get almost half the titles running, had that up in a day.

Quote:
ETA2: Dammit, I reimplemented RAM and ROM buffering based on bsnes's spec, and it also isn't affecting anything. At least we're narrowing things down here.


That one had a big impact on timing in Winter Gold for me. All the skiers were flickering before I added it.

Quote:
ETA3: byuu, do you have a copy of this? bsnes_v046_wip13.tar.bz2


Sure, I have everything from v019 and above. Accidentally formatted the hard drive with the earlier versions.

http://byuu.org/temp/bsnes_v046_wip13.tar.bz2

Quote:
As it turns out, HIB checks against 0x80 for the sign bit and not 0x8000. Oops.


Ah, so then you aren't using copy/paste for your opcode core. Perhaps I'll do a once over tomorrow to see if I can spot anything obvious.

You should try some SuperFX2 games. The only difference is the memory timing.

Overall, looking really good!
Posted By: Just Desserts Re: The SNES WIP topic - 09/03/09 02:31 PM
Originally Posted By byuu
Quote:
As it turns out, HIB checks against 0x80 for the sign bit and not 0x8000. Oops.


Ah, so then you aren't using copy/paste for your opcode core. Perhaps I'll do a once over tomorrow to see if I can spot anything obvious.


Awesome, thanks! And that's correct, I'm not doing a direct copy/paste. I'm pretty much looking at your code and translating it to MAME-ese on the fly, but every so often I'll inadvertantly miss something. smile

Originally Posted By byuu
You should try some SuperFX2 games. The only difference is the memory timing.


Unfortunately, none of them boot in MESS, presumably because of cart mapping issues. Neither Doom nor SMW2 even attempt to access the SuperFX chip before hanging.

Originally Posted By byuu
Overall, looking really good!


Thanks, and thank you for writing such a good reference emulator! smile
Posted By: Stiletto Re: The SNES WIP topic - 09/03/09 03:24 PM
Originally Posted By Stiletto
Originally Posted By Just Desserts
I have your S-DD1 and S-RTC implementations ported over, but neither of them currently work, and I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip? I'd be surprised if the cart didn't just use a stock RTC from some third-party manufacturer, for which datasheets exist.


I'd be willing to look, if I can get a decent PCB scan for SHVC-AE6J-JPN.


What, no love?

- Stiletto
Posted By: byuu Re: The SNES WIP topic - 09/03/09 03:41 PM
Hmm, I don't have an SVN tool on this work machine. All I can see is this: http://git.toseciso.org/?p=mess.git;a=summary

Where might I find the latest SuperFX code?
Posted By: R. Belmont Re: The SNES WIP topic - 09/03/09 03:45 PM
He doesn't have it checked in to MESS, so you couldn't see it there anyway.
Posted By: Just Desserts Re: The SNES WIP topic - 09/03/09 03:48 PM
Originally Posted By byuu
Hmm, I don't have an SVN tool on this work machine. All I can see is this: http://git.toseciso.org/?p=mess.git;a=summary

Where might I find the latest SuperFX code?


Ah, right. As a rule, I've been submitting my SuperFX core changes to the private MAME revision-control server, since CPU cores are considered to be part of MAME. Now that I have Star Fox mostly working, I'll package up all of my changes, including the SNES-side ones, and submit them to the MESS tree so that you can get at them. smile

Edit: You know what would be funny as hell? A Z80-based system that used a SuperFX chip. Given the way I have the IRQ line callback implemented (thanks to RB for the suggestion), it would be a trivial matter to put one together in MESS just for kicks. smile
Posted By: R. Belmont Re: The SNES WIP topic - 09/03/09 06:53 PM
Better: an NES mapper and a full-on Chinese Starfox ripoff in the style of those (arguably amazing) Donkey Kong Country ripoffs.
Posted By: Jonathan Wilson Re: The SNES WIP topic - 09/03/09 11:37 PM
I am surprised no-one put any kind of extra processing power into a NES mapper, we saw extra sound added (VRC7 etc).
Posted By: Just Desserts Re: The SNES WIP topic - 09/03/09 11:44 PM
Originally Posted By R. Belmont
Better: an NES mapper and a full-on Chinese Starfox ripoff in the style of those (arguably amazing) Donkey Kong Country ripoffs.


My god, that would actually be doable. The SuperFX normally has access to the SNES's bus, but there's nothing to say you couldn't just wire its bus up to a CPLD, which then arbitrates between it and a couple of roms, between it and some RAM, and between the 6502 and some RAM.

The only issue I can think of is that tilemap indices on the NES can only be from 00 to FF, but a full 256x240 buffer would require a full 10 bits, from 000 to 3FF. frown
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/03/09 11:48 PM
Originally Posted By Jonathan Wilson
I am surprised no-one put any kind of extra processing power into a NES mapper, we saw extra sound added (VRC7 etc).


The unreleased color dreams 'hellraiser' cart had a z80 on it. It suffered from excessive cost due to z80 and extra memory on it, and had timing issues and vram contention issues. It supposedly was a fairly awesome wolf3d style shooter though, iirc.

LN
Posted By: Just Desserts Re: The SNES WIP topic - 09/04/09 12:49 AM
It's been checked into SVN, enjoy.
Posted By: byuu Re: The SNES WIP topic - 09/04/09 01:55 AM
Quote:
Edit: You know what would be funny as hell? A Z80-based system that used a SuperFX chip.


Hah, screw enslavement. Isn't proper abstraction fun? When I first started on SA-1 support, I made it inherit from the S-SMP core instead of the S-CPU core for fun. But there's not much practical use for a 21MHz SPC700 smirk

Quote:
It's been checked into SVN, enjoy.


Wow. I can't believe you ported Andreas' C++ S-DD1 classes to C. I didn't want to mess with that at all. Disappointed about using the system time for the S-RTC, but oh well. It's more of a preference than anything else. You will need to add a hack to pass the SPC7110 test like ZSNES in that case. It sets the time and then checks it a second later to make sure it's incrementing properly. Initializing the last 16-bytes of SRAM to "SPC7110 CHECK OK" will work.

SuperFX, wow. You had to rewrite almost all of it. Sucks not having references and overloaded operators in C, but I don't want to start a language war so I'll shut up. Very impressive how fast you put that together. And I see you dodged all the common mistakes I made impeccably.

My biggest mistakes were not realizing that SREG and DREG are sometimes the same, and clobbering them before getting flag states and such; and screwing up the pipeline fetching, but those look pretty good with your code.

Glad you were able to avoid the messiness of the Snes9X core's faux-pipeline trickery in every single opcode and automate it as I have.
Posted By: Just Desserts Re: The SNES WIP topic - 09/04/09 02:08 AM
Originally Posted By byuu
Wow. I can't believe you ported Andreas' C++ S-DD1 classes to C. I didn't want to mess with that at all. Disappointed about using the system time for the S-RTC, but oh well. It's more of a preference than anything else. You will need to add a hack to pass the SPC7110 test like ZSNES in that case. It sets the time and then checks it a second later to make sure it's incrementing properly.


Ahh, I probably should have put a comment at the top of both the S-RTC and S-DD1 files containing a massive disclaimer that none of the code contained within actually works. Now that you explained how S-RTC works, I'll be redoing it to be more like your code, and currently neither SFA2 nor Star Ocean boot. frown

I'm trying to debug S-DD1 right now, actually. I'll have a trace of what it's doing posted up here shortly.

Originally Posted By byuu
SuperFX, wow. You had to rewrite almost all of it. Sucks not having references and overloaded operators in C, but I don't want to start a language war so I'll shut up. Very impressive how fast you put that together. And I see you dodged all the common mistakes I made impeccably.

My biggest mistakes were not realizing that SREG and DREG are sometimes the same, and clobbering them before getting flag states and such; and screwing up the pipeline fetching, but those look pretty good with your code.

Glad you were able to avoid the messiness of the Snes9X core's faux-pipeline trickery in every single opcode and automate it as I have.


Ah, I only dodged the mistakes because you made them first, and I thank you for that. I couldn't have done it anywhere near as cleanly or as quickly without being able to use your code, so hats off to you for writing such a great emulator to begin with!
Posted By: R. Belmont Re: The SNES WIP topic - 09/04/09 02:14 AM
Originally Posted By Stiletto
Originally Posted By Stiletto


I'd be willing to look, if I can get a decent PCB scan for SHVC-AE6J-JPN.


What, no love?


http://snesemu.black-ship.net/misc/hardware/RTC.png
Posted By: R. Belmont Re: The SNES WIP topic - 09/04/09 04:27 AM
I helped debug some SuperFX issues, and we're doing better now...







Posted By: Just Desserts Re: The SNES WIP topic - 09/04/09 04:44 AM
And another fix (clearing the high bit of PBR and ROMBR on set) gets the Voxel demo showing things, though very obviously wrong things:







Posted By: Justin Re: The SNES WIP topic - 09/04/09 05:03 AM
I love waiting for cool things to happen laugh
Posted By: Anna Wu Re: The SNES WIP topic - 09/04/09 05:33 AM
I am impressed. blush
Posted By: Waremonger Re: The SNES WIP topic - 09/04/09 06:00 AM
I don't know about everyone else but I enjoy these WIP posts more than I like playing the games. Big thanks to everyone involved (for work done on all the drivers, not just this one). Sorry to intrude! [/lurk]
Posted By: Shideravan Re: The SNES WIP topic - 09/04/09 04:15 PM
A new regression in SMW, in the first boss, the background corrupts:

Posted By: byuu Re: The SNES WIP topic - 09/04/09 04:35 PM
Quote:
And another fix (clearing the high bit of PBR and ROMBR on set) gets the Voxel demo showing things, though very obviously wrong things:


Oh hey, thanks! That one never worked in bsnes, but I tend not to debug PD ROMs for sanity reasons. 19 times out of 20, they tend to have the same problem on hardware.

But yeah, masking PBR and ROMBR to 7-bits fixed it.

The last visible bug I'm aware of is this:



If you start Super Mario World 2 V1.1 (U), and hold down the start button immediately and keep it down, it skips the island rotation (normal), but it also seems to "interlace" the logo (obviously not normal.)

Seems to be timing related, disabling my pixel cache delays fixes it but throws off Winter Gold. I really don't understand how the pixel cache works. Does a single SFX RAM access while its emptying stall until the entire cache is empty, do they interleave accesses, or does it just stall the pixel cache for one GSU write cycle? Meh.

Even with ROM buffer + RAM buffer + instruction cache + primary and secondary pixel cache + multiplier speed select support, timing in bsnes is still off from the real thing by about ~10% or so. Noticeable by music in certain scenes ending too early.

Quote:
I helped debug some SuperFX issues, and we're doing better now...


I almost want to say the Yoshi's Island scrambledness looks familiar ... but I can't think of anything at the moment.
Posted By: Just Desserts Re: The SNES WIP topic - 09/04/09 05:15 PM
Originally Posted By Shideravan
A new regression in SMW, in the first boss, the background corrupts:



Was this regression introduced specifically with the changes that I checked in? A specific revision number would rock.
Posted By: R. Belmont Re: The SNES WIP topic - 09/04/09 05:22 PM
I forgot that Winter Gold existed. I added PAL + SuperFX capability and here's what it does (which is basically a cheesy 3d skiing game with a ripoff of the groundbreaking Amiga demo "State of the Art" wrapped around it).




Posted By: byuu Re: The SNES WIP topic - 09/04/09 05:29 PM
The racers flickering in Winter Gold is due to timing. It's extremely sensitive, and very tiny changes often break the graphics again on me.

EDIT: finished checking all of MESS' opcodes against mine, I don't see any errors. Ah well, either I'm overlooking them as well or they lie in the S-CPU core.
Posted By: Just Desserts Re: The SNES WIP topic - 09/04/09 07:00 PM
Originally Posted By byuu
The racers flickering in Winter Gold is due to timing. It's extremely sensitive, and very tiny changes often break the graphics again on me.

EDIT: finished checking all of MESS' opcodes against mine, I don't see any errors. Ah well, either I'm overlooking them as well or they lie in the S-CPU core.


I dunno, I'd say both have similar likelihoods. I'd like to say it's the S-CPU core, but I know perfectly well that I visually scoured my SuperFX implementation 10+ times before I discovered my HIB typo. smile
Posted By: Kale Re: The SNES WIP topic - 09/04/09 07:48 PM
Originally Posted By Just Desserts
Originally Posted By Shideravan
A new regression in SMW, in the first boss, the background corrupts:



Was this regression introduced specifically with the changes that I checked in? A specific revision number would rock.


It's an old regression, I've even posted an inp during this topic...
Posted By: Multipass Re: The SNES WIP topic - 09/05/09 12:04 AM
Hello all,
Sorry but i need some help, i want to compil lastest svn snes driver, but i have some errors:

Compiling src/mess/drivers/snes.c...
src/mess/drivers/snes.c:56: error: 'superfx_r_bank1' undeclared here (not in a function)
src/mess/drivers/snes.c:56: error: 'superfx_w_bank1' undeclared here (not in a function)
src/mess/drivers/snes.c:57: error: 'superfx_r_bank2' undeclared here (not in a function)
src/mess/drivers/snes.c:57: error: 'superfx_w_bank2' undeclared here (not in a function)
src/mess/drivers/snes.c:58: error: 'superfx_r_bank3' undeclared here (not in a function)
src/mess/drivers/snes.c:58: error: 'superfx_w_bank3' undeclared here (not in a function)
src/mess/drivers/snes.c:239: error: 'snes_extern_irq_w' undeclared here (not in a function)
src/mess/drivers/snes.c:239: error: initializer element is not constant
src/mess/drivers/snes.c:239: error: (near initialization for 'snes_superfx_config.out_irq_func.writeline')
mingw32-make: *** [obj/windows/mamep/mess/drivers/snes.o] Error 1

Please, someone know how to make for the correct issue? More thanks
Posted By: Duke Re: The SNES WIP topic - 09/05/09 12:44 AM
Make sure you do a clean compile.
Posted By: Just Desserts Re: The SNES WIP topic - 09/05/09 04:40 AM
Originally Posted By Just Desserts
I know perfectly well that I visually scoured my SuperFX implementation 10+ times before I discovered my HIB typo. smile


What'd I say? What did I say?

Turns out I was clearing CY when I was clearing OV, S and Z at the start of the handler for ADD/ADC/ADDI/ADCI and SUB/SBC/SUBI/SBCI. As a result, ADC/ADCI/SBC/SBCI were behaving the same as their carry-free equivalents. That's bad.

Images, part 1/2:

Star Fox, fixes planet coloration and late culling of mothership components as it flies on-screen in the intro:




Doom, fixes everything except the massive flickering:















Posted By: Just Desserts Re: The SNES WIP topic - 09/05/09 04:41 AM
Part 2/2:

Dirt Trax FX, fixes the fact that it was only displaying half the polygons:








Voxel Demo, fixes rendering:




Vortex, fixes Z-buffering:




Edit: I'm going to go out on a limb here and say that the remaining issues in Yoshi's Island are NOT SuperFX-related. This is just based on the fact that things like the pause screen work perfectly, and the garbled graphics that are being displayed are being displayed in tiles, and using tile sets the SuperFX would not have available to it. In that case, over to you, Kale. smile
Posted By: byuu Re: The SNES WIP topic - 09/05/09 06:30 AM
Quote:
What'd I say? What did I say?

Turns out I was clearing CY when I was clearing OV, S and Z at the start of the handler for ADD/ADC/ADDI/ADCI and SUB/SBC/SUBI/SBCI.


>_<
Man, I positively suck at bug hunting. I was even looking for exactly that kind of bug. I saw the r = sreg part and totally ignored the clear carry right below it. Glad you figured it out, at least!
Posted By: Kale Re: The SNES WIP topic - 09/05/09 01:30 PM
Originally Posted By Just Desserts

Edit: I'm going to go out on a limb here and say that the remaining issues in Yoshi's Island are NOT SuperFX-related. This is just based on the fact that things like the pause screen work perfectly, and the garbled graphics that are being displayed are being displayed in tiles, and using tile sets the SuperFX would not have available to it. In that case, over to you, Kale. smile


Try to use the usual -cheat trick by lowering the main CPU clock speed to 50% on the bootstrap routine (i.e. pause just after the MESS disclaimer and do the downclock) and see if things improves...if it's the case then it's yet another "timing that needs cycle accurate" issue
Posted By: Just Desserts Re: The SNES WIP topic - 09/05/09 04:53 PM
Originally Posted By Kale
Try to use the usual -cheat trick by lowering the main CPU clock speed to 50% on the bootstrap routine (i.e. pause just after the MESS disclaimer and do the downclock) and see if things improves...if it's the case then it's yet another "timing that needs cycle accurate" issue


No luck, lowering the main CPU clock to 50% didn't help. :|
Posted By: Curt Coder Re: The SNES WIP topic - 09/05/09 06:18 PM
Compilation on 64-bit fails:

src\mame\machine/snesrtc.c(165) : warning C4305: '+=' : truncation from 'int' to 'UINT8'
src\mame\machine/snessdd1.c(680) : warning C4333: '>>' : right shift by too large amount, data loss
src\emu\cpu\superfx\superfx.c(537) : warning C4098: 'superfx_mmio_write' : 'void' function returning a value
Posted By: Stiletto Re: The SNES WIP topic - 09/05/09 06:46 PM
Originally Posted By R. Belmont
Originally Posted By Stiletto
Originally Posted By Stiletto


I'd be willing to look, if I can get a decent PCB scan for SHVC-AE6J-JPN.


What, no love?


http://snesemu.black-ship.net/misc/hardware/RTC.png


Ah, I knew I had seen a website like that around somewhere.

Sadly, this will really require parametric search capabilities (like what is offered at Partminer) - RTC chip, made by Sharp, DIP-24 package. If it exists other than a one-off. Tough stuff.

- Stiletto
Posted By: byuu Re: The SNES WIP topic - 09/05/09 06:51 PM
Quote:
src\emu\cpu\superfx\superfx.c(537) : warning C4098: 'superfx_mmio_write' : 'void' function returning a value


That one's my fault. C++ allows you to do:
void B() {}
void A() { return B(); }

Which was added to facilitate templates and such. I often use it in non-template areas, especially when it means you can omit {} around a conditional.
Posted By: R. Belmont Re: The SNES WIP topic - 09/05/09 07:28 PM
I'd be really surprised if the RTC wasn't something off-the-shelf.
Posted By: R. Belmont Re: The SNES WIP topic - 09/05/09 08:05 PM
64-bit MSVC, I assume? I'm not seeing any of those errors on 64-bit SDLMESS, although the first two at least are real and spectacular ;-)

gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
Posted By: Curt Coder Re: The SNES WIP topic - 09/05/09 08:37 PM
Yep, 64-bit MSVC. But those seem to be quite valid complaints.

Warning 1: UINT8 + 1000 (it should be UINT16 at least)
Warning 2: UINT16 >> 20, which is always 0.

I fixed them locally and disabled the TMS57002 cpu core (it gives a seizure to cl.exe with a 256K lines long source file)

The compilation dies finally at this point:

Linking vmessuid.exe...
LIBCMTD.lib(wcrt0.obj) : error LNK2019: unresolved external symbol wmain referenced in function __tmainCRTStartup
vmessuid.exe : fatal error LNK1120: 1 unresolved externals
make: *** [vmessuid.exe] Error 1120

What on earth does that mean?
Posted By: Darkstar Re: The SNES WIP topic - 09/05/09 10:11 PM
Normally this means either that some parts of the source were compiled with #define UNICODE while others were not, or that something is wrong with the application type (Windows app vs. Console app).
Or maybe your prototype of wmain() is wrong (some arguments have the wrong type)

Explanation: __tmainCRTStartup is the main entry point for the runtime library. It is a combined ANSI/Unicode function (the "t" from "tmain") and it calls the unicode version of main() which on Windows is called wmain()

HTH,
-Darkstar
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/06/09 05:43 AM
Quote:

Sadly, this will really require parametric search capabilities (like what is offered at Partminer) - RTC chip, made by Sharp, DIP-24 package. If it exists other than a one-off. Tough stuff.

- Stiletto


SDIP-24 package, not DIP-24. note the pin spacing.
Edit: could it be an MC146818 clone (same rtc used in ibm at)?

LN
Posted By: Kale Re: The SNES WIP topic - 09/07/09 10:59 PM
What could cause the following artifact in Ikari no Yousai (J) in MESS AND in my testing SNES PAL with Jap adapter (yeah, looks odd but it's like it) but doesn't in bsnes/snes9x?
(it's after you beat the first mini-boss)



http://mamedev.emulab.it/kale/fast/files/iny.jpg
Posted By: R. Belmont Re: The SNES WIP topic - 09/07/09 11:12 PM
Running a (J) cart on a PAL machine's going to have almost as many timing problems as MESS.
Posted By: Kale Re: The SNES WIP topic - 09/07/09 11:19 PM
Ah, good, so it's not broken then wink

I do wonder about the vertical stripes anyway...hits sprite limit perhaps?
Posted By: Kale Re: The SNES WIP topic - 09/09/09 05:40 PM
r5660 /src/emu/cpu/g65816/g65816op.h: [G65816]: Fixed a bug with SBC opcode N flag behaviour in Decimal Mode

This fixes The Mask life status behaviour, it was causing instant deaths if there was a 4xx -> 3xx transition. Probably fixes a bunch of other gameplay quirks as well in other two or three games...

Posted By: R. Belmont Re: The SNES WIP topic - 09/09/09 06:25 PM
Wait, something actually uses decimal mode? smile

ETA: when fixing 65816 core bugs, please also check if the M377xx has the same problem - it's mostly but not entirely 65816 compatible (no emulation mode, 2 accumulators via a prefix opcode, and a MUL instruction) and is based on the 65816 core.
Posted By: Stiletto Re: The SNES WIP topic - 09/10/09 05:27 AM
Originally Posted By Lord Nightmare
Quote:

Sadly, this will really require parametric search capabilities (like what is offered at Partminer) - RTC chip, made by Sharp, DIP-24 package. If it exists other than a one-off. Tough stuff.

- Stiletto


SDIP-24 package, not DIP-24. note the pin spacing.
Edit: could it be an MC146818 clone (same rtc used in ibm at)?


Good point, on both counts. I'll look into it later (at least as far as I can usually do things...)
Posted By: etabeta78 Re: The SNES WIP topic - 09/10/09 07:20 AM
As of svn 5666, MESS supports DSP3 & DSP4 emulation. Many thanks to Nach and the ZSNES team for the permission to use their code in MAME & MESS.

The code also includes some recent fixes to DSP4 (maybe the same ones mentioned by byuu in his Sep 7th news, but I'm not 100% sure)

While I'm proud of the fact that MESS is the first emulator to include this fix in a public release, it's actually hard to notice because of graphical corruptions which make Top Gear 3000 unplayable. smile

Moreover, we also got permission for the CX4 emulation which will be included soonish and it's working fine. This makes us 3 chips closer to the goal wink
Posted By: byuu Re: The SNES WIP topic - 09/10/09 04:14 PM
Quote:
Wait, something actually uses decimal mode?


My understanding is that the N and Z flag calculations are identical in both regular and decimal modes. However, grinvader advises that the V flag calculation may be different. I have no idea about the C flag. Need to generate some log files to be sure, but all my hardware dev stuff is boxed up at the moment.

Quote:
While I'm proud of the fact that MESS is the first emulator to include this fix in a public release


That's a pretty bold thing to brag about. "We're the first to publicly include someone else's fix for someone else's chip emulator."

Jonas Quinn should be getting the credit for the fix here, not MESS.

Pet peeve of mine. People fought about who added Andreas Naive's S-DD1 support first (ZSNES publicly, Snes9X privately), whoever it is on Wikipedia bragging about me including neviksti's SPC7110 support first, and so on. Releasing new builds faster than someone else isn't much to brag about. Andreas, neviksti and Jonas deserve that praise, not us for copying and pasting.

Saying such things eggs on the general public to think we're all competing against each other.

Quote:
This makes us 3 chips closer to the goal


ST011 and ST018 will be quite a bit tougher wink

Both will require major reverse engineering research and testing, several thousand man hours a piece. And each one only runs one subpar Shougi game. But they're both needed to claim true 100% compatibility.

We could definitely use some help there. Most of the people who worked to emulate all these obscure chips have all but left the scene.
Posted By: Just Desserts Re: The SNES WIP topic - 09/10/09 05:41 PM
Originally Posted By byuu
That's a pretty bold thing to brag about. "We're the first to publicly include someone else's fix for someone else's chip emulator."

Jonas Quinn should be getting the credit for the fix here, not MESS.

Pet peeve of mine. People fought about who added Andreas Naive's S-DD1 support first (ZSNES publicly, Snes9X privately), whoever it is on Wikipedia bragging about me including neviksti's SPC7110 support first, and so on. Releasing new builds faster than someone else isn't much to brag about. Andreas, neviksti and Jonas deserve that praise, not us for copying and pasting.

Saying such things eggs on the general public to think we're all competing against each other.


Relaaaaaaaax. Everyone is getting proper credit in whatever code is being checked into SVN. The message board is a more informal place, where I thought we were all above squabbling over l33t sk3n3 cr3dz.
Posted By: R. Belmont Re: The SNES WIP topic - 09/10/09 06:40 PM
Everyone has proper credit in the actual source. Also, I thought only dumpers had pointless flame wars about credits.

Andreas Naive is busy decrypting the Naomi protection ASIC and anyone who distracts him for SNES will face my (and Cah4e3's) wrath wink

As far as ST001x, they're probably stranger than you can possibly imagine. Seta are the people who made an arcade Shougi game based on a Z80 with an R3000 as the AI coprocessor. And an arcade golf game based on a Z80 with an R3000 as a polygon renderer. I guess the smart money is that those chips might be or contain an R3000 smile
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/10/09 06:59 PM
iirc dox said the st-018 is an nec v-something w/on die rom.
But the st-011 is the same as the st-010: a custom gate array with a z80 or z80-like core tacked onto it, plus ram and rom; stiletto looked it up.
Since its manufactured by sharp its possible the z80-like core matches the gameboy cpu's on-die core, so if we get the roms decapped, we may be able to pretty much drop them in...

LN
Posted By: Haze Re: The SNES WIP topic - 09/10/09 07:00 PM
Originally Posted By R. Belmont
Everyone has proper credit in the actual source. Also, I thought only dumpers had pointless flame wars about credits.

Andreas Naive is busy decrypting the Naomi protection ASIC and anyone who distracts him for SNES will face my (and Cah4e3's) wrath wink

As far as ST001x, they're probably stranger than you can possibly imagine. Seta are the people who made an arcade Shougi game based on a Z80 with an R3000 as the AI coprocessor. And an arcade golf game based on a Z80 with an R3000 as a polygon renderer. I guess the smart money is that those chips might be or contain an R3000 smile


Actually they use a V810 for the Shougi AI.

They do this on a V60 based system (SSV) with 'jsk' Joryuu Syougi Kyoushitsu

and on a ST0016(Z80 core) based system with Mayjinsen and Mayjinsen 2.

The V810 program differs on each game, but they're interchangable, probably just improved / bugfixed / optimized AI between versions.

According to Dox there are also physical (wooden) Shougi boards / computers which use a v810, and probably the same AI software as was used on the arcade games. (which is probably why Seta used it, a proven AI that they didn't have to develop)

It wouldn't surprise me if one of the SNES chips was actually a V810, maybe with internal ROM, maybe with the software uploaded somewhere, or in the main rom shared? (or if the carts have simply never been opened, not dumped because the main cpu can't see it)


Posted By: byuu Re: The SNES WIP topic - 09/10/09 08:35 PM
Quote:
The message board is a more informal place, where I thought we were all above squabbling over l33t sk3n3 cr3dz.


Quote:
Also, I thought only dumpers had pointless flame wars about credits.


Sorry, I didn't mean to seem like I was deeply offended or anything. Hard to reflect mood in plain-text without lots of ^__^. Also note that I wasn't asking for credit for anything I've done.

As I said, just a pet peeve. You both seem to find it silly as well, which is why I pointed it out to etabeta in the first place.

That behind us ...

Quote:
Andreas Naive is busy decrypting the Naomi protection ASIC and anyone who distracts him for SNES will face my (and Cah4e3's) wrath


Absolutely not. There's no way in hell I want to burden the genius who put CPS-2 Razoola out of business to work on two godawful Shougi games.

Quote:
I guess the smart money is that those chips might be or contain an R3000


A lot of people speculate on what is inside the chips. I don't see the point unless someone can dump the program ROMs from these chips. Even neviksti couldn't manage it. I believe he said they use NAND ROMs, and he can only stain NOR ROMs.

The interface between ST-0010 and ST-0011 is almost identical, so emulating it is similar. We "just" have to RE the chess AI. The ST-0018 is very different, but still uses a very simple communication system like all the other DSPs. I've RE'd how it works, what a few of the commands do and the way it transmits the board information to and from the coprocessor.

For the ST-0018, there are commands like:
- will this board result in a check(mate)?
- given this board, what is the best move for player A?

The former is simple, but getting the latter bit-perfect would be ... fun, to say the least.

I'm told that some would castrate you for daring to mention using a generic Shougi AI, but I really don't care personally if it's used as a placeholder until when and if someone can dump the PROMs. This is slightly hypocritical as I'm also of the belief that partially emulating something may potentially kill the motivation to do it the right way later on.

Quote:
Since its manufactured by sharp its possible the z80-like core matches the gameboy cpu's on-die core, so if we get the roms decapped, we may be able to pretty much drop them in...


If we get the ST program ROMs before the DSP-1, it will be a crime against all that is good. But at least we can finally claim the entire library is emulated at last. Is there any way we can help get this process started? Would Guru mind helping? Let's see ...

S-DSP: probably not needed, bit-perfect except for mute pulse
S-PPU1/2: probably won't help, not much data missing
CIC: would help devcart makers maybe, but not us
DSP-1: very important, some games show timing issues
ST-0010,DSP-2,DSP-3,DSP-4,Cx4: already software emulated fairly decently, but still nice for timing purposes
S-DD1, SPC7110, S-RTC, OBC1: complete waste of time
Posted By: Just Desserts Re: The SNES WIP topic - 09/10/09 09:38 PM
Honestly, guys? The solution to each one of these chips that needs to be decapped is fairly simple:

Step 1: Save $200, and possibly a tip to encourage the use of more expensive processes if necessary (FIB rework, etc.)
Step 2: Ship $200 + game to Guru and say, "Hey, Guru, send this to that Decapitator guy!"
Step 3: ?????
Step 4: Get either binary data or an extremely high-res, perfectly-stitched die shot photographed in an appropriate manner, plus possible chip identification
Step 5: Emulate!
Posted By: R. Belmont Re: The SNES WIP topic - 09/10/09 09:50 PM
The Z80GB is a Nintendo design, not Sharp. Sharp real Z80s are probably the most common brand I've seen in arcade boards, and of course the ST-0016 has a real full Z80 in it.

Quote:
As I said, just a pet peeve. You both seem to find it silly as well, which is why I pointed it out to etabeta in the first place.


Understood. It's just I've been adjacent to ground zero for pointless squabbling lately (ground one?) and so I'm especially sensitive to it.

As far as the rest, the process is defined. Send Guru the chip, he'll forward it to the decapper, and it'll be decapped either as time and funds allow or you can donate $200 to guarantee that chip will be decapped/read next. I just did so for the Saturn's SH-1 CD controller and I will certainly keep everyone informed how that goes.
Posted By: R. Belmont Re: The SNES WIP topic - 09/10/09 09:51 PM
JD: actually, the Paypal on the Decap page goes directly to the decapper, so you don't even have to send Guru any money smile
Posted By: byuu Re: The SNES WIP topic - 09/10/09 09:53 PM
Okay, let's give it a shot then wink

Since the DSP-1 is the most critical, we'll start there.
http://board.byuu.org/viewtopic.php?f=3&t=241
Posted By: Stiletto Re: The SNES WIP topic - 09/10/09 10:31 PM
Originally Posted By Lord Nightmare
iirc dox said the st-018 is an nec v-something w/on die rom.
But the st-011 is the same as the st-010: a custom gate array with a z80 or z80-like core tacked onto it, plus ram and rom; stiletto looked it up.
Since its manufactured by sharp its possible the z80-like core matches the gameboy cpu's on-die core, so if we get the roms decapped, we may be able to pretty much drop them in...

LN


Nope, you misquoted me - Seta ST010/011 is a NEC part.

From my email a few months ago:
I was thinking about the Seta ST010 chips used in SNES and also in "Twin Eagle II - The Rescue Mission" arcade. I may have "identified" it so to speak. This may be known but I didn't see it documented anywhere.

Looking at the chip label:
http://en.wikipedia.org/wiki/File:ST010_01.jpg
http://web.archive.org/web/20070223101622/nsrt.edgeemu.com/INFO/chip-pix/ST010.JPG

We see a DIP64/SDIP64 chip labeled as so:
Seta
ST010
D96050CW-012
9301KX708

D96050CW? That matches a format NEC commonly uses: uPD followed by five digits, two letters, and a three-digit speed number. up is commonly but not always dropped off NEC part numbers. u is sometimes µ (micro).

For example, go here:
http://www.necel.com/cgi-bin/nesdis/dl_docpdf.cgi?lang=J&litcode=C11178EJCV0IF00

You'll see part numbers like upD96075CW.

Okay, so let's say that it really is a UPD96050CW-012. What is it? Well, really hard to say other than it seems to be a MCU of some kind, 64-pin.
But go look at this:
http://www.datasheetarchive.com/pdf-datasheets/Datasheets-16/DSA-317291.pdf
and you'll see uPD96100 listed as a "semi-custom cell-based LSI IC". Of course, this isn't conclusive at all. Still, maybe more info than you originally had. I'll see if I can look into this any further.

Of course, other than my initial contact with NEC, I haven't followed up yet. It is indeed proprietary so it's an uphill battle.

[EDIT] Ack, misunderstood - anyhow, more fuel for the fire.
Posted By: Stiletto Re: The SNES WIP topic - 09/10/09 11:09 PM
Originally Posted By R. Belmont
I just did so for the Saturn's SH-1 CD controller and I will certainly keep everyone informed how that goes.


I need to start saving for Model 2...
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/11/09 12:05 AM
byuu: before we go out of our way to buy carts, I own (saved for decapping):
Super Mario Kart (has dsp-1, not 1b)
Dungeon Master (dsp-2)
SD Gundam GX (dsp-3)

So all we need is the decap funds for those three. I don't own a top gear 3000 cart so we will need that for dsp-4, and we need a cart with a guaranteed dsp-1b in it, like ballz 3d.

We also need a upd77c25 core to actually run the stuff once dumped. (I also need a upd77c20 core for running an old speech synth, but its practically identical to the upd77c25, just has a smaller stack, 1/4 the rom and half the ram)

I also own an F1 ROC II cart for ST-010 decapping.

LN
Posted By: byuu Re: The SNES WIP topic - 09/11/09 12:42 AM
I'd like the dump the DSP-1B first. Supports the most games with the least bugs. DSP-2,3,4 are all one game a piece. Not good to debug our UDP77c25 core. But since we do eventually want all three DSP variants, I suppose we can start with Super Mario Kart if need be.

Anyway, I'll work on the UDP core once we have the PROM dumped wink

Since we don't know the exact Cx4/ST-001x core names, we should probably hold off on those. I do kind of wonder how hard it would be to RE just the binary blob, eg use heuristics to guess what the chip is doing. Probably a nightmare.

This will probably also be limited to bsnes and MESS. I doubt anyone else wants SuperFX-level speed penalties for DSP-n chip emulation. Maybe they can offer both, I intend to remove the simulators when I can. But I guess we'll find out wink

At least one person has expressed interest now. Should I pool up the money and send it all at once, or should we just have multiple people donate small chunks of money?
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/11/09 12:43 AM
Shit, i forgot about the Cx4: I have a megamanx2 cart for that as well.

As for money: we may want to have one person sort of 'consolidate' any donations together, then send that to dr. decapsulator at the end. Mr. Do on the mameworld forums does something similar for buying bezels, and smittdog does something similar as 'the dumping union' for buying rare pcbs for mame.
Money should if sent via paypal be sent as gifts since that way paypal takes much less of a cut of it.
I nominate byuu to accept donations for now.

We should aim to do a dsp-1b first imho, so I'll see if I can find a cheap dsp-1b cart on ebay or find someone who's willing to donate one to the cause. (I'm working on this)
Edit: Done. Just got a ballz 3d cart from ebay for $4 including shipping.

As for upd77c20/77c25 code to work on to get the core working: Sega's air rescue arcade machine used a upd77P25 (eprom version) with the protection bit NOT set, allowing it to be dumped, which it was; the chip is used for intermachine communication only afaik, but it should be valid code. Also I have the upd77P20 code from that prose 2020 speech synth which if shifted around a bit to make the bits line up should also run on a 77c25 (the 77c25 is backwards compatible with 77c20 code with appropriate column shifting of the roms, that's why the ram increment ignores the highest address bit on the 77c25)

And before I forget:
UPD7720 = nmos mask version
UPD77C20 = cmos mask version (I have one of these on the Infovox speech synth card rachael sent me, not dumped yet but is unprotected)
UPD77P20 = nmos eprom version (I have one of these on the prose 2020 speech synth, dumped)

UPD77C25 = cmos mask version, has protection bit. DSP-X are these, with protection bit set.
UPD77P25 = ?cmos? eprom version, has protection bit. Sega air rescue uses one of these, with the protection bit clear, which was dumped.

LN
Posted By: mangamuscle Re: The SNES WIP topic - 09/11/09 01:42 AM
Originally Posted By byuu
This will probably also be limited to bsnes and MESS. I doubt anyone else wants SuperFX-level speed penalties for DSP-n chip emulation. Maybe they can offer both, I intend to remove the simulators when I can.

I do not remember exactly in what MAME drivers, but sometimes emulation of the real hardware has proven to be faster than the simulation.
Posted By: R. Belmont Re: The SNES WIP topic - 09/11/09 02:46 AM
The later Namco games. VivaNonno's black box simulation of the sequencer running on the M37702 and C352 synth chip ended up being significantly slower than actual emulation of the chips.
Posted By: guigongas Re: The SNES WIP topic - 09/11/09 01:36 PM
Originally Posted By guigongas
Could you improve the sound during battles in Chrono Trigger?
In the rest of the game the sound is nice, however in battles it keeps "freezing" all the time.

Thanks in advance!


Actually this isn't a bug. Setting the frameskip to "automatic" fixes the problem. smile
Posted By: Kale Re: The SNES WIP topic - 09/11/09 05:33 PM
Originally Posted By Kale

And speaking about perversions...

r5409 /src/mame/machine/snes.c: [SNES]: Fixed a partial update bug when the screen is in interlace mode






(now I wonder about why the girls are decentered,ideas?)


Did I've already said that bsnes is right and photo subject should be centered since I've tested it on real HW? grin
Posted By: R. Belmont Re: The SNES WIP topic - 09/11/09 06:53 PM
I'll try to act surprised that this is the bug that bothers Kale the most ;-)
Posted By: ht1848 Re: The SNES WIP topic - 09/11/09 07:12 PM
On the DSP-1b decappin' - I am in for $50. I like the pool method. Send to byuu now or should we wait for people to commit the rest?
Posted By: jbo_85 Re: The SNES WIP topic - 09/11/09 09:05 PM
What game is that? grin
Posted By: byuu Re: The SNES WIP topic - 09/11/09 09:58 PM
I've posted about the fundraiser on my front page, and I have three offers. One sent $50 so far. Another was for $10 and the last one didn't say.

Once I have $200, I'll throw in some money myself as a tip per LN and send it over, along with the transaction ID# and a screenshot and all that.

I suppose we can coordinate when and where to send stuff once Ballz 3D arrives and the money is ready.

ht1848, thanks for your interest. You can e-mail me at setsunakun0 at hotmail (please don't send money to my hotmail address! I won't be able to retrieve it) and I'll give you the PayPal address (don't want people sending me money out of the blue), or post on my forum. Either way wink

Quote:
What game is that?


Bishoujo Janshi Suchie-Pai. I only know that because I fixed an issue with the PPU counters that was affecting it :P
Posted By: Shideravan Re: The SNES WIP topic - 09/11/09 11:06 PM
Well some graphics problemas in SMW2 - yoshi's island:



And the DDR-4 Top Gear now Brokes after reache the planets screen (just before the race begins)...

Posted By: byuu Re: The SNES WIP topic - 09/12/09 02:05 AM
We're up to $120 in donations, plus the $50 I will throw in myself. Both FitzRoy and ht1848 are offering $50 as well, so we shouldn't need any more donations.

I read Guru's page, it mentiosn the cost as $330 per chip. Are you guys sure $200 + tip is enough?

http://guru.mameworld.info/decap/index.html

If so, we'll probably have the money by this time tomorrow. Should I send it now, or wait for Lord Nightmare to send his DSP-1B over?
Posted By: R. Belmont Re: The SNES WIP topic - 09/12/09 02:21 AM
Guru personally told me $200, but I can verify with him.
Posted By: byuu Re: The SNES WIP topic - 09/12/09 02:28 AM
I've sent him a PM on mameworld. We probably should have spoken with him first, but you know how it goes sometimes smile

EDIT: we have $173 now + $50 from me. We're in the clear.
Posted By: Guru Re: The SNES WIP topic - 09/12/09 03:42 AM
I've got one of the chips here in a cart from some SNES-based arcade game that Ranger Lennier sent some time ago. Might be DSP-1 or something. It has 2 or 3 games in it one was Mario something I think. So I have one of them already....


Posted By: etabeta78 Re: The SNES WIP topic - 09/12/09 05:48 AM
Quote:
That's a pretty bold thing to brag about. "We're the first to publicly include someone else's fix for someone else's chip emulator."

Jonas Quinn should be getting the credit for the fix here, not MESS.

Pet peeve of mine. People fought about who added Andreas Naive's S-DD1 support first (ZSNES publicly, Snes9X privately), whoever it is on Wikipedia bragging about me including neviksti's SPC7110 support first, and so on. Releasing new builds faster than someone else isn't much to brag about. Andreas, neviksti and Jonas deserve that praise, not us for copying and pasting.

Saying such things eggs on the general public to think we're all competing against each other.


I know it's been clarified, but I've been away and I wanted to say my opinion. my commit messages for both MAME & MESS clearly says the code is only ZSNES code (no mention to fixes, especially not claiming they were done by our team), the source code contains full copyright credits (including Jonas' credit) and no mention is done about my name or of anyone in the team, because we have done no fixes on the emulation itself. Hence, outside this forum no one could even dream we are the authors of the fixes.

this leaves my previous post, which I thought was ironic enough to avoid misunderstanding (we got the fix, but you cannot even test it because the game does not work properly smile )

I'm sorry that I was in a hurry and I agree it would have been more clear if I would have explicitly said it had been Nach to send me the fix (which in turn is only Jonas' work),
but I never claimed that I fixed any bug, only that MESS was including the fixes.

Sorry for the misunderstanding, but we can definitely move on smile
Posted By: etabeta78 Re: The SNES WIP topic - 09/12/09 05:57 AM
Originally Posted By Shideravan
And the DDR-4 Top Gear now Brokes after reache the planets screen (just before the race begins)...


it still beats me why this should affect video emulation, but if you play a bit with autoframeskip and fast forward, you can sometimes see the following screen and reach the race... from then, the glitches make the game unplayable, though smile

same weirdness happens when you start Chase H.Q.: the car screen bg color may change (apparently) depending on how many frames you skip
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/13/09 12:11 AM
Originally Posted By Guru
I've got one of the chips here in a cart from some SNES-based arcade game that Ranger Lennier sent some time ago. Might be DSP-1 or something. It has 2 or 3 games in it one was Mario something I think. So I have one of them already....

I think the NSS arcade games are too old to have used the dsp-1b, it probably has a dsp-1a or dsp-1 in it. we may need those later (particularly if its a dsp-1a) but for now we just need the 1b. The cart I ordered hasn't arrived yet, but when it does, should i send it directly to Dr. decapsulator?
(I have a package I need to send him anyway with some mess related CGB and gameboy pocket stuff from incog, not to mention that ballz 3d should have an F411B CIC on it which we probably want decapsulated eventually too)

LN
Posted By: byuu Re: The SNES WIP topic - 09/13/09 02:24 AM
Neat. I wasn't aware there were any DSP-n games on the NSS. Really not a fan of the way those are dumped, but that's another topic smile

Here is neviksti's thread about his attempt to decap the DSP-1B.

http://www.cherryroms.com/forums/copier-and-hardware-forum/manually-extracting-rom.html

And here's a bunch of pictures of the chip sans cap.
https://netfiles.uiuc.edu/mantey/www/DSP1b/

From this picture:
https://netfiles.uiuc.edu/mantey/www/DSP1b/DSP1b_overview.jpg

We believe the program ROM is at the top in the middle, and is NAND MaskROM.

Perhaps we should send this info to Dr. Decapsulator now to see what he thinks.
Posted By: R. Belmont Re: The SNES WIP topic - 09/13/09 02:28 AM
The uPD-whatever is normally readable (I personally dumped the Air Rescue chip in MAME), so this shouldn't require optical readout, just them tweeking the read protect and reading it out that way.
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/13/09 04:52 AM
Originally Posted By byuu
Neat. I wasn't aware there were any DSP-n games on the NSS. Really not a fan of the way those are dumped, but that's another topic smile

Byuu: maybe you're right: i think what ranger_lennier sent guru wasn't NSS but instead was the super famicombox carts, which are these incredibly strange large things. Starfox was released on super famicombox format, and smk may have also been released that way.

LN
Posted By: byuu Re: The SNES WIP topic - 09/13/09 06:16 AM
Quote:
i think what ranger_lennier sent guru wasn't NSS but instead was the super famicombox carts


I see. If it comes down to it, it won't be a huge deal to use a DSP-1 or DSP-1A first; but we definitely want the DSP-1B eventually.

If we were to continue (maybe we'll learn how to toggle the protection bit from the decap scans?), it'd definitely be best to target the DSP-3 (unplayable), then DSP-4 (lots of errors), then DSP-2 (edge-case errors), and only then the remaining two DSP-1 revisions. Of course if someone has money for a different order, that's cool too.

Quote:
this shouldn't require optical readout, just them tweeking the read protect and reading it out that way.


I wonder how easy that will be ... would be really neat if we don't have to bug Dr. Decapitator to help with all the other variants. I'm happy to pay him to help, but I know there's a lot of other deserving chips out there as well.
Posted By: ranger_lennier Re: The SNES WIP topic - 09/13/09 07:18 AM
Originally Posted By Lord Nightmare
Originally Posted By byuu
Neat. I wasn't aware there were any DSP-n games on the NSS. Really not a fan of the way those are dumped, but that's another topic smile

Byuu: maybe you're right: i think what ranger_lennier sent guru wasn't NSS but instead was the super famicombox carts, which are these incredibly strange large things. Starfox was released on super famicombox format, and smk may have also been released that way.

LN


Yes, I sent him two Super Famicom Box carts. BTW, are there any particular difficulties to emulating the Super Famicom Box?
Posted By: Kale Re: The SNES WIP topic - 09/13/09 12:17 PM
Well, it's a Super Famicom + external output (for the menu), so in theory it shouldn't be very hard...granted that the external output is straightforward and not awkward like the nss menu...
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 04:31 PM
hello all,
Please just one question,, how to make for to use super fx with one rom in snes.c driver?
I have this:

GAME( 1991, sn_xxxxx, snes, snes, snes_ms, snes, ROT0, "Nintendo", "XXX (XXX)", 0 )

And this:

ROM_START( sn_xxxxx )
SNES_BIOS
ROM_REGION( 0x400000, "user3", 0 )
ROM_LOAD( "sn_xxxxx.smc", 0x000000, 0x200000, CRC(C87C771C) SHA1(DECAF1A0DEB09AADBFB5B8403404C9307713E6A1) )
ROM_END

More thanks all for help
Posted By: Just Desserts Re: The SNES WIP topic - 09/13/09 04:37 PM
Originally Posted By Multipass
hello all,
Please just one question,, how to make for to use super fx with one rom in snes.c driver?
I have this:

GAME( 1991, sn_xxxxx, snes, snes, snes_ms, snes, ROT0, "Nintendo", "XXX (XXX)", 0 )

And this:

ROM_START( sn_xxxxx )
SNES_BIOS
ROM_REGION( 0x400000, "user3", 0 )
ROM_LOAD( "sn_xxxxx.smc", 0x000000, 0x200000, CRC(C87C771C) SHA1(DECAF1A0DEB09AADBFB5B8403404C9307713E6A1) )
ROM_END

More thanks all for help


Use -cart parameter:

mess snessfx -cart <the cartridge>

smile
Posted By: R. Belmont Re: The SNES WIP topic - 09/13/09 04:37 PM
You can't (there are multiple technical reasons it won't work) and we wouldn't support such a configuration.
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 06:34 PM
But it work when i load a rom with mess, i dont understand frown
I have tested it with snessfx machine driver but wont work,
Any driver init or machine init is required?
Posted By: R. Belmont Re: The SNES WIP topic - 09/13/09 06:36 PM
You are trying to bypass all the parts of MESS that are MESS and make it into MAME. We do not support that and it will not work. If you are that wound up about playing a specific game, make a batch file or shell script.
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 06:42 PM
I want just to understand how is used super fx in snes driver, sorry if i make an error, i have just make a modified driver of snes for to list somes snes games in mame
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 08:36 PM
Originally Posted By Just Desserts

Use -cart parameter:

mess snessfx -cart <the cartridge>

smile

How mean this i dont understand?
Posted By: R. Belmont Re: The SNES WIP topic - 09/13/09 08:44 PM
I'm not sure how to make that simpler.

1) Undo the changes you made to the driver and compile
2) At the command prompt type mess snessfx -cart c:\roms\starfox.smc (or whatever the complete path to your cartridge is).
3) Game runs.
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 08:52 PM
Its for command line version? or Its not possible by snes.c driver?
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/13/09 10:05 PM
at a command prompt (i.e. in winxp, click 'start', click 'run...' and type cmd at the prompt)
do cd into the directory which mess is installed in
i.e. If you start in
C:\Documents and Settings\Your_Username>_
and mess is located in c:\mess
type 'cd c:\mess' (without the 's)
then type:
'mess snesfx -cart "path where cartridge file lives plus name"'
i.e if i have the cart images in c:\pokerom\snesroms and i want to run starfox.smc, then I would type:
'mess snesfx -cart "c:\pokerom\snesroms\starfox.smc"' (again without the ' chars) and then mess should run the cart correctly.

LN
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 10:25 PM
Thanks for your help but, i want a driver config in snes.c for to use with mess part of mame, someone can help me please?
Posted By: R. Belmont Re: The SNES WIP topic - 09/13/09 10:28 PM
You don't understand. MESS doesn't work like MAME, the drivers can load arbitrary ROMs off your hard disk. You do not need to change the source to play your game ROMs, you simply specify them on the command line the way we've been telling you.
Posted By: Multipass Re: The SNES WIP topic - 09/13/09 10:33 PM
Ok thaanks for your help frown
Posted By: byuu Re: The SNES WIP topic - 09/13/09 11:47 PM
This is a general curiosity and not a critique ... but why exactly are you listing SNES + SuperFX as a separate machine, in this case, "snesfx"?

Given that the chips are inside the cartridges, doesn't it make more sense to auto-detect the special chips and use just the main "snes" driver?
Posted By: R. Belmont Re: The SNES WIP topic - 09/14/09 12:06 AM
You can't dynamically add CPUs yet as far as I know, so it's easier to do it this way.
Posted By: Just Desserts Re: The SNES WIP topic - 09/14/09 12:18 AM
Originally Posted By R. Belmont
You can't dynamically add CPUs yet as far as I know, so it's easier to do it this way.


Actually, right now it's just because the SuperFX chip runs all the time, resulting in massive slowdown on non-SFX games. This avoids that for now.
Posted By: R. Belmont Re: The SNES WIP topic - 09/14/09 12:47 AM
Oh, well that's easy to fix smile
Posted By: RColtrane Re: The SNES WIP topic - 09/14/09 01:17 AM
How hard is to fix that 'cycle' issue that prevents lots of games to initialize properly, in a scale from 1 to 10?

Just curious...
Posted By: Just Desserts Re: The SNES WIP topic - 09/14/09 02:55 AM
One bazillion
Posted By: etabeta78 Re: The SNES WIP topic - 09/14/09 06:35 AM
Originally Posted By byuu
This is a general curiosity and not a critique ... but why exactly are you listing SNES + SuperFX as a separate machine, in this case, "snesfx"?


for the exact same reason, we need a separate system for Genesis + SVP to play the only game released with this add-on chip (Virtua Racing)

at a point, I hope it will be possible to add CPU at start/reset: it would be extremely handy to add/remove floppy drives at runtime [1] to systems which now require a separate entry for the system + floppy configuration...

how far MAME/MESS is from such a point, only Aaron probably knows...


[1] or by performing a hard reset
Posted By: byuu Re: The SNES WIP topic - 09/14/09 07:06 AM
I see. My method was kind of cheap, and obviously not appropriate for MAME / MESS. I just attached another unnamed core, and at startup it would check which add-on chip was present and jump to its entry point. If there were no appropriate chip, it'd go into a dummy loop that would add a full second worth of clock cycles to the counter. Didn't slow down ordinary games by more than ~1%.
Posted By: judge Re: The SNES WIP topic - 09/14/09 07:31 AM
You could just enable or disable the cpu entirely depending on whether a cartridge had it or not.
Posted By: etabeta78 Re: The SNES WIP topic - 09/14/09 08:36 AM
you mean in MESS? I guess we shall just check if snes_had_addon_chip is equal to SUPERFX in src/mess/machine/snes.c , but which is the correct syntax to start/stop the corresponding CPU? if it does not slow down things too much, the same can be easily don efor gensvp as well smile
Posted By: judge Re: The SNES WIP topic - 09/14/09 08:41 AM
cputag_suspend/cputag_resume with reason SUSPEND_REASON_DISABLE. It looks like it should be possible to disable a cpu in the machine definition too.
Posted By: etabeta78 Re: The SNES WIP topic - 09/14/09 09:10 AM
I'll try to experiment a little bit in the next few days smile
Posted By: Kale Re: The SNES WIP topic - 09/14/09 11:16 AM
Originally Posted By RColtrane
How hard is to fix that 'cycle' issue that prevents lots of games to initialize properly, in a scale from 1 to 10?

Just curious...


Basically requires wait state stuff in the MAME/MESS cores or a major tree hit with the g65816 CPU core, aka not something that you can wake up tomorrow and it'll be done... whistle
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/14/09 07:59 PM
Got the ballz 3d cart today. Played it for 5 minutes. Now I can't wait to see it decapped. good riddance.
BTW happy birthday etabeta.

LN
Posted By: R. Belmont Re: The SNES WIP topic - 09/14/09 08:02 PM
Core wait state stuff cannot properly emulate the SNES (this is where Haze's famous "MAME/MESS can't ever emulate consoles" rant can be inserted). You *have* to do an S-CPU core that counts master cycles if you ever hope to run e.g. byuu's magical seek thing smile
Posted By: byuu Re: The SNES WIP topic - 09/15/09 12:02 AM
Quote:
Got the ballz 3d cart today. Played it for 5 minutes. Now I can't wait to see it decapped. good riddance.


Hahah, yeah. No real loss destroying that cart. Thanks a bunch for getting it for us.

Guru, please let me know once you receive it so I can send the payment. Should send as 3x$75, right?

Quote:
You *have* to do an S-CPU core that counts master cycles if you ever hope to run e.g. byuu's magical seek thing


It is quite the evil function, had to write a helper program to generate the opcode tables needed automatically. Too much to do by hand.
Posted By: Haze Re: The SNES WIP topic - 09/15/09 12:41 AM
Originally Posted By R. Belmont
Core wait state stuff cannot properly emulate the SNES (this is where Haze's famous "MAME/MESS can't ever emulate consoles" rant can be inserted). You *have* to do an S-CPU core that counts master cycles if you ever hope to run e.g. byuu's magical seek thing smile


(rant inserted, mentally at least)
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/15/09 01:15 AM
Originally Posted By byuu

Guru, please let me know once you receive it so I can send the payment. Should send as 3x$75, right?


I was actually going to send it directly to dr. decapsulator (along with some gameboys) rather than going through guru, since shipping from us->au->us is murder.

LN
Posted By: byuu Re: The SNES WIP topic - 09/15/09 04:04 AM
Okay, should I send the money now, then?
Also, someone I don't recognize sent me another $50 so now we're at $275 o.O
Posted By: Stiletto Re: The SNES WIP topic - 09/15/09 04:19 AM
Originally Posted By Haze
(rant inserted, mentally at least)


laugh
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/15/09 04:51 AM
byuu: I guess so? should be a link on the dr decapsulator blog page. I'll see if I can get the package out tomorrow... er, technically later today.

LN
Posted By: byuu Re: The SNES WIP topic - 09/15/09 05:32 AM
Fair enough, per Guru's notes, I'll send payment over three days.

http://i73.photobucket.com/albums/i221/byuusan/Payment1.png

Someone may want to let him know who the strange person sending him payments is wink
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/15/09 06:01 AM
Email sent, we may end up needing a little more money though. I asked him.

LN
Posted By: byuu Re: The SNES WIP topic - 09/16/09 02:17 AM
Second payment sent: http://img43.imageshack.us/img43/9974/picture1yw.png

Let me know about the money thing please. I only have $50 extra smirk
Posted By: Lord Nightmare Re: The SNES WIP topic - 09/16/09 05:21 AM
I haven't got a response yet (and hence haven't sent the package due to waiting for address confirmation), Its possible he changed his email address from the last time I contacted him. I'll ask around for more info.

LN
Posted By: byuu Re: The SNES WIP topic - 09/17/09 12:31 AM
I certainly hope he didn't change his e-mail because I just sent the last payment :P

http://img11.imageshack.us/img11/6217/picture1vzx.png
Posted By: Guru Re: The SNES WIP topic - 09/17/09 12:46 PM
the paypal address on the decap.mameworld.info site is correct. that goes directly to the Dr. I have no knowledge of if or when he receives it.
He usually let's me know when someone sends money so we can keep track of who wants which chips done, or if it's just a general donation for decapping. But he's been very quiet for the last 2 months.
If you're sending stuff directly, I guess send it to LN and he can send it all in one package. I don't need to be involved.
I really only care about the chips that I've already sent and other arcade related chips that I'm planning to send, and/or stuff that's already here waiting. There's far too much to do to get it all done in one year. It's going to take many years to get through it all.
And many donations.
Posted By: etabeta78 Re: The SNES WIP topic - 09/17/09 11:15 PM
fyi, current svn has Super Mario Kart fixed. Other DSP1 games should work as well.
Posted By: ht1848 Re: The SNES WIP topic - 09/17/09 11:48 PM
Originally Posted By etabeta78
fyi, current svn has Super Mario Kart fixed. Other DSP1 games should work as well.




Great!!!
Posted By: byuu Re: The SNES WIP topic - 09/17/09 11:58 PM
This may interest you all, assuming you're using the updated DSP-1 core from Andreas Naive.

Originally Posted By Overload
dsp1emu.cpp

Code:
#if DSP1_VERSION < 0x0102
if (Pos & 1) Distance -= (Node2 - Node1);
#endif

Pretty sure this code if enabled will fix problems with Pilotwings [DSP1] and maybe Suzuka 8 hours [DSP1A]

dsp1emu.hpp

Code:
#define DSP1_VERSION 0x0102

DSP1 = 0x0100, DSP1A = 0x0101, DSP1B = 0x0102


Of course, that may cause issues in DSP-1B only games. Probably not, but you never know.
Posted By: Just Desserts Re: The SNES WIP topic - 09/18/09 12:18 AM
Cross-posting from the SVN thread, with latest in MESS:





As it turns out, using Cx4::sin and Cx4::cos for the wireframe calculations rather than std::sin and std::cos causes very bad things to happen. smile
Posted By: byuu Re: The SNES WIP topic - 09/18/09 12:25 AM
Yeah, have to be very careful with the :: stuff in my code. I should've left the tables as sinTable and cosTable, sorry.
Posted By: etabeta78 Re: The SNES WIP topic - 09/18/09 09:30 AM
after some cart loading jugglery, S-DD1 starts showing something

SFA2

(but crashes after a short while)

Star Ocean


(but is gets stuck at a black screen immediately after those logos)

I guess in the weekend we might iron out some of the remaining problems, now that data is fed to the S-DD1 side of the code.

however, after this changes are in svn, I'd like you all to test your favorite games to be sure cart loading still works as before (it would be enough to check if the games you like starts properly)
Posted By: etabeta78 Re: The SNES WIP topic - 09/18/09 09:44 PM
ok. since the modified cart loading routine is now in svn, please report any game that was working yesterday and broken now.

I spent the day mainly testing if carts were still loading correctly and trying to compile a debug build with symbols of win32 SDLMESS. this left very short time to debug S-DD1.

However, gdb revealed that, for some reason, Street Fighter Alpha 2 feeds the wrong values to SDD1_OL_launch and the function blows up. I hope to find time in the weekend to study our SDD-1 implementation in search of the problem...
Posted By: byuu Re: The SNES WIP topic - 09/18/09 10:21 PM
Just saw that the SGB BIOS was dumped, neat.
http://www.its.caltech.edu/~costis/sgb_hack/

Reminded me of my old work on emulating the Super Game Boy. Unfortunately, I got stuck due to my limited knowledge of the Game Boy hardware. While I myself was using gambatte as the Game Boy core, I imagine MESS is in a great position to use their own core.

So, how interested would you guys be in working with me to emulate something new for the very first time, as opposed to simply adding all these old chips in? smile

My research notes are here:
http://byuu.org/files/supergameboy.txt

The problem I'm having is explained under the $7800 register section, and I'm also quite stumped on the purpose of $6001.

I've gotten far enough to have the entire SGB BIOS running, all Gameboy non-SGB games running perfectly with full video, audio and input; and I've gotten a few SGB-specific commands to execute, but again, that $7800 problem makes almost everything unplayable.

I took out the code from the core because it was too unstable (and because I wanted to modularize the GB portion to a DLL/SO library), but if anyone is interested I can post one of the public v045 WIPs that had the aforementioned support.

Note: I'm looking for more than suggestions, eg actual help: testing ideas directly and such. Someone familiar with the GB-side of things would be quite valuable.
Posted By: judge Re: The SNES WIP topic - 09/19/09 07:08 AM
Nice info there. I've been planning on removing the seperate supergb driver we have in MESS now and replace it with full snes+gb emulation so it can work more like the real thing did. But I have not done anything towards really adding it yet.

What I did notice is that after the initial sending the gameboy rom information the actual sgb games read back from ff00 and expect to not see the lowest 2 bits set. If both bits are set the games will not send any sgb games, otherwise they will. I don't think that explains anything about 6001 and 7800 though.
Posted By: etabeta78 Re: The SNES WIP topic - 09/19/09 09:45 AM
fixing a small mirroring problem gives us Star Ocean title screen



not sure still why it freezes when you press Start, however. I'm going to investigate SRAM in the afternoon, just to be sure the problem is not there.

otoh, it could well be a problem in our core emulation, since it's not the only game with this (annoying) behaviour


EDIT: you can play Star Ocean by underclocking maincpu below 50%! it's definitely a CPU sync issue. this means that S-DD1 is now supported in MESS smile
Posted By: Anna Wu Re: The SNES WIP topic - 09/19/09 11:12 AM
Maybe we need a " Thank You " button in the forum.

Thanks, etabeta78 smile
Posted By: Just Desserts Re: The SNES WIP topic - 09/19/09 04:01 PM
Hey byuu, who do I need to get permission from to include SPC7110 in MESS?
Posted By: etabeta78 Re: The SNES WIP topic - 09/19/09 04:20 PM
byuu itself did most of the research with the guys mentioned in the source / docs. I think it is enough to provide due credits in this case. wink
Posted By: byuu Re: The SNES WIP topic - 09/19/09 04:43 PM
Quote:
Hey byuu, who do I need to get permission from to include SPC7110 in MESS?


neviksti was the one to crack the decompression engine, and I optimized a bit of that, removing some loops and generating a lookup table to de-interleave bits. I also emulated all the rest (data port, math, memory mapper, RTC units) by studying the hardware test.

neviksti said PD, as did I, so no credit needed as per the S-DD1, S-RTC and SuperFX modules.

And lastly, don't forget that you'll need proper S-RTC support: if you just give it the system time, you won't be able to pass the FEoEZ test program on startup without a hack.

Just be sure to keep compatibility with my .rtc save format if you port over my code. SNESGT and Snes9X WIP also use it. The crazy time_t handling is to allow it to work even after Y2k38 even on 32-bit time_t systems.
Posted By: Just Desserts Re: The SNES WIP topic - 09/19/09 05:14 PM
Originally Posted By byuu
And lastly, don't forget that you'll need proper S-RTC support: if you just give it the system time, you won't be able to pass the FEoEZ test program on startup without a hack.


I'll burn that bridge as I cross it, for now I'm just trying to get Momotarou Dentetsu Happy working, I'll worry about FEoEZ later. smile

Originally Posted By byuu
Just be sure to keep compatibility with my .rtc save format if you port over my code. SNESGT and Snes9X WIP also use it.


I'll look into it. My only worry is that the MAME and MESS architecture is very strict about how it handles saving NVRAM - the data is deserialized into an .nv file, and there are no methods provided for saving ancillary data streams in arbitrary files. I'm sure there's some way I can do it, I just can't think of any at the moment.
Posted By: etabeta78 Re: The SNES WIP topic - 09/19/09 06:54 PM
I fear at the moment we are strictly forced to save these data in gamename.nv. once MAME adds support for multiple nvram/sram files we may immediately add support for these .rtc files.

for the time being I fear we have to append the rtc content at the end of the sram frown
Posted By: R. Belmont Re: The SNES WIP topic - 09/19/09 06:58 PM
What's in the .RTC files and why is compatibility such a big thing? Honestly it's in everyone's interest to discourage emulator-hopping lest it cause weird bugs that don't otherwise happen.
Posted By: etabeta78 Re: The SNES WIP topic - 09/19/09 07:13 PM
seta st010 almost ready for prime time

Posted By: Just Desserts Re: The SNES WIP topic - 09/19/09 07:39 PM
Originally Posted By R. Belmont
What's in the .RTC files and why is compatibility such a big thing? Honestly it's in everyone's interest to discourage emulator-hopping lest it cause weird bugs that don't otherwise happen.


It appears to just be 20 bytes of internal data, see bsnes/src/chip/srtc/srtc.cpp line 98. I don't believe, from looking at it, that it could cause any emulator-hopping bugs, since it's all just a bunch of UINT8s.
Posted By: Anna Wu Re: The SNES WIP topic - 09/19/09 08:36 PM
Originally Posted By etabeta78
seta st010 almost ready for prime time



Is the game F1 ROC II - Race of Champions working with last SVN ?
Posted By: Just Desserts Re: The SNES WIP topic - 09/19/09 08:48 PM
Originally Posted By Anna Wu
Originally Posted By etabeta78
seta st010 almost ready for prime time



Is the game F1 ROC II - Race of Champions working with last SVN ?


No, that is why he said it's "almost ready for prime time". It's something of an English phrase which means "almost ready to be shown", or "almost ready to be made public", indicating it is not yet shown or public smile
Posted By: Anna Wu Re: The SNES WIP topic - 09/19/09 08:52 PM
Originally Posted By Just Desserts


No, that is why he said it's "almost ready for prime time". It's something of an English phrase which means "almost ready to be shown", or "almost ready to be made public", indicating it is not yet shown or public smile


Ah, ok smile
Posted By: Just Desserts Re: The SNES WIP topic - 09/19/09 09:22 PM
SPC7110 and ST010 support have been checked in, enjoy.
Posted By: byuu Re: The SNES WIP topic - 09/20/09 12:56 AM
Well, these two games only allow you to set time when you first start them. If emulators use different formats, you can see how that'd be a problem. Worse yet is the old Snes9X format that appends the time info to the end of SRAM. Every other emulator chops this data off when they go to save to the same file.

Anyway, special chips. So that's everything we have but SA-1. When can we look forward to work on Super Game Boy, ST-0011 and ST-0018 support? smile

Quote:
there are no methods provided for saving ancillary data streams in arbitrary files


Try fopen() wink
(I'm joking, of course.)
Posted By: Just Desserts Re: The SNES WIP topic - 09/20/09 01:06 AM
Originally Posted By byuu
When can we look forward to work on Super Game Boy, ST-0011 and ST-0018 support? smile


When can I see that WIP code? smile
Posted By: byuu Re: The SNES WIP topic - 09/20/09 01:31 AM
As soon as you help write it laugh

Seriously, everyone who was working on special chip emulation is pretty much worn out, and I just can't find the slightest motivation to spend months working on two Shougi games. But it would be absolutely phenomenal to have full 100% compatibility.

If you're meaning my SGB WIP code, I'll have to ask forum goers. It seems I don't have it on my system anymore frown
Posted By: Robbbert Re: The SNES WIP topic - 09/20/09 01:49 AM
Not sure if this test program is meaningful...

Posted By: R. Belmont Re: The SNES WIP topic - 09/20/09 01:52 AM
byuu: since you'd know, what are the easiest SA-1 games to get running in terms of not using much of the add-on hardware? I'd like to get Jikkyou Parodius going, but I don't immediately want to slam my head into a game that uses all the features either smile
Posted By: byuu Re: The SNES WIP topic - 09/20/09 02:22 AM
It's been a while, so I'll do my best.

Kirby's Dreamland 3 and Dragon Ball Z: Hyper Dementia are the easiest. They don't use any features at all, IIRC. Just clone the S-CPU, add in the MMIO regs to start and stop, and you can have them running in 8 hours. Or at least, that's what it took me. For you guys probably 2 hours :P

Marvelous makes use of standard SA-1 DMA for the sprites, but it'll "run" even without it.

Parodius makes use of IRQs, I believe. And Super Mario RPG is very tough, using IRQs and character conversion mode 2 for level up text.

The two golf games use both character conversion DMA modes. Not even ZSNES or Snes9X support those yet.

SD Gundam G-NEXT uses CC1 DMA, and also has an expansion slot for BS-X cartridges.

Jumpin' Derby uses the NMI override thing that nothing else does, and I think it also uses the variable bit-length feature.

There's about a half-dozen features bsnes emulates that no known game even uses; such as the SA-1-side IRQ timers.

And worst of all, not a damn SA-1 game, out of all ~26 of them or whatever, even uses a fraction of the true power of the SA-1. Almost all of them could easily be made without the chip at all. I strongly suspect most of the time it was simply used as an anti-piracy device.

As always, take a look at my WIP forum. The SA-1 testing phase mentions many bugs I ran into and how to fix them.

Quote:
Not sure if this test program is meaningful...


It looks fairly primitive, but may be pointing out some useful bugs. If that is a PD ROM, may I ask where you found it? If it's copyrighted, forget I said anything.
Posted By: Stiletto Re: The SNES WIP topic - 09/20/09 03:19 AM
Originally Posted By byuu
It looks fairly primitive, but may be pointing out some useful bugs. If that is a PD ROM, may I ask where you found it? If it's copyrighted, forget I said anything.


It sounds like this: http://board.zsnes.com/phpBB2/viewtopic.php?p=121043
Posted By: Just Desserts Re: The SNES WIP topic - 09/20/09 04:29 AM
Originally Posted By byuu
Kirby's Dreamland 3 and Dragon Ball Z: Hyper Dementia are the easiest. They don't use any features at all, IIRC. Just clone the S-CPU, add in the MMIO regs to start and stop, and you can have them running in 8 hours. Or at least, that's what it took me. For you guys probably 2 hours :P


So, I take it I basically just need to hook a memory map up to the SA-1 chip that's similar to the SNES, and Kirby's Dreamland 3 will fire up? For the life of me I can't figure out what the heck this "cc1bwram" and "sa1bwram" and "sa1iram" stuff is, will KDL3 work without it?
Posted By: R. Belmont Re: The SNES WIP topic - 09/20/09 04:35 AM
Not that simple. Needs a separate CPU core and probably some extreme cart remapping in MESS, I'll handle it.
Posted By: byuu Re: The SNES WIP topic - 09/20/09 04:40 AM
The I-RAM and BW-RAM are visible to both chips. To aid in letting bsnes run out-of-order, and because only the SA-1 can make use of the bitmap-RAM projection mode, I have access interfaces for both chips. There's also some special stuff to handle character-conversion DMAs.

cc1 refers to character-conversion mode 1, while sa1 is usually referring to bog-standard SA-1 opcode memory accesses. I'll have to look at the code sometime to explain it better why I have both.

And not only the CPU, you need to support part of the SA-1 MMIO interface to let the main CPU start the SA-1 at a specified point.
Posted By: Just Desserts Re: The SNES WIP topic - 09/20/09 04:47 AM
Originally Posted By R. Belmont
Not that simple. Needs a separate CPU core and probably some extreme cart remapping in MESS, I'll handle it.


Bah, fine. I already duplicated the G65816 core into an SA1 core and was in the process of hooking up the MMIO writes to cpu_set_info. I figured I could have it going by the time you wake up tomorrow, seeing as you're probably going to bed soon. smile

Originally Posted By byuu
If you're meaning my SGB WIP code, I'll have to ask forum goers. It seems I don't have it on my system anymore frown


That's exactly what I meant. frown
Posted By: etabeta78 Re: The SNES WIP topic - 09/20/09 05:41 AM
Originally Posted By R. Belmont
...and probably some extreme cart remapping in MESS...


FWIW, the following code should cover the cart ROM remapping part.

Code:
while (read_blocks < 64 && read_blocks < total_blocks)
{
	/* Loading and mirroring data */
	memcpy(&snes_ram[0x008000 + read_blocks * 0x10000], &ROM[0x000000 + read_blocks * 0x8000], 0x8000);
	memcpy(&snes_ram[0x808000 + read_blocks * 0x10000], &ROM[0x000000 + read_blocks * 0x8000], 0x8000);
	memcpy(&snes_ram[0xc00000 + read_blocks * 0x10000], &ROM[0x000000 + read_blocks * 0x10000], 0x10000);
	read_blocks++;
}


Not sure about the changes needed for the SRAM.
Posted By: Just Desserts Re: The SNES WIP topic - 09/20/09 07:15 AM
Originally Posted By byuu
My research notes are here:
http://byuu.org/files/supergameboy.txt

The problem I'm having is explained under the $7800 register section, and I'm also quite stumped on the purpose of $6001.

I've gotten far enough to have the entire SGB BIOS running, all Gameboy non-SGB games running perfectly with full video, audio and input; and I've gotten a few SGB-specific commands to execute, but again, that $7800 problem makes almost everything unplayable.


Originally Posted By Research Notes

The six packets generated are in this format:
Packet #1: $f1, $??, <14 bytes of GB ROM data, starting from $0104>
Packet #2: $??, $??, <14 bytes of GB ROM data, starting from $0112>
Packet #3: $??, $??, <14 bytes of GB ROM data, starting from $0120>
Packet #4: $??, $??, <14 bytes of GB ROM data, starting from $012e>
Packet #5: $??, $??, <14 bytes of GB ROM data, starting from $013c>
Packet #6: $??, $??, <14 bytes of GB ROM data, starting from $014a>
$?? values are not looked at by the SGB BIOS at all. They can be anything, but
are most likely $f1,$00 for each packet.
$f1 corresponds to command $1e with a length of 1, eg ($1e << 3) + 1


I'm not entirely sure that that is accurate, either that the first byte corresponds to a command or that it corresponds to a length. The first byte itself seems to be arbitrary, and does not correspond to any kind of length - this is based off of the behavior I've observed in the real Super Game Boy boot ROM that has recently been dumped by Costis. Here's a C version of almost everything the boot ROM does:

Code:
int main(int argc, char* argv[])
{
	int index = 0, index2 = 0;
	int byte = 0, bit = 0;
	int sum = 0;
	int length = 6;
	UINT16 romAddr = 0, ramAddr = 0;
	UINT8 byte0 = 0;
	SP = 0xfffe;
	SetJOYP(0x30);
	for(index = 0x1fff; index >= 0; index--)
	{
		SetVRAM(index, 0);
	}
	SetNR52(NR52_ALL_ON);
	SetNR11(NR11_DUTY_12_5 | NR11_LENGTH_1);
	SetNR13(0xf3);
	SetNR51(NR51_SO2_4 | NR51_SO2_3 | NR51_SO2_2 | NR51_SO2_1 | NR51_SO1_2 | NR51_SO1_1);
	SetNR50(NR50_SO2VOL_7 | NR50_SO1VOL_7);
	SetBGP(0xfc); // 3:11 2:11 1:11 0:00 (monochrome)
	for(index = 0; index < 8; index++)
	{
		SetWRAM(0x58 + index, 0);
	}
	romAddr = 0x014f;
	ramAddr = 0x57;
	byte0 = 0xfb;
	do
	{
		for(index2 = 0; index2 < length; index++)
		{
			sum += GetROM(romAddr);
			SetWRAM(ramAddr--, GetROM(romAddr));
			romAddr--;
		}
		SetWRAM(ramAddr--, sum);
		SetWRAM(ramAddr--, count);
		count -= 2;
		length = 14;
	} while(count != 0xef);

	// Some audio? juju goes on in between the above and 0x0087, but it's unimportant

	// 0x0087:
	SetJOYP(0x00);
	SetJOYP(0x30);
	ramAddr = 0x00;
	while(ramAddr != 0x60)
	{
		for(byte = 0; byte < 16; byte++)
		{
			for(bit = 0; bit < 8; bit++)
			{
				if(GetWRAM(ramAddr++) & (1 << bit))
				{
					SetJOYP(0x10);
				}
				else
				{
					SetJOYP(0x20);
				}
				SetJOYP(0x30);
			}
		}
		SetJOYP(0x20);
		SetJOYP(0x30);
		Delay4Frames();
	}
	LockoutAndBoot();
}

// 0x00c2
void Delay4Frames(void)
{
	int index = 0, index2 = 0;
	D = 4;
	for(index = 0; index < 4; idex++)
	{
		while(GetLY() != 0x90);
		for(index2 = 0; index2 < 256; index2++);
	}
}

// 0x00fc
void LockoutAndBoot(void)
{
	SetLockout(1);
	CartBoot();
}

// 0x0150
void CartBoot(void)
{
	...
}


I can't say for certain exactly what the first byte really is, but it appears that the second byte is a summation of the 14 subsequent bytes in that particular row. For example, the buffer built up by the SGB BIOS for Wario Land II looks like:

Code:
F1 70 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F3 60 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F5 59 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F7 7A xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F9 F5 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
FB AC xx xx xx xx xx xx xx xx xx xx xx xx xx xx


Your thoughts?
Posted By: byuu Re: The SNES WIP topic - 09/20/09 10:29 AM
Well, I only looked at the SNES-side Super Game Boy BIOS code. It looked for the #$f1, and then it looked at bytes 2-16 of each packet and compared it against a copy it stored inside the BIOS itself. The other values can be anything and it still works.

That you've figured out the exact details from RE'ing the 256-byte GB-side BIOS is quite amazing, thank you. I had to fake the packets being sent on reset to start the SGB program, but it would probably be better to emulate the boot ROM and have it do that for us.
Posted By: Kale Re: The SNES WIP topic - 09/20/09 01:18 PM
Originally Posted By robbbert
Not sure if this test program is meaningful...



I can expect that most of them fails their test, but the CG RAM failing is quite bogus...?
Posted By: Just Desserts Re: The SNES WIP topic - 09/20/09 01:57 PM
Originally Posted By byuu
Well, I only looked at the SNES-side Super Game Boy BIOS code. It looked for the #$f1, and then it looked at bytes 2-16 of each packet and compared it against a copy it stored inside the BIOS itself. The other values can be anything and it still works.


Makes sense, it's probably an arbitrary value just so that the SNES-side program knows that the data was sent successfully. smile

Originally Posted By byuu
That you've figured out the exact details from RE'ing the 256-byte GB-side BIOS is quite amazing, thank you. I had to fake the packets being sent on reset to start the SGB program, but it would probably be better to emulate the boot ROM and have it do that for us.


I'm on a roll due to another GB side project I've got, it was pretty straightforward. I'm kind of disappointed that it didn't provide any insight into either what's sent to $6001 or $7800, though. frown
Posted By: Just Desserts Re: The SNES WIP topic - 09/20/09 02:47 PM
Hey byuu, you mentioned that you largely took Gambatte's code piecemeal to try to get SGB games working. Could this have anything to do with the issues you were seeing?

http://speeddemosarchive.com/kb/Super_Game_Boy_timing

Edit: Oh, hey, the proper values are already listed on... *shudder*... overclocked.org:

Quote:

Clock Speed: 4.194304 MHz (4.295454 MHz for Super GB)
Horiz Sync: 9198 KHz (9420 KHz for Super GB)
Vert Sync: 59.73 Hz (61.17 Hz for Super GB)
Posted By: byuu Re: The SNES WIP topic - 09/20/09 11:09 PM
The clock ratio for the Super Game Boy is just the main S-CPU rate, 21.477272MHz, divided by five. It shouldn't matter a whole lot there.

The main transmission protocol is a really, really slow serial thing over the joypad ports. But to send large amounts of data, eg for custom borders, it turns the screen off, then puts a lot of graphics into video RAM, sends a special command and the SGB BIOS uses the next frame's VRAM data for whatever the command was for.

The problem is that $7800 is a streaming auto-increment port, and those commands seem arbitrary and show up whenever. There's never a command-write that says "sync $7800 so the next read starts at offset 0." I think it may be related to the very unusual writes to $6001, but nothing I tried worked. So what kept happening was these commands would read out their own data and end up reading it from the wrong spot, resulting in gibberish custom data, and then the screen video output would get thrown off and the top of the screen would be moved a few lines, kind of like a lousy V-hold or something.

Anyway, on my WIP forum, Fras posted v045 wip09. That one has Super Game Boy support with sound. You should be able to see what I mean from it. The version of gambatte included has a couple of patches to expose the LY-counter, and to load and save to memory instead of disk.

Also, I tried e-mailing Costis to see if he'd be interested in looking into the two registers, but his lack of response seems to indicate he would not. Ah well, worth a try anyway.
Posted By: judge Re: The SNES WIP topic - 09/21/09 05:50 AM
Did you also try linking $7800 and the turning on of the gb video hardware? (I suppose you did though)
Posted By: byuu Re: The SNES WIP topic - 09/21/09 06:39 AM
I don't think that was one of the things I tried, no. I didn't do anything to coordinate $7800 with GB-level events, as I don't really know anything about the GB hardware.
Posted By: judge Re: The SNES WIP topic - 09/21/09 06:51 AM
The gb video rendering hardware can be turned off. This allows full access to the gb video ram and is usually used to upload new tile sets for instance. When the gb video rendering hardware is active then during rendering the gb video ram is not accessible from time to time.
Posted By: guigongas Re: The SNES WIP topic - 09/21/09 04:31 PM
Regressions in svn 5824:

-Super Mario World has no sound.
-Rock 'n' Roll Racing resets when entering a race
-Many other games don't even start

What happened?
Posted By: Anna Wu Re: The SNES WIP topic - 09/21/09 04:45 PM
Originally Posted By guigongas
Regressions in svn 5824:

-Super Mario World has no sound.
-Rock 'n' Roll Racing resets when entering a race
-Many other games don't even start

What happened?


It seems something wrong. Just check the game : The Legend of Zelda - A Link to the Past
Posted By: guigongas Re: The SNES WIP topic - 09/21/09 04:58 PM
What's wrong with Zelda? I can't see no error in it.
Posted By: etabeta78 Re: The SNES WIP topic - 09/21/09 05:27 PM
I see no problem in Legend of Zelda and Super Mario World has sound for what I can hear (but my eeepc run it at around 20%, so it's really cracking)

would you both mind to be more specific in what's wrong and possibly tell when the regressions appeared?

here everything works as berfore
Posted By: Just Desserts Re: The SNES WIP topic - 09/21/09 05:33 PM
This is really weird. Yesterday, Tafoid reported that he was getting a black screen in Mario Kart when trying to go in-game, and massive graphics problems in HyperZone and Joe & Mac. All three games worked fine for me after syncing up to the latest SVN tree and doing a clean build, and maliehmut confirmed what I was seeing. However, this morning, Kale reported the same HyperZone graphics corruption problems.

Now, some people are seeing problems in other games, but etabeta isn't seeing them. I don't have access to SVN, so I can't test on my own.

It can't be a 32-bit versus 64-bit issue, since both Tafoid and I use 32-bit builds. It can't be an MSVC versus GCC issue, because both Tafoid and I use GCC. All I can come up with is somehow he and I are using different versions of GCC - I'll post the output from gcc -v when I get home from work.
Posted By: etabeta78 Re: The SNES WIP topic - 09/21/09 05:58 PM
the difference may be in the game image used. it seems that Harmony's changes to add spc7110 support contained a line which broke loading of carts with an header

please try again with svn 5837 and post if you still have issues (or use nsrt to remove headers wink )
Posted By: R. Belmont Re: The SNES WIP topic - 09/21/09 05:59 PM
A clean 64-bit Linux build of SVN 5835 is playable in-game for Mario Kart, Mario World has sound, and Rock n' Roll Racing plays fine (these are all headerless images).
Posted By: etabeta78 Re: The SNES WIP topic - 09/21/09 06:03 PM
Kale has confirmed that rev 5837 fixes the problem for headered images as well.

adding the fact that the removed line was wrong, I think we are back to working state on every computer around wink
Posted By: ht1848 Re: The SNES WIP topic - 09/21/09 06:09 PM
Originally Posted By Just Desserts
This is really weird. Yesterday, Tafoid reported that he was getting a black screen in Mario Kart when trying to go in-game, ...(snip)


I am not sure if you saw my notes on IRC. The Mario Kart is not a recent regression. It has been there since at least August 12th. See my post with screenshot (bottom)

http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=52543#Post52543

It only happens if you quit while in gameplay and start another session. If you quit during any of the menus or clear your .nv it works fine the next start. And it is not really black it is just shifted to the left. You can see a single pixel of the screen on the far left. So I don't know if that is a mode 7 bug, a nvram bug, multisession bug or a compile bug (or all!)

Tafoid - Does that describe what you were seeing?

Just in case: I am using GCC, 32 bit on XP SP3 standard build with no fancy switches.

The only regression I have seen is that controls stopped working in "Super Star Wars - Empire Strikes back" just get stuck at start screen. no response. It worked release 133 and at lest part way into the SNES party of v134. I have not had time to narrow when it broke.

Edit: Better screen shot in Shideravan's Posrt
Posted By: guigongas Re: The SNES WIP topic - 09/21/09 06:27 PM
Originally Posted By ht1848
The Mario Kart is not a recent regression. It has been there since at least August 12th.


No, it's not that regression. It's a new one. But i think they already fixed it with latest svn. smile


Originally Posted By ht1848
The only regression I have seen is that controls stopped working in "Super Star Wars - Empire Strikes back"


This annoying bug is still present in all games of the Super Star Wars series.

Posted By: R. Belmont Re: The SNES WIP topic - 09/21/09 06:33 PM
ht1848: the DSP-1 didn't work on August 12 so it was not possible to get a working Mario Kart screenshot in that version. Would you care to share what you're smoking? smile
Posted By: ht1848 Re: The SNES WIP topic - 09/21/09 06:43 PM
yeah true true - "working" was probably a bad way of saying it. "In-game" would be a better way of stating it. Back then it had the DSP-1 issue that etabeta later fixed (all the drivers hit invisible walls) and it did the black screen upon restart after quiting from gameplay. 1 of those behaviors is now fixed (gameplay).

I'll check tonight on that last update (svn 5837), sounds like it worked for guigongas.
Posted By: ht1848 Re: The SNES WIP topic - 09/22/09 02:39 AM
On the multi-session bug. I found a slight variation...

As you have seen in previous screenshots if you exit emulation while in the driving game play you get this all black except for sliver on left side.

Just found that if you quit from game play portion of the attract/demo you get a different black bar. By attract I mean, start game and wait until it goes into the driving demo with Mario. This is with svn5839, clean build.

Not sure if that 2nd behavior helps track down the issue.
Posted By: byuu Re: The SNES WIP topic - 09/22/09 03:37 AM
Quote:
I can expect that most of them fails their test, but the CG RAM failing is quite bogus...?


Are you buffering CGRAM accesses properly? When you write the first value it gets stored in a buffer, and it writes the 15-bit pair on the second write. Writing to $2121 clears the "latch" so to speak so that the next write after will be buffered. Reads are immediate, however. d7 of every second read returns the PPU2 MDR, or open bus.

How about wrapping around? After writing to $2122 at $01ff, it wraps back to $0000.

We're lucky that the test doesn't try writing to CGRAM during active display, heh.
Posted By: Anna Wu Re: The SNES WIP topic - 09/22/09 05:49 AM
Originally Posted By guigongas
What's wrong with Zelda? I can't see no error in it.


SVN r5826
snespal driver



This was the reason why I gave a comment.


SVN r5839
snespal driver



Seems to be ok now.

PS: Using GCC for compiling.
Posted By: etabeta78 Re: The SNES WIP topic - 09/22/09 06:54 AM
I suggest you to use either nsrt or goodsnes to remove header from your roms. with proper headerless images you would have had no corruption.

however, we fixed the problem wink
Posted By: Anna Wu Re: The SNES WIP topic - 09/22/09 07:17 AM
Originally Posted By etabeta78
I suggest you to use either nsrt or goodsnes to remove header from your roms. with proper headerless images you would have had no corruption.

however, we fixed the problem wink


Thank you for the info, etabeta78. smile
Posted By: byuu Re: The SNES WIP topic - 09/22/09 08:56 AM
It'd be great if you guys were willing to enforce a no-copier-header rule for MAME/MESS images smile

They serve absolutely no purpose other than making IPS patch applications a crapshoot, and only remain due to popular emulators refusing to remove support for them.
Posted By: Kale Re: The SNES WIP topic - 09/22/09 12:38 PM
Originally Posted By byuu
Quote:
I can expect that most of them fails their test, but the CG RAM failing is quite bogus...?


Are you buffering CGRAM accesses properly? When you write the first value it gets stored in a buffer, and it writes the 15-bit pair on the second write. Writing to $2121 clears the "latch" so to speak so that the next write after will be buffered. Reads are immediate, however. d7 of every second read returns the PPU2 MDR, or open bus.

How about wrapping around? After writing to $2122 at $01ff, it wraps back to $0000.

We're lucky that the test doesn't try writing to CGRAM during active display, heh.


It was a rather silly bug on the read cgram data, something like:


case RCGDATA: /* Read data from CGRAM */
if (cgram_address & 0x01)
{
snes_ppu.ppu2_open_bus = ((UINT8 *)snes_cgram)[cgram_address] & 0xff;
}
else
{
snes_ppu.ppu2_open_bus &= 0x80;
snes_ppu.ppu2_open_bus |= ((UINT8 *)snes_cgram)[cgram_address] & 0x7f;
}


...instead of...


if (!(cgram_address & 0x01))
{
snes_ppu.ppu2_open_bus = ((UINT8 *)snes_cgram)[cgram_address] & 0xff;
}
else
{
snes_ppu.ppu2_open_bus &= 0x80;
snes_ppu.ppu2_open_bus |= ((UINT8 *)snes_cgram)[cgram_address] & 0x7f;
}


...guess that I need to check the other errors as well (first off the APU fail) smile
Posted By: guigongas Re: The SNES WIP topic - 09/22/09 02:06 PM
Originally Posted By guigongas
Regressions in svn 5824:

-Super Mario World has no sound.
-Rock 'n' Roll Racing resets when entering a race
-Many other games don't even start

What happened?

All working again. Thanks! smile
Posted By: byuu Re: The SNES WIP topic - 09/22/09 03:40 PM
Quote:
...guess that I need to check the other errors as well (first off the APU fail)


That may be a tough one. Surprisingly even Super Sleuth is failing it. Made this for fun / bragging. May help troubleshoot the remaining issues.
http://img242.imageshack.us/img242/8840/agingcassette.png

If you want to go at it anyway, I'd suggest referencing blargg's GME S-SMP core. It's also fully cycle-accurate for every testable opcode, and even emulates a special feature I don't, a glitch involving the counters.

But if you get them all, it's pretty neat. It runs a slightly different version of the SNES character test afterward while playing "When you wish upon a star" in the background. Would've been more fitting had I kept the name StarSNES wink

"EXT LATCH" would probably be the next one to target. It's probably using STAT78 and PIO for that.
Posted By: Kale Re: The SNES WIP topic - 09/22/09 06:36 PM
Originally Posted By byuu

"EXT LATCH" would probably be the next one to target. It's probably using STAT78 and PIO for that.


EXT LATCH tests the horizontal latch at 0x213c (OPHCT) (puts it at work ram $0054-5 then checks with various values, put a breakpoint at pc=9226 to quickly check it). I can workaround it but it's directly related to the maincpu/pixel clock timings, so it'll do damage in the long term. Same goes for the VH flag test, in the end the fault is shared of that 256/512 switch thing that I've putted up that shows one of the major flaws in MAME/MESS architecture...
Posted By: R. Belmont Re: The SNES WIP topic - 09/22/09 07:00 PM
The DMA MEMORY fail is probably a bit scarier smile
Posted By: Just Desserts Re: The SNES WIP topic - 09/22/09 07:01 PM
Originally Posted By Kale
Same goes for the VH flag test, in the end the fault is shared of that 256/512 switch thing that I've putted up that shows one of the major flaws in MAME/MESS architecture...


I don't quite understand how this 256/512 switch thing shows a "major flaw" in MAME/MESS architecture. Why not always render at 512 and artificially pixel-double lines that are 256?
Posted By: Kale Re: The SNES WIP topic - 09/22/09 07:25 PM
Because you need the playfield to be 512, so you need to double the horizontal resolution also, otherwise you'll get exceptions.
Posted By: Just Desserts Re: The SNES WIP topic - 09/22/09 08:12 PM
That's what I said, I think. When rendering each scanline, render it as 512 pixels wide. If the scanline is actually in 256-pixel-wide mode, then double the width of each pixel.
Posted By: R. Belmont Re: The SNES WIP topic - 09/22/09 08:35 PM
Exactly. Several drivers in MAME/MESS already do it.
Posted By: Kale Re: The SNES WIP topic - 09/22/09 09:35 PM
...and the SNES driver does it too. What I'm saying since day one is that the beam timing gets screwed in MAME/MESS if you need to stretch the screen like SNES, like is currently happening.
Posted By: Heretical_One Re: The SNES WIP topic - 09/22/09 11:51 PM
How is that happening? There's no way it should be possible to throw off the beam timing. beam advances 1/256th of a scanline per rendered dot (that is, dots that are not h-blank). All that changes is that 512 pixel modes output twice per dot. The counters still move just like 256-pixel mode, and beam timing should respect that...
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 01:02 AM
MAME's H and V counters are strictly in terms of real pixels. That said, I had passable raster timing working previously in the driver (not enough for hardcore, but it passed the various checks in the famous Electronics Test) so some /2s sprinkled around should at least restore that state of affairs.
Posted By: byuu Re: The SNES WIP topic - 09/23/09 08:04 AM
I don't think you're going to be able to fully duplicate the SNES H/V counter behavior by using what's built into MAME. There are some really odd things, like scanline 240 on non-interlace odd fields on NTSC sets missing one pixel (something to do with color burst, I've been told), and dots 323 and 327 lasting two clocks longer than the others (except on the short line mentioned above.)

Really, the PPU and CPU need to run on their own clocks, and you also have to support the bus communication delays between them, eg CPU write to a PPU reg takes 6 clocks to acknowledge, where a read takes 2 clocks to acknowledge.

Without this stuff, you won't be able to make use of most of my regression test ROMs frown
Those will save you a ton of headache with IRQ / NMI bugs.
Posted By: Just Desserts Re: The SNES WIP topic - 09/23/09 12:46 PM
Yeah, I've got to be honest here: I once tried to make some improvements to the MESS SNES driver's video hardware emulation. I ran, screaming, within 5 minutes, because it has practically no similarities to any other emulator's codebase.

I'm pretty sure that devices can have their own clocks now, so I dare say that the driver would seriously benefit from just scrapping the entire video hardware emulation and duping the g65816 core into an S-CPU core, and then trying to take as much of bsnes's code as possible.
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 01:11 PM
I'll leave aside the part where you're screaming from the rooftops that Kale and etabeta suck and focus on one fact: MAME/MESS architecturally cannot achieve full bsnes level accuracy as is and I'm not convinced that should be the goal. Yes, we can get much better CPU timing than we have now and that's important, but from what I've seen commercial games are generally a lot more forgiving then byuu's synthetic tests.
Posted By: etabeta78 Re: The SNES WIP topic - 09/23/09 01:14 PM
in fact, since last August, the structure between MESS and BSNES is more similar than it was before: BSNES rendering design was so elegant and simple that I modified MESS to work the same way, rendering one mode after the other and calling a common set of functions for each mode.

the main difference is that BSNES handles directly each single pixel (making "easier" to implement effects like offset-per-tile) while MESS does not (and hence OPT is still missing).

That said, moving the whole video emulation to a device in order to better sync things is probably a good idea... just don't count on me to do it (in the short term) because I keep being a bit busy with real life
Posted By: Kale Re: The SNES WIP topic - 09/23/09 01:38 PM
Originally Posted By R. Belmont
I'll leave aside the part where you're screaming from the rooftops that Arbee, Kale and etabeta suck and focus on one fact [...]


*fixed*, why you don't put yourself in that since you started the video emulation logic and I've simply followed your logic? laugh
In my humble opinion, I don't think that our snes codebase it THAT hard to follow. Problem is that we need good plans to fix the remaining issues that are: mosaic effects, OPT and the obj limit flag (the latter actually shouldn't be in the video code in the MAME/MESS logic anyway), that's all. All the rest is machine/timing related plus small quirks here and there...
Posted By: Just Desserts Re: The SNES WIP topic - 09/23/09 03:08 PM
Originally Posted By R. Belmont
I'll leave aside the part where you're screaming from the rooftops that Kale and etabeta suck


I didn't say that they sucked, I said that I ran away from it because its architecture was way outside of my comfort zone. If anyone or anything sucks, it's my ability to read unfamiliar code. smile

I'm just saying, as far as the code's structure, it seems unfamiliar to me, and could possibly stand a code clean-up pass - for example, the debug switches to turn layers on and off do not appear to work.
Posted By: etabeta78 Re: The SNES WIP topic - 09/23/09 03:31 PM
iirc, they got broken when we passed in video_update from

Code:
	for (y = cliprect->min_y; y <= cliprect->max_y; y++)
		snes_refresh_scanline(screen->machine, bitmap, y);


to

Code:
	for (y = cliprect->min_y; y <= cliprect->max_y; y++)
		snes_refresh_scanline(screen->machine, bitmap, y+1);


(notice the y+1). I've never gone back to fix them wink
Posted By: Kale Re: The SNES WIP topic - 09/23/09 04:18 PM

r5865 /src/mame/machine/snes.c: [SNES]: Fixed an incorrectly setted DMA register read, fixes DMA Memory in the test cartridge




Just three errors now. As a result, Clay Fighter and NHL '9x are working again.





(and don't ask to me why people should use an undefined DMA register bit as RAM, guess is again a SNES compiler issue....)
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 04:29 PM
Clay Fighter and NHL 9x put the inner loop of their sprite decompression in the DMA registers so it runs 3.58 MHz instead of 2.6.
Posted By: byuu Re: The SNES WIP topic - 09/23/09 05:44 PM
Quote:
BSNES rendering design was so elegant and simple that I modified MESS to work the same way


Why not use my renderer entirely? It should be almost as fast as others (the bottleneck is in S-CPU IRQ processing), and it's feature-complete. No worries about color add/sub bugs, mosaic, OPT, Mode7 EXTBG, glitched sprite height in interlace mode, etc etc.

Only the S-CPU and S-SMP rely on cothreads, you can easily detach the ~6 lines regarding them from the current renderer and use it in a state machine.

Quote:
(and don't ask to me why people should use an undefined DMA register bit as RAM, guess is again a SNES compiler issue....)


I use DMA registers for JMP (indirect) inside proportional font routines. Say you want to move a line of a letter six places over:
Code:
lda.l {bitpos}; phx; tax
lda {fontdata},y; and #$00ff; xba
-; beq +; lsr; dex; bra -; +; plx


Or:
Code:
lda.l {bitpos}; clc; adc.w #table; sta $430a
lda {fontdata},y; and #$00ff; jmp ($430a)
table: asl; asl; asl; asl; asl; asl; asl


Can't use $0000-1fff because the game itself may be using them, plus it's slower to access than $43xx.

$43xb (and its mirror, $43xf) make nice temporary storage registers. I kind of wish $43xb-$43xf were all valid, ah well.

Quote:
Yes, we can get much better CPU timing than we have now and that's important, but from what I've seen commercial games are generally a lot more forgiving then byuu's synthetic tests.


That's unfortunate. Darren and I were hoping MESS would take the torch eventually. At any rate, I think you'll reconsider when compatibility reaches >99%. I've had games break because I was off by literally a single cycle. Yes, being off by 6hz a frame at 21477272hz caused Mortal Kombat II to go crazy, it was just barely missing an IRQ.

And what some of these bastardized games do with IRQ and NMI should be a crime. There's a half-dozen games that only work because of a severe edge case involving the pipeline, the six-clock /IRQ and /NMI line holding delay, and a strange case where it keeps the acknowledge bit set during that time across reads. And if you don't get it right, games will deadlock on you.

You're right that they are forgiving, but only in one direction. Some games break if you're a little too slow, but not if you're way too fast, and vice versa. With over 4,000 games it's very hard to get them all working at the same time without being perfect.
Posted By: Just Desserts Re: The SNES WIP topic - 09/23/09 05:58 PM
Originally Posted By Kale
(and don't ask to me why people should use an undefined DMA register bit as RAM, guess is again a SNES compiler issue....)


What RB said. It's not a SNES compiler issue, it was pretty well-known that unused DMA registers can be treated as RAM, and have a faster access time for such speed-critical things as, say, streaming the vocals in Clay Fighter's music. smile
Posted By: Haze Re: The SNES WIP topic - 09/23/09 06:06 PM
Originally Posted By byuu

That's unfortunate. Darren and I were hoping MESS would take the torch eventually. At any rate, I think you'll reconsider when compatibility reaches >99%. I've had games break because I was off by literally a single cycle. Yes, being off by 6hz a frame at 21477272hz caused Mortal Kombat II to go crazy, it was just barely missing an IRQ.


and I thought I'd dealt with things which were fussy over timing ...

the Megadrive is much more forgiving, I think the only real case where implementing the delays between register write and effect even matter on that is Sesame Street. (which is lucky, because there really is no comprehensive, verified, guide to the timing on that anywhere)

I do wonder how well any of this will work in MAME/MESS tho, I seem to remember slight fluctuations in the timing between frames due to slight precision errors and rounding last time I tried to do anything (which was a long time ago..)

Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 06:14 PM
Quote:
That's unfortunate. Darren and I were hoping MESS would take the torch eventually. At any rate, I think you'll reconsider when compatibility reaches >99%.


I think we should take it eventually. But I also think we have a fairly long way to go otherwise before we consider that. The steps as I'd imagine them are like this (not necessarily in this exact order, although #4 obviously goes last):

1) Master cycle-based 65c816 so all operations and memory accesses take the correct number of master cycles
2) Audit SPC700 for cycle accuracy
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?
4) Once cothreads are added to the MAME core (Aaron is interested, but I don't know what all would be involved), go ahead and schedule the 65c816, spc700, and video correctly
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 06:18 PM
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.
Posted By: Just Desserts Re: The SNES WIP topic - 09/23/09 08:29 PM
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
Posted By: byuu Re: The SNES WIP topic - 09/23/09 09:16 PM
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
Posted By: etabeta78 Re: The SNES WIP topic - 09/23/09 09:22 PM
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
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 09:30 PM
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.
Posted By: Deunan Knute Re: The SNES WIP topic - 09/23/09 09:37 PM
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.
Posted By: Just Desserts Re: The SNES WIP topic - 09/23/09 10:08 PM
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
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 10:11 PM
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.
Posted By: byuu Re: The SNES WIP topic - 09/23/09 10:44 PM
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
Posted By: R. Belmont Re: The SNES WIP topic - 09/23/09 10:46 PM
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
Posted By: byuu Re: The SNES WIP topic - 09/23/09 10:48 PM
Quote:
And that's one case where being way too fast does hurt


True, ZSNES gets destroyed with any games that use streaming HDMA audio.

Earthworm Jim 2 (sound effects)
Clayfighters: TE?
Breath of Fire 2 [T-German]
N-warp Daisakusen [PD]

And so on. Test those in MESS if you want to have some fun =)
Posted By: Kale Re: The SNES WIP topic - 09/24/09 03:51 PM
Originally Posted By etabeta78
erm... dunno Kale's feelings but I don't really care about current code.


My feelings are pretty simple: we have 3 (THREE!) features missing from the video emulation and we want to nuke everything? Please...I find it pointless and a real waste of time rather than "my feelings are hurted on it". It's not like, let's say, the old Sega System 16 emulation that was full of crap from the top of the header file to the eof bit, there is something actually good that is (let's say the things plain and simple) ruined by the current g65816 core.
Start by hooking it up something that has a better timing...er, that actually has a timing than now then we'll talk again if the video emulation is good or bad.
Posted By: etabeta78 Re: The SNES WIP topic - 09/24/09 04:07 PM
mmm... let me state this clearly before I get misunderstood: if someone else shows up today with a brand new implementation which does not break anything and adds the missing features, I would have no problem to throw everything away.

is this likely to happen? no (among other reasons, people interested in fixing the MESS code are already working on it wink )

if it would depend only on me, otoh, I would simply try to rewrite the more deeper level of the rendering to directly handle pixel positions (not sure how to do it with the current code) since it is needed by OPT.

my first attempt went bad, and I'm currently a bit more interested in NES than SNES. but I'll try again as soon as I have enough spare time to spend on it smile
Posted By: R. Belmont Re: The SNES WIP topic - 09/24/09 04:09 PM
eta: NES needs more work than SNES at the moment anyway smile
Posted By: R. Belmont Re: The SNES WIP topic - 09/24/09 04:15 PM
Quote:
My feelings are pretty simple: we have 3 (THREE!) features missing from the video emulation and we want to nuke everything?


Actually, yes. Those 3 features are big and involved and will probably involve major rewrites of the code anyway. And secondly, we fail on a lot of subtle/buggy hardware behaviors (e.g. tile number wrapping for sprites). If we adopt byuu's code all of that goes away and we never have to worry about it again. We can instead spend more time avoiding fixing the CPU timing wink
Posted By: etabeta78 Re: The SNES WIP topic - 09/24/09 04:17 PM
About NES: I'm currently listing regressions compared to 0.130 (just a couple that I can see and one of them, the crash in Lagrange Point, has already been fixed locally) and other crashes/freezes which were occurring also in the past

After that, I plan to add a bit of info I collected in the past on mappers [1] (both the supported and the unsupported ones) and to try my luck with adding a few more mappers for chinese bootlegs

[1] I've always been disappointed by the lack of info on most of the mappers. either you check the source of other emus (Nestopia and FCEUMM) or you are on your own... hopefully, MESS source could be a good place to store some of the info wink
Posted By: Kale Re: The SNES WIP topic - 09/24/09 04:25 PM
Originally Posted By R. Belmont
Quote:
My feelings are pretty simple: we have 3 (THREE!) features missing from the video emulation and we want to nuke everything?


Actually, yes. Those 3 features are big and involved and will probably involve major rewrites of the code anyway. And secondly, we fail on a lot of subtle/buggy hardware behaviors (e.g. tile number wrapping for sprites). If we adopt byuu's code all of that goes away and we never have to worry about it again. We can instead spend more time avoiding fixing the CPU timing wink


I tell you the truth: I've got the mosaic effect to work a lot better at some point, but I've nuked the code because it was affecting sprites too (likely an implementation flaw).
I repeat it, I just need good plans for all of three and nothing else (and the OBJ flag requires decent timing anyway). If you want to take byuu's code and copycat it, fine and no problem, just don't count on me on doing so.
Posted By: RColtrane Re: The SNES WIP topic - 09/24/09 05:40 PM
Let me express my humble, no-emulator-programmer, personal point of view about this 'heated' SNES topic...

Kale and JD have a good point in this discussion because they are the current SNES driver developers, and they are doing lots of improvements to it, spending their spare time to try to fix the whole thing instead of saying what should be done from today forward.

Byuu did a great work with BSNES and was kind enough to open his source code to be used in MESS. He seems to be the most 'SNES knowledged' person here, though, he's been working more as an advisor and I don't think he will have motivation to port his entire code inside MESS by himself because he has his own emulator already.

To other people I don't have much left to say. I just think that if someone else is not happy enough with the current code, put yourself to the test and rewrite this driver from scratch (based on Byuu's code or not) and see if it gets better than the current one. If it shows better results, then replace the current code and nobody will be bothered or harmed in any way.

And pleeeeeease, remember that this is only a personal opinion based on things I've read in this topic. I don't have the power to criticize anyone in this project and this is not the idea wink

Posted By: byuu Re: The SNES WIP topic - 09/24/09 06:07 PM
Quote:
My feelings are pretty simple: we have 3 (THREE!) features missing from the video emulation and we want to nuke everything?


Certainly I don't mean to force my code on you if you don't want it. I actually lose my reference license if you guys use it in MESS, and bsnes becomes less competitive, so I have nothing to gain. I was merely offering in case you were frustrated with working on the SNEeSe-based one now.

It's your baby, and we're grateful for your work regardless of how you go about improving it.

Quote:
And secondly, we fail on a lot of subtle/buggy hardware behaviors (e.g. tile number wrapping for sprites)


Indeed. Did you know that sprites at X=256 count all tiles in RTO? That's a hardware bug that is required for Super Conflict's title screen to show up properly. And if sprite size=16x32 (mode 6) with OAM big-sprites disabled and OAM interlace enabled, the height is chopped in half to 16x16. It took a lot of time to find all that crazy shit wink

Quote:
he's been working more as an advisor and I don't think he will have motivation to port his entire code inside MESS by himself


I have a very hard time with code I didn't write. MESS in particular, I've still yet to even find which file handles $2100-213f writes.
Posted By: R. Belmont Re: The SNES WIP topic - 09/24/09 06:14 PM
If Kale wants to fix all of the known and unknown problems and is confident he can it's his time and he's welcome to do it. I just thought it'd make sense to bypass the graphics entirely and work on the more interesting issues and/or more X1 variants or whatever smile
Posted By: Just Desserts Re: The SNES WIP topic - 09/24/09 07:07 PM
Originally Posted By RColtrane
Kale and JD have a good point in this discussion because they are the current SNES driver developers, and they are doing lots of improvements to it, spending their spare time to try to fix the whole thing instead of saying what should be done from today forward.


For what it's worth, the SuperFX, etc. cores were all a few days' work, tops. Including me in the list of current SNES driver developers is giving me too much credit, I think. wink
Posted By: RColtrane Re: The SNES WIP topic - 09/25/09 12:32 PM
I just don't know if Kale knows how to deal with that cycle issues, otherwise he can fall in a dead end with his current code...
Posted By: Kale Re: The SNES WIP topic - 10/19/09 04:54 PM
Question to sfc experts:

Somebody addressed to me that the game Deae Tonosama Appare Ichiban refuses to run on some kind of xbox emulator that I don't know and don't want to know about...anyway, it displays the following message:



That basically means that the copy protection failed*, I've investigated a little and found that it does the following:

7F20CB: BF 0A FF 89 LDA $89ff0a,X
7F20CF: 9F 38 00 70 STA $700038,X
7F20D3: DF 38 00 70 CMP $700038,X
7F20D7: F0 01 BEQ 7f20da ($1) ;if the branch is true, then the copy protection fails
7F20D9: 6B RTL
7F20DA: CA DEX
7F20DB: D0 EE BNE 7f20cb (-$12)


As you may know, $700038 is "reserved" memory, so that should return open bus / fixed value on the real HW anyway...now the question is: if they putted that kind of check, that means that is supposed to fail somehow on bootleg software, but why 0x7000xx? Some kind of Internal RAM for these copy devices (since that gets written with 0 then read back)?

*thanks to Gridle & DFJustin to translate that smile.
Posted By: Lord Nightmare Re: The SNES WIP topic - 10/19/09 05:48 PM
It means, much like the snes pokemon bootleg/pirate original, that the pirates added some circuitry (probably a gal and some 74xx logic) to force specific values to specific open bus addresses. Hence the cart can be considered a custom 'mapper' with added protection.

LN
Posted By: R. Belmont Re: The SNES WIP topic - 10/19/09 06:22 PM
Isn't 7000xx battery RAM? That seems like a bog-standard "fail if there's NVRAM and we don't want it" check that was effective against many early copiers (which always provided the max amount that would fit in the mapping mode).

Also, is the problem that it fails on MESS, or just on some xbox thing?
Posted By: Kale Re: The SNES WIP topic - 10/19/09 06:33 PM
Nah, it's not happening in MESS, only on that xbox thing...I've asked just for curiosity smile
Posted By: byuu Re: The SNES WIP topic - 11/01/09 07:59 AM
::bump::

I found a way to get Super Game Boy support up and running in full.

The cheap, easy way: the SNES sets $2181-3 to a screen index where it expects $7800 to read from. It's offset by either $5000+ or $6800+, as the screen is apparently double-buffered. Subtract that, divide by 320 (size of a tile row), and set the read index there.

The hard way: it seems that reads are always linear across the screen, but certain actions cause one to miss four or more tile rows (eg entering the menu, processing certain SGB commands, etc.) When this happens, it doesn't tell the ICD2 chip anything, so I believe the chip also knows that $7800 hasn't been read and four tile rows have passed. Meaning it's probably buffering at most 1,280 bytes. So after reading $7800 again after so much time has passed in the LY counter, jump ahead to the current position.

Looks like $6000 is the GB-level LY counter, too. If you try and simulate the counter via cycle ticks, the video gets desynchronized and starts flickering really badly. Just feed it the real LY counter and you're good.

The Space Invaders arcade mode game sucks, too. Not at all worth the effort :P

Posted By: R. Belmont Re: The SNES WIP topic - 11/01/09 10:49 PM
Very nice smile
Posted By: Just Desserts Re: The SNES WIP topic - 11/02/09 01:53 AM
byuu, can I use your source code to try implementing full SGB support in MESS? smile
Posted By: byuu Re: The SNES WIP topic - 11/02/09 03:36 AM
Of course. I think it'd be great to have two full SGB emulators, in case certain games only work in one or the other. Plus I could use help with the multi-player support. I'm not entirely sure how you increment to choose the next gamepad. The pandocs method breaks games and seems to increment way too much.

All you really need for my work is supergameboy/interface. The stuff under bsnes/src/chip/supergameboy is just the DLL passthru and my $7800 access trick.

The fun part will be using MESS' GB support instead of Gambatte (which is GPLv2.) You'll need to be able to read out the LY counter, hook DMG $ff00 accesses, and make sure all video up to the current scanline is rendered when reading from $7800.

If you take the easy way like I did, you'll need to feed the S-CPU $2180 access address to the SGB core. And if you take the hard way, please do share if you can figure it out, heh.

Feel free to ask any questions and I'll do my best to explain.
Posted By: Anna Wu Re: The SNES WIP topic - 11/02/09 06:59 AM
Originally Posted By Just Desserts
byuu, can I use your source code to try implementing full SGB support in MESS? smile


If we add to the snes driver, we need a second cartslot ?
One for the SGB/SGB2 cart and the second for the GB cart ?
Posted By: etabeta78 Re: The SNES WIP topic - 11/02/09 07:15 AM
no. at the moment, I think the only solution would be to have a separate driver with the sgb bios and the gameboy hardware and you only load .gb carts to it

[dream=on]
in a perfect world (i.e. once we have devices everywhere in the source), we would have a single cartslot with a "child" cartslot device so that you emulate mounting the cart inside the sgb expansion
[dream=off]
Posted By: Anna Wu Re: The SNES WIP topic - 11/02/09 07:20 AM
Originally Posted By etabeta78
no. at the moment, I think the only solution would be to have a separate driver with the sgb bios and the gameboy hardware and you only load .gb carts to it

[dream=on]
in a perfect world (i.e. once we have devices everywhere in the source), we would have a single cartslot with a "child" cartslot device so that you emulate mounting the cart inside the sgb expansion
[dream=off]


This will be great. So we can use also other special carts like BS-X .
Posted By: byuu Re: The SNES WIP topic - 11/02/09 05:17 PM
It's the Sufami Turbo that is going to ruin that approach:
http://www.gamersgraveyard.com/repository/snes/peripherals/sufamiturbo.html

It accepts two carts, and you can create custom games by combining certain ones. So it's required to have a mechanism for loading more than one.

And then there's the BS-X non-Satellaview carts like Same Game. You can optionally insert a BS-X data pack to give the game custom graphics, such as one for Tengai Makyou.



I figured I may as well treat all multi-carts the same for consistency, although to be honest I do find it tedious to load multi-carts as it stands now.
Posted By: incog Re: The SNES WIP topic - 11/02/09 05:21 PM
Originally Posted By Anna Wu
This will be great. So we can use also other special carts like BS-X .


Or the even more bizarre Bandai Sufami Turbo



Edit: Damn, beaten to it.
Posted By: byuu Re: The SNES WIP topic - 11/02/09 06:14 PM
That's good, now I don't have to double post smile

http://img202.imageshack.us/img202/2235/bomberman2.png

Multi-player is pretty simple. Here's a trace log of writes to $ff00:

Code:
read from 14
1,0
read from 14
read from 14
1,1
0,1
read from 15
read from 15
read from 15
read from 15
read from 15
read from 15
1,1
read from 15
1,0
read from 15
read from 15
1,1
0,1
read from 12
read from 12
read from 12
read from 12
read from 12
read from 12
1,1
read from 12
1,0
read from 12
read from 12
1,1
0,1
read from 13
read from 13
read from 13
read from 13
read from 13
read from 13
1,1
read from 13
1,0
read from 13
read from 13
1,1
0,1
read from 14
read from 14
read from 14
read from 14
read from 14
read from 14
1,1


The pattern is obvious enough.

Write 1,1 to select and read out the ID (increment ID# here)
Write 1,0 to read out D-pad
Write 1,1 again for some reason (do not increment ID# here)
Write 0,1 to read out buttons
...
Write 1,1 to select and read out the NEXT ID (increment ID# here)
etc.

Still working on some fine details regarding initial values, what happens with MLT_REQs, etc.
Posted By: byuu Re: The SNES WIP topic - 11/03/09 05:21 PM
Quote:
now I don't have to double post


Or maybe I do, meh.

Had a lot of trouble getting all games to detect the SGB hardware when using $6003.d5,d4 to determine 1-player/2-player/4-player mode for masking the joypad ID. Games like Shin Megami Tensei Devil Children were writing out MLT_REQ and then immediately reading the joypad ID. This gives the BIOS no time to react and update $6003.

So I'll keep being evil for now:
Code:
  if(packetlock) {
    if(p15 == 1 && p14 == 0) {
      if((joyp_packet[0] >> 3) == 0x11) {
        mmio.mlt_req = joyp_packet[1] & 3;
        if(mmio.mlt_req == 2) mmio.mlt_req = 3;
      }


Pull the MLT_REQ state right out of the packet once it completes. Technically no reason the hardware can't do this, although it'd be quite odd for it to use $6003 at all in that case.

I also set it to not increment until both the D-pad and buttons for each controller has been read out. I'm not entirely sure how that's supposed to work, but this works for all the games I'm aware of, so ... whatever.

This also eliminates the need for the strange 0xf - (joyp_id ^ 3) trick I was using to get past the SMT: DC SGB test.

Next, Zelda DX v1.0 and v1.1 had some sort of glitch. Compare v1.0:
Code:
MASK_EN
1,1
1,0
0,1
1,1
0,0 <- this starts a new packet transfer
1,0
0,1
1,1
1,0
0,1
1,1


With v1.2:
Code:
MASK_EN
1,1
1,0
0,1
1,1
1,0 <- and yet it's missing here
0,1
1,1
1,0
0,1
1,1


It's sending a packet start transfer of P15=0,P14=0 periodically. With my previous release, this would eventually spit out a PAL01 command that sets all colors to black, effectively "turning the screen off."

Given that there was a revision to fix this, I expect this bug existed on real hardware as well; but it was most certainly affected by the line hold time requirements.

pandocs states:
Quote:
Data and reset pulses must be kept LOW for at least 5us. P14 and P15 must be kept both HIGH for at least 15us between any pulses.


So probably it was getting all 1's (which is an invalid command, likely ignored) or 1's and 0's. The latter is easy, just disable the if(strobelock) return; line. Fixes Zelda DX.

The proper fix, which I'll work on for a later release, is likely to take the time a value has been set into account before acknowledging it and performing bus contention ORing and such.

One will also note the lack of 1,1 hold that pandocs requests between the 0,1 and 1,0; as that's obviously a joypad polling routine with an errant 0,0 write mixed in somewhere.

Next, audio. With stock SGB audio volume, the SNES sound effects are so quiet you can't even hear them. By dividing the SGB samples by 3, the two blend much better together.

To handle the downsample from 2147KHz to 32KHz, blargg provided a moving average downsampler, which is said to be superior to a 4-tap hermite filter for this kind of difference.

Code:
void Audio::coprocessor_sample(int16 left, int16 right) {
  if(r_frac >= 1.0) {
    r_frac -= 1.0;
    r_sum_l += left;
    r_sum_r += right;
    return;
  }

  r_sum_l += left  * r_frac;
  r_sum_r += right * r_frac;

  uint16 output_left  = sclamp<16>(int(r_sum_l / r_step));
  uint16 output_right = sclamp<16>(int(r_sum_r / r_step));

  double first = 1.0 - r_frac;
  r_sum_l = left  * first;
  r_sum_r = right * first;
  r_frac = r_step - first;

  //write to sound card / mixing buffer / whatever here
  //this is called @ 32KHz
  output_coprocessor_sample(output_left, output_right);
}


Lastly, I also added save state support. Stupid, but fun.

It might be easier to hook up libsupergameboy with Gambatte into MESS, and then work on merging over MESS' DMG core.
Posted By: Just Desserts Re: The SNES WIP topic - 11/03/09 05:25 PM
Originally Posted By byuu
It might be easier to hook up libsupergameboy with Gambatte into MESS, and then work on merging over MESS' DMG core.


Disagreement. I'd wager if I had an up-to-date copy of your source tree, I could just use MESS's DMG core right away. smile
Posted By: judge Re: The SNES WIP topic - 11/03/09 05:28 PM
Originally Posted By byuu

Had a lot of trouble getting all games to detect the SGB hardware when using $6003.d5,d4 to determine 1-player/2-player/4-player mode for masking the joypad ID. Games like Shin Megami Tensei Devil Children were writing out MLT_REQ and then immediately reading the joypad ID. This gives the BIOS no time to react and update $6003.

So I'll keep being evil for now:
Code:
  if(packetlock) {
    if(p15 == 1 && p14 == 0) {
      if((joyp_packet[0] >> 3) == 0x11) {
        mmio.mlt_req = joyp_packet[1] & 3;
        if(mmio.mlt_req == 2) mmio.mlt_req = 3;
      }


Pull the MLT_REQ state right out of the packet once it completes. Technically no reason the hardware can't do this, although it'd be quite odd for it to use $6003 at all in that case.


Could it be that it simply halts the cpu in such a case?
Posted By: byuu Re: The SNES WIP topic - 11/03/09 06:30 PM
Quote:
I'd wager if I had an up-to-date copy of your source tree, I could just use MESS's DMG core right away.


You always do, you have WIP access on my forum :P
And the latest supergameboy is up on my page: http://byuu.org/bsnes/

Here's the fixed joyp_write() function, which is the only difference from what is already available:
Code:
void SuperGameBoy::joyp_write(bool p15, bool p14) {
  //===============
  //joypad handling
  //===============

  if(p15 == 1 && p14 == 1) {
    if(joyp15lock == 0 && joyp14lock == 0) {
      joyp15lock = 1;
      joyp14lock = 1;
      joyp_id = (joyp_id + 1) & 3;
    }
  }

  if(p15 == 0 && p14 == 1) joyp15lock = 0;
  if(p15 == 1 && p14 == 0) joyp14lock = 0;

  //===============
  //packet handling
  //===============

  if(p15 == 0 && p14 == 0) {
    //pulse
    pulselock = false;
    packetoffset = 0;
    bitoffset = 0;
    strobelock = true;
    packetlock = false;
    return;
  }

  if(pulselock) return;

  if(p15 == 1 && p14 == 1) {
    strobelock = false;
    return;
  }

  if(strobelock && (p15 + p14 != 0)) {
    //this is a malformed packet
    packetlock = false;
    pulselock = true;
    bitoffset = 0;
    packetoffset = 0;
  }

  if(strobelock) return;

  //p15:1, p14:0 = 0
  //p15:0, p14:1 = 1
  bool bit = (p15 == 0);
  strobelock = true;

  if(packetlock) {
    if(p15 == 1 && p14 == 0) {
      if((joyp_packet[0] >> 3) == 0x11) {
        mmio.mlt_req = joyp_packet[1] & 3;
        if(mmio.mlt_req == 2) mmio.mlt_req = 3;
      }

      if(packetsize < 64) packet[packetsize++] = joyp_packet;
      packetlock = false;
      pulselock = true;
    }
    return;
  }

  bitdata = (bit << 7) | (bitdata >> 1);
  if(++bitoffset < 8) return;

  bitoffset = 0;
  joyp_packet[packetoffset] = bitdata;
  if(++packetoffset < 16) return;
  packetlock = true;
}


It rejects invalid packets, which seems to work great for both Dracula and Zelda DX; without breaking any other games that I know of.

Quote:
Could it be that it simply halts the cpu in such a case?


I suppose that is technically possible. I don't see a command to restart the SGB after packets are transmitted, and if we restarted after a $700f read, it'd still probably be too late to change $6003. Plus if the SGB got stopped in the middle of gameplay while sending packets, the audio would most likely stall out for a couple MS, which would cause sharp popping. Thus, it probably doesn't halt.
Posted By: TheTrout Re: The SNES WIP topic - 11/09/09 03:03 AM
Hey, just out of curiosity, has anyone ever looked into why the cursor in Tetris Attack / Panel de Pon slowly drifts upward by itself? It renders the game unplayable and it bums me out that one of my favorite SNES games is one of the few not running great in MESS.
Posted By: Sune Re: The SNES WIP topic - 11/09/09 03:39 AM
Confirmed.

You can temporarily nudge the cursor back in line with the bricks by pressing Z or X.

Not only is it highly playable and fun, Tetris Attack also has a great soundtrack. Whoever did the music on this game was definitely a bass player..the bass even takes the lead in some of the songs.

Posted By: Lord Nightmare Re: The SNES WIP topic - 11/09/09 07:24 AM
Missing offset-per-tile emulation in the snes ppu is why tetris attack doesn't work quite right. Or that's what I heard, IIRC.

LN
Posted By: Just Desserts Re: The SNES WIP topic - 11/09/09 12:54 PM
Yeah, could be the same reason why Puzzle Bobble is pretty hosed, too.
Posted By: etabeta78 Re: The SNES WIP topic - 11/09/09 01:01 PM
fwiw, once I get stuck with SMS VDP and RealLife leaves me some spare time, I plan to try again to add missing SNES video features.

don't hold your breath though, it could take some time...
Posted By: RColtrane Re: The SNES WIP topic - 11/15/09 04:49 PM
The 'pixel aspect' video option is no longer working in this driver. And the 'switchres' option has weird results, it stretches the screen horizontally too much, cropping the image on both sides. I think these issues have started after the recent massive updates. Please verify.
Posted By: R. Belmont Re: The SNES WIP topic - 11/15/09 05:43 PM
Those are correct behavior. There is no other way to properly emulate the SNES video hardware, so stick with -noswitchres.
Posted By: RColtrane Re: The SNES WIP topic - 11/15/09 06:26 PM
Originally Posted By R. Belmont
Those are correct behavior. There is no other way to properly emulate the SNES video hardware, so stick with -noswitchres.


Ok... It seems to be my CRT monitor that doesn't support the needed SNES resolution. With LCD monitors it looks great!
Posted By: Multipass Re: The SNES WIP topic - 11/24/09 12:17 AM
Please all just one little question, Snes driver not support ExHiRom of 6mbit? i have tesed it but not work, thanks for reply wink
Posted By: etabeta78 Re: The SNES WIP topic - 11/24/09 07:19 AM
it supports the correct loading (MESS works like bsnes for loading). but the game probably fails due to other emulation problems. what title are you trying to play?
Posted By: Multipass Re: The SNES WIP topic - 11/24/09 10:28 AM
Dragon Quest 3 Translation, it's an expanded rom (so ExHiRom) of 6mb, but when i load it on mess snes driver, not work frown
Posted By: Anna Wu Re: The SNES WIP topic - 11/24/09 10:41 AM
The original Dragon Quest III - Soshite Densetsu (J) seems to work.

Posted By: Multipass Re: The SNES WIP topic - 11/24/09 10:51 AM
Yes of course, because this rom is not expanded (4mb). Rom expanded (and so rom more than 4mb) not supported in snes driver? (Tales of Phantasia, Star Ocean)
Posted By: etabeta78 Re: The SNES WIP topic - 11/24/09 11:00 AM
Star Ocean reaches the title screen with no problems (if you change the CPU clock as soon as emulation starts, so to avoid the sync problem that MESS still has) That's why I said that they are supported.

It might be that the patched rom is not recognized as exhirom by the loading routine. does the game work on bsnes?
Posted By: Multipass Re: The SNES WIP topic - 11/24/09 11:31 AM
wait i test it
Edit: The rom work with bsnes 0.057 version, but with mess , emulator crash directly

Posted By: etabeta78 Re: The SNES WIP topic - 11/24/09 02:09 PM
mmm... I'll take a look asap. it seems like we have broken something at some point smile

thanks for the report
Posted By: etabeta78 Re: The SNES WIP topic - 02/10/10 02:40 PM
After some time, I can finally announce that MESS does not crash anymore with large roms like Tales of Phantasia and the translation of DQ3.

moreover, I started to work a bit towards offset-per-tile and other improvements, but the road is still long...

Please report any regression which appears with the new code, so that it can be tracked down immediately.
So far, I only found the menu text in Seiken Densetsu 3 (at character selection) has broken. I hope to be able to fix it soon...
Posted By: Justin Re: The SNES WIP topic - 02/11/10 02:33 AM
The swinging pendulum is now missing from the Chrono Trigger title screen.
Posted By: etabeta78 Re: The SNES WIP topic - 02/11/10 07:22 AM
can you approximately track down when it broke? here, rev 7316 works like in 7250 (i.e. before my changes), hence I fear it has happened earlier...
Posted By: Justin Re: The SNES WIP topic - 02/12/10 05:48 AM
Hmm, you're right. It seems to have broken some time between the 0.135 and 0.136 releases.
Posted By: etabeta78 Re: The SNES WIP topic - 03/01/10 06:55 PM
I guess around the same time Super Tennis got broken as well. This is fairly annoying since I really like this game.

Once I'm done with the current cleanups, I'll try to track down both breakages (Chrono Trigger and Super Tennis)...
Posted By: etabeta78 Re: The SNES WIP topic - 03/01/10 09:03 PM
it turned out that both games had been broken by rev.6829.

by analyzing the changes, there were a couple of small bugs (it was safer to write ram before starting the timers and division should take 16 cycles, according to Anomie docs) but even fixing these details the games had problems.

therefore, the timers remain commented out until the other timing issues affecting the driver have been better understood

@Judge: were there games in need of these timers? some additional test case could be very handy smile
Posted By: judge Re: The SNES WIP topic - 03/01/10 09:26 PM
Yes, there was at least one game that depended on the timers
Posted By: etabeta78 Re: The SNES WIP topic - 03/01/10 09:37 PM
if you can remember which one, I'll try to see if I can fix it without breaking the rest of the games smile

of course, if you have any idea of an alternative fix, I'm open to any help/suggestion
Posted By: judge Re: The SNES WIP topic - 03/01/10 09:47 PM
Bof2 translation.
Posted By: etabeta78 Re: The SNES WIP topic - 03/01/10 10:17 PM
More weirdness: requiring 16 cycles for division (as per Anomie's docs) breaks several things, e.g. triforce pieces geometry in Zelda 3 intro...

This confirms once more that the timing in the driver is pretty sloppy (as if the many games requiring CPU overclock to start would not suffice to prove it)

I might come back to this later, but I'm more focused on understanding why better tile wraparound (needed to improve Tokimeki Memorial ingame graphics) breaks shadows in Zelda 3 intro, and why my tentative implementation of OPT breaks more games than it fixes.

For the time being, I will add a comment about Bof2 in the source.
Posted By: judge Re: The SNES WIP topic - 03/01/10 10:24 PM
The timing is most likely depended on the actual steps made by the hardware.
Posted By: byuu Re: The SNES WIP topic - 03/02/10 07:07 AM
I tried to warn you guys when Cowering was boasting about this in MESS and for me to fix my emulator :P

I said you'd break a ton of games, just to display d4s' "not for sale" screen on his unofficial translation.

You either do this one right, and spend the several months running real hardware tests to reverse the underlying math algorithm, or you leave those delays out. Otherwise you are asking for trouble.

Reference with all the technical background on just how complex the mul / div delays really are:
http://www.allgoodthings.us/mambo/index....d=2&id=3791
Posted By: etabeta78 Re: The SNES WIP topic - 03/02/10 08:07 AM
I missed that topic. thanks for the link!
Posted By: judge Re: The SNES WIP topic - 03/02/10 09:17 AM
At least there are some more known test cases now wink
Posted By: RColtrane Re: The SNES WIP topic - 03/02/10 01:04 PM
Originally Posted By judge
Yes, there was at least one game that depended on the timers


Rushing Beat
Posted By: byuu Re: The SNES WIP topic - 03/03/10 12:26 AM
Rushing Beat plays fine here without any mul/div timing.

The only thing the mul/div timers do is allow you to return incorrect mul/div results if the registers are read too early. The calculation runs in parallel with the SNES, so the S-CPU timing isn't really affected by this.

The only way a game can 'not work' by not emulating these calculation delays is if they ask for a value to be multiplied or divided, and only work when the result of that operation is incorrect. Do think about how absurd that would be for a moment.

Now even in the unlikely event that a game out there did rely on this, it would be expecting at least the 'correct' wrong result, and not whatever you guys return in that instance (0x00? The original value? Both are wrong.)

If it fixed the game in MESS, it was because of some other error being avoided by it.

Don't get me wrong, I am not making excuses for not supporting this properly. It sucks, and it's a gaping problem in our emulators if we want to claim they are accurate. It's just a really tough problem, and faking this delay isn't going to do any good; except maybe to alert ROM hackers / translators / demo coders that this delay exists when their code gets the wrong results. ( and subsequently result in RHDN posts that our emulators are inaccurate because ZSNES runs their broken code fine :P )

I need someone who can run tests on real hardware and is willing to bang out a metric ton of code and test results to analyze. I can't find the motivation right now to do that myself.
Posted By: RColtrane Re: The SNES WIP topic - 03/03/10 11:56 AM
Originally Posted By byuu
Rushing Beat plays fine here without any mul/div timing.


How do you make it to work? Here I'm getting only a black screen and nothing happens...:(
Posted By: Kale Re: The SNES WIP topic - 03/03/10 01:19 PM
I think he's referring to his bsnes emu. wink

For the 100th time, Rushing Beat has problems with the CPU timing, not the mul/div ... guess it doesn't even use that feature.

Anyway ... I've recently tried Brandish 2 on MESS ... there's a funny bug right at the beginning of the game on which the soldiers goes out of a door ... MESS emulates this by making them going in *erratic* directions ... I don't even know if it's logic or video related shocked
Posted By: ht1848 Re: The SNES WIP topic - 03/04/10 05:08 PM
was there any news on Ballz decapping? or did I miss it?
Posted By: Kale Re: The SNES WIP topic - 03/04/10 05:09 PM
Ok, checked Brandish 2 again after the compile fix ... current build now works, so I guess it was one of the 100s bugs that eta introduced just before 0.136 release ;P
Posted By: R. Belmont Re: The SNES WIP topic - 03/04/10 05:10 PM
I poked Guru about the decapping (the Saturn SH-1 CD controller is also in line) and he said they expect to do some stuff for us soon.
Posted By: Kale Re: The SNES WIP topic - 03/04/10 06:13 PM
It's a great news, but I don't know how it relates to this topic and the Super Famicom :P
Posted By: Haze Re: The SNES WIP topic - 03/04/10 06:41 PM
Originally Posted By Kale
It's a great news, but I don't know how it relates to this topic and the Super Famicom :P


Some of the SNES chips are inline to be decapped along with the Saturn SH1. I think it has plenty to do with the SUper Famicom ;-)
Posted By: Kale Re: The SNES WIP topic - 03/04/10 06:48 PM
Ah, ok ... it was just because I've read Saturn and didn't related to that ;P
Posted By: R. Belmont Re: The SNES WIP topic - 03/04/10 06:59 PM
Quoting 2 posts above that on this topic:

Quote:
was there any news on Ballz decapping? or did I miss it?


"Ballz decapping" being the SNES DSP-1.
Posted By: etabeta78 Re: The SNES WIP topic - 03/04/10 08:08 PM
Originally Posted By Kale
Ok, checked Brandish 2 again after the compile fix ... current build now works, so I guess it was one of the 100s bugs that eta introduced just before 0.136 release ;P


you might find interesting the fact that the bug was introduced by judge and not by me (also because I haven't touched the driver from last fall to last week wink ) :P

that said, what I broke a couple of weeks ago was Seiken Densetsu 3 player select screen. however, I never spent time to fix it because I was trying to rewrite the BG drawing routines to be more similar to BSNES ones (so that it's easier to debug MESS, being possible to compare the two sources). I will never thank enough byuu for writing such a clear emulator!

at last, today I managed to complete the changes and to re-add most of the features in the rewritten routines. these are the result:

- Seiken Densetsu 3 back in its previous state


- Tokimeki Memorial better than ever (no text yet, but you can see that priorities and resolutions are correct)


- and, as a bonus, an almost working implementation of offset-per-tiles mode


on the negative side, there are a couple of hires issues which results in not 100% perfect hires texts (e.g. in Desert Fighter,

but it only affects text, Suchi Pai works) and in a few of other minor problems (e.g Star screens in the SNES Test ROM do not scroll properly).

since the gain in readability and opt are imho clear improvements, I will commit these changes as a series of patches either later tonight or tomorrow.

stay tuned...
Posted By: R. Belmont Re: The SNES WIP topic - 03/04/10 08:31 PM
Nice!
Posted By: byuu Re: The SNES WIP topic - 03/04/10 10:14 PM
Quote:
I poked Guru about the decapping (the Saturn SH-1 CD controller is also in line) and he said they expect to do some stuff for us soon.


This is excellent news!

If this is a success, and we're able to emulate it properly, then we can gain perfect DSP-3 and DSP-4 support just by dumping the PROMs and using them in place of the DSP-1 PROM. That will lower the number of unemulated games to two.

I'm certain we can easily raise $250 or more for each of the remaining DSPs, if we can show the results with the DSP-1B PROM.

And if they are willing to reveal how it was done, we can probably have neviksti take a stab at the other ones.

Quote:
(e.g Star screens in the SNES Test ROM do not scroll properly).


I'm sure you're talking about some other issue, but hires and scrolling really don't go well together at all. Given the way it works you're guaranteed to have a jittery mess every other frame when scrolling. Makes it very hard to take a good screenshot.
Posted By: etabeta78 Re: The SNES WIP topic - 03/05/10 02:43 AM
about "scrolling stars", I think the Test Program alternates main & sub screen to give a sort of scrolling effect. my bet is that we fail to properly emulate some addsub corner case, but my first attempt to fix it, failed. I will try again once I've finished a few other things I wanted to clean up.

from the top of your head, can you remember:

* any game which uses OPT actively in easy to spot places, in addition to SNES Test Program (for the Mario screen above)? I know Puzzle Bobble uses Mode 4, but I was not able to find an occurrence of opt valid bit written

* any game which uses pseudo hires?

* any game which uses mosaic in Mode 5/6?

I think my current code still has some problem with the cases above, but I would need some separate test case for each of them, in order to test fixes...
Posted By: judge Re: The SNES WIP topic - 03/05/10 07:54 AM
Originally Posted By etabeta78
Originally Posted By Kale
Ok, checked Brandish 2 again after the compile fix ... current build now works, so I guess it was one of the 100s bugs that eta introduced just before 0.136 release ;P


you might find interesting the fact that the bug was introduced by judge and not by me (also because I haven't touched the driver from last fall to last week wink )


Wow, I'm good at breaking stuff it seems laugh
Looks like Brandish 2 is another test case for the div/mult timing then (if someone ever manages to figure it out).
Posted By: AWJ Re: The SNES WIP topic - 03/05/10 09:48 AM
Originally Posted By byuu
I'm sure you're talking about some other issue, but hires and scrolling really don't go well together at all. Given the way it works you're guaranteed to have a jittery mess every other frame when scrolling. Makes it very hard to take a good screenshot.


Why's that? Does the SNES generate even and odd fields differently in hires mode?
Posted By: R. Belmont Re: The SNES WIP topic - 03/05/10 01:31 PM
AFAIK the Chrono Trigger logo is supposed to animate using OPT - there's a bugzilla on it.
Posted By: Justin Re: The SNES WIP topic - 03/05/10 03:30 PM
Yeah there are two OPT bugs:
http://bugzilla.mess.org/show_bug.cgi?id=1843
http://bugzilla.mess.org/show_bug.cgi?id=1847
The second one seems to be almost working now.

Current SVN seems to have a problem where vertical scrolling works OK, but horizontal scrolling is chunky (scrolls several pixels at once rather than one at a time). This can easily be seen at various points in the Chrono Trigger intro.
Posted By: Kale Re: The SNES WIP topic - 03/05/10 03:33 PM
Originally Posted By etabeta78

but it only affects text, Suchi Pai works) and in a few of other minor problems (e.g Star screens in the SNES Test ROM do not scroll properly).


To me it looks something very "simple" like swapped x dots?

I also wonder why the text doesn't appear in Tokimeki Memorial or the nvram bug in Fushigi no Dungeon 2 / Super Drift Out, maybe it's the right time to check the SNES again, mainly because my current MAME alternatives aren't very satisfactory right now ...
Posted By: etabeta78 Re: The SNES WIP topic - 03/05/10 03:56 PM
@Justin: yeah, I noticed those bugzilla entries after Arbee's comment. and I was positively surprised by the improvement in Xmas demo. I'll take a look at the horizontal problem soon (I have a few cleanups pending which will be soon in svn)

@Kale: the text problem, which also happen in Seiken Densetsu 3, is related to either subscreen masking or color blending between main/subscreen. if you press Numkey 6 during emulation, you will se that toggling the screen fixes the problem. I still haven't found the culprit though (there are a couple of bugs in current svn, but I have fixed them locally and the hires problem is still there... will investigate more later)

about Tokimeki text, I was blaming DMA/HDMA since the text is not drawn anywhere apparently, but I haven't investigated further because I was already more than busy with adding OPT wink

of course, you are welcome to contribute smile
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/05/10 10:10 PM
Games which use PseudoHires (which I can remember):
Jurassic Park (go to any of the communication tower things which bring up the 'mr. dna's dino trivia'; also the hud/score at bottom may use pseudohires as well?)
Kirby's Dreamland 3 (SA-1 game; pseudohires is used for transparent clouds and water on some levels)

LN
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/05/10 10:22 PM
Originally Posted By AWJ

Why's that? Does the SNES generate even and odd fields differently in hires mode?


In Pseudohires mode, yes. In hires mode, I think so.

LN
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 11:01 AM
fixed hires text problem.

Seiken Densetsu 3

Desert Fighter


we were starting every hires line from the first mainscreen pixel followed by the first subscreen pixel, while things should go the other way around.

while at it, I documented the way color math works for hires (according to anomie's docs) and I made the debug key switching between subscreen and mainscreen to properly work in all cases
Posted By: Rychem Re: The SNES WIP topic - 03/06/10 01:06 PM
I am not sure if anyone else is come across this but with the recent changes in the snes driver. Super Mario World doesn't quite play the way it used to. The Mario sprite is offset on the level select screen and in level the background indexes across the screen making the game very hard to play. I have also noticed that the attract screen in Super Mario Kart does this as well.
Posted By: Xor Re: The SNES WIP topic - 03/06/10 01:59 PM
These are probably well known but anyways here are a couple of problems I've ran into with the 1.36 release (maybe fixed?)

TMNT Tournament Fighters







Tiny Toon Adventures Wacky Sports (broken graphics, locks up after gameplay demo)




Also Super Robot Taisen Gaiden Masou Kishin doesn't start and exibits this string in the terminal "warning: write to SOUND TEST register with data ff!"


Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 03:17 PM
Originally Posted By Rychem
I am not sure if anyone else is come across this but with the recent changes in the snes driver. Super Mario World doesn't quite play the way it used to. The Mario sprite is offset on the level select screen and in level the background indexes across the screen making the game very hard to play.


are you using 0.136? in current svn I cannot reproduce this problem

Originally Posted By Rychem
I have also noticed that the attract screen in Super Mario Kart does this as well.


again, Super Mario Kart runs in current svn exactly like in bsnes... I see no problem.

Originally Posted By Xor
These are probably well known but anyways here are a couple of problems I've ran into with the 1.36 release (maybe fixed?)

TMNT Tournament Fighters
Tiny Toon Adventures Wacky Sports (broken graphics, locks up after gameplay demo)


yes these are fixed (they suffered the same problem as Super Tennis and Chrono Trigger).

Originally Posted By Xor
Also Super Robot Taisen Gaiden Masou Kishin doesn't start and exibits this string in the terminal "warning: write to SOUND TEST register with data ff!"


This game has never worked in MESS, but I'm not sure if anybody had ever reported it. Thanks for pointing it out.


I suggest both of you to use Bobz build ( http://bobz38.free.fr/mess_autobuild/index.php ) to test SNES games in MESS, since 0.136 is definitely broken.
Posted By: Xor Re: The SNES WIP topic - 03/06/10 03:57 PM
Originally Posted By etabeta78

I suggest both of you to use Bobz build ( http://bobz38.free.fr/mess_autobuild/index.php ) to test SNES games in MESS, since 0.136 is definitely broken.

Will do!

Some quick tests (using Bobz build):

Tetris Battle Gaiden (works a bit into game, but turns black and unresponsive if you let it enter actual gameplay/demonstration)

TMNT Tournament Fighters (still shows this graphical error:)


Super Back to the Future II & Sugoi Hebereke (changes background color but shows no graphics, works in 0.136)

Super Family Tennis (problem with hires logo, players don't show in gameplay/demonstration)
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 05:54 PM
Originally Posted By Xor

TMNT Tournament Fighters (still shows this graphical error:)


This bug is indeed still present.

Originally Posted By Xor

Some quick tests (using Bobz build):

Tetris Battle Gaiden (works a bit into game, but turns black and unresponsive if you let it enter actual gameplay/demonstration)


could you explain me what do you mean exactly with "let it enter actual gameplay/demonstration"? I think this is working now, but I would like to be sure I'm not checking something different from what you meant...

Originally Posted By Xor

Super Back to the Future II & Sugoi Hebereke (changes background color but shows no graphics, works in 0.136)

Super Family Tennis (problem with hires logo, players don't show in gameplay/demonstration)


not confirmed with new changes done today. I tested Japanese versions of the games you mentioned and:




could you try again tomorrow (Bobz build gets updated once per day) and report if these games work?

anyway, thanks for testing smile
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 06:04 PM
svn 7520:[SNES] Fixed serial joystick reads to work as per docs.

This fixes a small regression introduced by Kale while fixing Suchie-Pai (rev. 5458). Now, Super Double Dragon and Super Star Wars Emprire Strikes Back recognize Start inputs again.

Unfortunately, this does not help Super Tetris 2 + Bombliss & Wordtris, whose inputs aren't recognized probably due to CPU timing problems... frown

EDIT: btw, this is another proof that few people actually use MESS for SNES: nobody noticed those games were broken since last summer... well, hopefully things will get better in future
Posted By: Kale Re: The SNES WIP topic - 03/06/10 06:06 PM
iirc Bishoujo Janshi Suchie Pai serial crap was related to romset v1.00 and not v1.01, you've checked that, right?
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 06:14 PM
yeah I tested that rom, and I think the problem is fixed: simply reverting your fix, Start was not recognized anymore. with the current code, it is.

or should I look for different issues?
Posted By: Kale Re: The SNES WIP topic - 03/06/10 06:19 PM
Think it was just the start button, can't really remember smile
Posted By: Xor Re: The SNES WIP topic - 03/06/10 06:38 PM
Whoa, weird. I tried them now and super family tennis, sugoi hebereke and super back to the future works. The only difference this time is that I explicitly started each game from the commandline while in the earlier tests I used the built-in file manager to select various games in succession. Tetris Battle Gaiden still turns black if you wait for the demonstration sequence (which shows gameplay) though (both in bobz version and in 0.136).

Also tried Dokapon Gaiden - Honoo no Audition which gives black screen (both bobz and 0.136)

I will make some more tests with a new build tomorrow.
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 06:55 PM
thanks.

btw, for the time being avoid using the internal file manager, or at least hard-reset emulation with Shift+F3 after you loaded a game

SNES emulation is currently affected by a bunch of multisession bugs which will be fixed once the PPU will become a device (after 0.137)
Posted By: jbo_85 Re: The SNES WIP topic - 03/06/10 10:21 PM
The problem with offset-per-tile mode is that vshift isn't updated using the new ypos.
Posted By: R. Belmont Re: The SNES WIP topic - 03/06/10 10:24 PM
See, now that's the kind of bug report I can really get behind smile
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 10:25 PM
@jbo_85: do you have a proposal for a fix? otherwise, I will take a look at vshift tomorrow (I'm currently busy with additional controller types)...
Posted By: jbo_85 Re: The SNES WIP topic - 03/06/10 10:53 PM
It can be fixed by putting:
yshift = ypos & ((8 << tilesize) - 1);
on line 728 in video/snes.c.
Posted By: etabeta78 Re: The SNES WIP topic - 03/06/10 11:40 PM
sir, you made my day laugh




Thanks a lot for spotting the problem and providing a solution.
Posted By: R. Belmont Re: The SNES WIP topic - 03/06/10 11:59 PM
Horizontal scrolling seems weirdly choppy on latest SVN. You can see it to some extent in Super Mario World, but it's really bad if you start up Secret of Mana and press start - the green BG behind the name entry goes chunk-chunk-chunk. It looks like it's missing the lowest 2 or 3 bits of the scroll position.
Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 12:33 AM
I thought SMW choppiness was due to my underpowered Eeepc (+ a bunch of OAM masking problems), but Secret of Mana clearly shows that there is some bug still crawling in the new code...

I'm going to track it down once I'm done with the inputs, if no one else beats me to it
Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 01:21 AM
fixed. it was actually pretty easy: your description of the problem reminded me that I hadn't re-implemented properly the horizontal scrolling due to lowest 3 bits of the hoffs reg blush

I had to remove it because to properly support it (without neither leaving a black strip on one side, nor writing beyond the last pixel) more boundary checks were needed in the tile drawing code and at first I was not sure where they would have fit... of course, I completely forgot about it afterwords frown

However, after all the small cleanups performed between 7493 and 7525, it was now fairly easy to fix the problem. Notice that this also fixed scrolling stars in the SNES Test Program!

In other words, I think there are no more known regressions compared to the old video code.

I will commit the fix as soon as I verify that it does not breaks anything else (e.g. OPT) smile
Posted By: Justin Re: The SNES WIP topic - 03/07/10 06:48 AM
Originally Posted By etabeta78
In other words, I think there are no more known regressions compared to the old video code.


Well, almost smile

The bit in the Chrono Trigger intro where Lavos comes up out of the earth seems to have a priority issue (left is 0.135, right is SVN):

Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 09:41 AM
Thanks for reporting it: it seems indeed an OAM priority problem. I'm going to investigate this, when I arrive to clean up OAM drawing (soon-ish, hopefully).
It might well be the same problem which affects TMNT Tournament Fighters...

Let's say that we are left with only a few priority problems compared to the old code (which was missing more important effects, like OPT and correct hires drawing, though) wink

on a different subject, I just finished to implement mouse support. Mario Paint has never worked in MESS, so I cannot use it to test the code, but Tetris & Dr. Mario correctly complains about it



and I was able to play Arkanoid with SNES mouse inputs, hence I think it should be mostly correct.
Posted By: Xor Re: The SNES WIP topic - 03/07/10 11:56 AM
Ok, downloaded the lastest bobz build (dated march 7) and tried a couple of games and encountered a similar problem with some of them (all ran explicitly from the commandline):

R-Type III third lightning (shows title and then turns black)

Tiny Toon Adventures - Wacky Sports Challenge (starts first demonstration then turns black)

Super Castlevania IV (shows part pf the intro sequence and then turns black)

also tried Super Bomberman Panic Bomber W which only shows black screen (it also fails in 0.136 where it says the following "warning: write to sound test register with data 00!")
Posted By: R. Belmont Re: The SNES WIP topic - 03/07/10 01:14 PM
DKC 1 and 2 turn all-green in game. SCV4 and Dracula X start out OK but almost immediately all sprites disappear, which makes it hard to play smile
Posted By: Xor Re: The SNES WIP topic - 03/07/10 01:55 PM
offtopic: R.Belmont, you mentioned that the saturn sh1 will be 'decapped', will that help with the saturn cd emulation? (I've only gotten two games to load sofar: Cotton and Guardian Force)

ontopic:

Monster Maker Kids - Ousama ni Naritai (sprites don't show in title/demonstration and probably in game either)
Posted By: R. Belmont Re: The SNES WIP topic - 03/07/10 02:31 PM
Yes.
Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 03:11 PM
I cannot reproduce most of these: in reverse order...

Originally Posted By Xor
Monster Maker Kids - Ousama ni Naritai (sprites don't show in title/demonstration and probably in game either)


I can see them in latest svn




Originally Posted By R. Belmont
DKC 1 and 2 turn all-green in game.


where?



Originally Posted By R. Belmont
SCV4 and Dracula X start out OK but almost immediately all sprites disappear, which makes it hard to play smile


at which point? (given my system crawls while emulating SNES, the first couple of levels are the best I can test, without better references)



might there be endianness problems? might it be 64bit specific?

Originally Posted By Xor
R-Type III third lightning (shows title and then turns black)


waiting a few seconds after the title screen, I see a black screen, but then the demo goes on:



Originally Posted By Xor
Tiny Toon Adventures - Wacky Sports Challenge (starts first demonstration then turns black)


same as above: it runs through the demo sequence, then screens become black but in a few seconds the konami logo is there

Originally Posted By Xor
Super Castlevania IV (shows part pf the intro sequence and then turns black)


I was able to pass through the whole intro (the one with the story), then the gameplay demo started without issues and finally it came back to the Konami logo and the title screen.

Originally Posted By Xor
also tried Super Bomberman Panic Bomber W which only shows black screen (it also fails in 0.136 where it says the following "warning: write to sound test register with data 00!")


This has never worked, unfortunately... it needs better timing of the CPU, iirc

------------------

Back on inputs, I added preliminary SuperScope support.



I suck at lightgun games (and inputs are quite unresponsive on my eeepc, making a nightmare to understand if the Turbo switch is on or off), so don't expect me to test all the games supporting it wink
If there are issues, I hope users could provide a test case (together with steps to reproduce it and expected behavior)
Posted By: R. Belmont Re: The SNES WIP topic - 03/07/10 03:18 PM
The easiest repro of these issues is to simply let DKC2 run out the title screen and drop into attract - it goes all black there and stays that way.
Posted By: Xor Re: The SNES WIP topic - 03/07/10 03:30 PM
Weird, I'm using the latest bobz build (march 7) and the games behave as I stated above. (winxp 32bit)

Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 04:38 PM
here dkc2 went successfully through three levels in the demo and back to the title without stopping to a black screen... however, later I will try with a fully clean compile (I usually only delete snes.o/nintendo.a files), and recheck... might be some problem which does not manifest in my build due to a mix of old and new .o files.

on the bad news side, superscope support is not working in fact. It worked once (with Super Scope 6), then not anymore (that's why I'm going to recompile in any case wink )
Posted By: Xor Re: The SNES WIP topic - 03/07/10 07:39 PM
hmmm I think I should better start pulling and building directly off the svn instead since otherwise I might be reporting stuff that's been fixed. does the svn build with the new mame buildtools?
Posted By: judge Re: The SNES WIP topic - 03/07/10 07:54 PM
yes, it builds with the new mame buildtools
Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 08:46 PM
some good news: I fixed the SuperScope support and I was finally able to reproduce the mentioned issues (screen turns to black suddenly in some games)

the bad news is that I'm still looking for a fix... more news when I find the culprit.
Posted By: etabeta78 Re: The SNES WIP topic - 03/07/10 09:39 PM
@Arbee: I'd need some help from you. could you try to compile a build with SYMBOLS=1 ans see if the issue is still present? I compiled a clean build with SYMBOLS=1 and one clean build with SYMBOLS=0. the first has no issues, the second is bugged.

This at least would explain why I was never able to reproduce the problems mentioned earlier: I was always using a SYMBOLS=1 build in my tests...

any idea of which kind of code might cause such a problem with the compiler?
Posted By: Xor Re: The SNES WIP topic - 03/07/10 11:06 PM
Likely it's something that screws up with optimization since when compiling with symbols the makefile uses -O0 (no optimizations) while compiling without symbols defaults to -O3. I'll do some tests.
Posted By: R. Belmont Re: The SNES WIP topic - 03/07/10 11:11 PM
You can override that behavior, of course. I ususally use 'make SYMBOLS=1 OPTIMIZE=3' for symbols, but then I'm often debugging fairly 'heavy' targets.
Posted By: Xor Re: The SNES WIP topic - 03/07/10 11:18 PM
Yeah I can pretty much verify that it's some code that gcc screws up with in optimization since I just compiled latest svn rev with -O0 and no symbols and no more black screens in the aforementioned games.

edit: it get's black screens already with -O1 so it must really have problem with some code.
Posted By: R. Belmont Re: The SNES WIP topic - 03/07/10 11:56 PM
Which file is it? video/snes.c or machine/snes.c?
Posted By: etabeta78 Re: The SNES WIP topic - 03/08/10 05:55 AM
the problem should be in video/snes.c. and I'm fairly sure that it's some new code that screws up the compiler and probably it's just a silly mistake I've done in rewriting the routines... I'm just not sure about how to properly debug it (so far I haven't managed to trace back the issue frown )
Posted By: jbo_85 Re: The SNES WIP topic - 03/08/10 11:08 AM
It's a buffer overflow in snes_draw_tile_object(). ii can sometimes be >= 256 and that isn't tested.
Posted By: judge Re: The SNES WIP topic - 03/08/10 05:28 PM

superscope introduced some errors here:

Code:
src/mess/drivers/snes.c: In function ‘UINT32 snes_superscope_offscreen_input(const input_field_config*, void*)’:
src/mess/drivers/snes.c:127: warning: comparison is always false due to limited range of data type
src/mess/drivers/snes.c:127: warning: comparison is always false due to limited range of data type
Posted By: etabeta78 Re: The SNES WIP topic - 03/08/10 07:35 PM
I'm going to take a look after dinner
Posted By: etabeta78 Re: The SNES WIP topic - 03/08/10 10:19 PM
fix submitted.

@jbo_85: earlier today I started to work on the OAM and I had the boundary checks locally implemented. but I had given up with optimized build, so I was unaware that it was the required fix.

I hope this fixes all the problems previously experienced. once again, thanks a lot for the tip!!

@judge: is Superscope support compiling now? I'd like to leave the proper checks there even if we currently only scan positive coordinates...
Posted By: Xor Re: The SNES WIP topic - 03/09/10 03:27 AM
Yes I compiled the latest svn with -O3 and the errors with black screens that you couldn't replicate works now.

Here's a few new tests:

R-Type 3 Third Lightning

watching the attract mode the first level shown looks fine but the second and later have corrupted sprites and tiles:


Mouryou Senki Madara 2

Seems to use the same hires mode for displaying text as Seiken Densetsu 3 does, there's a small glitch at the bottom of some of the kanji letters.



Keep up the great work!
Posted By: byuu Re: The SNES WIP topic - 03/09/10 01:14 PM
Thanks for the constant updates, a lot of fun to read. I should hopefully be more helpful once you get toward the final CPU timing bugs.

Quote:
EDIT: btw, this is another proof that few people actually use MESS for SNES: nobody noticed those games were broken since last summer... well, hopefully things will get better in future


Good luck with that one. I suspect that even once Microsoft kills 32-bit backwards-compatibility in Windows ~12, people will just start running ZSNES inside of DOSBox.

No release in three years, not portable, 100+ open bugs, some over ten years old, a UI that makes the Atari ST blush, sound effects are always distorted, and the latest build doesn't even play SA-1 games or have netplay. Yet it has 70% of the user base.

I stopped worrying about it a few years ago, I'd suggest you do the same or it will kill you inside. If that's what people want, more power to them.

Nothing to do with system requirements, either. SNESGT is blindingly fast yet better in every way. I assume it's all about familiarity.
Posted By: Haze Re: The SNES WIP topic - 03/09/10 01:32 PM
Originally Posted By byuu
Thanks for the constant updates, a lot of fun to read. I should hopefully be more helpful once you get toward the final CPU timing bugs.

Quote:
EDIT: btw, this is another proof that few people actually use MESS for SNES: nobody noticed those games were broken since last summer... well, hopefully things will get better in future


Good luck with that one. I suspect that even once Microsoft kills 32-bit backwards-compatibility in Windows ~12, people will just start running ZSNES inside of DOSBox.

No release in three years, not portable, 100+ open bugs, some over ten years old, a UI that makes the Atari ST blush, sound effects are always distorted, and the latest build doesn't even play SA-1 games or have netplay. Yet it has 70% of the user base.

I stopped worrying about it a few years ago, I'd suggest you do the same or it will kill you inside. If that's what people want, more power to them.

Nothing to do with system requirements, either. SNESGT is blindingly fast yet better in every way. I assume it's all about familiarity.


It's because people remember Zsnes from the 'good old days' when they first found a Snes emulator that ran the games they liked.. so they recommend it to their friends without looking for anything new, etc. etc.

Some people still use NeoRageX for the same reasons today even if MAME is a much closer experience to the real thing, and likewise a lot of perfectly good alternate emulators get ignored just because they're not MAME.

The problem is MESS has the reverse reputation, it's been such a god-damn awful emulator for most of the things (which people care about) it emulates for so long that hardly anybody is likely to remember it in a positive light, and therefore hardly anybody is going to recommend it, even if things have improved a bit now. (although performance and compatibility can still be dire, as it is for 32x)

I don't consider this the fault of the MESS developers, as I've found myself, the Console 'scene' tends to be very secretive, with more people concerned about making their software the best, and as a result not being helpful to others. It's always been less about team work, less about being open, and more about competition, and wasted efforts in rediscovering things people have already found out before. Again, I think this has improved a lot over the last few years, but there are still a number of examples of it.

The only way you're going to get a more significant userbase for the SNES driver is if MAME/MESS do merge completely, and I can't see that happening as long as Aaron is calling things at least, and even then interest in MAME and emulation in general is dipping, with many people quite content with the version they have, and seeing no reason to upgrade even when real improvements are made. Low / No user base does make testing things hard, the odd bug or useful new test case I do get for the Genesis stuff are things I would have never found myself without other people actually playing the games properly and I'm sure if more people used it I'd get more test cases.

The fixed lists for some of the slightly more obscure systems might make MESS more attractive to some (I'd end up very tempted to give some vectrex games a play), and you might find people start using the SNES driver that way, but a lot of people will probably be put off by the poor performance and hit & miss compatibility anyway, although having it documented will help as people will have a better expectation of what should work.

Also, as far as MESS is concerned, the graphic filters and 'tweaks' other emulators offer which aren't really suitable for MESS will always be a big draw, even if MESS does become a decent reference model like MAME.

Basically, yeah, there isn't much you can do about it.. people might come, but finding a way to get them to stick will be hard.
Posted By: etabeta78 Re: The SNES WIP topic - 03/09/10 01:39 PM
Originally Posted By byuu
Thanks for the constant updates, a lot of fun to read. I should hopefully be more helpful once you get toward the final CPU timing bugs.


that could take some time (currently in progress improved OAM drawing routines, to finally fix the "sprite limit" and the priorities; next target probably HDMA), but thanks a lot for both the direct and indirect help you gave: your source is a wonderful reference for what is currently known about the hardware; your notes on the OAM are being precious, explaining the few points that were unclear to me after reading bsnes implementation; and I borrowed the logic you used for SuperScope Turbo Mode which saved me some time in figuring out a fast way to toggle the right keys when necessary [1]

Originally Posted By byuu
I stopped worrying about it a few years ago, I'd suggest you do the same or it will kill you inside. If that's what people want, more power to them.


sad but true. but I'm especially worried about having to test 4000+ games by myself, whenever I try to make things closer to the hardware... well, at least we might hope that some MAME users decide they like MESS due to the common UI and options: this might give us a few more regular testers.


[1] btw, let me know if you want to be credited for those lines (line 463-491 of http://git.redump.net/cgit.cgi/mess/tree/src/mess/drivers/snes.c )
Posted By: etabeta78 Re: The SNES WIP topic - 03/09/10 01:57 PM
Originally Posted By Haze
and you might find people start using the SNES driver that way, but a lot of people will probably be put off by the poor performance and hit & miss compatibility anyway


latest code gained around 10-15% of speed compared to 0.135, on my EEEPC. it helps to only draw half of the pixels we used to draw.

there is still some space for optimization, but "hit & miss compatibility" due to the lack of proper CPU timing will have priority...
Posted By: R. Belmont Re: The SNES WIP topic - 03/09/10 02:18 PM
"Good enough and familiar" is better than "new and better". Ask Internet Explorer.

byuu got caught in the trap of believing what people *said* they wanted from bsnes (filters, add-on chip support) and ended up with a bunch more code to maintain and no particular increase in users.

Similarly, while I think things like having the software lists will make MESS easier to use up front, I don't think it'll have any significant impact on usage. Even if it were merged with MAME the net effect would be that more people would have the code but wouldn't actually use it. MAMEPlus has included MESS drivers forever (and a ton of filters!) and makes them as easy as any other console emulator through it's GUI and nobody uses the MESS drivers there either.

Ultimately you have to be working on emulation because you really enjoy it for itself. If you're in it as a user popularity contest you *will* burn out and quit. That's the real lesson of the parade of would-be MAME killers. FBA survives because Barry's making the emulator he wants to play, and that's what matters.
Posted By: Haze Re: The SNES WIP topic - 03/09/10 02:32 PM
Originally Posted By R. Belmont

Similarly, while I think things like having the software lists will make MESS easier to use up front, I don't think it'll have any significant impact on usage. Even if it were merged with MAME the net effect would be that more people would have the code but wouldn't actually use it. MAMEPlus has included MESS drivers forever (and a ton of filters!) and makes them as easy as any other console emulator through it's GUI and nobody uses the MESS drivers there either.


Most of the Megadrive reports I've had are from Mame32plus users, not MESS or plain HazeMD, although half of them have turned out to be because of dodgy compile options people often use with said build, or were due to bad roms because of it using the MESS driver rather than the hazemd fixed lists.

I think a lot of people just give up because they can't work out where to put the roms tho due to MESS expecting everything in very specific software folders, rather than just the correct zipname in 'roms'. I very much hope that once the software lists are in then MESS will happily look in the root roms folder for bios + software roms if it doesn't find them in the system folders.

Saying nobody uses them is pushing it a bit tho. I suspect more people use them there than in MESS which again might not be helping the reputation because they tend to be less stable than in the official MESS releases.


Posted By: R. Belmont Re: The SNES WIP topic - 03/09/10 02:45 PM
For Megadrive, the fixed lists will actually make it harder though. Right now you simply point it to the specific ROM file you want to play, whereas with the lists you have to have them in the specific folder. Existing MAME users will understand that concept, but a lot of noobs actually give up on MAME because they don't.
Posted By: TheTrout Re: The SNES WIP topic - 03/09/10 02:58 PM
Well, I for one actually love using MESS for systems like the SNES. Granted, I'm sad when a game I like has video errors (The Adventures of Batman & Robin, Tetris Attack, etc), but I can deal. I'm a big fan of the simplicity of MESS (and MAME, for that matter) - crisp and unfiltered graphics at any resolution, great in-game menu, easy to configure controls on-the-fly...

I only switch to bSNES when I hit a roadblock with a game (or I need to use the multitap). Otherwise, it's MESS all the way. I've been spreading the word to my friends as well, though I can't say if it's helping!
Posted By: Haze Re: The SNES WIP topic - 03/09/10 03:07 PM
Originally Posted By R. Belmont
For Megadrive, the fixed lists will actually make it harder though. Right now you simply point it to the specific ROM file you want to play, whereas with the lists you have to have them in the specific folder. Existing MAME users will understand that concept, but a lot of noobs actually give up on MAME because they don't.


I think there are enough 'existing MAME users' for the concept to be well understood, and for people to get help when they don't understand it. Besides, the old mechanism will still exist, but anybody wanting to report bugs will be expected to use the fixed lists and proper setnames I'm guessing. (or at least that would be my requirement for taking any bug reports given the number of times the problem has come down to 'bad rom' when people have reported things to me in the past)

Posted By: ht1848 Re: The SNES WIP topic - 03/09/10 03:10 PM
Quote:
EDIT: btw, this is another proof that few people actually use MESS for SNES: nobody noticed those games were broken since last summer... well, hopefully things will get better in future


Oh I totally called that Star Wars bug back in this thread...don't make me go look for it. Yes there are users. I will go find some more bugs now as it looks like Etabeta (you rock!) cleared my bugzilla entries. Was having compile problems last night (something megadrive related) so I couldn't test. I'll try again tonight and post my error somewhere if I can't figure it out (maybe user related).

As a long time MESS user, there are things that would increase the user base. I am game to give feedback but we need a new thread for that.
Posted By: etabeta78 Re: The SNES WIP topic - 03/09/10 04:00 PM
Originally Posted By ht1848
Oh I totally called that Star Wars bug back in this thread...don't make me go look for it.


you are right... shame on me

http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=54239#Post54239

I must have forgotten about it. But at least we have it fixed now, and I hope the garbage graphics has gone as well with the latest svn

Originally Posted By ht1848
Yes there are users. I will go find some more bugs now as it looks like Etabeta (you rock!) cleared my bugzilla entries. Was having compile problems last night (something megadrive related) so I couldn't test. I'll try again tonight and post my error somewhere if I can't figure it out (maybe user related).


current svn should compile fine (see http://mess.redump.net/mess:compile_failure )

bug reports are of course always welcome, especially if you can compare the current behavior with MESS 0.135 (0.136 had known problem, so it's not a good comparison), just to separate newly introduced issues from old problems

EDIT: also, please use a revision beyond 7543 to test... there were regressions with 7540 (sprite table creation is still not ready to be moved in the proper place, and I would prefer to avoid big regression until 0.137 is out wink )
Posted By: byuu Re: The SNES WIP topic - 03/09/10 05:21 PM
Quote:
The problem is MESS has the reverse reputation, it's been such a god-damn awful emulator for most of the things (which people care about) it emulates for so long that hardly anybody is likely to remember it in a positive light


There certainly is a jack-of-all-trades vibe when really, really incomplete modules are left enabled in the default build.

Yet stuff like the CD-i and Super A'can support is amazing, and really makes MESS stand out, even though that's incomplete.

As long as etabeta and co stay on top of SNES bug reports when they come in, I suppose it's great. But a dead, unattended module is probably only undermining confidence when there are better alternatives out there.

Quote:
the Console 'scene' tends to be very secretive, with more people concerned about making their software the best, and as a result not being helpful to others


Yes, the Saturn scene has been substantially held back by this. Thankfully Yabause is starting to make some serious headway.

The Genesis scene is the saddest. Kega Fusion, Regen and now Retrocopy. As if anyone even cares anymore, yet all the big-name Genesis emulators are as closed as could be.

The dead Gens' license isn't even legal, as it still uses the 15-year-old Starscream core that is non-commercial along with the GPL.

I remain extremely grateful for your work on HazeMD. Steve is a great guy, but if I play any Genesis games, HazeMD will be my first choice.

Quote:
btw, let me know if you want to be credited for those lines


Nah, no worries.

Quote:
"Good enough and familiar" is better than "new and better". Ask Internet Explorer.


I was going to make that comparison, but at least IE6 is fading below 20% now. Maybe if ZSNESv2 (aka IE7) were to come out, I'd feel less bad about it.

Quote:
byuu got caught in the trap of believing what people *said* they wanted from bsnes (filters, add-on chip support) and ended up with a bunch more code to maintain and no particular increase in users.


I don't know if I believed it or not, but I was happy to oblige the people looking for game bugs. You are correct of course, I've gained probably 10-20 people in return for a dozen filters, widescreen distortion modes, 7-zip multi-archive support, etc combined.

I've been moving away from that model, the new versions split all the filters, all the compression formats, all the excess into separate external DLLs.

I was even able to get rid of the bullshit "header heuristics" crap in favor of a pure XML-based mapping system (ala Nestopia) in the latest beta. The snesreader library generates the pitiful made-up mappings we're used to if you don't have a real XML mapping file to describe the board layout.

On my own PC, I don't use those plugin DLLs at all.

Now when it comes to special chips, they have absolutely nothing to do with the base hardware. You can put an 8-core Nehalem-EX inside an SNES cart if you want. You can hook up an MRI machine to it if you wanted. But end users just can't grasp that concept. We really have no choice but to support those; and MESS would seem to agree smirk

Quote:
Ultimately you have to be working on emulation because you really enjoy it for itself. If you're in it as a user popularity contest you *will* burn out and quit.


Yes, thank you very much. Behind my rant, this was the message I wanted to convey.

It's part of what makes me sick about closed source emulators. All that wasted testing, all that wasted research, all for something people will get tired of because they're in it for all the wrong reasons.

-----

As for myself, I don't wish to bemoan the success of others, and I really don't care about popularity. My goal is just to get as many people as I can onto a better emulator, regardless of which one that is.

The 13-year-old VRAM write bug has been the Achilles' Heel of the SNES translation scene. The 40-file-extension support has made a mockery of file load windows. The IPS-only support and refusal to obsolete copier headers has given patching a flip-of-the-coin chance of working and complicated loading. The reliance on magical voodoo heuristics to parse single binary blobs has made ROM loading a nightmare for every developer to date. And the bugs ... I spent seven years translating a game that 70% of people still can't even play.

The entire SNES scene is stuck in 1997, and we don't have the problem the NES scene does with 200 million emulators to choose from. All we need is one emulator to take charge and we can improve so much.

I really do hope you guys get some real market share. I'd love to be able to work with an active team who cares about sanity, and is willing to inconvenience people in the short term to make everything easier for everyone in the long term.
Posted By: byuu Re: The SNES WIP topic - 03/09/10 05:32 PM
Ranting aside, what do you guys think of the XML format for mapping SNES games?

Spec here:
http://board.byuu.org/viewtopic.php?f=16&t=542

Theory is that a real SNES does not look at the internal header bits to determine how to map it. And while with enough magic we are able to get all known games playable, the maps are most definitely not correct. Memory is mapped where nothing should be and vice versa.

The XML mapping is meant to describe the physical board layout in correlation to the popular SFC images. And although it doesn't directly give us perfect mapping, it allows for the possibility.

We just need to combine PCB identification:
http://users.tpg.com.au/advlink/spx/list.html

With the layouts mapped out by Overload. And lastly either keep an internal database associating games with their PCB IDs, or get tools like GoodSNES to include the proper XML maps.

And voila, no more header magic.

The point of XML over a strict internal database SHA256=PCB list is to allow ROM hacks and translations a means with which to run. Given the dozens upon dozens of triple-A translations for this system, it's very important to allow for this.
Posted By: R. Belmont Re: The SNES WIP topic - 03/09/10 06:26 PM
I agree with everything you just said, byuu smile I didn't realize Regen was also closed source though. At least there's a concerted effort to document Genesis h/w behavior in the open over at SpritesMind. Should get interesting once they're done with the YM2612 and move on to the VDP.

And yes, the real hardware doesn't care about the header. The hardware on the cart does the mapping, period.

I would suggest that if ZSNES bugs are hampering translations, then maybe translations groups should advertise prominently that their stuff only works on hardware or in bsnes or (hopefully) MESS.

I like your XML mapping stuff, it could very easily be included in MESS's XML software list.
Posted By: Haze Re: The SNES WIP topic - 03/09/10 06:46 PM
yeah 'header magic' is bad, it can give an indication, but the reality is you need a better way of specifying it to be sure.

with the MESS software lists, I guess it can be specified in the game list XML, and that will translate to some setting in the code (as would be the case with any other header)

Of course if you want to keep the open-ended approach too then supporting an open format which includes such details will be needed as well, but as you've already seen, getting any kind of traction with new ideas is difficult.

This is why I prefer the MESS 'fixed list' (be it internal or external) approach. It's just essentially a database of what each game needs, it means you don't have to mess around with the roms, or rom formats. The database tells the emulator what to do, the roms are in their native format.

Yes, some people might not like having set names, but creating even more rom formats is probably just going to result in only a handful of people caring, and plenty of people confused as to why a new format is needed, and simply ignoring it.
Posted By: Just Desserts Re: The SNES WIP topic - 03/09/10 06:49 PM
Originally Posted By byuu
Now when it comes to special chips, they have absolutely nothing to do with the base hardware. You can put an 8-core Nehalem-EX inside an SNES cart if you want. You can hook up an MRI machine to it if you wanted.


I've heard this viewpoint espoused before with that FMV-playback thing, and I've also heard that it's really not true. This was mentioned to me by someone who has done actual SNES development back when games were still under active development for it - you certainly may put an 8-core Nehalem-EX inside a SNES cart if you want to, but good luck feeding it data fast enough or getting data off the cart fast enough. There's a pretty low ceiling on exactly how fast the DMA engine can shove data across the bus, and while you can bolt pretty much anything onto an emulated machine, I'll be very interested in seeing the issues that crop up if you ever actually try to implement an accelerator in hardware. smirk
Posted By: Stiletto Re: The SNES WIP topic - 03/09/10 06:54 PM
Well, byuu's got his "MPEG" module in software, so that's a start. smile Hopefully a hardware implementation comes along...
Posted By: R. Belmont Re: The SNES WIP topic - 03/09/10 06:55 PM
Right, but bsnes also implements the correct DMA bandwidth limits and yet they have working FMV, so smile

The point does stand that the base hardware limits the usability of what you can chuck into a cart though.
Posted By: Just Desserts Re: The SNES WIP topic - 03/09/10 07:58 PM
Originally Posted By R. Belmont
Right, but bsnes also implements the correct DMA bandwidth limits and yet they have working FMV, so smile


I don't know, I guess I'll believe it when I see it working on an actual SNES using an actual proper mass storage device. wink

Originally Posted By R. Belmont
The point does stand that the base hardware limits the usability of what you can chuck into a cart though.


Right, that was more what I was trying to get across.
Posted By: byuu Re: The SNES WIP topic - 03/09/10 09:57 PM
Quote:
I didn't realize Regen was also closed source though.


He also had GPL code in the first few versions, but still didn't release his code. The worst possible case, benefiting from people who share whilst not returning the favor frown

Quote:
I would suggest that if ZSNES bugs are hampering translations, then maybe translations groups should advertise prominently that their stuff only works on hardware or in bsnes or (hopefully) MESS.


Oh, it's much worse than that. The latest was a team who released a patch that only ran on ZSNES. When they found out it didn't work on hardware or other emulators, they espoused, "well, it doesn't really matter, just use ZSNES instead."

I was as polite as possible and offered to help debug and fix the issue for them, but they were very notably perturbed that people were upset with the patch.

It bothers me because one day we'll either have to:
a) create a ZSNES emulator, or
b) completely lose these gem translations for good

And now from the other side of the spectrum: when I released my DL translation, I had two people accuse me of hacking it to ONLY run on bsnes. Nevermind the fact that the original, unmodified Japanese game also locked up and crashed on ZSNES ...

Quote:
Yes, some people might not like having set names, but creating even more rom formats is probably just going to result in only a handful of people caring, and plenty of people confused as to why a new format is needed, and simply ignoring it.


My plan was to match the loaded SHA256 sum to the database, preferably with an O(log n) search. I can understand how calculating an SHA256 sum would be a problem for MESS on CD/DVD-based systems. But for ROMs, it's more fool-proof. Can't trick the system by renaming a file wrong, and rainbow attacks on SHA256 are pretty hard at the moment.

Quote:
I don't know, I guess I'll believe it when I see it working on an actual SNES using an actual proper mass storage device.


Okay, sure smile
http://byuusan.kuro-hitsuji.net/lunar.sfc

This is the Lunar: Silver Star Story MPEG opening, encoded at 240x160x8bpp @ 30fps along with 32KHz stereo sound output, running on the S-DD1 hardware.

The only way in which it cheats is by accessing 64MB through the S-DD1 MMC, whereas the ROM on a real cartridge was 6MB in size. However, someone took that file and cut it to 6MB and was able to run the first several seconds off his cart. I can try and find out who, but it was mentioned on the nesdev thread by smkdan about his video ROMs.

I am happy to go into the explanation, but I am beyond 100% confident that the above is fully and completely possible. It's actually really, really very easy to do.

Quote:
you certainly may put an 8-core Nehalem-EX inside a SNES cart if you want to, but good luck feeding it data fast enough or getting data off the cart fast enough


Of course. My point was that the cartridge could have anything inside of it, not that the SNES could fully utilize what was there smile

You could for instance turn it into a really souped up DSP-1 if you wanted. Or have Deep Blue's chess algorithm going.

By saying you could put anything, of course it's a bit asinine since all commercial games ever made have been released. We have a fixed set of chips to support. I was more trying to represent that the chips inside the cartridge are not part of the SNES itself. Having DSP-1 support doesn't mean it's part of the SNES emulator, it's a DSP-1 chip emulator, or essentially a specific cartridge simulator at that point.
Posted By: R. Belmont Re: The SNES WIP topic - 03/09/10 10:12 PM
Quote:
Oh, it's much worse than that. The latest was a team who released a patch that only ran on ZSNES. When they found out it didn't work on hardware or other emulators, they espoused, "well, it doesn't really matter, just use ZSNES instead."

I was as polite as possible and offered to help debug and fix the issue for them, but they were very notably perturbed that people were upset with the patch.


I had no idea things were that bad. Nobody should ever release a "finished" translation that doesn't run on hardware. You're starting with a game that runs on hardware, it's not that difficult to make sure it stays that way.
Posted By: byuu Re: The SNES WIP topic - 03/09/10 11:22 PM
The thing is that most of these people don't have copiers or flash cartridges to test on hardware. So they use the most popular emulator to test as they go along. Naturally that emulator lets you do a million and one things real hardware won't allow, and they don't even notice.

The biggest one is that VRAM writes are not allowed during active display. To fix this, you add this code inside vram_write():
if(vcounter() < (overscan() ? 240 : 225) && !display_disabled()) return;

Won't break any known games, will actually *fix* Hook (U) garbage in the intro, an active bug since the very first release.

I was told some games were too timing sensitive, which I don't believe, but okay fine. Adjust the range. instead of 240/225, do 245/230. It's not perfect, but it'll give a lot of extra coverage for bad timing.

But nope, still not fixed. Just off the top of my head, it's broken the following fan translations:

Dragon Quest 1&2 Reprise - title screen graphic broken <broken forever, patch author is dead>
Dual Orb 2 - Yes/No menu broken [updated patch fixes it]
Mystic Ark - text is invisible [updated patch fixes it]
Sailor Moon - Another Story - intro text is corrupted <broken forever, patch author vanished>
Ys IV - no text is visible in dialog boxes [updated patch fixes it]

I've also hit this bug myself when I first found out about it in 2000 or so. I'm sure there are many more examples.

I've gotten at least three false bug reports on Sailor Moon, one on Mystic Ark, and two or three on ROM hacks. People see it working in ZSNES and assume the bug is on my side.
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/10/10 12:04 AM
Another patch which works in zsnes or other emus which ignore vram restrictions is fusoya's Secret of Mana VWF font patch. (or at least i've been told it doesn't work on real hardware, I've never tried it) http://fusoya.eludevisibility.org/som/index.html
I keep hoping one day someone will fix that patch to work on real hardware (I wouldn't think waiting for vblank in the code before vram write would be very complicated, but it might royally screw up the rest of the code and do a million and one other horrible things)

LN
Posted By: byuu Re: The SNES WIP topic - 03/10/10 03:20 AM
Fuck. It appears every SNES emulator gets ADC and SBC wrong in decimal mode. I've created hardware logs of every possible accumulator and status register result for every possible adc+sbc combination, and posted the details + logs here:
http://board.byuu.org/viewtopic.php?f=16&t=562

Anyone here feel like taking a crack at this? smile
Posted By: R. Belmont Re: The SNES WIP topic - 03/10/10 03:31 AM
Interesting. Can you flag specific combinations that are wrong? I have a working Apple IIgs with a real WDC 65c816, it'd be interesting to see if this is an S-CPU specific thing.
Posted By: judge Re: The SNES WIP topic - 03/10/10 07:22 AM
Hm, perhaps a similar thing as with the NES cpu? That one also has some small differences when compared to a stock 6502.

On homebrew/translation patches: I tend to ignore bug reports on those until they've actually been tested and confirmed working on real hardware.
Posted By: objectorbit Re: The SNES WIP topic - 03/10/10 03:52 PM
Originally Posted By byuu
The Genesis scene is the saddest. Kega Fusion, Regen and now Retrocopy. As if anyone even cares anymore, yet all the big-name Genesis emulators are as closed as could be.



I can't speak for Retrocopy, but Kega Fusion and Regen's authors are known for sharing info if you just ask. I'd say that's an acceptable compromise to the issue.
Posted By: byuu Re: The SNES WIP topic - 03/10/10 05:08 PM
Quote:
Can you flag specific combinations that are wrong?


Sure, we'll start with one case and continue to fix them.

In this post:
http://board.byuu.org/viewtopic.php?f=16&t=562&p=12134#p12134

I have a standalone C99 (or C++98) app that will emulate only adc+sbc, and will iterate over my adc_sbc_test.zip archive files, telling you if you passed or failed.

First failure is in adc_0000-7fff-clc-sed-p. Failure is at 0x207a.

So given the code:
lda #$20; clc; sed; adc #$7a

My emulator gives: A=00, P=2F
Hardware gives: A=00, P=6F

The difference is that the overflow flag is set on hardware, but not under emulation.

It seems there's an entirely different algorithm for overflow calculation in decimal mode.

Quote:
I can't speak for Retrocopy, but Kega Fusion and Regen's authors are known for sharing info if you just ask. I'd say that's an acceptable compromise to the issue.


I have written extensively on this subject:
http://byuu.org/articles/licensing/

I'm very, very much in favor of giving an author full control of their own source code. I understand how insanely demotivating it is to compete with yourself (as would the MAME team with that one closed source fork), how it's not fair to put in a ton of work when nobody returns the favor but does take your ideas, and so on.

And I realize it's a philosophically hypocritical position for me to take, but I truly feel that emulation is different.

Writing the latest media player or video game, that's your creation. It's your design, and releasing the source to that I could care less about.

But writing an emulator is about recreating hardware. We have to realize that hardware does not last forever. Sega will never make another original Mega Drive. Maybe there will be some knockoff clones, maybe even official clones, but they will be hardware emulators just as the RetroDuo is.

Real hardware fails. Capacitors stop holding charges, transistors fry, circuitry fails. This hardware is already ~20 years old. It is becoming increasingly difficult to get hardware to run tests on.

I would posit that in 30 years from now, we won't be able to run hardware tests on the Genesis any longer. Anything we failed to emulate, any behavior we weren't sure about, once that last Genesis fails ... that's it. Game over. We'll never know how it really worked.

Thus, it is absolutely imperative, for the sake of properly documenting and archiving the hardware, that we get over our petty little egos and work together to our fullest extent to preserve the hardware while we still can.

I see it as absolutely tragic that childish popularity contests are holding back reverse engineering efforts in the emulation scene.

Sharing info when someone asks is great, but words are not source code, documentation is never equal to implementation, people are hesitant to pester someone for info all of the time, authors will become annoyed if pestered too much for info, etc. It is a negative environment.

Put another way, do you think Gens or Regen would be a better emulator if Kega were open source? If these authors are willing to share any info, then why not share the source, too?
Posted By: R. Belmont Re: The SNES WIP topic - 03/10/10 05:27 PM
More concisely, closed-source non-commercial emulators are a prime example of the free-rider problem, which tl;drs down to "they get to use the free guys' research for free, and we don't get to use theirs".

At this point, I think the advantages of open source for non-commercial emulation are obvious and nearly overwhelming. I bag on PCSX2 a lot for seemingly only caring about JRPGs, but it does do an impressive job emulating hardware of near-Saturn-level complexity with order of magnitude higher clocks. And Dolphin's been even more impressive, even if I think they're well into the gray area with Wii support. Outside of the Sega space[1], open source rules the roost.

[1] Which is super odd. Genesis, Sega CD, 32X, Saturn, Dreamcast, and Model 2 all have only closed-source reference emulators, although I think more MAMEdevs have ElSemi's Model 2 source than have up to date MAME trees.
Posted By: byuu Re: The SNES WIP topic - 03/10/10 05:58 PM
Yes, free-rider is a big issue as well.

Okay, some more on ADC flags.

00+{00-79} sets V=0, with results of {00-79}
00+{7A-7F} sets V=1, with results of {80-85}
00+{80-FF} sets V=0, with results of {80-FF}

01+{00-78} sets V=0
01+{79-7F} sets V=1, with results of {80-86}
01+{80-FF} sets V=0

Very weird. I'm thinking that 7A is being "rounded" up to 80, and 80+ results set V; but then why doesn't 00+80 set it?

The window for overflow grows by one for each increment of the left-hand value.

---

So I think:

overflow = (A >= (0x7a - B)) && (A <= 0x7f);

Which works until 0x0b6f.

0B+6F: A=70, P=2C, V=0
Posted By: Heretical_One Re: The SNES WIP topic - 03/10/10 06:49 PM
byuu, could you test:

Code:
if(((~(i^j))&0x8)&((i^k)&0x8))
     set_overflow();


where i= the high nibble of the Accumulator, j = high nibble of the data, and k being the high nibble of the result. That bit of code was given to me many years ago by someone as "correct for known cases" at the time.

ETA: it at least should work for the 0x80+0 case, as well as the 7X cases.
Posted By: byuu Re: The SNES WIP topic - 03/10/10 06:51 PM
Okay, this code will pass for all possible combinations of:
lda #$xx; clc; sed; adc #$yy

Code:
void op_adc_b(uint8_t r0, uint8_t r1, uint8_t &a, uint8_t &p) {
  int r;
  if(decimal) {
    uint8_t n0 = (r0     ) & 15;
    uint8_t n1 = (r0 >> 4) & 15;
    n0 += (r1 & 15) + carry;
    if(n0 > 9) {
      n0 = (n0 - 10) & 15;
      n1++;
    }
    n1 += ((r1 >> 4) & 15);
    if(n1 > 9) {
      n1 = (n1 - 10) & 15;
      carry = 1;
    } else {
      carry = 0;
    }
    r = (n1 << 4) | n0;

    uint8_t L = r1 & 0x0f;
    uint8_t H = r1 & 0xf0;
    if((r1 & 0x80) == 0) {
      overflow = (r0 >= (0x7a - r1)) && (r0 <= 0x7f);
      if(L >= 0x0b && H <= 0x60) {
        uint8_t M = 0x6f - (H & 0x7f);
        if(r0 >= (M - (L - 0xb)) && r0 <= M) overflow = false;
      }
    } else {
      overflow = (r0 >= 0x80) && (r0 <= (0xf9 - (r1 - 0x80)));
      if(L >= 0x0b && H <= 0xe0) {
        uint8_t M = 0xef - (H & 0x7f);
        if(r0 >= (M - (L - 0xb)) && r0 <= M) overflow = true;
      }
    }
  } else {
    r = r0 + r1 + carry;
    carry = r > 0xff;
    overflow = ~(r0 ^ r1) & (r0 ^ r) & 0x80;
  }
  negative = r & 0x80;
  zero = (uint8_t)r == 0;

  a = r;
  p = 0x24 | (negative << 7) | (overflow << 6) | (decimal << 3) | (zero << 1) | (carry << 0);
}


Don't ask me why or how ...

Core part:
Code:
    uint8_t L = r1 & 0x0f;
    uint8_t H = r1 & 0xf0;
    if((r1 & 0x80) == 0) {
      overflow = (r0 >= (0x7a - r1)) && (r0 <= 0x7f);
      if(L >= 0x0b && H <= 0x60) {
        uint8_t M = 0x6f - (H & 0x7f);
        if(r0 >= (M - (L - 0xb)) && r0 <= M) overflow = false;
      }
    } else {
      overflow = (r0 >= 0x80) && (r0 <= (0xf9 - (r1 - 0x80)));
      if(L >= 0x0b && H <= 0xe0) {
        uint8_t M = 0xef - (H & 0x7f);
        if(r0 >= (M - (L - 0xb)) && r0 <= M) overflow = true;
      }
    }


---

This code fails the test: if(((~(i^j))&0x8)&((i^k)&0x8))
Posted By: judge Re: The SNES WIP topic - 03/10/10 07:07 PM
Looks like a bug in the cpu where it first does the decimal adjust which triggers a flip in the high bit and somehow interprets that as an overflow.

Edit:
hmmm, looking at regular 6502 ADC implementation (http://git.redump.net/cgit.cgi/mess/tree/src/emu/cpu/m6502/ops02.h#n312) it seems to give the results you're seeing....or am i missing something??
Posted By: byuu Re: The SNES WIP topic - 03/10/10 07:21 PM
blargg cracked it.

http://board.byuu.org/viewtopic.php?f=16&t=562&p=12138#p12138

That passes all of the adc+sbc tests. It's calculating overflow prior to the last ADC/SBC decimal-mode adjustment.

Adapting to 16-bit mode should be easy enough.
Posted By: judge Re: The SNES WIP topic - 03/10/10 07:27 PM
Cool, so once again nintendo doing things slightly different from what you'd normally expect.
Posted By: R. Belmont Re: The SNES WIP topic - 03/10/10 07:28 PM
Awesome smile I'll test on the real non-SCPU 65816 after work today. Would be interesting to get a test on a real 6502 also, but I don't have any of those.
Posted By: R. Belmont Re: The SNES WIP topic - 03/11/10 04:00 AM
Quote:
lda #$20; clc; sed; adc #$7a

My emulator gives: A=00, P=2F
Hardware gives: A=00, P=6F


My real Apple IIgs gives A=00, P=7B in both 8-bit native mode and emulation mode, and "mess apple2gs" gives A=00, P=3B so overflow is definitely wrong. And it's not something Nintendo broke even.
Posted By: byuu Re: The SNES WIP topic - 03/11/10 04:10 AM
I've implemented blargg's 8-bit versions in both 8-bit and 16-bit, by extending his algorithm appropriately. Source code is here:

http://board.byuu.org/viewtopic.php?p=12151#p12151

Given lda #$0123; adc #$4567: regs.a.w = 0x0123, rd.w = 0x4567

It's definitely correct for all 8-bit x 8-bit combinations.

I'd certainly appreciate it if anyone could confirm the new BCD code is correct, as I can't exactly test 16-bit x 16-bit full combinations on a 3MHz SNES with 32KB SRAM smirk

I suppose we should add the new ADC/SBC versions to both the Apple II GS and SNES cores in MESS, too.

Isn't that amazing, though? 15 years of SNES research and we never got add or subtract right, heh ...
Posted By: R. Belmont Re: The SNES WIP topic - 03/11/10 04:29 AM
Actually MESS only has one 65816 core that both drivers use for the moment, so it's easier smile

Decimal mode is rarely used, and using it outside the "obvious" bounds even less so so I'm not surprised it went forever without getting hit.
Posted By: Heretical_One Re: The SNES WIP topic - 03/11/10 08:39 AM
Arbee is right. This is at least the fifth investigation into SNES BCD in the last 12 years.

And every time the result is "oops. Bugs!"

byuu, one way to counter the 32 KB limit is "don't store results from the SNES in SRAM, store the emulated results in the ROM". Of course, you'd need to CRC-16 or checksum the results to get a full scan in, and then you'd need to actually check the failed pages later, but it gives you almost 4 MB to play with instead of 32K. It takes you a step further from the hard numbers because you can only get down to "these 8K results add up correctly" or so. But it's a different approach than is usual.
Posted By: byuu Re: The SNES WIP topic - 03/11/10 03:08 PM
Creating the same 16-bit x 16-bit test set that I used for the 8-bit version would require 16GB of storage. Each of the 16 tests would take approximately three full days to complete. And that's just running the tests.

Getting it to a PC, my fastest method would be blargg's serial controller, so I would have to add a 16GB transfer over a dial-up modem connection to the 48 days already needed.

I'm sorry, but not even I am that dedicated to accuracy.

Quote:
This is at least the fifth investigation into SNES BCD in the last 12 years.


Well at least we know with 100% certainty now that the 8-bit versions are correct, once and for all.

-----

EDIT: and the latest results:
http://board.byuu.org/viewtopic.php?f=16&t=562&p=12168#p12168

I've confirmed with 100% certainty that my (blargg's) 8-bit implementations are perfect. I've also confirmed that my adaptations to extend blargg's 6502 implementation to 16-bit 65816 is correct for ADC BCD accumulator results. I am unable to test ADC BCD flag results, or SBC BCD accumulator or flag results. Again only in 16-bit mode.

But flags are substantially easier than math to extend from 8-bits to 16-bits. And the extension to ADC is the same as the extension to SBC.

Thus, I am 99.9% sure my implementations are bit-perfect, both in 8-bit and 16-bit mode. I would be very surprised if not.

So if you guys want to implement it to your core, the final versions are listed in this post:
http://board.byuu.org/viewtopic.php?p=12151#p12151
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/11/10 06:16 PM
Can you port the theoretical code for adc/sbc TO the snes (without actually using decimal mode on the snes) and then have the snes sequentially do actual adc/sbc ops, then do software emulation, and compare the two (and throw an error to screen if they don't match)? I know MooglyGuy had something similar for testing mess's n64 rsp core vs the real one on the n64 itself, though I don't know what happened to it...

LN
Posted By: byuu Re: The SNES WIP topic - 03/11/10 06:27 PM
It would take several days to execute the adds directly. To emulate the adds in 65816 would make it days weeks or months to complete.

Here is an 8-bit ADC/SBC BCD + flag test from blargg:

http://rapidshare.com/files/362042163/test_adc_sbc.zip.html

Passes in bsnes v061r02 with the updated algorithms.

Fails in bsnes v061, Snes9X v1.52, Super Slueth v1.04f, SNESGT v0.230b6, MESS v0.136, and ZSNES v1.51.
Posted By: etabeta78 Re: The SNES WIP topic - 03/11/10 06:32 PM
small wip



which means I (almost) fixed the sprite limit flags.

since the changes are quite large, I will probably wait until 0.137 is out before commit, to avoid any last minute apocalypse wink


EDIT: further tests show that the new OAM code fixes also the missing Mario sprite at the upper-left corner of world map in SMW. the reported priority problems in TMNT and Chrono Trigger are not fixed though and a few glitches have been introduced in at least R-Type 3... more work is needed on the sprites wink
Posted By: Haze Re: The SNES WIP topic - 03/11/10 07:17 PM
Originally Posted By Lord Nightmare
Can you port the theoretical code for adc/sbc TO the snes (without actually using decimal mode on the snes) and then have the snes sequentially do actual adc/sbc ops, then do software emulation, and compare the two (and throw an error to screen if they don't match)? I know MooglyGuy had something similar for testing mess's n64 rsp core vs the real one on the n64 itself, though I don't know what happened to it...

LN


This makes the most sense to me.. you could do a random stress test (just throw random sequences at it, reporting if any fail) or just allow the test range to be subdivided so that anybody with a copier can run a range of it overnight if they want.

I don't know what the SNES community is like these days, but there might be enough people out there willing to run their SNES for a week to get some idea of if the 16-bit implementation is accurate.
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/11/10 08:40 PM
I'd certainly be willing to.

LN
Posted By: byuu Re: The SNES WIP topic - 03/12/10 06:53 PM
blargg made an extensive 16-bit adc/sbc test, which his algorithm and my 16-bit adaptation passes. He is 100% sure the implementation is perfect. I'll try and get a link to that when I can, need to get it e-mailed to me at home.

So, ADC/SBC out of the way. I'm tired of talking about the MUL/DIV delays, let's get that one resolved for good already.

blargg appears to have cracked the MUL algorithm already. I haven't personally confirmed it on hardware, but I trust his results. We need help with the DIV algorithm next.

Please join and discuss here if you can help:
http://board.byuu.org/viewtopic.php?f=16&t=569

And again I'll emphasize here, please don't provide baseless speculation and educated guesses. Nintendo hardware is not based on any semblance of logic or reasoning.

Answers and actual hardware research only, please.
Posted By: Stiletto Re: The SNES WIP topic - 03/12/10 07:11 PM
blargg is crazy-insane, and I love it. blargg is awesome. There can be no doubt in this. wink
Posted By: R. Belmont Re: The SNES WIP topic - 03/12/10 07:17 PM
That is indeed awesome!
Posted By: byuu Re: The SNES WIP topic - 03/13/10 05:59 AM
With the help of blargg's step-based multiplication algorithm:
if((WRMPYA >> shift) & 1) RDMPY += WRMPYB << shift;

I have successfully reverse engineered the ALU multiplication process. Details are posted here:
http://board.byuu.org/viewtopic.php?p=12235#p12235

Now I'm just hoping blargg or someone else can come up with the step-based division algorithm, and we can finally emulate this behavior correctly!
Posted By: R. Belmont Re: The SNES WIP topic - 03/13/10 07:19 AM
That's fantastic!
Posted By: byuu Re: The SNES WIP topic - 03/13/10 10:56 PM
blargg figured out the DIV algorithm:
http://board.byuu.org/viewtopic.php?p=12251#p12251

It works exactly like the 8-step MUL, only this one is 15-step.

So yeah, congratulations everyone. We can finally trick d4s' code into thinking it is running on a real SNES smile

There is a caveat that the new mini-SNES acts a little different on how it computes. But the new SNES really is a substantial redesign of a lot of the hardware. Not as much as a clone RetroDuo, but still. I chose to go after 1/1/1 and 2/1/3. When those are perfected (hah), I can consider the mini-SNES more.

But differences aside, these algorithms do have the important property that the true results are available at the correct time now. And it means that anything that relies on them won't work on certain hardware revisions.

So this really is an important thing to have. Almost as important as not writing to VRAM during active display.
Posted By: R. Belmont Re: The SNES WIP topic - 03/14/10 12:56 AM
MESS SVN #7566 passes all 4 ADC/SBC test programs. Woot! smile
Posted By: Stiletto Re: The SNES WIP topic - 03/14/10 01:24 AM
Woot indeed. Good job guys!
Posted By: byuu Re: The SNES WIP topic - 03/14/10 06:02 AM
Quote:
MESS SVN #7566 passes all 4 ADC/SBC test programs. Woot!


Great laugh

And as for:
http://www.allgoodthings.us/mambo/index....d=2&id=3791

My turn to say this back at Cowering ... "hopefully some of the other emu authors will fix their code" :P


(and my screenshot isn't double-width xD)

But I'll be nicer wink

http://byuu.org/temp/test_math.zip
http://bsnes.googlecode.com/files/bsnes_v062.zip

There is one small caveat. It seems real hardware will freak out on rare occasion if you strobe the registers too quickly. You'll see in my test_math.ufo file that there are three invalid bytes. They are essentially being ORed with ... something.

When this ORing happens depends on the individual SNES (different even for the same CPU/PPU1/PPU2 combination), and it is consistent (eg repeatable); and blargg has one that doesn't OR results at all.

The important point though is that the underlying algorithms are correct, as is the timing.
Posted By: Haze Re: The SNES WIP topic - 03/14/10 10:34 AM
Originally Posted By byuu
Quote:
MESS SVN #7566 passes all 4 ADC/SBC test programs. Woot!


Great laugh

And as for:
http://www.allgoodthings.us/mambo/index....d=2&id=3791

My turn to say this back at Cowering ... "hopefully some of the other emu authors will fix their code" :P


(and my screenshot isn't double-width xD)

But I'll be nicer wink

http://byuu.org/temp/test_math.zip
http://bsnes.googlecode.com/files/bsnes_v062.zip

There is one small caveat. It seems real hardware will freak out on rare occasion if you strobe the registers too quickly. You'll see in my test_math.ufo file that there are three invalid bytes. They are essentially being ORed with ... something.

When this ORing happens depends on the individual SNES (different even for the same CPU/PPU1/PPU2 combination), and it is consistent (eg repeatable); and blargg has one that doesn't OR results at all.

The important point though is that the underlying algorithms are correct, as is the timing.


Fantastic, this is the kind of guy we need running tests on the Seibu COP stuff, Dox doesn't have the patience to figure out what the seemingly random / unexpected results he gets are, and why we're getting them and how to avoid them ;-) (I concede, it doesn't make much sense tho) Some random addition / xoring going on there too, even on the 'simple' memcpy routines ;-/
Posted By: R. Belmont Re: The SNES WIP topic - 03/14/10 12:00 PM
The funny thing about Cowering posting that is the code for it was promptly ripped back out for breaking everything else smile

Also, MVN/MVP are perfectly useful on systems that actually have more than 128k of RAM, although it'd be nice if the extra 3 cycles/byte had been fixed. That's the cost of the world's last hand-laid-out processor I guess.
Posted By: byuu Re: The SNES WIP topic - 03/14/10 07:06 PM
Quote:
The funny thing about Cowering posting that is the code for it was promptly ripped back out for breaking everything else


Yeah, it didn't bother me at all, it was just kinda funny. The presumption that I wasn't aware of something so basic after all the stuff I've uncovered smile

Either way, I'm glad he brought it up and gave me the motivation to look at it again. It's wonderful to have one more nightmare behind us.

The final things left to do:
* S-CPU auto joypad poll timing
* S-CPUr1 HDMA crash detection
* S-CPU<>S-SMP port ORing
* S-SMP timer glitching
* S-SMP TEST register
* S-DSP mute pulse
* pseudo-random initialization of memory
* full cycle-level emulation of the S-PPU

If we get all of that, I will consider emulation as close as the difference between hardware revisions.

Quote:
Also, MVN/MVP are perfectly useful on systems that actually have more than 128k of RAM, although it'd be nice if the extra 3 cycles/byte had been fixed. That's the cost of the world's last hand-laid-out processor I guess.


It has such an immense cost per byte. 56 cycles/byte, whereas DMA is 8 cycles/byte.
Posted By: R. Belmont Re: The SNES WIP topic - 03/14/10 07:43 PM
Sure. But back in the real world that's 7 cycles/byte, DMA doesn't exist, and you have a 320x200 framebuffer with per-scanline palettes, H-INTs and optional RLE mode. No separate sound CPU, but you've got a chip that can play 32 channels of 8-bit samples by DMA. Now show solid-filled rotating polygonal objects with scrollers and music and starfields (and yes, people did).

The CPU wasn't designed for Nintendo, it was designed for Apple and Commodore. Once you understand that, it makes more sense smile
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/15/10 01:07 AM
What about the timing sync stuff between S-CPU and S-SMP/APU? I thought someone tried to test that and blew up their copier or something bad like that? I'm not even sure how that's possible...

LN
Posted By: byuu Re: The SNES WIP topic - 03/15/10 05:04 AM
Heh, blargg and I just spent eight hours researching the S-SMP TEST register. You guys are going to give up and quit when you see just how complex it really is, heh. It is, without a doubt, the craziest 8-bit register I've ever seen in my life. And we're still going.

http://byuusan.kuro-hitsuji.net/blargg_2010-03-14.zip

Quote:
What about the timing sync stuff between S-CPU and S-SMP/APU? I thought someone tried to test that and blew up their copier or something bad like that? I'm not even sure how that's possible...


My UFO 8.3j's RAM stopped working after trying it. Probably a bus conflict damaged it. It came back to life after 1.5 years of disuse, too. It may have been a coincidence, but at $200 a pop, I wasn't going to try again.

blargg tried it on hardware, it ORs between the old value and new value, but only on some bits, and only some of the time. Need pseudo-randomness and an extreme timing system to simulate it. Bit-perfect emulation of it is a misnomer.
Posted By: RColtrane Re: The SNES WIP topic - 03/15/10 04:31 PM
Super Kick Boxing has some graphic glitches again... frown
Posted By: etabeta78 Re: The SNES WIP topic - 03/15/10 06:24 PM
might be the same problem as r-type 3. if so, I'm trying to fix it... let's see how it does work out (especially because I have improvements to sprites waiting to be added smile )

of course, I would appreciate a lot if you can help to narrow down when the regression happened wink
Posted By: judge Re: The SNES WIP topic - 03/15/10 06:27 PM
etabeta78: will you also look at the div/mul implementation for mame/mess?
Posted By: etabeta78 Re: The SNES WIP topic - 03/15/10 07:06 PM
I have been away in the weekend. once I manage to commit OAM progresses, I will definitely look into byuu's and blargg's new findings.

but aren't the new findings mainly CPU related? if so, maybe Arbee wants to take care of them (to avoid breaking apple2gs in MESS)
Posted By: R. Belmont Re: The SNES WIP topic - 03/15/10 07:20 PM
Which new findings? ADC/SBC has already been committed.
Posted By: etabeta78 Re: The SNES WIP topic - 03/15/10 07:24 PM
isn't mul/div being worked on as well?

http://board.byuu.org/viewtopic.php?f=16&t=569&start=0
Posted By: R. Belmont Re: The SNES WIP topic - 03/15/10 07:42 PM
mul/div are SNES hardware, not CPU instructions.
Posted By: etabeta78 Re: The SNES WIP topic - 03/15/10 08:00 PM
my bad. I must have misread some of byuu's posts here, and I while I was traveling I wasn't able to follow the discussion on bsnes board.

I'll take a look when I can.

in the meanwhile, both r-type 3 and super kick boxing have sprite issues. my first series of OAM updates won't fix them (even if they will finally implement proper sprite limits in MESS), but I'm looking for a fix. hopefully, I will find it soon smile
Posted By: byuu Re: The SNES WIP topic - 03/15/10 08:01 PM
I also discovered an edge case with my implementation in v062.

It seems a lot of games are really good at parallelizing, and will write to $4202, $4204 and $4205 immediately after writing to $4203 and $4206.

What happens is when you write to $4203 and $4206, it caches the current values (WRMPYA + WRMPYB or WRDIVA + WRDIVB), and then each stage of the ALU doesn't actually employ a variable bit-shifter (obviously), but shifts those temporary values by one place each time. In other words, the internal values get decimated after the computation is complete; hence the need for the internal variables.

I guess programmers realized this and took advantage of it to edge out a little more speed.

You'll need to support this, or Seiken Densetsu 3 and Winter Gold, to name two, glitch in certain areas.

Lastly, I understand the importance of adding these things, especially while my knowledge about them is strong and I can help. But things like MUL/DIV are only going to cause new bugs, and not fix any games. With the problems you guys are having with general CPU timing, PPU rendering, etc ... it may not be the best idea to be going after these extreme edge cases, heh. I mean, there's hundreds of these things. Still, I'm happy to assist if you want this added now.
Posted By: Justin Re: The SNES WIP topic - 03/16/10 02:26 AM
You assume we care about playing games, personally I think breaking emulator detection is way cooler laugh
Posted By: byuu Re: The SNES WIP topic - 03/16/10 04:05 AM
Poorly worded. I meant there are behaviors that are more important, as evidenced by the fact that a lot more software relies upon them.

Okay, I wrote this up to help you guys out:
http://board.byuu.org/viewtopic.php?f=16&t=576

And blargg's tests are here:
http://byuu.org/temp/muldiv_tests.zip

There's additional research from what was mentioned previously, but it should now comprise 100% of all possible edge cases. Eg writes during computation, reads of RDDIV inside multiplication (yes, it actually updates that too), and full cycle stepping validation.

You're definitely going to need your core broken into individual cycles (eg no word reads), but it doesn't need external synchronization between cycles. Just call the alu_edge() function between each cycle and you should be good.
Posted By: etabeta78 Re: The SNES WIP topic - 03/16/10 05:43 AM
which means that it will take a while wink

let me fix OAM and slightly clean up dma/hdma, then I will see if I can get closer to bsnes about mul/div as well.
Posted By: etabeta78 Re: The SNES WIP topic - 03/16/10 10:52 AM
Originally Posted By RColtrane
Super Kick Boxing has some graphic glitches again... frown


I found the reason of these glitches: a "break;" had disappeared (while I was fixing a regression in Super Street Fighter 2) and we ended up changing the sprite address at the wrong time.

It's unfortunate you haven't noticed it before 0.137, but huge thanks for reporting it now. smile

Indeed, Super Kick Boxing suffered of the same problem as R-Type 3, but I was pretty sure the latter got broken by my new OAM code. Thanks to your report, I was able to discover that in fact both problems were present since rev.7546 and this helped a lot to spot the real issue and to fix it.

I will never repeat it enough: development and progresses would be way slower without testers.


EDIT: and, to clarify, the R-Type 3 regression which got fixed is the messed up title screen. problems reported in the advanced levels ( http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=59855#Post59855 ) are still there and will need some more debugging.
Posted By: Anna Wu Re: The SNES WIP topic - 03/16/10 02:58 PM
etabeta78 and byuu :

Thanks for your great effort to make the snes emulation better !

Posted By: R. Belmont Re: The SNES WIP topic - 03/16/10 03:29 PM
I can't wait for the first complaints now that sprite flickering is implemented (especially since most other (S)NES emulators let you turn it off).

Is there a document that breaks down the master cycles for all of the S-CPU instructions?
Posted By: byuu Re: The SNES WIP topic - 03/16/10 10:29 PM
Master cycles are based on memory access timing.

You won't find a better algorithm than mine. Even beats full and partial lookup table variants.

Code:
//rom_speed = 6 if $420d.d0 is set (FastROM), 8 otherwise
unsigned sCPU::speed(unsigned addr) const {
  if(addr & 0x408000) {
    if(addr & 0x800000) return rom_speed;
    return 8;
  }
  if((addr + 0x6000) & 0x4000) return 8;
  if((addr - 0x4000) & 0x7e00) return 6;
  return 12;
}


As for breaking apart the S-CPU cycles, you should really use the bsnes source code. There is the W65C816S documentation that explains it (only the older version), but it has errors. Especially in WAI and IRQ timing. And it's missing the IRQ edge case condition that converts an I/O cycle into a bus read.

Really, you'll save yourselves two years of fixing IRQ bugs in golf games if you port my S-CPU core instead of writing your own ... but whatever you guys want to do wink

If you go your own route, you should decide on whether or not you will use cooperative threading. Save states are still possible with it. If you choose not to, you will wish for death upon attempting to implement bus hold delays and proper H/DMA bus synchronization in a state machine. I couldn't do it after 2 years, and the Snes9X team gave up on it as well.

Also, here's the code we have so far for the S-SMP TEST register:
http://board.byuu.org/viewtopic.php?p=12381#p12381

Another gem. There is absolutely no game known, not even in the demo scene, that ever writes anything at all to this register.
Posted By: R. Belmont Re: The SNES WIP topic - 03/17/10 12:17 AM
Quote:
Really, you'll save yourselves two years of fixing IRQ bugs in golf games if you port my S-CPU core instead of writing your own ... but whatever you guys want to do


Twist my arm ;-)

Seriously, while we won't have cooperative threading initially, it's definitely something Aaron wants to look at. There are a number of 3D systems (e.g. Model 2) where the CPU or DSP is supposed to stall on FIFO reads/writes, and that's basically impossible without cothreads.
Posted By: etabeta78 Re: The SNES WIP topic - 03/17/10 12:33 AM
Back to my small contributions, I decided to temporarily stop the work on DMA/HDMA [1], and to convert the SNES sound to be a MAME device.

This allows to remove a few static variables and represents a first (small) step towards save states. The code will be added tomorrow morning (I have to review the changes and I'm definitely too tired right now)

Next target for device-fication might be the PPU...

[1] Tokimeki Memorial refuses to work properly as soon as
- I init HDMA according to docs
- I enable HDMA direction bit
- I add indirect transfer edge cases
Given that all 3 things are supposed to happen on the hardware, this means I'm missing something else. In any case, Kale did a wonderful job with the current code, and I only expect this to have a minor impact on the MESS emulation (but of course, there is no reason we should not try to follow Anomie's docs and byuu's source, for accuracy sake wink )
Posted By: byuu Re: The SNES WIP topic - 03/17/10 02:27 AM
anomie left before some of my HDMA findings, so I suppose I can tell you what to look out for.

The biggest one is that during an HDMA, all of the effective bytes are written to registers for all eight channels first, and then all eight channels update the line counter and fetch new addresses if necessary. In other words, the write + address fetch for each channel is not interleaved.

The reason for that is so that all of the PPU writes are always inside H-blank, even if you have eight indirect addressed HDMA modes transferring four bytes and reloading them all on the same scanline. Believe it or not, a couple of games need this.

And I think anomie may have updated his doc for this one, but just in case, there's a short-circuit behavior that was a bit trickier than first thought. If you are on the very last active HDMA channel, and it performs an indirect HDMA address load, and the channel is now completed, HDMA does not fetch the high byte of the address. The low byte ends up in the high byte (it's shifted in) and the low byte ends up as 0x00. The part that was determined post-anomie was that it only happens to the very last active HDMA channel for that transfer. Again, this one will break one game if not correct.

You'll probably want proper DMA/HDMA <> CPU synchronization added before doing the above. Because if you're off by ~6-12 cycles on every single transfer anyway, what's 8 more in extreme edge cases going to hurt? smile

Quote:
There are a number of 3D systems (e.g. Model 2) where the CPU or DSP is supposed to stall on FIFO reads/writes, and that's basically impossible without cothreads.


It'll really make your life easier if you want perfect HDMA<>CPU sync timing and bus hold delays smile

So you may want to hold off on your cycle-CPU until then.
Posted By: JonasP Re: The SNES WIP topic - 03/17/10 09:21 AM
the latest updates fixed the intro logo in Donkey kong country 3! smile

Still suffers from some priority issues though
Posted By: Haze Re: The SNES WIP topic - 03/17/10 10:14 AM
Originally Posted By R. Belmont
Quote:
Really, you'll save yourselves two years of fixing IRQ bugs in golf games if you port my S-CPU core instead of writing your own ... but whatever you guys want to do


Twist my arm ;-)

Seriously, while we won't have cooperative threading initially, it's definitely something Aaron wants to look at. There are a number of 3D systems (e.g. Model 2) where the CPU or DSP is supposed to stall on FIFO reads/writes, and that's basically impossible without cothreads.


and the 32x.
Posted By: R. Belmont Re: The SNES WIP topic - 03/18/10 02:54 AM
Sega never does something once. Which is why Cool Riders is such an interesting puzzle.
Posted By: Haze Re: The SNES WIP topic - 03/18/10 11:55 AM
Originally Posted By R. Belmont
Sega never does something once. Which is why Cool Riders is such an interesting puzzle.


I'm pretty sure they only did that sprite compression once ;-)

but yeah, there's something weird going on with that.. I wouldn't be surprised if that port where it writes ou the details for the front tilemaps / sprites wasn't some kind of comms port to be used with the other cpu (which doesn't do much yet, unless it's really just for the linkup)

I couldn't understand it, nor does it seem to send enough data to tell me which parts of the sprites I need to decompress anyway. Really, I'm surprised Luca or somebody similar hasn't picked it up, that kind of pseudo-blitter weirdness is usually right down his street. (which is why I mentioned those 4 games to him)
Posted By: jbo_85 Re: The SNES WIP topic - 03/23/10 01:54 PM
The remaining OAM priority issues can be fixed by only checking the priority of the topmost sprite against the backgrounds.

Passage in Anomie's Register Doc:
Code:
Note that only the priority of the topmost sprite is
considered relative to the backgrounds. Thus, if FirstSprite+3 and
FirstSprite+4 are identical except FirstSprite+3 has priority 0 and
FirstSprite+4 has priority 3, they will both be hidden by any backgrounds that
hide priority 0 sprites. This may seem counterintuitive, since FirstSprite+4
would normally go in front of these BGs, but many games depend on this
behavior.

Posted By: AWJ Re: The SNES WIP topic - 03/23/10 02:04 PM
That's exactly the same behaviour as the NES, only extrapolated to multiple BG layers and more than two levels of sprite priority. On the NES, IIRC either Super Mario Bros or SMB3 (or both) relies on it to produce the effect of a powerup item rising out of a block.
Posted By: Haze Re: The SNES WIP topic - 03/23/10 03:44 PM
Originally Posted By AWJ
That's exactly the same behaviour as the NES, only extrapolated to multiple BG layers and more than two levels of sprite priority. On the NES, IIRC either Super Mario Bros or SMB3 (or both) relies on it to produce the effect of a powerup item rising out of a block.


on a similar note, can somebody on good terms with the regen guys get the proper megadrive sprite masking algorithm? the one I have works with many of the difficult cases (pirates gold, galaxy force 2 etc.), but falls apart for some simple ones like the SOR status bar. None of the documentation I have seems accurate and able to handle all cases.
Posted By: etabeta78 Re: The SNES WIP topic - 03/23/10 05:01 PM
Originally Posted By jbo_85
The remaining OAM priority issues can be fixed by only checking the priority of the topmost sprite against the backgrounds.

Passage in Anomie's Register Doc:
Code:
Note that only the priority of the topmost sprite is
considered relative to the backgrounds. Thus, if FirstSprite+3 and
FirstSprite+4 are identical except FirstSprite+3 has priority 0 and
FirstSprite+4 has priority 3, they will both be hidden by any backgrounds that
hide priority 0 sprites. This may seem counterintuitive, since FirstSprite+4
would normally go in front of these BGs, but many games depend on this
behavior.



I spent quite some time in the past few days on this, but I'm not sure how this should work exactly. In particular, what does "topmost" means here?

If I use the priority of FirstSprite only for all sprites, in each line, then all the sprites will use the same priority w.r.t. the bg, i.e. all sprites become OAM0, OAM1, OAM2 or OAM3 depending on the priority of FirstSprite.

While this indeed fixes the current priority problems in Chrono Trigger intro, it also introduces many brand new priority problems. Look at the following snap, from Chrono Trigger intro, and in particular to the half-hidden character on the right:



the snap only shows Mode1 BG1A (the one with higher priority) and sprites, to better isolate the issue: FristSprite is OAM2, i.e. priority 6; BG1A has priority 8; the sprite of the jumping/rolling Goku-like character is OAM3, i.e. it would have priority 9. By using FirstSprite priority for all the sprites, you end up with OAM3 to become OAM2 and with the OAM3 sprites hidden below the BG1 layer, as the snap shows...

Another example is again in Chrono Trigger intro: the judge with the hammer disappears below its seat (which has higher priority than FirstSprite)...

I guess the problem it's me not understanding the docs, but could anyone explain me how this should work exactly?

EDIT: for whoever wants to try the code, I simply changed line 1265 of video/snes.c from

Code:
priority = oam_spritelist[active_sprite].priority_bits;


to

Code:
priority = oam_spritelist[0].priority_bits;


so that all the sprites in a line get the FirstSprite priority...
Posted By: etabeta78 Re: The SNES WIP topic - 03/23/10 05:19 PM
Originally Posted By Haze
on a similar note, can somebody on good terms with the regen guys get the proper megadrive sprite masking algorithm? the one I have works with many of the difficult cases (pirates gold, galaxy force 2 etc.), but falls apart for some simple ones like the SOR status bar. None of the documentation I have seems accurate and able to handle all cases.


did you check eke's genplus-gx source

the guy has done a lot of work on it (and he's always sharing back info, like Arbee well knows for the sound findings)
Posted By: R. Belmont Re: The SNES WIP topic - 03/23/10 05:21 PM
Yeah, I would post at the Spritesmind board asking. If they don't know it, there's several people there that frequently run tests on hardware.
Posted By: AWJ Re: The SNES WIP topic - 03/23/10 09:50 PM
Originally Posted By etabeta78
I spent quite some time in the past few days on this, but I'm not sure how this should work exactly. In particular, what does "topmost" means here?


The best way to understand it is that sprite-to-sprite priority (which depends on the sprite's index) is always completely evaluated before sprite-to-BG priority (which depends on the sprite's priority bits in OAM).

Say you have an opaque pixel from sprite 0 with priority 0, from sprite 1 with priority 3, and from a background tile all overlapping at the same screen position. Sprite 0 takes priority over sprite 1 because it is a lower-numbered sprite. Then, the background takes priority over Sprite 0 because that sprite is priority 0. The pixel color that gets outputted at that position is the background tile pixel.

The fact that Sprite 1 has priority over the background is irrelevant because Sprite 1 has already been masked by Sprite 0 before sprite-to-background priority is evaluated.

Many games on the NES and especially on the SNES take advantage of this quirk to selectively mask out parts of sprites and to simulate finer-grained levels of priority than the hardware natively provides.
Posted By: Haze Re: The SNES WIP topic - 03/23/10 11:16 PM
Originally Posted By etabeta78
Originally Posted By Haze
on a similar note, can somebody on good terms with the regen guys get the proper megadrive sprite masking algorithm? the one I have works with many of the difficult cases (pirates gold, galaxy force 2 etc.), but falls apart for some simple ones like the SOR status bar. None of the documentation I have seems accurate and able to handle all cases.


did you check eke's genplus-gx source

the guy has done a lot of work on it (and he's always sharing back info, like Arbee well knows for the sound findings)


Not wanting to drag this further off-topic, but this looks to me like the 'classic' first theory implementation, which causes problems in some games. I'll need to test the win32 build of the emulator at some point, but I have a feeling it won't handle several known cases.
Posted By: etabeta78 Re: The SNES WIP topic - 03/24/10 06:29 AM
Originally Posted By AWJ
The best way to understand it is that sprite-to-sprite priority (which depends on the sprite's index) is always completely evaluated before sprite-to-BG priority (which depends on the sprite's priority bits in OAM).

Say you have an opaque pixel from sprite 0 with priority 0, from sprite 1 with priority 3, and from a background tile all overlapping at the same screen position. Sprite 0 takes priority over sprite 1 because it is a lower-numbered sprite. Then, the background takes priority over Sprite 0 because that sprite is priority 0. The pixel color that gets outputted at that position is the background tile pixel.

The fact that Sprite 1 has priority over the background is irrelevant because Sprite 1 has already been masked by Sprite 0 before sprite-to-background priority is evaluated.

Many games on the NES and especially on the SNES take advantage of this quirk to selectively mask out parts of sprites and to simulate finer-grained levels of priority than the hardware natively provides.


Ok. In other words, it means that it's "topmost" in each pixel and not in each line. that makes sense and for sure it fixes the new problem in the screen I posted above.
I thought I had already tried to implement the priorities in the way you described, without properly fixing all the problems... but probably that was due to some different mistake of mine. I'll go back and try it again now that I know it is the correct approach.

Thanks a lot for clearing out the matter!
Posted By: etabeta78 Re: The SNES WIP topic - 03/24/10 11:42 AM
I was pretty sure I had already tried the "topmost-per-pixel" approach, and indeed when I applied it again, I ended up with the following image I remembered from my past tests:



the "lighted" tile is OAM0 and I thought (when I first tried this solution) it was a priority problem causing it to appear above BG2B. This time, thanks to AWJ, I knew priorities were fine, so I looked for other possible causes. In particular, toggling off the color math, I obtained this



i.e. color math is the effect responsible for darkened/lightened images...

long story short, the way I implemented sprite priorities was properly disabling color math whenever the sprite had palette 0-3, but it was not enabling it again if the sprite was covered by a BG with color math enabled. Fixing this stupid bug, sprites are finally correct



known graphics issues still present:
- hires mosaic is slightly wrong (and it cannot be fixed without partially rewriting hires rendering, however it should be barely noticeable)
- some tiles get corrupted after a while (R-Type 3)
- TMNT has strange coloured rectangles partially covering texts in the intro...
- pseudo-hires is still missing (I think I have it working, as the following snap shows



but I'd like to test screens with Dr.DNA trivia before officially adding it... does anyone know how to reach one of these trivia screen in Jurassic Park?)
Posted By: etabeta78 Re: The SNES WIP topic - 03/24/10 01:16 PM
ok. I managed to find a Dino Trivia screen (god, I always hated this game! ;)). the effect in MESS looks as follows (with pseudo-hires implemented):



definitely close to the image byuu posted some time ago



(left: tv/bsnes, right: emu with no pseudo-hires, bottom: emu with pseudo-hires)
Posted By: etabeta78 Re: The SNES WIP topic - 03/24/10 02:46 PM
thanks to half an hour of coffee break, I implemented blargg's & byuu's average routine for hires/pseudo-hires pixels. once I have cleaned up a bit the code [1], this will be added as an option for the user, to more accurately reproduce the tv blurring the same way as bsnes does. MESS screen:



[1] direct use of byuu's code does not work in this case, because we don't output pixels in order and I would like to avoid any additional drawing step (which could slightly hit performances)
Posted By: R. Belmont Re: The SNES WIP topic - 03/24/10 03:19 PM
Nice smile
Posted By: Haze Re: The SNES WIP topic - 03/24/10 04:50 PM
Originally Posted By R. Belmont
Nice smile


It looks better.. but unless it's part of the SNES chip it should be part of the MESS video output, not part of the system emulation. Many Megadrive games benefit from similar, but it's definitely not part of the genesis VDP. Polluting the emulation code with hacks to make the video emulation look nicer isn't really progress. If it is part of the SNES chip, then, yes, very nice :-)
Posted By: R. Belmont Re: The SNES WIP topic - 03/24/10 04:52 PM
Yes, well, until someone submits this mythical video output filter code this is the way to go (marked as "hack" of course).
Posted By: etabeta78 Re: The SNES WIP topic - 03/24/10 05:14 PM
well, as byuu explained once, it's part of the way a real tv would diplay snes output: a tv would not be able to separately show the 512 pixels present in hires or pseudo hires mode (i.e. no alternate columns as in the first screen, but only a blended mix of the two as in the second one).

iirc, it's something related to phosphors in a crt tv, but I guess he can better argument the need for this (completely unrelated to ntsc filter, though)

of course, this will be an option in the Driver Configurations and won't be present for NSS or bootlegs in MAME... and it will be marked as an hack in the code (it is also pretty much isolated in the last step of the drawing, so it does not obfuscate the way we document SNES drawing behaviour)

EDIT: also, let me stress that this "averaging" code is not a filter to improve the appearance and make the games look better, but it is the best way to make the LCD output similar to the expected tv output when the SNES outputs 512 half-pixels in place of the usual 256 pixels... still an optional hack, and marked as such, but without altering the way things should appear.
Posted By: Just Desserts Re: The SNES WIP topic - 03/24/10 06:03 PM
Originally Posted By etabeta78
well, as byuu explained once, it's part of the way a real tv would diplay snes output: a tv would not be able to separately show the 512 pixels present in hires or pseudo hires mode (i.e. no alternate columns as in the first screen, but only a blended mix of the two as in the second one).


Err, perhaps not, but that would only be due to the dot pitch of the phosphor mask, not anything inherent to the NTSC signal carrying the video signal itself, yes?
Posted By: Haze Re: The SNES WIP topic - 03/24/10 06:18 PM
Originally Posted By etabeta78

EDIT: also, let me stress that this "averaging" code is not a filter to improve the appearance and make the games look better, but it is the best way to make the LCD output similar to the expected tv output when the SNES outputs 512 half-pixels in place of the usual 256 pixels... still an optional hack, and marked as such, but without altering the way things should appear.


How is it not so, it sounds EXACTLY like a filter to improve the appearance of the games and make them look better on an LCD screen. If you wired the SNES up to a good enough quality TV I guess you'd see something like the unfiltered shots. Just because it isn't increasing the resolution and adding fake pixels doesn't mean it isn't a filter, in this case it's bluring pixels into fake pixels instead. Both are image enhancement filters.

I'm just not convinced that the build-up of these things in drivers is a good thing, efforts should be concentrated on improving MAME's ability to filter the output from the drivers instead, which will probably involve convincing Aaron to make the existing filter system more flexible, and maybe allowing drivers to provide additional metadata to it, so that it can better apply effects on lines where fake pixel doubling has occured etc. It would be nice if things like the NTSC filter were available to anybody who wanted to use them, on any driver. It's a decent filter and a lot more useful than burn-in simulators...

Actually doing the filtering in the drivers seems incorrect. I said the same about 'LCD flicker filters' for Gameboy etc. and I'll say the same for this.

What motivation is there to do it properly if all the drivers hack in their own implementations?
Posted By: etabeta78 Re: The SNES WIP topic - 03/24/10 06:40 PM
let's put it like this: if I were only blurring pseudo-hires pixels it would be a very bad hack (and I would have rejected it).
by equally blurring all 512 pixels modes, it is still an hack (and as such is turned off by default), but not so bad anymore imho, because it still describes the way TV would output the image

now, concerning general filter support in the core, it's not like there are thousands of devs which could add the necessary support into the core. I believe there are maybe 2 or 3 which could, and probably they won't care about incorrect and driver-specific workarounds, if they ever come to implement the support...

in the meanwhile, it's like with other screen artifacts: driver-specific workaround are probably better than nothing.
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/24/10 09:34 PM
the actual snes output is 512 pixels wide. in hires-X and hires-XY mode a bg layer is displayed on every single one of the 512 pixels. in normal mode the bg later is displayed with every pixel doubled (effectively horizontal res of 256). in pseudohires mode, two bg layers are displayed at once: one is displayed on every odd pixel of the 512, and one on every even pixel. The example image etabeta showed above (at http://mamedev.emulab.it/etabeta/fast/files/0051.png ) is correct (though the exact 'order' of the interleave of the two bg layers might be backwards, this is difficult but not impossible to check on real hardware). be sure to click on it so you can see it in full res.

Hires-Y mode and Hires-XY mode on the snes are flickery because they're swapping the Y lines every 60fps field, for a 30fps full framerate. Or this is how it's supposed to have worked.

LN
Posted By: byuu Re: The SNES WIP topic - 03/24/10 10:20 PM
I can understand the pedancy about blending hires mode. If you guys really want to go with the hideous version here ( http://mamedev.emulab.it/etabeta/fast/files/0051.png ), you can just tell people to stand really far back so that the eyes naturally blend the two layers wink

My understanding was that someone tried this on an RGB monitor (either with SCART or an RGB mod), and it still blurred. I don't think that the S-PPU itself is doing the blending.

Also note that the same blur affects both true hires and pseudo-hires. It's extremely inconsistent to only apply it to one and not the other. With the right tiledata and maps, you can make the exact same image in either true or pseudo-hires mode. They should not look different just because hires is more often actually 512-width, and pseudo-hires is more often used to blend two 256-width layers together.

----------

I have a huge favor to ask. Apparently the game Speedy Gonzales, both v1.0 and v1.1 lock up in level 6-1 whenever you hit this button:



Snark says it doesn't lock up on the real thing.

Some starting trace log stuff here:
http://board.byuu.org/viewtopic.php?f=3&t=611
http://board.byuu.org/viewtopic.php?f=3&t=571

I can't seem to figure this one out. It apparently affects every emulator out there, but not real hardware. And the game isn't doing anything even slightly unusual smirk

Given that it also affects MESS, could I bug you guys to see if you can find a fix as well smile

Would really like some help. None of the other SNES emu devs are active anymore.

EDIT: to make it less horrible, here's a hack to always start at level 6-1 smile

$81a626 lda $0b55
Modify that to:
a9 05 00; or lda #$0005

And Youtube comments on this:
http://www.youtube.com/comment_servlet?all_comments&v=4uUGr5wZJYg&fromurl=/watch%3Fv%3D4uUGr5wZJYg
Posted By: etabeta78 Re: The SNES WIP topic - 03/25/10 12:24 AM
Originally Posted By Lord Nightmare
The example image etabeta showed above (at http://mamedev.emulab.it/etabeta/fast/files/0051.png ) is correct (though the exact 'order' of the interleave of the two bg layers might be backwards, this is difficult but not impossible to check on real hardware). be sure to click on it so you can see it in full res.


the order should be fine as well: I followed Anomie's doc and BSNES by starting with the subscreen pixel, then going on with a mainscreen pixel etc.

Originally Posted By byuu
Also note that the same blur affects both true hires and pseudo-hires. It's extremely inconsistent to only apply it to one and not the other. With the right tiledata and maps, you can make the exact same image in either true or pseudo-hires mode. They should not look different just because hires is more often actually 512-width, and pseudo-hires is more often used to blend two 256-width layers together.


I started by the assumption that averaging only pseudo-hires would have been a gross hack, hence I followed your example and I blurred both (even if the whole blurring is an option left to the user).

Notice that tomorrow morning I will commit a more verbose revision of the code where, among other things, I will properly credit you and blargg for the average algorithm.

Originally Posted By byuu
I have a huge favor to ask. Apparently the game Speedy Gonzales, both v1.0 and v1.1 lock up in level 6-1 whenever you hit this button:



Snark says it doesn't lock up on the real thing.

Some starting trace log stuff here:
http://board.byuu.org/viewtopic.php?f=3&t=611
http://board.byuu.org/viewtopic.php?f=3&t=571

I can't seem to figure this one out. It apparently affects every emulator out there, but not real hardware. And the game isn't doing anything even slightly unusual smirk

Given that it also affects MESS, could I bug you guys to see if you can find a fix as well smile

Would really like some help. None of the other SNES emu devs are active anymore.


yeah, I was following that thread. I'll see if I can find any possible reason for the freeze, but I hope Kale and/or Just Dessert could take a look as well, since they are way better than me in this...
Posted By: byuu Re: The SNES WIP topic - 03/25/10 12:56 AM
Quote:
I'll see if I can find any possible reason for the freeze, but I hope Kale and/or Just Dessert could take a look as well, since they are way better than me in this...


Thanks a lot, I really appreciate the help laugh

Would be good to verify it happens in MESS too, I can't get to that point without cheat codes and save states; even with the start-at-6-1 hack.
Posted By: Xor Re: The SNES WIP topic - 03/25/10 05:59 AM
Great work etabeta, time for me to do an svn update and some serious testing methinks!
Posted By: JonasP Re: The SNES WIP topic - 03/25/10 08:12 AM
With the latest updates (great work!) the only remaining issue in DKC3 is the scrambled text in Swanky's side show.
Posted By: byuu Re: The SNES WIP topic - 03/25/10 08:43 AM
I've mostly cracked Speedy Gonzales. It seems that under certain circumstances, it's possible to glitch the S-CPU MDR to feed back 0x00 instead of the actual MDR. Speedy gets stuck in a loop for several hundred iterations fetching $1818, until eventually it gets $1800 and breaks out (by extreme luck and through multiple nested convolutions. This was definitely a bug in the game and not intentional.)

Logged hardware results and test source code here:
http://board.byuu.org/viewtopic.php?p=12961#p12961

So, you guys are the most pedantic about emulation authenticity (not a bad thing!) ... we can't emulate this. The glitch occurs completely randomly and unpredictably. The closest we can do is simulate it with a pseudo-random number generator, eg:

Code:
uint8_t CPU::getMDR() const {
  return (prng() % 255) ? regs.mdr : 0x00;
}


What would, or rather, what are, you guys going to do for this case? smirk
Posted By: etabeta78 Re: The SNES WIP topic - 03/25/10 09:47 AM
wow! you've been really fast!

dumb question (because I haven't read through the log results): is it 100% random? is there really nothing that can have changed the open bus value, due to some write/read from the game? it seems so strange that the game relies so heavily on unexpected behaviors... but I guess that bugged games have always existed, so this is just a particularly nasty example
Posted By: Haze Re: The SNES WIP topic - 03/25/10 09:56 AM
Originally Posted By byuu
I've mostly cracked Speedy Gonzales. It seems that under certain circumstances, it's possible to glitch the S-CPU MDR to feed back 0x00 instead of the actual MDR. Speedy gets stuck in a loop for several hundred iterations fetching $1818, until eventually it gets $1800 and breaks out (by extreme luck and through multiple nested convolutions. This was definitely a bug in the game and not intentional.)

Logged hardware results and test source code here:
http://board.byuu.org/viewtopic.php?p=12961#p12961

So, you guys are the most pedantic about emulation authenticity (not a bad thing!) ... we can't emulate this. The glitch occurs completely randomly and unpredictably. The closest we can do is simulate it with a pseudo-random number generator, eg:

Code:
uint8_t CPU::getMDR() const {
  return (prng() % 255) ? regs.mdr : 0x00;
}


What would, or rather, what are, you guys going to do for this case? smirk


won't this mean there is a 1/256 chance of a game that requires the right value breaking? ;-) (of course, maybe it would on real hardware if the glitching is unconditional, and not caused by any kind of excessive reading / writing / other activity in the system)
Posted By: etabeta78 Re: The SNES WIP topic - 03/25/10 10:00 AM
Originally Posted By JonasP
With the latest updates (great work!) the only remaining issue in DKC3 is the scrambled text in Swanky's side show.


could you provide an .inp file from the start to a Swanky show? remember to either delete .nv or to include it together with the inp file.

thanks in advance smile
Posted By: judge Re: The SNES WIP topic - 03/25/10 10:52 AM
Originally Posted By byuu
I've mostly cracked Speedy Gonzales. It seems that under certain circumstances, it's possible to glitch the S-CPU MDR to feed back 0x00 instead of the actual MDR. Speedy gets stuck in a loop for several hundred iterations fetching $1818, until eventually it gets $1800 and breaks out (by extreme luck and through multiple nested convolutions. This was definitely a bug in the game and not intentional.)

Logged hardware results and test source code here:
http://board.byuu.org/viewtopic.php?p=12961#p12961

So, you guys are the most pedantic about emulation authenticity (not a bad thing!) ... we can't emulate this. The glitch occurs completely randomly and unpredictably. The closest we can do is simulate it with a pseudo-random number generator, eg:

Code:
uint8_t CPU::getMDR() const {
  return (prng() % 255) ? regs.mdr : 0x00;
}


What would, or rather, what are, you guys going to do for this case? smirk


I find it hard to believe that it would be truly random (or random all the time). I'd expect there to be some special case that's triggering this.

Is the test done using the same screen parameters (possibly even contents) as the place of the bug? Or maybe sound? Are irqs enabled?

(fyi, I know nothing about snes hardware)
Posted By: R. Belmont Re: The SNES WIP topic - 03/25/10 12:33 PM
Yeah, this has got to be some kind of DMA/IRQ/who knows what interaction. Lots of other games would break if that readback really did randomly screw up.

ETA: does this game work on the later "slimline" SNES with the revised less-buggy chipset?
Posted By: JonasP Re: The SNES WIP topic - 03/25/10 02:06 PM
Originally Posted By etabeta78
Originally Posted By JonasP
With the latest updates (great work!) the only remaining issue in DKC3 is the scrambled text in Swanky's side show.


could you provide an .inp file from the start to a Swanky show? remember to either delete .nv or to include it together with the inp file.

thanks in advance smile


I can provide the .nv-file here. Just walk to the red and white tent and enter Swanky's show.
The ROM used is the NTSC version verified with no-intro.
NVRAM:
http://www.megaupload.com/?d=5Y7V67R2
Posted By: etabeta78 Re: The SNES WIP topic - 03/25/10 02:10 PM
thanks. it saves me a lot of time (especially because my eeepc cannot run snes at 100% speed) smile

I hope to find the problem (and a fix)
Posted By: byuu Re: The SNES WIP topic - 03/25/10 03:41 PM
EDIT: I figured it out. Solution is here:
http://board.byuu.org/viewtopic.php?p=12986#p12986

Basically, when NMI triggers (on the bus cycle edge), it clears the S-CPU Memory Data Register.

As the game loops while reading 16-bits, eventually an NMI triggers on the opcode edge after lda $185d,x [x=181a, effective=3077]; which turns $1818 into $0018. And that value magically gets the loop to break.

By observing the number of loop iterations needed to break out, it appears to match hardware very closely. Obviously it's not exact since the counters aren't aligned when you hit the button.

I will write a proper proof ROM later tonight to verify it 100%, but I'm pretty confident that we have this one cracked now.

Unfortunately this test is going to require clock-perfect S-CPU timing, but at least seeing it pass/fail on hardware, you can implement it in MESS smile
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/25/10 07:11 PM
ah, gotta love game bugs like this which accidentally abuse hardware.

LN
Posted By: Shoegazer Re: The SNES WIP topic - 03/26/10 12:25 AM
Just noticed an odd issue with the KO countdown timer in Super Punch-Out and 0.137. The left half of the timer number is diplayed on the far left side; while the right half is on the far right. The number should appear in the center of the screen (as it does in bsnes and real hw).

It's easy enough to replicate - just start the game and wait about 3-5 minutes through the attract mode/demo. Eventually the timer will appear.
Posted By: byuu Re: The SNES WIP topic - 03/26/10 05:30 AM
Side note: verified that the Speedy Gonzales thing is actually DMA and HDMA updating the MDR, not NMI as first suspected.

http://byuu.org/temp/test_mdrhdma.zip

It brings up entirely new problems by exposing that HDMA is asserting MDR after an opcode's read cycle from which the HDMA triggers; which is going to require a ground-up rethink of the MDR and HDMA sync subsystems. But anyway for right now, even without that, just let H/DMA update the MDR and Speedy will work.
Posted By: R. Belmont Re: The SNES WIP topic - 03/26/10 02:49 PM
Also the crap hack "Sonic on SNES" game that was based on Speedy. (That was way more interesting back before Sega started releasing 4 games a year featuring Sonic on Nintendo hardware).

Is this "ground up rethink" going to require major changes to your S-CPU? I want to know when it's safe to port, because I was gonna do it this weekend. That obviously would be dumb if it's gonna be in serious flux though.
Posted By: etabeta78 Re: The SNES WIP topic - 03/26/10 06:39 PM
Originally Posted By R. Belmont
Is this "ground up rethink" going to require major changes to your S-CPU? I want to know when it's safe to port, because I was gonna do it this weekend. That obviously would be dumb if it's gonna be in serious flux though.


I guess it's impossible to say it in advance:

http://board.byuu.org/viewtopic.php?f=16&t=614
Posted By: R. Belmont Re: The SNES WIP topic - 03/26/10 06:42 PM
Alright, I'll put that off then smile
Posted By: etabeta78 Re: The SNES WIP topic - 03/27/10 09:58 PM
fwiw, dkc3 garbled text is fixed in current svn



but latest fixes have broken Desert Figther title screen: I'm still working on a proper fix for this regression and on some more hdma improvements...
Posted By: etabeta78 Re: The SNES WIP topic - 03/28/10 07:47 AM
as of rev.7657 Desert Fighter title screen is properly cleared again (of course, without breaking Donkey Kong Country 3).

I hope to be able to make HDMA slightly closer to Anomie's doc soon, though... it might fix some other reported issues wink
Posted By: byuu Re: The SNES WIP topic - 03/28/10 07:58 AM
Spent about 14 hours on the problem, I can't come up with anything to perfectly emulate ( http://board.byuu.org/viewtopic.php?f=16&t=614 ), so if you wanted to port the S-CPU stuff you may as well do so now ... up to you, though.
Posted By: JonasP Re: The SNES WIP topic - 03/28/10 09:17 AM
Originally Posted By etabeta78
as of rev.7657 Desert Fighter title screen is properly cleared again (of course, without breaking Donkey Kong Country 3).

I hope to be able to make HDMA slightly closer to Anomie's doc soon, though... it might fix some other reported issues wink


Awesome!
Posted By: jbo_85 Re: The SNES WIP topic - 03/28/10 01:32 PM
There is a problem with Rudra no Hihou after you start a new game. The screen is wrong below the first textbox.
Posted By: etabeta78 Re: The SNES WIP topic - 03/28/10 03:32 PM
Originally Posted By byuu
Spent about 14 hours on the problem, I can't come up with anything to perfectly emulate ( http://board.byuu.org/viewtopic.php?f=16&t=614 ), so if you wanted to port the S-CPU stuff you may as well do so now ... up to you, though.


also, I start to think many of the remaining problems in the driver (but not all) reside in the CPU timing and opcodes... hence, a core which handles 99% of the cases properly would definitely help to single out the remaining problems in video and machine code.
Posted By: Lord Nightmare Re: The SNES WIP topic - 03/28/10 03:35 PM
And hopefully any future changes to fix the one case so far will not require gutting and redoing the entire s-cpu core...

LN
Posted By: etabeta78 Re: The SNES WIP topic - 03/28/10 06:04 PM
Originally Posted By guigongas
Here's a screenshot of the bug.



I hope this helps.


This bug reported in August has been fixed today (either by 7658 or by 7661). Not that I want to play this game, but...

Originally Posted By jbo_85
There is a problem with Rudra no Hihou after you start a new game. The screen is wrong below the first textbox.


This might have never worked (it was already broken during 0.136 cycle). Not sure what is causing the isssue, I'll add it to the list of bugs to check
Posted By: byuu Re: The SNES WIP topic - 03/29/10 07:10 AM
Originally Posted By Lord Nightmare
And hopefully any future changes to fix the one case so far will not require gutting and redoing the entire s-cpu core...


The worst possible thing that could happen is having my hold times for reads and writes disproven somehow. That would require adjusting every last timing value (when does Hblank start/stop, when does DMA transfer begin, etc) by +/-2 or whatever.

Nothing really major.

I also don't have the first idea how to verify it. All I know is that reading from $2137 latches the counters at N, and writing to $4201 latches them at N+4 master clock cycles.

Since they are FastROM, I extrapolate that to means writes "occur" at cycle_start+cycle_length, and reads "occur" at cycle_start+cycle_length-4.

TRAC concurred based off timing information in the official 65816 doc, but that doesn't mean it doesn't vary depending upon which chip / register you are accessing.

I don't have any way to verify that, need a hardware guru to go at it with an oscilliscope or something.
Posted By: JonasP Re: The SNES WIP topic - 03/29/10 12:51 PM
Accele Brid (r7661):

The game freezes with garbled graphics soon after you start a new game.
Posted By: Tafoid Re: The SNES WIP topic - 03/29/10 01:24 PM
Is this the japanese original or the english translation?
Some CRC's of the image would help.
Posted By: JonasP Re: The SNES WIP topic - 03/29/10 01:35 PM
Originally Posted By Tafoid
Is this the japanese original or the english translation?
Some CRC's of the image would help.


CRC32: 4a736c38
SHA1: 8c9b8623d51d646631c0e5bc592440db4cfd1eab

Japanese version
Posted By: Kale Re: The SNES WIP topic - 03/29/10 04:39 PM
Known bug, probably a flaw of the CPU core (i.e. not the timing).
Posted By: etabeta78 Re: The SNES WIP topic - 03/29/10 04:47 PM
btw, if you get annoyed by MZ-2500, you would be welcome to contribute here wink

e.g. any idea about why partial video updates in Desert Fighter start jumping between 80 and 140 as soon as you reach the screen with the mission map?
Posted By: guigongas Re: The SNES WIP topic - 03/29/10 04:57 PM
Originally Posted By etabeta78
This bug reported in August has been fixed today (either by 7658 or by 7661). Not that I want to play this game, but...

Thank you! smile
Posted By: JonasP Re: The SNES WIP topic - 03/29/10 05:50 PM
Originally Posted By Kale
Known bug, probably a flaw of the CPU core (i.e. not the timing).


OK, thanks. Is there a list of known bugs (I've checked bugzilla and it looks empty) to avoid double reports?
Posted By: Kale Re: The SNES WIP topic - 03/29/10 06:48 PM
Well, this topic is full of bug reports, somebody should go through the entire topic, check the bugs and do a recap, but it isn't a 5 minutes job.
Posted By: JonasP Re: The SNES WIP topic - 03/29/10 07:35 PM
Yeah, that's what I figured so I searched the forum for any post with the game title before reporting. Maybe it's listed under the export title?
Posted By: Kale Re: The SNES WIP topic - 03/30/10 02:18 AM
Checked Accelebrid, it does:

82D280: JSR ($d284,X) ;X is -0xfffe (!)
8260D2: SBC $ffffff,X ;bsnes has a rts here
8260D6: SBC $ffffff,X
...
827FFE: SBC $30c2ff,X


wrong rom image mapping I suppose ... or open bus.
Posted By: Justin Re: The SNES WIP topic - 03/30/10 02:22 AM
Originally Posted By Justin
This demo starts off cool, but then dies horribly.


This is working now. laugh
Posted By: etabeta78 Re: The SNES WIP topic - 03/30/10 05:38 AM
Originally Posted By Kale
Checked Accelebrid, it does:

82D280: JSR ($d284,X) ;X is -0xfffe (!)
8260D2: SBC $ffffff,X ;bsnes has a rts here
8260D6: SBC $ffffff,X
...
827FFE: SBC $30c2ff,X


wrong rom image mapping I suppose ... or open bus.


everything is possible, but I doubt it's a rom mapping fault. I double checked the mapping and it seems fine (same as bsnes I mean). I could have overlooked something, of course...

fwiw, if it calls bank1_r (as you mentioned in the shoutbox), then it's trying to access "banks" 0x00-0x20 or 0x80-0xa0 (the latter is covered by bank6_r, but for most cases this calls bank1_r). in both cases 0x7fff is either reserved or DSP1/2/3/4 (but this game does not have special chips, iirc)

EDIT: ok, Reserved memory should fall back to open bus (as in bsnes and as explained at http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=52896#Post52896 ). it does not fix Accelebrid, but it should be an improvement to accuracy. hence, I'm going to commit this change soon

EDIT2: added to svn
Posted By: byuu Re: The SNES WIP topic - 03/30/10 02:10 PM
Okay, I've written some tests to understand this HDMA-MDR behavior more: http://byuu.org/temp/test_mdrhdma2.zip

The good news is that we don't have a serious problem with bus timing nor HDMA execution order.

The bad news is that the behavior is flat out nonsense. In my first example, HDMA really does fetch before the S-CPU opcode cycle, and yet the subsequent open bus result is the HDMA fetch and not the S-CPU opcode fetch.

We can simulate it with some really fucked up code, but I would love to understand how the hell this is possible on a hardware level.

Also, an interesting side discovery came out of this: it wasn't storing the HDMA read value in MDR, it was storing the next HDMA counter value, even though a fetch wasn't at all needed (continuous HDMA mode was active with a high counter value.)

What this means is that for each active channel, it always fetches the next line value from the HDMA table. It will only actually use it and increment the HDMA address if the current line counter & 0x7f == 0, of course.

Makes sense from a hardware perspective, it's essentially saying there is no idle cycle, it's actually reading memory while checking the line counter at the same time.

It may explain the short-circuit behavior of HDMA indirect behaviors a bit better, but I haven't fully contrasted this finding with that one, yet.
Posted By: Kale Re: The SNES WIP topic - 03/30/10 02:44 PM
Originally Posted By etabeta78
Originally Posted By Kale
Checked Accelebrid, it does:

82D280: JSR ($d284,X) ;X is -0xfffe (!)
8260D2: SBC $ffffff,X ;bsnes has a rts here
8260D6: SBC $ffffff,X
...
827FFE: SBC $30c2ff,X


wrong rom image mapping I suppose ... or open bus.


everything is possible, but I doubt it's a rom mapping fault. I double checked the mapping and it seems fine (same as bsnes I mean). I could have overlooked something, of course...

fwiw, if it calls bank1_r (as you mentioned in the shoutbox), then it's trying to access "banks" 0x00-0x20 or 0x80-0xa0 (the latter is covered by bank6_r, but for most cases this calls bank1_r). in both cases 0x7fff is either reserved or DSP1/2/3/4 (but this game does not have special chips, iirc)

EDIT: ok, Reserved memory should fall back to open bus (as in bsnes and as explained at http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=52896#Post52896 ). it does not fix Accelebrid, but it should be an improvement to accuracy. hence, I'm going to commit this change soon

EDIT2: added to svn


Probably the open bus function gets faulty here ... I'm aware it's not 100% correct, but as usual it's a *cough* MAME core design quirk ...

fwiw, writing something like:
if(offset == 0x60d5) value = 0x60;
there "fixes" the problem.
Posted By: Kale Re: The SNES WIP topic - 03/30/10 06:03 PM
Ok, I'm going thru topic hunting here for looking old and new issues ... first off Super Bases Loaded 3 / Super Moero Pro Yakyu now gives this clever message after the Jaleco logo:



I wonder what broke this ...
Posted By: R. Belmont Re: The SNES WIP topic - 03/30/10 06:22 PM
Copy protection is usually limited to checking that the save RAM size is correct and mirrors properly. Given the hardware there's not much else you *can* check.
Posted By: etabeta78 Re: The SNES WIP topic - 03/30/10 07:19 PM
it got broken by some open_bus change, I guess. I tested the game two days ago and it was working (still with the window mask bug present).

now I'm going to see a movie. I'll look for the fix it as soon as I'm back, if Kale does not find it before then smile

as a temporary workaround, it's enough to replace some "return open_bus_read" I added this morning in snes_bankN_r (N=1,...,7) with "return 0xff". it seems at least one of them was wrong...
Posted By: Kale Re: The SNES WIP topic - 03/30/10 09:35 PM
Super Tetris 3 does the copy protection too:



(this screen looks neat anyway ^^U)
Posted By: R. Belmont Re: The SNES WIP topic - 03/30/10 09:38 PM
That makes sense, byuu mentioned some copiers would "eat" the open bus value. And that is a cool looking screen smile
Posted By: etabeta78 Re: The SNES WIP topic - 03/30/10 10:37 PM
Super Metroid has some famous anti-copier disclaimer as well (I triggered it once, while playing with SRAM mapping, almost 2 years ago)

However, it turned out to be a SRAM problem: I had changed the way SRAM is counted at start (in snescart.c), but I forgot to updated bank handlers accordingly, so those games ended up with 1024 times more SRAM than they should have... fixed now.

let me know if there is any other game which fails protection checks
Posted By: Kale Re: The SNES WIP topic - 03/30/10 10:59 PM
I'll let you know a lot of old/new issues *if* you give me the time, I'm just working on that.

EDIT: this?



;D

EDIT2: there was another (J) game with copy protection check ... that I've forgot the name ... I'll tell you shortly when I get to that part on the topic.
Posted By: etabeta78 Re: The SNES WIP topic - 03/30/10 11:05 PM
cool. now that I fixed this problem and I moved PPU registers to ppu code [1], I don't plan to change that much the code, so is all yours.

eventually, I will finish the conversion to a video device, but not immediately...


[1] where they should have been since the beginning: they only influence PPU variables and they even use different open bus sources than the main CPU...


EDIT: Super Metroid is fine with rev.7669 :P
and I recalled a nicer protection warning, but my memory could be at fault...


EDIT2: thanks for testing. good night smile
Posted By: Kale Re: The SNES WIP topic - 03/30/10 11:21 PM
Ah, you fixed Fushigi no Dungeon 2 ranking screen, I really appreciate that ^^U



EDIT: the game is Deae Tonosama Appare Ichiban (J), and it looks fixed. Oddly, my current compile has non-working inputs ... I'll recompile and let you know.

EDIT2: it's just the screwed compile.
Posted By: Kale Re: The SNES WIP topic - 03/31/10 12:09 AM
Here's the new & improved bug list, if there's anything not listed there, just let us know on this topic, thanks in advance:

*3x3 Eyes - Seima Korin Den (J): jumps at 8128, shouldn't according to bsnes;

*Accelebrid: hangs soon after the two drones exits from the screen, due of a flaw in its code it jumps to 8260d2 that is reserved address. It probably needs open bus DIRECTLY supported by the CPU core.

*Aging Cassette: errors on EXT LATCH, OBJ L OVER and APU (55)

*Bishoujo Janshi SuchiePai: mode 5 girls are still offsetted to the left (iirc even more than before?)

*Bishoujo Wrestler Retsuden: Exhibition wrestler select screen has a one-line bug with some elements

*Clay Fighter: sound part is bugged;

*Daffy Duck: The Marvin Missions: scroll flicker that isn't caused by timings, heretical_one says hirq?

*Desert Fighter (J): timing issue, the "mission no.1" screen displays after too much time.

*Energy Breaker: World Map is entirely missing (untested, needs somebody capable of playing this);

*F-1 Grand Prix Part 3 / Desert Fighter (J): heavy flicker during (ironically) the briefing for both games, probably abuses the gfx mode changes and the window / blending capabilities (at least mode 7 + something else)
\- Super Offroad the Baja: flickers during gameplay, switches between modes 1 & 7, related to the F-1 GP Part 3 issue of above

*Full Throttle Racing: glitch with the USA map, it displays cutted in half.

*Moryo Senki Madara 2: gap in the text? vshift bug maybe? (H)DMA?

*Puzzle Bobble / Bust-A-Move: Sprites goes offset after some time in challenge mode.

*SNES Test Program: fails "Electronic Test" / one item in Character Test is wrongly displayed (OPT Mode)

*Strike Gunner there's a "bug when the first boss flies past you" (untested)

*Super Drift Out: SRAM doesn't initialize properly, all times are 0'00"00

*Super Mario World: stage 1 boss background is (still) broken, uses mode 7;

*Super Moero Pro Yakyu: a bug with windows causes corrupted tiles during gameplay. At the time I'm writing, it also fails on a copy protection check.

*Super Soccer / BlazeOn: Screen is dimmed on the team selection screen / Atlus logo, could be a timing issue, but it probably isn't.

*Super Tetris 2 & Bombliss Limited (J): keeps showing the BPS logo, fails copy protection check?

*Super Tetris 3: fails copy protection check

*Super Tramp Collection (J): crashes for some reason (open bus?)

*Tokimeki Memorial: Missing text during gameplay?

*Toy Story: After beating the first boss, the stars that falls from the enemy aren't shown (untested)

*Tiny Toon Adventures - Buster Busts Loose (U): At the end of the first level, you get a chance to play a mini-game selectable from a spinning wheel. This wheel still show correctly at times, but not all the time. I notice if I fast forward - it seems to show correctly all the time. (untested)

*Wordtris: Controls stops working as soon as the menu screen appears

*Yoshi's Island (J): doesn't start at all now?

The following games hangs or have issues here and there due of the clock timing issues:
Act Raiser (U) (hangs after selecting a stage)
Brain Lord (J) (POST)
Final Fight 2 (when the screen scrolls vertically, missing black masking)
Ghost Chaser Densei (gameplay gfxs)
Ikari no Yousai (J) (garbage after beating the first boss, known to happen on a SNES PAL with JP cartridge too)
Kishin Douji Zenki 3 - Tenchi Meidou (J) (possibly something else too?)
Kyoraku Sanyo Toyomaru Daiichi Maruhon Parlor Parlor! 2 (J)
Libble Rabble (inputs)
Major Title (J) / The Skins Game (inputs)
Pilotwings (gameplay gfxs are offset)
Rushing Beat (J) (POST)
Ring ni Kakero (POST)
Secret of Mana (sound is broken)
Soul Blazer (U) - (after pressing start / sound doesn't work)
Super Tetris 2 & Bombliss (inputs)
Super Valis IV (POST)
Syvalion (after the Toshiba logo, it also now have scrolling bugs on the stars screen?)
Tales of Phantasia (J) (after the initial kanji screen)
Top Gear 3000 (after the selection screen, it also looks very dirty after it)
Yakochu (J) (flashes Yakochu then dies)

Regressed gamelist (caused by wrong program code / open bus hookup, just tested a couple of these):
Angelique - Premium Box (J)
Dai Koukai Jidai 2 (J)
Elfaria 2 (J)
Hakunetsu Professional Baseball Ganba League '93 (J)
Houkago in Beppin Jyogakuen (J)
International Tennis Tour (U)
James Pond's Crazy Sports (E)
Kishin Douji Zenki - Rettou Raiden (J)
Legend (U)(718)
Natsume Championship Wrestling (U)
Neugier (J)
Onita Atsushi FMV (J)
Sengo Kuno Hasha - Tenka Fubu heno Michi (J)
Shin Momotarou Densetsu (J)
Sim Ant (U)(49046)
Sporting News Power Baseball (U)
Super James Pond (U)
Suzuka 8 Hours (J)
Tadaima Yusya Bosyutyu Okawari (J)
Troddlers (U)
Undercover Cops (J)

Currently crashes for unknown / other reasons:
Ace wo Nerae (J)
Battle Racers (J)
Battle Soccer - Field no Hasya (J)
Big Ichigeki 2 University (J)
Captain Commando (J) (wrong cart mode selected)
Dikuritsu Sensou (J)
F-1 Grand Prix 2 (J) (writes to ROM address?)
Ganbare Daiku no Gensan (J)
Hoshi no Kirby 3 (J)
Hoshi no Kirby Super Deluxe (J)
Iso Zuri Ritou Hen (J)
Itoi Shigesato's Bass Turi No.1 (J) (tests RAM area $3046)
Jikkyo Power Pro Wresling (J) (hangs soon after the "dedicated to the Wrestling fans" screen)
Jikkyou Oshaberi Parodius (J)
J-League Soccer Prime Goal 3 (J) (hangs after Namco logo)
Jumpin' Derby (J) (SA-1 game)
Kirby Superstar (U) (tests RAM area $3000)
Kirby's Dream Land 3 (U)
Live-A-Live (wrong cart mode selected)
Mario Paint (JU) (Main CPU crashes, timing?)
Ms. Pac-Man (U)
Odekake Lester Lelele no Le (J)
Pachio Kun Special 2 (J)
Planets Champ TG 3000 (J)
Power Rangers Zeo - Battle Racers (U) (tests RAM area $3000)
Res Arcana Diana Ray - Uranai no Meikyu (J)
Shaq Fu (character screen)
Shin Nihon Pro Wresling Kounin '95 Tokyo Dome Battle 7 (J) (executes bad code)
Smurfs 2, The (E)
Soul & Sword (J)
Sound Novel Tukool (J)
Super 3D Baseball (J) (sound CPU crashes)
Super Bases Loaded 2 (U) (sound CPU crashes)
Super Bomberman Panic Bomber World (POST, doesn't load a proper sound cpu program)
Super Cup Soccer (J)
Super Genjin (J)
Super Goal! (U)
Super Mario Kart (J) (timing?)
Super Sangokushi (J)
Takemiya Masaki 9dan no Igo Taisyou (J)
Posted By: Justin Re: The SNES WIP topic - 03/31/10 12:35 AM
This demo just shows junk for two of the screens ("Dutch Viper" before the spinning balls and "The End") as compared with bsnes.
Posted By: Kale Re: The SNES WIP topic - 03/31/10 12:47 AM
As of r7670, Fushigi no Dungeon 2 doesn't display the proper ranking screen again, is it due of the new fix or it worked by chance? --"
Posted By: algrun Re: The SNES WIP topic - 03/31/10 04:57 AM
*Strike Gunner there's a "bug when the first boss flies past you" (untested)

there was but fixed in yesterday bobz build

Energy Breaker: World Map is entirely missing (untested, needs somebody capable of playing this)

works for me in r7666, unless i'm looking at the wrong map
same in yesterday bobz build but yet again i could be lookin at the wrong map

*Moryo Senki Madara 2: gap in the text?

yup there is a gap in the text in r7666 doesn't happen in bsnes
ther's still the gap in yesterday bobz build

Super Tramp Collection (J): crashes for some reason (open bus?)

black screen in r7666
also black screen in yesterday bob build
i didn't get a crash

Tokimeki Memorial: Missing text during gameplay?

on menus and name selection and stuff (i guess) the text is missing and when the game really starts most of the graphics are missing in r7666
same for menus but when the game starts the graphics missing before are shown and those shown before are missing and a line in the middle of the screen that shoudn't be there in yesterday bobz build

*Toy Story: After beating the first boss, the stars that falls from the enemy aren't shown (untested)

it doesn't show any stars at all in r7666
same in yesterday bobz build
Posted By: etabeta78 Re: The SNES WIP topic - 03/31/10 06:28 AM
@Kale: you can add that Rudra no Hihou has problem when the text windows appear and that R-Type 3 graphics get garbled in the second intro loop

OTOH Captain Commando (J) works now, I tried it yesterday. Yoshi's Island works as well in 7670 (even if with huge graphics issues) but you have to use snessfx because it's a Super FX game.

A couple of question tough:

*SNES Test Program: fails "Electronic Test" / one item in Character Test is wrongly displayed (OPT Mode)

which one? It seems the same as bsnes to me...

and how can I reach that Fushigi no Dungeon 2 score table?

@algrun: where did Tokimeki changed compared to past revisions? it works exactly the same as it did for me (svn 7670), and it keeps freezing as soon as I select anything in game (as it has always done)


I'm going to slowly test other issues today. I expect all the protection screens not to appear anymore...


EDIT: overall, I think timing issues (and possibly a bunch of bugs in the CPU opcodes?) might very well lead SNES to enable/disable in the wrong way layers and window masks and hoffs//voffs, producing some of the issues reported. also, we currently don't stop DMA if an HDMA starts in the same channel (which can break things, in principle) and this requires better timing as well to be implemented.

otoh, graphic effects and priorities seem pretty well emulated at this stage (you can compare our implementation of some effects with the snaps posted at http://board.zsnes.com/phpBB2/viewtopic.php?p=201064#201064 and you will see that our code is quite good), and it would be nice to rule out timing in the bugs above to see which problems still exist in the video code.
Posted By: etabeta78 Re: The SNES WIP topic - 03/31/10 08:50 AM
Kale, but did you simply copy and pasted the old list from August?!? tons of what you listed has been fixed for months...

e.g. Elfaria 2, SimAnt, Kishin Douji Zenki - Rettou Raiden, Super James Pond, Super Mario Kart, all the DSP1 games, and probably many more

you could have said you haven't tested any more the games in these lists...

plus, your list contains titles like Kirby Super Star which cannot work because SA-1 add-on CPU is not emulated.

I guess I'll have to rewrite the whole list later today wink
Posted By: Shoegazer Re: The SNES WIP topic - 03/31/10 01:13 PM
Don't forget to add Super Punch-Out to the list. There are issues displaying the KO countdown timer as per my previous post.
Posted By: etabeta78 Re: The SNES WIP topic - 03/31/10 01:26 PM
You can find a proper bug-list updated to rev. 7670 at this link

http://mess.redump.net/sysinfo:snes:bugs

This should make possible updating the page when new bugs are found or old bugs are fixed. In particular, Tafoid is running a whole testsuit and this will help to identify all the games which freezes completely MESS

Notice that I removed games previously listed as broken and which now actually work, but they might well have graphics bugs or other issues worth reporting, so keep testing wink
Thanks to algrun for testing some of the issues posted by Kale.

Finally, I separated the games not working due to unemulated chips from the ones due to buggy emulation: the former are expected not to work, the latter might get fixed

There are a few issues which I was unable to trigger/reproduce
* Act Raiser (U) (hangs after selecting a stage)
* Bishoujo Wrestler Retsuden: Exhibition wrestler select screen has a one-line bug with some elements (which elements?)
* Final Fight 2 (when the screen scrolls vertically, missing black masking)
* Fushigi no Dungeon 2: the score table has incorrect graphics (when it is displayed?)
* Ikari no Yousai (J) (garbage after beating the first boss, known to happen on a SNES PAL with JP cartridge too)
* Super Mario World: stage 1 boss background is (still) broken, uses mode 7 (this had been reported as fixed at MW... could anyone provide a .inp? it's painful to play this until the boss with an eeepc barely able to go at 60% and the keyboard);
* Puzzle Bobble / Bust-A-Move: Sprites goes offset after some time in challenge mode (sprite seems fine... it's only bubbles which sometimes move, as I reported in the linked page, or is there anything else wrong with this?)
* Tiny Toon Adventures - Buster Busts Loose (U): At the end of the first level, you get a chance to play a mini-game selectable from a spinning wheel. This wheel still show correctly at times, but not all the time. I notice if I fast forward - it seems to show correctly all the time.

could anyone help me e.g. by posting a .inp file or at least a snap with the problem? thanks
Posted By: zillion Re: The SNES WIP topic - 03/31/10 02:54 PM
I was playing Star Fox (U) last night with the latest svn build at Bobz. In the Asteroid level where you go inside some ships and destroy their core, when you exited the ships the space background was red and garbled instead of black space with stars.

Everything else looked great!
Posted By: algrun Re: The SNES WIP topic - 03/31/10 03:46 PM
Originally Posted By etabeta78

@algrun: where did Tokimeki changed compared to past revisions? it works exactly the same as it did for me (svn 7670), and it keeps freezing as soon as I select anything in game (as it has always done)


i got it now i was using v1.1 of the game wich plays as i said v1.0 freezes,it's not really like it freeze, you get an image of a girl and then some dots appear over the image, if you press the arrow buttons you can move the image as some puzzle,but definitely its not what it should be showing

Edit: i'll try to give some .inp files too for some of the games you posted

@Tafoid thanks for letting me know
Posted By: Tafoid Re: The SNES WIP topic - 03/31/10 04:31 PM
Just a FYI, I sent ETA this .INP already:

* Tiny Toon Adventures - Buster Busts Loose (U): At the end of the first level, you get a chance to play a mini-game selectable from a spinning wheel. This wheel still show correctly at times, but not all the time. I notice if I fast forward - it seems to show correctly all the time.
Posted By: byuu Re: The SNES WIP topic - 03/31/10 05:45 PM
Gentlemen, behold!

Code:
8281c8 lda #$07               A:c141 X:000c Y:0020 S:01d1 D:0000 DB:82 nvMxdIzC V:166 H: 490
8281ca sta $2100     [822100] A:c107 X:000c Y:0020 S:01d1 D:0000 DB:82 nvMxdIzC V:166 H: 502
8281cd lda #$0f               A:c107 X:000c Y:0020 S:01d1 D:0000 DB:82 nvMxdIzC V:166 H: 526
8281cf sta $2100     [822100] A:c10f X:000c Y:0020 S:01d1 D:0000 DB:82 nvMxdIzC V:166 H: 578


A.S.P. Air Strike Patrol.

The game uses mid-scanline writes to the display brightness register to simulate a shadow for your plane. Only way to emulate this is with a full, true cycle-based S-PPU1+2 emulator.

Any takers?
Posted By: Haze Re: The SNES WIP topic - 03/31/10 06:01 PM
that's awesome ;-) nothing new to people who have done c64 / speccy emulation I guess.. but it's really pushing things on a console.
Posted By: R. Belmont Re: The SNES WIP topic - 03/31/10 06:11 PM
There were a couple of NES games that were notorious for mid-scanline PPU twiddling (pretty much anything by Codemasters) but until now it was unknown on SNES. Nice work, byuu.
Posted By: byuu Re: The SNES WIP topic - 03/31/10 06:15 PM
Thanks, FitzRoy spotted it in-game. The most insidious part is that an emulator would never even know about it. They wouldn't see the shadow line and would think the game was perfect. Hence why I mentioned it here smile

This game just so happened to hit right between the exact point where I render the scanline, so my entire scanline ended up darkened, making it stand out big-time.

You guys probably also know about Uniracers, but if not ... that one writes to OAM during Hblank in 2-player mode. The S-PPU is controlling the OAM address at this time, and the last fetched sprite data is where the write ends up going. But that one's a lot easier to deal with since it writes during Hblank where the position is stable.
Posted By: Kale Re: The SNES WIP topic - 03/31/10 06:16 PM
Originally Posted By etabeta78
Kale, but did you simply copy and pasted the old list from August?!? tons of what you listed has been fixed for months...

e.g. Elfaria 2, SimAnt, Kishin Douji Zenki - Rettou Raiden, Super James Pond, Super Mario Kart, all the DSP1 games, and probably many more

you could have said you haven't tested any more the games in these lists...


Uhm:

Elfaria 2 (J) doesn't work
SimAnt works
Kishin Douji Zenki - Rettou Raiden doesn't work
Super James Pond works
Super Mario Kart (J) doesn't work

... I had a list and tested a bunch of them (and yes, they weren't working on my machine at the time of the revision). If they works now, ok, fine, but by working I don't mean "black screen" :P

#Ghost Chaser Densei - gfxs glitches during gameplay (e.g. below the status bar) <- again, timing bug
#Puzzle Bobble / Bust-A-Move: Sprites goes offset after some time in challenge mode (sprite seems fine… it's only bubbles which sometimes move, as I reported above, or is there anything else wrong with this?) <- left-over, you can remove this.

(will follow inps for some of the issues)
Posted By: judge Re: The SNES WIP topic - 03/31/10 06:16 PM
great, reminds me of gameboy...
Posted By: Kale Re: The SNES WIP topic - 03/31/10 06:56 PM
#Act Raiser (U) - crashes now *randomly* and can't get an inp to reproduce it (i.e. tried 5 times, 3 with inp and 2 without, crashes ONLY when I didn't recorded it, shrug), sound doesn't work anyway due of the timing crap.
#Bishoujo Wrestler Retsuden (J)
MESS

vs. BSNES

#Final Fight 2
http://mamedev.emulab.it/kale/fast/files/final_fight_2.zip
Pretty obvious, timing issue
#Fushigi no Dungeon 2 - Furai no Shiren
http://mamedev.emulab.it/kale/fast/files/shiren.zip
(delete nvram)
The "ranking screen" is that "wood board" that I check as the first thing I do in the inp (yeah, it isn't supposed to fart ;D) ... then I play "randomly" for one floor
and commit suicide, the ranking screen then is clearly garbage (the same play nets something like ... hmm, 50 points in a working game?)

#Ikari No Yousai
http://mamedev.emulab.it/kale/fast/files/ikari.zip
Maybe you can fix the sprites there, the garbage is caused by timing issues ... this *doesn't* happen on the US version Operation Logic Bomb, mainly because the latter has many bugfixes than the original Japanese release.
#Super Mario World
(delete nvram)
http://mamedev.emulab.it/kale/fast/files/super_mario_world.zip
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 12:19 AM
Elfaria 2 and the other ones you mentioned (even Japanese Super Mario Kart), all reached around 45 seconds ingame with no issues. given that on my eeepc this means around 5 minutes with my finger on the FFW key, I think I tested enough to remove a generic "do not work" report.
If more specific issues are reported, I can re-check them. Don't underestimate the time I spent on testing the games you listed: I never stopped to the title screen. wink

about me sucking at games, it's pretty much true when we talk about 8-16bit games, except for puzzle, platform and sport games (and I'm good at these only with a joypad, which I miss atm). that's why I appreciate if other people can help me with tests...

Finally, I cannot really imagine what is wrong with those broken sprites: tile and sprite code is pretty clean and it seems to follow bsnes one quite close (except for a bunch of possible missing masks, which I plan to implement soon)... I guess I'll have to debug a bit more the games, but I would point my finger towards the SNES reading/writing to OAM/VRAM at the wrong time...
Posted By: Kale Re: The SNES WIP topic - 04/01/10 01:30 AM
I swear and repeat, they doesn't work here, probably it's some (init) corruption bug that happens on machine-specific stuff?

About you sucking at games ... I was just joking. ;P
Posted By: jbo_85 Re: The SNES WIP topic - 04/01/10 01:47 AM
The OBJ L OVER test works if you don't fast forward. It's because the RTO flag calculation is skipped if you fast forward.
Posted By: byuu Re: The SNES WIP topic - 04/01/10 02:53 AM
Hahahah. Same reason I ended up disabling frame skipping entirely. The overhead of computing RTO ended up erasing more than half of the benefit of even having fast forward.

Going to try and get some TV pics of ASP, and then I'll look over your known bugs list to see if I remember any.
Posted By: byuu Re: The SNES WIP topic - 04/01/10 03:39 AM
Here comes the game of madness, bearing gifts of death and torture!





http://byuusan.kuro-hitsuji.net/airstrikepatrol/MOV00737.MPG

The best part of all: that shadow is a key component of the game. It tells you where your bombs are going to land. By not showing up in emulators, it makes the game substantially more difficult.
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 09:44 AM
Originally Posted By Kale
I swear and repeat, they doesn't work here, probably it's some (init) corruption bug that happens on machine-specific stuff?


try with a clean build. I tried to recompile everything and Super Mario Kart (Japan) is still perfectly playable...

can anyone else reproduce problems in SMK (J)?

Originally Posted By Kale
About you sucking at games ... I was just joking. ;P


I can still read smilies, so I knew that you were joking. but it's true that I suck on many games. with PSX-era games I got better in more game genres, but I still suck in some wink
Posted By: Kale Re: The SNES WIP topic - 04/01/10 12:11 PM
Originally Posted By jbo_85
The OBJ L OVER test works if you don't fast forward. It's because the RTO flag calculation is skipped if you fast forward.


I presume that's done INSIDE the VIDEO_UPDATE then, even though I've said to death to not do it here --"

I'd like to quote video/dc.c, because it's basically the same thing for this case:

Quote:

/******************
MAME note
*******************

The video update function should NOT be generating interrupts, setting timers or doing _anything_ the game might be able to detect
as it will be called at different times depending on frameskip etc.



Originally Posted By byuu
Here comes the game of madness, bearing gifts of death and torture!


fwiw ASP - Air Strike Patrol is the US name of Desert Fighter (J) ... one of the most famous games ... of this topic at least ;D They have done everything on that game ... interlacing, mixed modes 1-7, this new issue ... shrug ...

Originally Posted By etabeta78

try with a clean build. I tried to recompile everything and Super Mario Kart (Japan) is still perfectly playable...

can anyone else reproduce problems in SMK (J)?


Tried many times ... probably you have something like OPTIMIZE=0 in makefile or dunno, it gives black screen specifically on my end for whatever reason ...
It remembers me a similar bug on Prikura Daisakusen for the ST-V back in the day ... I was getting correct graphics but Haze was getting just garbage ... turned out that I wasn't returning proper values on a DMA status bit ...

Originally Posted By etabeta78
I can still read smilies, so I knew that you were joking. but it's true that I suck on many games. with PSX-era games I got better in more game genres, but I still suck in some wink


Practice makes perfect, that's the secret of VGs ... I suck at puzzle games and 1vs1 2d beat'em ups, but mainly because I don't play these at all.
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 12:34 PM
Originally Posted By Kale
Originally Posted By jbo_85
The OBJ L OVER test works if you don't fast forward. It's because the RTO flag calculation is skipped if you fast forward.


I presume that's done INSIDE the VIDEO_UPDATE then, even though I've said to death to not do it here --"



do you refer to setting the flag or to clearing it or both? iirc, the clearing part is already outside video update (it's inside a timer that get set either by the scanline or the hblank timer); the setting part is done in snes_update_objects_rto which gets called before scanline drawing and that can be moved outside video_update if necessary. if the latter, can you suggest a smarter place to move snes_update_objects_rto at?


Originally Posted By Kale
Tried many times ... probably you have something like OPTIMIZE=0 in makefile or dunno


no I don't. base makefile compiled on Win32 with

make TARGET=mess MESSUI=0

however, I also tried a SYMBOLS=1 build (which sets OPTIMIZE=0) and it works as well.

what's the image crc? I'm testing the nointro dump:

crc C8002453
md5 F7AFA112D7EC1D532636703E4B02700A
sha1 CBB853BF911255C1D8EB27CD34FC7855A0DDA218
Posted By: Kale Re: The SNES WIP topic - 04/01/10 01:06 PM
Originally Posted By etabeta78


do you refer to setting the flag or to clearing it or both? iirc, the clearing part is already outside video update (it's inside a timer that get set either by the scanline or the hblank timer); the setting part is done in snes_update_objects_rto which gets called before scanline drawing and that can be moved outside video_update if necessary. if the latter, can you suggest a smarter place to move snes_update_objects_rto at?


The only valid place is inside the read/write handler itself.


Quote:

no I don't. base makefile compiled on Win32 with

make TARGET=mess MESSUI=0

however, I also tried a SYMBOLS=1 build (which sets OPTIMIZE=0) and it works as well.

what's the image crc? I'm testing the nointro dump:

crc C8002453
md5 F7AFA112D7EC1D532636703E4B02700A
sha1 CBB853BF911255C1D8EB27CD34FC7855A0DDA218


crc 67D8A078 ... shrug, bad dump, just realized that it doesn't work in bsnes either ^^U
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 01:15 PM
Originally Posted By Kale
Originally Posted By etabeta78


do you refer to setting the flag or to clearing it or both? iirc, the clearing part is already outside video update (it's inside a timer that get set either by the scanline or the hblank timer); the setting part is done in snes_update_objects_rto which gets called before scanline drawing and that can be moved outside video_update if necessary. if the latter, can you suggest a smarter place to move snes_update_objects_rto at?


The only valid place is inside the read/write handler itself.


which handlers? the current emulation works as follows:

at the end of each scanline we update the OAM parameters that should be used for the next line; then we pass through OAM RAM, checking which sprites will be drawn in the scanline (and setting the flags if there are too many sprites); finally we draw the scanline (both BG layers and sprites). notice that RTO flags are not reset until next frame (and indeed the flag reset happens in a timer which is called at the beginning of the frame).

how do you suggest to re-implement it without breaking sprite limits?


Posted By: Kale Re: The SNES WIP topic - 04/01/10 01:41 PM
RTO is a SNES register flag, right?

So move/calc the OAM params in that specific register and change the value accordingly.
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 02:32 PM
could you take a look at snes_update_objects_rto? I cannot see exactly your idea would fit the SNES behavior (which is not something I made up, it's the way byuu describes and implement it, and he ran *a lot* of test on the hw about this flag): the flag can be updated at each scanline, not only when the register is accessed by the snes_io handler. also, notice that snes_oam is going to be a PPU thing only.
maybe we could add an handler which writes back to the register from the PPU, but would the handler be called at the right moment by the video_update?
Posted By: Haze Re: The SNES WIP topic - 04/01/10 03:00 PM
Originally Posted By etabeta78
could you take a look at snes_update_objects_rto? I cannot see exactly your idea would fit the SNES behavior (which is not something I made up, it's the way byuu describes and implement it, and he ran *a lot* of test on the hw about this flag): the flag can be updated at each scanline, not only when the register is accessed by the snes_io handler. also, notice that snes_oam is going to be a PPU thing only.
maybe we could add an handler which writes back to the register from the PPU, but would the handler be called at the right moment by the video_update?


Well the entire reason I don't use Video Update for anything in Genesis apart from copying a bitmap is so that the sprite collisions flag etc. works as expected. (I'm aware that it makes merging it with S18 harder, but that's tough)

My scanlines are rendered with timers, and to be honest, if you're going to do the brightness trick for that shadow which byuu points out then your only option is going to be using your own timers. Video Update has no concept of partial-scanline updates, and your code would need to at the very least be able to render a partial scanline up to the point where the brightness gets changed. (calculating the time since scanline started based on the timer, thus knowing the point at which the cpu changed the data)

If you've done C64 I'm surprised you don't know this tho? Afaik C64 makes extensive use of mid-scanline updates for some of the demos, which MAME can't handle with partial updates.

Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 04:44 PM
in fact, robiza has done all the video work on c64. I mainly cared about carts and tapes and memory banks (and to some extent floppies, until Curt came and made it better and faster)

and I know that flags can have problem with video updates, but I'm not so sure I can handle a complete rewrite by using timers at the moment, while I was more than capable to improve the original code until reaching the current level of accuracy (which is not bad, all considered)

now that the problem has surfaced, I added to my todo list the investigation of a timer-based rendering rewrite, but it won't happen anytime soon (especially because the current code is good as long as you don't frameskip, and it works pretty well even when you skip frames if the game is not too strict)
snes is definitely more in need of CPU timing fixes than this RTO flags problem...
Posted By: Duke Re: The SNES WIP topic - 04/01/10 05:33 PM
If you want to see a simple video system that renders partial scanlines via timers see the sam coupe driver (just to give you some pointers).
Posted By: Haze Re: The SNES WIP topic - 04/01/10 07:39 PM
Originally Posted By etabeta78
in fact, robiza has done all the video work on c64. I mainly cared about carts and tapes and memory banks (and to some extent floppies, until Curt came and made it better and faster)

and I know that flags can have problem with video updates, but I'm not so sure I can handle a complete rewrite by using timers at the moment, while I was more than capable to improve the original code until reaching the current level of accuracy (which is not bad, all considered)

now that the problem has surfaced, I added to my todo list the investigation of a timer-based rendering rewrite, but it won't happen anytime soon (especially because the current code is good as long as you don't frameskip, and it works pretty well even when you skip frames if the game is not too strict)
snes is definitely more in need of CPU timing fixes than this RTO flags problem...


MAME does have a flag which causes no frameskipping to be allowed in the drivers, but I found it to be unreliable (I can't remember exactly what the issue was, might have had something to do with the debugger, or partial updates)

As a temporary fix you might be able to use that, but it won't give you the long-term flexibility you need.
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 07:58 PM
my plan is: convert the ppu to be a device, see if I can fix any issue in games which don't start, and then take a break from this driver (waiting for cool things to happen on the CPU and timing side).

once RTO issues will be relevant in the currently huge buglist, I will put the video rewrite on top of my todo list.
with current svn, we now almost compare line-per-line code and output of MESS vs. bsnes and I already see this as a quantum leap compared to the 0.136 source code (not to mention the number of bugs that have been solved and the missing effects that have been added in the meanwhile)
Posted By: Lord Nightmare Re: The SNES WIP topic - 04/01/10 08:31 PM
etabeta78: you were working on the NES ppu stuff as well, right? Is there any chance you can get rid of the lookup tables in src/mame/machine/vsnes.c and just require for all vsnes games, a rom which contains the 9-bits-per-color color lookup for said game?
The lookup tables remap the 'scrambled' vs nes ppu roms back into the closest available colors in the normal ntsc-generated color spectrum, which is completely and utterly wrong to hardware.

Proposed function would be vsnes_get_color which takes the color index, the ppu type, and the color de-emphasis bits and monochrome bit for input, and returns an RGB color.

LN
Posted By: etabeta78 Re: The SNES WIP topic - 04/01/10 08:34 PM
yeah, I plan to work a bit more on NES as well, but let's remain in topic and discuss NES problems in the NES topic, when I'll be back to that driver...
Posted By: AWJ Re: The SNES WIP topic - 04/02/10 05:58 AM
Would anyone kick up a fuss if I just embedded the RGB PPU palettes in the source? It's not like it's possible to conventionally "dump" the internal PROMs, and AFAIK we don't even know how (bit order-wise) the data is stored inside the PPUs.
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 06:14 AM
Yes, they would. It's dead frakking easy to access loaded ROM data in this era of named regions, and size doesn't matter (the palettes are unlikely to be smaller than the SPC700 IPL ROM, for instance).
Posted By: AWJ Re: The SNES WIP topic - 04/02/10 06:31 AM
That's not the objection I have, it's that we don't have any idea how the bits are arranged inside the PPU (unless someone's decapped one at some point?) Even the fact that there are 9 bits per color is no more than logical induction based on the range of colors seen in the five PPU types that have distinct RGB palettes.

Treating the PPU palettes as ROMs doesn't make any more sense to me than trying to turn, I dunno, the YM2143 fixed instrument parameters (or any of the other lookup tables used by the YM sound devices) into a ROM.
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 11:48 AM
I don't understand what not knowing the final format has to do with how the data should be stored. If we ever find out for sure, change the files and the checksums. Big deal. And the YM2143 samples will eventually be converted to external load - it's on my todo list, albeit at a fairly low priority.
Posted By: Haze Re: The SNES WIP topic - 04/02/10 12:25 PM
I actually agree with AWJ here. There is no indication of what the real format is at all.. The palettes have been reverse engineered, not 'dumped' Putting them in a ROM file just seems misleading.
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 12:46 PM
We put stuff in ROM files on a fairly regular basis that isn't actually ROMs - the original Naomi keys, for instance. And then when we find out the real format, we replace the files.
Posted By: Kale Re: The SNES WIP topic - 04/02/10 01:54 PM
fwiw Pachio-Kun Special (J) hangs soon after selecting the data to load / new game.
Another game to put into the timing crap.

EDIT:
#Shin Nihon Pro Wresling Kounin '95 Tokyo Dome Battle 7 (J) (executes bad code)
#Super Trump Collection (J)
<- another two games to put into the timing hell
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 02:06 PM
I'm not sure the timing is as much of a problem as you guys are hoping. ZSNES doesn't even count cycles when executing the CPUs and it runs most if not all of those games cited. (It may be that eta's various attempts to enforce timing when we don't have any is ultimately harmful though).
Posted By: Kale Re: The SNES WIP topic - 04/02/10 02:11 PM
According to some SNES devs on which I've talked in the past, the ZSNES has so many hacks and I wouldn't trust it at all due of that ...

And, btw, when I say "timing" I just list games that I wouldn't like to check as first ones, because the timing thing is almost surely the reason about why they don't work.

Nobody loves to lose time, in short smile
Posted By: etabeta78 Re: The SNES WIP topic - 04/02/10 02:40 PM
Originally Posted By R. Belmont
(It may be that eta's various attempts to enforce timing when we don't have any is ultimately harmful though).


I don't follow you... which attempts are you referring to?
I have done no timing work at all until now.
I have only fixed drawing routines (because we were lacking many video effects), enabled HDMA in both directions and improved HDMA init and update procedures, and moved constants to a struct... none of these modified the SNES timing, which is still the same as last September...

EDIT: also, given the number of games which improves when you change cpu/apu clocks, maybe the timing is not the final solution to all the reported problems, but it can have a notice-able impact
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 02:41 PM
I mean things like enforcing no VRAM writes during active display. It's probably mostly harmless, but without proper timing that could certainly break correctly functioning games.

Also, be warned: bsnes's CPU is heavily integrated with (H)DMA and other stuff that's on-die with the S-CPU. (What's the Ricoh number again?) That's how it should be from a design standpoint (and especially for getting all the timing corner cases right), but it makes it more difficult to integrate with MAME/MESS where all the peripherals are in machine/snes.c, and it also means it's unusable for other 65816 systems (Apple IIgs, C64 with SuperCPU expansion).
Posted By: etabeta78 Re: The SNES WIP topic - 04/02/10 02:50 PM
well, I have seen no regressions in any game I tested (and I think it's because the code checks the real hpos/vpos rather than the latched ones): the games which are currently broken were broken in 0.135-0.136-0.137 as well

those handlers can be made optional though, by always entering in the disabled display case (which directly reads/writes vram/oam/cgram), if any bad side-effect surfaces
Posted By: Kale Re: The SNES WIP topic - 04/02/10 03:05 PM
Discovered why 3×3 Eyes - Seima Korin Den doesn't work.
Basically, 0x8128 is the IRQ vector, hence it fires the IRQ but it mustn't. If you comment out line 126, game boots and works fine ...
Stay tuned for a reason about why it fires that.

EDIT: Now it's official, MAME irq system sucks ass, because 3x3 Eyes does something VERY demented / twisted (take your pick). It has the NMITIMEN enabled all the time (0xa1), then it DISABLES the register (by writing 0x00) and executes a CLI opcode. Spurious IRQs happens due of that, because MAME, for whatever reason, remember that the irqs are called when in STI-mode.

Fun.
Posted By: Kale Re: The SNES WIP topic - 04/02/10 04:33 PM
Meanwhile (did some tests to check if I was right about this, I am so going to submit it):



My heart cries for this cry
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 04:38 PM
Eh? Most processors really do "remember" IRQs raised while the status register has them disabled and trigger them when you CLI or equivalent.

Why are the IRQs firing in the first place?
Posted By: Haze Re: The SNES WIP topic - 04/02/10 04:46 PM
Originally Posted By R. Belmont
We put stuff in ROM files on a fairly regular basis that isn't actually ROMs - the original Naomi keys, for instance. And then when we find out the real format, we replace the files.


In those cases we had something pretty solid at least, a key, and some strings we knew were returned. In the case of the palette it's just made up data isn't it?
Posted By: Kale Re: The SNES WIP topic - 04/02/10 04:49 PM
Due of the IRQ scanline triggering. Line 128 is that. My guess is that g65816 DOESN'T actually remember the IRQ firing, because I don't see any other solution to that. NMITIMEN bit 5 is enabled during STI, then the game clears it and clears the CLI too.

Oh, BSNES doesn't trigger that breakpoint at all, so I suppose that it behaves like I'm just saying.

I'm considering a MAME bug because you don't have any control over that, processors cores always acts as they remember the IRQ line raised, and the result is: a similar issue happens to Night Gal & friends system, I call a blitter write then irq the ncs and expect it to call just one irq ... no, MAME calls something like +1 irq for every time a blitter is executed, hence you have garbage for that game.
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 04:52 PM
So the game sets an HIRQ it doesn't want to ever get? That's perverse.

ETA: Clearing NMITIMEN is supposed to disable/ack the interrupt? In that case it should lower it in g65816 and then there's no problem when it hits CLI.
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 04:59 PM
Regarding the NES palette, my understanding is it was measured from the R/G/B output levels of various model PPUs running a test program. So it would at least have some hope of being correct. If that's not the case, then yeah it's just crap and putting it in MAME at all is probably of questionable value.
Posted By: Kale Re: The SNES WIP topic - 04/02/10 05:02 PM
Originally Posted By R. Belmont

ETA: Clearing NMITIMEN is supposed to disable/ack the interrupt? In that case it should lower it in g65816 and then there's no problem when it hits CLI.


Good point, I'll try it when it recompiles.
Posted By: Kale Re: The SNES WIP topic - 04/02/10 05:53 PM
r7679 /src/mame/machine/snes.c: [SNES]: Clear pending IRQ if the IRQ enable flag is disabled, fixes 3x3 Eyes - Seima Korin Den booting




Used the latter solution discussed with Arbee, since it's cleaner anyway.
Posted By: Tafoid Re: The SNES WIP topic - 04/02/10 06:32 PM
Tested games a bit yesterday - here are some findings:

Graphic Issues:
Ardy Lightfoot (cave roof graphics)
Blues Brothers (pre-title)
Bugs Bunny - Rabbit Rampage (beginning of first level)
Super F1 Circus (J) (title Screen)
Tom and Jerry (in-game - "Tom and Jerry The Movie" sign - there are supposed to be round knobs, but there are twin halfs showing instead)
Super Genjin 2 (J) - (menu text at title is black)
Secret of Evermore - (@ title screen, repeating graphics) .. (mode 7 after first battle - when ship is crashing)

Not Working (black screen/hang):
Rendering Ranger R2 (J)
Rival Turf
Rushing Beat (J) [!]
Posted By: Kale Re: The SNES WIP topic - 04/02/10 06:35 PM
Ho Ho Ho, spotted a g65816 core bug with F-1 Grand Prix Part 2:

C05940: LDA #$39
C05942: BMI c059a9 ($65)
C05944: ADC $858e65,X
C05948: STX $fea9
C0594B: SBC $950635,X
C0594F: ASL $8a
C05951: CLC
C05952: ADC #$40
C05954: BRK #$aa
00F04C: RTI




Do you need explainations? ;P
Posted By: AWJ Re: The SNES WIP topic - 04/02/10 06:45 PM
Looks like MESS is somehow reaching that code with the M flag in the wrong state.
Posted By: Kale Re: The SNES WIP topic - 04/02/10 06:51 PM
Yeah, stack RAM pointer is somehow fucked up in current emu ... I see that BSNES register stack is equal to 0xe10 ... but in MESS is 0x5555, and that's obviously fucked up ...
Posted By: R. Belmont Re: The SNES WIP topic - 04/02/10 07:04 PM
Yeah, that's a classic "M=short, code is supposed to run with it long" disassembly.
Posted By: byuu Re: The SNES WIP topic - 04/02/10 10:46 PM
Man, really sorry. I don't recall having bugs in any of the games you guys currently list as broken.

Quote:
Also, be warned: bsnes's CPU is heavily integrated with (H)DMA and other stuff that's on-die with the S-CPU.


Sort of. class CPUcore is just the raw 65816. I actually do need to add some tiny things for some special SA-1 edge cases, though.

Both class sCPU and class SA1 inherit the 65816 core, and then add their own extra hardware units.

Quote:
So the game sets an HIRQ it doesn't want to ever get? That's perverse.


You're going to love some of the stuff you find in the future.

Here's a fun one ... game has the following:
-; bit $4211; bpl - //wait for IRQ acknowledgement

IRQroutine:
lda $4211 //clear IRQ acknowledgement flag
rti

Yes, the games can break out of that loop, and many will lock up if they do not. The Snes9X team gave up on trying to support this with an opcode-based core.

There is a 6-cycle hold time for the interrupt lines. If you read them at just the right time within them, you can:
- cancel the pending interrupt, or
- read the acknowledgement bit as set twice in a row

Ah, and the fun cli stuff that shows the two-stage pipeline nature of the 65xx chips. Since IRQs are tested on the bus opcode edge, that is one stage ahead of the work cycle to clear cli. Thus an IRQ can still trigger immediately after a cli instruction has executed. But rep/sep and rti are different, because their I flag is cleared sooner within the cycle.

I believe F-1 Grand Prix and Sink or Swim do something sick like trigger HIRQs more than one time on the same line or something. You guys should play those for a bit and see how they respond in MESS.

Quote:
but in MESS is 0x5555, and that's obviously fucked up ...


Sounds like it's reading from uninitialized WRAM. 0x55 is such a fun pattern, multiple titles break without it, despite the fact that SNES WRAM is DRAM-based, and is thus completely unpredictable upon power-up, with serious variations across each run.

Quote:
And the YM2143 samples will eventually be converted to external load - it's on my todo list, albeit at a fairly low priority.


Be sure to externalize the S-DSP gaussian interpolation table, and the S-DSP counter lookup table, and the S-PPU light table while you're at it wink
Pro tip: $2100 INIDISP display brightness of zero isn't absolute black. If you max out your TV settings, you can still see the image. And thus, the ramp is not linear in nature, nor does it operate in the RGB colorspace.

Quote:
I'm not sure the timing is as much of a problem as you guys are hoping. ZSNES doesn't even count cycles when executing the CPUs and it runs most if not all of those games cited. (It may be that eta's various attempts to enforce timing when we don't have any is ultimately harmful though).


Indeed, I'm probably doing no good here.

There's lots of very edge-case games that require the most bizarre behavior you've ever seen. Like Speedy Gonzales and Wild Guns, for instance. But you guys are hitting some really simple things.

My discussion of these extreme edge cases is probably a mere distraction with the current state of things, and you'll probably just implement them incorrectly, possibly causing more bugs. The basics really need to be addressed first.

I guess what I'm hoping for in explaining the low-level stuff is that you guys will realize the futility of an opcode-based core, and move to cycle-based before you waste too much more time fixing up a dead end ...

By understanding the lowest level stuff now, you know exactly what your core will need to be able to handle, and can skip the 4-5 core rewrites I had to go through.

Also, one thing I will say, is that the VRAM write disable isn't hurting anything. Please don't even make that an option to bypass.

Regardless of whether or not it was ever their intention, the VRAM write issue has made ZSNES the IE6 of SNES emulators. It is the "extend" element of Microsoft's strategy. Why move to another emulator if it's going to break your (already broken) fan translations?

If your timing is really that awful, then adjust the range that you block writes. For instance, instead of blocking during V=0-224, change it to only block during V=8-216. Same effect, much more forgiving timing-wise.

We need every last emulator to counter this broken behavior and push for actual standards, so that we don't end up with more ZSNES-only software, perpetuating the negative feedback loop further.
Posted By: etabeta78 Re: The SNES WIP topic - 04/03/10 04:59 AM
Originally Posted By byuu
Man, really sorry. I don't recall having bugs in any of the games you guys currently list as broken.


don't worry. the only fact you wrote bsnes is a huge help. without it, we could only go back re-testing everything on the hardware; thanks to your help, we can currently simply fire up your emu and figure out what the expected behavior is.
Posted By: Kale Re: The SNES WIP topic - 04/03/10 01:45 PM
Found, it's an open bus crapness:

C0516A: LDA $004212
C0516E: BIT #$01
C05170: BEQ c05178 ($6)
<- it must jump here

It's weird though, in theory lda $4212 last open bus value should be 0x00, where it takes that needed 0x02?

Game works fine apart from this anyway:





EDIT:
Maybe ... LDA $4212 machine code is "0xaf 0x12 0x42 0x00"
So, the open bus for this specific opcode is either 0x42 / 0x12 and not 0x00?

EDIT2:
Actually, bit #$01 opcode indicates that is testing bit 0, not bit 1 like I've thought, yay for unclear dasm'ing ^^U
Posted By: Kale Re: The SNES WIP topic - 04/03/10 03:23 PM
And the winner is ...

r7683 /src/mame/ (machine/snes.c includes/snes.h): [SNES]: Moved the i/o update status inside a timer, this fixes F-1 Grand Prix Part 2 booting

For whatever reason, the scanline timer was jumping from 240 to 257 (!), hence it wasn't updating the i/o status (that happens on line 242 in this case). I've forced that to happen on a separate timer.

Questions:
*Does I/O update happens when the NMI is disabled?

EDIT: notice that this update requires a clean recompile (or a forced driver/snes.c compile), otherwise inputs doesn't work at all.
Posted By: Kale Re: The SNES WIP topic - 04/03/10 05:50 PM
Started now checking at Iso Zuri Ritou Hen (J), it sets an HIRQ at H=0, V=260 (NMITIMEN = 0xb1), and that causes a crash for whatever reason.
Disabling the irq firing makes it to boot and makes the sound to not work at all, hmm ...

Posted By: byuu Re: The SNES WIP topic - 04/04/10 08:33 AM
Hm, the PPU tests I just wrote are displaying the wrong pictures in MESS ... maybe you can take a look?


(should fade in and out)


(should scroll vertically)

The first one shows up as a solid white screen, and the second isn't showing the zig-zag patterns. Test ROM files are here:

http://byuu.org/temp/test_ppu.zip

Have fun wink
Posted By: etabeta78 Re: The SNES WIP topic - 04/04/10 08:36 AM
doesn't this require a dot-based PPU? or would it be fine in the old bsnes 0.63 PPU code?
Posted By: Kale Re: The SNES WIP topic - 04/04/10 02:17 PM
r7695 /src/emu/cpu/g65816/ (g65816.c g65816op.h): Added boundary checks for MVN and MVP opcodes in the G65816 CPU core, fixes booting in Iso Zuri Ritou Hen

In M mode, game does the following:

A = 0x10
B = 0x01

... when it transitions from 0x100 to 0xff, A had an identity crisis and suddently believes to be a 32-bit CPU register, hence it becomes 0xffffffff, cause of the crash. I've forced that to mask with 0xff to avoid it.

And now, some nice images of this *awesome* game wink


Posted By: byuu Re: The SNES WIP topic - 04/04/10 05:25 PM
Quote:
doesn't this require a dot-based PPU?


That was the joke, heh, sorry smile

Quote:
r7695 /src/emu/cpu/g65816/ (g65816.c g65816op.h): Added boundary checks for MVN and MVP opcodes in the G65816 CPU core, fixes booting in Iso Zuri Ritou Hen


Also be sure to set the DB register for good from these opcodes. But yeah, when you have opcodes that touch A and X+Y, it only cares about the state of either M or X, and never both. In the case of MVN and MVP, it cares about the state of P.X, and always treats A as 16-bit.
Posted By: Kale Re: The SNES WIP topic - 04/04/10 10:18 PM
DB register is currently setted as the value of the destination operand, guess it's good like this:

And, suddently, this started to work:





No idea what actually fixed this smile

EDIT: a PD application named "Paint" shows two issues:

* mouse support is pretty sucky at the moment;
* a gfx layer is entirely missing;

MESS

BSNES
Posted By: byuu Re: The SNES WIP topic - 04/04/10 11:14 PM
My mouse support sucks, too. I don't do anything with the mouse speed bits.
Posted By: Kale Re: The SNES WIP topic - 04/04/10 11:56 PM
Mario Paint does the following:

01E747: PHP
01E748: LDA $4212
01E74B: AND #$01
01E74D: BNE 01e747 (-$8)


Some kind of copy protection / timing check apparently (or simple bad code), because I don't see the point in pushing the P register. In MESS, we enter here at V point 226 (in BSNES that's 229 / 259) ... since we are "updating the inputs after three lines of vblank" that falls into timing edge case.

Very lucky. --"







Originally Posted By byuu

My mouse support sucks, too. I don't do anything with the mouse speed bits.


Heh, but your code doesn't ignore X/Y screen limits :P
Posted By: etabeta78 Re: The SNES WIP topic - 04/05/10 12:06 AM
mouse and superscope support is only sketchy. any improvement is welcome
Posted By: Kale Re: The SNES WIP topic - 04/05/10 12:53 AM
Another bug report:

Civilization (U) doesn't save properly, if you would like to resume a play, a "CONTINUE" option should pop-up ... current driver just doesn't do that.
Posted By: Kale Re: The SNES WIP topic - 04/06/10 01:48 PM
The Smurfs 2

85A57E: LDA $002140
85A582: CMP #$bbaa
85A585: BNE 85a5b7 ($30) <- ???


Enables some intense DMA transfers then checks sound port 0x2140, if it isn't 0xbbaa then it goes to an alternative route instead of just recheck the sound port. Timing bug.

Man, SNES programming tools must've been very very very ... very dire --"
Posted By: Kale Re: The SNES WIP topic - 04/06/10 04:01 PM
Another bug report, Final Fight (J) shows this at the Capcom logo, same issue as Super F1 Circus?



Sim City (garbage at the top of the title screen):



Super Tennis (U) / Super Tennis World Circuit (J) (mode 7 gfxs are offset when there's the change court animation):



Sim Earth has missing gfxs on gameplay (dunno why this was never reported before) and no sound



Pro Football (J) has flickering background, probably same issue of Daffy Duck and friends

Romancing SaGa (J) has misplaced gfxs just like Ardy Lightfoot:

Posted By: etabeta78 Re: The SNES WIP topic - 04/06/10 06:24 PM
Final Fight and Super Tennis have been like that since a long time (maybe since the beginning). I also thought I listed Super Tennis in the wiki bug page but I probably forgot about it

Sim City is otoh a regression happened after 0.137. I will try to find where it happened...

EDIT: Tin Star appears to have some glitch as well, appeared after 0.137. Give me a couple of days and I will have more time to find when these regressed and hopefully fix them.

btw, I finished going through Tafoid black screen. I will post the few new games which does not even reach title screen tomorrow (I still have to re-test a few of them)
Posted By: byuu Re: The SNES WIP topic - 04/06/10 08:03 PM
Finally, one I can answer.

Sim Earth needs proper vertical mosaic support to work.

Here's how you do it: take two variables, mosaicY and mosaicCounter. At Vcounter=1, reset mosaicY to 1, and mosaicCounter to the size value in MOSAIC ($4106.d7-d4). At each scanline, if mosaicCounter == 0, set mosaicY to the current Vcounter position. Now decrement mosaicCounter. If it's <= 0, reload the counter from MOSAIC's size value again.

Do that for each background independently. Simply writing to MOSAIC again won't reload the internal decrement counter, it'll have to reach zero to fetch in the new value.

Lastly, use mosaicY instead of the Vcounter for all purposes when rendering.

Obviously, you special case when $2106.d3-d0 has mosaic disabled for that BG by using the actual scanline instead.
Posted By: Kale Re: The SNES WIP topic - 04/06/10 08:12 PM
Super Famista (J) screen selection looks quite bogus:

MESS


BSNES


Guess it's some kind of subscreen issue.
Posted By: Heretical_One Re: The SNES WIP topic - 04/06/10 09:11 PM
That looks like color addition/subtraction, Kale.

As a "quick test", try the pilot selection in UN Squadron. I suspect it is similar.

Suspected cause: color addition or subtraction with halving is not working rcorrectly (possibly only with 0,0,0 blends)
Posted By: Kale Re: The SNES WIP topic - 04/06/10 09:38 PM
That works fine, but yeah, that looks like a color addition / subtraction crap.
Posted By: Kale Re: The SNES WIP topic - 04/07/10 12:36 AM
r7744 /src/mame/machine/snes.c: [SNES]: Basic implementation of the DMA master cycles steals

We started and here's the first results:

http://mamedev.emulab.it/kale/?p=1008

ETA: for some time, please don't report "minor" gfx glitches, just the black scren ones. I have to do many other tweaks to this thing hence it'll require some time. Please be patient.
Posted By: Heretical_One Re: The SNES WIP topic - 04/07/10 03:15 AM
Did the SNES get changed to a 21.whatever MHz clock?

If not, Kale, then you're stealing way too many cycles smile

8 master cycles is ~1 cycle at 2.68 MHz, or 1.33 cycles of what I thought MESS ran the CPU as (3.57 Mhz-ish)
Posted By: etabeta78 Re: The SNES WIP topic - 04/07/10 04:55 AM
Originally Posted By byuu
Finally, one I can answer.

Sim Earth needs proper vertical mosaic support to work.


ok I'll look into it, if Kale does not beat me. it's strange though, since we have some vertical mosaic support, but it seems to be not enough

Originally Posted By Heretical_One
That looks like color addition/subtraction, Kale.

As a "quick test", try the pilot selection in UN Squadron. I suspect it is similar.

Suspected cause: color addition or subtraction with halving is not working rcorrectly (possibly only with 0,0,0 blends)


the same color addition/subtraction seem to work fine with other games, though. it might be some edge case, I dunno, or a different reason

in general, if you want to test the various graphical modes and effects, you can simply recompile MESS with SNES_DEBUG_LAYER 1 in snes.h

then you can start to turn on/off modes and BGs (and isolate single priorities) and to enable/disable color math, horizontal mosaic effects and window masks.

of course, if the math/window/mosaic is enabled at the wrong time due to bogus read/write of the cpu, then these debug commands might not help much
Posted By: byuu Re: The SNES WIP topic - 04/07/10 05:19 AM
Quote:
ok I'll look into it, if Kale does not beat me. it's strange though, since we have some vertical mosaic support, but it seems to be not enough


Sim Earth was one of those bastard edge cases. It's the reason we ever even found out about the per-BG mosaic counters. Specifically, it was TRAC who was responsible for figuring that part out.
Posted By: Rychem Re: The SNES WIP topic - 04/07/10 10:04 AM
The latest SVN causes a bug in Super Mario World.

There is a slight flickering at the top of the screen while playing and after receiving a dialogue box in game the HUD disappears.

Thanks.


Posted By: Kale Re: The SNES WIP topic - 04/07/10 12:35 PM
Originally Posted By Heretical_One
Did the SNES get changed to a 21.whatever MHz clock?

If not, Kale, then you're stealing way too many cycles smile

8 master cycles is ~1 cycle at 2.68 MHz, or 1.33 cycles of what I thought MESS ran the CPU as (3.57 Mhz-ish)


I'm running it at 21.whatever smile Then, I take the single opcodes clocks and multiply by 6.
I'm sure that there are bugs in here (and I'm yet to implement cycle steal for the work RAM too), it's just sketchy atm. Plus probably we now have the probably obvious PPU timing bugs that I've said when modified the driver to run always at 512 H pixels ...

EDIT: Mario Paint now gets at the aforementioned point at V=239 (BSNES is V=229) ... we are (obviously) stealing too many cycles.
Posted By: etabeta78 Re: The SNES WIP topic - 04/07/10 03:42 PM
small note: S-DD1 stopped to work in rev 7652 due to the changes in snes_dma (i.e. moving some variables to the state class instead of directly accessing RAM)

Since I was not able to find the exact piece of code which was causing the regression, and I'm busy as hell at work, I simply reverted the function to read from snes_ram (+ a bunch of cosmetic changes). This should not introduce new regressions, but if there are any, please simply choose which snes_dma causes less damage and use that version. I hope to have some more time in the next days to find the proper solution...

EDIT: ok, I'm dumb...

the problems were caused by these lines:

Code:
		if ((offset >= 0x4300 && offset < 0x4380) ||
		   (offset >= 0x4800 && offset < 0x4808))
		{
			sdd1_mmio_write(space, (UINT32)offset, data);
			return;
		}


i.e. DMA addresses use sdd1_write instead of writing to the state variables... I'm going to fix this later tonight when I'm at home (hopefully)...
Posted By: Kale Re: The SNES WIP topic - 04/07/10 04:45 PM
Ok, I've reverted some code for now. There are still some video timing glitches, but at least they are more bearable now. I bet that something is F up somewhere, the fact that the G65816 cycle count doesn't work properly in the debugger doesn't help either. Any hints are appreciated now.
Posted By: judge Re: The SNES WIP topic - 04/07/10 05:11 PM
Reads done by the debugger are probably screwing up your cycle counts? I've had similar debugger side effects in the past where debugger reads caused irq flags to be cleared for instance.
Posted By: Kale Re: The SNES WIP topic - 04/07/10 05:51 PM
Uhm, for now I'm testing without the debugger, but that could be an issue as well ...
Posted By: etabeta78 Re: The SNES WIP topic - 04/07/10 05:57 PM
the s-dd1 vs. dma fight ended up with a draw this time, and we now have state variable properly used without screwing up completely s-dd1 games.

in any case, good work with the cycle stealing, Kale. I tried once to do the same but I thought it was cpu_eat_cycle the function to use...
Posted By: Kale Re: The SNES WIP topic - 04/07/10 06:29 PM
Yeah, doesn't make much sense ... but anyway, my basic goal is now reached, a.k.a. discover for good what are the "false positive games", there are two/three crashes that I would like to check (Kishin Douji Zenki 3 - Tenchi Meidou (J), Sound Novel Tsukuru,Super Tetris 2 & Bombliss Genteiban (J) ... )
Posted By: R. Belmont Re: The SNES WIP topic - 04/07/10 06:44 PM
There's some way to detect if an access is from the debugger and handle it differently. AFAIK mess/machine/apple2.c does it to protect the read-to-trigger softswitches.
Posted By: judge Re: The SNES WIP topic - 04/07/10 06:50 PM
Ah, these:
Code:
	if(!space->debugger_access)
Posted By: etabeta78 Re: The SNES WIP topic - 04/07/10 07:51 PM
note to myself: when I test (variable & 8), I get 0 or 8, not 0 or 1 (as if they're boolean). blush

too bad the mistake was a 1-line problem in a very large set of changes, so it went unnoticed when I double-checked rev.7549.
of course, now that I was looking for vertical issues, it hit me immediately

Fixing this silly mistake, I was able to get the following improvements (left = broken, right = fixed)

(Ardy Lightfoot)


(Tin Star)


of course, both games have now definitely better ingame graphics as well smile

and I'd expect Romancing Saga to be fine too
Posted By: Kale Re: The SNES WIP topic - 04/07/10 08:25 PM
Yes, Romancing SaGa works too. smile
Posted By: etabeta78 Re: The SNES WIP topic - 04/07/10 08:58 PM
btw, some of Kale's changes before 7725 also fixed R-Type 3 glitching graphics in later demo loops

and in current svn, also the brown solid rectangles covering text in TMNT intro screens are gone

If I have time this weekend, I will go through the bug list again to remove fixed entries
Posted By: byuu Re: The SNES WIP topic - 04/07/10 09:01 PM
I often use result = data & 0x08, etc. It will do 0->1 if result is of type bool. Hooray implicit casting. Have to be careful, Java / Ruby doesn't have this implicit casting, and some may not be aware of it.

But it beats the hell out of:
result = (bool)(data & 0x08);
Or the more terse:
result = !!(data & 0x08);
Posted By: Tafoid Re: The SNES WIP topic - 04/07/10 10:14 PM
Here is the latest spray of bugs found, If you see (REGRESS), it has regressed in the last week, probably likely to the cycle changes. There also might be duplicates of stuff in Wiki as I haven't weeded those out yet. I have not tested changes in the last 6 or so hours, including the graphic fix for Ardy + friends.

Black Screen or Hang
--------------------
Area 88 / U.N Squadron (REGRESS)
Asahi Shinbun Rensai - Katou Ichi-Ni-San Shougi - Shingiryuu (J)
Battletoads & Double Dragon - The Ultimate Team (REGRESS)
Clock Works (J) (REGRESS)
Gamars Puzzle (Unl) (Sound for a short time, black screen throughout)
Hayashi Kaihou Kudan no Igo Oodou (J)
Jikkyou Power Pro Wrestling '96 - Max Voltage (J) - Initial Graphics Splash - then hang
Kawasaki Superbike Challenge - Audio, but no graphics/hang (REGRESS)
Kirby's Fun Pak (E) [!]
Korean League (K)
Live A Live (J) - After START @ Title Screen, hang with sound (REGRESS)
Mortal Kombat II (Beta)
NHL Stanley Cup (U) [!] / Super Hockey (E) (REGRESS)
Packy & Marlon (U) (REGRESS)
Pirates of Dark Water, The (E) (REGRESS)
Popful Mail (J) (REGRESS)
Pop'n Twinbee (J) (Sample) [!]
Pro Kishi Jinsei Simulation - Shougi no Hanamichi (J)
Saikousoku Shikou Shougi Mahjong (J)
Scooby-Doo (Beta) - After copyright splashes - black screen
SM Choukyoushi Hitomi Vol 3.04 (J)
SM Choukyoushi Hitomi Vol 3.10 (J)
Sound Novel Tsukuru (J)
Super Battleship (REGRESS)
Super Valis IV (U)
Taikyoku Igo - Idaten (J) - some sound - black screen/hang
Takemiya Masaki Kudan no Igo Taishou (J)
Tecmo Super Bowl (Beta)
Wizardry Gaiden IV - Throb of the Demon's Heart
X-Terminator 2 Sauke (J) [!]
Young Merlin (U) - hang/black screen after hitting start @ title (REGRESS)
Zool (REGRESS)


Graphic Issues
--------------
Blazeon - ALTUS needlessly dim
Jungle Strike - slow graphics and insane flickering
NFL Quarterback Club - @ Title, strips of bad graphics (REGRESS)
Pachinko Challenger (J) - Company logo graphic issue
Pro Soccer (J) - corruption @ Title screen (REGRESS)
Raiden Trad (U) [!] - corruption @ Title screen (REGRESS)
Rise of the Robots - corruption @ Title screen (REGRESS)
Rocketeer, The (U) - corruption @ Title screen (REGRESS)
Shinri Game, The - Akuma no Kokoroji (J) - might be an issue with title - is it supposed to be rain/mist?
Sonic Blast Man - Animation when dizzy has graphic artifacts, strip of graphics out of place shortly after start
T2 - The Arcade Game (U) - flickering line near center during T2 Title (REGRESS)
Terminator 2 - Judgment Day - LJN rainbow logo (lower half corrupted)
Theme Park (E) [!] - menu background possibly incorrect
Warlock - Trimark screen flash corruption (REGRESS)
Ys V - flickering screen after game starts (REGRESS)
Zenkoku Juudan - Ultra Shinri Game (J) - Visit splash is corrupt
Posted By: Kale Re: The SNES WIP topic - 04/07/10 10:25 PM
Shinri Game, The - Akuma no Kokoroji (J) - might be an issue with title - is it supposed to be rain/mist? <- I think this is an issue with DMA / HDMA, text is missing after the title screen, and I'm aware that's controlled by HDMA too.
Posted By: etabeta78 Re: The SNES WIP topic - 04/08/10 04:21 AM
one thing we currently don't emulate is the fact that if HDMA is enabled in a channel, then it disable the DMA.

maybe it's not related, but...

EDIT: SimCity fixed and Final Fight (J) logo improved. they had some problem with sprites going from top to bottom. I hope we now handle all the cases properly...
Posted By: Kale Re: The SNES WIP topic - 04/08/10 02:21 PM
Originally Posted By Tafoid

Black Screen or Hang
--------------------
Pop'n Twinbee (J) (Sample) [!]


This is a plain bad dump, dumped as hirom when it's actually a lorom (and BSNES wasn't working with it either). Thanks to Cowering to spot this out.
Posted By: etabeta78 Re: The SNES WIP topic - 04/08/10 02:38 PM
SNES gamelist (soon to be added by judge) is based on the dumps nointro guys have