Xevious/Galaga

[tcdev]

As a background task, when I don't have the resources to work on other aspects of PACE, I've started to add Xevious (Galaga hardware), for no reason other than it being my all-time favourite arcade game, and something I've wanted to do for a very long time (as well as completely disassemble it).

It requires quite a large FPGA, so don't expect it to be portable to anything like the DE1/DE2 anytime soon... :(

[tcdev]

Nothing too exciting - had a few minutes over lunch so I added the RAM and VRAM blocks and it would appear that the main CPU is running, executing code from its ROM.

It's looping around address $027E? - maybe some I/O not hooked up or handshaking from the other CPUs. Time to break out IDA and start disassembling... :D

[tcdev]

Fiddled a bit more with Xevious tonight, adding the SUB and SUB2 CPUs.

This will be interesting because I need to time-slice all 3 Z80 CPUs, and they all have shared access to peripherals via a shared memory map. I'm clocking the system at 16x CPU clock speed (3.072 x 16 = 49.152MHz). The only other design with time-interleaving that I've done thus far is the Coco, which splits RAM access between the CPU and the VDG.

[tcdev]

Nothing much to report. Added the foreground tilemap layer but still no output from the running CPUs. At this point I don't even know which CPU is responsible for the 'garbled' start-up graphics or the self-test! Most likely it's due to the lack of NAMCO custom IC implementations to assist in handshaking/reset etc...

I also noticed that the current PACE architecture doesn't actually support more than a single tilemap layer! It's something I'll have to add sooner rather than later... of course it'll probably break every project in the repository (again).

[tcdev]

Tonight, while running some tests for work, I added support for multiple tilemaps layers to PACE.

However, it has broken every single project in PACE, and the projects with 0 tilemaps won't even compile! I think I have a fix for that, but it's ugly.

Each tilemap layer is an instance of the same entity, but each layer is a different configuration (architecture implementation). I can't figure out how to specify the configuration to use, without using 'entity work.<entity>(<configuration>)'. But because it's in a generate statement, if that layer doesn't exist in the design, it fails compilation (even though it isn't used).

Another nasty in this case is the use of an array (1 to 0). It actually seems to compile if I hack the configuration. I don't know whether it still synthesizes correctly though...

[tcdev]

Some more WIP. I was getting no video contents (the video RAM was cleared though) when I noticed in MAME that both the sub CPUs weren't actually running whilst the 'garbled' graphics are displayed on startup. So for now, I removed them and now I get to see the graphics cycle through their pattern for a few seconds. Yah!

I've added the palette and hooked up the attribute RAM for bg & fg tilemaps, and added palette lookup logic to the fg tilemap. I'm not sure the colour lookup is correct yet, but it's not important atm; at least it shows different colours now.

I've started implementation of the NAMCO 06XX custom chip, which interfaces the CPUs to the other custom chips and also controls the main CPU NMI. I still don't understand completely how it works yet, but it should in theory at least generate the main CPU NMI correctly?!? Hasn't made a difference to what I see though...

I'm not sure what holds the sub CPUs in reset at startup yet either. I suspect it's one of the custom chips, but I can't even see where that is in the MAME code.

I've added the VBLANK interrupt to the main & sub CPUs.

And I managed to find the self-test strings in the main CPU ROM. I suspect I'll need some more inter-CPU communications and/or protection implementation before I see any of those appear!?!

Another thought I've had is to use the bootleg ROMs which apparently don't use any of the NAMCO custom chips. However, I understand a 4th Z80 is used to implement the missing functionality. Certainly interesting to try...

[tcdev]

I'd forgotten that I _did_ actually know how/where the sub CPUs were reset. I've implemented that now, and with all 3 CPUs enabled the garbled graphics are now running. Still no further than that atm, but at least the CPU enables are sorted.

I fixed the VBLANK interrupts, which were only pulsed for a single CPU clock - that was never going to work! :O Now it does actually vector to the interrupt code.

That's enough for a Sunday night!

[tcdev]

Managed to find the time to do a little more this morning before starting work.

I added the dipswitches, as I noticed that there is a 'freeze' setting and was wondering if that was the reason it was halting before the self-test. Turns out not to be the case.

After looking further into it, I've deduced that the main CPU is definitely looping waiting for a flag in RAM to be set. I know where it is being set in the code, but as yet have not worked out how/when that code is triggered. I suspect that it has something to do with the protection implemented in the NAMCO custom ICs, because there's code that accesses them nearby.

