MiSTer FPGA Forum

Hi all,

In order to properly implement games like Arkanoid, Arkanoid Tournament, Bubble Bobble and Elevator Action, there will need to be an HDL implementation of the 68705 MCU. I've been researching the history of this MCU in MAME, the trouble people had in dumping the EPROM data from them, and what the difference between Arkanoid and Arkanoid Tournament is. This could also be ported to a small FPGA (paired with an EPROM) to keep physical PCBs going when their ageing MCUs die. Another use would be to support the creation of multi-kits for games like Arkanoid so they can host both Arkanoid & Arkanoid Tournament on the same PCB (I think that'd would excite quite a lot of Arkanoid owners).

So, has anyone started looking at this? I saw that the Arkanoid core didn't tackle the MCU yet and the Bubble Bobble core went with a C++ implementation. I'm about half-way through a VHDL course so I've got quite far to go yet. Any insight into a possible solution would be well received.
Thanks all.

nes4life wrote: ↑Wed May 05, 2021 9:10 pm the Bubble Bobble core went with a C++ implementation.

Can you develop a bit more on that?

Hey Jotego, having the 68705 implemented in C++ running on the ARM side works fine for MiSTer on the DE10-nano, and is likely good-enough for most people to simply enjoy playing the game, but I really want to pursue a pure HDL implementation for FPGA. I'd like the option to create a physical replacement for failing 68705s on real hardware (once a suitably small FPGA is targetted) and i'd like to preserve games as close to the original implementation as possible. I am in no way saying the hybrid approach is inferior but only that i personally want to make something that runs from a pure HDL form.

Would definitely like to talk to you more about FPGA vs CPU implementations, and what your goals are when you create a MiSTer core. I've a feeling this is all very subjective! Cheers.

nes4life wrote: ↑Mon May 10, 2021 12:51 pm Hey Jotego, having the 68705 implemented in C++ running on the ARM side works fine for MiSTer on the DE10-nano, and is likely good-enough for most people to simply enjoy playing the game, but I really want to pursue a pure HDL implementation for FPGA. I'd like the option to create a physical replacement for failing 68705s on real hardware (once a suitably small FPGA is targetted) and i'd like to preserve games as close to the original implementation as possible. I am in no way saying the hybrid approach is inferior but only that i personally want to make something that runs from a pure HDL form.

Would definitely like to talk to you more about FPGA vs CPU implementations, and what your goals are when you create a MiSTer core. I've a feeling this is all very subjective! Cheers.

I think he's confused because no core is running hybrid arm/fpga as of right now.

zakk4223 wrote: ↑Mon May 10, 2021 6:12 pm I think he's confused because no core is running hybrid arm/fpga as of right now.

Hey zakk4223, I guess I am confused as I'm having a hard time understanding how the FPGA is supposed to understand the C++? It's not an HDL so how is it interpreted? Surely that's executing on the ARM side? I'd love to be wrong though; is there some sort of pre-compilation / pre-configuration step that converts it over to configure the FPGA then? I am new to MiSTer development but I didn't think I was that far out with my fundamental understanding of how FPGAs get configured!

I assume you are looking at his jtbubl repo? The only cpp files there are in the documentation directory, which is not part of the built core. As a matter of fact, those are just copies of some mame source code.

If you are talking about something else please link to it.

zakk4223 wrote: ↑Mon May 10, 2021 8:23 pm I assume you are looking at his jtbubl repo? The only cpp files there are in the documentation directory, which is not part of the built core. As a matter of fact, those are just copies of some mame source code.

That's right. I often have source code from emulators in the doc folder for reference, together with schematics, chip datasheets, PCB photos and oscilloscope measurements. Pretty much anything I find relevant to understand the system goes to that folder.

The Bubble Bobble core has a native MCU running inside the FPGA. I think that the MCU implementation isn't perfect and it is making the intro bubbles disappear for some DIP switch settings.

Note that the core is also available for MiST and SiDi, which don't have an ARM processor.

Hey jotego, thanks for the reply. Makes total sense to include all that information in the docs folder. I really should have spent more time going over the implementation rather than giving it just a cursory glance; my apologies. When I get the time I'll go through the MCU FPGA code in the bubble bobble core properly. My secondary objective is to be able to port a 68705 implementation back onto a dedicated and much smaller FPGA / CPLD to keep physical PCBs going when their MCUs finally die. Ideally any modern replacement would take its ROM instructions from a removeable EPROM to make it more accessible & flexible (opening up a path to multi-games on a single board).

I foolishly assumed that some of the MiSTer cores were hybrid FPGA + CPU designs (with undoubtedly some lazy ports from MAME). If this has been avoided then that's really good news as I'm in favour of configuring games as closely to the original implementations as possible.

Hi everyone,
Now I'm revisiting this, I'm looking at how the Arkanoid implementation in MiSTer bypasses the need for the 68705.
My current understanding is that the ROMs are patched by the '.mra' files (negating decryption functions of 68705 and supplying the level lookup table) and the spinner is latched directly to the z80. Is this understanding correct?

I'm guessing this is how boot pcbs were created back in the day without a 68705. So, what I'd really like to do is replicate this on a real Taito PCB if possible. I can patch the eproms as suggested by the 'mra' files, but how do I physically latch the spinner? I can create a drop-in board that goes into the 68705 socket, or mount the Z80 into a child PCB to make new connections and add any supporting TTL.

Finally, is there support for Arkanoid Tournament in MiSTer? It's identical hardware but with different EPROM code and different 68705 code. Shouldn't be too hard to add.

Thanks all

There are multiple versions of Arkanoid ROMS that don't use this MCU. Last I looked when going over what needed to be implemented, there were no "MRA patches".

Everything was done in the program ROM either by the manufacturer or bootleggers. If that were the case, Tokio and Renegade wouldn't be bootleg releases. Only a Bubble Bobble bootleg uses this MCU.

You should just look over mame source. jtbubl isn't the place to go for the m6805 (68705R etc) variant used by Taito.

Anyone working on Elevator Action?