Home Creators Posts Import Register Favorites Logout

Content

The 1943 object (sprite) engine was implemented in a custom chip so it wasn't possible to look inside. However, the pin names are similar to those used in other CAPCOM games so it was pretty much obvious how to hook it up to an already working object engine.

Ghosts'n Goblins is designed for a total of 96 objects (sprites) of which up to 24 may fall in the same horizontal line. With a 6MHz pixel clock and 16 pixels per object you can see how 24*16/6MHz = 64 microseconds, i.e. the horizontal line time.

Initially, when I was developing 1943 I couldn't see the ship cannons. It was one of this despair moments that often occur when developing. Then I decided to break the 96 object rule and let more in. Voilà, ship cannons were in place then. I was able to read more objects from the sprite DMA buffer using the same clock speed of 6MHz. The DMA buffer is a feature CAPCOM games used to copy the object data from main CPU RAM to a different buffer. 6MHz worked for me even with more sprites due to a different implementation of the DMA logic, which could operate in fewer clock cycles than the original. But I didn't change the 24-per-line limitation on the object count.

This month I have been working on Bionic Commando. This game has full schematics available and it follows on the school of previous CAPCOM games. The object engine supports 32 sprites per line and uses an 8MHz clock. Make the math: 32*16/8MHz=64 microseconds. So at 8MHz you can draw 6 extra objects.

With this new information and the impression I sometimes had that I was missing a bullet in 1943 I decided to increase the sprite count in 1943 to 32 per line. I think this is what makes sense.

Please get the new files using the update script for JT cores or directly from the binary repository.

Files

Comments

Manuel Astudillo

These posts are great. I wonder if you could also write posts about the whole process of porting a game, from having the schematics to actually making a working implementation, what tools to use, if you reuse third party components, how do you test, etc. In other words, a kind of tutorial for other people that would also like to start porting arcade games to FPGAs but never dare to start due to lack of the initial knowledge that may just motivate them to start hacking...

John Farnell

I wholeheartedly agree. It was your technical posts (and your great work) that hooked me into becoming a patreon for the first time. I've got several books on FPGA VHDL and digital design that I plan to study in the coming months as I'd like to have a go at creating a core for an old arcade board that's relatively simple (perhaps meaning an early arcade) or possibly replicating one that's already been done. My limited understanding at the moment is that we can use things like the schematics (if available) and MAME roms to help. It seems intuitive that turning schematics into HDL for the FPGA would be something that can be learned. Then there's moving over the rom into the FPGA of course. But it seems there's also a whole lot of less tangible things needed, such as timings, which you'd think were just a mechanic from the schematics. I've seem almost no solid information on a step by step approach to taking and arcade board (or MAME rom) from source through to a core. That would be an amazing resource to help some of us make some headway. Perhaps make it an ebook and sell it too.

JOTEGO

Thank you. Sometimes I hesitate about the technical posts and I give priority to work on the cores. But I think many people enjoy the tech discussion too. So I’ll post more often about these topics then.

Steve Suavek

You're true inspector Columbo of electronics reverse engineering. Respect.