To this end, I tried the bootleg (xevios) roms and it actually gets further, clearing the screen after the garbled graphics are done, although the game still does not boot all the way to the attract mode. However, this does suggest that perhaps it is the protection preventing the namco version from running.

A good test might be to disable the NAMCO ICs in the MAME driver and compare the behaviour.

[tcdev]

More WIP, this time added templates for the 50XX, 51XX & 54XX NAMCO custom chips. Only the 50XX does something even remotely sensible atm.

These chips are actually Fujitsu MCUs. The 51XX is fully emulated in MAME, but the 50XX is a black-box implementation, which is fortunate as that seems to be the one causing my problems atm.

I know that my IRQ control from the 06XX isn't right, so that's WIP. The game now restarts a few times after the garbled graphics are finished, rather than freezing. Does this qualify as getting further? :D

FWIW: MAME's "documentation" of the hardware is somewhat lacking. Aside from being out-of-date, unfinished, and/or just plaing wrong, it still doesn't quite lend itself to documenting a design that you an readily replicate in hardware. I suppose being one of the few people actually attempting this, there wouldn't be many MAMEDEV'ers that would know this...:(

[Talus]

FWIW: MAME's "documentation" of the hardware is somewhat lacking. Aside from being out-of-date, unfinished, and/or just plaing wrong, it still doesn't quite lend itself to documenting a design that you an readily replicate in hardware. I suppose being one of the few people actually attempting this, there wouldn't be many MAMEDEV'ers that would know this...:(

I could have told you that... :) It is especially true when you get to the more complex games with advanced sprite engines that the difference between the software and hardware implementations become apparent. What they do in the drivers (including prerendering things and just storing it in memory) simply wouldn't work in hardware... Still, there is useful information to be gathered, such as memory maps and which ROM goes where.

But keep up the work. I look forward to playing Galaga someday!

[tcdev]

But keep up the work. I look forward to playing Galaga someday!
I'll get there, I"m sure! ;)

The sticking point the last day or so has been working out how the 06XX and the 51XX handshaking works. The MAME 'documentation' actually contradicts itself in this regard (when talking about the IRQ lines), and also omits any description of the functionality of one pin on the 06XX which is connected to the 5XXX chips.

Regardless, I think I have it sorted now, or at least, have invented a function for pin1 that should allow me to implement what is required, according to the MAME code.

As I mentioned, the 51XX in MAME is a black-box implementation. i.e. there's no MCU and no ROM emulated; rather the functions (reportedly) performed by the chip are coded directly in MAME. The most important function, AFAICT, is the reading of the switch and control inputs. Other functions include score management, but according to MAME Xevious does not use them.

This morning I implemented what I thought should operate according to the MAME documentation - as far as required to get to boot. I only got the chance to run it once - no debugging - but it remains frozen after the garbled graphics. No reason for concern yet, as I haven't even verified my implementation with SignalTap etc.

The MAME documentation also notes that it uses the custom chips "for protection". It may (also) be that I need to implement a little more functionality (eg.the 50XX) before Xevious will boot to the attract mode. Early days yet...

Certainly mildly challenging, which makes it more fun than simply transcribing schematics. And with any luck, once it's done, it should simply be a matter of exchanging ROMs, tweaking the video hardware emulation (the games all have different video logic) and Galaga - and Bosconian and DigDug for that matter - should just run! :cool:

[tcdev]

Tonight was the 1st time I've had a chance to fire up Xevious since the last posting in this thread.

I think I've got the 51XX working properly now, at least in so-called 'switch' mode.

I was hoping this would be enough to get to the self-test screen, but alas, it is not. I've been focusing on the 51XX too closely (and the NMI routine that reads it) and need to step back and see where it's spinning and where it should go next. I'll need to do some more execution tracing in MAME methinks...

[tcdev]

Some progress to report. Of sorts.

Finally worked out that it is actually executing the self-tests, and that I should be seeing the text on the screen. But I'm not. Or rather, wasn't.

Taking a step back it became apparent that my tilemap controller isn't even close to being right. Tiles are flipped horizontally, the X,Y axes are rotated, the scroll registers aren't implemented, and the transparency isn't right. Doh! :o The first step is usually getting the tilemap working with seeded video RAM and no CPU, but I skipped that step with Xevious. Serves me right... :o

Anyway, I've hacked together enough to at least see the self-test text now. I fixed the tile flip and implemented the scroll registers, but because of the rotation, I still need to fudge them to see any text.

RAM test is passing, ROM test is failing with a '4'. I'm yet to look any further into this, but at least I can see where it's going wrong now, rather than stabbing in the dark with no visual clues to go on!

[tcdev]

I've fixed the tilemap so that it is at least oriented correctly, and the palette should now be correct.

There are 7 'ROM checksums' in total. The 1st is the checksum of the full SUB2 ROM. The 2nd and 3rd are just copies of bytes @$0409 & $15FB in the SUB ROM. The last 4 are checksums of each of the physical MAIN ROM devices (4x4KB).

The check is failing with B=4, which is the 1st block of the MAIN ROM.

It's got me stumped atm. The checksum of the source binaries checks out fine. I can't see anything in the code that would corrupt this value in the absence of some security protection device (ie. 50XX/51XX). Then again, it's doing some narly context switching in the NMI that is triggered from the 06XX. Bleh!

If I patch out the test, it runs through to the attract mode, and then promptly reboots. I actually saw the "INSERT COIN" and "XEVIOUS" logo at one point! :cool:

EDIT: Both 'Xevios' and 'Battles' bootleg sets run through to the attract mode, and then reboot. That suggests that it is perhaps the NAMCO custom IC that is the problem after all. Very interesting. Next step is to remove it from the MAME driver and see if it fails with the same results...

[tcdev]

Hmm...

Removing the 50XX in the MAME driver causes the infinite reboot seen at the attract screen. So that at least explains that - I need to implement at least part of the 50XX behaviour there in order to get the game running.

I can't for the life of me emulate the 'ROM 4' behaviour in MAME. I removed pretty much everything that I haven't emulated in the FPGA and it still doesn't halt with that error. Even without the 50/51XX at all, it still passes. That suggests there's a problem in my implementation, rather than something missing?!? Bleh!

[tcdev]

Some good progress tonight. :)

