Re: [新聞] (WIP) David Haywood's Homepage

看板Emulator (模擬器)作者conpo (獅子たちの旗)時間9年前 (2015/12/14 22:03)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串55/78 (看更多)

2015.12.14 年末瘋狂更新w "No longer utter Pollux" The Dooyong developed shooters are some of the more original Korean efforts of the 1990s, while other companies were simply bootlegging hardware ideas and code and hacking them into new looking games, Dooyong actually created their own games and used their own hardware designs. The quality in general was fairly average, but they’re not terrible to play. The emulation of them still had some bugs too, each game uses a slightly different mapping (same basic ideas, but all the ports moved around, slight changes etc.) which means sometimes bad assumptions get made, or things get missed. One game in the driver that had always had issues was Pollux with visible problems even on the title screen, and a number of MameTesters bugs relating to it. We knew from earlier work on Flying Tiger that the hardware had some palette banking, it just hadn’t been hooked up on Pollux. I spent a bit of time hooking it up, but was initially a little confused, we knew that Pollux was missing a palette cycle effect on the title, but none of the colours in any of the palette banks were cycling. That actually turned out to be a simple case of a missing vblank flag. The 2nd palette bank uploaded by the game is for the most part a darker copy of the first, although it was quickly obvious that the title screen was meant to be using that darker copy and not the one that it was using before, the darker copy is where the palette colours were cycling, and also where the correct colours were for several other title screen elements rather than entirely just darker versions like the rest of the time the game is running. Now, when the palette ‘banking’ was hooked up to Flying Tiger we didn’t actually treat it as banking, we treated it as some ‘ram write protecetion’ meaning the bank bit was being used more like a RAM write protect flag than actual palette banking. This struck me as wrong, and a little more studying of a reference video for Pollux gave further weight to my theory that the hardware really did want to do real palette banking instead. What I’d noticed is that in Pollux, when a bomb was released, the screen was meant to show periodic brighter pulses for the duration of the bomb. What I found out is that we’d actually been rendering the whole of Pollux with the wrong palette, the brighter version, since it was first emulated. That brighter palette was actually only meant to be used when you used a bomb, that was the entire point in there being two palette banks, a simple and quick way to turn the whole screen brighter / darker without having to write a new palette during gameplay. This simple bankswitch on the palette actually fits well with Dooyong’s general design of this hardware – leaving the CPU as free as possible to just run the game logic, not be updating palette data and tilemap data) I implemented this, it turned out the selected palette bank for writing is also always the visible one. As a result the game looks much darker now, which greatly improves the contrast between backgrounds and sprites. There was a MameTesters bug concerning the character portraits in the ending, after fixing the above issues I checked and that was fixed too, not too surprising. Bad palettes http://mamedev.emulab.it/haze/pics2015/pollux_bad.png

Good palettes http://mamedev.emulab.it/haze/pics2015/pollux_good.png

Here’s a video from MAME with the fixes, it’s got cheats enabled, but allows you to see all scenes in the game for reference. https://www.youtube.com/watch?feature=player_embedded&v=wpjMsEAO-Vg

The Flying Tiger code was also updated with this new knowledge, although I don ’t know if anything has changed in it as a result. It’s possible some of the other games in the driver should have this hooked up too, I plan on checking that soon. "The Value Of Videos" One of the most important things we can do as a society is make videos of things, take photos of things, and share them for the world to see, you never quite know when what you’ve done might come in handy, or prove to be the only remaining reference that something once existed, it continues to amaze me how even things that were at one point popular are now difficult to find any visible trace of now. This is true of arcade games as much as anything else, and I Know when looking at the fruit machine and other non-video games the situation is even worse, sometimes not a single photo of a machine anywhere. While looking at Mega System 1 it was noted in the source that the game P47 sets some other bits during the Jaleco logo, effect unknown. Luckily, in this instance there was a video on YouTube of P47 booting up. It’s a terrible quality video, but it still gave us an idea of what was missing. https://www.youtube.com/watch?v=iyyE5OecGHI&feature=player_embedded

some kind of trail effect… I poked around with the code a bit, and have attempted to implement this in MAME. https://www.youtube.com/watch?v=nKsfHSvP42c&feature=player_embedded

