Sometimes drivers sit untouched for a while, not because they’re especially difficult to make progress on, but simply because they’ve ended up at the back of the queue while other potentially more interesting targets are looked at. PoPo Bear is one of those drivers.
BMC aren’t known for their regular arcade games, everything else we’ve been with the BMC brand on it has been a poorly disguised gambling / redemption game and the compact PCB design of PoPo Bear along with the 4 banks of dipswitches (above 2 is unusual for anything other than Gambling games) I actually expected it to be another gambling game, and issued a warning that if we were to buy one of two PCBs available at the time it should probably be the other one because it looked more interesting. In the end both were purchased, because even if it had turned out to be a gambling game the current policy means it would end up supported anyway and the prices were reasonable.
The original Dumping Union MAME World post from when it was purchased can be found here and the following PCB picture was supplied as part of that.
(The compact PoPo Bear PCB could easily have been a gambling game like most BMC titles)
Upon initial inspection of the ROMs they did indeed contain strings like ‘Hopper’ and ‘Payout’ which seemed to confirm that it was, like everything else, a gambling game, even if it didn’t look it from the screenshots we’d seen (but screenshots can always be deceptive, see games like Lucky Boom) Kale did some work on the driver back then and got it running the game, but the video implementation was left significantly incomplete (wrong res, bad sprites, bad scroll, bad enables etc.) and the game remained only borderline playable due to the glitches.
The interesting thing at this point was that it actually appeared I was wrong, all the aforementioned strings in the ROM simply appear to be leftovers from the codebase of another game probably developed to run on the same platform, this game was clearly a hybrid of the classic ‘Snake’ game lots of people grew up with on their phones (and we should really get around to emulating!) with elements of Bomberman thrown in for good measure, an actual proper game with no signs of any kind of Payout system or rigged gameplay.
Anyway, I decided to pick the driver up again the other day, clean it up, and fix up as many of the video bugs as I could.
I believe BMC to be either Chinese, or possibly Taiwanese like IGS, and (original) games and hardware from that region tend to lend themselves to some curious hardware designs in terms. This hardware is no exception to that, and while the CPU is a bog standard 68000 the video hardware has some oddities.
First on the list is the tilemap handling. The majority of arcade games have the video hardware access the graphic ROMs directly. On this board they’re memory mapped, don’t decode as tiles and the CPU has to copy them into memory before use. Not too unusual, but then you have a further peculiarity with the system. Despite there being a clear tilemap layout in RAM addressing tiles by number the data doesn’t actually get copied across as tiles, but instead as a linear 512 pixel wide bitmap. The hardware transparently converts the addressing into tiles for drawing, but the CPU can draw directly to the screen directly more easily than if it had to pack everything into tiles. The game doesn’t really take advantage of that, but it’s something you don’t see on every piece of arcade hardware, and is probably used to more of it’s full potential by some other undiscovered game on the platform.
I spent a fair bit of the time cleaning up and understanding this as part of the work I did on the driver, to hopefully make it clearer that the hardware really does use tiles for the tilemaps, even if the way they get stored is odd.
The tilemap chip supports 4 scrolling layers, of 128×64 8×8 tiles, and can turn on row-select and line-scroll effects for at least 2 of them. It uses 8bpp tiles from a single palette of 256 colours outputting a resolution of 480×240, not bad for a generic looking PCB.
The sprites similarly require their data to be copied into RAM first, a different area of RAM to the tile graphics. Otherwise they’re more conventional, not tile based, but must be multiples of 8 in size. The width and height are tied together, so sprites can be 8×8, 16×16, 32×32 or 64×64 pixels in size. They have their own set of 256 colours, although the palette addressing is messy, the sprite pixel data is 8-bit, which would give you access to all the colours anyway, but there seem to be at least another 4 bits to further convolute the addressing. That isn’t fully understood because the game makes minimal use of it. The priority system is a sprite to sprite one, with 16 levels of priority, again unusual, for the majority of systems the sprite to sprite priority is determined by the list order, with only the sprite to tilemap priority being determined by the sprite priority bits. It’s unclear if there is any level of sprite to tilemap control or if priorities are fixed.
Anyway I fixed most of that as well, the primarly problem was with the sizes, and the observation that all things should be equal width/height soon made things look a lot better.
With those fixes the game is now playable, truth be told Kale had already done most of the work needed back when he looked at it initially and it just needed some fresh eyes to clean things up and better understand a couple of aspects of it.
There are still some things not quite right, I think the hardware has some kind of timers and readback of the timer registers because right now a number of elements in the intro animate at turbo speeds, and the music playback is also quite broken. I’m hoping that now I’ve fixed the graphical side of thing Kale will revisit those, but in what time frame remains to be seen.
The game sports a year 2000 copyright, I guess when you take that into consideration it is incredibly dated looking for the time period involved, but it’s what you come to expect from some of the games developed by relatively unknown parties outside of the Japan. It also coincides with when IGS were doing well making me think this attempt to jump into the games market might have been inspired by that.
Anyway, here are some screenshots from the current emulation of the game, with the various fixes I’ve made applied over Kale’s initial work from last year
(Current Emulation shots from PoPo Bear)
Pretty, pretty, pretty, pretty good.
Excellent stuff, remember playing something similar in a fairground on Helston Flora Day.
Whats the current state of discreet sound, aka Zero Hour for example. Or are we just waiting for another god of discreet knowledge.
Thanks in advance
discrete sound (and discrete emulation) require a very specific set of skills, I don’t think anybody is active in that area at the moment, it’s thankless work for the most part.
Nice! I remember tipping Smittdogg off about this pcb being up for sale. I’m glad to see it finally getting some love.
Thanks Haze & Kale.
http://www.grb.or.kr/download/GameImage/2000/2000-P0081.jpg
anyway, In korean, “popo” means “kiss” (xxx)
What exactly is discrete sound and discrete emulation?
Obviously as a MAME user I have heard these expressions a lot, but have no idea what they mean in emulation terms.
Discrete sound means modeling the action of mostly analog circuits, down to the capacitance, inductance, resistance, and possibly the effects of circuit topology. How a certain amplifier clips at certain levels if applicable, all that jazz.
I proposed somewhere a logical extension to the HLSL shaders. HLSL is designed to enhance graphical authenticity under certain circumstances, while my idea is for audio.
The idea is to make impulse responses of a few different cabinets and use them for a convolution reverb setting in mame. Then it should sound, more like at least, like playing a real cabinet. If mame implemented VST support that would be doable now, but there’s probably some kind of license thing stopping that. An open source alternative no doubt exists.
For discrete emulation, see ht tp://en.wikipedia.org/wiki/Death_Race_%28video_game%29
A game I played when it came out. I’ve always been good at driving games.
T-Jay: Discrete sound means audio is produced by a set of dedicated analog and/or hybrid digital-analog circuits, each of which makes one specific sound. This was the case in e.g. Space Invaders and Asteroids, and lots of early-80s noisemaker toys :)
Discrete emulation means the game is done entirely in hard-coded logic; there is no CPU, no software, and often no ROMs.
In both cases, it’s quite a different paradigm from how MAME/MESS usually work and requires more of a pure electrical engineering skill set.
Stage 1 – 1? Hmm, I wonder if this thing has a second loop. It could happen, as SUN has done that with their games, and they are also a Korean company that made a good clone of Mr. Driller. Excellent work as usual, Haze! I would have never known if it weren’t for guys like you!
Arbee: I thought there was a difference, but didn’t know what it actually meant in emulation terms, so in ‘modern’ PC terms this is like the small PC speaker that bleeps, as it only makes one sound. So emulating that would be harder/different than say a ROM chip.
Am I guessing then a calculator of the 80’s was (I was very impressed with these as a kid – along with digital watches) based on hard coded logic as an example of ‘discrete emulation.
Thanks for the description :)
Visually speaking it reminds me a lot to Mouse Shooter GoGo by Metro… cool find.