I started with an implementation of the 50XX. To be precise, a rudimentary functional implementation adequate only for Xevious, which writes a total of 3 bytes and checks the value of the latter 2 responses. FTR, it activates the scoring functions, first zeroing the score, adding 5 (and reading it back) and then adding 90 (and reading that back). A failure resets the game.

During the process I discovered the code that does the check, and subsequently discovered that there was a routine that checks that the 1st 10 bytes of this routine hasn't been patched! Amazingly, that check routine was right next to the first, so it was not going to be hard to spot when you're poking around patching the protection out! Doh!

Still no dice, which had me stumped. So I set about trying to discover where the MAME code and my implementation differed in execution path. Not a trivial task with 3 CPUs, interrupts firing, and no interactive debugger on the FPGA. I finally found the culprit - a return address had the wrong high byte! That had me looking at where the return address was pushed onto the stack, i.e. the write-strobe generation...

Turns out it wasn't always generating a write strobe (the 3 CPUs are time-multiplexed) at the correct time. I was amazed that the code had managed to get anywhere at all with this problem, let-alone right through to the attract screen! After fixing the problem - the attract screen appears (see attached eye candy). :cool: Note that only the foreground tilemap layer is enabled atm, and the colour attribute looks like it's off by 1 tile.

It's not quite running right yet - the flashing 'INSERT COIN' is orders of magnitude too slow, for example - but the encouraging thing is that there's quite a bit of code to get through and all 3 CPUs need to play nice to get this far. I do know I'm missing some video interrupts on one of the SUB CPUs...

I also removed the MAIN ROM check code patch, and it passes, but for some reason that version then reboots in the attract mode. :confused:

I'm starting to get a handle on the Xevious disassembly as well. For instance:

The main CPU sends commands to the custom ICs and then handles the responses in the NMI handler.
One of the main routines consists of a 32-entry jump table that is copied into RAM, iterated through in a round-robin schedule. Each routine can execute a RST$30 to replace the jump table entry with the current PC and return - in effect yielding to the main routine.


Next on the list: add the video interrupt, implement the background tilemap layer, and try to work out why un-patching the ROM check is worse...

[tcdev]

