-------------------------
-  HARDWARE  MAME 0.125 -
-------------------------

CPU
SOUND
PROTECTION
INPUT/OUTPUT
OTHER
VIDEO / GRAFIK
ARCADE SYSTEMS
ROM/RAM TYPES
DECLARATION
MEMO

=================================================================================================================================================================================================================================================================================


CPU

  0.    MAME CPU Interface

  1.    Zilog
  1.1   Z80
  1.2   Z80 Versions
  1.3   Compatible/enhanced Z80 CPUs
  1.4   Z8000/Z8002

  2.    MOS-Tech
  2.1   M6502
  2.11  M65C02
  2.12  M65SC02/M65CE02
  2.13  M6509
  2.14  M6510
  2.15  M6510T
  2.16  M4510

  3.    Motorola
  3.1   M6800
  3.2   M6802
  3.3   M6805
  3.4   M6808
  3.5   M6809
  3.6   M68000
  3.61  M68008
  3.62  M68010 / 68010
  3.63  M68020/68EC020
  3.64  M68030
  3.65  M68040
  3.7   DSP56156

  4.    Signetics
  4.1   S2650

  5.    CCPU

  6.    Intel
  6.1   I8035
  6.2   I8039
  6.3   I8X41
  6.4   I8048
  6.5   8080
  6.6   8085A
  6.7   8086
  6.8   8088
  6.9   I80C86/I80C88
  6.10  80186
  6.11  I80188
  6.12  I80286
  6.13  I386
  6.14  I486
  6.15  I960
  6.16  PENTIUM
  6.17  MEDIAGX

  7.    Texas Instruments
  7.1   TMS7000
  7.2   TMS99xx
  7.21  TMS9900
  7.22  TMS9940
  7.23  TMS9980A/TMS9981
  7.24  TMS9995
  7.25  TMS99100
  7.26  TMS99105A
  7.27  TMS99110A
  7.3   TMS32025
  7.4   TMS32026
  7.5   TMS32031
  7.51  TMS32032
  7.6   TMS32051
  7.7   TMS34010
  7.8   TMS34020

  8.    Hitachi
  8.1   HD6309
  8.2   M6803
  8.3   HD63701
  8.31  HD63705
  8.4   HD64180
  8.5   H8/320
  8.6   H8/325
  8.7   H8/3002
  8.8   H8/3007
  8.9   H8/3044
  8.A   H8/3337
  8.B   Z180
  8.C   FD1089
  8.D   FD1094
  8.E   FD1149
  8.F   SH-2 / SH7600 family

  9.    NEC
  9.1   D70008
  9.2   uPD7751 / N7751
  9.3   uPD780C
  9.4   MC8123
  9.5   uPD7807
  9.6   uPD7810
  9.7   V20
  9.71  V30
  9.711 D80000
  9.712 NANAO 08J27291
  9.72  V33
  9.73  V53
  9.74  V60
  9.75  V70
  9.76  V810

 10.    Data East
 10.1   DECO CPU16
 10.2   DECO 45 / HuC6280
 10.3   DECO 59
 10.4   DECO 101 / ARM
 10.5   DECO 102
 10.6   DECO 156
 10.7   ARM7
 10.8   DECO ???
 10.9   DECO 222

 11.    Nintendo
 11.1   N2A03
 11.2   G65C816
 11.3   SPC700
 11.4   DSP-1
 11.5   RSP
 11.6   RCP
 11.7   RDP
 11.8   Minx

 12.    Atari
 12.1   DEC T11
 12.2   ADSP21xx
 12.21  ADSP2100
 12.22  ADSP2101
 12.23  ADSP2104
 12.24  ADSP2105
 12.25  ADSP21062 / SHARC
 12.26  ADSP2112
 12.27  ADSP2115
 12.28  ADSP2181
 12.3   DSP32C
 12.4   ASAP
 12.5   Jaguar GPU
 12.6   Jaguar DSP

 13.    Toshiba
 13.1   TMP8039
 13.2   TMP8085
 13.3   TMP68HC000
 13.31  TMP68301
 13.4   T5182
 13.5   TMPZ84C
 13.6   TLCS-90
 13.61  TMP90841
 13.62  TMP91C640

 14.    KONAMI

 15.    MIPS CPUs
 15.1   x64 dynamic recompiler
 15.2   x86 dynamic recompiler
 15.3   R3000
 15.31  R3560
 15.4   R4300
 15.41  R4600
 15.42  IDT R4650 (little)
 15.43  IDT R4650 (big)
 15.44  R4700
 15.5   R5000
 15.6   RM7000
 15.7   QED5271
 15.8   PSX CPU
 15.81  CXD8661R

 16.    AMD
 16.1   AMD 2901
 16.2   AM29000
 16.3   AM29116
 16.4   AM29323

 17.    Hyperstone
 17.1   E1-16T
 17.2   E1-32N
 17.3   E1-32XT
 17.4   GMS30C2116
 17.5   GMS30C2216
 17.6   GMS30C2132
 17.7   GMS30C2232

 18.    Fujitsu
 18.1   MB86233
 18.2   MB86235

 19.    IBM
 19.1   PowerPC 4xx/6xx
 19.11  PPC403
 19.12  PPC601
 19.13  PPC602
 19.14  PPC603
 19.15  PPC604
 19.16  Konami PowerPC based 3D games
 19.17  PowerPC MMU
 19.18  PowerPC FPU

 20.    SE3208

 21.    Others
 21.1   APEXC
 21.2   GenSync
 21.3   CP1610
 21.31  SSP1610
 21.4   CDP1802
 21.5   Fairchild 3850
 21.6   KABUKI
 21.7   ST0016
 21.8   TS-001-Turbo
 21.9   SCU DSP
 21.A   M7700
 21.A1  M37702
 21.A2  M37710
 21.B   MN1020012
 21.C   CY7C9101
 21.D   SC61860
 21.E   LH5801
 21.F   SM8500
 21.G   Saturn
 21.H   PDP1
 21.J   SSP1601 DSP

 22.    Sound Communication
 22.1   Seibu SEI0100BU
 22.2   Taito TC0140SYT
 22.3   Konami K054986

..................................................................................................................................................................................................................................



0.    MAME CPU Interface

- 0.124u2            : Oliver Stoenberg added the running_machine* parameter to the function passed into cpunum_set_irq_callback() and adds the IRQ_CALLBACK macro for the callback function.
- 0.123u4            : Zsolt Vasvari removed a couple of unused items from the cpuexec_data structure. Zsolt Vasvari moved all video timing logic from cpuexec.c to video.c. Added a  video_screen_register_vbl_cb() function for registering VBLANK callbanks. Changed inptport.c and debugcpu.c to make use the VBLANK callbacks. Added video_screen_get_time_until_vblank_start(). He did some fairly extensive testing, but this is a very signficant internal change, so some things may have broke.
- 0.123u2            : Atari Ace added some missing cores to cpuintrf.c.
- 0.123u1            : Atari Ace improved build independence for CPU/sound cores.
- 0.123              : Aaron Giles fixed regression in cpu_spinuntil* calls that broke a number of games.
- 0.122u8            : Aaron Giles moved cpu_getiloops() and cpu_scalebyfcount() to deprecat.h. Added #include "deprecat.h" where necessary to make this happen. Cleaned up cpuexec.c/.h to latest core style. Aaron Giles removed external access to cycles_currently_ran(). Replaced use of cycles_currently_ran() in v9938 code with mame_rand(), since that is effectively the same thing.
- 0.122u6            : Aaron Giles added CPUINFO_INT_CLOCK_MULTIPLIER to support CPU clock multipliers. Updated all CPU cores to return a CPUINFO_INT_CLOCK_MULTIPLIER of 1. Changed the core to actually respect both CPUINFO_INT_CLOCK_MULTIPLIER and CPUINFO_INT_CLOCK_DIVIDER. Updated a number of drivers to use cpunum_get_clock() instead of Machine->drv->cpu[x].clock. Raw input clock speeds should now be specified for all CPUs in the MACHINE_DRIVER.
- 0.122u5            : Atari Ace added machine and cpunum parameters to INTERRUPT_GEN callbacks. Fixed several places that were not using INTERRUPT_GEN or OPBASE_HANDLER macros.
- 0.121u2            : Aaron Giles deprecated cpu_yield* functions except for cpu_yield() itself, which yields for the current timeslice only. Drivers that relied on the other yielding functions should be updated to use cpu_boost_interleave() instead, as it does not have the same negative side effects on time management.
- 0.118u5            : Atari Ace changed all comparison for CPU and sound chip types to compare against CPU_DUMMY or Sound_DUMMY instead of 0. Also updated usages of sndti_to_sndnum() so that they use sndti_exists() where appropriate.
- 0.118u4            : Aaron Giles added new functions to the memory system to support CPU cores explicitly specifying the access mask on 32-bit and 64-bit data bus systems. This enables the MIPS core to handle SWL/SWR and SDL/SDR without a read/modify/write cycle. Updated the C and DRC MIPS cores to use this new mechanism.
- 0.116u3            : Zsolt Vasvari changed all CPU cores' internal timers to the mame_timer* functions as well as the remaining couple of core files that still used timer_alloc(). After this, none of the emu/* files have any old style timing code left.
- 0.116              : Atari Ace improved independence of CPU and sound core variants in order to make them more properly separated by the existing compile-time flags.
- 0.114u4            : Aaron Giles changed cpu_boost_interleave(), cpu_spinuntil_time(), and cpu_yielduntil_time() to take mame_time parameters instead of doubles. Aaron Giles changed MDRV_CPU_PERIODIC_INT() to take a frequency parameter instead of a time. This is converted internally to a subseconds value.
- 0.113u4            : Now enabling all CPUs by default, which helps ensure that even unused CPUs get updated with core changes, etc. [David Haywood]. Zsolt Vasvari removed now-obsolete old timing routines from cpuexec.
- 0.113              : Zsolt Vasvari removed cpu_gethorzbeampos() and replaced it with calls to video_screen_get_hpos(). Also changed TMS34010 configuration to take a screen number, and changed atarigen_get_hblank() to take a screen number as well.
- 0.104u8            : Nathan Woods added cpunum_set_clock_period(), a variation of cpunum_set_clock() that takes subseconds_t, providing better granularity.
- 0.104u6            : Atari Ace and Aaron Giles reduced global namespace pollution by marking many global functions explicitly static, especially in the CPU cores. Nathan Woods added validity checks to ensure CPU core completeness.
- 0.104u5            : Atari Ace and Aaron Giles cleaned up #include files in CPU/sound cores. CPU cores should generally only need to include cpuintrf.h. Sound cores should generally only need to include sndintrf.h. Aaron also made it a fatal error to request operations on invalid sound/CPU indexes. These have been logged to the error.log in the past, but really need to be cleaned up. Added a new function safe_activecpu_get_pc() that can be used when logging PCs to smartly detect whether or not it is safe to call activecpu_get_pc(). Aaron also changed CPU init/reset callbacks. The init callback now accepts a number of parameters, including the CPU index, the clock, a generic configuration parameter, and a pointer to the IRQ callback. The reset callback no longer takes any parameters (the configuration parameter has been moved to the init callback). And the IRQ_CALLBACK getter/setter has been removed since this is now set up once at initialization time.
- 0.104u2            : Aaron Giles removed scrbitmap and memory_region from the global Machine structure. There is no need for non-core systems to access these directly.
- 0.103u5            : Added src\cpu\cpu.mak.
- 30th January   2006: R. Belmont - A couple of people have recently asked for an introduction to how emulation actually works at a lower level. Introduction: At their lowest level, digital computers run programs that composed ultimately of a stream of numbers (this is called machine language). For a given CPU chip, certain numbers always mean certain things. For instance, on a 6502, the number '105? translates to 'ADC' or Add with Carry. It's important to realize that every time the 6502 encounters instruction 105 it will always perform the same addition operation. You could, in fact, write a valid program composed entirely of instruction 105, although it wouldn't be very interesting. Incidentally, the 3-letter code for the instruction ('ADC' in this case) is what is called assembly language, sometimes abbreviated ASM. Most programs for 8 bit processors were written in this manner - it's somewhat cryptic, but it also gives you full control with minimum size. The number itself is known as an opcode (operation code). Inside the CPU there's hardware to fetch the next instruction number from memory, figure out what it is, and execute it. Now, there's nothing digital hardware can do that digital software can't also do. So emulation starts off with a block of code (a CPU core) which does the same thing for a given type of processor, like a 6502 or Z80. In C-like pseudo-code, it would look something like this: CPU_Start: opcode = fetch_next_opcode(); if (opcode = 105) do_addition_with_carry(); else print 'ERROR: Unknown opcode!'; goto CPU_Start;  . That is remarkably close to how most real CPU cores work, incidentally. The major difference is ususally that a C switch statement is used to efficiently go to the right place for each opcode. Yeah, but where's the wakka-wakka come from? Each CPU has a limited amount of memory it can talk to. For 8 bit CPUs this was usually 64K (65,536 units). This means that each unit of memory has an address (similar to the one on your home) from 0 to 65,535. Some of this memory must be dedicated to the program itself (usually stored in ROMs). Some must be dedicated to a work area for the program (so-called work RAM). But addresses don't have to be just memory - they can also be devices. For instance, in Pac-Man, one set of memory addresses controls the horizontal and vertical positions of Pac-Man. By writing different numbers there, the video hardware will dutifully draw Pac-Man at various places on the screen without further CPU intervention. (This is quite a time-saver for the CPU!) Such special addresses are called registers or sometimes switches. For emulation, this is relatively easy. CPU cores don't want to tie themselves to one machine, so they call out to other code in the emulator (sometimes called the memory manager or memory mapper). To read a memory location, they call out with an address and expect to get an answer back from elsewhere in the emulator. To write a memory location, they call out with the address and the new number to place at that address. Code elsewhere in the emulator figures out for the current game if that address is work RAM, program storage, or something else entirely. The complete set of valid memory addresses for a machine is called a memory map. A simplified real-world example is Pac-Man once again. Addresses 0 to 16,383 are program storage (ROM chips in this case). Addresses 20,464 through 20,479 control the screen positions of Pac-Man and the ghosts. Address 20,480 contains the current status of the joystick. And so on. If you respond properly to all of the necessary addresses you get a running game. That is how basic emulation works.
- 0.102u5            : Nathan Woods changed activecpu_dasm() and activecpu_dasm_new() so that they "function" even if the getinfo handler does not specify CPUINFO_PTR_DISASSEMBLE nor CPUINFO_PTR_DISASSEMBLE_NEW.
- 14th December  2005: Aaron Giles - CPU Scheduling in MAME (part 4): Part 3 of this series discussed the problems involved in scheduling communication from a "later" CPU (one scheduled later in the round-robin order) to an "earlier" CPU. Since the MAME scheduler does not support changing the order of CPU execution within the round-robin, the only options to improve latency are to increase the interleave factor, either globally or temporarily. There are two other means of altering the scheduling of CPUs during execution. These are the cpu_yield() and cpu_spin() calls. Both of these methods have been abused often in the past due to a lack of understanding about how they actually work, so now is the time to set the record straight. What cpu_yield() does is end the current CPU's timeslice early. It does not affect the execution of any other CPUs in the system. Let's look at an example. Again we'll say that CPU #0 is running at 14MHz, and CPU #1 is running at 2MHz. There is a scheduled timer that is set to fire at time 0.000150. So we begin executing CPU #0 for 2100 cycles, but this time, partway through its timeslice (say, 1250 cycles in), one of its read/write handlers calls cpu_yield(). This aborts the current timeslice, leaving CPU #0's local time set to 0.000089286. Now CPU #1 gets its turn to execute. Normally it would have executed for its entire timeslice up to time 0.000150; however, since the previous CPU stopped early, the scheduler only schedules up to the time when the previous CPU stopped execution. This equates to 0.000089286 * 2,000,000 = 179 cycles. Let's say it executes for 180 cycles, giving it a local time of 0.00009. At this point, we tell the timer system that the global time is 0.000089286, but there are no timers ready to fire until 0.000150, so nothing happens, and the round robin begins again, scheduling each CPU to execute until 0.000150. Simple enough; this looks like it is the equivalent of setting an "instant" timer that goes off. Ah, but there is an additional side-effect that is not immediately obvious. cpu_yield() belongs to a class of synchronization calls: cpu_yielduntil_trigger(), cpu_yielduntil_int(), cpu_yielduntil_time(). All of these perform a cpu_yield() but have the additional side effect that the CPU is descheduled until the specified trigger/interrupt/time is signalled. This has some interesting consequences. Let's look at the previous example again, except that instead of calling cpu_yield(), we will call cpu_yielduntil_time(0.00005). This is essentially telling the scheduler to not only give up our timeslice, but remove us from the scheduling equation altogether for the next 50 microseconds. So: CPU #0 executes as before, ending its timeslice early at time 0.000089286 by calling cpu_yielduntil_time(0.00005). This aborts its timeslice and also internally sets a timer to go off at the current local time (0.000089286) plus 0.00005 seconds, or at time 0.000139286. Then CPU #1 executes up to the time when the previous CPU stopped execution, which is time 0.000089286. This is again 179 cycles, so we run the CPU, and it comes back claiming 180 cycles, making its local time now 0.00009. The timer system is called, but nothing is ready to fire, so the round-robin starts over. This time, when we ask the timer system when the next timer is set to go off, it reports 0.000139286, due to the timer that was set in response to cpu_yielduntil_time().
                       Now the round-robin begins again, except that CPU #0 is completely removed from the scheduling, so we skip right to CPU #1. Computing cycles: ((0.000139286 - 0.00009) * 2,000,000) = 99 cycles. We run CPU #1 with that request, and get back 101 cycles, putting its local time at 0.0001405, and the round-robin ends. At this point, the timer set in cpu_yielduntil_time() fires, and it enables CPU #0 to be scheduled for the next round. However, notice that the two CPUs are now signficantly out of sync with respect to each other. CPU #0 is still stuck back at local time 0.000089286, while CPU #1 is already at 0.0001405. There is still a timer set to go off at 0.000150, so that will be used as the target for the next round-robin. For CPU #0, that next pass at execution will run 0.000150 - 0.000089286 = 0.000060714 seconds, or 850 cycles, which is much longer than normal because it needs to execute more cycles to catch up to the target time. CPU #1, on the other hand, is almost at the target time, and only needs to execute 19 cycles to reach the target. So the big side-effect of using cpu_yielduntil_time() in this manner is that you cause the yielding CPU to get behind in the scheduling process. Repeated use of the yield calls can put the CPU farther and farther behind, which can result in some seriously wacky behavior. For example, since CPU #0 is starting out at a time significantly behind CPU #1, if it sets a timer, that timer could already be in the past relative to CPU #1. Analagous to the cpu_yield() calls are the cpu_spin() calls. These calls operate exactly the same as their partners, except that the local time for a spinning CPU is automatically bumped to the current global time at the end of each timeslice. This means that the CPU doesn't get behind; rather, it effectively "burns" all of the remaining cycles in a way that the spinning CPU will never get them back. The thing that is confusing to people is this: Yielding is a form of synchronization. Spinning is a hack. Even though they look similar, they are used for two very different purposes. There is really only one legitimate reason for spinning, and that is for adding spin loop optimizations to games that are doing no useful work while waiting for some event. If the event happens at some known time in the future, use cpu_spinuntil_time(). If that event is an interrupt, use cpu_spinuntil_int(). If that event is some other externally-driver factor, use cpu_spinuntil_trigger(), and then call cpu_trigger() when the event occurs. If you find yourself using a cpu_spin() call for synchronization, you are masking some other problem in the emulation system. Finally, a word about triggers. Triggers are simply a signalling mechanism that is used to indicate that a particular event has occurred. A trigger is identified by an integer, which is essentially a random number that is chosen by the person creating/using the trigger. There is no collision detection or means of allocating them (though there probably should be). To signal a trigger, you simply call cpu_trigger() with the trigger identifier. Triggers are mostly used in conjunction with the yield and spin calls to block execution of a CPU until the trigger is signalled. It's really no more complicated than that.
- 12th December  2005: Aaron Giles - CPU Scheduling in MAME (part 3): Part 2 of this article discussed the cooperation between the scheduler and timers that enables events to be synchronized between multiple CPUs. In short, when a CPU needs to signal an event to another CPU, it sets an "instant" timer which causes all CPUs to execute up to that point in time. Then, the timer callback is fired and the event can be signalled safely and accurately. The big problem with this approach is that it really only works well if the target CPU has a local time that is less than the current time. The example we looked at last time had CPU #0 signalling an interrupt to CPU #1. Since the round-robin ordering causes CPU #0 to execute first, we were (pretty much) guaranteed that when CPU #0 wanted to issue its signal, its local time would be greater than the local time of CPU #1. But what happens when CPU #1 wants to send a signal back to CPU #0? Taking the naive approach, and returning back to our previous example, let's say that we have CPU #0 running at 14MHz, and CPU #1 running at 2MHz. There is a scheduled timer that is set to fire in 150usecs, or at time 0.000150. So we begin executing CPU #0 for 2100 cycles, and it completes its timeslice normally, returning 2112 cycles, meaning its local time ends up being 0.000150857. Now we execute CPU #1 for its timeslice, which turns out to be 300 cycles as in the example from Part 1. However, this time, at 50 cycles into execution, CPU #1 decides that it needs to send a signal to CPU #0. So, rather than sending the signal immediately, it sets an instant timer to go off immediately, at time = 50 / 2,000,000 = 0.000025. This also has the side effect of aborting the execution of CPU #1 and ending the current round robin. So, at this point, the scheduler contacts the timer system and indicates that the global time should be updated to the minimum of all the CPUs' local times, which would be 0.000025. The timer system sees that there is a timer scheduled to go off at 0.000025, and fires it; in the callback, we send our signal to CPU #0. But wait, isn't CPU #0's local time already way off in the future at 0.000150857? Yep. This means that the signal arrives much later that it should have (0.000150857 - 0.000025 = 0.000125857 seconds, or 1762 CPU cycles too late), and we have lost our synchronization. How do we solve this problem? Well, we could have swapped the execution order, making the scheduler execute CPU #1 first. But in order to do that, we would have needed to predict the future once again. If the communication details between two CPUs are well-understood and follow strict rules, then it might be possible to make this sort of fine-grain scheduler tweaking work. Up to now, however, there has not been a good case made for running out-of-order like this. And so the round-robin order remains fixed. Traditionally in MAME - in fact, even before I ever wrote the timer system and the scheduler -
                       the way this sort of communication issue was resolved was to increase the interleave factor between CPUs. The interleave factor was a number that indicated how frequently the CPUs in MAME were configured to re-synchronize their execution times each video frame. (This was specified in terms of video frames originally because all timing in MAME was done relative to video frames before the timers existed). The interleave factor is specified globally in MAME's machine driver structure. It is implemented by computing how many times per second the synchronization is implied (for example, an interleave of 100 with a game that runs at 60Hz, would imply 6000 synchronizations per second), and simply setting a timer with a NULL callback to go off at that rate. No callback is needed because no action needs to be performed; rather, the mere existence of the timer firing at that rate effectively brings all CPU into sync at that frequency. Back to our example, let's say our game runs at a 60Hz frame rate, and we bump the interleave factor to 500. That will ensure for us 500 * 60 = 30,000 synchronizations per second, or once every 0.000033333 seconds. This means that there will be a timer set to fire every 0.000033333 like clockwork. So let's re-evaluate what happens and why the interleave improves things. Remember that the timer system figures out when the first timer is set to fire. Previously, our first timer was going to go off at 0.000150, but now we have this interleave timer which is going to go off even earlier at 0.000033333, so that determines what our first timeslice will be. Taking 0.000033333 * 14,000,000 gives us 467 cycles, so we execute CPU #0 for 467 cycles. Let's say it comes back having executed 470 cycles. That puts our local time at 0.000033571. Now we execute CPU #1 for its timeslice, which turns out to be 67 cycles with the new timer in place. Again, at 50 cycles into execution, CPU #1 decides that it needs to send a signal to CPU #0. So we set an instant timer to go off immediately, at time = 0.000025. This ends the round robin, and the timer system is notified just as before. This time, however, CPU #0 receives the signal at 0.000033571, which is only 0.000008571 seconds or 120 CPU cycles too late. This is a big improvement over 1762 cycles, but it's still not perfect. By increasing the interleave we could make it even better if we wanted. In fact, the interleave factor effectively determines the worst case latency for a signal from one CPU to another. Could we make it perfect? Well, actually, we could. If we set up a timer to run at a frequency of 2,000,000 times per second (the clock speed of the 2nd fastest CPU), then we would get as close as possible to perfect interleave. CPU #0 would never execute longer than a single clock on CPU #1, so when CPU #1 sent a signal, it would hit CPU #0 at the same time as the end of that particular clock cycle on CPU #1. To set the interleave that high
                       would require specifying an interleave of 33333 in the game's machine driver. Try it sometime. Things get very very slow. This is because a context switch between two CPUs is not free, and when you try to set up a timer to run that frequently, you spend all your time context switching and very little time actually executing any code on the CPUs. The ideal solution to this is to detect when it is likely that CPU #1 needs to signal CPU #0, and temporarily boost the interleave so that, at least for a while, synchronization is guaranteed. This is the purpose of the cpu_boost_interleave call. It takes two parameters. The first parameter is how frequently the timer should fire - note that it is not specified in terms of video frames, but rather as an absolute time. You can also pass 0 here, which causes the system to automatically pick the clock rate of the 2nd fastest CPU, which will give you ideal synchronization. The second parameter specifies how long, in seconds, you want to maintain this level of interleave. Generally, you don't want it on too long. Most commonly, games in MAME are set up so that "master" CPUs are run first, and communication tends to go from earlier CPUs to later ones in the round-robin order. Interleave boosting is used in these cases when the "slave" CPUs need to send some information back, and the master is sitting there waiting for a response. Keep in mind that none of these systems are perfect, yet they have been successfully used for many thousands of different platforms.
-  9th December  2005: Aaron Giles - CPU Scheduling in MAME (part 2): Part 1 described the basic round robin scheduling algorithm used by MAME when running multiple CPUs. It can be summarized as: 1. Determine when the next timer is going to fire. 2. Loop over each CPU: Compute the difference between this time and the CPU's local time, execute for at least that long and count up the cycles executed and compute the CPU's local time. 3. Return to step 1. Now this is all fine and great when you can predict the future - notice that step 1 requires you to do just that. And many events in MAME are in fact periodic and predictable in nature, so this works out ok as a starting point. One very common event that isn't predictable, however, is communication between two CPUs. In fact, this is one of the main reasons I added the timer system to MAME in the first place. Let's look at an example of what can go wrong with CPU communication when there is no synchronization. Going back to our previous example, we have CPU #0 running at 14MHz, and CPU #1 running at 2MHz. We also know there is a timer that is going to fire in 150usecs, or at time 0.000150. So we begin executing CPU #0 for 2100 cycles. This time, however, the code executing on CPU #0 decides to signal an interrupt to CPU #1 at a point 1500 cycles into its execution (at time = 1500 / 14,000,000 = 0.000107143). With no synchronization, the interrupt is signalled (generally some state is set in CPU #1's context indicating that an interrupt is pending), and CPU #0 continues executing until the end of its timeslice. When it's done, it has executed 2112 cycles like before, and its local time is 0.000150857. Now it's time to execute CPU #1 for the first time. Right away, however, it notices that it has an interrupt pending, so it may process the interrupt, and then continue executing for the rest of its timeslice normally. So what's the problem? Well, CPU #0 signalled the interrupt at local time = 0.000107143, but CPU #1 acted on the interrupt at local time = 0 (right at the start of its timeslice). Let's say CPU #1 is a sound CPU; maybe the music started just a fraction of a second too early as a result. Worse, let's say CPU #1 was busy doing something else and wasn't ready to handle the interrupt just then. Maybe you've crashed the code or altered its state in a bad way. What might not be immediately obvious in looking at the timer system is that most of the timers that are created are set to fire instantly. If you've even seen timer_set(TIME_NOW, ...) in MAME, you've seen a request for a instant timer. This is done because timers are effectively synchronization barriers. The whole scheduling algorithm is based upon executing all the CPUs until the time when the next timer is set to fire. Setting up an instant timer is essentially asking the scheduler and the timer system to work together to bring all the CPUs up to the current instant in time before calling the function you provide it.
                       How does this help the interrupt signalling issue described above? Let's say that when CPU #0 decides to signal an interrupt to CPU #1, it doesn't signal it immediately. Rather, it sets an instant timer to go off. Since the current time = 0.000107143, that is when the timer is scheduled to fire. But timers don't fire until the end of the round robin sequence, and then only after all CPUs have reached that time. So even if we were at the end of the round robin, it still wouldn't be able to fire just yet because CPU #1 is still sitting back at time = 0. We have another issue here as well. CPU #0 has just set a timer to go off at time = 0.000107143, but it also still has 600 cycles left to execute before the end of its timeslice. We could potentially allow it to complete its run, ending up at time = 0.000150857. But then when we executed CPU #1, we would only execute up until the time the timer was set to go off (at 0.000107143), and the two CPUs would be significantly out of sync. Rather than letting that happen, whenever a new timer is created during a timeslice, and it is scheduled to fire before that timeslice is up, the timer system and the scheduler work together to abort the execution of that CPU. Generally, this means that the CPU will stop executing at the end of the current instruction, and return control back to the scheduler. In this case, since CPU #0 set the timer during its timeslice, and since the timer is scheduled to fire during the timeslice, execution on CPU #0 is aborted with 600 cycles left to go. The scheduler knows that CPU #0 only executed 1500 of its requested 2100 cycles, and updates the local time of CPU #0 to be 1500 / 14,000,000 = 0.000107143. Now CPU #1 gets its chance to execute. 0.000107143 * 2,000,000 = 215 cycles, so we execute CPU #1 for that long. When it is finished, maybe it actually executed 217 cycles, so its local time is 0.0001085. The global time is updated to the minimum of the CPU times, in this case 0.000107143, and the timer system is asked to process timers. At this point, the callback for the instant timer we set is called, and in that callback is where we signal the interrupt to CPU #1. Returning to the scheduler, we look into the future and see that there is still a timer set to go off at time = 0.000150, so we compute cycles for CPU #0 (600) and execute. After CPU #0 is done, we switch to CPU #1 and start executing. CPU #1 now has an interrupt pending, but it has been signalled at the correct local time (or close to it, at 0.0001085), and synchronization between the two CPUs has been achieved. What happens when CPU #1 tries to talk back to CPU #0? Find out in part 3, which will deal with this complex issue.
-  7th December  2005: Aaron Giles - CPU Scheduling in MAME (part 1): Multi-CPU games in MAME are scheduled in a round-robin fashion. The order of the round robin execution is strictly defined by the order of the CPUs in the machine driver. There is no way to alter this order; however, you can affect the scheduling by suspending CPUs or adjusting the granularity of the scheduling. That kind of stuff will be discussed more in part 2. The scheduler relies on the timer system, which knows when the next timer is scheduled. All scheduling happens between firings of timers. Similarly, timers are never fired while a CPU is executing. This important to keep in mind. The scheduler queries the timer system to find out when the next timer is set to fire. It then loops over each CPU, computes how many cycles that CPU needs to execute to reach that time, and runs the CPU for that many cycles. When the CPU is finished executing, it returns how many cycles it actually executed. This information is accumulated and converted back into a "local CPU time", in order to account for overshooting or early exiting from the CPU core. For example... Let's say that CPU #0 is running at 14MHz, and CPU #1 is running at 2MHz. Let's also say that we're starting at time 0 (local CPU time for both CPUs is 0), and a timer is scheduled to go off in 150 microseconds (time = 0.000150). The round robin logic will start with CPU #0 and compute how many cycles it needs to execute to reach 0.000150. Since we're starting from time 0, we need to execute for at least 150usec. 0.000150 * 14,000,000 = 2100 cycles. It then calls that CPU's execute function with 2100 cycles; when the execute function returns, it specifies how many cycles it actually ran. Let's say it returns saying that it ran 2112 cycles. (CPU cores generally overshoot because many instructions take more than 1 cycle each to execute.) 2112 cycles puts the local CPU time for CPU #0 at 0.000150857 (2112 / 14,000,000). Now it's time for CPU #1 to execute. 0.000150 * 2,000,000 = 300 cycles. So we call execute(300), and get back 300 cycles. CPU #1 local time is now 0.000150. At this point, both CPUs have executed, and both their local times are greater than or equal to the target time 0.000150.
                       So the scheduler calls the timer system to let it process the timers. When finished, it again asks when the next timer will fire. Let's say it's set to fire exactly 150usec later at time = 0.000300. Back to the scheduler, we start the round robin over again. CPU #0 needs to execute (0.000300 - 0.000150857) * 14,000,000 = 2088 cycles to reach a local time of 0.300. Note that we took into account the extra cycles that we executed last time. So we call execute(2088), and we get back, say, 2091. That puts our local time at 0.000150857 + 0.000149357 = 0.000300214. Now it's CPU #1's turn. (0.000300 - 0.000150) * 2,000,000 = 300 cycles again. Calling execute(300), we get back 302 cycles. This puts CPU #1's local time at 0.000150 + 0.000151 = 0.000301. Again, both CPUs have executed, both their local times are greater than or equal to 0.000300, so we contact the timer system to let it run its timers. This procedure continues throughout the execution of the system. Some things to note here. After the first round robin, CPU #0's local time was slightly ahead of CPU #1's local time. After the second pass, the opposite was true. Thus, you can't be guaranteed at any time that any given CPU is ahead of or behind the others. Also, be sure to keep in mind that each CPU has its own local time. The timer system also has a "global time". The global time is generally the minimum of all the CPU local times. Which time is used when calling the timer system depends entirely upon which CPU context is currently active. If a CPU context is active (generally true only while a CPU is executing; for example, in read/write callbacks), then all timer operations treat the "current time" as the CPU local time, accounting for all cycles that have been executed on that CPU so far in the current timeslice. If a CPU context is not active (all other times; for example, in timer callbacks), then the "current time" is the global time. The global time is updated at the end of each timeslice before the scheduler calls into the timer system to let it run its timers, and that global time is used to dispatch the timers.
- 0.101u3            : Aaron Giles changed the way encrypted CPU memory is allocated and managed. Previously, memory_set_opcode_base() was used to set a single pointer to the decrypted opcodes; however this presented a number of limitations. Now that all RAM and ROM-like regions are assigned banks, the memory system now tracks decrypted opcodes per bank. For implicit banks (marked RAM or ROM in the memory map), a new function memory_set_decrypted_region() configures which areas of the address space contain decrypted opcodes and where the decrypted opcodes live. For explicit banks, there is a new function memory_configure_bank_decrypted() which operates identically to memory_configure_bank() but specifies a pointer to the decrypted opcodes on a per-bank basis. Updated all drivers using the old mechanism to the new mechanism and removed the old system.
- 0.101u2            : Aaron Giles added support for logical mapping to the CPU interfaces and debugger. CPUs that have an MMU now need to support several new interface bits, including a logical address mask and page size for each address space, as well as a new translate function. There is also a new disassembler interface that should be used going forward, which will make it much simpler to keep the disassemblers standalone and not dependent on MAME functions for opcode accesses. Converted the i386 core to use the new interfaces.
- 0.95               : CPUs tagged as audio CPUs are no longer disabled when sound is turned off [Aaron Giles].
- 0.94u2             : cpuintrf.c cleanup [Aaron Giles].
- 0.81u7             : Ville Linde adds a check enabled when MAME_DEBUG is defined that raises an error if the CPU core executed a negative cycle count in cpuexec.c.
- 0.80               : Nathan Woods introduces cpu_getscanlinetime_mt() and cpu_getscanlineperiod_mt(); variants on their namesake calls except they return mame_time instead of double (src/cpuexec.c).
- 0.79u3             : Nathan Woods added a new consistency check on CPUs to check for the existence of certain get_info cases needed for debugging. This consistency check is currently only enabled for MESS (src/mame.c).
- 0.79u2             : CPU specific memory map fix [Aaron Giles]. Nathan Woods fixed the CP1610 core cpuintrf.c and the declaration of activecpu_set_irq_callback().
- 0.79u1             : Support for CPU-specific internal memory maps [Aaron Giles].
- 0.78u4             : Address spaces are now determined dynamically based on whether a given CPU returns a non-zero value for the address bus width for a given space [Aaron Giles].
- 0.78u3             : smf fixed cpuintrf compile bug with DJGPP.
-  8th January   2004: smf sent in a small fix for compiling cpuintrf.c in DJGPP.
- 0.76u2             : Aaron Giles added new function: activecpu_eat_cycles(cycles), needed for idle skipping in certain situations.
- 0.75               : Nathan Woods added a call cpuintrf_set_dasm_override() that gives drivers the ability to customize disassemblies.  This probably isn't very useful for MAME, but it is useful for MESS for things like software interrupts used for BIOS calls. Aaron Giles changed scanline timing to use floor() to get consistent results and fixed bug in time computation if requesting a scanline in the next frame.
- 0.58               : Added src\cpuint.c.
- 29th August    2001: Aaron Giles sent another CPU interface cleanup update, removing redundant code and improving the interface.
- 0.54               : Added src\cpuexec.c. Aaron Giles made major changes to the CPU interface. As a result of this, some games are temporarily broken, most notably CPS2.
- 22nd August    2001: Aaron Giles started cleaning up the CPU interface and fixing obscure bugs in it.
- 14th November  2000: Aaron Giles fixed a bug in CPU interface that caused suspended CPUs to never get released.
- 0.37b5             : New functions in cpuintrf.c: cpu_get/set_cycle_table(), cpu_set_irq_callback() + New CPU cores and fixes to old ones [Juergen Buchmueller].
- 20th July      2000: Juergen Buchmueller submitted some new functionality to the CPU interfaces.
- 0.36               : Juergen Buchmueller added cpu overclocking control to the on screen display (available only when cheats are enabled).
- 0.36RC1            : Lots of CPU fixes and cleanup [Juergen Buchmueller].
- 0.36b12            : Juergen Buchmueller added cpu overclocking control to the on screen display.
- 0.35b7             : Major overhaul to the cpu cores [Juergen Buchmueller].
- 0.35b6             : Major changes to the whole CPU interface and cores [Juergen Buchmueller].
-  2nd March     1999: Eric Hustvedt updated the CPU interface, resulting in a little speed boost.
- 0.30               : Aaron Giles redesigned cpuintrf.c to be more modular and readable.
- 0.29               : Moved the memory code from cpuintrf.c to memory.c.
- 0.27               : New support functions in cpuintrf.c: cpu_getfcount(), which returns the number of CPU cycles till the end of the current video frame (as opposed to cpu_geticount(), which  returns the number of CPU cycles till the next call of the interrupt handler) cpu_getiloops(), which returns the number of times the interrupt handler will be called before the end of the video frame (useful in interrupt handlers). cpu_gettotalcycles(), which returns the total number of CPU cycles passed since the CPU was reset. ignore_interrupt(), companion to interrupt() and nmi_interrupt(). This allows interrupt handlers to be cpu-independant, avoiding use of CPU-specific interrupt indetifiers.
- 0.22               : Changed CPUIntrf regarding readmem/writemem optimizations.
- 0.21               : Added M6809 CPU support. Changes in cpuintrf.c and driver.h to accommodate the new CPU. The first driver working on this CPU is Super Pac Man. The driver is based on the super-detailed KEG file of Replay emulator by Kevin Brisley.
- 0.16               : Nicola finally took the time to change Z80.h/M6502.h to make them work together. This allowed me to remove some kludges in cpuintrf.c. I also added some new functions, which can be used regardless of the CPU type: cpu_getpc(), cpu_geticount(), cpu_seticount().
- 0.12               : Multiple CPU support. All you have to do to setup multiple CPUs is add entries to the cpu[] array in the MachineDriver definition. Each CPU can have different type (currently Z80 and M6502 are supported), clock, address space, memory/IO port hook, interrupt handlers, number of interrupts per video frame.




1.    Zilog

1.1   Z80

- 0.123u4            : Changed Z80DMA to new device interface, updated mario.c and dkong.c to use new interface. Illustrates how to keep existing memory read/write handlers. This is slower than caching the device interface, but does not have an impact on devices accessed at a low frequency like in this case [Couriersud].
- 0.123u3            : One-line fix for the Z80PIO. At the moment when the interrupt control word is sent (with interrupts enabled), an interrupt occurs. In reality, interrupts are disabled until the interrupt mask byte is sent [Robert].
- 0.122u4            : Added machine\z80dma.c/h. Added Z80 DMA chip [Couriersud]: Only implements intelligence to emulate dkong3. Fixed a misleading comment in 8257dma.h.
- 0.122u2            : Barry Rodewald removed the increasing of the R register from each IX/IY related (FD xx or DD xx) instruction on the Z80. According to documentation and the behavior of the Amstrad CPC driver, this is incorrect.
- 0.114u3            : Removed cpu\z80\z80dasm.h.
- 0.111u5            : Aaron Giles rewroted Z80 interrupt handling to avoid a bad bug in the post-EI interrupt signalling.
- 0.111u4            : Aaron Giles fixed several bugs and improved emulation of the Z80 SIO chip.
- 0.105u1            : Fixed the Z80 PIO code to prevent an interrupt to occur between the PIO_OP_MODE byte and mask which follows. According to the datasheet, this is not permitted in hardware [Robert].
- 0.104u1            : Added machine\z80ctc.c, z80pio.c and z80sio.c. Removed machine\z80fmly.c. Aaron Giles separated various Z80 peripherals (CTC, PIO) into separate modules. Added SIO module, hooked it up to NFL Football. Still no visible progress.
- 0.104              : Nicola Salmoria and Aaron Giles made 8-bit A,B,C,D,E,H and L registers available in the Z80 debugger.
- 0.101u2            : Frank Palazzolo fixed Z80 behavior on cold versus warm reset.
- 0.98u3             : Aaron Giles added step in/out support to the Z80 disassembler.
- 0.98u2             : Added cpu\z80\z80daisy.c. Aaron Giles rewroted the Z80/Z180 daisy chaining logic to work a little closer to the hardware. Updated the Z80 CTC and PIO modules to support the new model. Changed the CTC module to not generate interrupts if there is an outstanding request on the same timer is currently in service; this allows Journey to (finally) run with the correct CPU speed.
-  2nd July      2005: Dave Widel - Did some tests to see how accurate mame is for initializing the z80. Long story short mame's only getting 2 registers right, PC and I. So far I've tried 5 different z80's with the same results. AF,BC,DE,HL,IX,IY,SP,AF',BC',DE',HL',R are all initialized incorrectly. Technically I guess I'm not sure about R, it's either initialized or used incorrectly. The upper right is the registers at boot (see screenshot). It should be full of garbage. except for RI which should be 1300. Lower right is after filling all regs with FF and resetting. It should be all FF except RI=1300. Lower left is all 00 except R=13. The z80's tested were 2 Zilogs, 1 SGS, 1 Sharp, 1 NEC. Z80's don't work correctly when booted they have to be reset so when I say booted, I'm assuming it's after the first reset. I don't know what the values are at boot. I would guess none of the registers including the pc are set at boot.
- 0.89u4             : Juergen Buchmueller cleaned up z80 core, removing the optional inexact emulation mode and the leading underscores from macro names to comply with C99 naming conventions.
- 0.82u1             : Juergen Buchmueller fixed Z80 RETN / RETI cycle counts.
- 0.79u2             : Nathan Woods patched the Z80 CPU core to set the Z80 cycle tables to their defaults on startup. This removes any need for drivers to reset the Z80 cycle tables back to their defaults on exit.
- 0.77u3             : Nathan Woods added osd_die() function; a friendlier way to die in some unexpected fatal way than exit(-1) or [shudder] raise(SIGABRT).
- 0.77u2             : Found the way the OTIR/INIR instructions affect the PF flag and removed the Z80 look-up tables [Ramsoft, Sean Young].
- 0.77               : Removed cpu\z80\z80daa.h. Sean Young and Stefano improved Z80 DAA emulation allowing removal of look-up table (cpu\z80\z80daa.h). Credit for the Z80 DAA emulation improvement goes to 'Ramsoft' ( http://www.ramsoft.bbk.org/).
-  8th December  2002: Barry Rodewald submitted a bug fix for resetting the Z80 in the CPS-2 driver, and smf improved the fix.
-  4th January   2002: Andrea Mazzoleni partially fixed a bug in compiling the Z80 CPU core with GCC 3.0.x.
- 18th April     2001: Sean Young adjusted the Z80 core to work better with MSX emulation.
- 15th April     2001: Sean Young fixed some more undocumented flags in the Z80 CPU core.
- 27th March     2001: Olivier Galibert fixed multi-z80 games that were broken because of a bug in the save state routines.
- 14th November  2000: Sean Young submitted some bug fixes for Z80's undocumented opcodes.
- 29th July      2000: Juergen Buchmueller fixed the Z80 problems in Brute Force.
-  9th May       2000: Juergen Buchmueller fixed some Z80 core bugs.
-  4th February  2000: Juergen Buchmueller fixed a Z80 bug with banked memory.
- 10th January   2000: Juergen Buchmueller sent in a new version of his Z80 core with yet more fixes to the timing.
- 30th December  1999: Aaron Giles fixed some compilation bugs and removed a minor Z80-related kludge from Tapper and Timber.
- 24th December  1999: Juergen Buchmueller made the Z80 cycle counting even more exact, but it still isn't perfect. Together with his another fix to some other Z80 problems they seem to fix Tehkan World Cup from losing its sound.
- 0.36b7             : Some improvements to the Z80 emulator [Juergen Buchmueller].
- 13th October   1999: Juergen Buchmueller sent in another Z80 update.
-  5th October   1999: Juergen Buchmueller sent in another Z80 update with better emulation of the undocumented opcodes.
-  3rd October   1999: Juergen Buchmueller sent in a new version of the Z80 core with more undocumented opcodes added.
- 29th September 1999: Michael Soderstrom fixed a Z80 bug affecting the usage of BIG_FLAGS_ARRAY.
-  9th May       1999: Juergen Buchmueller fixed a Z80 bug involving interrupt flipflops.
- 14th April     1999: Juergen Buchmueller fixed a Z80 bug which affected Astrocade emulation (on the MESS side).
- 13th April     1999: Jürgen has modified the Z80 core to understand more than 64kB of memory.
- 11th April     1999: Nicola fixed Puzzle De Pon z80 error.
-  1st April     1999: Nicola fixed some bug with cycle skipping and Z80
-  8th March     1999: Juergen Buchmueller improved the Z80 core (regulus & starjack work again).
-  2nd March     1999: Brad Oliver fixed problems of the C Z80 core on Mac
-  1st March     1999: Juergen Buchmueller has fixed a RETN opcode bug in the Z80 core.
- 0.35b3             : [DOS] X86 asm Z80 core [Juergen Buchmueller].
- 27th February  1999: Jürgen has made the z80 code faster with memory accesses.
- 12th February  1999: Juergen Buchmueller has made the ASM Z80 core even better. Speed improvements range from 25% (Galaga) to 45% (Tapper). It's still far from complete, and daisy-chaining doesn't work.
-  6th February  1999: Juergen Buchmueller has made a preliminary x86 assembler Z80 core for MAME. Currently not many games work, but it shows an enhancement of about 20% in the speed.
- 0.35b1             : New Z80 emulator [Juergen Buchmueller].
- 0.34               : Juergen Buchmueller fixed bug in the Z80 emulator which caused crashes in Tapper and Tron.
- 0.34b2             : Frank Palazzolo fixed bug in the Z80 block I/O instructions (INI, IND, INIR, INDR, OUTI, OUTD, OTIR, and OTDR).
- 0.33b1             : Juergen Buchmueller added support for undocumented Z80 opcodes to the C Z80 core.
- 0.31               : Tatsuyuki Satoh added support for Z80 daisy chain interrupts.
- 0.29               : Aligned to version 1.2 of Marcel de Kogel's Z80 emulator. New memory handling functions, about 10%-30% faster than before. Moved the memory code from cpuintrf.c to memory.c. Banked ROMs can now be handled in a cleaner and faster way. Use the new MRA_BANK1... types in the memory handler arrays, and cpu_setbank() to set the current bank. The Z80 and M6809 emulators natively support bank switching.
- 0.27               : Source: Tatsuyuki Satoh added Z80PIO and Z80CTC emulator, in COMMON.C
- 0.21               : Source: Nicola introduced changes to the Z80 emulator code that intercept some sorts of tight loop used during an interrupt waitstate. Normal games should not be affected, while Galaga and 1942 are now very fast!!
- 0.16               : Source: Nicola finally took the time to change Z80.h/M6502.h to make them work together. This allowed me to remove some kludges in cpuintrf.c. I also added some new functions, which can be used regardless of the CPU type: cpu_getpc(), cpu_geticount(), cpu_seticount().
- 0.12               : Source: Multiple CPU support. All you have to do to setup multiple CPUs is add entries to the cpu[] array in the MachineDriver definition. Each CPU can have different type (currently Z80 and M6502 are supported), clock, address space, memory/IO port hook, interrupt handlers, number of interrupts per video frame. Sometimes interrupt requests happen while interrupts are disabled. Until now I just ignored them, but some games need them to be processed as soon as interrupts are reenabled. Rally X is an example of such a game. The Z80 engine has provision to do that, but it would make writing a driver more complex (need to find the interrupt acknowledge register) so I slightly modified the engine to automatically cache an interrupt request and execute it as soon as interrupts are enabled.
- 0.04               : Use version 1.1 of Z80Em by Marcel de Kogel. Faster! (note that I had to make a couple of changes to Z80.c to make Crazy Climber work).
- 0.01               : Z80Em Portable Zilog Z80 Emulator Copyright (C) Marcel de Kogel 1996,1997.


1.2   Z80 Versions

      Z80 Familie

      Z80A CPU   = Z0840004 PSC  DIL-40
      Z80B CPU   = Z0840006 PSC  DIL-40
      Z80A CTC   = Z0843004 PSC  DIL-40    CTC = Counter Timer Controller;  Z8430, DIP28 (Pipeline)
      Z80B CTC   = Z0843006 PSC  DIL-40
      Z80A PIO   = Z0842004 PSC  DIL-40
      Z80B PIO   = Z0842006 PSC  DIL-40
      Z80A SIO-0 = Z0844004 PSC  DIL-40
      Z80B SIO-0 = Z0844006 PSC  DIL-40
      Z80A DART  = Z0847004 PSC  DIL-40
      Z8530 AB1  = Z0847006 PSC  DIL-40


      ZiLOG Data-Communictions

      Z85230  DIL-40
      Z85C30  DIL-40     PCB: F15se



      Enhanced Z80 Microprocessors

      Z84C00  CPU     DIL-40     6/10Mhz
      Z84C20  PIO     DIL-40       10Mhz
      Z84C30  CTC     DIL-40        6Mhz
      Z84C40  SIO-0   DIL-40       10Mhz
      Z84C90  KIO     PLCC-84      10Mhz


- 0.120              : Andrew Gardner and Justin Kerk hooked up the KL5C80 communications CPU to the HNG64 BIOS and emulated some of its features.
- 0.119u4            : Removed cpu\z80gb\daa_tab.h. Bug fixes for the Z80GB cpu core [Wilbert Pol]: Fixed cycle count for taking an interrupt. Fixed cycle count for BIT X,(HL) instructions. Fixed flags in RRCA instruction. Fixed DAA instruction. Fixed flags in ADD SP,n8 instruction. Fixed flags in LD HL,SP+n8 instruction.
- 0.116u4            : Wilbert Pol simplified interrupt handling in the Z80GB core.
- 0.111u6            : Nathan Woods and Wilbert Pol incorporated changes to MESS CPU cores to fix asserts and improve Z80GB emulation.
- 0.111u2            : Added Z80 GameBoy CPU(cpu\z80gb\z80gb.c) [Wilbert Pol]. The GameBoy version differs from the Z80 in many ways.
- 0.100u4            : Aaron Giles added save state support to the Z80 CTC system.
- 0.37b14            : Removed cpu\z80gb\z80gb.c, z80gbd.c and daa_tab.h.
- 16th July      1999: Mathis Rosenhauer sent in a Cosmic Chasm driver with much better Z80CTC sound.
- 0.28               : Aaron Giles perfected the CTC emulation, needed by the MCR driver.
- PCB: Z80, Z80A, Z80-A, Z80B, Z80-B, Z80CTC, Z80-CTC, Z80PIO
- PCB: Z840006 (QFP44), Z84C0006PEC, Z84C0008PEC, Z84C00A85, TMPZ84C000AP-8, TMPZ84C011AF-6, TMPZ84C011BF-6, TMPZ84C015BF-8, Goldstar Z8400B PS, Z8400APS, 84C000AM-6 (ZN1/2)
- PCB: Lwings: Z80(custom) and Z80A(sound), Exerion: SHARP LH0080A(Z80A), Passsht: SHARP LH0080BZ80B, Myhero: Z80A + Z80A-PIO, Starforc: Z80A CPU + Z80PIO + Z80CTC..., Fortecar: SGS Z8400AB1 (Z80ACPU), Paranoia: CPU Z84C00A85 (Z80A CPU), Aerofgt: LH0080B Z80B-CPU
- PCB: Agallet: Z84C0008PEC  DIP40, Z84C000FEC, QFP44 (Grdnstrm), Z0840006PCS 6MHz (Lordgun), F15se: Zilog Z85C3010VSC (communications controller)
- PCB: Mechatt: Z08400 (40 pin, compatible to Z80), Avengers: Z0840006PSC(Z80B), Contcirc: Z0840004PSC, Polepos2: ZILOG Z8400APS-Z80ACPU
- PCB: Dbz2: SHARP LH0080E (Z80E), MOSTEK MK3880N-4-Z80CPU (Lsasquad, Tactcian, Thepit), LZ8420M (Btlkroad), KL5C80A12CFP (Mjreach1, Hkagerou, NeoGeoHyper64), SGS Z80ACPUB1 (Crash)



1.3   Compatible/enhanced Z80 CPUs

      D780        : The NEC D780C  is a Z80A compatible processor for program and sound (Mariner, Myhero, Tehkanwc).
      D70008      : The NEC D70008 is a Z80A compatible processor for program and sound (Bbmanw, Dynablst, Silkworm, Tbowl).
      ST-0016     : The Seta custom chip ST-0016 is a all in one z80, gfx and sound chip (Nratechu, Mayjinsn, Renju)



1.4   Z8000/Z8002

- 0.109u5            : Aaron Giles converted the z8000 disassemblers to the new format and added step in/out support where it was obvious.
- 0.35b2             : Z8000 emulator [Juergen Buchmueller].
- SOURCE: cpu\z8000\z8000.c
- GAMES: Pole Position (Namco 1982), Pole Position II (Namco 1983)
- PCB: ST Z8002B1-NONSEGCPU, ZILOG Z8002PS-NONSEGCPU, DIP40 (Polepos2), LH8002P-Z8002CPU (Polepos)




2.    MOS-Tech (Metal Oxid Semiconductor)

2.1   M6502

- 0.124u4            : Roberto Fresca fixed the 6502 family of disassemblers to show the correct bit to operate for BBR, BBS, RMB and SMB instructions (65C02/65CE02 CPUs and variants).
- 0.114u4            : Added cpu\m6502\minc4510.h. Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.110              : Aaron Giles fixed assertions in 6502 diassembler caused by stricter checking introduced in 0.109u5.
- 0.102              : Nathan Woods fixed 6502 initialization so that all internal states are reset properly.
- 0.101u3            : Nathan Woods updated 6502 family of disassemblers to the new disassembler style.
- 0.95u3             : Nathan Woods updated some M6502 variants (DECO CPU16, M65C02, N2A03) in accordance with his recent M6502 changes and fixed crashes in NES games with new 6502 code.
- 0.95u2             : Nathan Woods added a hook that allows drivers to override the indexed addressing mode in cpu/m6502/m6502.c + m6502/ops02.h (there is a certain system on the MESS side that does some very ugly tricks to change the behavior of this mode).
- 0.94u5             : Nathan Woods removed RUNTIME_LOADER and implemented disassembler flags in cpu/m6502/6502dasm.c and did some minor cleanups.
- 0.84u5             : Curt Coder fixed disassembly in mirrored regions for the 6502.
- 0.84               : Aaron Giles removed some silly 6502 speedups in the Atari games.
- 0.82               : Stefan Jokisch fixed the 6502 STX (abs) cycle count.
- 21st February  2004: Nathan Woods sent in another miscellaneous patch for I286 and M6502 CPU cores.
- 26th April     2003: Stefan Jokisch fixed the cycle counts for the P[HL][PA] instructions in the 6502 CPU core.
-  5th December  2001: Zsolt Vasvari and Aaron Giles fixed a small bug in 6502/65c02 CPU cores.
- 18th August    2001: Zsolt Vasvari updated the 6502 CPU core so that another hack could be removed from the Burger Time decryption.
-  5th March     2001: Olivier Galibert fixed a bug in the 6502 core which was introduced by the saved states support, and some Taito games that were broken because of some bugs in the state saving code.
- 0.37b10            : Added cpu\m6502\opsn2a03.h.
- 25th November  2000: Peter Trauner fixed some problems in the M6502 CPU core.
- 16th December  1999: Juergen Buchmueller fixed a 6502 interrupt bug.
- 0.35b11            : Major overhaul to the Atari games, and fixes to the 68000 and 6502 cores to get them going properly [Aaron Giles].
- 18th April     1999: Aaron Giles modified the 6502 core to fix Indiana Jones, and changed the Atari System 1 drivers to decode certain graphics data from PROMs instead of hard-coded variables.
- 0.34b2             : Juergen Buchmueller replaced the 6502 emulator with a new one which also supports 65C02 and 6510. Marat Fayzullin's core is no longer used.
- 0.33b2             : Christophe Verre fixed a bug in 6502/dasm.c (this only applies if you compile it to get a standalone disassembler - it is not part of MAME)
- 0.33b1             : Changed the 6502 emulation to disable interrupts on a reset. Not sure if this is the correct behaviour, but Centipede needed it for the service mode to work.
- 0.30               : Aaron Giles supports 6502 bank switching via cpu_setbank().
- 0.27               : Bernd Wiebelt sincerely hopes he fixed the BCD-emulation in the 6502 emulation. Source: New macro ROM_RELOAD(), meaning to reload the previous ROM at a different address (useful with 6502 games which need reset/irq vectors at FFFx).
- 0.16               : Source: Nicola finally took the time to change Z80.h/M6502.h to make them work together. This allowed me to remove some kludges in cpuintrf.c. I also added some new functions, which can be used regardless of the CPU type: cpu_getpc(), cpu_geticount(), cpu_seticount(). Fixed a couple of bugs in M6502 BCD arithmetic. One of them was causing the pepper counter in Burger Time to behave strangely.
- 0.14               : Fixed bug which sometimes caused 6502 games not to run (actually they did run, but interrupts didn't happen).
- 0.13               : Use latest version of Marat's 6502 engine.
- 0.12               : Source: Multiple CPU support. All you have to do to setup multiple CPUs is add entries to the cpu[] array in the MachineDriver definition. Each CPU can have different type (currently Z80 and M6502 are supported), clock, address space, memory/IO port hook, interrupt handlers, number of interrupts per video frame. Nicola had already done a similar change to the 6502 engine, it was needed by Burger Time which wouldn't accept coins otherwise. Burger Time is the first multiple CPU game supported by MAME (two 6502, one for code, one for sound).
- 0.10               : Support for 6502 CPU. From a driver writer point of view, it is used just like the Z80, the only difference being that you have to specify CPU_M6502 instead of CPU_Z80 in the MachineDriver definition. Multiple CPUs are still NOT supported. Centipede is the first and Nibbler is the second 6502 game supported by MAME. Nicola currently using the M6502 Emulator (1996) by Marat Fayzullin & Alex Krasivsky. The version used in MAME is slightly modified.
- GAMES: Astro Fighter (Data East 1980), Mouse Trap (Exidy 1981), Burger Time (Data East 1982)
- PCB: R6502 (Centiped), SynerTek SY6502A (Fantasy), UM6502A CPU + R6502P SND (Pcktgal), 8333 (SY 6502A) (Liberate)
- PCB: 6502, 6502A, 6502B, R6502, R6502P, Rockwell R6502AP, R65C02P2, RP6502, RP6502A, RP65C02, RP65C02A, UM6502, UM6502A, S8010-6502 or S8010 6502 (Astrof)


2.11  M65C02

- 0.124u4            : Roberto Fresca fixed the 6502 family of disassemblers to show the correct bit to operate for BBR, BBS, RMB and SMB instructions (65C02/65CE02 CPUs and variants).
- 0.122u2            : Peter Trauner fixed M65C02 optimization.
- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
-  5th December  2001: Zsolt Vasvari and Aaron Giles fixed a small bug in 6502/65c02 CPU cores.
-  4th May       2000: Juergen Buchmueller fixed again a bug in the 65c02 opcodes.
- 30th April     2000: Zsolt Vasvari fixed a 65c02 instruction handling bug.
- 13th April     2000: Keith Wilkins fixed PLX/PLY handling in the 65c02 emulation.
- 0.34b2             : Juergen Buchmueller replaced the 6502 emulator with a new one which also supports 65C02 and 6510. Marat Fayzullin's core is no longer used.
- NOTES: The M65C02 has not illegal opcodes from the M65XX series, but has additional commands. So not full compatible to 6502 series.
- GAMES: Seta - Thundercade (1987), Twin Eagle (1988), Caliber 50 (1989), Meta Fox (1989)
- PCB: RP65C02 (Lastmiss), RP65C02A (Birdtry), R65C02P2 (Thedeep)


2.12  M65SC02/M65CE02

- 0.124u4            : Roberto Fresca fixed the 6502 family of disassemblers to show the correct bit to operate for BBR, BBS, RMB and SMB instructions (65C02/65CE02 CPUs and variants).
- 0.123u1            : Atari Ace rescued the M65CE02 core from bitrot hell.
- 0.120u1            : Added cpu\m6502\mincce02.h.
- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.111u1            : Giuseppe Gorgoglione converted m65ce02.c to use cpuintrf_temp_str() instead of local string pools.
- 0.94u5             : Nathan Woods removed RUNTIME_LOADER in cpu/m6502/m65ce02.c.
- 0.36RC1: 65sc02 and 65ce02 cpu cores [Peter Trauner].
- NOTES: The M65sc02 is M65c02 compatible and has additional commands.
- GAMES: Bonus Card, Jolly Card, Jolly Poker
- PCB: G65SC02P (Igpoker, Jollycrd, Pool10)


2.13  M6509

- 0.120u1            : Wilbert Pol fixed memory access for m6509 instructions 91 and b1.
- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.111u5            : Nathan Woods fixed a M6509 register naming bug.
- 0.90u1             : Nathan Woods fixed the M6509 core to appease the new compiler.
- 0.79u3             : Nathan Woods updated M6509 CPU core to MAME 0.79.
- 11th February  2004: Nathan Woods updated the MESS specific CPU cores (such as I286, M4510 and M6509) with latest changes.
- SOURCE: cpu\m6502\t6509.c


2.14  M6510

- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.101u3            : Nathan Woods added internal memory maps for the m6510 and m4510 CPU cores. Updated m4510 to use address translation hooks.


2.15  M6510T
- SOURCE: cpu\m6502\m6502.c


2.16  M4510

- 0.120u1            : Wilbert Pol fixed the M4510 cpu core from not updating the instruction cycle counter.
- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.109u2            : Nathan Woods added checking for register symbol names to ensure they aren't numeric (which prevents their identification by the expression parser). Changed the M4510 CPU symbols to avoid tripping this check.
- 0.101u3            : Nathan Woods added internal memory maps for the m6510 and m4510 CPU cores. Updated m4510 to use address translation hooks.
- 0.79u3             : Nathan Woods updated M4510 CPU core to MAME 0.79.
- 11th February  2004: Nathan Woods updated the MESS specific CPU cores (such as I286, M4510 and M6509) with latest changes.
- 10th May       2000: Peter Trauner added a m4510 (m6502 variant) CPU core.
- NOTES: The M4510 CPU has a integrated 20 bit memory management (map), 2 cia6526 integrated and 1 uart integrated
- SOURCE: cpu\m6502\m4510.c





3.    Motorola

3.1   M6800

- 0.122u7            : Aaron Giles added internal divider on m680* series CPUs (except the original m6800). Updated clocks on all games using them to remove the explicit divider.
- 0.121u2            : Atari Ace fixed the m6800 cpu core so that the cpu variants can be compiled independently once again.
- 0.120u3            : Curt Coder fixed the M6800 core, which break many 6800-based games in 0120u2. 
- 0.109u5            : Aaron Giles converted the m680x disassemblers to the new format and added step in/out support where it was obvious.
- 0.100u4            : Aaron Giles added missing registers to the 6800 core's save state.
-  5th June      2002: Jarek Burczynski added a new opcode to the M6800/NSC8105 CPU core.
-  7th February  2001: Phil Stroffolino added collision detection to Fire Truck, but it still unfortunately does not work with the C 6808/6800 core.
- 0.36RC1            : Tatsuyuki Satoh fixes and improvements to the 6800 family emulator.
- 10th March     2000: Tatsuyuki Satoh fixed m6800 port write functions, Namco System 1 DAC gain and also a sound stream bug.
- 0.36b8             : Tatsuyuki Satoh finally fixed the CMPX instruction in the 680x core. On the 6800 it does not affect the C flag, on the others (6803, 63701) it does.
- 15th October   1999: Tatsuyuki Satoh sent in a Namco System 1 update with a correct romset for Blazer, DAC sound fixes and some other fixes to m6800.
- 0.36b6             : Jess Askey fixed bug in the 6800 CMPX instructions.
-  7th April     1999: Nicola Salmoria has updated Pac Land and Rolling Thunder drivers to work on the new 6800 (not 68000 ;-) core, but music speed is still sometimes screwed.
- 19th March     1999: Jürgen has fixed some bugs in the 6800 core.
-  8th February  2000: Tatsuyuki Satoh did a few bugfixes and optimized the m6800 core.
- 0.35b2             : Brad Oliver added Sky Diver (Atari 1978 - first game uses the M6800 CPU)
- GAMES: Atari - Drag Race (1977), Sky Diver (Atari 1978), Monte Carlo (1979)
- PCB: 68A00 (Sflush, Fgoal), 6800 (Triplhnt)


3.2   M6802

- 0.122u7            : Aaron Giles added internal divider on m680* series CPUs (except the original m6800). Updated clocks on all games using them to remove the explicit divider.
- NOTES: M6802 almost (fully?) equal to the M6800. In Qix drives a 6802 an 8-bit DAC and according to the schematics a TMS5220 speech chip, which is never accessed.
- GAMES: Qix (Taito 1981), The Electric Yo-Yo (Taito 1982), Discs of Tron (Bally Midway 1983), Jack Rabbit (Zaccaria 1984)
- PCB: 6802 (Jackrabt), HD46802P (Spiders, R2dtank), F6802P (Poker, Sdungeon), S6802P (Murogem)


3.3   M6805

- 0.122u7            : Aaron Giles added internal divider on m680* series CPUs (except the original m6800). Updated clocks on all games using them to remove the explicit divider.
- 0.109u5            : Aaron Giles converted the m6805 disassemblers to the new format and added step in/out support where it was obvious.
- 0.101u5            : Ernesto Corvi fixed 6805 core so that CLRA does not modify the carry flag.
- 13th March     2002: Ernesto Corvi fixed a few bugs in the M6805 CPU core, but fortunately the bugs didn't affect anything.
- 0.31               : 6805 emulator, needed by Arkanoid [Aaron Giles].


3.4   M6808

- 0.122u7            : Aaron Giles added internal divider on m680* series CPUs (except the original m6800). Updated clocks on all games using them to remove the explicit divider.
- 14th February  2001: With Nicola Salmoria's help, Juergen Buchmueller fixed some 6808 CPU core bugs that prevented Fire Truck from working.
- 0.35b3             : Brad Oliver fixed a couple of bugs in the 6808 core.
- 0.33b7             : Source: [DOS] Included Neil Bradley's asm M6808 emulator. Note: You need NASM to compile (the makefile defaults to NASMW, the Win32 version) [Alex Pasadyn].
- 0.31               : New 6808 emulator [John Butler]. Ernesto Corvi added support for HD63701YO extra opcodes to the M6808 emulation. Larry Bank fixed bug in the 6808 emulation of TSX and TXS.
- GAMES: Williams - Defender (1980), Stargate (1981), Robotron (1982), Blaster (1983), Joust2 (1986)


3.5   M6809

- 0.122u7            : Aaron Giles added internal divider on m680* series CPUs (except the original m6800). Updated clocks on all games using them to remove the explicit divider.
- 0.116u2            : Ernesto Corvi fixed minor cycle timing issue in 6809 CPU core.
- 0.115u3            : Ernesto Corvi and Zsolt Vasvari fixed bug that failed to initialize all IRQ states in the 6809 core on a reset. Also fixed cycle timing and removed obsolete code from the core.
- 0.112u1            : Nathan Woods changed 6809/6309 CPU cores to call the MAME debugger when CWAI/SYNC is used.
- 0.111u1            : Giuseppe Gorgoglione extensively rewroted the 6809dasm.c disassembler.
- 0.110              : Aaron Giles fixed assertions in 6809 diassembler caused by stricter checking introduced in 0.109u5.
- 0.107u2            : Antoine Mine connected unimplemented opcode $01 on the 6809 core.
- 0.101u1            : Aaron Giles fixed missing save state registrations in the M6809 CPU core.
- 0.90u2             : Hans de Goede fixed 6809dasm.c compile warning.
- 0.78u3             : Changed name 'M6809E' to 'M6809'. Aaron Giles fixed the hd63705_get_info in the M6809 core, it crached in 0.78u2.
- 0.78u2             : Changed name 'M6809' to 'M6809E'.
- 23rd July      2003: Martin Adrian submitted a bug fix for the EXG and TFR opcodes in the M6809 CPU core.
-  5th September 2002: Tim Lindner submitted a fix to the SEX instruction in the m6809 CPU core.
- 29th June      2002: Nathan Woods submitted a fix for a timing bug in the M6809 CPU core.
- 16th August    2000: Juergen Buchmueller fixed a bug in 6809 cycle counting.
- 15th June      2000: A small bug in the M6809 core was squished, fixing some CoCo 3 program bug on the MESS side.
- 0.36b8             : Juergen Buchmueller cleaned up the 6809 and Konami-2 emulations.
- 25th October   1999: Jürgen fixed some m6809 bugs and made new ones.
- 23rd September 1999: John Butler fixed an ASR bug in m6809.
- 21st September 1999: Michael Soderstrom fixed an ASR bug in m6809.
-  5th September 1999: Aaron Giles fixed a small 6809 cycle timing bug.
-  9th March     1999: Juergen Buchmueller has updated the 6809 core again.
-  2nd March     1999: Juergen Buchmueller has fixed Rolling Thunder MCU problems by simplifying the 6809 interrupt handling and corrected CWAI emulation.
- 26th February  1999: Jürgen has also fixed some timer system problems and worked on 6809 code.
- 0.33b6             : Mathis Rosenhauer improved cycle counting in the 6809 emulator.
- 0.33b3             : Keith Wilkins fixed bug in the 6809 disassembler.
- 0.29               : M6809 emulators natively support bank switching. Aaron Giles and Tatsuyuki Satoh did some optimizations to the 6809, and modified it to always fetch opcodes directly from RAM (much faster). The Ghosts 'n Goblins, Star Wars and Williams drivers needed reworking to support that.
- 0.28               : John Butler provided a new 6809 emulator. It is faster than the previous one, and fixes some bugs including the ship moving in the wrong direction on the tower level of Star Wars and the bonus maze in Pac & Pal.
- 0.23               : Modifications were done to M6809 emulator to support FIRQ.
- 0.21               : Added M6809 CPU support. Changes in CPUIntrf.c and Driver.h to accommodate the new CPU. The first driver working on this CPU is Super Pac Man. The driver is based on the super-detailed SUPERPAC.KEG file of Replay emulator by Kevin Brisley. M6809 emulator is based on L.C. Benschop's 6809 Simulator V09 (Copyright 1994,1995 L.C. Benschop, Eidnhoven The Netherlands).
- GAMES: Namco - Super Pac-Man (1982 - 2x), Mappy (1983 - 2x), Motos(1985 - 2x), Pac-Mania (1987 - 3x)
- PCB: MOTOROLA M6809 DIP40 (Truco), MC6809 (Rockrage), HD6809EP (Chinagat), 68A09EP (Metrocrs), 6809EP (Csilver), MC68B09EP (Contra, Ddribble), MC68A09EP (MegaZone), MC6809EP (Sdungeon), EF68B09 (Timekill), EF68B09EP (MK), Fujitsu MBL68B09E (Lemnangl), S22GD-EF68B09EP (Mk), Hitachi HD68A09 or HD68B09 (Xsleena), HD68B09EP + MC6809P-CW38602 (Cheyenne), HD68A09EP (Junofrst)



3.6   M68000 (ASM, C core and DASM)

- 0.123u5            : Aaron Giles fixed 68000 prefetching operation. Previous behavior was incorrect. Fabio Priuli fixed M68000 build logic to only include it if enabled.
- 0.117              : Zsolt Vasvari fixed ROL opcode in the 68000 emulator.
- 0.111u1            : Removed cpu\m68000\cpudefs.h. Alex Jackson fixed two bugs in the m68000 core: Fixed a miscompilation issue with GCC4 that was first noticed in Altered Beast but also affected Moonwalker, Galaxy Force 2, and probably many other games. Fixed the core's compile-time self-configuration so that it uses the same code paths on LP64 platforms (64-bit Linux, etc.) as on LLP64 (64-bit Windows) and 32-bit platforms. Giuseppe Gorgoglione removed m68000\cpudefs.h. This was used by the old assembly m68000 core. Removed from m68kmame.c and m68kmame.h as well many references to the old core (e.g A68K0, A68K2, etc.).
- 0.109u1            : Aaron Giles simplified the 68000 core generation logic to just produce one file. Hopefully this will cure some of the build issues with the core.
- 0.108u1            : David Haywood added a callback to the 68000 emulator for the TAS instruction, which allows different implementations based on external hardware.
- 0.107u1            : Charles MacDonald fixed memory write ordering bug in the 68000 core.
- 0.105u1            : Added cpu\m68000\m68kfpu.c.
- 0.104u4            : More global system cleanup [Aaron Giles, Atari Ace]: Moved 68000-specific build rules to cpu.mak and updated the 68000 disassembler to use the new interfaces.
- 0.102u2            : Alex Jackson tweaked the 68000 disassembler to display F-line traps in a more obvious fashion. Also changed to decorate jump targets for relative branches.
- 0.98u1             : Aaron Giles turned on address error checking in the 68000 core and fixed several issues with address error checking in the 68000 core ( this slows things down a bit but is more accurate and allows correct behavior of a couple of badly-programmed games). Aaron fixed also a 68000 bug that treated 8-bit branches with $FF offsets as illegal, rather than allowing them and generating an address error.
- 30th June      2005: Jorge Cwik - I solved the undocumented timing of the 68000 DIVU/DIVS instructions: Below is attached source code for computing the exact number of cycles taken by a specific division on the Motorola 68000 CPU. As far as I know this information was not (publicly) available before. Current emulators for 68000-based machines (Amiga, Atari ST, MAC, MAME, etc) reached an amazing level of accuracy. The exact timing of the division instructions remained as one of the main inaccuracies because this is not documented in the available manuals. Hopefully, with this issue solved now, 68000 emulation can take one-step forward. The code and algorithm was only partially tested. It is not feasible to do an exhaustive test on real hardware in a single machine. The source code is available at: http://pasti.fxatari.com/docs/div68kCycleAccurate.c
- 0.95u3             : Fixed cycle counts for several 68000 instructions [Andrew Seed].
- 0.92               : Removed cpu\m68000\asmintf.c and cpu\m68000\make68k.c.
- 0.87u3             : Olivier Galibert added some hooks to C 68k core in preparation for Sega decryption updates.
- 0.81               : Sebastien Volpe improved timing of several 68k instructions, these changes could do with being verified on a real 68k. m68kcpu.h, m68kcpu.c: A) scc (68000 only): CYC_SCC_R_FALSE was defined, not used, and misnamed as the extra 2 cycles happens when CC is true: now used and renamed to CYC_SCC_R_TRUE. m68kmake.c: B) add/adda/and/or/sub/suba (68000 only): the 'extra 2 cycles' cases were not handled correctly: corrected to be effective on .l only, and also on register direct (previously, all sizes were affected, and only in immediate mode). C) jmp d(An,Xn) / pea (An) (68000/68010): tables corrected. D) movem (68000/68010): generated basecount were incorrect in many cases, so I added a dedicated table. m68k_in.c: E) movem.l d(PC),reglist / movem.l d(PC,Xn),reglist (68000/68010): changed basecount. F) asr/asl/lsr/lsl/ror/rol/roxr/roxl (68000/68010): added '+2n' cycles where missing, as the shift/rotate memory is the only case where '+2n' does not apply, and is treated in a specific opcode handler.
- 0.79u2             : Leon van Rooij fixed a m68kdasm bug.
- 0.79               : Fixed ASM 68k core to compile again [BUT].
- 0.78u3             : Aaron Giles fixed the inability to compile with asm 68k.
- 0.72u2             : Acho A. Tang fixed a bug in the C 68000 core with the SBCD Opcode. States of the sign(N) and overflow(V) flags after SBCD, ABCD and NBCD operations are "undefined" according to Motorola. The C core randomizes the V flag and sets the N flag like signed operations. Viofight expects determinant results of the two flags from SBCD or it gets stuck in a math loop. The V flag now returns zero and the N flag mirrors carry exactly like what the ASM core does.
- 15th August    2003: Acho A. Tang fixed Viewpoint from crashing with the ASM 68k core too.
- 0.69u3             : Razoola changed MULU timing in asm 68k core so that it matches the C ones.
- 0.69a              : C 68k core is now default, this fixes collisions in Assault.
- 26th May       2003: David Haywood forwarded the 68k CPU core select and Neo Geo save states from MAME32 Plus!
- 25th October   2002: Mike Coates fixed the LSL / LSR opcodes in the ASM 68k core.
- 11th June      2002: Karl Stenerud updated the C 68k core to emulate address error exceptions.
-  9th May       2002: Olivier Galibert fixed the reset opcode in the ASM 68k core.
- 23rd April     2002: Karl Stenerud fixed a bug in the privilege violation emulation in the C 68k core.
- 28th January   2002: Aaron Giles also fixed a crash that happened with the core changes and resetting 68k CPUs.
- 18th January   2002: Stefan Jokisch did a tiny clean-up on the ASM 68k core to make it compile with Visual C.
- 15th September 2001: Aaron Giles fixed some problems with 68k CPU interrupts.
- 23rd July      2001: Nicola Salmoria fixed a 68k disassembler bug.
- 16th May       2001: Aaron Giles fixed a small bug in the C 68k core.
- 16th April     2001: Mike Haaland fixed an ASM 68k CPU core compilation bug.
-  8th April     2001: Mike Coates changed the way in which interrupts are processed in the ASM 68k core, which should fix a few problems.
- 21st March     2001: Mike Coates fixed the Incredible Technologies 32-bit games' slowness with the ASM 68k core for good.
- 19th March     2001: Aaron Giles did a quick and dirty fix for Incredible Technologies 32-bit games' slowness with the ASM 68k core.
- 14th March     2001: Mike Coates renamed some variable names to be consistent between the ASM and C 68k cores.
-  9th March     2001: Mike Coates improved the ASM 68k core's save state support.
-  7th March     2001: Mike Coates fixed the ASM 68k core to compile properly again.
-  4th March     2001: Mike Coates fixed several bugs in the ASM 68k core.
-  4th March     2001: Nicola Salmoria improved the C 68k core so that it can use separate memory handlers for different width data, and he fixed it from crashing in many Neo Geo games.
-  2nd March     2001: Mike Coates fixed the ASM 68k core to compile on *nix.
- 20th February  2001: Karl Stenerud fixed some 68k disassembler bugs.
- 18th February  2001: E. Watanabe fixed the ASM 68k core to work with Namco System 2 and Taito F3 sound.
- 17th February  2001: Mike Coates changed the ASM 68k core to work correctly with encrypted opcodes.
- 0.37b12            : Added machine\m68kfmly.c.
- 12th February  2001: Mike Coates fixed pc-relative addressing modes in the ASM 68k core.
-  4th February  2001: Karl Stenerud added PC-relative read modes to the C 68k core but the MAME memory core has not been updated to work properly yet.
- 28th January   2001: Karl Stenerud sent in an update to the C 68k core, containing the beginnings of 68000/010 and 68020 separation.
- 27th January   2001: Mike Coates separated the 68000/010 and 68020 cores so that the ASM 68k core can be used with the C 68020 core, giving a nice speed boost to all the 68k games. Paul Leaman added Vampire: The Night Warriors to the CPS-2 driver, and like Vampire Savior, it will not work before some important 68k core changes are made.
-  5th January   2001: smf fixed encrypted opcodes handling in the C 68k core and subsequently fixed Enduro Racer again.
- 21st November  2000: Aaron Giles fixed another bug in the ASM 68k core.
- 19th November  2000: Aaron Giles fixed some more ASM 68k core bugs.
- 16th November  2000: Aaron Giles fixed some opcode bugs in the ASM 68k core
- 13th November  2000: Aaron Giles fixed some problems in the ASM 68k core.
-  8th November  2000: Aaron Giles fixed the ASM 68k core to work with the new memory system.
-  4th September 2000: Nicola Salmoria fixed a bug in the C 68k core which affected Zwackery.
- 22nd August    2000: Nicola Salmoria fixed a 68k bug affecting Bombjack Twin.
-  2nd August    2000: Andrea Mazzoleni fixed a compilation bug in the C 68k core.
- 30th July      2000: Brad Oliver fixed a few 68k core bugs.
- 21st June      2000: Karl Stenerud and Mike Coates fixed some problems in the 68k cores.
-  4th April     2000: Karl Stenerud fixed the longstanding bug in C 68k core which caused Hippodrome to crash.
- 23rd March     2000: Mike Coates fixed an ASM 68k core bug which affected Super Sidekicks 4.
-  9th February  2000: Mike Coates fixed some ASM 68k core bugs.
-  7th February  2000: Aaron Giles fixed another 68k core bug.
- 0.36b15            : make68k.exe now requires as parameter the path of the comptab.asm include file (see makefile).
- 0.36b8             : Fixes to the x86 asm 68k core [Mike Coates].
- 25th October   1999: Mike Coates fixed some ASM 68k core bugs.
- 18th October   1999: Mike Coates fixed some bugs in the ASM 68k core.
- 0.36b4             : Darren Olafson fixed a 68000 "bug" (actually an undocumented feature of the cpu) that caused the timer to roll over from 00 to 99 in KOF98.
- 26th August    1999: Karl Stenerud fixed sbcd and abcd opcodes in the C 68k core.
- 22nd August    1999: Darren Olafson fixed an ASM 68k core bug which made kof98 timer incorrect.
- 0.36b3             : Karl Stenerud updated the 68000 C core.
-  8th August    1999: Mike Coates fixed PC fetch and stack in ASM 68k core.
- 20th June      1999: Mike Coates fixed ASM 68k core timings in debug mode.
- 28th May       1999: Mike Coates fixed some interrupt bugs of the asm 68k core, and now Spinmaster, Sengoku 2 and Riding Hero work on it.
- 26th May       1999: Mike Coates added support for previous PC to the asm 68k core.
- 0.35b13            : Mike Coates fixed a couple of bugs in the 68000 emulation (both asm and C). They affected Power Spikes 2 and F1 Dream.
- 12th May       1999: Mike Coates finally fixed the Power Spikes 2 and F1 Dream bugs in both asm and C 68k cores.
- 0.35b12            : Mike Coates fixed F1 Dream protection workaround (note that the game still doesn't work correctly with the 68000 C core).
- 0.35b11            : Major overhaul to the Atari games, and fixes to the 68000 and 6502 cores to get them going properly [Aaron Giles].
- 21st April     1999: Mike Coates fixed 68k assembler stuff so that it compiles.
- 11th April     1999: Aaron Giles has updated the 68k core for better interrupt emulation and other stuff.
- 10th April     1999: Aaron Giles fixed the C 68k core to compile on Macs.
-  9th April     1999: Nicola modified the m68k core to start faster, and the slowdown in the beginning of m68k games should be gone. He also fixed the crash if control-c was pressed during the rom load.
- 0.35b10            : Please report any problem you find with the C 68000 core. There are no known bugs as of now (apart from ball movement in Power Spikes 2), if no new bugs are found we'll switch back to test the asm core.
-  5th April     1999: Jürgen changed the DOS makefile to build the m68k core automatically, which should help ironing out the last bugs. He also fixed an opcode order problem.
-  4th April     1999: Jürgen fixed the slow initialization of m68k (it caused small sound hiccups at the beginning of every m68k game)
- 28th March     1999: Mike Coates implemented the STOP operation correctly in the ASM 68k core, which should help getting Indy working.
- 26th March     1999: Nicola fixed 64th Street to work with the C 68k core
- 0.35b8             : Changed name 'M68000' to '68000'. Most of the problems of beta 7 have been fixed, but the C 68000 core still isn't 100%.
- 23rd March     1999: Darren Olafson has updated the asm 68k core for better cycle timing.
-  1st March     1999: Tatsuyuki Satoh has sped up the C 68k core. Mike Coates has fixed several bugs with the ASM 68k core (Shock Troopers should work now).
- 21st February  1999: Karl Stenerud has sent in a newer C m68k core.
- 0.35b2             : New 68000 C core [Karl Stenerud]. For testing purposes, this is also being used in the DOS version instead of the asm core. Differences:  1. Faster. This code is, barring ram fetch time, almost twice as fast as the existing C core in MAME. I've done extensive speed profiling on both engines. The only problem now is the slow memory access in MAME due to bankswitching et al. 2. Emulation more correct. I found many bugs in the MAME engine (and many, many more in mine for that matter) when I pitted them head-to-head. I have run random instructions from each opcode class at least 10 million times, comparing the resultant CPU states, and have left it running random instructions for 1 billion iterations. In every case, I have adhered to the specs defined in M68000PM/AD REV.1.  3. Disassembler is correct. The current M68000 disassembler in mame has a tendency to disassemble instructions that have an invalid EA mode. 4. Cycle counting is 99.9% correct. The only instructions which don't have  correct cycle counts are divs, divu, muls, mulu, and they're not worth counting correctly. (I'm not about to waste emulation time counting 0-1 and 1-0 sequences).  5. > 32 bit friendly. I've taken care to ensure maximum portability without sacrificing speed. The result is conditional compiling dependant on your architecture. I've also implemented and tested a compatible solution for  architectures that lack 8, 16, or 32 bit signed storage types.  6. The code is carefully laid out to be readable. (I beg to differ - NS)
- 0.35b1             : The 68000 based games no longer have to read and mix two 8 bit ports to get a 16 bit value [Brad Oliver].
- 0.34               : Bryan McPhail made several improvements and bug fixes to the Data East 68000 games (Midnight Resistance, Bad Dudes, Robocop, etc.).
- 0.34b6             : The x86 asm 68000 core: several bugs have been fixed (most notably, it now runs under pure DOS) but it is still not complete. For example, the two Metal Slugs hang shortly after game start. They will work if you recompile using the C core.
- 0.34b6             : Several games have experimental 68000 idle cycle skipping, for these games you should see increases of between 5% and 20%. Games currently using this method are: Puzzle De Pon, Karnov's Revenge, Wind Jammers, Street Hoops and Neo Bomberman.
- 0.34b5             : x86 ASM 68000 core. This is a major speed improvement [Mike Coates, Darren Olafson].
- 0.34b4             : Brad Oliver fixed bug in the 68000 interrupt handling which causes Rastan Saga to not boot correctly.
- 0.34b3             : Mike Coates fixed SBCD in M68000 disassembler.
- 0.34b2             : Nicola Salmoria fixed a bug in the 68000 BCD emulation which caused the F1 Dream timer to malfunction.
- 0.34b1             : Mike Coates fixed a bug in the NOT instruction of the 68000 core.
- 0.33b7             : Close to accurate 68000 instruction timing [Brian Verre]. Darren Olafson slightly improved speed of the 68000 emulator.
- 0.33b4             : The 68000 memory handlers can again be word-aligned instead of longword-aligned [Aaron Giles].
- 0.33b1             : Juergen Buchmueller improved speed of the C 68000 core.
- 0.31               : Aaron Giles fixed 68000 emulator to properly handle interrupt priorities. Source: [Aaron Giles] Memory for the 68000 is allocated automatically. You no longer have to do it yourself. The memory interface reads/writes 16 bits at a time to improve performance. Writing a single byte is a bit tricky, because the 68000 can cause write to either the high or the low byte without affecting the other; thus the second parameter for a 16-bit write is a bit more complicated. The top 16 bits are a mask which is supposed to be ANDed with the 16-bit value already in memory; the bottom 16 bits are the actual data values, to be ORed with the result. To aid in doing these operations, use the macros READ_WORD(), WRITE_WORD(), COMBINE_WORD() and COMBINE_WORD_MEM().
- 0.30               : Aaron Giles made some changes to the 68000 emulator memory interface, and a new 68000 disassembler. Improved the 68000 cpu interface.
- 0.28               : Jarek Burczynski adapted the M68000 emulator from the System 16 Arcade Emulator by Thierry Lescot. The only known problem of this emulator is that it doesn't count CPU cycles, only instructions. The first driver to use the 68000 is Rastan, also provided by Jarek.
- PCB: MC68EC000FN (Salmndr2), MC68000P10 (Cawing) = M68000 10 MHz, MC68HC000 (Bcstry), Signetics SCN68000CAN64 (Badlands, Tmnt), TM68HC000p-16 (Mcatadv), HD68000 (Hvoltage, Splndrbt), Hitachi HD68HC000PS8 (MegaPlay), 68HC000FN16 (Bang), TS 68000 (Rainbow), MC68000P12 OB26M8829  64 pin (Pntnpuzl)
- PCB: 68HC000FN10, PLCC68 (Grdnstrm)
- PCB: 59 <- Data East Code (Mutantf, Rohga), DATA EAST 74 - surface scratched (Sotsugyo)


3.61  M68008

- 0.121u2            : Curt Coder fixes the M68008 data bus to properly use 8-bit accesses.
- 0.82               : Curt Coder added MC68008 support to the MC68000 core.
- NOTES: The M68008 must use ROM_LOAD16_WORD_SWAP to load ROMs.



3.62  M68010 / 68010

- 0.112u2            : Ernesto Corvi fixed behavior of MOVEC instruction on later 680x0 chips and in the disassembler.
- 28th January   2001: Karl Stenerud sent in an update to the C 68k core, containing the beginnings of 68000/010 and 68020 separation.
- 27th January   2001: Mike Coates separated the 68000/010 and 68020 cores so that the ASM 68k core can be used with the C 68020 core, giving a nice speed boost to all the 68k games.
- 0.36RC1            : Changed name 'MC68010' to '68010'.
- 17th August    1999: Aaron Giles fixed an embarrassing 68010/68020 mode selection bug.
- 0.35b13            : Changed name '68010' to 'MC68010'.
- NOTES: The M68010 has extra opcodes.



3.63  M68020 / 68EC020

- 0.112u2            : Ernesto Corvi fixed behavior of MOVEC instruction on later 680x0 chips, and in the disassembler.
- 0.110u1            : Aaron Giles fixed max instruction bytes for 68020+ CPUs to avoid assertion in new disassembler.
- 25th November  2001: Bryan McPhail resent an old bug fix to the 68020 CPU core which fixes a crash in Under Fire.
- 16th June      2001: Aaron Giles updated the ASM 68020 core, making the itech32 games playable with it but others not yet.
-  2nd June      2001: Bryan McPhail fixed yet another 68020 core bug which made Under Fire playable.
-  1st May       2001: Bryan McPhail fixed a 68020 core bug which caused a lot of problems with the Taito F3 driver, namely a Puzzle Bobble 2 intro background graphics problem and some Bubble Memories bugs. In addition, the bugfix makes the following games fully playable: Elevator Action Returns, Darius Gaiden, Puzzle Bobble 4, Landmaker, Twin Qix and Gekirindan.
- 28th January   2001: Karl Stenerud sent in an update to the C 68k core, containing the beginnings of 68000/010 and 68020 separation.
- 27th January   2001: Mike Coates separated the 68000/010 and 68020 cores so that the ASM 68k core can be used with the C 68020 core, giving a nice speed boost to all the 68k games.
- 15th January   2001: Bryan McPhail finally submitted his Taito F3 driver, which is not graphically perfect and crashes hard sometimes but has complete ES5505 sound emulation thanks to Aaron Giles, Ian Schmidt and R. Belmont. Not all games are working due to 68020 core bugs.
- 0.37b9             : The 68EC020 core now uses 32-bit memory handlers. The Psikyo driver has been updated to use the new interface. Unfortunately, this support has yet to make it into the x86 asm 68000 core, so it is once again disabled for this build [Aaron Giles].
- 17th October   2000: Aaron Giles updated the C 68k core to support 32-bit bus width in 68020 emulation.
- 0.37b8             : The x86 asm 68000 core now has limited 68020 support and runs the Psikyo games, so is reenabled by default [Darren Olafson].
- 30th September 2000: Darren Olafson sent in an updated ASM 68k core with support for the two Psikyo 68020 games, and fixed a bug that prevented sf2accp2 from working.
- 26th March     2000: Karl Stenerud updated the 68020 core a bit.
-  3rd March     2000: Karl Stenerud has added some more 68020 functionality to the C 68k core.
-  8th February  2000: Luca Elia fixed a 68020 bug.
-  6th February  2000: Aaron Giles improved the 68020 support a lot, and added distinction for 68EC020.
- 19th July      1999: Karl Stenerud updated the C 68k core, adding some 68020 opcodes and fixing bugs.
- 17th August    1999: Aaron Giles fixed an embarrassing 68010/68020 mode selection bug.
- PCB: MC68EC020FG16, QFP100 (Dreamwld, Elvactr), MC68EC020FG25 (Machbrkr), MC68EC020RP25 (Groundfx), TMP68EC020F (Samuraia)


3.64  M68030
- 0.112u2            : Ernesto Corvi fixed behavior of MOVEC instruction on later 680x0 chips, and in the disassembler.
- NOTES: Supported by disassembler only.
- SOURCE: cpu\m68000, m68kdasm.c


3.65  M68040
- 0.112u2            : Ernesto Corvi fixed behavior of MOVEC instruction on later 680x0 chips, and in the disassembler.
- 0.106u9            : Improved M68040 FPU emulation [Ville Linde].
- 22nd June      2006: Ville Linde - I have made some major improvements to the Taito JC System driver. First I improved and fixed bugs in the M68040 FPU. Then I found the missing vertical blank interrupt, after which things really started to work. After that, I needed to figure out how the 2D graphics works. Turns out the 2D graphics chip is just a basic object processor, not too different from the one in Konami's Firebeat hardware. Landing Gear and Side by Side 2 already run through their attract modes. Densya De Go! also shows some graphics, but hangs pretty soon. Apparently it needs a bit more of the train controller emulated.
- 0.105u1            : Ville Linde added many FPU opcodes to the M68040 core.
- 10th April     2006: Ville Linde - I picked up the Taito JC System driver again in hopes of getting it to do something interesting. The two major roadblocks were the missing FPU stuff from the M68040 core and the missing TMS320C51 DSP core. The TMS DSP emulation already works well enough that the basic communication and ROM tests are already working. There's also enough of the 68040 FPU emulated that the games won't just crash when they hit FPU opcodes. None of the games still show anything interesting graphics-wise, but progress is progress nevertheless.
- 0.97u5             : Ville Linde added very basic 68040 support to the 68000 core.
-  8th April 2004: David Haywood - I don't think I'll be finishing this one myself somehow, needs a 68040 core (currently running on the 68020) and various other bits and pieces before it stands a chance of working. WIP driver should be included in the next update tho.
- GAMES: Taito System JC - Landing Gear (1995), Side By Side (1997)
- PCB: MC68040RC25  PGA type (Landgear, Sidebs, Sidebs2)
- SOURCE: cpu\m68000\


3.7   DSP56156
- 0.110u5            : Improvements to the Polygonet Commanders driver [Andrew Gardner]: Implemented various dsp56k opcodes. Polygonet Commanders now gets past the memory tests.
- 27th November  2006: Andrew Gardner - As far as the network error (in the network) goes, it should be fairly straightforward to fix up - there remain a hearty hunk of writes that aren't going anywhere, and who knows, maybe I can convince Arbee to take another look at this'shizzle after i touch up a few more unimplemented dsp56k opcodes...
- 0.110u1            : Polygonet Commanders update [Andrew Gardner]: Added more accurate host interface to dsp56k core. Removed a bunch of hacks in plygonet.c.
- 0.106u6            : Improvements to Polygonet Commanders [R. Belmont]: Fixed Z80 IRQ/NMIs to go to the right CPU again, modernized memory map and added network status bit, so the initial test passes well enough to make the DSP56k crash on unimplemented opcodes.
- 11th June      2006: R. Belmont - Polygonet Commanders now passes POST again and now hits unimplemented opcodes in the 56156 DSP. Over to you, Andrew.
- 0.106u1            : Some improvements to the Polygonet Commanders driver [Andrew Gardner]: Adds change_PC() calls to the dsp56k core, removed hacky dsp56k initialization, enabling and disabling, added preliminary implementation of banking hardware tied to the dsp56k in Polygonet Commanders.
- 0.104u5            : Some small improvements to the Polygonet Commanders driver [Andrew Gardner]. Added DSP56156 (10MHz) CPU2 and K054539 (48000 Hz) sound.
- 0.99u6             : Renamed (dsp56kdasm.c) to (dsp56dsm.c) and (dsp56kops.c) to (dsp56ops.c).
- 0.99u3             : Andrew Gardner added DSP56k CPU core and hooked it up to the Polygonet Commanders driver.
- 15th July      2005: Andrew Gardner - The Motorola (now Freescale Semiconductor - Motorola owned them at the time) DSP56k series of processor is a strange beast in many ways... Nothing too crazy - variable length opcodes, strange decoding criteria, a few addressing modes, but honestly nothing to offer too much opposition for the would-be conqueror... To save you the trouble of guessing why I'd be writing a CPU core for such a thing (and why I'd mention R. Belmont and his infinite benevolence), here's the system16 link to the arcade games that use it : http://www.system16.com/konami/hrdw_polygonet.html (Konami's Polygonet Hardware). Polygonet Commanders is currently in MAME as a non-working driver and Belmont's got the sound hooked up and some hacks to get the thing to pass its memory tests. Then it stops ticking... I haven't looked at why it stops working yet, but I'm guessing it has something to do with the giant hole where a DSP56156 CPU core should be! Anyways, to my knowledge, the other game on the hardware, Poly-Net Warriors, has not been dumped (I'd be impressed if someone out there has even seen it in person), so it looks like it's just me and Polygonet. If anyone knows of any other interesting things that use a DSP56156 (so I can bug-squish the core some more) - feel free to mail me - I'll pass your knowledge on via this page and hopefully enhance the core using it... But here's the news : last night I finally managed to make the first real strides towards a truly working DSP56156 core in MAME. I removed a single memory-test hack Belmont put into the polygonet driver. Basically, the 68000 used to send a message to a nonexistent DSP56156. This message went nowhere, but Arbee knew the message was going to result in the DSP56156 filling a portion of memory with some simple values, and instead filled the proper piece of memory (using hard-coded C) with data the 68000 was expecting. Now, when the 68000 sends that message, it gets received (via a communications hack I put in :P) by the DSP56k core and it whirrs up, runs a few dozen opcodes, and fills the memory with the proper information! Now this may not seem all that interesting, and I can't show cool screen shots to back up the work, but rest assured, I'm totally stoked over the fact that my DSP56156 is running in tandem with a 68000, and they're actually getting along :)... Next on the todo list is to get the second memory test un-hacked. This is going to be a lot trickier though, as I'm going to need to do some arithmetic on the chip, and it seems to have a somewhat strange way of handling math in its 40-bit accumulator buffers.
- SOURCE: cpu\dsp56k\dsp56k.c and drivers\plygonet
- PCB: Motorola DSP56156FE40 or XC56156 DSP
- GAMES: Polygonet Commanders (Konami 1993)





4.    Signetics

4.1   S2650

- 0.122u5            : Zsolt Vasvari fixed 2650 disassembly of the sense and flag bits. Fixed incorrect argument order in OUT instruction. Corrected spacing.
- 0.122u4            : Zsolt Vasvari fixed S2650 register window display.
- 0.109u5            : Aaron Giles converted the s2650 disassemblers to the new format and added step in/out support where it was obvious.
- 0.107u4            : Aaron Giles fixed overflow computation in the S2650 core.
- 0.107u1            : Minuous fixed a S2650 register overflow bug (originally reported to the MESS Team).
- 0.101u2            : Aaron Giles added save state support to the S2650 CPU.
- 0.98u3             : Improvements to the S2650 core [Manfred Schneider]: Fixed LPSU opcode and changed cycle counts to match technical documentation.
- 0.89u6             : Juergen Buchmueller updated S2650 CPU core to count more accurate clock cycle counts.
- 10th June      2002: Aaron Giles fixed the clock speeds in some games that use the S2650 CPU.
- 31st May       2000: Mike Coates fixed the Zaccaria 2650 games to work with MAME 0.37b3.
-  5th May       2000: Mike Coates fixed some S2650 core bugs.
- 19th August    1999: Mike Coates fixed a bug in S2650 which made Hunchback miscalculate things, and sent in a driver for Hunchback running on Donkey Kong hardware.
- 0.33b6             : Signetics 2650 emulator [Juergen Buchmueller].
- SOURCE: cpu\s2650\s2650.c
- GAMES: Lazer Command (Meadows Games 1976), Meadows Lanes (Meadows Games 1977), The Invaders and Super Invader Attack (Zaccaria/Zelco 197?), Dead Eye (Meadows 1978), Gypsy Juggler (Meadows 1978), Hunchback (Century 1983), Herbie at the Olympics (CVS 1984)
- PCB: 2650A (Shootgal), 2650 (Porky), MAB2650A CRG3243MOY (Hunchback)




5.    CCPU

- 0.123u4            : Aaron Giles fixed CCPU and QB3 to no longer rely on cpu_scalebyfcount(). Fixed busted timing in the CCPU core. Changed watchdog to count internally rather than using external watchdog support. Altered CCPU to accept interrupt signals from the driver. Updated clocks in the cinemat driver to be derived from the clock crystal.
- 0.109u5            : Aaron Giles converted the CCPU disassemblers to the new format and added step in/out support where it was obvious.
- 0.87u3             : Removed cpu\ccpu\ccputabl.c.
- 11th October   2004: Aaron Giles - I started looking into adding QB-3 to the Cinematronics vector game driver when I realized that I was going to have to make changes to the CCPU core to actually get the game up and running.
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. * Harvard architecture CPUs now have data memory fully implemented now. Affected CPUs are the ADSP210x, TMS3201x, TMS3202x, PIC16C5x, and CCPU. All cores have been modified to fully split program and data memory. All drivers using these cores now specify explicit program and data memory maps. This also gets rid of a ton of ugly macros used in memory maps. [Aaron Giles]
- 0.37b9             : The CCPU core are now full 16-bit cores. This fixes the input ports on the Cinematronics games [Aaron Giles].
-  6th September 2000: Brad Oliver fixed a small bug in the CCPU core.
- 0.35b8             : Changed name 'C-CPU' to 'CCPU'.
- NOTES: The CCPU code comes from the Retrocade emulator (1998).
- GAMES: Space Wars (Cinematronics 1978), Barrier (Vectorbeam 1979), Armor Attack (Cinematronics 1980), Star Castle (Cinematronics 1980), Demon (Rock-ola 1982)





6.    Intel

6.1   I8035

- 0.121u3            : Couriersud corrected a potential issue if more than one 8039/8035 is used by a driver. Also should fix a potential inconsistency between saving and loading a state.
- 27th July      2003: Olivier Galibert fixed a bug in the jump addressing in the i8035 CPU core.
- 20th June      2001: Quench adjusted the way in which reading ports works in the i8035/39/48 CPU core.
- NOTES: The Emulation of the I8035 sound CPU based on the 8048 emulator by Dan Boris
- GAMES: Radar Scope (Nintendo 1980), Donkey Kong (Nintendo 1981), Astro Blaster (Sega 1981)
- SOURCE: i8039.c
- PCB: W8035 (Spcforce), MBL8035N (MCU, RAM 64byte, ROM N/A) ShootingGallery


6.2   I8039

- 0.124u3            : Wilbert Pol fixed I8039 DAA instruction when A is > 0xF9.
- 0.122u6            : Couriersud fixed regression on i8039 T1 counter mode. i8039.c/mario.c updates [Couriersud]: Fixed movd instructions, add MB8884 and M58715 cpu types, moved timer hack to M58715, added ram_mask for internal ram access, added R.A11 as 'M' to dasm flags, added EA "IO" port, mario now uses M58715 as sound cpu, hooked up EA line for M58715, fixed portA startup value and documented hardware changes to use a I8039 on a mario board.
- 0.121u3            : Couriersud corrected a potential issue if more than one 8039/8035 is used by a driver. Also should fix a potential inconsistency between saving and loading a state.
- 0.112              : Minor cleanup to the 8039 disassembler [Nathan Woods].
- 0.107u2            : Aaron Giles fixed bug in 8039 CPU handling of A11 latch.
- 0.104u7            : Aaron Giles updated the i8039 disassembler to the new interface.
- 0.78u4             : Aaron Giles fixed incorrect address bus widths on the I8039 CPU core.
- 0.71u3             : Olivier Galibert fixed i803x jumps.
- 16th January   2002: Quench corrected the internal behaviour of interrupt handling in the i8039 CPU core.
- 20th June      2001: Quench adjusted the way in which reading ports works in the i8035/39/48 CPU core.
- 0.36b12            : Nicola Salmoria added preliminary 8039 + DAC sound in Finalizer.
- 0.35b2             : Brian Stern fixed some bugs in the I8039 emulation.
- 0.34b4             : Dan Boris fixed bug in the I8039 external interrupt handling.
- 0.33b7             : Andrea Mazzoleni added the I8039 to the debugger, using Mike Cuddy's disassembler.
- 0.30               : 8039 emulator, and _emulated_ sound in Donkey Kong, Donkey Kong Jr. and Mario Bros. Since the boards also use discrete circuits to generate sound, some samples are still needed to get complete sound support. Also partial sound in Radarscope [Ron Fries, Dan Boris, Mirko Buffoni].
- 0.20               : Ron Fries created a new set of Donkey Kong samples, using Mike Cuddy's 8039 emulator. The new samples no longer have static, they are aliased and louder.
- NOTES: Based on the I8048 emulator by Dan Boris
- GAMES: Carnival (Sega 1980), Mario Bros. (Nintendo 1983), Juno First (Konami 1983), Gyruss (Konami 1983), Finalizer (Konami 1985)
- PCB: TMP8039P-6 (Megazone), OKI MSM80C39RS = 8039 sound CPU (Wilytowr), D8039LC (Junofrst)


6.3   I8X41

- 0.109u5            : Aaron Giles converted the i8x41 disassemblers to the new format and added step in/out support where it was obvious.
- 0.90               : Juergen Buchmueller fixed crash in i8x41 cpu core reading uninitialized internal RAM.
- 13th January   2003: Quench improved the i8x41 CPU core.
- 0.37b13            : Added cpu\i8x41\i8x41.c and 8x41dasm.c.
-  8th February  2001: Juergen Buchmueller managed to fix some 8x41 emulation bugs and got a few DECO Cassette system games running.
- 31st January   2001: Juergen Buchmueller further fixed the i8x41 core and hooked some parts of the DECO cassette system to the Burger Time driver.
-  9th October   1999: Juergen Buchmueller sent in an Intel 8x41 core.
- NOTES: The I8x41 core emulates the UPI-41/8041/8741/8042/8742. The work based on Intel(tm) UPI(tm)-41AH/42AH Users Manual
- GAMES: All DECO Cassette games


6.4   I8048

- NOTES: Based on the I8048 emulator (C) 1997 by Dan Boris
- GAMES: Sai Yu Gou Ma Roku (Japan bootleg 1) - China Gate (1988) clone
- SOURCE: cpu\i8039\i8039.c



6.5   8080

- 0.104u5            : Kopromaster fixed incorrect flags emulation in the 8080 CMA instruction.
- 0.72u2             : Changed name 'I8080' to '8080'. Included 8080 core updates from MESS.
- 0.62               : Changed name '8080' to 'I8080'.
- 21st July      2002: Krzysztof Strzecha fixed some problems in the I8080 CPU core.
- 17th June      2000: Juergen Buchmueller fixed the cycle counts in 8080/8085A CPU cores.
- 0.35b8             : Changed name 'I8080' to '8080'.
- SOURCE: cpu\i8085\i8085.c
- GAMES: Midway - Gun Fight (1975), Sea Wolf (1976), Laguna Racer (1977), Space Invaders (1978)
- PCB: 8080A (Polaris, Sheriff, Stactics), Mitsubushi M5L8080AP (Dynadice), National Semiconductor 822-INS8080AD-C8080A (Invaders), P8080A (Ozmawars)


6.6   8085A

- 0.123u4            : Nicola Salmoria fixed 8085 RST75 not working with PULSE_LINE. According to datasheet, RST7.5 is latched on rising edge, while the other maskable interrupts are sampled.
- 0.122u7            : i8085.c updates [Couriersud]: 8085 has an internal clock divider by 2. Changed i8085.c to reflect this for I8085. I8080 still at 1. Changed driver clocks to reflect internal clock divider. Added some FIXME: Comments where clocks for I8085 are outside specs. Zsolt Vasvari fixed saving I8085 callbacks across a reset. Added 'pull' callback for the SID pin. This is needed by the Red Alert voice board.
- 0.115u3            : John Allentown fixed bug in INR/DCR opcodes in 8085 CPU core.
- 0.111u6            : Zsolt Vasvari removed archaic i8080_EXACT flag from the 8085 core.
- 0.111u2            : Tomasz Slanina fixed SIM opcode in i8085 emulator.
- 0.109u5            : Aaron Giles converted the i8085 disassemblers to the new format and added step in/out support where it was obvious.
- 23rd September 2003: Nathan Woods forwarded a fix from MESS to the CMPSW instruction in the i86 CPU core.
-  5th September 2003: Krzysztof Strzecha add INR r, DCR r, ADD r, SUB r and CMP r. Instructions should affect parity flag. Fixed only for non x86 asm version (#define i8080_EXACT 1).
- 0.72u2             : Changed name 'I8085A' to '8085A'. Included 8080 core updates from MESS.
- 19th August    2003: Tomasz Slanina re-submitted some old i8085 CPU core bugfixes done originally by Krzysztof Strzecha.
- 0.62               : Changed name '8085A' to 'I8085A'.
-  5th March     2002: Juergen Buchmueller added the undocumented opcodes to the 8085a CPU core.
- 23rd June      2002: Acho A. Tang submitted an update to the i8085 core, fixing the interrupt system.
- 15th April     2001: Zsolt Vasvari fixed an i8085 CPU core bug which affected Meteoroids title screen.
- 17th June      2000: Juergen Buchmueller fixed the cycle counts in 8080/8085A CPU cores.
- 0.33b4             : I8085 emulator [Juergen Buchmueller].
- SOURCE: cpu\i8085\i8085.c
- GAMES: Phoenix (Amstar 1980), Meteoroids (Venture Line 1981), Red Alert (Irem 1981)
- PCB: D8085A (Triv Quiz), NEC D8085AHC (Paranoia), M5L8085AP (Bullfgtr, Dwarfd), AM8085APC (Phoenix)


6.7   8086

- 0.119u3            : Philip Bennett changed the following x86 instructions to read/write an entire word rather than two separate bytes: mov_axdisp, mov_dispax, stosw (8086 only) and rep stosw (8086 only). Also tweaked handling of x86 WAIT instruction.
- 0.118u3            : Added cpu\i86\i86mem.c. Changed name 'I8086' to '8086'. Changed I8086 CPU core to use a 16-bit data bus. Updated affected drivers: gottlieb, leland, tx1, fantland, tetriunk. Cleaned up naming of CPUs (i86 -> i8086, etc.) [Aaron Giles].
- 0.101u3            : Nathan Woods updated i86 and i286 cores to hook into the new i386 disassembler.
- 0.89u5             : Nathan Woods fixed disassembler calls in the I86 and I286 core, so that instructions are not falsely disassembled as 32-bit.
- 0.87u4             : Juergen Buchmueller fixed a cut+paste bug in cpu\i86\instr86.c. Changed SUBB() macro to SUBW().
- 0.87u3             : Removed cpu\i86\i86dasm.c.
- 0.75               : Nathan Woods fixed REP CMPSW so that it uses words and not bytes (cpu\i86\instr86.c).
-  1st August    2003: Nathan Woods added state saving support to the i86 and i286 CPU cores.
- 0.70u2             : Nathan Woods fixed i86 DAA opcodes and more.
- 15th June      2003: Colin Howell, Nathan Woods and Bryan McPhail fixed the DAA opcode in the i86 CPU core.
- 0.62               : Changed name 'I86' to 'I8086'.
- 0.57               : Julien Frelat fixed OUTSB/OUTSW bugs in I86 emulation.
- 26th November  2001: Julien Frelat submitted a bugfix for the (REP) OUTSB and OUTSW opcodes for the i86 CPU core.
- 15th April     2001: Nicola Salmoria fixed an i8086 CPU core bug which broke the high score screen in Q*Bert.
- 0.37b10            : Added cpu\i86\i86.txt.
- 26th November  2000: Peter Trauner fixed several issues in the i86 CPU core and sent in a preliminary version of runtime driver loading support, allowing drivers and CPU and sound cores to be loaded separately from the executable when needed.
- 0.37b3             : Lots of changes to some CPU cores (mostly i86) [Peter Trauner, Juergen Buchmueller, Aaron Giles].
- 13th May       2000: Aaron Giles sent in another i86 core / Gottlieb drivers update fixing some bugs.
- 11th May       2000: Aaron Giles sent in some major functionality updates to the 8086, 80186 and 80286 cores.
-  2nd June      1999: Nicola sent in a preliminary Shanghai driver, but it stumbles on a bug of the i86 core.
- 0.35b1             : Juergen Buchmueller fixed several bugs in the I86 emulator.
- 0.34b5             : I86 disassembler for the debugger, based on code by Robin Hilliard [Andrea Mazzoleni].
- 0.33b6             : Fixed bug in the I8086 emulator which caused MACH3 not to work. MACH3 now does the attract mode, but it will never be playable without the laser disc.
- 0.31               : Fabrice Frances fixed a bug in the 8086 emulator which caused unexpected deaths in Krull. Fabrice Frances cleaned up the I86 emulator, including 286 instructions (but with 8088 timing).
- 0.24               : Fabrice Frances submitted a new faster I86 emulator. The entire I86 directory is changed, and most of Gottlieb games are now faster.
- 0.18               : Fabrice Frances submitted a much faster version of the 8086 emulation. Q*Bert now runs at full speed with -frameskip 1 on my 486/100.
- 0.17               : Fabrice Frances submitted an 8088/8086 CPU emulator. Initial work based on David Hedley's IBM PC Emulator (pcemu).
- NOTES: 20 bit adress bus, 16 bit data bus and registers. 6 bytes prefetch queue.
- SOURCE: emu\cpu\i86.c
- GAMES: Q*bert (Gottlieb 1982), Mad Planets (Gottlieb 1983), Curve Ball (Mylstar 1984)
- PCB: NEC D8088 (Qbert), AMD P8088 (Borntofi)


6.8   8088

- 0.118u3            : Changed name 'I8088' to '8088'.
- NOTES: The I8088 is a I8086 with 8 bit data bus. Prefetch queue only 4 byte, and refilled when 1 byte empty.
- GAMES: M.A.C.H. 3 (Mylstar 1983 - Laser Disc game). MAME uses the I8086.
- PCB: P8088-1 (Hotblock), AMD P8088-2 (Borntofi)


6.9   I80C86/I80C88
- NOTES: Theses are I8086/8088 CPU's and the CPU command "mov cs, " are ignored.


6.10  80186

- 0.122u6            : Aaron Giles cleaned up leland clocks a little. Made the i186 divide-by-2 clock internal.
- 0.118u3            : Changed name 'I80186' to '80186'.
- 0.62               : Changed name 'I186' to 'I80186'.
- 0.37b3             : I186 support [Peter Trauner, Juergen Buchmueller, Aaron Giles].
- 11th May       2000: Aaron Giles sent in some major functionality updates to the 8086, 80186 and 80286 cores.
- NOTES: The I80186/I80188 has integrated pic8259, pit8253, dma8253 (but not at standard pc addresses) and additional instructions.
- GAMES: Leland - Quarterback (1987), Viper (1988), Pigout (1990), Danny Sullivan's Indy Heat (1991)
- SOURCE: emu\cpu\i86.c


6.11  I80188
- NOTES: The I80188 has a 8bit data bus.
- SOURCE: I86.c


6.12  I80286

- 0.110u2            : Barry Rodewald fixed flags access in the i286 core (cpu\i86\i286.c).
- 0.103              : Nathan Woods changed i286 core to use the same INPUT_LINE_A20 that the i386 core uses.
- 0.101u3            : Nathan Woods updated i86 and i286 cores to hook into the new i386 disassembler.
- 0.89u5             : Nathan Woods fixed disassembler calls in the I86 and I286 core, so that instructions are not falsely disassembled as 32-bit.
- 0.79u3             : Nathan Woods updated the I286 CPU core to MAME 0.79.
- 21st February  2004: Nathan Woods sent in another miscellaneous patch for I286 and M6502 CPU cores.
- 11th February  2004: Nathan Woods updated the MESS specific CPU cores (such as I286, M4510 and M6509) with latest changes.
-  1st August    2003: Nathan Woods added state saving support to the i86 and i286 CPU cores.
- 11th May       2000: Aaron Giles sent in some major functionality updates to the 8086, 80186 and 80286 cores.
- 0.31               : Fabrice Frances cleaned up the I86 emulator, including 286 instructions (but with 8088 timing).
- NOTES: The I80286 is not supported yet. MAME uses the I8086 emulator. The I80286 is a 80186 with additional instructions and 24 bit address bus
- SOURCE: emu\cpu\i86.c



6.13  I386

- 0.122u5            : Aaron Giles added support for outputting 64-bit target addresses in the i386dasm.
- 0.119u4            : Fixed several issues in the i386 core [Couriersud]: The INTR-line for i386 is a "level" line; changed interrupt handling to trigger on asserted line. In 32bit mode, determine trap/interrupt from gate-header. Interrupt line is read during two bus cycles. Adjust CYCLES accordingly.
- 0.119u1            : Aaron Giles fixed a few more 64-bit disassembler problems in i386dasm.c.
- 0.118u4            : Aaron Giles significantly improved the i386 disassembler. Changed it so that it no longer outputs 'byte ptr' except for ambiguous cases. Updated for full 64-bit disassembly support. Added support for the full IA32 opcode matrix as specified by recent Intel manuals, including all SSE opcodes and variants.
- 0.114u4            : Aaron Giles improved access to system registers in i386 core. Added explicit caching of segment data and flags. Fixed several minor issues.
- 0.114u2            : Aaron Giles added preliminary 64-bit disassembly support to i386dasm.c.
- 0.103u5            : Nathan Woods added support for the various x86 8-bit and 16-bit derived registers, as hidden registers in the i386 core. Nathan also changed several byte operands in the i386 disassembler to be diassembled as unsigned rather than signed.
- 0.103u4            : Intel i386/i486/Pentium update [Nathan Woods]: Fixed A20 mask implementation. Added A20 mask to debugger translate callback. Implemented Pentium opcode CMPXCHG8B. Fixed XADD, and added support for the 8 and 16 bit variants.
- 0.103u3            : Nathan Woods added SegBase() and SegLimit() functions to the i386 core debugger.
- 0.102u2            : Nathan Woods fixed 16-bit i386 disassembly so it stays within the current segment.
- 0.102u1            : Nathan Woods changed some i386 disassembly parameters to be unsigned.
- 0.101u3            : Aaron Giles fixed FPU decoding and a few other minor issues in the i386 disassembler.
- 0.101u2            : Aaron Giles cleaned up i386 disassembler to produce Intel-standard output.
- 0.100u4            : Added cpu\i386\cycles.h, i386ops.h, i486ops.c, pentops.c and x87ops.c. Removed cpu\i386\i386op16.h and cpu\i386\i386op32.h. Updates to the I386 core [Ville Linde]: Added i486, Pentium and Cyrix MediaGX CPUs. Replaced the opcode tables with a dynamically built one. Rewrote the cycle counting to support different CPUs. Added page translation. Tons of bugfixes. Also updated the SPI driver to work with these changes.
- 0.98u2             : Ville Linde and David Haywood fixed the i386->z80 communication in the Seibu SPI driver. This fixes the flash rom update and should also fix any remaining hangs/pauses. The flash rom update should take around 5 minutes. Now all games should have proper sample data.
- 0.91u1             : Bryan McPhail added support for encrypted opcodes in i386 disassembler (for Irem games).	Added some of the NEC V series instructions into i386 disassembler.
- 0.90               : Nathan Woods fixed the i386 algorithm for identifying 32-bit segments, near branches now won't force a segment reload, implemented RET imm16 under 16-bit mode, ixed SBB instruction (the borrow was deducted from the second operand, not the result), fixed LDS, LSS, LES, LFS, LGS under 32-bit mode and partially implemented LLDT, LTR, CLTS, WAIT and MOV dr instructions.
- 0.89u6             : Nathan Woods fixed I396 LMSW opcode and the disassembler will now list segment prefixes when appropriate.
- 0.89u5             : Nathan Woods implemented SMSW instruction in the I386 core and marked retf instruction as DASMFLAG_STEP_OUT in the I386 disassembler.
- 0.89u4             : Nathan Woods added support for DASMFLAG_STEP_OVER and DASMFLAG_STEP_OUT flags in i386 core.
- 0.88u4             : Aaron Giles added a "PC" register to the I386 core so that it should work in the new debugger.
- 0.84u5             : Ville Linde improved i386 disassembly format.
- 0.84u3             : Ville Linde added some missing i386 opcodes.
- 0.82u3             : Nathan Woods revamped interrupt handling; a bonafide line is now implemented and also a IRQ callback (i386ops.c). Fixed also CALL absolute instruction under 16 bit mode (i386op16.c).
- 0.82u2             : i396 enhancements [Nathan Woods]: CALL16 opcode will now only adjust IP instead of EIP when in 16-bit mode. Minor bug fix in RETF opcode. Changed REP and REPNE opcode implementations to use the same code. INTO will now interrupt even if IF is zero.
- 0.82               : Nathan Woods implemented zeroing out A20 lines, XLAT opcode, state save support and DAA fixes. And the Unknown instructions now disassemble as '???'.
- 0.81u8             : Nathan Woods implemented partially far CALL and JMP instruction (i386op16.c), PUSH rm8 instruction (i386ops.c). Implemented usage of segment limits (or whatever they are called) and 16-bit interrupts, added initial values of IDTR are now properly specified, i386_interrupt() is no longer called when i386_set_irq_line() is called with a state of zero and actual cycle count is now returned (cpu/i386/i386.c). Added a distinction between maskable and non maskable interrupts (like int 3, illegal instruction etc) and a distinction between invalid and unimplemented instructions. Invalid instructions raise an interrupt, and unimplemented instructions call osd_die() for now. i386_set_irq_line() will no longer raise an interrupt when passed with state=0. Various string intructions now use SI/DI instead of ESI/EDI when in 16-bit mode. Implemented LOCK and RETF. Fixed a bug in LMSW and minor disassembler fixes. Ville Linde bugfixed Nathan's REP prefix handling.
- 0.81u7             : Added cpu\i386\i386dasm.c. Ville Linde wrote a new i386 disassembler. DASM386 wasn't always showing stuff correctly, and now the i386 core can be compiled without i86.Improved i386/z80 interleaving. This should help with the small pauses. Fixed some stuff in the i386 core. These don't seem to affect the SPI games, but should help with MESS. Improve the i386 and added DS and SS segment prefixes. renamed fs,gs -> segment_FS, segment_GS, added INTO opcode, regression tested and fixed AAS opcode (incorrect behavior in Intel docs), added AAA opcode (with correct behavior), added AAD and AAM opcodes, added CMC opcode, added SETALC opcode which is undocumented, removed a non-existing PUSH8 opcode from groupFE_8, regression tested and fixed SHLD and SHRD opcodes, fixed AF flag calculation and fixed AF flag in SUB and DEC opcodes. Nathan Woods fixed a bug in i386_set_info() when changing the EIP register (cpu\i386\i386.c). Implemented ES, BOUND, DAA, DAS, AAS, INSB, INSW, OUTSB, OUTSW, LES, LDS, HLT, LSS, LFS, LGS, IMUL with a 32 bit adjustment. Fixed some compilation errors under non-GCC compilers. Added also a check enabled when MAME_DEBUG is defined that raises an error if the CPU core executed a negative cycle count in cpuexec.c.
- 0.81u6             : Nathan Woods partially implemented i386 INT, INT3, ES segment override, an IMUL variant, LMSW, a minor 16 bit bug fix and coprocessor escape instructions. Ville Linde found and fixed bugs in several shift/rotate instructions. This corrects the bosses in Raiden Fighters. Completely rewrote REP/REPNE prefix handling. Fixes the following: Battle Balls attract mode runs correctly now, balls no longer all the same color in-game in Battle Balls, E-Jan now coins up and Viper Phase 1 is now playable (with encrypted gfx).
- 0.81u5             : Nathan Woods implemented i386 in/out instructions and converted printf()/exit() combination of calls to osd_die(). osd_die() messages now get sent to both logerror and console output.
-  8th April     2004: Nathan Woods implements the in/out instructions in the i386 CPU core.
- 0.81u4             : SPI / i386 updates [Ville Linde]. raidnfgt now runs normally and correctly through attract mode and gameplay, modulo the encrypted graphics. Still kinda mesmerizing. viperp1 starts to boot now, but doesn't get very far.
- 0.81u3             : Ville Linde fixes the i386 core and improve the SPI system. Senkyu and E-Jan High School now do something.
- 0.81               : i386 CPU core (used by the SPI driver) [Ville Linde].
-  1st April     2004: Ville Linde sent in another update to the i386 CPU core and the Seibu SPI driver, with better 386/z80 communications (but still not correct) and some cleanup.
- 30th March     2004: Tomasz Slanina fixed a unnecessary write in the bit test opcode in the i386 CPU core.
- 28th March     2004: Ville Linde submitted an i386 CPU core and a Seibu SPI system driver supporting Senkyu / Battle Balls, Viper Phase 1, E-Jan High School, Raiden Fighters and Raiden Fighters 2 which would be playable but the graphics are encrypted, and the sound is also not emulated.
- 0.76u1             : Nathan Woods added a few macros for other miscellaneous X86 opcodes. Added a drc_dasm() call, a debug call that uses MAME's I386 disassembler to disassemble DRC'd code (didn't compile, commented out until fixed).
- SOURCE: cpu\i386\i386.c
- PCB: Seibu SPI - Advanced Micro Devices AM386DX/DX-40, QFP132 (Rfjet), AM386DX/DXL-25, QFP132 (Rdft), Intel NG80386DX25 (Ejanhs, Viprp1)


6.14  I486

- 0.103u2            : I486 CPU patch [Nathan Woods]: Implemented XADD, INVLPG and CMPXCHG instructions and made the opcode table const correct.
- 0.101u2            : Ville Linde fixed time stamp counter in the Pentium core.
- 0.100u4            : Updates to the I386 core [Ville Linde]: Added i486, Pentium and Cyrix MediaGX CPUs. Replaced the opcode tables with a dynamically built one. Rewrote the cycle counting to support different CPUs. Added page translation. Tons of bugfixes. Also updated the SPI driver to work with these changes.
- SOURCE: cpu\i386\i386.c
- PCB: 80486 (Pangofun)



6.15  I960

- 0.122u6            : Ernesto Corvi, ElSemi fixed RET instruction on the i960 core.
- 0.119u1            : Ernesto Corvi fixed SCALER, SCALERL and ATANRL opcodes in the i960 core.
- 0.109u5            : Aaron Giles converted the i960 disassemblers to the new format and added step in/out support where it was obvious.
- 0.106u9            : i960 bugfixes [Ville Linde].
-  2nd June      2006: Ville Linde - One of my i960 core fixes fixed the problems Dead or Alive was having.
- 0.104u4            : Aaron Giles fixed bug i9600104u2ora (The debugger errors out when you try to run a game using the i960 cpu core. It displays the following error "disasm_generate_bytes: unknown size = 32".)
- 0.88u1             : R. Belmont and Stephan Cecchinel fixed errors in atanr and logepr opcode.
- 0.88               : ElSemi fixed bug in movl opcode.
- 17th October   2004: R. Belmont - ElSemi found a major i960 core bug. That combined with some work I was doing to make a lot of the Model 2 games run better.
- 0.87u2             : i960 updates [R. Belmont]: Added spanbit. Fixed error noted by ElSemi in spanbit and scanbit. Added non-queued interrupts to support games with the interrupt table in ROM (this fixes the colors and hanging in Sky Target, and Pilot Kids will need it too). Added the ability for read/write handlers to declare themselves "noburst", for memory regions which don't auto-increment the address on i960 bulk transfers. General cleanup of the interrupt handling to remove duplicated code. There should be no functional difference.
- 0.87u1             : i960 updates [R. Belmont]. Added support for the following opcodes: nor, addc, subc, atanr, sinr, cosr, tanr, atanrl, logrl, sinrl, cosrl and tanrl. Added those and some others to the disassembler. Added parens for the compiler warning. Fixed stt to only store 3 words instead of 4. Added logepr and cvtri. Fixed cmpr and cmprl - they were comparing garbage instead of the correct registers. Added disassembly for movrl. Added scanbit. Rewrote flushreg, it was *totally* wrong before. HOTD now runs, among others. Added hack to divo so divide by zero doesn't crash MAME (some games read back 0 from the not-yet-existing DSP and do this). More disassembler improvements. Added NAND, EDIV, SCALER, SCALERL, ROUNDR, ROUNDRL, EXPRL, MOVRE, and CPYSRE opcodes. Fixed some errors in interrupt handling. Solves corrupt graphics in fvipers and crashes in fvipers, schamp, and dynamcop. Added REMR opcode.
- 29th September 2004: R. Belmont - Added Sky Target (which refuses to set it's palette properly - go figure). Also fixed an i960 core bug that was causing crashes and corrupt graphics in Fighting Vipers and Sonic Championship, among other things.
- 27th September 2004: R. Belmont - A few games that needed some additional i960 core work...Daytona USA, Gunblade, Topskater, Virtual One and Desert Tank.
- 25th September 2004: R. Belmont - You have the right to remain silent! (3 "cop" themed games are now running) - Dynamite Cop, vcop. Actually, being silent is boring so I added sound to all the Model 2 games.
- 24th September 2004: R. Belmont - Even more Model 2 and i960 work... dynabb, The House of The Dead, fvipers, schamp, Zero Gunner and vf2.
- 22nd September 2004: R. Belmont - More Model 2 and i960 work (no new pictures yet, but many more games now start up - Speed Racer). A very nice side effect of the i960 work has surfaced however...
- 21st September 2004: R. Belmont - Added a bunch of i960 opcodes and started picking up one of the pieces left by Olivier Galibert's disk failure (Sega Model 2). Indy 500, Behind Enemy Lines and Virtua Striker will going to be a "Modeler" style driver until further notice. 2D layers, inputs, and sound/music only, IOW.
- 0.85u1             : R. Belmont fixed debugger crash when using F10 with the i960 core.
- 0.84u2             : R. Belmont fixed a brown-paper-bag bug where the PC and AC registers were getting swapped on return from interrupts, rewrote the frame cache mechanism using a simple FIFO concept (Final Lap R now runs further) and aligned reads and writes now use the full-size paths through the core instead of always breaking everything down into bytes.
- 0.84u1             : R. Belmont fixed bugs in the i960 concmpo, concmpi and modi instructions, added "text" and hex displays of the AC register for debugging and TESTx opcodes to the disassembler.
- 0.82               : Olivier Galibert added a bunch of floating point opcodes and stylistic fixes to the i960 core.
- 0.81u9             : Olivier Galibert cleanups the i960 core, so the disassembler compiles.
- 0.81u8             : i960 cpu core / disassembler [Olivier Galibert, R. Belmont, Farfetch'd].
- 24th April     2004: R. Belmont sent in a i960 CPU core and disassembler written by him, Olivier Galibert and Farfetch'd, and a preliminary (not working) Namco System FL driver with thanks to information from ElSemi.
- 21st April     2004: R. Belmont - Olivier Galibert started writing a brand-new i960 CPU core for MAME (you get zero guesses why). I added interrupt support and several opcodes and started working on a Namco System FL driver, meaning Speed Racer.
- NOTES: The Intel I960 is a 32Bit RISC processor (QFP132). Richard Mitton wrote a core for the I960 (virtua I960).
- SOURCE: cpu\i960\i960.c
- EMULATOR: Nebula Model 2
- PCB: NG80960KA = i960 (Speedrcr, NamcoFL-System), NG80960KB = i960 (Dead or Alive), BehindEnemyLines, ManxTT, DaytonaUSA and VirtuaCop1/2


6.16  PENTIUM
- 0.100u4            : Updates to the I386 core [Ville Linde]: Added i486, Pentium and Cyrix MediaGX CPUs. Replaced the opcode tables with a dynamically built one. Rewrote the cycle counting to support different CPUs. Added page translation. Tons of bugfixes. Also updated the SPI driver to work with these changes.
- NOTES: Intel Pentium
- SOURCE: cpu\i386\i386.c + drivers\taitowlf.c
- GAMES: Psychic Force 2012 (Taito 1997)


6.17  MEDIAGX
- 0.100u4            : Updates to the I386 core [Ville Linde]: Added i486, Pentium and Cyrix MediaGX CPUs. Replaced the opcode tables with a dynamically built one. Rewrote the cycle counting to support different CPUs. Added page translation. Tons of bugfixes. Also updated the SPI driver to work with these changes.
- NOTES: Cyrix MediaGX
- SOURCE: cpu\i386\i386.c + drivers\mediagx.c
- GAMES: Area 51: Site 4 (Atari Games 1998)
- PCB: Cyrix CX5510Rev2, QFP208 (A51site4)




7.    Texas Instruments


7.1   TMS7000
- 0.111u2: Added TMS7000 emulator [Tim Lindner].
- SOURCE: cpu\tms7000\tms7000.c


7.2   TMS99xx
- 0.109u4            : Aaron Giles cleaned up TMS99xx core debugging and converted to new disassembler syntax, adding step over/out support.
- 0.96u1             : Brad Oliver fixed PPC assembly code in the TMS99xx core.
- 0.36b13            : Raphael Nabet added other members of the TMS99xx family.


7.21  TMS9900
- 0.119u3            : Removed cpu\tms9900\9900stat.h.
- 0.95u4             : Added cpu\tms9900\ti990_10.c. Raphael Nabet added several TMS9900 enhancements and variants from MESS.
-  3rd December  2003: Brad Oliver fixed the inline PPC assembly in the TMS9900 CPU core.
- 0.69               : Andrea Mazzoleni adds a test for the GNU C compiler to skip some POWERPC inline assembler not compatible with the GNU assembler format (cpu/tms9900/9900stat.h + 99xxstat.h).
- 0.34b6             : TMS9900 emulator [Andy Jones, based on original code by Ton Brouwer].
- NOTES: This is the original processor from 1976.


7.22  TMS9940
- NOTES: The embedded version (1979) of the TMS9900.


7.23  TMS9980A/TMS9981

- 0.77u3             : TMS9900 inline asm update [Brad Oliver]. The syntax for the inline ppc assembly in the tms9900 core has changed slightly.
- 0.36b11            : Raphael Nabet made some changes to the TMS9900 emulation that completely screw up Cosmic Guerilla.
- 0.36b9             : Raphael Nabet updated the TMS9900 emulator.
- 28th September 1999: Raphael Nabet sent in another TMS9900 update.
-  1st September 1999: Raphael Nabet sent in an update to the TMS9900 core.
- 10th May       1999: Jürgen fixed a TMS9900 debugger bug.
- 0.34b6             : TMS9900 emulator [Andy Jones, based on original code by Ton Brouwer].
- NOTES: 8-bit variant of the TMS9900. Two version: TMS9980A and TMS9981 with an extra clock and simplified power supply.
- GAMES: Cosmic Guerilla (Universal 1979), Looping (Venture Line 1982), Sky Bumper (Venture Line 1982)
- PCB: TMS9980 (Looping), TMS9980ANL-Y8130 (Supertnk)


7.24  TMS9995

- 0.37b12            : TMS9995 emulator.
- NOTES: Improved TMS9980 and quite faster as a TMS9900.
- GAMES: Venture Line - Looping (1982), Sky Bumper(1982)

7.25  TMS99100
- 0.80: Nathan Woods added an entry for the TMS99100 processor in cpuintrf.h

7.26  TMS99105A
- NOTES: late variant, widely improved, 1981

7.27  TMS99110A
- NOTES: Same as above, with floating point support, (c) 1981



7.3   TMS32025

- 0.114u1            : Aaron Giles fixed internal timer counting in the TMS32025 core. This makes the music in Cool Pool and 9 Ball Shootout bearable.
- 0.109u5            : Aaron Giles converted the tms32025 disassemblers to the new format and added step in/out support where it was obvious.
- 0.96u2             : Aaron Giles fixed bug in MAC instructions in the TMS32025 core. Fixed cycle counting problems that led to inaccurate internal timers. Also added the ability to specify internal read/write handlers for CPUs so that the new debugger can view internal RAM. Hooked this up for the TMS32025 core.
- 0.86u1             : Phil Stroffolino fixed DSP math bugs. The DSP communications RAM latch mode hooked up in the namcos22 driver, this fixes graphics for many titles.
- 0.81u8             : Phil Stroffolino fixed lst and lst1 opcodes and the "ignore ARP" hack has been replaced with a better hack, that doesn't interfere with indirect addressing. Preliminary serial I/O support has been added, to update DRR/DXR on RINT and XINT interrupts.  set_irq_line() no longer masks the lines with 0x7; this allows external triggering of RINT/XINT interrupts.
- 14th April     2004: Phil Stroffolino and Quench fixed another bug in the sblk opcode in the TMS32025 CPU core.
- 13th April     2004: Quench fixed a bug in the TMS32025 CPU core in which internal RAM was being dynamically reallocated at every call to the reset handler.
-  7th April     2004: Phil Stroffolino fixed a bug in the ldpk opcode in the TMS32025 CPU core.
- 0.63               : Added cpu\tms32025\tms32025.c, \32025dsm.c and \dis32025.c. TMS32025 CPU core [Quench].
-  2nd January   2003: Olivier Galibert sent in a somewhat updated version of the TMS32025 CPU core together with some improvements to the Taito Air system driver, making Top Landing display some polygons but it is still far from perfect.
- 26th December  2002: Quench added timer emulation to the TMS32025 CPU core.
- 18th November  2002: Quench sent in a TMS32025 CPU core and a preliminary Taito AIR system driver, but graphics emulation is not complete so it does not work very well.
- SOURCE: cpu\tms32025\tms32025.c
- GAMES: Taito - Top Landing (1988), Air Inferno (1990), Prop Cycle (1996)
- PCB: TMS320C25 (Topland), TI320C25 DSP (printed as C71), WYBUX1G1  QCC68 = TMS320C25 int 544 word RAM, 4k ROM (Aircombj)


7.4   TMS32026

- 0.78u4             : Aaron Giles added a TMS32026 entry and reworked the handling of internal RAM to work in the new system. This means the Taito Air system is now back to its former state.
- SOURCE: cpu\tms32025\tms32025.c
- GAMES: Cool Pool (Catalina 1992), 9-Ball Shootout (E-Scape EnterMedia 1993)
- PCB: 320C26 (9ballsht)


7.5   TMS32031

- 0.122u2            : TMS3203x core updates [Aaron Giles]: Fixed interrupt handling. Added support for edge-triggered interrupts on '32. Expanded interrupt support for the '32. Updated drivers using TMS3203x core to deassert interrupts. Added externally accessible functions for converting '3x floating point format. Updated gaelco3d driver to use new functions.
- 0.120u4            : Aaron Giles fixed TMS32031 ABSF opcode to work as documented and not produce a proper negative and fixed display of TMS32031 floating point registers in the debugger.
- 0.120u2            : Aaron Giles added NORM implementation to the TMS32031 core.
- 0.113u3            : Couriersud added save state support to TMS32031.
- 0.109u5            : Aaron Giles converted the tms32031 disassemblers to the new format and added step in/out support where it was obvious.
- 0.102u1            : Aaron Giles added new inline math functions to mamecore.h, along with mechanisms for the OSD layer to override them with platform-specific variants: count_leading_zeros, count_leading_ones, and fixed_mul_shift. Updated the TMS32031 core to make use of the first two.
-  2nd March     2004: Aaron Giles - After getting Radikal Bikers working well, I decided to figure out what was up with Surf Planet. Turns out they were relying on unspecified behavior of the TMS32031 by placing a CALL statement at the end of a repeat block. They tell you several times in the docs for the CPU never to do this, but hey, I guess if it works more power to them. With that fixed and some rendering tweaks, I'm currently getting about 30-50% of full speed on my 3GHz machine. If I turn off bilinear filtering and run at half resolution, both games are playable near 100%. Of course, I don't have the sound working yet, and that will kill the speed nicely (it's a DCS-like ADSP chip, sorry!)
- 24th February  2004: Aaron Giles removed some test code from the memory system and fixed a bug in the TMS32031 CPU core that caused wrong polygons in Radikal Bikers.
- 16th February  2004: Aaron Giles added support for the IACK and IDLE commands in the TMS32031 CPU core.
- 24th February  2004: Aaron Giles - Fixed a subtle bug in the TMS32031 core that was causing problems with Radikal Bikers. Now at least all the geometry shows up okay. I'm still at a loss to explain alpha blending, Z buffering, or perspective correction. The incomplete driver should be in u2, so if you know some 3D math, feel free to have a look and see if you can't help me figure it out!
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. [Aaron Giles]
-  6th November  2003: Aaron Giles fixed the unmapped memory access logging to show the effective address (taking the address shift into account on CPUs like TMS34010 or TMS32031).
-  5th November  2003: Aaron Giles improved the TMS32031 core a lot, making Offroad Challenge almost playable.
-  8th December  2002: Aaron Giles fixed a lot of things in the TMS32031 CPU core.
- 0.62               : Added cpu\tms32031\tms32031.c and \32031ops.c, \dis32031.c. TMS32031 CPU emulation [Aaron Giles].
- 28th October   2002: Aaron Giles sent in a TMS32031 CPU core and Williams V-Unit driver supporting Cruis'n USA and Cruis'n World complete with perfect sound emulation. P4 - 4 GHz or Athlon XP 4000+ recommended.
- NOTES: The TMS320C31PQL is a 32bit DSP with 33MFLOPs (Primrage)
- SOURCE: cpu\tms32031\tms32031.c
- GAMES: Midway - Cruis'n USA (1994), Cruis'n World (1996), Primal Rage (Atari 1994), T-Mek (Atari 1994)
- PCB: TMS32C031 (DriversEdge), Taito E07-11 TMS320C31, QFP132 (Sidebs2)


7.51  TMS32032
- 0.122u2            : TMS3203x core updates [Aaron Giles]: Fixed interrupt handling. Added support for edge-triggered interrupts on '32. Expanded interrupt support for the '32. Updated drivers using TMS3203x core to deassert interrupts. Added externally accessible functions for converting '3x floating point format. Updated gaelco3d driver to use new functions.
- SOURCE: cpu\tms32031\tms32031.c


7.6   TMS32051

- 0.111u2            : Taito JC driver improvements [Ville Linde]: Various bug fixes and some new opcodes to the TMS320C51 core. Moved video hardware emulation to video/taitojc.c. Implemented 3D hardware emulation.
- 25th December  2006: Ville Linde - One of the most interesting parts of the Taito 3D hardware is the math co-processor that has been integrated into one of the Taito custom chips. The coprocessor does two functions. The first function does 3D point projection to 2D, and was quite straightforward to understand from the DSP disassembly. The second function however, required a lot more head scratching. Eventually I figured out that this function is used to calculate polygon intersection calculations while clipping the polygons against the viewport. The reason why yet another math unit is needed may not be clear at first. But once you look at how the math functions work, it becomes more clear. Both of the math functions are dividing something, and a quick look at the TMS320C51 datasheet reveals that it doesn't have a division unit at all. The emulation of the math co-processor, coupled with some additional TMS320C51 bug fixes gives us almost perfectly working 3D.
- 17th December  2006: Ville Linde - I've been working on fixing bugs in the TMS320C51 core and trying to understand the 3D hardware in Taito's JC System. So far I've managed to figure out the polygon format and texture mapping. As a result Side by Side 2 already shows the road polygons and some other stuff.
- 0.107u3            : Taito JC update [Ville Linde]: Some general improvements to the driver and added some more opcodes to the TMS320C51 core.
- 0.106u9            : Improved the TMS320C51 core [Ville Linde].
- 0.105u1            : Added TMS320C51 cpu core [Ville Linde].
- 10th April     2006: Ville Linde - I picked up the Taito JC System driver again in hopes of getting it to do something interesting. The two major roadblocks were the missing FPU stuff from the M68040 core and the missing TMS320C51 DSP core. The TMS DSP emulation already works well enough that the basic communication and ROM tests are already working. There's also enough of the 68040 FPU emulated that the games won't just crash when they hit FPU opcodes. None of the games still show anything interesting graphics-wise, but progress is progress nevertheless.
- SOURCE: cpu\tms32051\tms32051.c



7.7   TMS34010

- 0.123u5            : Changed TMS34010 to take a screen tag instead of screen number [Zsolt Vasvari].
- 0.115u1            : Aaron Giles added support for misaligned PIXBLT operations in the TMS34010 core. The code still needs cleanup but improves the new JPM driver.
- 0.114u4            : Aaron Giles simplified register and flags management in the TMS34010 core. Reviewed all flag handling and fixed a couple of minor discrepancies.
- 0.114u2            : Aaron Giles cleaned up internal interrupt handling in the TMS34010 core.
- 0.114u1            : Aaron Giles substantially changed the TMS340x0 interfaces to allow the CPU emulator to directly manage the video screen. Glitches in several games are now fixed as a result (for example the flashing screens in NBA Jam are now gone at last).
- 0.113u3            : Philip Bennett changed the TMS340x0 core to clear the HSTCTLH NMI bit on an acknowledge. Philip Bennett fixed display of immediate word and long operands in the TMS340x0 disassembler.
- 0.113u1            : Zsolt Vasvari began converting drivers over to the new more accurate video timing functions (video_screen_* functions instead of cpu_*). This first batch includes all the games using the TMS34010 chip and the Atari games that use atarigen.c.
- 0.113              : Zsolt Vasvari removed cpu_gethorzbeampos() and replaced it with calls to video_screen_get_hpos(). Also changed TMS34010 configuration to take a screen number, and changed atarigen_get_hblank() to take a screen number as well.
- 0.109u5            : Aaron Giles converted the tms34010 disassemblers to the new format and added step in/out support where it was obvious.
- 0.96u3             : Aaron Giles fixed TMS34010 reverse blitters so they didn't perform extraneous source memory fetches.
- 0.96u2             : Aaron Giles fixed window mode 1 in the TMS34010 core, as well as bugs that prevented misaligned stack accesses from working and a bug that didn't force the PC to be 16-bit aligned.
- 0.96               : Added step in/out support to TMS34010 disassembler [Aaron Giles].
- 0.84u5             : Andrea Mazzoleni fixed a memory crash in the TMS34010 core (removed an illegal free()).
-  3rd June      2004: Olivier Galibert fixed a save state crash that occurred in some games that use the TMS34010 CPU.
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. [Aaron Giles]
-  6th November  2003: Aaron Giles fixed the unmapped memory access logging to show the effective address (taking the address shift into account on CPUs like TMS34010 or TMS32031).
- 0.75               : Aaron Giles removed 4x executes per loop which screwed up timing and fixed internal interrupt generation to get consistent timing results.
- 17th January   2003: Aaron Giles added refresh register emulation to the TMS34010 CPU core.
-  6th January   2003: Aaron Giles fixed some things in the TMS34010 CPU core that will be needed for the Art & Magic games.
-  3rd January   2003: Aaron Giles sent in another update that gets the 34010-based games working again after yesterday's changes, and he fixed BattleToads and Hard Drivin' to compute the VBLANK duration appropriately.
-  3rd January   2003: Aaron Giles sent in another update that gets the 34010-based games working again after yesterday's changes, and he fixed BattleToads and Hard Drivin' to compute the VBLANK duration appropriately.
-  2nd January   2003: Aaron Giles fixed VBLANK timing and display interrupt bugs in the TMS34010 CPU core and he fixed Cool Pool so that its graphics no longer flicker.
- 18th November  2002: Nathan Woods added state save support for the TMS34010 CPU core.
- 12th July      2002: Nathan Woods adding save state capability to the TMS34010 CPU core.
-  3rd December  2001: Aaron Giles fixed a few TMS34010 bugs, fixing the missing sprites in Exterminator and fixing the Hard Drivin' crashes.
- 25th September 2000: Aaron Giles fixed some internal TMS34010 bugs.
-  8th September 2000: Aaron Giles sent in a new TMS34010 core with a few bugfixes, and finally officially sent the Hard Drivin' / S.T.U.N. Runner driver.
- 17th August    2000: Aaron Giles sent in updated ADSP2100 and TMS34010 cores, fixing some bugs which affected the Atari polygon games.
- 0.37b5             : Complete rewrite of the 34010 drivers [Aaron Giles].
- 20th July      2000: Aaron Giles fixed some TMS34010 core bugs which might have caused problems with Terminator 2, and he fixed the clipping in DCS emulation.
- 28th January   2000: Zsolt Vasvari fixed speeds in some TMS34010 games and highscores now display in Trog.
-  5th December  1999: Aaron Giles fixed a fast stack code problem in the TMS34010 core.
- 0.36b9.1           : Aaron Giles fixed a few bugs in the TMS34010 games.
- 0.36b9             : Several changes and improvements to the TMS34010 emulation and to the Williams games using CVSD sound [Aaron Giles].
- 14th November  1999: Aaron Giles fixed some TMS34010 graphics bugs.
- 13th November  1999: Aaron Giles sent in a TMS34010 update with accurate timing, more functionality and he also sent in a Smash TV sound hardware speedup.
- 0.36b7             : Improvements to the 34010 emulation [Aaron Giles].
- 16th October   1999: Aaron Giles sent in a TMS34010 update with a few structural changes and bugfixes.
- 21st September 1999: Zsolt Vasvari did another TMS34010 update, and Hi Impact is now 1-2 fps faster.
- 20th September 1999: Zsolt Vasvari sent in a minor TMS34010 core update, and he also hooked up the Terminator 2 gun properly.
- 19th February  1999: Zsolt Vasvari has optimized the TMS34010 core, resulting in a 5% improvement in speed.
- 0.34b2             : TMS34010 emulator [Alex Pasadyn, Zsolt Vasvari].
- GAMES: Narc (Williams 1988), Smash T.V. (Williams 1990), Mortal Kombat (Midway 1992)
- PCB: TMS34010FNL-50 (50MHz, QCC68) (Nbajam), TMS34010FNL-40 (CheeseChase), TMS 34010 (Mk)



7.8   TMS34020

- 0.122u4            : TMS34020 fixes [Aaron Giles]: Allowed 32-bit pixel sizes. Fixed RPIX instruction.
- 0.114u1            : Aaron Giles substantially changed the TMS340x0 interfaces to allow the CPU emulator to directly manage the video screen. Glitches in several games are now fixed as a result (for example the flashing screens in NBA Jam are now gone at last).
- 0.113u3            : Philip Bennett changed the TMS340x0 core to clear the HSTCTLH NMI bit on an acknowledge. Philip Bennett fixed display of immediate word and long operands in the TMS340x0 disassembler.
- 18th November  2001: Aaron Giles sent in some TMS34020 CPU core changes and a driver for Revolution X.
- GAMES: Revolution X (Midway 1994), Battle Toads (Rare 1994)







8.    Hitachi

8.1   HD6309

- 0.122u7            : Aaron Giles marked HD6309 as divide-by-4 internally. Updated drivers accordingly.
- 0.118u6            : More HD6309 fixes [Tim Lindner]: The SEXW instruction not longer clears the overflow flag. Now generating an illegal instruction trap if invalid registers specified for TFM.
- 0.118              : Darren Atkinson fixed a number of issues in the HD6309 core.
- 0.117u2            : Captain Ahab fixed HD6309 dissaembly of the post-byte for ,W++ and ,--W.
- 0.116u1            : Zsolt Vasvari fixed N flag setting in DIV overflow.
- 0.115u2            : Tim Lindner fixed some page 1 opencode lengths in the 6309 dissasembler.
- 0.112u1            : Nathan Woods changed 6809/6309 CPU cores to call the MAME debugger when CWAI/SYNC is used.
- 0.111u1            : Giuseppe Gorgoglione extensively rewroted the 6309dasm.c disassembler and fixed minor bugs in the hd6309 interface.
- 0.106u7            : Nicola Salmoria fixed some instruction forms in the 6309 diassembler to consume the correct number of bytes.
- 0.99u4             : Nathan Woods fixed the PULUW instruction on the 6309 disassembler.
- 0.99u2             : Tim Lindner fixed 6309 division instructions overflow behavior on the HD6309.
- 0.95u3             : Tim Lindner fixed index addressing mode disassembly for HD6309.
- 0.95u1             : Nathan Woods fixed SEXW instruction (hd6309\6309ops.c) and Cycle Counts Page (hd6309\6309tbl.c).
- 0.90               : Nathan Woods fixed the undocumented bit test opcodes in hd6309 cpu core.
- 0.80               : Nathan Woods fixed the ABCD opcode in cpu\hd6309\6309ops.c
- 0.79u1             : Minor HD6309 timing enhancements, and changed a few indexing modes to be illegal [Nathan Woods].
- 30th January   2004: Nathan Woods sent in minor timing enhancements to the 6309 CPU core.
- 0.72u1             : Nathan Woods fixed 6309dasm.c disassembler for better message, when invalid opcodes are disassembled.
- 0.37b6             : True HD6309 emulation (instead of using the M6809) [Tim Lindner].
-  2nd September 2000: Nicola Salmoria fixed a 6309 bug which affected Fast Lane and Double Dragon.
- 18th August    2000: Tim Lindner submitted a HD6309 CPU core to replace the current hack of 6809 core.
- 0.36RC1            : Changed name 'M6309' to 'HD6309'.
- NOTES: The code was hacked out of the fully-featured 6809 disassembler by Sean Riddle and then mutliated into a 6309 disassembler by Tim Lindner.
- GAMES: Double Dragon (Technos 1987), Psycho-Nics Oscar (2x, Data East 1988), Combat School (Konami 1988)
- SOURCE: cpu\hd6309\hd6309.c
- PCB: 63C09E (Combasc, Thehustl), HD63C09EP (Lethalen), HD63B09EP (source)



8.2   M6803

- 0.120u2            : Curt Coder added SCI support to M6803/HD63701.
- 0.118u1            : Curt Coder added missing port 3/4 to M6803 cpu core.
- 0.88u7             : Nathan Woods modified the M6803 CPU core to use an internal memory map.
- 0.37b1             : 6803/63701 external port writes no longer set to 1 the bits that are set as inputs in the DDR register. Instead, they are set to the value returned by a read from the port [Tatsuyuki Satoh].
- 0.36b8             : Tatsuyuki Satoh finally fixed the CMPX instruction in the 680x core. On the 6800 it does not affect the C flag, on the others (6803, 63701) it does.
- 0.35b6             : Note: The CPU cores have been completely torn apart and rearranged in this release. Don't be surprised if a large number of games donì't work at all. For example, Twin Cobra doesn't boot, and most (all?) of the games using a 6803 lock up (ctrl-alt-del needed).
- GAMES: Irem  - Moon Patrol (1982), Tropical Angel (1983), Spelunker (1985)
- PCB: HD6803P (Youjyudn), MC6803P (BabyPac-Man), MC6803CPD (Kidniki)



8.3   HD63701

- 0.120u2            : Curt Coder added SCI support to M6803/HD63701.
- 0.37b1             : 6803/63701 external port writes no longer set to 1 the bits that are set as inputs in the DDR register. Instead, they are set to the value returned by a read from the port [Tatsuyuki Satoh].
- 17th November  1999: Ernesto Corvi fixed sound in all the games using Namco sound system driven by a HD63701 (incl. Baraduke and Metrocross).
- 0.36b8             : Tatsuyuki Satoh finally fixed the CMPX instruction in the 680x core. On the 6800 it does not affect the C flag, on the others (6803, 63701) it does.
- 0.36b7             : Some fixes to HD63701 IRQ handling, and support for ICI (Input Capture Interrupt) [Tatsuyuki Satoh].
-  2nd March     1999: Ernesto Corvi fixed Pacland and Rolling Thunder sound by emulating two new opcodes in the 63701 core.
- 0.31               : Ernesto Corvi added support for HD63701YO extra opcodes to the M6808 emulation.
- NOTES: The HD63701 is a MCU for input, EEPROM and DAC. It's similiar to the M6800 and compatible to the M6808 with extra instructions.
- GAMES: Namco - Pac-Land (1984), Sky Kid (1985), Hopping Mappy (1986), Pac-Mania (1987), Tank Force (1991)
- PCB: HD63701YOP (Ddragon), 637B01 (Darktowr), 60A1  DIP40 (Drgnbstr, 3D Thunder Ceptor2), 64A1 (Dangseed, BoxyBoy, Splatter), 64A1 = 6809 based Namco custom CPU (Bakutotu, Berabohm), HD63701Y0P (Spdodgeb)


8.31  HD63705

- NOTES: The HD63705 is a IO Microcontroller for Dips/input ports.
- GAMES: Namco - Assault (1988), Ordyne (1988), Cosmo Gang the Video (1991)


8.4   HD64180

- NOTES: The Hitachi HD64180 is a 8 bit processor, dual channel DMAC, memory mapped I/O, used for multigame link.
- SOURCE: drivers\asuka.c
- PCB: HD64180RP8 (Cadash, Iqblock)


8.5   H8/320
- PCB: H8/320 MCU (Twrldc94)


8.6   H8/325
- PCB: Hitachi H8/325 HD6473258P10 MCU (Vgoalsoc, Les Fiches)


8.7   H8/3002
- 0.122u8            : Added some instructions to the H8/30xx CPU [Luca Elia]: or.l ERs, ERd; rotl/shal.l ERd; not.l/neg.l ERd; exts.w Rd; sub/or/xor.l #Imm:32, ERd;  bset/bnot/bclr.b Rn, @ERd; bst/bist.b #Imm:3, @ERd and bnot.b #Imm:3, @ERd.
- 0.109u5            : Aaron Giles converted the H83002 disassemblers to the new format and added step in/out support where it was obvious.
- 0.105u1            : Tomasz Slanina added several missing H8 opcodes to the core and color DAC to driver lastfght.c.
- 0.103u3            : H8/3002 update [R. Belmont]: Limited vector reads to 24 bits. Added SHLL.W, EXTU.L, SUBS.L #2, and SUBS.L #4 opcodes.
- 0.102u3            : Updated the H8/3002 emulation [R. Belmont]: Added more bXXX.b #imm, (@)Rn instructions and added subtract with carry instructions.
- 0.99u1             : cync fixed several problems in the H8/3002 core. Improves sound in Namco System 12 and ND-1.
-  5th August    2005: R. Belmont - Got a nice present today from a coder who goes by cync: a set of major bugfixes to the H8/3002 CPU core. As you know, this is the "sub-CPU" in many later Namco games. So what do the fixes do? They correct most of what was wrong with the sound and music in all of the ND-1 (NCV1/NCV2) and System 12 games. All the games involved now sound way better, and of course I've already backported the fixes to ZiNc so the music's better there too. Paca Paca in ZiNc is now reasonably playable, since the music now actually sounds like music. And games that had decent sound before like Fighting Layer are pretty much perfect now. It's awesome. Thanks, cync!
- 0.95u6             : Fixed h8_group7 opcode (case 0x8) and disassembler.
- 0.86u3             : R. Belmont fixed btst #imm, @Rn instruction - it was giving reversed results, which crashed ncv2's MCU program.
-  2nd September 2004: R. Belmont - Fixed a bug in the H8/3002 CPU core. Got it on speaking terms with the 68000 on the Namco ND-1 hardware. Result: Namco Classics Collection volumes 1 and 2 are both fully playable with full sound and music.
- 0.86u1             : R. Belmont fixed endianness problem in H8/3002
- 0.84u5             : R. Belmont fixed an issue in the H8/3002 core where the timer start register would mess up timers that were already running. Improves the music tempo for S12 games.
- 0.84u2             : Added a core for the Hitachi H8/3002 MCU [R. Belmont]. It was originally written by the Zinc authors The_Author & DynaChicken for Zinc. R. Belmont have fairly extensively rewritten it and adapted it to MAME semantics with their permission. Cycle counts are probably not right because the manual's a bit confusing, but they're at least ballpark.
-  8th July      2004: R. Belmont - More H8/3002 work. Rewrote the timers to use MAME's timer system so music speeds should be accurate now. Need to finish the ITU cleanup now.
-  4th July      2004: R. Belmont - The H8/3002 work continues along. I've fixed a ton of bugs that The_Author left in the original core now.
- 29th June      2004: R. Belmont - Started cleaning up ZiNc's H8/3002 core for MAME submission (this will add sound and fix protection on Namco Classics 1 & 2 and the System 12 games). Fixed some flag calculations on the ADD opcodes and some "edge cases" on the C352 to improve music in NCV1/2. Still need to fix some issues with the controls in Aqua Rush and Paca Paca.
- PCB: HD6413002F16 microcontroller, QFP100 (Ncv1, Ncv2), HD6413002F17 (TekkenTagTournament), Hitachi H8/3002 HD6413002F17 (Aquarush)
- NOTES: The H8/3000 MCU series is normally back-compatible to the 8-bit H8/300, but the 3002 does not include "emulation mode" - it always runs in full 16/32-bit ("advanced") mode. So this core is not suitable for general H8/300 emulation.
- SOURCE: cpu\h83002\h83002.c
- GAMES: Namco Classic Collection Vol. 2 (1996)
- PCB: Hitachi H8/3002 HD6413002F17 MCU (Tekkentt)


8.8   H8/3007
- 0.122u8            : Added some instructions to the H8/30xx CPU [Luca Elia]: or.l ERs, ERd; rotl/shal.l ERd; not.l/neg.l ERd; exts.w Rd; sub/or/xor.l #Imm:32, ERd;  bset/bnot/bclr.b Rn, @ERd; bst/bist.b #Imm:3, @ERd and bnot.b #Imm:3, @ERd. Added H8/3007 & H8/3044 variants with their memory maps. Preliminary implementation of the H8/3007 timers.


8.8   H8/3044
- 0.122u8            : Added some instructions to the H8/30xx CPU [Luca Elia]: or.l ERs, ERd; rotl/shal.l ERd; not.l/neg.l ERd; exts.w Rd; sub/or/xor.l #Imm:32, ERd;  bset/bnot/bclr.b Rn, @ERd; bst/bist.b #Imm:3, @ERd and bnot.b #Imm:3, @ERd. Added H8/3007 & H8/3044 variants with their memory maps. Preliminary implementation of the H8/3007 timers.
- 22nd April     2007: Luca Elia - I've been working on two games by Taiwanese Subsino. They use the Hitachi H8/3044 CPU, which features an undumped internal ROM, and whose emulation in MAME is somewhat incomplete.  Add to that a bit of protection, and the prospects of getting the games to work were limited. Fortunately, though, it looks like the internal ROM is not critical, as I got Bishou Jan (Smiling Jan) (Subsino 1999) to work, albeit with some issues. The video hardware is tilemap based. At the moment there is no sound: the sound chip is unknown, nor do I see sound related writes. Furthermore I had to slightly patch the interrupt routines, and skip what appears to be protection checks. I also had to fix/add the emulation of several instructions in the CPU core. The other Subsino game is Last Fighting, a Bomberman clone currently in MAME as non-working. Same CPU but different, blitter based, video hardware. I'm starting to implement that and, even if much work is still needed, I'm now hopeful to get it to run.
- NOTES: The H8/3044 is a H8/3002 with 24bit address bus and has 32k MASKROM and 2k RAM, clock input is 16.000MHz [32/2]. MD0,MD1 & MD2 are configured to MODE 6 16M-Byte Expanded Mode with the on-chip 32k MASKROM enabled.
- SOURCE: drivers\lastfght.c
- PCB: SUBSINO SS9689 6433044A22F, re-badged Hitachi H8/3044 HD6433044A22F Microcontroller, QFP100 (Lastfght)


8.9   H8/3337
- PCB: Hitachi H8/3337 HD64F3337CP16 (Elvis)



8.A   Z180

- 0.122u8            : Zsolt Vasvari fixed reset crashes in all Z180 games. Removed the various busy loop and non-exact optimzations from the Z180 core.
- 0.119u1            : Improvements to the Z180 core [Pierpaolo Prazzoli]: Added the 2 Programmable Reload Timers. Fixed the Internal I/O Registers remapping. Added logical -> physical memory translation. Disabled loops hack. Removed "extra icount". Changed interrupts handling. Now they're checked as in Z80 core. Simplified RETN and EI opcodes. Fixed PRT interrupts. Cleared both interrupts flip flops when taking any irq. Added _IFF2 = _IFF1; just before _IFF1 = 0; when taking an NMI.
- 21st September 2007: Pierpaolo Prazzoli - After having fun with a simple decryption and with  a couple of fixes to the Z180 core, I could get a first screenshot from the game. But there's something else going wrong now, that causes the game code to crash. I don't know yet if it's another cpu core bug or protection... As a bonus, with those fixes to Z180 core I could get sound working in galaga game inside 20pacgal.
- 0.109u5            : Aaron Giles converted the z180 disassemblers to the new format and added step in/out support where it was obvious.
- 0.98u2             : Aaron Giles rewrote the Z80/Z180 daisy chaining logic to work a little closer to the hardware (added cpu\z80\z80daisy.c).
- 27th August    2004: Guru - As an update to the previous news, there seems to be another way we can get at the data in the HD647180 MCU. Not directly, but we can side-step around it with this device (http://www.advantech.com/products/Model_Detail.asp?model_id=1-KLY4E&PD=), which allows us to snoop on what any chip is sending to any other chip, and what it receives from any other chip. It can be used to monitor and capture any data travelling to/from it's Data and Address lines. Even a Logic Analyser is no good because to capture all the data we need would require a Logic Analyser with a HUGE amount of on-board RAM (typical Analysers have only 512k or less RAM on-board which would allow capturing only a fraction of a second of data). We can't get a direct dump of the internals (we'll never get that), but the captured data will allow us to develop an accurate HLE of the chip's end functions. I believe this is similar/identical to the device that is being used to break the Hitachi FD1094's used on many Sega boards. I would guess that it can be used to snoop on many other Microcontrollers too, I'm sure. So probably this is the next gizmo we will look at buying.... :-)
- 25th August    2004: Guru - I finally located the Teki Paki board and attempted to dump it's HD647180 (QFP80) using the recently-arrived adapter. Bad news unfortunately, it's protected. So there's is virtually no hope of ever seeing sound emulated in those Toaplan games that use this chip. Adding to this dilemma, I swapped the Vimana chip with the Teki Paki one and the board had no sounds at all, which tells me the contents of each chip per game is different. Of course, when I put the chip back onto the correct PCB, it works fine :) In other (bad) news, I've also attempted a dump of the HD647180 PLCC84 chip on Gaelco's Masterboy. This is also protected. This is the main CPU code, so the game will not run at all without it. Masterboy is a pretty crap game anyway, so no loss there.
- 15th February  2004: Nicola Salmoria sent in a driver for Ms.Pac-Man/Galaga - 20 Year Reunion and fixed some bugs in the Z180 CPU core.
- 25th July      2002: Nicola Salmoria added Golden Fire II to the Mosaic driver and fixed a small bug in the Z180 CPU core MMU addressing.
- 0.57               : Z180 emulator [Juergen Buchmueller].
- 23rd December  2001: Nicola Salmoria updated the Z180 CPU core, which is used by the game Mosaic.
- 0.37b10            : Added cpu\z180\z180.c, z180.h, z180cb.c, z180daa.h, z180dasm.c, 180dd.c, z180ed.c, z180fd.c, z180op.c, z180ops.h, z180tbl.h and z180xy.c.
- 20th September 2000: Juergen Buchmueller sent in some bugfixes to the Z180 core and for the memory interface.
- 16th September 2000: Juergen Buchmueller sent in a preliminary Z180 emulation core.
- NOTES: The Z180 (HD647180) is a sound cpu with internal rom (32k). It uses a 8-bit microprocessor (DIP64), code compatible with the Zilog Z80.
- SOURCE: cpu\z180\z180.c
- GAMES: Mosaic (Space 1990), Fire Shark (Toaplan 1990), Vimana (Toaplan 1991) - not dumped yet
- PCB: Hitachi 1D2 R HD647180X0FS6 (Ghox), UC06 DIP64  surface scrached (Mosaic)


8.B   FD1089

- 0.92u1             : FD1089 Update [Nicola Salmoria, Charles MacDonald]. Complete table for 317-0033 (Alien Syndrome) and 317-0034 (Super Hang-On).
- 0.90u4             : Nicola Salmoria and Charles MacDonald improved the FD1089 decryption logic. Added complete table for Enduro Racer and more data to Super Hang On Table.
- 0.90u1             : FD1089 decryption [Nicola Salmoria, Charles MacDonald]. - 100% accurate emulation of FD1089A, FD1089B should be considered 99% because it will have to be verified with other CPUs (it is 100% for all currently supported games). Complete tables provided by Charles MacDonald for 317-0018 (Action Fighter), 317-0022 (Dunk Shot), 317-0168 (Aurail). Partial tables derived by comparison with the unencrypted versions for Enduro Racer, Alex Kidd, 317-0024 (Time Scanner), 317-0033 (Alien Syndrome, 3 versions), 317-0027 (SDI). (actual working cpus are needed to obtain full tables).
-  3rd January   2005: Aaron Giles - A bit sooner than I expected! Nicola submitted the first pass at the FD1089A/B decryption, and it's quite impressive. There are a number of new games this enables, including Action Fighter and Dunk Shot, as well as a number of alternate versions of Alien Syndrome, Alex Kidd, SDI, Time Scanner and Aurail. Luckily, as Charles guessed, Action Fighter seems to work fine on MAME, without the graphics issues he mentioned on his site. The game appears to be something of a Spy Hunter ripoff, letting you pilot various vehicles, chasing down bad guys. Dunk Shot needed some tweaking to get working, but it's fully playable now as well, including controls for all four players. All the new variants of existing games are hooked up now and their controls are working. Hopefully I'll get the chance to finish up the sprite consolidation in the next couple of days so that I can submit this giant updated mass of goodness!
- 11th December  2004: Charles MacDonald - Got Dunk Shot fixed, works fine now. The weird thing is that it's a System 16B game but the video hardware seems to be a little different. I developed a utility to encrypt a test program for direct use on the Dunk Shot FD1089A, and have confirmed that it cannot execute unencrypted code. So patching the original game code on a per-game basis to extract data seems to still be necessary, at least for the time being. This makes the process more difficult but certainly not impossible-
-  5th December  2004: Charles MacDonald - Here's Dunk Shot (System 16B, 317-0022) decrypted and running. Thanks to Dave Widel for donating the CPU, and ShinobiZ & COY for providing the original and bootleg Dunk Shot ROM sets. This is the first FD1089A game that has been decrypted. While it it's encryption method is less complex, finding the right place to insert your own decryption routine is extremely difficult. This is because all data as well as code is encrypted (no vector table changes, hard to know where code starts/stops) and there are no direct instructions, which was the most important finding that led to the FD1094 being figured out. As eight of every 16 bits are encrypted, you have a 50/50 chance of identifying code sequences, which improves as the size of the search data increases. A disappointing aspect of the FD1094 is that you cannot easily restore a non-working game. It's possible to manually put together an unencrypted ROM set from the original data and several decrypted program ROM images (one for each state used), but it is difficult to be 100% sure the result is correct and these kinds of hacks are frowned upon. Luckily this is not the case with the FD1089A. While opcodes and data are encrypted, there is no state mechanism so the decrypted data is just two copies of the program ROM image, one decrypted as code, and the other as data. You could write these to a larger ROM and have the 68000 FC0 pin drive the high order address line to select the decrypted opcodes or decrypted data portion. What remains to be seen is how difficult it is to decrypt other FD1089A based games. I was able to make progress with Dunk Shot because I had a bootleg set and could get an idea of the what the game code did, so it could be patched. For a game with no bootleg it's trickier since you can only make guesses about the game's program flow, what instructions are used at which addresses, etc.
-  3rd December  2004: Charles MacDonald - Progress on the FD1089A/B is on hold at the moment, as I'm waiting for more CPUs to run tests on. Not a problem, just need to determine what the common points are between games rather than what's specific to Dunk Shot.
- 12th November  2004: Charles MacDonald - I've been examining a board which appears to implement the FD1089A workings using regular TTL parts and some programmable logic. It's pretty old (1985) and finding information for some of the components has been difficult. If anyone can help out, I'm looking for information (datasheets, primarily pin assignments) for the following parts: Harwin M3-7643B-5 / Intersil M37643B, Harwin M3-7649-5 / Intersil M37649, Fujitsu MB7142E and Toshiba TMM24128AP (just a 128kx8 EPROM, need a pinout though). I'm also looking for dead or unwanted FD1089A or FD1089B CPUs from any game to run tests on.
- 29th October   2004: Charles MacDonald - I've been able to decrypt a large portion of the game "Dunk Shot" which uses a FD1089A. It turns out the program ROMs from the bootleg dump (used as a reference to locate code in the encrypted ROMs) weren't completely bad, the decrypted data and opcodes are stored separately and in unusual locations within each ROM. There should probably be more data (about 1/3 of the original content is accounted for) but it was more than enough to get started with. The FD1089A is fairly interesting: both code and data are encrypted, and a wider range of address bits seem to be used for the decryption (compare to FD1094 where the encryption 'wrapped' on 16K boundaries). Everything from the program space is encrypted identically, so using an instruction with a PC-relative EA mode allows you to read the PC/SP vectors, game code, interrupt handler code, etc. Thankfully no 'states' this time to deal with, as the FD1089A is very different from the FD1094. One problem with encrypted code and data is that it's harder to determine where sections of code start and end. Also there are no 'direct' opcodes so it isn't easy to program the FD1089A at all. An advantage with Dunk Shot (and possibly other games) is that only bits $FC48 of each word are encrypted, the remaining bits are unmodified. So you can search for a sequence of data and get fairly good matches, the longer the search data is the more accurate the results are. For example longer instructions like 'move.l #imm32, $mem.w' are easier to find, and from there the unencrypted bits of the opcode can be changed to modify the EA mode to something more desirable. There's plenty of work left to be done, but some initial progress has been made.
- NOTES: The FD1089 is a 680000 with built-in encryption. It contains some battery-backed RAM, when the battery dies the CPU stops working. Both opcodes and data are encrypted, using different (but related) tables. Decryption works on 16-bit words, but only 8 bits are affected, the other 8 are left untouched. Opcodes are always encrypted; data can be not encrypted, this is necessary otherwise RAM would not work as expected (writing data and reading it back would return a different number). The FD1089A and FD1089B work in the same way, but the decryption tables are different. The internal RAM only contains the code of the table to use at every address (only 12 bits of the address are used, so the encryption repeats). The FD1089 design is clearly derived from the MC8123. The MC8123 is a Z80 so it made sense to encrypt all 8 data bits and use 12 of the 16 address bits. It makes a lot less sense to encrypt only half of the 16 data bits; using 12 of the 24 address bits might be ok, but not in the way they did it. The choice of address bits to use was probably dictated by the need to not encrypt data in certain areas of the address space, so they had to include the top 8 bits of the address. However this means that if you pick e.g. area 000000-00FFFF, where most of the program code resides, just 4 address bits affect the encryption, making it very weak when compared to the MC8123. Out of the 16kB of internal RAM, you need less than 128 bytes to decrypt a whole game - the rest is not used. A waste of space and security. Also, since only 8 of the 16 bits are encrypted, it is very easy to use the unencrypted ones to search for known sequences of code or data.
- SOURCE: machine\fd1089.c
- GAMES: Action Fighter (Sega 1986), Dunk Shot (1987)
- PCB: Hitachi FD1089A 317-0018 (Afighter)


8.C   FD1094

- 0.124u2            : Save state support for FD1094 chips [MAMEPlus].
- 29th March     2007: Aaron Giles - #1 With A...: I took a break from Excite League and decided to look at Bullet instead, mainly because it was a bigger unknown than a baseball game. After some more aggressive improvements to my analysis tools and many hours of tedium, I managed to get almost all of the code for the game successfully idenitified. Out of the 8192 key bytes, I'm down to less than 100 ambiguous cases, and have over 67% of the mystery bits in the key identified. With this work, I'm finally able to get the game up and running. It passes all tests, the attract mode runs, and the game is pretty playable, though I think there are a few minor glitches that still need to be worked out. Interestingly, it appears to be the only 3-player dual-joystick game I can think of. Haven't gotten far enough into the game to really get a feel for what it's like, but I will include the current partial key with the next MAME update so you can have a look yourself.
- 21st March     2007: Aaron Giles - FD1094 Analysis, part 3: Unfortunately, just knowing the pseudo-random number generation formula is only good enough to identify the low 6 bits in 8188 out of the 8192 bytes of the key. The top two bits aren't generated by the formula, and the first four bytes are completely independent. The first four bytes of the FD1094 key are what's known as the 'global' key. The first byte indicates which internal mode the FD1094 switches into whenever an interrupt is taken (the FD1094 has 256 different modes that it can be in, and programs can switch between them at will while running). The three bytes following affect how the bit permutations work across the entire key, which is why we generally refer to it as the 'global' key. In order to decrypt a given word of the program code, we take the 8-bit value from the key at the corresponding address, plus the 24 bits from the global key, plus the 8-bit current mode, and use those 40 bits to determine how to shuffle the bits to produce the final result. Fortunately, there are some patterns in the global key that help reduce the keyspace by a few bits (each bit that is 'locked' reduces the search space by a factor of 2, so each bit counts!), so in the end we only have to search all 8 bits of the first byte, and 16 bits over the next three bytes, so 24 bits total. Add that to the 22 bits necessary to fully describe a seed value for the random number generator, and we're up to 46 bits worth of 'root' key data necessary to generate all of the full 8192-byte key, minus the top two bits. So, what's in those top two bits of the rest of the key? Well, as I mentioned in part 1, bit $80 is set consistently at addresses from $0004-$0FFF, and bit $40 is set consistently at addresses from $1004-$1FFF. So actually, for most of the bytes, one of the two remaining bits is a constant value. It's that final bit that is the tricky part. One of the features of the FD1094 is that, after all the bit permutation has completed, certain decrypted values are thrown away and replaced by the value $FFFF. This was likely done either to prevent the use of certain opcodes, or (more likely) so that $FF fills-which are a common encryption weakness-could be encrypted in a random fashion. Regardless of the reasons, the final bit has a significant effect on this $FFFF replacement step. If the bit is 0, a certain subset of decrypted values are replaced; if the bit is 1, a more expansive set of decrypted values are replaced (including all of those that get replaced if the bit is 0). To simplify the following explanation, I'm going to break the decrypted values into 3 categories. Category A opcodes are never converted to $FFFF. Category B opcodes are always converted to $FFFF, regardless of the state of the mystery bit.
                       And Category C opcodes are only coverted to $FFFF if the mystery bit is set to 1. Thus, at encryption time, the programmers had to be careful about what opcodes were present in the original code stream. Obviously opcodes in Category A were fine. However, opcodes in Category B are always converted to $FFFF, so they had to completely avoided; presumably there was some mechanism to avoid that problem. And for the opcodes in Category C, it had to be ensured that the mystery bit was set to 0 in the key. Now, there are several potential theories about how the mystery bit was generated for the key. One theory is that the bit comes from the random number generator, but is then modified to change the bit to 0 wherever there is an opcode from Category C in the path. Statistical analysis of all the existing keys disproves this theory: if it were true, then the mystery bit should be set to 0 consistently less than 50% of the time. In reality the mystery bit varies quite a bit; on some games it is 0 in 30% of the bytes, and on others it goes as high as 70%. A second theory is that by default the mystery bit is set to 1 everywhere except where there is an opcode from Category C. This would mean that the mystery bit is strictly determined by the original code. This theory seems more likely. A quick analysis of the simplest game (Sonic Boom) reveals that the mystery bit is only 0 if there is at least one Category C opcode present, and is 1 in all other cases. This is not definitive, but it is a good indication. So, how can we figure out what that last bit is? That's the trick, and the reason that I've been pounding away at creating some new debugger extensions. It involves a lot of tedious work, and I don't think we'll get 100% perfect results, but I'm hopeful we can get something playable at least. It essentially involves analyzing all possible decrypted combinations that you get when you decrypt the code with the mystery bit set and clear, discarding any invalid opcodes, and then manually selecting the right answer based on analysis of the code. Through this mechanism I've managed to get the title screen of Excite League to come up, and have identified over 30% of the mystery bits in Bullet.
- 0.113u3            : Aaron Giles added extensive (but still WIP) FD1094 debugging tools for help in brute force searching for keys (machine\fddebug.c).
- 21st March     2007: Aaron Giles - FD1094 Analysis, part 2: The next step in analyzing the FD1094 keys was to see if I couldn't replicate the pattern of the existing keys using a linear congruential generator (LCG). A LCG is typically written in the form: x' = (a * x + b) % c  which requires three constant parameters a, b, and c to be determined. Assuming that this was done with 32-bit math, that would be 2^32 x 2^32 x 2^32 = 2^96 possible combinations. That's a bit much to brute-force examine. Fortunately, thanks to the fact that the bit sequences repeat at even powers of two, we can eliminate c from the equation entirely, since it is just a mask. Furthermore, a property of LCGs with even power of 2 values for c is that bit n repeats with a frequency of 2^n. Beyond these two factors, if you think about it, bits in x that sit higher than the one we are interested in don't really matter. For example, if we are interested in bit 8, and a is $7F and b is $42, then we will get the same bit sequence in bit 8 as we would if a were $F87F and b were $10442 (you may need to do the math to convince yourself - I did). Thus, only the bits below bit 8 matter when searching for a and b. Given these additional constraints, our search space got significantaly smaller. Taking, for example, a bit that repeats with a frequency of 8192 (2^13), we need only look at 2^13 values for a and 2^13 values for b, or 2^26 total possibilities. Not bad at all. Of course, for each a/b combination, we had to generate the sequence of 2^13 bits in order to compare against our existing data. After doing some searching across all the keys, eventually I found that a consistent value for a worked to generate the low six bits of all the keys, when combined with an initial seed value, one of 5 different initial values for b, and one of 6 different shift amounts (i.e., compute x', then shift right by a given amount, and mask against $3F to get the low six bits). It turned out that every single one of the existing FD1094 keys could have its low six bits generated in this fashion, and through this mechanism, I was able to fix single-bit errors in several keys. At last, the analysis was starting to pay off! Nicola noticed something odd about the values for a and b, and further reduced the equation to:  t = a * x and x' = t + (t << 16). The nice thing about this equation is that it gets rid of the arbitrary shift and b values entirely, leaving only an initial seed value which is unique for each game. So, with the mystery of the low 6 bits solved, and one of the two remaining bits fixed across most of the key, all that is left is to figure out what the final bit is for each of the 8192 bytes of the key. Unfortunately, it turns out that this bit does not appear to be algorithmically generated. More on that in part 3.
- 19th March     2007: Aaron Giles - Got the 'Title Screen' of Excite League decrypted (317-0079 FD1094 CPU).
- 19th March     2007: Aaron Giles - FD1094 Analysis, part 1: As you might have noticed, there has been some good recent progress on emulating the remaining encrypted Sega games, even though we don't have the CPUs available for analysis. This has stemmed from some analysis of the keys used in the games. For the MC8123-based games, Nicola has taken the analysis to its final conclusion and successfully generated full keys. Unfortunately for the FD1094, it's not quite that simple, but progress is being made, and I'm still hopeful the game code can be decoded. Now, I'm no encryption expert (as I've said many times before), but for a while now I've had the sneaking suspicion that that keys stored in the FD1094 CPUs used by Sega were too large to be anything other than algorithmically generated. About a month ago, I posted the idea to the MAME developer list, asking if anyone else thought this might be an avenue worth pursuing, but didn't get much of a response. So I decided to start an analysis of the FD1094 keys that we currently have. I started by looking for obvious patterns. There are a couple of interesting ones. Namely: Bytes in the key at addresses $0004-0FFF all have bit $80 set. Bytes in the key at addresses $1004-1FFF all have bit $40 set. And Bits 0-5 of each key are very uniformly random (almost exactly 50/50 0's versus 1's). Armed with this knowledge, I decided to start looking for repetitions in each of the low 6 bits of all the keys we had. The theory I was going under is that some sort of pseudo-random number generator was responsible for producing these bits. At the time these devices were created, there was not a big focus on cryptographically secure random number generation, so I was hoping they used some kind of simple linear congruential generator (LCG - see http://en.wikipedia.org/wiki/Linear_congruential_generator). If they did, then eventually any sequence they generated would repeat. My initial theory was that there was one generator, and that by stringing together bits from different keys, we might be able to reconstruct the algorithm that generated them. So I wrote a program that read in all the keys and looked for sequences where the ending set of values from one key overlapped the starting set of values from another key, taking each bit independently. Sure enough, it didn't take long to discover that there were what looked to be several long sequences of bits, some of which repeated at regular intervals. The interesting thing here is that the bit sequences I was finding repeated at even power of 2 intervals, which initially made me think that perhaps the algorithm for generating the keys was more of a bit permutation than an LCG, but OG helpfully pointed out that an LCG with a modulus of an even power of 2 will repeat its bits at an even power of 2 frequency. Even more interesting was the discovery that in the cases where bit 0 of a key had a period of 2^n, bit 1 would have a period of 2^n+1, bit 2 would have a period of 2^n+2, etc. This indicated that it was quite likely the case that the low 6 bits were generated all at once with a single LCG. This was even better news than I had hoped. The next step, then, was to figure out what the parameters of the LCG were. I'll talk about that in part 2.
- 0.112u2            : Aaron Giles fixed bad bits in a couple of FD1094 keys and added a small optimization to the FD1094 decoding step.
- 0.112u1            : Added etc\fd1094dp.c.
- 11th January   2006: Charles MacDonald - I've put together a brief tutorial on doing conversions of FD1094 based games to use decrypted ROM sets and a standard 68000. This explains the steps I went through when working on Alien Storm. I'll add more details and maybe some tools later (http://cgfm2.emuviews.com/fdconv.php).
-  2nd January   2006: Charles MacDonald - I converted a dead System 18 AliFD1094-based game (Alien Storm) to use a decrypted ROM set. It works perfectly, and can be done with a ROM replacement and a simple circuit that goes between the 68000 and program ROMs.
- 0.94u5             : Nicola Salmoria updated the FD1094 decryption.
- 0.94u4             : Nicola Salmoria changed FD1094 state change behavior slightly to keep Gain Ground happy.
- 0.89u1             : Thierry and Gerald added new keys for several FD1094 games.
- 0.88u6             : Nicola Salmoria further improved the S16 decryption code.
- 0.88u5             : Various Sega S16 decryption improvements [Nicola Salmoria, Charles MacDonald]. Several more cpus read, improvements to decryption made based on those.
- 0.88u4             : Nicola Salmoria fixed a bug in the fd1094dp.c and fd1094.c decryption to allow for Cotton to be decrypted.
- 0.88u3             : Added etc\fd1094dp.c. More FD1094 improvements [Nicola Salmoria]. Added a program to produce the key tables from dumped state data is now included as etc/fd1094dp.c, please note the key table format has changed slightly to reflect some new findings.
- 0.88u2             : Removed machine\fd1094ky.c. Further improvements to the FD1094 decryption, this is now almost fully understood, additional FD1094 cpus are needed to work out the remaining details. Keys are now stored in the romsets as they should be a close representation of the data stored in the FD1094 CPUs [Nicola Salmoria].
- 0.88u1             : Charles MacDonald and Nicola Salmoria improve the FD1094 emulation. More sets now run (eswatu, fpoint, goldnaxc, cltchitr).
- 0.88               : Added machine\fd1094.c, machine\fd1094ky.c and machine\s16fd.c. Removed machine\fd1094\317-0092.c. Emulation of Sega FD1094 encrypted 68k CPUs [Charles MacDonald - extracting data from CPUs, Nicola Salmoria - decryption code]. This will allow for significant progress in the emulation of the remaining encrypted Sega games. Note that we require working CPUs to extract encryption data from in order to emulate the encrypted titles, see http://cgfm2.emuviews.com/ for more details. As a result of this code several of the encrypted games will now boot (astorm, ddcrew, wb3a, wb3b, tetris, ddux, sonicbom etc.)
- 21st October   2004: Charles MacDonald - Should be a lot of FD1094's coming in the next week or two, that will make up for the lack of updates. I've still been doing plenty of tests with the FD1094 and dumping table data in the meantime, which is useful but not exactly worth discussing. I ran some tests on the System 24 hardware to see how CPU performance is affected when one CPU accesses memory or a device on the other one's bus.
- 0.87u4             : Added machine\fd1094\317-0092.c, Nicola Salmoria added the code to decrypt FD1094 CPU 317-0092 in states 0x00-0xff (0x00 is reset, 0x10 is IRQ) this is the CPU used by tetris, code is not hooked up yet (machine\fd1094\317-0092).
- 25th September 2004: Charles MacDonald - I wrote a new, reasonably fast version of the table dumping software. It works entirely using direct opcodes with no reliance on encrypted data, so you can start dumping tables from any FD1094 without modifying the software. It also only resets the FD1094 once and doesn't rely on double exceptions to halt it, as it's been theorized that resets or other unusual behavior may cause additional drain on the battery, possibly as a tamper-proofing feature. A 16K block is provided for any state initialization (compare instructions or to enter an interrupt) so data from any state can be retrieved. It's been optimized as much as I can and the time it takes to dump tables is fixed regardless of the amount of state setup code. I will be releasing a software package with documentation for how to build the Sega board <> PC link, which I have simplified into a USB-based two chip design. It's easy to make, cheap, and all you need is a device programmer to burn some EPROMs and a PLD. I'll be including the decryption programs and other code for System 24 software development. When I have the time, I'd like to write some example programs for System 16/18/C2/Mega Play as well, to go along with the System 24 stuff.
- 18th September 2004: Charles MacDonald - Great news, I've been able to sucessfully decrypt any 16K block from D.D. Crew. It should be possible to decrypt the entire game at this point. Because D.D. Crew is so large, I'm going to work on Tetris first. The argument to the compare instruction has an effect the decryption state for all following data. Most of it's 32 bits do something, though there are plenty of settings that give the same decrypted output. All you have to do is make the FD1094 execute compare instructions as they come up in the code, and the rest of the data can be decrypted. From what I've seen the result is not cumulative, so just need to run the last compare instruction instead of all prior ones. The catch is that because the decryption state can be changed by the programmer at almost any point in the game's code, you have to trace through the code which is a tedious process. D.D. Crew changes the state a lot but only uses the same few arguments, so one solution would be to decrypt the entire ROM multiple times with different compares being used, and then patch together the correct parts. Tetris only changes the state four times in the startup code and doesn't do anything afterwards, making it a better choice to work with. What's really exciting is, assuming no other problems arise, the technique I'm using is applicable to any FD1094 module. There is no restriction on the source ROM size or the memory map (none of the original code is executed except for the compares). The only work that needs to be done for each game is to get the initial PC (which can be automated) and determine which instruction changes the decryption state, but from what I've seen in other bootlegs it's always the same one.
-  6th September 2004: Charles MacDonald - I've been getting some good tips and ideas from people. I modified the way data is captured using a shorter 'move.w #$imm, d0' instruction so data can be decrypted without needing tables for two adjacent words. Then a TRAP instruction can be placed after the test code to jump to a code fragment that stores D0 to memory. Currently the decrypting code works fairly well, and it takes about 5 minutes to get all the data from a single location. This is mainly because resetting the CPU makes it go through it's startup code each time before the first TRAP can be taken to the test code. This allows data following the first decrypted location to be decrypted too, I've done about 8 sequential positions now. At some point I'll come up against the code fragments used to do the test write and result store, but I can relocate those in the earlier decrypted range of data. The real problem is time and storage; for the first issue I can try to automate the PC-hosted program to dump data, look up the opcode from the resulting table, and proceed with the next word. The table data should amount to 1GB (table size is 128k, 8k positions to test) which is too much for me to put at my website for interested parties. :) Because the area being decrypted starts later in the ROM, you'd think the earlier data would be unrecoverable. But since the decryption wraps on 16K boundaries, I can just decrypt the first few hundred bytes of the next 16K to get the tables needed to decrypt the earlier parts. In theory, of course, as this is based on current assumptions. Stability is an issue because the FD1094 thinks it's in a System 16 environment and tries to do things that don't agree with the System 24 hardware when booting up. This can cause lock-ups, which would interrupt the process if it could be automated. On another subject, does anybody have a scan of the PCB for a Mega Play cartridge? I should be getting a Mega Play PCB soon but have no carts, and want to see what kind of differences there are between Mega Play and Genesis cartridges.
-  5th September 2004: Charles MacDonald - While comparing the Tetris data dumps, there appear to be a very specific group of values that are never generated as a result of the decryption function. These are all opcodes that access data with the PC relative addressing mode. Instructions like LEA and PEA aren't present because they only use the program counter to generate an effective address. The operands are all set to zero, since their value doesn't actually matter. It's interesting that these specific ones are omitted, in fact I haven't seen any bootlegs or unencrypted originals that have encrypted counterparts which use these types of instructions. I think the FD1094 designers prevented their use to get around having an 'easy' way to access memory in the supervisor program space. A smart move for them, but bad news for us. :) A majority of the values decrypted by the CPU have a unique output. The Tetris data shows that for the ones that don't, they nearly always map to $FFFF, $4E73, $0612, and $0404, and to a much lesser degree the values are in the 4xxx-6xxx range. It makes you wonder how (for example) an immediate operand can have all 64k possible values represented if the decrypted output has a smaller range than that. I guess I'll keep working with Tetris, for the life of me I cannot get E-Swat to behave. The bootleg code is too out of sync with the original to get an idea of what's going on. I also have a CPU for D.D. Crew but I believe that game has no bootleg for a reference. It may be possible to get tables of data from a few more locations in Tetris, but I don't think I'll bother with that unless somebody makes a request.
-  4th September 2004: Charles MacDonald - With the PC link working on my System 24 board, I have been doing tests on the Hitachi FD1094 CPU that Tetris uses (the 317-0092) because there is a very similar bootleg to it. I can also try E-Swat, but those are the only CPU modules I own that also have bootlegs. Tetris has the following instruction: 00005D0: 6945 BD0B 535B     move.w #$1111, $E0F6.w - My goal was to modify the immediate word operand and capture the decrypted value written to $FFE0F6. I modified the Tetris code to take a TRAP exception to this location, then added a RTE after it. Later in the game's code, a marker is written to RAM which is used to check when the write has occured. The other CPU can monitor this location and change the operand in a loop. Here is a table of the decrypted data: Update: I've added data from several other addresses too. This gives a better example of which values are position-independant and which ones change based on their address. Also I byteswapped all the files to be LSB first. (the other one wasn't, oops) tetris-data2.zip (1.3MB) - The 5d2.tbl table above has all 64k values of the word at address $0005D2. The results are fascinating, for example many values like 0E71 are decrypted as 4E71, which was the correlation I discussed earlier between the 4xxx group of opcodes. Even more interesting, the decrypted data has a lot of duplicate results, such as many values being decrypted as $FFFF. I had assumed every input would have a unique output. Remember that the decryption hardware also takes the current address into account, so some of the values would be different for another address, except for the 'fixed' results like the 4xxx group. Anyway, while it's not much, it's a first step to understanding how the FD1094 works. If anybody has some ideas for me to try, or notices anything interesting in the data, please let me know. I'll try to get some tables of data from other locations, though there are other experiments I want to run first. Update: One other point of interest: I tried relocating code fragments at different offsets and it turns out only bits 13-0 of the address are used when decrypting. Bits 23-14 are unused. So you can position the code at any 16K boundary and it will be decrypted in the same way. This means the 5d2.tbl file of decrypted data can be used in other locations. For example, in Tetris again: 00045D2: 799D CE7F BF3F     cmpi.b #$1E ($51, a6) - The decrypted value of $799D from the table is $0C2E. And in the bootleg version: 00045D2: 0C2E 001E 0051     cmpi.b #$1E ($51, a6) - There you have it, a perfect match. Tetris is pretty small so I can't give any more examples, but I think this shows the idea.
-  2nd September 2004: Charles MacDonald - I finished the prototype of a PC communications card that fits into the 30-pin expansion connector found on many Sega arcade boards. The transfer rate is about 180K per second in either direction, which is perfectly adequate -- most of the boards I own have less than 64k of RAM for program storage anyway. The limiting factor is the how fast the 68000 (10 MHz in this case) can process data. One experiment I tried was to have my System 16 emulator upload the video RAM contents to a Shinobi board during gameplay. There is quite a lot of flicker from the color and sprite RAM writes, and it doesn't run at full speed, but was nevertheless cool to watch. I think a better application in an emulator would be to have a hotkey that uploads the video state to the target hardware when pressed, so you can compare the software rendered display to what the real one should look like. Now that the communication code is working fairly well on both ends, I'll see about adapting it to the System 18/24/C2 platforms. In theory, this will conveniently solve the problem of ROM swapping on the System 24 board (no more bent pins!) so I can get back to playing around with the FD1094 and disk controller again. I've been running low on working flash memory chips and didn't want to risk wasting any more. Apart from just loading programs, the other nice aspect is that large amounts of data can be saved to disk instead of printed on the screen. This will be handy for testing the math chips that E-Swat uses.
- 23rd June      2004: Charles MacDonald - I've found out something really interesting about the Hitachi FD1094 instruction encoding. In comparing the bootleg or unencrypted original versions of several games to their encrypted counterparts, I noticed a group of instructions have a similar encoding to the original 68000 opcodes, that are always encoded in the same way regardless of position. The operands are encrypted, however. Normally instructions are encrypted based on their value and their address, so for example two ADDX.W instructions in sequence would have two very different opcodes. But in this case, a stream of identical opcodes have the same value. The group seems to be most of the 68000 $4xxx ones, most notably LEA is absent. In the FD1094 they are replaced as $0xxx.
- NOTES: The FD1094 is a custom CPU based on the 68000, which runs encrypted code. The decryption key is stored in 8kB of battery-backed RAM; when the battery dies, the CPU can no longer decrypt the program code and the game stops working (though the CPU itself still works - it just uses a wrong decryption key). Being a 68000, the encryption works on 16-bit words. Only words fetched from program space are decrypted; words fetched from data space are not affected. The decryption can logically be split in two parts. The first part consists of a series of conditional XORs and bitswaps, controlled by the decryption key, which will be described in the next paragraph. The second part does a couple more XORs which don't depend on the key, followed by the replacement of several values with FFFF. This last step is done to prevent usage of any PC-relative opcode, which would easily allow an intruder to dump decrypted values from program space. The FFFF replacement may affect either ~300 values or ~5000, depending on the decryption key. The main part of the decryption can itself be subdivided in four consecutive steps. The first one is executed only if bit 15 of the encrypted value is 1; the second one only if bit 14 of the _current_ value is 1; the third one only if bit 13 of the current value is 1; the fourth one is always executed. The first three steps consist of a few conditional XORs and a final conditional bitswap; the fourth one consists of a fixed XOR and a few conditional bitswaps. There is, however, a special case: if bits 15, 14 and 13 of the encrypted value are all 0, none of the above steps are executed, replaced by a single fixed bitswap. In the end, the decryption of a value at a given address is controlled by 32 boolean variables; 8 of them change at every address (repeating after 0x2000 words), and constitute the main key which is stored in the battery-backed RAM; the other 24 don't change with the address, and depend solely on bytes 1, 2, and 3 of the battery-backed RAM, modified by the "state" which the CPU is in. The CPU can be in one of 256 possible states. The 8 bits of the state modify the 24 bits of the global key in a fixed way, which isn't affected by the battery-backed RAM. On reset, the CPU goes in state 0x00. The state can then be modified by the program, executing the instruction CMPI.L #$00xxFFFF, D0 where xx is the state. When an interrupt happens, the CPU enters "irq mode", forcing a specific state, which is stored in byte 0 of the battery-backed RAM. Irq mode can also be selected by the program with the instruction CMPI.L #$0200FFFF, D0. When RTE is executed, the CPU leaves irq mode, restoring the previous state. This can also be done by the program with the instruction CMPI.L #$0300FFFF, D0. Since bytes 0-3 of the battery-backed RAM are used to store the irq state and the global key, they have a double use: this one, and the normal 8-bit key that changes at every address. To prevent that double use, the CPU fetches the 8-bit key from a different place when decrypting words 0-3, but this only happens after wrapping around at least once; when decrypting the first four words of memory, which correspond the initial SP and initial PC vectors, the 8-bit key is taken from bytes 0-3 of RAM. Instead, when fetching the vectors, the global key is handled differently, to prevent double use of those bytes. But this special handling of the global key doesn't apply to normal operations: reading words 1-3 from program space results in bytes 1-3 of RAM being used both for the 8-bit key and for the 24-bit global key.
- SOURCE: machine\fd1094.c + machine\fddebug.c
- WEB: http://unemulated.emuunlim.com/sega_security.html
- GAMES: Sega - Shinonbi (1987), Moonwalker (1990), Ryukyu (1990), Line of Fire, System24
- PCB: HITACHI FD1094 A-12 9K1 (Loffire, Qsww), FD1094 317-0058-03D (System24)

   Hitachi MCU label         System24 Disc label           Game

   SEGA 317-0058-02                                        Sspirits
   SEGA 317-0058-03D                                       System24 board (MAME)
   SEGA 317-0058-06B         DS3-5000-06B                  RoughRacer
   SEGA 317-0058-08B         DS3-5000-08B                  Qsww

   NOTE: Sega uses a pattern of naming on the floppy disks (DS3-5000-xxx). The xxx is the last part of the Hitachi CPU number.



8.D   FD1149
- NOTES: The FD1149 CPU is undumpable yet!
- GAMES: Sega - Burning Rival F1 (1992), Dark Edge (1992), Super Lap (1993), Dragon Ball Z (1994)



8.E   SH-2 / SH7600 family

- 0.109u5            : Aaron Giles converted the sh2 disassemblers to the new format and added step in/out support where it was obvious.
- 0.102u4            : Mariusz Wojcieszek introduced cpu_readop16() for opcode fetching.
- 0.99u3             : Mariusz Wojcieszek fixed 64 bit / 32 bit division in division unit and added callback called when cpu reads FTCSR register (intended for idle loop skipping for slave SH-2 CPU in ST-V).
- 0.89u5             : SH-2 bounds overflow fix [Mame32Plus]
- 0.79               : Fixed a problem with the SH2 speedup previously added [Olivier Galibert].
- 0.78u4             : Some slight SH-2 speedups [Carlos Santillan].
- 16th October   2003: David Haywood fixed a DMA problem in the SH-2 CPU core that caused broken tile graphics in Shienryu, so Shienryu is now mostly playable although some sprite colors are off.
- 15th October   2003: Olivier Galibert fixed some bugs in the SH-2 DMA thanks to information from sthief.
- 0.75u1             : Olivier Galibert cleaned up SH-2 core a bit.
- 12th October   2003: Olivier Galibert and Aaron Giles fixed more bugs in the timer system and SH-2 CPU core.
- 0.74u1             : Various SH2 fixes improving master/slave support, this improves Shienryu on ST-V but its not yet playable due to incomplete ST-V emulation) [Olivier Galibert].
- 15th September 2003: Olivier Galibert sent in fixes to the SH2 CPU core to make it work in a dual setup, and he fixed the DMA1 interrupt vector in it.
- 26th April     2003: Sthief fixed a bug in the CMPSTR instruction in the SH-2 CPU core.
-  3rd February  2003: Sthief fixed a small bug in the SH-2 CPU core but it does not seem to affect any games.
- 0.62               : Implementation of the SH7604 internal timers, giving sound to Sol Divide and the Super Kaneko Nova System games [R. Belmont].
- 22nd October   2002: Olivier Galibert updated the SH-2 CPU core with some cleanups and added mirror addresses to the division box.
- 20th October   2002: Olivier Galibert fixed a few things in the SH-2 CPU core.
- 15th September 2002: R. Belmont fixed the SH7604 internal timers so that the music in the Super Kaneko Nova System games is fixed and the controls work in the Taisen Hot Gimmick games.
- 14th September 2002: R. Belmont implemented the SH7604 internal timers which gets music and sound running in the rest of the Super Kaneko Nova System games, but the music still suddenly stops working after a while in the games. It also added sound to Sol Divide and gets the Taisen Hot Gimmick games working.
- 13th September 2002: Spice fixed a SH-2 CPU core bug which caused the freezing boss in Strikers 1945 II.
- 27th July      2002: Olivier Galibert fixed NMIs in the SH-2 CPU core.
- 0.59               : Added cpu\sh2\sh2.c and sh2dasm.c
-  3rd March     2002: Olivier Galibert fixed the negc instruction in the SH-2 CPU core.
-  2nd March     2002: Olivier Galibert fixed a few bugs in the SH-2 CPU core which also fix Daraku Tenshi - The Fallen Angels.
-  1st March     2002: R. Belmont fixed a bug in the SH-2 CPU core which fixes the missing background graphics in Strikers 1945 II, although they still aren't perfect due to other unemulated features.
- 24th February  2002: Olivier Galibert fixed a bug that caused SH-2 registers fail to appear in the debug mode.
- 21st February  2002: David Haywood reported some progress in emulating Hitachi SH-2 based Psikyo games. Strikers 1945 II and Space Bomber are playable, although they miss a lot of graphics, have some wrong colors and no sound. S. Glaize reported progress on Super Kaneko Nova System which also uses the Hitachi SH-2 CPU. Gal's Panic S and Gal's Panic 4 work up to the title screen, Panic Street, Cyvern, Jan Jan Paradise, Sen-know and Tel Jan work up to the actual gameplay but crash after a while, and Puzz Loop isn't playable although the attract mode shows something.
- 0.37b14            : Removed cpu\sh2\sh2.c and sh2dasm.c.
-  7th February  2001: Sylvain Glaize fixed some bugs in the SH-2 CPU core.
- 0.37b10            : Added cpu\sh2\sh2.c, sh2.h and sah2dasm.c.
-  ???           2000: Juergen Buchmueller added the SH-2 CPU core.
- NOTES: The Hitachi SH-2 Processor is used in the Kaneko's 'SuperNova' System, Sega ST-V Titan hardware (Sega arcade hardware system based on the Saturn console) and some Psikyo games. This work is based on tiraniddo C/C++ implementation of the SH-2 CPU core and was adapted to the MAME CPU core requirements by Juergen Buchmueller for MAME. Thanks also go to Chuck Mason and Olivier Galibert.
- SORUCE: cpu\sh2\sh2.c
- GAMES: Psikyo - Strikers 1945 II (1997), Space Bomber (1998), Gunbird 2 (1998)
- PCB: Hitachi SH2 HD6417604F28, QFP144 (Gnbarich, Gunbird2), HD6417095 (STV-PCB), Hitachi SH7032 HD6417032F20 (Coolridr), SH2 (Avengrgs)



8.F   SH-4

- 0.123u6            : Oliver Stoenberg fixed "garbage" (newlines) in the debugger window when debugging the SH-4 CPU.
- 0.123u4            : R. Belmont fixed SH4 refresh ticks value of 0, makes awbios not blow up the timer system.
- 0.123u2            : Samuele Zannoli added missing SH4 instructions and bugfixed the FPU. Improved NAOMI I/O board emulation and added working controls.
- 0.122u2            : Samuele Zannoli added initial FPU support to the SH4 core.
- 0.120u3            : Samuele Zannoli corrected some errors in the SH4 core and implemented store queues and the basics of DMA. Added a call to simulate DMA transfers with external devices.
- 0.117u2            : More SH-4 core improvements [Samuele Zannoli]: Fixes some problems in the disassembly and instruction execution from the previous patch. Adds interrupt management. Implements register bank switching. Adds RTC timer counters. Adds memory refresh timer. Adds three timers of the TMU. Adds a configuration structure that specifies the processor mode pin settings. Internal processor clock frequencies calculated from mode pins and cpu clock. Systems using the sh4 processor secify its configuration structure.
- 0.116u1            : Added cpu\sh4\sh4regs.h. SH4 CPU core improvements [Samuele Zannoli]. Corrected opcode decoding and decodes all opcodes of sh4. Corrected disassembly and added support for all instruction of sh4 not in sh2. Now disassembles all fpu instructions. Changed cpu to little-endian (sh4 can be either big or little). Corrected which data is read and written from memory. Added registers fpul and dbr. Added (non-fpu) instructions of sh4 non present in sh2. Added four fpu instructions. Modified memory-mapped internal register management so that all internal registers can be actually used. Added file sh4regs.h with defines for all sh7750 internal registers. Implemented internal registers for memory refresh. Removed some internal registers of sh2 not present in sh4. Added preliminary support for internal cache used as ram.
- 0.114u1            : R. Belmont added very preliminary SH4 CPU core.
- NOTES: Hitachi SH-4 (SH7750 family) emulator
- SOURCE: cpu\sh4\sh4.c
- PCB: Hitachi SH4 CPU (BGAxxx, with heatsink and fan) (NAOMI-Bios)



9.    NEC


9.1   D70008

- NOTES: The NEC D70008 is a Z80A compatible processor for program and sound.
- GAMES: Tecmo - Tecmo Bowl (1987), Silkworm (1988), World Cup'90 (1989) and Dyna Blaster (Irem 1992)
- PCB: NEC D70008AC-8 (Silkworm, Tbowl, Wc90), D70008 (Dynablst)


9.2   uPD7751 / N7751

- 0.35b2             : Mike Balfour added support for the 7751 sound chip in Monster Bash. Two samples are still needed (discrete circuits).
- NOTES: The N7751 is a 8048 CPU derivative (clone) and emulation based on Monster Bash code.
- GAMES: Monster Bash (Sega 1982), Major League (Sega 1985), Quartet (Sega 1986), Alex Kidd (Sega 1986), Body Slam (Sega 1986), Shinobi (Sega 1987)
- PCB: NEC D7751C (Bodyslam), NEC7751 (source)


9.3   uPD780C

- NOTES: The NEC D780C is a Z80A compatible processor for program and sound.
- PCB: D780 (Buckrog), NEC D780C-1 (Flstory), D780C (Devstors)


9.4   MC8123

- 0.122u4            : "Simplified" MC8123 decryption, though it's still more complicated than I'd like it to be [Nicola Salmoria].
- 0.113u3            : Nicola Salmoria added proper MC8123 decryption code. Added machine\mc8123.h. Hooked up a number of games that were using the chip, making many of them playable.
- 16th March     2007: David Haywood - Now that the MC8123 it's been decrypted I've gone back to looking at Ganbare Chinsan Ooshoubu. The hardware seems quite simple. Fixed colors. And the final previously unemulated game that Nicola's MC8123 work allows to be emulated is DakkoChan House, another Mahjong title, this one running in the system1.c driver. In order to work properly it needs the mahjong control panel emulating correctly (otherwise it hangs when booting) I've started looking at this.
- 15th March     2007: David Haywood - Nicola found a weakness in the way Sega generated their keys for the M8123 which made decrypting Fantasy Zone 2 and Opa Opa much easier than anybody had expected. Both games (running on the System E arcade platform) work fine with the SMS emulation from HazeMD. I need to port this over to MAME so that they work properly in MAME too. Aaron should be thanked too for noticing that the FD1094 keys were generated by a Psuedo-Random number generator rather than actually being Random, this was also found to apply to the MC8123 and was the basis of Nicola's work.
- 14th March     2007: R. Belmont - Nicola has fully cracked the Sega MC8123 encrypted CPU. This means, among other things, that games like Opa Opa and Fantasy Zone 2 now run. MAMEdev was afraid those games might be lost forever, since no working examples were known, but now they'll be back to life.
- 0.112              : Nicola Salmoria improved decryption of MC8123-0054 (Shinobi sound CPU) based on a new dump.
- 0.93               : Pierpaolo Prazzoli and Nicola Salmoria added MC8123 317-0064 decryption table to Ufo Senshi Yohko Chan.
- 0.89u6             : MC8123 update [Nicola Salmoria]. Expanded the decryption tables, they change when bit 15 of the address is set. Table for 317-0066 (Altered Beast) almost complete, but there are still some uncertain values for opcodes above 8000 (not actually needed). Incomplete table for 317-0054 (Shinobi). Still not enough to decrypt the program. Tables for 317-0043 (wbml) and ninjakd2 derived by comparison of the original with the decrypted bootleg. They are incomplete but enough to fully decrypt the program. Unfortunately Block Gal and Perfect Billiards cannot be done in the same way because encrypted and decrypted programs are different versions.
- 0.89u3             : Decryption of MC-8123B 317-0066 encrypted z80 used by altbeas2 [Nicola Salmoria, Dave Widel].
- NOTES: The NEC MC-8123 is a Z80 with built-in encryption. It contains some battery-backed RAM, when the battery dies the CPU stops working. It was used in a few games; for now, only 317-0066 has been decrypted. It is still not know how much the encryption can vary from one CPU to the other. I've assumed that the encryption tables are hardcoded, and the internal RAM only contains the code of the table to use.
- SOURCE: machine\mc8123.c
- PCB: NEC MC8123B 651 (Blockgal, Shinobi), MC-8123A 317-5012 (Chinsan)


9.5   uPD7807

- 0.64: Support for uPD7807. Nicola Salmoria added sound in Reikai Doushi. Added uPD7807 (8MHz) and DAC sound.
- 13th January 2003: Nicola Salmoria replaced the MCU simulation hacks with full emulation of the uPD7807 CPU in the Home Data driver, also making the sound emulation work fine.
- GAMES: Home Data - Reikai Doushi (1988), Mahjong Lemon Angel (1990)
- PCB: uPD7807CW (Mjikaga, Mjkinjas, Vitaminc)


9.6   uPD7810

- 0.123u3            : Wilbert Pol added basic support for the NEC uPD7801, uPD78C05 and uPD78C06 CPUs to the uPD7810 CPU core.
- 0.109u5            : Aaron Giles converted the upd7810 disassemblers to the new format and added step in/out support where it was obvious.
- 0.82u3             : Eisuke Watanabe fixed the upd7810 gta, gti, dgt, working reg opcodes and SIO input. Added sound support to the Metro driver.
- 20th March     2002: Peter Trauner submitted an update to the NEC uPD7810 CPU core, fixing a lot of bugs.
- 11th March     2001: Juergen Buchmueller fixed some compilation problems in the NEC uPD7810 CPU core.
- 0.37b13            : Added cpu\upd7810\upd7810.c, 7810ops.c, 7810tbl.c and 7810dasm.c. NEC UPD7810 CPU emulation [Juergen Buchmueller].
-  6th March     2001: Juergen Buchmueller updated the NEC uPD7810 CPU core again.
-  5th March     2001: Juergen Buchmueller sent in another NEC uPD7810 CPU core update with some bugfixes.
-  4th March     2001: Juergen Buchmueller added some more functionality to the NEC uPD7810 CPU core.
-  3rd March     2001: Juergen Buchmueller fixed a few bugs in the NEC uPD7810 CPU core.
-  1st March     2001: Juergen Buchmueller wrote a CPU core for NEC uPD7810, but it still lacks some features.
- NOTES: The NEC uPD7810 CPU controlls soundchips like + MSM6295 + YM2413 or YRW801-M + YMF278B (unemulated). The work based on the NEC Electronics User's Manual, April 1987.
- GAMES: Metro - Puzzli (1995), Dai Toride (1995), Pang Poms (Metro 1992)
- SOURCE: upd7810.c -> uPD7810/11, 7810H/11H, 78C10/C11/C14 emulator
- PCB: NEC D78C10ACW (Lastfreo, Lastfort), NEC D78C10ACN (Karatour), NEC78C10 (Dharma)



9.7   V20

- 0.90               : Fixed a disassembler bug with the NEC cpu core [Angelo Salese].
- 0.88u2             : Bryan McPhail fixed NMI handling in the NEC V20/V30/V33 cores.
- 22nd February  2003: Bryan McPhail sent in a better version of the V20/V30/V33 CPU core fix and he also fixed the cycle counts in it.
- 21st February  2003: Angelo Salese fixed a V20/V30/V33 CPU core bug that caused problems with the timer in Gunforce 2 / Geostorm.
- 24th November  2001: Bart T. submitted a small bugfix to the NEC disassembler.
- 23rd July      2001: Bryan McPhail fixed a bug in the NEC disassembler.
- 29th July      2001: Stefan Jokisch fixed some NEC CPU core bugs.
- 26th July      2001: Nicola Salmoria fixed a NEC CPU core bug which caused sporadic tempo in the Irem games' sound.
- 25th July      2001: Nicola Salmoria improved the Irem sound CPU emulation, which allows R-Type Leo to work without kludges, and he decrypted Hook and Mystic Riders.
- 24th July      2001: Nicola Salmoria yet improved the Irem CPU decryption tables, and got sound working in Undercover Cops and R-Type Leo.
- 18th July      2001: Nicola Salmoria fixed several NEC CPU core bugs and errors in the Irem CPU decryption tables, and got sound working in Gunforce.
- 13th May       2001: Bryan McPhail finally fixed the V20 / V30 cycle count bug which affected the speed in Raiden, R-Type and more.
- 0.37b8             : Rewritten the NEC CPU core, with correct timing and support for encryption [Bryan McPhail].
- 11th September 2000: Bryan McPhail sent in a huge Irem games update with a rewritten NEC core, fixing many bugs. R-Type Leo title screen was fixed as well as preliminary Irem GA20 custom sample player support was added.
- 0.36b9             : Fixed a few bugs in the NEC CPU core that caused problems in Hook, Gunforce, Lethal Thunder and maybe others [Bryan McPhail, Nao].
- 10th November  1999: With help from Nao, Bryan McPhail fixed NEC core problems and now Hook and Dream Soccer 94 are fully playable.
- 0.36b6             : New NEC CPU cores [Oliver Bergmann].
- 24th September 1999: Oliver Bergmann sent in a NEC V20, V30, V33 cpu core.
- NOTES: The Nec CPU core based code on the i286 emulator by Fabrice Frances which had initial work based on David Hedley's pcemu(!). This new core features 99% accurate cycle counts for each processor, there are still some complex situations where cycle counts are wrong, typically where a few instructions have differing counts for odd/even source and odd/even destination memory operands.
- PCB: D70108C-8 (Borntofi)
- SOURCE: cpu\nec\nec.c


9.71  V30

- 0.124u2            : Robiza fixed NEC V30 DASM when a "real-time encrypted CPU" is used. Also fixed execution clocks for add, addc, and, or, xor, cmp, sub and subc instructions.
- 0.118u3            : Added cpu\nec\necdasm.c. Changed NEC V30 CPU core to use a 16-bit data bus. Updated affected drivers: raiden, raiden2, m72, m90, m92, m107, segas32, hng64, deadang, dynduke, sengokmj, shanghai, lockon, tatsumi, fantland, twins, gunpey, ttchamp. Separated V-series disassembler from the i386 disassembler and updated it to use proper register and opcode terminology [Aaron Giles, Philip Bennett, Pierpaolo Prazzoli].
- 0.118u2            : Aaron Giles fixed disassembly of V30 bit instructions.
- 0.90               : Fixed a disassembler bug with the NEC cpu core [Angelo Salese].
- 0.88u2             : Bryan McPhail fixed NMI handling in the NEC V20/V30/V33 cores.
- 0.66               : Bryan McPhail fixed some bugs in the NEC CPU emulation. This includes raster effect problems in Geostorm and the 99 credits bug in Lethal Thunder. 
- 22nd February  2003: Bryan McPhail sent in a better version of the V20/V30/V33 CPU core fix and he also fixed the cycle counts in it.
- 21st February  2003: Angelo Salese fixed a V20/V30/V33 CPU core bug that caused problems with the timer in Gunforce 2 / Geostorm.
-  5th December  2001: Bart T. submitted another NEC V30 disassembler bugfix.
- 13th May       2001: Bryan McPhail finally fixed the V20 / V30 cycle count bug which affected the speed in Raiden, R-Type and more.
- 14th November  2000: Bryan McPhail fixed a bug in the NEC CPU core which affected scoring in Bomberman World (NEC V30).
- 24th September 1999: Oliver Bergmann sent in a NEC V20, V30, V33 cpu core.
- GAMES: R-Type (Irem 1987), Shanghai (Sunsoft 1988), Bomberman (Irem 1992)
- PCB: D70116C (Bchopper), uPD70116C (Sengoku Mahjong), D70116HG-16 (Raiden2, Raidndx), Sony 8623h9 CXQ70116D-8 DIP40 (Kyuukyoku no Othello, PanicRoad), NEC 8948NP V30 (Roundup)
- SOURCE: cpu\nec\nec.c


9.711 V30MZ
- 0.111u2: Added V30MZ emulator [Bryan McPhail]. Based on code by Oliver Bergmann (Raul_Bloodworth@hotmail.com) who based code on the i286 emulator by Fabrice Frances which had initial work based on David Hedley's PCEMU(!).
- SOURCE: cpu\v30mz\v30mz.c



9.712 D80000

- 0.124u5            : Robiza fixed another opcode in Match It II.
- 0.123u3            : Another Risky Challenge opcode to fix a sprite bug and a general clean up of the remarks in the driver [Robiza].
- 0.123u2            : David Haywood and Robiza changed IREM CPU decryption to be 'real-time' (it's a feature of the CPU). Moved decryption table setup to 'config' struct for the CPU. Added latest tables from Robiza, making Risky Challenge playable, promoted it to working. Told CPU core to not decrypt code after brkn instruction, enabling it again on iret, allowing me to remove several 'don't decrypt range' hacks in the code. Updated all drivers accordingly. Currently the disassembly is a bit weird now, this will need looking at.
- 0.123u1            : Several more Risky Challenge opcodes. You can now see "gameplay" [Robiza].
- 0.122u8            : More opcode improvements to Risky Challenge [Robiza].
- 0.122u7            : Robiza added further unencrypted opcodes to Risky Challenge. The game now boots with the intro animation.
- 0.119u3            : Several more opcode fixes for Risky Challenge [Robiza].
- 0.119u1            : Robiza identified a number of additional new opcodes for Risky Challenge/Gussun.
- 0.117u1            : Robiza added more opcode decryption to Gussun Oyoyo.
- 0.117              : Robiza reduced a few more opcodes for Gussun Oyoyo. The game now boots and you can coin up.
- 0.116u4            : Robiza found a number of additional encrypted opcodes for clone Gussun Oyoyo.
- 0.116u3            : Populated several more Irem CPU opcodes for Gussun Oyoyo [Robiza].
- 0.116u2            : Robiza fixed a couple more Irem CPU opcodes to improve Match It 2.
- 0.116u1            : Robiza fixed another IREM opcode, now Match It II is fully playable.
- 0.115u3            : Robiza fixed several more opcodes in the encrypted Irem Custom V30 CPU.
- 0.115u2            : Pierpaolo Prazzoli added a new IREM D80000 opcode for Match It II. There still are 4 unknown opcodes and the "no tiles" bug before it will be promoted to working status.
- 0.115u1            : Pierpaolo Prazzoli identified a couple of new opcodes in the Irem V30 CPU which improves Match It II.
- 20th January   2005: Pierpaolo Prazzoli - It tooks 2 weeks and 120 opcodes to see Shisensho II booting...
- 31st July      2003: Angelo Salese improved the decryption in Risky Challenge / Gussun Oyoyo, but it still doesn't work perfectly.
- 27th July      2001: Nicola Salmoria decrypted the sound CPU in In the Hunt, Major Title 2 and Perfect Soldiers. He also fixed the colors in Major Title 2.
- 25th July      2001: Nicola Salmoria improved the IREM sound CPU emulation, which allows R-Type Leo to work without kludges, and he decrypted Hook and Mystic Riders.
- 19th July      2001: Nicola Salmoria decrypted the sound CPU in Blade Master and Lethal Thunder.
- 18th July      2001: Nicola Salmoria fixed several NEC CPU core bugs and errors in the IREM CPU decryption tables, and got sound working in Gunforce.
- 0.37b8             : Added machine\irem_cpu.c/h.
- 11th September 2000: Bomberman / Dynablaster and Bomberman World / Atomic Punk were decrypted and added by Bryan.
- NOTES: The Irem D80000 is a custom V30 CPU for program and sound. It uses a simple opcode lookup encryption.
- SOURCE: machine\irem_cpu.c
- PCB:
       D800001A1                              (Rtypeleo)
       D8000011A1                             (Inthunt)
       D8000019A1                             (Riskchal)
       D8000020A1 023 9320NK700               (Shisen2)
       D8000021A1                             (Wpksoc)
       D8000022A1                             (Psoldier)
       D8000023A1                             (Dsoccr94)



9.713 NANAO 08J27291

- 0.124u4            : Robiza fixed 2 opcodes for Quiz F-1, now the little machines move correctly.
- 0.124u3            : Robiza fixed an opcode in Quiz F-1. Fixed encrypted disassembly for bp+ix+offset8 and bp+it+offset8.
- NOTES: The NANAO 08J27291 is a custom V30 CPU like the D80000. It uses a simple opcode lookup encryption.
- SOURCE: machine\irem_cpu.c
- PCB:
       08J27261A1 011 9108KK700    PLCC84     (Gunforce, Hasamu)
       08J27261A1 012 9123KK200               (Bombrman)
       08J27291A4 014 9147KK700    PLCC84     (Gunforc2, Quizf1)
       08J27291A5                             (Uccops)
       08J27291A6                             (Nbbatman) V30?
       08J27291A7                  PLCC84     (Majtitl2)




9.72  V33

- 0.90               : Fixed a disassembler bug with the NEC cpu core [Angelo Salese].
- 0.88u2             : Bryan McPhail fixed NMI handling in the NEC V20/V30/V33 cores.
- 0.66               : Bryan McPhail fixed some bugs in the NEC CPU emulation. This includes raster effect problems in Geostorm and the 99 credits bug in Lethal Thunder. 
- 22nd February  2003: Bryan McPhail sent in a better version of the V20/V30/V33 CPU core fix and he also fixed the cycle counts in it.
- 21st February  2003: Angelo Salese fixed a V20/V30/V33 CPU core bug that caused problems with the timer in Gunforce 2 / Geostorm.
- 29th April     2000: Bryan McPhail added the USA romset of In The Hunt to the M92 driver, and he fixed the slowdowns in V33 games.
- 24th September 1999: Oliver Bergmann sent in a NEC V20, V30, V33 cpu core.
- GAMES: Irem - Hook (1992), R-Type Leo (1992)
- NOTES: V33 is a super version of the V30 that separates address bus and data bus, executes all instrucitons with wired logic, not micro-codes. Therefore, V33 is two times faster than V30 at same clock frequency. V33 has the parformance equivalent to i80286.
- PCB: D70136L-10  = V33 with 10 Mhz (Rtypeleo), uPD70136L (Majtitl2), NEC D71036L V33 (Gunforce)
- SOURCE: cpu\nec\nec.c



9.73  V53

- NOTES: V53 and V53A (V53 below) are one of the NEC V series micrcontrollers. These are microcontroller that integrated some peripherals with V33 cored. Its peripherals are equivalent to V50's peripherals, so that V53 is a microcontroller that replaced V50's core-processor from V30 to V33. And V33 core-processor has compatible instruction set as Intel 8086/80186 microprocessor. Difference between V53 and V53A: It is difference on the core-processor V33 and V33A. At the V33, some intrurupt vector number such as undefined instruction fault are differnt to intel i80X86. At the V33A, these number are re-defined same as intel i80X86 prcessors.
- NOTES: Core-Processor: V33 compatible. Serial I/F: 1 channel (8251 compatible). Timer/Counter: 3 channels (8254 compatible). DMA: 4 channels (8237/8271 compatible). Intrerupt Controller: 8 lines (8259 compatible). BUS I/F: Address: 24bit (selectable address expantion capability like an EMS), Data: 8/16bit (Dynamic bus sizing), Address and Data bus are separated. Minimum two clocks/access, Programmable wait controller (0-7 wait) and DRAM refresh controll. Package: 132pin PGA, QFP120. Operating conditions: Operating Frequency: 2-20MHz and Power consumption: 900mW (@16MHz)
- PCB: NEC D70236AGJ-16 V53A  QFP120 (HyperNeoGeo64), µPD70236



9.74  V60

- 0.113u4            : Ernesto Corvi added v60_stall mechanism to allow for synchronization between the V60 core and an external CPU.
- 0.109u5            : Aaron Giles converted the v60 disassemblers to the new format and added step in/out support where it was obvious.
- 0.106u6            : R. Belmont added workaround to make the V60 core work properly on GCC 4.x (tested on 4.1.1).
- 0.97u4             : Aaron Giles fixed V60 SBR handling to ignore the low 12 bits. This allows the hack in clone Tetris Plus 2 (MegaSystem 32 Version) to be removed.
-  2nd July      2005: Luca Elia - I sent a fix for the V60 CPU that stopped Eagle Shot Golf from crashing later in game, and got Mobil Suit Gundam Final Shooting (1995) to boot.
- 0.97u3             : Aaron Giles fixed exception handling and task switching in the V60 core.
- 24th June      2005: Luca Elia - Eagle Shot Golf has been in the ssv.c driver for quite some time now, hanging at the boot and just showing a black screen. After much investigation of its stack handling during the boot process, I was able to nail down the problem: the emulation of the TRAP and STTASK instructions of the V60 CPU. A change there got the game past the boot...
- 0.97u2             : Aaron Giles added step in/out support to the V60 disassembler.
- 0.97u1             : Aaron Giles changed V60 CPU to clock multiple cycles per instruction instead of requiring every driver to divide the clock; updated all drivers to use the correct clock speed.
- 0.96               : Removed abort() calls from V60 CPU driver [Brad Oliver].
- 0.95u1             : Sebastien Chevalier fixed V60 DIVFS opcode.
- 30th March     2004: Olivier Galibert fixed a slight bug in the V60 CPU core where it didn't have I/O address space.
- 0.77u2             : Olivier Galibert fixed a few V60 floating point opcodes.
- 24th November  2003: Olivier Galibert fixed the negf and absf opcodes in the V60 CPU core.
- 22nd November  2003: Olivier Galibert fixed the sclf opcode in the V60 CPU core.
- 0.76u1             : V60 improvements (LDTASK, STTASK, ABSF and some missing \n.) [Olivier Galibert].
- 19th October   2003: Olivier Galibert added LDTASK, STTASK and ABSF opcodes to the V60 CPU core.
-  8th October   2003: Kobat fixed another bug that was in the V60 CPU core.
-  7th October   2003: Aaron Giles fixed the V60 CPU core that was causing problems in Outrunners and other games.
- 0.75               : Aaron Giles fixed bug in the time accounting for the V60 which was causing Outrunners to run with flickering sprites and slow music. Kobat and Olivier Galibert fixes another V60 bug introduced in 0.74u2 which broke the v70 games (and further broke Outrunners).
- 29th September 2003: Olivier Galibert fixed the interrupt stack, some floating point operations and added the NEGF opcode to the V60 CPU core.
- 0.74               : Workaround for a V60 crash causing ultra-x not to run on some systems [Tomasz Slanina].
-  5th September 2003: Tomasz Slanina sent in a quick and dirty fix for the LDPR opcode crash in the V60 CPU core.
- 29th August    2003: Tomasz Slanina fixed the interrupts and register layout in the V60 CPU core, making Ultra X Weapons run (with graphics glitches) along with Twin Eagle 2 (unplayable due to unemulated protection).
- 0.69b              : Aaron Giles fixed a bug in the V60 CPU core causing it to break with the new timer system.
- 31st May       2003: Aaron Giles fixed a problem in the V60 CPU core unearthed by the timer code updates.
- 0.65               : Added cpu\v60\v60mem.c. Aaron Giles optimized the V60/V70 memory access.
- 10th February  2003: Aaron Giles changed the V60 CPU core to fetch opcodes directly rather than through the memory handlers, making it somewhat faster.
-  6th January   2003: Olivier Galibert added V60/V70 state saving support.
- 30th September 2002: Olivier Galibert fixed some V60 CPU core bugs which caused jerky scrolling in Change Air Blade.
- 21st May       2002: An anonymous contributor sent in a fix for the V60 core which makes Super Real Mahjong Part 4 and 7 playable.
-  4th May       2002: Nicola Salmoria fixed the V60 CPU core bug which broke the SSV system games.
- 20th February  2002: Brad Oliver fixed a V60 CPU core memory bug that occurred on the Mac side.
- 0.56               : Added cpu\v60\v60.c, v60d.c, optable.c, 3x am.c and 7x op.c. V60 cpu core [Farfetch'd, R. Belmont].
- 26th October   2001: Olivier Galibert fixed a bug which caused the debugger to crash when using the V60 CPU core.
- 20th October   2001: Olivier Galibert fixed a bug which caused the debugger to show wrong values with the V60 CPU core.
-  3rd October   2001: Olivier Galibert ported the V60 CPU core originally made by Farfetch'd and R. Belmont to MAME.
- NOTES: V60 coding by Farfetch'd. The V60 CPU has a 32 bit RISC architecture and runs at 16Mhz with 2.5 MIPS.
- SOURCE: cpu\v60\v60.c
- GAMES: Survival Arts (Sammy 1993), Drift Out '94 (Visco 1994), Monster Slider (Visco 1997)
- PCB: NEC D70616R-16 16Mhz (RadRally), NEC D70615GD-16-S  QFP120 (Drifto94, Vasara2, Model1)



9.75  V70

- 0.65               : Aaron Giles optimized the V60/V70 memory access.
-  6th January   2003: Olivier Galibert added V60/V70 state saving support.
- 0.62               : V70 CPU support [Olivier Galibert].
- 23rd September 2002: Olivier Galibert fixed the debugger and -listinfo with V70.
- 22nd September 2002: Olivier Galibert added V70 support to the V60 core.
- GAMES: Jaleco - Best Bout Boxing (1994), Desert War (1995), Gratia (1996)
- PCB: NEC D70632GD-20 (Bbbxing, Desertwr, P47aces), NEC D70632R-20 9314X9 V70 (Titlef)



9.76  V810
- 0.111u1            : Giuseppe Gorgoglione fixed minor bugs in the V810 interface.
- 0.109u5            : Aaron Giles converted the v810 disassemblers to the new format and added step in/out support where it was obvious.
- 0.103u1            : Atari Ace fixed out-of-bounds array writes in the V810 core.
- 0.84u5             : Preliminary NEC V810 core [Thomasz Slanina].
- 19th July      2004: Tomasz Slanina - Finished NEC V810 cpu core. Mayjinsen 2 (ST-0016 hw) is playable, Mayjinsen (ST-0016 hw) has gfx glitches but it's playable and Joryuu Syougi Kyoushitsu (SSV hw) - dump is incomplete, main cpu (v60?) roms are missing.
- 24th October   2003: Tomasz Slanina - NEC V810 cpu core (for MAME (Mayjinsen, Mayjinsen II, Joryuu Syougi Kyoushitsu) and MESS).
- NOTES: NEC V810 (upd70732) core
- SOURCE: cpu\v810\v810.c
- GAMES: Mayjinsen (Seta 1994), Mayjinsen 2 (Seta 1994), Joryuu Syougi Kyoushitsu (Visco 1997)
- PCB: UPD70732-25 V810 (Mayjinsn), NEC JAPAN D70732GD-25 (C)NEC1991 V810 9651MK007 (Jsk)






10.    Data East


10.1   DECO CPU16

- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.63               : Added cpu\m6502\tdeco16.c. DECO16 CPU support.
-  5th January   2003: Bryan McPhail submitted the DECO16 CPU core and a driver for Boomer Rang'r / Genesis, Kamikaze Cabbie and Liberation.
- NOTES: Data East's DECO CPU16 is a an encypted 6502 custom CPU with additional custom opcodes.
- SOURCE: cpu\m6502\tdeco16.c
- GAMES: Data East - Boomer Rang'r (1983), Kamikaze Cabbie/Yellow Cab (1984), Liberation (1984), Battle Wings/B-Wings (84), Zaviga (1984)
- PCB: DECO CPU16 M1018 2Z43 (Liberate, Prosoccr), CPU CPU16 - PGA package (Kamikcab), CPU 16 (Kamikcab)



10.2   DECO 45 / HuC6280

- 0.122u6            : Charles MacDonald fixed HuC6280 low-speed mode so it uses 4 cycles instead of 3.
- 0.122u5            : Added machine\pcecommn.c/h. Mariusz Wojcieszek added MESS PC-Engine emulatation system.
- 0.121u3            : Wilbert Pol fixed uninitialized variable in H6280 core.
- 0.119u2            : Wilbert Pol fixed NMI handling in H6280 CPU core.
- 0.119u1            : Fixed a number of issues in the H6280 CPU core [Wilbert Pol]: Taking of interrupts is delayed to respect a pending instruction already in the instruction pipeline. Added 1 cycle for decimal mode ADC and SBC instructions. Changed cycle counts for CSH and CSL instructions to 3. Added T flag support to the SBC instruction. Fixed ADC T flag to set the Z flag based on the value read. Added 3 cycle penalty to ADC, AND, EOR, ORA, and SBC instructions when the T flag is set. Fixed cycle count and support for 65536 byte blocks for the TAI, TDD, TIA, TII and TIN instructions. Fixed RDWORD macro in the disassembler. Fixed setting of N and V flags in the TST instructions. Removed unneeded debug_mmr code. Fixed TSB and TRB instructions. Added 1 delay when accessing the VDC or VCE areas. Implemented low and high speed cpu modes.
- 0.109u5            : Aaron Giles converted the H6280 disassemblers to the new format and added step in/out support where it was obvious.
- 0.104u1            : Buddabing added save state support to the Hu6280 CPU core.
- 0.103u2            : H6280 updates [Rob Bohms]: Added T-flag emulation and fixed read calls in the HuC6280 CPU and sound CPU.
- 0.103u1            : Many H6280/PCE fixes [Rob Bohms, Charles MacDonald]: Fixed cases where sprites could render outside of the buffer. Added VRAM to VRAM DMA (Charles). Multiple h6280 fixes (Charles). Provided functions to correctly handle VRAM accesses for the entire 128K range (Charles). Added some of the I/O buffer bits from the hardware page. Fixed h6280 IRQ ranges to support proper mirroring. Hooked up h6280 IRQs to the PC Engine. Corrected sprite-to-sprite rendering priorities. Partially enforce 16 sprite limit.
-  8th November  2005: Charles MacDonald - Changed timer implementation, no longer single shot and reading the timer registers returns the count only. Fixes the following: Mesopotamia: Music tempo & in-game timer, Dragon Saber: DDA effects, Magical Chase: Music tempo and speed regulation, Cadash: Allows the first level to start and Turrican: Allows the game to start. Changed PLX and PLY to set NZ flags. Fixes: Afterburner: Graphics unpacking and Aoi Blink: Collision detection with background. Fixed the decimal version of ADC/SBC to *not* update the V flag, only the binary ones do. Fixed B flag handling so it is always set outside of an interrupt; even after being set by PLP and RTI. Fixed P state after reset to set I and B, leaving T, D cleared and NVZC randomized (cleared in this case). Fixed interrupt processing order (Timer has highest priority followed by IRQ1 and finally IRQ2).
- 0.101u4            : Aaron Giles updated the H6280 CPU to use the new address translation system.
- 20th February  2005: Charles MacDonald - The PCBs for my PC Engine development board arrived last week and I've been working on debugging them since. Most of the problems seemed to be about how the HuC6280 handles a bus transaction when reading or writing memory, it's not nearly as simple as the patents would lead you to believe. The glue logic was implemented on a GAL22V10, which was a good choice as I've been reprogramming it a lot to tweak the design. Once the hardware bugs are resolved, I'm hoping to do some serious work on TGEmu and my PC Engine documentation. I may release the design to the public domain if there is sufficient interest, though it's not that much cheaper compared to Tototek's PCE-PRO 32M Flash Cart. But a DIY project is always rewarding, I was pretty excited when I had Blazing Lazers running for the first time.
- 31st January   2005: Charles MacDonald - I've been finalizing the design for a TurboGrafx-16 / PC Engine development board. It provides a USB interface to a PC to transfer programs, has 512k of flash memory, and 512k of NVRAM. The addressing decoding is flexible so programs can be stored in either or both memories, and "split" HuCard images can be executed out of NVRAM (up to 256k+256k max). I built a simpler prototype on a breadboard that worked fine, the next step is to get some PCBs manufactured after the board layout is verified.
- 17th March     2004: Bryan McPhail fixed a hard crash that occurred when trying to debug HuC6280 code.
-  3rd September 2000: Bryan McPhail fixed an internal timer bug in the Hu6280 core.
- 0.37b2             : Bryan McPhail fixed Hu6280 emulation bugs which caused missing levels in Trio the Punch.
-  4th April     2000: Karl Stenerud fixed a 6280 disassembler bug.
- 0.36b13            : Changed name 'H6280' to 'HuC6280'.
- 25th December  1999: Bryan McPhail sent in a big update to Data East games with fully correct sound frequencies and with a few Hu6280 fixes.
- 14th June      1999: Bryan McPhail fixed Hu6280 communications in Caveman Ninja sound system.
- 23rd April     1999: Bryan McPhail updated the Hu6280 core and the Hippodrome & Fighting Fantasy drivers. Those two games now work fully.
- 0.35b5             : H6280 emulator, used by several DECO games [Bryan McPhail].
-  1st March     1999: Bryan McPhail has sent in his dec0 driver, with Boulder Dash support added and Sly Spy and Midnight Resistance now have full sound and music. All this was possible to do because he also added support for the Hu6280 CPU into MAME.
- NOTES: Remember (!) there is also the HuC6280 sound chip in MAME. The CPU source code based on the 6502 emulator by Juergen Buchmueller. The code is around 99% complete!  Several things are unimplemented (like csh, csl opcodes are not supported and set opcode and T flag behaviour).
- GAMES: Data East - Robocop (1988), Midnight Resistance (1989), Sly Spy (1989), Boulder Dash (1990)
- SOURCE: cpu\h6280\h6280.c
- PCB: Hudson Soft Hu6280A (Dragngun), Hu C6280, Hu6280 (Mutantf), Data East custom chip 45 - 80 pins (Funkyjet, Mutantf, Rohga, Tumblep)



10.3   DECO 59

- NOTES: The DECO Custom Chip 59 is a M68000 CPU.
- SOURCE: darkseal.c, madmotor.c and vaportra.c
- PCB: DECO Custom Chip 59, PQFP64 (Funkyjet, Mutantf, Rohga, Wizdfire)



10.4   DECO 101 / ARM

- 0.123u2            : R. Belmont fixed unaligned 32-bit reads in the ARM7 core.
- 30th May 2007      : R. Belmont - More ARM7 fixes (including several that were backported to the original ARM core - could someone check if it's now possible in 0.115u2 to beat the end boss on Dragon Gun?), so of course I have a few new GBA screens.
- 0.115u1            : R. Belmont and Ryan Holtz fixed carry flag calculation for SUB/SBC/CMP family instructions in the ARM core.
- 0.111u2            : Aaron Giles improved cycle timings in the ARM CPU core. Altered the deco32 CPU clocks to be more realistic.
- 0.109u5            : Aaron Giles converted the ARM disassemblers to the new format and added step in/out support where it was obvious.
- 0.103u3            : Bryan McPhail fixed an ARM interrupt bug. David Haywood added BCD multiply to ARM coprocessor to fix World Cup Volley '95.
- 0.103u2            : Cleanups to the ARM core [Bryan McPhail]. Tomasz Slanina modified ARM CPU core to allow World Cup Volley '95 to start.
- 0.103u1            : Updates for the ARM core [Bryan McPhail]: Fixed software interrupts and several mode change bugs. Added preliminary coprocessor support.
- 0.99               : Backed out some of the ARM core changes which broke several games.
- 0.98u4             : Bryan McPhail fixed several bugs in the ARM core which break Captain America but fix some other issues. Tomasz Slanina fixed unaligned 32-bit reads in the ARM core.
-  1st August    2005: Tomasz Slanina - Fixed a bug in the ARM CPU core, which in turn fixed the colours in Osman.
- 0.58               : Added cpu\arm\arm.c + armdasm.c. ARM CPU emulation [Bryan McPhail, Phil Stroffolino].
-  3rd February  2002: Bryan McPhail submitted the Captain America driver and ARM CPU core written by him and Phil Stroffolino. Captain America is almost perfect and includes sound, but the other games in that driver don't work - Fighter's History uses a protection chip, Dragon Gun and Locked 'N Loaded use a different sprite RAM format which is not yet emulated, and Tattoo Assassins works with sound, but lacks the graphics ROMs.
- 0.37b14            : Removed cpu\arm\arm.c and arm\dasm.c.
- 20th July      2000: Juergen Buchmueller submitted a preliminary ARM cpu core.
- NOTES: MAME emulted the ARM 2/3 CPU. TODO: Software interrupts unverified (nothing uses them so far, but they should be ok). Timing - Currently very approximated, nothing relies on proper timing so far. IRQ timing not yet correct (again, nothing is affected by this so far).
- SOURCE: cpu\arm\arm.c
- GAMES: Captain America (Data East 1991)
- PCB: ARM DE101 (Lockload), 101 (Dragngun)


10.5   DECO 102

- 0.95u6             : Added machine\deco102.c.
- 0.95u5             : Nicola Salmoria figured out decryption of remaining DECO102 games.
- 0.95u4             : Nicola Salmoria added preliminary decryption to DECO 102 games.
- 22nd April     2005: Nicola Salmoria - Bryan noticed that changing a single value in the Pocket Gal Deluxe decryption (related to the address scrambling) revealed some clear text in Diet Go Go. THis means that the encryption key is almost hardcoded as I expected, but with some minor variation (maybe externally to the DE102 iself). I have isolated the variations in just two numbers, a 16-bit one for the address scrambling and an 8-bit one (or two 4-bit ones) for the data bits permutation and xor. Fine tuning the values to correctly decrypt data in Diet Go Go was easy enough. Double Wings required a little more works, but it was still easy. I just needed to brute force the 16-bit parameter. Doing that was easy because I just had to decrypt the ROM using each possible value for the parameter, and count how many zeros were in the decrypted data. When their number rised from a couple of thousands to tens of thousand, I had a "good enough" value for the parameter, which I could later tweak by hand. So, data was decrypted in all four games (the other one is Boogie Wings which decrypted with the same parameters as Pocket Gal Deluxe), but opcodes were still encrypted. However, most of the work was already done. Even if the opcodes are encrypted differently from data, the address scrambling must of course be the same, otherwise there wouldn't be a 1:1 correlation between logical address and physical address. Therefore, only the data bits permutation and xor changes. The obvious candidate for that variation was the 8-bit parameter. A brute force search was even easier in this case. I just had to try all possible values and count how many times 4E75 (the opcode for RTS) appeared. When it increased from a couple of times to several hundreds, I had the key. So all four known games using this CPU (Pocket Gal Deluxe, Diet Go Go, Double Wings and Boogie Wings) should now be fully decrypted. Non of them is working; for that, the driver will have to be finished, and possibly some more protection worked around. But the first hurdle has been overcome.
- 20th April     2005: Nicola Salmoria - The recent discovery of a decrypted bootleg of Pocket Gal Deluxe was a pleasant surprise. This is one of a handful of games that use the same encrypted custom CPU - called DE102. It is now confirmed that the CPU is a 68000. Thanks to the bootleg, I was able to figure out the decryption algorithm. It is quite straightforward, and it involves: (1) Address scrambling. When the CPU wants to read a word from logical address N, it fetches it from ROM space at address N'. The scrambling of the address requires 16 conditional XORs with 16-bit values. (2) Data bits permutation. After reading the word from ROM, the order of its bits is altered. There are 16 possible permutations; which one to use depends trivially on the logical address and (3) Data XOR. After changing the bit order, the value is XORed with one of 16 other values. Which one to use depends trivially on the logical address. While working on Pcket Gal Deluxe, I was hoping that the DE102 would use a fixed key, which would have emant free decryption of a few other games. Unfortunately, this turned out to not be the case. The algorithm surely is the same, but the key is different. Determining the key without having a decrypted version to compare with is a lot more difficult, as you can imagine. Also, it seems that at least one of the other games encrypts data and opcodes differently, which makes things a lot more complicated. In the next days, I'll see if I can find a way to break the key somehow.
- NOTES: Encrypted M68000 main CPU (QFP128) in Diet Go Go, Boogie Wings, Double Wings and Pocket Gal DX
- SOURCE: machine\deco102.c
- PCB: DE102 (Pktgaldx, Boogwing)



10.6   DECO 156

- 0.103u2            : David Haywood added BCD opcodes to 156 / ARM co-processor.
- 31st December  2005: Bryan McPhail - Due to pressing deadlines in 'real' work, this took somewhat longer than I thought to finish off. Unfortunately, although all Deco156 games now boot in Mame, only Night Slashers and Heavy Smash are properly playable. All the other games make use of a math co-processor which is not yet understood. Of the broken games Skull Fang works the most - the attract mode is fully correct, and it's playable up to the first boss. The other games mostly have serious gameplay errors (eg, AI players do not respond correctly in Hoops). Sound is also bust in all of the new games.
-  1st August    2005: David Haywood - Shortly after the release of u3 I made some further improvements to the 156 emulation, removing a kludge (allowing the Eeproms to work) and fixing the music.
- 0.98u3             : Fully emulated DECO 156 encryption [David Haywood, Nicola Salmoria, Olivier Galibert, Bryan McPhail].
- 31st July      2005: David Haywood - Final 156 update for tonight... General: Added Sprites, EEPROM settings don't work on any game and No Sound. Magical Drop / Magical Drop Plus / Chain Reaction: This is highly unstable and prone to crashing, I'm not too sure if its due to protection or CPU bugs, none of the other games behave this badly. Gameplay is also very sluggish. Osman / Cannon Dancer: Still doesn't boot without going into the debugger. Has problems with Sprite colours (16-bit ram on 32-bit bus maybe?) and tile banking. Also tilemaps don't seem large enough at the moment. Party Time: Seems quite playable, some tile bank problems. Charlie Ninja: Tilemaps aren't big enough, sprites are a bad dump, some scrolling problems on title screen.. (I'm sure it was ok before). Joe And Mac Returns: Playable, although I can set it to either a very fast speed, or a very sluggish speed depending on Vblank, I'm not sure which is correct... Completed a few levels and it didn't crash so it seems ok.
- 30th July      2005: David Haywood - 3 Weeks of staring at numbers solid until 4am, a bit of teamwork with key developers, and we have our first results... (Magical Drop (Deco 156) shows the message: WARNING - GAME MODE SETTING ERROR). Its not much, but maybe a sign of things to come. Update: I moved from Magical Drop to Joe and Mac Returns. Note that the tile roms on both sets are bad dumps, hence the corruption in the screenshots. Sprites haven't been added. Fixed the tile banking for the platforms. 2nd Update: Found a way to get Osman to boot via the debugger and it appears we can fix the Joe & Mac Returns tile rom by using bits from each of the bad dumps. None of these will be playable until the protection has been worked out however.
- 0.98u2             : Some progress on the Deco 156 encryption [David Haywood].
- NOTES: Data East MLC Hardware uses an encrypted CPU labelled 156, which is completely unknown. The encryption is likely very complex because the files in the archive that are encrypted don't compress at all. The decryption is internal to the chip which makes trojaning the board or manual decryption very difficult.
- NOTES: The Data East chip 156 is an encrypted ARM processor.
- SOURCE: machine\deco156.c
- PCB: DE156, QFP100 (Skullfng), 156  932EV 301801 (Nslasher), 156 (Backfire, Charlien, Osman, Stadhr96)



10.7   ARM7

- 0.123u1            : ARM7 updates [Anonymous]: Correct mode at reset (it's always 0b1....). HandlePSRTransfer: remove wrong code, correct detection of privileged mode. Correct carry output for ROR. Thumb ASR Rd,Rs: correct carry computation. Thumb ldmia/stmia: correct value for writeback when the writeback reg is in the list. ARM ldm/stm ignore lower bits of the address. Most of the exceptions force the I bit. Ignore some flag bits in the CPSR.
- 0.123              : R. Belmont fixed PSR transfers in the ARM7 core.
- 0.122u7            : SGINut added support for the BLX opcode in ARM7 THUMB mode.
- 0.119u1            : ARM7 core fixes [R. Belmont]: Fixed unaligned reads/writes (again). Fixed minimum instruction bytes to account for Thumb mode. Fixed missing dependency in ARM7 build rule. Fixed Thumb mode ASR instruction.
- 0.118u1            : ARM7 core fixes [R. Belmont, Ryan Holtz]: Fixed behavior when R15 is the source of a MOV. Fixed flags calc for ADC/SBC. Fixed flags calc for NEG. Fixed flags calc for CMP. Fixed time running backwards on Thumb instructions. Fixed some ARM instructions doing indiscriminate change_pc()s.
-  9th August 2007   : R. Belmont - DisARMing: Another day, another bunch of dead ARM7 bugs. Good stuff from this batch includes both Metroid games (GBA) now being playable and improved music quality in some games. Cheat sheet on the MAME significance: A good-running ARM7 core will be necessary for future PGM games (as their protection programs are trojaned or decapped) and sound in NAOMI games if/when those are supported. It's much easier to test the core with GBA games though.
-  7th August 2007   : R. Belmont - Ryan and I fixed several more ARM7 core bugs and a few GBA hardware emulation issues, and now many more games boot or are playable that weren't before.
- 0.115u3            : More ARM wrestling: [R. Belmont]: Fixed error in carry propagation on ALU opcodes of the form ALU r1, r2, r3 SHIFTEROP #imm. Fixed Thumb ADD instructions where the PC is involved. Fixed LDMIA to mask off bits 0 and 1 of the destination address. MSR instruction now properly respects processor mode and field code flags.
- 30th May 2007      : R. Belmont - More ARM7 fixes (including several that were backported to the original ARM core - could someone check if it's now possible in 0.115u2 to beat the end boss on Dragon Gun?), so of course I have a few new GBA screens.
- 0.115u1            : Improvements to the ARM7 core [R. Belmont, Ryan Holtz]: Fixed 32-bit unaligned reads to "scramble" properly. Fixed carry flag calc for SUB/SBC/CMP family instructions. Fixed multiply-and-accumulate instructions. Added more instructions to the disassembler. Fixed logical and arithmetic shifts. Added more Thumb instructions. Fixed relative loads and stores Fixed LSL/LSR with zero shift values. Fixed the disassembly of CMN. Verified behavior when ADD destination is the PC on real h/w.
- 13th May       2007: R. Belmont - More work on the ARM7 SUB/SBC/CMP in Thumb mode were miscalculating the carry flag, and I also improved a few more GBA hardware bits. More games are showing their faces and/or playing better music and/or showing better graphics.
- 0.115              : Additional ARM7 core fixes [R. Belmont]: Fixed SWI instruction in Thumb mode. Rewrote SWP instruction to work properly. Added some missing change_pc()s.
-  5th May       2007: R. Belmont - ARMed and dangerous: MooglyGuy and I shook the ARM7 core and some more bugs fell out, with these results. Keep in mind the GBA video emulation in the driver is extremely simplistic right now, so it's amazing the GBA stuff shows as well as it does. You can't tell here, but all the sound hardware is present and rockin' in most of these games too.
- 0.114u4            : Significant ARM7 update [R. Belmont]: Cleaned up disassembly. Added support for many more Thumb instructions. Removed unnecessary logging. Unaligned reads/writes are supported.
-  1st May       2007: R. Belmont - MAME/MESS's ARM7 core was misinterpreting the very important Thumb version of SWI (SoftWare Interrupt, used on GBA to call the very useful BIOS routines) as 'branch always'. Fixed that, and all sorts of things lit up.
- 0.111u6            : MooglyGuy fixed the disassembly, operation and cycle timing of many Thumb instructions in the ARM7 core.
- 0.109u5            : Aaron Giles converted the ARM7 disassemblers to the new format and added step in/out support where it was obvious.
- 0.105u4            : MooglyGuy improved ARM7 thumb mode disassembler. Big pile of updates/improvements to the ARM7 core thumb mode and the PGM drivers [David Haywood, ElSemi].
-  1st May       2005: David Haywood - Been doing some work with ElSemi updating the Thumb support in the ARM core based on the Nebula code. As a result these are improved (but don't work properly due to various core bugs.) They also run at about 25% speed because the ARM emulation is very demanding. Thanks to Mooglyguy for the original Thumb support.
- 0.104u5            : Preliminary Thumb implementation for the ARM7 core. Many opcodes present, but there are definite sign problems [Ryan Holtz].
- 0.91u1             : ARM7 compiler fixes [Lawrence Gold]: Trailing comma at the end of an enum.
- 0.90u2             : ARM7 CPU core [Steve Ellenoff].
- SOURCE: cpu\arm7\arm7.c
- PCB: Cirrus Logic CL-PS7500FE-56QC-A 84903-951BD ARM 9843J, ARM710C, QFP240 (Ssfindo), CL-PS7500 84877-951BD ARM 9843J (Ppcar), ARM 312 SAMSUNG S3C2410 (Bballoon)


10.8   DECO ???
- NOTES: The SH-2 CPU is placed on the Game side of the Data East MLC cart.
- SOURCE: drivers\deco_mlc.c
- PCB: SH-2 CPU, surface scratched, QFP144 (Avengrgs)


10.9   DECO 222
- NOTES: The DECO 222 or C10707 CPU is a custom 6502. Decrypt CPU1 or CPU2 (audio) roms - see driver btime.c or dec8.c
- PCB: C10707-1 (Boomrang, Kamikcab, Oscar, ProSoccer, Sdtennis, Shootout), DECO 222 (dec8.c)





11.    Nintendo

11.1   N2A03

- 0.114u4            : Wilbert Pol improved accuracy of 6502 CPU cores (DECO CPU16, M4510, M6502, M6509, M6510, M6510T, M65C02, M65SC02 and N2A03) to implement the read/write that happens on every cycle. Moved the "undocumented" instructions from the 6510 cores into the main 6502 core, since there were several other versions of the 6502 cores which have the same undocumented instructions. Removed some of the #define override magic that was going on to make the code easier to read and understand. Updated the 6510 core port_read and port_write functions to include the ddr register in the parameters.
- 0.108u5            : Wilbert Pol updated the TN2A03 CPU to match the proper cycle timings and unsupported opcodes revealed by Blargg's NES chip test.
- 0.102u4            : Rob Bohms fixed one invalid N2A03 opcode.
- 0.102u3            : Rob Bohms implemented some N2A03 undocumented opcodes.
-  9th September 1999: Juergen Buchmueller added the Nintendo 2A03 CPU to the 6502 core.
- NOTES: The N2A03 is a modified 6502 with built-in input ports and two (analog?) outputs.
- NOTES: There is also the N2A03 sound CPU.
- SOURCE: cpu\m6502\tn2a03.c
- GAMES: Nintendo - Donkey Kong 3 (1983) PlayChoice-10 games (1983-1991)


11.2   G65C816

- 0.113u4            : G65816/M37710 CPU core updates [R. Belmont]: Fixed a race condition in the WAI instruction where the CPU could get stuck. (MESS bug #661, may have caused intermittent issues with Namco games in MAME too). Fixed block transfer instructions when the accumulator is in short mode. (Fixes some SNES games not booting, notably Final Fantasy Mystic Quest).
- 0.109u5            : Aaron Giles converted the G65816 disassemblers to the new format and added step in/out support where it was obvious.
- 0.107u3            : 65816/377xx update [R. Belmont]: Made block transfer instructions interruptable as they are on both actual chips (previously a single opcode could eat >400,000 cycles with obvious consequences for interrupt timing). Fixed M377xx block transfers (move one less byte than the 65816).
- 0.102u3            : Rob Bohms fixed the ADC and SBC opcodes in G65816 (for BCD math).
- 0.100u4            : Updated 65816 and 37710 cores [R. Belmont]: Fixed both CPUs to set the data bank register to the destination on an MVN/MVP. Some minor tweeks so the debugger works properly when the 65816 is executing out of a read handler (as it always is for the SNES).
- 0.94u2             : Nathan Woods added to src/cpu/g65816/g65816op.h a patch which fixes a bug whereby the CPU could switch modes without entering the set of functions for that mode. Specifically, if a mode change occurs it will break out of the execute function and reenter the correct function.
- 0.93               : G65816 disassembler changes [Nathan Woods]. program_read_byte() is no longer used for disassembling and also the core now reports the PC as being the full PB or with PC.
- 0.92               : Nathan Woods added a hook that allows a driver to install a custom read handler for reading interrupt vectors (the 65816 has a signal that is asserted when reading a vector and certain hardware needs to reroute the read).
- 0.90u4             : Nathan Woods fixed G65C816 DASM error.
- 0.90u2             : Nathan Woods cleaned up the G65816 CPU code a bit; make some functions static and added step over/out support to the disassembler.
- 0.71u3             : Angelo Salese fixed the BCD conversion when using the Decimal Flag in ADC and SBC.
- 0.37b14            : Removed cpu\g65816\g65816.c, g65816ds.c and g65816o0-4.c.
- 28th May       2000: Karl Stenerud updated the G65C816 CPU core.
- 22nd May       2000: Lee Hammerton fixed yet some more G65C816 core bugs.
- 20th May       2000: Lee Hammerton fixed a G65C816 core disassembly bug.
- 18th May       2000: Karl Stenerud sent in a preliminary G65C816 CPU core.
- NOTES: The Nintendo SNES G65C816 or GTE65816 CPU is a C64/C128 upgrade CPU. Has 16 bit wide registers, 24 bit address space, 65c02? compatible mode and additional commands.
- SOURCE: cpu\g65816\g65816.c
- GAMES: Nintendo Super System games (1991-...)


11.3   SPC700

- 0.102u5            : Rob Bohms fixed the SUBW H flag in the SPC700 core.
- 0.102u3            : Fixed several bugs in the SPC700 core [R. Belmont]: Fixed carry usage in ADC/SBC, fixed overflow flag in ADDW/SUBW (I think), BRK now modifies the status register properly and fixed DAA/DAS edge case.
- 0.100u4            : R. Belmont fixed operand order for SBC to memory
- 0.100u3            : R. Belmont fixed bugs in SPC700 ADC, SBC, ADDW, SUBW, MUL, DIV and CLRV opcodes.
- 0.100u2            : R. Belmont fixed disassembly of 2 SPC700 instructions, fixed behavior of the APU port clear flag to not clobber the output ports - games now can boot and run without the "APU skipper" and fixed SPC700 CMP instruction flags.
- 0.37b14            : Removed cpu\spc700\spc700.c and spc700ds.c.
- 28th May       2000: Karl Stenerud sent in a new SPC700 CPU core.
- NOTES: The Sony/Nintendo SPC700 CPU is 6502-based at heart but contains a lot of the extended opcodes of the Mitsubishi 770 and 7700 series 65xxx-based MCUs, plus a few special twists borrowed from the 68000. It was designed by Sony's Ken Kutaragi, later the "father of the PlayStation". Original emulation by Anthony Kruize and Lee Hammerton. Thanks to Anonymous, TRAC, Brad Martin, anomie, Blargg, and everyone else on ZSNES Technical for probing the darker corners of the SNES with test programs so we have a chance at getting things accurate.
- GAMES: Nintendo Super System games (1991-...)
- SOURCE: cpu\spc700\spc700.c


11.4   DSP-1

- 0.122u3            : Improves accuracy and documentation of NSS/SNES DSP-1 [Andreas Naive, R. Belmont].
- 0.102u3            : DSP-1 support (including all subtypes) [R. Belmont].
- NOTES: SNES "DSP-1" add-on chip. Code from http://users.tpg.com.au/trauma/dsp/dsp1.html. By The Dumper (Electrical Engineering), Neviksti (Physics), Overload (Computer Science), Andreas Naive (Mathematics)
- SOURCE: machine\snesdsp1.c


11.5   RSP

- 0.122u7            : RSP Changes [SGINut, Nicola Salmoria, Ville Linde]: Initialize RSP registers to 0 in lieu of mame_rand. Re-fix RSP single-stepping mode when set by another CPU. Reading the RSP PC returns only the least significant 12 bits. Fixed flag behavior when read out via CFC2. Fixed RSP VRCP instruction to match the real hardware results. Corrected VRCP element lookup. Corrected unaligned DMA behavior.
- 16th January   2008: MooglyGuy - One Step Forward and No Steps Back. A couple new discoveries: * The RSP's registers power up to a random state, excluding accumulators, which are initialized to zero. * The RSP executes exactly one instruction before kicking into single-step mode, rather than immediately changing modes. What's next? Who knows!
- 0.122u6            : Minor RSP fixes [SGINut]: Fixed accumulator state on powerup by testing against real hardware. Fixed single-step behavior by testing against real hardware.
- 0.121u2            : More formally separated the RSP core from the N64 driver [Atari Ace].
- 26th August    2007: MooglyGuy - Making progress on the RSP probe. Over the past few days I've been putting the polishing touches on the user interface for the RSP Probe section of the test suite; the only remaining task is to write the actual probe code itself. This isn't as absurd as it sounds; in fact, the probe code will be rather elementary, as I've already written standalone versions to test individual opcodes, and by and large it'll be a copy/paste job. The most difficult issue so far has been how to present the appropriate amount of data to the user for tweakage. The main issue with regards to the interface was how to deal with series of flag-affecting opcodes. I hadn't thought of this until I looked at opcodes on an individual basis, but there are some ops where the behavior is dependent on the compare, carry, or zero flags when entering the instruction, and can subsequently modify those flags for further use. As it turns out, the maximum number of chained instructions is around three, so it was a simple matter of having three opcode selectors that are enabled and disabled when the appropriate opcode is selected in the selector before it.
-  6th July      2007: MooglyGuy - I've started to work on RSP Probing. This is somewhat of a challenge from a user interface standpoint; previously, any testing was done by me hand-assembling RSP instructions and surrounding them with the appropriate MTC2, ADDI (to tweak the numeric parameters) and branch opcodes, converting the resulting binary into a header file containing an array of 4096 pre-defined bytes, and then recompiling the probe. In this case, I have to find some way of encapsulating that behavior into a pretty interface so that the end user doesn't have to recompile the probe every time he or she wishes to test a new opcode. My current plan of action is to let the user select the following parameters: 1. Opcode to test. 2. Vector parameter increment values for parameters 0 through 7. 3. Start and end values. 4. Load address and load values (for vector-load opcodes). 5. Store address (for vector-store opcodes). One issue to which I am acquainted is the fact that some vector opcodes use one vector as an input parameter, whereas others use two vectors. Some opcodes load a vector's parameters from DMEM, others store the parameters into DMEM. What I'm considering is having the probe simply fill the secondary input vector with parameters in the reverse order as the primary input vector in the case of opcodes that have two input vectors. The planned method for handling load and store opcodes is to have the necessary additional user-tweakable parameters appear when the user selects the relevant opcodes on the opcode toggle. This is going to be a bit of a pain, in that it will tax the UI framework that I've put together for the probe, but it shouldn't be anything that I can't handle.
-  5th July      2007: MooglyGuy - I've drawn up a basic block diagram of the N64's architecture. 1. RCP - Reality Central Processor. MIPS chip model R4300. Clocked at approximately 94MHz, with 16kbytes of instruction cache and 8kbytes of data cache (though the listed cache sizes are questionable). Integrates standard COP0 (MMU) and COP1 (FPU) modules. 2. RDRAM - The Nintendo 64's base configuration contains 4mbytes of RDRAM located at the expected place in KUSEG, KSEG0 and KSEG1. An additional 4mbytes is mapped directly after the first 4mbytes if the user has a memory expansion pack inserted into the memory expansion slot. 3. RSP - Reality Signal Processor. Depending on how you look at it, it's either a standard MIPS chip on testosterone or a standard MIPS chip on an antiandrogen. It was designed specifically to handle display lists and audio lists. Its status is partially accessible by the RCP as COP2. The RSP has no MMU or FPU; COP0 access maps to the RDP (4)'s status and command buffer, COP1 does not exist, and COP2 maps to a custom vector instruction set designed specifically for the Nintendo 64, though it is rumored that the instruction set is the predecessor to the VICE multimedia extensions found in the Silicon Graphics O2 workstation. The RSP's vector extensions give the RSP an additional 32 vector registers; each register is 128 bits wide, made up of eight 16-bit fixed-point values that are accessible in various combinations based on bitfields present in the vector-specific instructions. The vector registers can also be accessed manually via MFC2 and MTC2 instructions. In addition, there are eight 64-bit-wide accumulator registers that are accessible only through individual vector-related instructions.
                                   To call the RSP's memory architecture bizarre would be an understatement; its instruction cache (8kbytes) and data cache (8kbytes) have been repurposed into the only memory accessible to the RSP. Furthermore, the RSP uses Harvard architecture, limiting data fetches to DMEM and instruction fetches to IMEM. Both IMEM and DMEM are mapped into the RCP's memory space; both the RCP and RSP may initiate DMA transfers to and from RDRAM, and the RCP can manually access the RSP's memory area, though manual access is subject to caching. In both this respect and the additional vector instructions, the RSP can be likened to one of the Playstation 2's VU1 or one of the Playstation 3's SPUs. I could provide more information, but this entry is already quite long, so if any further information is desired, drop me a line at my above-listed locations. 4. RDP - Reality Display Processor. This is what handles most - not all - graphical capabilities for the Nintendo 64 (more on that in a moment). It pulls 64-bit-wide command packets from either RDRAM or RSP DMEM depending on a bit in its status register. Command packets can range from a single 64-bit word (Full Sync, Sync Pipe, Set Color Image, Load TLUT, et cetera) to 22 words (Triangle with Gouraud, Texture and Z-Buffering). While it is not as fast in terms of fill rate as the Playstation 1's GPU, it makes up for it in feature richness. It supports significantly more texture formats than either the Sega Saturn (which is ostensibly not a 3D system, anyway) or the Playstation, including YUV16, Intensity (grayscale texture tinted by a specified primitive color, useful for particle effects) and Intensity with Alpha. It features a four-parameter color combiner which implements the equation (A - B) * C + D separately for both RGB and Alpha, as well as four-parameter blending with optional two-cycle mode (with the expected throughput penalty, of course); in fact, the Color Combiner is sufficiently advanced that outside of software rasterization, one needs full pixel shader support in order to fully emulate its features. The RDP's framebuffer and Z buffer are stored directly in RDRAM. 5. VI - Video Interface. It's fairly unremarkable, as it is designed to be. It handles low-level signal generation, allowing framebuffer origin, color burst, horizontal sync, vertical sync, and other signal-related parameters to be tweaked to the engineer's liking. More usefully, it is worth noting that since the framebuffer is memory-mapped instead of being in a separate CPU-inaccessible region of memory as with the Playstation 1, framebuffer effects are a cinch. 6. Cartridge Memory - This is worth noting, as the cartridge is mapped at 0xb0000000, not 0xbfc00000. In fact, a cartridge is not bootable. The Nintendo 64's Peripheral Interface contains four kbytes of embedded ROM which is initially mapped into memory, but becomes invisible after a certain (as yet unknown) number of cycles. Its job is to perform initial handshaking with the security IC on a cartridge, then subsequently perform a DMA transfer to move a specific portion of the cartridge's memory into KSEG0, at which point the RCP jumps to 0x80000400. While the RCP can access cartridge memory directly, it is much more efficient to simply perform a DMA transfer as necessary. 7. RSP Access - This is labeled simply because of the multitude of ways that the RCP and RSP can communicate. First and foremost, the RCP can read and write the RSP's status registers - including PC. The main status register for the RSP has eight semaphores that serve specifically as a way to communicate without having to yank a full interrupt on the RCP. As mentioned in section (3), the RSP's IMEM and DMEM ranges are accessible from the RCP as well, but are subject to caching. Lastly, both the RCP and RSP can initiate a DMA transfer of IMEM, DMEM or both ranges. Hopefully this provides some insight into the strange, convoluted world that is the Nintendo 64.
-  4th May       2007: MooglyGuy - I've been thinking of writing a complete test tool for the Nintendo 64 hardware. As it is currently planned, the test tool will have the following features: 1. Memory Probe: View memory (U8 / U16 / U32 / S8 / S16 / S32 / Float), Write memory (U8 only) and Memory Playback - build a list of addresses and values that will be written to in one go. Useful for triggering a DMA transfer or other event that requires multiple register accesses acros a short period of time. 2. RSP Probe: Harness for hooking up a C-based RSP core for parallel testing. Pull register contents into main memory for viewing. Direct read/write access into IMEM and DMEM via the Memory Probe. Manual single-step and Program Counter control. 3. RDP Probe: RDP packet constructor. Choose packet type from a verbal list. Set named parameters rather than arbitrary 32-bit words. RDP packet playback; playback a sequence of packets transcribed by MAME, or your own emulator if you conform to the same specification.
-  6th April     2007: MooglyGuy - She'll Dance: At first, I was under the impression that it would take a prohibitive amount of time to comprehensively test the reciprocal and reciprocal square-root functions due to the fact that VRCPH/L and VRSQH/L operate on 32-bit operands, and it takes long enough to do a test run of a standard single-element opcode. Initial estimates based on 8 hours for a 2^14-iteration test on a given opcode resulted in a rough guesstimate of approximately 60 years(!) to run through all possible values for both VRCPH/L and VRSQH/L. However, whilst daydreaming at work today, I hit upon the notion that it might enter the realm of feasibility if I were to cut out the main two bottlenecks - most notably the full register mirroring, opcode-level interleave, and general emulation of the full RSP. With that in mind, I went about writing a very short function to populate the entirety of DMEM with a given span of 0x800 reciprocal values, and a custom function to calculate what the emulator would generate based on simply copy/pasting the single opcode's source into a for loop. Amazingly, this managed to reduce the time domain from taking on the order of 32 hours to test all 2^16 input values for an opcode to two seconds. At this point, it appears that a conservative estimate would be approximately 24 to 48 hours to test all possible values of VRCPH and VRCPL. Since I do not currently have a DexDrive or memory pack, I will be dumping all discrepant values to the screen and transcribing them - not anywhere near as Sisyphean a task as transcribing all values in their entirety. With that, I leave you with a snapshot of the first page of values for me to transcribe.
-  5th April     2007: MooglyGuy - Theatre of the Macabre: Several points to touch upon: As it turns out, the massive geometry corruption in the Zelda games as well as Diddy Kong Racing and Mickey's Speedway is due to unaligned DMA. Apparently this is causing trashed display lists to be sent, which is naturally a bad thing. This is likely due to a CPU core bug, though I will be writing a separate probe program to test behavior when performing unaligned DMA anyway. As it turns out, my initial fix to VRCP was only a fix for the gross inaccuracy in looking up the appropriate element. After extended testing, it has been discovered that some values will occasionally generate a result that is very slightly different between the N64 and emulated RSP, for no apparent reason. For a solution, see the point below. An anonymous contributor has suggested simply dumping out full tables for all values that VRCP, VRCPH/VRCPL, VRSQH and VRSQL can generate, storing the results on a memory pack which can then be read on the PC via a DexDrive. However, one point I failed to note during the discussion was that while VRCP works with a single 16-bit element, VRCPH/L and VRSQH/L utilize two 16-bit elements to form a 32-bit value. Hence, full tables would be prohibitive in size. However, a viable alternative is to store a table (presumably much smaller) of only those values that differ between cores. It's a hack, granted, but it still results in the proper effect.
- 31st March     2007: MooglyGuy - New Math: A few new test items this afternoon: Opcode / Description / Status: VADD - Vector - Add Pass (tentative); VSUB - Vector Subtract -> Pass (tentative); VABS - Vector Absolute Value -> Pass (tentative); VADDC - Vector Add w/ Carry -> Pass (tentative); VSUBC - Vector Subtract w/ Carry -> Pass (tentative) and VRCP - Vector Reciprocal -> Fixed. I'm tentatively marking VADD*/VABS/VSUB* as passing - it's run through about 4% of the test suite values right now, but typically if it hasn't failed by now it's not going to. Addendum: It just occurred to me that I should probably mark VSAW (Vector Store Accumulator Word) as passing as well. I use it to transfer the accumulators into a vector, which I then write to DMEM, in the register-transfer function of the RSP probe. Since the transfer function works on both the N64 and MESS, it's an incidental test, so it's obviously fine.
- 31st March     2007: MooglyGuy - Shave and a Haircut: The clipping operations seem to check out: Opcode - Description - Status: VCL - Vector Clip -> Low Pass; VCH - Vector Clip High -> Pass and VCR - Vector Clip Reverse -> Pass. Also, it would appear that there's some confusion with regards to what I'm currently doing, due to an update that I failed to post: I found out what was preventing the patched core from working, so I am now back to testing individual opcodes against the Nintendo 64 itself.
- 30th March     2007: MooglyGuy - Discordianism: A hodge-podge of opcode updates: Opcode - Description - Status; VAND - Vector AND -> Pass; VNAND - Vector Not AND -> Pass; VOR - Vector OR -> Pass; VNOR - Vector Not OR -> Pass; VXOR - Vector Exclusive OR -> Pass; VNXOR - Vector Not Exclusive OR -> Pass; VCL - Vector Clip Low -> Pass; VCH - Vector Clip High -> Pass and VCR - Vector Clip Reverse -> Pass.
- 30th March     2007: MooglyGuy - The Programmer's Stone: Latest opcodes to undergo testing: VRSQL / VRSQH: Vector Reciprocal Square-root Low/High. First verified inaccuracy. Shouldn't subtract the destination element off of 7 when looking up the destination element, just use the value encoded in the opcode. VRCPL / VRCPH: Vector Reciprocal Low/High. Same issue.
- 24th March     2007: MooglyGuy - Wonder Twins: I probably should have done this after first applying it, but I have discovered that the patch that made the RSP core endian-independent also managed to prevent any games from working now. With that in mind, I am currently bolting the original, endian-dependent RSP core onto the new, endian-independent RSP core, without actually making it a separate CPU core. Before each opcode is executed, it will synchronize the bolted-on RSP's data memory (hacked into a separate array) with the main RSP data memory, and after each opcode, it will compare the separate fake DMEM and register state with the endian-independent RSP's DMEM and register state. If there's a desync, it will fatalerror, and inform me of the current Program Counter so that I can see what opcode I need to fix in the endian-independent core. Simple, right?
- 24th March     2007: MooglyGuy - Irrational Exuberance => VMULF: Pass
- 24th March     2007: MooglyGuy - Electric Avenue: At the moment, VMULF is undergoing unit testing. It consists of loading s0 with a value, then loading it into each of the elements in v1 and v2, then executing VMULF v0, v1, v2. This will load v0 with v1 * v2 * 2. The current test harness loads s0 with 0 and subsequently adds 0x0011 to s0 with each iteration. This strikes me as a fair enough balance between comprehensiveness, given that running 65536 iterations would be prohibitive, whereas 3855 iterations (0xFFFF / 0x0011 = 0x0F0F) is comprehensive enough, ensures that the elusive 0xFFFF edge case will be tested, and is still quick enough to be able to run to completion through the night. As I type up this entry, it's up to 0x2222. Hopefully, by tomorrow morning, it will still be running, and will have rolled over!
- 18th March     2007: MooglyGuy - 1 In 10 Will Enjoy It: Well, the RSP probe seems to be working. Hooray! I've highlighted the registers and their corresponding positions in vector register 0. It'd reflect the lower 16 bits of r16 through r23, but as you can see, the registers were in the middle of updating when I snapped the picture. I ended up having to implement a couple of workarounds. First, you'll notice that there appears to be a lot of strange contents in the registers. That's because the RSP's registers are in a randomized state on powerup. For what it's worth, though, they appear to be in the same random state every powerup, so theoretically it would be a trivial matter to emulate them with such values. For now, though, I put in a workaround such that it first copies the real registers into the emulated registers so as to not throw a spurious mismatch. Secondly, single-stepping mode does not handle jumps gracefully, and so I've made it so that the prober does not attempt to run the register-copy function if the RSP is in the middle of a jump. Anyway, now it's pretty much on the eminent Ville Linde to write the proper probe code rather than the rudimentary test data that I'm using. Still, good stuff all around.
- 16th March     2007: MooglyGuy - Alas, Poor Yorick: Well, the Doctor V64 arrived, and it works perfectly. The RSP probe, on the other hand, does not. I've commented out everything that tries to touch the RSP directly, leaving it just emulating the RSP and updating the display on-screen, but even then it just gives me a black screen. I'll be damned if anything is occurring to me immediately offhand as to what the problem could be, given that the demonstration program that hcs includes with alt-libn64 works fine, and I've made only minimal modifications to its functionality. Ah well, I'll take a look at it after a touch of WoW. Yeah, I know.
-  9th March     2007: MooglyGuy - Highway To Hell: Actually, it's faux-failure - I intentionally induced an error in the CPU core to make it fail. It will automatically dump out any mismatching GPRs, vector registers and accumulators that do not match, as well as their previous states (which is admittedly redundant to display twice) and the twin program counters (emulated and real) onto the screen for easy debugging. The next step, as I wait for the Doctor V64 to arrive from the UK, is to add other functionality such as being able to page through a display of the entire register set after a mismatch. In addition, yesterday I found the first - arguably most important for the trojaning effort - thing to figure out about the N64's hardware: how the RSP handles setting the program counter while handling a branch in single-step mode. Think about it: The RSP single-steps through a branch, but there is still another instruction to be executed immediately after. While the RSP is halted, you set the PC to be elsewhere. What happens? We shall see.
-  6th March     2007: MooglyGuy - That's A Big Twinkie: What is shown in that picture is an emulated N64 displaying the register contents of an emulated RSP being emulated on that emulated N64, the RSP having just run a short bit of code. For all intents and purposes, I now have a program which can conceivably run test code on a real Nintendo 64. I expect once the Doctor V64 is in my possession that it won't run on a real Nintendo 64, because that's how my luck has been. However, for now, take comfort in the thought that perfect RSP emulation may soon be a reality.
-  3rd March     2007: MooglyGuy - The Late Night Double-Feature Picture Show: I managed to optimize the register usage of the RSP register-transfer function. My original plan was to limit unit testing to vector operations only, but in the event that a full test is ever desired, it should now be possible to test all instructions' effects on all general-purpose registers except one (t0) now. I've hard-coded the register-display function to show "0xdeadbeef" for registers that can't be tested. I suppose marking r0 as untestable is a bit unfair, but there's just not a whole hell of a lot to test.
-  3rd March     2007: MooglyGuy - Baby Steps: A couple new developments. First of all, thanks to an anonymous donator, I will soon be in the possession of a Doctor V64 unit with which I can run test code on a real N64 - this is when the magic starts to happen. The current plan of attack for probing the behavior of the RSP is to directly port MAME's current RSP core to the N64 itself, and to run the emulated RSP in lockstep with the real RSP, verifying the vector register contents after each instruction (it can be safely assumed that non-special opcodes are in good condition already). According to documentation, the RSP has facilities for running in single-stepping mode such that it will automatically halt after executing one instruction, though I have not heard any verification as to whether or not this works as expected. Second of all, the prober is slowly starting to take shape. The first step, getting a C compiler running that can cross-compile for the N64, has taken place. Currently all the test code does is pull values from the area of RSP DMEM that I have reserved for the RSP-side code to copy the vector registers, but the hard part (getting a viable C compiling environment and the ability to display text on-screen) is done. The next step, over the next day or two, will be for me to graft MAME's RSP core into this new codebase, but that should be reasonably simple.
- 24th February  2007: MooglyGuy - Jiggery-Pokery: First up, thanks to some help from pinchy, the N64 driver in MESS 0.113 should boot via a proper PIF ROM dump rather than the faking it (and most N64 emulators) currently use. Apparently it's been floating around for a while now, but nobody knew how to hook it up right. If you don't understand what I just said, then you are probably the same kind of person who loves UltraHLE and drove an emulation-savvy acquaintance of mine into hiding, so go do some Googling, then come back. After making a particular opcode, 0x7C1C97C0, recompile as a NOP rather than not recompile at all, Legend of Zelda: Ocarina of Time boots right up and looks ugly as sin. Legend of Zelda: Majora's Mask also boots right up. However, I think that this is an incorrectly-named dump. It is, in fact, a dump of "The Adventures of Link in Bizarro RSP Land and the Quest to Buy MooglyGuy a Doctor V64 so that He and Ville Can Fix the Damn Thing". Diddy Kong Racing boots, but dies on an unaligned RSP DMA: sp_dma (RSP): sp_dram_addr unaligned: 0021DB86. Jet Force Gemini runs through its initial loading screens, and then is polite enough to inform me that the RSP has managed to crash. As for the rest of the CIC-6105 games that I know of offhand, Donkey Kong 64, Perfect Dark and Banjo-Tooie simply do nothing. Conker's Bad Fur Day, in keeping with its bad-boy reputation, feels the obligation to make MESS segfault. Mickey's Speedway USA, as if anyone needed any more proof that it's based on the Diddy Kong Racing engine, also dies with an unaligned RSP DMA: sp_dma (RSP): sp_dram_addr unaligned: 002A7DBA. If anyone wishes to see snappier progress on the N64, I would highly advise purchasing a Doctor V64, V64jr, or CD64 unit for myself, Ville Linde, or both of us. Or you could keep waiting around for Project 64 1.7, which will be out shortly after I have grown old and died.
- 0.109u5            : Aaron Giles converted the RSP disassemblers to the new format and added step in/out support where it was obvious.
- 0.105u4            : Nintendo 64 system improvements [Ville Linde, Ryan Holtz]: Fixed a major bug in the RSP core, rewrote the PIF handling and slightly improved triangle rendering.
- 0.105u1            : R. Belmont split out some of the Nintendo 64 core pieces into MESS-shareable modules.
- 0.104u6            : RSP CPU core [Ville Linde]: Major update to the Aleck64 driver. Still not fully working yet.
- NOTES: The Nintendo/SGI Reality Signal Processor (RSP) is depending on how you look at it, it's either a standard MIPS chip on testosterone or a standard MIPS chip on an antiandrogen. It was designed specifically to handle display lists and audio lists. Its status is partially accessible by the RCP as COP2. The RSP has no MMU or FPU; COP0 access maps to the RDP (4)'s status and command buffer, COP1 does not exist, and COP2 maps to a custom vector instruction set designed specifically for the Nintendo 64, though it is rumored that the instruction set is the predecessor to the VICE multimedia extensions found in the Silicon Graphics O2 workstation. The RSP's vector extensions give the RSP an additional 32 vector registers; each register is 128 bits wide, made up of eight 16-bit fixed-point values that are accessible in various combinations based on bitfields present in the vector-specific instructions. The vector registers can also be accessed manually via MFC2 and MTC2 instructions. In addition, there are eight 64-bit-wide accumulator registers that are accessible only through individual vector-related instructions. To call the RSP's memory architecture bizarre would be an understatement; its instruction cache (8kbytes) and data cache (8kbytes) have been repurposed into the only memory accessible to the RSP. Furthermore, the RSP uses Harvard architecture, limiting data fetches to DMEM and instruction fetches to IMEM. Both IMEM and DMEM are mapped into the RCP's memory space; both the RCP and RSP may initiate DMA transfers to and from RDRAM, and the RCP can manually access the RSP's memory area, though manual access is subject to caching. In both this respect and the additional vector instructions, the RSP can be likened to one of the Playstation 2's VU1 or one of the Playstation 3's SPUs. I could provide more information, but this entry is already quite long, so if any further information is desired, drop me a line at my above-listed locations.
- SOURCE: cpu\rsp\rsp.c
- GAMES: Eleven Beat (Hudson 1998), Magical Tetris Challenge (Capcom 1998)



11.6   RCP
- 18th January   2008: MooglyGuy - I seem to have discovered a fairly major issue in the way MAME indexes the elements in the VRCP opcode versus the way the real N64 indexes them. Running a very simple test on VRCP with 0001 as the first word in V[0] and 0000 as the remaining words, here are the results of various combinations of element parameters and VS1REG parameters in MAME (see http://www.moogle-tech.com/smf/index.php?topic=4.0). Quite a bit different. For what it's worth, I'm pretty sure that this can be fixed by replacing the assignment of sel in VRCP, VRCPH and VRCPL simply with "EL & 7" rather than the convoluted "VEC_EL_2(EL, del)".  The only testing I did was to make that modification in MAME and then run Mario 64 and Mario Kart 64; neither was broken any worse than before, but neither was fixed any more than before either - I'd do more comprehensive testing, but I'm heading to bed immediately after posting this because I'm fricking exhausted.
- NOTES: The Reality Central Processor (RCP) is a MIPS chip model R4300. Clocked at approximately 94MHz, with 16kbytes of instruction cache and 8kbytes of data cache (though the listed cache sizes are questionable). Integrates standard COP0 (MMU) and COP1 (FPU) modules.



11.7   RDP
- 20th April 2008: MooglyGuy - Two-cycle texture lookups are completely wrong in MESS. Big shock, right? The whole principle behind two-cycle texturing is that you can look up texels from independent textures in order to do clever things like masking, or not having to upload textures quite as often (upload two textures one time, then just change the combiner mode to switch textures). With the current implementation, we just copy the value of texel0 into texel1. Yeah, that's kind of wrong. I fixed it. This gets us from the current jumbled mish-mash for menu backgrounds in Paper Mario.
- 13th April 2008: MooglyGuy - I decided to look into yet another long-standing bug in MESS's RDP emulation, which is that two-cycle blending is, in a word, screwed up. Two things are wrong with the current implementation: First, two-cycle blending simply takes the output of the second color-combiner cycle as the blended color and calls it a night. This is because of numerous blending issues caused by not having that hack in there. However, it would appear that the majority of the aforementioned issues are caused by the fact that the "inverse pixel alpha" blender input is not quite so. In fact, the inverse-alpha blender input is the inverse of the A-line multiplexer. It is not a constant inverse of the color combiner alpha, as once thought. With that fixed, a number of other things fall in line, including: Ships, planets, and asteroids in Asteroids Hyper 64 are no longer overly dark. The UI in Bio F.R.E.A.K.S. is no longer almost entirely black, and there aren't characters that randomly have black polygons. Clouds are no longer white blocks in the background of Dr. Mario 64's main menu...
- 11th April 2008: MooglyGuy - Rejection Correction: A number of months ago I submitted what I thought was a fix for alpha rejection.  In case you're unfamiliar with it, MESS currently has issues with textures that are bordered with an alpha of zero - the completely transparent pixels still write to the Z buffer.  The end result can be seen the most readily in Mario Kart 64, where all of the karts have a box around them that obscures karts in front of them. As you can see, it's impossible to see the karts in front of Yoshi despite the fact that you should be able to.  This is because Yoshi's sprite is drawn first, and even the transparent pixels surrounding the sprite write to the Z buffer.  The end result is that when the game attempts to draw a sprite that's farther out in front of Yoshi's sprite, the pixels are Z-rejected when they should be visible without issue. My original fix was to reject pixels if the color-combined color had an alpha of zero, but unfortunately this caused issues in a number of other games. As it turns out, the N64 rejects pixels that have an alpha of zero when the texel itself is fetched, before any color combine or blend operations even take place. With that in, things look much better.
-  9th April 2008: MooglyGuy - I tacked Z-buffer viewing onto the PIN64 Viewer. It shows what I'd already guessed, which is that the N64 has some way of aborting Z-buffer writes for texels that have an alpha of 0. However, it also shows something that I wasn't expecting, which was that the N64 seems to have a different Z-buffer format than what we're emulating. It would appear that Z values are biased upwards as they get further away from the far plane - note the shift towards red at the end of the track on real hardware versus green in MESS. I'm not quite sure what this ultimately means, as MESS currently writes the Z value of a pixel into the Z buffer, which is what would make the most sense for a real N64 as well. Oh well, once I can hand-construct commands, it shouldn't be too difficult to figure out. The RDP can be coaxed into drawing a trapezoid with a single triangle command if you pass in degenerate Middle-X-Start and High-X-Start values (click for big). It's kind of hard to see, but that little red blob has four sides. Fun!
-  8th April 2008: MooglyGuy - In renderer news, it would appear that I've found the source of the cracks between triangles in MESS. Anyone who has attempted to run Mario Kart 64 in MESS has noticed the seams that are present in almost every scene. The reason for this behavior is that the software rasterizer originally written by Ville Linde (currently MIA) does not handle fractional coordinates. At all. The end result of this is that triangles have their Y coordinates "snapped" to a full-pixel boundary, while the X coordinates remain the same, resulting in uneven boundaries between triangles that would otherwise be aligned. This can only happen because of the funky way in which the N64 stores its coordinates.  As opposed to virtually any rational system such as the Playstation or any modern 3D hardware, the N64 specifies its vertices in low edge / middle edge / high edge / slope form.  This was clearly done to save processing time, as the edge-walking hardware on the RDP can take in the data virtually unmodified, but it can easily cause rasterization glitches if a person isn't careful. The RDP's edge-walking hardware very likely operates in the following sequence: 1. Load High-X and Middle-X into XLeft and XRight, 2. Load High-Slope and Middle-Slope into StepLeft and StepRight, 3. Load High-Y into Y index, 4. Rasterize 0.25-pixel scanline from XLeft to XRight, 5. Add 0.25*StepLeft to XLeft, 6. Add 0.25*StepRight to XEnd, 7. Increment Y index by 0.25, 8. If Y is less than Middle-Y, go to Step 4, 9. Load Low-X into XRight, 10. Load Low-Slope into StepRight, 11. Rasterize 0.25-pixel scanline from XLeft to XRight, 12. Add 0.25*StepLeft to XLeft, 13. Add 0.25*StepRight to XEnd, 14. Increment Y index by 0.25, 15. If Y is less than Low-Y, go to Step 11 and 16. Done. It's a fairly long list of steps, but it's also fairly simple.  Pretty much any software rasterizer functions that way, it usually translates X/Y triplets into that format. With a quick-and-dirty fix that is going to need some massaging to get into a state that can be submitted, we now get these pretty screenshots. If you look closely, you'll notice that alpha-blended triangles are overly "bold".  This is an outgrowth of the fact that each scanline is redrawn up to four times. A proper fix for this will be to emulate coverage, which is a bit of a daunting task.
-  7th April 2008: MooglyGuy - Thanks to a few additions to the PIN64 Viewer, I've achieved a considerable speedup. The new additions are: * Moving texture descriptors out of cartridge space and into RAM, * Transferring textures using Cart -> RAM DMA rather than memcpy and * Not flushing the data cache after the texture data copy (it was redundant once memcpy went away). Rendering a frame of Mario Kart 64 now takes less than one second rather than anywhere from 5 to 10. With this in mind, I've managed to narrow down the source of the geometry corruption, though I haven't quite found the cause. For some as-yet unknown reason, sometimes a triangle command will cause the triangle before it to become corrupt. No idea why. Observe (all images link to larger versions). Ultimately, I'm not sure what's causing this. The relevant textures are all the same, so it can't be the texture cache being overwritten. The data itself is not changing, so that's not it. It's not a matter of flushing the command data, as that's already being flushed out of the cache. Weirder still, it would appear that direct framebuffer writes can go a bit wonky when they're done after the RDP is finished with its own rendering. Eagle-eyed readers will notice some of the tiles of the TLUT - all of which are supposed to be precisely 8×8 pixels, which I'm manually rendering by writing to the framebuffer - are running into their neighboring areas, and are sometimes being overwritten by neighboring areas. Funky! I have no idea what's causing this, possibly something to do with coverage, possibly not.
-  6th April 2008: MooglyGuy - I've finally managed to get my N64 development environment up and working again. Apparently the time off did my mind some good, as within about an hour and a half I fixed the texture byteswapping issue that had me stumped for several weeks. Previously, text at the top and bottom of the screen was corrupt in the race introduction sequence in Mario Kart 64, and there was significant graphical corruption in Dr. Mario 64's main menu to the point of causing a system hang when run on real hardware. With proper byteswapping, we now get. Eagle-eyed readers will notice that there are some geometry issues in Mario Kart 64. I'm not quite sure what's causing that, as the rest of the scene geometry is largely unaffected. I'll have to look into it once I've optimized the viewer - rendering a capture takes upwards of 5 to 10 seconds, so it's impractical to page through a capture's commands in order to isolate the ones with issues. In other news, Adam Gashlin (hcs, of Neon64 and USF fame) has managed to mostly fix N64 audio output in MESS. There appears to be some sort of issue with the DMA DAC audio device in MAME / MESS, however, as the stream written by -wavwrite shows odd glitches that aren't present if the raw audio stream is dumped out to a file. That's been submitted to MAME along with a DMA fix by Ville Linde. Edit: As there seems to be some confusion, the above screenshots are of the PIN64 Viewer running on a real N64, taken with a video capture card.  I'm sick of having to buy a new 4-pack of AA batteries nearly every week for my crappy digital camera, so this is going to be the new means of taking real-hardware screenshots going forward.
-  5th March 2008: MooglyGuy - A couple bits of miscellany: TLUT (Texel Look-Up Table) viewing support, an update to my frame-merge tool, pin64merge, to support my most recent modifications to the capture format, and a minor PIN64 Viewer bugfix. Yes, the PIN64 Player still has some texture issues to work out, which will pretty much be my text task.
-  7th January   2008: MooglyGuy - ColourBorrower showed me them. In case anyone feels like comparing against reference material, the good ColourBorrower provided me with a link to various Pokemon Puzzle League videos, found here. The strange corruption in the collage on 1/6/2008, "My Pokemans", seems to be caused when the game attempts to draw the borders around the playfield and meters. Now I just need to figure out why. In other news, Ziggy's Z64 plugin is great, I'm sure, but it rewrites a fairly substantial amount of MESS's RDP functionality in order to get hardware acceleration working. I can't make heads or tails of what the changes were under the hood versus MESS's behavior, so I've put in a request for the man to summarize the changes he made. Here's hoping it works. Looks like we've got a bit of work to do. In addition, if it appears that MESS is a bit darker than my TV, it's because it is; not because my TV is increasing the gamma level, but because gamma correction is turned on in the VI by default and MESS doesn't emulate it.
-  6th January   2008: MooglyGuy - I finally got into the swing of writing test code for the N64 again, and decided to tackle the fact that the behavior of DMA transfers when the Count and Skip fields were non-zero was unknown. A couple hours later, I have a fix for almost any game in MESS that previously died with a non-zero dma_count or dma_skip assertion. Wonder of wonders, Pokemon Puzzle League now fires right up and is fully playable. Yesterday I fixed texture loading and texel fetching for 32-bit RGBA textures, which fixes Mario Kart 64's title logo. Last but not least, I was able to reenable texture clamping. It was previously disabled because enabling it broke Rampage: World Tour, but it was able to be reenabled once I discovered the reason. If you're curious, apparently texture coordinates should be recentered on 0,0 for the sake of texel lookup after coordinate clamping and mirroring, not before.
- 29th December  2007: MooglyGuy - (2) I know that there's something wrong with the way MESS handles edges. But nobody can give me a clear, plain English answer as to WHAT is wrong. All I've been able to gather is that inconsistencies and inaccuracies are creeping in due to the fact that when it comes to X coordinates, MESS performs a wholesale truncation of Everyone who has an inkling as to what is wrong seems insistent on describing it in the most arcane methods possible, and when I ask for a more concise summary as to what's wrong, I'm given a link that attempts to describe polygon edge rasterization in an even more crepuscular manner than to what I'm already being subjected. That's not to sound ungrateful for the help that people have tried to provide, it's just that as yet I've failed to understand any explanations given. I know that the problem is the truncation that MESS performs; in MESS, if X is 0.0 to 0.9999, it's truncated to 0, 1.0 -> 1.9999 = 1, 2.0 -> 2.9999 = 2, and so on. But... how's it supposed to be? 0.0 -> 0.4999 = 0, 0.5 -> 1.4999 = 1, and so on? Or what? Just saying that the Nintendo 64 handles coordinates with quarter-pixel accuracy doesn't help me at all, I need to know how to go from those fixed-point values to integer values so that I can actually draw pixels into the framebuffer! After all, it's not like the Nintendo 64 has some huge internal framebuffer that renders at four times the X and Y resolution and then downsamples when storing it to RAM, there's obviously some very simple rounding that it performs in order to obtain whole pixels plus a given coverage (CVG) value. Everyone has yet to tell me what the form is that that rounding takes. RDP is similar to OpenGL? Okay, but that doesn't quite help, the OpenGL spec is huge and I don't know where to begin looking! Argh! The only person who reasonably COULD figure out what is wrong is addicted to WoW, and I don't see that changing anytime soon.
- 29th December  2007: MooglyGuy - Triangles (Even Pink Ones): Today was a pretty productive day, adding support for the following commands: Triangle (all modes), Set Scissor, Set Fill Color, Set Fog Color, Set Blend Color and Set Env. Color. With the triangle and color editing, we can send Mario on our very own LSD trip. he Set Scissor command, as the name implies, affects the scissor box for polygon drawing. The remaining commands that I need to support are as follows: Set Key GB, Set Key R, Set Convert, Set Prim Depth, Set Other Modes, Load TLUT, Set Tile Size, Load Block, Load Tile, Set Tile, Fill Rectangle, Set Prim Color, Set Texture Image, Set Z Image and Set Color Image. Some of these probably don't actually need to be edited - for instance, I hear that color keying is actually broken in production N64 units. Who knew?
- 28th December  2007: MooglyGuy - Hack 'n Slash: Well, that ended up being a lot easier than I thought it would be, though I'm not 100% sure it's accurate to the hardware. I put in a specific check to disable writing the pixel to the framebuffer and Z-buffer if the alpha of the pixel, post-color-combine, is zero. Surprisingly, it didn't seem to adversely affect things: 
- 27th December  2007: MooglyGuy - The Freeman's Nemesis: The first command-editing screen is now in, it allows you to edit the "Set Combine" command. To do so, I had to create a new part, the UIDropdown class. When you have a Set Combine command selected in the main event list, pressing 'E' will bring up the command edtior screen for the command, if one is relevant. Once you press 'D' (Done) the editor screen will go away and return you to the main event list. As a demonstration, I edited most of the Set Combine events to use the following equation for texture color: ( C_ZERO - C_ZERO ) * C_ZERO + C_TEX0. Which results in the following scene (see screenshot). Update: Now we go into the realm of 2D, with the ability to edit Textured Rectangle commands. After some jiggery-pokery to support non-fullsreen UIScreen instances, we have a handy editor for the aforementioned commands: After some fooling around, we can enhance Super Mario 64 for the visually impaired! Not sure what command I'm going to support next. Update (2): Curse the N64. Damn the N64 to hell. I'm inches away from just throwing in the towel. I took a break from PIN64 to try to track down a genuine rendering bug, which is that textures with an alpha border always write to Z, even when fully transparent. For a real example of this, look at the screenshot I posted in "Retro-Active" with the trees in it; you can see that the upper-left tree has a border of transparent pixels around it, and you can actually see the castle through the tree behind it. This is caused by the fact that the frontmost tree is drawn before the rearmost tree, but the tree's entire triangles write to the Z buffer, rather than just the opaque pixels. Thus when the tree behind the frontmost tree is drawn, pixels that should appear do not, as there's an invisible border out to the edges of the frontmost tree's triangles that's written into the Z-buffer. Normally, 3D hardware provides a facility called an "alpha compare" function, which will selectively reject pixels as they're being rendered if their alpha values fall below a given threshold value. In fact, the N64 provides just such a feature. The problem? The Set Other Modes command that comes down the pipe most recently before the trees does not, in fact, enable alpha comparison. I've yet to figure out how the hell, then, the N64 knows to reject the relevant pixels and prevent them from writing to the Z buffer. What's annoying me so much, though, is the fact that everyone seems convinced that it should be really easy to track down, but nobody has offered any convincing explanations as to why it happens.
- 24th December  2007: MooglyGuy - Differently Abled: I've put the ability to disable events in PIN64. Observe the scene with the water polys enabled in Mario64. Update: I've added another UIList to the upper-right pane in the window so that you can see additional info on the command that you have selected. In doing so, PIN64 has made its first true step towards usefulness. For instance, it seemed to me that the bottom face of the first billboard you encounter in Mario 64 was being drawn incorrectly. Now that I have the ability to get a proper interactive view of the commands being sent to the RDP, I can see that the errant drawing is not due to an RDP implementaton bug, but is in fact probably due to an RSP core bug.
- 19th December  2007: MooglyGuy - I've brought the PIN64 UITextQueue class up to date, and am now keeping a list of the events that are queued.
- 16th December  2007: MooglyGuy - PEBKAC: Over the past two weeks I've been overhauling PIN64 under the hood to use proper classes and singletons rather than make everything an ungodly mess of global functions and typedefs. I've done a first pass at converting the UI system found in NUTS - I now have the UITextField class converted over and I've created a new UIRect class to encapsulate colored tiles of arbitrary size in order to get filled window backgrounds and such. It's very rudimentary, but the following demonstrates one UIRect instance and two UITextField instances contained within a single UIScreen instance inside the UI singleton. Also note that I've added the ability to highlight the currently-selected triangle event with a white line around the edges.
- 29th November  2007: MooglyGuy - Making A Pass: I've nearly perfected texture support in PIN64. I had a lingering issue that I didn't figure out until this evening, which is that some captures seemed to be lacking around half the polygons that should have been there. It wasn't until I considered the relative lack of power that the N64 has that it dawned on me: Most N64 games do not, in fact, run at 60 frames per second. With that in mind, I added a #define to my output routines in MESS to output five sequential frames' worth of captures to separately-named files. My hunch was right, and it turns out that a number of games draw half of the geometry in one pass, then the rest of the geometry in a second. I threw together a program to merge together two or more individual frame captures, and lo and behold, it worked perfectly. What follows is a series of screenshots from my current working version. I've also implemented the ability to cycle the event display index. This is the same capture as the merged in-game captures, but with the event display index set to stop halfway through rendering the castle. The next step for PIN64 is to give it some sort of keyboard-controlled user interface for viewing the current state of registers, and possibly manually modifying registers. In addition, I plan to add playback support on real hardware.
- 25th November  2007: MooglyGuy - While NUTS provides a reasonably decent method for detecting errors in MESS's RSP implementation, there's currently no good way to test the RDP implementation. Certainly, NUTS has a rudimentary method for sending packets to the RDP manually, but there's no in-depth tool. With that in mind, I'm now working on a program tentatively called PIN64 - Polygon Inspector for N64. The current plan is to add functionality to MESS that will allow the user to capture all of the commands sent to the RDP over the course of a given frame, then load that capture in a separate program in order to externally analyze the RDP behavior. The analysis tool will allow the user to see a rendering of all or some of the packets sent to the RDP over the course of the frame, view the state of the RDP after each packet, and possibly modify the RDP state somewhat as well. This has the distinct advantage of being able to capture a single frame from MESS, then iterate on MESS's RDP emulation without having to re-run the game each time. Yesterday and today I threw together some initial work. PIN64, in its current state, can either dump the command stream as text or render the command stream on-screen. As I have not yet added support to MESS for saving the textures when they're loaded, the captures lack textures. Nonetheless, it's working decently thus far (see screenshots).
- NOTES: The Reality Display Processor (RDP) handles most - not all - graphical capabilities for the Nintendo 64 (more on that in a moment). It pulls 64-bit-wide command packets from either RDRAM or RSP DMEM depending on a bit in its status register. Command packets can range from a single 64-bit word (Full Sync, Sync Pipe, Set Color Image, Load TLUT, et cetera) to 22 words (Triangle with Gouraud, Texture and Z-Buffering). While it is not as fast in terms of fill rate as the Playstation 1's GPU, it makes up for it in feature richness. It supports significantly more texture formats than either the Sega Saturn (which is ostensibly not a 3D system, anyway) or the Playstation, including YUV16, Intensity (grayscale texture tinted by a specified primitive color, useful for particle effects) and Intensity with Alpha. It features a four-parameter color combiner which implements the equation (A - B) * C + D separately for both RGB and Alpha, as well as four-parameter blending with optional two-cycle mode (with the expected throughput penalty, of course); in fact, the Color Combiner is sufficiently advanced that outside of software rasterization, one needs full pixel shader support in order to fully emulate its features. The RDP's framebuffer and Z buffer are stored directly in RDRAM.
- NOTES: http://moogle-tech.com/blog/  PIN64 = Polygon Inspector for N64



11.8   Minx
- 0.116u4            : Updates to the minx CPU core [Wilbert Pol]: Fixed TEST (94,95,96, and 97) instructions. Fixed 2 MOV instructions (BE and BF). Fixed one AND instruction (DC).
- 0.114u4            : Wilbert Pol added a cpu core for a cpu nicknamed minx. This cpu core is used to emulate the cpu in the nintendo pokemon mini handheld console. 
- SOURCE: cpu\minx\minx.c




12.    Atari

12.1   DEC T11

- 0.124u4            : DEC T-11 CPU improvements [Miodrag Milanovic]: HALT - now calls interrupt vector. ILLEGAL - had PC=0 at the end which makes code not run fine. MARK - now it is implemented.
- 0.124u3            : Aaron Giles removed ancient 720 kludge in the T-11 core. Also added support in the T-11 core for an external vector via irq_callback. Apparently the hardware actually did support this and it is necessary for emulating the BK 0010/11 computer in MESS.
- 0.111u1            : Giuseppe Gorgoglione converted t11dasm.c to use cpuintrf_temp_str() instead of local string pools.
- 0.109u5            : Aaron Giles converted the T-11 disassemblers to the new format and added step in/out support where it was obvious.
- 0.104u1            : Buddabing added save state support to the T-11 CPU core.
- 0.101u2            : Aaron Giles got rid of gross banking hack in the T11 core. Updated Atari System 2 driver to accommodate the lack of the hack.
- 0.36b2             : Aaron Giles fixed a bug in the T-11 emulation which caused APB not to work and the end of race results in Super Sprint to contain garbage.
-  3rd August    1999: Aaron Giles fixed a bug in T11 opcodes and APB started working, but it has some sprite priority problems.
- 16th June      1999: Aaron Giles did a small T-11 cpu core fix, but it doesn't help any of the games.
- 0.33b4             : T11 CPU emulator. This is used by the Atari System 2 drivers [Aaron Giles].
- GAMES: Atari Games - Paperboy (1984), 720 Degrees (1986), Championship (1986), Sprint Super Sprint (1986), APB (1987)




12.2   ADSP21xx

- 0.109u5            : Aaron Giles converted the ADSP21xx disassemblers to the new format and added step in/out support where it was obvious.
- 0.104u1            : Buddabing added save state support to the ADSP-21xx CPUs core.
- 0.103u3            : Aaron Giles added timer support to the ADSP cores and hooked it up for the DCS games.
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. * Harvard architecture CPUs now have data memory fully implemented now. Affected CPUs are the ADSP210x, TMS3201x, TMS3202x, PIC16C5x, and CCPU. All cores have been modified to fully split program and data memory. All drivers using these cores now specify explicit program and data memory maps. This also gets rid of a ton of ugly macros used in memory maps. [Aaron Giles]
- 21st March     2003: Brad Oliver fixed a problem in the ADSP-210x CPU core that occurred in MacMAME.


12.21  ADSP2100

- 0.120u1            : Aaron Giles fixed some incorrect code in the ADSP2100 external flag handling.
- 0.94               : ADSP2100 big endian fix [Alex Eddy].
- 0.77u3             : Aaron Giles fixed ROM loading code in the ADSP2100 core.
- 0.76u2             : Aaron Giles fixed loading of 0 counters so they don't execute infinitely and fixed initial state of the SSTAT register in the ADSP2100.
-  8th December  2002: Aaron Giles added ADSP-2115 support to the ADSP-2100 CPU core and fixed various bugs in it.
-  2nd January   2001: Jarek Burczynski optimized the ADSP2100 core a bit, resulting in a 7 % speed gain on some platforms.
- 17th August    2000: Aaron Giles sent in updated ADSP2100 and TMS34010 cores, fixing some bugs which affected the Atari polygon games.
- 28th July      2000: Michael Soderstrom fixed an ADSP-2100 core crash.
- 22nd July      2000: Juergen Buchmueller optimized the ADSP2100 core a bit, but with no visible speed gain.
-  9th July      2000: Ernesto Corvi fixed a debugger bug affecting ADSP2100.
-  6th December  1999: Aaron Giles sent in a preliminary ADSP-2100 core.
- NOTES: ADSP2100 is a Analog Device Single Processor.
- SOURCE: cpu\adsp2100\adsp2100.c
- GAMES: Atari - S.T.U.N. Runner (1989), Hard Drivin' (1988)



12.22  ADSP2101

- SOURCE: cpu\adsp2100\adsp2100.c
- GAMES: Atari - Steel Talons (1991), Hard Drivin's Airborne  (1993)



12.23  ADSP2104

- 0.77u3             : Aaron Giles added the ADSP2104 variant to the ADSP2100 core, fixed ROM loading code in the ADSP2100 core and changed the mechanism for DCS to report buffer full/empty states. Added IOASIC support for buffer full/buffer empty interrupts from DCS. Added preliminary DCS support for ADSP-2104-based sound.
- 12th December  2003: Aaron Giles - Gauntlet: Dark Legacy and War: Final Assault work with the new ADSP-2104-based DCS sound core, the others fall over at the moment unless I help them along.
-  7th December  2003: Aaron Giles added the ADSP2104 variant to the ADSP2100 CPU core.
- SOURCE: cpu\adsp2100\adsp2100.c
- PCB: ADSP-2104 (Gauntdl), ADSP2104 Gauntleg


12.24  ADSP2105

- 30th November  2000: Ernesto Corvi fixed a bug in the 2105 interrupt model.
- 0.37b5             : ADSP2105 cpu emulation, used by Mortal Kombat 2 sound [Ernesto Corvi].
- SOURCE: cpu\adsp2100\adsp2100.c
- GAMES: Midway - MK II (1993), MK III (1993), WWF: Wrestlemania (1995), Rampage: World Tour (1997)
- PCB: ADSP-2105, PLCC68 (Kinst2), ADSP-2105-KP40, QCC68 (Nbajam)


12.25  ADSP21062 / SHARC

-  8th April     2007: Ville Linde - I fixed some multi-processor issues in the SHARC core, and some Voodoo-related issues in the NWK-TR/Hang Pilot graphics board emulation. As a result, Hang Pilot sprung to life in its whole 3D glory. There seems to be some texture problems still to be fixed though.
-  5th April     2007: Ville Linde - Racing Jam and Hang Pilot are finally starting to show something. I had to force the SHARC not to execute the display list because of some weird bugs, so no 3D graphics yet.
- 0.113u3            : Ville Linde fixed several SHARC opcodes where data transfer was done regardless of the condition. This fixes many things, like the upside-down geometry in Model 2B games. And also, probably all the remaining clipping issues in Gradius 4. At least the planet zooming out in the intro works now. Ville Linde fixed also an interrupt delay slot problem in the SHARC core.
- 18th March     2007: Ville Linde - I was finally able to find and fix the SHARC bugs that were causing Solar Assault and GTI Club to crash. After that I went to improve the Konami 3D graphics chip emulation. Now both games are starting look quite good. Neither game is playable yet, though. Solar Assault is currenly missing the analog controls, and GTI Club still has some problems with the network chip.
- 0.109u5            : Aaron Giles converted the sharc disassemblers to the new format and added step in/out support where it was obvious.
- 0.109u3            : Added cpu\sharc\sharcdma.c and cpu\sharc\sharcmem.c. Removed cpu\sharc\sharcdtb.c. Major rewrite of the SHARC core [Ville Linde]: Bit-accurate reciprocals. More accurate pipeline emulation. Fixed the problems with operation latencies. Regression tested a few floating-point operations for bit-accurate results. Improved DMA emulation. This update will fix most (but not all) of the clipping problems in Gradius 4 and NBA Play by Play.
- 0.106u2            : Ville Linde added support for circular buffering in the SHARC core, and fixed several minor bugs.
- 0.104u1            : GTI Club updates [Ville Linde]: Added some more SHARC opcodes.
- 0.102              : Many fixes to the SHARC core [Ville Linde].
-  9th November  2005: Ville Linde - Fixed a DMA latency issue in the SHARC core. The graphics problems in Gradius 4 are now fixed.
-  7th November  2005: Ville Linde - Fixed another bunch of SHARC bugs and added a few more opcodes. Most of the missing graphics are now showing in Gradius 4, but they are still rather broken, probably due to some more SHARC bugs.
- 30th October   2005: Ville Linde - I've continued to add features and fix bugs in the SHARC core. Now the SHARC is sending the first triangle commands to the Voodoo. For now it's limited to some non-textured triangles in the color test screen and the stars in the background of the first level.
- 24th October   2005: Ville Linde - Fixed some stupid mistakes and added a few more SHARC opcodes and now Gradius 4 gets ingame. Most of the graphics are still missing as they are done with the 3dfx chips.
- 0.99u2             : Ville Linde reworked the SHARC internal ram implementation so that multiple instances of the core work and added data address space.
- 0.97u2             : Improvements to the SHARC CPU core [Ville Linde]: Correct IRQ handling and added many more opcodes, including floating-point
- 0.97u1             : Ville Linde added ADSP-21062 core and partially hooked it up for the Model 2B games and Konami PowerPC based 3D games.
- 25th May       2005: Ville Linde - I've continued my progress on my Analog Devices ADSP-2106x SHARC core. The results are finally starting to show. Gradius IV already passes all of its bootup tests. The 3Dfx chips have also been hooked up already. Unfortunately the game is protected, like all the other Hornet games. Silent Scope currently passes all the tests on the first graphics board. The second board isn't emulated yet. Midnight Run and GTI Club pass all the tests, except one FIFO test, which fails on both boards.
- NOTES: Portions of the code based on ElSemi's SHARC emulator
- SOURCE: cpu\sharc\sharc.c
- PCB: ADSP 21062, ADSP-21062 (labelled KS160X2 HD/C13327.00-2.0 SHARC) (GTIClub, Gradius4), ADSP-21062 "SHARC" EDC35181A-3.0 (Sscope), SHARC ADSP 512k flash Konami no. 022M16C (Sscope2)

12.26  ADSP2112
- PCB: Speed Up (Gaelco 1996)


12.27  ADSP2115
- 0.63               : ADSP-2115 CPU support [Aaron Giles].
- GAMES: Midway - War Gods (1996)


12.28  ADSP2181
- 0.103              : Aaron Giles did some cleanup in the ADSP-21xx core to support program memory more correctly and support execution from multiple banks.
- 0.102u5            : Aaron Giles implemented some more functionality of the ADSP-2181 needed for Road Burners.
- 0.84               : Aaron Giles added ADSP2181 variant to the ADSP21xx CPU cores.
- PCB: ADSP-2181, QFP128 (NBAJamExtreme), ADSP2181 (Batmanfr)



12.3   DSP32C

- 0.109u5            : Aaron Giles converted the DSP32C disassemblers to the new format and added step in/out support where it was obvious.
- 0.62               : Added cpu\dsp32\dsp32.c, dsp32dis.c and dsp32ops.c. DSP32 CPU emulation [Aaron Giles].
- 26th October   2002: Aaron Giles fixed a bug in the DSP32C core that caused random airborne objects in Hard Drivin's Airborne.
- SOURCE: cpu\dsp32\dsp32.c
- GAMES: Atari - Race Drivin' (1990), Hard Drivin's Airborne (prototype 1993)


12.4   ASAP
- 0.109u5            : Aaron Giles converted the ASAP disassemblers to the new format and added step in/out support where it was obvious.
- 0.37b10            : Added cpu\asap\asap.c, asap.h and asapdasm.c. Added ASAP CPU [Written by Aaron Giles].
- 17th November  2000: Aaron Giles sent in a driver for an Atari prototype game called BeatHead.
- NOTES: ASAP = Atari Simplified Architecture Processor
- SOURCE: cpu\asap\asap.c
- GAMES: BeatHead (prototype) (Atari Games 1993)


12.5   Jaguar GPU
- 0.109u5            : Aaron Giles converted the jaguar disassemblers to the new format and added step in/out support where it was obvious.
- 0.79u3             : Nathan Woods adding a missing case to jaguargpu_get_info()
- 0.72u1             : Nathan Woods fixed a bug in the NORMI opcode.
- 0.71u2             : Nathan Woods get_jaguar_memory() now based on memory_get_read_ptr(). Jaguar blitter won't crash if it is instructed to blit to a weird address.
- 0.62               : Added cpu\jaguar\jaguar.c and \jagdasm.c.
- 30th October   2002: Aaron Giles sent in the long-delayed Cojag driver, supporting Area 51, Maximum Force and Vicious Circle complete with perfect sound emulation.
- SOURCE: cpu\jaguar\jaguar.c
- GAMES: Atari - Area 51 (1995), Maximum Force (1996), Vicious Circle (1996 prototype)
- PCB: Jaguar CPU V1.0 6sc880hf106 (Area51, Maxforce)


12.6   Jaguar DSP

- 0.72u1             : Nathan Woods fixed a bug in the NORMI opcode. 
- 30th October   2002: Aaron Giles sent in the long-delayed Cojag driver, supporting Area 51, Maximum Force and Vicious Circle complete with perfect sound emulation.
- SOURCE: cpu\jaguar\jaguar.c
- GAMES: Atari - Area 51 (1995), Maximum Force (1996), Vicious Circle (1996 prototype)
- PCB: Jaguar DSP V1.0 sc414201ft (has Motorolla logo) (Area51)




13.    Toshiba

13.1   TMP8039
- NOTES: See I8039.
- PCB: TMP8039P-6 (Megazone)

13.2   TMP8085
- NOTES: See I8085.
- PCB: TMP8085AP (Hvoltage, Splndrbt)


13.3   TMP68HC000
- NOTES: See M68000.
- PCB: TMP68HC000N, DIP64 (Bbakraid, Rezon), TMP68HC000P (Tetrisp2), TMP68H000P (Mouja), TMP68000 (Kickoff))

13.31  TMP68301
- 0.68               : Added machine\tmp68301.c.
- NOTES: The Toshiba TMP68301 is a 68HC000 + serial I/O, parallel I/O, 3 timers, address decoder, wait generator, interrupt controller, all integrated in a single chip.
- SOURCE: emu\machine\tmp68301.c
- GAMES: MS Gundam Ex Revue (Banpresto 1994), Puzzle De Bowling (Nihon System 1999)
- PCB: TMP68301AF (Grdians, Kiwame, Niyanpai), TMP68301 (Penbros, Pzlbowl)


13.4   T5182
- 0.112u4            : Added T5182 support, which gives sound to darkmist, mustache and panicr [Nicola Salmora, Lord Nightmare, Ernesto Corvi].
- 28th February  2007: R. Belmont - Nicola submitted the completely reconstructed internal ROM of the Toshiba T5182 custom cpu and an updated driver so all 3 games (Darkmist, Mustache Boy and Panic Road) using it have full sound and music.
- NOTES: The Toshiba T5182 is a encrypted custom cpu.
- SOURCE: audio\t5182.c
- GAMES: Mustache Boy (1987), Dark Mist (Taito 1986), Panic Road (Taito 1986)
- PCB: Toshiba T5182 MCU, NDIP50


13.5   TMPZ84C
- NOTES: DIP40  - see Z80.
- PCB: TMPZ84C00AP (Tkdensho), TMPZ84C011AF (Bakuhatu), TMPZ84C011BF (Mjegolf), TMPZ84C015BF (Hanakanz, Quizchq)


13.6   TLCS-90
- 0.111u1            : Luca Elia added new Toshiba TMP90840/TMP91640 CPU core.
- 10th December  2006: Luca Elia - More TLCS-90 games work: A few more games powered by the TMP91C640 CPU now work, like the much requested Mahjong Tenkaigen. These screenshots are actually from one of several bootlegs that where dumped, the original is protected and does not work yet. Another one running on pretty much the same hardware, dynax.c, is Mahjong Reach. This is a bootleg as well, and the only dumped version.
-  3rd December  2006: Luca Elia - I've emulated the TMP90C840/TMP91C640 microcontrollers, some of the few CPU's still unsupported in MAME. They belong to the TLCS-90 family, introduced by Toshiba in the early nineties, the ancestor of the TLCS-900 that powers the Neo Geo Pocket. This 8-bit CPU is essentially a Z80 on steroids: different binary encoding, 20 bit address bus, more opcodes and addressing modes, interrupt controller, 6 timers, A/D conversion, serial interface, 53 I/O lines, 48 internal registers plus optional internal RAM and ROM. The TMP90C841 (ROM-less '840), with external program rom, drives the music in Rapid Hero, which is no longer silent. The TMP91C640 was used in a number of Dynax mahjong games of that era, like Mahjong If (1990) and Mahjong Tensinhai (1995). There are a couple more mahjong games for which the internal rom has been dumped, through an expensive adapter, that I'm now working on, as well as a few bugs to fix before I'm done with this.
- 22nd June      2005: Tomasz Slanina - Working again on TLCS-90 core.
- NOTES: The Toshiba TLCS-90 is similar to the Z80 but with different opcodes - not emulated.
- SOURCE: cpu\tlcs90\tlcs90.c


13.61  TMP90841
- 0.111u1            : Luca Elia added new Toshiba TMP90840/TMP91640 CPU core.
- SOURCE: cpu\tlcs90\tlcs90.c
- PCB: TMP90C841, SDIP64 (Raphero, Cafedoll)


13.62  TMP91C640
- 0.111u1            : Luca Elia added new Toshiba TMP90840/TMP91640 CPU core.
-  3rd December  2006: Luca Elia - I've emulated the TMP90C840/TMP91C640 microcontrollers, some of the few CPU's still unsupported in MAME. They belong to the TLCS-90 family, introduced by Toshiba in the early nineties, the ancestor of the TLCS-900 that powers the Neo Geo Pocket. This 8-bit CPU is essentially a Z80 on steroids: different binary encoding, 20 bit address bus, more opcodes and addressing modes, interrupt controller, 6 timers, A/D conversion, serial interface, 53 I/O lines, 48 internal registers plus optional internal RAM and ROM. The TMP90C841 (ROM-less '840), with external program rom, drives the music in Rapid Hero, which is no longer silent. The TMP91C640 was used in a number of Dynax mahjong games of that era, like Mahjong If (1990) and Mahjong Tensinhai (1995). There are a couple more mahjong games for which the internal rom has been dumped, through an expensive adapter, that I'm now working on, as well as a few bugs to fix before I'm done with this.
- 16th July      2005: Luca Elia - Mahjong Chuukanejyo is the first game dumped from the box that bnathan sent to Guru. A 1998 Mahjong game by Dynax, running on ddenlovr.c hardware. The CPU is a Z80. Most games from that box use a currently unemulated Toshiba processor (TMP91P640N) instead.
- SOURCE: cpu\tlcs90\tlcs90.c
- PCB: TMP91P640N-10 running at 10.7375MHz (Mahjong Tenkaigen - Dynax 1991), TMP91C640N




14.    KONAMI

- 0.101u4            : Aaron Giles updated the KONAMI disassembler to new format.
- 23rd October   1999: Juergen Buchmueller did some Konami CPU fixes.
- 0.36b4             : Ernesto Corvi fixed a Konami CPU bug which caused problems with Parodius' dancer level.
- 12th August    1999: Ernesto Corvi added more addressing modes to the Konami CPU.
- 11th August    1999: Nicola sent in a driver for Parodius, and added two new opcodes to the Konami CPU (needed for Parodius).
- 0.36b2             : Konami 052001/053248 CPU emulation, used by many games [Ernesto Corvi, Manuel Abadia].
- NOTES: The KONAMI CPU based on the M6809 cpu core.
- GAMES: Konami - Ajax (1987), Thunder Cross (1988), Gang Busters (1988)
- PCB: 053248 CPU (Parodius,Surpratk), 52001 CPU (88games), 052526 (Blockhl)



15.    MIPS CPUs

- 0.124u4            : Aaron Giles inverted the sense of the memory mask that is passed to read/write handlers. Previously, the mask indicated which bits were NOT requested to be read/written. Now, the mask indicates which bits ARE to be read/written, which is more logical. Updated a number of drivers and the MIPS CPU cores to comply.
- 0.122u5            : Aaron Giles fixed bug where the 64-bit DRC was not saving rbp.
- 0.119u2            : Added cpu\drcfe.c. Aaron Giles fixed MIPS3 disassembly of j/jal instructions.
- 0.119u1            : Added cpu\mips\mdrc64.c and cpu\mips\mips3fe.c/h. 
- 0.118u6            : Aaron Giles made a cleanup pass through the new x86emit.h code emitters, changing the way memory is referenced and replacing macros with inline functions. Updated MIPS and PowerPC drc cores to use the new emitters. Removed the old macro-based ones in x86drc.h.
- 0.118u4            : Aaron Giles added new functions to the memory system to support CPU cores explicitly specifying the access mask on 32-bit and 64-bit data bus systems. This enables the MIPS core to handle SWL/SWR and SDL/SDR without a read/modify/write cycle. Updated the C and DRC MIPS cores to use this new mechanism. Aaron Giles fixed recently introduced bug in the mips3 core that caused the C core to launch off into nowhere after the first instruction. 
- 0.118u3            : Added cpu\mips\mips3com.c. Aaron Giles consolidated common code between drc and non-drc MIPS cores.
- 0.114u4            : Vas Crabb updated the MIPS3 DRC to align the stack to sixteen-byte boundaries at the point of calls, as required by Mac OS X calling conventions. It doesn't break compatibility with Windows or Linux calling conventions. This fixes crashes in MIPS3 games when running on OS X for Intel.
- 0.104u4            : R. Belmont hooked up the R4650 properly in the MIPS recompiler.
- 0.104u3            : R. Belmont and Aaron Giles added support for IDT-specific MIPS MUL instruction in the MIPS3 core, recompiler and disassembler.
- 0.102u5            : Aaron Giles fixed subtle bug in the MIPS3 recompiler that prevented Tenth Degree from working.
- 21st December  2005: Aaron Giles - Figure out why Tenth Degree no longer worked. It used to, and I was sure it was due to the Voodoo rewrite. I spent quite a bit of time looking into that, assuming I was returning an incorrect value from the status register or something. Turns out I was completely wrong. Instead, an "optimization" I had made to the MIPS dynarec core a while back had a subtle side effect. The problem was literally with the particular opcode: slti r2,r3,$1. In the old dynarec core, that was translated as: mov eax,[r3.lo]; mov edx,[r3.hi]; sub eax,1; sbb edx,0; shr edx,31; mov [r2.hi],0 and mov [r2.lo],edx. The optimization I added was to convert code that subtracted 1 from a register to use the dec opcode instead, since it is more compact. So the new code was: mov eax,[r3.lo]; mov edx,[r3.hi]; dec eax; sbb edx,0; shr edx,31; mov [r2.hi],0 and mov [r2.lo],edx. Which is 4 bytes smaller, taking up less instruction/trace cache space. Multiply this over a lot of generated code and it has an impact. The problem is that dec eax is not quite the same as sub eax,1. Specifically, dec does not set the carry flag, meaning that the sbb instruction that followed would never "borrow" from the high word, messing up the math. So with that, Tenth Degree is working again, and better than ever. One thing I discovered in my recent research is that if certain values (red, green, blue, alpha, Z, and W) overflow during triangle rasterization, they are allowed to wrap in a slightly odd fashion. For example, if the red component increases from $FF to $100 to $101 over the course of several pixels, you would expect it to wrap from $FF to $00 to $01. But the internal microcode in the Voodoo actually checks explicitly for $100 and clamps it to $FF, while allowing $101 to wrap to $01. So what you actually get is a transition from $FF to $FF to $01. Why is this important? Well, let's say you are drawing a triangle such that the leftmost pixel has a red value of 0.0 and the rightmost pixel has a red value of 1.0. Converting these values to integers between 0-255 means the left value is $00 and the right value is $100. If the Voodoo allowed simple wrapping, that last pixel would be drawn as $00, showing up as an ugly black pixel right next to a bright red one. The simple clamping logic allows for a bit of slop of 1 on either the high or low side without producing artifacts. The upshot is that if you run an old build of MAME and look at Tenth Degree, you'll see lots of artifacts - unsightly black or white pixels that shouldn't be there. Implementing this clamping logic turns out to fix these problems. Mace: The Dark Age also suffered from the same problem to a lesser degree. I bet the Tenth Degree engine was based off of the Mace engine.
- 0.102              : Aaron Giles fixed handling of the FR bit in the Status register on MIPS3. This fixes a few problems in CarnEvil, and probably affects a few other games as well. Also fixed bug where TLB exceptions were not filling in the Context and EntryHi registers correctly.
- 0.101u4            : R. Belmont added missing SC/LL opcodes to the MIPS3 interpreter. smf updated dismips to handle the new disassemblers.
- 0.101u3            : Aaron Giles added MMU support to the MIPS3 dynamic recompiler. Re-enabled it by default. Added direct fast RAM access to the dynamic recompiler, as well as optional hotspot optimizations. Most games should show a net speedup over the pre-MMU compiler.
- 0.101u2            : Aaron Giles added MMU support to the non-drc MIPS3 emulator. Converted the Killer Instinct, Seattle, Vegas, and Hyper Neo-Geo 64 drivers to a proper physical memory layout. Disabled the drc MIPS3 core until MMU support is added there as well.
- 0.96u3             : Nathan Woods added better debugging support to the MIPS core.
- 0.96u2             : Nathan Woods modified the MIPS DRC core to disable optimizations when mame_debug is on. This makes it easier to run comparative traces when running both with and without MIPS DRC enabled (cpu\mips\mdrcold.c).
- 0.84u3             : Aaron Giles fixed crash in the MIPS core introduced with the 0.84u2 changes.
- 0.82u2             : Added cpu\mips\mdrcold.c. Aaron Giles added support for the Config register and for new variants: R4700, QED5271, RM7000 and fixed bug in LWXC1/LDXC1/SWXC1/SDXC1 instructions and extracted core codegen portion into new #include file mdrcold.c (mips3drc.c).
-  8th May       2004: Aaron Giles - So I spent about half the week trying to rewrite the MIPS recompiler from scratch, and then remembered what an awful lot of work it was. So I went back to the existing one, which works, and decided to start applying most of the optimizations there. The final result won't be as substantially faster as I would have liked, but I hope I can get a good chunk of the speedups in. So far so good on about half of them, but the most recent one (register allocation of floating point registers and using SSE math throughout) is causing me fits like the off-kilter NFL Blitz image. The games boot now, but their geometry is seriously screwed.
- 28th April     2004: Aaron Giles - I have about 1/4 of the instructions rewritten, as well as the core control flow analysis. I still need to finish up the instructions, write the final register allocator, and then get it working, so I think it will be a few weeks before I have anything to show for it. I'm currently guessing it will be about 2x as efficient as the old one. I'm also restructuring it a bit so that it will be possible to add an x86-64 backend eventually.
- 28th February  2004: Aaron Giles - MIPS recompiler rewrite: I have about 1/4 of the instructions rewritten, as well as the core control flow analysis. I still need to finish up the instructions, write the final register allocator, and then get it working, so I think it will be a few weeks before I have anything to show for it. I'm currently guessing it will be about 2x as efficient as the old one. I'm also restructuring it a bit so that it will be possible to add an x86-64 backend eventually.
- 0.81u6             : MIPS software interrupt fix [Aaron Giles].
- 0.81u5             : Aaron Giles fixed MIPS core interrupt, added MIPS core MIPS3DRC_FLUSH_PC option for accurate PC handling when debugging and fixed MIPS bug when directly accessing 2-byte values in big endian mode.
- 12th April     2004: Aaron Giles fixed a bug in the MIPS CPU core where software interrupts were masked by the global IE flag.
- 0.79u2             : Removed cpu\mips\dismips32.mak.
- 19th February  2004: smf fixed the standalone MIPS disassembler.
- 0.78               : Aaron Giles fixed handling of condition codes so they are stored in CCR31 now and handling of CCR31 so that rounding modes are set correctly (in the DRC only) (cpu\mips\mipsdasm.c).
- 0.76u2             : Aaron Giles fixed MIPS3DRC FP rounding glitches and now actually respecting the global FP rounding mode.
- 0.76u1             : Changed cpu\mips\mips.c to psx.c
- 0.75               : Replaced instances of "inline", "static inline", and "static __inline" with "INLINE". This fixes some build problems with xmame and makes things more consistent [Lawrence Gold].
- 0.72u1             : Nathan Woods removed use of the GCC specific varargs on macros feature in mips.c
- 0.71               : Added cpu\mips\dismips.mak.
- 0.69a              : Few tweaks/minor optimizations to MIPS3 Dynacrec [Aaron Giles].
- 0.67               : Added cpu\mips\mips3drc.c.
- 0.63               : Added cpu\mips\mips3.c and \mips3dsm.c. IPS III/IV CPU cores [Aaron Giles].
-  8th December  2002: Aaron Giles added CPU cores for MIPS III/IV architectures
- 0.37b3             : Preliminary MIPS CPU emulation [smf].
- NOTES: The only type of processor currently emulated is the one from the PSX. This is a custom r3000a by LSI Logic with a geometry transform engine, no mmu & disabled data cache.
- SOURCE: cpu\mips\mips3.c
- GAMES: Killer Instinct/2 - R4600 (little)




15.1   x64 dynamic recompiler

- 0.119u4            : Aaron Giles fixed 64-bit DRC bug that broke kinst in the previous release. Aaron Giles added code to detect potential hotspots in the 64-bit DRC. Added hotspots to all the seattle.c games and several of the vegas.c games.
- 0.119u3            : Aaron Giles fixed several more bugs in the 64-bit MIPS recompiler. It is now capable of running the Seattle games and the 3D Gauntlets. 
- 0.119u2            : Aaron Giles switched MIPS3 64-bit DRC over to new system that is more aggressive about register allocation and mapping. Sadly, there is little to no obvious performance benefit, but the resulting code is better organized. Aaron Giles created new generic x86/x64 logging system x86log, and updated both MIPS3 DRC cores to use it. Aaron Giles created new generic DRC frontend management. Future work involves retooling the MIPS3 frontend around this new architecture.
- 0.119u1            : Added cpu\x64drc.c. Aaron Giles added preliminary attempt at a new x64 dynamic recompiler for the MIPS 3/4 CPUs. The current version works enough to run a few basic games (kinst, carnevil), but many others fail. Furthermore, this version is already being supplanted by a more advanced version that does register allocation and constant folding. For now it is disabled by default.
- SOURCE: cpu\x64drc.c



15.2   x86 dynamic recompiler

- 0.125              : Aaron Giles added xchg and a few other missing opcodes to x86emit.h.
- 0.120u3            : Vas Crabb cleaned up the inline assembly for both x86 and PPC, enabled the mul32 family assembly stuff on 32-bit x86, and fixed some compiler warnings on 64-bit GCC. In addition: * Provided single-precision reciprocal approximation code for PowerPC and x86 with SSE2. * Filled in all other TBD functions in eigccx86.h for completeness. * Conditionalised some code in eigccppc.h so that it isn't used when the compiler has 64-bit instructions available.
- 0.120u2            : Added emu\eigccx86.h.
- 0.119u2            : Added cpu\x86log.c. Aaron Giles fixed nasty x86emit bug involving 16-bit opcodes on 64-bit systems. Aaron Giles created new generic x86/x64 logging system x86log, and updated both MIPS3 DRC cores to use it. Aaron Giles created new generic DRC frontend management. Future work involves retooling the MIPS3 frontend around this new architecture.
- 0.119u1            : Aaron Giles fixed several 64-bit errors in the code generators in x86emit.h.
- 0.118u6            : Aaron Giles made a cleanup pass through the new x86emit.h code emitters, changing the way memory is referenced and replacing macros with inline functions.
- 0.118u5            : Aaron Giles added more opcode emitters to x86emit.h.
- 0.118u4            : Added cpu\x86emit.h. Aaron Giles updated the x86 drc helper code to support externally-allocated cache. Also added support for allocating data structures out of the cache. Modified initialization so that it does not immediately generate code but rather waits for a reset to do that. Fixed code generation bug when generating [reg*scale] modrm forms. Aaron Giles added new module x86emit.h which supports dynamic code generation for both x86 and x64 systems. This new system is a far more complete solution, though not all opcodes are defined yet. The interface for this is also cleaner than the previous one defined in x86drc.h. Existing DRC cores are still using the old interface, but the new one is preferred for new development.
- 0.105u5            : Improvements to the x86 drc engine and the Windows blitters [???]: Blitter CPUID features now accessed by drc_x86_get_features() call. Added win_blit_init(), to initialize the blitter. Changes to DRC to support usage for things other than CPU cores. Fixed drc_dasm() so it works once again. Added macros for a number of MMX/SSE instructions. Added a number of MMX/SSE instructions to the i386 disassembler.
- 0.89u5             : Nathan Woods added macros for pushfd() and popfd() to src/x86drc.h.
- 0.84               : Aaron Giles added support for many more instruction forms in x86drc.h.
- 0.82u2             : Aaron Giles fleshed out SSE support, made it optional for recompilers to keep the PC/ICount in registers and made append_verify_code work for sizes > 4.
- 0.81u4             : Aaron Giles fixes the x86 dynamic recompiler for MIPS. Fixes an edge case where a memory access like: lw  r3,$0(r0). Would leave the stack in a funny state and lead to a crash. Instructions of the form: ld   r10,0(r10). Would load the low word into r10 first, and then use the modified r10 (plus 4) as the address of the high word. Fixes the sky graphics in several of the kinst2 levels.
- 0.78u1             : Nathan Woods added a few more instruction declarations and a call to retrieve CPU feature flags from CPUID (src/x86drc.c).
- 0.76u2             : Aaron Giles added better support for tweaking the FP rounding modes.
- 0.76u1             : Nathan Woods added a few macros for other miscellaneous X86 opcodes. Added a drc_dasm() call, a debug call that uses MAME's I386 disassembler to disassemble DRC'd code (didn't compile, commented out until fixed).
- 29th May       2003: Aaron Giles did some minor tweaks and optimizations to the MIPS3 dynarec core.
- 0.69               : Andrea Mazzoleni fixes some macros with arguments not used (src/x86drc.h). Otherwise it doesn't compile with gcc 2.95.3.
- 0.67               : Added src\x86drc.c. MIPS 3/4 x86 dynamic recompiling core [Aaron Giles].
- 29th March     2003: Aaron Giles added MIPS 4 (R5000) support to the MIPS 3 (R4600) CPU core and he added dynamic recompiling to both of them.
- SOURCE: cpu\x86drc.c


15.3   R3000
- 0.101u4            : Aaron Giles updated R3000 core to the new disassembler interfaces and to new format.
- 0.78u2             : Changed name 'R3000' to 'R3000__big_'.
- 0.76u2             : Aaron Giles fixed instruction timings for MULT/DIV
- 0.75u1             : Aaron Giles fixed the speedup for R3000 version of Area 51 / Max. Force Duo
- 0.59               : Added cpu\mips\r3000.c
-  3rd March     2002: Aaron Giles fixed a bug in the swl/swr instructions in the R3000 CPU core.
- 0.55               : Added cpu\mips\r3kdasm.c.
- GAMES: Maximum Force (Atari 1996), Vicious Circle (Atari 1996 prototype), Police Trainer (P&P Marketing 1996)
- PCB: IDT 79R3041-25J XB9647P, SDT 79R3041 (Policetr), IDT79R3041 (Sshooter, Maxforce), IDT79R3051-25J 9407C (SuperEagleShot), sdt79r3041 (Area51)

15.31  R3560
- NOTES: Super Real Mahjong P5 uses in MAME the R3000 (big) CPU instead of the R3560.
- PCB: R3560 (Srmp5)


15.4   R4300
- PCB: NEC D30200GD-100 VR4300, QFP120 (NeoGeoHyper64), CPU-NUS A (11beat, Mtetrisc)

15.41  R4600
- 0.84u2             : Aaron Giles added support for non-integral clock multipliers in the MIPS3 core.
- 0.78u2             : Changed name 'R4600' to 'R4600__little_' or 'R4600__big_'.
- 0.78               : Aaron Giles fixed handling of condition codes so they are stored in CCR31 now and handling of CCR31 so that rounding modes are set correctly (in the DRC only).
- 16th December  2003: Aaron Giles sent in a small fix to the MIPS3 dynarec core that caused problems in Vegas hardware games.
- GAMES: Killer Instinct (Rare 1994), Killer Instinct 2 (Rare 1994)
- PCB: SDT79R4600-100MS <50MHz (Kinst)


15.42  IDT R4650 (little)
- 0.104u4            : R. Belmont hooked up the R4650 properly in the MIPS recompiler.

15.43  IDT R4650 (big)
- 0.104u4            : R. Belmont hooked up the R4650 properly in the MIPS recompiler.
- PCB: NKK NR4650-167, QFP208 = R4600-based 64bit RISC CPU (Gp500)


15.44  R4700
- 0.82u2             : Aaron Giles added support for the Config register and for new variants: R4700, QED5271, RM7000 and fixed bug in LWXC1/LDXC1/SWXC1/SDXC1 instructions and extracted core codegen portion into new #include file mdrcold.c (mips3drc.c).



15.5   R5000
- 0.78u2             : Changed name 'R5000' to 'R5000__little_' or 'R5000__big_'.
- 19th December  2003: Aaron Giles - Wow, that was a tricky bug. Turns out nobody was ever saving the FPU condition codes in the R5000 core, so if you took an interrupt between a compare and a branch on the result of that compare, you would hose the compare. This led to all kinds of nasty.
- 0.76u2             : Aaron Giles fixed MIPS3 timer handling so we don't set a timer too far in advance and changed timer handling so that the default Compare value doesn't trigger timers, fixed cycle chomping to make sure we don't go over an interrupt boundary, added correct cycle times for MULT/DIV instructions and fixed display of the Count reigster in the debugger. Also added better support for tweaking the X86DRC FP rounding modes.
- 29th March     2003: Aaron Giles added MIPS 4 (R5000) support to the MIPS 3 (R4600) CPU core and he added dynamic recompiling to both of them.
- PCB: IDT 79RV5000 64-bit Processor (Gauntleg)

15.6   RM7000
- 0.82u2             : Aaron Giles added support for the Config register and for new variants: R4700, QED5271, RM7000 and fixed bug in LWXC1/LDXC1/SWXC1/SDXC1 instructions and extracted core codegen portion into new #include file mdrcold.c (mips3drc.c).

15.7   QED5271
- 0.82u2             : Aaron Giles added support for the Config register and for new variants: R4700, QED5271, RM7000 and fixed bug in LWXC1/LDXC1/SWXC1/SDXC1 instructions and extracted core codegen portion into new #include file mdrcold.c (mips3drc.c).
- PCB: RM5271 (Gauntdl)


15.8   PSX CPU

- 0.124u3            : PSX core updates [smf]: Removed casts and removed unnecessary decoding from NCLIP. Added signed values to PAIR & PAIR64. Renamed PAIR64.lw to PAIR64.q. Tidied up DPCS, improved flag calculation and added support for lm/sf fields. Added sf/lm support to INTPL, improved flag calculation & calculates correct RGB. Fixed calculation of bit 31 of GTE FLAG register, when writing to it directly. Added lm mode to OP and fixed the calculation. Added lm mode to SQR.
- 0.124u2            : PSX updates [smf]: Fixed the SR masks for MTC0. Added ability to test the instruction/data cache ram. The scratchpad and BIU register are now handled internally to the CPU. All writes are performed with masks. SWL/SWR used to be implemented with two writes ( one byte and one word ) when writing three bytes, now it only ever performs one. Byte and Word writes use masks as they leave the rest of the register on the bus, which can be picked up by larger registers. The read/write functions to use are cached when the SR bits are updated, as are the bad address masks. Added coprocessor 1 & 3 support, though they don't do anything useful. All loads now go through the delay pipeline, a lwl/lwr will grab the value out of the pipeline if it's updating the same register. Added undocumented behaviour of BLEZ/BGTZ. The comparison for zero can be changed by specifying an alternate register in the RT field ( the documentation says you should always use register 0 ). Restricted to 16 COP0 registers & generate an exception if any of the 5 for the MMU are used. Added BCF/BCT instructions, although I have found no conditions that affect them yet. Generates an exception if any MMU instructions are executed. Sets the CE instruction for all exceptions, not just those involving a coprocessor. The bits of the opcode that specify the coprocessor are grabbed no matter what the instruction. Added TAR register and BT bit in SR. When an exception occurs during a branch, BT determines whether it was taken or not. The TAR register gets set to the destination of the branch. Fixed the BD bit when you are in a branch delay slot and you didn't take the branch, this shows up in the pipeline as !pc. Fixed branches within a branch delay slot. Multiply & divide instructions can be aborted if you write to HI/LO before reading the result. Added data breakpoints, you don't appear to be able to set breakpoints on any of the addresses internal to the CPU. Multiply/divide/GTE instructions can execute when an exception is taken, although the EPC indicates that it hasn't. The BIOS avoids rerunning GTE instructions as they are destructive, so you have to make sure they run. Added bus error handling, PSXCPU is limited to 8mb of ram & any access outside this range will trigger an exception. I believe this is to be an internal limit. Added CXD8661R as a specific CPU type, System 12 appears to allow more than 8mb of ram & it's possible that this is different. Mapped out all instructions to either generate an exception or ignore bits. Updated the disassembler to match the decoding. Fixed disassembling of branch instructions in a branch delay slot. Lui checks for a ori/addiu following and will show you the result. Added step over/out support. Fixed standalone disassembler. Fixed SZ0 truncation. Fixed IRGB truncation and conversion to IR1/IR2/IR3. Added IR1/IR2/IR3 saturation when calculating ORGB.Fixed OTZ sign extension. Fixed reading from SXYP. Fixed reading from IRGB. Fixed writing to LZCR. Fixed sign extension of GTE control registers. Fixed writing to FLAG. Fixed flag calculation in F macro and fixed avsz3 & avsz4 flag & otz calculation.
-  8th April     2008: smf - 1 on 1 Government Revisited: Most of my work recently has been to improve the accuracy of the PlayStation CPU emulation. This hasn't made much of a difference to any games, though if you write your own code and it runs on the emulator then it's more likely to run on the real thing. I've now moved onto writing GTE unit tests, there were a couple of games with geometry issues & I wanted to have some visible sign of progress. This is the result of improving the data transfer between the CPU and the GTE. There are a few GPU issues, but I'll get to them some other time. Someone will need to write a cheat for this though, or explain to me how to beat the computer.
- 0.122u6            : First pass at fixing the CPU clock speeds on the playstation based hardware. The internal divide in the CPU core has been set to 4 as we have no wait states, incorrect DMA timing, no gpu timing, no DMA bus stealing and no gte timing [smf]. Changed PSX CPU clock speed to 67737600 Hz.
- 16th January   2008: smf - The clockspeed of the PSX based games in MAME has always been a little on the low side. Mainly to make up for the lack of cache emulation and bus contention, also partly because the GTE timing isn't emulated yet. Due to the recent attention to crystals, there has been some investigation as to what the real clock speed should be. Thanks to Guru's probing we are able to say for definate what is going on. The CPU has an internal divider and on the majority of boards is fed a 67.7376mhz clock. I have currently got MAME to report this frequency, with an internal divider of 4 to keep it roughly the same as before ( it should be 2 but I'll leave that until the rest of the timing issues are sorted ). Some information has been floating around for a while that has never been confirmed & now seems to be a good time. The 67mhz clock doesn't appear on the namco system 12 or the later system 10 boards. It appears they have their own higher rated part. System 12 runs on a 100mhz clock, while system 10 runs on a 101.4912mhz clock. So system 12 being faster has been elevated from rumour, to probable. The GPU clock is the same across all hardware. I'd have thought they'd have done something about that, especially as all the system 12 games like to run in interlace. Maybe it's more efficient or has faster ram, we'll leave that one for another day.
- 0.110              : smf and Aaron Giles fixed crash when resetting PSX games.
- 25th August 2006   : smf - As Ian guessed the answer for real hardware is 0x1234def0. Currently MAME ignores the byte write completely and gives 0x12345678. This is because when it's testing which half of the register is being accessed, it only considers word or dword writes. That should be easy to sort out, it just needs a different check for the mem_mask. The real problem comes because the program_write_byte_32le call only takes a byte, so there is no way to pass the extra bits. I have coded some alternate memory handlers that allow you to specify a mem_mask value & then the shifting can be handled by the cpu core. This is slower when accessing RAM though as instead of a byte write it's performing a read, two ands, a not and then a write. I could change the data type for program_write_byte_32le, but thats a bit hacky. Passing the mem_mask in would also allow lwl/lwr/swl/swr to be emulated correctly when it's accessing three bytes ( there is no program_write_triple_32lw, yet...). Progress has been stalled after I upgraded to 0.108 to start work on the memory handlers, but then the debug build of mess locked up and the non-debug build displayed the screen in kaleidoscope-vision. I fixed both problems & then found that the lockup was fixed in 0.108u1 when Aaron changed timer.c. So, back to more interesting things...
-  1st August 2006   : smf - Olivier Galibert gets one of the four points, the question was... What are the possible effects? & both b and d are possible. B will occur when ra is in the range 0-7fffffff, the relative branch is affected by being in a branch delay slot (the clue was in the title of the post). Disassembling branch instructions becomes a bit more complex, lets hope nobody ever uses this. (1 point) D will occur when ra is in the range 80000000-ffffffff, which is the most likely as most software runs in kernel space on the PlayStation. (1 point). If an interrupt occurs when the pc is 8001f6e4 then B will happen whatever value ra is as the nop is in the delay slot of the bgez and the PlayStation always subtracts 4 from the PC when restarting after an exception (1 point). Last of all is a bonus point because the bgez instruction encoding is non standard, but the PlayStation ignores the extra bits that are set ( the standard encoding would be ff ff e1 07 ). Nobody else scored a point because the explanation was just as important as picking one of the answers ( or you could have just said a, b, c & d ). If I'd thought about it more I'd have used bgezal ra, I'll try to prepare more next time.
- 0.102u4            : smf fixes branch target address disassembly in the PSX disassembler.
- 0.102              : Olivier Galibert fixed bug in PSX GTE flag settings.
- 0.101u4            : smf updated PSX core to new save state and disassembler interfaces.
- 0.97u3             : Improvements to the PSX CPU core [smf]: Correct behaviour for a branch in a delay slot, added BIOS and syscall logging of all known functions & their parameters (writing to file descriptor 1 or putchar will output to the console), fixed disassembly of gte instructions and dismips.mak
- 0.92               : smf improved root counter emulation and DMA acknowledge emulation. Changes visible area immediately instead of during video update. Added new board notes from Guru and removed 8.3 restrictions on namco system 11 rom names.
- 0.88u4             : smf updated the PSX core to show more registers.
- 0.84u3             : smf fixed the PSX SIO timer so that it only fires when there is data to send & processes one bit per tick.
- 0.84               : smf improved PSX root counters. Darkcoder fixed the Speaker Puncturing Unit in the PSX games. R. Belmont and smf fixed several endian issues in the PSX-related drivers.
- 0.82u1             : smf fixed another PSX SIO bug.
- 0.82               : PSX SIO improvements [smf].
- 26th April     2004: smf sent in an update to the PSX hardware improving the SIO ports.
- 15th April     2004: smf fixed the GPL12 opcode in the PSX GTE which caused problems with the ground graphics in Cool Boarders Arcade Jam.
-  1st March     2004: Carlos Santillan submitted some speedups to the PSX hardware drivers.
- 0.79u3             : Misc PSX cleanups [smf].
- 0.79u1             : Various PSX file updates / cleanups [smf].
- 30th January   2004: smf fixed a few more problems in the PSX driver uncovered by the memory system changes.
- 28th January   2004: Aaron Giles fixed the PSX driver, both broken by the memory system.
- 0.78               : PSX core improvements [smf]. Fixed MVMVA disassembly, SWC bit in SR is ignored, fixed MVMVA with LM bit set, added SQR & CC opcodes, added preliminary looped DMA detection, improved root counter emulation, improved SIO emulation, preliminary PSXSPU emulation, preliminary screen flipping / blanking support, added GPU packet 41, 52 & 77, Supports uploading 1024 pixel wide textures and esetting GPU sets default texture window.
- 0.71               : Added Star Sweep to MAME
- NOTES: The PSXCPU is from Sony Playstation. The PSX hardware are in Namco System 11 and Sony ZN1/ZN2 games. The PSX CPU is a custom r3000a with a built in geometry transform engine, no mmu & no data cache.
- GAMES: Star Sweep (Axela 1997)
- PCB: Sony CXD8530AQ/CXD8530CQ


15.81  CXD8661R
- 0.124u2            : PSX updates [smf]: Added CXD8661R as a specific CPU type, System 12 appears to allow more than 8mb of ram & it's possible that this is different. Fixed the SR masks for MTC0. Added ability to test the instruction/data cache ram. The scratchpad and BIU register are now handled internally to the CPU. All writes are performed with masks. SWL/SWR used to be implemented with two writes ( one byte and one word ) when writing three bytes, now it only ever performs one. Byte and Word writes use masks as they leave the rest of the register on the bus, which can be picked up by larger registers. The read/write functions to use are cached when the SR bits are updated, as are the bad address masks. Added coprocessor 1 & 3 support, though they don't do anything useful. All loads now go through the delay pipeline, a lwl/lwr will grab the value out of the pipeline if it's updating the same register. Added undocumented behaviour of BLEZ/BGTZ. The comparison for zero can be changed by specifying an alternate register in the RT field ( the documentation says you should always use register 0 ). Restricted to 16 COP0 registers & generate an exception if any of the 5 for the MMU are used. Added BCF/BCT instructions, although I have found no conditions that affect them yet. Generates an exception if any MMU instructions are executed. Sets the CE instruction for all exceptions, not just those involving a coprocessor. The bits of the opcode that specify the coprocessor are grabbed no matter what the instruction. Added TAR register and BT bit in SR. When an exception occurs during a branch, BT determines whether it was taken or not. The TAR register gets set to the destination of the branch. Fixed the BD bit when you are in a branch delay slot and you didn't take the branch, this shows up in the pipeline as !pc. Fixed branches within a branch delay slot. Multiply & divide instructions can be aborted if you write to HI/LO before reading the result. Added data breakpoints, you don't appear to be able to set breakpoints on any of the addresses internal to the CPU. Multiply/divide/GTE instructions can execute when an exception is taken, although the EPC indicates that it hasn't. The BIOS avoids rerunning GTE instructions as they are destructive, so you have to make sure they run. Added bus error handling, PSXCPU is limited to 8mb of ram & any access outside this range will trigger an exception. I believe this is to be an internal limit. Mapped out all instructions to either generate an exception or ignore bits. Updated the disassembler to match the decoding. Fixed disassembling of branch instructions in a branch delay slot. Lui checks for a ori/addiu following and will show you the result. Added step over/out support. Fixed standalone disassembler. Fixed SZ0 truncation. Fixed IRGB truncation and conversion to IR1/IR2/IR3. Added IR1/IR2/IR3 saturation when calculating ORGB.Fixed OTZ sign extension. Fixed reading from SXYP. Fixed reading from IRGB. Fixed writing to LZCR. Fixed sign extension of GTE control registers. Fixed writing to FLAG. Fixed flag calculation in F macro and fixed avsz3 & avsz4 flag & otz calculation.
- PCB: SONY CXD8661R L9A0088 WE19960 NNM 9738, QFP208 (Soulclbr, Tektagt)


16.    AMD

16.1   AMD 2901
- NOTES: The Vertigo vector CPU (Exidy Vertigo hardware) consists of four AMD 2901 bit slice processors. The microcode for these CPUs is stored in 13 bipolar proms for a total of 512 52 bit wide micro instructions. The microcode not only crontrols the 2901s but also loading and storing of operands and results, program flow control and vector generation.
- SOURCE: video\vertigo.c
- GAMES: Top Gunner (Exidy 1986)

16.2   AM29000
- 16th May       2004: Philip Bennett - With a reasonable amount of free-time on my hands I've resumed work on the Am29000 core. Most of the instructions are implemented, but it's not quite up to the job yet...
- 30th March     2004: Philip Bennett - Working on F-15 Strike Eagle for the past few weeks. Currently, the 68000 and TMS34010 are hooked up. The game starts with a bit of high kludgery, but without an Am29000 core (a 32-bit RISC CPU responsible for generating the 3D objects) it's far from playable. In addition, an 80C31 MCU core is needed for sound emulation. Battle of the Solar System and Super Tank Attack run on similar hardware, but there's not a lot to show from them at the moment. I've began writing an Am29000 core (it disassembles code at the moment), but with the sheer amount of academic work I'm lumbered with at the moment progress will be slow.
- PCB: AM29000-16, 32bit RISC microprocessor, 4 stage pipeline (Botss, F15se)
- SOURCE: drivers\micro3d.c

16.3   AM29116
- NOTES: http://www.bitsavers.org/pdf/amd/_dataSheets/29116_dataSheet_Mar86.pdf
- PCB: AM29116DC = 16-bit bipolar microprocessor  (Turbosub)

16.4   AM29323
- NOTES: Co-processor for AM29000
- SOURCE: drivers\micro3d.c
- PCB: AM29C323 = 32 x 32bit parallel floating point multiplie (Botss, F15se)





17.    Hyperstone

- 0.122u3            : Pierpaolo Prazzoli fixed typo for IO1 irq callback in hyperstone core.
- 0.121u1            : Aaron Giles optimized the hyperstone core, gaining ~50% speed improvement in most games. Implemented clock prescaling and corrected interrupt priority handling. Then fixed the clock speeds on the most of the games and killed most of the speed gains in quite a number of them (Sorry!).
- 0.114              : David Haywood avoided a memset in the hyperstone core to give ~4% speedup in Hidden Catch.
- 0.109u5            : Aaron Giles converted the e132xs disassemblers to the new format and added step in/out support where it was obvious.
- 0.104u3            : Pierpaolo Prazzoli fixed typo in Hyperstone core that led to false positive warning popups.
- 0.103u5            : Updates to the Hyperstone core [Pierpaolo Prazzoli]: Removed nested delays. Added better delay branch support. Fixed PC seen by a delay instruction, because a delay instruction should use the delayed PC (thus allowing the execution of software opcodes too).
- 0.103u4            : Fixes to the Hyperstone core [Pierpaolo Prazzoli]: Removed nested delays. Don't allow software opcodes to be executed in a delay slot.
- 30th January   2006: Working hard on Eolith games. This time I could make Hidden Catch - (c)1998 Eolith to work. It suffered from a nasty bug in the Hyperstone cpu core, because it used a memory instruction which reads data from the memory address stored in the source register, writes the data read in the destination register and then increments the source register by 4, but... if source and destination registers are the same? Well, it only incremented the register instead of reading the data from memory without incrementing it. This is strange because they could have used a normal instruction which does the same but doesn't increment the source register, but anyway... probably the compiler was a bit crap.
- 0.92               : Pierpaolo Prazzoli fixed Hyperstone Iram mirroring and Tomasz Slanina improved the Hyperstone based drivers.
- 0.90               : Pierpaolo Prazzoli fixed timer and removed the hack. Tomasz Slanina fixed delayed branching for delay instructions longer than 2 bytes.
-  1st January   2005: Tomasz Slanina - Fixed nasty bug in hyperstone core and made few changes to dgPix driver - X-files (or rather 'xxx-files') partially works, but is not playable.
- 0.89u1             : Workaround for excessive RAM use in Hyperstone based games [Pierpaolo Prazzoli].
- 0.88u5             : Brad Oliver fixed Hyperstone compile errors.
- 0.88u4             : Pierpaolo Prazzoli added other Hyperstone models to the core.
- 0.88u3             : Tomasz Slanina fixed addc, subc, mulu and muls opcodes in the Hyperstone core. This fixes title screen objects in Super Lup Lup Puzzle and bullets in Mission Craft. Pierpaolo Prazzoli fixed software opcodes when used as delay instructions and added nested delays.
- 0.88u2             : Some hyperstone debugger cleanups [Pierpaolo Prazzoli].
- 0.87u1             : Pierpaolo Prazzoli fixed the I/O addresses in Hyperstone and so removed the hack from vamphalf driver.
- 0.87               : Tomasz Slanina added "undefined" C flag to shift left instructions. Pierpaolo Prazzoli added interrupts-block for delay instructions, fixed get_emu_code_addr, added LDW.S and STW.S instructions and fixed floating point opcodes.
- 17th September     : Kale - Made some improvements to the Hyperstone driver and Vamp 1/2 is 'playable', but has a large number of graphical glitches and locks up after a short time of playing.
- 0.86               : Hyperstone CPU Core improvements [Tomasz Slanina, Pierpaolo Prazzoli]. Tomasz Slanina: Interrupts after call and before frame are prohibited now, emulation of FCR register, Floating point opcodes (preliminary), fixed stack addressing in RET/FRAME opcodes, fixed bug in SET_RS macro, fixed bug in return opcode (S flag), added C/N flags calculation in add/adc/addi/adds/addsi and some shift opcodes, added writeback to ROL, fixed ROL/SAR/SARD/SHR/SHRD/SHL/SHLD opcode decoding (Local/Global regs), fixed I and T flag in RET opcode, fixed XX/XM opcodes, fixed MOV opcode, when RD = PC, fixed execute_trap(), fixed ST opcodes, when when RS = SR, added interrupts and fixed I/O addressing. Pierpaolo Prazzoli fixed fetch, fixed decode of e132xs_xm opcode, fixed 7 bits difference number in FRAME / RET instructions, some debbugger fixes, added generic registers decode function and some other little fixes.
-  7th July      2004: Tomasz Slanina - Fixing bugs in Hyperstone core.
- 0.81u6             : Pierpaolo Prazzoli added h flag handling in the DASM, fixed wrong interpretation of some opcode bits in the DASM, fixed Frame instruction when d-code was 0 and always set the new entry table.
- 0.81u4             : Pierpaolo Prazzoli added addressing of next byte if in load / store instructions using Displacement Address Mode PC is used as register destination. Added local registers wrap around modulo 64. Added trap instructions to the dasm. Added some debug info when high global registers are written. Fixed some wrong format in the dasm. Changed reset to act as an exception, as the doc claims (before it crashed if reset was used as an exception).
- 0.81u1             : Pierpaolo Prazzoli fixed another Hyperstone bug.
-  1st April     2004: Pierpaolo Prazzoli sent in another small fix to the Hyperstone CPU core, fixing a bug where some instructions could have used a wrong value for the PC.
- 31st March     2004: Pierpaolo Prazzoli fixed the display of branch addresses in the Hyperstone CPU core.
- 29th March     2004: MooglyGuy fixed the immediate and const values in the Hyperstone CPU core.
- 10th March     2004: Pierpaolo Prazzoli cleaned up the register get/set functions in the Hyperstone CPU core.
- 0.80               : Pierpaolo Prazzoli made various Hyperstone core improvements.
- 28th February  2004: Pierpaolo Prazzoli sent in some fixes to the Hyperstone CPU core.
- 0.76u2             : Some Hyperstone fixes/improvements [Mooglyguy, Pierpaolo Prazzoli].
- 26th October   2003: Pierpaolo Prazzoli and MooglyGuy fixed some problems in the Hyperstone CPU core.
- 0.72u2             : Preliminary Hyperstone Core, not yet working well enough to run anything [Pierpaolo Prazzoli].
- 16th August    2003: Pierpaolo Prazzoli did some fixes to the Hyperstone CPU core.
- 14th August    2003: Pierpaolo Prazzoli sent in a very preliminary Hyperstone CPU core.


17.1   E1-16T
- NOTES: 16bit Hyperstone model. MAME emulates the E1-16T, E1-16XT, E1-16XS and E1-16XSR
- SOURCE: cpu\e132xs\e132xs.c
- GAMES: Cool Mini, Super Lup Lup Puzzle (1999) and Vamp 1/2 (1999)

17.2   E1-32N
- 0.72u2             : Added cpu\e132xs\e132xs.c and cpu\e132xs\32xsdasm.c,
- NOTES: 32bit Hyperstone model
- SOURCE: cpu\e132xs\e132xs.c
- GAMES: Hidden Catch, Land Breaker and Raccoon World


17.3   E1-32XT

- NOTES: 32bit Hyperstone model. The MAME E1-32XS cpu emulator is compatible with: E1-32, E1-16, E1-32X, E1-16X, E1-32XN, E1-32XT, E1-16XT, E1-32XS, E1-16XS, E1-32XP (ever released?), E1-32XSB (compatible?), E1-16XSB (compatible?)
- SOURCE: cpu\e132xs\e132xs.c
- GAMES: X-Files (dgPix 1999), Racoon World (Eolith) and others
- PCB: Hyperstone E1-32XN (Mosaicf2)


17.4   GMS30C2116
- NOTES: 16bit Hynix model
- SOURCE: cpu\e132xs\e132xs.c
- PCB: GMS 30C2116 based on Hyperstone technology (Misncrft)

17.5   GMS30C2216
- NOTES: 16bit Hynix model
- SOURCE: cpu\e132xs\e132xs.c

17.6   GMS30C2132
- 18th February 2007: Pierpaolo Prazzoli - Added a new driver for Crazy War (Eolith 2002).
- NOTES: 32bit Hynix model
- GAMES: Crazy War (Eolith 2002)
- SOURCE: cpu\e132xs\e132xs.c

17.7   GMS30C2232
- NOTES: 32bit Hynix model
- SOURCE: cpu\e132xs\e132xs.c
- PCB: Hyundia GMS30C2232 (Spotty)




18.    Fujitsu

18.1   MB86233

- 0.119u4          : El Semi added the repeat count register (reg 0x34) access and immediate value load to the MB86233 core (needed by Pilot Kids).
- 0.119u1          : Synchronized the MB86233 core with ElSemi's, fixing a few bugs along the way [Ernesto Corvi].
- 0.119            : Aaron Giles fixed recent changes to the MB86233 core that broke Virtua Racing.
- 0.118u6          : MB86233 core changes [ElSemi]: Fixed a double move opcode and added a previously unknown double move opcode.
- 0.113u4          : Ernesto Corvi and ElSemi added more recently discovered opcodes to the MB86233 core and disassembler.
- 0.113u3          : Ernesto Corvi added a preliminary MB86233 CPU core. Still needs to be hooked up to the Sega Model 2 driver.
- 12th October 2005: Charles MacDonald - I acquired a Virtua Fighter boardset a while ago and am tracing out the board connections to figure out how everything works. Eventually I'd like to get my own code running on the system to investigate TGP functions and to document the Model 1 hardware, but in the meantime just figuring out the organization of everything is important. I ended up removing the V60 from a spare System 32 board to figure out the pin assignments for the QFP-variety V60 within a reasonable time frame, necessary for Model 1 work. The board is still functional, just needs a CPU now.
- NOTES: The Fujitsu TGP chip MB86233 is a coprocessor (aparently part of the Sparc/SparcLite family of processors) and is used extensively to create the 3D objects. It's a 32-bit Co-Processors and supports Floating Point, Stem Rotate, and 3D Matrix operations. Capable of 16 MFlops.
- GAMES: SEGA Model 1, 2 & 2A
- SOURCE: cpu\mb86233\mb86233.c
- PCB: 315-5571 and 315-5572 (Model1)


18.2   MB86235

-  7th October 2004: R. Belmont - src/cpu/mb86235 almost compiles now (it's down to 1 screen full of errors, from several dozen earlier today). I realize that's not real exciting, but emulation's like that sometimes.
- NOTES: Is the Fujitsu MB86235 like the MB86233 a coprocessor?
- GAMES: Behind Enemy Lines (Sega 1998)




19.    IBM

19.1   PowerPC 4xx/6xx

- 0.121u3            : Ville Linde added PowerPC 604 processor support. Moved PowerPC opcode tables to the CPU context to allow multiple simultaneous processors with different opcode tables.
- 0.120u3            : Vas Crabb cleaned up the inline assembly for both x86 and PPC, enabled the mul32 family assembly stuff on 32-bit x86, and fixed some compiler warnings on 64-bit GCC. In addition: * Provided single-precision reciprocal approximation code for PowerPC and x86 with SSE2. * Filled in all other TBD functions in eigccx86.h for completeness. * Conditionalised some code in eigccppc.h so that it isn't used when the compiler has 64-bit instructions available.
- 0.120u2            : Added emu\eigccppc.h.
- 0.118u6            : Aaron Giles made a cleanup pass through the new x86emit.h code emitters, changing the way memory is referenced and replacing macros with inline functions. Updated MIPS and PowerPC drc cores to use the new emitters. Removed the old macro-based ones in x86drc.h.
- 0.115u1            : Ville Linde added lswx and stswx opcodes to the PowerPC core.
- 0.114u3            : Made the PowerPC dynarec options runtime configurable [Ville Linde],
- 0.112u1            : Ville Linde added support for the Motorola MPC8240 to the PowerPC core.
- 0.101u3            : Nathan Woods updated PowerPC core to use new disassembler style.
- 0.99u3             : Ville Linde fixed PowerPC recompiler so that Scud Race works again.
- 0.98u2             : More PowerPC updates [Nathan Woods]: Moved update_counters() to be executed after the DRC epilogue code is appended; now behaves more like the non-DRC core. Fixed some bugs in DRC exeception handling (SRR1 was not being set up properly, and not all MSR flags were being cleared). Refactored DRC core to call MMU hooks. ISI exceptions will now be thrown if the MMU hooks report an unexecutable address in the DRC core. Fixed a rounding error in the decrementer. Added support for decrementer exceptions when the DEC register is written to in both cores. Added support for ISI/DSI exceptions with setjmp()/longjmp() in the non-DRC core.
- 0.98u1             : Nathan Woods added infrastructure to generate DSI and ISI exceptions, made the lbz/lbzu/lbzux/lbzx instructions properly clear out the high 24 bits in the results and added SRR0 and SRR1 to the debug view.
- 0.97u4             : Added cpu\powerpc\ppc_mem.c. More PowerPC improvements [Nathan Woods]: Fixed exception handling; previously the MSR register was stored in EDX, and EDX is not preserved across the call to ppc_set_msr(). Implemented recompile_fcmpo(). Fixed certain rules in rules.mak (some said drc_ops.h instead of drc_ops.c). Commented the MSR_* values. Moved BAT registers into their own structure. Added DSI and ISI exceptions (non-DRC core only for now). Moved READ*/WRITE* functions into ppc_mem.c. Changed memory handling so that reading and writing are done through function pointers that can be changed at runtime (which would be useful if, say a MMU was implemented in the future). Ville Linde made another fix to the PowerPC counters, reimplementing them from scratch.
- 0.97u3             : Improvements to the PowerPC cores [Ville Linde]: Rewrote the interrupt handling in the interpreter core so it matches the DRC core, fixed MCRXR instruction and some timebase problems, so LeMans 24 is now working. Nathan Wood made the DRC PowerPC core compilable when HAS_PPC403 is 0.
- 0.97u2             : Nathan Woods implemented the MCRXR instruction in the PowerPC core and fixed usage of change_pc().
- 0.97u1             : Ville Linde made additional progress on the PowerPC DRC (faster), support for more exceptions, better support for the PPC internal serial ports. Nathan Woods added debugger support for the decrementer register in the PowerPC core.
- 0.96u4             : Nathan Woods implemented in the PowerPC core the SMI input line and added a placeholder for the TLBISYNC input line (doesn't do anything yet).
- 0.96u2             : Nathan Woods patched the non-DRC PPC core to compile properly when not all PPC cores (403, 602, 603) are enabled. Implemented fcmpo instruction.
- 0.96u1             : Added cpu\powerpc\ppcdrc.c + drc_ops.c. Ville Linde added dynamic recompiler for PowerPC cores. Brad Oliver fixed big endian issues in the PPC core.
- 0.91u1             : PPC compiler fixes [Lawrence Gold]: Trailing comma at the end of an enum.
- 0.90u3             : Lawrence Gold fixed some PPC core compiler warnings.
- 0.86               : Added IBM/Motorola PowerPC 4xx/6xx emulator [Ville Linde, Bart Trzynadlowski, Stefano Teso].
- SOURCE: cpu\powerpc\ppc.c


19.11  PPC403
- 0.110u1            : Ville Linde added support for Fixed Interval Timer to the PPC403 core.
- 0.86               : PowerPC 403 core [Ville Linde, Bart Trzynadlowski, Stefano Teso]. This is basically SuperModel (Sega Model 3 emu)'s PPC core minus the FPU and 6xx-series specific instructions (that stuff isn't ported to MAME yet). As such, it's passed all manner of synthetic PPC torture tests and should be quite reliable for any PPC403-based hardware.
- 21st August    2004: Ville Linde - Submitted a MAME version of SuperModel's PowerPC core plus the WIP Konami PPC drivers.
- NOTES: Originally written by Bart Trzynadlowski for Supermodel project. PowerPC 403 opcodes and MAME conversion by Ville Linde.
- SOURCE: cpu\powerpc\ppc403.c (IBM/Motorola PowerPC 4xx/6xx emulator)
- PCB: IBM PowerPC 403GA (Gticlub), PPC403GA-JC33C1 (Gradius4, Sscope/2)


19.12  PPC601
- 0.118u5            : Ville Linde added support for the PowerPC 601.
- SOURCE: cpu\powerpc\ppc.c


19.13  PPC602
- 0.107u1            : Ville Linde added some PPC602 specific opcodes and registers.
- 0.91               : Added cpu\powerpc\ppc602.c. Improvements to PPC core / Model 3 driver [Ville Linde]. Some step 2.0 games now show something.
- 0.90u2             : Support for PPC602 [Ville Linde].
- SOURCE: cpu\powerpc\ppc602.c
- PCB: EMPPC602FB66 (Heatof11), IBM POWERPC 602 (Heatof11)


19.14  PPC603
- 0.97u3             : Ville Linde did another overhaul on the PPC603 counters (timebase should increment once every four core clock cycles and decrementer should decrement once every four bus cycles).
- 0.96u4             : Nathan Woods implemented the TBU special variable on the 603.
- 0.90u2             : Model 3 Update [Ville Linde]. Better interrupt handling. Nested interrupts work properly. Major bugfixes. Added some unimplemented opcodes.
- 12th December  2004: Ville Linde - Fixed a ton of bugs in the PPC603 core and fixed the EEPROM among other things. Scud Race now runs normally through the attract mode (without 3D graphics of course).
- 0.89u4             : Additional 64-bit integer related cleanups in model3/ppc [Lawrence Gold].
- 0.89u3             : Ville Linde major bugfixes to the PPC603 emulation, especially the FPU. Lawrence Gold fixed some compiler related issues with >32-bit integers in PPC / Model 3.
- 0.89u1             : PPC core improvements (603 support) for Sega Model 3 [Ville Linde].
- 25th November  2004: R. Belmont - Added with Andrew Gardiner and Ville Linde the 64-bit PowerPC 603 core and a skeleton Sega Model 3 driver (no video emulation, most games barely boot).
- SOURCE: cpu\powerpc\ppc603.c
- PCB: PowerPC603ev, QFP240  HEATSINKED (Harley)


19.15  PPC604
- 0.121u3            : Ville Linde added PowerPC 604 processor support. Moved PowerPC opcode tables to the CPU context to allow multiple simultaneous processors with different opcode tables.
- SOURCE: cpu\powerpc\ppc.c


19.16  Konami PowerPC based 3D games
- 0.124              : R. Belmont got most of the Konami PPC games running again.
- 0.114u2            : Ville Linde removed all the timing kludges from machine/konppc.c. GTI Club is kind of playable now. You can finish a lap or two, but eventually it will hang on network error. 
-  7th December  2005: Ville Linde - I'm slowly starting to understand how the custom Konami 3D chipset works. Now I'm getting some simple polygon stuff showing, the most complex one being the Konami logo in Operation Thunder Hurricane.
- 0.102              : Many fixes to the Konami PPC drivers [Ville Linde].
- 0.97u2             : Improvements to the Konami PPC games [Ville Linde]: Fixed Gradius 4 data ROM mapping, PPC/SHARC communications, NVRAM protection on some games and stubbed out LAN interface.
- 0.97u1             : Progress on the Konami PowerPC drivers [Ville Linde]. Cleaned up and consolidated common hardware. Hooked up ADSP-21062 and 3dfx chips. Initial reverse-engineering work on the K001005 custom 3D chipset in GTI Club. Initial NVRAM values plugged in for many games (they're used as a crude protection, similar to the EEPROM on GV System). No games are playable or even show much yet, but nearly all of them do pass POST now.
- 21st August    2004: Ville Linde - Submitted a MAME version of SuperModel's PowerPC core plus the WIP Konami PPC drivers.
- GAMES: GTI Club (Konami 1996), Konami ZR107 System, Konami NWK-TR System and Konami Hornet System
- SOURCE: machine\konppc.c


19.17  PowerPC MMU
- 0.123u5            : Nathan Woods changed how the PowerPC MMU is enabled at compile time, to cut down on the amount of unused functions in MAME.
- 0.103u1            : Nathan Woods added PowerPC MMU code, but enabled only for MESS due to breakage of the Model 3 games.
- 0.97u5             : Nathan Woods added hooks to support a future MMU in the PowerPC core.


19.18  PowerPC FPU
- 0.105u2            : Ville Linde fixed floating point rounding error in the PowerPC FPU.
- 0.89u3             : Ville Linde major bugfixes to the PPC603 emulation, especially the FPU. Lawrence Gold fixed some compiler related issues with >32-bit integers in PPC / Model 3.




20.    SE3208
- 0.109u5            : Aaron Giles converted the se3208 disassemblers to the new format and added step in/out support where it was obvious.
- 0.103              : Brad Oliver fixed several endian issues with the SE3208 core and the Crystal System driver.
- 0.90               : SE3208 CPU core emulation [ElSemi].
- NOTES: The CRYSTAL SYSTEM using a VRender0 System on a Chip. The chip contains: CPU Core SE3208 (info at www.adc.co.kr) @ 43Mhz, 2 DMA chans, 4 Timers, 32 PIO pins, PWM output, 32 channels wavetable synth (8bit linear, 16bit linear and 8bit ulaw sample format) and Custom 2D video rendering device (texture mapping, alphablend, roz)
- GAMES: The Crystal of Kings (Brezzasoft 2001), Evolution Soccer (Evoga 2001)
- SOURCE: cpu\se3208\se3208.c



21.    Others

21.1   APEXC
- 0.111u2            : Added APE(X)C CPU emulation [Raphael Nabet]
- 0.37b14            : Removed cpu\apexc\apexc.c and apexcdsm.c.
- 0.37b13            : Added cpu\apexc\apexc.c and apexcdsm.c.
- NOTES: APE(X)C (All Purpose Electronic X-ray Computer) was a computer built by Andrew D. Booth and others for the Birkbeck College, in London, which was used to compute cristal structure using X-ray diffraction. It was one of the APEC series of computer, which were simple electronic computers built in the early 1950s for various British Universities. Known members of this series are: * APE(X)C: Birkbeck College, London (before 1953 (1951?)). * APE(N)C: Board of Mathematical Machines, Oslo. * APE(H)C: British Tabulating Machine Company. * APE(R)C: British Rayon Research Association. * UCC: University College, London (circa january 1956). * MAC (Magnetic Automatic Calculator): "built by Wharf Engineering Laboratories" (february 1955), which used some germanium diodes. * The HEC (built by the British Tabulating Machine Company), a commercial machine sold in two models at least (HEC 2M and HEC 4) (before 1955)
- SOURCE: cpu\apexc\apexc.c



21.2   GenSync
- 0.36RC1            : This game was removed from MAME. Nicola wrote: Pong was too much of a simulation and too little of an emulation. It didn't really fit into MAME's architecture which is CPU-based and targeted at accurately reproducing the gameplay of the original.
- 0.36b10            : Juergen Buchmueller added Pong (this game has no ROMs).
- NOTES: GenSync = Generic Video Synchronization CPU replacement for non-CPU games
- GAMES: Pong (Atari 1972)


21.3   CP1610
- 0.79u2             : Nathan Woods fixed the CP1610 core (cpuintrf.c) and the declaration of activecpu_set_irq_callback().
- 0.79u1             : Renamed CPU_CP1600 to CPU_CP1610 [Nathan Woods].
- 0.37b14            : Removed cpu\cp1600\cp1600.c and 1600dasm.c.
- NOTES: General Instrument CP1600 emulator by Frank Palazzolo
- SOURCE: cpu\cp1610\cp1610.c


21.31  SSP1610
- 0.123u5            : Removed ssp1610.c, ssp1610d.c and ssp1610d.c. Grazvydas Ignotas (notaz) added support for Sega Virtua Processor, to run Genesis/MegaDrive version of Virtua Racing, intended to be used by MESS. It consists of a CPU core SSP1601, and updates in megadriv.c. SSP1601 replaces SSP1610, as it has been confirmed that SVP actually contains SSP1601. The current SSP1610 is only a placeholder (nearly completely unimplemented) anyway. Changed megadriv.c add a new driver for Genesis/MegaDrive+SVP combination, also add SVP memory controller logic and memory map.
- 0.113u2            : Pierpaolo Prazzoli added very preliminary SSP1610 CPU core.
- SOURCE: cpu\ssp1610\ssp1610.c


21.4   CDP1802
- 0.124u3            : Curt Coder added machine parameter and macros for the CDP1802 callback functions. This seems to have fixed the player sprite flashing in Destroyer/Altair/Draco [Curt Coder].
- 0.116u1            : Curt Coder fixed the reset mode in CDP1802.
- 0.114u3            : Additional CDP1802 updates, taken from MESS [Curt Coder].
- 0.114u2            : Curt Coder fixed CDP1802 DMA emulation.
- 0.112u2            : Removed cdp1802\1802tbl.c.
- 0.112u1            : Improvements to the Cidelsa driver [Curt Coder]: Fixed the disassembly of cdp1802 opcode LSKP. Changed the cdp1802 opcode OUT to increment R(X) after calling the write handler.
- 0.109u5            : Aaron Giles converted the CDP1802 disassemblers to the new format and added step in/out support where it was obvious.
- 0.109u2            : Added support for Cosmac RCA CDP1802 [Peter Trauner].
- 0.37b14            : Removed cpu\cdp1802\cdp1802.c, 1802dasm.c and 1802tbl.c.
- 0.37b11            : Renamed cpu\cdp1802\disasm.c to 1802dasm.c and table.c to 1802tbl.c.
- 23rd August    2000: Peter Trauner added a Cosmac CDP1802 CPU core.
- GAMES: Cidelsa
- SOURCE: cpu\cdp1802\cdp1802.c



21.5   Fairchild 3850
- 0.118u3            : Wilbert Pol fixed F8 CPU core to not clobbert the irq_callback on a reset.
- 0.117u2            : Nathan Woods fixed up f3853 core to work with new timing code.
- 0.111u2            : Added F8 emulator [Juergen Buchmueller]
- 0.37b14            : Removed cpu\f8\f8.c and f8dasm.c.
- NOTES: This work is based on Frank Palazzolo's F8 emulation in a standalone Fairchild Channel F emulator and the 'Fairchild F3850 CPU' data sheets.
- SOURCE: cpu\f8\f8.c + cpu\f8\f3853.c


21.6   KABUKI
- NOTES: The "Kabuki" is a custom Z80 module which runs encrypted code and manufactured by VLSI. The encryption key is stored in some battery-backed RAM.
- SOURCE: machine\kabuki.c
- PCB: KABUKI, BUNRAKU and SHARAKU (Capcom/Mitchell games), DL-030P (CPS2)


21.7   ST0016
- 0.105u5            : Improvements to the MACS driver [Tomasz Slanina]: Fixed a couple of gfx bugs in st0016 video emulation, added hacks to allow MACS games to boot and removed REGION_DISPOSE flag from srmp5 and speaglsht (no more crashes).
- 0.92               : Tomasz Slanina improved the MACS driver. Now using ST0016 Video, however emulation is still incomplete so it doesn't do much more yet.
- 19th July      2004: Tomasz Slanina - Added BG tilemap support (4/8 bpp) to ST-0016 emulation.
- 0.81u7             : R. Belmont and Tomasz Slanina added ST-0016 stereo sound to the ST0016 driver. Neratte Chu and Renju Kizoku now have sound.
- NOTES: The Seta custom chip ST-0016 is a all in one z80, gfx and sound chip (http://www.slanina.pl/arc.html)
- GAMES: Renju Kizoku (Visco 1994), Seta - Mayjinsen(1994), Super Eagle Shot (1994), Neratte Chu (1996)
- PCB: SETA ST-0016 TC6187AF JAPAN 9348YAA, QFP208 (Speglsht)


21.8   TS-001-Turbo
- 0.124u3            : David Haywood made some changes to the 'V25' code in toaplan2.c. Batsugun does upload what looks to be the entire program, unencrypted. If enabled it runs to the point of waiting for interrupts, however, for those it looks like it needs a real V25 core with register banks etc.
- 0.88               : Added MSM6295 sound via command tables in Batsugun and Knuckle Bash.
- NOTES: The Toaplan secondary cpu TS-001-Turbo is likely an NEC V25+ with some internal rom code and controls the YM2151 and OKI M6295 sound on some boards.
- SOURCE: audio\toaplan2.c
- PCB: TS-001-TURBO, QFP94 (Fixeight), TS-002-MACH (Dogyuun), TS-004-DASH (Knuckle Bash), TS-007-SPY (Grind Stormer, VFive)


21.9   SCU DSP
- 29th November  2005: Mariusz Wojcieszek - Fixed parallel instructions which increment CT registers to update CT register only once, after dsp operation is finished. This fixes instructions like MOV MC0,X MOV MC0,Y used by vfremix. Changed ALU 32bit instructions to not sign extend their result when loaded to ALU. This matches Sega's dspsim behaviour. Changed DMA addnumber handling to match Sega's dspsim.
- 0.99u3             : Mariusz Wojcieszek fixed add number in DSP DMA.
- 13th August    2005: Mariusz Wojcieszek - Fixed add number in DSP DMA.
- 0.96               : Angelo Salese fixed the T0F behaviour in the DMA operation, it was causing an hang in Treasure Hunt due of that and removed the dsp.log file creation when you are not using the debug build.
- 12th April     2005: Angelo Salese - Fixed the T0F behaviour in the DMA operation,it was causing an hang in Treasure Hunt due of that. Removed the dsp.log file creation when you are not using the debug build.
- 0.88u5             : Angelo Salese finished flags in ALU opcodes and SR opcode: MSB does not change.
- 14th November  2004: Angelo Salese - Finished flags in ALU opcodes. SR opcode: MSB does not change.
- 28th March     2004: Mariusz Wojcieszek rewrote ALU and MUL operations using signed arithmetics, improved DMA and fixed MOV ALH,x.
- 0.79               : Unaligned SCU direct mode DMA fix [R. Belmont].
- 0.77u3             : Added machine\scudsp.c.
- 11th December  2003: Mariusz Wojcieszek submitted an improvement to the SCU DSP emulation in the ST-V driver, but Virtua Fighter Remix still doesn't work properly.
- 11th December  2003: Mariusz Wojcieszek - Result of ALU command is stored into ALU register. X-Bus command: MOV [s],X can be executed in parallel to other X-Bus commands. Y-Bus command: MOV [s],Y can be executed in parallel to other Y-Bus commands. Jump and LPS/BTM support: jump addresses are absolute, prefetched instructions are executed before jump is taken, after each instruction, X and Y is multiplied and contents are loaded into MUL register. Fixed RL8, fixed MVI, flags computation in MVI and JMP is partly guessed (because of errors in docs), added reading DSP mem from SH2 side and overworked disassembler.
- NOTES: Virtua Fighter Remix (Sega 1995) is the only STV game that needs the SCU DSP.
- SOURCE: machine\scudsp.c, drivers\stv.c


21.A   M7700
- 0.85u2             : R. Belmont added a WIP Mitsu M7700 series CPU core, specifically targeting the M37710.
- SOURCE: cpu\m37710\m7700ds.c


21.A1  M37702
- 0.107u3            : 65816/377xx update [R. Belmont]: Made block transfer instructions interruptable as they are on both actual chips (previously a single opcode could eat >400,000 cycles with obvious consequences for interrupt timing). Fixed M377xx block transfers (move one less byte than the 65816).
- 0.104u2            : Updates to the M37710 core [R. Belmont]: Fixed LDM behavior when executing outside of bank 0. Fixed various global bugs when executing outside of bank 0. Fixed so top 8 bits of X & Y are preserved when in 8-bit index mode. Fixed some disassembly errors. Added save state support. Added M37702 alias for documentation purposes.
- 17th January   2006: R. Belmont - Phil Stroffolino was able to trojan and dump the BIOSes from the C71 3D math engine (actually a TMS32c025) and the C74 sound/inputs MCU (actually an M37702). He's already flying high with the C71 - using that code many long-standing graphics problems are now gone and several games that didn't work properly now work 100% (such as Ace Driver: Victory Lap).
- 11th January   2006: Charles MacDonald - I recently purchased two Suzuka 8 Hours PCBs (Namco System 2) and will see what can be done about trojaning the M37702-based C68 custom chip used on it. This would be helpful for System 2 and System 21 games. Also I'd like to take a closer look at the alternate type of video hardware this game has, since there seem to be some minor emulation issues in MAME.
-  4th January   2006: Charles MacDonald - Some information is needed about the M37702 MCUs used in various Namco games. If anyone can help, the following needs to be determined: Which games use the C71, C72, or C73 chips. Which games use the C77 (or higher numbered) chip. What we know so far is: C68  = System 2 (Final Lap 3, Suzuka 8 Hours) + System 21, C69  = NA-1 (World Court Tennis), C70  = NA-2 (Quiztou, Numan Athletics), C71  = System 22 (Master TMS32025 DSP BIOS), C72  = ?, C73  = Found on a test board, but used in any games?, C74  = System 22, C75  = NB-1 (Nebulas Ray) + NB-2 (Out Foxies) + System FL and C76  = System 11 (Xevious 3D/G). In the interim I've been examining the BIOS and working on a better trojan as well as figuring out how hardware on the MCU side works. So far adapting the NA-1 trojan for the C70 chip has not worked, but given the many similarities to C69 I feel a solution is not far off. It looks like all the System 2 games that have C68 do not use the external program ROM socket. Do any System 21 games use it, if such a socket is present? Updated the chip list based on information from Justin (thanks for the PCB pic!), Kayama, Fujix, Oliver, Guru and R. Belmont.
-  3rd January   2006: R. Belmont - Charles MacDonald has trojaned the MCU BIOS for Namco NA-1. Primarily this means correct emulated sound and music as opposed to the current (very good) simulation. I'm working on hooking everything up in MAME properly right now. And yes, this can also be considered proof of concept for trojaning other troublesome Namco MCUs (including System 11, 22, NB-1/NB-2, and FL) although the specific method won't quite apply.
-  2nd January   2006: Charles MacDonald - I've been running tests on the Namco NA-1 hardware over the last few days, and figured out how to dump the internal ROM of the M37702 MCU used in Super World Court. The BIOS has a function where code can be copied from the 68000 side over to MCU RAM and executed, making it quite insecure. I wrote a program that copies a portion of the M37702 memory to shared RAM, and the 68000 can change and run the program in a loop to read any part of the MCU address space. I think the same technique will work for other NA-1 games; at least what I've seen in MAME is that a number of them also upload code fragments for the MCU to use. For other types of Namco hardware that use the M37702, it's highly dependant on what services the MCU makes available. Also, now that the BIOS can be examined and user code can be executed on the MCU side for testing, maybe the NA-1 sound hardware (integrated in the multiple purpose 219 chip) will get figured out. Though the existing simulation of the NA-1 sound hardware is remarkably good.
- NOTES: The Mitsubishi M37702 (printed as C74) is a sound MCU with mask ROM
- SOURCE: audio\namcoc7x.c
- PCB: (printed as C74) System 22


21.A2  M37710

- 0.121u4            : Phillip Bennett changed M37710 CPU to use the CPU clock for its internal timer rather than a hard-coded value. Fixes tempo in Namco NA-1 games.
- 0.113u4            : G65816/M37710 CPU core updates [R. Belmont]: Fixed a race condition in the WAI instruction where the CPU could get stuck. (MESS bug #661, may have caused intermittent issues with Namco games in MAME too). Fixed block transfer instructions when the accumulator is in short mode. (Fixes some SNES games not booting, notably Final Fantasy Mystic Quest).
- 0.109u5            : Aaron Giles converted the m37710 disassemblers to the new format and added step in/out support where it was obvious.
- 0.107u3            : 65816/377xx update [R. Belmont]: Made block transfer instructions interruptable as they are on both actual chips (previously a single opcode could eat >400,000 cycles with obvious consequences for interrupt timing). Fixed M377xx block transfers (move one less byte than the 65816).
- 0.104u2            : Updates to the M37710 core [R. Belmont]: Fixed LDM behavior when executing outside of bank 0. Fixed various global bugs when executing outside of bank 0. Fixed so top 8 bits of X & Y are preserved when in 8-bit index mode. Fixed some disassembly errors. Added save state support. Added M37702 alias for documentation purposes.
- 12th February  2006: R. Belmont - I found the remaining M377xx core bug that was preventing System 22 games from using the dumped C74 BIOS. It's actually a difference from the 65C816: for anyone who's done any SNES hacking, you might find this interesting. Or not. Take this assembly program, which is the same on both processors (except the 7700 doesn't need the first two instructions - it has no 6502 emulation mode): CLC, XCE ; make sure we're in native mode - 65816 only, REP #$30 ; all registers to 16 bits, LDA #$0123, LDX #$4567, LDY #$89AB, SEP #$30 ; all registers to 8 bits and REP #$30 ; back to 16 again. Now, what are the 16-bit values of A, X, and Y at that point? On a real 65C816 (tested on an Apple IIgs) A is 0123, X is 0067, and Y is 00AB. On the M377xx (I can't test on one, but there's a routine at C881 in the C74 BIOS that makes this behavior extremely clear) A is 0123, X is 4567, and Y is 89AB. The upshot is that with this and some other fixes, the System 22 games (including Ace Driver!) now play music using their own real correct BIOSes. No more BAD DUMP and PR1DATA.8K tomfoolery.
-  4th February  2006: R. Belmont - The C74 BIOS for Namco's System 22 games is fun. And by 'fun' I mean (insert the Howard Dean scream here). It's found a few more lingering bugs in the M377xx core though, so that's always useful.
- 0.103u2            : R. Belmont added another addressing mode for SBCB opcade and fixed MPY to clear the carry flag in M37710.
- 0.101u1            : Some improvements to M37710 [cync].
- 0.100u4            : Updated 65816 and 37710 cores [R. Belmont]: Fixed both CPUs to set the data bank register to the destination on an MVN/MVP. Some minor tweeks so the debugger works properly when the 65816 is executing out of a read handler (as it always is for the SNES).
- 0.99u10            : Aaron Giles fixed interrupt problem in the M37710 core that caused problems with the recent Namco update.
- 0.99u9             : Major Namco sound improvements [R. Belmont]: Speed-cheated all instances of the M37710/C352 sound system so CPU requirements don't go up much. This also helped back off the requirements a hair for Prop Cycle and Time Crisis.
- 0.99u7             : Cync fixed several bugs in the Namco System 22 sound system (fixed interrupt update).
- 0.92               : R. Belmont fixed bug in M37710 cpu core.
- 26th January   2005: R. Belmont - Finishing the first pass of the Namco Super System 22 MCU integration, where the M37710 reads the controls.
- 0.86u4             : R. Belmont added support for externally-pulsed timers (Prop Cycle uses this to read the pedals).
- 0.86u2             : R. Belmont added analog and digital I/O port support. (anyone know how to control PC case fans from software?  Prop Cycle's "fan" output is bit 1 of 37710 port 5... ;-), added LDB absolute and DIV direct opcodes, rewrote the RLA instruction. Pretty much everything was wrong with it including the result, flags, and cycle count and fixed disassembly for RLA.
- 0.86u1             : R. Belmont added opcodes ROR B, LDB direct indexed, MPY stack relative and DIV direct opcode.
- 25th August    2004: R. Belmont - Got the M37710 talking to the 68020 in the Super System 22 games, so e.g. Prop Cycle now has music and sound effects. Now working out how the MCU reads the controls to eliminate more HLE hacks...
- 0.86               : M37710 changes [R. Belmont]: Data bus is actually 16 bit, not 8, fixed saving of status register on interrupts, fixed errors in PHB, PHT, PLT, and ANDB opcodes, added XAB, PLB, and ROLB opcodes, fixed IRQ dispatch errors and various get_info fixes.
- 21st August    2004: R. Belmont - Fixed a ton more bugs in the M37710 and submitted it.
- 19th August    2004: R. Belmont - Even more work on the M37710. Fixed a bunch of bugs and added 2 more opcodes so Prop Cycle is now happy, but Time Crisis is angry now instead.
- 18th August    2004: R. Belmont - Continued work on the M37710. Fixed data bus width to 16-bit (oops), added timer support, and fixed some obscure IRQ handling bugs. Result? It crashes when Prop Cycle tries to play a sound (grumble), but I do have some leads to chase when I'm less tired.
- 0.85u2             : R. Belmont updated the Namco Super System 22 driver to use preliminary M37710 core, but it doesn't do anything useful yet.
- SOURCE: cpu\m37710\m37710.c
- NOTES: Mitsubishi M37710 is based on the WDC 65C816 core, with the following notable changes: Second accumulator called "B" (on the 65816, "A" and "B" were the two 8-bit halves of the 16-bit "C" accumulator). 6502 emulation mode and XCE instruction are not present. No NMI line. BRK and the watchdog interrupt are non-maskable, but there is no provision for the traditional 6502/65816 NMI line. 3-bit interrupt priority levels like the 68000. Interrupts in general are very different from the 65816. New single-instruction immediate-to-memory move instructions (LDM) replaces STZ. CLM and SEM (clear and set "M" status bit) replace CLD/SED. Decimal mode is still available via REP/SEP instructions. INC and DEC (0x1A and 0x3A) switch places for no particular reason. The microcode bug that caused MVN/NVP to take 2 extra cycles per byte on the 65816 seems to have been fixed. The WDM (0x42) and BIT immediate (0x89) instructions are now prefixes. 0x42 when used before an instruction involving the A accumulator makes it use the B accumulator instead. 0x89 adds multiply and divide opcodes, which the real 65816 doesn't have. The various 7700 series models differ primarily by their on board peripherals. The 7750 and later models do include some additional instructions, vs. the 770x/1x/2x, notably signed multiply/divide and sign extension opcodes. Peripherals common across the 7700 series include: programmable timers, digital I/O ports, and analog to digital converters.
- PCB: M37710S4BFP, QFP80 (Airco22b, Alpinerc, Propcycl)


21.B   MN1020012
- PCB: Panasonic MN1020012A sound CPU, QFP128  (Taito GNET-System, Ftimpacta, Gdarius, Raystorm)

21.C   CY7C9101
- PCB: CY7C9101 16-Bit Arithmetic Logic Unit (ALU) (Primrage, TMek), CYC9101 (Guardian)

21.D   SC61860
- 0.117u2            : Nathan Woods fixed up sc61860 core to work with new timing code.
- 0.111u5            : Nathan Woods fixed a size bug in the SC61860 disassembler.
- 0.111u2            : Added Sharp 61860 emulator [Peter Trauner].
- 0.37b14            : Removed cpu\sc61860\sc61860.c, scdasm.c, scops.c, sctable.c, sc.h and readpc.c.
- 0.37b11            : Renamed cpu\sc61860\disasm.c to scdasm.c, ops.c to scops.c and table.c to sctable.c.
- NOTES: The Sharp SC61860 is a CPU Sharp in pocket computers
- SOURCE: cpu\sc61860\sc61860.c

21.E   LH5801
- 0.111u2            : Added Sharp LH5801 CPU [Peter Trauner].
- 0.37b14            : Removed cpu\lh5801\lh5801.c, 5801dasm.c and 5801tbl.c.
- 0.37b13            : Added cpu\lh5801\lh5801.c, 5801dasm.c and 5801tbl.c.
- NOTES: Based on info found on an artikel for the Tandy TRS80 PC2.

21.F   SM8500
- 0.122u7            : Atari Ace added a missing case statement in sm8500d.c, noticed while reviewing dead code warnings.
- 0.111u2            : Added Sharp SM8500 CPU [Wilbert Pol].
- SOURCE: cpu\sm8500\sm8500.c

21.G   Saturn
- 0.118u2            : Wilbert Pol fixed HP Saturn CPU core disassembler.
- 0.111u2            : Added Saturn CPU [Peter Trauner] for HP calculators.
- 0.37b14            : Removed cpu\saturn\saturn.c, saturnds.c, satops.c and sattable.c
- 0.37b13            : Added cpu\saturn\saturn.c, saturnds.c, satops.c and sattable.c
- SOURCE: cpu\saturn\saturn.c

21.H   PDP1
- 0.111u2            : Added PDP1 CPU [Barry Silverman, Vadim Gerasimov]. The Programmed Data Processor (PDP-1) is a high speed, solid state digital computer designed to operate with many types of input-output devices with no internal machine changes. It is a single address, single instruction, stored program computer with powerful program features. Five-megacycle circuits, a magnetic core memory and fully parallel processing make possible a computation rate of 100,000 additions per second. The PDP-1 is unusually versatile. It is easy to install, operate and maintain. Conventional 110-volt power is used, neither air conditioning nor floor reinforcement is necessary, and preventive maintenance is provided for by built-in marginal checking circuits. PDP-1 circuits are based on the designs of DEC's highly successful and reliable System Modules. Flip-flops and most switches use saturating transistors. Primary active elements are Micro-Alloy-Diffused transistors. The entire computer occupies only 17 square feet of floor space. It consists of four equipment frames, one of which is used as the operating station. The Central Processor contains the control, arithmetic and memory addressing elements, and the memory buffer register. The word length is 18 binary digits. Instructions are performed in multiples of the memory cycle time of five microseconds. Add, subtract, deposit, and load, for example, are two-cycle instructions requiring 10 microseconds. Multiplication requires and average of 20 microseconds. Program features include: single address instructions, multiple step indirect addressing and logical arithmetic commands. Console features include: flip-flop indicators grouped for convenient octal reading, six program flags for automatic setting and computer sensing, and six sense switches for manual setting and computer sensing. The coincident-current, magnetic core memory of a standard PDP-1 holds 4096 words of 18 bits each. Memory capacity may be readily expanded, in increments of 4096 words, to a maximum of 65,536 words. The read-rewrite time of the memory is five microseconds, the basic computer rate. Driving currents are automatically adjusted to compensate for temperature variations between 50 and 110 degrees Fahrenheit. The core memory storage may be supplemented by up to 24 magnetic tape transports. PDP-1 is designed to operate a variety of buffered input-output devices. Standard equipment consistes of a perforated tape reader with a read speed of 400 lines per second, and alphanuermic typewriter for on-line operation in both input and output, and a perforated tape punch (alphanumeric or binary) with a speed of 63 lines per second. A variety of optional equipment is available, including the following:
- 0.37b14            : Removed cpu\pdp1\pdp1.c and pdp1dasm.c.
- SOURCE: cpu\pdp1\pdp1.c


21.J   SSP1601 DSP
- 0.123u5: Grazvydas Ignotas (notaz) added support for Sega Virtua Processor, to run Genesis/MegaDrive version of Virtua Racing, intended to be used by MESS. It consists of a CPU core SSP1601, and updates in megadriv.c. SSP1601 replaces SSP1610, as it has been confirmed that SVP actually contains SSP1601. The current SSP1610 is only a placeholder (nearly completely unimplemented) anyway. Changed megadriv.c add a new driver for Genesis/MegaDrive+SVP combination, also add SVP memory controller logic and memory map.
- NOTES: Samsung SSP1601 DSP. Not everything is implemented, but it is accurate enough to properly emulate Virtua Racing for Genesis/MegaDrive.
- SOURCE: cpu\ssp1601\ssp1601.c




22.    Sound Communication

22.1   Seibu SEI0100BU

- NOTES: The SEI0100BU YM3931 is not a Yamaha chip (!). It is the main/sub cpu interface, similar to Konami's K054986A or Taito's TC0140SYT. It also provides the Z80 memory map and interrupt control.
- SOURCE: audio\seibu.c
- GAMES: Tad - Cabal (1988), Blood Bros. (1990), Raiden (Seibu 1990), Dead Angle (1988)
- PCB: SEI0100BU YM3931 9106 EANA (Sdgndmps), SEI0100BU YM3931 9149 EALA (Sdgndmrb), SEI0100BU YM3931 9203 EAFA (Heatbrl), YM3931 SEI0100BU  DIP64 (Skysmash)


22.2   Taito TC0140SYT
- PCB: TCO140SYT (Othunder, Sci, Aquajack)
- SOURCE: audio\taitosnd.c


22.3   Konami K054986
- GAMES: Konami - Lethal Enforcers (1992), X-Men (1992), Martial Champion (1993), Polygonet Commanders (1993), Violent Storm (1993)
- PCB: 054986A (Viostorm, Xmen)



 


SOUND

  1.    MAME Sound Interface
  1.1   Streams
  1.2   Mixer
  1.3   Discrete sound
  1.4   Speaker
  1.5   Custom
  1.6   Analog
  1.7   Samples
  1.8   ADPCM
  1.9   Sound filter

  2.    Digital Analog Converter (DAC)
  2.1   AMD
  2.11  0800
  2.12  0807
  2.13  08CQ
  2.2   Analog Devices
  2.21  AD561
  2.22  AD706
  2.23  AD1847
  2.24  AD1851
  2.25  AD1866
  2.26  AD1868
  2.3   Asahi Kasei Microsystems
  2.31  AK4309
  2.32  AK4310
  2.33  AK4316
  2.4   NEC
  2.41  MC1408
  2.42  MC14016
  2.43  D6376
  2.44  D6379
  2.5   Philips
  2.51  TDA1004
  2.52  TDA1010
  2.53  TDA1311
  2.54  TDA1386
  2.55  TDA1543
  2.56  TDA1545
  2.6   Sanyo
  2.61  LC7528
  2.62  LC7881
  2.63  LC78815
  2.64  LC78820
  2.65  LC78832
  2.7   Other
  2.71  SND01
  2.72  MB88347
  2.73  MSM6376
  2.74  BU9480

  3.    Texas Instruments
  3.1   SN76477
  3.2   SN76489
  3.21  SN76489A
  3.3   SN76496
  3.4   TMS36XX
  3.41  TMS3615
  3.5   TMS57002

  4.    Atari
  4.1   TIA
  4.2   POKEY
  4.3   Atari Audio Board II
  4.4   Jaguar

  5.    Yamaha
  5.1   FM Sound Core
  5.2   YM2149
  5.3   YM2151
  5.4   YM2203
  5.5   YM2413
  5.6   YM2608
  5.7   YM2610
  5.71  YM2610B
  5.8   YM2612
  5.9   YM3012
  5.10  YM3014
  5.11  YM3016
  5.12  YM3438
  5.13  YM3526
  5.14  YM3528
  5.15  YM3812
  5.16  YMF262
  5.17  YMF268-F
  5.18  YMF271
  5.19  YMF278B
  5.20  YMF286-K
  5.21  SCSP
  5.22  AICA
  5.23  YMZ280B
  5.24  YMZ284
  5.25  AY-3-8910A
  5.26  AY-3-8912A
  5.27  AY-3-8913A
  5.28  Y8950
  5.29  YAC513
  5.30  YAC515
  5.31  YAC516
  5.32  Yamaha DELTA-T ADPCM

  6.    Bally/Midway/Sente
  6.1   Astrocade
  6.2   CEM3394

  7.    Exidy
  7.1   Exidy 440

  8.    Namco
  8.1   Namco sound
  8.2   Namco 15XX
  8.21  Namco 50XX
  8.22  Namco 52XX
  8.23  Namco 54XX
  8.24  Namco 56XX
  8.25  Namco 58XX
  8.3   Namco CUS30
  8.4   Namco 63701X
  8.5   Namco System 1
  8.6   Namco NA
  8.7   C140
  8.8   C352

  9.    OKI
  9.1   MSM5205
  9.2   MSM5232
  9.21  MSM5253
  9.22  MSM5295
  9.3   OKI6295
  9.4   MSM6585

 10.    Nintendo
 10.1   N2A03 / NES APU
 10.2   SNES Custom
 10.3   S-DSP
 10.4   S-SMP

 12.    Konami
 12.1   K005289
 12.2   K007232
 12.3   K051649
 12.4   K053260
 12.5   K054539
 12.6   K054544
 12.7   K056800

 13.    Sega
 13.1   Sega PCM
 13.2   RF5C68
 13.3   RF5C320
 13.4   RF5C400
 13.5   MultiPCM

 14.    Seta
 14.1   X1-010
 14.2   ST0016

 15.    Hudson Soft
 15.1   HuC6280

 16.    Philips
 16.1   SAA1099
 16.2   SAA71111

 17.    Capcom
 17.1   Q-Sound
 17.2   CAPCOM-Q1

 18.    Nanao
 18.1   GA20

 19.    Ensoniq
 19.1   ES5503
 19.2   ES5505
 19.3   ES5506
 19.4   ES5510
 19.5   ES5701
 19.6   SUPER GLU

 20.    Brian Schmidt Music Technology
 20.1   BSMT2000

 21.    Gaelco
 21.1   Gaelco GAE1
 21.2   Gaelco CG1V

 22.    Sony
 22.1   SPU

 23.    Excellent Systems
 23.1   ES8712

 24.    Sound Systems
 24.1   Bally Midway sound boards
 24.11  Squawk & Talk
 24.12  Chip Squeak Deluxe
 24.13  Turbo Chip Squeak
 24.14  Sounds Good
 24.15  Midway/Williams Audio Boards
 24.2   Sega
 24.21  G80 Universal sound
 24.3   Leland
 24.4   DMA-driven DAC
 24.41  CAGE
 24.42  Midway DCS audio board
 24.5   MSX AUDIO
 24.6   Amiga custom sound
 24.7   Seibu Sound System
 24.8   Vegas sound system
 24.9   Data East Pinball soundboard
 24.A   Taito soundboard

 25.    Synthesizer / MIDI
 25.1   SAM9773
 25.11  SAM448
 25.2   ICS2115
 25.3   QS1000
 25.4   KS0164
 25.5   VRender0

 26.    Speech processors
 26.1   DAC Speech
 26.2   Texas Instruments
 26.21  TMS0285
 26.22  TMS5100
 26.23  TMS5110
 26.24  TMS5200
 26.25  TMS5220
 26.26  M58817
 26.3   Votrax SC-01
 26.4   TSI S14001A
 26.5   GI
 26.51  SP0250
 26.52  SP0256
 26.6   Hitachi HD38880 and HD38882
 26.7   HC-55516
 26.8   VLM5030
 26.9   SSI263
 26.A   NEC
 26.A1  uPD7756
 26.A2  UPD7759
 26.B   MSM5218
 26.C   Alpha 88

 27.    Other
 27.1   Melody Generator
 27.2   Sample Generating CPU
 27.3   Waveform Generator
 27.31  S2688
 27.4   Noise Generator
 27.41  MM5437
 27.42  MM5837
 27.43  CDP1869
 27.5   TIA-MC1
 27.6   DSP
 27.61  Zoom Corp ZSG-2
 27.62  AN7395
 27.7   MESS sound cores
 27.71  Beep
 27.72  Wave
 27.73  SID

 28.    Extern
 28.1   Cassette Tape
 28.11  Clarion 809
 28.2   CD Audio

 29.    Extra
 29.1   MB87078
 29.2   Toshiba
 29.21  TC9176
 29.22  TC9185
 29.3   AN5836
 29.4   BA3121
 29.5   SSM2047
 29.51  SSM2300
 29.6   TEA6320

 30.    Audio Amplifier
 30.1   Fujitsu
 30.2   Hitachi
 30.3   Japan Radio Co.
 30.4   National Semiconductor
 30.5   NEC
 30.6   NJMxxxx
 30.7   Other
 30.8   Philips
 30.9   Sanyo
 30.A   Toshiba
 30.B   TL0xx

 31.    Potentiometers
 31.1   VR
 31.2   RV
 31.3   DS1267

..................................................................................................................................................................................................................................




S1.    MAME Sound Interface

- 0.123u2            : Atari Ace added some missing cores to sndintrf.c.
- 0.122u7            : Couriersud added MDRV_SOUND_ROUTE_EX to specify target input channel.
- 0.121u3            : Aaron Giles added an assert to ensure that the sound clear latch value is only set at init time, since its value is not saved.
- 0.120u3            : Some build-related improvements to the sound cores [Atari Ace]: The WAVE dependency on MESS code was made explicit, so it can be built independentally of MESS.
- 0.118u5            : Atari Ace changed all comparison for CPU and sound chip types to compare against CPU_DUMMY or SOUND_DUMMY instead of 0. Also updated usages of sndti_to_sndnum() so that they use sndti_exists() where appropriate.
- 0.116u3            : Zsolt Vasvari updated all sound cores to use mame_time instead of double.
- 0.116              : Atari Ace improved independence of CPU and sound core variants in order to make them more properly separated by the existing compile-time flags.
- 0.114u3            : Added support for aliasing sound types. This allows minor variants in sound cores to share the same fundamental "type" so that the same sndti_* functions can be used regardless of the subtype [Aaron Giles].
- 0.112u1            : Aaron Giles added new function sound_find_sndnum_by_tag() to look up a sound index by its tag.
- 0.111u1            : Nathan Woods adding remaining MESS sound cores (sound\sid.c, sid6581.c, sidenvel.c, sp0256.c ...) to the core MAME sources.
- 0.108u3            : David Haywood added workaround for crash in the sound code under some edge cases.
- 0.104u5            : Atari Ace and Aaron Giles cleaned up include files in CPU/sound cores. CPU cores should generally only need to include cpuintrf.h. Sound cores should generally only need to include sndintrf.h.
- 0.104u4            : Added src\sound.c and sndhrdw\generic.c.
- 0.103u5            : Added sound\sound.mak.
- 0.102              : Aaron Giles removed ROMREGION_SOUNDONLY. Since -nosound no longer disables sound CPUs or sound cores (and hasn't for a while), failing to load sound ROMs was only leading to crashes.
- 0.99u9             : Aaron Giles fixed bug that caused the sound cores to keep running while paused.
- 0.94u2             : Aaron Giles removed some unwanted clamping code from sound core. Nathan Woods added entries for two MESS specific sound cores (C64/128) in src/sndintrf.c.
- 0.93u1             : Aaron Giles fixed running with -nosound.
- 0.93               : Sound System update [Aaron Giles]. sndintrf.c: Sound cores are now hooked up very much like CPU cores. There is a single get_info function that is public for each core; all other functions and data are retrieved through it. Similar to CPU cores, you can call sndtype_xxx() to query/set values for a specific sound chip type; you can also call sndnum_xxx() to query/set values for an indexed sound chip in the Machine->drv->sound array; finally, you can call sndti_xxx() to query/set values for the nth instance of any give sound chip type (sndti = sound type+index). At startup, all sound cores/filters are created. Then all the speakers are created. Finally, everything is wired up together. There are new consistency checks to make sure you don't do anything wildly bad. sndintrf.c calls the OSD layer now, and always requests stereo output. It also does a final downmix from the various speaker streams into left/right streams based on the X coordinate of the speaker. sndintrf.h: We now no longer #include every sound core's header. You have to include them yourself in your driver.
- 0.76u2             : Nathan Woods removed the update procedure in a MESS specific sound core.
- 0.76u1             : Nathan Woods removed wave_sh_stop() call from the MESS specific WAVE sound interface (it is extraneous now). Leon van Rooij changed a variable name that conflicts with a GCC built-in.
- 0.35b10            : Nicola Salmoria reorganized the sound subsystems.
- SOURCE: sndintrf.c



S1.1   Streams

- 0.112u4            : Aaron Giles changed most sound cores to generate audio at their internal clock rates (or some multiple/divisor of them) rather than at the user specified output rate. This completes the second step of decoupling audio emulation from the user's sample rate choice. Aaron Giles fixed a number of issues related to the new streaming engine and sound code. Fixed crash when restoring from a save state. Fixed crash when running with -nosound. Fixed loud looping when halted in the debugger. Fixed crash when changing sample rates (YM2203 mainly). Fixed crash in K054539 sound core.
- 0.112u3            : Aaron Giles simplified the OSD interface for sound. Removed osd_start_audio_stream and osd_stop_audio_stream; OSD initialization code is now responsible for initialization. Removed osd_get_mastervolume and osd_sound_enable, keeping management of the main volume in emu/sound.c. Aaron Giles changed sound streaming engine to be emulated time based instead of sample based. This means that emulation behavior is independent of the user-specified sample rate (except that some sound cores still use this value; to fixed in a future update). Also separated sound generation from video frame rate. Sound is now pushed to the OSD layer at a fixed rate of 50 updates per emulated second. This entailed a change in the way sound is handed to the OSD layer. Instead of the OSD layer requesting arbitrary numbers of samples each frame, the core now pushes the appropriate number of samples based on the emulated time. Aaron Giles simplified the OSD interface for sound. Removed osd_start_audio_stream and osd_stop_audio_stream; OSD initialization code is now responsible for initialization. Removed osd_get_mastervolume and osd_sound_enable, keeping management of the main volume in emu/sound.c.
- 0.110u3            : Aaron Giles removed obsolete timing parameter from stream_update().
- 0.104              : Added src\streams.c.
- 0.101u1            : Aaron Giles added save state information for streams so that dynamic volume changes get properly restored. Unfortunately this breaks all existing save states.
- 0.100              : Aaron Giles fixed crash in some games when using a low sample rate or -nosound.
- 0.94               : Aaron Giles removed extraneous clipping when passing streams from one output to the next input.
- 0.93u1             : Sound system update fixes [Aaron Giles]. Added streams engine oversamples by averaging now, removed some obsolete code from the streams code and removed obsolete macro in sound/streams.c.
- 0.93               : Sound System update [Aaron Giles]. sound/streams.c: Added a new type defined in sound/streams.h: stream_sample_t, which is used to represent a sample as used by the stream system. It is typedef'd to an INT32. Regardless of the size of stream_sample_t, all streams should be generated as if 16 bits were the maximum. The extra bits give us headroom to overdrive things if we want. All streams have the same format callback, with support for multiple inputs and outputs. Each stream has a sample rate; inputs to that stream will be down/upsampled to that rate; outputs will be down/upsampled as necessary to connect to the input of the next stream/speaker in line. Each input to a stream has its own gain, and each output has a gain as well. These can be controlled while things are running to provide some extra volume knobs. I haven't done much in the way of optimizations in order to keep things simple and working. Once things are back to normal, I may consider some additional optimizations.
- 0.34b4             : New streams.c to abstract audio streams. This makes them easier to use and more efficient. osd_play_streamed_sample() should now be considered a private function and should not be used in new code [Nicola Salmoria].
- 0.01               : SEAL Synthetic Audio Library API Interface Copyright (C) 1995, 1996 Carlos Hasan.
- SOURCE: sound\streams.c



S1.2   Mixer

- 0.93               : Removed sound\mixer.c.
- 0.85u2             : Aaron Giles fixed bug that prevented the mixer from loading data unless all channels had been modified.
- 0.84u5             : Andrea Mazzoleni fixed the mixer code so it doesn't crash if the OSD layer returns an error.
-  7th March     2001: Andrea Mazzoleni improved the mixer system to include an adjustable low pass filter, which will be used with the Darius 2 driver.
- 0.37b12            : New filtering code for the audio mixer. It is applied to audio streams generated at a sampling rate different from the sound card's one, improving quality. Some examples with a very audible difference are: fantasy, polyplay, galaxian (the background effect when playing), nibbler, vanguard and all the Seta games.
- 19th December  2000: Hiromitsu Shioya added some expanded volume setting functions to the mixer system.
- 0.36b15            : Source: Added gain support to mixer.c, through the new MIXERG() macro (extension of MIXER()). Removed the gain filed from AY8910, YM2203, YM2610 structures.



S1.3   Discrete sound

- 0.124u5            : Couriersud added DISCRETE_KEY_SALLEN_FILTER to discrete sound system. 
- 0.124u4            : Couriersud fixed a bug in disc_flt.c (konami filters). Fixed discrete sound and konami filter addressing in galaxian driver.
- 0.124u1            : Discrete sound system improvements [Couriersud]: Added DISCRETE_RCFILTER_SW to discrete sound. This implements multiple RC networks with CD4066 switches to connect/disconnect capacitor. Implemented discrete mixing in circusc using DISCRETE_RCFILTER_SW and sound routing to route 76416 output to discrete logic. Added discrete filtering and mixing to galaxian.c games using konami_sound. Fixed timing of stream_update in discrete_sound_w. All sound cores update before processing changed data. Added stream_update to discrete_sound_r. Now supports multiple output nodes per module. In this case, NODE_XXX is the default output. Alternative outputs may be accessed by using NODE_XXX_YY where 00<Y<08. You may also access nodes with macros: NODE_XXX = NODE_SUB(XXX, 0), NODE_XXX = NODE(XXX) and NODE_XXX_YY = NODE_SUB(XXX, YY) with YY != 00. This should e.g. make discrete sound emulation easier when dealing with e.g. flip flops (Q & QQ) and binary counters. Added sanity checks to check consistency issues introduced by this change. Modules specify number of outputs ==> Certain special modules (WAVELOG) may no longer be used as input nodes. Removed explicit (NODE_XX + expr) from a couple of drivers.
- 0.122u7            : Couriersud fixed DISCRETE_INPUT_STREAM and added input channel # to DISCRETE_INPUT_STREAM.
- 0.119u2            : Atari Ace added macros to clean up definitions of the discrete sound interfaces. At the same time, made them all const.
- 0.117u1            : Couriersud added two inverter oscillators supporting enable and mixing in signals to discrete.h / disc_wav.c.
- 0.116u3            : Couriersud extended the flt_rc filter to support highpass filtering. Fixed the lowpass filter to actually do a lowpass filter. Hooked up the filter to King & Balloon and updated several other drivers to the new interface.
- 0.116              : Added new components to the discrete sound system [Couriersud]: Added a "inverter oscillator" component. This can also be used as a raw sine generator - needed by radarscp. Added a "integration circuit" based on transistor and RC. Added a "modulated RC discharge" component.
- 0.113              : Derrick Renaud fixed regressions in 3 of the discrete games from 0.112u4.
- 0.112u4            : New DISCRETE_ADJUSTMENT_TAG module that uses tags instead of port numbers. Updated all games to use it, because it is now the preferred method. Added Discrete sound to Checkmate [Derrick Renaud].
- 0.112u3            : Derrick Renaud updated the DISCRETE_OP_AMP_OSCILLATOR circuit to get it ready for a future driver. It allows the DISC_OP_AMP_OSCILLATOR_1 | DISC_OP_AMP_IS_NORTON oscillator to use nodes to adjust the resistance values instead of only being static values. Derrick also added discrete sound for Amazing Maze. And added new Discrete modules: DISCRETE_LOOKUP_TABLE & DISCRETE_LOGIC_JKFLIPFLOP.
- 0.106u2            : Discrete sound updates [Derrick Renaud]: Typedef'ed external discrete sound structures to follow current structure use. Statically defined their use in most drivers to stop name pollution. Created new DISCRETE_555_VCO1 module. This is the 555&Op-amp oscillator circuit used by Borderline.
-  8th May 2006      : Frank Palazzolo - For a while now, I've been wanting to experiment with new methods of high-speed circuit simulation. The idea would be to prototype some discrete-audio stuff, possibly for MAME, using something like Python. After looking into the requirements, I realized that I needed to handle polynomials with a single variable, and ratios of these polynomials. Also, I needed to be able to handle real or complex variables. I looked around on the web, and I found that SciPy (http://www.scipy.org/) is finally coming along nicely on Windows. However, I wasn't entirely happy with the root finder they use. Along the way, I also found the ratfun (http://calcrpnpy.sourceforge.net/ratfunManual.html) package, which looked perfect, but was unsupported on Windows. I dug in and in a couple weekends, got it building under Windows. I think I'll be using it for the experiments, whenever I get back to it.
- 0.103u5            : Changed includes\rc.h to rescap.h. Discrete sound updates [Derrick Renaud]: Added new DISCRETE_CSVLOG module that lets you log discrete nodes as CSV (comma separated values) data. Modified discrete core to use the clock specified in the MDRV_SOUND_ADD line. If the clock is specified as 0, then the discrete emulation will default to the audio sample rate clock. Tweaked Phoenix Effect 2 sound to be more accurate matching oscilliscope data. Changed the Phoenix discrete clock rate to a fixed rate of 120000 allowing the simulation to be more accurate with less alaising noise at the cost of speed. Fixed the bug in the DISCRETE_NOTE module that produced notes 1 count off.
- 0.103u4            : Derrick Renaud added/changed the following discrete modules: DISCRETE_WAVELOG - easy way to log discrete nodes as a .wav file to compare against scope waveforms. DISCRETE_OUTPUT - added a final gain parameter to get it to 16 bit wav level (the old VOL setting was disabled after the last sound re-write).
- 0.102u5            : Frank Palazzolo fixed bug in discrete filtering code.
- 0.99u6             : Discrete sound update: Added DST_RCDISC5 (Diode in series with R/C), added DST_ASWITCH (analog switch), added LFSR functions DISC_LFSR_XOR_INV_IN0 and DISC_LFSR_XOR_INV_IN1 and fixed DSD_555_ASTBL__R2
- 0.99u2             : Derrick Renaud fixed the discrete sound 555 timer modules when using actual DC mode.
- 0.94u2             : Added includes\rc.h. Nathan Woods changed wavwrite type from 'void *' type to an opaque pointer 'wav_file *' in src/sound/discrete.c.
- 0.94u1             : Discrete sound updates [Derrick Renaud]. Added DSS_INPUT_STREAM (Connects external streams to the discrete system). Added magnitude conversions macro (includes\rc.h).
- 0.93u1             : Discrete Sound Update [Derrick Renaud]: Discrete Sound Changes: Various tweaks to the discrete modules and updated all drivers to use new code. DISCRETE_COUNTER, DISCRETE_LFSR_NOISE, DISCRETE_NOTE added different clocking types to be more flexable. DISCRETE_COUNTER_FIX - removed and merged with DISCRETE_COUNTER. New Discrete Modules: DISCRETE_DIODE_MIXERx - Mixes signals through diodes. DISCRETE_MULTIPLEXx - 1 of 2/4/8 signal multiplexer. DISCRETE_RCDISC4 - Various charge/discharge circuits.
- 0.93               : Added sound\flt_rc.c and sound\flt_vol.c Changed name 'Discrete_Components' to 'Discrete'.
- 0.90u2             : New Sound Functionality [Derrick Renaud]. Took Frank Palazzolo's DISCRETE_FILTER2 code and made it work outside of the discrete system (see sound\filter.h for new functions). Added op-amp bandpass filtering circuit to sound\namco54.c
- 0.90               : New Discrete Sound Functionality [Derrick Renaud, Frank Palazzolo]. Properly emulated DISC_OP_AMP_FILTER_IS_BAND_PASS_1M type filter used by many games ( see http://home.cogeco.ca/~derrickmame/galaga/Galaga_filters.html). Re-wrote atarifb and abaseb to use component value only code and new filter.
- 0.89               : Discrete Sound Update [Derrick Renaud]. Modified Discrete core node inputs to use pointers to the data, instead of moving the data into the inputs at each step. This speeds up discrete emulation. Modified all current modules and drivers to use new code. Added new Discrete Modules: DISCRETE_555_ASTABL has been modified to remove control voltage support and DISCRETE_555_ASTABL_CV has been added if control voltage is used.
- 0.88u4             : Discrete Sound Update [Derrick Renaud]. Moved discrete sound code from drivers and put in audio\. Removed the memory mapping system from the discrete inputs. Modified all current drivers to use new code. It served no purpose and was never functional. It only added a layer of confusion to the code by forcing it's use on all current drivers that do not need it. If memory mapped inputs are needed in the future (not likely), then they can be added with a DISCRETE_INPUT_MAP function. Now the discrete inputs are written to by their node name only (eg. discrete_sound_w(NODE_xx, data)). DISCRETE_INPUT and DISCRETE_INPUTX have been removed in favour of new easier to use input modules. New Discrete Modules: DISCRETE_INPUT_DATA(node)  - accepts 8-bit data from discrete_sound_w. Output at reset is 0. DISCRETE_INPUT_LOGIC(node) - 0 if data=0; 1 if data=!0.  Output at reset is 0. DISCRETE_INPUT_NOT(node)   - 0 if data=!0; 1 if data=0.  Output at reset is 1. DISCRETE_INPUTX_DATA(node, gain, offset, init), DISCRETE_INPUTX_LOGIC(node, gain, offset, init) and DISCRETE_INPUTX_NOT(node, gain, offset, init) - same as above, but will modify the output by the given GAIN and OFFSET. At reset the output will be INIT modified by GAIN and OFFSET.
- 0.88u2             : Brad Oliver fixed a bug in the discrete code. Derrick Renaud added to DISCRETE_555_ASTABLE an option to use quick charge diode (will be needed for Frogs) and an option to disable oscillation if R1 (charge) is out of circuit (will be needed by Invaders). Modified DISCRETE_555_CC to discharge cap due to natural losses if there is no charging current (needed by Frogs). This makes it more accurate then the current perfect cap that will retain a charge forever. Modified all current drivers to use new code. Added the new discrete module DISCRETE_555_MSTABLE (555 monostable simulation).
- 0.88               : Discrete Sound System update [Derrick Renaud]. Continued cleanup of code to make it more readable. New Discrete Modules: DISCRETE_NOTE - counter circuit used to create tones/music, DISCRETE_INTEGRATE - various op amp integration (ramp) circuits and DISCRETE_OP_AMP_TRIG_VCA - Did not know what to call this ( Basically it is a programable voltage controlled amp. But uses only an on/off trigger. It has resistors to select the rise/fall times. Also it is not a true VCA. It actually adjusts amplitude by clipping more/less off the bottom of the input signal. But it is a common circuit.)
- 0.80u2             : Removed sound\disc_out.c. Discrete Sound System updates [Aaron Giles, Derrick Renaud]. Aaron: * major internal cleanup and reworking of how nodes are created, fixed bug in 555 timer that led to whiny noise in Hit Me, added new input port type for analog adjuster, changed osd interface for discrete sound adjusters to use the new input port type, changed NODE_ADJUSTMENT to get its value from an input port, adjuster values are now saved in the config file and changed all games using adjusters to use the new system. - Derrick: Discrete Sound Changes: Continued cleanup of code to make it more readable. New Discrete modules added: DISCRETE_OP_AMP_OSCILLATOR - various op amp oscillator circuits that are entered using component values and DISCRETE_OP_AMP_VCO - various op amp voltage controlled oscillator circuits that are entered using component values. Game Driver Changes: Finished updating games to use Aaron's DISCRETE_ADJUSTMENT changes.
- 17th March     2004: Aaron Giles - I've been doing some internal cleanup of the discrete sound system, and have modified the way analog adjusters are handled so that they are saved in the .cfg file.
- 0.80u1             : Improved Discrete Sound System [Aaron Giles]: New DISCRETE_LOGIC_DFLIPFLOP type, changed the way multichannel output is done; affects some existing drivers, support for up to 16 channels of sound and discrete sound support for Hit Me.
- 0.80               : Discrete sound updates [Derrick Renaud]: Fixed/added more documentation of functions at top of discrete.h, DISCRETE_555_ASTABLE - changed to use common options with DISCRETE_555_CC and DISCRETE_TRANSFORMx - fixed bug that preformed math in the wrong order. Also added more math functions. New Discrete Modules Added: DISCRETE_555_CC - Constant Current based 555 VCO with 8 main configurations, that automatically configure from components used, DISCRETE_566 - NE566 simulation, DISCRETE_COMP_ADDER - Multiple parallel capacitor/resistor circuit, DISCRETE_DAC_R1 - R1 Ladder DAC that automatically configures from components used, DISCRETE_MIXERx - Resistor/Op Amp mixer stage with filtering that calulates proper gains & filtering. It automatically configure from components used and DISCRETE_SCHMITT_OSCILLATOR - VCO based on a Schmitt Inverter. Game Driver Changes: poolshrk - Converted to new component value only code, firetrk, montecar, superbug - Converted to new component value only code. Pulled discrete code out and put in audio\ataridis.c.  montecar still needs filtering on crash sound, atarifb, canyon & skydiver - minor changes to work with new code and triplhnt - added component value discrete sound, but have not figured out Shot and Bear Roar video memory locations. These are needed to make sound effects work.
- 0.78u5             : Discrete sound system updates [Derrick Renaud]: Fixed/added more documentation of functions at top of discrete.h. Fixed bug that allowed DISCRETE_RCFILTER module to use nodes not available to it. Added new Discrete modules: High pass R/C filter (DISCRETE_CRFILTER), presettable up/down counter with external clock and selectable count edge (DISCRETE_COUNTER), presettable up/down counter with bult-in frequency generator (DISCRETE_COUNTER_FIX), selectable edge trigger / re-trigger / output active state (DISCRETE_ONESHOT) and the same with reset (DISCRETE_ONESHOTR). R. Belmont fixed discrete sound system crash with -nosound.
- 0.69               : Fixed the 'no stereo' bug in src\sound\discrete.c [BUT]. Derrick Renaud fixed a minor bug in src\sound\discrete.h causing DISCRETE_LOGIC_INVERT not to work. Andrea Mazzoleni substitutes the _HUGE macro with the standard DBL_MAX value in src/sound/disc_mth.c.
- 22nd May       2003: Derrick Renaud sent in another update to the discrete sound system, fixing a few bugs and adding sounds to Drag Race, Night Driver and Orbit.
- 0.68               : Discrete sound system update [Keith Wilkins, Derrick Renaud and Frank Palazzolo]: DISCRETE_MULTADD (Multiply followed by add),  DISCRETE_TRANSFORM (Multiple math functions), DISCRETE_ADSR (structure in place - no code yet), DISCRETE_555_AST (555 astable generator with squarewave or cap charge out), DISCRETE_SQUAREWFIX (same as DISCRETE_SQUAREWAVE but not accurate during freq/duty changes - extremely fast), DISCRETE_SQUAREWAVE2 (squarewave defined by Off/On time periods), DISCRETE_FILTER1 and DISCRETE_FILTER2 (High order filter implementation), forced clipping of output values to max +32767/-32768 in disc_out.c, LFSR 48kHz bug fixed + code speedup and faster then sample rate frequency support, bugfix to discrete_sound_start system initialisation for unitialised nodes, _kill for made common code for all modules with context except for input functions and rewrite/restructure of discrete.c & discrete.h to allow fully flexible number of inputs on a node.
- 14th May       2003: Derrick Renaud changed the Atari sports games to use the discrete sound system, adding all sounds to them.
-  8th May       2003: Derrick Renaud did some improvements in the discrete sound system, fixing a few sounds and making it faster.
- 0.66               : Derrick Renaud and Keith Wilkins make a major update to the discrete sound system. This includes adjustable parameters controls in the UI, fixes to existing games, and new sound support in canyon, polaris, sprint and ultratnk.
-  1st March     2003: Keith Wilkins and Derrick Renaud submitted a large update to the discrete sound system, adding discrete sound to Canyon Bomber, Polaris, Sprint, Sprint 2, Ultra Tank and samples to Circus, Clowns and Sea Wolf.
- 22nd February  2003: Acho A. Tang submitted a very basic implementation of the discrete sounds in Stinger.
-  8th February  2003: Keith Wilkins sent in a preliminary update to the discrete sound system with a few new functions and bug fixes.
- 31st January   2003: Aaron Giles forwarded Derrick Renaud's improvements to the discrete sound in Fire Truck, Super Bug and Monte Carlo.
- 21st January   2003: Derrick Renaud adding preliminary discrete sounds and fixing controls in Polaris.
-  3rd August    2002: Ken Reneris submitted another small improvement to the Asteroids discrete sound emulation and added phosphorescent persistence emulation to the vector graphics drawing code, possibly improving the look & feel of vector games.
- 24th July      2002: Ken Reneris and Keith Wilkins both submitted improvements to the discrete sound system in Asteroids.
- 13th June      2001: Frank Palazzolo optimized the discrete sound system a little.
-  4th March     2001: Keith Wilkins added discrete sound support to Fire Truck and fixed a few other bugs in the discrete sound engine.
- 0.37b11            : Added sound\discrete.c, disc_dev.c, disc_flt.c, disc_inp.c, disc_mth.c, disc_out.c and disc_wav.c.
- 17th January   2001: Bernd Wiebelt fixed a bug causing static in the discrete sound functions.
- 0.37b11            : Keith Wilkins made some support for discrete component sound emulation. Changed name 'Custom' to 'Discrete_Components'.
- 28th November  2000: Keith Wilkins sent in a discrete sound system update, fixing some sounds in Asteroids.
- 20th November  2000: Keith Wilkins sent in an update to the discrete sound system, fixing some sound problems in Asteroids and Lunar Lander.
- 16th November  2000: Keith Wilkins updated the discrete sound system again and added support for Asteroids and Asteroids Deluxe.
- 11th November  2000: Keith Wilkins updated the discrete sound system emulation to support Lunar Lander.
-  7th November  2000: Keith Wilkins sent in a preliminary version of discrete sound system emulation, not supporting any game yet.
- 20th November  1998: Zaxxon uses discrete sound circuitry that cannot be emulated. I got lucky and found some sound boards that still had some power in them. Most Zaxxon boards the capacitors are all dried up so a lot of the sound disappear. Stuff to do: Zaxxon has 5 flight sound variations.
- 0.30               : 8039 emulator, and _emulated_ sound in Donkey Kong, Donkey Kong Jr. and Mario Bros. Since the boards also use discrete circuits to generate sound, some samples are still needed to get complete sound support. Also partial sound in Radarscope [Ron Fries, Dan Boris, Mirko Buffoni].
- GAMES: Atari - Super Bug (1977), Fire Truck (1978), Asteroids (1979), Lunar Lander (1979)
- NOTES: The Sega G-80 Raster board uses discrete sound circuitry (Games: Sega - Astro Blaster (1981), 005 (1981), Space Odyssey (1981), Monster Bash (1982), Pig Newton (1983) and Sindbad Mystery (1983))
- SOURCE: Driver by Keith Wilkins. See sound\discrete.h for for documentation on usage.


S1.4   Speaker
- 0.123u3            : Converted speakers into devices. Machine->config no longer houses an array of speakers; instead they are iterated through using the new macros (defined in sound.h) speaker_output_first() and speaker_output_next(). Updated all relevant code to do this [Aaron Giles].
- 0.37b14            : Removed sound\speaker.c.
- NOTES: Sound driver to emulate a simple speaker, driven by one or more output bits.
- GAMES: 8080bw.c
- SOURCE: sound\speaker.c


S1.5   Custom
- 0.93               : Many drivers using "custom" drivers were just using hard-coded samples and playing them with the (now-defunct) mixer. This is not "custom", it is "samples". They have been converted over to samples [Aaron Giles].
- SOURCE: sound\custom.c
- GAMES: galaxian.c games, Dead Eye (Meadows 1978), Galaxian (Namco 1979), Phoenix (Amstar 1980), Sky Base (Omori 1982)



S1.6   Analog

- 23rd August    2000: Juergen Buchmueller added preliminary analog sound emulation to Pulsar.
-  9th March     2000: Juergen Buchmueller sent a preliminary Phoenix analog sound driver.
- 13th February  2000: Juergen Buchmueller added preliminary analog sound simulation to Asteroids.
- 12th February  2000: Juergen Buchmueller added preliminary analog sound simulation to Battle Zone and Red Baron.



S1.7   Samples

- 0.122u8            : Aaron Giles added stream_get_sample_rate(), stream_get_time(), and stream_get_sample_period(). These functions are not really tested yet -- make sure they give reasonable results when first used! Updated streams.h header to latest core style.
- 0.111u2            : Zsolt Vasvari added support for multiple instances of the samples sound system.
- 0.108u3            : Firewave added some minimal validation on the sample rate configuration parameters.
- 0.108              : Aaron Giles added sample_get_base_freq() to allow for querying to the base frequency of samples.
- 0.107u3            : Aaron Giles fixed bug that caused the sound sampling code to not track changes in the refresh rate.
- 0.107u1            : Andrew Gardner removed hard core dependency on samples.
- 0.104u2            : Aaron Giles removed a ton of hacks that were checking for Machine->sample_rate==0, which is now guaranteed to never be true.
- 0.98u4             : Aaron Giles added pause/resume support for sample playback.
- 0.98u3             : Roman Scherzer fixed crash in MAME if 0-length data block was found in a WAV file.
- 0.94u2             : Aaron Giles fixed sample playback glitch.
- 0.93               : There is now a start function that allows you to create your own custom samples if you want. This allows us to replace "custom" drivers with "samples" in several cases. There is a new call sample_start_raw() which lets you play a raw sample from a pointer to INT16 data [Aaron Giles].
- 0.79u2             : Support for Tailgunner samples recorded by Zonn Moore.
-  4th January   2004: Chris Hardy added sound support to Space Firebird with samples.
- 29th October   2003: Tim Cottrill added sample support to Armor Attack and Sundance.
- 17th November  2002: Stefan Jokisch added support for sound samples in Subroc-3D.
- 25th September 1999: Mike Coates added samples to Space Panic.
- 21st September 1999: Zsolt Vasvari sent in a vicdual update which supports samples for Pulsar and Invinco.
-  3rd September 1999: Zsolt Vasvari sent in a nice update to the Vicdual driver, for example Depth Charge now has samples.
- 30th June      1999: Mathis Rosenhauer added samples for Rip Off and Solar Quest.
- 0.35b13            : Source: struct GameSample no longer has a volume field (since it is not stored in .wav files), to replace that struct Samplesinterface has an additional volume field which affects all samples played [Nicola Salmoria]. Replaced osd_adjust_sample() with osd_set_sample_freq() and osd_set_sample_volume(), and the OSD_PAN_xxx macros with MIXER_PAN_xxx.
- 0.35b11            : Aaron Giles added support for .wav samples. The custom .sam samples are no longer supported (you can use the sam2wav converter to convert them).
- 0.35b3             : Mike Coates support samples in Cosmic Guerilla.
- 0.34RC1            : Zsolt Vasvari support samples in Astro Fighter. The sound library took a lot of work. Two boardsets made this possible.
- 0.33b7             : Peter Clare support 16 bit samples in sound/samples.c
- 0.31               : Howie Cohen added support for missing samples to Donkey Kong Jr.
- 0.29               : Brad Oliver and Shane Monroe supported partial sound (through samples) in Mario Bros.
- 0.27               : Al Kossow and Brad Oliver provided drivers for the Sega vector games (Eliminator, Space Fury, Star Trek, Tac-Scan, Zektor). Partial sound support (speech) is available through samples for some of them. Mike Coates added partial sound support (through samples) to the Carnival driver.
- 0.21               : Changes in COMMON.H for the sample structure. Now it has infos on replayrate, resolution and volume of the sample to be played. BE SURE TO DOWNLOAD THE NEW SET OF SAMPLES, OR THE "MAMESAM" CONVERTER OR YOU WILL GET NO SOUND FOR SAMPLE BASED GAMES!!
- 0.20               : Ron Fries created a new set of Donkey Kong samples, using Mike Cuddy's 8039 emulator.
- 0.18               : Samples are now loadaed by the main engine, not the single drivers. This is done via the new field samplenames in the GameDriver structure. Samples can then be retrieved by the drivers in Machine->samples.
- GAMES: Namco - Rally X (1980), Galaga (1981), Xevious (1982), Pole Position (1982)
- SOURCE: sound\samples.c



S1.8   ADPCM

- 0.93               : Removed sound\adpcm.c.
-  1st November  2003: R. Belmont fixed the ADPCM functions so that games can have both MSM6295 sound chips and plain ADPCM at the same time, and he added complete sound emulation to Grand Cross Pinball.
- 31st October   2003: R. Belmont allow a driver to use both MSM6295s and "raw" ADPCM voices (gcpinbal). Also added some error trapping for MAME_DEBUG builds.
- 30th October   2003: R. Belmont added ADPCM sounds to Cabal and Dead Angle / Gang Hunter, with thanks to Jarek Burczynski for decrypting the sample ROMs.
-  2nd April     2001: Jarek Burczynski added state saving support to ADPCM and OKIM6295 sound emulation cores.
- 14th February  2001: Andrea Mazzoleni added a nice filtering sound resampling algorithm for the driver that do not produce sound at the requested sample rate.
- 29th August    2000: Nicola Salmoria added correct Z80 ADPCM emulation to the Legendary Wings / Trojan driver.
- 12th July      2000: Nicola Salmoria fixed the ADPCM sound frequency in Double Dragon and did some general cleanup in the driver.
-  2nd July      2000: CAB fixed the ADPCM frequency in the Tecmo16 driver.
- 25th June      2000: E. Watanabe fixed the ADPCM sound in the Tecmo16 driver.
- 18th August    1999: Phil Stroffolino sent in an update to the Samurai driver, with ADPCM sound and a lot of other fixes.
-  7th August    1999: Andrew Prime added PCM sound to System 18 and 3D games (using Hiromitsu Shioya's PCM code).
- 24th June      1999: Steve Ellenoff fixed Gladiator ADPCM sample pitch.
- 0.35RC1            : Sound in Great Swordsman. Tatsuyuki Satoh fixed ADPCM playback in Great Swordsman and Gladiator.
-  1st June      1999: Tatsuyuki Satoh fixed the ADPCM hack in Gladiator driver. Nicola worked on the Great Swordsman ADPCM sound.
- 31st May       1999: Aaron Giles sent in an update to the ADPCM core, to support better the newer Atari games.
- 30th April     1999: Phil Stroffolino sent in updates to many things: the SNK drivers have mostly working ADPCM sound and Cabal bootleg has ADPCM sound.
- 24th April     1999: Nicola modified the ADPCM sounds of Klax to change volume as the pieces come closer.
- 0.35b11            : Bryan McPhail added ADPCM samples to Mad Gear.
- 0.35b1             : Jarek Parchanski added PCM samples to Ninja Kid II.
- 0.34               : David Winter added Hyper Olympic (bootleg using ADPCM samples).
- 0.34b3             : Juergen Buchmueller added smoothing to ADPCM playback. Phil Stroffolino added ADPCM sounds to Renegade. Nicola Salmoria added ADPCM sample playback to the bootleg Hyper Olympic.
- 0.33b5             : Nicola Salmoria fixed bug in ADPCM sample playback. Many games are affected, e.g. Robocop, Bad Dudes.
- 0.31               : Aaron Giles improved ADPCM support. Jarek Burczynski fixed ADPCM sample support in Rastan.
- 0.24               : Fixed problems with ADPCM decoding, so now Kung Fu Master doesn't need separate samples anymore (I didn't distribute them because of copyright on sounds). The samples are now calculated during bootstrap of the game.
- GAMES: Taito - Rastan (1987), Cadash (1987), Maze of Flott (1989)



S1.9   Sound filter

- 0.93               : Filter (volume) this is a new very simple filter that can be used to control the volume of a stream if you need an extra knob. Filter (RC) -- this is a new filter that replaces the old RC filter that was in the streams code. Eventually, this could get replaced by some simple discrete logic [Aaron Giles].
-  8th March     2001: David Graves adjusted the Darius 2 and Ninja Warriors drivers to include support for the low pass filter.
-  7th March     2001: Andrea Mazzoleni improved the mixer system to include an adjustable low pass filter, which will be used with the Darius 2 driver.
- 0.37b12            : Added sound\filter.c.
- 14th February  2001: Andrea Mazzoleni added a nice filtering sound resampling algorithm for the driver that do not produce sound at the requested sample rate.
- 28th June      1999: Tatsuyuki Satoh fixed the VLM5030 and RC filter interface in Double Dribble. Nicola Salmoria fixed the filter interface in Time Pilot 84.
- 30th March     1999: Tatsuyuki Satoh modified the RC filter to be external and separated it from streams system.
- 0.35b8             : Zsolt Vasvari implemented the RC filters in early Konami games (Time Pilot, Pooyan, etc.)
- 18th March     1999: Zsolt Vasvari has added RC filter functions to all the games which use the Time Pilot sound board.
- 0.34b3 : Francesco Caporali added RC filter emulation to Gyruss. This improves some sound effects, e.g. the force field noise.





S2.    Digital Analog Converter (DAC)

- 0.104u6            : Aaron Giles added 4x oversampling support to the DAC sound system.
- 0.80               : Nathan Woods fixed a small typo in the DMADAC interface line in sndintrf.c
- 14th May       2001: Stefan Jokisch fixed the DAC sound in Atari Basketball.
- 25th February  2000: Vernon C. Brooks fixed Namco System 1 DAC.
-  9th February  2000: Tatsuyuki Satoh fixed some DAC problems in Namco System 1 games.
- 13th December  1999: Nicola Salmoria added preliminary DAC sound to Finalizer
-  7th October   1999: Tatsuyuki Satoh added DAC sounds to Namco System 1 driver.
-  1st October   1999: Aaron Giles added 16-bit interfaces to the DAC routines.
- 29th August    1999: Phil Stroffolino hooked up DACs properly in Samurai (Taito) and added the missing ROM.
- 11th June      1999: Paul Leaman and Nicola added one of the DACs to the Leland driver.
- 30th April     1999: Chris Hardy added the DAC sound to Megazone.
- 0.31               : Tatsuyuki Satoh improved YM2203 and YM2151 emulator, and DAC interface, with 16 bit samples support.
- 0.30               : Source: Tatsuyuki Satoh centralized dac.c for dac sound emulation. Several drivers use it.
- 0.29               : Nicola Salmoria add digital audio (DAC) in the Taito games (used for some sound effects, most notably Tarzan's yell in Jungle King). Also, music plays in Jungle King. All the Williams games. Samples are no longer needed and may be deleted [Steven Hugg, Mirko Buffoni, Nicola Salmoria].
- 0.28               : Fabrice Frances added *emulated* sound to Q*Bert, Reactor, Krull and Mad Planets. The samples are no longer needed and may be removed. Q*Bert Qubes would work as well, if we had the sound ROM ;-( Speech is not emulated... yet!
- GAMES: Lazer Comand (Meadows 1976), Defender (Williams 1980), The Fairyland Story (Taito 1985)
- SOURCE: sound\dac.c



S2.1   AMD

S2.11  0800
- PCB: DAC0800LCN (Turbo)

S2.12  0807
- PCB: DAC0807LCN (Mplanets)

S2.13  08CQ
- PCB: AMD DAC-08CQ (Cntsteer)


S2.2   Analog Devices

S2.21  AD561
- PCB: AD561 DAC (Omegrace)

S2.22  AD706
- PCB: AD706, SOIC8, DAC? (A51site4)

S2.23  AD1847
- PCB: ANALOG DEVICES AD1847JP 'SOUNDPORT', PLCC44, surface mounted (A51site4)

S2.24  AD1851
- PCB: D/A converter, 16bit, 0.008% THD (Nbajam, MK3)

S2.25  AD1866
- PCB: AD1866R Analog Devices dual 16-bit audio DAC (Gauntleg, Nbajamex, Blitz99)

S2.26  AD1868
- PCB: The Konami custom chips 054544/054986A have a Analog Devices AD1868R inside.



S2.3   Asahi Kasei Microsystems

S2.31  AK4309
- PCB: Asahi Kasei AK4309-VM Digital to Analog Audio Converter, SOIC24 (Heatof11, Polystar)

S2.32  AK4310
- PCB: AKM_AK4310VM DAC Audio Converter, 16Bit Resolution, Single DAC, Serial Digital Interfaces (Beastrzr, Area51, Sfex2, Brvblade, Raystorm, Taito GNET-System)

S2.33  AK4316
- PCB: Asahi Kasei AK4316-VS (MetalManiax)



S2.4   NEC

S2.41  MC1408
- SOURCE: drivers\zaccaria.c
- PCB: 10 bit DAC (Trog), AM1408 (Vsgongf)

S2.42  MC14016
- GAMES: Rock Climber (Taito 1981)
- SOURCE: drivers\rockclim.c
- PCB: MC14016BCP (Jungler)

S2.43  D6376
- PCB: NEC D6376 Audio 2-channel 16-Bit D/A Converter, SOIC16 (NintendoSuperSystem, SegaModel3, Scud, Speglsht), UPD6376 (Renju)

S2.44  D6379
- PCB: NEC uPD6379 Audio 2-channel 16-bit D/A converter 10mW , SOIC8 (PGM-System), D6379GR (Capcom-ZN1/2, Taito GNET-System)



S2.5   Philips

S2.51  TDA1004
- PCB: (Sprint1)

S2.52  TDA1010
- PCB: (Scorpion, Armada)

S2.53  TDA1311
- PCB: Philips DA1311A DAC  SOIC8 (Crysking (DA1133A ?), Misncrft, PPCar)

S2.54  TDA1386
- PCB: Philips TDA1306T Noise Shaping Filter DAC, SOIC24 (CPS3), TDA1386T (Sega Model3, Bel, Harley)

S2.55  TDA1543
- NOTES: Philips Dual 16-bit DAC
- GAMES: Ground Effects (Taito 1992), Alligator Hunt (Gaelco 1994), Gallop Racer (Tecmo 1996), Radikal Bikers (Gaelco 1998)

S2.56  TDA1545
- PCB: DA1545A (Xfiles)



S2.6   Sanyo

S2.61  LC7528
- PCB: LC7528CN (Botss, F15se)

S2.62  LC7881
- PCB: Sanyo LC7881 16bit DAC, SOIC20 (Luckywld, Gollygho, BackFire, Wcvol95)

S2.63  LC78815
- PCB: LC78815  2-Channel 16-Bit D/A Converter, SOIC20 (NamcoSystem11, Ncv1/2)

S2.64  LC78820
- NOTES: Sanyo LC78820 2-channel 18-bit D/A Converter, DIP20
- PCB: LC78820 (Titlef, Model1)

S2.65  LC78832
- PCB: LC78832M  2-Channel 16-Bit D/A Converter LSI with 2 On-Chip Digital Filters, SOIC20 (NamcoSystem12, GP500)


S2.7   Other

S2.71  SND01
- PCB: Konami SND01 715-057P 842200, DIP40 (Finalizr)

S2.72  MB88347
- PCB: Fujitsu MB88347 8bit 8 channel D/A converter with OP AMP output buffers, SOIC16 (Gp500, NamcoSystem12)

S2.73  MSM6376
- NOTES: The MSM6376 is a ADPCM sample player
- PCB: Oki MSM6376 on soundboard (MPU4VideoSystem)

S2.74  BU9480
- PCB: Rohm BU9480F, 16-bit stereo D/A converter for audio application SOP8, Tape and Reel (11beat, Mtetrisc)


S3.    Texas Instruments

S3.1   SN76477

- 0.112u4            : Added SN76477 noise RNG (random number generator) polynomial [Zsolt Vasvari, Derrick Renaud, Jarek Burczynski]
- 0.111u6            : Zsolt Vasvari and Derrick Renaud rewrote the SN76477 emulator from scratch. The main difference between the old one and the new one is that it is based on measurements from a real chip. Also the emulator is fully analog, meaning that timings/frequencies, etc. are based on voltage levels. This gives a much more true-to-life emulation where the weird behavior of the real chip comes emulated for free. The code itself is also a lot simpler and more understandable.
- 0.111u3            : Zsolt Vasvari added the remaining input pins to the SN76477 Interface. If these pins are constant, they can now be defined in the structure as opposed to having to call functions in an init routine. Modified all the drivers that use a 76477.
- 0.104u4            : Adam Bousley added save state support to the SN76477 sound chip.
- 0.94u2             : Derrick Renaud fixed SN76477 emulation bug where gain was 3x more then it should be, causing effects to clip for 2/3rds of the time and fixes the attack time for one-shot envelope mode.
-  8th April     2000: Zsolt Vasvari fixed a bug in the SN76477 emulator and got the explosion sound working in Space Chaser.
-  5th April     2000: Zsolt Vasvari added cocktail mode support and some SN76477 sound support to Space Chaser.
- 22nd March     2000: Zsolt Vasvari added SN76477 support to Space Invaders.
- 20th March     2000: Juergen Buchmueller fixed some SN76477 and Phoenix sound bugs.
- 0.36RC1            : Preliminary SN76477 emulation [Juergen Buchmueller].
- 16th February  2000: Zsolt Vasvari and Juergen Buchmueller added preliminary DAC and SN76477 sound to Bandido. Jürgen also fixed Asteroids Deluxe explosion sound.
- 14th February  2000: Juergen Buchmueller fixed some bugs in the SN76477 sound core, and added support for it to Crazy Balloon.
- 11th February  2000: Juergen Buchmueller added preliminary SN76477 analog/digital sound chip emulation to Stratovox / Speak & Rescue.
- GAMES: Space Invaders (Midway 1978), Galaxy War (Taito 1979), Ozma Wars (SNK 1979), Sheriff (Nintendo 1980)
- SOURCE: sound\sn76477.c
- PCB: TMS SN76477N (Laserbat), SN76477N (Laserbat), TI76477 (Speakres), SN76477 DIP28 (Malzak), 76477 (Clayshoo)


S3.2   SN76489

- 0.116u2             : Justin Kerk and Lord Nightmare updated a number of games to correctly use the SN76489 instead of the SN76496, which was a later design.
- 0.115u4            : Lord Nightmare fixed a number of games to explicitly use the SN76489 now that it behaves differently from the SN76496.
- 0.114u3            : Improved noise emulation in the SN76496 emulator. Added several variants which differ based on the noise generator and other parameters [Lord Nightmare].
- 21st March     2002: Olivier Galibert found the correct shift register operations for noise generators for both SN76489 and YM3812.
- GAMES: Chameleon (Jaleco 1983), Van-Van Car (1983), Time Pilot'84 (Konami 1984), Finalizer (Konami 1985), Super Cross 2 (1986)
- NOTES: The SN76489 noise generator uses a 15-bit shift register with taps on bits D and E, output on /E. It uses a 15-bit ring buffer for periodic noise/arbitrary duty cycle.
- SOURCE: sound\sn76496.c
- PCB: TI SN76489 PSGs (Chameleo), SN76489AN (Myhero), SN-76489 (Appoooh), 76489 (Chboxing, Sbugger), Texas J327A-SN76489AN (Ufosensi)


S3.21  SN76489A
- 0.114u3            : Improved noise emulation in the SN76496 emulator. Added several variants which differ based on the noise generator and other parameters [Lord Nightmare].
- NOTES: The SN76489A noise generator uses a 16-bit shift register with taps on bits D and F, output on F. It uses a 16-bit ring buffer for periodic noise/arbitrary duty cycle.
- SOURCE: sound\sn76496.c



S3.3   SN76496

- 0.114u3            : Improved noise emulation in the SN76496 emulator. Added several variants which differ based on the noise generator and other parameters [Lord Nightmare].
- 0.104u8            : Chris Law and Aaron Giles fixed second SN76496 on Congo Bongo to have the correct frequency.
- 0.104u4            : Adam Bousley added save states to the SN76496 sound chip for Sega System 1 games.
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the SN76496 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.95u2             : Sebastien Chevalier updated the SN76496 Write functions (according to the SN76489 document found on SMSPower).
- 0.34b3             : Nicola Salmoria rewritten the SN76496 emulator. This fixes speech in Choplifter.
- 0.31               : Tatsuyuki Satoh supported 16 bit samples in AY8910 and SN76496. Nicola Salmoria fixed sound in Exed Exes; it has one 8910 and two 76496, not two 8910.
- 0.30               : Tatsuyuki Satoh and Nicola Salmoria cleaned up the SN76496 emulation, now it is similar to the 8910 one and all games use Tatsuyuki's code. This affects several games, most notably the Mr. Do! series.
- 0.27               : Tatsuyuki Satoh make changes in SN76496 emulation (added SN76496UpdateB function to emulate 2 chips on 8 channel PCM sound cards)
- 0.18               : Nicola finally added some lousy, very inaccurate, noise to the 76496 emulator. This affects Lady Bug and Green Beret.
- NOTES: The SN76494 and SN76496 noise generator are probably identical in operation to the SN76489A. They have an audio input line which is mixed with the 4 channels of output.
- SOURCE: sound\sn76496.c
- GAMES: Lady Bug (Universal 1981), Mr Do (Universal 1982), Sindbad Mystery (Sega 1983), Kick Rider (1984), Return of the Invaders (Taito 1985)



S3.4   TMS36XX

- 15th March     2000: Juergen Buchmueller sent in yet another TMS36xx sound core update with some bugfixes and adjustments.
- 13th March     2000: Juergen Buchmueller fixed some problems in the TMS36xx sound core.
- 0.36RC2            : TMS36XX emulation [Juergen Buchmueller]. Juergen rewritten sound emulation in Phoenix, samples are no longer used.
- 12th March     2000: Juergen Buchmueller sent in a sound core for TMS36xx sound chips, and modified Phoenix, Pleiads, Naughty Boy and Monster Bash to use it.
- NOTES: The TMS36XX core support the MM6221AA (Phoenix - 1980), TMS3615 (Naughty Boy - 1982) and TMS3617 (Monster Bash - 1982).
- GAMES: Phoenix (Amstar 1980), Pleiads (Tehkan 1981), Monster Bash (Sega 1982)
- SOURCE: sound\tms36xx.c



S3.41  TMS3615

- 0.107u2            : Added sound\tms3615.c.
- GAMES: Laser Battle (Zaccaria 1981)
- SOURCE: sound\tms3615.c
- PCB: TMS3615-25 (Naughtyb), TMS 3615NS-28 (Laserbat)



S3.6   TMS57002

- NOTES: The TI TMS57002 is a effect DSP.
- GAMES: Konami System GX
- SOURCE: machine\konmigx.c - Emulation by Olivier Galibert
- PCB: TMS57002DPHA DSP, QFP80 (G-Darius, Raystorm), TMS570020PHA (Le2, RacinForce)






S4.    Atari

S4.1   TIA

- 0.111u2            : Nathan Woods changed TIA code to only allow initialization at init time.
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the TIA sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.68               : Added sound\tiasound.c and sound\tiaintf.c.
-  3rd April     2003: Stefan Jokisch sent in a driver for Tournament Table (Hardware is identical to the VCS2600 except for an extra 6532 chip).
- 28th July      2001: Added support for sample rates > TIA clock rate, through oversampling.
- 0.37b14            : Removed sound\tiasound.c and tiaintf.c.
- 30th October   1998: Modified for use in MESS by Dan Boris.
- 14th January   1997: Cleaned up sound output by eliminating counter reset.
- 10th September 1996: Atari TIA sound emulator [Ron Fries].
- SOURCE: sound\tiasound.c
- GAMES: Atari - Tournament Table (1978)


S4.2   POKEY

- 0.104u2            : Aaron Giles added save state support to the POKEY emulator.
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the POKEY sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.93               : Changed name 'Pokey' to 'POKEY'.
- 0.89u3             : Juergen Buchmueller attempted to make Pokey random number generator work better with recordings (not verified to improve things yet).
- 0.84u5             : MikeJ fixed subtle behavior in the ALLPOT handlers for the POKEY when held in reset.
- 0.37b7             : Juergen Buchmueller fixed the Pokey emulation so that the Tempest reset bug is fixed, this time for real and forever.
- 28th August    2000: Juergen Buchmueller modified the Pokey RNG functions to finally work as they would in real hardware.
- 25th June      2000: Juergen Buchmueller fixed the Pokey sound core, and Tempest sounds a bit better now.
- 0.36RC1            : Juergen Buchmueller has rewritten the Pokey emulator for greater accuracy.
- 10th February  2000: Juergen Buchmueller fixed yet more stuff in the Pokey core.
-  5th February  2000: Juergen Buchmueller made some speedups to the Pokey core.
-  3rd February  2000: Juergen Buchmueller rewrote the Pokey code.
- 21st December  1999: Juergen Buchmueller fixed games using pokey from crashing when run without sound.
- 17th December  1999: Juergen Buchmueller fixed the Pokey POT emulation.
- 0.36b12            : The hangs in Tempest caused by the Pokey protection should now be fixed once and for all [Juergen Buchmueller].
- 0.35b2             : Zsolt Vasvari added Centipede (bootleg with AY8910 instead of Pokey).
- 0.34b8             : Juergen Buchmueller improved the Pokey emulation.
- 0.30               : Aaron Giles make same changes to the POKEY interface.
- 0.29               : Brad Oliver updated pokyintf.c to be more like 8910intf.c. Variable clock frequency, port callbacks, a clipping parameter, variable updates per frame. Most noticeably, Tempest has much improved sound with more frequent updates.
- 0.27               : Thanks to the precious information on the Pokey random number generator provided by Eric Smith, Hedley Rainnie and Sean Trowbridge, some problems with Centipede (start with 18 credits) and Tempest (hang after level 13) are now solved. Source: Brad Oliver wrote the new audio\pokyintf.c file. It handles most of the pokey interface to pokey.c. Rather than call milliped_sh_start() or whatever, call pokeyx_sh_start(), where x is the number of pokeys. It will keep track of the pokey count and use the appropriate clipping. I'm not sure 3 pokeys is a possible combination so there is no such pokey3_sh_start() routine.
- 0.16               : Brad Oliver modified pokey.c and pokey.h to make them more portable.
- 0.14               : Ron Fries provided a new version of his Pokey emulator which fixes problems in the interface with the SEAL audio library (signed vs. unsigned samples).
- 0.12               : Sound in Centipede, through Ron Fries' POKEY emulator. The biggest difference between the emulator and the original hardware is that the emulator emulates an 'ideal' POKEY chip. All output from the emulator is a based on a precise square wave, whereas the output from the original chip has decay.  Though the output is slightly different, I don't believe this difference is easily discernible. Another slight difference is the 17-bit/9-bit poly. Since the polynomial is large (2^17 bits), I choose to create the sample using a random number generator rather than a table. I don't believe this difference is significant. There are also a few differences which are introduced by aliasing. This is a direct result of using an output sampling rate which is not identical to the original sound rate.  It is most evident with high frequencies. A final difference is the lack of support for the High-Pass Filter functionality.  I plan to add this in a future release if necessary.
- NOTES: Based on original info found in Ron Fries' Pokey emulator, with additions by Brad Oliver, Eric Smith and Juergen Buchmueller, paddle (a/d conversion) details from the Atari 400/800 Hardware Manual. Polynome algorithms according to info supplied by Perry McFarlane.
- POKEY chip emulator
  rev 4.5: Changed the 9/17 bit polynomial formulas such that the values required for the Tempest Pokey protection will be found. Tempest expects the upper 4 bits of the RNG to appear in the lower 4 bits after four cycles, so there has to be a shift of 1 per cycle (which was not the case before). Bits #6-#13 of the new RNG give this expected result now, bits #0-7 of the 9 bit poly. Reading the RNG returns the shift register contents ^ 0xff. That way resetting the Pokey with SKCTL (which resets the polynome shifters to 0) returns the expected 0xff value.
      4.4: Reversed sample values to make OFF channels produce a zero signal. Actually de-reversed them; don't remember that I reversed them.
      4.3: For POT inputs returning zero, immediately assert the ALLPOT bit after POTGO is written, otherwise start trigger timer depending on SK_PADDLE mode, either 1-228 scanlines or 1-2 scanlines, depending on the SK_PADDLE bit of SKCTL.
      4.2: Half volume for channels which are inaudible (this should be close to the real thing).
      4.1: Default gain increased to closely match the old code. Random numbers repeat rate depends on POLY9 flag too! Verified sound output with many, many Atari 800 games, including the SUPPRESS_INAUDIBLE optimizations.
      4.0: MAME - Rewritten from scratch. 16bit stream interface. Serout ready/complete delayed interrupts. Reworked pot analog/digital conversion timing. Optional non-indexing pokey update functions.
      2.0: (31st Jan 1997 - Ron Fries) Support for multiple POKEY chips. The maximum supported is configured at compile time. An adjustable gain. The previous releases had a built-in gain of 64. A clipping option. Depending on the number of chips emulated and the configured gain, it is possible for the output to exceed 8-bits. Clipping can be enabled to prevent this, though it does increase the processing time.
- GAMES: Atari - Tempest (1980), Centipede (1980), Missile Command (1980)



S4.3   Atari Audio Board II
- 0.95u3             : Sebastien Volpe cleaned up error.log messages by correcting sound chip info in atarijsa.c.
- 0.89u5             : Fixed atarijsa memcpy [Mame32Plus].
- 27th April     2001: Aaron Giles fixed Atari JSA sound boards' CPU and sound chip frequency calculation.
- SOURCE: audio\atarijsa.c   Atari Audio Board II
- GAMES: Atari - Xybots (1987), Toobin (1988), Batman (1991)
- PCB: JSA Audio II PCB (Hydra), External sound board JSA III PCB with YM2151 and 6502A CPU (Roadriot)


S4.4   Jaguar
- 0.72u1             : Nathan Woods changed one of the #include paths in audio/jaguar.c (due to ProjectBuilder on Mac issues)
- GAMES: Atari CoJag hardware - Fishin' Frenzy (Warner 1995), Area 51 (Atari 1996), Maximum Force Duo v2.0 (Atari 1998)
- SOURCE: audio\jaguar.c


S5.    Yamaha

S5.1   FM Sound Core

- 0.116u3            : Zsolt Vasvari updated FM emulator to use mame_time instead of double. Removed old neogeo hack from FM code as it appears to no longer be necessary.
- 0.99u8             : Fixed pointer of FM channels and FM basic status.
- 0.99u7             : Aaron Giles removed gross cur_chip hack from the OPN emulator.
-  3rd August    2003: Jarek Burczynski fixed YM2608 initial values (after the reset), fixed flag and irqmask handling (YM2608) and fixed BUFRDY flag handling (YM2608).
- 16th June      2003: Jarek Burczynski improved various things in the FM core, including support of the ymdeltat module, x1bit/x8bit DRAM usage for ADPCM samples, memory read/write via deltat and ADPCM synthesis in slave mode.
- 14th June      2003: Jarek Burczynski implemented all of the YM2608 status register flags, implemented support for external memory read/write via YM2608 and implemented support for deltat memory limit register in YM2608 emulation.
- 22nd May       2003: Jarek Burczynski fixed LFO PM calculations (copy&paste bugfix).
-  8th May       2003: Jarek Burczynski fixed SSG support.
- 22nd April     2003: Jarek Burczynski implemented 100% correct LFO generator (verified on real YM2610 and YM2608).
- 15th April     2003: Jarek Burczynski added support for YM2608's register 0x110 - status mask.
- 12th December  2002: smf fixed a minor logging problem in the FM core.
-  1st December  2002: Jarek Burczynski fixed register addressing in YM2608, YM2610, YM2610B chips. (verified on real YM2608). The addressing patch used for early Neo-Geo games can be removed now.
- 26th November  2002: Jarek Burczynski and Nicola Salmoria recreated YM2608 ADPCM ROM using data from real YM2608's output. Added emulation of YM2608 drums. Output of YM2608 is two times lower now - same as YM2610 (verified on real YM2608).
- 16th August    2002: Jarek Burczynski binary exact Envelope Generator (verified on real YM2203); identical to YM2151, corrected 'off by one' error in feedback calculations (when feedback is off), corrected connection (algorithm) calculation (verified on real YM2203 and YM2610).
-  8th February  2002: Aaron Giles fixed the bug in FM timers which affected Final Fight and lots of other games.
- 18th December  2001: Jarek Burczynski added SSG-EG support (verified on real YM2203).
- 14th August    2001: Jarek Burczynski greatly improved the accuracy of the various FM sound chip emulators.
- 12th August    2001: Jarek Burczynski corrected sin_tab and tl_tab data (verified on real chip), feedback calculations (verified on real chip), phase generator calculations (verified on real chip), envelope generator calculations (verified on real chip) and FM volume level (YM2610 and YM2610B). Changed YMxxxUpdateOne() functions (YM2203, YM2608, YM2610, YM2610B, YM2612), this was needed to calculate YM2610 FM channels output correctly. (Each FM channel is calculated as in other chips, but the output of the channel gets shifted right by one *before* sending to accumulator. That was impossible to do with previous implementation).
- 23rd July      2001: Jarek Burczynski and Nicola Salmoria corrected YM2610 ADPCM type A algorithm and tables (verified on real chip)
- 11th June      2001: Jarek Burczynski corrected end of sample bug in ADPCMA_calc_cha(). Real YM2610 checks for equality between current and end addresses (only 20 LSB bits).
- 28th May       2001: Tatsuyuki Satoh fixed the bad sound frequency in games which use the Yamaha sound chips.
- 31st May       2001: Tatsuyuki Satoh added state saving support to the FM sound core.
- 24th May       2001: Jarek Burczynski re-submitted an update to the FM sound core.
- 0.36b7             : Several improvements to FM sound emulators. This also fixes crashes in some Jaleco Mega System 1 games [Tatsuyuki Satoh].
-  4th October   1999: Tatsuyuki Satoh sent in an update to his FM core with still incomplete LFO support (intro of Rock 'n Rage needs this) and some other bugfixes.
- 12th April     1999: Tatsuyuki Satoh has updated the FM engine, adding preliminary support for YM-2608.
- 23rd February  1999: Tatsuyuki Satoh has updated the FM sound engine, mainly speeding up YM-2610 and fixing things.
-  9th December  1998: Hiro-shi changed ADPCM volume (8->16, 48->64), replaced ym2610 ch0/3 (YM-2610B), init cur_chip (restart bug fix), changed ADPCM_SHIFT (10->8) missing bank change 0x4000-0xffff, added ADPCM_SHIFT_MASK and changed ADPCMA_DECODE_MIN/MAX.
-  8th December  1998: Hiro-shi renamed ADPCMA -> ADPCMB, ADPCMB -> ADPCMA, moved ROM limit check.(CALC_CH? -> 2610Write1/2), tested program (ADPCMB_TEST), moved ADPCM A/B end check, ADPCMB repeat flag(no check), changed ADPCM volume rate (8->16) (32->48).
- 0.34b6             : [DOS] Nicola replaced the -fm option with -ym2203opl. Added -noym3812opl to use the digital emulation of the YM3812 instead of the SoundBlaster OPL chip. Note that with -noym3812opl you also need external drum samples. FULL sound support in the NeoGeo games, FM synth and ADPCM samples, on 90% of games using the YM2610 emulator.
- 0.34b2             : Tatsuyuki Satoh updated the FM emulation and the way the 8910 updates its buffers. FM also has support for YM2608 and YM2612, though they are not compiled in.
- 0.30               : Tatsuyuki Satoh added YM2203 emulation not using the SoundBlaster OPL3 chip. This is more accurate than the previous one, which used the SoundBlaster OPL chip, however it is also slower. You can still revert to the old behavior using the -fm command line option. Nicola added partial emulated sound in Bubble Bobble (only the YM2203 chip, therefore only some sound effects - no music).
- 0.23               : "And there was MUSIC!". Thanks to Ishmair's FM engine, music is supported in Commando, Ghosts 'n Goblins, Diamonds. Since the synthesis is based on FM generation via OPL, you must have a SoundBlaster, Adlib, or compatible to get the music.
- 0.22               : Nicola added COMMANDO. Original Sound is done by YM2203 (FM synthesis) while now is done by 8910 (no FM). So music is not present.
- SOURCE: sound\fm.c


S5.2   YM2149

- 0.124u5            : Fixed AY-3-8910/YM2149 and derivatives envelope handling [Couriersud].
- NOTES: The Yamaha YM-2149 is a noise and square wave generator and is compatible (?) to the AY-3-8910. MAME uses the compatible AY-8910. The YM2149 has twice as many envelope steps (slightly higher quality), but MAME emulates the AY-8910 with the 2149's added quality so there's no difference.
- GAMES: Lode Runner (Irem 1984 - 2x), Gridiron Fight (Tehkan 1985 - 2x), Solomon's Key (Tecmo 1986 - 3x), Shanghai III (Sunsoft 1993)
- PCB: KC89C72 YM2149F (Ampoker2, Monglfir, Pool10, Soccernw), AM2149F (Tehkanwc), Yamaha YM2149F Qty 2 (Slapfigh), WB 5300 (American Poker), WB5300 (Cherry Master), Winbond WF19054 (Bmcbowl, Cherry Master II, Paranoia)


S5.3   YM2151

- 0.112u4            : Changed the YM2151 to prevent timer problems [Nicola Salmora, Lord Nightmare, Ernesto Corvi].
- 0.94u4             : BUT fix crash games using FM sound chips when you load state (sound\2151intf.c, 2203intf.c, 2608intf.c, 2610intf.c and 2612intf.c).
- 0.93               : Aaron Giles removed the YM2151 alternate version and kept only Jarek's around. Having two cores was confusing and caused problems.
- 0.89u1             : Temporarily disabled YM2151 save states until someone find out why its crashing in debug/symbol/map builds.
- 30th April     2002: Jarek Burczynski sent in significant improvements to both the YM3812 and YM2151 cores.
- 18th July      2002: Jarek Burczynski updated the YM2151 sound core, fixing a bug that caused corrupt sound when hitting the robot at the end of the first level in TMNT.
- 12th May       2002: Jarek Burczynski fixed a few inaccuracies in the YM2151 sound chip emulator.
- 20th February  2002: Jarek Burczynski sent in an improvement to the YM2151 sound emulation's LFO noise generator which makes the YM2151 emulation almost exactly sample-accurate to the original.
- 13th February  2002: Jarek Burczynski added oversampling to the YM2151 interface.
- 0.55               : Changed name 'YM-2151' to 'YM2151'.
- 29th August    2001: Jarek Burczysnki improved the YM2151 LFO emulation.
- 0.54               : Fixes to the YM2610 and YM2151 emulation, verified on the real chip [Jarek Burczynski].
- 20th August    2001: Jarek Burczynski further improved the accuracy of the YM2151 LFO emulation.
- 0.37b14            : Added sound\ym2151.txt.
-  3rd April     2001: Jarek Burczynski added state saving support to the YM2151 sound core.
- 28th December  2000: Yochizo fixed YM2151 frequency in the Toaplan2 driver.
-  9th October   2000: Yochizo re-applied the Toaplan2 driver updates, and fixed the YM2151 interface to be 16-bit.
- 15th July      2000: Juergen Buchmueller fixed a YM2151 bug affecting Shisen / Sichuan II.
- 20th June      2000: Bryan McPhail fixed some YM2151/OKIM6295 sound balance problems in several drivers.
- 20th May       2000: Jarek Burczynski fixed some YM2151 bugs.
- 0.36RC1            : Changed name 'YM2151a' to 'YM2151'. Improvements to the YM2151 emulator [Jarek Burczynski]. Only one of the two YM2151 emulators is linked, this is determined at compile time. The default is Jarek's, which is more accurate though a little slower. It can be replaced with Tatsuyuki's changing the makefile.
- 0.36b12            : Tatsuyuki Satoh fixed OPN and OPM output level. Unfortunately this means that all games using YM2203, YM2151 etc. need to be rebalanced.
-  6th December  1999: Jarek Burczynski rebalanced the YM2151 core.
- 14th November  1999: Tatsuyuki Satoh fixed LFO in YM-2151.
-  5th November  1999: Jarek Burczynski fixed a small bug in YM2151.
- 24th October   1999: Bryan McPhail added an original Tumblepop romset (with correct YM2151 sounds) to the driver.
- 0.36b7             : Aaron Giles fixed YM2151 sound board support for Joust 2. Jarek Burczynski improvements to the other YM2151 emulator too.
- 0.35b12            : Major improvements to Atari sound (e.g. speech in Toobin') [Aaron Giles].
- 12th February  1999: Nicola added YM2151 support for Street Fighter 1, but samples are still missing.
- 0.34b8             : Support for stereo output. This is implelemented in the YM2610 and in Tatsuyuki's YM2151. It can be used by other games, for example the Atari System 2 games (Paper Boy etc.) have two Pokeys, one per channel [Nicola Salmoria]. [DOS] Stereo sound support. It is a little slower than mono, to turn it off use -nostereo. Stereo is enabled only for YM2610 and YM2151 games. The others always use mono.
- 0.31               : New YM2151 emulator [Jarek Burczynski]. Tatsuyuki Satoh improved YM2203 and YM2151 emulator, and DAC interface, with 16 bit samples support.
- 0.30               : YM2151 emulation [Tatsuyuki Satoh].
- NOTES: The YM2151 has a CMS speech mode with internal timer.
- GAMES: Marble Madness (Atari 1984), Gauntlet (Atari 1985), WEC Le Mans (Konami 1986)
- PCB: BS901, DIP24  (RShark, Grdnstrm, Rapidfire), K-666 (Rbmk, Wbbc97), CA5101 (Finalttr), CA101 (Metlsavr), KA51 c9235 (28 pin IC - in 24 pin socket (2 legs outside socket on each side !!!)) (Hyperpac, 3in1, Suplup), 3569 9142s 827620r (Drgnbowl)



S5.4   YM2203

- 0.112u4            : Aaron Giles fixed crash when changing sample rates (YM2203 mainly).
- 0.94u4             : BUT fix crash games using FM sound chips when you load state (sound\2151intf.c, 2203intf.c, 2608intf.c, 2610intf.c and 2612intf.c).
- 0.93               : The YM2203/2608/2610 chips now pass a set of functions into the FM core with pointers to all the AY8910-compatibility routines, rather than relying on global pointers [Aaron Giles].
-  8th May       2003: Jarek Burczynski fixed a bug in the YM2203 core that caused a stuck tone in Desert Assault.
- 12th December  2002: Jarek Burczynski sent in an update to the FM sound chip emulators with support for YM2608 drums, perfect envelope generator in YM2203, YM2610, YM2608 and YM2612 and other small fixes.
- 16th August    2002: Jarek Burczynski - Binary exact Envelope Generator (verified on real YM2203); it is identical to YM2151. Corrected 'off by one' error in feedback calculations (when feedback is off). Corrected connection (algorithm) calculation (verified on real YM2203 and YM2610).
- 0.57               : Jarek Burczynski did SSG EG type support added to YM2203 emulation (which is now complete). This fixes hbarrel wave sound on start of level 1, and some sound effects in other games (e.g. Dark Seal).
- 21st December  2001: Jarek Burczynski added SSG EG type support to the YM2203 emulation, which fixes sounds in Heavy Barrel and Dark Seal.
- 30th November  2001: Aaron Giles improved the handling of AY8910 and YM2203 simultaneously.
- 0.55               : Changed name 'YM-2203' to 'YM2203'.
- 27th August    2001: Tatsuyuki Satoh added support for using AY8910 and YM2203 at the same time, making it possible to add correct sound in City Connection.
- 28th May       2001: Tatsuyuki Satoh fixed the bad sound frequency in games which use the Yamaha sound chips.
- 26th February  2001: Tatsuyuki Satoh sent in an update to the YM-2203 emulator, correcting a few parameters.
- 13th December  2000: Jarek Burczynski fixed YM2203 frequency calculation and added sound to Drive Out.
- 0.36b15            : Source: Added gain support to mixer.c, through the new MIXERG() macro (extension of MIXER()). Removed the gain filed from AY8910, YM2203, YM2610 structures.
- 0.36b12            : Tatsuyuki Satoh fixed OPN and OPM output level. Unfortunately this means that all games using YM2203, YM2151 etc. need to be rebalanced.
- 17th June      1999: Brad Oliver fixed YM2203 core to be multi-session friendly.
- 0.35b2             : Bryan McPhail fixed the YM2203 in Ghost Busters.
- 0.35b1             : Partial sound in The Real Ghostbusters. The YM2203 doesn't seem to work correctly [Nicola Salmoria].
- 0.34b6             : [DOS] Nicola replaced the -fm option with -ym2203opl. Added -noym3812opl to use the digital emulation of the YM3812 instead of the SoundBlaster OPL chip. Note that with -noym3812opl you also need external drum samples.
- 0.31               : Tatsuyuki Satoh improved YM2203 and YM2151 emulator, and DAC interface, with 16 bit samples support.
- 0.30               : Tatsuyuki Satoh added YM2203 emulation not using the SoundBlaster OPL3 chip. This is more accurate than the previous one, which used the SoundBlaster OPL chip, however it is also slower. You can still revert to the old behavior using the -fm command line option. Nicola added partial emulated sound in Bubble Bobble (only the YM2203 chip, therefore only some sound effects - no music).
- 0.23               : "And there was MUSIC!". Thanks to Ishmair's YM-2203 FM engine, music is supported in Commando, Ghosts 'n Goblins, Diamonds. Since the synthesis is based on FM generation via OPL, you must have a SoundBlaster, Adlib, or compatible to get the music.
- 0.22               : Nicola added COMMANDO. Original Sound is done by YM2203 (FM synthesis) while now is done by 8910 (no FM). So music is not present.
- NOTES: Yamaha FM Synthesis Sound Processor. Emulator JFF emulates the YM2203 chip via OPL3 chip (most Sound Blasters and clones are equipped with it. OPL3 can't really emulate the YM2203 chip, but by some fiddling one can get reasonable sound out of it.)
- PCB: YM2203, YM 2203, YM2203C DIP40 (Xsleena), YM2203CX (Bublbobl), TM2203 (Empcity, Shootout)


S5.5   YM2413

- 0.122u4            : Aaron Giles added save state support to YM2413.
- 0.94u5             : Angelo Salese added two new functions to the YM2413 sound chip: YM2413_register_port_0_msb_w() and YM2413_data_port_0_msb_w(), they are used by pkgnsh.
-  3rd March     2003: Jarek Burczynski sent in an update to the YM3812 sound core, fixing the same copy & paste bug that haunted the YM2413 core and another problem that occurred if the Y8950 support wasn't compiled in.
- 27th February  2003: Jarek Burczynski fixed a small copy & paste bug in the YM2413 sound core.
- 0.63               : All new, much better, YM2413 emulation [Jarek Burczynski].
- 18th November  2002: Jarek Burczynski sent in a massively improved YM2413 sound chip emulation.
- 0.61               : New YM-2413 emulator [Fabio R. Schmidlin, Charles Mac Donald].
- 13th June      2002: Sean Young submitted Fabio R. Schmidlin's improved YM2413 sound chip emulator.
- 0.37b12            : Added sound\ym2413.h and 2413intf.c. Source - Standalone YM2413 emulator, giving much better sound in e.g. Pang [Mitsutaka Okazaki, Sean Young].
-  1st February  2001: Sean Young integrated Mitsutaka Okazaki's YM2413 emulator (http://www.angel.ne.jp/~okazaki/ym2413/) into MAME, and all the games utilizing it sound much better now.
- 16th July      2000: Brad Oliver adapted Charles MacDonald's YM2413 emulation into MAME, though its accuracy is not yet known, so it might or might not replace the current emulation.
- 0.37b4             : Improved YM2413 emulation [Paul Leaman].
-  7th June      2000: Paul Leaman sent in a YM2413 update with proper frequency calculations.
- 19th May       1999: Paul Leaman did a bit of cleanup on the YM-2413 code.
- 0.34b5             : A beginning for a YM2413 emulator. It pushes data through the YM3812 [Paul Leaman, Ernesto Corvi].
- GAMES: Pang (Mitchell 1989), Buster Bros (Capcom 1989), Rampart (Atari 1990)
- PCB: YM2413  DIL18 (Ddenlovr), YM2413 DAC (Btlfield, Timesold), UM3567 9323-AM (Cabaret), UM3567 compatible with YM2413 (Grndtour), U3567 (Iqblock), 6868A DIP18 (Mjchuuka)



S5.6   YM2608

- 0.94u4             : BUT fix crash games using FM sound chips when you load state (sound\2151intf.c, 2203intf.c, 2608intf.c, 2610intf.c and 2612intf.c).
- 0.93               : The YM2203/2608/2610 chips now pass a set of functions into the FM core with pointers to all the AY8910-compatibility routines, rather than relying on global pointers [Aaron Giles].
- 0.70u2             : Jarek Burczynski makes various sound improvements to YM2610, YM2608 and Y8950, inspired by Frits Hilderink (NLMSX emulator author). Inspired by Frits Hilderink (NLMSX emulator author) Jarek attempted to improve support of the ymdeltat module for the status registers (YM2610,YM2608,Y8950), implement x1bit/x8bit DRAM usage for the ADPCM samples, implement memory read/write via deltat (Y8950 and YM2608) and ADPCM synthesis in 'slave' mode (CPU controlled, instead of memory based). Jarek made some tests but the changes are quite big so please test them before including. I'm sure the Y8950 will be tested by NLMSX authors too.
- 29th April     2003: Jarek Burczynski sent in a fix to the DELTA-T decoding in the YM2608 sound core, fixing the bad sounds in Mechanized Attack, and he fixed the LFO emulation in all of the FM chips.
- 0.63               : Jarek Burczynski added drum support in YM2608 emulation (check e.g. Tail 2 Nose). 
- 12th December  2002: Jarek Burczynski sent in an update to the FM sound chip emulators with support for YM2608 drums, perfect envelope generator in YM2203, YM2610, YM2608 and YM2612 and other small fixes.
-  1st December  2002: Jarek Burczynski - Fixed register addressing in YM2608, YM2610 and YM2610B chips (verified on real YM2608). The addressing patch used for early Neo-Geo games can be removed now.
- 26th November  2002: Jarek Burczynski and Nicola Salmoria - Recreated YM2608 ADPCM ROM using data from real YM2608's output which leads to added emulation of YM2608 drums. Output of YM2608 is two times lower now, same as YM2610 (verified on real YM2608),
- 0.37b3             : Aaron Giles fixed YM2608 adpcm support.
- 22nd May       2000: Aaron Giles fixed some YM2608 core bugs.
- 12th April     1999: Tatsuyuki Satoh has updated the FM engine, adding preliminary support for YM-2608.
- 0.34b2             : Tatsuyuki Satoh updated the FM emulation and the way the 8910 updates its buffers. FM also has support for YM2608 and YM2612, though they are not compiled in.
- GAMES: World Cup '90 (Tecmo 1989), Tail to Nose (V-System Co. 1989), Hatris (Video System Co. 1990)
- PCB: YM2608B (Mechatt, Tail2nos)



S5.7   YM2610

- 0.122u1            : Philip Bennett fixed a YM2610 regression: Changed 'void refresh_fc_eg_chan(FM_CH *CH )' from INLINE to static to work around gcc 4.2.1 codegen bug (sound\fm.c).
- 0.94u4             : BUT fix crash games using FM sound chips when you load state (sound\2151intf.c, 2203intf.c, 2608intf.c, 2610intf.c and 2612intf.c).
- 0.93               : The YM2203/2608/2610 chips now pass a set of functions into the FM core with pointers to all the AY8910-compatibility routines, rather than relying on global pointers [Aaron Giles].
- 0.84               : Blip fixed save/restore crash in the YM2610 emulation (sound\fm.c).
- 27th November  2003: Leon van Rooij fixed the state saving support in the YM2610 sound core.
- 0.70u2             : Jarek Burczynski makes various sound improvements to YM2610, YM2608 and Y8950, inspired by Frits Hilderink (NLMSX emulator author). Inspired by Frits Hilderink (NLMSX emulator author) Jarek attempted to improve support of the ymdeltat module for the status registers (YM2610,YM2608,Y8950), implement x1bit/x8bit DRAM usage for the ADPCM samples, implement memory read/write via deltat (Y8950 and YM2608) and ADPCM synthesis in 'slave' mode (CPU controlled, instead of memory based). Jarek made some tests but the changes are quite big so please test them before including. I'm sure the Y8950 will be tested by NLMSX authors too.
- 0.69b              : Aaron Giles fixed a problem which caused sound to break in games using a YM2610 using the new timer system.
-  2nd June      2003: Aaron Giles fixed a bug in the YM2610 timers.
- 22nd May       2003: Jarek Burczynski fixed a bug in the YM2610 sound chip emulator that caused problems in the Magician Lord intro for example.
- 14th April     2003: Jarek Burczynski fixed LFO support in an YM2610-only compilation.
- 12th December  2002: Jarek Burczynski sent in an update to the FM sound chip emulators with support for YM2608 drums, perfect envelope generator in YM2203, YM2610, YM2608 and YM2612 and other small fixes.
-  1st December  2002: Jarek Burczynski - Fixed register addressing in YM2608, YM2610 and YM2610B chips (verified on real YM2608). The addressing patch used for early Neo-Geo games can be removed now.
- 0.55               : Changed name 'YM-2610' to 'YM2610'.
-  2nd September 2002: ElSemi submitted a fix for the YM2610 Delta-T samples which fixes the sound in the KOF99 how to play screen and in the Shock Troopers intro.
-  7th December  2001: Paul Hampson submitted a modification that allows the YM2610 sound chip to be compiled without needing YM2610B as well.
-  2nd October   2001: Stefan Jokisch fixed a bug in the YM2610 sound chip emulation which caused missing sounds in Chase H.Q.
- 0.54               : Jarek Burczynski fixes to the YM2610 and YM2151 emulation, verified on the real chip.
- 17th July      2001: Nicola Salmoria improved the YM2610 ADPCM algorithm.
- 16th September 2000: David Graves abstracted the Taito YM2610 sound interface.
- 0.36b15            : Source: Added gain support to mixer.c, through the new MIXERG() macro (extension of MIXER()). Removed the gain filed from AY8910, YM2203, YM2610 structures.
- 0.35b6             : Improvements to the YM2610 timers, added an interface for external volume control [Tatsuyuki Satoh].
- 0.35b4             : Improved the YM2610 emulation [Tatsuyuki Satoh].
- 23rd February  1999: Tatsuyuki Satoh has updated the FM sound engine, mainly speeding up YM-2610 and fixing things.
- 0.34b8             : Support for stereo output. This is implelemented in the YM2610 and in Tatsuyuki's YM2151. It is a little slower than mono, to turn it off use -nostereo.
- 0.34b6             : YM2610 emulator [Hiromitsu Shioya]. Ernesto Corvi support sound in Super Space Invaders (YM-2610). FULL sound support in the NeoGeo games, FM synth and ADPCM samples, on 90% of games using the YM2610 emulator.
- SOURCE: sound\2610intf.c
- GAMES: Taito - Superman (1988), Rambo III (1989), Sonic Blast Man (1990), Warrior Blade (1991), Slap Shot (1994)



S5.71  YM2610B

-  1st December  2002: Jarek Burczynski - Fixed register addressing in YM2608, YM2610 and YM2610B chips (verified on real YM2608). The addressing patch used for early Neo-Geo games can be removed now.
-  7th December  2001: Paul Hampson submitted a modification that allows the YM2610 sound chip to be compiled without needing YM2610B as well.
- SOURCE: sound\2610intf.c
- Games: Taito - Sonic Blast (1990), Puzzle Bobble (1994), Magical Date (1996)
- PCB: YM2610B (Pbobble, Sbm, Silentd, Warriorb)



S5.8   YM2612

- 0.120u3            : Some build-related improvements to the sound cores [Atari Ace]: The YM2612 core now can be built without including the YM3438 core.
- 0.107u3            : David Haywood adjusted the DAC sound level on the 2612 to something more reasonable (sound\fm.c).
- 0.94u4             : BUT fix crash games using FM sound chips when you load state (sound\2151intf.c, 2203intf.c, 2608intf.c, 2610intf.c and 2612intf.c).
- 12th December  2002: Jarek Burczynski sent in an update to the FM sound chip emulators with support for YM2608 drums, perfect envelope generator in YM2203, YM2610, YM2608 and YM2612 and other small fixes.
- 20th August    1999: Jim Hernandez fixed System18 sound chip frequency.
-  7th August    1999: Andrew Prime added PCM sound to System 18 and 3D games (using Hiromitsu Shioya's PCM code).
- 10th March     1999: Tatsuyuki Satoh has sent in an interface for YM-2612 (System18 games use this sound chip).
- 0.34b2             : Tatsuyuki Satoh updated the FM emulation and the way the 8910 updates its buffers. FM also has support for YM2608 and YM2612, though they are not compiled in.



S5.9   YM3012

-  2nd June      1999: Nicola fixed Street Fighter ADPCM sound and added the second channel for the YM3012 chip.
- NOTES: Yamaha YM3012 16bit serial DAC/Volume control chip (DIP8)
- GAMES: Gryzor (Konami 1987), Rainbow (Taito 1987)
- PCB: YM3012 (Archrivl, Pururun, Silkroad), YM3012A (SF2), Cypress CY5002 (Metmqstr), Cypress CY5001 (Gotcha), CA5102  DIP16 (RapidFire, Gotcha), BS902 (Bubl2000)



S5.10  YM3014

- NOTES: D/A converter, serial input, 16bit D/range
- GAMES: Iron Horse (Konami 1986), Bubble Bobble (Taito 1986 - 2xYM-3014), Teenage Mutant Ninja Turtles (Konami 1989)
- PCB: YM3014 DIP8 (GulfWar2), Y30148 (Csilver, Passsht, Shanghai), U6614 (Multchmp), U6614B (Svolley), K-664 (Rbmk, Wbbc97), KS8002 (Magicbub), KA12 = Compatible to Y3012 or Y3014 (Vamphalf, 3in1semi), ka12 c9235 (3in1semi)



S5.11  YM3016

- NOTES: Like YM3012 a volume control chip.
- GAMES: Dynamite League (Taito 1990), Sel Feena (East Technology 1991), Turbo Force (Video System Co. 1991), Welltris (Video System Co. 1991)
- PCB: Y3016-F (Nost), YM3016D (Turbofrc), YM3016F (Aquajack)



S5.12  YM3438

- 0.55               : Changed name 'YM-3438' to 'YM3438'.
- NOTES: The YM-3438 emulation comes from Li Jih Hwa and Thierry Lescot System 16 emulator and YM3438 information are from Hiromitsu Shioya and Jim Hernandez.
- NOTES: The Sega C/C2 system uses a YM3438 (compatible with the YM2612) for FM based music generation.
- GAMES: Shadow Dancer (Sega 1989), Alien Storm (Sega 1990), Blocken (Visco 1994)
- SOURCE: sound\2612intf.c



S5.13  YM3526

- 0.108u4            : Vas Crabb added save state support for YM3526.
- 0.60               : Complete rewrite of YM3812/YM3526/Y8950 emulation, verified on the real chip [Jarek Burczynski].
- 0.55               : Changed name 'YM-3526' to 'YM3526'
- 0.36b1             : New digital YM3812/YM3526 emulator (in the DOS version, use -noym3812opl to enable it). It doesn't support the rhythm section yet, but is overall better than the old one [Tatsuyuki Satoh].
- 0.34b5             : YM3812 and YM3526 software emulator. In the DOS version it is disabled because we are using the 100% compatible SoundBlaster OPL chip [Carl-Henrik Skårstedt]. A beginning for a YM2413 emulator. It pushes data through the YM3812 [Paul Leaman, Ernesto Corvi].
- GAMES: SNK - ASO (1985), Athena (1986), Bermuda Triangle (1987)


S5.14  YM3528
- NOTES: MAME uses the YM3526 instead of the YM3528.
- Games: Bubble Bobble (Taito 1986), Sei Senshi Amatelass (Nichibutsu 1986) and Western Express (Data East 1986)



S5.15  YM3812

- 0.120u3            : Some build-related improvements to the sound cores [Atari Ace]: BUILD_ instead of HAS_ macros are used in 3812intf.c for consistency with the other fm cores.
- 0.108u4            : Vas Crabb added save state support for YM3812.
-  3rd March     2003: Jarek Burczynski sent in an update to the YM3812 sound core, fixing the same copy & paste bug that haunted the YM2413 core and another problem that occurred if the Y8950 support wasn't compiled in.
- 20th July      2002: Jarek Burczynski fixed another small bug in the YM3812 sound chip emulation.
- 0.60               : Complete rewrite of YM3812/YM3526/Y8950 emulation, verified on the real chip [Jarek Burczynski].
- 30th April     2002: Jarek Burczynski sent in significant improvements to both the YM3812 and YM2151 cores. YM3812: Fixed simultaneous usage of all three different chip types. Used real sample rate when resample filter is active.
- 26th March     2002: Jarek Burczynski did a major improvement on the YM3812 sound chip emulation, making it much more accurate than before by comparing its output with the real chip.
- 21st March     2002: Olivier Galibert found the correct shift register operations for noise generators for both SN76489 and YM3812.
- 0.55               : Changed name 'YM-3812' to 'YM3812'.
- 0.36b2             : Tatsuyuki Satoh further improved the YM3812 emulator, especially the rhythm section (check Snow Bros!). [DOS] -noym3812opl is now the default (this won't have effect unless you delete mame.cfg) [Nicola Salmoria].
- 30th July      1999: Tatsuyuki Satoh updated his YM-3812 core yet again, fixing crashes.
- 23rd July      1999: Tatsuyuki Satoh fixed yet another YM-3812 emulator bug and fixed rhythm sound handling in the YM-3812 emulator.
- 22nd July      1999: Tatsuyuki Satoh added dual chip support to the YM-3812 emulator, and fixed some crashes.
- 21st July      1999: Tatsuyuki Satoh fixed some YM-3812 IRQ problems, for example with Raiden.
- 0.36b1             : New digital YM3812/YM3526 emulator (in the DOS version, use -noym3812opl to enable it). It doesn't support the rhythm section yet, but is overall better than the old one [Tatsuyuki Satoh].
- 16th July      1999: Tatsuyuki Satoh fixed Toki YM-3812 sound.
- 14th July      1999: Tatsuyuki Satoh sent in a totally new YM-3812 emulator which sounds a lot better than the old one.
-  2nd June      1999: Nicola fixed Street Fighter ADPCM sound and added the second channel for the YM3812 chip.
- 0.34RC1            : When using the SoundBlaster OPL chip, YM3812 commands are converted to play at the correct frequency [Carl-Henrik Skårstedt].
- 0.34b6             : [DOS] Nicola replaced the -fm option with -ym2203opl. Added -noym3812opl to use the digital emulation of the YM3812 instead of the SoundBlaster OPL chip. Note that with -noym3812opl you also need external drum samples.
- 0.34b5             : YM3812 and YM3526 software emulator. In the DOS version it is disabled because we are using the 100% compatible SoundBlaster OPL chip [Carl-Henrik Skårstedt]. A beginning for a YM2413 emulator. It pushes data through the YM3812 [Paul Leaman, Ernesto Corvi].
- 0.33b7             : The YM3812 emulator still passes commands to the Sound Blaster OPL chip, but it handles timers in software. osd_ym3812_status and osd_ym3812_read removed [Aaron Giles].
- GAMES: Armed Formation (Nichibutsu 1988 - YM3812), Out Zone (Toaplan 1990 - YM3812), Break Thru (Data East 1986 - YM3526)
- PCB: YM3812 (OPL2) (Ikari3, Prehisle), YM 3812 (Ghostb, Gondo), U6612 (Crospang, Multchmp), 6564L (SOP24)(Chindrag, Drgnwrld), KS8001 (Nmg5, Magicbub)



S5.16  YMF262
- 23rd April     2003: Jarek Burczynski sent in some minor fixes to the YMF262 sound core.
- 0.66               : Added sound\ymf262.c and \262intf.c. YMF262 emulator [Jarek Burczynski].
-  3rd March     2003: Jarek Burczynski submitted the first version of the YMF262 emulator and Tecmo System driver with a debug function that was used to test it. Thanks to Olivier Galibert and Chris Hardy for YMF262 and YAC512 chips and to Stiletto for the datasheets.
- NOTES: The soundblaster cards used the YMF262 for MIDI (OPL3).
- GAMES: Tecmo System - Deroon DeroDero (1996), Touki Denshou - Angel Eyes (1996)



S5.17  YMF268-F
- NOTES: MAME uses the YMF278B instead of the YMF268-F.
- GAMES: Psikyo - Sol Divide (1997), Taisen Hot Gimmick (1997)



S5.18  YMF271

- 0.104u2            : Nathan Woods added state save support to the Jaleco MegaSystem 32 and YMF271 sound core.
- 0.99u3             : Ville Linde fixed all the volume table calculations in the YMF271 core.
- 0.99u2             : Fixed more YMF271 issues [Ville Linde]: The mix buffer pointer was not being reset between two 2-operator FM sounds, causing missing sounds. Fixed some bugs in the phase modulation of FM sounds and added low-frequency oscillator (LFO).
- 0.99u1             : Major improvement to the YMF271 sound core [Ville Linde]: Fixed timer A and note pitch calculation. Added envelope generator, stereo panning and fixed other volume calculations and FM sound generation.
- 0.84u3             : Ville Linde added support for external read/write handlers to the YMF271 (required for SPI flash ROM updating mode).
- 0.84               : Toshiaki Nijiura improved YMF271C sound quality.
- 0.81u8             : Ville Linde fixed YMF271 pitch, this improves music in Brave Blade.
- 0.77u3             : Added sound\ymf271.c. YMF271 sound core plus very preliminary hook up in ms32.c (only Desert War makes any sound at all and it doesn't really seem to be anything like correct, this is probably due to a combination of z80 communication and banking issues) [R. Belmont].
- 12th December  2003: R. Belmont sent in a YMF271 sound core and added it to the Jaleco Mega System 32 driver, but sound doesn't work in it yet.
- NOTES: The Yamaha YMF271-F "OPX" emulator based in part on YMF278B emulator by R. Belmont and O. Galibert.
- SOURCE: sound\ymf271.c
- GAMES: Jaleco - Best Bout Boxing (1994), Desert War (1995), P-47 Aces (199x)
- PCB: YMF271-F, QFP128 (Beastrzr, Rfjet), YMF-271-F (F1superb)



S5.19  YMF278B

- 0.79               : YMF278b update, improving sound in Asura Blade [R. Belmont].
- 0.69u3             : Bug fix to loop addressing on YMF278B which helps stablise the tuning on looped samples (noticable in parts of s1945 at least) [OpenMSX].
-  4th June      2003: R. Belmont forwarded a OpenMSX guys' fix for the loop addressing in the YMF278B sound chip emulation, improving some parts of Strikers 1945 music.
- 15th January   2003: R. Belmont fixed the pitch problem in the YMF278B sound chip, noticeable in the Strikers 1945 II coin input sound.
- 0.63               : R. Belmont fixed YMF278B emulation. 
- 12th December  2002: R. Belmont fixed the YMF278B sound frequency in the Psikyo SH-2 systems and fixed a bug in it that caused missing sounds in Hot Debut.
- 0.62               : Added sound\ymf278b.c. Preliminary YMF278B emulation (missing FM support) [R. Belmont].
-  8th September 2002: R. Belmont fixed the missing bass and drum sounds in the YMF278B sound chip emulation.
- 18th August    2002: Olivier Galibert added preliminary envelope support to the YMF278B sound chip emulation and fixed the endlessly looping sounds. Sixtoe fixed the pitch in the YMF278B core.
- 12th August    2002: Olivier Galibert fixed the sample pitch in the YMF278B emulation, but some samples are still erroneously looping over and over.
- 11th August    2002: Olivier Galibert integrated R. Belmont's YMF278B sound chip emulation (FM not emulated yet) and Paul Priest's graphics fixes to the Psikyo driver, and Strikers 1945 is now playable with sound, though the sound is not entirely correct. Sound was also added to the Psikyo SH-2 driver, and sprite zoom in Aero Fighters was fixed.
- NOTES: The Yamaha OPL4 (YMF-278B), which is an OPL3 with a very powerful PCM section added. It's nothing at all like the YMZ-280, which is a very bare-bones ADPCM chip. The Yamaha 2MB YRW801 rom has the samples for the OPL4 (YMF-278B).
- SOURCE: sound\ymf278b.c
- GAMES: Psikyo - Strikers 1945 (1995), Sengoku Blade (1996), Space Bomber (1998)
- PCB: YMF278B-F, QFP80 (Bangball, Gunbird), YMF278 OPL4, QFP80 (Asurabld, Sbomberb)



S5.20  YMF286-K

- NOTES: The Yamaha YMF286-K is compatible to YM2610 (see psikyo.c) and not yet emulated by MAME.
- GAMES: Psikyo - Gun Bird (1994), Battle K-Road (1994)
- PCB: YMF286-K (Btlkroad, Gunbird, Nost, S1945), YMF286K (Blzntrnd), YMF 286-K (Mcatadv)



S5.21  SCSP

- 0.125              : Kingshriek fixed an envelope corner case in the SCSP.
- 0.124u1            : Fixed encoding/decoding of negative denormal floats in the AICA/SCSP DSP. Shouldn't actually affect any games [kingshriek, Deunan Knute].
- 0.122u8            : Further improvements to SCSP FM [kingshriek].
- 0.122u7            : Preserve fractional part of sample offset when looping in SCSP. Fixes remaining pitch stability problems. Fixed minor issue with timers B&C expiring [kingshriek, R. Belmont].
- 0.122u6            : Kingshriek removed unnecessary check that could cause SCSP hangs in Guardian Force.
- 0.122u4            : Implemented decent-sounding FM in SCSP [kingshriek].
- 0.122              : More major SCSP fixes [kingshriek]: Rewrote much of the interpolation code. Improved key-rate scaling calculation. Fixed playback of non-looping samples with a zero loop-end address. Fixed backwards looping mode so that it initially reads forward until encountering the loop-start address. Preliminary but reasonable-sounding FM support. Fixed overflow in frequency calculation. Improved FM, but it's disabled for now because it doesn't sound right yet. Improved DSP wet/dry mix (should be correct now). Fixed a minor LPSLNK problem.
- 0.121u4            : SCSP updates [kingshriek]: Added effect-in mixer. Added DSP floating-point support. Added bounds check to the DECAY1 EG output. Fixed the saw PLFO waveform. Fixed loop points so loops no longer go out of tune/include garbage samples.
- 0.121u3            : SCSP improvements [kingshriek]: Added logarithmic envelope table. Set envelope level to start at 0x17f in the ATTACK state (0x3ff-0x280) as per Neill's notes. Changed EG_SHIFT from 8 to 16 - more precision is needed to differentiate the longer decay envelope times. In the DECAY1-->DECAY2 transition, changed the "<=" to "<". Decreased the output of the effect out mixer a bit. Fixed unaligned 16-bit samples. Prevented keyoffs from killing slots when already in the release state. Envelope steps in the attack state are apparently exponential. To account for this, I change the envelope output to linear for attacks. Change the release rate calculation to use the decay table instead of the attack one.
- 0.120u4            : SCSP fixes [kingshriek]: Fixed DECAY1 envelope state to not exit immediately. Improved support for LPSLNK and SBCTL. Fixed panning calculation bug. Fixed case where key-rate scaling is off.
- 0.120u3            : Some build-related improvements to the sound cores [Atari Ace]: The SCSP dependency on mame/drivers/stv.c was removed allowing it to built independent of the driver.
- 0.120u1            : R. Belmont fixed a corner case in the SCSP involving timers which are polled with their IRQ enable shut off.
- 0.119u4            : More SCSP improvements [El Semi]: Fixed endianness issue on 8-bit samples and added interpolation. Disabled modulation attempt (should fix the crash problems). Tweeked pitch calculation.
- 0.119u3            : R. Belmont fixed broken SCSP from last update.
- 0.119u2            : SCSP improvements [R. Belmont, ElSemi]: Fixed issue with changing the pitch of an active voice set to backwards or bidirectional loop. Removed fake reverb. Fixed internal DSP to operate properly. Rewrote timers and interrupt handling. Fixed operation when 2 SCSPs are present.
- 25th September 2007: R. Belmont - ElSemi and I have been fixing up the SCSP emulation in MAME lately due to the emergence of .SSF (Saturn/ST-V) music rips. He's still working out why samples in Radient Silvergun get overdriven all to heck, but in the meantime I've done the following: * Fixed the effects DSP to work properly in MAME - the kick drum in Shienryu now has the proper reverb applied, and this fixes missing sounds/instruments in several ST-V games. It also fixed a Saturn Qsound demo disc that boots over in MESS. * Rewrote the timers to use MAME timers. This fixes missing sound in a few ST-V games and gives Die Hard Arcade correct tempo. It also eliminates the IRQ storms you may have seen running ST-V games with -oslog. * Fixed some IRQ trouble. This got sound working again in Model 2A games, like Dead or Alive.
- 0.119u1            : SCSP fixes [R. Belmont]: Fix writes to the hole in the SCSP address space (0x430 to 0x5ff) to not trash global registers. Fixed SCSP DMA to not read random memory for its' registers.
- 0.113u4            : R. Belmont fixed crashes in some games using the SCSP.
- 0.113u3            : David Haywood fixed crashing bugs in SCSP emulation.
- 0.112              : R. Belmont fixed SCSP DSP RAM initialization.
- 0.111u6            : ElSemi added preliminary support for the built-in effects DSP in the SCSP, which lots of games use for reverb, QSound and other effects.
- 0.97u1             : Ville Linde fixed a minor bug in the SCSP timer handling.
- 0.93               : Changed name 'YMF292-F_SCSP' to 'SCSP'.
- 0.88               : Fixed undersized array causing stack trashing in YMF292-F SCSP (thanks to Mame32Plus).
- 0.81u9             : SCSP Update [ElSemi]: Fixed envelope rates to be correct, added key rate scaling and ringbuffer support.
- 0.77u3             : SCSP updates [Elsemi, R. Belmont].
-  3rd December  2003: ElSemi added support for per-voice gain parameters in the SCSP sound core, improving the sound balance.
- 0.77u2             : SCSP fixes (improves music in some games a little) [ElSemi / R. Belmont].
- 27th November  2003: ElSemi fixed the erratic static sounds in the SCSP sound core.
- 26th November  2003: R. Belmont and ElSemi fixed various bugs in the SCSP sound core, improving the sound greatly in the ST-V driver.
- 0.76u2             : R. Belmont fixed SCSP crash with -nosound.
- 0.76u1             : Added sound\scsp.c and sound\scsplfo.c.
- 25th October   2003: R. Belmont added ElSemi's SCSP sound chip emulator to the ST-V driver, but the sound and music only works properly in Shienryu.
- NOTES: SCSP = Saturn Custom Sound Processor. This chip has 32 voices. Each voice can play a sample or be part of an FM construct. Unlike traditional Yamaha FM chips, the base waveform for the FM still comes from the wavetable RAM. Unsupported: FM mode (no known Model 2/3, Saturn, or ST-V game uses it) and on-board programmable DSP and related functionality.
- GAMES: Virtua Fighter 2 (1995), Dead or Alive (1996)
- SOURCE: sound\scsp.c + sound\scspdsp.c (SCSP DSP handling) + sound\scsplfo.c (SCSP LFO handling)
- PCB: 315-5687, QFP128   YMF292-F LAKE (DeadOrAlive, Harley)



S5.22  AICA
- 0.125              : Kingshriek fixed an envelope corner case in the AICA.
- 0.124u1            : Fixed encoding/decoding of negative denormal floats in the AICA/SCSP DSP. Shouldn't actually affect any games [kingshriek, Deunan Knute].
- 0.123u2            : Added sound\aica.c/h, aicadsp.c/h and aicalfo.c. Added and hooked up AICA (NAOMI sound chip). NAOMI boot sounds now play. Since it's an SCSPx2 with ADPCM instead of FM it's already feature-complete except filter envelopes. A bug in the ARM7 core causes incorrect pan/level values to be computed in e.g. the NAOMI SOUND TEST menu. This is not a defect in the AICA [ElSemi, Deunan Knute, kingshriek, R. Belmont].
- 20th February  2008: R. Belmont - Samuele Zannoli is at it again. Here's a few SH-4 bugfixes and NAOMI I/O board improvements later... I've also further improved the NAOMI audio emulation. No new samples this time, sorry.
- 17th February  2008: R. Belmont - A couple of nice coincidences linked together today. First up, I submitted the AICA core to MAME so NAOMI now has sound. Secondly, MAME Italia dumped the NAOMI game Toy Fighter, which successfully gets into it's test mode (gameplay doesn't work). Test mode includes the sound test, and here's what it sounds like (http://rbelmont.mameworld.info/naomi.mp3), with the "load times" cut out to make things managable. The first thing you hear is the NAOMI boot chimes - they're supposed to not be very loud, so do not crank your volume when you hear them. After that is song #1 in Toy Fighter's sound test.
-  8th February  2008: R. Belmont - I'm working on emulation of the AICA (the Dreamcast/NAOMI/Hikaru sound chip) behind the scenes with kingshriek and Deunan Knute (the Makaron author). Since AICA is basically an SCSP with double the voices and a few feature tweaks the obvious basis was MAME's now reference-quality SCSP emulation. That's allowed us to get to a pretty good state in a short amount of time. The ADPCM sample type isn't quite right yet, but the basic functionality and effects DSP are working. You can take a listen to the current code playing a piece from Sakura Taisen 4 right here (http://rbelmont.mameworld.info/sakutai4.mp3). Note: This is via a DSF rip, it doesn't mean Dreamcast works in MESS.
- NOTES: The AICA (NAOMI sound chip) is effectively a 64-voice SCSP, with the following differences: No FM mode. A third sample format (ADPCM) has been added. Some minor other tweeks (no EGHOLD, slighly more capable DSP).
- SOURCE: sound\aica.c



S5.23  YMZ280B

- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the YMZ280B sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.102u4            : Ville Linde added external ram read and write handlers and data read port to YMZ280B.
- 0.99u2             : R. Belmont added support for "external memory address" registers on the YMZ280B, which can be used to read the contents of attached ROM or RAM.
- 0.93               : Sound System update [Aaron Giles]. This code is just terrible now compared to when I first wrote it!
- 17th April     2004: R. Belmont cleaned up Shiriru's YMZ280B update which has a little more accurate sound generation, fixing a music looping bug in the Super Kaneko Nova System driver.
- 12th December  2001: Aaron Giles fixed the crackling sounds in the YMZ280B sound chip emulation.
- 0.37b11            : Shiriru submitted some fixes to YMZ280B emulation.
- 12th December  2000: Shiriru submitted a few more fixes to the YMZ280B sound core.
-  6th December  2000: Shiriru submitted yet another Cave update with it's own sprite drawing functions and a fix to the YMZ280B sound core.
- 0.37b10            : Bernd Wiebelt fixed a YMZ280B bug that caused bad sound in the Cave games.
- 23rd November  2000: Bernd Wiebelt and Aaron Giles fixed several problems in the YMZ280B sound core.
- 0.37b5             : YMZ280B sound emulation, used by the Cave games [Aaron Giles].
- 27th June      2000: Aaron Giles sent in an update to the YMZ280B sound core with much better sound output.
- 22nd June      2000: Aaron Giles sent in a preliminary YMZ280B sound core, adding sound to Dangun Feveron, ESP Ra.De. and Uo Poko.
- GAMES: Cave - Dodonpachi (1997), Dangun Feveron (1998), Uo Poko (1998), ESP Ra.De. (1998)
- NOTES: YMZ280B is a 8 Channel PCM/ADPCM decoder
- PCB: YMZ280B-F, QFP64 (Bbakraid), YMZ280B  MONAURAL OUTPUT (Bishi), YMZ 280 B-F (Tetrisp2)


S5.24  YMZ284

- 0.114u4            : Aaron Giles added several AY8910 variants (AY8912, AY8913, AY8930, YM2149, YM3439, YMZ284 and YMZ294) so we can better specify the use of compatible but slightly different chips.
- NOTES: This chip is in place where a 40 pin chip is marked on PCB, possibly a replacement for some other 40 pin YM chip or a dummy chip?  MAME uses in Don Den Lover a AY-3-8910 for it !?
- PCB: YMZ284-D, DIL16 (Ddenlovr)


S5.25  AY-3-8910A

- 0.124u5            : Fixed AY-3-8910/YM2149 and derivatives envelope handling [Couriersud].
- 0.124u4            : AY-3-8910 rewrite [Couriersud]: Added a model to calculate mixing of channels with different resistance loads. Based on above, each channel may be assigned a different load in individual case, i.e. channels not tied together. Rewrote ay8910.c to make emulation simpler. Changed the config structure to include a flag field and output resistor loads. Updated all drivers affected. Added some "Todos" related to stuff I discovered when reading datasheets. Fixed a bug in disc_flt.c (konami filters).
- 0.114u4            : Changed name 'AY8910' to 'AY-3-8910A'. Aaron Giles added several AY8910 variants (AY8912, AY8913, AY8930, YM2149, YM3439, YMZ284 and YMZ294) so we can better specify the use of compatible but slightly different chips.
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the AY8910 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.93u1             : AY8910 no longer attempts to free memory allocated with auto_malloc [Aaron Giles].
- 0.93               : Changed name 'AY-3-8910' to 'AY8910'. Aaron Giles cleaned up the AY8910 interface for the YM chips to access this.
- 0.88               : Added save state support for AY8910 (thanks to Mame32Plus).
- 0.71               : Jarek Burczynski improved AY8910 noise generator.
- 30th June      2003: Jarek Burczynski and Olivier Galibert fixed the AY-3-8910 noise generator.
- 0.62               : Changed name 'AY-8910' to 'AY-3-8910'.
- 26th May       2002: Nicola Salmoria added a resample filter to the AY8910 emulator, but there isn't much of a quality improvement.
-  5th May       2002: Nicola Salmoria fixed the AY8910 emulator which caused missing sounds in some Irem M-62 system games.
- 30th November  2001: Aaron Giles improved the handling of AY8910 and YM2203 simultaneously.
- 27th August    2001: Tatsuyuki Satoh added support for using AY8910 and YM2203 at the same time, making it possible to add correct sound in City Connection.
- 16th August    2001: Zsolt Vasvari fixed AY8910's behaviour with Lock'n'Chase.
- 0.36b15            : Source: Added gain support to mixer.c, through the new MIXERG() macro (extension of MIXER()). Removed the gain filed from AY8910, YM2203, YM2610 structures.
- 0.35b2             : Zsolt Vasvari added Centipede (bootleg with AY8910 instead of Pokey).
- 0.34b2             : Tatsuyuki Satoh updated the FM emulation and the way the 8910 updates its buffers.
- 0.33b7             : Nicola changed the AY8910 emulation to generate three separate audio streams for the three channels instead of premixing them. This improves audio quality, increases the volume, and doesn't seem to affect performance too much.
- 0.31               : Tatsuyuki Satoh supported 16 bit samples in AY8910 and SN76496.
- 0.30               : Tatsuyuki Satoh, Fabrice Frances, Nicola Salmoria and Pete Ground completely rewritten the 8910 emulator and interface. This affects a lot of games, but the one which benefits more is Gyruss: it now plays many sound effects which were missing. Nicoal changed the way 8910 sound is updated: there's no longer a fixed "updates per frame" value defined in the driver, instead the audio is stream is generated whenever a chip register is written to (and at every vblank). This improves sound quality in several games.
- 0.27               : Nicola changed the 8910 sound chip emulation interface to allow updates more frequent than 60 per second. Also increased the sampling frequency to 44.1kHz. These changes provide dramatic improvements in sound quality, which you can appreciate in e.g. Gyruss and Pooyan.
- 0.20               : Source: Changed 8910intf to support 5 PSGs (Gyruss have them!). 8910_sh_update() doesn't emulate the 8910 audio if sound is disabled (the I/O ports of the chip are still emulated, since some games use them for input).
- 0.18               : Fixed bug in the 8910 emulation which caused noise to be played in Crazy Kong when you jumped over a barrel.
- 0.16               : Source: Nicola wrote some general purpose routines to simplify interface with the AY8910. They are in 8910intf.c.
- 0.13               : Nicola modified the 8910 emulator to set the clock frequency at run time, so sound in Crazy Climber and Crazy Kong is now back as normal.
- 0.12               : Since the 8910 emulator doesn't allow to set the clock frequency at runtime, I temporarily switched to using the default one. This affects sound in Crazy Climber, Crazy Kong and Bagman.
- 0.05               : By popular demand, reverted to the old AY-3-8910 emulation code.
- 0.04               : New experimental AY-3-8910 sound emulation code provided by Andy Milne. This sounds better in some places and worse in others. It is used by Crazy Climber, Crazy Kong and Bagman.
- 0.02               : AY-3-8910 emulation by Ville Hallik and Michael Cuddy. Based on Sound.c from Marat Fayzullin's fMSX distribution, original source by Ville Hallik 1996. Michael Cuddy working on emulator for the classic video game Gyruss. Gyruss, along with many other video games of the early to mid 1980's (the golden age of video games, IMHO), used a programmable sound generator (PSG) chip from General Instruments called the AY-3-8910. The 8910 PSG is capable of generating three voices, with limited envelope control as well as a random "noise" channel. The 8910 also has two 8-bit I/O ports which could be read under program control. There were two other chips in the family, the AY-3-8911, and AY-3-8912. Both of these chips are identical to the 8910 from the programmers perspective, with the exception that the 8911 only had 1 I/O port and the 8912 had none. The 8910 (the real one), maintains a set of 15 registers internally. Programming these registers is done through two or three memory mapped or I/O mapped locations. The first location (Base+0x00) is a latch into which a register number is written. The second location (Base+0x01) can then be written to update the value of a register. The third location (Base+0x02) can be read to fetch the value of a register. Some hardware implementations will map the second two locations onto the same address so that a read or a write to a single locations "does the right thing". The actual values that should be programmed into these registers is beyond the scope of this document. Datasheets are available from Jameco Electronics (which also still stocks this part -- although the part is out of production: ones that I bought on 12/1996 were made in mid 1984 so Jameco may not have them for long. I have a copy of the datasheet, and I might put it up on my web site if my scanner decides to cooperate. If you are writing an emulator (and you probably are, since this code is of limited use to anyone else), you need to study the schematic or ROMS of the machine that you are trying to emulate to determine which memory address or I/O port the PSG(s) are mapped to.
- GAMES: Crazy Climber (Nichibutsu 1980), Moon Patrol (Irem 1982), Hole Land (Tecfri 1984)
- PCB:  AY8910, AY-8910, AY3-8910, AY-3-8910A, AY-3-8912 (Bcruzm12, Boomrang, Offroad, Skylancr), AY38910/P (Fortecar), GI AY-3-8910 (Wtennis), GI AY-3-8913 (Mach3), GI8910 (Speakres), 8910/8912 combo (Carnival), AY3-8912 (Quizmstr)
- PCB: AY-3-8910 compatible ==> Winbond 95101 DIP40 (Mjchuuka, Mjdchuka), OKI M5255 9203 (Ampoker2)


S5.26  AY-3-8912A
- 0.114u4            : Aaron Giles added several AY8910 variants (AY8912, AY8913, AY8930, YM2149, YM3439, YMZ284 and YMZ294) so we can better specify the use of compatible but slightly different chips.
- NOTES: D-Day (Olympia 1982) uses two GI 8912  -> MAME uses two AY-8910.
- GAMES: Omega Race (Midway 1981)


S5.27  AY-3-8913A
- 0.115u1            : James Wallace corrected the pulse shape of the timer output in the MPU4 driver, and also correctly identified the AY sound chip as an AY8913.



S5.28  Y8950

- 0.108u4            : Vas Crabb added added partial save state support for the Y8950 sound chip.
- 0.76u2             : Jarek Burczynski fixes to the ymdeltat module. Generally - even more flags work correctly now. These changes are necessary for the msx sound emulation (Y8950) and were tested in nlmsx emulator by Frits Hilderink.
- 0.70u2             : Jarek Burczynski makes various sound improvements to YM2610, YM2608 and Y8950, inspired by Frits Hilderink (NLMSX emulator author). Inspired by Frits Hilderink (NLMSX emulator author) Jarek attempted to improve support of the ymdeltat module for the status registers (YM2610,YM2608,Y8950), implement x1bit/x8bit DRAM usage for the ADPCM samples, implement memory read/write via deltat (Y8950 and YM2608) and ADPCM synthesis in 'slave' mode (CPU controlled, instead of memory based). Jarek made some tests but the changes are quite big so please test them before including. I'm sure the Y8950 will be tested by NLMSX authors too.
-  3rd March     2003: Jarek Burczynski sent in an update to the YM3812 sound core, fixing the same copy & paste bug that haunted the YM2413 core and another problem that occurred if the Y8950 support wasn't compiled in.
- 0.60               : Fixes to Y8950 sample playback [Acho A. Tang]. Complete rewrite of YM3812/YM3526/Y8950 emulation, verified on the real chip [Jarek Burczynski].
- 0.36b11            : Y8950 emulator, used by Ginga NinkyouDen [Tatsuyuki Satoh].
- 20th November  1999: Tatsuyuki Satoh added support for Delta-T ADPCM of Y8950, and he modified Ginga Ninkyouden driver to use it.
- NOTES: The Y8950 is basically a YM3526 with ADPCM built in.
- GAMES: SNK - Victory Road (1986), Guerrilla War (1987), Chopper I (1988),  Jaleco - Ginga NinkyouDen (1987)


S5.29  YAC513
- NOTES: The Yamaha YAC513-M is a Audio Digital to Analog (D/A) converter.
- GAMES: Desert War (Jaleco 1995), Strikers 1945 II (Psikyo 1997), Gunbird 2 (Psikyo 1998) and the Jaleco MegaSystem 32.
- PCB: YAC513-M  SOIC16 (Cbaj, Rdft)


S5.30  YAC515
- GAMES: GunBarich (Psikyo 2001)
- PCB: YAC515-M (Gnbarich)


S5.31  YAC516
- NOTES: The Yamaha YAC516 is a Audio Digital to Analog converter.
- GAMES: Billiard Academy Real Break (1998), Battle Bakraid (8ing 1999), Gaia Crusaders (Noise Factory 1999)
- PCB: YAC516-E  SSOP24 (Bbakraid), YAC 516-E (Brvblade), YAC516-M DAC  SOIC16 (Rfjet)


S5.32  Yamaha DELTA-T ADPCM
- 0.76u2             : Fixes to the ymdeltat module. Generally even more flags work correctly now. These changes are necessary for the msx sound emulation (Y8950) and were tested in nlmsx emulator by Frits Hilderink [Jarek Burczynski].
-  3rd August    2003: Jarek Burczynski - Fixed BRDY flag implementation.
- 24th July      2003: Jarek Burczynski, Frits Hilderink - Fixed delault value for control2 in YM_DELTAT_ADPCM_Reset
- 22nd July      2003: Jarek Burczynski, Frits Hilderink - Fixed external memory support.
- 15th June      2003: Jarek Burczynski - Implemented CPU -> AUDIO ADPCM synthesis (via writes to the ADPCM data reg $08). Implemented support for the Limit address register. Supported two bits from the control register 2 ($01): RAM TYPE (x1 bit/x8 bit), ROM/RAM. Implemented external memory access (read/write) via the ADPCM data reg reads/writes. Thanks go to Frits Hilderink for the example code.
- 14th June      2003: Jarek Burczynski - Various fixes to enable proper support for status register flags: BSRDY, PCM BSY, ZERO. Modified EOS handling
-  5th April     2003: Jarek Burczynski - Implemented partial support for external/processor memory on sample replay
-  1st December  2002: Jarek Burczynski - Fixed first missing sound in gigandes thanks to previous fix (interpolator) by ElSemi. Renamed/removed some YM_DELTAT struct fields
- 28th December  2001: Acho A. Tang - Added EOS status report on ADPCM playback.
-  5th August    2001: Jarek Burczynski- now_step is initialized with 0 at the start of play.
- 12th June      2001: Jarek Burczynski - Corrected end of sample bug in YM_DELTAT_ADPCM_CALC. Checked on real YM2610 chip - address register is 24 bits wide. Thanks go to Stefan Jokisch (stefan.jokisch@gmx.de) for tracking down the problem.
- NOTES: YAMAHA DELTA-T ADPCM sound emulation is used by fmopl.c (Y8950) and fm.c (YM2608 and YM2610/B). Base program is YM2610 emulator by Hiromitsu Shioya.
- SOURCE: sound\ymdeltat.c




S6.    Bally/Midway/Sente

S6.1   Astrocade

- 14th April     1999: Juergen Buchmueller fixed a Z80 bug which affected Astrocade emulation (on the MESS side).
- 0.34b4             : Frank Palazzolo support emulation of the Astrocade sound chip (Gorf, Wizard of Wor, etc.)
- NOTES: Driver by Frank Palazzolo. Portions copied from the Pokey emulator by Ron Fries
- SOURCE: sound\astrocde.c
- GAMES: Midway - Wizard of Wor (1980), Extra Bases (1980), Gorf (1981)


S6.2   CEM3394
- 0.104u3            : Aaron Giles added oversampling and save state support to the CEM3394 emulator.
- NOTES: CEM-3394 is an analog synth chip.
- GAMES: Bally/Sente with 6x CEM3394 (!) - Trivial Pursuit (1984), Stocker (1984), Mini Golf (1985), Name That Tune (1986), Rescue Raider (1987)
- SOURCE: sound\cem3394.c





S7.    Exidy

- 0.117              : Zsolt Vasvari fixed regression in Exidy sounds.
- 0.112u1            : Lord Nightmare fixed the exidy/stern-sb1000 6840-based sound hardware to use what is believed (based on the schematic) to be the proper LFSR/PRNG waveform for its secondary clock source.
- 0.112              : Proper implementation of noise generator in the Exidy/Berzerk sound circuit [Lord Nightmare].
- 0.104u6            : Aaron Giles added oversampling support to the Exidy custom sound.
- 30th December  2002: Jim Hernandez fixed the noise emulation in the Exidy sound system.
-  2nd June      2000: Aaron Giles sent in a Star Fire / Fire One update, fixing more of the graphics glitches, and he sent in an Exidy sound system update.
- 22nd May       2000: Aaron Giles improved the Exidy sound system
- 0.35b2             : Dan Boris made good progress in sound emulation of the Exidy games (Venture, Pepper 2, etc.)
- 0.34RC1            : Preliminary sound support in the Exidy games [Dan Boris].
- SOURCE: audio\exidy.c - drivers\exidy.c and \victory.c



S7.1   Exidy 440

- 0.123u6            : Zsolt Vasvari changed exidy440_sound_command back to "UINT8." Since it's used by both 8-bit and 16-bit systems, the automatic allocation is not worth it if you need an ugly UINT16 ** cast. Removed deprecat.h from some of the exidy files.
- 0.123u1            : Further altered the Exidy 440 code in preparation for moving to proper sound chip emulation [Zsolt Vasvari].
- 10th July      2003: Aaron Giles fixed the timer bugs that caused the exidy440 games to fail.
-  7th September 1999: Aaron Giles made the Exidy 440 sound output much clearer.
- 0.36b5             : Aaron Giles improved sound in the Exidy 440 games.
- NOTES: The Exidy 440 sound system based on the Retrocade CVSD decoder by Zonn Moore and Neil Bradley.
- SOURCE: audio\exidy440.c
- GAMES: Exidy - Crossbow (1983), Cheyenne (1984), Combat (1985), Who Dunit (1988)





S8.    Namco

S8.1   Namco sound

- 0.119u3            : Removed includes\nam_cust.h.
- 0.93u1             : Sound system update fixes [Aaron Giles]. As an experiment, removed oversampling from namco.c now that the sound core will do it for you
- 0.77u3             : Improved Namco Sound core [BUT].
-  3rd December  2003: BUT sent in an update to the Namco WSG sound core with better sound generation.
- 12th February  2002: 'BUT' submitted an improved version of the Namco sound core, which allows for cleaner sound.
- 0.36b14            : Takahiro Nogi added noise generator to the Namco sound emulation.
- 0.36b11            : Juergen Buchmueller and Tatsuyuki Satoh improved emulation of the Galaxians sound subsystem. Samples are no longer used.
-  1st July      1999: Tatsuyuki Satoh fixed some small things in Namco sound system emulation.
- 13th March     1999: Nicola Salmoria updated the Namco sound driver to support dynamic changes to the waveform data
- 0.35b5             : Aaron Giles merged the old and new Namco sound subsystem, and added support for stereo output.
- 0.30               : Nicola Salmoria and Aaron Giles completely rewritten the Namco waveform audio subsystem. This gets rid of some artefacts in Pac Man (eating a ghost) and Ms Pac Man (eating dots while a fruit is bouncing). Also better emulation of the custom I/O chip in the Namco games.
- 0.19               : Added partial sound support to RallyX (no explosions yet). Thankx to Ron Fries.
- NOTES: The driver handles the four known types of NAMCO wavetable sounds: 3-voice mono (PROM-based design: Pac-Man, Pengo, Dig Dug, etc), 8-voice quadrophonic (Pole Position 1, Pole Position 2), 8-voice mono (custom 15XX: Mappy, Dig Dug 2, etc) and 8-voice stereo (System 1)
- SOURCE: sound\namco.c
- GAMES: Namco PuckMan (1980), Rally X (1980), Galaga (1981)


S8.2   Namco 15XX
- 0.79u1             : Nicola Salmoria added three new sound chips: NAMCO_15XX, NAMCO_52XX, NAMCO_54XX, and changed drivers to use them (NAMCO_54XX is just a placeholder playing samples, until the chip is reverse engineered). Also correct handling of 52XX sample start/end pointers in ROM.
- GAMES: Super Pac-Man (1982)
- PCB: 1502 Sound Generator (Grobda)


S8.21  Namco 50XX
- 0.114u1            : Nicola Salmoria added actual emulation of the microcontroller used for the Namco 50xx chip as found in Bosconian and Xevious.
- 27th March     2007: Guru - Here's the next chip we've decapped in a little more detail (50XX). This shows the full chip die at approx 20X magnification (reduced to minimise the file size, the real image is 5X bigger) and is roughly pasted together from 6 separate images for your viewing pleasure.
- 0.79u1             : Better emulation of 50XX custom, no more need for hacks in bosconian [Nicola Salmoria].
- NOTES: The Namco 50XX chip is a Fujitsu MB8842, which has twice the ROM and RAM of the 54xx chip. It is used for Player score control (only used as protection check).
- SOURCE: machine\namco50.c
- GAMES: Bosconian, Xevious (DIP28)


S8.22  Namco 52XX
- 0.112u2            : Derrick Renaud implemented filters for the 52xx sound effects in preparation for future changes.
- 14th January   2005: Derrick Renaud added filtering circuit to sound\namco52.c and converted it to stream based. Also added proper filters to the Namco52 sample player of Bosconian, Galaga, Pole Position and Xevious. Adjusted relative effect volumes per schematics.
- 0.79u1             : Added sound\namco52.c. Nicola Salmoria added three new sound chips: NAMCO_15XX, NAMCO_52XX, NAMCO_54XX, and changed drivers to use them (NAMCO_54XX is just a placeholder playing samples, until the chip is reverse engineered). Also correct handling of 52XX sample start/end pointers in ROM.
- 0.30               : Martin Scragg fixed Bosconian crashing: This was the speech processor being used for a protection check.
- NOTES: The Namco 52XX is instance of the Fujitsu MB8852 MCU is programmed to act as a sample player. It is used by just two games: Bosconian and Pole Position.
- SOURCE: sound\namco52.c
- GAMES: Bosconian (1981), Pole Position (1982)


S8.23  Namco 54XX
- 0.112u2            : Derrick Renaud added discrete filters to the new Namco 54xx sound effects.
- 0.112u1            : Replaced implementation of Namco 54xx sound chip with new MB8844 CPU core running the original embedded ROM code. Removed old sound core. Pole Position and Bosconian no longer require samples as a result [Nicola Salmora, Ernesto Corvi, Guru].
- 0.93               : Derrick Renaud swapped Namco 54xx filters on Port A & C. This fixed Xevious sound.
- 0.90u2             : Derrick Renaud added op-amp bandpass filtering circuit to sound\namco54.c and updated the Namco 54xx noise sound and added the R/C values to Bosconian, Galaga, Pole Position and Xevious.
- 0.89u5             : Jarek Burczynski improved the Namco 54xx Noise Generator (Type A and B emulated, type C algo still unknown).
- 0.79u1             : Added sound\namco54.c. Nicola Salmoria added three new sound chips: NAMCO_15XX, NAMCO_52XX, NAMCO_54XX, and changed drivers to use them (NAMCO_54XX is just a placeholder playing samples, until the chip is reverse engineered). Also correct handling of 52XX sample start/end pointers in ROM.
- NOTES: The Namco 54XX is instance of the Fujitsu MB8852 MCU and is programmed to act as a noise generator. It is used for explosions, the shoot sound in Bosconian and the tire screech sound in Pole Position.
- SOURCE: audio\namco54.c
- GAMES: Xevious (1982)


S8.24  Namco 56XX
- 0.78u4             : Nicola Salmoria implements the 56XX and 58XX I/O custom chips (machine\namcoio.c) used by all the games. The I/O chips are now accurately simulated, fixing subtle nuances during normal operation and not-so-subtle ones in test mode; e.g. you can now scroll the grid in Mappy's test mode.
- NOTES: I/O (coin management built-in), DIP42
- GAMES: Dig Dug II, Gaplus, Grobda, Libble Rabble, Motos, Pac & Pal, Pacman & Chomp Chomp, Phozon, Super Pacman, Tower Of Druaga, Toy Pop 


S8.25  Namco 58XX
- 0.78u4             : Nicola Salmoria implements the 56XX and 58XX I/O custom chips (machine\namcoio.c) used by all the games. The I/O chips are now accurately simulated, fixing subtle nuances during normal operation and not-so-subtle ones in test mode; e.g. you can now scroll the grid in Mappy's test mode.
- NOTES: I/O (coin management built-in), DIP42
- GAMES: Dig Dug II, Gaplus, Grobda, Libble Rabble, Mappy, Phozon, Super Pacman, Tower Of Druaga, Toy Pop 


S8.3   Namco CUS30
- 0.99u2             : BUT adjusted Namco CUS30 noise frequency.
- 0.89               : Nicola Salmoria cleaned up the CUS30 wavedata/sound command/RAM interface, put it all in a single function.
- 0.80               : Nicola Salmoria added SOUND_NAMCO_CUS30 for better documentation (alias for the standard SOUND_NAMCO)
- SOURCE: sound\namco.c
- GAMES: Namco - Dragon Buster (1984), Pac-Land (1984), Metro-Cross (1985), Rolling Thunder (1986), Wonder Momo (1987)


S8.4   Namco 63701X
- 0.80               : Nicola Salmoria totally rewritten the 63701X emulation and moved it to a separate module. Fixed silence compression, this improves quality in some samples; supported volume control.
- NOTES: An Hitachi HD637A01X0 MCU programmed to act as a sample player. Used by some Namco System 86 games. The MCU has internal ROM which hasn't been dumped, so here we simulate its simple functions. The chip can address ROM space up to 8 block of 0x10000 bytes. At the beginning of each block there's a table listing the start offset of each sample. Samples are 8 bit unsigned, 0xff marks the end of the sample. 0x00 is used for silence compression: '00 nn' must be replaced by nn+1 times '80'.
- SOURCE: sound\n63701x.c
- GAMES: Namco - Genpei ToumaDen (1986), Rolling Thunder (1986), Wonder Momo (1987)



S8.5   Namco System 1

-  1st March     1999: Aaron Giles has updated the Namco System 1 sound system, merging it with the other Namco system. He also added 16-bit sampling support for it.
- 0.35b1             : Support for the Namco System 1 sound system [Ernesto Corvi].
- NOTES: The Namco System 1 is a custom 8 channel 16-bit stereo PSG for sound effects.
- GAMES: Namco - Pac-Mania (1987), Galaga '88 (1987), Dangerous Seed (1989), Tank Force (1991)


S8.6   Namco NA

- 0.101u5            : cync implemented several missing features in the Namco NA sound emulator.
- 0.101u1            : Many improvements to NamcoNA sound [cync].
- 27th February  2003: Phil Stroffolino did some further improvements on the NamcoNA sound emulation.
- 26th February  2003: cync submitted a major improvement to the NamcoNA sound emulation.
- 0.63               : Added sound\namcona.c. Preliminary Namco NA sound support [Phil Stroffolino].
- NOTES: The Namco NA1/2 Sound hardware use PCM samples and sound sequencing metadata are written by the main CPU to shared RAM. The sound CPU's type is unknown, though it appears to be little endian. It has an internal BIOS.
- SOURCE: sound\namcona.c
- GAMES: Namco - Exvania (1992), Knuckle Heads (1992), Tinkle Pit (1993)


S8.7   C140

- 0.122u1            : Philip Bennett fixed C219 sample read order and implemented sign+magnitude format (sound\c140.c).
- 0.95u4             : Mamesick fixed C140 sound routing in the Namco games (namcos2/21.c).
- 20th July      2002: R. Belmont submitted an update to the Namco C140 sound chip emulation, improving Cybersled and others though they aren't yet really playable.
- 0.37b5             : Support for compressed PCM playback in the C140 emulator [CAB].
- 26th June      2000: CAB added compressed PCM playback to the C140 core and did some cleanups.
- 18th November  1999: CAB fixed bad noise in 8-bit emulation of C140.
- 12th November  1999: CAB fixed some C140 and Namco System 2 sound related problems.
-  5th November  1999: CAB fixed quite some C140 problems.
- 0.36b8             : C140 emulation [Phil Stroffolino].
- 22nd October   1999: Keith Wilkins finally added the C140 sound core (done by Phil Stroffolino with help from CAB) to the Namco System 2 driver.
-  2nd March     1999: Juergen Buchmueller has fixed Rolling Thunder MCU problems by simplifying the 6809 interrupt handling and corrected CWAI emulation.
- SOURCE: drivers\namcos2.c - The C140 is a 24 Channel Stereo PCM Sample player.
- GAMES: Namco - Assault (1988), Dragon Saber (1990), Cosmo Gang the Video (1991)


S8.8   C352

- 0.112u1            : Improvements to C352 sound emulator [cync, hoot development team]. Rewrote loop and flag handling, added support for global key-on register. Fixed state saving.
- 0.101u5            : The hoot development team made several fixes and improvements to the C352 sound emulator.
- 0.101u1            : Many improvements to C352 sound [cync].
- 0.99u9             : Major Namco sound improvements [R. Belmont]: C352 now sets output pitch correctly by input clock. Added emulated sound and music to all NB-1, NB-2 and System 11 games, using Prop Cycle's BIOS as a substitute until the original can be trojaned or otherwise obtained. Hooked it up for plain System 22 games as well, but they're not interested in passing down proper commands for some reason. Speed-cheated all instances of the M37710/C352 sound system so CPU requirements don't go up much. This also helped back off the requirements a hair for Prop Cycle and Time Crisis.
- 0.87u2             : C352 Pitch adjustment [R. Belmont, Cap]
- 0.86u3             : Namco C352 update [R. Belmont]. Many many fixes to wave start/end/bank handling plus added chain mode support. Thanks to cap @ VivaNonno for the tips.
- 0.86               : R. Belmont remove C352 debug printf that accidentally snuck in.
- 0.84u2             : Added a preliminary core for the Namco C352 PCM chip [R. Belmont]. It was originally written by the Zinc authors for Zinc and has been adapted for MAME by R. Belmont with their permission. It's not sounding real great yet on music, although it's better than the Zinc original.
- 10th July      2004: R. Belmont - Added save states and a log-scale volume curve to the C352, which improves the music in a lot of games.
- 29th June      2004: R. Belmont - Started cleaning up ZiNc's H8/3002 core for MAME submission (this will add sound and fix protection on Namco Classics 1 & 2 and the System 12 games). Fixed some flag calculations on the ADD opcodes and some "edge cases" on the C352 to improve music in NCV1/2. Still need to fix some issues with the controls in Aqua Rush and Paca Paca.
- NOTES: Namco C352 custom PCM chip with 32 voices, supports 8-bit linear and 8-bit muLaw samples and Output: digital, 16 bit, 4 channels
- SOURCE: sound\c352.c
- Games: Namco - Tekken 3 (1996),  Soul Calibur (1998), Aqua Rush (1999)
- PCB: C352, QFP100 (Ncv1/2)





S9.    OKI

S9.1   MSM5205

- 0.111u1            : Mamesick fixed copy/paste bug in the Irem sound hardware dealing with MSM5205 chips (audio\irem.c).
- 0.106u9            : Nicola Salmoria changed the MSM5205 ADPCM decoder to no longer perform bounds checking to prevent the signal from overflowing. The MSM5205 data sheet clearly states that this isn't the case, and there is no overflow protection in the chip. Also, the chip's internal DA converter is just 10-bit, even if the processed signal is 12-bit.
- 0.93               : Aaron Giles removed ADPCM entirely and wired up dummy MSM5205s to most of the drivers still using it; these need to be revisited and fixed.
- 18th February  2003: Nicola Salmoria fixed an interrupt callback problem in the MSM5205 sound chip emulation.
- 0.37b13            : Nicola Salmoria added Speech in Champion Wrestler.
- 24th March     2000: Manuel Abadia added MSM5205 sound to Splash!
- 0.35RC1            : Added support for slave mode to the MSM5205 emulation [Tatsuyuki Satoh].
-  2nd June      1999: Tatsuyuki Satoh totally rebuilt the MSM5205 emulator and it's a lot better now.
- GAMES: Moon Patrol (Irem 1982), Tropical Angel (Irem 1983), Kung Fu Master (Irem 1984), Silkworm (Tecmo 1988)
- PCB: MSM5205 (Appoooh), M5205 (Funystrp, Splash), OKI M5205 ADPCM (Empcity)


S9.2   MSM5232

- 0.124              : Nicola Salmoria added Noise Output to the MSM5232 emulation.
- 0.123u6            : Nicola Salmoria fixed MSM5232 noise LFSR formula (done by Jarek Burczynski; thanks to Corrado Tomaselli for samples). Changed MSM5232 emulator to output channels separately. Added output of SOLO channels to MSM5232 emulator.
- 0.57               : Added sound\msm5232.c, MSM5232 sound emulator [Jarek Burczynski, Hiromitsu Shioya]. Jarek Burczynski support MSM5232 in Fairy Land Story and Buggy Challenge.
- 21st October   2001: Jarek Burczynski sent in a MSM5232 sound chip emulator (thanks to CAB), adding music to Fairy Land Story and adding one missing sound effect to Buggy Challenge.
- NOTES: MSM5232 is a 8-Channel Tone Generator by OKI.
- SOURCE: sound\msm5232.c
- GAMES: Taito - Buggy Challenge (1984), The FairyLand Story (1984)
- PCB: MSM5232RS (Fieldday, Onna34ro), MSM5332 (Nycaptor), OKI M5232 (Splndrbt), M3M5232RS (Kouyakyu)


S9.21  MSM5253
- NOTES: Bronx (Cycle Shooting bootleg) and Colt (NY Captor bootleg) uses the M5253 sound chip (MAME uses the MSM5232).
- PCB: M5253 (Cyclshtg, NYcaptor)


S9.22  MSM5295
- NOTES: I/O chip? or =>OKI6295
- SOURCE: drivers\rampart.c, relief.c, shuuz.c
- PCB: M5295 (Urashima)


S9.3   OKI6295

- 0.111u6            : David Haywood fixed a couple of errors introduced in the OKI6295 pin shuffling.
- 0.111u3            : David Haywood moved OKIM6295 pin 7 state (internal divider) to internal structure. Updated all drivers to specify pin state when setting the interface. Added comments for all cases where the original frequency wasn't / 132 or /165 as the real pin state is unknown.
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the OKIM6295 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.96u1             : Aaron Giles added ADPCM utilities to OKIM6295.c and used those to hook up sound once again in the Seibu games.
- 0.93u1             : Aaron Giles fixed several issues with banking and playback in the OKI6295.
- 0.93               : Added sound\okim6295.c.
- 0.77               : R. Belmont fixed a driver to allow to have MSM6295s and plain ADPCM voices coexist (required for gcpinbal).
-  1st November  2003: R. Belmont fixed the ADPCM functions so that games can have both MSM6295 sound chips and plain ADPCM at the same time, and he added complete sound emulation to Grand Cross Pinball.
- 0.63               : Changed name 'OKI6295' to 'MSM6295'.
- 17th December  2002: Nicola Salmoria fixed a bug in the OKIM6295 sound chip emulation that caused samples being played erroneously in Got-cha and Steel Force, and he sent in a driver for Got-cha.
- 29th August    2001: Lax fixed some M6295 sound chip frequencies.
- 11th July      2001: Luca Elia fixed OKI m6295 emulation from crashing with sound disabled.
-  2nd April     2001: Jarek Burczynski added state saving support to ADPCM and OKIM6295 sound emulation cores.
- 23rd October   2000: Takahiro Nogi added bank switching function for M6295 samples and tweaked playback frequency in the Toaplan2 driver.
- 20th June      2000: Bryan McPhail fixed some YM2151/OKIM6295 sound balance problems in several drivers.
- 23rd July      1999: Jim Hernandez fixed Vapor Trail sound with the new OKI6295 interface.
- 22nd July      1999: Bryan McPhail sent in a driver for Crude Buster, and modified OKI6295 core to support different frequencies.
- 24th April     1999: Nicola modified the ADPCM sounds of Klax to change volume as the pieces come closer.
-  8th February  1999: Bryan McPhail made the ADPCM code support two OKI 6295 chips with samples in different memory regions.
- 0.31               : Aaron Giles improved ADPCM support, plus support for the OKIM6295 ADPCM chip. Several drivers use these.
- SOURCE: sound\okim6295.c
- GAMES: Forgotten Worlds (Capcom 1988), Pang (Mitchell 1989), Mad Gear (Capcom 1989), 1941 (Capcom 1990)
- PCB: M6295GS (Naname), M6296 (Hotdogst, Tumblep, CycleWarriors), U6295 (Suprpool), AD-65 QFP44 (Bmcbowl, Grdnstrm), AD65 (Egghunt, Popspops), AR17961 QFP44 (Chindrag, Paradise, Pwrinst2), K-665-9249 (Powerins), K-665 9546 (blktiger.c), K668 (Sdmg2, Slqz2), MK28 (Bmcbowl), M28 (QFP44)(SuperMoto), 6606 (QFP44) (Mjchuuka), SMS6295 (Riot), AC0A26 (Drgnwrld)



S9.4   MSM6585

- 0.77               : R. Belmont added full sound / music in Grand Cross and fixed the drivers to allow to have MSM6295s and plain ADPCM voices coexist (required for gcpinbal). Added ADPCM sound chip and set sound to mono.
- NOTES: The MSM6585 is a version-up to the previous M5205 with some additional capabilies and improvements. It plays ADPCM samples. The emulation comes from RAINE.
- GAMES: Grand Cross (Excellent System 1994)
- SOURCE: drivers\gcpinbal.c
- PCB: M6585  DIP18 (Gcpinbal, Vmetal)





S10.    Nintendo

S10.1   N2A03 / NES APU

- 0.113              : Aaron Giles fixed regression in Nintendo games that did not specify a clock for the NES APU.
- 0.104u3            : Aaron Giles added save state support to the NES APU sound chip.
- 0.102u5            : Changed name 'NES' to 'N2A03'. R. Belmont hooked up the same NES APU implementation in both MAME and MESS. Also correctd the memory mapping of the APU in the Playchoice 10 driver.
- 0.93               : Changed name 'Nintendo' to 'NES'. Aaron Giles changed the way the NES APU worked so that it used streams properly instead of an update function.
- 0.80               : Oliver Achten improved the NES APU emulation: Various bugs concerning the DPCM channel fixed and fixed $4015 read behaviour.
-  2nd March     2004: Oliver Achten fixed the NES APU sound core, especially the broken DPCM audio channel.
- 13th September 2000: Juergen Buchmueller fixed some bugs in the new NES sound core.
- 12th September 2000: Matt Conte submitted a NES sound core update, and it definitely sounds better now.
-  4th July      2000: Matthew Conte improved the NES sound engine yet again.
- 0.36b13            : New NES sound emulation for Punch Out and Donkey Kong 3 [Matthew Conte, wwtk@mail.com].
- 26th December  1999: wwtk@mail.com and Matthew Conte contributed a new NES sound driver
- NOTES: Based on the Nofrendo/Nosefart NES N2A03 sound emulation core written by Matthew Conte and redesigned for use in MAME/MESS.
- NOTES: There is also the N2A03 CPU !!!
- SOURCE: sound\nes_apu.c
- GAMES: dkong.c, playch10.c, punchout.c and vsnes.c


S10.2   SNES Custom
- DRIVER: Based on the original MESS driver by Lee Hammerton
- NOTES: The Custom sound module of the Nintendo Super System hardware contains the chips: S-SMP - Stamped 'Nintendo S-SMP (M) SONY (C) Nintendo '89' custom sound chip (QFP80) and S-DSP - Stamped 'Nintendo S-DSP (M) (C) SONY '89' custom sound DSP (QFP80).
- SOURCE: audio\snes.c
- GAMES: nss.c - Nintendo Super System games (The Addams Family, Contra 3, Lethal Weapon(1992))


S10.3   S-DSP
- PCB: Nintendo S-DSP (M) (C) SONY '89' custom sound DSP, QFP80 (NintendoSuperSystem)

S10.4   S-SMP
- PCB: Nintendo S-SMP (M) SONY (C) Nintendo '89' custom sound chip, QFP80 (NintendoSuperSystem)



S12.    Konami

S12.1   K005289

- 0.93               : Changed name '005289' to 'K005289'.
-  7th December  1999: CAB and Bryan McPhail fixed some problems with 005289/051649 sound chip emulators.
- 0.36b11            : Taken the 005289 emulation out of namco.c [Bryan McPhail].
- 29th November  1999: Bryan McPhail added correct implementation of the 005289 sound chip to Nemesis.
- NOTES: The 005289 is a 2 channel sound generator, each channel gets it's waveform from a prom (4 bits wide). The 005289 has no data bus, so data values written don't matter. From Nemesis schematics the address lines A0-A4 of the prom run to the 005289, giving 32 bytes per waveform. Address lines A5-A7 of the prom run to PA5-PA7 of the AY8910 control port A, giving 8 different waveforms. PA0-PA3 of the AY8910 control volume.
- GAMES: Konami - Nemesis (1985), Konami GT (1985), Galactic Warriors (1985), TwinBee (1985)


S12.2   K007232

- 0.93               : Changed name '007232' to 'K007232'.
- 10th May       2002: Hiromitsu Shioya improved the K007232 sound chip emulation.
- 0.36b3             : Nicola Salmoria added support for external volume control to the K007232 and fixed Aliens, Ajax etc.
-  6th August    1999: Hiromitsu Shioya sent a 007232 update, which sounds a lot better.
-  3rd August    1999: Bryan McPhail sent in a 007232 update which added bankswitching to the samples, necessary for Main Event.
-  3rd March     1999: Hiromitsu Shioya sent in a newer version of the K007232 sound chip emulation which now supports stereo output.
- 0.35b1             : Konami 007232 sound chip emulator. This is used by TMNT [Hiromitsu Shioya]. Howie Cohen added the 007232 to TMNT.
- GAMES: Konami - Salamander (1986), Gang Busters (1988), Devastators (1988), TMNT (1989)
- SOURCE: chqflag.c - 007232 volume & panning control is almost certainly wrong.


S12.3   K051649

- 0.93               : Changed name '051649' to 'K051649'.
- 30th January   2004: Nathan Woods sent in minor timing enhancements to the K051649 sound core.
- 18th April     2001: Sean Young fixed a frequency calculation bug in the K051649 (SCC) sound core.
- 14th November  2000: Bryan McPhail fixed K051649 sound problems in Haunted Castle.
-  7th December  1999: CAB and Bryan McPhail fixed some problems with 005289/051649 sound chip emulators.
- 0.36b11            : 051649 emulation, used in Haunted Castle [CAB, Bryan McPhail].
- 30th November  1999: Bryan McPhail added 051649 sound chip emulation to Haunted Castle, which now has fully emulated sound.
- NOTES: The 051649 is a 5 channel sound generator, each channel gets it's waveform from RAM (32 bytes per waveform, 8 bit signed data). This sound chip is the same as the sound chip in some Konami megaROM cartridges for the MSX. It is actually well researched and documented: http://www.msxnet.org/tech/scc. K052539 is equivalent to the K051649 chip except channel 5 does not share waveforms with channel 4.
- GAMES: Konami - City Bomber (1987), Kitten Kaboodle (1988), Haunted Castle (1988), Hexion (1992)
- PCB: 051649(SCC) (Hexion)


S12.4   K053260

- 0.93               : Changed name '053260' to 'K053260'.
-  1st March     2004: Oliver Achten fixed the PPCM (Packed PCM) decoding in the K053260 sound chip emulation, improving samples in Asterix, The Simpsons, TMNT 2 and others.
-  8th March     2001: Ernesto Corvi and Nicola Salmoria added support for dual K053260 sound chips, fixing sound in Over Drive.
- 0.37b2             : Ernesto Corvi fixed adpcm decoding in the K053260, this improves several Konami games.
- 16th April     2000: Ernesto Corvi updated the K053260 ADPCM decoding to use a better algorithm, and the sound is much better.
- 31st August    1999: Ernesto Corvi sent in a K053260 update with a lot better digital sound because the samples were just normal PCM after all.
- 23rd August    1999: Ernesto Corvi sent in a K053260 update with misc. fixes.
- 12th August    1999: Ernesto Corvi sent in another K053260 update with stereo channels in correct order.
-  9th August    1999: Ernesto Corvi sent in a K053260 update, with fixes to ADPCM decoding.
- 0.36b2             : Konami 053260 sound chip emulation [Ernesto Corvi]. Ernesto Corvi added 053260 emulation in Punk Shot.
- GAMES: Konami - Punk Shot (1990), The Simpsons (1991), Sunset Riders (1991)


S12.5   K054539

- 0.121u3            : BUT fixed buffer overflow in K054539.
- 0.112u4            : Aaron Giles fixed crash in k054539 sound core.
- 0.112u3            : Aaron Giles changed K054539 to run at native sample rate.
- 0.93               : Changed name '054539' to 'K054539'.
- 0.69b              : R. Belmont fixed bug in K054539 causing bad vocals in Dadandarn.
-  1st June      2003: R. Belmont fixed the K054539 sound chip emulation to ignore writes to an active voice's position register, fixing the vocals in Kyukyoku Sentai Dadandarn.
- 16th April     2003: Minachun improved the panning and volume adjustment in the K054539 sound core.
- 21st January   2003: Acho A. Tang fixed reversed stereo in some games that use the K054539 sound chip.
- 0.57               : Olivier Galibert added reverb to the 054539, improving sound in Xexex and Twinbee Yahhoo.
- 14th August    2001: Olivier Galibert fixed a bug with 16-bit samples in the K054539 sound chip emulation.
- 0.37b12            : Source - 054539 sound emulation, used in X-Men, Xexex, GI Joe [Olivier Galibert].
- 14th February  2001: Olivier Galibert fixed a small bug in the K054539 sound chip emulation that caused a few missing sounds in X-Men.
- 29th January   2001: Olivier Galibert wrote 054539 sound chip emulation (thanks to CAB), and now Xexex and X-Men have sound.
- 0.37b8             : Added sound\k054539.c/h.
- NOTES: The eight PCM channels of a K054539 do not have seperate volume controls.
- GAMES: Konami - Xexex (1991), X-Men (1992), GI Joe (1992)
- PCB: 054539, QFP160 (Mmaulers)


S12.6   K054544
- NOTES: The Konami Custom 054544 is exactly the same as a 054986A and has the Analog Devices AD1868R inside. The 054544 is capable of 16-bit sound. Compression format for certain sounds is unknown.
- PCB: 054544 (Xmen)


S12.7   K056800
- 0.110u3            : Ville Linde consolidated K056800 (MIRAC) sound system interface emulation (machine/konamiic.c).
- PCB: Konami Hornet System, Konami System GX, Konami GTI Club System



S13.    Sega

S13.1   Sega PCM

- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the Sega PCM/Multi-PCM sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.94               : SegaPCM now does stream_update on reads/writes for slightly better accuracy [Aaron Giles].
- 0.76u1             : Olivier Galibert fixes the pitch (the 15800Hz value was wrong, it should have been the main 4Mhz clock divived by 256) and also makes the code ultra-paranoid when it comes to out-of-range accesses in the sample roms. Power Drift's sound code sometimes puts semirandom values for the first handful of keyons on song transitions.
- 25th October   2003: Olivier Galibert fixed the pitch (again) in the SegaPCM sound core and fixed some bug that was triggered by Power Drift trying to play out-of-range samples.
- 30th September 2003: Olivier Galibert fixed another bug in the SegaPCM sound core.
- 29th September 2003: Olivier Galibert fixed the looping samples in the SegaPCM sound core.
- 28th September 2003: Tatsumaki fixed a small typo in the SegaPCM sound core that resulted in slightly wrong pitch of the samples.
- 15th September 2003: Olivier Galibert sent in another fix to the SegaPCM sound chip emulation.
-  7th September 2003: Olivier Galibert sent in a SegaPCM sound chip emulation cleanup with some fixes thrown in.
- 17th February  2000: Andrew Prime fixed SegaPCM sound in the System16 drivers.
- 0.36b2             : Sega PCM and RFC68 sound emulators, used by System 16 [Hiromitsu Shioya].
- GAMES: Sega - Enduro Racer (1987), Out Run (1986), Super Hang-On (1992)


S13.2   RF5C68
- 0.104u9            : Aaron Giles fixed engine noise looping (sound\rf5c68.c).
- 0.96u4             : Aaron Giles rewrote the RF5C68 sound emulator from the specs, improving sound in the System 18/32 games.
- 0.89u1             : Aaron Giles fixed a rf5c68 memory access bug.
-  8th February  2004: R. Belmont reverted the RF5c68 sound emulation to an earlier version, to fix some tuning problems.
- 26th October   2003: Olivier Galibert rewrote the RF5C68 sound chip emulation.
- 11th March     2003: R. Belmont fixed a small typo in the RF5C68 sound core
- 0.36b2             : Sega PCM and RFC68 sound emulators, used by System 16 [Hiromitsu Shioya].
- SOURCE: sound\rf5c68.c - RICOH RF5C68 PCM controller
- GAMES: Sega - Shadow Dancer (1989), Alien Storm (1990), Moon Walker (1990)
- PCB: 315-5476A, 80 pins (Radr, Sega System32)


S13.3   RF5C320
- PCB: CPS2-B RF5C320 CAPCOM DL-3129 (QFP208)
- GAMES: Capcom - Street Fighter EX (1996), Rival Schools (1997), Gallop Racer (Tecmo 1996)


S13.4   RF5C400
- 0.113              : Actually included the RF5C400 changes mentioned for 0.112u4 [Hoot Development Team].
- 0.112u4            : RF5C400 sound core improvements [Hoot Development Team]: Implemented volume envelopes. Corrected the channel volume calculation. Documented registers for reverb, chorus, and per-channel digital filter (actual effects are not implemented yet).
- 0.112u1            : Rewrote much of the RF5C400 sound emulator to support looping, stereo panning and 8-bit sample support [hoot development team, Ville Linde].
- 19th October   2006: R. Belmont - I'm still looking for samples of Konami RF5c400 games, but in the meantime Ville Linde and I have improved the emulation of the chip so that Gradius 4 and Solar Assault now sound very much like the real thing, and GTI Club isn't far behind. (NBA Play By Play and the Thrill Drive games have something very strange happening - either a mild address line swap on the sample data or the ROMs are in weird Konami byte mode or who knows what).
-  7th October   2006: R. Belmont - If you have a Konami PowerPC-based game or PCB with the RF5c400 sound system (check system16 or MAWS if you aren't sure - this includes games like Gradius 4, Solar Assault, NBA Play By Play, Thunder Hurricane, Thrill Drive, Racing Jam, and more) and it's in good working order, I need some samples off one to fix up the RF5c400 emulation in MAME/M1/hoot. Please PM me on one of the 3 boards I read: bannister.org, www.mame.net, or www.mameworld.info if you can supply stereo mp3 samples of such a machine. Update: Guru got me some samples from Gradius 4, which have given me 2 pieces of info about the chip I didn't previously have. Sweet. Many more samples are still needed to achieve decent emulation however.
- 0.103              : Some RF5C400 improvements [hoot development team].
- 0.102u1            : Ville Linde added very, very preliminary emulation of the Ricoh RF5C400.
- SOURCE: sound\rf5c400.c
- PCB: RICOH RF5C400, PQFP (GTIClub, Gradius4)


S13.5   MultiPCM

- 0.123u5            : Saturate MultiPCM on clip and fix envelope discontinuity [ElSemi].
- 0.97u5             : Aaron Giles cleaned up bank handling in Sega Multi-PCM sound core.
- 0.93               : Changed name 'Sega_315-5560' to 'MultiPCM'.
- 30th June      2003: R. Belmont sent in an update to the MultiPCM sound chip emulator, adding a new banking mode used by Stadium Cross, though the sound in that game is still not perfect.
- 12th April     2003: R. Belmont added save state support to the MultiPCM sound core and did a little cleanup on it.
- 0.67               : Added sound\multipcm.c. Sega 315-5560 "MultiPCM" sound chip emulation [R. Belmont].
- 31st January   2003: R. Belmont sent in a very preliminary System 32 Multi driver in which basically only the MultiPCM sound works, nothing else.
- NOTES: Sega System 32 Multi/Model 1 custom PCM chip (315-5560) emulation.
- SOURCE: sound\multipcm.c
- GAMES: Sega - Outrunners (1992), Hard Dunk (1994)





S14.    Seta

S14.1   X1-010

- 0.65               : Added sound\x1_010.c. Nicola Salmoria added stereo support to the X1-010 emulator and made it a proper sound core.
- 20th August    2002: Manbow-J submitted an improvement to the X1-010 (Seta PCM) sound chip emulation.
- NOTES: The Seta Custom Sound Chip X1-010 is a 16 voices sound generator, each channel gets it's waveform from RAM (128 bytes per waveform, 8 bit unsigned data) or sampling PCM (8bit unsigned data).
- SOURCE: sound\x1_010.c
- GAMES: Thundercade (Seta 1987) uses a YM2203 + YM3812 instead of X1-010.
- PCB: X1-010, QFP80 Sound Chip (Champbwl), Mitsubishi X1-010 M60016 CALRUA (Deerhunt)


S14.2   ST0016

- 0.93               : Changed name 'ST-0016' to 'ST0016'.
- 0.81u7             : R. Belmont and Tomasz Slanina added ST-0016 stereo sound to the ST0016 driver.
- 20th April     2004: R. Belmont added support for looping samples and fixed a few other things in the ST-0016 sound chip emulation.
- 19th April     2004: R. Belmont added sound to the Seta ST-0016 driver and David Haywood fixed a slight bug in it.
-  7th March     2004: Tomasz Slanina - More Seta ST-0016 stuff (in multicpu games only st-0016 is emulated): Mayjinsen (V810 + ST-0016), Mayjinsen 2 (V810 + ST-0016), Super Eagle Shot (R3000 + ST-0016), Super Real Mahjong P5 (R3000 + ST-0016) - No gfx .. sound code is executed every frame and Neratte cyuh! (ST-0016) - Problems with rombanking.
- NOTES: Seta custom ST-0016 chip sound emulation by R. Belmont, Tomasz Slanina and David Haywood
- GAMES: Mayjinsen (Seta 1994), Neratte Chu (Seta 1996), Renju Kizoku (Visco 1994)
- SOURCE: sound\st0016.c
- PCB: SETA ST-0016 TC6187AF (Speglsht), SETA ST-0016 TC6210AF (Mayjisn2, Nratechu, ), ST-0016 (Srmp5)




S15.    Hudson Soft

S15.1   HuC6280

- 25th November  2007: Charles MacDonald - The HuC6280 PSG used in the PC Engine and several Data East arcade games has six "tone" channels which output a short waveform (32 x 5-bit samples) repeatedly. The last two channels have independent random noise generators that replace the tone output, which generate one bit per sample, interpreted as the minimum ($00) or maximum ($1F) sample value. For the purposes of accurate emulation it would be useful to know exactly how the random data is generated. This involves two steps; analysis of the recorded noise output and determining the type of random noise generator being used. Both the tone and noise channels can be configured to run at the same frequency. I chose the slowest ones, $00 for noise and $3E for tone output which is approximately 1804 Hz. The tone output was loaded with a square wave, such that within one sample of the noise output (one bit) there is a full square wave on the tone output. This provided a reference "clock" for the noise "data", which was used for extracting the noise bitstream from the recorded output of the chip. The clock had one transition at the same time the noise output changed and another in the middle when the output has settled somewhat. During playback, the tone sample buffer index is not necessarily in sync with the noise output, it can be offset by up to 32 samples. By toggle the frequency of the tone channel briefly using the control pad, it was possible to change the index. With a little trial and error you can get the two perfectly aligned. I'm not too familiar with audio processing in general, but I could see that the problem of extracting digital data from an analog source was something a Schmitt-triggered input would be capable of doing in an electronic circuit. I implemented this in software, in the form of a program that would look at both channels and reconstruct the clock and data bitstreams by applying hysteresis to the recorded samples. When the clock had a negative pulse, the data was in a valid state and it's current state was recorded. This type of processing also had the advantage of being able to handle situations where the noise output had multiple 1's or 0's in sequence; the output would decay towards zero after an initial peak, but the hysteresis prevented this from looking like a sequence of "100000" rather than it's actual value of "111111". With the bitstream reconstructed, it was time for some analysis. One way to generate random bits is with a linear feedback shift register (LFSR) something that is easy to implement in hardware. Gridle pointed out a very useful program that implements the Berlekamp-Massey algorithm for determining the shortest LFSR that matches a given bitstream: http://www.qualcomm.com.au/PublicationsDocs/b-m.c  According to the program it was a LFSR! The LFSR was 18 bits, with bits (LSB) 0, 1, 11, 12, and 17 (MSB) tapped. Assuming a right-shift on each clock pulse, the bit shifted out is the noise sample. The tapped bits are XOR'd together and inserted into bit 17. After /RESET is asserted the LFSR is initialized with bit 0 set and all other bits reset. It has a maximum sequence of 131071 bits before repeating. To confirm this I wrote a test program that generated a bitstream based on the LFSR, and then searched for that sequence within the extracted bitstream from a recording. As expected the generated bitstream was found and it repeated every 131071 bits within the recording. I wanted to see which registers affected the LFSR, but as it turns out none of them do except for the LFSR frequency control. If the channel is turned on or off, noise is turned on or off, or if any other setting is adjusted, the LFSR always runs at the specified noise frequency. Apart from a reset, the LFSR state can't be changed. I did a few more recordings at other frequencies and on other systems (using a mix of HuC6280 and HuC6280A chips) to confirm the results; and indeed the findings were identical each time. The only unknown is how the random noise generator of the PC-FX sound chip works, which contains the same PSG core with ADPCM output added. One of these days I'd like to look at the random noise generator used in the Namco NA-1 board, it's internal state can be read and written during playback, and clocked 'manually' one step at a time. It should be possible to extract the bits without recording any samples and analyze that directly.
- 0.103u2            : H6280 updates [Rob Bohms]: Added T-flag emulation and fixed read calls in the HuC6280 CPU and sound CPU.
- 0.67               : Added sound\c6280.c. HuC6280 sound emulation [Charles MacDonald].
-  1st April     2003: Charles MacDonald submitted a HuC6280 sound chip emulator and added support for it in the Battle Rangers / Bloody Wolf driver.
- NOTES: Remember (!) there is also the HuC6280 CPU in MAME. The HuC6280 sound chip emulator based on Paul Clifford PSG documentation and Richard Bannister TGEmu.
- GAMES: Battle Rangers/Bloody Wolf (Data East 1988), mpu4.c
- SOURCE: sound\c6280.c
- PCB: KIA6280 (Legendoh)




S16.    Philips

S16.1   SAA1099
- 20th July      2000: Manuel Abadia submitted a Philips SAA1099 sound chip emulator.
- GAMES: Xor World (Gaelco 1990), Master Boy (Gaelco 1991)
- PCB: SAA1099P (Xorworld)

S16.2   SAA71111
- PCB: Philips SAA71111AH2 20505650 bP0219, QFP64 (Chameleon 24-in-1)





S17.    Capcom

S17.1   Q-Sound
- 0.109u1            : David Haywood added bounds checking to the qsound driver.
- 0.94u1             : Aaron Giles fixed '3 speaker problem' with Qsound.
- 0.93               : Changed name 'QSound' to 'Q-Sound'.
- 0.88               : Added Qsound save state support (thanks to Mame32Plus).
- 27th December  1999: Paul Leaman sent in a small Qsound update to the alternate Qsound player.
- 0.36b11            : QSound player (preliminary) [CAB, Paul Leaman, Miguel Angel Horna].
-  5th December  1999: Paul Leaman merged his and Miguel's Qsound cores.
-  4th December  1999: Miguel Angel Horna sent in yet another Qsound update.
- 30th November  1999: Miguel Angel Horna submitted yet another Qsound driver, which sounds pretty good now.
- 28th November  1999: Miguel Angel Horna and Paul Leaman both submitted a Qsound driver, but neither of them are working correctly.
-  1st August    1999: Paul Leaman added some kind of sound to the Qsound games, but frequency and length of the samples aren't yet right.
- 30th June      1999: Paul Leaman sent a new CPS-1 driver with stub functions for the Qsound system. It doesn't play anything yet, but simple sample playing shouldn't be far off.
- 13th February  1999: More progress on the CPS1 driver. Some of the later CPS1 games utilizing the Q-sound system are now working (such as Cadillacs & Dinosaurs, Punisher and Warriors of Fate), and a few minor bugs have been fixed. No sound though, because the Q-sound roms are encrypted. Information about 'Kabuki' encryption system is very welcome.
- NOTES: Capcom System QSound with 16 channel stereo sample player. QSpace position is simulated by panning the sound in the stereo space. Many thanks to CAB, the author of Amuse.
- GAMES: Capcom - Warriors of Fate (1992), The Punisher (1993), Mega Man 2 (1996)


S17.2   CAPCOM-Q1
- PCB: Q-Sound chip also stamped DL-1425 45570 9420S 40 (C)92 AT&T (PLCC84) or DL-1425 11008 9741T 74 (C)92 LUCENT (PLCC84).
- GAMES: Capcom - Street Fighter EX (1996), Rival Schools (1997), Gallop Racer (Tecmo 1996)
- PCB: DSP-16P DL1425 (Sfexp, Sfex2), DL-1425 DSP-16A (C) 92 AT&T - CAPCOM-Q1 QSound Processor (CPS2).




S18.    Nanao

S18.1   GA20

- 0.112              : R. Belmont rewroted faux x86 assembly in the Irem GA20 sound core.
- 0.93               : Sound System update [Aaron Giles]. Acho cod... transmission lost.
- 0.89u5             : Stephen Behling fixed a IremGA20 64-bit crash.
- 0.80u2             : R. Belmont added channel status readback to the GA-20, which fixes some occasional odd voice-stealing behavior I've heard playing R-Type Leo.
- 0.79u2             : R. Belmont fixed Irem's GA-20 pitch.
- 18th February  2004: R. Belmont - Reverse-engineered the proper pitch calculation for the Irem GA-20 sound chip and submitted to MAMEdev. I no longer need samples from those games. Thanks to Fujix, Yasuhiro Ogawa, the Guru, and Tormod for real PCB samples that made this possible.
- 17th February  2004: R. Belmont - Japump has kindly sent samples from an R-Type Leo and Guru's got a Gunforce. Samples from any other games using an Irem GA-20 are still needed though.
- 14th February  2004: R. Belmont - Looked into the pitch calculation for the Irem GA-20. I have something that works a lot better (R-Type Leo's music all matches the OST now) but it's still not perfect. I need PCB recordings from the test menu of a GA-20 based game (R-Type Leo would be great, but any MAME m92.c or m107.c game would probably work). Please private message me on one of the 3 boards I read (the bannister.org M1 board, the mame.net board, or the MAMEWorld boards) if you can do this.
-  7th January   2003: Bryan McPhail fixed the IremGA20 sound chip emulation from crashing if sound was turned off.
- 30th May       2002: Acho A. Tang did a few small cleanups in various drivers and improved the Irem GA-20 sound chip emulation slightly. Applied hyperbolic gain control to volume and used a musical-note style progression in sample rate calculation(still very inaccurate).
- 18th April     2002: Acho A. Tang improved the Irem GA-20 sound chip emulation which helps some of the games on the Irem M-92 hardware. Rewrote channel mixing and added prelimenary volume and sample rate emulation
- 11th January   2002: Acho A. Tang submitted a modification to the Irem GA20 sound chip emulation, which partially fixes some sample pitch problems in the Irem M-92 driver.
- 0.37b8             : Added sound\iremga20.c/h. Preliminary Irem GA20 sound emulation [Bryan McPhail]. Bryan McPhail added preliminary sound in Blade Master, Gunforce, UUCops and Lethal Thunder.
- 11th September 2000: Bryan McPhail sent in a huge Irem games update with a rewritten NEC core, fixing many bugs. R-Type Leo title screen was fixed as well as preliminary Irem GA20 custom sample player support was added.
- SOURCE: sound\iremga20.c
- GAMES: Irem - Hook (1992), R-Type Leo (1992), In The Hunt (1993)
- PCB: Nanao GA20, QFP80 (Gunforc2), Nanao-GA20 (Inthunt, Uccops)





S19.    Ensoniq

S19.1   ES5503
- 0.114              : R. Belmont made behavior of ES5503 IRQ status register more accurate.
- 0.113u4            : ES5503 updates [R. Belmont]: Major fixes to IRQ semantics and end-of-sample handling. Sample memory now configurable. Added state save support. Calculates output rate properly based on the input clock. Hooked up properly to Moonquake.
- 0.113u3            : ES5503 improvements [R. Belmont]: Fixed extraneous click at end of samples. Improved timing behavior. Fixes music tempo in many Apple IIgs apps and games in MESS.
- 0.109              : R. Belmont fixed ES5503 behavior for voice volumes > 127 (cures missing sounds/music notes in several Apple IIgs demos and games).
- 0.105u3            : ES5503 emulation [R. Belmont].
- 16th March     2005: R. Belmont - I submitted first-pass working ES5503 emulation to MESS for their now-in-CVS Apple IIgs driver.
- NOTES: The ES5503 was the next design after the famous C64 "SID" by Bob Yannes. It powered the legendary Mirage sampler (the first affordable pro sampler) as well as the ESQ-1 synth/sequencer. The ES5505 (used in Taito's F3 System) and 5506 (used in the "Soundscape" series of ISA PC sound cards) followed on a fundamentally similar architecture.
- SOURCE: sound\es5503.c
- GAMES: Moonquake (Sente 1987)


S19.2   ES5505
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the ES5505/6 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.98u3             : Jarek Burczynski fixed subtle bug in ES5505/6 interpolation code.
- 20th April     2003: R. Belmont fixed a few memory leaks in the ES550x sound core.
- 16th November  2002: Nicola Salmoria added preliminary sound CPU communication to the Macross Plus driver, but sound doesn't work yet due to an unemulated IRQ feature in the ES5506 sound core.
- 0.60               : Acho A. Tang improved Irem GA20 emulation, used by M92 games.
-  3rd April     2002: Aaron Giles fixed a potential crash bug in the ES550x sound chip emulators, but this doesn't fix anything else.
- 0.53               : Aaron Giles fixed a ES550x bug that caused Taito F3 and Incredible Tech games to sound bad.
-  4th August    2001: Aaron Giles fixed the ES-550x sound bug which caused scratchy sound.
- 27th January   2001: Bryan McPhail sent in a Taito F3 sound update, with the sound cutting out bug fixed and stereo sound implemented (it was mono before).
- 0.37b11            : ES5505/6 emulation [Aaron Giles].
- 16th January   2001: Aaron Giles fixed a small interpolation bug in the ES5505 core.
- 15th January   2001: Bryan McPhail finally submitted his Taito F3 driver, which is not graphically perfect and crashes hard sometimes but has complete ES5505 sound emulation thanks to Aaron Giles, Ian Schmidt and R. Belmont.
- NOTES: The Ensoniq ES5505/6 sound emulation for the Taito F3 games eats lots of memory as 8 bit PCM data is decoded as 16 bit for use by the current ES5505 core.
- GAMES: Taito - Arabian Magic (1992), Gunlock (1993)
- PCB: Ensoniq OTISR2 5505, DIP48 (Elevactr, Twinqix, Undrfire, Groundfx), ENSONIQ OTISR2 5505 OTIS (Scfinals)


S19.3   ES5506
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the ES5505/6 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.98u3             : Jarek Burczynski fixed subtle bug in ES5505/6 interpolation code.
- 0.53               : Aaron Giles fixed a ES550x bug that caused Taito F3 and Incredible Tech games to sound bad.
- 0.37b11            : Added sound\es5506.c. ES5505/6 emulation [Aaron Giles].
- 10th January   2001: Aaron Giles sent in a small update to the ES5506 sound core, fixing some digital filter bugs.
- GAMES: Time Killers (Strata 1992), Storm Blade (Visco 1996), Monster Slider (Visco 1997)
- PCB: OTTOR2 ES5506000102 (Macrossp), ENSONIQ OTTO R2 (Quizmoon)


        ES5506 GENMIDI2 sample rom labels (16MBit MaskROM, DIP42):

        ENSONIC (C) 1992 2M     1350901601 9320 1.00'         (Pairs - drivers\itech32.c)
        ENSONIC (c) 1992 2M     1350901601 20584A-M           (Gt3d)
        ENSONIC          2MX16U 1350901801 9312 1.00          (Gt97, Gt98)

        Pairs sample rom text:
        SDGI  9.Jan 05 1993 V1.00  GENMIDI2 2MX8 Compressed Audio Sample Data Copyright (c) 1992 Ensoniq Corp.


S19.4   ES5510
- 0.106u8            : David Haywood moved some common code into taito_en.c (taito ensoniq sound system).
- NOTES: ES5510 DSP, DSP ram = 512bytes = 0x200
- SOURCE: audio\taito_en.c
- PCB: ENSONIQ 5510 (Superchs), ESPR5  5510 ESP, DIP48 (Scfinals), ESPR6 ES5510 (Sidebs2), ENSONIC ESP-R6 (Groundfx), EnsoniqESP-R6 (Undrfire), ES5510000106 ESPR6 (Elevactr, Twinqix)


S19.5   ES5701
- NOTES: ???
- PCB: ENSONIQ 5701, QFP100 (Scfinals), 5701000101 (Elevactr, Twinqix)


S19.6   SUPER GLU
- PCB: ENSONIC SUPER GLU (Groundfx, Undrfire)




S20.    Brian Schmidt Music Technology

S20.1   BSMT2000

- 0.113              : Aaron Giles rewrote the BSMT2000 to be more accurate. Various modes are now software selected at startup based on the register value at reset time. Changed all existing drivers so they properly hooked up the reset line on the chip in order to make this control work. Also added correct BSMT2000 ADPCM output.
- 0.112              : Aaron Giles removed linear interpolation from the BSMT2000 by default since the original chip did not do interpolation.
- 0.104u4            : Aaron Giles added save state support to the BSMT2000 sound emulator and the dcheese driver.
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the BSMT2000 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.57               : Added sound\bsmt2000.c. BSMT2000 sound emulator [Aaron Giles].
- NOTES: BSMT2000 = Brian Schmidt Music Technology
- SOURCE: sound\bsmt2000.c
- GAMES: Double Cheese (1993), Battle Toads (Rare 1994), Police Trainer (P&P Marketing 1996)
- PCB: BSMT2000 D15505N (Dcheese)





S21.    Gaelco


S21.1   Gaelco GAE1

- 0.63               : Added sound\gaelco.c
- 30th December  2002: Manuel Abadia sent in the Gaelco GC-1V/GAE1 driver, supporting Alligator Hunt, Maniac Square and Bang! playably and World Rally 2, Touch & Go and Snowboard Championship not working because of DALLAS protection.
- SOURCE: sound\gaelco.c
- GAMES: Gaelco - Alligator Hunt (1994), World Rally 2 (1995), Maniac Square (1996)
- PCB: GAE1 449, QFP208 (Aligator, Wrally2), GAE1 501 (Touchgo)


S21.2   Gaelco CG1V

- 0.93               : Changed name 'GAELCO_CG-1V' to 'GAELCO_CG1V'.
- 0.63               : Added sound\gaelco.c
- 30th December  2002: Manuel Abadia sent in the Gaelco GC-1V/GAE1 driver, supporting Alligator Hunt, Maniac Square and Bang! playably and World Rally 2, Touch & Go and Snowboard Championship not working because of DALLAS protection.
- SOURCE: sound\gaelco.c
- GAMES: Gaelco - Snow Board Championship (1996), Bang! (1998)
- PCB: CG-1V 388 (Bang), GC-1V 366 (Snowboar)





S22.    Sony

S22.1   SPU
- 0.93               : Changed name 'PSX_SPU' to 'SPU'.
- 0.84               : smf added PIO SPU ram writes, fixed status register read/write, internal mixer clamps output to 16 bits to fix distortion, state saves all registers, removed the need for casts by making the decoded sample buffer signed and DMA read/writes are limited to the SPU ram.
- 0.80u3             : R. Belmont added Konami GV System driver. The SPU emulation needs a lot of help, especially on Wedding Rhapsody. smf is working on it.
- 19th February  2004: smf added preliminary PSX SPU sound emulation and fixed the standalone MIPS disassembler.
-  6th February  2004: R. Belmont - The always fabulous Pete B. (http://sourceforge.net/projects/peops/) is donating his P.E.Op.S SPU code to MAME, so we'll have sound soon too.
- 15th January   2004: R. Belmont - smf is working on the PSX SPU (sound chip) which will get the rest of the sound working in the Konami GV games.
- 0.78               : Added sound\psx.c. Preliminary PSXSPU emulation [smf].
- NOTES: The Sony Playstation custom chips CXD2922 and CXD2925 are SPU's
- SOURCE: sound\psx.c
- PCB: Sony CXD2922CQ, QFP100 (Rvschool, Sfex, Sfex2), CXD2925Q (Brvblade), CXD2922BQ + CXD2925Q (Konami GV System)





S23.    Excellent Systems

S23.1   ES8712
- 0.95u6             : Quench added new ES8712 sound core, and hooked up sound in Varia Metal.
- NOTES: The ES8712 chip from Excellent Systems generates a singel channel ADPCM stream. Samples are currently looped, but whether they should and how, is unknown. Interface to the chip is also not 100% clear. Should there be any status signals signifying busy, end of sample - etc?. Core is heavily borrowed from the OKI M6295 source.
- SOURCE: sound\es8712.c
- PCB: ES-8712, es8712, chip is branded 'EXCELLENT' (Vmetal), ES-88712 (Gcpinbal)






S24.    Sound Systems


S24.1   Bally Midway sound boards

S24.11  Squawk & Talk
- 0.122u6            : Aaron Giles added clocks to the MCR sound boards and some of the MCR games. Added TMS5220 variants TMS5200 and TMC0285 as proper chips. Changed MCR squawk & talk to use the TMS5200 as documented.
- NOTES: Squawk & Talk sound board
- SOURCE: audio\mcr.c
- GAMES: Discs of Tron (1983), Mr. and Mrs. Pac-Man (198?)


S24.12  Chip Squeak Deluxe
- 0.97u5             : Aaron Giles updated memory maps for the MCR Chip Squeak Deluxe and Sounds Good boards.
- NOTES: Chip Squeak Deluxe is a 68000 CPU and DAC sound.
- SOURCE: audio\mcr.c
- GAMES: Bally Midway - Spy Hunt (1983), Zwackery (1984), Turbo Tag (prototype 1985)


S24.13  Turbo Chip Squeak
- NOTES: Turbo Chip Squeak is a M6809 CPU and DAC sound.
- GAMES: Bally Midway - Demolition Derby (1984), Sarge (1985), Max RPM (1986), Spy Hunter 2 (1987)


S24.14  Sounds Good
- 0.97u5             : Aaron Giles updated memory maps for the MCR Chip Squeak Deluxe and Sounds Good boards.
- NOTES: 'Sounds Good' is a 68000 CPU and DAC sound. Spy Hunter 2 uses a 'Sounds Good' and 'Turbo Chip Squeak' sound board.
- SOURCE: audio\mcr.c
- GAMES: Bally Midway - Power Drive (1986), Rampage (1986), Star Guards (1987), Xenophobe (1987), Blasted (1988)


S24.15  Midway/Williams Audio Boards
- 0.101u1            : Aaron Giles added save state support to the Williams sound boards. Cleaned up and fully mapped the Williams sound boards.
- SOURCE: audio\williams.c


S24.2   Sega

S24.21  G80 Universal sound
- PCB: Ixion, Razmataz


S24.3   Leland
- 1st generation sound hardware was controlled by the master Z80. It drove an AY-8910/AY-8912 pair for music. It also had two DACs that were driven by the video refresh. At the end of each scanline there are 8-bit DAC samples that can be enabled via the output ports on the AY-8910. The DACs run at a fixed frequency of 15.3kHz, since they are clocked once each scanline.
- 2nd generation sound hardware was used in Redline Racer. It consisted of an 80186 microcontroller driving 8 8-bit DACs. The frequency of the DACs were controlled by one of 3 Intel 8254 programmable interval timers (PITs). The clock outputs for each DAC can be read, and are polled to determine when data should be updated on the chips. The 80186's two DMA channels are generally used to drive the first two DACs, with the remaining 6 DACs being fed manually via polling.
- 3rd generation sound hardware appeared in the football games (Quarterback, AAFB) and the later games up through Pigout. This variant is closely based on the Redline Racer sound system, but they took out two of the DACs and replaced them with a higher resolution (10-bit) DAC. The driving clocks have been rearranged a bit, and the number of PITs reduced from 3 to 2. Like the 2nd generation board, the first two DACs are driven via the DMA channels, and the remaining 5 DACs are polled.
- 4th generation sound hardware showed up in Ataxx, Indy Heat, and World Soccer Finals. For this variant, they removed one more PIT and 3 of the 8-bit DACs, and added a YM2151 music chip and an externally-fed 8-bit DAC. The externally driven DACs have registers for a start/stop address and triggers to control the clocking.
- SOURCE: audio\leland.c - Driver by Aaron Giles and Paul Leaman


S24.4   DMA-driven DAC
- 0.113u3            : Couriersud added save state support to DMA-driven DAC.
- 0.112u4            : Aaron Giles removed a big pile of goofiness from the DMA-driven DAC driver now that it is no longer necessary.
- 0.79u2             : Added sound\dmadac.c.
- 19th February  2004: Aaron Giles added support for a DMA-driven DAC sound device.
- SOURCE: sound\dmadac.c
- GAMES: Midway - MK2 (1993), War Gods (1995), Carnevil (1998); Atari - Primal Rage (1994), TMEK (1994), Vapor TRX (1998)


S24.41  CAGE
- 0.79u2             : Aaron Giles added support for DMA based DAC 'sound chip' and updated DCS / CAGE to use it.
- 20th February  2004: Aaron Giles - I've decided to take a bit of a break from bending my mind on the 3D texture mapping to do some more core improvements (uh oh....) First thing I recently submitted is a "new" sound device: the DMA-driven DAC. This is essentially what the DCS and CAGE sound systems do. They start their chip's internal DMA controller, point it at the sample data, and let the DMA controller stream the data to the DAC(s). Since I had written this code twice (once for DCS, once for CAGE), and since the Gaelco 3D games use a similar technique, I decided to formalize the code into a new common sound device.
- 0.77               : Added sndhrdw\cage.c. Aaron Giles fixed frequency computation - CAGE now works ok!, added speedup mechanism, fixed positioning of the 4 voices.
-  9th November  2003: R. Belmont - CAGE works for T-MEK and Primal Rage. It doesn't work yet for Metal Maniax or San Francisco Rush (the 32031 does boot and act normally in those games, it just isn't responding to commands at the moment).
-  7th November  2003: Aaron Giles added the CAGE sound system emulation to Primal Rage (and a bunch of non-working drivers).
- SOURCE: audio\cage.c
- PCB: PCB Nr. A053304 (Tmek, Primrage, Metal Maniax)


S24.42  Midway DCS audio board
- 0.122u6            : Aaron Giles hooked up Revolution X DCS reset line. Signaled IRQ on correct CPU when DCS sends data back.
- 0.122u4            : Aaron Giles fixed crash when saving state of older DCS-based games.
- 0.122u1            : Aaron Giles fixed ROM-based DCS2 system to ignore HLE transfers (fixes broken sound in invasn). Properly reduced internal memory on the ADSP-2104 variants.
- 0.103              : Aaron Giles got the DCS-3 sound system working for Road Burners.
- 27th December  2005: Aaron Giles - I'm looking for someone out there who has a 2D Midway game with a DCS sound system. This would include Mortal Kombat 2, Mortal Kombat 3, NBA Hangtime, WWF Wrestlemania, 2 On 2 Open Ice Challenge, or Rampage: World Tour. Basically, I need to know how much RAM there is for the ADSP chip. If the system is on an external card, this is pretty easy, just identify the RAM chips on the card and let me know what they are. For the Wolf unit games, I think the sound system is on-board, so you'll just need to identify the smaller RAM chips (they will probably be 8kx8 or 32kx8 parts). In fact, knowing this info for the Cruisin' and Killer Instinct games would be useful as well.
- 0.84u3             : Aaron Giles cleaned up and reorganized the DCS sound module. This required changing the way ROMs are loaded for all of the DCS-using games.
- 0.81u6             : Aaron Giles added support for DCS HLE downloading via FIFO (used by Vegas games).
- 0.81u5             : DCS2 upload command HLE optimization (to make driver easier to work with) [Aaron Giles].
- 0.79u2             : Aaron Giles added support for DMA based DAC 'sound chip' and updated DCS / CAGE to use it.
- 20th February  2004: Aaron Giles - I've decided to take a bit of a break from bending my mind on the 3D texture mapping to do some more core improvements (uh oh....) First thing I recently submitted is a "new" sound device: the DMA-driven DAC. This is essentially what the DCS and CAGE sound systems do. They start their chip's internal DMA controller, point it at the sample data, and let the DMA controller stream the data to the DAC(s). Since I had written this code twice (once for DCS, once for CAGE), and since the Gaelco 3D games use a similar technique, I decided to formalize the code into a new common sound device.
- 0.78               : Aaron Gile fixed reporting of input full/output empty states.
- 31st  October  2003: Aaron Giles recently submitted an updated DCS sound engine that works 100% for WarGods.
- 0.72u2             : Removed DCS Speed-Ups.
- 0.63               : Added sndhrdw\dcs.c.
- 21st July      2000: Ernesto Corvi fixed the last remaining bugs in the inter-cpu communication in DCS emulation.
- 20th July      2000: Aaron Giles fixed the clipping in DCS emulation.
- NOTES: Theses drivers uses the DCS audio: kinst.c, midtunit.c, midvunit.c, midwunit.c and midxunit.c
- SOURCE: audio\dcs.c
- GAMES: DCS2 = Gauntlet Legends, Tenth Degree; DCS3 = Road Burners and San Francisco Rush 2049


S24.5   MSX AUDIO
- GAMES: Ginga NinkyouDen (Jaleco 1987), The Legend of Air Cavalry (SNK 1988), ChopperI (SNK 1988)
- PCB: SOUND: YM2149 Y8950(MSX AUDIO), SOUND: YM3812x1 / MSX-AUDIOx1 or SOUND: YM3526, MSX-AUDIO (?)


S24.6   Amiga custom sound
- 0.105u1            : Aaron Giles rewroted a large chunk of the Amiga emulation to support sound and additional video modes/effects including extra half-bright mode, manual sprites and mid-scanline changes. This is still a work in progress. Aaron also modified Arcadia driver which using empty RAM regions for RAM or had extraneous memory regions. Added Custom (3579545 Hz) stereo sound and changed visible area to 671x216 and VSync to 59.997002 Hz.
- GAMES: Arcadia Systems games (1987/1988)
- SOURCE: audio\amiga.c


S24.7   Seibu Sound System
- 0.124u1            : Stephh changed Seibu sound CPU to use AM_READ_PORT("COIN") (seibu_sound_map) instead of input_port_0_r.
- 0.122u6            : Aaron Giles cleaned up memory maps in the Seibu sound interfaces. Changed to use shared sound configs instead of statically copying them in each driver.
- NOTES: The Seibu sound system comprises of a Z80A, YM3812, YM3931 and OKI MSM6205. As well as sound the Z80 can controls coins and pass data to the main cpu. There are a few little quirks that make it worthwhile emulating in a seperate file: The YM3812 generates interrupt RST10, by asserting the interrupt line, and placing 0xd7 on the data bus. The main cpu generates interrupt RST18, by asserting the interrupt line, and placing 0xdf on the data bus. A problem can occur if both the YM3812 and the main cpu try to assert the interrupt line at the same time. The effect in the old Mame emulation would be for sound to stop playing - this is because a RST18 cancelled out a RST10, and if a single RST10 is dropped sound stops as the YM3812 timer is not reset. The problem occurs because even if both interrupts happen at the same time, there can only be one value on the data bus. Obviously the real hardware must have some circuit to prevent this. It is emulated by user timers to control the z80 interrupt vector.
- SOURCE: audio\seibu.c


S24.8   Vegas sound system
- NOTES: The Vegas Sound I/O boards consists of: Vegas SIO  - ADSP2104 (16MHz, boot ROM and 4MB RAM), Deluxe SIO - ADSP2181 (32MHz, no ROM and 4MB RAM) and Denver SIO - ADSP2181 (33MHz, no ROM and 4MB RAM).

- SOURCE: drivers\vegas.c
- GAMES: Atari/Midway Seattle games


S24.9   Data East Pinball soundboard
- NOTES: Tattoo Assassins is a prototype, only 25 test units were manufactured and distributed to test arcades before the game was recalled. Tattoo Assassins is the only game developed by Data East Pinball in USA.
- SOURCE: drivers\deco32.c
- PCB: Soundboard 520-5077-00 R (Tattass)


S24.A   Taito soundboard
- 0.37b8             : Added sndhrdw\taitosnd.c/h.
- GAMES: Taito - Rastan (1987), Rainbow Islands (1987), Superman (1988), Taito L-System, Taito F2 System and Taito B System



S25.    Synthesizer / MIDI


S25.1   SAM9773
-  8th June      2006: Pierpaolo Prazzoli - Started fixing / finishing Pasha Pasha 2 (which is Gotcha 2) driver with the new redump. The sound system uses an unemulated sound chip (DREAM SAM9773) plus 2 M6295, but unfortunately it uses a read protected mcu as sound cpu.
- NOTES: ATMEL DREAM SAM9773 Single Chip Synthesizer/MIDI with Effects and serial interface, clock 9.6MHz, TQFP80 (Pasha2)


S25.11  SAM448
- PCB: SAM448-20J (F15se), UV erasable microprogram sequencer/Special Application Memory Device from Waferscale Integration


S25.2   ICS2115
- 0.81u3             : Olivier Galibert added preliminary PGM sound emulation. It has bad sounds now and causes crashes for now.
- NOTES: Driver by O. Galibert and ICS emulation by Elsemi (Nebula Emu.). The ICS WaveFront-2115 Wavetable midi syntesizer are used in some actual sound cards (Turtle Beach).
- SOURCE: sound\ics2115.c
- PCB: WAVEFRONT ICS2115V, PLCC84 (PGM System)


S25.3   QS1000
- NOTES: Wavetable Audio chip from AdMOS (http://www.hwass.co.kr/product.htm). The General MIDI Chipset QDSP 1000 MIDI Player (80c32 CPU), MIDI 16th Channel(32 Poly) using as Effect EPROM (512Kb) and MIDI Background Music EPROM (512Kb)
- SOURCE: drivers\eolith.c, ssfindo.c, vamphalf.c
- PCB: QDSP QS1000 AdMOS 9638R, QFP100 (Ssfindo, Misncrft, Raccoon)

       Wavetable roms for the QS1000 are:

       QS1001: QDSP QS1001A Wavetable audio chip. 512k x 8 ROM, SOP32 (Hidctch2/3, Nhidctch).  1M ROM manufactured by AdMOS (Now LG Semi.), SOP32  (Misncrft, Raccoon), QS-1001A (Crazywar)
       QS1003: (Legendoh)
        1008S: HWASS 1008S-1 Wavetable Audio Samples chip, 1MB x 8 MaskROM, SOP32 (Ssfindo)
     NASN9289: Re-badged ROM. Should be compatible with existing QS100x Wavetable Audio Sample ROMs (dumped as 1M x 8 SOP32 MaskROM) (Ppcar)


S25.4   KS0164
- NOTES: Manufactured by Samsung. General Midi compliant 32-voice Wavetable Synthesizer Chip. Omni Wave Synthesizer (Dedicated-Special Application Linear Circuit) 
- NOTES: The 16-bit CPU core was Sequoia's design and was licensed to Samsung. It was a 16-bit core with a nearly perfectly orthogonal instruction set. You could even multiply the PC by the stack pointer if you wanted.
- PCB: SEC KS0164 (running at 16.9MHz), QFP100 (Xfiles, Kdynastg,Fishing Maniac 3)


S25.5   VRender0
- 0.93               : Changed name 'VRender_Zero' to 'VRender0'. Aaron Giles fixed a clipping bug that was lurking there (negative clipping wrapped to positive values -- noticeable at 32-bits).
- 0.90u3             : Lawrence Gold fixed Vrender0 sound broken in 0.90u2.
- 0.90               : VRender Zero emulation [ElSemi].
- NOTES: The CRYSTAL SYSTEM using a VRender0 System on a Chip. The chip contains: CPU Core SE3208 (info at www.adc.co.kr) @ 43Mhz, 2 DMA chans, 4 Timers, 32 PIO pins, PWM output, 32 channels wavetable synth (8bit linear, 16bit linear and 8bit ulaw sample format) and Custom 2D video rendering device (texture mapping, alphablend, roz)
- SOURCE: sound\vrender0.c
- GAMES: The Crystal of Kings (Brezzasoft 2001), Evolution Soccer (Evoga 2001)
- PCB: MESGraphics VRenderZERO (all-in-one main CPU/graphics/sound, QFP240) (Crysking)





S26.    Speech processors


S26.1   DAC Speech
- 0.34b3             : Brad Oliver fixed speech in King & Balloon. Ernesto Corvi fixed speech in Karate Champ.
- 0.36b1             : Zsolt Vasvari added "Get Ready!" speech to Grobda. The hardware in Grobda automatically cycles the bottom 6 address lines of sound RAM, so they probably added a latch loaded when the bottom 4 lines are 0010 (which corresponds to locations not used by the sound hardware). The program writes the same value to 0x02, 0x12, 0x22 and 0x32. However, removing the 15XX from the board causes sound to disappear completely, so the DAC might be built-in after all (see drivers\mappy.c).
- 0.33b2             : Nicola Salmoria added speech to Champion Baseball.
- 0.31               : Nicola addes speech in Mat Mania.



S26.2   Texas Instruments

S26.21  TMS0285

- 0.72u1             : Nathan Woods added support for the TMS0285 variant (an old variant of the TMS5220)
- NOTES: The tms0285 is an early variant of the tms5220 used in the ti-99/4(a) computer. The exact relationship of this chip with tms5200 & tms5220 is unknown, but it seems to use slightly different tables for LPC parameters.
- SOURCE: sound\tms5220.c


S26.22  TMS5100

- 0.122u2            : Couriersud added coefficient maps for TMS5100 and M58817 from documented sources to tms5110r.c. Also changed CVS driver to use TMS5100 according to PCBInfos and "game system operational" now sounds more natural.
- GAMES: Shooting Gallery (Seaton Grove/Zaccaria 1984)
- PCB: TMS5100ANL Speech (Shootgal), UMC 8923S-UM5100 voice processor (Filetto)


S26.23  TMS5110

- 0.122u7            : Couriersud added all known variants of the TMS5110 as proper chips. Updated dkong, cvs and scramble to use new chips.
- 0.122u4            : Couriersud completed TMS5110A code for the game 'A. D. 2083'. Working speech synthesis.
- 0.122u3            : Fixed TMS5110 tables [Couriersud, Lord Nightmare].
- 0.122u2            : TMS51xx and M58817 speech updates [Couriersud]: Removed sound/m58817.*. Added support for multiple coefficients maps to tms5110.*. Fixed interpolation factors (see tms5110r.c for reason). Made lattice calculation precision 9bit. Added support for READBIT and LOADADDRESS commands to tms5110.c. More changes in line with various patents. Documented TRS-02, TKG-02/03 "voice" interface.
- 0.111u5            : Lord Nightmare fixed PRNG noise in the TMS5110/5220 code and added signal wrapping to match the patent.
- 0.111u1            : Lord Nightmare fixed a problem with the chirp tables of both the tms5220 and the tms5110. Also backported Jarek's PRNG implementation from tms5110.c to tms5220.c so it no longer relies on rand().
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the TMS5110 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.101              : Aaron Giles added save state support to the TMS5110 sound chip.
- 0.94u1             : Aaron Giles fixed games using the TMS5110 (sound\5110intf.c) which refused to start (Bagman, cvs driver etc.).
- 0.93u1             : Aaron Giles adding missing memset when initializing the TMS5110 and TMS5220 structures; should prevent the crashes. And fixed signed/unsigned error in the TMS5110 core.
- 0.92               : Jarek Burczynski added real noise generator to TMS5110.
- 0.37b6             : TMS5110 emulator, used by Bagman and Super Bagman [Jarek Burczynski].
-  8th August    2000: Jarek Burczynski wrote a TMS5110 emulator and added speech support to Bagman.
- NOTES: "perform dummy read" is not mentioned in the datasheet of the TMS5110. However Bagman speech roms data are organized in such way so bit at address 0 is NOT a speech data. Bit at address 1 is data speech. Seems that the TMS5110 is performing dummy read before starting to execute a SPEAK command.
- SOURCE: sound\tms5110.c + 5110intf.c
- GAMES: CVS games, Valadon Automation - Bagman (1982) and Super Bagman (1984)


S26.24  TMS5200

- NOTES: This sound chip isn't emulated in MAME yet. MAME use for Jack Rabbit the TMS5220, so sound isn't accurate.
- GAMES: Zaccaria - Money Money (1983), Jack Rabbit (1984)


S26.25  TMS5220

- 0.123u2            : Atari Ace added some missing #if's to 5220intf.c.
- 0.122u6            : Zsolt Vasvari disabled code in the TMS5220 that set the Buffer Empty flag after a stop frame. This fixes Victory. This might be the incorrect fix but the old code wasn't working either.
- 0.118u6            : Lord Nightmare updated TMS5220 core to use shifts instead of divides for the parameter interpolation. Also added support for internal clamping to 8-bit output when using the internal DAC.
- 0.118u2            : Further improvements to the TMS5220 emulation and more unification with the TMS5110 core [Lord Nightmare].
- 0.118              : Modularized the TMS5220 code [Lord Nightmare].
- 0.111u5            : Lord Nightmare fixed PRNG noise in the TMS5110/5220 code and added signal wrapping to match the patent.
- 0.111u2            : Lord Nightmare added missing initialization to the TMS5220 RNG.
- 0.111u1            : Lord Nightmare fixed a problem with the chirp tables of both the tms5220 and the tms5110. Also backported Jarek's PRNG implementation from tms5110.c to tms5220.c so it no longer relies on rand().
- 0.103u4            : Aaron Giles added stream_set_sample_rate() call and converted the TMS5220 sound core to output at their native sample rates, allowing the core sound system to perform over/re-sampling to the output rate.
- 0.100u4            : Aaron Giles added save state support to the TMS5220 chip.
- 0.93u1             : Aaron Giles adding missing memset when initializing the TMS5110 and TMS5220 structures; should prevent the crashes.
- 0.80               : Nathan Woods added a security margin in the estimate of the delay for speech synthesis ready line to come low (needed for a MESS side bug fix) in sound\tms5220.c
- 12th February  2003: Nathan Woods added support for TMS5220 speech ROM, though this feature is not used by any arcade game emulated so far.
- 0.37b6             : Changed name 'TMS5520' to 'TMS5220'.
- 14th February  2000: Aaron Giles modified TMS5220 and ADPCM sound cores to produce sound streams at correct sample rates.
- 11th July      1999: Raphael Nabet sent in a new version of TMS5220 emulator with support for speech rom. Phil Stroffolino sent in an update to the sprite manager.
- 0.30               : TI TMS5220 emulator [Frank Palazzolo]. This handles speech in Star Wars and other games. Aaron Giles added speech in Discs of Tron.
- NOTES: The TI TMS5220 Speech chip uses Linear-Predictive decoding scheme to produce speech from very compact data. It is virtually identical to the chip used in the landmark "Speak 'N Spell" toy produced in the '70s. This scheme is very similar to the U.S. Federal Standard LPC-10e coding system, which was developed soon after this chip. The TI speech chip contains a 128-bit parallel-in, serial-out FIFO, a 10-pole digital lattice filter which models the vocal tract, and a D/A converter. It was originally design to operate either with a microcomputer interface, or with a serial speech ROM. The Speech ROM functionality is now emulated, although no arcade games require it currently. The input data is writen a byte at a time into the chip, and it is decoded bitwise into variable length frames.
- GAMES: Looping (Venture Line 1982), Star Wars (Atari 1983), Gauntlet (Atari 1985), Road Blasters (Atari 1987)
- PCB: TSP5220 (720, Eprom), TMS5220 (Looping), 5220 (Victory)



S26.26  M58817
- 0.122u2            : TMS51xx and M58817 speech updates [Couriersud]: Removed sound/m58817.*. Added support for multiple coefficients maps to tms5110.*. Fixed interpolation factors (see tms5110r.c for reason). Made lattice calculation precision 9bit. Added support for READBIT and LOADADDRESS commands to tms5110.c. More changes in line with various patents. Documented TRS-02, TKG-02/03 "voice" interface.
- 0.122              : Couriersud wrote a M58817 sound driver and hooked it up to Radar Scope (TRS01). Uses TMS5110 speech synthesis. LPC format is identical, however coefficients seem to be different. Until coefficients are known, samples are used.
- NOTES: Structure from TMS5110 interface. This is a wrapper around the TMS5110 interface. M58817 & TMS5110 seem to be similar, however it is very probable that they use different "coding" tables for energy, pitch. Speech is understandable, but off. This driver supports to use a "sample" interface instead as well.
- PCB: M58815 (Dkong)




S26.3   Votrax SC-01

- 0.120u3            : Some build-related improvements to the sound cores [Atari Ace]: VOTRAX can now be built independentally of SAMPLES.
- 0.93               : Aaron Giles pulled out the dead Votrax core (was still being hard-compiled) and made it a proper sound type (which currently isn't included).
- 0.34b4             : Kevin Bales improved speech in Gorf. It now plays speech 100% accurately except for the missing samples.
- 0.31               : Alex Judd made better speech in Gorf.
- NOTES: Votrax SC-01 synthesizer uses 64 phoneme to produce speech. The PinMAME uses all original 64 phonemes (http://www.pinmame.com/ + http://pinmame.retrogames.com/).
- GAMES: Gottlieb games uses the Votrax speech chip in the revision 1 sound board (Q*bert and Reactor). The revision 2 games uses a GI SP-0250 speech chip.
- SOURCE: audio\astrocde.c, gorf.c and gottlieb.c



S26.4   TSI S14001A

- 0.122u7            : Zsolt Vasvari changed S14001A emulator to allow setting the clock frequency instead of the clock multiplier. This is how the real chip works. Changed the Berzerk driver to set the S14001A clock as per the schematics.
- 0.117u2            : Lord Nightmare connected S14001A speech to the Wolf Pack driver.
- 0.111u6            : Lord Nightmare added the missing volume and frequency controls to the Berzerk driver and s14001a core. Fixed the issue with random words being spoken instead of the proper ones. Word is now latched at the proper time.
- 0.111u5            : Lord Nightmare fixed a minor problem with sound clipping in the s14001a.
- 0.111u4            : Preliminary emulation of the TSI S14001A speech synthesizer as found in Berzerk/Frenzy (and also Stern pinballs) [Lord Nightmare, Kevtris, R. Belmont].
- NOTES: TSI S14001A emulator by Jonathan Gevaryahu ("Lord Nightmare") with help from Kevin Horton ("kevtris"). MAME conversion and integration by R. Belmont. The TSI S14001A speech chip produced speech with speech roms from the VSU-1000 board. Berzerk, Universal Research Laboratories/Stern Inc., 1980. Just passing a Berzerk machine was a new experience for most people. The machine actually spoke! Few people had experienced voice-synthesis at the time, and it made quite an impression. Because digitization was so expensive, the sentences spoken by Berzerk shared a vocabulary of only 30 words. The speech was done using LPC coding that I believe was invented by T.I., although I remember we used a National Speech chip in it. This was when speech and memory was expensive, so we didn't just digitize sounds and dump them out through a DAC. I remember it cost something like $1000 per word to have the compression done, so we tried to come up with a limited vocabulary which could be rearranged and reused as much as possible. There was some guy up in Silicon Gulch who did this stuff for a living - so it is possible to make money while talking in a monotone.
- GAMES: Stern - Berzerk (1980) and Frenzy (1982)
- SOURCE: sound\s14001a.c



S26.5   GI

S26.51  SP0250

- 0.102u5            : SP0250 update [Nicola Salmoria]: Added SP0250 speech chip to The Three Stooges. Streamlined the SP0250 emulation to avoid timing issues which were preventing 3 stooges from working. Fixed glitches in the speech that were caused by not resetting the filter stages when a speech frame is loaded. Made the SP0250 support the external clock rate. Changed the playback rate to match the real board by making the clock divider a reasonable number.
- 0.93               : Changed name 'GI_SP0250' to 'SP0250'.
- 0.72               : Added sound\sp0250.c. Support for GI SP0250 speech [Olivier Galibert].
- 27th July      2003: Olivier Galibert sent in support for SP0250 sound chip and Sega G80 speech board, adding emulated speech to Astro Blaster, Space Fury, Star Trek and Zektor.
- NOTES: The GI SP0250 is a digital LPC speech sound synthesizer (Sega G80 boards). http://www.dsplib.com/chips/sp025x.html
- SOURCE: sound\sp0250.c - Issues: Exact noise algorithm, exact noise pitch (probably ok), exact main frequency (probably ok), exact amplitude decoding (aka mantissa:exponent), 7 bits output mapping and whether the pitch starts counting from 0 or 1.
- GAMES: Sega - Astro Blaster (1981), Space Fury (1981), Star Trek (1982), Zektor (1982)
- PCB: G-80 Speech Synthesis chip (Astrob), GI SP-0250


S26.52  SP0256
- 0.111u1            : Added GI SP0256 Narrator Speech Processor [Joe Zbiciak]. Ported to MESS by Tim Lindner. Nathan Woods adding remaining MESS sound cores to the core MAME sources.
- NOTES: The SP0256-AL2 is a text to speech controller. It synthesizes 'alophones' to somethink like 'speech primitives'.
- SOURCE: sound\sp0256.c 
- PCB: GI-SP0256A-AL (Sauro)


S26.6   Hitachi HD38880 and HD38882

- NOTES: The Hitachi HD38880 is a speech chip with an EPROM interface (HD38882). Got-Ya just sends it a sound command (0-0x1a)
- GAMES: Fantasy (SNK 1981), Got-Ya (Game-A-Tron 1981) and Vanguard
- WEB: http://www.freepatentsonline.com/4435832.html
- PCB: HD38880BP, HD38882PA06 (Fantasy, Thehand)



S26.7   HC-55516

- 0.122u8            : Zsolt Vasvari reorganized exidy440 audio code to make it easier to eventually use the MC3417/18 emulation directly. Added MC3418 variant support to the HC55516 audio code.
- 0.122u7            : Changed name 'HC55516' to 'HC-55516'. Zsolt Vasvari added the ability to the HC55516 emulator to take an external osciallator. Updated Mouse Trap to use the new interface. Added MC3417 and MC3418 variants to the HC55516 sound emulation. Changed Mouse Trap to use MC3417.
- 0.101u1            : Aaron Giles added save state support to the HC55516 sound chip.
- 0.36b9             : Aaron Giles make several changes and improvements to the TMS34010 emulation and to the Williams games using CVSD sound.
- 0.36b8             : CVSD sound in Mouse Trap [Dan Boris, Aaron Giles].
- 23rd October   1999: Dan Boris and Aaron Giles added the digital CVSD sound to Mousetrap.
- 0.36b7             : Aaron Giles rewritten the HC55516 CVSD decoder. This affects Sinistar, Joust 2, Arch Rivals, Pigskin, Tri-Sports, Smash TV, Trog, Narc.
- 11th October   1999: Aaron Giles sent in a CVSD/HC55516 rewrite, which sounds a little better.
- 0.35b2             : CVSD emulation, used for speech in Sinistar and in the 34010 games (Smash TV etc.) [Larry Bank, Alex Pasadyn]. Alex Pasadyn emulated speech in Sinistar. Samples are no longer used.
- NOTES: Harris HC55516 CVSD decoder
- SOURCE: sound\hc55516.c
- GAMES: Mouse Trap (Exidy 1981), Sinistar (Williams 1982), Joust 2 (Williams 1986), Narc (Williams 1988)
- PCB: Harris 55564 CVSD (Trog), HC3-55536 (Olibochu), HARISS HCI-55536-5 (Jangou)


S26.8   VLM5030

- 0.58               : Tatsuyuki Satoj fixed the VLM5030 emulation (Punch Out, Track & Field, Yie-Ar Kung Fu etc.).
- 23rd January   2002: Tatsuyuki Satoh added the 4800/9600bps parameter support to the VLM5030 sound chip emulation, fixing some speech in Jailbreak.
- 22nd January   2002: Tatsuyuki Satoh fixed the noise generator in the VLM5030 sound chip emulation, completely removing the need for samples.
- 21st January   2002: Tatsuyuki Satoh submitted a new, much improved version of the VLM5030 sound chip emulation, used for speech in (Super) Punch-Out and a few other drivers. It is now more than 90% accurate to the original, and only a few small problems remain.
- 23rd July      2001: Tatsuyuki Satoh adjusted the speed parameter in the VLM5030 emulation.
- 19th July      2001: Tatsuyuki Satoh improved the filter parameter in VLM5030 emulation but it is still not perfect.
- 0.37b14            : Tatsuyuki Satoh improved speech in Double Dribble.
- 29th March     2001: Tatsuyuki Satoh improved the VLM5030 emulator a little, but further progress will be very difficult without the exact decoding algorithm.
-  4th October   1999: Tatsuyuki Satoh sent in an update to his FM core with still incomplete LFO support (intro of Rock 'n Rage needs this) and some other bugfixes.
- 28th June      1999: Tatsuyuki Satoh fixed the VLM5030 and RC filter interface in Double Dribble.
- 0.35b13            : Tatsuyuki Satoh improved VLM5030 emulation.
- 10th May       1999: Tatsuyuki Satoh sent in a MUCH better version of the VLM5030 software emulator, but it is not yet quite as good as the samples, though better than the older one.
- 13th April     1999: Tatsuyuki Satoh and Ernesto Corvi added VLM5030 support for the Double Dribble driver.
- 12th April     1999: Ernesto Corvi sent in the Double Dribble driver made by Manuel Abadia, which only lacks colors and VLM5030 emulation.
- 0.33b6             : Tatuyuki Satoh fixed bug in VLM5030 emulator which caused samples not to work.
- 0.33b3             : Tatsuyuki Satoh updated the VLM5030 emulation (Punch Out etc.). Since quality is still bad, the emulator is only used when samples are not available.
- NOTES: The VLM5030 speech emulator based on the TMS5220 driver. NOTES: 9bit DAC is composed of 5bit Physical and 3bitPWM. TODO: Noise Generator circuit without 'rand()' function.
- GAMES: Punch-Out!! (Nintendo 1984), Road Fighter (Konami 1984), Yie Ar Kung-Fu (Konami 1985)
- SOURCE: sound\vlm5030.c



S26.9   SSI263
- PCB: SSI263 Speech Synthesizer - Thayer's Quest (RDI 1984)



S26.A   NEC

S26.A1  uPD7756
- NOTES: The uPD7756 is a speech processor with internal rom and not emulated yet.
- PCB: D7756 - Moero Pro Yakyuu Homerun (Jaleco 1988)


S26.A2  UPD7759

- 0.108u4            : Vas Crabb added save state support for uPD7759.
- 0.93               : Changed name 'uPD7759' to 'UPD7759'.
- 0.91u2             : uPD7759 rewrite, fixing sound in System 16 games [Aaron Giles].
-  6th September 2003: Olivier Galibert added support for silence compression and fixed the end-of-sample garbage and 4x command length in the UPD7759 sound chip emulator.
-  6th March     2003: Acho A. Tang fixed the wrong UPD7759 samples being played in the Twin16 driver, and he fixed a bug in the UPD7759 emulation that caused problems with playing the last sample.
- 0.65               : Acho A. Tang fixed some issues with uPD7759 (TMNT, 88 Games, P.O.W.).
-  9th February  2003: Acho A. Tang fixed various problems in the uPD7759 sound chip emulation, including a crash in the System16 driver and missing and/or incorrect sounds in TMNT, P.O.W. and '88 Games.
- 0.59               : Rewritten the UPD7759 emulator (used by TMNT etc) [Olivier Galibert].
- 12th February  2002: Olivier Galibert rewrote the UPD7759 sound chip emulation with far better accuracy and he fixed a few problems in the drivers that use it.
- 27th October   1999: Takahiro Nogi fixed UPD7759 problems in Vulcan Venture.
- 0.36b3             : Ernesto Corvi changed the UPD7759 emulator to support two chips ('88 Games needed this) and fixed a bug in the ADPCM decoding.
- 14th August    1999: Ernesto Corvi did a small bugfix update to UPD7759.
- 0.35b13            : Juergen Buchmueller improved uPD7759 ADPCM decode.
- 11th May       1999: Jürgen made the uPD7759 sound a little better and fixed some other things.
- 0.35b2             : NEC uPD7759 emulation. This is used by TMNT, System 16, and others [Juergen Buchmueller, Mike Balfour, Howie Cohen]. uPD7759 support in Golden Axe, Shinobi, Passshtb, Alien Syndrome, Altered Beast [Howie Cohen].
- NOTES: The UPD7759 is a speech processing LSI that utilizes ADPCM to produce speech or other sampled sounds. It can directly address up to 1Mbit (128k) of external data ROM, or the host CPU can control the speech data transfer. The UPD7759 is usually hooked up to a 640 kHz clock and has one 8-bit input port, a start pin, a busy pin, and a clock output. The adpcm converter converts nibbles into 9-bit DAC values. It has an internal state of 4 bits that's used in conjunction with the nibble to lookup which of the 256 possible steps is used. Then the state is changed according to the nibble value. Essentially, the higher the state, the bigger the steps are, and using big steps increase the state. Conversely, using small steps reduces the state. This allows the engine to be a little more adaptative than a classical ADPCM algorithm. The UPD7759 can run in two modes, master (also known as standalone) and slave. The mode is selected through the "md" pin. No known game changes modes on the fly, and it's unsure if that's even possible to do.
- SOURCE: sound\upd7759.c
- GAMES: Shinobi (Sega 1987), Altered Beast (1988), Combat School (Konami 1988), E-Swat (Sega 1989)
- PCB: uPD7758C or D7759C (TMNT), uPD7759C (Rabiolep), D7759C (Tmnt), D7759GC (Elvis), NEC 7759 (Pow)



S26.B   MSM5218
- PCB: OKI MSM5218RS ADPCM Voice Analysis/Synthesis IC (Jangou Lady)


S26.C   Alpha 88
- NOTES: MAME use a simple DAC interface for the Voice/Speech of the Alpha 88 (see alha68k.c)
- PCB: Alpha 88 Voice Chip (Sbasebal)





S27.    Other

S27.1   Melody Generator
- NOTES: The sound board of 005 (Sega 1981) generates a melody with an LS393 counter hooked to addr lines A0-A6 of a 2716 ROM. Port B from the 8255 hooks to addr lines A7-A10 of the 2716. D0-D4 output from the 2716 into an 6331. D5 outputs from the 2716 to a 555 timer. D0-D7 on the 6331 output to two LS161s. The LS161s output to the LS293 (also connected to 8255 B4). The output of this feeds into a 4391, which produces "MELODY" output.
- SOURCE: audio\segar.c

S27.2   Sample Generating CPU
- 13th December  2002: Zsolt Vasvari hooked up the background color and sample generating CPU in SF-X.


S27.3   Waveform Generator

S27.31  S2688
- NOTES: American Microsystems S2688P Waveform-Function Generator, Digital Noise Generator, VDD-14.0v (Buckrog)



S27.4   Noise Generator

S27.41  MM5437
- PCB: National Semiconductor MM5437 pseudo-random noise generator chip, DIP8 (Pairs)

S27.42  MM5837
- NOTES: The MM5837 is a noise generator. MAME has the code stolen straight from POKEY.c
- GAMES: Bally/Sente SAC-1 system games (balsente.c), Gridlee (Videa 1983)
- SOURCE: machine\balsente.c + drivers\gridlee.c
- PCB: 5837N (Buckrog/Zoom909)

S27.43  CDP1869
- 0.124u4            : Curt Coder added a macro for the CDP1869 interface, and made write handlers optional.
- 0.109u2            : Added support for CDP1869 sound [Peter Trauner].
- NOTES: The Cosmac RCA CDP1869 is a white noise generator. There are also the CDP1869/70/76 Video Interface Systems.
- SOURCE: sound\cdp1869.c


S27.5   TIA-MC1
- 0.108u1            : Added TIA-MC1 sound [Eugene Sandulenko]. Special thanks to Shiru for his standalone emulator and documentation.
- GAMES: Konek-Gorbunok (Terminal 1988)
- SOURCE: audio\tiamc1.c


S27.6   DSP

S27.61  Zoom Corp ZSG-2
- NOTES: DSP = Digital Signal Processor
- PCB: Zoom Corp ZSG-2 sound DSP, QFP100 (Taito GNET-System), ZOOM ZSG-2 (Ftimpcta, Gdarius, Raystorm)

S27.62  AN7395
- PCB: Panasonic AN7395S Spatializer IC (3-D Surround), SOIC20 (GTIClub)


S27.7   MESS sound cores

S27.71  Beep
- 0.37b14: Removed sound\beep.c.
- SOURCE: sound\beep.c

S27.72  Wave
- 0.37b14: Removed sound\wave.c.
- SOURCE: sound\wave.c

S27.73  SID
- 0.111u1: Added SID emulator [Peter Trauner]. Based on michael schwend's sid play. Noise generation algorithm is used courtesy of Asger Alstrup Nielsen. His original publication can be found on the SID home page. Noise table optimization proposed by Phillip Wooller. The output of each table does not differ. MOS-8580 R5 combined waveforms recorded by Dennis "Deadman" Lindroos.
- SOURCE: sound\sid.c, sound\sid6581.c (SID6581/SID8580), sound\sidenvel.c (ADSR volume envelope of the SID-chip), sound\sidvoice.c, sound\sidw6581.h and sound\sidw8580.h.




S28.    Extern

S28.1   Cassette Tape

- 0.37b7             : Phil Stroffolino added Thief and NATO Defense.
- 12th July      2000: Phil Stroffolino added cassette tape sample support to the Pacific Novelty games (Shark Attack, Thief, NATO Defense).
- 27th March     2000: Phil Stroffolino sent in a preliminary Thief driver, but only attract mode works.
- NOTES: Journey (Bally Midway 1983) use a music cassette tape.
- GAMES: Pacific Novelty - Shark Attack (1980), Thief (1981), NATO Defense (1982)


S28.11  Clarion 809
- NOTES: Tic Tac Quiz (Sega/Gremlin 1977) use the Clarion 809 cassette player. The tape deck is automobile stereotype that plays in either direction. The unit has no rewind capability even though it is a reel-to-reel system.


S28.2   CD Audio
- 0.93               : Changed name 'CD_Audio' to 'CD/DA'.
- 0.80u3             : R. Belmont added Preliminary CD-ROM support for CHDMAN. CDROM emulation primitives, including Red Book audio playback. Audio tracks on CDs are not compressed on a CD image at present (or more accurately they're gzip compressed, which is useless). The plan is to use FLAC at some point.
- 15th January   2004: R. Belmont - CD audio tracks now work for CHD-CDs, so Susume! Taisen Puzzle-Dama has background music.
- NOTES: CD-DA "Red Book" audio sound hardware. Relies on the actual CD logic and reading in cdrom.c
- GAMES: STV, Konami GV-System





S29.    Extra

- 12th April     2001: David Graves added the subwoofer emulation to darius2d and fixed a few other problems.
- 0.35b2             : Sound fade timer ports in the CPS1 games (see Willow's Test mode for an example) [Paul Leaman].


S29.1   MB87078
- 0.37b14            : Added machine\mb87078.c. MB87078 emulation, used by some Taito B games [Jarek Burczynski].
-  7th March     2001: Jarek Burczynski added MB87078 (an electronic volume control) emulation to the Taito B driver.
- NOTES: The Fujitsu MB87078 is a 6bit 4channel electronic volume control. An excerpt from the datasheet about the chip functionality: "A digital signal input controls gain every 0.5 dB step from 0dB to -32dB. Gain variable range: 0 dB to -32 dB by 0.5dB or -infinity, Gain variable range is expanded to connect two channels serially (0 dB to -64 dB), Each channel gain can be set respectively, Test function is provided (to confirm internal data), Data is initialized by reset signal (all channels are set to 0dB) and Logic I/O is TTL comatible". There are 6 digital data input/output pins and DSEL pin that selects the group (there are two) of internal registers to be read/written.
- SOURCE: emu\machine\mb87078.c
- PCB: MB87078P, SOIC24 (Gp500, Landgear, Spacedx)


S29.2   Toshiba

S29.21  TC9176
- PCB: Toshiba TC9176P High Efficiency Electronic Volume, DIP16 (CPS2)

S29.22  TC9185
- PCB: Toshiba TC9185P Electronic Volume Control IC, DIP20 (CPS2)


S29.3   AN5836
- PCB: Matsushita AN5836 DC Volume and Tone Control IC, SIL12 (NintendoSuperSystem)


S29.4   BA3121
- PCB: Ground Isolation Amplifier/ Noise Eliminator, SOIC8 (Gamshara, Mrdrilr2)


S29.5   SSM2047
- PCB: SSM2047 = Sound generator circuit (Botss, F15se)

S29.51  SSM2300
- PCB: SSM2300 = Sample and hold amplifier (F15se)


S29.6   TEA6320
- PCB:  Philips TEA6320T Sound fader control circuit (Area51)




S30.    Audio Amplifier


S30.1   Fujitsu

        MB3615       (Shadfrce, Agress)
        MB3712       5.7 Watt Power AMP, SIP8 (Champbwl, Tripool)
        MB3722       (Hcrash)
        MB3730       (Rezon, Thepit)
        MB3731       SIP12 (40love, Daikaiju, Tokio)
        MB3733       Power Amp IC (SegaSystem16B)
        MB3735       15W Power AMP with dual output used for stereo sounds (Sci, Viofight, Nastar)
        MB3771       Power Supply Monitor with Watch Dog Timer (i.e. Reset IC) (Raystorm), MB3771, MB3771F, 3771, DIP8, SOIC8 (Evilston, Gollygho, Gunbird2, Luckywld, S1948II)
        MB3773       DIP8 (Gstriker, VGoalSoccer, Capcom ZN1, SegaSystem16B)
        MB3790       (Drifto94)

        WIP:
        MB3773
        - 0.84: Added MB3773 emulation.
        - SOURCE: emu\machine\mb3773.c
        - PCB: Fujitsu MB3773, DIP8 (Gstriker, VGoalSoccer, Capcom ZN1, SegaSystem16B)



S30.2   Hitachi

        HA13001      Dual 5.5W Power amplifier IC (Nintendo Super System, NeoGeo, Gotcha)
        HA13118      18W audio amplifier (Loderndf, rdft2)
        HA1366       HA1366W audio amplifier (Hyperspt, Trackfld)
        HA1368       (Cafedoll)
        HA1377       HA1377A (Combh)
        HA1384       MA1384 (Hparadis)
        HA17408      (Kabukiz)
        HA17555      (Wwjgtin)



S30.3   Japan Radio Co.

        JRC2902      Quad Operational Amplifier, SOIC14 (Polystar, Konami-M2)
        JRC2904      Dual Low Power Op Amp, SOIC8 (NintendoSuperSystem)
        JRC3404      Low Power Quad Op AMP, DIP8 (Champbwl)
        JRC4560      Op Amp IC, DIP8 (Ejanhs, Rdft, Viprp1), 4560D (Brvblade, rdft2)
        JRC4556      JRC 4556-15268B  Audio Support? (Xmen)
        JRC4741      JRC4741 (Psikyo PS3-V1 hardware)



S30.4   National Semiconductor

        LM324        LM324N (Riot, Rockclim, Sichuan2, Spaceg, Trucocl, Vanvan, Youma), GL324 (Twinadv), CA324E (Ghostb), UA324PC (Phoenix)
        LM339        Embargo
        LM340        LM3401N (Invaders, Ozmawars), LM340T12 (Phoenix)
        LM348        Carnival
        LM358        Low Power Dual Operational Amplifier, SOIC8 (Cbaj, Gp500, Glpracr, Sfex2, Surfplnt), LM358N (Snookr10), LN358N (Ttchamp)
        LM377        LM377N sound (Mrdo)
        LM380        LM380N amp chip (Shuttlei, Spaceg, Chameleon 24-in-1)
        LM383        LM383T is a 5 pin audio Amp (Pntnpuzl)
        LM385        LM385 is a adjustable Micropower Voltage Reference Diode, SOIC8 (CPS3)
        LM393        (Unknown SEGA game)
        LM458        458 (Shuttlei)
        LM613        LM613 (Maxforce)
        LM741        LM741CN (Hustler, Mplanets)
        LM833        Dual Audio Operational Amplifier, DIP8 (CPS2, Rvschool), ST Microelectronics LM833N Low Noise Audio Dual Op-Amp, DIP8 (CPS3), 
        LM1203       Video out - DIP28, CRT output/drive PreAMP & Comparitor, LM1203N (Namco Classics Vol.1/2 (1995/6), Mega Touch 3/5)
        LM1877       (Astinvad)
        LM3900       LM3900N (Cyclshtg, Headoni, Ladyfrog, Spaceg, Victnine)
        LM7805       LM78L05 (Maxforce), LM7805CV (Drgnwrld)
        LM7809       LM78L05 (Maxforce)



S30.5   NEC

        uPC324       uPC324C (Hcrash, Mjkojink, Wrofaero, Mjkojink, DDragon, SegaSystem16b), NEC C324C (Wrofaero)
        uPC624       uPC624C (Buckrog)
        uPC844       NEC uPC844C Quad High Speed Wide Band Operational Amplifier, DIP14 (PGM-System, Titlef, Model1)
        uPC1241      uPC1241H (HatchCatch, Pipeline, 3in1semi)
        uPC1242      uPC1242 (Shocking), UPC1242H (Sdmg2), uPD1242H (IQblock)
        uPC1318      uPC1318 (Armchmp2)
        uPC3403      NEC uPC3403 High Performance Quad Operational Amplifier, DIP14 (Vmetal), MC3403 (Gunforce, Pairs), 3403 (Pairs), NEC PC3403C (Csilver)
        uPC4064      UPC4064 (Titlef, SegaSystem32)



S30.6   NJMxxxx

        NJM2060      (Beastrzr)
        NJM2100      (Raystrom, Taito GNET-System)
        NJM3414      NJM3414A 70mA Dual Op Amp, SOIC8 (Gp500, Mrdilr2, NamcoSystem12), Y3414B (Ghostb)
        NJM5532      NJM5532 DIP8 (GTIClub, Polystar)



S30.7   Other

        4558         4558 Operational Amplifier, SOIC8 (NamcoSystem11, Kabukiz, NeoGeo, NCV1/2), KA4558 (Xfiles, Kdynastg), GL4558 (Sichuan2), C4558C (Csilver)
        AN7130       Single-Channel Audio Power-Output Amplifier (Taxidrvr)
        CA741        Intersil CA741 High Gain Operational Amplifier (Jchan)
        GL358        GL358 N16 Dual Operational Amplifier, Isup 2.0mV (Topshoot)
        IR3702       Sharp IR3702N Quad General Purpose Op Amp (Buckrog)
        KA22065      Samsung KA22065 4.6 Dual Power AMP (Pasha2)
        LF351        Fairchild LF351N Single/Input Operational Amplifier (JFET) (Turbo)
        LMC6484      CMOS Quad Rail-to-Rail Input and Output Operational Amplifier (Nbajamex, Harley)
        M51516       Mitsubishi M51516 Single-Channel Audio Power-Output Amplifier (Xsleena, Agress, Amidar)
        MC33274      Motorola MC33274 High Performance Operational Amplifiers + Comparators (Sidebs, Sidebs2, Landgear)
        MJM2904      MJM2904 (Koikois)
        NE5532       Dual (Low Noise) Operational Amplifier from Philips or Fairchild, NE5532, DIP8 (Glpracr, Gradius4, CPS2), NE5532AN (Sscope2), NJM5532 (Gticlub)
        NTE1423      NTE1423 5.7W, SIP8, Power Amplifier  (Ghosthunt, Tutstomb)
        TBA820       ST Microelectronics TBA820 1.2W Audio Amplifier (Poker)
        TS271        TS271CN  Programmable Low Power CMOS Single Op-amp (Skattv)



S30.8   Philips

        TDA1510      (Crzrally)
        TDA1515      (Kdynastg)
        TDA1518      (Titlef)
        TDA1519      Philips TDA1519A Dual 6W Stereo Power Amplifier, SIL9 (Crysking, JumppopAMP, PGM system), Philips TDA1519A 22W BTL/Dual 11W Audio Power Amplifier IC, SIL9 (Lastfght)
        TDA1554      tda1554q amplifier (Area51, Maxforce)
        TDA2002      TDA2002 sound (Headon2, Passsht)
        TDA2003      Cyclshtg, NYcaptor
        TDA7240      TDA7240A is a 20W Bridge Amplifier (Nbajamex, Mk3)



S30.9   Sanyo

        LA4445       (Rockrage)
        LA4460       Sanyo 12W Power Amplifier, SIL10 (Djboy, Baraduke, Bruckrog, Bonkadv, SnowBros)
        LA4705       Sanyo LA4705 15W 2-channel Power Amp, SIP18 (MrDriller2, NamcoSystem12)
        LA6324       LA6324N = High-performance quad operational amplifier, DIP14 (Fantasy)



S30.A   Toshiba

        TA7222       5.8 Watt Audio Power Amplifier, SIP10 (Headoni, Vmetal)
        TA7252       Toshiba TA7252AP 5.9W audio power amplifier (Pkgnshdx)
        TA7630       NOTES: In Buggy Challenge the 7630 chips controlls the MSM5232 sound chip outputs (bass/treble, volume/balance). - GAMES: Buggy Challenge (Taito 1984), Forty-Love (Taito 1984), The FairyLand Story (Taito 1985), - SOURCE: drivers\40love.c, flstory.c, msisaac.c, nycaptor.c, buggychl.c
        TA7900       Toshiba? TA7900S (Gberet)
        TA8030       TA8030S - WatchDog Timer, might be controlled by JP1 ??? (Dfeveron)
        TA8139       TA8139S (11beat, Mtetrisc)
        TA8201       Toshiba TA8201 18W BTL x 2-Channel Audio Power Amplifier, TA8201 (CPS3, 11beat, Mtetrisc)
        TA8205       TA8205AH (Nslasher), TA8205 (Nitrobal, Schmeisr)
        TA8210       Audio AMP (Seta SSV system)
        TA8225       Toshiba TA8225L 45W BTL Audio Amplifier, ZIP17, TA8225H (Model1), TA8225L (CPS2)



S30.B   TL0xx

        TL062        ST Microelectronics Dual Low Power Operational Amplifier (DIP8), (Pasha2, Model1)
        TL074        JFET Lo Noise Quad OP Amp (Sci, Goundfx, Nastar, Viofight)
        TL082        (Legendoh)
        TL084        (Buckrog, Flytiger, Gollygho, Luckywld, Sega-System16B)





S31.    Potentiometers

S31.1   VR
- NOTES: Potentiometer for sound volume/brightness/...
- PCB: VR1-4 (Spaceg), VR1/2/3 (Headoni), VR1 Volume Pot (Mrdrilr2)

S31.2   RV
- PCB: RV1/2, RV3/4 (Mermaid)

S31.3   DS1267
- PCB: DALLAS DS1267 digital potentiometer (Botss, F15se)





 


PROTECTION

  0.    The Decapping Project
  
  1.    Alpha Electronics
  1.1   ALPHA-8201
  1.2   ALPHA-8301
  1.3   8302
  1.4   8303
  1.5   8304
  1.6   8333
  1.7   8404
  1.8   8511
  1.9   8713

  2.    Atari
  2.1   Slapstik
  2.2   SLOOP

  3.    Capcom
  3.1   CPS2
  3.2   CPS3

  4.    DALLAS
  4.1   DS1204
  4.2   DS5002FP

  5.    Fujitsu
  5.1   MB8841
  5.2   MB8842
  5.3   MB8844
  5.4   MB8851
  5.5   MB8852
  5.6   MB14241
  
  6.    Intel
  6.1   I8031
  6.2   80C31
  6.3   80C32
  6.4   I8051
  6.5   I8052
  6.6   I8741
  6.7   I8742
  6.8   I8748
  6.9   I8749
  6.A   I8751
  6.B   I8752
  6.C   87C751
  6.D   89C51
  6.E   89C52
  6.F   89C55
  6.G   90C32

  7.    Komami
  7.1   051550
  7.2   051733
  7.3   052591
  7.4   Konami ESC

  8.    Microchip PIC-MCU
  8.1   PIC16C54
  8.2   PIC16C55
  8.3   PIC16C57
  8.4   PIC16C84

  9.    Motorola
  9.1   M68701
  9.2   M68705
  9.21  M68705 MCU rom
  9.22  MC68HC705
  9.3   MC68HC11

 10.    Namco
 10.1   Cxx
 10.2   C68
 10.3   C69
 10.4   C70
 10.5   C71
 10.6   C74
 10.7   C75
 10.8   C76

 11.    National Semiconductor
 11.1   COP410
 11.2   COP420

 12.    Nichibutsu
 12.1   1411M1
 12.2   1412M2
 12.3   1413M3
 12.4   1414M4
 12.5   NSC8105

 13.    Nintendo
 13.1   Nintendo VS System (VSNES)
 13.2   Playchoice security chip
 13.3   Aleck64 (Nintendo64 based hardware)

 14.    Sega
 14.1   Sega encryption

 15.    Seibu
 15.1   COPX-01
 15.2   COPX-02
 15.3   COPX-03

 16.    Texas Instruments
 16.1   TMS32010
 16.2   TMS32015
 16.3   TMS32020

 17.    Taito
 17.1   C-Chip

 18.    Other
 18.1   Program Protection
 18.2   Random Number Generator
 18.3   Opcode encryption
 18.4   DL57S22
 18.5   Toshiba T5324
 18.6   Mitsubishi M50747
 18.7   ASIC
 18.8   CAT702
 18.9   Address lines scrambling
 18.A   Dongle
 18.B   Custom security
 18.B1  Epoxy block
 18.B2  BBX

 19.    Programmable Logic Devices (PLDs)
 19.1   PAL
 19.2   GAL
 19.3   CPLD
 19.4   FPGA
 19.5   Other

..................................................................................................................................................................................................................................




P0.    The Decapping Project

- 27th February  2008: Guru - I've struck a deal with a company that does IC security work to process most, if not all of the micro-controllers that I'm currently holding. This includes the following chips and possibly more that may come my way in the near future: BSMT2000, All remaining Namco custom MCUs (i.e. 59xx, 62xx etc), NMK004, Sega Model 1 TGPs, Namco customs C70, C75 & C76, Sound MCUs from Vimana and Teki Paki, QSound chips from Capcom ZN1 and CPS1/2), Kaneko Beast (DJ Boy, B Rap Boys), Kaneko Mermaid (Heavy Unit), C-Chip from Bonze Adventure, Sound MCUs from Fix Eight and Knuckle Bash, MCU's from Victorious Nine, Xain'd Sleena/Solar Warrior, Alcon, Prebillian, Tokio and possibly others that I can find, MCU's from Joshi Volleyball, Meikyuu Hunter G, Super Qix, Gladiators, Tatakae! Big Fighter and possibly others, Every PIC16C621A that I have here (maybe 20, used by GDROM-based games), Sound MCU from Dynamic Shoot & Moero Proyakyuu Home Run, MCU from Kyuukyoku Tiger, MCUs from NBA Jam Extreme and Primal Rage II, MCU from NAOMI/Hikaru/HNG64 JVS I/O board and probably two or three other chips from a few Mamedevs. There will also be the possiblity of a few others including Gaelco's suicidal DS5002 from World Rally at a later date in a separate analysis project. This is a special Guru-deal with some conditions. To get this work done by a professional company would cost about $80k-$100k. This includes decapping and micro-photographing of maskROM and decapping plus UV-zapping of protection bits and readout of internal EPROM. We can wait for an unknown period of time for one or two other people to try their attempts at about 10% of these with no guarantee of success. Make no mistake, most of these are beyond even the above average set-up. We're talking BIG dollars to process most of these chips. Or we accept the special Guru-deal and get it all for $7500. That's an amazing price when you consider to process one PIC16C621A costs $1200 per chip! On top of that, this company is also MAME-friendly and supports our cause.... one of the reasons why we're getting such a cheap price. Oh and they were influenced by my Guru-Charm, of course. They are also able to extract the ROM directly from the IC substrate so in some cases high-magnification of the die and tedious bit-analysis may not even be required..... they can suck the bits right off the chip directly! Of course, there's a problem. There's always a problem! I can cover $2500 of that, but to move forward I need to come up with the rest of the bucks. I'm hoping for assistance from out there in internet-land. As I said, this could be the most important day in emulation history providing the funds can be achieved. If you can help, simply click the Paypal Donation button to the right. Thanks!
- 27th March     2007: Guru - Here's the next chip we've decapped in a little more detail (Namco 50XX). This shows the full chip die at approx 20X magnification (reduced to minimise the file size, the real image is 5X bigger) and is roughly pasted together from 6 separate images for your viewing pleasure.
- 10th March     2007: Guru - I've been thinking about how to defeat the protected MCU's that use EPROM. My theory is to unlock the chip by exposing only the protection fuse to UV light, which should then allow the chip to be read as an unprotected MCU (for example 68705P5's on many early Taito games, and Intel 8751 MCU's used on Sega S16/S18 and others). Of course, there is a catch. It requires a high quality microscope that can be connected to a PC. There is such a device available. In fact many models are available on eBay from a retail seller. Not cheap though! This one is probably the minimum required. It can magnify up to 90X and has a 3.3MP CCD camera. Those camera/mag. specs are the same as the pics I got from the Japanese lab which were used to successfully re-create the code from the Namco 54xx MCU. We'll still need the Japanese lab for decapping and photographing maskROM-based MCUs, but this type of thing can't really be done by someone else, it needs a hands-on approach and lots of time. This method just might work well enough to allow reading the chip in it's unprotected form. According to MCU protection specialists (http://www.cl.cam.ac.uk/research/security/tamper/), the method I have described is one of the well known methods used to defeat EPROM-based MCUs. We could do the same, given the equipment. The only problem now is lack of funds.
-  5th February  2006: With the successful 'decap dumping' of the MCU from Bubble Bobble, it got us (MAMEDev) thinking if we could do this with a few more chips. Thus the 'Decapping Project' was born.
- NOTES:
         The Problem: The development of some games in MAME is sometimes not accurate or has come to a halt because of missing code from protection devices. Emulation problems exist because custom chips on PCBs contain special code that is usually protected and therefore undumpable and the game will not work correctly without that code. Trying to fake that chip by simulating it with guessed code is not always the best way and sometimes isn't even possible at all.
         The Solution: One method used to defeat this kind of protection is to decap the chip and extract the 'bits' using manual extraction methods. This means the top of the chip is removed using fuming nitric acid (>98% pure nitric acid) then rinsed with acetone (and repeated many times) until the chip die is exposed. Then the chip is placed under a microscope and magnified pics are taken of the chip die (usually X100 or greater magnification) and the resulting images are processed manually to obtain the contents of the ROM. Unfortunately this method is time consuming, requires expensive equipment and is extremely hazardous to health (and we value our vital body parts like fingers and eyes dearly). So we are using the services of a professional decapping laboratory to help us with the decapping and magnification tasks. The total cost for each chip is approximately US$330. This includes decapping and enough X100 pics to give us the image of the ROM. Compared to buying the equipment ourselves (possibly around US$50000+) and dealing with the dangers involved, that cost is quite reasonable :-)
         The Rules: One of the main issues with decapping is that this method of data extraction can only be done with chips that contain MASKROM, it doesn't work for EPROM. In layman terms, MASKROM is kind of like an image of 0's and 1's that is 'moulded' into the chip die when it is manufactured. Those 0's and 1's are easy to see when magnified and given some time and experience can be decoded to produce binary code and/or data. This usually only works with older chips as many newer microcontrollers have added layers of protection and stealth that can defeat decapping methods and require much more effort and expense.
         The Myths: Regardless of whether we're successful with a particular chip or not, decapping is a fool-proof method that gives us a 100% solution of gained knowledge. There is no other way to know for sure about the contents of any custom chip except to decap the chip and find out what's inside. Some people say it's possible to probe chips, figure out what type they are, then wire them up and dump them or blackbox them using an army of logic analysers. Many of those people have not actually produced any evidence of this and are not living in the real world. The only way to obtain the truth is 'The Right Way(tm)'
         The Participants: The chips we're mostly concerned about are Micro-Controller Units aka MCU's or custom chips from mid 80's to late 90's arcade games containing MASKROM who's code is undumpable using normal methods. We're mostly guessing that many of these listed below contain MASKROM, but some may not. After some discussion, below is a list of chips that have been determined as possible candidates for decapping with additional info showing the games that used those chips and the status of the decapping effort.

         Chip Name / Part Number     Package       Found on

         6801U4 MCU                  DIP40         Bubble Bobble 
         6801U4 MCU                  DIP40         Kiki KaiKai. Same type of chip as Bubble Bobble, but instead of the Bubble Bobble dino there is a pic of the Kiki KaiKai knight 
         C-Chip                      SDIP64        Bonze Adventure 
         Other C-Chips               SDIP64        Rainbow Islands, Operation Wolf, Superman, Volfied, Mega Blast 
         Namco Custom 50xx           DIP28         Bosconian, Xevious 
         Namco Custom 51xx           DIP42         Bosconian, Dig Dug, Galaga, Pole Position 1 & 2, Xevious 
         Namco Custom 52xx           DIP42         Bosconian, Pole Position 1 & 2 
         Namco Custom 53xx           DIP42         Dig Dug, Pole Position 1 & 2 
         Namco Custom 54xx           DIP28         Bosconian, Galaga, Pole Position 1 & 2, Xevious 
         Namco Custom 56xx           DIP42         Dig Dug II, Gaplus, Grobda, Libble Rabble, Motos, Pac & Pal, Pacman & Chomp Chomp, Phozon, Super Pacman, Tower Of Druaga, Toy Pop 
         Namco Custom 58xx           DIP42         Dig Dug II, Gaplus, Grobda, Libble Rabble, Mappy, Phozon, Super Pacman, Tower Of Druaga, Toy Pop 
         Namco Custom 59xx           DIP42         Pac & Pal, Pacman & Chomp Chomp 
         Namco Custom 62xx           DIP28         Gaplus 
         Kaneko Beast                DIP40         DJ Boy 
         Kaneko Mermaid              DIP40         Heavy Unit 
         Namco C67                   PLCC68        All Namco System 21 games. Trojan used to extract BIOS, decapping not required. 
         Namco C76                   QFP80         All Namco System 11 games 
         Kaneko MCUs                 QFP74         Jackie Chan, Shogun Warriors, BRap Boys, Blood Warrior, Gals Panic etc 
         Toaplan MCUs                QFP94         Fix Eight, Dogyuun, Knuckle Bash, Grindstorm, VFive, Batsugun 
         NMK MCU (NMK004)            QFP64         Macross, Gun Nail, Acrobat Mission, Vandyke, Thunder Dragon + more? 
         Toshiba T5182 MCU           NDIP50         Panic Road, Lost Castle in Dark Mist. Note: Decapping isn't required. The chip has a metal cover that is easily removed by de-soldering it, revealing everything as shown in the pic. 
         BSMT2000 (TMS32015 with mask ROM) DIP40    Used on Battle Toads, Police Trainer, Sharpshooter, Tattoo Assassins, Double Cheese, Fred Flintstones' Memory Match and Lotto Fun 2. Also used on Data East pinball machines. 
         CPS2 QSound sound chip      (DSP16A with mask ROM) PLCC84   Used on Capcom CPS1/2 and some ZN1/2 based Capcom games (Gallop Racer/SFEX/EX2 etc) 
         Fujitsu MB86233 'TGP' DSP   QFP160         Used on Sega Model 1, 2 & 2A 

        - WWW: http://www.mameworld.net/gurudumps/decap/index.html




P1.    Alpha Electronics

P1.1   ALPHA-8201
- 0.123u6            : Alpha Denshi major update [Nicola Salmoria]: Fixed Alpha 8201/830x MCU simulation. All hacks from the equites driver removed. Fixed equites restart position after going underground. Fixed hvolume, splndrbt 2 players. Removed hacks from exctsccr2. Fixed CPU gameplay in shougi. Added dump of Alpha 8201 MCU to games that use it (the ROM isn't used yet, HMCS44 CPU core needs to be written first).
- 0.109u5            : Aaron Giles converted the alph8201 disassemblers to the new format and added step in/out support where it was obvious.
- 0.104u8            : Tatsuyuki Satoh added emulation of the Alpha 8201/8301 MCU, and connected it to champbbj, champbb2, talbot, shougi, shougi2 and exctsccr.
- NOTES: Shougi (Alpha 198x) use a custom MCU ALPHA 8201 (DIP42). It's connected to the RAM that is shared with the first CPU.
- SOURCE: cpu\alph8201\alph8201.c
- PCB: Alpha8201 (Exctsccr), ALPHA 8201 DIP42 (Shougi)


P1.2   ALPHA-8301
- 0.104u8            : Tatsuyuki Satoh added emulation of the Alpha 8201/8301 MCU, and connected it to champbbj, champbb2, talbot, shougi, shougi2 and exctsccr.


P1.3   8302
- 12th September 2004: Pierpaolo Prazzoli added Exciting Soccer II protection (still at least one issue because you can't control the player).
- NOTES: The main purpose of the MCU is to control the program flow. This tables are actually subroutine addresses, wich get pushed onto the stack one after the other. Basically then the program runs and when it returns on one of these subroutines, it expects to land on the proper 'next' subroutine. All tables built manually from the analisis of the bootleg set.
- GAMES: Exciting Soccer (Alpha Denshi 1983) uses the ALPHA 8302 MCU.
- SOURCE: machine\exctsccr.c
- PCB: Alpha 8302 (Exctsccr) 

P1.4   8303
- NOTES: The 8303 controlled sound
- GAMES: Alpha Denshi - Bull Fighter (1984), Equites (1984), Splendor Blast (1985)
- SOURCE: equites.c - Lack of 8303/8404 tech info. All MCU results are guessed.
- PCB: Alpha 8303 44801B42 3M 3(Bullfgtr), ALPHA-8303 (Splndrbt), 8303 (Liberate), unknown 8303 (Shootout), ProSoccer, KamikazeCabbie, BoomerRang

P1.5   8304
- PCB: ALPHA-8304 (Hvoltage)

P1.6   8333
- PCB: 8333 = SY 6502A (Liberate)

P1.7   8404
- SOURCE: equites.c - The 8303/8404 have a lack of tech info. All MCU results are wild guesses.
- PCB: Hvoltage says ALPHA-8304 !!!

P1.8   8511
- PCB: ALPHA-8511, 40 pin (Skysoldr, TimeSold, Jongbou)

P1.9   8713
- PCB: ALPHA-8713 (Goldmedl)




P2.    Atari

P2.1   Slapstik

- 0.123u5            : Aaron Giles changed slapstic management to always install an opbase handler to more aggressively catch code executing in the slapstic region. Updated all drivers to separate the slapstic region of ROM into a different ROM section from the fixed ROM.
- 0.122u4            : Atari updates [Aaron Giles]: Added save state support to slapstic. Modified slapstic code to support address range mirrors.
- 0.96u3             : Aaron Giles simplified additive path in slapstic code. This should not impact any games that use it, but it is worth verifying (see atarisy1+2.c, atetris.c, harddriv.c and starwars.c games).
- 18th September 2002: Aaron Giles fixed the remaining issues with the Rampart slapstic behaviour.
- 15th November  2001: Aaron Giles added another version of Road Blasters that uses a different Slapstic chip.
- 0.53               : Added includes\slapstic.h.
- 30th July      2001: Aaron Giles finally ironed out the last Slapstic bugs, fixing Pit Fighter and Rampart for good.
- 21st June      1999: Nicola Salmoria finally fixed Empire Strikes Back's slapstic issues, and the game itself is playable!
- 22nd June      1999: Ernesto Corvi fixed the slapstic problems in Rampart. Nicola Salmoria fixed the slapstic problems in Xybots, and fixed Empire Strikes Back from hanging at the highscore screen.
- 20th June      1999: Nicola Salmoria and Ernesto Corvi fixed the slapstic issues in Gauntlet and Gauntlet 2.
- NOTES: The slapstic was a security chip made by Atari, which was used for bank switching and security in several coin-operated video games from 1984 through 1990. The slapstic generally sits between the CPU's address bus and one of the program ROMs. The son of slapstik is a protection chip called SLOOP.
       - The slapstic chip is a socketed DIP20 on the board and the number on the chip will be 137412-1xx.
- SOURCE: machine\slapstic.c


P2.2   SLOOP
-  6th February  2002: Aaron Giles re-submitted Zsolt Vasvari's and Jim Hernandez's Buck Rogers sample support, fixed the Blaster line fill and added the missing ASIC65 source file.
- NOTES: The SLOOP (or "SLOOPstic") is a follow-on chip to the slapstic. It provides a similar type of security, but is programmed onto a GAL6001, rather than a custom part. It was created because Atari was running out of slapstics to use in their games, and the original masks for the slapstic had been lost by the company that manufactured them. A separate FAQ for this chip is planned for the future.
       - Road Riot 4WD (1991): (Aaron Giles) The core hardware is pretty similar to Hydra, but the emulation suffers from the lack of understanding of a custom ASIC on the board. Apparently this ASIC is used for complex math operations, and improper emulation of it leads to incorrectly drawn roads and crashes. It is likely this game also uses a SLOOP (son-of-slapstik) chip for protection. The sound board is a standard Atari 6502, YM2151 and ADPCM board.
       - Guardians of the 'Hood (1992): (Aaron Giles) Runs on the same hardware as Road Riot 4WD, but seems to have a much simpler chip in place of the custom ASIC. On the other hand, it is still unplayable due to a lack of understanding of the SLOOP protection chip.
       - Space Lords (1992): (Aaron Giles) This is the first Atari game to use a 68020 processor. Other games to follow on similar hardware include Moto Frenzy, T-Mek, and Primal Rage. The video and sound hardware is quite similar to the previous games (Guardians of the Hood and Road Riot 4WD). However, the SLOOP chip appears to have gone away, only to be replaced by something equally sinister. Space Lords uses this chip to produce the palette for the sprites, which is why all the screenshots have incorrect colors. The protection chip is also used to produce some in-game parameters, making it nigh impossible to play without accurate emulation.
- GAMES: Atari G42 System - Guardians of the 'Hood and Road Riot 4WD



P3.    Capcom

P3.1   CPS2

- 0.112u2: Many more CPS2 keys added. Removed all XORs and support for them from MAME [Nicola Salmoria, Andreas Naive].
- 17th February 2007: Nicola Salmoria - CPS2 not much left to do: When I originally wrote the key searching program, that was on the assumption that the key for the second Feistel network was 96 bits long. Each (E,D) pair reduces the key space by a factor of about 2^16, so to isolate the correct key with good confidence one would need at least 96/16 = 6 (E,D) pairs. The big problem is finding those pairs. Remember that they must be at compatible addresses, that is addresses whose bottom 17 bits are the same. This is a serious limitation, because the code of several games only covers a range of 0x80000 bytes, which would give a maximum of 4 pairs at any address. For the Super Puzzle Fighter 2 games, the range is just 0x40000 bytes, giving just 2 pairs per address. One can find hundreds, even thousands of of (E,D) pairs, but if they are not at compatible addresses they are of no use to find the key using this attack. However, now we know that the key actually has only 64 significant bits, some of which are repeated. I therefore rewrote the program to take that into account. This means that only 4 (E,D) pairs are needed to isolate the key. Also, I made several important optimisations that I missed the first time around, like caching intermediate results and speeding up the s-boxes calculations by using precalculated tables (this last optimisation also made into MAME so the decryption when loading a game is now faster). The end result is a program that is orders of magnitude faster than the previous one. Now it takes just 15 seconds to find the key given 8 (E,D) pairs. With 5 pairs, which was just plain impossible before, it takes 5 minutes.
                                        With 4 pairs, 35 minutes. These improvement made it simple to find most of the remaining keys, even for games that didn't have a matching revision already decrypted (most notably some of the Steeet Fighter Zero versions). But there's more: the program is now fast enough to go one step further, and look for the key with just 3 pairs. Of course 3 pairs are not enough to isolate the right key: they only reduce the key space by about 2^48, therefore leaving about 2^16 keys which are compatible with the data. Once a 64-bit key for the second Feistel network is selected, the compatible 64-bit master keys can then be easily generated, and used to verify other (E,D) pairs at different addresses. This allows to find the correct key in less than one day, and I had to use this extended attack for a couple of the most problematic games. In the meantime, Andreas Naive has been busy implementing the attack he had described on his blog, and was able to find the keys for two of the Super Puzzle Fighter 2 games. Unfortunately, the attack failed on the third. Work is still in progress on that one, and there is some hope that the key will eventually be found. The only other games that are missing a key are the two CPS2 versions of Mega Man. There is no decrypted CPS2 version of that game to compare with, and the CPS1 version seems to be too different to be able to find good pairs.
- 0.111u5: Nicola Salmoria removed XORs from almost all CPS2 games in place of proper emulation of the encryption.
- 23rd January 2007: Guru - Here's a few pics of the very first custom chip that I sent to a professional Japanese IC decapping company that we (Mamedev) are using to help us with some MAME-related things. Hopefully if this is successful, more will follow and also hopefully talented hardware devs like JROK will be able to make replacements for it to repair real PCBs. You may also be wondering why we're doing this instead of using some other people who frequent the 'boards' who have offered to do this kind of thing for free? The answer is fairly simple.... apart from the amount of time it takes to get this done, the level of communication is somewhat 'sporadic' and so far offers to supply other chips to them have been ignored. We requested pics of some CPS2 ICs that were said to have been decapped and so far nothing has surfaced (over a month has passed since then). Doing it this way gives us more control over what we achieve and ensures the work is done in a timely manner. Apart from that, the plan to get this IC decapped has been in the works for several months, so we might as well use the professional IC decapping company whenever possible because the amount of ICs we need to decap is possibly too much work for someone to do in their spare time for free.
- 21st January 2007: Nicola Salmoria - CPS2 Key Bit Order: As previously mentioned, the 64-bit keys I'm currently using should be the same as the hardware ones, except for a fixed permutation of the bits. The permutation is actually irrelevant as far as the algorithm is concerned, since it is already taken into account when generating subkeys. The difference that it does make, however, is that there are strong suspicions that some of the keys are not random numbers, so what looks like random gibberish currently would show some order if we had the correct permutation. Take the ssf2 versions for example. There are currently 6 different versions supported: World, USA, Asia, Japan, Tournament World, Tournament Japan. Here are the keys (in a different order): 3D9E1E15A58C32CE, 3599DF35AD98284C, B74433502F4653D7, 8758E3923FFA1A50, F0AE3D08420DD6BF and 6260014FD857F7A7. There is something immediately obvious about those keys: they all contain exactly 32 0s and 32 1s. When picking one random 64-bit numbers, the likelihood of this happening is about 1 in 10, so it's ok. But the likelihood of it happening for SIX numbers is about 1 in 1 million! So we can be pretty sure that those keys are not random numbers. What is one particularly simple sequence that has exactly 32 1s? Well, of course 0123456789ABCDEF. And sure enough, after looking at the bits for a while and applying an appropriate permutation, here is what the above keys become: 0123456789ABCDEF, 1032547698BADCFE, 45673210CDEFAB89, 67451032FEDC98BA, 89ABDCEF45672301 and CDEFBA9823016754. Looks much better doesn't it? Though there's no way to tell how close it is to the real thing.
- 19th January 2007: Nicola Salmoria - CPS2 Moving Slowly Now: The improved attack works, and I've been able to recover a few more keys, but it takes a lot of computation time--several hours per game. I've also experienced some failures, e.g. I could find the key for dimahoo but not for gmahou. This might have been because of a false positive when looking for pairs with the complementation property, so now I'm trying again with a different pair. Since the searches take so long, experimenting isn't easy. On the plus side, I've applied the improved attack also to some games for which XOR files were not available, and it worked in a number of cases--though it failed in many others. One of the new versions supported is mshb, which I is the first Brazilian version of a CPS2 game to work. Andreas has published details on a theoretical attack using differential cryptanalysis which looks promising. If Andy's calculations are correct, it should allow to retrive the key for the three most problematic games: spf2t, spf2xj, and spf2ta. It does require a lot of (E,D,k) triplets, something in the order of 2^16-2^17, which is a bit steep, but we should be able to do that in a few cases. One thing to note about my attack, which I might not have explained clearly, is that it requires a remarkably small amount of data: it has worked for many games with just 7 (E,D) pairs. The problem is that those pairs must all be at the same address (as far as the encryption is concerned; that is, bits 1-16 of the address must be the same). Those 7 pairs allow to retrieve the 96-bit key for the second round at that address, and once that is known, the 64-bit master key can be found in less than 1 second, without having to know ANY other (E,D) pair at any address. Unfortunately for game like spf2t, whose full encryption range covers just 2 repetitions of an address, we are never going to have 7 pairs so the attack will never work.
- 17th January 2007: Nicola Salmoria - CPS2 The Fight Continues: I've finished going through all the games previously supported by MAME using XOR files, and generating keys using this attack (http://mamelife.blogspot.com/2007/01/how-to-bruteforce-cps2.html). The attack needs a minimum of 7 (E,D) pairs at some address in order to work, though with just 7 pairs it takes several hours to find the key. Most of the games provided at least 8 pairs, a few 7, so the attack worked. On 11 games the attack didn't work. Three of them only provide 2 pairs, so there's no way for the attack to work--a different approach will be needed. The others provide 4 pairs, and I'm now trying to still perform the attack, using a new trick. Remember the complementation property? For every address A, we know that exists another address A1 such that D(X, A) = D(X ^ 0xffff, A1) ^ 0xffff. The problem is that we don't know A1. We can search it, however, using the XOR data. Pick an address, look at the four (E,D) pairs associated to it, and then see if at another address there is a pair (E ^ 0xffff, D ^ 0xffff). That way we can put together the information from the two addresses, raising the number of pairs from 4 to 7, barely enough to run the attack. There's a possibility of false positives when doing this, so avoid all pairs where E or D are 0x0000 or 0xffff, because those values are very common and make the probablity of a false positive much higher. In theory this trick should work, though it will require some luck and a lot of time. The holy grail remains an attack which could use pairs from different addresses; that would be the only way to retrieve the key for the games that lack XORs.
- 14th January 2007: Nicola Salmoria - CPS2 Getting Closer: The correlations between the 96-bit keys of the two Feistel networks were crucial in getting the s-boxes with 4 or 5 inputs "in sync"--that is, make them idential to the real ones apart from a fixed XOR or permutation applied to the whole box. Eventually, I ended with a layout which I'm 99.9% sure is equivalent to the real one. We cannot know the exact contents of the real s-boxes without getting them from the actual hardware, but the current ones should be matematically equivalent. The result is here: http://xoomer.alice.it/nicola.salmoria/cps2crptv2.zip. The most notable news is that the key is now reduced to 64 bits, and the one we are currently using should be identical to the one used by the hardware, apart from a fixed permutation of the bits. Finding the real permutation would be nice, but obviously that's not something we can determine from the algorithm, since the order of the bits of the key is completely irrelevant. What is interesting to note is that the keys used by some games don't seem to be random. If they were random one would expect there to be around 32 0s and 32 1s, but sometimes this isn't the case. E.g.: pzloop2: 3332206a0077f829; mshj: 01c0c951370f4c80; dstlka: 04048b4e2a498879; ringdest: 0405541367806575 and cybotsj: 0404821534388354. Of these, the last three literally scream "I'm not a random number!". Guessing the right bit order to make something appear, of course, is another matter. Some of the watchdog values contain birth dates, e.g. cmpi.l #$19660419,D1, so I expect the same thing might be happening here. Also, it makes sense for the pzloop2 one to be more regular than the others because it's third party game. On the key extraction front, things are going reasonably well. The brute force attack described in the previous article is working decently on most games, however for some of them the available data isn't enough. I'll have a more precise list once I've finished going through all the games. After that, we'll need to devise a better attack if we want to get the missing keys. The discovery that the key is only 64 bits might help to construct a better attack, though at the moment I don't have many ideas. The fact that the algorithm is divided in two parts, with the output of the first one affecting the key on the second part, complicates things.
- 12th January 2007: Nicola Salmoria - How to bruteforce CPS2: I couldn't devise an attack using differential cryptanalysis and the XOR files. The fact that the second 96-bit key changes with the address makes thing more difficult, and I couldn't think of a way to effectively use data from different addresses. The XOR files give us no more than 8-16 (E,D) pairs at a given address (remember that the encryption only uses the low 16 bits of the address). We have no choice of what data we have, so we have to make the best of it. So the idea I had is to use a meet in the middle brute force attack which exploits a weakness in the s-boxes. Remember also that the fn round functions are made of 4 s-boxes each. These are the 16 s-boxes, with their inputs and outputs. f2b1 is the weakest link. It has only four inputs, 0246. To get those four inputs, we need just three boxes in round 1: f1b1, which outputs 67, f1b3, which outputs 14, and f1b4, which outputs 02. We don't need f1b2, which outputs 35. So if we start from the ciphertext and run it through the first two rounds of the Feistel network, scanning all 224 possible keys for f1b1, f1b3, f1b4, and f2b1, we'll get all possible values for bits 46 of R2. Now let's start from the plaintext instead, and go up. If we scan all 26 keys for f4b2, we'll get all possible values for bits 47 of R2 again. Now we impose that bit 4 calculated in these two ways is the same, and given enough (E,D) pairs we have a huge pruning of the valid keys. From experiments, at least 8 pairs are needed for the attack to work effectively, but with 12 it's faster. When we have a match on bit 4, we start adding more key bits, 6 or 12 at a time. First f4b4, to match bit 6 of R2. Then f1b2 and f2b3, to match bit 7 of R2. At this point, we are most likely already left with a single key, so adding more key bits doesn't increase the computation time. The important thing is to do it 6 bits at a time, in order to avoid unnecessary calculations. Soon enough, we have reconstructed the whole 96-bit key. This will be the key at a specific address--of course, before running the search we'd have scanned the whole data and selected the address with most different pairs, in order to make the attack more effective. After the 96-bit key at one address is found, the rest is easy. Since the 96-bit key is modified by the 16-bit result of the first FN in a fixed way, we just use brute force to find the correct 16-bit value at every address, and then we have a full subkey table as when we had the full 8GB tables at the beginning. The process is working reasonably well, it's taking me 20-40 minutes to find the 192-bit key for a game. It could be made faster, probably. I've done some games for which I had more data, and Razoola was kind enough to provide additional data that will help with many other games. I'm not yet sure that the attack will work on all games, but it surely will on a good percentage.
                                       Some very good news after obtaining more keys is that I found strong correlations between the first and second 96-bit keys, so they are effectively the same key, just permuted. This will also allow to fix the order of the subtables in the s-boxes of the first FN, in the same way I did for the second. Should we consider ourselves finished after that? Not yet: whether it will be possible to generate keys for games for which we lack XOR data is an open problem. In that case, the best we can expect to do is to match the startup code from a different version of the game, so we'll have several (E,D) pairs at consecutive addresses, and no more than one pair at a given address. A new attack will have to be devised in order to use that kind of information. Hopefully the discovery that the first and second 96-bit keys are correlated will help.
- 0.111u3: Andreas Naive and Nicola Salmoria replaced CPS2 CHDs with preliminary decryption function.
-  9th January 2007: Nicola Salmoria - CPS2 coming to MAME: I've submitted to MAMEDEV the code to replace the 4GB CHDs with 192-bit keys. It contains all the information needed to understand the algorithm, including the s-boxes. There is still a lot of uncertainty about the contents of the s-boxes. They do their job, but since they are different from the originals they also affect the key. Using the real s-boxes might make correlations between the key bits more apparent, if they exist (anyway, having only 7 keys to look at, there's not enough data to speculate on any kind of correlation). I'm hoping that it will be possible to extract the s-boxes contents from photos of the decapped CPS2 chip. That would be an important step forward in the accuracy of the emulation. Now the next challenge is finding the keys for the other CPS2 games that have XOR files but not full tables. I have some ideas, but it doesn't look simple. We have a lot of (E,D,k) triplets for those games, but unfortunately not many once you fix k (the 96-bit key used in the second FN), and that would be the most important part. Note that we don't have to find the whole 192-bit key all at once. Once the second 96-bit was found, then we could easily use brute force to get the 16-bit key seed at every address, and therefore easily find the first 96-bit key.
-  8th January 2007: Razoola - Nicola Salmoria of MAME Dev seems to have worked out the rest of the CPS2 algo (though there is still some s-boxes to complete), to quote his blog... * Take the 16-bit address and a 96-bit key and run them through the first Feistel network, to produce a 16-bit subkey. * Take the 16-bit ciphertext, 16-bit subkey, and another 96-bit key and run them through the second Feistel network, to produce the 16-bit plaintext. Our congratulations go out to him, again to Andreas Naive and also Charles MacDonald who all played a role to get to this point today. Looking back at the way things have gone from the first XOR release some six years ago (after the discovery of the main weakness in the system), we know some people were quite unhappy at our unwillingness to have this algo known for emulation (Statement of 7th Janurary 2001). It was always our intention to hold back information to help achieve this until the system was commercially dead (our view was 3 years after the last game released). It is very satisfying to know we achieved this as believe it or not Janurary 2007 is just past that three year mark (Hyper Street Fighter II was released in December 22nd 2003). I will update the encryption page with the details once Nicola has fully documented the Algo within MAME.
-  8th January 2007: Nicola Salmoria - CPS2 Fundamental Breakthrough: Today I realised why I was having problems with the correlations between subkey bits, where some bits had to be derived from the others not only using XOR, but also AND and OR. The reason was again in the s-boxes that only have 4 or 5 data inputs instead of the full 6. Those boxes contain 2 or 4 subtables, and the order of the subtables inside the box or the order of the bits inside each subtable isn't particularly important when decrypting a single address, because they can always be compensated by appropriate bits in the subkey. However, when putting all subkeys together, those things became important. E.g. I could be finding that when using subtable #3 in a box, then two of the inputs had to be inverted. To fix this, I had to rearrange the subtables inside the s-boxes to make everything in sync. The result was excellent. Previously, some of the correlations among the 96 bits were overly complex, taking up to 4 bits at once. Now every bit is directly correlated to another. The only exception is the bits that correspond to the "empty" inputs of s-boxes that take only 4 or 5 data inputs. What this means is that all 6 inputs of all s-boxes always receive the XOR of three sources: either a data bit, a key seed bit, and a global key bit; or two key seed bits, and a global key bit. That's only the beginning of the good news, though. After fixing the s-boxes, I could attack again the first part on the algorithm on the assumption it was a 4-round Feistel network, and indeed it was. So the algorithm turns out to be like this: Take the 16-bit address and a 96-bit key and run them through the first Feistel network, to produce a 16-bit subkey. Take the 16-bit ciphertext, 16-bit subkey, and another 96-bit key and run them through the second Feistel network, to produce the 16-bit plaintext. So now, for the first time, I would be able to produce a program that algorithmically decrypts one of the game for which we have full tables, without using any table. It's not yet time to celebrate, though: the s-boxes for the first Feistel network still have to be properly determined, and this might require having access to some more games. Once that is done, producing keys for games that we have complete tables for will be quite simple. Finding keys for games for which we don't have full tables, however, is an entirely different matter. As said above, we are potentially dealing with a 192-bit key here; it's possible that the key is smaller and the bits are reused, however since we don't know how they would be, we have to treat it like a 192-bit one. For a key of that size, obviously brute force is out of the question; and while the XOR tables do provide some information, it's probably not the kind of information that would allow to use the differential cryptanalysis techniques we'd need.
-  7th January 2007: Nicola Salmoria - CPS2 Won't Be Tamed That Easily: Some people thought we were almost finished with the CPS2 algorithm, but this doesn't seem to be the case. True, at least the 4GB tables could now be replaced with a single 128kB table, but that's still not how the hardware works, and it wouldn't be possible to generate proper keys for the games that are missing the full 8GB tables, which is the main concern. From the full tables, we can extract a 96-bit subkey for every address. These wouldn't be the actual keys used by the hardware, however I think me and Andy have agreed that they are, apart from a fixed XOR and bit permutation that wouldn't change from game to game. So we can forget about this step of the decryption for the time being, and move on. The problem now is to understand how the hardware generates the 96-bit subkey starting from the address and from the global key. I have determined that only 16 bits are needed to generate the 96-bit subkey; this was sort of expected, but it isn't without problems. We can generate only 94 bits of the subkey starting from those 16 bits and using only XOR operations. The remaining 2 bits need AND/OR operations, something which I have no explaination for at this point. That was the least of the problems anyway. The major hurdle at this point is that the mapping from address to 16-bit key seed is very far from trivial. The scheme should be as follows: Take 16-bit address, N-bit global key, and generate a 16-bit key seed using an unknown algorithm. Take 16-bit key seed, M-bit global key, and generate 96-bit subkey using an unknown algorithm. Take 16-bit ciphertext, 96-bit subkey, and generate 16-bit plaintext using the algorithm we have discovered. I think it would make sense for the algorithm in step 1. to be another 4-round Feistel network. If this is the case, things are quite harder than before. To break the other Feistel network, we could rely on complete knowledge of ciphertext-plaintext relationship. Now we can't: we only have a vague idea of what the 16-bit key seed could be. If we could rely on a 16-bit value except for a constant XOR and permutation, it wouldn't be a problem, since that wouldn't change the nature of the Feistel network. Unfortunately, we don't have that luxury. Let's see that with an example. Let's say that the first algorithm generates a 4-bit key seed, abcd, which is expanded into the 6-bit subkey ABCDEF this way: A = a; B = a XOR b; C = a XOR c; D = b XOR c; E = b XOR d; F = b XOR c XOR d. We don't know anything about abcd, all we see is ABCDEF, but we need to guess what abcd looks like. So we notice that D = B XOR C; F = A XOR C XOR E; and we decide that a' = A; b' = B; c' = C; d' = E; so we would have A = a'; B = b'; C = c'; D = b' XOR c'; E = d'; F = a' XOR c' XOR d'. This all works as far as generating the subkey from the seed goes, the problem is that abcd and a'b'c'd' are two completely different numbers! We have that a'b'c'd' = abcd XOR aab; so this isn't simply a XOR with a constant value, it's a variable modification of the number. And this is something that the Feistel network cannot handle.
-  6th January 2007: Nicola Salmoria - CPS2 Subkeys: I said earlier that I was going to post the program to extract subkeys from a CHD, and the subkey lists for a few games, however after extracting the subkeys I found important relationships between the subkey bits so I'll have to work on that first. A subkey consists of 24*4 = 96 bits. There are 65536 subkeys, so the total is 786kB of data. What I found that one bit of the subkey is constant, while 59 can be derived from the others with a XOR (which is constant for all 65536 addresses, but changes from game to game). So this hints at a 64-bit global key, while the independent subkey bits drop for now at 96-1-59 = 36 bits.
- 19th December 2006: Nicola Salmoria - CPS2 notes, part 5: In part 1 i showed some constant values in the table that shows how many times flipping a bit in the ciphertext flips a bit in the plaintext. But there's more than that. It seems that there are more properties which are true for all games, regardless of the key (see table). So in total there are 2x4x2x2x4 = 128 combinations. Each combination is used by exactly 256 tables. Note the symmetry of it all. 16 values are affected, related to 2 bits of the ciphertext and 8 bits of the plaintext. This suggests that the algorithm might work on the data 8 bits at a time, or even only 4 bits at a time. The regular behaviour could be caused by a step, at the beginning or at the end of the algorithm, that doesn't use the key. Another thing we can do is check which of the 128 combinations corresponds to each memory address, and look for a way to correlate the two. Unfortunately there doesn't seem to be a simple way to do that.
- 19th December 2006: Nicola Salmoria - CPS2 notes, part 4: I have to stress that there is NO progress being made in breaking the encryption. The things I am showing in these notes have been known for over a year and haven't lead to any breakthrough. Hopefully, a public discussion of these properties could generate some valuable feedback. There also isn't any kind of competition against the people that are attacking the CPS2 encryption in hardware. On the contrary, I think that the hardware path will be the only way to gather more information about the algorithm. In these notes I have shown several properties that are always true, regardless of the key. This means that they are properties of the algorithm itself, and therefore are hardcoded in hardware. For example, there almost surely are fixed substitution boxes which could be extracted from the custom CPU. If an algorithm is reconstructed by studying the CPU, we can also test it against the known properties, regardless of the key. If it doesn't match, then the algorithm isn't right. Once an algorithm fitting the properties is found, we can start looking for the key.
- 18th December 2006: Nicola Salmoria - CPS2 notes, part 3: In part 1 we were flipping bits in the ciphertext, and seeing what happened to bits in the plaintext. We can do the opposite, of course, and there's something unexpected in the results. I'll show the total number of times the bits change (in hex) instead of percentages, to make the point more visible (see table). The values highlighted in orange are the only two that are constant in every table (there were four in the inverse table). But the values highlighted in red are the most interesting. They are not constant--they can vary among a few possible values. But the sum of the two values in each column is constant, and it's always 0x10000. Why? I have no idea.
- 18th December 2006: Nicola Salmoria - CPS2 notes, part 2: The complementation property was an important discovery--and not just because it reduces the size of the tables in half. Still, we haven't taken full advantage of it yet. Let's recap the basics of the CPS2 encryption first. Inputs: 16-bit value stored in ROM; 16-bit address (bits 1-17 of the physical address) key of unknown size, different for every game Outputs: 16-bit decrypted value. Let's call D(X,A,K) the decryption of value X at address A using key K. The complementation property says that for every A there is exactly one A1 such that D(X,A,K) = D'(X',A1,K) where x' is the complement of x. This finding is important because it shows that A has an algorithmical effect on the encryption. In Sega's FD1094 CPU, the key for every address is just stored in a huge table. If the CPS2 CPU worked in the same way, the complementation property wouldn't happen. This isn't too much of a surprise: with the Kabuki CPU, we had already seen that Capcom preferred a complex algorithm with a small key, while Sega preferred a simpler algorithm with a huge key. Unfortunately we don't yet know how to calculate A1 given A. It varies from game to game so it must be a function of the key. The complementation property isn't unheard of, even in strong ciphers, so it isn't necessarily a weakness in the algorithm. For example, DES (http://en.wikipedia.org/wiki/Data_Encryption_Standard#Minor_cryptanalytic_properties) has it. In that case, it reads D(X,K) = D'(X',K'). In general, the complementation property indicates that there are probably XOR operations happening, which cause the complement operation to cancel out. Let's see this with an example: consider a substitution function f, and an algorithm such that d = e XOR f(e XOR k), if we take the complements we have e' XOR f(e' XOR k') = e' XOR f(e XOR k) = (e XOR f(e XOR k))' = d' of course this is a very simple example. Note that x' doesn't have to be the complement in this case: you can define it as e.g. x' = x XOR 1, and it will still work. So the CPS2 algorithm obviously isn't that simple. A more realistic example would be a Feistel network (note that DES is an example of a Feistel network). If you define the Feistel network as Li = Ri-1 and Ri = Li-1 XOR f(Ri-1 XOR Ki-1). It should be easy to see how the complementation property would ensue. The idea of the CPS2 encryption being a Feistel network is tempting, however I don't think this is the case, because I would expect the diffusion to be much better than what we have seen in part 1.
- 17th December 2006: Nicola Salmoria - CPS2 notes, part 1: Since the finding of the complementation property (sfzj_049e38[x] ^ 0xffff == sfzj_05ee0c[x ^ 0xffff]  => 8GB / 2 is still 4GB) almost one year ago, there has been no progress at all on the CPS2 encryption. I'm going to explain here some of the (remarkably few) things we know about the encryption. A common misconception is that the decryption tables look like "random data". They may look so to the naked eye, but the most basic statistical checks show that this isn't the case. Take an encrypted value, change a bit in it, and look at what happens to the output. For a random table, you'd expect every bit in the decrypted value to change with 50% probability. This isn't happening. Take a look at the following statistics taken on a single table (see http://mamelife.blogspot.com/): on rows, you have the encrypted bit that changes; on columns, the frequency with which the decrypted bit changes. So there is a large number of values around 50%, which look just random, but there are also values very far from that. This indicates that the encryption algorithm doesn't have good diffusion. This is a weakness, though it hasn't been exploited yet. Of particular interest are the four values I highlighted in red. While the other values change from game to game and from table to table, those four values are always the same. E.g. flipping bit 9 in the encrypted value causes bit 0 in the decrypted value to flip exactly 0x5080 times out of 0x10000, for every game, at every address. This property is quite interesting. It is the most obvious "signature" of the algorithm. Does it help? Well, it tells us that if the algorithm contains bit permutations that depend on the key, those permutations cannot affect bits 3 and 9 in the encrypted value, nor bits 0 and 14 of the decrypted data. Apart from that, however, the property doesn't tell us much, because even if we know that the bits have to change that many times, we don't know exactly when to flip them. Discovering that would be a significant advance in the understanding of the algorithm.
- 0.110u4: CPS2 updates [David Haywood]: Added table for Jyangokushi (from Guru). Note that GFX/Sound roms aren't dumped on this one. Removed old 'handcrafted' XORs for games which we have CHDs for and replaced them with XORs generated from MAME using the CHD. This means anyone with the CHD can easily generate the XORs (using the code I've left in there) if they need to be able to run the games with a shorter startup time. Disabled the loading of the XORs by default for all sets with a CHD. Now only the CHD is loaded, unless the #define is changed at the top in which case only the XORs generated from the CHD are loaded.
- 0.110u3: David Haywood added raw decryption table to choko. Enabled the use of the large CHD-based tables by default.
- 0.110u2: David Haywood added support for using CHDs to decrypt CPS2 games. This code is disabled for the moment, but will be enabled in the future. Only a handful of games have complete tables so far. These tables are huge (~4GB) and uncompressable until the encryption algorithm is understood.
- 19th September 2006: Charles MacDonald - With the success of the Choko dump from a while ago, I'm working to get the CPS-2 dumping tools and instructions updated. Changes were made from the last version, mostly bugfixes and speed-ups to decrease the amount of time it takes to dump a full table set. There's also a minor modification that needs to be done to the PCB, to ensure stability, though now that it's known which features are absolutely needed, I might redesign it. Admittedly not many people have been interested in getting more of the games dumped, probably because all the popular ones we wasted tons of quarters on are already emulated!
- 0.105u3: Aaron Giles uncommented/added missing undumped ROMs/XORs in the CPS2 games.
- 0.105u1: David Haywood updated CPS driver to more accurately draw tilemaps, based on evidence from a board with mixed ROMs.
- 14th February 2006: Guru - A CPS2 USB adapter arrived, thanks to Charles MacDonald. The adapter plugs into the 64-pin CN7 on the B board. The chips on the bench are the original ROMs and PALs. ROM3 is changed and ROM10 is added. Plus 1 PAL on the A board is changed and 2 PALs on the B board are changed. Unfortunately, none of the PALs were socketed and this particular B board didn't have a CN7 connector! So I had to desolder a CN7 connector from another dead CPS2 board and solder it to this board and desolder and socket the 3 PALs as well! Luckily she still works! It's not that exciting to look at though.
- 15th January 2006: Razoola - Nicola Salmoria has reported on his blog some progress in understanding the CPS2 algo. He has managed to shrink the current 8gig table of SFZ down to 4gig. This is the first breakthrough in understanding the encryption used. For more information visit his blog.
- 11th January 2006: Charles MacDonald - I've tried to package and clean up all the CPS-2 related development stuff I have that was used for table dumping. This can be used for writing CPS-2 software, running tests on the system, and dumping table data so we can hopefully figure out the encryption at some point. I will definitely include more sample programs, documentation, and hardware information in future updates to the package, but I wanted to get this off my to-do list.
-  5th January 2006: Razoola - While playing around coding on a dead CPS-2 board I have today I found that the encryption algo is still fully in place even after the CPS-2 board has suicided. That said, on examining values the number do not match those of the expected game. This almost certainly confirms that their is only _one_ algo over all CPS-2 games with the only difference being key data (like Kabuki on CPS-1). I passed some test code onto Charles MacDonald so that he can check the values he gets there (on his dead SFA3 board). Those should match what I see here and to be honest it looks just a formality. When you consider the watchdog on a suicide board is 0xFFFF,0xFFFF,0xFFFF (example opcode, CMPI.L #$FFFFFFFF,$FFFF0000) everything starts to make sence. There was a big debate over this going back to when we first broke past the protection. The worry voiced by some DEVs was that all boards would be needed again to get the algo for each game. This new discovery certainly confirms that once the algo is known for one game all the others can be brute forced using the XOR tables. As for figuring out the algo itsself whats needed now is a complete dump of tables (8gig) of the algo executing in this default state. Using this the algo should be easier to understand because any key data used for math should be 0xFFFF. I have quickly dumped a complete table for a couple of addresses and while it still looks a mess there are certinally more patterns compared to a normal game. Update: I've got word back from Charles and after some work (over irc) he has managed to get the same data I was seeing. This basically confirms what I mentioned above. There were some initial problems with his transfer system (which is far superior to mine) giving different results. It turned out that at some point during the process the protected RAM was being reprogrammed!!! The exact way this is happening is not yet known but it opens up some large posibilities if the cause can be found and understood. This situation did not happen when he was dumping games that were non suicide. It currently looks like there is no way to get a full 8gig table because the protected region in a suicide state seems to be only 0x10000 bytes where a complete table covers 0x20000 bytes. Hopefully we can get around this.
-  4th January 2006: Razoola - I have written a small tool that can be programmed onto EPROM and used to test if a CPS2 board has suicided.
- 19th November 2005: Charles MacDonald - Thanks to a generous donation from Razoola and the CPS2Shock team, I've been given B-boards for the following games: sfzj, csclubj and sfz3. I have dumped complete table sets from the first two and am doing tests on the latter. It has no battery, so I can see how the hardware works when the battery-backed SRAM is erased. With a much larger data set (32 GB) spanning four games, hopefully some patterns will be discovered. I'm still interested in dumping a regional variant for one of the currently dumped games to see what kinds of similarities might exist between the two. Most likely I will revise and release the tools and specifications for my CPS-2 development setup in the future. Then other people could dump table sets from their games and contribute to this project. There are so many CPS-2 games out there that I couldn't possibly do it all myself, nor would I want to.
- 12th October 2005: Charles MacDonald - Getting a bunch of PCBs to work with in the next few weeks: three CPS-2 'B' boards (more on those next update), Shanghai for HD63484 tests, and a Quartet 2 board. I'll continue my CPS-2 research once the other games arrive. One of them has no battery so I can skip the annoying encryption and run tests directly, which will be a huge convenience. I think right now all the useful data that can be extracted from xmcota and pzloop2j has been obtained.
- 30th September 2005: Charles MacDonald - I've been doing some research on the CPS-2 hardware in the last few months, starting as soon as the System 32 work was put on hold. I'll give a basic overview of the encryption, however I should point out I'm just elaborating on the findings that Razoola originally made, which are at CPS-2 Shock. As you can imagine the results of his prior experiments have been absolutely essential to this project. The CPS-2 hardware uses a custom 68000 CPU running at 16MHz, though the effective speed is lower due to video DMA. Out of the 16MB address range, the lower 4MB is allocated for ROMs storing program code and data. The first 1MB of this area is where decryption is enabled, though the exact boundary under the 4MB point may change from game to game. In addition to the address range check, there is a timer that expires after a certain amount of time has passed. When this happens, decryption is turned off and the 68K will execute code exactly as it is read from memory. A sequence of one or more specific instructions, changing on a per-game basis, will reset the timer and enable encryption again. The timer can be restarted after any duration from when it has expired. The decryption logic uses bits A16 through A1 of the 68K address bus, meaning the encryption wraps every 128K. For each encrypted word at a given address there is exactly one unique output; in contrast to the FD1094 there are no disabled opcodes or 'blanked' data that resolve to the same decrypted value. Data read from the supervisor or user code space is decrypted (e.g. opcodes and operands) and data from the supervisor or user data space is not. The size of a complete set of decrypted data for one game quite large, totalling 8GB - it takes forever to dump. There are no duplicate tables within a game's table set or between sets for different games, though I've only examined tables dumped from the two 'B' boards I have. I've discussed analysis of the table data with a few other people and so far the encryption seems to be pretty tough to solve. As a result, I think progress will depend on additional help. If you have skill in this type of thing (strong mathematics background and familiarity with encryption) and would like to lend a hand, then please get in contact with me. Working with the CPS-2 hardware has been challenging due to the large amount of custom parts involved. I designed a communications board with a USB adapter, DTACK generator, and interface to the CPS-2 video and peripheral bus to run software on it, as well as several adapters to replace the 16V8 GALs with more capable 22V10 GALs that have their own shared I/O bus. Small update for some common questions: The two games I've dumped are xmcota and pzloop2j, which are both already emulated in MAME. The ETA for a complete table dump (65,536 files) is 9 hours, and it's fully automated. Sometimes the system locks up randomly and has to be reset which slows things down, this occured quite a lot for pzloop2j and not at all for xmcota. They have different types of B boards, perhaps that has something to do with it. Many people are suggesting to look at Street Fighter Zero and it's variants, as well as Rockman which had a less common CPS-2 release but is very similar to the CPS-1 version. The only thing that would be really useful is to find two games that are encrypted with the same or similar keys, so unless Rockman has an identical key as another game it's not that useful. I would be interested in getting data out of another variant of xmcota.
- 27th October 2004: Razoola - There seems to be someone making quick hacks of XOR files we have released in the past to get games running which don't currently have XORs. While this sounds a good thing it's actually no different than using the region switch option in kawaks for example. The big problem is that these new XOR's contain incorrect information in relation to what the real encryption would return for many addresses when compared to real hardware. It also makes it less likely for these games to be donated in the future so good XOR's can be created as people will think they already have good XOR's. The reality is these new hacked XOR's are prone to all the bugs that come with using region switching in CPS2 games. It's for these reasons that I want it known I have nothing to do with these hacks and I would advise against them being used officially in any emulator as they cannot guarantee an accurate game.
- NOTES: The CPS-2 encryption only affects opcodes, not data. It consists of two 4-round Feistel networks (FN) and involves both the 16-bit opcode and the low 16 bits of the address. The hardware also has different watchdog opcodes and address range (see below) which are stored in the battery backed RAM. There doesn't appear to be any relation between those and the 64-bit encryption key, so they probably use an additional 64 bits of battery-backed RAM. The encryption does _not_ cover the entire address space. The range covered differs per game. The CPS2 system has a watchdog system that will disable the decryption of data if the watchdog isn't triggered at least once every few seconds. The trigger varies from game to game (some games do use the same) and is basically a 68000 opcode/s instruction. The instruction is the same for all regions of the game. The watchdog instructions are listed alongside the decryption keys.
- SOURCE: machine\cps2crpt.c



P3.2   CPS3
- SOURCE:



P4.    DALLAS

P4.1   DS1204
- PCB: Data Key - MegaTouch (Merit)

P4.2   DS5002FP
-  8th December  2002: Manuel Abadia sent in a driver for Target Hits but it is unplayable due to an undumped DS5002FP MCU.
-  6th December  2002: Manuel Abadia sent in a preliminary driver for World Rally that works somewhat, but won't be playable because of an undumped DS5002FP MCU.
- NOTES: The DS5002FP MCU use external battery ram (32k) - see wrally2 PCB info
- GAMES: Gaelco - Glass (1993), World Rally (1993), TH Strikes Back (1994)
- PCB: DS5002 (Touchgo)




P5.    Fujitsu

P5.1   MB8841
- 0.122u8            : Cleaned up Kangaroo driver [Aaron Giles]: Documented MB8841 (needs to be decapped to get code). Proper video timing. Full memory maps. Simplified and more accurate video logic.
- 25th January   2007: Guru - For those that didn't realise, the chip below is a Namco Custom 54xx and is used on Xevious, Galaga, Bosconian and Pole Position for generating some sounds (for example the 'death bang' sound in Galaga). The chip is actually a Fujitsu MB884x-family microcontroller with 1k internal maskROM. If you want to blow your mind with technical details, the datasheet is here (http://www.sharpmz.org/download/mb8843.pdf).
- 23rd January   2007: Guru - Here's a few pics of the very first custom chip that I sent to a professional Japanese IC decapping company that we (Mamedev) are using to help us with some MAME-related things. Hopefully if this is successful, more will follow and also hopefully talented hardware devs like JROK (http://www.jrok.com/) will be able to make replacements for it to repair real PCBs. You may also be wondering why we're doing this instead of using some other people who frequent the 'boards' who have offered to do this kind of thing for free? The answer is fairly simple... Apart from the amount of time it takes to get this done, the level of communication is somewhat 'sporadic' and so far offers to supply other chips to them have been ignored. We requested pics of some CPS2 ICs that were said to have been decapped and so far nothing has surfaced (over a month has passed since then). Doing it this way gives us more control over what we achieve and ensures the work is done in a timely manner. Apart from that, the plan to get this IC decapped has been in the works for several months, so we might as well use the professional IC decapping company whenever possible because the amount of ICs we need to decap is possibly too much work for someone to do in their spare time for free.
- NOTES: The Fujitsu MB8841 is a 4-bit microprocessor/MCU with 8k rom (see Kangaroo). It generates a protection NMI in games after the startup. The custom CPU also controls the video flip control line. MAME patched this protection.
- SOURCE: cpu\mb88xx\mb88xx.c
- GAMES: Sun Electronics - Route 16 (1981), Kangaroo (1982), Arabian (1983), Fly-Boy ??? (Kaneko 1982)
- PCB: MB8841 (Route16)


P5.2   MB8842
- 0.114u1            : Nicola Salmoria added actual emulation of the microcontroller used for the Namco 50xx chip as found in Bosconian and Xevious.
- NOTES: The Namco 50XX chip is a Fujitsu MB8842, which has twice the ROM and RAM of the 54xx chip. It is used for Player score control (only used as protection check).
- SOURCE: cpu\mb88xx\mb88xx.c


P5.3   MB8844
- 0.114u1            : Changed name 'MB88xx' to 'MB8844'.
- 0.112u1            : Replaced implementation of Namco 54xx sound chip with new MB8844 CPU core running the original embedded ROM code. Removed old sound core. Pole Position and Bosconian no longer require samples as a result [Nicola Salmora, Ernesto Corvi, Guru].
- SOURCE: cpu\mb88xx\mb88xx.c
- GAMES: Namco - Bosconian (1981) and Pole Position (1982)


P5.4   MB8851
- NOTES: 4-bit MCU (DIP42)
- SOURCE: machine\namcoio.c


P5.5   MB8852
- NOTES: 4-bit MCU (DIP28)
- SOURCE: machine\namcoio.c
- GAMES: Namco - Bosconian (1981) and Pole Position (1982)


P5.6   MB14241
- 0.113u2            : Zsolt Vasvari] created a new file for MB14241, which is the shifter IC used by Invaders hardware games.
- NOTES: MB14241 did custom operations. In Field Goal (Taito 1979) it shifts the data.
- SOURCE: machine\mb14241.c
- PCB: MB14241 (40love, Fieldday, Jollyjgr)




P6.    Intel

P6.1   I8031
- 25th November  2004: R. Belmont - Converted Steve Ellenoff's i8031/8051/8052/8731/8751/8752 core to the latest MAME core and submitted it so Aaron can emulate the protection in Sega's "Moonwalker" properly.
-  3rd April     2004: Philip Bennett - I've hastily transferred Steve Ellenoff's i8051 PinMAME core over to MAME. As a result, F-15SE and B.O.T.S.S start up with some DAC humming and what sounds like FM machine-gun fire and bell chimes. Given that the 68000 and 8031 aren't communicating properly, that's the extent of the current sound emulation.
- SOURCE: drivers\sliver.c (Hollow Corp 1996)
- PCB: i8031, DIP40, sound MCU (Sliver)


P6.2   80C31
- 25th November  2004: R. Belmont - Converted Steve Ellenoff's i8031/8051/8052/8731/8751/8752 core to the latest MAME core and submitted it so Aaron can emulate the protection in Sega's "Moonwalker" properly.
- SOURCE: cpu\i8051\i8051.c
- PCB: SC80C31BCCN40 MCU = 8051 family (Botss, F15se), LGS GMS80C301 (Puzzlekg)

P6.3   80C32
- SOURCE: cpu\i8051\i8051.c
- PCB: SIEMENS 80C32 (Cardline)


P6.4   I8051
- 0.122u8            : Jim Stolis corrected previous i8051 timer fix to use more accurate IE SFRs.
- 0.122u7            : Jim Stolis fixed I8051 timers from firing when not enabled. Checking TCON alone is not enough to invoke timers. Added IE SFR flags in conditional.
- 21st January   2008: Jim Stolis - Hack Free: I finally found the bug that was forcing me to add memory hacks to the driver in order for it to bypass the memory tests for each game. The I8051 core library was basically firing the timers when they were sometimes not enabled. What this did was cause the timer interrupts to modify memory while the memory check subroutine was running. The memory check routine was writing specific values into memory and verifying that they read back the same value that was written. But with the timers updating memory at the same time, the memory check would not find the values it was expecting and therefore fail. The fix should help slightly increase the responsiveness of the game code too. I believe the I8051 core has other areas to investigate, but this fix is a huge change for the driver. With the fix in place, all memory hacks in the driver can be removed. This means any new clones that are added in the future should drop in nicely without any special memory modifications. I will be submitting a new driver update in the near future with all the hacks removed.
- 0.122u3            : Pierpaolo Prazzoli fixed save states in i8051 cpu core.
- 0.121u2            : stephh fixed BCD math error in i8051 core.
- 0.120u4            : Jim Stolis fixed a bug in the i8051 core that improperly fired the Timer2 interrupt when it wasn't enabled.
- 0.120u1            : Jim Stolis fixed several i8051 issues: Fixed a bug with some opcodes having the wrong cycle counts. Fixed a bug where determining the proper timer mode. Fixed a bug where determining the proper serial transmit mode. Added support for split timer mode.
- 0.111u1            : Special LIU fixed implementation of da_a instruction in i8051 core. Giuseppe Gorgoglione converted 8051dasm.c to use cpuintrf_temp_str() instead of local string pools.
- 0.109u5            : Aaron Giles converted the i8051 disassemblers to the new format and added step in/out support where it was obvious.
- 0.89u1             : Aaron Giles fixed I8051 cpu core bugs. Uses correct read/write memory routines for external accesses now and supported external IRQs.
- 25th November  2004: R. Belmont - Converted Steve Ellenoff's i8031/8051/8052/8731/8751/8752 core to the latest MAME core and submitted it so Aaron can emulate the protection in Sega's "Moonwalker" properly.
- 0.88u5             : i8x51 cpu core [Steve Ellenoff]. This work is based on 'Intel(tm) MC51 Microcontroller Family Users Manual', 8051 simulator by Travis Marlatte and Portable UPI-41/8041/8741/8042/8742 emulator V0.1 by Juergen Buchmueller.
-  3rd April     2004: Philip Bennett - I've hastily transferred Steve Ellenoff's i8051 PinMAME core over to MAME. As a result, F-15SE and B.O.T.S.S start up with some DAC humming and what sounds like FM machine-gun fire and bell chimes. Given that the 68000 and 8031 aren't communicating properly, that's the extent of the current sound emulation.
-  1st April     2004: Philip Bennett - I've been informed (thanks Thomas!) that there's an i8051 core in PinMAME, supporting the i80C31 MCU. Sound emulation *may* follow soon. I'm expecting thumping FM techno soundtracks from F-15 Strike Eagle and B.O.T.S.S.
- SOURCE: cpu\i8051\i8051.c


P6.5   I8052
- 25th November  2004: R. Belmont - Converted Steve Ellenoff's i8031/8051/8052/8731/8751/8752 core to the latest MAME core and submitted it so Aaron can emulate the protection in Sega's "Moonwalker" properly.
- 0.88u5             : i8x51 cpu core [Steve Ellenoff]. This work is based on 'Intel(tm) MC51 Microcontroller Family Users Manual', 8051 simulator by Travis Marlatte and Portable UPI-41/8041/8741/8042/8742 emulator V0.1 by Juergen Buchmueller.
- SOURCE: cpu\i8051\i8051.c
- SOURCE: drivers\vamphalf.c (I8052 (24000000/4 = 6 MHz?) + I8052 code: snd-rom2.us1)
- GAMES: All Player's Edge Plus games, Mission Craft (Sun 2000), Wyvern Wings (SemiCom 2001)
- PCB: 83c02 = I8052 compatible (Pepp0516)


P6.6   I8741
- 0.104u9            : Tatsuyuki Sato fixed Joshi Volleyball and Great Swordsman, which was broken in an earlier update.
- NOTES: NEC 8741 emulation by Tatsuyuki Satoh
- NOTES: The NEC 8741 communicate between main and sub CPU. Read Joystick and Coin Slot (both players). And read buttons (Fire 1, 2 and 3 (both players), service button)
- SOURCE: machine\tait8741.c
- GAMES: Taito - Joshi Volleyball (1983), Great Swordsman (1984), Gladiator (1986)
- PCB: I8741A MCU (Fshark bootleg), NEC 8741 (Gladiatr), 8741 (Josvolly)


P6.7   I8742
- NOTES: MCU internal ROM size = 2048 bytes ($800)
- SOURCE: cpu\i8x41\i8x41.h
- PCB: i8742 (Drtoppel), INTEL D8742 (Tnzs), i8742 MCU (Chukatai, Tnzs), M-CHIP 40-pin (Arknoid2)


P6.8   I8748
- NOTES: MCU internal ROM size = 1024 bytes ($400). The game 'Sai Yu Gou Ma Roku' (Japan bootleg 1) has a i8748H MCU on board, but MAME uses the I8048.
- SOURCE: drivers\chinagat.c
- PCB: Intel i8748H (Chinagat), 8748 (Sstingry), 8748 (Csilver)


P6.9   I8749
- 0.123u2            : Curt Coder added i8749 CPU variant for MESS.
- NOTES: drivers\chinagat.c: There's an Intel i8748 CPU on the bootlegs (bootleg 1 lists D8749 but the microcode dump's the same).
- PCB: NEC D8749HC (Stratof), D8749 (Chinagat), 8749HD (Wildfang), Intel 8749H (WB3), P8749H (Toki)


P6.A   I8751
-  6th April     2007: Charles MacDonald - I was running some timing tests on the 8751 MCUs used in several Sega games, and noticed they seemd to respond to the internal ROM / external program memory select pin (/EA) even when it was changed after a reset. I thought this meant it may have been possible to force the MCU to run a user specified program and dynamically enable/disable the internal ROM while running. This ended up not being the case, the opcodes are fetched but not acted upon. Maybe the MCU internally drives NOPs onto the data bus. I wonder if the program counter continually increments so that you could force the PC to get into the external program memory range, but in the limited testing environment I had set up this didn't seem to happen. Probably the PC is never incremented. This behavior seems to be standard across the Intel C8751 and D8751 chips. If /EA is pulled high or left unconnected, the internal ROM program runs. If /EA is tied to ground it stops execution and starts fetching opcodes by strobing /PSEN repeatedly. You can change /EA as many times as you want and reset the MCU with it in different states, you'll get the same behavior every time. It's unfortunate, but at least this confirms that a trick used to dump some protected 8051s will not work on these MCUs in particular. I compared their operation to a unprotected AT89C52 which responded correctly, so this is definitely a function of the MCU security bit(s).
- 0.104u4            : Aaron Giles fixed the 8751 MCU (8751MCUgames0104u3: segas16a/b, segas18 games using a 8751 are not working).
- 0.90               : Nicola Salmoria updated the Super Qix driver. Repaired the ROM code and added support for the I8751 MCU, so the two original sets work.
- 0.89u1             : Aaron Giles hooked up the 8751 in mwalk, mwalka and mwalkb and fixed sound ROM loading - all games now work.
- 25th November  2004: R. Belmont - Converted Steve Ellenoff's i8031/8051/8052/8731/8751/8752 core to the latest MAME core and submitted it so Aaron can emulate the protection in Sega's "Moonwalker" properly.
- 12th January   2003: Bryan McPhail emulated the i8751 protection in Firetrap so the original version works.
-  9th January   2003: Bryan McPhail fixed the erratic coin inputs in the i8751 emulation in the Karnov driver.
- 26th December  2002: Angelo Salese simulated the i8751 protection in Birdie Try so that the game is playable, but there are some misplaced sprites in it. Bryan McPhail corrected the CPU clock speed in it.
- 31st July      2000: Guru - Dumped Karnov's i8751 MCU.
- 15th January   2000: Bryan McPhail got the two original Side Pocket romsets working by simulating the i8751 MCU.
- 25th September 1999: Nicola added Gallop to the M72 driver, but the rest of the M72 games need their i8751 MCU emulated before they work.
- 0.35b3             : Simulated the 8751 protection in F-1 Dream [Eric Hustvedt].
- NOTES: i8751 (C8751H-88) is read protected. The Mad Gear pcb has an unused pad on the board for an i8751 (trivia for the DEV).
- NOTES: Protection simulation (drivers\m72.c): Most of the games running on this board have an 8751 protection mcu. It is not known how it works in detail, however it's pretty clear that it shares RAM at b0000-b0fff. On startup, the game writes a pattern to the whole RAM, then reads it back expecting it to be INVERTED. If it isn't, it reports a RAM error. If the RAM passes the test, the program increments every byte up to b0ffb, then calls a subroutine at b0000, which has to be provided by the mcu. It seems that this routine is not supposed to RET, but instead it should jump directly to the game entry point. The routine should also write some bytes here and there in RAM (different in every game); those bytes are checked at various points during the game, causing a crash if they aren't right. Note that the program keeps incrementing b0ffe while the game is running, maybe this is done to keep the 8751 alive. We don't bother with that. Finally, to do the ROM test the program asks the mcu to provide the correct values. This is done only in service, so doesn't seem to be much of a protection. Here we have provided the correct crcs for the available dumps, of course there is no guarantee that they are actually good. All the protection routines below are entirely made up. They get the games running, but they have not been derived from the real 8751 code.
- SOURCE: cpu\i8051\i8051.c
- DRIVERS: deco.c (machine + drivers), dec8.c, firetrap.c, segahang.c, segas16a/b.c, segas18.c, sidepckt.c, superqix.c, tigeroad.c, karnov.c
- GAMES: Data East - Side Pocket (1986), Fire Trap (1986), Karnov (1987), Capcom - F1 Dream (1988)
- PCB: MPU 8751 (Ghostb, Gondo), C8751H (Blktiger, Srdarwin), D8751H (Airduel, Sf1), i8751 (Garyoret, Wndrplnt), iC8751H-88-L5310039 (Shtngmst)


P6.B   I8752
- 25th November  2004: R. Belmont - Converted Steve Ellenoff's i8031/8051/8052/8731/8751/8752 core to the latest MAME core and submitted it so Aaron can emulate the protection in Sega's "Moonwalker" properly.
- 18th November  2003: David Haywood emulated the Philips 87c52 MCU in Cookie and Bibi 2. And More More plus doesn't point the vectors there but does have a jump there in the code. See hyperpac for an example, the protection data for that game was extracted from the bootleg.
- 12th November  2003: David Haywood emulated the protection (87c52) in Hatch Catch, so it's now fully playable with sound.
- NOTES: The Intel or Philips 8752 MCU is read protected, the code can't be dumped. The following games uses the I8752 MCU (MCU code can't be dumped): snowbros.c - hyperpac, twinkle, toppyrap, moremore, moremorp, 3in1semi, cookbib2, cookbib3 and finalttr. And driver tumbleb.c - htchctch, cookbib, chokchok, metlsavr, bcstry and bcstrya.
- SOURCE: cpu\i8051\i8051.c
- GAMES: SemiCom - Hatch Catch (1995), Hyper Pacman (1995), More More Plus (199?), Cookie and Bibi 2 (1996)
- PCB: Intel P8752 MCU (Finalttr), Philips P87C52EBPN MCU DIP40 (Semibase, Dreamwld, Hyperpac, BCStory), 87C52 (Htchctch)
- PCB: TSC87C52-16CB, PLCC44, Programmable 8BIT MCU (Monglfir, Soccernw)


P6.C   87C751
- 26th September 2005: Pierpaolo Prazzoli - Emulated OKI6295 sound in Power Balls (Super Slam conversion). The Philips 87C751 sound MCU wasn't read-protected (=> s87c751.bin).
- 0.95u2             : Quench improved Super Slam audio MCU simulation.
-  1st February  2004: Quench simulated the OKI6295 sound CPU (Signetics 87C751) in Super Slam, but it's not perfect yet.
- NOTES: The 87C751 is a 8051 based MCU (DIP24) with 2k x8 OTP EPROM and 64k x8 SRAM.
- NOTES: MCU 87C751 simulation: A table converts commands sent from the main CPU, into sample numbers played back by the sound processor. All commentry and most sound effects are correct, however the music tracks may be playing at the wrong times. Accordingly, the commands for playing the samples is just a guess: 1A, 1B, 1C, 1D, 1E, 60, 61, 62, 65, 66, 67, 68, 69, 6B, 6C. Samples 63, 64 and 6A are currently not fitted anywhere. Note that samples 60, 61 and 62 combine to form a music track. Ditto for samples 65, 66, 67 and 68. Command 29 is fired when the game is completed successfully. It requires a melody from bank one to be playing, but we're already using the bank one melody during game play. The sound CPU simulation can only be perfected once it can be compared against a real game board.
- SOURCE: drivers\sslam.c
- PCB: Philips 87C751 sound MCU (Powerbal), Signetics 87C751 (Sslam)


P6.D   89C51
- NOTES: http://www.atmel.com/dyn/products/product_card.asp?family_id=604&family_name=8051+Architecture&part_id=1939
- SOURCE: cpu\i8051\i8051.c
- PCB: Atmel 89C51 MCU, protected (Rbmk), AT89C51 (Topshoot, Chameleon 24-in-1), AT89c4051-24PC (Beastrzb, Spotty)


P6.E   89C52
- NOTES: http://www.atmel.com/dyn/products/product_card.asp?family_id=604&family_name=8051+Architecture&part_id=1939
- SOURCE: cpu\i8051\i8051.c
- SOURCE: drivers\eolith.c + pasha2.c
- PCB: Atmel AT89C52 MCU w/8k internal FlashROM, DIP40 (Hidctch2, Pasha2, 3in1semi, Moremore)


P6.F   89C55
- PCB: Atmel 89C55  8-Bit Microcontroller with 20K Bytes Flash, KD89C55A (SuperMoto)


P6.G   90C32
- NOTES: Hyundai GMS90C32 MCS-51 Compatible Microcontroller w/8k internal EPROM, clock 12.000MHz (PLCC44). Note: EA (External Access Enable on pin35) is LOW, thus it is configured to use the External EPROM at U111. The chip is configured by placing a small smt zero Ohm resistor across 2 pads adjacent to pin35. So a romless condition can be easily checked by looking to see if the resistor is present. If the resistor is not present, EA is configured to HIGH and the chip is using it's internal ROM.
- PCB: GMS90C32 (Hidctch3)




P7.    Komami

P7.1   051550
- NOTES: The Coin Counters are handled by the Konami Custom 051550
- PCB: Citybomb, Ultraman, Kittenk, Tricktrp


P7.2   051733
- 28th December  1999: Manuel Abadia sent in a Konami update with K051733 working fully in Devastators and Blades of Steel.
- 27th December  1999: Manuel Abadia added the K051733 protection hacks to Blades of Steel and the game works a little bit better.
- 26th December  1999: Manuel Abadia sent in a driver for Fast Lane, but it isn't playable because of the K051733 protection.
- NOTES: The protection of the Konami 051733 is not fully understood. The enemies in Chequered Flag might not appear correctly.
- GAMES: Konami - Fast Lane (1987), Blades of Steel (1987), Chequered Flag (1988)


P7.3   052591
- NOTES: The 052591 is used for protection in Thunder Cross and S.P.Y. (simulated PMCU protection). In Thunder Cross is the K052591 for collision detection. In Hexion (Konami 1992), however, the only thing it seems to do is clear the screen.
- GAMES: Konami - Thunder Cross (1988), Hexion (1992)


P7.4   Konami ESC
-  4th May       2003: Acho A. Tang submitted a major improvement to the Konami GX driver, improving the graphics emulation and emulating the ESC protection in Salamander 2, Dragoon Might and Tokimeki Memorial Puzzle-dama, making them all playable.
- NOTES: Konami ESC (E Security Chip) protection chip. The ESC is a custom microcontroller with external SRAM connected to it. It's microprogram is uploaded by the host game. The ESC has complete DMA access to the entire 68020 address space, like most Konami protection devices. Most games use the same or a compatible microprogram. This program gathers the sprite information scattered around work RAM and builds a sprite list in sprite RAM which is properly sorted in priority order. The Japanese version of Gokujou Parodius contains a 68020 version of this program at 0x2a285c. The code below is almost a direct translation into C of that routine. Salamander 2 uses a different work RAM format and a different ESC program, and Dragoon Might uses a third format and program. These games haven't been reverse-engineered yet and so have no sprites. Winning Spike and the Type 4 games use a new protection chip made from a Xilinx FPGA. See type4_prot_w for details.
- GAMES: Konami System GX - Salamander 2, Sexy Parodius, Twinbee Yahhoo, Dragoon Might and Daisu-Kiss




P8.    Microchip PIC-MCU

- 0.109u5            : Aaron Giles converted the pic16c5x disassemblers to the new format and added step in/out support where it was obvious.
- 14th February  2004: Quench updated the PIC16C5x CPU core to support internal memory maps, and he updated the relevant drivers to use the functionality as well.
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. * Harvard architecture CPUs now have data memory fully implemented now. Affected CPUs are the ADSP210x, TMS3201x, TMS3202x, PIC16C5x, and CCPU. All cores have been modified to fully split program and data memory. All drivers using these cores now specify explicit program and data memory maps. This also gets rid of a ton of ugly macros used in memory maps. [Aaron Giles]
- 0.78               : Aaron Giles added support for Biofreaks, fixed remaining issues in California Speed, verified California Speed HDD dump (works in self test, not in boot ROM test), fixed timer change that broke Blitz 2000 and added proper PIC IDs for Wayne Gretzky and Mace. Added sound auto acknowledgement option, added new PIC mapping for Gauntlet: Dark Legacy and fixed initial sound IRQ state. DCS: Fixed reporting of input full/output empty states.
- 0.77u3             : Aaron Giles fixed several minor bugs that affected Biofreaks and California Speed and increased default visible area to handle Biofreaks. Tweaked the Midway PIC handling so that Biofreaks can read its serial number. Correct audio ADSP2115 CPU2 clock speed to 16MHz and graphics resolution to 512x400.
- 0.69b              : Quench various fixes to the PIC16C5x core.
- 31st May       2003: Quench sent in various fixes to the PIC16C5x core and added sound to Big Twin.
- 0.69               : Fixed a problem with missing 'returns' in the PIC CPU core [Bryan McPhail].
- 17th May       2003: Bryan McPhail fixed a small bug in the PIC CPU core where it didn't return a value properly.
- 0.67               : Added cpu\pic16c5x\pic16c5x.c, \16c5xdsm.c and \dis16c5x.c. PIC16C5x CPU core [Quench].
-  5th April     2003: Quench sent in a PIC16C5x CPU core and added sound emulation to Dragon Master using it.
- SOURCE: cpu\pic16c5x\pic16c5x.c


P8.1   PIC16C54
- NOTES: PIC16C54 DIP-18 MEM: 512x12, 25 Bytes RAM   4/20MHz max.
- GAMES: Stone Ball (Art & Magic 1994), Strata/Incredible Tech - World Class Bowling (1995), Shuffleshot (1997), Golden Tee'97 (1997), World Class Bowling Deluxe (1999)
- SOURCE: drivers\itech32.c
- PCB: PIC 16C54, PIC 16C54A 04/P, PIC 16C54B, PIC16C54-HS/P (Pntnpuzl), ITBWL-3 (Wcbowl), ITBWL-4 (Wcbowldx), ITGFS-3/ITGFM-3 (Gt97), ITGF98-M (Gt98), ITGF99 (Gt99), ITGF-1/ITGF-2 (Gt3d), ITGF2K (Gt2k), ITSHF-1 (Shufshot)


P8.2   PIC16C55
- GAMES: Dragon Master (Unico 1994)
- PCB: PIC16C55 (Drgnmst), PIC16C55 SND.MCU (Tumblep - bootleg set)


P8.3   PIC16C57
- 0.97u3             : Quench added preliminary PIC16C57/OKI6295 sound support for Action Hollywood.
- 0.95               : Pierpaolo Prazzoli added PIC16C57 sound to Excelsior.
- 0.69b              : Quench got sound working in Big Twin with the use of the PIC HEX dump.
- 31st May       2003: Quench sent in various fixes to the PIC16C5x core and added sound to Big Twin.
- 31st August    2000: Nicola Salmoria sent in a driver for World Beach Volley, again without sound due to an undumped PIC chip.
- NOTES: PIC16C57C DIP-28 MEM: 2048x12, 72 Bytes RAM   4MHz max.
- NOTES: Games with working PIC16C5 CPU: Big Twin and Excelsior
- GAMES: Tengai / Sengoku Blade (Psikyo 1996), World Beach Volley (Playmark 1995), Big Twin (Playmark 1995), Strikers 1945 (Psikyo 1995), Kick Goal (TCH 1995), Mortal Kombat 3 (Midway 1994), WWF: Wrestlemania (Midway 1995)
- SOURCE: cpu\pic16c5x\pic16c5x.c
- PCB: PIC16C57-X T/P (MK3, Wwfmania), PIC16C57C (Gauntleg), PIC16C57-HS/P  Ic-8-bit CMOS MCU Otp (Hotmind)


P8.4   PIC16C84
- PCB: Ttchamp




P9.    Motorola

P9.1   M68701

-  5th August    2006: Nicola Salmoria - Excellent work by Trinity, the original MCU ROM has been extracted. This required removing the cover from the chip, taking photographs of it under a microscope and manually decoding the contents of the ROM bit by bit. The photo shown in the previous post confirms that it's in the 6801 class, not a 68701 however as it was conjectured, but a 6801U4. With this ROM, we finally have the final piece of the puzzle for a 100% guaranteed perfect emulation. Checking the original MCU program was very interesting. It was designed to provide many protection features that were eventually not used by the game, like: * Process coin inputs and update the credit counter * Handle the number of remaining lives for both players * Handle the current round number * Handle variable speed incrementing for four variables and * Return values from a 1280 bytes table of seemingly random data. The reasons why those features were not used are probably various. Some of them were probably awkward to use because they require to one one frame for the MCU to process the data, others weren't flexible enough like the coin input processing that wouldn't allow for coinage settings different from the ones hardcoded in the MCU (though versions of Bubble Bobble with different coinage settings don't seem to have been made anyway).
-  4th August    2006: Dave Widel - Good news for Bubble Bobble fans. It seems someone named Trinity has dumped the MCU. Apparently by decapping the chip, photographing it through a microscope and transposing the pic into binary form. Hopefully this will enable some boards to be repaired.
-  3rd August    2006: Nicola Salmoria - What's inside the TAITO JPH1011P MCU? ... It's a MC6801U4 TM7 © 1982. More on this later.
- 0.90               : Nicola Salmoria updated the Bubble Bobble driver. Removed the 68705 CPU emulation, since that's not what the original used, simulated the 68701 MCU (enemy movement should now be correct), fixed clock item behaviour (now enemies start moving again after 10 seconds), supported coin lockout and emulated the boblbobl protection device (getting rid of the ROM patches).
- NOTES: The Motorola M68701 is a microcontroller with 2K internal ROM and read protected. The original Bubble Bobble board has a 68701 protection MCU, which hasn't been read. Its behaviour is simulated and should be a good approximation but not 100% accurate.
- NOTES: KiKi KaiKai uses a custom 68701 MCU which isn't dumped. The bootleg Knight Boy replaces it with a 68705. The bootleg is NOT 100% equivalent to the original (a situation similar to Bubble Bobble): collision detection is imperfect, the player can't be killed by some enemies. I think the bootleggers put the custom mcu in a test rig, examined its bus activity and replicated the behaviour inaccurately because they coudln't figure it all out. Indeed, the 68705 code reads all the memory locations related to the missing collision detection, but does nothing with them.
- SOURCE: machine\bublbobl.c  (68701 protection simulation)
- PCB: JPH1011P protection MCU (Bublbobl)


P9.2   M68705

- 0.115              : Aaron Giles updated 68705 clocks to take into account the internal divide by 4. Added constant so that it is clear why this is being done.
- 17th October   2003: Guru - Received a Dangerous Dungeons PCB from Pelle and dumped the 68705 microcontroller on it.
- 11th August    2003: Guru - Dumped successfully the MCU from Tiger with the Data IO Unisite Programmer.
- 31st July      2003: Guru - Successfully used the Data I/O Unisite programmer to read the 68705 microcontroller on Pit N' Run.
-  8th September 2000: Nicola Salmoria fixed the Return of Invaders driver to use the 68705 emulation correctly instead of relying on a protection hack.
- 17th July      2000: Nicola Salmoria added correct MCU communication to Legend of Kage.
-  1st December  1999: Quench added correct MCU roms to Flying Shark and Wardner.
- 19th August    1999: Nicola added the 68705 image to Fairyland Story, and the attract mode and intro now work, but it hangs when a game is started.
- 0.36b3             : Nicola emulated the 68705 protection in Mania Challenge.
- 13th August    1999: Nicola Salmoria added a 68705 image to Mania Challenge, which is now working!
- 27th June      1999: Nicola modified all the 68705 roms to be 2048 bytes instead of 1920.
- 24th June      1999: Nicola added made-up 68705 roms to Arkanoid's US and Japanese versions, which fixes the later levels.
- 25th May       1999: Tatsuyuki Satoh sent in a preliminary Chack'n Pop driver, but it doesn't really work since the MCU (68705) rom image is missing. Marco Cassili fixed some dips from the Exidy driver.
- 0.35b3             : Nicola Salmoria properly emulated the 68705 protection in The Electric Yo-Yo, Kram, Space Dungeon, Zoo Keeper. And make support for the ORIGINAL version of Bubble Bobble, with 68705 code from a pirate board. Wizards *do* throw stones in this version.
- 0.34b1             : Nicola Salmoria made the original Elevator Action now works, using the 68705 mcu ROM which was missing. Since there is one additional CPU to emulate, it is slower than the bootleg version. Also replaced Front Line with the complete set containing the 68705 code. It still doesn't work though.
- NOTES: The Motorola M68705 is a microcontroller with 2K internal ROM and read protected.
- GAMES: Arkanoid (Taito 1986), Pushman (Comad 1990)
- PCB: MC68705P5S (Tigerh), MC68705P3 (Arkanoid), M68705P5S (40love), MC68705R3  DIP40 (Bballs), MC68705R3P-06A46E-QLCK9018 (Pipeline)


P9.21  M68705 MCU rom
- NOTES: The rom for the M68705 MCU is protected (2048 bytes).
- PCB: Motorola 15-00011-01 DA68235, 28 pins (Fieldday, Pitnrun), DA68305 (Flstory)


P9.22  MC68HC705
- PCB: MC68HC705C8ACS (Goldstar), MC68HC705C8P (Steaser)


P9.3   MC68HC11
- 0.115u3            : Phil Skuse fixed disassembly of brset and brclr opcodes in the 68HC11 core.
- 0.111u2            : Taito JC driver improvements [Ville Linde]: Implemented MC68HC11 communications. Added analog controls via MC68HC11.
- 0.109u5            : Aaron Giles converted the mc68hc11 disassemblers to the new format and added step in/out support where it was obvious.
- 0.91u1             : MC68HC11 compiler fixes [Lawrence Gold]: ANSI C89 unfortunately doesn't allow unnamed structs or unions, so I had to uglify this code a bit. A cleaner solution is welcome.
- 0.91               : Motorola MC68HC11 CPU core [Ville Linde].
- SOURCE: cpu\mc68hc11\mc68hc11.c
- NOTES: Microcontroller with 64k internal ROM
- PCB: MC68HC11M0, QFP80 (Landgear, Sidebs, Sidebs2)



P10.    Namco

P10.1   Cxx
-  4th January   2006: Charles MacDonald - Some information is needed about the M37702 MCUs used in various Namco games. If anyone can help, the following needs to be determined: Which games use the C71, C72, or C73 chips. Which games use the C77 (or higher numbered) chip. What we know so far is: C68  = System 2 (Final Lap 3, Suzuka 8 Hours) + System 21, C69  = NA-1 (World Court Tennis), C70  = NA-2 (Quiztou, Numan Athletics), C71  = System 22 (Master TMS32025 DSP BIOS), C72  = ?, C73  = Found on a test board, but used in any games?, C74  = System 22, C75  = NB-1 (Nebulas Ray) + NB-2 (Out Foxies) + System FL and C76  = System 11 (Xevious 3D/G). In the interim I've been examining the BIOS and working on a better trojan as well as figuring out how hardware on the MCU side works. So far adapting the NA-1 trojan for the C70 chip has not worked, but given the many similarities to C69 I feel a solution is not far off. It looks like all the System 2 games that have C68 do not use the external program ROM socket. Do any System 21 games use it, if such a socket is present? Updated the chip list based on information from Justin (thanks for the PCB pic!), Kayama, Fujix, Oliver, Guru and R. Belmont.
- 19th July      2004: R. Belmont - The Namco sound MCUs (Systems 11, 22, NB-1, NB-2, FL) are read-protected. So we're moving on to plan B. The screenshot is from MAME (trojan program) - if it runs properly on real hardware we'll be able to use it to dump the internal ROMs from all the C7x series sound MCUs. Don't get too excited though, it hasn't even been verified to boot on a real PCB yet.

P10.2   C68
- 19th September 2006: Charles MacDonald - Thanks to ogoun and Stiletto the Namco C68 MCU has been positively identified as a M37450 and I now have some documentation for it. I modified an existing PC-Engine USB / flash memory card I made to interface with the MCU (hooking up through the EPROM and PAL sockets) which has allowed some experiments to be run, but didn't result in the internal ROM being dumped. There are plenty of other things to try - one big advantage is that external memory can be mapped into the stack range (due to limited on-chip RAM) which may allow for a stack overflow technique to be used. Currently I am working on some better development hardware for the 68000 side so I can have external control of the dual port RAM the MCU has access to.
- 24th July      2006: Charles MacDonald - When I was working on the C69 MCU found in the Namco NA-1 hardware, it came to my attention that later Namco System 2 boards had a C68 MCU instead of the HD63705 which earlier revisions used. It seemed reasonable to assume Namco used a M37702 as well considering the C68 and C69 are physically identical. I had picked up two Suzuka 8 Hours boards to examine the C68 and see what possibilities there were for trojaning it.The MCU interface is virtually unchanged for the C68 compared to the previous System 2 boards, except for some slightly different connections and a new address decoding PAL. However the C68 pinout doesn't match any of the M377xx series. After disassembling some of the external program ROM dumps used by the C68 in a few games, investigation of the code shows it's actually a Mitsubishi 740 series based MCU, which is a 6502 core with extra instructions and features. Of course when Mitsubishi's microprocessor division was transferred to Renesas, they dropped support (and documentation!) of the older chips. I was able to reverse engineer the PAL outputs to put together the original equations and come up with a memory map, as well as make a partial pinout of the C68. However, I need some help locating a datasheet (user manual) for it, and I don't know the official part number. The C68 is a 100-pin QFP plastic chip, rectangular in shape with pin counts of 24, 16, 24, and 16 pins going around the perimeter from pin 1. The part has a date marking of 1991. While there are many modern parts that are similar to this chip, most of them are for USB or LED segment drivers and do not have an external address/data bus, which the C68 does. The 3806 group of the 740 series, particularly the M38063M6-XXXFP seems like a very close match, but the pins are shifted around. I already have the 740 software manual (e740sum.pdf). Feature-wise, it has eight analog channels, possibly 6 or more I/O ports (going by Mitsubishi's nomenclature, ports 0,1,2 are the data, address low, address high buses, and ports 3,4,5 are used for general I/O), internal RAM of at 256 to 512 bytes at $0000-007F/$0100-013F, and internal mask ROM of an unknown size. Another unusual feature is that the SFRs are at $D0-$FF instead of $00-$3F which may help in identifying it. In the following pinout, the address/data buses, CNVss, and analog converter channel inputs have to match whatever chip is being looked at as a potential candidate, the others are not critical. I've been through everything I can find at the Renesas website and in my collection of manuals, so I'm fairly sure the C68 corresponds to a part that is no longer in production or supported. If anyone has any tips or ideas about which chip this part is based on, I'd certainly like to hear your suggestions! I'm looking forward to writing code for the C68 as I've been wanting to work with the 740 series chips for a while now. And hopefully, a method to read the internal ROM can be figured out.
- 11th January   2006: Charles MacDonald - I recently purchased two Suzuka 8 Hours PCBs (Namco System 2) and will see what can be done about trojaning the M37702-based C68 custom chip used on it. This would be helpful for System 2 and System 21 games. Also I'd like to take a closer look at the alternate type of video hardware this game has, since there seem to be some minor emulation issues in MAME.
- NOTES: System 2 (Final Lap 3, Suzuka 8 Hours) and System 21 use the C68
- PCB: C68 MCU = M37450 = M37450S2FP (QFP80): Gollygho

P10.3   C69
-  6th May       2006: Charles MacDonald - Guru kindly sent another NA-2 board for me to work with. I've got the NA-1 USB hardware hooked up to it and have tried running some of the C69 trojans as well as new programs to figure out what's going on. Namco did a good job patching up the holes in the C69's security. ;) I'm sure in time the C70 can be dumped.
- 11th January   2006: Charles MacDonald - Progress on the C70 trojan has temporarily halted. After Guru had run a bunch of tests to help determine what was going on, it appears that the MCU commands used by the C69 trojan are implmented as do-nothing functions in the C70, so it isn't possible to simply upload code or do a memory transfer in the opposite direction to read the internal ROM out. Luckily, Guru has offered to send a NA-2 board for me to experiment with, and hopefully some methods for reading the internal ROM can be derived from the C69 BIOS which may apply to the C70.
- NOTES: NA-1 (World Court Tennis) use the C69

P10.4   C70
- 11th June      2006: R. Belmont - Spent most of the day pulling apart the music player in the Namco NA-1 (C69) BIOS looking for exploits we can use to trojan the C70. Unfortunately, unlike the later players, there isn't a wide open opcode that'll do it for us, but I still have many other ideas.
-  6th May       2006: Charles MacDonald - Guru kindly sent another NA-2 board for me to work with. I've got the NA-1 USB hardware hooked up to it and have tried running some of the C69 trojans as well as new programs to figure out what's going on. Namco did a good job patching up the holes in the C69's security. ;) I'm sure in time the C70 can be dumped.
- 11th January   2006: Charles MacDonald - Progress on the C70 trojan has temporarily halted. After Guru had run a bunch of tests to help determine what was going on, it appears that the MCU commands used by the C69 trojan are implmented as do-nothing functions in the C70, so it isn't possible to simply upload code or do a memory transfer in the opposite direction to read the internal ROM out. Luckily, Guru has offered to send a NA-2 board for me to experiment with, and hopefully some methods for reading the internal ROM can be derived from the C69 BIOS which may apply to the C70.
- NOTES: NA-2 (Quiztou, Numan Athletics) use the C70
- PCB: C70 (Emeralda), C70 = rebadged M37702, QFP80 (Namco NA2)

P10.5   C71
- 17th January   2006: R. Belmont - Phil Stroffolino was able to trojan and dump the BIOSes from the C71 3D math engine (actually a TMS32c025) and the C74 sound/inputs MCU (actually an M37702). He's already flying high with the C71 - using that code many long-standing graphics problems are now gone and several games that didn't work properly now work 100% (such as Ace Driver: Victory Lap).
- PCB: C71 TI TMS320C25 DSP, C71 WEYW40116, C71 D72260FN 980 FE-5CA891W (NamcoSystem22)

P10.6   C74
- 0.104u2            : Updates to the Namco System 22 driver [R. Belmont]: Necessary changes to System 22 games to use the real C74 BIOS for music/sound. Added system controller register to boot the C74. Speedup cheat for the CPU board C74. Promoted Ace Driver from NO_SOUND to IMPERFECT_SOUND.
- 17th January   2006: R. Belmont - Phil Stroffolino was able to trojan and dump the BIOSes from the C71 3D math engine (actually a TMS32c025) and the C74 sound/inputs MCU (actually an M37702). The C74 is a bit more interesting. Unlike Super System 22, which has one M37710 (37710 and 37702 are the same MCU, just '02 has an internal ROM and '10 boots externally like a normal CPU), original System 22 has 2 M37702s (C74) with identical internal BIOSes. Based on the state of one of the MCU's inputs, the BIOS boots one of 2 different programs. The first one, intended for the C74 on the I/O board, reads all the inputs, massages them, and transmits them via the MCU's built-in serial port to the second MCU. The second MCU recieves the data via it's own serial port, puts that in shared RAM for the 68020 to see, and handles all the sound and music duties.
-  3rd January   2006: R. Belmont - Charles MacDonald has trojaned the MCU BIOS for Namco NA-1. Primarily this means correct emulated sound and music as opposed to the current (very good) simulation. I'm working on hooking everything up in MAME properly right now. And yes, this can also be considered proof of concept for trojaning other troublesome Namco MCUs (including System 11, 22, NB-1/NB-2, and FL) although the specific method won't quite apply.
-  2nd January   2006: Charles MacDonald - I've been running tests on the Namco NA-1 hardware over the last few days, and figured out how to dump the internal ROM of the M37702 MCU used in Super World Court. The BIOS has a function where code can be copied from the 68000 side over to MCU RAM and executed, making it quite insecure. I wrote a program that copies a portion of the M37702 memory to shared RAM, and the 68000 can change and run the program in a loop to read any part of the MCU address space. I think the same technique will work for other NA-1 games; at least what I've seen in MAME is that a number of them also upload code fragments for the MCU to use. For other types of Namco hardware that use the M37702, it's highly dependant on what services the MCU makes available. Also, now that the BIOS can be examined and user code can be executed on the MCU side for testing, maybe the NA-1 sound hardware (integrated in the multiple purpose 219 chip) will get figured out. Though the existing simulation of the NA-1 sound hardware is remarkably good.
- NOTES: The Mitsubishi M37702 (printed as C74) is a sound MCU with mask ROM
- SOURCE: audio\namcoc7x.c
- PCB: (printed as C74) System 22

P10.7   C75
- 10th August    2006: R. Belmont - On the trojan front, the 68020 side runs well on the PCB, but I've had some issues getting the MCU to cooperate. And at 20 minutes erase time per EPROM the turnaround is pretty nasty (I don't know how Guru puts up with it). Still, onwards we go...
-  6th August    2006: R. Belmont - Finally getting somewhere on the C75 trojan. I found a great universal cross-assembler and wrote a 68020 assembly program based on the startup/diagnostic code from Mach Breakers since that's the PCB I have to play with. Finally I've come up with a program that works to my satisfaction in MAME. Next comes actually trying it on the PCB, but since it's mostly unaltered Namco code it hopefully shouldn't be too problematic.
- SOURCE: audio\namcoc7x.c
- PCB: NAMCO 75 (M37702 MCU) (Speedrcr, NamcoFL-System), NB-1 and NB-2

P10.8   C76
- SOURCE: audio\namcoc7x.c
- PCB: NamcoSystem11




P11.    National Semiconductor

P11.1   COP410
- 0.124u1            : COP CPU updates [Curt Coder]: Implemented interrupt. Implemented serial input/output. Fixed XAD/LDD, XIS1, RMB3 opcodes. Fixed clock divider. Fixed internal memory map size. Added some cpu variants. Fixed serial timer. Fixed clocks. Fixed COP410 RMB3, XAD instructions. General cleanup.
- 0.118u1            : Andrew Gardner fixed two minor bugs in the COP400 CPU disassembler. Hooked up the internal 64 bytes of DATA RAM to the core.
- 0.109u5            : Aaron Giles added save state support to the COP4xx core. Aaron Giles converted the COP4x0 disassemblers to the new format and added step in/out support where it was obvious.
- 0.109u4            : Nathan Woods added a COP410 core to the COP4xx collection.
- 0.109u3            : Added National Semiconductor COP410 emulator [Dan Boris].
- NOTES: The National Semiconductor COP410 is a microcontroller and manages CPU communnication.
- SOURCE: cpu\cop400\cop410.c

P11.2   COP420
- 0.118u3            : Andrew Gardner added counter emulation to the COP420 CPU core. Hooked it up to Thayer's Quest and added an alternate set.
- 0.114u1            : Curt Coder fixed XABR opcode in the COP420 core, added LBI skip for extended opcodes and fixed the CPU name in save states. Added GAME_SUPPORTS_SAVE flag to the Cidelsa games. Draco still has no sound though.
- 0.109u3            : Added National Semiconductor COP420 emulator [MAME Team]. Curt Coder added COP420 core to Draco (Cidelsa 1981).
- 29th January   2001: Phil Stroffolino sent in the playable Looping driver, with correct graphics and colors, but it lacks one of the nicest features of the game - speech and music. The COP420 microcontroller in fact helps with the CPU communication, so it is probably necessary for sound emulation.
- NOTES: The National Semiconductor COP420 is a microcontroller and manages CPU communnication.
- SOURCE: cpu\cop400\cop420.c
- Games : Looping (Venture Line 1982), Thayer's Quest (1984)




P12.    Nichibutsu

P12.1   1411M1
- GAMES: Nichibutsu - Pastel Gal (1985)

P12.2   1412M2
- NOTES: The 1412M2 is a protection chip (not emulated by MAME yet), used by the sound CPU - in Mighty Guy a Z80 CPU.
- GAMES: Nichibutsu - Mighty Guy (1986), Amazon (1986), Sei Senshi Amatelass (1986)

P12.3   1413M3
- 0.86u2             : Takahiro Nogi added some process to the 1413M3 custom chip. And adjusted the interrupt of drivers using machine/nb1413.c/h. So, some titles are broken.
- 0.57               : Moved machine\nb1413m3.h to includes\.
- 0.37b8             : Added machine\nb1413m3.c/h.
- NOTES: This custom chip is use by many Mahjong games (drivers\nbmj8688.c)
- SOURCE: machine\nb1413m3.c - driver by Takahiro Nogi

P12.4   1414M4
- GAMES: Nichibutsu - Terra Force (1987)


P12.5   NSC8105
-  5th June      2002: Jarek Burczynski added a new opcode to the M6800/NSC8105 CPU core.
- 30th November  1999: Zsolt Vasvari sent in a NSC8105 core and modified Seicross driver to use it.
- NOTES: The NSC-8105 is similiar to the M6800/M6802, but the opcodes are scrambled and there is at least two new opcode ($ec and $fc)
- GAMES: Nichibutsu - Frisky Tom (1981), Radical Radial (1982), Seicross (1984)
- PCB: NSC81050-102  8127 E37 (Seicross)




P13.    Nintendo

P13.1   Nintendo VS System (VSNES)

        RP2C03C               Vspinbal, Smgolf
        RP2C03B               Btlecity, Duckhunt, Starlstr
        RP2C04 0001           Hogalley, Machridr, Vsbball
        RP2C04 0002           Bnglngby, Cstlevna, Wrecking
        RP2C04 0003           Excitebk, Goonies
        RP2C04 0004           Iceclimb
        RC2C05-1              Jajamaru
        RC2C05-2              Mightybj
        RC2C05-3              Vsgshoe
        RC2C05-4              Topgun


P13.2   Playchoice security chip
- NOTES: The 16 bytes security data is stored on prom RP5H01.
- SOURCE: drivers\playch10.c

        Playchoice 10 carts examples:

        PCH1-01-ROM      (Pc_ebike, Pc_kngfu, Pc_smb)
        PCH1-01-ROM-A    (Pc_grdus, Pc_tkfld)
        PCH1-01-ROM-B    (Pc_rnatk)
        PCH1-02-ROM-B    (Pc_cntra, Pc_cvnia, Pc_dbldr, Pc_rygar)
        PCH1-02-ROM-D    (Pc_radrc)
        PCH1-01-ROM-E    (Pc_miket)
        PCH1-01-ROM-F    (Pc_rcpam, Pc_tmnt)
        PCH1-02-ROM-F    (Pc_drmro, Pc_ftqst, Pc_ngaid)
        PCH1-01-ROM-G    (Pc_gntlt, Pc_smb3)
        PCH1-02-ROM-G    (Pc_suprc)
        PCH1-04-ROM-G    (Pc_ngai3, Pc_tmnt2, Pc_wcup)


P13.3   Aleck64 (Nintendo64 based hardware)

        CIC-NUS-5101          Boot protection chip    (11beat, Magical, Mtetrisc)
        BK4D-NUS              Similar to the save chip used in N64 console carts

        - 0.105u4: Nintendo 64 system improvements [Ville Linde, Ryan Holtz]: Fixed a major bug in the RSP core, rewrote the PIF handling and slightly improved triangle rendering.
        - 0.105u1: R. Belmont split out some of the Nintendo 64 core pieces into MESS-shareable modules.
        - SOURCE: drivers\aleck64.c + video\n64.c



P14.    Sega

P14.1   Sega encryption
-  4th May       2005: As you might already have seen on Haze's WIP, yesterday I succeeded in decrypting Gardia and Space Position. This was an interesting case of pieces falling into place rapidly one after another. The first piece was the decryption of Calorie Kun, thanks to a decrypted bootleg which was recently found. This didn't look like a particolarly interesting breakthrough at the moment: the encryption algorythm was already known, the key would have been difficult to find by hand but with the reference of the bootleg it could be derived automatically in a few minutes - just the time to write a program. This renewed my interest in the remaining Sega encrypted games that use this algorithm, in particular Gardia. David Widel revealed that he had decrypted a portion of it months ago, but got stuck and put aside the results without publishing them. Believe it or not, he decrypted most of the code by comparing it with My Hero - even if that's a completely different game, it shares a lot of almost identical code with Gardia. The data David provided was very useful to get started. Another really useful coincidence was that we have two sets of Gardia (one supposedly being a bootleg, but still encrypted). The two sets are different versions, with code shifted by a few bytes in places. This is an ideal situation when decrypting games that use simple algorithms like this one. When you have decrypted a portion of code in one set, you can use it to decrypt the same portion of code in the other set; but this way you also automatically decrypt some more code in the second set, which is still encrypted in the first set, so you can go back to the first set and decrypt even more code, and so on - you slowly build up the two keys in parallel. While I was doing this, I rapidly noticed that the key used by the second set for opcodes was identical to the one used by the first set for data. Shortly afterwards, I also noticed that the key used by the second set for data was identical to the one used by the first set for opcodes - just shifted by one byte. At that point I was on the lookout; I have to admit that I didn't notice it immediately, but eventually I discovered that the keys were actually the same as Calorie Kun, apart from the shift. When I found that, I just copied the whole Calorie Kun keys and I was almost finished - Gardia booted but had some problems. I just had to find a few more bytes at the end of the key to fix them. Space Position was the easiest of all. At that point I was almost sure it would have used the same key. I checked some bytes of the partial key I had manually derived years ago, matched them with the known key, copied over the data with the appropriate shift, launched the game, and it was already working, on the first try - apart from the emulation issues which Haze later fixed. This completes the decryption of all currently known Sega games using the "easy" Z80 encryptions. Unfortunately there are a few encrypted Z80 games left, using the suicide MC8123 CPU, which might be lost forever: all boards using the CPU seem to be dead, and the key is just about impossible to find without an hardware attack.
-  4th May       2005: David Haywood - Nicola decrypted Space Position however it doesn't work correctly in the current driver as it uses the hardware in a slightly different way to Angel Kids. I've started fixing the driver, the first fix was using different roms for the upper / lower tilemap (In Angel Kids both tilemaps have identical roms so it was impossible to tell which set was for which tilemap). With this fix the title screen looks good. The sprites may need drawing in reverse order, or a priority bit may be missing / handled incorrectly. There is currently no sound. Update: Fixed sound and hang when game starts due to main CPU requiring a response from the sound CPU. Fixed sprite drawing and added controls. Game seems to be fully playable.
- 0.96               : Nicola Salmoria cleaned up sega Z80 encryption code.
- 0.34b1             : Nicola Salmoria moved the Sega encryption code used by Flicky, Future Spy, and many others, to machine/segacrpt.c.
- NOTES: Several Sega Z80 games have program ROMs encrypted using a common algorithm (but with a different key). The hardware used to implement this encryption is either a custom CPU, or an  epoxy block which probably contains a standard Z80 + PALs. The encryption affects D3, D5, and D7, and depends on M1, A0, A4, A8 and A12. D0, D1, D3, D4 and D6 are always unaffected. The encryption consists of a permutation of the three bits, which can also be inverted. Therefore there are 3! * 2^3 = 48 different possible encryptions.
- SOURCE: machine\segacrpt.c



P15.    Seibu

P15.1   COPX-01
- 0.124u2            : Seibu COP cleanup, primarily sorting the code and identifying similarities in different implementations [David Haywood].
-  7th April     2008: David Haywood -I've decided to dust off the Seibu protection stuff Kale was working on and take a look at that. It's a complex beast to say the least, and quite whether I'll be able to emulate it or not I don't know. Based on what's already been documented there appear to be multiple parts to the protection. A bunch of registers, Some maths operations, DMA operations, a 'Macro' table it uploads and can trigger which can perform other sequenced, complex protection operations on a per game basis, and an external rom 'COPX-01? or 'COPX-02? which is probably used for lookups on some of the maths operations. It looks like the protection device is integrated into the system controller and can access anything on the board. This is of course all undocumented, and figuring it out from guesswork alone isn't easy. I'm currently pondering over the possibility of running some test code on the boards but the interaction with the protection devices (uploading of tables etc.) is vast, complex, and very subtle in places so it's hard to know what to test, especially as it's hard to know where in ram to look for results. There is also a later revision of the MCU using external rom 'COPX-03' which is used on the V33 based "New Zero Team" and "New Raiden 2", however, this MCU seems to be a completely different beast, unrelated to the previous generation. In those cases the games upload a much larger amount of data to the MCU device, maybe the entire program, but it looks to be encrypted. I'm not making any promises that there will be any progress on any of thsee games, but rest assured, they are being looked at, they haven't been forgotten, they're just *hard*, really hard, especially the non-68k based ones which have additional banking issues to worry about.
- NOTES: The Raiden 2 hardware games use the 2nd (and 3rd) generation of Seibu's 'COP' protection, utilizing the external 'COPX_D2' and 'COPX_D3' lookup roms (probably for math operations)  These chips, marked (c)1992 RISE Corp. are not thought to be the actual MCU which is probably internal to one of the Seibu customs.
- GAMES: Legionnaire (TAD 1992), Seibu Cup Soccer (Seibu 1992)
- PCB: COPX-D1 (cupsoc), COPX-01 (legionna)


P15.2   COPX-02
- 0.124u2            : Seibu COP cleanup, primarily sorting the code and identifying similarities in different implementations [David Haywood].
-  7th April     2008: David Haywood -I've decided to dust off the Seibu protection stuff Kale was working on and take a look at that. It's a complex beast to say the least, and quite whether I'll be able to emulate it or not I don't know. Based on what's already been documented there appear to be multiple parts to the protection. A bunch of registers, Some maths operations, DMA operations, a 'Macro' table it uploads and can trigger which can perform other sequenced, complex protection operations on a per game basis, and an external rom 'COPX-01? or 'COPX-02? which is probably used for lookups on some of the maths operations. It looks like the protection device is integrated into the system controller and can access anything on the board. This is of course all undocumented, and figuring it out from guesswork alone isn't easy. I'm currently pondering over the possibility of running some test code on the boards but the interaction with the protection devices (uploading of tables etc.) is vast, complex, and very subtle in places so it's hard to know what to test, especially as it's hard to know where in ram to look for results. There is also a later revision of the MCU using external rom 'COPX-03' which is used on the V33 based "New Zero Team" and "New Raiden 2", however, this MCU seems to be a completely different beast, unrelated to the previous generation. In those cases the games upload a much larger amount of data to the MCU device, maybe the entire program, but it looks to be encrypted. I'm not making any promises that there will be any progress on any of thsee games, but rest assured, they are being looked at, they haven't been forgotten, they're just *hard*, really hard, especially the non-68k based ones which have additional banking issues to worry about.
- NOTES: The Raiden 2 hardware games use the 2nd (and 3rd) generation of Seibu's 'COP' protection, utilizing the external 'COPX_D2' and 'COPX_D3' lookup roms (probably for math operations)  These chips, marked (c)1992 RISE Corp. are not thought to be the actual MCU which is probably internal to one of the Seibu customs.
- GAMES: Heated Barrel (Tad 1992), Denjin Makai (Seibu 1993), Zero Team (Seibu 1993)
- PCB: COPX-D2 (Rise Corp. 1992), DIP40 (denjinmk, heatbrl, zeroteam)


P15.3   COPX-03
-  7th April     2008: David Haywood -I've decided to dust off the Seibu protection stuff Kale was working on and take a look at that. It's a complex beast to say the least, and quite whether I'll be able to emulate it or not I don't know. Based on what's already been documented there appear to be multiple parts to the protection. A bunch of registers, Some maths operations, DMA operations, a 'Macro' table it uploads and can trigger which can perform other sequenced, complex protection operations on a per game basis, and an external rom 'COPX-01? or 'COPX-02? which is probably used for lookups on some of the maths operations. It looks like the protection device is integrated into the system controller and can access anything on the board. This is of course all undocumented, and figuring it out from guesswork alone isn't easy. I'm currently pondering over the possibility of running some test code on the boards but the interaction with the protection devices (uploading of tables etc.) is vast, complex, and very subtle in places so it's hard to know what to test, especially as it's hard to know where in ram to look for results. There is also a later revision of the MCU using external rom 'COPX-03' which is used on the V33 based "New Zero Team" and "New Raiden 2", however, this MCU seems to be a completely different beast, unrelated to the previous generation. In those cases the games upload a much larger amount of data to the MCU device, maybe the entire program, but it looks to be encrypted. I'm not making any promises that there will be any progress on any of thsee games, but rest assured, they are being looked at, they haven't been forgotten, they're just *hard*, really hard, especially the non-68k based ones which have additional banking issues to worry about.
- NOTES: The Raiden 2 hardware games use the 2nd (and 3rd) generation of Seibu's 'COP' protection, utilizing the external 'COPX_D2' and 'COPX_D3' lookup roms (probably for math operations)  These chips, marked (c)1992 RISE Corp. are not thought to be the actual MCU which is probably internal to one of the Seibu customs.
- PCB: COPX_D3.357 (Raiden DX Seibu 1996)


P16.    Texas Instruments

P16.1   TMS32010
- 0.110u3            : Rainer Keuchel fixed bug in overflow handling and SUBC emulation in the TMS32010 core.
- 0.109u5            : Aaron Giles converted the tms32010 disassemblers to the new format and added step in/out support where it was obvious.
- 0.80u2             : Quench fixed some problems with the 32010 update. Cycle counts for invalid opcodes 7F1E and 7F1F are now 0.
-  2nd March     2004: Quench added internal data memory map to the TMS32010 CPU core and fixed overflow in the ADDH instruction, and adjusted the Twin Cobra / Wardner, Toaplan1 and Hard Drivin' drivers accordingly.
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. * Harvard architecture CPUs now have data memory fully implemented now. Affected CPUs are the ADSP210x, TMS3201x, TMS3202x, PIC16C5x, and CCPU. All cores have been modified to fully split program and data memory. All drivers using these cores now specify explicit program and data memory maps. This also gets rid of a ton of ugly macros used in memory maps. [Aaron Giles]
- 30th May       2003: Aaron Giles fixed the BIO pin handling in the TMS32010 CPU core.
- 0.62               : Changed name '320C10' to 'TMS32010'.
- 0.37b9             : The TMS320C10 core are now full 16-bit cores. This fixes gameplay in several Toaplan games [Aaron Giles].
- 0.35b8             : Changed name 'TMS32010' to 'TMS320C10'.
- 0.35b3             : TMS32010 emulator [Quench]. Quench emulated the protection (TMS32010) in Twin Cobra, which is now fully playable.
- SOURCE: cpu\tms32010\tms32010.c - TMS32010 DSP code by Tony La Porta
- GAMES: Toaplan - Twin Cobra (1987), Flying Shark (1987), Wardner (1987), Demon's World (1989)
- PCB: TMS320C10NL-14 microcontroller (Twincobr), D70012U GXC-02 MCU 71400 (SkyShark), D70012U GXC-02 MCU (Delta) 71900 (Wardner), D70016U GXC-04 MCU (delta) 74000 (TwinCobra)

P16.2   TMS32015
- NOTES: The TMS32015 controlls palette, sounds and inputs and has a built-in ROM.
- GAMES: TMS320E15 (AmeriDarts), TMS320P15FNL (Hdrivair)

P15.3   TMS32020
- 0.78u4             : CPUs with an implicit address shift (e.g., the TMS34010 shifts addresses right 3 bits; the TMS32031 shifts addresses left 2 bits) now automatically get that shift applied to addresses in their memory maps and in calls to install_memory_read/write_handler(). This eliminates many ugly macros in the memory maps. Affected CPU cores are the ADSP210x, CCPU, PIC16C5x, TMS3201x, TMS3202x, TMS32031, and TMS340x0. Note that the CPU cores themselves still need to pass shifted values to the core read/write routines. All drivers using these cores have had their icky macros and bitshifts removed. * Harvard architecture CPUs now have data memory fully implemented now. Affected CPUs are the ADSP210x, TMS3201x, TMS3202x, PIC16C5x, and CCPU. All cores have been modified to fully split program and data memory. All drivers using these cores now specify explicit program and data memory maps. This also gets rid of a ton of ugly macros used in memory maps. [Aaron Giles]
- SOURCE: namcos21.c




P17.    Taito

P17.1   C-Chip
- 0.97u1             : Bryan McPhail added proper C-chip emulation to Operation Wolf.
- 0.96u2             : Bryan McPhail improved C-chip simulation in Volfied to accurate timing and correct colour data for all levels.
- 0.57               : Improved C-Chip simulation in Bonze Adventure [Stefan Jokisch, Ruben Panossian].
- 24th November  2001: Stefan Jokisch resubmitted an improvement to the C-Chip emulation for Bonze Adventure.
-  2nd September 2001: Stefan Jokisch improved the C-Chip emulation in Bonze Adventure.
-  7th December  2000: David Graves updated the Rainbow Islands driver to work a bit better and added better C-chip emulation done by Stefan Jokisch.
- 27th November  2000: Stefan Jokisch submitted a fix for Rainbow Islands secret room bug caused by incomplete C-chip simulation.
- 0.35b12            : Mike Coates makes Rainbow Islands playable (using the C-Chip dump from Jumping).
- 21st April     1999: Mike Coates emulated Rainbow Island's C-Chip more correctly.
- NOTES: The Controller or "Command Chip" is an encrypted Z80 which communicates with the main board as a protection feature. In Superman, the C-chip's main purpose is to handle player inputs and coins and pass commands along to the sound chip. In Mega Blast, the C-Chip will simply used as RAM, the game doesn't even bother to change banks.
- SOURCE: machine\chip.c
- PCB: Taito TC0030CMD SDIP64 (Bonze Adventure, Volfield), TC00300MD (Opwolf), TC 0030 CMD (Megab)




P18.    Other

P18.1   Program Protection

        1943.c, blktiger.c : The game crashes (thru a jump to 0x8000), if a read from this address doesn't return the value it expects.
        aeroboto.c : Protection read at 0x2973, 0x3004 and writes at 0x01a2
        afega.c    : Unknown write to 0x080012/13. This fixes the text in Service Mode.
        airbustr.c : Reading $efe0 ram probably resets a watchdog mechanism that would reset the main cpu.
        clshroad.c : Protection at 0x05C6 - The death sequence in Fire Battle never ends so the game is unplayable after you die once.
        kopunch.c  : It looks like there is a security chip, that changes instruction of the form: ld a,$0C + jr nc,$0333  into something else (maybe just a nop) with the effect of resuming execution from the operand of the JR  NC instruction.
        mpatrol.c, mrdo.c : Moon Patrol do strange things if a read from address 0x8800 doesn't return the value it expects. Mr. Do! doesn't clear the screen if a read from address 0x9803 doesn't return the value it expects.
        naughtyb.c : 1st protection in Pop Flamer relies on reading values from a device at $9000 and writing to 400A-400D (See $26A9). Then value stored in 400C must be xxxx1001 (rrca x 3) or else reset. 2nd protection relies on the values stored in 400A-400D matching $2690+($400E) (Starts at $460). If the values all match then it will jump to 0x0011 instead of 0x0009 (refresh instead of reset).
        offtwallc  :  In several places of 'Off the Wall', the value 1 is stored to the byte at $3fdf1e. A fairly complex subroutine is called, and then $3fdf1e is checked to see if it was set to zero. If it was, "HARDWARE ERROR" is displayed.


P18.2   Random Number Generator
- 0.70u5             : Barry Rodewald changed drivers to use mame_rand for random numbers.
- 27th June      2003: Barry Rodewald changed all drivers needing random numbers to use MAME's own random number generation.
- 26th January   2003: Bernd Wiebelt added a generic random number generator to the core.
- NOTES: In 99% of arcade games, a software based pseudo-random number generator is used. It's code no different from that driving the gameplay, so it's 100% accurate. The random number simulation that was added to the MAME Namco System1 driver is a hack. They read values from a special chip. It's deterministic, sometimes used for protection, and other times for pseudo-random values. The code that was added isn't based objectively on the behavior of the real cuskey, which has yet to be reverse-engineered.
- GAMES: Splatter House (Namco 1988), Sega System 32 games (have a true hardware random-number generator), NeoGeo Games (SMA chip ?)


P18.3   Opcode encryption
- 0.35b1: Nicola Salmoria added a horrible dirty hack to allow opcode encryption on CPUs other than the main one. It's really ugly and needs a rewrite, but it's enough to get sound in Pocket Gal and The Real Ghostbusters.

P18.4   DL57S22
- NOTES: In Survival (Rock-ola 1982) there is a 14 pin part connected to the 8910 Port B D0 labeled DL57S22. There is a loop at $2002 that reads the player controls -- the game sits in this loop as long as Port B changes.  Also, Port B seems to invert the input bits, and the game checks for this at $2f32.  The game also uses the RIM instruction a lot, that's purpose is unclear, as the result doesn't seem to be used (even when it's stored, the result is never read again.)  I would think that this advances the protection chip somehow, but isn't RIM a read only operation?
- SOURCE: drivers\phoenix.c


P18.5   Toshiba T5324
- 12nd September 2003: Guru - Finally completed the adapter to read the nasty Toshiba embedded ROM on US Championship V'Ball. Still some work to do though, it's not quite giving us the correct read yet... it's taken Jarek and I many hours over several months to get to this point, we're not far off now.
- PCB: Toshiba 0615 T5324 TRJ-101 (Vball)


P18.6   Mitsubishi M50747
- 19th November 2006: Tomasz Slanina - Working on Double Dealer protection similar to used in other jalmah.c games (Mitsubishi M50747 MCU used for protection and providing main program code snippets), shots from real board, not emulation.
- NOTES: Single-chip 8-bit CMOS Microcontroller (6502 CORE), 8192 ROM, 256 RAM, SDIP64
- PCB: M50747 (Daireika, Kakumei, Mjzoomin)


P18.7   ASIC
- SOURCE: machine\pgmprot.c
         ASIC3         Oriental Legend (1997 IGS)
         ASIC022       Dragon World 3 (1998 IGS)
         ASIC025       Dragon World 3 (1998 IGS)
         ASIC28        Knights of Valour (1999 IGS)


P18.8   CAT702
- NOTES: The CAT702 is a ZN security/protection chip/MCU (DIP20).
- NOTES: The chip has a sticker of the form XXnn, where XX is the company and nn a number: AC = Acclaim, AT = Atlus, CP = Capcom, ET = Raizing, KN = Konami, MG = Tecmo, TT = Taito and TW = Atari
- SOURCE: machine\znsec.c
- PCB: CAT702 103090-ET02 = Raizing (Beastrzr), CAT702 103090-MG03 (Cbaj), CAT702 CP06 = Capcom (Rvschool), TT10 or TT16 (Taito GENT-System)


P18.9   Address lines scrambling
- SOURCE: drivers\afega.c


P18.A   Dongle
- 0.106u5            : Juergen Buchmueller added new dongle data (cexplore.pro 32 byte) to Explorer (Cassette). The dongle data is reverse engineered by table analysis.
- 0.106u3            : David Widel and Juergen Buchmueller added dongle data (TYPE1 DONGLE (DE-0061) with alternate PROM) to Highway Chase. The dongle data is reverse engineered from manual decryption - Game now playable.
- 27th May       2006: Dave Widel - I've been working on the decryption for chwy, so I haven't had any sleep for two days. I can't stop once I start working on something like this. I have ~233 out of the 256 decrypted. Usually they get easier by this point but this one seems to get harder as I near the end. UPDATE: Looks like the data in my table repeats. Juergen spotted it imediately. I have enough data already for him to solve it, looks like chwy is decrypted.
- 18th March     2006: Guru - A 984A02 dongle and a Magic Gate security dongle (Capcom/Banpresto 2003 - Namco System 256 hardware) arrived late yesterday from Japan.
- 0.99u2             : Juergen Buchmueller improved some DECO cassette games. Found bitswap for Zeroize type #3 dongle; found hack to get it running w/o the dongle ROM by debugging the game code; changed year to 1983; removed NOT_WORKING flag. Changed visible area to 240x248.
- 0.89u5             : Juergen Buchmueller added a NOP dongle (returning the data read from cassette as is) to Flying Ball - Game now playable.
- SOURCE: machines\decocass.c


P18.B   Custom security

P18.B1  Epoxy block
- PCB: Check the lizwiz.txt for: How to reading the data of 2x 2732 EPROMs in a epoxy block.
- PCB: Springer - The security CPU module is in a tin shell about 3x4 inches which is filled with epoxy, removing the epoxy exposes a Nicad, a Z80, a 6116LP RAM, a 74LS32, a 74LS05 and a 4069 plus a few diodes & resistors. The first ROM has a blank space and I assume that the RAM has program code stored in it to act as unaccessable ROM code.
- PCB: S562008 - Custom security block (battery backed) (Hardhead, SuperRanger), SUNA T568009 (HardHead2, Sparkman)

P18.B2  BBX
- NOTES: The BBX coprocessor in Shanghai Kid (Taiyo 1985) is burried in an epoxy block (1.5" by 2" by 4") and it is connected to the PCB by a 40 pin DIP socket labeled IC30. It contains a surface-mounted Z80 (TMPZ84C00P), LS245 logic IC and Fujitsu MB8464 ram (8k x 8 SRAM, external battery backed). The BBX coprocessor receives graphics and sound-related commands from the main CPU via shared RAM. It directly manages an AY8910, is responsible for populating spriteram, and forwards appropriate sound commands to the sample-playing CPU.
- SOURCE: drivers\shangkid.c





P19.    Programmable Logic Devices (PLDs)

-  6th December  2007: Charles MacDonald - Boolean minimization: I have been getting quite a lot of feedback about the PAL analyzer circuit. Currently it will generate the minimal equations for a given pin, and then do a term coverage check to remove intermediate equations that resulted from the minimization but should really be replaced with another one that has wider coverage of the input terms. What I didn't expect was pin polarity being an issue. One of the M92 PALs had a pin which reduced to the following mess assuming it was an active low output: *...*. Looks like some complicated logic was involved. But if we assume it's active high. As you can see the polarity you are targeting during minimization makes all the difference. As a quick way of attempting to generate the smallest set of equations possible I added a check to find which output level occurs the least for a given pin. It's also entirely possible to have a simple set of equations that generate the opposite of the desired polarity and a complex set that give the desired one. I think to keep the output of the program as human-readable as possible I will always try to generate the smallest set, and this means running the minimization process twice to see which polarity gives the best results. The amount of data to process for a given pin increases exponentially based on the number of input terms used; currently the program slows to a halt when processing a CPS-2 PAL that has 12 inputs (4096 equations). There are a number of optimizations that can be made, but for now I want to keep the program simple enough until the basic functions of it work properly. Then I'll tune it for speed. The dumping process has been tweaked quite a bit and it can dump a PAL in a few seconds instead of ~15 minutes. Note that the dumping process (generating a binary dump of all PAL states from the target device itself) and the minimization (turning the state data into a set of equations) are two very different things. I have been running tests on the Jaleco Mega System 32 hardware, but for some reason I can't get any layer other than the text foreground layer to appear. I'm sure all I need is the right combination of video register settings and priority RAM settings, but nothing is working yet. Hopefully I'll have more updates about it in the near future.
-  2nd November  2007: Charles MacDonald - Replacing a PAL: I picked up an Irem Gunforce (M92) board recently. After dumping the PALs I found the board wouldn't boot and the picture wouldn't sync - turns out IC51 had been inserted backwards. Oops! What kind of damage had been done? Hopefully just IC51 was bad and the rest of the hardware was OK. IC51 is a 16L8 type PAL. The device was programmed in 'simple' mode as opposed to 'complex' mode which allows output pins to be tri-stated individually. Bidirectional pins 13 and 15 were always tri-stated, so they were inputs, or (less likely) outputs with their output enables turned off. Which inputs were used? Of the six outputs, each one only uses a handful of inputs. This seemed promising - there would be less data to examine. A number of the inputs were never used, either the settings particular to Gunforce didn't call for them or the pins were left disconnected. At some point I'll take the two PCB apart to see what these pins are connected to. What you don't always see is a case where each output pin has only one set of inputs that drive that pin to a certain level. That meant all other sets of input combinations could be rejected (omitted in the above listing for brevity). This also revealed the "active" polarity for each output pin, active low, low, low, low, high, low respectively. I had some 22V10 to 16V8 adapters from my CPS-2 projects, so I wrote up a set of replacement equations in WinCUPL. I burned the resulting JEDEC fusemap to a 22V10, plugged the adapter into the IC51 socket on the Gunforce board and powered it up. Success! The self-checks passed and the attract mode started cycling. As the first real use of dumping an unknown PAL and (manually) generating a replacement, the PAL analyzer worked perfectly. Not all PALs use simple logic equations as shown above and that's where you need the software to examine and reject unused input settings automatically. You could easily have thousands of input settings to look through. But in this case, the data set was small enough to be examined by hand. The old PAL seems to be permanently damaged, when redumped the data suggests all bidirectional pins have changed to input only. So remember, don't plug PALs in backwards! Or at least dump them first.
- 26th October   2007: Charles MacDonald - PAL analyzer: A few months ago I developed a device to analyze read-protected PALs conforming to the 16x8 pinout over a USB connection. The hardware works fine, but the software has been quite difficult to write given all the different ways PALs can be configured. I think I'll release the project files soon rather than wait any longer to finish it. Currently the software can detect the following: - Bidirectional pin function (input, output, output+OE). - Inputs used by a bidirectional pin in output or output+OE mode. - Inputs used for the OE-enabling input of a bidirectional pin. - Device configuration (registered, complex, simple). - Presence of I9 acting as a global-OE for bidirectional pins. This is a hint towards identifying registered 16V8 PALs. Device support: All 16L4, 16L6, 16L8 compatible parts and 16V8 compatible parts in complex or simple mode. There is no standard way to determine how a registered PAL works, but you can write your own test function to send data to the PAL and see how it responds. This allows support of 16R4/6/8 and 18VC8 devices on a case-by-case basis, and PLS153/CK2605 devices if pins 9,11 aren't configured as outputs. It may be possible to support registered devices that simply latch inputs and used the feedback from the macrocells to feed the logic array, but more complex things like counters, state machines, shift registers, FIFOs, and multiple latches are too specific to detect in a generic way. Pins configured in combinatorial mode for a registered PAL that don't rely on feedback from a registered macrocell can still be analyzed, however. The next step is to determine the logical relationship between the input terms that enable a particular output or assert it, though that part isn't quite done. I have a working program to do this with a simple PALs (assuming 10 inputs, and all bidirectional pins are output-only, with no output enable controls) but it needs to be rewritten to support all configurations properly. When that is done a PAL dump can be converted to a CUPL source file describing all the logic the PAL implements. From that point you could burn a 100% compatible replacement part for repair or in the context of emulation see exactly what the PAL does. I've wanted a plug-and-play solution for PAL dumping in a lot of previous projects, and it's great to almost have it now.



P19.1   PAL
        PAL = Programmable Array Logic

        - 0.105u4            : Aaron Giles added a new tool jedutil, which will convert .JED files to binary form and back again. Added new ROM region REGION_PLDS, which is designed to hold binary dumps of PLD fusemaps (produced from .JED files by jedutil). Added logic to -romident to automatically parse .JED files to identify them against these binary dumps. Added PLD dumps to the Vindicators, Batman, Pit Fighter, ThunderJaws and Relief Pitcher drivers. More to come shortly. Converted PLDs for catnmous and lazarian to the new binary format.
        -  2nd May 2006: Aaron Giles - One of the best uses of MAME is the identification of random video game parts. Thanks to the -romident feature, you can dump a ROM or PROM from a game and pretty quickly identify what game you have. Believe me, as someone who owns a giant pile of PCBs, it is not always easy to tell. In theory, MAME should catalog all the programmable parts on an arcade PCB. This is useful not only because of the -romident feature, but also because if a part fails due to bit rot or corrosion or some other kind of damage (or is just missing), you can identify it, track down the data, and program yourself a new one. Up until now, we have only been really cataloging ROM-based devices, in spite of the fact that another class of device " the Programmable Logic Device (PLD) " is often found on PCBs, especially those dating from the mid-80's onward. PLDs are a class of device that includes PALs, GALs, and other related devices, which are programmable in much the same way that ROMs and EPROMs are. One of the big reasons why we haven't been including PLDs is because they are generally not stored in raw binary format, like ROM data. Rather, they are stored in a format known as the JEDEC file format (.JED), which is basically a text file containing all the data, with lots of room for programmer-inserted comments and many optional fields. This is not really a big problem in and of itself, except for the fact that every single programmer out there, when reading a PLD, will produce slightly different output. This in turn makes tools such as the -romident feature useless for such devices because -romident works by comparing the CRCs and SHA1s of the files, which would be different even for the same PLD read by different programmers. I finally took a close look at the .JED file format over the past week, and came up with several strategies for how MAME can finally begin cataloging these parts. After a bit of discussion, I finally settled on one that will be implemented in the 0.105u4 release which should be coming up shortly. Here is how it works. At the creamy center of a .JED file is what is known as the 'fuse map'. This is the raw set of binary 1s and 0s that get programmed into the PLD. In fact, the rest of the .JED file beyond that is mostly filler: some checksums, default states for unspecified fuses, etc. The final fuse map is really the important data, along with the type of device that was used (was it a GAL16V8A or a PAL16L8?).
                                       So the basic premise for logic devices in MAME works like this: the fuse map is stored in raw binary form, preceded by a single 32-bit (big-endian) value that specifies the total number of fuses. Each bit of the fuse map is packed into a byte from LSB to MSB. This, it turns out, is the exact format that is used for the internal fuse map checksum, so it is a natural arrangement. I decided not to try and encode the device type into the file because (a) there are way too many devices to be concerned with, and (b) many devices with similar but not identical names are equivalent. Rather, PLDs that are added to MAME should specify the device type in the filename. (Also keep in mind that if the device type were encoded into the file itself, then if person A reads a GAL16V8 and person B reads a GAL16V8A that contain identical data, they would not match). How do you get data in and out of this format? Well, starting with 0.105u4, the default build of MAME will build a new utility called jedutil, which can convert a .JED file into its binary form, and vice-versa. This means that you can find the binary form of a PLD, run jedutil on it, and extract a .JED which can be programmed into a real life PLD using any standard programmer. So how does this help -romident? Well, if you read a PLD from a board and want to see if it matches anything we've cataloged, you can do one of two things. You can take the resulting .JED and run jedutil on it to convert it to binary form. Or, you can just point -romident to the .JED file directly, because I've added code to the romident feature that recognizes .JED files and automatically parses them into binary form on the fly. The first experiments in using this will be the mid-80's and later Atari games, which I've been working on cleaning up the names on, and which I've already read the GALs from. I know there are several other games out there that we already have good PAL/GAL dumps from as well. Hopefully we can produce an even more complete catalog of arcade game devices as a result.
                                       Many of Atari's games used GALs to control the logic for memory addressing, video, and sound. Unfortunately, most of the GALs on shipping Atari boards have the security fuse blown, meaning that if one goes bad, you'll have a tough time trying to make a replacement. Furthermore, since GALs are EEPROM based, they are subject to deterioration over time. Luckily, some equipment does exist that can read these protected GALs. So, as a service to anyone out there who needs a replacement GAL to fix an Atari board, I've decided to set up this page where you can grab the necessary JEDEC files for any GALs you need to replace. Disclaimer: Although these reads were taken from working boards, I have not programmed replacements for these to verify that the JEDEC files are accurate.
        - SOURCE: tools\jedutil.c


        PAL10H8      Suprglob
        PAL10L8      Gaplus, Maniach
        PAL12L6      Cchasm, ZeroTarget, PAL12H6 (Archrivl)
        PAL12L10     Metlhawk, Cosmo
        PAL14L4      Citycon
        PAL16B4      Ssozumo
        PAL16H2      Seicross
        PAL16L8      MMI PAL16L8ACN, PAL16L8BCN, PAL168ACN (Ddragon), AMD AMPAL16L8APC, TIBPAL16L8 (20 pins), PAL16L8NC (Freekick, Ufosensi)
                     The PAL16L8ACN encrypted the data in roms. An encryption table can you find in drivers\galaxian.c (-> init_checkman)
        PAL16R4      PAL16R4A, PAL16R4B, PAL16R4PC, PAL16R4ANC, PAL16R4NC, MMI PAL16R4CN (DIP20), AmPAL16R4A
        PAL16R6      Aso, Crzrally, Chopper   NOTES: In Bagman a PAL16R6 is used for guards controlling (Inputs are connected to buffered address lines AB0, AB1, AB2, AB3, AB4, AB5 and AB6)
        PAL16R8      Captaven, Skullxbo
        PALCE16V8    PALCE16V8H (Oisipuzl), PLCE16V8 (Spacedx), AMD PALCE 16V8H stamped 'PS5-1', DIP20 (Gunbird2)
        PAL20L8      PAL20L8BCNS (Darius2, Archrivl, Cadash), PAL20L8BCN (NamcoFL-System)
        PAL20L10     PAL20L10ACNS (Buccanrs), PAL20X10 (Trisport), PAL20X10 (Archrivl, Luckywld, Elvactr)
        PAL20R4      PAL20R4ACNS (Ninclown, Ufosensi)
        PAL20V8      Luckywld
        PALCE20V8    PALCE20V8H  DIP24 (Rfjet), PLCE20V8 (Spacedx), PAL CE 20v8h (Trucocl)
        PALCE22V10   PALCE22V10H-25PC/4 (Megat6, Propcycl, Alpinerc)

        TIBPAL16L8   (Btlkroad, Finalb)
        TIBPAL16R4   (Timekill)
        TIBPAL22V10  TIBPAL22V10ACNT (Hotmind)

        EPL10P8      (Legend), EPLIOP8BP (Stratof)
        EPL12P8      EPL12P6A (Airwolf), EPL12P6 (Legend)
        EPL16P4      Ricoh EPL16RP4BP (F1GP)
        EPL16P8      Ricoh EPL16P8BP (Ashnojoe, Spinlbrk), EPLIOP8BP (Stratof)

        ATF1500      Atmel ATF1500A      PLD  A-22912 (Gauntdl)
        ATF16V8      Atmel ATF16V8-10PC  DIP20, ATF16V8B marked A-21647    (Area51, Crysking, Metmqstr)

        18CV8        18CV8PC (Mgcrystl), AMI 18CV8 (Riot), 18CV8 (Sailormn), HY18CV8S (Rebus, Twinadv), ICT PEEL 18CV8P  DIP20  stamped 'SXX005-5' or 'SXX011B' (Bmcbowl, Rfjet)
        22CV10       ICT 22cv10aj (Area51), 22CV10 (Hayaosi1), 22CV10P (Boogwin)

        Signetics
        CK2605       DIP20 (Shinobi, Sega-System16a)
        PLS153       PLS153A (Smathtv), PLS 153N (Xenophob)
        PLHS18P8     PLHS18P8BN (Othunder, Gollygho, Airco22b)


        NAMCO
        SYS87B-1 = SYS87B-2B = PAL16L8
        SYS21C1  = SYS21PC1  = PAL20L8
        SYS87B-3             = PAL20L10
        PCB: Airco22b, Gollygho



P19.2   GAL
        GAL = Gate Array Logic

        GAL16V8      PLCC20, DIL20, DIP20       GAL16V8A (Finalb, Pitfight), GAL16V8B (Gogomile), GAL16V8D stamped 'MCTL01'(Gnbarich, Rfjet)
        GAL20V8      PLCC-28, DIL-24            GAL20V8A 15LP L244D02 (Timekill), GAL20V8B (MK3), GALv20V8B (Topshoot)
        GAL22V10     PLCC-28, DIL-24            GAL22V10B (Drtomy)
        GAL6001      (Guardian)          NOTES: The SLOOP (or "SLOOPstic") is a follow-on chip to the slapstic. It provides a similar type of security, but is programmed onto a GAL6001, rather than a custom part. It was created because Atari was running out of slapstics to use in their games, and the original masks for the slapstic had been lost by the company that manufactured them. A separate FAQ for this chip is planned for the future.

        SCX6218UTP   National Semiconductor MicroCMOS Gate Array  (Stunrun), SB942 SCX621BUTP (Hdrivair, Racedriv), SCX62180UTP (Harddriv)



P19.3   CPLD
        CPLD = Electrically Erasable Complex Programmable Logic Device

        Altera
        EPM3064     ALTERA MAX EPM3064ATC100-10  (TQFP100, stamped S10MA2A)                           (MrDriller2)
        EPM7032     ALTERA     EPM7032LC44-15T D9522, QFP44/PLCC44 (Midway no. A-22544)               (Bangball, Gauntleg, Inufuku)
        EPM7064     ALTERA     EPM7064QC100 CPLD (QFP100), EPM7064LC84 (PLCC84)                       (Taito GNET-System)
        EPM7128     ALTERA MAX EPM7128ELC84-20, MAX EPM7128STC100-10 (labelled S12M841), MAX7128      (Gotcha, Tekken Tag Tournament)
        EPM7160     ALTERA MAX EPM7160ELC84-10 (PLCC84 CPLD, labelled 'PSX PiD 9-19-96 2FDA')         (Primrag2)

        AMD
        MACH110     CPLD, PLCC44  (Poitto, Pururun, Tickee)
        MACH111     GTI Club (Konami 1996), NBA Jam Extreme (Acclaim 1996), Silent Scope 2 (Konami 2000)
        MACH130     The Return of Lady Frog (Microhard 1993)
        MACH210     MACH210-15, QCC44, switch matrix CPLD (Ncv1, BurglarX, EggVenture)
        MACH211     Battle Bakraid (8ing 1999), Beastorizer (8ing 1997), Brave Blade (8ing 2000)
        MACH231     MACH231-15-JC/1-18JI/1 (Snookr10)

        Cypress
        CY37064     CPLD KEYCUS, PLCC44, labelled KC048 or KC053   (Aquarush, MrDriller)
        CY37128     CY37128VP160 CPLD, TQFP160, labelled KC001A    (Gamshara, MrDriller)
        CY37256     CY37256VP208 CPLD, TQFP208                     (NamcoSystem10)

        Lattice
        pLSI 1016   LATTICE pLSI1016  PLCC44  (suprnova.c), isp1016E (Deerhunt)
        pLSI 1032   pLSI1032 (Stagger), Lattice pLSI 1032-60LJ (Hyperpac, Newfant), 1032E (Rbmk)
        pLSI 2032   Lattice pLSI 2032-80LJ (Behind Enemy Lines, Jchan), ispLSI2032 (Deerhunt)
        pLSI 2064   PLCC 44
        pLSI 2096   TQFP 128

        SDT7134     PLCC44, custom CPLD ?  (F15se)

        XILINX
        XC7336      XILINX PC44ACK9633 A63458A                   (Tetrisp2, Rdft)
        XC9536      XILINX CPLD (PLCC44, Konami no. Q931H1)      (Gaia, Sscope2)
        XC9572      XILINX CPLD (TQFP100)                        (Gauntleg)
        XC95108     XILINX (PQFP100, Flash Complex PLD)          (Bbakraid, Gunpey)
        XC95144     XILINX (TQFP100, Flash Complex PLD)          (Bbakraid)
        XC95288     XILINX (TQFP208, Flash Complex PLD)          (G-Stream G2020)




P19.4   FPGA
        FPGA = Field Programmable Gate Array


        Altera
        EPF10K10QC208    ALTERA EPF10K10QC208-4 FPGA               (NeoGeoHyper64)
        EPF6016TC144     ALTERA EPF6016TC144-2  FLEX 6000 PLD, TQFP144    (Gauntleg, Gauntdl)

        Actel
        A128oxc          ACTEL A128oxc pq16oc, square smd          (Speedup)
        A42MX09          ACTEL A42MX09, PLCC84                     (A51site4)
        A42MX16          ACTEL A42MX16 FPGA, QFP160                (Pasha2)

        EMP7064LC68    FPGA,  A-20259 Custom Chip                  (Nbahangt, MK3, Wwfmania)

        HP FPGA 1FY5-0003 9351-HONG KONG NPFY5B5880                (MetalManiax)

        Playmark
        010412         FPGA Playmark 010412                        (Sderby)
        018969         Playmark 018969                             (RoulettePlaymark)
        018970         Playmark 018970                             (RoulettePlaymark)


        XILINX
        XC3020         XILINX XC3020A                              (Kdeadeye)
        XC3030         XILINX (PLCC84), ATT3030-70M84              (Sexyboom, Stonebal)
        XC3042         XILINX XC3042-70, xc3042A                   (Eggventr, Touchmaster3000/4000)
        XC3130         XILINX (TQFP100)                            (Skullfng, Avengrgs)
        XC3142         XILINX FPGA XC3142-3 TQ144C X25839M AIG9326 (MetalManiax)
        XC3190         XILINX FPGA XC3190-3 PQ160C X35728M AIG942  (MetalManiax)
        XC4003         XILINX FPGA CX4003-6 PQ100C X25788M ASG9325 (MetalManiax)
        XC5210         XILINX PQ240C X68710M AKJ9544               (Tetrisp2)
        XCS05          XILINX Spartan XCS05 FPGA   (QFP100)        (X-Files, Kdynastg)
        XCS10          XILINX Spartan XCS10 FPGA   (QFP144)        (Ppcar)
        XCS10XL        XILINX (FPGA, QFP100, Konami no. 4C)        (Sscope2)
        XCS236A        XILINX XCZ236A-25                           (Cheesech)


P19.5   Other

        Altera
        EP1810LC20T    EPLD (Primrage. SF2, T-mek)
        EP610PC        Altera EP610PC-35 (Smashtv)
        EP910PC        Altera EP 910PC-40 (Raiden, Smashtv)

        Intel
        N5C090-60 simple PLD (PLCC44), 100% compatible with Altera EP900
        P5C060     16 Macrocell CMOS PLD, One-Time-Programmable Logic Device, 26MHz fMAX (Mk)

        Quicklogic
        QL2003-XPL84C 0003BA  PLD (PLCC84)            1945iii, 3in1semi, Pclubys, Ssfindo, Suplup, Vamphalf
        QL2007-XPQ208C                                Bcstry, Semibase
        QL12X16B-XPL84C                               Pclubys, Searchey




 


INPUT/OUTPUT

  1.    I/O chips

  2.    RIOT (RAM & I/O Timer)
  2.1   6532
  2.2   8155
  2.3   8156

  3.    Interrupt controller
  3.1   8259
  3.2   71059

  4.    UART (Universal Asynchronous Receiver and Transmitter)
  4.1   8212
  4.2   8251
  4.3   MB89371
  4.4   NEC
  4.41  7001
  4.42  71051
  4.5   DUART
  4.51  16552
  4.52  68681

  5.    DMA controller
  5.1   MC6844
  5.2   uPD8257
  5.3   MB89237

  6.    Interfaces
  6.1   PIA (Peripheral Interface Adapter)
  6.11  6821
  6.2   PPI (Parallel Peripheral Interface)
  6.21  8255
  6.3   VIA (Versatile Interface Adapter)
  6.31  6522
  6.4   CIA (Complex Interface Adapter)
  6.41  6526
  6.42  8510
  6.43  8520
  6.44  8530
  6.5   RS232
  6.51  6850
  6.52  DS232
  6.53  DS1228
  6.54  ICL232CPE
  6.6   Other
  6.61  RP5H01
  6.62  2651
  6.63  UM82C11
  6.64  SN75452
  6.65  MC68901
  6.66  MC88916
  6.67  8243
  6.68  8250
  6.69  8279
  6.6A  AM2950
  6.6B  QS32X384
  6.6C  IC2 Bus

  7.    I/O Controller
  7.1   Toshiba 82265
  7.2   Toshiba 8740
  7.3   SMC FDC37C932
  7.4   TE7750

  8.    Input/Coins/Leds
  8.1   Analog Digital Converter (ADC)
  8.2   PC3092
  8.3   Super Sound I/O
  8.31  Flasher
  8.32  Lamp Sequencer
  8.33  Lamp Driver
  8.4   Trackball/Spinner/Mouse/Pedal
  8.41  TC4584
  8.42  D4701
  8.43  Analog pedal
  8.5   On-Screen Display (OSD)
  8.6   TV Frequency Synthesizer
  8.7   Touchscreen
  8.71  MicroTouch Systems
  8.72  Touchmaster
  8.8   PC-AT Keyboard

  9.    Controller
  9.1   Floppy Disk
  9.11  MB89311
  9.12  8272
  9.12  MB4107
  9.2   IDE
  9.21  EIDE
  9.3   SCSI
  9.31  53CF96
  9.32  53C810
  9.4   PCI
  9.41  MPC105
  9.42  MPC106
  9.43  GT64010
  9.5   USB
  9.6   PCMCIA
  9.7   Network
  9.71  91C94
  9.72  20020
  9.73  66220
  9.74  LAN
  9.75  Data Link

 10.    Transceiver
 10.1   Analog Devices
 10.11  ADM485
 10.12  ADM619
 10.13  ADM708
 10.2   SP485
 10.3   HYC2485
 10.4   DS8921
 10.5   SN75179

 11.    Optocoupler
 11.1   Sharp
 11.11  PC900
 11.12  PC910

 12.    Cassette / Cartridge / Floppy / Harddisk / CD / Laser Disc
 12.1   Cassette System
 12.11  DECO Cassette System
 12.12  Multi Amenity Cassette System (MACS)
 12.2   Cartridge
 12.21  Max-A-Flex
 12.22  PlayChoice-10
 12.23  Sega MegaTech
 12.24  Sega MegaPlay
 12.25  SNK NeoGeo
 12.26  Nintendo Super System (NSS)
 12.3   Floppy Disk
 12.4   Harddisk images / CHD (Compressed Hunks of Data)
 12.5   CD ROM
 12.6   Laser Disc

 13.    Motherboard chipset
 13.1   I750

 14.    Connectors

 15.    PC hardware

.................................................................................................................................................................................................................................


I1.    I/O chips

- 15th March     2004: Charles MacDonald added I/O chip and partial VDP emulation for shdancer, shdancrj, shdancbl, shdancrb, moonwlkb and astormbl.
- 0.78u4             : Nicola Salmoria implements the 56XX and 58XX I/O custom chips (machine/namcoio.c) used by all the games. The I/O chips are now accurately simulated, fixing subtle nuances during normal operation and not-so-subtle ones in test mode; e.g. you can now scroll the grid in Mappy's test mode.
- 29th May       2001: David Graves streamlined the I/O handling in most of the Taito 68k based games
- 28th June      1999: Manuel Abadia fixed the custom IO chip reset bugs in Mappy driver.
- 28th March     1999: Ernesto Corvi sent in a new Gaplus driver with preliminary Galaga 3 (clone) support added (not working because of a different custom I/O chip).
- 0.30               : Better emulation of the custom I/O chip in the Namco games.
- 0.21               : Support for GALAGA. Special thanks to Martin Scragg that provided us crucial information on custom I/O chips.
- 0.20               : Source: 8910_sh_update() doesn't emulate the 8910 audio if sound is disabled (the I/O ports of the chip are still emulated, since some games use them for input).



I2.    RIOT (RAM & I/O Timer)

I2.1   6532
- 0.117u2            : Wilbert Pol updated the 6532 riot interface to be more like the 6522via and 6821pia interfaces.
- 0.117              : Wilbert Pol changed the 6532riot code to split r6532_init into r6532_init and r6532_reset.
- 0.116u4            : Wilbert Pol improved the 6532riot timer implementation. Implemented irq callback support.
- 0.111u2            : Nathan Woods changed 6532riot code to only allow initialization at init time.
- 0.82u2             : Judge added a 6532 RIOT patch (fixes some things in MESS).
- 0.78u5             : Nicola Salmoria rewroted machine\6532riot.c. This fixed the gfx problems and bad sound in the Gameplan driver, video\gameplan.c is no longer needed; machine\6532riot: added PA7 adge detect and irq callback.
- 0.68               : Added machine\6532riot.c.
- NOTES: Game 'Star Wars' stored sound commands from the main CPU in the 6532 port A data register and the 6532 port B data register is interfaced to the TMS5220 data bus (see audio\starwars.c).
- GAMES: Victory (Exidy 1982), Star Wars (Atari 1983)
- SOURCE: emu\machine\6532riot.c
- PCB: R6532P (Qbert, Mtrap), SY6532A (Mplanets)


I2.2   8155
- NOTES: The 8155 is also a RIOT, but it has not an extra source code in MAME like the 6532 RIOT.
- PCB: TMP8155 (Equites), M5L8155P (Splndrbt), NEC D8155HC (Hvoltage, Paranoia), 8155 (Bullfgtr)

I2.3   8156
- NOTES: The interrupt in Space Bugger is generated by 8156 - very old combination chip containing 256*8 RAM (used as stack area), a timer and 8+8+6 ports. After game start all 8156 ports are set as inputs, timer is working in mode 3 - automatic reload. TC register is set to 0x7f. Timer input frequency is unknown. Output should be close to 1440 Hz.
- SOURCE: drivers\sbugger.c
- GAMES: Space Bugger (Game-A-Tron 1981)
- PCB: TMP8156 RIOT, 2048-Bit/256 x 8 Static MOS RAM with I/O Ports and Timer (Sbugger)



I3.    Interrupt controller

I3.1   8259
- 0.124u5            : Miodrag Milanovic added support for 8080/85 mode interrupts to the 8259 PIC.
- 0.124u3            : Wilbert Pol changed the PIC8259 implementation into a device.
- 0.101u2            : Added machine\pic8259.c.
- NOTES: Unicorn Microelectronics UM8259A Programmable Interrupt Controller
- SOURCE: emu\machine\pic8259.c
- PCB: 8259 (Mrflea)

I3.2   71059
- NOTES: NEC D71059C interrupt controller - 8259 compatible
- PCB: NEC D71059C (Dsoccr94, Inthunt, Gunforce), (Rtypeleo)

      



I4.    UART (Universal Asynchronous Receiver and Transmitter)

I4.1   8212
- SOURCE: drivers\spacefb.c - Communicates to the Sound card (via 8212 latch)
- PCB: 8 bits gets "sent" to a 8212 chip (Spacefb), INS/DP8212N P8212, DIP 24 (Malzak, Rjammer), ICL8212CPA 8049SI (Unknown TMS9980 board), 8049 (Stratof)

I4.2   8251
- NOTES: Toshiba 82C51AM-10 Programmable 8-bit I/O Serial Interface, SOP28 (Model1)
- SOURCE: drivers\gladiatr.c  - 8251 (Debug port ?)
- PCB: 8251 (Mmpanic, PPKing), 8251A (Fortecar), i8251A USART (Turbosub), 82C51 (Model1)

I4.3   MB89371
- SOURCE: drivers\konamigq.c + konamigv.c (UART)
- GAMES: Crypt Killer (Konami 1995)

I4.4   NEC

I4.41  7001
- SOURCE: drivers\ssv.c - uPD7001C (UART)
- PCB: uPD7001C (Sxyreact)

I4.42  71051
- SOURCE: drivers\ssv.c - uPD71051 (UART)
- PCB: NEC uPD71051C Serial Control Unit, DIP28 (CPS2), NEC D71051 (Janjans2), D71051GU (SegaModel3, Bel, Scud), uPD71051 (Mslider), NEC D71051 (Harley)


I4.5   DUART

I4.51  16552
- 0.110u5            : Added PC16552D DUART emulation [Ville Linde].
- NOTES: National Semiconductor PC16552D Dual Universal Asynchronous Receiver/Transmitter with FIFOs
- GAMES: Konami FireBeat System
- SOURCE: emu\machine\pc16552d.c

I4.52  68681
- 0.124u4            : Added machine\68681.c\h. Mariusz Wojcieszek added preliminary 68681 DUART (machine\68681.c).
- SOURCE: drivers\micro3d.c, audio\taito_en.c
- PCB: Signetics SCN68681C1N40 Dual Asynchronous Receiver/transmitter (Skattv, Tm3k, Tm4k), MC68681 (Groundfx, Scfinals), MC68681P (UART) (F15se),



I5.    DMA controller

I5.1   MC6844
- NOTES: The MC6844 is a DMA controller
- SOURCE: audio\exidy440.c
- GAMES: 6844 Showdown (1988) - Exidy System 440
- PCB: MC6844P-CM88708 (Cheyenne)

I5.2   uPD8257
- 0.121u3            : Couriersud hooked up and written 8257 DMA controller. All dkong, dkongjr based, Epos and 2650 based games now use the 8257.
- SOURCE: emu\machine\8257dma.c
- PCB: upD8257C NEC DMA Controller (Shootgal)

I5.3   8237
- 0.124u2            : Wilbert Pol changed the 8237DMA implementation into a device.
- GAMES: mediagx.c + taitowlf.c
- SOURCE: emu\machine\8237dma.c
- PCB: Intel8237A functionally compatible (Radr), Fujitsu MB89237A  DMA Controller, 




I6.    Interfaces


I6.1   PIA (Peripheral Interface Adapter)

I6.11  6821

- 0.124u3            : Aaron Giles removed word-sized handlers from 6821pia.c. Updated drivers that needed them to use these new interfaces instead.
- 0.122u6            : 6821 PIA changes [Zsolt Vasvari]: Added orthogonal accessors. Removed hacky update_shared_irq_handler(), now the same IRQ callback maybe called multiple times, but this shouldn't be a problem. IRQ lines are cleared on a reset.
- 0.120              : Tim Lindner changed 6821 PIA logging so that it only logs core messages once.
- 0.115u3            : Zsolt Vasvari updated PIA interfaces to support masks for port A/B inputs. This allows proper behavior of unconnected pins, according to the specs. Updated a number of games to use the new interfaces. Zsolt Vasvari fixed subtle behavior in handling of PIA port A. This allows for the removal of hacks in the Qix driver and the Williams driver. Zsolt Vasvari fixed PIA numbers in revamped Spiders driver.
- 0.115u2            : Zsolt Vasvari removed the addressing order parameter from pia_config() and replaced it with dedicated write and read handlers.
- 0.111u5            : Nathan Woods added an assertion to prevent usage of pia_set_input_[a|b]() when input reading callbacks are specified.
- 0.106u10           : Nathan Woods fixed 6821 PIA addressing regression in the Atari machine driver (machine\atari.c).
- 0.105u2            : Nathan Woods did some cleanup on the 6821 PIA functions, converting to new MAME struct conventions and enforcing that configuration/initialization happens only at init time.
- 0.105u1            : Nathan Woods added accessors for the CA2, CB2 and IRQ signals on the 6821 PIA.
- 0.104u6            : Nathan Woods added accessors to return output values for the 6821 PIA.
- 0.100u4            : Aaron Giles cleaned up 6821 PIA initialization and save state registration.
- 0.95u2             : Nathan Woods fixed 6821 PIA emulation.
-  8th August    2003: Martin Adrian fixed the behavior of the 6821 PIA when reading disconnected pins.
-  2nd May       2003: Nathan Woods updated the 6821 PIA init function to support save states.
- 29th April     2001: Nathan Woods added state saving support for the 6821 PIA chip.
- 26th September 2000: Aaron Giles modified the 6821 PIA emulation to work properly with the new memory interface.
- 0.36b6             : Aaron Giles changed the 6821 PIA interface.
- NOTES: The Motorola 6821 PIA is a Peripheral Interface Adapter for sound/coin-switch/player control devices.
- GAMES: Taito - Qix (1981), The Electric Yo-Yo (1981), Zoo Keeper (1982)
- SOURCE: emu\machine\6821pia.c
- PCB: Mototola 6821 PIA (Qix), MC68A21 (Spiders), MC68B21CP (Royalcrd, Strkforc), MC6821P (Magiccrd), HD6821 (BigBoy, R2dtank), HD46821P (Spiders), hd46821p (Tugboat), EF6821P (Monglfir), EF68B21P (Soccernw)



I6.2   PPI (Parallel Peripheral Interface)

I6.21  8255

- 0.124u4            : Wilbert Pol converted the PPI8255 implementation to a device. 
- 0.104u2            : Nathan Woods did miscellaneous cleanups to the 8255 PPI code. Changed some 'int' types to 'offs_t' and 'UINT8'. Added ppi8255_get_portA/B/C() functions. Also fixed some formatting problems.
- 0.101              : Aaron Giles added save state support to the 8255 PPI.
- 0.96u2             : Nathan Woods rewrote 8255 PPI mode 2 support, and hooked 8255 to Buck Rogers properly.
- 0.95u3             : Nathan Woods merged in 8255 PPI mode 2 functionality.
- NOTES: The 8255 is a parallel peripheral interface. It has three 8-bit outputs. Zaxxon's discrete circuits is triggered by an output pin of the 8255. There are four registers in the 8255. They are mapped to (111x xxxx 0011 11pp) by Zaxxon. Zaxxon writes to these at FF3C-FF3F. There are three modes of the 8255, but by the schematics I can see that Zaxxon is using "Mode 0", which is very simple.
- GAMES: Scramble (Konami 1981), Zaxxon (Sega 1982), Rescue (Stern 1982)
- SOURCE: emu\machine\8255ppi.c
- PCB: 8255A (Rescue), D8255 (Buckrog), NEC D8255AC-2  DIP40 (Bodyslam, Pipeline), uPD8255AC-2 (Hangonjr), UM82C55A-PC (Sfkick), M5M82C255ASP (Countrun), M5L8255AP-5 (Triplep), TMP8255AP-5 (Taxidrvr), Intel P8255A (Dribling, Dealer), EC 8255AC (RoundUp), AMD AM8255APC (Quiz211)




I6.3   VIA (Versatile Interface Adapter)

I6.31  6522

- 0.122u4            : Changed 6522 emulation such that when writing to the ACR register with the timer 1 in continuous counting mode, the timer 1 value should not be reloaded but keep on counting [Wilbert Pol].
- 0.97u2             : Mathis Rosenhauer fixed the way the VIA 6522 shift register was implemented to get rid of the previous hacky way.
- 0.78u5             : Nicola Salmoria rewroted machine\6522via.c. This fixed the gfx problems and bad sound in the Gameplan driver, video\gameplan.c is no longer needed; machine\6522via: fixed port writes so that pins set as input are pulled high. This is required by the gameplan games and is confirmed by the 65422 data sheet. Added support for CA2 pulse handshake.
- 0.77u1             : 6522 VIA fixes and updates from MESS [Nathan Woods].
-  3rd May       2002: Zsolt Vasvari cleaned up the Leprechaun / Pot of Gold drivers and added proper VIA 6522 chip emulation.
- 0.37b8             : Added machine\6522via.c/h.
- NOTES: The Rockwell 6522 VIA is a versatile interface adapter. The 6522 emulation based on MAME's M6821. The Atari System 1 hardware use a SY6522A for communication to the TMS5220.
- SOURCE: emu\machine\6522via.c
- DRIVERS: atarisy1.c, beezer.c, bmcbowl.c, gameplan.c, itech8/32.c and leprechn.c
- GAMES: Kaos (GamePlan 1981), Beezer (Tong Electronic 1983), all itech8 and 32 games.
- PCB: Rockwell R6522 (Timekill), Synertek SY6522A VIA (Bmcbowl), UM6522A 8926S (Pntnpuzl)



I6.4   CIA (Complex Interface Adapter)

I6.41  6526
- 0.117              : Pete Rittwage reverted patch to the 6526CIA as it was causing issues with Amiga/Arcadia emulation.
- 0.115u3            : Pete Rittwage fixed bit calculation in 6526cia.c which broke joysticks in the MESS C64 driver.
- 0.111u4            : Ernesto Corvi fixed system time counters in the Amiga code.
- 0.111u2            : Amiga core system updates [Ernesto Corvi]: Updated 6526/8520 CIA to be able to set the value of the SP pin. This is needed to emulate the Amiga keyboard. Fixed a bug on the 6526/8520 CIA that prevented chained counters from working.
- 0.111u1            : Ernesto Corvi reimplemented one-shot timer modes in the 6526 CIA (Amiga) emulation.
- 0.109u2            : Nathan Woods improved timer accuracy and added save state support to the 6526 CIA module.
- 0.107u2            : Nathan Woods implemented CNT pin and some serial features of the 6526 CIA chip.
- 0.105u3            : Nathan Woods refactored the 8530 CIA code from the Amiga into a separate module and made it support both the 6526 and 8530 variants.
- SOURCE: emu\machine\6526cia.c + machine\amiga.c
- PCB: CIA 6526 (Attckufo)

I6.42  8510
- NOTES: Amiga CIA
- GAMES: Moonquake (Sente 1987)

I6.43  8520
- 0.111u2            : Amiga core system updates [Ernesto Corvi]: Updated 6526/8520 CIA to be able to set the value of the SP pin. This is needed to emulate the Amiga keyboard. Fixed a bug on the 6526/8520 CIA that prevented chained counters from working.
- SOURCE: machine\6526cia.c + machine\amiga.c

I6.44  8530
- 0.105u3            : Nathan Woods refactored the 8530 CIA code from the Amiga into a separate module and made it support both the 6526 and 8530 variants.




I6.5   RS232

I6.51  6850

- 0.124u1            : James Wallace added dynamic control of RX and TX pins to 6850 ACIA emulation - this is needed for correct operation of the MPU4 Video communications system, and may be handy for some MESS systems. To use, set the rx and tx clocks to 0 in the acia interface, then use acia_tx_clock_in() and acia_rx_clock_in() respectively.
- 0.123u4            : Kingshriek improved (not perfect) ACIA slot monitoring.
- 0.123u3            : Some improvements to the 6850 ACIA CTS pin checking logic and the MPU4 ACIA clock logic [James Wallace].
- 0.123u2            : James Wallace changed the 6850 core to allow dynamic RX and TX clock alteration, to at least try to remove a few of the MPU4 timing problems.
- 0.120u2            : Rewrote ACIA6850 implementation [Curt Coder].
- 0.118u1            : Curt Coder changed 6850ACIA to use MSB/LSB read handlers.
- 0.114u2            : MPU4 improvements [James Wallace]: Decommissioned machine/mpu4.c, as the 6850acia code from Phil does the same job, making one less thing to maintain.
- 0.113              : Added machine\6850acia.c.
- 0.108u3            : Removed machine\6850acia.c. Big update to the MPU4 driver [El Condor]: Added support for reverse clocking in the VFD code. Changed the 6840 to not run the counter clock if no frequency is specified. Reworked the MPU4 drastically to be more in sync with AGEMAME. MPU4 video should now be working a little better. Deprecated machine\6850acia.c, replacing it with a specialized driver (machine\mpu4.c).
- 0.103u2            : Added machine\6850acia.c.
- NOTES: The MC6850 is a RS232 communications interface. The 25-way RS232 D-type in Qix (1981) is layed out but not fitted.
- Games: Qix (Taito 1981), Tail to Nose (V-System 1989), Begas Battle (DataEast 1983)
- SOURCE: emu\machine\6850acia.c
- PCB: 6850 (Qix), MC68B50P (F1gp, Gstriker, Tail2nos), EF68B50P (BegasBattle), M6850 UART I/O to sound board (machine\balsente.c), 6850 ACIA (Memory map of Qix and Zookeep), 6850 serial IO (MPU4VideoSystem)


I6.52  DS232
- PCB: DS232AS serial port chip (Blitz99), 232ACBN (Gauntdl)

I6.53  DS1228
- NOTES: DALLAS DS1228  RS232 communications interface
- PCB: DS1228 (RS232 port for debug) (F15se)

I6.54  ICL232CPE
- PCB: ICL232CPE  RS232 port for communication to Host PCB (Botss, F15se)




I6.6   Other

I6.61  RP5H01
- GAMES: Playchoice 10, Nintendo VS-System RP5H01 interface
- SOURCE: emu\machine\RP5H01.c

I6.62  2651
- PCB: Signetics SCN2651CC1N28 communications interface (Botss, F15se)

I6.63  UM82C11
- PCB: UMC 8935CS-UM82C11 Printer Adapter Interface (Filetto)

I6.64  SN75452
- PCB: Texas Instruments SN75452 (Shuttlei) - Dual Peripheral Drivers (SN75451 - SN75454)

I6.65  MC68901
- SOURCE: drivers\micro3d.c
- PCB: Motorola MC68901P Interface, Multi-Function Peripheral (F15se, Botss)

I6.66  MC88916
- PCB: Motorola MC88916 Multifunction Peripheral Interface, SOIC20 (GTIClub)

I6.67  8243
- PCB: NEC D8243C, DIP24 (BodySlam, Sega-System16a)

I6.68  8250
- PCB: 8250 (Rocnrope), UMC 8936CS-UM8250B Programmable asynchronous communications element (Filetto)

I6.69  8279
- 0.108u2: Aaron Giles added a more complete 8279 implementation.
- NOTES: Display/keyboard driver
- SOURCE: drivers\turbo.c
- PCB: D8279 (Buckrog, Turbo), P8279 (Turbo)

I6.6A  AM2950
- NOTES: The AMD AM2950DC is a I/O port to the sound processor.
- PCB: BegasBattle (DataEast 1983)

I6.6B  QS32X384
- PCB: QuickSwitch Products QS32X384 High-Speed CMOS 20-Bit Bus Switch (Mtetrisc)

I6.6C  IC2 Bus
- 0.120u2: Added machine\i2cmem.c. smf added generic I2C bus memory support. Hooked up to the cubocd32 driver.
- PCB: Skattv
- SOURCE: machine\i2cmem.c



I7.    I/O Controller

I7.1   Toshiba 82265
- NOTES: I/O Custom chip
- SOURCE: taifo_f2
- PCB: TMP82C265BF: Growl (Taito 1990), Quiz-HQ (Taito 1990), Solitary Fighter (Taito)

I7.2   Toshiba 8740
- PCB: TOSHIBA TMP87CH40N-4828 I/O controller, SDIP64 (NeoGeoHyper64)

I7.3   SMC FDC37C932
- PCB: SMC FDC37C932APM, QFP160 (A51site4) - Plug and play compatiable ultra I/O Controller with software mangment from Standard Microsystems  

I7.4   TE7750
- SOURCE: drivers\taito_f2.c - I/O chip for footchmp and ninjak
- PCB: TE7750 (Ninjak)





I8.    Input/Coins/Leds


I8.1   Analog Digital Converter (ADC)

- 0.114u2            : Ville Linde added ADC1213x A/D converter emulation (machine\adc1213x).
- 0.96u1             : smf fixed ADC overflow condition in ADC083x code.
- 0.95u3             : Added machine\adc083x.c. Cycle accurate emulation of ADC0831/ADC0832/ADC0834/ADC0838 serial analogue to digital converters [smf].
- NOTES: 8-Bit Serial I/O A/D Converters with Muliplexer Options (ADC0831/ADC0832/ADC0834/ADC0838)
- PCB: Gun games need an ADC to interpret the movement of the players gun.
- SOURCE: emu\machine\adc083x.c + emu\machine\adc1213x.c


       ADC0804         DIP20                              (Dday, Armchmp2, SuperMonacoGP)
       ADC0808         ADC0808CCN, S9530AG-ADC0808-CCV    (LockLoad, Backfire)           NOTES: A/D converter for lightgun (Othunder)
       ADC0809         ADC0809CCN                         (Superchs, Groundfx, Opwolf3)  NOTES: The ADC0809CCN is a 8-bit ADC with 8-way mux or 8-bit Microprocessor Compatible A/D Converter with 8-Channel Multiplexer (DataSheet at http://www.national.com/ds/AD/ADC0808.pdf).
       ADC0834                                            (Racin' Force)                 NOTES: National Semi ADC0834 steering wheel
       ADC0844                                            (Max RPM)                      SOURCE: drivers\mcr3.c
       ADC0848     NSC ADC0848CCN                         (Gauntleg)
       ADC12138    NSC ADC12138                           (Gradius4, Konami-HornetSys)   NOTES: 12-bit + serial I/O ADC with MUX, self calibrating

       AD558           AD558JN                            (Showdown)
       AD813           AD 813AR, SOIC14                   (A51site4, 11beat, Mtetrisc)
       AD7582          AD7582KN                           (MetalManiax)                  NOTES: 12-bit ADC

       TLC549    Texas Instruments TLC549 8-BIT Analog-to-Digital Converter with serial control, compatible to TLC540-545-1540 (Surfplnt)


I8.2   PC3092
- NOTES: Chip for coin inputs and start buttons.
- SOURCE: drivers\crbaloon.c



I8.3   Super Sound I/O
- 0.122u6            : Aaron Giles added clocks to the MCR sound boards and some of the MCR games. Added TMS5220 variants TMS5200 and TMC0285 as proper chips. Changed MCR squawk & talk to use the TMS5200 as documented.
- 0.117u2            : Ernesto Corvi fixed incorrect implementation of SSIO volume controls in the MCR driver. This makes the engine sound in Spy Hunter audible again, among other things.
- 0.98u1             : Aaron Giles did some major cleanup on the MCR drivers: Implemented Super Sound I/O interrupts properly, filled out all memory maps according to schematics, fixed sound sync with various sound boards, allowing for kludges to be removed from Power Drive and Star Guards, re-verified all connections from wiring diagrams and documented various lamp and driver boards from the games.
- NOTES: SSIO or Super Sound I/O boards can you find in MCR1/2/3 games.
- SOURCE: drivers\mcr.c

    ====================================================
    CPU #2 (Super Sound I/O)
    ====================================================
    0000-3FFF   R     xxxxxxxx    Program ROM
    8000-83FF   R/W   xxxxxxxx    Program RAM
    9000-9003   R     xxxxxxxx    Audio latches 1-4
    A000          W   xxxxxxxx    AY-8910 #1 control
    A001        R     xxxxxxxx    AY-8910 #1 status
    A002          W   xxxxxxxx    AY-8910 #1 data
    B000          W   xxxxxxxx    AY-8910 #2 control
    B001        R     xxxxxxxx    AY-8910 #2 status
    B002          W   xxxxxxxx    AY-8910 #2 data
    C000          W   xxxxxxxx    Audio status
    E000          W   xxxxxxxx    Unknown
    F000        R     xxxxxxxx    Audio board switches
    ====================================================


I8.31  Flasher
- NOTES: For the 'Flasher Control' in Discs of Tron is a 555 timer set up in astable mode with R1=R2=56k and C=1uF giving a frequency of 8.5714 Hz. The timer is enabled if J1-3 is high (1). The output of the timer is connected to the input of a D-type flip flop at 1A, which is clocked by the AC sync (since this is a fluorescent light fixture). The J1-4 input is also connected the input of another D-type flip flop on the same chip at 1A. The output of this directly controls the light fixture. Thus: J1-3 enables a strobe effect at 8.5714 Hz (77.616ms high, 38.808ms low) and J1-4 directly enables/disables the lamp. The two outputs are wire-ored together.
- SOURCE: drivers\mcr3.c

I8.32  Lamp Sequencer
- NOTES: For the 'Lamp Sequencer' in Discs of Tron is a 556 timer set up in astable mode with two different frequencies, one using R1=R2=10k and C=10uF giving a frequency of 4.8 Hz, and the second using R1=R2=5.1k and C=10uF giving a frequency of 9.4118 Hz. The outputs of these clocks go into a mux at U4, whose input is selected by the input bit latched from J1-6. The output of the mux clocks a 16-bit binary counter at U3. The output of the binary counter becomes the low 4 address bits of the 82S123 PROM at U2. The upper address bit comes from the input bit latched from J1-5. Each of the 5 output bits from the 82S123 is inverted and connected to one of the lamps. The /CE pin on the 82S123 is connected to the input bit latched from J1-4. Thus: J1-4 enables (0) or disables (1) the lamp sequencing, J1-5 selects one of two 16-entry sequences stored in the 82S123 and J1-6 selects one of two speeds (0=4.8 Hz, 1=9.4118 Hz).
- SOURCE: drivers\mcr3.c

I8.33  Lamp Driver
- NOTES: For the 'Lamp Driver' in Spy Hunter is a 3-to-8 latching demuxer connected to the input bits. Three of the inputs (J1-11,10,12) specify which output to write to, and the fourth input (J1-14) is the data value. A fifth input (J1-13) controls the strobe to latch the data value for the demuxer. The eight outputs directly control 8 lamps.
- SOURCE: machine\lamps.c



I8.4   Trackball/Spinner/Mouse/Pedal

I8.41  TC4584
- NOTES: The TC4584 is used for trackball/spinner control.
- PCB: TC4584 (Fitegolf), 4584 CMOS (GigasMark3)

I8.42  D4701
- 0.110u2: smf added uPD4701 emulation to Konami System 573.
- NOTES: Mouse/Trackball interface by NEC
- GAMES: Forgotten Worlds (Capcom 1988), Caliber 50 (Seta 1989), EagleShotGolf (Sammy 1994), Backfire (Data East 1995)
- SOURCE: emu\machine\upd4701.c
- PCB: NEC D4701AC (EagleShot), NEC4701 (Krzybowl), uPD4701c

I8.43  Analog pedal
-  8th September 1999: Aaron Giles added better analog pedal support for APB (Atari 1987) and other Atari System 1/2 games.
- SOURCE: drivers\atarisy2.c



I8.5   On-Screen Display (OSD)
- PCB: Mitsubishi M50458-001SP On-Screen Display Chip (NDIP32) (NintendoSuperSystem)


I8.6   TV Frequency Synthesizer
- PCB: Toshiba TD6358N Frequency Synthesizer for TV/CATV, SOIC8 (NamcoSystem12)


I8.7   Touchscreen

I8.71  MicroTouch Systems
- 0.124u4: Added machine\microtch.c\h. Mariusz Wojcieszek moved Microtouch touch screen controller emulation to separate module (machine\microtch.c).
- NOTES: Paint & Puzzle is a touch screen game from MicroTouch Systems.
- PCB: ICS1578N 9334  19-507 Rev 2  (c) 1992 (28pin) and IC Intel MicroTouch 5603670 REV 1.0  L3372718E P8798 (Pntnpuzl)

I8.72  Touchmaster
- PCB: Touchscreen games Touchmaster 3000 and 4000



8.8   PC-AT Keyboard
- 0.124u2            : Wilbert Pol removed the hardcoded dependency on a 8254 device from the 8042kbdc code. Changed the drivers using the 8042kdbc to define their own 8042kdbc - 8254 dependency.
- 0.117u2            : Nathan Woods fixed up pckeybrd.c to work with new timing code.
- 0.101u2            : Added machine\pckeybrd.c
- SOURCE: emu\machine\8042kbdc.c
- GAMES: mediagx.c + taitowlf.c



I9.    Controller


I9.1   Floppy Disk

I9.11  MB89311
- PCB: Fujitsu MB89311 CMOS Floppy Disk Controller / Formatter (Sega System24)

I9.12  8272
- PCB: UMC 8928LP-UM8272A floppy disk controller (Filetto)

I9.12  MB4107
- PCB: Fujitsu MB4107AP Disk-Tape Support Circuit, Floppy Disk Vari-Freq Osc (VFO) (Sega System24)


I9.2   IDE

- 0.124u3            : Aaron Giles converted the IDE controller to a device. Updated all drivers accordingly.
- 0.79u2             : Nathan Woods added ide_bus_0_r() call to access the bus directly.
-  9th February  2004: Nathan Woods sent in miscellaneous fixes to the IDE controller emulation.
- 0.78               : Aaron Giles fixed IDE controller final sector handling for Gauntlet: Dark Legacy and added new PIC mapping.
- 0.77u3             : Aaron Giles made sure the IDE controller in the Seattle games waits a minimum amount of time before generating an interrupt. The IDE controller features buffer is now filled in completely. Also fixed code that reads the bus master status register from a word offset. Nathan Woods added #ifndef <headername>_H protection (harddisk.h + chd.h).
- 0.69a              : Update adding support for a few things needed in the future [Aaron Giles].
- 27th May       2003: Aaron Giles updated the IDE controller emulation to support a couple more commands and added DMA bus mastering support that will be necessary for the Seattle games.
-  8th December  2002: Aaron Giles implemented compressed hard disk extraction and merging in the hdcomp tool, added support for various things in the IDE controller emulation.
- 0.59               : Added machine\idectrl.c.
-  8th March     2002: Aaron Giles added hard disk support and emulation for a standard IDE controller.
- NOTES: IDE = Integrated Drive Electronics 

       IDE Controller:
       83461       VT83C461, QFP100                  (Area51, Maxforce, Primrag2)
       87415       PC87415VCG                        (Blitz99)
- SOURCE: emu\machine\idectrl.c


I9.21  EIDE
- NOTES: EIDE = Enhanced Integrated Drive Electronics 
- PCB: CMDPCI646U2, PC1646U2 CMD EIDE Controller for HDD Quantum Fireball (Gauntleg, Gauntdl)



I9.3   SCSI
- 0.124u2            : R. Belmont reverted previous SCSI CD change which broke some games.
- 0.124u1            : Various SCSI devices register state items by their disk ID, which are not unique across device types. Introduced a device-type offset for CD-ROMs so their registrations don't clash with harddisks [R. Belmont].
- 0.124              : R. Belmont fixed SCSI case when no device exists (e.g. running the sys573 BIOS directly).
- 0.122u2            : Oliver Stoneberg fixed several memory leaks related to SCSI CD emulation.
- 0.120u2            : Added machine\scsi.c, scsidev.c, scsicd.h and machine\cr589.c. smf added support for CR-589 firmware to the System 573 driver. Made substantial changes to the SCSI support, making it require fewer hacks, and allowing one device to be derived from another.
- 0.118u3            : Added machine\wd33c93.c. Ernesto Corvi added a fairly complete WD33C93 SCSI controller emulation, and also updated the cps3.c driver to use it.
- 0.99u3             : SCSI hard disk updates [R. Belmont]: Added FORMAT UNIT, READ (6 byte), WRITE (6 byte), READ (12 byte), MODE SENSE and READ CAPACITY commands, changed INQUIRY to ID as a real Seagate model, which makes MacOS much happier than a manufacturer code of "MAME" and added some MESS-specific tweeks to initialization.
- 0.96u2             : R. Belmont and Ville Linde fixed a number of bugs and added support for more SCSI commands and modes.
- 0.95               : Added machine\scsihd.c.
-  8th January   2004: R. Belmont - Fixed a bunch of bugs all around GV, the SCSI controller, and other bits. Hyper Athlete now has all it's men in MAME and is fully playable, and the corrupted graphics in Wedding Rhapsody are fixed (it's a quiz game). Also figured out the problem with Susume Taisen Puzzle-dama in MAME, and Simpsons Bowling no longer freezes and just needs the trackballs hooked up to be fully playable.
- NOTES: SCSI = Small Computer System Interface
- SOURCE: emu\machine\scsihd.c + emu\machine\wd33c93.c

       SCSI Controller:
       AMD 33C93A,  PLCC44 (CPS3)           


I9.31  53CF96

- 0.95               : R. Belmont changed konamigv and konamigq drivers to support the new 53cf96 configuration system. AM53cf96.c is now fully configurable: you can have any combination of up to 7 CD-ROMs and/or harddisks attached to the emulated SCSI bus and specify what each one's SCSI ID is. CD-ROM emulation expanded to support more SCSI commands and bugfix some existing ones. Moved actual CD-ROM and harddisk device emulation out of am53cf96.c to new scsicd.c and scsihd.c files. CD-ROM emulation expanded to support more SCSI commands and bugfix some existing ones.
- 0.80u3             : R. Belmont added preliminary CD-ROM support for CHDMAN. CDROM support for the AM53cf96 SCSI controller.
- 0.78               : Added machine\am53cf96.c. NCR 53CF96-2 SCSI controller emulation [R. Belmont].
- NOTES: AMD/NCR/Symbios 53CF96 SCSI-2 controller. Qlogic FAS-236 and Emulex ESP-236 are equivalents.
- SOURCE: emu\machine\am53cf96.c
- PCB: NCR 53CF96-2 hard drive control IC, QFP100 (CryptKiller)


I9.32  53C810

- 0.102              : Nathan Woods and R. Belmont began adding support for SCRIPTS programs to the 53C810 emulation.
- 0.101u1            : Tomas Karlsson integrated 53C810 into the SCSI framework.
- 0.99u3             : Ville Linde fixed recent LSI53C810 update which caused the Model 3 games to crash.
- 0.97u5             : Nathan Woods abstracted the memory interfaces and improved 53C810 SCSI emulation.
- 0.90u2             : Ville Linde fixed 53c810 SCSI single-stepping mode DMA and added memory moves and DMA callback.
-  3rd January   2005: Ville Linde - Fixed some bugs in the SCSI emulation, and now 3D graphics is also working in Virtua Fighter 3, Sega Bass Fishing, Scud Race and the Step 1.5 versions of Virtua Striker 2 and VS2 '98. There are still a lot of glitches and crashing though.
- 0.89u3             : Ville Linde added preliminary 53c810 SCSI emulation. Lost World now tries to download everything necessary to the Real3D stuff.
- NOTES: LSI Logic LSI53C810A PCI to SCSI I/O Processor
- SOURCE: emu\machine\53c810.c
- PCB: 53C810 (Harley)




I9.4   PCI
- 0.101u2           : Added machine\pci.c
- NOTES: Information on PCI vendors can be found at http://www.pcidatabase.com/
- SOURCE: emu\machine\pci.c


I9.41  MPC105
-             0.89u3: Ville Linde improved the MPC105 emulation. R. Belmont added init for mpc105 bridge (Motorola MPC105 PCI Bridge/Memory Controller - drivers\model3.c)
-  2nd December 2003: Aaron Giles - Well, I finally decided to figure out what the heck was up with California Speed. Turns out there were a few subtle problems in the PCI configuration code when setting up the 3dfx card. With that fixed, I was able to map the proper self-test button, and finally hook up all the controls. Then came some ugly sound synchronization issues. Like Wayne Gretzky's 3D Hockey, this game won't boot unless the sound is working. After some fiddling, I was able to get it to work. Unlike San Francisco Rush, this one starts up and is playable, though there are some obvious color issues (well, not so obvious here, but it is in other screen shots). However, it doesn't last too long until we hit a snag. Much like San Francisco Rush, we get some math errors and the game freaks out. I really hope this doesn't mean I have to add full floating point exception support....
- GAMES: Atari - California Speed, San Francisco Rush and Wayne Gretzky's 3D Hockey.


I9.42  MPC106
- 21st June     2005: Ville Linde - I dug up Supermodel after over a year and ran some test runs with Sega Rally 2. This helped me to find a small bug in the MPC106 emulation. Fixing that small problem had some very nice results. Now both Sega Rally 2 and Star Wars Trilogy are working in MAME!
- NOTES: Motorola MPC106 PCI Bridge/Memory Controller
- SOURCE: drivers\model3.c
- PCB: MOTOROLA  XPC106ARX66CE  MPC106+, BGA304 (Harley)

I9.43  GT64010
- NOTES: Galileo GT64010 PCI Bridge/System Controller.
- SOURCE: drivers\seattle.c



I9.5   USB
- PCB: The Namco System12 system has a USB connector for controls (Aquarush, Ehrgeiz, Mrdrillr). The I/O board in the NAOMI games is connected to the main board with a USB link.


I9.6   PCMCIA
- PCB: Ricoh RF5C296  PCMCIA controller - TQFP144 (Taito GNET-System)



I9.7   Network

I9.71  91C94
- 0.82u2            : Aaron Giles implemented the new SMC91C94 ethernet controller. Only loopback mode supported.
- NOTES: SMC ISA/PCMCIA Ethernet & Modem Controller
- SOURCE: emu\machine\smc91c9x.c
- PCB: SMC91C94QFP (Gauntleg), SMSC LAN91C94 (Gauntdl)

I9.72  20020
- NOTES: Network communmication IC
- PCB: SMC_COM20020I (Sidebs2), SMC COM20020-5ILJ  PLCC28 (NeoGeoHyper64), COM20020 (Groundfx)

I9.73  66220
- PCB: The M66220FP is a 256 x 8bit Mail-Box Inter-MPU data transfer (Raystorm, Taito GNET-System)

I9.74  LAN
- PCB: LAN board Nr. A052967 (Tmek), K9100259A J9100202A LAN INTERFACE BOARD (Dblaxle), Clarn II LAN PCB - local area network board (Spclords), LAN  PCB  GQ931 PWB (Sscope2), uPD72105C  - LAN hookup for multiple machines (Dblaxle, Wgp)

I9.75  Data Link
- PCB: Fujitsu MB89374 Data Link Controller, SDIP42 (Radr, Model1)



I10.    Transceiver

I10.1   Analog Devices

I10.11  ADM485
- PCB: ADM485JR 5V Low Power EIA RS485 transceiver, SOIC8 (Gp500, NamcoSystem12/23)

I10.12  ADM619
- PCB: ADM619AR is a 900MHz RF Transceiver - SOIC16, compatible to AD6190 (Nbajamex)

I10.13  ADM708
- PCB: ADM708AR (Taito GNET-System)


I10.2   SP485
- PCB: Sipex SP485CS is a low power half-duplex RS485 transceiver (Sscope2)

I10.3   HYC2485
- PCB: Hyundai HYC2485S is a SMC ARCNET Media Transceiver - RS485 5Mbps-2.5Mbps (Sscope2)

I10.4   DS8921
- PCB: National DS8921ATM Differential Line Driver (RS422/423) and Receiver Pair, SOIC8 (NamcoSystem12, NamcoSystem23, Gp500)

I10.5   SN75179
- PCB: Texas Instruments SN75179 Differential Driver and Receiver Pair, DIP8 (Model1)



I11.    Optocoupler

I11.1   Sharp

I11.11  PC900
- PCB: Sharp PC900 Digital Output Type OPIC Photocoupler, DIP6 (Cybsled, Gollygho, Luckywld)

I11.12  PC910
- PCB: Sharp PC910L0NSZ Logic-Gate-Output Optocoupler, High speed 10Mb/s, high CMR type, DIP8 (Cybsled, Gollygho, Luckywld), Sharp PC9D10 (NamcoNA2, NamcoFLSystem, Speedrcr)




I12.    Cassette / Cartridge / Floppy / Harddisk / CD / Laser Disc


I12.1   Cassette System

I12.11  DECO Cassette System

- 23rd July      2001: Dave Haywood resubmitted some DECO Cassette System additions.
-  5th June      2001: David Haywood added some alternative versions of the DECO Cassette system games to the decocass driver.
-  6th March     2001: Juergen Buchmueller fixed some bugs in the state saving functions, added support for them to the DECO Cassette system driver.
- 26th February  2001: Juergen Buchmueller sent in another DECO Cassette system driver update with a few fixes to the graphics.
- 24th February  2001: Juergen Buchmueller sent another DECO Cassette system driver update with a few bugfixes.
- 21st February  2001: Juergen Buchmueller fixed some memory corrupting bugs in the Burger Time and DECO Cassette system drivers.
- 17th February  2001: Juergen Buchmueller managed to get the background tiles partially working in the DECO Cassette system driver, but the graphics are still not perfect.
- 15th February  2001: Juergen Buchmueller sent in another DECO Cassette system update with Explorer and Scrum Try, however they are both still missing some graphics.
- 14th February  2001: Juergen Buchmueller improved the sound CPU communication in the DECO Cassette system driver and added Boulder Dash - the original version.
- 12th February  2001: Juergen Buchmueller sent in an updated DECO Cassette system driver with support for Bump N Jump / Burnin' Rubber, Burger Time, Graplop / Cluster Buster, La.Pa.Pa / Rootin' Tootin', Fighting Ice Hockey, Pro Bowling, Night Star, Pro Soccer and Peter Pepper's Ice Cream Factory, but the games still lack some graphics.
- 11th February  2001: Juergen Buchmueller improved the DECO Cassette system driver even more, now Disco No. 1, Pro Tennis and Tornado are working too.
-  9th February  2001: Juergen Buchmueller sent in the first version of the DECO Cassette system driver, supporting Lock 'n Chase, Treasure Island, Super Astro Fighter, Astro Fantasia, Lucky Poker, Pro Golf and Mission X. The rest are either not yet dumped or use protection that has not been cracked yet.
-  8th February  2001: Juergen Buchmueller managed to fix some 8x41 emulation bugs and got a few DECO Cassette system games running: Super Astro Fighter, Pro Golf and Mission X (the last one with wrong colors though). Accurate to the original, the games need 1 - 2 minutes to load from the simulated tape. Also many thanks to Al Kossow for his incredible work on preserving this system that was near extinction.
- 31st January   2001: Juergen Buchmueller further fixed the i8x41 core and hooked some parts of the DECO cassette system to the Burger Time driver.


I12.12  Multi Amenity Cassette System (MACS)

-  1st May       2004: Tomasz Slanina - Present very preliminary emulation screenshots of Yu-Ka/Yu-Jan and Seimei-Kantei. The MACS system is strange, a cartridge based system and using ST-0016 chip.
- 24th April     2004: David Haywood sent in a preliminary MACS driver which also does not work at all.
- GAMES: I'Max - Kisekae Mahjong, Kisekae Hanafuda, Yubis / T.System - Yu-Ka, Yu-Jan



I12.2   Cartridge

I12.21  Max-A-Flex
-  8th November  2004: Mariusz Wojcieszek - Wrote a driver for the Max-A-Flex system (Atari 600XL). Four titles have appeared on this platform officially only.
- NOTES: The Max-A-Flex system is basically an Atari 600XL computer inside an arcade cabinet, which uses game cartridges. There is additional hardware that controls the length of time that you may play the game. Each time you insert a quarter, an amount of time determined by dip switch settings on the controller board is added. While the timer is running, all controls are active and you can control the game via Start, Select, Option, an 8-way joystick and one button. When the timer gets down to 10 seconds of play remaining, the control board starts beeping a progressivly higher pitched beep and flashing the "insert coin" and "extend play" lights. When the timer gets to zero, the controls become non-functional, but the game does not reset, so you could add more coins and continue playing.
- GAMES: First Star Software - Astro Chase (1982), Bristles (1983), Boulder Dash (1984), Flip and Flop (1983)

I12.22  PlayChoice-10
- SOURCE: drivers\playch10.c

I12.23  Sega MegaTech
- SOURCE: drivers\segac2.c
- PCB: Just 2 ROMs in the cartridge (Goldnaxe)

I12.24  Sega MegaPlay
- SOURCE: drivers\segac2.c
- PCB: (Mp_sonic)

I12.25  SNK NeoGeo
- NOTES: MVS version, MGD-2 and MGD-II format
- SOURCE: drivers\neogeo.c

I12.26  Nintendo Super System (NSS)
- SOURCE: drivers\nss.c
- PCB: (Nss_lwep)




I12.3   Floppy Disk

-  2nd April     2002: Aaron Giles removed a ROM length limitation from the ROM loading system, to better support floppy disk images.
- PCB: Floppy Disks:  Maxell Super RD MF2-256HD (RoughRacer, Qsww)



I12.4   Harddisk images / CHD (Compressed Hunks of Data)

- 0.123u6            : Aaron Giles fixed CHDMAN -extract to a physical drive on Windows.
- 0.118u6            : smf fixed regression that caused CHD games to crash if the CHD was not present. Also fixed change that required write access to CHDs. Aaron Giles fixed CHD search paths again so that they look in parent subdirectories. smf added SCSIOP_GET_INQUIRY_BUFFER to scsicd & scsihd.
- 0.118u5            : Nathan Woods removed CHD interface structure. CHDs now rely on the corefile routines to perform file I/O. Updated the rest of the system to handle this reality. A side-effect is that "split" CHDs, which never got much play, have now been deprecated.
- 0.118u4            : chdman improvements [smf]: Fixed toc parsing to allow spaces and quotes in file names. Supports "offset start length" track syntax that cdrdao creates if you don't read subcode. Tracks are always padded with zeros & not whatever data happens to follow. Moved cdrom_track_input_info out of src/lib/util/cdrom.h and into src/tools/chdcd.h. Added audio byte swapping support.
- 0.118u2            : smf improved fixes to the chdman CD creating code.
- 0.118u1            : smf fixed chdman_open() "w" to always create/truncate the file, leaving "r+" to try opening first and then truncating. This matches behavior in the core.
- 0.117u1            : Roman Scherzer fixed crash in CHD code if reading beyond the end of the file.
- 0.116u4            : smf added support to CHDMAN to cope with toc files created with cue2toc.
- 0.112u2            : Aaron Giles added several new modules to the utility library libutil. First is a generic huffman encoding module. Second is a module that allows you to read/write AVI files in a platform-independent way. And third is a lossless A/V compression module. These three pieces together, plus some changes in the CHD code, allow for the creation of CHDs with compressed audio and video. Added two new commands to chdman: -createav converts an AVI file in uncompressed YUY format or HuffYUV-compressed YUY format with "left" prediction into a CHD. And -extractav converts a CHD containing compressed audio & video into an uncompressed YUY format AVI file.
- 0.111u5            : Aaron Giles changed behavior in chdman so that a 0 sector size means the default.
- 0.111u4            : Aaron Giles simplified the hard disk interfaces a bit. Aaron Giles also added support in chd.c for lossy compressors, computing CRCs and other hashes based on the decompressed output in those cases. Also added support for asynchronous reads/writes using the new osd work item interfaces.
- 0.111u3            : Aaron Giles cleaned up chdman, normalizing its behavior and improving error reporting.
- 0.110u3            : Aaron Giles enhanced chd.c to support hunk sizes up to 16MB, versus the previous 64k limit and added hooks to chd.c to specify codec-specific configuration info. Aaron Giles added support for split CHD files. CHD files can be transparently split into multiple pieces and left that way during read access. Modifications to split files are always written to the last file. A new command chdman -split is now available to split an existing CHD file.
- 0.110u2            : Significant cleanup of chd.c [Aaron Giles]: Got rid of the horrible last_error concept; now all routines return an error directly. Fixed several issues in managing metadata. Changed compression and verification routines to be client-driven rather than monolithic. Changed internal codec usage to be more flexible. Altered chdman and MAME to use the new interfaces. Added new -createraw command for creating raw data CHDs.
- 0.109u5            : smf updated CHD locating behavior to accept CHDs referenced by the parent of a clone if the hash matches, even if it has a different name.
- 0.104u3            : Chris Hardy fixed CHDMAN to write the correct number of logical bytes when extracting something that is not an even number of hunks large.
- 26th January   2006: R. Belmont - As most people understand by now, the ZiNc arcade emulator runs games based on varients of the original 1995 Sony PlayStation hardware. For a variety of reasons (one being just to see what happened), I've done some initial work towards having it also emulate the base home console itself. The 3 major points of difference are the CD-ROM drive's type (custom Sony vs. IDE or SCSI in the arcade boards that used CDs), the memory cards, and the joypads. I hooked up a CD-ROM capability by loading and calling out to an ePSXe-compatible CD plugin and almost immediately started getting some cool things to happen. Here's a few: Silent Hill: Boot warning Title, Wipeout XL: Title In-game, Tekken: Galaga (loading)In-game, Crash Bandicoot: Title, Time Crisis: Title In-game and Madden NFL '97: Main menu In-game. Please note that the final fate and design of this feature are not yet decided, so if you're definitely interested in shaking things up a little in PSX emulation (it's been kinda dead for a while, hasn't it?), voice your support on the official ZiNc forum at bannister.org.
- 0.103u4            : Aaron Giles moved CHD file access routines to fileio.c.
- 0.103u3            : Lawrence Gold added support for >4GB CHD files to CHDMAN for non-Windows systems.
- 0.103              : Lawrence Gold fixed CHDMAN to support 64-bit file sizes on some *nix platforms.
- 24th March     2005: Aaron Giles - Can I use chdman to put a CHD file back onto a hard disk? Yes you can, at least under Windows. You have to be logged in as administrator, and you have to know which physical volume your target hard disk is mapped as. The easiest way to do that on Windows XP and later is to right click on My Computer and select Manage from the menu. In the Computer Management window, in the tree on the lefthand side, select Disk Management. That will show you a list of all the physical hard disks you have plugged in. They will be listed as "Disk 0", "Disk 1", etc. Make a note of which disk number your target hard disk is. Once you've done that, it's easy to "image" the CHD file onto the disk. Just use the following syntax: chdman -extract imagename.chd \\.\PHYSICALDRIVEn - where "imagename.chd" is the name of the CHD file, and the "n" next to PHYSICALDRIVE is the disk number you figured out above. This technique has been used by several people to restore dead hard drives on arcade games. Note that you can also use chdman to create a backup of a hard disk image in much the same way: chdman -createhd \\.\PHYSICALDRIVEn imagename.chd. Which is how most of the CHD images have been created.
- 0.88               : Rene Single fixed a cut and paste error in CHDMAN.
- 0.86u3             : CHDMAN update [R. Belmont]. This makes the parser deal with .toc files output by current cdrdao better. I need to just give in and rewrite it for 2-pass operation sometime, it'll be much cleaner then. Also converted some CD images to CHD. Incidentally, if anyone has any idea where to get specs for e.g. CloneCD or some other popularish image format(s) let me know and I'll add support.
- 0.81u7             : smf fixed a couple of issues with hard disks without checksums.
- 0.80               : Nathan Woods added some completion messages, and fixed the code that was falsely assuming that progress() was a function pointer in chdman.c
- 0.79u3             : Nathan Woods added -createblankhd and -copydata commands, new arguments to -createhd and ported it to Macintosh.
- 23rd February  2004: Nathan Woods added a few new commands to chdman and ported it to Macs.
- 0.78u5             : Olivier Galibert removed some 'smart' code from CHD filename handling.
- 0.78u1             : Nathan Woods added workaround for deficiency in Metrowerks compiler in chd.c
- 21st December  2003: R. Belmont - Added CD-ROM support to the CHD format and CHDMAN utility. (For the curious, CDRDAO rips are used as input, and CDRWIN bin/cue could be added easily).
- 0.77u3             : Nathan Woods added #ifndef <headername>_H protection to src/harddisk.h and src/chd.h.
- 0.77u2             : Removed src\hdcomp.c. CHDman updates, with added checks to make sure source chd's aren't corrupt when doing updates etc [Aaron Giles].
- 30th November  2003: Aaron Giles sent in another update to chdman, making it verify the files when doing an update, merge or a diff operation.
- 25th November  2003: smf fixed some slight bugs in chdman that prevented it from compiling under DOS.
- 0.77u1             : Added src\chdman.c and src\chd.c. New CHD format and management tools [Aaron Giles]. hdcomp is now chdman old chd files are _not_ compatible, they will need to be updated using chdman -update oldchd.chd newchd.chd. CHD now stands for 'Compressed Hunks of Data' not 'Compressed Hard Drive' as the format is more flexible.
- 21st November  2003: Aaron Giles - Well, I think the new CHD format seems to be working okay. It turns out that the hard drives for the Seattle games are often copied onto much larger hard drives, so finding one on the "factory original" hard drive is a bit tricky. It also means that if you compress the hard drive, it will often have garbage data on the end that makes the resulting CHD much larger than it should be. For example, the Mace hard disk I have is a 3.2GB hard disk, but most of the data on there is garbage and irrelevant to the game. I've been looking into ways of reliably "chomping" away the garbage. My current experiments have Mace down to a svelte 130MB, down from 1.2GB.
- 18th November  2003: Aaron Giles fixed various problems in the new CHD code.
- 17th November  2003: Aaron Giles sent in the first update to the CHD format support, separating the file format and hard disk functionality and adding support for SHA1 checksums in the format.
- 16th November  2003: Aaron Giles - We have a new CHD format. The next version of MAME will require you to update your CHDs. Now don't worry, you can do it yourself using the chdman utility (formerly known as hdcomp). Why the need for an updated format? Well, the existing format was close but not quite general enough to do everything we wanted to support other things like CD images and whatnot, so I re-engineered the CHD format to be usage-neutral. In fact, the code that actually implements the format doesn't know anything about hard disks, sectors, cylinders, etc. I also beefed up the compression a bit so you can get SmallCHD-like sizes in an officially supported manner. There are a also a bunch of other small tweaks & features in the updated format that make it overall a pretty nice improvement.
- 14th November  2003: Aaron Giles started rewriting the compressed hard disk code to better support different formats.
- 29th October   2003: Aaron Giles added a function for making desired read/write accesses take extra time.
- 0.76u1             : Reversed harddisk.c back to 0.73 status.
- 0.75               : Nathan Woods moved some variable declarations out of for loops so that it can compile in non-GCC compilers (src/harddisk.c).
-  6th October   2003: Roman Scherzer fixed a small crash bug in the harddisk writing functions.
- 26th September 2003: Bryan Aldrich submitted an improvement to the compressed hard drive image functions to avoid storing duplicate blocks in the .chd file when creating it, making the file a little smaller if there was redundancy.
- 18th August    2003: Roman Scherzer submitted a small bug fix to the hdcomp program.
- 0.72u1             : Nathan Woods added a function to retrieve the harddisk interface.
- 0.71u1             : Stefan Jokisch fixed MAME not looking in parent directory for Hard Drive images.
- 0.70u1             : Nathan Woods enhances the hard disk code to support sector sizes other than 512 bytes (a non-IDE harddisk in MESS for one of the TI systems uses this).  src/machine/idectrl.c has been modified to take this into account; it requires that HD images be 512 bytes.  The new code is fully backwards compatible with old CHDs that do not have a sector size within them.  
- 31st March     2003: Brad Oliver fixed several minor bugs that affected big-endian systems.
-  1st January   2003: Aaron Giles and Paul Priest fixed a bug in the hard disk image MD5 computation that affected Killer Instinct and Killer Instinct 2.
-  8th December  2002: Aaron Giles implemented compressed hard disk extraction and merging in the hdcomp tool, added support for various things in the IDE controller emulation.
- 30th November  2002: Aaron Giles fixed a crash that sometimes occurred when creating a new hard disk difference file.
- 20th November  2002: Aaron Giles improved the MD5 verification fix.
- 18th November  2002: Aaron Giles sent in an alternate fix for the false-positive MD5 checksums and improved the hdcomp tool.
- 13th November  2002: Aaron Giles prevented hard disk images being stored in ZIP files, and cleaned up various things in the source.
- 31st October   2002: smf added HD image support to the DOS version.
- 0.59               : Added src\harddisk.c, hdcomp.c and md5.c
-  8th March     2002: Aaron Giles added hard disk support and emulation for a standard IDE controller.
- SOURCE: tools\chdman.c

       Hard Drives:
       HDD2141                   HDD2141 MK4313MAT (8944 CYL, 15 Heads, 63 Sectors and 4GB) (Bmcorerm)
       HDD2718                   HDD2718 MK2104MAV (4200 CYL, 16 Heads, 63 Sectors and 2GB) (Bmcompmx)
       Quantum ????              2.1 GB (Jdredd)
       Quantum Fireball EL       2.5 GB (Gauntleg)
       Quantum EL2.5AT           2.5 GB IDE HARD DRIVE (A51site4)
       ST9150AG                  Kinst
       ST9420AG                  Wg3dh - Seagate Laptop Drive model ST9420AG (988 CYL, 16 Heads, 52 Sectors and 420.8MB)
       TOSHIBA MK1924FBV         TOSHIBA MK1924FBV - 2.5" 543MB SCSI hard drive, contains GFX + main program (CryptKiller)
       TOSHIBA ???               988U.A01 4.3 GB (Bmcompm2)
       TOSHIBA ???               858U.A01 2.2 GB (Bmcompmx)



I12.5   CD ROM

- 0.124u2            : R. Belmont reverted previous SCSI CD change which broke some games.
- 0.124u1            : Various SCSI devices register state items by their disk ID, which are not unique across device types. Introduced a device-type offset for CD-ROMs so their registrations don't clash with harddisks [R. Belmont].
- 0.118u6            : smf added SCSIOP_GET_INQUIRY_BUFFER to scsicd & scsihd.
- 0.118u1            : smf fixed converting CD's containing audio that were ripped by cdrdao, which was broken recently. The code is cleaner and more maintainable now. 
- 0.116u4            : R. Belmont added stricter checking in cdrom.c to prevent crashes in games when no CD-ROM is present.
- 0.114u2            : R. Belmont updated stvcd to be working enough that most Saturn games at least die for some other reason, and a few actually do useful things. Also included a small update to the core cdrom code so you can fetch a sector without knowing in advance what format it is.
- 0.111u1            : Nathan Woods moved a chunk of platform specific code out of chdcd.c and romcmp.c into the osd_tool code.
- 0.110u4            : SCSI CD emulation improvements [Ville Linde]: Added Play Audio (12) command. Fixed track number and added MSF support to Read Sub-Channel command.
- 0.110u3            : Aaron Giles cleaned up cdrom.c. Removed audio implementation and relocated code into sound/cdda.c. Changed metadata format to be textual instead of binary (old metadata format is still supported). Removed external access to CHD positions; all accesses are now done at the physical LBA level and converted internally.
- 0.109u5            : R. Belmont improved behavior of SCSI CD implementation for audio playback and TOC reading commands.
- 0.106u1            : Improvements to CHD-CD support [R. Belmont]: Additional RAW CD sector conversion support, so a game can request e.g. 2048-byte data sectors from a RAW CHD-CD and still get the right data. Reversed CHDMAN error message - now non-RAW CHD-CDs are deprecated. Susume now uses a RAW CHD-CD read directly from an original pressed Konami disc.
- 18th March     2006: Guru - CDROM - GE984 A01(BM) arrived late yesterday from Japan.
- 0.103              : R. Belmont added cdrom_get_track_length() to cdrom.c and completely rewrote machine/stvcd.c and .h. There's a lot less there now, but what's there is more understandable and works much better.
- 0.95               : Added machine\scsicd.c. R. Belmont moved actual CD-ROM and harddisk device emulation out of am53cf96.c to new scsicd.c and scsihd.c files. CD-ROM emulation expanded to support more SCSI commands and bugfix some existing ones. Added -extractcd to convert CHD-CDs back into CDRDAO .bin/.toc images.
- 0.89u1             : R. Belmont fixed small problem in CHDCD.
-  5th April     2004: R. Belmont improved the CHD-CD support slightly, to support other track formats better.
- 0.81               : CHDMan CHDCD creation fix [R. Belmont].
- 0.80u3             : Added src\cdrom.c, chdcd.c and sound\cdda.c. R. Belmont added Preliminary CD-ROM support for CHDMAN. Input is from CDRDAO .toc/.bin  images (cdrdao.sourceforge.net). CDRDAO comes with utilities to convert CDRWIN .cue/.bin images to .toc/.bin format. CDROM emulation primitives, including Red Book audio playback and support for the AM53cf96 SCSI controller. The SCSI CD-ROM emulation needs to be separated out from the AM53cf96 if we ever emulate other SCSI controllers or CD-ROM drives. CHDMAN doesn't output anything useful when you extract a CHD-CD. It should write out a CDRDAO image.
- 15th January   2004: R. Belmont - CD audio tracks now work for CHD-CDs, so Susume! Taisen Puzzle-Dama has background music.
-  2nd January   2004: R. Belmont - Ongoing work on CHD-CD support to make it submittable.
- 21st December  2003: R. Belmont - Added CD-ROM support to the CHD format and CHDMAN utility. (For the curious, CDRDAO rips are used as input, and CDRWIN bin/cue could be added easily).
- 0.77               : Support for preliminary CD driver for the STV game Sports Fishing 2 (machine\stvcd.c)
- NOTES
  - If the CD in the Konami-GV System is swapped to another GV game, the game will boot but will stop with an error '25C MBAD' (the EEPROM is 25C). So the games can not be swapped by simply exchanging CDs because the EEPROM will not re-init itself if the CDROM is swapped. This appears to be some form of mild protection to stop operators swapping CD's. The CD contains one MODE 1 data track and several Redbook audio tracks which are streamed to the speaker.
  - The CD for the Konami GV System contains one MODE 1 data track and several Redbook audio tracks which are streamed to the speaker via CN8.
  - For the Capcom CPS-3 games the dumper used CDRWIN V.3.4C to copy the CD
  - CD labels: CAP-WZD-5 (Capcom 1996 - Warzard), CAP-JJK-140 (Capcom 1998 - JoJo's Venture), 703EAA02 (Konami 1998 - Heatof11)
- GAMES: cps3.c, konamigv.c, konamim2.c, stv.c (sfish2)
- SOURCE: src\cdrom.c, tools\chdcd.c, emu\machine\scsicd.c, machine\stvcd.c, sound\cdda.c
- PCB: CAP-WZD-5 (CD labeled as 703EAA02 (Heatof11)

       CDROM drives:
       Panasonic / Matsushita CR-504-KCM  4X SCSI  drive (CPS-3)
       Panasonic              CR-583      8x CDROM drive (Polystar)





I12.6   Laser Disc

- 0.112u3            : Aaron Giles added new tool makemeta.exe, which can generate properly formatted metadata for laserdisc CHDs using either a specially captured AVI as input (preferred) or a hand-crafted set of encoded Philips codes.
- 0.112u2            : Aaron Giles added several new modules to the utility library libutil. First is a generic huffman encoding module. Second is a module that allows you to read/write AVI files in a platform-independent way. And third is a lossless A/V compression module. These three pieces together, plus some changes in the CHD code, allow for the creation of CHDs with compressed audio and video. Added two new commands to chdman: -createav converts an AVI file in uncompressed YUY format or HuffYUV-compressed YUY format with "left" prediction into a CHD. And -extractav converts a CHD containing compressed audio & video into an uncompressed YUY format AVI file. Finished hooking up laserdisc support to the new audio/video compression. Note that we still do not have canonical CHDs of laserdisc data at the moment, but all the support is now present for when they start to appear.
- 0.111u5            : Aaron Giles added support for the custom Badlands commands to the LD-V1000 emulation.
- 0.111u4            : Ernesto Corvi added support for the Pioneer PR-8210 laserdisc player. Aaron Giles improved behavior of the laserdisc code when seeking so it doesn't get "stuck". Added preliminary support for the 22VP932 laserdisc player.
- 0.111u3            : More updates to the laserdisc emulation, based on more complete understanding of how the discs are encoded and how they will eventually be stored [Aaron Giles].
-  2nd January   2007: Aaron Giles - Some Laserdisc Progress: After a bit of a hiatus with the holidays and fun power outages, I've been back making some progress on the laserdisc support. I now have the basic CHD format spec'ed out and implemented. And I have modified chdman.exe to support two new commands: -createav, which takes an AVI file plus an optional metadata file and compresses them to a CHD; and -extractav, which takes a CHD file and extracts it to an AVI file and a metadata file. (And yes, the AVI reader/writer is cross-platform code, so it will work on non-Windows platforms as well. I also have a mostly complete QuickTime reader/writer, but am not sure if it is worth the effort to complete it. Though plugging the two together would produce an AVI <-> QuickTime conversion program, which would be useful!). I'm happy to say that with a little bit of work using a test capture, I am now actually capable of displaying video from within MAME. There's still a lot of work to do yet to get the rest of the way, but this is a good step forward. Next up will be synchronizing frame and track numbers (you'll note the numerical discrepancy in the screenshot), wiring up the sound, improving performance, further enhancing chdman.exe with some additional I/O options, and all the while working with the great group of folks I've been talking to in order to get great quality source captures. More to come as it all comes together!
- 0.110u5            : Reorganized the laserdisc support a bit to accommodate new players. Added Sony LDP-1450 support.
-  4th December  2006: Aaron Giles - It should be pretty obvious with the update to the Dragon's Lair driver in 0.110u4 that something is brewing on the laserdisc front. There has been a lot of discussion over the years about how to make it happen, what video formats to use, etc, etc. In the end, it seemed that nobody was ever happy enough with the proposed ideas to actually take them and run. But with the discs and equipment getting older and older, and my (relatively) recent success in reading an NFL Football CED (http://www.cedmagic.com/featured/nfl.html) (thanks to Tim's (http://arcadecollecting.com/) help), I figured it was finally time to just pick a direction and move forward. One of the big stumbling blocks is that pretty much all existing video compression algorithms are heavily patented. Which means that for freely developed and freely available software, there isn't really a good way of utilizing standards such as MPEG. Plus, MPEG hardly qualifies as 'archival' quality. For this reason, MAME will be going its own way, but it won't be straying too far from the usual paths. The container format for the data will be CHD (which originally stood for Compressed Hard Drive, but has since been redubbed as Compressed Hunks of Data). Each frame, including audio and video data, will be a fixed length (some frames will have one fewer audio sample due to rounding, but this is easy to compute). The video frame rate, height, width, audio sample rate, and number of channels will be encoded in the CHD metadata. Each frame is independently compressed. Audio data is stored as multiple 16-bit channels at an arbitrary sample rate (we will be shooting for 44.1kHz stereo during sampling). The audio data is compressed losslessly using Huffman-compressed deltas. This gives a nice compromise between storing the data raw and doing something more complex and aggressive like FLAC. Audio data is just a drop in the bucket anyway from a data rate perspective, so why skimp? This compression may also be used in the future for CHD-CD's with audio tracks, and for systems that read/playback tape-based data. Video data compression is still being fine-tuned, and is waiting some good quality source data to experiment with, both animated and filmed. At a minimum, a lossless compression based on Huffman-compressed per-channel (Y,Cb,Cr) deltas will be available. This is essentially what HuffYUV does. I have also written a lossy DCT-based compressor that is tuned for archival purposes rather than bit rate limiting. That is, with an MPEG compressor you specify your data rate, and the compressor quantizes the DCT coefficients to fit the data rate. With our video compression, you specify a maximum error and a maximum average error for each channel, and the compressor tweaks the quantization on each 8x8 block indepedently to ensure that those criteria are met. The source material will be sampled at DVD resolutions (720x486 for NTSC video) in 'uncompressed' form - which is actually slightly compressed in that it is 4:2:2 subsampled, so each Cr and Cb sample covers two pixels horizontally. This is oversampling for laserdisc video, but it's better to have more data than not enough data. This effectively gives you 16 bits per pixel uncompressed, or 720 x 486 x 2 = 699,840 bytes per frame. Add in a frames' worth of audio data (assuming 29.97fps) at 44100Hz gives an extra 5886 bytes, for a total per-frame average of 705,726 bytes (5.4 MBits) per frame. Once you start multiplying that out, it's a lot of data: 20.6 MB/second, 1.18 GB/minute, or 70.9 GB/hour. Most video game laserdiscs are CAV, which maxes out at 54000 frames, or just over 30 minutes. Lossless tends to give you between 2:1 and 3:1 compression.
                                    Going up to lossy with medium deltas (up to 4/256 per component) gets you closer to 4:1 and 5:1 compression with almost no visible difference. Increasing the max deltas beyond that helps further with compression, but it definitely starts to become visible. Not everything is nailed down yet, and it will probably take a couple of months to materialize, but those are the basics. The first game I'm looking at is obviously Dragon's Lair, but coincidentally, I just received in the mail a driver for the American Laser Games series (http://www.dragons-lair-project.com/tech/pages/alg.asp) of shooters as well, which were all run on an Amiga 500 with a genlock. Fortunately, the Amiga emulation is pretty decent these days, so things are progressing well there. Now that the basic system is up and running, I'm hoping others can help get the rest of the laser games moving forward. In 0.110u4 I included support for a couple of common laserdisc players. Even though you can't see any video yet, you can at least watch their operation to see if things are working properly. In 0.110u5 I'll have support for the Sony LDP-1450 (http://www.dragons-lair-project.com/tech/ldguide/sony.asp) laserdisc player and the ability to display dummy frames (each frame is solid color and gets a unique Cb/Cr value) so that you get a little better sense of the operation. And hopefully in the next month or so, I'll have the first video running at last...
- 0.110u4            : Added machine\laserdsc.c. Aaron Giles rewroted the Dragon's Lair driver from the schematics. Added new module machine/laserdsc.c which has laserdisc emulation for the PR-7280 and LD-V1000 laserdisc players. Full emulation of the laserdisc is pending support for CHD audio/video and high quality rips, but you can operate the game and see the frame numbers that would be displayed. Added built-in layout to display the scores, lives and credit information.
-  1st September 2001: Mirko Buffoni added support for the Dragon's Lair video. However, it only works with the DVD-ROM version and only in Windows, so inclusion is unlikely.
- SOURCE: emu\machine\laserdsc.c
- GAMES: Dragon's Lair (Cinematronics 1983), M.A.C.H. 3 (Mylstar 1983), Us vs. Them (Mylstar 1984)

        Hitachi VIP-9500/9550           Galaxy Range (Sega 1984)
        Philips 22VP932                 Space Ace (European), Dragon's Lair (European)
        Pioneer PR-7820                 Dragon's Lair (Cinematronics 1983)
        Pioneer LD-V1000, LD-V1100      Badlands (Konami 1984)
        Pioneer PR-8210A                M.A.C.H. 3  (Mylstar 1983), Cliff Hanger
        Sony LDP-1000A                  Cobra Command (Data East 1984)

        Hardware: Z80, 6809 or 6502
        Sound   : TI SN76496 PSG or 2x AY-3-8910


        http://www.laserarcade.com/





I13.    Motherboard chipset

I13.1   I750

- SOURCE: drivers\deco32.c
- PCB: Intel i750 = Intel 82750 on the Back Board (Dragngun, Lockload)




I14.    Connectors

        8x2  - 8-pin connector for extra controls (Janjans2)
       18x2  - Edge connector, 18-way (Harem, Jollycrd, Promutrv, Royalcrd)
       22x2  - Edge connector, 22-way (Jollycrd, Royalcrd)
       36x2  - Edge connector, 36-pin (Puckman)
       56x2  - Edge connector, 56-way (Roughrac)
       100x2 - Edge connector, 100-pin (Profpac) - Interconnect cable to 6 boards

       28WAY - Edge connector is JAMMA backwards (GND is pin 28,27; +5V is pins 26,25 etc) and with RBG locations moved (i.e. not standard JAMMA) (Pkgnshdx)
       48WAY - Edge connector used for extra controls and to output the 2nd speaker when set to stereo mode. (NamcoSystem11)

       JAMMA - Edge connector (Puzzlekg)

       CN103 - 4-pin connector for gun hookup
       CN106 - 4-pin connector for gun hookup
       CN121 - Output connector for left/right speakers (Rdft)
       CN503 - Connector for optional 15kHz external video output (R,G,B,Sync, GND)
       CN504 - Connector for optional 2nd speaker (for stereo output)
       CN505 - Connector for optional 4th player controls
       CN506 - Connector for optional 3rd player controls
       CN651 - Connector for optional analog controls
       CN652 - Connector for optional trackball
       CN654 - Connector for optional memory card

       G6A-474P - PCB: OMRON G6A-474P is a four pole double throw relay (F1GP, Tail2nos)

       IDC34 - IDC34 way flat cable plug (PGM-System), IDC 34 (Crysking, SegaSystem24)
       IDC40 - IDC connector, 40 pin (leading to sound board) (Nbajamex), IDC connector for plugging of a flat 40-wire cable (not used, purpose unknown, possible CDROM/DVD) (NamcoSystem10)

       IDE   - Standard (PC-compatible) 40 pin IDE CDROM flat cable connector and 4 pin power plug connector (Polystar)

       J103  - Custom Namco connector for plug-in ROM PCB
       J201  - Custom Namco connector for mounting of main ROM (game) board, 100 pin
       J202  - Custom Namco connector for mounting of another board (not used, purpose unknown),  80 pin

       USB-A   - Standard USB type A connector, PCB labelled '(TX)'   (NamcoSystem12)
       USB-B   - Standard USB type B connector, PCB labelled '(RX)'   (NamcoSystem12)



I15.    PC hardware
- 0.124u1            : Did some major cleanup and gutting of pcshare.c. [Wilbert Pol]
- 0.101u2            : Added machine\pcshare.c.
- NOTES: Functions to emulate general aspects of the machine (RAM, ROM, interrupts, I/O ports). The information herein is heavily based on 'Ralph Browns Interrupt List'.




 


OTHER

  1.    Transistors
  1.1   TTL (Transistor Transistor Logic) IC's
  1.2   C-MOS (LOC - MOS)
  1.3   Others
  1.4   Logic Gates

  2.    Timer & Clock ICs
  2.1   NE555
  2.2   NE556
  2.3   NE558
  2.4   NE566
  2.5   MC6840
  2.6   MB8873
  2.7   8253
  2.8   8254
  2.9   NEC D71054

  3.    RTC (Real Time Clock)
  3.1   DALLAS
  3.11  DS1221
  3.12  DS1302
  3.13  DS1643
  3.14  DS2401
  3.15  DS2404
  3.16  DS17487
  3.2   Epson
  3.21  3520
  3.22  4543
  3.23  62423
  3.24  65271
  3.25  72421
  3.26  72423  
  3.3   Motorola
  3.31  MPC948
  3.32  MPC950
  3.4   NEC
  3.41  PD4990
  3.5   OKI
  3.51  6242
  3.6   Other
  3.61  8521
  3.62  V3021

  4.    Key chip

  5.    Clock
  5.1   Crystal
  5.11  Crystal Resonator
  5.2   Cypress
  5.21  CY2291
  5.22  CY2292
  5.5   ICS
  5.51  9120
  5.52  9170
  5.53  9159
  5.6   Others
  5.61  8224
  5.62  8284
  5.63  2061ASC
  5.64  MX8330
  5.65  MC88915

  6.    Reset IC
  6.1   Dallas
  6.11  DS1232
  6.12  DS1233
  6.2   Mitsubishi, NEC
  6.21  PST518
  6.22  PST532
  6.23  PST573
  6.24  PST575
  6.25  PST592
  6.26  M51953
  6.3   Maxim
  6.31  MAX690
  6.32  MAX691
  6.33  MAX693
  6.4   Mitsumi
  6.41  MM1026
  6.42  MM1035
  6.5   Texas Instruments
  6.51  TL7700
  6.52  TL7705
  6.6   Other
  6.61  ADM690
  6.62  HA16103

  7.    Voltage regulator
  7.1   7660
  7.2   7808
  7.3   7812
  7.4   PQ30RV21
  7.5   3423
  7.6   LT1084

  8.    Switch
  8.1   S301
  8.2   S551

  9.    Diodes
  9.1   4148
  9.2   Laser Disc diode

 10.    Capacitor
 11.    Debug Mode
 12.    BIOS
 13.    Instruction Cards

..................................................................................................................................................................................................................................


O1.    Transistors


       C1815
       - NOTES: The C1815 is a transistor. This transistor is used for driving RGB in Special Criminal Investigation for example.
       - GAMES: Head On (Irem 1980), Special Criminal Investigation (Taito 1989)

       D633
       - PCB: The D633 is a Si NPN POWER transistor used in 68k reset circuit (TIP122 compatible) (Sci)

       IR2C24
       - PCB: Sharp IR2C24AN  6-Unit 320mA Transistor Array (Speedrcr, Namco FL-System, NamcoNA2)

       M53357
       - PCB: Mitsubishi M53357P (=LS157 = Quad 2 to 1 line data selectors/multiplexers) in (40love)

       M54532
       - NOTES: Mitsubishi M54532P / M54532FP, DIP16 = 4-unit 1.5A darlington transistor array with clamp diode
       - PCB: M54532 (Rvschool, Glpracr, Sfex2)

       MC14584
       - NOTES: This chip is used for the trackball trigger / reading / converting values. Joystick appears to be used also for selecting stance, club and direction.
       - PCB: Motorola MC14584b  HEX Schmitt Trigger (Eaglshot, SSV)

       PS2501
       - PCB: NEC PS2501 High Isolation Voltage Single Transistor Type Multi Photocoupler, DIP16 (CPS3)

       SLA4060
       - PCB: Sanken Electric Co. NPN Darlington Transistor Array, SIP12 (NamcoSystem11/12)

       TD62003
       - NOTES: TD62003 PNP 50V 0.5A Quad Darlington Switch for driving coin meters and lamps/LEDs.
       - PCB: Toshiba TD62003AP (RongRong), TD62oo3AP (Topshoot), TD62003, DIP16 (Crysking, Sci), TD62003P (40love)

       TD62064
       - NOTES: TD62064 NPN 50V 1.5A Quad Darlington Switch for driving coin meters.
       - PCB: TD62064 (CPS3, ZN1/2, Sci) Evilston, TD62064AP  DIP16 (Radikal Bikers)

       TIP120
       - PCB: TIP120 (UpScope)

       TIP122
       - NOTES: General-Purpose NPN Darlington Transistor
       - PCB: TIP122  TO-220 (Ghosthunt, Tutstomb)

       ULN2003
       - NOTES: ULN2003 is a High Voltage High Current Darlington Transistor Array comprising 7 NPN Darlinton pairs.
       - PCB: Toshiba ULKN2003, DIP16 (Lastfght), ULN2003A (CatherineWheel), ULN2003 for coin counter output (Chboxing, Chwrestl, Sauro) 

       ULN2064
       - PCB: ST ULN2064B, DIP16 (A51site4, MK3, Kinst)

       ULN2803
       - NOTES: ULN2803 is a Octal High Voltage, High Current Darlington Transistor Arrays with common emitter
       - PCB: ST ULN2803A (Lethalj), Motorola ULN2803  DIP18 (Ghosthunt, Tutstomb)

       ULN2805
       - PCB: Usg182



O1.1   TTL (Transistor Transistor Logic) ICs


       Manufacturer:
       Fairchild Semiconductor          74LCXxxx
       ???                              74LVTxxx
       Philips                          74HCxxx
       National Semiconductor         DM74LSxxx
       Texas Instruments              SN74LCxxx, 1N74SxxxN



       TTL - ICs/Types

       7400 Quad 2-input NAND gates. Pins 14,  74LS00, 74HC00 (DIP14), 74HC00P, 74F00 (SOIC14), F7400PC, 7400-PC
       7401 Quad 2-input open-collector NAND gates. Pins 14
       7402 Quad 2-input NOR gates. Pins 14,   74LS02, DM7402N, F7402PC
       7403 Quad 2-input open-collector NAND gates. Pins 14
       7404 Hex inverters. Pins 14,   SN74LS04N, SN7404N, 74LS04, 74HC04, 74F04PC, DM7404N, 7404-PC, HC04 (NeoGeo)
       7405 6x Hex open-collector inverters. Pins 14,  74LS05, DM7405
       7406 6x Hex open-collector high-voltage inverters. Maximum output voltage is 30V. Pins 14,  DM7406N
       7407 6x Hex open-collector high-voltage buffers. Maximum output voltage is 30V. Pins 14,   74F07 (SOIC14)
       7408 Quad 2-input AND gates. Pins 14,  7408N, 74LS08, 74ALS08, DM7408N, F7408PC, F7408N
       7409 Quad 2-input open-collector AND gates. Pins 14
       7410 Triple 3-input NAND gates. Pins 14,  74LS10
       7411 Triple 3-input AND gates. Pins 14,  SN74LS11N
       7412 Triple 3-input open-collector NAND gates. Pins 14
       7413 Dual 4-input NAND gates with schmitt-trigger inputs. Pins 14
       7414 Hex inverters with schmitt-trigger inputs. Pins 14,  74LS14N, 74HC14, 74HCT14, LS14 (SOIC14), 78AT3TK HC14 (SOIC14)
       7415 Triple 3-input open-collector AND gates. Pins 14
       7416 Hex open-collector high-voltage inverters. Maximum output voltage is 15V. Pins 14,  F7416PC
       7417 Hex open-collector high-voltage buffers. Maximum output voltage is 15V. Pins 14
       7418 Dual 4-input NAND gates with schmitt-trigger inputs. Pins 14
       7419 Hex inverters with schmitt-trigger line-receiver inputs. Pins 14
       7420 Dual 4-input NAND gates. Pins 14,  74LS20, 7420PC
       7421 Dual 4-input AND gates. Pins 14
       7422 Dual 4-input open-collector NAND gates. Pins 14
       7423 Dual 4-input Expandable NOR w/strobe. Pins 16,  74LS23
       7424 Quad 2-input NAND gates with schmitt-trigger line-receiver inputs. Pins 14
       7425 Dual 4-input NOR gates with enable input. Pins 14
       7426 Quad 2-input open-collector high-voltage NAND gates. Maximum output voltage is 15V. Pins 14
       7427 Triple 3-input NOR gates. Pins 14
       7428 Quad 2-input NOR gates with buffered outputs. Pins 14
       7430 8-input NAND gate. Pins 14
       7431 Hex delay elements. Pins 16
       7432 Quad 2-input OR gates. Pins 14,  SN7432N, 74LS32, 74HC32, 74HCT32 (SOIC14), HC32 (NeoGeo)
       7433 Quad 2-input open-collector NOR gates. Pins 14
       7434 Hex Buffer. Pins 14
       7435 Hex Buffer open-collector. Pins 14
       7437 Quad 2-input NAND gates with buffered output. Pins 14,  74LS37
       7438 Quad 2-input open-collector NAND gates with buffered output. Pins 14
       7439 Quad 2-input positive NAND buffers with open-collector outputs. Pins 14
       7440 Dual 4-input NAND gates with buffered output. Pins 14
       7442 1-of-10 inverting decoder/demultiplexer. Pins 16,  SN7442AN, F7442APC, DM7442N
       7443 4-line to 10-line decoders (excess 3 to decimal). Pins 16
       7444 4-line to 10-line decoders (3-gray to decimal). Pins 16
       7445 BCD to decimal decoder/driver. Pins 16,   SN7445N74
       7446 Open-collector BCD to 7-segment decoder/common-anode LED driver with ripple blank input and output. Pins 16
       7447 Open-collector BCD to 7-segment decoder/common-anode LED driver with ripple blank input and output. Pins 16,   7447A (equivalent to an LS47/48)
       7448 BCD to 7-segment decoders/drivers. Pins 16,  74LS48
       7449 BCD to 7-segment decoders/drivers (open-collector outputs). Pins 14
       7450 Dual 2-wide 2-input AND-OR-INVERT gates (one gate expandable). Pins 14
       7451 2-wide 2-input and 2-wide 3-input AND-NOR gates. Pins 14,   DM74LS51N
       7452 Expandable 4-wide AND-OR gates. Pins 14
       7453 Expandable 4-wide AND-OR-INVERT gates. Pins 14
       7454 4-wide 2/3-input AND-NOR gate. Pins 14
       7455 2-wide 4-input AND-NOR gate. Pins 14
       7456 50-to-1 Frequency Divider. Pins 8
       7457 60-to-1 Frequency Divider. Pins 8
       7458 2-wide 2-input and 2-wide 3-input AND-OR gates. Pins 14
       7460 Dual 4-input expanders. Pins 14
       7461 Triple 3-input expanders. Pins 14
       7462 4-wide AND-OR expanders. Pins 14
       7463 Hex current-sensing interface gates. Pins 14
       7464 4-2-3-2 input AND-OR-INVERT gates. Pins 14
       7465 4-2-3-2 input AND-OR-INVERT gates. Pins 14
       7468 Dual 4-bit decade counter. Pins 16
       7469 Dual 4-bit binary counter. Pins 14
       7470 AND-Gated J-K positive edge triggered flip-flops. Pins 14
       7471 AND-OR-Gated J-K master-slave flip-flops with preset. Pins 14
       7472 J-K flip-flop with triple ANDed J an K inputs, set and reset. Pins 14
       7473 Dual positive-edge-triggered J-K flip-flop with reset. Pins 14
       7474 Dual D flip-flop with set and reset. Pins 14,   74LS74, 74S74N, 74HC74, 74HC74B1, DM74LS74N, DM7474N, 74F74
       7475 Dual 2-bit transparent latches with complementary outputs. Pins 16
       7476 Dual J-K flip-flops with set and reset. Pins 16
       7477 4-bit bistable latches. Pins 14
       7478 Dual negative-edge-triggered J-K flip-flops with common clock, set and common reset. Pins 14
       7480 1-bit binary full adder. Pins 14
       7481 16-bit Random-Access-Memories. Pins 14
       7482 2-bit binary full adder. Pins 14
       7483 4-bit binary full adder with fast carry. Pins 16,   DM74LS83AN, SM74LS83AN
       7484 16-bit Random-Access-Memories. Pins 16
       7485 4-bit noninverting magnitude comparator with cascade inputs. Pins 16
       7486 Quad 2-input XOR gates. Pins 14,  7486N, 74LS86, F7486PC, LS86A (SOIC14)
       7487 4-bit true/complement, zero/one elements. Pins 14
       7488 256-bit read-only-memories. Pins 16
       7489 64-bit read/write memories. Pins 16
       7490 4-bit asynchronous decade counter with /2 and /5 sections, set(9) and reset. Pins 14
       7491 8-bit serial-in serial-out shift register with two AND gated serial inputs and complementary outputs. Pins 14
       7492 4-bit asynchronous divide-by-twelve counter with /2 and /6 sections and reset. Pins 14
       7493 4-bit asynchronous binary counter with /2 and /8 sections and reset. Pins 14
       7494 4-bit shift registers. Pins 16
       7495 4-bit universal shift register with separate shift and parallel-load clocks. Pins 14
       7496 5-bit shift register with asynchronous reset and asynchronous preset inputs. Pins 16
       7497 6-bit synchronous binary rate multiplier. Pins 16
       7498 4-bit data selector/storage registers. Pins 16
       7499 4-bit bidirectional universal shift registers. Pins 16
       74100 8-bit bistable latches. Pins 24
       74101 AND-OR-Gated J-K negative edge triggered flip-flops with preset. Pins 14
       74102 AND-Gated J-K negative edge triggered flip-flops with preset and clear. Pins 14
       74103 Dual J-K negative edge triggered flip-flops with clear. Pins 14
       74106 Dual J-K negative edge triggered flip-flops with preset and clear. Pins 16
       74107 Dual J-K flip-flops with clear. Pins 14,   74LS107, 74107N
       74108 Dual J-K negative edge triggered flip-flops with preset, common clear and common clock. Pins 14
       74109 Dual J-/K positive edge triggered flip-flops with preset and clear. Pins 14
       74110 AND-Gated J-K master-slave flip-flops with data lockout. Pins 14
       74111 Dual J-K master-slave flip-flops with data lockout. Pins 16
       74112 Dual J-K negative edge triggered flip-flops with preset and clear. Pins 16
       74113 Dual J-K negative edge triggered flip-flops with preset. Pins 14
       74114 Dual J-K negative edge triggered flip-flops with preset, common-clear and common-clock. Pins 14
       74116 Dual 4-bit latches. Pins 24
       74120 Dual pulse synchronizers/drivers. Pins 16
       74121 Monostable multivibrators. Pins 14
       74122 Retriggerable monostable multivibrators with clear. Pins 14
       74123 Dual retriggerable monostable multivibrators with positive and negative inputs and direct clear. Pins 16
       74124 Dual voltage-controlled oscillators with enable inputs. Pins 16
       74125 Quad bus buffer gates with three-state outputs. Pins 14,  TI SN74LS125AN
       74126 Quad bus buffer gates with three-state outputs. Pins 14
       74128 Line Drivers. Pins 14
       74131 3 to 8 line decoder/demultiplexer with address registers. Pins 16
       74132 Quad 2-Input positive NAND schmitt triggers. Pins 14,  74HC132
       74133 13-Input positive NAND. Pins 16
       74134 12-Input positive NAND gates with three-state outputs. Pins 16
       74135 Quad exclusive OR/NOR gates. Pins 16
       74136 Quad exclusive OR gates with open-collector outputs. Pins 14,  DM74LS136N
       74137 3 to 8 line decoders/demultiplexers with address latches. Pins 16
       74138 3 to 8 line decoders/demultiplexers. Pins 16,   74LS138, 74HC138, 74F138, F138, DM74LS138N
       74139 Dual 2 to 4 line decoders/demultiplexers. Pins 16,   74LS139, 74S139N, 74HC139, 74F139
       74140 Dual 4-input positive NAND 50-ohm line drivers. Pins 14
       74141 BCD to decimal decoder/driver. Pins 16
       74142 Counter/latch/decoder/driver. Pins 16
       74143 Counters/latchs/decoders/drivers. Pins 24
       74144 Counters/latchs/decoders/drivers. Pins 24
       74145 BCD to decimal decoders/drivers for lamps, relays, MOS. Pins 16
       74147 10-Line decimal to 4-line BCD priority encoders. Pins 16
       74148 8 to 3 line octal priority encoders. Pins 16,   74LS148
       74150 1 of 16 data selectors/multiplexers. Pins 24
       74151 1 of 8 data selectors/multiplexers. Pins 16
       74152 1 of 8 data selectors/multiplexers. Pins 14
       74153 Dual 4-line to 1-line data selectors/multiplexers. Pins 16,   TTL74153, 74LS153, DM74153N
       74154 4-line to 16-line decoders/demultiplexers. Pins 24
       74155 Decoders/Demultiplexers. Pins 16
       74156 Decoders/Demultiplexers. Pins 16
       74157 Quad 2 to 1 line data selectors/multiplexers. Pins 16,  74LS157, 74HC157, DM74157N
       74158 Quad 2 to 1 line data selectors/multiplexers. Pins 16,   SN74LS158N, DM74158N
       74159 4 to 16 line decoders/demultiplexers. Pins 24
       74160 Synchronous 4-bit counters (decade, direct clear). Pins 16,   SN74160N
       74161 Synchronous 4-bit counters (binary, direct clear). Pins 16,  74161N, 74LS161, DM74LS161N, DM74161AN, F74161PC, PCB: Ckong - The bank switch on the graphics ROMS was controlled by pin 3 of J9 (LS161).
       74162 Synchronous 4-bit counters (decade, synchronous clear). Pins 16
       74163 Synchronous 4-bit counters (binary, synchronous clear). Pins 16,  74LS163
       74164 8-bit parallel out serial shift registers (synchronous clear). Pins 14
       74165 8-bit shift register (parallel load with complementary outputs). Pins 16
       74166 8-bit shift register (parallel/serial input, serial output). Pins 16,  DM74166N
       74167 Synchronous decade rate multipliers. Pins 16
       74168 4-bit up/down synchronous counters (decade). Pins 16
       74169 4-bit up/down synchronous counters (binary). Pins 16
       74170 4-by-4 register files. Pins 16
       74171 Quad d-type flip-flops with clear. Pins 16
       74172 16-bit register files. Pins 24
       74173 4-bit d-type registers (3-state outputs). Pins 16,  74F273
       74174 Hex d-type flip-flops (single-rail ouputs, common direct clear). Pins 16,  74174N, SN74174N, 74LS174, 74S174N, DM74LS174N
       74175 Quad d-type flip-flops (complementary outputs, common direct clear). Pins 16,  74LS175, SN74175N
       74176 Presettable decade/biquinary counters. Pins 14
       74177 Presettable binary counters. Pins 14
       74178 4-bit universal shift register. Pins 14
       74179 4-bit universal shift registers. Pins 16
       74180 9-bit odd/even parity generator/checker. Pins 14
       74181 Arithmetic logic units/function generators (16 arithmetic operations,16 logic functions). Pins 24
       74182 Look-ahead carry generators. Pins 16
       74183 Dual carry-save full adders. Pins 14
       74184 Code converters (BCD to binary). Pins 16
       74185 Code converters (Binary to BCD). Pins 16
       74187 1024-bit read-only-memories (256 4-bit words, open-collector outputs). Pins 16
       74188 256-bit programmable read-only-memories (32 bytes, 32 x 8). DIP16,  74S188, SN74S188N, DM74S188A (Ad2083, Sprint1/2)
       74189 64-bit ramdom-access-memories (16 4-bit words, 3 state outputs). Pins 16, 74s189 ram (Revenger, Tripool)
       74190 Synchronous up/down counters (BCD). Pins 16
       74191 Synchronous up/down counters (Binary). Pins 16
       74192 Synchronous up/down dual clock counters (BCD with clear). Pins 16
       74193 Synchronous up/down dual clock counters (Binary with clear). Pins 16
       74194 4-bit bidirectional universal shift registers. Pins 16,  74LS194
       74195 4-bit parallel-access shift registers. Pins 16
       74196 Presettable decade/biquinary counters/latches. Pins 14
       74197 Presettable binary counters/latches. Pins 14
       74198 8-bit bidirectional universal shift registers. Pins 24
       74199 8-bit bidirectional universal shift registers (J-/K serial inputs). Pins 24
       74201 256-bit random-access-memories (256 1-bit words, 3 state outputs). Pins 16,  74LS201, 74S201
       74217 256-bit random-access-memories with three state outputs (64 x 4-bit words). Pins 20
       74218 256-bit random-access read/write memories with three state outputs (32 x 8-bit words). Pins 20
       74219 64-bit random-access-memories (16 x 4-bit words). Pins 16
       74221 Dual monostable multivibrators. Pins 16
       74222 64-bit FIFO memories 16 4-bit words (input-ready enable, output-ready enable, 3-state output). Pins 20
       74224 64-bit FIFO memories 16 4-bit words (3 state output). Pins 16,    74LS224N
       74225 80-bit FIFO memories 16 5-bit words. Pins 20
       74226 4-bit parallel latched bus transceivers (3 state outputs). Pins 16
       74227 64-bit FIFO memories 16 4-bit words (input-ready enable, output-ready enable, open-collector outputs). Pins 20
       74228 64-bit FIFO memories 16 4-bit words (open-collector outputs).Pins 16
       74230 Octal buffers and line drivers (3 state output). Pins 20
       74231 Octal buffers and line drivers (3 state output). Pins 20
       74240 Octal buffers/Line drivers/Line receivers (inverted 3 state outputs). Pins 20,  74LS240
       74241 Octal buffers/Line drivers/Line receivers (non-inverted 3 state outputs). Pins 20,  74LS241
       74242 Quad bus tranceivers (inverted 3 state outputs). Pins 14
       74243 Quad bus tranceivers (non-inverted 3 state outputs). Pins 14
       74244 Octal buffers/Line drivers/Line receivers (non-inverted 3 state outputs). Pins 20,   74LS244N, 74LVT244, 74F244N (SOIC20), 74ACTT244N
       74245 Octal bus tranceivers (non-inverted 3 state outputs). Pins 20,   74LS245P, 74HC245N, 74F245 (SOIC20), 74LVT245, LVT245SS, 74LCX245 (SOP20), ST T74L6245BI (Bmcbowl)
       74246 BCD to seven segment decoders/drivers with ripple blanking. Pins 16,  74LS246
       74247 BCD to seven segment decoders/drivers with ripple blanking. Pins 16
       74248 BCD to seven segment decoders/drivers (internal pull-up outputs). Pins 16
       74249 BCD to seven segment decoders/drivers (open-collector outputs). Pins 16
       74251 Data selectors/multiplexers (true and inverted 3 state outputs). Pins 16
       74253 Dual data selectors/multiplexers (3 state outputs). Pins 16
       74257 Quad data selectors/multiplexers (non-inverted 3 state outputs). Pins 16
       74258 Quad data selectors/multiplexers (inverted 3 state outputs). Pins 16
       74259 8-bit addressable latches. Pins 16,   74LS259, HC259 (NeoGeo)  SOURCE: shougi.c, PCB: Dkongjr, Boggy84, MetalManiax
       74260 Dual 5-input positive NOR gates. Pins 14
       74261 2-bit by 4-bit parallel binary multipliers. Pins 16
       74265 Quad complementary output elements. Pins 16
       74266 Quad 2-input exclusive NOR gates with open-collector outputs. Pins 14
       74270 2048-bit read-only-memories (open-collector outputs, 512 x 4-bit words). Pins 16
       74271 2048-bit read-only-memories (open-collector outputs, 256 x 8-bit words). Pins 20
       74273 Octal d-type flip-flops (common clock, single rail outputs). Pins 20,  74LS273, 74LS273NA, 74HC273N,  LS273 (The LS273 is a Octal +ve edge trigger D-type flip-flop with Reset; SOURCE: machine\ajax.c)
       74274 4-bit by 4-bit binary multipliers. Pins 20
       74275 7-bit slice wallace trees. Pins 16
       74276 Quad J-/K flip-flops (seperate clocks, edge-triggering, common direct clear and preset). Pins 20
       74278 4-bit cascadable priority registers. Pins 14
       74279 Quad /S./R latches. Pins 16
       74280 9-bit odd/even parity generators/checkers. Pins 14
       74281 4-bit parallel binary accumulators. Pins 24
       74283 4-bit binary full adder. Pins 16,  74LS283
       74284 4-bit by 4-bit parallel binary multipliers used with '285. Pins 16
       74285 4-bit by 4-bit parallel binary multipliers used with '284. Pins 16
       74287 1024-bit programmable read-only-memories (256 bytes, 256 x 4). DIP 16 / PLCC20,  74S287  (Soccer, Sprint1, Skyraid), DM74S287AN
       74288 256-bit programmable read-only-memories (32 bytes, 32 x 8, bipolar PROM). DIP 16,  74S288, DM74S288N (Spaceg)
       74289 64-bit random-acces-memories (16 x 4-bit words, open collector outputs). Pins 16
       74290 Decade counters (divide-by-two and divide-by-five). Pins 14
       74292 Programmable frequency dividers/digital timers (digitally programmable from 2^2 to 2^31). Pins 16
       74293 4-bit binary counters (divide-by-two and divide-by-eight). Pins 14
       74294 Programmable frequency dividers/digital timers (digitally programmable from 2^2 to 2^15). Pins 16
       74295 4-bit bidirectional universal shift registers. Pins 14
       74297 Digital phase-locked-loop filters (cascadable for higher-order loops). Pins 16
       74298 Quad 2-input multiplexers with storage. Pins 16
       74299 8-bit bidirectional universal shift/storage registers (3 state outputs). Pins 20
       74301 256-bit random-access-memories (256 1-bit words, open collector outputs). Pins 16,  SN74S301N
       74317 256-bit random-access-memories with open-collector outputs (64 x 4-bit words). Pins 20
       74318 256-bit random-access-memories with open-collector outputs (32 x 8-bit words). Pins 20
       74319 64-bit random-access-memories (16 x 4-bit words, open-collector outputs). Pins 16
       74320 Crystal controlled oscillators. Pins 16
       74321 Crystal controlled oscillators (with F/2 and F/4 count-down outputs). Pins 16
       74322 8-bit shift registers with sign extend (3-state outputs, multiplexed I/O). Pins 20
       74323 8-bit bidirectional shift/storage registers (3 state outputs). Pins 20
       74324 Voltage Controlled Oscillator. Pins 14
       74347 BCD to seven-segment decoders/drivers (open-collector outputs, low voltage version of 'LS47). Pins 16
       74348 8-Line to 3-line priority encoders (3 state outputs). Pins 16
       74351 Dual 8-line to 1-line data selectors/multiplexers (3 state outputs, four common data inputs). Pins 20
       74352 Dual 4-line to 1-line data selectors/multiplexers (inverting version of 'LS153). Pins 16
       74353 Dual 4-line to 1-line data selectors/multiplexers (3 state outputs,inverting version of 'LS253). Pins 16
       74354 8-line to 1-line data selectors/multiplexers/transparent registers (3 state outputs). Pins 20
       74355 8-Line to 1-line data selectors/multiplexers/transparent registers (open-collector outputs). Pins 20
       74356 8-Line to 1-line data selectors/multiplexers/edge-triggered registers (3 state outputs). Pins 20
       74357 8-Line to 1-line data selectors/multiplexers/edge-triggered registers (open-collector outputs). Pins 20
       74365 Hex bus drivers (non-inverted 3-state outputs, gated enable inputs). Pins 16
       74366 Hex bus drivers (inverted 3-state outputs, gated enable inputs). Pins 16
       74367 Hex bus drivers (non-inverted 3-state outputs organised to facilitate handling of 4-bit data). Pins 16,  74LS367, DM74LS367N
       74368 Hex bus drivers (inverted 3-state outputs organised to facilitate handling of 4-bit data). Pins 16,  74LS368
       74370 2048-bit read-only-memories (512 x 4-bit words, 3-state outputs). Pins 16
       74371 2048-bit read-only-memories (256 x 8-bit words, 3-state outputs). Pins 20
       74373 Octal d-type latches (3-state outputs, common output control, common enable). Pins 20,  74LS373N, SN74ALS373
       74374 Octal d-type flip-flops (3-state outputs, common output control, common clock). Pins 20,   74LS374N, 74L374, 74S374N, 74HCT374, SN74ALS374
       74375 4-bit bistable latches. Pins 16
       74376 Quad J-/K flip-flops (common clock, common clear). Pins 16
       74377 Octal d-type flip-flops (single rail outputs, common enable, common clock). Pins 20,  74LS377
       74378 Hex d-type flip-flops (single rail outputs, common enable, common clock). Pins 16
       74379 Quad d-type flip-flops (single rail outputs, common enable, common clock). Pins 16
       74381 Arithmetic logic units/function generators (8 binary functions, use 'S182 for look-ahead carry). Pins 20
       74382 Arithmetic logic units/function generators (ripple carry and overflow outputs). Pins 20
       74384 8-bit by 1-bit two's-complement multipliers. Pins 16, NOTES: The 74ls384 is a serial subtractor - multiplier - accumulator. For the full calculation 33 GMCLK pulses are generated. The calculation performed is: ACC = ACC + (A - B) * C, SOURCE: machine\starwars.c
       74385 Quad serial adders/subtractors. Pins 20
       74386 Quad 2-input exclusive-OR gates. Pins 14
       74390 Dual decade counters (bi-quinary or bcd sequences). Pins 16
       74393 Dual 4-bit binary counters. Pins 14,  74LS393
       74395 4-bit universal shift registers (3-state outputs). Pins 16
       74396 Octal storage registers (parallel access). Pins 16
       74398 Quad 2-input multiplexers with storage (double-rail outputs). Pins 20
       74399 Quad 2-input multiplexers with storage. Pins 16
       74412 Multi-mode buffered 8-bit latches (3-state outputs, direct clear). Pins 24
       74422 Re-triggerable monostable multivibrators (internal timing resistor). Pins 14
       74423 Re-triggerable monostable multivibrators. Pins 16
       74425 Quad gates (3-state outputs, active-low enabling). Pins 14
       74426 Quad gates (3-state outputs, active-high enabling). Pins 14
       74428 System controller for 8080A. Pins 28
       74436 Line driver/memory driver circuits - MOS memory interface. Pins 16
       74437 Line driver/memory driver circuits - MOS memory interface. Pins 16
       74438 System controller for 8080A. Pins 28
       74440 Quad tridirectional bus transceivers (open-collector outputs, non-inverted logic). Pins 20
       74441 Quad tridirectional bus transceivers (open-collector outputs, inverted logic). Pins 20
       74442 Quad tridirectional bus transceivers (3-state outputs, non-inverted logic). Pins 20
       74443 Quad tridirectional bus transceivers (3-state outputs, inverted logic). Pins 20
       74444 Quad tridirectional bus transceivers (3-state outputs, inverted and non-inverted logic). Pins 20
       74445 BCD-to-decimal decoders/drivers. Pins 16
       74446 Quad bus tranceivers with direction controls (3-state outputs). Pins 16
       74447 BCD-to-seven-segment decoders/drivers (low-voltage version of 'LS247). Pins 16
       74448 Quad tridirectional bus transceivers (open-collector outputs, inverted and non-inverted logic). Pins 20
       74449 Quad bus tranceivers with direction controls (3-state outputs). Pins 16
       74465 Octal buffers with 3-state outputs (true outputs). Pins 20
       74466 Octal buffers with 3-state outputs (inverted outputs). Pins 20
       74467 Octal buffers with 3-state outputs (true outputs). Pins 20
       74468 Octal buffers with 3-state outputs (inverted outputs). Pins 20
       74471 Programmable read-only-memory (256 bytes). 74S471, SN74S471N
       74472 4096-bit programmable read-only-memories (512 bytes, 512 x 8). DIP20,  74S472 (Guardian)
       74474 4096-bit programmable read-only-memories (512 bytes, 512 x 8). DIP24,  74S474 (Sidetrac)
       74476 4096-bit programmable read-only-memories (1024 bytes, 1024 x 4). 74S476 (Dribling, Superbug)
       74481 4-bit slice cascadable processor elements. Pins 48
       74482 4-bit slice cascadable control elements. Pins 20
       74484 BCD-to-binary code converter. Pins 20
       74485 Binary-to-BCD code converter. Pins 20
       74490 Dual decade counters. Pins 16
       74505      ?                         DM74505N (Dwarfd)
       74516 4096-bit programmable read-only-memories (512 bytes, 512 x 8). 74S516, SN74S516 (Tx1)
       74518 8-bit magnitude comparator (input pull-up resistor, open-collector output). Pins 20
       74519 8-bit magnitude comparator (open-collector output). Pins 20
       74520 8-bit magnitude comparator (input pull-up resistor, inverted totem-pole output). Pins 20
       74521 8-bit magnitude comparator (inverted totem-pole output). Pins 20
       74522 8-bit magnitude comparator (input pull-up resistor, inverted open-collector output). Pins 20
       74533 Octal d-type transparent latches (3-state buffer-type outputs). Pins 20
       74534 Octal d-type edge-triggered flip-flops (3-state buffer-type outputs). Pins 20
       74538 3 to 8 line decoders/demultiplexers (3-state outputs, output parity control). Pins 20
       74539 2 to 4 line decoders/demultiplexers (3-state outputs, output parity control). Pins 20
       74540 Octal buffers and line drivers (inverted data output). Pins 20
       74541 Octal buffers and line drivers (tru data output). Pins 20,   DM74ALS541
       74560 Synchronous 4-bit counters (decade, sync and async clear). Pins 20
       74561 Synchronous 4-bit counters (binary, sync and async clear). Pins 20
       74563 Octal d-type transparent latches (inverted outputs). Pins 20
       74564 Octal d-type edge-triggered flip-flops (inverted outputs). Pins 20
       74568 Synchronous 4-bit up/down counters (decade, sync and async clear). Pins 20
       74569 Synchronous 4-bit up/down counters (binary, sync and async clear). Pins 20
       74571 2048-bit programmable read-only-memories (512 bytes, 512 x 4). PLCC20,   74S571 (Dodgem, Sprint1)
       74572 4096-bit programmable read-only-memories (1024 bytes, 1024 x 4). DIP18,   74S572 (Vangrd2)
       74573 Octal d-type transparent latches (functionally equivalent to 'LS373 & 'S373). Pins 20,   74HC573
       74574 Octal d-type edge-triggered flip-flops (functionally equivalent to 'LS374 & 'S374). Pins 20
       74575 Octal d-type edge-triggered flip-flops (non-inverted outputs). Pins 24
       74576 Octal d-type edge-triggered flip-flops (inverted outputs). Pins 20
       74577 Octal d-type edge-triggered flip-flops (inverted outputs, synchronous clear). Pins 24




       WIP:

       7474
       - 0.101              : Aaron Giles added save state support to the 7474 TTL.
       -  6th July      2002: Zsolt Vasvari fixed the missing sound in Mr. Kougar (7474).
       - 0.37b15            : Added machine\7474.c.
       - NOTES: TTL7474 is apositive-edge-triggered D-type flip-flop with preset, clear and complementary outputs.
       - SOURCE: emu\machine\7474.c
       - GAMES: Car Polo (Exidy 1977), Mr. Kougar (ATW 1984)

       7492
       - 0.94u5             : Derrick Renaud updated firetrk, montecar and superbug to use new 7492 counter. Changed adjusters so frequency goes higher when adjusted to the right.
       - NOTES: The TTL7492 is a 4-bit asynchronous divide-by-twelve counter with /2 and /6 sections and reset. Pins 14
       - SOURCE: sound\discrete.h

       74123/LS123
       - 0.115u2            : New 74123 timer emulator [Zsolt Vasvari]. It supports different ways a 74123 can be hooked up that affect the timing period. The old implementation was incorrect in lots of respects.
       - 0.88               : Derrick Renaud added a macro that calculates the pulse time of a 74LS123 or LS123. TIME_OF_74LS123(r,c) - r is in Ohms and c is in Farads. c must be greater then 1000pF to use this function
       - 25th January   2002: Aaron Giles fixed some problems with the 74123 emulator that appeared with the timer changes.
       - NOTES: The TTL74123 is a monoflop, there are 2 monoflops per chips (see machine\74123.c)
       - SOURCE: emu\machine\74123.c
       - GAMES: Sound in Sheriff (Nintendo 1980)

       74148
       - 0.61               : Added machine\74148.c
       - 20th June      2002: Zsolt Vasvari added emulation for a 74148 chip which will be needed for proper emulation of Car Polo.
       - NOTES: TTL74148 is a 8-line-to-3-line priority encoder
       - SOURCE: emu\machine\74148.c
       - GAMES: Car Polo (Exidy 1977)

       74153
       - 0.61               : Added machine\74153.c
       - NOTES: Dual 4-line to 1-line data selectors/multiplexers
       - SOURCE: emu\machine\74153.c
       - GAMES: Car Polo (Exidy 1977)

       74181
       - 0.103u1: Major cleanup/rewrite of the Berzerk driver [smf]: Merged memory & io read/write maps. Video ram & magic ram share the same memory. Hooked up nvram in frenzy memory map. Emulates magic ram shifter/flopper with 9 74LS153's as per the schematics. Emulates magic ram alu with 2 74LS181's hardwired to logic mode as per the schematics. 74LS181 emulation based on the logic diagram from the datasheet, supporting logic mode & arithmetic mode.
       - NOTES: TTL74181 is a 4-bit arithmetic Logic Unit 
       - SOURCE: emu\machine\74181.c
       - GAMES: Berzerk (Stern 1980), Frenzy (Stern 1982)

       74624
       - 0.122u2: Added discrete 74LS624(56789) implementation [Couriersud]: DISCRETE_74LS624 is a VCO needed for dkongjr. Supports Logic, Energy and Count outputs.




O1.2   C-MOS (LOC - MOS)

       4001 Quad 2-input NOR gates. Pins 14
       4006 Dual 4-bit and dual 5-bit serial-in serial-out shift registers. Pins 14 -> audio\phoenix.c, CD4006BE (Invaders), CD4006CN (Ozmawars)
       4011 Quad 2-input NAND gates. Pins 14
       4015 Dual 4-bit shift registers. Pins 16
       4017 Synchronous decimal counters/dividers. Pins 16
       4024 Asynchronous 7-bit Dual counter. Pins 14
       4028 8 - 4 - 2 - 1 - BCD/Decimal decoder. Pins 16
       4030 Quad exclusive OR gates. Pins 14
       4040 12-Stage Binary Ripple Counter;  Philips HCF4040, 74HC4040 (Chameleon 24-in-1, Unknown Sega, Sega-System24)
       4042 4-bit Auffang register. Pins 16
       4047 Monostable / astable multivibrator. Pins 14
       4049 6x inverted drivers. Pins 16
       4066 Switch
       4071 Quad 2-input OR gates. Pins 14
       4076 Quad d-type flip-flops. Pins 16
       4081 Quad 2-input AND gates. Pins 14; HEF4081BP
       4093 Quad 2-input NAND with schmitt-trigger inputs, DIP14; ST-Microelectronics HCF4093BE (Draw Poker Hi-Lo)
       4511 8 - 4 - 2 - 1 - BCD / 7-segment decoder. Pins 16
       4512 8-line multiplexer. Pins 16
       4520 Hitachi HD14520 Dual Up Counter, DIP16 (Champbwl)
       4528 Dual monostable multivibrators. Pins 16
       4539 Dual addressable 4-bit multiplexer. Pins 16



       NOTES:

       4001
       - PCB: CD4001BE (Unknown)

       4066
       - NOTES: The sound output in Fantasy (SNK 1981) is switched on/off by a 4066 IC.
       - NOTES: The polynome output bit for noise sound in Phoenix etc. is used to gate bits 6 + 7 of sound latch A through the upper half of a 4066 chip. Bit 6 is sweeping a capacitor between 0V and 4.7V while bit 7 is connected directly to the 4066 (see audio\pleiads.c).
       - SOURCE: sound\discrete.h  (DISC_CD4066_THRESHOLD)
       - SOURCE: audio\ataridis.c, geebee.c, pleiads.c rockola.c and spiders.c
       - PCB: TC4066 (Fantasy), 4066 (Buckrog, Naughtyb, Spaceg, Tripool), CD4066BCN (Unknown Alpha Denshi board)

       4098
       - PCB: CD4098BE (Murogem), 

       4528
       - PCB: CD4528BCN  (Unknown)



O1.3   Others

       DS0026    National Semi. DS0026CG, DS0026CN   Dual High-Speed MOS Driver, 5 MHz Two Phase MOS Clock Driver
       TC428     TC428CPA                            Dual CMOS High-speed Driver (Skattv)
       N8T26     N8T26AN                             Quad Bus-Line Transceiver       (Unkmeyco)
       N8T245    N8T245N                             ?= 74245 Octal bus tranceivers  (Strvmstr)
       3214      Mitsubishi M53214P                  Inverting-Function Schmitt Trigger (Headoni)
       3245      MC3245L                             Clock Driver  (Invaders)
       3417      Motorola MC3417L                    Continuously Variable Slope Delta Modulator              (Showdown)
       3418      Motorola MC3418L                    Continuously Variable Slope Delta Modulator/DE-Modulator (Showdown)
       3674      DS3674N                             Clock Driver   (Ozmawars)
       5801      Allegro MicroSystems UCN5801A       BiMOS II latched drivers        (Gotcha, Pasha2)
       6345      NEC uPD6345                         Serial 8-bit Shift Register IC, SOIC16 (NamcoSystem12)
       6914      AN6914                              Dual Comparators                (Hcrash)
       8226      Mitsubishi M5L8226P                 4 Bit Parallel Bidirectional Bus Drivers (R2dtank)
       8990      Mitsubishi M58990P                  8-Bit 8-Channel MUX-Input Binary-Output A-D Converter (LockOn)
       10124     Hitachi HD10124                     TTL-DTL-Input Level Translator - AND/NAND  (Yachtsman)
       14175     Motorola MC14175 (=74175)           Quad Type D-type Flip-Flop      (Buckrog)
       40174     ST Microelectronics HCF40174BE      Hex d-type flip-flops           (Unknown board)  


O1.4   Logic Gates



       GATE                        FUNCTION                  IC        Examples (A1, A2 = data input; x = output)


       AND   = AND                 x = a * b                 7408      A1 = 0, A2 = 1  => x = 0  ,   A1 = 1, A2 = 1  => x = 1

       OR    = OR                  x = a + b                 7432      A1 = 0, A2 = 1  => x = 1  ,   A1 = 1, A2 = 1  => x = 1
                                       _
       NOT   = INVERT              x = a                     7450      A1 = 0  => x = 1  ,  A1 = 1  => x = 0
                                       _______
       NAND  = NOT AND             x = (a * b)               7400      A1 = 0, A2 = 1  => x = 1  ,   A1 = 1, A2 = 1  => x = 0
                                       _______
       NOR   = NOT OR              x = (a + b)               7402      A1 = 0, A2 = 1  => x = 0  ,   A1 = 1, A2 = 1  => x = 0
                                        _             _
       XOR   = Exclusive OR        x = (a * b) + (a * b)     7486      A1 = 0, A2 = 1  => x = 1  ,   A1 = 1, A2 = 1  => x = 0
                                        _   _
       XNOR  = Exclusive NOR       x = (a * b) + (a * b)     74266     A1 = 0, A2 = 1  => x = 0  ,   A1 = 1, A2 = 1  => x = 1




O2.    Timer & Clock ICs

O2.1   NE555
- 0.106u2            : Discrete sound updates [Derrick Renaud]: Created new DISCRETE_555_VCO1 module. This is the 555&Op-amp oscillator circuit used by Borderline.
- 0.99u6             : Discrete sound update: Fixed DSD_555_ASTBL__R2
- 0.99u2             : Derrick Renaud fixed the discrete sound 555 timer modules when using actual DC mode.
- 0.89               : Discrete Sound Update [Derrick Renaud]. Added new Discrete Modules: DISCRETE_555_ASTABL has been modified to remove control voltage support and DISCRETE_555_ASTABL_CV has been added if control voltage is used.
- 0.88u2             : Derrick Renaud added to DISCRETE_555_ASTABLE an option to use quick charge diode (will be needed for Frogs) and an option to disable oscillation if R1 (charge) is out of circuit (will be needed by Invaders). Modified DISCRETE_555_CC to discharge cap due to natural losses if there is no charging current (needed by Frogs). This makes it more accurate then the current perfect cap that will retain a charge forever. Modified all current drivers to use new code. Added the new discrete module DISCRETE_555_MSTABLE (555 monostable simulation).
- 0.80u2             : Discrete Sound System updates [Aaron Giles, Derrick Renaud]. Aaron: * major internal cleanup and reworking of how nodes are created, fixed bug in 555 timer that led to whiny noise in Hit Me.
- 0.80               : Discrete sound updates [Derrick Renaud]: DISCRETE_555_ASTABLE - changed to use common options with DISCRETE_555_CC. New Discrete Modules Added: DISCRETE_555_CC - Constant Current based 555 VCO with 8 main configurations, that automatically configure from components used.
- 0.68               : Discrete sound system update [Keith Wilkins, Derrick Renaud and Frank Palazzolo]: DISCRETE_555_AST (555 astable generator with squarewave or cap charge out).
- SOURCE: sound\discrete.c + disc_dev.c 
- PCB: Buckrog, Fantasy, Mrjong, Vsgongf, Crballon - bit 6 sound related (to 555), Ckong - 555 timer chip hacked directly to the board for a "speed control" feature - turn the pot to change the game's speed, Poker2 - sound probably discrete with ne555 timer chip (located near amp/volume control)
- PCB: 555 (Buckrog), NE555 (Headoni, Suprridr), NE555P (Mtrap, Pangofun, Spacefrt), NEC uPD555 (11beat, Mtetrisc)


O2.2   NE556
- NOTES: audio\firetrk.c: Siren is built around a 556 based VCO, the 4 bit input value is smoothed between transitions by a 10u capacitor.
- PCB: 556 (Shuttlei, Naughtyb, Rockclim), NE556A (Headon2), NE556A944 (Astrof), LM556CN (Astrof)


O2.3   NE558
- PCB: NE558, SOIC16(A51site4)


O2.4   NE566
- 0.80               : Discrete sound updates [Derrick Renaud]: DISCRETE_566 - NE566 simulation.
- SOURCE: sound\discrete.c + disc_dev.c 
- NOTES: audio\asteroid.c: The slow VCO is implemented with a 555 timer and a 566 is used for the higher VCO.


O2.5   MC6840
- 0.124u1            : Philip Bennett fixed interrupt handling and 16-bit memory accessors in 6840ptm.c. Also cleaned up code for the sake of readability.
- 0.123u2            : James Wallace fixed a few corner cases in the 6840 emulation based on running the MPU4 test ROMs, and added the ability to dynamically alter the external clock frequencies in game.
- 0.122u8            : James Wallace changed 6840 interrupt handling to work like the recent 6821 changes. Updated MPU4 driver accordingly. Updated Scorpion 2 driver to match MPU4 coding style.
- 0.116u1            : Atari Ace fixed a number of errors and simplified the code significantly in the ptm6840 code.
- 0.108u3            : El Condor fixed 6840 counter behavior in continuous mode.
- 0.108u2            : El Condor tidied up the 6840 emulator a bit.
- 0.107u3            : More improvements to the 6840 timer module. Updated the MPU4 driver to the most recent implementation. Convert Cosmic Chasm over to using the new system [El Condor].
- 0.106u12           : El Condor fixed interrupt clearing function in 6840 module.
- 0.106u8            : More generic 6840 module improvements [El Condor].
- 0.106u5            : More generic 6840 improvements [El Condor].
- 0.106u1            : El Condor fixed MSB accesses and latch reading in the 6840 emulator.
- 0.105u5            : More improvements to the BFM driver and the 6840 timer emulation [El Condor].
- 0.105u4            : El Condor cleaned up 6840 implementation and revised Bellfruit Scorpion 2 driver's handling of unmapped regions. Also updated the MPU4 memory map.
- 0.103u2            : Added machine\6840ptm.c.
- NOTES: Motorola 6840 PTM (Programmable Timer Module). A 6840PTM is used for internal timing in the MPU4 boards (mpu4.c), one of it's functions is to act with an AY8913 chip as a crude DAC device.
- NOTES: Driver by El Condor based on previous work by Aaron Giles, 'Re-Animator' and Mathis Rosenhauer.
- SOURCE: emu\machine\6840ptm.c + mpu4.c
- SOURCE: machine\mcr.c + mcr68.c
- Games: Beezer (Tong Electronic 1982), Victory (Exidy 1982), Midway MCR-68k system games


O2.6   MB8873
- NOTES: The MB-8873E is a timer IC.
- Games: Ginga NinkyouDen (Jaleco 1987)


O2.7   8253
- 0.124u1            : Wilbert Pol converted the pit8253 implementation into a device. To make it easier to use I've also created a src/emu/devconv.h in the same style as src/emu/memconv.h.
- 0.102              : Mathis Rosenhauer fixed save/restore of 8253 PIT, removed shift register since it just seems to be needed to compensate for different DAC speeds, added 8254 PIT from PC emulation and added state saving.
- 0.101u2            : Added machine\pit8253.c.
- NOTES: The 8253 is a programmable interval timer chip.
- GAMES: Victory (Exidy 1982), Clay Shoot (Allied Leisure 1979), balsente.c, exidy.c
- SOURCE: emu\machine\pit8253.c
- PCB: NB5K8253 (LaserBase)


O2.8   8254
- 0.124u2            : Wilbert Pol removed the hardcoded dependency on a 8254 device from the 8042kbdc code. Changed the drivers using the 8042kdbc to define their own 8042kdbc - 8254 dependency.
- 0.101u3            : Removed machine\8254pit.c
- NOTES: The 8254 is a programmable interval timer chip. Different to 8253: The 8254 has an additional readback feature.
- SOURCE: machine\pit8253.c


O2.9   NEC D71054
- NOTES: The NEC D71054 is a timer chip (timer write handle, MACHINE_INIT and other functions)
- PCB: D71054C (Wrofaero)
- SOURCE: drivers\seta.c


O2.A   MC146818
- 0.110u2            : Nathan Woods updated MC146818 module to use new core date/time routines.
- 0.101u2            : Added machine\mc146818.c. Implementation of the MC146818 [Nathan Woods, Peter Trauner].
- NOTES: Real time clock chip with battery buffered ram (or CMOS). Used in IBM PC/AT, several PC clones, Amstrad NC200. PC CMOS info (based on info from Padgett Peterson).
- GAMES: Atari MediaGX and Taito Wolf System (drivers\mediagx.c + taitowlf.c)
- SOURCE: emu\machine\mc146818.c




O3.    RTC (Real Time Clock)


O3.1   DALLAS

O3.11  DS1221
- NOTES: The DALLAS DS1221 chip preserved Time and date.
- PCB: Ataxx

O3.12  DS1302
- 0.90               : Added DALLAS DS1302 emulation [ElSemi].
- NOTES: RTC+BACKUP RAM
- SOURCE: emu\machine\ds1302.c
- PCB: Dallas DS1302, DIP8 (Crysking)

O3.13  DS1643
- NOTES: NonVolatile TimeKeeping RAM
- PCB: DALLAS DS1643 (Heatof11)

O3.14  DS2401
- 0.124u1           : smf fixed DS2401 state loading now that the digital i/o board's serial number has been changed to a const by not saving it. As the serial number cannot be changed at run time it was rather pointless.
- 0.112u3           : smf added DS2401 emulation (Konami System 573).
- SOURCE: emu\machine\ds2401.c

O3.15  DS2404
- 0.81u7             : Ville Linde added preliminary Dallas DS2404 (RTC/CMOS) emulation to the Seibu SPI system.
- NOTES: RTC + NVRAM
- SOURCE: emu\machine\ds2404.c
- PCB: Dallas DS2404S EconoRAM Time Chip, SOIC16 (Rfjet, Ejanhs)

O3.16  DS17487
- PCB: Hitpocker - DALLAS REAL TIME CLK DS17487-5



O3.2   Epson

O3.21  3520
- PCB: Seiko Epson S-3520 Real Time Clock, SOIC14 (NintendoSuperSystem)

O3.22  4543
- PCB: EPSON R4543 Real Time Clock Module, SOIC14 (Gp500, NamcoSystem12, NamcoSystem23)

O3.23  62423
- PCB: EPSON RTC62423, SOP24 (NeoGeoHyper64)

O3.24  65271
- 0.110u5: Added Epson RTC65271 emulation [Raphael Nabet].
- GAMES: Konami FireBeat System
- SOURCE: emu\machine\rtc65271.c

O3.25  72421
- 0.90u2: Ville Linde added Epson RTC-72421 emulation
- NOTES: 4-bit RTC-Modul 10ppm
- PCB: RTC 72421B   4382, DIL18 (Ddenlovr)

O3.26  72423
- PCB: RTC72423 (Harley, SegaModel3)





O3.3   Motorola

O3.31  MPC948
- PCB: The Motorola MPC948 is a low voltage clock chip (Gauntleg, Gauntdl).

O3.32  MPC950
- PCB: MPC950, QFP32  (Harley)


O3.4   NEC

O3.41  PD4990
- 0.104u6            : Xvi added save state support to PD4990a device for NeoGeo.
- 0.34b1: NEC PD4990A support.
- NOTES: The NEC PD4990A is a serial I/O Calendar & Clock IC used in the NEO GEO and probably a couple of other machines.
- SOURCE: emu\machine\pd4990a.c
- PCB: D4990A (NeoGeo)


O3.5   OKI

O3.51  6242
- 0.124u5            : Dirk Best converted the MSM6242 RTC into a proper device. 
- 0.118u1            : MSM6242 updates [Ernesto Corvi]: Added support for 12/24 hour mode. Added support for the HOLD bit.
- 0.111u1            : Luca Elia moved MSM6242 real time clock to its own file.
- GAMES: drivers\ddenlovr.c, dynax.c, realbrk.c, royalmah.c and suprnova.c
- SOURCE: emu\machine\msm6242.c
- PCB: REAL TIME CLOCK MSM6242 (Hanakanz), RTC M6242B (Pkgnsh, Quizchq, Yarunara), M62X42B (Meosism), M62X42 (suprnova.c), 6242 (Mmpanic), OKIM62X42B (Skattv)


O3.6   Other

O3.61  8521
- SOURCE: TC8521AP (RTC?)
- PCB: 8521 (Sonofphx)

O3.62  V3021
- PCB: EM Microelectronic-Marin SA Ultra Low Power 32kHz CMOS V3021 Real Time Clock, DIP8 (PGM-System)



O4.    Key chip
-  3rd March 2000: Vernon C. Brooks fixed some key chip problems with World Stadium.




O5.    Clock


O5.1   Crystal
- 0.123u2            : Corrado Tomaselli reverted sound OSC of Truxton II to 27mhz/8 since the original OST runs at this speed. The PCB I measured the previous clock was 28mhz/8 and it's a different PCB version from the common one. Since MAME doesn't support multiple OSC I prefer to use the 27mhz one.
- 0.122u3            : Added new file xtal.h, documenting all known arcade PCB clock cystals. Drivers should be updated to use these as a basis for their clocks, and the list should be augmented as additional crystals are found [Guru, Aaron Giles].
- SOURCE: emu\drivers\xtal.h

       Clock Crystal = Xtal = Oscillator = OSC = X1, X2 or X101

       12098                    (Sprint1)
       169NDK19                 (Kdynastg, Xfiles)
       A33.868 KDS 7M           (NeoGeo Hyper64)
       A40.000 KDS 7L           (NeoGeo Hyper64)
       CSB455E                  (Passsht)
       D180A7                   (Heatof11)
       D320L7                   (NeoGeo Hyper64)
       K SSJ1                   (Boggy84)
       M33.333 KDS 7M, KDS7M    (NeoGeo Hyper64, A51site4)
       M50.113 KDS 7L           (NeoGeo Hyper64)
       M53.693 KDS 745          (Soulclbr)
       M53.693 KDS 920          (Aquarush)
       MEC18432 = 18432.00 KHz  (Chewing, Circusc, StarFigh)
       M.S.C.                   (Horekid)
       Nymph C016018            (Darktowr, Tstrike)
       POE400B (blue crystal)   (Pspikes)
       RXD MP-18                (Horekid)
       TI 75175, DIP8           (Janjans2)
       V100.00 KDS 745          (Soulclbr)
       V100.00 KDS 928          (Aquarush)



O5.11  Crystal Resonator

       CSB380E               (Ddragon)
       CSB398P               (Goldnaxe)
       CSB480E               (Ddragon)
       CSB1056J              (Dbz2)

       1000J-S               (Hrdtimes)

       POE400B               (Mastboy, Pspikes)


O5.2   Cypress

O5.21  CY2291
- NOTES: The CY2291 is the clock input source for the R4650 in Gp500.
- PCB: Cypress CY2291 Three-PLL General Purpose EPROM Programmable Clock Generator - SOIC20 (Gp500)

O5.22  CY2292
- NOTES: Port names: XTALIN, XTALOUT, XBUF, CPUCLK, CLKA, CLKB, CLKC and CLKD
- PCB: Cypress CY2292S Three-PLL General-Purpose EPROM Programmable Clock Generator, SOIC16 (Polystar)



O5.5   ICS

O5.51  9120
- PCB: ICS9120, SOIC8 (A51site4)

O5.52  9170
- PCB: Integrated Circuit Systems Inc. AV9170 Clock Synchronizer and Multiplier, Voltage Controlled Oscillator, SOIC8 (Gradius4, Sscope2, NamcoSystem11/12)

O5.53  9159
- PCB: ICS9159M 9743-14, SOIC28 (A51site4)



O5.6   Others

O5.61  8224
- NOTES: 8224 clock divider chip
- PCB: 8224 (Konek), MPB8224C (Fastdraw), iP8224 (Draw Poker Hi-Lo)

O5.62  8284
- PCB: AMD D8284A  Clock Generator Driver for I8068/88 (Mplanets)

O5.63  2061ASC
- PCB: IC Designs 2061ASC-1 Programmable Clock Generator, SOIC16 (Gp500, NamcoSystem11/12)

O5.64  MX8330
- PCB: Macronix MX8330 RAMBUS Clock Generator (Mtetrisc)

O5.65  MC88915
- PCB: MC88915FN70 Single Low Skew CMOS Clock PLL Driver






O6.    Reset IC

O6.1   Dallas

O6.11  DS1232
- PCB: Dallas DS1232S reset IC, SOIC16 (Primrag2), DS1232, SOIC8 (A51site4), DS1232 DIP8 (RapidFire), DALLAS DS1232 MicroMonitor ? (MetalManiax)

O6.12  DS1233
- PCB: Dallas DS1233 master reset IC, SOIC4 (Crysking)


O6.2   Mitsubishi, NEC

O6.21  PST518
- PCB: Mineswpr

O6.22  PST532
- NOTES: PST532 IC for system reset and battery backup switching (Realbrk)
- PCB: PST532A (Realbrk, Pkgnsh)

O6.23  PST573
- PCB: PST573D System Reset IC with 2.7V detection circuit, SOIC4 (Gamshara)

O6.24  PST575
- PCB: System Reset IC, SOIC4 (Gp500, NamcoSystem23)

O6.25  PST592
- PCB: PST592J System Reset IC with 2.7V detection circuit, SOIC4  (Gamshara, MrDriller2)

O6.26  M51953
- PCB: Mitsubishi Electric Corp. M51953B or M5195B Voltage Detection and System Reset IC, SIP5 (CPS2)



O6.3   Maxim

O6.31  MAX690
- PCB: MAX690 CPA (Dynobop)

O6.32  MAX691
- PCB: MAX691CPE Reset IC with Watchdog and Battery switchover (Skattv)

O6.33  MAX693
- PCB: Maxim max693acwe Watchdog  (Blitz99, MK3)



O6.4   Mitsumi

O6.41  MM1026
- PCB: Mitsumi Monolithic IC MM1026BF System Reset with Battery Backup, SOIC8 (NintendoSuperSystem)

O6.42  MM1035
- PCB: Mitsumi Monolithic IC MM1035 System Reset and Watchdog Timer, DIP8 (Vmetal, Gunmast)


O6.5   Texas Instruments

O6.51  TL7700
- PCB: Texas Instruments TL7700 Supply-Voltage Supervisor/Power-On Reset IC, DIP8 (Tokio)

O6.52  TL7705
- PCB: TL7705 (Armchmp2, Klondkp, Ppcar, Pasha2), ST7705C Reset/Watchdog IC, SOIC8 (Xfiles, Kdynastg), TL7705ACP Supply-Voltage Supervisor (Skattv)



O6.6   Other

O6.61  ADM690
- PCB: Analog Devices ADM690 4.65V Reset, Battery Switchover, Watchdog Timer, Power Fail Input IC, DIP8 (Pairs)

O6.62  HA16103
- PCB: Hitachi HA16103FPJ Watchdog Timer, SOIC20 (CPS-3)



O7.    Voltage regulator

O7.1   7660
- PCB: DC-DC Voltage Convertor, SOIC8 (Ppcar)

O7.2   7808
- PCB: Voltage regulator for TV output (Chboxing, Chwrestl)

O7.3   7812
- PCB: 12V voltage regulator (Model1)

O7.4   PQ30RV21
- PCB: Sharp PQ30RV21, PQ30RV31 5V to 3.3V Voltage Regulator (NamcoSystem10, NamcoSystem12)

O7.5   3423
- PCB: Motorola MC3423 Overvoltage Sensing Circuit, SOIC8 (Pairs)

O7.6   LT1084
- PCB: Linear Technology LT1084 Low Dropout/Fixed Positive Adjustable Voltage Regulators (Mtetrisc)



O8.    Switch

O8.1   S301
- PCB: Slide switch for stereo or mono sound output (Rvschool, Sfex2, Taito GNET system).

O8.2   S551
- PCB: Dip switch - 4 position, defaults all OFF (Rvschool, Sfex2, Taito GNET system).



O9.    Diodes

O9.1   4148
- PCB: Standard diode 1N4148 (Wallc)

O9.2   Laser Disc diode
- PCB: Cliff Hanger uses the PR-8210 player and I have heard that it can also run on the LD-V1100 with an infrared transmitter (which only consists of two diodes and two resistors). (CliffHanger)



O10.    Capacitor
- NOTES: A capacitor is an electrical/electronic device that can store energy in the electric field between a pair of conductors (called "plates").
- PCB: 2621N (Laserbat)


O11.    Debug Mode

       - Debugger ROM (extra): Atari - Sprint1/2+Dominis, Wolfpack
       - "Unused" Dip Switch: Time Soldiers - Make the ROM writable and the game will enter a 'debug' (probably from the development system).
       - Edge-connector testpin: Mjyuugi
       - Debug port: Gladiator,    Spacefb: Port 3  bit 6 = unused (Debug switch - Code jumps to $3800 on reset if on)
       - RS232 port for debug: F15se
       - Debug Mode dipswitch: Seicross, Jungler, Gun.Smoke, Stinger, Kuri Kinton, Image Fight
       - Debug features: CPS1 games
       - CPU debug switch: Beathead (ASAP CPU)



O12.    BIOS

        Arcade Systems with BIOS (Basic Input Output System):

        Acclaim                     Acclaim PSX (acpsx)
        Arcadia Systems             Arcadia System BIOS (ar_bios)
        Atari                       Atari PSX (atpsx)
        Brezzasoft                  Crystal System BIOS (crysbios)   MX27L1000QC-12 128k x8 EEPROM (BIOS DATA)
        Century Electronics         CVS Bios (cvs)
        Century Electronics         Quadtel TVGA9000i BIOS Software (Paint & Puzzle (1993?))
        Data East                   DECO Cassette System (decocass)
        Exidy                       Max-A-Flex (maxaflex)
        I'Max                       Multi Amenity Cassette System BIOS (macsbios)
        IGS                         PGM (Polygame Master) System BIOS (pgm)
        Kaneko                      Super Kaneko Nova System BIOS (skns)
        Konami                      Baby Phoenix/GV System (konamigv)
        Konami                      System GX (konamigx)
        Namco                       Namco NA-1/2 System     SOURCE: dricers\namcona1.c
        Namco                       Namco System 2          NSY2BIOS, SYS2C65C, SYS2C68 (BIOS DATA)     SOURCE: dricers\namcos2
        Nintendo                    Nintendo Super System BIOS (nss),  NSS-ic14-02 is BIOS rom
        Nintendo of America         PlayChoice-10 BIOS (playch10)
        Sega                        Mega Play BIOS (megaplay)
        Sega                        Mega-Tech BIOS (megatech)
        Sega                        ST-V Bios (stvbios)
        Sega                        Sega System 24
        SNK                         Hyper NeoGeo 64 Bios (hng64)
        SNK                         Neo-Geo (neogeo)
        Sony/Atlus                  Atlus PSX (atluspsx)
        Sony/Capcom                 ZN1/2 (cpzn1/2)
        Sony/Capcom/Tecmo           NAOMI System        ST 27c160 16Mbit/16 bit (BIOS DATA)
        Sony/Eighting/Raizing       PS Arcade 95 (psarc95)
        Sony/Tecmo                  TPS (tps)
        Sony/Taito                  Taito FX1 (taitofx1)
        Taito                       Taito GNET System




O13.    Instruction Cards

        Joshi Volleyball (1983)
        G3000261A (Instruction card #1)
        G3000262A (Instruction card #2)

        Prebillian (Taito 1986)
        G2000578A (Service Instructions)       G20 00578A
        G2000577A (Board Adjustment Manual)    G20 00577A
        G3000410A (Instruction card #1)        G30 00410A
        G3000411A (Instruction card #2)        G30 00411A

        Vs. Hot Smash (Taito 1987)
        G2000686A (Service Instructions)
        G2000682A (Board Adjustment Manual)
        G3000432A (Instruction card #1)
        G3000433A (Instruction card #2)

        Twin Hawk (Taito 1989)
        G2001005A Service Instructions (Manual)
        G2001006A Game Manual
        G3000527A Instruction Card

        Hat Trick Hero (Taito 1990) - Football Champ clone
        G2001260A (Service Instruction Manual)
        G3000621A (Instruction card #1)
        G3000622A (Instruction card #2)

        Quiz Jinsei Gekijoh (Taito 1992)
        G3000703A (Instruction card 1)
        G3000704A (Instruction card 2)
        G1000996A (Instruction card 3)
        G2001472A (Instruction manual)

        Quiz Crayon Shinchan (Taito 1993)
        G3000724A (Instruction card 1)
        G3000725A (Instruction card 2)
        G2001518A (Instruction manual)

        Crayon Shinchan Orato Asobo (Taito 1993)
        G1001075A - Display Sticker
        G2001553A - Service Instruction Manual
        G3000744A - Instruction Card
        C0601012A - Electro Tap Splice




 


VIDEO / GRAFIK

  1.    Custom chips
  1.1   Atari
  1.2   Banpresto
  1.3   Capcom
  1.4   Cave
  1.5   Data East
  1.6   Dooyong
  1.7   Dynax
  1.8   Excellent Systems
  1.9   Fujitsu
  1.10  Gaelco
  1.11  IGS
  1.12  Imagetek
  1.13  Incredible Technologies
  1.14  Jaleco
  1.15  Kaneko
  1.16  Konami
  1.17  LSI Logic
  1.18  Nakanihon
  1.19  Namco
  1.20  Nanao
  1.21  NEC
  1.22  Nintendo
  1.23  NMK
  1.24  Other
  1.25  Philko
  1.26  Psikyo
  1.27  Seibu
  1.28  Sega
  1.29  Seta
  1.30  SNK
  1.31  SONY
  1.32  Subsino
  1.33  Taito
  1.34  Tecmo
  1.35  Technos
  1.36  Toaplan
  1.37  V-System

  2.    Custom Video
  2.1   Signetics
  2.11  S2636
  2.12  S2637
  2.2   Atari
  2.21  TIA
  2.22  GTIA
  2.23  ANTIC
  2.24  AMD 29C101
  2.25  ASIC65
  2.3   MOS
  2.31  MOS6560
  2.32  VIC6560
  2.4   Nintendo
  2.42  2C0X PPU
  2.5   Philips
  2.51  SAA 5020
  2.52  SAA 5050
  2.6   Blitter
  2.61  Fujitsu MB1551x
  2.62  ITV4400
  2.63  GA9201
  2.7   Collision chips
  2.71  PC3259
  2.8   TLC34076
  2.9   YGV608
  2.A   Midway ICs
  2.B   Data East Ace/Jack

  3.    2D Graphic
  3.1   VRender Zero

  4.    3D Graphic
  4.1   Polygon games
  4.2   Sprites games
  4.21  Sega 16-bit hardware
  4.22  Sega System24
  4.23  Sega System32
  4.24  Sega ST-V
  4.3   Other 3D games
  4.4   Textures games
  4.5   PSX GPU
  4.6   3dfx Voodoo Graphic
  4.61  Voodoo 2
  4.62  Voodoo Banshee
  4.63  Voodoo 3
  4.64  Voodoo chips + cards
  4.7   Gaelco 3D
  4.8   Real3D 1000
  4.9   Konami
  4.91  K001005
  4.92  K001006
  4.A   3DO
  4.B   Direct3D

  5.    Video controller
  5.1   Actel
  5.2   Altera
  5.3   Brooktree
  5.4   Cosmac
  5.5   Hitachi
  5.6   Texas Instruments
  5.8   Other
  5.9   Palette resistors

  6.    Video D/A converter
  6.1   CXD1178
  6.2   MC44200
  6.3   NPC
  6.31  SM5840
  6.32  SM5877

  7.    RGB Pre-Driver
  7.1   RES NET
  7.2   Sony
  7.21  CXA1145
  7.22  CXA1634
  7.23  CXA1779
  7.24  CXA2067
  7.3   000180

  8.    Video Display
  8.1   OKI MSC1937

..................................................................................................................................................................................................................................




G1.    Custom chips


G1.1   Atari


       137304-2002                                                 (Arcadecl)


       Slapstic chips

       137412-101              Empire Strikes Back/Tetris
       137412-103              Marble Madness
       137412-104              Gauntlet
       137412-105              Indiana Jones/Paperboy
       137412-106              Gauntlet II
       137412-107              Peter Packrat/Xybots/2p Gauntlet/720
       137412-108              Road Runner/Super Sprint
       137412-109              Championship Sprint/Road Blasters
       137412-110              Road Blasters/APB
       137412-111              Pit Fighter
       137412-112              Pit Fighter (Europe)
       137412-113              Unknown (Europe)
       137412-115              Race Drivin' DSK board
       137412-116              Hydra
       137412-117              Race Drivin'
       137412-118              Rampart/Vindicators II


       137418-103                                                  (Xybots)
       137419-101    137419-101, 137419-104                        (Cyberbal, Guardian, Primrage, Tmek, Xybots)
       137526-001                                                  (Xybots)
       137536-001                                                  (Arcadecl, Xybots)
       137550-001    SOS-137550-001 TAIWAN  20 pin Motorola        (Arcadecl, Cyberbal, Guardian, Klax, Primrage, Sparkz, Tmek)
       137552-001    VMA-137552-001                                (Cyberbal)
       137593-001    VLSI chip, labeled 8915AV U9684 VGT8001-6206  (Arcadecl, Klax)
         ????        VLSI MPG  VGT8003-2148   9027EV               (F15se, Botss)
         ????        VLSI MPG  VGT8007-2105   9027EV               (F15se, Botss)
       137665-1020   Atari                                         (Guardian)


       WIP:
       - 0.37b8: Added vidhrdw\atarian.c/h, atarimo.c/h, ataripf.c/h and atarirle.c/h (Gauntlet, Toobin, Xybots, atarisy1.c...).


G1.2   Banpresto

       IKM-AA004 1633JF8433 JAPAN 9523YAA    QFP208         (Macrossp, Quizmoon)
       IKM-AA005 1670F1541  JAPAN 9525EAI    QFP208         (Macrossp, Quizmoon)
       IKM-AA006 1633JF8432 JAPAN 9525YAA    QFP208         (Macrossp, Quizmoon)



G1.3   Capcom

       CPS2:

       DL-030P               DIP40     KABUKI      Custom encrypted Z80, running at 8.000MHz, manufactured by VLSI Technology. On most PCB's this is a regular Zilog Z80 (Z0840008PSC)
       DL-0311               QFP160    CPS-A-01    Graphics Processors
       DL-0921               QFP160    CPS-B-21    Graphics Processors
       DL-1123               QFP136                I/O Controller
       DL-1425               PLCC84    CAPCOM-Q1   Q-Sound Processor, DSP-16A (C) 92 AT&T, clock input of 60.000MHz
       DL-1525               QFP208    SPA         Custom 68000 CPU + ASIC
       DL-1625               QFP128    SPB         Custom 68000 CPU, running at 16.000MHz
       DL-1727               QFP160    MIF
       DL-1827               QFP160    CIF
       DL-1927               QFP120    CGA
       DL-2027               QFP120    CGD
       DL-2227               QFP64     DRC         DRAM Refresh Controller


       CPS3:

       DL-2729  SD10-505     QFP304    PPU
       DL-2829  SD07-1514    QFP208    CCU
       DL-2929  SD08-1513    QFP208    IOU         I/O controller
       DL-3129               QFP208    C.P.S.2-B   RF5C320 sound
       DL-3329  SD04-1536    QFP144    SSU
       DL-3429  SD06-1537    QFP144    GLL1
       DL-3529  SD11-1755    QFP80     GLL2


       PU11256, PU13478    16M MASK ROM (read as 27C160)         (Punisher)



G1.4   Cave

       9050KX016    47pie2, Suchipi                (NEC D65012GF303 9050KX016 - QFP80)


       Sprites
       013 9918EX008                         (Gaia)
       013 9341E7009                         (Mazinger)
       013 9346E7002   QFP240                (Agallet, Metmqstr, Sailormn)

       Tilemaps
       038 9320EX702   QFP176                (Nost)
       038-9320EX703   PQFP176  GFX          (Mcatadv)
       038 9320EX706   QFP176                (Naname)
       038 9330EX705   QFP176                (Nost)
       038 9335EX706                         (Mazinger)
       038 9429WX709                         (Pwrinst2)
       038 9429WX727                         (Donpachi)
       038 9437WX711   QFP176                (Agallet, Metmqstr, Sailormn)
           9807EX004   QFP240                (Dfeveron, Korokoro)
           9838EX004   QFP240                (Korokoro)
       038 9838WX001                         (Dfeveron, Gaia)
       038 9838WX003                         (Dfeveron, Gaia)
           9838WX004   QFP144                (Korokoro)



G1.5   Data East

       TC110G21     TC110G21AF (Sdgndmps, SD Gundam Sangokushi, Raiden DX)
       TC110G38     TC110G38AF (Botss, F15se)
       TC15G008     TC 15G008AP (Liberate), TC15G008AP-0048 (Cross Shooter, Metlclsh, Panic Road)
       TC15G032     TOSHIBA TC15G032CY, TC15GO32AY 0013 8623A DSPC10, TC156032AY (Counter Steer, Garyoret, Lastmisn, Metlclsh, Shootout)
       TC17G005     TC17G005AN (Cross Shooter, Panic Road)
       TC17G008     TC17G008AN (Cross Shooter, Panic Road)
       TC17G014     TC17G014AP-0048 (Mustache)
       TC17G032     DYNAX TC17G032AP-0246 JAPAN 8828EAI (Hanamai, Hana Oriduru)
       TC25SC900    TC25SC900AF (SD Gundam Sangokushi, Heated Barrel, Olympic Soccer'92)


       L7B0072      L7A0072 DATA EAST BAC 06 VAE8713 (Boulder Dash, Robo Cop, The Deep)
       L7B0073      L7B0073 DATA EAST MXC 06 8746 (Boulder Dash, Robo Cop, The Deep)


       DE45                                Hu6280 CPU         QFP80          Edrandy
       DE52   9322EV 298251 VC5259-0001    Sprites            QFP128         Rhoga, Fghthist, Nslasher, Wcvol95, 9235EV 205941  VC5259-0001 (Dblewing)
       DE55                                Background GFX     QFP160         Rhoga, Edrandy
       DE56                                GFX encryption     QFP160         Prtytime, Rhoga, Fghthist
       DE59                                M68000             QFP64          Rhoga, Mutamtf, Edrandy
       DE60                                Protection/IO                     Edrandy
       DE66                                Protection/IO      QFP100         Edrandy
       DE71   9228EV-313141                Sprites            QFP100         Rhoga
       DE74   24220F009                    GFX encryption     QFP160         Lockload, Fghthist, Nslasher
       DE75                                Protection/IO                     Captaven, Robocop2
       DE77   9303K9200                                       SOP28          Captaven, Dblewing (?)
       DE99   L7A0967  'Ace' chip          Alpha blending?    QFP208         Nslasher
       DE101                               ARM CPU                           Dragngun, Lockload
       DE102  237                          68000              QFP128         Pktgaldx
       DE104  L7A0717 9148                 Protection/IO      QFP100         Nslasher,   L7A0717  9143 (Dblewing)
       DE113                               Alpha Blending                    Lockload, Dragngun
       DE141  24220F008                    GFX encryption     QFP160         Nslasher, Wcvol95
       DE145                                                                 Lockload
       DE146  L7A0680                      Protection/IO      100 pin        Dragngun, Fghthist, Stadhr96
       DE150                               GFX controller                    Avengrgs, Skullfng
       DE153  L7A0888 9328                                    QFP144         Nslasher
       DE156  932EV 301801                 ARM CPU            QFP100         Nslasher, Wcvol95
       DE170                                ?                                Fghthist
       DE186                                ?                                Dragngun, Lockload
       DE187                                ?                                Dragngun, Lockload
       DE200  9320PD027                                       QFP100         Fghthist, Nslasher
       DE222  C10707-1                     Custom 6502                       Ghostb, Srdarwin, Oscar
       DE223                               Protection                        Avengrgs, Chainrec, Joemacr, Osman

       SOURCE: Data East protection in machine\decocrpt.c

       NOTES:
       - Custom chip 55 provides two playfields of 4bpp tiles, with optional rowscroll and column scroll. Some games use two of these to give 4 playfields. Palette banking, tile banking and priority are outside the scope of this chip, and usually differ between games. Some games combine the 4bpp output of each playfield to give an effective 8bpp display.
       - Custom chip 56 is the same as 55 but with on-chip decryption, so encrypted roms can be used.
       - Custom chip 74 is the same as 56 but with different decryption tables.
       - Custom chip 141 appears to be the same as 56.



       DECO CUSTOM CHIPS (dec8.c games)

       HMC20    DECO HMC20 M60232                (Ghostb, Gondo, Shackled, Shootout, Garyoret, Lastmisn)
       SSC10    DECO SSC10 M60324  42pin         (Boomrang, Cobracom, Kamikcab, Liberation, Shootout)
       VSC30    DECO VSC30 M60348                (Ghostb, Gondo, Shackled, Shootout, Garyoret, Lastmis)




G1.6   Dooyong

       DOOYONG           H2A11004           SCU                      Gulfstrm
       DY-2                                          PLCC44          Flytiger
       DY001     Hyundai DOOYONG DY001-A    FPGA     PLCC84          Flytiger, Gulfstrm
       DY002     Hyundai DOOYONG DY001-A    FPGA     PLCC84          Flytiger, Gulfstrm

       DOOYONG DY-OBJ-01 H2B34027                                    Popbingo
       DY208   DY-OBJ-01                                             Superx

       DOOYONG DY-PL-1   H2A16011                    QFP160          Sadari
       DOOYONG DY-PL-1   H2A32067                                    Popbingo
       DY160   DY-PL-1                                               Superx




G1.7   Dynax

       1108    Dynax 1108F0405, 1108F0406                   Mmpanic, Quizchq, Hparadis
       1427    Dynax 1427F0071                              Mmpanic, Quizchq, Hparadis
       TC17G032AP-0246 JAPAN 8828EAI                        Hanamai, Mjfriday


G1.8   Excellent Systems

       ES-9203                      Gcpinbal
       ES-9207                      Aquarium, Gcpinbal
       ES-9208                      Aquarium, Gcpinbal
       ES 9303                      Aquarium

       ES-8712     ADPCM sound      Gcpinbal, Vmetal




G1.9   Fujitsu

       CG10103 145 9520 Z14             Sprite           QFP160            Gstriker, Suprslam, Vgoalsoc
       CG24143 4181 9449 Z01            square SMD       QFP208            Jchan, Galpani3
       CG24173 6186 9447 Z01            square SMD       QFP208            Jchan, Galpani3

       MB605E53U or MB60553             Tilemap                            Gstriker, Vgoalsoc



       NOTES:
       - The Fujitsu CG10103 sprite generator is Tile based, has 16x16 4bpp tiles, Up to 7x7 in each block, 5 bit of palette selection for the mixer, Scaling (x/y), Flipping, Indipendent sorting list and 1 bit of priority for the mixer
         SOURE: video\gstriker.c
       - The Fujitsu MB60553 tilemap chip has 1 Plane, Tiles 16x16 and 4bpp, Map 64x64, Scrolling and Indexed banking (8 banks)
         SOURE: video\gstriker.c




G1.10  Gaelco


       CHIP EXPRESS RASTER   M1178-01 M032541-4 / M027851-1 9706          Radikalb, Surfplnt
       CHIP EXPRESS CHK1     M1105-01 M048494-22                          Radikalb
       CHIP EXPRESS SU3DCOL  M026402-3 9647                               Surfplnt



G1.11  IGS

       IGS001                                                             Grndtour
       IGS002                                                             Grndtour, IQBlock
       IGS003                   ASIC used for I/O (=8255)                 Chindrag, Lordgun
       IGS005      QFP144
       IGS006      QFP144
       IGS007      QFP144
       IGS008      QFP160
       IGS011      QFP160       F5XD  174    GFX controller?              Chindrag, Vbowl
       IGS012      QFP80        9441EK001    possible MCU?                Drgw2, Vbowl
       IGS017      QFP208                                                 Mgcs
       IGS022                   ASIC                                      Drgw3
       IGS023      QFP256       L8A0290                                   PGM-System
       IGS025      PLCC68       ASIC or 8255 ?                            Drgw2, Drgw3, Olds
       IGS026      QFP144                                                 PGM-System
       IGS027A     QFP120       ARM7 based CPU with internal 64k ROM      Ddp2
       IGS028      QFP100                                                 Olds
       IGS029                                                             Mgcs
       IGS031                                                             Slqz2




G1.12  Imagetek

       14100    Imagetek 14100 052 9309EK701, QFP208 (Poitto), Imagetek 14100 052 9227KK701 (Pangpoms)     NOTES: Imagetek 14100 is a custom video chip used in Metro Games.
       14220    Imagetek 14220 071 9338EK707, QFP208, I4220 071 9403EK701 (Balcube, Blzntrnd, Toride2g, Vmetal)    NOTES: The Imagetek 14220 is a Video Chip for 8 bit sprites and tiles used by Metro Games
       14300    14300 095                                                 (Mouja, Dokyusei, Dokyusp, Gakusai, Gakusai2)
       15000    Imagetek 15000 (2ch video & 2ch sound)                    (Tmmjprd, Rabbit)




G1.13  Incredible Technologies

       IT42          Graphics Generator       QFP208          Pairs, Timekill
       ITV4400       Custom Blitter                           Hstennis, Neckneck
       ITBP-1        PAL   TIBPAL 16R4                        Pairs, Rimrockn, Timekill
       ITMP-1        PAL                                      Ninclown
       ITSS-1        PAL   TIBPAL 16L8                        Pairs, Rimrockn, Timekill
       ITVS          ITVS.PLD, PAL16L8                        GTG, Stratab
       ITVS-2        PAL???                                   Rimrockn, Wfortune
       ITVS-3        PAL16L8                                  Peggle, Neckneck, Hstennis
       ITVS-4        PAL???                                   Rimrockn
       ITVS-5        PAL16L8                                  Ninclown, Pokrdice, Slikshot
       ITVS-7        TIBPAL 16R4-15CN         20 pins         Timekill
       ITVS-8        TIBPAL 16R4-15CN         20 pins         Timekill
       ITVS-9        GAL20V8A                 24 pins         Timekill
       ITVS-10       TIBPAL 16L8-15CN         20 pins         Timekill
       ITVS-11A      TIBPAL 16L8-15CN         20 pins         Timekill
       ITVS-12                                                Pairs
       ITVS-13                                                Pairs
       ITVS-14                                                Pairs
       ITVS-15                                                Pairs
       ITVS-16A                                               Pairs




G1.14  Jaleco


       JALECO       MCU, scratched surface          DIP24      IC pinout -> see drivers\ddayjlc.c; Games: D-Day (Jaleco 1984) + Parallel Turn (Jaleco 1984)

       GS-9000404 9248EP004                         QFP44
       GS-9000406 9345K5005                         QFP80

       GS600406                                                (Scudhamm)

       GS900151                                     QFP44
       GS90015-01   GS9001501, GS900151             QFP44
       GS90015-02                                   QFP100
       GS90015-03                                   QFP80
       CS90015-04                                   QFP64
       GS90015-05                                   QFP100
       GS90015-06                                   QFP100
       GS90015-07                                   QFP64
       GS90015-08                                   QFP64
       GS90015-09                                   QFP64
       GS90015-10                                   QFP64
       GS90015-11                                   QFP100
       GS90015-12                                   QFP80

       MR90015      ROM-Label   (1-35)                         (F1gpstar, Scudhamm, Wildplt)

       GS91022-01   9335EK005                       QFP120
       GS91022-02   9340EK703   or  9347EX002       QFP160     (Tetrisp2)
       GS91022-03   9343PP718                       QFP100
       GS91022-04   9334PP710   or  9721PD008       QFP100     (Desertwr, Tetrisp2)
       GS91022-05   048 9726HX002                              (Tetrisp2)


       SS91022-01   9336 ABGA                       QFP208
       SS91022-02   9330 IAGA                       QFP100
       SS91022-03   9428XX001   or  9343EX012       QFP176
       SS91022-05   9347EX002   or  9349EX002       QFP120
       SS91022-07   9338EV 436111 06440             QFP208
       SS91022-10   9513EV 370121 06441             QFP144     Decryption (Desertwr, Gratiaa, Tp2m32, Gametngk)


       SS92046-01   9338EV 436091 06441             QFP144     Decryption (Bbbxing, F1superb, Tetrisp, Hayaosi1)
       SS92047-01   9425EV 367821 06441             144pin     Decryption (Gratia, Kirarast)
       SS92048-01   9410EV 436091 06441                        Decryption (P47-Aces)




G1.15  KANEKO

       KANEKO         BABY004 9511EX009 VT-171     QFP44              (Galpani3, Jchan, SuperKanekoNovaSystem)
       KANEKO ALTAIR    BY006-224                  QFP208             (SuperKanekoNovaSystem)
       KANEKO BEAST                                DIP40              (Djboy)
       KANEKO DENEB     BY007-32F                  QFP208             (SuperKanekoNovaSystem)
       KANEKO CALC1-CHIP                           DIP40              (Galpanic, Galsnew)
       KANEKO CALC3 508                            QFP74, MCU         Note: Decapping shows the CALC3 MCU to be a NEC uPD78322 series MCU with 16K internal ROM.  
       KANEKO HELP1-CHIP                                              (Blazeon)
       KANEKO I/O JAMMA MC-8282 047, MC-8282837    46 pin             (Mgcrystl, Galsnew)
       KANEKO IU-001 9045KP002                     QFP44              (Mgcrystl)
       KANEKO IU-004                                                  (Berlwall)
       KANEKO JAPAN 9152EV 175101                  QFP160
       KANEKO JAPAN 9203 T     or 9203T            QFP44
       KANEKO JAPAN 9204 T                         QFP44
       KANEKO JAPAN 9448 TA                        QFP44              (Gmtr2)
       KANEKO KC-001                                                  (Gpan2qiz)
       KANEKO KC-002 L0002 023 9339EK706           QFP208             (Gmtr2)
       KANEKO KC-BYO KA05-1068                                        (Gpan2qiz)
       KANEKO KC-TAS KA07-1209                                        (Gpan2qiz)
       KANEKO KC-YUU KA06-0041                                        (Gpan2qiz)
       KANEKO KC-SHU KA03-1849                                        (Gpan2qiz)
       KANEKO MERMAID                              DIP40              (Heavy Unit)
       KANEKO MUX2-CHIP                            QFP64              (Mgcrystl)
       KANEKO PANDORA   PX79C480FP-3  sprite chip                     (Djboy, Snowbros, Galpanic)
       KANEKO PISCES                                                  (Gpan2qiz)
       KANEKO SPCII-A  JH-4181                     QFP208             (SuperKanekoNovaSystem)
       KANEKO SPCII-B  JH-6186                     QFP208             (SuperKanekoNovaSystem)
       KANEKO TBS0P01 452 9430HK001 / TBSOP01      PQFP74 square SMD                   Note: ToyBox NEC uPD78324 series MCU with 32K internal rom
       KANEKO TBSOP02 454 9451MK002   Custom MCU?  QFP74,             (Gmtr2)    Note: ToyBox NEC uPD78324 series MCU with 32K internal rom
       KANEKO VEGA      BY005-197                  QFP144             (SuperKanekoNovaSystem)
       KANEKO VIEW2-CHIP 23160-509 9047EAI         QFP144             (Blazeon, Bloodwar, Mgcrystl)
       KANEKO VIEWIII-A  BL-001                    QFP240             (SuperKanekoNovaSystem)
       KANEKO VU-001 046A                          QFP48              (Mgcrystl, BakuretsuBreaker)
       KANEKO VU-002 052 151021                    QFP160             (Berlwall, Blazeon, Mgcrystl)
       KANEKO VU-003                                                  (Berlwall)

       699205P                                     QFP44              (Bakubrkr, Mgcrystl)
       699206P                                     QFP44              (Bakubrkr, Mgcrystl)



       KANEKO PANDORA
       - 0.117u1: Moved Sand Scorpian and Gals Panic over to use the Pandora emulation. Also fixed some problems in the pandora emulation which improves the sprites in Djboy [David Haywood].
       - 0.117: David Haywood moved "Pandora" sprite chip implementation to its own file. Updated Snow Bros, Air Buster, DJ Boy and Heavy Unit to use ths new generic implementation.
       - SOURCE: video\kan_panb.c + kan_pand.c


G1.16  Konami

       K824-501    Gberet, Megazone
        510-47     Tmnt (DIP64)

       0005290     Hcrash                              (SDIP64)
       0005291     Hcrash                              (ZIP64)
       0005292     Hcrash                              (SDIP64)
       0005293     Hcrash                              (SDIP64), also stamped 'TC15G014AP-0019'
       0005294     Hcrash                              (ZIP64)
       0005295     Hcrash                              (SDIP64)
       003461      Polystar                            (QFP100)
       005849      Gberet, Jailbrek                    (005849 8523 E04)
       005885      Finalizr, Jackal, Ddribble          (PGA177)
       007121      Combasc, Tricktrp
       007232      Citybomb, Hcrash                    (SDIP64)
       007324      Lethalen
       007327      Rockrage                            (DIP40)
       007342      Rockrage, TheHustl                  (PGA181)
       007420      Rockrage, TheHustl                  (SDIP64)
       007452      Combasc, Blkpanthr
       007552      Ddibble                             (PAL16L8A)
       007553      Ddibble                             (PAL10L8)
       007593      Blkpanthr, Kittenk, Citybomb        (custom ceramic flat pack with 56 legs)
       007644      Lethalen, Tmnt                      (22pin MSI package)
       051316      88games, Ajax, Tail2nos, Utraman    (PSAC)
       051550      Ultraman, Citybomb
       051649      Citybomb
       051937      Thndrx2, Tmnt                       (Konami 051937 8937 W39)
       051960      Thndrx2, Tmnt                       (Konami 051960 8938 W32)   Triggered IRQs (Ajax)
       051962      Surpratk, Blockhl, Tmnt             (Konami 051962 8930 W52)
       052001                                                                     KONAMI CPU
       052109      Surpratk, Blockhl, Tmnt             (Konami 052109 8926 W42)   Triggered IRQs, controll coin counters, select work RAM or palette and enable char ROM reading through the video RAM.
       052295      Citybomb                            (PAL16L8)
       052526      Blockhl                             (Konami 052526 8925 Y13)  KONAMI CPU
       052535      Spy
       052627      Kittenk                             (PAL16L8)
       053180      Spy
       053244      Lethalen, Rollerg, Surpratk, Tmnt2    (Sprite Control)
       053245      Lethalen, Rollerg, Surpratk, Tmnt2    (Sprite Rendering)
       053246      Dadandrn, Dbz, Dbz2, Moo, Rungun, Mystwarr, Le2  (053246A QFP120 - Motion objects)
       053247      Dbz, Dbz2, Moo                      - SOURCE: The screen in Over Drive is cluttered with sprites which aren't supposed to be visible, increasing the coordinate mask in K053247_sprites_draw() from 0x3ff to 0xfff fixes this but breaks other games (e.g. Vendetta).
       053248                                                                    KONAMI CPU
       053250      Xexex, Over Drive                   - NOTES: The K053250(LVC) is a effect generator.
       053251      Dbz, Dbz2, Tmnt2, Moo, Xmen
       053252      Dadandrn, Dbz, Dbz2, Hexion, Rollerg, Moo, Rungun   (QFP44 - Motion objects)
       053253      Rungun, Xmen                        - NOTES: Motion objects (Rungun)
       053260      Thndrx2
       053936      Blzntrnd, Dadandrn, Suprslam, Rungun    (053936 PSAC2  - QFP80 Backgrounds)  - NOTES: ROZ layer generator (Dbz, Dbz2, F1GP), 3d ROZ plane used for backgrounds (PolygoneCommanders)
       053990      Mtlchmpj. Tmnt2
       054000      Thndrx2
       054009      Plygonet                       (polygon rasterizers)
       054010      Plygonet                       (polygon rasterizers)
       054156      Dadandrn, Dbz, Dbz2, Mystwarr  (Tiles, QFP160)
       054157      Dadandrn, asterix.c, dbz2.c, gijoe.c, konamigx.c and xexex.c   (QFP160)  - NOTES: The K054157 is a complete subset of the K056832.
       054321      Xmen
       054338      Dadandrn, Le2                  (QFP160) - NOTES: Alpha blending (drivers\xexex.c)
       054539      Lethalen                       (PCM sound chip)
       054968A     Lethalen
       055550      Dadandrn                       (QFP64)
       055555      Dadandrn, Le2, Konami-GX       (8-bit-per-pixel priority encoder, PCUCS, QFP176, very tiny chip)
       055673      Dadandrn, Le2, Rungun          (QFP176 (?)- Motion objects - Very tiny chip )
       055996      Dadandrn, Gaiapolis            (PAL16L8 for sound)
       056046      Lethalen                       Mask16M-8bit rom
       056049      Lethalen                       Mask8M-16bit rom
       056230      RacinForce                     (LAN interface)
       056469      Dadandrn, Gaiapolis            (PAL16L8 for CPU/GFX)
       056540      RacinForce, Opengolf
       056602      Cryptklr, Konami GV            (A/D converter ?)
       056734      Daiskiss, Puzldama
       056766      Le2                            (Sprites)
       056800      Le2, Gradius4                  (PQFP80)
       056832      gijoe.c, konamigx.c, moo.c, mystwarr.c and xexex.c       (Tiles)
       056879      Le2, Polystar, Racinfrc        (QFP120)
       057910      Gokuparo
       057911      Gokuparo
       057913      Gokuparo
       057915      Gokuparo
       057917      Gokuparo
       057920      Gokuparo
       057921      Gokuparo
       058141      CryptKiller                    (PCM sound chip)
       058143      Hmcompm2, Bmcompm2             (Tiles)
       058146      Soccerss, Konami System GX
       058232      Polystar                       (ceramic flat pack IC, DAC?)
       058239      Konami-GV                      (PALCE16V8H)


       KS10011     KS10011-PF                       = 053936             Plygonet, Racinfrc, Suprslam
       KS10021     KS-10021                         = 054009             Plygonet
       KS10031     KS-10031                         = 054010             Plygonet
       KS10071     PQFP w/heatsink                                       GTIClub
       KS10081     PQFP                                                  GTIClub
       KS10101                                                           Bmcompmx, Hmcompm2
       KS160X2     KS160X2 HD/C13327.00-2.0 SHARC   = ADSP 21062         GTIClub
       KS40011     KS40011-PF                       = 056230             Racinfrc

       001005      Custom 3D chipset                                     GTIClub
       001231      PALCE16V8H                                            Konami-GV
       001604      Tilemap                                               GTIClub
       0038323     0038323 E9750, 0038323 E9825, SOIC8  Security Chip    Konami80sArcadeGallery, Konami-HornetSystem
       0000033906  Konami Custom 33906, QFP160                           Gradius4, Sscope2 
       0000037122  Konami custom 37122, QFP208                           Sscope/2


       KonamiIC
       - 0.121u2            : Lei Wu added save state support to a number of Konami custom chips.
       - 0.112              : Aaron Giles cleaned up some poorly written code in konamiic.c; there is still much work to be done here, but it fixes the GX sprites.
       - 0.110u3            : Added machine\konamiic.c. Ville Linde consolidated K056800 (MIRAC) sound system interface emulation (machine/konamiic.c).
       - 11th July 2005     : David Haywood - Its certainly not pretty, although compared to the Genesis verison its a work of art, but the Arcade version of Lethal Enforcers now works well enough in MAME to be considered 'Working'. There are still a number of glitches, of note are: Sprite Lag - Sprites seem to lag other sprites, rather strange, no idea why, maybe its correct. Sprite Positioning - may be off by 1 pixel, the first level shadow sprites don't line up if I line up the doors on the other levels, I need to see which is right, or if Konami are playing weird tricks. Shadows - Only the background gets shadowed by the shadow sprites (Glass) for some reason enemies don't, probably a limitation of the current sprite/shadow implementation in konamiic.c. Rowscroll - A rowscoll effect is used for the background on the car stage, this isn't currently emulated. Priorities should be mostly correct, scrolling is correct, gunshots seem fairly accurate (maybe very slightly above the cursor).
       - 0.98u1             : David Haywood fixed Escape Kids memory maps and video hardware (video/konamiic.c).
       - 0.71u1             : Acho A. Tang did many improvements to Run and Gun making it playable (single screen game only): drivers\rungun.c: mem maps, device settings, component communications, I/O's, sound...etc. video\rungun.c: general clean-up, clipping, alignment and video\konamiic.c: missing sprites and priority.
       -  6th June      2003: R. Belmont updated the documentation in the KonamiIC emulation. Acho A. Tang fixed some minor graphics glitches in the Konami GX driver and cleaned up the KonamiIC emulation.
       - 11th March     2003: R. Belmont sent in a major update to the Konami IC emulation by him and Phil Stroffolino.
       - SOURCE: machine\konamiic.c + video\konamiic.c

       007121
       - 0.36RC1: Nicola Salmoria fixed sprites colors in Contra and other improvements to Konami 007121-based games.

       051316
       -  1st April     2000: Nicola Salmoria updated Hot Chase to use the 051316 functions.
       -  8th October   1999: Manuel Abadia added multiple 051316 graphics chip support.
       - 30th May       1999: Nicola has begun working on Shanghai, but it contains a strange graphics chip so the progress will probably be very slow.

       052109
       - 0.95u3             : R. Belmont added dx/dy settings to K052109, similar to those known to exist in the '156 and later chips.

       053247
       - 0.120u3            : Atari Ace added static qualifiers and renamed symbols in MAME in an effort to further tidy up the global namespace. Generally generic names were targeted and some symbols that were both static and extern. Some specifics: K053247_ram was made static throughout and the existing K053247_export_config was used to obtain the value in xmen.c.
 
       053250
       -  8th June      2003: Acho A. Tang did another small improvement on the K053250 graphics emulation.

       053936
       -  5th March     2001: Nicola Salmoria added K053936 graphics chip emulation to Blazing Tornado, and improved the K054157 emulation a bit.

       054157
       - 28th February  2004: R. Belmont added 8-bit access to the K054157 Konami chip and sent in a preliminary Lethal Enforcers driver which doesn't really work at all.
       - 0.71u1             : Acho A. Tang completed K054157 to K056832 migration.
       -  5th March     2001: Nicola Salmoria improved the K054157 emulation a bit.
       -  4th March     2001: Olivier Galibert added linescroll support to the Konami K054157 emulation, used by Xexex, GI Joe and Asterix.

       056832
       - 0.104u7            : Pierpaolo Prazzoli updated the Dragonball Z games to use the K056832 chip emulation, fixing color offsets and priorities.
       - 0.104u5            : Pierpaolo Prazzoli converted Asterix to use K056832 emulation.
       - 0.91u1             : R. Belmont implemented 48xx bankswitch region in Lethal Enforcers, which can toggle between custom chip registers and RAM (evil!). Removed hack to pass POST since we now do it the right way. Corrected K056832 RAM interface, added preliminary support for external linescroll RAM on the K056832. This helps with the garbage tilemaps a bit since linescroll data is no longer getting sprayed all over VRAM (note, with this update the driver was just crashing when I tested it, so maybe something is wrong).
       -  1st September 2003: R. Belmont fixed a bug in the K056832 ROM readback, so the mask ROM tests work again in some of the Konami games.
       - 0.71u1             : Acho A. Tang added preliminary K056832 tilemap<->linemap switching and tileline code.
       - 13th June      2003: Acho A. Tang updated Bucky O'Hare and Moo Mesa to use the K056832 graphics chip emulation which is far more complete than what the driver previously used, fixing various graphics effects and fixing the hang after the stage 2 boss.

       K001604
       - 0.114u3            : Further improved the ROZ layer emulation in the K001604 [Ville Linde].
       - 0.113u4            : Ville Linde improved the K001604 ROZ layer emulation.
       - 0.112u3            : Ville Linde improved the K001604 tilemap chip emulation.
       - 0.104u1            : GTI Club updates [Ville Linde]: Improved K001604 tilemap emulation, very preliminary K001005 & K001006 3D graphics emulation.
       - SOURCE: gticlub.c + nwk-tr.c

       K007420
       - 0.72u2              : Fixed boundary conditions and kludge removal in K007420 [Acho A. Tang]

       ????? (Konami programmable amplifier chip)
       - 27th June 2006: R. Belmont - I'm doing something I meant to do years ago (but MAME wasn't capable of supporting it at the time) - emulating the Konami programmable amplifier chip. It's actually a big ceramic thing that's sadly rather fragile and it's found in games from Xexex pretty much onward. This will make the test menu volume control work in a whole bunch of games, and also effectively make the sound emulation "perfect" in them.




G1.17  LSI Logic

       L1A3787                                        Mk
       L1A6017 (MAX1 EXIT)                            Dcheese
       L1A7968 Williams Electronics 5410-1346500      Crusnusa

       L4A0270                                        Atomicp



       Midway/Williams Electronics

       5410-12862-00    DMA-driven DAC                Mk3, Wwfmania
       5410-13465-00    DMA-driven DAC                Crusnusa (5410-1346500)
       5410-14120-00                                  MK3
       5410-14589-00    I/O           QFP164          Gauntleg, Gauntdl
       5410-14590-00                  QFP80           Gauntleg, Gauntdl
       5410-15349-00 Orbit 61142A                     Blitz99




G1.18  Nakanihon

       NL-001        DYNAX NL-001 WD10100                     Mmpanic
       NL-002        NL-002-3D1                               RongRong, Quizchq
       NL-005        208 pin, square, surface-mounted         Ddenlovr

       4L10F2467     QFP160                                   Realbrk, Pkgnsh, Pkgnshdx
       4L10F2468     QFP160                                   Realbrk, Pkgnsh, Pkgnshdx

       70C160F009    QFP160 (208),  Graphics generator        Dynax games: Mjchuuka, Mjdchuka
       70C160F011                                             Dynax games: Hkagerou, Mjreach1



G1.19  Namco

       -  9th March     2007: Guru - Two Namco 67 IC's for decapping arrived today. Thanks to Justin D.
       - 0.78u4             : Added machine\namcoio.c.
       - 0.88u1             : Shaun Stephenson confirmed Libble Rabble Custom IO chip numbers.
       - NOTES: machine\namcoio.c: Namco custom I/O chips 56XX and 58XX (plus an unknown one used only by Pac & Pal - could be "57XX", I guess). These chips work together with a 16XX, that interfaces them with the buffer RAM. Each chip uses 16 nibbles of memory; the 16XX supports up to 4 chips, but most games use only 2. The 56XX and 58XX are pin-to-pin compatible, but not functionally equivalent: they provide the same functions, but the command codes and memory addresses are different, so they cannot be exchanged. The devices have 42 pins. There are 16 input lines and 8 output lines to be used for I/O. It is very likely that the chips are standard 4-bit microcontrollers with embedded ROM, but it hasn't been determined which type. The closest match so far is the Oki MSM6408/MSM6422, but the pinout doesn't match 100%. Since the Namco customs appear to be manufactured by Fujitsu, they might be MB8851, but I haven't found data sheets nor pinouts for those devices.


       00XX                   Tilemap address generator with scrolling capability (only Super Pacman)
       02XX                   GFX data shifter and mixer (16-bit in, 4-bit out)
       03XX                   ?
       04XX                   Sprite address generator
       05XX                   Starfield generator (Bosconian)
       06XX                   Interface to custom 5xXX
       07XX                   Clock divider
       08XX                   Bus controller
       09XX                   Address bus interface
       10XX                   Z8002 bus controller
       11XX (CUS11)           GFX data shifter and mixer (16-bit in, 4-bit out) [1]
       12XX                   Sprite generator
       13XX                   Dual scrolling tilemap address generator
       15XX (CUS15)           Sound control
       16XX (CUS16)           I/O control
       17XX                   Tilemap address generator with scrolling capability
       20XX (CUS20)            tilemap and sprite address generator
       21XX (CUS21)           Sprite generator
       26XX (CUS26)           Starfield generator
       29XX (CUS29)           Sprite line buffer and sprite/tilemap mixer
             CUS27    DIP40   Clock divider
             CUS30   SDIP64   Sound control
             CUS31    DIP48
       33XX (CUS33)           Timing generator
       34XX (CUS34)           Address decoder
             CUS35            Sprite address generator
             CUS36            Dual tilemap generator
             CUS39    DIP42   Sprite generator
             CUS41    DIP40   Address decoder [2] [3]
             CUS42    QFP80   Dual scrolling tilemap address generator
             CUS43   SDIP64   Dual tilemap generator
             CUS47            Address decoder
             CUS48   SDIP64   Sprite address generator
       50XX           DIP28   Player score control (only used as protection check)
       51XX           DIP42   I/O (coin management built-in)
       52XX           DIP42   Sample player
       53XX           DIP42   I/O (steering wheel support)
       54XX           DIP28   Explosion sound (noise) generator
       56XX (CUS56)   DIP42   I/O (coin management built-in)
       58XX (CUS58)   DIP42   I/O (coin management built-in)
       59xx           DIP42
             CUS60            MCU (63701) aka 60A1
             CUS64            MCU (63701)
       62XX (CUS62)   DIP28   I/O and explosion generator
             CUS95            I/O interface
       98XX (CUS98)           Lamp/coin output
       99XX (CUS99)           Sound volume/enable
             CUS115           Expansion board ROM banking [4]
             CUS116           Display output generator
             CUS117           Main/sub CPU MMU
             CUS120           Sprite/tilemap mixer and palette address interface
             CUS121           Sound CPU address decoder
             CUS123           Scrolling tilemap address generator
             CUS133           Tilemap generator
             CUS151           Protection. Changes from game to game




       Other:

       0037     ?, DIL28                                    Digdug
       0042     Video Ram Addresser                         Grobda
       0044     Video Ram Addresser                         Pacnpal
       0228     GFX data shifter and mixer, DIL28           Digdug
       0425     Sprite address generator, DIL28             Digdug
       0433     Motion Object Controller                    Grobda, Pacnpal
       0482     ?, DIP28                                    Pacland
       0640     Interface to Custom 5303, DIL28             Digdug
       0748     Clock Divider, DIL28                        Digdug
       0763     Clock Divider/Sync Generator                Grobda
       0764     Clock Divider                               Digdug
       0773     Clock Divider/Sync Generator                Grobda, Pacnpal
       0883     Bus controller, DIL28                       Digdug
       1100     Datashift Playfield Register                Pacnpal
       1108     Datashift Playfield Register                Grobda, Pacnpal
       1179     ?, DIP28                                    Pacland
       1200     Motion Object Position                      Pacnpal
       1204     Motion Object Position                      Grobda
       1275     ?, DIP28                                    Pacland
       1371     ?, DIP28                                    Pacland
       1500     Sound Generator                             Pacnpal
       1502     Sound Generator                             Grobda
       1600     ?                                           Pacnpal
       1603     I/O control                                 Grobda
       5156     I/O, DIL42                                  Digdug
       5303     I/O, DIL42                                  Digdug
       5601     Protection ?                                Pacnpal
       5604     I/O interface                               Grobda
       5806     I/O interface                               Grobda
       5902     Protection ?                                Pacnpal
       60A1     ?, DIP40                                    Pacland

       DD1-6    ?, DIL20                                    Digdug



       C27     DIP40         GFX motion obj.                (Pacland)
       C29     SDIP64                                       (Pacland)
       C30     SDIP64        Known 63701 MCU                (Pacland)
       C34     DIP24                                        (Pacland)
       C36     SDIP64                                       (Pacland)
       C39                   Video
       C45     QFP80         Land Generator                 (Luckywld)
       C48                   GFX motion obj.
       C65                   MCU I/O Controller             (Sgunner)
       C67     PLCC68
       C68     QFP80
       C70     QFP80         Rebadged M37702                (Namco NA-1/2 System)
       C71     PLCC68        TI320C25 DSP
       C74                   M37702 Sound MCU
       C75     QFP80         M37702 Sound MCU
       C76     QFP80         M37702 Sound MCU               (Namco System 11)
       C102    QFP80         ROZ Memory Access Control      (Gollygho)
       C106                  OBJ X-Axis Zoom Control
       C107                  Land Line Buffer
       C116    QFP80         I/O  Screen Waveform Generator
       C117
       C120                  Video
       C121    QFP64         Yamaha YM2151 Sound Gen
       C123    QFP80         GFX background, Tile Mem Decoder
       C133                  GFX background
       C134    DIP28         OBJ Address Generator
       C135    DIP28         OBJ Line matching
       C137    DIP28         Clock Generator IC
       C138    QFP80
       C139    QFP64         Serial I/F Controller (SCI)  SOURCE: drivers\namcos22.c
       C140    QFP120        24 Channel stereo PCM sample player
       C143    KeyCustom
       C145    QFP80         GFX Tile Memory Access
       C146    QFP80         OBJ Line Buf Steering
       C148    QFP64         CPU Bus Manager             NOTES: The C148 is a custom devices for the M68000. C148 Features are: 3 Bit output port, 3 Bit input port, 3 Chip selects, 68000 Interrupt encoding/handling, Data strobe control, Bus arbitration, Reset output, Watchdog (NamcoSystem 2)
       C149    DIP28         Mouse/Trackball Decoder
       C150    QFP64
       C152    (8822 Z02)
       C154    KeyCustom
       C156    QFP64         Pixel Stream Combo
       C157    NDIP24
       C160    QFP80         Control Inputs
       C165    NDIP28
       C167    QFP128
       C169    QFP120        ROZ(B)
       C184    KeyCustom
       C185    KeyCustom     (Tankfrce)
       C186    QFP160
       C187    QFP160
       C195    QFP160        Shared SRAM Controller for 68000
       C196    CPP
       C197    DIP24
       C198    QFP160        DSP processors
       C199    QFP100        CPU 18K
       C210    SOP28         (Namco NA-1/2 System)
       C214
       C215    QFP176        (Namco NA-1/2 System)
       C218    QFP208        (Namco NA-1/2 System)
       C219    QFP160        (Namco NA-1/2 System)
       C300    QFP160
       C304    QFP120
       C305    Palette
       C311
       C317    QFP178        IDC Main CPU (68000)
       C323    KeyCustom
       C324    KeyCustom
       C325    KeyCustom
       C326    KeyCustom
       C327    DIP24
       C329    QFP100        CPU?
       C335
       C337    PFP
       C342    QFP160
       C345    (9348EV  333791  VY06436A  NX25024K JAPAN)   (Speedrcr)
       C347    QFP80         GFX OBJ
       C350                                                 (Exvania)
       C351    QFP160        Sound processor
       C352    QFP100        32ch PCM Sound
       C353    QFP120
       C354    (32 pin)      (Exvania, Swcourt)
       C355    QFP160        Motion OBJ(B)         WIP: - 0.78u5: Phil Stroffolino hooked up a private (placeholder) implementation of zdrawgfx() for C355 sprite rendering, adding sprite-tilemap orthogonality for all games using that chip. This fixes MAMEtesters bug ptblank056gre. Also C355 sprite rendering no longer relies on game-specific hacks for XY placement or cropping.
       C356                  (Cgangpzl)
       C357                  (Swcourt)
       C358
       C359    KeyCustom
       C361    QFP120
       C362    KeyCustom
       C365    (32 pin)                                   (Quiztou)
       C366    KeyCustom
       C367
       C368    DIP32
       C370    (Japan 9419A)                              (Ridge Racer, Ridge Racer 2)
       C373    DIP64         LAND-related                 (Luckywld)
       C374    QFP160
       C376
       C379    QFP64
       C380                                               (Speedrcr)
       C381    QFP144
       C382    QFP160                                     (Machbrkr, Outfxies)
       C383    QFP100                                     (Machbrkr, Outfxies)
       C384    QFP48         GFX(3)                       (Machbrkr, Outfxies)
       C385    QFP144                                     (Machbrkr, Outfxies)
       C386
       C388    KeyCustom
       C389    KeyCustom                                  (Cybrcomm)
       C390    KeyCustom, DIP32
       C391    KeyCustom
       C392?                                              (Ace Driver, Victory Lap)
       C393
       C395    QFP168
       C396    QFP160
       C397    QFP160
       C399    QFP160
       C400    QFP100
       C401    QFP64
       C402    QFP144
       C403    QFP136
       C404    QFP208
       C405    QFP176
       C406    KeyCustom, QFP120
       C407    QFP64
       C409    KeyCustom
       C413    QFP208
       C416    QFP176
       C417    QFP208
       C421    QFP208
       C422    QFP64
       C426    KeyCustom
       C428    KeyCustom
       C430    KeyCustom
       C431    KeyCustom
       C434    KeyCustom
       C435    QFP144
       C442    KeyCustom
       C443    KeyCustom
       C444    QFP136
       C446    QFP160
       C447    QFP256


       L7A0564      QFP100
       L7A0565      QFP100

       3PDSP1       PAL 16L8          (Cybsled)
       3PDSP2       PAL 16L8          (Cybsled)
       3PDSP4       PAL 16L8          (Cybsled)
       3PDSP5       PAL 16V8          (Cybsled)
       3POBJ4.JED   PLHS18P8  OBJ(B)  (Aircombj)
       3P0BJ3.JED   PLHS18P8  OBJ(B)  (Aircombj)
       3PDSP5.JED   GAL16V8A  DSP     (Aircombj)

       NB1-2        PAL16L8   "DEC75"   (Machbrkr, Outfxies)
       NB2-1        PALCE16V8 "Mixer"   (Outfxies)
       NB2-2        PAL16L8   "SIZE"    (Outfxies)



       NamcoSystem1

       S11GUN0     PLCC84 FPGA (not populated)
       S11GUN1     Altera Max EPM7128STC100-10 EPLD (QFP100, not populated)
       S11GUN2     Altera Max EPM7128STC100-10 EPLD (QFP100)
       S11GUN3     Altera Max EPM7128STC100-10 EPLD (QFP100)

       S11MOT1A    Standard System 11 PAL (DIP20)
       S11MOT2A             - " -
       S11MOT3A             - " -


       NamcoSystem12

       S12HSC1A     PALCE 16V8H
       S12HSC2A     PALCE 22V10H
       S12HSC3A     PALCE 22V10H

       S12MOT1A     PALCE 22V10H, PLCC28
       S12MOT1C     PALCE 22V10H
       S12MOT2A     PALCE 22V10H, PLCC28
       S12MOT2C     PALCE 22V10H
       S12MOT3A     PALCE 16V8H, PLCC28
       S12MOT3C     PALCE 16V8H
       S12MOT4A     PALCE 22V10H, PLCC28
       S12MOT5A     PALCE 22V10H, PLCC28
       S12MOT6A     PALCE 22V10H, PLCC28
       S12MOT7A     PALCE 16V8H, PLCC28



       KEYCUS (Namco System 10/12/23)

       KC001    S10    Mr Driller 2
       KC003    S10    Gekitoride-Jong Space
       KC006    S12    Tekken 3
       KC007    S10    Mr. Driller G
       KC010    S23    Time Crisis 2
       KC012    S10    Kotoba no Puzzle Mojipittan
       KC014    S12    Libero Grande
       KC017    S10    Panicuru Panekuru
       KC019    S10    Star Trigon
       KC020    S12    Soul Calibur
       KC021    S12    Ehrgeiz
       KC022    S10    Utyuu Daisakusen Chocovader Contactee
       KC027    S12    Super World Stadium '99
       KC029    S23    GP500
       KC035    S12    Derby Quiz My Dream Horse
       KC036    S12    Tenkomori Shooting
       KC037    S12    Fighting Layer
       KC038    S12    Paca Paca Passion
       KC042    S12    Point Blank 2
       KC043    S12    Super World Stadium '99
       KC044    S12    Tekken Tag Tournament
       KC045    S12    Ghoul Panic
       KC046    S12    Paca Paca Passion 2
       KC048    S12    Mr Driller
       KC052    S12    Paca Paca Passion Special
       KC053    S12    Aqua Rush
       KC054    S12    Golgo 13
       KC059    S12    Golgo 13 Kiseki no Dandou




G1.20  NANAO

       KNA6021901    DIP42               (Spelunkr, Youjyudn, Kidniki, Ldrun, Ldrun4)
       KNA6032601    DIP40               (Spelunkr, Youjyudn, Kidniki, Ldrun, Ldrun4)
       KNA6032701    DIP42               (Spelunkr, Youjyudn, Kidniki, Ldrun4)
       KNA6034201    DIP40               (Spelunkr, Youjyudn, Kidniki, Ldrun, Ldrun4)
       KNA6074601    60pin flat package  (Spelunkr, Youjyudn, Kidniki)
       KNA6077305    60pin flat package  (Spelunkr, Youjyudn, Kidniki)

       08J27504A1    QFP160              (Dsoccr94, Gunforc2, Majtitl2)

       GA21          QFP136              (Dsoccr94, Gunforc2, Majtitl2)
       GA22          QFP160              (Dsoccr94, Firebarr, Gunforc2, Majtitl2)
       GA23          QFP180              (Gunforce)
       GA25                              (Hasamu)
       GA30                              (Firebarr)
       GA31                              (Firebarr)
       GA32                              (Firebarr)

       70H016                            (Kikcubic)
       91H014                            (Kikcubic)



G1.21  NEC

       D6376       2-channel 16-Bit D/A Converter (SOIC16)           Renju, Scud, Speglsht, NintendoSuperSystem
       D6379GR     2-channel 16-bit D/A converter 10mW typ. (SOIC8)  PGM-System, Taito GNET-System

       D65006C     ???                                               Bigrun
       D65012GF303 9050KX016                    (QFP80)              47pie2, Suchipi
       D65024GF035 8805KK019   uPD65024, FPGA   (QPFP100)            Rallybik, Truxton, Vimana
       D65054GF102                              (QFP100)             Scud (D65654GF102)
       D65081R077  8833K9  or  D6508|R077 8805k9                     Truxton, Rallybik

       D71011      DIP18            ?                                Kothello
       D71036L     V33 CPU                                           Gunforce
       D71051C     D71051GU, DIP28  ssv.c: uPD71051/uPD7001C (UART)  CPS2, Mslider, Bel
       D71054C     Timer, drivers\seta.c                             Indyheat, Wrofaero, Gundhara
       D71055C                                                       Cherry Master + unknown game by Dynax
       D71059C     Interrupt controller (8259 compatible)            Rtypeleo
       D72103AGC   HDLC Serial com chip                              Glpracr2, Cbaj
       D72105C     uPD72105C   LAN hookup for multiple machines      Dblaxle, Wgp

       DX-101                                                        Grdians, Pzlbowl, Penbros
       DX-102     I/O                                                Meosism, Grdians, Pzlbowl, Penbros




G1.22  Nintendo

       RP2C04-001           Baseball, Freedom Force, Gradius, Hogan's Alley, Mach Rider, Pinball, Platoon, Super Xevious
       RP2C04-002           Castlevania, Ladies Golf, Mach Rider, Raid on Bungeling Bay, Slalom, Stroke N' Match Golf, Wrecking Crew
       RP2C04-003           Dr Mario, Excite Bike, Goonies, Soccer, TKO Boxing
       RP2C05-004           Clu Clu Land, Excite Bike, Ice Climber, Ice Climber Dual, Super Mario Bros.
       RC2C05-01            Ninja Jajamaru Kun (Japan)
       RC2C05-02            Mighty Bomb Jack
       RC2C05-03            Gumshoe
       RC2C05-04            Top Gun




G1.23  NMK


       NMK004
       - 22nd March     2005: Nicola Salmoria - The NMK004 cannot be dumped directly using the common methods, but the way it operates can probably be used to extract the internal ROM data in another way. The external ROM contains data tables used to play the samples and music; but not only that, it contains pointers to those tables. By changing those pointers, we can make the NMK004 use its internal ROM as if it was one of the external tables. In particular, this can be done with the table that contains the sample numbers to be played by the two OKI6295. We can then log the commands sent by the NMK004 to the OKI6295, and this will allow us to determine which sample it is attempting to play - and therefore the value of the internal ROM byte it has just read. This is still at the theorical level, until one of the hardware gurus gets his hands dirty and tries to put it in practice. So in theory there shouldn't be problems - unfortunately the hardware setup needed to get it all to work isn't trivial. But I'm confident that in due time it will be done.
       - 0.94u4             : Nicola Salmoria improved NMK004 simulation and prevented hang in Black Heart.
       - 17th March     2005: Nicola Salmoria - All NMK004 games have sound, though in some of them it's better than in others. Mustang is possibly the worst one - I have doubts about the sound ROM being a bad dump. There were a few major problems - music stopping shortly after starting, or games completely freezing MAME. I have found a bug in the loops handling which should have caused most of these problems.
       - 0.94u2             : NMK004 sound simulation [Nicola Salmoria].
       -  7th March     2005: Nicola Salmoria - I am at a point that I almost consider good enough. The FM part is supported as well. The state machine seems to produce the correct notes, the only strange thing is that the volume is extremely low - I had to push it to 2.0 gain and lower all the others to make it reasonable. There might be a bug somewhere in the way the FM parameters are set - this stuff is much more complex than the PSG. At this point, I'm more worried about the protection in some games than by the sound, which is coming along nicely. It has to be said that this simulation I've written was mostly for personal education and for reference. I am 99% certain the NMK004 internal ROM can be extracted, using a technique I thought of. Theoretically it's very simple, but the process will require some hardware work. And of course, once the ROM is extracted, we'll have to see if it can be ran in MAME. It supposedly is a TLCS-90, which is one of the few CPUs not yet supported by MAME, so an emulator for that CPU would have to be written. Which would be a good thing because it would also allow to support Mahjong If and sound in Rapid Hero. Having the simulation code available might help while writing the CPU emulator.
       -  6th March     2005: Nicola Salmoria - The NMK004 state machine supports: Six FM channels; each pair of them shares one of the three YM2203 voices. Three PSG channels, each one using one of the PSG voices of the YM2203. Eight Effects channels, which can use the total eight voices provided by the two Oki M6295 to play sample-based sounds like drums (but they are also sometimes used to play effects not music related). Direct triggering of Oki M6295 samples (this is not strictly part of the state machine). I am growing more and more convinced that the internal ROM of the NMK004 is the same in all games. A few of the games in the driver have additional protection issues, but at this point I don't think they are related to the NMK004. The problems with the PSG notes were just caused by a silly omission of a *2 in a table lookup. Things that happen when hacking around at 4AM. The PSG part sounds quite good now. Only the FM part is missing...
       -  4th March     2005: Nicola Salmoria - It looks like the Z80 sound program for Task Force Harrier, which is the only known game predating the introduction of the NMK004, uses a data format which is very similar to the one used by the NMK004. The main command table and the sample tables are slightly different, and the music tables look very similar if not identical. It would probably be possible to modify the Z80 program to use the different tables, but I think I'll take the longer route and rewrite the program in C - so I'll learn how a program like that works in detail, which can always be useful knowledge.
       -  3rd March     2005: Nicola Salmoria - One of the longest standing hurdles in MAME emulation is the sound in NMK/UPL games like Mustang, Vandyke, GunNail, etc. Those games use an custom CPU, labelled "NMK004", to drive the sound. It is still not known what kind of CPU it is, what's known is that it has 8 or 16kB of internal ROM which cannot be directly dumped, and which contains the whole program. The external ROM only contains data. I am convinced that the program contained inside the NMK004 is either always the same, or it has minor difference to handle protection - but the format of the data in the external ROM is always the same. What I'm trying to do at the moment is understand the format of the external data. I have started with the easy part, that is the Oki 6295 samples control. I have found the command table, and the mappingd from command to 6295 sample number. This allowed me to make the games play the correct samples at the correct time so e.g. in Vandyke I hear a "swoosh" when I swing the sword and a "uumph" when I jump. I still haven't understood all of the control bits, so it isn't perfect yet, but it's a good start for a night's work. I'm hoping that other games that use a standard Z80 instead of the NMK004 will use similar logic to drive the sound (though I have already verified that they don't use the same data format as the NMK004). Of course the YM2203 part will be much harder since it won't be just a matter of playing a few samples here and there, but I will have to fully understand how the data translates into music and drive the YM2203 accordingly. However there's nothing stopping it in principle, so I am confident that eventually I or someone else will be able to add full sound to these games.
       - 16th August    2004: Guru - The big news is in dumping the Tenkaigen MCU (A Toshiba TMP91P640N in SDIP64 package), we've realised that the sound MCU/CPU on the NMK games that use NMK004 is the same chip, just in a QFP44 package which I have support for in the programmers software! So I can dump those too, but unfortunately we'll need another adapter. This means sound in GunNail, Mustang, Acrobat Mission, Vandyke, Black Heart and possibly others that use the NMK004 chip is possible once the chip is dumped.
       - SOURCE: machine\nmk004.c
       - PCB/SOURCE: The NMK004 CPU might be a Toshiba TLCS-90 class CPU (is similar to Z80 but with different opcodes ?) with internal ROM (?) in the 0000-3fff range.



       NMK112
       - 0.99u4             : Created new NMK112 ROM banking module and connected it up to a number of drivers that made use of it. Affected games are in cave.c, nmk16.c, powerins.c, quizpani.c and toaplan2.c [Alex W. Jackson].
       -  7th July      2005: Alex W. Jackson - As promised, here's my NMK112 unification patch. This patch affects the following games which use the NMK112 chip (including clones, unless noted): cave.c: donpachi and pwrinst2; nmk16.c: macross2, tdragon2, raphero (theoretically - driver doesn't have sound yet), bjtwin, nouryoku and sabotenb; powerins.c: powerina (not powerins); quizpani.c: quizpani (thanks Reip) and toaplan2.c: batrider and battleg. This is my first non-trivial code contribution to MAME, not to mention my first time writing C code in quite a while (VB and Python have made my brain mushy) so a real MAMEDev should probably look over the patch carefully to make sure I haven't done anything stupid. In particular, I don't understand exactly what the ACCESSING_LSB macro does--I just copied it from the old code in nmk16.c. I also don't know if I have correctly named the function NMK112_okibank_word_w(). Only the LSB of the data written is actually used (the data is ANDed with 0xFF and then passed to the 8-bit handler), so perhaps it should be called NMK112_okibank_lsb_w() instead. If any games output incorrect samples after using this patch, they may need to have NMK112_set_paged_table() called in their driver initialization. Determine which of the two M6295s is playing the wrong samples, and add NMK112_set_paged_table(chipnum, 0) to the game's DRIVER_INIT. See Donpachi for an example. Judging by the old code I replaced, I don't believe any games other than Donpachi require this (there was a comment in cave.c implying that Donpachi was an unusual case), but I may be mistaken. The interface to the NMK112 used by the two Raizing games in toaplan2.c can probably be tidied up, but I left it as it was since I don't have either of those romsets to test. In this patch I also took the liberty of fixing an apparent mistake in raphero's sound ROM loading, in case someone gets the sound emulation working in the future.
       - NOTES: NMK112 custom IC for bankswitching the sample ROMs of a pair of OKI6295 ADPCM chips. The address space of each OKI6295 is divided into four banks, each one independently controlled. The sample table at the beginning of the address space may be divided in four pages as well, banked together with the sample data. This allows each of the four voices on the chip to play a sample from a different bank at the same time.
       - SOURCE: machine\nmk112.c



       NMK002     QFP80
       NMK004     QFP64       Sound CPU                         Acrobatm, Blkheart, Gunnail, Mustang, Vandyke
       NMK005     QFP64       possible MCU?                     Bioship, Quizpani
       NMK008     QFP84
       NMK009     QFP100
       NMK111     QFP64
       NMK112     QFP64       Custom IC for bankswitching
       NMK214
       NMK215
       NMK901     QFP80                                         Bioship
       NMK902     QFP44                                         Bioship
       NMK903     QFP44                                         Bioship


       Links: http://upl-gravedigger.hp.infoseek.co.jp/top.html




G1.24  Other

       Afega               AFEGA AFI-GFSK (PLCC68), AFEGA AFI-GFLK (QFP208), AFI-CF5K       Grdnstrm, Popspops, Bubl2000 (LTC1 = AFEGA AFI-GFSK, LTC2 = AFEGA AFI-GFLK)
       Atlus               ATLUS 8647-01 013                                      Donpachi, Pwrinst2
       AXELL               AXELL AG-1 AX51101     (graphics LSI)                  Gunpey
       Comad               T91B-06, T91B-07                       DIP32           Fantasy95, Hotpinbl
       Electronic Devices  INGA 1 / INGA 2 I.G.1BB  48844758V (PLCC84 FPGA)       Borntofi
       Eolith              EV0514-001                             QFP100          Raccoon, Puzzlekg
       FACE                FX1037-FACE-FA01-2075                  QFP176          Mcatadv, Nost
       Fuuki               FI-002K, FI-003K                       QFP208          Pbancho, Gogomile, Asurabld
       Graphic Techno      001599 + CP S No C2012                                 Taxidrvr
       Home Data           HOMEDATA GX61A01 102 8728KK or 8842KK  QFP100          Lemnangl
       Hudson              HuC6260A, HuC6270                                      Battlera (video\battlera.c), Paranoia, TourVision
       Hyperstone ?        SYS L2D HYP Ver 1.0 ASIC Express, L2D_HYP              Legendoh, Spotty
       Mahjong games       NB19010 and NB22090
       Nihon System        06B49P                                 DIP28           Countrun, FreeKick
       P&P Marketing       AJ001 5380-JY3306A, AT001              QFP160          Policetr, Sshooter
       Tatsumi             TZB215, TZB315 = TZ8315                                Round Up, CycleWarriors
       Texas Instruments   TI 52C1HXW and TI 52ALROW                              Ttchamp
       Unico               MDE-2001                                               Stoffy
       Williams            Special Chip 2 (custom BIT/BLT chip)                   Mysticm
       Zoran               Zoran ZR36011PQC + ZR36050PQC          QFP100          Sliver - NOTES: The background images on this hardware are in JPEG format, the Zoran chips are hardware JPEG decompression chips.



G1.25  Philko

       PK8701     PK8701 8720                 Outrun
       PK8702     PK8702 8717                 Atomicp, Outrun
       PK8703                                 Outrun
       PK8704                                 Outrun
       PK8705                                 Outrun
       PK8801                                 Twinfalc, Xyonix


G1.26  Psikyo

       PS2001     PS2001B                  (Btlkroad, Gunbird, S1945, Tengai)
       PS3103                              (Btlkroad, Gunbird, S1945, Tengai
       PS3204                              (Btlkroad, Gunbird, S1945, Tengai
       PS3305                              (Btlkroad, Gunbird, S1945, Tengai)
       PS6406     PS6406B    QFP208        (Gunbird2, Gnbarich, Daraku, S1945II)
       PS6807                QFP208        (Hotgmck, Loderndf, Hotdebut, Hgkairak)



G1.27  Seibu

       SEI80BU      611 787                                                      Cshooter, Deadang
       SEI0010BU    TC17G005AN-0025                                              Deadang, Panic Road
       SEI0020BU    TC17G008AN-0015                                              Cshooter, Deadang
       SEI0021BU    TC17G008AN-0022                                              Deadang, Panic Road
       SEI0030BU    TC17G005AN-0026                                              Cshooter, Panic Road
       SEI0040BU    TC15G008AP-0048                                              Cshooter, Panic Road
       SEI0050BU    MA640 00                                                     Cshooter, Deadang, Panic Road
       SEI0060BU    TC17G008AN-0024                                              Cshooter, Deadang
       SEI0070BU                                                                 Mustache
       SEI0100BU    YM3931 9106 EANA                         (DIP64)             Heatbrl, Cupsoc, Godzilla, Skysmash
       SEI150       W (triangle symbol) 40101                                    Raidendx, Raiden2
       SEI0160      F15 359                                  (QFP60)             Sdgndmps, Sengokmj, Skysmash
       SEI0181                                               (QFP80)             Skysmash
       SEI0200      TC110G21AF 0076 9121EAI JAPAN            (QFP100)            Denjinmk, Heatbrl, Legionna, Godzilla, Skysmash
       SEI0210                                               (QFP128)            Sengokmj, Skysmash
       SEI0211      9107 ABCB                                (QFP128)            Heatbrl, Legionna, Cupsoc, Godzilla
       SEI0220BP    JAPAN S 9114 U                           (QFP64, QFP80)      Heatbrl, Legionna, Cupsoc, Godzilla, Skysmash
       SEI252       SB05-106                                 (QFP208)            Raiden2, Raidndx, Ejanhs, Senkyu, Viperp1
       SEI300       TC25SC900AF 001 9211eai                  (QFP184)            Heatbrl, Legionna, Cupsoc, Godzilla
       SEI333                                                                    Raidendx
       SEI360       SB06-1937                                (QFP160)            Raiden2, Raidndx
       SEI400       SB07-3460                                (QFP208)            rdft2
       SEI600       SB08-1513                                (QFP208)            rdft2
       SEI1000      SB01-001                                 (QFP184)            Raiden2, Raidndx, Denjinmk

       RISE10       Tile-Encryption chip                     (QFP240)            Raiden Fighters 2, Raiden Fighters Jet
       RISE11       9823 GAX1    Tile-Encryption chip        (QFP240)            Raiden Fighters Jet
       SIE150                                                (QFP100)            Raiden Fighters 2, Raiden DX


G1.28  Sega

       315-0015   MCU on Body Slam board. Does the following: Halt 68000 (which has been running for a bit beforehand), set up palette, show warm-up counter in middle of the text layer and let 68000 continue to run
       315-0033   831100  Custom CPU
       315-0042   40-pin - replaced several TTL chips (Carnival, Invho2, Sspaceat),  VIC 315042 (Sspaceat)
       315-0062   Security chip (Astrob)
       315-0063   Security chip (Spaceod)
       315-0064   G-80 Security chip (Spacfury, Startrek)
       315-0070   G-80 Security chip
       315-0076   G-80 Security chip (Elim2)
       315-0082   G-80 Security chip for Monster Bash
       315-0172
       315-0220   EEPROM EPM5032DC-25

       315-3513   (Potopoto)
       315-4249   (Strkfgtr)
       315-4296   (Potopoto)

       315-5006   Encrypted CPU for Monster Bash (N7751?)
       315-5010   Encryption Pengo
       315-5011   315-5011 8549X5, Sprite line comparitor, DIP40     (Enduror, Hangon)
       315-5012   315-5012 8605P5, Sprite generator control, DIP48   (Enduror, Hangon)
       315-5013   Encryption Super Zaxxon, Ixion
       315-5014   Encryption Buckrog
       315-5018   Encryption Yamato
       315-5025   (Wmatch)
       315-5028   Encryption Sindbad Mystery
       315-5030   Encryption Up'n Down and Razzmatazz
       315-5033   Encryption Regulus
       315-5041   Encryption Mister Viking
       315-5048   Encryption SWAT
       315-5049   8551PX, Tilemaps, SDIP64    (Shtngmst, Enduror)
       315-5051   Encryption Flicky and Ninja Princess (bootleg)
       315-5053   PAL
       315-5054   PAL
       315-5056   PAL
       315-5061   Encryption Future Spy
       315-5064   Encryption Water Match
       315-5065   Encryption Bull Fight
       315-5069   Encryption Star Force (same key as Super Locomotive)
       315-5070   PAL12H6
       315-5071   PAL16R6
       315-5072   PAL16R6
       315-5073   PAL16L4 (protected) (Combh)
       315-5074   PAL10L8 (Combh)
       315-5084   Custom Z80  (Jongkyo)
       315-5093   Encryption Pitfall II
       315-5098   Encryption Ninja Princess (same key as Up'n Down)
       315-5102   Encryption Sega Ninja
       315-5106   PAL16R, DIP20      (Enduror)
       315-5107   PAL16R, DIP20, Horizontal timing control   (Hangon)
       315-5108   PAL16R, DIP20, Vertical timing control     (Hangon)
       315-5110   Encryption I'm Sorry
       315-5114   Encryption Chboxing, Chwrestl (same key as Regulus)
       315-5115   Encryption TeddyBoy Blues
       315-5122   PAL, Timing   (Hangon)
       315-5124   VDP - Sega Master System console
       315-5132   Encryption My Hero
       315-5135   Encryption Heavy Metal and Wonder Boy (set 1a & 3)
       315-5139   315-5139 8537 CK2605 V J  (Shtngmst)
       315-5141   Signetics CK2605, Z80 address decoding, DIP20
       315-5142   Signetics CK2605, DIP20
       315-5143   PAL, Sprite-related?
       315-5144   PAL, Sprite-related?, DIP20
       315-5145   PAL
       315-5147   PAL, unknown, DTACK-related
       315-5149   82S153 FPLA, Video mixing, DIP20
       315-5150   PAL
       315-5155   PAL, DIP20, Road bit extraction
       315-5159   8751 MCU
       315-5162   Encryption 4D Warriors and Rafflesia
       315-5164   PAL      (Enduror)
       315-5165   PAL      (Enduror)
       315-5166   PAL      (Enduror)
       315-5167   PAL      (Enduror)
       315-5168   PAL      (Enduror)
       315-5169
       315-5170   PAL      (Enduror)
       315-5171   PAL      (Enduror)
       315-5172   PAL      (Enduror)
       315-5177   Encryption Astro Flash and Wonder Boy (set 1)
       315-5178   Encryption Wonder Boy (set 2)
       315-5179   Encryption Robo Wres 2001 (NEC D315-5179)
       315-5193   PAL, 68000/MCU interface & address decoding
       315-5194
       315-5195   Memory mapper, QFP100
       315-5196   Sprite generator
       315-5197   Tilemap generator (System 16B) (108 8944 Y95) (PGA135)
       315-5202   PAL, 68000/MCU interface & address decoding  (Bodyslam)
       315-5203   PAL           (Robowres)
       315-5211   Sprite generator, 315-5211 136 8802 Y29 (PGA179)      (Aburner2)
       315-5213   PAL16R6, DIP20, Sprite-related                        (System16b)
       315-5214   Signetics CK2605, DIP20                               (System16b)
       315-5218   315-5218 134 8939 W00, SEGA PCM CHIP, QFP100          (Aburner2, Shangon)
       315-5222   PAL, Road mixing
       315-5223a  PAL
       315-5224   PAL
       315-5225   PAL
       315-5226   PAL
       315-5227a  PAL
       315-5228   PAL
       315-5242   Color encoder (315-5242 0301) (Custom ceramic DIP32 package) (QFP44)
       315-5244   82S153 FPLA, DIP20
       315-5246
       315-5248   Hardware multiplier, 315-5248 406AU 8939 W18, QFP100  (Strkfgtr)
       315-5249   Hardware divider, 315-5249 186BU 8917 W70, QFP120
       315-5250   Compare/Timer chip, 315-5250 423U 8940 W13, QFP120   (Aburner2, Loffire)
       315-5251   PAL                              (Shangon)
       315-5254   (9Y01)                           (Loffire)
       315-5275   Road generator, QFP100           (Aburner, Smgp)
       315-5278   PAL, Sprite ROM bank control     (Smgp)
       315-5279   PAL, Video mixing                (Afterburner)
       315-5280   PAL, Z80 address decoding        (Loffire, Smgp)
       315-5290   PAL, Main CPU address decoding   (Loffire)
       315-5291   PAL, Main CPU address decoding   (Loffire)
       315-5292   Tilemap generator, QFP160        (System 24, Model1)  (Mahmajn, VF)
       315-5293   Object generator, QFP160         (Mahmajn)
       315-5294   Mixer, QFP100                    (Mahmajn)
       315-5295   Object Generator, QFP100         (SegaSystem24);  Address decoder/interrupt controller (Mahmajn/2)
       315-5296   315-5296 8949KD, QFP100 - I/O handler  SOURCE: machine\system24.c - The 315-5296 has eight 8bits I/O ports, three output-only pins, some protection, and external/daughterboard chip selection on half of the address range.
       315-5298   PAL, Signetics PLS153F Field Programmable Logic Array, DIP20
       315-5304   PAL, Video mixing                (Smgp, Loffire)
       315-5305   Sprite generator                 (Strkfgtr)
       315-5306   Video sync and rotation          (Strkfgtr)
       315-5312   Video mixing                     (Strkfgtr)
       315-5313   VDP,  315-5313 7101 9Z 04 65 C   (Columns2, Tfrceac)
       315-5314   PAL
       315-5315   PAL
       315-5316   PAL
       315-5317   PAL
       315-5318   PAL
       315-5319   PAL
       315-5325   PAL
       315-5328   PAL
       315-5330               (Sega MegaPlay)
       315-5336   PAL         (Smgp)
       315-5337   PAL         (Smgp)
       315-5338   Sega Custom, QFP100         (Model1)
       315-5349   PAL16L8BCN  (Sega MegaPlay)
       315-5360   Memory mapper?
       315-5361   Sprite generator
       315-5362   Tilemap generator
       315-5373   PAL, Video mixing, PLS153      (Mwalk)
       315-5374   PAL, Sprite timing
       315-5375   PAL, System timing
       315-5385   Sprites?, QFP128   (Radr, Titlef)
       315-5386   Tilemap generator, QFP184   (Radr, Titlef)
       315-5387   Sprites, QFP160   (Radr, Titlef)
       315-5388   Priority, video mixing, QFP160   (Radr, Titlef)
       315-5389   PAL, VDP sync
       315-5390   PAL
       315-5391   GAL22V10, Z80 address decoding  (Clutch Hitter)
       315-5393   PAL
       315-5394   PAL
       315-5395   PAL
       315-5394                 (Tfrceac)
       315-5395                 (Tfrceac)
       315-5422   Sega Custom, QFP160   (Model1)
       315-5423   Sega Custom, QFP160   (Model1)
       315-5424   Sega Custom, QFP160   (Model1)
       315-5425   Sega Custom, QFP160   (Model1)
       315-5430   PAL, Video mixing
       315-5433                 (Sega MegaPlay)
       315-5436   Tile/sprite banking
       315-5441   GAL16V8A      (Radr, Sega System32)
       315-5442   PAL           (Radr)
       315-5452                 (Tfrceac)
       315-5463   Sega Custom, QFP160         (Model1)
       315-5464   Sega Custom, QFP160         (Model1)
       315-5465   Sega Custom, QFP100         (Model1)
       315-5476   RF5C68 PCM sound, 80 pins square chip    (Sega System32)
       315-5478   GAL16V8A, DIP20     (Model1)
       315-5483   PAL CK2605, DIP20   (Model1)
       315-5484   GAL16V8A, DIP20     (Model1))
       315-5485   GAL16V8A, DIP20     (Model1)
       315-5486   GAL16V8A, DIP20     (Model1)
       315-5507   PAL           (Radr)
       315-5546   GAL16V8A, DIP20     (Model1)
       315-5547   AMI 18CV8PC-25 PAL, DIP20     (Model1)
       315-5552   GAL16V8A/B    (Jparc, Sonic)
       315-5560   MultiPCM sound chip, QFP80  (Titlef)
       315-5571   SEGA MODEL1 TGP, QFP160     (Model1)         
       315-5572   SEGA MODEL1 TGP, QFP160     (Model1)
       315-5573   Sega Custom, QFP160         (Model1)
       315-5577   Lattice GAL16V8A, DIP20)    (Model1)
       315-5578   Lattice GAL16V8A, DIP20)    (Model1)
       315-5579   Lattice GAL16V8A, DIP20)    (Model1)
       315-5591   QFP100         (Titlef)
       315-5596   Lattice GAL16V8A, DIP20  (Titlef)
       315-5598   Lattice GAL16V8A, DIP20  (Titlef)
       315-5611   Lattice GAL16V8A PAL, DIP20   (Model1)
       315-5624   MMI PAL16L8BCN PAL, DIP20     (Model1)
       315-5625   PQFP144       (Doa, VF)
       315-5644   PQFP160       (Doa, VF)
       315-5645   PQFP208       (Doa, VF)
       315-5646   PQFP304       (Doa, VF)
       315-5647   PQFP304       (Doa, VF)
       315-5648   PQFP44/64/100  (Doa, VF)    QFP64 (Harley)
       315-5649   QFP100        (Bel, Harley)
       315-5651   GAL16V8A      (Sega MegaPlay)
       315-5653   GAL16V8A      (Sega MegaPlay)
       315-5654   PAL16L8BCN    (Sega MegaPlay)
       315-5655   PAL16L8BCN    (Sega MegaPlay)
       315-5661   GAL16V8A      (Sega MegaPlay)
       315-5672   QFP196        (Bel, VF)
       315-5673   QFP240        (Bel, VF)
       315-5674   PQFP120       (Doa, VF)
       315-5677   PQFP240       (Doa, VF)
       315-5678   PQFP240       (Doa, VF)
       315-5679   PQFP240       (Doa, Sega Model 2A)
       315-5687   YMF292-F LAKE QFP128   (Bel, Coolridr, VF)
       315-5688   FH3007        (STV-Bios)
       315-5689   HD64440F      (STV-Bios)
       315-5690   FH3006        (STV-Bios)
       315-5691                 (Coolridr)
       315-5692                 (Coolridr)
       315-5693                 (Coolridr)
       315-5694                 (Coolridr)
       315-5695                 (Coolridr)
       315-5696                 (Coolridr)
       315-5697                 (Coolridr)
       315-5698                 (Coolridr)
       315-5712   PQFP144       (Doa, VF)
       315-5725   QFP144        (Bel)
       315-5737   GAL16V8B      (Doa, VF)
       315-5744                 (STV-Bios)
       315-5757                 (Coolridr)
       315-5758                 (Coolridr)
       315-5762   PLCC68        (Scud)
       315-5778                 (STV-Bios)
       315-5793   GAL16V8B      (Doa, VF)
       315-5798   QFP304        (Bel)
       315-5799   QFP368        (Bel)
       315-5800   GAL16V8B      (Coolridr)
       315-5801   GAL16V8B      (Coolridr)
       315-5802   GAL16V8B      (Coolridr)
       315-5803   GAL16V8B      (Coolridr)
       315-5804   QFP144        (Harley)
       315-5815   GAL16V8B      (Doa)
       315-5838                 (Decathlt)
       315-5849                 (Coolridr)
       315-5864   GAL16V8B      (Coolridr, VF)
       315-5879   PAL           (Bel)
       315-5881   317-50xx-COM  (Elandore)
       315-5893   QFP240        (Harley)
       315-5894   QFP240        (Harley)
       315-5917   QFP80         (Harley)
       315-5968   GAL16V8
       315-5969   GAL16V8
       315-6022   QFP208        (Harley)
       315-6050   Lattice ispLSI 2032 80LJ H833B23, PLD (Pltkids, Vs2v991)
       315-6057   BGA                (Harley)
       315-6058   BGA                (Harley)
       315-6059   BGA                (Harley)
       315-6060   BGA                (Harley)
       315-6061   BGA                (Harley)
       315-6074   PALCE16V8          (Harley)
       315-6075   PALCE16V8          (Harley)
       315-6089   GAL16V8D, PLCC20   (Harley)
       315-6090   GAL16V8B           (Harley)
       315-6102   PALCE16V8, PLCC20  (Harley)


       316-1921                 (Razmataz)


       317-0001      ?
       317-0002      ?
       317-0003      ?
       317-0004      Custom Z80   Calorie Kun
       317-0005      Custom Z80   Space Positio
       317-0006      Custom Z80   Gardia
       317-0007      8751H        Gardia
       317-0008      ?
       317-0009      ?
       317-0010      8751H        Quartet
       317-0011      8751H        Dump Matsumoto
       317-0012      ?
       317-0013      FD1089B      Enduro Racer
       317-0014      MC-8123B     DakkoChan Jansoh
       317-0015      8751H        Body Slam
       317-0016      FD1089?      Fantasy Zone
       317-0017      ?
       317-0018      FD1089A      ActionFighter
       317-0019      ?
       317-0020      ?
       317-0021      FD1089A      Alex Kid
       317-0022      FD1089A      Dunk Shot
       317-0023      FD1089A      ?
       317-0024      FD1089B      Time Scanner
       317-0025      ?
       317-0026      ?
       317-0027      FD1089B      SDI
       317-0028      FD1089A      SDI
       317-0029      MC-8123B     Block Gal
       317-0030      MC-8123B     Perfect Billiards
       317-0031      ?
       317-0032      ?
       317-0033      FD1089A      Alien Syndrome
       317-0034      FD1089B      Super Hang On
       317-0035      ?
       317-0036      ?
       317-0037      FD1089B      Alien Syndrome
       317-0038      ?
       317-0039      ?
       317-0040      FD1094       Bullet ?
       317-0041      FD1094       Bullet
       317-0042      MC-8123B     Opa Opa
       317-0043      MC-8123B     Wonder Boy Monster Land
       317-0044      FD1089?      Super Hang On
       317-0045      FD1094       Super League
       317-0046      FD1094       Heavyweight Champ
       317-0047      FD1094       Heavyweight Champ ?
       317-0048      FD1094       Wonderboy 2
       317-0049      FD1094       Shinobi (System 16B)
       317-0050      FD1094       Shinobi (System 16A)
       317-0051      FD1094 ?     Sonic Boom ?
       317-0052      FD1094 ?     Sonic Boom ?
       317-0053      FD1094       Sonic Boom
       317-0054      MC-8123B     Shinobi (System 16A)
       317-0055      FD1094 ?     Thunder Blade ?
       317-0056      FD1094       Thunder Blade
       317-0057      MC-8123B     Fantasy Zone 2
       317-0058-01   FD1094           ?
       317-0058-02C  FD1094       Scramble Spirits
       317-0058-03D  FD1094       Gain Ground
       317-0058-04D  FD1094       Crack Down
       317-0058-05C  FD1094       Super Masters
       317-0058-05D  FD1094       Super Masters
       317-0058-06   FD1094       Rough Racer
       317-0058-07   FD1094           ?
       317-0058-08   FD1094       Quiz Syukudai
       317-0058-09D  FD1094       Dynamic Country Club
       317-0059      FD1094       Ace Attacker
       317-0060      FD1094       Ace Attacker
       317-0061      FD1094       Ace Attacker
       317-0062                       ?
       317-0063                       ?
       317-0064      MC-8123B     Ufo Senshi Yohko Chan
       317-0065      FD1094       Altered Beast
       317-0066      MC-8123B     Altered Beast
       317-0067      FD1094       Altered Beast
       317-0068      FD1094       Altered Beast (Japan)
       317-0069      FD1094       Altered Beast
       317-0070      FD1094       Passing Shot (4P, Japan)
       317-0071      FD1094       Passing Shot (4P, US) ?
       317-0072      FD1094       Passing Shot (4P, Export) ?
       317-0073                        ?
       317-0074      FD1094       Passing Shot (World, 4 Players)
       317-0075                        ?
       317-0076      8751         Altered Beast
       317-0077      8751         Altered Beast
       317-0078      8751         Altered Beast
       317-0079      FD1094       Excite League
       317-0080      FD1094       Passing Shot (2P, Export?)
       317-0081                        ?
       317-0082                        ?
       317-0083                        ?
       317-0084      FD1094       W/Boy3 Monster Lair (Japan)
       317-0085      FD1094       W/Boy3 Monster Lair (Japan)
       317-0086      FD1094       W/Boy3 Monster Lair ?
       317-0087      FD1094       W/Boy3 Monster Lair (Japan)
       317-0088      FD1094       W/Boy3 Monster Lair (US) ?
       317-0089      FD1094       W/Boy3 Monster Lair (Export)
       317-0090      FD1094       Wrestle War (Japan)
       317-0091      FD1094       Tetris (Japan, S16B)
       317-0092      FD1094       Tetris (Japan, S16B)
       317-0093      FD1094       Tetris (Japan, S16A)
       317-0093A     FD1094       Tetris (Japan, S16A)
       317-0094      FD1094       Dynamite Dux (Japan) ?
       317-0095      FD1094       Dynamite Dux (US) ?
       317-0096      FD1094       Dynamite Dux (Export?)
       317-0097                        ?
       317-0098      8751         W/Boy3 Monster Lair
       317-0099      8751         Tough Turf
       317-0100      8751         Tough Turf
       317-0101      FD1094       Wrestle War (US) ?
       317-0102      FD1094       Wrestle War (Export)
       317-0103      8751         Wrestle War
       317-0104      8751         Tough Turf
       317-0105      FD1094       Turbo Out Run ?
       317-0106      FD1094       Turbo Out Run
       317-0107      FD1094       Turbo Out Run
       317-0108                        ?
       317-0109                        ?
       317-0110      FD1094       Golden Axe (Export)
       317-0111                        ?
       317-0112      8751         Golden Axe
       317-0113                        ?
       317-0114      FD1094       Bay Route ?
       317-0115      FD1094       Bay Route (Japan)
       317-0116      FD1094       Bay Route (Export)
       317-0117      FD1094       Turbo Out Run ?
       317-0118      FD1094       Turbo Out Run (upgrade)
       317-0119      FD1094       Turbo Out Run ?
       317-0120      FD1094       Golden Axe (Export)
       317-0121      FD1094       Golden Axe (Japan)
       317-0122      FD1094       Golden Axe (US)
       317-0123A     8751         Golden Axe
       317-0124A     FD1094       Super Monaco GP (Japan)
       317-0125A     FD1094       Super Monaco GP (US)
       317-0126      FD1094       Super Monaco GP (Export)
       317-0126A     FD1094       Super Monaco GP (Export)
       317-0127A     FD1094       Flash Point (Japan)
       317-0128      FD1094       E-Swat (Japan)
       317-0129      FD1094       E-Swat (US)
       317-0130      FD1094       E-Swat (Export)
       317-0131                      ?
       317-0132                      ?
       317-0133                      ?
       317-0134      FD1094       Line of Fire (Japan)
       317-0135      FD1094       Line of Fire (US)
       317-0136      FD1094       Line of Fire (Export)
       317-0137                      ?
       317-0138                      ?
       317-0139      FD1094       Bloxeed (Japan)
       317-0140      EPM5032      Bloxeed
       317-0141                      ?
       317-0142      FD1094       MVP (Japan)
       317-0143      FD1094       MVP (US)
       317-0144      FD1094       Racing Hero (Export)
       317-0145      FD1094       Racing Hero (US)
       317-0146      FD1094       Alien Storm (2P, Japan)
       317-0147      FD1094       Alien Storm (3P, US)
       317-0148      FD1094       Alien Storm (3P, Export)
       317-0149      EPM5032      Columns
       317-0150                      ?
       317-0151                      ?
       317-0152                      ?
       317-0153      FD1094       Pontoon
       317-0154                      ?
       317-0155                      ?
       317-0156      EPM5032(?)   Bonanza Bros
       317-0157      FD1094       Moon Walker (Japan)
       317-0158      FD1094       Moon Walker (US)
       317-0159      FD1094       Moon Walker (Export)
       317-0160      EPM5032      Columns II
       317-0161      FD1094       GP Rider (Japan) ?
       317-0162      FD1094       GP Rider (US)
       317-0163      FD1094       GP Rider (Export)
       317-0164      FD1094       Laser Ghost (Japan) ?
       317-0165      FD1094       Laser Ghost (US)
       317-0166      FD1094       Laser Ghost (Export)
       317-0167                   Aurail
       317-0168      FD1089B      Aurail
       317-0169B     FD1094       AB Cop (Export?)
       317-0170      FD1094       AB Cop ?
       317-0171      FD1094       AB Cop ?
       317-0172      EPM5032      Thunder Force AC
       317-0173                      ?
       317-0174                      ?
       317-0175      FD1094       Clutch Hitter (Japan)
       317-0176      FD1094       Clutch Hitter (US)
       317-0177      EPM5032      Dynamic Country Club (ROM version)
       317-0178      EPM5032      Ribbit
       317-0179A     FD1094       Cotton (Japan)
       317-0180      FD1094       Cotton (US)
       317-0181A     FD1094       Cotton (Export)
       317-0182      FD1094       D.D. Crew (2P, Japan) ?
       317-0183      FD1094       D.D. Crew (2P, US) ?
       317-0184      FD1094       D.D. Crew (2P, Export)
       317-0185      FD1094       D.D. Crew (4P, Japan) ?
       317-0186      FD1094       D.D. Crew (4P, US)
       317-0187      FD1094       D.D. Crew (4P, Export) ?
       317-0188      FD1094       D.D. Crew (3P, Japan) ?
       317-0189      FD1094       D.D. Crew (3P, US) ?
       317-0190      FD1094       D.D. Crew (3P, Export) ?
       317-0191      EPM5032      Quiz Rouka Ni Tattenasai
       317-0192                      ?
       317-0193      EPM5032      Twin Squash
       317-0194      FD1094       Desert Breaker (Japan) ?
       317-0195      FD1094       Desert Breaker (US) ?
       317-0196      FD1094       Desert Breaker (Export)
       317-0197A     FD1094       Wally wo Sagase! (rev A, Japan)
       317-0197B     FD1094       Wally wo Sagase! (rev B, Japan)
       317-0198                      ?
       317-0199                      ?
       317-0200      EPM5032      Tokoro San no MahMahjan
       317-0201                      ?
       317-0202                      ?
       317-0203      EPM5032      Puyo Puyo
       317-0204      FD1149       Dark Edge
       317-0205      EPM5032      Quiz Mekuromeku Story
       317-0206                      ?
       317-0207                      ?
       317-0208                      ?
       317-0209                      ?
       317-0210      FD1149       F1 Super Lap
       317-0211      EPM5032      Tanto-R
       317-0212      FD1149       Burning Rival
       317-0213                      ?
       317-0214                      ?
       317-0215      FD1149       Dragon Ball Z
       317-0216                      ?
       317-0217      FD1149       Dragon Ball Z
       317-0218                      ?
       317-0219      EPM5032      Stack Columns
       317-0220      EPM5032      Tokoro San no MahMahjan 2
       317-0221                      ?
       317-0222      FD1149       J League
       317-0223                      ?
       317-0224      EPM5032      Ichidant-R
       317-0225                      ?
       317-0226      EPM5032      Quiz Ghost Hunter
       317-0227                      ?
       317-0228      EPM5032      Puyo Puyo II



       317-5012      MC-8123A     Ganbare ChinsanOoshoubu
       317-5021      FD1089B      Sjryukoo
       317-5023      FD1094       Ryukyu

       317-5039-COM
       317-5040-COM
       317-5041-COM
       317-5042-COM
       317-5043-COM
       317-5044-COM
       317-5049-COM


       839-0068     IC61  Sega System 16A                      Sjryuko
       839-0111     EXTENSION BOARD SYSTEM II                  Mahmajn, Mahmajn2
       839-0138     Sensor board/Steering Controller           Sega System24
       
       SE-93-JCEK     ?                                        Tantr
       SE-93-JDDA     ?                                        Topshoot
       SE-94-JDDB     ?                                        Topshoot
       SE-95 JDDC     ?                                        Topshoot


       TA04      Intercommunication and sync generator chip    Aladbl
       TA05      Input controller                              Aladbl
       TA06      VDP                                           Aladbl



       WIP:
       315-5250: - 25th January 2005: Aaron Giles - Spent some time this evening playing with the compare chip (315-5250) on my E-Swat board. This chip is present on several System 16B boards as well as on the X-board systems, and is used for doing simple 16-bit compares between values. Well, at least it looks simple at the start. For the most part, the implementation I currently have works fine, but it's not good enough to get the remaining few protected Golden Axe sets working. The symptom is that your player is stuck near the top of the screen.
       315-5197: -  6th May 2006: Charles MacDonald - I've been revisiting some older hardware research I did with a fresh viewpoint and have been examining video timings for several PCBs as well as other functions: Sega 315-5197 tilemap chip (System 16B, Outrun, X-Board): 400 pixels per scanline: 29 pixels from /HSYNC high to /BLANK high (left border), 321 pixels from /BLANK high to /BLANK low (active display), 18 pixels from /BLANK low to /HSYNC low (right border) and 32 pixels from /HSYNC low to /HSYNC high (horizontal sync. pulse). 262 scanlines per frame: 20 scanlines from /VSYNC high to /BLANK high (top border), 224 scanlines from /BLANK high to /BLANK low (active display), 14 scanlines from /BLANK low to /VSYNC low (bottom border) and 4 scanlines from /VSYNC low to /VSYNC high (vertical sync. pulse). Using 6.293780 MHz pixel clock, 60.05 frames per second. Of scanlines 0-223, /XINT follows /HSYNC on line 222. It goes low when /HSYNC goes low at the start of the horizontal sync. pulse at the end of line 222, and goes high when /HSYNC goes high at the start of the horizontal sync. pulse at the end of line 223. It is asserted for exactly one scanline (400 pixels).
       315-5292: -  6th May 2006: Charles MacDonald - I've been revisiting some older hardware research I did with a fresh viewpoint and have been examining video timings for several PCBs as well as other functions: Sega 315-5292 tilemap chip (System 24, Model 1): 656 pixels per scanline:  69 pixels from /HSYNC high to /BLANK high (left border), 496 pixels from /BLANK high to /BLANK low (active display), 43 pixels from /BLANK low to /HSYNC low (right border) and 48 pixels from /HSYNC low to /HSYNC high (horizontal sync. pulse). 424 scanlines per frame: 25 scanlines from /VSYNC high to /BLANK high (top border), 384 scanlines from /BLANK high to /BLANK low (active display), 11 scanlines from /BLANK low to /VSYNC low (bottom border) and 4 scanlines from /VSYNC low to /VSYNC high (vertical sync. pulse). Using 16 MHz pixel clock, 57.52 frames per second. Setting $270001.b = $01 selects an invalid 512-scanline screen mode (same horizontal timings) where the display is enabled during the vertical sync. pulse and blanked at the wrong time. Maybe it's an unimplemented feature or used for chip testing, but it's definitely not useful. However it prevents framebuffer autoerase from working properly, so you can draw as many sprites as you want and keep the old ones.




G1.29  Seta

       X1-001A   Sprites Generators   (SDIP64)
       X1-002A   Sprites Generators   (SDIP64)
       X1-001    (also has written YM3906) Sampleplayer?         Extermination, Thundercade
       X1-002    (also has written YM3909)                       Extermination, Thundercade
       X1-003
       X1-004    Input related functions - connected to joystick/input controls (SDIP52)
       X1-005    X0-005
       X1-006    X0-006 (65c02)
       X1-007    Video DAC? - connected to RGB output (SDIP42)
       X1-010    Sound Chip, 16Bit PCM    (QFP80)
       X1-011    Tilemaps Generators (QFP100)
       X1-012    Tilemaps Generators (QFP100)
       X1-014    Sprites?


       ST-0004    Video DAC                                        Drifto94, EagleShotGolf, Srmp4, Survarts, Vasara2
       ST-0005    Parallel I/O                                     Drifto94, EagleShotGolf, Srmp4, Survarts, Vasara2
       ST-0006    Video controller                                 Drifto94, EagleShotGolf, Srmp4, Survarts, Vasara2
       ST-0007    System controller                                Drifto94, EagleShotGolf, Srmp4, Survarts, Vasara2
       ST-0009    Generate tilemaps               (QFP176)         Gdfs
       ST-0015    60EN502F12   System controller  (QFP208)         SuperEagleShot
       ST-0016    z80, gfx & sound (all in one)   (QFP208)         SuperEagleShot, Mayjinsen
       ST-0017                                                     Srmp6
       ST-0020    Generate zooming sprites  (QFP304 - heaksinked)  Gdfs
       ST-0026    NiLe (video + sound)                             Srmp6
       ST-0035                                                     Mtetris
       ST-0039                                                     Mtetris
       ST-0042                                                     11beat, Mtetris
       ST-0043                                                     11beat
       ST-0045                                                     Mtetris




G1.30  SNK

       SNK-CK 22A078801 CLK                                                Ikari3, Tnexspce
       SNK-CG 22A078802 CGO                                                Mechatt
       SNK    22A078803 IO                                                 Ikari3, Tnexspce
       SNK NEO-CMC 90G06CF7042 JAPAN 9926EAI D0358AAA (QFP240)        Kof99


       NEO-G0          QFP64
       NEO-E0          QFP64
       PRO-B0          QFP136
       LSPC-A0         QFP160
       PRO-C0          QFP136
       NEO-F0          QFP64
       NEO-D0          QFP64
       NEO-ZMC2        QFP80
       NEO-I0          QFP64



G1.31  SONY

       CXD1095Q                                      (QFP64)           MegaPlay System, SuperMonacoGP
       CXD2922CQ   SPU                               (QFP100)          RivalSchools, StreetFighterEX, BattleArenaToshinden2
       CXD2923AR   SPU                                                 Cryptkiller, NamcoSystem11 Board
       CXD2925Q    SPU
       CXD2938Q    SPU                               (QFP208)          MrDriller2
       CXD8514Q    GPU
       CXD8530BQ, CXD8530CQ   CPU                    (QFP208)          Cryptklr, KonamiGV, NamcoSystem11, Ts2, RivalSchools, StreetFighterEX, BattleArenaToshinden2
       CXD8538Q    GPU                                                 CryptKiller
       CXD8561Q, CXD8561BQ, CXD8561CQ    GPU         (QFP208)          RivalSchools, StreetFighterEX, BattleArenaToshinden2, MrDriller2
       CXD8606BQ, CXD8606CQ   CPU / GTE              (QFP208)          MrDriller2, Gamshara
       CXD8654Q    GPU                                                 Paca Paca Passion Special, TekkenTagTournament
       CXD8661R    CPU    L9A0088 WE19960 NNM 9738                     Paca Paca Passion Special, TekkenTagTournament




G1.32  Subsino

       SUBSINO 9623EX008                              QFP208           Lastfght
       SS9100                                         QFP44            Super Moto (Subsino 1996)
       SS9101                                         DIP42            Super Moto (Subsino 1996)
       SS9601                                                          Bishjan
       SS9689 6433044A22F Hitachi H8/3044             QFP100           Lastfght
       SS9802 9933                                    QFP100           Lastfght, Bishjan
       SS9803                                                          Bishjan
       SS9804 0001                                    QFP100           Lastfght
       SS9904                                                          Bishjan


G1.33  Taito


       Taito Custom Chips I:

       PC010SA     Custom Ceramic IC SIP14       PCB: Tokio
       PC030CM     Custom Ceramic IC SIP20       PCB: Bublbobl, Tokio   SOURCE: The coin inputs are handled by the PC030. It would be responsible of handling the coin counters.
       PC040DA     Video DAC         SIP19       PCB: Tokio             SOURCE: rastan.c
       PC050CM     Coin I/O                      SOURCE: drivers\rastan.c
       PC060HA     Main/Sub CPU communication    PCB: Eto, Opwolf, Rastan, Viofight, Volfied
       PC080SN     Tilemap generator             SOURCE: taitoic.h   PCB: Darius, Opwolf, Topspeed  NOTES: Darius uses 3 x PC080SN for generating tilemaps. They must be mapped somehow to a single memory block and set of scroll registers. There is an additional text tilemap on top of this, to allow for both background planes scrolling.
       PC090OJ     Sprite generator              WIP: 14th February 2002: David Graves consolidated the emulation of the Taito sprite chip PC090OJ.



       Taito Custom Chips II:

           -        TC0100SCN    TC0200OBJ    TC0300FLA    TC0400YSC        -
       TC0010VCU    TC0110PCR    TC0210FBC    TC0310FAM        -        TC0510NIO
       TC0020VAR    TC0120SHT    TC0220IOC    TC0320OBR        -        TC0520TBC
       TC0030OMD    TC0130LNB        -            -            -        TC0530SYC
       TC0040IOC    TC0140SYT        -        TC0340BEX        -        TC0540OBN
       TC0050VDZ    TC0150ROD        -            -            -            -
       TC0060DCA    TC0160ROM    TC0260DAR    TC0360PRI        -            -
       TC0070RGB    TC0170ABT    TC0270MOD    TC0370MSO    TC0470LIN    TC0570SPC
       TC0080VCO    TC0180VCU        -        TC0380BSH    TC0480SCP    TC0580PIV
       TC0090LVC    TC0190FMC        -        TC0390LHC        -        TC0590PIV


           -            -            -
           -            -            -
       TC0620SCC        -            -
       TC0630FDP        -            -
       TC0640FIO        -        TC0840GLU
       TC0650FDA        -            -
       TC0660FCM        -            -
           -        TC0770CMU    TC0870HVP
           -        TC0780FPA        -
           -            -            -



       TC0020VAR                  Sprites?
       TC0030OMD                  C-Chip protection
       TC0050VDZ                  Sprites?
       TC0070RGB     28 pin       Palette/Video DAC
       TC0080VCO                  Tilemaps   (Combined tilemap and motion object generator)
       TC0090LVC                  C-Chip protection (Z80)
       TC0100SCN     QFP160       GFX (row and column)
       TC0110PCR     100 pin      Palette
       TC0140SYT                  Sound communication. Main/Sub CPU interface + Sub CPU address decoder and I/O interface.
       TC0150ROD                  GFX - Road generator
       TC0190FMC                  Input      (4 players input?sprite banking?)
       TC0220IOC                  I/O interface
       TC0260DAR     QFP100       Palette
       TC0280GRD                  ROZ
       TC0310FAM                  Sound volume and panning
       TC0320OBR                  Sprites
       TC0360PRI     QFP100       Priority
       TC0430GRW                  ROZ
       TC0480SCP                  GFX (row and column)
       TC0510NIO                  I/O
       TC0520TBC     QFP100       Sprites
       TC0530SYC     QFP160       Sound communication
       TC0540OBN     QFP160       Sprites
       TC0590PIV                  Tilemaps  (Undrfire)
       TC0620SCC                  Lightgun ??? pivot port ???   (Undrfire)
       TC0630FDP     QFP208       Playfield generator?  (Nearest tile roms)
       TC0640FIO     QFP120       I/O & watchdog?
       TC0650FDA     QFP100       Priority mixer?  (Near paletteram & video output)
       TC0660FCM     QFP160       Sprites? (Nearest sprite roms)
       TC0770CMU     QFP208
       TC0780FPA     QFP240
       TC0840GLU     QFP144       TCO840GLU (Landgear, Sidebs/2)
       TC0870HVP     QFP208



       WIP:

       TC0100SCN      
       - 0.123u4            : Zsolt Vasvari fixed taitoic regression that caused crashes in several games.
       - 0.108u4            : Robzia fixed TC0100SCN flipscreen mode for Liquid Kids and other games using the same Taito graphics chips.
       - 0.100u4            : Bryan McPhail fixed flipscreen in TC0100, which improves Liquid Kids.
       - 0.97u5             : Nicola Salmoria fixed TC0100SCN row scroll (Thunder Fox and Warrior Blade).
       - 0.97u2             : Pierpaolo Prazzoli fixed video problems in Warrior Blade, which broke with the new TC0100SCN colscroll addition.
       - 0.97u1             : Bryan McPhail implemented column scroll in TC0100SCN chip; used on (at least) The Ninja Kids, Gun & Frontier, Growl and Galmedes.
       -  4th December  2000: David Graves added support for a third Taito TC0100SCN chip emulation.
       -  1st December  2000: David Graves updated the TC0100SCN Taito chip emulation to support extra wide tilemaps, making Darius 2, Ninja Warriors and Warrior Blade playable.
       - SOURCE: video\taitoic.c

       TC0150ROD
       -  2nd September 2001: David Graves added preliminary support for the Taito TC0150ROD road graphics chip used in the Taito Z games, and he also optimized the sprite drawing in Top Speed.

       TC0360PRI
       - 0.98u1             : Bryan McPhail fixed one of the TC360 sprite blending modes (used in Pulirula round 2 and Liquid Kids attract mode).
       - 0.89u1             : Bryan McPhail added the TC0360PRI blending modes to the games with rotation layers. This includes Pulirula & Liquid Kids. One of the blending modes is new to these games (not used in Gun Frontier) and I have no way to verify it's actually correct - someone with a working board will need to verify (Liquid Kids: Fish going in water in attract mode, Pulirula: Crystals on level 2).

       TC0480SCP
       - 14th January   2001: David Graves added double width tilemap support to the TC0480SCP chip emulation and wrote a Slap Shot driver but it has incomplete sprite graphics decoding so some graphical errors remain.



G1.34  Tecmo

       TECMO-3                                                      Spbactn, Stratof
       TECMO-4                                                      Spbactn, Stratof
       TECMO-5     MCU? clock input 6.000MHz on pin15 (SDIP64)      Riot, Spbactn, Stratof, Ginkun
       TECMO-6     or TECMO-06  YM6048       (QFP160)               Riot, Spbactn, Stratof, Ginkun
       TECMO-7     or TECMO-07  YM6621       (QFP160)               Riot
       TECMO-8                               (QFP136)               Riot
       TECMO-9,    MN53030XTB                (QFP124)               Riot
       TECMO-10                              (QFP128)               Riot
       TECMO-11    MN51005XTC                (QFP64)                Riot
       TECMO-12    MN51005XTD                (QFP64)                Riot

       TECMO       MN50005XTA                                       Stratof
                   MN53007TQA    MCU on Toaplan PCB                 Vimana

       TECMO AA02-1927          (QFP160)                            Deroon, Tkdensho
       TECMO AA03-8431          (QFP208)                            Deroon, Tkdensho






G1.35  Technos


       TJ-001     TECHNOS  TJ-001        (QFP80)    Agress
       TJ-002                                       Shadfrce, Wwfwfest
       TJ-003                                       Wwfwfest
       TJ-004                                       Shadfrce, Wwfwfest
       TJ-005                                       Shadfrce


G1.36  Toaplan

       Toaplan-02 M70H005 7Z2001                                Truxton
       Toaplan-02 M70H005 7Y2002                                Rallybik

       L7A0498 GP9001 TOA PLAN 9044      (QFP208)               Ghox, Fixeight
       L7A0498 GP9001 TOA PLAN 9150                             Fixeight, Grind Stormer
       L7A0498 GP9001 TOA PLAN 9152                             Truxton II
       L7A0498 GP9001 TOA PLAN NNG 9217 WK94254                 Armed Police Batrider
       L7A0498 GP9001 TOA PLAN 9236                             Battle Garegga
       L7A0498 GP9001 TOA PLAN 9335                             Battle Bakraid
       L7A0498 GP9001 TOA PLAN 9240                             Mahou Daisakusen

       TOAPLAN JAMMA HK-1000 1070001     (48 pin)               Ghox, Fixeight

       BCU-2         Background? GFX     (PQFP160)              Vimana
       FCU-2 8J1     Foreground? GFX     (PQFP136)              Truxton



G1.37  V-System

       - NOTES: Various Video System Co. games using the V-System graphic chips C7-01 GGA, VS8803, VS8904 and VS8905. The VS8904/8905 chips handles sprites and the VS8803 tilemap.
       - PCB: Aerofgt, F1gp, Pipedrm, Pspikes, Quiz18k, Tail2nos, Welltris

       V-System C7-01 GGA
       VS8803
       VS8904 (QFP64)
       VS8905 (QFP80)


       - PCB: F1gp, F1gp2, Fromancr, Fromanc2, Fromanc4, Gstriker, Inufuku Suprslam, Taotaido

       VS9108 =  Fujitsu CG10103 145 9520 Z14    (QFP160)     Sprite chip
       VS9209 4L01F1429 JAPAN 9523EAI            (QFP64)
       VS920A
       VS920B
       VS920C                                    (144pin)
       VS920D 4L04F1689 JAPAN 9524EAI            (QFP160)
       VS920E 4L06F1057 JAPAN 9533EAI            (QFP176)
       VS920F 4L01F1435 JAPAN 9524EAI            (QFP100)
       VS9210 4L06F1056 JAPAN 9525EAI            (QFP176)
       VS9611

       NOTES:
       - The VS920A is a (very) simple tilemap chip with 1 Plane, Tiles 8x8, 4bpp, Map 64x64 and no scrolling or other effects.
         SOURE: video\gstriker.c





G2.    Custom Video


G2.1   Signetics

G2.11  S2636
- 0.37b10            : Added vidhrdw\s2636.c + s2636.h.
- NOTES: The Signetics 2636 is a video chip for Sprite-Object/Background collision detection
- SOURCE: emu\video\s2636.c   +   drivers\cvs.c, malzak.c, quasar.c and zac2650.c
- GAMES: The Invaders (Zaccaria 1978), Quasar (Zaccaria 1980), Cosmos (Century Electronics 1981), Malzak (Kitronix)
- PCB: S 2636N, DIP 40 (Malzak), 2636 40-pin (Galaxia), Signetics 2636 (Catnmous)

G2.12  S2637
- Not emulated!
- NOTES: The Emerson Arcadia console used a Signetics 2637 chip for its sound and graphics, and the Signetics 2636 is simply an earlier revision of this chip.
- GAMES: Zaccaria - Cat 'n' Mouse (1982), Lazarian  (1982)



G2.2   Atari

G2.21  TIA

- 0.117u3            : Wilbert Pol added an optional vsync callback to the TIA emulation to allow a driver to dynamically change the screen configuration.
- 0.117u2            : More TIA improvements [Wilbert Pol]: Fixed some minor missile graphics positioning issues. Moved some initialization code from tia_init to tia_reset.
- 0.116u4            : Some more TIA graphics and sound improvements [Wilbert Pol]: INPT4 and INPT5 are now read when needed instead of by a timed function. This removes the need for the tia_init_pal function. Improved handling of the HMOVE functionality. Added code to reduce the flickering caused by some Atari 2600 games. Improved the sound poly generation. Improved the handling of POLY5_DIV3 sound mode.
- 0.116              : More TIA updates from MESS [Wilbert Pol]: Rewrote drawing of playing graphics. Improved handling of player graphics reset signals. Improved handling of HMOVE signals.
- 0.115u3            : Wilbert Pol updated TIA graphics code (code comes from the MESS repository). Also updated Tournament Table driver to accommodate the changes.
- 0.111u5            : Nathan Woods updated the TIA video driver to use the new BITMAP_ADDR* macros instead of using the line[] array.
- 0.111u2            : Nathan Woods changed TIA code to only allow initialization at init time.
- 0.111u1            : Nathan Woods fixed reset problem in the TIA emulation (video\tia.c).
- 0.97u3             : Wilbert Pol fixed a minor bug in TIA emulation (video\tia.c), taken from the MESS code.
- 0.68               : Added vidhrdw\tia.c.
- NOTES: TIA = Television Interface Adapter
- SOURCE: video\tia.c
- GAMES: Tournament Table (1978)

G2.22  GTIA
- NOTES: GTIA = Graphics Television Interface Adapter - Atari 400/800. Based on Atari 400/800 MESS driver by Juergen Buchmueller
- SOURCE: video\gtia.c + video\atari.c
- GAMES: Exidy Max-A-Flex games

G2.23  ANTIC
- NOTES: Video controller. Based on Atari 400/800 MESS briver by Juergen Buchmueller.
- SOURCE: video\antic.c
- GAMES: Exidy Max-A-Flex games

G2.24  AMD 29C101
- NOTES: The early-to-mid 90's Atari raster games use RLE-compressed sprites. These sprites were decoded, colored, and scaled on the fly using an AMD 29C101 ALU unit. The instructions for the ALU were read from 3 512-byte PROMs and fed into the instruction input (see video\atarirle.c).
- GAMES: Atari Games - Hydra(1990), Primal Rage

G2.25  ASIC65
- 0.77               : Aaron Giles improved ASIC65 logic for Road Riot 4WD - almost playable and added support for Guardians of the Hood.
- 0.62               : Added machine\asic65.h.
- 0.59               : Added machine\asic65.c.
-  6th February  2002: Aaron Giles added the missing ASIC65 source file.
- NOTES: The ASICs are used to speed up the simulation, so they likely perform complex math operations or graphics operations.
- NOTES: Road Riot 4WD (1991): (Aaron Giles) The core hardware is pretty similar to Hydra, but the emulation suffers from the lack of understanding of a custom ASIC on the board. Apparently this ASIC is used for complex math operations, and improper emulation of it leads to incorrectly drawn roads and crashes. It is likely this game also uses a SLOOP (son-of-slapstik) chip for protection. The sound board is a standard Atari 6502, YM2151 and ADPCM board.
       - Guardians of the 'Hood (1992): (Aaron Giles) Runs on the same hardware as Road Riot 4WD, but seems to have a much simpler chip in place of the custom ASIC. On the other hand, it is still unplayable due to a lack of understanding of the SLOOP protection chip.
       - The Namco System II board is a 5 ( only 4 are emulated ) CPU system. The complete system consists of two boards: CPU + GRAPHICS. It contains a large number of custom ASICs to perform graphics operations, there is no documentation available for these parts.
- GAMES: Namco System II, Atari G42
- SOURCE: machine\asic65.c



G2.3   MOS

G2.31  MOS6560
- NOTES: See VIC6560

G2.32  VIC6560
- 15th August    2005: Tomasz Slanina - Game is running on VIC6560 - like chip MOS6560, with few changes in the internal structure. Video, colors and sounds are emulated now (based on PeT's 6560 code from MESS).
- NOTES: Video and sound emulation based on MOS 656x driver by PeT (MESS)
- NOTES: Differences between 6560 and Attack Ufo derivative chip: No invert mode, no multicolor and 16 col chars.
- GAMES: Added Attack Ufo (Ryoto Electric Co. 1980)
- SOURCE: video\attckufo.c and audio\attckufo.c
- PCB: VIC 6560 40pin IC "C" (Attckufo)



G2.4   Nintendo

G2.41  2C0X PPU
- 0.124u5            : NES/PlayChoice 10 changes [Mariusz Wojcieszek]: Added support for mapping ROM and RAM in PPU video memory space.
- 0.117u2            : Removed video\ppu2c03b.h.
- 0.116              : Removed video\ppu2c03b.c.
- 0.111u5            : Nathan Woods updated the Nintendo 2C03B PPU video driver to use the new BITMAP_ADDR* macros instead of using the line[] array.
- 0.108u1            : Added video\ppu2c0x.c. Major cleanup/rewrite of the NES PPU rendering code [Brad Oliver]. This should improve the accuracy of the NES-based games (playch10.c and vsnes.c). Report anything odd or broken at MAMETesters.
- 0.104u5            : Nathan Woods changed the NES PPU interfaces to follow new struct conventions.
- 0.102u3            : Rob Bohms fixed $4014 sprite DMA in NES PPU.
- 0.97u2             : Andrew Church fixed NES PPU video timing.
- NOTES: The RP2C04 PPU chips are functionally interchangeable, but the colors will be different than normal. This code is heavily based on Brad Oliver's MESS implementation.
- SOURCE: video\ppu2c0x.c
- PCB: RC2C03B (Duckhunt, Vstennis), RP2C03C (Smgolf, Vspinbal), RP2C04 (Bnglngby, Hogalley, Iceclimb, Machridr, Vsbball), RC2C05 (Jajamaru)



G2.5   Philips

G2.51  SAA 5020
- PCB: Philips SAA 5020, DIP 24 (Malzak), Special Function TV Interface Circuit - Teletext Timing Chain Display Contoller

G2.52  SAA 5050
- NOTES: Teletext character generator
- SOURCE: video\malzak.c
- PCB: SAA5050, DIP 28 (Malzak)


G2.6   Blitter
- 13th April     2005: Aaron Giles - Picking up from my last article on blitters, the next thing I was going to talk about was how to time a blitter. At a rough guess, if you have schematics handy, you can look at a blitter chip and do an approximation of how long a blit will take. A blitter chip, like a CPU, needs a clock, so that's a good starting point. For example, the blitter on the classic Williams games (Joust, Robotron, etc) runs at 4MHz. That means it's going to be limited to 4 million operations in a second. But you can go beyond that. If you look at the width of the data bus that the blitter has, then you can tell how many bits it can operate on at a time. The Williams blitters have a 4-bit bus, and there are two of them running in parallel, so that's 8 bits per operation, or 2 4-bit pixels. Taking the guessing game one step further, if there is only one address bus on the chip (as is the case for the Williams blitters), then it can't read graphics data from the source and write to a target at the same time. In fact, it will need to constantly swap back and forth between the source address and the destination address. So, assuming that it takes one clock to read a source byte, one clock to swap to the target address, one clock to write a target byte, and one clock to swap back to the source address, you're looking at 4 clocks per operation. So, putting all this together, I'd have a first guesstimate that the Williams blitter could handle (4000000 clocks / 4 clocks per operation) * (8 bits per operation / 8 bits per byte) = 1 million bytes per second, give or take. So that's the ballpark to expect. I'm currently working on an update to the early Williams games that will factor this in, in the hopes that Robotron might slow down enough to match the arcade (a number of folks have noticed that Robotron runs too fast in MAME at the higher levels). Of course, the ideal situation would be if we could measure this directly. Unfortunately with the Williams games, there's no obvious way to do it because the blitter HALTs the main CPU while the blit is happening, in order to gain full control over the systemwide address and data busses. If I had an oscilloscope and a PCB to play with, I could probably do some measurements that way. But there's no obvious software path to do it. (Okay, I lied, there is one: I could program the sound CPU to measure the timing, and then send start/stop signals to the sound CPU just before/after the blit is done. That might be worth trying). Fortunately, most later hardware that used blitters decided that it didn't really make sense to suspend the main CPU while a blit was happening, so they were designed to operate in parallel with the main CPU. These are generally known as an "asynchronous blitters". The Incredible Technologies blitters are like this. The nice thing is that this setup makes it relatively straightforward to measure how long blits of different sizes take to complete. Having done this now for the 8-bit IT games, I'll describe the gory details in my next blitter-related post.
-  6th April     2005: Aaron Giles - A number of games I've done drivers for (Williams, Strata, Art & Magic, etc) use blitters as their way of drawing graphics on the screen. This is different from the way most arcade games work, and is actually much more similar to a modern computer. In these games (and in computers), there is a large chunk of video memory which is called the "frame buffer". The frame buffer contains 'n' bits of information for each pixel you see on the screen. Now, one immediate problem you run into with a frame buffer is that there is some hardware that is constantly scanning through this memory and pushing that data to the screen. If you are in the middle of modifying a bunch of pixels and the scanner intersects the area you are drawing to, then you can produce an effect called "tearing", where a partially rendered object is displayed (this is a simplification, but it illustrates the general idea). To get around this, most blitter-based games have two frame buffers. At any given time, one of the frame buffers is actively being scanned and displayed to the screen, while drawing happens to the other frame buffer. After the beam has scanned to the bottom of the display, the two buffers are swapped. This is known as "page flipping". The early Williams games didn't have enough video RAM to do page flipping, so they had to be very aware of what scanline was currently being displayed. Once the scanning beam had passed below the area of video RAM they wanted to animate, then they could make their changes without fear of tearing. This is generally referred to as "drawing behind the beam". So where does a blitter come into play? Well, in general it was entirely possible to sit there and muck about with the frame buffer using the main CPU. In fact, Defender doesn't have a blitter at all - it is all drawn by the main CPU. The problem is that it takes a lot of CPU power to draw lots of pixels on the screen. And although a CPU can certainly accomplish a lot, it is not specifically designed for drawing lots of pixels at high speeds. One solution to this could be to add a second CPU that is responsible for drawing the graphics, based on commands from the first CPU. In fact, a number of games such as Gyruss and the Cinematronics/Leland games (Quarterback, Ataxx, Super Off Road, etc) do just that. However, a CPU is an expensive part. And it's not optimized for doing graphics. So a number of folks caught onto the idea of designing custom ICs that were dedicated to performing very fast graphics operations. In general, it's not enough to just draw pixels, these chips also had to do a lot of bit manipulation and address computations to handle things like X and Y flipping, transparency, scaling, etc. The term that has come up over time to describe this kind of operation (copying large arrays of data and manipulating them during the copy) is a "blit". And custom chips that are dedicated to this sort of work are called blitters. So, you can think of a blitter as a custom chip that is designed to copy graphics (which are normally stored in ROM or RAM) to a frame buffer while manipulating the data in a programmed fashion. So what makes this tricky in MAME? Well, first off, every company designed their own blitter. There is no standard way of blitting. Generally, this just takes some reverse engineering power and a lot of patience to figure out what's happening. The really tricky part is the fact that blitters don't perform their operations instantaneously - it takes some time to actually shuffle through all that data and render it to the frame buffer. As a simplification, most blitters in MAME are implemented as "instantaneous" blitters, meaning they complete instantly. The problem is that many games rely on the speed of the blitter to limit their speed, or else overtax the blitter so that the original game slowed down when too much was being drawn at one time. Figuring out how fast the blitters operated is the trick, and I'll talk more about that next time.
- 0.95u2             : Aaron Giles rewrote blitter implementation to be much simpler (no more macros) and measured and implemented accurate blitter timing (fixes some speed problems).


G2.61  Fujitsu MB1551x
- NOTES: Halley's use 2x Fujitsu MB15510, MB15511 and MB15512 blitter coprocessors for rendering graphics layers.
- GAMES: Halley's Comet (Taito 1986)


G2.62  ITV4400
- NOTES: ITV4400 custom blitter for rendering
- GAMES: Wheel Of Fortune (1989), Dyno Bop (1990), Hot Shots Tennis (1990) and Ninja Clowns (1991)
- SOURCE: drivers\itech8.c and video\itech8.c
- PCB: Incredible Technologies ITV4400 CF93458FN (Dynobop, Hstennis)


G2.63  GA9201
- NOTES: The GA9201 is a custom blitter chip (120pin IC).
- GAMES: Shanghai III (1993), Blocken (1994), Hebereke no Popoon (1994)
- PCB: GA9201 KA01-0249 JAPAN 9332EAI, QFP120 (Heberpop)



G2.7   Collision chips

- 26th November  1999: Zsolt Vasvari added The Percussor to the Zodiack driver, and he fixed the collision detection in Crazy Balloon and in the TaitoSJ games.
- 26th October   1999: Phil Stroffolino got collision detection working in Vulcan Venture with help from Dave Spicer and Nao.
-  7th September 1999: Nicola improved Vendetta collision detection.
- 29th August    1999: Ernesto Corvi finally added sprite-sprite collisions to Thunder Cross.
- 16th August    1999: Ernesto Corvi emulated the collision chip in Vendetta, and the game is now fully playable.


G2.71  PC3259
- NOTES: The PC3259 is a sprite/char collision detection
- SOURCE: grchamp.c, crbaloon.c, bking2.c


G2.8   TLC34076
- 0.122u6            : Zsolt Vasvari changed TLC34076 and games using it to RGB32. Removed global Machine variable where possible.
- 0.64               : Added vidhrdw\tlc34076.c.
- 17th January   2003: Aaron Giles abstracted the TLC34076 palette chip emulation used by Art & Magic, Battletoads and a few other drivers.
- SOURCE: emu\video\tlc34076.c


G2.9   YGV608
- 0.99u9             : Aaron Giles removed tilemap_dispose call and fixed the two drivers that were using it. This fixes improper save state registrations in megasys1 and ygv608 games.
- 0.86u4             : Mark McDougall added tile flipping in NCV2.
- 25th March     2003: David Haywood fixed the incorrect graphics in Namco Classics Vol.2 but it still crashes when trying to start a game.
-  4th July      2001: Mark McDougall added Namco Classics Vol.2 to the ncv1 driver, but it doesn't quite work because of missing rotation / zoom emulation.
- 0.37b16            : Added vidhrdw\ygv608.c.
- 11th June      2001: Mark McDougall worked on adding Namco Classics Vol.2, but the driver isn't complete yet.
-  8th June      2001: Mark McDougall sent in his Namco Classics Collection Vol.1 driver, which lacks some graphical effects and sound.
- NOTES: Yamaha YGV608 - PVDC2 Pattern mode Video Display Controller 2. Controlls screen size, rotation, split-screen scrolling, scaling...
- SOURCE: video\ygu608.c
- PCB: Yamaha YGV608-F  video controller, QFP100 (Ncv1, Ncv2)



G2.A   Midway ICs
- 0.82u2             : Aaron Giles added support for sfrushrk PIC, timeout on PIC reads to speed up sfrushrk and fixed missing sound reset latch at startup.
- 0.81u5             : Aaron Giles added faux support for setting the real time clock (to pass diags), added shuffle map for Vapor TRX and implemented crude loopback in UART (to pass diags).
- 0.78               : Aaron Giles added sound auto acknowledgement option, added new PIC mapping for Gauntlet: Dark Legacy and fixed initial sound IRQ state. DCS: Fixed reporting of input full/output empty states.
- SOURCE: machine\midwayic.c


G2.B   Data East Ace/Jack
- NOTES: Dragon Gun (1993) and Tattoo Assassins (1994) use an unemulated chip (Ace/Jack) for special blending effects. It's exact effect is unclear.
- SOURCE: drivers\deco32.c




G3.    2D Graphic

G3.1   VRender Zero
- 0.93               : Aaron Giles fixed a VRender0 clipping bug that was lurking there (negative clipping wrapped to positive values -- noticeable at 32-bits).
- 0.90               : VRender Zero emulation [ElSemi].
- DRIVER: The CRYSTAL SYSTEM using a VRender0 System on a Chip. The chip contains: CPU Core SE3208 (info at www.adc.co.kr) @ 43Mhz, 2 DMA chans, 4 Timers, 32 PIO pins, PWM output, 32 channels wavetable synth (8bit linear, 16bit linear and 8bit ulaw sample format) and Custom 2D video rendering device (texture mapping, alphablend, roz)
- NOTES: The VRender0 is a very special 2D sprite renderer. The spec says it's based on 3D technology. The device processes "display lists" that contain pointers to the texture, tex coords and the step increments on x and y (dxx,dxy,dyx,dyy) allowing ROZ effects on sprites. It supports alphablend with programmable factors per channel and for source and dest color.
- SOURCE: video\vrender0.c
- PCB: MESGraphics VRenderZERO (all-in-one main CPU/Graphics/Sound, QFP240) (Crysking)




G4.    3D Graphic

G4.1   Polygon games

       Game                          Manufacturer         Source         Notes

       Tunnel Hunt                   Atari (1979)         tunhunt.c      The video hardware includes: box-on-box expansion in hardware (effectively one of the earliest polygon rendering games) for rendering the tunnel. Scalable sprites for targeting cursor and player shots. These can be tiled fullscreen for the shield (grid) effect. Hardware decompression and stretching of run-length-encoded motion-object data for enemy shots, ships, and the title screen graphic and alphanumeric text layer.
       "I, Robot"                    Atari (1983)         irobot.c       M6809 (1.5MHz)
       Hard Drivin'                  Atari (1988)         harddriv.c     TMS34010 to render the polygons and graphics
       S.T.U.N. Runner               Atari (1989)         harddriv.c     TMS34010 to render the polygons and graphics
       F-15 Strike Eagle             Microprose (1990)    micro3d.c
       Galaxian^3                    Namco (1990)                        6-player laserdiscs polygon game
       Race Drivin'                  Atari (1990)         harddriv.c     TMS34010 to render the polygons and graphics
       Solvalou                      Namco (1991)         namcos21.c
       Starblade                     Namco (1991)         namcos21.c
       Steel Talons                  Atari (1991)         harddriv.c     TMS34010 to render the polygons and graphics
       Winning Run 91                Namco (1991)         namcos21.c
       Air Combat                    Namco (1992)         namcos21.c
       Battle of the Solar System    Microprose (1992)    micro3d.c
       Cyber Sled                    Namco (1993)         namcos21.c
       Ridge Racer                   Namco (1993)         namcos22.c
       Ace Driver                    Namco (1994)         namcos22.c
       Ridge Racer 2                 Namco (1994)         namcos22.c
       Air Combat 22                 Namco (1995)         namcos22.c
       Alpine Racer                  Namco (1995)         namcos22.c
       Avengers In Galactic Storm    Data East (1995)     deco_mlc.c
       Cyber Commando                Namco (1995)         namcos22.c
       Cyber Cycles                  Namco (1995)         namcos22.c
       Rave Racer                    Namco (1995)         namcos22.c
       Prop Cycle                    Namco (1996)         namcos22.c


- 0.120u4            : Removed video\polynew.c/h. Aaron Giles updated model2.c, taitojc.c and gticlub.c to use the new polygon routines. Deprecated the old poly.c and renamed polynew.* to poly.*. Unified poly.c callbacks so that tri and quad callbacks work the same way.
- 0.120u3            : Aaron Giles expanded polynew.c to support quad rendering. Converted midvunit.c over to using the new quad rendering, which fixes a number of rendering issues that have plagued the driver since the start. Aaron Giles added Z-clipping logic to polynew.c. Converted namcos22 over to using that code. Simplified namcos22 significantly, working in quads throughout the lower-level pipeline and then handing the results off to polynew.c.
- 0.120u1            : Aaron Giles created new module polynew.c which combines triangle setup, rasterization and Voodoo-like multiprocessor support. Coverted Gaelco3D, Midway V-Unit, Namco System 22 and Voodoo drivers over to the new system.
- SOURCE: emu\video\polynew.c



G4.2   Sprites games

G4.21  Sega 16-bit hardware
- 22nd March     2005: There were several problems with Line of Fire. Particular that game, all of which are interesting, and none of which had anything to do with the CPU interleaving that I originally thought was the source of my troubles. In the end, it mostly came down to the divide chip. As I mentioned previously, the game will sometimes attempt to divide by zero. Now, the divide chip has flags to let you know that you've caused an error, but the game never reads them. It would then take the result of the divide-by-zero, look it up in a table, and use the resulting value in future calculations. The problem is that the table was only ~32 entries long, so when I tried returning 32767 as the result of a divide by zero, it read some random ROM location and used that instead of a valid value. To work around this, I am guessing that divide by zero either returns 0 or 1. I'll have to work with Charles to figure the exact details out. But all that served to fix was the fast/slow/fast/slow speed at which you moved through the level, and which eventually ended up hanging the game. Once that was all better, the game would hang right near the end of the first level. At least that part was consistent. First, though, I had to fix the jittery sprites. I was pretty sure there was no way this game would be that poorly done (though at the same time I think the Sega fanboys make a few too many assumptions that Sega would never have graphics glitches in their games). I first started guessing that the divide chip actually didn't do a full 32-bit by 16-bit divide, but rather maybe a 24-bit by 16-bit divide, or some other reduced accuracy version. This actually produced smoother results, but it screwed up a lot of other stuff too. Eventually I noticed that the value 0x8000 was being used as the divisor quite often, while at other times it was using values in the 0x7f00 range. If I treat those values as signed 16-bit values, then the 0x8000 would suddenly flip from +32000 to -32000, which seemed kind of odd. So I tried going back to a full 32-bit by 16-bit divide, but treating the values as unsigned, and suddenly things were much easier to look at. But back to the hang at the end of level 1. I eventually put a trace on both the CPUs right near the end of the level, in order to see what was happening. It turned out that the main CPU would execute some code, then jump backwards into the middle of an instruction. This is a clear sign that something seriously bad was happening. On a hunch, I tried loading up the Japanese version of the game and looking at the equivalent code. Turns out one word in the World version ROM was wrong. But if the ROM dump was bad, then it wouldn't have passed the memory test in service mode. The only other logical explanation is that there must be a small error in the decryption key for the World version. Hopefully "The Doctor" will figure that out for me. Related to the divide chip issue was the bug that made GP Rider behave strangely. My original divide chip implementation had us recomputing the results every time the dividend or divisor was changed. But it turns out (and is actually pretty clear from the schematics, now that I've looked at them again) that the divide is actually explicitly triggered by writing to a higher address. The reason this was important for GP Rider is that they would trigger one divide, and then load the dividend for the next divide before reading the result of the previous divide. With my original code, writing the dividend for the second divide was trashing the results of the first divide.
- 0.94u5             : Aaron Giles fixed several divide chip behaviors (segaic16.c), fixing Line of Fire and GP Rider (divide by zero just returns the divisor (needs to be verified), mode 1 divides are unsigned and divides are only triggered by a write with A4 set).
- 0.94u2             : Aaron Giles implemented Y-board sprite priorities (not fully understood, but seems to work), found missing 8th bit in Outrun/X-board sprite pitch, implemented Outrun/X-board road priorities according to logic dump from Leopardcats, hooked up road RAM double buffering that was missing for Outrun/X-board and disabled direct scanline mode for Outrun road, which doesn't support it (video/segaic16.c). In machine/segaic16.c he changed divide-by-zero case to return a value.
- 0.91               : Aaron Giles added support for 3 multiply chips and 3 divide chips and fixed timer/compare chip implementation to match real PCB (machine/segaic16). Also added tilemap flipping support and sprite flipping support for 16A and 16B sprites (video/segaic16).
- 0.90u4             : Aaron Giles cleaned up tilemap handling using the new user_data feature and added pixel-accurate scaling to System 16B sprites (video/segaic16.c).
- 0.90u1             : Aaron Giles unified all memory mapping code and moved it into machine/segaic16.c, unified all tilemap, sprite and road code and moved it into video/segaic16.c and improved documentation on the various register layouts on the video side. Note that in the process, I broke the title screen animation for Laser Ghost, and there is now a 1-pixel column error on ddcrew's attract mode. These are known issues that I will try to address soon.
- 0.89u5             : Aaron Giles cleaned up the math chip emulation (machine\segaic16.c), should be much closer now.
- 0.89u3             : Aaron Giles created a new machine/segaic16.c to hold non-video common hardware, preliminary multiply/compare implementation moved there and changed segaic_init_palette to take a number of palette entries.
- SOURCE: machine\segaic16.c + video\segaic16.c and drivers\segahang.c + segaorun.c + segas16b.c + segas18.c + segaxbd.c + segaybd.c
- GAMES: Space Harrier (1985), Out Run (1986), After Burner II (1987), Thunder Blade (1987), Super Hang-On (1987), Galaxy Force 2 (1988), A.B. Cop (1990), Strike Fighter (1991)


                 CPU      Tiles      Sprites   Priority  Color     SCPU  Sound                Other
  System C       68000    315-5313                       315-5242  z80   ym3438               315-5296(IO)
  Space Harrier  68000x2                                 (c)       z80   ym2203 pcm(b)
  System 16B     68000    315-5197   315-5196  GAL       (c)       z80   ym2151 upd7759       315-5195
  After Burner   68000x2  315-5197   315-5211A GAL       315-5242  z80   ym2151 315-5218      315-5250(a) 315-5248(x2) 315-5249(x2) 315-5275(road)
  System 18      68000    315-536x   315-536x            315-5242  z80   ym3834(x2) RF5c68(d) 315-3296(IO) 315-5313(vdp)
  Galaxy Force   68000x3             315-5296+ 315-5312  315-5242  z80   ym2151 315-5218      315-5296(IO)

  Hang-on hardware        : The first one. Two tilemap planes, one sprite plane, one road plane. The shadow capability doesn't seem to be used, the highlight/shadow switch in the 5242-equivalent is global for all colors.
  Space harrier hardware  : Similar to hang-on, with per-color highlight/shadow selection, and the shadows are used.
  System16a / Pre-system16: Space harrier without the road generator.
  System16b               : 4-layer tilemap hardware in two pairs, with selection between each members on the pairs on a 8-lines basis. Slightly better sprites.
  System18                : System 16b plus a genesis vdp.
  Outrun                  : System 16b with sprites with better zooming capabilities, plus a road generator able to handle two roads simultaneously.
  X-Board                 : Outrun with a better fillrate and an even more flexible road generator.
  Y-Board                 : New design, with two sprite planes and no tilemaps. The back sprite planes has a huge fillrate and the capability to have its frame buffer completely rotated. Also, it has a palette indirection capability to allows for easier palettes rotations. The front sprite plane is 16b.


G4.22  Sega System24
- 0.68               : Added vidhrdw\segaic24.c.
- NOTES: The odd one out hardware. Medium resolution. Entirely ram-based, no graphics roms. 4-layer tilemap hardware in two pairs, selection on a 8-pixels basis. Tile-based sprites(!) organised as a linked list. The tilemap chip has been reused for model1 and model2, probably because they had it handy and it handles medium res.
- SOURCE: video\segaic24.c and drivers\system24.c + model1.c + model2.c
- GAMES: Virtua Racing (1992), Daytona USA (1993), Star Wars Arcade (1993), Virtua Fighter (1993), Wing War (1994), Manx TT Superbike (1995)

                 CPU      Tiles      Sprites   Priority  Color     SCPU  Sound                Other
  System 24      68000x2  315-5292   315-5293  315-5294  315-5242        ym2151 dac           315-5195(x3) 315-5296(IO)
  System 32      V60      315-5386A  315-5387  315-5388  315-5242  z80   ym3834(x2) RF5c68(d) 315-5296(IO)




G4.23  Sega System32
-  5th July      2005: Aaron Giles - System 32 is certainly a curious beast, and one of the most intriguing parts of the system is the mixer chip. The mixer chip is the bit that takes input from 8 different video sources - 4 tilemap layers, one text layer, one bitmap layer, one background layer, and one sprite layer - and determines which layer is visible for each pixel. Beyond that, it is also responsible for looking up the palette entry of that pixel and generating the final RGB values for it. Along the way, it has the capability to adjust the RGB values and perform some blending, along with a host of other wacky functions. In short, it's a mess, and rather difficult to understand. When faced with these kinds of situations in arcade hardware, it's best to try and "be the ball" - think like a piece of hardware, understand its capabilities, its inputs, its outputs, its clock speed, and try to come up with limitations on its behavior that can help explain what's going on. For example. It's been known for a while that the System 32 mixer chip has an alpha blending feature. In order to perform alpha blending, you need to take the RGB values of one pixel, apply a multiplier, and add them to the RGB values of a second pixel, after applying the opposite multiplier. It's also been known that you can turn on alpha blending for each layer, so that, say, two of the background layers are both alpha blended with the pixels underneath them. Now, if that's the case, then you should in theory be able to turn on alpha blending for all 8 layers if you wanted. Ah, but wait. For each layer, in order to do alpha blending, you would have to know that layer's RGB values. How do you get the RGB values? Well, you have to look them up in palette RAM. Hmmmm. That's a memory access, which requires a clock to the RAM chips to fetch the data. If I had to do 8 palette RAM lookups, I would need to use 8 clocks to perform 8 separate reads from palette RAM. But the input clock to the mixer is not fast enough to cram 8 memory accesses into it, especially given the maximum speed rating on the palette RAM memory chips. In fact, one memory access seems to be the most we can reasonably expect to get per pixel. So how can we even do alpha blending at all? Well, looking at the board, palette RAM is 32k long, separated into two 16k banks. That's interesting. At the time the boards were produced, it was certainly possible to use larger RAM chips, so why did they use two banks of smaller chips instead of one bank of larger chips? Well, as it turns out, the busses for each bank of chips go to different parts of the mixer. So the mixer can apparently access separate entries in each half of palette RAM independently. Okay, but how does this look from a software point of view? Tests have verified that I can read and write independent values across all 32k of palette RAM. Ah, but I hadn't enabled alpha blending! If I turn that bit on in the mixer, some interesting magic happens: I can read the full 32k of palette RAM normally, but all writes I make get automatically mirrored to the opposite 16k chunk. Which means that if I enable blending in the mixer, and then fill the low 16k of palette RAM, the upper 16k will automatically be filled with an exact copy. This means that the mixer can look up two pixel indexes and get their RGB values at the same time, by looking one up in the lower 16k and the other in the upper 16k. So we now have an explanation for how we can get two palette lookups per pixel. How do we limit it to 2, given that each layer could result in an alpha blend? Well, thinking about things in the absence of alpha blending, the mixer needs to figure out which pixel is "on top" out of all the layers. Then it will look up the RGB value of that pixel and output the result. It makes sense, then, that for alpha blending, it would figure out not only which layer's pixel is "on top", but also which layer's pixel is the 2nd from the top.
                                     Then, if alpha blending is enabled for the "on top" pixel, the mixer can alpha blend between the topmost and 2nd-to-topmost pixel. This isn't perfect, because it is assuming that the 2nd-to-topmost layer didn't also have alpha blending enabled, but in practice, this is exactly what the hardware does. As a final point, it's actually even more complicated than this. Each layer specifies with a bitmask exactly which other layers it can alpha blend against. So when the mixer figures out which layer's pixel is on top, and which layer's pixel is 2nd-from-top, it then has to see if alpha blending is enabled between those two layers specifically. If it's not, then the topmost pixel is displayed normally; otherwise, the alpha blend takes place.
- NOTES: There are still MANY issues with the system 32 driver, mostly video related. The system use a 5-layer tilemap hardware consisting of 4 independant rom-based layers with linescroll, lineselection, linezoom and window clipping capability and one simpler ram-based text plane. Mixed ram/rom sprite engine with palette indirection, per-color priority (thankfully not actually used). The sprite list includes jumping and clipping capabilities, and advanced hot-spot positioning. The mixer chip adds totally dynamic priorities, alpha-blending of the tilemaps, per-component color control, and some other funnies we have not been able to decypher.
- SOURCE: drivers\segas32.c
- GAMES: F1 Exhaust Note (1991), Sonic The Hedgehog (1992), Jurassic Park (1994)

                 CPU      Tiles      Sprites   Priority  Color     SCPU  Sound                Other
  System 32      V60      315-5386A  315-5387  315-5388  315-5242  z80   ym3834(x2) RF5c68(d) 315-5296(IO)




G4.24  Sega ST-V
- NOTES: The ultimate 2D system. Even more advanced tilemaps, with 6-dof roz support, alpha up to the wazoo and other niceties, known as the vdp2. Ths sprite engine, vdp1, allows for any 4-point streching of the sprites, actually giving polygonal 3D capabilities. Interestingly, the mixer capabilities took a hit, with no real per-sprite mixer priority, which could be considered annoying for a 2D system. It still allowed some beauties like Radiant Silvergun.
- SOURCE: machine/stvcd.c + scudsp.c and drivers\stv.c
- GAMES: Funky Head Boxers (1995), Die Hard Arcade (1996), Steep Slope Sliders (1998)





G4.3   Other 3D games

       TX-1                          Tatsumi (1983)       tx1.c
       Buggy Boy                     Tatsumi (1985)       tx1.c
       Top Landing                   Taito (1988)         taitoair.c
       Four Trax                     Namco (1989)         namcos2.c
       World Grand Prix              Taito (1989)         wgp.c
       Air Inferno                   Taito (1990)         taitoair.c
       Over Drive                    Konami (1990)        overdriv.c
       Double Axle                   Taito (1991)         taito_z.c
       Grand Prix Star               Jaleco (1991)        cischeat.c
       Racing Beat                   Taito (1991)         taito_z.c
       Road Riot 4WD                 Atari (1991)         atarig42.c
       Cool Pool                     Catalina (1992)      coolpool.c
       Ground Effects                Taito (1992)         groundfx.c
       Moto Frenzy                   Atari (1992)         atarigx2.c
       Outrunners                    Sega (1992)          multi32.c
       Stadium Cross                 Sega (1992)          multi32.c
       Suzuka 8 Hours                Namco (1992)         namcos2.c
       9-Ball Shootout               E-Scape (1993)       coolpool.c
       Racin' Force                  Konami (1994)        konamigx.c
       Road Riot's Reveng            Atari (1994)         atarigx2.c
       T-MEK                         Atari (1994)         atarigt.c
       Slipstream                    Capcom (1995)        system22.c
       Snow Board Championship       Gaelco (1996)        gaelco.c




G4.4   Textures games
- 28th October   2002: Aaron Giles sent in a TMS32031 CPU core and Williams V-Unit driver supporting Cruis'n USA and Cruis'n World complete with perfect sound emulation. P4 - 4 GHz or Athlon XP 4000+ recommended.
- GAMES: Midway V-Unit - Cruis'n USA (1994), War Gods (1995), Cruis'n World (1996), Off Road Challenge (1997)



G4.5   PSX GPU

- 28th June      2005: smf - It took about half an hour to get Tenkomori Shooting up and running as there were alot more protection checks than other System 12 games. There were a couple of problems with the graphics though. I spent some more time studying the protection checks, which allowed me to remove all the rom patches from the games that previously required them. Unfortunately this didn't help and it hasn't got Soul Calibur or Tekken Tag any closer to being emulated either. I started looking closer to home and I discovered it was using a little known feature of the PSX, that allows you to flip sprites. None of the unofficial GPU docs mention it at all and Pete Bernert has only supported x flipping in his GPU plugins, no game had used y flipping until now. After adding x & y flipping it looks much better. I had to verify which was which as they were always setting both or none. So after verifying the sprite flipping bits on a console I sent the information to Pete to add to his renderers. The only issue now was the intro didn't look quite right. This took a while to track down, eventually I realised that they were dma'ing 1792 bytes at a time from the mdec output. Each block is 512 bytes, which makes 3 and a half blocks. The code in MAME & most other emulators can't cope with this. With a fix for this issue the intro looks great too. It's not over yet. Although Pete had added the y sprite flip to the GPU plugins, the game wouldn't even boot in ZiNc. It took alot of tracing and comparing to MAME, but I eventually found it. I had to retrofit the MDEC fix onto ZiNc's MDEC decoder as well.
- 0.94u4             : smf fixed bugs in PSX texture window (PSX GPU - video\psx.c). This fixes pitch in Libero Grande and playfield in Aqua Rush.
- 0.78               : PSX core improvements [smf]. Fixed MVMVA disassembly, SWC bit in SR is ignored, fixed MVMVA with LM bit set, added SQR & CC opcodes, added preliminary looped DMA detection, improved root counter emulation, improved SIO emulation, preliminary PSXSPU emulation, preliminary screen flipping / blanking support, added GPU packet 41, 52 & 77, Supports uploading 1024 pixel wide textures and esetting GPU sets default texture window.
- NOTES: Preliminary software renderer
- SOURCE: video\psx.c + machine\psx.c
- GAMES: Sony ZN1/ZN2    - Battle Arena Toshinden 2 (1995), Gallop Racer (1996), Dead Or Alive (1998)
         Namco System 11 - Tekken (1994), Dunk Mania (1995), Soul Edge (1996)
         Namco System 12 - Tekken 3 (1996), Soul Calibur (1998)
         Konami GV       - Hyper Athlete (1996), Powerful Baseball '96 (1996)
- PCB: CXD8514Q, CXD8538Q, CXD8561Q, CXD8654Q (Sony GPU, QFP208)




G4.6   3dfx Voodoo Graphic

- 0.123u5            : Voodoo now takes a device_config for the screen [Zsolt Vasvari].
- 0.121              : Atari Ace fixed bug in Voodoo statistics accumulation. 
- 0.120u1            : Couriersud and Aaron Giles improved multiprocessor Voodoo performance by reducing contention during rendering. Extended the system to allow for more overlap between rendering and emulation.
- 0.120              : Aaron Giles made several more traditional optimizations to the voodoo emulations, gaining a few percent improvement.
- 0.119u4            : Aaron Giles updated Voodoo code to use the new work functions. It now queues small scanline chunks as independent items rather than using shared items. Updated code to also copy some parameters to allow for greater overlapping of emulation and rendering.
- 0.119u3            : Aaron Giles changed the 3dfx Voodoo emulation code to take advantage of the new threading mechanisms. It now creates a work queue with the WORK_QUEUE_FLAG_MULTI flag set, and uses shared work items to spread rasterization work across multiple processors. Note that this support should be considered experimental; under some circumstances it is known to deadlock. If you encounter problems, set OSDPROCESSORS to 1 to effectively produce the previous behavior. Added new work item flag WORK_ITEM_FLAG_SHARED. When specified on a work item that is queued to a work queue created with the WORK_QUEUE_FLAG_MULTI hint, it means that all threads will be dispatched to process the one work item, instead of the first thread removing it. These "shared" work items are only considered complete when all processing threads have returned [Aaron Giles].
- 0.119u1            : Aaron Giles fixed Voodoo video timing according to the manual, including blanking periods and vsync interrupts. This makes Carnevil and some other games run once again at their proper speed. Aaron Giles updated Voodoo drawing code to track changes to the front buffer and allow skipping unrendered frames for more even framerates.
- 0.114u2            : Ville Linde hooked up vblank interrupt to Voodoo in all Voodoo-based games
-  8th April     2007: Ville Linde - I fixed some multi-processor issues in the SHARC core, and some Voodoo-related issues in the NWK-TR/Hang Pilot graphics board emulation. As a result, Hang Pilot sprung to life in its whole 3D glory. There seems to be some texture problems still to be fixed though.
- 0.102u5            : Aaron Giles fixed overflow in Voodoo 1/W calculation that messed up some textures and added missing color combine mode used by Gauntlet Dark Legacy.
- 0.102u4            : More Voodoo updates [Aaron Giles]: Fixed bug that trashed fbzMode when the fogMode was changed, added preliminary Voodoo 2 support; Gauntlet Legends works again and changed float-to-int conversion to be done manually.
- 0.102u3            : More Voodoo updates [Aaron Giles]: Added support for CLUT/gamma ramps; enables fade in/out effects. Changed stall callback to notify both start and end of stalling. Decreased bilinear resolution to 4 bits for Voodoo 1. Fixed statistics and added some new ones. Now properly masking off unsupported bits for earlier chipsets. Fixed NOP command so it doesn't always reset statistics. Fixed bug that caused the refresh rate to never be updated. Fixed 16-bit writes to the frame buffer. Fixed crashing bug after resetting the chip. Added support for Voodoo 2's new fog, colorpath, and chromaRange modes. Added correct wrapping for ARGB, W and Z values. Fixed bug where depth was written to the Z buffer without bias. And Now aggregates shorter commands to reduce the number of context switches.
-  4th December  2005: Aaron Giles - So I thought I had everything figured out. I found a nice depth buffer bug that fixes numerous problems in the Voodoo games (and which happened to be there in the old implementation as well). I figured out the weird alpha blending problem. And the only thing that was left was understanding why Carnevil was no longer rendering its polygons correctly relative to the background movie. I looked everywhere for the problem, and it turned out to be much more subtle than I realized. It turns out that a number of the games use the DMA functionality of the Galileo GT64010A chipset to send data to the Voodoo. This actually makes a lot of sense. The Voodoo has a limited size FIFO where the data goes in, and when that is full, whoever is sending the data has to stall until the Voodoo has had a chance to finish whatever it was backed up doing. Far better to let the DMA system stall than letting the main CPU stall when it could be doing real work. In the old implementation, I made all commands to the Vooodoo complete instantly. This meant that any DMA transfer, no matter how long, finished instantaneously, even if it was rendering tons and tons of polygons or clearing the screen. In the new implementation, I changed the code to actually approximate the amount of time each polygon and screen clear takes. The problem with this is that DMAs no longer complete instantly, and this has revealed a subtle problem. Many of the games kick off a nice long DMA to the Voodoo and let it complete asynchronously while the main CPU is off busy doing other things. The problem is, there is code in most of the games that also directly accesses the Voodoo without checking to see if there is still a DMA in progress. When this happens, new commands were being inserted into the rendering queue at the wrong spot. The most obvious side effect was in Carnevil, where they would write a command in the middle of a DMA that turns off depth buffering, meaning that all subsequent triangles were rendered without doing any depth comparisons. The trick is figuring out what the behavior should be. I've tried hacking it so that if the CPU writes to the Voodoo while the DMA is in progress, then the CPU stalls until the DMA completes, and only then does the write go through. This works but introduces other glitches in the system. So now I have to come up with another theory.
- 0.102u2            : Added video\vooddefs.h. Removed vidhrdw driver vooddraw.h, voodlfb.h, voodrast.h, voodregs.h, voodrgen.h and voodrx86.h. Rewrote the Voodoo emulation code to be more accurate to the original [Aaron Giles]: Support for multiple simultaneous boards (hello Silent Scope). Pixel-pipelined framebuffer accesses now work. Alpha buffer operations now supported. Triple buffering now supported. Proper memory allocation and handling based on configuration. Proper FIFO handling, including low/high water marks and stalling. Approximate timing calculations based on quoted fill rate specs. Detail textures implemented. All math is done in fixed point. Proper edges calculated for polygons (stars appear in Gradius 4 now). Much easier to add specific rasterizers now. This is a work in progress; some stuff is not quite right yet. Voodoo 2 emulation is completely broken.
- 28th November  2005: Aaron Giles - I've never been quite happy with how the Voodoo emulation code ended up. It's a pretty big system to emulate, and in order to get things working quickly, I took several shortcuts. I ignored a few features (detail textures, trilinear filtering, alpha buffers), simplified the math (using floating point, even though the original works in fixed point), cheated on the PCI interface (did not fully emulate the FIFOs), and faked the timing (completely ignored it, that is). This was expedient toward getting the first games up and running, but now it's time to go back and do it right. So I'm rewriting everything from scratch. Fortunately, I'm mostly done. I still have to add fogging, fix a few precision issues with far-away textures, and correct a few other glitches before it's ready. But the code is much simpler and better organized, and operates more closely to the original. Which brings up another point: I recently acquired a Voodoo 2 card for my "oldie" PC (thanks, Tim!), which I'm using to verify some of the behaviors. Although I won't claim perfect pixel accuracy, this new version should be much closer. The new Voodoo will be in in time for 0.102u2, but Voodoo 2 emulation is completely busted at the moment and will have to be brought up to the new system afterwards. One step at a time...
- 0.102u1            : Aaron Giles fixed some minor problems with the LOD calculations in the Voodoo driver.
- 0.102              : Aaron Giles implemented pixel-accurate dithering in the Voodoo emulation.
- 0.101u5            : Added video\voodrx86.h and video\voodrgen.h. Aaron Giles added very experimental rasterizer generator for the Voodoo emulator, which generates X86 assembly blitters optimized for each case. Unfortunately, it doesn't help performance much and they are still too buggy so they are disabled for now. Enable them in the makefile. Also made some of the hack optimizations runtime enableable in the Voodoo emulator, and added a frameskipper. Use Ctrl+1-6 to control frameskipping, Ctrl+F/H/Q to run at full/half/quarter resolution.
- 0.88               : Aaron Giles fixed Voodoo code broken by cleanup in 0.87u3.
- 0.84u2             : Added video\vooddraw.h, \voodlfb.h, \voodrast.h and \voodregs.h. Removed video\voodblit.c. Aaron Giles refactored the Voodoo code, fixing several errors in the LOD calculations and the Voodoo 2 command FIFO.
- 0.82u2             : Aaron Giles cleaned up Voodoo logging. All stats now accessible via the backslash key, got rid of ugly red/blue swap hack,  fixed missing truncation on vertex coordinates (fixes vaportrx graphics) and added support for alternate LFB write modes.
- 0.81u5             : Aaron Giles added full memory FIFO emulation, removed hack for fastfill operations after a buffer swap, added compile time option to reduce the resolution, added client callbacks for VBLANK synchronization, cleaned up handling of statistics and debugging info, added optional R/B component swapping (for vaportrx), fixed crashing problems when executing Midway POSTs and now dynamically computing refresh rate based on hSync/vSync registers.
- 0.77u3             : Aaron Giles added code to clip the Voodoo vertexes to 1/16th of a pixel increments, fixed writes to the palette RAM on the Voodoo, fixed small errors in the Voodoo rendering when bilinear filtering and fixed handling of local alpha blending on the Voodoo.
-  5th December  2003: Aaron Giles - Turns out that California Speed revealed a few bugs in my 3dfx emulation. Bilinear filtering was adding too much error to allow for chroma keying, which is used a whole bunch. There was also a misunderstanding in how the "a_other" term was computed, which prevented all FMV sequences from displaying anything. And finally, this is the first game to use palettized 8-bit textures, and there was a bug in how the palettes were uploaded. The upshot is the game still crashes, but it looks much prettier along the way! I also spent a little bit of time looking at the Vegas sound system, which has some quirks of its own....
- 0.77               : Added vidhrdw\voodoo.c and vidhrdw\voodblit.c. 3dfx Voodoo Graphics SST-1 emulator [Aaron Giles].
- SOURCE: emu\video\voodoo.c, drivers\seattle.c
- GAMES: Atari - Mace: The Dark Age (1996), San Francisco Rush (1996), Vapor TRX (1998); Midway - NFL Blitz (1997), CarnEvil (1998)



G4.61  Voodoo 2

- 21st December  2005: Aaron Giles - Been taking another look at the Vegas drivers again now that the Voodoo 2 emulation is working. Gauntlet Legends was working again in 0.102u4, which is a good sign. A couple more fixes and Gauntlet Dark Legacy was working again - at least as well as it had been before, which is to say fine until you actually got in-game, at which point all the environment graphics were drawn all-black. Looking into this problem a bit more revealed that the Dark Legacy engine had added light maps to the rendering, using a multiplication between two textures to produce the final result. The Voodoo rasterizers support this just fine, but what was new is that they were now using a new mode in the Voodoo 2 which specifically selects the texture color rather than a color computed through other means. Since this mode didn't exist in the original Voodoo, the code was just using '0' for this case and producing a black background. Adding support for this made the graphics appear. Yay!
- 0.102u4            : Aaron Giles added preliminary Voodoo 2 support; Gauntlet Legends works again.
- 0.84u2             : Aaron Giles refactored the Voodoo code, fixing several errors in the LOD calculations and the Voodoo 2 command FIFO.
- 0.78               : Aaron Giles added initial Voodoo 2 support, removed hack to toss what I thought were bogus triangles, improved W buffer handling and accuracy of depth buffer handling.
- 19th December  2003: Wow, that was a tricky bug. Turns out nobody was ever saving the FPU condition codes in the R5000 core, so if you took an interrupt between a compare and a branch on the result of that compare, you would hose the compare. This led to all kinds of nasty. The graphics are still very glitchy (I took a bunch of screen shots and this was the best one), but we're seeing most of the geometry now. However, the glitches in most of the Seattle games are now gone as a result. I also fixed the W-buffering on the 3dfx emulation to be closer to what I think is correct. This fixes some minor glitches in a few of the Seattle games.
- 12th December  2003: Aaron Giles - Several of the Atari and Midway Vegas games are now booting. They look pretty. The Voodoo 2 emulation is mostly working for FMV and static screens, but it's falling over when actual geometry is being rendered. In addition, the games are kind of flaky at the moment, crashing MAME sometimes, and none of them work yet with the dynarec R5000 core. And finally, though Gauntlet: Dark Legacy and War: Final Assault work with the new ADSP-2104-based DCS sound core, the others fall over at the moment unless I help them along. So all in all, some exciting developments, but there's still quite a ways to go to get things stabilized.
-  9th December  2003: Aaron Giles - Well, after a frustrating night trying to get this to work, I'm finally getting somewhere with my Voodoo 2 emulation....




G4.62  Voodoo Banshee
- 0.103u3            : Many Voodoo updates to add Voodoo Banshee and Voodoo 3 support [Aaron Giles].
- 16th January   2006: Aaron Giles - Took a decent amount of hacking, but I'm finally into the attract mode in NBA Showtime. The game crashes out pretty quickly and there are other problems, but at least now I can verify that the CHD dump is good (and it is).
- 27th December  2005: Aaron Giles - There's a part of me that wants to try and start on the Voodoo Banshee emulation, but I also really want to get the Voodoo 2 games working first. Plus, the Banshee requires a whole bunch more glue to support the 2D side of things, so that means faking VGA grossness. I only hope the games don't actually use the 2D stuff for anything except setting the display mode! Fortunately, the 3D section is pretty compatible with the Voodoo 2.



G4.63  Voodoo 3
- 0.103u3: Many Voodoo updates to add Voodoo Banshee and Voodoo 3 support [Aaron Giles].
- GAMES: San Francisco Rush 2049


G4.64  Voodoo chips + cards

       Chips:
       3Dfx 500-0003-03 FBI    PIXELFX    Pixel processor                QFP240    (Gradius4, Sscope)
       3Dfx 500-0004-02 TMU    TEXELFX    Texture processor              QFP208    (Gradius4, Sscope)
       3Dfx 500-0009-01                   Pixel processor                QFP256    (Gauntleg, Sscope2, Konami-HornetSystem)
       3Dfx 500-0010-01                   Texture processor              QFP208    (Gauntleg, Sscope2)

       Voodoo cards:
       Obsidian2 PCI 650-0818-03D         Quantum 3D Voodoo2 card                  (Gauntdl, Gauntleg)

       Extra:
       TI TVP3409-170CFN                  RAM DAC?                                 (Wg3dh, Blitz99)
       GT64010                 GALILEO    PCI Bridge/System Controller     ?       (Blitz99)
       PC87415                            Harddisk IDE controller  




G4.7   Gaelco 3D
- SOURCE: video\gaelco3d.c
- GAMES: Gaelco - Speed Up (1996), Surf Planet (1997), Radikal Bikers (1998)
- PCB: 3D-3G, QFP206 square smd (Radikalb, Speedup, Surfplnt)


G4.8   Real3D 1000
- 19th January   2005: Ville Linde - Fixed a bug in the Real3D DMA emulation. This fixes the 3D graphics in Virtual On 2 and Harley Davidson & L.A. Riders. Virtual On 2 still doesn't have working controls and Harley Davidson has lots of glitches and crashes before getting ingame.
- 0.89u3: Ville Linde major bugfixes to the PPC603 emulation, especially the FPU. Improved MPC105 emulation and added preliminary 53c810 SCSI emulation (Lost World now tries to download everything necessary to the Real3D stuff).


G4.9   Konami

G4.91  K001005
- 0.113u3            : Ville Linde improved K001005 polygon rendering.
- 0.110u3            : Ville Linde added texture-mapping and z-buffer to K001005 emulation.
- 0.104u1            : GTI Club updates [Ville Linde]: Improved K001604 tilemap emulation, very preliminary K001005 & K001006 3D graphics emulation.
- 0.97u1             : Ville Linde made more progress on the Konami PowerPC drivers. Initial reverse-engineering work on the KS001005 custom 3D chipset in GTI Club.
- NOTES: Konami K001005 Custom 3D Pixel Renderer chip (KS10071)
- SOURCE: drivers\gticlub.c + zr107.c

G4.92  K001006
- 0.104u1: GTI Club updates [Ville Linde]: Improved K001604 tilemap emulation, very preliminary K001005 & K001006 3D graphics emulation.
- SOURCE: drivers\gticlub.c


G4.A   3DO
- NOTES:
- SOURCE: drivers\konamim2.c
- GAMES: Beavis and Butt-head (Atari 1995 prototype), Die Alien Scum!! (Warner 1996 prototype), Tobe! Polystars (Konami 1997), Heat of Eleven '98 (Konami 1998)
- PCB: 3DO chip 9701 B861131 VY21118- CDE2 3DO 02473-001-0F (QFP208) (Polystar), B861132-VY21118-CDE2-3DO-02473-001-0F (Heatof11)



G4.B   Direct3D
 - 23rd October  2003: Leon van Rooij sent in an update to the Windows Direct3D code, fixing a bug that caused a black screen in rotated ST-V games.
 - 11th June     2003: Leon van Rooij fixed various bugs and crashes in the Direct3D video output.
 - 30th May      2003: Leon van Rooij fixed the Direct3D problem that caused timing problems in various drivers due to worse floating point math precision.
 - 19th May      2003: Leon van Rooij sent in another update to the Direct3D video output, adding a few new options.
 - 18th May      2003: Leon van Rooij fixed some small problems in the Direct3D video output.
 - 16th May      2003: Leon van Rooij sent in a major update to the Direct3D output, adding RGB effects, scanlines, hardware accelerated -effect sharp and various other useful things.
 -  1st May      2003: Leon van Rooij submitted basic Direct3D support, giving the ability to turn off bi-linear filtering when using hardware stretch.




G5.    Video controller

G5.1   Actel

       A1010     A1010A-1, A1010b A-22096                     S.S. Mission (Comad 1992), Shadow Force (Technos 1993), Area51
       A1020     A1020A, A1020B             (PLCC84)          Gumbo (1994), Magic Bubble (Yun Sung 199x), Burglar X (Unico 1997)      NOTES: The ACTEL A1020A PL84C (PLCC84) is the same graphics controller chip as the Texas Instruments TPC 1020.
       A1425     Actel A1425A-2 PQ100C 9536 (QFP100)          NBAJamExtreme
       A4MX09                                                 Ssriders
       A40MX04   ACTEL A40MX04-F, A40MX04F  (PLCC84)          Multi Champ (ESD 1998), The Legend of Silkroad (Unico 1999), Head Panic (ESD 2000)
       A54SX16A  Actel A54SX16A             (QFP208)          Fire Hawk (ESD 2001)

G5.2   Altera

       EP1800                                                 Twinfalc (Philko 19xx)
       EP1810    EP1810lc-45, EP1810LC20T, EP1810LC-35T       West Story (1990), Street Fighter II (1992), Primal Rage (Atari 1994), Guardians of the Hood (Atari 1992)



G5.3   Brooktree

       Bt101      BT101KC30                                F15se                          NOTES: 8-bit digital to analog converter.
       Bt121      BT121KPJ50 (50MHz), Bt121KPJ80 (80MHz)   Timekill, Eggventrm Lethalj    NOTES: The Brooktree Bt121KPJ80 features: 80 MHz pipelined operation (RAMDAC), Triple 8-bit D/A converters, Optional internal voltage reference, TTL-compatible inputs, +5 V CMOS monolithic construction, PLCC44 package and Typical power: 600 mW
       Bt476      Bt476KP35                                Wfortune                       NOTES: 6-bit DAC
       Bt478      BT478KPJ50                               Wheelfir
       Bt481      Bt481AKPJ110, QFP44                      Policetr, Sshooter             NOTES: 256-Word Color Palette 15, 16 & 24-bit Color Power-Down RAMDAC, QFP44



G5.4   Cosmac

       CDP1869/70/76 Video Interface System

       - 0.115u2            : Aaron Giles fixed the CDP1869 to fill the border area with the background color. Added cropping to the Cidelsa games.
       - 0.113u4            : Curt Coder changed CDP1869 to use proper write handlers for MESS.
       - 0.113u3            : Curt Coder externalized CDP1869 color bit handling to a callback function for MESS.
       - 0.113u2            : Curt Coder fixed CDP1869 double width mode (for MESS).
       - 0.112u1            : Improvements to the Cidelsa driver [Curt Coder]: Set CDP1869 display size and visible area according to data sheet. Added CDP1869 CFC emulation (probably never used by anything but just for completeness' sake). Cleaned up driver.
       - 0.111u4            : Curt Coder added CDP1869 video emulation to the Cidelsa driver. The games still don't work due to timing and interrupt issues.
       - 0.109u2            : Added support for CDP1869 (sound + video).
       - NOTES: The Cosmac CDP1869/70/76 Video Interface System (VIS).
       - WEB: http://homepage.mac.com/ruske/cosmacelf/cdp1869.pdf
       - SOURCE: emu\video\cdp1869.c



G5.5   Hitachi

       HD6845     The HD6845SP is a videocard controller        68A45 (Qix, Zookeep), UM6845 (Xyonix), HD6845SP (PBallon), HD68455P (Fantasy), HD6845SP (Hitpoker), MC6845P (Magiccrd, Poker), HD468458SP (R2dtank), HD6445 (Cyclwarr)
                  UM6845RA (CRT controller, supports alphanumeric and graphics modes, addresses up to 16 KB of video memory, 2 MHz) (Steaser)

       HD46505    HD46505SP (40 pin) drivers\tugboat.c      Satansat, Hanamai, Hnayayoi, Spiders, R2dtank, HD46505R (LaserBase), HD465055P (Fantasy)
          6505s = HD46505S CRT Controller ???                   BlitzVideoPoker
       HD63484    Hitachi HD63484PS8 Video controller, SDIP64   Shangha2, SOURCE: drivers\shanghai.c - HD63484_start


       6845
       - 0.124              : Zsolt Vasvari added option in MC6845 to programatically set the clock pin. This is needed by at least one MESS driver. Added mc6845_set_hpixels_per_column() for the Hercules gfx adapter.
       - 0.123u5            : Zsolt Vasvari added some new 6845 varieties: MC6845-1, H46505, HD6845 and SY6545-1.
       - 0.123u5            : Zsolt Vasvari changed the MC6845 to take and pass device_config's only. The following shook out from this that are applicable to other devices as well: Running_machine is no longer taken, passed or stored MC6845_t is now private. Since passing device_config's is not device type safe, I added a get_safe_token() to mc6845.c to check the device passed in for the valid type. Zsolt Vasvari changed MC6845 to take a screen tag instead of a screen number. Zsolt Vasvari fixed flickering in Electric Yo-Yo. Changed qix driver to use the MC6845's VSYNC notification for interrupts.
       - 0.123u4            : MC6845 updates [Zsolt Vasvari]: Now signalling both 0->1 and 1->0 transitions of synching pins. Added mc6845_assert_light_pen_input; uses a timer for latching the light pen address. Added reset device function. Implemented VSYNC height computation difference between the Motorola and the Rockwell devices. Since the Commodore 40xx computers program an HSYNC width that extends past the end of the scanline, I am clamping it in lack of anything better to do. Added support for the Commodore 6545-1 device type. Added support for the status register. Better variable names. More asserts. Aaron Giles converted MC6845 read/write handlers to READ/WRITE8_DEVICE_HANDLERs. Updated all MC6845-using drivers to use the new macros and call the updated functions. Removed the many little helper functions that used to do this work.
       - 0.123u3            : Zsolt Vasvari added support for cursors in the MC6845 emulation. All 4 blinking modes are supported.
       - 0.123u2            : Zsolt Vasvari changed all drivers using the MC6845 chip to use the new device interface. Removed mc6845_config.
       - 0.123u1            : MC6845 updates [Zsolt Vasvari]: Changed the 6845 to be handle based -- adjusted all drivers. Renamed crtc6845 to mc6845. Allow reading registers 12 and 13. Reading write-only registers return 0. Updated comments in header.
       - 0.115u2            : Zsolt Vasvari changed the CRTC6845 emulator to optionally control the screen configuration and video rendering. Updated the Qix and Spiders driver to use the new functionality. Added notifications for when the display enable pin changes in order to drive blanking signals.
       - 0.115              : Aaron Giles hooked up 6845 CRTC to the qix-based games. All games now generate display resolutions and frame rates on the fly. Cleaned up memory maps and a few other bits along the way. Added save state support.
       - 0.107u1            : Updates to the MagicFly driver [Robert Fresca]: Figured out the MC6845 (mapped at $0800-$0801). Fixed the screen size based on MC6845 registers. Fixed the visible area based on MC6845 registers. Fixed gfx rom region. Solved the NMI/vblank issue. Now attract works. Changed CPU clock to 625khz. Added new findings to the technical notes. Marked magicfly PAL as NO_DUMP (read protected).
       - 0.33b5             : Added Motorola 6845 CRT Controller interface driver (video\crtc6845.c)
       SOURCE: emu\video\crtc6845.c


G5.6   Texas Instruments

       TMS9128    TMS-9128NL video processor          CliffHanger
       TMS9918                       NOTES: The TMS9918(A), TMS9928(A) and TMS9929(A) are used by the Coleco, MSX, SG-1000 console and TI99/4(A). Color palette, multi color- and screen modes, sprite rendering and collision. SOURCE: video\tms9928a - Document at http://www.msxnet.org/tech/tms9918a.txt
       TMS9927    TMS9927 VTAC       NOTES: The video controller registers effect screen size (currently hard-coded on a per-game basis in MAME). SOURCE: video\tief.c  GAMES: Pacific Novelty - Shark Attack (1980), Thief (1981), NATO Defense(1982)
       TMS9928    TMS9928A VDP       
       TMS9929                       NOTES: Model TMS9929(a) is the PAL variant of TMS9918 video chip. It runs at 50Hz instead of 60Hz  SOURCE: video\tms9928a
       TMS9937    TMS9937NL          Trivquiz, TriviaQuizI+III
       TMS34061   TMS34061FNL        NOTES: Video controller (User's Guide available on www.spies.com/arcade)   Capbowl, Dynobop, Hstennis, Rimrockn, Stratab
       TMS34070                      NOTES: Video Output Graphics Controller (Video Palette, CRT Driver)        Amerdart

       TPC1020    TI TPC1020AFN-084C is the same as the ACTEL A1020A PL84C (PLCC84)  (Cupsoc, TMEK, Powerins, Wrally)
       - PCB: TPC 1020 (Fantasia), TPC 1020AFN-084c (Stlforce), TPC1020AFN-084C1 (Nbajam), TPC1020BFN-068C2 (Primrage, Tmek), TPC1020BFN-084 (Maddonna, Wheelfir), TPC1024AFN-084C (Paradise, Perestro), TI 32005BWBL - TPC1020AFN-084C (Mstworld), TI9206BL-1183715-TPC1020AFN-084C (THoop), 9206BL-6161569-TPC1020AFN-084C (Sf2ce), Texas 2260BXEBL-TPC1020AFN-084C (Drtomy)



       TMS9928
       - 0.117              : Zsolt Vasvari simplified code in TMS9928 video system.
       - 0.111u5            : Aaron Giles removed gross TMS9928a configuration in place of more standard techniques. Updates the Cliffhanger and sg1000a drivers accordingly.
       - 0.111u4            : R. Belmont fixed TMS9928 so it recalculates the pattern mask when its dependancies change so we don't end up in weird half-modes.
       - 0.77u1             : Fixes and updates from MESS to tms9928a.c [Nathan Woods].
       - 0.68               : Added vidhrdw\tms9928a.c. 
       GAMES: driver\sg1000a.c + cliffhgr.c
       SOURCE: emu\video\tms9928a.c


       TMS34061
       - 0.123u5            : Zsolt Vasvari converted atarigen and TMS34061 to be handle based.
       - 0.95u2             : Aaron Giles cleaned up TMS34061 implementation to remove dirty pixel tracking and fixed scanline calculations in TMS34061 code and updated the Capcom Bowling driver to use it.
       - 0.33b5             : Added TMS34061 video controller.
       SOURCE: emu\video\tms34061.c


G5.8   Other

       ADV476KN50   PCB: Analog Devices ADV476KN50E CMOS Monolithic 256x18 Color Palette RAM-DAC, DIP28 (Ghosthunt, Stonebal, Rapidfire, Tickee)
       ADV476KN80   PCB: ADV476KN80E, DIP28 (Stonebal)
       ADV7120KP30  PCB: ADV7120KP30, PLCC44 (Harley)
       AT76C176     PCB: Atmel AT76C176 1-Channel 6-Bit AD/DA Convertor with Clamp Circuit, DIP28 (Sliver)
       CM602, CM607P PCB: Magiccrd, Fortecar
       CRT5037      PCB: Sharkatt, Statriv2, Trivquiz
       CRTC99       PCB: ESD CRTC99 Graphics Controller, QFP240 (Mchampdx, Tangtang), ESD_CRTC99 (Hedpanic)
       CXA1179      PCB: Sony CXA1779P TV/Video Circuit RGB Pre-Driver, DIP28 (NamcoSystem12)
       DP8350       PCB: National DP8350N CRT Controller
       EL2386       PCB: Elantec Semiconductor 250MHz Triple Current Feedback Op Amp with Disable, SOIC16 (Ppcar)
       GD5401       PCB: Cirrus Logic CL GD5401-42QC-B-31063-198AC  standard VGA chip
       GM6845       PCB: Goldstar GM68B45S is the same as Hitachi HD6845 CTR Controller (Bmcbowl)
       HM86171      PCB: Hualon Microelectronics HMC HM86171 VGA 256 colour RAMDAC, DIP28 (Dunhuang, Lastfght)
       MP1210       Micro Power Systems MP1210HN, MP1210RD/883  PCB: 12-Bit Digital-to-Analog Converter, Double-Buffered (9ballsht)
       ICS5342      PCB: ICS GenDAC ICS5342-3, PLCC68, surface mounted (A51site4, Gauntleg, Gauntdl)
       IMSG176      PCB: Inmos IMSG176P 6-bit DAC (Gtg, Gtg2, CoolPool, Rimrockn, Stratab)   SOURCE: drivers\coolpool.c
       IR3P32       PCB: Sharp IR3P32A Special Function TV Interface Circuit, Conversion of color diff sig. & lumin. to RGB, NDIP30 (NintendoSuperSystem)
       KDA0476BCN   PCB: Bmcbowl  RAMDAC
       MB89322B     NOTES: CMOS Programmable CRT Controller (LockOn)
       MC6845       NOTES: CRT Controller    PCB: MC68B45P (Intgames), Screen Controller chip UMC UM6845B (Twincobr, Xyonix)
       MS176        PCB: Mosel MS176, 6-bit DAC (Dynobop, Neckneck, Slikshot)
       S951060      SOURCE: Video IC in Othello Derby is S951060-VGP.
       SY6545       Synertek SY6545, 6545-1   CRT Controller (Pottnpkrr)


       SY6545
       - 0.123u3     : Nathan Woods added a stub implementation of the Rockwell 6545.
       NOTES: Synertek SY6545, 6545-1   CRT Controller (Pottnpkrr)

       V9938
       - 0.122u8     : Aaron Giles replaced use of cycles_currently_ran() in v9938 code with mame_rand(), since that is effectively the same thing.
       - 0.111u5     : Nathan Woods updated the Yamaha V9938 MSX2 video driver to use the new BITMAP_ADDR* macros instead of using the line[] array.
       - NOTES: Yamaha V9938C, MSX2 Video Processor, Video Output Graphics Controller, Res. 512 x 212 (Mega Touch 3)
       - SOURCE: emu\video\v9938.c + emu\video\v9938mod.c + drivers\sangho.c + meritm.c



G5.9   Palette resistors

- 0.120u4            : Altered TTL low high levels in res_net.c. This will broaden the color range a bit. Since the results are normalized, there is only a limited effect visible [Couriersud].
- 0.116u3            : Changed video\res_net.c to \resnet.c. Couriersud created a new resistor network interface for computing palettes from color PROMs and component values on the PCB. Fixed several issues with the previous implementation.
- 0.91u2             : Added video\res_net.c.
- NOTES: Compute weights for resistors networks. Function can evaluate from one to three networks at a time. The output weights can either be scaled with automatically calculated scaler or scaled with a 'scaler' provided on entry.
- GAMES: mazerbla.c, shougi.c, sbowling.c and wallc.c
- SOURCE: video\resnet.c





G6.    Video D/A converter


G6.1   CXD1178
- PCB: SONY CXD1178Q is a 8-bit RGB 3-channel D/A converter, QFP48 (Alpinerd, MrDriller2, Propcycl)

G6.2   MC44200
- NOTES: The Motorola MC44200FT is a 3 Channel 8-bit video D/A converter
- PCB: MC44220 (Sscope), MC44200FT, QFP44 (NamcoSystem12, Primrag2, Sscope2), XC44200, QFP44 (GTIClub, NamcoSystem11)




G6.3   NPC

G6.31  SM5840
- PCB: (Scud)

G6.32  SM5877
- PCB: NPC SM5877AM - 3rd Order 2-Channel D/A Converter - SOIC24 (Sscope2, Graduis4, GTIClub)




G7.    RGB Pre-Driver

G7.1   RES NET
- 0.84u5             : Jarek Burczynski added new function: compute_resistor_net_outputs() in res_net.h. This function calculates outputs (not weights) of color circuits where the hardware consists of open collector PROMs.
- 0.61               : Added vidhrdw\res_net.h.
NOTES: Compute weights for resistors networks. Function can evaluate from one to three networks at a time. The output weights can either be scaled with automatically calculated scaler or scaled with a 'scaler' provided on entry.
GAMES: Strike Bowling (Taito 1982)
SOURCE: video\res_net.h

G7.2   Sony

G7.21  CXA1145
- PCB: Sony CXA1145P (Topshoot)

G7.22  CXA1634
- PCB: Sony CXA1634P (Topshoot)

G7.23  CXA1779
- PCB: Sony CXA1779P is a TV/Video circuit RGB Pre-Driver, DIP28 (Gp500, Namco System12 - Aquarush, Soulclbr)

G7.24  CXA2067
- PCB: Sony CXA2067AS is a TV/Video circuit RGB Pre-Driver, SDIP30 (Mrdrilr2)


G7.3   000180
- PCB: The 000180 is used for driving the RGB output (Cryptklr, Konami-GV)

G7.3   000180


G8.    Video Display

G8.1   OKI MSC1937
- 0.109              : El Condor made MSC1937 operation more accurately match datasheet and wiring diagram. Added indexed getters to the output system to match the newly introduced setters.
- 0.108u2            : El Condor cleaned up the vacfdisp module to display 14 and 16 segment displays. Added a separate character set for the OKI MSC1937. Changes Scorpion 2 to the new system. Tidied up the 6840 emulator a bit.
- NOTES: VFD (Vacuum Fluorescent Display) controllers of the BFM BD1 vfd display (OKI MSC1937) have a built in character table, which converts the displayable characters into on/off signals for the various segments. However, each controller has its own way of assigning the segments, making standardisation a problem. Currently, the model used by the OKIMSC1937 is considered as a standard with the BD1 model converted to it at drawing time.
- NOTES: The OKI MSC1937 is a clone of Rockwell 10937/10957.
- SOURCE: emu\machine\roc10937.c


 


ARCADE SYSTEMS


  1.    Amiga
  1.1   Amiga 500 board
  1.2   Arcadia Multi Select System
  1.3   Sente Super System

  2.    Atari
  2.1   Atari System 1
  2.2   Atari System 2
  2.3   Atari G1
  2.4   Atari G42
  2.5   Atari GX2
  2.6   Atari GT
  2.7   Atari CoJag
  2.8   Atari/Midway Seattle
  2.9   Atari/Midway Vegas
  2.A   Atari MediaGX

  3.    Bally/Sente SAC-1 System

  4.    Capcom
  4.1   Capcom System 1
  4.2   Capcom System 2
  4.3   Capcom System 3

  5.    Century Electronics
  5.1   CVS

  6.    Data East
  6.1   DECO Cassette System
  6.2   Data East PC-Engine
  6.3   Data East 32
  6.4   Data East MLC

  7.    Exidy
  7.1   Max-A-Flex

  8.    IGS
  8.1   PGM

  9.    Irem
  9.1   M62
  9.2   M72
  9.3   M92
  9.4   M107

 10.    Jaleco
 10.1   Mega System 1
 10.2   Mega System 32

 11.    Kaneko
 11.1   Super Nova System

 12.    Konami
 12.1   GX-Boards
 12.2   GX611
 12.3   GX777
 12.4   GX797
 12.5   GX973
 12.6   System GX
 12.7   System GV

 13.    Metro

 14.    Midway
 14.1   MCR-1 System
 14.2   MCR-2 System
 14.3   MCR-3 System
 14.4   MCR-68k System
 14.5   Midway T-Unit System
 14.6   Midway V-Unit System
 14.7   Midway Wolf-Unit System
 14.8   Williams/Midway Y/Z-unit system

 15.    Namco
 15.1   Namco System 86
 15.2   Namco System 1
 15.3   Namco System 2
 15.4   Namco System NA-1 / NA-2
 15.5   Namco System NB-1
 15.6   Namco System ND-1
 15.7   Namco System 11
 15.8   Namco System 12
 15.9   Namco System 21
 15.10  Namco System 22
 15.11  Namco System 23

 16.    Nintendo
 16.1   Playchoice 10
 16.2   Super System

 17.    Sega
 17.1   G-80 Raster
 17.2   G-80 Vector
 17.3   System 1/2
 17.4   SG-1000
 17.5   System 16A
 17.6   System 16B
 17.7   System 18
 17.8   System 24
 17.9   System 32
 17.10  System C
 17.11  System C2
 17.12  MegaPlay
 17.13  Mega Tech
 17.14  Multi-32
 17.15  Model 1
 17.16  Model 2
 17.17  Model 3
 17.18  Titan-V

 18.    Seibu
 18.1   SPI

 19.    Seta
 19.1   SSV

 20.    SNK
 20.1   SNK
 20.2   SNK68

 21.    Sony
 21.1   ZN1/ZN2

 22.    Taito
 22.1   Taito Air System
 22.2   Taito B System
 22.3   Taito F2 System
 22.4   Taito F3 System
 22.5   Taito H System
 22.6   Taito L System
 22.7   Taito SJ System
 22.8   Taito X System
 22.9   Taito Z System
 22.A   Taito GNET System

 23.    Tecmo
 23.1   Tecmo 68k system
 23.2   Tecmo System

 24.    Board Serial Numbers / Labels
..................................................................................................................................................................................................................................




H1.    Amiga

H1.1   Amiga 500 board
- CPU   : 68000 (7159090 Hz)
  SOUND : Custom (3579545 Hz), 2x Channels
  VIDEO : 671x216 (59.997002 Hz, palettesize 4096)
- SOURCE: drivers\upscope.c
- GAMES : Up Scope (Grand Products 1986)


H1.2   Arcadia Multi Select System
- CPU   : 68000 (7159090 Hz)
  SOUND : Custom (3579545 Hz), 2x Channels
  VIDEO : 671x216 (59.997002 Hz, palettesize 4096)
- NOTES : In the late 80s, Arcadia collaborated with Mastertronic to create their own ten-interchangeable-game arcade platform called the Arcadia Multi Select system, using the same hardware as the beloved Commodore Amiga computer. In fact, the Multi Select's main PCB is an A500 motherboard, to which the ROM cage is attached through the external expansion port. Reportedly the system was also (or was originally) supposed to have been released in two five-game Super Select versions--"Arcade Action" and "Sports Simulation"- but no specimens of these have ever been seen. Piggyback 1.5mb rom board, a 8255 parallel peripheral interface, DALLAS DS1220Y NVRAM and PAL16L8.
- SOURCE: drivers\upscope.c
- GAMES : Magic Johnson's Fast Break (Arcadia Systems 1988)


H1.3   Sente Super System
- CPU   : 68000 (7159090 Hz)
  SOUND : Custom (3579545 Hz), ES5503 (7159090 Hz), 2x Channels
  VIDEO : 671x216 (59.997002 Hz, palettesize 4096)
- SOURCE: drivers\mquake.c
- GAMES : Moonquake (Sente 1987)



H2.    Atari

H2.1   Atari System 1
- CPU   : 68010 (7159090 Hz), M6502 (1789772 Hz)
  SOUND : YM2151 (3579545 Hz), POKEY (1789772 Hz), TMS5220 (650826 Hz), 2x Channels
  VIDEO : 336x240 (60 Hz, palettesize 1024)
- SOURCE: drivers\atarisy1.c
- GAMES : Marble Madness (1984), Peter Pack-Rat (1984), Indiana Jones (1985), Road Runner (1985), Road Blasters (1987)


H2.2   Atari System 2
- CPU   : T11 (10 MHz), M6502 (1789772 Hz)
  SOUND : YM2151 (3579545 Hz), 2x POKEY (1789772 Hz), TMS5220 (625000 Hz), 2x Channels
  VIDEO : 512x384 (60 Hz, palettesize 256)
- SOURCE: drivers\atarisy2.c
- GAMES : Paperboy (1984), 720 Degrees (1986), Super Sprint (1986), APB (1987)


H2.3   Atari G1
- CPU   : 68000 (14318180 Hz), M6502 (1789500 Hz)
  SOUND : YM2151 (3579000 Hz), OKI6295 (9037 Hz), 1 Channel
  VIDEO : 336x240 (60 Hz, palette 1280)
- SOURCE: drivers\atarig1.c
- GAMES : Hydra (1990), Pit Fighter (1990)


H2.4   Atari G42
- CPU   : 68000 (14318180 Hz), M6502 (1789500 Hz)
  SOUND : YM2151 (3579000 Hz), OKI6295 (9037 Hz), 1 Channel
  VIDEO : 336x240 (60 Hz, palette 2048)
- SOURCE: drivers\atarig42.c
- GAMES : Road Riot 4WD (1991), Guardians of the 'Hood (1992)


H2.5   Atari GX2
- CPU   : 68EC020 (14318180 Hz), M6502 (1789500 Hz)
  SOUND : YM2151 (3579000 Hz), 2x OKI6295 (9037 Hz), 2x Channels
  VIDEO : 336x240 (60 Hz, palette 2048)
- SOURCE: drivers\atarigx2.c
- GAMES : Moto Frenzy (1992), Space Lords (1992), Road Riot's Revenge (1994)


H2.6   Atari GT
- CPU   : 68EC020 (25 MHz), TMS32031 (33868800 Hz)
  SOUND : 4x DMA-driven DAC, 2x Channels
  VIDEO : 336x240 (60 Hz, palette 32768)
- SOURCE: drivers\atarigt.c
- GAMES : Primal Rage (1994), T-MEK (1994)


H2.7   Atari CoJag
- CPU   : 68EC020 (25 MHz), Jaguar GPU (26 MHz), Jaguar DSP (26 MHz)
  SOUND : 2x DAC, 2x Channels
  VIDEO : 320x240 (60 Hz, palette 65534)
- NOTES : The hardware is a variant of the Jaguar home console. The interesting thing about the CoJag system is that the designer had the option of using either a 68010 or a MIPS R3000 as the primary CPU. The CoJag also had an IDE interface so you could hook up a hard disk, which is what Area 51 uses. As far as I know, nobody has yet attempted to emulate the CoJag hardware.
- SOURCE: drivers\cojag.c
- GAMES : Atari - Area 51 (1995), Maximum Force (1996), Vicious Circle (1996)


H2.8   Atari/Midway Seattle
- CPU   : R5000 (little) (150 MHz), ADSP2115 (16 MHz)
  SOUND : 2x DMA-driven DAC, 2x Channels
  VIDEO : 640x480 (57 Hz, palette 65536)
  EXTRA : 3dfx Voodoo Card, Harddisk 
- SOURCE: drivers\cojag.c
- GAMES : San Francisco Rush (Atari 1996), Wayne Gretzky's 3D Hockey (Atari 1996), NFL Blitz (Midway 1997), CarnEvil (Midway 1998)


H2.9   Atari/Midway Vegas
- CPU   : R5000 (little) (200 MHz), ADSP2104 (16 MHz)
  SOUND : 2x DMA-driven DAC, 2x Channels
  VIDEO : 640x480 (57 Hz, palette 65536)
- SOURCE: drivers\vegas.c
- GAMES : Gauntlet Legends (1998), Tenth Degree (1998), Road Burners (1999)


H2.A   Atari MediaGX
- CPU   : MEDIAGX (166 MHz)
  SOUND : 2x DAC, 2x Channels
  VIDEO : 640x240 (60 Hz, palette 16)
- SOURCE: drivers\mediagx.c
- GAMES : Area 51: Site 4 (1998)



H3.    Bally/Sente SAC-1 system
- CPU   : M6809 (1.25 MHz), Z80 (4 MHz)
  SOUND : 6x CEM3394, 1 Channel
  VIDEO : 256x240 (60 Hz, palette 1024)
- GAMES : Bally/Sente - Trivial Pursuit (1984), Stocker (1984), Mini Golf (1985), Name That Tune (1986), Rescue Raider (1987)



H4.    Capcom
H4.1   Capcom System 1
- CPU   : 68000 (10 MHz), Z80 (3579545 Hz)
  SOUND : YM2151 (3579545 Hz), OKI6295 (6061 Hz), 1 Channel
  VIDEO : 384x224 (60 Hz, palette 4096)
- GAMES: Capcom - Forgotten Worlds (1988), Ghouls'n Ghosts (1988), Willow (1989), Mercs (1990), Varth (1992)

H4.2   Capcom System 2
- CPU   : 68000 (11.8 MHz), Z80 (8 MHz)
  SOUND : Q-Sound (4 MHz), 2x Channels
  VIDEO : 384x224 (59.633331 Hz, palette 4096)
- GAMES: Super Street Fighter 2: The New Challengers (1993), X-Men: Children of the Atom (1994), X-Men Vs. Street Fighte(1996)

H4.3   Capcom System 3
- CPU   : SH-2 (20 MHz)
  SOUND :
  VIDEO : 512x512 (60 Hz, palette 4096)
- Hardware: Arcade CD + encryption cartridge
- GAMES: Warzard (1996), Streetfighter III (1997)



H5.    Century Electronics
H5.1   CVS
- CPU   : 2x S2650 (894886 Hz)
  SOUND : 2x DAC, TMS5110 (640000 Hz), 1 Channel
  VIDEO : 248x240 (60 Hz, palette 16)
- SOURCE: drivers\cvs.c
- GAMES: Century Electronics - Cosmos (1981), Wall Street (1982), Hunchback (1983)



H6.    Data East
H6.1   DECO Cassette System
- CPU: 2x M6502, I8X41        Sound: 2x AY-3-8910       Video: 240x240, 32 colors
- NOTES: The games are protected with dongles. There are five types of dongles (PROM/EPROM with 32, 2048, 4096, 32768 bytes data or NOP's). The tape use a leader-BOT-data-EOT-trailer format: A cassette has a transparent piece of tape on both ends, leader and trailer. And data tapes also have BOT and EOT holes, shortly before the leader and trailer. The holes and clear tape are detected using a photo-resitor. When rewinding, the BOT/EOT signal will show a short pulse and if rewind continues a constant high signal later. The specs say the holes are "> 2ms" in length.
- GAMES: Cassette - Highway Chase (1980), Lock'n'Chase (1981), Burger Time (1983), Boulder Dash (1985)

H6.2   Data East PC-Engine
- CPU: HuC6280, HuC6280 (Sound)    Sound: YM-2203, MSM5205    Video: 256x232, 512 colors
- NOTES: This board is a modified PC Engine PCB, differences from PC-Engine console: Input ports are different (2 dips, 2 joysticks, 1 coin port), _Interface_ to palette chip is different, palette data is the same. Extra sound chips, and extra processor to drive them. Twice as much VRAM.
- GAMES: Data East - Battle Rangers (1988)

H6.3   Data East 32
- CPU: ARM, HuC6280    Sound: YM2151, 2x MSM6295      Video: 320x240, 2048 colors
- GAMES: Data East - Captain America (1991), Dragon Gun (1993)

H6.4   Data East MLC
- CPU: ARM or SH-2    Sound: YMZ280B, YAC513          Video: 320x240, 4096 colors
- NOTES: The MLC system is basically an 8" x 6" x 2" plastic box with a JAMMA connector on it. The PCB's are very compact and have almost entirely surface mounted components on both sides of both boards. One board contains the RAM, sound hardware and I/O, the other board contains the CPU and ROMs. All main boards are identical between the MLC games and can be changed just by plugging in another game and pressing test to reset the EEPROM defaults.
- GAMES: Data East - Avengers In Galactic Storm (1995),  Skull Fang (1996)


H7.    Exidy
H7.1   Max-A-Flex
- NOTES: The Max-A-Flex system is basically an Atari 600XL computer inside an arcade cabinet. There is additional hardware that controls the length of time that you may play the game.
- GAMES: First Star Software - Astro Chase (1982), Flip and Flop (1983), Boulder Dash (1984)



H8.    IGS
H8.1   PGM
- CPU: M68000, Z80 (Sound)   Sound: ICS WaveFront-2115 Wavetable    Video: 448x224, 2304 colors
- NOTES: PGM = PolyGame Master. A flexible cartridge based platform, it only uses a 68000 for the main processor and a Z80 to drive the sound. Resolution is 448x224, 15 bit colour. Sound system is ICS WaveFront-2115 Wavetable midi syntesizer, used in some actual sound cards (Turtle Beach). The later games would appear to be encrypted.
- GAMES: IGS Oriental Legend (1997), Dragon World II (1997), Knights of Valour (1999)


H9.    Irem
H9.1   M62
- CPU: Z80 (4 MHz), M6803 (sound)   Sound: 2x AY-8910, 2x MSM5205     Video: 384x256, 512 colors
- GAMES: Irem - Lode Runner (1984), Spelunker (1985), Kid Niki (1986)

H9.2   M72
- CPU: NEC V30 (16 MHz), Z80 (sound)   Sound: YM-2151, DAC     Video: 384x256, 1024 colors and Nanao video controller
- Video capabilities: Sprites and the two backgrounds layers
- GAMES: Irem - R-Type (1987), Battle Chopper (1987), Ninja Spirit (1988), Image Fight (1988)

H9.3   M92
- CPU: NEC V33 (18 MHz), NEC V30 (sound)   Sound: YM-2151, GA20     Video: 320x240, 1024 colors
- GAMES: Irem - Gunforce (1991), Hook (1992), R-Type Leo (1992), In The Hunt (1993)

H9.4   M107
- CPU: NEC V33 (28 MHz), NEC V30 (sound)   Sound: YM-2151, GA20     Video: 240x320, 2048 colors
- GAMES: Irem - Fire Barrel (1993), Dream Soccer '94 (1994)


H10.    Jaleco
H10.1   Mega System 1
- CPU: M68000 (12 MHz), M68000 (Sound)     Sound: YM-2151, 2x MSM6295       Video: 256x224, 1024 colors
- GAMES: Jaleco - P-47 (1988), RodLand (1990), Avenging Spirit (1991), Cybattler (1993)

H10.2   Mega System 32
- CPU: V70, Z80        Sound: YMF271, YAC513      Video: 320x224, 32768 colors
- GAMES: Jaleco - Best Bout Boxing (1994), Desert War (1995)


H11.    Kaneko
H11.1   Super Nova System
- CPU: Hitachi SH-2      Sound: YMZ280B      Video: 320x240, 32768 colors
- NOTES: System use a BIOS
- GAMES: Cyvern (1998), Puzz Loop (1998)


H12.    Konami
H12.1   GX-Boards
- NOTES: Konami boards are from GX300 to GX9910. Some examples: Finalizer (GX523), Double Dribble(GX690), Flak Attack (Konami GX669), Fast Lane(GX752), Labyrinth Runner (GX771), Gangbusters(GX878) and Gradius 3 (GX945)

H12.2   GX611
- CPU: HD6309, Z80 (Sound)    Sound: YM-2203, uPD7759    Video: 256x224, 128 colors
- GAMES: Konami - Combat School (1988)

H12.3   GX777
- CPU: HD6309, Z80 (Sound)    Sound: 2x YM-3812    Video: 224x256, 128 colors
- GAMES: Konami - Battlantis (1987), The Hustler (1987)

H12.4   GX797
- CPU: HD6309, M6809 (Sound)    Sound: YM-2203, uPD7759    Video: 224x256, 48 colors
- GAMES: Konami - Blades of Steel (1987)

H12.5   GX973
- CPU: KONAMI, Z80 (Sound)    Sound: YM-2151    Video:  288x224, 1024 colors
- GAMES: Konami - Block Hole (1989)

H12.6   System GX
- CPU: M68020, M68000 (Sound)   Sound: ???   Video: ???

H12.7   System GV
- NOTES: SCSI CD-based PSX hardware
- CPU: PSX CPU                 Sound: PSX SPU + CD Audio (Sound)   Video: 640x480, 65536 colors

H13.    Metro
- CPU: M68000, uPD7810       Sound: OKIM6295+YM2413 or YMF278B+YRW801-M   Video: 360x224, 8192 colors
- GAMES: Metro - Pang Poms (1992), Poitto! (1993), Puzzli (1995), Bal Cube(1996)


H14.    Midway
H14.1   MCR-1 system
- CPU: Z80 (2.5 MHz), Z80 (sound)   Sound: 2x AY-8910     Video: 480x512, 32 colors
- GAMES: Midway - Solar Fox (1981), Kick (1981)

H14.2   MCR-2 system
- CPU: Z80 (2.5 MHz), Z80 (sound)     Sound: 2x AY-8910     Video: 480x512, 64 colors
- GAMES: Midway - Satan's Hollow (1981), Tron (1982), Two Tigers (1984)

H14.3   MCR-3 system
- CPU: Z80 (5 MHz), Z80 (sound)   Sound: 2x AY-8910     Video: 512x480, 128 colors
- GAMES: Midway - Tapper (1983), Timbern (1984)

H14.4   MCR-68k system
- CPU: M68000 (7.6 MHz), M68000 (sound)   Sound: DAC     Video: 512x480, 128 colors
- GAMES: Midway - Zwackery (1984), Xenophobe (1987), Blasted (1988)

H14.5   Midway T-Unit System
- CPU: TMS34010 (6.25 MHz), M6809 (sound)   Sound: YM2151, DAC, MSM6295      Video: 395x254, 32768 colors
- GAMES: Midway - Mortal Kombat (1992), Judge Dredd (1993), NBA Jam (1993)

H14.6   Midway V-Unit System
- CPU: TMS32031 (50 Mhz), ADSP2105 (sound)   Sound: Custom      Video: 512x400, 32768 colors
- GAMES: Midway - Cruis'n USA (1994), Cruis'n World (1996)

H14.7   Midway Wolf-Unit System
- CPU: TMS32031 (6.25 Mhz), ADSP2105 (sound)   Sound: Custom      Video: 395x253, 32768 colors
- GAMES: Midway - Mortal Kombat 3 (1994), Rampage: World Tour (1997)

H14.8   Williams/Midway Y/Z-unit system
- CPU: TMS34010 (6 Mhz), M6809 (sound)   Sound: YM2151, DAC, HC55516      Video: 400x256, 4096 colors
- GAMES: Narc (Williams 1988), Smash T.V. (1990), Total Carnage (1992)


H15.    Namco
H15.1   Namco System 86
- CPU: 2x M6809 (Main and Sound), HD63701     Sound: YM-2151, Namco, PCM sound ROM, Custom       Video: 288x224, 512 colors
- GAMES: Namco - Hopping Mappy (1986), Sky Kid Deluxe (1986), The Return of Ishtar (1986), Rolling Thunder (1986)

H15.2   Namco System 1
- CPU: 3x M6809 (Main, Sub and Sound), HD63701 (Input,EEPROM,DAC)     Sound: YM-2151+YM-3012, Namco, DAC       Video: 224x288, 5121 colors
- Graphics: 3 scrolling 64x64 tilemapped playfields, 1 scrolling 64x32 tilemapped playfield and 2 fixed 36x28 tilemapped playfields
- GAMES: Namco - Pac-Mania (1987), Galaga '88 (1987), Dangerous Seed (1989), Tank Force (1991)

H15.3   Namco System 2
- CPU: 2x M68000 (Mainand Sub), M6809 (Sound), HD63705 (Dips/Input), CPU5     Sound: C140, YM-2151       Video: 224x288, 8192 colors
- Graphics Board: 1 x Rotate/Zoom tile plane (256x256 tiles) and 128 Sprites (128 Sprites displayable, but 16 banks of 128 sprites)
- Text/tile plane generator: 2 x Static tile planes (36x28 tiles) and 4 x Scolling tile planes (64x64 tiles)
- NOTES: CPU5 is a Serial I/F Controller and it is not emulated by MAME yet.
- GAMES: Namco - Assault (1988), Finest Hour (1989), Rolling Thunder 2 (1990), Super World Stadium (1992)

H15.4   Namco System NA-1 / NA-2
- CPU: M68000 (8 MHz)    Sound: ???    Video: 304x224, 8192 colors
- GAMES: Namco - Knuckle Heads (1992), Emeraldia (1993)

H15.5   Namco System NB-1
- CPU: M68EC020 (12.5 MHz)   Sound: ???    Video: 288x224, 8192 colors
- GAMES: Namco - Point Blank (1994), Super World Stadium '96 (1996)

H15.6   Namco System ND-1
- CPU: M68000 (12.28 MHz)    Sound: ???    Video: 224x288, 256 colors
- GAMES: Namco - Namco Classics Collection Vol.1 (1995), Namco Classics Collection Vol.2 (1996)

H15.7   Namco System 11
- CPU: PSX_CPU (16 MHz)    Sound: Namco C352    Video: 640x480, 65536 colors
- GAMES: Namco - Tekken (1994), Xevious 3D (1995), Soul Edge (1995), Star Sweep (1997)

H15.8   Namco System 12
- CPU: PSX_CPU (16 MHz)    Sound: ???    Video: 640x480, 65536 colors
- GAMES: Namco - Tekken 3 (1996), Aqua Rush (1999)

H15.9   Namco System 21
- CPU: 68EC020 (25 MHz)   Sound: ???    Video: 640x480, 32768 colors
- GAMES: Namco - Prop Cycle (1996)

H15.10  Namco System 22
- CPU: 2x M68000 (12.288 MHz), M6809, HD63705    Sound: C140, YM2151     Video: 496x480, 32768 colors
- GAMES: Namco - Solvalou (1991), Starblade (1991)

H15.11  Namco System 23
- CPU: R4650 (MIPS III) 166 MHz                  Sound:     Video: 768x512, 8192 colors
- GAMES: Namco - GP500 (1999)


H16.    Nintendo
H16.1   Playchoice 10
- CPU: Z80, N2A03           Sound: Nintendo, DAC         Video: 256x480, 320 colors
- GAMES: Nintendo PlayChoice-10 - Mario Bros. (1983), Ninja Gaiden (1989), Solar Jetman (1990)

H16.2   Super System
- CPU: G65C816 (2.68 MHz)   Sound: SPC700, Custom        Video: 256x240, 32768 colors
- GAMES: Nintendo Super System cart - F-Zero, Super Tennis, Super Mario World, Lethal Weapon (1993)


H17.    Sega
H17.1   G-80 Raster
- CPU: Z80, I8035 or N7751 (Sound)     Sound: Mixture of TMS36XX, DAC, Custom, Speech Synthesis, discrete sound circuitry   Video: 224x256, 65 colors or 129 colors
- NOTES: The board uses security chips (315-0064, 315-0070, 315-0076, 315-0082). And a 315-0062  for Astro Blaster and a 315-0063 for Space Odyssey. Sindbad Mystery does *not* use the standard G-80 security chip; rather, it uses the Sega System 1 encryption. Also the Sega raster games don't have a color PROM.  Instead, it has a color RAM that can be filled with bytes of the form BBGGGRRR.
- GAMES: Sega - Astro Blaster (1981), 005 (1981), Space Odyssey (1981), Monster Bash (1982), Pig Newton (1983), and Sindbad Mystery (1983)

H17.2   G-80 Vector
- CPU: Z80     Sound: Samples (EPROMs), Custom        Video: Vector Screen, 256 colors
- NOTES: The Sega vector games don't have a color PROM, it uses RGB values for the vector guns.
- GAMES: Sega: Space Fury (1981), Zektor (1982), Tac/Scan (1982), Star Trek (1982)   Gremlin: Eliminator (1981)

H17.3   System 1/2
- CPU: 2x Z80 (4MHz)   Sound: 2x SN76496     Video: 224x240 or 224x256, 1536 colors
- GAMES: Sega - Up'n Down (1983), Flicky (1984), Spatter (1984), Pitfall II (1985), Choplifter (1985), Wonder Boy (1986)

H17.4   SG-1000
- GAMES: Sega - Champion Boxing (1984), Champion Pro Wrestling (1985)

H17.5   System 16A
- CPU: M68000 (10 MHz), Z80 (Sound)   Sound: YM-2151, NEC uPD7751 ADPCM decoder, DAC Sound   Video: 320x224, 4096 colors
- GAMES: Sega - Alex Kidd (1986), Fantasy Zone (1986), Quartet II (1986)

H17.6   System 16B
- CPU: M68000 (10 MHz), Z80 (Sound)   Sound: YM-2151, NEC uPD7759 ADPCM decoder    Video: 320x224, 4096 colors
- GAMES: Sega - Alien Syndrome (1987), Shinobi (1987), Altered Beast (1988), Riot City (1991)

H17.7   System 18
- CPU: M68000 (10 MHz), Z80 (Sound)   Sound: 2x YM-3438, Sega RF5C68 PCM Sound   Video: 320x224, 4096 colors
- GAMES: Sega - Shadow Dancer (1989), Alien Storm (1990)

H17.8   System 24
- CPU: 2x M68000      Sound: YM2151 and Sega Custom PCM (YM3012 DAC)
- NOTES: The System 24 is the first Sega system that needs a medium resolution arcade monitor to work. It's also the first Sega system that read the program from a floppy disk (80 tracks (0-79)). There are also versions of some games using a rom board instead of the disk (Bonanza Bros at least).
- GAMES: Sega - Hot Rod (1988), Scramble Spirits (1998), Bonanza Bros. (1990), Rough Racer (1990)

H17.9   System 32
- CPU: NEC V60 (1.34 MHz), Z80 (Sound)   Sound: 2x YM3438, RF5C68    Video: 320x224, 16384 colors
- GAMES: Sega - Spiderman (1991), Holosseum (1992), Sonic (1992), Alien 3 (1993)

H17.10  System C
- CPU: M68000 (10 MHz)                   Sound: YM-2612, SN76496     Video: 320x224, 2048 colors
- GAMES: Sega - Columns (1990), Columns II (1990)

H17.11  System C2
- CPU: M68000 (10 MHz), Z80 (Sound)   Sound: YM-2612, SN76496, uPD7759    Video: 320x224, 2048 colors
- NOTES: Sega's C2 was used between 1989 and 1994, the hardware being very similar to that used by the Sega MegaDrive/Genesis Home Console Sega produced around the same time.
- GAMES: Sega - Borench (1990), Tant-R (1992), Poto Poto (1994)

H17.12  MegaPlay
- CPU: M68000 (7.67 MHz), Z80 (Sound)   Sound: YM2612, SN76496    Video: 320x224, 2048 colors
- NOTES: A Sega Genesis-Mega Drive based arcade system.
- GAMES: Sega cartridge - Sonic The Hedgehog

H17.13  Mega Tech
- CPU: M68000 (7.67 MHz), Z80 (Sound)   Sound: YM2612, SN76496    Video: 320x224, 2048 colors
- NOTES: A time-based Sega Genesis-Mega Drive / Master System based arcade system.
- GAMES: Sega cartridge - Super Monaco GP, World Championship Soccer

H17.14  Multi-32
- CPU: NEC V60, Z80   Sound: YM3438, Sega Custom PCM
- GAMES: Sega - Hard Dunk (1992), Title Fight (1992), Stadium Cross (1992), Out Runners (1993)

H17.15  Model 1
- CPU: NEC V60 (uPD-70616), Co-Processors: Fujitsu TGP (x4), M68000 (10Mhz/Sound)    Sound: Sega PCM    Video Resolution 496x384, 65536 colors
- Rendering specs: 180,000 polygons/s, 540,000 vectors/s, 1,200,000 pixels/s. Video capabilities: Flat Shading, Diffuse Reflection, Specular Reflection, 2 Layers of Background Scrolling, Alpha Channel
- GAMES: Sega - Wing Wars (1992), Virtua Racing (1993), Virtua Fighter (1993)

H17.16  Model 2
- CPU: I960, M68000    Sound: YMF292-F
- NOTES: The Model 2 system did a two version (2A and 2B).
- GAMES: Sega - Daytona USA (1993)

H17.17  Model 3
- GAMES: Sega - Virtua Fighter 3 (1996), Lost World, Virtua Striker 2 (1998)

H17.18  Titan-V
- NOTES: Sega ST-V (Sega Titan Video)


H18.    Seibu
H18.1   SPI
- CPU: Intel 386 DX 25MHz / 33MHz    Sound: Z80 8MHz, YMF271F      Video: 320x240, 6144 colors
- NOTES: The Seibu SP system consists of a main board and a plug-in cartridge containing the game software. The games on SPI hardware can be swapped by changing the top cartridge and then moving jumper JP072 to the alternative position. This re-flashes some ROMs for a few minutes (accompanied by a techno music track). Afterwards, a message tells you to put the jumper back to the original position and reboot the PCB. The new game then plays. There were a few revisions of this hardware, though most are the same with only minor changes such as different IC revisions etc.


H19.    Seta
H19.1   SSV
- CPU: NEC V60    Sound: Ensoniq ES5506     Video: 336x240, 32768 colors
- NOTES: Seta, Sammy, Visco = SSV
- GAMES: Survival Arts (1993), Drift Out '94 (1994), Monster Slider (1997), Change Air Blade (1999)


H20.    SNK
H20.1   SNK
- CPU: 3x Z80      Sound: 2xYM3526 or YM3526 + Y8950      Video: 288x216, 1024 colors
- GAMES: SNK - TNK III (1985), Ikari Warriors (1986), Bermuda Triangle (1987), Chopper I (1988)

H20.2   SNK68
- CPU: M68000, Z80,       Sound: YM3812, uPD7759      Video: 256x224, 2048 colors
- GAMES: SNK - P.O.W. (1988), Street Smart (1989), Ikari III (1989)


H21.    Sony
H21.1   ZN1/ZN2
- CPU: PSXCPU, Z80   Sound: Sony Playstation
- GAMES: Capcom - Battle Arena Toshinden 2 (1995), Tetris The Grand Master (1998), Strider Hiryu 2 (1999)


H22.    Taito
H22.1   Taito Air System
- CPU: M68000, Z80, TMS320C25      Sound: YM-2610       Video: 512x400, 8192 colors
- NOTES: TMS320C25 needs to be emulated.
- GAMES: Taito - Top Landing (1988), Air Inferno (1990)

H22.2   Taito B System
- CPU: M68000 (12 MHz), Z80 (Sound)     Sound: YM-2610       Video: 320x224, 4096 colors
- Graphics: It supports 4 separate layers of graphics - one 64x64 tiled scrolling background plane of 8x8 tiles, a similar foreground plane, a sprite plane capable of sprite zooming and a text plane which may be 'pageable.
- GAMES: Taito - Nastar (1988), Rambo 3 (1989), Ashura Blaster (1990), Space Invaders DX (1994)

H22.3   Taito F2 System
- CPU: M68000 (12 MHz), Z80 (Sound)     Sound: YM-2610       Video: 320x224, 4096 colors
- Graphics: The main board supports three 64x64 tiled scrolling background planes of 8x8 tiles, and a powerful sprite engine capable of handling all the video chores by itself (used in e.g. Super Space Invaders). The front tilemap has characters which are generated in RAM for maximum versatility (fading effects etc.). The expansion board can have additional gfx chip e.g. for a zooming/rotating tilemap, or additional tilemap planes.
- GAMES: Taito - Final Blow (1988), Camel Try (1989), Liquid Kids (1990), Metal Black (1991)

H22.4   Taito F3 System
- CPU: M68EC020 (16 MHz), M68000 (Sound)     Sound: ES5505       Video: 320x232, 8192 colors
- Custom chips: TC0630 FDP - Playfield generator?, TC0640 FI0 - I/O & watchdog?, TC0650 FDA - Priority mixer?, TC0660 FCM - Sprites?
- GAMES: Taito - Ring Rage (1992), Gunlock (1993), Elevator Action Returns (1994), Bubble Memories (1995), Landmaker (1998)

H22.5   Taito H System
- CPU: M68000 (12 MHz), Z80 (Sound)     Sound: YM-2610      Video: 320x240
- GAMES: Taito - Syvalion (1988), Recordbreaker (1988), Dynamite League (1990)

H22.6   Taito L System
- CPU: Z80 (6 MHz)                      Sound: YM-2203       Video: 320x224, 256 colors
- NOTES: The Taito L-System boards are Monoprocessor games (1 main z80, no sound z80).
- GAMES: Taito - Puzznic (1989), Palamedes (1990), Play Girls (1992), Cachat (1993)

H22.7   Taito SJ System
- CPU: Z80 (4 MHz), Z80 (Sound)         Sound: 4x AY-8910, DAC    Video: 256x224, 64 colors
- GAMES: Taito - Space Seeker (1981), Jungle King (1982), Elevator Action (1983 + M68705 Protection)

H22.8   Taito X System
- CPU: M68000 (8 MHz), Z80 (Sound)      Sound: YM-2610        Video: 384x240, 2048 colors
- GAMES: Taito - Superman (1988), Twin Hawk (1989), Balloon Brothers (1992)

H22.9   Taito Z System
- CPU: M68000 (12/16MHz), Z80 (Sound)   Sound: YM-2610        Video: 320x240
- NOTES: The Taito Z system has a number of similarities with the Taito F2 system, and uses some of the same custom Taito components.
- GAMES: Taito - Chase HQ (1988), Battle Shark (1989), Aqua Jack (1990)

H22.A   Taito GNET System
- NOTES: The Taito GNET System uses a Sony ZN-2 Motherboard (Main CPU/GPU/SPU, RAM, BIOS, EEPROM & peripheral interfaces), Taito FC PCB (Sound hardware & FLASHROMs for storage of PCMCIA cart contents) and Taito CD PCB (PCMCIA cart interface)
- GAMES: Go By RC! (Taito 1999), Psyvair Medium Unit (Success 2000), Souten-Ryu (Taito 2000), Nightraid (Takumi 2001)


H23.    Tecmo
H23.1   Tecmo 68k system
H23.2   Tecmo System


H24.    Board Serial Numbers / Labels


        Board                                   Manufacturer            Games                                         Notes

        60138-0083                              SunA                    Hardhead
        800-0058, 800-0107, 800-3157            Sega                    005, Carnival, Elim2
        833-6599, 833-6072, 833-10545           Sega                    Angelkds, Bodyslam, Jpark, Spidey
        834-0131, 834-5120, 834-5386            Sega                    Buckrog, Scobra, Tapper
        837-11542, 838-11587, 837-11861         ST-V system, Model 3    Bakubaku, Colmns97, Harley
        838-12885                               Sega                    RyuKyu
        84P0100B, 84P0501A                      Nichibutsu              Tubep, Rjammer
        86117                                   CAPCOM                  1943
        8661961000 (8661971000)                 Namco                   Ehrgeiz, Fgtlayer, Soulclbr
        8661961101 (8661971101)                 Namco                   Aquarrush, Mrdrillr
        97695-1                                 CAPCOM ZN-2             Sfex2, Sfexp, Strider2, Techromn
        A007203, A009787, A036434               Atari                   Boxer, SkyDiver, Warloards
        A74-PWB-A-(A), A77-PWB-A-(A)            Home Data               Mhgaiden, Hourouki
        AA017756, AA017757, AA017xxx            Taito                   Ballbomb, Galxwars, Invatpt2
        AM007B1094                              Art & Magic             Stonebal
        AT-9301033D, AT-C03                     Atlus                   Ddonpach, Naname
        BP922, BP923, BP924                     Banpresto               Dbz, Umanclub, Neobattl
        C2 Board                                Sega System C/C2        Puyopuyo, Tantr
        COH-100, COH-110, COH-700               Namco System11/12       Starswep, Aquarush
        COH-1002M, COH-3002C                    ZN-1/ZN-2 BIOS          Glpracr2
        COMAD-01, COMAD-0953                    Comad                   Bballs, Fantsy95
        CP-SYTEM II  # 93646B-7                 CAPSOM System 2         Mmatrix
        CV070005                                Taito                   Ballbomb, Galxwars, Invatpt2, Ozmawars         Audio/IO board
        D0208298L1, D039198L-0                  Dyna Electronic         Dondenmj, Hnayayoi
        D0706088L1-0, D0908288L1-0, D1708228L1  Dynax                   Mjdiplb, Tontonb
        D5512068L1-2                            Dynax                   Mjangels, Quiztvqq
        DE-0030, DE-0298, DE-0346               Data East               Alphaho, Mutantf, Thedeep
        DEC-22VO, DEC-22V0                      Data East               CharlieNinja, DoubleWings, LadyKiller2
        DSP-3, DSP-5, DSP-9                     Data East               Disco, Lnc, Cburnrub
        E90, E92                                Seta                    11beat, Mtetrisc
        ES-9206, ES-9309B-B                     Excellent Systems       Aquarium, Vmetal
        GDP-01, GDP-02                          Amenip                  Nmouse, Woodpecker, Piranha
        GN672, GN678, GN715                     Konami                  GTIClub, Sscope2
        GP-11, GP-13, GP-15                     Namco System11/12       Starswep, Daneyes, MrDrillr
        GX973                                   Konami                  Blockhl
        ISP-1244-1A                             Data Amusements         Sucasino
        J1100004A                               Taito                   40love, FieldDay, VictoriousNine
        K1100010A, K1100388A, K1100470A         Taito                   Bonzeadv, Cadash, Crimec
        KA302C                                  Psikyo                  Gunbird, Btlkroad
        ZO1DK-002                               Kaneko                  Brapboys, Shogwarr
        KRB-14, KRB-17                          SunA                    Hardhead, Starfigh
        KT-4109-2                               Konami                  Tazmania, Losttomb
        L-1200-B, L1200                         Konami cpu/sound board  Superbon, Miminkey, Tazmania
        LINDA2, LINDA25                         Wintechno, Face         Mcatadv, Nost
        M4300056B, M4300140A                    Taito                   Bigevglf, Topspeed, Ninjaw
        M6100070A, M6100326A, M6100109A         Taito, SNK              Twineagl, Tsamurai, Tnk3
        M62-A-B, M62-E-A                        IREM M62 Hardware       Battroad, Ldrun
        M92-A-B, M92-B-G                        IREM M92 Hardware       Gunforc2, Majtitl2
        MACS-SUB, MACS2-SUB                     Multi Amenity Cassette System     Cultname, Yujan
        MB-94166 EB91022-20101, MB-9314         Jaleco Mega System 32   Kirarast, Gametngk, Tetrisp
        MJ-8956                                 Mahjong games           47pie2, Kakumei2, Suchipi
        MPG DW-00011C, MPG 010-00018-002        MicroProse              Botss, F15se
        MTR5260-A                               Metro/Banpresto         Daitorid, Poitto, Pururun, Puzzli
        NB6853, NB67634                         Nichibutsu              Aparel, Mjuraden
        NEO-MVH MV1                             Neo-Geo                 Nightmare in the Dark
        P0-055B, P0-057A, P0-051A, PO055D       Seta, Visco, Taito      Wits, Twinhawk, Blockcar, Thunderl
        PB91008, BP954KA                        Banpresto               Sdgndmps, Gundhara
        PCB-100102                              Acclaim                 Nbajamex
        PI-500802, P1-500810, P1-500861,        Nintendo                Helifire, Spacefev, Spacelnc
        PO-063A, PO-102A, PO-114A               Banpresto, Seta, Sammy  MadShark, Rezon, Zingzip
        PS4                                     Psikyo                  Hotgmck, Hgkairak, Hotdebut, Loderndf
        PWB 351535A, PWB 352011A, PWB454204A    Konami                  Crimfght, Mainevt, Punkshot, Thunderx, Winspike
        RA9503, RA9701, RA-MA7893-01            Eighting/Raizing        Battleg, Beastrzr
        RB-91105A EB911009-20045-1              Jaleco                  Bigstrik, Cybattlr
        SEI-8611M, SEI-8712A                    Seibu                   PanicRoad, Deadang
        SH403, SH404                            Psikyo                  S1945, Tengai
        SXX2C ROM SUB                           SPI system              Ejanhs, Senkyu
        TA-0017-1, A-0021, TA-0023, TA-0031     Technos                 Maniach, Chinagat, Ddragon, Wwfwfest
        TKG4                                    DK/Jr Conversion board  Drakton, Spcfrcii
        TP-020, TP-023, TP-027                  Toaplan                 Grind Stormer, Batsugun
        TPS                                     Tecmo                   Glpracr, Glpracr2, Todemo
        UPL-83001, UPL-90058, UPL-90064         UPL                     Mouser, Mustang, Vandyke
        VG330-B, VG340-A                        Make Software / Elf     Mahjong Doukyuhsei
        VG420                                   Metro                   Skyalert, Lastfort
        X73-PWB-A(C), X77-PWB-A-(A)             Home Data               Mjkojink, Mjhokite
        YS-2002, YS-2113                        Yunsung                 Pclubys, Tgtball
        ZN-2                                    Sony (Playstation)      Sfex2, Sfexp
        ZPU                                     Stern                   Berzerk, Frenzym, Mazerbla, Cliffhanger




 


ROM/RAM TYPES

  1.    ROM
  2.    PROM
  2.1   EAROM
  2.2   EEPROM
  2.21  BIOS EEPROM
  2.3   EPROM Emulator
  2.4   Flash Memory
  2.41  Flash ROM
  2.42  Flash Memory + Switching Regulator

  3.    RAM
  3.1   SRAM
  3.2   SGRAM
  3.3   DRAM
  3.4   EDO RAM
  3.5   VRAM

  4.    NVRAM
  4.1   DALLAS
  4.11  DS1220
  4.12  DS1225
  4.13  DS1230
  4.14  DS1235
  4.2   FM1208

  5.    NOVRAM
  5.1   2055
  5.2   2212
  5.3   2816

  6.    Buffer
  6.1   81LS95
  6.2   CY7B991
  6.3   4050

  7.    FIFO
  7.1   LH5496
  7.2   LH540202
  7.3   7200
  7.31  7201
  7.32  7203
  7.4   ACT7814
  7.5   KM75C02

  8.    Battery backed RAM
  8.1   449
  8.2   5164
  8.3   M4T28
  8.31  M48T58
  8.4   MK48T02
  8.41  MK48T08
  8.5   MK48Z02
  8.51  MK48Z08

  9.    Battery
  9.1   2032
  9.2   2325
  9.3   5104
  9.4   QTC85


..................................................................................................................................................................................................................................


R1.    ROM
-----------


WIP:

-  3rd February 2008: Guru - Some time ago I bought an adapter for one of my EPROM Programmers for support of a 128M TSOP48 maskROM. It turns out that the same chip is used in Atomiswave carts and is easily dumped. I think I might have actually bought it for that purpose 3 years ago! The main problem now is it takes 2 1/2 hours to read one chip and to verify it with 3 reads will take an unacceptably long time. Oh yeah, so I have decided to upgrade that unit to the latest high speed USB2 model. That will set me back around AU$1800 and also requires a separate universal TSOP48 module which is another AU$400. But ahh, it's for the good of MAME-kind.


Texas Instruments (TMS 25xx/27xx):

2516        =    2048 =    2k        (TI TMS2516JL) (Astrob, Centiped)
2532        =    4096 =    4k        (TI TMS2532JDL, TMS2532JL, SGSM2532, MCM2532C) (Liberatr, Mspacman)
2564        =    8192 =    8k        (TI 2564, TMS2564JL, HSRM2564) (Kick, Paranoia)

2708        = >  8 kbit =  8 x 1024 bit = 1024 bytes = 1 kbyte = 1k  (1k x 8, DIP24 - TMS2708JL, Mitsubushi 2708, OKI MSM2708, National Semiconductor MM2708Q, F2708, 82S2708, MCM2708)
2716        = > 16 kbit = 16 x 1024 bit = 2048 bytes = 2k            (2k x 8 - TMS2716, AM2716, SGS M2716, D2716D, MBM2716, M5L2716K, MSM2716AS, Mostek MK2716J, ID2716, Toshiba TMM323D-2716, AMD2716)
2732        =    4096 =    4k        (4k x 8, AMD2732DC, AM2732DC, Fujitsu 2732A, NEC D2732D, ID2732A, M5L2732K, ET2732Q, MBM2732)
2758        =    2048 =    2k        (MM2758Q, Intel B2758, TMS2758JD) (Hustler, DiscoFever, Mooncrst)
2763        =    8192 =    8k        (Intel D2763)
2764        =    8192 =    8k        (TMS2764, Fujitsu MBM2764K, Mitsubushi M5L2764K, ML52764, Intel P2764, D2764A, SGS M2764, TMM2764, ID2764, SGS M2764, AN482764G, HN482764G, F-DIL-28, SEEQ DQ2764, SEEQ2764)
27080       = 2097152 = 2048k = 2MB  (NEC uPD27080)
27128       =   16384 =   16k        (Mitsubishi M5L27128K, M27128A, D27128, AM27128, HN4827128G, I27128A, P27128A)
27256       =   32768 =   32k        (AM27256, TMM27256AD, Intel P27256, HN27256, NEC D27256D, MBM27256, TMS27256JL, F-DIL-28)
27301       =  131072 =  128k
27512       =   65536 =   64k        (AM27512, SGS/Thomson M27512-2FIST, HN27512P, TMM27512D, M27512FI, TMS27PC512)
27CX322     =    4096 =    4k        (F1gpstar)
27CX642     =    8192 =    8k        (Wildplt)
27C64       =    8192 =    8k
27C010      =  131072 =  128k        (AMD 27C010, AM27C010, TI TMS27C010A, D27C010A, NM27C010Q)
27C020      =  262144 =  256k        (AM27C020, D27C020, ID27C020, Atmel AT27C020 - OTP Mask, Intel 27C020)
27C040      =  524288 =  512k        (4MBit Mask, DIP32) (AM27C040, M27C040Q, TI 27C040, W27C040)
27C080      = 1048576 = 1024k = 1MB  (ATMEL AT27C080, F-DIL-32, 1M x 8)
27C100      =  131072 =  128k        (AM27C100, 27C100A)
27C101      =  131072 =  128k        (M5M27C101K, HM27C101AG)
27C128      =   16384 =   16k
27C160      = 2097152 = 2048k = 2MB  (M27C160, ST 27C160, 16Mbit/16 bit, DIP42)
27C201      =  262144 =  256k
27C202      =  262144 =  256k
27C210      =  131072 =  128k
27C220      =  262144 =  256k
27C240      =  524288 =  512k
27C256      =   32768 =   32k        (AM27C256, GI27C256, M27C256, MBM27C256A, NEC 27C256AC, NMC27C256Q, ST27C256, S27C256, 27C256B, DIP28)
27C301      =  131072 =  128k        (HN27C301P)
27C322      = 4194304 = 4096k = 4MB  (32MB DIP42, M27C322) (DemonFront)
27C400      =  524288 =  512k
27C402      =  524288 =  512k
27C512      =   65536 =   64k        (AM27C512, MBM27C512, NEC D27C512C, ST M27C512, TMS27C512, 27C512P, DIP28, F-DIL-28)
27C642      =    8192 =    8k        (Atmel AT27HC642R) (Armchmp2)
27C800      = 1048576 = 1024k = 1MB
27C801      = 1048576 = 1024k = 1MB  (ST M27C801, ST27C801, SGS 27C801; DIP32)
27C802      = 1048576 = 1024k = 1MB  (MSM27C802CZ)
27C0248     =  262144 =  256k        (Gticlub)
27C1000     =  131072 =  128k        (M271000ZB, D27C1000D, DIP32)
27C1001     =  131072 =  128k        (271001, DIP32, F-DIL-32) (Poundfor)
27C1024     =  131072 =  128k        (F-DIL-40, DIP40)
27C1602     = 2097152 = 2048k = 2MB  (MSM271602CZ, MSM27C1602CZ, DIP42) (Gnbarich)
27C1652     = 2097152 = 2048k = 2MB  (MSM27C1652CZ) (Gnbarich)
27C2000     =  262144 =  256k        (Macronix MX27C2000, 2MBit, DIP32 EPROM)
27C2001     =  262144 =  256k        (ST M27C2001, NEC 27C2001, F-DIL-32)
27C2048     =  262144 =  256k
27C2100     =  262144 =  256k        (mx27c2100 - Nitrobal)
27C3202     = 4194304 = 4096k = 4MB  (32MB TSOP48 Type II OTP Mask) (MartialMaster)
27C3252     = 4194304 = 4096k = 4MB  (MR27C3252CZ, 32MBit, SOP44) (NamcoSystem12)
27C4000     =  524288 =  512k        (Macronix MX27C4000, D27C4000D, DIP32)
27C4001     =  524288 =  512k        (ST M27C4001, SGS 27c4001, F-DIL-32)
27C4002     =  524288 =  512k        (ST-M27C4002, DIP40, F-DIL-40)
27C4096     =  524288 =  512k        (AM27C4096, D27C4096, 274096, Hitachi HN27C4096, 256k x 16, DIP40)
27C4100     =  524288 =  512k        (Macronix MX27C4100)
27C4200     =  524288 =  512k
27C8000     = 1048576 = 1024k = 1MB  (uPD27C8000, MX27C8000, 42 pin 8MBit Mask)
27C8001     = 1048576 = 1024k = 1MB




Other:

303         =    ?    =    ?         (IGSD0303, 256x16) (Drgnwrld)
406         =    1024 =    1k        (NEC B406, 1024 x 4)
426         =    1024 =    1k        (NEC uPB426, B426)
2864        =    8192 =    8k        (Jedi)
3622        =            512 bytes   (512 x 4) (Ace)
3758        =    1024 =    1k        (MSM3758AS) (Headon2)
4716        =    2048 =    2k        (AM4716) (Bradley, Tugboat)
4764        =    8192 =    8k        (Sstrngr2)
5317        =            256 bytes   (PR5317.76) (Brain)
6253        =    ?    =    ?         (MSM6253RS, OKI M6253, OKI 6253, General Purpose Mask Programmable ROM, DIP18) (Sega-System24, SuperKanekoNovaSystem, Strkfgtr)
8148        =    1024 =    1k        (NEC R8148IY, 1024 x 4 SRAM) (Pengo)
8316        =    2048 =    2k        (8316E) (Orbit)
8422        =    2048 =    2k        (Fujitsu MB8422)
8423        =    2048 =    2k        (GI8423)
8437        =    8192 =    8k        (GI8437)
9016        =  131072 =  128k        (Fujitsu 9016, DIP28) (Ainferno)
9316        =    2048 =    2k        (GI9316B) (Boothill, Centiped)
23090       =  131072 =  128k        (Sharp LH23090) (Rallybik)
23128       =   16384 =   16k
23160       = 2097152 = 2048k = 2MB  (M5M23160, 16MBit, 42 pins mask)
23256       =   32768 =   32k
26512       =   65536 =   64k        (MX26C512APC) (Dreamwld, Moremorp)  
40986       =  131072 =  128k        (Pang)
58732       =    1024 =    1k        (M58732S) (Spacefev)
83400       = 2097152 = 2048k = 2MB  (MB83400)
83800       = 2097152 = 2048k = 2MB  (MB83800)
231011      =  131072 =  128k        (KM231011) (Chequered Flag)
231024      =  131072 =  128k        (RP231024D) (Ddragon2)
231600      = 2097152 = 2048k = 2MB  (23C1600) (Powerins)
231610      = 2097152 = 2048k = 2MB  (23C1610, MX23C1610T, SOP44, TSOP48) (Rdft)
232100      =    ?    =    ?         (23C2100) (Kouryu)
233210      = 4194304 = 4096k = 4MB  (GM23C32100A 32MBit DIP42, MX23C3210TC TSOP48)
234000      =  524288 =  512k        (MN234000, 23C4000, 4MBit Mask, 32 pins) (Bonzeadv)
234001      =  524288 =  512k        (NEC D23C4001)
234100      =  524288 =  512k        (MX23C4100, SOP40, DIP40)
236410      = 8388608 = 8192k = 8MB  (MX23C6410, 64MBit MaskROM, SOP44)
238000      = 1048576 = 1024k = 1MB  (MX23C8000, D23C8000SCZ, SOP32)
238001      = 1048576 = 1024k = 1MB  (NEC D23C8001, 23C8001E)
261600      = 2097152 = 2048k = 2MB  (MT26C1600)
275308      =   32768 =   32k        (AMIC 275308) (Hidnctch)
531000      =  131072 =  128k        (Toshiba TC531000P - 28 pin and pin 22 is the extra address pin)
531024      =  131072 =  128k        (TC531024, DIP24)
533202      =  262144 =  256k        (M533202, SOP44 mask)
534000      =  524288 =  512k        (TC534000AP, TC534000P, MB534000)
534002      =  524288 =  512k        (M534002C-13, SOP40 mask, BIOS rom) (Rvschool, Sfex, Ts2)
538200      = 1048576 = 1024k = 1MB  (TC538200AP)
541000      =  131072 =  128k        (TC541000)
541001      =  131072 =  128k        (TC541001)
571000      =  131072 =  128k        (TC571000)
571001      =  131072 =  128k        (Toshiba TC571001D, 57C1001, 571001D) (Midres)
571025      =  131072 =  128k        (TC57H1025AD)
574000      =  524288 =  512k        (TC574000AD, TC574000D) (Topshoot, NintendoSuperSystem)
574200      =  524288 =  512k        (TC574200, 57C4200 256k X 16, DIP40)
578200      = 1048576 = 1024k = 1MB  (57C8200)
831000      =  131072 =  128k        (MB831000, DIP28)
831600      = 2097152 = 2048k = 2MB  (MB831600)
831620      = 2097152 = 2048k = 2MB  (Arabfgt, Brival, Dbz2)
832000      =  131072 =  128k        (MB832000) (Gollygho)
832001      =  131072 =  128k        (MB832001, DIP32)
834000      =  524288 =  512k        (MB834000, DIP32)
834100      =  524288 =  512k        (MB834100)
838000      = 1048576 = 1024k = 1MB  (MB838000)
838200      = 1048576 = 1024k = 1MB  (MB838200B, DIP42)
2316000     = 2097152 = 2048k = 2MB  (KM23C16000, KM2316000, uPD23C16000GX, 2316000, 16MBit SOP44 mask)
2332000     = 4194304 = 4096k = 4MB  (KM23C32000, uPD23C32000GX)
2332020     = 4194304 = 4096k = 4MB  (uPD23C32020A, uPD23C32020CZ, 32MBit, DIP42 mask) (Sfex2)
2364000     = 8388608 = 8192k = 8MB  (Sharp 23C64000F, surface mounted)
5316200     = 2097152 = 2048k = 2MB  (TC5316200CP)
5332204     = 4194304 = 4096k = 4MB  (TC5332204AP) (Kof99, Vsnetscr)
5716200     = 2097152 = 2048k = 2MB  (TC5716200)
5716200     = 2097152 = 2048k = 2MB  (57C16200) (Donpatchi)
8316200     = 2097152 = 2048k = 2MB  (MB8316200B, SOP44, DIP42)



   8 MEG    =  8 MegaBit = 1MBbytes
  16 MEG    = 16 MegaBit = 2MB
  32 MEG    = 32 MegaBit = 4MB

  1M Mask   =   131072 =   128k            (DIP28) (Champbwl)
  2M Mask   =   262144 =   256k            (DIP32) (Champbwl)
  4M Mask   =   524288 =   512k            (DIP42) (Rezon)
  8M Mask   =  1048576 =  1024k = 1MB
 16M Mask   =  2097152 =  2048k = 2MB
 32M Mask   =  4194304 =  4096k = 4MB      (DIP42 or SOP44) (Drgw2)
 64M Mask   =  8388608 =  8192k = 8MB
128M Mask   = 16777216 = 16384k =16MB

2megcust    =   262144 =   256k             (Fixeight)
COPX-D1     =   524288 =   512k             (DIP40) (Cupsoc)
COPX-D2     =   524288 =   512k             (RISE CORP  4M MASK, DIP40) (Godzilla, Denjinmk), 2M-16bit ? (Sdgndmrb)
F16MB       =  2097152 =  2048k = 2MB       (Sftm)
623B01      =  2097152 =  2048k = 2MB       (16MBit MASKROM) (Heatof11, Polystar)
23V32000    =  4194304 =  4096k = 4MB       (32MBit MASKROM, DIP42, IGSD0301 UM23V32000) (Drgnwrld)
NUS-ZHAJ    =  8388608 =  8192k = 8MB       (64Mbit MASKROM), DIP28) (11beat)


Hitachi ROM's:

462532      =    4096 =    4k        (HN462532G = 2532)
462708      =    1024 =    1k        (HN462708 = 2708)
462716      =    2048 =    2k        (HN462716G = 2716) (HM462716G) (Sbugger)
462732      =    4096 =    4k        (HN462732G = 2732) (HN422732G) (Promutrv)
62302       =  262144 =  256k        (HN62302)
62318       = 1048576 = 1024k = 1MB  (HN62318)
62344       =  524288 =  512k        (HN62344BPC84)
62404       =  524288 =  512k        (HN62404, QFP44)
62412       =  262144 =  256k        (Punkshot)
62414       =  524288 =  512k        (HN62414)
62415       =  524288 =  512k        (HN62415P)
62418       = 1048576 = 1024k = 1MB  (HN62418)
62428       = 1048576 = 1024k = 1MB  (HN62428P)
62434       =  524288 =  512k        (HN62434)
62444       =  524288 =  512k        (HN62444) (Racin' Force)
624017      = 2097152 = 2048k = 2MB  (HN624017P)
624116      = 2097152 = 2048k = 2MB  (HN624116, DIP42)
624316      = 2097152 = 2048k = 2MB  (HN624316, SOP44 16M mask)




Sharp ROM's:

LH5762      =    8192 =    8k          (labelled 04544191) (Finalap3, Gollygho)
LH5763      =    8192 =    8k          (Sharp LH5763J)
LH530800    =  131072 =  128k          (LH530800A, SOP32)
LH53100     =  131072 =  128k
LH532       =  262144 =  256k
LH53200     =  262144 =  256k
LH532048    =  262144 =  256k          (LH532048, SOP40)
LH532100    =  262144 =  256k          (DIP32)
LH532200    =  262144 =  256k          (LH532200)
LH532500    =  262144 =  256k
LH53400     =  524288 =  512k
LH534100    =  524288 =  512k          (Sharp LH534100, DIP32)
LH534200    =  524288 =  512k          (LH534200)
LH534500    =  524288 =  512k          (LH534500, 256k x 16, DIP40)
LH537019    = 2097152 = 2048k = 2MB    (SOP44, 16M mask, Bangball - YMF278B wave data ROM)
LH53800     = 1048576 = 1024k = 1MB    (LH53805N, LH53806N, LH53808N, LH53809N...) (F1gp)
LH538000    = 1048576 = 1024k = 1MB    (LH538100, SOP32)
LH538100    = 1048576 = 1024k = 1MB    (LH538100, DIP/SOP32)
LH538500    = 1048576 = 1024k = 1MB    (LH538500)
LH5364000   = 8388608 = 8192k = 8MB    (Sfex2)

LH532A      =  262144 =  256k          (Pipedrm - roms a29 and a30)
LH532G      =  262144 =  256k          (F1gp)
LH532J      =  262144 =  256k          (Quiz18k, Welltris)
LH534G      =  524288 =  512k          (Quiz18k, F1gp2)
LH534J      =  524288 =  512k          (Pipedrm, Welltris)
LH537F      = 2097152 = 2048k = 2MB    (F1gp2)
LH537K      = 2097152 = 2048k = 2MB    (Gogomile)
LH5370H     = 2097152 = 2048k = 2MB    (Gogomile)
LH538N      = 1048576 = 1024k = 1MB    (Gogomile)
LH538P      = 1048576 = 1024k = 1MB    (F1gp)





R2.    PROM (Programmable ROM)
------------------------------

NOTES: Color Prom (Red/Green/Blue), Alpha Numerics PROM, Sync prom, Sprite Prom, Decoder prom...
READER: Needham EMP-20 PROM reader



AM (27Sxx) - Bi-polar PROMs:

27S08 = AM27S08                   =   32 bytes
27S13 = AM27S13                   =  512 bytes  (Quiz211)
27S18 = AM27S18                   =   32 bytes
27S19 = AM27S19, AM27S19DC        =  256 bytes
27S21 = AM27S21, AM27S21APC       =  256 bytes  ( 256 x 4)
27S29 = AM27S29APC                =  512 bytes
27S33 = AM27S33PC                 = 1024 bytes  (1024 x 4)


Fujitsu PROMs:

7051 = MB7051                     =   32 bytes  (  32 x 8)
7052 = MB7052                     =  256 bytes  ( 256 x 4)
7054 = MB7054                     = 1024 bytes  (1024 x 8)
7056 = MB7056                     =   32 bytes  (  32 x 8)
7112 = MB7112                     =   32 bytes  (  32 x 8)
7114 = MB7114E, MB7114H, MB7114L  =  256 bytes  ( 256 x 4)
7116 = MB7116, MB7116H            =  512 bytes  ( 512 x 4) (Chinagat, SchmeizerRobo)
7118 = MB7118, MB7118E            =  256 bytes  ( 256 x 8) (Luckywld, ThunderCeptor2)
7122 = MB7122E, MB7122H, MB7122Y  = 1024 bytes  (1024 x 4, DIL18) (Aso, Csilver, Wizdfire, Robocop)
7124 = MB7124E, MB7124H           =  512 bytes  ( 512 x 8)
7128 = MB7128E, MB7122H           = 2048 bytes  (2048 x 4)
7132 = MB7132, MB7132E            = 1024 bytes  (1024 x 8)
7134 = MB7134, MB7134E            =     ?                  (Victroad)
7138 = MB7138                     = 2048 bytes  (2048 x 8)

8516 = MB8516                     = 2048 bytes  (2048 x 8) (Cosmica)
8518 = MB8518                     = 1024 bytes  (1024 x 8) (Rotaryf)
8532 = MB8532                     = 4096 bytes  (4096 x 8) (Gomoku, Ckong)



Harris PROMs:

7602 = M3-7602-5                           =    ?                   (Dwarfd)
7603 = Harris 7603, M3-7603                =   32 bytes  (  32 x 8)
7609                                       = 1024 bytes  (1024 x 8) (Gunfight)
7611 = Harris 7611, Harris M3-7611-5       =  256 bytes  ( 256 x 4)
7621 = 7621                                =  512 bytes             (Arkanoid)
7641 = Harris 7641, M3-7641-5-7802         =  512 bytes  ( 512 x 8) (Circus, Sinistar)
7643 = Harris MI-7643A-5                   = 1024 bytes  (1024 x 4)
7649 = Harris M3-7649A-5                   =    ?                   (Mysticm)



Intersil PROMs:

5600 = IM5600, Intersil 5600      =   32 bytes
5610 = IM5610, IM5610CPE          =   32 bytes  (32 x 8, bipolar)
5623 = IM5623, IM5623CPE          =  256 bytes  (Rallyx)



MMI (63sxxx) PROMs:

6301   = MMI6301                  =  256 bytes  (256 x 4, 16-pin)
6306        ?                          ?                            (Arkanoid, Shootgal)
6330   = MMI6330-1J               =   32 bytes                      (Cosmic Alien)
6331   = MMI6331-1J, 6331-1N      =   32 bytes  (32 x 8, Bi-polar)  (MrKourgar)
6336   =    ?                     =   32 bytes                      (N-Sub, Nmouse)
6349   = MMI6349                  =  512 bytes                      (Airattck, Quiz211,Travrusa)
6350   = MMI6350                  =   32 bytes                      (Travusa)
6353   = MMI6353     Bi-polar     = 1024 bytes  (1024 x 4)          (Depthch, Fieldday)
63S080 = MMI63S080N               =   32 bytes                      (Halleys)
63S081 = MMI63S081N               =   32 bytes
63S140 = MMI63S140N               =  256 bytes                      (Imolagp)
63S141 = MMI63S141N  Bi-polar     =  256 bytes  (256 x 4, DIP16)    (Tokio, Avengers, Mainevt, Kikikai = 63S141AN)
63S281 = MMI63S281N               =  256 bytes  (256 x 8)           (Darkmist, Panic Road, AirRaid, SOURCE: Mustache = 4096 bytes !? )
63S441 = NMI63S441N               = 1024 bytes



Signetics (82SXXX) PROMs:

82S23  =   32 bytes  (N82S23)
82S29  =  256 bytes  (N82S29N, 256 x 4  bipolar PROM)
82S100 =  256 bytes  (256 x 8) (Catnmous, Laserbat) - NOTES: In MAME is the 82s100.13m from Catnmous a 245 bytes PLD)
82S115 =  512 bytes  (512 x 8)
82S123 =   32 bytes  (N82S123AN, N82S123N,  32 x 8  bipolar PROM)
82S126 =  256 bytes  (256 x 4)
82S129 =  256 bytes  (N82S129AN, 256 x 4)
82S130 =  512 bytes  (512 x 4) (Quasar, Galaxia)
82S131 =  512 bytes  (SN82S131N, 512 x 4)
82S135 =  256 bytes  (N82S135, 82S135N, 256 x 8)
82S137 = 1024 bytes  (N82S137N, 1024 x 4  bipolar PROM)
82S141 =  512 bytes  (512 x 8)
82S147 =  512 bytes  (SN82S147N, Philips N82S147AN, 512 x 8  bipolar PROM, DIP20)
82S153 = 1024 bytes  (1024 x 4)
82S158 = 2048 bytes  (2048 x 8) (Arkanoid)
82S181 = 1024 bytes  (1024 x 8)
82S185 = 2048 bytes  (N82S185, 2048 x 4)
82S191 = 2048 bytes  (82S191N, 2048 x 8)




Texas Instruments PROMs:

74S188 =   32 bytes     (SN74S188N, DM74S188A, 32 x 8, DIP16) (Ad2083, Sprint1)
74S287 =  256 bytes     (DM74S287AN, DM74S287N, 256 x 4, DIP 16, PLCC20) (Soccer, Sprint1, Skyraid)
74S288 =   32 bytes     (SN74S288N, DM74S288N, 32 x 8, bipolar PROM, DIP16) (Spaceg)
74S471 =  256 bytes     (SN74S471N) (Astrof)
74S472 =  512 bytes     (512 x 8, DIP20) (Guardian)
74S474 =  512 bytes     (512 x 8, DIP24) (Sidetrac)
74S476 = 1024 bytes     (1024 x 4) (Dribling, Superbug)
74S516 =  512 bytes     (SN74S516, 512 x 8) (Tx1)
74S571 =  512 bytes     (512 x 4, PLCC20) (Dodgem, Sprint1)
74S572 = 1024 bytes     (1024 x 4, DIP18) (Vangrd2)


Texas Instruments (TBPxxSxx) PROMs:

TBP18S030 =   32 bytes     (TBP18S030N, 256-bit 32 x 8)
TBP21S41  = 1024 bytes
TBP21S42  =  512 bytes     (Pettanp)
TBP24S10  =  256 bytes     (TBP24S10N, 256x4)
TBP24S41                   (Atari Soccer, Turbo)
TBP24S030 =  256 bytes
TBP28S42  =  512 bytes     (Pettanp, TX1)
TBP28S46  =  512 bytes     (TBP28S46N, Bking)
TBP28L22  =  256 bytes     (TBP28L22N, 256 x 8, Bi-polar)
TBP42S10  =  256 bytes



Others PROMs:

93427                    =  256 bytes    (93427PC) (Brdrline, Centiped)
93448                    =  512 bytes    (TESLA 93448, 93448PC-F7809, MBH93448C) (512 x 8) (Circus)
93451                    = 1024 bytes    (Dodgem)
93453                    = 1024 bytes    (Depthch)
93511                    = 2048 bytes    (93Z511DC) (Portrait)
EB16.22                  =  256 bytes    (Data Prom) (Bioatack, Sfposeid, Timetunl)
S68E08                   =  512 bytes    (Denjinmk, Godzilla, Sdgndmrb)
Cypress CY7C291          =  256 bytes    (Bi-polar) (Mspacman)
Cypress   7C292A         = 2048 bytes    (2048 x 8)
Cypress   7C264          = 8192 bytes    (8192 x 8)
NS 47S287                = 2048 bytes



R2.1   EAROM

- 0.27               : Added generic EAROM routines for the Atari Vector games, they are in src/machine/atari.c and src/machine/atari.h
- NOTES: EA ROM is an Erasable Reprogrammable rom to save the top 3 high scores and other things.
- GAMES: Atari - Centipede (1980), Tempest (1980), Asteroid Deluxe(1980), Black Widow (1982), Cloud9 (1983)



R2.2   EEPROM

- 0.84               : Added machine\at28c16.c.
- 0.82u2             : Tomasz Slanina changed the eeprom_interface_93C46 (please check games using this to make sure non broke).
- 0.81u7             : Ville Linde added 93C46 eeprom to RF2 single and RF2 2K. It's not hooked up though.
- 20th June      2001: Luca Elia added generic support for the 93C46 which is the most commonly used EEPROM.
- 19th January   2001: David Haywood updated the Cave driver, adding default EEPROM support so that the games are pre-set to factory default settings.
- SOURCE: machine\eeprom.c + emu\machine\at28c16.c
- PCB: 93C46 = 128 Bytes EEPROM DIP8 (Polystar, Glpracr), 93C46A (Fromanc2), AT28C16 (Maxforce)


       CMOS serial EEPROMs (DIP or SIO - 8)

       24C01        128 bytes x 8   Amtel 24C01A serial EEPROM (DIP8)
       24C02        256 bytes x 8
       24C04        512 bytes x 8   24c04a (Hotblock)
       24C08       1024 bytes x 8
       24C16       2048 bytes x 8
       24C32       4096 bytes x 8
       24C64       8192 bytes x 8
       24C128     16384 bytes x 8   Toshiba TMM24128AP
       24C256     32768 bytes x 8   Toshiba TMM24256AP
       24C512     65536 bytes x 8   Toshiba TMM24512P (Robocop, Sqix)

       28C16       2048 bytes x 8   SOP24 / DIP24; Atmel AT28C16A, BR28C16A, 28C16A-15/P, CSI CAT28C16, DIP24,    (Machbrkr, Glpracr, Badlands, Outfxies, Stonebal)
       28C64       8192 bytes x 8   AT28C64 (Propcycl, Alpine Racer)


       Microwire (CMOS serial EEPROMs  DIP8 or SIO8)

       93C45        128 bytes x 8 /  64 x 16      AKM93C45, equivalent to 93C46 (Fixeight, Nslasher, Avengrgs)
       93C46        128 bytes x 8 /  64 x 16      93LC46B (Gauntleg), SGS Thomson ST93C46CB1 (Sailormn, Agallet), NMC 9346N (Lordrun), 93LC46BX (1K Low-power 64 x 16-bit organization serial EEPROM) (Deerhunt)  NOTE: In Hvysmsh the 93C46 chip has identical halves and fixed bits.
       93C56        256 bytes x 8 / 128 x 16      93LC56 (Loderndf, Gunbird2, Daraku, Hotgmck) SOURCE: drivers\psikyo4.c
       93C66        512 bytes x 8 / 256 x 16      AMTEL AT93C66, PSOP8 (Bbakraid, Policetr, Sshooter)
       93C76               1k x 8 / 512 x 16
       93C86               2k x 8 /  1k x 16
       93C96                                      93CF96-2 (Komani-GV)



       Other      Type (Game)

       16911      OKI M16911                                       (Gaiapols)
       2205       ER2205, ER-2205                                  (Centiped, Qwakprot)
       2914       Seiko S2914 EEPROM, DIP8                         (Gdfs)
       5032       Altera EPM5032DC, EPM5032                        (Tantr, Zunkyou, Tfreac, Columns, Mahmajn, Mahmajn2)
       58C65      HN58C65                                          (Luckywld, Gollygho)
       5911       ER5911                                           (Moo, Mystwarr)
       68234      Motorola 68234 EPROM                             (Frontlin)
       80011      Mitsubishi M6M80011, 64 x 16 Serial EEPROM, DIP8 (NintendoSuperSystem)




R2.21  BIOS EEPROM

       27L1000         Macronix MX27L1000QC-12 (128k x 8 EEPROM, PLCC32)       (Crysking)
       SST29EE020      2 Megabyte, PLCC32, surface mounted,  Phoenix BIOS      (A51site4)




2.3   EPROM Emulator

-  8th November  2007: Charles MacDonald - 16-bit EPROM Emulator: I've been interested in doing some research on the Jaleco Mega System 32 hardware, which is emulated in MAME but has a few remaining issues. Guru generously donated a "Desert War" board for testing, and now I had to figure out the best way to run my own programs on it. Being a 32-bit system, the two 8-bit EPROM emulators that were developed for the Gaelco "Master Boy" dumping project wouldn't be enough as Desert War uses four 8-bit ROMs. I decided to make a new EPROM emulator based around the IDT7025, a 16K dual-port RAM. What makes this device useful is that it allows control of the individual byte lanes for both ports. This allows the RAM to be interfaced with CPUs of varying bus widths and endianness without any glue logic. On the PCB the left port connects to a FT2232 chip in Host Bus Emulation mode (an 8051-alike bus) and the right port is buffered and goes to headers for DIP cables to plug into two 8-bit ROM sockets of the target board. The real challenge with this project was assembly; the IDT7025 chips I had came in an 84-pin PLCC package. I used a Mill-Max SMT socket to attach the RAM to the board, but this meant soldering the socket to the board using a regular iron. To simplify this process, I increased the pad size of the LCC footprint inward so there was more surface area leading up to the pin pad. This greatly simplified tacking the socket in place, kept solder from bridging with adjacent pins, and made soldering all 84 pins in place a snap. I've tested the first one on a Sega Model 1 board and it works as expected, I was able to re-use the 8-bit ROM emulator code to control it so the software is done. I'll make another and that should be all that's needed to start running test programs on the Jaleco Mega System 32 hardware. I'll also put up the project files (schematic, source code, and instructions) for it soon.
- 21st September 2007: Charles MacDonald - EPROM emulator update: I've added a memory test feature to check if the RAM being used is OK. Oddly enough the Model 1 hardware draws enough power that my DS1230 NVRAM refuses to operate. Thought it was bad, but it works fine in other systems. I switched it out with a new Hitachi HM62256LP SRAM and everything is working again.





R2.4   Flash Memory

R2.41  Flash ROM

- 0.112u3            : smf added X76F100 emulation and ZS01 emulation (HLE of System 573 PIC).
- 0.109u5            : smf improved flash emulation and added support for Fujitsu 29F016A flash chips. Switches Konami games over to new flash chips.
- 0.104u6            : Ville Linde added the missing commands and proper maker/device IDS to the flash memory handlers for Fujitsu MBM29F016A, used by Konami Firebeat hardware (not yet emulated).
- 0.97u3             : Nathan Woods added sanity checking and changed a printf() to logerror() to intelfsh.c.
- 0.95u3             : smf increased FLASH_CHIPS_MAX in machine\intelfsh.h and merged 8 & 16 bit Intel Flash NVRAM handler & passes the chip number as a parameter.
- 0.95u1             : Flash updates [smf]. Implemented state saving for Flash chips, fixed block erase on 16bit Flash chips and increased maximum number of Flash chips.
- 0.94u1             : Intel Flash improvements [smf].
- 0.93u1             : Flash ROM support update [R. Belmont]: Added support for arbitrary manufacturer and chip IDs instead of hardcoding. Added support for the extended chip ID protocol favored by AMD and Fujitsu. Bumped limit up to 8 chips.
- 0.86u2             : R. Belmont added word-wide flash ROM support (specifically IDs itself as the Sharp LH28F400 found on Konami "Beat the Champ" PCBs).
- 0.80u3             : R. Belmont support Intel Flash ROM emulation.
-  7th January   2004: R. Belmont - Figured out how Konami's glue chip that talks to 4 Intel Flash ROMs on Simpsons Bowling works, with some cool results...
- SOURCE: emu\machine\intelfsh.c


       28F200   =    262144 =   256k           Intel Flash        PA28F200BX              2MBit                    (Dunkmnia, NamcoSystem11)
       28F400   =    524288 =   512k           Intel Flash        E28F400                 4M                       (GNET-System, Capcom ZN2), Sharp LH28F400 (btchamp)
       28F008   =   1048576 =  1024k =  1MB    Intel Flash        E28F008SA     TSOP40    8M    Sharp LH28F008     (Propcycl, Tekken2, Rfjet)
       28F016   =   2097152 =  2048k =  2MB    Intel Flash        E28F016S5     TSOP40   16M                       (PacaPacaPassionSpecial)
       28F032   =   4194304 =  4096k =  4MB    Intel Flash        E28E320J5     TSOP56   32M    DA28F320J5, E28F0320         (Soulclbr, Xfiles)
       28F640   =   8388608 =  8192k =  8MB    Intel Flash        DA28F640J5    SSOP56   64M                       (Mrdrilr2)
       28F128   = 167772126 = 16384k = 16MB    Intel Flash        E28F128J3A    TSOP56  128M                       (Crysking)

       29F040   =    524288 =  512k                                                                                (Bballoon)
       29F400   =    524288 =  512k            Fujitsu Flash      MBM29F400B    SOP44     4M    29F400TA           (MrDriller, Tekkentt)
       29F550   =    524288 =  512k  ?         ?                  TM29F550ZX               ?                       (Go2000)
       29F8100  =   1048576 = 1024k  =  1MB    Macronix                         SOP44     8M                       (Jumppop)
       29F016   =   2097152 = 2048k  =  2MB    Fujitsu Flash      MBM29F016     TSOP48   16M    29F016A            (MrDriller, Tekkentt, KonamiSystem 573)
       29F1610  =   2097152 = 2048k  =  2MB    Macronix           MX29F1610MC   SOP44    16M    29F1610ML          (Silkroad, Vshoot), MX29F1610ML (Mchampdx), MX 29F1610 (Mosaicf2, Vasara2)

       29W32000 =   4194304 =  4096k =  4MB    Samsung NAND Flash KM29W32000AT  TSOP44   32M    3.3V Serial EEPROM, KM29W32000AT, KM29N32000TS (SeeSeeFindOut)
       8F1600   =         ? =     ?k =  ?MB    Hitachi            HN98F1600T10  TSOP56    ?M    (CPS2)
       9F2808   =  16777216 = 16384k = 16MB    Samsung NAND Flash K9F2808U0B    TSOP48  128M                       (NamcoSystem10)
       9F5608   =  33554432 = 32768k = 32MB    Samsung NAND Flash K9F5608U0B    TSOP48  256M                       (Bballoon)
       X76F100  =



       X76F100
       - 0.112u3: Added machine\x76f100.c. smf added X76F100 emulation and ZS01 emulation (HLE of System 573 PIC).
       NOTES: The X76F100 is a Password Access Security Supervisor, containing one 896-bit Secure SerialFlash array. Access to the memory array can be controlled by two 64-bit passwords. These passwords protect read and write operations of the memory array.
       SOURCE: emu\machine\x76f100.c

       ZS01
       - 0.112u3: Added machine\zs01.c. smf added X76F100 emulation and ZS01 emulation (HLE of System 573 PIC).
       SOURCE: machine\zs01.c




R2.42  Flash Memory + Switching Regulator

       MAX232         Maxim MAX232CPE Dual EIA-232 Driver/Receiver, DIP16     (CPS-2, 11beat, Mtetrisc)
       MAX232         Maxim MAX232CPE Multichannel RS-232 Driver/Receiver     (Ppcar)
       MAX705                                                                 (Kinst, Kinst2)
       MAX734         Flash Memory Programming Supply Switching Regulator (+12V 120mA), SOIC8     (MrDriller2, Gp500)


       MB3759         Fujitsu MB3759 Switching Regulator Controller, DIP16 (Model1)


       X76F041
       - 0.109u4: Added machine\x76f041.c.
       NOTES: The X76F041 is a Password Access Security Supervisor, containing four 128 x 8 bit SecureFlash arrays. Access can be controlled by three 64-bit programmable passwords, one for read operations, one for write operations and one for device configuration. The data sheet has an incorrect diagrams for sequential read with password, there shouldn't be an extra address after the 0xc0 command.
       SOURCE: emu\machine\x76f041.c
       GAMES: Konami System 573 games



R3.    RAM
----------

 256   = Hitachi S256KLP (Umanclub)
 314   = TMM314 (Invadpt2, Monsterz)
 411   = 411A (Wldarrow), uPD411 (Unkmeyco)
 416   = TMM416, NEC D416 (Jollyjgr, Kangaroo)
1023   = TMS1023 (Idsoccer)
2009   = Toshiba TMM2009 (Ppking)
2015   = Toshiba TMM2015 (2k x 8, DIP24)
2016   = Toshiba TMM2016AP, TMM2016BP, SRM2016C15, S2016C, 2016 (2k x 8 SRAM, DIP24) (Tehkanwc, Truxton, Turbosub, Bronx)
2018   = Toshiba TMM2018D, Motorola MCM2018AN45 (2k x 8 SRAM, DIP24)
2063   = Toshiba TMM2063AP (8k x 8 SRAM, DIP28)
2064   = Toshiba TMM2064, SRM2064C (8k)
2088     (Groundfx)
2101   = (256 x 4 SRAM)
2102   = (1k x 8)
2111     (256 bytes x 4 SRAM) (Ipminvad, Headoni)
2114   = M5L2114, TMS2114, MM2114N, NEC uPD2114LC, Hitachi HM572114P, 2114UCE, 2114 (1k x 4 SRAM = 512 bytes, DIP18) (Calorie, Astrof, Monzagp, Starspnr)
2115     (Rockclim)
2125   = D2125A (Bcruzm12, Carjmbre, Cclimber, Monsterz)
2128   = OKI MSM2128, 2128SL (16kbit = 2k x 8)
2144     (Blasto)
2147     (Noboranb)
2148   = MBM2148L-55 (1k x 4 SRAM, DIP18)
2364   = TMM2364 (Turbo)
2416   = Winbond W2416K  (Karianx, Paranoia, Wbbc97)
2700   = 27ls00 (256 x 1 SRAM, with 3-state outputs, 55ns access time) (Botanic - sprite buffer ram)
2701   = AM2701-50JC (256 x 1 RAM, open collector outputs) (Botss, F15se)
3106     (256 x 1) (Ace)
3517   = SANYO LC3517A
3564   = SANYO LC3564SM-85 (SMD) (Jchan)
3664   = SANYO LC3664 (8k x 8 SRAM, SOIC28)
4015   = MK4015N (Carnival)
4016   = NEC D4016, TMS4016 (Lastfero, Lastfort, CliffHanger)
4027   = MOSTEK MK4027-4, ITT 4027 4D, MCM4027 (4k RAM, DIP16) (Spaceg, Astrof, Shuttlei)
4044   = Mitsubishi M5T4044P (Astinvad)
4045   = TMS4045 (RAM, DIP18) (Shuttlei, Spaceg)
4060   = TMS4060 (Sbowling)
4069     (2k x 8) (Carnival, Springer)
4116     (Beezer, Sharkatt)
4164     (Idsoccer)
4334   = 4334 (Qix), HM4334P (SRAM) (Unknown Sega game)
4416   = TMS4416 (16k x 4 DRAM) (Hcrash, Dogfgt)
4461   = TMS4461
4517   = MCM4517 (Gt102b)
4801   = MN4801AN-3IRL (Conquer)
5101   = 5101 (Carjmbre, Malzak, Skybase, Statriv2, Trivquiz), SCM5101E, D5101LC (SRAM) (Cclimber)
5116   = LH5116D, P5116, (2k x 8) (Brapboys, Heatbrl)
5160   = Sharp LH5160D
5164   = Sharp LH5164D (8k x 8 RAM) (Tdragon2, Tharrier, Nss_con3) 
5168   = Sharp LH5168D, LH5168N (8k x 8 SRAM, SOP28)
5264     (8k x 8 ?) (Robokid)
5268   = Sharp LH5268AN (8k x 8 SRAM, SOP28) (MK3, Capcom ZN1/2)
5280     (Invaders)
5493   = ISSI 5493R45-001 (128k x 8 SRAM, SOJ32)
5497   = Sharp LH5497D (Jchan)
5501   = Toshiba TC5501P (256 x 4 SRAM, DIP22)
5563   = TC5563 (Drgpunch, Mmpanic)
5565   = Toshiba TC5565 (8k x 8 SRAM, DIP28)
5588   = Toshiba TC5588P (8k x 8 SRAM, DIP28)
6064     (Omegaf  ram ?)
6114   = UM6114 (1k x 4 SRAM) (Ninjemak)
6116   = Hitachi HM6116LP, HY6116AP, Vitalec V61C16S45L, 61C16 (2k x 8 RAM, DIP24) (Wwfwfest)
6117   = HM6117P (Gs4002, Gt102b)
6148   = Hitachi HM6148HP (1k x 4 SRAM, DIP18)
6164   = Unicorn Microelectronics UM6164DS-12, UM6164BK, 61C64 (8k x 8 SRAM, SOJ28) (Daitorid, Puzzli)
6166     (Psychic5 ram ? = 6116 (!))
6168   = LH6168, ISSI IS61C68 (Dblewing, CyberSled)
6206   = MCM6206 (32k x 8 SRAM, SOJ28)
6216   = BR6216B (2k x 8) (Fromanc2)
6262     (Cairblad)
6264   = MCM6264CP35, UT6264PC (Dunhuang), UT6264 (SOIC28), Hyundai HY6264P, 6264ALSP, CDM6264LE12, Mosel MS6264, Hitachi HM6264LP  (8k x 8 SRAM, DIP28), UM6264 (Funybubl)
6265   = BR6265BF
6514   = M3-6514 ram? (Dwarfd)
6516   = Mosel MS6516 (2k x 8) (Gtg, Stratab)
6810   = MC6810, MCM68A10P (128x8 SRAM) (Shooting Gallery, Victory)
7063   = MB7063
8114     (Espial)
8116     (FieldGoal, Progolf)
8148     (1k x 4 SRAM) (Grobda)
8216   = Mitsubishi M5L8216  (256 bytes x 1 SRAM, DIP16) (Amidar, Headoni, Spaceg), uPB8216 (Sbugger), MPB8216 (Monsterz), P8216
8264     (64k x 4 DRAM) (Buckrog)
8416   = MB8416
8421   = Fujitsu MB8421 (Dual Port SRAM, SDIP52) (Opwolf3, Model1)
8431   = Fujitsu MB8431 (RAM?, SDIP52) (Model1)
8464   = Fujitsu MB8464A (8k x 8 SRAM, SOP28, DIP28) (CPS2, SegaSystem32)
9114     (D-Day)
9122   = AM9122 (256 x 4 SRAM) (Turbosub, Bcruzm12)
18128  = TC18128CFWL (Bel)
18318    (Portrait)
24258  = W24258S (SOP28)
25520  = SHARP LH25520 (Nslasher)
29128  = AM29128 (2k x 8) (Turbosub)
35256  = SANYO LC35256 (32k x 8 SRAM, SOP28)
41101  = D41101C-1 (Snowbros)
41256  = PDM41256SA20P (32k x 8 SRAM)
41264  = D41264
41464  = Toshiba TMM41464 (64k x 8) (Berlwall, Sparkz, Sega System24)
42101  = D42101C (DIP24)
43001  = NEC D43001GU (32k x 8 SRAM, Cbaj)
43256  = NEC D43256C, NEC 43256, uPD43256, D43256BGU (32k x 8 SRAM, DIP28) (Contcirc, Rfjet)
44001  = MT4C4001, 4C4001 (1M x 4 DRAM, SOJ28) (Kinst, Kinst2)
44251  = TMS44251 (28 pin ZIP) (Stonebal)
50464  = HM50464 (Pbillian)
511664 = M511664, TC511664
51257  = M51257 (256k SRAM)
51821  = TC51821 (Cyclwarr)
51832  = TC51832AFL (32k x 8 SRAM, SOP28)
52250  = LH52250AN (32k x 8 SRAM, SOP28)
52256  = LH52256ALSP, LH52256CN (32k x 8 SRAM)
52258  = Sharp LH52258 (32k x 8 SRAM)
53461  = HM53461, HM53461ZP (64k x4 Multiport CMOS VRAM) (Galsnew, Radm, Titlef)
53462    (Drgpunch)
53464  = V53C464AP80 (Pitbossm)
54260  = MCM54260 (SOJ40) (Stonebal)
55257  = Toshiba TC55257CFL, TC55257DFL, TC55257N (32k x 8 SRAM, TSOP28)
55328  = TC55V328AJ, TC55328AJ (SSOP28)
57725  = MB57725
58275    (Kingfut)
58725  = M58725P, MB58725
58754  = M58754 (Astinvad)
61256  = Unicorn Microelectronics UM61256FK, UM61256FS, UM61256AK, IS61C256AH, 61C256, Epson SRM2B61256 (32k x 8 SRAM, DIP28/SOJ28 Cache RAM)
61640  = 61C640 (Balcube)
62068  = MCM62068AEJ25 (SSOP28)
62256  = Hitachi HM62256ALSP, HM62256LFP, HM62256LP, HY62256A, Mosel 62256, UM62256D, UM62256E (32k x 8 SRAM, SOJ28/DIP28)
65738  = HM3-65738BK
64256  = (32k x 8) (Bubl2000)
65256  = Hitachi HM65256BLSP, 65256BLFP (surface-mounted, 32k x 8 SRAM, DIP28, SOP28)
65728  = HM3-65728BK (Sderby, Madmotor)
65756    (Aligator, Biomtoy)
65764  = HM65764, HM3-65764
70178  = UMC UM70C178 (Cheesech)
71024  = IDT71024
71124  = MB71124, IDT71V124 (128k x 8 SRAM, SOJ32) (Gp500)
71256  = IDT71256, DT71256, CAT71C256 (32k x 8 SRAM, SOIC/SOJ28) (B-RapBoys)
74201  = 74S201 (256-bit RAM) (Conquer, Hotshock, Mirax, Zigzag)
84256  = Fujitsu MB84256A, 84256 (32k x 8 SRAM, SOP28, DIP28)
93419  = (64 x 8+1 SRAM)  (Battlex, Changela, Taito SJ)   NOTES: Palette RAM chip 93419 (64 x 9 (nine!!!)): bits A0-used as the 8-th bit data input (d0-d7->normal, a0->d8), SRAM with open-collector outputs
93422  = AMD AM93422DC, 93L422DC (256 x 4 SRAM) (40love, Pturn, Turbosub, Ad2083)
93425  (Mrflea, Portrait)
241024 = W241024AI, W241024AK-15 (1Meg SRAM) (Sscope2)
341256 = NKK N341256SJ, N341256P, 34256 (32k x 8 SRAM, SOJ28) (Raiden2)
414260 = Panasonic MN414260SJ
424800 = NEC 424800 (CryptKiller)
431000 = NEC D431000AGW
511632 = TC511632FL
514252 = M514252A
514260 = Toshiba TC514260BJ, OKI M514260C, Hitachi HM514260AJ8, HM514260CJ7, HY514260 (256k x 16 DRAM, SOIC40, SOJ40)
514262 = M514262 (Ddenlovr)
514270 = HM514270CJ7 (Bel, Harley)
514400 = TC514400, Hatachi HM514400BS7 (1M x 4 DRAM) (Gdfs, Eaglshot)
514800 = TC514800 (Mayjisn2)
518128 = Toshiba TC518128 (Rfjet)
521002 = LH521002AK
524256 = TC524256BZ, TC524256Z (Lockload, Mjchuuka)
528126   (9ballsht, coolpool)
528128 = Vitelic V52C8128K70 (possibly 128k x8 DRAM, SOJ40) (9ballsht, Pairs)
528256 = Sharp LH528256, LH52B256D (Bloodwar, Desertwr, Speglsht)
528257 = TC528257 (Landgear, Speglsht)
524258 = Toshiba TC524258BZ, Vitelic V52C4258Z (256k x8 SRAM, ZIP28) (Ghosthunt, Tickee, Tutstomb)
528267 = Toshiba TC528267J (RapidFire)
534256 = Hyundai HY534256 (256K x 4, 1MBit DRAM, DIP20) (Sliver)
538254 = HM538254BJ (Bel)
538256 = V53C8256HP45 (256k x 8, Fast Page Mode CMOS DRAM) (Megat6)
544256 = Toshiba TC544256BZ (Cheesech)
544260 = TC544260 (Vcircle)
551001 = Toshiba TC551001BFL (128k x 8 SRAM, SOP32)
551664 = Toshiba TC551664J5, TC55V1664AJ (1MBit SRAM, 64k x 16, SOJ44)
611024 = ISSI IS61C1024 (128k x8 SRAM, SOJ32)
616416 = IS61C6416 (Legendoh)
621024 = IS62C1024 (Trophyh)
628032 = ST M628032 (32k x 8 SRAM, SOIC28)
628256 = LH628256 (256k x 8 SRAM, DIP28) (Gtmr2)
628512 = (512k x 8 SRAM)
658128 = Hitachi HM658128ADFP-10 (128k ? x 8 SRAM, SOP32) (CPS2 System) (16k x 8 SRAM, DIP32) (Model1)
658512 = Hitachi HM658512LP-8 (64k x 8 SRAM, DIP32) (Model1)
725608 = LG GLT725608 (SOIC28) (Gunbird/2)
2316162 = T2316162 (SOJ44) (Gunpey, Xfiles)
4116256 = ISSI IC41C16256 (256k x 16 DRAM, TSOP44) (Legendoh)
4216800 = ISSI IC42S16800 (4(2)M x 8(16) Bits x 4 Banks, 128MBit SDRAM)
4516161 = NEC uPD4516161ag5-A10 (1M x 16 SDRAM, TSOP)
5118160 = Toshiba TC5118160BJ (256k x 16 DRAM, SOJ42) (CPS3)
5216165 = Hitachi HM5216165 (1M x 16 SDRAM, TSOP48)
5316258 = V53C16258HK40 (256k x 16 RAM) (Blitz99)
5425632 = OKI 54V25632 (256k x 32 SGRAM, QFP100) (Gamshara)
81141622  (Gticlub)





Cypress RAM                  PCB note
------------------------------------------------------------------------------------------------------------
CY7C109         1M SRAM
CY7C128         2k x 8 SRAM                      CY7C128A, CY7128A
CY7C132         DIP48, RAM?                                                     (Luckywldm, Gollygho)
CY7C141         1k (Drivedge - dual ported shared RAM btw 68k and TMS)
CY7C182         8k x 9 SRAM, SOJ28
CY7C185         8k x 8 SRAM, SOP28, DIP28        CY7C185, CY7B185               (Gticlub, Model1)
CY7C188                                                                         (Bel)
CY7C195                                                                         (Gstriker, Vgoalsoc)
CY7C199         32k x 8 SRAM, SOIC28             CY7C1399                       (GP500, Gauntdl)
CY7C382                                          CY7C382-0JC                    (Honeydol)
CY7C384                                          CY7C384A-XJC                   (Honeydol, Maddonna)
CY7C421                                                                         (Rfjet)
CY7C1019        128k x 8 SRAM, SOJ32             CY7C1019BV33-15VC              (Gamshara)




LGS + Goldstar RAM           PCB note
------------------------------------------------------------------------------------------------------------
71C4260         SOJ40                            LGS GM71C4260AJ70              (Metmqstr)
76C28           2k x 8 SRAM                      LGS GM76C28A, GM76C28K, Goldstar GM76C28A, GS GM76C28 (Twincobr), KT76C28K (Crazywar)
76C88           8k x 8, SOP28                    LGS GM76C88ALFW
76C256          32k x 8 SRAM, SOP28              LGS GM76C256BLL, Goldstar GM76C256ALL (Fortecar), GM76256 (Crysking)




Mitsubishi RAM               PCB note
------------------------------------------------------------------------------------------------------------
M5M410092       TQFP128                          M5M410092FP                    (Harley)
M5M44170                                         M5M44170CJ                     (Bel)
M5M442256                                        M5M442256AJ, M5M442256AL       (Eggventr)
M5M44260        256k x 16 DRAM, 4MBit                                           (Cbaj, Capcom ZN1/2)
M5M4464                                                                         (Brapboys, SegaSystem24)
M5M4V4169                                                                       (Harley)
M5M4V4265       256k x 16 DRAM, TSOP40/44                                       (NamcosSystem32)
M5M51008        SOP32                            M5M51008AFP                    (Outfxies)
M5M5165                                                                         (Angelkds)
M5M5178         8k x 8 SRAM, DIP28               M5M5178AFP, M5M5178AP          (Model1, NamcoSystem22)
M5M5179                                          M5M5179AJ                      (Airco22b, Gollygho, Luckywld)
M5M5189                                                                         (Cybsled)
M5M5256         SOP28                            M5M5256BFP                     (Vshoot)
M5M5278                                          M5M5278P                       (Titlef)
M5M5517         2048 x 8 SRAM                    M5M5517P, M5517P               (40love, Gyrodine)




SEC + Samsung RAM            PCB note
------------------------------------------------------------------------------------------------------------
KM4116V256                                       KM4116V256G, KM416C256         (Gaia)
KM416S1020      16M SDRAM, TSOB48                                               (GP500, NamcoSystem23)
KM416V256                                        KM416V256BLT                   (Konami-GV)
KM416C1200                                       KM416C1200CJ                   (Gauntdl)
KM416C1204        2M x 8 DRAM, SOJ42             KM416C1204AJ, KM416C1204CJ     (Finalgdr, Ppcar, Ssfindo)
KM416V1204        1M x 16 EDO DRAM, TSOP44       KM416V1204BT, KM416V1204CT     (NamcoSystem12, GNET-System)
KM4216C256      256k x 16                                                       (Radikalb, Surfplnt)
KM4216V256                                                                      (Cryptklr)
KM424C257                                                                       (Alpinerc)
KM428C256       256k x 8 Dual Port DRAM, SOJ40   KM428C256J, KM428C256TR        (Aligator, Bang)
KM44C256                                         KM44C256BT                     (Pntnpuzl)
KM48V514        512k x 8 (4MBit) DRAM, SOJ28     KM48V514BJ, KM48V514DJ         (Capcom-ZN-1+2, Tecmowcm)
KM6161002        64k x 16 CMOS SRAM, SOJ44       KM6161002BJ, KM6161002CJ       (Xfiles, Kdynastg)
KM62256                                          KM62256BLS, KM62256CLP         (Fromanc2, Wbbc97)
KM6264                                           KM6264AL, KM6264BLS            (Jollycrd, Brapboys)
KM681000       128k x 8 SRAM, SOP32, SMD         KM681000ALP, KM681000BLG       (Splash, Silkroad)
KM681002       128k x 8 SRAM, SOJ32                                             (CPS3)
KM68257                                                                         (Scud, Hotdogst)
KM68658                                                                         (Kickgoal)




Sony RAM                     PCB note
------------------------------------------------------------------------------------------------------------
CXK5813         2k x 8   SRAM                    CXK5813D                       (Robowres)
CXK5814                                          CXK5814P                       (Pairsnb)
CXK5816                  SRAM                    CXD5816SP                      (Bcstry, Meijinsn, Shougi)
CXK58257        32k x 8  SRAM, SOP28             CXK58257ASP, CXK58257AP        (Drivedge, 32k)
CXK58258                                         CXK58258BP                     (Powerins)
CXK5863         8k x 8   SRAM, DIP28             CXK5863BP, CXK58638P, 5863P    (CPS2, Fromanc2)
CXK5864         64k      SRAM                    CXK5864ASP, CXK5864PS          (Le2, Truxton, Wildfang)
CXK581000                                                                       (Grdians)
CXK581001                                                                       (Gundamex)




Signetics RAM                PCB note
------------------------------------------------------------------------------------------------------------
8202            RAM or ROM?                      INS8202N, 8202                 (Astrof, Portrait)
82S09           RAM or ROM?                      N82S09                         (Spaceg, StrikesAndSpares, Turbo, Wwjgtin )
8205            RAM or ROM?                      INS82LS05N                     (Astrof)
82S16           256bytes x 1bit Bipolar DRAM     N82S16N                        (Wwjgtin, Amspdwy, Rescue, Tripool, Striv)
82S19           RAM on the Video Board                                          (Mrflea)



Other RAM
---------
AAA16K4P (Wildfang)
AAA64K1P (Powerins)
Nintendo RDRAM18-NUS (Mtetrisc)






R3.1   SRAM

61L256S           = (32K x 8 bit High Speed CMOS SRAM) (Finalgdr)
BS616LV1010       = (64k x 16 SRAM, TSOP44)   (DemonFront)
IMS1630           = IMS1630LH, IMS1630LN (General-Purpose Static RAM, DC Output (25mA), 2V Data Retention, Low Power) (Palamed)
MT4C1M16E5DJ      = (72 PIN SIMM Memory modules) (A51site4)
MT48LC1M16AT      = (Gauntdl)
MT5C1008          = (128k x 8 SRAM) (MetalManiax)
24257             = Winbond W24257, W24257S, W24257AJ (32k x 8 SRAM)
435101            = Hitachi HM435101 (General-Purpose Static RAM) (Fastdraw)


R3.2   SGRAM

54V25632          =  OKI 54V25632 (256k x32 SGRAM, QFP100)                             (Gamshara)
KM4132G271        =  Samsung KM4132G271Q,KM4132G271BQ  (128k x 32 x 2 banks SGRAM, QFP100)   (Glpracr)




R3.3   DRAM

MB461       (Beezer)
MB8118      (Chboxing, Chwrestl, Laserbas)
MB8128    = Fujitsu MB8128 (2k x 8 SRAM, DIP24) (Robowres, Sega-System16a)
MB8146    = MB8146A (USG32)
MB81416   = Fujitsu MB81416, MB81416A, MB-81416 (4bit x 16384, DRAM) (40love)
MB81464     (Luckywld)
MB81466   = Fujitsu MB81C466 (System 24)
MB814256  = Fujitsu 81C4256 (256k x 4 DRAM, SOJ24)
MB814260  = Fujitsu 814260  (256k x 16 DRAM 4MBit, SOJ40) (Beastrzr, Loderndf)
MB8178    = Fujitsu MB81C78A (8k x 8 SRAM ?, SOP28) (SegaSystem24, Cyclwarr, Smgp)

4464      = NEC D4464c, Panasonic MN4464M (64k x 4 DRAM, DIP18)
45160     = TI TMS45160DZ (256k x 16 DRAM)
418160    = TI TMS418160ADZ (1MB x 16 DRAM)
424210    = uPD424210 (256k x 16 DRAM, SideBs2)
424260    = NEC 424260, NEC 42S4260 (SMD, Jchan, Mk3) (256k x 16 DRAM, SOIC40, SideBs2)
424805    = 424805AL (512k x 8, 4MBit DRAM, SOJ28)
4218160   = (2MB x 8 / 1MB x 16 DRAM) (Sidebs, Sidebs2)

591616    = Toshiba TC59S1616AFT (512k-Words x 2-Banks x 16-Bits SDRAM, TSOP50) (11beat, Harley, Sega-Model3)
514256    = M514256, TC514256BZ, MCM514256, HM5142560JP8, OKI M514256  (1M DRAM)
514260    = M514260C (SOIC40), HY514260B, Hitachi HM514260JP8, TC51V4260BJ (256k x 16 DRAM, 4MBit DRAM, SOJ40)
5118164   = Hyundai HY5118164CJC, HY51V18164BJC (SOJ42) (16M x 16 DRAM) (Misncrft, Sscope2)
57651620  = Hyundai HY57V651620 (4MB x 16 SDRAM, SSOP54) (Crysking)

71C18160  = LG Semiconductor GM71C18160CJ6 (1M x 16 DRAM, SOJ42) (Klondkp)



R3.4   EDO RAM

321664    = Sanyo LC321664AJ   64k x 16 EDO DRAM (SOP40)              (Raystorm)
41LV16100 = ISSI IS41LV16100S 1M        EDO DRAM (TSOP50/44) Type II  (Mrdrilr2)
41LV16256 = ISSI IS41LV16256  256k x 16 EDO DRAM TSOP44/40   Type II  (Mrdrilr2), 16256 (Spotty)
416V1204  = Samsung KM416V1204BT-L5- 1M x16 EDO DRAM  (TSOP44/40)     (Sfex2, NamcoSystem12, GNET-System)
416V2540  = Samsung KM416V2540  256k x16 EDO DRAM (TSOP40/44)         (Gp500)
4E151611  = Samsung K4E151611C-JC60 1M x16Bit CMOS EDO DRAM (SOJ44)   (Kdynastg)
71C18163  = LG Semi GM71C18163, Hynix GM71C18163, 1M x16 EDO DRAM (SOJ44) (Suplup)
81C256K16 = Silicon Magic SM81C256K16CJ 100MHz EDO RAM, 4Meg          (Gauntleg, Gauntleg, Gradius4, Sscope2)




R3.5   VRAM

55160   = TMS55160DGH      256k x 16                            (MetalManiax)
81461   = MB81461          256k VRAM                            (Volfied)
548262  = M548262          256k x 8, Fastpage VRAM              (Pkgnsh, Realbrk)
44C251  = TMS44C251        256k x 4 Dual Port VRAM, ZIP28       (Mjdchuka)
42C4064 = MT42C4064Z        64k x 4 VRAM                        (Gtg, Hstennis, Ninclown, Wfortune)
42C8128                                                         (Mk3)


R4.    NVRAM (Non Volatile RAM)

- 0.104              : Mathis Rosenhauer fixed NVRAM handling in Star Wars/ESB (only affects test mode).
- 0.103u1            : smf hooked up nvram in Frenzy memory map.
- 0.99               : Brian Troha hooked up NVRAM for World Class Bowling Tournament (v1.40).
- 0.96u4             : Aaron Giles added thrash protection emulation to the NVRAM in coolpool.c.
- 0.88u2             : Frank Palazzolo added NVRAM handling to Robby Roto and Professor PacMan (still not working always but self-tests pass) and support stereo in Wizard of Wor, Robby Roto, Gorf and Professor PacMan (Sounds great now!!). Added 'Reset on powerup', 'Halt on error', 'Beep', 'ROM' and 'Unknown' dipswitch.
- 0.84u5             : smf hooked up NVRAM for Namco system 12 correctly.
- 0.83               : Justin Szczap added NVRAM to Spiders.
- 0.77               : Curt Coder fixed Cue Brick NVRAM handler.
- 0.76u2             : Aaron Giles added some pre-initialization to the WarGods NVRAM.
- 18th June      2002: HobbesAtPlay submitted a patch to add saving the NVRAM in Tri-Sports.
- 18th January   2001: David Graves added NVRAM emulation to Slap Shot.
-  4th December  2000: Aaron Giles fixed a NVRAM bug in Rim Rockin' Basketball.



R4.1   DALLAS

R4.11  DS1220
- PCB: DALLAS DS1220Y  16k  DIP24 (Ghosthunt, RapidFire, Strvmstr, Tickee)

R4.12  DS1225
- PCB: DALLAS DS1225Y  16k Non-volitile RAM (MegaTouch 3/5)

R4.13  DS1230
- PCB: DS1230 NV RAM (Megat6)

R4.14  DS1235
- PCB: DALLAS DS1235Y non-volatile SRAM (Passsht)


R4.2   FM1208
- PCB: RAMTRON FM1208S 4096bit Nonvolatile Ferroelectric RAM, 512 x 8, DIP24 (Raystom, Taito GNET-System)



R5.    NOVRAM

R5.1   2055
- NOTES: NOVRAM used by Atari games to save high scores.
- PCB: ER2055 (Qwak), ER-2055 (Caterpillar Olympia 1980)

R5.2   2212
- SOURCE: drivers\starwars.c  - AM_RANGE(0x4500, 0x45ff)  = 256
- PCB: Xicor 2212, 256x4, NOVRAM (Esb)

R5.3   2816
- PCB: Little 2x12 pin chips labeled XICOR X2816BP (Klax), KM2816A (Cheyenne)



R6.    Buffer

R6.1   81LS95
- PCB: The DM81LS95 is a 3-STATE Octal Buffer or TriState buffer (Portrait), DM18LS95N or DM18LS97N (Astrof)

R6.2   CY7B991
- PCB: Programmable Skew Clock Buffer, PLCC32 (Sidebs, Sidebs2, Landgear)

R6.3   4050
- PCB: Toshiba TC4050BP Non-Inverting Hex Buffer / Converter,  DIP16 (Champbwl), 4050 (Pairlove, 11beat, Magical, Mtetrisc)



R7.    FIFO

R7.1   LH5496
- PCB: Sharp LH5496D-50 Asynchronous FIFO, DIP28 (Ejanhs, Rdft, Rdft2, Rfjet, Senkyu, Viprp1)

R7.2   LH540202
- PCB: LH540202U  CMOS 1024 x 9 Asynchronous FIFO, PLCC32 (Cbaj, ZN1/2)

R7.3   7200
- PCB: Integrated Devices Technology IDT7200  256 x 9 CMOS Asynchronous FIFO (NamcoSystem23)

R7.31  7201
- PCB: IDT 7201 LA 35J, 512 x 9 Async FIFO (Blitz99), AMD AM7201-35JC (Gauntleg)

R7.32  7203
- PCB: AM7203A (GTIClub)

R7.4   ACT7814
- PCB: ACT7814-25  64 x 18 strobed FIFO (MetalManiax)

R7.5   KM75C02
- PCB: Samsung KM75C02 FIFO RAM, DIP28 (Sliver)



R8.    Battery backed RAM

R8.1   449
- PCB: Battery backed up NEC D449C ram (Gepoker)

R8.2   5164
- PCB: P5164SL battery SRAM (Gtg2, Stratab), P5164  8k x 8 RAM (Gtg), P5164S (Hstennis, Peggle, Slikshot)

R8.3   M4T28
- PCB: ST M4T28-BR12SH1 Timer Keeper Snap Hat RAM (Gauntleg, Gauntdl)

R8.31  M48T58
- 0.93u2: M48T58 / M48T58Y emulation, used by hornet and others [smf].
- SOURCE: machine\timekpr.c
- PCB: M48T58Y-70PC1 ST Mirco Timekeeper RAM with internal lithuim battery, 8k x 8, DIP32 (Dstage, Gradius4)

R8.4   MK48T02
- PCB: MK48T02B-15 TIMEKEEPER RAM (MetalManiax)

R8.41  MK48T08
- 0.101u4            : smf removed code that reset the timer when reading/writing on the mk48t08 timekeeper chip.
- 0.95u3             : smf commented out logerror's in timekpr.c.
- 0.93u2             : Added machine\timekpr.c.
- SOURCE: emu\machine\timekpr.c
- PCB: ST MK48T08B-10 TimeKeeper Ram - Lithuim Battery backed RAM chip (8k x 8) (Opwolf3), MK48T08B-10 Battery Backup SRAM (Slapshot)

R8.5   MK48Z02
- PCB: MK48Z02B-15 ZEROPOWER RAM (MetalManiax, Amerdart)

R8.51  MK48Z08
- PCB: M48Z08-100PC1 Zero Power RAM (Monglfir)



R9.    Battery

R9.1   2032
- PCB: Sony CR2032 3 Volt Coin Battery (Stmblade, Sega System24), CR-2032 battery (Hyperspt), 3 Volt coin battery for use with DS2404S (Viprp1)

R9.2   2325
- PCB: 2325 battery (Blitz99)

R9.3   5104
- NOTES: The Tadiran TL-5104 3.6V lithium (AA-sized) is for battery backup's.
- GAMES: Ataxx (Leland 1990)

R9.4   QTC85
- PCB: Battery QTC85 AA 3B960 (Truco)




 


DECLARATION



Hex table
---------

              16  = 0x10
              32  = 0x20
              64  = 0x40
             128  = 0x80
             256  = 0x100
             512  = 0x200
  1k  =     1024  = 0x400
  2k  =     2048  = 0x800
  4k  =     4096  = 0x1000
  8k  =     8192  = 0x2000
 16k  =    16384  = 0x4000
 32k  =    32768  = 0x8000
 64k  =    65536  = 0x10000
128k  =   131072  = 0x20000
256k  =   262144  = 0x40000
512k  =   524288  = 0x80000
 1MB  =  1048576  = 0x100000
 2MB  =  2097152  = 0x200000
 4MB  =  4194304  = 0x400000
 8MB  =  8388608  = 0x800000
16MB  = 16777216  = 0x1000000
32MB  = 33554432  = 0x2000000
64MB  = 67108864  = 0x4000000





Hexadecimal / Binary
--------------------

 0  = 0000
 1  = 0001
 2  = 0010
 3  = 0011
 4  = 0100
 5  = 0101       Examples:   $9A = 0x9A = 1001 1010
 6  = 0110                   $17        = 0001 0111
 7  = 0111                   $EF        = 1110 1111
 8  = 1000
 9  = 1001
 A  = 1010
 B  = 1011
 C  = 1100
 D  = 1101
 E  = 1110
 F  = 1111



ASCII code
----------


30 31 32 33 34 35 36 37 38 39 
-----------------------------
 0  1  2  3  4  5  6  7  8  9


41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A
-----------------------------------------------------------------------------
 A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z


61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A
-----------------------------------------------------------------------------
 a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s  t  u  v  w  x  y  z


20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F    3A 3B 3C 3D 3E 3F 40    5B 5C 5D 5E 5F 60
-----------------------------------------------    --------------------    -----------------
    !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /     :  ;  <  =  >  ?  @     [  \  ]  ^  _  ` 





Resistor table
--------------

Color     Value    Multiply        Tolerance

Silver              x 0.01         +/-  10 %
Gold                x 0.1          +/-   5 %
Black       0       x 1                            * To get the ohm value of a resistor you
Braun       1       x 10           +/-   1 %         must read the colors rings from left to
Red         2       x 100          +/-   2 %         right. The last two rings on the right side
Orange      3       x 1k                             are the Multiply and the Tolerance ring.
Yellow      4       x 10k
Green       5       x 100k                           Example:
Cyan        6       x 1M                             A resistor with the following colors:
Violet      7       x 10M                            Red (2), Black (0), Orange (1k) and Gold
Grey        8                                        has 20k Ohm (20 x 1k) and a 5% tolerance.
White       9                      +/-  20 %         This is RES_K(20) in the MAME C-source.




NAMES TABLE
-----------

A/D    = Analog Digital
AC     = Alternate Current
ADC    = Analog Digital Converter
ADPCM  = Adaptive Delta Pulse Code Modulation 
ADSP   = Analog Device Single Processor
AGP    = Accelerated Graphics Port
AI     = Audio Interface
ALU    = Arithmetic Logic Unit
ANSI   = American National Standards Institute
API    = Application Program Interface
ARP    = Address Resolution Protokoll
ASCII  = American Standard Code of Information Interchange
AT     = Advanced Technology
ATA    = Advanced Technology Attachment
ATAPI  = Advanced Technology Attachment with Packet Interface
BBS    = Bulletin Board System
BCD    = Binary Coded Decimal 
BDOS   = Basic Disk Operating System
Bit    = Binary Digit (0 or 1)
BIOS   = Basic Input/Output System
Byte   = 1 Byte = 8 bits
CCP    = Control Command Processor
CDROM  = Compact Disk - Read Only Memory
CGA    = Color Graphics Adapter
CHD    = Compressed Hunks of Data
CIA    = Complex Interface Adapter
CISC   = Complex Instruction Set Computer
CP/M   = Control Program for Microcomputers
CPU    = Central Processing Unit
CR     = Control Register
CTC    = Counter/Timer Controller
D/A    = Digital Analog
DAC    = Digital Analog Converter
DAT    = Digital Audio Tape
DC     = Direct Current
DD/2D  = Double Density (floppy disk)
DDR    = Data Direction Register / Double Data Rate (RAM)
Disk   = Floppy Disk (Format: 3 1/2 and 5 1/4 inch)
DOS    = Disk Operating System
DS     = Double Sided (floppy disk)
DMA    = Direct Memory Addressing (NOT the usual term of Direct Memory Access)
DNS    = Domain Name Service
DRAM   = Dynamic Random Access Memory
DSP    = Digital Single Processor
DRC    = Dynamic ReCompiling
DUART  = Dual Universal Asynchronous Receiver Transmitter (=2*UART)
EAROM  = Electrically Alterable ROM
EEPROM = Electrically Erasable Programmable ROM
EDORAM = Extended Data Output RAM
EIA    = Electronics Industries Association
EIDE   = Enhanced Intelligent/Integrated Drive Electronics 
EOT    = End Of Transmission
EPROM  = Erasable Programmable ROM
FIFO   = First In - First Out (buffer)
FILO   = First In - Last Out (buffer)
FMV    = Full Motion Video
FM     = Frequency modulation
FPGA   = Field Programmable Gate Array
FTP    = File Transfer Protocol
GAL    = Gate Array Logic
GPU    = Graphics Processsor Unit
HD     = High Density (floppy disk)
HDD    = Hard Disk Drive
HTTP   = Hypertext Transfer Protokoll
IC     = Integrated Circuit
IDE    = Integrated Drive Electronics
IEEE   = Institute of Electrical and Electronics Engineers
I/O    = Input/Output
IP     = Internet Protocol
IPX    = Internetwork Paket Exchange Protocol
IRQ    = Interrupt ReQuest line
ISA    = Industrie-Standard-Architektur
ISDN   = Integrated Services Digital Network
JEDEC  = Joint Electron Device Engineering Council
JFET   = Junction Field Effect Transistor
ISO    = International Standards Organization
JPEG   = Joint Photographics Expert Group  
LAN    = Local Area Network
LCD    = Liquid Crystal Display
LED    = Light Emitting Diode
LFO    = Low Frequency Oscillator
LLC    = (Logical Link Control
LPC    = Linear Predictive Coding
LRC    = Longitudinal Redundancy Check
LSI    = Large Scale Integration
MCU    = Micro Controller Unit
MHS    = Message Handling System
MIPS   = Million Instructions Per Second
Modem  = Modulator/Demodulator
MOS    = Metal Oxide Semiconductor
MPEG   = Motion Picture Expert Group
MPU    = Micro Processing Unit
MSI    = Medium Scale Integration
NMI    = Non Maskable Interrupt
NTSC   = National Television System Commitee
NVRAM  = Non Volatile RAM
OTP    = One Time Programmable
OPTO   = Light Sensor Package (Chip) 
PAL    = Programmable Array Logic
PAL TV = Phase-Alternation-Line TV
PDR    = Port Direction Register
PLD    = Programmable Logic Device
PCI    = Peripheral Component Interconnect
PCM    = Pulse Code Modulation
PCMCIA = Personal Computer Memory Card International Association
PWM    = Pulse Width Modulation
PPCM   = Packed PCM
PIA    = Peripheral Interface Adapter
PIO    = Parallel Input Output
PIT    = Programmable Interval Timer
PLD    = Programmable Logic Device
PPI    = Parallel Peripheral Interface
PPP    = Point To Point Protokoll
PROM   = Programmable ROM
RAM    = Random Access Memory
RGB    = Red Green Blue
RIOT   = RAM I/O TIMER
RISC   = Reduced Instruction Set Computer
ROM    = Read Only Memory
ROZ    = ROtate and Zoom
RS-232 = Recommended Standard 232
RTL    = Resistor Transistor Logic
SAP    = Service Advertising Protocol
SATA   = Serial Advanced Technology Attachment
SCI    = Serial Controller Interface
SCSI   = Small Computer System Interface
SD/1D  = Single Density (floppy disk)
SDRAM  = Synchronous Dynamic RAM
SGRAM  = Synchronous Graphics RAM
SI     = Standard Interface
SIMM   = Single Inline Memory Module
SIO    = Serial Input/Output 
SM     = Surfaced Mounted
SMB    = Server Message Block-Protokoll
SMTP   = Simple Mail Transfer Protocol
SNA    = SubNet Access Protocol
SPX    = Sequenced Packet Exchange
SPU    = Sound Processsor Unit
SQL    = Structured Query Language
SRAM   = Static RAM
SPU    = Sound Processor Unit
SS     = Single Sided (floppy disk)
TCP    = Transmission Control Protocol
TTL    = Transistor Transistor Logic
UDMA   = Ultra Direct Memory Access
VGA    = Video Graphics Adapter
VFO    = Variable Frequence Oscillation
VIA    = Versatile Interface Adapter
UART   = Universal Asynchronous Receiver and Transmitter
USART  = Universal Synchronous/Asynchronous Receiver/Transmitter
USB    = Universal Serial Bus
UDP    = User Datagram Protocol
VRAM   = Video RAM
WRAM   = Windows RAM
WWW    = World Wide Web



PACKAGE NAMES
-------------
P = Plastic, C = Ceramic and M = Metal 

BGA    = Ball Grid Array
CPLD   = Complex Programmable Logic Device
CZIP   = Ceramic Zig-Zag Inline Package
DIP    = Dual Inline Package
DIL    = Dual In-Line
LCC    = Leaded Chip Carrier 
LSI    = Large Scale Integration
MQFP   = Metal Quad Flat Package 
MSI    = Medium Scale Integration
PGA    = Pin Grid Array
PLCC   = Plastic Leaded Chip Carrier
PQFP   = Plastic Quad Flat Package 
QFP    = Quad Flat Package
SDIP   = Shrink Dual Inline Package
SIL    = Single Inline
SIP    = Single Inline Package
SMD    = Surface Mounted Device
SOIC   = Small Outline IC (Integrated Circuit)
SOJ    = J-Leaded Small Outline Package
SOP    = Small Outline Package
SSOP   = Shrink Small Outline Package
TQFP   = Thin Quad Flat Package
TSOP   = Thin Small Outline Package
VLSI   = Very Large Scale Integration
VSOP   = Very Small Outline Package
ZIP    = Zig-Zag Inline Package



BOARD
-----

68k    = Motorola 68000
AMP    = Amplifier
BATT   = Battery
BD     = Board
BG     = BackGround
BKG    = BackGround
BPROM  = Bi-polar Prom
AUX    = Auxiliary
CLK    = Clock Crystal
CLR    = Color Prom
CNx    = Connection
CHR    = Character
CRAM   = Colour RAM
CRC    = Checksum
CRT    = Graphic/Video
CRTC   = Video Controller
DIPSW  = Dipswitch
DSW    = Dipswitch
DTH    = Dr Math PCB
EPR    = EPROM
FG     = ForeGround
GFX    = Graphics/Video PCB
GIB    = Gun Interface PCB
HD     = Hard Drive
HST    = Host PCB
HSync  = Horizontal Syncronization  
ID     = File IDentification
LB     = Lower Board
LOC    = Location
LSB    = Least Significant Bit
nS     = nano Seconds
MB     = Middle Board
MCLK   = Main Clock Crystal
MUX    = Multiplexer
OBJ    = Object/Sprite
OBN    = Motion Objects
OSC    = Oscillator/Clock Crystal
OST    = Oscillator
PCB    = Printed Circuit Board
PGM    = Program ROM
Piggy  = Piggy-backed
POT    = Potentiometer  (BASS, TREBLE, BALANCE, LEFT/RIGHT and VOLUME)
PQFP   = Plastic Quad Flat Package
PSG    = Programmable Sound Generator
PWR    = Power Supply
QFP    = Quad Flat Package
RTC    = Real Time Clock
SCN    = Screen/Background
SND    = Sound / Sound PCB
SPTHX  = Special Thanks
SSB    = Speech/Sound PCB
SW     = Dipswitch
TB     = Top Board
TQFP   = Thin Quad Flat Package
TX     = Text (Scroll)
VGB    = Video Graphics PCB
VID    = Video
VDC    = Volt Direct Current (=> +5vdc)
VDP    = CRT controller
VRAM   = Video RAM
VSync  = Vertical Syncronization  
XTAL   = Crystal (also X1, X2,...)



PREFIX      MANUFACTURER                         EXAMPLES
-----------------------------------------------------------------------

ADM         Analog Devices                       ADM690
AM          AMD                                  AM27C512
AK          Asahi Kasei Microsystems             AK4309
AT          Atmel                                AT27C080, AT28C16
CY          Cypress                              CY7C109
CXK5        Sony                                 CXK5808
D           NEC                                  D2732D
DS          Dallas                               DS1220
EL          Elantec Semiconductor                EL2386
GLT         LG                                   GLT725608
GM          Goldstar, LGS                        GM76C28K, GM76C88ALFW, GM76C256BLL
HN          Hitachi                              HN27C4096, HN462708
HY          Hyundai                              HY6264
ICS         Integrated Circuit Systems           ICS9120
IDT         Integrated Devices Technology        IDT7200
INS         National Semiconductor               INS8080AD
IS          ISSI                                 ISSI IS61C68
JRC         Japan Radio Co.                      JRC2902
KM          Samsung, SEC                         KM29W32000AT, KM4116V256G
LC          Sanyo                                LC3517
LH          Sharp                                LH5763J
LM          National Semiconductor               LM385, LM833
LT          Linear Technology                    LT1084
M           ST Microelectronics                  M271000ZB, M533202
M5          Mitsubushi                           M5L2764K, M5L27128K
MC          Motorola                             MC68B09EP, MC68705P5
MB          Fujitsu                              MB8422
MK          MOSTEK                               MK4027
MM          National Semiconductor               MM5437
MMI         ?                                    MMI6301
MN          Panasonic                            MN414260
MP          Micro Power Systems                  MP1210
MR          OKI                                  MR27V12800, MR27C3252CZ
MS          Mosel                                MS6516
MSM         OKI                                  MSM2128
MX          Macronix                             MX27C2000
N           NKK                                  N341256
NJM         ?                                    NJM3414
NMC         NS                                   NMC27C256Q
P           Intel                                P27256
PT          Proton                               PT8010AF
SLA         Sanken Electric Co.                  SLA4060
SN          Signetics                            SN82S131N, N82S137N
SM          Silicon Magic                        SM81C256K16CJ
SMC         Standard Microsystems                SMC FDC37C932
ST          ST Microelectronics                  ST7705C
SY          Synertek                             SY6545
TC          Toshiba                              TC531000, TMM2009
TDA         Philips                              TDA1519, TDA1543
TMS         Texas Instruments (TI)               TMS27C010
UCN         Allegro MicroSystems                 UCN5801A
UM          Unicorn Microelectronics             UM6164DS
uPB         NEC                                  uPB426
uPD         NEC
V           Vitelic                              V52C8128K70
W           Winbond                              W24257
X           Xicor                                


Afega  = Art-Fiction Electronic Game
CAPCOM = Japan Capsule Computers
CPS    = Capcom Play System
IREM   = International Rental Electronics Machines
PSE    = Project Support Engineering
SSS    = Success Corp.
SSV    = Seta, Sammy and Visco



 


MEMO


OTHER
-----
1718 = XILINX 1718DPC: Kdeadeye
1736 = XILINX 1736DPC, labelled 3302: MetalManiax
1765 = XILINX 1765DPC: MetalManiax
21859 = Altera PLCC Seattle A-21859: Blitz99
2465: Krzybowl
3631 (DIP18): Mjchuuka, Mjdchuka
3384 = 3384q 10bit bus switch?: Gauntdl
4064: Lastfort
45055: IDsoccer
5216: Lastfort
53323: Buckrog (=Mitsubishi M533xx =LS23 ?)
53354: AttackUfo (=Mitsubishi M533xx ? =LS54)
57C55LK: Ttchamp
58256: NeoGeo
6262: Cairblad
6269: Lstfort
6508 = 6502 ?: Astrof
6520 = SY6520: JackPottensPoker
6820 = SY6820: Copsnrob, JackPottensPoker
70337: Firebarr
70C178 = UMC UM70C178 (Ram or gfx ctrl?): Cheesech
71AJC46A (SOIC8): Harley
75365: Buckrog
75LBC176: Radikalb, Surfplnt
7801 (Square Konami Chip labeled "7801"): Fastlane
78081 = NEC_78081G503: ZN games
7910: Rockclim       ----------7910C  Multi-Melody IC  Epson  
7can2 4k, SOIC, Texas Instruments: Blitz99
8010 = Proton PT8010AF PLCC (Filetto)
8117yu: Buckrog
8228 = ECG8228 = i D8228: Fastdraw, Draw Poker Hi-Lo
8329X5: Kchamp
9218 = AMD AM9218BPC (maskroms ?): Tempest
9312 = TRW9312HH: Dcheese
9325-AG (Elliptical Filter): Bmcbowl
9343T (QFP44): Bloodwar
A082: Jail Break
AL9106(QFP64) ALPHA?: MahjongTenkaigen
AMT001: IQBlock
ASSP 5C105: Radm
BI 898-3-R 22  8920  (?, DIP16, tied to HD63484): Kothello
BU6244KS = BIG BODY 2 BU6244KS 704 157, QFP56: Polystar
C118 = NEC C118H: Espial
C159 = NEC C159A: Buckrog
CDP1855 = RCA CDP1855CDX 201 (noise generator?): Lgp
CF37201: IDsoccer
CA810AQM (sound): Invaders
D31B3100: Murogem
D481165 = D4811650GF: Harley
D482445 = D482445LGW-A70 = DRAM?: Btchamp, Sidebs/2, KonamiGVSystem
D49307 = HITACHI DF1 D49307: suprnova.c
DAC76: Beezer
F119708APCM = Nbajam
FCU-2 = FCU-2 8J1: Truxton
GEN6480830 (Texas Instruments): PachiFever
GW6582: Chameleon 24-in-1
HM9253101: Zombraid
iP8275: Dwarfd
KC89C72: Monglfir, Pool10, Soccernw
L4A0270: Atomicp - LSI LOGIC L4A0270
L5220574: Megat3
LGS GD75232 (SOIC20): A51site4
LGS Prime 3C 9930R (QFP100), Prime 3C 9849R: SeeSeeFindOut, Ppcar
LVX125: 11beat, Mtetrisc
M24CL16-S: Bballoon
M6395 (= Mitsubishi M63954P ?? Power MOSFETs: HVIC series): Dharma
M58715 = Mitsubishi M58715-051P (SRAM or AY-3-8910 sound like in clone Masao ?): Mario
M60067 = Mitsubishi M60067-0901FP 452100 (QFP208, GA1): Gogomile, Pbancho
M9524LT = Possibly some sort of RGB video output chip: Ncv1/2
MAB8031AH = Philips MAB8031AH MCU = I8031?: Chelnov
MD0204 = Fuji MD0204 JAPAN F39D110, QFP128: Sliver
MDP1601-102G, MDP1603: Dwarfd 
MB112S146 (MCU ?): Arkanoid
MB14282: R2dtank, Spiders
MB14368: R2dtank
MB4391: Buckrog, 005 (audio\segar.c)
MB87316: Thunderj, Xybots (40-pin)
MB89372 = Fujitsu MB89372P-SH, SDIP64 (RAM ?): SuperMonacoGP
MO-92000 (DIP64): 47pie2, Suchipi
MM54104 digitalker speech: Scorpion
NB19010 and NB22090: Mahjong games
NTA0002 (QFP80): Chameleon 24-in-1
NVC285: Puckman
PB255a: Megat3
P620B: Polepos2
PC165500N: MegaTouch3/5
RY050012 (Texas Instruments): PachiFever
S9052AB (PLCC 80): Steeltal
SH2-102, SH3-555: Wiping
SIS6091 QFP80  (Graphics controller?): Kothello
SPR800E OP-CX1, QFP208: 1945kiii
ST010 (Custom chip): Drifto94
T062 Op AMP?, SOIC8: NamcoNA2
T6R8139: Hallyes
TA-06SD 9933 B816453 128 pin square SMD: Puckpkmn
TA891945 = Y-BOX TA891945 100 pin SMD: Puckpkmn
TCA940 (sound): Astrof, Ozmawars
TI 8CA00YF: Gauntdl
TR9C1710 = TR9C1710 6-bit DAC like in CoolPool ? (9ballsht)  SOURCE: drivers\coolpool.c
TV16B 0010 ME251271, 160 pin SMD: Puckpkmn
TZ8315: CycleWarriors
UA010: Rocktris
uPD82157 = NEC uPD82157N7-002 TBGA (huge): Gauntleg
W2466: IQblock
W31001, W31002, W31003, W31004 (Custom ICs ?): CyberTank
XD2210: Portrait
ZC407615CFN (infralink): Hitpoker




TMS42010P: Steeltal
6734: NamcoSystem12
C1891 = NEC C1891ACY, DIP20 (Transistor ?): NeoGeoHyper64
8274 = iP8274: Dwarfd   Similar Part ? = UPD7201AC or FIFO
4AK16: Konami-HornetSystem

---------------------------------------------------------------------------------------------------------------------





Links:
------
CHIP SEARCH: http://www.xs4all.nl/~ganswijk/chipdir/
http://www.datasheetarchive.com/
http://www.datasheets.org.uk/
http://www.chipdocs.com/pnsearch/search.html?rstart=0&firm=0&keyword=????
http://www.stormaster.com/Spies/arcade/simulation/processors/index.html
http://www.dsplib.com/chips/sp025x.html
http://www.coinopexpress.com/products/pcbs/pcb/Chameleon_24_2839.html
http://www.jmpc.com/Starcade/stargames.htm
http://www.alldatasheet.com
http://www.elektronik-kompendium.de/


Dip switch settings:
http://www.solvalou.com/subpage/arcade_dips/
http://www.aut0maten.de/arcadeswitch.php

Arcade Pinouts: http://www.ionpool.net/arcade/pinouts/pinouts.html

Homepage :  http://www.mameworld.net/mameinfo
E-Mail   :  mameinfo@ewetel.net
PCB-Infos:  http://www.mameworld.net/mameinfo/update/PCB-infos0120u4.zip



© 2000-2008  M.A.S.H.

