Home Page Forums MAME MAME thread about ARC CPU cores

MCS-51 needs to be reworked to go down to at least S-cycle granularity for serial to work properly. AJR’s talked about doing it at various times. The high-speed pipelined MCS-51 implementations are so radically different I’m not sure you’d be able to get accurate timings for them if you tried building them on the same S-cycle based core as the original Intel implementation.

You could fix the Microprose sound issue without rewriting the MCS-51 code by making a stub device_serial_interface thing to interface between the microcontroller and the UART on the other side. The trouble is, the code in that driver is pretty crusty, so you’d probably end up wanting to do a fair bit of refactoring while you were at it. That’s probably why no-one has done it so far – untangling old code isn’t that much fun.

The MAME CPU cores that need the most work, to put it plainly, are those that haven't been added except as stubs. Lately I've started work on real emulation for Motorola's CPU16 (M68HC16), which is a sort of low-end 16-bit DSP loosely based on M68HC11. As usual, I'm implementing it as an enormous state machine, which was perhaps not the easiest way considering the numerous addressing modes for all of the arithmetic and logical instructions.

For those architectures which have enough of the instruction set emulated in MAME, the problem often becomes the lack of emulation for on-chip peripherals. UARTs are indeed a common omission, and MAME's MCS-51 core indeed particularly suffers from the lack of a proper UART, but they're critical mostly for certain applications that tend to demand them, such as MIDI synthesizers and video display terminals. Many other MCUs and SoCs have UARTs that are used very little (ST2XXX) to not at all (RISC II) in systems that have been dumped.

Timer blocks have been emulated more often in MAME, but a fair number have still yet to be added. KL5C80A12 is still missing one of its two timer blocks, and I plan to add that someday because it's a probable blocker for consolidating the Sammy medal games and running their Flash setup menu from the BIOS (which was formerly simply bypassed but now is hacked to run just enough code to initialize a few critical registers). The Atari CAGE emulation is rather messy right now because a whole bunch of TMS320C31 peripherals lack proper emulation, including the timers. The "PSX" CPU emulation is missing cycle-by-cycle DMA when I last checked, which is a blocker for replacing a whole set of legacy SCSI devices with modern counterparts. The MN1880 emulation I've written is now badly in need of interrupt sources from timers and other on-chip peripherals; it would help a lot if some documentation for that Panasonic MCU family were to turn up with more details on those than the mere summary sheets now available. (If those aren't forthcoming, my best guess would be that some of the timer registers might be similar to those of other Panasonic MCUs from the MN1870 and MN101 families.)

The Motorola DSP56156 that's used in Konami's Polygonet Commanders and Polynet Warriors is *very* close to doing what it should. I ran out of time years ago to finish it off. The code is in a really weird state right now though. I was trying to do some abstractions in 2010 that modern C++ probably do much more easily.

The specific CPU can be a little frustrating working with because the documentation can be off in parts, but there *is* plenty of documentation, a few documentation addendum, and a win16 simulator for it, that can all be referenced. I wrote some python scripts that would exercise the simulator in ways that MAME exercised the core as well. It should be a fun project.

The MAME CPU core is communicating with the main CPU well enough to upload a bunch of 3d model data to the right spots - the dsp56156 just isn't grinding through its calculations yet. (see post here called "Polygonz attack" - https://mameworld.info/ajg/ ). If i remember right, it's getting stuck in a loop because i don't emulate one of the loop instructions right? Hard to recall.

I can try to dig up all the junk I have that would help in its emulation, if you're curious.

Personally, I'm rather interested in getting that core up and running as well. Any junk is appreciated.

The annoying thing about the DSP56156 is that it's more or less completely different from the DSP56001, which is another thing that's completely missing in MAME: Having a DSP56001 core would, at a minimum, allow audio emulation on the SGI Indigo, remove what will eventually be blockers for improving NeXT and Atari Falcon emulation, and potentially make life easier for implementing one of the Digital Video Cartridge variants on the Philips CD-i.