I’ve looked a bit more at Mega Phoenix, and discovered one or two things. Firstly the game seems very sensitive to timing. If I bump the CPU up the 128Mhz (which is completely ridiculous for a 68k) it actually ends up transferring most of the graphics, and you can see what the game looks like, so here are some pictures of a single loop.
All is not well however, for one, that’s a gross hack, and also the game isn’t really stable and will crash if too much action takes place, the graphics flicker, the enemies are invisible in round 4, and the Phoenixship on Round 6 is flickery and corrupt too. That’s hardly surprising given the nature of the hack.
I haven’t yet tried to hook up the sound, and the port where the service mode and player start buttons are read is either multiplexed or some kind of serial port.
I also don’t know what 2 of the roms are used for apart from the initial interrupt vectors, possibly the missing round 4 graphics, but it doesn’t even attempt to transfer from unmapped addresses, also there’s a cross-hatch pattern in there which I’d expect to be used in service mode, but again no attempt to read anywhere but known addresses is made.
Speaking of the service mode.. The background graphics don’t get displayed there either (they are uploaded, but then erased?!), but this is what it looks like.
That immediately reminded me of another game I’ve worked on.. Little Robin
It’s the same service mode. What else did this tell me? That the VDP I struggled to emulate in Little Robin is actually.. An unbadged TMS34010. I’ve confirmed this by hooking up a TMS34010 in the Little Robin driver, and it does indeed upload code for it and run it, however the backgrounds don’t appear (much like the MegaPhoenix Service mode)
I’m not sure if there are flaws in our TMS34010 emulation, or they both need a better hookup of something somewhere so for now I’ve just left Little Robin using my old simulation of the VDP.
What it does make me wonder is if Inder / Dinamic were actually the ones who made Little Robin for TCH. The Test Mode being identical is more than a little suspicious.
Note, I don’t consider MegaPhoenix playable yet due to the issues I’ve mentioned. I don’t know how much work it will be, it depends what the source of the actual bugs is.
I’m sure you’ve probably already thought of this, but are there other clocks that are derived from the main CPU clock? Maybe the other multipliers/dividers are wrong and jacking up the CPU clock gets the others closer to correct.
Something isn’t right because you gotten the graphics show up better on the MegaPhoenix by using an hack. Like you said it still having issues. Make me wonder CPU clock have a miscalculation somewhere.
Maybe bad dumps?
No, just timing errors somewhere in the emulation.
It might want to read flags related to the screen position somewhere, or just be a lot more fussy about the 34010 than games we have running.
Correct timing between multiple cpu’s in mame and mess is hard unless you use 1:1 interleave. Usually neither is done and it works through luck. Today your luck might have run out.
Yeah, setting perfect interleave was the first thing I tried, unsurprisingly it didn’t help, the TMS already forces sync per-scanline, which is usually enough.
I suspect there are multiple factors involved here, some of the flags 68k side maybe, could even be a scanline counter somewhere, and maybe TMS bugs, I find the issues with Little Robin when the TMS is enabled (rather than the simulation code I wrote without realising it was a TMS) to be interesting.
The TMS340 isn’t some obscure and rarely-tested component. There are tons of games that have one as the main CPU (Hard Drivin’ has three of them). If there were bugs in that core we’d know about it.
the number of ‘TODO’ comments in the source would suggest it’s been implemented only as far as ‘what needs to work’ and there are some hacks in there already for Cool Pool. I’m not saying it IS the TMS, I’m saying at this stage it’s impossible to rule out.
You could say the same about the Z80, it’s one of the most used CPUs in MAME, but it’s nowhere near good enough for the ZX Spectrum for instance.
Personally I do think it’s something more mundane, but I’m not overly familiar with the general way these things are hooked up a (otherwise I might have recognized Little Robin for having a TMS in the first place instead of reverse engineering it as a graphics chip!) I have looked in several other drivers tho to get a grasp of what is / isn’t possible in terms of the chip.
Hello David,
Maybe this could help (but i’m pretty sure you have it already) : http://www.transputer.net/mtw/rg-750/doc/tms34010/t34010ug.pdf
PS : has the owner of the board made a picture of megaphoenix board ?
Cheers,
Denis
‘Dumping Union’
yeah, I’ve seen the user manuals.
I’ve decided to try and rule out what I can on the 68k side first of all.
Enricnes supplied the following images
https://mamedev.emulab.it/haze/reference/megxphoenix_1.jpg
https://mamedev.emulab.it/haze/reference/megaphx_2.jpg
It’s a 3 board setup, 1 lower board, then an upper board with the roms and another upper board with the sound hardware.
There is some kind of PIC(I think) (P40) next to the ROMs but it probably handles the bootstrap stuff.
He has 2 copies of the game, one is dead. It doesn’t really surprise me that one is dead because the game relies on things like communication with the Z80 before it will even display anything (and for the z80 to communicate the components the z80 talks to must work too) so if anything even on the z80 side is broken you won’t get a picture(!) lots of work to diagnose.
As you can see from the rom boards they clearly planned on using this for even bigger games!
At least in Nonamed II snippets, the PIC is used for the next functions: read switches 0-1, read security codes 0-3, start watchdog and return software version.