Made some progress with the background tilemap. It's almost - but not quite - right. I'm pretty sure the attribute (for both tilemaps) is being latched at the wrong bit offset. But the background is certainly recognisable, despite being entirely the wrong colour. I'm still yet to decypher the colour lookups in the MAME driver... at this point I don't understand how it even uses the 2-bit pixel value! :confused: Definitely easier in some respects to emulate hardware in hardware (firmware/FPGA)! :D

I'll post some eye candy when I get the background looking a little better!

[tcdev]

Did a little more work on it this morning. It's closer, but I'm having trouble deciding whether there is a problem with it now, or not. It's very difficult to ascertain given the colour mapping is completely wrong.

Might be worth trying to fix the colours first...

Anywhere, here's what I see atm...

EDIT: OK, there's definitely a problem with the attribute of 2! columns in each tile...

[roglio]

Great work indeed!!!

Thank you tc.

[tcdev]

I haven't had a lot of opportunity to play with the hardware lately, so I haven't done much with the FPGA implementation.

However, whenever I can catch a few spare minutes I've been plodding through the disassembly (which BTW is available in the repository as PDF files). I haven't found much else that helps with the implementation as such, but I am slowly adding more comments.

Unfortunately, Xevious is one of those examples of heavily data-driven execution, so lots of 'magic addresses' with very little clues as to the true nature of the variables. With plenty of hand-shaking between the 3 CPUs via shared memory variables, it's actually quite a nightmare to decypher. As you'd expect, most of the clues thus far come from what's printed on the screen.

Right now I'm back to the situation where the attract screen goes 'ga-ga' after a second or so, and more often than not, results in a reboot. I'm starting to suspect my less-than-complete 51XX implementation again; it's possible the game is seeing the SERVICE switch toggling which will result in reboots. Alternatively, it could be the SOUND self-tests, which I've yet to actually find in the code!

To this end, I've just added 'credits mode' to the 51XX, although it hasn't been tested at all at this point.

[tcdev]

No exciting progress to report. Mostly because I haven't had much time to spend on it.

I have looked more closely at the disassembly of the SUB2 CPU. I've got a reasonable handle on what it is doing now, even if I don't know all details of the data in the ROM.

Basically, the SUB2 CPU controls the 3-channel NAMCO sound chip, and that is all. After an initial ROM check the handshaking with the MAIN CPU is restricted to a handful of memory locations. And from memory, only 1 (or perhaps 2) locations are read back by the MAIN CPU. The MAIN CPU writes values to a few locations in order to trigger certain sounds being played. I'm not sure of the exact allocation of addresses to sounds, but I think they're used to prioritize sounds, or perhaps interleave them for more voices?

I could probably write some test code, or at least patch the ROM, to get more detail on how the sounds work, and which sound values produce what. But it's perhaps not worth the trouble at this stage...

After the self-check, the SUB2 seems to have very little influence on the execution of the MAIN CPU. I don't think there's any busy-waits, for example. In summary, you could probably patch out the SUB2 ROM check in the MAIN ROM code and remove the SUB2 CPU from the design... something I may attempt to minimise build times in Quartus...

[roglio]

Hi tc, the repository is healty? Do I can synthesize for DE1?

[tcdev]

Hi tc, the repository is healty? Do I can synthesize for DE1?
If you mean Xevious, then yes, the respository will build but unfortunately there's simply no way it'll fit in the DE1 as-is. It's using around 100KB of on-chip memory atm. Parts of it could be moved into flash and SRAM without too much difficulty, but I don't have the time to do that atm. And probably won't get around to it until I've gotten it fully working.

If you mean other projects, then they're mostly broken atm. When I started Xevious I had to add support for 2 tilemap layers and unfortunately that broke pretty much every project. For the most part it wouldn't be hard to fix, but very time-consuming to go through every one.

What exactly did you want to build?

[roglio]

Sorry for late reply... I would just play around with the pace project that run on my trusty DE1.

It's healty now?

[tcdev]

OK, I'm going to have another look at getting Xevious running...

[tcdev]

Meh! This platform is a Royal PITA.

It's not running right now, and I didn't really change anything that could affect the game. Reverting the changes doesn't help either. I do recall it was sporadic, so there's likely a start-up condition and/or RAM content that is causing problems. I hate this type of problem... :(

No doubt I need to re-visit the NAMCO custom IC implementations. I'm only now recalling that the 50XX implementation is actually based on an early MAME functional emulation, not the real thing (it's a CPU/SM of sorts).

Might be easier to move on to 1942 and Vulgus...