I don’t know if this is actually correct, at the point where they want the trails to vanish they adjust a parameter, the original video isn’t really clear enough to show how the trails are removed, so I’ve had to guess. If anybody has a P47 PCB and can record a better quality video it would be appreciated, the one on YouTube was more useful than the original poster probably ever thought it would be, but not really good enough to say my emulation is correct :-) "Mirror Mirror" Another long-standing problem with the Mega System 1 driver is the lack of character movement in the attract modes of 64th Street and Chimera Beast. A similar problem was fixed in Cybattler a long time ago by handling a mirror address for main RAM, easily noticed due to unmapped reads/writes, but the other two games weren’t making any unmapped reads or writes. Today I decided to try a little experiment. I knew from the ‘nmk16.cpp’ hardware that sometimes the 68k is hooked up to RAM in a way that means the byte write behavior is a little unusual. The standard way of handling byte writes is to make sure only the byte of the word that is being written to changes, leaving the other half of the word alone. Due to the way the 68k works it’s also possible for that hookup to be slightly different, so that a byte write alters the content of both bytes in the destination word, mirroring the written byte in the other half. Most games break if you implement things the latter way, they assume they can write bytes without them corrupting the adjacent byte. I quickly changed Megasystem 1 to use that method to see what happened, the result, a working attract mode. I do wonder if this is part of a bigger picture, NMK and Jaleco often worked together, there are Jaleco games in ‘nmk16.cpp’ and NMK developed several of the titles for Jaleco’s Megasystem hardware too, it’s possible some hardware ideas / designs were also being shared. While only Chimera Beast and 64th Street show obvious improvements from this, and both of those are ‘Megasystem 1 Type C’ hardware, I’ve hooked it up to all hardware types (except D, but that’s very different and did cause the game to crash) I’ve not noticed any real differences this way, most games don ’t make many byte writes, some avoid them entirely. St. Dragon makes an unusually high number so it might be worth checking / verifying that nothing has broken there with these changes, it is afterall possible that only one of the board types has this design. Here are some revised attract mode videos from the games. The 64th Street one also shows the environment damage that was previously missing (Kale fixed it last week) and the Chimera Beast one, to my surprise, shows the Mosaic effect, it’s used ingame when you get grow. https://www.youtube.com/watch?feature=player_embedded&v=kIOSoTHtBIc

https://www.youtube.com/watch?v=qhBjrqNTDm8&feature=player_embedded

"Somewhere Only Slightly Less Dangerous Than The Hands Of A Hoarder" Following on from the post about the rare PV1000 game being dumped we have saw another rare Japanese console / computer game dumped. This time it’s one for the Tomy Pyuuta system, an early ’16-bit’ machine. The Pyuuta games while not graphically spectacular or ambitious do seem to offer some fast paced arcade-like gameplay, and this one is no exception. The game in question is “Bermuda Triangle” Despite the initial appearance (what looks to be a massively oversized ship at the bottom of the screen) it has no connection with the much later arcade title released by SNK. This is a fast and challenging wave based shoot / dodge game. This one was also rather costly, with most of it being paid for by MooglyGuy this time around. https://www.youtube.com/watch?v=XkkWiSVlsj0&feature=player_embedded

"Makeup On A Broken Man" The Jaleco Megaystem 1 driver is broken to an almost shambolic level, nothing really works as it should. This is mainly down to interrupt handling, timing, sometimes subtle protections, and generally things not being understood well. It did used to run ‘better’ but even back then it was held together with hacks. If you’re expecting this post to be about Ninja Kazan (Iga Ninjyutsuden) being fixed, or the random sprite lag being fixed, or Takeda Shingen / Shingen Samurai-Fighter crashes being fixed then stop reading now, they’re not, I have no clue how to fix them without resorting to the hacks of old, and I’d really rather not do that. Kale did add a video RAM mirror allowing the background destruction to function correctly in 64th Street (characters still don’t move during attract tho) and so I decided that while fixing the bigger issues with the driver simply wasn’t going to happen it was probably worth making some other improvements for the time when that does happen. It has been known since system11 acquired a PCB and made a video that there was a graphical effect missing in Takeda Shingen, A Mametesters report was created with 2 handy videos demonstrating the effect in Takeda Shingen and the P-47 test mode. This was a while back, and in the meantime the Final Burn Alpha devs emulated the effect due to having more active devs on the MS1 driver than we have. Since nobody else had done it yet, and it was easy enough, I ported the FBA code that dink and iq_132 had written back into MAME; since the FBA code was based on the MAME code in the first place this wasn’t too difficult. The result can be seen in the vidoes below. Note, I’ve used the English language set ‘Shingen Samurai-Fighter’ instead of the Japanese language set system11 used for his video. Also note, the game really is broken beyond being playable in MAME right now and crashes out at the start of level 2 even in this test video. The effect can be seen after I pick up the power-up which turns my sword into a flashing one, and then kill some enemies, with the effect emulated they ‘pixelate’. https://www.youtube.com/watch?v=8KoigziHzTo&feature=player_embedded

The P-47 test mode video demonstrates more clearly the settings for Mosaic that are available. (same settings as Mametesters reference video have been used, you can see the effect creates the same pixels in MAME) https://www.youtube.com/watch?v=XsLulHtj_i0&feature=player_embedded

The effect is also used on the Jaleco logo in P47, after the spinning squares, looks a bit ugly, but should be correct. There’s actually another missing effect on the Jaleco logo here, the initial graphics should draw sprite trails, we’re going to have to look into that one too, could once again be the only place it gets used(!) https://www.youtube.com/watch?v=nrmGrWeMASA&feature=player_embedded