I’ve continued to poke around at the XaviX emulation and figured out what was preventing the Namco Nostalgia 1 TV game from running. Namco Nostalgia 1 contains Mappy, Xevious and arranged versions of said games.
(technical reason, the lda ($0a), y style instructions are expected to fetch the pointer from zero page ram, but the actual data pointed to needs to be fetched from ROM, at least for upper banks)
The Nostalgia collections also make aggressive use of the screen clipping registers, for whatever reason in the Mappy remix the developers decided to clip the house to a single pixel at each side of the playfield, even if the full house is present in the graphics. I implemented the clipping based on other games, but it seems like I was clipping a pixel too much off the left side, so in the video I recently uploaded the left border is missing. Not clipping that column of pixels does result in an unwanted space where you can see the background between the status bar and left edge in Snowboarder, but I have a feeling that would happen on hardware, and Mr. Do’s videos of the Nostalgia games are of far higher quality than any of the Snowboarder (non SSX version) so I’m going with what the better videos show as evidence.
Interestingly the high score handling on both the Mappy games in this collection appears to be broken, showing the high score as ’00’ or ‘000’ in / when the high score table is presented rather than the true high score. I thought this was an emulation bug, but again checking Mr Do’s original hardware videos the exact same thing happens there. I’m not sure what happens if you beat the real score, possibly that fixes it, unless high scores simply don’t work at all?
Below are some screenshots of the boot screens and the arranged Mappy game, which plays like an Arkanoid style game where holding the button down at the right time gives you extra jump height (but don’t do it 3 times in a row as your rope changes colour and will snap if you attempt to do a high jump while it’s red)
The Xevious arrangement takes the form of a flag collection / bombing run style game, where you’re rushing to the end of stages against a clock with various things slowing you down rather than outright killing you.
The classic versions of each game run too
Fixing the bug that was causing Namco Nostalgia 1 to not boot also allowed Radica’s Baseball 2 to show some screens, although I haven’t got the analog inputs hooked up, so it isn’t yet playable.
Adding EE-PROM support allowed Excite Fishing to show a few more screens, before moaning about the EE-PROM again because presumably my hookup is still incorrect (the Nostalgia games no longer moan either, but don’t remember your changes properly even if they do write them to the EE-PROM)
I also started looking at the Super XaviX a bit, which needed additional opcodes etc. implementing in the CPU core. The most impressive progress with that one is Dirt Rebel MX, where the menu screens are fully functional, and the game even seems to control, but graphics need work (definitely needs raster interrupts for the road rendering)
XaviXport Tennis also reaches ingame, although again probably needs raster interrupts to do the linescroll effect on the court, and also has no working controls other than a single button to advance through menus. This also runs in an interlace mode and sends the fields on alternating frames, which means the entire image shakes ups and down at the moment, I’ll probably have to figure out a ‘clean’ way to deinterlace and render in a higher resolution otherwise it’s migraine inducing.
Lord of the Rings shows some stuff, but appears to use DMA in a strange way, and doesn’t transfer a valid palette (and goes no further than these screens)
Dragon quest does similar also expecting a weird DMA behavior, but gets stuck on this screen instead (it does actually upload a palette, but I’d hacked up palette use for making the previous screenshots and not restored it)
Star Wars seems to make more extensive use of the custom opcodes and is currently not showing anything.
Just curious, what is it about XaviX that motivates you to implement it at the top of your list of things to do?
Also, your starting early article needs to add the Salter bike dump, recently donated, changing: ” It will be interesting to see if the version for the Salter bikes actually ends up being dumped and emulated in MAME eventually too.”
“Mappy: Nyaamco-Dan no Gyakushuu” and “Xevious: Scramble Mission”, in case you want to give them their actual names. They are off-shots more than arranged versions.
Cheers.
XaviX is an interesting challenge and represents the kind of work MAME has always excelled at; figuring out random pieces of hardware, especially for things that would otherwise be lost / forgotten / aren’t really interesting enough for a standalone emulator to survive.
Basically it’s been fun to work on. It’s also got some historical significance because, especially in Japan, there were a lot of licensed official IPs (like these Taito / Namco things) in the form of toys etc. using the tech, and things like the XaviXport, while not a massive commercial success, did kind of foreshadow the whole Wii / motion control craze.
There’s also the angle that working on them is relevant to what other people are doing, which means there’s support for the work being done; Peter has been buying the various games, Sean has been dumping the ones he is able to handle, and for the rest, due to level of interest, we’ll hopefully end up finding a solution that works. Add to that, these things are often toys, don’t work great with modern HD TV sets and I imagine you’ll find a lot of them just end up on the scrap pile, so unless we start emulating them we might find them increasingly difficult to source.
Offshoots is probably a better term for the Namco ones, yeah, the Taito ones are a bit boring in comparison (just character swaps really, with slightly changed mechanics for each character)
The final reason I’d give is just personal swing, I’ve always been curious about these things and the tech inside them, so having the chance to work with them fulfills a personal interest. I kinda wish I’d known these things existed back in the day and that there were people writing games for this kind of tech because it’s exactly the kind of work I could have done, and would have likely enjoyed.
Yeah, the bike thing will need updating, at least once we emulate it, it remains to be seen what functions the undumped IO MCU provides. Apparently there’s another model not dumped too.
Haze, what do you think is going on with the color? What’s interesting is the Lord of the Rings has fully saturated colors, even if the palette is wrong.
Do you think the color is correct and there was some kind of ‘chroma gain’ applied to the analog out? Or does the palette handling need more work?
I don’t know, the palette is some kind of HSV / HSL thing, my conversion to RGB is incorrect.
The Elan based ones (Space Invaders 5-in-1 etc.) have a similar, but not identical scheme which I also don’t have right.
The conversion algorithm I’m using is just the most common one you can find online. I’m not especially knowledgeable on the colour conversion process, so somebody could probably do a better implementation than the one I have.
Lord of the Rings has no palettte handling hookup up, so is rendering with the MAME default palette.
just read this on bannister’s :
( the concept that “games should be presented the way they actually ran” is apparently controversial )
kind of ironic considering that , for so many years now , mame’s default settings include this atrocious aa / blur effect that completely obliterates all the pixels
not as bad as running 4:3 games in 16:9 but pretty close
funny how vastly incorrect aspect ratio + ugly filters is what 95% of the youtube audience seems to upload / like
i hope mame can change that default setting in the future !
I understand your frustration, although the actual emulation is still correct and not being altered in any way, your complaint is merely with the presentation of the final bitmap which you can control quite easily. Default input mappings aren’t always ideal either, the idea is that you change them.
I go for correct aspect with my videos, but yeah, they end up filtered, not because of MAME, but because the best software I’ve found (one where I don’t have to create intermediate files 6x the size) has no ‘sharp scale’ filter and YouTube is absolutely the dumbest thing ever if you upload a video as 240p
You can always specify a prescale value higher than 0 for sharper pixels, if you’re recording the gameplay via OBS or you just want to play (LCD games will look distorted, though) .
For MAME’s internal video recording, you can use After Effects to make a high resolution 4:3 template and rescale the video to it, just make sure to set the “quality and sampling” of the video layer to “Draft” and set the exported video’s render settings as “Quality: Current settings” (so that it doesn’t ignore that “Draft” setting in the layer).
That said, the “CRT-geom” shader is probably the most faithful way to play most of the systems that MAME emulates “the way they actually ran” (although scanlines will have the wrong orientation in vertical monitor games). Last time I tried, even HLSL added some blur and bloom that I don’t remember happening on real, well maintained CRTs (made it look more like how a TV looks like when filmed/photographed) and made games like Sonic quite annoying to play.
I actually find MAME’s quite powerful when it comes to scaling, smoothing, and aspect options, personally I always get what I want from it in that area (when I’m still puzzled with rotation options but heh no huge deal)
There’s indeed the prescaler (filter 1 with prescale 2 is already great for hiding scaling artifacts and smooth things a bit), but with HLSL you can also apply much more advanced smoothing if you turn everything scanlines, mask etc, OFF, then only use X & Y defocus: custom smoothing both directions independently, awesome!
I even do combinations using either stretching or integer, custom defocus, and handmade png artwork effects.
You can do that per-system or per-game also of course using specialized inis.
Agreed bilinear by default is ugly, and the default HLSL raster.ini settings in D3D are atrocious (should be named ‘ruined crt’). BGFX’s default HLSL looks better but not yet ideal and changing + saving your settings is a challenge with that backend.
The raster.ini is easy to clean up and retart from scratch though, just wipe it and copy the mame.ini’s default starting neutral settings then set everything to your liking from scratch. Of course per-game or system works too.
Recommmend to wait for 0.203 that fixes the overlapping specialized .ini’s issue though, or you’ll go pulling your hair out.
Just wanted to say that Byuu, the author of Higan and Byuu emulators, just moved to Japan for work. I remember seeing him a few times in the Mame forums. Not sure if you know him, but maybe he can help find some toys and things.